RAG en production : le guide technique pour l'entreprise

80 % des POC RAG ne passent jamais en production. Le fossé entre "ça marche dans un notebook" et "ça marche à l'échelle avec de vrais utilisateurs" est considérable : documents qui changent, permissions à respecter, hallucinations à détecter, latence à maîtriser, évaluation à industrialiser.

Ce guide couvre ce qu'il faut réellement pour déployer un système RAG en production dans un contexte d'entreprise. Pas de prompt magique ni de démo sur trois PDF — mais une architecture complète, les erreurs à éviter, et les patterns avancés qui font la différence entre un prototype et un produit.

Qu'est-ce que le RAG ?

Le Retrieval-Augmented Generation (RAG) est un pattern d'architecture qui consiste à alimenter un LLM avec du contexte pertinent avant de lui demander de générer une réponse.

Le problème de base est simple : les LLM ne connaissent pas vos données internes. Ils ont été entraînés sur du texte public, pas sur votre documentation Confluence, vos procédures SharePoint, ou vos spécifications techniques internes. Le RAG comble ce fossé.

Le flux de base :

1. Query — l'utilisateur pose une question
2. Retrieve — le système recherche les documents pertinents dans une base vectorielle
3. Augment — les documents récupérés sont injectés dans le prompt
4. Generate — le LLM génère une réponse fondée sur ce contexte

Simple en théorie. En pratique, chaque étape cache des décisions d'architecture qui déterminent si votre système sera fiable ou inutilisable.

Pour aller plus loin sur notre approche, consultez notre expertise RAG.

Architecture RAG production-grade

Un RAG en production ne se résume pas à un script qui indexe des PDF et appelle l'API d'OpenAI. C'est un système distribué avec plusieurs composants critiques.

Pipeline d'ingestion documentaire

Tout commence par la capacité à extraire du texte structuré depuis vos sources : PDF, Confluence, SharePoint, Notion, Google Drive, bases de tickets, emails. Chaque source a ses spécificités — un PDF scanné nécessite de l'OCR, un document Confluence contient des macros et des tableaux imbriqués, une page Notion mélange texte, bases de données et médias.

