Étiqueter et versionner

Ce que vous saurez faire

Notez ce qu’une réponse correcte doit contenir, plutôt qu’une seule réponse parfaite, et qui l’a décidé et pourquoi. Donnez ensuite une version à l’ensemble, pour que chaque score indique les données exactes qui ont servi à le calculer.

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

Ce que vous devez savoir

• Les sous-groupes et le tableau de couverture, dans Choisir des cas représentatifs.
• La politique de Grace, avec les équipes et les règles H1 à H5 qui rendent needs_human vrai. Elle se trouve dans data/policy.md de votre projet.

Ce qu’il vous faut sur votre ordinateur

• Le projet eval-harness avec python -m harness coverage de la dernière leçon, et son environnement virtuel actif. python -m pytest -q se termine par 8 passed (8 tests réussis).
• Si votre projet ne fonctionne plus, copiez l’instantané C11/snapshots/end-of-m01 comme dans Réinitialiser le projet. Refaites ensuite les étapes du tableau de couverture (environ cinq minutes).

Aucun compte ni aucune clé.

Une commande de gâteau

Une personne commande un gâteau d’anniversaire. Elle n’apporte pas de photo en disant « faites exactement ce gâteau ». Elle écrit ce qui compte sur le bon de commande : chocolat, sans noix, « Bonne fête, Sam » sur le dessus, prêt samedi à 15 h. Tout gâteau qui respecte chaque ligne convient. Un beau gâteau contenant des noix ne convient pas, car une personne invitée a une allergie.

Le bon indique aussi qui a pris la commande et quand. Si la personne appelle pour la modifier, le pâtissier n’efface pas l’ancienne ligne. Il note le changement, la raison et la date, et la commande reçoit une nouvelle version. Le samedi, tout le monde sait quelle version de la commande le gâteau doit respecter.

Le problème : une seule réponse idéale

La façon la plus simple d’étiqueter un cas de test consiste à écrire la réponse parfaite et à comparer celle du système. On appelle souvent cette réponse parfaite une réponse idéale. Amira essaie cette méthode sur le billet de soutien T-64707: un client a été facturé deux fois pour une armoire de salle de bain. Elle écrit une réponse idéale. La vraie réponse de la référence de base suit, puis une réponse incorrecte qu’elle a écrite pour tester l’idée. Sa réponse idéale et la réponse incorrecte ont été créées pour cette leçon; celle du milieu est la vraie réponse enregistrée.

Réponse	Texte	Mots de la réponse idéale qu’elle contient
Idéale (créée)	« Je suis désolé pour la double facturation de la commande LK-561208. Après confirmation, nous remboursons le montant supplémentaire sous 3 jours ouvrables. »	19 sur 19
Référence de base (réelle)	« Je suis désolé que vous ayez été facturé deux fois. Notre équipe des paiements examinera les frais. Une double facturation confirmée est remboursée sous 3 jours ouvrables après confirmation. Vous pouvez partager les captures d’écran pour faciliter l’examen. »	9 sur 19 (0,47)
Incorrecte (créée)	« Je suis désolé pour la double facturation de la commande LK-561208. Nous avons remboursé le montant supplémentaire. Il sera crédité sur votre carte sous 3 jours ouvrables. »	16 sur 19 (0,84)

Aucune réponse ne correspond exactement au texte idéal. Un test de correspondance exacte rejette donc les deux. Un test de mots communs fait pire : il préfère la réponse incorrecte. Cette réponse dit « Nous avons remboursé », mais l’assistant ne peut rien rembourser. La règle 8 de la politique précise que seule une personne de l’équipe peut le faire. La réponse de la référence de base est correcte, mais elle utilise d’autres mots. Plusieurs réponses différentes sont correctes. Une réponse peut aussi ressembler beaucoup à la réponse idéale tout en enfreignant la règle la plus importante.

L’idée : étiqueter ce qui doit être vrai

Les étiquettes décrivent donc ce qui doit être vrai dans une réponse correcte, comme le bon de commande. Une étiquette est la réponse qu’un bon système donne pour un cas, notée avant de calculer le moindre score. Chaque cas de Larkfield a trois types d’étiquettes :

