Machine learning : comprendre les bases sans être expert, enfin simple

Un client m'appelle en début d'année, un peu paniqué. Sa boîte de logistique veut « faire de l'IA » sur ses tournées de livraison, et son prestataire lui a envoyé un devis à cinq chiffres rempli de termes qu'il ne comprend pas. Il me demande : « Est-ce que je me fais avoir, ou est-ce que c'est vraiment si compliqué que ça ? » Vingt minutes plus tard, il avait compris de quoi on parlait. Pas parce que je suis un génie, mais parce que personne ne lui avait expliqué les bases du machine learning sans jargonner.

C'est le problème avec ce sujet. Entre les définitions interchangeables qui traînent partout et les cours universitaires, il manque l'étage du milieu : celui qui vous permet de tenir une réunion avec un data scientist sans hocher la tête bêtement. Voilà ce que je vais essayer de combler ici.

Machine learning sans maths : ce qui se passe vraiment

Oubliez les équations deux minutes. L'idée centrale tient en une phrase : au lieu d'écrire une règle à la main, on montre des exemples à la machine et elle devine la règle.

Prenons un cas concret. Vous voulez filtrer les spams. La méthode « classique » consiste à écrire : si le mail contient « viagra », alors spam. Puis « si le mail contient un lien raccourci », puis « si l'expéditeur est inconnu »… Vous empilez des règles. Ça marche trois mois, puis les spammeurs s'adaptent et vous repassez votre week-end à corriger.

L'approche machine learning est différente. Vous prenez 10 000 mails que vous avez étiquetés vous-même « spam » ou « pas spam ». Vous les donnez à un algorithme. Il regarde les mots qui reviennent, leur fréquence, la structure des liens, l'heure d'envoi, et il construit lui-même une frontière statistique entre les deux catégories. Vous ne lui avez pas dit « le mot viagra est suspect ». Il l'a déduit.

L'analogie qui marche à tous les coups

Quand j'explique ça à quelqu'un qui n'a jamais touché à l'informatique, je reviens toujours à la même image. Un programme classique, c'est une recette de cuisine : ingrédients + étapes = plat. Le machine learning, c'est un apprenti cuisinier à qui vous faites goûter cinquante plats réussis et cinquante ratés, et à qui vous demandez de reproduire la recette. Personne ne lui a donné les proportions. Il a goûté.

Le revers de la médaille est immédiat : si vous lui faites goûter cinquante plats ratés par erreur, il apprendra à cuisiner mauvais. Et ça, c'est le problème numéro un de tout projet. J'y reviens plus bas.

Les trois façons dont une machine apprend

Toute la littérature sur le sujet tourne autour du même triptyque. Vous n'avez pas besoin d'aller plus loin pour comprendre 90 % des conversations.

Apprentissage supervisé : celui que vous utiliserez 8 fois sur 10

On donne à la machine des exemples avec la bonne réponse. C'est le cas du filtre à spam. C'est aussi le cas quand un assureur veut prédire le risque d'un sinistre : il a des milliers de dossiers passés, avec, pour chacun, la réponse (a-t-il eu un accident ou non ?). On dit que les données sont « étiquetées ».

C'est de très loin la famille la plus utilisée en entreprise, parce que c'est celle qui donne le résultat le plus prévisible. Elle a un coût caché énorme : quelqu'un doit étiqueter les données. Sur un projet de détection de défauts sur une chaîne de production, un industriel que je connais a passé huit mois à faire annoter des photos par ses techniciens. Huit mois. Le modèle, lui, s'est entraîné en deux heures.

Apprentissage non supervisé : chercher des groupes sans savoir lesquels

Ici, pas d'étiquettes. On donne un gros paquet de données brutes et on demande à l'algorithme de trouver des structures. Typiquement : segmenter une clientèle. On ne lui dit pas « fais-moi trois groupes ». On lui demande de regarder si des comportements se ressemblent, et de les rassembler.

Franchement, c'est la famille la plus séduisante sur le papier et la plus décevante en pratique. Les groupes existent toujours mathématiquement — la machine trouvera des paquets quoi qu'il arrive. La vraie question est : est-ce que ces paquets veulent dire quelque chose pour votre métier ? Une fois sur deux, la réponse est non.

Renforcement : la machine apprend en essayant

Vous connaissez peut-être ce schéma par les programmes qui battent des champions d'échecs ou de go. On ne donne pas de bonnes réponses. On donne un système de récompense, et la machine explore : elle tente une action, reçoit un signal positif ou négatif, ajuste. Elle recommence des millions de fois.

Ce n'est pas réservé aux jeux. Une plateforme de livraison qui optimise l'ordre de ses arrêts en temps réel utilise ce principe. Mais ça reste compliqué à mettre en place, parce qu'il faut un environnement où on peut se tromper sans conséquence — et dans le monde réel, se tromper a des conséquences.

