Guides

RAG en 2026 : le guide complet pour connecter une IA à vos données

Comprenez le RAG en 2026 : architecture, embeddings, recherche hybride, bases vectorielles, sécurité, RGPD, évaluation, coûts et mise en production.

Promptique13 août 202625 min de lecture

Connecter une intelligence artificielle à la documentation d’une entreprise paraît simple : on dépose des fichiers, on pose une question et le modèle répond. En production, la difficulté se trouve ailleurs. Il faut retrouver le bon passage, au bon moment, pour la bonne personne, préserver ses droits d’accès, citer la preuve et savoir refuser lorsque les documents ne suffisent pas. Le RAG, ou génération augmentée par récupération, organise précisément cette chaîne.

Ce guide explique comment concevoir un RAG en 2026 sans dépendre d’un fournisseur. Il s’adresse autant au décideur qui doit cadrer le projet qu’au praticien chargé de l’architecture, des données ou de l’évaluation. Vous apprendrez à préparer les sources, découper les documents, produire des embeddings, choisir un index, combiner recherche sémantique et recherche lexicale, évaluer chaque composant et sécuriser le système au regard du RGPD.

Contenu vérifié le 13 août 2026. Les principes restent volontairement indépendants des modèles, bases vectorielles et services cloud. Les fonctions, tarifs et limites de chaque produit doivent être contrôlés dans sa documentation au moment du déploiement.

L’essentiel en 60 secondes. Un RAG ne rend pas un modèle omniscient et ne supprime pas les hallucinations. Il recherche d’abord des passages autorisés dans une base documentaire, puis les fournit au modèle afin qu’il formule une réponse appuyée sur ces éléments. La qualité dépend surtout de cinq points : des sources fiables et à jour, un découpage adapté, une récupération mesurée sur de vraies questions, des citations vérifiables et des contrôles d’accès appliqués avant la recherche. Commencez petit, évaluez le retriever séparément du générateur et prévoyez une réponse explicite lorsque la preuve manque.

Qu’est-ce que le RAG ?

RAG signifie Retrieval-Augmented Generation, soit génération augmentée par récupération. Le principe consiste à associer deux systèmes. Le premier recherche des informations dans un corpus externe. Le second, généralement un grand modèle de langage, produit une réponse à partir de la question et des passages récupérés.

L’article fondateur de Lewis et ses coauteurs, publié à NeurIPS en 2020, combinait une mémoire paramétrique, portée par le modèle, avec une mémoire non paramétrique, constituée d’un index dense de passages. En 2026, le terme RAG désigne plus largement une architecture applicative : ingestion de données, indexation, recherche, éventuel reclassement, construction du contexte, génération, citations et contrôles.

La distinction est importante. Le modèle possède des connaissances apprises pendant son entraînement, mais celles-ci peuvent être anciennes, imprécises ou impossibles à attribuer. Le corpus RAG peut, lui, être mis à jour sans réentraîner le modèle. Il peut contenir des procédures internes, contrats, catalogues, tickets, normes, bases de connaissances ou données structurées. Chaque passage peut conserver une origine, une date, une version et des droits d’accès.

Ce que le RAG résout, et ce qu’il ne résout pas

Il rend une connaissance externe consultable. Une nouvelle procédure peut être indexée sans modifier les paramètres du modèle.
Il apporte de la traçabilité. Une réponse peut pointer vers le document, la page, la section et la version utilisés.
Il réduit le contexte inutile. Le modèle reçoit quelques passages ciblés au lieu d’un dépôt documentaire entier.
Il facilite la gouvernance. Les documents peuvent être retirés, réindexés, expirés ou filtrés selon l’utilisateur.

Le RAG ne garantit toutefois ni vérité, ni exhaustivité, ni conformité. Si la source est fausse, si le bon passage n’est pas retrouvé ou si le modèle déforme la preuve, la réponse reste défaillante. Un système peut aussi citer un passage réel qui ne soutient pas exactement l’affirmation formulée. Pour comprendre ce risque, consultez notre guide sur les hallucinations des IA génératives et leurs parades.

