MLOps : industrialiser le cycle de vie du Machine Learning

Le MLOps (Machine Learning Operations) désigne l'ensemble des pratiques qui industrialisent le cycle de vie d'un modèle de machine learning : de l'entraînement jusqu'au déploiement et à la surveillance en production. Inspiré du DevOps, il ajoute une contrainte majeure : gérer non seulement le code, mais aussi les données et les modèles, qui évoluent dans le temps.

Cette page ouvre la formation MLOps, de niveau intermédiaire. Elle définit le MLOps, le distingue du DevOps, décrit le cycle de vie d'un modèle, les niveaux de maturité, les bonnes pratiques, les outils et la gestion du drift, puis dit précisément ce qui est publié et ce qui manque encore. Public : à l'aise avec le machine learning et le déploiement.

Ce que vous allez apprendre

• Définir le MLOps et ce qu'il ajoute au DevOps.
• Suivre le cycle de vie d'un modèle en production.
• Situer votre organisation sur l'échelle de maturité.
• Connaître les bonnes pratiques (versioning, tests, CI/CD).
• Définir le drift comme un changement des données, et savoir pourquoi on surveille un modèle.
• Repérer ce que la formation couvre déjà, et ce qui arrive.

À qui s'adresse cette formation, et que faut-il savoir avant ?

La formation MLOps s'adresse à ceux qui savent entraîner un modèle et veulent le faire vivre en production, sans le refaire à la main à chaque changement : ingénieurs DevOps ou plateforme qui accueillent des modèles, data scientists qui veulent livrer proprement. Elle ne réexplique pas le machine learning.

Le prérequis est la formation Machine learning : les fondamentaux, dont l'accueil présente le parcours : familles d'apprentissage, poste reproductible avec conda et Jupyter, régression et clustering avec scikit-learn. Il faut aussi lire du Python et connaître les notions de conteneur et de pipeline CI/CD. Pour le module Livrer (Kubeflow), ajoutez les objets de base de Kubernetes (pods, jobs, namespaces). Les deux formations partagent la racine /docs/mlops/ mais gardent chacune leur plan de cours : celle-ci commence là où l'autre s'arrête, au moment où un modèle entraîné doit devenir un service.

Que couvre la formation, et où en est-elle ?

La formation s'organise en trois modules : Reproduire, Livrer, Exploiter. Reproduire rend chaque entraînement traçable et rejouable ; Livrer empaquette un modèle et le met en service ; Exploiter le surveille, détecte sa dérive et sait revenir en arrière. Le plan complet, avec le suivi de votre progression, est dans Mon parcours.

La formation est en cours d'écriture, et l'état publié se dit tel qu'il est. Le module Reproduire est le plus avancé : il enchaîne six leçons, un projet reproductible (graine fixée, environnement verrouillé, Git), le versionnement des données avec DVC sur un stockage S3, le pipeline DVC qui rejoue un entraînement à l'identique, le suivi d'expériences sur un serveur MLflow, le registre de modèles (versions et alias) et les tests du modèle qui refusent un modèle moins bon. Chacune a son lab à rejouer sur votre poste ; l'épreuve de fin de niveau clôt le module.

Les modules Livrer et Exploiter n'ont pour l'instant qu'une leçon chacun : Kubeflow, présenté en concept (la plateforme est décrite, pas déployée), et le monitoring des modèles (drift, étiquettes retardées, rollback). L'empaquetage et le déploiement d'un modèle sur Kubernetes ne sont pas encore publiés, pas plus que leurs épreuves de fin de niveau, les deux seules à venir. Chaque leçon se valide par un quiz, et par un lab quand elle en porte un.

Qu'est-ce que le MLOps ?

Le MLOps transforme un modèle entraîné dans un notebook en un service fiable, surveillé et traçable. Sans lui, un modèle prometteur reste un prototype : impossible de le redéployer proprement, de savoir comment il a été produit, ni de détecter quand il se dégrade.

L'objectif est de permettre aux équipes data science, DevOps et produit de collaborer pour livrer des modèles robustes et maintenables.

MLOps et DevOps : les différences

Le MLOps s'inspire du DevOps mais s'en distingue sur des points clés, car un modèle n'est pas qu'un logiciel :

Aspect	DevOps	MLOps
Artefacts	Code source	Code + données + modèles
Tests	Unitaires, intégration	+ validation statistique du modèle
Déploiement	CI/CD	CI/CD + surveillance des performances
Monitoring	Logs, erreurs, uptime	+ drift de données, précision, biais
Reproductibilité	Builds identiques	+ versions des jeux de données

Glissez pour voir

En MLOps, un artefact complet, c'est code + données + configuration + poids du modèle. Sans cette traçabilité, impossible d'expliquer un résultat ou de corriger un incident.

Le cycle de vie d'un pipeline MLOps

