Leçon 4 — La surveillance
Le mode de panne propre au machine learning
Une application qui tombe déclenche une alerte, quelqu'un est réveillé, le problème est corrigé.
Un modèle qui se dégrade ne déclenche rien. Il continue de répondre, dans le bon format, avec la même latence et la même assurance. Simplement, ses prédictions sont plus souvent fausses.
C'est ce que la surveillance doit attraper, et c'est pour cela que la supervision technique habituelle — disponibilité, temps de réponse, taux d'erreur HTTP — est nécessaire et complètement insuffisante.
Les deux dérives, et pourquoi la distinction compte
La dérive des données
Ce qui entre dans le modèle change. La distribution des variables s'écarte de celle vue à l'entraînement.
Causes ordinaires : une nouvelle gamme de produits, une campagne qui attire une clientèle différente, un changement de saison, un capteur remplacé, un formulaire modifié qui ne remplit plus le même champ, un nouveau pays ouvert.
La bonne nouvelle : cela se détecte sans connaître la vérité. Il suffit de comparer la distribution actuelle des entrées à celle de référence.
La dérive du concept
La relation entre les entrées et la sortie change. Les mêmes caractéristiques ne conduisent plus au même résultat.
Causes ordinaires : un concurrent modifie ses prix et le comportement d'achat change ; les fraudeurs adaptent leurs méthodes à votre détection ; une réglementation nouvelle modifie les décisions ; une crise change les priorités des clients.
La mauvaise nouvelle : cela ne se détecte pas sans étiquettes. Les entrées peuvent rester parfaitement identiques alors que le modèle est devenu faux. C'est la dérive la plus dangereuse, et elle exige de connaître la vérité terrain.
Votre modèle influence les données qu'il recevra demain. Un moteur de recommandation qui met un produit en avant fait grimper ses ventes, ce qui confirme au réentraînement suivant que ce produit se vend bien. Un modèle de risque qui refuse un profil ne verra jamais si ce profil aurait remboursé.
Ce phénomène n'apparaît sur aucun indicateur classique, et il fausse progressivement le modèle. Le seul remède connu : conserver une petite fraction de décisions aléatoires — quelques pourcents — pour continuer à observer ce que le modèle aurait écarté. C'est un coût assumé en échange d'une capacité à mesurer.
Les quatre niveaux de surveillance
Ils se mettent en place dans cet ordre, du plus facile au plus informatif.
Niveau 1 — Les indicateurs techniques
Disponibilité, latence aux centiles hauts, taux d'erreur, volume de requêtes, consommation mémoire.
C'est le socle, il est identique à n'importe quel service, et il ne dit rien sur la qualité des prédictions. Un modèle parfaitement disponible peut se tromper systématiquement.
Niveau 2 — Les entrées
Là commence la vraie surveillance du modèle. À suivre :
- Le taux de valeurs manquantes par variable, comparé à la référence. Une variable qui passe de 2 % à 40 % de valeurs manquantes signale une rupture en amont.
- La distribution de chaque variable importante : moyenne, écart-type, quantiles pour les variables numériques ; fréquence des catégories pour les variables qualitatives.
- L'apparition de catégories inconnues, absentes à l'entraînement.
- Les valeurs hors plage attendue.
Comment quantifier un écart de distribution : l'indice de stabilité de population — PSI — est le plus utilisé en pratique parce qu'il est simple et interprétable. La convention courante : en dessous de 0,1, pas de changement significatif ; entre 0,1 et 0,25, changement modéré à examiner ; au-delà de 0,25, changement important. Le test de Kolmogorov-Smirnov et la divergence de Jensen-Shannon sont des alternatives.
Le piège : sur beaucoup de variables, vous obtiendrez des alertes tous les jours. Surveillez les cinq à dix variables les plus importantes du modèle, pas les deux cents.
Niveau 3 — Les sorties
Ce niveau est très informatif et coûte presque rien à mettre en place.
- La distribution des prédictions. Si un modèle prédisait 3 % de fraude et en prédit soudain 11 %, quelque chose s'est passé, même sans connaître la vérité.
- La distribution des scores de confiance. Un déplacement vers des scores plus bas signale que le modèle rencontre des cas qu'il connaît mal, et cela précède généralement la dégradation mesurée.
- Le taux d'abstention, si votre système peut refuser de décider.
Niveau 4 — La performance réelle
C'est le seul niveau qui mesure ce qui compte, et le plus difficile, parce qu'il faut la vérité terrain.
Le problème est le délai. Vous prédisez aujourd'hui une résiliation à 60 jours : vous saurez dans 60 jours. Vous détectez une fraude : la contestation arrive dans trois semaines. Vous prédisez un défaut de paiement : la réponse vient dans un an.
Ce qui fonctionne pour raccourcir le délai :
- Un échantillon annoté manuellement. Quelques dizaines de cas par semaine vérifiés par un humain donnent une mesure continue, avec une incertitude connue. C'est le dispositif le plus rentable, et le plus rarement mis en place.
- Des indicateurs de substitution disponibles plus tôt : le client a-t-il ouvert le courriel, l'opérateur a-t-il suivi la recommandation, le contrôle qualité aval a-t-il rejeté la pièce.
- Les corrections des utilisateurs. Quand un opérateur modifie une prédiction, c'est une étiquette gratuite. Enregistrez-les systématiquement : c'est la source d'annotation la moins chère qui existe.
Le jeu de référence figé
Un dispositif simple, peu coûteux, et remarquablement efficace.
Constituez un jeu de quelques centaines d'exemples avec leurs vraies réponses, et repassez-le régulièrement — chaque semaine, et systématiquement après tout changement de modèle, de code ou d'environnement.
Ce que cela vous donne : la certitude qu'aucune modification technique n'a cassé quelque chose ; une détection immédiate d'un problème d'environnement ; et une base de comparaison stable entre versions.
Ce que cela ne vous donne pas : la performance sur les données actuelles. Le jeu est figé, donc il ne dérive pas. Il détecte les régressions techniques, pas la d érive du monde. Les deux dispositifs sont complémentaires et ne se remplacent pas.
Construire des alertes qui servent
L'échec le plus courant de la surveillance n'est pas l'absence d'alertes : c'est leur excès. Une équipe qui reçoit trente alertes par jour les ignore toutes, et la seule qui comptait passe avec les autres.
Quatre règles :
Alerter sur peu de choses. Trois à cinq indicateurs vraiment importants valent mieux que cinquante. Le reste va sur un tableau de bord consulté, pas dans une notification.
Chaque alerte doit avoir une action associée, écrite à l'avance. Si vous ne savez pas quoi faire quand elle se déclenche, ce n'est pas une alerte : c'est du bruit. Supprimez-la ou définissez l'action.
Utiliser une fenêtre temporelle. Un pic isolé n'est pas une dérive. Alertez sur une moyenne glissante de plusieurs jours, sinon vous réagirez à du bruit statistique.
Séparer l'urgent de l'important. Le service est tombé : notification immédiate. La distribution d'une variable dérive : point hebdomadaire. Mélanger les deux détruit l'attention.
Le tableau de bord minimal
Ce qui doit exister pour tout modèle en production, et qui tient sur un écran :
| Indicateur | Fréquence | Ce qu'il révèle |
|---|---|---|
| Volume de prédictions | quotidienne | rupture d'alimentation, changement d'usage |
| Latence au 95e centile | quotidienne | dégradation d'infrastructure |
| Taux de valeurs manquantes, 5 variables clés | quotidienne | rupture en amont |
| PSI sur les 5 variables clés | hebdomadaire | dérive des données |
| Distribution des prédictions | quotidienne | changement de comportement du modèle |
| Distribution des scores de confiance | hebdomadaire | signal précoce de dégradation |
| Performance sur échantillon annoté | hebdomadaire | performance réelle |
| Jeu de référence figé | hebdomadaire et à chaque changement | régression technique |
| Métrique métier | mensuelle | la valeur réellement apportée |
La dernière ligne est celle qui décide de la survie du projet, et c'est la plus souvent absente.
Quand réentraîner
Trois déclencheurs, par ordre de pertinence.
Sur dégradation constatée. La bonne approche : les indicateurs montrent une baisse, on réentraîne. Cela suppose de mesurer, ce qui est tout l'objet de cette leçon.
Sur calendrier. Chaque mois ou chaque trimestre, indépendamment des indicateurs. C'est simple, prévisible, et cela réentraîne parfois pour rien ou trop tard. Acceptable comme filet de sécurité, insuffisant comme unique dispositif.
Sur dérive détectée. Un PSI élevé déclenche le réentraînement. Attention : une dérive des entrées n'implique pas nécessairement une dégradation de performance. Vérifiez avant d'agir.
Un réentraînement automatique sur des données non validées propage silencieusement les erreurs de données dans le modèle. Un champ mal alimenté pendant une semaine devient un modèle appris sur des données fausses, et il passe en production sans que personne ne l'ait regardé.
Les prérequis avant d'automatiser : des tests de qualité des données qui bloquent le pipeline, une validation automatique du nouveau modèle contre l'ancien sur un jeu de test, un déploiement en canari, et un retour arrière testé. Tant que ces quatre éléments n'existent pas, gardez le déclenchement manuel.
Et n'oubliez pas la question inverse : parfois, la bonne décision est de retirer le modèle. S'il n'apporte plus de valeur mesurable, le maintenir coûte de l'argent et de l'attention. Un modèle retiré proprement est un succès de gestion, pas un échec.
À retenir
- Un modèle qui se dégrade ne déclenche aucune alerte : la supervision technique est nécessaire et très insuffisante.
- La dérive des données se détecte sans étiquettes ; la dérive du concept exige la vérité terrain et c'est la plus dangereuse.
- Les boucles de rétroaction faussent progressivement le modèle ; conservez une petite fraction de décisions aléatoires.
- Quatre niveaux : technique, entrées, sorties, performance réelle. Les niveaux 2 et 3 coûtent peu et rapportent beaucoup.
- Surveillez cinq à dix variables clés, pas deux cents, et utilisez le PSI pour quantifier l'écart.
- Un échantillon annoté chaque semaine est le dispositif le plus rentable pour mesurer la performance réelle.
- Une alerte sans action associée écrite d'avance est du bruit ; alertez sur peu de choses avec une fenêtre temporelle.
- N'automatisez le réentraînement qu'avec tests de données, validation, canari et retour arrière testé.
Leçon suivante — L'organisation : rôles, propriété, dette →