Retour en arrière et retrait

Ce que vous saurez faire

Quand une mise en production tourne mal, revenez au modèle fiable en quelques secondes. Prouvez qu’il répond correctement. Supprimez ensuite la version défectueuse pour que personne ne puisse la démarrer par erreur.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 45 minutes

Ce que vous devez savoir

• Les états d’une version et RELEASES.md, dans Versions et déploiement progressif.
• GET /v1/monitor et ses alertes, dans Surveiller la santé du modèle.
• La vérification de parité, dans Vérifier la parité. L’erreur au démarrage avec une mauvaise empreinte (code de sortie 3), dans Charger et initialiser.
• compose.yaml avec --wait et sa vérification de santé, dans Paramètres de ressources du conteneur.

Ce qu’il vous faut sur votre ordinateur

• ~/projects/escalation-service avec le moniteur, les trois paquets, RELEASES.md et data/july_labels.csv, dans Surveiller la santé du modèle : exercice guidé. Les 42 tests réussissent.
• Votre .env avec MODEL_VERSION=1.0.0 et l’empreinte de 1.0.0.
• Si votre projet manque ou ne fonctionne plus, copiez l’instantané nextia-learning-labs/C17/snapshots/end-of-m05. Il contient tous les fichiers de ce module, sauf le paquet de rc1 : cette leçon le retire. Pour l’exercice, recréez-le avec les commandes de Une mise en production a une version et une empreinte. Utilisez votre propre empreinte. Utiliser un instantané présente les étapes.

Testé avec Python 3.14.6 et Docker Desktop (Docker Engine 29.6.1) sur macOS, avec une puce Apple. Les étapes pour Windows et Linux n’ont pas été testées.

Garder l’ancien pont ouvert

Quand une ville construit un nouveau pont, elle garde l’ancien ouvert jusqu’à ce que le nouveau réussisse son essai de charge. Si le nouveau pont montre une fissure le premier jour, la circulation retourne immédiatement sur l’ancien. Personne ne répare le nouveau pont pendant que les voitures attendent.

La mise en production d’un modèle fonctionne de la même façon. La nouvelle version peut échouer avec le trafic réel, même après un bon essai en parallèle. Vous gardez donc l’ancienne version prête et vous savez exactement comment y revenir.

Le problème : une alerte, et chaque minute compte

Pour s’exercer, Amira met volontairement rc1 en service sur son propre ordinateur. C’est une simulation : aucun vrai billet de soutien ne l’atteint. Elle règle .env sur rc1 et le démarre :

.env (the drill)

MODEL_VERSION=1.1.0-rc1
MODEL_SHA256=fa04bc40bea99723095ec4db600b7060fbfce0f2ec461534bb06c1829b47fe06

Terminal, in ~/projects/escalation-service

docker compose up -d --wait
python bench/bench.py http://127.0.0.1:8000 --requests 300 --warmup 0
curl http://127.0.0.1:8000/v1/monitor

Après 300 billets de juillet, le moniteur affiche (version abrégée) :

{"scored_total":300,"window":300,...,"flag_rate":0.837,"mean_score":0.4147,...,
 "alerts":["flag rate 0.837 is above the review capacity 0.20"],"model_version":"1.1.0-rc1"}

Larkfield reçoit environ 45 billets par jour. À 83,7 %, rc1 en signale environ 38 chaque jour, et l’équipe expérimentée peut en examiner 9. Chaque jour ajoute environ 29 billets signalés que l’équipe ne peut pas traiter.

Tomás : « Laissez-moi trouver le bogue et le corriger. Il me faut un jour, peut-être deux. » Chaque jour coûte 29 billets à l’équipe de Grace. Et une correction faite à la hâte crée une nouvelle version que personne n’a testée.

Revenir en arrière d’abord, trouver la cause ensuite

Un retour en arrière ramène le service à la dernière version reconnue comme fiable, sans la modifier. Dans les états d’une version, c’est la branche de Live (en service) vers Rolled back (retour en arrière effectué). L’état Known good (fiable) redevient Live :

