RAG en entreprise : développement, coût et mise en production

En 2026, le RAG (Retrieval-Augmented Generation) est devenu l'architecture de référence pour les entreprises qui veulent tirer parti de l'IA sans exposer leurs données à des modèles généralistes. Le principe est simple à énoncer mais exigeant à bien mettre en oeuvre : connecter un grand modèle de langage à votre base documentaire interne, pour qu'il réponde à partir de vos propres sources plutôt qu'à partir de connaissances génériques. En pratique, cela change tout à la pertinence et à la fiabilité des réponses.

Là où ChatGPT vous donnera une réponse plausible sur n'importe quel sujet, un assistant RAG bien conçu (définition du RAG) vous répondra en citant le paragraphe exact de votre procédure interne, la clause précise de votre contrat cadre, ou le dernier échange client enregistré dans votre CRM. C'est cette différence, entre la plausibilité et la précision, qui fait du RAG un outil de travail réel plutôt qu'un gadget de démonstration.

Ce guide s'adresse aux dirigeants de PME et d'ETI, aux DSI et aux responsables métier qui envisagent un projet RAG et veulent comprendre l'architecture avant de signer un bon de commande. Il s'adresse aussi à ceux qui ont déjà lancé un projet et cherchent à corriger le tir. Nous avons rassemblé ici douze ressources que Tensoria a produites sur le sujet, chacune avec un angle précis. La présente page est le fil conducteur qui vous aide à naviguer selon votre situation.

Tensoria est une agence IA basée à Toulouse qui conçoit des assistants IA internes et des solutions IA sur mesure pour les PME et ETI. Nous déployons des assistants IA interne RAG depuis plusieurs années, et nous avons appris à distinguer les projets qui réussissent de ceux qui échouent silencieusement. Ce guide condense ces retours d'expérience, sans théorie superflue.

Définition

Le RAG en entreprise, concrètement

Un RAG en entreprise est un assistant qui cherche d'abord la réponse dans vos propres documents, puis rédige à partir des passages trouvés en affichant ses sources. RAG est l'abréviation de Retrieval-Augmented Generation, que l'on traduit par génération augmentée par la recherche. Le modèle de langage cesse d'être une mémoire : il devient un rédacteur, et la mémoire reste votre base documentaire.

La différence avec un ChatGPT d'entreprise standard tient en une phrase : sans RAG, l'assistant répond avec ce qu'il a appris sur internet ; avec un RAG, il répond avec la version en vigueur de votre procédure, la clause exacte de votre contrat cadre ou la fiche technique du produit que vous fabriquez. Et il indique dans quel document il l'a trouvée, ce qui permet à un collaborateur de vérifier en dix secondes.

C'est aussi ce qui rend le RAG économe : vous n'avez rien à réentraîner. Quand une procédure change, vous remplacez le document, l'index se met à jour, et l'assistant répond avec la nouvelle version dès le lendemain. Aucune des deux autres approches disponibles (le fine-tuning et le grand contexte) ne permet cela aussi simplement.

Le pipeline d'un RAG, étape par étape

Un système RAG enchaîne six étapes, dont quatre se jouent avant la première question posée. C'est important à comprendre : la qualité d'un RAG se décide surtout hors ligne, pendant l'indexation, pas au moment où l'utilisateur tape sa question.

• Collecte. Connexion aux sources réelles : SharePoint, Google Drive, une GED, un ERP, un CRM, un intranet, parfois de simples dossiers réseau ou des boîtes mail partagées.
• Préparation. Extraction du texte, OCR pour les documents scannés, nettoyage des en-têtes et pieds de page répétés, dédoublonnage, et surtout conservation des métadonnées : auteur, date, service, version, niveau de confidentialité.
• Découpage. Les documents sont coupés en passages (chunks) de taille cohérente avec leur structure. Un contrat se découpe par article, un manuel par section, un compte rendu par point d'ordre du jour.
• Vectorisation et stockage. Chaque passage est transformé en vecteur par un modèle d'embeddings, puis stocké dans une base vectorielle. En PME, pgvector (une extension de PostgreSQL) suffit souvent ; Qdrant et Weaviate deviennent intéressants quand le volume et le filtrage se complexifient.
• Recherche. À la question posée, le système récupère les passages les plus proches, filtre selon les droits et les métadonnées, puis réordonne les résultats. Vu de l'utilisateur, c'est un moteur de recherche interne qui répond en rédigeant.
• Génération. Un modèle (Mistral, Claude, GPT selon vos contraintes) rédige la réponse à partir des seuls passages retenus, avec l'instruction explicite de dire qu'il ne sait pas quand l'information ne s'y trouve pas.

Les patterns qui font la différence en entreprise

Un RAG basique (recherche vectorielle seule, découpage en blocs de taille fixe) donne une démonstration convaincante et un outil décevant. Les patterns suivants sont ceux qui séparent un prototype d'un assistant réellement utilisé :

