Une commerciale demande au chatbot interne : « Quelles remises appliquons-nous aux clients hôteliers ? » La recherche trouve trois documents très proches du sujet. Deux sont des règles commerciales normales. Le troisième est un fichier de direction avec marges d’achat et conditions spéciales.
Pour la similarité sémantique, le résultat est excellent. Pour les permissions, il est interdit.
C’est le défaut classique d’un RAG construit uniquement autour de la pertinence. Le moteur récupère les meilleurs chunks, puis les envoie au modèle. Si le contrôle d’accès intervient seulement après la génération, le contenu confidentiel se trouve déjà dans le contexte.
Le RAG « permission-aware » impose une règle plus saine : on ne recherche que parmi les documents auxquels l’utilisateur actuel a réellement droit. La pertinence s’applique ensuite à ce sous-ensemble.
Les permissions RAG séparent pertinence et autorisation
La logique Zero Trust n’accorde pas un accès simplement parce que l’utilisateur se trouve « à l’intérieur » du réseau. Identité, ressource et politique comptent dans chaque décision.
Une requête RAG contient donc deux problèmes : qu’est-ce qui répond à la question ? Et qu’est-ce que cette personne a le droit d’utiliser comme source ?
Les droits peuvent venir des groupes, rôles, ACL ou métadonnées du système documentaire. Le produit choisi importe moins que l’ordre : filtrer l’espace autorisé, puis faire le ranking sémantique.
Fait confirmé : les architectures Zero Trust s’appuient sur l’identité et la ressource pour les décisions d’accès.
Recommandation : ne demandez pas au modèle de juger après coup si un document confidentiel déjà chargé dans son contexte peut être cité. L’autorisation doit intervenir avant.
Une migration RAG peut aplatir les droits existants
Le premier pilote va vite : export SharePoint ou Drive, embeddings, index vectoriel, chatbot. La démo paraît excellente.
Mais l’environnement source peut contenir des droits hérités par dossier que l’export n’a pas conservés. Le nouvel index devient alors beaucoup plus ouvert que la source.
Dans un hôtel, la même recherche pourrait contenir horaires du petit-déjeuner, planning du personnel, plaintes clients, tarifs fournisseurs et rapports de direction. Une requête sur « coût petit-déjeuner » peut faire remonter une feuille de marge au lieu du tarif public.
Le cache est un autre piège. Une réponse autorisée pour la direction est stockée avec son contexte, puis réutilisée de façon trop large pour un autre utilisateur.
Il faut donc préserver le périmètre d’accès dans l’indexation, le retrieval, le cache et la trace de réponse.
Un flow permission-aware en six étapes
Commencez petit mais rendez la règle visible.
- Classifiez les documents. Public, interne, équipe, confidentiel, fortement restreint.
- Conservez les ACL dans l’index. Le document ou chunk doit rester lié aux rôles ou groupes autorisés.
- Utilisez une identité authentifiée. « Je suis le directeur » écrit dans le prompt ne change pas le rôle.
- Filtrez avant le ranking sémantique. Les chunks interdits ne doivent pas devenir candidats.
- Journalisez source et décision d’accès. On doit pouvoir reconstituer pourquoi un contenu a été utilisé.
- Testez les refus. Un utilisateur sans droit RH demande salaires, évaluations ou marges et ne doit récupérer aucun chunk sensible.
Une petite structure peut n’avoir que trois rôles. Ce n’est pas la sophistication qui protège ; c’est le fait de ne pas considérer « employé » comme accès universel.
Le cas difficile : l’information dérivée
Un modèle peut produire une information sensible sans récupérer un document explicitement interdit. Plusieurs sources autorisées peuvent, ensemble, permettre de déduire une marge, une stratégie ou une situation personnelle.
Ce problème n’a pas de solution parfaite par ACL. Pour des domaines très sensibles, séparer les knowledge bases ou imposer des politiques de réponse spécifiques est souvent plus simple.
Le transfert humain est aussi nécessaire quand la source est autorisée mais la décision ne devrait pas être déléguée. Le bot peut montrer la politique RH ; il ne doit pas forcément conseiller de licencier une personne dans un cas particulier.
L’accès aux faits et l’autorité décisionnelle sont deux contrôles différents.
Le pilote minimum doit essayer de faire échouer les droits
Prenez deux groupes — vente et direction — et deux types de documents. Ajoutez volontairement une feuille confidentielle.
Écrivez dix questions normales et dix questions interdites, dont certaines indirectes. Faites aussi prétendre à l’utilisateur qu’il a une autre fonction. Regardez les logs de retrieval : une réponse finale polie ne suffit pas si le modèle a quand même vu le contenu interdit.
Mesurez les chunks non autorisés récupérés, les refus erronés pour utilisateurs autorisés, les réponses avec source traçable, le délai de propagation d’une modification ACL, les handovers pour doute de droit et la couverture des catégories sensibles par les tests.
La capacité à répondre est seulement la moitié du produit. L’autre moitié est la capacité à ne pas répondre depuis la mauvaise source.
Conclusion : dès qu’une PME possède des droits documentaires différenciés, son RAG doit les respecter. Sinon, elle construit une nouvelle entrée vers les mêmes fichiers — mais sans la serrure déjà présente sur l’ancienne.
L'injection indirecte concerne le contenu. L'identité technique précise au nom de qui la recherche agit.
Sources
FAQ
Exclure les dossiers confidentiels suffit-il ?
Pour un pilote simple, parfois. Dès que plusieurs groupes partagent un index, un filtrage plus fin devient utile.
Le modèle peut-il décider lui-même si un document est sensible ?
Il peut aider à classifier, mais ne devrait pas être la seule barrière d’autorisation.
Chaque chunk doit-il porter une ACL ?
L’implémentation varie. Le système doit néanmoins pouvoir appliquer le bon droit à tout contenu récupérable.
Que se passe-t-il si l’utilisateur écrit « je suis directeur » ?
Rien côté permission. Le rôle doit venir d’une identité authentifiée, pas du texte du prompt.
Faut-il séparer les documents RH ?
Ce n’est pas obligatoire techniquement, mais une séparation plus forte simplifie souvent le contrôle des domaines très sensibles.