Pourquoi les conversations IA échouent : 10 causes

Analyser les échecs d’un agent IA, c’est classer chaque conversation IA ratée selon sa cause avant que quiconque ne la corrige. La plupart des échecs qualifiés d’« hallucinations » sont autre chose : un article manquant, une règle périmée ou ambiguë, une recherche documentaire ratée, un outil en panne ou un mauvais transfert. Chaque cause a un responsable et un correctif différents : l’étiquette décide donc si le correctif fonctionne.

En bref

• « Hallucination » décrit un symptôme (une réponse fausse donnée avec assurance), pas une cause. Traitez-la comme la dernière explication, pas la première.
• Dix causes couvrent presque toutes les conversations IA ratées au support, des lacunes de contenu à la confusion côté client.
• Une seule question règle la plupart des cas : existait-il une source validée qui répondait à la question, et l’agent l’a-t-il utilisée ?
• Les causes liées au contenu vont au responsable des contenus ou des règles, les causes liées aux outils à l’équipe technique, et seuls les défauts de raisonnement à l’équipe qui règle l’agent IA.
• Suivez chaque semaine la répartition par cause pour 1 000 conversations. Les parts seules sont trompeuses, car une cause peut augmenter en part tout en diminuant en nombre.

Pourquoi les équipes qualifient-elles chaque échec d’un agent IA d’hallucination ?

Les équipes qualifient chaque échec d’hallucination parce que la transcription ne montre que le résultat : une réponse fausse, énoncée avec assurance. La cause se trouve en amont, dans le contenu, la règle, l’étape de recherche, un outil ou les règles de transfert. Sans étape qui classe la cause, le mot le plus familier l’emporte, et le correctif atterrit dans le prompt.

Le mot a un sens précis. Le profil de risque du NIST pour l’IA générative définit la confabulation, « aussi appelée familièrement hallucinations », comme le fait pour un système de « générer et présenter avec assurance des contenus erronés ou faux » (NIST AI 600-1, section 2.2, en anglais, notre traduction). Cela couvre le modèle qui invente quelque chose. Cela ne couvre pas un agent qui a fidèlement répété un article de remboursement périmé, ni un agent qui a suivi une règle que personne n’a jamais écrite.

La différence compte, car la mauvaise étiquette envoie le travail à la mauvaise équipe. Une modification du prompt ne peut pas corriger un article qui n’existe pas. Quand l’éditeur d’outils support Pylon a classé environ 200 tickets que son agent IA avait escaladés en une semaine dans sa propre file, les lacunes de contenu « représentaient plus de la moitié des escalades » et les demandes de fonctionnalités 15 % (Pylon, septembre 2026, en anglais, notre traduction). Ce sont les données d’une seule entreprise, pas une référence du secteur, mais aucune de ces deux causes n’est un problème de modèle.

Ce guide fait partie de notre dossier sur la gestion des politiques des agents IA, qui explique comment les règles sont rédigées, attribuées et versionnées. Ici, l’accent est mis sur l’étape qui précède le correctif : nommer correctement la cause.

Quelles sont les dix raisons pour lesquelles les conversations IA échouent ?

Au support, les conversations IA échouent pour dix raisons principales : une lacune de contenu, un contenu périmé ou contradictoire, une règle manquante ou ambiguë, un échec de la recherche documentaire, une erreur de raisonnement ou une hallucination, l’échec d’une action ou d’un outil, un transfert raté, une erreur de périmètre, un bug produit ou une demande de fonctionnalité, et un problème côté client. Chacune laisse une trace différente dans la transcription.

Le tableau ci-dessous est la typologie à copier. Utilisez-la comme liste de choix dans votre formulaire de revue, une cause par critère échoué.

Étiquetez le critère échoué, pas la conversation entière, car une conversation peut échouer pour deux causes. Les causes 6 et 7 se cachent souvent dans les taux de contention ; notre guide sur les erreurs silencieuses des agents IA explique comment les faire apparaître. Pour les conseillers, la distinction équivalente se trouve dans notre guide sur l’erreur du conseiller ou l’erreur de processus (en anglais).

Comment distinguer une hallucination d’une règle manquante ?

Vous distinguez une hallucination d’une règle manquante en vérifiant la source. Si une source validée et à jour répondait à la question et que l’agent s’en est écarté, c’est une hallucination ou une erreur de raisonnement. Si aucune source ne couvrait le cas, ou si la règle n’existe que dans la tête des conseillers expérimentés, c’est une règle manquante, et aucune modification du modèle ne la corrigera.

Les quatre paires les plus souvent confondues :

