MlFlow, une plateforme opensource de Machine Learning pour des projets en Data Science optimisés

Mlflow a été présenté à l’occasion du Spark+AI Summit 2018. Il s’agit d’une plateforme open source développée par Databricks permettant de gérer le cycle de vie des modèles de Machine Learning.

MLflow permet aux Machine Learning Engineer, comme aux utilisateurs moins techniques, de suivre les informations liées à l’entraînement et à la mise en production des modèles de machine learning. Un autre des avantages de cette plateforme est qu’elle intègre des frameworks reconnus en machine learning tels que Scikit-Learn, PyTorch ou encore TensorFlow.

Qu’est-ce que MLflow et pourquoi l’utiliser ?

MLflow est une plateforme open source, développée par Databricks, qui permet de gérer le cycle de vie des modèles de Machine Learning. Présentée au Spark+AI Summit 2018, elle aide les Machine Learning Engineers comme les utilisateurs moins techniques à suivre les informations liées à l’entraînement et à la mise en production des modèles. Un atout clé est sa compatibilité avec des frameworks reconnus tels que Scikit-Learn, PyTorch et TensorFlow. MLflow couvre aussi les applications d’IA générative et les agents, avec des capacités de traçage, d’évaluation et d’observabilité.

Concrètement, MLflow centralise paramètres, métriques, artefacts et versions pour rendre les expériences comparables et reproductibles. Les équipes gagnent en vitesse d’itération, en collaboration et en traçabilité, tout en restant indépendantes des fournisseurs grâce à un écosystème ouvert et modulaire. Pour les data scientists et ML engineers, la valeur se mesure en temps gagné, en qualité de modèle mieux contrôlée et en déploiements plus fiables.

• Suivi d’expériences: enregistrer et comparer hyperparamètres, métriques, artefacts et résultats avec MLflow Tracking.
• Reproductibilité: structurer projets et dépendances avec MLflow Projects pour relancer une exécution à l’identique.
• Gestion et gouvernance des modèles: versionner, valider et promouvoir les modèles du brouillon à la production avec le Model Registry.
• Déploiement polyvalent: empaqueter les modèles avec MLflow Models et les servir en batch ou en temps réel, sur Docker, Kubernetes, Azure ML ou AWS SageMaker.
• LLM et agents: tracer les requêtes et étapes intermédiaires, évaluer la qualité et maîtriser les coûts grâce aux fonctions d’observabilité, d’évaluation, de gestion des prompts et à une passerelle unifiée pour les fournisseurs de LLM.
• Écosystème ouvert: open source sous licence Apache 2.0, intégrations larges avec les principaux frameworks et outils, sans verrouillage fournisseur.

Problématiques d’un projet Machine Learning

La réalisation d’un projet de Machine Learning (ML) est compliquée pour les équipes en science des données. Elles sont confrontées à plusieurs défis.

Tout d’abord, il y a de nombreux outils et versions différents utilisés depuis la préparation des données jusqu’à l’entraînement des modèles. Cela peut causer des problèmes de compatibilité et de gestion.

Ensuite, il est difficile de suivre et de comprendre comment les modèles de ML sont entraînés en raison de la multitude de paramètres possibles. Que vous travailliez seul ou en équipe, savoir exactement comment chaque modèle a été entraîné devient un casse-tête.

De plus, il est souvent difficile de réutiliser le code sans des instructions détaillées. Que vous partagiez votre code avec un développeur pour une utilisation en production ou que vous deviez revenir sur un projet antérieur pour le débugger, il est essentiel de pouvoir reproduire les étapes du processus de ML.

Enfin, mettre un modèle en production peut être compliqué en raison des nombreux outils de déploiement et des environnements variés requis, ainsi que le développement en continue du modèle avec l’intégration de nouvelles données. Cela ajoute une couche de complexité supplémentaire au processus global.

Douleurs fréquentes que MLflow aide à résoudre

• Perte d’historique des essais, métriques et hyperparamètres d’un entraînement.
• Incapacité à relancer une expérience à l’identique à cause des dépendances et des seeds non contrôlés.
• Absence de point central pour stocker modèles et artefacts, difficultés de comparaison.
• Passage du notebook à l’API servi en production long et fragile.
• Manque de gouvernance: pas de versions, pas de processus clair d’approbation et de promotion des modèles.

En synthèse : MLflow apporte un socle unique pour rendre vos travaux traçables, reproductibles et déployables, depuis l’idée testée en notebook jusqu’au service opérationnel.

Comment assurer la reproductibilité des expériences ?

La reproductibilité exige de figer les versions de code et de dépendances, de contrôler l’aléa (seeds) et de documenter précisément la commande d’exécution. MLflow Projects fournit une structure normalisée du projet (fichier MLproject, points d’entrée) et un environnement d’exécution déclaré (généralement via conda.yaml) pour relancer un entraînement à l’identique.

Enjeux	Leviers MLflow
Versions de code	Capture du commit Git (source version) dans les runs, exécution via mlflow run qui référence le dépôt.
Dépendances et OS	MLflow Projects avec conda.yaml (ou équivalent) pour figer packages et versions, environnement recréé à la volée.
Seeds aléatoires	Définir et logger un paramètre seed (ex. mlflow.log_param("seed", 42)) et l’appliquer dans le code.
Jeux de données	Enregistrer la référence des données (chemin, version) comme param/tag et déposer un manifest ou un échantillon en artifact.
Commande d’exécution	Points d’entrée du fichier MLproject avec paramètres typés, relance standardisée et traçable.

1. Structurer le dépôt avec un fichier MLproject et définir les entry_points.
2. Déclarer l’environnement dans conda.yaml et vérifier la création locale.
3. Initialiser les seeds dans le code, logger seed et versions de données.
4. Lancer l’entraînement avec mlflow run . -P param=valeur.
5. Contrôler dans l’UI MLflow la version de code, l’environnement et les artefacts.

Comment tracer métriques, hyperparamètres et artefacts ?

MLflow Tracking est l’interface pour enregistrer et visualiser tout ce qui compte pendant vos expériences. Vous organisez votre travail par experiment, puis chaque exécution crée un run qui regroupe paramètres, métriques, tags et artefacts.

• Experiments : dossiers logiques pour un projet.
• Runs : exécutions individuelles horodatées.
• Params : hyperparamètres et constantes d’entraînement.
• Metrics : résultats chiffrés, éventuellement enregistrés au fil des itérations.
• Tags : métadonnées libres pour filtrer et retrouver les runs.
• Artifacts : fichiers produits (modèles, graphiques, rapports, configurations).

Exemple : pour un classifieur scikit-learn, loggez C, max_depth en params, accuracy et auc en metrics à la fin ou à chaque epoch, une matrice de confusion en image comme artifact, et le modèle sérialisé avec log_model. Vous pourrez ensuite comparer les runs dans l’UI et sélectionner la meilleure configuration.

