Architecture RAG en entreprise : les choix qui comptent

Le RAG est l'architecture la plus déployée de l'IA en entreprise, et probablement la plus mal comprise. Le principe tient en une phrase : nous branchons un modèle de langage sur la documentation de l'entreprise, puis nous le laissons répondre à partir de ces données. Sur une démonstration avec vingt PDF, cela fonctionne en une après-midi.

En production, avec quinze ans de devis, de procédures, de contrats, de plans et de rapports, le tableau change. Une référence exacte ne remonte pas. Deux versions contradictoires d'une même procédure sortent côte à côte. Un tableau est mal lu. Le modèle répond très bien, à partir du mauvais document.

C'est le malentendu central du RAG : la qualité du système dépend beaucoup moins du LLM que de sa capacité à retrouver la bonne information. Un RAG sérieux n'est pas « ChatGPT branché sur une base vectorielle ». C'est un moteur de recherche complet, sur lequel nous greffons ensuite un modèle de langage.

Voici comment nous raisonnons chez BUMPSLAB quand nous construisons ce type de système, et les sept choix d'architecture qui décident si votre RAG restera un prototype ou tiendra en production.

Un RAG d'entreprise est un moteur de recherche avant d'être un LLM

RAG signifie retrieval-augmented generation, génération augmentée par récupération d'information. L'idée consiste à séparer deux problèmes. Le modèle de langage sait lire, raisonner et rédiger. Mais il ne connaît pas vos contrats, vos dossiers clients, vos gammes de fabrication ni vos anciens devis. Le RAG lui apporte ces informations au moment où il en a besoin.

Prenons une PME d'usinage. Un deviseur demande :

« Quelle matière avait été utilisée pour la pièce VLT-2024-0142, et quelle était la tolérance sur l'alésage ? »

Le système ne doit pas espérer que le modèle connaisse la réponse. Il doit comprendre la question, retrouver les documents portant sur VLT-2024-0142, isoler les passages contenant la matière et la tolérance, ne transmettre que ces passages au modèle, produire une réponse, puis citer le document et la page qui la justifient.

Takeaway : le RAG ne donne pas au modèle davantage de connaissances de façon permanente. Il lui donne la bonne information, au bon moment. Toute la difficulté tient dans le mot « bonne ».

Nous avons traité ailleurs le choix amont, RAG contre fine-tuning contre MCP. Cet article prend la suite : une fois le RAG retenu, quelles décisions structurent réellement le système.

Pourquoi le RAG « basique » casse en production

L'architecture des premiers prototypes tient en quatre étapes :

Document → découpage → embeddings → recherche vectorielle → LLM

Nous découpons les documents en morceaux, les chunks. Chaque morceau devient un vecteur numérique, un embedding, qui représente approximativement son sens. La question de l'utilisateur devient elle aussi un vecteur, et nous remontons les morceaux dont les vecteurs sont les plus proches. Les cinq ou dix premiers partent au LLM.

Pour un prototype, c'est excellent. Pour une base documentaire réelle, beaucoup moins. Prenez cette phrase dans un rapport :

« Roulement SKF 6205-2RSH utilisé sur l'ensemble VLT-2024-0142. »

La recherche sémantique comprend très bien « Quel roulement utilise cet ensemble ? ». Mais les entreprises ne travaillent pas qu'avec du sens. Elles travaillent avec VLT-2024-0142, 6205-2RSH, OF-38452, ISO 2768-mK, Client 28471 : des références exactes, des noms propres, des acronymes, des codes article. Sur ce terrain, la recherche vectorielle seule décroche vite.

Le réflexe habituel, quand la réponse est mauvaise, consiste à changer de modèle. De GPT à Claude, de Claude à Gemini, d'un 30B à un 70B. Cela améliore parfois la formulation. Mais si le système transmet le mauvais extrait, un meilleur LLM produit surtout une meilleure réponse à partir de la mauvaise information.

La chaîne réelle ressemble plutôt à ceci :

Sources → parsing → chunking → enrichissement → indexation → retrieval → reranking → contexte → LLM → citations → évaluation