• Les décisions, que le code peut comparer exactement : l’équipe et la nécessité qu’une personne traite le billet (needs_human). Elles incluent la règle de la politique qui l’exige.
• Les critères de la réponse : ce qu’elle must (doit) contenir, par exemple photo, person_will_contact, stop_using, reply_in_french. Ils précisent aussi ce qu’elle must_not (ne doit pas) contenir : claims_action, asks_secret, other_customer_details, promises_outcome. Le module 3 transforme ces codes en vérifications.
• La provenance : qui a étiqueté le cas, quand, comment et ce qui a changé ensuite. La provenance est l’historique de l’origine de quelque chose.

Une réponse idéale reste utile comme exemple idéal : une bonne réponse qui montre au lecteur le sens des critères. Elle n’est pas la cible. Le diagramme décompose un cas réel.

Un cas et ses étiquettes : deux décisions, des règles pour la réponse et un historique des décisions et des changements.

Description textuelle du diagramme

Le cas T-64944 est dans la partition dev et le sous-groupe « difficult » (difficile), car il contient des fautes. Le client écrit : « salut désolé de vous déranger mais le salon de jardin en rotin reçu est pas le bon. j’ai commandé brun foncé et ils ont envoyé le pâle. comment je le retourne?? merci ». Le cas comporte quatre groupes d’étiquettes. Les décisions, notées par le code : l’équipe est returns et needs_human est false, car aucune règle ne s’applique. Les règles de la réponse : elle doit demander une photo; elle ne doit pas affirmer une action ni demander un secret. Qui, quand et comment : l’auteur du cours l’a étiqueté le 9 octobre 2026 en appliquant la politique de Grace. L’équipe vient de l’étiquette du cours sur l’apprentissage profond, relue. Révision après les exécutions : la prochaine étape est passée de return_steps à photo. La raison est la règle 3 de la politique : un mauvais article à la livraison exige une photo.

Lisez le cas dans le projet. Exécutez cette commande dans le terminal de VS Code :

python -m harness show T-64944 --run baseline

La sortie :

T-64944 | split dev | slice difficult | source c06-valid
Text: hi sorry to bother u but the rattan patio set that came is the wrong one. i ordered the dark brown and they sent the light one. how do i send it back?? thank u
Expected: team returns | needs_human false | next step photo
Reply must: photo | must not: claims_action, asks_secret
Labelled by: course author, 2026-10-09; Grace's policy (teams, H1-H5) applied by reading; team: the deep learning course's label (two models agreed), read again by the course author; next_step: return_steps -> photo on review (policy rule 3: a wrong or damaged item on arrival needs a photo within 14 days, then a replacement or a refund)

baseline-v2-chat-small-r1-b6a2b9: {"team": "returns", "needs_human": false, "reason": "They want to return the wrong item, so this is a returns request."}
Reply: I’m sorry you received the wrong colour. Please send us a photo of the item within 14 days of delivery; return shipping is covered for a wrong item. The returns team can guide you through sending it back.

La réponse de la référence de base réussit ce cas : bonne équipe, bonne décision, photo, aucune action affirmée, aucun secret demandé. Elle utilise ses propres mots.

Qui a étiqueté les cas et comment

La provenance n’aide que si elle est honnête. La voici donc au complet. L’auteur du cours a écrit les étiquettes en appliquant la politique écrite de Grace, et des scripts les ont vérifiées. L’auteur a lu chaque billet et décidé de l’équipe, de la règle qui rend needs_human vrai, de la prochaine étape et des critères de réponse. Pour les 140 billets réutilisés, l’équipe venait du cours sur l’apprentissage profond, où deux modèles s’étaient entendus. L’auteur du cours a relu chaque billet. C’est la lecture d’une seule personne; une autre pourrait trancher différemment certains cas limites. L’auteur a aussi écrit les notes de référence du module 4: les scores de 30 réponses, selon la grille de Grace.

Grace et Priya peuvent discuter des étiquettes, et vous serez en désaccord avec certaines. C’est normal : une étiquette représente une interprétation d’une politique écrite. Notez votre désaccord et sa raison. C’est le rôle d’un évaluateur.

Quand un système contredit une étiquette

Les étiquettes changent. Une étiquette peut être incorrecte, la politique peut être floue, ou un lecteur peut remarquer quelque chose de nouveau. L’important est qu’un changement suive une procédure, et que cette procédure soit écrite. Voici la procédure suivie pour le jeu de données de Larkfield. Trouvez l’étape 6 dans le diagramme.