Comment versionner et gouverner les modèles ?

Sans gouvernance, il est difficile de savoir quel modèle peut être promu, par qui et sous quelles conditions. MLflow Model Registry centralise les modèles, garde l’historique des versions et facilite les transitions contrôlées entre environnements.

• Versions : chaque enregistrement de modèle crée une version traçable avec ses métadonnées.
• Stages : états standards (Staging, Production, Archived) pour refléter le cycle de vie.
• Approbations et commentaires : description, tags et discussions pour formaliser revues, validations et motifs de promotion.

En pratique : après sélection d’un run gagnant, enregistrez le modèle dans le Registry, créez une nouvelle version, attachez un rapport d’évaluation en artifact, puis promouvez en Staging pour tests d’intégration. Une fois validé métier et qualité, transitionnez en Production, tout en archivant l’ancienne version.

Comment passer du notebook à la production ?

Un notebook sert à explorer et itérer vite, la production exige des modèles packagés, des interfaces stables et une observabilité minimale. MLflow Models empaquète vos modèles dans des flavors standardisés et permet de les servir en local ou dans le cloud, avec intégrations vers Docker, Kubernetes, Azure ML ou AWS SageMaker.

1. Logger le modèle au format MLflow approprié (ex. scikit-learn, PyTorch), avec l’environnement capturé.
2. Enregistrer ce modèle dans le Model Registry pour créer une version officielle.
3. Valider en Staging via tests d’intégration et jeux de validation, documenter les résultats.
4. Déployer : servir en REST avec mlflow models serve ou via conteneurisation et services managés (ex. Azure ML, SageMaker).
5. Surveiller : tracer métriques d’inférence, conserver les artefacts de suivi et planifier les réentraînements.

Explication : le format MLflow garantit que le même package (code, dépendances, poids) est utilisé de bout en bout, ce qui réduit les écarts entre environnement de développement et production, et accélère les cycles de mise à jour contrôlés.

Architecture et composants de MLflow

MLflow est une plateforme open source développée par Databricks pour gérer le cycle de vie des modèles de machine learning, du suivi des expériences jusqu’à la mise en production. Elle peut être utilisée localement pour un usage individuel, ou déployée côté serveur pour un usage collaboratif. Dans une installation typique, des clients MLflow (scripts, notebooks, pipelines) envoient leurs journaux au Tracking Server, qui persiste les métadonnées dans un backend store et dépose les artefacts dans un artifact store, tandis que l’interface web permet de visualiser et comparer les exécutions. MLflow s’intègre à des frameworks reconnus comme Scikit-Learn, PyTorch ou TensorFlow, ce qui facilite son adoption dans des environnements hétérogènes.

Composant	Rôle	Interactions et hébergement typiques
MLflow UI	Interface web pour explorer expériences, runs, métriques, paramètres et artefacts, comparer les modèles et suivre leur historique.	Servie par le Tracking Server. Accède en lecture au backend store et à l’artifact store.
MLflow Tracking Server	Point central qui expose l’API et orchestre la persistance des informations de tracking.	Reçoit les appels des clients MLflow, écrit les métadonnées dans le backend store, référence et lit les artefacts dans l’artifact store. Déployé en local, sur serveur on-premise ou dans le cloud.
Backend store	Base de données des métadonnées: expériences, runs, paramètres, métriques, tags, liaisons de modèles.	SQLite pour le développement local, MySQL ou PostgreSQL pour un serveur multi-utilisateurs. Le Tracking Server y lit et écrit en continu.
Artifact store	Dépôt de fichiers produits par les runs: modèles, graphiques, logs, jeux de données dérivés.	Système de fichiers local, stockage objet de type S3, Azure Blob ou Google Cloud Storage. Le Tracking Server publie et référence les emplacements d’artefacts.
Model Registry	Catalogue central pour versionner les modèles et gérer leurs états (Staging, Production, Archived) avec commentaires et historique.	S’appuie sur le backend store et référence des artefacts dans l’artifact store. Favorise la collaboration et la gouvernance en équipe.

Quels sont les composants clés (UI, Tracking Server, stores) ?

Le cœur de MLflow repose sur la séparation entre service, métadonnées et fichiers, ce qui simplifie l’installation et l’hébergement à différentes échelles.

• MLflow UI: permet d’explorer les expériences, filtrer et comparer les runs, inspecter paramètres et métriques, télécharger ou prévisualiser les artefacts, et consulter l’historique des modèles.
• MLflow Tracking Server: service central auquel les clients envoient paramètres, métriques et artefacts. Il expose l’API et sert l’interface web. On le configure avec une base de données pour le backend store et un répertoire ou un bucket pour l’artifact store.
• Backend store: stocke toutes les métadonnées des expériences et des modèles. En local, une base légère suffit, alors qu’en production on privilégie une base SQL robuste pour la concurrence et la durabilité.
• Artifact store: stocke les fichiers associés aux runs, par exemple les modèles enregistrés via MLflow Models, les figures d’évaluation, les logs ou les jeux de données préparés.
• Model Registry (optionnel mais recommandé en équipe): permet de promouvoir un modèle d’un état à l’autre, de tracer les versions, d’ajouter des commentaires et de normaliser les déploiements vers les environnements cibles.

Quelles interfaces: Python, R, CLI, REST ?

MLflow est pensé pour être accessible depuis différents environnements. Les équipes peuvent consigner et interroger leurs expériences via des SDK, la ligne de commande ou une API REST, ce qui facilite l’intégration dans des notebooks, des scripts, des jobs CI/CD et des services applicatifs.

Interface	Usages typiques
Python	Définir l’URI de tracking, créer une expérience, démarrer un run, logger paramètres et métriques, consigner des artefacts et des modèles, activer l’autologging avec des frameworks comme Scikit-Learn, PyTorch ou TensorFlow, charger ou enregistrer un modèle dans le Registry.
R	Actions équivalentes au SDK Python: créer expériences et runs, logger paramètres, métriques et artefacts, interagir avec l’UI et le Registry depuis des scripts R ou R Markdown.
CLI	Lancer le serveur ou l’UI, gérer expériences et runs, empaqueter et servir des modèles, automatiser des tâches de suivi dans des pipelines CI/CD.
REST	Intégration language-agnostic: créer runs, consigner paramètres, métriques et lots d’événements, rechercher des runs, interagir avec le Model Registry depuis des services, des agents ou des applications tierces.

Comment démarrer avec MLflow en 3 étapes ?

MLflow permet aux équipes de suivre les paramètres, métriques et artefacts produits lors des expériences de Machine Learning, puis de comparer et déployer les meilleurs modèles. Voici un mini tutoriel reproductible pour passer de zéro à une interface de suivi opérationnelle en quelques minutes.