La branche de retour en arrière. La version défectueuse passe à Rolled back, et la version fiable revient à Live. Rien n'est reconstruit.

Description textuelle du diagramme

C’est le même diagramme que dans la première leçon de ce module. Cette leçon utilise deux de ses flèches. Une alerte après la mise en production fait passer la version en service à retour en arrière effectué. Ici, il s’agit de rc1 dans l’exercice. La flèche retour en arrière ramène la version fiable, 1.0.0, à en service. Plus tard, quand la cause est connue, la version remplacée est retirée.

Un retour en arrière est rapide seulement si trois conditions sont remplies avant le problème :

1. La version fiable est encore là. Son paquet se trouve dans l’image, à côté du nouveau. Rien n’a besoin d’être construit ou téléchargé.
2. Son empreinte est consignée. RELEASES.md la contient. Vous la copiez, vous ne la calculez pas à la hâte.
3. Les étapes ont été testées. Un retour en arrière que personne n’a essayé reste un plan, pas un retour en arrière. Cet essai s’appelle un exercice de retour en arrière.

Le retour en arrière d’Amira demande deux lignes dans .env et une commande. D’abord, sauvegardez le journal de prédictions de rc1 : le journal de l’ancien conteneur disparaît quand Compose remplace le conteneur.

macOS/Linux

Terminal

docker compose logs escalation --no-log-prefix > predictions-rc1.log

Windows

PowerShell

docker compose logs escalation --no-log-prefix | Out-File -Encoding utf8 predictions-rc1.log

Remettez ensuite .env à 1.0.0, avec l’empreinte de RELEASES.md :

.env (rollback)

MODEL_VERSION=1.0.0
MODEL_SHA256=8f233029aa4c896dce1a5b3dfa970cd085088386bbe7784519f15a5b1a433b74

Prédisez : l’image est déjà sur l’ordinateur, et le démarrage à froid du module 4 prenait environ 2 secondes avec un CPU. Combien de temps faudra-t-il pour que Compose indique que le service est sain?

macOS/Linux

Terminal

time docker compose up -d --wait

Windows

PowerShell

Measure-Command { docker compose up -d --wait }

La sortie :

 Container escalation-service-escalation-1 Recreate
 Container escalation-service-escalation-1 Recreated
 Container escalation-service-escalation-1 Starting
 Container escalation-service-escalation-1 Started
 Container escalation-service-escalation-1 Waiting
 Container escalation-service-escalation-1 Healthy
docker compose up -d --wait  0.05s user 0.05s system 1% cpu 6.959 total

7,0 secondes pour atteindre Healthy (sain). Cinq autres exercices ont pris de 5,9 à 6,5 secondes. Le service répond plus tôt : Compose attend la vérification de santé, qui s’exécute toutes les 5 secondes. Amira a mesuré l’interruption avec un script qui appelait /ready toutes les 0,05 seconde pendant un retour en arrière. rc1 répondait jusqu’à l’arrêt de l’ancien conteneur. Ensuite, rien ne répondait pendant environ 2 secondes. Puis 1.0.0 répondait.

Après le retour en arrière : vérifier le contrat et les prédictions

Healthy signifie que /ready répond. Cela ne prouve pas que le bon modèle répond correctement. Amira vérifie trois choses, dans cet ordre.

Quel modèle répond? curl http://127.0.0.1:8000/v1/model :

{"model_version":"1.0.0","bundle_sha256":"8f233029aa4c896dce1a5b3dfa970cd085088386bbe7784519f15a5b1a433b74","threshold":0.19,...,"shadow_version":null}

L’empreinte correspond à celle de RELEASES.md. Calcule-t-il les scores comme pendant l’entraînement? La vérification de parité du module 3 :

Terminal, with .venv active

python parity/check_parity.py http://127.0.0.1:8000 bundles/escalation-1.0.0

La sortie (version abrégée) :

case     ticket      expected     served difference
normal   T-116940    0.187598   0.187598    2.8e-17
...
unknown  T-900008    0.111725   0.111725    5.6e-17
14 of 14 cases match within 1e-09.

