MLOps : définition, cycle de vie et outils (2026)

Le MLOps est l'ensemble des pratiques qui permettent de déployer un modèle de machine learning en production, puis de le maintenir fiable dans la durée. Il étend le DevOps à deux objets que le logiciel classique ignore : les données et le modèle. Sa raison d'être tient en un constat : un modèle se dégrade tout seul, parce que le monde qu'il a appris change.

En bref : MLOps, définition en 30 secondes

Le MLOps est l’ensemble des pratiques qui permettent de mettre un modèle de machine learning en production, puis de l’y maintenir fiable. Le terme contracte machine learning et operations, sur le modèle de DevOps.

La différence avec le DevOps tient à ce qui est suivi. Le DevOps versionne du code. Le MLOps versionne du code, des données et un modèle entraîné.

Cette différence en produit une autre, plus importante. Un logiciel dont personne ne touche le code continue de fonctionner. Un modèle dont personne ne touche le code se dégrade quand même, parce que le monde qu’il a appris change. C’est la raison d’être du MLOps.

L’enjeu est bien documenté : la difficulté d’un projet d’IA se situe rarement dans l’entraînement du modèle. Elle se situe dans les mois qui suivent sa mise en service.

Qu’est-ce que le MLOps

Un modèle de machine learning en production n’est pas un livrable, c’est un service. Il consomme des données en continu, produit des décisions, et sa qualité varie sans qu’aucune ligne de code ne change.

Le MLOps répond à quatre questions que le développement logiciel classique n’a pas à se poser.

Quelle version tourne ? Un modèle est le produit d’un code, d’un jeu de données, d’hyperparamètres et souvent d’une graine aléatoire. Sans les quatre, l’entraînement n’est pas reproductible. Savoir quel artefact sert les prédictions du jour est la base de tout le reste.

Est-il encore bon ? Un modèle validé à 92 % de précision ne le reste pas nécessairement. La surveillance de la performance en production est une fonction permanente, pas une étape de recette.

Peut-on le remplacer sans casse ? Le déploiement d’une nouvelle version demande de la comparer à celle en service sur du trafic réel, et de pouvoir revenir en arrière rapidement.

Peut-on expliquer une décision passée ? Rejouer une prédiction émise il y a six mois suppose de retrouver le modèle, les données d’entrée et le contexte. C’est une exigence de confiance, et de plus en plus une exigence réglementaire.

MLOps et DevOps : les trois différences qui comptent

	DevOps	MLOps
Objet versionné	Code	Code, données, modèle
Déploiement	Déterministe	Produit un modèle à valider avant service
Dégradation	Nécessite un changement	Survient sans changement, par dérive
Test	Assertions vrai ou faux	Métriques statistiques, seuils
Retour arrière	Redéployer le commit précédent	Redéployer le modèle précédent, données comprises
Surveillance	Erreurs, latence, disponibilité	Idem, plus la dérive et la qualité des prédictions

Le point le plus contre-intuitif pour une équipe venue du logiciel est la ligne « dégradation ». En développement classique, un service stable le reste tant que son environnement ne bouge pas. En machine learning, l’environnement est la donnée, et la donnée bouge toujours.

Le cycle de vie MLOps

Une chaîne MLOps mature comporte sept étapes, organisées en boucle plutôt qu’en ligne droite.

        ┌──────────────────────────────────────────────┐
        │                                              │
        ▼                                              │
  [1. Données] ── collecte, nettoyage, versionnage     │
        │         (DVC, LakeFS)                        │
        ▼                                              │
  [2. Features] ── transformation, feature store       │
        │                                              │
        ▼                                              │
  [3. Entraînement] ── expériences tracées             │
        │              (MLflow, W&B)                   │
        ▼                                              │
  [4. Évaluation] ── métriques, biais, seuils          │
        │            décision go / no-go               │
        ▼                                              │
  [5. Registre] ── artefact versionné + métadonnées    │
        │                                              │
        ▼                                              │
  [6. Déploiement] ── shadow, canari, A/B              │
        │             (BentoML, KServe, vLLM)          │
        ▼                                              │
  [7. Surveillance] ── dérive, performance, coût       │
        │              (Evidently, WhyLabs)            │
        │                                              │
        └──── réentraînement déclenché ────────────────┘

