Un client écrit : « Vous m’avez dit que l’annulation était gratuite jusqu’à 48 heures avant. Mon offre dit autre chose. »
Le collaborateur ouvre le transcript. La réponse du chatbot est nette, polie, convaincante. Mais il ne voit ni le document utilisé, ni sa version, ni le passage qui a servi de base.
Ce n’est pas forcément un problème de données anciennes. Deux documents parfaitement actuels peuvent s’appliquer à deux situations différentes.
C’est là que la traçabilité de la réponse devient utile. Le terme technique est provenance : pouvoir reconstruire sur quoi l’IA s’est appuyée pour formuler une affirmation.
Fraîcheur et provenance ne répondent pas à la même question
La fraîcheur demande : cette information est-elle encore valide ? La provenance demande : d’où vient cette information et pourquoi a-t-elle été appliquée ici ?
Une politique modifiée hier peut ne pas s’appliquer à un contrat signé l’an dernier. À l’inverse, un ancien document peut rester la référence valable pour un client particulier.
Le standard W3C PROV décrit la provenance comme les informations concernant les entités, activités et personnes impliquées dans la production d’une donnée. Une PME n’a pas besoin d’implémenter toute l’ontologie W3C. Elle peut reprendre la logique essentielle.
Pour une réponse de chatbot, il est utile de conserver : l’identifiant de la source, sa version, le passage utilisé, son périmètre, le moment du retrieval et le contexte d’autorisation.
Fait confirmé : la famille W3C PROV fournit un modèle standard pour représenter et échanger des informations de provenance.
Recommandation : pour les réponses qui engagent le client, garder au minimum la source, la version et le passage pertinent dans le trace interne, même si l’interface client n’affiche qu’une référence courte.
Toutes les réponses n’ont pas besoin de cinq citations
Un client qui demande les horaires peut recevoir une réponse simple. Un message « merci » n’a besoin d’aucune source.
La traçabilité devient importante lorsqu’une réponse peut créer une attente ou un désaccord : prix, annulation, garantie, disponibilité, remboursement, délai, conditions de contrat, droit à une prestation ou périmètre du service.
Dans ces cas, le chatbot peut passer en mode preuve.
Le message visible reste naturel : « Selon nos conditions d’annulation, version du 12 août 2026… ». Une petite référence suffit. En interne, on garde davantage : document ID, section, timestamp, autres résultats pertinents et contexte du compte client.
Attention aux sources internes. Si l’utilisateur n’a pas le droit de voir un document, la citation ne doit pas le révéler. La provenance complète le contrôle d’accès ; elle ne le remplace pas.
Deux sources crédibles qui se contredisent sont plus dangereuses qu’une source absente
Dans une entreprise, la base documentaire parfaite n’existe presque jamais.
La page publique mentionne une condition. Le PDF commercial en mentionne une autre. Une ancienne FAQ contient une exception pour les groupes. Le CRM contient encore une clause particulière négociée pour ce client.
Un chatbot trop simple choisit le passage le plus proche et transforme cette sélection en réponse définitive.
Un meilleur système traite le conflit comme un état du workflow. Si deux sources incompatibles concernent une promesse client, la règle devient : ne pas arbitrer silencieusement.
Le bot peut dire : « Je trouve deux conditions différentes qui pourraient s’appliquer. Je préfère faire vérifier votre cas par notre équipe. »
Ce n’est pas un échec conversationnel. C’est une bonne frontière de responsabilité.
Et même une seule source peut être mauvaise : paragraphe ambigu, tableau sans unité, note interne jamais validée. La provenance aide à identifier ce qui a été utilisé. Elle ne transforme pas un document faible en vérité.
Une couche de traçabilité sans reconstruire tout le système
Le travail commence dans la source documentaire.
- Donner à chaque document important un ID stable, un owner et une version ou date d’approbation.
- Conserver ces métadonnées lors du découpage en chunks et de l’indexation.
- Définir des classes de réponses : routine, engagement client, information sensible, conflit.
- Afficher une source au client quand elle aide réellement ; conserver un trace plus riche pour l’équipe.
- Obliger le chatbot à s’abstenir ou transférer lorsque les preuves sont contradictoires ou insuffisantes.
- Tester ce qui se passe quand un document est remplacé ou supprimé.
Le dernier point est souvent oublié. Si une source disparaît après trois mois, il faut pouvoir comprendre quel document avait été utilisé au moment de la conversation, tout en respectant les règles internes de conservation et de protection des données.
Le handover humain doit transporter les sources
Un transfert du type « le client a une question sur l’annulation » oblige le collaborateur à refaire tout le travail.
Un bon handover contient la question, la réponse envisagée, les sources et versions trouvées, le conflit éventuel et la raison pour laquelle le chatbot n’a pas tranché.
Exemple : « Tarif public v4 = X ; contrat client = condition spéciale ; aucune promesse finale envoyée. » Le collaborateur peut alors décider rapidement.
L’humain garde la responsabilité. Une source parfaitement traçable peut être mal rédigée, mal appliquée ou juridiquement hors contexte. La provenance rend la décision explicable ; elle ne garantit pas l’exactitude absolue.
Pilote minimal et métriques utiles
Choisissez une zone où les questions créent de vrais désaccords : annulation, garantie, livraison ou périmètre d’un service. Préparez 30 à 50 cas avec documents conflictuels, exception client, source manquante et droits d’accès différents.
Mesurez le taux de réponses avec trace complet, le taux de réponses engageantes basées sur la bonne source applicable, les conflits détectés, les transferts avec preuve exploitable, les affirmations définitives sans support suffisant et, si possible, le temps nécessaire au collaborateur pour vérifier le dossier.
La conclusion : une bonne réponse IA n’est pas seulement une phrase plausible. Pour les sujets importants, l’entreprise doit pouvoir remonter à la preuve qui a produit cette phrase. Sinon, le chatbot reste difficile à auditer précisément au moment où le client conteste quelque chose.
La mise à jour des connaissances règle la responsabilité. Le RAG avec permissions évite qu'une citation interne devienne une fuite.
Sources
Avant la réalisation, choisissez la technique nécessaire. Le comparatif RAG ou fine-tuning sépare faits absents, erreurs de recherche et problèmes de sortie en rendant la maintenance visible.
FAQ
Faut-il montrer une source sur chaque message ?
Non. Les interactions de routine doivent rester simples. Pour une affirmation engageante, la source doit au minimum rester traçable en interne.
Le nom du document suffit-il ?
Pas toujours. La version, le passage et le moment du retrieval sont utiles lorsqu’un document change.
Que faire si deux sources se contredisent ?
Ne pas choisir silencieusement lorsqu’il y a un impact client. Marquer le conflit et transmettre le dossier avec les preuves.
Provenance et RAG, c’est la même chose ?
Non. RAG récupère du contenu pour répondre. La provenance décrit l’origine et la contribution des sources à la réponse produite.
Que faire si la source est supprimée plus tard ?
Prévoir un historique ou des métadonnées suffisantes pour l’audit, dans les limites de la politique de conservation et de protection des données.