À retenir. Le RAG n’est pas une base de connaissances magique. C’est une chaîne de recherche et de génération dont chaque maillon doit être observable, testé et gouverné.

Comment fonctionne un pipeline RAG ?

Un pipeline RAG comporte une phase hors ligne, qui prépare les connaissances, puis une phase en ligne, exécutée pour chaque question. Séparer ces deux chemins simplifie le diagnostic : une erreur de réponse peut venir de l’ingestion, de la récupération ou de la génération.

1. Ingestion : transformer des sources en documents fiables

L’ingestion collecte les contenus autorisés et les transforme dans un format exploitable. Elle peut traiter du HTML, des fichiers bureautiques, des PDF, des courriels, une documentation produit, un wiki ou des enregistrements issus d’une base métier. L’extraction doit préserver autant que possible la structure : titre, sous-titres, listes, tableaux, numéros de page et liens.

Un PDF scanné exige une reconnaissance optique de caractères. Un tableau mal extrait peut inverser des colonnes et rendre la réponse dangereuse. Un document dupliqué dans plusieurs versions peut faire remonter une règle obsolète. Le pipeline doit donc dédupliquer, normaliser l’encodage, détecter la langue, identifier la version et rejeter les fichiers corrompus. Conservez l’original, son empreinte, sa provenance, sa date d’ingestion et le résultat de l’extraction.

2. Chunking : découper sans casser le sens

Un chunk est une unité de recherche, souvent un passage de quelques phrases. Un découpage trop court perd le contexte nécessaire. Un découpage trop long mélange plusieurs sujets et augmente le bruit envoyé au modèle. Il n’existe donc pas de taille universelle.

Découpage structurel : suivre les titres, articles, sections, paragraphes ou lignes d’un tableau.
Découpage glissant : conserver un léger chevauchement pour éviter qu’une définition et son exception soient séparées.
Découpage sémantique : détecter les changements de sujet, utile lorsque la structure du fichier est pauvre.
Parent-enfant : indexer des petits passages précis, puis restituer une section parente plus complète au générateur.

Le bon réglage se mesure sur vos questions. Pour une politique RH, la section et sa date d’effet comptent. Pour du code, une fonction complète vaut souvent mieux qu’un nombre fixe de tokens. Pour un catalogue, chaque fiche produit peut devenir une unité. Stockez avec chaque chunk son identifiant stable, le document parent, l’emplacement, la version, la langue, la date de validité et les règles d’accès.

3. Embeddings : représenter le sens sous forme de vecteurs

Un modèle d’embedding transforme un texte en vecteur numérique. Deux passages proches dans l’espace vectoriel sont supposés partager une proximité sémantique. La question de l’utilisateur est encodée avec un modèle compatible, puis comparée aux vecteurs des chunks.

Le choix ne se résume pas au nombre de dimensions. Vérifiez la qualité dans les langues du corpus, la compréhension du vocabulaire métier, la longueur maximale, le coût, la latence, la licence, le lieu de traitement et la stabilité de version. Une migration de modèle d’embedding impose généralement de recalculer les vecteurs et de comparer les deux index sur un jeu d’évaluation. Ne mélangez pas silencieusement des vecteurs produits par des modèles incompatibles.

4. Indexation : rendre les passages retrouvables

L’index associe au minimum un vecteur, le texte du chunk et ses métadonnées. Une recherche exacte compare la requête à tous les vecteurs et offre le meilleur rappel possible, mais devient coûteuse à grande échelle. Les index de voisins les plus proches approximatifs, notamment HNSW ou IVFFlat, accélèrent la recherche en acceptant un compromis entre vitesse et rappel.