Le contrat tient-il toujours? Envoyez un billet valide et un billet invalide avec les commandes curl de Connecter l’API. Les deux réponses :

POST /v1/score, the example ticket T-120001 →
200 {"ticket_id":"T-120001","score":0.35065699401024064,"flag":true,"threshold":0.19,"model_version":"1.0.0","warnings":[]}

POST /v1/score, priority "high" and created_hour 24 →
422 {"error":{"code":"invalid_ticket","message":"The ticket does not match the model's contract.","request_id":"f1fc9c0f7335","fields":["created_hour","priority"]}}

Le score est identique à celui du module 3, jusqu’au dernier chiffre, et la structure de l’erreur est identique. Amira ajoute une ligne à l’historique dans RELEASES.md : l’exercice, les 7,0 secondes, la parité de 14 sur 14 et les vérifications du contrat.

Remarque

Le moniteur repart de zéro après un retour en arrière : il réside dans le processus, et le processus est nouveau. Juste après les vérifications, /v1/monitor affiche "scored_total":14, soit les 14 cas de parité. Ses compteurs décrivent seulement 1.0.0.

Le piège : un seul conteneur et une mauvaise empreinte

Compose utilise un seul conteneur pour le service. docker compose up -d arrête d’abord l’ancien conteneur, puis démarre le nouveau. C’est l’interruption de 2 secondes. Si le nouveau conteneur ne peut pas démarrer, aucun ancien conteneur ne peut prendre le relais.

Amira l’a essayé volontairement. rc1 était en service. Elle est revenue en arrière avec la bonne version, mais avec l’empreinte de 1.1.0, prise dans la mauvaise ligne de RELEASES.md :

 Container escalation-service-escalation-1 Recreate
 Container escalation-service-escalation-1 Recreated
 Container escalation-service-escalation-1 Starting
 Container escalation-service-escalation-1 Started
 Container escalation-service-escalation-1 Waiting
container escalation-service-escalation-1 exited (3)

Le journal explique pourquoi :

ERROR escalation: Start-up error: bundles/escalation-1.0.0: the bundle digest is 8f233029aa4c..., but MODEL_SHA256 expects 382077148b6c...
ERROR:    Application startup failed. Exiting.

La vérification d’empreinte a fait son travail : elle a refusé un paquet qui ne correspondait pas. Mais rc1 était déjà arrêté. Avant le retour en arrière, le service de soutien avait un mauvais modèle. Maintenant, il n’a plus aucun modèle, jusqu’à ce que quelqu’un corrige .env. Le retour en arrière a aggravé la situation.

Avec un seul conteneur, l'ancienne version s'arrête avant que la nouvelle soit prête. Avec des révisions, l'ancienne version répond jusqu'à ce que la nouvelle soit prête. Un mauvais retour en arrière ne change donc rien.

Description textuelle du diagramme

La rangée du haut représente la configuration de ce cours : un seul conteneur, remplacé par docker compose up -d. rc1 répond, puis s’arrête. Ensuite, aucun service pendant environ 2 secondes, puis 1.0.0 répond. Avec une mauvaise empreinte, le nouveau conteneur quitte avec le code 3 après l’arrêt de rc1, et rien ne répond.

La rangée du bas représente une plateforme avec des révisions, comme dans les cours sur Docker et sur CI/CD. 1.0.0 démarre à côté de rc1. La plateforme transfère le trafic seulement quand 1.0.0 est prêt, puis rc1 s’arrête. Avec une mauvaise empreinte, 1.0.0 ne devient jamais prêt, et rc1 continue de répondre. C’est toujours incorrect, mais pas pire qu’avant.

Deux choses vous protègent avec un seul conteneur :

