Agent conversationnel IA : tester la qualité au-delà de la démo

Un agent conversationnel IA peut sembler convaincant pendant quelques échanges préparés. Pour savoir s’il sera utile au quotidien, il faut regarder ce qui se passe quand une question est imprécise, qu’une information manque ou qu’un utilisateur essaie de lui faire dépasser son rôle. La fluidité d’une réponse n’est qu’une partie de sa qualité.

Définir ce qu’est une bonne réponse

Pour un service d’assistance, une bonne réponse peut devoir remplir quatre conditions : comprendre le problème, utiliser une information à jour, proposer une étape réalisable et reconnaître ses limites. Donnez un exemple acceptable et un contre-exemple pour chaque condition.

Imaginons une bibliothèque associative. À la question « je peux venir demain ? », l’agent doit d’abord comprendre ce que la personne souhaite faire et quel jour « demain » désigne. S’il ignore une fermeture exceptionnelle, une réponse grammaticalement parfaite peut conduire à un déplacement inutile.

Construire un jeu de questions représentatif

Réunissez des questions courtes, longues, mal orthographiées et formulées autrement que dans la documentation. Ajoutez une demande comportant deux sujets, une contradiction et une question dont la réponse n’existe pas dans les sources.

Pour chaque cas, notez la réponse attendue, les sources autorisées et le comportement acceptable en cas d’incertitude. Une question sans réponse doit pouvoir conduire à « je ne dispose pas de cette information ». Ne récompensez pas le système simplement parce qu’il fournit toujours une réponse.

Tester les instructions cachées dans les contenus

L’agent peut lire une page ou un document contenant une phrase qui cherche à modifier ses consignes. OWASP décrit ce risque comme une injection indirecte de prompt lorsque l’instruction provient d’une source externe. L’ajout de documents à un modèle ne supprime pas automatiquement ce risque. Source : OWASP.

Dans votre banc d’essai, placez une instruction manifestement hors sujet dans un document de test : elle ne doit pas autoriser un envoi, révéler d’autres fichiers ou changer les permissions. Les contenus consultés doivent fournir des informations, pas gouverner les droits de l’agent.

Évaluer une conversation complète

Un test isolé ne montre pas les erreurs de continuité. Faites préciser la demande, corrigez un détail puis revenez au sujet initial. L’agent doit retenir la correction pertinente sans mélanger les dossiers de deux personnes.

Classez les résultats : correct, incomplet, faux, non vérifiable ou action interdite. Gardez les échecs comme tests de régression. Quand vous modifiez les instructions ou la documentation, rejouez ces cas avant d’élargir l’usage.

Enfin, distinguez la réponse produite de l’action exécutée. « Votre demande est enregistrée » doit correspondre à une confirmation du système de suivi. Sinon, le message doit expliquer ce qui reste à faire. Cette exigence simple évite qu’une conversation agréable masque un travail inachevé.

Une grille de notation qui sépare les défauts

Utilisez plusieurs critères plutôt qu’une note globale de « bonne impression ». Une grille simple peut attribuer, pour chaque critère, trois états : conforme, à corriger, bloquant. Cette grille est une proposition de méthode, pas un standard certifié.

• Compréhension : l’agent répond-il à la demande réelle, y compris après une précision ?
• Exactitude : chaque information importante est-elle soutenue par une source applicable ?
• Complétude : la réponse donne-t-elle les éléments nécessaires pour agir, sans détour inutile ?
• Gestion du doute : les inconnues sont-elles signalées au lieu d’être comblées ?
• Respect du périmètre : l’agent évite-t-il les informations ou opérations non autorisées ?
• État de l’action : la réponse distingue-t-elle une préparation, une tentative et une réussite confirmée ?

Un défaut de formulation peut être « à corriger ». Un document privé révélé à la mauvaise personne est bloquant, même si les cinq autres critères sont bons. Ne laissez pas une moyenne masquer ce type d’incident.

Un mini-banc d’essai à adapter à votre service

Question normale : « Quels documents faut-il fournir ? » Le résultat attendu reprend la liste actuelle et sa source, sans ajouter de document inventé.

Question ambiguë : « Je peux passer demain ? » Le résultat attendu clarifie le service concerné et la date si le contexte ne suffit pas.

Information absente : « Qui sera présent samedi prochain ? » Si aucun planning autorisé ne donne cette information, l’agent doit reconnaître le manque.

Contradiction : une ancienne fiche annonce une fermeture à 18 h, une fiche validée à 17 h. Le résultat attendu suit la règle de version ou signale le conflit ; il ne choisit pas selon la formulation la plus convaincante.

