Récapitulation et examen final

Dix modules pour passer d'un carnet Jupyter qui donne 0,82 d'AUC sur le portable d'Alice à un service surveillé qui se réentraîne tout seul et sait revenir à la version précédente en une commande. Voici la carte complète, puis les fils qui la traversent.

Le cours d'un coup d'œil

Module	L'essentiel à retenir
1. Ce que MLOps résout	Six manques du carnet : quelles données, quelles versions, reproductibilité, contrat de service, surveillance, retour arrière
2. Reproductibilité	Quatre graines (hash, random, numpy, torch), cuDNN déterministe, verrouillage complet des dépendances, conteneur d'entraînement
3. MLflow Tracking	Paramètres, métriques, artefacts ; autolog capte le cadre, on ajoute à la main les métriques métier
4. Versionnage DVC	Pointeur dans Git, contenu ailleurs ; commit + md5 données + run_id = lignage complet
5. Registre et alias	Le service charge par @champion, jamais par run_id ; six métadonnées obligatoires
6. Conteneurisation	Image slim, étage de construction, utilisateur non privilégié, modèle chargé une seule fois, config par variables d'environnement
7. Intégration continue	pandera pour les données, seuils par tranche pour le modèle, trivy pour l'image, approbation humaine pour la production
8. Modes de service	Trois questions règlent le choix entre lots, en ligne et flux ; une seule fonction de variables partagée
9. Surveillance	KS, chi-carré, PSI ; dérive du concept invisible aux entrées ; l'alerte utile a seuil, taille et action
10. Réentraînement et retour arrière	Trois déclencheurs, deux validations (hors ligne et canari), retour arrière en une commande

La chaîne du fil rouge, du carnet au service autonome

Le modèle de résiliation d'abonnés télécom a suivi tout le chemin. Au module 1, il vivait dans le carnet d'Alice, sans graine ni version. Au module 2, il est devenu reproductible ; au module 3, chaque essai est resté comparable aux 37 autres. Au module 4, les données sont versionnées avec DVC et chaque exécution note commit, snapshot et run_id. Au module 5, le meilleur artefact est enregistré, muni de ses six métadonnées, et promu par un simple déplacement d'alias. Au module 6, il est emballé dans une image Docker de 400 Mo qui charge le modèle une fois au démarrage. Au module 7, un GitHub Actions teste tout à chaque commit, construit l'image, la scanne et exige une signature avant la production. Au module 8, il sert des scores par lots chaque nuit à un tableau de bord des conseillers. Au module 9, un rapport Evidently hebdomadaire signale les dérives à partir d'un PSI supérieur à 0,25 sur les variables importantes. Au module 10, la détection d'une dérive relance le pipeline, valide la version candidate par canari, et bascule l'alias champion — ou revient en arrière sans attendre.

Les fils qui traversent le cours

Tout modèle en production est trois artefacts : le code, les données, les poids. La reproductibilité (module 2), le versionnage (module 4) et le registre (module 5) rendent ces trois artefacts opposables. Sans les trois, le modèle est un objet mystérieux ; avec les trois, c'est un livrable qu'on ose signer.

Les données changent, le code non ; la surveillance passe donc avant le test. Les tests du module 7 attrapent les régressions dues à un commit ; la surveillance du module 9 attrape les régressions dues à la réalité. Un projet MLOps qui investit lourdement dans la première et néglige la seconde protège la version, pas la promesse.

La promotion et le retour arrière sont deux gestes symétriques. Le module 5 rend la promotion triviale en déplaçant un alias ; le module 10 rend le retour arrière trivial de la même manière. Une équipe qui peut promouvoir en un clic mais pas revenir en arrière en un clic n'a pas terminé sa chaîne.

Chaque brique choisie l'a été pour un compromis explicite. Un lot plutôt qu'un service en ligne (module 8) parce que la fraîcheur d'un jour suffit et coûte dix fois moins. Un PSI plutôt qu'un KS strict (module 9) parce qu'un chiffre unique se suit dans le temps. Un canari plutôt qu'un bleu-vert (module 10) parce que la comparaison en production livre un signal que les tests hors ligne ne peuvent pas livrer.

L'examen final

L'examen comporte 40 questions couvrant les dix modules : manques d'un carnet et niveaux de maturité, sources de non-déterminisme sur CPU et GPU, journalisation avec MLflow, versionnage avec DVC et lignage à trois identifiants, registre et étapes de promotion, image Docker sécurisée, chaîne GitHub Actions avec ses tests spécifiques, choix entre lot, en ligne et flux, dérive des données et du concept avec les bonnes mesures, déclenchement du réentraînement, canari, retour arrière et gouvernance.

Plusieurs questions présentent des situations à diagnostiquer : une alerte de dérive qui se déclenche trop souvent, une promotion à l'aveugle qui casse un segment sensible, un service qui recharge le modèle à chaque requête, une chaîne dont le test de modèle est intermittent. C'est le jugement qui est évalué, pas la récitation de définitions.

En cas de réussite, votre attestation d'achèvement est délivrée immédiatement ; son numéro est vérifiable par tout tiers sur la plateforme.

Avant de commencer

Reprenez le tableau ci-dessus et, pour chaque ligne, demandez-vous « comment verrais-je que je me trompe ici ? ». Si vous savez dire pourquoi le service charge le modèle une seule fois, pourquoi le PSI ne se lit pas sur une seule journée, et pourquoi une promotion sans jeu de test figé est un piège, vous êtes prêt. Bonne chance !

Examen final

Prêt à valider ce cours ?

40 questions tirées au hasard dans la banque du cours · seuil de réussite 70 % · certificat PDF vérifiable délivré immédiatement en cas de réussite.

Commencer l'examen

Connexion à votre compte InSkillML et abonnement actif requis. Vous pouvez aussi lancer l'examen depuis Mes cours.