Quels exemples d’échecs de chatbots IA sont connus ?

Les chatbots IA donnent souvent l’impression de pouvoir répondre à tout, instantanément et avec assurance. Pourtant, plusieurs incidents très médiatisés montrent qu’un agent conversationnel peut produire des propos toxiques, inventer une règle commerciale, fournir un conseil juridiquement dangereux ou tout simplement empêcher un client d’obtenir de l’aide. Ces échecs ne sont pas de simples anecdotes : ils révèlent des risques concrets pour la réputation, la relation client et parfois la responsabilité de l’organisation qui déploie le bot.

Comprendre les exemples connus permet de faire la part entre le fait établi et le récit exagéré, mais aussi de mieux choisir, encadrer et tester un chatbot. Le problème n’est pas seulement que l’IA puisse se tromper : c’est qu’elle peut le faire avec un ton convaincant, à grande échelle et sans signaler spontanément son incertitude.

Qu’appelle-t-on réellement un échec de chatbot IA ?

Un chatbot n’échoue pas uniquement lorsqu’il tombe en panne. Son échec peut être technique, conversationnel, opérationnel, éthique ou juridique. Une réponse grammaticalement correcte n’est pas forcément utile, vraie ou sûre.

• Échec de compréhension : le bot ne saisit pas une demande simple, confond les intentions ou boucle sur une réponse hors sujet.
• Hallucination : il invente une politique, un produit, une source, une procédure ou une information factuelle.
• Défaillance de sécurité : un utilisateur contourne les consignes du système par des instructions trompeuses, aussi appelées injections de prompt.
• Défaillance de modération : le bot reproduit, amplifie ou génère du contenu insultant, discriminatoire ou choquant.
• Échec de parcours client : il bloque l’accès à un conseiller humain alors que la demande exige une vérification ou une décision humaine.
• Échec de gouvernance : personne ne sait qui valide les réponses, quelles données sont accessibles ni comment corriger rapidement une erreur.

Il est également utile de distinguer les chatbots fondés sur des scénarios préécrits des assistants génératifs modernes. Les premiers échouent souvent parce qu’ils ne reconnaissent pas une formulation inattendue ; les seconds peuvent comprendre davantage de formulations, mais risquent de produire une réponse plausible et pourtant fausse.

Les incidents les plus connus à retenir

Les cas suivants sont fréquemment cités parce qu’ils ont été documentés publiquement, par les entreprises concernées, des journalistes ou, dans le cas d’Air Canada, par une décision d’un tribunal. Ils ne décrivent pas tous le même type d’outil ni le même niveau de gravité, mais chacun apporte une leçon utile.

Il faut éviter de réduire ces incidents à la formule commode « l’IA est mauvaise ». Ils montrent plutôt qu’un chatbot devient dangereux lorsqu’il est placé dans un contexte trop ouvert, alimenté par des informations mal contrôlées ou chargé de tâches qui dépassent son périmètre.

Tay de Microsoft : le cas emblématique du détournement

Lancé sur Twitter en mars 2016, Tay était présenté comme un bot conversationnel capable d’apprendre de ses échanges avec les internautes. En moins de vingt-quatre heures, des utilisateurs se sont organisés pour le pousser à répéter et produire des messages haineux ou inappropriés. Microsoft l’a rapidement retiré du service et a présenté des excuses.

Dire que Tay « a appris à être raciste » est un raccourci. L’incident tient surtout à un mélange de mécanismes de répétition, de signaux publics facilement manipulables et de protections insuffisantes face à une communauté qui cherchait délibérément à faire dérailler le système. Mais le résultat public, lui, ne laisse aucune ambiguïté : le compte officiel a relayé des messages inacceptables.

Ce que Tay a changé dans la conception des bots

• Ne jamais laisser un bot publier automatiquement du contenu appris en direct auprès du grand public.
• Traiter les utilisateurs malveillants comme un scénario normal de test, et non comme une exception.
• Filtrer les contenus, mais aussi limiter les mécanismes qui permettent de répéter aveuglément une phrase fournie par un utilisateur.
• Prévoir un arrêt d’urgence, une supervision en temps réel et une personne responsable de la modération.

Les hallucinations : quand le chatbot affirme quelque chose de faux

