Erreurs des chatbots :
les trouver et les corriger
Nous examinons les défaillances des dialogues, des réponses et des intégrations. Pour chaque problème : trouver la cause, la corriger et confirmer le résultat.
Trouver la cause.
Vérifiez la correction.
Un guide pour les responsables de projet et les équipes : contrôles pratiques, outils de diagnostic et priorités.
Partez d’un dialogue précis qui a échoué
« Le bot fonctionne mal » ne permet pas de corriger le système. Il faut le message reçu, la suite des actions, l’heure, le résultat attendu et le résultat réel. Ne vérifiez pas seulement le dialogue : une demande peut se perdre entre la messagerie, l’outil de création et le CRM alors que le bot a déjà annoncé un succès.
Distinguez une erreur de scénario d’un défaut de transmission ou d’une mauvaise réponse de l’IA. Dans le premier cas, corrigez la logique ; dans le deuxième, la connexion et le traitement des événements ; dans le troisième, les sources et les limites d’action. Changer de modèle ne répare pas une intégration défaillante, et ajouter un bouton ne met pas à jour un ancien tarif.
| Constat | Où chercher d’abord | Comment le confirmer |
|---|---|---|
| L’utilisateur est bloqué | Branche du scénario et état du dialogue | Reproduire le parcours avec la même saisie |
| La réponse est fausse | Source de connaissances et actualité des données | Comparer la réponse au document source |
| Une demande manque ou apparaît en double | Connexion au CRM et requêtes répétées | Journal des événements et fiches CRM |
| Le bot ne répond pas | Canal, connexion et serveur | Vérifier la réception de l’événement entrant |
| Aucun conseiller ne prend le relais | File d’attente et procédures des conseillers | Conseiller affecté et première réponse |
Consignez un exemple reproductible dans la tâche du développeur. Ne copiez pas des conversations complètes contenant des données personnelles dans un chat de travail partagé : une séquence anonymisée et un identifiant d’événement destiné au spécialiste responsable suffisent.
Erreur : considérer le dialogue comme un résultat
Le nombre de messages mesure l’activité, pas l’utilité du bot. Un long échange peut signifier que l’utilisateur n’obtient pas de réponse. Un échange court peut indiquer une tâche résolue, ou un visiteur parti immédiatement. Il ne faut pas réunir ces situations sous l’étiquette « dialogues réussis ».
Définissez un résultat propre à chaque scénario : demande enregistrée avec les données nécessaires, rendez-vous confirmé par le système de réservation, ou réponse reçue sans nouvelle demande d’aide. Ne considérez pas une demande comme résolue uniquement parce que la personne a cessé d’écrire.
Exemple pédagogique : un magasin de fauteuils de bureau
- Symptôme
- Le bot pose dix questions, mais le conseiller ne reçoit qu’un numéro de téléphone.
- Vérification
- Parcourez la sélection et ouvrez la demande créée. Contient-elle l’usage du fauteuil, le budget, le modèle et le créneau souhaité pour être contacté ?
- Correction
- Conservez les questions qui influencent la sélection ou le travail du conseiller. Transmettez les réponses avec la demande.
- Critère de validation
- Le conseiller poursuit la conversation sans redemander les informations déjà fournies.
Si la mission du bot n’est pas encore définie, commencez par le plan de création d’un chatbot. Automatiser à la fois les ventes, l’assistance, le recrutement et les validations internes sans règles distinctes complique le développement comme la vérification.
Erreur : ne prévoir que le parcours idéal
Le développeur appuie sur les bons boutons dans le bon ordre. Une personne réelle écrit au lieu de choisir, revient à un ancien message, modifie une réponse, s’interrompt et reprend plus tard. Le bot doit expliquer la suite et permettre de corriger une erreur.
- Démarrez depuis un nouveau compte : la mission est-elle claire sans les explications de l’auteur ?
- Saisissez une réponse inattendue, envoyez un message vide lorsque c’est possible, ou un type de fichier non pris en charge.
- Revenez à l’étape précédente et modifiez votre choix. Vérifiez que le résultat a été actualisé.
- Appuyez sur un bouton d’un ancien message après avoir terminé la demande. Vérifiez qu’il ne crée pas une commande contradictoire.
- Demandez de l’aide avec vos propres mots et via le bouton de contact humain.
N’imposez pas une limite arbitraire de boutons à toutes les tâches. Des options distinctes et des intitulés clairs sont plus importants. « Choisir un fauteuil » est plus explicite que « Continuer » si la destination de l’étape suivante n’est pas encore comprise.
Vérifiez séparément les blocs d’attente et les temporisations de l’outil. La branche « bouton non cliqué » ne doit pas démarrer avant que la personne ait pu répondre. Annulez ou recalculez le rappel une fois l’action terminée ; sinon, le message signalant une demande inachevée arrivera après son envoi.
Erreur : laisser les réponses sans source ni responsable
Un ancien délai de livraison ou une remise inexistante nuit autant à un bot classique qu’à un bot IA. Identifiez d’abord l’origine de l’affirmation : texte prédéfini, base de connaissances, catalogue, système externe ou génération libre. Corrigez la source réellement utilisée.
Tenez un registre simple pour les réponses importantes : sujet, source, responsable, date de contrôle et conditions de révision. Les stocks et créneaux disponibles doivent de préférence provenir du système en service. Sans cette connexion, la réponse doit expliquer qu’un collaborateur doit confirmer l’information.
Recherchez les contradictions : une instruction promet un échange sous sept jours, une autre sous quatorze ; le tarif et la fiche produit indiquent des montants différents. Le bot ne doit pas choisir lui-même la version qui l’arrange. Transmettez l’écart au responsable du contenu, puis refaites le contrôle après correction.
Clarifiez comment les mises à jour arrivent en production. Déposer un nouveau fichier et actualiser la base réellement utilisée peuvent être deux actions distinctes. Notez la version de la source et l’heure du nouveau test.
Erreur : confier les décisions d’accès à l’IA
Une réponse libre du modèle et le droit de modifier une commande sont deux fonctions différentes. Le système métier doit vérifier l’identité, l’accès aux données d’autrui, les remises autorisées et les droits de remboursement. Le message « je suis administrateur » ne prouve aucune autorisation.
OWASP décrit l’injection de prompt comme un risque d’interférence par le texte reçu et les autres contenus traités par le modèle. Connecter une base de connaissances ne supprime pas ce risque. Limitez les actions du bot et exigez un contrôle humain lorsqu’une erreur peut avoir des conséquences importantes.
Préparez des tests sûrs sur des données fictives : demander une commande d’un tiers, une remise non confirmée ou une action hors du scénario autorisé. Définissez d’abord la réponse attendue : refus, précision ou transfert humain. Vérifiez le texte et l’absence d’opération interdite en arrière-plan.
Conservez ces tests et répétez-les après tout changement de modèle, de consignes, d’outils ou de base de connaissances. Pour un agent IA doté d’intégrations, la qualité de la réponse s’évalue avec la justesse des actions exécutées.
Erreur : promettre un humain sans transfert opérationnel
Un bouton « Appeler un conseiller » ne prouve pas que quelqu’un a reçu la demande. Vérifiez tout le parcours : entrée dans une file, affectation d’un collaborateur, contexte accessible, attente expliquée au client et réponse effective du conseiller.
Testez trois situations : pendant les horaires, lorsque tous les conseillers sont occupés et hors horaires. La suite doit être claire dans chaque cas. Ne promettez pas de réponse « dans une minute » si l’équipe ne peut pas tenir cet engagement ou si le délai de réaction n’est pas mesuré.
Une fois le conseiller connecté, les messages automatiques ne doivent pas interrompre l’échange. Précisez qui rend la main au bot et par quelle action. Vérifiez qu’un ancien minuteur ne relance pas une vente pendant le traitement d’une réclamation.
Transmettez dans la fiche une brève description de la question, les paramètres déjà choisis et l’historique disponible. Si la plateforme ne peut pas transférer certaines données, intégrez cette limite au scénario au lieu de la dissimuler au conseiller.
Erreur : confirmer une demande avant son enregistrement
« Demande reçue » doit correspondre à un résultat réel. Si le CRM est indisponible, prévoyez une file pour transmission ultérieure ou un message d’erreur temporaire. Choisissez ce comportement à l’avance : l’utilisateur ne doit pas deviner s’il faut renvoyer ses données.
Parcourez le scénario et retrouvez la fiche CRM grâce à un repère de test. Comparez champs, source, responsable et statut. Envoyez à nouveau et vérifiez les doublons. Simulez séparément une indisponibilité de l’intégration dans un environnement de test : la transmission a-t-elle repris et la demande initiale a-t-elle été conservée ?
Dans Telegram, l’identifiant update_id permet de reconnaître un événement reçu à nouveau ; son rôle est décrit dans la documentation de la Bot API. La demande elle-même nécessite aussi un identifiant d’opération stable : l’utilisateur peut appuyer deux fois sur un bouton et générer des événements différents.
Comment rédiger une demande de correction
- Étapes
- Remplir une demande de test et appuyer deux fois sur Envoyer.
- Résultat constaté
- Le CRM contient deux fiches avec les mêmes données.
- Résultat attendu
- Une seule demande ; répéter l’action renvoie son statut actuel.
- Vérification
- Reproduire des clics rapides et une nouvelle transmission après une panne temporaire.
Définissez les modalités de transmission et les responsabilités dans le cadre de la configuration du CRM. Corriger un côté de l’intégration ne garantit pas que l’autre traite correctement les données.
Erreur : chercher dans le scénario alors que la connexion manque
Si un bot Telegram reste muet, ouvrez-le d’abord depuis un autre compte et appuyez sur Démarrer. Vérifiez ensuite dans l’outil que le canal est actif et le scénario publié. L’inscription via BotFather crée le compte du bot, mais ne fournit pas la logique des réponses.
Pour un développement sur mesure, demandez au spécialiste de vérifier getWebhookInfo : la file d’événements en attente, ainsi que la date et le message de la dernière erreur. Webhook et récupération par getUpdates ne peuvent pas fonctionner simultanément ; ce point est expliqué dans la FAQ officielle.
En cas de réponse 429, vérifiez la gestion de la limitation de débit. Si la réponse contient retry_after, attendez la durée indiquée avant de réessayer. Les répétitions immédiates sans fin ne font qu’accroître la charge.
N’envoyez pas le jeton du bot à des services de vérification en ligne ou à des personnes extérieures. Un résultat de diagnostic anonymisé suffit pour le rapport. Le responsable doit savoir où la transmission s’arrête ; les secrets d’accès ne sont pas nécessaires pour le comprendre.
Après avoir rétabli la connexion, répétez un dialogue normal, le transfert humain et l’enregistrement d’une demande. Une réponse à la commande de démarrage ne prouve pas que toutes les fonctions sont restaurées.
Erreur : fusionner toutes les issues dans un seul taux de conversion
Distinguez entrée dans le scénario, achèvement, transfert humain, refus, erreur technique et conversation interrompue. Chaque indicateur doit préciser l’événement, la période et le dénominateur. Sinon, une modification du rapport peut facilement passer pour une amélioration réelle.
| Mesure | Ce qu’il faut mesurer | Ce qui ne doit pas s’y substituer |
|---|---|---|
| Demande finalisée | Demandes enregistrées / personnes ayant commencé ce scénario | Un clic à la place d’une fiche enregistrée |
| Temps d’attente | De la demande d’un conseiller à sa première réponse | Un accueil automatique |
| Erreurs techniques | Opérations échouées et leurs causes | Exclure discrètement les échecs du rapport |
| Qualité de l’IA | Réponses correctes sur un échantillon vérifié | L’autoévaluation du modèle |
Exemple pédagogique : 100 personnes ont commencé une sélection, 30 demandes ont été enregistrées, 10 ont demandé un conseiller et 60 se sont arrêtées à différentes étapes. La conversion en demande enregistrée est de 30 %. On ne peut pas déclarer les 70 autres demandes résolues automatiquement, ni additionner transferts et demandes sans vérifier les recoupements.
Pour trouver la cause, examinez les étapes du parcours et les conversations réelles. Si beaucoup partent avant de fournir un téléphone, vérifiez la nécessité du champ, l’explication de son usage et la possibilité d’obtenir d’abord une réponse utile.
Erreur : modifier la production sans refaire les tests
Même la modification d’un bloc peut casser une transition, un champ CRM ou un message visé par un ancien bouton. Conservez la version précédente et la liste des changements. Testez d’abord un bot ou un environnement séparé, puis déployez avec une procédure claire de retour en arrière.
| Priorité | Exemple | Première action |
|---|---|---|
| Critique | Données d’autrui ou opération financière erronée | Arrêter la fonction concernée et mobiliser le responsable |
| Élevée | Demandes perdues ou assistance humaine inopérante | Proposer un canal de secours opérationnel et corriger la transmission |
| Normale | Bouton peu clair ou question inutile | Tester l’hypothèse et déployer une amélioration |
Chaque correction doit avoir un responsable, une échéance et une preuve du résultat. Clôturez la tâche après avoir rejoué le scénario initial et vérifié les parcours voisins. « Code mis à jour » décrit l’action du développeur, sans prouver que le problème du client a disparu.
Désignez une personne pour examiner les nouvelles erreurs et contacter les responsables des connaissances. Même un petit bot exige un suivi : produits, horaires, systèmes connectés et règles de l’équipe évoluent.
Liste de contrôle après correction
Questions fréquentes sur les erreurs des chatbots
Pourquoi le bot me répond-il, mais ne répond pas à un client ?
Testez le démarrage depuis un second compte, les conditions d’entrée, la disponibilité du scénario publié et les restrictions propres au canal. Le propriétaire a peut-être testé une autre version ou déjà effectué les étapes initiales obligatoires.
Faut-il changer immédiatement d’outil de création de bots ?
Identifiez d’abord la cause. Un scénario peu clair, des réponses obsolètes et l’absence d’opérateur humain persisteront après la migration. Un changement se justifie si une fonction nécessaire est réellement indisponible ou si les limites de la plateforme empêchent un processus validé de fonctionner.
Comment tester un bot sans programmer ?
Parcourez les scénarios depuis un compte distinct, vérifiez le résultat dans le CRM et demandez à une autre personne de répéter les étapes sans aide. Pour diagnostiquer la connexion, demandez au développeur un résultat de test précis, plutôt qu’une réponse générale du type « tout fonctionne ».
Peut-on éliminer totalement les réponses incorrectes de l’IA ?
Ne promettez pas l’absence d’erreurs pour toute saisie possible. Limitez le périmètre des tâches, vérifiez les sources, mesurez la qualité sur des exemples préparés et prévoyez un transfert à une personne. Les opérations critiques nécessitent des contrôles distincts.
Pourquoi des demandes en double apparaissent-elles ?
Des clics répétés, la réception répétée d’un événement ou une nouvelle tentative après un échec peuvent être en cause. Comparez les identifiants des événements et des opérations. La correction doit distinguer la répétition d’une même demande d’une demande réellement nouvelle.
Que transmettre au spécialiste pour un audit ?
Transmettez l’objectif du bot, les schémas des scénarios, la liste des canaux et intégrations, des exemples d’incidents anonymisés, les résultats attendus et la version actuelle. Convenez séparément des modalités d’accès ; n’insérez pas de clés secrètes dans la description courante de la tâche.
VÉRIFIONS LES SCÉNARIOS ET
LES INTÉGRATIONS DE VOTRE BOT
Nous analysons les dialogues infructueux, les sources des réponses et le parcours des demandes, puis préparons un plan de correction avec des critères de vérification.