RAG souverain vs RAG cloud : comparatif architecture, sécurité et coût

Rappel : qu'est-ce que le RAG et comment ça fonctionne ?

Le Retrieval-Augmented Generation est une architecture qui améliore les LLM en leur donnant accès à une base de connaissances externe au moment de la génération. Plutôt que de s'appuyer uniquement sur ce qui a été appris lors de l'entraînement, le LLM récupère des documents pertinents en temps réel et les intègre dans son contexte avant de répondre.

Les 4 étapes d'un pipeline RAG

1. Indexation : Les documents sources (PDFs, Word, emails, pages web internes…) sont découpés en chunks, convertis en vecteurs numériques (embeddings) par un modèle d'embedding, puis stockés dans une base de données vectorielle.
2. Récupération (Retrieval) : Quand l'utilisateur pose une question, celle-ci est également convertie en vecteur. La base vectorielle retourne les N chunks les plus similaires (recherche par similarité cosinus ou produit scalaire).
3. Augmentation (Augmentation) : Les chunks récupérés sont injectés dans le prompt du LLM, sous forme de contexte supplémentaire.
4. Génération (Generation) : Le LLM génère sa réponse en s'appuyant à la fois sur ses connaissances intrinsèques et sur le contexte fourni.

L'avantage clé du RAG sur le fine-tuning est la mise à jour en temps réel : ajouter un nouveau document à la base vectorielle le rend immédiatement accessible, sans réentraîner le modèle. C'est pour cette raison que le RAG est privilégié pour les bases de connaissances d'entreprise qui évoluent fréquemment.

Enjeux de souveraineté dans le RAG

Un RAG cloud classique (ex. : Azure OpenAI + Azure Cognitive Search) implique que deux types de données quittent votre infrastructure à chaque requête :

• Les chunks de documents envoyés au service d'embedding (ex. : text-embedding-ada-002 d'OpenAI) lors de l'indexation
• Le contexte augmenté (chunks + question de l'utilisateur) envoyé au LLM pour la génération

Même si le fournisseur cloud garantit ne pas utiliser vos données pour entraîner ses modèles (ce que font Azure OpenAI et AWS Bedrock dans leurs conditions entreprise), vos documents transitent par leurs serveurs, sont traités sur leurs GPU, et peuvent être soumis à des lois extra-européennes comme le Cloud Act américain.

Catégories de données à risque dans un RAG

Catégorie de données	Exemples concrets	Risque RAG cloud	Approche recommandée
Données personnelles sensibles (RGPD Art. 9)	Dossiers RH, données santé, opinions syndicales	Très élevé	RAG souverain obligatoire
Secret des affaires	Brevets, roadmaps, prix, contrats clients	Élevé	RAG souverain fortement recommandé
Secret professionnel	Données cabinets avocats, médecins, experts-comptables	Très élevé	RAG souverain obligatoire
Données financières réglementées	Informations privilégiées (AMF), données DORA	Élevé	RAG souverain ou cloud certifié HDS/SecNumCloud
Données internes non confidentielles	Procédures internes, FAQ RH générique, documentation produit	Faible	RAG cloud acceptable avec DPA conforme
Données publiques	Documentation technique publique, contenus web	Nul	RAG cloud sans contrainte

Architecture RAG souveraine : les composants

Un RAG souverain complet peut être déployé sur votre infrastructure avec des composants 100 % open source. Voici l'architecture de référence.

Schéma de l'architecture RAG souveraine

┌─────────────────────────────────────────────────────────────┐
│                    INFRASTRUCTURE ON-PREMISE                │
│                                                             │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐  │
│  │   Sources    │    │  Ingestion   │    │  Embedding   │  │
│  │  Documents   │───▶│  Pipeline    │───▶│   Model      │  │
│  │ (PDF,DOCX,   │    │(LangChain /  │    │(nomic-embed/ │  │
│  │  emails...)  │    │ LlamaIndex)  │    │ multilingual │  │
│  └──────────────┘    └──────────────┘    │  -e5-large)  │  │
│                                          └──────┬───────┘  │
│                                                 │ vecteurs  │
│                                          ┌──────▼───────┐  │
│                                          │  Base        │  │
│  ┌──────────────┐    ┌──────────────┐    │  Vectorielle │  │
│  │  Interface   │    │    LLM       │    │(Qdrant /     │  │
│  │  Utilisateur │───▶│ d'inférence  │    │ ChromaDB /   │  │
│  │ (Open WebUI/ │    │  (Ollama /   │◀───│ Weaviate)    │  │
│  │  custom app) │    │  vLLM)       │    └──────────────┘  │
│  └──────────────┘    └──────────────┘                      │
│                                                             │
│  Modèles : Mistral 7B/24B, Llama 3.1 8B/70B, Qwen2.5      │
└─────────────────────────────────────────────────────────────┘

Stack technologique recommandée

Composant	Option 1 (légère)	Option 2 (production)	Critère de choix
Orchestrateur LLM	Ollama	vLLM	Ollama : simplicité. vLLM : throughput élevé, GPU optimisé.
Framework RAG	LlamaIndex	LangChain + LangSmith	LlamaIndex : RAG natif. LangChain : écosystème plus large.
Base vectorielle	ChromaDB	Qdrant	ChromaDB : prototype rapide. Qdrant : production, filtrage avancé.
Modèle d'embedding	nomic-embed-text	multilingual-e5-large	nomic : anglais. multilingual-e5 : multilingue, meilleur pour FR.
Modèle LLM	Mistral 7B Instruct	Mistral-Large ou Llama 3.1 70B	7B : CPU/GPU modeste. 70B : GPU serveur (2x A100).
Interface utilisateur	Open WebUI	Application custom	Open WebUI : déploiement rapide. Custom : intégration métier.

Exemple de configuration Ollama + Qdrant (Docker Compose)

# docker-compose.yml — Stack RAG souveraine
version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
    ports:
      - "127.0.0.1:11434:11434"  # Jamais exposé publiquement
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    restart: unless-stopped

  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant
    volumes:
      - qdrant_data:/qdrant/storage
    ports:
      - "127.0.0.1:6333:6333"   # Accès local uniquement
    environment:
      - QDRANT__SERVICE__API_KEY=${QDRANT_API_KEY}
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    volumes:
      - open_webui_data:/app/backend/data
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}
      - ENABLE_SIGNUP=false  # Désactiver l'inscription libre
    depends_on:
      - ollama
    restart: unless-stopped

