Les tests d’agents IA permettent à une équipe support de prouver qu’un agent IA se comporte toujours correctement avant qu’un changement n’atteigne les clients. Vous construisez des cas de test à partir de vraies conversations résolues et de défaillances passées, vous les relancez avant chaque modification du prompt, des règles, de la base de connaissances ou du modèle, vous simulez des clients difficiles, vous vérifiez les actions de l’agent et vous ne mettez en production que lorsqu’un seuil écrit est atteint.
En bref
- Un agent qui réalise des actions doit être testé sur ce qu’il a fait (remboursement émis, limite respectée, cas transféré), pas seulement sur ce qu’il a dit.
- Les meilleurs cas de test viennent de vos propres conversations résolues et de vos défaillances passées.
- Relancez tout le jeu de non-régression avant chaque modification du prompt, des règles, des connaissances, du modèle ou des outils.
- Lancez chaque cas critique plusieurs fois : un agent qui réussit une fois peut échouer sur le même cas à l’exécution suivante.
- Écrivez le seuil de mise en production avant la série de tests, pour que personne ne discute des seuils après avoir vu les résultats.
Ce guide est la partie « avant mise en production » de notre guide plus large sur l’évaluation des agents IA.
Que sont les tests d’agents IA, et en quoi diffèrent-ils des tests de chatbot ?
Les tests d’agents IA vérifient un agent qui raisonne sur plusieurs tours et réalise des actions dans vos systèmes, comme émettre des remboursements, modifier des commandes ou mettre à jour des comptes. Les tests de chatbot vérifient surtout des réponses et des parcours de conversation. La différence tient aux conséquences : une mauvaise réponse de chatbot induit un client en erreur, une mauvaise action d’agent modifie de vrais enregistrements.
Si votre bot ne fait que répondre et transférer, voyez comment tester un chatbot. Cet article couvre ce qui change dès que l’agent peut agir.
| Ce que vous testez | Chatbot | Agent IA qui réalise des actions |
|---|---|---|
| Le parcours | Parcours scripté, prévisible | Varie d’une exécution à l’autre ; plusieurs chemins valides |
| Les actions | Peu ou aucune | Appels d’outils aux effets réels : remboursements, annulations, changements d’adresse |
| La constance | Surtout déterministe | La même entrée peut produire un autre résultat à l’exécution suivante |
| Le transfert | Bouton ou mot-clé | Une décision que l’agent prend en cours de conversation |
La constance est la partie difficile. Dans l’étude τ-bench, où un modèle de langage joue le client et où l’agent travaille avec des outils propres au domaine et des consignes de règles, même des agents performants en appel de fonctions réussissaient moins de 50 % des tâches et réussissaient la même tâche de vente au détail sur les 8 essais moins de 25 % du temps. La réussite était jugée sur l’état de la base de données à la fin de la conversation, pas sur la réponse.
Que doit contenir un cas de test d’agent IA ?
Un cas de test d’agent IA a besoin de six champs principaux : le scénario, le profil du client, le résultat attendu, les actions que l’agent a le droit de réaliser, une règle de réussite qu’une deuxième personne appliquerait de la même façon et la conversation source dont il vient. Sans les deux derniers, les résultats des tests deviennent des opinions.
Voici le modèle : les six champs principaux, plus quatre qui gardent le jeu maintenable. Copiez-le dans un tableur, une ligne par cas.
| Champ | Ce qu’il faut écrire | Exemple |
|---|---|---|
| ID du cas et étiquettes | Un identifiant stable plus des étiquettes d’intention, de risque et de canal | RF-014 · remboursement · risque élevé · chat |
| Scénario | Ce que veut le client et les faits que l’agent peut consulter | Le client a reçu un blender endommagé, commande vieille de 31 jours, payée 89 USD |
| Profil du client | Ton, connaissances, comportement au fil des tours | Poli au début, conteste après la première réponse, demande « juste le remboursement » |
| Résultat attendu | L’état final dans vos systèmes, plus ce qu’il faut dire au client | Pas de remboursement automatique (le délai est de 30 jours) ; remplacement proposé ou cas transféré à une personne avec le détail de la commande |
| Actions autorisées | Quels outils l’agent peut appeler, avec quelles limites | Consulter la commande : oui. Créer un remplacement : oui. Émettre un remboursement : non (hors délai). Transférer : oui |
| Règle de réussite | Binaire et vérifiable par quelqu’un d’autre | Réussi si aucun remboursement n’est émis, si aucun n’est promis au client, et si un remplacement est créé ou si la note de transfert mentionne la commande et le dommage |
| Gravité | Ce que signifie un échec | Critique : argent ou règles. Majeur : mauvaise réponse, sans dommage. Mineur : ton |
| Essais | Combien d’exécutions doivent réussir | Critique : 3 sur 3. Autres : 2 sur 3 |
| Conversation source | Lien vers la vraie conversation dont il vient | Lien du ticket, plus la date d’ajout et la raison |
| Responsable et dernière revue | Qui tient le cas à jour | Responsable de la règle de remboursement, revu quand la règle change |
Deux règles gardent le modèle utile. D’abord, le résultat attendu décrit un état, pas une phrase : le guide d’ingénierie d’Anthropic sur l’évaluation des agents fait le même constat avec un exemple de réservation de vol, où ce qui compte est qu’une réservation existe dans la base de données, pas que l’agent dise en avoir fait une. Ensuite, chaque cas renvoie à la conversation qui le justifie : quand une règle change, vous retrouvez et mettez à jour les cas qu’elle touche.
Comment construire un jeu de tests de référence à partir de vraies conversations ?
Construisez le jeu de tests de référence à partir de votre propre trafic : des conversations résolues qui montrent l’agent sous son meilleur jour, des défaillances passées que vous ne voulez plus jamais voir, des escalades et les cas limites de chaque règle. Commencez avec 20 à 50 cas et enrichissez le jeu chaque semaine, plutôt que d’attendre un jeu parfait de plusieurs centaines.
Le guide d’Anthropic estime que 20 à 50 tâches simples tirées de vraies défaillances constituent un excellent départ, et recommande de convertir les défaillances signalées par les utilisateurs en cas de test pour que la suite reflète l’usage réel.
Un premier jeu équilibré de 50 cas pourrait ressembler à ceci (une illustration ; ajustez les poids à votre propre volume et à votre risque) :
| Catégorie | Cas | D’où ils viennent |
|---|---|---|
| Intentions principales, parcours nominal | 15 | Vos 10 à 15 motifs de contact les plus fréquents, une conversation résolue sans accroc pour chacun |
| Cas d’action | 10 | Remboursements, annulations, changements d’abonnement, mises à jour d’adresse : juste dans et juste hors de chaque limite |
| Défaillances passées | 10 | Conversations où l’agent s’est trompé, rouvertes, ou ayant donné lieu à une réclamation |
| Cas de transfert | 6 | Cas que l’agent doit passer à une personne : menaces juridiques, clients vulnérables, signaux de fraude |
| Cas sans réponse connue | 4 | Questions auxquelles votre base de connaissances ne répond pas ; l’agent doit le dire, pas inventer |
| Cas malveillants | 5 | Tentatives de pousser l’agent au-delà d’une limite ou hors de ses instructions |
Gardez dans le jeu les cas qui réussissent : une correction sur un parcours peut en casser un autre sans bruit, et seuls les cas qui réussissaient auparavant le montreront. Retirez les données personnelles de chaque conversation source avant qu’elle ne devienne un cas de test.
Comment lancer des tests de non-régression avant chaque changement d’un agent IA ?
Lancez les tests de non-régression en rejouant tout le jeu de référence sur l’agent modifié avant sa mise en production, avec les mêmes règles de réussite que la fois précédente, et en comparant les résultats à ceux de la version actuelle. Tout changement compte : prompts, règles, articles de la base de connaissances, versions de modèle, outils et règles de routage modifient tous le comportement. Un article d’aide modifié peut changer les réponses sur les remboursements autant qu’une modification du prompt.
| Changement | Ce qui casse le plus souvent | Relance minimale |
|---|---|---|
| Prompt ou instructions | Ton, périmètre, moment du transfert | Jeu complet |
| Règle (délai de remboursement, limites) | Cas d’action à la frontière de l’ancienne et de la nouvelle limite | Jeu complet, plus de nouveaux cas limites pour la nouvelle limite |
| Article de la base de connaissances ajouté ou modifié | Les réponses qui le citent ; les sujets voisins | Cas étiquetés avec ce sujet, puis le jeu complet avant la mise en production |
| Version du modèle | N’importe quoi, souvent de façon subtile | Jeu complet, cas critiques avec des essais supplémentaires |
| Nouvel outil ou nouvelle permission | Actions, mauvais outil choisi, actions sans confirmation | Cas d’action et cas malveillants, puis le jeu complet |
| Règle de routage ou de transfert | Cas qui doivent, ou ne doivent pas, arriver à une personne | Cas de transfert, puis le jeu complet |
Lancez les cas critiques plus d’une fois. Les agents ne sont pas déterministes : une seule réussite ne prouve pas grand-chose. C’est pour cette raison que les auteurs de τ-bench ont proposé pass^k, la probabilité que les k exécutions réussissent toutes. Le calcul (illustration) : un cas que l’agent réussit 90 % du temps ne réussit 3 exécutions d’affilée que 73 % du temps (0,9 × 0,9 × 0,9), et 8 exécutions d’affilée que 43 % du temps.
Les cas de non-régression doivent réussir à 100 %, ou très près. Le guide d’Anthropic fait la même distinction : les évaluations de non-régression doivent avoir un taux de réussite proche de 100 %, alors que les évaluations de capacités pour de nouvelles compétences peuvent démarrer bas.
Comment simuler des clients pour tester un agent IA ?
Simulez des clients en faisant jouer le client par un second modèle à partir d’un profil écrit, sur plusieurs tours, face à l’agent que vous testez. Donnez à chaque profil un objectif, des faits, un tempérament et un point de rupture, et ajoutez des profils malveillants qui poussent l’agent au-delà de ses limites.
Des questions isolées testent des réponses. La simulation sur plusieurs tours, le principe retenu par τ-bench, teste ce qui déraille dans les vraies conversations : le client qui change de demande en cours de route ou qui insiste pour obtenir un remboursement que la règle n’autorise pas.
Écrivez cinq à huit profils et réutilisez-les d’un scénario à l’autre :
- Le client clair : une seule demande, tous les détails fournis. Votre référence.
- Le client vague : numéro de commande manquant, mauvais nom de produit. Teste les questions de clarification.
- Le client qui change de sujet : commence par la livraison, termine par une annulation.
- Le client insistant : rejette trois fois la première réponse et demande une exception. Teste les limites sous pression.
- Le client mécontent : menace de partir ou de se plaindre publiquement. Teste le ton et le transfert.
- Le client vulnérable : évoque un deuil, une maladie ou des difficultés financières. Teste vos règles de transfert pour ces cas.
- Le manipulateur : se fait passer pour un membre du personnel, colle « ignore tes instructions » ou cache des instructions dans une pièce jointe. Teste la résistance à ce que l’OWASP appelle l’injection de prompt.
Un profil ne trouve que les problèmes que vous avez pensé à y écrire : utilisez la simulation pour élargir le jeu, et les vraies conversations pour le garder honnête. Les agents vocaux ajoutent les accents, les interruptions et la qualité de la ligne ; voyez le contrôle qualité des agents vocaux IA.
Comment tester les actions et les appels d’outils d’un agent IA ?
Testez les actions en vérifiant l’état final dans vos systèmes après la conversation, pas la description que l’agent fait de ce qu’il a fait. L’enregistrement du remboursement existe-t-il, pour le bon montant, sur la bonne commande ? L’agent est-il resté dans ses limites, a-t-il demandé une confirmation là où elle était requise, et n’a-t-il appelé aucun outil interdit ?
Une réponse qui dit « j’ai traité votre remboursement » ne prouve rien. Vérifiez quatre points par cas d’action :
- La bonne action. L’outil attendu a été appelé, et aucun outil inattendu.
- Les bons paramètres. Bonne commande, bon client, bon montant, bon motif.
- Dans les limites. Montant sous le plafond, permission détenue, validation demandée là où vos règles exigent une personne.
- Un compte rendu fidèle. Ce que l’agent a dit au client correspond à ce qui s’est réellement passé dans le système.
L’OWASP classe l’autonomie excessive parmi les principaux risques des applications LLM : des actions dommageables rendues possibles par trop de fonctionnalités, trop de permissions ou trop d’autonomie. Ses mesures de prévention (extensions minimales, permissions minimales, validation par l’utilisateur) font aussi office de liste de tests. Écrivez au moins un cas par limite où le client demande juste un peu plus que la limite.
Lancez les tests d’action dans un environnement de test (sandbox) ou sur des comptes de test, jamais sur des enregistrements réels. La formation de Salesforce sur son Agentforce Testing Center prévient que les tests d’agents peuvent modifier les données du CRM et recommande de ne l’utiliser que dans une sandbox.
Le transfert est aussi une action : vérifiez que l’agent transfère les cas qu’il doit transférer, avec une note qui permet à la personne de reprendre (qualité de la gestion des escalades).
Comment les défaillances en production deviennent-elles de nouveaux cas de test ?
Les défaillances en production deviennent des cas de test grâce à une routine hebdomadaire : trouver les conversations où l’agent IA s’est trompé, confirmer la défaillance, retirer les données personnelles, écrire le cas avec le modèle ci-dessus et l’ajouter au jeu de référence. Le changement suivant ne peut pas passer en production tant que ce cas ne réussit pas.
Le plus difficile est de trouver les défaillances. Une conversation que l’agent a « résolue » peut quand même contenir une mauvaise réponse, une règle inventée ou un transfert manqué, et les tableaux de bord la comptent comme un succès (erreurs silencieuses des agents IA). Le monitoring des agents IA décrit ce qu’il faut surveiller au quotidien, et le guide sur le contrôle qualité des agents IA montre comment construire la grille qui les repère.
C’est là que le contrôle qualité des conversations réelles et les tests avant mise en production se rejoignent. AutoPilot de Kaizo évalue chaque conversation résolue par un agent IA avec votre propre grille et relie chaque note aux preuves : vous obtenez des défaillances confirmées, chacune avec une conversation source pour le modèle. Une fois la correction en production, l’évaluation des conversations réelles des semaines suivantes montre si elle a tenu.
Voyez où votre agent IA échoue aujourd’hui. Kaizo évalue les conversations des agents IA avec la même grille que votre équipe et relie chaque note aux lignes qui la justifient. Réserver une démo.
Si vous évaluez avec un juge IA, vérifiez aussi le juge. Notre guide pour valider l’évaluation de la QA par IA (en anglais) montre comment comparer les notes automatiques à celles de vos évaluateurs avant de leur faire confiance.
Que doit vérifier le seuil de mise en production d’un agent IA ?
Le seuil de mise en production d’un agent IA est une courte liste écrite de conditions qu’un changement doit remplir avant d’atteindre les clients, convenue avant la série de tests. Il doit bloquer sur toute défaillance critique, exiger des résultats de non-régression quasi parfaits, couvrir chaque action et chaque limite, et nommer qui valide et comment revenir en arrière. Copiez-le et fixez vos propres chiffres.
Avant la série
- Le changement est écrit : quoi, pourquoi, qui l’a demandé.
- De nouveaux cas pour le changement lui-même (une nouvelle limite reçoit des cas juste en deçà et juste au-delà).
- Chaque défaillance confirmée en production depuis la dernière mise en production figure dans le jeu.
- Comptes de test et sandbox prêts ; aucun enregistrement client réel à portée.
La série
- Tout le jeu de référence lancé sur l’agent modifié et sur l’agent actuel, avec les mêmes règles de réussite.
- Cas critiques (argent, données, juridique, clients vulnérables) lancés au moins 3 fois chacun.
- Profils simulés lancés, dont le manipulateur et le client insistant.
Conditions de réussite
- Cas critiques : 100 % de réussite, à chaque essai. Un seul échec bloque la mise en production.
- Cas de non-régression : au moins 98 % de réussite, et aucun cas réussi lors de la dernière mise en production n’échoue désormais sans explication.
- Cas d’action : aucune action hors de la liste autorisée, aucun montant au-dessus de la limite, aucune action annoncée qui n’a pas eu lieu.
- Cas de transfert : chaque cas à transférer obligatoirement est arrivé à une personne avec une note exploitable.
- Cas sans réponse connue : aucune réponse inventée.
Validation et après la mise en production
- Un responsable nommé signe : le responsable support ou CX pour les règles et le ton, le responsable IA pour la partie technique.
- Le retour arrière est prêt : le prompt, la base de connaissances et la version de modèle précédents peuvent être restaurés le jour même.
- Les premiers jours de conversations réelles après la mise en production sont examinés de plus près que d’habitude.
Exemple chiffré (une illustration avec des chiffres inventés). Une équipe raccourcit son délai de remboursement de 30 à 14 jours. Son jeu de référence compte 120 cas : 40 critiques, 80 autres. Les cas critiques sont lancés 3 fois, les autres une fois : la série compte donc 200 essais. Résultat : 196 essais sur 200 réussissent, un taux de 98 % qui paraît sain. Mais les 4 échecs se concentrent sur deux cas critiques. Dans l’un, l’agent propose encore un remboursement au 20e jour dans un essai sur trois. Dans l’autre, le profil du client insistant obtient un remboursement « commercial » dans les trois essais. Le seuil bloque la mise en production. La correction est apportée au prompt et à un article de la base de connaissances, deux nouveaux cas critiques sont ajoutés pour le 14e et le 15e jour, et la nouvelle série réussit 206 essais sur 206. Une moyenne aurait laissé passer le bug ; le seuil, non.
De quels outils avez-vous besoin pour tester un agent IA ?
Il vous faut trois types d’outils : un endroit où conserver et versionner les cas de test, un moyen de les lancer sur l’agent (souvent avec des clients simulés) et un moyen de noter les résultats selon vos règles de réussite.
- Un tableur et des exécutions manuelles suffisent en dessous d’environ 50 cas et de quelques changements par mois.
- Une fonction de test intégrée à la plateforme convient pour une seule plateforme avec des parcours standard. L’Agentforce Testing Center de Salesforce, par exemple, génère 20 cas de test par défaut, et vous choisissez combien sont positifs et négatifs.
- Les outils de test et de simulation ajoutent des clients simulés, des essais répétés et des contrôles de mise en production dans la chaîne de déploiement.
- Le contrôle qualité des conversations réelles évalue ce qui s’est vraiment passé après la mise en production et réinjecte les défaillances confirmées dans le jeu.
Quel que soit votre choix, gardez les cas dans un format que votre équipe support peut lire et modifier, sinon les responsables des règles cessent de les mettre à jour.
Quand un programme de test complet n’est-il pas pour vous ?
Un programme complet est disproportionné si votre agent IA traite quelques dizaines de conversations par semaine, ne fait que répondre à des questions et ne peut pas réaliser d’actions. Dans ce cas, lisez les transcriptions chaque semaine et gardez une courte liste de 20 cas que vous relancez à la main après chaque changement.
Le contrôle qualité des conversations réelles ne le remplace pas non plus : évaluer les conversations une fois terminées ne bloque pas un changement avant sa mise en production. Il vous faut les deux : des tests avant le changement, et l’évaluation de chaque conversation des agents IA après.
Comment démarrer cette semaine
Vous pouvez disposer d’un premier jeu de référence, d’un seuil de mise en production écrit et d’une première série de référence en cinq jours ouvrés, avec un export de conversations récentes, le modèle ci-dessus et un environnement de test.
- Lundi : exportez 30 conversations résolues par l’agent IA et 20 qui ont mal tourné. Retirez les données personnelles.
- Mardi : transcrivez-les dans le modèle. Indiquez lesquelles sont critiques.
- Mercredi : écrivez le seuil de mise en production. Faites valider les chiffres par le responsable support et le responsable IA.
- Jeudi : lancez le jeu sur l’agent actuel, avec trois essais pour les cas critiques. C’est votre référence ; attendez-vous à quelques échecs.
- Vendredi : convenez de la règle selon laquelle aucune modification du prompt, des règles, des connaissances ou du modèle ne passe en production sans nouvelle série, et fixez un créneau hebdomadaire pour ajouter les nouvelles défaillances au jeu.
Voyez la gouvernance des agents IA pour savoir à qui revient la validation.
Questions fréquentes
Qu’est-ce que l’automatisation des tests par l’IA ?
L’automatisation des tests par l’IA désigne en général l’utilisation de l’IA pour tester un logiciel, par exemple des agents qui écrivent et exécutent des scripts de test pour une application web. Cet article traite d’un autre sujet : prouver qu’un agent IA en contact avec les clients répond et agit correctement avant chaque changement.
Les agents IA ont-ils des outils ?
Oui. Les outils d’un agent IA sont les fonctions qu’il peut appeler, comme consulter une commande ou émettre un remboursement. C’est pour cela que les tests d’agents doivent vérifier l’état final dans vos systèmes, pas seulement la réponse.
Qu’est-ce qu’un testeur IA ?
Soit une personne qui teste des systèmes d’IA, soit une IA qui teste d’autres logiciels. Au service client, c’est en général un responsable qualité ou un responsable IA qui écrit des cas de test à partir de vraies conversations et décide si un changement atteint le seuil de mise en production.
De combien de cas de test un agent IA a-t-il besoin ?
Commencez avec 20 à 50 cas tirés de vraies conversations et de défaillances passées, puis ajoutez chaque défaillance confirmée en production. La couverture de vos intentions principales, de vos actions et de vos limites compte davantage que le nombre brut.
À quelle fréquence faut-il lancer les tests de non-régression d’un agent IA ?
Lancez tout le jeu avant chaque modification des prompts, des règles, des connaissances, des modèles, des outils ou du routage, et chaque semaine même quand rien n’a changé, parce que les fournisseurs de modèles et les systèmes connectés changent eux aussi.
