Dérive des modèles : pourquoi une IA se dégrade et comment la surveiller

En novembre 2021, Zillow annonce l'arrêt de son programme d'achat immobilier automatisé, Zillow Offers. Le chiffre le plus parlant tient en une ligne : au seul troisième trimestre, l'entreprise a acheté 9 680 maisons et n'en a revendu que 3 032. Elle provisionne plus de 300 millions de dollars de dépréciation sur ce trimestre, licencie environ un quart de ses effectifs — près de 2 000 personnes sur un peu plus de 6 400 — et referme une aventure dont les pertes se chiffreront en centaines de millions de dollars. En cause : un algorithme de valorisation immobilière, le Zestimate, qui avait cessé de coller à la réalité d'un marché bouleversé par la pandémie. Ce n'est pas un bug au sens classique du terme — le code fonctionnait exactement comme il avait été conçu pour fonctionner. C'est un modèle qui a continué à produire ses estimations avec la même assurance, alors que le monde qu'il décrivait avait changé sous ses pieds plus vite qu'il ne pouvait l'apprendre. Ce phénomène porte un nom : la dérive des modèles, ou model drift.

La dérive des modèles n'est pas une anomalie rare réservée aux cas d'école. C'est une propriété structurelle de tout système d'apprentissage automatique déployé dans un environnement qui évolue — c'est-à-dire, en pratique, tous les environnements. Un modèle de scoring de crédit entraîné avant une récession, un filtre anti-spam confronté à de nouvelles tactiques, un système de recommandation qui n'a pas vu passer un changement de mode : dans chaque cas, le modèle continue de calculer, mais ses calculs s'appuient sur une photographie du monde qui devient obsolète. La question n'est donc pas de savoir si un modèle va dériver, mais quand, à quelle vitesse, et comment s'en apercevoir avant que les conséquences ne deviennent coûteuses.

Cet article propose un tour d'horizon complet du sujet : ce qu'est la dérive, ses différentes formes, pourquoi elle survient, comment la détecter avec des outils statistiques éprouvés, et quelles stratégies permettent de la maîtriser en production. Trois études de cas réelles — Zillow, la pandémie de COVID-19 et Google Flu Trends — illustrent concrètement ce qui se joue quand la surveillance fait défaut.

Qu'est-ce que la dérive des modèles, exactement ?

La dérive des modèles désigne la dégradation progressive de la précision ou de la pertinence des prédictions d'un modèle au fil du temps, à mesure que l'écart se creuse entre les données sur lesquelles il a été entraîné et les données qu'il rencontre en production. Un modèle ne « désapprend » pas au sens propre : ses paramètres restent figés une fois l'entraînement terminé. C'est le monde autour de lui qui bouge, pendant que ses paramètres, eux, ne bougent pas — sauf réentraînement.

Il est utile de distinguer deux notions souvent confondues, mais conceptuellement différentes :

• La dérive des données (data drift, aussi appelée covariate shift) : les propriétés statistiques des données d'entrée changent, alors que la relation entre ces entrées et la sortie attendue reste, elle, stable. Exemple : un modèle de reconnaissance faciale confronté à une population d'utilisateurs dont la composition démographique a évolué depuis l'entraînement.
• La dérive de concept (concept drift) : c'est la relation elle-même entre les variables d'entrée et la variable cible qui change. Formellement, il s'agit d'un changement, dans le temps et de façon imprévue, des propriétés statistiques de la variable que le modèle cherche à prédire. Exemple classique : un modèle de scoring de crédit entraîné sur des données d'avant une récession économique peut mal classer le risque une fois la récession installée, parce que la définition même d'un « bon » ou d'un « mauvais » profil a changé avec le contexte macroéconomique.

Le vocabulaire n'est pas nouveau. Le terme de concept drift a été introduit dès 1986 par Jeffrey Schlimmer et Richard Granger, dans des travaux sur l'apprentissage incrémental à partir de données bruitées ; ils y décrivaient déjà un algorithme, baptisé STAGGER, conçu pour suivre une cible mouvante. Près de quatre décennies plus tard, la formulation de référence reste la même : il y a dérive de concept lorsque la probabilité conditionnelle P(y | x) — la relation entre les entrées x et la cible y — change dans le temps. Cette définition, en apparence abstraite, a une conséquence très concrète : un modèle peut recevoir des entrées parfaitement normales, sans le moindre signe de dérive des données, et se tromper malgré tout, simplement parce que la règle qui lie ces entrées au résultat n'est plus celle qu'il a apprise.

