Un modèle peut réussir ses tests et perdre progressivement son utilité. Les clients changent, les produits évoluent, une nouvelle règle de saisie modifie les données, ou la relation entre les variables et le résultat se transforme. Cette évolution est souvent appelée dérive. Le mot couvre plusieurs phénomènes ; une surveillance sérieuse doit préciser lequel elle cherche à détecter et ce qu’elle fera lorsqu’un signal apparaît.
Ce guide propose une méthode de surveillance pour un modèle de machine learning déjà déployé. Il distingue les changements d’entrée, les changements de cible et la dégradation réelle des décisions. Les chiffres cités dans les exemples sont fictifs et servent uniquement à expliquer les calculs. Avant la mise en production, une évaluation sans fuite de données reste indispensable : un score initial biaisé rendrait la surveillance difficile à interpréter.
Définir la dérive avec précision
La dérive des données, ou dérive des entrées, signifie que la distribution des variables reçues en production diffère de celle utilisée comme référence. Un formulaire peut recueillir davantage de dossiers internationaux, une catégorie peut devenir plus fréquente ou les montants moyens peuvent changer. Cela ne prouve pas que le modèle se trompe davantage. Il peut rester performant si la relation entre les entrées et la cible demeure stable dans les zones concernées.
La dérive du concept désigne un changement dans la relation entre les variables et le résultat recherché. Une habitude d’achat peut évoluer alors que les variables mesurées gardent des distributions proches. Le modèle voit des entrées familières, mais la signification prédictive de ces entrées a changé. On ne peut généralement confirmer ce phénomène qu’avec des résultats observés et correctement reliés aux prédictions passées.
Il existe aussi une dérive de la cible : la fréquence du résultat évolue. Une hausse des défauts, des retards ou des résiliations peut modifier l’intérêt d’un seuil de décision. Les trois situations se combinent parfois. Pour éviter les diagnostics hâtifs, utilisez une formulation précise dans les rapports : « la proportion de dossiers du segment A a augmenté » ou « le rappel mesuré sur les cas étiquetés a diminué », plutôt que « le modèle dérive » sans autre détail.
Repartir du cas d’usage et des conséquences
La surveillance commence par la décision soutenue par le modèle. Prédit-il une probabilité, classe-t-il des demandes, priorise-t-il une revue humaine ou déclenche-t-il automatiquement une action ? Une variation de score n’a pas la même conséquence dans ces quatre cas. Décrivez qui reçoit la prédiction, à quel moment et ce qui se passe lorsqu’elle est incorrecte. Cette description guide les métriques, les seuils et les délais d’intervention.
Prenons un modèle qui signale des retards de livraison avant expédition. Si l’équipe peut appeler les clients concernés, une hausse des faux positifs augmente la charge de travail ; une hausse des faux négatifs laisse davantage de retards sans prévention. Le suivi doit donc distinguer ces erreurs. Une simple précision globale peut rester stable alors que le coût opérationnel change. L’article sur le choix entre précision et rappel détaille cette logique.
Fixez ensuite l’horizon d’observation. Une prédiction de retard peut être vérifiée quelques jours plus tard ; une prédiction de départ client peut demander plusieurs mois. Tant que la vérité n’est pas disponible, les métriques de performance sont provisoires ou impossibles à calculer. Le plan de surveillance doit préciser ce délai, la fréquence de mise à jour des labels et la manière d’identifier les cas dont le résultat reste inconnu.
Construire une référence crédible
Comparer la production à l’ensemble d’entraînement est intuitif, mais pas toujours juste. Cet ensemble peut couvrir plusieurs années, être volontairement équilibré ou exclure des situations rares. Une référence de validation proche du contexte de déploiement peut mieux représenter le fonctionnement attendu. Conservez néanmoins la référence d’entraînement pour comprendre l’écart avec ce que le modèle a appris.
Documentez la période, les filtres, le volume, la version du pipeline et les populations présentes dans chaque référence. Sans ces informations, une alerte peut provenir d’un changement de définition plutôt que du monde réel. Une référence figée permet de voir l’éloignement depuis le lancement. Une référence glissante aide à repérer les changements récents, mais peut finir par considérer une dégradation lente comme normale. Les deux vues répondent à des questions différentes.
Segmentez avec prudence. Un indicateur global peut cacher une forte dérive sur une région ou un canal minoritaire. À l’inverse, des segments trop petits produisent des fluctuations sans intérêt. Définissez les segments importants à partir du cas d’usage et imposez un volume minimal avant d’interpréter un pourcentage. Gardez la possibilité d’examiner les observations individuelles après une alerte, dans le respect des règles de confidentialité applicables.
Vérifier d’abord la qualité des données
Une colonne soudainement vide, un nouveau code inconnu ou un montant multiplié par cent peuvent déclencher une alerte de dérive. Le modèle n’est alors pas nécessairement devenu obsolète ; le pipeline d’alimentation est peut-être défectueux. Avant toute conclusion statistique, contrôlez le schéma, les unités, les valeurs manquantes, les doublons et la fraîcheur. Le guide sur le contrôle qualité dans un pipeline propose une méthode pour placer ces tests.
Vérifiez également le code de préparation utilisé en production. Si un encodeur de catégories ou une normalisation diffère de la version validée, le changement observé vient de l’implémentation. Conservez les versions du modèle, des transformations et des sources dans les journaux. Une dérive apparente peut disparaître après correction du traitement, mais les prédictions déjà émises pendant l’incident doivent être évaluées séparément.
La qualité des labels mérite sa propre surveillance. Si les résultats sont saisis plus tard, par une autre équipe ou selon une nouvelle définition, les métriques calculées peuvent changer sans que les prédictions aient changé. Documentez le processus de labellisation et vérifiez sa stabilité. Un modèle ne peut être jugé correctement si le critère qui définit une « bonne réponse » bouge silencieusement.
Suivre les variables numériques et catégorielles
Pour une variable numérique, commencez par des résumés lisibles : taux de valeurs manquantes, médiane, quantiles et répartition en classes pertinentes pour le métier. Une moyenne seule peut manquer un changement dans la queue de distribution. Tracez les périodes côte à côte et regardez les effectifs. Si une variable est très asymétrique, une petite hausse d’événements extrêmes peut compter davantage qu’un déplacement de la moyenne.
Pour une variable catégorielle, suivez les catégories les plus fréquentes, les nouvelles catégories et la part « autre » ou « inconnue ». Une nouvelle catégorie peut être parfaitement normale après le lancement d’un produit, mais elle peut être mal traitée par le modèle. La question est à la fois statistique et technique : comment l’encodage réagit-il à cette valeur ? Quelle décision le modèle prend-il pour les lignes concernées ?
Ne surveillez pas uniquement les variables prises une à une. Deux colonnes peuvent garder chacune leur distribution et changer de relation. Par exemple, les commandes internationales peuvent désormais être concentrées dans un canal qui était auparavant national. Une revue de quelques croisements métier importants peut révéler ce changement. Limitez toutefois les croisements automatiques : leur nombre explose rapidement et multiplie les alertes difficiles à expliquer.
Interpréter les tests statistiques avec prudence
Des tests de comparaison de distributions peuvent détecter des écarts qu’un graphique ne montre pas immédiatement. Leur résultat dépend fortement du volume d’observations. Avec beaucoup de données, un écart minuscule peut devenir statistiquement significatif ; avec peu de données, un changement important peut passer inaperçu. Associez donc le test à une mesure de taille d’effet et à une interprétation métier.
Les seuils ne doivent pas être copiés d’un tutoriel sans examen. Simulez des périodes historiques normales et des incidents connus pour voir quels seuils produisent des alertes utiles. Si vous surveillez des centaines de variables tous les jours, attendez-vous à de faux signaux même lorsque rien d’important ne change. Regroupez les alertes, hiérarchisez les variables essentielles et exigez parfois que le signal persiste plusieurs périodes.
Une alerte statistique doit ouvrir une enquête, non déclencher automatiquement un réentraînement. Demandez d’abord si le changement touche une population que le modèle sert réellement, si les prédictions deviennent plus incertaines et si les résultats observés confirment une dégradation. Un modèle réentraîné sur des données récentes mais mal étiquetées peut être pire que l’ancien. Le coût d’une fausse intervention fait partie du choix des seuils.
Mesurer la performance lorsque les résultats arrivent
Lorsque les labels sont disponibles, calculez les métriques définies avant le lancement, par période et par segment. Pour une classification, examinez les vrais et faux positifs, les vrais et faux négatifs, puis la précision et le rappel adaptés à l’usage. Une métrique agrégée ne montre pas toujours si le seuil de décision reste pertinent. Pour une régression, comparez notamment les erreurs absolues et leur distribution dans les cas importants.
Conservez la date de prédiction et la date de connaissance du résultat. Sans cette séparation, les cas les plus récents paraîtront artificiellement meilleurs ou pires parce que seuls certains labels sont déjà arrivés. Si les dossiers complexes prennent plus de temps à résoudre, les premiers résultats disponibles ne représentent pas toute la population. Signalez explicitement le taux de labels connus et les biais possibles dans les rapports.
Comparez les nouvelles métriques à une référence raisonnable, avec leurs volumes et une marge d’incertitude. Une baisse de trois points sur vingt dossiers peut relever du hasard ; la même baisse répétée sur plusieurs milliers de dossiers demande une enquête. Vérifiez aussi le nombre de décisions et la charge créée pour les équipes. Une amélioration mathématique qui produit trop d’alertes peut dégrader le service réel.
Examiner les segments et l’équité d’usage
Les performances moyennes peuvent rester bonnes alors qu’un groupe d’utilisateurs est moins bien servi. Choisissez des segments liés au déploiement : région, canal, type de produit ou période. Selon le contexte, des analyses supplémentaires peuvent être nécessaires pour évaluer les effets sur les personnes concernées. Les données permettant ces analyses doivent être traitées avec précaution, selon les règles internes et juridiques pertinentes.
Un segment qui dérive n’appelle pas automatiquement un modèle distinct. Vérifiez d’abord la qualité de ses données, son volume et la définition de sa cible. Comparez ensuite les erreurs et leurs conséquences. Une différence de performance peut venir d’un manque de données d’entraînement, d’un processus opérationnel différent ou d’une nouvelle population. Chaque cause appelle une réponse différente.
Le cadre AI RMF du NIST recommande de documenter les méthodes de mesure et de surveiller les systèmes en production dans leur contexte d’usage. Cette approche évite de limiter la surveillance à un tableau de chiffres techniques. Incluez les retours des utilisateurs et les incidents opérationnels, car certains défauts importants ne se voient pas dans une métrique globale.
Définir des alertes et une procédure d’enquête
Une alerte utile contient la variable ou la métrique concernée, la période, le volume, la référence, l’ampleur de l’écart et la version du modèle. Elle indique qui doit examiner le signal. Évitez les notifications vagues du type « dérive détectée » : elles imposent de reconstruire tout le contexte avant d’agir. Une vue permettant de comparer les observations touchées avec la référence accélère le diagnostic.
Organisez l’enquête dans un ordre simple : confirmer que les données sont arrivées complètement, vérifier le pipeline et les changements de source, examiner les segments concernés, puis comparer les prédictions et les résultats connus. Notez les hypothèses écartées. Si un défaut de source est trouvé, corrigez-le et évaluez l’effet sur les prédictions passées. Si le changement est réel, discutez avec les responsables métier avant de choisir une action.
Prévoyez plusieurs réponses possibles : poursuivre sous surveillance, ajuster le seuil de décision après validation, revenir à un modèle antérieur, mettre une revue humaine, collecter de nouveaux labels ou réentraîner. L’ordre dépend du risque. Une procédure de retour arrière testée est souvent plus utile qu’une promesse de réentraînement immédiat. Toute modification doit produire une nouvelle comparaison sur un jeu de test gardé à l’écart des décisions de développement.
Réentraîner sans effacer la preuve du problème
Le réentraînement est une hypothèse de solution, pas une conséquence automatique d’un graphique déplacé. Définissez le jeu de données admissible, la période, la qualité des labels et le protocole de validation. Conservez le modèle précédent, les résultats de référence et les cas qui ont déclenché l’enquête. Sinon, il devient impossible de savoir si la nouvelle version a réellement corrigé le problème ou seulement déplacé l’erreur.
Évaluez le nouveau modèle sur des périodes récentes et sur des cas historiques importants. Un modèle adapté au mois dernier peut oublier une situation rare mais critique. Vérifiez la calibration si les probabilités servent à fixer des seuils, et comparez les conséquences opérationnelles des décisions. Un gain de score moyen ne suffit pas lorsque le coût des erreurs varie selon les cas.
La reproductibilité des expériences de machine learning aide à rendre cette comparaison vérifiable. Archivez la version des données, du code, des paramètres et des transformations. Notez aussi pourquoi la décision de déploiement a été prise, qui l’a validée et ce qui déclencherait un retour arrière. Cette traçabilité réduit les débats fondés sur des souvenirs divergents lorsque de nouvelles alertes apparaissent.
Construire un tableau de bord qui conduit à l’action
Un tableau de bord de surveillance doit commencer par l’état du service : version active, volume de prédictions, fraîcheur des entrées, taux d’erreurs techniques et disponibilité des labels. Viennent ensuite les indicateurs de qualité, les changements de distribution et les métriques de performance. Cet ordre aide à comprendre si une baisse de score vient du modèle, du pipeline ou d’un échantillon incomplet.
Montrez les tendances et les effectifs, pas uniquement des feux de couleur. Un seuil franchi de peu pendant une journée n’a pas la même portée qu’une dégradation continue pendant plusieurs semaines. Permettez de filtrer par segment important et d’ouvrir la définition de chaque indicateur. Les utilisateurs du tableau doivent savoir ce qui est calculé, sur quelle population et avec quel retard.
Revue et responsabilité sont aussi importantes que l’interface. Fixez une fréquence d’examen, un responsable de premier niveau et une personne habilitée à décider d’un changement de modèle. Conservez une courte note pour chaque alerte traitée. Le tableau de bord devient ainsi une mémoire opérationnelle, pas seulement un ensemble de courbes. Pour l’organisation de ce travail, voir également les pratiques MLOps.
Questions fréquentes
Une dérive des entrées signifie-t-elle que le modèle est mauvais ?
Non. Elle signale que les données reçues diffèrent de la référence choisie. Il faut vérifier la qualité des données, les populations concernées et, dès que possible, les résultats observés. Une variation peut être attendue et sans effet notable sur la décision.
Peut-on surveiller un modèle sans labels immédiats ?
Oui, en suivant la qualité des entrées, les distributions, les volumes, les sorties et les incidents. Il faut toutefois reconnaître que ces indicateurs ne mesurent pas directement la justesse. Prévoyez le rattachement ultérieur des labels aux prédictions pour vérifier les hypothèses.
Quand faut-il réentraîner ?
Quand une évaluation montre qu’une nouvelle version répond mieux au besoin, sur des données fiables et avec un protocole comparable. Le calendrier seul ou une alerte statistique isolée ne suffisent pas. Le retour arrière et la surveillance après déploiement font partie de la décision.
La surveillance de la dérive est une boucle de décision : observer, vérifier, expliquer, agir et mesurer l’effet de l’action. Elle reste utile lorsque ses indicateurs correspondent à des risques réels et lorsque ses alertes ont un propriétaire. Cette logique s’applique aussi aux systèmes génératifs : l’évaluation d’un RAG demande de distinguer les défauts de recherche des défauts de réponse.