Accueil › Glossaire › Experiment Tracking

Experiment Tracking

L’experiment tracking (suivi d’expériences) est la pratique qui consiste à enregistrer systématiquement tous les détails de chaque run d’entraînement ML (paramètres, métriques, code, données, environnement et artefacts) pour rendre les expériences reproductibles, comparables et auditables.

Sans experiment tracking, un projet ML ressemble rapidement à un dossier rempli de fichiers model_final_v3_VRAI_FINAL.pkl et de notebooks commentés dont personne ne se souvient des résultats. L’experiment tracking résout ce chaos en créant un registre central de tout ce qui a été tenté, avec quels résultats, permettant de retrouver en quelques secondes la configuration exacte qui a produit votre meilleur modèle.

Pourquoi l’experiment tracking est fondamental

Développer un modèle de machine learning est un processus itératif. Vous testez des dizaines, parfois des centaines de combinaisons : architectures différentes, hyperparamètres variés, preprocessing modifié, nouveaux features, datasets mis à jour. Chaque combinaison produit un run avec ses propres résultats. Sans un système pour capturer tout cela, vous perdez la trace de ce qui fonctionne et pourquoi.

Reproductibilité

La reproductibilité est le problème numéro un en ML. Un modèle qui fonctionne sur votre laptop doit fonctionner de manière identique quand un collègue le relance ou quand il est déployé en production. L’experiment tracking garantit cela en enregistrant la totalité du contexte d’un run : le code exact (commit Git), les données utilisées (version du dataset), les hyperparamètres, les seeds aléatoires et l’environnement logiciel (versions des bibliothèques). Avec ces informations, n’importe qui peut recréer exactement le même résultat.

Comparaison systématique

Quand vous avez exécuté 50 runs avec des paramètres différents, comment identifiez-vous le meilleur ? Sans tracking, vous faites des captures d’écran de métriques et vous les comparez dans un tableur. Avec un outil d’experiment tracking, vous filtrez, triez et visualisez tous vos runs dans un dashboard interactif. Vous pouvez superposer les courbes de loss de plusieurs runs, trier par F1-score, filtrer par learning rate. La comparaison qui prenait une heure se fait en 30 secondes.

Collaboration d’équipe

Dans une équipe de data scientists, plusieurs personnes expérimentent simultanément sur le même problème. L’experiment tracking centralise tous les résultats dans un même endroit. Un collègue peut voir vos runs, comprendre ce que vous avez testé, et partir de vos résultats plutôt que de tout recommencer. C’est la fin des emails avec des screenshots de notebooks.

Auditabilité et conformité

Pour les industries réglementées (finance, santé, assurance), chaque décision d’un modèle en production doit être traçable. L’experiment tracking fournit l’historique complet : qui a entraîné quel modèle, avec quelles données, quand, et quels résultats ont justifié sa mise en production. C’est le fondement de toute stratégie de gouvernance ML.

Que faut-il tracker exactement ?

Un run d’expérience ML produit une quantité importante d’informations. Voici les catégories essentielles que votre système de tracking doit capturer :

Concepts clés de l’experiment tracking

Experiment

Un experiment est un conteneur logique qui regroupe des runs liés à une même tâche. Par exemple, l’experiment « détection-fraude » contient tous les runs d’entraînement testés pour ce problème. Vous pouvez avoir des experiments longue durée (un cas d’usage métier entier) ou éphémères (les résultats d’un hyperparameter sweep déclenché par une pull request).

Run

Un run est une exécution unique d’un script d’entraînement. Chaque run enregistre ses métadonnées (paramètres, métriques, timestamps) et ses artefacts (fichiers produits : modèles, images, logs). Un run est l’unité atomique du tracking : c’est lui que vous comparez, filtrez et sélectionnez.

Child Runs

Certains outils permettent de créer des runs enfants sous un run parent. C’est utile pour regrouper les runs d’une cross-validation (un parent + un enfant par fold) ou les itérations d’un hyperparameter sweep. MLflow supporte nativement cette hiérarchie.

Autologging

