Le MLOps (Machine Learning Operations) est l'ensemble des pratiques pour déployer, surveiller et maintenir des modèles ML en production de façon fiable et reproductible. Sans MLOps, 87% des projets ML ne dépassent pas le stade du prototype.
Pourquoi le MLOps est-il indispensable ?
Un modèle ML n'est pas un logiciel classique : il se dégrade dans le temps à mesure que les données du monde réel évoluent. Sans surveillance active, un modèle peut silencieusement produire des prédictions erronées pendant des semaines.
- Data drift : la distribution des données en entrée change (ex : comportement client post-COVID)
- Concept drift : la relation entre features et cible change (ex : nouveau segment de marché)
- Infrastructure drift : dépendances et environnements évoluent, modèles devenant incompatibles
Versioning des modèles et des données
Tout comme le code est versionné avec git, les modèles et les données doivent l'être. MLflow est le standard open source pour le tracking d'expériences ML, tandis que DVC (Data Version Control) gère les gros fichiers de données.
- MLflow Tracking : logguer métriques, paramètres et artefacts pour chaque expérience
- MLflow Model Registry : versionner les modèles avec des transitions (Staging → Production)
- DVC : versionner les datasets et relier chaque version de données à un commit git
- Weights & Biases (W&B) : alternative SaaS avec visualisations avancées
CI/CD pour le Machine Learning
Un pipeline CI/CD ML automatise l'entraînement, l'évaluation et le déploiement des modèles. Chaque commit de code ou de données peut déclencher un réentraînement et, si les métriques passent les seuils, un déploiement automatique.
- GitHub Actions ou GitLab CI : déclencher les pipelines ML sur push ou schedule
- Tests de non-régression : le nouveau modèle doit battre l'ancien sur un dataset de référence
- Tests de qualité des données : vérifier le schéma et les distributions avant l'entraînement
- Gates de déploiement : validation humaine ou automatique selon les métriques
Containerisation avec Docker
Docker garantit que votre modèle s'exécute dans le même environnement en développement, en staging et en production. Un Dockerfile bien écrit capture toutes les dépendances et élimine les problèmes « ça marche sur ma machine ».
- Image de base : python:3.11-slim ou des images CUDA pour les modèles GPU
- Multi-stage build : séparer l'image de build (lourde) de l'image de production (légère)
- Health checks : Docker vérifie automatiquement que le service est opérationnel
- Docker Compose : orchestrer model server + monitoring + base de données localement
Serving : exposer votre modèle
Un modèle en production est exposé via une API. FastAPI est le choix dominant pour sa rapidité, sa documentation automatique et son support natif de Python async. Pour les modèles à forte charge, BentoML et Triton Inference Server offrent des optimisations avancées.
- FastAPI : API REST rapide, documentation OpenAPI auto-générée
- BentoML : packaging et serving multi-framework (sklearn, PyTorch, TensorFlow)
- TorchServe : serving optimisé pour les modèles PyTorch
- ONNX Runtime : convertir les modèles en format portable pour accélérer l'inférence
Monitoring en production
Le monitoring ML va bien au-delà du monitoring applicatif classique. Il faut surveiller à la fois l'infrastructure (latence, CPU, mémoire) et la qualité du modèle (distributions des entrées, performances sur des labels spot-checkés).
- Métriques d'infrastructure : p50/p95/p99 latence, taux d'erreur, throughput
- Métriques de données : PSI (Population Stability Index) pour détecter le data drift
- Métriques de modèle : précision spot-check sur des labels manuels périodiques
- Alertes : seuils configurés dans Prometheus + Grafana ou outils SaaS (Evidently, Arize)
Un modèle sans monitoring en production, c'est comme conduire les yeux fermés : vous n'avez aucune idée de la direction prise.
Stack MLOps recommandée en 2026
MLflow (tracking) + GitHub Actions (CI/CD) + Docker (containerisation) + FastAPI (serving) + Evidently (monitoring) : cette stack open source couvre 90% des besoins sans vendor lock-in.