Droits d'accès et IA d'entreprise : empêcher un assistant de contourner le cloisonnement

Les droits d'accès d'une IA d'entreprise désignent l'ensemble des règles qui déterminent quelles informations un assistant ou un agent IA peut lire, restituer ou utiliser, et pour le compte de qui. Le cloisonnement est le résultat attendu de ces règles : chaque utilisateur n'obtient, par l'intermédiaire de l'IA, que ce qu'il aurait eu le droit de consulter directement.

La difficulté est nouvelle. Un dossier partagé ou un CRM applique ses permissions au moment où l'on ouvre un fichier. Une IA, elle, lit des centaines de documents, les découpe, les indexe, les résume et les recompose dans une réponse. À chacune de ces étapes, la permission d'origine peut se perdre. Ce guide explique comment un assistant IA peut contourner les permissions, pourquoi il révèle souvent un sur-partage qui existait déjà, ce qu'exigent les textes (RGPD, CNIL, ANSSI, secret professionnel) et comment construire un cloisonnement vérifiable en sept étapes. Il appartient à notre série sur le deuxième cerveau, l'IA agentique et l'IA en environnement réglementé, et approfondit un point seulement esquissé dans notre guide sur l'injection de prompt.

Droits d'accès d'une IA : définitions et vocabulaire

Le sujet mêle des notions de sécurité informatique et de conformité qu'il vaut mieux poser avant d'aller plus loin. Elles sont employées dans le même sens dans le reste de cette série.

• Habilitation : autorisation donnée à une personne d'accéder à une catégorie de données ou à une fonction. La CNIL en fait une fiche à part entière de son guide de la sécurité des données personnelles.
• Besoin d'en connaître : principe selon lequel une personne n'accède qu'aux informations nécessaires à sa mission, même si son rang ou sa fonction lui permettraient d'en voir davantage.
• Moindre privilège : traduction technique du besoin d'en connaître ; chaque compte, humain ou logiciel, reçoit les droits minimaux pour sa tâche.
• Cloisonnement : séparation effective des informations entre entités, équipes, rôles ou dossiers, de sorte qu'une information d'un compartiment ne fuie pas vers un autre.
• Sur-partage (oversharing) : situation où des documents sont accessibles à plus de personnes que nécessaire, souvent par accumulation de liens de partage, de groupes trop larges ou de règles héritées.

Ce qui change avec l'IA. L'Agence nationale de la sécurité des systèmes d'information l'écrit sans détour dans ses recommandations de sécurité pour un système d'IA générative (ANSSI-PA-102, avril 2024) : l'accès à un système d'IA « complexifie » l'application du besoin d'en connaître, et le système doit intégrer la question des droits d'accès dans les réponses qu'il apporte. L'ANSSI distingue trois catégories de données :

La conséquence pratique est importante. Une information confidentielle ne doit pas servir à entraîner ou affiner un modèle partagé par des utilisateurs qui n'ont pas à la connaître : c'est l'objet de la recommandation R18 de l'ANSSI. Le cloisonnement se joue donc dans la seconde catégorie, celle des documents consultés à la volée, et c'est là que surviennent la plupart des contournements.

Comment un assistant IA peut contourner les permissions : cinq mécanismes

Un contournement de permissions par une IA est rarement le fait d'une attaque. Il résulte le plus souvent d'un choix d'architecture fait sans penser aux droits. Voici les cinq mécanismes les plus courants, décrits de manière vulgarisée.

1. Le compte technique à droits larges. Pour relier une IA à une messagerie, un espace documentaire ou un CRM, on crée un connecteur. S'il fonctionne avec un compte de service qui voit tout, plutôt qu'au nom de l'utilisateur qui pose la question, l'IA hérite des droits de ce compte et non de ceux de l'utilisateur. N'importe quel collaborateur peut alors obtenir, en posant la bonne question, ce que seul l'administrateur pouvait lire. L'OWASP range ce défaut parmi les causes d'agence excessive (LLM06:2025, « permissions excessives »).

