# Comment créer un ensemble d’évaluation à partir de votre propre travail?

Date: 2026-01-12 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/ensemble-evaluation-propre-travail/

**Answer:** Rassemblez une trentaine de vraies tâches que vous avez déjà faites, notez pour chacune l’entrée et ce que doit contenir une bonne réponse, et choisissez comment chacune sera notée : par correspondance exacte, avec une courte grille ou par un modèle qui joue le rôle de juge. Faites passer chaque modification de prompt ou de modèle sur l’ensemble complet et comparez les résultats, en gardant à l’esprit que 30 exemples détectent les grandes différences, pas les petites.

Une **eval** (abréviation d’*evaluation*, évaluation) est un ensemble fixe de cas de test sur lequel vous faites tourner un système d’IA pour mesurer s’il fait bien un travail. Les bancs d’essai publics sont des evals construites par des chercheurs pour mesurer des habiletés générales. Une eval construite à partir de votre propre travail répond à une question plus étroite et plus utile : ce prompt, ce modèle ou cet agent fait-il bien *mes* tâches, et la modification que je viens de faire a-t-elle aidé ou nui?

Vous n’avez pas besoin d’un logiciel spécial pour commencer. Un tableur fait l’affaire, et un format de fichier simple vous permet de passer au code plus tard. Ce qui compte, c’est que les cas soient réels, que la définition d’une « bonne » réponse soit écrite avant de regarder le moindre résultat, et que vous utilisiez chaque fois le même ensemble.

## Étape 1 : rassembler 30 vraies tâches

Parcourez votre travail récent et recopiez 30 tâches pour lesquelles vous aimeriez l’aide d’une IA. Supposons que vous gérez les communications d’un petit organisme sans but lucratif et que vous voulez de l’aide pour transformer les notes des réunions du conseil d’administration en courte mise à jour publique. Choisissez :

- environ 20 cas **typiques** (des réunions ordinaires),
- environ 7 cas **difficiles** (notes longues, décisions contradictoires, points délicats qui doivent rester confidentiels),
- environ 3 cas **limites** (notes sans décision, notes en abrégé, une réunion annulée).

Répartissez-les sur différents mois et sujets. Si dix cas viennent d’une même longue réunion, ce ne sont pas dix tests indépendants, un point sur lequel les sections suivantes reviennent.

## Étape 2 : écrire ce que doit contenir une bonne réponse

Pour chaque cas, écrivez le **résultat attendu**. Parfois, c’est une seule réponse exacte, comme une catégorie ou un nombre. Pour les tâches de rédaction, c’est habituellement une courte liste d’éléments obligatoires et d’éléments interdits plutôt qu’un texte parfait :

| Cas | Doit inclure | Ne doit pas inclure |
|---|---|---|
| 07 – réunion de mars | Date de début du nouveau programme (14 avril); budget approuvé | Noms des deux employés dont il a été question à huis clos |
| 12 – réunion de juin | Vote du conseil sur le nouveau bureau | Chiffres provisoires marqués « non définitif » |

Les conseils d’OpenAI pour son cadre à code source ouvert Evals nomment quatre qualités d’une bonne eval : ses cas partagent un thème, ils sont exigeants, on voit clairement à quoi ressemble une bonne réponse grâce à des réponses de référence ou à une grille, et quelqu’un a vérifié les cas avec soin. Ce dernier point compte plus qu’il n’y paraît : une réponse attendue erronée pénalise en silence un modèle qui a raison.

## Étape 3 : choisir comment chaque cas est noté

Il existe trois méthodes de notation courantes, et une même eval peut les combiner :

1. **Correspondance exacte ou inclusion.** Le résultat doit être égal à une chaîne précise, ou la contenir. Rapide, gratuit et objectif; bon pour les dates, les étiquettes et les nombres.
2. **Une grille notée par une personne.** Une courte liste de vérification, par exemple : tous les éléments obligatoires présents (2 points), aucun élément interdit (2 points), moins de 150 mots (1 point). Plus lent, mais digne de confiance.
3. **Un modèle comme juge.** Un autre modèle note le résultat selon la grille. L’étude MT-Bench de 2023 a constaté que des modèles puissants utilisés comme juges s’accordaient avec les préférences humaines plus de 80 % du temps, mais elle a aussi montré des biais connus : ils favorisent les réponses plus longues, peuvent favoriser la réponse présentée en premier et peuvent préférer leur propre texte. Si vous comparez deux versions avec un juge, faites-le deux fois en inversant l’ordre et ne comptez une victoire que si les deux passages concordent.

