Un chatbot RAG fiable repose sur un corpus maîtrisé

01Une réponse fluide peut masquer une source inutilisable

Le premier échec ne ressemble pas à une panne. Le chatbot formule une réponse nette, mais il reste impossible d’identifier la source ou de vérifier son niveau d’accès. La fluidité du dialogue masque alors le défaut décisif : l’utilisateur ne peut pas vérifier si la réponse s’appuie sur le bon document, dans sa version applicable, ni si ses droits lui permettent de le consulter.

Le contrôle commence en amont de la génération. Puisqu’un système RAG récupère des éléments du corpus avant de répondre ^[1], il faut examiner les documents qu’il peut retrouver, corriger les doublons, retirer les contenus inutiles, désigner le responsable de chaque mise à jour et définir les métadonnées ainsi que la règle d’accès attachée à chaque source. Ces vérifications ne garantissent pas la justesse de toute réponse ; elles rendent au moins son origine contrôlable.

Les droits doivent aussi être testés avec des profils distincts. Azure AI Search peut filtrer les documents retournés en fonction des autorisations que leurs métadonnées associent à l’utilisateur qui effectue la requête ^[2]. Cette possibilité technique ne vaut pas validation de la configuration. Le même test, exécuté avec plusieurs profils, doit confirmer que chacun ne récupère que les documents autorisés et que la citation affichée renvoie à un contenu qu’il peut effectivement consulter. Si la source est inaccessible, obsolète ou ambiguë, le déploiement ne peut pas être validé.

Le critère d’acceptation ne porte donc plus seulement sur la qualité de la réponse. La formulation reste importante, mais la décision dépend d’abord de la possibilité de contrôler toute la chaîne. Il faut savoir quel contenu a été recherché, pourquoi il a été retenu, si l’utilisateur pouvait le consulter et si la réponse reste fidèle au passage récupéré.

Le RAG vise à fonder la réponse sur des connaissances récupérées après l’entraînement du modèle ^[6]. Ce fonctionnement ne transforme pas automatiquement le corpus en référence fiable. L’entreprise doit donc administrer la base de connaissances, définir les documents admis et les exclusions, puis désigner les responsables.

02L’inventaire qualifie les sources avant leur indexation

L’inventaire va au-delà du comptage des fichiers. Il relie chaque question attendue aux documents susceptibles d’y répondre. Pour chaque source, il consigne au minimum son propriétaire, son statut, son périmètre métier, ses utilisateurs autorisés, sa version applicable et l’événement qui impose une révision. Toute information manquante doit être renseignée avant l’indexation.

Le NIST décrit le RAG comme un système qui identifie des informations pertinentes dans une base de connaissances et les fournit au modèle génératif comme contexte ^[5]. La décision de déploiement doit donc tenir compte des contenus que la recherche peut sélectionner. Avant la génération, il faut donc contrôler l’intitulé du document, ses éventuelles contradictions avec d’autres sources et ses métadonnées.

Le nettoyage suppose ensuite des décisions traçables. Fusionner deux versions, retirer une annexe ou corriger un titre modifie ce que le système pourra retrouver. Chaque opération doit préserver l’origine du document et laisser une trace de la raison pour laquelle il a été modifié. Le protocole consigne également chaque doublon et la décision prise à son sujet.

Le découpage mérite le même contrôle. Un fragment doit conserver assez de contexte pour rester compréhensible lorsqu’il est récupéré seul. Le titre, le périmètre métier ou une condition d’application doivent rester associés à la consigne qu’ils précisent. Le test consiste à lire le passage récupéré sans le document complet et à vérifier qu’il suffit encore à étayer la réponse attendue.

Cet inventaire permet une première décision : le corpus documentaire est-il prêt pour ce chatbot ? Il l’est lorsque les sources nécessaires peuvent être nommées, administrées et reliées à des questions concrètes. Une collection volumineuse ne peut pas être considérée comme prête si le statut de ses documents reste incertain.

03Les habilitations se contrôlent au moment de la récupération