La vie du jeu de données d'évaluation. L'évaluateur change les étiquettes seulement avec une raison. Chaque changement crée une version, et rien ne franchit les limites des partitions.

Description textuelle du diagramme

Le diagramme comporte trois bandes. La première construit le jeu de données en quatre étapes. Recueillez les billets. Étiquetez chaque cas avec des règles de réponse et une trace de la personne qui l’a étiqueté. Répartissez les cas : mélangez chaque sous-groupe et distribuez les cas à tour de rôle. Donnez au fichier sa première version, une empreinte. La deuxième bande utilise et révise le jeu de données. Exécutez les systèmes et enregistrez chaque sortie avec la version. Ensuite, un évaluateur, dans un encadré en pointillés, lit chaque cas où un système contredit une étiquette. Il change une étiquette seulement avec une raison écrite. Cela crée la version 2, avec une nouvelle empreinte du fichier, mais la même empreinte des entrées. Les sorties enregistrées restent donc valides. La troisième bande montre les limites des partitions. Des lignes épaisses séparent dev, holdout et contaminated : aucun billet ne franchit une ligne. Dev est ouverte : vous la lisez, ajustez le système avec elle et la notez aussi souvent que nécessaire. Une flèche en pointillés revient de dev à l’étape d’exécution. Holdout est figée et notée une seule fois, pour décider de la mise en production. Contaminated contient les billets utilisés pour construire la requête et sert seulement à mesurer l’écart.

Après les premières exécutions de la référence de base et du candidat, l’auteur du cours a relu certains cas. Il s’agissait des cas où un système contredisait une étiquette ou échouait à un critère de réponse. Cela représentait 63 des 200 cas de dev et holdout. Le résultat :

Ce qui s’est passé	Cas	Pourquoi
Prochaine étape changée : étapes de retour → photo	10	Règle 3 de la politique : un article incorrect ou endommagé à la livraison exige d’abord une photo.
Prochaine étape changée pour les billets de sécurité : garantie → aucune	16	Pour un billet de sécurité, il faut cesser d’utiliser le produit et attendre une personne. Décision appliquée à tous les cas de la règle H1.
Prochaine étape changée : aucune promesse de vérifier	5	Une personne traite ces billets de toute façon (menace juridique, instructions dans le billet, commande perdue).
Prochaine étape changée : le taille-bordure a été testé	1	Un taille-bordure testé n’est pas inutilisé; les étapes de retour ne s’appliquent donc pas.
needs_human est resté faux, même si un système disait vrai	21	Aucune règle de la politique ne s’applique (par exemple, paiement en plusieurs versements, compte verrouillé).
L’équipe est restée la même, même si un système en choisissait une autre	2	T-65388 reste avec returns; T-65615 reste avec account.

Ainsi, 32 étiquettes ont changé, toutes pour la prochaine étape. Aucune étiquette d’équipe ni aucune étiquette needs_human n’a changé. La provenance de chaque cas modifié indique ce qui a changé et pourquoi, comme vous l’avez vu pour T-64944.

Examinons maintenant la faiblesse de cette procédure. La révision portait seulement sur les cas où un système était en désaccord. Quand l’étiquette et les deux systèmes se trompaient ensemble, personne ne vérifiait. Chaque changement rapprochait aussi une étiquette de ce qu’un système avait répondu. Une telle révision ne peut que faire paraître les systèmes meilleurs. Une procédure plus solide comporte quatre parties :

1. Deux évaluateurs étiquettent les mêmes cas, sans voir les étiquettes de l’autre. Le module 4 mesure leur degré d’accord dans Calibrer les évaluateurs.
2. La personne responsable de la politique tranche chaque désaccord. Pour Larkfield, c’est Grace.
3. La raison est inscrite dans le cas, comme le fait label.changed.
4. Une décision s’applique à tous les cas concernés, pas seulement à ceux où un système a échoué. La décision de sécurité ci-dessus a été appliquée ainsi, à tous les cas de la règle H1.

Le coût : un deuxième évaluateur double le temps d’étiquetage, et régler les désaccords prend du temps à la personne responsable. Pour un jeu de 200 cas, cela représente quelques jours de travail. Faites-le avant qu’une décision de mise en production dépende des étiquettes, pas après.