La documentation officielle de pgvector rappelle clairement ce compromis : HNSW offre généralement un meilleur rapport vitesse-rappel, avec davantage de mémoire et un temps de construction supérieur, tandis qu’IVFFlat se construit plus vite et consomme moins de mémoire. Ce choix doit être validé avec vos volumes, filtres et objectifs de latence, pas avec un benchmark générique.

5. Retrieval : retrouver, filtrer et reclasser

Au moment de la question, le système commence par établir l’identité et les droits de l’utilisateur. Il peut ensuite reformuler la requête, appliquer des filtres de tenant, langue, date ou version, puis lancer une ou plusieurs recherches. La recherche dense repère une proximité de sens. La recherche lexicale, comme BM25, excelle souvent sur les références exactes, acronymes, numéros de contrat ou noms de produit. Une recherche hybride fusionne les deux listes.

Les meilleurs candidats peuvent ensuite être reclassés par un reranker, plus lent mais plus précis. Le premier étage privilégie le rappel et ramène un ensemble assez large. Le second privilégie la précision et sélectionne les passages réellement utiles. Pour une question ambiguë, le système peut générer plusieurs variantes de recherche ou demander une clarification. Pour une question conversationnelle, il doit reformuler l’échange en requête autonome sans inventer d’intention.

Les travaux sur le Dense Passage Retrieval ont montré l’intérêt des représentations denses pour la recherche de passages. Cela ne signifie pas que le dense remplace toujours le lexical. Dans une documentation réelle, les deux signaux sont complémentaires.

6. Génération : répondre avec preuves et limites

Le générateur reçoit une instruction, la question et les passages retenus. L’instruction doit définir le rôle des sources, le format de réponse, la manière de citer et le comportement en cas d’information absente ou contradictoire. Un bon système sépare nettement les instructions du contenu récupéré et traite ce dernier comme une donnée potentiellement non fiable, jamais comme une commande.

Chaque affirmation importante doit pouvoir être reliée à un passage précis.
La réponse doit distinguer le fait présent dans les sources de l’inférence du modèle.
Les contradictions, dates et versions doivent être signalées.
Si les preuves sont insuffisantes, le système doit le dire et proposer une action utile.

Une grande fenêtre de contexte ne dispense pas de sélectionner les passages. L’étude Lost in the Middle a montré que la capacité nominale à accepter un long contexte ne garantit pas une utilisation robuste des informations, notamment lorsque l’élément pertinent se trouve au milieu. Plus de contexte peut aussi signifier plus de coût, de latence et de bruit.

Les principales architectures RAG en 2026

Architectures RAG et situations adaptées
Architecture	Principe	Quand l’utiliser	Point de vigilance
RAG simple	Une recherche vectorielle, puis génération	Prototype, corpus homogène, questions simples	Faible sur les identifiants exacts et les questions complexes
RAG hybride	Fusion recherche dense et lexicale	Documentation métier avec termes, codes et synonymes	Poids de fusion à calibrer sur des cas réels
RAG avec reranking	Recherche large, puis reclassement précis	Exigence élevée de précision	Latence et coût supplémentaires
RAG hiérarchique	Recherche fine, restitution d’un parent plus riche	Contrats, normes, manuels structurés	Relations parent-enfant à maintenir
RAG structuré	Texte associé à SQL, API ou graphe	Chiffres, inventaires, dépendances, données à jour	Validation stricte des requêtes et permissions
RAG agentique	Un agent choisit les recherches et outils	Questions en plusieurs étapes et sources multiples	Surface d’attaque, coût et imprévisibilité accrus

Le RAG multimodal ajoute des images, graphiques, captures ou audio. Le défi n’est pas seulement de produire un embedding multimodal : il faut préserver le lien entre la légende, le visuel, le tableau et la page. Le Graph RAG représente explicitement des entités et relations, utile pour certaines questions de dépendance ou de parcours, mais il ajoute une couche de modélisation et de maintenance. Il n’est pas automatiquement supérieur à un bon RAG hybride.

