Fallbacks pour chatbots IA : Détecter et rediriger les lacunes de connaissances en toute sécurité

Un chatbot web n'a pas besoin de répondre à chaque question. L'essentiel est qu'il reconnaisse les moments où sa base de connaissances ne fournit pas une fondation fiable, et qu'il reste utile pour les visiteurs. Combler une lacune par une supposition plausible crée un problème de confiance : un délai de livraison erroné, une règle de produit inventée ou une consigne de support inadaptée peuvent engendrer plus de travail qu'une limite claire et concise.

Pourquoi l'absence de résultats est un problème produit à part entière

Dans le cas d'un chatbot IA adossé à une base de connaissances, l'absence de réponse peut résulter d'au moins trois causes distinctes. Premièrement, l'information peut être réellement manquante. Deuxièmement, elle peut exister, mais rester introuvable en raison de la langue, de la formulation, des métadonnées ou du classement. Troisièmement, elle est bien accessible, mais ne suffit pas pour fournir une réponse sûre. Ces cas de figure se ressemblent dans le chat, mais nécessitent des actions opérationnelles différentes.

Les systèmes de retrieval n'évaluent pas automatiquement si une réponse est acceptable d'un point de vue business. La documentation officielle sur la Retrieval-Augmented Generation dans Azure AI Search décrit comment combiner la recherche textuelle et vectorielle pour fournir des sources à une réponse. Cette combinaison améliore la recherche, mais ne remplace pas une règle définissant le moment où un résultat est jugé suffisant. C'est pourquoi un chatbot doit prendre une décision clairement définie avant la génération de texte : répondre, poser une question de clarification ou rediriger en toute sécurité.

Une « non-réponse » n'est pas une impasse vide

Une réponse de fallback exploitable ne se contente pas de dire : « Je n'ai pas d'information à ce sujet ». Elle repose sur quatre piliers : nommer la limite sans prétextes techniques, éviter toute affirmation non vérifiée, proposer une clarification précise ou une alternative sûre, et indiquer si nécessaire la voie vers un interlocuteur humain. La tonalité peut être amicale, mais elle ne doit pas masquer l'incertitude.

• Limite : « Je ne trouve pas d'information fiable à ce sujet dans les données validées. »
• Contexte : « S'agit-il d'une commande, d'un contrat ou d'une configuration technique ? »
• Prochaine étape : « Si vous me donnez la référence du produit, je peux vérifier à nouveau les documents disponibles. »
• Handoff : « Pour une vérification définitive, nous transmettons votre demande à l'équipe compétente. »

Ainsi, le chat reste utile sans inventer de prix, de délais, d'effets juridiques ou d'engagements. La règle du handoff doit intervenir délibérément plus tôt lors du traitement de données personnelles, de paiements, d'offres individuelles ou de questions relatives à la sécurité. Le guide déjà publié sur le Human Handoff dans le support web aide à concevoir le transfert comme un processus clair plutôt que comme une issue de secours.

Opérationnaliser la décision avant la réponse

Les équipes ne devraient pas adopter un seuil magique issu d'une démo. Le score d'un moteur de recherche n'est qu'un signal et peut varier en fonction de l'index, du modèle, de la langue et du mélange de requêtes. La documentation du Semantic Ranking rappelle que la distribution des scores de re-classement (reranker) peut fluctuer. C'est pourquoi un seuil doit toujours correspondre à un jeu de données testé et à une catégorie d'erreur concrète.

Une décision adaptée à la pratique peut combiner plusieurs vérifications. Existe-t-il au moins une source dans un domaine de contenu autorisé ? Correspond-elle à la langue et à la version actuelle du produit ou du contrat ? Contient-elle une justification directe pour la réponse planifiée ? Les meilleurs résultats sont-ils contradictoires ? C'est seulement lorsque ces critères sont suffisamment remplis que le générateur est autorisé à formuler une réponse. Dans le cas contraire, le bot pose une question ciblée ou bascule vers le fallback.

Exemple : Information de livraison ferme

Si une personne demande la date de livraison d'un produit précis, un article général sur les expéditions ne suffit pas. Le bot peut expliquer qu'il ne trouve pas d'information ferme, demander le numéro de commande ou la variante du produit, et renvoyer vers le support. En revanche, une réponse comme « Votre colis arrive demain » ne serait pas couverte par la base de connaissances. Le même principe s'applique aux garanties, résiliations, questions de santé et accès aux comptes : plus le dommage potentiel est élevé, plus la preuve doit être solide.

Tester le retrieval avant de réécrire le contenu

Une non-réponse constitue souvent un excellent signal de mesure. Avant qu'une équipe ne rédige un nouveau prompt, elle doit analyser l'ensemble de la chaîne : question d'origine, langue détectée, requête de recherche normalisée, filtres appliqués, meilleurs résultats, versions de sources utilisées et issue choisie. On découvre ainsi si un document est manquant ou si la recherche passe à côté.

1. Classer l'intention de la question de manière anonymisée (ex. produit, support, compte ou juridique).
2. Mettre en regard les sources attendues et les résultats réellement extraits.
3. Journaliser les filtres de langue, de validité, d'accès et de version produit.
4. Vérifier si les premiers résultats étayent réellement la question ou contiennent simplement des termes similaires.
5. Marquer le cas comme une lacune documentaire, un problème de retrieval, une règle de sécurité ou un handoff légitime.

