Pourquoi le MLOps ? Le probleme de la dette technique ML
Passer un notebook Jupyter a la production est l'un des defis les plus sous-estimes du machine learning. Les modeles se degradent avec le temps (drift), les dependances evoluent, les donnees changent, et sans pratiques rigoureuses, maintenir un modele en production devient rapidement un gouffre de dette technique.
Le MLOps (Machine Learning Operations) repond a ce probleme en appliquant les principes DevOps — automatisation, reproductibilite, monitoring, CI/CD — au cycle de vie ML. L'objectif : deployer des modeles rapidement, de facon fiable, et les maintenir performants dans la duree.
L'article fondateur 'Hidden Technical Debt in Machine Learning Systems' (Sculley et al., Google, NeurIPS 2015) a montre que le code ML lui-meme ne represente qu'une petite fraction du systeme : configuration, collecte de donnees, verification des features, infrastructure de serving, monitoring — tout cela constitue la majorite de la complexite reelle.
Sculley et al. - Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015Le cycle de vie d'un modele ML
Le cycle de vie ML comprend plusieurs phases sequentielles mais iteratives, chacune pouvant etre automatisee et versionnee.
1. Preparation des donnees et feature engineering
Collecte et validation des donnees sources, 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). Un feature store centralise peut stocker et servir les features de maniere cohesive entre training et inference.
2. Experimentation et selection de modeles
Experimentation avec suivi : MLflow Tracking, Weights & Biases, Comet ML ou Neptune permettent de logger hyperparametres, metriques, artefacts et code pour chaque run. Hyperparameter tuning (Optuna, Ray Tune, Keras Tuner). Selection selon les metriques metier (pas seulement la loss) et validation croisee robuste. Les experiences doivent etre reproductibles — environnement fixe (Docker), seed fixe, versions des librairies fixees.
3. Evaluation et validation avant deploiement
Un modele ne se deploie pas seulement parce qu'il depasse un seuil de precision. L'evaluation pre-deploiement inclut : tests de performance par segment (equite, biais), evaluation sur donnees recentes hors de la periode d'entrainement, tests de robustesse (perturbations, inputs adversariaux), verification de la conformite aux SLA de latence et throughput du serving.
4. Deploiement et serving
Strategies de deploiement : blue/green (switch instantane), canary (rollout progressif), shadow mode (prediction en parallele sans impact prod), A/B testing (comparaison de versions). Formats de serving : API REST (FastAPI + Docker), batch scoring (Spark, dbt + SQL), edge deployment (ONNX, TFLite, Core ML). Le model registry stocke les artefacts, les versions et les metadonnees de chaque modele promu en staging puis en production.
CI/CD pour le ML : pipelines et model registry
Le CI/CD ML est different du CI/CD applicatif classique : en plus du code, il faut versionner et tester les donnees, les features et les modeles.
Pipeline CI/CD ML typique
Trigger (push, schedule ou nouveau batch de donnees) → validation des donnees (schema, distribution, completude) → feature engineering reproductible → training du modele → evaluation automatique (metriques vs baseline et vs modele en prod) → enregistrement dans le model registry si OK → tests d'integration du serving (latence, format de sortie) → deploiement en staging → smoke tests → promotion en production. Outils : GitHub Actions, GitLab CI, Kubeflow Pipelines, Prefect, Airflow, Vertex AI Pipelines.
Model registry : versionning et gouvernance des modeles
Un model registry est le catalogue centralize des modeles ML : il stocke les artefacts (weights, preprocessing pipeline), les metadonnees (metriques, dataset utilise, hyperparametres), les stages (Staging, Production, Archived) et les transitions avec approbation. MLflow Model Registry, Vertex AI Model Registry, SageMaker Model Registry et Weights & Biases Registry sont les solutions les plus repandues. Sans registry, le 'modele en prod' est souvent un fichier .pkl quelque part sur un serveur, sans traçabilite.
Le CI/CD ML ajoute le Continuous Training (CT) : en plus de tester et deployer du code, on retrain automatiquement les modeles sur nouvelles donnees quand une condition est remplie (drift detecte, performance en dessous d'un seuil, nouveau batch hebdomadaire). C'est la boucle qui maintient les modeles a jour sans intervention manuelle.
Feature store : centraliser et reutiliser 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 probleme cle : eviter que chaque equipe recalcule les memes features differemment, avec un risque de training/serving skew (features calculees differemment a l'entrainement et a l'inference).
Architecture d'un feature store
Un feature store comprend deux parties : le offline store (base de donnees batch pour l'entrainement — S3, BigQuery, Snowflake) et l'online store (base a faible latence pour l'inference en temps reel — Redis, DynamoDB, Bigtable). La feature pipeline synchronise les deux. Les outils majeurs : Feast (open-source, cloud-agnostic), Tecton (managed, enterprise), Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS), Databricks Feature Engineering.
Le training/serving skew survient quand les features utilisees pendant l'entrainement sont calculees differemment pendant l'inference (ex : normalisation avec des stats differentes, encodage different, fenetres de temps differentes). Un feature store garantit que la meme logique est appliquee dans les deux contextes. Sans feature store, ce type de bug est silencieux et peut degrader les performances en production sans alerte evidente.
Monitoring ML : drift de donnees, drift de concept et alertes
Le monitoring ML est fondamentalement different du monitoring applicatif. Une API peut etre 'up' (latence OK, pas d'erreur 5xx) tout en produisant des predictions incorrectes a cause d'un changement dans les donnees d'entree. Le monitoring ML surveille la qualite des predictions, pas seulement l'infrastructure.
Types de drift et methodes de detection
Data drift (drift de covariables) : la distribution des inputs change par rapport a la distribution d'entrainement. Detection : tests statistiques (Kolmogorov-Smirnov, Chi-2, Population Stability Index) sur les features en production vs training. Concept drift : la relation entre inputs et output change — le modele pourrait avoir ete entraine sur des donnees qui ne refletent plus le monde reel. Plus difficile a detecter : necessite des labels en production (ground truth). Performance drift : les metriques metier (precision, recall, RMSE, business KPIs) se degradent. Necessite un pipeline de labellisation en production.
Outils de monitoring ML
Evidently AI (open-source, rapports HTML et dashboards Grafana), Arize AI, WhyLabs, Fiddler (enterprise), Seldon Alibi Detect (librairie Python). Les plateformes cloud ont leurs propres solutions : Vertex AI Model Monitoring, SageMaker Model Monitor, Azure ML Data Drift. Le monitoring ML s'integre generalement au stack observabilite existant (Prometheus, Grafana, Datadog).
Il existe deux strategies de retraining : schedule-based (toutes les semaines, tous les mois — simple mais peut retrainer inutilement ou pas assez) et trigger-based (quand le drift depasse un seuil ou quand la performance descend en dessous d'un seuil — plus precis mais necessite un bon pipeline de monitoring). Le retraining est declenche par le CI/CD : nouveau dataset → pipeline de training automatique → model registry → deploiement si metriques OK.
Ancrer le MLOps avec la repetition espacee
Le MLOps combine des concepts d'infrastructure (feature store, model registry, pipelines), de methode (CI/CD ML, Continuous Training) et de statistiques (drift, tests statistiques). Les flashcards permettent d'ancrer chaque concept independamment et de les relier dans leur logique de bout en bout.
Les 4 phases du cycle de vie ML, difference data drift vs concept drift vs performance drift, role du feature store et training/serving skew, strategies de deploiement (blue/green, canary, shadow), role du model registry, et outils associes (MLflow, Feast, Evidently). Questions frequentes en entretien ML Engineer et Data Scientist senior.
Questions frequentes sur le MLOps
Qu'est-ce que le MLOps ?
Le MLOps (Machine Learning Operations) est un ensemble de pratiques qui combinent DevOps, Data Engineering et Machine Learning pour industrialiser le cycle de vie des modeles ML. Il couvre le versioning des donnees et modeles, les pipelines de training et deploiement automatises, le monitoring en production, et le retraining. L'objectif est de passer d'un notebook a un systeme ML fiable et maintenable.
Quelle est la difference 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 en plus versionner les donnees et les modeles (pas seulement le code), tester les modeles (pas seulement l'application), monitorer la qualite des predictions (pas seulement l'infrastructure), et gerer le retraining quand les donnees evoluent. Le CI/CD ML est donc un superset du CI/CD classique.
Qu'est-ce qu'un feature store ?
Un feature store est une plateforme qui centralise la creation, le stockage et le serving des features ML. Il comprend un offline store pour l'entrainement (batch, haute capacite) et un online store pour l'inference en temps reel (faible latence). Il garantit que les features sont calculees de la meme facon a l'entrainement et en production, evitant le training/serving skew. Outils : Feast, Tecton, Vertex AI Feature Store, SageMaker Feature Store.
Qu'est-ce que le drift en ML ?
Le drift en ML designe la degradation des performances d'un modele due a des changements dans les donnees ou les relations entre variables. Data drift (covariates drift) : la distribution des inputs change par rapport au training. Concept drift : la relation entre inputs et output change (le monde evolue). Performance drift : les metriques metier se degradent. Chaque type se detecte differemment et necessite une reponse adaptee.
Qu'est-ce qu'un model registry ?
Un model registry est le catalogue centralise des modeles ML : il stocke les artefacts (weights, preprocessing pipeline), les metadonnees (metriques, dataset, hyperparametres), les stages de cycle de vie (Staging, Production, Archived) et les transitions avec historique. Sans registry, les modeles en production ne sont pas tracables. Outils : MLflow Model Registry, Vertex AI, SageMaker, Weights & Biases.
Quelles sont les strategies de deploiement ML ?
Blue/green : un deploiement remplace l'autre instantanement, rollback facile. Canary : le trafic est redirige progressivement (5% → 20% → 100%) vers la nouvelle version. Shadow mode : le nouveau modele fait des predictions en parallele sans impact sur les utilisateurs, utile pour valider avant mise en prod. A/B testing : deux versions servent differents segments d'utilisateurs pour comparer les performances. Le choix depends des risques et du volume.
Quels sont les outils MLOps les plus utilises ?
Experimentation : MLflow, Weights & Biases, Comet ML. Pipelines : Kubeflow, Prefect, Airflow, Vertex AI Pipelines. Feature store : Feast, Tecton, Vertex AI Feature Store. Serving : BentoML, Seldon, KServe, FastAPI + Docker. Model registry : MLflow, Vertex AI, SageMaker. Monitoring : Evidently AI, Arize AI, WhyLabs. Versioning donnees : DVC. La plupart des cloud providers (GCP Vertex AI, AWS SageMaker, Azure ML) offrent aussi des plateformes MLOps integrees.
Article precedent : Data Mesh, Data Products et Data Contracts