Une architecture agentique peut décomposer une question, choisir un index, interroger une base structurée puis vérifier une réponse. Elle devient pertinente lorsque la procédure justifie cette autonomie. Pour distinguer récupération, outils, mémoire et protocole MCP, lisez notre guide complet sur les agents IA et MCP.

Comment choisir une base vectorielle ?

La base vectorielle n’est qu’un composant du système. Une équipe disposant déjà de PostgreSQL peut préférer une extension vectorielle afin de conserver transactions, métadonnées et sauvegardes dans le même environnement. Un corpus très volumineux, multitenant ou soumis à une charge de recherche élevée peut justifier un moteur spécialisé. Un service managé réduit l’exploitation, mais crée des dépendances de coût, de localisation et de portabilité.

Critères de sélection d’un moteur de recherche vectorielle
Critère	Question à poser	Preuve attendue
Qualité de recherche	Quel rappel obtient-on au niveau de latence visé ?	Benchmark sur votre corpus et vérité terrain
Filtres	Les permissions sont-elles appliquées avant ou pendant la recherche ?	Tests d’isolement et plan d’exécution
Recherche hybride	Dense, lexical et fusion sont-ils natifs ou à orchestrer ?	Mesures par type de requête
Mises à jour	Comment supprimer, réindexer et remplacer un document ?	Test de fraîcheur et preuve de suppression
Exploitation	Quelles sauvegardes, restaurations, métriques et alertes existent ?	Exercice de restauration chronométré
Sécurité	Chiffrement, réseau privé, rôles et journaux sont-ils disponibles ?	Revue d’architecture et test d’accès négatif
Portabilité	Peut-on exporter textes, métadonnées et vecteurs ?	Export réimporté dans un environnement vierge
Coût total	Quel coût avec réplication, index, trafic et croissance ?	Simulation à 12 et 24 mois

Ne choisissez pas sur la seule vitesse d’une démonstration. Mesurez au minimum le rappel du top k, la latence aux percentiles 50 et 95, le débit, le temps d’indexation, la taille de l’index et le comportement avec filtres. Un index approximatif peut retourner moins de résultats pertinents après un filtrage très sélectif. Testez donc les combinaisons réelles de tenant, service, langue et date.

Conseil pratique. Gardez le texte canonique et les métadonnées dans un format exportable. Un vecteur peut être recalculé. Une provenance ou un droit d’accès perdu est beaucoup plus difficile à reconstruire.

Sécurité, confidentialité et RGPD

Un RAG concentre des documents, des index et des journaux de questions qui peuvent révéler des informations sensibles. Les embeddings ne doivent pas être considérés comme anonymes par défaut. Ils restent liés à des contenus, peuvent exposer des similarités et doivent recevoir une protection proportionnée aux données sources. La sécurité se conçoit de l’ingestion à l’affichage.

Appliquer les droits avant la récupération

Chaque chunk doit hériter des permissions de son document. L’identité, le tenant, le rôle, le périmètre et, si nécessaire, le niveau de classification doivent filtrer les candidats avant leur exposition au modèle. Récupérer des passages interdits puis les retirer après coup laisse déjà circuler des données et peut révéler des scores ou des métadonnées.

séparer les tenants lorsque le niveau de risque le justifie ;
limiter l’écriture dans l’index au pipeline d’ingestion ;
journaliser les modifications, recherches sensibles et décisions de filtrage ;
révoquer rapidement un document lorsque sa permission change ;
tester qu’un utilisateur non autorisé n’obtient ni contenu, ni titre, ni citation.

Se défendre contre l’injection et l’empoisonnement

Un document récupéré peut contenir une instruction malveillante, visible ou cachée, qui demande au modèle d’ignorer ses règles, de divulguer un secret ou d’appeler un outil. C’est une injection indirecte. Un attaquant peut aussi ajouter des textes conçus pour remonter sur des requêtes fréquentes : c’est un empoisonnement du corpus.

