Legirag

La démonstration

Le problème

Un modèle de langage interrogé sur une question de droit produit une réponse plausible et difficile à vérifier. Trois faiblesses reviennent. Il cite des articles de mémoire, sans garantie qu'ils existent sous cette forme. Il ignore la date de vigueur, alors qu'un texte abrogé ou pas encore applicable donne une réponse fausse. Et il ne suit pas les renvois.

Les articles de droit comportent des renvois, parfois vers un autre code. Il faut suivre ces renvois pour retrouver les règles utiles à la réponse. La vitesse maximale sur autoroute en est un bon exemple. L'article du code de la route qui porte la limitation ne définit pas ce qui constitue juridiquement une autoroute ; cette définition vit dans le code de la voirie routière. Une réponse qui s'arrête au premier article laisse de côté la règle décisive.

Chaque affirmation de la réponse doit renvoyer à un article retrouvé dans le corpus. Le modèle désigne ses sources par leur index dans la liste fournie. Ce rattachement garantit que la source existe dans le corpus ; il ne garantit pas la justesse de l'interprétation qui en est faite.

Le trajet d'une question

L'agent est un graphe de quatre étapes exécutées dans un ordre fixé par le code.

route. Un premier appel au modèle détermine le ou les codes juridiques concernés par la question.

search. La question est transformée en vecteur, puis deux recherches partent dans Postgres : l'une par mots-clés, l'autre par proximité de sens. Les cinquante premiers résultats de chaque côté sont fusionnés par pondération de rang réciproque, filtrés, et une vingtaine d'articles remontent à l'agent.

draft. Le modèle rédige la réponse sans produire les citations. Il désigne chaque source par son index dans la liste qui lui a été fournie, et le code substitue ensuite la citation réelle. Si un index ne correspond à aucune source fournie, la rédaction est relancée, deux fois au maximum, après quoi l’agent s’abstient explicitement.

followRenvois. Si un article cité renvoie à un texte non encore couvert, l'agent va le chercher et relance une rédaction avec la source complémentaire. La boucle est bornée à deux passages.

Sur la question de vitesse évoquée plus haut, le routage retient le code de la route, la recherche remonte l'article portant la limitation, le suivi de renvois va chercher la définition dans le code de la voirie routière, et la réponse finale s'appuie sur les deux textes.

Deux modèles se partagent le travail. Un modèle rapide traite le routage et la première rédaction ; un modèle plus capable prend le relais quand la question demande plusieurs renvois ou davantage de rigueur.

Deux garde-fous structurels

Le premier tient dans le schéma de sortie. La réponse est validée contre une structure qui encode des règles métier : une abstention doit obligatoirement porter l'indication de ce qui manque et de vers qui escalader ; une réponse qui ne s'abstient pas doit obligatoirement citer une règle principale. Une réponse qui viole ces règles est rejetée avant l'affichage.

Le second est dans la base de données. La sécurité au niveau des lignes de Postgres filtre ce qu'une requête a le droit de voir, indépendamment du code qui l'a écrite. Un article abrogé, hors de sa fenêtre de validité, ou hors du périmètre retenu au routage, ne remonte jamais. Le filtrage tient donc à la base elle-même, quelle que soit la requête posée au-dessus.

Ce que la démonstration donne à voir

Chaque étape de l'agent s'affiche pendant qu'elle s'exécute, et reste consultable ensuite sur une page de trace : les codes retenus, les articles remontés, les renvois suivis, les tokens consommés par appel.

Le coût est calculé à partir de l'usage réel. Chaque appel porte l'identifiant exact du modèle qui l'a traité, converti en dollars via une table de prix vérifiée auprès de l'API de tarification du fournisseur. Un modèle absent de cette table reste sans coût attribué.

Un niveau de détail supplémentaire, prompts complets et réponses brutes, est capturable pendant une question mais reste dans le navigateur qui l'a posée. Il n'est jamais envoyé au serveur : le projet n'a pas de comptes utilisateurs, et une page de trace se partage par son URL.