• Copiez, puis vérifiez. Avant up, comparez l’empreinte dans .env avec la ligne de la version dans RELEASES.md. Faites-le caractère par caractère, ou avec une courte commande comme grep 8f233029 RELEASES.md.
• Préférez une plateforme avec des révisions pour un vrai service. Azure Container Apps garde l’ancienne révision jusqu’à ce que la nouvelle soit prête (Configuration opérationnelle dans L’essentiel de Docker et du nuage pour les développeurs en IA). Si vous avez suivi CI/CD, tests et mises en production sûres, Stratégie de retour en arrière utilise un paramètre pour revenir seulement au modèle précédent, de la même façon.

Retirer la version défectueuse

Après l’exercice, Grace et Priya décident : rc1 ne sera jamais mis en service. Elles comprennent l’erreur de seuil, et 1.1.0 est le candidat corrigé. Laisser rc1 dans le projet a un coût. Un jour, quelqu’un pourrait saisir 1.1.0-rc1 dans .env, et l’image le démarrerait sans protester. Son empreinte est valide.

Le retrait supprime une version de tout ce qui peut l’exécuter et conserve la raison du retrait. Pour rc1 :

1. Le registre. Dans RELEASES.md, l’état de rc1 devient retired (retiré), avec la raison et la date. La ligne reste : l’historique des essais sert de preuve.
2. L’image. Supprimez le dossier bundles/escalation-1.1.0-rc1. Si vous utilisez Git, son historique conserve les fichiers.
3. Les ressources en cours d’exécution. Supprimez tout conteneur qui l’exécutait, comme escalation-shadow de la première leçon, et tout paramètre SHADOW_.

Reconstruisez, puis regardez à l’intérieur de la nouvelle image :

Terminal

docker compose build
docker run --rm escalation-service:1.0.0 ls bundles

La sortie :

escalation-1.0.0
escalation-1.1.0

Essayez maintenant l’ancienne erreur : MODEL_VERSION=1.1.0-rc1 et son empreinte dans .env, puis docker compose up -d --wait. Le service refuse :

ERROR escalation: Start-up error: bundles/escalation-1.1.0-rc1: no SHA256SUMS file

C’est le but du retrait : une version retirée ne peut pas revenir par erreur. Remettez .env à 1.0.0, puis redémarrez.

La même règle s’applique à tout ce qu’une mise en production laisse derrière elle. Dans le nuage, une révision canari, un point de terminaison de test ou un deuxième conteneur coûte de l’argent. Même sans trafic. C’est aussi un élément de plus qui peut répondre à une requête. Supprimez-le quand son test se termine. Vérifier et supprimer, dans L’essentiel de Docker et du nuage pour les développeurs en IA, montre comment faire pour un déploiement infonuagique.

Le RELEASES.md final du cours contient 1.0.0 en service (fiable), rc1 retiré et 1.1.0 candidat, avec un tableau d’historique. L’instantané end-of-m05 le contient.

Exercice guidé : le retour en arrière

Attention

Faites cet exercice uniquement sur votre propre ordinateur. Il met volontairement un modèle défectueux en service. Notez l’empreinte de 1.0.0 avant de commencer.

1. Dans .env, définissez MODEL_VERSION=1.1.0-rc1 et l’empreinte de rc1 tirée de RELEASES.md.
2. Exécutez docker compose up -d --wait.
3. Envoyez 300 billets de juillet avec python bench/bench.py http://127.0.0.1:8000 --requests 300 --warmup 0.
4. Appelez GET /v1/monitor. Vérifiez que alerts (alertes) contient une alerte.
5. Sauvegardez le journal dans predictions-rc1.log.
6. Dans .env, définissez MODEL_VERSION=1.0.0 et l’empreinte de 1.0.0. Comparez l’empreinte avec RELEASES.md.
7. Exécutez time docker compose up -d --wait (Windows : Measure-Command { docker compose up -d --wait }). Notez le temps.
8. Appelez GET /v1/model. Vérifiez la version et l’empreinte.
9. Exécutez check_parity.py. Vous devriez voir 14 of 14 cases match (14 cas sur 14 correspondent).
10. Envoyez le billet valide et le billet invalide, comme dans Après le retour en arrière. Vérifiez 200 avec le modèle 1.0.0, puis 422 avec deux champs.
11. Ajoutez l’exercice à RELEASES.md : la date, le temps et les résultats des étapes 8 à 10.

