RAG souverain et conforme RGPD : le guide complet 2026

La généralisation des assistants conversationnels en entreprise a fait émerger une question stratégique que peu d'organisations avaient anticipée : où vivent réellement vos connaissances, et qui y a accès ? Adopter le RAG (Retrieval-Augmented Generation) sans réfléchir à la souveraineté de la donnée revient à confier le patrimoine informationnel de l'entreprise à une boîte noire dont vous ne maîtrisez ni la localisation, ni la rétention, ni les usages secondaires.

Ce guide détaille, étape par étape, comment concevoir une architecture RAG souveraine et conforme au RGPD, sans sacrifier la qualité de réponse ni la vélocité des équipes. Il s'adresse autant au CTO qui arbitre l'architecture qu'au DPO qui devra défendre les choix de traitement devant un régulateur, et au Head of AI qui doit livrer un assistant réellement utile. Vous n'y trouverez pas de promesse magique : la souveraineté a un coût d'ingénierie, mais ce coût est aujourd'hui parfaitement maîtrisable avec des briques open source matures.

Pourquoi la souveraineté n'est plus une option

Pendant longtemps, la souveraineté numérique a été perçue comme une préoccupation de DSI tatillonne ou de juriste excessivement prudent. Trois évolutions ont changé la donne.

D'abord, la valeur s'est déplacée vers la donnée propriétaire. Les modèles de fondation sont devenus des commodités largement disponibles : entre Llama 4, Mistral Large 2, Qwen 3 ou DeepSeek-V3 côté ouvert, et les familles Claude, GPT/série o ou Gemini 2.x côté API fermée, la capacité brute de génération ne différencie plus personne. Ce qui distingue une entreprise, c'est le corpus interne qu'elle injecte dans ces modèles. Contrats, procédures, historique support, documentation produit, comptes rendus de R&D : ces actifs constituent désormais un avantage concurrentiel qu'on ne souhaite pas voir fuiter, ni servir à entraîner le modèle d'un fournisseur — et indirectement celui de vos concurrents.

Ensuite, le cadre réglementaire s'est durci. Le RGPD impose depuis 2018 de documenter le parcours de chaque donnée personnelle, mais c'est l'EU AI Act qui a rebattu les cartes. Entré en vigueur le 1er août 2024, il déploie ses obligations par paliers : interdiction des pratiques inacceptables et exigence de littératie IA dès février 2025, obligations pour les modèles à usage général (GPAI) en août 2025, puis le gros des obligations pour les systèmes à haut risque en août 2026, certaines repoussées à 2027. Un assistant RAG qui touche à du recrutement, du scoring crédit, de la santé ou des services publics peut basculer dans la catégorie « haut risque » et déclencher des obligations de documentation, de supervision humaine et de gestion des risques. Anticiper ce calendrier, ce n'est pas de la sur-prudence : c'est éviter de devoir réarchitecturer en urgence un système déjà en production.

Enfin, les incidents se sont multipliés. Fuites de prompts contenant des données clients, réutilisation de conversations pour l'entraînement, sous-traitants hors UE non déclarés, transferts vers les États-Unis fragilisés à chaque remise en cause des cadres d'adéquation : chaque trimestre apporte son lot de mauvaises surprises qui rappellent que l'externalisation aveugle a un coût. Quand un collaborateur colle un contrat confidentiel dans un assistant grand public, la donnée a déjà quitté votre périmètre — et aucune clause contractuelle a posteriori ne la fera revenir.

La souveraineté ne signifie pas tout réinternaliser. Elle signifie savoir, à tout instant, où se trouve chaque donnée et sous quelle juridiction elle est traitée — et pouvoir le démontrer sur pièces.

Les quatre piliers d'une architecture RAG souveraine

Une architecture souveraine repose sur quatre piliers complémentaires. Aucun ne suffit isolément : un stockage parfaitement localisé ne protège rien si l'inférence part en clair vers un fournisseur non encadré, et le meilleur modèle auto-hébergé ne vaut rien si une requête d'un tenant peut remonter les documents d'un autre.

1. La localisation et la maîtrise du stockage