2. L'index qui oublie les droits. Pour répondre vite, l'IA ne relit pas les documents d'origine : elle interroge un index, souvent une base vectorielle, où les textes ont été découpés en fragments. Si les droits du document source ne sont pas recopiés sur chaque fragment, ils disparaissent. Le référentiel OWASP LLM08:2025 (faiblesses des vecteurs et des représentations) décrit précisément ce risque d'accès non autorisé et de fuite entre utilisateurs, et recommande des bases « tenant compte des permissions », avec un partitionnement logique strict.

3. Le contenu dérivé sans étiquette. Une IA produit des résumés, des synthèses de dossier, des fiches de préparation de rendez-vous, une « mémoire » des échanges. Ces contenus dérivés reprennent l'information de documents protégés, mais ils sont souvent stockés ailleurs, sans les restrictions de la source. Un résumé du dossier d'un dirigeant, rangé dans un espace commun, en dit parfois plus que le dossier lui-même.

4. Le décalage de synchronisation. Un collaborateur change d'équipe, un client retire son autorisation, un document est déplacé dans un dossier restreint. Si l'index de l'IA n'est mis à jour que périodiquement, l'ancien droit reste actif dans l'IA pendant des heures ou des jours. La révocation est effective dans l'outil source, pas encore dans l'assistant.

5. L'agrégation (effet mosaïque). Chaque information prise isolément peut être accessible à tous : un rendez-vous dans un agenda partagé, une mention dans un compte rendu, une ligne dans un tableau de suivi. Rapprochées par une IA capable de tout lire en quelques secondes, elles peuvent révéler une information sensible que personne n'avait écrite, par exemple qu'un client prépare une cession ou traverse un divorce. Ce risque n'est pas réglé par les droits d'accès document par document ; il relève de l'analyse de risque et du choix des sources reliées.

Masquer n'est pas cloisonner. Une parade fréquente consiste à laisser l'IA lire tous les documents, puis à filtrer ou censurer sa réponse. C'est insuffisant. Le modèle a déjà lu l'information ; elle peut ressortir reformulée, en creux (« je ne peux pas vous parler du dossier X »), ou à la faveur d'une injection de prompt. Le seul filtrage robuste est celui qui écarte un document avant qu'il entre dans le contexte du modèle.

Sur-partage : quand l'IA respecte les droits, mais que les droits sont trop larges

Le cas inverse est tout aussi fréquent, et souvent plus surprenant pour les dirigeants. L'IA respecte scrupuleusement les permissions existantes, et c'est précisément ce qui pose problème.

Microsoft le documente pour son propre assistant : sa documentation de préparation à Copilot (mise à jour en août 2026) rappelle que l'assistant et les agents récupèrent les données en « respectant les permissions, paramètres de partage et politiques existants », et invite les administrateurs à traiter le sur-partage avant le déploiement. Elle précise que les paramètres de partage de SharePoint sont, par défaut, réglés sur l'option la plus permissive, et liste les signaux de risque à rechercher : liens ouverts à « tout le monde » ou à toute l'organisation, groupes trop larges, héritage de permissions rompu, sites sans propriétaire.

Accessible n'est pas trouvable. Avant l'IA, un document mal partagé restait en pratique protégé par son obscurité : il fallait connaître son existence, son emplacement, son nom. Une IA supprime cette protection de fait. Elle ne crée pas l'exposition, elle la rend trouvable en une question. Un tableau des rémunérations déposé il y a trois ans dans un dossier commun devient, du jour au lendemain, une réponse possible à « combien gagne tel collègue ? ».

D'où une règle de prudence : auditer les droits avant de brancher l'IA, et non après le premier incident. L'outil de Microsoft propose d'ailleurs un mécanisme intermédiaire, la « découverte restreinte de contenu », qui laisse les permissions d'un site inchangées mais l'exclut des réponses de l'assistant le temps de le remettre en ordre. Quelle que soit la solution retenue, le principe est transposable : on peut exclure une source du périmètre de l'IA tant que ses droits n'ont pas été revus. Notre guide sur la cartographie des sources avant un projet d'IA propose de traiter les droits comme l'une des six couches à documenter pour chaque source.

Le paramétrage des droits fait partie du déploiement

Si vous envisagez de relier vos emails, vos documents et votre CRM à une mémoire commune, la question des droits se pose dès le premier jour. Pour Brain, elle est traitée au déploiement : chaque collaborateur n'accède qu'au périmètre qui le concerne, les droits se règlent par collaborateur et par périmètre, les usages sont tracés et les accès aux outils connectés restent révocables à tout moment. La page Sécurité & souveraineté détaille ces engagements.

