Machine learning : comprendre les bases sans être mathématicien

Savez-vous ce qui m'a le plus surpris quand j'ai commencé à travailler sur des modèles de machine learning ? Ce n'est pas la quantité de mathématiques qu'il faut connaître. C'est le peu qu'il en faut réellement, à condition d'accepter une chose simple : personne ne vous demandera de démontrer quoi que ce soit à la main.

J'ai animé plusieurs ateliers d'initiation pour des profils très variés : chefs de projet, développeurs web, marketeurs, une ancienne juriste reconvertie. Le point commun de tous ceux qui bloquaient au bout de deux semaines ? Ils ouvraient un cours de machine learning, tombaient sur du calcul matriciel dès la troisième page, et refermaient l'onglet en se disant que ce n'était pas pour eux. C'est faux. Ce qui bloque, ce n'est pas la difficulté des maths. C'est l'ordre dans lequel on vous les présente.

Pourquoi les maths ne sont pas le vrai obstacle

La formule qui revient tout le temps dans les présentations, c'est celle-ci : le machine learning est un ensemble de méthodes où la machine déduit des règles à partir d'exemples, au lieu qu'on les lui écrive à la main. Vrai, mais inutile tant qu'on ne l'a pas vécu.

Prenons un cas concret. J'ai accompagné une équipe qui voulait prédire quels clients allaient résilier leur abonnement. La vraie difficulté n'a jamais été mathématique. Elle a été de répondre à trois questions : qu'est-ce qu'un « client résilié », exactement ? Sur quelle période regarde-t-on ? Et quelles informations avait-on sur lui avant qu'il parte ? Voilà le travail.

Ce que vous devez vraiment savoir

Sur les quatre notions que je retiens, deux vous serviront tous les jours. La moyenne, parce que la plupart des modèles cherchent à ne pas trop s'en écarter. Et l'écart-type, parce qu'il vous dit si une donnée est bizarre ou banale. C'est tout. Pas de démonstration, pas de formule développée. Juste l'intuition.

Les deux autres, la notion de fonction et la probabilité conditionnelle, méritent dix minutes chacune. Une fonction, c'est une machine à transformer une entrée en sortie. La probabilité conditionnelle, c'est la probabilité qu'un événement arrive sachant qu'un autre a eu lieu. Si vous avez déjà dit « ça m'étonnerait qu'il pleuve, le ciel est noir », vous avez fait du raisonnement conditionnel.

Ce que vous pouvez ignorer sans remords

Voilà ma position, et je l'assume pleinement : vous n'avez pas besoin du calcul matriciel pour comprendre le machine learning. Ni des dérivées partielles. Ni de la descente de gradient écrite sous forme d'équation. Ces outils sont ceux des gens qui entraînent des modèles depuis zéro, ou qui les modifient en profondeur.

Si votre travail consiste à cadrer un projet, choisir un outil, ou dialoguer avec une équipe technique, ces sujets vous concernent de très loin. Les apprendre par principe, c'est comme étudier la mécanique des fluides pour savoir nager.

Comment un modèle apprend, sans que vous résolviez une équation

L'analogie que j'utilise à chaque fois, et qui fonctionne étonnamment bien : imaginez que vous êtes sur une colline, les yeux bandés, et que vous voulez descendre jusqu'au point le plus bas. Vous ne voyez rien. Alors vous tâtez le sol sous vos pieds, vous sentez dans quelle direction ça descend, vous faites un petit pas. Puis vous recommencez. Des centaines de fois.

C'est exactement ce que fait un modèle qui s'entraîne. Chaque pas le rapproche d'une situation où il se trompe le moins possible. Vous n'avez pas besoin de savoir calculer l'inclinaison du terrain. Vous avez besoin de comprendre qu'il avance par tâtonnement, et qu'il peut se coincer dans un creux qui n'est pas le fond de la vallée.

La régression, expliquée simplement

Une régression, c'est tracer la courbe qui passe au plus près d'un nuage de points. Rien de plus. Si vous avez déjà ajouté une courbe de tendance sur un graphique Excel, vous avez fait de la régression linéaire sans le savoir.

Ce qui change avec le machine learning, c'est l'échelle et le nombre de variables. Au lieu d'une courbe, on en cherche une qui dépend de trente paramètres à la fois. Mais le principe reste le même : minimiser l'écart entre ce que le modèle annonce et ce qui s'est réellement passé.

Classification ou régression : comment choisir

La question à se poser est bête comme chou. Est-ce que je veux prédire une catégorie ou un nombre ? Classer des e-mails en « spam » et « pas spam », c'est de la classification. Estimer le prix d'un appartement, c'est de la régression.

Je me suis déjà trompé là-dessus, et ça m'a coûté cher. Sur un projet, j'avais modélisé la prédiction du nombre de jours de retard d'une livraison comme une régression classique. Erreur. Ce qui intéressait vraiment le client, c'était de savoir si le colis arriverait en retard ou non. La vraie question était un problème de classification déguisé en régression. J'ai perdu trois semaines avant de m'en rendre compte.

Le vocabulaire qui débloque tout

La « boîte noire », vous l'avez sûrement croisée. L'expression est commode et trompeuse. Elle laisse croire qu'on ne peut rien dire d'un modèle. En pratique, on peut toujours dire quelque chose : quelles données il a vues, ce qu'il optimise, et à quel point il se trompe.