Le vocabulaire qui change tout (et qu'on ne vous explique jamais)

Voici les cinq mots qui reviennent dans toutes les réunions et que la plupart des articles de vulgarisation passent sous silence. Les comprendre, c'est immédiatement parler la langue de vos équipes techniques.

• Features (ou variables) : les informations que vous donnez au modèle. Pour prédire un départ de client, ce sera son ancienneté, son nombre de connexions le mois dernier, le montant de sa facture. Le choix des features pèse plus lourd que le choix de l'algorithme.
• Label : la réponse attendue. « Ce client est parti : oui/non. »
• Découpage entraînement / test : on cache une partie des données au modèle pendant qu'il apprend, puis on lui demande de prédire dessus. Sans ce découpage, on ne mesure rien.
• Surapprentissage (ou overfitting) : le modèle a appris par cœur les exemples au lieu de comprendre la tendance. Il est brillant sur les données qu'il connaît et catastrophique sur le reste. C'est l'erreur la plus fréquente, et de très loin.
• Précision vs rappel : deux façons différentes de compter les réussites. Un modèle médical peut avoir intérêt à ne rater aucun malade (rappel élevé), quitte à déclencher des fausses alertes. Un filtre anti-fraude bancaire, à l'inverse, doit éviter de bloquer des clients innocents.

Si vous ne retenez qu'une chose de cette section : un score élevé veut dire « score élevé sur des cas qu'il n'a jamais vus ». Tout le reste est du vernis.

Quelle mesure choisir ? Le tableau qui tranche

Situation	Mesure à privilégier	Pourquoi
Filtrer des emails indésirables	Rappel	Mieux vaut laisser passer un spam que jeter un message important
Détecter une fraude bancaire	Précision	Bloquer un client honnête coûte plus cher qu'une fraude manquée
Prédire un départ de client	Score global + suivi du taux de contact réel	Ce qui compte, c'est le résultat commercial, pas la métrique technique
Trier des photos médicales	Rappel	Rater une anomalie est inacceptable

Ce qui fait échouer les projets (et ce qu'on ne dit jamais)

Sur dix projets de machine learning que j'ai vus passer, combien ont accouché de quelque chose d'utile au quotidien ? Trois, peut-être quatre. Le reste s'est enlisé. Et les raisons ne sont presque jamais techniques.

Le problème n°1 : la donnée

Un modèle entraîné sur des données bancales produira des résultats bancals, aussi sophistiqué soit-il. Vos données client sont éparpillées dans trois outils qui ne communiquent pas. Vos anciens dossiers contiennent des valeurs manquantes. Personne n'est d'accord sur ce que veut dire le champ « statut ». Vous pouvez avoir le meilleur algorithme du monde, il apprendra votre désordre.

J'ai vu une équipe passer six semaines sur le choix de l'algorithme, puis découvrir en production que le modèle avait appris un artefact du jeu de données — une variable qui n'avait aucun sens métier mais qui corrélait parfaitement dans l'historique. Résultat : silencieusement faux.

Le biais algorithmique, ce n'est pas de la science-fiction

Si vous entraînez un système de tri de candidatures sur dix ans d'embauches passées, il reproduira les habitudes d'embauche de ces dix ans. Y compris les mauvaises. Ce n'est pas le modèle qui est « sexiste » : c'est l'historique qu'on lui donne. La machine n'a aucun moyen de savoir que l'historique était problématique — elle a juste appris à le reproduire.

Le RGPD encadre tout ça depuis sa mise en application, avec un droit à l'explication : une décision automatisée qui vous concerne doit pouvoir être expliquée. C'est précisément pour ça que le secteur cherche des modèles « interprétables », même quand un modèle plus opaque serait plus performant.

Le coût réel, souvent sous-estimé

Entraîner un modèle coûte de l'énergie et du temps machine. Faire tourner un modèle en production coûte, lui, en continu. Une entreprise qui déploie une recommandation personnalisée pour un million d'utilisateurs paie des serveurs tous les mois. Ce poste n'apparaît jamais dans la démo, toujours dans la facture.

Par où commencer concrètement, sans être data scientist

La bonne nouvelle : depuis quelques années, les outils no-code ont rendu l'expérimentation accessible. Vous pouvez tester une intuition en une après-midi, sans écrire une ligne de code. La mauvaise : ces outils ne remplacent pas la question de fond, qui est toujours « quel problème est-ce que je cherche à résoudre ? ».

Un parcours réaliste en quatre étapes

1. Choisir un problème petit, mesurable, avec des données disponibles. Pas « améliorer le service client ». Plutôt « prédire quels tickets vont dépasser 48 h de traitement ».
2. Rassembler et nettoyer 500 à 2 000 exemples. C'est l'étape la plus ingrate et la plus déterminante.
3. Tester avec un outil no-code (classification d'images simple, prédiction tabulaire basique) pour voir si le signal existe. Si le modèle n'arrive à rien sur un petit échantillon, passer à l'échelle ne sauvera rien.
4. Si ça marche, mesurer en conditions réelles avant toute généralisation. Et se poser la question du biais, du coût et de la conformité.

Combien de temps ? Honnêtement, sur un cas simple et bien cadré, comptez quelques semaines pour un premier résultat utilisable. Sur un cas flou, des mois. La différence se joue rarement sur la technique.

Le vrai changement, c'est le dialogue. Vous n'avez pas besoin de savoir coder pour comprendre ce qu'on vous propose. Vous avez besoin de savoir poser les bonnes questions : quelles features, quel découpage, comment mesure-t-on, qu'est-ce qu'on fait quand le modèle se trompe ? Ce sont des questions de métier, pas de mathématiques.

La prochaine fois qu'un prestataire vous enverra un devis rempli de sigles, vous ne signerez pas les yeux fermés. Et peut-être que vous poserez la seule question qui compte vraiment : « Sur quels exemples le modèle s'est-il entraîné, et qui les a validés ? » La réponse vous en apprendra plus que n'importe quelle démonstration.