RAG Avec Contrôle des Permissions : Ce Que Ça Coûte Vraiment de Bien Faire

Un RAG avec contrôle des permissions signifie que votre étape de récupération filtre selon qui pose la question, pas seulement ce qu'il demande — et ce filtre doit être intégré à la requête vectorielle elle-même, pas appliqué dans un second passage effectué par le LLM après coup. La plupart des équipes l'apprennent à leurs dépens : leur démo RAG fonctionne parfaitement sur une base de connaissances partagée, puis quelqu'un demande à appliquer des accès documentaires par utilisateur, et c'est toute la couche de récupération qui doit être refaite.

Pourquoi « ajouter simplement une vérification des permissions » ne fonctionne pas

Le réflexe consiste à conserver son pipeline de récupération existant et à greffer une vérification en fin de chaîne : récupérer les top-k chunks, puis demander à un LLM (ou à un moteur de règles) « cet utilisateur est-il autorisé à voir ça ? » avant de transmettre le contexte à l'étape de réponse. Cette approche échoue de deux manières :

• Elle est non déterministe. Un LLM chargé de contrôler les accès se trompera parfois, et « parfois faux » n'est pas une politique de contrôle d'accès acceptable — a fortiori avec des dossiers médicaux, des documents juridiques ou des fichiers RH.
• La fuite s'est déjà produite. Au moment où vous filtrez post-récupération, le contenu restreint a déjà été chargé dans une fenêtre de contexte et transmis quelque part. La journalisation, le cache ou une trace de débogage intempestive peuvent le divulguer avant même que votre filtre ne s'exécute.

La solution consiste à intégrer les permissions dans la requête — de la même façon qu'on ajoute une clause WHERE user_id = ? dans une requête SQL plutôt que de tout récupérer et de filtrer dans le code applicatif. Nous avons observé le même principe dans nos propres outils : dans un moteur de prospection interne que nous avons construit, un seul appel filtrant et extrayant en une passe unique surpassait systématiquement une chaîne en plusieurs étapes récupérant largement avant de raisonner sur la pertinence — moins coûteux, plus rapide, et moins d'endroits où quelque chose peut mal tourner. Le RAG avec contrôle des permissions est la version critique pour la sécurité de cette même leçon : filtrez à la source, pas après coup.

Ce qui change concrètement dans votre architecture

Si vous utilisez Postgres avec pgvector ou un vector store managé, la récupération avec contrôle des permissions requiert généralement :

1. Des métadonnées de permissions sur chaque chunk. Pas seulement un document_id — vous devez savoir, au moment de l'indexation, quels rôles, équipes ou identifiants utilisateurs sont autorisés à voir chaque chunk. Cela implique généralement de re-chunker et de ré-embeder votre corpus existant, pas simplement un patch de métadonnées.
2. Une sécurité au niveau des lignes ou un filtre équivalent dans le chemin de requête. Postgres dispose d'un support natif via les politiques de sécurité au niveau des lignes, et Supabase s'appuie directement dessus pour le RLS multi-tenant. La recherche par similarité et le filtre d'accès s'exécutent en une seule requête, de sorte que la recherche vectorielle d'un utilisateur ne peut littéralement pas retourner des lignes qu'il n'est pas autorisé à voir.
3. Un modèle de permissions qui évolue dans le temps. Les documents sont partagés, les rôles sont révoqués, les équipes sont restructurées. Si vos embeddings et vos permissions résident dans des systèmes distincts qui se synchronisent selon un calendrier, il existe une fenêtre pendant laquelle la session d'un employé licencié peut encore récupérer des documents auxquels il a perdu l'accès une heure plus tôt. Les vérifications de permissions en temps réel sont non négociables dès lors que le système touche à quelque chose de réglementé.
4. Une stratégie de réindexation, pas seulement une logique de récupération. C'est ce qui fait exploser les estimations. Ajouter des ACL à un système RAG qui compte déjà 50 000 documents indexés signifie que vous n'écrivez pas une nouvelle requête — vous retraitez l'intégralité du corpus en y attachant des tags de permissions, puis vous validez que ces tags sont corrects avant de confier du contenu sensible au système.