Le premier réflexe consiste à vérifier où sont physiquement stockés vos documents, vos métadonnées et vos vecteurs. Une base vectorielle hébergée dans une région européenne, opérée par une entité soumise au droit de l'Union, constitue le socle minimal. PostgreSQL avec l'extension pgvector, déployé sur une infrastructure que vous contrôlez, offre cette garantie tout en évitant l'enfermement propriétaire d'un service vectoriel fermé : vos embeddings vivent dans la même base que vos données métier, sous le même régime de sauvegarde, de chiffrement et d'accès.

Côté hébergement, l'écosystème européen s'est étoffé : OVHcloud et Scaleway proposent du calcul et du GPU dédié en région UE, Mistral AI opère sa Plateforme depuis l'Europe, et Aleph Alpha cible spécifiquement les cas souverains en Allemagne. Selon la sensibilité, vous pouvez aller du cloud souverain managé jusqu'au GPU dédié, voire l'on-prem complet pour les données les plus critiques.

Sur le plan de l'indexation, pgvector propose deux familles d'index. HNSW (Hierarchical Navigable Small World) offre un excellent compromis rappel/latence et se règle via trois paramètres clés : m (nombre de connexions par nœud, typiquement 16), ef_construction (effort à la construction, 64–200) et ef_search (effort à la requête, ajustable à chaud). L'alternative IVFFlat se construit plus vite et consomme moins de mémoire, mais exige un volume représentatif avant d'être pertinente. Pour maîtriser le stockage à grande échelle, le type halfvec (16 bits au lieu de 32) divise quasiment par deux l'empreinte des vecteurs avec une perte de rappel souvent négligeable ; la quantization binaire pousse la logique plus loin pour les très gros corpus.

-- Table de chunks avec embedding et scope tenant
CREATE TABLE document_chunks (
  id            bigserial PRIMARY KEY,
  organization_id bigint NOT NULL,
  document_id   bigint NOT NULL,
  content       text   NOT NULL,
  embedding     halfvec(1536) NOT NULL,   -- 16 bits pour réduire le stockage
  metadata      jsonb  NOT NULL DEFAULT '{}'
);

-- Index HNSW (cosine) — règle ef_search à la requête pour arbitrer rappel/latence
CREATE INDEX ON document_chunks
  USING hnsw (embedding halfvec_cosine_ops)
  WITH (m = 16, ef_construction = 100);

-- Index partiel par organisation pour le cloisonnement (voir pilier 3)
CREATE INDEX ON document_chunks (organization_id);

2. La maîtrise des flux d'inférence

Le stockage souverain ne sert à rien si chaque requête envoie le contexte complet vers un fournisseur de modèle hors UE sans encadrement. Trois stratégies coexistent, et la plupart des architectures matures les combinent.

• Modèles hébergés en UE : recourir à des fournisseurs proposant des points d'accès européens avec engagement contractuel de non-rétention et de non-entraînement. La Plateforme de Mistral, les offres d'OVHcloud ou de Scaleway autour de modèles ouverts entrent dans cette catégorie. Vous gagnez en simplicité opérationnelle tout en gardant la donnée sous droit européen.
• Modèles auto-hébergés : déployer des modèles ouverts (Llama 4, la famille Mistral, Qwen 3, DeepSeek pour le raisonnement, Gemma 3 pour les plus petits gabarits) sur votre propre infrastructure GPU pour les cas les plus sensibles. C'est l'option la plus exigeante en MLOps, mais la seule qui garantit qu'aucun octet de prompt ne quitte votre périmètre. Un modèle de classe « Small » suffit souvent pour la synthèse de passages déjà récupérés.
• Approche hybride : router les requêtes selon leur niveau de sensibilité. Les données critiques restent sur l'infrastructure interne ; les requêtes anodines (FAQ publique, documentation déjà en ligne) peuvent bénéficier de modèles externes plus performants.

Le routage par sensibilité mérite d'être formalisé plutôt que laissé à l'improvisation. Un schéma de décision simple :