La distinction n'est pas qu'académique : elle oriente le diagnostic et la réponse. Une dérive des données trouve souvent son origine dans des facteurs internes — un changement dans le pipeline de collecte, un capteur mal recalibré, une nouvelle source de données mêlée à l'ancienne. Une dérive de concept, elle, provient le plus souvent de facteurs externes : l'évolution du comportement des utilisateurs, un contexte économique différent, ou l'adaptation délibérée d'acteurs malveillants — un spammeur qui change de tactique en est l'exemple le plus intuitif. Un bon diagnostic commence toujours par se demander : est-ce mes données qui ont changé de forme, ou est-ce le lien entre ces données et la réalité qu'elles décrivent ?

Les différentes formes de dérive, en détail

Au-delà du duo data drift / concept drift, plusieurs variantes méritent d'être connues, car elles appellent des réponses différentes.

Dérive graduelle, soudaine, récurrente et incrémentale

La dérive graduelle s'installe lentement, sur des mois — l'évolution progressive des habitudes de consommation en est un exemple typique. La dérive soudaine survient en quelques jours, voire en quelques heures : un choc économique, un changement réglementaire brutal, ou l'irruption d'un événement inédit. La dérive récurrente, elle, suit un motif cyclique et prévisible — la saisonnalité des ventes de vêtements ou la variabilité annuelle de la qualité de l'air en sont des illustrations documentées, avec des frontières de décision qui diffèrent d'une saison à l'autre selon les conditions météorologiques. Enfin, la dérive incrémentale procède par petits paliers successifs, chacun trop faible pour déclencher une alerte isolément, mais dont l'accumulation finit par peser lourd.

Cette typologie n'est pas une invention de circonstance : elle structure la synthèse de référence publiée en 2014 par João Gama et ses coauteurs, l'une des plus citées du domaine. On peut la résumer d'un coup d'œil, en précisant pour chaque régime le type de réponse qu'il appelle :

Régime de dérive	Vitesse d'installation	Exemple concret	Réponse adaptée
Soudaine	Heures à jours	Confinement de mars 2020, choc réglementaire	Réentraînement d'urgence, bascule vers un modèle de repli
Graduelle	Semaines à mois	Glissement des goûts, inflation lente	Réentraînement périodique, surveillance des tendances
Incrémentale	Par petits paliers	Vieillissement progressif d'un capteur	Suivi cumulé, seuils sur la dérive accumulée
Récurrente	Cyclique, prévisible	Saisonnalité des ventes, qualité de l'air	Modèles saisonniers dédiés, mémoire des concepts passés

Dérive des données amont (upstream data changes)

Une catégorie souvent négligée mérite une attention particulière : les changements de données en amont du modèle, indépendants de toute évolution du monde réel. Une mise à jour de schéma dans une base de données, un renommage de colonne resté sans documentation, un bug dans un pipeline ETL qui commence à injecter des valeurs nulles, ou encore le remplacement silencieux d'un capteur par un modèle légèrement différent : autant de causes purement techniques qui produisent des symptômes identiques à ceux d'une vraie dérive de concept, sans qu'aucune réalité externe n'ait réellement changé. C'est souvent la cause la plus facile à corriger — à condition de savoir qu'elle existe et de la chercher en priorité avant d'incriminer le modèle lui-même.

Dérive des labels et boucles de rétroaction

Un dernier cas mérite d'être signalé : la dérive alimentée par le modèle lui-même. Un système de recommandation qui influence ce que les utilisateurs regardent, cliquent ou achètent modifie, de fait, les données qui serviront à son propre réentraînement futur. Cette boucle de rétroaction n'est pas une hypothèse théorique : la littérature sur les systèmes de recommandation a montré qu'un réentraînement répété sur les réactions des utilisateurs amplifie le biais de popularité — les articles déjà populaires le deviennent encore davantage, les autres s'effacent — jusqu'à provoquer un effondrement de la diversité du catalogue et un glissement mesurable des préférences observées, plus marqué encore pour les groupes minoritaires d'utilisateurs. Le modèle finit par mesurer moins les goûts réels de son public que l'écho de ses propres recommandations passées. Surveiller la dérive suppose alors de se demander non seulement « le monde a-t-il changé ? » mais aussi « mon propre système a-t-il changé le monde qu'il observe ? ».

Pourquoi les modèles se dégradent-ils ?

Les causes de dérive sont multiples, et il est utile de les classer selon leur origine pour savoir où porter son attention en priorité.

Les changements de comportement des utilisateurs figurent parmi les causes les plus fréquentes. Les habitudes de consommation, les requêtes de recherche, les préférences esthétiques évoluent en continu, parfois insensiblement, parfois brutalement à la faveur d'une tendance ou d'un événement médiatique. Un modèle de recommandation entraîné sur les goûts d'il y a dix-huit mois porte, par construction, une vision datée du présent.

