RAG (Retrieval-Augmented Generation) : définition, fonctionnement, architecture

Quick Answer : RAG, définition en 30 secondes

Le RAG (Retrieval-Augmented Generation, « génération augmentée par recherche ») est une technique d’intelligence artificielle qui connecte un grand modèle de langage (LLM) à une base de documents. Avant de répondre à une question, le système recherche les passages pertinents dans cette base, les fournit au modèle, et le modèle génère une réponse fondée sur ces documents — avec citation des sources.

En pratique, un RAG fonctionne en 4 étapes :

Question — l’utilisateur pose une question en langage naturel.
Recherche (retrieval) — le système retrouve les documents les plus proches de la question dans une base vectorielle.
Augmentation — les passages trouvés sont insérés dans le prompt envoyé au LLM.
Génération — le LLM rédige une réponse ancrée dans ces passages, sources à l’appui.

Pourquoi c’est devenu le standard : un LLM seul répond depuis sa mémoire d’entraînement — figée, générique, sujette aux hallucinations. Le RAG le fait répondre depuis vos documents, à jour, vérifiables. C’est l’architecture IA la plus déployée en entreprise en 2026 (recherche documentaire, support niveau 1, onboarding, conformité).

Qu’est-ce que le RAG (Retrieval-Augmented Generation) ?

Le terme vient d’un article de recherche de 2020 (Lewis et al., Meta AI) : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. L’idée : plutôt que d’espérer que le modèle « sache », on lui donne de quoi savoir au moment de la question.

L’image la plus juste est celle d’un consultant qui ouvre vos classeurs avant de répondre. Le LLM apporte la capacité de lecture, de synthèse et de rédaction ; la base documentaire apporte les faits. Le RAG est la tuyauterie entre les deux.

Trois propriétés découlent de cette définition :

La connaissance est externe au modèle. Mettre à jour la réponse du système, c’est réindexer un document — pas ré-entraîner un modèle. Heures contre semaines.
La réponse est traçable. Chaque affirmation peut pointer vers sa source (« d’après la procédure RH-2024-03, paragraphe 4.2… »). Sans citation, vous n’avez pas un RAG : vous avez un LLM qui hallucine sur des documents internes.
Le modèle est interchangeable. Le même RAG peut tourner sur Mistral Large (souverain), GPT-4o ou Claude — le choix du LLM devient un paramètre, pas une fondation.

Comment fonctionne le RAG : le schéma étape par étape

Deux phases distinctes : la préparation (une fois, puis à chaque mise à jour) et la réponse (à chaque question).

Phase 1 — Préparation de la base (indexation) :

Collecte des documents sources (SharePoint, GED, wiki, Drive, CRM, contrats, FAQ).
Découpage (chunking) de chaque document en passages de 200 à 1 000 tokens.
Vectorisation (embeddings) : chaque passage est converti en une signature numérique qui capture son sens.
Stockage des vecteurs + métadonnées dans une base vectorielle (Qdrant, pgvector, Chroma).

Phase 2 — Réponse à une question (runtime) :

La question de l’utilisateur est convertie en vecteur avec le même modèle d’embeddings.
La base vectorielle retrouve les 5 à 10 passages les plus proches (similarité sémantique).
Ces passages sont insérés dans le prompt envoyé au LLM, avec une consigne stricte : répondre uniquement à partir des sources, citer, dire « je ne sais pas » si la réponse n’y est pas.
Le LLM génère la réponse, sources citées.

La force du dispositif : la recherche sémantique retrouve des passages par le sens, pas par mots-clés. « Combien de jours pour un décès de proche ? » retrouve la procédure « congés exceptionnels » même si le mot « décès » n’y figure qu’une fois.

Pourquoi coupler un LLM à un RAG plutôt que l’utiliser seul

Un LLM utilisé seul a trois limites structurelles que le RAG corrige :