Requête entrante
   │
   ├─ Contient des données personnelles / secrets métier ?
   │     ├─ OUI → modèle auto-hébergé (GPU dédié, UE)
   │     └─ NON ↓
   │
   ├─ Corpus interne confidentiel mais non personnel ?
   │     └─ OUI → modèle open hébergé en UE (non-rétention)
   │
   └─ Contenu public / faible sensibilité ?
         └─ API externe performante (si l'arbitrage qualité le justifie)

La classification de sensibilité s'appuie idéalement sur les métadonnées portées par chaque chunk (niveau de confidentialité, présence de données personnelles détectée à l'ingestion), de sorte que la décision de routage soit déterministe et auditable, et non laissée au hasard d'une heuristique.

3. Le cloisonnement multi-tenant

Dans un contexte B2B, l'isolation entre clients ou entre départements est non négociable. Chaque requête de recherche doit être scoptée par identifiant d'organisation, et cette contrainte doit être appliquée au niveau de la couche d'accès aux données, pas seulement dans l'interface. Une fuite inter-tenant n'est pas un bug mineur : c'est un incident de sécurité majeur, potentiellement une violation de données au sens du RGPD, avec obligation de notification sous 72 heures.

Concrètement, le filtre tenant doit faire partie de la requête de similarité elle-même, jamais d'un post-filtrage applicatif qui laisserait fuiter des candidats du mauvais tenant dans le top-k avant tri :

-- Le scope organisation est DANS la requête vectorielle, pas après
SELECT id, content, metadata
FROM document_chunks
WHERE organization_id = $1            -- cloisonnement non négociable
ORDER BY embedding <=> $2             -- distance cosine
LIMIT 20;

Selon le niveau d'exigence, on peut renforcer ce cloisonnement avec la Row-Level Security de PostgreSQL, des schémas séparés par tenant, voire des bases distinctes pour les clients les plus régulés. Le principe reste : l'isolation est une propriété de l'infrastructure, vérifiable par des tests automatisés, pas une discipline de développeur.

4. La traçabilité et l'auditabilité

Chaque réponse générée doit pouvoir être reliée à ses sources. Cette traçabilité sert deux objectifs : la confiance de l'utilisateur (qui peut vérifier l'origine de l'information et détecter une hallucination) et la conformité (qui exige de documenter le traitement). Conservez, pour chaque interaction, les journaux de requêtes, les identifiants des documents et chunks récupérés, le score de pertinence, la version du modèle d'embedding et celle du modèle de génération.

Cette journalisation est ce qui transforme un audit en exercice de routine plutôt qu'en crise. Quand un client demande « sur quoi se fonde cette réponse ? » ou qu'un régulateur exige de retracer un traitement, vous disposez de la chaîne complète. Attention toutefois : ces journaux contiennent eux-mêmes des données potentiellement personnelles et doivent donc être soumis à une politique de rétention explicite (voir checklist RGPD).

Le pipeline de traitement documentaire, pas à pas

La qualité d'un système RAG se joue largement en amont de la génération, dans la façon dont les documents sont ingérés et préparés. Voici les cinq étapes incontournables.

1. Extraction — Adapter l'extraction au format : PDF (souvent le plus traître, entre colonnes, tableaux et PDF scannés nécessitant de l'OCR), DOCX, pages web, exports d'outils métier. Une extraction bâclée propage du bruit dans tout le pipeline : un tableau aplati en charabia ou un en-tête répété mille fois polluera durablement la pertinence.
2. Nettoyage — Supprimer les en-têtes, pieds de page, mentions légales répétitives et artefacts de mise en page. C'est aussi l'étape où détecter et marquer les données personnelles, afin d'alimenter le routage par sensibilité et l'éventuelle pseudonymisation.
3. Découpage sémantique — Segmenter le texte en respectant les frontières logiques (sections, paragraphes) plutôt qu'un découpage mécanique au nombre de caractères. Un chevauchement modéré (de l'ordre de 10 à 20 % de la taille de chunk) préserve le contexte d'une frontière à l'autre. Des techniques plus avancées affinent encore le résultat : le late chunking (calculer l'embedding sur le document entier avant de découper, pour que chaque chunk hérite du contexte global) et le contextual retrieval (préfixer chaque chunk d'un court contexte généré par LLM) réduisent nettement les ruptures de sens.
4. Vectorisation — Calculer les embeddings, idéalement de façon asynchrone via une file de jobs pour ne pas bloquer l'ingestion de gros volumes. Le choix du modèle d'embedding compte : text-embedding-3-large d'OpenAI (jusqu'à 3072 dimensions), voyage-3, Cohere embed v3, ou en open et multilingue bge-m3 et Jina embeddings v3 — ce dernier particulièrement pertinent dans un contexte souverain où l'on souhaite garder l'embedding lui aussi sous contrôle.
5. Indexation — Stocker les vecteurs avec un index HNSW adapté à la recherche par similarité, en conservant les métadonnées (source, date, permissions, niveau de sensibilité) attachées à chaque segment. Ce sont ces métadonnées qui rendront possibles le filtrage, le cloisonnement et l'effacement ciblé.

