03 h 47. Tallinn. 900 €. La carte de Mme Martin, encore.
Lundi matin, cette transaction passait sans qu'aucun système ne la voie. Cet après-midi, elle va traverser tout ce que vous avez construit — et on va la suivre, milliseconde par milliseconde.
Formation MLOps · Dotika · Bloc 8 · 3 h
Le système
vivant
Assemblage final & présentations — toutes les briques existent. Aujourd'hui, tout respire ensemble — et vous le prouvez en direct.
01 / 34
Le fil rouge · où on en est
Sept briques, construites de vos mains
Le modèle, l'API, le conteneur, la mémoire, la qualité, le cluster, la vigie : chaque pièce a été construite, testée, versionnée cette semaine. Sur la carte, presque tout est allumé.
Mission du bloc 8 : faire respirer les briques ensemble — et le prouver, en direct, devant les autres.
assemblage end-to-enddémo liverevue de pairs
· MLOps02 / 34
L'objectif du bloc
À 16 h, chaque binôme démontre un pipeline complet : commit → CI → registry → canary → monitoring, en direct
Pas un slide, pas une capture d'écran : un vrai commit poussé devant tout le monde, qui traverse toute la chaîne jusqu'au dashboard. C'est la preuve des six compétences de la semaine.
· MLOps03 / 34
Bloc 8 · 3 h · théo 0h30 / prat 2h30
Trois temps pour finir
1h30
Assemblage du pipeline complet end-to-endLa checklist en main : commit témoin, CI, image, canary, registry, dashboard — jointure par jointure.
pratique
1h00
Présentations des projets & revue de code entre pairsDémo de 5 minutes par binôme, puis revue croisée avec la grille : reproductibilité, tests, clarté, gouvernance.
pratique
0h30
Clôture & perspectives (LLMOps, plateformes managées, CT)Le chemin parcouru, et ce qui vous attend après : continuous training, cloud managé, modèles géants.
théorie
· MLOps04 / 34
Acte 1
Boucler
la boucle
05 / 34
Le fil rouge · retour au point de départ
· MLOps06 / 34
La transaction traverse tout
300 millisecondes
dans votre système
L'API reçoit la transaction, interroge le modèle v3 chargé depuis le registry, rend son verdict : score 0,94, bloquée. L'alerte part chez l'analyste, son feedback est journalisé, le monitoring enregistre la prédiction et surveille la dérive. Toute la semaine tient dans ce trajet.
Mme Martin dort. Le système, lui, ne dort jamais.
POST /predict {"amount": 900, "hour": 3, …}
← modèle : v3 · Production · registry MLflow
→ score 0.94 · verdict : FRAUDE · 8 ms
→ alerte → file analyste · feedback journalisé
→ métriques : Prometheus · drift : OK
← modèle : v3 · Production · registry MLflow
→ score 0.94 · verdict : FRAUDE · 8 ms
→ alerte → file analyste · feedback journalisé
→ métriques : Prometheus · drift : OK
Un trajet, cinq briques — chaque ligne existe grâce à un bloc de la semaine.
· MLOps07 / 34
L'état des lieux
Tout existe — mais est-ce que tout se parle ?
Chaque brique a été testée seule. Un système, c'est autre chose : c'est les jointures. Et les jointures, personne ne les a encore toutes vérifiées d'un coup.
FastAPI ✓Docker ✓MLflow ✓CI/CD ✓Kubernetes ✓Prometheus · Grafana ✓le tout, bout à bout… à prouver
Un tas de briques n'est pas une maison. L'assemblage de cet après-midi, c'est vérifier chaque jointure, dans l'ordre — avec une checklist, comme les pilotes avant le décollage.
· MLOps08 / 34
La définition qui guide tout
C'est quoi, un système « assemblé » ?
Un système est assemblé quand un seul commit suffit à changer la production — sans qu'aucune main ne touche un serveur.
Du git push au modèle servi : tests, image, déploiement canary, bascule — tout s'enchaîne tout seul, et tout se voit sur le dashboard. Si une seule étape réclame une intervention manuelle, il reste un trou. C'est ce trou qu'on chasse cet après-midi.
· MLOps09 / 34
L'outil de l'après-midi
La checklist d'assemblage, six jointures
Jointure 1
Le commit déclenche la CI
git push, et le pipeline s'allume tout seul — sans clic, sans « lance-le pour moi ».
Jointure 2
La CI pousse l'image
Tests verts → image buildée, taguée avec le commit, envoyée au registry d'images.
Jointure 3
Le cluster déploie en canary
La nouvelle version reçoit d'abord une fraction du trafic — le reste ne bouge pas.
Jointure 4
L'API sert la version Production du registry
Le modèle vient de MLflow, pas d'un .pkl copié à la main. /health annonce sa version.
Jointure 5
Le monitoring voit tout
Latence, volume, taux d'alerte : le dashboard bouge quand le trafic bouge.
Jointure 6
L'alerte drift pointe vers le réentraînement
Quand la vigie crie, on sait quoi faire et où : la boucle est bouclée.
· MLOps10 / 34
Les trous fréquents
Les 5 pannes classiques de l'assemblage
Panne 1
L'image tourne, mais sert le vieux modèle
Un :latest qui ne l'est plus, ou un modèle figé dans l'image au build. Diagnostic : /health doit annoncer la version — croyez-le, pas vos souvenirs.
Panne 2
La CI est verte, le cluster n'a rien vu
Le manifest pointe toujours l'ancien tag d'image. Diagnostic : kubectl describe deployment — quelle image tourne vraiment ?
Panne 3
Ça marchait en local, ça tombe en prod
Variable d'environnement ou secret manquant dans le manifest. Diagnostic : kubectl logs, les dix premières lignes disent tout.
Panne 4
Le canary reçoit 0 % ou 100 % du trafic
Labels et selectors qui ne se croisent pas. Diagnostic : kubectl get endpoints — qui est vraiment derrière le service ?
Et la cinquième : le dashboard plat — Prometheus scrape le mauvais port. Ouvrez /metrics à la main : si rien n'y vit, rien ne vivra sur Grafana.
· MLOps11 / 34
La méthode quand ça casse
Debugger un système,
pas un script
Quand la chaîne casse, on ne relance pas tout « pour voir ». On suit la transaction : on remonte la chaîne maillon par maillon, du symptôme vers la cause, en posant à chaque brique la même question — toi, tu vois quoi ?
Le bug vit toujours à une jointure. Trouvez la dernière brique qui dit la vérité : la panne est juste après.
# remonter la chaîne, dans l'ordre
curl api/health # quelle version répond ?
kubectl logs deploy/fraud-api # des erreurs ?
kubectl describe pod # image ? env ? secrets ?
mlflow models … # v3 bien en Production ?
curl api/metrics # est-ce que ça respire ?
curl api/health # quelle version répond ?
kubectl logs deploy/fraud-api # des erreurs ?
kubectl describe pod # image ? env ? secrets ?
mlflow models … # v3 bien en Production ?
curl api/metrics # est-ce que ça respire ?
Cinq questions, une par brique — 90 % des pannes tombent avant la troisième.
· MLOps12 / 34
Acte 2
Prouvez-le
13 / 34
Feynman, jusqu'au bout
Savoir l'expliquer,
c'est l'avoir compris
Toute la semaine, chaque concept a été expliqué depuis zéro — méthode Feynman. Dernier exercice : c'est vous qui expliquez. Une démo qui marche prouve que le système tient ; une explication claire prouve que vous tenez le système.
· MLOps14 / 34
Le format · 5 minutes par binôme
La démo de 5 minutes, minute par minute
min 0–1
Le commitUne modification réelle — un paramètre, une feature — poussée en direct, devant tout le monde.
git push
min 1–3
La chaîneLa CI passe, l'image part, le canary monte — vous commentez ce qui se passe, brique par brique.
CI · registry · canary
min 3–4
La preuve/predict répond avec la nouvelle version, /health la confirme, le registry est d'accord.
curl · MLflow
min 4–5
Le dashboardLatence, prédictions, drift : le système vit sous les yeux du public.
Grafana
· MLOps15 / 34
Trois conseils de présentation
Montrer, assumer, parler métier
Montrez, ne racontez pas
Le terminal et le dashboard valent mille slides. Si ça se voit à l'écran, inutile de le dire — commentez, ne récitez pas.
Assumez les ratés
Une démo qui accroche et que vous diagnostiquez calmement — checklist en main — impressionne plus qu'une vidéo parfaite.
Parlez métier
Commencez par Mme Martin, finissez par les euros économisés. La technique, c'est le milieu du sandwich.
Le public n'évalue pas votre aisance : il vérifie que le système tient et que vous savez dire pourquoi.
· MLOps16 / 34
La revue de code croisée
Quatre questions à poser au dépôt d'un autre
Reproductibilité
Je clone, je lance : ça tourne ?
Un README honnête, un docker compose up qui suffit. Le test ultime du bloc 4 — appliqué par un inconnu.
Tests
Que protège vraiment la CI ?
Les tests couvrent-ils l'API et le contrat du modèle ? Un test cassé bloque-t-il réellement le merge ?
Clarté
Le code se lit-il sans guide ?
Des noms qui disent ce qu'ils font, une structure src/ prévisible, pas de cellule morte ni de code zombie.
Gouvernance
Qui a promu le modèle, et où est la trace ?
Le passage en Production est-il visible dans MLflow ? Peut-on savoir quel humain a approuvé quoi, quand ?
· MLOps17 / 34
Revue croisée · les règles du jeu
On relit le code, jamais le codeur
Ce qu'on donne
Des questions plutôt que des sentences, des pistes plutôt que des reproches — et des compliments précis : « ce test-là est malin » vaut mieux que « c'est bien ».
2 points forts relevés, minimum
Ce qu'on propose
Chaque critique arrive avec une piste concrète et actionnable. Une revue qui ne dit que « bof » n'apprend rien à personne.
1 amélioration concrète, proposée par écrit
En entreprise, la revue de pairs est le rituel qui fait progresser le plus vite. Autant prendre le pli aujourd'hui.
· MLOps18 / 34
Acte 3 · théo 0h30
Et après ?
19 / 34
Le chemin parcouru
Lundi matin, vendredi soir
Lundi matin
Un notebook sur un laptop
- Un modèle qui meurt quand l'ordinateur se ferme
- Personne ne peut l'interroger — sauf son auteur
- Aucune trace des expériences, aucune garantie
Vendredi soir
Un système en prod, surveillé
- Une API conteneurisée, déployée en canary sur un cluster
- Chaque modèle versionné, chaque déploiement testé en CI
- Le drift surveillé, l'alerte prête, le rollback à un clic
· MLOps20 / 34
Les promesses du bloc 1 · vérifiées
Six compétences, prouvées sur un vrai projet
✓ 01Rendre un système ML reproductible — il tourne partout, à l'identiqueDocker · bloc 4
✓ 02Transformer un modèle en service interrogeable en temps réelFastAPI · bloc 3
✓ 03Tracer chaque expérience et gérer le cycle de vie des modèlesMLflow · bloc 5
✓ 04Automatiser la qualité — rien ne part en prod sans preuveCI/CD · bloc 6
✓ 05Déployer à l'échelle, sans coupure, avec retour arrièreKubernetes · canary · bloc 7
✓ 06Surveiller un modèle en prod et détecter sa dérive avant l'incidentmonitoring · drift · bloc 7
La sixième se coche dans une heure, à la fin de votre démo. Ce sont les six promesses du lundi matin — tenues.
· MLOps21 / 34
Perspectives · où vous en êtes
Les trois niveaux de maturité MLOps
Niveau 0 — tout à la main
Le notebook du lundi : entraînement manuel, déploiement copier-coller, aucune trace. C'est là que vivent encore beaucoup d'équipes.
Niveau 1 — pipeline automatisé
Votre système du vendredi : CI/CD, registry, canary, monitoring. Un commit suffit à changer la prod, avec preuves.
Niveau 2 — continuous training
Le système se réentraîne tout seul quand la vigie l'exige. La prochaine marche — et elle est plus proche qu'elle n'en a l'air.
Vous avez fait en une semaine le saut que beaucoup d'équipes mettent des années à faire : du niveau 0 au niveau 1.
· MLOps22 / 34
Perspective 1 · continuous training
Le monitoring appuie
sur le bouton
Aujourd'hui, l'alerte drift ouvre un ticket et un humain relance l'entraînement. Au niveau 2, l'alerte déclenche le pipeline : réentraînement sur données fraîches, évaluation contre le champion en place, promotion seulement s'il fait mieux. Les mêmes briques que les vôtres — orchestrées.
Vous avez déjà toutes les pièces. Le continuous training, c'est un déclencheur de plus — et beaucoup de discipline.
# le pipeline de niveau 2, en pseudo-config
on: drift_alert
steps:
- retrain: données des 30 derniers jours
- evaluate: challenger vs champion
- promote: si PR-AUC ↑ et coût ↓ — sinon, on garde v3
on: drift_alert
steps:
- retrain: données des 30 derniers jours
- evaluate: challenger vs champion
- promote: si PR-AUC ↑ et coût ↓ — sinon, on garde v3
La boucle complète : la vigie du bloc 7 nourrit l'entraînement du bloc 2.
· MLOps23 / 34
Perspective 2 · le cloud managé
SageMaker, Vertex AI, Databricks : du déjà-vu
Les grandes plateformes vendent exactement ce que vous venez de construire — registry, pipelines, endpoints, monitoring — mais gérés pour vous.
SageMaker (AWS)
Endpoints managés, model registry, pipelines : vos blocs 3, 5 et 6 — facturés à l'heure, sans cluster à tenir.
Vertex AI (Google)
Entraînement, déploiement, monitoring de drift intégrés : votre bloc 7 en mode « quelqu'un d'autre porte le pager ».
Databricks
MLflow y est natif — normal, ce sont ses créateurs. Votre bloc 5, à l'échelle de l'entreprise.
Vous savez ce qui se passe sous le capot : c'est ce qui distingue le pilote de l'utilisateur. Les plateformes passent, les concepts restent.
· MLOps24 / 34
Perspective 3 · LLMOps
Les mêmes douleurs, avec des modèles géants
Prompts
Le prompt est le nouvel hyperparamètre
Il se versionne, se teste, se rollback — votre réflexe Git du bloc 1 s'applique mot pour mot.
Evals
Pas de PR-AUC pour du texte
Des jeux d'évaluation, des juges automatiques, de la relecture humaine — mais la même question : comment prouver que c'est bon ?
Coûts
Chaque requête a un prix
Le monitoring compte les tokens autant que la latence. Le coût métier du bloc 2, à la puissance dix.
Déjà-vu
« Ça marchait hier », « quelle version répond ? »
Les douleurs du lundi matin, à l'identique. Bonne nouvelle : vous connaissez déjà les remèdes.
· MLOps25 / 34
Perspectives · où pratiquer ensuite
Trois façons d'entretenir le muscle
Refaire le pipeline
Un autre dataset — churn, spam, défauts de paiement : mêmes briques, nouveau problème. Le meilleur portfolio possible.
Contribuer
MLflow, FastAPI, Evidently sont open source. Une issue bien documentée ou un correctif de doc : un excellent premier pas.
Se certifier
AWS ML Specialty, GCP ML Engineer, CKA côté cluster : elles valident ce que vous savez déjà faire de vos mains.
Le MLOps s'entretient comme il s'apprend : en construisant. Un système par trimestre, et vous serez la personne qu'on écoute.
· MLOps26 / 34
Avant de se quitter · l'essentiel
Cinq réflexes à emporter — pour toujours
Réflexe 1
Tout versionner
Code, données, modèles, config : ce qui n'est pas versionné n'existe pas — et ne se répare pas.
Réflexe 2
Automatiser la preuve
Rien ne part en prod sans qu'une machine l'ait vérifié. La confiance se construit en CI, pas en réunion.
Réflexe 3
Déployer progressivement
Canary d'abord, rollback toujours prêt. On ne parie jamais toute la prod sur un seul déploiement.
Réflexe 4
Surveiller après le déploiement
Le vrai travail commence quand le modèle est en prod. Un modèle sans vigie est un incident en attente.
Et le cinquième : rester simple. La régression logistique en production bat le réseau de neurones en notebook — tous les jours de la semaine.
· MLOps27 / 34
Acte 4 · lab
À vous :
2h30 au clavier
28 / 34
Mission 1 / 2 · 1h30 · pratique
Assembler — la checklist en main
Dérouler les six jointures de l'acte 1 sur votre projet : un commit témoin, la CI qui pousse l'image, le canary qui monte, l'API qui sert la version Production du registry, le dashboard qui bouge, l'alerte drift qui pointe au bon endroit. Chaque case cochée = une preuve — commande, capture ou URL.
Livrable : la checklist cochée et prouvée, commitée dans docs/assemblage.md.
git pushkubectl get podscurl /healthmlflow uiGrafana
Les 5 pannes classiques vous attendent quelque part. C'est prévu — le diagnostic fait partie de l'exercice.
· MLOps29 / 34
Mission 2 / 2 · 1h00 · pratique
Présenter — puis relire ses pairs
Cinq minutes par binôme, le format de l'acte 2 : commit en direct, chaîne commentée, preuve par /predict, dashboard final. Puis la revue croisée : chaque binôme relit le dépôt d'un autre avec la grille — reproductibilité, tests, clarté, gouvernance.
Livrable : votre démo jouée, et une revue écrite — 2 points forts, 1 amélioration — déposée en issue sur le dépôt relu.
démo 5 mingrille de revueissue sur le dépôtquestions du public
Ordre de passage tiré au sort. Le trac est normal : le système, lui, est prêt.
· MLOps30 / 34
Definition of done · la semaine entière
Ce qui doit exister à 16 h
Un pipeline démontré en direct, une checklist prouvée, une revue donnée — et une revue reçue.
C'est la definition of done du bloc 8, et donc de la formation : le dépôt contient tout, la démo a eu lieu, et un pair extérieur a validé que ça se clone et que ça tourne. Rien de déclaratif — que des preuves.
pipeline end-to-end ✓démo jouée ✓revue croisée ✓docs/assemblage.md commité
· MLOps31 / 34
Démo finale · le fruit de la semaine
Le système complet, en direct
0
fraudes bloquées en direct
Chaque ligne traverse l'API, le modèle v3 du registry, le monitoring — la boucle complète de l'acte 1. Ça, c'est votre travail de la semaine.
#
Transaction
Score
Verdict
API
● en ligne
Modèle servi
v3 registry
Latence p99
8 ms
Drift
● surveillé
· MLOps32 / 34
Le fil rouge · fin de parcours
Tout est allumé
Regardez la carte une dernière fois : le flux entre, le cerveau score, l'API répond, le conteneur tient, la mémoire se souvient, la qualité veille, le cluster encaisse, la vigie surveille. Rien de tout cela n'existait lundi matin.
Le système respire. Et quand il se déréglera — parce qu'il se déréglera — vous saurez le voir, le diagnostiquer et le soigner.
commit → prodcanarydrift surveillé
· MLOps33 / 34
Merci
Le modèle est en production.
Il est surveillé. Il vit
AI Driven. Human Approved. — merci pour cette semaine. Pour celles et ceux qui restent : le bonus GPU commence dans dix minutes.
34 / 34