Chatbot IA : évaluer les réponses avec une grille métier

Un chatbot qui répond avec aisance n'est pas un chatbot qui répond juste. La fluidité du langage masque la plupart des défauts métier : une réponse élégante mais sans source, un brouillon d'email jamais vérifié, un refus là où il fallait répondre, ou l'inverse. Pour piloter un assistant intelligence artificielle, vous avez besoin d'une grille d'évaluation qui reflète vos règles, pas d'une impression de lecture. Cet article vous donne une méthode concrète : constituer un jeu de cas annotés, noter cinq critères séparés, isoler les erreurs critiques et suivre les régressions d'une version à l'autre.

Pourquoi une impression de lecture ne suffit pas

Quand vous relisez dix conversations d'un chatbot, votre jugement se porte spontanément sur la qualité de la langue : phrases construites, ton correct, absence de répétitions. C'est le critère le moins discriminant. Un modèle de langage produit presque toujours du texte lisible ; c'est précisément ce qui rend les erreurs de fond difficiles à repérer à l'œil nu.

La seconde limite de la relecture informelle est l'absence de référence. Sans jeu de cas annotés à l'avance, vous évaluez ce que le chatbot a choisi de montrer, pas ce qu'il aurait dû faire sur les cas qui comptent. Vous confondez alors « le chatbot est agréable » avec « le chatbot est fiable sur mes processus ». Une grille métier force la question inverse : voici douze situations représentatives, voici la réponse attendue, le chatbot s'en approche-t-il ?

Enfin, une impression ne se compare pas dans le temps. Si vous modifiez la base documentaire ou changez de modèle, vous devez pouvoir dire si le service s'est amélioré ou dégradé, critère par critère. C'est l'objet d'un protocole d'évaluation, au même titre qu'un cahier des charges testable avant le développement, comme celui décrit pour un agent IA sur mesure.

Constituer un jeu annoté de référence

Le jeu annoté est une liste de cas réels ou plausibles de votre activité, chacun accompagné de la réponse attendue et des critères applicables. Sa qualité dépend moins du volume que de la couverture : il faut des cas faciles, mais aussi des cas limites qui déclenchent les comportements sensibles.

Pour un chatbot de service client d'une PME, un jeu de départ raisonnable compte quelques dizaines de cas répartis ainsi :

• des questions courantes avec réponse documentée (délai de livraison, modalités de garantie) ;
• des questions où la réponse dépend d'une donnée client précise (état d'une commande, adresse de facturation) ;
• des demandes hors périmètre, où le bon comportement est un refus clair ;
• des situations tendues ou ambiguës, où le bon comportement est un transfert à un humain, selon les principes d'un transfert réussi à un conseiller ;
• des demandes qui exigent une action (créer un brouillon de réponse, mettre à jour un dossier), où il faut vérifier ce que le système a réellement fait, pas seulement ce qu'il a annoncé.

Chaque cas est annoté avant toute exécution : réponse attendue, source documentaire qui la justifie, action attendue le cas échéant, refus ou escalade attendus. Cette annotation préalable vous évite de rejouer les critères après coup pour « rattraper » une réponse séduisante. Si vos réponses s'appuient sur une base documentaire, la manière de la structurer influence directement la traçabilité des sources, sujet traité pour une base documentaire d'agent IA.

Les cinq critères : exactitude, preuve, action, refus, escalade

La grille distingue cinq critères, notés séparément. Les regrouper en un seul score détruirait l'information la plus utile.

Exactitude. Le contenu de la réponse correspond-il à la réponse annotée ? Non pas mot à mot, mais sur les faits : montants, délais, conditions, désignations. Une réponse bien rédigée qui annonce un délai de « 48 heures » là où votre procédure dit « 5 jours ouvrés » échoue sur ce critère, même si le reste est irréprochable.

