Contrôle d'accès dans un RAG : les choix d'architecture à documenter

Un RAG d'entreprise ne doit pas transformer un droit d'accès flou en recherche conversationnelle à grande échelle. Avant l'ingestion, l'équipe doit pouvoir expliquer comment elle identifie l'utilisateur, décide l'accès à un document, applique cette décision pendant la recherche et prouve le résultat après coup.

En bref

Le contrôle d'accès commence par une règle métier explicite, pas par un filtre ajouté à la base vectorielle.
Documentez ces choix : identité, objet protégé, règle d'autorisation, propagation à l'index, refus, révocation et audit.
Testez autant les accès refusés que les réponses utiles. Un résultat pertinent obtenu à partir d'une source non autorisée reste un échec.

Cette méthode est un cadre de conception. Elle ne remplace pas une analyse de sécurité, de protection des données ou de conformité adaptée à votre organisation.

Pourquoi documenter l'accès avant l'indexation ?

L'indexation découpe, enrichit et rend les documents retrouvables. Si l'équipe ne sait pas quelles permissions doivent suivre chaque document, elle ne sait pas quelles métadonnées conserver ni quels scénarios de refus tester.

Le principe est cohérent avec la Zero Trust Architecture du NIST, publiée en août 2020 : aucune confiance implicite ne découle du seul emplacement réseau, et l'accès à une ressource doit être authentifié et autorisé avant l'établissement d'une session. Pour un RAG, cela conduit à traiter la requête d'un utilisateur comme une demande d'accès à des passages précis, pas comme une simple recherche sémantique.

Le document utile est donc une fiche de décision lisible par le métier, la sécurité et l'équipe de build. Elle évite deux raccourcis : répliquer des groupes sans savoir ce qu'ils signifient, ou utiliser une identité technique unique qui lit plus que l'utilisateur final.

Quelle identité le RAG utilise-t-il réellement ?

Commencez par tracer le chemin entre la personne et la requête. Il faut distinguer :

Élément	Question à documenter	Preuve attendue
Utilisateur	Qui pose la question ?	Identifiant stable et mode d'authentification
Contexte	Dans quelle organisation, équipe ou rôle agit-il ?	Attributs et groupes exploités
Service RAG	Avec quelle identité appelle-t-il les sources et l'index ?	Flux d'identité et scopes techniques
Source documentaire	Où la règle d'accès fait-elle autorité ?	Système propriétaire et propriétaire métier

Cette distinction est essentielle lorsqu'un service interroge un connecteur avec une identité de service. Cette identité peut être nécessaire techniquement. Elle ne doit pas devenir le substitut silencieux des droits de la personne qui pose la question.

La méthode de documentation AI Act pour un système GenAI aide à relier cette décision d’identité à un cas d’usage, une version de connecteur, un test et une preuve d’exploitation. Le dossier ne remplace pas la règle d’accès, mais il doit permettre de retrouver pourquoi elle a été conçue et modifiée.

L'OWASP recommande, dans sa fiche LLM06:2025 Excessive Agency, de suivre l'autorisation et le périmètre de sécurité de l'utilisateur afin que les actions sur les systèmes aval soient exécutées dans son contexte, avec le minimum de privilèges nécessaire. Cette recommandation concerne aussi les connecteurs de lecture : le périmètre transmis doit être explicite et testable.

Quel objet protège-t-on dans le corpus ?

Le mot « document » cache plusieurs niveaux. Une politique peut être autorisée dans son ensemble, tandis qu'une annexe ou une version de travail ne l'est pas. À l'inverse, un même document peut être légitimement visible par plusieurs groupes.

Avant de choisir le schéma d'index, définissez l'objet porteur de la règle :

le document source entier ;
une section ou un passage, si le découpage modifie le périmètre ;
une pièce jointe ou une version, si elle a un cycle de vie distinct ;
un ensemble documentaire, lorsqu'une règle de cloisonnement s'applique à tout un espace.

Pour chaque objet, conservez un identifiant de source, un propriétaire, un état de publication et la règle d'accès applicable. Le chunk vectoriel ne doit pas être la seule mémoire de cette décision. Il doit pouvoir être relié au document d'origine et à la règle qui l'autorise.

