Votre assistant IA voit-il plus que vos utilisateurs ?

L'assistant IA que vous déployez sur vos données internes est une bombe à retardement si vous le connectez avec un compte de service unique. Le risque que tout le monde redoute, c'est l'attaque externe : un pirate qui aspire la base de données. Le risque réel, celui qui se matérialise tous les jours dans les entreprises qui ont sauté l'étape de conception des habilitations, c'est la fuite latérale entre équipes : un collaborateur habilité qui obtient par l'assistant ce que l'écran de l'application lui refuse.

Cet article traite la couche IA comme un utilisateur de plus, soumis aux mêmes habilitations que vos collaborateurs humains, et distingue deux architectures aux conséquences opposées : l'index unique consulté avec un compte de service contre la requête exécutée sous l'identité de l'utilisateur. Il ajoute la journalisation des interrogations et des exports comme exigence à part entière, parce que ce qui compte, ce n'est pas seulement qui peut voir quoi, mais aussi qui pourra reconstituer six mois après ce qui a été vu.

La fuite qu'on redoute vient de l'intérieur, pas de l'extérieur

Le scénario classique lors des appels d'offres : un RSSI demande comment vous empêchez une intrusion externe d'aspirer toute la documentation interne via l'assistant IA. La réponse est triviale : chiffrement en transit, authentification OAuth, segmentation réseau, audit des logs d'accès. C'est important, mais ce n'est pas le vrai problème.

Le vrai problème, c'est le collaborateur légitime qui pose une question anodine et obtient une réponse qu'il n'aurait jamais dû voir. Trois cas concrets, tous relevés lors d'audits clients au cours des six derniers mois :

1. Un acheteur junior interroge l'assistant sur les délais moyens de paiement des fournisseurs. L'assistant cite un tableau de bord financier auquel l'acheteur n'a pas accès dans le système de gestion, avec des chiffres de trésorerie que seule la direction financière devrait voir.

2. Un responsable marketing demande un résumé des performances de la campagne en cours. L'assistant inclut dans sa réponse des données issues du CRM commercial, notamment les marges par client, alors que l'équipe marketing n'a jamais eu accès aux marges.

3. Un chargé de projet interroge l'assistant sur l'avancement d'un dossier. L'assistant cite un email interne entre direction générale et direction juridique, classé confidentiel, parce que l'index contient tous les emails du serveur Exchange.

Dans les trois cas, l'assistant a fonctionné exactement comme prévu : il a cherché l'information dans l'index, l'a trouvée, et l'a restituée. Le problème n'est pas un bug technique, c'est une architecture où l'IA a accès à tout et filtre après coup, ce qui revient à ne rien filtrer du tout.

Deux architectures, deux niveaux de risque : compte de service contre identité de l'utilisateur

Il existe deux façons de concevoir les habilitations d'un assistant IA sur des données internes.

Architecture 1 : index unique avec compte de service. Toutes les données sont indexées dans un moteur de recherche unique (Elasticsearch, Azure Cognitive Search, base vectorielle). L'assistant IA interroge cet index avec un compte de service doté de droits de lecture universels. Les habilitations utilisateur sont censées être appliquées après la recherche, au moment où l'assistant filtre les résultats avant de les afficher.

C'est l'approche par défaut de 80 pour cent des déploiements que nous avons audités, parce que c'est la plus simple à mettre en œuvre et la mieux documentée par les fournisseurs de plateformes RAG. Le souci, c'est que cette architecture transforme l'IA en contournement de toutes les habilitations métier.

Pourquoi ? Parce que filtrer après coup revient à demander à l'IA de refaire le travail du système de gestion des droits, alors qu'elle n'a aucune visibilité sur les règles métier qui régissent ces droits. Un exemple : dans votre ERP, un acheteur peut voir les lignes de commande de son périmètre géographique, mais pas les marges négociées au niveau groupe. Cette règle n'est pas un simple filtre "champ marge = masqué", c'est une logique applicative qui combine rôle, périmètre géographique, niveau hiérarchique, et type de contrat. Comment l'IA doit-elle la reproduire après avoir récupéré un document qui mélange tout ?

Réponse courte : elle ne peut pas. Donc elle renvoie tout, ou alors elle filtre sur des critères approximatifs qui laissent passer des fuites. Les deux scénarios ont été mesurés en production.