Un pipeline MLOps enchaîne des étapes automatisées qui transforment des données brutes en modèle déployé et surveillé. Le schéma ci-dessous se lit de gauche à droite en quatre blocs (collecte, préparation, modèle, production), puis revient en arrière : quand le monitoring signale une dérive et qu'une investigation la juge nuisible, le réentraînement repart des features (les variables d'entrée du modèle).

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

1. Collecte et ingestion : rassembler et centraliser les données, avec contrôles qualité et versioning des jeux de données.

2. Nettoyage et feature engineering : préparer les données via des pipelines réutilisables, à l'entraînement comme en production.

3. Entraînement et évaluation : entraîner les modèles et suivre les expériences avec MLflow.

4. Packaging et déploiement : empaqueter le modèle (souvent en conteneur) et le déployer en API, en batch ou en edge.

5. Monitoring et drift : surveiller latence, précision et dérive des données en continu.

6. Réentraînement : relancer un pipeline quand une dégradation est confirmée, avec traçabilité via un registre de modèles (le catalogue versionné des modèles produits).

Les niveaux de maturité MLOps

Le MLOps est un chemin de progression. Google Cloud le décrit en trois niveaux de maturité (0, 1 et 2) dans MLOps: Continuous delivery and automation pipelines in machine learning, reformulés ici et à ne pas confondre avec les trois modules de la formation :

• Niveau 0, processus manuel : toutes les étapes, de l'analyse des données à la validation du modèle, sont exécutées à la main. Les data scientists transmettent le modèle entraîné aux ingénieurs, qui le déploient.
• Niveau 1, automatisation du pipeline ML : le pipeline d'entraînement est automatisé pour réentraîner le modèle en continu sur des données récentes, avec validation automatique des données et du modèle. C'est le pipeline entier qui est déployé, et non plus le seul modèle.
• Niveau 2, automatisation du pipeline CI/CD : un système d'intégration et de livraison continues construit, teste et déploie rapidement les nouvelles versions des composants du pipeline.

L'objectif n'est pas d'atteindre le niveau 2 d'emblée, mais de progresser en supprimant le travail manuel étape par étape.

Les bonnes pratiques clés

Un pipeline MLOps solide ne se résume pas à empiler des outils. Quatre fondations comptent plus que le reste :

• Versioning des données, des modèles et des expériences, pour reproduire et comparer.
• Infrastructure as Code (Terraform, Ansible) pour des environnements reproductibles.
• Tests du modèle : comportement, robustesse, impact métier, au-delà du simple « ça tourne ».
• CI/CD et Continuous Training (réentraîner et revalider le modèle de façon automatisée) : automatiser entraînement, validation, déploiement et réentraînement.

Commencer simple

N'adoptez pas dix outils d'un coup. Un socle MLflow + versioning couvre déjà l'essentiel. On ajoute de la complexité seulement quand le besoin est réel, pour éviter la dette opérationnelle prématurée.

Les outils du MLOps

Le paysage est vaste. L'idée est de construire une chaîne cohérente, adaptée à votre maturité, plutôt que d'accumuler des briques :

Besoin	Outils courants
Suivi des expériences	MLflow, Weights & Biases
Orchestration de pipelines	Kubeflow, Flyte, ZenML
Déploiement de modèles	BentoML, Seldon, FastAPI
Monitoring et drift	Evidently AI, Prometheus + Grafana
Versioning données/modèles	DVC, LakeFS

Glissez pour voir

Surveillance et drift

Une fois déployé, un modèle doit être surveillé, car le monde qu'il décrit évolue. On appelle drift ce changement : la distribution des données, ou leur relation au phénomène étudié, n'est plus celle de l'entraînement. Il fait courir le risque que le modèle devienne silencieusement moins pertinent, mais ce risque est à vérifier, le drift ne le prouve pas. On distingue le data drift (la distribution des entrées change) du concept drift (la relation entre entrées et cible change). La surveillance ML détecte ces dérives et lève une alerte. Elle ne suffit pas à décider : un drift n'implique pas toujours une baisse de qualité, et un réentraînement lancé automatiquement sur un simple seuil est un piège que la leçon sur le monitoring explique, mesures à l'appui.

À retenir

1. Le MLOps industrialise le cycle de vie ML, du prototype au service surveillé.
2. Il étend le DevOps aux données et aux modèles, pas seulement au code.
3. Le cycle enchaîne données, entraînement, déploiement, monitoring, réentraînement.
4. Progressez par maturité : supprimez le travail manuel étape par étape.
5. Surveillez le drift : déployer n'est pas la fin, c'est le début de la vie en production.

FAQ : questions fréquentes

Le MLOps, c'est quoi ?

Quelle différence entre MLOps et DevOps ?

Qu'est-ce que le drift en MLOps ?

Par quel outil MLOps commencer ?

×

📖 Voir la documentation →