Trois termes reviennent sans arrêt, et les confondre fait perdre un temps fou.

• Entraînement : la phase où le modèle ajuste ses paramètres sur des exemples. La plus longue, la plus coûteuse.
• Inférence : le moment où le modèle entraîné répond à une nouvelle donnée. C'est ce qui tourne en production.
• Surapprentissage : le modèle a tellement bien appris les exemples qu'il ne sait plus généraliser. Un élève qui a révisé par cœur et qui sèche dès que l'énoncé change.

Le surapprentissage est de loin le piège le plus fréquent. Je le détecte aujourd'hui d'une manière simple : quand les résultats sur les données d'entraînement sont excellents et que ceux sur des données neuves s'effondrent, l'alerte est là.

Données d'entraînement et données de test

On ne juge jamais un modèle sur ce qu'il a déjà vu. On met toujours une partie des données de côté, comme une épreuve qu'on garde sous enveloppe. Si un prestataire vous présente des performances calculées uniquement sur les données d'entraînement, méfiance. Ce chiffre ne veut rien dire.

Un parcours pas à pas, sans écrire une ligne de code

Voici comment je conseille de démarrer, dans cet ordre précis. Je l'ai testé sur une dizaine de personnes sans bagage scientifique, et celles qui ont suivi l'ordre sont allées jusqu'au bout. Les autres se sont découragées en quinze jours.

1. Prenez un jeu de données que vous comprenez. Les ventes de votre entreprise, vos propres dépenses. Le sujet doit vous parler.
2. Ouvrez un outil qui fait le travail à votre place. Pas de code au début.
3. Posez une question fermée. « Est-ce que ce client va acheter ? » plutôt que « pourquoi les clients achètent ? ».
4. Regardez les erreurs du modèle, une par une. C'est là que vous apprendrez le plus.
5. Changez une seule chose à la fois, puis mesurez.
6. Refaites l'exercice sur un autre jeu de données, pour vérifier que vous avez compris le mouvement et pas juste recopié une recette.

L'étape 4 est celle que tout le monde saute. C'est pourtant la seule qui vous fera progresser réellement. Un modèle qui se trompe vous en apprend plus qu'un modèle qui tombe juste.

Faut-il apprendre Python pour comprendre le machine learning ?

Non, pas pour comprendre les bases. Vous pouvez saisir ce qu'est un modèle, ce qu'il optimise, et comment il se trompe sans écrire une ligne de code. En revanche, dès que vous voudrez tester vos propres hypothèses sur des données réelles, un langage devient nécessaire. Python reste le plus courant, mais ce n'est pas un prérequis pour la compréhension.

Un modèle entraîné est-il toujours juste ?

Jamais. Un modèle fait des erreurs, et c'est même sa propriété la plus utile à connaître. La bonne question n'est pas « est-ce qu'il a raison ? » mais « à quelle fréquence se trompe-t-il, et sur quels cas ? ». Un modèle qui rate systématiquement les profils rares vous le fera payer cher en production, même avec un score global correct.

Comparer les approches selon votre profil

Deux personnes peuvent apprendre le même sujet par des chemins opposés. Voici ce que j'observe chez ceux qui s'en sortent.

Profil	Ce qu'il faut maîtriser	Ce qu'on peut mettre de côté	Durée réaliste
Chef de projet	Vocabulaire, cycle de vie d'un modèle, lecture des erreurs	Calcul matriciel, dérivées	Un mois, à raison de quelques heures par semaine
Développeur web	Notions de fonction, probabilité conditionnelle, une bibliothèque standard	Démonstrations formelles	Six à huit semaines
Analyste métier	Moyenne, écart-type, qualité des données	Tout le reste au départ	Deux à trois semaines
Futur praticien	L'ensemble, y compris l'algèbre linéaire	Rien	Plusieurs mois, et c'est normal

Ce tableau n'a rien d'une règle gravée. Il reflète ce que je vois autour de moi. La variable qui pèse le plus n'est ni le niveau de maths ni le temps disponible : c'est la capacité à poser une question claire avant de toucher au moindre outil.

La question qui vaut mieux que toutes les formules

Avant d'ouvrir quoi que ce soit, demandez-vous : « Quelle décision cette prédiction va-t-elle changer ? » Si la réponse est « aucune », arrêtez tout de suite. Vous économiserez des semaines.

J'ai vu une équipe passer deux mois à affiner un modèle de recommandation dont personne ne regardait jamais les résultats. Techniquement irréprochable. Inutile. Et ça, aucune formule ne l'aurait détecté.

Ce qu'il faut retenir

Le machine learning n'attend pas de vous que vous soyez mathématicien. Il attend de vous que vous sachiez ce que vous cherchez, que vous compreniez ce qu'un modèle fait en une phrase, et que vous acceptiez de regarder ses erreurs en face plutôt que son score global.

Les formules viendront si vous en avez besoin. La plupart des gens n'en ont pas besoin. Ceux qui s'obstinent à les apprendre avant tout le reste finissent souvent par abandonner avant d'avoir posé leur première question utile.

Alors la prochaine fois qu'un article vous assomme de matrices dès le deuxième paragraphe, fermez-le. Vous ne perdez rien. Vous gagnez le temps qu'il vous aurait pris.