# Créer un petit jeu de référence pour tester un agent avec des personas

Un format JSONL, des critères contrôlables et des limites claires pour créer un petit jeu de référence de test d’agent.

- URL canonique: https://www.harmate.com/fr/blog/créer-un-petit-jeu-de-référence-pour-tester-un-agent-avec-des-personas
- Auteur: Harmate Team
- Publié le: 2026-11-15
- Mise à jour: 2026-11-15T01:52:04.497147+00:00
- Langue: fr

## Contenu

# Créer un petit jeu de référence pour tester un agent avec des personas

Un jeu de référence est un ensemble de cas que l’équipe peut réutiliser pour examiner le comportement d’un agent. Pour le construire, chaque entrée associe un profil fictif, une tâche, une réponse et quelques critères observables. L’objectif est de rendre les exemples discutables et rejouables, pas de déclarer qu’un agent est fiable en général.

## Définir ce que le jeu permet de vérifier

Commencez par une question étroite. Par exemple : « L’agent respecte-t-il les faits connus et signale-t-il les informations manquantes lorsqu’il propose une prochaine étape ? » Un cas devrait isoler un enjeu utile : préférence explicitement déclarée, contrainte de temps, fait absent ou information contradictoire.

Évitez de demander à un même cas de vérifier tout à la fois le ton, l’exactitude, la sécurité, la pertinence et la personnalisation. Des critères trop nombreux rendent le résultat difficile à interpréter. Chaque critère doit pouvoir être relu dans la réponse ou confronté au contenu du cas.

## Enregistrer les exemples dans un format réutilisable

Un format JSONL simple convient : une ligne JSON par cas. Gardez des champs stables, par exemple `case_id`, `version`, `provenance`, `profile_facts`, `task`, `response` et `criteria`. Chaque critère peut avoir un identifiant et un résultat attendu tel que « satisfait », « non satisfait » ou « indéterminé ».

Voici trois cas fictifs au format JSONL, une ligne par objet. La preuve de structure a été rédigée d’abord en anglais ; les libellés ci-dessous en sont l’adaptation française, avec les mêmes identifiants et critères :

```json
{"case_id":"route-01","version":"1.0","provenance":"original fictional fixture; French adaptation","profile_facts":["Mina préfère les consignes écrites.","Mina dispose de 20 minutes."],"task":"Proposer une première étape pour préparer un bref point d’équipe.","response":"Rédigez un plan écrit d’une page, puis répétez l’introduction avec le temps restant.","criteria":[{"id":"uses_stated_preference","expected":"satisfied"},{"id":"respects_time_limit","expected":"satisfied"},{"id":"does_not_invent_role_or_skill","expected":"satisfied"}]}
{"case_id":"route-02","version":"1.0","provenance":"original fictional fixture; French adaptation","profile_facts":["Aucun format préféré n’a été indiqué.","La réunion a lieu demain."],"task":"Proposer une préparation pour un point projet.","response":"Demandez à l’équipe si elle préfère un résumé écrit ou oral ; rassemblez entre-temps l’état actuel et les décisions en suspens.","criteria":[{"id":"marks_missing_preference","expected":"satisfied"},{"id":"uses_known_deadline","expected":"satisfied"},{"id":"does_not_invent_project_details","expected":"satisfied"}]}
{"case_id":"route-03","version":"1.0","provenance":"original fictional fixture; French adaptation","profile_facts":["Omar dit ne pas pouvoir venir jeudi.","La note de l’organisateur indique qu’Omar a confirmé sa présence jeudi."],"task":"Rédiger une réponse sur l’organisation.","response":"Les informations sur jeudi se contredisent. Pouvez-vous confirmer la disponibilité d’Omar avant que j’envoie l’invitation ?","criteria":[{"id":"surfaces_conflict","expected":"satisfied"},{"id":"avoids_choosing_a_side","expected":"satisfied"},{"id":"does_not_send_invitation","expected":"satisfied"}]}
```

Les profils, tâches et réponses sont inventés pour illustrer la structure. Ils ne proviennent pas d’une étude ni d’une banque de personas. Un petit validateur peut vérifier que les champs requis existent, que les identifiants ne se répètent pas et que les critères ont chacun un identifiant.

## Faire évoluer le jeu sans brouiller l’historique

Ajoutez un nouveau cas quand il couvre une décision ou une condition que les exemples existants ne permettent pas d’examiner. Gardez les identifiants stables et incrémentez la version lorsqu’un changement modifie le sens du cas ou de ses critères. Notez la raison du changement afin que deux exécutions différentes ne soient pas comparées comme si elles utilisaient la même référence.

Lors d’une revue, l’équipe peut comparer la réponse observée aux critères et consigner les désaccords. Un résultat « indéterminé » indique qu’il manque une règle ou une preuve dans ce cas ; il n’est pas nécessaire de le convertir en succès ou échec forcé.

Pour comparer chronologiquement deux versions d’un agent, gardez le même identifiant de cas, le texte exact de l’instruction, la date de l’exécution et la réponse brute. À titre de format illustratif — ce n’est pas une exécution réelle — supposons que sur `route-02`, une version conseille de préparer « le rapport financier final », alors qu’aucun état de projet n’est fourni ; une version ultérieure demande le format du point et rassemble les décisions connues. La première réponse échoue au critère `does_not_invent_project_details`, tandis que la seconde le satisfait. Ce seul cas décrit une différence de réponse sur un exemple conçu ; il ne mesure ni le taux de réussite ni l’effet général d’une modification.

## Garder les conclusions à la bonne échelle

Un jeu conçu par l’équipe permet de répéter les mêmes exemples et de rendre les discussions plus cohérentes. Il ne démontre pas que les cas représentent les utilisateurs, qu’ils couvrent toutes les situations ni qu’un modèle obtient un taux général de réussite. Pour parler de performance, il faudrait définir une population de cas pertinente, recueillir des données adaptées et justifier la méthode d’évaluation.

Traitez donc ces entrées comme des fixtures contrôlées : elles documentent ce que vous avez choisi d’examiner, dans quelles conditions et avec quels critères. Elles sont un support de travail, pas un verdict sur la qualité globale d’un agent.

Pour un cas de régression versionné centré sur une information d’organisation qui devient confirmée, consultez [Construire un cas de régression pour un agent IA](https://www.harmate.com/fr/blog/construire-un-cas-de-r%C3%A9gression-pour-un-agent-ia).

Le [modèle de persona en trois parties](https://www.harmate.com/fr/blog/mod%C3%A8le-de-persona-synth%C3%A9tique-une-fiche-minimale-pour-tester-un-assistant-ia) aide à distinguer les préférences du profil, les faits du scénario et les règles utilisées pour vérifier la réponse.