Tester le routage d’un chatbot IA : erreurs, handoff et comparaison des locales

Un chatbot de site web peut lancer de nombreuses conversations et pourtant les router de manière incorrecte. Un nombre élevé de leads, de sessions résolues ou de transferts en dit peu sur le fait que la décision correspondante était correcte sur le plan métier. Peut-être qu’une simple question de support a été interprétée comme une intention d’achat, qu’un prospect sérieux est resté bloqué dans une boucle de FAQ ou qu’un transfert souhaité a abouti auprès de la mauvaise équipe.

Quiconque souhaite tester le routage d’un chatbot IA a donc besoin de plus qu’un tableau de bord KPI général. Les éléments décisifs sont des parcours attendus vérifiables, des classes d’erreurs clairement nommées, des événements tout au long de l’entonnoir et des échantillons réguliers de conversations à examiner. Ce guide présente une mise en place pratique pour les équipes web, support, marketing et produit.

Pourquoi la qualité du routage est une tâche de mesure à part entière

Le panorama existant des KPI de chatbot IA explique comment le taux de résolution, la qualité des leads et le ROI sont liés. Pour l’amélioration opérationnelle, il faut toutefois mesurer un niveau plus bas : le parcours sélectionné était-il correct pour la demande concrète ?

Un chatbot peut marquer une session comme « résolue » sur le plan formel alors que la réponse passait à côté de la demande. À l’inverse, un transfert vers un humain peut être exactement le résultat souhaité et économiquement pertinent. La qualité du routage n’évalue donc pas s’il y a le moins de transferts possible, mais si la réponse, la qualification, le support, le handoff ou le refus sont adaptés à la situation.

Définir d’abord les parcours attendus et les classes d’erreurs

Avant de créer des événements ou des tableaux de bord, chaque demande pertinente a besoin d’un parcours cible attendu. Une matrice de routage simple suffit souvent : question produit, intention d’achat, client existant ayant un problème, souhait de parler à un humain et demande non prise en charge. La qualification multilingue des leads montre quelles questions et quels transferts peuvent se trouver derrière ces parcours.

Faux positif : le chatbot détecte un lead alors qu’il n’y en a aucun

Un faux positif survient par exemple lorsque « Combien coûte la livraison ? » lance immédiatement un parcours de lead ou qu’une cliente existante est à nouveau enregistrée comme nouveau contact. Cela pèse à la fois sur les équipes commerciales et sur les utilisateurs. Mesurez donc combien de conversations routées comme leads par le chatbot sont ensuite jugées non pertinentes par les équipes commerciales ou lors de la revue.

Faux négatif : un intérêt réel n’est pas reconnu

Un faux négatif existe lorsqu’une intention d’achat concrète se termine par une réponse générale, sans proposer de possibilité de contact adaptée. Cette erreur est plus difficile à voir dans le tableau de bord, car aucun événement de lead n’a été déclenché. Elle est surtout détectée au moyen de cas de test, par la recherche de motifs dans les échantillons et par la comparaison avec des canaux de contact ultérieurs.

Erreur de handoff : transfert déclenché, mais non abouti

Les handoffs présentent eux aussi plusieurs profils d’erreur : escalade trop précoce, souhait de parler à un humain non pris en compte, transfert vers la mauvaise équipe ou handoff initié techniquement sans acceptation. L’article sur le handoff humain dans le chatbot IA décrit les critères métier ; les analytics doivent ensuite montrer si le processus a réellement été mené à terme.

Un Golden Set pour le routage, et pas seulement pour les réponses

Le Golden Set pour la qualité des réponses peut être étendu aux attentes de routage. Google Cloud documente, pour les cas de test Dialogflow, entre autres des attentes concernant les intents reconnus, les pages actives, les flows et les outils. Le principe est également utile indépendamment d’un fournisseur concret : un cas de test ne décrit pas seulement la réponse attendue, mais le parcours attendu.

Chaque cas de test de routage devrait contenir au minimum :

• une saisie utilisateur réelle ou formulée de manière réaliste, sans données à caractère personnel ;
• la locale, le canal et le contexte de conversation nécessaire ;
• la demande attendue et une classification alternative autorisée ;
• le parcours cible attendu : réponse, support, qualification, handoff ou refus ;
• les questions de clarification et les champs de données autorisés ;
• le motif de handoff attendu et l’équipe cible ;
• la gravité de l’erreur et la personne responsable de la validation métier.