1. Installation locale
2. Lancer le serveur de tracking
3. Logger votre premier run

Installation locale

1. Avec pip
   

   # 1) Créer et activer un environnement Python 3.10+
   python -m venv .venv
   # macOS/Linux
   source .venv/bin/activate
   # Windows PowerShell
   .venv\Scripts\Activate.ps1
   
   # 2) Installer MLflow
   pip install -U pip mlflow
   

   MLflow côté PyPI indique un prérequis Python 3.10 ou plus récent. Voir la fiche PyPI.

2. Avec conda
   

   # 1) Créer un environnement
   conda create -n mlflow-demo python=3.10 -y
   conda activate mlflow-demo
   
   # 2) Installer MLflow
   conda install -c conda-forge mlflow -y
   

   Paquet conda-forge mlflow.

3. Vérifier l’installation
   

   mlflow --version
   python -c "import mlflow, sys; print('MLflow', mlflow.__version__, '| Python', sys.version)"
   

Astuce pratique: si vous travaillez derrière un proxy ou un antivirus d’entreprise, autorisez le port local utilisé par l’UI de MLflow afin d’afficher l’interface dans votre navigateur.

Lancer le serveur de tracking

Démarrez un serveur MLflow local qui expose l’API de tracking et l’UI. Cette commande lance un serveur prêt à l’emploi sur votre machine.

• Commande:

  mlflow server

• Port par défaut: 5000
• UI: http://localhost:5000

Vous pouvez changer le port si nécessaire. mlflow server --port 5050. Documentation Self-hosting et CLI MLflow.

Logger votre premier run

Voici un exemple minimal en Python qui enregistre un paramètre, des métriques au fil des étapes, puis un petit artefact texte. Exécutez ce script pendant que le serveur local tourne.

Rendez-vous sur l’UI à l’adresse ci-dessus pour comparer vos exécutions, explorer les métriques et télécharger les artefacts. La documentation officielle rappelle que l’UI locale est accessible sur le port 5000 par défaut. Guide de démarrage MLflow.

Les différents outils de MLflow

Pour répondre aux principales problématiques d’un projet ML, MLflow réunit quatre briques complémentaires que l’on peut utiliser séparément ou ensemble : Tracking pour suivre les expériences, Projects pour la reproductibilité, Models pour emballer et servir les modèles, et le Model Registry pour gérer leur cycle de vie et leurs versions.

MLflow Tracking

MLflow Tracking fournit une interface et des API pour enregistrer et visualiser les expériences menées lors de l’entraînement de modèles. Vous conservez une trace claire des itérations, comparez les configurations et documentez vos résultats.

Principales entités et usages :

• Experiments : dossiers logiques regroupant l’ensemble des essais d’un même projet.
• Runs : exécutions individuelles rattachées à un experiment.
• Params : hyperparamètres et configurations enregistrés avec mlflow.log_param(s).
• Metrics : métriques de performance loggées avec mlflow.log_metric, visualisables dans l’UI pour comparer les runs.
• Tags : métadonnées libres pour enrichir la traçabilité, par exemple la version de code ou le jeu de données.
• Artifacts : fichiers produits par un run : modèles, graphiques, rapports, notebooks, etc., via mlflow.log_artifact(s).

Depuis le code, on définit l’URI du serveur de tracking, l’expérience, puis on démarre un run pour journaliser paramètres, métriques et artefacts. L’UI MLflow permet ensuite de filtrer, comparer des runs et d’inspecter les détails d’un essai.

Bonnes pratiques : centraliser l’experiment par problématique, utiliser des tags pour relier code et données, activer l’autologging lorsque disponible (mlflow.autolog()), consigner systématiquement jeux de données et graphiques de validation, et fixer une nomenclature de runs claire pour faciliter la comparaison.

MLflow Projects

MLflow Projects standardise la structure d’un projet pour garantir la reproductibilité et simplifier l’exécution locale ou distante. Un projet est défini par un fichier MLproject qui décrit l’environnement et les points d’entrée.

Exemple minimal de fichier MLproject :

On exécute ensuite le projet avec mlflow run . -e train -P max_depth=6 en local, ou depuis un dépôt Git. L’environnement peut être Conda via conda.yaml ou venv, ce qui garantit que les dépendances sont identiques d’une machine à l’autre.

• Points clés : points d’entrée paramétrables, exécution locale ou distante, isolation des dépendances, intégration naturelle avec le Tracking pour conserver versions et résultats.
• Reproductibilité : le couple MLproject + environnement versionné permet de relancer un entraînement à l’identique.

MLflow Models

MLflow Models propose un format standardisé pour emballer, versionner et déployer des modèles ML sous différentes flavors, ce qui facilite leur portabilité vers divers environnements, y compris des services REST ou des plateformes cloud comme Azure ML et AWS SageMaker, ainsi que l’inférence sur Apache Spark.

• Flavors : scikit-learn, TensorFlow, PyTorch, XGBoost, LightGBM, Spark MLlib, et la flavor générique pyfunc pour une interface de prédiction unifiée.
• Signature d’E/S : description explicite des colonnes d’entrée et de la sortie, que l’on peut déduire avec mlflow.models.infer_signature au moment du logging.
• Entrées/Sorties : sérialisations prises en charge selon la flavor, prédiction via mlflow.pyfunc.load_model ou mlflow.<framework>.load_model.

En pratique, on sauvegarde un modèle avec mlflow.<framework>.log_model en fournissant éventuellement la signature et des artefacts associés, puis on le recharge localement pour tester les prédictions ou on le sert en REST avec mlflow models serve. Cette standardisation maintient un lien clair entre les modèles déployés et leur historique d’entraînement.

Qu’est-ce que le Model Registry ?

MLflow Model Registry est le référentiel central pour versionner les modèles, gérer leurs stages et orchestrer les transitions jusqu’à la production. Il offre une UI et des API pour documenter, commenter et gouverner les déploiements.

• Versions : chaque enregistrement de modèle possède des versions numérotées, liées à des runs et à leurs artefacts.
• Stages : Staging pour les validations pré‑production, Production pour le modèle actif en service, Archived pour les versions retirées.
• Transitions et approbations : passage d’un stage à l’autre avec historique, commentaires et règles d’approbation selon votre processus qualité.
• Webhooks : déclenchement automatisé de pipelines CI/CD lors d’événements du registre, par exemple tests, déploiements ou notifications.

En pratique, on promeut une version en Staging pour lancer les tests, puis en Production après validation, tout en archivant l’ancienne version. Cette démarche garantit traçabilité, retour arrière rapide et alignement entre équipes data, ML et produit.

Comment déployer et servir un modèle MLflow ?