Un petit Golden Set composé de questions réelles et nettoyées au préalable convient parfaitement à ces comparaisons. L'article sur la mesure de la qualité des réponses d'un chatbot IA explique pourquoi les questions critiques ou rares ne doivent pas être noyées dans une moyenne. Ajoutez-y délibérément des questions sans réponse correspondante dans vos données. C'est le seul moyen de vérifier si le chatbot réagit de façon maîtrisée face à ce qu'il ignore.

Traduire les lacunes de connaissances en workflow éditorial

Un seul échange dans le chat ne justifie pas la création d'une nouvelle FAQ. En revanche, plusieurs fallbacks sécurisés similaires indiquent qu'une information importante est manquante ou difficile à trouver. Une liste sobre en données suffit : intention, classe d'erreur, langue concernée, identifiants des sources existantes et statut. Les historiques complets de conversation, les noms ou les données de compte n'ont pas leur place sur un tableau d'analyse général.

L'expert métier responsable décide ensuite s'il faut compléter une FAQ, préciser une page produit, améliorer des métadonnées ou ajuster le texte du handoff. Chaque ajout nécessite un responsable, une source et une date. Pour les informations sensibles au facteur temps (disponibilités, promotions), l'ajout d'une date d'expiration est recommandé. L'équipe évite ainsi qu'un article bien intentionné ne devienne lui-même la prochaine source obsolète.

Ne pas utiliser le taux d'hallucination comme unique KPI de qualité

Un faible taux d'erreurs visibles peut être trompeur si le bot esquive trop souvent les questions. Inversement, un taux de réponse élevé n'est pas un succès si les réponses ne sont pas appuyées par leurs sources. Il est préférable de privilégier un ensemble restreint d'indicateurs : part de demandes traitées avec certitude, part de fallbacks motivés, taux de handoff par intention, délai avant décision métier, lacunes récurrentes et résultats d'échantillonnages manuels. L'évaluation doit pouvoir être segmentée par langue, domaine produit et classe de risque.

Le NIST AI Risk Management Framework recommande de gérer les risques en contexte et d'ancrer des processus de mesure et de gestion. Pour les équipes web, cela ne signifie pas enregistrer chaque conversation, mais disposer de responsabilités claires et de critères vérifiables pour des réponses sûres.

L'évaluation doit également correspondre à des situations d'utilisation réelles. Une question courte sur smartphone contient souvent moins de contexte qu'une requête détaillée sur ordinateur. Les fautes de frappe, les abréviations de produits et les mélanges de langues sont des saisies attendues, pas des exceptions. Ne vous limitez pas à tester la question idéalement formulée : testez des variantes sans numéro de commande, avec plusieurs noms de produits ou avec des indications temporelles floues. Chaque variante doit déclencher soit une réponse étayée, soit une clarification pertinente, soit un handoff sécurisé. Un fallback qui ne fonctionne que sur des questions de test parfaites ne protège pas dans la réalité du quotidien.

Le retour du support est tout aussi crucial. Lorsque les collaborateurs répondent à une demande transmise, ils peuvent catégoriser brièvement le motif : information manquante, information obsolète, accès nécessaire ou décision individuelle requise. Ces catégories relient le site web, la rédaction de la base de connaissances et le service client, sans transformer l'utilisateur en sujet d'analyse. Un coup d'œil mensuel sur les catégories les plus fréquentes suffit généralement à planifier des améliorations prioritaires.

Check-list pour un fallback sécurisé

• Les réponses n'apparaissent qu'avec des sources adaptées, validées et à jour.
• Les seuils et combinaisons de signaux ont été vérifiés à l'aide d'un Golden Set.
• Les classes de risque élevé disposent de leurs propres règles de clarification et de transfert humain.
• Les textes de fallback expliquent la limite sans prétextes techniques internes ni fausse certitude.
• Les journaux ne contiennent que les informations de diagnostic strictement nécessaires.
• Les cas récurrents se voient attribuer un responsable et un statut d'amélioration vérifiable.
• Les nouvelles sources sont re-vérifiées avant validation, après modification et à leur expiration.

Conclusion : Des limites honnêtes améliorent la qualité des réponses

Un chatbot IA professionnel ne répond pas au plus grand nombre de questions possible, mais uniquement à ce que sa base de connaissances vérifiée permet de soutenir. La meilleure réponse de fallback est concrète, utile et transmet les demandes engageantes sans friction. Lorsque les équipes traitent les cas de non-réponse comme des données de test et des signaux éditoriaux, le retrieval ainsi que les contenus s'améliorent de manière mesurable. Commencez avec dix questions clés, dix questions volontairement sans réponse et un processus de handoff clair par classe de risque. Vous poserez ainsi une base solide avant de confier plus de responsabilités au chatbot.

Sources

• Microsoft Learn : RAG et IA générative dans Azure AI Search
• Microsoft Learn : Vue d'ensemble du Semantic Ranking
• Microsoft Learn : Créer une requête de recherche textuelle
• NIST : Cadre de gestion des risques liés à l'IA