Voir la gouvernance de Brain Découvrir la méthode

Droits par collaborateur et par périmètre • Traçabilité des usages • Accès révocables

Trois niveaux de cloisonnement dans un deuxième cerveau

Un deuxième cerveau d'entreprise rassemble des faits, des documents, des échanges et des décisions. Le cloisonnement s'y organise à trois niveaux complémentaires, du plus large au plus fin.

Rôle ou périmètre ? Le contrôle par rôle (RBAC, role-based access control) est simple à gérer, mais grossier : tous les conseillers voient tous les clients. Le contrôle par périmètre, ou par attributs, est plus précis mais exige une donnée fiable sur « qui suit quel dossier ». Dans une petite structure, une combinaison des deux suffit généralement : un rôle donne accès à un type d'information, un périmètre restreint ce rôle à certains dossiers, et quelques dossiers sensibles font l'objet d'une liste nominative.

Les droits de l'IA ne dépassent jamais ceux de l'utilisateur. C'est la règle structurante. Un agent IA qui agit pour une personne ne doit lire que ce que cette personne peut lire. Un agent qui travaille pour toute l'organisation (préparer un tableau de bord, surveiller des échéances) doit avoir un périmètre propre, écrit et limité, et ses productions doivent être diffusées selon les droits de leurs destinataires, pas selon les siens. La page Sécurité de Brain indique d'ailleurs que chaque agent n'accède qu'au périmètre concerné.

Le cas des données d'usage. Les questions posées à l'IA sont elles-mêmes des informations. « Préparer la lettre de licenciement de X » ou « simuler la donation de Mme Y à son fils » révèlent beaucoup. Les historiques de conversation, et toute mémoire que l'IA constitue à partir d'eux, doivent donc rester attachés à leur auteur, sauf partage volontaire. C'est le même raisonnement que pour les contenus dérivés : ils héritent de la sensibilité de ce qu'ils contiennent.

Ce qu'exigent les textes : RGPD, CNIL, ANSSI et secret professionnel

Aucun texte ne parle spécifiquement des « droits d'accès d'une IA ». Mais plusieurs obligations générales s'appliquent pleinement dès qu'une IA restitue des données personnelles ou couvertes par un secret.

L'ANSSI insiste sur les réglages par défaut. Sa recommandation R35 vise expressément les outils d'IA tiers qui se connectent aux mails, aux espaces documentaires, aux dépôts de code et aux services de visioconférence : il faut vérifier, dès l'activation, que les droits positionnés par défaut ne sont pas « trop laxistes ou trop ouverts par conception », puis contrôler que les mises à jour fonctionnelles du produit ne changent pas le besoin d'en connaître.

Un exemple propre aux professions financières. Les professionnels assujettis à la lutte contre le blanchiment ont l'interdiction de porter à la connaissance du client ou de tiers l'existence et le contenu d'une déclaration de soupçon (article L. 561-18 du Code monétaire et financier). Une IA qui aurait accès aux notes de vigilance et qui rédige un projet d'email au client, ou répond à un collaborateur non concerné, ferait courir un risque réel. Ce type de dossier relève d'un compartiment à part, accessible aux seules personnes désignées, et c'est un bon test de tout dispositif : la note la plus sensible du cabinet est-elle réellement hors de portée de l'assistant pour tous les autres ? Notre guide sur l'IA et le secret professionnel détaille le trajet des données et les architectures possibles.

Méthode en sept étapes pour cloisonner une IA d'entreprise

La méthode suivante s'applique à une petite ou moyenne structure qui relie, ou s'apprête à relier, une IA à ses outils. Elle ne suppose pas d'équipe de sécurité dédiée.