Le contrôle d’accès doit s’appliquer au moment où la recherche sélectionne les documents. Microsoft recommande de l’appliquer lors de la récupération ^[10]. AWS indique que le filtrage par métadonnées permet de contrôler précisément les documents récupérés dans un système RAG ^[8]. Les règles d’habilitation doivent donc être inscrites dans les métadonnées et appliquées à la requête, puis testées avec des profils réels.

Les architectures documentées prévoient aussi de séparer les sous-systèmes au moyen d’autorisations de gestion des identités et des accès ^[9]. Elle ne répond toutefois pas à toutes les questions métier. Il reste à décider quel groupe peut consulter chaque source, comment un changement de poste modifie les droits et ce qui se passe lorsqu’une métadonnée manque.

Le test ne doit pas porter uniquement sur le texte final. Deux vérifications doivent rester distinctes : la récupération éventuelle d’un document interdit et la présence effective du document attendu dans l’index. La présence ou l’absence d’une réponse ne permet, à elle seule, de tirer aucune conclusion sur ces deux points. Le relevé d’essai doit donc mettre en regard le profil, les filtres appliqués, les sources récupérées et la réponse affichée.

Les cas limites sont particulièrement instructifs : document sans groupe déclaré, utilisateur rattaché à plusieurs fonctions, source déplacée, droit retiré ou citation pointant vers un emplacement devenu inaccessible. Le résultat admissible est défini avant l’essai. À défaut, un résultat inattendu risque d’être interprété après coup comme un comportement acceptable.

Cette gradation évite de confondre possibilité technique et politique d’accès. La configuration peut appliquer des filtres, mais l’entreprise doit encore définir des règles cohérentes et des profils utilisateurs clairement définis. Le déploiement reste en attente si l’accès à un document sensible dépend d’une règle non écrite ou d’un groupe dont la gestion n’est attribuée à personne.

04Une citation visible ne suffit pas à étayer la réponse

Une citation rend la réponse vérifiable lorsque l’utilisateur peut ouvrir la source et comparer son contenu à l’affirmation. L’étude citée présente les citations comme un moyen de relier le contenu généré à des sources vérifiables ^[3]. Ce lien doit être vérifié dans le passage réellement utilisé.

Une source peut être pertinente pour le sujet sans soutenir la phrase affichée. Elle peut aussi contenir une réserve omise, une règle ancienne ou un exemple transformé en généralité. Le contrôle commence par le lien visible et se poursuit par la vérification du passage, du document complet et de sa version.

Les travaux cités montrent pourquoi le contrôle doit porter sur chaque affirmation.

Même avec un contexte pertinent, un système RAG peut produire des affirmations non étayées ou contradictoires ^[4]. La seule présence d’une citation ne constitue donc pas un critère suffisant. La réponse doit relier chaque affirmation à la bonne source, respecter sa portée et signaler quand le corpus ne permet pas de conclure.

La correction commence par le cas observé. Le relevé conserve la question, le profil, les passages récupérés et la réponse. Le responsable détermine ensuite si le défaut vient du document, de ses métadonnées, du découpage, de la recherche ou de la formulation. Après correction et nouvelle indexation si nécessaire, le même cas est rejoué. Le cas devient ainsi un test de régression.

05Les règles de mise à jour se définissent avant l’indexation

Une date affichée ne prouve pas qu’un document reste applicable. Le fait qu’un document soit encore à jour dépend de sa nature, de son propriétaire et de l’événement qui le rend caduc. Une procédure peut changer après une validation interne, une fiche produit peut être remplacée et une ancienne règle peut rester utile à des fins historiques. Chaque famille de documents nécessite donc une politique explicite.

AWS recommande le versionnage, des règles de fraîcheur et une réindexation pour limiter la persistance d’informations obsolètes ^[7]. Le cycle de vie doit donc être défini avant la mise en service. Il faut savoir comment une modification est détectée, quand elle entre dans l’index et comment son effet est vérifié.

La politique de mise à jour doit aussi prévoir les cas d’échec. Si une réindexation n’aboutit pas, le service ne doit pas laisser croire que la nouvelle source est déjà disponible. Le suivi doit distinguer la modification du document, son ajout effectif à l’index et sa récupération dans les réponses de contrôle.

