RAG et droits d'accès : faire hériter un RAG des permissions Active Directory (Entra ID)

Note de transparence. Cet article est rédigé conformément à la politique éditoriale d'IgnitionAI. Les affirmations sur le comportement d'Entra ID, Microsoft Graph et SharePoint renvoient à la documentation Microsoft Learn officielle, avec date de consultation. Les recommandations d'architecture sont des estimations IgnitionAI taguées comme telles.

Quelques semaines après le déploiement d'un assistant interne, un opérateur d'une direction métier pose une question banale. La réponse cite une note préparatoire au comité de rémunération, qu'il n'aurait jamais dû voir. L'assistant n'a rien forcé : il a interrogé l'index en respectant des permissions techniques bien plus larges que ce que les propriétaires métier croyaient. C'est le scénario qui revient le plus souvent en mission, et il se règle à la conception, pas après l'incident.

Un RAG d'entreprise hérite des droits Active Directory en propageant l'appartenance aux groupes de l'utilisateur jusqu'au moteur de recherche. Cela se joue à trois niveaux : un tag ACL posé sur chaque chunk à l'ingestion, un filtre pré-retrieval appliqué à la requête, une vérification au moment de la réponse. Voici comment le câbler sur Entra ID, et les six cas qui le cassent en production.

Le modèle mental : de l'identité au chunk

Le principe tient en une chaîne. L'utilisateur est authentifié par Entra ID. Son appartenance aux groupes de sécurité voyage jusqu'au vector store, qui ne retourne que les chunks dont les autorisations recoupent ces groupes.

Utilisateur (Entra ID)
  -> groupes de sécurité (claims du token, ou Microsoft Graph si débordement)
  -> filtre pré-retrieval sur le vector store
  -> chunks dont les tags ACL recoupent les groupes de l'utilisateur
  -> génération LLM sur ce sous-ensemble autorisé uniquement

La règle d'or : aucun document hors périmètre ne doit entrer dans le contexte passé au LLM. Filtrer après coup la réponse générée est trop tard, le modèle a déjà lu le document. Le filtrage se fait avant la recherche de similarité, ce que nous appelions le pré-retrieval dans notre comparatif des cinq architectures de contrôle d'accès. Cet article creuse la mise en œuvre concrète de l'une d'elles.

Étape 1 · Tagger les chunks à l'ingestion

Chaque chunk indexé porte les autorisations de son document source. Au moment de l'ingestion, vous lisez les permissions du document (groupes de sécurité SharePoint, ACL du système de fichiers) et vous les stockez comme metadata du chunk.

{
  "text": "Procédure de clôture comptable T4, étape 3...",
  "acl": ["grp-finance-fr", "grp-direction"],
  "source": "sharepoint/finance/cloture-t4.docx",
  "sensitivity": "confidential",
  "version": "2026-06-01"
}

Le champ acl contient les identifiants des groupes autorisés à lire le document. Les champs sensitivity et version servent au contrôle de conformité et à la suppression ciblée (voir plus bas). Sans ces metadata posées dès l'ingestion, aucun filtrage propre n'est possible ensuite.

Étape 2 · Résoudre les groupes de l'utilisateur à la requête

À chaque requête, vous récupérez les groupes de l'utilisateur authentifié, puis vous les passez comme prédicat de filtrage au vector store.

Microsoft Graph expose l'appartenance transitive d'un utilisateur, groupes imbriqués compris, via l'API transitiveMemberOf (documentation Microsoft Graph, consultée juin 2026) :

GET https://graph.microsoft.com/v1.0/me/transitiveMemberOf/microsoft.graph.group?$select=id

Vous transmettez ensuite la liste obtenue au vector store. Sur Qdrant, le filtre par metadata (documentation Qdrant filtering, consultée juin 2026) prend la forme d'une correspondance « au moins un groupe en commun » :

{
  "filter": {
    "must": [
      { "key": "acl", "match": { "any": ["grp-finance-fr", "grp-direction", "grp-tous"] } }
    ]
  }
}

La recherche de similarité ne s'applique alors qu'aux chunks dont l'acl contient au moins un des groupes de l'utilisateur. Le reste de l'index reste invisible.

Les six cas qui cassent en production

