On parle partout de Retrieval-Augmented Generation, presque toujours de la même manière : on prend un modèle de langage, on lui « branche » les documents de l'entreprise, et dès lors il répond en citant ses sources. La réalité, comme souvent, est plus intéressante que la brochure.
Nous le savons parce qu'une plateforme RAG, nous l'avons réellement construite et mise en exploitation — entièrement on-premise, sur du matériel dans notre périmètre, avec des modèles ouverts. Elle est aujourd'hui le socle d'ACME ECMS IA & RAG Integration, et vous trouverez sur la page dédiée les schémas de l'infrastructure et une démo de son fonctionnement. Ici, en revanche, nous racontons ce que les schémas ne disent pas : les cinq leçons qui ont changé notre façon de concevoir ces systèmes.
1 · La qualité se joue dans le retrieval, pas dans le modèle
La tentation, quand on débute, est de se concentrer sur le modèle : quel LLM, combien de paramètres, quelle version. C'est la mauvaise partie du problème. Si les étapes qui récupèrent les documents apportent au modèle le mauvais contenu, le modèle le plus puissant du monde ne fera qu'une seule chose : bien résumer la mauvaise chose.
Le vrai travail se situe en amont : comment on découpe les documents (le chunking), avec quelles représentations on les indexe (les embeddings), et surtout quelle structure on donne à la base de connaissances. Dans notre plateforme, à côté de l'index vectoriel vit un knowledge graph : des entités et des relations extraites des documents, qui permettent de répondre aussi à des questions qui traversent plusieurs documents — là où la seule similarité sémantique ne suffit pas.
2 · Récupération hybride plus re-ranking : deux étapes, pas une
Une seule passe de recherche doit choisir entre deux objectifs contradictoires : ne rien perdre de pertinent et ne pas laisser passer de bruit. La solution qui a fonctionné pour nous est de les séparer.
La première étape est large et hybride — vecteurs, mots-clés et graphe ensemble — et optimisée pour le rappel : mieux vaut un candidat de trop qu'un de moins. La seconde étape est un re-ranker, un modèle dédié qui réordonne les candidats selon leur pertinence réelle par rapport à la question, et écarte ce qui ressemble mais ne répond pas. C'est l'un des composants qui a le plus élevé la qualité perçue des réponses : les sources citées cessent d'être « proches du sujet » et commencent à être les bonnes.
3 · Toutes les questions ne méritent pas le RAG
Une erreur courante consiste à traiter chaque requête de la même manière : quoi que demande l'utilisateur, on lance toute la pipeline — recherche, re-ranking, génération avec contexte. Le résultat : des réponses lentes et coûteuses même quand rien de tout cela n'était nécessaire.
Dans notre architecture, la première décision revient à un planner : un composant qui classifie la requête et choisit la voie. Une salutation ou une question de culture générale prennent la voie directe, sans toucher à la base documentaire; une question sur les contrats, les procédures ou les projets active la pipeline complète. Cela ressemble à un détail : en exploitation, c'est la différence entre un système qui « répond quand il peut » et un service aux latences et consommations prévisibles.
4 · Sans métriques, vous ne faites que deviner
Vous changez le modèle d'embedding et les réponses « semblent » meilleures. Vous revoyez le chunking et elles « semblent » moins bonnes. Semblent à qui? Sur quelles questions? Le ressenti de celui qui développe n'est pas une métrique, et sur un système qui répond en langage naturel, l'œil s'habitue vite.
C'est pourquoi la plateforme inclut une évaluation systématique de la qualité (nous utilisons le framework RAGAS, avec un jeu d'essai construit en italien sur nos cas d'usage) : à chaque modification, nous mesurons à quel point les réponses restent fidèles aux sources, à quel point elles sont pertinentes par rapport à la question et quelle est la qualité du contexte récupéré. C'est le même principe que notre méthode — mesurer, analyser, améliorer, vérifier — appliqué à l'IA : chaque intervention part d'un chiffre et revient à un chiffre.
La bonne question n'est pas « l'IA répond-elle bien? », mais « par rapport à quoi, mesuré comment, et mieux ou moins bien qu'hier? ».
5 · L'on-premise est faisable — et parfois c'est la seule voie
La leçon peut-être la plus contre-intuitive : pour un RAG d'entreprise, pas besoin d'un hyperscaler. Des modèles ouverts sur des GPU dimensionnés pour le cas d'usage, au sein d'une infrastructure gouvernée, couvrent la très grande majorité des besoins réels — et apportent un avantage qu'aucune API distante ne peut offrir : les données ne quittent jamais le périmètre.
Pour des secteurs entiers, ce n'est pas un caprice, c'est une exigence. Dans la Santé, les données relatives à la santé bénéficient de la protection renforcée de l'art. 9 du GDPR; dans l'Administration publique, la souveraineté des données et les orientations sur le cloud pèsent lourd. Une architecture on-premise (ou sur cloud privé en Italie) résout le problème à la racine — et, avec des modèles ouverts, élimine aussi le vendor lock-in.
L'autre moitié de la leçon : un tel système doit être géré comme un service, pas comme une expérimentation. Supervision des composants, sauvegarde de la base de connaissances, mises à jour contrôlées des modèles : la partie « exploitation » compte autant que la conception.
Par où commencer
S'il fallait condenser les cinq leçons en un seul conseil : commencez petit, mais commencez en mesurant. Un cas d'usage concret, un corpus documentaire défini, des métriques de qualité dès le premier jour — et une architecture qui ne vous oblige pas à choisir entre innover et garder vos données à leur place.
Comment notre plateforme est construite — schémas d'infrastructure, flux logique et démo animée du cycle de vie — est raconté sur la page IA, Agents et RAG. Et si vous voulez comprendre ce qu'elle pourrait faire sur votre patrimoine documentaire, parlons-en.
