Bloc 1 : pourquoi le ML en production est différent
Semaines 1 à 3. Vous savez déployer, automatiser et observer une application classique. Ce bloc montre pourquoi cela ne suffit plus dès qu'une partie du comportement est apprise à partir des données : un modèle se dégrade sans que personne n'y touche, sa panne ne lève aucune erreur, et le résultat d'un entraînement dépend de données, de paramètres et d'aléas qu'il faut savoir figer pour le reproduire.
Le fil conducteur : reproduire avant d'automatiser
Au semestre 1, on déployait à la main avant d'automatiser, pour savoir ce que l'outil remplace. Le semestre 3 suit la même logique. Au TP 22, vous recevrez un notebook de « recherche » qui produit un excellent modèle... et que vous ne parviendrez pas à ré-exécuter. Ce n'est qu'après avoir vécu cette impuissance que vous restructurerez le projet et versionnerez ses données, au TP 23. On ne peut ni orchestrer, ni déployer, ni surveiller un entraînement qu'on ne sait pas reproduire.
Organisation du bloc
Ce que vous saurez faire à la fin du bloc
- Expliquer, exemples chiffrés à l'appui, pourquoi un système de ML accumule une dette technique propre (Sculley et al., 2015).
- Identifier sur un projet réel l'intrication des variables, les dépendances de données instables, le décalage entre entraînement et service et les boucles de rétroaction.
- Rendre un entraînement reproductible : code, données, configuration, graines aléatoires, environnement.
- Situer une équipe sur l'échelle de maturité MLOps et choisir un mode de mise à disposition adapté à un besoin.