L’évaluation des agents IA est la façon dont une équipe support prouve que son agent IA donne des réponses correctes, autorisées et utiles. Elle comporte deux temps : les evals avant le lancement, où vous faites tourner des conversations de test selon des critères de réussite écrits, et l’évaluation en production, où vous évaluez les vraies conversations clients avec une grille. Il vous faut les deux, un juge calibré et un responsable nommé.
En bref
- Les evals avant lancement vous disent si une modification peut être mise en production sans risque ; l’évaluation en production vous dit ce que l’agent IA a réellement fait à vos clients.
- Mesurez la résolution correcte, le respect des règles, l’exactitude des actions, la qualité des escalades et le ton ; traitez le taux de contention comme du contexte, jamais comme la note qualité.
- Utilisez un juge LLM pour le volume et des évaluateurs humains pour le calibrage et les cas à haut risque, et vérifiez leur accord critère par critère.
- Les petits échantillons ratent les défaillances rares mais coûteuses : à 40 000 conversations par mois, un échantillon de 1 % a 45 % de chances de ne montrer aucun cas d’une défaillance qui touche 80 clients.
- Donnez à chaque indicateur un responsable, un seuil et une fréquence ; le tableau du cadre ci-dessous est un point de départ à copier.
Ce guide s’adresse au responsable support qui répond de l’agent une fois qu’il parle aux clients, pas aux ingénieurs qui le construisent. Pour les bases, lisez notre guide sur le contrôle qualité des agents IA ; si vous décidez encore jusqu’où automatiser, commencez par le service client agentique.
Qu’est-ce que l’évaluation des agents IA au service client ?
L’évaluation des agents IA au service client est le processus reproductible qui consiste à vérifier les conversations d’un agent IA selon des critères de réussite écrits : la réponse était-elle correcte, autorisée par les règles, l’action promise a-t-elle vraiment eu lieu, l’agent a-t-il passé la main quand il le fallait, et le ton était-il juste ? Elle s’applique avant le lancement sur des cas de test et après le lancement sur de vraies conversations.
Votre équipe IA utilisera ces termes issus des guides pour développeurs :
| Terme | Ce qu’il signifie | Exemple au support |
|---|---|---|
| Tâche ou cas de test | Un scénario avec des entrées et des critères de réussite définis | « Un client demande le remboursement d’une commande livrée il y a 40 jours » |
| Grader (évaluateur automatique) | La logique qui note un aspect du résultat | « L’agent a-t-il refusé le remboursement en vertu de la règle des 30 jours ? » |
| Transcription | L’enregistrement complet d’une exécution, y compris les actions de l’agent | Le chat, plus la requête à l’API de remboursement et sa réponse |
| Résultat | L’état final dans vos systèmes | Un remboursement est-il réellement enregistré dans le système de commandes ? |
La dernière ligne compte le plus pour le support. Une transcription où l’agent écrit « votre remboursement est en cours » n’équivaut pas à un remboursement dans le système. Les praticiens qui exploitent des agents de support décrivent exactement cette défaillance : l’agent annonce une action comme effectuée alors que l’appel d’API derrière a échoué.
Que retenir de « Demystifying evals for AI agents » d’Anthropic pour le support ?
L’article technique d’Anthropic Demystifying evals for AI agents (en anglais) est le guide que beaucoup cherchent par son nom. Pour les équipes support, il se résume à cinq points : commencer petit avec de vraies défaillances, vérifier les résultats et pas seulement les mots, mesurer la constance, tester les deux côtés de chaque décision et continuer à lire les transcriptions.
- Commencez avec 20 à 50 vraies défaillances. L’article qualifie 20 à 50 tâches simples tirées de vraies défaillances de « très bon début » et cite la file du support comme source. Votre équipe qualité les a déjà.
- Évaluez le résultat, pas le récit. L’exemple de remboursement de l’article combine un contrôle d’état (ticket résolu, remboursement traité), des contrôles sur les actions de l’agent (identité vérifiée, remboursement dans les limites) et une grille LLM pour l’empathie et la clarté.
- Mesurez la constance avec pass^k, la probabilité que les k exécutions d’une tâche réussissent toutes. L’article note que cela « compte particulièrement pour les agents en contact avec les clients, dont les utilisateurs attendent un comportement fiable à chaque fois ». Un agent qui réussit une tâche 75 % du temps réussit les 3 exécutions seulement environ 42 % du temps.
- Testez dans les deux sens. Vérifiez quand l’agent doit agir et quand il ne doit pas. Un jeu rempli de cas « doit rembourser » produit un agent qui rembourse trop souvent.
- Lisez les transcriptions. « Vous ne saurez pas si vos graders fonctionnent bien à moins de lire les transcriptions et les notes de nombreux essais. »
L’article qualifie aussi le monitoring en production de réactif : les clients rencontrent le problème avant vous. Les équipes support ont besoin des deux temps.
Evals avant lancement ou évaluation en production : quelle différence ?
Les evals avant lancement font tourner votre agent IA sur des conversations de test avant qu’une modification soit mise en ligne, pour bloquer un mauvais prompt, un mauvais modèle ou une mauvaise mise à jour des connaissances. L’évaluation en production note les vraies conversations des clients, pour trouver les défaillances que votre jeu de tests n’avait pas imaginées. Avant le lancement, c’est un filtre ; en production, c’est le contrôle qualité continu.
| Evals avant lancement | Évaluation en production | |
|---|---|---|
| Question à laquelle elle répond | Cette modification est-elle sûre ? | Qu’a fait l’agent à nos clients cette semaine ? |
| Entrée | Cas de test, clients simulés, conversations passées rejouées | Chaque vraie conversation traitée par l’agent IA |
| Quand elle tourne | Avant chaque modification de prompt, de modèle, d’outil ou de contenu | En continu, à mesure que les conversations sont résolues |
| Responsable habituel | Responsable IA ou automatisation | Responsable qualité, le responsable CX fixant les seuils |
| Point fort | Repère les régressions avant que les clients ne les voient | Repère ce que personne n’avait pensé à tester |
| Angle mort | Ne trouve que ce que contient le jeu de tests | Ne trouve les problèmes qu’une fois qu’ils sont arrivés |
| Pour approfondir | Tests d’agents IA et tester un chatbot | Monitoring des agents IA et le reste de cette page |
Les deux temps s’alimentent : chaque défaillance trouvée en production devient un nouveau cas de test. La simulation, où un second modèle joue le client, relève de l’avant-lancement ; des benchmarks comme τ-bench (en anglais) l’utilisent pour des tâches de support dans la distribution et le transport aérien.
Comment écrire des evals pour un agent IA ?
Pour écrire des evals pour un agent IA, rassemblez 20 à 50 vraies conversations où l’agent ou votre équipe s’est trompé, écrivez à quoi ressemble un résultat correct pour chacune, ajoutez des cas où la bonne décision est de refuser ou d’escalader, donnez à chaque critère son propre grader et faites tourner chaque cas plusieurs fois avant chaque modification.
L’équipe support définit les cas ; l’équipe IA les branche :
- Tirez les cas du contrôle qualité. Les conversations en échec ou escaladées des 90 derniers jours, regroupées par intention.
- Écrivez le résultat attendu en une phrase. « Refuse le remboursement, cite la règle des 30 jours, propose un avoir, n’escalade pas. »
- Ajoutez les cas miroirs. Pour chaque cas « doit refuser », un cas « doit le faire » ; pour chaque cas « doit escalader », un cas où l’escalade serait une erreur.
- Séparez les critères. Exactitude, règles, action, escalade et ton ont chacun leur propre contrôle ; l’article d’Anthropic recommande un juge par dimension de la grille.
- Vérifiez le système, pas la phrase. Quand l’agent effectue une action, le grader lit l’enregistrement dans le système de commandes ou le helpdesk, pas l’affirmation de l’agent.
- Faites tourner chaque cas 3 à 5 fois et ne le comptez comme réussi que si toutes les exécutions réussissent. C’est pass^k en pratique.
- Gardez deux jeux. Un jeu de non-régression qui doit réussir presque 100 % du temps, et un jeu de capacités plus difficile pour les intentions que vous comptez automatiser ensuite.
La version minimale, telle que la décrivent les praticiens, consiste en quelques dizaines de vrais tickets qui ont mal tourné, rejoués à chaque modification du prompt. Notre guide sur les tests d’agents IA détaille la conception des tests, les campagnes de non-régression et la simulation.
Quels indicateurs d’évaluation des agents IA comptent au service client ?
Les indicateurs d’évaluation des agents IA qui comptent au service client sont la résolution correcte, l’exactitude des réponses, le respect des règles, l’exactitude des actions, la qualité des escalades et le ton, complétés par les recontacts et les retours clients. La contention et la déflexion indiquent seulement que le client n’a pas atteint une personne : elles vont dans la colonne contexte, pas dans la note qualité.
| Indicateur | Définition | Pourquoi il compte |
|---|---|---|
| Résolution correcte | Part des conversations traitées par l’IA évaluées comme résolues avec une réponse correcte et sans recontact sous 7 jours | La version honnête du « taux de résolution » |
| Exactitude des réponses | Part des conversations sans erreur factuelle par rapport à vos propres contenus | Repère les règles, prix et étapes inventés |
| Respect des règles | Part des conversations sans manquement aux règles de remboursement, d’identité, d’information ou de périmètre | Un manquement se répète dans chaque conversation similaire |
| Exactitude des actions | Part des actions annoncées par l’agent qui correspondent à l’enregistrement du système | Repère le « remboursement effectué » alors que l’API a échoué |
| Qualité des escalades | Part des transferts faits sur le bon déclencheur, avec le contexte transmis ; plus le taux d’escalades manquées | Un mauvais transfert oblige le client à tout recommencer |
| Ton | Part des conversations qui réussissent vos critères de ton et d’empathie | Une réponse correcte mais froide fait quand même perdre des clients |
| Contention (contexte) | Part des conversations qui n’ont jamais atteint une personne | Indicateur de volume uniquement ; il compte les mauvaises réponses comme des succès |
Associez le taux de contention (en anglais) à un contrôle de résolution, lisez notre guide pour mesurer la performance d’un agent IA afin de comparer équitablement IA et conseillers, et reportez les critères dans une grille d’évaluation d’agent IA.
Juge LLM ou relecture humaine : comment les calibrer ?
Utilisez un juge LLM pour évaluer chaque conversation et des évaluateurs humains pour le calibrer et prendre en charge les cas à haut risque. Calibrez en faisant noter les mêmes 100 à 200 conversations à l’aveugle par deux évaluateurs et par le juge, mesurez l’accord séparément pour chaque critère et reformulez le critère partout où le juge et les humains divergent.
Le LLM as a judge consiste à faire noter une conversation par un modèle de langage selon vos critères écrits (notre définition, en anglais). L’article de recherche Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (en anglais) a montré que GPT-4 atteignait plus de 80 % d’accord avec les préférences humaines, le même niveau d’accord que celui des humains entre eux. Il liste aussi les points faibles du juge : biais de position, de verbosité et d’auto-complaisance, et un raisonnement limité.
Une routine de calibrage qui tient :
- Notez à l’aveugle. Deux évaluateurs et le juge notent le même jeu séparément. Les évaluateurs se mettent d’accord d’abord, puis comparent avec le juge.
- Mesurez critère par critère. Un accord global de 90 % peut cacher un critère de ton à 70 %. Pour les critères réussi ou échoué, suivez le rappel : parmi les vrais manquements aux règles, combien le juge en a-t-il repéré ?
- Laissez le juge répondre « inconnu ». L’article d’Anthropic recommande de donner au juge une porte de sortie pour réduire les notes inventées. Transmettez les « inconnu » à une personne.
- Recalibrez après chaque modification de la grille, du modèle du juge ou du périmètre de l’agent, et au moins une fois par mois.
Notre protocole pour valider la notation par IA en une semaine (en anglais) en fait un plan jour par jour, avec des seuils d’accord.
Combien de conversations faut-il évaluer ?
Pour les evals avant lancement, 20 à 50 vrais cas de défaillance suffisent pour commencer, puis quelques centaines à mesure que vous automatisez d’autres intentions. Pour l’évaluation en production d’un agent IA, évaluez chaque conversation si vous le pouvez, car les défaillances les plus coûteuses sont rares et les défaillances rares se cachent dans les échantillons. Gardez une double notation humaine sur 100 à 200 conversations par mois.
Illustration (pas des données client). Un agent IA traite 40 000 conversations par mois. L’équipe qualité évalue un échantillon de 1 % : 400 conversations.
| Défaillance | Taux | Clients touchés par mois | Nombre attendu dans l’échantillon de 400 | Probabilité que l’échantillon n’en montre aucune |
|---|---|---|---|---|
| Mauvaise éligibilité au remboursement | 0,5 % | 200 | 2 | 13 % |
| « Remboursement effectué » alors que l’API a échoué | 0,2 % | 80 | 0,8 | 45 % |
La probabilité de n’en voir aucune est égale à (1 moins le taux) à la puissance 400. Même deux erreurs de remboursement repérées ressemblent à du bruit ; évaluer les 40 000 conversations fait apparaître 200 et 80 cas, regroupés par intention.
Trois règles empiriques :
- Marge d’erreur. Un taux de résolution correcte de 90 % mesuré sur 400 conversations est précis à environ ±3 points (confiance de 95 %), donc une baisse à 88 % reste dans le bruit. Sur 40 000 conversations, la marge est d’environ ±0,3 point.
- Zéro défaillance ne veut pas dire zéro risque. Si vous ne voyez aucune défaillance sur n conversations, le taux réel peut encore atteindre environ 3 divisé par n : montrer un taux inférieur à 1 % demande environ 300 conversations sans défaut, inférieur à 0,1 % environ 3 000.
- Les jeux de calibrage sont petits à dessein. 200 conversations doublement notées avec 85 % d’accord situent cet accord à environ ±5 points près : assez pour repérer un critère mal formulé, pas pour classer les évaluateurs.
Les calculs sont expliqués dans notre article sur les statistiques d’échantillonnage en contrôle qualité (en anglais).
Le cadre d’évaluation des agents IA (tableau à copier)
Ce cadre liste, pour un agent IA de service client, ce qu’il faut évaluer, la méthode, l’indicateur, un exemple de seuil, le responsable et la fréquence. Les seuils sont des exemples à discuter, pas des références du secteur : fixez les vôtres à partir de votre propre niveau de référence et de ce que vous coûte une seule défaillance.
| Ce qu’il faut évaluer | Méthode | Indicateur | Exemple de seuil | Responsable | Fréquence |
|---|---|---|---|---|---|
| Exactitude des réponses | Juge LLM ayant accès à votre base de connaissances ; contrôles ponctuels humains | Part des conversations sans erreur factuelle | 98 % ou plus ; chaque nouveau type d’erreur rattaché à sa source sous une semaine | Responsable qualité avec le responsable des connaissances | Chaque conversation évaluée ; revue hebdomadaire |
| Respect des règles | Contrôles par règles sur les actions plus un juge LLM sur la formulation | Taux de manquements, séparés en critiques et mineurs | Zéro manquement critique sur le jeu de non-régression ; chaque manquement en production examiné | Responsable des règles ou de la conformité | Chaque conversation ; alerte le jour même pour les manquements critiques |
| Exactitude des actions | Comparer l’affirmation de l’agent à l’enregistrement du système | Taux d’écart entre actions annoncées et actions réelles | Zéro écart avant le lancement ; chaque écart en production examiné | Responsable IA ou automatisation | Avant chaque modification ; chaque jour en production |
| Résolution correcte | Juge LLM plus recontact sous 7 jours | Part des conversations traitées par l’IA résolues correctement | Fixé à partir du niveau du premier mois ; analyser toute baisse de 3 points ou plus | Responsable CX | Chaque semaine |
| Qualité des escalades | Critères de la grille : bon déclencheur, contexte transmis, pas de boucle | Taux d’escalades manquées ; part des transferts avec contexte complet | Tous les cas de test « doit escalader » réussis avant le lancement ; escalades manquées sous 1 % en production | Responsable qualité avec le responsable du routage | Chaque semaine |
| Ton et empathie | Juge LLM par critère, calibré par les évaluateurs | Part des conversations qui réussissent les critères de ton | 95 % ou plus, après calibrage | Responsable qualité | Chaque conversation ; calibrage mensuel |
| Constance | Exécutions répétées du jeu de tests critiques | pass^k avec k = 5 | 90 % ou plus sur les tâches critiques | Responsable IA ou automatisation | Avant chaque modification de prompt, de modèle, d’outil ou de contenu |
| Fiabilité du juge | Double notation à l’aveugle par deux évaluateurs | Accord par critère ; rappel sur les échecs critiques | 85 % d’accord ou plus par critère ; 90 % de rappel sur les échecs critiques | Responsable qualité | Chaque mois, et après toute modification de la grille ou du modèle |
| Résultat client | CSAT sur les conversations traitées par l’IA, recontacts, abandons | Tendance par rapport à votre référence | Pas de baisse deux semaines d’affilée | Responsable CX | Chaque semaine ; chaque mois dans la revue de performance de l’agent IA |
Pourquoi le seuil de constance est strict : une tâche qui réussit 98 % des exécutions isolées réussit les 5 exécutions environ 90 % du temps, et une tâche à 95 % seulement environ 77 % du temps. Chaque client tombe sur l’exécution du moment.
Qui doit être responsable de l’évaluation des agents IA ?
L’évaluation des agents IA demande trois responsables : le responsable IA ou automatisation mène les evals avant lancement et corrige les prompts et les outils, le responsable qualité mène l’évaluation en production et le calibrage du juge, et le responsable CX fixe les seuils et décide si l’agent est étendu, maintenu ou restreint. Les responsables des connaissances et des règles corrigent les contenus que les notes pointent.
L’erreur fréquente consiste à confier l’évaluation uniquement à l’équipe qui construit l’agent : ceux qui construisent mesurent ce qu’ils peuvent changer, alors que les responsables support ont besoin de voir ce que les clients ont reçu. Confiez les chiffres de production à une personne du support ; le tableau du cadre ci-dessus nomme un responsable par indicateur. L’évaluation n’est qu’une partie d’un modèle de supervision plus large, décrit dans notre guide sur la gouvernance des agents IA.
Quels outils d’évaluation des agents IA les équipes support utilisent-elles ?
Les équipes support utilisent quatre types d’outils d’évaluation des agents IA : les plateformes d’evals et d’observabilité pour développeurs, pour les tests avant lancement et les traces ; les outils de simulation qui jouent le client ; les analyses intégrées à la plateforme d’agents ; et les plateformes de contrôle qualité des conversations, qui évaluent les vraies conversations avec une grille. La plupart des grandes équipes finissent avec un outil par temps.
| Type d’outil | Exemples sur le marché | Ce qu’il dit | Limites pour un responsable support |
|---|---|---|---|
| Evals et observabilité pour développeurs | LangSmith, Langfuse, Arize Phoenix, Braintrust, DeepEval | Cette modification a-t-elle cassé un test ? Où dans la trace l’échec s’est-il produit ? | Conçus pour des ingénieurs ; les notes correspondent rarement à votre grille support |
| Tests par simulation | Outils dédiés de simulation et d’appels de test | Comment l’agent gère-t-il des centaines de clients scénarisés ? | Ne valent que par leurs scénarios ; pas de vrais clients |
| Analyses de la plateforme d’agents | Reporting d’Intercom Fin, des agents IA de Zendesk, de Salesforce Agentforce, de Decagon, de Sierra | Combien de conversations ont été automatisées ou contenues ? | Mesurent le volume plus que la justesse |
| Contrôle qualité des conversations | Kaizo et d’autres plateformes de contrôle qualité | Chaque vraie conversation était-elle correcte, autorisée et bien traitée ? | Interviennent après la conversation, pas avant une mise en production |
Kaizo se situe sur la dernière ligne. AutoPilot évalue chaque conversation résolue selon votre propre grille, et chaque note renvoie aux preuves dans la conversation. Vous testez la notation par rapport aux évaluations historiques de votre équipe avant la mise en service, et les évaluateurs gardent les conversations qui demandent du jugement. Notre page sur le contrôle qualité des agents IA montre comment cela fonctionne dans Zendesk et Salesforce.
Voyez-le sur vos propres conversations. Kaizo évalue 100 % de vos conversations de support et transforme les résultats en coaching. Réserver une démo.
Quand ce niveau d’évaluation n’est pas pour vous
Si votre agent IA traite quelques dizaines de conversations par semaine, laissez de côté le cadre, le juge et l’outil : lisez vous-même chaque transcription pendant une heure par semaine avec une courte liste de contrôle (correct, autorisé, bon transfert, bon ton). Lancez le programme complet quand le volume dépasse ce qu’une personne peut lire, ou quand l’agent commence à agir, par exemple sur des remboursements ou des modifications de compte.
Si ce qu’il vous faut est une suite de tests pour développeurs dans votre chaîne de mise en production, c’est un autre outil ; la plateforme de contrôle qualité de Kaizo évalue les conversations une fois terminées et peut fonctionner à côté.
Comment démarrer l’évaluation des agents IA cette semaine
Vous pouvez démarrer l’évaluation des agents IA cette semaine sans rien acheter. En cinq jours, une équipe support peut choisir trois intentions, rassembler 30 vraies défaillances, écrire cinq critères oui ou non, évaluer 100 conversations récentes comme niveau de référence et s’accorder sur les responsables et les seuils. Tout le reste du cadre part de là.
- Lundi : choisissez l’intention au plus fort volume, la plus risquée (en général les remboursements ou les modifications de compte) et celle dont les clients se plaignent le plus.
- Mardi : extrayez 10 mauvaises conversations par intention du contrôle qualité, des réclamations et des escalades ; écrivez le résultat correct pour chacune en une phrase.
- Mercredi : écrivez cinq critères (réponse correcte, règles, action conforme au système, escalade, ton), chacun sous forme de question oui ou non, avec la preuve qui permet de trancher.
- Jeudi : deux évaluateurs notent 100 conversations récentes à l’aveugle. C’est votre niveau de référence et votre premier jeu de calibrage.
- Vendredi : remplissez le tableau du cadre avec vos noms, vos chiffres de référence et une date pour la première revue mensuelle.
Confiez les 30 défaillances à votre équipe IA comme premier jeu de non-régression : rien n’est mis en production tant qu’il n’est pas réussi.
Questions fréquentes
Quel est un bon taux d’exactitude pour un agent IA de service client ?
Il n’existe pas de chiffre universel ; tout dépend de ce que coûte une mauvaise réponse. À titre d’exemple de seuil, visez 98 % ou plus de conversations sans erreur factuelle et zéro manquement critique aux règles sur votre jeu de non-régression. Fixez le seuil de production à partir de votre propre niveau de référence et analysez toute baisse de 3 points ou plus.
À quelle fréquence faut-il relancer les evals d’un agent IA ?
Relancez le jeu de non-régression avant chaque modification de prompt, de modèle, d’outil ou de connaissances, car chacune peut casser quelque chose qui fonctionnait. Évaluez les conversations de production en continu, revoyez les chiffres chaque semaine et calibrez le juge chaque mois et après chaque modification de la grille.
Faut-il évaluer les agents IA avec la même grille que les conseillers ?
Utilisez des critères communs là où ils s’appliquent aux deux, comme une réponse correcte et le bon ton, pour que les résultats restent comparables. Ajoutez ensuite les critères dont seul un agent IA a besoin : ancrage dans vos contenus, exactitude des actions, périmètre et déclencheurs d’escalade. Un standard unique complété par des contrôles propres à l’IA fonctionne mieux que deux grilles sans lien.
Quelle est la différence entre pass@k et pass^k ?
pass@k est la probabilité qu’au moins une des k exécutions réussisse, ce qui convient aux outils où une seule bonne réponse suffit. pass^k est la probabilité que les k exécutions réussissent toutes. Le service client a besoin de pass^k, car chaque client ne reçoit qu’une exécution et attend la bonne réponse à chaque fois.
L’évaluation des agents IA est-elle la même chose que leur monitoring ?
Non. Le monitoring surveille en direct les volumes, les erreurs et les alertes pour que vous remarquiez vite un problème. L’évaluation juge si chaque réponse était correcte, autorisée et bien traitée, avant le lancement sur des cas de test et après le lancement sur de vraies conversations. L’évaluation en production alimente le monitoring, et chaque défaillance qu’elle trouve devient un nouveau cas de test.
