Le RAG (Retrieval Augmented Generation) s’est imposé en 2024-2026 comme l’architecture de référence pour connecter un LLM aux données internes de l’entreprise. Le principe est simple : plutôt que de réentraîner le modèle sur des données propriétaires (coûteux, risqué, difficile à mettre à jour), on lui fournit à la volée les extraits de documents pertinents pour répondre à la requête de l’utilisateur. Ce découplage entre connaissance et inférence explique le succès de l’approche. Mais un pipeline RAG est aussi une nouvelle surface d’attaque, un système de traitement de données personnelles potentiel, et un candidat probable à la réglementation AI Act. Voici le panorama technique et opérationnel pour une mise en oeuvre sécurisée en environnement B2B.
Architecture d’un pipeline RAG : les cinq composants
Un pipeline RAG se décompose en cinq étapes distinctes. Comprendre leur rôle respectif est le prérequis pour en gérer la sécurité.
1. Ingestion et chunking. Les documents sources (PDF, contrats, wikis internes, tickets, emails) sont découpés en passages (généralement 256 à 1024 tokens). Trop petit, le contexte est insuffisant ; trop grand, on dilue la pertinence et on augmente le coût d’inférence. Des stratégies avancées (hierarchical chunking, parent-child) améliorent la précision pour les longs documents structurés.
2. Embeddings. Chaque chunk est converti en vecteur numérique par un modèle d’embedding (text-embedding-3-large d’OpenAI, ou des modèles open source comme nomic-embed-text). Ce vecteur représente la sémantique du passage dans un espace de haute dimension (768 à 3072 dimensions selon le modèle). Propriété mal connue : les embeddings ne sont pas totalement opaques. Des travaux académiques ont montré qu’il est possible d’extraire partiellement le texte original à partir des vecteurs, en particulier pour des phrases courtes et stéréotypées. Une base vectorielle exposée représente donc plus qu’un simple index technique.
3. Base vectorielle. Les vecteurs sont stockés dans une base spécialisée optimisée pour la recherche de similarité cosinus ou euclidienne. Solutions principales : pgvector (extension PostgreSQL), Chroma, Weaviate, Qdrant, Pinecone, Milvus. Chaque collection ou namespace peut être isolé par tenant, ce qui constitue la base du contrôle d’accès.
4. Retrieval. À chaque requête, la question de l’utilisateur est elle-même convertie en embedding. La base vectorielle retourne les k passages les plus proches (typiquement k = 3 à 10). Un re-ranker peut affiner le résultat par pertinence croisée. Les architectures hybrides (dense + sparse, BM25 + embedding) améliorent la précision pour les requêtes à mots-clés spécifiques (numéros de référence, termes techniques).
5. Génération augmentée. Les passages récupérés sont injectés dans le prompt système envoyé au LLM. Le modèle génère sa réponse en s’appuyant sur ces extraits. La fenêtre de contexte (context window) du LLM est le facteur limitant : elle détermine combien de passages peuvent être fournis simultanément.
Comparatif des bases vectorielles enterprise
| Outil | Type | Contrôle d’accès | Localisation des données | Note |
|---|---|---|---|---|
| pgvector | Extension PostgreSQL | ACL PostgreSQL standard | Hébergement propre | Choix naturel si PostgreSQL existant |
| Qdrant | Open source / managé | Collections + API key | Self-hosted ou cloud | Bonne performance, Rust, actif |
| Weaviate | Open source / managé | RBAC, multi-tenant | Self-hosted ou cloud | Filtrage hybride mature |
| Chroma | Open source | Collections | Self-hosted | Simple, dev-friendly, limité en prod |
| Pinecone | SaaS | Namespaces + clés | Cloud AWS/GCP | Performant, SaaS US |
| Azure AI Search | SaaS | RBAC Azure AD | Azure EU disponible | Intégration native Azure OpenAI |
Pour les entités soumises à NIS2, DORA ou à des exigences de localisation des données (données de santé HDS, données de défense), le choix du mode d’hébergement de la base vectorielle est aussi stratégique que celui du LLM lui-même.
Risques cyber spécifiques au RAG
Les pipelines RAG introduisent quatre vecteurs d’attaque qui n’existent pas sur un LLM isolé.
Prompt injection indirecte. C’est le risque n°1, documenté dans l’OWASP Top 10 for LLM Applications (LLM01:2025 Prompt Injection). Un attaquant insère des instructions dans un document indexé (PDF, page web, ticket). Quand ce document est extrait par un autre utilisateur, les instructions malveillantes sont injectées dans le contexte du LLM. Si le modèle est configuré pour agir (envoyer un email, appeler une API), l’attaque peut produire des effets réels. La défense combine la séparation des instructions et des données dans le prompt système, le sandboxing des actions, et l’audit des documents avant indexation.
Fuite de données inter-tenant. Dans une architecture multi-tenant où plusieurs équipes ou clients partagent la même base vectorielle, une absence de contrôle d’accès au niveau du retrieval peut exposer des documents d’un tenant à un autre. L’erreur classique : appliquer le contrôle d’accès uniquement à l’interface utilisateur, en laissant l’API de recherche vectorielle sans restriction côté serveur. La bonne pratique est de filtrer par tenant_id ou namespace dans chaque requête de recherche, côté serveur.
Extraction de données via embeddings. Une base vectorielle exposée sans authentification (erreur de configuration, bucket S3 public) peut permettre une reconstruction partielle du corpus source. Cela est particulièrement problématique si le corpus contient des données personnelles au sens du RGPD, ou des données soumises au secret des affaires.
Empoisonnement du corpus (data poisoning). Un attaquant ayant accès au pipeline d’ingestion peut injecter des documents contenant des informations fausses. Le LLM les intégrerait à sa réponse et les citerait comme des faits. Pour les systèmes de support client, juridiques ou RH, ce vecteur peut produire des dommages significatifs. La protection passe par un contrôle d’accès strict sur les sources autorisées, un versioning du corpus et une signature des documents indexés.
Conformité RGPD et AI Act
Angle RGPD. Un pipeline RAG qui indexe des documents contenant des données personnelles est un traitement au sens de l’article 4 du règlement (UE) 2016/679. Cela implique une base légale, une finalité documentée, une durée de conservation et la capacité à honorer les droits des personnes concernées. Le droit à l’effacement (article 17) est le plus complexe : supprimer une entrée de la base vectorielle ne suffit pas si le document source reste dans le corpus d’ingestion. Il faut un pipeline de suppression avec re-indexation complète.
La CNIL attend des responsables de traitement qu’ils documentent les flux de données, en particulier lorsque des données personnelles transitent vers des modèles tiers (API LLM). Un pipeline RAG qui envoie des extraits de documents contenant des données personnelles à un LLM hébergé hors UE doit prévoir les garanties appropriées : clauses contractuelles types (CCT) ou, pour les prestataires américains certifiés, l’EU-US Data Privacy Framework (DPF).
Angle AI Act. Le règlement (UE) 2024/1689 classe les systèmes IA selon leur usage, pas selon leur architecture. Un assistant documentaire interne sans enjeu décisionnel relève du risque limité (obligation de transparence). Un système RAG qui informe des décisions RH, de crédit ou médicales bascule en haut risque avec sept obligations associées (documentation technique, gestion des risques, gouvernance des données, logs, supervision humaine, exactitude mesurée, évaluation de conformité). Pour le détail des obligations par niveau de risque, voir l’article dédié sur les obligations AI Act pour DSI et RSSI.
Les systèmes agentiques utilisant un RAG comme outil de recherche dans un workflow plus large (voir Agentic AI en entreprise) héritent des risques cumulés des deux architectures. L’analyse de risque doit couvrir l’ensemble du pipeline, pas uniquement la brique RAG isolée.
Gouvernance et bonnes pratiques opérationnelles
Cinq principes structurent une gouvernance RAG solide en environnement enterprise.
Contrôle d’accès au niveau du retrieval. Les autorisations doivent être vérifiées dans la requête vectorielle elle-même, pas seulement dans l’UI. Un utilisateur ne doit recevoir que des passages issus des documents auxquels il a accès dans le système source (SharePoint, Confluence, etc.). La bonne pratique est de stocker les métadonnées d’accès (ACL, groupe, classification) dans la base vectorielle comme filtres applicables à chaque requête de recherche.
Journalisation et traçabilité. Chaque requête doit être loguée avec : l’identifiant utilisateur, la question posée (ou son hash si elle contient des données sensibles), les identifiants des passages récupérés, et la réponse générée. Ce journal est indispensable pour l’audit AI Act, la détection d’anomalies et la réponse aux incidents.
Fraîcheur du corpus. Un corpus obsolète produit des réponses périmées citées avec le même niveau de confiance qu’une information à jour. Un pipeline de re-indexation incrémental (déclenché sur les modifications documentaires) ou périodique (re-indexation complète hebdomadaire) doit être opérationnel avant la mise en production.
Isolation des environnements. La base vectorielle de production ne doit pas être accessible depuis les environnements de développement ou de test. Les tests de pertinence doivent utiliser un corpus anonymisé. Cette règle est souvent ignorée en phase de POC, créant un risque de fuite lors du passage en production.
Évaluation continue. La qualité d’un système RAG se dégrade silencieusement quand le corpus évolue. Des frameworks d’évaluation (RAGAS, TruLens) permettent de mesurer trois métriques clés : la faithfulness (la réponse est-elle supportée par les passages récupérés ?), l’answer relevance (la réponse répond-elle à la question ?) et le context recall (les bons passages ont-ils été récupérés ?). Ces métriques constituent le monitoring RAG, analogue au monitoring de performance en infrastructure.
Modèle d’hébergement du LLM : trois options
Le choix entre LLM en SaaS, LLM managé et LLM on-premise conditionne le profil de risque du pipeline RAG.
Un LLM SaaS (API OpenAI, Anthropic, Mistral API) simplifie le déploiement mais implique un transfert de données hors de l’infrastructure de l’entreprise. Chaque passage fourni au LLM est envoyé au fournisseur dans le prompt. Pour les données soumises au secret professionnel, au secret des affaires ou à une réglementation sectorielle (DORA articles 28 et 30, exigences LPM), ce transfert doit être encadré contractuellement (clauses de non-utilisation pour l’entraînement, DPA conformes RGPD) et techniquement (absence de journalisation côté fournisseur, chiffrement en transit).
Un LLM managé sur infrastructure souveraine européenne (Microsoft Azure EU Data Boundary, OVHcloud AI, Scaleway LLM Inference) réduit le risque juridique d’extraterritorialité pour les entités concernées par NIS2 ou des exigences sectorielles. Pour les contraintes de localisation des données, voir le pilier /cloud/.
Un LLM on-premise ou en déploiement privé (Llama 3, Mistral, Mixtral sur GPU propre ou loué) maximise le contrôle mais introduit une charge opérationnelle (VRAM, latence, coût GPU, mises à jour du modèle) que peu d’équipes IT peuvent absorber. Le compromis courant pour les données très sensibles est un modèle local de taille intermédiaire (7 à 13 milliards de paramètres) avec RAG, plutôt qu’un grand modèle SaaS sans RAG.
Le NIST AI Risk Management Framework (NIST AI 100-1) recommande d’évaluer le profil de risque de chaque composant du système IA séparément : LLM, base vectorielle, pipeline d’ingestion, interface utilisateur. Cette granularité est aussi celle attendue par l’AI Act pour les systèmes à haut risque. Les référentiels ANSSI et ENISA constituent les bases documentaires de référence pour les volets cybersécurité et conformité.
Le RAG n’est pas une solution clé en main. C’est un pattern d’architecture qui déplace les problèmes plus qu’il ne les supprime : les hallucinations diminuent mais ne disparaissent pas, la sécurité de la base documentaire devient critique, et la conformité réglementaire s’applique à l’ensemble du pipeline. Pour les DSI et RSSI, le critère de succès d’un projet RAG n’est pas la qualité de la démo sur un corpus de test. C’est la capacité à le gouverner, l’auditer et le maintenir en production sur la durée, avec une surface d’attaque maîtrisée et une traçabilité documentée.