Les évolutions macro-économiques et réglementaires touchent particulièrement les modèles financiers et assurantiels. Un modèle de scoring de crédit calibré en période de croissance peut sous-estimer le risque en période de ralentissement, précisément au moment où une évaluation fiable compte le plus.

L'adaptation adverse concerne les domaines où un acteur a intérêt à contourner le modèle. La détection de spam en est l'exemple le plus cité : dès qu'un filtre devient efficace contre une tactique donnée, les émetteurs de spam ajustent leur approche, ce qui rend obsolète la frontière de décision apprise par le modèle. La détection de fraude obéit à la même logique de course-poursuite permanente, où l'adversaire réentraîne, lui aussi, sa propre stratégie à chaque itération.

Les ruptures exogènes, enfin, regroupent les événements soudains et largement imprévisibles à l'échelle d'un modèle individuel : une crise sanitaire, un choc géopolitique, un événement climatique majeur. Ces ruptures ont ceci de particulier qu'elles affectent souvent simultanément un grand nombre de modèles dans des secteurs très différents, ce qui en fait les cas les plus spectaculaires — et les plus instructifs — pour comprendre la dérive en pratique.

La dérive n'est pas le signe d'un modèle mal conçu. C'est la conséquence logique d'un modèle statique confronté à un monde qui, lui, ne l'est pas.

Étude de cas : Zillow Offers, l'algorithme qui n'a pas vu venir la volatilité

Le cas Zillow mérite d'être détaillé, car il illustre presque tous les mécanismes de dérive à la fois. Zillow Offers était un programme d'« iBuying » : l'entreprise achetait directement des maisons auprès de particuliers, sur la base d'une estimation algorithmique de leur valeur — le fameux Zestimate — puis les revendait après de légères rénovations, en tablant sur une marge calculée à l'avance par le modèle.

Un détail technique éclaire toute l'affaire. Zillow publie deux mesures de précision très différentes pour son Zestimate : sur les biens déjà mis en vente, l'erreur médiane nationale est d'environ 1,9 %, mais sur les biens hors marché — ceux qui ne sont pas listés — elle grimpe autour de 6,9 %. La raison est simple : une fois un bien mis en vente, l'algorithme dispose du prix affiché par l'agent pour s'y « ancrer ». Or Zillow Offers achetait précisément des maisons hors marché, dans la configuration où le modèle est le moins fiable. Une marge de manœuvre de quelques points, tolérable sur un marché calme, devient un piège dès que les prix s'emballent.

Le système fonctionnait raisonnablement bien tant que le marché immobilier évoluait de façon relativement stable et prévisible. La pandémie a bouleversé cet équilibre. Les prix de l'immobilier américain ont grimpé à un rythme historique en 2020 et 2021, portés par des taux d'intérêt bas et une demande de logements plus grands liée au télétravail. Le modèle de Zillow, construit pour anticiper des variations progressives, s'est retrouvé confronté à une volatilité que ses données d'entraînement n'avaient jamais connue à cette échelle.

Deux facteurs aggravants ont transformé une dérive de modèle en désastre opérationnel. D'abord, le Zestimate reposait en partie sur des ventes déjà conclues, avec un décalage estimé à plusieurs semaines (de l'ordre de 30 à 60 jours selon les analyses du secteur) pour prendre des décisions d'achat immédiates — un décalage temporel qui, en période de marché stable, importe peu, mais qui devient critique quand les prix bougent vite. Ensuite, la pénurie de main-d'œuvre du secteur du bâtiment pendant la pandémie a ralenti la rénovation et la revente des biens achetés, allongeant la durée pendant laquelle Zillow restait exposé à des maisons dont la valeur de marché continuait d'évoluer sous ses pieds. Un analyste cité dans la presse spécialisée a estimé qu'environ deux tiers des maisons achetées par Zillow valaient, au moment de la clôture du programme, moins que ce que l'entreprise avait payé pour les acquérir.

Le résultat : un algorithme qui surévaluait systématiquement les biens dans un marché en accélération, sans mécanisme de correction suffisamment réactif pour suivre le rythme. Zillow n'a pas été victime d'un bug logiciel, mais d'une dérive de concept non détectée à temps — ou détectée trop tard pour ajuster la stratégie d'achat avant que les pertes ne s'accumulent à grande échelle. Le PDG de l'entreprise a lui-même résumé l'échec en des termes qui pourraient servir de définition à la dérive de concept :

« Nous avons constaté que l'imprévisibilité de la prévision des prix de l'immobilier dépasse de loin ce que nous avions anticipé. » — Rich Barton, PDG de Zillow, novembre 2021

Étude de cas : la pandémie, un choc de dérive à l'échelle d'un secteur entier

