← Retour au blog

Gouverner les expériences ML

Lucian BLETAN

L’expérimentation en machine learning est par nature chaotique. Sans une structure, elle se transforme rapidement en une collection de notebooks aux noms obscurs, de datasets temporaires et de résultats impossibles à reproduire. Un carnet d’expériences fiable n’est pas une contrainte bureaucratique ; c’est un outil essentiel qui relie une hypothèse à son code, ses données, ses paramètres et ses résultats. L’objectif est simple : ne jamais se demander “quel était ce modèle qui fonctionnait si bien la semaine dernière ?“.

du chaos à la méthode

Sans gouvernance, le processus est une impasse. Avec un suivi structuré, chaque expérience devient une brique de connaissance réutilisable.

approche gouvernée

approche chaotique

est remplacée par

notebook_final_v2_test.ipynb

données_locales.csv

modèle.pkl

résultats oubliés

hypothèse

run id: churn_abc123

code: git commit hash

données: dvc hash

params & métriques

modèle & conclusion tracés

prérequis

  • Un outil de suivi d’expériences (MLflow, DVC, Weights & Biases) ou un simple repo Git avec une convention claire.
  • Une convention de nommage pour les expériences et les modèles.
  • Un stockage centralisé pour les artefacts (modèles, graphiques, datasets).

idées clefs

La gouvernance des expériences repose sur des principes simples pour garantir la reproductibilité et capitaliser sur les connaissances acquises.

expérience ml gouvernée

id unique

un identifiant par run

traçabilité totale

git

dvc

paramètres & métriques

tout est loggué

artefacts versionnés

modèles, graphiques, etc.

conclusion actionnable

synthèse en 3 lignes

pas à pas

étape 1: structurer et tracer chaque run

Chaque exécution d’un script d’entraînement est un “run”. Il doit être identifié de manière unique et toutes ses métadonnées doivent être enregistrées. La plupart des outils MLOps automatisent cela.

# Exemple de métadonnées enregistrées pour un run
run_id: "churn_model_20220508_142015"
git_commit: "f4a1b2c3"
data_version: "users_v2.1"
status: "completed"

params:
  model_type: "RandomForestClassifier"
  max_depth: 6
  learning_rate: 0.05

metrics:
  auc: 0.802
  f1_score: 0.61

étape 2: versionner les données et les modèles

Le code est versionné avec Git. Les données et les modèles, qui sont souvent de gros fichiers binaires, doivent l’être avec un outil adapté comme DVC (Data Version Control).

# Ajouter le dataset d'entraînement au suivi de DVC
dvc add data/training_set.csv

# Ajouter le modèle entraîné au suivi
dvc add models/churn_model.joblib

# DVC crée des fichiers .dvc légers que l'on peut commiter avec Git
git add data/training_set.csv.dvc models/churn_model.joblib.dvc
git commit -m "feat: train new churn model with user v2.1 data"

étape 3: publier une synthèse concise

Le but n’est pas d’accumuler des métriques, mais de générer de la connaissance. Chaque expérience doit se conclure par une synthèse simple.

  • Ce qui a fonctionné: “Augmenter la profondeur de l’arbre de 4 à 6 a amélioré l’AUC de 2%.”
  • Limites et observations: “Le modèle reste peu performant sur le segment des nouveaux utilisateurs.”
  • Prochaine étape: “Tester l’ajout de la feature ‘temps_session_moyen’.“

pièges frequents

  • Symptôme: Personne ne retrouve une expérience passée car les noms sont du type “test_1”, “test_final”.

    • Cause: Noms flous et manque de conventions.
    • Correctif: Imposer une convention de nommage stricte pour les expériences (ex: [objectif]_[modèle]_[date]).
  • Symptôme: Impossible de ré-entraîner un modèle qui donnait de bons résultats il y a 3 mois.

    • Cause: Les artefacts (données, modèle) sont stockés sur le disque local d’un data scientist qui a quitté l’entreprise.
    • Correctif: Utiliser un stockage centralisé et versionné pour tous les artefacts (DVC, MLflow).
  • Symptôme: Les rapports d’expériences sont des documents de 10 pages que personne ne lit.

    • Cause: Rapports trop verbeux et pas orientés action.
    • Correctif: Imposer un format de synthèse court (3 à 5 points clés maximum). L’important est la conclusion, pas le détail du processus.

faq

  • Faut-il un outil MLOps complexe pour commencer ? Non. Vous pouvez commencer avec un simple fichier README.md dans un repo Git, où chaque expérience est une section. L’important est de prendre l’habitude de tout tracer. Les outils comme MLflow deviennent utiles lorsque le nombre d’expériences et de contributeurs augmente.

  • Quelle est la chose la plus importante à tracer ? Si vous ne deviez tracer qu’une seule chose, ce serait le lien entre la version du code (commit Git), la version des données, et les métriques de performance obtenues. C’est le triptyque de base de la reproductibilité.