RAG auditable : les six exigences qui précèdent le choix d'une architecture

Une question revient sans cesse dès qu'un projet documentaire démarre. Le RAG fait-il mieux qu'un bon moteur de recherche, qu'une fenêtre de contexte allongée ou qu'une simple base de données ? Le débat se règle presque toujours sur le terrain de la précision. Dans les systèmes documentaires réglementés, ce cadrage manque l'essentiel, et les six exigences décrites ici relèvent d'un problème d'architecture plutôt que d'un verdict sur une technologie.

Une comparaison mal posée

Opposer le RAG à la recherche d'information a peu de sens, puisque le RAG utilise lui-même un moteur de recherche. La comparaison pertinente met en regard trois familles de dispositifs, la récupération suivie d'une synthèse, la récupération seule et la requête structurée. Chacune répond correctement à certaines questions et se révèle inadaptée à d'autres.

Le critère d'évaluation mérite lui aussi d'être déplacé. La justesse apparente d'une réponse se constate en quelques secondes. Sa recevabilité devant un auditeur se démontre, document par document. Sept questions permettent de vérifier la solidité de la chaîne de preuves qui soutient une réponse :

• de quel document la réponse provient-elle,
• de quelle version de ce document,
• laquelle faisait autorité à quelle date,
• quel passage précis justifie l'affirmation produite,
• les éléments récupérés étaient-ils suffisants pour répondre,
• certains d'entre eux se contredisaient-ils,
• le résultat peut-il être reproduit à l'identique ?

Six exigences découlent de ce cadrage. Elles valent quelle que soit la technologie retenue, et elles constituent la partie stable du problème.

Exigence 1, la traçabilité relève de l'architecture

L'affirmation inverse circule largement. Elle attribue au RAG une propriété qu'il ne possède pas en propre. La récupération d'information ne garantit à elle seule ni la traçabilité ni la vérifiabilité de la source. Le système peut faire remonter le mauvais document, citer un passage qui ne justifie pas la phrase générée, mélanger plusieurs sources ou laisser le modèle combler les lacunes à partir de ses données d'entraînement.

À l'inverse, une architecture à long contexte qui transporte les identifiants de document, leurs versions et les positions de page peut être parfaitement auditable. Une citation affichée ne prouve rien tant qu'elle n'a pas été vérifiée contre le passage qu'elle désigne. Ce contrôle relève de la conception du système et rejoint les exigences détaillées dans notre guide du RAG en secteur réglementé.

Exigence 2, la validité temporelle

Voilà l'exigence dont on parle le moins, alors qu'elle décide de la recevabilité des réponses. Les corpus réglementaires sont indexés dans le temps, et pas seulement versionnés. « Quelle procédure s'appliquait le 15 mars 2025 ? » constitue une requête différente de « quelle est la procédure actuelle ? ».

Répondre suppose trois opérations enchaînées. Interpréter d'abord la date contenue dans la question. Déterminer ensuite la version qui faisait autorité à cette date. Restituer enfin son contenu accompagné de sa chaîne de preuves. Retourner la dernière version valide constitue une mauvaise réponse, et la plupart des pipelines la fournissent pourtant sans le signaler.

« Une réponse cohérente, correctement citée et fondée sur une procédure abrogée franchit sans encombre une revue documentaire. Puis elle fonde une décision. »

Exigence 3, la gravité des erreurs prime sur leur fréquence

Un découpage en chunks mal calibré produit des réponses incomplètes ou faiblement étayées. Le défaut se voit, il agace les utilisateurs et il se corrige. Une erreur de validité temporelle produit tout autre chose, une réponse fluide, correctement sourcée et adossée à un texte qui n'était plus en vigueur.

Les deux problèmes existent et demandent tous deux du travail. Le second passe les contrôles de forme, survit à une relecture rapide et peut aboutir à une décision opérationnelle. Les priorités de traitement gagnent à être établies sur la gravité des conséquences et non sur le taux d'occurrence. Les causes classiques de dégradation de la qualité sont détaillées dans notre article sur les raisons pour lesquelles un RAG répond mal.

Exigence 4, l'abstention fait partie de la capacité à répondre

Annoncer qu'un système « réduit les hallucinations » reste trop vague pour tenir lieu de spécification. Trois vérifications explicites doivent précéder la génération :

• la suffisance des preuves, qui mesure si les éléments récupérés couvrent réellement la question posée,
• la détection des contradictions entre les passages retenus, y compris entre versions successives d'un même texte,
• l'évaluation de la couverture, qui identifie les parties de la question restées sans support documentaire.

Ces trois contrôles constituent des choix d'architecture à part entière. Ils méritent l'effort avant toute tentative d'optimisation d'un modèle d'embeddings, dont le gain marginal reste faible en comparaison. Ces contrôles sont décrits dans le fonctionnement de notre assistant documentaire.

Exigence 5, la qualité des métadonnées s'hérite