C'est ici que la plupart des implémentations dérapent. Chacun de ces cas est documenté, et chacun a une parade.

1. Les groupes imbriqués. Si un utilisateur appartient à GroupB, et que GroupB appartient à GroupA, ses droits incluent les deux. L'appartenance directe ne suffit donc pas : il faut l'appartenance transitive. Les group claims d'Entra ID incluent les groupes imbriqués, sauf si vous restreignez les claims aux groupes assignés à l'application (Microsoft Entra, group claims, consultée juin 2026). Utilisez transitiveMemberOf, jamais la seule appartenance directe.

2. Le token déborde. Entra ID limite le nombre de groupes émis dans un token : 150 pour une assertion SAML, 200 pour un JWT. Au-delà, les groupes sont tout simplement omis du token (même source). Une implémentation qui lit les groupes depuis le token donnera alors des résultats incomplets à vos utilisateurs les plus connectés. La parade : pour ces comptes, interroger Microsoft Graph plutôt que de faire confiance au token.

3. La limite de filtrage à 1 000 groupes. Entra ID ne prend en charge le filtrage par groupes que si l'utilisateur appartient à 1 000 groupes ou moins, appartenances directes et transitives confondues (même source). Au-delà, l'architecture doit basculer sur un autre modèle d'autorisation, par exemple des rôles applicatifs plutôt que des groupes bruts.

4. La révocation et la latence de réindexation. Retirer un utilisateur d'un groupe prend effet immédiatement si vous résolvez ses groupes à chaque requête. En revanche, si un document est reclassé ou voit ses permissions modifiées, son tag acl dans l'index reste figé jusqu'à la réindexation. Estimation IgnitionAI fondée sur nos 3 missions 2024-2025 : prévoir une réindexation incrémentale déclenchée par événement sur les changements de permissions, pas seulement un batch nocturne, sous peine d'une fenêtre d'exposition de plusieurs heures.

5. Les règles deny et les permissions uniques. Un document peut rompre l'héritage de son site et porter une règle de refus explicite, qui prime sur l'autorisation de groupe. Un filtre qui ne raisonne qu'en « groupes autorisés » laissera passer ce document. Le tag ACL à l'ingestion doit refléter les permissions effectives du document, pas celles supposées de son emplacement.

6. Les comptes désactivés et les liens de partage. Un compte désactivé doit perdre l'accès immédiatement, ce qui suppose d'invalider tout cache de groupes. Et les liens de partage de type « toute personne disposant du lien » accordent un accès qui ne passe par aucun groupe : ils sont invisibles à un filtre fondé sur l'appartenance. Ces liens doivent être audités et révoqués en amont, pas contournés au niveau du RAG.

Réduire la surface avant de brancher le RAG

Le cas d'ouverture de cet article ne vient pas du RAG, mais d'un périmètre de permissions trop large hérité d'années de partages. La première action n'est donc pas technique côté IA, elle est de gouvernance côté source.

Deux leviers Microsoft existent pour cela. Restricted SharePoint Search limite la recherche organisationnelle et Copilot à une liste de sites explicitement validés, jusqu'à 100 sites, désactivée par défaut. Elle existe précisément pour donner le temps d'auditer les permissions avant d'ouvrir l'index (Microsoft, Restricted SharePoint Search, consultée juin 2026). Les sensitivity labels Microsoft Purview classent et chiffrent les documents sensibles, et cette classification se propage à SharePoint et OneDrive (Microsoft Purview, sensitivity labels, consultée juin 2026).

Le même principe vaut pour un RAG sur mesure : l'index ne doit ingérer que des sources dont les permissions ont été auditées. Un RAG branché sur un périmètre non audité transforme un oversharing latent en exposition actionnable en quelques jours.

Journalisation et conformité

Le contrôle d'accès n'est complet qu'avec sa trace. Chaque requête doit enregistrer l'utilisateur, les groupes résolus, les chunks retournés et la réponse générée. Cette journalisation répond à l'obligation de traçabilité de l'Article 12 du Règlement (UE) 2024/1689 sur l'IA pour les systèmes à risque élevé, et permet de répondre à un audit a posteriori.

Le droit à l'effacement de l'Article 17 du RGPD s'applique aux données indexées. Le champ version posé à l'ingestion permet la suppression ciblée des vecteurs concernés sans réindexation totale.

