Aller au contenu principal
Commencer gratuitement
Menu
Leçon 1 sur 9 · Évaluation de prompts

Introduction aux évaluations

Leçon 1 sur 9 Mis à jour le 5 novembre 2026 Intermédiaire
Sur cette page
  1. Benchmarks et évaluations maison
  2. La boucle de travail
  3. De quoi est faite une évaluation
  4. Trois façons de noter
  5. Le seuil d’exactitude avant le prix
  6. À vous de jouer
  7. Points clés à retenir

Cette leçon explique ce qu’est une évaluation de prompt, en quoi elle diffère des benchmarks publiés, de quoi elle est faite, et pourquoi elle précède toute itération sérieuse sur un prompt. Vous en sortez avec le vocabulaire du cours (cas, réponse attendue, notateur, score), la boucle de travail qu’il applique de bout en bout, et le réflexe que la documentation actuelle place avant tout : fixer un seuil d’exactitude à partir de ce que coûte une erreur.

Mise à jour du 5 novembre 2026. Ce cours adapte les neuf carnets « Prompt evaluations » du dépôt anthropics/courses, écrits en 2024 pour Claude 3 ; le dépôt est archivé en lecture seule depuis le 15 septembre 2026. La démarche n’a pas bougé, mais trois choses ont changé : le Workbench de la Console, support de la leçon 2, a été retiré le 17 août 2026 au profit du playground, qui n’enregistre pas d’évaluations ; le code a été relu contre la documentation actuelle (famille Claude 5.5 et Fable 5.1, sorties structurées, réflexion adaptative, API de lots) ; et Claude Academy a publié en 2026 un cours « Introduction to evals » dont les repères (seuil d’exactitude, coût par tâche réussie, verdict structuré, évaluations en production) sont intégrés aux leçons 2, 8 et 9. Les identifiants promptfoo ont été vérifiés le 5 novembre 2026 sur la documentation de l’outil.

Benchmarks et évaluations maison

Le cours s’ouvre sur une distinction qui évite bien des malentendus. Les benchmarks de modèles (MMLU, ARC, TruthfulQA et leurs successeurs) sont les examens standardisés de l’IA : les éditeurs les publient pour comparer les modèles entre eux et suivre le progrès général. Ils renseignent sur les aptitudes larges d’un modèle, pas sur son aptitude à votre tâche. L’image du cours est celle du couteau suisse : il fait vingt choses, mais si vous l’achetez pour ouvrir des boîtes de conserve en camping, une seule compte. Le cours de Claude Academy le dit plus sèchement : aucune comparaison publiée n’a jamais vu votre prompt.

Les évaluations de prompt, ou évals, sont des tests systématiques qui mesurent ce qu’un couple prompt + modèle produit sur votre cas d’usage. Deux citations de l’équipe des architectes solutions d’Anthropic, reprises du carnet, résument l’enjeu : l’incapacité à mesurer la performance des modèles est le premier obstacle au passage en production, et c’est elle qui fait du prompting un art plutôt qu’une science ; les évaluations prennent du temps, mais faites en amont, elles en font gagner et sortent de meilleurs produits plus tôt. Les deux raisons pour lesquelles on ne les écrit pas sont tout aussi simples : on ne connaît pas l’idée, ou on ne sait pas par où commencer. Le cours répond aux deux.

Ce qu’une évaluation vous apporte, concrètement :

  • Itérer sur le prompt : la version 2 fait-elle mieux que la version 1 sur ma tâche ?
  • Assurer la qualité avant et après chaque déploiement : la dernière modification a-t-elle provoqué une régression ?
  • Comparer des modèles objectivement : puis-je passer au nouveau modèle en gardant ou en améliorant mon score ?
  • Réduire les coûts : puis-je passer au modèle le moins cher et le plus rapide sans perdre en qualité ?

La boucle de travail

Écrire et optimiser un prompt suit une boucle dont l’évaluation est le pivot : on commence par les cas de test, on écrit un premier jet de prompt, on le fait passer sur les cas pour obtenir un score de référence, puis on modifie le prompt et on recommence. Sans mesure quantitative, impossible de savoir si une modification améliore quoi que ce soit. La documentation actuelle ajoute une étape en amont, que la leçon 2 détaille : définir des critères de réussite mesurables avant d’écrire la première ligne du prompt, et garder un jeu de cas mis de côté pour la validation finale.

