RAG en entreprise : architecture, cas d'usage et retours d'expérience

Sur les 18 derniers mois, nous avons audité plus d'une vingtaine de projets RAG (Retrieval-Augmented Generation) dans des grands groupes français. Le scénario se répète : une démo bluffante construite en quelques semaines, validée par un sponsor enthousiaste, puis un passage en production qui s'étire et déçoit. Le bot interne « répond bien » sur dix questions de test, retourne des hallucinations ou des bouts de doc obsolète sur les vraies questions des utilisateurs. La direction conclut que « l'IA n'est pas mûre ». L'IA, en réalité, n'est pas le maillon faible.

L'écart entre une démo RAG et un RAG en production se joue sur quatre choses qui ne dépendent pas du LLM : la qualité de l'ingestion, la stratégie de chunking, la gouvernance des sources et l'observabilité. C'est moins glamour qu'un benchmark GPT-5 contre Claude 4.6 Sonnet, mais c'est ce qui sépare les projets qui passent à l'échelle des prototypes qu'on remet sous le tapis. Cet article décortique l'architecture, les décisions structurantes et les cas d'usage où le RAG fait vraiment la différence.

Qu'est-ce qu'un RAG, vu de bout en bout

Le principe tient en une phrase : on ne demande pas au LLM de « savoir » la réponse, on lui fournit les bons extraits documentaires au moment de la question, et on lui demande de répondre uniquement à partir de ces extraits. C'est ce qui permet à un Claude 4.6 Sonnet, un GPT-5 ou un Mistral Large 3 de répondre avec précision sur la convention collective interne, le catalogue produits ou les comptes rendus du dernier comité — choses qu'aucun modèle public n'a jamais vues.

La chaîne complète comporte cinq étapes, dont seule la dernière implique le LLM. C'est ce que la plupart des projets ratent : ils consacrent 80 % de leur attention au prompt et au modèle, alors que les 80 % de qualité finale se jouent en amont.

Architecture RAG type — pipeline d'indexation (offline) et pipeline de requête (online)

Une bonne ressource pour creuser la chaîne pas à pas : la documentation RAG de LangChain et l'OpenAI cookbook RAG qui montrent les bouts de code minimum, utiles pour cadrer un POC en interne.

Les quatre décisions architecturales structurantes

Au-delà des composants techniques, quatre choix conditionnent la trajectoire d'un projet RAG. Pris dans le bon ordre, ils évitent 80 % des refactos coûteux à six mois.

• Stratégie de chunking — taille fixe (512 / 1024 tokens) ou découpage sémantique ? Avec ou sans contextualisation amont (Contextual Retrieval) ? Le mauvais découpage est la première cause d'échec d'un RAG, devant le choix du modèle.
• Hybrid search ou pure vector ? — la recherche purement vectorielle rate les requêtes contenant un identifiant produit, un code interne, un nom propre rare. La combinaison embeddings + BM25 (recherche par mots-clés) reste la valeur sûre.
• Reranking — un retrieve top-20 puis un rerank top-3 améliore quasi systématiquement la précision finale. Cohere Rerank ou un cross-encoder open source font une vraie différence pour quelques dizaines de millisecondes par requête en plus.
• Gouvernance des permissions — qui a le droit de voir quoi ? Si un commercial peut interroger un RAG qui retrouve des fiches RH, vous avez un problème de sécurité avant d'avoir un problème de qualité. Le filtrage par metadata au moment du retrieval n'est pas optionnel.

Choix du vector store : Pinecone, Weaviate, pgvector, Qdrant

Le marché s'est stabilisé autour de quatre options sérieuses pour un usage entreprise. Le bon choix dépend moins de la performance brute (toutes sont rapides à l'échelle du million de chunks) que de l'écosystème existant et du modèle d'hébergement acceptable.

Sur les déploiements grands comptes français, la combinaison qui revient le plus est pgvector pour la majorité des cas (en s'appuyant sur l'infrastructure Postgres déjà présente, hébergée chez OVH ou Scaleway), ou Qdrant dès qu'on dépasse les 5-10 millions de chunks et qu'on cherche de la performance avec souveraineté. Pinecone reste excellent pour démarrer vite, à condition que la donnée puisse sortir de l'UE — ce qui est rarement le cas dans une banque ou une assurance. La documentation Pinecone détaille les benchmarks officiels.

Choix du modèle d'embedding : OpenAI, Cohere, Mistral

L'embedding model transforme chaque chunk de texte en un vecteur. Sa qualité détermine la pertinence du retrieval — un bon LLM derrière un mauvais embedding produit des réponses fluides mais hors sujet. Trois familles dominent en 2026 pour l'usage entreprise.

• OpenAI text-embedding-3-large (3 072 dimensions, multilingue) — la valeur sûre, performante en français, intégration facile. Inconvénient : passage par les API US, ce qui pose question sur les données sensibles.
• Cohere embed-multilingual-v3 (1 024 dimensions, 100+ langues) — excellent compromis qualité/coût, très bien sur le français, disponible aussi via AWS Bedrock en région EU.
• Mistral mistral-embed (1 024 dimensions) — l'option souveraine, hébergeable sur infrastructure française, qualité comparable sur le corpus français. Le bon choix pour les organisations sous contrainte de localisation des données.

Trois conseils opérationnels qu'on répète à chaque démarrage de projet : ne mélangez jamais des chunks embedded avec des modèles différents dans le même index ; testez le modèle d'embedding sur vos données avec un dataset d'évaluation maison plutôt que sur les benchmarks publics ; gardez un plan de migration (les vecteurs ne sont pas portables d'un modèle à l'autre, il faut tout réindexer).