Intégrez des cas clairs, des formulations ambiguës, des fautes de frappe, des négations et des cas limites. « Je ne veux pas d’offre, seulement le délai de livraison » est souvent plus précieux pour la détection des leads qu’une demande de démo formulée idéalement.

Matrice de confusion : lire concrètement précision et rappel

Le NIST AI Risk Management Framework recommande d’associer l’exactitude à des ensembles de test réalistes, représentatifs de l’utilisation attendue, et d’évaluer séparément les résultats pour différents segments. Il mentionne explicitement les taux de faux positifs et de faux négatifs comme mesures pertinentes. Pour le routage des chatbots, on peut en déduire une petite matrice de confusion.

• Précision des leads : part des leads correctement détectés parmi toutes les conversations que le chatbot a routées comme leads.
• Rappel des leads : part des vrais leads détectés parmi toutes les conversations ayant réellement un intérêt d’achat dans l’échantillon vérifié.
• Mauvais routage support : part des demandes de clients existants qui aboutissent à tort dans le parcours commercial.
• Taux de correspondance du handoff : part des cas où le motif de transfert attendu et l’équipe cible sont corrects.

Aucun indicateur isolé ne suffit. Une précision très élevée peut résulter de règles trop prudentes qui ignorent de nombreux leads réels. Un rappel élevé peut à l’inverse se payer par trop de faux positifs. Définissez donc, pour chaque classe d’erreur, un seuil acceptable et un niveau d’urgence différent.

De la conversation à un entonnoir de handoff mesurable

Un entonnoir doit rendre visible le chemin de décision, et non collecter l’intégralité du contenu de la conversation. Des événements techniques pertinents sont par exemple chat_started, intent_detected, route_selected, qualification_started, handoff_offered, handoff_requested, handoff_accepted, handoff_completed, lead_submitted et route_corrected.

Pour chaque événement, une ID de session pseudonyme, la locale, la classe d’intent détectée, le parcours choisi, le motif de résultat, le canal de handoff et la version du bot suffisent généralement. Les transcriptions brutes n’ont pas automatiquement leur place dans chaque système d’analytics. Ceux qui utilisent Google Analytics peuvent en outre rattacher les résultats métier finalisés à des événements de lead recommandés comme generate_lead, qualify_lead ou disqualify_lead. Les explorations d’entonnoir aident ensuite à analyser les abandons entre les étapes définies.

Un handoff accepté est plus important qu’un handoff déclenché

Dans ses analytics d’agents, Microsoft distingue notamment les sessions résolues, escaladées et abandonnées, ainsi que les escalades intentionnelles, non intentionnelles et demandées par l’utilisateur. Cette séparation est utile pour votre propre logique de mesure. Un événement de handoff déclenché ne prouve pas encore qu’un humain a pris le relais.

Consignez donc au minimum l’offre, la demande, l’acceptation et la clôture séparément. Le taux d’acceptation du handoff est la part des transferts acceptés parmi les transferts demandés. Le taux de clôture du handoff examine si, après l’acceptation, un résultat traçable a été enregistré. Vérifiez en plus le temps d’attente, l’abandon avant acceptation, la mauvaise équipe cible et les réacheminements.

Comparer les locales sans tomber dans le piège du classement

Les problèmes de routage peuvent être spécifiques à une langue. Un bref souhait d’achat en allemand peut sembler univoque, tandis qu’une formulation polie et indirecte dans une autre langue est trop tôt classée comme non engageante. Comparez donc la précision, le rappel, l’acceptation du handoff et l’abandon par locale, mais jamais sans volume de cas ni mix de trafic.

• Utilisez les mêmes scénarios métier de base pour chaque locale.
• Ajoutez des synonymes, des formules de politesse et des négations naturels localement.
• Séparez les erreurs linguistiques des offres, horaires d’ouverture ou canaux de contact divergents.
• N’évaluez pas de petits échantillons comme un classement fiable.
• Examinez les segments atypiques à partir de conversations concrètes et anonymisées.

Combiner monitoring de production et tests de régression

