Leçon 5 — Pourquoi les modèles échouent

Une part importante des projets de machine learning n'atteint jamais la production, et parmi ceux qui y arrivent, beaucoup déçoivent. Les causes sont remarquablement peu nombreuses et se répètent d'un projet à l'autre. Les connaître, c'est pouvoir les diagnostiquer au lieu de les subir.

Cause 1 — La fuite de données

Le symptôme. Une performance anormalement élevée. 99 % sur un problème métier que les humains résolvent mal.

Le mécanisme. De l'information qui ne sera pas disponible au moment de la vraie prédiction s'est glissée dans l'entraînement. Trois formes principales :

• Une variable qui fuit : la colonne « date de résiliation » utilisée pour prédire la résiliation, ou « traitement prescrit » pour prédire un diagnostic. La leçon 3 en donne le catalogue.
• Une transformation calculée trop tôt : une moyenne de mise à l'échelle, une liste de catégories ou une sélection de variables calculée sur l'ensemble des données avant le découpage. C'est la forme la plus discrète, et c'est précisément ce que les pipelines empêchent.
• Une duplication entre entraînement et test : le même client présent dans les deux, ou deux photos quasi identiques du même objet séparées par le découpage aléatoire. Le modèle reconnaît, il ne généralise pas.

Le diagnostic. Listez les variables par importance. Si celle qui domine est une information postérieure à l'événement prédit, vous avez trouvé. Vérifiez aussi les identifiants : un modèle qui accorde de l'importance à un numéro de dossier exploite l'ordre d'insertion en base, ce qui n'a aucun sens causal.

Cause 2 — Le surapprentissage

Le symptôme. Excellent à l'entraînement, médiocre au test. 99 % contre 71 %.

Le mécanisme. Le modèle a mémorisé ses exemples au lieu d'apprendre le motif général — bruit et coïncidences compris. Le cas d'école reste le classifieur loup contre husky qui avait en réalité appris à détecter la neige à l'arrière-plan.

Les causes profondes. Trop peu d'exemples pour la complexité du modèle ; trop de variables par rapport au nombre de lignes ; un entraînement poursuivi trop longtemps ; des réglages qui laissent le modèle libre de mémoriser, comme un arbre sans limite de profondeur.

Les remèdes, par ordre d'efficacité réelle : plus de données, ce qui marche presque toujours ; simplifier le modèle ; régulariser, c'est-à-dire pénaliser la complexité pendant l'entraînement ; arrêter tôt, en surveillant la validation ; et augmenter les données en créant des variantes, ce qui est particulièrement efficace sur les images.

Le symptôme inverse existe aussi. Le sous-apprentissage — mauvais partout — signale un modèle trop simple ou des variables sans signal. Il est moins dangereux, parce qu'il est visible immédiatement.

Cause 3 — Le décalage de distribution

Le symptôme. Bon en test, mauvais dès le premier jour en production. Le modèle n'a pas eu le temps de dériver : il était déjà inadapté.

Le mécanisme. Les données d'entraînement ne ressemblent pas aux données réelles. Ce n'est pas un problème d'algorithme mais de représentativité de l'échantillon.

Des cas typiques, tous rencontrés dans la vraie vie :

• Un modèle de vision entraîné sur des photographies de studio, déployé sur des images prises au téléphone dans un entrepôt mal éclairé.
• Un modèle de scoring entraîné sur les clients d'une région, déployé nationalement.
• Un modèle entraîné sur des données historiques nettoyées à la main, alimenté en production par un flux brut contenant des doublons et des champs mal remplis.
• Un modèle entraîné sur les clients ayant répondu à un questionnaire, censé décrire tous les clients.

Le diagnostic. Comparez les distributions des variables entre entraînement et production. Si la moyenne, la dispersion ou la proportion de valeurs manquantes diffèrent nettement sur une variable importante, vous avez la cause.