Donner une version au jeu de données

La révision a changé 32 étiquettes. Un score avant la révision et un score après sont mesurés par rapport à des réponses différentes. Chaque score doit donc indiquer les données exactes qui ont servi à le calculer. Un nom comme « le jeu d’avril » ne suffit pas : quelqu’un peut modifier le fichier et garder le nom.

La solution est une empreinte du contenu : un code court calculé à partir de chaque octet du fichier. SHA-256 est une méthode courante. Changez un caractère, et l’empreinte change complètement. Voici les 12 premiers caractères de trois empreintes. Les textes diffèrent d’un mot, puis d’une lettre majuscule :

Texte	Les 12 premiers caractères de son SHA-256
T-64944 next_step: return_steps	718710ff1de3
T-64944 next_step: photo	0778f2b8d724
T-64944 next_step: Photo	29dfe1f7908c

Le projet utilise les 12 premiers caractères du SHA-256 du fichier comme version du jeu de données. python -m harness cases l’affiche sur sa première ligne : {ds.version}. Avant la révision, c’était {ds.version_before_review}.

Cela soulève une question. La référence de base a été exécutée avant la révision. Son exécution enregistrée est-elle encore valide? La réponse dépend de ce que le système a vu. Le système a vu les identifiants des cas, les textes et les pièces jointes, jamais les étiquettes. Le projet possède donc une deuxième empreinte, la version des entrées. Elle porte seulement sur les identifiants, les textes et les pièces jointes. La révision ne l’a pas changée. Les sorties enregistrées correspondent donc toujours exactement à ces billets.

Deux versions d'un même jeu de données. Les étiquettes ont changé, donc l'empreinte du fichier a changé. Les textes sont inchangés, donc l'empreinte des entrées et les sorties enregistrées restent valides.

Description textuelle du diagramme

Deux colonnes. Celle de gauche représente le jeu de données avant la révision, utilisé pour exécuter la référence de base. Son empreinte de fichier, calculée sur chaque octet, est 263bbd4f180d. Son empreinte des entrées, calculée seulement sur les identifiants, les textes et les pièces jointes, est 3f90ab808275. Celle de droite représente le jeu de données après la révision : 32 étiquettes de prochaine étape ont changé, mais aucun texte. Son empreinte de fichier est d4c96eaa10c0, et son empreinte des entrées reste 3f90ab808275. Les empreintes des fichiers sont différentes. Celles des entrées sont identiques.

Ajouter la version des entrées au projet

1. Ouvrez harness/dataset.py. La nouvelle fonction utilise json, que le fichier importe déjà. Vérifiez que les importations commencent ainsi :

   harness/dataset.py

   import hashlib
   import json
   from collections import Counter
   from pathlib import Path

2. Trouvez la fonction version. En dessous, laissez deux lignes vides et ajoutez cette fonction :

   harness/dataset.py

   def inputs_version(cases: list[Case]) -> str:
       """A version of what the system sees (case IDs, texts and attachments), without the labels.
   
       A label can change after review; the saved outputs stay valid as long as this version is the same."""
       lines = sorted(json.dumps([c.case_id, c.text, c.attachments], ensure_ascii=False) for c in cases)
       return hashlib.sha256("\n".join(lines).encode("utf-8")).hexdigest()[:12]

   La fonction écrit une ligne par cas avec seulement les trois entrées, puis trie les lignes. L’ordre du fichier n’a donc plus d’importance. Enfin, elle calcule l’empreinte des lignes.

3. Enregistrez le fichier. Affichez la version des entrées des 271 cas :

   python -c "from harness.dataset import inputs_version, load_cases; print(inputs_version(load_cases(split='all')))"

   La sortie :

   3f90ab808275

4. Ouvrez outputs/runs.json. Trouvez dataset_version et inputs_version dans l’exécution de la référence de base. Leurs valeurs sont 263bbd4f180d et 3f90ab808275. La version du fichier est plus ancienne, mais celle des entrées correspond à l’étape 3. L’exécution est donc valide pour le jeu de données actuel.

Exercice guidé : changer une étiquette

Vous allez changer volontairement une étiquette et observer les deux versions. Faites d’abord une copie de sauvegarde, car les prochaines leçons utilisent le fichier original.