Afficher les résultats attendus

Étape 4 : "flag_rate":0.837 et l’alerte flag rate 0.837 is above the review capacity 0.20 (le taux de signalement de 0,837 dépasse la capacité d’examen de 0,20). Les mêmes 300 billets donnent le même taux sur chaque ordinateur.

Étape 7 : environ 6 à 7 secondes sur l’ordinateur de test. Votre temps est différent.

Étapes 8 à 10 : les sorties de Après le retour en arrière.

Une ligne d’historique pour l’étape 11 :

| 2026-10-08 | Rollback drill: 1.1.0-rc1 live, 300 July tickets, alert (flag rate 0.837). Back to 1.0.0: healthy after 7.0 s, parity 14 of 14, contract checks pass. | Amira |

À vous de jouer : retirer rc1

Retirez rc1 aux trois endroits indiqués dans Retirer la version défectueuse. Prouvez-le ensuite : l’image affiche seulement deux paquets, et MODEL_VERSION=1.1.0-rc1 provoque un arrêt au démarrage. Exécutez python -m pytest à la fin. Prédisez d’abord : un test a-t-il besoin de rc1?

Afficher la réponse

docker run --rm escalation-service:1.0.0 ls bundles affiche escalation-1.0.0 et escalation-1.1.0. Le démarrage avec rc1 échoue avec no SHA256SUMS file (aucun fichier SHA256SUMS). Les tests donnent 42 passed (42 tests réussis) : chaque test utilise le paquet 1.0.0, donc aucun n’a besoin de rc1. La ligne de rc1 dans RELEASES.md :

| 1.1.0-rc1 | `fa04bc40bea9...fe06` | retired | 2026-10-08 | Shadow, July: flagged 87.0% of the last 1,000 tickets. Balanced weights with the old threshold 0.19. Never answered a real request. Bundle removed from the image. | Grace, Priya |

Erreur courante

Le retour en arrière arrête le service : une mauvaise empreinte

Symptôme : pendant un retour en arrière, docker compose up -d --wait se termine avec container ... exited (3) (le conteneur a quitté avec le code 3). curl http://127.0.0.1:8000/ready ne peut pas se connecter. Le journal affiche Start-up error: bundles/escalation-1.0.0: the bundle digest is 8f233029aa4c..., but MODEL_SHA256 expects 382077148b6c... (erreur au démarrage : l’empreinte du paquet est 8f233029aa4c…, mais MODEL_SHA256 attend 382077148b6c…).

Cause : .env contient la bonne version, mais l’empreinte d’une autre version. Le service refuse correctement de charger le paquet. Avec un seul conteneur, Compose a d’abord arrêté l’ancienne version, donc rien ne répond maintenant.

Correction : copiez l’empreinte de 1.0.0 depuis sa ligne dans RELEASES.md vers .env, puis relancez docker compose up -d --wait. Dans l’exercice, cela a pris 5,9 secondes. Faites ensuite les trois vérifications de Après le retour en arrière.

Pour un vrai service d’IA : les gens sont pressés au moment d’un retour en arrière. Faites-en une copie depuis un registre écrit, répétée lors d’un exercice. Utilisez une plateforme qui garde l’ancienne version active jusqu’à ce que la nouvelle soit prête.

Vérifiez votre compréhension

Tomás veut corriger rc1 sur place plutôt que revenir en arrière. Donnez deux raisons de revenir en arrière d'abord.

Afficher la réponse

D’abord, le temps : rc1 signale environ 38 des 45 billets quotidiens, alors que l’équipe peut en examiner 9. Un retour en arrière prend quelques secondes. Une correction prend un jour ou plus. Ensuite, la sécurité : une correction faite à la hâte crée une nouvelle version non testée. 1.0.0 est fiable, avec son empreinte, sa parité et son historique. Revenez en arrière, puis trouvez la cause sans pression et créez un nouveau candidat.

Vérifiez votre compréhension

