Qu’est-ce que la dérive des données en production ?

Un modèle en production ne se dégrade pas parce qu’il vieillit : il se dégrade parce que le monde bouge et que lui ne bouge plus. Et le symptôme est qu’il n’y a pas de symptôme — pas d’exception, pas d’alerte, juste des prédictions qui deviennent progressivement fausses.

Les deux dérives, qu’il faut distinguer

La dérive des données (data drift) : la distribution des entrées change. Une nouvelle région, une application mobile qui remplace le site web, un capteur recalibré, une campagne marketing qui amène un autre public. Le modèle extrapole hors de son domaine d’apprentissage.

La dérive du concept (concept drift) : la relation entre les entrées et la cible change. Les mêmes entrées devraient maintenant produire une autre réponse. Un changement de comportement d’achat, une fraude qui s’adapte, une réglementation nouvelle. C’est la plus grave, parce qu’aucune vérification sur les entrées ne la détecte.

Le cas d’école à citer, parce qu’il montre que les deux se cumulent : les modèles de prévision de demande en mars 2020. Les entrées ont changé, et la relation entre elles et la demande a changé aussi.

Comment on la détecte

Sur les entrées, immédiatement. C’est ce qu’on peut surveiller sans attendre :

• comparer la distribution de chaque variable à celle de l’entraînement — test de Kolmogorov-Smirnov, indice de stabilité de population, divergence de Jensen-Shannon ;
• surveiller le taux de valeurs manquantes et l’apparition de modalités inconnues, qui signalent presque toujours un changement en amont plutôt qu’un changement du monde ;
• surveiller la distribution des prédictions elle-même. Elle ne demande aucune étiquette et bouge dès que les entrées bougent : c’est le signal le moins coûteux et le plus rentable.

Sur la performance, plus tard. C’est la seule mesure qui compte vraiment, et elle demande les étiquettes réelles — disponibles avec un délai de jours ou de mois. Sur un modèle de risque de crédit, la vérité arrive avec deux ans de retard, ce qui rend la surveillance des entrées indispensable en attendant.

Le point qui montre l’expérience : une alerte de dérive n’est pas une alerte de dégradation. Une variable peut se décaler franchement sans que la performance bouge, si le modèle ne s’appuie pas dessus. D’où le réflexe de pondérer la surveillance par l’importance des variables, et de ne déclencher une action que sur un faisceau de signaux.

Ce qu’on met en place

1. Consigner les entrées et les prédictions, avec la version du modèle. Sans cette trace, aucun diagnostic n’est possible plus tard.
2. Collecter les étiquettes réelles dès qu’elles arrivent, et les rattacher aux prédictions correspondantes.
3. Réentraîner périodiquement, sur un rythme calé sur la vitesse du phénomène, et non « quand quelqu’un s’en souviendra ».
4. Valider tout réentraînement avant bascule, sur une période postérieure, puis déployer progressivement — la dérive n’est pas une raison de déployer un modèle non vérifié.

Et la nuance qui vaut d’être posée en fin de réponse : la boucle de rétroaction est un cas particulier redoutable. Quand le modèle influence les données qui serviront à le réentraîner — un modèle antifraude qui bloque des transactions n’apprend plus jamais ce qui se serait passé, un moteur de recommandation ne voit que ce qu’il a lui-même proposé — la dérive vient du modèle lui-même. On y répond en réservant une petite part de trafic à une décision aléatoire ou neutre, pour continuer à observer le monde tel qu’il est.