Limite du LLM seul	Ce que change le RAG
Connaissance figée à la date d’entraînement	Connaissance mise à jour par simple réindexation
Aucune connaissance de vos documents internes	Répond à partir de votre documentation
Hallucinations sur les faits précis, invérifiables	Réponses ancrées dans des sources citées, vérifiables

C’est pourquoi le RAG s’est imposé face au fine-tuning entre 2024 et 2026 : les LLM à contexte long (100 000 tokens et plus) acceptent des dizaines de pages en entrée, les bases vectorielles open-source (Qdrant, Chroma, pgvector) se déploient en quelques heures, et les frameworks (LangChain, LlamaIndex) ont stabilisé les patterns. Une PME prototype un RAG en 1 à 2 semaines.

Architecture d’un RAG en production : les 6 composants

Une pipeline RAG mature comporte six composants.

[Sources documentaires]
   SharePoint, GED, wiki, Drive, CRM
            │
            ▼
[1. Ingestion] ─── parsing PDF/DOCX/HTML, OCR si scanné
            │
            ▼
[2. Chunking] ─── découpage en passages de 200-1000 tokens
            │
            ▼
[3. Embeddings] ─── signature numérique par chunk
            │
            ▼
[4. Vectordb] ── stockage Qdrant / Chroma / pgvector
            │
            ├──── (au runtime, requête utilisateur)
            ▼                              │
[5. Retrieval] ◄─────────────────── embedding requête
       │       top-K chunks                │
       ▼                                   │
[6. Génération] ─── LLM avec contexte ◄────┘
       │
       ▼
[Réponse + citations sources]

1. Ingestion documentaire. Parsing PDF (OCR si scanné), DOCX, HTML, Markdown, transcripts audio (Whisper). Bonne pratique : préserver les métadonnées (auteur, date, source, sensibilité) tout au long du pipeline pour pouvoir filtrer en aval.

2. Chunking. Découpage fixe (500 tokens, simple), sémantique (par section logique, plus pertinent) ou hiérarchique (vue d’ensemble + détail). Le chunking est ce qui distingue un RAG médiocre d’un RAG performant — investir du temps ici.

3. Embeddings. Mistral Embed (France, souverain), OpenAI text-embedding-3 (US, dépendance au transfert), ou modèles ouverts self-hosted (BGE-M3, E5). Pour la souveraineté : Mistral Embed ou open-source déployé en interne.

4. Base vectorielle. Qdrant (référence 2026, self-hostable), Chroma (POC), pgvector (si Postgres déjà en place), Weaviate/Milvus (grande échelle). Pinecone (SaaS US) à éviter pour des données sensibles. Pour les cas réglementés : Qdrant self-hosted sur Scaleway, OVHcloud ou cloud SecNumCloud.

5. Retrieval. Similarité cosinus, top-K (5-10). Améliorations courantes : hybrid search (vecteurs + BM25, meilleure précision sur les termes techniques), reranking (cross-encoder), filtres metadata (par date, source, profil utilisateur).

6. Génération avec citation. Le LLM reçoit la question, les passages, et un prompt système exigeant des citations explicites. La citation est non négociable : c’est la condition de la confiance utilisateur et de la conformité (article 5.1.d RGPD — exactitude).

RAG ou fine-tuning : comment choisir

Critère	RAG	Fine-tuning
Délai de mise en œuvre	1-4 semaines	4-12 semaines
Coût initial	5-25 k€	30-100 k€
Mise à jour de la connaissance	Réindexer (heures)	Ré-entraîner (jours)
Transparence	Citations possibles	Boîte noire
Précision factuelle	Élevée (ancrée sources)	Moyenne
Style / ton spécifique	Limité	Excellent
Compétences requises	Dev avec API LLM	Data science + GPU

Règle de décision : connaissance qui évolue, sources multiples, citation requise → RAG. Style à apprendre, terminologie ultra-spécialisée, latence critique → fine-tuning. La majorité des cas d’usage entreprise → RAG en premier choix, fine-tuning en seconde intention si l’évaluation le justifie.