volumes:
  ollama_data:
  qdrant_data:
  open_webui_data:

Choix de la base vectorielle

La base vectorielle est le cœur du système RAG. Son choix impacte les performances, la scalabilité et les fonctionnalités de filtrage disponibles.

Critère	ChromaDB	Qdrant	Weaviate	pgvector
Licence	Apache 2.0	Apache 2.0	BSD-3	PostgreSQL
Déploiement	Embarqué ou serveur	Docker/K8s natif	Docker/K8s	Extension PostgreSQL
Performances (1M vecteurs)	Correctes	Excellentes	Très bonnes	Bonnes
Filtrage métadonnées	Basique	Avancé (payloads JSON)	GraphQL puissant	SQL natif
Permissions par document	Manuel	Filtres natifs	Via GraphQL	Row-level security PostgreSQL
Maturité production	Prototype / dev	Production ready	Production ready	Production (si PG maîtrisé)
Multitenancy	Collections séparées	Collections + namespaces	Classes + tenants	Schémas / RLS
Cas d'usage idéal	POC, équipe dev	Production IA entreprise	Use cases graphe/ontologie	Données déjà dans PostgreSQL

Notre recommandation : Utilisez ChromaDB pour les phases de prototypage (démarrage en 5 minutes, aucune infrastructure), et migrez vers Qdrant pour la production. Qdrant offre le meilleur rapport performances/simplicité pour un RAG d'entreprise.

Architecture RAG cloud : les offres des hyperscalers

Azure OpenAI + Azure AI Search

La solution la plus répandue en France grâce aux datacenters français d'Azure (France Central, France South). Elle combine :

• Azure OpenAI Service : accès aux modèles GPT-4o, GPT-4 Turbo et text-embedding-3 via des endpoints dédiés
• Azure AI Search (ex-Cognitive Search) : moteur de recherche vectorielle managé avec filtres, semantic ranking et hybrid search
• Azure Blob Storage : stockage des documents sources
• Azure AI Document Intelligence : extraction de texte depuis PDFs et images

AWS Bedrock + Amazon Kendra

L'alternative AWS, plus récente en adoption française :

• Amazon Bedrock : accès aux modèles Anthropic Claude, Llama 3, Mistral et Amazon Titan
• Amazon Kendra : moteur de recherche documentaire avec compréhension sémantique
• Amazon Bedrock Knowledge Bases : solution RAG managée complète (ingestion, embedding, retrieval)

Google Vertex AI Search

