RAG documents internes : architecture, coûts, pièges 2026

"On a 10 ans de comptes rendus client, mais personne ne sait retrouver l'information." "Mon assistante passe 30 % de son temps à chercher dans d'anciens dossiers." "Chaque consultant réinvente la roue à chaque projet." Ces verbatim reviennent systématiquement dans les PME et ETI que nous accompagnons chez Tensoria. Le problème n'est pas le manque d'information — c'est l'incapacité à la retrouver.

Un système RAG sur documents internes résout précisément ce problème : il connecte un LLM à l'ensemble de votre corpus documentaire et permet de l'interroger en langage naturel, avec citation des sources. Cet article couvre l'architecture complète, les choix techniques qui comptent (chunking, embeddings, retriever, reranker), les métriques de production, les coûts réels du POC au TCO annuel, et les pièges qui font échouer les projets en production.

Il est écrit pour un DSI ou un dirigeant qui veut comprendre ce qu'il achète — pas pour vendre de l'enthousiasme sur l'IA.

Ce qu'est (vraiment) un RAG sur documents internes

Un RAG (Retrieval-Augmented Generation) sur documents internes est un système qui indexe l'ensemble de vos fichiers — PDF, Word, présentations, wikis, notes Confluence, emails exportés — les encode en vecteurs sémantiques, puis, à chaque question d'un utilisateur, retrouve les passages les plus pertinents avant de générer une réponse sourcée.

La réponse inclut systématiquement les références documentaires : titre du fichier, numéro de page, date de création. L'utilisateur sait d'où vient l'information. Si aucun passage pertinent n'est trouvé, le système répond "je ne sais pas" plutôt que d'inventer.

Ce n'est pas un chatbot avec des réponses scriptées. Ce n'est pas une simple recherche plein texte. C'est un moteur de compréhension sémantique sur votre corpus documentaire propriétaire, couplé à un modèle de génération de langage.

Les problèmes concrets que ça résout

Avant de parler architecture, il faut être précis sur ce que le RAG règle et ce qu'il ne règle pas. Les cas d'usage où le ROI est direct :

• Capitalisation sur les projets passés. Un consultant qui démarre une nouvelle mission peut interroger les anciens livrables similaires sans parcourir des arborescences SharePoint à 6 niveaux de profondeur.
• Réduction des questions internes répétitives. Les réponses aux procédures, aux politiques RH, aux conditions de garantie produit sont dans les documents. Le RAG les rend accessibles sans solliciter un expert à chaque fois.
• Mémoire institutionnelle. Dans une ESN avec un turnover de 15 à 20 % par an, chaque départ emporte de la connaissance implicite. Le RAG indexe ce qui est écrit et le rend transmissible.
• Gain de temps mesurable. Une assistante qui passe 30 % de son temps à chercher représente 125 heures par an. À 40 euros de coût salarial chargé, c'est 5 000 euros par collaborateur et par an d'inaction.

Ce que le RAG ne résout pas : les informations qui ne sont pas dans les documents, le manque de gouvernance documentaire (documents obsolètes non archivés), et les données structurées qui vivent en base SQL (là, une requête SQL ou un outil BI répond mieux).

Pour les secteurs où ce cas d'usage est particulièrement structurant, voir notre article sur les 3 cas d'usage RAG qui génèrent le plus de ROI en entreprise.

Architecture type : pipeline complet

Voici le pipeline complet d'un RAG sur documents internes, de l'ingestion à l'interface utilisateur. Chaque étape a des choix techniques distincts.

Étape 1 : ingestion et parsing

L'ingestion consiste à extraire le texte brut depuis les formats sources. Pour les PDF natifs (texte numérique), les outils comme pdfplumber ou pymupdf suffisent. Pour les PDF scannés ou les images, un OCR layout-aware est indispensable en amont : AWS Textract, Azure Document Intelligence, ou tesseract pour les cas simples.

Les tableaux XLSX méritent un traitement spécifique : extraction cellule par cellule avec les entêtes de colonnes associées à chaque ligne, plutôt qu'une sérialisation brute du tableau en texte continu.

Étape 2 : chunking et indexation

