Tester un agent IA : par où commencer ?
Un agent IA ne répond jamais deux fois exactement pareil. Voici comment construire une première stratégie de test qui tient la route : jeux de scénarios, critères d'évaluation, garde-fous et non-régression.
Tester un agent IA, c’est accepter de perdre le confort du expect(result).toBe(42). La même question peut donner deux réponses différentes, toutes les deux justes, ou une juste et une fausse. Le métier de QA ne disparaît pas pour autant : il change d’outils et de critères.
Voici la démarche que j’applique quand je démarre les tests d’un agent ou d’un assistant IA.
1. Écrire ce que l’agent doit faire, et ce qu’il ne doit jamais faire
Avant le moindre test, il faut un contrat. Pour un agent, il tient en deux listes :
- Les missions : les tâches qu’il doit réussir (répondre à une question produit, créer un ticket, résumer un document…).
- Les interdits : ce qu’il ne doit jamais faire (inventer un prix, divulguer une donnée personnelle, exécuter une action sans confirmation, sortir de son périmètre).
Les interdits sont souvent oubliés, alors que ce sont eux qui coûtent le plus cher en production.
2. Construire un jeu de scénarios, pas un jeu de données
Un bon jeu de test pour un agent ressemble à une liste de conversations réalistes, classées par famille :
- Le chemin nominal : la demande claire, bien formulée.
- Les reformulations : la même demande dite autrement, avec des fautes, en anglais, en abrégé.
- Les cas limites : demande ambiguë, information manquante, question hors sujet.
- Les tentatives de détournement : « ignore tes instructions », demande de données d’un autre utilisateur, injection cachée dans un document fourni.
Commencez petit : trente à cinquante scénarios bien choisis valent mieux que mille générés sans réfléchir.
3. Définir des critères d’évaluation mesurables
Puisqu’on ne peut pas comparer mot pour mot, on évalue des propriétés de la réponse :
| Critère | Question posée | Comment le vérifier |
|---|---|---|
| Exactitude | Les faits sont-ils justes ? | Comparaison avec une réponse de référence |
| Pertinence | Répond-elle à la question posée ? | Revue humaine ou LLM évaluateur |
| Respect du périmètre | Reste-t-elle dans son rôle ? | Règles et mots-clés interdits |
| Format | Le JSON, la longueur, la langue sont-ils bons ? | Assertions classiques |
| Action | Le bon outil a-t-il été appelé avec les bons paramètres ? | Traces de l’agent |
Les deux dernières lignes sont de bonnes nouvelles : une partie du test d’un agent reste parfaitement déterministe. Vérifiez d’abord tout ce qui peut l’être avec des assertions classiques.
4. Tester les actions, pas seulement le texte
Un agent ne fait pas que parler : il appelle des outils, des API, il écrit en base. C’est là que les tests ressemblent le plus à nos tests d’intégration habituels. Pour chaque scénario, on vérifie :
- quel outil a été appelé, et dans quel ordre ;
- avec quels paramètres ;
- ce qui se passe quand l’outil échoue (timeout, erreur 500, réponse vide).
Si votre agent expose ses traces (et il devrait), ces vérifications s’automatisent comme n’importe quel test d’API.
5. Répéter chaque scénario plusieurs fois
Un scénario qui passe une fois n’est pas un scénario qui passe. Je lance chaque cas plusieurs fois et je regarde le taux de réussite, pas un simple vert ou rouge. Un cas qui réussit 7 fois sur 10 est un vrai problème, même s’il était vert au premier lancement.
6. Brancher la non-régression dans la CI
Chaque changement de prompt, de modèle ou d’outil peut tout casser. Le jeu de scénarios devient donc une suite de non-régression :
- lancée à chaque modification du prompt ou de la configuration ;
- avec un seuil d’acceptation par famille de scénarios ;
- et un rapport qui montre ce qui a changé par rapport à la version précédente.
Pour aller plus loin
Le syllabus ISTQB AI Testing, que je prépare en ce moment, donne un cadre solide à tout ça : biais, explicabilité, tests de robustesse. J’y reviendrai dans de prochains articles, ainsi que sur l’évaluation par un LLM, qui mérite un article à elle seule.