Avec MLflow Models, les modèles sont packagés dans un format standardisé appelé flavors, ce qui facilite leur déploiement sous forme de service REST, en conteneur Docker, sur des plateformes cloud managées comme AWS SageMaker ou Azure ML, ou encore sur Kubernetes. Cette portabilité réduit la friction entre expérimentation et production, tout en gardant l’historique et les métadonnées depuis le tracking jusqu’au registre de modèles.

Quelles options de déploiement selon le besoin ?

Option de déploiement	Cas d’usage conseillé
Serveur local avec mlflow models serve	POC rapide, tests d’intégration, edge ou petite latence locale sans dépendance cloud.
Conteneur Docker	Portabilité maximale, CI/CD, exécution identique des environnements dev, préprod et prod.
Kubernetes	Scalabilité horizontale, haute disponibilité, contrôle fin des ressources et du réseau.
Managé cloud: SageMaker, Azure ML	Autoscaling, SLA, sécurité et observabilité intégrées, intégration IAM/réseau d’entreprise.
Batch sur Spark	Inférence à grande échelle hors ligne, traitements périodiques avec Apache Spark.

Quel rôle pour mlflow models serve et l’API REST ?

mlflow models serve expose un modèle MLflow au format pyfunc via un service HTTP local. C’est idéal pour le développement, l’inférence à la périphérie ou l’intégration simple avec une application existante. Le serveur fournit des endpoints REST standard et accepte des formats d’entrée centrés DataFrame pour des prédictions synchrones.

Exemple rapide