1. Données. Le versionnage des jeux de données est la fondation. Sans lui, un entraînement n’est pas reproductible, et une régression de performance devient impossible à diagnostiquer.

2. Features. La transformation des données brutes en variables exploitables. Le piège classique est le décalage entre la transformation d’entraînement et celle de production, qui produit des prédictions correctes en test et fausses en service. Un feature store résout ce décalage en partageant le même code des deux côtés.

3. Entraînement. Chaque expérience est tracée : paramètres, jeu de données, métriques, artefact produit. Une équipe qui compare ses résultats par capture d’écran a déjà perdu la reproductibilité.

4. Évaluation. Au-delà de la métrique principale, l’évaluation mesure les performances par sous-population. Un modèle globalement bon peut être mauvais sur un segment, ce qui devient un problème d’équité autant que de qualité.

5. Registre de modèles. L’artefact validé est enregistré avec ses métadonnées et son stade : développement, pré-production, production, archivé. Le registre est la source de vérité pour répondre à « quelle version tourne ».

6. Déploiement progressif. Le déploiement en ombre fait tourner le nouveau modèle sur du trafic réel sans que ses sorties soient servies. Le déploiement canari lui confie un faible pourcentage du trafic. Les deux permettent de mesurer avant d’engager.

7. Surveillance. Trois familles d’indicateurs : la santé technique du service, la dérive des données d’entrée, et la performance métier lorsque la vérité terrain devient disponible. C’est la surveillance qui déclenche le retour à l’étape 1.

Les trois niveaux de maturité MLOps

Toutes les organisations n’ont pas besoin du niveau maximal. Situer le sien évite d’investir à côté.

Niveau 0 — artisanal. L’entraînement se fait dans un carnet de notes, le déploiement à la main. Acceptable pour un modèle unique, peu critique, réentraîné rarement. Le coût caché apparaît au premier départ de la personne qui l’a construit.

Niveau 1 — pipeline d’entraînement automatisé. L’entraînement est orchestré et reproductible, le registre de modèles existe, la surveillance de base est en place. C’est le niveau qui convient à la grande majorité des entreprises, et celui que nous visons par défaut dans nos projets.

Niveau 2 — chaîne complète automatisée. La détection de dérive déclenche un réentraînement, l’évaluation valide ou rejette automatiquement, le déploiement progressif s’enchaîne. Ce niveau se justifie quand les modèles sont nombreux ou que la dérive est rapide, par exemple en détection de fraude.

Passer du niveau 0 au niveau 1 apporte l’essentiel du bénéfice. Le saut au niveau 2 coûte cher et ne se rentabilise que sur des volumes ou une criticité qui le justifient.

Le drift : le problème qui n’existe pas en DevOps

C’est le concept central du MLOps, et celui qui surprend le plus les équipes.

Le data drift désigne un décalage de la distribution des données d’entrée par rapport à celles de l’entraînement. Un modèle entraîné sur une clientèle française voit ses entrées changer quand l’entreprise ouvre au Canada.

Le concept drift est plus insidieux. La relation entre les entrées et la cible change : le monde a bougé, la règle apprise n’est plus la bonne. Un changement réglementaire, un nouveau concurrent ou une crise suffisent à le provoquer. Les données peuvent sembler normales pendant que les prédictions deviennent fausses.

La détection repose sur des tests statistiques comparant les distributions, et sur le suivi de la performance quand la vérité terrain arrive. La difficulté pratique est le délai : dans un modèle de risque de crédit, le résultat réel n’est connu que des mois plus tard. Il faut alors surveiller des indicateurs indirects.

