Aller au contenu principal

Module 1 — Ce que MLOps résout que le développement classique ignore

Lundi matin, Alice, analyste chez un opérateur télécom, envoie un message à l'équipe : « J'ai un modèle qui atteint 0,82 d'AUC sur la prédiction de résiliation, il faut le mettre en production. » Le carnet Jupyter est propre, les métriques sont bonnes, la démonstration est convaincante. Six mois plus tard, personne n'utilise ce modèle et l'analyste a quitté l'entreprise. Cette histoire, tous les responsables de plateforme d'apprentissage l'ont vécue. MLOps est la discipline qui empêche qu'elle se répète.

Le carnet de départ, et ce qu'il ne dit pas​

Le carnet d'Alice fait 400 lignes. Il charge un extrait CSV posé sur son poste, applique quelques transformations, entraîne un RandomForestClassifier, affiche une matrice de confusion. Tout tourne en douze minutes sur son portable. Le problème n'est pas dans ces douze minutes ; il est dans tout ce que le carnet ne dit pas.

  • Quel jeu de données exactement ? L'extrait CSV s'appelle churn_v3_final.csv. Personne ne sait comment il a été construit, ni ce qui le distingue de churn_v3_final_corrige.csv posé à côté.
  • Quelles versions des bibliothèques ? Le carnet importe sklearn sans fixer la version. Le portable d'Alice avait scikit-learn 1.3.2 ; le serveur de la production a 1.5.1. Le même modèle, réentraîné, donne 0,79 au lieu de 0,82.
  • Reproductible ? Aucune graine n'est fixée. Deux exécutions successives sur la même machine ne donnent pas exactement les mêmes résultats.
  • Comment on l'appelle en production ? Le carnet lit un fichier, la production appellera un service qui répond à un JSON. La transformation des variables entre les deux moments est écrite deux fois, et diverge.
  • Comment on sait qu'il fonctionne encore ? Un modèle qui donne 0,82 sur les abonnés de janvier peut tomber à 0,68 sur ceux de juin, sans que la moindre erreur applicative ne le signale.
  • Comment on revient en arrière ? La question ne s'était même pas posée.

Ces six manques ne sont pas des détails d'implémentation. Ce sont les six piliers du cours.

Pourquoi les recettes du logiciel classique ne suffisent pas​

Un service web sans apprentissage a un comportement déterministe : mêmes entrées, même sortie. On le teste avec des données figées, on le déploie, et il continue de fonctionner tant que le code ne change pas.

Un modèle d'apprentissage introduit trois régimes que le développement logiciel classique n'a jamais eu à traiter.

Les données changent, même si le code ne change pas. Les habitudes des abonnés varient avec les saisons, la concurrence, les campagnes marketing. Le modèle d'Alice, entraîné en janvier, verra en juin une population qui ne ressemble plus à celle qu'il a apprise. On appelle ce phénomène la dérive (module 9). Le modèle se dégrade en silence : aucun test unitaire ne lève d'exception, aucune journal n'affiche d'erreur.

Le modèle est une fonction des données, du code et de la graine. Deux équipes qui exécutent le même carnet sur les mêmes données mais avec des versions différentes de numpy obtiennent des poids différents. Sans verrouillage, la reproductibilité disparaît (module 2).

L'expérimentation est le mode de travail par défaut. Un développeur logiciel écrit une fonction et la teste ; un praticien de l'apprentissage lance trente entraînements pour comparer des hyperparamètres, des variables, des architectures. Chaque exécution produit des artefacts qui doivent être retrouvables trois mois plus tard, sinon la valeur du travail est perdue (module 3).

Les cinq niveaux de maturité MLOps​

L'industrie a adopté une grille qui aide à situer une équipe :

NiveauÀ quoi il ressemble
0Un carnet Jupyter, aucun suivi, aucun versionnage. Le cas d'Alice.
1Les exécutions sont journalisées et comparables (MLflow), l'environnement est verrouillé.
2Données et modèles sont versionnés ; un registre porte des étapes de promotion.
3Une chaîne d'intégration continue teste automatiquement les données et le modèle à chaque commit.
4Le réentraînement est déclenché par la dérive, avec validation et retour arrière automatiques.

Ce cours conduit d'un carnet de niveau 0 à un service de niveau 4 sur le même dépôt, module après module.

Ce que MLOps n'est pas

MLOps n'est pas un outil, pas une plateforme, pas un titre de poste. C'est un ensemble de pratiques, souvent portées par la même personne qui écrit le modèle. Croire qu'on « adopte MLOps » en achetant un produit est le premier piège ; le second est de croire qu'un carnet propre suffit à s'en passer.

En résumé​

  • Un modèle qui marche en carnet n'a franchi qu'une petite partie du chemin vers un service utile ; six pratiques manquent presque toujours.
  • Les données changent, le code non : un modèle se dégrade en silence sans aucune erreur applicative visible.
  • L'expérimentation est le mode par défaut : chaque exécution doit rester retrouvable, comparable et reproductible.
  • La grille de maturité en cinq niveaux situe une équipe et donne un cap.

Le module 2 ouvre le premier chantier : rendre l'entraînement reproductible.