Détecter les lacunes de connaissances d'un chatbot IA : résoudre systématiquement les questions sans réponse

Un chatbot de site web ne peut répondre de manière fiable que s'il dispose d'informations pertinentes, validées et faciles à trouver. En pratique, les lacunes de connaissances prennent rarement la forme d'un rapport structuré. Elles se nichent dans des réponses de secours (fallback) sécurisées, des relances répétées, des transferts inutiles vers des agents humains ou des réponses d'apparence plausible mais sans source fiable. Se contenter d'observer le nombre de questions sans réponse revient donc à ne voir qu'une partie du problème.

Un processus efficace associe donc données d'exploitation, examen éditorial et tests. L'objectif n'est pas de copier immédiatement chaque formulation inhabituelle dans la base de connaissances. Il s'agit d'identifier les besoins d'information récurrents, d'en déterminer la cause et de ne valider que les réponses dont la responsabilité métier peut être assumée. Ce guide propose une démarche pragmatique pour les équipes support, contenu et produit.

Qu'est-ce qu'une lacune de connaissances dans un chatbot IA ?

Une lacune de connaissances survient lorsqu'une question légitime d'un utilisateur, située dans le périmètre prévu, ne peut être répondue de manière fiable par une affirmation validée. Cela peut signifier que l'information est totalement absente. Plus souvent, elle existe mais elle est obsolète, trop générale, inadaptée sur le plan linguistique, impossible à explorer (crawl) ou introuvable lors de la recherche documentaire (retrieval). Des sources contradictoires constituent également une lacune : le chatbot possède alors un savoir trop ambigu plutôt qu'insuffisant.

Ce concept ne doit pas être assimilé à n'importe quelle situation de No-Match. Pour Dialogflow CX, Google documente des événements No-Match intégrés lorsque les saisies ne correspondent à aucune intention (intent). Microsoft évoque quant à lui des « unrecognized utterances » dans ses analyses Copilot Studio, c'est-à-dire des formulations qui ne déclenchent aucun sujet spécifique. Ces signaux constituent des points de départ utiles, mais ne prouvent pas encore qu'un nouveau contenu soit nécessaire. La question était peut-être hors périmètre, la formulation ambiguë ou la source existante simplement non trouvée.

Quels signaux intégrer dans l'analyse des lacunes ?

Fallbacks sécurisés et questions sans réponse

L'indice le plus évident est une réponse de type « Je ne dispose pas d'informations fiables à ce sujet ». Ce fallback sécurisé vaut mieux qu'une affirmation inventée, mais doit être enregistré comme un événement contrôlable. Le texte exact de la question n'est pas le seul élément pertinent : la langue, la page concernée, l'horodatage, le périmètre sélectionné et la suite de l'échange le sont aussi. Les données à caractère personnel ou confidentielles ne doivent pas être intégrées sans filtrage préalable dans un système éditorial.

Faible niveau de confiance et manque de sources

Une réponse fournie par le système peut également révéler une lacune de connaissances. C'est le cas en l'absence de sources, lors d'un résultat de recherche (retrieval) peu pertinent, en présence de multiples résultats contradictoires ou si la réponse ne couvre qu'une partie de la question. Le score technique de confiance (confidence) ne suffit pas à lui seul pour juger : les seuils varient selon le modèle, le système et le niveau de risque. L'élément décisif reste la capacité de l'équipe à vérifier et valider l'affirmation à partir d'une source autorisée.

Relances répétées, abandons et transferts (handoffs)

Lorsque les utilisateurs reformatent la même question, insistent à plusieurs reprises ou demandent immédiatement un conseiller humain, il est probable que la première réponse n'ait pas répondu à leur besoin. Il en va de même pour un nombre anormalement élevé d'abandons de conversation après un sujet précis. Ces parcours doivent être analysés dans leur contexte. Un transfert vers un agent (handoff) peut être la solution appropriée, notamment pour des décisions au cas par cas, des réclamations ou des données sensibles. Il ne s'agit pas automatiquement d'une erreur de contenu.

Différences selon la langue (locale) et le canal

Une réponse en allemand peut fonctionner correctement alors que la version française est manquante ou utilise une désignation de produit différente. De même, les questions posées sur une page de tarifs peuvent être formulées différemment de celles du centre d'aide. C'est pourquoi les regroupements doivent pouvoir être examinés au moins par langue (ou locale) et par contexte d'utilisation. Un résumé global risquerait autrement de masquer une lacune ciblant une localisation spécifique.

Du signal brut au backlog de contenu priorisé

