MLflow

MLflow est une plateforme open source permettant de gérer l'intégralité du cycle de vie du machine learning, du suivi des expérimentations jusqu'au déploiement des modèles et à la surveillance en production. Conçue à l'origine par les ingénieurs de Databricks et lancée en juin 2018, elle a été cédée à la Linux Foundation en juin 2020 et fonctionne désormais comme un projet open source neutre sous licence Apache 2.0. Avec plus de 30 millions de téléchargements mensuels et 20 000 étoiles GitHub grâce à la contribution de plus de 900 développeurs, c'est la plateforme MLOps la plus adoptée dans les environnements d'entreprise, utilisée par des sociétés du Fortune 500 et des milliers d'organisations concevant des systèmes de ML en production.

La plateforme couvre quatre domaines principaux : le suivi des expérimentations (enregistrement des paramètres, des métriques et des artefacts lors des exécutions d'entraînement), un registre de modèles (gestion des versions, environnements de test et workflows d'approbation pour la promotion des modèles), le déploiement de modèles (packaging vers Docker, API REST, Kubernetes et des plateformes cloud telles que AWS SageMaker et Azure ML) et, depuis MLflow 3, l'observabilité GenAI de niveau production. MLflow 3 a ajouté le traçage basé sur OpenTelemetry pour les applications LLM, l'évaluation LLM-as-a-judge, un Prompt Registry avec comparaison des versions, la prise en charge du streaming via la classe ResponsesAgent, et des intégrations de traçage automatique pour PydanticAI, smolagents et plus de 20 frameworks GenAI. Il prend en charge Python, TypeScript, JavaScript, Java et R, et fonctionne avec toutes les principales bibliothèques de ML, notamment PyTorch, TensorFlow, scikit-learn, XGBoost et LightGBM. Vous pouvez l'associer à Databricks Mosaic AI pour un déploiement entièrement géré ou l'exécuter de manière totalement auto-hébergée sur votre propre infrastructure.

Ce que fait réellement MLflow en mai 2026

MLflow 3, lancé le 11 juin 2025, a marqué un tournant, passant d'un simple registre d'expérimentations à une plateforme complète d'ingénierie IA. L'architecture de base est passée d'un modèle centré sur l'exécution (run) à un modèle centré sur le LoggedModel, où les modèles sont des entités de premier plan connectées aux exécutions, traces, prompts et métriques d'évaluation qui les ont façonnés. Cela facilite considérablement la comparaison des variantes de modèles entre les expérimentations, le suivi du lignage depuis les données d'entraînement jusqu'au déploiement en production en passant par l'évaluation, et la gestion de l'historique des versions des agents GenAI avec la même rigueur que celle auparavant réservée aux modèles de ML classique.

Du côté du ML classique, le workflow est bien établi. Un data scientist installe MLflow avec un simple pip install mlflow, appelle mlflow.sklearn.autolog() avant l'entraînement, et chaque hyperparamètre, métrique et artefact de cette exécution est automatiquement capturé. L'interface de suivi permet ensuite aux équipes de comparer des centaines d'exécutions côte à côte, de filtrer par seuils de métriques et d'enregistrer le meilleur modèle dans le Model Registry en un seul clic. À partir de là, les modèles passent par les étapes de test (staging) et de production avec des portails d'approbation, puis se déploient sous forme de points de terminaison REST, de conteneurs Docker ou de tâches d'inférence par lots.

Les capacités GenAI introduites dans MLflow 3 répondent à un problème que l'architecture d'origine n'avait jamais anticipé : le débogage à grande échelle du comportement non déterministe des agents. Le système de traçage, basé sur OpenTelemetry, capture chaque prompt, appel d'outil, étape de récupération et réponse du LLM dans une trace structurée. Lorsqu'un agent hallucine ou échoue, les ingénieurs rejouent la trace complète dans l'interface utilisateur pour identifier l'étape exacte où le contexte a posé problème. Le système de juge LLM fournit des évaluateurs basés sur la recherche pour mesurer systématiquement la qualité du texte libre, y compris l'évaluation des conversations à plusieurs tours ajoutée dans MLflow 3.10 (février 2026) et la surveillance continue avec des alertes "judge-in-the-loop" ajoutées dans la version 3.9 (janvier 2026).

"Le traçage de MLflow 3.0 a été essentiel pour faire évoluer notre plateforme de sécurité basée sur l'IA. Il nous offre une visibilité de bout en bout sur chaque décision du modèle, ce qui nous aide à déboguer plus rapidement, à surveiller les performances et à garantir que nos défenses évoluent en même temps que les menaces." - Sam Chou, Ingénieur Principal chez Barracuda Networks, blog Databricks, juin 2025