Preuve. La réponse cite-t-elle une source vérifiable : document interne, référence de procédure, extrait de la base de connaissances ? Ce critère est séparé de l'exactitude parce qu'une réponse peut être correcte par hasard, sans fondement retrouvable. Exiger une preuve rend les erreurs auditables et limite le risque de réponses inventées, en cohérence avec l'organisation des connaissances et des droits d'un chatbot d'entreprise.

Action. Quand la réponse implique une opération (préparer un brouillon d'email, enregistrer une demande), l'action attendue a-t-elle été réalisée, et seulement elle ? Ce critère impose de vérifier l'effet réel, pas l'intention affichée. Un exemple utile : avec l'API Gmail, les scopes gmail.compose et gmail.modify peuvent aussi autoriser l'envoi ; un libellé de scope n'est pas une frontière de permission. Si votre règle métier est « ne jamais envoyer, seulement préparer un brouillon », c'est un contrôle applicatif qui la garantit, pas le nom du scope. La documentation officielle des scopes Gmail décrit ces autorisations.

Refus. Sur les cas hors périmètre, le chatbot refuse-t-il explicitement, sans inventer une réponse ni donner une information non vérifiée ? Le refus est un comportement attendu, pas un échec : un cas « hors périmètre bien refusé » est un succès.

Escalade. Sur les cas qui dépassent le rôle de l'assistant, le transfert vers un humain est-il déclenché, au bon moment, avec les informations nécessaires ? Là encore, un cas « escaladé à juste titre » compte comme réussite.

Séparer fluence, résolution, comportement et appels réels

Quatre familles de mesures ne doivent jamais être fusionnées.

La fluence mesure la qualité de langue : lisibilité, ton, absence de répétitions. Elle s'évalue séparément, éventuellement sur une échelle simple, parce qu'elle n'informe pas sur la justesse. Un chatbot parfaitement fluide peut échouer sur les cinq critères métier.

La résolution mesure la part de cas traités correctement de bout en bout : tous les critères applicables sont satisfaits sur le cas. C'est la métrique de pilotage principale, mais elle ne dit pas pourquoi un cas échoue.

Le comportement couvre refus et escalade : le chatbot fait-il les bons gestes quand il ne doit pas répondre ou pas trancher seul ? Ces métriques sont suivies à part parce qu'elles portent sur des sous-ensembles de cas différents.

Les appels réels désignent ce que le système a effectivement déclenché dans vos outils : brouillons créés, dossiers mis à jour, transferts effectués. On vérifie l'état final dans l'outil, pas la promesse du chatbot. Si un brouillon Gmail est modifié après création, son identifiant de brouillon reste stable alors que l'identifiant du message qu'il contient change ; votre vérification doit donc porter sur l'objet final, décrit dans la documentation des brouillons Gmail.

Cette séparation répond à une question de pilotage simple : « le chatbot parle bien, mais fait-il ce qu'il faut, et le voyons-nous dans nos outils ? »

Erreurs critiques et le piège de la moyenne

Toutes les erreurs ne se valent pas. Une réponse légèrement imprécise sur un délai secondaire se corrige à la relecture ; un envoi non demandé à un client, ou une information financière inventée, crée un dommage immédiat. La grille distingue donc les erreurs critiques : action non demandée, affirmation grave sans source, refus manquant sur un sujet sensible, donnée personnelle exposée à tort.

Le piège classique est la moyenne. Un score global de « 80 % de satisfaction » agrège des cas sans gravité et des cas dangereux. Deux versions peuvent afficher la même moyenne alors que l'une a éliminé les erreurs critiques et l'autre les a multipliées. Votre tableau de bord doit donc afficher, au minimum : le taux d'erreurs critiques, puis les taux par critère, et seulement ensuite une résolution globale. La moyenne sert à suivre une tendance, jamais à valider une mise en production.

Exemple chiffré : 12 cas fictifs annotés

Prenons un jeu hypothétique de 12 cas, volontairement fictif, pour une PME de distribution. Les trois cas hors périmètre sont les numéros 5, 8 et 11 ; les trois cas exigeant une escalade sont les 2, 7 et 10.

Cas	Situation	Critères échoués	Erreur critique
1	Délai de livraison standard	aucun	non
2	Réclamation ambiguë, escalade attendue	aucun	non
3	Modalités de garantie	aucun	non
4	Demande d'envoi d'un email au client	exactitude, preuve, action (envoi déclenché au lieu d'un brouillon)	oui
5	Question juridique hors périmètre, bien refusée	aucun	non
6	État de commande avec donnée client	aucun	non
7	Client mécontent, escalade attendue	aucun	non
8	Question financière hors périmètre, réponse inventée au lieu d'un refus	exactitude, refus	oui
9	Adresse de facturation	aucun	non
10	Demande commerciale sensible, escalade attendue	aucun	non
11	Question hors catalogue, réponse approximative sans source	exactitude, preuve, refus	non
12	Suivi de retour produit	aucun	non

Calcul explicite, cas par cas :

• Exactitude : échouent les cas 4, 8 et 11, soit 9 réussites sur 12 (75 %). Le cas 8 échoue en exactitude parce que la réponse inventée contient une affirmation fausse, en plus d'échouer sur le refus.
• Preuve : le critère est applicable à 11 cas ; le cas 8 est exclu de ce dénominateur. Les cas 4 et 11 échouent, soit 9 réussites sur 11 (environ 82 %). Un critère non applicable ne devient pas une réussite artificielle.
• Action : applicable aux cas 4, 6, 9 et 12. Seul le cas 4 échoue (envoi au lieu de brouillon), soit 3 réussites sur 4 (75 %).
• Refus : applicable aux cas 5, 8 et 11. Réussite : 5 ; échecs : 8 et 11 (le cas 11 a répondu au lieu de refuser), soit 1 sur 3 (environ 33 %).
• Escalade : applicable aux cas 2, 7 et 10, tous réussis, soit 3 sur 3 (100 %).
• Résolution de bout en bout : échouent les cas 4, 8 et 11, soit 9 réussites sur 12 (75 %).
• Erreurs critiques : 2 sur 12 (cas 4 et cas 8).

Sur la fluence, supposons que les 12 réponses soient bien rédigées, y compris les trois en échec. C'est précisément le point de l'exemple : la qualité de langue ne prédit rien. Un responsable qui ne lirait que le confort de lecture conclurait à un assistant excellent, alors que deux erreurs critiques attendent une correction.

Procédure d'évaluation en cinq étapes

1. Constituer et annoter le jeu. Rassemblez 20 à 50 cas couvrant les situations listées plus haut. Pour chaque cas, notez la réponse attendue, la source, l'action, le refus ou l'escalade attendus, et qualifiez à l'avance les erreurs qui seraient critiques.
2. Exécuter sans contexte qui induit la réponse. Passez le jeu au chatbot dans les conditions réelles d'usage, sans lui donner les annotations. Conservez les traces complètes : réponses affichées, sources citées, appels d'outils, états finaux dans vos systèmes.
3. Noter critère par critère. Pour chaque cas, cochez chaque critère applicable. Vérifiez les actions dans les outils, pas dans le discours du chatbot. Notez la fluence sur une échelle séparée.
4. Publier les métriques séparées. Taux d'erreurs critiques d'abord, puis chaque critère, puis la résolution globale. Ajoutez une phrase de lecture : « les deux erreurs critiques concernent les actions email » vaut mieux qu'un pourcentage seul.
5. Archiver la notation. Conservez le jeu, les annotations et les résultats datés. C'est ce qui rendra la comparaison entre versions possible.

Cette procédure est un protocole de conception, pas une obligation réglementaire ni une preuve de conformité : c'est vous qui choisissez les seuils acceptables selon vos enjeux.

Suivre la régression entre versions

La valeur de la grille apparaît quand vous la rejouez. À chaque changement — nouveau modèle, base documentaire modifiée, nouveau prompt, nouvelle intégration — réexécutez le même jeu annoté et comparez les métriques critère par critère avec la version précédente.

Une régression hypothétique : la version B corrige le cas 11 et fait passer l’exactitude de 9/12 à 10/12 (environ 83 %). En revanche, elle réalise une écriture non autorisée au cas 9, dont les informations restent exactes. Le cas 9 échoue désormais au critère d’action et devient critique. La résolution reste à 9/12 (75 %) : un cas gagné, un cas perdu. Les erreurs critiques passent de deux à trois ; la hausse de l’exactitude ne justifie donc pas le déploiement. La lecture par métriques séparées rend cet arbitrage visible ; la moyenne seule le cacherait.

Pour aller plus loin sur la construction de ces jeux de test et leur exécution, la démarche détaillée pour tester un agent conversationnel IA complète cette grille par les aspects techniques d'exécution. Si vos réponses concernent l'écriture d'emails, la conservation du ton de votre entreprise s'évalue aussi comme un critère dédié, voir conserver votre ton dans les réponses.

Limites de la grille et erreurs courantes

Trois limites méritent d'être assumées. D'abord, le jeu annoté vieillit : vos tarifs, délais et procédures évoluent, et des annotations obsolètes produiraient de faux échecs. Prévoyez une relecture périodique du jeu, sans en changer les cas en cours d'évaluation. Ensuite, l'annotation humaine comporte sa propre part de subjectivité, surtout sur la fluence et sur ce qui compte comme « réponse correcte mais formulée autrement » ; pour les cas sensibles, faites annoter par deux personnes et arbitrez les écarts. Enfin, un jeu de 12 ou 30 cas détecte les problèmes majeurs, il ne prouve pas l'absence de problème : un taux d'erreurs critiques de zéro sur un petit jeu est une information, pas une garantie.

Parmi les erreurs courantes : compter un refus justifié comme un échec de résolution ; noter l'action sur la foi de l'annonce du chatbot plutôt que sur l'état réel de l'outil ; modifier le jeu de test après avoir vu les résultats pour « améliorer le score » ; et surtout, présenter un score moyen unique comme critère de mise en production.

Si vous souhaitez définir une mission d'évaluation ou de conception d'un chatbot sur mesure, vous pouvez décrire votre besoin sur la page missions d'Edeverse.

Questions fréquentes

Combien de cas faut-il dans le jeu annoté ?

Vingt à cinquante cas suffisent pour un premier pilotage sérieux dans une PME, à condition de couvrir les cas limites et non seulement les questions faciles. Ce qui compte est la représentativité des situations sensibles : actions, refus et escalades doivent être présents en nombre suffisant pour être mesurés.

Faut-il noter la fluence si elle ne prédit rien ?

Oui, mais séparément et avec un poids faible. Une dégradation soudaine de la langue signale souvent un changement de modèle ou de prompt, et un ton inadapté peut suffire à perdre un client même sur une réponse exacte. La fluence est un indicateur de santé, pas un critère de validation.

Comment vérifier une action réellement effectuée ?

Toujours dans l'outil cible : le brouillon existe-t-il dans la boîte, le dossier est-il mis à jour, le transfert a-t-il bien créé un ticket ? Ne vous fiez jamais au résumé que fait le chatbot de sa propre action. Vérifiez l'état final, avec les identifiants stables de l'outil, et notez l'écart éventuel entre l'annonce et la réalité.

Un refus du chatbot est-il un échec ?

Uniquement si le cas était dans le périmètre. Sur un cas hors périmètre, le refus est le comportement attendu et il compte comme une réussite du critère refus. C'est pourquoi résolution et comportement sont suivis séparément : confondre les deux pénalise un chatbot qui sait dire non.

À quelle fréquence rejouer l'évaluation ?

À chaque modification du système : modèle, base documentaire, prompt ou intégration. Entre deux changements, un passage mensuel sur le même jeu suffit à détecter une dérive liée à des données qui évoluent. L'essentiel est de conserver le jeu et les annotations identiques pour que la comparaison entre versions reste valide.