Le découpage est l'étape la plus sous-estimée. Un mauvais chunking sabote la pertinence quelle que soit la qualité du modèle d'embedding — on ne rattrape jamais en aval une information découpée au mauvais endroit.

Au-delà de la recherche vectorielle pure : hybride et reranking

La recherche purement dense (vecteur contre vecteur) a un angle mort : elle gère mal les correspondances exactes — un numéro de référence, un acronyme métier, un nom propre rare. La recherche hybride combine un canal lexical (BM25 / mots-clés) et un canal dense, puis fusionne les deux classements, le plus souvent par RRF (Reciprocal Rank Fusion). On récupère ainsi le meilleur des deux mondes : la robustesse du mot-clé et la compréhension sémantique du vecteur.

Une seconde couche fait souvent la différence : le reranking. Un cross-encoder (Cohere Rerank 3, ou en open bge-reranker-v2-m3, Jina reranker, Voyage rerank) re-score finement les 20 à 50 meilleurs candidats avant de n'en garder que 3 à 5 pour le contexte. C'est un investissement modeste en latence (quelques dizaines de millisecondes) pour un gain de précision souvent spectaculaire, et un reranker open auto-hébergé reste pleinement compatible avec une architecture souveraine. Pour les documents visuels (PDF complexes, schémas), les approches multi-vecteurs type ColBERT / ColPali ouvrent une voie complémentaire.

Conformité RGPD : la checklist opérationnelle

Au-delà des principes, voici les points concrets à valider avant toute mise en production.

• Base légale — Identifier la base juridique du traitement (intérêt légitime, consentement, exécution contractuelle) pour chaque catégorie de donnée ingérée. Documentez-la dans votre registre des traitements ; c'est la première question d'un contrôle.
• Minimisation — N'ingérer que les documents réellement utiles. Un corpus pléthorique augmente la surface de risque sans gain proportionnel de pertinence — et dégrade souvent la qualité de récupération en noyant les bons passages.
• Droit à l'effacement — Garantir qu'un document retiré du corpus voit aussi ses vecteurs et ses copies dérivées supprimés. La suppression doit cascader jusqu'aux embeddings : un chunk effacé en base mais toujours présent dans l'index vectoriel ou dans un cache reste une donnée vivante. Testez cette cascade comme vous testeriez une migration, car c'est exactement le point qu'un régulateur viendra vérifier.
• Données personnelles dans les prompts — Mettre en place une détection et, si nécessaire, une pseudonymisation des données personnelles avant leur envoi à un modèle externe. Le routage par sensibilité décrit plus haut est le complément naturel de cette mesure.
• Sous-traitants — Tenir à jour le registre des sous-traitants et de leurs localisations, et s'assurer que chaque transfert hors UE est encadré (clauses contractuelles types, évaluation des garanties). Chaque fournisseur de modèle ou d'embedding est un sous-traitant à part entière.
• Durée de conservation — Définir et appliquer des politiques de rétention sur les journaux de conversation et les historiques de requêtes, y compris ceux que vous avez créés pour la traçabilité du pilier 4.

La conformité RGPD n'est pas une couche qu'on ajoute à la fin : c'est une propriété qu'on conçoit dès le schéma de données. Un document_id propre qui relie chunk, vecteur et source rend l'effacement trivial ; son absence le rend impossible.

