Monitoring & drift

Le piège : tout est vert, tout est faux

CPU normal, latence normale, 0 erreur 5xx… et le modèle raconte n'importe quoi depuis trois semaines. La dégradation d'un modèle est silencieuse par nature : il répond toujours, juste de plus en plus mal. Ton monitoring backend surveille le service ; il faut y ajouter le monitoring du modèle.

Les quatre étages

1. Système (tu maîtrises) : latence, erreurs, saturation, VRAM/TTFT pour les LLMs ;
2. Données d'entrée : distribution de chaque feature comparée à l'entraînement — % de nulls, moyennes, catégories inconnues. Un data drift annonce la dégradation avant qu'elle ne se voie ;
3. Prédictions : distribution des sorties (le taux de « fraude prédite » saute de 2 % à 9 % ? incident amont probable), confiance moyenne ;
4. Performance réelle : le vrai score… quand les labels arrivent. C'est le feedback delay : la fraude avérée se sait à 90 jours — d'où l'importance des étages 2-3 comme alarmes précoces.

Mesurer une dérive

Comparer deux distributions : PSI (Population Stability Index, le standard bancaire — alerte à 0.2) ou test de Kolmogorov-Smirnov. En pratique : un job planifié calcule le PSI de chaque feature sur la fenêtre glissante vs la référence d'entraînement, et alerte au dépassement.

Boucler la boucle

Le monitoring n'est utile que s'il déclenche quelque chose :

drift/perf sous seuil → alerte → réentraînement (pipeline module 4, déjà idempotent)
   → évaluation vs modèle courant → promotion registry → déploiement canary

Le canary/shadow mérite le détour : le nouveau modèle reçoit d'abord un trafic miroir (shadow : il prédit, on n'utilise pas) ou une fraction (canary), comparé au champion en continu. Le pattern champion/challenger — ton blue-green, avec une métrique métier comme arbitre.