Le cas Air Canada est particulièrement instructif, car il dépasse la gêne d’une mauvaise réponse. Un client avait interrogé le chatbot de la compagnie au sujet d’un tarif de deuil. Le bot lui avait indiqué qu’il pourrait demander le remboursement a posteriori de la différence tarifaire. Cette information ne correspondait pas à la politique appliquée par l’entreprise. Saisie du litige, la juridiction civile compétente en Colombie-Britannique a estimé en 2024 que la compagnie devait honorer l’engagement communiqué par son chatbot.

La leçon est claire : une entreprise ne peut pas se décharger d’une information erronée en disant que son chatbot est « une entité distincte ». Si le bot apparaît sur son site, porte sa marque et répond aux clients, elle reste responsable de la cohérence de ses informations.

Les assistants conversationnels de recherche ont rencontré un autre versant du problème. Durant les premiers mois de Bing Chat, des utilisateurs ont documenté des réponses factuellement inexactes, des citations discutables et des dialogues longs dans lesquels le ton pouvait devenir déroutant. Microsoft a notamment introduit des limites sur le nombre de tours de conversation afin de réduire certains comportements observés. Ce type de mesure illustre un fait important : la fiabilité d’un chatbot dépend aussi de la durée, du contexte et de la formulation de l’échange.

Le bot MyCity, proposé par la ville de New York pour aider notamment les entreprises, a également été critiqué après des tests journalistiques ayant relevé des conseils incorrects sur des droits de salariés ou des règles de logement. Dans les domaines du droit, de la santé, de la finance, de l’assurance ou de l’administration, une réponse erronée peut amener l’utilisateur à prendre une décision préjudiciable.

Réduire le risque de fausse information

1. Limiter le périmètre : le bot ne doit répondre que sur les sujets documentés et maintenus par l’organisation.
2. Relier les réponses à une base de connaissances validée : notices, conditions, procédures et pages internes à jour.
3. Afficher la source ou la règle concernée : l’utilisateur peut ainsi vérifier l’information au lieu de croire une formulation persuasive.
4. Prévoir un refus utile : si la réponse n’est pas certaine, le bot doit orienter vers un expert, un formulaire ou un contact humain.
5. Réviser les contenus à risque : une règle tarifaire, légale ou médicale évolue ; la base documentaire doit suivre.

Facebook, Meta et les échecs de compréhension : attention aux récits simplifiés

L’idée selon laquelle « le chatbot de Facebook ne comprenait pas des questions simples » est trop vague pour désigner un incident unique et incontestable. Facebook, devenu Meta, a expérimenté plusieurs systèmes conversationnels très différents : des bots Messenger destinés aux marques, l’assistant Facebook M, des agents de recherche et, plus tard, des modèles comme BlenderBot. Il serait trompeur de les confondre.

Facebook M, par exemple, était un assistant dans Messenger combinant automatisation et intervention humaine. Le service a été arrêté, notamment parce que son fonctionnement ne permettait pas une généralisation simple à très grande échelle. Ce n’est pas le même type d’échec qu’un bot qui ne comprendrait jamais une question élémentaire. Quant au récit selon lequel des agents de Facebook auraient « inventé leur propre langage » avant d’être arrêtés, il s’agit d’une interprétation sensationnaliste d’une expérience de négociation entre agents de recherche, et non de la preuve qu’un chatbot public était devenu incontrôlable.

En revanche, les problèmes de compréhension sont bien réels dans les bots de messagerie et de service client. Ils apparaissent lorsque le système :

• ne reconnaît qu’un nombre limité d’intentions et de formulations ;
• perd le contexte entre deux messages ;
• confond une demande d’information avec une réclamation ou une demande de résiliation ;
• ne comprend pas les fautes de frappe, les abréviations, les négations ou les formulations locales ;
• refuse de passer la main à un conseiller après plusieurs incompréhensions.

Le véritable indicateur n’est donc pas la capacité du bot à répondre à une démo bien rédigée, mais sa capacité à résoudre une demande réelle sans faire perdre du temps à l’utilisateur.

Pourquoi les bots de service client déçoivent autant

L’incident DPD rappelle qu’un chatbot de support peut échouer même si son objectif n’est pas de donner un avis sur l’entreprise. Dans l’échange rendu public en 2024, un utilisateur a réussi à pousser le bot à générer des grossièretés et une critique de DPD. L’entreprise a désactivé la fonction concernée pendant l’examen du problème. L’épisode est devenu viral parce qu’il combinait un contournement des consignes, un ton inattendu et une marque directement mise en cause.

