Définir le bon résultat, constituer un jeu de scénarios, tester plusieurs fois, mesurer simplement, inclure la sécurité : le test avant le go.
À retenir avant de commencer
Un agent se comporte différemment d’un logiciel classique : ses sorties varient d’un essai à l’autre, et une réponse qui semble bonne peut être une mauvaise action. Le tester correctement demande de vérifier le résultat, les conditions d’arrêt et la formulation.
La méthode tient en cinq étapes : définir ce qu’est une bonne réponse, constituer un jeu de scénarios, tester plusieurs fois, mesurer avec des critères simples, et inclure la sécurité dans la grille.
Avant de tester : définir ce qu’est une bonne réponse
Un test commence par une référence : qu’est-ce qu’une réponse réussie pour cette tâche ? LangSmith appelle cela définir « what good looks like » (ce à quoi ressemble le bon résultat) à partir de cas réels, avant de lancer le premier test. [45]
Concrètement : collecte dix à trente demandes réelles, note la réponse idéale pour chacune (ou au moins le résultat attendu : la bonne action, le bon refus, la bonne question), et tu obtiens ton jeu de référence.
La grille de passage
Un agent prêt pour la production doit passer une série de scénarios types. Clique sur chaque scénario pour le marquer comme vérifié.
Interaction-signature
La grille de passage
Un scénario qui échoue devient un point de correction documenté : le pilote avance.
- Demande nominale : la demande classique reçoit la bonne réponse.
- Demande ambiguë : l’agent demande une précision au lieu de deviner.
- Information manquante : l’agent s’arrête proprement au lieu d’inventer.
- Hors périmètre : une demande étrangère à la tâche est refusée poliment.
- Donnée sensible : l’agent refuse de divulguer une information protégée.
- Prompt injecté : une tentative de détournement (« ignore tes instructions ») est ignorée.
- Outil en panne : une erreur d’outil produit un message clair au lieu d’un faux succès.
- Action engageante : l’agent demande la validation au lieu d’exécuter.
- Demande en double : l’agent évite de rejouer la même action deux fois.
- Client mécontent : le ton reste adapté, sans promesse excessive.
Évaluer le résultat métier, au-delà de la formulation
Les modèles produisent des formulations variables : deux réponses correctes peuvent différer dans leurs mots. Anthropic recommande de grader le résultat (l’action, la décision, l’effet) plutôt que de comparer les phrases, et de lancer plusieurs essais par test pour obtenir des résultats cohérents, car les sorties varient d’un run à l’autre. [44]
En pratique : pour une relance, deux questions pour une relance : l’agent a-t-il choisi le bon dossier, préparé le bon message et demandé la validation ? La ressemblance du texte à un modèle vient après.
La trace comme matière de test
Chaque exécution d’agent laisse une trace : les appels, les outils utilisés, les décisions, les garde-fous déclenchés. OpenAI recommande d’utiliser ces traces comme matière de test : des évaluateurs structurés notent les traces avec des critères pour détecter les régressions et les modes de défaillance à l’échelle, et des jeux de données réutilisables permettent de comparer les versions. [43]
C’est le principe du test de régression : chaque nouvelle version doit être rejouée sur le même jeu de scénarios pour vérifier qu’elle ne casse rien. [45]
Les métriques simples
Les plateformes d’évaluation proposent des critères prêts à l’emploi. Microsoft liste des évaluateurs intégrés : cohérence, ancrage dans les sources (groundedness), exactitude des appels d’outils, achèvement de la tâche, sécurité. [46] Google mesure notamment le succès de la tâche et la sécurité, avec des comparaisons sur des réponses de référence. [47]
Pour une PME, trois critères suffisent au début : la tâche aboutit-elle ? L’agent a-t-il utilisé le bon outil ? La réponse est-elle ancrée dans les sources fournies ? Des outils comme DeepEval proposent d’ailleurs des métriques « LLM comme juge » avec un critère, une grille et un seuil : un moyen d’évaluer sans expertise technique lourde. [49]
Les tests de sécurité font partie de la grille
La sécurité fait partie de la grille dès la première ligne. L’OWASP documente les failles les plus courantes des applications à base de LLM, avec les tests associés [48] :
- l’injection de prompt (LLM01) : un utilisateur tente de détourner l’agent avec des instructions cachées ;
- la divulgation d’informations sensibles (LLM02) : les instructions système et données protégées restent hors de portée des questions indirectes ;
- les faiblesses d’indexation (LLM08) : les documents récupérés peuvent contenir des contenus malveillants.
Le scénario 6 de la grille (prompt injecté) et le scénario 5 (donnée sensible) couvrent l’essentiel pour un premier déploiement.
Le résumé utile
Définis d’abord « ce à quoi ressemble le bon résultat » : cas réels, résultats attendus.
Passe les dix scénarios types, y compris les échecs et les refus.
Évalue le résultat métier plusieurs fois : les sorties varient d’un essai à l’autre.
Rejoue le même jeu à chaque version (régression) et garde la sécurité dans la grille.
Une fois la grille passée, l’agent entre en production, et là il faut l’observer. C’est le prochain article de la série.