• Hallucination ou règle manquante. Le test : « un nouveau conseiller, en lisant uniquement vos sources écrites, aurait-il pu répondre correctement ? » Si ce n’est pas le cas, l’agent IA n’avait rien à quoi être fidèle.
• Hallucination ou contenu périmé. Si le fait erroné figure mot pour mot dans un article, l’agent a fait son travail. C’est l’article qui est en échec.
• Hallucination ou échec de la recherche documentaire. Si le bon article existe mais que la réponse correspond à un sujet voisin, l’agent a répondu fidèlement à partir de la mauvaise page. La génération augmentée par récupération (RAG), la méthode qu’utilisent de nombreux agents IA de support, associe un modèle à une recherche dans vos contenus (Lewis et al., 2020, en anglais) : l’étape de recherche peut donc échouer à elle seule.
• Action hallucinée ou échec d’un outil. « Votre remboursement est en cours » sans remboursement dans le système, c’est soit l’agent qui revendique une action qu’il n’a jamais effectuée, soit un appel d’outil qui a échoué sans bruit. Le journal de l’outil vous dit lequel. Notre guide sur l’audit du taux de résolution des agents IA explique comment vérifier les actions annoncées par rapport aux enregistrements du système.

Notre guide pour repérer les hallucinations des agents IA présente la routine pour les vraies hallucinations une fois isolées. Cette page est le filtre qui décide lesquelles sont vraies.

L’arbre de décision du tri : dix questions dans l’ordre

Le moyen le plus rapide de classer une conversation IA ratée est de répondre à une liste fixe de questions, dans un ordre fixe, et de s’arrêter au premier « oui » ou « non » qui nomme une cause. L’ordre compte : il écarte les causes liées au client, au produit et aux systèmes avant d’incriminer le contenu, et le contenu avant d’incriminer le modèle.

Copiez-le dans votre formulaire de revue. Répondez pour un critère échoué à la fois.

1. Un conseiller aurait-il compris ce que voulait le client à partir de ce qu’il a écrit ? Non : côté client (cause 10). Oui : continuez.
2. La demande relevait-elle bien de l’agent IA ? Non, et il l’a traitée quand même : erreur de périmètre (cause 8). Oui : continuez.
3. Le problème de fond était-il un défaut, ou quelque chose que le produit ne fait pas ? Oui : bug produit ou demande de fonctionnalité (cause 9). Non : continuez.
4. L’agent devait-il effectuer ou vérifier une action (recherche, remboursement, résiliation, mise à jour), et cet appel a-t-il échoué, expiré ou été refusé ? Oui : échec d’une action ou d’un outil (cause 6). Non : continuez.
5. La conversation aurait-elle dû passer à un conseiller, à un autre moment, ou avec un meilleur contexte ? Oui : transfert raté (cause 7). Non : continuez.
6. Une source validée répond-elle à cette question ? Non, et la règle est claire pour tout le monde : lacune de contenu (cause 1). Non, et la règle dépend de la personne à qui l’on demande : règle manquante ou ambiguë (cause 3). Oui : continuez.
7. Cette source est-elle à jour, et la seule sur le sujet ? Non : contenu périmé ou contradictoire (cause 2). Oui : continuez.
8. L’agent a-t-il utilisé cette source pour cette réponse ? Non : échec de la recherche documentaire (cause 4). Oui : continuez.
9. La réponse correspond-elle à la source ? Non : erreur de raisonnement ou hallucination (cause 5). Oui : continuez.
10. Le critère lui-même est-il juste ? Si l’agent a suivi fidèlement une source validée et à jour et a quand même échoué, le critère de la grille est peut-être faux. Envoyez-le au responsable qualité pour calibrage plutôt que de forcer une cause.

La question 10 est la soupape de sécurité : une typologie qui ne peut pas dire « notre critère était faux » accuse celui qui reste. Comptez combien de fois vous atteignez la question 9. C’est le seul chemin qui aboutit à « hallucination ».

Qui corrige chaque cause, et comment l’orienter ?

Chaque cause a un responsable, choisi selon l’endroit où le correctif doit se faire : le contenu va au responsable des contenus ou des règles, les systèmes à l’équipe technique, le produit à l’équipe produit, et seuls les instructions et le raisonnement au responsable de l’IA. Orientez la conversation avec les preuves jointes, jamais un simple chiffre.

Nommez chaque responsable comme une personne, pas comme une équipe. Une note d’orientation contient quatre éléments : la cause, deux ou trois conversations d’exemple avec les lignes en échec repérées, l’intention concernée avec son volume hebdomadaire, et la date à laquelle vous réévaluerez. Sans les exemples, l’équipe qui reçoit la note discute du classement au lieu de corriger.

Corriger un agent IA, ce n’est pas coacher une personne : le correctif doit modifier le contenu ou la configuration que lit l’agent. Notre article sur la différence entre coacher les conseillers et corriger les agents IA détaille cette distinction. Pour les causes 6 et 8, le bon correctif est parfois une limite, pas une meilleure réponse. L’OWASP cite « l’excès de fonctionnalités », « l’excès d’autorisations » et « l’excès d’autonomie » comme causes profondes des actions dommageables des agents (OWASP LLM06, en anglais, notre traduction), et c’est là que prennent le relais nos guides sur les garde-fous des agents IA et les niveaux d’autonomie des agents IA.