1. Copiez les données d’évaluation dans un fichier de sauvegarde :

   macOS et Linux

   cp data/cases.jsonl data/cases.backup.jsonl

   Windows

   Copy-Item data\cases.jsonl data\cases.backup.jsonl

2. Ouvrez data/cases.jsonl dans VS Code. Cherchez (Ctrl+F, ou Cmd+F sur macOS) T-64944. Sur cette ligne, remplacez "next_step": "photo" par "next_step": "return_steps" : l’étiquette avant la révision. Enregistrez le fichier.

3. Exécutez python -m harness cases. La première ligne affiche maintenant une nouvelle version :

   271 cases, dataset version d7ae5a8497ad

4. Exécutez de nouveau la commande de l’étape 3 de la section précédente. La version des entrées reste 3f90ab808275 : vous avez changé une étiquette, pas une entrée.

5. Remettez le fichier original en place :

   macOS et Linux

   mv data/cases.backup.jsonl data/cases.jsonl

   Windows

   Move-Item -Force data\cases.backup.jsonl data\cases.jsonl

6. Exécutez encore une fois python -m harness cases. La version doit de nouveau être {ds.version}.

Et si vous changez plutôt le texte d’un billet?

Amira a fait l’essai : elle a retiré un point d’interrogation du texte de T-64944. La version du jeu de données est devenue fd626b625f82, et la version des entrées est devenue 07c4e9eae983. Si une entrée change, les sorties enregistrées ne correspondent plus aux cas. Chaque système doit alors être exécuté de nouveau sur le nouveau jeu.

À vous de jouer : vous faites la révision

Trois étiquettes ont changé pendant la révision. Lisez chaque cas avec python -m harness show <ID> --run baseline, puis lisez la politique dans data/policy.md. Pour chacun, écrivez « d’accord » ou « pas d’accord » et justifiez votre choix en une phrase.

1. T-64740 : le poteau d’un parasol s’est fissuré et la toile est tombée vers un enfant. Prochaine étape : warranty_claim → none.
2. T-81024 : une commande en retard de quatre semaines et une menace de poursuite. Prochaine étape : investigate → none.
3. T-65003 : un taille-haie que le client a essayé et veut maintenant retourner. Prochaine étape : return_steps → none, et needs_human reste à faux.

Afficher les notes d’une personne chargée de la révision

Ce sont des notes, pas la réponse. Une autre personne attentive peut être en désaccord.

1. D’accord. La règle H1 s’applique, donc une personne s’en occupe. La réponse doit dire « cessez de l’utiliser » et qu’une personne contactera le client. Cette personne décide du recours à la garantie. La réponse ne doit donc pas le promettre.
2. D’accord. La règle H2 s’applique (un avocat). Une personne traite le billet, donc la réponse ne doit pas promettre une enquête. Elle dit seulement qu’une personne contactera le client.
3. Pas d’accord, ou du moins, demander à Grace. La provenance elle-même dit qu’« une personne doit décider si le produit peut être retourné ». Si une personne doit décider, peut-être que la règle H3 (hors de la politique) s’applique. Dans ce cas, needs_human devrait être à vrai. La référence de base indiquait vrai. La politique n’est pas claire ici. Notez la question pour Grace et ne changez pas l’étiquette sans consulter quelqu’un.

Erreur courante

La version du jeu de données n'est pas d4c96eaa10c0

Symptôme : python -m harness cases affiche une autre version sur sa première ligne, par exemple 271 cases, dataset version d7ae5a8497ad (271 cas, version du jeu de données d7ae5a8497ad). Rien d’autre ne semble anormal, et les tests réussissent toujours.

Cause : data/cases.jsonl a changé. Vous n’avez peut-être pas remis la sauvegarde en place après l’exercice. Ou un éditeur a modifié le fichier lors de l’enregistrement, par exemple les fins de ligne. Un score obtenu avec ce fichier n’est pas comparable aux scores de ce cours.

Solution :

1. Vérifiez le fichier avec les sommes de contrôle fournies. Sur macOS et Linux, exécutez shasum -a 256 -c SHA256SUMS dans le dossier data. cases.jsonl: OK signifie que le fichier est l’original. Sur Windows, exécutez Get-FileHash data\cases.jsonl et comparez l’empreinte à la première ligne de data/SHA256SUMS. Windows l’affiche en majuscules; les lettres sont les mêmes.
2. Si le fichier n’est pas l’original, remettez la sauvegarde en place (étape 5 de l’exercice). Sans sauvegarde, copiez data/cases.jsonl depuis l’instantané des exercices C11/snapshots/end-of-m01.
3. Exécutez python -m harness cases. La version doit être {ds.version}.

