RAG souverain : le modèle compte moins que vos documents

Le principe du RAG (Retrieval-Augmented Generation) est simple : au lieu de compter sur ce que le modèle a mémorisé pendant son entraînement, on va chercher les passages pertinents dans vos documents et on les lui fournit au moment de répondre. L'idée a été formalisée dès 2020 et est devenue l'architecture par défaut de toute IA d'entreprise sérieuse, parce qu'elle règle d'un coup trois problèmes : l'obsolescence des connaissances, l'impossibilité de citer ses sources, et la nécessité de garder les données hors du modèle.

Mais « aller chercher les passages pertinents » recouvre une chaîne de sept maillons. Chacun peut casser silencieusement, et l'utilisateur ne verra qu'une chose : une réponse à côté de la plaque, formulée avec aplomb.

1. Le découpage : la décision la plus sous-estimée

Un document n'entre pas entier dans le contexte du modèle : on le fractionne en passages. La taille de ces passages détermine tout le reste.

Trop petits, ils perdent leur contexte : un paragraphe isolé qui commence par « Dans ce cas, le délai est porté à deux mois » ne dit plus de quel cas il s'agit. Trop grands, ils diluent l'information utile dans du remplissage, et le passage cesse d'être discriminant à la recherche.

Le vrai gain n'est pas dans le réglage d'un nombre de caractères, mais dans le respect de la structure du document : découper aux titres et sous-titres plutôt qu'à l'aveugle, ne jamais casser un tableau, prévoir un léger recouvrement entre passages consécutifs, et surtout rattacher à chaque passage l'en-tête de sa section. Un extrait de délibération qui se souvient qu'il appartient au chapitre « Urbanisme » de la séance du 12 mars vaut dix extraits anonymes.

Chaque passage doit aussi porter ses métadonnées : source, date, direction émettrice, niveau de confidentialité. Elles serviront au filtrage, à la citation, et aux droits d'accès.

2. Les embeddings : le maillon francophone

Un modèle d'embedding convertit un texte en vecteur numérique, de sorte que deux textes de sens proche se retrouvent proches dans l'espace. C'est ce qui permet à « Quelles pièces pour un permis de construire ? » de retrouver un document intitulé « Composition du dossier de demande d'autorisation d'urbanisme », sans qu'aucun mot ne soit commun.

Deux points de vigilance pour un déploiement français :

• Le multilingue n'est pas optionnel. Beaucoup de modèles d'embedding sont excellents en anglais et médiocres sur le français administratif, ses sigles et ses formulations juridiques. Ce choix se teste sur vos documents, pas sur un classement générique.
• Changer de modèle d'embedding oblige à tout réindexer. Les vecteurs d'un modèle ne sont pas comparables à ceux d'un autre. C'est une décision d'architecture, pas un paramètre qu'on ajuste en cours de route, d'où l'intérêt de la trancher pendant le pilote.

3. Le re-ranking : le maillon qui fait la différence

La recherche vectorielle est rapide mais approximative : elle compare des vecteurs calculés séparément pour la question et pour chaque passage. Résultat, elle ramène volontiers dix passages « du bon sujet », dont deux seulement répondent réellement.

Le re-ranking corrige cela. Un second modèle, un cross-encoder, qui lit la question et le passage ensemble, rescore les candidats et ne garde que les meilleurs. C'est plus coûteux, donc on ne l'applique qu'à une vingtaine de passages présélectionnés, pas à toute la base.

L'effet est double : le passage utile remonte en tête, et surtout le contexte envoyé au modèle est plus court et plus propre. Moins de bruit, c'est moins d'hallucination et moins de tokens à traiter, donc aussi moins de VRAM et plus de débit. C'est la raison pour laquelle notre pile de production intègre un reranker BGE entre la récupération et le LLM.

4. Les droits d'accès : le risque que personne ne teste

C'est le point le plus grave et le moins souvent traité dans les projets pilotes. Un index vectoriel construit « sur tout le lecteur réseau » est une machine à faire remonter, à n'importe quel agent, un compte rendu d'entretien annuel, une note RH ou un dossier disciplinaire, parce que le passage était pertinent au regard de la question posée.

La règle est simple : les droits s'appliquent à la récupération, pas à la réponse. Filtrer après coup, en demandant au modèle de « ne pas divulguer », n'est pas un contrôle d'accès, c'est une politesse. Le filtre doit être appliqué dans la requête à l'index, à partir de l'identité de l'utilisateur et des métadonnées de chaque passage.

C'est aussi une exigence de conformité : le RGPD impose une minimisation qui se joue précisément ici, et le raisonnement complet est détaillé sur notre page IA & RGPD et dans nos garanties de sécurité.

5. L'évaluation : on n'améliore que ce qu'on mesure

La plupart des chaînes RAG sont réglées « au ressenti » : on pose trois questions, ça a l'air mieux, on garde. Ce n'est pas tenable dès qu'il y a plusieurs paramètres en jeu.

La méthode qui fonctionne tient en une phrase : constituer un jeu de questions de référence. Entre 50 et 100 questions réellement posées par les utilisateurs, chacune associée au document qui contient la réponse. Ce jeu se construit une fois, avec les métiers, et devient l'étalon de toutes les décisions techniques qui suivent.

Trois indicateurs suffisent :

• Le taux de récupération : dans combien de cas le bon document figure-t-il parmi les passages retenus ? Si ce chiffre est bas, aucun modèle au monde ne rattrapera le coup.
• La fidélité : la réponse est-elle entièrement soutenue par les passages fournis, sans ajout inventé ?
• Le taux de citation : la réponse renvoie-t-elle à une source vérifiable par l'utilisateur ?

Avec ce jeu, chaque modification, un nouveau découpage, un autre modèle d'embedding, l'ajout du re-ranking, devient une mesure et non une opinion.

6. Et le modèle, alors ?

Il arrive en dernier, et c'est une excellente nouvelle. Quand la chaîne de récupération fait correctement son travail, la tâche demandée au modèle se réduit à : lire trois à cinq passages, en extraire la réponse, la formuler clairement et citer d'où elle vient. C'est une tâche de synthèse, pas de connaissance encyclopédique.

Un modèle open weight de l'ordre de 24 milliards de paramètres y suffit très largement, c'est ce que nous exploitons en production, et le sujet du choix est traité en détail sur notre page Modèles LLM. Cela change complètement l'économie du projet : plus besoin du plus gros modèle du marché, donc plus besoin de l'API d'un hyperscaler, donc la souveraineté devient abordable. Le dimensionnement matériel correspondant se calcule avec notre calculateur de VRAM.

Ce qu'il faut retenir

Si un projet d'IA interne déçoit, le réflexe « changeons de modèle » est presque toujours le mauvais. Dans l'ordre, il faut d'abord vérifier que les documents sont correctement extraits, que le découpage respecte leur structure, que la récupération remonte le bon passage, et qu'un re-ranking nettoie le contexte. Le modèle n'est que le dernier maillon, et de loin le plus facile à remplacer.

C'est aussi ce qui rend le RAG compatible avec la souveraineté : vos documents ne servent jamais à entraîner quoi que ce soit, ils restent dans un index que vous maîtrisez, et une donnée retirée de l'index disparaît de l'IA le jour même.