← Parcours
🚀

MLOps et projets en production

Avancé
🧠Comprendre en lisant n'est pas savoir écrire.🧠Un module est fini quand tu peux le reproduire fenêtre fermée.🧠Écris le problème en français avant d'écrire du code.🧠Une question impossible cache trois questions faciles.🧠Retape le code à la main. Puis referme et réécris-le.🧠Essaie d'abord, cherche ensuite.🧠Cherche « comment on écrit ça », jamais « qu'est-ce que je dois faire ».🧠Pour comprendre du code, casse-le.⌨️Une fonction qui plante sur un cas limite n'est pas finie.⌨️Si un bloc a un nom clair, il mérite d'être une fonction.⌨️Savoir lire une erreur vaut plus que connaître dix méthodes.⌨️Diagnostiquer, c'est éliminer dans l'ordre — pas essayer au hasard.⌨️Une optimisation sans mesure avant/après est une croyance.🔍Regarde le fichier avant de le charger.🔍Une performance anormalement bonne est une hypothèse à réfuter.🔍Cette valeur existe-t-elle à l'instant où je dois prédire ?🔍fit sur le train, transform partout.🔍Un chiffre qu'on ne sait pas raconter est un chiffre qu'on n'a pas compris.🔍Un graphique sans question n'a rien à dire.🤖Un score d'entraînement parfait n'est jamais une bonne nouvelle.🤖Le jeu de test ne se regarde qu'une fois.🤖Plus tu essaies de configurations, plus ton meilleur score est optimiste.🤖Un seuil de décision est un arbitrage économique, pas un réglage technique.🤖Commence toujours par une baseline. Note son score.🤖Le meilleur modèle n'est pas le plus précis, c'est celui qu'on peut maintenir.🚀Un modèle en production n'est pas un livrable, c'est un système vivant.🚀Un secret publié est un secret compromis.🚀Pour chaque permission : que se passe-t-il si cette machine est compromise ?🚀Un post-mortem qui cherche un coupable ne produit aucune amélioration.🚀« Nous n'utilisons pas cette variable » n'est pas une garantie d'équité.🚀Rends l'arbitrage explicite et chiffré. Ne le tranche pas en silence.🚀Un résultat qu'on ne sait pas reproduire est une anecdote.

🎯 Objectifs d'apprentissage

À l'issue de ce module, tu seras capable de :

  • 01Versionner données, code et modèles de façon reproductible
  • 02Automatiser entraînement et déploiement dans un pipeline CI/CD
  • 03Détecter une dérive de données ou de concept en production
  • 04Auditer un modèle sous l'angle de l'équité et de la conformité

Prérequis

Modules ML classique et Cloud

📖 Lectures de référence

Sélection d'expert — les ressources gratuites sont signalées.

Designing Machine Learning Systems

Payant

Chip Huyen

~50 €. Le livre le plus cité pour les entretiens de ML Engineer. Chip Huyen a construit ces systèmes chez NVIDIA et Snorkel.

Machine Learning Engineering

Gratuit

Andriy Burkov

Lecture gratuite en ligne (modèle « read first, buy later »). Très dense, très pratique.

Fairness and Machine Learning

Gratuit

Barocas, Hardt & Narayanan

Gratuit. La référence académique sur l'équité algorithmique, par des chercheurs de Berkeley et Princeton.

Du notebook au code de production

⏱ 50 min

Un modèle qui marche dans un notebook n'a aucune valeur tant qu'il n'est pas utilisable de façon fiable.

Structurer un projet ML :

projet/
├── data/            # jamais versionné dans git (DVC)
├── notebooks/       # exploration uniquement
├── src/
│   ├── features.py  # transformations réutilisables
│   ├── train.py     # entraînement reproductible
│   └── predict.py   # inférence
├── tests/
└── configs/         # hyperparamètres en YAML

Règles d'or :
- Fixer les seeds aléatoires (reproductibilité)
- Versionner code (git), données (DVC) et modèles (MLflow)
- Tracker chaque expérience : hyperparamètres, métriques, artefacts
- Écrire des tests : sur les features, sur les formats de données, sur la non-régression du modèle

import mlflow
with mlflow.start_run():
    mlflow.log_params({"lr": 0.01, "depth": 8})
    mlflow.log_metric("f1", 0.91)
    mlflow.sklearn.log_model(model, "model")

📚 Pour aller plus loin

✍️ Exercices de la leçon

2 exercices

Fais-les dans l'ordre, dans un vrai fichier .py — pas dans ta tête. Ne déplie la correction qu'après avoir écrit quelque chose, même faux.

🔧

Exercice A — Sortir un modèle de son notebook

Application directe · Tu appliques ce que tu viens de lire.

Prends un notebook d'entraînement que tu as écrit dans un module précédent et transforme-le en projet de production :

  1. 1.extrais les transformations dans src/features.py
  2. 2.extrais l'entraînement dans src/train.py, pilotable par un fichier configs/train.yaml
  3. 3.fixe toutes les graines aléatoires
  4. 4.enregistre l'expérience avec MLflow : paramètres, métriques, modèle
  5. 5.écris un test qui vérifie qu'une fonction de transformation produit bien ce qu'on attend

Vérifie ensuite que python src/train.py --config configs/train.yaml reproduit exactement le score du notebook.

🎯

Exercice B — « Chez moi ça donne 0,89 »

Page blanche · Aucun squelette : à toi de choisir la méthode.

Page blanche. Enquête de reproductibilité.

Tu annonces un F1 de 0,89. Ton collègue clone le dépôt, lance le script, obtient 0,84. Vous avez le même code.

Écris la checklist de diagnostic ordonnée : toutes les causes possibles, de la plus fréquente à la plus rare, avec pour chacune le test qui la confirme ou l'élimine.

Puis :
- implémente un script verifier_reproductibilite.py qui contrôle automatiquement les causes les plus courantes
- explique laquelle de ces causes est impossible à éliminer complètement, et comment on vit avec

Une différence de 5 points n'est pas du bruit. Quelque chose de concret diffère entre vos deux exécutions — trouve quoi.

🤖

Un point pas clair ? Clique sur 💬 Demander au tuteur en bas à droite.