Le guide de sécurité RAG de l’OWASP recommande notamment de suivre la provenance, vérifier l’intégrité, rechercher les motifs suspects, cloisonner les droits et surveiller l’index. Ajoutez une chaîne de confiance pour les connecteurs, une validation des types de fichiers, une analyse du texte extrait et une approbation pour les nouvelles sources. Délimitez le contenu récupéré et dites explicitement au modèle de le traiter comme une donnée, pas comme une instruction.

Aucun prompt ne constitue à lui seul une barrière de sécurité. Un agent relié à des outils doit disposer de capacités minimales, d’autorisations vérifiées côté serveur et d’une validation humaine avant les actions sensibles. Une réponse RAG destinée à informer ne doit pas devenir silencieusement un ordre de paiement, une modification de compte ou une décision individuelle.

Appliquer le RGPD au cycle complet

Lorsque les sources, questions, réponses ou journaux contiennent des données personnelles, documentez les finalités, la base légale, les catégories de données, les destinataires, les durées de conservation et les transferts éventuels. Le principe de minimisation s’applique aussi au corpus : indexer tout ce qui est techniquement accessible n’est pas une finalité.

Cartographier : source originale, copie extraite, chunks, embeddings, cache, traces et sauvegardes.
Minimiser : retirer les champs inutiles et éviter les journaux de prompts trop détaillés.
Limiter : définir des durées et un mécanisme effectif de suppression dans tous les dérivés.
Informer : expliquer l’usage du système et les droits lorsque le traitement l’exige.
Évaluer : réaliser une AIPD si le traitement est susceptible d’engendrer un risque élevé.

La CNIL consacre des recommandations au développement des systèmes d’IA et insiste sur la responsabilité, la minimisation, la sécurité et l’analyse d’impact. Le profil NIST pour l’IA générative complète utilement cette approche avec la gouvernance, les tests avant déploiement, la provenance et la gestion des incidents.

Le cadre juridique dépend du cas d’usage, pas du mot RAG. Un assistant documentaire interne, un outil de recrutement et un système médical n’ont ni les mêmes risques ni les mêmes obligations. Notre guide IA générative en entreprise, RGPD et AI Act permet d’inscrire le projet dans une gouvernance plus large.

Comment évaluer un RAG sérieusement ?

Une démonstration réussie ne prouve rien sur la production. L’évaluation doit utiliser un jeu de questions représentatif, versionné et annoté. Il doit couvrir les requêtes fréquentes, rares, ambiguës, multilingues, contradictoires, sans réponse, sensibles aux permissions et dépendantes d’une date. Incluez des formulations naturelles, des fautes, des acronymes et des questions conversationnelles.

Mesurer d’abord la récupération

Recall@k : la preuve attendue figure-t-elle parmi les k passages récupérés ?
Precision@k : quelle part des passages récupérés est réellement pertinente ?
MRR : à quel rang apparaît le premier passage pertinent ?
nDCG : le classement respecte-t-il les degrés de pertinence ?
Taux de couverture : quelle part des questions répondables dispose d’au moins une preuve ?

Si la preuve n’entre jamais dans le contexte, modifier le prompt du générateur ne corrigera pas le problème. Inspectez les échecs par source, langue, longueur, type de question et filtre. Comparez dense seul, lexical seul, hybride, différents chunkings, valeurs de k et rerankers. Gardez une référence de recherche exacte sur un sous-ensemble afin de mesurer la perte due à l’index approximatif.

Mesurer ensuite la réponse