Tout ce qui précède suppose une couche documentaire dotée de dates d'entrée en vigueur fiables et de liens de remplacement propres. Dans les secteurs pharmaceutique et public, ces champs sont régulièrement incomplets, contradictoires ou absents. La récupération hérite alors de cette dette, sans moyen de la réparer par l'ingénierie.

Lorsque la dette est lourde, l'ordre des priorités s'inverse et la gouvernance documentaire passe avant l'architecture de récupération. Ce chantier est plus lent et plus politique que n'importe quelle tâche technique de cette liste. Autant l'annoncer clairement en phase de cadrage, la version sophistiquée de l'architecture n'est pas toujours la première chose à construire.

Exigence 6, la localité recouvre cinq contraintes

Localisation des données, souveraineté juridique, contrôle opérationnel, garde physique et garantie contractuelle sont constamment confondus sous un même mot. Les organisations n'expriment pourtant pas le même besoin. Certaines demandent que les données restent dans le pays tout en acceptant un opérateur tiers. D'autres exigent la garde physique du matériel. D'autres encore se satisfont d'un engagement contractuel opposable.

Le cadre applicable au marché français est détaillé sur notre page consacrée à l'intelligence artificielle souveraine en France. Les structures de coûts diffèrent fortement d'une ligne à l'autre, puisque l'hébergement local prend aussi bien la forme d'une capacité louée, d'un cloud privé ou d'une colocation que d'un matériel détenu en propre. Le point commun à toutes ces configurations tient à un effet de bord rarement anticipé. La réindexation cesse d'être élastique. Changer de modèle d'embeddings prend alors la forme d'un projet, avec un budget et un calendrier, là où une infrastructure mutualisée n'y voyait qu'une tâche batch. Cet arbitrage rejoint celui que nous détaillons sur le coût réel d'un projet RAG et dans notre guide du RAG souverain on-premise.

Le cas particulier des chiffres

Une question portant sur les volumes du dernier trimestre par région relève du SQL ou de la business intelligence. Un vector store constitue un mauvais substrat de calcul, et aucune optimisation de la récupération ne corrigera ce choix de fondation.

Des architectures hybrides restent possibles. La récupération sert alors à retrouver la définition interne d'un indicateur et la requête structurée à en produire la valeur. Cette combinaison suppose toutefois que la définition soit documentée et non ambiguë, condition qui reste loin d'être acquise dans la majorité des organisations.

Aucune architecture unique ne s'impose

Un moteur de recherche lexical bien outillé, assorti de règles de citation strictes et de logique métier, satisfait les mêmes exigences. Un knowledge graph versionné également. Une architecture à long contexte correctement instrumentée aussi. Les exigences forment la partie stable du problème, les architectures la partie mobile, et l'ordre des deux mérite d'être respecté au moment de choisir.

Cette grille de lecture s'applique directement au périmètre d'un assistant documentaire interne comme à celui d'un copilote IA souverain déployé sur le système d'information de l'organisation.

Questions fréquentes

Le RAG garantit-il la traçabilité des réponses ?
Non. La récupération peut faire remonter le mauvais document ou citer un passage qui ne justifie pas la phrase produite. La traçabilité provient de l'architecture qui transporte identifiants, versions et positions de page, puis vérifie la citation au lieu de se contenter de l'afficher.

Qu'est-ce que la validité temporelle dans un corpus réglementaire ?
La capacité du système à déterminer quelle version d'un document faisait autorité à une date donnée. Répondre à « quelle procédure s'appliquait le 15 mars 2025 ? » exige d'interpréter la date, d'identifier la version en vigueur à cette date, puis d'en restituer le contenu et la chaîne de preuves.

Comment un assistant documentaire décide-t-il de ne pas répondre ?
Par trois vérifications explicites avant la génération, la suffisance des éléments récupérés, la détection des contradictions entre passages et l'évaluation de la couverture de la question.

Faut-il un RAG pour interroger des chiffres ?
Non. Les agrégats relèvent du SQL ou de la business intelligence. Une architecture hybride permet d'utiliser la récupération pour la définition d'un indicateur et la requête structurée pour sa valeur, à condition que la définition soit documentée.

Que recouvre l'exigence de localité des données ?
Cinq contraintes distinctes, la localisation territoriale, la souveraineté juridique, le contrôle opérationnel, la garde physique et la garantie contractuelle. Le coût du dispositif dépend directement de celle qui est réellement exigée.

Deux questions aux équipes qui exploitent ces systèmes

Le sujet progresse par confrontation des pratiques, et deux points nous intéressent particulièrement. Comment gérez-vous les requêtes indexées dans le temps, autrement dit comment déterminez-vous la version en vigueur à une date passée plutôt que la dernière version disponible ? Et comment imposez-vous concrètement la suffisance des preuves, en amont de la génération, par une vérification après génération, ou par les deux ?

Transparence : nous développons une plateforme d'IA souveraine déployée on-premise pour les secteurs régulés, ce qui explique la concentration de notre travail sur ces contraintes. Le présent article propose un cadrage du problème et non une étude de cas.