Nous avons rencontré ce sujet sur le cas ADEME, où l’analyse automatisée des demandes d’aides doit rester juste alors que les dispositifs d’aide évoluent. Un modèle figé aurait vieilli en même temps que les dispositifs qu’il analyse.

Les outils MLOps en 2026

Le paysage s’est stabilisé. Voici les briques courantes, avec une préférence pour ce qui est auto-hébergeable.

Fonction	Outils	Souverain
Suivi d’expériences, registre	MLflow, Weights and Biases	MLflow, auto-hébergeable
Versionnage des données	DVC, LakeFS	Les deux
Orchestration	Airflow, Dagster, Prefect	Les trois
Feature store	Feast, Hopsworks	Les deux
Service de modèles	BentoML, KServe, vLLM	Les trois
Surveillance et dérive	Evidently, WhyLabs	Evidently
Plateforme intégrée	Kubeflow, ZenML	Les deux

Pour une organisation soumise au RGPD, l’essentiel de cette chaîne est open source et déployable sur une infrastructure européenne. Une pile MLflow, DVC, Airflow et BentoML sur un cloud souverain ne fait aucun compromis fonctionnel par rapport à une plateforme gérée hors Union européenne.

Le conseil pratique : commencer par le suivi d’expériences et le registre de modèles. Ce sont les deux briques qui apportent le plus tôt de la valeur, et elles ne demandent pas de refonte d’infrastructure.

LLMOps : ce qui change avec les grands modèles de langage

L’arrivée des LLM a déplacé une partie des problèmes sans supprimer les anciens. Trois différences structurantes.

L’objet versionné change de nature. Sur un système de RAG, le modèle est souvent un service tiers que vous ne réentraînez pas. Ce que vous versionnez, ce sont les prompts, le corpus indexé, la stratégie de découpage et les paramètres de récupération. Un changement de prompt modifie le comportement autant qu’un réentraînement.

L’évaluation devient composite. Il n’existe pas de métrique unique équivalente à la précision. L’évaluation combine des jeux de tests de référence, des jurys automatiques où un modèle note les sorties d’un autre, et des retours humains. Constituer ce jeu de tests est le travail le plus rentable d’un projet LLM.

Le coût devient un indicateur de production. Une dépense au token fait de la latence et du coût par requête des métriques à surveiller au même titre que la qualité. Un changement de prompt qui améliore la réponse et double la facture est un arbitrage, pas une amélioration.

Ce qui ne change pas : la traçabilité, la capacité de retour arrière et la surveillance de la dérive. Un corpus indexé vieillit exactement comme un jeu d’entraînement.

MLOps, RGPD et IA Act

Aucun texte n’impose le MLOps. Plusieurs obligations le supposent en pratique.

L’IA Act exige, pour les systèmes à haut risque, une journalisation des événements, une documentation technique du système, une gouvernance des données d’entraînement et une supervision humaine effective. Ces exigences sont désormais attendues au 2 décembre 2027, après le report acté par le digital omnibus. Elles décrivent, en langage réglementaire, ce qu’une chaîne MLOps produit naturellement.

Côté RGPD, l’article 22 encadre les décisions exclusivement automatisées et suppose de pouvoir expliquer la logique appliquée. Rejouer une prédiction passée demande d’avoir conservé le modèle et les entrées. C’est une fonction MLOps avant d’être une fonction juridique. Notre guide IA et RGPD détaille ce croisement, et l’IA explicable en couvre le versant méthodes.

Ce que nous refusons de promettre

« Il faut une plateforme MLOps complète avant de démarrer. » Faux, et coûteux. Une équipe qui met en place Kubeflow avant d’avoir un modèle en service construit une infrastructure sans usage. Le suivi d’expériences et le registre suffisent à démarrer.

« Le réentraînement automatique règle la dérive. » Dangereux tel quel. Un réentraînement déclenché sans validation propage une dégradation de données dans le modèle. La boucle automatique doit toujours passer par une évaluation qui peut refuser la nouvelle version.