• Vertex AI : plateforme ML avec Gemini Pro, PaLM 2 et modèles d'embedding Google
• Vertex AI Search (ex-Enterprise Search) : moteur de recherche vectorielle + BM25 hybride
• Document AI : extraction de contenu structuré depuis documents

Comparatif performances et coûts

Performances : RAG souverain vs RAG cloud

Métrique	RAG souverain (Qdrant + Mistral-Large)	RAG cloud (Azure OpenAI + AI Search)
Latence P50 (requête simple)	1,2 — 2,5 s	0,8 — 1,8 s
Latence P99 (requête complexe)	4 — 8 s	3 — 6 s
Throughput (req/min, 4 GPU A100)	120 — 180 req/min	Limité par quotas (600 req/min par défaut)
Qualité des réponses (FR, éval RAGAS)	0,78 — 0,85	0,82 — 0,90
Disponibilité	Dépend de votre infra	99,9 % SLA
Scalabilité	Manuelle (ajout GPU/nœuds)	Automatique (scale out managé)

Coûts : modèle de calcul comparatif

Pour une entreprise de 200 utilisateurs actifs générant 500 requêtes/jour en moyenne :

Poste de coût	RAG souverain (on-premise)	Azure OpenAI + AI Search
Embedding (indexation initiale, 1M tokens)	0 € (modèle local)	~20 € (text-embedding-3-small)
Embedding (requêtes, /mois)	0 €	~150 € (500 req/j × 30j × 1k tokens avg)
Génération LLM (/mois)	0 € (modèle local)	~2 400 € (GPT-4o, 500 req/j × 3k tokens)
Base vectorielle (/mois)	0 € (Qdrant open source)	~300 € (Azure AI Search S1)
Infrastructure matérielle	2 000 €/mois (amortissement 2× A100 PCIe)	0 € (managé)
Ops et maintenance (/mois)	~800 € (0,5 ETP DevOps)	~200 € (moindre maintenance)
Total mensuel	~2 800 €	~3 070 €

Au-delà de 150-200 utilisateurs actifs, le RAG souverain devient compétitif — et les GPU s'amortissent sur 4-5 ans. L'avantage coût du cloud disparaît rapidement avec le volume.

Sécurité et confidentialité des données

Ce que le RAG cloud fait voyager hors de votre périmètre

1. À l'indexation : Le texte extrait de vos documents (ou leurs chunks) est envoyé à l'API d'embedding du cloud. Pour 1 000 documents de 50 pages, cela représente des dizaines de millions de tokens de vos données les plus sensibles qui transitent vers des serveurs tiers.
2. À chaque requête : Les chunks récupérés (passages de vos documents) + la question de l'utilisateur sont envoyés au LLM cloud. Toute requête sur des données confidentielles implique leur transmission vers l'extérieur.
3. Les métadonnées : Noms de fichiers, chemins, auteurs, dates — informations qui peuvent révéler votre organisation interne.

Ce que garantissent (et ne garantissent pas) les clouds

Garantie	Azure OpenAI Enterprise	AWS Bedrock	RAG souverain
Pas d'utilisation pour entraînement	Oui (contractuel)	Oui (contractuel)	Natif — données ne quittent pas l'infra
Chiffrement en transit	TLS 1.3	TLS 1.3	TLS 1.3 (à configurer)
Chiffrement au repos	AES-256	AES-256	AES-256 (à configurer)
Localisation données (France)	Oui (France Central)	Non (Paris en dev)	Totale
Immunité Cloud Act	Non	Non	Oui
Audit indépendant de l'accès	Non (logs Azure seulement)	Non	Oui (vous contrôlez)
Conformité SecNumCloud	Non	Non	Possible

Migration d'un RAG cloud vers on-premise

La migration d'un RAG cloud existant vers une architecture souveraine est techniquement réalisable. Voici la méthode en 5 étapes.

Étape 1 — Audit de l'existant (semaine 1)