Un processus rationalisé empêche l'équipe de collecter des transcriptions au hasard ou de surévaluer des observations isolées. Les sept étapes suivantes peuvent être réalisées chaque semaine, ou plus fréquemment en cas de volume important.

1. Définir la collecte : Déterminez quels événements doivent être considérés comme candidats : fallback sécurisé, absence de source fiable, relance répétée, avis négatif, transfert humain inutile ou fausse affirmation signalée. Documentez également les données qui ne sont volontairement pas enregistrées.
2. Nettoyer les contenus : Supprimez ou masquez les données à caractère personnel, les numéros de commande, les coordonnées et les textes libres inutiles pour l'analyse. Le guide sur l'analyse de chatbot IA sobre en données (datensparsame Chatbot-Analytics) montre comment planifier séparément les événements, l'échantillonnage et la conservation.
3. Normaliser les questions : Regroupez les formulations ayant le même sens sans perdre les nuances importantes. « Combien de temps ai-je pour retourner un article ? » et « Quel est le délai de retour ? » appartiennent probablement au même cluster ; « Puis-je retourner un produit personnalisé ? » peut nécessiter sa propre règle.
4. Classifier la cause : Distinguez un contenu manquant, une source obsolète, un problème de recherche ou de structure, une politique peu claire, une lacune liée à la locale, un périmètre volontairement exclu ou une décision humaine nécessaire. Ce diagnostic détermine l'action à entreprendre.
5. Définir la priorité : Évaluez la fréquence, l'impact utilisateur, la pertinence commerciale et le risque. Une remarque rare concernant une restriction critique en matière de sécurité peut s'avérer plus importante qu'une question fréquente relevant de la discussion générale (smalltalk). La méthode d'évaluation doit être claire et vérifiable pour votre entreprise, sans être mathématiquement complexe.
6. Attribuer la responsabilité des sources : Chaque réponse prévue nécessite une source autorisée ainsi qu'une personne ou un rôle habilité à valider son contenu. Si l'un de ces éléments manque, l'entrée reste ouverte ; un modèle linguistique ne doit pas inventer une politique d'entreprise. Un modèle opérationnel adapté est décrit dans le guide sur la gouvernance de contenu pour chatbots IA.
7. Créer un test de recette : Enregistrez des questions représentatives, les messages clés attendus, les sources autorisées et le comportement prévu hors périmètre. Après chaque modification, vérifiez si la lacune est comblée et si les réponses existantes restent stables.

Quels champs doit contenir une bonne entrée de backlog ?

Un ticket intitulé « Le chatbot ne connaît pas le délai de retour » est trop sommaire. Il risque de déboucher sur un texte qui répond à la demande d'exemple sans prendre en compte les variantes, les exceptions ou les responsabilités. Une entrée exploitable contient au minimum :

• un sujet de cluster neutre et deux à cinq exemples de questions anonymisées,
• la locale, le contexte de la page et le parcours utilisateur concerné,
• le comportement observé et le comportement souhaité,
• la catégorie de cause et la priorité motivée,
• l'URL de la source autorisée ou le statut « source manquante »,
• la responsabilité métier (ownership), le rôle de révision et l'échéance cible,
• la date de validité, les exceptions connues et le comportement de transfert souhaité,
• les cas de test et des critères de recette mesurables.

Une simple observation de conversation devient ainsi une unité de travail éditoriale. De plus, cela permet de vérifier si le problème peut réellement être résolu par du contenu. Un problème technique de recherche (retrieval) relève par exemple de l'équipe recherche ou plateforme, tandis qu'une règle de retour non clarifiée relève du service métier responsable.

Exemple pratique : traiter correctement les questions sur les retours

Imaginons que des utilisateurs posent de manière répétée des questions sur le retour de produits personnalisés. Le chatbot indique tantôt le délai général, tantôt une exclusion incertaine, et transfère parfois la demande au support. L'équipe ne doit pas déduire une nouvelle règle à partir des réponses précédentes. Il convient d'abord de clarifier quelle politique validée s'applique, pour quels pays et groupes de produits elle est valable, et à quel moment un examen au cas par cas est nécessaire.

Ensuite, une source structurée est créée avec une règle générale, des exceptions clairement identifiées, un champ d'application et un critère d'escalade. Les cas de test couvrent des questions directes, des variantes familières, une autre locale et un cas limite volontairement non automatisable. Pour ce cas limite, un transfert vers un agent humain (Human Handoff) transparent est attendu, plutôt qu'une réponse en libre-service forcée.

