Autorisations RAG pour chatbots de site web : contrôler l'accès aux documents en toute sécurité

Un chatbot de site web peut regrouper des réponses issues de pages de FAQ, de documents produits et de sources de connaissances internes. C'est très utile, jusqu'à ce que cette même base de connaissances contienne des contenus qui ne sont pas destinés à tout le monde. La sécurité d'une réponse ne dépend alors plus seulement de la qualité du modèle de langage, mais de l'étape de récupération (retrieval) sous-jacente : quels documents cette requête précise a-t-elle le droit de consulter ?

Les autorisations RAG associent des identités, rôles ou groupes vérifiés à des métadonnées sur les documents. Le chatbot ne reçoit que des sources déjà filtrées. L'objectif est délibérément strict : ce n'est pas au modèle de décider, sur la base du prompt, si une information est confidentielle. L'application limite le contexte autorisé, documente cette décision et choisit un fallback sécurisé en cas d'incertitude.

Pourquoi les consignes de prompt ne remplacent pas le contrôle d'accès

Une instruction système du type « Ne donne aucune information interne » est utile, mais elle ne constitue pas une couche d'autorisation. Si un document non autorisé parvient dans le contexte, la réponse peut en faire la synthèse, le révéler indirectement ou le reconstituer si l'utilisateur insiste. De même, une vérification du texte a posteriori arrive trop tard et s'avère sujette aux erreurs. La sécurité commence donc avant la génération et, idéalement, avant le classement des résultats.

Azure AI Search décrit le « Security Trimming » comme un modèle de filtrage : les documents portent des valeurs d'identité ou de groupe ; la requête ne contient que les identifiants de la personne qui pose la question. De manière similaire, Amazon Bedrock souligne que les filtres de recherche sensibles aux ACL ne remplacent pas l'authentification. Votre application doit d'abord vérifier elle-même l'identité de manière fiable et ne transmettre qu'un contexte dûment vérifié.

Les quatre piliers d'une solution solide

1. Vérifier l'identité et la session côté serveur

Une fenêtre de chat publique n'a généralement aucun droit d'accès aux documents confidentiels. Elle ne doit accéder qu'à des sources publiques. Pour un portail client ou un espace réservé aux employés, la personne est en revanche identifiée via sa connexion existante. Lisez le rôle, l'organisation et les groupes pertinents côté serveur à partir de la session ou d'un jeton signé. Ne vous fiez jamais à un champ transmis librement par le navigateur comme role=admin ni à un message dans le chat prétendant une appartenance.

2. Maintenir des métadonnées d'autorisation avec chaque source

Chaque extrait (chunk) a besoin, en plus du texte, de l'URL et de la date de mise à jour, d'une information d'accès claire : par exemple audience=public, un identifiant d'organisation (tenant ID), une liste de groupes autorisés ou une classification. Ces métadonnées doivent provenir de la même source métier que les autorisations du document. Une feuille de calcul séparée qui n'est mise à jour qu'occasionnellement crée une dérive dangereuse. Pour les nouveaux documents et les modifications de droits de groupe, la synchronisation des métadonnées doit donc faire partie intégrante du flux de publication ou d'exploration (crawl).

3. Filtrer avant le classement (ranking)

La requête construit un filtre basé sur le contexte vérifié. Ce n'est qu'ensuite que les résultats sémantiques ou hybrides sont évalués. Ainsi, un manuel confidentiel ne peut pas l'emporter en tant que résultat particulièrement pertinent pour être éliminé par la suite. Dans un environnement multi-tenant, l'ID d'organisation est un filtre obligatoire et pas seulement un signal de classement. Pour les données personnelles ou particulièrement protégées, il est également recommandé d'utiliser un espace de données distinct plutôt qu'une collecte commune simplement filtrée de manière logique.

4. Journaliser les sources et les décisions

Pour le support et l'analyse des incidents, les transcriptions de chat ne suffisent pas à elles seules. Pour chaque requête, il doit être possible de vérifier quels attributs d'identité non sensibles ont été utilisés pour construire le filtre, quelle classe de filtre a été appliquée, combien de résultats restaient après le filtrage et quelles sources sont réellement arrivées dans le prompt. Ne conservez pas de contenu intégral ou de jetons inutiles. Un événement d'audit sobre en données permet de repérer les erreurs sans faire du monitoring une seconde fuite d'informations.

Un déroulement pratique pour les équipes web

1. Associez chaque source de connaissances à un public cible clair : public, client, partenaire, équipe interne ou organisation spécifique.
2. Définissez quelles données de session (claims) prouvent ce public cible. Les groupes issus du système d'identité sont plus fiables que les champs de formulaire librement remplis.
3. Intégrez ces données de session côté serveur dans le filtre de recherche et n'autorisez qu'un ensemble restreint et connu de champs de filtrage.
4. Effectuez un rapprochement à chaque exploration (crawl) : les documents nouveaux, modifiés et supprimés ont également besoin de métadonnées d'autorisation mises à jour.
5. Ne fournissez au modèle que les résultats filtrés, accompagnés d'une instruction claire de ne pas deviner les informations manquantes.
6. En cas d'absence de résultat, de sources contradictoires ou d'autorisation floue, redirigez vers un canal de contact humain sécurisé.

Ce processus complète la structuration décrite dans notre article sur le découpage RAG (chunking) : de bons segments améliorent la pertinence des résultats, mais ne remplacent pas le contrôle d'accès. De même, la fraîcheur des sources reste essentielle ; un état des autorisations obsolète représente à la fois un problème de qualité et de sécurité.

