Leçon 3 — Le déploiement
Trois modes, et le choix est structurant
La question n'est pas « comment déployer » mais « quand la prédiction doit-elle être disponible ». La réponse détermine tout le reste : l'architecture, le coût, la complexité et les contraintes de latence.
Mode 1 — Le traitement par lots
Le modèle tourne périodiquement sur un ensemble d'enregistrements, et les prédictions sont stockées pour être lues plus tard.
Exemple : chaque nuit, calculer le score de résiliation des 12 000 clients et écrire les résultats dans une table. Le lendemain, l'équipe commerciale consulte la table.
Pourquoi c'est très souvent le bon choix :
- Aucune contrainte de latence. Le traitement peut prendre une heure, personne n'attend.
- Infrastructure banale. Une tâche planifiée et une table. Pas de service à maintenir en haute disponibilité.
- Débogage confortable. Les entrées et les sorties sont persistées : on peut relire, comparer, rejouer.
- Coût maîtrisé. On calcule une fois par période, pas à chaque consultation.
Sa limite : les prédictions sont périmées entre deux exécutions, et l'on ne peut pas prédire pour une entité qui vient d'apparaître.
Commencez par le traitement par lots dès que le besoin le permet, ce qui est le cas beaucoup plus souvent qu'on ne le croit. Beaucoup d'équipes construisent un service temps réel là où une table rafraîchie chaque nuit aurait suffi, et paient ce choix en complexité, en incidents et en coût pendant des années.
La question à poser : la décision est-elle prise dans la seconde suivant l'événement ? Si non, le traitement par lots suffit.
Mode 2 — Le service en ligne
Le modèle est exposé derrière une interface appelée à la demande, et répond en quelques dizaines ou centaines de millisecondes.
Exemple : au moment du paiement, évaluer le risque de fraude sur la transaction en cours.
Quand c'est nécessaire : quand la prédiction dépend d'informations connues seulement à l'instant de la demande — le contenu du panier, la géolocalisation, le texte que l'utilisateur vient de saisir.
Ce que cela impose, et qu'on sous-estime :
- Un service à maintenir disponible, avec supervision, redémarrage automatique, montée en charge.
- Une latence garantie, mesurée sur les percentiles hauts et non sur la moyenne : c'est le 95e ou 99e centile qui détermine l'expérience réelle.
- La récupération des variables en temps réel. C'est souvent le vrai goulot d'étranglement : si le modèle a besoin du « nombre de commandes des 30 derniers jours », il faut le calculer en quelques millisecondes. D'où l'intérêt d'un magasin de variables avec un accès rapide, évoqué en leçon 2.
- Une dégradation gracieuse : que renvoie le système si le modèle est indisponible ? Une valeur par défaut, une règle simple, une erreur ? Cette décision doit être prise, pas découverte lors du premier incident.
Le compromis courant et souvent optimal : précalculer par lots les variables lentes, et ne calculer en ligne que ce qui dépend de l'instant. On obtient la réactivité sans la complexité complète.
Mode 3 — L'embarqué
Le modèle est sur l'appareil : téléphone, navigateur, caméra, capteur industriel.
Pourquoi : latence de quelques millisecondes sans aller-retour réseau, fonctionnement hors ligne, et confidentialité — les données ne quittent pas l'appareil, ce qui règle beaucoup de questions réglementaires.
Ce que cela impose :
- Un modèle compact. On utilise des architectures conçues pour cela, comme les familles MobileNet vues dans le cours de vision, et des techniques de réduction : quantification, qui réduit la précision numérique des poids, élagage, qui supprime les connexions peu utiles, distillation, qui transfère les capacités vers un modèle plus petit.
- Un format d'exécution adapté : ONNX Runtime, TensorFlow Lite, Core ML selon la cible.
- Une stratégie de mise à jour. Un modèle sur cent mille appareils ne se met pas à jour d'une commande, et vous vivrez avec plusieurs versions en circulation simultanément.
- Une surveillance dégradée : vous ne voyez pas ce qui se passe sur les appareils, sauf si vous remontez explicitement des indicateurs, ce qui pose ses propres questions de vie privée.
Le tableau de choix
| Traitement par lots | Service en ligne | Embarqué | |
|---|---|---|---|
| Latence | minutes à heures | millisecondes | millisecondes |
| Complexité d'exploitation | faible | élevée | moyenne |
| Coût d'infrastructure | faible | élevé | quasi nul |
| Fraîcheur des prédictions | périodique | immédiate | immédiate |
| Débogage | facile, tout est persisté | moyen | difficile |
| Fonctionne hors ligne | sans objet | non | oui |
| Confidentialité des données | serveur | serveur | sur l'appareil |
| À privilégier quand | la décision n'est pas immédiate | l'entrée est connue à l'instant | réseau absent ou données sensibles |
Mettre en service sans casser
Le modèle est prêt. Le basculer d'un coup sur 100 % du trafic est une mauvaise idée. Quatre stratégies, à combiner.
Le déploiement en ombre
Le nouveau modèle reçoit le trafic réel et ses prédictions sont enregistrées sans être utilisées. L'ancien modèle continue de décider.
C'est la première étape à faire systématiquement. Elle valide gratuitement ce qui casse le plus souvent : le format des données réelles, les valeurs manquantes inattendues, la latence sous charge, et la comparaison des distributions de prédictions entre ancien et nouveau. Aucun risque utilisateur, et l'essentiel des surprises est détecté là.
Le déploiement canari
On envoie une petite fraction du trafic — 1 %, puis 5 %, puis 25 % — au nouveau modèle, en surveillant les indicateurs techniques et métier à chaque palier.
Le point qui compte : définir à l'avance les critères d'arrêt. « Si le taux d'erreur dépasse X ou si la latence au 95e centile dépasse Y, on revient en arrière automatiquement. » Un critère décidé pendant l'incident n'est pas un critère.
Le test A/B
Deux modèles servent deux groupes d'utilisateurs comparables, et l'on mesure la métrique métier, pas la métrique de modèle.
C'est le seul moyen de savoir si le nouveau modèle apporte réellement de la valeur. Un modèle plus précis peut produire un résultat métier inférieur — par exemple parce qu'il concentre ses prédictions sur des cas où l'action n'a pas d'effet.
Attention à la durée : il faut assez de données pour conclure, et une durée qui couvre un cycle complet — semaine, mois, saison selon l'activité. Conclure au bout de deux jours est un piège classique.
Le drapeau de fonctionnalité
Un interrupteur qui permet de désactiver le modèle en une seconde, sans redéploiement, et de revenir au comportement précédent.
C'est le filet de sécurité minimal. S'il n'existe pas, la seule option en cas d'incident est un déploiement d'urgence, sous pression, ce qui aggrave généralement la situation.
Les tests avant d'ouvrir le trafic
Cinq vérifications, dans cet ordre :
- Le modèle se charge dans l'environnement cible, avec les versions exactes de production.
- Sur un jeu de référence figé, il produit exactement les mêmes prédictions qu'à l'entraînement. Une divergence ici signale une différence d'environnement ou de préparation des données — le problème le plus courant et le plus coûteux à découvrir plus tard.
- Il résiste aux entrées dégradées : valeurs manquantes, valeurs aberrantes, types inattendus, champs absents. Il doit échouer proprement, pas produire une prédiction absurde.
- Sa latence sous charge respecte l'exigence au 95e centile, pas en moyenne.
- Le retour arrière a été testé. Pas documenté : testé.
Le point 2 mérite d'être souligné : c'est le test qui attrape la divergence entraînement-service, et il est très rarement fait.
À retenir
- La question de départ est quand la prédiction doit exister, ce qui détermine le mode de déploiement.
- Le traitement par lots est plus souvent suffisant qu'on ne le croit, et infiniment plus simple à exploiter.
- Le service en ligne impose disponibilité, latence au centile haut, récupération rapide des variables et dégradation gracieuse.
- L'embarqué apporte hors ligne et confidentialité, au prix d'un modèle compact et de versions multiples en circulation.
- Déployez d'abord en ombre : cela détecte l'essentiel des surprises sans aucun risque.
- Puis canari avec des critères d'arrêt définis d'avance, test A/B sur la métrique métier, et un drapeau de désactivation immédiate.
- Testez que le modèle produit les mêmes prédictions sur un jeu de référence : c'est le test qui attrape la divergence entraînement-service.
Leçon suivante — La surveillance : dérive, indicateurs, alertes →