Exemples de RAG en entreprise

Support / FAQ produit niveau 1 : documentation produit + tickets résolus indexés ; baisse du volume de tickets niveau 1 de l’ordre de 30-50 % sur les périmètres bien cadrés.
Onboarding interne : politiques RH, procédures, supports de formation interrogeables en langage naturel — au lieu de 12 wikis.
Recherche juridique et conformité : jurisprudence, contrats types, procédures internes pour juristes et fonctions conformité.
R&D : publications internes, brevets, comptes rendus — retrouver des travaux antérieurs oubliés.
Rédaction commerciale : propositions passées et fiches produit indexées pour générer des propositions factuellement ancrées.

Côté budget : 50 à 200 € par mois en fonctionnement pour une PME (1 000 documents, 100 utilisateurs), 5 à 25 k€ d’investissement initial selon la complexité. POC en 1-2 semaines, industrialisation complète en 3 à 6 mois — le poste qui prend du temps n’est pas la techno, c’est l’ingestion des sources et la gouvernance des accès.

RAG et RGPD

Le RAG est un traitement automatisé qui doit être encadré :

Inscription au registre (article 30) : finalité, données traitées, sous-traitants, durées.
AIPD si la base contient des données personnelles à risque — voir notre guide AIPD pour projet IA.
Pseudonymisation à l’ingestion quand possible — voir notre guide anonymisation et NER par IA et notre guide IA et RGPD.
Hébergement souverain pour les données sensibles : Mistral + Qdrant sur Scaleway — voir notre guide LLM local en entreprise.
Contrôle d’accès : filtres metadata alignés sur les permissions des sources d’origine. Sans ce filtrage, le RAG devient un canal de fuite de droits.

Ce qu’on refuse de promettre

Trois antiPatterns qu’on évite chez DPLIANCE quand on conçoit un RAG sur mesure.

« On indexe tout, on règlera l’accès après. » Faux. Le contrôle d’accès se conçoit dès l’ingestion. Indexer 100 000 documents avec accès uniforme, c’est créer un canal de fuite de droits monumental — la rétro-application des permissions est techniquement complexe et juridiquement fragile.

« Le RAG corrige des sources mal organisées. » Faux. Un RAG sur des sources contradictoires répond avec des informations contradictoires. Le RAG amplifie la qualité des sources, il ne la corrige pas. Profiter du projet pour faire le ménage documentaire est souvent l’effet de bord le plus utile.

« On démarre direct avec un agent qui fait RAG + actions. » Mauvaise idée pour un premier projet. Le RAG seul a déjà ses pièges (chunking, accès, citation). Y ajouter un agent autonome multiplie les risques. Démarrer par un RAG simple, valider, puis ajouter de l’orchestration agentique — voir notre guide IA agentique.

Ce type d’architecture, nous la concevons et la déployons en production — découvrez notre agence Data/IA. Quand une solution sur mesure inclut un RAG, on livre la stack complète : modèle (Mistral, on-premise selon la sensibilité), vectordb (Qdrant souverain par défaut), ingestion de vos sources, contrôle d’accès aligné sur vos permissions, citations systématiques, monitoring qualité.

FAQ

Qu’est-ce que le RAG (définition simple) ?

Le RAG (Retrieval-Augmented Generation, ou « génération augmentée par recherche ») est une technique d’IA qui connecte un LLM à une base de documents : avant de répondre, le système recherche les passages pertinents dans cette base, les fournit au modèle en contexte, et le modèle génère une réponse fondée sur ces documents, avec citation des sources. C’est l’architecture IA la plus déployée en entreprise en 2026 pour faire répondre un modèle à partir d’une documentation interne plutôt que de sa mémoire générique.

Quelle est la différence entre un RAG et un LLM utilisé seul ?