Comment mener un tri hebdomadaire des échecs de l’IA ?

Menez le tri des échecs de l’IA en une séance hebdomadaire de 45 à 60 minutes : récupérez les conversations ratées, regroupez-les par intention, classez les principaux groupes avec l’arbre de décision, orientez chaque cause vers son responsable avec des exemples, et vérifiez si les correctifs de la semaine précédente ont tenu. Classez des groupes, pas des conversations isolées, pour que la séance suive le volume.

Une routine qui fonctionne :

1. Lundi : récupérez les échecs. Prenez chaque conversation IA qui a échoué sur un critère critique la semaine précédente (exactitude, règles, action, escalade). Si vous n’évaluez qu’un échantillon, ajoutez chaque conversation suivie d’une réouverture, d’une réclamation ou d’un nouveau contact sous 7 jours.
2. Regroupez par intention. Remboursements, changements d’adresse, problèmes de connexion. Commencez par les cinq intentions qui comptent le plus d’échecs.
3. Classez trois à cinq conversations par groupe. Passez les dix questions. Si elles concordent, étiquetez le groupe. Si elles divergent, le groupe recouvre deux problèmes : scindez-le.
4. Orientez. Un ticket par cause et par intention, vers un responsable nommé, avec les exemples et une date de réévaluation.
5. Vérifiez la semaine précédente. Pour chaque correctif livré, comparez le nombre d’échecs sur cette intention avant et après. Un correctif qui n’a pas fait bouger le chiffre était le mauvais correctif ou la mauvaise cause.
6. Consignez. Une ligne par groupe : semaine, intention, cause, nombre, responsable, correctif, résultat. Ce journal est votre répartition des échecs dans le temps.

Le responsable qualité anime la séance avec le responsable de l’IA, le responsable des contenus et un responsable support ops. Les responsables des règles, l’équipe technique et l’équipe produit ne la rejoignent que lorsqu’un de leurs sujets est à l’ordre du jour. Les transferts ratés n’apparaissent souvent qu’en suivant plusieurs conversations, et c’est là que le contrôle qualité des parcours clients aide.

Comment mesurer la répartition des échecs de l’IA dans le temps ?

Mesurez la répartition des échecs en nombre d’échecs pour 1 000 conversations IA, ventilé par cause, chaque semaine, à côté de la part de chaque cause. Le nombre pour 1 000 montre si une cause diminue. La part montre où se trouve le travail restant. Lisez les deux, car corriger une cause fait paraître les autres plus grandes en part, même quand rien n’a changé.

Pylon l’a constaté dans ses propres données : à mesure que ses lacunes de contenu diminuaient, les signalements de bugs sont « passés de 8,5 % des escalades à 19 % » (Pylon, en anglais, notre traduction). Une part en hausse ne signifie pas à elle seule plus de bugs : les autres tranches ont rétréci.

Un exemple chiffré (illustration, chiffres inventés pour montrer le calcul)

Prenez un agent IA qui traite 12 000 conversations par semaine. En semaine 1, 480 échouent sur un critère critique : 40 pour 1 000. L’équipe corrige les principaux groupes liés au contenu et aux règles en quatre semaines. En semaine 5, à volume égal, 290 échouent : 24,2 pour 1 000.

Trois enseignements. Les trois causes liées au contenu sont passées de 260 à 95 échecs, de 54,2 % à 32,8 % de la répartition. Les hallucinations sont passées de 7,3 % à 11,4 % des échecs alors que leur nombre baissait de 35 à 33 : un responsable qui ne lirait que les parts conclurait que le modèle s’est dégradé. Et les échecs d’outils ont à peine bougé (de 40 à 38), ce qui indique que l’équipe technique n’a pas encore livré son correctif.

Les indicateurs à garder dans le tableau de bord :

• Échecs pour 1 000 conversations IA, au total et par cause.
• Part par cause, pour décider où porter l’effort la semaine suivante.
• Récurrence : échecs sur une intention et une cause marquées comme corrigées. Au-dessus de zéro après deux semaines, le correctif n’a pas tenu.
• Délai de correction par responsable, du ticket d’orientation à la réévaluation.
• Taux de non-classés : les échecs que personne n’a pu classer. S’il dépasse une petite part, la typologie ou les critères doivent être retravaillés.

Quand cette typologie n’est-elle pas pour vous ?

