← Retour aux parcours
Construire des systèmes IAAvancé

MLOps

Mettre l’IA en production et l’y maintenir — malgré la dérive, les incidents et les factures.

La plupart des projets IA n’échouent pas sur le modèle. Ils échouent trois mois après le lancement, en silence, quand plus personne ne sait quelle version tourne, pourquoi les chiffres ont bougé, ni qui appeler. Le MLOps est la discipline qui empêche ça, et son manque de glamour est délibéré. Ce parcours traite un modèle pour ce qu’il est réellement en production : une dépendance avec un contrat de données, un coût, un budget de latence et un taux de péremption. Vous commencez par la fondation ennuyeuse — la reproductibilité. Si vous ne pouvez pas reconstruire le modèle du mois dernier à partir du seul dépôt, vous n’avez pas un système, vous avez une anecdote. Puis le déploiement : packaging, rollout, rollback, et cette vérité inconfortable qu’un déploiement en shadow vous apprendra plus en une semaine que n’importe quelle métrique hors ligne. Vient ensuite la supervision, où ce parcours prend sa position la plus tranchée : la justesse du modèle est le dernier signal à vous alerter et le premier que tout le monde surveille. La distribution des entrées et la qualité des données bougent en premier — c’est donc là que doivent vivre vos alertes. Vous traiterez la dérive, les décisions de réentraînement, et la question que l’on évite : quand mettre un modèle à la retraite. Et vous vivrez un vrai incident, car rédiger un postmortem sur un système dont la justesse est statistique enseigne plus en un après-midi qu’un mois de lecture. Le coût est une métrique de premier rang du début à la fin, pas une surprise financière découverte au renouvellement.

NiveauAvancé
Durée estimée6-9 mois
Phases3

Ce que vous allez apprendre

Pipelines reproductibles et versioning des donnéesPackaging et service (batch, online, shadow)CI/CD avec garde-fous d’évaluationSupervision de la qualité et de la distribution des entréesDétection de dérive et stratégie de réentraînementRollback, canary et livraison progressiveCoût par prédiction et dimensionnementGestion d’incidents et postmortems sans blâme

Prérequis

  • Python et Git au quotidien
  • Une expérience en ML ou en applications LLM
  • Les conteneurs et la ligne de commande
  • Une première exposition à un fournisseur cloud

Débouchés

  • Ingénieur MLOps
  • Ingénieur plateforme ML
  • Ingénieur fiabilité IA
  • Data engineer avec périmètre ML en production

Phases

Phase 1 — Reproductibilité & packaging

Pouvoir reconstruire, identifier et annuler tout ce que vous livrez — à partir du seul dépôt.

Durée estimée · 8-10 semaines

Si vous ne pouvez pas le reconstruire, il ne vous appartient pas

Demandez à une équipe quelles données exactes ont produit le modèle qui sert actuellement les clients. Le silence qui suit est le problème que règle cette étape. Le versioning du code est résolu ; celui des données est là où l’on triche, et c’est la moitié qui décide si un débogage prend une heure ou quinze jours. La traçabilité d’une prédiction jusqu’aux lignes qui l’ont entraînée paraît excessive — jusqu’à ce qu’un régulateur ou un client furieux la demande.

Sujets couverts

Versioning des données et snapshots immuablesSuivi d’expériences qui survit à celui qui les a lancéesPipelines déterministes et environnements figésRegistres d’artefacts et adressage par contenuTraçabilité : prédiction → modèle → dataset → ligneSeeds et les limites honnêtes du déterminismeDocumenter le contrat de données

Ce que vous allez construire

  • Reconstruire un modèle à partir d’un seul hash de commit et montrer que les métriques correspondent à l’original dans une tolérance annoncée
  • Remonter d’une prédiction de production jusqu’au snapshot d’entraînement et à la version de dataset exacts qui l’ont produite
  • Écrire le contrat de données d’un flux d’entrée, le casser volontairement en staging et prouver que le pipeline refuse d’entraîner

Packaging et mise en service

Le choix du mode de service conditionne tout le reste, et la plupart des équipes partent par défaut sur un endpoint temps réel dont elles n’avaient pas besoin — un batch nocturne est moins cher, plus simple et plus facile à réparer, et une part surprenante des cas d’usage s’en accommode. Le tueur classique ici est le skew training/serving : la même feature calculée de deux façons dans deux bases de code. Ça n’apparaît jamais dans vos métriques hors ligne et toujours en production.

Sujets couverts