"MLflow 3.0 nous a donné la visibilité dont nous avions besoin pour déboguer et améliorer nos agents de questions-réponses en toute confiance. Ce qui prenait auparavant des heures de conjectures peut désormais être diagnostiqué en quelques minutes." - Daisuke Hashimoto, Tech Lead chez Woven by Toyota, blog Databricks, juin 2025

Où se situe MLflow par rapport à Weights and Biases et Comet ML

Weights and Biases est le concurrent le plus direct pour le suivi des expérimentations, mais les deux outils sont architecturalement opposés sur l'axe de l'hébergement. W&B est un SaaS orienté cloud : toutes les données d'expérimentation se synchronisent sur les serveurs de W&B en temps réel, ne nécessitant aucun travail d'infrastructure. MLflow est auto-hébergé par défaut, ce qui signifie que les équipes possèdent entièrement leurs données, mais gèrent également la base de données, le stockage des artefacts, la configuration de l'authentification et le processus de mise à jour. La couche de visualisation de W&B est également nettement plus performante : elle propose des graphiques en coordonnées parallèles, des projecteurs de plongements (embeddings), des matrices de confusion et des rapports de type recherche partageables pour les parties prenantes non techniques. L'interface utilisateur de MLflow propose des graphiques linéaires et des histogrammes de base. Pour l'optimisation des hyperparamètres, W&B inclut Sweeps, un système d'optimisation bayésienne intégré ; MLflow n'a pas d'équivalent natif et s'appuie sur des bibliothèques externes comme Optuna ou Ray Tune. Le compromis financier est direct : le forfait Team de W&B coûte 50 $ par utilisateur et par mois, tandis que MLflow est gratuit mais nécessite un budget d'infrastructure et des heures de DevOps. Les équipes ayant investi dans Databricks associent souvent MLflow à Anyscale pour les charges de travail d'entraînement distribué, conservant les données d'expérimentation en interne tout en faisant évoluer la puissance de calcul en externe.

Comet ML occupe un terrain d'entente. Comme W&B, il est orienté cloud avec des tableaux de bord interactifs en temps réel, des graphiques en coordonnées parallèles et des outils de collaboration qui manquent à MLflow par défaut. Là où Comet se différencie mécaniquement, c'est dans le lignage des artefacts : la couche d'artefacts de Comet suit explicitement quelles expérimentations ont produit et consommé chaque jeu de données ou artefact de modèle, maintenant la provenance au niveau de l'artefact plutôt qu'au niveau de l'exécution. Le lignage de MLflow se fait au niveau de l'exécution ; pour obtenir un lignage au niveau des artefacts dans MLflow, vous avez besoin de l'intégration Databricks Unity Catalog, qui nécessite le niveau géré. Comet propose également le service de modèles basé sur une API REST comme voie de déploiement légère ; le modèle de déploiement de MLflow est plus riche (Docker, Kubernetes, SageMaker, MLServer) mais plus lourd en infrastructure. Pour les équipes explorant le service de modèles sans orchestration complète, BentoML offre une couche de déploiement complémentaire qui fonctionne bien avec le registre de MLflow. Les équipes évaluant les workflows de fine-tuning utilisent souvent MLflow aux côtés de Predibase, qui gère le fine-tuning basé sur LoRA et intègre le suivi des expérimentations dans des registres compatibles avec MLflow.

À quoi ressemble la réalité du workflow MLflow

Pour une équipe qui part de zéro, la configuration du suivi des expérimentations est véritablement rapide : installez, configurez une URI de suivi pointant vers une base de données PostgreSQL et un bucket S3, et les premières exécutions commencent à apparaître dans l'interface utilisateur en quelques minutes. Les difficultés commencent à grande échelle et aux limites de l'ensemble des fonctionnalités.

La complexité de l'auto-hébergement est le point de friction le plus constant. Au-delà du tracker local basé sur des fichiers, une configuration MLflow de niveau production nécessite un backend de base de données relationnelle (PostgreSQL ou MySQL), un stockage d'objets pour les artefacts, une configuration réseau pour l'accès multi-utilisateurs et une forme d'authentification. La version open source n'a pas de RBAC intégré ; l'accès en équipe multi-utilisateurs est soit ouvert par défaut, soit nécessite un proxy d'authentification personnalisé. Les équipes sans ingénieurs d'infrastructure dédiés se retrouvent fréquemment à passer des jours sur ce qu'elles pensaient prendre des heures.

L'interface utilisateur est un autre rappel à la réalité. Elle est fonctionnelle et suffisante pour la comparaison d'expérimentations individuelles, mais elle ne prend pas en charge les commentaires d'équipe, les rapports partagés ou le type de documentation narrative que permet la fonctionnalité Reports de W&B. Une équipe de data science présentant l'évaluation d'un modèle à des parties prenantes non techniques devra exporter les résultats ailleurs. L'API de requête, quant à elle, a fait l'objet de plaintes récurrentes : les expérimentations stockées dans un backend SQL ne peuvent pas être interrogées directement avec SQL, ce qui frustre les ingénieurs qui s'attendent à un accès natif à la base de données pour leurs propres données.