L’autologging capture automatiquement les paramètres et métriques sans code explicite. Quand vous appelez mlflow.autolog() avant l’entraînement, MLflow intercepte les appels aux frameworks supportés et enregistre tout : les hyperparamètres du modèle, les métriques d’évaluation, les artefacts (poids, feature importance), et même les signatures d’entrée/sortie du modèle.

Artifact Store

Les métadonnées (paramètres, métriques, tags) sont stockées dans un backend store (base de données SQL). Les artefacts volumineux (poids du modèle, datasets, images) sont stockés séparément dans un artifact store (S3, GCS, Azure Blob, ou un dossier local). Cette séparation permet de scaler indépendamment les métadonnées et les fichiers lourds.

Les outils d’experiment tracking en détail

MLflow Tracking : le standard open source

MLflow est la plateforme open source la plus adoptée pour l’experiment tracking, avec plus de 30 millions de téléchargements mensuels. Son composant Tracking enregistre les paramètres, métriques, code et artefacts via une API Python simple et une interface web pour explorer les résultats.

MLflow 3, sorti en 2025, a refondu l’architecture pour supporter nativement les applications GenAI. Le tracking couvre désormais non seulement les runs ML classiques mais aussi les traces LLM (observabilité des étapes intermédiaires d’un agent ou d’une chaîne RAG), les prompts versionnés et les évaluations avec juges LLM. MLflow 3.10 (février 2026) a ajouté le support multi-workspace, l’évaluation de conversations multi-tour et le tracking des coûts LLM.

import mlflow

# Configurer le tracking
mlflow.set_tracking_uri("http://localhost:5000")
mlflow.set_experiment("detection-fraude")

# Activer l'autolog pour scikit-learn
mlflow.autolog()

# Entraîner normalement : tout est capturé automatiquement
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import f1_score

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)

with mlflow.start_run(run_name="rf-baseline"):
    model = RandomForestClassifier(n_estimators=200, max_depth=10, random_state=42)
    model.fit(X_train, y_train)

    # Logger des métriques custom en plus de l'autolog
    predictions = model.predict(X_test)
    mlflow.log_metric("f1_custom", f1_score(y_test, predictions))

    # Logger un artefact custom (confusion matrix en image)
    mlflow.log_artifact("confusion_matrix.png")

Pour le tracking par epoch (réseaux de neurones), MLflow supporte le paramètre step qui permet de logger des métriques à chaque itération et de visualiser les courbes d’apprentissage dans l’interface :

with mlflow.start_run(run_name="transformer-v3"):
    mlflow.log_params({
        "model": "transformer",
        "hidden_dim": 256,
        "learning_rate": 3e-4,
        "epochs": 50
    })

    for epoch in range(50):
        train_loss, val_loss = train_one_epoch(model, train_loader, val_loader)

        # Logger les métriques avec le step pour les courbes
        mlflow.log_metric("train_loss", train_loss, step=epoch)
        mlflow.log_metric("val_loss", val_loss, step=epoch)
        mlflow.log_metric("val_accuracy", evaluate(model, val_loader), step=epoch)

Weights & Biases : le tracking collaboratif

Weights & Biases (W&B) se positionne comme la plateforme ML « developer-first » avec un accent sur la collaboration et la visualisation. Son interface est unanimement reconnue comme supérieure à celle de MLflow : dashboards interactifs, comparaison de runs en temps réel, rapports partagés et tables de données explorables.

W&B s’intègre avec plus de 20 frameworks (PyTorch, TensorFlow, scikit-learn, HuggingFace Transformers, etc.) en quelques lignes de code. Le logging est quasi-identique à MLflow dans sa simplicité :

import wandb

# Initialiser un run
run = wandb.init(
    project="detection-fraude",
    name="xgboost-v2",
    config={
        "model": "xgboost",
        "n_estimators": 500,
        "max_depth": 8,
        "learning_rate": 0.05
    }
)

# Logger des métriques pendant l'entraînement
for epoch in range(100):
    train_loss, val_loss = train_one_epoch(model, epoch)
    wandb.log({
        "train_loss": train_loss,
        "val_loss": val_loss,
        "epoch": epoch
    })

# Logger un artefact
artifact = wandb.Artifact("training-data", type="dataset")
artifact.add_file("data/train.parquet")
run.log_artifact(artifact)

run.finish()