Après un retour en arrière, Compose indique Healthy (sain). Pourquoi cela ne suffit-il pas? Que vérifiez-vous?

Afficher la réponse

Healthy signifie seulement que /ready a répondu. Vérifiez trois choses. Quel modèle répond : dans GET /v1/model, la version et l’empreinte correspondent à la ligne de RELEASES.md. Calcule-t-il les scores comme pendant l’entraînement : check_parity.py donne 14 sur 14. Le contrat tient-il : un billet valide reçoit 200 et le score attendu, un billet invalide reçoit 422 avec les champs.

Exercice du module

Exercice guidé → tâche autonome. L’exercice guidé portait sur rc1, un modèle dont les scores avaient changé. Créez maintenant votre propre candidat défectueux avec une autre erreur, mettez-le en service dans votre simulation locale, puis rétablissez 1.0.0.

Votre tâche : un candidat avec un mauvais seuil

1. Dans ~/projects/ticket-model, créez un candidat avec un seuil mal copié : python retrain.py --out model-1.1.0-rc2 --threshold 0.12.
2. Empaquetez-le comme version 1.1.0-rc2. Ajoutez sa ligne à RELEASES.md.
3. Réglez .env sur rc2 et son empreinte. Mettez-le en service avec docker compose up -d --build --wait : l’image a besoin du nouveau paquet. Envoyez 300 billets de juillet et lisez /v1/monitor.
4. Revenez à 1.0.0. Chronométrez le retour et faites les trois vérifications.
5. Retirez rc2.
6. Écrivez deux phrases : comment le moniteur de rc2 diffère de celui de rc1, et ce que cette différence révèle sur la cause.

Afficher un exemple de réponse

Étapes 1 et 2 :

Trained on 18118 tickets (to the end of May). Threshold 0.12 (fixed by hand).
June: ROC AUC 0.749, average precision 0.346, flagged 352 of 1002 (35.1%), precision 0.307, recall 0.688.
Made bundles/escalation-1.1.0-rc2: 14 parity cases, threshold 0.12.
Bundle digest (MODEL_SHA256): d6fad059f7dbdb1ff8603a3d62e4c56af5b1cab5d185344c6a97d3f6b7a6a8f8

Étape 3, /v1/monitor :

{"scored_total":300,"window":300,"contract_errors":{},"unknown_categories":{},"flag_rate":0.33,"mean_score":0.1173,
 "latency_ms":{"p50":2.12,"p95":3.22},"shadow":null,"alerts":["flag rate 0.330 is above the review capacity 0.20"],"model_version":"1.1.0-rc2"}

Étape 4 : sain après 6,2 secondes. /v1/model donne 1.0.0 avec son empreinte, et la parité donne 14 of 14 cases match within 1e-09 (14 cas sur 14 correspondent à 1e-09 près). Le billet valide donne 200 avec le score 0,35065699401024064. Le billet invalide donne 422 avec created_hour et priority.

Étape 5 : la ligne de rc2 indique retired, son dossier est supprimé et l’image affiche deux paquets.

Étape 6 : rc1 avait un score moyen de 0,4147 sur les mêmes 300 billets. Ses scores ont donc changé : le modèle lui-même a changé. rc2 a un score moyen normal, 0,1173, mais un taux de signalement de 33 %. Les scores sont corrects, et le seuil est mauvais. Le score moyen vous indique où chercher.

Vérification du module

Vérifiez votre compréhension

Rappel : que consigne chaque colonne de RELEASES.md, et quelle colonne le service vérifie-t-il au démarrage?

Afficher la réponse

Version : le nom destiné aux personnes. Bundle digest (empreinte de l’ensemble) : la valeur de MODEL_SHA256. Status (statut) : candidat, en mode fantôme, en production, fiable, retour en arrière ou retiré. Since (depuis) : la date du statut. Evidence (preuves) : les chiffres qui justifient le statut. Approved by (approuvé par) : la personne qui a décidé. Le service vérifie l’empreinte : load_bundle compare l’empreinte de SHA256SUMS à MODEL_SHA256 avant de charger quoi que ce soit.