Le cas Zillow n'est pas isolé. La pandémie de COVID-19 a provoqué l'un des épisodes de dérive de concept les plus étudiés et les plus documentés de l'histoire récente du machine learning, précisément parce qu'elle a touché simultanément des milliers de modèles à travers des secteurs très différents — retail, santé, transport, finance.

Dans le commerce de détail, les confinements ont bouleversé en quelques semaines des habitudes de consommation qui s'étaient construites sur des années. Les chiffres du Bureau du recensement américain donnent la mesure du basculement : la part du commerce en ligne dans les ventes de détail est passée d'environ 11 % en 2019 à près de 14 % en 2020, un bond de trois points en une seule année là où il en fallait habituellement plusieurs. En valeur, les ventes en ligne ont bondi de 43 %, passant de 571 à 815 milliards de dollars — soit près de 244 milliards de dollars de demande supplémentaire redirigés vers un canal que les modèles de prévision pré-pandémiques n'avaient pas appris à anticiper. Les prévisions se sont écartées fortement de la réalité : effondrement de certaines catégories comme l'habillement, pics de demande soudains sur d'autres comme les produits d'entretien, et comportements d'achat marqués par des visites moins fréquentes mais des paniers plus volumineux.

Une dérive brutale, pas progressive

Ce qui distingue le choc pandémique d'une dérive ordinaire, c'est sa vitesse. La plupart des modèles de prévision sont conçus pour absorber des évolutions progressives — une tendance qui s'installe sur des mois, une saisonnalité qui se répète chaque année. Le confinement de mars 2020 a produit, en l'espace de quelques semaines, une rupture qu'aucune fenêtre d'entraînement historique ne pouvait anticiper. Les secteurs qui s'en sont le mieux sortis sont ceux qui disposaient déjà d'une surveillance continue de la performance de leurs modèles, capable de déclencher un réentraînement d'urgence plutôt que d'attendre le cycle habituel.

Une étude portant sur la prévision des ventes d'un détaillant de vêtements pendant la crise sanitaire a par exemple mis en évidence que les approches combinant plusieurs algorithmes de machine learning, réajustés fréquemment sur des données récentes, résistaient nettement mieux aux ruptures brutales que les modèles statiques réentraînés selon un calendrier fixe et espacé. La leçon rejoint celle de Zillow : ce n'est pas la sophistication du modèle qui a fait la différence, mais la capacité à détecter le changement et à réagir vite.

Étude de cas : Google Flu Trends, la dérive qui passe inaperçue

La troisième affaire complète le tableau, car elle illustre le pire scénario : une dérive lente qui s'installe sans que personne ne la voie. Lancé en 2008, Google Flu Trends (GFT) promettait d'estimer l'activité grippale aux États-Unis à partir du volume de certaines requêtes de recherche, avec une ou deux semaines d'avance sur les statistiques officielles des Centers for Disease Control (CDC). Le modèle, entraîné sur les données de 2003 à 2008, était devenu un cas d'école du big data — jusqu'à ce qu'il se mette à se tromper spectaculairement.

Lors de la saison grippale 2012-2013, GFT a surestimé le pic de grippe d'environ 140 %, et sur les saisons 2011 à 2013 il a plus que doublé les niveaux réellement mesurés par les CDC. Deux mécanismes de dérive se sont conjugués. D'une part, l'algorithme de recherche de Google évoluait en permanence — suggestions automatiques, requêtes recommandées — ce qui modifiait le signal même sur lequel le modèle s'appuyait : une dérive amont, provoquée par le producteur des données lui-même. D'autre part, la relation entre les recherches et la maladie réelle a glissé : la couverture médiatique anxiogène gonflait le volume de requêtes liées à la grippe sans qu'il y ait davantage de malades. Fitté une seule fois et pratiquement jamais réentraîné, le modèle a surestimé l'activité grippale durant 100 des 108 semaines qui ont suivi, entre août 2011 et septembre 2013, selon l'étude de référence de Lazer et ses coauteurs (2014) — un dérèglement resté invisible faute d'une confrontation régulière et rigoureuse aux chiffres de terrain des CDC.

Le problème de Google Flu Trends ne tenait pas à la taille de ses données, mais à l'illusion que le volume pouvait dispenser de vérifier, dans la durée, que le modèle collait encore à la réalité.

La leçon fait la transition parfaite vers la surveillance : GFT ne s'est pas effondré parce qu'il était mal conçu, mais parce que personne ne comparait, en continu, ses prédictions à une vérité terrain indépendante. Une dérive détectée à temps se corrige ; une dérive qu'on ne mesure pas se paie au prix fort.

Comment détecter la dérive : les méthodes qui marchent

Détecter la dérive avant qu'elle ne cause des dégâts suppose une surveillance systématique, organisée autour de deux familles complémentaires de méthodes : celles qui comparent des distributions statistiques, et celles qui surveillent directement la performance du modèle.