Pourquoi plus de contenu n'est pas automatiquement préférable

Une erreur fréquente consiste à répondre à chaque cluster par une nouvelle FAQ. Cela peut générer des doublons, des contradictions et dégrader les résultats du retrieval. Avant de créer un nouveau contenu, vérifiez si une page existante doit être complétée, mieux structurée ou retirée du périmètre d'exploration (crawl). Le processus de maintien d'une base de connaissances à jour aide à la sélection des sources, à la fréquence de crawl et au contrôle des contenus obsolètes (stale content).

Il est tout aussi risqué de reprendre sans vérification de vraies formulations d'utilisateurs comme données d'entraînement ou de test. Google souligne dans ses recommandations de conception que l'ajout aveugle de saisies No-Match peut entraîner un biais d'intention (intent bias) indésirable. Seule l'analyse des causes permet de décider si une formulation doit être ajoutée, une formulation existante nettoyée ou une intention en concurrence erronée corrigée.

Boucler la boucle grâce aux tests de régression

Une lacune n'est pas considérée comme comblée dès qu'un nouveau texte est publié. Elle l'est lorsque des questions représentatives dans le contexte prévu affichent le comportement attendu. Google décrit des cas de test comportant des attentes au niveau de la conversation ou du tour de parole (turn) et une comparaison avec un cas de référence (Golden Case). Pour les chatbots de site web, ce principe s'applique indépendamment du modèle : la question, le message clé attendu, la source autorisée, le transfert requis et les affirmations interdites sont documentés.

Un jeu de tests restreint et bien entretenu a plus de valeur qu'une vaste collection non vérifiée. Intégrez les lacunes confirmées dans le jeu de référence (Golden Set) existant et réexécutez les cas pertinents après toute modification de contenu, de prompt, de modèle ou de recherche (retrieval). Le guide détaillé sur la mesure de la qualité des réponses des chatbots IA approfondit ce processus de révision.

Quels indicateurs montrent les progrès accomplis ?

Ne vous contentez pas de suivre un taux de fallback global. Un ensemble restreint d'indicateurs est bien plus parlant : nombre de clusters priorisés ouverts, délai de clarification métier, proportion d'entrées du backlog disposant d'une source autorisée, réussites aux tests de régression et réapparition de lacunes après validation. Segmentez les résultats par locale et par parcours d'utilisation principal, sans analyser les petits groupes de façon trop détaillée afin de ne pas rendre des personnes indirectement identifiables.

Microsoft répertorie les expressions non reconnues et les sujets à faible taux de résolution comme des signaux d'optimisation potentiels. De son côté, le NIST souligne dans son AI Risk Management Framework l'importance d'une surveillance continue, de jeux de tests documentés, des retours d'expérience et de l'observation du comportement en production. Il en découle une règle de travail fondamentale : les indicateurs doivent soutenir la prise de décision, mais ne remplacent pas l'examen métier d'une source d'information.

Check-list hebdomadaire pour les équipes support et rédaction

• Collecter les nouveaux candidats de manière sobre en données et éliminer les abus manifestes.
• Regrouper les questions synonymes par locale et enrichir les clusters existants.
• Confirmer la cause, l'impact et le risque pour les clusters les plus importants.
• Rechercher les sources existantes, signaler les contradictions et clarifier la responsabilité du contenu.
• Ne publier que des modifications validées ; maintenir le périmètre (scope) et le transfert (handoff) explicites.
• Exécuter des cas de test représentatifs et documenter les résultats.
• Après quelques jours d'utilisation, vérifier si le cluster réapparaît ou s'il a simplement changé de forme.

Conclusion : les lacunes de connaissances forment une boucle éditoriale

Les questions sans réponse ne deviennent précieuses que si l'équipe les traite non pas comme de vagues journaux de chat, mais comme des indices vérifiables. Collecter, nettoyer, regrouper, déterminer la cause, prioriser, valider la source et tester : ce cycle vertueux relie la réalité du support à une base de connaissances fiable. Il ne réduit pas chaque transfert et ne répond volontairement pas à chaque question de façon automatisée. En revanche, il clarifie là où le chatbot peut aider en toute fiabilité – et là où une limite nette offre une meilleure expérience utilisateur.

Sources

• Microsoft Learn: Measure and improve agent performance with KPIs and analytics
• Google Cloud : gestionnaires d'état Dialogflow CX et événements No-Match
• Google Cloud: General agent design best practices
• Google Cloud: Dialogflow CX Test cases
• NIST AIRC: AI Risk Management Framework Core