En parallèle, chaque appel modèle ou outil est instrumenté selon une convention ouverte (OpenTelemetry), exportable vers un outil d'observabilité si des identifiants sont configurés. Sans clés, rien ne sort.

Les mêmes outils, hors de l'interface

Cinq outils sont opérationnels : recherche dans le corpus, suivi d'un renvoi, routage d'une question, calcul déterministe (jamais confié au modèle) et escalade explicite vers un humain. Trois autres sont déclarés dans le protocole sans être encore implémentés.

Ces outils sont exposés par un serveur MCP (Model Context Protocol) en plus de l'interface web. Un client compatible peut donc brancher sa propre logique sur le corpus juridique sans rien connaître du code interne.

Déploiement

Interface sur Vercel. API et serveur MCP empaquetés en conteneurs, déployés en fonctions Lambda. Infrastructure décrite en Terraform et reproductible depuis zéro, secrets en gestionnaire dédié, permissions réduites au nécessaire. Tests unitaires, tests de bout en bout et suite d'évaluation exécutés en intégration continue, la suite d'évaluation bloquant la fusion en cas de régression.

Stack

Modèles : Claude Haiku 4.5 et Sonnet 5, via Amazon Bedrock.

Mesurer chaque étape séparément

Une chaîne de ce type pose une difficulté propre : quand la réponse finale est mauvaise, l'erreur peut venir de l'ingestion, du découpage, de la recherche ou de la rédaction. Chaque étape a donc sa mesure, indépendante des autres.

Ingestion. L'extraction des renvois entre articles est évaluée sur un échantillon de cinquante renvois annotés à la main : 0,90 de précision, 0,85 de rappel, revérifiés en distribution sur les 157 174 articles retenus avant tout chargement en base. Une extraction fausse casserait le suivi des renvois sans rien signaler.

Découpage. Préfixer chaque fragment de texte par son code et son chemin hiérarchique avant de le vectoriser fait passer la proportion de questions dont le bon article ressort en tête de 0,625 à 0,875, et le rang réciproque moyen de 0,75 à 0,90, comparé à un découpage naïf.

Recherche. La recherche hybride, mesurée sur le même échantillon, n'apporte rien par rapport à la recherche vectorielle seule. Elle est conservée quand même : une question de droit contient souvent un numéro d'article exact que le vectoriel seul rate, et l'échantillon est trop petit pour trancher. Le gain mesuré est donc nul, et la décision de la garder repose sur un cas que l'échantillon ne couvre pas.

Agent. Sur quinze questions annotées, le bon code est retenu dans tous les cas, la couverture des renvois obligatoires est complète, et la décision de s'abstenir est correcte dans 80 % des cas. Les échecs restants portent sur des questions à fausse prémisse, où l'agent répond au lieu de signaler que la question elle-même ne tient pas. L'échantillon reste petit ; il vaut comme plancher vérifiable, rejoué automatiquement à chaque contribution, une régression bloquant la fusion.

Ce qui n'est pas construit

Un reclassement dédié des résultats de recherche était prévu pour affiner l'ordre final avant lecture par l'agent. Il n'est pas branché.

La recherche s'appuie sur Postgres et son extension vectorielle plutôt que sur un moteur de recherche vectorielle dédié. Une seule base porte le texte et les vecteurs, et l'accès à la recherche est isolé derrière un contrat qui permettrait d'en brancher un autre.

La réindexation, quand le texte d'un article change, passe par un déclencheur Postgres alimentant une file en base, drainée par un script. Le plan initial prévoyait une chaîne de services événementiels managés. L'événement réel étant un changement dans la base, un mécanisme natif de la base s'est révélé plus direct.

La démonstration publique indexe cinq codes (civil, pénal, consommation, route, impôts), pour tenir dans un hébergement gratuit. Le pipeline d'ingestion traite les 73 codes du corpus.