Tracking & gestion de modèles — donner une mémoire au système : chaque expérience tracée, chaque modèle versionné, chaque décision prouvable.
Le fil rouge · où on en est
En boîte, portable — et amnésique
Bloc 4 : le système vit dans une image Docker, identique sur toutes les machines. Mais demandez-lui d'où vient son modèle : silence. Combien d'essais avant celui-là ? Quels réglages ? Quel score ? Personne ne sait — et rien, nulle part, ne s'en souvient.
Mission du bloc 5 : donner une mémoire au système — un carnet de bord que personne ne peut oublier de remplir.
MLflowtrackingregistry
L'objectif du bloc
À la fin du bloc, chaque expérience est tracée, chaque modèle versionné — et l'API sert toujours la bonne version
Et vous savez le prouver : qui a entraîné quoi, quand, avec quels réglages, quel score — et quelle version tourne en production, à la seconde où on vous le demande.
Bloc 5 · 4 h · théo 0h30 / prat 3h30 · jours 2–3
Quatre missions, un carnet
1h20
Tracker les expériencesParamètres, métriques, artefacts — et comparer les runs dans l'UI.
pratique
1h10
Juger au-delà de la moyenneAnalyse d'erreurs & performance par segment — la théorie du bloc vit ici.
théo 0h30 + prat 0h40
0h50
Gérer le cycle de vieModel Registry : versioning, staging → production → archivage.
pratique
0h40
Brancher l'API au registreIntégration MLflow ↔ FastAPI : servir le modèle depuis le registry.
pratique
Réparties sur deux jours : 3 h le jour 2, 1 h le jour 3 — le carnet, lui, ne fermera plus.
Acte 1
L'amnésie
Rappel du bloc 2 · la douleur
Huit modèles, zéro souvenir
Lundi, bloc 2 : huit modèles entraînés, des scores recopiés dans un tableau markdown, des .pkl aux noms de plus en plus désespérés. Vous l'avez vécu — et ce n'était qu'un après-midi, seul, sur un seul projet.
Maintenant, imaginez six mois, cinq personnes, trente modèles.
model_final.pkl
model_final_v2.pkl
model_final_v2_VRAI.pkl model_final_v2_VRAI_celui_la.pkl # et le tableau markdown ? écrasé au dernier commit.
Votre dossier de lundi. Sans remède, c'est votre dossier pour toujours.
L'histoire qui fait mal · l'audit
3 mars, 9 h 12. Le régulateur demande : « Quel modèle a bloqué cette transaction — entraîné sur quelles données, avec quels réglages ? »
Dans la salle : silence. Le modèle a changé quatre fois depuis. Personne ne sait lequel tournait ce jour-là — et « on ne sait plus » n'est pas une réponse qu'un régulateur bancaire accepte.
L'addition du silence
Ce que l'amnésie coûte, très concrètement
La reproductibilité
Impossible de refaire le modèle d'il y a trois mois : le code a bougé, les données aussi, les réglages sont perdus. Ce qui ne se reproduit pas ne se débogue pas.
La conformité
En banque, chaque décision automatique doit être explicable a posteriori. Un modèle introuvable, c'est un risque réglementaire — avec amende au bout.
Le temps d'équipe
Re-tester ce qui avait déjà été testé, re-perdre des conclusions déjà acquises, se disputer sur « qui avait le bon score ». Des semaines, chaque année.
Le pire : ces coûts sont invisibles au quotidien. On ne les voit que le jour où on en a besoin — le jour de l'audit, de l'incident, du départ d'un collègue.
Le vrai périmètre
Ce qui définit vraiment « un modèle »
Ingrédient 1
Le code
La version exacte du script d'entraînement — un commit Git, pas « à peu près la branche main de la semaine dernière ».
Ingrédient 2
Les données
Quel dataset, quelle version, quel split train/test. Les mêmes réglages sur d'autres données donnent un autre modèle.
Ingrédient 3
Les réglages
Hyperparamètres, features, seuil de décision — tout ce que vous avez choisi à la main pendant l'itération du bloc 2.
Ingrédient 4
L'environnement
Les bibliothèques et leurs versions — celui qu'on a justement figé au bloc 4 avec Docker. Un ingrédient déjà sous contrôle.
Changez un seul des quatre : ce n'est plus le même modèle. Et un .pkl seul ne raconte aucun des quatre.
La règle du bloc
Pas écrit, pas arrivé
Une expérience qui n'est pas enregistrée est une expérience qui n'a jamais eu lieu.
Et la mémoire humaine ne compte pas : elle part en vacances, change de projet, quitte l'entreprise. La mémoire doit être automatique — écrite par la machine, au moment où ça se passe, sans discipline requise. C'est exactement le travail de MLflow.
Acte 2
Le carnet de bord automatique
Feynman · 3 minutes
Le carnet de labo qui s'écrit tout seul
Les chimistes le font depuis deux siècles : une manipulation, une page — conditions, dosages, résultat. MLflow fait pareil pour vos modèles, sans stylo : quelques lignes dans votre script, et chaque entraînement écrit sa page lui-même.
Vous ne tiendrez jamais le carnet à jour à la main. La machine, si — à chaque fois, sans exception.
# la page du run, écrite toute seule
run 2026-07-07 14:32 · run-a4f2
C=0.5 · class_weight=balanced
pr_auc=0.842 · coût=28 750 €
model.pkl · pr_curve.png · git 4f2a91c
Un entraînement = une page. Personne n'a rien recopié.
La page du carnet
Un run, quatre rubriques
Rubrique 1
Les paramètres
Tout ce que vous avez choisi : C, class_weight, seuil, liste de features. Les réglages qui font ce modèle-là et pas un autre.
Rubrique 2
Les métriques
PR-AUC, precision, recall, coût métier — les chiffres du verdict. Et bientôt : les mêmes, par segment.
Rubrique 3
Les artefacts
Les fichiers produits : le modèle lui-même, la courbe PR, le csv des pires erreurs. Attachés au run, pour toujours.
Rubrique 4
Le contexte
Commit Git, date, durée, auteur — capturés gratuitement. Exactement la partie qu'on oublie toujours de noter à la main.
Le coût d'entrée
Quatre lignes dans votre train.py
with mlflow.start_run():
mlflow.log_param("C", 0.5)
mlflow.log_metric("pr_auc", 0.842)
mlflow.sklearn.log_model(model, "model") # le .pkl a trouvé une maison
C'est tout le coût d'entrée : votre train.py du bloc 2, plus ces lignes — et plus jamais d'amnésie. Le carnet vit dans mlruns/, et se lit dans le navigateur.
mlflow uilocalhost:5000aucune infra requise pour démarrer
Le vocabulaire · trois mots
Le run, l'expérience, le serveur
Un run est une page. Une expérience est un classeur. Le tracking server est la bibliothèque de l'équipe.
Aujourd'hui, la bibliothèque tient sur votre machine — un simple dossier mlruns/. En entreprise, c'est un serveur partagé : toute l'équipe écrit dans le même carnet, et l'auditeur du 3 mars obtient sa réponse en trente secondes.
L'UI · avant / après
Fini, le tableau markdown
Lundi · à la main
Le tableau markdown
Recopier chaque score sans se tromper — en théorie
Illisible à dix runs, perdu au premier commit malheureux
Aujourd'hui · automatique
L'UI MLflow
Chaque run enregistré tout seul, à la seconde près
Trier par PR-AUC, filtrer par paramètre — deux clics
Même information, mais l'une demande de la discipline et l'autre zéro. En MLOps, ce qui repose sur la discipline finit toujours par casser.
Le geste clé de l'UI
Trier, filtrer, comparer
Sélectionnez trois runs, cliquez sur compare : les paramètres qui diffèrent sont surlignés, les métriques tracées côte à côte. « Qu'est-ce qui a fait gagner le run 7 ? » a enfin une réponse visuelle — pas une réponse de mémoire.
La boucle du bloc 2 — hypothèse, changement, mesure — a maintenant un tableau de bord.
La vue comparaison : les réglages en face des scores.
La discipline du carnet
Ce qu'on logge — et ce qu'on ne logge jamais
Toujours
Paramètres, métriques, le modèle, le commit. La page minimale — celle qui répond à l'auditeur et permet de reproduire.
Souvent
La courbe PR, la matrice de confusion, le csv des pires erreurs. Tout ce qui aidera l'analyse de la semaine prochaine.
Jamais
Les données brutes des clients. Le carnet trace un pointeur et un hash du dataset — pas les transactions elles-mêmes.
Réflexe bancaire : le carnet doit prouver sans exposer. Tracer la provenance des données, oui — les recopier, non.
Acte 3 · la théorie du bloc vit ici
Au-delà de la moyenne
Théorie · 0h30
Un modèle bon en moyenne peut être mauvais exactement là où ça coûte
La PR-AUC globale résume 57 000 transactions de test en un chiffre. Mais la banque ne perd pas d'argent « en moyenne » — elle le perd sur les gros montants, la nuit, sur des segments précis. C'est là qu'il faut regarder.
Où découper
Les segments qui comptent, pour la fraude
Segment 1
Par montant
Rater une fraude à 4 800 € ou à 12 €, ce n'est pas la même perte. Le recall sur les gros montants est LA métrique qui parle au métier.
Segment 2
Par heure
La nuit : moins de transactions, plus de fraudes, moins d'analystes éveillés. Un modèle qui décroche à 3 h du matin coûte cher en silence.
Segment 3
Par profil de V
Les V du bloc 2 dessinent des familles de comportement. Un modèle peut briller sur une famille et rater l'autre — la moyenne n'en dira rien.
Segment 4
Par période
Début vs fin du dataset : si la performance glisse avec le temps, vous venez de rencontrer le drift — le grand sujet du bloc 7.
Le piège de l'après-coup
Découper sans se mentir
Le piège
Segments choisis après coup
On découpe jusqu'à trouver un segment où le modèle brille
On en trouve toujours un — et il ne prouve rien
La méthode
Segments définis à l'avance
Choisis avec le métier, avant de regarder les résultats
Les mêmes pour tous les modèles — la comparaison reste honnête
C'est le même réflexe d'honnêteté que le test intouchable du bloc 2 — appliqué au découpage plutôt qu'aux données.
Du rituel manuel à l'artefact
L'analyse d'erreurs, version outillée
# le rituel du bloc 2, devenu artefact du run
errors.sort_values("Amount").to_csv("worst_errors.csv")
mlflow.log_artifact("worst_errors.csv")
# et la performance par segment, loggée comme le reste
for seg, part in test.groupby("segment"):
mlflow.log_metric(f"recall_{seg}", recall(part))
Trier les fraudes ratées, chercher le pattern : le rituel ne change pas — mais il laisse une trace attachée à chaque run. Six mois plus tard, les erreurs du run 7 sont encore là, consultables, comparables.
Story · lequel choisiriez-vous ?
Le duel : la moyenne contre le segment
Modèle A — le champion du classement
PR-AUC globale 0,86. Trié premier dans l'UI. Mais regardez le segment : au-dessus de 1 000 €, il rate une fraude sur trois.
31 % des fraudes > 1 000 € ratées
Modèle B — trois points derrière
PR-AUC globale 0,83. Moins bien classé. Mais sur les gros montants — là où l'argent part vraiment — il attrape presque tout.
9 % des fraudes > 1 000 € ratées
La moyenne dit A. Le coût métier dit B — les fraudes chères sont précisément celles qu'on ne peut pas rater. Sans métriques par segment, vous auriez promu A sans même voir le débat.
Ce que ça change dans le carnet
Le verdict, en trois regards
PR-AUC pour trier les candidats, segments pour voir où ils pèchent, coût métier pour trancher.
La performance par segment devient une métrique comme les autres — loggée dans chaque run, triable dans l'UI. Et la décision finale reste celle du bloc 2 : convertie en euros. Trois regards, un verdict — et tout est écrit.
Acte 4
Le registre
Le problème d'après
Du fichier baladeur au registre central
Le monde des .pkl
Un fichier qu'on se passe
Mail, clé USB, dossier partagé — lequel est le bon ?
Personne ne sait lequel tourne en prod, ni depuis quand
Le Model Registry
Un nom, des versions, des stages
Un nom officiel — fraud-detector — et des versions : v1, v2, v3…
Chaque version pointe vers son run : params, métriques, erreurs, tout
Le registre ne stocke pas « un fichier » : il relie chaque version du modèle à toute son histoire. Le tracking répond « d'où il vient » ; le registre répond « lequel sert ».
Versions & stages
Le cycle de vie officiel d'une version
Un seul état officiel par version, des mots standard que tout le métier partage. Archived n'est pas la corbeille : l'audit du 3 mars peut toujours rappeler v1 à la barre.
Le geste qui change tout
La promotion : une décision tracée
Promouvoir en production n'est plus un copier-coller — c'est un acte enregistré : qui, quand, pourquoi.
La transition Staging → Production laisse une trace horodatée et signée, avec la justification en commentaire. Le jour de l'audit, la réponse tient en une ligne : v3, promue le 28 février par Lina — « recall gros montants +22 %, à coût égal ».
Gouvernance · avant-goût du bloc 6
Qui a le droit de promouvoir ?
Pas n'importe qui
En banque, promouvoir est un rôle : quelques personnes nommées — pas « celui qui a le mot de passe du serveur ».
Pas n'importe quand
Un modèle ne monte qu'après ses preuves en staging : métriques globales, segments, coût métier — le verdict en trois regards.
Pas sans raison
La justification écrite est obligatoire. Au bloc 6, la chaîne CI ajoutera son propre gardien : aucun modèle qui régresse ne passera.
Aujourd'hui, ces règles reposent sur vous. Au bloc 6, elles deviendront des barrières automatiques — on prend le réflexe maintenant.
Le raccord · le bloc 3 rencontre le bloc 5
L'API ne connaît plus de nom de fichier
# avant — bloc 3 : un fichier qu'on espère être le bon
model = joblib.load("model_final_v2_VRAI.pkl")
# après — bloc 5 : une adresse officielle
model = mlflow.pyfunc.load_model("models:/fraud-detector@production")
L'API demande « la version en production » au registre — plus jamais de fichier baladeur. Changer de modèle ne touche ni au code, ni à l'image Docker : on repointe, l'API suit.
Teaser · bloc 7
Se tromper devient réversible
v3 déçoit en production ? On repointe : v2 redevient Production, v3 part en archive avec la raison de son retrait. Trente secondes, zéro redéploiement, zéro ligne de code — l'API sert l'ancienne version à son prochain rechargement.
Un système qui sait revenir en arrière est un système qu'on ose faire avancer.
# v3 → Archived · v2 → Production # durée totale : 30 secondes, tracée
Le rollback de modèle — on l'automatisera au bloc 7.
Démo live · à vous de jouer
Trois runs, une promotion
L'expérience · fraud-detector
Le registre · fraud-detector
v2Productionpromu mardi · « baseline battue »
v1Archivedla baseline du bloc 2
Trois runs minimum avant de promouvoir — comme dans la vraie vie.
Avant de coder · l'essentiel
Cinq réflexes à emporter
Réflexe 1
Pas écrit, pas arrivé
Chaque entraînement écrit sa page : paramètres, métriques, artefacts, commit — automatiquement.
Réflexe 2
Comparer dans l'UI, pas de mémoire
Trier, filtrer, comparer les runs. Le tableau markdown est mort lundi soir.
Réflexe 3
Juger par segment
La moyenne cache. Segments définis à l'avance, métriques par segment loggées, verdict en euros.
Réflexe 4
La production est une adresse
models:/fraud-detector@production — pas un fichier. Promotion et rollback = repointer, tracé.
Et le cinquième : la promotion se justifie par écrit — qui, quand, pourquoi. C'est cette ligne-là qui répond à l'auditeur.
Acte 5 · lab
À vous : 3h30 au clavier
Mission 1 / 4 · 1h20 · pratique
Tracer et comparer vos runs
Instrumentez votre train.py du bloc 2 avec MLflow : paramètres, métriques (dont le coût métier), le modèle et la courbe PR en artefacts. Puis rejouez vos itérations de lundi — cinq runs minimum — et comparez-les dans l'UI.
Livrable : cinq runs dans l'UI, triés par PR-AUC — et la réponse à « le run 7, c'était quoi déjà ? » en deux clics.
Binômes du bloc 2 : reprenez votre meilleur modèle — il va enfin avoir un état civil.
Mission 2 / 4 · théo 0h30 + prat 0h40
Juger au-delà de la moyenne
Définissez vos segments avec le formateur — montant, heure — avant de regarder les résultats. Puis loggez recall et coût par segment dans chaque run, et le csv des pires erreurs en artefact. Enfin, rejouez le duel : votre meilleur modèle global l'est-il aussi sur les fraudes > 1 000 € ?
Livrable : métriques par segment visibles dans l'UI, worst_errors.csv attaché à chaque run — et votre verdict, argumenté en euros.
groupby(segment)log_metric(f"recall_{seg}")log_artifactsegments fixés à l'avance
La théorie de l'acte 3 vit ici : si vos deux meilleurs modèles s'inversent sur un segment, vous tenez le débat.
Mission 3 / 4 · 0h50 · pratique
Ouvrir le registre
Enregistrez votre champion sous le nom fraud-detector, créez v1 puis v2 (votre challenger), faites-les passer par Staging, promouvez la meilleure en Production — justification écrite obligatoire — et archivez l'autre.
Livrable : un registre à deux versions, une seule en Production, et une raison de promotion qu'un auditeur comprendrait.
register_modelStaging → ProductionArchiveddescription de version
Testez le rollback : repointez v1 en Production, constatez, remettez v2. Trente secondes, chrono en main.
Mission 4 / 4 · 0h40 · pratique
Brancher l'API au registre
Modifiez votre FastAPI du bloc 3 : au démarrage, elle charge models:/fraud-detector@production au lieu d'un chemin de fichier. Testez. Puis promouvez une autre version et vérifiez que l'API la sert — sans toucher au code.
Definition of done : POST /predict répond depuis la version Production — et un changement de stage change le modèle servi, preuve à l'appui.
C'est le raccord de la semaine : bloc 2 (le modèle), bloc 3 (l'API), bloc 4 (la boîte), bloc 5 (la mémoire) — soudés.
La boucle est bouclée
« Quel modèle tournait le 3 mars, entraîné comment, promu par qui ? » — vous répondez en trente secondes
C'est le test final du bloc : des runs tracés, des métriques par segment, un registre avec une seule version en Production, une API qui la sert. Le silence de l'acte 1 est devenu une réponse.
Le fil rouge · fin du bloc 5
Le système a une mémoire
Regardez la carte : le carnet de bord est branché sous le cerveau, et la puce de version — v3 · prod — dit au monde entier quel modèle sert. Chaque essai laisse une trace, chaque promotion un motif.
Mais la qualité repose encore sur la discipline humaine : rien n'empêche de promouvoir un mauvais modèle un vendredi à 18 h. Il manque un gardien automatique.
tracé ✓versionné ✓gardé… pas encore
La suite
Plus personne ne livre à la main
Bloc 6 — CI/CD, validation des données & gouvernance : chaque changement passe la chaîne qualité avant de toucher la production.
· MLOps