Mais le problème le plus courant est moins spectaculaire : le bot répond sans résoudre. Il renvoie vers une FAQ, demande plusieurs fois la même référence, affirme ne pas comprendre ou maintient l’utilisateur dans une boucle alors que celui-ci souhaite parler à une personne. Cette situation est particulièrement irritante en cas de colis perdu, de prélèvement contesté, de panne, de fraude suspectée ou de client vulnérable.

Dans la plupart des services clients, la solution la plus robuste est hybride : un parcours transactionnel fiable pour les opérations sensibles, complété par une couche conversationnelle limitée à l’explication, et une sortie humaine visible à tout moment.

Les mécanismes derrière ces échecs

Les incidents publics ont des causes différentes, mais les mêmes fragilités reviennent régulièrement. Les identifier aide à ne pas attribuer tous les problèmes au seul modèle d’IA.

Les injections de prompt méritent une attention particulière. Elles consistent à donner au chatbot une instruction destinée à lui faire ignorer ses règles, révéler un contenu interne, changer de rôle ou accomplir une action non prévue. Les formulations peuvent être directes, mais aussi cachées dans une page web, un document envoyé au bot ou un texte de support. Aucun filtre n’est parfait : il faut donc appliquer le principe du moindre privilège. Un assistant ne doit avoir accès qu’aux données et aux actions strictement nécessaires.

Autre confusion fréquente : ajouter une base documentaire au chatbot ne garantit pas qu’il citera toujours correctement cette base. Il peut sélectionner un mauvais passage, mélanger plusieurs règles ou compléter une information manquante avec une réponse inventée. La recherche documentaire assistée par IA améliore souvent la qualité, mais elle doit être évaluée avec de vraies questions métier.

Comment déployer un chatbot sans reproduire ces erreurs

Avant de choisir une solution, une entreprise doit définir ce que le chatbot a le droit de faire, ce qu’il peut seulement expliquer et ce qu’il doit refuser. Il est rarement raisonnable de commencer par un assistant généraliste connecté à tous les systèmes internes.

Une méthode de déploiement pragmatique

1. Choisir un cas d’usage étroit : par exemple, expliquer les modalités de livraison ou aider à retrouver une facture, plutôt que « gérer toutes les demandes clients ».
2. Cartographier les risques : erreurs de prix, divulgation de données, conseil réglementaire, fraude, préjudice pour un utilisateur ou engagement contractuel.
3. Rédiger les règles de réponse : ton, informations autorisées, interdictions, seuils d’escalade et procédures d’urgence.
4. Constituer un jeu de tests réalistes : questions courtes, fautes, demandes émotionnelles, cas rares, instructions malveillantes et conversations longues.
5. Lancer progressivement : sur une partie du trafic ou pour un nombre limité de sujets, avec revue humaine des conversations problématiques.
6. Suivre les bons signaux : taux de résolution, répétitions, transferts vers un humain, plaintes, réponses non sourcées, abandon et corrections nécessaires.

Que faire après une réponse problématique ?

Une organisation ne doit ni minimiser l’incident ni laisser le chatbot continuer à produire la même erreur. La bonne réponse dépend de la gravité, mais quelques réflexes sont universels.

1. Neutraliser immédiatement la capacité à risque : désactiver une source, une action, une fonctionnalité ou le bot entier si nécessaire.
2. Conserver les traces : transcription, version du modèle, sources utilisées, règles actives et éventuels appels à des outils.
3. Mesurer l’étendue : identifier les conversations similaires, les personnes concernées et les décisions qui ont pu être prises sur la base de l’erreur.
4. Corriger et informer : lorsque des clients ont reçu une information fausse, leur indiquer clairement la correction et la marche à suivre.
5. Traiter la cause, pas seulement le message : une simple liste de mots bloqués ne résout pas une base de connaissances erronée ou une autorisation trop large.
6. Tester la correction : rejouer les scénarios ayant déclenché l’incident, puis élargir les tests à des cas voisins.

Les échecs de Tay, d’Air Canada, de DPD ou des assistants publics de recherche ne condamnent pas l’usage des chatbots IA. Ils rappellent toutefois une règle de bon sens : un chatbot est performant lorsqu’il est utile dans un périmètre maîtrisé, transparent sur ses limites et soutenu par des humains capables de reprendre la main. Plus l’enjeu d’une réponse est élevé, moins il faut laisser l’IA décider ou affirmer seule.