La boucle prompt + évaluation Cinq étapes : écrire les cas de test, rédiger un premier prompt, le faire passer sur les cas pour un score de référence, lire les échecs et modifier le prompt, relancer ; retour vers le score tant qu'il bouge. INTRODUCTION La boucle prompt + évaluation 1 Cas entrées réelles + réponses attendues, écrites avant tout appel 2 Brouillon un premier prompt honnête, pas le meilleur possible 3 Score chaque sortie comparée à l'attendu par un notateur 4 Échecs les lire : format ? raisonnement ? consigne manquante ? 5 Retouche un changement ciblé, puis relancer les mêmes cas tant que le score bouge ; en amont, des critères de réussite et un jeu mis de côté Sans mesure, impossible de savoir si un changement améliore quoi que ce soit : c'est ce qui fait du prompting une science plutôt qu'un art.
D'après le carnet « Evaluations 101 » (anthropics/courses, carnet archivé) et la page Define success criteria and build evaluations (documentation Claude).

De quoi est faite une évaluation

Une évaluation bien conçue repose sur quatre éléments, et le vocabulaire vaut pour tout le cours.

  • L’entrée : l’instruction ou la question posée au modèle. Elle doit ressembler à ce que votre application recevra réellement, cas limites compris.
  • La réponse attendue (golden answer) : la réponse correcte ou idéale, écrite par une personne avant qu’un modèle ne tourne. Pour les tâches spécialisées, elle vient des experts du domaine.
  • La sortie du modèle : ce que le couple prompt + modèle a produit pour cette entrée.
  • Le score : une valeur, quantitative ou qualitative, qui dit comment la sortie se compare à la réponse attendue.

Une entrée avec sa réponse attendue forme un cas ; ce qui compare la sortie à l’attendu s’appelle un notateur (grader), que ce soit du code, un modèle ou une personne. Le carnet recommande au moins cent cas pour obtenir des résultats fiables, tout en avouant que ses propres exemples en comptent beaucoup moins pour épargner les crédits des apprenants. Le cours de Claude Academy nuance pour les débutants : un jeu de vingt à cinquante cas simples est déjà un excellent point de départ, à condition qu’il ressemble à ce que la production envoie.

De quoi est faite une évaluation Quatre tuiles : l'entrée, la réponse attendue, la sortie du modèle, le score ; entrée et réponse attendue forment un cas, ce qui compare s'appelle un notateur. VOCABULAIRE De quoi est faite une évaluation 01 Entrée L'instruction ou la question, telle que l'application la recevra ; cas limites compris. Réaliste Stratifiée 02 Réponse attendue La réponse correcte, écrite par une personne avant tout appel ; par un expert si la tâche l'exige. Golden answer Jeu étiqueté 03 Sortie du modèle Ce que le couple prompt + modèle a produit pour cette entrée. Collectée Transformée au besoin 04 Score Ce que vaut la sortie face à l'attendu : réussi ou non, un nombre, un verdict. Par notateur Agrégé en % Entrée + réponse attendue = un cas. Ce qui compare la sortie à l'attendu = un notateur : du code, un modèle ou une personne.
D'après le carnet « Evaluations 101 » (anthropics/courses, carnet archivé).

Trois façons de noter

Le cours distingue trois approches de notation, et la documentation actuelle donne la règle de choix : prendre la méthode la plus rapide qui reste fiable et passe à l’échelle.

La notation par code compare la sortie à l’attendu par une règle : égalité exacte, présence d’une phrase, expression régulière, validation d’un JSON. Elle est la plus rapide, la plus fiable et la moins chère ; elle ne sait juger que ce qu’on peut programmer. Leçons 3 à 7.

La notation humaine fait lire chaque sortie à une personne. C’est la plus souple et la plus fine, mais lente et coûteuse ; la documentation conseille de l’éviter autant que possible. Le cours de Claude Academy lui laisse les travaux spécialisés à fort enjeu, les réponses qui relèvent du jugement, et le contrôle par échantillon des autres notateurs. Leçon 2.