1. Inventorier qui voit quoi aujourd'hui. Pour chaque source envisagée (messagerie, espace documentaire, CRM, agenda), notez qui y a accès, par quel mécanisme (compte nominatif, groupe, lien de partage) et depuis quand. C'est la couche « droits » de la cartographie des sources.
2. Nettoyer le sur-partage avant de brancher. Supprimez les liens ouverts à tous, les groupes « tout le personnel » posés par commodité, les accès d'anciens collaborateurs. Une source dont les droits n'ont pas été revus reste hors du périmètre de l'IA.
3. Écrire la matrice rôles × périmètres. Quelques rôles, quelques familles d'information, une case par croisement (voir l'exemple ci-dessous). La matrice se valide par la direction, comme toute habilitation selon la CNIL.
4. Exiger un accès au nom de l'utilisateur. Le connecteur doit interroger les sources avec les droits de la personne qui pose la question, ou appliquer un filtre équivalent avant la recherche. Refusez les architectures où l'IA lit tout puis masque.
5. Tester le cloisonnement avec des comptes de rôles différents. Préparez une dizaine de questions pièges (« résume le dossier X », « qui a fait l'objet d'une alerte ce trimestre ? », « quelles sont les rémunérations de l'équipe ? ») et posez-les depuis chaque profil. Vérifiez aussi les sources citées : une réponse doit toujours indiquer d'où vient l'information, ce qui rend les fuites visibles (voir notre guide sur la fiabilité des réponses d'une IA).
6. Journaliser et revoir. Conservez la trace de qui a interrogé quoi et quelles sources ont été utilisées (ANSSI, R29). Revoyez les droits de l'IA après chaque mise à jour notable de l'outil et à intervalle fixe ; l'ANSSI cite une fréquence mensuelle, la CNIL un minimum annuel pour les habilitations.
7. Gérer les mouvements. Arrivée, absence longue, réaffectation de portefeuille, départ : chaque mouvement modifie le périmètre dans l'IA le jour même. Vérifiez que l'index et les mémoires suivent, et pas seulement l'annuaire.

Exemple de matrice pour un cabinet fictif. Prenons un cabinet de conseil patrimonial fictif de sept personnes : deux associés, trois conseillers, une assistante, une responsable conformité.

Cette matrice est une illustration, pas un modèle réglementaire : chaque structure l'adapte à son organisation. Elle montre surtout que l'IA ne crée pas de nouvelle règle ; elle applique, ou trahit, celles que l'organisation a déjà. Les données de santé, catégorie particulière au sens de l'article 9 du RGPD, et les données RH justifient presque toujours un compartiment séparé. La matrice gagne à être annexée à la charte d'usage de l'IA.

Questions à poser à un fournisseur d'IA sur les droits d'accès

Les réponses à ces questions disent davantage sur la maturité d'un outil que n'importe quelle démonstration. Exigez-les par écrit.

1. Les sources sont-elles interrogées avec les droits de l'utilisateur qui pose la question, ou avec un compte technique ?
2. Le filtrage par droits intervient-il avant la recherche dans l'index, ou après la génération de la réponse ?
3. En combien de temps une révocation dans l'outil source (départ, changement d'équipe) est-elle prise en compte par l'IA ?
4. Les résumés, synthèses et mémoires produits par l'IA héritent-ils des droits de leurs sources ?
5. Les historiques de conversation sont-ils visibles par d'autres utilisateurs, par l'administrateur, par l'éditeur ?
6. Vos clients sont-ils séparés techniquement les uns des autres (index, mémoires, modèles affinés) ?
7. Mes données servent-elles à entraîner un modèle utilisé par d'autres ?
8. Quels journaux d'accès puis-je consulter, et pendant combien de temps sont-ils conservés ?

Les réponses ont aussi leur place dans le contrat, notamment dans l'accord de traitement prévu par l'article 28 du RGPD. Les mesures générales de protection du cabinet restent nécessaires ; elles sont rappelées dans notre guide sur la sécurité des données en cabinet.

Où se place Brain. Majors Brain relie les sources d'une organisation (messagerie, agenda, espace documentaire, CRM) à une mémoire commune. Sa page sécurité indique que le déploiement inclut le paramétrage fin des droits, par collaborateur et par périmètre, avec une traçabilité des usages, et que les données n'entraînent aucun modèle public. Sa méthode commence par une cartographie des sources, puis un périmètre initial de deux ou trois sources, testé sur des dossiers réels avant tout élargissement. Ce rythme progressif a un avantage direct pour le cloisonnement : on revoit les droits d'un petit nombre de sources, on les teste, puis on étend. Les questions ci-dessus s'appliquent à Brain comme à tout autre outil.