Pourquoi le MLOps ? La dette technique ML et les niveaux de maturite
Passer un notebook Jupyter a la production est l'un des defis les plus sous-estimes du machine learning. Les modèles se degradent avec le temps (drift), les dépendances évoluent, les données changent, et sans pratiques rigoureuses, maintenir un modèle en production devient rapidement un gouffre de dette technique.
Le MLOps (Machine Learning Opérations) répond a ce problème en appliquant les principes DevOps — automatisation, reproductibilite, monitoring, CI/CD — au cycle de vie ML. L'objectif : déployer des modèles rapidement, de façon fiable, et les maintenir performants dans la durée sans intervention manuelle constante.
Niveaux de maturite MLOps : de 0 a 2
Google Cloud a formalise trois niveaux de maturite MLOps. Niveau 0 — Manuel : les Data Scientists travaillent dans des notebooks Jupyter, le déploiement est un processus ad hoc (upload d'un fichier .pkl, script manuel), il n'y a pas de pipeline de training automatise, pas de monitoring, et les modèles en production ne sont pas tracables. C'est l'état de la majorite des projets ML naissants.
Niveau 1 — Automatisation des pipelines : le training est automatise dans un pipeline reproductible (Kubeflow, Vertex AI Pipelines, Prefect), le Continuous Training (CT) retraine automatiquement le modèle sur nouvelles données selon un schedule ou un trigger de drift. Le modèle deploye est tracable (model registry). Niveau 2 — CI/CD complet : en plus du CT, le pipeline de training lui-même est versionne et teste en CI. Chaque modification du code de feature engineering ou du modèle declenche un pipeline de validation complet avant de promouvoir une nouvelle version en production. C'est l'état cible pour les systèmes ML critiques.
L'article fondateur 'Hidden Technical Debt in Machine Learning Systems' (Sculley et al., Google, NeurIPS 2015) a montre que le code ML lui-même ne représente qu'une petite fraction du système : configuration, collecte de données, vérification des features, infrastructure de serving, monitoring — tout cela constitue la majorite de la complexité réelle. Les auteurs ont identifie des antipatterns spécifiques au ML : entanglement des features, feedback loops caches, correction du monde réel (le modèle influence les données qu'il va predire).
Sculley et al. - Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015Le cycle de vie d'un modèle ML
Le cycle de vie ML comprend plusieurs phases sequentielles mais iteratives, chacune pouvant être automatisée et versionnée. La clé est que ces phases ne sont pas lineaires : les résultats d'évaluation peuvent remettre en question les choix de feature engineering, le monitoring en production peut declencher un nouveau cycle de training.
1. Preparation des données et validation
Collecte et validation des données sources (schema, distribution, completude), nettoyage et traitement des valeurs manquantes, creation des features (transformation, encodage, normalisation), split train/validation/test avec attention au data leakage, et versioning des datasets (DVC, Delta Lake, Iceberg). La validation des données est souvent négligée et pourtant critique : TFX Data Validation, Great Expectations ou Soda permettent de definir des assertions sur les données d'entraînement qui echouent automatiquement le pipeline si les données sont anormales (colonne manquante, distribution aberrante, taux de nullite trop eleve).
Le data leakage est le piege majeur de cette phase : des features créées avec des informations du futur (qui ne seraient pas disponibles au moment de l'inference) produisent des modèles artificiellement performants en évaluation mais inutilisables en production. Le feature store avec point-in-time correctness (voir section suivante) est la solution systématique.
2. Experimentation et sélection de modèles
Experimentation avec suivi : MLflow Tracking, Weights & Biases, Comet ML ou Neptune permettent de logger hyperparametres, métriques, artefacts et code pour chaque run. Sans tracking, comparer des experiences devient impossible. Hyperparameter tuning : Optuna (bayesien), Ray Tune (distribue), Keras Tuner. Sélection selon les métriques métier (pas seulement la loss) — un modèle avec 99 % de précision sur un dataset déséquilibre peut avoir un recall de 0 sur la classe minoritaire.
Les experiences doivent être reproductibles : environnement fixe (Docker ou Conda avec versions fixées), seed aleatoire fixe, dataset versionne. La reproductibilite est la condition de base pour comparer deux experiences de façon significative et pour debugger un comportement inattendu en production.
3. Évaluation rigoureuse avant déploiement
Un modèle ne se deploie pas seulement parce qu'il depasse un seuil de précision. L'évaluation pre-déploiement inclut : tests de performance par segment (equite algorithmique — le modèle se comporte-t-il différemment selon les groupes demographiques ?), évaluation sur données récentes hors de la période d'entraînement (temporal holdout), tests de robustesse (perturbations, inputs adversariaux, valeurs hors domaine).
La comparaison au modèle en production (champion/challenger) est essentielle : si le nouveau modèle n'est pas meilleur que l'existant sur les métriques métier, il ne se deploie pas. Cette gate automatique dans le pipeline CI/CD empêche les régressions silencieuses.
4. Déploiement et stratégies de serving
Stratégies de déploiement : blue/green (switch instantane, rollback immédiat si régression, zero downtime), canary (rollout progressif a 5 % → 20 % → 100 %, permet de détecter des régressions sur un trafic réel limite), shadow mode (le nouveau modèle fait des predictions en parallèle sans impact sur les utilisateurs — idéal pour comparer les sorties avant toute mise en prod), A/B testing (deux versions servent differents segments d'utilisateurs pour comparer les performances métier dans des conditions réelles).
Formats de serving : API REST (FastAPI + Docker — flexible, polyvalent), batch scoring (Spark, dbt + SQL — pour les cas ou la latence n'est pas critique), edge deployment (ONNX, TFLite, Core ML — modèles embarqués sur device). Le choix depend du SLA de latence (temps réel < 100ms vs batch nocturne), du volume de requetes et des contraintes de coût.
CI/CD pour le ML : pipelines, tests de modèles et model registry
Le CI/CD ML est different du CI/CD applicatif classique : en plus du code, il faut versionner et tester les données, les features et les modèles. Un pipeline CI/CD ML complet ajoute le Continuous Training (CT) au CI/CD classique.
Pipeline CI/CD ML typique
Trigger (push sur le repo, schedule ou nouveau batch de données détecte) → validation des données (schema, distribution, completude via Great Expectations ou TFX DV) → feature engineering reproductible → training du modèle avec seed fixe → évaluation automatique (métriques vs baseline et vs modèle champion en prod) → enregistrement dans le model registry si les gates sont validées → tests d'intégration du serving (latence p95, format de sortie, gestion des inputs edge cases) → déploiement en staging → smoke tests automatiques → promotion en production selon la stratégie choisie (canary ou blue/green).
Outils de pipeline : GitHub Actions ou GitLab CI pour les triggers et l'orchestration CI, Kubeflow Pipelines ou Vertex AI Pipelines pour les pipelines ML distribues sur Kubernetes, Prefect ou Airflow pour les workflows de données, ZenML (framework ML multi-stack agnostique). La tendance récente est aux pipelines declaratifs versionnables en code (DAG as code).
Testing ML : au-dela des métriques
Le testing ML couvre plusieurs niveaux. Tests unitaires des features : chaque fonction de transformation est testée avec des entrées connues et des sorties attendues (valeurs limites, nulls, types inattendus). Tests du preprocessing pipeline : le pipeline complet produit-il le bon schema de sortie sur un mini-dataset de référence ? Tests comportementaux du modèle (behavioral tests) : le modèle satisfait-il des invariances attendues ? (ex : changer la race dans une feature textuelle ne doit pas changer la prediction d'un modèle de credit scoring). Tests de performance : le modèle depasse-t-il le seuil minimum sur le holdout set et surpasse-t-il le modèle champion ?
Les tests comportementaux (ou metamorphic tests) sont particulièrement importants pour les modèles de NLP : des perturbations mineures sur l'input (synonym replacement, changement de casse) ne doivent pas produire des changements de prediction radicaux. La librairie Checklist (Ribeiro et al., Microsoft, ACL 2020) formalise cette approche.
Model registry : versioning et gouvernance des modèles
Un model registry est le catalogue centralise des modèles ML : il stocke les artefacts (weights, preprocessing pipeline, signature d'inputs/outputs), les métadonnées (métriques d'évaluation, dataset utilise, hyperparametres, commit git du code), les stages du cycle de vie (None → Staging → Production → Archived) et l'historique des transitions avec approbation humaine optionnelle. Sans registry, le 'modèle en prod' est souvent un fichier .pkl quelque part sur un serveur, sans traçabilite ni possibilité de rollback.
MLflow Model Registry (open-source, s'intègre avec Databricks), Vertex AI Model Registry (GCP), SageMaker Model Registry (AWS), Weights & Biases Registry et Comet ML Model Registry sont les solutions les plus repandues. Le choix suit souvent le cloud provider ou la plateforme MLOps principale. L'essentiel : chaque déploiement en production doit pointer vers une version enregistrée dans le registry, avec un audit trail complet.
Le CI/CD ML ajoute le Continuous Training (CT) : en plus de tester et déployer du code, on retraine automatiquement les modèles sur nouvelles données quand une condition est remplie (drift détecte, performance sous un seuil, nouveau batch hebdomadaire). C'est la boucle qui maintient les modèles a jour sans intervention manuelle. Le CT est distingue du CI/CD classique car il implique des ressources de calcul importantes (GPU, données volumineuses) — il ne se declenche pas a chaque commit mais selon des triggers métier ou de qualité.
Feature store : centraliser et réutiliser les features ML
Un feature store est une plateforme qui centralise la creation, le stockage, la documentation et le serving des features ML. Il resout un problème clé : éviter que chaque équipe recalcule les mêmes features différemment, avec un risque de training/serving skew (features calculées différemment a l'entraînement et a l'inference).
Architecture offline/online d'un feature store
Un feature store comprend deux parties : le offline store (base de données batch pour l'entraînement — S3 + Parquet, BigQuery, Snowflake, Delta Lake) et l'online store (base a faible latence pour l'inference en temps réel — Redis, DynamoDB, Bigtable, Cassandra). La feature pipeline synchronise les deux : elle calcule les features en batch, les materialise dans l'offline store, puis les propage vers l'online store pour le serving en temps réel.
Les outils majeurs : Feast (open-source, cloud-agnostic, s'intègre avec Redis, BigQuery, Snowflake), Tecton (managed enterprise, AWS et GCP), Vertex AI Feature Store (GCP natif, managed), SageMaker Feature Store (AWS natif), Databricks Feature Engineering (intégration native avec Delta Lake et Unity Catalog). Le choix depends de l'écosystème cloud existant et du budget.
Point-in-time correctness : éviter le data leakage
La point-in-time correctness est la garantie que, lors de la creation d'un dataset d'entraînement, chaque exemple utilise uniquement les features disponibles au moment de l'événement (et non des features calculées après). Sans cette garantie, on créé du data leakage : si l'on joint les features de profil d'un utilisateur avec leur valeur actuelle plutot que leur valeur au moment de l'achat, on 'contamine' les exemples d'entraînement avec des informations du futur.
Les feature stores implementent la point-in-time correctness via des requetes temporelles : 'donne-moi les valeurs des features pour cet utilisateur, telles qu'elles existaient a cette date et heure précise.' Sans feature store, reproduire cette garantie manuellement avec des jointures SQL temporelles est error-prone et difficile a auditer. C'est l'une des raisons principales qui justifie l'investissement dans un feature store pour les organisations avec plusieurs modèles ML en production.
Le training/serving skew survient quand les features utilisées pendant l'entraînement sont calculées différemment pendant l'inference (normalisation avec des stats differentes, encodage different, fenêtres de temps differentes). Un feature store garantit que la même logique est appliquée dans les deux contextes. Sans feature store, ce type de bug est silencieux et peut degrader les performances en production sans alerte évidente — le modèle répond, ne plante pas, mais ses predictions deviennent de moins en moins fiables.
Monitoring ML : drift de données, drift de concept et alertes
Le monitoring ML est fondamentalement different du monitoring applicatif. Une API peut être 'up' (latence OK, pas d'erreur 5xx) tout en produisant des predictions incorrectes a cause d'un changement dans les données d'entrée. Le monitoring ML surveille la qualité des predictions, pas seulement l'infrastructure.
Les trois types de drift et leurs méthodes de détection
Data drift (drift de covariables) : la distribution des inputs change par rapport a la distribution d'entraînement. Exemple : le modèle de scoring de credit a ete entraine sur des données pre-COVID ; les distributions de revenus et de comportements de paiement ont change. Détection : tests statistiques (Kolmogorov-Smirnov pour les variables continues, Chi-2 pour les catégoriques, Population Stability Index — PSI — pour les scorecards credit).
Concept drift : la relation entre inputs et output change — le monde évolue, mais les inputs restent les mêmes. Exemple : 'utiliser internet le soir' etait correle a 'jeune' en 2005, ce n'est plus le cas en 2025. Plus difficile a détecter car il nécessite des labels en production (ground truth). Performance drift : les métriques métier (précision, recall, RMSE, business KPIs comme le chiffre d'affaires incremental génère par le modèle de recommendation) se degradent. Nécessite un pipeline de labellisation en production et du temps pour accumuler suffisamment de labels.
Observabilite ML et outils de monitoring
Evidently AI (open-source, rapports HTML et dashboards Grafana, monitore la distribution des features et les métriques de performance), Arize AI (plateforme managed, SHAP explanations intégrées, analyse de segments), WhyLabs (monitoring continu avec profils de données), Fiddler (enterprise, monitoring et explainability). Les plateformes cloud ont leurs propres solutions : Vertex AI Model Monitoring (GCP), SageMaker Model Monitor (AWS, détecte data drift et model quality drift), Azure ML Data Drift. Ces outils s'integrent généralement au stack observabilite existant (Prometheus, Grafana, Datadog, PagerDuty pour les alertes).
L'observabilite ML va au-dela du drift : elle inclut le logging des predictions et des inputs en production (pour le deboggage et le retraining), le monitoring des latences de serving (p50, p95, p99), les métriques de fairness par segment, et les feedback loops (les labels réels quand ils arrivent). Conserver un log des predictions avec leurs inputs permet de reconstituer un dataset de retraining a partir des données de production réelles.
Deux stratégies. Schedule-based : retraining automatique toutes les semaines ou tous les mois — simple a implementer, mais peut retrainer inutilement (coût GPU) ou pas assez vite (si le drift est rapide). Trigger-based : le retraining se declenche quand le PSI depasse un seuil (ex : PSI > 0.2 sur une feature clé) ou quand la performance descend sous un seuil — plus precis mais nécessite un pipeline de monitoring robuste. En pratique, les équipes matures combinent les deux : un schedule minimum + des triggers pour les derives soudaines.
Quand adopter le MLOps et quand éviter la complexité
Le MLOps n'est pas adapte a tous les contextes. L'objectif est d'avoir le niveau de maturite MLOps adapte aux besoins réels — ni trop peu (dette technique, modèles qui se degradent en silence), ni trop (complexité inutile qui ralentit l'iteration).
Critères pour monter en maturite MLOps
Le passage du niveau 0 au niveau 1 se justifie quand : le modèle en production doit être retraine régulièrement (données qui changent, utilisateurs qui évoluent), plusieurs Data Scientists travaillent sur le même projet et ont besoin de comparer leurs experiences de façon systématique, les time-to-production depassent plusieurs semaines de façon recurrente, ou des incidents de 'modèle qui plante en prod' ont eu lieu et ne peuvent pas être debuggues faute de traçabilite.
Le passage au niveau 2 (CI/CD complet) se justifie pour les systèmes ML critiques : recommendations produit, scoring de credit, détection de fraude, pricing dynamique — tout modèle dont la degradation a un impact direct mesurable sur le revenu ou le risque. Pour un modèle de reporting analytique interne qui tourne une fois par semaine, le niveau 1 suffit largement.
Choisir son stack MLOps selon le contexte
Start-up / petite équipe : commencer par MLflow (tracking + model registry open-source) + GitHub Actions pour l'automatisation + Evidently AI pour le monitoring. Stack minimaliste, rapide a mettre en place, extensible. Scale-up sur GCP : Vertex AI Pipelines + Vertex AI Model Registry + Vertex AI Feature Store + Cloud Monitoring — stack intégrée, managed, sans ops. Scale-up sur AWS : SageMaker Pipelines + SageMaker Model Registry + SageMaker Feature Store + CloudWatch. Enterprise multi-cloud ou on-premise : Kubeflow Pipelines (sur Kubernetes) + MLflow + Feast + Seldon ou BentoML pour le serving — stack open-source, portable, mais nécessite plus d'ops.
La plateforme la plus populaire en 2025 est Databricks (qui intègre MLflow nativement, Unity Catalog, Feature Engineering, et s'appuie sur Delta Lake) pour les organisations deja sur Spark ou Delta. Le critère de choix premier n'est pas la technologie mais la friction d'adoption : le meilleur tool est celui que l'équipe va réellement utiliser.
Comme le Data Mesh theater, il existe un 'MLOps theater' : des organisations qui deploient Kubeflow, MLflow, un feature store et Evidently sans avoir de modèle ML réellement en production (ou un seul, rarement retraine). L'infrastructure MLOps est un investissement qui se justifie par le volume de modèles en production et la fréquence de retraining. Pour un premier modèle, un notebook + un cron job de retraining mensuel peut être plus adapte que Kubeflow.
Ancrer le MLOps avec la répétition espacée
Le MLOps combine des concepts d'infrastructure (feature store, model registry, pipelines), de méthode (CI/CD ML, Continuous Training, testing ML) et de statistiques (drift, tests statistiques, PSI). La multiplicite des outils et leur interdependance rendent la memorisation passive peu efficace.
Les flashcards Memia 'MLOps et production ML' et 'Monitoring et drift des modèles' couvrent les distinctions clés pour les entretiens ML Engineer, Data Scientist senior et Head of Data Science : les niveaux de maturite MLOps, les trois types de drift, le role du feature store, la structure d'un model registry et les stratégies de déploiement.
Les thèmes les plus testes : (1) Les 3 types de drift et comment les détecter. (2) Training/serving skew : qu'est-ce que c'est, comment l'éviter. (3) Différence entre blue/green, canary et shadow deployment. (4) Role du model registry : quoi stocker, pourquoi c'est critique. (5) Point-in-time correctness : pourquoi c'est nécessaire dans un feature store. (6) Niveaux 0/1/2 de maturite MLOps : caracteristiques et critères de transition.
Approfondir le cluster Data & IA
Questions fréquentes sur le MLOps
Qu'est-ce que le MLOps ?
Le MLOps (Machine Learning Opérations) est un ensemble de pratiques qui combinent DevOps, Data Engineering et Machine Learning pour industrialiser le cycle de vie des modèles ML. Il couvre le versioning des données et modèles, les pipelines de training et déploiement automatisés, le monitoring en production, et le retraining. L'objectif est de passer d'un notebook a un système ML fiable et maintenable sur le long terme.
Quels sont les niveaux de maturite MLOps ?
Google Cloud définit 3 niveaux. Niveau 0 (manuel) : notebooks, déploiement ad hoc, pas de monitoring. Niveau 1 (pipeline automation) : training automatise dans un pipeline reproductible, Continuous Training sur nouvelles données, model registry. Niveau 2 (CI/CD complet) : le pipeline de training lui-même est versionne et teste en CI — chaque modification du code de feature engineering ou du modèle declenche un pipeline de validation avant promotion en production.
Quelle est la différence entre MLOps et DevOps ?
DevOps automatise le cycle de vie du code applicatif (build, test, deploy, monitor). MLOps etend ces principes au ML : il faut versionner les données et les modèles (pas seulement le code), tester les modèles (pas seulement l'application), monitorer la qualité des predictions (pas seulement l'infrastructure), et gerer le retraining quand les données évoluent. Le Continuous Training (CT) est l'extension clé spécifique au ML.
Qu'est-ce qu'un feature store ?
Un feature store centralise la creation, le stockage et le serving des features ML. Il comprend un offline store pour l'entraînement (batch, haute capacité : S3, BigQuery, Delta Lake) et un online store pour l'inference en temps réel (faible latence : Redis, DynamoDB). Il garantit la point-in-time correctness (évite le data leakage) et que les features sont calculées de la même façon a l'entraînement et en production. Outils : Feast, Tecton, Vertex AI Feature Store, SageMaker Feature Store, Databricks Feature Engineering.
Qu'est-ce que le drift en ML ?
Le drift désigne la degradation des performances d'un modèle due a des changements. Data drift : la distribution des inputs change vs la distribution d'entraînement (détecte par KS test, PSI). Concept drift : la relation entre inputs et output change — le monde évolue (plus difficile a détecter, nécessite des labels en production). Performance drift : les métriques métier se degradent (nécessite un pipeline de labellisation). Chaque type nécessite une réponse adaptée.
Qu'est-ce que le training/serving skew ?
Le training/serving skew survient quand les features calculées pendant l'entraînement different de celles calculées pendant l'inference (stats de normalisation differentes, encodage different, fenêtres temporelles differentes). Le modèle répond sans erreur mais ses predictions se degradent silencieusement. Un feature store avec la même logique de calcul pour le training et le serving élimine ce risque. C'est l'un des bugs les plus difficiles a détecter sans outillage adequat.
Qu'est-ce qu'un model registry ?
Un model registry centralise les modèles ML : artefacts (weights, preprocessing pipeline), métadonnées (métriques, dataset utilise, commit git du code), stages (Staging → Production → Archived) et historique des transitions. Sans registry, les modèles en production ne sont pas tracables et les rollbacks sont impossibles. Outils : MLflow Model Registry, Vertex AI Model Registry, SageMaker Model Registry, Weights & Biases Registry.
Quelles sont les stratégies de déploiement ML ?
Blue/green : switch instantane, rollback immédiat, zero downtime. Canary : rollout progressif (5% → 100%) — détecte les régressions sur trafic réel limite. Shadow mode : predictions en parallèle sans impact utilisateur — idéal avant toute mise en prod pour comparer les sorties. A/B testing : deux versions pour des segments differents — compare les métriques métier en conditions réelles. Le choix depend des risques métier et du volume.
Qu'est-ce que la point-in-time correctness ?
La point-in-time correctness garantit que, lors de la creation d'un dataset d'entraînement, chaque exemple utilise uniquement les features disponibles au moment de l'événement — pas des valeurs calculées après coup. Sans cette garantie, on créé du data leakage : le modèle semble performant en évaluation mais echoue en production. Les feature stores implementent cette garantie via des requetes temporelles ('features de l'utilisateur X telles qu'elles existaient le 15 mars a 14h35').
Quand ne pas adopter MLOps ?
Ne pas over-engineer pour un premier modèle ou une équipe de 1-2 personnes. Un notebook + un cron job de retraining mensuel peut suffire. L'investissement MLOps se justifie quand : plusieurs modèles sont en production simultanément, le retraining doit être fréquent (données qui changent vite), la degradation du modèle a un impact direct sur le revenu ou le risque, ou plusieurs Data Scientists travaillent en parallèle et doivent comparer leurs experiences. Commencer par MLflow pour le tracking — c'est le minimum utile.
Article précédent : Data Mesh, Data Products et Data Contracts