La notation par modèle confie le jugement à un second modèle muni d’une grille : ton, pertinence, exactitude par rapport à un document, respect d’une charte. Rapide, souple, elle passe à l’échelle, mais on teste d’abord sa fiabilité avant de s’y fier. Leçons 8 et 9.

Trois façons de noter Trois colonnes : par code (rapide, fiable, étroit), par un humain (fin, lent, coûteux), par un modèle (souple, à vérifier) ; la règle : la méthode la plus rapide qui reste fiable. NOTATEURS Trois façons de noter Code Comment Égalité, sous-chaîne, expression régulière, schéma, ensembles. Pour Identifiants, catégories, nombres, formats. Limite Ne juge que ce qu'on sait programmer. Leçons 3 à 7 Humain Comment Une personne lit chaque sortie et note. Pour Travaux spécialisés, fort enjeu ; contrôle par échantillon. Limite Lent, coûteux : à éviter en routine. Leçon 2 Modèle Comment Un second modèle, une grille, un verdict structuré. Pour Ton, pertinence, refus, exactitude face à un document. Limite À tester contre le code et contre un humain avant confiance. Leçons 8 et 9 Règle de la documentation : prendre la méthode la plus rapide, la plus fiable et la plus scalable ; le code dès qu'une vérification exacte existe.
D'après la page Define success criteria and build evaluations (documentation Claude) et le carnet « Evaluations 101 » (anthropics/courses, carnet archivé).

Le seuil d’exactitude avant le prix

Le cours de 2024 présentait les économies possibles comme un bénéfice parmi d’autres. Le cours de Claude Academy de 2026 en fait une méthode : on décide d’abord quel taux de réussite un modèle doit atteindre pour être déployé, puis seulement on regarde ce qu’il coûte. L’image est celle de l’échelle à acheter pour atteindre le haut d’un mur : avant de comparer les prix, on mesure le mur, parce qu’une échelle trop courte ne vaut rien à aucun prix ; parmi celles qui atteignent, on prend la moins chère.

Le seuil se calcule à partir de ce que coûte une mauvaise réponse. L’exemple du cours : une mauvaise extraction oblige quelqu’un à vérifier un rapport à la main, cinq minutes ; l’équipe peut en absorber cinq par mois sur cinquante rapports, donc le seuil est de 90 %. Si une erreur coûte 1 000 dollars parce qu’elle atteint un client, le seuil monte à 100 % et le prix du modèle compte à peine. On compare ensuite les modèles sur le coût par tâche réussie : le coût total d’un passage sur tous les cas, divisé par le nombre de tâches réussies et non par le nombre d’appels, parce que chaque appel est facturé, y compris ceux qui se trompent. La leçon 9 montre les tableaux complets.

À vous de jouer

Nommer votre tâche. Prenez un prompt que vous utilisez déjà et répondez par écrit : quelle est l’entrée, quelle est la réponse attendue, qui serait capable de l’écrire à l’avance, et qu’est-ce qui fait qu’une sortie est juste ? Si la dernière réponse tient en une règle, la notation par code suffira ; sinon notez pourquoi.

Chiffrer une erreur. Pour la même tâche, estimez ce que coûte une mauvaise réponse (temps de correction, client perdu, décision faussée) et combien d’erreurs par mois votre équipe absorbe. Déduisez-en votre seuil d’exactitude ; vous le réutiliserez à la leçon 2.

Sources officielles : 01_intro_to_evals.ipynb (anthropics/courses, archivé) · Define success criteria and build evaluations (documentation Claude) · Introduction to evals (Claude Academy, 2026)

Points clés à retenir

  • Les benchmarks comparent les modèles entre eux ; une évaluation mesure un couple prompt + modèle sur votre tâche.
  • Une évaluation = des cas (entrée + réponse attendue écrite à l’avance), les sorties du modèle, un notateur, un score.
  • Trois notateurs : code (rapide et fiable), humain (fin mais lent), modèle (souple, à vérifier avant de s’y fier).
  • Cent cas sont la recommandation du cours ; vingt à cinquante cas réalistes suffisent pour commencer.
  • Fixer le seuil d’exactitude à partir du coût d’une erreur, puis comparer les modèles au coût par tâche réussie.
Leçon suivante →Critères de réussite et première évaluation à la main