Votre chatbot RAG indexe des documents internes, et certains utilisateurs commencent à voir des données auxquelles ils ne devraient pas accéder. Quelle est la cause et la correction ?

Un utilisateur pose une question au chatbot et reçoit le contenu d'un document auquel il n'aurait jamais dû accéder — une grille de salaires, la feuille de route d'une autre équipe, un dossier RH. Le réflexe est d'accuser le modèle. C'est le mauvais réflexe.

Pourquoi il s'agit d'autorisation, pas d'hallucination

Le modèle fait exactement ce qu'on lui a demandé : il a reçu ce document dans sa fenêtre de contexte et l'a résumé fidèlement. La défaillance s'est produite avant la génération, à l'étape de récupération. Si votre récupérateur exécute une recherche par similarité sur tout l'index et renvoie les top-k fragments sans tenir compte de qui interroge, alors tout document secret suffisamment pertinent devient accessible. Le modèle ne peut pas appliquer une permission qu'on ne lui a jamais donnée.

C'est le classique contrôle d'accès défaillant déguisé en problème d'IA. Le RAG transforme discrètement tout votre corpus documentaire en surface interrogeable, et une interface qui masque le lien vers un fichier ne sert à rien si la récupération en extrait quand même le texte vers le prompt.

La correction : autoriser à la récupération

Imposez les permissions de l'utilisateur au niveau du document, au moment de la requête, pour que seuls les fragments auxquels il a droit entrent dans le contexte. Concrètement :

• Attachez des métadonnées de propriété/ACL à chaque fragment lors de l'ingestion.
• Transmettez l'identité authentifiée de l'utilisateur et ses appartenances de groupe au récupérateur et filtrez avant que la recherche par similarité ne renvoie ses résultats, pas après.
• Revérifiez les permissions au moment de la réponse pour tout élément sensible, et réindexez ou invalidez les documents lorsque leurs ACL changent.

Pourquoi les distracteurs sont dangereux

• Augmenter la température / hallucination : la température change l'aléatoire, pas ce qui est récupérable. Les données sont réelles et correctement récupérées — c'est tout le problème.
• Prompt système plus long : un prompt demandant au modèle d'« être prudent » est un garde-fou souple et contournable, posé sur un contexte déjà fuité. Une injection de prompt ou une question astucieuse le défait. Le contrôle d'accès doit être une vérification stricte dans le code.
• Changer de modèle : chaque modèle restitue ce que vous placez dans son contexte. Un autre modèle hérite de la même faille de récupération.

Ce que les recruteurs veulent entendre

Que vous localisez le bug à la couche récupération/autorisation, que vous imposez le moindre privilège par utilisateur, et que vous ne comptez jamais sur la prose du modèle pour remplacer une décision de contrôle d'accès que l'application devrait prendre.