## Étape 4 : le conserver dans un format simple

OpenAI Evals conserve les cas de test en **JSONL**, un fichier texte qui contient un objet JSON par ligne, avec une clé `input` pour le prompt et une clé `ideal` pour la réponse attendue. Même si vous n’utilisez jamais ce cadre, le format est facile à lire et à charger dans n’importe quel langage :

```json
{"id": "07", "input": [{"role": "user", "content": "Rédige une mise à jour publique de 150 mots à partir de ces notes : ..."}], "ideal": ["14 avril", "budget approuvé"], "must_not": ["huis clos"], "type": "typical"}
{"id": "12", "input": [{"role": "user", "content": "Rédige une mise à jour publique de 150 mots à partir de ces notes : ..."}], "ideal": ["nouveau bureau"], "must_not": ["non définitif"], "type": "hard"}
```

Un script de dix lignes peut alors envoyer chaque entrée à un modèle, vérifier automatiquement les listes `ideal` et `must_not`, et enregistrer les résultats pour la révision avec la grille. Gardez le fichier dans un système de gestion de versions, et quand vous modifiez un cas, notez-le, pour ne pas comparer d’anciens et de nouveaux résultats comme s’il s’agissait du même test.

> **À essayer :** ouvrez un tableur vide avec quatre colonnes : entrée, doit inclure, ne doit pas inclure, type de cas. Remplissez dix lignes à partir du travail du mois dernier avant de lancer le moindre modèle. Vous avez maintenant le début d’une eval.

## Étape 5 : s’en servir chaque fois que quelque chose change

Faites passer l’ensemble complet chaque fois que vous modifiez le prompt, changez de modèle ou ajustez les outils d’un agent. Notez le résultat et lisez chaque cas qui est passé de la réussite à l’échec. Ces quelques résultats en apprennent habituellement plus que le chiffre global.

## Combien d’exemples faut-il pour se fier au résultat?

Cela dépend de la taille de la différence que vous devez voir. Les recherches d’Anthropic sur la statistique des evals recommandent de rapporter une **erreur type** avec chaque résultat, une mesure de combien il bougerait si vous aviez tiré un autre ensemble de questions, ainsi qu’un intervalle de confiance à 95 % d’environ 1,96 erreur type de part et d’autre. Pour un taux de réussite, l’erreur type est la racine carrée de p × (1 − p) ÷ n, où p est le taux de réussite et n le nombre de cas.

Pour un système qui réussit 80 % des cas, cela donne environ ±14 points de pourcentage avec 30 cas, ±8 avec 100 et ±4 avec 400. Ainsi, 30 cas permettent de distinguer un prompt à 60 % d’un prompt à 90 %, mais pas 80 % de 84 %. Si deux versions tournent sur les mêmes cas, comparez-les cas par cas, une comparaison **appariée**, qui, comme le note Anthropic, donne une réponse plus précise que la comparaison de deux totaux. Et si de nombreux cas proviennent de la même source, comme une seule longue réunion, ils comptent moins que leur nombre ne le laisse croire; Anthropic a constaté qu’ignorer de tels regroupements pouvait sous-estimer l’erreur d’un facteur de trois ou plus.

Une démarche pratique : commencez avec 30 cas pour attraper les gros problèmes, montez vers 100 à mesure que de vraies tâches arrivent, et traitez toute différence plus petite que la marge ci-dessus comme une égalité.

## Sources

- Building an eval (openai/evals docs): https://github.com/openai/evals/blob/bd3b4d0afa7785f0374c46c32a32dd4c55105c28/docs/build-eval.md
- A statistical approach to model evaluations: https://www.anthropic.com/research/statistical-approach-to-model-evals
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena: https://arxiv.org/abs/2306.05685v4