Comment actualiser les résultats d’un RAG d’entreprise lorsque les droits d’un document changent ?

Réponse courte

Lorsqu’un document change de droits dans un système RAG, actualiser seulement l’index de recherche ne suffit pas. Vérifiez l’accès au document avec l’identité actuelle de l’utilisateur avant de générer une réponse ; appliquez la même limite d’autorisation aux caches, aux aperçus des sources et aux exports. Renvoyer une ancienne réponse en cache à un utilisateur dont les droits ont été retirés constitue aussi une fuite de données.

Le filtre de recherche n’est pas la dernière frontière de sécurité

Les droits de groupes ou d’utilisateurs peuvent être associés aux fragments lors de l’indexation. Ces copies peuvent être périmées. Après sélection du document, mais avant transmission au modèle, vérifiez l’accès dans le système source. Excluez de préférence les documents dont l’accès est inconnu ou invérifiable.

Accéder au document et afficher un résumé dérivé relèvent de la même chaîne de droits. Sans séparation du cache par utilisateur ou contexte d’autorisation adéquat, le résumé d’un utilisateur autorisé peut atteindre quelqu’un d’autre. Protéger le lien du document mais pas le texte de réponse est incomplet.

Propager les changements à toutes les copies

Définissez des événements explicites pour la suppression d’un document, les changements d’appartenance à un groupe et la révocation d’un partage. La mise à jour des index, des caches de réponses et des copies d’aperçu des sources doit être suivie sous forme de tâches traçables. Les tâches inachevées doivent figurer dans les rapports. Le document d’exigences doit préciser si le système peut restituer un contenu sur la base d’anciens droits lorsque le système source est temporairement inaccessible.

Demander au modèle de ne pas partager de documents confidentiels ne remplace pas le contrôle d’accès. Les instructions d’un document externe ne doivent pas non plus élargir les droits. L’approche OWASP des risques LLM est un point de départ ; préparez séparément les tests négatifs de l’application. Le choix du modèle ne change pas l’endroit où la frontière doit être imposée.

Trois utilisateurs pour la recette

Posez la même question avec un utilisateur autorisé, un non autorisé et un dont les droits ont ensuite été retirés. Répétez après mise en cache d’une réponse autorisée. Vérifiez aussi aperçus et liens de téléchargement. Réussir signifie non seulement supprimer un résultat, mais empêcher l’accès non autorisé à la réponse dérivée.

Liste de contrôle de mise en œuvre

L’accès est-il vérifié avant transmission au modèle ?
Le cache est-il séparé par contexte d’autorisation ?
L’état des tâches de suppression et de révocation des droits est-il visible ?
Aperçus et téléchargements appliquent-ils le même contrôle ?
Existe-t-il un test négatif après révocation des droits ?

Questions fréquentes

Un prompt peut-il limiter l’accès aux données ?

C’est une règle de comportement complémentaire ; il ne remplace pas le contrôle d’accès côté serveur.

Attendre la mise à jour de l’index suffit-il ?

La fenêtre de retard doit être gérée séparément. Il faut donc vérifier les droits actuels avant de générer la réponse.

Périmètre et limites

Adaptez l’architecture au modèle d’accès de la source et à la classification des données. Cette liste n’est ni une certification de sécurité ni une garantie contre toutes les menaces.

Sources et actualité

Vérification des sources : 7 octobre 2026. Les versions des documents liés et les conditions des fournisseurs peuvent changer. Vérifiez la version actuelle de la source concernée avant toute mise en œuvre.

Service associé

Découvrir les logiciels sur mesure et les applications mobiles