W&B a aussi introduit W&B Weave, un module de tracing et d’observabilité spécifiquement conçu pour les applications GenAI. Weave capture les appels LLM, les étapes de retrieval dans un pipeline RAG, et les décisions d’outils dans un agent, avec une interface dédiée pour debugger chaque étape.

Le principal compromis : W&B est cloud-first. La version gratuite est limitée (projets privés limités), et les plans payants (Teams à ~$50/utilisateur/mois) s’additionnent vite pour les grandes équipes. Des options self-hosted et Dedicated Cloud existent pour les organisations avec des exigences de souveraineté des données.

Neptune : métadonnées et requêtage avancé

Neptune se distingue par ses capacités de requêtage et de filtrage avancées sur les métadonnées d’expériences. Là où MLflow et W&B offrent des interfaces de comparaison visuelles, Neptune permet de construire des requêtes complexes pour retrouver des runs spécifiques dans un historique de milliers d’expériences.

Neptune excelle dans les scénarios où la traçabilité et la conformité sont prioritaires. Les industries réglementées (finance, santé, automobile) apprécient son système d’audit trail détaillé et sa capacité à relier chaque modèle à la version exacte des données, du code et de la configuration qui l’a produit.

Le modèle de pricing de Neptune est basé sur l’usage (heures de tracking, volume de stockage), ce qui peut le rendre économique pour les petites équipes mais coûteux à grande échelle.

ClearML : tracking « automagique »

ClearML (anciennement Allegro Trains) est une plateforme open source complète qui va au-delà du simple experiment tracking. Son module Experiment Manager capture automatiquement les métriques, le code source, les notebooks Jupyter, les fichiers de configuration et même les conteneurs Docker associés à chaque run.

Le point fort de ClearML est l’intégration avec sa propre infrastructure d’orchestration : vous pouvez transformer n’importe quel script Python en tâche ClearML, la mettre dans une queue, et ClearML gère le scheduling sur vos GPU (cloud, on-premise ou hybride). Le tracking et l’orchestration dans le même outil éliminent le besoin de connecter MLflow à Airflow ou Kubeflow séparément.

ClearML propose un free tier généreux (100 Go de stockage d’artefacts) et une version Enterprise managée pour les organisations avec des exigences de sécurité. L’interface est fonctionnelle mais moins raffinée que celle de W&B.

TensorBoard : le vétéran

TensorBoard est l’outil de visualisation historique de l’écosystème TensorFlow. Il offre des visualisations de métriques, de graphes de modèles, de distributions de poids et d’images. Bien qu’il soit souvent le premier choix pour les utilisateurs TensorFlow, il a des limitations significatives : pas de model registry, pas de gestion multi-utilisateur native, pas de requêtage avancé. Pour un usage au-delà de la visualisation personnelle, il est insuffisant. La plupart des équipes l’utilisent en complément d’un outil de tracking plus complet comme MLflow ou W&B.

Comparatif des outils d’experiment tracking

Bonnes pratiques d’experiment tracking

Nommez vos runs de manière descriptive

Un nom de run comme « run_23 » ne vous dira rien dans deux semaines. Utilisez des noms qui décrivent l’hypothèse testée : rf-200trees-depth10-baseline, transformer-lr3e4-dropout05, xgboost-feature-v2-no-outliers. MLflow permet de passer un run_name dans mlflow.start_run(), W&B utilise le paramètre name dans wandb.init().

Utilisez les tags pour organiser

Les tags permettent de catégoriser vos runs selon des dimensions utiles : type de modèle (random_forest, transformer), phase (exploration, optimisation, final), dataset utilisé (v2026-Q1), ou auteur. Les tags facilitent le filtrage dans le dashboard quand vous avez des centaines de runs.

Loggez les métriques par step

Pour les entraînements itératifs (réseaux de neurones), ne loggez pas seulement les métriques finales. Utilisez le paramètre step pour enregistrer la loss et l’accuracy à chaque epoch. Les courbes d’apprentissage sont indispensables pour diagnostiquer les problèmes (overfitting, underfitting, learning rate trop élevé).

Référencez la version des données

Loggez systématiquement un paramètre dataset_version ou data_hash dans chaque run. Si vous utilisez DVC, référencez le tag DVC correspondant. Un modèle n’est reproductible que si vous pouvez retrouver exactement les données sur lesquelles il a été entraîné.