L'indice de stabilité de population (PSI)

Le Population Stability Index (PSI), développé à l'origine pour le scoring de crédit dans des institutions financières, compare la distribution d'une variable entre deux périodes — typiquement les données d'entraînement et les données de production récentes. La méthode consiste à découper les valeurs observées en tranches (« buckets »), puis à comparer la proportion d'observations tombant dans chaque tranche entre les deux périodes. Le résultat est un score unique, facile à interpréter et à automatiser dans un tableau de bord de surveillance. Les seuils communément admis sont les suivants :

• PSI ≤ 0,1 : pas de dérive significative, la distribution est restée stable ;
• 0,1 < PSI ≤ 0,2 : dérive modérée, à surveiller de près ;
• PSI > 0,2 : dérive significative, une investigation — voire un réentraînement — est généralement justifiée.

L'intérêt du PSI tient à sa simplicité opérationnelle : un seul nombre par variable, calculable à intervalles réguliers, qui permet de prioriser l'attention sur les variables qui bougent le plus sans avoir à examiner manuellement chaque distribution.

Le test de Kolmogorov-Smirnov et les mesures de divergence

Le test de Kolmogorov-Smirnov (test K-S) est un test statistique non paramétrique qui évalue si deux échantillons proviennent de la même distribution sous-jacente, sans présupposer de forme particulière pour cette distribution. Si le test conclut que les données de production et les données d'entraînement proviennent probablement de distributions différentes, c'est un signal fiable de dérive des données. D'autres mesures complètent cette boîte à outils selon la nature des variables surveillées. La divergence de Jensen-Shannon et le test du chi carré conviennent respectivement aux distributions de probabilité et aux variables catégorielles. La distance de Wasserstein (ou earth mover's distance), qui mesure le « travail » minimal nécessaire pour transformer une distribution en une autre, s'avère précieuse pour les variables numériques dont les distributions ne se recouvrent que partiellement — là où le test K-S perd en finesse — au prix, toutefois, d'un défaut pratique : contrairement aux tests statistiques, elle ne fournit pas de seuil de décision naturel, et il faut donc en calibrer un à la main à partir de l'historique.

Les détecteurs séquentiels pour flux de données

Les méthodes précédentes comparent deux lots figés — un jeu de référence et un lot récent. Une autre famille, née de la recherche sur l'apprentissage en flux (stream learning), surveille au contraire un flux continu, observation après observation, et signale le point de rupture en temps réel. La méthode DDM (Drift Detection Method) part d'un principe simple : tant que la distribution est stable, le taux d'erreur d'un modèle doit décroître ou rester constant à mesure qu'il voit davantage d'exemples ; une remontée statistiquement significative de ce taux trahit une dérive. ADWIN (Adaptive Windowing) maintient une fenêtre de taille variable qu'il coupe automatiquement dès que deux sous-fenêtres présentent des moyennes trop divergentes, ce qui lui permet de repérer aussi bien les ruptures brutales que les glissements progressifs. Le test de Page-Hinkley, hérité du contrôle qualité industriel, accumule les écarts à la moyenne attendue (somme cumulée, ou CUSUM) et déclenche l'alerte quand cette somme franchit un seuil. Ces détecteurs, souvent réservés aux cas où la vérité terrain arrive rapidement, sont particulièrement adaptés aux systèmes qui décident et vérifient en continu — détection de fraude, maintenance prédictive, publicité en ligne.

Méthode	Ce qu'elle compare	Type de donnée	Force / limite
PSI	Proportions par tranche entre deux périodes	Numérique et catégorielle (binnée)	Un score unique interprétable ; seuils empiriques 0,1 / 0,2
Kolmogorov-Smirnov	Fonctions de répartition de deux échantillons	Numérique continue	Sensible ; fournit un seuil, mais très réactif sur gros volumes
Jensen-Shannon	Deux distributions de probabilité	Numérique et catégorielle	Bornée et symétrique ; pas de test d'hypothèse intégré
Wasserstein	« Coût » de transport entre deux distributions	Numérique, y compris peu chevauchantes	Robuste en haute dimension ; seuil à calibrer soi-même
DDM / ADWIN / Page-Hinkley	Taux d'erreur ou moyenne d'un flux dans le temps	Flux continu avec vérité terrain	Détection en temps réel ; exige un retour rapide sur la performance

La surveillance directe de la performance