• Recherche hybride. Combiner la recherche sémantique avec une recherche par mots-clés classique (BM25). Indispensable dès qu'il y a des références, des codes article, des numéros de norme ou des noms propres, que la recherche vectorielle seule rate régulièrement.
• Filtrage par métadonnées. Restreindre la recherche à un service, une année, un client, un type de document. C'est aussi le mécanisme qui porte les droits d'accès.
• Reranking. Un second modèle réordonne les vingt passages candidats pour ne garder que les cinq réellement pertinents. C'est souvent le gain de précision le plus rentable d'un projet.
• Reformulation de la question. Les utilisateurs posent des questions courtes et implicites. Réécrire la requête avant la recherche, et gérer les questions de suivi dans une conversation, évite une grande partie des réponses hors sujet.
• Récupération du document parent. On cherche sur de petits passages précis, mais on donne au modèle la section complète autour du passage trouvé, pour qu'il ne réponde pas à partir d'un extrait tronqué.

Pour le détail du choix d'infrastructure, voir notre comparatif des bases de données vectorielles pour le RAG et l'architecture type d'un RAG sur documents internes en PME.

Prérequis données

Ce qui fait vraiment échouer un RAG : les données d'entrée

Dans la grande majorité des projets RAG que nous reprenons, le problème vient des documents indexés, pas du modèle choisi. Un assistant ne peut pas être plus clair que la documentation qu'on lui donne à lire, et il hérite fidèlement de son désordre.

Voici les situations qui dégradent le plus la qualité des réponses, par ordre de fréquence observée :

• Les PDF scannés sans couche texte. Un document scanné est une image. Sans OCR, il est invisible pour le système : l'assistant ne dit pas qu'il ne l'a pas lu, il répond simplement à partir des autres documents. C'est la panne la plus silencieuse et la plus fréquente.
• Les doublons et les versions concurrentes. Quand « procédure achats v3 », « procédure achats v3 finale » et « procédure achats v3 finale OK » coexistent, le système récupère une version au hasard parmi les trois. L'utilisateur reçoit une réponse juste sur la forme et périmée sur le fond.
• Les documents sans contexte. Un tableau Excel de tarifs sans intitulé de colonne explicite, un mémo qui renvoie à « l'annexe jointe », une présentation faite pour être commentée à l'oral : ces contenus se vectorisent mal parce qu'ils ne se suffisent pas à eux-mêmes.
• Les droits d'accès non modélisés. Si le partage de fichiers repose sur des habitudes plutôt que sur des groupes clairs, il n'existe aucune règle à reproduire dans l'assistant. Le chantier des droits précède alors le chantier IA.
• Le savoir non écrit. Beaucoup de réponses attendues ne sont dans aucun document : elles sont dans la tête de deux personnes. Un RAG les rend visibles par leur absence, ce qui est utile, mais il ne les invente pas.
• Les documents périmés jamais archivés. Sans date de fin de validité ni dossier d'archive, le système traite un tarif de 2019 avec le même sérieux que celui de cette année.

Ce que le terrain ajoute : documents difficiles et bugs de chaîne

Un corpus bien organisé en documents Word s'exploite bien. Les difficultés viennent d'ailleurs : les tableaux, graphiques et schémas sont difficiles à exploiter pour l'IA, les documents faits uniquement de schémas ne livrent presque rien, les doublons faussent la recherche, et certains PDF sont délicats à lire. Notre article sur le chatbot interne sur les procédures détaille ce qui s'exploite bien et ce qui pose problème.

Nuance importante : en audit, la cause la plus fréquente n'est pas le modèle mais un bug dans la chaîne de traitement, qui s'ajoute à la qualité des documents. Trois cas réels :

D'où l'ordre de travail : mesurer, corriger ces bugs, puis seulement améliorer la lecture des documents, le découpage et la recherche. Le déroulé complet, étape par étape, est décrit dans améliorer un RAG : l'ordre des étapes sur un cas réel.

Évaluation

Comment savoir si votre RAG répond juste

Pour mesurer la qualité d'un RAG, il faut un jeu de questions de référence avec les réponses attendues, constitué avant la mise en service. Sans lui, aucune discussion sur la qualité n'est possible : chacun cite deux ou trois réponses qui l'ont marqué, et le projet avance à l'impression.

Ce jeu de test n'a rien de sophistiqué. Vingt à cinquante questions suffisent pour démarrer, cinquante à cent donnent un jeu solide : des questions réelles, collectées auprès des futurs utilisateurs, avec pour chacune la bonne réponse et le document qui la contient. Un tableur suffit. Ce qui compte, c'est qu'elles soient représentatives : questions fréquentes, questions pièges, et questions dont la réponse n'existe nulle part, pour vérifier que le système sait se taire.

La question qu'on pose en premier en mission

Quand nous intervenons sur un RAG existant, la première question est toujours la même : « Comment mesurez-vous la performance de votre RAG ? » En général, personne ne sait répondre. Les réponses entendues sont « Comment on fait pour mesurer ? » ou « Non, pas vraiment ». Quand la réponse est oui, c'est le plus souvent « on pose quelques questions », parfois les trois mêmes à chaque fois.

