3 min de lecture

---

L’entraînement d’un modèle d’apprentissage automatique est la partie facile. La partie difficile commence ensuite : comment déployer ce modèle de façon fiable en production, le maintenir à jour et détecter dès qu’il cesse de fonctionner correctement ? MLOps – la discipline située à l’intersection de l’apprentissage automatique et de DevOps – fournit les réponses. Les plateformes cloud rendent désormais ces réponses accessibles à tous.

Pourquoi les projets ML échouent-ils en production ?

La statistique est sans appel : selon Gartner, seuls 53 % des projets ML parviennent à passer du stade de prototype à celui de la production. Les causes sont rarement liées aux algorithmes – elles sont opérationnelles. Les data scientists travaillent dans des notebooks, le déploiement est manuel, aucune surveillance n’est mise en place, et personne ne remarque lorsque les données d’entrée évoluent.

Le résultat ? Des modèles qui excellent dans un notebook Jupyter, mais échouent lamentablement en production. L’écart entre l’expérimentation et la production constitue le problème central que MLOps résout.

L’architecture MLOps : du feature store à la model registry

Une pipeline MLOps robuste repose sur cinq composants fondamentaux :

Feature Store : Dépôt centralisé pour les caractéristiques pré-calculées, réutilisables par plusieurs modèles. Feast (open source) ainsi que les feature stores natifs de SageMaker et de Vertex AI éliminent les travaux redondants d’ingénierie des caractéristiques.

Training Pipeline : Tâches d’entraînement automatisées et reproductibles, avec gestion des versions pour le code, les données et les hyperparamètres. Kubeflow Pipelines, SageMaker Pipelines et Vertex AI Pipelines constituent les implémentations les plus courantes.

Model Registry : Dépôt versionné pour les modèles entraînés, doté de métadonnées, de métriques et de traçabilité (lineage). La Model Registry de MLflow et les registres natifs des fournisseurs cloud constituent la norme de facto.

Serving Infrastructure : Inférence évolutif via des API REST ou un traitement par lots (batch processing). Le auto-scaling, les tests A/B et les déploiements progressifs (canary deployments) pour les modèles fonctionnent de manière analogue aux microservices classiques.

Model Monitoring : Surveillance continue des données d’entrée (Data Drift), de la qualité des prédictions (Model Drift) et des métriques opérationnelles (latence, débit).

Data Drift : le risque invisible

Les modèles ML sont entraînés sur des données historiques. Lorsque la distribution des données en production change – par exemple à cause d’effets saisonniers, de nouveaux segments clients ou de chocs externes – , la qualité du modèle se dégrade progressivement. Sans surveillance, on ne s’en aperçoit qu’une fois que les indicateurs métier commencent à chuter.

Les solutions modernes de détection de drift utilisent des tests statistiques (Kolmogorov-Smirnov, Population Stability Index) au niveau des caractéristiques (features) et au niveau des prédictions. Dès qu’un drift est détecté, la pipeline déclenche automatiquement un nouvel entraînement avec les données les plus récentes. SageMaker Model Monitor et Vertex AI Model Monitoring implémentent ce schéma « out-of-the-box ».

Géré vs auto-hébergé : la décision « construire ou acheter »

Les plateformes MLOps gérées telles que SageMaker, Vertex AI et Azure ML réduisent radicalement la barrière à l’entrée. Entraînement, inférence et surveillance sont intégrés ; l’infrastructure est entièrement abstraite. Pour les équipes souhaitant rapidement atteindre la production, cette voie est fortement recommandée.

Les piles auto-hébergées reposant sur Kubeflow, MLflow, Seldon et Prometheus offrent davantage de flexibilité et de portabilité, mais exigent une capacité d’ingénierie considérable. Ce choix est pertinent pour les entreprises disposant de grandes équipes ML et ayant des exigences spécifiques en matière de souveraineté des données ou de portabilité multi-cloud.

Démarrage pratique : MLOps en trois niveaux de maturité

Niveau 0 – Manuel : Les modèles sont entraînés et déployés manuellement. La surveillance repose sur des tableaux de bord. Ce niveau est acceptable pour les premiers proofs-of-concept.

Niveau 1 – Automatisation des pipelines : L’entraînement est automatisé et reproductible. Les modèles sont déployés via des pipelines CI/CD. La dérive des données (Data Drift) est surveillée. La plupart des entreprises devraient démarrer à ce niveau.

Niveau 2 – Automatisation complète : Entraînement continu déclenché par la détection de drift, tests A/B automatisés, feature stores, retour arrière (rollback) automatisé. Ce niveau concerne les équipes exploitant de nombreux modèles en production.

Pour aller plus loin sur cloudmagazin.com

• Plateformes de gestion SaaS : maîtriser l’informatique fantôme (shadow IT) dans le cloud
• AIOps : comment l’intelligence artificielle automatise l’exploitation cloud et prévient les pannes
• FinOps : comment les entreprises prennent enfin le contrôle de leurs coûts cloud

Questions fréquentes

Quelle est la différence entre MLOps et DevOps ?

DevOps automatise le cycle de vie logiciel (code → construction → test → déploiement). MLOps étend ce cycle aux exigences propres à l’apprentissage automatique : gestion des versions des données, suivi des expériences (experiment tracking), ingénierie des caractéristiques (feature engineering), entraînement des modèles, model registry et surveillance des modèles. Les principes fondamentaux (automatisation, surveillance, reproductibilité) restent identiques.

Quelle plateforme cloud convient le mieux à MLOps ?

SageMaker (AWS) propose la gamme de fonctionnalités la plus étendue et bénéficie de la plus grande communauté. Vertex AI (GCP) s’intègre parfaitement à BigQuery et offre des fonctionnalités AutoML particulièrement puissantes. Azure ML se distingue dans les environnements écosystémiques Microsoft. Le choix dépend du fournisseur cloud déjà utilisé et du profil technique de l’équipe.

Combien d’ingénieurs ML sont nécessaires pour mettre en œuvre MLOps ?

Pour un démarrage (niveau 1), 1 à 2 ingénieurs ML suffisent pour configurer la pipeline. Les services gérés réduisent considérablement ce besoin. Pour le niveau 2, avec de nombreux modèles en production, on compte généralement 1 ingénieur ML pour 5 à 10 modèles opérationnels.

Quel est le coût de MLOps dans le cloud ?

Les coûts liés à la plateforme varient fortement selon la complexité du modèle et le volume d’inférence. Une configuration typique, comprenant un entraînement quotidien et une inférence en temps réel, coûte entre 500 et 2 000 €/mois pour l’infrastructure. Le facteur de coût le plus important reste toutefois le nombre d’heures d’ingénierie consacrées à la configuration et à la maintenance.

MLOps est-il nécessaire pour les applications basées sur des grands modèles linguistiques (LLM) ?

Oui, mais avec des adaptations. Les LLM sont rarement entraînés in-house – l’accent est mis sur la gestion des prompts, l’optimisation des pipelines RAG (Retrieval-Augmented Generation), l’évaluation et la surveillance des hallucinations. LLMOps, en tant que sous-discipline, répond précisément à ces besoins spécifiques.

Source de l’image : Pexels / Google DeepMind