Leçon 6 — Récapitulatif et FAQ
Les cinq leçons en une page
Leçon 1 — pourquoi ça échoue. Presque jamais pour des raisons de précision. Un problème mal défini, des données de production différentes, aucun propriétaire après la livraison, une intégration impossible, aucune mesure de valeur, et une dette technique qui s'accumule. Le modèle est une petite fraction du système.
Leçon 2 — la reproductibilité. Quatre éléments à figer : données, code, environnement, paramètres. Le versionnement des données est le trou le plus fréquent. Un notebook n'entraîne pas un modèle de production, et la préparation des données doit être une seule implémentation partagée.
Leçon 3 — le déploiement. La question est « quand la prédiction doit-elle exister ». Le traitement par lots suffit plus souvent qu'on ne le croit. Déployez en ombre, puis en canari avec des critères d'arrêt définis d'avance, mesurez en A/B sur la métrique métier, et gardez un interrupteur.
Leçon 4 — la surveillance. Un modèle qui se dégrade n'alerte pas. La dérive des données se détecte sans étiquettes, la dérive du concept non. Surveillez entrées et sorties, gardez un échantillon annoté chaque semaine, et n'ayez que des alertes assorties d'une action.
Leçon 5 — l'organisation. Cinq compétences à couvrir, un propriétaire nommé, un niveau de maturité adapté à vos problèmes réels, une fiche de modèle avec la section « ce qu'il ne faut pas en faire », et le courage de retirer ce qui ne sert plus.
Glossaire
| Terme | Ce que cela veut dire |
|---|---|
| MLOps | les pratiques qui font vivre un modèle en production |
| Pipeline | l'enchaînement automatisé des étapes de préparation et d'entraînement |
| Versionnement des données | la capacité à retrouver exactement le jeu utilisé |
| Suivi d'expériences | l'enregistrement automatique de chaque exécution et de ses résultats |
| Registre de modèles | le catalogue des versions et de leur stade de déploiement |
| Magasin de variables | le service qui calcule et sert les variables, identiquement partout |
| Divergence entraînement-service | l'écart entre la préparation des données à l'entraînement et en production |
| Fuite de données | une information indisponible au moment réel de la prédiction |
| Traitement par lots | des prédictions calculées périodiquement et stockées |
| Service en ligne | des prédictions calculées à la demande |
| Déploiement en ombre | le nouveau modèle reçoit le trafic sans que ses sorties soient utilisées |
| Déploiement canari | une fraction croissante du trafic envoyée au nouveau modèle |
| Test A/B | deux modèles comparés sur la métrique métier |
| Drapeau de fonctionnalité | un interrupteur permettant de désactiver sans redéployer |
| Dérive des données | la distribution des entrées s'écarte de la référence |
| Dérive du concept | la relation entre entrées et sortie a changé |
| PSI | l'indice de stabilité de population, mesure d'écart de distribution |
| Vérité terrain | la vraie réponse, souvent connue avec retard |
| Jeu de référence figé | un jeu de test invariant, repassé à chaque changement |
| Fiche de modèle | la documentation d'un page décrivant usage, limites et responsable |
| Quantification | la réduction de précision des poids pour alléger le modèle |
| Boucle de rétroaction | le modèle influence les données qu'il recevra ensuite |
Les 12 questions que les gens posent vraiment
1. Quels outils faut-il apprendre ?
Le socle utile partout : Git, Docker, une chaîne d'intégration continue, et MLflow pour le suivi d'expériences et le registre. Ensuite selon le contexte : un orchestrateur pour les pipelines — Airflow, Prefect, Dagster —, un outil de versionnement de données comme DVC, et la plateforme cloud de votre organisation. Apprenez Git et Docker en priorité : ils servent quoi qu'il arrive.
2. Faut-il une plateforme MLOps complète ?
Pas au début. Un dépôt propre, un suivi d'expériences, une image conteneurisée, un jeu de test figé et un tableau de bord couvrent l'essentiel du risque. Les plateformes se justifient à partir de plusieurs modèles en production et de réentraînements réguliers. Installer l'outillage avant d'avoir le problème est le gaspillage le plus fréquent du domaine.
3. Combien de temps pour passer du modèle à la production ?
Cas simple, données propres, intégration légère : deux à six semaines. Cas réel avec contraintes de sécurité, données à préparer et intégration dans l'existant : trois à neuf mois. Le modèle représente rarement plus de 20 % de cet effort, ce qui surprend systématiquement les équipes.
4. Comment savoir si mon modèle se dégrade sans attendre la vérité terrain ?
Trois signaux disponibles immédiatement : la distribution des entrées comparée à la référence, la distribution des prédictions, et la distribution des scores de confiance. Le dernier est le meilleur signal précoce : un déplacement vers des scores plus bas indique que le modèle rencontre des cas qu'il connaît mal, et cela précède généralement la baisse de performance.
5. À quelle fréquence réentraîner ?
Cela dépend entièrement de la vitesse de dérive de votre domaine. Détection de fraude : hebdomadaire, car les fraudeurs s'adaptent. Recommandation : mensuelle. Score de risque crédit : trimestrielle ou semestrielle. Vision industrielle sur un procédé stable : annuelle ou sur événement. La bonne réponse vient de vos indicateurs, pas d'une règle générale.
6. Le réentraînement automatique, bonne ou mauvaise idée ?
Bonne à terme, dangereuse au début. Sans tests de qualité des données qui bloquent le pipeline, un champ mal alimenté pendant une semaine devient un modèle appris sur des données fausses, déployé sans relecture. Les quatre prérequis : tests de données bloquants, validation automatique contre l'ancien modèle, déploiement en canari, retour arrière testé.
7. Qui doit être responsable en cas d'erreur du modèle ?
Une personne identifiée, côté métier, qui assume la décision prise à partir de la prédiction. Le modèle n'est pas responsable : c'est un outil. Dans un cadre réglementé, cette responsabilité est explicitement exigée, et le cours sur l'éthique détaille les obligations.
8. Comment gérer plusieurs modèles en production ?
Un inventaire avec, pour chaque modèle : son propriétaire, sa date de dernier entraînement, sa métrique métier, son statut. Cela paraît trivial et fait défaut presque partout. À partir de cinq modèles, un registre et un tableau de bord unifié deviennent nécessaires. Et prévoyez une revue annuelle pour retirer ce qui ne sert plus.
9. Le MLOps s'applique-t-il aux LLM ?
Les principes tiennent : reproductibilité, versionnement des consignes comme du code, évaluation sur un jeu figé, surveillance, retour arrière. Trois spécificités s'ajoutent : la version du modèle du fournisseur peut changer sous vos pieds, donc épinglez-la ; le coût par requête devient un indicateur de premier plan ; et l'évaluation est plus difficile faute de réponse unique. Voir la leçon sur la production du cours LLM.
10. Faut-il un data scientist ou un ingénieur logiciel ?
La plupart des équipes ont trop du premier et pas assez du second. Le goulot d'étranglement d'un projet réel est presque toujours l'ingénierie des données et l'intégration, pas la modélisation. Un bon ingénieur logiciel qui apprend le machine learning est souvent plus utile en production qu'un spécialiste des modèles qui n'a jamais déployé.
11. Comment convaincre la direction d'investir dans le MLOps ?
Pas avec des arguments techniques. Avec le coût des incidents : le temps passé à déboguer un modèle non reproductible, la valeur perdue pendant les mois de dégradation non détectée, le coût de reconstruire un modèle dont l'auteur est parti. Un exemple chiffré de votre propre historique vaut mieux que toute présentation.
12. Où aller après ce cours ?
IA dans le cloud pour l'infrastructure et la maîtrise des coûts. Éthique de l'IA pour l'audit, la documentation et les obligations réglementaires. Grands modèles de langage pour les spécificités des systèmes génératifs.
Les cours premium couvrent MLflow, la conteneurisation, l'intégration continue pour le machine learning, la surveillance et les plateformes cloud, avec projets réels et un certificat vérifiable après un examen de 40 questions. Inclus dans toutes les formules payantes.
Dernière étape — Passez le quiz et découvrez votre attestation →