Leçon 1 — Pourquoi la plupart des modèles n'atteignent jamais la production
Le constat
Selon les enquêtes du secteur, une majorité importante des modèles développés en entreprise n'arrive jamais en production, et parmi ceux qui y arrivent, beaucoup sont abandonnés dans l'année.
Le réflexe est de chercher une cause technique : le modèle n'était pas assez bon. C'est presque toujours faux. Les six causes réelles, dans l'ordre où on les rencontre, sont ailleurs.
Cause 1 — Le problème n'était pas défini
C'est la première cause, et la plus coûteuse.
« Nous voulons utiliser l'IA pour améliorer la satisfaction client » n'est pas un problème de machine learning. C'est une intention. Il manque tout : quelle décision sera prise à partir de la prédiction ? Par qui ? Quand ? Que se passe-t-il si la prédiction est fausse ? Comment saura-t-on que ça a marché ?
Un projet correctement défini répond à ces questions avant l'exploration des données. Une formulation utilisable ressemble à ceci :
Chaque lundi, prédire pour chacun des 12 000 clients actifs la probabilité de résiliation dans les 60 jours. Les 200 scores les plus élevés sont transmis à l'équipe de fidélisation, qui appelle. Aujourd'hui, la sélection est faite à la main par ancienneté du contrat et nous rappelons 200 clients par semaine. Le succès se mesure par le taux de résiliation évité sur les clients appelés, comparé à un groupe témoin non appelé.
Tout y est : la fréquence, le périmètre, la sortie attendue, qui agit, la référence actuelle, et une mesure de succès avec un groupe témoin.
Quelle décision change grâce à la prédiction ? Qui l'utilise, et est-il d'accord ? Que fait-on aujourd'hui sans modèle — c'est votre référence à battre ? Combien coûte une erreur, dans chaque sens ? Comment mesurera-t-on la valeur apportée ?
Un projet incapable de répondre aux cinq n'est pas prêt. Reporter ces questions à plus tard, c'est garantir qu'elles surgiront après six mois de travail.
Cause 2 — Les données de production ne sont pas celles de l'entraînement
Le modèle a été entraîné sur un extrait propre, préparé, complet. En production, il reçoit autre chose.
Des valeurs manquantes là où il n'y en avait pas. Des formats différents parce que la source n'est pas la même. Des retards : la variable la plus prédictive n'est disponible que trois jours après le moment où il faut prédire. Des échelles décalées parce que la normalisation appliquée à l'entraînement n'a pas été reproduite à l'identique.
Le cas le plus vicieux est la fuite de données, décrite dans le cours de machine learning : une variable de l'entraînement contenait une information qui n'existe pas encore au moment de la prédiction réelle. Le modèle affiche une performance excellente en test et s'effondre en production, et le diagnostic prend des semaines.
Ce qui prévient réellement : construire la chaîne de préparation une seule fois, sous forme de code partagé entre l'entraînement et la production. Toute transformation faite à la main dans un notebook et réécrite ensuite pour la production est une divergence en attente.
Cause 3 — Personne n'est propriétaire après la livraison
Le modèle est livré, l'équipe passe au projet suivant, et plus personne ne regarde.
Ce qui rend ce cas particulier, c'est que rien ne tombe en panne. Une application qui plante déclenche une alerte et quelqu'un intervient. Un modèle qui se dégrade continue de répondre, avec la même assurance, simplement moins bien. Une perte de dix points de performance peut passer inaperçue pendant six mois.
Ce qui fonctionne : un propriétaire nommé, avec un indicateur métier qu'il suit et une revue périodique inscrite dans son agenda. Sans nom sur la ligne, il n'y a pas de propriétaire.
Cause 4 — L'intégration est impossible
Le modèle fonctionne. Le mettre là où il servirait est une autre affaire.
Les obstacles concrets sont banals et bloquants : le système métier est un progiciel qui n'accepte pas d'appel externe ; les données nécessaires sont dans un entrepôt rafraîchi la nuit alors qu'il faut prédire en temps réel ; l'équipe qui exploite l'application n'a pas de créneau de livraison avant deux trimestres ; la politique de sécurité interdit l'appel sortant nécessaire.
Ce qui prévient : parler à l'équipe qui exploitera le système dès la première semaine, pas au moment de livrer. Et dessiner le chemin complet de la donnée — d'où elle vient, quand elle est disponible, où la prédiction arrive, qui la voit — avant d'entraîner quoi que ce soit.
Cause 5 — La valeur n'est pas mesurée
Sans mesure de valeur, le modèle devient une ligne de coût sans justification, et il disparaît au premier arbitrage budgétaire.
L'erreur est de confondre métrique de modèle et métrique métier. Le F1 n'intéresse pas la direction. Ce qui l'intéresse est le nombre de résiliations évitées, le temps de traitement économisé, le taux de défaut détecté avant expédition.
Ce qui fonctionne : définir la métrique métier avant de commencer, et garder un groupe témoin si c'est possible. Sans témoin, vous ne pourrez jamais distinguer l'effet du modèle de l'effet d'une saison, d'une campagne ou d'un changement de tarif. C'est le seul moyen de prouver la valeur, et cela se décide en amont, pas après.
Cause 6 — La dette technique s'accumule
Un article de référence de Google, Hidden Technical Debt in Machine Learning Systems, a décrit ce phénomène il y a une décennie, et il reste d'actualité.
Un système de machine learning accumule des formes de dette propres. Le code de préparation des données finit par représenter la majorité du système. Les dépendances de données sont invisibles : personne ne sait qu'une table alimente trois modèles, et quelqu'un la modifie. Les modèles en cascade, où la sortie de l'un alimente l'entrée de l'autre, propagent les erreurs. Et le code mort de configuration s'empile, parce qu'on n'ose plus retirer un paramètre dont on ignore l'effet.
Le tableau que retient l'article : le modèle représente une petite fraction du code d'un système de machine learning réel. Tout le reste — collecte, validation, transformation, service, surveillance, outillage — est du logiciel classique, et se dégrade comme du logiciel classique.
La liste de contrôle avant d'écrire du code
Si vous ne retenez qu'une chose de cette leçon, retenez cette liste. Chaque case non cochée est un risque identifié.
- La décision que la prédiction change est écrite noir sur blanc.
- La personne ou le système qui consomme la prédiction est identifié et d'accord.
- La référence actuelle — ce qu'on fait sans modèle — est mesurée.
- Le coût des deux types d'erreur est estimé, même grossièrement.
- La métrique métier et le dispositif de mesure, groupe témoin compris, sont définis.
- Les données nécessaires existent au moment de la prédiction, et pas seulement après coup.
- Le chemin d'intégration est validé avec l'équipe qui exploitera le système.
- Un propriétaire est nommé pour l'après-livraison.
Une demi-journée sur cette liste économise régulièrement plusieurs mois.
À retenir
- La majorité des modèles n'atteint jamais la production, et presque jamais pour des raisons de précision.
- La première cause est un problème mal défini : quelle décision, pour qui, comparée à quoi, mesurée comment.
- Les données de production diffèrent de celles de l'entraînement : partagez la chaîne de préparation sous forme de code.
- Un modèle sans propriétaire se dégrade sans alerte, parce que rien ne tombe en panne.
- L'intégration se valide dès la première semaine, pas au moment de livrer.
- Sans métrique métier et groupe témoin, la valeur ne pourra pas être prouvée.
- Le modèle est une petite fraction du système ; tout le reste est du logiciel qui se dégrade.
Leçon suivante — La reproductibilité : données, code, environnement →