Vérifiez votre compréhension

Prédiction : 1.1.0 fonctionne en mode fantôme aux côtés de 1.0.0 sur les billets de juillet. La surveillance déclenchera-t-elle une alerte pour le modèle fantôme? Faudra-t-il alors retirer 1.1.0 comme rc1?

Afficher la réponse

Oui, une alerte. Sur les 1 000 derniers billets, le taux de signalement du modèle fantôme est de 0,206, juste au-dessus de 0,20. Le modèle en production est à 0,212. Mais il ne faut pas le retirer comme rc1. Son seuil provient de ses propres scores. Sur le mois, il signale 19,4 % des billets, avec une précision de 0,342 et un rappel de 0,474. Ces valeurs sont proches de celles de 1.0.0. Les deux versions dépassent 20 % à la fin juillet à cause des entrées, et non du modèle. Il s’agit du canal social et de l’exportation défectueuse. La décision revient à Grace et à Priya, à partir de ces preuves.

Vérifiez votre compréhension

Vérification finale : après un retour en arrière, montrez que le contrat de l'API et les prédictions sont corrects. Quelles commandes et quels résultats?

Afficher la réponse

GET /v1/model : model_version (version du modèle) 1.0.0, et bundle_sha256 (empreinte de l’ensemble) égale à l’empreinte de 1.0.0 dans RELEASES.md. python parity/check_parity.py http://127.0.0.1:8000 bundles/escalation-1.0.0 : 14 of 14 cases match within 1e-09 (les 14 cas concordent avec une tolérance de 1e-09). Cela couvre les entrées normales, manquantes, extrêmes et inconnues. POST /v1/score avec le billet d’exemple : 200, score 0,35065699401024064, model_version 1.0.0. POST /v1/score avec priority (priorité) « high » (élevée) et created_hour (heure de création) 24 : 422 avec fields (champs) ["created_hour","priority"].

Récapitulatif

Le module 5 en bref

• Une mise en production comprend une version et une empreinte, consignées dans RELEASES.md, votre registre de modèles. Le seuil appartient à la version : rc1 a conservé l’AUC et signalé 86 % des billets.
• Un modèle fantôme calcule les scores du trafic réel avec le candidat, mais le modèle en production fournit les réponses. Un déploiement canari répond à une petite part du trafic. Commencez en mode fantôme lorsqu’une mauvaise réponse coûte du temps à une personne.
• Le service mesure ses indicateurs de santé : erreurs de contrat, catégories inconnues, latence, taux de signalement comparé à la capacité et score moyen. outcomes.py ajoute la précision et le rappel quand les étiquettes arrivent.
• Un retour en arrière rétablit la version fiable sans nouvelle construction. Il faut deux lignes dans .env et environ 7 secondes. Vérifiez ensuite le modèle, la parité et le contrat.
• Avec un seul conteneur, une empreinte incorrecte pendant un retour en arrière laisse le service indisponible. Les plateformes avec révisions gardent l’ancienne version en service.
• Le retrait supprime une version de l’image et des ressources en cours d’exécution, et conserve sa ligne comme preuve.

Revenir à un état connu

1. Arrêtez et supprimez le service : docker compose down.
2. Supprimez l’image : docker image rm escalation-service:1.0.0.
3. Si vous avez créé un conteneur de test qui existe encore, supprimez-le : docker rm -f escalation-shadow.
4. Copiez l’instantané nextia-learning-labs/C17/snapshots/end-of-m05 dans un nouveau dossier, comme dans Utiliser un instantané. Créez son .venv et son .env avec MODEL_VERSION=1.0.0 et l’empreinte de l’ensemble 1.0.0 du cours.
5. Exécutez python -m pytest. Vous devriez voir 42 passed (42 tests réussis). Ensuite, exécutez docker compose up -d --build --wait.

Ensuite, une étude de cas permet de pratiquer une mise en production et un retour en arrière sur un modèle de régression. Il n’y a alors aucun seuil à vérifier.

Leçon suivante : Mettre en production un nouveau modèle de prix des maisons