Pourquoi deux entreprises ne devraient pas construire le même RAG

Un assistant qui explore une documentation technique, un moteur de recherche interne et un outil qui génère des mémoires de plus de 120 pages peuvent tous reposer sur du RAG. Ils ne devraient pourtant pas partager la même architecture. Les retours d’expérience de Quentin Lavallée, Yosr Abdelmoula et Zarah Sultan, AI Engineers chez aiko, montrent pourquoi les documents, les usages métier et les contraintes de production doivent passer avant le choix de la stack.

Un RAG peut fonctionner parfaitement en démonstration et devenir inutilisable une fois confronté aux conditions réelles de l’entreprise. Les documents changent. Les utilisateurs n’ont pas tous les mêmes droits. Certaines informations se cachent dans des tableaux ou des pages scannées. Une réponse vraisemblable peut s’appuyer sur le mauvais passage. Et une architecture rapide à mettre en place peut devenir difficile à diagnostiquer dès que la qualité se dégrade.

Ces problèmes n’appellent pas tous la même réponse technique. C’est ce que montrent trois projets menés dans des contextes très différents.

Quentin travaille sur un RAG intégré comme outil à un agent conversationnel. Le corpus se compose principalement de documentations techniques en PDF, avec du texte, des tableaux et des images d’illustration. Yosr a construit un assistant d’accès à l’information interne destiné à environ 200 personnes, en s’appuyant sur un service RAG managé. Zarah a développé une application capable d’exploiter plusieurs pièces d’un dossier d’appel d’offres pour générer un mémoire technique structuré, parfois long de plus de 120 pages.

Même famille technologique, trois architectures. Leur point commun ne se trouve pas dans une base vectorielle, un modèle d’embeddings ou un fournisseur cloud. Il tient dans une méthode : commencer par les documents, les questions posées et les conditions d’utilisation, puis seulement choisir les briques techniques.

La stack RAG universelle est un faux raccourci

Réduire un RAG à un LLM connecté à une base vectorielle masque l’essentiel. En production, le système forme une chaîne complète : il faut synchroniser les sources, extraire et structurer leur contenu, le découper, l’indexer, retrouver les bons passages, produire une réponse, appliquer les droits d’accès et surveiller le fonctionnement de l’ensemble.

Chacune de ces briques répond à des contraintes différentes. Une erreur d’extraction ne se corrige pas comme un mauvais résultat de recherche. Un problème de droits d’accès ne relève pas de la génération. Une réponse obsolète peut venir d’un document qui n’a jamais été réindexé, alors même que le modèle fonctionne exactement comme prévu.

Pour cette raison, Yosr et Zarah convergent vers une architecture modulaire, dans laquelle ingestion, extraction, indexation, retrieval et génération restent séparés. Zarah résume l’intérêt de ce découpage : il permet de « corriger ou remplacer une brique sans remettre en cause l’ensemble de l’application ».

Cette modularité n’impose pourtant pas une stack unique. Le système peut être construit sur mesure, s’appuyer sur un service managé ou exposer le retrieval comme un outil appelé par un agent. Le bon choix dépend du niveau de contrôle attendu, du délai disponible, de la complexité des documents et des capacités de maintenance de l’équipe.

L’enjeu dépasse donc la performance technique immédiate. Une architecture monolithique peut accélérer un prototype, mais rendre chaque évolution plus coûteuse. À l’inverse, une séparation claire des composants facilite le diagnostic, limite les reconstructions complètes et laisse davantage de liberté pour faire évoluer le système.

Les documents déterminent les choix techniques

Les projets de Quentin et de Zarah illustrent particulièrement bien ce principe. Tous deux partent de corpus majoritairement composés de PDF. Pourtant, l’analyse de ces documents les conduit à des décisions presque opposées.

Dans le projet de Quentin, les images sont des schémas de prise de mesures ou des photographies de produits. Elles illustrent une information déjà présente dans le texte. Les transformer systématiquement avec de l’OCR ou un modèle de vision ajouterait de la complexité sans nécessairement produire une information plus utile. L’architecture retient donc une extraction légère : le texte et les tableaux sont extraits, la présence de l’image est signalée et la source permet à l’utilisateur de retrouver l’illustration originale.

Le découpage suit la même logique. Les documents étant naturellement structurés par pages, un chunk par page constitue un point de départ simple et cohérent. Cette décision pourra être revue si l’évaluation montre que certaines réponses nécessitent un autre découpage, mais elle évite de complexifier le pipeline avant d’avoir observé un problème réel.

