Surveillance des modèles ML : un playbook pour CDO

Un modèle de scoring crcrThe percentage of visitors or prospects who complete a desired action (purchase, sign-up, contact form), calculated as conversions divided by total opportunities.Voir la définition complète →édit déployé en janvier peut se retrouver, dès septembre de la même année, à prédire sur une distribution de données que ses développeurs n'ont jamais vue. Ce n'est pas une hypothèse : c'est ce qui s'est produit chez plusieurs grands prêteurs lors des cycles de taux rapides de 2022-2023, lorsque les comportements de remboursement ont divergé brutalement des patterns d'entraînement. Le modèle continuait à tourner, les métriques de production semblaient stables, et les équipes risque découvraient le problème plusieurs semaines plus tard, lors de la réconciliation trimestrielle.

La difficulté en 2026 n'est pas l'absence d'outils, mais l'absence de processus. Les plateformes MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.Voir la définition complète → (Databricks, AWS SageMaker Model Monitor, Azure ML, ou des solutions spécialisées comme Evidently AI) fournissent des primitives de détection. Ce que la plupart des organisations n'ont pas, c'est un protocole clair sur quand agir et comment décider qu'un réentraînement est justifié plutôt que superflu.

Construire le système de surveillance : séquence concrète

Étape 1 : distinguer trois types de dérive avant de configurer quoi que ce soit

La dérive de données d'entrée (data drift) signifie que la distribution des features a changé. La dérive de concept (concept drift) signifie que la relation entre les features et la cible a changé, même si les inputs semblent stables. La dérive de performance est détectable directement sur les métriques (AUC, RMSE, précision), mais elle suppose que vous avez des labels en temps réel, ce qui n'est souvent pas le cas.

Commencez par auditer vos cas d'usage : pour lesquels avez-vous un retour de labels rapide (quelques heures, quelques jours) ? Pour lesquels le label n'arrive que dans 30, 60 ou 90 jours ? Cette distinction conditionne l'ensemble de votre stratégie de monitoring.

Étape 2 : poser des seuils par modèle, pas globalement

Une erreur fréquente consiste à appliquer un seuil unique de drift (souvent PSI > 0,2 ou une p-value sur un test KS) à tous les modèles de l'entreprise. Un modèle de recommandation e-commerce tolère une dérive saisonnière naturelle. Un modèle de détection de fraude, non.

Pour chaque modèle, documentez : la fréquence de rafraîchissement attendue des données d'entrée, le coût métier d'une fausse alarme de réentraînement (temps ingénieur, risque de régression), le coût d'un modèle dégradé non détecté. Avec ces trois paramètres, vous pouvez calibrer des seuils asymétriques et défendables devant le COMEX.

Étape 3 : instrumenter en couches

Ne vous limitez pas aux métriques agrégées. Configurez au minimum :

• un suivi des distributions feature par feature (PSI, distance de Wasserstein selon la nature de la variable)
• une surveillance des prédictions sortantes (distribution du score, proportion de prédictions positives)
• une alerte sur les données manquantes ou les anomalies de pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → en amont, qui génèrent souvent de faux positifs de dérive

Les équipes qui ne surveillent que la performance agrégée manquent les dérives localisées : un modèle de churn peut se dégrader uniquement sur le segment mobile sans que le AUC global ne bouge significativement pendant plusieurs semaines.

Étape 4 : définir des triggers de réentraînement, pas juste des alertes

Une alerte sans protocole de réponse est du bruit. Définissez deux niveaux de réponse distincts.

Le premier niveau est le réentraînement automatique : déclenché sur un pipeline CI/CD, avec validation automatique sur un hold-out récent, déploiement conditionnel si les métriques sont supérieures au modèle en production. Ce niveau convient aux modèles à faible impact métier ou aux modèles pour lesquels vous avez des données labellisées fraîches en continu.

Le deuxième niveau est le réentraînement supervisé : une alerte est émise, une équipe data science analyse les causes avant d'agir. Ce niveau est obligatoire pour les modèles réglementés (notation de crédit, scoring RH, modèles utilisés dans des décisions à impact individuel significatif).

Étape 5 : conserver une baseline de comparaison vivante

Le modèle de référence n'est pas celui du dernier sprint. Conservez en production (en shadow mode) la version précédente du modèle pendant au moins 30 jours après chaque mise à jour. Cela permet de distinguer une dégradation due à la dérive d'une régression introduite par le réentraînement lui-même, distinction que beaucoup d'organisations sont incapables de faire après coup.

Pièges courants et comment les éviter

Le premier piège est de confondre dérive et bruit. Un pic de PSI sur 48 heures peut refléter une anomalie d'ingestion, une promotion marketing ou un incident technique en amont. Avant de déclencher un réentraînement, vérifiez systématiquement les logs de pipeline. Plusieurs équipes ont réentraîné des modèles sur des données corrompues par une migration ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète →, produisant un modèle plus dégradé que l'original.

Le deuxième piège est la prolifération des alertes sans gouvernance. Databricks, SageMaker et leurs équivalents génèrent facilement des dizaines d'alertes par jour si les seuils ne sont pas calibrés. Un CDO qui hérite de 200 alertes hebdomadaires de dérive finit par les ignorer toutes. Limitez les alertes actionnables à celles pour lesquelles un responsable nommé a une procédure de réponse documentée.

Le troisième piège est d'oublier le réentraînement adversarial dans les cas de fraude ou de cybersécurité. Dans ces domaines, la dérive n'est pas accidentelle : des acteurs l'induisent délibérément pour contourner vos modèles. Une stratégie de réentraînement purement réactive est insuffisante ; il faut coupler la surveillance à une veille sur les nouveaux patterns d'attaque.

Pour démarrer cette semaine

• Listez vos dix modèles en production et identifiez, pour chacun, le délai médian entre déploiement et dernier réentraînement.
• Pour les trois modèles les plus critiques, vérifiez s'il existe un seuil de dérive documenté et un responsable désigné pour agir en cas d'alerte.
• Choisissez un modèle à faible risque pour tester un pipeline de réentraînement automatique avec validation sur hold-out récent, avant de l'étendre aux cas sensibles.
• Ajoutez à votre prochain comité data un point fixe mensuel sur l'état de santé des modèles en production, avec un indicateur simple : pourcentage de modèles avec monitoring actif et seuils calibr