Batch vs online vs streaming : choisir honnêtementConteneurisation et figeage des dépendancesRegistre de modèles et promotion entre environnementsContrats d’inférence et validation de schéma en entréeCold starts, warm-up et comportement de l’autoscalingSkew training/serving et comment le détecterLe choix matériel comme décision de coût, pas comme signe extérieur

Ce que vous allez construire

  • Servir un modèle de trois façons — batch, online, shadow — et rédiger la note d’une page qui tranche, chiffres à l’appui
  • Construire un détecteur de skew qui compare les valeurs de features à l’entraînement et au service sur du trafic réel et alerte sur les écarts
  • Prendre un endpoint surdimensionné et diviser son coût par deux, avec un tableau de percentiles de latence prouvant que rien n’a cassé

Phase 2 — Déploiement & CI/CD

Rendre les mises en production ennuyeuses : automatisées, réversibles, et observées avant d’atteindre tout le monde.

Durée estimée · 8-10 semaines

Livrer sans retenir son souffle

Le déploiement en shadow est la technique la plus sous-utilisée du domaine : faire tourner le nouveau modèle sur du trafic réel, ne rien servir, comparer. Ça coûte une inférence de plus et ça achète une preuve qu’aucun benchmark hors ligne ne donne. Et le rollback mérite d’être un chemin répété, pas une improvisation à minuit : si revenir en arrière exige une personne qui dort, vous n’avez pas un rollback, vous avez un espoir.

Sujets couverts

Déploiement shadow : trafic réel, risque nulCanary et répartition de traficTests A/B et les statistiques qu’on sauteLe rollback comme chemin de premier rang, répétéBlue/green et épinglage de versionFeature flags pour les versions de modèlesConditionner une mise en production aux résultats d’évaluation

Ce que vous allez construire

  • Faire tourner un nouveau modèle en shadow pendant une semaine et produire le rapport de comparaison qui tranche go/no-go
  • Répéter un rollback chronomètre en main jusqu’à ce que n’importe qui puisse revenir en arrière en moins de cinq minutes
  • Livrer un canary sur une petite part de trafic, définir à l’avance la règle d’abandon automatique, et la déclencher volontairement

Pipelines et CI/CD

Une suite de tests qui vérifie votre code mais jamais vos données ne teste que la moitié facile. Les transformations sont l’endroit où se cachent les bugs, et une colonne silencieusement corrompue entraînera volontiers un modèle qui passe tous les tests unitaires. L’autre décision, c’est le réentraînement : réentraîner sur calendrier est une habitude, réentraîner sur déclencheur est une stratégie. La plupart des équipes réentraînent au calendrier parce que c’est facile à justifier, puis ne réentraînent plus quand le calendrier devient du bruit.

Sujets couverts

Tester les pipelines de données, pas seulement le codeTests unitaires des transformations et des lignes limitesGarde-fous d’évaluation qui bloquent un mauvais mergeRéentraînement planifié vs déclenché par événementOrchestration et jobs idempotentsBackfills et retraitement sans duplicationSecrets, accès et piste d’audit

Ce que vous allez construire

  • Ajouter des tests de qualité de données à un pipeline, corrompre une colonne en staging et prouver que le build échoue avant l’entraînement
  • Poser un garde-fou d’évaluation en CI et ouvrir une pull request qui échoue légitimement dessus
  • Remplacer un réentraînement planifié par un déclencheur lié à un signal mesuré, et défendre par écrit le seuil choisi

Phase 3 — Supervision, dérive & incidents

Repérer la dégradation avant vos utilisateurs, et savoir exactement quoi faire à 3 h du matin.

Durée estimée · 8-12 semaines

Superviser ce qui bouge en premier

Les dashboards de justesse sont rassurants et quasi inutiles comme alarme, car la vérité terrain arrive avec des semaines de retard — quand la courbe plie, vous vous trompez depuis un mois. Les entrées bougent en premier. Surveillez distributions, taux de nulls et cardinalité, et traitez un changement de schéma en amont pour ce qu’il est : un incident. Autre chose : chaque alerte de dérive sur laquelle on ne peut pas agir apprend à votre équipe à ignorer la suivante.

Sujets couverts

Distribution des entrées et qualité des données comme première alarmeDérive de covariables, de labels, de concept — et comment les distinguerVérité terrain retardée et métriques proxySupervision par segment : la moyenne cache la panneConception des alertes et fatigue d’alerteChangements de schéma en amont comme incidentsLes dashboards que personne ne lit, et quoi construire à la place