Les tests hors ligne et les métriques live répondent à des questions différentes. Le Golden Set montre, avant une modification, si les parcours connus continuent de fonctionner. Les données de production révèlent de nouvelles formulations, des thèmes saisonniers et des changements de comportement non intentionnels. Google Cloud décrit les cas de test enregistrés et les tests continus comme un moyen de rendre visibles les régressions sur les intents, les flows et les transitions.

Un rythme praticable consiste à réaliser des tests avant chaque modification pertinente, à mener une revue hebdomadaire des mauvais routages remarquables et à comparer les seuils une fois par mois. Ne déclenchez pas d’alerte à chaque fluctuation, mais en cas d’écarts nets par rapport à une base de référence documentée, par exemple une forte hausse des handoffs non intentionnels dans une locale donnée.

Planifier des analytics sobres en données

Les analytics de routage peuvent contenir des données à caractère personnel, en particulier lorsque des transcriptions, des coordonnées ou des résultats CRM sont reliés. La Commission européenne résume notamment les principes du RGPD en termes de limitation des finalités, de minimisation des données, de limitation de la conservation ainsi que d’intégrité et de confidentialité. En pratique, cela signifie : nommer les finalités, ne collecter que les champs d’événements nécessaires, limiter les accès et définir des intervalles de suppression ou de contrôle.

Des indicateurs agrégés et des événements pseudonymes suffisent pour de nombreuses questions de routage. Les textes complets ne devraient être utilisés que dans le cadre d’un processus de revue justifié et protégé. La base juridique et la durée de conservation adaptées à chaque cas doivent être vérifiées par des personnes compétentes ; cet article ne constitue pas un conseil juridique.

Un plan de démarrage en 14 jours

1. Jour 1–2 : Définir les cinq demandes principales et leurs parcours attendus.
2. Jour 3–4 : Définir les faux positifs, les faux négatifs et les erreurs de handoff avec leur niveau de gravité.
3. Jour 5–6 : Ajouter pour chaque parcours au moins des cas de test clairs, ambigus et négatifs.
4. Jour 7 : Documenter les noms d’événements, les propriétés autorisées et les limites de protection des données.
5. Jour 8–9 : Vérifier l’entonnoir du début de la conversation jusqu’au handoff accepté ou à la demande qualifiée.
6. Jour 10–11 : Créer une première matrice de confusion pour chaque locale importante.
7. Jour 12 : Examiner éditorialement dix sessions remarquables et marquer les causes.
8. Jour 13–14 : Déployer un changement ciblé, exécuter à nouveau le Golden Set et surveiller les valeurs live.

Liste de contrôle pour un routage fiable

• Les parcours attendus et les équipes cibles sont documentés sur le plan métier.
• Les faux positifs et les faux négatifs sont mesurés séparément.
• L’offre, la demande, l’acceptation et la clôture du handoff sont des étapes distinctes.
• La précision et le rappel ne sont pas interprétés sans taille d’échantillon.
• Les segments par locale disposent de cas de test naturels et validés éditorialement.
• Les tests de régression s’exécutent avant les modifications ; des revues live ont lieu régulièrement.
• Les analytics ne collectent que les données nécessaires à la finalité définie.

Conclusion

Un bon routage de chatbot IA ne se reconnaît pas au plus grand nombre possible de leads ni au plus petit nombre possible de handoffs. Il se reconnaît au fait que les demandes arrivent de manière fiable à l’étape suivante appropriée. Avec des parcours attendus, une matrice de confusion du routage, un entonnoir de handoff complet et des revues spécifiques aux locales, on obtient un système de mesure qui explique les erreurs et permet des améliorations concrètes.

Commencez petit : cinq parcours, un Golden Set maîtrisable et quelques événements clairement définis. L’analytics de chatbot générale devient ainsi un processus qualité robuste pour le support, les ventes et l’expérience utilisateur.

Sources

• NIST : Cadre de gestion des risques liés à l’intelligence artificielle (AI RMF 1.0)
• Google Cloud : cas de test Dialogflow CX
• Google Cloud : tests continus et déploiement
• Microsoft Learn : vue d’ensemble de l’analytics de Copilot Studio
• Microsoft Learn : analyser les agents conversationnels
• Google Analytics : rapport sur un formulaire de génération de leads
• Google Analytics : audiences suggérées pour la génération de leads
• Commission européenne : principes du traitement des données à caractère personnel au titre du RGPD