« Une image est bien plus parlante pour l’utilisateur que sa transcription en texte », souligne Quentin. Le choix le plus sobre n’est pas ici une concession technique : il correspond mieux à l’usage.

Dans le projet de Zarah, les pièces des dossiers d’appels d’offres contiennent au contraire des informations réparties entre plusieurs documents, tableaux, schémas, illustrations et pages parfois scannées. Une extraction limitée au texte risquerait de supprimer précisément les éléments dont le métier a besoin. Le pipeline mobilise donc des outils comme Docling et, lorsque nécessaire, de l’OCR, tout en conservant la structure et les références aux pages.

Cette complexité a un coût concret. Lors d’un test local, l’extraction et l’indexation de deux PDF totalisant 58 Mo ont pris environ vingt minutes. Il ne s’agit pas d’une mesure consolidée de production, mais le test suffit à montrer que l’ingestion ne peut pas être considérée comme une étape instantanée ou secondaire.

Ces deux architectures ne se contredisent pas. Elles appliquent la même règle : utiliser l’approche la plus simple qui préserve réellement l’information utile. Surajouter de l’OCR ou de la vision au premier corpus augmenterait les délais et la maintenance. Ne pas les prévoir dans le second diminuerait la fiabilité du résultat. La forme des documents produit directement des conséquences sur les coûts, le time-to-production et la qualité du service.

Le métier détermine jusqu’où le système peut être autonome

Le niveau de contrôle nécessaire dépend également de ce que l’entreprise fera du résultat.

Dans l’assistant documentaire de Quentin, le RAG retourne à l’agent des passages pertinents avec le document, la page et le lien d’origine. L’agent formule la réponse, mais l’utilisateur peut consulter la source et retrouver l’image associée. La vérification reste disponible au moment de la consultation.

Dans le projet de Zarah, le système participe à la production d’un livrable beaucoup plus engageant : un mémoire technique constitué de nombreuses sections et construit à partir de plusieurs pièces documentaires. Une réponse convaincante à une question isolée ne suffit plus. Il faut vérifier la cohérence du document, la pertinence de chaque information et son rattachement à une source.

« Réussir à générer un document de plus de 120 pages ne garantit pas que toutes les informations sont exactes », rappelle Zarah.

L’architecture intègre donc des citations documentaires, un signalement explicite des informations qui n’ont pas été retrouvées et une validation humaine avant l’export Word. L’objectif n’est pas d’obtenir le document le plus long ni la génération la plus autonome, mais un contenu suffisamment traçable et fiable pour être utilisé par le métier.

L’efficacité globale reste à confirmer par des évaluations métier et des tests en production. Cette limite est importante : le volume produit constitue un fait observable, pas une preuve de qualité. Le bon niveau d’autonomie ne se décide pas à partir de ce que le modèle sait générer, mais à partir des conséquences qu’aurait une information inexacte.

Les contraintes de production tranchent les arbitrages techniques

Le projet mené par Yosr montre une autre forme d’arbitrage. L’objectif était de permettre à environ 200 personnes de retrouver un intervenant adapté ou une information contenue dans les documents internes. L’environnement du client et la contrainte de délai ont conduit à retenir Vertex AI Search, un service RAG managé.

L’extraction, le chunking, les embeddings et l’indexation pouvaient ainsi être en grande partie délégués au service. Le projet a été mis en production en environ huit jours. Ce résultat ne signifie pourtant pas que l’architecture était devenue automatique. L’effort s’est déplacé vers l’ingestion, les autorisations, les métadonnées et le déploiement.

Le connecteur natif avec Google Drive a notamment été testé, puis écarté au profit d’une ingestion depuis Cloud Storage. Ce choix permettait de mieux maîtriser ce qui était indexé, à quel moment et avec quelles métadonnées. Un connecteur présenté comme prêt à l’emploi ne garantit pas qu’il répondra aux contraintes de volume, de synchronisation ou de contrôle rencontrées sur le terrain.

La gestion des droits d’accès constituait un second point critique. Tous les utilisateurs ne pouvaient pas consulter les mêmes documents. Les autorisations ont donc été intégrées aux métadonnées et appliquées au moment de la recherche, selon l’identité de la personne qui pose la question.

