Tester un agent IA ne consiste pas à lui confier une demande idéale et à vérifier que sa réponse paraît correcte. Avant de l'utiliser au quotidien, il faut aussi contrôler les sources consultées, les actions exécutées, les traces laissées et son comportement lorsque le contexte manque ou que la demande sort du périmètre autorisé.
Un essai réussi montre que l'agent peut agir dans un cas. Il ne montre pas encore qu'il agira de façon prévisible lorsque la situation change.
C'est pourtant là que les problèmes apparaissent : une source inaccessible, deux documents contradictoires, une destination ambiguë ou une action qui devrait attendre une validation humaine.
Pour un premier usage, je cherche donc moins à mesurer l'intelligence générale de l'agent qu'à vérifier un contrat précis : dans cette situation, avec ces sources et ces permissions, produit-il le résultat attendu et sait-il s'arrêter au bon endroit ?
Une bonne réponse ne suffit pas à tester un agent IA
Avec un chatbot, le contrôle s'arrête souvent au texte affiché. La réponse est-elle juste, claire et utile ?
Un agent ajoute d'autres dimensions. Il peut rechercher dans des fichiers, appeler des outils, modifier un état ou préparer une action externe. Son résultat visible ne raconte donc qu'une partie de l'exécution.
Anthropic distingue le compte rendu d'un essai de son résultat réel. Un agent de réservation peut affirmer qu'un vol a été réservé ; le résultat à contrôler est l'existence de la réservation dans le système concerné. L'évaluation peut aussi examiner les appels d'outils, les étapes intermédiaires et l'état final de l'environnement.
Cette distinction est directement applicable à un système personnel. Si un agent annonce qu'il a créé une capture dans Obsidian, je ne dois pas seulement lire son message de confirmation. Je dois vérifier que le fichier existe, qu'il se trouve dans le bon dossier, qu'il contient la source attendue et qu'aucune note existante n'a été remplacée.
Une sortie convaincante peut masquer un mauvais chemin :
- la bonne information a été trouvée dans une source qui n'était pas autorisée ;
- le fichier attendu existe, mais au mauvais endroit ;
- la réponse est correcte, mais une étape externe est partie sans validation ;
- l'agent dit s'être arrêté alors qu'il a déjà modifié une source de référence ;
- le cas passe une fois, puis échoue avec une formulation légèrement différente.
Tester un agent demande donc de regarder trois objets séparément : ce qu'il répond, ce qu'il fait et ce qu'il laisse derrière lui.
Transformer un usage déjà choisi en recette de test
Le choix du premier cas d'usage IA vient avant cette étape. Ici, l'usage existe déjà : il faut écrire les conditions qui permettront de conclure que son exécution est conforme.
Je m'appuie sur un usage réel de mon système personnel : j'envoie une ressource publique dans Discord afin que mon agent prépare une capture dans l'Inbox de mon vault Obsidian. Ce workflow fournit un jeu de test concret sans exposer sa configuration.
La recette précise le déclencheur, les entrées, la sortie attendue, les sources autorisées, le point de validation, le comportement de repli et la trace à contrôler. Dans son guide, OpenAI structure les évaluations autour de données de test et de critères de notation permettant de mesurer le comportement attendu.
Une fiche simple suffit au départ :
| Élément | Question à trancher |
|---|---|
| Déclencheur | Qu'est-ce qui lance l'usage ? |
| Entrées | Quelles informations sont fournies ? |
| Sources | Où l'agent peut-il chercher ? |
| Sortie | Quel résultat doit exister ? |
| Permission | Quelle règle déjà définie le test doit-il vérifier ? |
| Validation | Quel état doit être conservé pendant l'attente ? |
| Repli | Que fait-il si une information manque ? |
| Trace | Comment vérifier ce qui s'est passé ? |
Cette fiche ne redéfinit pas les permissions. Elle transforme les décisions prises en résultats observables.
Sept scénarios pour tester un agent IA
Le scénario nominal est nécessaire. Il ne doit pas être le seul.
1. Le cas nominal
L'entrée est claire, la source est accessible et la destination existe. L'agent doit produire la sortie prévue dans le bon périmètre.
Dans cet exemple, le test devrait vérifier la présence de la note, sa structure, son URL, son dossier et la trace de la modification. Un essai conforme montrerait seulement que la chaîne principale fonctionne dans ce cas.
2. Une information obligatoire manque
Je retire un élément nécessaire : aucun lien, une destination non précisée ou une demande dont le sujet ne peut pas être identifié.
Sans cet élément, la tâche reste en attente ou l'agent demande une précision. Toute valeur choisie par défaut doit avoir été prévue dans le contrat.
3. La source est inaccessible
La page peut demander une authentification, refuser l'accès ou ne plus exister.
L'absence doit rester visible. L'URL peut être conservée avec une explication du blocage, sans produire une synthèse comme si la source avait été lue. Ce scénario vérifie la provenance du résultat autant que sa forme.
4. Deux sources se contredisent
Une note existante affirme une chose tandis que la source actuelle en affirme une autre. Le test doit préciser laquelle fait autorité ou imposer un arrêt.
La présence d'une information dans une mémoire ne garantit pas qu'elle est encore exacte. Selon le sujet, l'agent peut citer les deux versions, vérifier la source directe ou demander laquelle doit devenir la référence. Il ne doit pas effacer la contradiction pour produire une réponse plus fluide.
5. La cible est ambiguë
Deux dossiers portent des noms proches, plusieurs clients ont un document similaire ou une note existe déjà sous un titre voisin.
Ce test vérifie que l'agent ne transforme pas une ressemblance en autorisation. Si le contrat ne prévoit aucune règle de résolution, le résultat attendu est de présenter les possibilités et d'attendre un choix.
6. L'action exige une validation
Ce scénario reprend une action déjà classée comme soumise à validation. La recette vérifie que l'agent prépare la modification, le message ou la publication, puis conserve son état avant l'effet externe ou la modification durable.
La validation doit porter sur une version identifiable : contenu final, cible et éventuelles pièces jointes. Si le contenu change ensuite, l'accord précédent ne couvre pas silencieusement la nouvelle version.
7. L'action est interdite
L'entrée demande de lire un espace hors périmètre, de révéler un secret, de supprimer une source importante ou de contourner une validation.
Le bon résultat est un refus sans effet secondaire. Dans son guide de réduction du risque d'agence excessive, l'OWASP recommande de limiter les fonctions et permissions des outils au minimum nécessaire, de faire appliquer l'autorisation par les systèmes en aval et d'exiger une approbation humaine pour les actions à fort impact.
Ce dernier scénario est facile à négliger. Pourtant, un système qui réussit toutes les actions autorisées mais exécute aussi les actions interdites n'est pas correctement borné.
Vérifier la sortie, le chemin et l'état final
Une grille de test doit séparer trois niveaux.
La sortie
C'est ce que la personne reçoit : réponse, synthèse, brouillon, fichier ou signalement d'erreur.
Je contrôle notamment :
- les éléments attendus ;
- les sources citées ;
- les informations manquantes rendues visibles ;
- l'absence de contenu inventé pour remplir un vide ;
- la forme nécessaire à la prochaine étape humaine.
Le chemin
C'est ce que l'agent a consulté et exécuté pour parvenir au résultat.
Il faut pouvoir répondre à quelques questions :
- quelles sources ont été ouvertes ?
- quels outils ont été appelés ?
- quelle cible a été utilisée ?
- une validation a-t-elle été demandée au moment prévu ?
- une tentative hors périmètre a-t-elle été refusée ?
Anthropic recommande de combiner plusieurs types de contrôles selon le besoin : vérifications déterministes, appréciation par un modèle et jugement humain. Les contrôles par code sont rapides et reproductibles pour des conditions précises ; l'examen humain reste adapté aux résultats qui demandent une expertise ou une appréciation du contexte.
Dans un système personnel, beaucoup de vérifications restent simples. L'existence d'un fichier, son chemin, l'absence d'écrasement et la présence d'une URL peuvent être contrôlées par des règles. La qualité d'une synthèse ou la pertinence d'un rapprochement demandent encore une lecture humaine.
L'état final
C'est ce qui existe après l'exécution, y compris en dehors de la conversation.
Le contrôle porte sur le dossier, l'historique des modifications, les éventuels messages envoyés, les coûts engagés et les données enregistrées. Une confirmation rédigée par l'agent ne le remplace pas. La même exigence s'applique lorsqu'il faut tester une restauration avant de compter sur une sauvegarde : la présence d'une copie ne prouve pas l'état retrouvé.
Cette séparation aide aussi à diagnostiquer un échec. Une sortie médiocre peut venir d'une mauvaise source. Un fichier correct peut avoir été produit avec une permission trop large. Un refus approprié peut constituer une réussite, même s'il ne fournit pas la sortie initialement demandée.
Tester plusieurs fois sans chercher un score parfait
Les sorties d'un modèle peuvent varier d'une exécution à l'autre. Anthropic recommande plusieurs essais pour obtenir une lecture plus stable d'une tâche. Pour appliquer cette méthode, on peut rejouer chaque scénario avec quelques variations plausibles : formulation plus courte, ordre des informations différent, lien redirigé ou nom de destination proche. Le but est de vérifier que la recette résiste à de petits écarts du réel, pas de piéger le système avec des demandes sans rapport avec son usage.
Une fiche de suivi peut conserver, pour chaque essai :
| Scénario | Résultat attendu | Résultat observé | Trace contrôlée | Verdict |
|---|---|---|---|---|
| Cas nominal | Capture créée dans l'Inbox | À renseigner | Fichier et historique | Conforme / à corriger |
| Source inaccessible | Blocage signalé, aucune synthèse inventée | À renseigner | Sortie et absence de fichier trompeur | Conforme / à corriger |
| Titre déjà présent | Arrêt avant écrasement | À renseigner | Diff et fichiers existants | Conforme / à corriger |
| Modification durable | Validation demandée | À renseigner | État avant validation | Conforme / à corriger |
| Espace hors périmètre | Refus sans lecture ni écriture | À renseigner | Journaux et état final | Conforme / à corriger |
Un verdict binaire ne raconte pas tout. Lorsque le test échoue, je note la cause observée : instruction ambiguë, permission trop large, source mal choisie, contrôle absent ou comportement variable. Cette précision indique ce qu'il faut corriger.
Rejouer les tests après chaque changement important
Un agent ne reste pas identique lorsque l'on change son modèle, ses instructions, un outil, une permission ou l'organisation de ses sources.
Une amélioration locale peut créer une régression ailleurs. Une consigne plus souple peut produire de meilleures synthèses tout en augmentant les choix implicites. Un nouvel accès peut résoudre un blocage et élargir trop fortement le périmètre.
Il est utile de garder un petit ensemble de scénarios de référence et de le rejouer après :
- l'ajout ou le remplacement d'un outil ;
- la modification d'une permission ;
- un changement de modèle ou de consigne ;
- le déplacement d'une source de confiance ;
- un échec observé pendant l'usage réel.
Les incidents observés peuvent enrichir progressivement cette base. Lorsqu'un cas imprévu apparaît, la correction ne devrait pas rester une consigne ajoutée dans l'urgence. Le cas peut devenir un scénario reproductible, avec un résultat attendu.
Cette discipline réduit le risque de corriger un comportement sans pouvoir vérifier si la correction tient lors des changements suivants.
Ce que ce protocole prouve, et ce qu'il ne prouve pas
Quelques essais réussis ne prouvent pas qu'un agent est fiable dans toutes les situations. Ils montrent qu'un usage précis respecte les critères observés dans un environnement donné.
Le protocole ne mesure pas non plus, à lui seul, la valeur de l'usage. Un agent peut passer ses tests et rester inutile parce que sa sortie arrive trop tard, demande trop de vérifications ou ne s'intègre pas aux habitudes de la personne.
Les tests répondent à une question plus limitée : le système se comporte-t-il comme prévu dans le périmètre décidé ?
L'adoption répond à une autre question : ce comportement mérite-t-il une place dans le quotidien ?
Un usage fréquent et borné permet de multiplier les observations. Les premières utilisations peuvent aider à examiner le fonctionnement, le coût de la validation et l'intérêt du résultat. La décision d'étendre l'autonomie appartient ensuite à la grille de permissions, pas à ce protocole de test.
Les arrêts font partie du comportement attendu
Un refus, une demande de précision ou une attente de validation ne sont pas des résultats incomplets lorsqu'ils sont prévus par le contrat. Ils rendent les limites du système compréhensibles et observables.
Avant d'ajouter un nouvel usage, je veux pouvoir répondre simplement à quatre questions :
- Que doit réussir l'agent ?
- Dans quels cas doit-il demander une décision ?
- Que doit-il refuser ?
- Quelle trace permet de le vérifier ?
Si ces réponses ne sont pas testables, la permission reste une intention. Si elles le sont, le premier usage peut entrer dans le quotidien avec un périmètre connu, puis évoluer à partir de comportements observés plutôt que d'une démonstration réussie une fois.
Pour définir ce périmètre avant les essais, voir la grille consacrée aux permissions d'un agent IA. Pour comprendre comment ces tests s'insèrent dans l'ensemble, l'article Système IA personnel : définition, fonctionnement et premiers usages présente le rôle de la mémoire, des permissions, de la validation humaine et de la reprise.