• Inventorier toutes les sources de documents indexées
• Identifier le modèle d'embedding utilisé (importante pour choisir le remplaçant)
• Mesurer les métriques de performance actuelles (latence, qualité des réponses)
• Identifier les intégrations (applications qui consomment l'API RAG)

Étape 2 — Setup de l'infrastructure (semaines 1-2)

# Installation Ollama + téléchargement des modèles
curl -fsSL https://ollama.ai/install.sh | sh

# Modèle de génération
ollama pull mistral-large:latest
# ou
ollama pull llama3.1:70b

# Modèle d'embedding (multilingue, meilleur pour le français)
ollama pull nomic-embed-text

# Démarrer Qdrant
docker run -d --name qdrant \
  -p 127.0.0.1:6333:6333 \
  -v $(pwd)/qdrant_storage:/qdrant/storage \
  -e QDRANT__SERVICE__API_KEY=$QDRANT_API_KEY \
  qdrant/qdrant:latest

Étape 3 — Ré-indexation des documents (semaines 2-3)

Les embeddings ne sont pas transférables entre modèles différents — vous devez ré-indexer l'ensemble de vos documents avec le nouveau modèle d'embedding local. Exemple de script Python :

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.vector_stores.qdrant import QdrantVectorStore
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama
import qdrant_client

# Configuration 100% locale
client = qdrant_client.QdrantClient(url="http://localhost:6333",
                                     api_key="votre_api_key")

embed_model = OllamaEmbedding(
    model_name="nomic-embed-text",
    base_url="http://localhost:11434"
)

llm = Ollama(
    model="mistral-large",
    base_url="http://localhost:11434",
    request_timeout=120.0
)

vector_store = QdrantVectorStore(client=client,
                                  collection_name="documents_entreprise")

# Indexation des documents
from llama_index.core import Settings, StorageContext
Settings.embed_model = embed_model
Settings.llm = llm

documents = SimpleDirectoryReader("/path/to/docs").load_data()
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex.from_documents(documents,
                                         storage_context=storage_context)

print(f"Index créé : {len(documents)} documents indexés")

Étape 4 — Tests et validation (semaine 3-4)

• Constituer un jeu de questions de référence (golden dataset) avec les réponses attendues
• Mesurer les métriques RAGAS (faithfulness, answer relevancy, context precision)
• Comparer avec les performances du RAG cloud sur les mêmes questions
• Tester les cas limites : questions hors périmètre, documents mal formatés, langues mixtes

Étape 5 — Basculement et décommission (semaines 5-8)

• Migration progressive du trafic (10% → 50% → 100%)
• Monitoring comparatif en parallèle pendant 2 semaines
• Décommission de l'infrastructure cloud (supprimer les index Azure AI Search, désactiver les endpoints OpenAI)
• Vérification que les données ne sont plus accessibles côté cloud (suppression des données résiduelles)

Cas d'usage par secteur

Secteur juridique — Recherche documentaire confidentielle

Un cabinet d'avocats indexe ses dossiers, contrats et jurisprudences dans un RAG souverain. Le secret professionnel interdit absolument l'utilisation d'un RAG cloud : les extraits de dossiers envoyés pour embedding constitueraient une violation du secret. Stack recommandée : Qdrant + Mistral 7B Instruct (latence faible pour recherche rapide) + interface personnalisée avec authentification par dossier.

Secteur santé — Aide à la décision médicale

Un hôpital déploie un assistant IA qui interroge les protocoles de soins internes et la littérature médicale. Les données de santé sont des données sensibles RGPD Article 9 — hébergement HDS obligatoire. Un RAG souverain déployé sur l'infrastructure HDS existante est la seule option conforme. Stack : vLLM + Qdrant + Llama 3.1 70B (meilleures performances médicales).

Secteur industriel — Documentation technique et maintenance

Un manufacturier indexe ses manuels de maintenance, schémas d'équipements et historiques d'interventions. Les données techniques représentent le savoir-faire de l'entreprise. Un RAG souverain sur le réseau OT/IT de l'usine permet un accès sans connexion Internet — critical pour les environnements industriels. Stack : Ollama + ChromaDB (volume modéré) + Open WebUI pour les techniciens.

Recommandations : quel RAG choisir ?

Situation	Recommandation	Raison
POC / exploration < 3 mois	RAG cloud	Rapidité de mise en place, pas d'infrastructure à gérer
Données publiques ou peu sensibles	RAG cloud acceptable	Ratio coût/bénéfice favorable si volume modéré
Données personnelles sensibles (Art. 9 RGPD)	RAG souverain obligatoire	Conformité réglementaire non négociable
Secret professionnel (avocat, médecin, expert-comptable)	RAG souverain obligatoire	Obligation déontologique
Secret des affaires, brevets, R&D	RAG souverain fortement recommandé	Risque espionnage industriel via Cloud Act
> 150 utilisateurs actifs	RAG souverain	Coût inférieur au cloud à partir de ce seuil
Environnement sans connexion Internet (OT, défense)	RAG souverain uniquement	Contrainte physique