Hors écosystème Microsoft

Le schéma à trois niveaux ne dépend pas de Microsoft. Avec Okta, Keycloak ou un autre fournisseur d'identité, le principe reste identique : récupérer les groupes ou rôles de l'utilisateur via OIDC ou SCIM, tagger les chunks avec les autorisations de la source, filtrer en pré-retrieval.

Pour les cas où l'autorisation dépend d'attributs plutôt que de groupes (région, niveau d'habilitation, projet), le modèle ABAC remplace les listes de groupes par des règles sur attributs. Pour les relations complexes (un utilisateur accède à un document parce qu'il gère son auteur), le modèle ReBAC est plus adapté. Le point de filtrage, lui, ne change pas : avant la recherche de similarité, jamais après.

FAQ : RAG et permissions Active Directory

• Comment un RAG hérite-t-il des permissions Active Directory ?

  En propageant l'appartenance aux groupes de l'utilisateur jusqu'au filtre de recherche, sur trois niveaux. Premier : un tag ACL posé sur chaque chunk à l'ingestion, soit les groupes autorisés du document source. Deuxième : un filtre pré-retrieval à la requête, soit les groupes de l'utilisateur authentifié, résolus via Microsoft Graph. Troisième : une vérification à la réponse. Aucun document hors périmètre n'entre dans le contexte passé au LLM.

• Faut-il lire les groupes depuis le token Entra ID ou via Microsoft Graph ?

  Via Microsoft Graph dès que l'utilisateur appartient à beaucoup de groupes. Entra ID limite le token à 150 groupes en SAML et 200 en JWT ; au-delà, les groupes sont omis du token. L'appel transitiveMemberOf de Graph renvoie l'appartenance complète, groupes imbriqués compris, sans cette limite.

• Le filtrage par groupes a-t-il une limite ?

  Oui. Entra ID ne prend en charge le filtrage par groupes que si l'utilisateur appartient à 1 000 groupes ou moins, appartenances directes et transitives confondues. Au-delà, il faut basculer sur des rôles applicatifs ou un modèle d'autorisation par attributs (ABAC).

• Que se passe-t-il quand on retire un accès à un utilisateur ?

  Si les groupes sont résolus à chaque requête, le retrait prend effet immédiatement. Le cas plus délicat est la modification des permissions d'un document : son tag ACL dans l'index reste figé jusqu'à réindexation. Nous recommandons une réindexation incrémentale déclenchée par événement sur les changements de permissions, pour éviter une fenêtre d'exposition.

Méthodologie et sources

Sources techniques (consultées en juin 2026) :

• Microsoft Graph, List a user's transitive group membership : learn.microsoft.com/graph
• Microsoft Entra, Configure group claims for applications (groupes imbriqués, limites 150/200 et 1 000 groupes) : learn.microsoft.com/entra
• Microsoft, Restricted SharePoint Search : learn.microsoft.com/sharepoint
• Microsoft Purview, Sensitivity labels : learn.microsoft.com/purview
• Qdrant, Filtering : qdrant.tech

Sources réglementaires :

• Règlement (UE) 2024/1689 sur l'intelligence artificielle, Article 12 (journalisation) : EUR-Lex
• Règlement (UE) 2016/679 (RGPD), Article 17 (droit à l'effacement) : EUR-Lex

Estimations IgnitionAI : les recommandations d'architecture (réindexation incrémentale, audit du périmètre avant ingestion) reposent sur 3 missions de conception ou d'audit RAG livrées en 2024-2025 auprès d'ETI françaises de secteurs régulés. Variation possible selon le contexte. Voir notre politique éditoriale.

Dernière relecture des sources : 2026-06-14.

Articles connexes IgnitionAI :

• Contrôle d'accès dans un RAG d'entreprise : 5 architectures comparées
• Microsoft 365 Copilot : l'audit de gouvernance que personne ne fait
• RAG d'entreprise en production : 5 décisions critiques que vos premiers POC vous cachent

Vous concevez un RAG qui doit respecter les droits d'accès de votre Active Directory ? Notre cadrage de deux semaines couvre l'audit du périmètre, le modèle d'autorisation et l'architecture cible, avec un go/no-go écrit. Demander un échange.