RAG en production : sécuriser ingestion, embeddings et rétrieval

Le pattern RAG (Retrieval Augmented Generation) est devenu en 2024-2025 l'architecture par défaut pour les applications LLM en entreprise : on indexe un corpus, on récupère les passages pertinents à la requête, on les fournit en contexte au LLM, qui répond. Élégant en apparence, le RAG accumule en pratique trois familles de risques sécurité spécifiques que les architectures naïves ne gèrent pas. Voici comment les adresser.

Architecture RAG type et ses points de friction

`` [Documents source] → [Chunking] → [Embeddings] → [Vector DB] ↓ [Requête utilisateur] → [Embedding] → [Search] → [Top-K passages] ↓ [Prompt + passages] → [LLM] → [Réponse] ``

Trois zones de friction sécurité :

1. Ingestion (gauche) : qui peut faire entrer des documents dans l'index, sous quelles conditions ?
2. Stockage et recherche (centre) : qui peut accéder aux embeddings et aux passages, comment garantit-on l'isolation ?
3. Génération (droite) : comment évite-t-on les prompt injections indirectes via le contenu indexé ?

1. Sécurisation de l'ingestion

Risque : data poisoning

Un attaquant insère dans votre corpus des documents qui contiennent :

• Des instructions cachées que le LLM exécutera quand le passage sera retrouvé (prompt injection indirecte).
• Des fausses informations plausibles pour orienter les réponses ("la procédure officielle est de transférer les paiements à ce nouvel IBAN...").
• Des jeux de données statistiquement biaisés pour empoisonner les retrievals futurs.

Contre-mesures

• Provenance vérifiée : tout document indexé doit venir d'une source authentifiée et autorisée. Pas d'ingestion de documents arbitraires soumis par des utilisateurs externes sans validation.
• Pipeline d'ingestion à plusieurs étages :

- Scan antivirus / antimalware classique. - Détection de patterns suspects (instructions imperatives, balises de structure étranges, contenu obfusqué). - Validation par règles métier (un doc RH doit être labelé RH par un humain avant indexation).

• Quarantaine des documents sources non validés. L'index n'est mis à jour que sur passage en allowlist.
• Versioning et rollback : chaque ingestion est traçable, réversible. Un poisoning détecté peut être annulé sans réindexer le corpus complet.
• Monitoring : détection d'anomalies sur les passages les plus retournés (volume, longueur, sentiment). Une augmentation soudaine de la fréquence de récupération d'un passage peut indiquer un poisoning ciblé.

2. Sécurisation du stockage et de la recherche

Risque : fuite cross-tenant

Si plusieurs clients (ou plusieurs équipes) partagent une infrastructure RAG sans isolation appropriée, une requête d'un tenant peut récupérer des passages d'un autre tenant. C'est probablement le risque RAG le plus sous-estimé en 2026.

Patterns d'isolation

Niveau 1 — Métadonnées filtrées (faible coût, faible isolation) :

• Chaque vecteur dans la DB porte un attribut tenant_id.
• Les requêtes filtrent par tenant_id avant le top-K.
• Risque résiduel : un bug dans le filtrage (oubli, mauvaise condition) leak immédiat. À utiliser uniquement avec une stack mature et testée.

Niveau 2 — Index séparés (coût moyen, isolation forte) :

• Un index distinct par tenant.
• Les requêtes vont par construction dans l'index du tenant correct.
• Risque résiduel : routing logic à sécuriser (un mauvais aiguillage peut leaker).

Niveau 3 — Infrastructure dédiée (coût fort, isolation maximale) :

• Une instance de DB par tenant, voire un cluster.
• Pour les données très sensibles ou les exigences réglementaires (santé, finance, secret défense).

Le bon choix dépend de votre criticité et de votre échelle. Mon défaut pour les SaaS B2B avec données sensibles : niveau 2 (index séparés).

Risque : recherche pondérée par les mauvais critères

Un vector search retourne les passages les plus similaires sémantiquement — pas forcément les plus autorisés. Sans contrôle complémentaire, le top-K peut contenir des passages que l'utilisateur courant n'a pas le droit de voir.

Solutions :

• Filtrage post-retrieval sur ACL : après le top-K, filtrer les passages que l'utilisateur n'est pas autorisé à voir.
• Mieux : filtrage pre-retrieval via metadata-aware search (les vector DBs récents le supportent : Pinecone, Weaviate, Qdrant).
• Encore mieux pour très sensible : index séparés par groupe d'autorisation, comme pour le multi-tenant.

3. Sécurisation de la génération

Risque : prompt injection indirecte

C'est le risque qui rapproche le RAG des intégrations LLM générales. Le scenario type :

1. Un attaquant a inséré un document dans le corpus (légitimement ou via une faille d'ingestion) qui contient une instruction.
2. Quand un utilisateur pose une question proche du sujet, ce document est récupéré dans le top-K.
3. L'instruction cachée est exécutée par le LLM (exfiltration, comportement malveillant, biais).

C'est exactement le pattern de la faille Slack AI, à l'échelle d'un corpus indexé.

Contre-mesures

• Délimitation explicite dans le prompt : les passages récupérés sont entourés de balises typées et le system prompt indique qu'ils ne contiennent que des informations, jamais des instructions.
• Instruction explicite au modèle d'ignorer les instructions présentes dans le contexte récupéré (palliatif imparfait mais utile).
• Output filtering : un classifieur en sortie qui détecte les comportements anormaux (exfiltration, instructions inversées, hallucinations dangereuses).
• Sanitization des passages récupérés avant injection dans le prompt (suppression des structures de prompt évidentes, normalisation).
• Pour les agents qui font du RAG + appels d'outils : validation humaine des actions à effet de bord. Voir Agents autonomes.

Le réglage du chunking et du retrieval

Au-delà du sécurité pure, deux choix techniques ont un impact :

Chunking

• Chunks trop courts : le contexte sémantique est perdu, le LLM hallucine pour combler.
• Chunks trop longs : le top-K contient trop d'information non-pertinente, augmente la surface d'attaque.
• Sweet spot : 500-1500 tokens par chunk avec overlap de 100-200 tokens.

Retrieval

• Top-K trop petit : risque de réponses incomplètes, frustrations utilisateurs.
• Top-K trop grand : noyade du LLM dans l'information, dégradation des réponses.
• Sweet spot typique : top-3 à top-7, avec re-ranking optionnel par un modèle léger.

Observabilité et logs

Pour tout système RAG en production, conservez :

• La requête utilisateur originale.
• L'embedding de la requête (utile pour le débogage et l'analyse).
• Les top-K passages retournés (avec leur source).
• Le prompt final envoyé au LLM.
• La réponse générée.
• Toute action/outil déclenchée par la réponse.

Cette télémétrie est ce qui permet de :

• Détecter un poisoning a posteriori.
• Investiguer un comportement anormal.
• Améliorer le système (chunks mal récupérés, requêtes problématiques).
• Démontrer la conformité (AI Act, ISO 42001).

Coût total de la sécurisation

Faire un RAG sécurisé n'est pas 10x plus cher qu'un RAG basique. C'est environ 30-50% de plus en coût d'infra et 1-2 mois de travail design supplémentaire. Le ROI est dans le fait de pouvoir déployer en production sur des données sensibles, ce qu'un RAG naïf ne permet pas.