« Un modèle à 95 % de précision est prêt pour la production. » La précision globale ne dit rien de la performance par sous-population, ni de la stabilité dans le temps, ni du comportement sur les cas rares. Ce sont ces trois dimensions qui décident si un modèle tient en service.

C’est le cœur de ce que nous faisons comme agence Data et IA : concevoir des systèmes qui restent justes après la mise en service, pas seulement le jour de la recette. Quand une mission inclut du machine learning, nous livrons la chaîne complète, versionnage des données compris, registre de modèles, déploiement progressif et surveillance de la dérive.

FAQ

Qu’est-ce que le MLOps (définition simple) ?

Le MLOps regroupe les pratiques, les outils et l’organisation qui permettent de mettre un modèle de machine learning en production et de l’y maintenir fiable. Le terme vient de la contraction de machine learning et operations, sur le modèle de DevOps. La différence tient à ce qui est versionné et surveillé : en DevOps, du code ; en MLOps, du code, des données et un modèle entraîné, dont les comportements évoluent indépendamment.

Quelle est la différence entre MLOps et DevOps ?

Le DevOps automatise le cycle de vie du code. Le MLOps automatise le cycle de vie du code, des données et du modèle. Trois différences pratiques en découlent. Un déploiement DevOps est déterministe, un déploiement MLOps produit un modèle dont la qualité doit être mesurée avant mise en service. Un logiciel ne se dégrade pas sans changement de code, un modèle se dégrade avec la dérive des données. Enfin, reproduire un build DevOps demande le commit, reproduire un entraînement demande aussi le jeu de données et la graine aléatoire.

Qu’est-ce que le drift d’un modèle ?

Le drift est la dégradation progressive des performances d’un modèle dont le code n’a pas changé. Deux formes principales. Le data drift désigne un décalage de la distribution des données d’entrée par rapport à celles de l’entraînement. Le concept drift désigne un changement de la relation entre les entrées et la cible : le monde a changé, la règle apprise n’est plus la bonne. Un modèle de scoring entraîné avant un changement réglementaire en est l’exemple type.

Quels sont les outils MLOps en 2026 ?

Le socle courant combine MLflow ou Weights and Biases pour le suivi d’expériences et le registre de modèles, DVC ou LakeFS pour le versionnage des données, Airflow, Dagster ou Prefect pour l’orchestration, BentoML, KServe ou vLLM pour le service, et Evidently ou WhyLabs pour la détection de dérive. Kubeflow et ZenML proposent des plateformes intégrées. Pour un déploiement souverain, la majorité de ces briques sont open source et auto-hébergeables.

Qu’est-ce que le LLMOps et en quoi diffère-t-il du MLOps ?

Le LLMOps applique la démarche MLOps aux grands modèles de langage. Trois différences comptent. L’objet versionné n’est plus seulement un modèle entraîné mais aussi des prompts, un corpus indexé et une configuration de récupération. L’évaluation ne se réduit pas à une métrique unique, elle combine jeux de tests, jurys automatiques et retours humains. Enfin le coût se pilote au token, ce qui déplace la surveillance vers la latence et la dépense par requête.

À partir de quand faut-il investir dans le MLOps ?

Dès qu’un modèle sort du carnet de notes pour servir une décision réelle, même à petite échelle. Le seuil n’est pas le volume mais la conséquence : si une prédiction erronée a un effet sur un client, un dossier ou un budget, il faut au minimum savoir quel modèle a produit quelle sortie, et sur quelles données. Cette traçabilité minimale coûte peu au démarrage et devient très coûteuse à reconstituer après coup.

Le MLOps est-il obligatoire pour la conformité RGPD ou IA Act ?

Aucun texte n’impose le MLOps en tant que tel. En revanche, les obligations de journalisation, de traçabilité et de supervision humaine prévues par l’IA Act pour les systèmes à haut risque supposent en pratique un dispositif de ce type. Savoir quel modèle a produit quelle décision, sur quelles données, et pouvoir le rejouer, c’est très exactement ce que fournit une chaîne MLOps correctement outillée.