Capturez l’environnement

Loggez le requirements.txt ou le conda.yaml comme artefact de chaque run. Les résultats numériques peuvent varier entre des versions différentes de PyTorch ou de CUDA. MLflow capture automatiquement les dépendances avec mlflow.autolog() et les packages avec log_model().

Structurez les runs complexes

Pour un hyperparameter sweep avec 100 combinaisons, créez un run parent qui représente le sweep entier et des runs enfants pour chaque combinaison. Cela garde votre dashboard propre et permet de voir les résultats du sweep comme un ensemble cohérent plutôt que 100 runs disparates.

Ne supprimez jamais les runs

Même les runs ratés sont informatifs. Ils vous disent ce qui ne fonctionne pas. Utilisez les tags pour marquer les runs (failed, promising, production-candidate) plutôt que de supprimer. Le stockage est bon marché ; la connaissance perdue est coûteuse.

Guide d’implémentation pas à pas

Voici un workflow complet avec MLflow, l’outil le plus universel. Les principes s’appliquent à tous les outils de tracking.

Étape 1 : Installer et démarrer le serveur

# Installation
pip install mlflow

# Serveur local (développement)
mlflow server --host 0.0.0.0 --port 5000

# Serveur production (PostgreSQL + S3)
mlflow server 
  --backend-store-uri postgresql://mlflow:password@db:5432/mlflow 
  --default-artifact-root s3://my-bucket/mlflow-artifacts/ 
  --host 0.0.0.0 --port 5000

Étape 2 : Configurer un experiment et tracker un premier run

import mlflow
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.metrics import accuracy_score, f1_score, precision_score, recall_score

mlflow.set_tracking_uri("http://localhost:5000")
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="gbm-baseline") as run:
    # Logger les paramètres
    params = {
        "model_type": "gradient_boosting",
        "n_estimators": 300,
        "max_depth": 5,
        "learning_rate": 0.1,
        "subsample": 0.8,
        "dataset_version": "churn-data/v2026-03-15"
    }
    mlflow.log_params(params)

    # Entraîner
    model = GradientBoostingClassifier(**{k: v for k, v in params.items()
                                          if k != "dataset_version" and k != "model_type"})
    model.fit(X_train, y_train)
    predictions = model.predict(X_test)

    # Logger les métriques
    mlflow.log_metrics({
        "accuracy": accuracy_score(y_test, predictions),
        "f1": f1_score(y_test, predictions),
        "precision": precision_score(y_test, predictions),
        "recall": recall_score(y_test, predictions)
    })

    # Logger le modèle avec signature
    from mlflow.models import infer_signature
    signature = infer_signature(X_test, predictions)
    mlflow.sklearn.log_model(model, "model", signature=signature)

    # Logger des artefacts supplémentaires
    mlflow.log_artifact("feature_importance.png")

    print(f"Run ID: {run.info.run_id}")

Étape 3 : Comparer les runs via l’API

import mlflow

# Rechercher les meilleurs runs
runs = mlflow.search_runs(
    experiment_names=["churn-prediction"],
    filter_string="metrics.f1 > 0.85",
    order_by=["metrics.f1 DESC"],
    max_results=10
)

# Afficher les résultats
print(runs[["run_id", "params.model_type", "params.n_estimators",
            "metrics.f1", "metrics.accuracy"]].to_string())

# Identifier le meilleur run
best_run = runs.iloc[0]
print(f"nMeilleur run: {best_run.run_id}")
print(f"F1: {best_run['metrics.f1']:.4f}")
print(f"Modèle: {best_run['params.model_type']}")

Étape 4 : Promouvoir le meilleur modèle vers le registry

from mlflow import MlflowClient

client = MlflowClient()

# Enregistrer le modèle du meilleur run dans le registry
model_uri = f"runs:/{best_run.run_id}/model"
mv = mlflow.register_model(model_uri, "churn-predictor")

# Promouvoir via alias (MLflow 3+)
client.set_registered_model_alias("churn-predictor", "champion", version=mv.version)
print(f"Modèle v{mv.version} promu comme champion")