Ce que vous allez construire

  • Instrumenter la supervision des entrées d’un modèle en production et attraper un vrai changement amont avant que la moindre métrique de justesse ne bouge
  • Casser la moyenne volontairement : trouver un segment où le modèle est bien pire que le chiffre affiché et ajouter une alerte par segment
  • Auditer vos alertes, supprimer toutes celles sur lesquelles personne n’a agi le trimestre dernier, et justifier chaque suppression

Coût, incidents et retrait

Les systèmes statistiques échouent autrement : pas d’exception, pas de stack trace, juste des réponses discrètement moins bonnes. Votre runbook doit donc répondre à une question que le logiciel ordinaire ne pose jamais : comment décide-t-on que le système est cassé ? Et le retrait reste tabou : les modèles survivent à leur utilité parce que personne n’est récompensé pour en éteindre un, et chacun qu’on garde est un coût permanent et un risque permanent.

Sujets couverts

Coût par prédiction et par résultat réussiBatching, cache et dimensionnementRunbooks : la décision, pas seulement les commandesAstreinte pour des systèmes sans stack tracePostmortems sans blâme et le correctif qui n’est pas une personneDécisions de réentraînement : quand ça n’aidera pasDéprécier et retirer un modèle, délibérément

Ce que vous allez construire

  • Publier le coût par prédiction de chaque modèle que vous exploitez, puis réduire d’un tiers le plus cher sans régression de qualité
  • Écrire un runbook dont la première section est « comment savoir si c’est vraiment cassé », le confier à quelqu’un qui n’a jamais vu le système et lui faire passer un exercice
  • Retirer un modèle : prouver qu’il ne justifie plus son coût, migrer ses consommateurs, et l’éteindre

Questions

Le MLOps, c’est du DevOps avec des étapes en plus ?

L’outillage se ressemble ; les modes de défaillance non. Le logiciel ordinaire est déterministe et casse bruyamment — une exception, une stack trace, un dashboard rouge. Un modèle a une dépendance que vous ne contrôlez pas et ne pouvez pas versionner poliment : le monde. Il se dégrade en silence, sa justesse est statistique et non binaire, et la vérité terrain qui vous dirait qu’il se trompe arrive des semaines après les dégâts. Cela change ce que vous construisez : des tests de données en plus des tests de code, des déploiements shadow parce que la staging ne reproduit pas les vraies entrées, une supervision de dérive parce que rien ne lève d’erreur, et un runbook dont la première question est « est-ce vraiment cassé ? ». Les compétences DevOps se transfèrent. Les réflexes, non.

Ai-je besoin de MLOps si je n’utilise que des APIs LLM sans jamais entraîner ?

Plus que vous ne le croyez, et souvent dans une position pire. Vous héritez de toute la charge opérationnelle sans posséder le modèle. Le fournisseur met à jour quelque chose sous vos pieds et votre comportement change sans un seul commit de votre côté : c’est une dépendance dont vous ne maîtrisez pas le changelog. Vos prompts sont des artefacts qui exigent versions, diffs et rollback, et la plupart des équipes les gardent dans un littéral de chaîne modifié un vendredi. Votre coût est variable par requête plutôt que fixe par serveur, ce que la finance n’a jamais eu à modéliser. Votre suite d’évaluation est votre seul test de régression, car il n’existe pas de test unitaire pour le ton. Le vocabulaire change ; la discipline est identique.

Quels outils et plateformes faut-il apprendre ?

Apprenez les concepts et construisez d’abord la version minimale à la main. Un registre de modèles peut commencer comme un dossier avec une convention de nommage et un manifeste ; un garde-fou d’évaluation comme un script en CI ; la traçabilité comme une colonne dans une table. Le faire manuellement sur un vrai système vous apprend quel est réellement le problème, si bien qu’en évaluant une plateforme vous saurez dire si elle le résout ou si elle se contente de le renommer. Les ingénieurs qui apprennent une plateforme d’abord deviennent fluents chez un fournisseur et démunis quand l’entreprise en choisit un autre — et ce paysage de fournisseurs change plus vite que presque partout ailleurs. Les concepts, eux, sont stables : reproductibilité, garde-fous, observation, réversibilité. Rien dans cette liste n’a changé en dix ans.

Parcours liés

Applications LLMMachine LearningAgents IA

Envie de suivre ce parcours avec un coach et une cohorte ?

Découvrir la 212AY Academy →