Une fois ces obstacles de configuration surmontés, la profondeur de MLflow en tant que plateforme de cycle de vie est difficile à égaler en open source. Les transitions de test et de production du Model Registry avec des workflows d'approbation, combinées à l'ajout dans MLflow 3.11.1 (avril 2026) de l'identification automatique des problèmes pour détecter les régressions de qualité dans les agents déployés, offrent aux équipes d'entreprise une gouvernance des modèles prête pour l'audit sans frais d'abonnement à un fournisseur. AWS SageMaker, Azure ML et Google Vertex AI proposent tous une intégration native de MLflow pour un suivi géré, ce qui élimine la majeure partie du fardeau de l'auto-hébergement pour les équipes déjà sur des plateformes de ML cloud.

À qui s'adresse MLflow

MLflow convient aux équipes pour lesquelles la propriété des données et le contrôle de l'infrastructure sont non négociables : les secteurs réglementés (santé, finance, défense) qui ne peuvent pas envoyer de données d'entraînement à des plateformes SaaS tierces, et les entreprises qui ont déjà développé la capacité DevOps pour exécuter leurs propres services. C'est le choix par défaut pour toute équipe travaillant sur Databricks, où Managed MLflow est inclus et où Unity Catalog fournit une gouvernance des modèles sans outillage supplémentaire. Les équipes concevant à la fois des pipelines de ML classique et des applications GenAI bénéficient de la plateforme unifiée de MLflow 3 : le même outil qui suit la recherche d'hyperparamètres d'un modèle à boosting de gradient peut désormais tracer un agent LLM à plusieurs étapes et évaluer la qualité de ses résultats avec des métriques de juge. Les chercheurs et les ingénieurs ML des entreprises ayant investi dans Databricks trouveront également qu'il s'intègre naturellement avec Databricks Mosaic AI pour les workflows de fine-tuning et de service de modèles de fondation.

Les chiffres d'adoption racontent une histoire cohérente. Trente millions de téléchargements mensuels n'est pas un hasard ; cela reflète à quel point MLflow s'est ancré dans la chaîne d'outils ML Python comme la voie de la moindre résistance pour l'enregistrement des expérimentations. Les universités enseignant des cours MLOps, les fournisseurs de cloud concevant des plateformes ML gérées et les équipes de données d'entreprise se standardisant sur Databricks adoptent tous MLflow par défaut comme registre partagé et couche de suivi. Cette force d'attraction en fait un choix par défaut raisonnable même pour les équipes qui pourraient préférer l'interface utilisateur de W&B, car l'alignement organisationnel et les intégrations existantes l'emportent souvent sur la préférence pour le produit. Les équipes associant MLflow à une plateforme de fine-tuning comme Predibase obtiennent un cycle de vie complet, du fine-tuning basé sur LoRA jusqu'au registre de production, sans quitter l'écosystème open source. Ceux qui optimisent l'efficacité du service LLM en parallèle de la gouvernance des expérimentations peuvent combiner le registre de MLflow avec BentoML pour une pile de déploiement auto-hébergée qui reste entièrement sous leur contrôle.

Ce que MLflow n'est pas

MLflow n'est pas une solution clé en main pour les petites équipes sans ressources d'infrastructure. Si votre équipe souhaite que le suivi des expérimentations fonctionne en dix minutes sans configurer de bases de données ni de stockage d'objets, Weights and Biases ou Comet ML vous conviendront mieux. Ce n'est pas un outil d'optimisation des hyperparamètres : il n'y a pas d'équivalent intégré à W&B Sweeps, et l'intégration avec des optimiseurs externes nécessite une configuration supplémentaire. Ce n'est pas un orchestrateur de pipelines : MLflow ne planifie pas les tâches d'entraînement, ne gère pas les pipelines de données et ne coordonne pas les workflows à plusieurs étapes comme le font Airflow ou Prefect. Les équipes s'attendant à une couche de collaboration complète avec des rapports partageables et des commentaires d'équipe seront déçues par l'interface utilisateur open source. Et malgré les ajouts GenAI de MLflow 3, les équipes concevant principalement des applications LLM sans aucune charge de travail de ML classique pourraient trouver que Langfuse ou des outils d'observabilité LLM similaires et spécialisés sont plus adaptés. La divulgation de sécurité de JFrog de décembre 2024 (CVE-2024-27132, CVSS 7.2) a également souligné que les instances MLflow auto-hébergées exécutant des recettes non fiables peuvent être exposées à une exécution de code à distance côté client via XSS, une préoccupation pour les équipes acceptant des soumissions de modèles externes ou exécutant des environnements de notebooks partagés.