Où va réellement le coût

Les équipes budgétisent le modèle et la logique de récupération. Sur ce même corpus de 50 000 documents, le vrai coût apparaît ailleurs :

• L'audit des données. Quelqu'un doit déterminer qui est réellement censé voir quoi — et avec 50 000 documents, ce n'est pas un tableur rempli en une après-midi. C'est une confirmation des accès département par département, souvent à partir d'une connaissance tacite qui n'a jamais été formalisée, avant qu'un seul tag de permission ne soit attaché.
• Le ré-embedding à grande échelle. Re-chunker et ré-embeder 50 000 documents n'est pas un traitement qu'on lance le soir et qu'on vérifie le lendemain matin — si le modèle de permissions modifie ce qui constitue une unité récupérable (en divisant un dossier partagé en sections par équipe, par exemple), les limites de chunks elles-mêmes changent, ce qui en fait une passe de retraitement sur l'ensemble du corpus, pas une simple mise à jour de métadonnées par-dessus.
• Les tests des cas négatifs. Tester que le système récupère correctement est simple. Tester qu'il ne récupère jamais quelque chose qu'un utilisateur ne devrait pas voir — sur toutes les combinaisons de rôles — c'est ce qui demande un vrai travail de QA. C'est la même catégorie de travail couverte dans une checklist de sécurité pour les agents IA, et cela mérite la même rigueur que vous appliqueriez au code d'authentification — pas « on a essayé quelques prompts et ça semblait correct ».
• La journalisation d'audit. Dans les contextes médicaux ou gouvernementaux, vous devez souvent prouver, après coup, exactement ce qu'un utilisateur a récupéré et pourquoi — ce qui implique de journaliser la requête filtrée, pas seulement la réponse finale. Cela rejoint directement ce que nous avons écrit sur l'architecture défendable en justice pour l'IA en santé : le journal doit être défendable, pas seulement présent.

Quand vaut-il mieux construire soi-même plutôt qu'acheter ?

Si votre modèle d'accès est simple — un seul tenant, une base de connaissances partagée, tout le monde voit tout — n'implémentez pas de récupération avec contrôle des permissions. C'est une complexité inutile pour un problème que vous n'avez pas. Commencez par les fondamentaux dans RAG expliqué pour les fondateurs et avancez.

Construisez vous-même quand :

• Votre modèle de permissions est au cœur du produit (SaaS multi-tenant, dossiers médicaux, bases de connaissances internes avec contenu RH ou juridique confidentiel).
• Vous avez besoin d'une révocation en temps réel — les changements d'accès doivent prendre effet immédiatement, pas à la prochaine synchronisation.
• Vous opérez dans un secteur réglementé où « on a filtré après la récupération » ne résistera pas à un audit.

Envisagez une couche managée (de nombreuses plateformes de recherche et de RAG en entreprise proposent désormais une récupération avec ACL intégrée) quand votre modèle de permissions s'aligne clairement sur des structures standard de rôles/groupes et que vous n'avez pas besoin de personnaliser la logique de filtrage elle-même. Quelle que soit votre option, appliquez le même niveau d'exigence aux garanties de récupération du fournisseur que vous en appliqueriez à tout contrat avec un prestataire IA — consultez les évaluations dans les contrats IA pour savoir quoi demander concrètement.

En une phrase

Ne demandez pas au LLM d'appliquer le contrôle d'accès après la récupération — appliquez-le dans la requête qui effectue la récupération, et budgétisez la réindexation de votre corpus, pas seulement l'écriture d'un nouveau code de récupération.

Si vous cadrez un système RAG nécessitant de vraies frontières de permissions — dossiers médicaux, SaaS multi-tenant, documents internes avec des sections confidentielles — parlons-en.