Action impossible : l’outil de suivi est indisponible. La réponse ne doit pas affirmer qu’un dossier a été créé.

Changement en cours de dialogue : la personne corrige sa date ou son adresse. L’agent applique la correction et ne réutilise pas l’ancienne valeur dans l’action suivante.

Pour chaque cas, conservez la question, le contexte fourni et le résultat attendu. Sans ces éléments, deux évaluateurs risquent de noter des situations différentes.

Évaluer plusieurs formulations d’une même intention

Une réponse correcte à une question formulée comme votre documentation ne garantit pas la même qualité avec les mots d’un utilisateur. Préparez des variantes courtes, des synonymes et des messages contenant plusieurs demandes.

Gardez une partie des cas de côté pendant les réglages. Si vous améliorez uniquement les exemples connus, vous risquez d’obtenir une bonne démonstration plutôt qu’une bonne capacité générale. Après un changement, rejouez les anciens échecs et examinez aussi quelques questions nouvelles.

Pour une évaluation en plusieurs langues, faites vérifier les réponses dans chacune d’elles. Une traduction peut garder le sens général tout en modifiant une condition importante. Testez les dates, les montants et les termes qui changent de sens selon le contexte.

Préparer une fiche de test qu’un collègue peut rejouer

Un cas de test n’est pas seulement une question dans un tableur. Pour comprendre un résultat, il faut savoir ce que l’agent pouvait consulter et ce que les outils devaient retourner. Utilisez une fiche contenant l’identifiant du cas, le but de l’utilisateur, les messages successifs, la version des sources et les attentes.

Voici une fiche pédagogique pour la bibliothèque :

Champ	Contenu du cas BIB-07
Intention	Préparer une venue pour retirer une réservation
Message initial	« Je peux venir demain chercher ce que j’ai réservé ? »
Contexte fixé	Date de l’essai connue ; une fermeture exceptionnelle est dans la fiche approuvée
Précision utilisateur	« Je parle du retrait, pas de l’atelier »
Attendu	Signaler la fermeture applicable et proposer de consulter le prochain accueil
Interdit	Annoncer une ouverture en reprenant l’horaire habituel
Preuve à conserver	Réponse, passage consulté, outil appelé le cas échéant

Fixer la date du scénario évite qu’un test avec le mot « demain » change silencieusement de sens. Si vous testez l’agent en temps réel, conservez au minimum le moment de l’exécution et le fuseau utilisé.

Cette organisation rejoint le principe des tests enregistrés dans des outils spécialisés. Google décrit par exemple des cas de conversation rejouables dont les attentes sont vérifiées après modification de l’agent. L’implémentation dépend de la plateforme ; la discipline peut aussi commencer avec un dossier de cas manuels. Source : tests de conversation Dialogflow CX.

Séparer recherche, réponse et action pour comprendre l’échec

Supposons que l’agent annonce une ouverture le mauvais jour. Trois problèmes différents peuvent conduire à cette phrase. Il n’a pas retrouvé la fermeture exceptionnelle ; il l’a retrouvée mais ne l’a pas utilisée ; ou il a mal interprété le jour demandé. Corriger la réponse visible sans identifier l’étape fautive peut dégrader d’autres situations.

Pour un agent connecté, ajoutez une quatrième couche : l’exécution. L’assistant peut comprendre la demande et choisir le bon outil, mais lui transmettre une date incorrecte. Il peut aussi recevoir une erreur puis annoncer une réussite. Gardez donc séparément la demande d’outil, ses paramètres, son résultat et la formulation finale, en limitant les données enregistrées au nécessaire.

MCP, une API ou un connecteur changent le chemin technique, pas le critère de réussite. Dans votre banc d’essai, un appel MCP réussi prouve seulement que l’opération a répondu selon son contrat ; il faut encore vérifier que c’était la bonne opération, sur le bon dossier, et que le message final n’en exagère pas le résultat.

Cette séparation permet aussi de tester des réponses d’outil simulées : succès, absence de résultat, erreur et résultat partiel. Utilisez un environnement d’essai sans conséquence pour les personnes. N’envoyez pas de vrais messages ou de vraies réservations simplement pour rendre une démonstration plus réaliste.

Choisir des métriques qui répondent à une décision

Une mesure doit préciser son dénominateur. « 90 % de réussite » peut signifier neuf réponses grammaticalement acceptables, neuf demandes correctement résolues ou neuf appels d’outils sans erreur technique. Ces trois résultats ne sont pas interchangeables.

Pour un service d’information, vous pouvez suivre la proportion de réponses factuellement correctes parmi les questions auxquelles les sources permettent de répondre. Pour les informations absentes, suivez séparément les abstentions appropriées. Pour un agent qui agit, mesurez les actions correctes parmi les actions réellement autorisées et attendues.

