Conteneurisation avec Docker — le système entre dans une boîte standard et devient portable : laptop, serveur, cloud, il tourne partout à l'identique.
Bloc 3 : le cerveau a une adresse. POST /predict répond en quelques millisecondes, les erreurs sont propres, les tests passent. Mais tout ce théâtre vit sur votre laptop — avec votre Python, vos libs, vos réglages.
Mission du bloc 4 : mettre le système dans une boîte qui démarre à l'identique sur n'importe quelle machine.
· MLOpsdocker compose up : l'API, la base de transactions et MLflow se lèvent ensemble, connectés, sur le laptop du voisin comme sur le serveur de la banque. Fini le « ça marche chez moi ».
· MLOps · MLOpsVendredi, 17 h. L'API est parfaite : les tests passent, la démo éblouit. On la copie sur le serveur de la banque. Elle ne démarre pas.
Le code est identique au caractère près. Et pourtant, rien ne marche. Vous l'avez déjà vécu — c'est la douleur n°1 du bloc 1, revenue en personne.
· MLOpsVotre laptop : Python 3.11, Debian récent, les bonnes libs système. Le serveur : Python 3.8, une vieille libc, pas les mêmes drivers. Le même code, deux mondes — et le modèle sérialisé n'aime que le vôtre.
Le code n'était pas le problème. Le problème, c'était tout ce qu'il y a autour du code.
· MLOpsVotre programme ne tourne jamais seul : il repose sur un empilement que personne ne voit — jusqu'au jour où il change.
· MLOpsLa riposte classique : tout documenter. Un README fleuve qui décrit chaque étape, chaque version, chaque piège. Il est faux dès la première mise à jour, et chacun le suit à sa manière — donc chacun obtient une machine différente.
Un document décrit un environnement. Il ne le garantit jamais.
· MLOpsEmballer le code et tout son empilement — Python, libs, réglages, mini-OS — dans un seul objet scellé, qu'on déplace tel quel. C'est exactement l'idée du conteneur. Et elle ne vient pas de l'informatique.
· MLOps1956. Malcom McLean, transporteur routier, regarde des dockers vider son camion caisse par caisse pendant des heures — et invente la boîte en acier standardisée.
Même taille partout, empilable, scellée, manipulable par n'importe quelle grue du monde. Le contenu peut être n'importe quoi — la boîte, elle, est toujours la même.
· MLOps · MLOpsUn conteneur logiciel = votre code + son environnement complet, scellés dans une boîte standard que toute machine sait exécuter.
Le serveur n'a plus besoin de connaître Python, vos libs ni votre OS. Il n'a besoin que d'une seule compétence : savoir ouvrir des boîtes. Cette compétence s'appelle Docker — et elle est installée partout, du laptop au cloud.
· MLOps · MLOpsChaque instruction de la recette ajoute une strate figée par-dessus la précédente. Docker garde chaque strate en cache : ce qui n'a pas changé n'est jamais reconstruit — ni retéléchargé.
Comprendre les couches, c'est comprendre pourquoi certains builds prennent 3 secondes et d'autres 20 minutes.
· MLOpsUne image se partage comme du code — via un registry : le GitHub des boîtes. Trois gestes suffisent.
Teaser : au bloc 6, c'est la CI qui fera build + push à chaque commit. La bibliothèque deviendra le point de passage obligé entre votre code et la production.
· MLOpsPresque — mais la différence de poids change tout à l'usage.
C'est cette légèreté qui rend possible la suite : multiplier les répliques de l'API en quelques secondes — rendez-vous au bloc 7 avec Kubernetes.
· MLOpsLe doc d'installation de 40 pages, réécrit en cinq lignes exécutables — versionnées dans Git avec le code.
Chaque ligne crée une couche du mille-feuille. docker build exécute la recette ; docker run sert le plat.
· MLOpsParce qu'une couche modifiée invalide toutes celles du dessus. Et vous modifiez votre code cent fois par jour — vos dépendances, une fois par semaine.
La règle : du plus stable en haut du Dockerfile au plus volatil en bas. Une ligne déplacée, des heures gagnées chaque semaine.
· MLOpsSans garde-fou, COPY embarque tout le dossier : les 150 Mo du CSV, l'historique .git, les notebooks — et parfois le .env avec les secrets. Une image obèse, et une fuite qui attend son heure.
Dans la boîte, on met le nécessaire au voyage. Pas le bureau entier.
· MLOpsPremier build de l'équipe : 2,1 Go. Le coupable ? Tout l'outillage qui a servi à construire voyage encore dans la boîte livrée.
· MLOps · MLOpsLundi matin : lancer l'API, puis la base de transactions, puis MLflow — dans le bon ordre, avec les bons ports. Trois terminaux, et un rituel que personne ne mémorise.
Notre système n'est plus un programme : c'est un organisme à plusieurs organes. Mettre chaque organe en boîte ne suffit pas — il faut un chef d'orchestre.
· MLOpsDocker Compose : on décrit l'état voulu du système dans un YAML — et une commande le fait exister.
Ce fichier est commité dans Git : l'architecture du système devient du texte relu en revue de code.
· MLOpsCompose crée un réseau privé pour le système : l'API joint la base à l'adresse db:5432, MLflow à mlflow:5000. Pas d'IP à connaître, pas de configuration réseau — le nom du service suffit.
« localhost », vu de l'intérieur d'un conteneur, c'est le conteneur lui-même. Premier piège du lab — vous voilà prévenus.
· MLOpsUn conteneur est jetable : on le détruit et on le recrée sans état d'âme — c'est sa force. Mais les transactions de la banque, elles, doivent survivre. Un volume est un disque géré par Docker, branché dans le conteneur : les données y vivent, hors de la boîte.
Le conteneur meurt, le volume reste. L'éphémère calcule, le durable se souvient.
· MLOpsNouveau collègue, nouveau serveur, machine de démo : git clone, docker compose up, café. Le doc d'installation de 40 pages est mort — remplacé par un fichier de vingt lignes qui ne ment jamais.
· MLOpsUn conteneur n'a pas d'écran : si l'API meurt au démarrage, tout s'est joué en silence. docker logs rejoue tout ce que le processus a écrit — c'est l'enregistreur de vol de la boîte, et le premier geste de tout diagnostic.
Avant de soupçonner Docker, lisez ce que votre programme a dit en mourant.
· MLOpsQuand les logs ne suffisent pas, on ouvre un shell à l'intérieur du conteneur qui tourne : vérifier que le modèle est bien là, tester la connexion à la base, inspecter les variables d'environnement — sur place.
Le conteneur n'est pas une boîte opaque. C'est une pièce dans laquelle on peut entrer, regarder, et ressortir.
· MLOpsPar défaut, le processus tourne en root dans le conteneur. Une faille dans l'API, et l'attaquant est administrateur de la boîte.
L'API n'a besoin que de conduire. On lui donne le volant — pas les clés du camion, ni celles du dépôt.
· MLOpsLe tag :latest ne veut pas dire « la meilleure version ». Il veut dire « la dernière poussée, par n'importe qui, à n'importe quel moment ».
Une image :latest peut changer entre deux déploiements — et voilà le démon « ça marchait hier » de retour, dans la boîte censée l'avoir tué. En production, on épingle tout : python:3.11-slim, postgres:16, fraud-api:1.4.2. Un tag explicite, c'est la reproductibilité qu'on vient de gagner — ne la rendez pas au hasard.
· MLOpsEt le cinquième : jamais root, jamais :latest. La boîte est aussi une frontière de sécurité — et une promesse de reproductibilité.
· MLOpsÉcrire le Dockerfile de l'API du bloc 3 : build, run, tester POST /predict depuis l'extérieur de la boîte. Puis optimiser : .dockerignore, ordre des couches vérifié au chrono, et multi-stage — objectif : une image sous les 500 Mo.
Livrable : docker run -p 8000:8000 fraud-api → /predict répond ; image finale < 500 Mo, chronos avant/après notés.
Binômes : un qui code, un qui questionne — on échange à la mi-temps.
· MLOpsÉcrire compose.yml : l'API, la base de transactions (postgres) et MLflow. L'API joint la base par son nom de service, un volume garde les données, un healthcheck ordonne les démarrages.
Livrable : docker compose up démarre les trois services ; down puis up → les transactions ont survécu.
Piège annoncé : « localhost » dans un conteneur, c'est le conteneur. Appelez les services par leur nom.
· MLOpsOn vous livre trois systèmes en panne : dépendance manquante, nom de service erroné, port occupé. Diagnostic aux logs et à l'exec — sans regarder le code d'abord. Puis on durcit votre propre image : utilisateur non-root, tags épinglés partout.
Livrable : les trois pannes expliquées par écrit (symptôme → indice → cause), et un Dockerfile durci commité.
Le but n'est pas de réparer vite — c'est de diagnostiquer proprement. La méthode servira toute la semaine.
· MLOpsRegardez la carte : le système est scellé dans sa boîte. La même image démarre sur votre laptop, le serveur de la banque, le cloud — à l'identique, en une commande. Le démon « ça marche chez moi » est mort.
Mais une question reste sans réponse : quel modèle est dans la boîte ? Entraîné quand, sur quoi, avec quelle PR-AUC ? Personne ne s'en souvient — et c'est le prochain danger.
· MLOpsBloc 5 — Tracking & gestion de modèles avec MLflow : chaque expérience notée, chaque modèle versionné. « Le run 7, c'était quoi déjà ? » — plus jamais.