RAG sécurisé — Retrieval Augmented Generation isolé

Définition

RAG (Retrieval Augmented Generation) est une architecture qui combine un LLM avec une base documentaire indexée — le LLM, au lieu de répondre uniquement à partir de ses connaissances internes, est "augmenté" par la recherche dans la base documentaire au moment de la requête. C'est le pattern dominant pour permettre à un LLM de répondre sur la base de documents propres à l'entreprise sans devoir le ré-entraîner.

Un RAG sécurisé est une architecture où :

1. L'indexation (extraction → chunking → embedding → stockage vectoriel) se fait sur infrastructure souveraine, sans envoi du contenu vers un fournisseur tiers.
2. La recherche vectorielle (similarité cosinus, BM25 hybride, etc.) est exécutée localement.
3. La génération par le LLM se fait sur infrastructure souveraine (cf. /criteres/llm-auto-heberge/).
4. Aucun prompt ni contexte client ne traverse Internet à aucune étape.

Cela suppose typiquement : une base de données vectorielle (pgvector, Qdrant, Weaviate, Milvus, ChromaDB) déployée en local + un modèle d'embedding open source (BGE-M3, e5, jina-embeddings) auto-hébergé + un LLM open source auto-hébergé.

Pourquoi c'est important pour un hébergeur HDS

Le RAG est le pattern le plus pertinent pour les applications IA santé : copilote médical sur dossiers patient, recherche dans un corpus de protocoles d'études cliniques, assistant infirmier sur les fiches CCAM, etc. L'avantage du RAG est qu'il permet au LLM de citer ses sources — utile pour la traçabilité médicale.

Le RAG sécurisé adresse plusieurs risques structurels du RAG en SaaS :

1. Fuite par l'index. Si le corpus envoyé pour indexation chez un tiers (typique pattern early 2023 chez Pinecone, Weaviate Cloud, etc.) contient des données sensibles, on a déjà perdu.
2. Fuite par le contexte enrichi. Le prompt envoyé au LLM contient les passages retrouvés — donc des extraits de documents sensibles. En API externe, ils transitent.
3. Dépendance à la disponibilité tiers. Une rupture d'API rend le service inopérant.

L'auto-hébergement intégral du RAG est techniquement plus complexe que le simple LLM auto-hébergé, mais c'est la seule réponse cohérente avec les exigences HDS pour des cas d'usage à fort contenu de données sensibles.

Comment ce critère est attribué dans le comparateur

• ✓ Vérifié — l'acteur documente publiquement une offre RAG opérée sur son infrastructure souveraine, en précisant l'embedding et la base vectorielle.
• ◆ Revendiqué — mention "RAG sécurisé" sans détail vérifiable.
• — Non documenté — pas de mention publique.

Pour quel profil c'est critique

Sources officielles

• HuggingFace — guides RAG : huggingface.co/blog.
• CNIL — Recommandation IA santé.
• Pgvector — github.com/pgvector/pgvector (la solution la plus citée pour un RAG souverain low-cost).

Limites

Le RAG sécurisé est plus exigeant en ressources que l'inférence pure : il faut maintenir une base vectorielle, surveiller la dérive des embeddings quand le corpus évolue, et garantir la cohérence des permissions (qui peut interroger quoi). Les acteurs qui revendiquent ce critère doivent démontrer une maîtrise opérationnelle complète, pas seulement un déploiement de POC.