Les cinq cas d'usage qui marchent en production

Sur la vingtaine de projets RAG audités, ces cinq familles concentrent la quasi-totalité des succès. Aucune n'est une surprise — ce qui surprend, c'est de voir combien d'organisations partent sur des cas d'usage qui ne tiennent pas.

• Assistant documentaire interne — répondre à des questions sur la documentation produit, technique ou réglementaire interne. Le ROI est immédiat dans les fonctions support, juridique, conformité, achats. Le plus simple à industrialiser, le moins risqué.
• Support client niveau 1 — agent conversationnel qui répond aux questions fréquentes en s'appuyant sur la base de connaissances et l'historique CRM. Économie de tickets significative à condition d'avoir une escalade humaine claire et un tracking des cas non résolus.
• Conformité et veille réglementaire — interroger un corpus de textes réglementaires (BCE, AMF, ANSSI, AI Act, RGPD…) pour produire des notes ou des analyses d'impact. Cas d'usage très valorisé en banque/assurance, où la veille manuelle est chronophage.
• Knowledge management transverse — agréger les connaissances éparpillées entre SharePoint, Confluence, Slack, mails, comptes rendus de réunion. Cas plus complexe (gouvernance des accès), mais ROI durable une fois en place.
• Génération sourcée — produire un document (note, mémo, réponse à appel d'offres) en s'appuyant sur des extraits cités, avec traçabilité. C'est ici que la combinaison RAG + LLM dépasse vraiment ce qu'un humain seul peut faire en termes de couverture documentaire.

Le point commun de ces cinq cas : ils tolèrent une réponse partielle ou « je ne sais pas, voici les sources pertinentes ». Ils ne demandent pas au système d'inventer ce qui manque. C'est exactement l'inverse d'un cas d'usage marketing qui demanderait au RAG de « générer une accroche créative à partir de la doc produit » — là, le RAG n'apporte rien, et il y a fort à parier que ça déraille.

Pourquoi les cas d'usage RAG échouent

Sur les projets qui patinent, on retrouve toujours une combinaison de plusieurs des pièges suivants. La bonne nouvelle : aucun n'exige d'inventer un nouveau modèle. Tous se règlent au niveau ingestion / pipeline / observabilité.

L'observabilité d'un RAG : le vrai différenciateur

C'est l'angle mort de presque tous les projets que nous reprenons. Un RAG sans observabilité est une boîte noire dont la qualité dégrade silencieusement à mesure que la base documentaire change. Trois briques indispensables, indépendamment du stack choisi.

Eval dataset — un jeu de questions / réponses attendues / sources attendues, construit avec les utilisateurs métier. 100 à 500 lignes suffisent pour démarrer. Ce dataset devient la référence : à chaque changement (nouveau modèle, nouveau chunking, nouveau prompt), on rejoue l'éval et on regarde ce qui s'améliore et ce qui régresse.

Framework d'évaluation — RAGAS est devenu le standard de fait. Il calcule des métriques spécifiques au RAG : context precision (les chunks récupérés sont-ils pertinents ?), context recall (a-t-on récupéré tout ce qui était nécessaire ?), faithfulness (la réponse est-elle bien fondée sur les chunks ?), answer relevance. Ces métriques sont plus utiles que la « précision globale » qu'on entend trop souvent en réunion.

Tracing en production — LangSmith ou Langfuse pour tracer chaque requête de bout en bout : question, chunks récupérés, score du reranker, prompt final, réponse, feedback utilisateur. Sans ces traces, vous ne saurez pas pourquoi le système a halluciné sur une question donnée — et donc vous ne saurez pas le corriger.

Pour les organisations qui industrialisent plusieurs cas d'usage en parallèle, ces briques s'inscrivent dans une démarche plus large de mise en production des LLM, qu'on a détaillée dans notre article sur le choix des LLM en production et dans le retour d'expérience sur la création d'un agent IA d'entreprise.

Comment nous intervenons sur un projet RAG

Nous accompagnons banques, assureurs, industriels et acteurs publics français sur le passage en production de leurs RAG depuis 2023. Nos missions s'organisent en général autour de trois angles, selon la maturité de l'équipe interne.

• Audit d'un RAG existant — diagnostic de la chaîne complète (ingestion, chunking, embeddings, retrieval, prompt), identification des points de fuite de qualité, recommandations priorisées.
• Conception d'architecture — choix des composants (vector store, embeddings, LLM, reranker), définition de la gouvernance des sources et des accès, dimensionnement infra et coûts.
• Industrialisation — mise en place du dataset d'éval, du tracing, des pipelines CI/CD pour les changements de prompt et de chunking, formation des équipes data/IA internes.

Le sujet recoupe nos expertises GenAI et data engineering. C'est un projet IA et un projet data — séparer les deux est l'une des raisons pour lesquelles autant de RAG d'entreprise n'arrivent pas à passer le mur de la production.

Ce que change un RAG bien conçu

Un RAG en production qui tient n'est pas un projet où l'on a trouvé le bon modèle. C'est un projet où l'on a accepté que 70 % du travail se fait sur la donnée, le pipeline et l'observabilité, et que le LLM n'est que la dernière étape — celle qu'on peut changer en quelques heures quand un meilleur modèle sort. Les organisations qui réussissent sont celles qui ont arrêté de traiter le RAG comme un projet IA pour le traiter comme un produit data, avec un backlog, des évaluations régulières, une roadmap. Le reste n'est que de la plomberie soignée.