MLOps et MLflow : la démarche n’est pas l’outil

« On fait du MLOps, on a installé MLflow. » La phrase se dit souvent, et elle contient une confusion de catégorie. Autant dire qu’on fait du DevOps parce qu’on a installé Jenkins.

DevOps  = méthode, pratiques        MLOps   = méthode, pratiques
Jenkins = outil                     MLflow  = outil

Le MLOps est une façon de travailler. MLflow est un logiciel qui aide à en mettre en œuvre une partie. On peut faire du MLOps sérieux sans MLflow, et installer MLflow sans faire de MLOps du tout.

Le cycle que le MLOps couvre

La flèche du bas est ce qui distingue ce schéma d’un pipeline logiciel classique : ce n’est pas une chaîne, c’est une boucle. Un modèle n’est jamais terminé, parce que les données sur lesquelles il travaille continuent d’arriver.

Le MLOps consiste à faire tourner cette boucle de façon fiable, reproductible et sans intervention héroïque. Cela comprend des outils, mais surtout des décisions : à quelle cadence réentraîner, à quelle condition promouvoir, qui valide, ce qu’on surveille, comment on revient en arrière.

Ce que MLflow couvre, et ce qu’il ne couvre pas

C’est la carte qui manque dans la plupart des présentations. MLflow est excellent sur une portion précise du cycle.

Autrement dit, MLflow répond très bien à trois questions — qu’avons-nous essayé, quelle version tourne, où est l’artefact — et laisse tout le reste ouvert. Ce n’est pas une lacune : c’est un choix de périmètre, et c’est ce qui lui permet de s’insérer dans des architectures très différentes.

Ses composants, dans l’ordre où on les rencontre :

• Tracking — le suivi des expériences : paramètres, métriques, artefacts.
• Models — un format d’emballage qui rend un modèle chargeable indépendamment de la bibliothèque qui l’a produit.
• Model Registry — le nom, les versions, et qui est en service.
• Projects — une façon de décrire une exécution reproductible.

Le registre, et le détail qui compte

Le registre est le point de bascule entre expérimenter et servir. Un essai devient un modèle nommé, avec des versions :

FraudModel
├── v1 → F1 = 0,86
├── v2 → F1 = 0,91
└── v3 → F1 = 0,94

Reste à dire lequel tourne. MLflow le fait par des alias, un mécanisme qui remplace les anciennes « étapes » Staging et Production — dépréciées depuis la version 2.9 et retirées depuis la version 3.

from mlflow import MlflowClient

client = MlflowClient()

client.set_registered_model_alias('FraudModel', 'champion', 3)

Le service, lui, ne connaît plus aucun numéro de version :

models:/FraudModel@champion

L’intérêt est net : promouvoir revient à déplacer l’alias, et revenir en arrière consiste à le remettre sur la version précédente. C’est exactement le protocole champion contre candidat de la décision de réentraînement, et un même modèle peut porter plusieurs alias, ce qui rend un test A/B exprimable.

Un piège à connaître, et il en rappelle un autre : déplacer l’alias ne change rien aux services déjà démarrés. Ils continuent de servir la version qu’ils ont chargée en mémoire, jusqu’à leur redémarrage. C’est le même phénomène que modifier un ConfigMap sans redémarrer les Pods : la source de vérité a changé, le consommateur ne l’a pas relue. La promotion d’un modèle doit donc s’accompagner d’un redéploiement, ou d’un service capable de recharger.

Pourquoi le MLOps n’est pas du DevOps avec des modèles

C’est la question qui sépare une compréhension de surface d’une compréhension réelle. Trois différences, et elles sont structurelles.

L’artefact ne dépend pas seulement du code. En logiciel, le même code produit le même binaire. En apprentissage automatique, le même code sur d’autres données produit un autre modèle. Versionner le code ne suffit donc pas à reproduire quoi que ce soit : il faut versionner le code et les données, ce qui n’a pas d’équivalent en DevOps classique et explique la présence d’outils dédiés.

Le système se dégrade sans que personne ne l’ait touché. Une application dont le code ne change pas fait la même chose demain. Un modèle dont rien ne change devient faux, parce que le monde qu’il décrit a bougé. C’est la dérive, et elle rend la surveillance obligatoire au lieu d’être une bonne pratique.

La justesse est statistique. On ne teste pas un modèle par des assertions : predict(x) == y n’a pas de sens sur un cas isolé. Les tests portent sur des seuils, des distributions, des propriétés — ce qui rend l’intégration continue plus difficile à écrire et les critères de promotion plus délicats à définir.

Ces trois différences expliquent pourquoi les pratiques DevOps se transposent sans se copier : la boucle de rétroaction ne passe pas par les tickets d’incident, mais par les données.

Une architecture possible

Le mot important est possible. Chaque boîte est remplaçable : GitLab CI plutôt que GitHub Actions, Airflow ou Dagster pour orchestrer, un service géré plutôt qu’un déploiement maison. Ce qui ne se remplace pas, c’est la présence de chaque fonction : versionner, entraîner, tracer, décider, déployer, surveiller, boucler.

Deux fonctions manquent d’ailleurs à ce schéma, et leur absence est fréquente en pratique : la version des données, sans laquelle rien n’est reproductible, et la détection de dérive, que Prometheus ne fait pas — il mesure la latence et le taux d’erreur, pas le déplacement d’une distribution.

La partie droite du schéma est du territoire connu : Docker fabrique l’image, Kubernetes la fait tourner, avec un Deployment et un Service. Un modèle servi par FastAPI dans un conteneur ne demande rien de particulier au cluster, et c’est une bonne nouvelle : l’infrastructure ne sait pas qu’elle héberge un modèle.

Où commencer, honnêtement

L’erreur la plus coûteuse est de construire la boucle complète avant d’avoir un modèle qui sert à quelque chose. Une progression réaliste :

Niveau 0 — le carnet manuel. Tout se fait à la main, le modèle est déployé une fois. C’est acceptable pour valider qu’un modèle a de la valeur, et inacceptable dès qu’il en a.

Niveau 1 — l’entraînement reproductible. Un script versionné, remplaçable par une commande, avec suivi des expériences et un registre. Le déploiement reste déclenché par un humain. C’est le niveau dont la plupart des équipes ont besoin, et beaucoup s’arrêtent là très légitimement.

Niveau 2 — la boucle automatisée. Réentraînement planifié, évaluation automatique, promotion sous condition, surveillance qui déclenche. Utile quand le phénomène bouge vite ou quand les modèles sont nombreux.

Et l’avertissement qui va avec : passer au niveau 2 sans surveillance en place est un recul, pas un progrès. Un système qui promeut automatiquement des modèles sans savoir mesurer leur dégradation industrialise l’erreur au lieu du travail.

Ce qu’il faut retenir

La phrase à garder :

Le MLOps est la façon d’industrialiser l’apprentissage automatique. MLflow est un outil qui aide à en mettre en œuvre certaines parties.

Le test qui tranche, devant n’importe quelle discussion d’architecture : demandez qui décide de promouvoir un modèle, à quelle condition, et comment on revient en arrière. Si les réponses existent, il y a du MLOps — quels que soient les outils. Si elles n’existent pas, aucun outil ne les fournira.

Pour la suite : le suivi des expériences pour la première brique, l’instrumentation d’un script réel pour la mettre en œuvre, et quand et comment réentraîner pour la décision qui fait tourner la boucle.