Avant de propager cette règle à l’index, formalisez aussi le périmètre de données du RAG : catégories admises, exclusions, transformations autorisées, sorties et retrait. Un contrôle d’accès fiable ne rend pas une source pertinente ou exploitable par défaut.

Comment écrire une règle d'autorisation vérifiable ?

Une règle exploitable répond à une phrase simple : « cet utilisateur peut lire ce document dans ce contexte parce que… ». Évitez les libellés vagues comme « documents internes » ou « équipe finance » sans source de vérité.

Une fiche de règle peut prendre cette forme :

Décision	Exemple de formulation à adapter	Test associé
Sujet	L'utilisateur est authentifié par l'annuaire de l'organisation.	Une requête sans session est refusée.
Attribut	L'accès dépend du groupe métier et du périmètre d'organisation.	Deux utilisateurs de groupes différents reçoivent des ensembles distincts.
Ressource	Le document hérite de la règle définie dans sa source.	La règle indexée correspond à celle de la source.
Effet	Seuls les passages d'un document autorisé peuvent être proposés au modèle.	Un passage interdit n'apparaît ni dans le contexte ni dans la réponse.
Exception	Une dérogation a un propriétaire et une date de fin.	Après l'échéance, l'accès est refusé.

Cette règle doit aussi couvrir les résultats vides. Une absence de passage peut venir d'un manque de contenu ou d'un refus d'accès. Le système n'a pas à révéler quelle hypothèse est vraie si cette information elle-même crée une fuite.

Où appliquer la décision d'accès dans l'architecture ?

Une architecture robuste applique la même intention à plusieurs étapes. Les mécanismes exacts dépendent de la source, de l'IAM et du stockage retenus. L'important est de documenter la responsabilité de chaque couche.

À la connexion, établissez l'identité et les attributs utilisables.
À l'ingestion, rattachez le contenu indexé à son document d'origine et à la règle d'accès à propager.
À la recherche, transmettez un périmètre d'autorisation vérifiable au mécanisme de récupération.
Avant la génération, ne fournissez au modèle que des passages autorisés et traçables.
À la réponse, affichez seulement des citations que l'utilisateur est autorisé à consulter.
Dans les traces, enregistrez les éléments nécessaires pour enquêter sans transformer les logs en copie du corpus sensible.

Le guide sur les architectures de contrôle d'accès RAG présente plusieurs mécanismes possibles, comme le filtrage de métadonnées, l'isolation d'index ou les politiques de base de données. Ici, le critère de choix est différent : pour chaque mécanisme, l'équipe doit pouvoir montrer où une erreur de mapping serait détectée.

Comment traiter les changements et les révocations ?

Un droit d'accès n'est pas figé. Un utilisateur change d'équipe, un document est reclassé, une source est supprimée ou une dérogation arrive à échéance. Le dossier d'architecture doit décrire ce qui déclenche la mise à jour et comment l'équipe vérifie son effet.

Documentez au minimum :

la source de vérité des droits et celle du contenu ;
le déclencheur de synchronisation, périodique ou événementiel ;
le comportement en cas d'échec de synchronisation ;
le propriétaire qui traite l'écart ;
un test de révocation exécuté sur un corpus représentatif.

Ne transformez pas une durée de cache en promesse universelle. La fraîcheur acceptable dépend du type de données, du risque et de la capacité de l'organisation à détecter un écart. Ce choix doit être accepté par les responsables concernés et soumis à un test réaliste.

Quelles preuves faut-il garder pour l'audit et l'exploitation ?

La traçabilité ne consiste pas à conserver chaque échange sans limite. Elle consiste à garder des preuves proportionnées qui permettent de répondre à une question d'exploitation : quelle identité a demandé quoi, quel périmètre a été calculé, quelles sources ont été utilisées et quel mécanisme a produit la réponse ?

Pour chaque scénario sensible, définissez à l'avance :

les événements à journaliser ;
les champs à minimiser ou masquer ;
les personnes autorisées à consulter ces traces ;
la durée de conservation applicable dans votre contexte ;
la procédure lorsqu'un accès inattendu est signalé.

