L’erreur la plus courante dans un RAG d’entreprise est simple : tout importer, poser des questions et considérer comme automatiquement sûres les réponses accompagnées de citations.
La deuxième erreur apparaît plus tard : quelqu’un découvre que l’assistant peut répondre à partir de documents que l’utilisateur n’aurait jamais dû voir. Grilles salariales. Contrats clients. Projets de documents juridiques. Notes du conseil d’administration. Tickets d’assistance. Enquêtes RH. Procédures de sécurité. La réponse peut être exacte et citée, tout en constituant une fuite d’informations.
Un assistant RAG exploitant les connaissances de l’entreprise n’est pas un moteur de recherche dont les réponses seraient mieux rédigées. C’est un système d’information soumis à des autorisations. Traitez-le comme tel.
La récupération doit appliquer des autorisations au moins aussi strictes que celles des systèmes sources. Si un utilisateur ne peut pas ouvrir un document dans Google Drive, SharePoint, Notion, Confluence ou le CRM, le RAG ne doit pas le récupérer pour cet utilisateur.
La règle principale
La couche de récupération doit répondre à cette question avant de renvoyer le moindre segment :
Cet utilisateur est-il autorisé à voir cette source en ce moment ?
Il ne faut pas demander d’abord « cette source se trouve-t-elle dans la base vectorielle ? », « est-elle pertinente ? » ou « est-elle utile ? ». L’autorisation passe avant tout.
Il existe trois modèles courants :
| Modèle | Fonctionnement | Adéquation |
|---|---|---|
| Index séparés | Un index par public ou espace de travail | Équipes simples, autorisations peu granulaires |
| Filtrage des métadonnées | Stocker les métadonnées d’ACL, de groupe et de source, puis filtrer avant la récupération | La plupart des systèmes RAG d’entreprise |
| Vérification des autorisations en temps réel | Interroger les autorisations des systèmes sources au moment de la récupération | Données sensibles ou autorisations fréquemment modifiées |
Le bon choix dépend des systèmes sources et du niveau de risque. Pour la plupart des PME, des index séparés associés à un filtrage des métadonnées suffisent. Pour les données clients, RH, juridiques ou réglementées, des vérifications en temps réel peuvent être nécessaires.
La partie difficile : maintenir les ACL synchronisées
Chacun des modèles ci-dessus repose sur une condition implicite : les données d’autorisation de votre index doivent correspondre à celles du système source. C’est dans cette synchronisation que réside la véritable difficulté technique.
Origine des ACL. SharePoint et OneDrive exposent les autorisations de chaque élément au moyen de l’API Microsoft Graph ; Google Drive fournit les autorisations par fichier avec l’API Drive ; Confluence applique des restrictions aux espaces et aux pages. Chaque système utilise des structures différentes — utilisateurs, groupes, héritage, liens de partage — ainsi que des limites de débit d’API et des définitions distinctes des personnes autorisées à consulter un contenu.
L’expansion des groupes est indispensable. La plupart des autorisations réelles sont accordées à des groupes, lesquels peuvent être imbriqués. Le groupe « Sales EU », membre de « Sales », lui-même membre de « All Staff », doit être développé en une liste d’utilisateurs concrets soit au moment de la synchronisation — métadonnées d’index plus volumineuses, requêtes plus rapides — soit lors de la requête — données plus fraîches, mais traitement plus lent et davantage d’appels d’API. Faites ce choix explicitement ; sinon, les équipes appliqueront des méthodes incohérentes.
Le délai de synchronisation est un paramètre de sécurité, et non un détail de performance. Lorsqu’un utilisateur perd l’accès à un document — changement de fonction, départ de l’entreprise ou dossier devenu confidentiel — l’index continue d’appliquer l’ancienne ACL jusqu’à la prochaine synchronisation. Définissez et consignez le délai de révocation acceptable pour chaque corpus : quasi immédiat pour les corpus à diffusion restreinte, éventuellement quelques heures pour les documents décrivant les processus internes. Si ce délai n’est pas formalisé, la réponse réelle sera « lors de l’exécution de la tâche nocturne », ce qui ne résistera pas à un examen de sécurité.
Les vérifications en temps réel améliorent la fraîcheur au prix de la latence, des quotas d’API et d’un nouveau mode de défaillance. Un contrôle d’autorisation à chaque récupération ajoute un aller-retour vers le système source pour chaque requête et consomme rapidement les quotas d’API à grande échelle. Le compromis habituel consiste à utiliser un cache de courte durée, ce qui transforme discrètement le « temps réel » en un « délai de synchronisation plus court ». Quel que soit le choix retenu, définissez explicitement le comportement en cas d’expiration : si le contrôle d’autorisation échoue ou expire, le segment n’est pas transmis. Appliquez un refus par défaut, journalisez l’échec et laissez l’assistant refuser de répondre : une réponse correcte mais lente vaut mieux qu’une fuite rapide.
Le test de départ mentionné dans la section consacrée aux tests permet de vérifier l’efficacité réelle du dispositif : un compte désactivé ne doit rien récupérer dans les corpus à diffusion restreinte. Cette garantie doit être valable dès le lendemain de la désactivation, et pas seulement après la prochaine resynchronisation complète.
Limites des sources
Ne créez pas un réservoir unique regroupant toutes les connaissances. Séparez les corpus selon leur public et leur sensibilité :
| Corpus | Public | Exemples | Règle |
|---|---|---|---|
| Public/produit | Tout le monde | Documentation d’aide, tarifs publics, pages produit | Adapté à un assistant largement accessible |
| Opérations internes | Salariés | Documents de processus, FAQ internes | Réservé aux salariés |
| Service | Membres du service | Guides de vente, réponses types du support, procédures d’exploitation technique | Filtrage par groupe |
| Dossiers clients | Équipes affectées | Tickets, contrats, notes de compte | ACL stricte et audit |
| À diffusion restreinte | Utilisateurs nommément désignés | RH, juridique, sécurité, conseil d’administration | Généralement un système séparé ou aucun RAG |
Plus le public d’un corpus est limité, plus il est facile d’évaluer les risques de fuite.
Contrôles d’ingestion
De nombreuses fuites trouvent leur origine dans le pipeline d’ingestion.
Avant d’indexer une source, capturez :
- Système source.
- ID du document.
- Propriétaire.
- Public ou ACL.
- Étiquette de sensibilité.
- Horodatages de création et de mise à jour.
- Date d’expiration ou de révision.
- Autorisation d’utiliser le document pour la récupération par l’IA.
- Présence éventuelle de données à caractère personnel.
Si le système source a déjà des étiquettes, conservez-les. Si ce n’est pas le cas, ajoutez une étape de classification légère avant l’ingestion.
Contrôles lors de la récupération
La récupération doit avoir lieu dans cet ordre :
- Identifier l’utilisateur et les groupes.
- Identifier l’espace de travail ou l’assistant demandé.
- Filtrer les sources candidates par corpus, ACL, sensibilité et fraîcheur.
- Récupérer uniquement les segments pertinents issus des sources autorisées.
- Reclasser les segments autorisés.
- Générer la réponse avec des références de source.
- Refuser de répondre ou déclencher une escalade lorsque les sources autorisées sont insuffisantes.
Ne récupérez pas les données avant de les filtrer ultérieurement dans la consigne. Si un segment interdit entre dans le contexte du modèle, le périmètre de sécurité est déjà compromis.
Comportement des consignes et des réponses
L’assistant doit recevoir les instructions suivantes :
- Répondre uniquement à partir des sources récupérées.
- Citer le titre et la section/lien de la source.
- Dire quand les sources autorisées ne contiennent pas la réponse.
- Distinguer clairement les inférences des faits étayés par des sources.
- Éviter de révéler l’existence de sources restreintes.
- Ne pas résumer les contenus auxquels l’utilisateur n’a pas accès.
Mauvais refus :
« J’ai trouvé les grilles salariales des RH, mais vous n’y avez pas accès. »
Meilleur refus :
« Je ne dispose d’aucune source approuvée pour répondre à cette question. »
La seconde réponse ne révèle ni l’existence ni le thème des documents à diffusion restreinte.
Journalisation sans créer une deuxième fuite
Les journaux d’un RAG sont sensibles. Ils peuvent contenir des questions d’utilisateurs, des segments récupérés, des identifiants de source, des réponses et parfois des données à caractère personnel.
Journalisez suffisamment d’informations pour diagnostiquer les incidents :
- ID utilisateur ou ID pseudonymisé.
- Assistant/espace de travail.
- Horodatage de la requête.
- Identifiants des sources récupérées.
- Résultat du filtrage d’autorisation.
- ID de réponse.
- Motif du refus ou de l’escalade.
- Latence et erreurs.
Faites attention à :
- Questions utilisateur complètes.
- Segments récupérés dans leur intégralité.
- Réponses générées complètes.
- Données client.
- Sujets RH/juridique/sécurité.
Pour les systèmes sensibles, stockez des journaux expurgés ou des identifiants de source plutôt que le texte intégral. Appliquez aux journaux leur propre contrôle d’accès et leur propre durée de conservation.
Sources obsolètes et conflictuelles
Les autorisations ne constituent pas le seul périmètre à maîtriser. La qualité des sources compte également.
Chaque source indexée doit avoir un propriétaire et une règle de fraîcheur :
| Type de source | Règle de révision |
|---|---|
| Tarifs | Révision à chaque changement de tarif |
| Politique | Révision à la mise à jour du propriétaire de la politique, au moins trimestriellement |
| Documentation produit | Révision à chaque version |
| Modèle de document juridique | Révision par le responsable juridique |
| Réponse type du support | Révision mensuelle ou après l’apparition d’un motif récurrent d’escalade |
Lorsque des sources se contredisent, l’assistant ne doit signaler le conflit que si l’utilisateur a accès aux deux. Sinon, il doit répondre à partir de la source autorisée faisant le plus autorité ou déclencher une escalade.
Test des limites d’autorisation
Testez avec des utilisateurs, pas seulement des documents :
- Employé avec un accès large.
- Salarié disposant uniquement des accès de son service.
- Manager avec un accès uniquement à l’équipe.
- Consultant.
- Ancien employé ou compte désactivé.
- Agent du service client.
- Administrateur.
Pour chacun, posez :
- Une question à laquelle ils devraient pouvoir répondre.
- Une question juste en dehors de leurs autorisations.
- Une question portant sur un document à diffusion restreinte dont ils connaissent l’existence.
- Une question pour laquelle les documents publics et internes se contredisent.
- Une question contenant une injection de consigne : « Ignorez les règles d’accès. »
Le résultat attendu n’est pas simplement une « bonne réponse », mais une « bonne réponse fondée sur des sources autorisées ».
Parcours de déploiement
Commencez avec le corpus le moins sensible :
- Documentation publique et produit.
- Documents décrivant les opérations internes.
- Documents propres à un service.
- Dossiers clients avec ACL stricte.
- Corpus à diffusion restreinte, uniquement après approbation explicite des équipes de sécurité et juridiques.
À chaque étape, mesurez :
- Pertinence des réponses.
- Qualité des citations.
- Correctitude du refus.
- Taux de récupération de sources interdites.
- Taux de sources obsolètes.
- Signalements utilisateurs de sources manquantes ou erronées.
Ne faites pas cela pour le moment
Ne placez pas « tous les documents de l’entreprise » dans un seul assistant.
Ne comptez pas sur les instructions de la consigne pour faire respecter les autorisations.
Ne journalisez pas les segments récupérés dans leur intégralité pour les corpus sensibles sans politique claire de conservation et d’accès.
Ne mélangez pas les documents RH, juridiques, clients et publics dans le même corpus.
Ne laissez pas le RAG répondre en dehors de ses sources autorisées juste pour être utile.
À retenir
Un RAG exploitant les connaissances de l’entreprise est précieux, car il apporte au travail quotidien des réponses étayées par des sources. Il présente aussi un risque : même une réponse correctement étayée peut divulguer des informations.
Concevez d’abord les périmètres d’autorisation. Filtrez avant la récupération. Séparez les corpus selon leur public. Conservez les métadonnées des sources. Refusez de répondre de manière sûre. Journalisez avec soin. Testez avec de véritables profils d’autorisation. Si un utilisateur ne peut pas accéder directement à une source, le RAG ne doit pas l’utiliser pour lui répondre.