Chaque étape porte un choix d'architecture, et plusieurs pèsent bien plus lourd que le modèle final.

Choix 1 : préparer les documents, et les découper juste

Avant de chercher une information, il faut rendre les documents exploitables. Cela paraît évident avec un PDF texte, beaucoup moins avec un scan, un plan industriel, un contrat de 80 pages, un classeur Excel, un export ERP ou un document multilingue.

L'ingestion doit préserver la structure du document et conserver ses métadonnées : version, date, auteur, type, client ou projet associé, page d'origine, droits d'accès. La raison est simple : une phrase sortie de son contexte perd son sens. « Délai : 6 semaines » ne veut rien dire si l'on ne sait plus à quel devis, quel fournisseur et quelle version elle appartient.

Le chunking n'est pas un réglage de taille

Le découpage est le choix le plus sous-estimé de toute la chaîne. Des chunks trop grands embarquent du bruit et noient l'information utile. Des chunks trop petits détruisent le contexte. La bonne stratégie dépend du document : une procédure se découpe par section, un contrat par clause, un rapport par page ou sous-section, un tableau doit souvent rester entier, et un plan technique exige encore une autre approche lorsque l'information vit dans l'image plutôt que dans une couche texte.

Takeaway : la règle n'est pas « des chunks de 500 tokens », c'est « un chunk doit représenter une unité d'information que l'on pourrait raisonnablement citer seule dans une réponse ».

Choix 2 : recherche hybride, sémantique et lexicale

Les deux, et c'est l'une des décisions les plus rentables d'un RAG moderne. La recherche vectorielle est excellente pour comprendre le sens : « délai de livraison fournisseur » retrouve un texte qui parle de « lead time d'approvisionnement ». Une recherche lexicale classique de type BM25 est excellente pour retrouver un terme précis : « Retrouve le dossier OF-38452 » est un cas où elle reste imbattable.

Dans un environnement métier, les deux questions arrivent le même jour, souvent du même utilisateur. Nous exécutons donc les deux recherches et fusionnons leurs résultats. C'est ce que l'on appelle la recherche hybride, et c'est notre point de départ sur la quasi-totalité des RAG métier que nous construisons.

Vecteur seul : rarement suffisant. BM25 seul : trop rigide. Hybride : beaucoup plus robuste.

Choix 3 : le reranker, meilleur rapport qualité sur complexité

Une fois trente ou cinquante candidats remontés, encore faut-il déterminer lesquels répondent réellement à la question. C'est le rôle du reranker. La première recherche privilégie la vitesse et ratisse large. Le reranker fait ensuite un travail plus coûteux mais bien plus précis : il prend la question et chaque passage candidat, et évalue directement leur pertinence.

Nous passons donc de 1 000 000 de passages → 30 candidats, puis de 30 candidats → 5 passages réellement utiles. L'architecture est efficace parce qu'elle réserve le calcul cher à une fraction minuscule de la base.

Un RAG professionnel ressemble donc beaucoup plus souvent à recherche hybride → 30 candidats → reranking → 5 à 10 passages → LLM qu'à recherche vectorielle → top 5 → LLM.

Choix 4 : le contextual retrieval, quand le chunk oublie d'où il vient

Le découpage introduit un problème subtil. Prenez ce chunk :

« Le chiffre d'affaires a progressé de 12 % par rapport à l'exercice précédent. »

Pris seul, il est presque inutilisable. De quelle entreprise parle-t-on, de quelle année, de quel département ? Le document original le savait, le chunk l'a oublié.

Le contextual retrieval consiste à enrichir chaque morceau, avant indexation, avec quelques informations qui le replacent dans son contexte. Le même chunk devient :

« Extrait du rapport annuel 2025 de l'entreprise X, section résultats France. Le chiffre d'affaires a progressé de 12 % par rapport à l'exercice précédent. »

Le passage devient nettement plus facile à retrouver correctement. Dans ses propres mesures, Anthropic rapporte une réduction de 49 % des échecs de retrieval en combinant contextualisation, recherche lexicale et embeddings, et de 67 % lorsqu'un reranker est ajouté.