Dimensions essentielles d’évaluation d’une réponse RAG
Dimension	Question de contrôle
Fidélité	Chaque affirmation est-elle soutenue par le contexte fourni ?
Pertinence	La réponse traite-t-elle la question sans digression ?
Exactitude	Le résultat correspond-il à une référence validée lorsque celle-ci existe ?
Citations	Les liens pointent-ils vers le bon passage et la bonne version ?
Abstention	Le système refuse-t-il correctement quand la preuve manque ?
Sécurité	Résiste-t-il aux injections, fuites inter-tenant et demandes interdites ?
Utilité	Un utilisateur peut-il agir correctement à partir de la réponse ?

Les cadres de recherche RAGAS et ARES proposent des méthodes pour séparer pertinence du contexte, fidélité et pertinence de la réponse. Les juges basés sur un LLM accélèrent les itérations, mais ils peuvent être biaisés ou instables. Calibrez-les avec un échantillon humain, conservez les versions du juge et faites relire les erreurs à fort impact par des experts du domaine.

Définissez des seuils avant le pilote : taux minimal de récupération, taux maximal d’affirmations non soutenues, latence acceptable et zéro fuite de permission. Séparez les critères bloquants des préférences de style. La méthode détaillée dans Évaluer un prompt : critères, cas de test et non-régression s’adapte bien aux prompts de génération et aux scénarios complets du RAG.

Coûts, latence et exploitation

Le prix du modèle de génération n’est qu’une ligne. Le coût total inclut extraction et OCR, embeddings initiaux, réindexation, stockage des textes et vecteurs, réplication, recherche, reranking, tokens de contexte, cache, observabilité, évaluation, sécurité et revue humaine. Les heures consacrées à corriger les sources représentent souvent une part majeure de la valeur créée, même si elles apparaissent peu dans la facture cloud.

Leviers de coût et compromis
Levier	Réduit	Risque associé
Chunks plus courts	Tokens par passage	Contexte insuffisant, davantage de vecteurs
Top k plus faible	Reranking et contexte	Preuve manquée
Index approximatif	Latence de recherche	Rappel inférieur
Cache	Recherches et génération répétées	Réponse périmée ou mal isolée
Petit modèle de génération	Coût et latence	Fidélité ou synthèse plus faibles
Réindexation incrémentale	Calcul d’ingestion	Documents supprimés ou modifiés oubliés

Modélisez le coût par étape plutôt qu’avec un montant unique. Pour chaque mois : volume nouveau à extraire, nombre de chunks à encoder, taille d’index répliquée, requêtes, candidats reclassés, tokens envoyés au modèle, réponses générées et taux de contrôle humain. Ajoutez des scénarios de croissance et de reprise après incident. Une solution moins chère par requête peut coûter davantage si elle exige une maintenance constante ou génère plus d’erreurs.

Côté latence, mesurez chaque segment : authentification, reformulation, embedding de requête, recherche, reranking, assemblage, premier token et réponse complète. Fixez un budget par étape. La diffusion progressive de la réponse améliore la perception, mais ne doit pas afficher un contenu non vérifié avant les contrôles nécessaires.

RAG, long contexte ou fine-tuning ?

Ces approches répondent à des problèmes différents et peuvent être combinées. Le RAG apporte des faits externes, actualisables et citables. Le fine-tuning modifie le comportement du modèle : style, format, classification ou maîtrise répétée d’une tâche. Une longue fenêtre de contexte permet de joindre ponctuellement un dossier, sans construire immédiatement un index. Un outil ou une requête structurée calcule une valeur au lieu de demander au modèle de la deviner.

Choisir la bonne méthode d’adaptation
Besoin principal	Approche prioritaire	Pourquoi
Connaissance souvent mise à jour et citée	RAG	Sources remplaçables sans réentraînement
Format ou ton très stable	Prompt, exemples, puis fine-tuning si nécessaire	Le besoin porte sur le comportement
Un dossier ponctuel de taille raisonnable	Long contexte	Moins d’infrastructure pour un usage isolé
Calcul exact ou donnée transactionnelle	API, SQL ou outil	Résultat déterministe et actualisé
Question complexe sur sources et systèmes	RAG plus outils, éventuellement agent	Recherche documentaire et action sont distinctes

