Critères de réussite et première évaluation à la main

Cette leçon prend la place du carnet consacré au Workbench de la Console, qui proposait un outil d’évaluation notée à la main avec comparaison de versions. Cet outil n’existe plus : le Workbench a été retiré le 17 août 2026, remplacé le 18 par le playground, qui montre la requête SDK et la réponse de chaque exécution mais n’enregistre ni prompts, ni variables, ni évaluations. La démarche du carnet, elle, reste entière : on la refait ici avec ce que la documentation recommande aujourd’hui, des critères de réussite écrits, un jeu de cas conçu, un notateur par champ, et la notation humaine remise à sa juste place, celle d’un contrôle par échantillon.

Des critères avant le prompt

La documentation actuelle fait précéder toute évaluation d’une étape que le cours de 2024 laissait implicite : définir des critères de réussite. Un bon critère est spécifique (« classification de sentiment exacte » plutôt que « de bonnes performances »), mesurable (une métrique chiffrée ou une échelle qualitative appliquée de façon constante), atteignable (fondé sur des repères connus, pas sur un espoir) et pertinent (aligné sur ce que l’application doit faire pour ses utilisateurs). Même un sujet flou se chiffre : « moins de 0,1 % de sorties signalées toxiques sur dix mille essais » est un critère ; « des sorties sûres » n’en est pas un.

La documentation donne le contre-exemple et l’exemple pour une analyse de sentiment. Mauvais : « le modèle doit bien classer les sentiments ». Bon : « un score F1 d’au moins 0,85 sur un jeu de test mis de côté de dix mille messages variés, soit cinq points de mieux que la base actuelle ». La plupart des cas d’usage demandent plusieurs critères à la fois : fidélité à la tâche, cohérence entre réponses similaires, pertinence, ton, respect de la confidentialité, exploitation du contexte, latence, prix. Le même exemple, complet, fixe à la fois un F1 minimal, un taux de sorties non toxiques, une répartition des erreurs entre gênantes et graves, et un temps de réponse.

Concevoir le jeu de cas

Trois principes de conception viennent de la documentation, et le cours de Claude Academy en ajoute un quatrième.

• Coller à la tâche : les cas reflètent la distribution réelle des entrées, cas limites compris : données absentes ou hors sujet, entrées trop longues, saisies malveillantes pour un chat, cas ambigus où des humains ne seraient pas d’accord.
• Automatiser autant que possible : formuler les questions pour qu’un programme ou un modèle puisse noter (choix multiple, correspondance de chaîne, code, juge LLM).
• Préférer le volume à la finesse : beaucoup de cas notés automatiquement avec un signal un peu plus faible valent mieux que quelques cas notés à la main avec soin.
• Stratifier les cas limites : donner à chaque type d’entrée inhabituelle à peu près la part qu’il a en production. Si les rapports scannés font 5 % du flux, ils font 5 % du jeu.

L’exemple fil rouge du cours de Claude Academy, repris aux leçons 8 et 9, rend cela concret. Meridian, un bureau d’études fictif, reçoit cinquante rapports de projet par mois et un prompt en extrait trois champs : l’identifiant du projet, l’état du planning, le risque principal. Son jeu compte cinquante cas : trente rapports ordinaires, dix qui couvrent plusieurs projets, dix sans section « risques ». Les réponses attendues sont écrites à la main avant le premier appel, dans un seul fichier, golden.json, qui contient un enregistrement par cas : son identifiant, sa catégorie (typical, multi_project ou missing_risk) et la réponse attendue pour chaque champ. C’est le jeu étiqueté.

Un notateur par champ

La règle est de prendre, pour chaque champ, la méthode la plus rapide qui reste fiable. Le code vérifie tout ce qu’il peut vérifier exactement ; le juge LLM reçoit seulement ce qui reste ; les personnes gardent les travaux spécialisés et le contrôle par échantillon. Pour les trois champs de Meridian :

Quand un rapport ne nomme aucun risque, la réponse attendue est null, et le code sait vérifier cela par une égalité exacte. Ce découpage dessine le reste du cours : notation par code (leçons 3 à 7), juge LLM (leçons 8 et 9).

L’exercice du carnet, refait à la main

Le carnet du Workbench travaillait sur un prompt de traduction de code vers Python, avec deux variables, le code source et son langage. Il l’essayait sur trois entrées (JavaScript, Ruby, C#), notait chaque sortie sur 5, modifiait le prompt, relançait et comparait les deux versions côte à côte. Rien de tout cela n’exige l’outil disparu : un tableur à quatre colonnes (entrée, sortie v1, sortie v2, note) et le playground, ou trois appels à l’API, suffisent.

Le premier prompt demandait simplement de traduire le code fourni. Les trois sorties étaient correctes, et toutes avaient les mêmes défauts : un préambule (« Certainly! Here’s the Python translation… »), le code noyé dans des explications, un format impossible à traiter par programme. Le carnet leur donnait 3 sur 5. La version 2 ajoutait trois lignes : formater la réponse dans une balise <python_code>, et n’émettre que cette balise, sans autre texte. Les trois nouvelles sorties ne contenaient plus que le code, balisé : 5 sur 5. La comparaison de versions du Workbench ne faisait que mettre ces deux colonnes côte à côte.

Please translate this code to Python.
Format your response as follows:

<python_code>
Your Python translation here
</python_code>

Only output the <python_code> tags without any other text content

Ce que l’exercice enseigne vraiment, c’est la limite de la notation humaine : elle a suffi pour trois cas et deux versions, elle ne tiendra pas cinquante cas et dix versions. Dès la leçon suivante, le code prend le relais, et la personne ne revient que pour noter un échantillon et vérifier que les notateurs automatiques sont d’accord avec elle.

À vous de jouer

Écrire vos critères. Reprenez la tâche choisie à la leçon 1 et rédigez trois critères qui passent les quatre tests (spécifique, mesurable, atteignable, pertinent), dont un sur la forme de la sortie et un sur le coût ou la latence. Indiquez pour chacun comment vous le mesurerez.

Construire vingt cas. Rassemblez vingt entrées réelles, dont trois ou quatre cas limites dans la proportion où ils arrivent ; écrivez la réponse attendue de chacun avant tout appel ; décidez pour chaque champ s’il sera noté par code, par juge ou par vous. Ce jeu sert jusqu’à la fin du cours.

Sources officielles : 02_workbench_evals.ipynb (anthropics/courses, archivé) · Define success criteria and build evaluations (documentation Claude) · Build a minimum viable eval (Claude Academy, 2026) · Notes de version de la plateforme (retrait du Workbench le 17 août 2026, playground le 18)

Points clés à retenir

• Un critère de réussite est spécifique, mesurable, atteignable et pertinent ; la plupart des tâches en demandent plusieurs.
• Le jeu de cas reflète la production, cas limites compris et dans leur proportion ; les réponses attendues s’écrivent avant tout appel.
• Un notateur par champ : code dès qu’une vérification exacte existe, juge LLM pour le texte libre, humain pour l’échantillon.
• Le Workbench a disparu en août 2026 ; sa démarche (noter, modifier, comparer des versions) se fait avec un tableur et le playground.
• La notation humaine ne passe pas à l’échelle : elle sert à contrôler les notateurs automatiques, pas à les remplacer.