Petit modèle, grande rigueur : comment l'ingénierie fait d'un LLM compact européen un système de RAG agentique souverain de niveau production

Le RAG est souvent présenté comme une solution capable de transformer instantanément n'importe quel corpus documentaire en un assistant omniscient. Si vous avez un tant soit peu testé cette approche, vous le savez : la réalité est tout autre. Un RAG costaud, qui donne de bons résultats, c'est possible, mais cela repose sur une ingénierie rigoureuse. Surtout quand les contraintes s'accumulent.

C'est en embrassant des contraintes fortes — souveraineté, transparence et maîtrise totale de l'infrastructure — que nous avons conçu un système RAG agentique de niveau industriel pour un client exigeant. Cet article partage ce retour d'expérience : comment, loin des effets d'annonce, nous avons transformé un défi complexe en une architecture performante et souveraine, dont chaque progrès est validé par la mesure.

Le vocabulaire du RAG

• RAG (Retrieval-Augmented Generation) : technique qui, avant de faire répondre un modèle de langage, va d'abord chercher les passages pertinents dans un corpus documentaire et les fournit comme contexte.
• Chunk / chunking : découpage d'un document en fragments de taille maîtrisée (ici de l'ordre de 512 tokens), unités de base de la recherche.
• Embedding : représentation mathématique (un vecteur) d'un chunk, qui permet de mesurer la proximité de sens entre deux textes en comparant leurs vecteurs.
• Index vectoriel : base de données de ces vecteurs, interrogeable pour retrouver les chunks les plus proches d'une question.
• Retrieval : l'étape de recherche documentaire proprement dite.
• Reranking : réordonnancement fin des chunks candidats par un modèle spécialisé, après une première recherche large.
• Cross-encoder : modèle de reranking qui lit ensemble la question et un document pour noter leur pertinence ; précis mais coûteux.
• Hybrid search : combinaison d'une recherche par mots-clés et d'une recherche vectorielle par le sens.
• Query rewriting : reformulation automatique de la question de l'utilisateur pour améliorer la recherche.
• LLM-as-a-judge : usage d'un modèle de langage pour noter la qualité ou la pertinence d'un résultat.
• RRF (Reciprocal Rank Fusion) : méthode statistique robuste qui fusionne plusieurs classements en un seul.
• CRAG (Corrective RAG) : variante de RAG où le système évalue lui-même ce qu'il a trouvé et relance une recherche si c'est insuffisant.
• TTFT (Time to First Token) : délai avant que l'utilisateur ne voie apparaître le premier mot de la réponse.

---

Acte I — La fabrique souveraine : ingérer 10 000 documents sans perdre une page

Tout système de RAG (Retrieval-Augmented Generation : génération augmentée par la recherche documentaire) vaut d'abord ce que vaut son corpus. Avant d'optimiser la moindre requête, il faut résoudre un problème industriel : faire entrer des milliers de documents hétérogènes — PDF, pages web, forums, fiches pratiques — dans un index interrogeable, et les y maintenir à mesure que les sources vivent.

Nous avons conçu ce pipeline d'ingestion comme une usine : chaîne orchestrée, files d'attente, reprise automatique sur incident.

Chaque document traverse une séquence d'étapes orchestrée : chargement → parsing (extraction du texte) → détection de langue → résumé → chunking (découpage en fragments) → contextualisation → embedding (vectorisation) → persistance → extraction de concepts → indexation vectorielle. L'ensemble est exécuté par une flotte de workers asynchrones : des processus de traitement indépendants, alimentés par une file d'attente qui leur distribue le travail.

Deux étapes en particulier :

• Le contextual chunking. Un chunk de 512 tokens extrait de la page 40 d'un rapport perd son sens hors de son document. Avant embedding, chaque chunk est enrichi d'un contexte généré : de quel document il vient, de quoi parle la section. Cette technique améliore mesurablement le retrieval en aval.
• L'indexation multilingue par document. Un corpus réel mélange français et anglais. La langue de chaque document est détectée à l'ingestion et pilote son analyse lexicale — la façon dont les mots sont ramenés à leur racine (stemming) selon la morphologie de la langue —, plutôt qu'un réglage global forcément approximatif.

Le self-healing comme principe. À cette échelle, des échecs ponctuels sont une certitude statistique : un PDF corrompu, un pic de charge, une coupure réseau. La différence entre un prototype et une plateforme, c'est ce qui se passe ensuite :

• Tout traitement qui échoue définitivement part en dead-letter : marqué, visible, jamais perdu en silence.
• Un sweeper périodique détecte les documents restés bloqués en cours de route et les remet en file automatiquement. Aucun document ne reste abandonné : c'est une garantie du système.
• Les synchronisations continues avec les sources externes sont protégées par un circuit breaker anti-suppression massive : si une source amont signale soudainement la disparition d'une fraction anormale du corpus — panne ou erreur de configuration chez le fournisseur —, la plateforme refuse de propager la suppression et alerte, au lieu d'amputer l'index.
• La ré-ingestion d'une base entière se fait en zero-downtime : chaque document est remplacé automatiquement, l'index reste interrogeable pendant toute l'opération.