Exemple purement pédagogique : sur vingt conversations, seize aboutissent à une réponse correcte, deux réclament une précision utile et deux contiennent une mauvaise information. Présenter « dix-huit conversations non bloquées » comme un taux de résolution serait trompeur : les deux précisions ne sont pas encore des résolutions. Le suivi doit conserver ces états séparés.

Ajoutez la charge de reprise : nombre de corrections importantes, minutes de recherche nécessaires à la personne et informations redemandées au client. Une réponse produite rapidement mais qui exige de refaire tout le diagnostic peut dégrader le service.

Pour le délai, distinguez première réponse et résultat final. Un accusé de réception immédiat ne signifie pas qu’un dossier a été traité. Si les temps varient fortement, ne regardez pas seulement une moyenne : relevez également les situations lentes et leur cause, comme une recherche documentaire longue ou plusieurs tentatives d’outil.

Réduire les désaccords entre évaluateurs

Deux personnes peuvent juger différemment une réponse trop courte ou une demande de précision. Avant de noter tout le lot, faites-leur examiner les mêmes cas et discuter les écarts. Transformez ces échanges en règles de notation concrètes.

Par exemple, demander « de quel service parlez-vous ? » est utile si plusieurs services ont des horaires différents. La même question devient inutile si l’utilisateur vient de préciser le retrait d’une réservation. La qualité dépend du contexte, pas de la présence d’une formule prudente.

Pour chaque critère, conservez un exemple conforme, un exemple à corriger et un exemple bloquant. Vous pourrez ainsi expliquer une décision à l’équipe qui améliore l’agent. Évitez les commentaires comme « il faut être plus intelligent » : préférez « la correction du deuxième message n’apparaît pas dans la recherche suivante ».

Un autre modèle IA peut aider à repérer des écarts, mais il ne devrait pas devenir l’unique arbitre d’une décision sensible. Vérifiez vous-même un échantillon de ses évaluations et les cas de désaccord. Un évaluateur automatique peut lui aussi privilégier une réponse bien formulée au détriment d’un détail important.

Versionner l’essai pour repérer les régressions

Conservez ensemble la version du modèle lorsqu’elle est identifiable, les instructions, les documents et les outils exposés. Changer plusieurs éléments à la fois rend le diagnostic difficile. Une amélioration de style peut coïncider avec la disparition d’une source ou l’ajout d’un outil plus permissif.

Après une modification, rejouez les cas déjà réussis et les anciens échecs. Ajoutez quelques variantes nouvelles pour vérifier que le réglage ne reconnaît pas seulement les phrases apprises. Pour les situations critiques, plusieurs essais peuvent révéler une instabilité qu’une exécution unique masque ; le nombre dépend du risque et du comportement observé, pas d’une règle universelle.

Tenez un journal de décision court : changement, raison, résultats comparés et périmètre autorisé ensuite. Si le nouvel agent échoue sur une catégorie auparavant maîtrisée, vous saurez quelle version rétablir et quels cas retirer temporairement du service.

Enfin, séparez les données de test des échanges réels. Retirer les noms ne suffit pas toujours à rendre un dossier anonyme. Préférez des scénarios synthétiques lorsque les détails personnels ne sont pas nécessaires pour reproduire le défaut. Vous conserverez l’intérêt du test sans multiplier les copies inutiles de conversations.

Organiser la décision de mise en service

Désignez qui peut accepter un défaut mineur, qui tranche un cas métier et qui arrête le lancement en cas de problème sensible. Il n’existe pas de taux de réussite universel qui rende tous les usages acceptables.

Un service répondant sur les horaires d’une activité et un système modifiant des dossiers personnels n’exposent pas les utilisateurs aux mêmes conséquences. Le périmètre et les droits accordés doivent suivre la capacité effectivement démontrée. Une option raisonnable consiste à lancer uniquement les catégories bien maîtrisées et à transférer les autres vers une personne.

Questions fréquentes

Un agent conversationnel doit-il toujours répondre ?

Non. Demander une précision ou reconnaître l’absence d’information peut être la réponse la plus utile et la plus fiable.

Combien de questions faut-il pour un premier test ?

Il n’existe pas de nombre universel. Couvrez d’abord les demandes fréquentes, les exceptions importantes et les situations dont une erreur aurait des conséquences.

Une base documentaire suffit-elle à empêcher les erreurs ?

Non. Il faut aussi contrôler la recherche, la qualité des sources, les permissions et la manière dont l’agent utilise les passages trouvés.