Le vrai problème n'est pas l'absence de mesure au lancement, c'est qu'elle n'est ni faite ni suivie à chaque évolution ou nouvelle fonctionnalité. Sans mesure à chaque changement, on ne sait pas si l'assistant progresse ou régresse.

Une mesure binaire, dès les premiers jours

Nous mettons en place l'évaluation dès le début du projet, avec un pourcentage de performance. Chaque réponse est classée de façon binaire : bonne, complète ou fausse. Une note de 1 à 5 est peu pertinente, parce que deux relecteurs n'attribuent jamais la même.

• Dès les 2 à 3 premiers jours : 20 à 50 questions de test, suffisantes pour une première mesure.
• Pendant les tests : toutes les questions posées par les utilisateurs sont reprises dans le jeu d'évaluation, qui s'enrichit au lieu d'être figé.
• À chaque évolution : nouvelle fonctionnalité, changement de modèle, nouveau découpage, on relance la mesure avant de livrer.

La première mesure surprend régulièrement : un RAG basique répond juste à 50 à 70 % des questions. Après les premières corrections, nous avons vu des assistants passer de 30 % à 70 %, de 50 % à 70 %, ou de 20 % à 50 % sur des cas d'usage complexes. Le détail de la méthode est dans notre article mesurer la performance d'un RAG en entreprise.

Séparer la recherche de la rédaction

La première chose à mesurer n'est pas la réponse, c'est la recherche. Sur chaque question du jeu de test, le bon document figure-t-il parmi les passages récupérés ? Si la réponse est non, aucun changement de modèle ni de prompt n'y fera quoi que ce soit : le problème est en amont, dans le découpage, l'indexation ou le filtrage. Cette distinction évite des semaines de réglages inutiles.

Trois indicateurs lisibles par un dirigeant

• Taux de réponses correctes sur le jeu de test, validé par un référent métier et non par l'équipe technique.
• Taux de sources correctes : la réponse est-elle appuyée sur le bon document ? Une bonne réponse issue du mauvais document est un problème, parce qu'elle ne se reproduira pas.
• Taux d'abstention : la proportion de questions où le système répond qu'il ne sait pas. Un taux nul est un mauvais signal, pas un bon : cela veut dire que l'assistant improvise plutôt que de reconnaître les trous de la documentation.

Des outils comme RAGAS automatisent une partie de cette évaluation (fidélité aux sources, pertinence des passages), mais ils ne remplacent pas la relecture métier sur un échantillon. Si un système est déjà en production et donne des réponses décevantes, notre audit RAG et agents IA établit cette mesure de départ et identifie la cause dominante avant toute correction.

Limites

Limites du RAG et cas où ce n'est pas la bonne réponse

Un RAG ne remplace ni une base de données ni un logiciel métier : il retrouve et reformule de l'information écrite, rien de plus. Connaître ses limites avant de lancer un projet évite la déception classique du pilote qui marche bien sur les questions de démonstration et déçoit sur les vraies.

• Il ne compte pas et n'agrège pas. « Combien de contrats arrivent à échéance ce trimestre ? » n'est pas une question de RAG, c'est une requête sur des données structurées. La bonne architecture combine alors une recherche documentaire et une interrogation de base, comme dans notre exemple de RAG sur factures fournisseurs en architecture hybride.
• Il raisonne mal à l'échelle du corpus entier. Les questions du type « quels sont les points communs de tous nos contrats depuis cinq ans » demandent de lire la totalité du fonds, pas d'en extraire cinq passages.
• Il ne répond pas à ce qui n'est écrit nulle part. Si la règle est implicite ou connue de deux personnes, l'assistant ne la déduira pas.
• Il lit mal les documents très visuels. Plans cotés, schémas techniques, tableaux complexes en PDF : des approches multimodales existent, mais le résultat reste à vérifier systématiquement. Sur les métrés, le chiffrage et la conformité réglementaire, le contrôle humain ou le logiciel métier reste la référence.
• Sa fraîcheur dépend de la réindexation. Un document modifié ce matin n'est visible qu'après le prochain passage d'indexation. Cette fréquence est un paramètre à décider, pas une propriété magique du système.

Quatre situations où il faut renoncer au RAG

• Un corpus de quelques dizaines de documents bien rangés. Une arborescence claire et une bonne recherche plein texte rendent le même service pour un effort sans comparaison.
• Un besoin exclusivement chiffré. Si toutes les questions portent sur des chiffres présents dans l'ERP ou le CRM, c'est un sujet de tableau de bord et de requêtes, pas de recherche documentaire.
• Un besoin d'action plutôt que de réponse. Quand l'attente est « que ça relance le client » ou « que ça crée le devis », c'est un projet d'automatisation, éventuellement augmenté d'IA, pas un assistant documentaire.
• Un seul document à la fois. Analyser un contrat reçu ce matin ne demande pas d'index : un outil généraliste avec une grande fenêtre de contexte fait l'affaire. C'est aussi le raisonnement à tenir face aux outils intégrés du marché, que nous comparons dans Notion IA ou RAG sur mesure, aux côtés de Microsoft Copilot pour les entreprises déjà équipées en Microsoft 365.