La bonne fréquence ne se décrète donc pas pour l’ensemble du corpus. Elle résulte du risque associé à chaque contenu et du délai acceptable entre une modification et son effet. Après un changement connu, le test doit répondre à deux questions : quelle version le système retrouve-t-il et l’utilisateur peut-il le constater ?

06Les tentatives de détournement permettent de tester les protections réellement actives

Les tests d’acceptation doivent confronter le service à des demandes conçues pour contourner ses règles. Deux scénarios sont testés en premier : une consigne hostile placée dans la question de l’utilisateur, puis une consigne hostile placée dans un document que le système peut récupérer. Pour chacun, le résultat attendu précise ce qui doit être ignoré, refusé ou signalé.

Le périmètre se limite aux effets observables dans la chaîne RAG : les documents récupérés, la réponse, les citations et l’ouverture des sources. Il ne constitue ni un audit exhaustif du RGPD ni une comparaison entre architecture locale et cloud, qui appellent des décisions séparées.

Un autre essai porte sur l’exfiltration : demander un document complet, une série d’extraits ou une information réservée depuis un profil dépourvu du droit nécessaire. Le résultat est examiné dans la réponse, les citations et les documents récupérés. Il y a dépassement des droits dès qu’un contenu protégé devient accessible, même si la formulation finale paraît prudente.

Ces scénarios restent séparés des tests ordinaires de pertinence. Une réponse défaillante à une question métier révèle un défaut de qualité ; une source protégée récupérée révèle un défaut d’accès. La correction, le responsable et le seuil de blocage ne sont pas identiques. Le registre d’acceptation doit conserver cette distinction.

Des essais croisés doivent aussi associer plusieurs difficultés. Un document obsolète peut contenir une consigne indirecte ; un profil peut accéder à une version courante sans être autorisé à consulter l’archive ; une citation peut révéler le titre d’une source restreinte. Ces essais vérifient que les protections ne fonctionnent pas uniquement dans le cas le plus simple.

Le protocole ne garantit pas l’absence de tout détournement futur. Il consigne les risques testés dans le périmètre à partir de scénarios reproductibles, attribue chaque écart à un responsable et maintient hors service les cas non résolus.

07La mise en service dépend d’une matrice d’acceptation

La décision finale relie l’état documentaire aux résultats observés. Une démonstration d’interface ne répond pas à cette exigence. Il faut une matrice qui indique, pour chaque axe, la preuve attendue, l’écart constaté et sa conséquence. Cette matrice évite qu’une bonne qualité rédactionnelle compense, à tort, un défaut de droits.

La matrice ci-dessous relie l’état du corpus, les contrôles réalisés et la décision de déploiement.

La décision peut être limitée à un périmètre réellement maîtrisé. Un service limité à des documents qualifiés et à des profils connus est plus facile à vérifier qu’une ouverture générale dont les droits restent ambigus. Cette restriction doit être consignée dans les critères d’acceptation, avec les questions couvertes et celles qui restent hors champ.

Un cadrage devient utile lorsque personne n’assume la responsabilité de l’ensemble. Lorsque les métiers connaissent les documents et que l’équipe technique maîtrise l’index, mais que personne ne coordonne l’ensemble, la conception d’un assistant adapté aux données et aux contraintes réelles permet d’attribuer clairement les responsabilités et de définir des critères de décision vérifiables. Le point de départ demeure une question métier, accompagnée de sa source attendue et du profil autorisé.

La décision peut alors s’appuyer sur un résultat vérifiable. Le déploiement devient possible lorsque, pour chaque question testée, le système retrouve une source applicable et accessible au bon utilisateur, puis produit une réponse fidèle à cette source, dont la maintenance suit une règle connue. Il suffit qu’un de ces éléments reste indéterminé pour restreindre le périmètre du service ou différer sa mise en exploitation.

La mise en service exige que chaque réponse renvoie à une source applicable, accessible au bon profil et maintenue selon une règle connue.