Les méthodes statistiques présentent une limite : elles détectent un changement dans les données, mais pas nécessairement un changement qui affecte réellement la qualité des prédictions. La deuxième famille d'approches consiste donc à surveiller directement des métriques de performance — précision, erreur moyenne, taux de faux positifs — dès que la vérité terrain (le résultat réel observé après coup) devient disponible. C'est la méthode la plus directe, mais elle suppose un délai : dans le scoring de crédit, par exemple, il faut parfois attendre plusieurs mois avant de savoir si un emprunteur a effectivement fait défaut. Dans l'intervalle, seule la surveillance des distributions d'entrée permet une alerte précoce.

En pratique, une stratégie de surveillance robuste combine les deux approches : les tests statistiques sur les distributions d'entrée pour une détection rapide, et le suivi de la performance réelle dès que la vérité terrain est disponible, pour confirmer — ou infirmer — l'urgence d'agir.

Bien régler les seuils d'alerte

Un piège fréquent, une fois les outils statistiques en place, consiste à multiplier les alertes sans discernement. Des seuils trop sensibles noient les équipes sous des notifications qui ne correspondent pas à une dérive réellement problématique, et finissent par produire l'effet inverse de celui recherché : les alertes sont ignorées par lassitude, y compris le jour où l'une d'elles signale un vrai problème. Des seuils trop larges, à l'inverse, laissent passer des dérives qui auraient mérité une intervention précoce. La bonne pratique consiste à calibrer les seuils progressivement, à partir de l'historique réel de variabilité de chaque variable en conditions normales, plutôt que d'appliquer d'emblée une valeur générique identique à tous les indicateurs. Certaines équipes distinguent également un seuil d'observation, qui déclenche une simple mise sous surveillance renforcée, d'un seuil d'action, qui déclenche une investigation ou un réentraînement — une granularité à deux niveaux qui limite la fatigue liée aux fausses alertes tout en gardant une réactivité suffisante sur les signaux qui comptent vraiment.

Les outils de surveillance en production

La détection de la dérive ne se fait plus, dans la grande majorité des équipes, avec des scripts ad hoc exécutés manuellement. Un écosystème d'outils dédiés au monitoring de modèles s'est structuré ces dernières années, avec des approches complémentaires selon la taille de l'organisation et le degré de contrôle recherché sur l'infrastructure.

Evidently AI s'est imposé comme une référence côté outils ouverts, avec une bibliothèque permettant de calculer automatiquement les indicateurs de dérive présentés plus haut (PSI, test K-S, divergences) et de générer des rapports de surveillance intégrables dans un pipeline MLOps existant, avec la possibilité d'un déploiement entièrement sur l'infrastructure de l'équipe. D'autres plateformes comme Arize et Fiddler ciblent plutôt les équipes qui préfèrent une solution gérée, avec des tableaux de bord orientés production à grande échelle et des workflows d'alerte en temps réel. WhyLabs, de son côté, met l'accent sur une architecture qui privilégie la confidentialité des données, un point sensible pour les organisations soumises à des contraintes réglementaires strictes.

Une catégorie plus récente d'outils s'attaque directement au problème du délai de la vérité terrain. NannyML, par exemple, propose d'estimer la performance d'un modèle sans attendre les labels réels : sa méthode CBPE (Confidence-Based Performance Estimation) reconstruit les cases d'une matrice de confusion à partir des probabilités de sortie du modèle, à condition que celles-ci soient bien calibrées. L'approche a une limite qu'il faut connaître : elle absorbe bien la dérive des données, mais reste par construction aveugle à la dérive de concept pure — car sans aucune vérité terrain, il n'existe tout simplement aucun moyen de savoir que la relation entre entrées et sortie a changé. Du côté des grands fournisseurs cloud, la surveillance s'est également banalisée : un service comme Amazon SageMaker Model Monitor établit une « ligne de base » à partir des données d'entraînement, compare en continu les données de production à cette référence, et peut déclencher automatiquement une alerte — voire un réentraînement — dès qu'une contrainte est violée.

Databricks, dans un billet consacré à la mise en production des modèles, résume bien l'esprit qui doit guider le choix d'un outil : la surveillance continue consiste à ingérer en flux les données de production et à comparer leurs propriétés statistiques à un jeu de référence, de façon systématique et automatisée, plutôt qu'au gré de vérifications ponctuelles. Le choix de l'outil compte moins que la discipline qu'il permet d'installer : sans processus régulier de comparaison entre les données actuelles et les données de référence, même le meilleur outil ne sert à rien.

Le choix entre une solution ouverte à héberger soi-même et une plateforme gérée dépend surtout de la maturité de l'équipe et de la sensibilité des données traitées. Une petite équipe qui démarre a souvent intérêt à commencer par une bibliothèque ouverte, intégrée directement dans son pipeline existant, quitte à migrer plus tard vers une solution gérée à mesure que le nombre de modèles à surveiller augmente et que le besoin de tableaux de bord centralisés, partagés entre plusieurs équipes, se fait sentir. Une organisation soumise à des contraintes réglementaires fortes — santé, finance — privilégiera en général une architecture qui garde les données de production à l'intérieur de son propre périmètre, quitte à consacrer davantage d'efforts d'intégration en amont. Dans tous les cas, le critère décisif reste le même : la capacité de l'outil à s'intégrer sans friction dans le cycle de déploiement existant, car un outil de surveillance que personne ne consulte régulièrement n'apporte, en pratique, pas plus de garantie qu'une absence totale de surveillance.