Architecture 2 : requête exécutée sous l'identité de l'utilisateur. L'IA n'a pas de compte de service. Quand un utilisateur pose une question, l'assistant transmet la requête aux systèmes sources (ERP, CRM, serveur de fichiers, base documentaire) en se faisant passer pour cet utilisateur, via un token OAuth ou une impersonation Kerberos. Les systèmes sources appliquent leurs propres règles d'habilitation, et ne renvoient que ce que l'utilisateur a le droit de voir.

C'est l'approche que nous recommandons depuis janvier 2026 à tout client qui gère des données sensibles ou des périmètres métier cloisonnés. Elle coûte plus cher à mettre en œuvre, parce qu'elle impose de connecter l'IA à chaque système source via son API authentifiée plutôt que de tout indexer dans un silo unique. Mais elle délègue la gestion des droits aux systèmes qui la connaissent déjà, au lieu de la recoder dans une couche IA qui n'a aucune légitimité à le faire.

Pourquoi filtrer la réponse après coup ne protège rien

Un fournisseur de plateforme RAG va vous dire : "notre système applique des filtres de sécurité sur les résultats avant de les afficher à l'utilisateur, donc même si l'IA interroge un index global, l'utilisateur ne verra que ce qu'il a le droit de voir."

Voici pourquoi cet argument ne tient pas.

Premier souci : le filtrage repose sur des métadonnées que personne ne maintient. Pour filtrer, il faut savoir qui peut voir quoi. Donc il faut que chaque document indexé porte des métadonnées de type "visible par : équipe Finance, rôle direction, niveau N+2". Dans les entreprises que nous avons auditées, ces métadonnées n'existent tout simplement pas, ou alors elles sont incohérentes entre systèmes. Résultat : soit l'index est ouvert à tous, soit il est fermé à tous, ce qui rend l'IA inutile.

Deuxième souci : les règles métier ne sont pas des tags. Les habilitations métier ne se réduisent jamais à une liste de tags. Elles combinent rôle, périmètre organisationnel, contexte de la donnée, et logique applicative. Exemple réel : un responsable achats peut voir les bons de commande signés de son périmètre, mais pas les devis en cours de négociation portés par un collègue du même service. Ce n'est pas un tag "visible par achats", c'est une règle "visible si signé ET périmètre utilisateur OU si propriétaire du dossier". Reproduire cette logique dans un filtre de recherche générique, c'est recoder tout l'ERP dans la couche IA.

Troisième souci : l'IA voit les données avant le filtrage. Même si le filtrage marchait parfaitement, l'IA a lu les données interdites pour pouvoir les filtrer. Or les modèles de langage actuels gardent une mémoire de session : si l'assistant a vu un document confidentiel dans une requête précédente, il peut en réutiliser des fragments dans une réponse ultérieure, même si le document filtré ne devrait plus être visible. Ce n'est pas un bug, c'est le fonctionnement normal d'un modèle à contexte long.

Bilan : le filtrage après coup est une illusion de sécurité. Il peut marcher sur des cas simples (un document public contre un document privé), mais il échoue dès que les règles d'habilitation reflètent une vraie organisation avec des périmètres métier.

Rôle et périmètre : deux dimensions distinctes que les fournisseurs confondent

Une confusion récurrente dans les cahiers des charges : demander au fournisseur "comment vous gérez les rôles utilisateur dans l'IA", et obtenir comme réponse "nous appliquons des filtres par équipe sur les résultats de recherche".

Rôle et périmètre sont deux dimensions distinctes.

Le rôle définit ce qu'un utilisateur peut faire : consulter, éditer, valider, exporter. Dans un ERP, un contrôleur de gestion a le rôle "lecture seule" sur les données comptables, alors qu'un comptable a le rôle "édition". Le rôle ne dit rien sur quelles données l'utilisateur peut voir, seulement ce qu'il peut en faire.

Le périmètre définit quelles données un utilisateur peut voir : son équipe, sa région, ses clients, ses dossiers. Dans un CRM, un commercial peut voir les opportunités de son portefeuille, alors qu'un directeur commercial peut voir toutes les opportunités de sa région. Le périmètre ne dit rien sur ce que l'utilisateur peut faire avec ces données, seulement lesquelles il peut toucher.

Un système d'habilitation complet combine les deux : rôle ET périmètre. Un acheteur junior a le rôle "lecture" sur le périmètre "fournisseurs de sa catégorie", alors qu'un directeur achats a le rôle "édition" sur le périmètre "tous fournisseurs groupe". Si votre fournisseur d'IA ne distingue pas les deux, il ne pourra pas reproduire les règles métier de vos applications.