Ce n'est pas pour autant une fonctionnalité magique : contextualiser chaque chunk coûte du calcul supplémentaire à l'ingestion. Nous l'activons quand la structure du corpus le justifie, typiquement des documents longs, des passages ambigus, une documentation très répétitive ou des sources où le contexte global est indispensable.

Choix 5 : GraphRAG, utile mais rarement nécessaire

GraphRAG revient dans toutes les discussions dès qu'un RAG devient complexe. Le principe est différent : au lieu de représenter les documents uniquement comme des morceaux de texte, nous extrayons aussi les entités et leurs relations.

Client A → possède → Machine X → utilise → Composant Y → fourni par → Fournisseur Z

Cela devient intéressant pour les questions multi-hop, dont la réponse exige de relier plusieurs informations : « Quels fournisseurs interviennent sur les machines utilisées par les clients dont les contrats arrivent à renouvellement au prochain trimestre ? ». Cette réponse n'existe dans aucun paragraphe unique, il faut traverser plusieurs relations.

En revanche, ajouter un graphe pour répondre à « Quelle est notre procédure de création d'un nouveau fournisseur ? » est du sur-équipement.

Takeaway : nous commençons simple, nous mesurons les erreurs, et nous n'ajoutons de la complexité que lorsqu'elle corrige un problème identifié.

Choix 6 : base vectorielle et modèle d'embedding

La base vectorielle

Dans la majorité des projets PME et ETI, la question n'est pas de trouver « la meilleure » base, mais celle qui s'accorde avec l'infrastructure existante.

Solution	Quand nous la considérons
pgvector	PostgreSQL est déjà en place et le volume reste raisonnable
Qdrant	Choix par défaut pour un RAG auto-hébergé et dédié
Weaviate	La recherche hybride native est au centre du besoin
Milvus	Très gros volumes, et une équipe capable d'absorber la complexité opérationnelle
Chroma	Prototype ou expérimentation

Pour beaucoup de PME, pgvector ou Qdrant couvrent largement le problème. Si toute l'application repose déjà sur PostgreSQL et que le corpus reste modeste, ajouter une seconde technologie uniquement pour stocker des vecteurs se justifie rarement. À l'inverse, une base dédiée devient intéressante dès que le filtrage, l'indexation et la recherche prennent de l'importance. Regardez autre chose que la vitesse brute : filtrage par métadonnées, sauvegardes, haute disponibilité, gestion des droits, observabilité, coût opérationnel. Le benchmark le plus impressionnant n'est pas nécessairement le meilleur choix d'architecture.

Le modèle d'embedding

Autre erreur fréquente : passer des semaines à choisir le LLM et dix minutes à choisir le modèle d'embedding, alors que c'est lui qui transforme documents et requêtes en représentations utilisées par la recherche sémantique. Son choix dépend des langues en présence, du vocabulaire métier, de la latence acceptable et des contraintes de souveraineté. Une entreprise suisse peut devoir chercher simultanément en français, allemand, italien et anglais : un embedding optimisé pour l'anglais devient alors un mauvais compromis, même avec un excellent score sur un benchmark public. La seule réponse sérieuse consiste à tester sur vos propres questions et vos propres documents.

Choix 7 : quel LLM derrière le RAG

Seulement maintenant arrive le choix que beaucoup font en premier. Il faut distinguer deux familles de tâches.

Retrouver et reformuler une information factuelle : répondre sur une procédure, extraire une donnée, résumer un dossier, comparer deux documents, citer un contrat, sortir les caractéristiques d'une pièce. Si le retrieval a fait son travail, l'effort demandé au modèle reste modeste, et les modèles open source ou open weights modernes sont très compétitifs.

Raisonner fortement sur les informations retrouvées : croiser plusieurs contraintes juridiques, mener une analyse financière, construire un raisonnement en plusieurs étapes, choisir dynamiquement parmi de nombreux outils, arbitrer une situation ambiguë. Les modèles frontier gardent ici un avantage réel.

Takeaway : la bonne question n'est pas « quel est le meilleur modèle ? », mais « quelle quantité d'intelligence devons-nous réellement acheter pour cette tâche ? ». Mettre le modèle le plus cher du marché derrière un retrieval médiocre est une mauvaise allocation de budget.