Le remède. Il n'est pas algorithmique : il faut collecter des données qui ressemblent à la réalité de déploiement. C'est souvent la partie la plus coûteuse d'un projet, et l'escamoter garantit l'échec.

Cause 4 — La dérive

Le symptôme. Bon au lancement, dégradation progressive sur des semaines ou des mois, sans qu'aucun changement n'ait été apporté au système.

Le mécanisme. Le monde bouge, le modèle est figé. Ses paramètres ont été fixés à l'entraînement et il n'apprend rien de son usage.

Deux formes distinctes :

• La dérive des données : la population change. Nouveaux segments de clientèle, nouvelles gammes de produits, nouveau vocabulaire.
• La dérive du concept : la relation elle-même change. Les fraudeurs s'adaptent précisément aux détections mises en place ; ce qui prédisait la fraude l'an dernier ne la prédit plus.

Un cas devenu canonique : tout modèle de prévision entraîné avant 2020 s'est effondré en 2020, parce que rien dans son historique ne ressemblait à ce qui est arrivé. Aucun modèle n'extrapole hors de son expérience.

Le remède. Surveiller en continu, et réentraîner périodiquement. C'est exactement la raison d'être du MLOps : sans surveillance, la dégradation est invisible jusqu'à ce qu'un métier remonte le problème, souvent des mois trop tard.

Cause 5 — L'objectif mal posé

Le symptôme. Le modèle fait exactement ce qu'on lui a demandé, et personne n'en veut.

C'est la cause la plus fréquente d'échec de projet, par opposition aux échecs techniques, et la moins souvent nommée.

Des exemples parlants :

• On prédit quels clients vont partir, alors que la question utile était lesquels on peut retenir. Ce ne sont pas les mêmes : les plus susceptibles de partir sont parfois les plus impossibles à convaincre.
• On optimise le taux de clic, et on obtient des titres racoleurs qui dégradent la confiance dans la marque.
• On prédit la panne dans les 24 heures, alors que l'équipe de maintenance a besoin de sept jours pour planifier une intervention.
• On atteint une excellente précision globale, mais le modèle ne fournit aucune explication, alors que la réglementation en exige une.

Le remède est en amont, et il ne comporte pas une ligne de code : formuler la décision que le modèle doit aider à prendre, identifier qui l'utilisera et quand, et définir avant de commencer la mesure de succès en termes métier.

Le tableau de diagnostic

Symptôme observé	Cause probable	Où regarder
Score anormalement élevé	fuite de données	l'importance des variables, la chronologie
Excellent à l'entraînement, mauvais au test	surapprentissage	la taille des données, la complexité du modèle
Mauvais partout	sous-apprentissage	la richesse du modèle, le signal des variables
Bon en test, mauvais dès le jour 1	décalage de distribution	la comparaison des distributions
Bon au début, dégradation lente	dérive	la surveillance dans le temps
Techniquement bon, personne ne l'utilise	objectif mal posé	la conversation initiale avec le métier

La séquence de diagnostic

Dans cet ordre, parce qu'il va du moins coûteux au plus coûteux à vérifier : fuite, puis surapprentissage, puis décalage, puis dérive, puis objectif. Les deux premières se détectent en une heure sur un notebook. La dernière demande une réunion, et c'est pourtant celle qui aurait dû venir en premier, avant même le projet.

---

En trois phrases

Cinq causes expliquent la quasi-totalité des échecs : la fuite de données, reconnaissable à un score trop beau ; le surapprentissage, reconnaissable à l'écart entre entraînement et test ; le décalage de distribution, qui fait échouer dès le premier jour ; la dérive, qui dégrade lentement un modèle figé dans un monde qui bouge ; et l'objectif mal posé, où le modèle fonctionne mais ne répond pas à la question utile. Les quatre premières se diagnostiquent avec des vérifications précises et peu coûteuses. La cinquième est la plus fréquente et ne se corrige qu'en amont, dans la conversation avec le métier.

---

Suite — Leçon 6 : récapitulatif et FAQ →