Le RAG (Retrieval-Augmented Generation) est devenu un standard en 2025-2026 : on injecte du contexte métier au LLM via une base vectorielle. Puissant. Mais c'est aussi la première source de fuite cross-tenant que je rencontre en mission. Voilà les contrôles que je pose pour un RAG sérieux en prod.
Les vrais risques d'un RAG en prod
1. Fuite cross-tenant
Le bug n°1. Un utilisateur du tenant A reçoit dans son contexte un extrait de document du tenant B. Causes typiques : index unique pour tous les tenants avec filtre métadata mal appliqué, embedding cache partagé, fallback sur "default index" en cas d'erreur.
2. Injection indirecte via documents
Un attaquant insère du contenu malveillant dans un document qui sera ingéré par votre RAG. À l'inférence, ce contenu se retrouve dans le contexte de l'agent et déclenche un comportement contrôlé. Voir prompt injection detection.
3. Memorization via embeddings
Les embeddings peuvent permettre une reconstruction partielle du contenu source. Si l'embedding est exposé (API publique du vector store mal sécurisée), risque de leak des documents indexés.
4. Fuites de PII dans les chunks
Vous indexez un document qui contient des PII, vous le servez à un LLM, qui peut les régurgiter dans l'output.
5. Stale data / droit à l'effacement
Un utilisateur exerce son droit RGPD d'effacement. Vos chunks et embeddings restent dans le vector store, retrouvables.
6. Empoisonnement de l'index
Un attaquant qui peut ajouter des documents à l'index peut introduire du contenu qui biaisera les réponses.
Les 10 contrôles que je pose en prod
1. Isolation tenant stricte au niveau index
Schémas viables :
- Index par tenant (idéal pour cloisonnement fort, coût plus élevé).
- Index partagé avec filtre métadata strict côté retrieval (acceptable si filtre testé adversarialement).
- Namespace par tenant dans le vector store (Pinecone, Weaviate supportent).
À éviter : index partagé avec filtre côté LLM après retrieval — trop facile à contourner.
2. Tests adversariaux d'isolation
Suite de tests : pour chaque release, l'utilisateur du tenant A essaie d'extraire du contexte du tenant B via prompts variés. Si un seul test passe = bloquant.
3. Authentification au niveau retrieval
Le service de retrieval vérifie l'identité de l'agent et son scope (quel tenant). Pas de fallback sur "default tenant" en cas d'absence de claim.
4. Sanitization des documents ingérés
Avant indexation, scan PII (option : masquage ou rejet selon politique). Détection d'instructions injection (patterns connus). Validation du format.
5. Pas d'embeddings exposés en API publique
Le vector store n'est pas accessible directement par l'utilisateur. Toujours via une couche de retrieval qui applique authn/authz.
6. Versioning de l'index
Capacité de revenir à une version antérieure de l'index si compromission détectée. Snapshots réguliers, signature.
7. Audit log des retrievals
Chaque retrieval loggué avec : timestamp, agent, tenant, query (ou son hash), documents retournés (IDs), score similarity. Indispensable pour investigation post-incident.
8. Droit à l'effacement opérable
Procédure documentée et testée : à partir d'un userId / dataSourceId, on supprime :
- Les chunks correspondants dans le vector store.
- Les caches embeddings.
- Les logs si rétention dépassée.
Test trimestriel sur un utilisateur de test.
9. Rotation des embeddings models
Si vous changez de modèle d'embedding, l'ancien index est obsolète. Procédure de re-indexation contrôlée, pas de mix old/new embeddings.
10. Output filtering côté LLM
Même avec retrieval cloisonné, garder une couche de filtering output qui détecte les fuites PII inattendues (regex emails, téléphones, IDs internes).
Le cas particulier du RAG métier réglementé
Pour santé, finance, juridique :
- Hébergement souverain ou conforme (HDS, EBIOS, secret professionnel).
- Chiffrement embeddings au repos (transparent côté vector store).
- Traçabilité par utilisateur de chaque chunk consulté (audit obligatoire).
- Explicabilité : pour chaque réponse, capacité de pointer la source.
Voir assistant IA en métier réglementé.
Les pièges que je vois revenir
Croire que le filtre métadata suffit
Filtre métadata = un seul test "WHERE tenant_id = X". Si une seule ligne du code de retrieval saute ce filtre (mode debug, fallback erreur, cache mal scopé), fuite. Test adversarial obligatoire.
Ne pas tester le multi-tenant en CI
Une fois mis en place, l'isolation se dégrade silencieusement si pas testée à chaque release. Suite de tests d'isolation = bloquante en CI.
Indexer tout ce qui vient
Une équipe alimente le RAG avec n'importe quel document interne pour "que ce soit dispo". 6 mois plus tard, des données RH se retrouvent dans le contexte d'un assistant commercial. Gouvernance des sources : ce qu'on indexe, pourquoi, qui valide.
Droit à l'effacement comme afterthought
Si vous n'avez pas codé l'effacement dès le départ, vous découvrez à la première demande que c'est très coûteux à faire proprement. Architecture à anticiper.
Pas de plan en cas de compromission
Si quelqu'un injecte du contenu malveillant dans votre RAG, vous restaurez quoi ? D'où ? En combien de temps ? Plan documenté, snapshots versionnés.
Mon avis en 1 ligne
Un RAG sans isolation tenant testée adversarialement = fuite cross-tenant en attente d'arriver. Les 10 contrôles posent une baseline défendable. Compter 3-6 semaines pour mettre en place sur un RAG existant, plus si l'architecture est à refondre. C'est le sujet sur lequel j'écris le plus de findings critiques en audit applicatif IA en 2026.