Le cas suisse : la souveraineté est un choix d'architecture

Pour une entreprise suisse, un second critère s'ajoute à la performance : où passent les données. Deux notions sont régulièrement confondues. La résidence des données signifie qu'elles sont physiquement hébergées en Suisse. La souveraineté signifie que l'ensemble de la chaîne, stockage, embeddings, inference, logs, sauvegardes, support et télémétrie, reste sous des juridictions et des contrôles acceptés par l'entreprise.

Un service hébergé dans une région cloud « Switzerland » n'est donc pas automatiquement souverain. La question se pose sur tout le chemin parcouru par la donnée, ce qui est particulièrement sensible avec un RAG puisque la documentation traverse plusieurs briques :

document → OCR → embeddings → base → reranker → LLM → monitoring

Sécuriser le seul LLM ne suffit pas. C'est exactement le point que nous développons dans notre analyse de ce que « LLM souverain » veut vraiment dire pour une PME suisse.

Classifier la donnée avant de choisir le modèle

Nous préférons commencer par la donnée. Une classification en trois niveaux suffit dans la plupart des cas.

• Niveau A, données publiques ou peu sensibles. Documentation publique, catalogue, site web, contenus commerciaux génériques. Nous privilégions la performance et utilisons des modèles frontier lorsqu'ils apportent un bénéfice réel.
• Niveau B, données internes ou confidentielles. Procédures, documentation technique, contrats, données commerciales. Nous durcissons les contraintes sur l'hébergement, la rétention et les fournisseurs.
• Niveau C, données hautement sensibles. RH, santé, secrets industriels, dossiers financiers, informations personnelles sensibles, ou données soumises à des exigences réglementaires fortes. Une chaîne souveraine suisse ou on-premise devient ici une exigence d'architecture.

Cette grille évite deux extrêmes symétriques : envoyer toutes les données vers le modèle le plus performant du marché sans se poser de question, ou imposer l'infrastructure la plus fermée possible à toute l'entreprise, y compris sur du contenu public, avec un coût et une complexité inutiles. La meilleure architecture est presque toujours hybride.

À quoi ressemble une stack RAG souveraine

Pour une PME suisse, une architecture crédible tient en six briques. Le stockage et le compute sur une infrastructure suisse, par exemple Exoscale, Infomaniak ou une infrastructure interne. La base de recherche en Qdrant ou PostgreSQL avec pgvector auto-hébergé. Le retrieval en hybride, BM25 plus embeddings, fusion, puis reranking. Les embeddings et le reranking exécutés en Suisse ou directement chez le client. Le LLM en open weights, Apertus, Mistral ou Qwen, sur infrastructure suisse. Et le monitoring dans le même périmètre que le reste.

Apertus, développé par l'EPFL, l'ETH Zurich et le CSCS, est intéressant précisément parce qu'il rend cette chaîne réalisable de bout en bout. Cela ne veut pas dire qu'il sera le meilleur modèle pour chaque tâche. Cela veut dire que le choix existe, et c'est ce qui compte.

Un même système peut d'ailleurs utiliser plusieurs modèles : open source hébergé en Suisse sur les données sensibles, frontier sur la documentation publique quand son raisonnement apporte un gain mesurable, petit modèle rapide pour l'extraction simple. Le modèle devient une ressource que l'orchestrateur sélectionne selon le problème. Nous rendons donc la couche RAG agnostique vis-à-vis du modèle : le jour où un meilleur modèle sort, ou où les contraintes d'un client changent, la couche de données n'est pas à reconstruire.

Ce que presque tous les projets RAG oublient : l'évaluation

Comment savoir si un RAG fonctionne ? Pas en posant cinq questions pendant une démonstration. Il faut un jeu de référence, construit avec les métiers :

Question : quelle est la matière de la pièce VLT-2024-0142 ? Document attendu : plan-technique-VLT-2024-0142.pdf Passage attendu : page 2 Réponse attendue : TA6V / Ti-6Al-4V

