Tester un agent IA n’est ni du test logiciel ni du benchmark de modèle. Un agent suit un chemin qui change d’une exécution à l’autre : la seule mesure qui ait du sens est donc une distribution — même tâche, mêmes conditions, vingt exécutions, combien se terminent correctement. L’arithmétique est simple et brutale : un agent précis à 95 % à chaque étape ne termine correctement qu’environ 60 % des tâches à dix étapes. Un dispositif d’évaluation qui fonctionne comporte quatre volets : un jeu de cas issu du réel, une mesure à quatre niveaux, une campagne de régression à chaque changement et une surveillance en production.
Pourquoi le test logiciel classique ne fonctionne pas ici
Le test logiciel conventionnel suppose le déterminisme : la même entrée produit la même sortie, il suffit donc de couvrir les chemins. Chez un agent, cette hypothèse ne tient plus. La même entrée peut produire un chemin différent, un ordre d’outils différent et un résultat différent — non pas à cause d’un bug, mais du fait même du fonctionnement du modèle.
La question du test change donc de nature. Au lieu de réussi ou échoué, la question devient : à quelle fréquence réussit-il, et à quelle distance de la moyenne se situe le pire échec. Les équipes qui se brûlent sont celles qui ont vu une démonstration réussie, en ont conclu que le système fonctionnait, et ont découvert en production que la démonstration était la meilleure exécution sur cinq.
La métrique de réussite la plus souvent citée dans le secteur mesure une réussite unique dans des conditions optimales. En production, ce qui compte est la stabilité : même tâche, nombreuses exécutions. L’écart entre ces deux chiffres est l’écart entre une démonstration et un système.
L’arithmétique qui explique presque tout
Un agent exécute une tâche sous la forme d’une chaîne d’étapes. Si chaque étape est indépendante, le taux de réussite de la tâche est le produit des probabilités. Cela paraît trivial jusqu’au moment où l’on met des chiffres.
| Précision par étape | Tâche à 5 étapes | 10 étapes | 20 étapes |
|---|---|---|---|
| 90 % | 59 % | 35 % | 12 % |
| 95 % | 77 % | 60 % | 36 % |
| 98 % | 90 % | 82 % | 67 % |
| 99 % | 95 % | 90 % | 82 % |
Deux conclusions opérationnelles en découlent. Premièrement : raccourcir la tâche vaut plus que d’améliorer le modèle. Passer de vingt étapes à dix, à 95 % de précision, fait presque doubler le taux de réussite, de 36 % à 60 %. Deuxièmement : les chaînes longues exigent une précision par étape très difficile à atteindre ; les tâches longues réclament donc des points de contrôle et une validation en cours d’exécution plutôt qu’une boucle continue unique.
C’est aussi la raison pour laquelle des tâches exceptionnellement longues échouent encore la plupart du temps, même avec les meilleurs modèles disponibles. Découper le travail en sous-tâches assorties de validations intermédiaires n’est pas un compromis d’ingénierie : c’est la seule voie que les mathématiques autorisent.
Comment construire un jeu de cas qui vous apprend vraiment quelque chose
Un jeu de tests rédigé par la personne qui a construit l’agent échouera en production, parce qu’il reflète ce que le développeur a imaginé. Le bon jeu provient de trois sources.
| Type de cas | D’où il provient | Quelle proportion |
|---|---|---|
| Chemin nominal | Les vingt dernières demandes traitées manuellement | ~40 % du jeu |
| Cas limites réels | Réclamations, remboursements, cas ayant nécessité une escalade | ~40 % du jeu |
| Cas adverses | Tentatives d’injection, entrée manquante, contradictions, demandes hors périmètre | ~20 % du jeu |
Chaque cas a besoin d’une condition de réussite définie à l’avance. Non pas une note subjective, mais une condition vérifiable : le champ a été mis à jour avec la bonne valeur, l’e-mail est parti à la bonne adresse, le total correspond au calcul manuel, ou l’agent a refusé d’agir et a escaladé. Un cas sans condition de réussite n’est pas un cas de test, c’est une impression.
Une taille de départ raisonnable : 40 à 80 cas, chacun exécuté cinq à dix fois. Cela paraît beaucoup, mais cela représente quelques minutes d’exécution et quelques euros de coût — face à un seul client qui a reçu une mauvaise réponse.
Quatre niveaux de mesure
Mesurer uniquement le résultat masque la cause. Un dispositif utile mesure quatre niveaux en parallèle.
| Niveau | Ce qui est mesuré | Ce que cela révèle |
|---|---|---|
| Résultat | Si la condition de réussite a été remplie | Si le système franchit la barre métier |
| Chemin | L’ordre des outils choisis et le nombre d’étapes | Où l’agent commence à dériver, avant que le résultat ne casse |
| Outil | Taux d’appels avec un argument erroné ou un outil inadapté | Quelles descriptions d’outils doivent être corrigées |
| Coût | Jetons, appels et temps par tâche | Si la solution reste économique à l’échelle |
Le niveau chemin est le plus important pour le débogage. Une erreur d’agent se manifeste généralement loin de l’endroit où elle a été créée : sans journal complet de chaque appel et de chaque résultat, il est impossible de retrouver l’étape qui a amorcé la dérive. Le contexte structurel est expliqué dans Anatomie d’un agent IA d’entreprise.
Régression : ce qui casse un agent auquel vous n’avez pas touché
Un agent fait partie des rares systèmes capables de casser sans que personne n’ait modifié une ligne à l’intérieur. Il y a trois causes principales.
Mise à jour du modèle. Le fournisseur livre une nouvelle version et le comportement se déplace — généralement meilleur en moyenne et moins bon sur des cas précis qui avaient été calibrés pour la version précédente. Toute montée de version du modèle impose donc une exécution complète du jeu avant bascule.
Changement de schéma d’outil. Un champ ajouté, un nom modifié, une nouvelle valeur par défaut. L’agent ne plantera pas ; il continuera d’appeler l’outil de la manière qui était correcte hier.
Dérive des données. La forme des demandes entrantes évolue avec le temps, de nouveaux produits arrivent, la formulation des clients change. Un jeu de tests vieux d’un an teste un monde qui n’existe plus.
Une règle de travail simple : le jeu s’exécute automatiquement à chaque changement du prompt, des outils ou du modèle, et il est rafraîchi tous les trimestres à partir du trafic réel.
Surveillance en production — la seule chose qui mesure la vérité
Le jeu mesure ce que vous avez pensé à tester. La production mesure ce qui se passe. Quatre indicateurs suffisent à détecter à temps presque tous les problèmes.
- Taux d’achèvement. La part des tâches terminées sans intervention humaine et sans échec.
- Taux d’escalade. À quelle fréquence l’agent s’est arrêté pour demander un humain. Une hausse soudaine signale un changement dans les entrées ; une baisse soudaine signale un excès de confiance.
- Taux de correction. À quelle fréquence un humain a modifié ce que l’agent proposait. C’est l’indicateur le plus proche de la qualité réelle.
- Coût par tâche réussie. Pas le coût par appel. Les tâches qui échouent et sont relancées constituent le coût réel — le volet financier est détaillé dans le guide de réduction du coût d’inférence.
Le taux de correction est aussi le signe le plus clair de la justesse du point de validation. Si presque personne ne corrige quoi que ce soit, la validation est devenue un tampon automatique — un sujet traité dans le guide de la validation humaine.
Une checklist avant que l’agent ne touche un client
- Chaque cas du jeu possède une condition de réussite sans ambiguïté, écrite avant l’exécution.
- Chaque cas est exécuté au moins cinq fois, et l’indicateur rapporté est la stabilité plutôt que la meilleure exécution.
- Le jeu comprend des cas adverses, y compris des tentatives d’injection par chaque canal d’entrée — voir le guide des permissions.
- Un journal complet des appels d’outils et de leurs résultats existe pour chaque exécution, stocké et consultable.
- Une barre métier chiffrée pour la mise en production a été définie, plutôt qu’un sentiment de « c’est assez bon ».
- Un scénario de repli a été défini : que se passe-t-il quand l’agent échoue, et qui récupère la tâche.
Questions fréquentes
Que sont les évaluations (evals) d’un agent IA ?
Un dispositif de test qui mesure le comportement de l’agent sur un jeu de cas prédéfini, chaque cas sur plusieurs exécutions, et qui rapporte la distribution des résultats plutôt qu’une réussite isolée. Il couvre le résultat, le chemin, l’usage des outils et le coût.
De combien de cas de test a-t-on besoin ?
Un jeu de départ de 40 à 80 cas couvre l’essentiel du comportement d’un agent mono-tâche, à condition d’être réparti entre chemin nominal, cas limites réels et cas adverses. Plus important que le nombre de cas : le nombre d’exécutions par cas, qui doit être d’au moins cinq.
Pourquoi un agent qui fonctionnait en démonstration échoue-t-il en production ?
Parce que la démonstration mesurait une exécution dans des conditions confortables. En production, la tâche est plus longue, les entrées sont plus sales et les erreurs se composent d’étape en étape. Un agent précis à 95 % par étape ne termine correctement qu’environ 60 % des tâches à dix étapes.
Peut-on utiliser un modèle pour juger l’agent ?
Oui, mais uniquement comme couche complémentaire. Le jugement automatisé convient aux mesures qualitatives telles que le ton ou la complétude d’une réponse, pas aux conditions de réussite vérifiables de façon déterministe. Tout cas vérifiable par comparaison de valeurs doit être vérifié ainsi.
Quand exécute-t-on le jeu de tests ?
À chaque changement du prompt, des outils ou de la version du modèle, plus un rafraîchissement périodique du jeu à partir du trafic réel. Un agent peut casser même sans que personne n’y ait touché, principalement à la suite d’une mise à jour de modèle ou d’un changement de schéma d’outil.
À lire ensuite
Agents IA auto-hébergés : quand l’infrastructure interne se justifie – Les évaluations décident de la mise en production. L’endroit où l’agent s’exécute décide de ce que vous pourrez journaliser, mesurer et rejouer ensuite.