Que faire une fois la dérive détectée ?

Détecter la dérive n'est que la moitié du travail. La question suivante — que faire une fois l'alerte déclenchée — appelle des réponses graduées, du simple ajustement au réentraînement complet.

Le réentraînement, à quelle fréquence ?

Il n'existe pas de fréquence universelle de réentraînement : elle dépend de la vitesse à laquelle le domaine évolue, de la criticité des décisions prises par le modèle et du coût du réentraînement lui-même. Certaines équipes adoptent un calendrier fixe — quotidien, hebdomadaire, mensuel ou trimestriel — qui offre un bon compromis entre simplicité opérationnelle et fraîcheur du modèle. D'autres préfèrent un réentraînement déclenché par la performance : on ne retouche le modèle que lorsque les indicateurs de surveillance franchissent un seuil d'alerte prédéfini, ce qui évite de consommer des ressources de calcul pour des ajustements qui ne seraient pas justifiés par un changement réel. Le choc pandémique a d'ailleurs montré la limite du calendrier fixe : un modèle réentraîné une fois par trimestre pouvait rester, pendant des semaines, calé sur un monde qui n'existait plus — d'où l'intérêt d'un déclenchement piloté par la surveillance plutôt que par l'horloge.

Le déploiement en champion / challenger

Une pratique répandue consiste à déployer un nouveau modèle réentraîné en parallèle de l'ancien, sans remplacer immédiatement ce dernier. Le modèle « challenger » reçoit une partie du trafic, ou fonctionne en mode silencieux (« shadow deployment »), le temps de comparer ses performances à celles du modèle « champion » en place. Cette approche limite le risque d'un remplacement précipité qui introduirait de nouveaux problèmes, tout en offrant des données de comparaison directes et fiables avant toute bascule définitive.

L'humain dans la boucle

Pour les décisions à fort enjeu — crédit, santé, sécurité — la meilleure réponse à une dérive détectée n'est pas toujours un réentraînement automatique. Il peut être préférable d'abaisser temporairement le seuil de confiance à partir duquel le modèle décide seul, et de renvoyer davantage de cas ambigus vers une revue humaine, le temps de comprendre la nature exacte du changement observé. Cette prudence a un coût opérationnel, mais elle évite d'automatiser une correction sur la base d'un diagnostic encore incertain.

Bonnes pratiques pour une surveillance durable

Au-delà des outils et des méthodes ponctuelles, quelques principes structurent une démarche de surveillance efficace sur la durée.

• Définir une référence claire dès le départ : conserver précisément le jeu de données et les métriques de performance au moment du déploiement initial, pour disposer d'un point de comparaison stable dans le temps.
• Valider en continu, pas seulement au lancement : l'échec de Google Flu Trends tient largement à l'absence de confrontation régulière à une vérité terrain indépendante ; une bonne performance au lancement ne garantit rien sur la durée si personne ne la revérifie hors échantillon.
• Surveiller les entrées autant que les sorties : un changement dans les distributions d'entrée précède souvent, de plusieurs jours ou semaines, une dégradation mesurable de la performance. C'est le principal intérêt d'une détection basée sur les distributions plutôt que sur la seule performance finale.
• Prioriser les variables selon leur importance : toutes les variables d'entrée ne pèsent pas de la même façon dans les prédictions du modèle. Concentrer la surveillance sur celles qui comptent le plus évite de noyer les équipes sous des alertes peu pertinentes.
• Documenter chaque épisode de dérive : consigner la cause identifiée, la méthode de détection qui a fonctionné et la réponse apportée constitue une mémoire précieuse pour affiner les seuils d'alerte au fil du temps.
• Anticiper les ruptures amont : avant de conclure à une dérive de concept, vérifier systématiquement qu'aucun changement technique — schéma de données, pipeline, source — n'explique le signal observé.

Cette discipline rejoint une intuition simple, déjà présente dans la pratique du génie logiciel classique : un système qui n'est jamais surveillé ne donne pas l'impression de bien fonctionner, il donne simplement l'impression de ne pas avoir de problème. La différence entre les deux se révèle rarement au moment où elle serait la moins coûteuse à corriger.

Le meilleur moment pour détecter une dérive n'est pas quand les résultats deviennent visiblement mauvais, mais quand les données commencent, discrètement, à ne plus ressembler à ce que le modèle a appris.