Répétez l'exercice sur 50, 100 ou 500 questions représentatives des usages réels, puis mesurez séparément cinq choses : le retrieval (le bon document a-t-il été retrouvé ?), le ranking (le bon passage apparaît-il assez haut ?), le grounding (la réponse est-elle réellement supportée par les sources ?), les citations (les références correspondent-elles aux affirmations ?) et la réponse finale (la formulation répond-elle à la question posée ?).

Cette séparation est décisive. Si le bon passage n'a jamais été retrouvé, retoucher le prompt du LLM ne sert à rien. Si le passage est correct mais la réponse mauvaise, le problème est côté génération. C'est ce qui permet d'améliorer le système par la mesure plutôt qu'à l'intuition, et c'est aussi l'un des écarts les plus nets entre un pilote et un système qui tient. Nous détaillons cette mécanique dans les coulisses d'Atlas, notre RAG industriel souverain.

Un bon RAG sait dire « je ne sais pas »

La meilleure réponse d'un système documentaire n'est pas toujours une réponse. Si aucune source suffisante n'a été retrouvée, il doit pouvoir dire : « Je n'ai pas trouvé cette information dans les documents disponibles. » Cela semble banal, c'est pourtant l'une des différences fondamentales entre une démonstration impressionnante et un outil utilisable : en contexte métier, une réponse plausible mais inventée coûte beaucoup plus cher qu'une absence de réponse.

Le système a donc besoin d'un seuil de confiance et de règles explicites. Retrieval insuffisant : pas de réponse factuelle. Sources contradictoires : nous montrons les deux. Document ancien : nous l'indiquons. Aucune citation : nous ne présentons pas l'information comme certaine.

La confiance ne vient pas du fait que le modèle parle bien. Elle vient de notre capacité à vérifier pourquoi il affirme quelque chose.

RAG, long contexte ou fine-tuning

Le RAG n'est pas toujours la bonne réponse. Sur un corpus très petit, quelques centaines de pages relativement stables, transmettre directement l'ensemble des documents au modèle est plus simple : pas de base vectorielle, pas de retrieval. Cette option mérite d'être testée avant d'ouvrir un chantier. Le RAG devient pertinent quand la connaissance dépasse le contexte du modèle, quand les documents changent régulièrement, quand il faut chercher vite, filtrer par droits, citer précisément les sources, et quand le volume grimpe.

Le fine-tuning répond à un autre besoin : il modifie le comportement du modèle, son format de réponse, son style, un vocabulaire ou une tâche répétitive. Ce n'est pas la bonne méthode pour lui faire mémoriser une base documentaire qui bouge toutes les semaines.

Takeaway : le RAG apporte la connaissance, le fine-tuning modifie le comportement. Les deux se combinent, mais ils ne s'opposent pas.

Notre stack par défaut, et le tableau de décision

Il n'existe pas de stack universelle. Pour une PME ou une ETI disposant d'une base documentaire métier importante, notre point de départ ressemble à ceci :

• Ingestion : parsing structuré, OCR si nécessaire, conservation des métadonnées et des pages.
• Chunking : selon la structure du document, pas selon un nombre fixe de tokens.
• Indexation : embeddings multilingues et index lexical.
• Stockage : Qdrant auto-hébergé, ou pgvector si un PostgreSQL existant suffit.
• Recherche : hybride, sémantique et BM25.
• Reranking : classement précis des meilleurs résultats.
• Génération : modèle choisi selon la tâche et la sensibilité de la donnée.
• Confiance : citations obligatoires, seuil de qualité, droit de ne pas répondre.
• Évaluation : jeu de questions métier et tests anti-régression.

La technologie exacte changera. Cette architecture, beaucoup moins.

Votre situation	Choix de départ
Quelques dizaines de documents	Tester d'abord le long contexte
Gros corpus documentaire	RAG
Références, noms propres, codes articles	Recherche hybride
Résultats proches mais mal classés	Ajouter un reranker
Chunks ambigus hors de leur contexte	Contextual retrieval
Questions nécessitant plusieurs relations	Évaluer GraphRAG
PostgreSQL déjà présent, volume raisonnable	pgvector
RAG dédié, auto-hébergé	Qdrant
Très grands volumes	Évaluer Milvus
Questions factuelles et extraction	Modèle open weights souvent suffisant
Raisonnement complexe	Tester les modèles frontier
Données sensibles suisses	Infrastructure et inference suisses
Données extrêmement sensibles	Envisager l'on-premise
Pas encore de jeu d'évaluation	Ne rien optimiser avant de le créer