Le fine-tuning n’est pas une base documentaire fiable : il est difficile d’attribuer une réponse à une version précise, de retirer un fait isolé ou de garantir sa restitution. À l’inverse, le RAG ne suffit pas toujours à apprendre un format complexe. Commencez par le mécanisme le plus simple qui répond au besoin, puis combinez seulement après avoir mesuré la lacune.

Le modèle reste un choix d’architecture, pas une religion. Notre comparatif ChatGPT, Claude, Gemini et Mistral fournit une méthode pour évaluer fonctions, données, connecteurs et coût, mais une application RAG doit aussi pouvoir changer de modèle sans reconstruire toute sa couche documentaire.

Cinq cas d’usage concrets

Support client

Le système retrouve les procédures correspondant au produit, au pays et à la version du contrat. Il propose une réponse citée au conseiller, qui la valide. Les métriques utiles sont la résolution correcte, la conformité aux procédures, le temps gagné et le taux d’escalade, pas seulement la satisfaction stylistique.

Assistant juridique ou conformité

Le RAG recherche les clauses, textes et politiques applicables à une date donnée, puis présente les passages sans se substituer au juriste. La version, la juridiction et la date de validité doivent filtrer la recherche. Toute synthèse importante exige une vérification humaine.

Connaissance interne

Les collaborateurs interrogent procédures, décisions et documentation technique selon leurs droits existants. Le projet échoue si le wiki est obsolète. Un responsable doit donc être désigné pour chaque source, avec une date de revue, un statut et un mécanisme de signalement.

Maintenance industrielle

À partir d’un modèle d’équipement, d’un code erreur et d’un historique autorisé, le système retrouve les pages du manuel et les interventions similaires. Il peut guider le diagnostic, mais les consignes de sécurité et les seuils critiques doivent rester explicites, validés et prioritaires.

Veille et recherche

Un corpus daté d’articles, brevets ou publications permet de comparer des sources et de suivre une évolution. Le système doit distinguer date de publication, date de l’événement et date d’ingestion. Il ne doit pas présenter un résumé comme un consensus.

Tutoriel conceptuel : construire un premier RAG en dix étapes

Ce parcours volontairement neutre peut être mis en œuvre avec des composants locaux, open source, cloud ou managés. L’objectif du premier pilote est de prouver la qualité et la sécurité, pas de couvrir toute l’entreprise.

Cadrer la décision. Définissez les utilisateurs, questions, sources, actions autorisées et cas où une validation humaine reste obligatoire.
Créer une vérité terrain. Réunissez des questions réelles, la réponse attendue, les passages probants et les cas sans réponse.
Sélectionner un corpus maîtrisé. Commencez avec une source utile, propre, versionnée et dotée d’un propriétaire éditorial.
Définir le contrat documentaire. Pour chaque document et chunk, exigez identifiant, provenance, version, langue, dates, droits et empreinte.
Comparer les découpages. Testez structure, longueur et chevauchement sur la vérité terrain, sans choisir une taille par habitude.
Établir une référence de recherche. Mesurez lexical, dense et hybride, puis ajoutez un reranker seulement si le gain justifie sa latence.
Construire le contexte. Dédupliquez, respectez un budget de tokens, conservez les identifiants de citation et séparez données et instructions.
Contraindre la réponse. Demandez une synthèse fidèle, des citations par affirmation et une abstention utile lorsque les preuves manquent.
Tester les échecs. Vérifiez permissions, documents empoisonnés, contradictions, suppression, panne d’un composant, requêtes vagues et changements de modèle.
Piloter puis surveiller. Déployez auprès d’un groupe limité, analysez les retours et réévaluez après chaque modification de source ou composant.

