RAG (Retrieval-Augmented Generation) : le guide pratique de la mise en production

Un LLM généraliste connaît le web public jusqu’à sa date de coupure. Il ne connaît ni vos procédures internes, ni vos contrats, ni la version du référentiel produit publiée hier. Le RAG, pour Retrieval-Augmented Generation, consiste à chercher les passages pertinents dans vos documents au moment de la question, puis à les fournir au modèle comme contexte.

Formulé ainsi, c’est presque banal. En pratique, la démonstration se construit en deux jours et la mise en production prend deux à quatre mois. L’écart ne vient pas de l’algorithme, il vient de ce qui l’entoure : la qualité des documents en entrée, la mesure de la qualité en sortie, le coût par requête quand mille personnes s’en servent au lieu de trois, et le fait qu’un utilisateur ne doit jamais voir un extrait auquel il n’a pas droit.

Ce guide décrit ce que nous mettons en place quand un RAG doit tenir en production. Il commence par la question qui revient systématiquement en cadrage : ne vaudrait-il pas mieux fine-tuner le modèle ?

Ces trois leviers ne répondent pas à la même question. Le prompt engineering change les instructions. Le RAG change ce que le modèle sait au moment de répondre. Le fine-tuning change son comportement par défaut. Choisir l’un pour faire le travail de l’autre est la cause d’échec la plus fréquente en audit.

Critère	Prompt engineering	RAG	Fine-tuning
Ce que ça change	Les instructions	Les connaissances mobilisées	Le comportement par défaut
Fraîcheur des données	Sans objet	Immédiate	Réentraînement
Traçabilité	Non	Citations vérifiables	Non
Coût par requête	Faible	Élevé (contexte injecté)	Faible
Latence ajoutée	Nulle	Étape de recherche	Nulle
Données nécessaires	Aucune	Vos documents	Milliers d’exemples annotés
Réversibilité	Totale	Bonne	Faible : un actif à maintenir

L’arbre de décision que nous utilisons en cadrage tient en trois questions.

La réponse dépend-elle de documents qui vous appartiennent
et qui changent dans le temps ?
   |
   +-- non --> commencez par le prompt engineering.
   |           Beaucoup de projets s'arrêtent ici, et c'est
   |           une bonne nouvelle pour le budget.
   |
   +-- oui --> RAG.
               |
               +-- le format, le ton ou le vocabulaire metier
               |   restent-ils faux malgre un prompt travaille
               |   et des exemples dans le prompt ?
               |      |
               |      +-- non --> RAG seul.
               |      +-- oui --> RAG + fine-tuning de style
               |                  sur un petit modele.
               |
               +-- la latence interdit-elle toute recherche ?
                      |
                      +-- oui --> cas rare. C'est presque
                                  toujours un probleme de cache
                                  ou de budget de tokens,
                                  pas de modele.

Un point de vigilance pour finir : le fine-tuning n’injecte pas de connaissances fiables, il déplace des probabilités. Un modèle fine-tuné sur votre documentation emploiera votre vocabulaire avec assurance, y compris quand il invente. L’offre de fine-tuning évolue par ailleurs vite selon les fournisseurs : vérifiez ce qui est disponible au moment de votre décision plutôt que de vous fier à un comparatif, y compris celui-ci.

Une chaîne RAG se lit en deux temps : une partie hors ligne qui construit l’index, une partie en ligne qui répond. Les confondre est une erreur de conception classique — elles n’ont ni les mêmes contraintes de latence ni les mêmes exigences de disponibilité.

HORS LIGNE - indexation
  Sources        Extraction      Decoupage       Embedding      Index
  GED, wiki  --> + nettoyage --> + metadata  --> + version --> vectoriel
  SharePoint     + OCR           ACL, date,      du modele      + index
  base SQL                       version                        lexical

EN LIGNE - requete
  Question --> Reformulation --> Recherche hybride --> Reranking --> top-k
                                 vecteur + BM25
                                 filtre ACL obligatoire            |
                                                                   v
  Reponse <-- Verification <-- Generation LLM <-- Prompt + passages
              citations,                          + consigne de citation
              abstention

Chacun de ces blocs est un endroit où la qualité peut se perdre, et où elle peut se mesurer. Sans instrumentation par étage, un RAG qui répond mal est un système opaque dans lequel chacun a un avis et personne n’a de preuve.

Remarque de terrain : dans la grande majorité des mauvaises réponses, le modèle n’est pas en cause — le bon passage n’a jamais été remonté. Le débat sur le choix du LLM arrive loin derrière celui sur la qualité de l’index.