Ce workflow illustre la connexion naturelle entre experiment tracking et model versioning : le tracking produit des candidats, le registry gère les modèles promus.

Experiment tracking pour les applications GenAI

L’experiment tracking pour les LLM et les applications RAG diffère du ML classique sur plusieurs points :

Tracing des appels LLM

Un pipeline GenAI comporte plusieurs étapes : retrieval de documents, appel au LLM, post-processing, appels d’outils. Le tracing capture chaque étape avec ses entrées, sorties, latence et coût. MLflow 3 fournit un module de tracing avec auto-instrumentation pour 20+ frameworks (LangChain, LlamaIndex, OpenAI, Anthropic). W&B propose la même fonctionnalité via W&B Weave.

Tracking des prompts

Le prompt system est l’artefact le plus critique d’une application LLM. Modifier un mot peut changer radicalement le comportement. Le Prompt Registry de MLflow 3 version les prompts avec la même rigueur que les modèles : chaque version est un artefact immuable avec son historique de modifications.

Évaluation avec juges LLM

Les métriques classiques (accuracy, F1) ne s’appliquent pas directement aux LLM. MLflow 3 et W&B supportent l’évaluation avec des juges LLM (un modèle évalue les sorties d’un autre) et le feedback humain structuré. Ces scores d’évaluation sont trackés comme des métriques standard, permettant de comparer les runs GenAI avec la même rigueur que les runs ML classiques.

Tracking des coûts

Chaque appel LLM via API a un coût en tokens. MLflow 3.10 extrait automatiquement les informations de modèle des spans LLM et calcule les coûts, avec une vue agrégée dans l’onglet « Overview » de chaque trace. C’est indispensable pour optimiser le rapport qualité/coût d’une application GenAI en production.

Anti-patterns à éviter

Le tableur comme tracker

Un Google Sheet pour noter les résultats de vos expériences est la solution la plus naturelle et la pire : saisie manuelle (donc erreurs), pas de format standard, aucune connaissance des données et du preprocessing utilisés, aucune automatisation possible. Utilisez un vrai outil de tracking dès le premier run.

Le tracking sélectif

Ne tracker que les runs « intéressants » ou les métriques principales est une fausse économie. Vous ne savez pas à l’avance quels runs seront utiles rétrospectivement. Trackez tout, automatiquement, et filtrez après coup. Le coût de stockage est négligeable comparé à la valeur de l’information perdue.

Les silos par data scientist

Si chaque membre de l’équipe utilise un serveur de tracking local, les résultats sont fragmentés et non comparables. Centralisez le tracking dès que l’équipe dépasse une personne. Un serveur MLflow partagé avec un backend PostgreSQL se met en place en une journée.

Les métriques sans contexte

Un F1-score de 0.94 ne signifie rien si vous ne savez pas sur quelles données il a été calculé, avec quel split, sur quelle population. Loggez systématiquement le contexte (version des données, taille du dataset, distribution des classes) en plus des métriques brutes.

Experiment tracking dans la stack MLOps

L’experiment tracking ne fonctionne pas en isolation. Il se connecte aux autres composants de votre infrastructure MLOps :

La stack typique en 2026 pour une équipe ML mature : MLflow ou W&B pour le tracking et le registry, DVC ou lakeFS pour le versionnage des données, Kubeflow ou Airflow pour l’orchestration des pipelines, et Evidently ou NannyML pour le monitoring en production.

Verdict

L’experiment tracking est le premier investissement MLOps à faire. Avant le model registry, avant l’orchestration, avant le monitoring. Parce que sans tracking, tout le reste est construit sur du sable : vous ne pouvez pas versionner ce que vous n’avez pas enregistré, vous ne pouvez pas automatiser un pipeline dont vous ne connaissez pas les métriques de référence.

Le coût de démarrage est quasi nul : pip install mlflow, mlflow.autolog(), et vous êtes opérationnel en 5 minutes. La valeur est immédiate : dès le deuxième run, vous pouvez comparer avec le premier. Et quand votre équipe grossit, les résultats de chacun sont centralisés, comparables et reproductibles.

Si vous ne faites qu’une seule chose en MLOps cette semaine, installez un outil d’experiment tracking. Tout le reste en découle.