Ce qui arrive aux droits d'un document quand il entre dans un index

Question posée par un DSI lors d'un atelier en mars 2026 : "quand on indexe un document SharePoint dans l'IA, est-ce que les droits SharePoint suivent le document dans l'index ?"

Réponse courte : non, sauf si vous le codez explicitement.

Par défaut, un indexeur (qu'il soit Elasticsearch, Pinecone, ou Azure AI Search) ne connaît rien aux habilitations du système source. Il aspire le contenu du document, il calcule ses embeddings vectoriels, il l'enregistre dans l'index, et il oublie tout le reste. Les droits SharePoint restent dans SharePoint.

Pour que les droits suivent le document, il faut que l'indexeur récupère les listes de contrôle d'accès (ACL) de chaque document et les stocke comme métadonnées dans l'index, puis que la couche de recherche filtre les résultats en fonction de l'utilisateur connecté. C'est techniquement faisable, mais c'est une personnalisation que 90 pour cent des fournisseurs ne livrent pas par défaut.

Conséquence pratique : si vous indexez un SharePoint avec des bibliothèques restreintes, et que vous interrogez cet index avec un compte de service, tous les documents deviennent visibles par tous les utilisateurs qui passent par l'IA, quels que soient les droits SharePoint. La fuite est structurelle.

Solution de repli : ne pas indexer, et forcer l'IA à interroger SharePoint via son API Graph avec le token de l'utilisateur connecté. SharePoint applique ses propres droits, et ne renvoie que ce que l'utilisateur peut voir. C'est l'architecture 2 décrite plus haut.

Journaliser les interrogations et les exports : ce que vous devez pouvoir reconstituer six mois après

Une fuite de données n'est jamais détectée le jour même. Elle est découverte trois mois, six mois, parfois un an après, lors d'un audit, d'un incident de sécurité, ou d'une plainte client. À ce moment-là, la question devient : qui a vu quoi, et quand ?

Pour y répondre, il faut que votre système journalise quatre éléments :

1. Qui a posé la question. Identité de l'utilisateur connecté, pas "compte de service IA". Si tous les logs indiquent "service-account-rag-prod", vous ne pourrez jamais retracer une fuite.

2. Quelle question a été posée. Le texte exact de la requête utilisateur, pas seulement "recherche effectuée". Une requête "quels sont les clients avec plus de 500 K€ de CA ?" n'a pas le même niveau de sensibilité qu'une requête "quelle est la météo à Casablanca ?".

3. Quels documents ont été consultés pour répondre. Les identifiants des documents récupérés par le RAG, avec leur système source (ERP, CRM, SharePoint, base documentaire). Si l'IA a cité un tableau de bord financier confidentiel, vous devez pouvoir retrouver quel fichier Excel a été utilisé.

4. Quelle réponse a été affichée à l'utilisateur. Le texte généré par l'IA, parce que c'est ce que l'utilisateur a effectivement vu. Un document peut contenir cent lignes, mais si l'IA n'en a cité qu'une seule, ce n'est pas la même exposition.

Ces quatre éléments doivent être enregistrés dans un système de logs immutable, avec horodatage et signature, pour pouvoir reconstituer une chronologie fiable lors d'un audit. Le RGPD et la loi marocaine 09-08 imposent tous deux la traçabilité des accès aux données personnelles, donc juridiquement, ce n'est pas optionnel.

En pratique, nous avons constaté que 60 pour cent des déploiements d'IA en entreprise ne journalisent rien au-delà de "requête exécutée". Aucune trace de l'utilisateur, aucune trace des documents consultés, aucune trace de la réponse affichée. Si une fuite se matérialise, l'entreprise ne pourra ni la prouver ni la quantifier, ce qui la met en défaut face à la CNDP ou à un tribunal.

Les six questions à poser au fournisseur, et les réponses qui doivent vous alerter

Voici six questions à poser à tout fournisseur de plateforme RAG ou d'assistant IA sur données internes. Les réponses indiquent si le fournisseur a pensé la sécurité dès la conception, ou si les habilitations sont un vernis rajouté après coup.

Question 1 : est-ce que l'IA interroge un index global avec un compte de service, ou est-ce qu'elle interroge les systèmes sources sous l'identité de l'utilisateur ?

Réponse attendue : sous l'identité de l'utilisateur, via des tokens OAuth ou impersonation. Si la réponse est "index global", demandez comment les habilitations sont appliquées, et qui maintient les métadonnées de droits.

Question 2 : si un document change de droits dans le système source (un fichier SharePoint devient confidentiel), combien de temps avant que l'index reflète ce changement ?

Réponse attendue : en temps réel, ou sous quinze minutes. Si la réponse est "ré-indexation hebdomadaire", vous avez une fenêtre de sept jours pendant laquelle un document confidentiel reste visible par tous.

Question 3 : est-ce que l'IA peut citer un document que l'utilisateur n'a pas le droit d'ouvrir dans l'application source ?

Réponse attendue : non, jamais, parce que l'IA ne reçoit que les documents autorisés. Si la réponse est "nous filtrons les résultats avant affichage", demandez comment ce filtre reproduit les règles métier du système source.

Question 4 : est-ce que les logs enregistrent l'identité de l'utilisateur qui a posé la question, ou seulement le compte de service qui a interrogé l'index ?

Réponse attendue : identité de l'utilisateur, dans un log immutable. Si la réponse est "nous loggons les requêtes système", vous ne pourrez jamais retracer une fuite.

Question 5 : si un utilisateur exporte une réponse de l'IA (copier-coller, PDF, capture d'écran), est-ce que cet export est journalisé ?

