#Mise en production des modèlesCopier le lien

Mettre un modèle en production ne se résume pas à exposer une API. On définit des contrats d'entrées et de sorties, on versionne le modèle et ses dépendances, et on surveille la latence, les erreurs et la dérive de données. Les tests d'intégration couvrent le pipeline de features autant que l'inférence.

La stratégie de déploiement alterne canary, A/B et shadow traffic pour limiter les risques. Le feedback de production alimente un processus d'amélioration continue avec des données fraîches et des protocoles de réentraînement maîtrisés.

#Prérequis et objectifsCopier le lien

Prérequis: TP « Pipeline ML complet » (pipeline scikit-learn reproductible), page « Évaluation et généralisation » (dérive, protocoles), notions d'API du module « Backend pratique ».

Objectifs d'apprentissage:

• définir le contrat d'un service de prédiction: schéma d'entrée, sortie, garanties de latence;
• versionner modèle, preprocessing et dépendances comme un tout indissociable;
• choisir une stratégie de déploiement (canary, A/B, shadow) selon le risque et la capacité de mesure;
• définir les indicateurs de surveillance (latence, erreurs, dérive) et les seuils de rollback;
• écrire le protocole de réentraînement avant d'en avoir besoin.

#Du labo à la prodCopier le lien

#Le contrat de serviceCopier le lien

Un service de prédiction se spécifie comme une API: types et plages des features attendues, comportement sur valeurs manquantes ou inattendues, format de sortie (score brut, probabilité calibrée, décision à seuil), et garanties non fonctionnelles (latence p95, débit). Deux pièges spécifiques au ML:

Le preprocessing fait partie du contrat. Le modèle a été entraîné sur des features standardisées, encodées, imputées d'une certaine façon: le service doit appliquer exactement la même chaîne. C'est la raison de versionner le Pipeline complet (preprocessing inclus) et pas seulement les poids: un modèle servi avec un scaler différent de celui de l'entraînement produit des prédictions fausses sans erreur visible.

Les plages de validité sont explicites. Un modèle entraîné sur des montants de 0 à 10000 euros n'a aucune garantie au-delà; le contrat doit dire ce qui se passe (refus, valeur par défaut, flag de faible confiance), plutôt que laisser le modèle extrapoler en silence.

#Packaging et reproductibilitéCopier le lien

Le livrable minimal: l'artefact modèle (Pipeline sérialisé), le fichier de dépendances épinglées (versions exactes de scikit-learn, numpy, etc.), le schéma de données attendu, et les métriques de référence obtenues en validation. Deux artefacts entraînés avec des versions de bibliothèque différentes peuvent diverger; l'épinglage est une exigence de correction, pas de confort.

#Tests: au-delà de l'accuracyCopier le lien

Tests de contrat: entrées valides, entrées invalides (types, plages, catégories inconnues), valeurs manquantes; chaque cas a un comportement défini et testé.

Tests de régression de prédiction: un jeu de requêtes de référence, figé, rejoué à chaque déploiement; les prédictions doivent rester identiques (ou dans une tolérance écrite) sauf changement volontaire. Ce test détecte les régressions silencieuses: dépendance montée de version, preprocessing réordonné.

Tests de performance: latence p95 sous charge représentative, empreinte mémoire. Un modèle plus précis de deux points mais trois fois plus lent peut être un mauvais trade.

Tests de non-régression des métriques d'équité: les écarts par sous-groupe (page « Éthique et interprétabilité ») sont vérifiés à chaque version, pas seulement au premier déploiement.

#Stratégies de déploiementCopier le lien

#Diagramme: canary contrôléCopier le lien

Canary: la nouvelle version reçoit une petite fraction du trafic réel (typiquement 1 à 10%), le reste reste sur la version stable. On compare les métriques des deux branches sur des populations comparables; en cas d'écart hors seuils, rollback automatique. Condition de validité: assez de trafic pour que la comparaison soit statistiquement significative pendant la fenêtre d'observation.

A/B test: deux versions servies à des groupes aléatoires d'utilisateurs, décision sur une métrique métier (taux de conversion, satisfaction), pas sur une métrique de modèle. Durée calculée avant le test (puissance statistique), pas arrêtée au moment où ça arrange.

Shadow traffic: la nouvelle version reçoit une copie du trafic réel mais ses réponses ne sont pas servies. Idéal pour mesurer latence et distribution des prédictions sans risque utilisateur; ne mesure aucune métrique métier, puisque l'utilisateur ne subit pas les nouvelles décisions.

#Surveillance: ce qui se dégrade et comment le voirCopier le lien

Latence: p50, p95, p99. Le p95 est la métrique de contrat; le p99 révèle les cas pathologiques (requêtes volumineuses, cache froid).

Erreurs: taux d'erreurs techniques (500, timeouts) et erreurs de contrat (entrées hors spécification), qui signalent que la population réelle diverge de ce qui était prévu.

Dérive de données: distribution des features en entrée comparée à une référence (test de Kolmogorov-Smirnov, divergence KL, ou simple suivi de quantiles). Une dérive de features ne dégrade pas forcément la qualité, mais elle invalide les garanties: le modèle opère hors de son domaine de validité.

Dérive de concept: la relation entrée/sortie change. Détectable seulement avec des labels retardés (retours utilisateurs, décisions confirmées a posteriori). C'est la dérive la plus dangereuse et la plus lente à apparaître.

Qualité des prédictions en production: là où les labels arrivent, suivre la métrique principale sur fenêtre glissante, avec les mêmes précautions de comparaison que le canary (périodes et populations comparables).

#Réentraînement: le protocole s'écrit avant la panneCopier le lien

Un protocole de réentraînement précise: la fenêtre de données (période glissante ou cumulée, avec justification), le pipeline de features (identique à la production), les critères de déclenchement (calendar-based, dérive détectée, dégradation de métrique), la validation hors-ligne obligatoire avant promotion (le nouveau modèle doit battre le champion sur un protocole figé, pas « sembler meilleur »), et le plan de retour arrière. Sans cela, le réentraînement automatique devient une bombe à retardement: un incident de données en amont se propage directement en production.

#Exercice vérifiable: le plan de déploiement d'un modèleCopier le lien

Exercice d'écriture, avec livrables observables. Considérez un modèle de scoring de risque de défaut, 10000 requêtes/jour, labels confirmés à J+30. Rédigez: (1) le contrat d'entrée/sortie avec les comportements aux bornes; (2) les SLI/SLO: latence p95 cible, taux d'erreur, seuils de dérive de features déclenchant une alerte; (3) le plan canary: fraction initiale, durée minimale pour atteindre la significativité au vu du volume, métriques de promotion et de rollback; (4) le protocole de réentraînement complet. Éléments de corrigé vérifiables: le contrat traite explicitement le cas « montant hors plage » et « catégorie inconnue »; le canary à 5% (500 req/jour) nécessite plusieurs jours pour comparer les taux de défaut, car l'événement est rare: la fenêtre d'observation doit être calculée à partir du taux de base, pas choisie arbitrairement; les labels de qualité n'étant disponibles qu'à J+30, la détection de dérive de concept est retardée d'un mois, ce qui impose une surveillance de features plus serrée en compensation; le réentraînement exige une validation hors-ligne contre le champion sur une période de test disjointe, jamais une simple comparaison au fil de l'eau.

#QuizCopier le lien