Pour tester un agent IA avant sa mise en production, partez de cas métier réels, y compris ceux où il faut s'arrêter. Chaque test précise le résultat attendu, les actions autorisées et la gravité d'une erreur. Comparez ensuite la réponse de l'agent aux changements effectués dans vos outils. Ces vérifications permettent d'appliquer une règle de lancement définie avant les essais.
Pourquoi une démonstration réussie ne suffit-elle pas ?
Une démonstration montre qu'un agent réussit un exemple choisi. Elle laisse ouvertes d'autres questions : comment réagit-il à une donnée manquante, une consigne contradictoire ou une panne ? Et respecte-t-il ses permissions lorsque la demande change ?
Un agent peut annoncer qu'il a créé une fiche dans votre CRM, le logiciel qui centralise vos contacts commerciaux, alors que l'opération a échoué. Le test consiste à retrouver cette fiche, vérifier ses champs et s'assurer qu'aucun autre dossier n'a changé. Une réponse convaincante peut masquer une action incorrecte.
Le NIST AI Risk Management Framework recommande des tests avant le déploiement, puis régulièrement en exploitation, dans des conditions proches de l'usage réel. Il demande de documenter les cas testés, les mesures et les conditions des essais. Ce cadre volontaire laisse à l'entreprise le choix des seuils, selon les conséquences d'une erreur.
Quels cas faut-il réunir pour tester un agent IA ?
Le jeu de test rassemble des exemples récents du travail de l'équipe, avec les cas où l'agent doit demander une vérification ou s'arrêter. Ces scénarios servent à construire des evals : des tests structurés qui évaluent le comportement de l'agent selon des critères définis. Anthropic décrit cette approche pour évaluer les réponses, les actions et les résultats des agents.
Les evals couvrent plusieurs familles de cas :
- les demandes courantes qui représentent le cœur du périmètre ;
- les variantes de format, de vocabulaire ou de source réellement observées ;
- les informations manquantes, anciennes ou contradictoires ;
- les exclusions et les demandes hors périmètre ;
- les erreurs rencontrées pendant le prototype ;
- les actions interdites ou soumises à validation ;
- les pannes d'un outil, d'une API ou d'une source nécessaire.
Une fiche commune précise ce qui compte pour chaque cas. Le responsable métier et la personne qui construit l'agent peuvent ainsi comparer leurs conclusions.
| Scénario | Résultat attendu | Preuve à contrôler | Gravité d'une erreur |
|---|---|---|---|
| Cas courant | Résultat complet dans le format prévu | Contenu et enregistrement créés au bon endroit | Gênante si une correction simple suffit |
| Information manquante | Signalement explicite ou passage en revue | Aucun champ inventé, dossier visible dans la file prévue | Critique si l'agent fabrique une donnée qui déclenche une action |
| Demande hors périmètre | Refus ou transfert à la personne désignée | Aucun outil non autorisé appelé | Selon les données et l'action possibles |
| Instruction hostile dans une source | Instruction ignorée, traitement arrêté si nécessaire | Objectif, permissions et données inchangés | Critique si des données sortent ou si une action interdite part |
| Panne d'un outil | Échec signalé et reprise prévue | Pas de doublon ni d'état partiellement validé | Selon la réversibilité de l'opération |
Le nombre de cas dépend du travail confié à l'agent. Une tâche stable demande moins de variantes qu'un processus qui combine plusieurs sources et outils. Chaque comportement inattendu ou conséquence encore non couverte justifie d'ajouter un cas au jeu de test.
Que faut-il mesurer pendant le test ?
Les mesures indiquent si le travail de l'agent est correct, vérifiable et acceptable pour l'usage prévu. Un message envoyé sans accord ou une donnée confidentielle exposée reste une erreur critique, même avec un bon score moyen.
Les mesures utiles dépendent de la tâche :
- la proportion de résultats acceptés, corrigés, rejetés ou transférés à une personne ;
- les informations exactes, manquantes et inventées ;
- le respect des exclusions et des actions interdites ;
- l'exactitude des créations, modifications ou envois dans les outils ;
- le temps nécessaire pour vérifier et corriger un résultat ;
- les doublons, échecs partiels et reprises après une panne ;
- le coût et le délai d'une exécution lorsqu'ils influencent l'usage réel.
Un taux précise quels cas ont été testés et sur quelle période. Exemple illustratif : « 18 cas acceptés sur 20 scénarios de qualification relus par la responsable commerciale ». « 90 % de réussite » seul ne dit rien des deux échecs ni de leur gravité.
La CNIL recommande de partir d'un besoin concret, d'encadrer les usages et de rendre les limites explicites. Elle demande aussi d'organiser les responsabilités autour du déploiement. La grille de test traduit ces choix en critères que l'équipe peut vérifier à chaque essai.
Comment vérifier les actions réellement exécutées ?
Pour vérifier les actions de l'agent, comparez l'état des outils avant et après chaque essai important, avec une trace reliant les changements au scénario. Une sandbox permet de l'exécuter dans un environnement isolé, avec des limites sur les fichiers, outils et connexions accessibles. L'explication du sandboxing par Anthropic détaille ces restrictions : réduire quelques permissions ne suffit pas à isoler tout un environnement.
Du cas métier à la décision de lancement
- Cas métierUn exemple réel définit le travail attendu.
- Exécution isoléeL’agent agit avec des droits et un périmètre réduits.
- RésultatL’équipe compare le contenu aux critères métier.
- ActionElle vérifie l’état réel des outils et des données.
- DécisionLa règle fixée avant le test autorise ou bloque le lancement.
- Nouveaux casLes erreurs qui affectent le travail deviennent de nouveaux cas.
Le contrôle suit six étapes :
- Exécutez le cas dans une sandbox ou, à défaut, avec des droits réduits adaptés au test.
- Comparez le résultat au contenu attendu et aux critères métier.
- Vérifiez les outils appelés, les données lues et les permissions utilisées.
- Contrôlez l'enregistrement, le message, le fichier ou le statut réellement créé.
- Recherchez les changements non demandés, les doublons et les états incomplets.
- Ajoutez toute erreur qui affecte le travail au jeu de test avant d'essayer une nouvelle version.
L'OWASP Top 10 for Agentic Applications 2026 décrit comment un agent peut être détourné de son objectif, mal utiliser ses outils ou abuser de ses permissions. Les essais incluent donc une instruction hostile dans une source, un outil indisponible, un accès insuffisant et une action hors périmètre. Ces scénarios complètent les tests métier ; un contrôle de sécurité adapté au système reste nécessaire.
Que montre le cas du négociant en vins ?
Le cas du négociant en vins montre l'importance de tester l'agent avec les critères du client. Celui-ci recherchait des cavistes et des grossistes, vérifiait leur correspondance à ses critères et enregistrait les résultats dans son CRM.
J'ai d'abord précisé les sources à consulter, les entreprises à exclure et les informations à conserver. J'ai ensuite construit l'agent qui mène la recherche et prépare une liste qualifiée dans le CRM. Plusieurs essais ont été nécessaires pour ajuster la qualification aux critères du client. Il garde le choix des entreprises à contacter.
Ce cas documente plusieurs ajustements, sans taux de précision ni nombre de scénarios. La première version a donc eu besoin de corrections pour suivre la méthode du client. Lors des essais, les désaccords servent à préciser les critères ; les cas déjà examinés permettent ensuite de vérifier les corrections.
Pour tester un agent comparable, la fiche relie la décision attendue au critère du client et à sa source. Elle signale les informations absentes et décrit le résultat attendu dans le CRM. L'envoi d'un message demande une décision et des contrôles distincts.
Quelle règle utiliser avant la mise en production ?
La règle de lancement fixe à l'avance les erreurs qui bloquent la production et celles acceptables pendant une phase encadrée. Elle précise aussi qui autorise le lancement.
Préparez cette décision en six points :
- Listez les cas critiques qui exigent tous le comportement attendu.
- Fixez les seuils utiles pour les autres catégories et la manière de les calculer.
- Définissez qui relit les résultats ambigus et qui accepte le risque restant.
- Prévoyez la reprise manuelle, l'arrêt et le retour à la version précédente.
- Lancez sur un volume et des permissions limités avant d'élargir.
- Surveillez les erreurs réelles et ajoutez-les au jeu de test à chaque modification.
Une erreur sur une action irréversible peut bloquer le lancement malgré un bon score global. Une différence de formulation sans effet sur le travail ne justifie pas forcément le même refus. Pour interpréter le score, regardez quelles erreurs l'agent commet, si l'équipe peut les repérer et si elle peut les corriger.
Après le lancement, les tests de non-régression vérifient qu'une modification ne casse pas un comportement déjà validé. Une nouvelle source, un modèle différent, une instruction modifiée ou un autre outil peut changer les résultats de l'agent. Rejouer les evals concernées permet de repérer ces changements ; l'équipe garde aussi une procédure de retour à la version précédente.
Quand différer la mise en production
Le lancement attend si l'équipe ne sait pas décrire le résultat attendu, repérer une erreur importante ou reprendre la tâche manuellement. Des droits trop larges, des actions sans trace ou l'absence de responsable de l'arrêt sont aussi des motifs de report. Dans ces situations, limitez d'abord l'agent à la préparation du travail ou à une action réversible.
Ce qu'il faut retenir
- Les evals couvrent le travail réel de l'équipe, les exceptions et les actions interdites.
- Chaque scénario précise le résultat attendu, la preuve à vérifier et la gravité d'une erreur.
- Le contrôle porte sur la réponse de l'agent et les changements effectués dans les outils.
- La règle de lancement fixe les erreurs bloquantes, la reprise et le responsable avant les essais.
- Les tests de non-régression sont rejoués après chaque changement important et enrichis avec les erreurs rencontrées.
Pour préparer les tests de votre prototype ou de votre automatisation avec IA, apportez quelques cas réels, le résultat attendu et l'action à exécuter. Nous pouvons cadrer ce premier test pendant un échange gratuit de 30 minutes.
Questions fréquentes
Le nombre de cas dépend des tâches et des risques de l'agent. Le jeu couvre le travail courant, les variantes, les exclusions, les données manquantes, les pannes et les actions critiques. Il s'enrichit dès qu'un essai ou l'usage réel révèle une nouvelle catégorie d'erreur.
Oui, un modèle peut noter des critères de forme ou aider à trier de nombreux résultats, à condition de comparer ses notes à une revue humaine. Les champs, les permissions et les actions demandent aussi des contrôles exacts. Le modèle évaluateur ne voit pas forcément ce qui a changé dans le CRM ou l'outil appelé.
Des cas réels sont utiles s'ils représentent le travail attendu, après retrait des données personnelles ou confidentielles inutiles au test. Un environnement isolé, avec des accès limités, permet de les rejouer sans agir directement sur les systèmes de production.
Réussir les tests n'autorise pas automatiquement un agent à agir seul. Le besoin de validation dépend de ses droits, des conséquences d'une erreur et de la capacité de l'équipe à la repérer et la corriger. Une action externe, sensible ou difficile à annuler peut rester soumise à un accord humain.
Écrit par Antoine mazu. Antoine aide les petites entreprises de services à comprendre et améliorer leurs processus grâce à des solutions adaptées, avec ou sans IA. Basé à Bayonne, il associe réflexion produit et réalisation technique.
Sources : NIST AI RMF Core, CNIL sur le déploiement d'une IA générative, OWASP Top 10 for Agentic Applications 2026, réalisations d'Antoine mazu, evals pour les agents et sandboxing d'Anthropic. Pages relues le 15 septembre 2026.
