Le MLOps est une démarche. Un outil est un logiciel. Confondre les deux, c’est dire qu’on fait du DevOps parce qu’on a installé Jenkins.
La démarche, c’est l’ensemble des pratiques qui font qu’un modèle vit : on peut le reconstruire, le servir, le comparer à un champion, le retirer, le réentraîner, savoir qui l’a promu. Elle ressemble au DevOps par l’esprit — automatiser, versionner, raccourcir le délai entre une idée et un artefact fiable — et s’en distingue par une boucle que le logiciel classique n’a pas : les données continuent d’arriver, donc le système n’est jamais fini.
MLflow, un registre, un orchestrateur, un outil de surveillance : chacun couvre une portion. Aucun ne fait la démarche à votre place. On peut faire du MLOps sérieux avec peu d’outils, et n’en faire aucun avec tous les logos.
Que vous parlez de décisions, pas de stack.
Si vous répondez « on a mis MLflow », la question suivante sera : et le reste ? Le suivi d’expériences est un morceau. Le déploiement, l’astreinte, le contrat avec le métier, la collecte des étiquettes réelles n’arrivent pas avec le paquet Python.
« Donc il faut une plateforme MLOps. »
Pas forcément. Il faut les pratiques à l’échelle du risque. Un modèle lu une fois par mois dans un fichier peut vivre avec un script versionné, une date, et une revue. Un modèle dans un flux d’autorisation a besoin d’une chaîne, d’un propriétaire, d’un rollback. L’outil suit le besoin, pas l’inverse.
« C’est juste du DevOps avec des pickles. »
Non, parce que le comportement dépend d’un jeu de données qui n’est pas le code. Versionner le dépôt sans versionner les données, c’est versionner la recette et perdre les ingrédients.
Le développement de cette distinction est dans MLOps et MLflow : la démarche n’est pas l’outil.
La phrase à garder : le MLOps, c’est comment l’équipe décide ; l’outil, c’est comment elle consigne.