Versionnez ensemble le corpus de test, les paramètres de recherche, le modèle d’embedding, l’index, le prompt et le générateur. Sinon, une amélioration apparente restera impossible à reproduire. Pour approfondir le rôle des consignes, consultez le guide complet du prompt engineering.

Sept erreurs qui fragilisent un RAG

Indexer tout le stockage partagé sans propriétaire, tri ni finalité.
Mesurer uniquement la réponse finale et ignorer le retriever.
Utiliser la similarité vectorielle seule pour les codes et références exactes.
Appliquer les permissions après la récupération.
Confondre citation existante et affirmation réellement soutenue.
Mettre en cache sans tenant, version ni durée de validité.
Changer modèle ou chunking sans test de non-régression.

Checklist avant mise en production

Cas d’usage, responsables et limites documentés.
Sources autorisées, datées, versionnées et révocables.
Droits propagés à chaque chunk et testés négativement.
Jeu d’évaluation représentatif et critères bloquants définis.
Recherche dense, lexicale et hybride comparées.
Citations ouvrables jusqu’au passage source.
Abstention, contradictions et dates testées.
Injection, empoisonnement et fuite inter-tenant testés.
Suppression, sauvegarde, restauration et réindexation exercées.
Coût, latence, dérive et incidents surveillés.

FAQ sur le RAG

1. Le RAG supprime-t-il les hallucinations ?

Non. Il apporte des preuves potentielles, mais la récupération peut échouer et le modèle peut encore déformer ou dépasser les sources.

2. Faut-il obligatoirement une base vectorielle ?

Non. Une recherche lexicale ou structurée peut suffire. La base vectorielle devient utile lorsque la proximité sémantique améliore vos requêtes réelles.

3. Quelle taille de chunk choisir ?

Aucune taille universelle n’existe. Comparez plusieurs découpages sur un jeu de questions et préservez les unités logiques du document.

4. Combien de passages faut-il récupérer ?

Le plus petit nombre atteignant votre objectif de rappel. Mesurez plusieurs valeurs de k, puis retirez les doublons et reclassez si nécessaire.

5. Les embeddings contiennent-ils des données personnelles ?

Ils peuvent rester liés à des contenus ou individus. Ne les considérez pas anonymes sans analyse démontrée et protégez-les selon le risque.

6. Peut-on construire un RAG sans envoyer les documents à un tiers ?

Oui, avec des composants hébergés dans votre environnement. Il faut alors assumer leur sécurité, leur exploitation et leurs mises à jour. Notre guide de l’IA locale en 2026 détaille le matériel, les moteurs et les contrôles à prévoir.

7. Quand ajouter un reranker ?

Lorsque le premier étage retrouve la preuve mais la classe mal. Validez que le gain de précision compense coût et latence.

8. Comment maintenir les données à jour ?

Détectez créations, modifications et suppressions, utilisez des identifiants stables, réindexez les dérivés concernés et mesurez le délai de fraîcheur.

9. Le RAG est-il adapté aux chiffres en temps réel ?

Pas seul. Interrogez la base ou l’API source avec une logique contrôlée, puis utilisez le modèle uniquement pour expliquer le résultat.

10. Comment savoir si le projet crée de la valeur ?

Reliez qualité technique et indicateur métier : temps économisé, résolution correcte, erreurs évitées, adoption utile et coût complet par tâche.

Sources primaires et documentation officielle

Conclusion

Un RAG fiable commence par une connaissance gouvernée et une recherche mesurée, pas par le choix d’un chatbot. Faites du passage source l’unité de preuve, de l’autorisation un filtre préalable et de l’abstention une fonction normale. Avec ce socle, vous pourrez changer de modèle, faire évoluer l’index et étendre les usages sans perdre la traçabilité essentielle à la confiance.

Si vous débutez, replacez cette architecture dans notre guide complet de l’intelligence artificielle générative. Puis construisez un pilote étroit, testable et réversible avant toute généralisation.