En production, ce pipeline doit être incrémental (ne pas tout réindexer à chaque modification), résilient (gérer les erreurs de parsing sans bloquer l'ensemble), et observable (savoir quel document a été indexé, quand, avec quel résultat).

Stratégies de chunking

Le chunking — la façon dont vous découpez vos documents en fragments — est l'une des décisions les plus impactantes sur la qualité de votre RAG.

• Fixed-size : découpage par nombre de tokens avec overlap. Simple, prévisible, mais ignore la structure du document.
• Semantic : découpage basé sur les ruptures de sens (changement de sujet, de section). Plus intelligent, mais plus coûteux à implémenter.
• Hierarchical : chunks imbriqués (document → section → paragraphe) avec navigation parent-enfant. Permet de remonter le contexte quand un chunk seul ne suffit pas.
• Parent-child : on indexe des petits chunks pour la recherche, mais on remonte le chunk parent (plus large) au moment de la génération. C'est souvent le meilleur compromis entre précision de la recherche et richesse du contexte.

La taille optimale dépend de votre cas d'usage. Pour de la documentation technique, des chunks de 512 à 1024 tokens avec un parent-child sur les sections fonctionnent bien. Pour du juridique ou du réglementaire, des chunks plus petits (256-512) avec un overlap important réduisent le risque de couper une clause en deux.

Modèles d'embedding

Le modèle d'embedding transforme vos chunks de texte en vecteurs numériques. C'est la brique qui détermine la qualité de votre recherche sémantique.

• OpenAI text-embedding-3-large : excellent rapport qualité/simplicité, 3072 dimensions, supporte le raccourcissement de dimensions.
• Cohere Embed v3 : très performant en multilingue, supporte nativement les types de recherche (query vs document).
• Open-source (BGE-M3, E5-Mistral) : auto-hébergeables, pas de dépendance API externe, performances comparables sur les benchmarks MTEB.

Le choix dépend de vos contraintes : si la donnée ne doit pas quitter votre infrastructure, un modèle open-source sur GPU est la seule option. Sinon, les API managées sont plus simples à opérer.

Base vectorielle

La base vectorielle stocke vos embeddings et exécute la recherche par similarité.

• pgvector : extension PostgreSQL. Si vous avez déjà PostgreSQL en production, c'est le choix le plus pragmatique — pas de nouvelle infrastructure à gérer. Limité en performance au-delà de quelques millions de vecteurs.
• Qdrant : base vectorielle dédiée, excellente en performance et en filtrage par métadonnées. Auto-hébergeable. Notre recommandation pour les projets qui ont besoin de scalabilité.
• Pinecone : entièrement managé, zéro ops. Pertinent si votre équipe ne veut pas gérer d'infrastructure.
• Weaviate : hybride (vectoriel + BM25 natif), bon choix si vous voulez un seul système pour la recherche hybride.

Retrieval : au-delà de la similarité cosinus

La recherche par similarité vectorielle seule ne suffit pas. En production, vous avez besoin de :

• Recherche hybride : combiner BM25 (recherche lexicale classique) avec la recherche vectorielle. BM25 excelle pour les termes exacts (noms de produits, codes, acronymes) que la recherche sémantique peut manquer.
• Re-ranking : après avoir récupéré les top-50 résultats par recherche hybride, un modèle de re-ranking (Cohere Rerank, cross-encoder) reclasse les résultats par pertinence réelle. La différence de qualité est souvent spectaculaire — c'est l'optimisation qui a le meilleur ratio effort/impact.
• Filtrage par métadonnées : restreindre la recherche par date, type de document, département, niveau de confidentialité. Indispensable en entreprise.

Génération et prompt design

Le LLM qui génère la réponse finale doit être guidé correctement :

• Claude (Anthropic) : fenêtre de contexte de 200K tokens, excellent pour les RAG avec beaucoup de contexte. Notre choix par défaut pour les projets de documentation interne.
• GPT-4 : polyvalent, écosystème mature.
• Mistral : option européenne, auto-hébergeable, bon rapport performance/coût.

Le prompt pour un RAG production-grade n'est pas un simple "réponds à la question en utilisant le contexte". Il doit inclure des instructions pour citer les sources, signaler quand le contexte est insuffisant, et structurer la réponse de façon utile.

Citation et grounding

En entreprise, une réponse sans source n'a aucune valeur. Votre système doit :

• Attribuer chaque affirmation à un chunk source spécifique
• Fournir un score de confiance (le contexte récupéré répond-il réellement à la question ?)
• Permettre à l'utilisateur de vérifier la source en un clic

C'est la différence entre un chatbot gadget et un outil de travail adopté par les équipes.

Les 7 erreurs qui tuent un RAG en production

1. Mauvais chunking

Des chunks trop gros injectent du bruit dans le contexte — le LLM se perd dans des informations non pertinentes. Des chunks trop petits perdent le contexte nécessaire à la compréhension. La bonne taille dépend de votre contenu, et il faut la valider empiriquement, pas la deviner.

2. Pas de re-ranking

Le top-k par similarité cosinus n'est pas le top-k par pertinence. Un document peut être sémantiquement proche de la query sans y répondre. Le re-ranking corrige ce problème et améliore typiquement la qualité de 15 à 30 % sur les métriques de retrieval.

3. Ignorer les métadonnées

Un document de 2019 et un document de 2024 sur le même sujet ont la même similarité vectorielle. Sans filtrage par date, votre RAG peut servir des informations obsolètes avec une grande confiance. Les métadonnées (date, auteur, type, département, version) sont des signaux critiques que trop d'implémentations ignorent.

4. Pas d'évaluation systématique

Tester un RAG "au feeling" — poser quelques questions et vérifier si les réponses semblent correctes — ne passe pas à l'échelle. Vous avez besoin de datasets d'évaluation, de métriques automatisées, et de benchmarks reproductibles. Sinon, chaque modification de votre pipeline est un pari aveugle.

5. Hallucinations non détectées

Un RAG mal conçu peut halluciner tout en ayant l'air confiant. Si votre système ne vérifie pas que la réponse générée est effectivement fondée sur le contexte récupéré (grounding verification), vous construisez un système qui ment poliment à vos utilisateurs.

6. Pas de pipeline de mise à jour

Vos documents évoluent. Si votre index n'est pas mis à jour en continu (ou au minimum quotidiennement), votre RAG sert des réponses périmées. En production, l'ingestion doit être incrémentale, automatisée, et monitorée.

7. Ignorer les permissions

C'est le point le plus critique en entreprise. Si l'utilisateur A peut accéder à des documents confidentiels de l'utilisateur B via votre RAG, vous avez un incident de sécurité. Le RAG doit respecter les ACL (Access Control Lists) de vos sources documentaires, ce qui complexifie significativement l'architecture de retrieval.

Évaluer un RAG : les métriques qui comptent

L'évaluation d'un RAG se fait sur deux axes : la qualité du retrieval et la qualité de la génération.

Qualité du retrieval

• Recall@k : parmi les documents pertinents, combien sont dans le top-k récupéré ? C'est la métrique fondamentale — si le bon document n'est pas récupéré, le LLM ne peut pas donner la bonne réponse.
• Precision@k : parmi les k documents récupérés, combien sont pertinents ? Un precision faible signifie que vous injectez du bruit dans le contexte.
• MRR (Mean Reciprocal Rank) : à quel rang se trouve le premier document pertinent en moyenne ? Plus le MRR est élevé, moins vous dépendez d'un k élevé.

Qualité de la génération

• Faithfulness (fidélité) : la réponse est-elle fondée sur le contexte récupéré, ou le LLM invente-t-il des informations ? C'est la métrique anti-hallucination.
• Relevance : la réponse répond-elle réellement à la question posée ?
• Completeness : la réponse couvre-t-elle tous les aspects de la question ?

Outils d'évaluation

• RAGAS : framework open-source d'évaluation RAG. Calcule automatiquement faithfulness, relevance, et context recall. Point de départ solide.
• promptfoo : outil d'évaluation de prompts et de systèmes LLM. Permet de définir des test suites reproductibles.
• Évaluation custom : pour les cas métier spécifiques, rien ne remplace un dataset d'évaluation construit avec vos experts métier, combiné à des métriques adaptées.
• Évaluation humaine : thumbs up/down sur les réponses, feedback qualitatif, boucle d'amélioration continue. Indispensable en complément des métriques automatisées.

RAG avancé : les patterns qui font la différence

Une fois les fondamentaux solides, ces patterns avancés permettent de franchir un palier de qualité.

Query transformation

La question de l'utilisateur est rarement optimale pour la recherche vectorielle.

• HyDE (Hypothetical Document Embeddings) : le LLM génère un document hypothétique qui répondrait à la question, puis on recherche des documents similaires à cette réponse hypothétique. Améliore significativement le recall sur les questions complexes.
• Multi-query : le LLM reformule la question en plusieurs variantes, chaque variante est utilisée pour une recherche séparée, et les résultats sont fusionnés. Couvre plus d'angles sémantiques.
• Step-back prompting : le LLM génère d'abord une question plus générale avant de répondre à la question spécifique. Utile pour les questions qui nécessitent du contexte de fond.

Agentic RAG

Au lieu d'un pipeline fixe query → retrieve → generate, un agent IA décide quand et comment rechercher. Il peut :

• Décomposer une question complexe en sous-questions
• Décider de chercher dans plusieurs sources différentes
• Évaluer si le contexte récupéré est suffisant avant de répondre
• Reformuler et re-chercher si les premiers résultats sont insatisfaisants

C'est l'évolution naturelle du RAG : passer d'un pipeline statique à un système adaptatif.

Multi-index RAG

Différents types de documents appellent différentes stratégies d'indexation. Un index unique pour la documentation technique, les FAQ, les contrats juridiques et les emails ne donnera pas de bons résultats. Le multi-index permet d'adapter le chunking, les embeddings, et la stratégie de recherche à chaque type de contenu, puis de fédérer les résultats.

Graph RAG

Combiner un knowledge graph (entités et relations) avec la recherche vectorielle. Le graph capture les relations structurées (personne → travaille pour → entreprise → utilise → technologie) que la recherche vectorielle seule ne peut pas modéliser. Particulièrement utile pour les bases documentaires avec beaucoup de références croisées.

Corrective RAG (CRAG)

Le système évalue ses propres résultats de recherche. Si le contexte récupéré est jugé insuffisant ou non pertinent, il déclenche automatiquement une stratégie alternative : reformulation de la query, recherche dans un index différent, ou escalade vers un opérateur humain. Ce pattern réduit drastiquement les hallucinations sur les questions difficiles.

Stack technique recommandé

Voici la stack que nous recommandons pour un RAG production-grade en entreprise :

Cette stack est éprouvée, maintenable, et offre un bon équilibre entre flexibilité et simplicité opérationnelle.

Comment Origin 137 déploie du RAG en production

Nous avons déployé des systèmes RAG en production sur Confluence, SharePoint, et des bases documentaires internes pour des entreprises de toutes tailles.

Notre approche suit une méthodologie en 4 phases :

1. Cadrage — audit des sources documentaires, définition des cas d'usage prioritaires, choix de la stack technique
2. MVP — pipeline d'ingestion, indexation, premier RAG fonctionnel sur un périmètre restreint avec évaluation automatisée
3. Industrialisation — gestion des permissions, pipeline de mise à jour continue, re-ranking, monitoring, intégration dans les outils existants
4. Optimisation — patterns avancés (agentic RAG, graph RAG), feedback loops, amélioration continue basée sur les métriques

Chaque phase produit un livrable utilisable. Pas de tunnel de 6 mois avant la première démo.

Découvrez nos projets IA et nos cas d'usage RAG pour des exemples concrets.