Réponse attendue : oui, avec identité utilisateur, horodatage, et contenu exporté. Si la réponse est "nous ne gérons pas les exports", vous avez un trou béant dans la traçabilité.

Question 6 : si je vous demande dans six mois qui a eu accès à tel document via l'IA, pouvez-vous me fournir la liste ?

Réponse attendue : oui, avec requête, réponse, et horodatage. Si la réponse est "nous ne conservons pas ces données", vous êtes en défaut RGPD dès qu'une donnée personnelle transite par l'IA.

Les trois premières questions testent l'architecture des habilitations. Les trois suivantes testent la traçabilité. Si un fournisseur échoue sur plus de deux questions, soit il n'a pas conçu son produit pour des données sensibles, soit il vous vend une sécurité cosmétique.

FAQ

Est-ce qu'on peut appliquer les mêmes habilitations à l'IA qu'à un utilisateur humain ?

Oui, c'est exactement ce que fait l'architecture par impersonation : l'IA interroge les systèmes sources en se faisant passer pour l'utilisateur connecté, donc elle hérite de ses habilitations. Le système source ne voit pas la différence entre une requête humaine et une requête IA, il applique les mêmes règles.

Si l'IA ne peut voir que ce que l'utilisateur peut voir, est-ce que ça limite son utilité ?

Non, parce que l'utilisateur pose des questions sur des données qu'il a déjà le droit de voir. L'IA ne sert pas à contourner les habilitations, elle sert à synthétiser et à croiser des données dispersées. Un acheteur qui interroge l'IA sur ses fournisseurs obtiendra une réponse utile même si l'IA ne voit que son périmètre, parce que c'est son périmètre qui l'intéresse.

Est-ce que filtrer les résultats après la recherche peut marcher si les métadonnées de droits sont bien maintenues ?

Sur des cas simples, oui. Sur des organisations réelles avec des règles métier complexes, non. Les métadonnées de droits ne sont jamais à jour, parce que personne n'a le temps de les maintenir manuellement, et parce que les règles métier changent plus vite que les tags. L'impersonation délègue cette maintenance au système source, qui la connaît déjà.

Comment journaliser les interrogations sans violer le RGPD ?

Le RGPD impose de journaliser les accès aux données personnelles, donc enregistrer qui a consulté quoi est une obligation, pas une violation. Ce qui compte, c'est de sécuriser les logs (chiffrement, accès restreint, durée de rétention limitée) et de les utiliser uniquement pour l'audit et la sécurité, jamais pour de la surveillance généralisée.

Est-ce qu'un utilisateur peut extraire des données via l'IA même s'il n'a pas le droit de les exporter dans l'application source ?

Oui, si l'IA permet le copier-coller ou la génération de PDF sans contrôle. C'est pour ça que les exports doivent être journalisés et, dans certains cas, bloqués. Un utilisateur qui a le droit de consulter un document n'a pas forcément le droit de l'exporter, et l'IA doit respecter cette distinction.

Besoin d'auditer vos habilitations IA ou de concevoir une architecture sécurisée pour vos données internes ? Nous accompagnons les entreprises dans la mise en place de systèmes RAG conformes aux exigences métier et réglementaires. Découvrez notre offre RAG entreprise et notre accompagnement en conseil digital.