Un RAG mal monté, c'est la façon la plus rapide de fuiter des données qui n'auraient jamais dû sortir. Le pattern classique : tu indexes « toute la documentation », un utilisateur pose une question innocente et le système lui renvoie un fragment d'un document auquel cette personne ne devrait pas avoir accès. Ce n'est pas un bug exotique — c'est l'architecture par défaut de presque tous les RAG de démo.
Les permissions avant les embeddings
Le contrôle d'accès n'est pas un filtre qu'on ajoute à la fin : il vit dans la couche de récupération. Avant que le modèle ne voie quoi que ce soit, le système a déjà restreint quels fragments cet utilisateur précis peut récupérer. L'identité commande ; l'embedding vient après.
Partitionne l'index par permission
On ne met pas tout dans un seul index en priant. On segmente par niveau d'accès et on attache des métadonnées de permission à chaque fragment, de sorte que la requête ne peut toucher que ce qui correspond à celui qui demande.
- Filtrage par identité à la récupération, pas à la réponse.
- Index ou partitions segmentés par niveau d'accès.
- Métadonnées de permission sur chaque fragment indexé.
- Audit des requêtes : qui a demandé quoi et ce qu'on lui a renvoyé.
Citation ou ça ne sert à rien
Chaque réponse renvoie à sa source. Sans citation, pas de confiance ni de traçabilité : l'utilisateur ne peut pas vérifier, et toi tu ne peux pas auditer. En enterprise, une réponse sans source est une réponse que tu ne peux pas défendre.
Ce qu'on mesure
- Précision de récupération (est-ce qu'il ramène le pertinent ?).
- Fuites d'accès : l'objectif c'est zéro, et ça s'audite.
- Couverture de citation : % de réponses avec source vérifiable.
- Uptime et latence du pipeline.
Voilà ce que fait un Senior AI Infrastructure Implementer : il ne « branche pas un RAG », il déploie un système de connaissance qui scale, cite et respecte les permissions — parce qu'en enterprise une donnée fuitée n'est pas un incident technique, c'est une crise.