L'architecture RAG de Consia : explication simple

Pourquoi ce terme mérite un article

RAG est un acronyme qu'on voit partout dans les articles sur l'IA — rarement expliqué clairement, encore moins pour des non-techniciens. Pourtant, c'est la notion centrale qui sépare une IA « boîte noire » d'une IA « traçable ».

Cet article vulgarise le concept, détaille comment il est implémenté dans Consia, et explique ce qu'il garantit et ce qu'il ne garantit pas.

Le problème résolu par le RAG

Avant de comprendre la solution, comprenons le problème.

Un modèle de langage (LLM) comme ceux qui propulsent ChatGPT, Gemini ou Claude est entraîné sur d'immenses corpus de texte — des milliards de documents. À la fin de l'entraînement, il contient une représentation mathématique de tout ce qu'il a lu. Mais il n'a pas une « bibliothèque » qu'il peut consulter. Il a juste une intuition probabiliste de ce qu'il a vu.

Conséquence : quand vous lui demandez « Quelle est la date de l'arrêt Chronopost ? », il ne va pas chercher dans une base. Il prédit le mot le plus probable après votre question. Si son entraînement a vu l'arrêt Chronopost plusieurs fois, sa prédiction est fiable. Sinon, il invente en produisant une date plausible.

C'est pour ça que les IA généralistes hallucinent régulièrement sur les références juridiques : elles ont vu trop peu de fois les arrêts français pour s'en souvenir précisément, mais elles connaissent la forme des références. Elles produisent du texte qui ressemble.

Ce que le RAG change

Le Retrieval-Augmented Generation (littéralement : génération augmentée par récupération) introduit une étape intermédiaire.

Au lieu de demander directement au LLM « dis-moi la date de l'arrêt Chronopost », le RAG procède ainsi :

1. Comprendre la question (l'IA reformule l'intention : recherche d'une jurisprudence précise)
2. Aller chercher l'information dans une base de données externe (Légifrance, Judilibre, Wikipédia, base propriétaire…)
3. Injecter les documents récupérés dans le contexte du LLM
4. Demander au LLM de synthétiser en se basant sur ces documents

Le LLM n'invente plus — il reformule ce que la base lui a fourni. L'hallucination sur les faits est structurellement limitée.

L'architecture RAG de Consia

Détaillons ce qui se passe quand vous tapez une question dans Consia.

Étape 1 — Analyse de la question

Votre prompt est analysé par notre LLM. Il en extrait les intentions de recherche :

• Quel type de source est pertinent ? (texte, arrêt, doctrine, etc.)
• Quels filtres s'appliquent ? (dates, juridictions, mots-clés)
• Quel est le domaine juridique concerné ?

Le LLM produit une ou plusieurs requêtes structurées vers les bases officielles. Cette étape est rapide (< 500 ms) et elle ne produit pas de contenu final — juste un plan de recherche.

Étape 2 — Interrogation des bases officielles en temps réel

Consia a des connecteurs vers plusieurs sources officielles :

• Légifrance (DILA) — via l'API officielle pour les textes de loi, codes, conventions collectives Kali, journaux officiels
• Judilibre (Cour de cassation) — via l'API officielle pour les arrêts des juridictions françaises
• EUR-Lex — pour la réglementation européenne

Chaque requête envoie plusieurs appels parallèles à ces API. Le temps de réponse moyen de ces API est entre 200 ms et 1 s.

Les documents retournés sont des sources primaires : texte intégral, identifiant officiel, métadonnées (date, juridiction, chambre…), hash cryptographique permettant de vérifier l'intégrité.

Étape 3 — Sélection et injection dans le contexte

Pas tous les documents retournés ne sont pertinents. Consia applique une couche de re-ranking :

• Score de pertinence sémantique (à quel point le document répond à la question posée ?)
• Score de pertinence temporelle (un arrêt récent vaut plus qu'un arrêt obsolète)
• Score de pertinence juridictionnelle (un arrêt de la Cour de cassation vaut plus qu'un arrêt de cour d'appel sur un même point)

Les 3 à 10 documents les mieux classés sont injectés dans le contexte du LLM pour la génération finale.

Étape 4 — Synthèse finale par le LLM

Le LLM reçoit :

• Votre question originale
• Les documents officiels sélectionnés
• Un système prompt qui lui demande de citer explicitement les sources et de ne pas inventer

Il produit la réponse en s'appuyant sur les documents fournis. Il peut reformuler, structurer, synthétiser, mais ne devrait pas inventer des références absentes du contexte.

Étape 5 — Affichage des cartes de sources

C'est l'étape qui rend le RAG visible pour l'utilisateur. En parallèle de la réponse textuelle, Consia affiche dans l'interface des cartes représentant les sources officielles utilisées :

• Une carte par arrêt cité (avec identifiant Judilibre, date, chambre, lien vers Judilibre)
• Une carte par article de loi (avec identifiant Légifrance, lien)

Vous pouvez cliquer sur chaque carte pour accéder à la source primaire. En cas de doute sur la réponse textuelle, la carte fait foi.

Ce que le RAG ne garantit pas

Pour être honnête, le RAG n'est pas un bouclier absolu :

1. Le LLM peut mal interpréter un document. Si Judilibre retourne un arrêt dont le sommaire est ambigu, le LLM peut produire une synthèse légèrement déformée. La carte de source permet à l'utilisateur de détecter l'écart.

2. Le RAG dépend de la qualité de la recherche. Si la requête initiale est mal formulée et retourne des documents peu pertinents, la synthèse sera de qualité moyenne, même si les sources sont exactes.

3. Le RAG ne couvre pas les sources hors base. Un article de doctrine non disponible sur une source officielle ne sera pas récupéré. Consia ne remplace pas une bibliothèque doctrinale.

4. Le re-ranking peut se tromper. Si plusieurs arrêts sont pertinents et contradictoires, le RAG peut privilégier l'un plutôt qu'un autre. Le regard d'avocat reste nécessaire.

Ces limites sont assumées. Elles ne suppriment pas la valeur du RAG — elles définissent le périmètre dans lequel il est utile.

Les alternatives au RAG et pourquoi nous n'en avons pas choisi

1. Fine-tuning du modèle sur le corpus juridique. Technique : on ré-entraîne le LLM sur des milliers de décisions juridiques. Bénéfice : le modèle « connaît mieux » le droit français. Limite : il continue à générer, pas à consulter. Les hallucinations diminuent mais ne disparaissent pas.

2. Entraînement d'un modèle propriétaire from scratch. Technique : on entraîne un LLM dédié au droit. Limite : coûte des centaines de millions, et les modèles propriétaires spécialisés performent moins bien que les généralistes RAG-augmentés (c'est l'enseignement des benchmarks 2024-2025).

3. Bases vectorielles internes. Technique : on crée une base vectorielle des arrêts et textes de loi. Limite : il faut la maintenir à jour, avec tous les risques de désynchronisation. Les API officielles sont déjà à jour — autant les utiliser directement.

Le RAG avec API officielles en temps réel est la solution qui a le meilleur rapport qualité/coût/maintenance pour un SaaS juridique.

Pour aller plus loin

• Comment Consia évite les hallucinations — focus sur le produit
• Anonymisation des prompts : comment ça marche techniquement — le cycle de vie des données
• Tester Consia gratuitement — voir le RAG en action sur une vraie question

Le RAG n'est pas un buzzword. C'est une architecture concrète qui transforme la relation entre un avocat et une IA — d'une relation de confiance aveugle à une relation de vérification continue. Pour une profession qui vit de la preuve, cette différence est structurante.