L’ingestion est la partie la moins gratifiante du projet et celle qui détermine le résultat. Un PDF exporté d’un traitement de texte, un PDF scanné et un PDF de tableaux ne s’extraient pas de la même façon : les traiter à l’identique produit un corpus dont une partie est du bruit, et ce bruit remontera dans les réponses.

Les règles que nous appliquons

• Un chunk doit être compréhensible seul. Un extrait commençant par « Dans ce cas, le délai est porté à trente jours » est inutilisable : on ignore de quel cas il s’agit.
• Préfixez chaque chunk de son contexte structurel : titre du document, fil des sections parentes, date de version. Quelques dizaines de tokens, pour un gain de pertinence très supérieur au coût.
• Taille de 400 à 1 000 tokens, avec 10 à 15 % de recouvrement, en respectant la structure du document plutôt qu’en découpant au caractère. Un tableau coupé en deux ne veut plus rien dire.
• Portez les metadata dès l’ingestion : source, identifiant stable, date, version, propriétaire, périmètre de confidentialité, version du modèle d’embedding. Ce que vous n’aurez pas stocké là, vous ne pourrez pas le filtrer plus tard.

Le piège des doublons de version

Dans un espace documentaire d’entreprise, le même document existe souvent en quatre exemplaires : la version validée, le brouillon, la copie d’un autre service et l’export PDF de la précédente. Sans déduplication ni règle de fraîcheur, votre RAG répondra régulièrement avec la version périmée, et avec le même aplomb que pour la bonne. Une règle de préséance explicite — source de vérité par type de document, puis date décroissante — coûte une journée et évite une perte de confiance durable.

Le choix du modèle d’embedding fait couler beaucoup d’encre pour un impact souvent inférieur à celui du découpage. Les familles suivantes donnent toutes des résultats exploitables sur du français professionnel.

Modèle	Dimensions	Mode
OpenAI text-embedding-3-large	3072, réductible à l’appel	API
Cohere Embed (multilingue)	1024 selon variante	API
Voyage (famille voyage-3)	1024 selon variante	API
BGE-M3	1024	Auto-hébergé, ouvert

La vraie contrainte est ailleurs : changer de modèle d’embedding oblige à réindexer l’intégralité du corpus. Sur quelques milliers de documents, c’est une soirée ; sur plusieurs millions de chunks, c’est un projet, avec une fenêtre pendant laquelle deux index coexistent. Stockez la version du modèle dans les metadata dès le premier jour.

Où stocker les vecteurs

Solution	Intérêt principal	Quand la choisir
pgvector	Pas de nouvelle brique à exploiter	Vous avez déjà PostgreSQL. Par défaut.
Qdrant	Filtrage sur metadata performant	Cloisonnement fin, latence serrée
Elasticsearch / OpenSearch	Lexical et vectoriel dans un seul moteur	Vous en exploitez déjà un
Pinecone	Zéro exploitation	Pas d’équipe d’exploitation disponible

Notre recommandation par défaut reste pgvector tant que le corpus se compte en centaines de milliers de chunks : une brique de moins à sauvegarder, à sécuriser et à facturer. La bascule se décide sur des mesures de latence et de rappel, pas sur une intuition de volumétrie. Et quel que soit le moteur, les paramètres d’index approximatif de type HNSW arbitrent entre rappel et latence : réglez-les avec votre jeu de tests.

La recherche purement vectorielle échoue sur ce qu’elle devrait réussir le plus facilement : les références exactes. Un numéro de contrat, une référence produit, un acronyme interne sont mal servis par la similarité sémantique. La recherche hybride n’est donc pas une optimisation avancée, c’est une base.

• Hybride vecteur plus BM25 : les deux recherches en parallèle, puis fusion des classements — une fusion de rangs réciproques suffit. Gain immédiat sur les requêtes contenant des identifiants.
• Reranking : remontez large (30 à 50 passages), puis faites trancher un modèle de reranking de type encodeur croisé pour n’en garder que 4 à 8. C’est le levier au meilleur rapport gain sur effort après le découpage.
• Reformulation de la requête : indispensable en conversation. « Et pour les CDD ? » ne veut rien dire hors contexte ; résolvez les références avant de chercher.
• Filtres sur metadata : périmètre, période, type de document. Un filtre bien posé fait souvent mieux qu’un meilleur modèle d’embedding.
• Abstention explicite : si le meilleur passage reranké reste sous un seuil de pertinence, ne générez pas. Un assistant qui sait se taire est un assistant que l’on garde.