Le texte extrait est découpé en chunks, encodé en vecteurs d'embedding, puis stocké dans une base vectorielle avec ses métadonnées (chemin du fichier, date, département, auteur, niveau de confidentialité). C'est l'étape qui conditionne le plus la qualité finale du retrieval.

Étape 3 : retrieval et reranking

À chaque requête, le système effectue une recherche hybride (BM25 + recherche dense), récupère les 20 meilleurs candidats, les réordonne avec un reranker, et sélectionne les top-5 pour le contexte du LLM.

Étape 4 : génération

Le LLM reçoit le contexte (les 5 passages) et la question. Le prompt inclut une instruction explicite de citation des sources entre crochets. La température est fixée à 0,2 maximum pour limiter les inventions.

Stack 2026 : tradeoffs concrets

Il n'existe pas de stack universelle. Voici les trois configurations que nous déployons le plus fréquemment, avec leurs conditions d'usage réelles.

Stack 1 : Python / LangChain + Qdrant + GPT-4o

La configuration de référence pour la majorité des projets PME/ETI. LangChain offre une maturité production élevée et une documentation abondante. Qdrant self-hosted permet de garder les données sur site (OVH, Scaleway, ou infrastructure on-premise). GPT-4o via l'API OpenAI Enterprise garantit que vos données ne servent pas à l'entraînement.

Adapté pour : corpus jusqu'à 500 000 documents, équipes qui veulent du contrôle sans ops lourds, données modérément sensibles.

Stack 2 : LlamaIndex + Weaviate Cloud + Claude Sonnet

LlamaIndex excelle sur les pipelines RAG complexes : multi-step retrieval, agent RAG, gestion de sources hétérogènes. Weaviate Cloud réduit la charge opérationnelle (pas de VPS à maintenir). Claude 3.7 Sonnet est plus précis sur les textes longs et ambigus, et gère mieux les documents techniques denses.

Adapté pour : projets avec plusieurs types de sources, besoin de qualité supérieure sur corpus complexe, équipe qui préfère réduire les opérations infrastructure.

Stack 3 : Haystack 2.x + Elasticsearch + Mistral (on-premise)

Le choix souverain et RGPD-maximaliste. Tout reste sur votre infrastructure : aucune donnée ne quitte votre périmètre. Elasticsearch apporte un BM25 éprouvé et des capacités de filtrage avancées. Mistral (modèle ouvert via Ollama ou vLLM) réduit le coût par requête à quasi zéro après l'investissement infrastructure.

Adapté pour : données RH, données médicales, secrets industriels, secteurs réglementés. Compromis à accepter : qualité de génération inférieure de 10 à 15 % aux modèles frontier comme GPT-4o ou Claude.

Pour une analyse approfondie de l'approche souveraine, voir notre article sur l'architecture RAG souveraine avec Mistral.

Le choix entre cloud et on-premise a également un impact direct sur le budget total. Notre article sur le coût d'un projet RAG détaille les scénarios TCO pour les deux approches.

Chunking et embeddings : les décisions qui font la qualité

Le chunking est l'étape la plus sous-estimée d'un projet RAG. Un mauvais découpage dégrade irrémédiablement la précision du retrieval, quelle que soit la qualité du LLM en aval.

Stratégie de chunking recommandée

Chunking sémantique plutôt que fixe. Un chunk de 512 tokens fixe coupe une clause contractuelle en plein milieu ou regroupe trois sections de procédure sans lien logique. Préférez le découpage par paragraphe ou section logique, avec détection des titres et sous-titres comme délimiteurs naturels.

Overlap de 15 à 20 %. Un overlap de 75 à 100 tokens entre chunks consécutifs évite de perdre le contexte de jonction. Sans overlap, une question qui porte sur une idée qui s'étend sur deux paragraphes ne trouve rien.

Traitement spécifique par type de document :