• Endpoints principaux:
  • GET /ping pour la vérification de liveness.
  • POST /invocations pour l’inférence synchronisée.

  Quelles intégrations cloud utiliser (SageMaker, Azure ML, Kubernetes) ?

  Le choix dépend de vos exigences en matière de scalabilité, de sécurité et d’opérations. Les plateformes managées délèguent l’infrastructure et apportent gouvernance et autoscaling. Kubernetes donne un contrôle maximal, au prix d’efforts d’exploitation plus élevés. MLflow s’intègre aux deux approches grâce à ses flavors et à son serveur d’inférence compatible REST.

  Plateforme	Avantages	Limites
  AWS SageMaker	Endpoints managés, autoscaling, GPU, intégration IAM, monitoring et A/B testing.	Coûts à surveiller, spécificités AWS, packaging d’image à respecter.
  Azure Machine Learning	Online endpoints managés, intégration Azure AD et réseau privé, MLOps avec registres et pipelines.	Couplage à l’écosystème Azure, quotas et politiques à configurer.
  Kubernetes	Portabilité cloud ou on‑prem, contrôle fin des ressources, intégration possible avec KServe ou Seldon.	Compétences SRE/DevOps nécessaires, observabilité et sécurité à assembler.

  Comment packager via Docker et pyfunc ?

  1. Définir le modèle au format pyfunc: logguez le modèle avec MLflow (mlflow.sklearn.log_model, mlflow.pyfunc.log_model ou un wrapper PythonModel). Enregistrez la signature d’entrée avec mlflow.models.infer_signature.
  2. Capturer l’environnement: laissez MLflow générer conda.yaml ou fournissez un requirements.txt pour garantir la reproductibilité.
  3. Construire l’image:

     mlflow models build-docker -m "models:/MonModele/Production" -n mon-image:latest
     

     L’image embarque le serveur d’inférence MLflow et vos dépendances.
  4. Exécuter et tester:

     docker run -p 8080:8080 mon-image:latest
     
     curl -X POST http://127.0.0.1:8080/invocations \
       -H "Content-Type: application/json" \
       -d '{"dataframe_split":{"columns":["f1","f2"],"data":[[1.2,3.4]]}}'
     

  5. Publier et déployer: poussez l’image dans votre registre, déployez-la sur Kubernetes, SageMaker ou Azure ML selon vos contraintes.

  Bonnes pratiques: centralisez vos modèles dans le Model Registry MLflow, utilisez des étapes Staging puis Production, automatisez la promotion et le déploiement via votre CI/CD, et conservez la même image entre environnements pour limiter les écarts.

  Mettre en production un modèle avec MLflow

  Hébergement et stockage: comment configurer MLflow en équipe ?

  Pour un usage d’équipe, l’objectif est de centraliser les expériences, garder les artefacts accessibles et sécuriser l’accès. Concrètement, on déploie un serveur MLflow partagé, on sépare le stockage des métadonnées du stockage des artefacts, on ajoute un proxy sécurisé, puis on équipe les utilisateurs d’une URL de suivi commune.

  • Serveur partagé: une instance MLflow accessible sur le réseau de l’entreprise, avec base SQL et stockage d’objets.
  • Stockage: base SQL pour les runs et métadonnées, stockage d’objets pour les modèles, figures, checkpoints.
  • Sécurité de base: HTTPS via reverse proxy, authentification simple, contrôle réseau et sauvegardes.
  • Ergonomie: même URL de suivi pour toute l’équipe, conventions de nommage des expériences et des projets.

  Quelle différence entre backend store et artifact store ?

  MLflow utilise deux stockages complémentaires. Le backend store conserve les métadonnées légères des expériences (expériences, runs, paramètres, métriques, tags, registre de modèles). L’artifact store conserve les fichiers volumineux produits par les runs, par exemple modèles, fichiers de poids, graphiques, notebooks ou données dérivées. On choisit généralement un SGBD pour le backend store, et un stockage d’objets cloud ou un partage réseau pour les artefacts.

  Type de store	Rôle	Exemples de configuration
  Backend store SQL	Métadonnées d’expériences et de modèles	PostgreSQL: postgresql://user:pass@host:5432/mlflow MySQL: mysql+pymysql://user:pass@host:3306/mlflow SQLite (dev): sqlite:///mlflow.db
  Backend store fichier	Métadonnées locales pour maquettes	--backend-store-uri ./mlruns (usage local uniquement)
  Artifact store S3	Fichiers lourds: modèles, images, logs	URI: s3://mon-bucket/mlflow Env: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION Compatible S3: MLFLOW_S3_ENDPOINT_URL pour MinIO
  Artifact store GCS	Fichiers lourds	URI: gs://mon-bucket/mlflow Env: GOOGLE_APPLICATION_CREDENTIALS=/chemin/compte.json
  Artifact store Azure	Fichiers lourds	URI: wasbs://[email protected]/path ou abfss://... Env: AZURE_STORAGE_CONNECTION_STRING ou compte + clé
  Artifact store local/NFS	Fichiers lourds sur serveur interne	URI: file:///mnt/mlartifacts (droits POSIX ou export NFS)

  Comment démarrer un serveur distant et l’UI ?

  1. Préparer l’environnement:
     • Créer une base SQL dédiée: par exemple PostgreSQL mlflow avec utilisateur restreint.
     • Choisir le stockage d’artefacts: bucket S3, GCS, Azure Blob, ou répertoire partagé.
     • Ouvrir le port applicatif interne, par exemple 5000, et réserver un nom DNS.
  2. Lancer le serveur MLflow en « proxy d’artefacts »: le serveur gère l’accès au stockage d’objets.

     export AWS_ACCESS_KEY_ID=...
     export AWS_SECRET_ACCESS_KEY=...
     export AWS_DEFAULT_REGION=eu-west-1  # exemple
     
     mlflow server \
       --host 0.0.0.0 --port 5000 \
       --backend-store-uri postgresql://mlflow:***@db:5432/mlflow \
       --artifacts-destination s3://mon-bucket/mlflow
     

     Alternative « accès direct au stockage »: les clients écrivent eux‑mêmes dans le bucket.

     mlflow server \
       --host 0.0.0.0 --port 5000 \
       --backend-store-uri postgresql://mlflow:***@db:5432/mlflow \
       --no-serve-artifacts \
       --default-artifact-root s3://mon-bucket/mlflow
     

  3. Configurer les clients:

     # sur les postes des utilisateurs
     export MLFLOW_TRACKING_URI=http://mlflow.mondomaine:5000
     python -c "import mlflow; mlflow.set_experiment('demo'); 
     with mlflow.start_run(): mlflow.log_param('lr',0.1); mlflow.log_metric('acc',0.9)"
     

  4. Placer MLflow derrière un reverse proxy HTTPS (exemple NGINX + Basic Auth):

     server {
       listen 443 ssl;
       server_name mlflow.mondomaine;
     
       ssl_certificate /etc/letsencrypt/live/mlflow/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/mlflow/privkey.pem;
     
       location / {
         proxy_pass http://127.0.0.1:5000;
         proxy_set_header Host $host;
         proxy_set_header X-Forwarded-Proto https;
         auth_basic "Acces restreint";
         auth_basic_user_file /etc/nginx/.htpasswd;
       }
     }
     

  5. Vérifier la santé du service:
     • Interface: ouvrir https://mlflow.mondomaine et lister les expériences.
     • API: curl -s https://mlflow.mondomaine/version doit retourner la version du serveur.
     • Artefacts: lancer un run test et vérifier la création dans le bucket ou le partage.

  Bonnes pratiques de déploiement: exécuter MLflow en service système avec redémarrage automatique, activer la journalisation applicative, et documenter l’URL de suivi ainsi que les conventions d’équipes (espaces de noms d’expériences, dossiers d’artefacts par projet).

  Quelles options de sécurité et permissions de base ?

  • Authentification côté client: variables d’environnement prises en charge par MLflow.

    # Basic Auth via proxy
    export MLFLOW_TRACKING_USERNAME=<utilisateur>
    export MLFLOW_TRACKING_PASSWORD=<mot_de_passe>
    
    # Jeton Bearer si votre proxy le transmet
    export MLFLOW_TRACKING_TOKEN=<token>
    

  • Chiffrement et réseau:
    • HTTPS obligatoire au proxy, interdire l’accès public, limiter les IP sources.
    • Isoler la base SQL et le bucket dans le réseau privé, journaux d’accès activés.
    • Éviter les clés en dur dans le code, préférer IAM/roles ou comptes de service.
    • En mode proxy d’artefacts, seules les clés du serveur sont nécessaires.
    • Politiques par préfixe d’artefacts par équipe ou par projet.
    • Activer le versioning et le chiffrement côté stockage, plan de sauvegarde pour la base SQL.
    • En MLflow managé (par exemple Databricks), utiliser le contrôle d’accès par rôles et le catalogue de gouvernance pour le Model Registry, les expériences et les artefacts. Idéal pour des équipes nombreuses ou multi‑espaces de travail.

    En synthèse: commencez simple avec une base PostgreSQL et un bucket d’artefacts, placez MLflow derrière un reverse proxy HTTPS avec authentification, puis formalisez les permissions par projet. Vous pourrez ensuite étendre vers un service managé avec RBAC si les besoins d’échelle et de gouvernance augmentent.

    Découvrir le métier de Data Scientist

    Quelles intégrations MLflow supporte-t-il ?

    MLflow s’intègre à un large écosystème afin de suivre, évaluer, packager et déployer vos modèles. Les utilisateurs techniques comme moins techniques peuvent centraliser paramètres, métriques et artefacts, tout en profitant d’intégrations natives avec des frameworks reconnus comme Scikit-Learn, PyTorch et TensorFlow, ainsi que de formats de modèles standardisés appelés flavors.

    • Frameworks et bibliothèques ML : scikit-learn, TensorFlow/Keras, PyTorch, XGBoost, LightGBM, ainsi que des intégrations orientées GenAI et agents.
    • Formats et flavors de modèles : flavors dédiés par framework et flavor universel pyfunc pour une exécution homogène, interopérabilité possible avec des serveurs REST et des UDF Spark.
    • Orchestration et data pipelines : intégration fluide avec Airflow, Prefect ou Argo pour planifier entraînements, évaluations et déploiements.
    • CI/CD : compatibilité avec GitHub Actions et GitLab CI pour automatiser tests, entraînements, enregistrements au registre et promotions de modèles.
    • Déploiement et serving : exposition en API REST, batch scoring, conteneurs Docker, Kubernetes, ou plateformes cloud comme Azure ML et AWS SageMaker.
    • Langages et SDK : Python, Java, R, JavaScript/TypeScript pour instrumenter, tracer et exploiter les modèles dans divers environnements.

    Avec quels frameworks ML s’intègre-t-il ?

    MLflow Models définit des flavors par framework afin de standardiser l’empaquetage et l’inférence. Ces flavors fonctionnent de pair avec MLflow Tracking et, selon le framework, l’autologging peut capter automatiquement hyperparamètres, métriques et artefacts.

    • scikit-learn → mlflow.sklearn (flavor natif, support des pipelines scikit-learn, signatures d’entrée et de sortie, autologging).
    • TensorFlow / Keras → mlflow.tensorflow et mlflow.keras (sauvegarde du modèle, métriques d’entraînement, artefacts, autologging).
    • PyTorch → mlflow.pytorch (sérialisation Python ou TorchScript pour servir, enregistrement des checkpoints et métriques, autologging selon les configurations).
    • XGBoost → mlflow.xgboost (sauvegarde booster et paramètres, autologging).
    • LightGBM → mlflow.lightgbm (sauvegarde modèle et métriques, autologging).
    • Flavor universel → mlflow.pyfunc pour emballer n’importe quel modèle comme fonction prédictive standardisée, utile pour unifier le serving et les UDF Spark.

    Comment l’utiliser avec des pipelines et la CI/CD ?

    Dans les pipelines, MLflow sert de couche de traçabilité et de promotion des modèles. L’orchestrateur planifie les tâches d’extraction de données, d’entraînement et d’évaluation, tandis que la CI/CD automatise tests, packaging et transitions dans le registre de modèles.

    Cas concret : un workflow Airflow exécute chaque nuit un entraînement. Les tâches orchestrent préparation des données, apprentissage, évaluation puis enregistrement dans le Model Registry avec un stage Staging. Une pipeline GitHub Actions déclenchée sur main rejoue les tests, valide les métriques et, après approbation, promeut la version en Production. GitLab CI peut fournir le même schéma avec des environnements protégés.

    • Airflow : DAGs pour entraîner, évaluer, enregistrer et comparer des modèles, puis transition de stage via l’API MLflow.
    • Prefect : flows et tâches pour orchestrer entraînements, évaluations et batch inference avec suivi centralisé dans MLflow.
    • Argo Workflows : exécution sur Kubernetes, conteneurs reproductibles, MLflow comme serveur de tracking et registre externe.
    • GitHub Actions : jobs de lint/tests, entraînement, mlflow.log_model, création de version dans le registre, règles d’approbation pour promouvoir.
    • GitLab CI : stages build/test/train/register, environments protégés et approbations pour la promotion contrôlée.

    Databricks vs OSS: que change le MLflow managé ?

    La version open source fournit le suivi d’expériences, les flavors de modèles, les projets et le registre. La version managée par Databricks reprend ces briques et ajoute une exécution élastique, une gouvernance centralisée et une expérience unifiée pour l’évaluation, l’observabilité et le déploiement, sans orientation commerciale ici.

    Critère	MLflow open source	MLflow managé sur Databricks
    Hébergement et scalabilité	Serveur de tracking et stockage à opérer et à faire évoluer soi‑même.	Service hébergé, ressources élastiques et haute disponibilité gérées.
    Gouvernance et sécurité	Contrôles basiques, gestion des accès à configurer côté infra.	RBAC fin et gouvernance centralisée via Unity Catalog, journaux d’activité et audit.
    Expérience UI	UI MLflow standard pour runs, comparaisons et registre.	UI intégrée à l’espace de travail Databricks avec évaluation et traçage unifiés pour ML et GenAI.
    Registry et promotion	Model Registry avec stages Staging/Production/Archived.	Registry intégré à Unity Catalog, partage inter‑workspaces, workflows de promotion gouvernés.
    Orchestration et exécution	Intégration libre avec Airflow/Prefect/Argo, compute à gérer.	Intégration native avec Jobs et clusters Databricks, mises à jour automatiques.
    Déploiement et serving	Serving REST local, Docker/Kubernetes, Azure ML ou AWS SageMaker.	Model Serving managé avec monitoring, alertes et intégration evaluation/observability.

    Se former à la Data et à l'IA

    Quelles bonnes pratiques adopter avec MLflow ?

    MLflow permet aux Machine Learning Engineer, comme aux utilisateurs moins techniques, de suivre les informations liées à l’entraînement et à la mise en production des modèles de machine learning. Pour garantir qualité et traçabilité, structurez votre usage des modules Tracking, Projects, Models et du registre de modèles autour de règles simples et partagées.

    • Centraliser le suivi: définissez une unique URI de suivi et un stockage d’artefacts commun pour toutes les équipes.
    • Standardiser conventions et tags: imposez un schéma de nommage et des tags obligatoires pour chaque exécution.
    • Tout journaliser: hyperparamètres, métriques, artefacts, version de code, version de données et signature des entrées du modèle.
    • Assurer la reproductibilité: utilisez MLflow Projects, décrivez l’environnement, fixez les seeds et versionnez les jeux de données.
    • Valider avant promotion: mettez en place des critères d’acceptation et un processus de revue pour le passage des modèles entre les stages du registre.
    • Automatiser via CI/CD: déclenchez évaluations, contrôles qualité et notifications à chaque nouvel enregistrement ou changement de stage.
    • Gouverner les accès: appliquez des rôles d’approbation et conservez un historique d’audit complet.

    Comment nommer, taguer et organiser les expériences ?

    • Conventions de nommage des expériences: produit/domaine/projet/objectif, par exemple “reco/ecommerce/prix/optimisation”. Ajoutez éventuellement l’environnement entre parenthèses: “… (dev|staging|prod)”.
    • Noms de runs courts et informatifs: algo-jeuDeDonnéesVersion-granularité-date, par exemple “xgboost-v3-daily-2026-06-25”.
    • Tags obligatoires sur chaque run:
      • project, owner, team
      • git_sha, branch, entry_point
      • framework, framework_version, model_type
      • data_source, data_version ou hash, split_id
      • random_seed, target_metric, budget/compute
      • stage_target (prévu: staging ou production)

      En pratique, créez un modèle de “fiche d’expérience” réutilisable: description métier, hypothèses, protocole d’évaluation, jeux de données, budget de calcul, critères de réussite, contacts et liens vers les runs MLflow pertinents.

      Comment renforcer la reproductibilité (Projects, environnements, seeds) ?

      1. Déclarer un MLproject: définissez les entry_points, paramètres et dépendances de votre projet MLflow Projects.
      2. Geler l’environnement: fournissez conda.yaml ou requirements.txt et la version de Python. Pour le deep learning, précisez image Docker, CUDA et cuDNN.
      3. Fixer les seeds: renseignez random, NumPy et, si nécessaire, PyTorch ou TensorFlow, puis logguez la valeur unique random_seed.
      4. Versionner les données: référencez un snapshot immuable (URI + hash), logguez la version et le schéma, et sauvegardez la logique de split.
      5. Journaliser le code: enregistrez git_sha, la branche et, si possible, la diff ou l’archive du code comme artefact.
      6. Signer les entrées du modèle: log_model avec signature et input_example pour fiabiliser le rechargement et les tests d’inférence.
      7. Capturer l’environnement d’exécution: “pip freeze”, infos CPU/GPU, OS, variables critiques, et stockez-les en artefacts.
      8. Automatiser une relance: une pipeline CI ré-exécute l’entry_point principal avec les mêmes paramètres et vérifie l’égalité des métriques clés dans une tolérance définie.

      Cette checklist garantit que toute exécution peut être relancée à l’identique: même code, mêmes dépendances, mêmes données, mêmes seeds et mêmes paramètres, ce qui simplifie le débogage, l’audit et le transfert vers la production.

      Comment gérer la gouvernance (stages, approbations) ?

      1. Enregistrement initial: à la fin d’un run, enregistrez le modèle dans le Model Registry avec liens vers le run, les artefacts et la signature.
      2. Validation automatique: une job d’évaluation compare aux baselines, vérifie la robustesse, la dérive de données et les contraintes de performance/coût. Les résultats sont loggués dans MLflow.
      3. Revue humaine: un reviewer valide la conformité (métriques, biais, sécurité, traçabilité). L’approbation est consignée via commentaires et tags.
      4. Promotion en Staging: déploiement contrôlé sur environnement de test, tests d’intégration et canary, collecte de télémétrie et de feedback.
      5. Passage en Production: promotion avec justification, alias de version mis à jour, plan de rollback vers la dernière version stable.
      6. Notifications et webhooks: déclenchez CI/CD, alertes Slack ou Teams lors d’un nouvel enregistrement ou d’un changement de stage. Sur Databricks Managed MLflow, utilisez les webhooks du registre; en open source, orquestrez ces notifications via l’API REST et votre outil de CI.
      7. Audit et archivage: conservez l’historique complet des transitions, commentez les décisions, archivez les anciennes versions quand elles ne sont plus servies.

      Adossez ce processus à des contrôles d’accès: seuls certains rôles peuvent enregistrer, valider et promouvoir. Combinez suivi MLflow, logs de déploiement et tableaux de bord de monitoring pour une visibilité de bout en bout et une conformité vérifiable.

      Se former à la Data Science

      Un cas d’usage: comment passer de l’entraînement au déploiement ?

      Voici un fil conducteur de bout en bout avec MLflow, de l’entraînement au service en production, en suivant la chaîne tracking → registry → serving. Contexte d’exemple: un classificateur Scikit-Learn pour prédire le churn clients, mais la démarche est identique avec PyTorch ou TensorFlow. MLflow permet d’enregistrer paramètres, métriques et artefacts, puis de versionner et promouvoir un modèle jusqu’à l’API de prédiction.

      Étape 1: données, entraînement, logging

      1. Préparer les données et figer leur version (train, validation, test), en notant l’emplacement et le hash pour assurer la traçabilité.
      2. Créer une expérience et démarrer un run MLflow pour l’entraînement, afin d’enregistrer automatiquement le contexte de l’exécution.
      3. Journaliser les hyperparamètres et le contexte d’entraînement: algorithme, version du code, graine aléatoire, taille des échantillons, features utilisées.
      4. Suivre les métriques clés pendant et après l’entraînement: par exemple AUC, précision, rappel, perte, ainsi que les courbes (ROC, précision‑rappel) exportées en artefacts.
      5. Enregistrer les artefacts utiles: figures de diagnostic, matrice de confusion, rapport d’évaluation, jeux de features sélectionnées, et le modèle sérialisé.
      6. Enregistrer le modèle au format MLflow avec son environnement d’exécution et sa signature d’entrée/sortie, pour garantir une inférence reproductible.
      7. Comparer les runs dans l’UI MLflow, filtrer par métriques et sélectionner un candidat pour la suite.

      Exemple concret: vous logguez learning_rate, max_depth et class_weight, obtenez AUC=0,89 sur validation, déposez confusion_matrix.png et roc_curve.png comme artefacts, puis enregistrez le modèle avec sa signature. L’UI MLflow permet de trier les runs, visualiser l’évolution des métriques et retrouver précisément le jeu de données et le code utilisés.

      Étape 2: enregistrement au registry et validation

      1. Enregistrer le meilleur run dans le Model Registry de MLflow en créant une nouvelle version du modèle (v1). Le registre centralise versions, métadonnées et états.
      2. Définir et vérifier la signature du modèle (schéma des entrées, types, forme des sorties), et conserver l’environnement d’exécution associé.
      3. Procéder à une évaluation indépendante: backtest ou validation sur un échantillon tenu à part, journaliser les métriques et graphiques en artefacts de validation.
      4. Revue croisée et gouvernance: ajouter description, tags (par exemple data_version, use_case, owner), consigner les checks passés, puis promouvoir la version vers l’état Staging.
      5. Automatiser ces étapes dans un pipeline CI/CD: seuils de qualité bloquants, notifications, et génération d’un rapport d’évaluation stocké avec la version du modèle.

      En pratique, Staging sert aux tests d’intégration et de charge, tout en gardant l’historique des évaluations et des artefacts par version. Une fois les critères validés, la version est prête pour le déploiement.

      Étape 3: mise en production et monitoring initial

      1. Déployer la version validée en service: point de terminaison REST via MLflow Models, un conteneur Docker sur Kubernetes, ou un service managé (par exemple Azure ML ou AWS SageMaker), selon vos contraintes.
      2. Effectuer des smoke tests: requête de santé, prédiction sur un exemple connu, vérification des dépendances et de la compatibilité de la signature.
      3. Mettre en place les premiers contrôles opérationnels: latence moyenne et p95, taux d’erreurs, débit, journaux d’accès, avec alertes sur seuils.
      4. Journaliser les prédictions et le contexte d’inférence dès le départ (identifiant de requête, version du modèle, horodatage, features agrégées), en respectant les règles de confidentialité.
      5. Surveiller la qualité: comparer en ligne la distribution des entrées à celle de l’entraînement pour détecter une dérive, échantillonner des prédictions pour revue humaine, boucler le feedback vers MLflow pour réévaluation.
      6. Promouvoir en Production lorsque les checks passent durablement, conserver un alias vers la version courante, et archiver l’ancienne version pour rollback rapide si nécessaire.

      Astuce pratique: démarrez en mode canari (faible pourcentage de trafic) et augmentez progressivement. Les métriques opérationnelles et les journaux de prédiction, associés à la version du modèle dans MLflow, facilitent le débogage et la comparaison lors des prochaines itérations.

      Formation Data Scientist certifiante

      MLflow et les LLMs: que peut-on faire ?

      Historiquement centré sur le cycle de vie des modèles ML classiques, MLflow s’est enrichi pour couvrir les applications à base de modèles de langage: observabilité des requêtes et des agents, évaluation continue, gestion des prompts et déploiement. Vous conservez les atouts existants de MLflow Tracking, Projects et Models pour suivre paramètres, métriques et artefacts, tout en ajoutant des briques dédiées aux LLMs pour itérer plus vite, comparer et mettre en production avec confiance.

      • Observabilité et traçage: capture des entrées, sorties et étapes intermédiaires des applications et agents LLM, compatible OpenTelemetry, avec suivi qualité, coûts et latence.
      • Évaluation: exécutions d’évaluations systématiques avec métriques prêtes à l’emploi et LLM-as-a-judge, comparaison de versions et détection de régressions.
      • Prompts: registre et versionnage des prompts, tests A/B et optimisation, traçabilité complète entre prompts, évaluations et performances.
      • Agent Server: hébergement rapide d’agents via une API FastAPI avec validation des requêtes, streaming et traçage intégré.
      • AI Gateway: API unifiée compatible OpenAI pour tous les fournisseurs, gestion centralisée des clés, routage, limites de débit, fallbacks et contrôle des coûts.
      • Intégrations: prise en charge des principaux frameworks et fournisseurs LLM, sans verrouillage éditeur.

      Comment évaluer prompts et tracer les runs LLM ?

      Dans MLflow, vous pouvez créer des jeux de données d’évaluation dédiés aux tâches LLM, puis lancer des runs qui enregistrent à la fois les métriques (exactitude, pertinence, sécurité, latence, coût) et les traces détaillées de chaque requête. MLflow Tracking conserve les paramètres clés, par exemple le fournisseur et le modèle utilisés, la température, la version du prompt et les outils appelés par un agent. Les exécutions sont ensuite comparées dans l’interface MLflow, ce qui facilite l’analyse de variantes de prompts et de modèles, l’identification de régressions et la sélection de la meilleure combinaison pour la production.

      Exemple: pour un assistant de support, vous constituez un dataset d’évaluation à partir de tickets réels. Vous testez deux prompts et deux modèles. Chaque run journalise les métriques de qualité et la trace complète (messages, appels outils, latences), ainsi que les artefacts utiles comme des rapports d’analyse. Dans la vue MLflow, vous comparez les variantes, retenez la meilleure, puis continuez à prélever des traces de production pour enrichir votre dataset et réévaluer régulièrement.

      Qu’apportent Agents et AI Gateway ?

      Avec Agent Server, vous orchestrez et exposez des agents en quelques minutes tout en profitant du traçage et de la validation des requêtes. L’AI Gateway fournit une couche d’accès unifiée à plusieurs fournisseurs de LLM: une seule interface pour configurer des clés, définir des politiques de routage, appliquer des limites de débit, activer des fallbacks et suivre les coûts. Ensemble, ils apportent une gouvernance centralisée, une meilleure résilience et une itération plus rapide du prototype à la production.

      • Gouvernance et sécurité: un point de contrôle pour gérer l’accès aux modèles, appliquer des politiques et auditer les usages.
      • Résilience et maîtrise des coûts: routage multi-fournisseurs, fallbacks automatiques, limites de débit et suivi budgétaire.
      • Itération et qualité: déploiement rapide d’agents avec traçage intégré, comparaisons de versions et évaluations en continu.
      • Cas d’usage: assistants RAG, agents outillés pour automatiser des workflows métiers, classification et extraction de texte à grande échelle.
      Maîtriser MLflow pour les LLMs

      FAQ courte et dépannage

      Voici des réponses rapides aux questions récurrentes sur MLflow, ainsi qu’une mini‑checklist de diagnostic pour gagner du temps quand quelque chose ne marche pas comme prévu.

      MLflow fonctionne-t-il avec R ?

      Oui. MLflow propose un SDK R qui permet de suivre des expériences, consigner des métriques et des artefacts, et interagir avec le serveur de suivi. En pratique, l’écosystème d’exemples et d’intégrations reste beaucoup plus riche côté Python.

      • Ce qui marche bien: tracking des runs, enregistrement d’artefacts, consultation des résultats et interaction via l’API REST.
      • Points d’attention: les fonctionnalités les plus récentes autour des LLM et des agents, l’AI Gateway et l’Agent Server sont d’abord disponibles en Python. Vérifiez toujours la disponibilité dans le SDK R avant de planifier une mise en production.
      • Bon réflexe: pour des workflows hybrides, vous pouvez entraîner en R et exploiter le suivi, l’évaluation et le registre de modèles depuis Python ou via l’API REST lorsque c’est nécessaire.

      Puis-je utiliser MLflow avec Docker/Kubernetes ?

      Oui. MLflow s’intègre bien aux conteneurs pour le serveur de tracking comme pour le service d’inférence, et peut être déployé sur Kubernetes.

      • Images et conteneurs: vous pouvez exécuter mlflow server dans un conteneur, en configurant le backend store et l’artifact store via variables d’environnement. Pour l’inférence, empaquetez votre code et servez le modèle avec mlflow models serve dans une image.
      • Kubernetes: déployez le serveur de tracking ou vos services d’inférence derrière un Deployment et un Service, avec un Ingress pour l’accès sécurisé. Des charts Helm communautaires existent pour accélérer l’installation.
      • Alternatives managées: si vous êtes sur Databricks, Managed MLflow et Model Serving simplifient le déploiement à l’échelle.
      • Ressources utiles: documentation et exemples sur mlflow.org et le dépôt GitHub MLflow.

      Comment faire de l’A/B testing de modèles ?

      Deux approches complémentaires existent. D’abord hors ligne, comparez plusieurs candidats sur un jeu d’évaluation et logguez les métriques dans MLflow Tracking. Ensuite en ligne, exposez deux versions et répartissez le trafic pour mesurer l’impact réel.

      Cas concret: enregistrez deux versions dans le Model Registry, étiquetez-les clairement, puis routez 50 pour cent du trafic vers chaque version via votre passerelle d’API ou votre application. Logguez les prédictions et indicateurs métier comme des métriques de run, comparez dans l’UI MLflow, puis promouvez la meilleure version en Production. Vous pouvez aussi itérer rapidement en taguant les runs, en figeant les artefacts de comparaison et en automatisant l’évaluation avant promotion.

      Un run n’apparaît pas: que vérifier ?

      • Tracking URI: vérifiez MLFLOW_TRACKING_URI ou mlflow.set_tracking_uri(...) dans votre code. Beaucoup d’absences viennent d’un URI pointant en local au lieu du serveur attendu.
      • Expérience: contrôlez mlflow.set_experiment(...) et le workspace ciblé. Un run peut être créé dans une autre expérience ou un autre workspace.
      • Permissions: assurez-vous d’avoir les droits de lecture sur l’expérience et le modèle si vous êtes sur une plateforme managée.
      • Backend store et artefacts: le serveur doit pouvoir écrire dans la base de métadonnées et le stockage d’artefacts. Testez la connectivité et les identifiants.
      • Run context: démarrez et fermez bien le run, par exemple avec with mlflow.start_run(): en Python. Hors contexte, certains logs sont ignorés.
      • Autologging et erreurs silencieuses: activez les logs en niveau INFO et vérifiez la console. Une exception pendant l’entraînement peut empêcher l’envoi des métriques.
      • Réseau et proxy: si vous logguez depuis un job ou un notebook distant, contrôlez pare-feu, proxy et certificats TLS.
      • Actualisation UI: rechargez l’UI MLflow, changez de filtre, vérifiez l’horodatage et les colonnes visibles.

      En pratique, commencez par exécuter localement un script minimal qui loggue un paramètre, une métrique et un artefact sur l’expérience cible. Si ce test passe, remontez la chaîne côté pipeline, identifiant, puis permissions jusqu’au job incriminé.

      Découvrir le métier de Data Scientist