Tracking d'expériences & model registry

Le problème que tu reconnaîtras immédiatement

Sans outillage, un projet ML ressemble à ça : model_final_v2_VRAI_final.pkl, un notebook modifié depuis, et personne ne sait quels hyperparamètres ont produit le modèle en prod. C'est du code non versionné, version cauchemar : le modèle dépend du code ET des données ET de la config ET du hasard.

Le tracking : chaque run est loggé

Un outil de tracking (MLflow, l'open-source de référence ; W&B côté SaaS) enregistre pour chaque entraînement :

import mlflow

with mlflow.start_run():
    mlflow.log_params({"lr": 3e-4, "max_depth": 6, "dataset": "clients_2026_07"})
    model = entrainer(...)
    mlflow.log_metrics({"auc": 0.91, "recall": 0.84})
    mlflow.log_model(model, "churn")     # l'artefact lui-même

Résultat : une UI où tu compares les runs, tries par métrique, et retrouves exactement la provenance de n'importe quel modèle. C'est ta stack d'observabilité, appliquée à l'entraînement.

Le model registry : le artifact repository des modèles

Le registry versionne les modèles promus : churn v12 — staging, churn v11 — production. Chaque version pointe vers son run (donc son code, ses données, ses métriques). Le déploiement devient : « promouvoir v12 en production » — auditable, rollbackable.

Ce qu'il faut versionner (la liste complète)

1. Code : git, évidemment ;
2. Hyperparamètres & config : loggés au run ;
3. Données : hash/version du dataset (DVC ou convention de partitions immuables — leçon 8.4) ;
4. Environnement : lockfile + image (module 3) ;
5. Le modèle produit : registry.

Avec ces cinq-là, n'importe quel modèle de prod est reconstructible — l'exigence de reproductibilité du module 1, outillée.