L'audit de connaissances : le préalable trop souvent négligé

Avant de vectoriser quoi que ce soit, prenez le temps de cartographier votre patrimoine informationnel. Cet audit de connaissances répond à des questions simples mais décisives :

• Quels documents font autorité, et lesquels sont obsolètes ? Une procédure abrogée mais toujours indexée produira des réponses fausses avec un aplomb total.
• Quelles zones de votre documentation présentent des lacunes que les utilisateurs vont immanquablement solliciter ?
• Quels contenus contiennent des données sensibles nécessitant un traitement particulier (routage, pseudonymisation, exclusion pure et simple) ?
• Qui est propriétaire de chaque source, et selon quelle fréquence est-elle mise à jour ?

Un système RAG amplifie la qualité — ou la médiocrité — du corpus qu'on lui donne. Injecter une documentation contradictoire et périmée produira un assistant qui répond avec assurance… des inexactitudes. C'est le piège le plus insidieux : un mauvais assistant qui dit « je ne sais pas » est inoffensif ; un mauvais assistant qui invente avec confiance détruit la confiance des utilisateurs en quelques interactions. La détection des lacunes (« knowledge gaps ») en cours d'usage permet ensuite d'enrichir le corpus là où les besoins réels se manifestent, plutôt que de tout documenter par anticipation.

Mesurer ce qui compte vraiment

Un projet RAG ne se pilote pas à l'intuition. Quelques indicateurs structurants :

• Taux de réponses sourcées — Proportion de réponses appuyées sur au moins une source vérifiable. En deçà d'un certain seuil, l'assistant hallucine plus qu'il ne s'informe.
• Pertinence de récupération — Les bons documents remontent-ils dans le top des résultats ? On la mesure sur un golden set de questions de référence, avec des métriques de type context precision / context recall.
• Latence perçue — Le temps de réponse reste-t-il compatible avec un usage conversationnel fluide ? Le reranking, le routage, l'auto-hébergement ont tous un coût qu'il faut surveiller bout en bout.
• Taux de lacunes détectées — Fréquence des requêtes pour lesquelles le corpus ne contient aucune réponse satisfaisante. C'est votre feuille de route d'enrichissement.

Pour aller au-delà des intuitions, des frameworks comme RAGAS automatisent l'évaluation sur les axes faithfulness (la réponse est-elle fidèle aux sources ?), answer relevancy, context precision et context recall, complétés par des approches LLM-as-judge. L'enjeu n'est pas de viser des scores parfaits, mais de disposer d'un tableau de bord stable : sans baseline, toute « amélioration » du pipeline n'est qu'une opinion.

Ces métriques transforment un assistant « magique » mais opaque en un système d'information pilotable, dont on peut justifier les progrès auprès de la direction — et la conformité auprès d'un régulateur.

Conclusion : la souveraineté comme avantage durable

Construire une architecture RAG souveraine demande un effort initial supérieur à celui d'un branchement direct sur une API généraliste. Mais cet effort se rentabilise vite : il transforme une dépendance subie en un actif maîtrisé. Vous gardez le contrôle de vos connaissances, vous documentez votre conformité sans panique à chaque audit, et vous bâtissez une confiance durable avec vos clients comme avec vos régulateurs.

La bonne nouvelle, c'est que les briques techniques sont aujourd'hui matures. PostgreSQL et pgvector avec un index HNSW pour le stockage, des modèles ouverts performants (Llama 4, Mistral, Qwen 3, DeepSeek) pour l'inférence sensible, des hébergeurs européens crédibles, une recherche hybride avec reranking pour la qualité, des pipelines d'ingestion éprouvés : tout existe pour bâtir un RAG à la fois performant et souverain. Il ne reste plus qu'à l'assembler avec méthode — et à commencer par cartographier ce que vous savez vraiment.

Pour aller plus loin

• Souveraineté de l'IA pour l'entreprise européenne : le guide stratégique 2026
• RGPD et IA générative : le guide de conformité de vos projets RAG
• Architecture RAG de production : du chunking au reranking, le guide complet