Cette discipline prolonge le cadrage d'un projet RAG : un prototype ne démontre pas une capacité de production s'il ne peut pas expliquer ses sources, ses refus et ses limites. Lorsqu'un système peut aussi agir via des outils métier, le contrôle des sources ne suffit plus : notre guide sur les validations humaines d'un agent IA connecté aux outils métier aide à définir les opérations qui doivent être soumises à une décision explicite.

Quels tests rendent la règle crédible ?

Un jeu d'évaluation RAG doit contenir des tests positifs et négatifs. Les tests positifs vérifient qu'une personne trouve une source autorisée et utile. Les tests négatifs vérifient que le système ne fournit ni passage, ni citation, ni indice exploitable sur une source interdite.

Préparez au moins les scénarios suivants :

deux utilisateurs avec des droits différents sur un même thème ;
un document autorisé et un document interdit très proches sémantiquement ;
une révocation ou un changement de groupe ;
une source supprimée ou reclassée ;
une demande qui tente d'obtenir la liste ou le contenu de documents hors périmètre ;
une défaillance du connecteur d'identité ou de la synchronisation des droits.

Pour chaque test, conservez l'identité simulée, les sources autorisées, les sources interdites, le résultat attendu et l'observation réelle. Le guide Évaluer un RAG en production explique comment rattacher ces cas au jeu de tests global, plutôt que de les laisser dans une recette de sécurité isolée.

Quelle décision prendre avant de lancer le build ?

Avant le premier sprint, réunissez ces six preuves dans une page de décision :

l'identité utilisateur et les attributs réellement disponibles ;
l'objet protégé et la source de vérité des droits ;
la règle d'autorisation formulée et testable ;
le chemin de propagation vers l'index et la génération ;
le mécanisme de révocation et le comportement en cas de défaut ;
les scénarios d'accès refusé, les traces et leurs responsables.

S'il manque l'une de ces preuves, un prototype peut encore servir à explorer une intégration. Il ne doit pas être présenté comme la démonstration que le système protège les données de production.

FAQ

Faut-il copier toutes les ACL dans une base vectorielle ?

Pas nécessairement. Le choix dépend de la source de vérité, du mécanisme de recherche et des exigences de fraîcheur. En revanche, l'équipe doit toujours pouvoir relier le passage retrouvé à une règle d'accès valide et tester les changements de droits.

Un filtre de métadonnées suffit-il à sécuriser un RAG ?

Un filtre peut être une partie du mécanisme. Il ne remplace ni l'identité utilisateur, ni la qualité des métadonnées propagées à l'ingestion, ni les tests de refus et de révocation. La sécurité dépend du chemin complet entre la source et la réponse.

Que doit répondre le RAG quand aucun document n'est autorisé ?

La réponse doit être définie dans le contrat de service. Elle doit rester utile sans confirmer l'existence d'un document sensible. Évitez de distinguer inutilement « aucun résultat » et « résultat interdit » si cette distinction révèle une information.

Qui valide les règles d'accès d'un RAG ?

La validation doit associer le propriétaire métier des données, l'équipe qui maîtrise l'identité et les accès, ainsi que l'équipe responsable du système. Selon le contexte, les fonctions sécurité, juridique ou protection des données peuvent également devoir intervenir.

Méthodologie et sources

NIST SP 800-207, Zero Trust Architecture, publié en août 2020, consulté le 11 septembre 2026. Cette publication décrit les principes d'une architecture zero trust, dont l'absence de confiance implicite fondée sur la localisation réseau et l'authentification ainsi que l'autorisation avant l'accès à une ressource.
OWASP, LLM06:2025 Excessive Agency, consulté le 11 septembre 2026. La fiche recommande notamment de suivre l'autorisation et le périmètre de sécurité de l'utilisateur, avec le minimum de privilèges nécessaire pour les systèmes aval.

La méthode présentée est une grille de documentation pour un RAG d'entreprise. Elle ne contient ni données clients, ni statistiques de mission, ni promesse de sécurité ou de conformité. Les choix d'architecture et les règles de conservation doivent être validés dans le contexte de chaque organisation.

Vous devez déterminer comment un RAG peut respecter les droits d'accès existants avant le build ? Décrivez votre contexte à IgnitionAI. Un premier échange peut aider à clarifier les sources, les décisions d'architecture et les scénarios de test à documenter.