Erreur fréquente : filtrer après la recherche

Une erreur de conception classique consiste à récupérer les dix meilleurs résultats, puis à vérifier leurs étiquettes pour supprimer les documents problématiques. Cela semble suffisant à première vue, mais échoue en raison d'effets secondaires. Le résultat non autorisé peut déjà apparaître dans les journaux, les caches ou une sortie de débogage. De plus, son score modifie la sélection des autres résultats. Il est préférable d'appliquer le filtre directement dans la requête de recherche afin que seuls les documents autorisés soient pris en compte.

Une seconde erreur réside dans la confiance aveugle accordée aux fonctionnalités ACL d'un fournisseur. La documentation technique peut indiquer clairement qu'un service prend en compte les ACL lors de la récupération, sans pour autant vérifier lui-même l'authenticité du contexte utilisateur transmis. Vérifiez donc scrupuleusement : qui authentifie l'utilisateur ? D'où proviennent les groupes ? Quand les droits sont-ils synchronisés dans le système de recherche ? Que se passe-t-il si des métadonnées sont manquantes ?

Fail closed : quelle attitude adopter en cas d'incertitude

En cas d'information manquante, de source non synchronisée ou d'erreur de recherche, le chatbot ne doit pas essayer d'élargir sa recherche. Utilisez une réponse neutre : le contenu demandé n'est pas disponible dans le contexte d'accès actuel ; un interlocuteur humain peut vérifier les accès. Il ne s'agit pas d'une faiblesse dans l'expérience utilisateur, mais d'une limite honnête. L'article consacré à l' escalade vers un agent humain montre comment concevoir cette transition de manière concrète et sans impasse.

Pour les contenus publics, le même principe s'applique à plus petite échelle : si les sources sont insuffisantes, le bot doit faire part de son incertitude, proposer des liens vérifiés ou indiquer un moyen de contact, plutôt que d'inventer des détails plausibles. Cela réduit les hallucinations et évite qu'une réponse soi-disant utile n'incite à une validation erronée.

Cas de test indispensables avant le déploiement

Un test d'autorisation n'est pas une simple vérification ponctuelle par un administrateur. Créez un jeu de test de référence (Golden Set) composé de questions identiques pour plusieurs rôles : invité, client inscrit, partenaire autorisé, utilisateur bloqué et administrateur. Pour chaque combinaison, définissez les sources attendues, et pas seulement le texte de réponse espéré. Testez également les changements de groupe, les sessions expirées, les documents supprimés, les métadonnées ACL manquantes et une panne du service de recherche.

Contrôlez au moins quatre points dans les résultats : aucune URL ou identifiant de document non autorisé ne parvient dans le contexte ; les sources autorisées restent accessibles ; la réponse ne mentionne aucun contenu issu de documents filtrés ; et le fallback reste compréhensible. Ajoutez ces vérifications à vos tests de qualité des réponses afin d'évaluer conjointement la sécurité et la qualité métier.

Appliquer la protection des données et la transparence de manière pragmatique

Les données d'autorisation sont elles-mêmes sensibles. Utilisez autant que possible des identifiants techniques stables plutôt que des noms en clair dans les métadonnées de recherche. Limitez les journaux d'audit à leur objectif, leur durée de conservation et aux attributs strictement nécessaires. Informez les utilisateurs de manière transparente lorsqu'un chatbot accède à un espace connecté et proposez une voie humaine pour les questions relatives aux accès. Cet article ne remplace pas un conseil juridique personnalisé ; les durées de conservation et les bases légales dépendant de votre contexte d'utilisation.

Sur le plan technique, une répartition claire des responsabilités s'impose : les propriétaires de contenus gèrent les publics cibles, l'équipe identité est responsable des jetons et de la vérification des sessions, et l'équipe produit s'assure du bon fonctionnement des filtres et des fallbacks. Ainsi, la base de connaissances ne devient pas un réservoir de données incontrôlé, mais une source dont la portée reste parfaitement maîtrisée.

Check-list avant la mise en ligne

• Chaque source non publique est-elle attribuée à un rôle, un groupe ou un ID d'organisation ?
• Le contexte de la requête provient-il d'une identité vérifiée côté serveur ?
• Le filtre intervient-il avant la recherche et le classement ?
• Les modifications de droits et les explorations (crawls) sont-elles synchronisées ensemble ?
• Existe-t-il des tests de régression basés sur les rôles avec les sources attendues ?
• Chaque état inconnu ou défaillant mène-t-il à une transition sécurisée ?
• Les journaux sont-ils sobres en données et suffisants pour l'analyse des erreurs ?

Conclusion

Un bon chatbot de site web ne répond pas à toutes les questions pour tout le monde. Il affiche uniquement les sources correspondant au contexte d'accès vérifié et sait rester en retrait en cas d'incertitude. Commencez par une matrice de sources restreinte, un filtre côté serveur et quelques rôles de test clairs. Vous pourrez ensuite étendre progressivement les métadonnées d'autorisation, les audits et la synchronisation, sans faire reposer votre sécurité sur la seule formulation des prompts.

Sources

• Microsoft Learn : Security Filter Pattern dans Azure AI Search
• Microsoft Learn : Contrôle d'accès au niveau des documents dans Azure AI Search
• Amazon Bedrock : Activation de la prise en compte des ACL
• Amazon Bedrock : Contrôles d'accès au niveau des documents