Les approches plus ambitieuses — graphe de connaissances, boucles d’auto-critique — ont un intérêt réel sur des corpus très reliés, mais ajoutent latence, coût et modes de défaillance. Ne les introduisez qu’après avoir mesuré que l’hybride et le reranking plafonnent.

C’est le point qui sépare un prototype d’un système exploitable. Tant que la qualité se juge en essayant trois questions en réunion, toute modification est un pari.

Constituer un jeu de référence

Comptez 50 à 200 questions écrites avec les métiers, pas par l’équipe technique. Chaque entrée contient la question, la réponse attendue et — point souvent oublié — l’identifiant des passages qui devraient être remontés. Incluez des questions faciles, des questions ambiguës, et surtout des questions sans réponse dans le corpus : ces dernières mesurent ce qui fonde la confiance, la capacité à dire qu’on ne sait pas.

Mesurer à deux étages

• Recherche : taux de présence du bon passage dans les k premiers résultats, rang moyen inverse, précision et rappel du contexte. Si cet étage est mauvais, inutile de regarder le suivant.
• Génération : fidélité au contexte, pertinence de la réponse, taux d’abstention sur les questions sans réponse. La bibliothèque ragas implémente ces métriques ; LangSmith ou Braintrust apportent le suivi dans le temps.

Mesurer l’hallucination concrètement

Imposez au modèle de citer l’identifiant du passage à l’appui de chaque affirmation, puis vérifiez deux choses automatiquement : que les identifiants cités existent dans le contexte fourni, et que chaque affirmation est réellement soutenue par le passage cité. La première est un simple contrôle de cohérence et attrape déjà beaucoup. La seconde s’automatise avec un modèle juge — différent de celui qui a généré la réponse, sous peine de mesurer la complaisance d’un modèle envers lui-même.

Faites tourner l’ensemble en intégration continue à chaque changement de prompt, de découpage, de seuil ou de version de modèle, avec des seuils de non-régression bloquants. Sans cela, votre RAG se dégradera par petites touches sans que personne ne puisse dire quand ni pourquoi.

Le coût d’un RAG est presque entièrement déterminé par les tokens d’entrée, donc par une décision d’architecture : combien de passages vous injectez, et de quelle taille.

Contexte injecte = k passages x taille moyenne d'un chunk
Exemple : 6 passages x 700 tokens          = 4 200 tokens
Consigne systeme + historique + question    =   800 tokens
                                            -------------
Entree par requete                          = 5 000 tokens
Sortie moyenne                              =   400 tokens

Cout mensuel = requetes/mois x (entree x tarif_entree
                              + sortie x tarif_sortie)
             + embedding a l'indexation (ponctuel)
             + hebergement de l'index (recurrent)

Renseignez les deux tarifs de votre fournisseur et vous avez votre facture. Ce qui compte est de voir que passer de 6 à 12 passages double la ligne dominante. Beaucoup d’équipes augmentent k pour compenser une mauvaise recherche : elles paient deux fois un problème de découpage.

Les leviers, par ordre d’efficacité

• Baisser k grâce au reranking. Six bons passages battent quinze passages moyens, et coûtent moitié moins.
• Mise en cache du préfixe de prompt. La consigne système est identique à chaque appel ; les principaux fournisseurs facturent moins cher les tokens d’entrée déjà vus.
• Cache sémantique des questions fréquentes. Une part importante du trafic porte sur une poignée de sujets. Attention : segmentez le cache par périmètre de droits, sinon il devient un canal de fuite.
• Routage par difficulté. Un petit modèle pour les reformulations, le grand pour les synthèses.

La latence se pilote au p95, pas à la moyenne

Un utilisateur ne se souvient pas de la médiane, il se souvient de la fois où il a attendu. Posez un budget par étape et instrumentez chacune séparément : recherche, reranking, premier token, génération complète. Le reranking et le nombre de tokens produits sont les deux postes qui dérapent. Enfin, deux mesures rendent le système supportable avant toute optimisation fine : diffuser la réponse en flux et afficher l’étape en cours. L’attente perçue tient autant à l’interface qu’à l’infrastructure.

C’est le sujet qui fait échouer les mises en production en comité de sécurité, et celui qui est traité en dernier. Un RAG est une machine à agréger : il rassemble en une réponse des éléments épars que l’utilisateur n’aurait pas rapprochés seul. Le contrôle d’accès se conçoit, il ne s’ajoute pas.