Et l'ensemble tourne dans le périmètre d'infrastructure choisi par l'organisation : la souveraineté ne se joue pas seulement sur le modèle de langage, elle se joue sur toute la fabrique, de la collecte des sources à l'index vectoriel.

Acte II — La campagne d'optimisation : mesurer la physique, puis frapper juste

Un corpus sain ne suffit pas. Le cœur du système est un workflow agentique : la recherche documentaire n'y est pas un simple appel à un moteur, mais un graphe capable de boucler et de s'auto-corriger.

query rewriting → hybrid search → reranking → grading → (si insuffisant : refine ciblé, nouvelle recherche) → synthèse citée

Un superviseur décide à chaque tour s'il faut interroger le corpus ; le sous-graphe de recherche évalue lui-même la qualité de ce qu'il trouve et peut relancer une recherche affinée avant de s'engager. Cette boucle corrective — le pattern Corrective RAG (CRAG) — est documentée dans la littérature scientifique. La durcir pour la production sur un modèle compact est une autre affaire.

1. Protéger les signaux à haute précision. Question réelle d'utilisateur : « que dit le critère 2.7 ? » du référentiel interne. Le document existe, il est indexé, et la recherche le classait en 3 952ᵉ position, noyé sous des documents génériques. Cause profonde : les termes les plus discriminants d'une question (numéro de critère, référence, sigle rare) sont précisément ceux que les moteurs diluent. Notre mécanisme — original par rapport aux piles RAG standard — détecte automatiquement les identifiants et les termes rares du corpus grâce à une projection de document frequency (DF) maintenue en continu, les rend obligatoires dans une branche de recherche dédiée, et fusionne le tout. Résultat mesuré : le document cible passe de la 3 952ᵉ à la 2ᵉ position.

2. Rétrograder le juge. Avant la rédaction, un modèle de langage note la pertinence de chaque chunk retrouvé : le fameux LLM-as-a-judge, standard de l'industrie. Nos mesures ont révélé un phénomène contre-intuitif : sur un modèle compact, un juge qui répond proprement peut être plus nuisible qu'un juge qui échoue, car son jugement médiocre s'applique alors réellement, jusqu'à écarter le chunk qui contenait la réponse. Notre réponse est architecturale : les meilleurs résultats selon un signal statistique robuste (la Reciprocal Rank Fusion, RRF) survivent toujours au filtrage ; l'avis du modèle ne sert plus qu'à promouvoir ce dont il est très sûr, jamais à opposer un veto. À contre-courant de l'orthodoxie LLM-as-a-judge, cette inversion a fait passer la précision du contexte transmis au modèle de 15 % à 40 %.

3. Mesurer le coût réel avant d'optimiser. Le reranking final par cross-encoder — un modèle qui lit ensemble la question et chaque document pour les noter — apportait le plus de pertinence, mais pesait jusqu'à 80 % du temps de réponse. Plutôt que d'empiler des optimisations plausibles, nous avons mesuré : coût linéaire au nombre de paires question-document, indépendant de leur longueur. Cette seule mesure a disqualifié plusieurs fausses bonnes idées (tronquer les textes, cascader deux étages) et désigné les deux vraies : un cache de scores adressé par contenu (content-addressed : aucun recalcul de ce qui a déjà été évalué) et le passage sur GPU. Résultat : un reranking 4 à 5 fois plus rapide, et une latence de bout en bout ramenée de 31,5 s à 18,9 s en médiane (−40 %).

Cette campagne a aussi forgé une règle que nous appliquons désormais partout : un seuil de décision n'est jamais une constante universelle, c'est une propriété du modèle qui l'a produit — tout changement de composant impose une recalibration. C'est le genre de rigueur qui ne se voit pas dans une démonstration, et qui fait toute la différence en production.

Acte III — La validation : prouver le workflow par la mesure

C'est la partie dont nous sommes le plus fiers, parce qu'elle est la moins spectaculaire et la plus décisive. Aucune des optimisations ci-dessus n'a été « conçue puis livrée ». Chacune est née d'une trace, a été contredite ou confirmée par un benchmark, et n'a été retenue qu'une fois prouvée.

Tracing intégral du raisonnement. Chaque exécution est tracée étape par étape : chaque nœud du graphe (query rewriting, search, reranking, grading, synthèse) émet son span horodaté, avec ses entrées, ses sorties et son coût. Quand un comportement intrigue, nous ne spéculons pas : nous lisons la trace et la comparons à une trace de référence saine. C'est ainsi qu'ont été établis, preuves à l'appui, les diagnostics les plus fins de la campagne, y compris ceux qui ont réfuté nos propres hypothèses initiales.

