Vous voyez beaucoup de notebooks Jupyter. Peu deviennent production fiable. Les data scientists adorent les modèles. Les ops adorent les système stables. Entre les deux? Un fossé abyssal.
Développer un modèle ML, c'est 20% du travail. Le déployer, le monitorer, le maintenir, le retraîner? Les 80% restants. Et c'est là où la plupart des équipes échouent parce qu'elles confondent data science et data engineering.
Le MLOps, c'est l'ensemble des pratiques qui transforment un modèle en production fiable et maintenable.
Trois niveaux de maturité
Google Cloud définit les niveaux clairement. Niveau 0 : manuel complet. Data scientist entraîne en notebook, déploie manuellement, pas de monitoring, pas de CI/CD. C'est le niveau de beaucoup trop d'équipes et c'est un risque majeur.
Niveau 1 : pipeline automatisé. Pipeline d'entraînement déclenché automatiquement, déploiement semi-automatisé avec validation, monitoring basique. Minimum requis pour le core product.
Niveau 2 : CI/CD/CT complet. Intégration continue des données et du code, déploiement continu avec rollback automatique, retraînement continu déclenché par détection de drift, monitoring avancé avec alertes proactives.
L'objectif : Niveau 2 pour chaque modèle core.
La stack de référence en 2026
Six composants interconnectés. Le Feature Store gère centralement les features, sharing entre modèles, versioning. Feast, Tecton. L'Experiment Tracker suit vos expériences, compare métriques, assure la reproductibilité. MLflow, Weights & Biases.
Le Pipeline Orchestrator automatise les étapes d'entraînement. Dagster, Airflow, Prefect. Le Model Registry versions les modèles, promeut staging vers production, stocke metadata. MLflow, W&B.
La plateforme de Serving déploie les modèles en API. BentoML, Seldon, TorchServe. Le Monitoring Stack détecte le drift, mesure la perf, envoie les alertes. Evidently, WhyLabs, Arize.
Ces six pièces travaillent ensemble de manière orchestrée.
Monitoring et drift: le combat quotidien
Le monitoring est le composant le plus critique et le plus négligé. Quatre types de drift à surveiller constamment.
Le data drift : les données d'entrée changent? Distribution des features, nouvelles valeurs? Vous le détectez comment?
Le concept drift : la relation entre features et cible change? Le modèle doit prédire différemment mais ne le sait pas.
Le feature drift : des colonnes deviennent indisponibles ou changent de format?
La dégradation de performance : les métriques business (pas juste techniques) régressent?
Quand un drift est détecté, le pipeline de retraînement se déclenche automatiquement ou envoie une alerte pour investigation. Le monitoring c'est la différence entre un système qui se maintient et un qui dérive.
CI/CD/CT: l'équivalent DevOps pour ML
L'intégration continue : chaque modification du code d'entraînement, du pipeline features ou des tests déclenche une validation automatique. Le déploiement continu : le modèle validé se déploie automatiquement en staging, puis en prod après A/B test. Le retraînement continu : le modèle se réentraîne automatiquement quand le monitoring détecte du drift ou selon un calendrier.
Ce triptyque CI/CD/CT, c'est les pratiques DevOps appliquées aux spécificités du ML - données, reproductibilité, évaluation. C'est l'industrialisation, pas l'artisanat.
Roadmap réaliste: 12 mois
Phase 1 (mois 1-2) : experiment tracking MLflow ou W&B et model registry pour tous les projets. Investissement minimal, impact immédiat sur la reproductibilité.
Phase 2 (mois 3-5) : pipeline d'entraînement automatisé pour les modèles core avec Dagster ou Airflow.
Phase 3 (mois 6-8) : monitoring en production avec Evidently ou WhyLabs. Dashboards de drift, alertes, métriques business.
Phase 4 (mois 9-12) : CI/CD/CT complet avec retraînement automatisé et A/B testing.
Budget : 2-3 ML Engineers à temps plein pour construire et maintenir. C'est un investissement structurant qui se rentabilise au premier modèle core en production.
MLOps et LLMOps convergent en 2026
Les pratiques MLOps et LLMOps convergent maintenant. Les LLM en production nécessitent les mêmes fondamentaux : versioning des prompts, pipeline d'évaluation automatisé, monitoring de la qualité, retraînement/ré-optimisation continu.
Les outils évoluent : LangSmith pour l'observabilité LLM, Braintrust pour l'évaluation, W&B pour le tracking unifié ML+LLM. L'équipe MLOps de 2026 gère à la fois les modèles ML classiques et les systèmes LLM, avec plateforme d'industrialisation commune.
L'essence du sujet
Le MLOps c'est pas un projet IT. C'est l'industrialisation de la valeur données. Un modèle qui fonctionne en démo et un modèle en production fiable, c'est deux univers différents. MLOps c'est le pont entre les deux.
Les meilleures équipes en 2026 ne parlent plus de « data science » et « data engineering » en silos. Elles parlent d'une chaîne d'approvisionnement complète, orchestrée, monitorée. De l'idée à la valeur produite.
C'est ça, produire en production.