• Filtrez avant la recherche, jamais après. Remonter vingt passages puis retirer ceux auxquels l’utilisateur n’a pas droit laisse fuir de l’information par la seule observation de ce qui manque. Les droits sont une condition de la requête, pas un post-traitement.
• Dénormalisez les droits dans les metadata du chunk, avec une réconciliation régulière avec l’annuaire. Un droit révoqué doit disparaître de l’index en heures, pas en semaines.
• Isolez les corpus très sensibles dans des index distincts. Une erreur de filtre n’a pas la même conséquence sur un index partagé et sur un index cloisonné.
• Traitez vos traces comme des données sensibles. Les journaux d’un RAG contiennent les questions des utilisateurs et des extraits confidentiels : chiffrement, conservation courte, accès restreint.

Ce que le RGPD implique concrètement

Si votre corpus contient des données personnelles — dossiers RH, tickets de support, contrats nominatifs — trois obligations deviennent des exigences techniques. La minimisation : excluez à l’ingestion ce qui n’a pas à être interrogeable, plutôt que de tout indexer puis filtrer. Le droit à l’effacement : une suppression doit se propager à la source, aux deux index, aux caches et aux traces ; sans identifiant stable posé dès l’ingestion, c’est impossible à garantir. La sous-traitance : le fournisseur du modèle en est un, ce qui suppose un contrat adapté, une localisation de traitement maîtrisée et la garantie que vos données ne servent pas à l’entraînement.

Ajoutez une analyse d’impact si le traitement est à grande échelle. Ces sujets se traitent en cadrage ; repris après la mise en service, ils coûtent une refonte.

Un RAG livré fonctionne. Un RAG livré et laissé seul se dégrade. Voici les défaillances que nous voyons revenir, et le correctif structurel associé.

Symptôme	Cause réelle	Correctif
Réponses correctes mais périmées	Documents supprimés à la source, toujours présents dans l’index	Synchronisation par suppression réelle, pas seulement par ajout
Qualité qui baisse à mesure que le corpus grossit	Le bon passage sort du top-k noyé dans le bruit	Reranking, filtres de périmètre, hygiène du corpus
Régression brutale sans déploiement	Le fournisseur a fait évoluer le modèle derrière un alias	Épingler une version datée, rejouer les tests avant bascule
Utilisateur voyant un document interdit	Droits dénormalisés jamais réconciliés	Réconciliation planifiée et supervisée
Abandon silencieux des utilisateurs	Aucune boucle de retour, la dérive des usages passe inaperçue	Retour explicite dans l’interface, revue mensuelle

Le dénominateur commun : un RAG est un produit, pas un livrable. Il lui faut un responsable, une revue périodique des questions restées sans réponse et un jeu de tests qui vit. Sans cela, la question n’est pas de savoir s’il se dégradera, mais quand quelqu’un s’en apercevra — et ce sera un utilisateur, trop tard.

La trajectoire la plus sûre tient en quatre étapes, sur huit à dix semaines.

1. Cadrer sur un périmètre étroit et un public identifié. Un corpus, une population, une question métier. Un assistant qui répond bien sur les procédures d’un service vaut mieux qu’un assistant qui répond mal sur tout.
2. Écrire le jeu de tests avant le code. Cinquante questions avec leurs réponses et leurs passages attendus. C’est aussi le meilleur révélateur d’une documentation incomplète.
3. Construire la chaîne la plus simple qui tienne : ingestion propre, découpage soigné, recherche hybride, reranking, citations, abstention. Pas d’agent ni de graphe tant que la mesure ne le réclame pas.
4. Mettre en service avec le cadre de production : droits filtrés en amont, budget de tokens, suivi de la latence p95 et du coût par requête, retour utilisateur, évaluation en intégration continue.

Le RAG n’est ni une révolution ni un gadget : c’est une brique d’ingénierie logicielle ordinaire, dont la difficulté est concentrée dans la donnée et dans la mesure.

C’est le travail que nous menons au titre de notre expertise Intelligence Artificielle : sortir les modèles du carnet de notes, avec une évaluation continue et un coût par requête sous contrôle. Prototype qui plafonne, comité de sécurité à convaincre, ou simple doute sur la pertinence du RAG dans votre cas : décrivez-nous la décision qui est devant vous. Quarante-cinq minutes, sans engagement, avec un associé — et si l’IA n’est pas la bonne réponse, nous vous le dirons avant le devis.