Ce que nous retenons

Le RAG est souvent présenté comme une fonctionnalité. C'est une discipline d'ingénierie. Poser quelques PDF dans une base vectorielle et envoyer les cinq résultats les plus proches à un LLM suffit pour une démonstration. Passer en production demande une ingestion fiable, une recherche hybride, un reranking, des droits et des métadonnées conservés, un modèle choisi pour la tâche plutôt que pour son prestige, une maîtrise du chemin parcouru par les données, une citation sur chaque réponse, et une mesure continue de la qualité du retrieval.

Pour améliorer un RAG, nous commençons rarement par changer de LLM. Nous commençons par vérifier ce qu'il a réellement reçu comme information.

C'est aussi ce qui rend les modèles ouverts et souverains crédibles en entreprise. Quand la bonne information est retrouvée et correctement présentée, le modèle n'a pas besoin de connaître toute votre entreprise : il doit surtout savoir utiliser les quelques passages que nous venons de lui fournir. Le sujet n'est donc plus de chercher « le meilleur LLM », mais de construire une architecture où chaque donnée est envoyée au bon moteur, avec le bon niveau de sécurité, pour la bonne tâche.

C'est la logique que nous appliquons pour construire Atlas et nos assistants documentaires métier : un socle de données indépendant du modèle, mesurable, sourcé, et déployable en Europe, en Suisse ou directement dans l'infrastructure du client. Pour les PME industrielles, cette brique s'inscrit dans une trajectoire plus large que nous décrivons dans notre guide IA pour PME industrielle.

FAQ

Un RAG empêche-t-il complètement les hallucinations ? Non. Un RAG réduit fortement le problème lorsqu'il retrouve de bonnes sources, mais le LLM reste un modèle génératif. Il faut ajouter des citations, un seuil de confiance, une évaluation régulière et des règles permettant au système de ne pas répondre.

Quelle est la différence entre une base vectorielle et un RAG ? La base vectorielle n'est qu'une brique du système. Le RAG comprend aussi l'ingestion, le découpage des documents, les embeddings, la recherche, le reranking, la génération, les citations et l'évaluation.

Faut-il forcément une base vectorielle ? Non. Sur un petit corpus, fournir directement les documents au modèle peut suffire et coûte moins cher à opérer. Une base devient intéressante quand le volume, les performances de recherche ou les besoins de filtrage augmentent.

GPT ou Claude sont-ils forcément meilleurs pour un RAG ? Pas nécessairement. Sur des questions factuelles où le bon passage est déjà fourni, des modèles open weights plus petits suffisent souvent. Les modèles frontier se différencient surtout quand le raisonnement demandé est complexe.

Peut-on construire un RAG entièrement hébergé en Suisse ? Oui. Compute, stockage, embeddings, base vectorielle, reranking et LLM disposent aujourd'hui d'options hébergeables en Suisse ou directement chez le client. La difficulté n'est plus technique, elle est d'architecture et de contrat.

RAG ou fine-tuning ? Pour connecter une IA à une connaissance documentaire qui évolue, RAG. Pour modifier durablement le comportement du modèle sur une tâche, fine-tuning. Les deux répondent à des problèmes différents et se combinent très bien.

Comment savoir si notre RAG est bon ? En construisant un jeu de questions représentatives et en mesurant séparément la capacité du système à retrouver la bonne source, à la classer correctement et à produire une réponse fidèle. Sans jeu d'évaluation, nous optimisons à l'intuition.

---

Un RAG qui tient en production se juge sur ce qu'il retrouve, pas sur ce qu'il rédige. Si vous voulez savoir où en est votre corpus et quelle architecture il appelle vraiment, notre méthode de cadrage part de vos documents et de vos questions réelles, pas d'une stack décidée à l'avance.