MLflow : maîtrise le suivi de tes expériences ML (Partie 1)

Dans la plupart des projets ML que je croise, il n'existe aucun système dédié au suivi des expériences. Un tel système enregistre deux choses :

…et ce, sur toutes tes expériences.

Le plus souvent, tout se passe dans un notebook Jupyter, sans protocole automatisé de suivi : la configuration des modèles et le suivi des données sont gérés à la main.

Les résultats sont recopiés dans un Google Sheet ou un document texte. Ça tient quelques jours, puis tu ne sais plus quel jeu d'hyperparamètres a produit ton meilleur score.

MLflow règle ce problème. C'est un outil open source qui s'utilise aussi bien en local, pour toi seul, que sur un serveur partagé pour toute une équipe, et qui s'intègre à la plupart des services cloud.

Ce mini-cours est publié en deux volets. Tu vas brancher MLflow sur un vrai projet scikit-learn et automatiser tout ce que tu notes aujourd'hui à la main. Ce premier volet couvre les composants de MLflow, le vocabulaire (expérience, run), ta première démo instrumentée, la façon dont MLflow range tes résultats, son interface web, puis la gestion de plusieurs runs et de plusieurs expériences. Le second volet traite l'autologging, le serveur de tracking partagé, les modèles, le Model Registry et les Projects.

🧪 Testé avec MLflow 3.18, scikit-learn 1.9 et Python 3.13 (novembre 2026).

Si tu veux d'abord l'idée générale en version courte, elle est dans ce shot :

Avant d'entrer dans le détail technique, prenons le temps de comprendre ce que MLflow vient résoudre. Les approches classiques en ML sont encore largement manuelles, et trois difficultés reviennent dans presque tous les projets.

Un projet ML ne se résume pas à du code : il faut aussi versionner les modèles et les données, et le tout doit rester cohérent. Sans méthode, tu perds la capacité de reproduire un résultat, de suivre les changements dans le temps et de garantir la cohérence entre les étapes du projet.

Le symptôme typique : un dossier plein de data.csv, data1.csv, data2.csv, data_final.csv, et la question que tout le monde finit par se poser, « avec quel fichier ai-je entraîné ce modèle ? ». La réponse n'existe nulle part, sauf dans la mémoire de quelqu'un.

Pour les données, c'est exactement le sujet du mini-cours sur DVC :

Dans un workflow classique, suivre et gérer à la main les paramètres et les données est un vrai défi : c'est un processus sujet aux erreurs, long, et sans traçabilité. On finit presque toujours par consigner les configurations de paramètres et les sources de données dans des tableurs ou des documents.

Cette approche freine l'efficacité, et elle empêche de tenir un historique complet des expériences. Impossible de savoir ce qui a été essayé, avec quelles données, ni de reproduire et valider un résultat après coup.

Dans les environnements ML classiques, la collaboration se heurte à l'absence d'outils centralisés et de pratiques standardisées. Les membres de l'équipe travaillent le plus souvent chacun dans leur coin, et partager un modèle, une expérience ou un résultat devient pénible.

Faute de plateforme unifiée, les efforts restent cloisonnés : la connaissance circule mal, le cycle de développement ralentit et l'équipe avance moins vite que la somme de ses membres.

À cela s'ajoutent des déploiements incohérents, des problèmes de passage à l'échelle et l'absence de structure de projet standard. Résoudre ces problèmes est la condition d'un ML efficace, scalable et reproductible.

La bonne nouvelle : ces trois problèmes se règlent très bien avec des pratiques MLOps standard. Elles aident à construire, entraîner, déployer et même automatiser les différentes étapes d'un projet ML, avec très peu d'intervention manuelle. MLflow, entièrement open source, en est l'une des meilleures portes d'entrée.

MLflow est entièrement open source et couvre le cycle de vie complet d'un projet ML. Concrètement, il permet de :

Pour le ML classique, MLflow s'organise autour de quatre composants :

Pour l'IA générative, MLflow ajoute deux briques : l'AI Gateway, qui centralise l'accès aux fournisseurs de LLM (OpenAI, Anthropic…) et leur gestion, et l'évaluation des applications LLM avec mlflow.genai.evaluate. Elles sortent du cadre de ce mini-cours. En haut à gauche de l'interface web, un sélecteur sépare d'ailleurs GenAI et Model training : on reste sur Model training du début à la fin.

Chaque composant répond à un point précis du cycle de vie d'un projet ML, et tu les verras un par un dans ce mini-cours : le Tracking dans ce premier volet, puis les Models, le Model Registry et les Projects dans le second volet. Pour commencer, installe MLflow :

pip install mlflow

L'entraînement d'un modèle est un processus itératif : tu changes un hyperparamètre, tu testes une nouvelle feature, tu ajoutes des données, tu essaies un autre algorithme. Au bout de quelques jours, tu te retrouves avec tellement de combinaisons que retrouver la configuration exacte du meilleur modèle devient presque impossible, sauf si tu as tout noté à la main.

Imagine que tu retrouves un excellent score, par exemple 89,2 % d'accuracy, sans savoir comment tu l'as obtenu : quels hyperparamètres, quelles données, quelle version du code ?

Pourquoi ça compte ? Pour une raison principale : la reproductibilité. Elle est au cœur d'un ML fiable : indispensable pour collaborer et pour comparer des modèles à des moments ou dans des environnements différents. Un résultat qui marche sur ta machine et pas sur celle d'un collègue, c'est le symptôme d'une mauvaise reproductibilité.

Sans pratiques de reproductibilité solides, on ne peut ni répliquer ni valider les résultats de quelqu'un d'autre, ce qui entame la crédibilité du travail. MLflow Tracking les rend possibles en enregistrant les paramètres, la version du code et les dépendances utilisés pendant l'entraînement. Tout le déroulé peut ensuite être reconstitué à l'identique par quelqu'un d'autre.

Tu disposes aussi d'une interface web pour consulter les résultats de tes logs et les comparer. Elle tourne en local ou sur un serveur distant, ce qui facilite le partage des expériences entre équipes.

Une expérience est une collection nommée de runs. Elle sert à regrouper des exécutions liées entre elles, pour pouvoir les comparer facilement. Quand tu démarres une nouvelle expérience, MLflow lui crée un espace dédié.

Un run est une exécution unique de ton workflow d'entraînement, au sein d'une expérience. Il encapsule tout ce qui s'y est passé : le code, les paramètres, les métriques et les artefacts produits.

MLflow enregistre automatiquement pour toi les détails d'un run : les hyperparamètres utilisés, les métriques calculées pendant l'entraînement, et les fichiers ou modèles produits. Tout est ensuite accessible dans l'interface de MLflow ou par programmation, via l'API. C'est ce que tu vas voir tout de suite sur un exemple concret.

💡 En continuant, tu vas découvrir :