Vérifiez votre compréhension

Tomás propose de noter les réponses selon le nombre de mots qu'elles partagent avec une réponse de référence. Utilisez le billet T-64707 pour expliquer le problème et dites ce que les étiquettes contiennent plutôt.

Afficher la réponse

Pour T-64707, la réponse correcte de la référence de base partage seulement 9 des 19 mots de la réponse de référence (0,47). Une réponse incorrecte construite pour l’exemple en partage 16 (0,84). Elle affirme « Nous avons remboursé », alors que l’assistant ne peut rien rembourser. Le chevauchement des mots favorise donc la mauvaise réponse. Les étiquettes indiquent plutôt ce qui doit être vrai. Elles donnent les décisions (équipe, needs_human avec sa règle) et ce que la réponse doit contenir : ici, le délai lié à la double facturation. Elles indiquent aussi ce qu’elle ne doit pas contenir : une action prétendument effectuée ou une demande de renseignement secret.

Vérifiez votre compréhension

La révision a changé 32 étiquettes après l'exécution de la référence de base. Pourquoi son exécution enregistrée reste-t-elle valide, et quand ne le serait-elle plus?

Afficher la réponse

Le système a seulement vu les identifiants des cas, les textes et les pièces jointes. La révision a changé des étiquettes, pas des entrées. La version des entrées est donc restée 3f90ab808275. Les sorties enregistrées restent celles de ces billets précis. Les scores changent, car ils sont calculés avec les nouvelles étiquettes, mais les sorties ne changent pas. Si un texte ou une pièce jointe changeait, la version des entrées changerait. Il faudrait alors exécuter les systèmes de nouveau.

Vérifiez votre compréhension

La révision a porté seulement sur les cas où un système était en désaccord avec une étiquette. Nommez un problème de cette procédure et un changement qui le corrige.

Afficher la réponse

Personne n’a lu les cas où l’étiquette et les deux systèmes se trompaient de la même façon. Et chaque changement a rapproché une étiquette de ce qu’un système avait dit. La révision peut donc seulement améliorer les résultats apparents des systèmes. Une solution est de demander à une deuxième personne d’étiqueter les mêmes cas sans voir les premières étiquettes. Une autre est que Grace, responsable de la politique, tranche chaque désaccord. Une troisième consiste à appliquer chaque décision à tous les cas concernés, comme pour la décision liée à la sécurité.

Récapitulatif

• Une réponse de référence est une mauvaise cible : plusieurs réponses sont correctes, et une mauvaise peut partager la plupart de ses mots. Utilisez-la comme exemple de référence pour les lecteurs, pas comme test.
• Chaque cas a des étiquettes : décisions (équipe, needs_human et sa règle), critères pour la réponse (must (doit contenir), must_not (ne doit pas contenir)) et provenance (qui, quand, comment, ce qui a changé et pourquoi).
• L’auteur du cours a rédigé les étiquettes en appliquant la politique écrite de Grace, puis des scripts les ont vérifiées. C’est l’interprétation d’une seule personne; au module 4, vous serez la deuxième personne à noter certaines réponses.
• La révision a porté sur 63 cas où un système était en désaccord et a changé 32 étiquettes de prochaine étape. Réviser seulement les désaccords d’un système ne peut qu’améliorer ses résultats apparents. Deux personnes indépendantes et un responsable qui tranche les désaccords offrent une méthode plus solide.
• La version du jeu de données correspond aux 12 premiers caractères de l’empreinte SHA-256 du fichier : {ds.version}. La version des entrées ({ds.inputs_version}) couvre seulement ce que le système voit. Les sorties enregistrées restent donc valides après un changement d’étiquette.
• Votre projet contient maintenant inputs_version(). Les tests réussissent toujours : 8 passed (8 tests réussis).

Ensuite, vous garderez séparées les trois parties du jeu de données. Vous mesurerez ce qui arrive lorsqu’un cas de test a déjà été vu.

Leçon suivante : Éviter la contamination