Des benchmarks rejoués, systématiquement. Deux jeux de questions de référence — un benchmark interne de 40 questions et un benchmark de 95 questions construit sur les usages réels du client — sont rejoués sur chaque version candidate, avec scoring systématique (mécanique puis LLM judge indépendant), analyse par nœud (routage, déclenchement des boucles correctives, temps par étape) et comparaison stricte à la version précédente. Une amélioration qui ne survit pas au benchmark n'est pas une amélioration ; une régression détectée au benchmark ne part jamais en production. Le socle logiciel suit la même exigence : plus de 2 300 tests automatisés verrouillent chaque brique.

C'est ce protocole, et lui seul, qui autorise les chiffres suivants :

Indicateur	Avant	Après
Réussite sur le jeu de questions de référence du client	instable	100 %
Questions sans échec critique (benchmark de 95 questions)	~72 %	99 %
Précision du contexte documentaire transmis au modèle	15 %	40 % (+167 %)
Latence end-to-end (médiane)	31,5 s	18,9 s (−40 %)
TTFT (Time to First Token) (médiane)	18,5 s	2,5 s (−86 %)
Vitesse de reranking	référence	×4 à ×5
Fiabilité du grading	~3 %	~100 %
Classement du document cible sur question à référence précise	3 952ᵉ	2ᵉ

Le pari souverain, tenu

Rappelons le choix de départ : le modèle qui rédige les réponses est Mistral Small, un modèle ouvert européen, compact, déployé sur une infrastructure maîtrisée, et non un modèle géant consommé en boîte noire. La chaîne est souveraine de bout en bout : modèle européen open weights, moteur vectoriel et base de données open source, hébergement sur le cloud européen OVHcloud, données qui ne quittent jamais le périmètre défini. Le déploiement lui-même est souverain : piloté en GitOps, l'état complet de la plateforme est décrit dans un dépôt Git versionné et réconcilié en continu sur le cluster Kubernetes — auditable, reproductible, réversible, sans dépendance à une console propriétaire.

Ce choix a une conséquence technique profonde : un modèle compact ne pardonne rien. Un modèle géant « rattrape » souvent une chaîne médiocre par sa seule puissance ; un modèle compact tel que celui utilisé ici expose chaque maillon faible et force à le corriger pour de bon. Chacune des optimisations racontées ici est un maillon que cette exigence a révélé. C'est précisément pour cela que le résultat est robuste : rien, dans cette chaîne, ne repose sur l'espoir que le modèle compensera.

La souveraineté n'a donc pas été le prix à payer contre la qualité. Elle a été la contrainte qui a produit la qualité, et chaque amélioration bénéficie mécaniquement à tout modèle qu'on y branche, y compris les plus grands.

Ce qui est réellement différenciant

Par honnêteté intellectuelle, distinguons la bonne ingénierie de l'avance réelle :

1. Le juge rétrogradé au rang de départage. À contre-courant de la pratique LLM-as-a-judge dominante : le verdict d'un modèle ne peut jamais opposer de veto à un signal statistique fiable. Validé en production par un quasi-triplement de la précision.
2. La recherche ancrée pilotée par la rareté. Détection automatique des termes discriminants du corpus, rendus obligatoires dans la recherche — un mécanisme absent des piles RAG standard, décisif sur les questions précises, celles où l'erreur coûte le plus cher.
3. L'usine d'ingestion self-healing. Sweep automatique des documents bloqués, circuit breaker anti-suppression massive, ré-ingestion zero-downtime : des garanties inscrites dans l'architecture, tenues par le système lui-même.

Le reste — hybrid search, boucle corrective, reranking GPU, caches — relève de l'état de l'art bien exécuté. C'est la combinaison qui produit le résultat : rigueur sur les fondamentaux, inversions originales là où l'orthodoxie échoue, et preuve par la mesure à chaque étape.

Ce que cela signifie pour votre organisation

• La souveraineté est un avantage opérationnel. Un modèle ouvert européen, une infrastructure maîtrisée, et 100 % de réussite sur les questions réelles d'un client, dans le même système.
• La fiabilité est une propriété du système. Ingestion self-healing, décisions déterministes, boucles correctives bien armées : les gains décisifs sont architecturaux.
• Exigez des chiffres. Un fournisseur d'IA doit pouvoir montrer ses traces, ses benchmarks, et l'évolution mesurée de ses indicateurs, version après version. C'est le seul critère qui distingue une plateforme industrielle d'une démonstration réussie.

C'est la conviction qui guide notre feuille de route : ne jamais laisser un maillon échouer en silence, et ne rien affirmer qui ne soit prouvé par la mesure.