Ce qu'il faut retenir

La dérive des modèles n'est ni un accident rare, ni une fatalité insurmontable : c'est une conséquence prévisible du déploiement d'un système statique dans un monde qui continue, lui, d'évoluer. Le cas Zillow montre ce qui se produit quand la vitesse du changement dépasse la capacité de correction du système ; le choc de la pandémie sur les modèles de prévision retail montre que même une rupture largement partagée à l'échelle d'un secteur entier peut être mieux absorbée par les organisations qui avaient déjà mis en place une surveillance continue ; Google Flu Trends rappelle, lui, que la dérive la plus dangereuse est celle que personne ne mesure.

Les outils pour anticiper ce phénomène existent, sont éprouvés et relativement accessibles : des méthodes statistiques comme le PSI, le test de Kolmogorov-Smirnov ou la distance de Wasserstein pour détecter tôt les changements dans les données, des détecteurs séquentiels comme DDM ou ADWIN pour les flux en temps réel, des plateformes de monitoring — ouvertes ou gérées — pour automatiser cette surveillance, et des stratégies de réponse graduées, du réentraînement programmé au déploiement prudent en champion/challenger, en passant par le renforcement temporaire de la supervision humaine sur les cas ambigus.

La leçon la plus utile pour une équipe qui met un modèle en production n'est donc pas « mon modèle va-t-il dériver ? » — la réponse est presque toujours oui, tôt ou tard — mais « ai-je mis en place les moyens de le savoir avant que cela ne coûte cher ? ». C'est cette bascule, d'une confiance statique envers un modèle figé vers une vigilance continue sur ses conditions d'usage, qui distingue les déploiements qui vieillissent bien de ceux qui, comme le Zestimate en 2021, finissent par coûter beaucoup plus que prévu.

Sources

Cet article s'appuie sur des sources publiques et vérifiables :

• Evidently AI, « What is concept drift in ML, and how to detect and address it » — evidentlyai.com (définitions concept drift / data drift).
• IBM, « What Is Model Drift? » — ibm.com (définition et typologie de la dérive, seuils PSI).
• J. Gama, I. Žliobaitė, A. Bifet, M. Pechenizkiy, A. Bouchachia, « A Survey on Concept Drift Adaptation », ACM Computing Surveys, 2014 — dl.acm.org (taxonomie des régimes de dérive).
• I. Žliobaitė, « Learning under Concept Drift: an Overview », 2010 — arxiv.org (origine du terme, Schlimmer & Granger 1986, formulation P(y|x)).
• CNN Business, « Zillow's home-buying debacle shows how hard it is to use AI to value real estate » — edition.cnn.com (étude de cas Zillow Offers).
• NPR, « Zillow will stop buying and renovating homes and cut 25% of its workforce » — npr.org (chiffres du démantèlement, citation de Rich Barton).
• insideAI News, « The $500mm+ Debacle at Zillow Offers – What Went Wrong with the AI Models? » — insideainews.com (mécanismes détaillés, erreur médiane on/off-market du Zestimate).
• Iguazio, « Concept Drift and the Impact of COVID-19 on Data Science » — iguazio.com (dérive de concept liée à la pandémie).
• U.S. Census Bureau, « E-Commerce Sales Surged During the Pandemic » — census.gov (part du e-commerce 2019-2020, +43 % en valeur).
• Time, « Google Flu Trends Failure Shows Drawbacks of Big Data » — time.com (surestimation de ~140 %, « big data hubris »).
• D. Lazer, R. Kennedy, G. King, A. Vespignani, « The Parable of Google Flu: Traps in Big Data Analysis », Science, 2014 — science.org (surestimation durant 100 des 108 semaines, août 2011 à septembre 2013).
• Databricks, « Productionizing Machine Learning: From Deployment to Drift Detection » — databricks.com (méthodologie de surveillance continue en production).
• Brandon Wie, « Population Stability Index (PSI) for Model Drift Detection » — brandonwie.dev (explication détaillée du PSI et de ses seuils).
• Superwise, « A hands-on introduction to drift metrics » — superwise.ai (Kolmogorov-Smirnov, Jensen-Shannon, Wasserstein).
• NannyML, « No Ground Truth: How to Monitor ML Models » — nannyml.com (estimation de performance sans vérité terrain, CBPE et ses limites).
• Amazon Web Services, « Data and model quality monitoring with Amazon SageMaker Model Monitor » — docs.aws.amazon.com (ligne de base, contraintes, alertes cloud).
• M. Mansoury et al., « Feedback Loop and Bias Amplification in Recommender Systems », 2020 — arxiv.org (amplification du biais de popularité par réentraînement).