Un LLM seul répond depuis sa mémoire d’entraînement : connaissance figée à une date de coupure, aucune connaissance de vos documents internes, hallucinations fréquentes sur les faits précis. Un RAG force le LLM à s’appuyer sur des documents récupérés au moment de la question : la connaissance est à jour (il suffit de réindexer), propre à votre organisation, et vérifiable grâce aux citations. Le modèle reste le même ; c’est le contexte fourni qui change tout.

Quand faut-il choisir RAG plutôt que fine-tuning ?

RAG est généralement préférable au fine-tuning pour : une connaissance qui évolue régulièrement (procédures, catalogue produit), des sources multiples à citer, un besoin de transparence sur l’origine de l’information, une équipe sans expertise data science. Le fine-tuning est préférable pour : un style ou ton spécifique à apprendre durablement, une terminologie ultra-spécialisée, une latence très critique. La majorité des cas d’usage entreprise gagnent à démarrer en RAG ; le fine-tuning vient en complément si le RAG seul ne suffit pas.

Quelle base vectorielle choisir pour un RAG ?

Pour PME et POC : Qdrant (open-source, self-hostable, la référence souveraine en 2026), Chroma (très simple, bon pour démarrer), pgvector (extension PostgreSQL, idéal si Postgres est déjà dans votre stack). Pour la production à grande échelle : Qdrant en cluster, Weaviate, Milvus. Pour la souveraineté maximale : self-hosted sur Scaleway, OVHcloud ou cloud SecNumCloud. À éviter pour des données sensibles : les vectordb SaaS US (Pinecone) qui ré-introduisent le risque de transfert que le RAG était censé contourner.

Le RAG élimine-t-il les hallucinations ?

Non, mais il les réduit drastiquement. Le RAG contraint le LLM à se fonder sur des documents fournis, ce qui fait typiquement passer les hallucinations factuelles de 90 % à moins de 5 % sur des questions dont la réponse est dans le corpus. Les hallucinations résiduelles surviennent quand les documents ne contiennent pas la réponse (le modèle invente au lieu de dire « je ne sais pas »), quand il extrapole malgré le contexte, ou quand les sources se contredisent. Un bon RAG impose la citation des sources et un mécanisme explicite « réponse introuvable ».

Quelle est la différence entre RAG et agent IA ?

Un RAG répond à une question en s’appuyant sur des documents — c’est un composant. Un agent IA décide d’une succession d’actions (recherche, appel API, écriture, validation humaine) pour accomplir une mission — c’est un système. Le RAG est souvent une brique des agents : l’agent fait du RAG quand il doit chercher de l’information, mais peut aussi envoyer un mail ou lire un calendrier. Démarrer par un RAG est plus simple et moins risqué qu’un agent autonome. Voir notre guide IA agentique.

Le RAG est-il conforme RGPD ?

Le RAG est un traitement automatisé à inscrire au registre des traitements (article 30 RGPD). Si la base de connaissances contient des données personnelles, AIPD recommandée et obligatoire selon les cas. Hébergement : LLM + vectordb sur infrastructure souveraine (Mistral + Qdrant sur Scaleway) pour éviter le risque de transfert UE-US. Contrôle d’accès indispensable : un utilisateur ne doit voir que les passages auxquels il a légitimement accès dans les sources — sinon le RAG devient un canal de fuite de droits. Voir notre guide IA et RGPD.

Sources : Lewis et al. 2020, « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks » et travaux ultérieurs ; documentation officielle Mistral AI, Qdrant, Chroma, pgvector, Weaviate ; documentation LangChain et LlamaIndex ; Règlement (UE) 2016/679 (RGPD) ; CNIL — recommandations sur l’IA et le RGPD.

Pour cadrer un projet RAG dans votre organisation — architecture, vectordb, intégration SI, contrôle d’accès, conformité — voir notre guide LLM local en entreprise, notre guide IA et RGPD, notre guide IA agentique, ou contactez-nous via nos solutions IA sur mesure.