• Tableaux Excel : chunkez par ligne de données avec les entêtes de colonnes répétées dans chaque chunk. Ne sérialisez pas le tableau en texte continu : le LLM perd la structure.
• PDF scannés : OCR layout-aware en premier (AWS Textract ou Azure Document Intelligence), puis chunking sémantique. Un OCR basique sans détection de layout casse les colonnes et les tableaux.
• Présentations PPTX : chunkez slide par slide, avec le titre de la slide et le nom de la présentation en métadonnée.
• Documents longs (rapports d'étude, normes) : ajoutez un chunk de résumé par section en plus des chunks détaillés. Cela améliore le recall sur les questions de synthèse.

Choix du modèle d'embeddings

Le modèle d'embeddings détermine la qualité de la recherche sémantique. En 2026, les options pertinentes pour un corpus d'entreprise :

• text-embedding-3-large (OpenAI, 3072 dims) : le meilleur équilibre qualité/facilité de déploiement pour un corpus multilingue FR/EN. Coût : 0,13 dollar pour 1 million de tokens d'indexation.
• multilingual-e5-large (Microsoft, open source) : très pertinent pour un corpus 100 % français, déployable localement sans coût API. Légèrement inférieur à text-embedding-3-large sur les requêtes courtes.
• camembert-large fine-tuné sur votre domaine : le meilleur choix si votre corpus est entièrement francophone et contient un jargon métier dense (droit, médecine, ingénierie). Nécessite un fine-tuning, donc un investissement supplémentaire de 3 000 à 8 000 euros.
• text-embedding-ada-002 (OpenAI) : à éviter en 2026. Obsolète, remplacé par text-embedding-3-large sur tous les benchmarks.

Retriever, reranker et prompt grounding

Retrieval hybride : BM25 + dense

Le retrieval dense seul (recherche vectorielle) rate les requêtes précises : "numéro de devis D-2024-087", "article 12.3 du contrat Dupont", "norme NF EN 12845". Ces requêtes nécessitent un exact match que BM25 gère nativement.

Le retrieval hybride combine les deux : BM25 pour les correspondances exactes sur termes métier, acronymes et références, recherche dense pour la compréhension sémantique et les synonymes. La fusion des deux listes de résultats se fait via Reciprocal Rank Fusion (RRF), un algorithme sans paramètre à calibrer qui se comporte bien dans la majorité des cas.

Reranker : le filtre qui compte

Le retrieval hybride renvoie 20 candidats. Le reranker les réordonne pour sélectionner les top-5 qui iront dans le contexte du LLM. C'est un cross-encoder : il évalue chaque paire (question, chunk) ensemble, contrairement à l'embedding qui encode question et chunks séparément.

Modèles recommandés :

• ms-marco-MiniLM-L-6-v2 : léger (22M paramètres), latence de 50 à 80 ms, gain de précision de +15 à +20 % sur Recall@5.
• bge-reranker-large : plus précis (+25 % sur corpus FR), latence de 150 à 200 ms. À préférer si la latence n'est pas un critère critique.

Le coût du reranker est négligeable : déployé sur CPU, il ajoute moins de 0,3 euro pour 1 000 requêtes.

Structure du prompt et grounding

La structure du prompt conditionne directement le taux d'hallucination :

1. Contexte d'abord, question ensuite. Placer le contexte en premier ancre la génération sur les passages retrouvés.
2. Instruction de citation explicite. "Cite ta source entre crochets [Nom du document, p.X]" réduit les inventions et permet à l'utilisateur de vérifier.
3. Instruction de refus explicite. "Si la réponse n'est pas dans les documents fournis, réponds 'Je n'ai pas trouvé cette information dans la documentation disponible'." Sans cette instruction, le LLM hallucine plutôt que d'admettre l'absence d'information.
4. Température 0,1 à 0,2 maximum. Au-delà, le modèle "créatif" s'éloigne des passages sources.

Pour aller plus loin sur l'optimisation d'un système RAG en production, voir notre article sur l'optimisation d'un RAG de la démo à la production.

Métriques de production à surveiller

Sans golden set et sans monitoring, un projet RAG est une boîte noire. Le client dira "ça marche moins bien qu'avant" sans pouvoir le quantifier, et l'équipe technique ne pourra pas distinguer une amélioration d'une régression lors des itérations.

La première chose à faire avant de coder : constituer un golden set de 50 à 100 paires question/réponse attendue avec le client. C'est l'investissement de cadrage qui rend tout le reste mesurable.

Pour le monitoring en production, Langfuse (open source, self-hostable) ou Langsmith permettent de tracer chaque requête, les chunks retrouvés, les scores de reranking et les coûts API. Ces outils sont indispensables pour déboguer les cas où le système répond mal.

Le RAG agentique ajoute une couche de raisonnement multi-étapes sur ce pipeline de base, avec des métriques supplémentaires à surveiller.

Coûts réels : POC, MVP, TCO annuel

Voici les fourchettes que nous observons sur les projets que nous accompagnons à Toulouse et dans toute la France. Ces chiffres incluent le développement, l'infrastructure et les coûts d'API — pas uniquement la partie "code".

POC : valider sur vos vrais documents (8 000 à 15 000 euros)

Durée : 6 à 8 semaines. Périmètre : un type de document, un département, un cas d'usage précis. Livrable : démo interactive, évaluation qualitative sur golden set, recommandations d'architecture pour le MVP.

Ce budget couvre 10 à 15 jours/homme d'un ingénieur RAG (600 à 1 200 euros HT/jour) et l'infrastructure minimale de test. C'est la seule façon de savoir si vos documents sont exploitables tels quels ou s'ils nécessitent un nettoyage préalable.

MVP en production (25 000 à 50 000 euros)

Durée : 3 mois. Périmètre : ingestion complète du corpus, intégration SI (SSO, droits d'accès), interface utilisateur aboutie, monitoring, documentation de maintenance. Inclut une conduite du changement légère (formation des premiers utilisateurs).

La fourchette est large car tout dépend de la qualité de vos données. Un MVP sur 500 PDF bien structurés n'a rien à voir avec un MVP sur 10 000 fichiers hétérogènes incluant des scans à 150 DPI et des tableaux Excel imbriqués.

TCO annuel à scale (18 000 à 40 000 euros par an)

Composition du TCO annuel :

• Coûts API LLM : pour 50 utilisateurs à 5 questions/jour avec GPT-4o, comptez 150 à 400 euros par mois selon la longueur des réponses.
• Hébergement base vectorielle : Qdrant self-hosted sur VPS 8 cores / 32 Go RAM : 80 à 200 euros par mois. Qdrant Cloud pour les mêmes volumes : 150 à 400 euros par mois.
• Serveur applicatif : 50 à 200 euros par mois selon le volume de requêtes simultanées.
• Maintenance et évolutions : 15 à 20 % du budget de développement initial par an. Sur un MVP à 35 000 euros, c'est 5 000 à 7 000 euros par an de maintenance.

Pour une décomposition détaillée des postes de coût et le point de bascule cloud vs souverain, voir notre guide complet sur le budget d'un projet RAG en entreprise.

Délais réels et ce qui rallonge

Minimum réaliste : 10 semaines de la commande à la mise en production. Médiane sur nos projets : 16 semaines.

Ce qui rallonge systématiquement :

• Qualité des données (+2 à +4 semaines) : documents scannés non OCRisés, arborescences chaotiques avec plusieurs versions du même fichier, documents en langues mixtes sans séparation claire. Sur un projet récent, le parsing de PDFs techniques avec tableaux imbriqués a représenté 40 % du temps de développement total.
• Droits d'accès et sécurité (+2 à +3 semaines) : l'intégration SSO (Active Directory, Okta), la définition des politiques de permissions par rôle, et les tests de non-régression sécurité prennent plus de temps que prévu dans 80 % des projets.
• Intégration SharePoint / Teams / Confluence (+2 semaines) : les APIs de ces plateformes sont bien documentées, mais la gestion des permissions héritées, des bibliothèques imbriquées et des métadonnées personnalisées ajoute de la complexité.
• Conduite du changement (facteur critique) : si les utilisateurs ne changent pas leurs habitudes de recherche, le projet est abandonné en 3 mois malgré la qualité technique. Former 20 personnes prend du temps. Prévoir au minimum 2 sessions d'onboarding et un référent interne dédié.

Pièges fréquents en production

Voici les cinq erreurs que nous voyons le plus souvent sur les projets RAG internes. Chacune est évitable si elle est anticipée.

Piège 1 : ingérer sans trier

Mettre tous les documents sans discrimination fait baisser la précision. Les anciens documents obsolètes génèrent des contradictions : le RAG cite une procédure de 2019 contredite par celle de 2024. Prévoir une phase de déduplication et de datation avant ingestion. Pour chaque type de document, définir une politique claire : ne garder que la dernière version ? Archiver les documents antérieurs à N ans ?

Piège 2 : ignorer les droits d'accès

Le RAG répond avec tous les documents indexés. Si un commercial peut interroger des données RH ou des marges confidentielles, c'est un incident de sécurité, pas un bug d'implémentation. Les filtres de metadata par rôle doivent être pensés dès la conception de l'index, pas ajoutés après coup. Ajouter des permissions a posteriori nécessite souvent une ré-indexation complète du corpus.

Piège 3 : pas d'évaluation quantitative

Sans golden set constitué avec le client avant de coder, il est impossible de mesurer les améliorations. Le client dira "ça répond moins bien" sans pouvoir le prouver. L'équipe technique ne sait pas si une modification du prompt ou du chunking a amélioré ou dégradé le système. 50 questions avec les réponses attendues, c'est le minimum pour piloter le développement.

Piège 4 : chunking fixe sur des documents hétérogènes

Un chunk de 512 tokens coupe un contrat au milieu d'une clause ou inclut trois sections de procédure sans lien. Le retrieval retrouve des passages incohérents, le LLM génère des réponses confuses. Le chunking doit être adapté à la structure de chaque type de document, pas paramétré une fois pour toutes.

Piège 5 : confondre recall et précision

Un système qui renvoie toujours beaucoup de contexte a un bon recall mais des réponses verbeuses et peu fiables. Un système trop sélectif rate des informations pertinentes. Le reranker + la sélection top-k est le curseur entre les deux. Calibrer ce curseur sur votre golden set, pas sur vos intuitions.

Pour une liste plus exhaustive des causes d'échec, voir notre article sur les erreurs qui font échouer les projets RAG en entreprise.

Quand ne pas faire de RAG interne

Un RAG n'est pas la solution à tous les problèmes documentaires. Il y a des situations où il ne vaut pas l'investissement :

• Corpus inférieur à 200 documents bien organisés. Un wiki bien structuré ou un moteur de recherche full-text (Meilisearch, Typesense) suffit amplement et coûte 10 fois moins cher.
• Données principalement structurées en base SQL. Les questions sur des données tabulaires (stocks, commandes, chiffre d'affaires) sont mieux résolues par du SQL ou un outil BI que par du RAG.
• Gouvernance documentaire inexistante. Si vous ne savez pas quels documents sont à jour, si personne n'est responsable de la documentation, indexer le chaos produit un RAG chaotique. Commencer par mettre de l'ordre dans les documents avant de les indexer.
• Restaurant ou petite structure sans corpus documentaire. Quelques fiches recettes ou procédures ne justifient pas un projet RAG. Le ROI est insuffisant.

Dans le doute, un audit IA de cadrage permet de confirmer en 2 à 3 jours si le cas d'usage justifie un RAG ou si une solution plus simple répond au besoin.

Questions fréquentes

Pour aller plus loin

• RAG en entreprise : tout comprendre sur la technologie — les fondamentaux du RAG, pour ceux qui veulent comprendre avant de décider.
• Coût d'un projet RAG : budget et TCO complet — décomposition poste par poste et comparatif cloud vs souverain.
• Optimiser un RAG de la démo à la production — les leviers techniques pour améliorer recall, latence et coût.
• Les erreurs qui font échouer les projets RAG — retour d'expérience sur les patterns d'échec récurrents.
• RAG souverain avec Mistral : architecture 100 % française — pour les organisations avec des contraintes de souveraineté fortes.
• RAG agentique : quand le retrieval devient multi-étapes — l'étape suivante une fois le RAG de base en production.
• Combien coûte un assistant IA interne — comparatif SaaS clé en main vs sur mesure.
• Service Tensoria : assistant IA interne RAG — notre offre d'accompagnement de l'audit au déploiement.