Le MLOps est une culture avant d’être un outil

Il existe une tentation très compréhensible dans les projets d’intelligence artificielle : installer un outil de MLOps, enregistrer quelques métriques et déclarer que les expériences sont désormais reproductibles. À mon avis, c’est commencer par le mauvais bout.

Le MLOps — Machine Learning Operations — ne se réduit pas à une plateforme. C’est une manière de faire travailler ensemble les personnes qui préparent les données, écrivent le code, entraînent le modèle et exploitent le service. L’outil rend les pratiques visibles ; il ne les invente pas.

Reproductible pour qui ?

Avant d’ajouter un système de experiment tracking, il faut répondre à une question souvent oubliée : qui doit pouvoir reprendre l’expérience ? Le chercheur qui veut comparer une hypothèse, l’ingénieur qui doit corriger un pipeline ou l’équipe métier qui veut comprendre une décision n’ont pas besoin des mêmes informations.

Un run bien documenté devrait au moins relier le code, la version des données, les paramètres, les métriques, les artefacts et l’environnement. Mais la documentation doit aussi expliquer l’hypothèse testée. Sans cette phrase, une suite de chiffres devient difficile à interpréter, même si elle est techniquement complète.

L’outil ne remplace pas le jugement

MLflow, DVC, Git ou un Model Registry sont utiles parce qu’ils structurent les traces. Pourtant, une équipe peut enregistrer des centaines de runs sans apprendre quoi que ce soit si elle ne sait pas lesquels comparer et pourquoi promouvoir un modèle.

Je préfère une équipe qui conserve dix expériences compréhensibles à une équipe qui en conserve mille sans contexte. Le critère important n’est pas le volume de logs ; c’est le temps nécessaire pour répondre à trois questions : qu’avons-nous essayé, qu’avons-nous appris et pourquoi cette version a-t-elle été retenue ?

Le coût caché de la reproductibilité

La reproductibilité a un coût : stockage des artefacts, versionnement des données, tests de pipeline, temps de rédaction et maintenance des environnements. Il faut donc choisir le niveau de preuve adapté au risque.

Pour une exploration pédagogique, un fichier requirements.txt, un seed et une note de contexte peuvent suffire. Pour un service qui influence des personnes, il faudra aussi un audit trail, des tests de dérive, une procédure de rollback et une responsabilité clairement attribuée.

Ma position

Le premier livrable MLOps ne devrait pas être un dashboard. Ce devrait être un accord d’équipe : quelles informations sont obligatoires pour déclarer une expérience terminée, qui vérifie ces informations et quelles conditions permettent de mettre un modèle en production ?

Les outils viendront ensuite. Ils seront plus simples à choisir, parce que l’équipe saura enfin quel problème elle cherche à résoudre. Le MLOps commence donc moins par l’infrastructure que par une discipline collective de la preuve.

Éviter le MLOps cérémoniel

Il existe un risque inverse : transformer chaque expérience en formulaire interminable. Une équipe peut remplir des champs obligatoires, produire des dashboards et respecter un workflow sans mieux comprendre ses modèles. Ce MLOps cérémoniel donne l’apparence de la rigueur sans produire de décision plus fiable.

La règle devrait être simple : chaque métadonnée obligatoire doit répondre à une question future. Si le commit permet de retrouver le code, si la version du dataset explique une différence et si la métrique correspond à une décision métier, le champ a une utilité. Sinon, il faut le supprimer ou le rendre optionnel.

Un bon test consiste à demander à une personne absente du projet de reprendre un run. Si elle peut expliquer le résultat et reproduire les étapes principales, la pratique fonctionne. Si elle ne fait que consulter un écran, l’outil a pris la place de la méthode.