La distinction est déterminante : un document non autorisé ne doit atteindre ni le modèle, ni la réponse, ni les sources affichées. « Filtrer après génération ou demander au modèle d’ignorer certaines sources ne constitue pas un contrôle d’accès », insiste Yosr.

Le projet montre ainsi ce que le managé permet — accélérer le déploiement et réduire certains besoins d’infrastructure — mais aussi ce qu’il ne résout pas. Les accès cloud, les comptes de service, la sécurité documentaire et la qualité de l’ingestion restent des décisions de production. Dans ce type de projet, les prérequis d’accès peuvent même devenir le chemin critique avant la technologie RAG elle-même.

L’estimation réalisée pendant le cadrage situait le coût du moteur près de zéro à l’usage nominal, grâce aux paliers gratuits disponibles dans l’environnement retenu. Ce chiffre reste une estimation, à contrôler dans la console de facturation du client. Il illustre néanmoins un point important : le coût d’un RAG ne dépend pas uniquement du modèle. Il se joue aussi dans l’architecture, l’hébergement, l’ingestion, le contrôle des accès et la capacité à diagnostiquer les erreurs.

La production ne commence pas après le prototype

Les difficultés qui apparaissent en production sont rarement des ajouts périphériques. Elles sont souvent la conséquence de décisions repoussées pendant la conception.

Un index construit une fois pour une démonstration devient obsolète si aucun mécanisme de synchronisation n’a été prévu. Des droits absents des métadonnées peuvent imposer une réindexation complète. Une recherche uniquement sémantique peut sembler convaincante sur des questions générales et échouer sur des références produit, des codes ou des noms exacts. Une réponse sans source empêche l’utilisateur de distinguer une information retrouvée d’une formulation simplement plausible.

La production commence donc dès la façon dont les documents entrent dans le système. Dans le projet de Quentin, un traitement nocturne détecte les fichiers modifiés afin de ne relancer l’ingestion que lorsque cela est nécessaire. La recherche hybride combine similarité sémantique et mots-clés pour mieux traiter les termes techniques exacts. Dans l’architecture de référence de Yosr, les questions, les passages récupérés, la latence et les coûts doivent être suivis dès le départ. Chez Zarah, la séparation des composants et la validation humaine permettent de localiser plus facilement l’origine d’une erreur.

Cette observabilité est essentielle, car une bonne formulation peut masquer une mauvaise recherche. Lorsqu’un RAG répond mal, le premier réflexe ne devrait pas être de changer de LLM, mais d’examiner les passages qui lui ont été fournis. La recherche et la génération doivent pouvoir être évaluées séparément.

Concevoir pour la production ne signifie pas construire immédiatement l’architecture la plus sophistiquée. Le projet de Quentin assume au contraire un périmètre initial réduit, qui pourra évoluer à partir des résultats de l’évaluation. Cela signifie anticiper ce qui sera difficile ou coûteux à ajouter plus tard : la mise à jour des documents, les droits d’accès, la traçabilité, la modularité et les mécanismes de contrôle.

Partir de ce qui doit fonctionner, pas de ce qui est disponible

Les trois expériences conduisent à la même conclusion : une architecture RAG ne devrait jamais commencer par une liste d’outils.

Elle commence par les documents tels qu’ils existent réellement, y compris leurs tableaux, leurs images, leurs doublons et leurs défauts de classement. Elle dépend ensuite du risque métier associé à une mauvaise réponse : simple aide à la recherche, contenu à vérifier ou livrable engageant. Elle doit enfin tenir compte des conditions quotidiennes d’exploitation : mises à jour, droits, coûts, hébergement, maintenance et capacité à comprendre les erreurs.

C’est ce qui explique que deux entreprises ne devraient pas construire le même RAG. Non parce que chaque projet exigerait une architecture entièrement originale, mais parce que les mêmes briques ne produisent de valeur qu’une fois ajustées au corpus, à l’usage et aux contraintes de production.

Le bon RAG n’est donc pas celui qui accumule le plus de composants. C’est celui dont les arbitrages techniques rendent le service attendu plus fiable, plus sûr et réellement exploitable par les équipes.

Cet article ouvre une série consacrée au RAG en production. Les prochains volets approfondiront les décisions qui séparent un prototype convaincant d’un système durable. Ces travaux nourriront également un livre blanc plus opérationnel, conçu comme une boîte à outils pour cadrer, évaluer et industrialiser un projet RAG.