Une typologie à dix causes n’est pas pour vous, ou pas encore, quand votre agent IA répond à quelques centaines de questions par mois à partir d’un petit centre d’aide et n’effectue aucune action. Trois catégories suffisent alors : le contenu (causes 1 à 3), l’agent IA (4, 5, 8, 10) et tout le reste. Passez à la liste complète quand des responsables extérieurs au support commencent à recevoir le travail.

Les signes que trois catégories ne suffisent plus : l’agent effectue des actions dans d’autres systèmes, vous avez plus d’un agent IA ou d’une plateforme qui répond aux clients, les règles changent plus d’une fois par trimestre, ou deux équipes se disputent chaque semaine pour savoir à qui revient un échec. Si la même intention continue d’échouer après les correctifs, menez une analyse des causes racines plus poussée sur ce seul groupe plutôt que d’ajouter des catégories.

La place de Kaizo

Kaizo assure le contrôle qualité et la supervision de la gouvernance pour les équipes support où les personnes et les agents IA se partagent le travail. Il couvre le volet preuves de l’analyse des échecs : évaluer les conversations, faire apparaître les causes racines et réévaluer après un correctif. Il ne rédige pas vos articles ni vos règles.

AutoPilot évalue chaque conversation résolue selon votre propre grille, et pour le contrôle qualité des agents IA, vous ajoutez les critères sur lesquels un agent IA échoue et connectez votre base de connaissances pour qu’il juge par rapport à vos contenus. Chaque note renvoie aux preuves dans la transcription. Les insights et l’analytique transforment ces notes en causes racines (le processus défaillant, la friction dans le produit, la lacune de compétences), ce qui donne au tri hebdomadaire ses premiers groupes et ses exemples.

Voyez-le sur vos propres conversations. Réservez une démo et venez avec une intention que votre équipe considère comme un problème d’hallucination.

Par où commencer cette semaine

Commencez par les pires conversations IA de la semaine dernière, pas par un nouvel outil. Ajoutez les dix causes à votre formulaire de revue, classez un petit lot avec l’arbre de décision, nommez un responsable par cause et corrigez d’abord le plus grand groupe lié au contenu.

1. Collez le tableau des dix causes dans votre formulaire de revue comme liste de choix obligatoire pour chaque critère échoué.
2. Prenez les 30 pires conversations IA de la semaine dernière et passez les dix questions sur chacune. Comptez combien atteignent la question 9.
3. Nommez un responsable par cause, comme des personnes, et mettez-vous d’accord sur le format de la note d’orientation.
4. Réservez un créneau récurrent de 45 minutes pour le tri et démarrez le journal avec les groupes de cette semaine.
5. Choisissez le plus grand groupe lié au contenu et corrigez-le en premier. Réévaluez l’intention la semaine suivante. Le volet règles complet de la boucle se trouve dans notre guide sur la gestion des politiques des agents IA.

Questions fréquentes

Chaque mauvaise réponse d’un agent IA est-elle une hallucination ?

Non. Une hallucination est un contenu généré par le modèle qui n’est étayé ni par ses sources ni par la conversation. Une mauvaise réponse copiée d’un article périmé, ou une supposition sur un cas qu’aucune règle ne couvre, est un échec de contenu. Le test consiste à savoir si une source correcte et validée existait et si l’agent s’en est écarté.

Ancrer un agent IA sur vos propres contenus met-il fin aux hallucinations ?

L’ancrage dans vos contenus réduit les réponses inventées, mais ne les supprime pas, et il ajoute de nouveaux points de défaillance. L’agent peut récupérer le mauvais article, en citer un périmé, ou encore s’écarter du bon. C’est pourquoi la recherche documentaire et le contenu périmé ont leurs propres causes dans la typologie, distinctes de l’hallucination.

Qui doit être responsable de l’analyse des échecs d’un agent IA ?

Le responsable qualité est en général responsable du classement et du tri hebdomadaire, car la grille et les preuves de revue relèvent du contrôle qualité. Les correctifs reviennent aux responsables de chaque cause : contenus, règles, configuration de l’IA, équipe technique, support ops et produit. Une seule personne responsable du classement garde des étiquettes cohérentes d’une semaine à l’autre.

Combien de conversations IA ratées faut-il classer chaque semaine ?

Classez des groupes, pas chaque conversation. Trois à cinq conversations par groupe, sur les cinq intentions qui comptent le plus d’échecs, représentent 15 à 25 lectures par semaine et couvrent en général la plupart des échecs. Lisez-en davantage dans un groupe quand les conversations divergent sur la cause.

Les demandes de fonctionnalités doivent-elles compter comme des échecs de l’agent IA ?

Comptez-les, mais présentez-les à part des échecs propres à l’agent. Une demande de fonctionnalité met en échec le client, pas l’agent, et aucune modification du contenu ou du prompt ne la règle. Les compter montre à l’équipe produit à quelle fréquence les clients la formulent, et évite qu’elles ne gonflent le taux d’erreur de l’agent IA.