Lex : un système de recherche juridique construit comme un RAG d’entreprise

1. En un écran

Liens réels, vérifiés le 31 octobre 2026 (HTTP 200)

• Article 50 du règlement (UE) 2024/1689 (règlement sur l’IA), en français : le libellé consolidé du 27 juillet 2026, l’obligation de transparence, avec son permalien, son empreinte et la mention « © European Union ».
• Art. 1er de la loi du 4 décembre 2019 relative à l’Office du Ducroire, dans sa version applicable au 1er janvier 2020 : le texte, son empreinte SHA-256, la source officielle (ELI) et la citation usuelle à copier.
• Le dossier de la même loi : une version détenue, et les deux versions consolidées que l’éditeur nomme et que Lex ne détient pas, dites comme telles.
• La même loi au 1er janvier 2015 : un refus typé no_version_for_date, avec history_begins 2020-01-01 et la version la plus proche. Pas de « meilleur effort », pas de page vide.
• Comparer deux dates (2020-06-01 et 2026-10-28) : les identités d’articles des deux versions et les consolidations de l’éditeur entre les dates.
• Le dossier du RGPD : expressions anglaise et française, libellé original daté, ce que l’index UE ne tient pas (titres, dates d’entrée en vigueur) dit en toutes lettres.
• Confiance et couverture : la fiche d’évaluation, servie aussi en JSON.

2. Les quatre briques, dans Lex

Brique 1 : l’analyse des documents, relationnelle

Lex lit deux formats officiels : Formex, le XML de l’Office des publications de l’UE (src/Lex.V3.Ingest/Europe/EuFormex*.cs), et Akoma Ntoso, le XML de Legilux (src/Lex.V3.Ingest/Luxembourg/LuxembourgAkn*.cs). Il ne les découpe pas en morceaux de taille fixe : il en extrait la structure dans deux index SQLite (luxembourg-index.sqlite3, europe-index.sqlite3), tables STRICT, construits deux fois et comparés octet pour octet.

Côté UE (EuropeIndexBuilder.cs) : members, articles (avec heading, wording_date, publisher_work_celex), article_sources (le paquet et l’URI officielle de chaque article), article_digests, states (chaque libellé consolidé avec la date de consolidation de l’éditeur), force_dates (entrée en vigueur, application, fin de validité, avec leur prédicat source) et corrigendum_lines. Le texte est lu une fois, à l’ingestion ; une requête lit des lignes typées, pas un PDF.

Brique 2 : l’analyse de la question, déterministe

Avant de chercher un mot, Lex lit la question comme une référence exacte (src/Lex.V3.Api/ExactReference.cs, CitationDates.cs, ArticleNumbers.cs) : un ELI, un CELEX (formes consolidées comprises), une citation au Mémorial ou au Journal officiel, une adresse du site, un acte par son type et sa date, ou la citation d’un article d’un acte à une date. Vérifié le 28 octobre : la recherche « Art. 1er de la loi du 4 décembre 2019 relative à l’Office du Ducroire Luxembourg » n’est pas cherchée mot à mot ; elle est reconnue (outcome: opens, kind: citation) et ouvre l’article ; « 32024R1689 » ouvre le dossier du règlement IA. Les numéros d’article sont lus à une clé (1er, premier et 1 sont la même ; 42 et 42bis sont deux numéros ; jamais un numéro voisin). La langue est un paramètre, pas une devinette. Aucun modèle ne reformule la question.

Brique 3 : la recherche, la structure d’abord

1. L’identifiant. resolve, dossier : l’acte ou la version qu’un identifiant exact nomme, ou identifier_unknown.
2. La version à une date. as_of, in_force_on, timeline : la version qu’une date sélectionne dans les intervalles typés ; no_version_for_date ou ambiguous_version plutôt qu’un choix silencieux.
3. L’article. evidence_bundle, article_history, diff : l’article nommé dans cette version, ou anchor_not_in_version avec les ancres voisines et do_not_fall_back_to_full_text_search: true.
4. Les mots, en dernier. search : une correspondance lexicale sur le texte des articles, dans deux voies (stricte : la phrase telle que tapée ; relâchée : chaque mot), pliée depuis le 27 octobre : accents, casse, apostrophes typographiques, espaces insécables (src/Lex.V3.Contracts/Index/TextFolding.cs), avec un extrait de 80 caractères avant et 200 après la première correspondance, dont les parties matched sont marquées sur les caractères d’origine. Il n’y a pas de base vectorielle, et la réponse le dit elle-même : modes_not_held: ["bm25", "semantic"], ranking: "none", page_is: "the first hits in the stated order, not the best hits".

Pourquoi pas de vecteurs ? Parce que la question d’un juriste porte presque toujours sur un objet identifié (cet acte, cet article, cette date), et qu’un rang par similarité y est un bruit : la fiche d’évaluation enregistre d’ailleurs un résultat négatif explicite (la recherche hybride n’est pas activée tant qu’un jeu d’or étiqueté par des personnes ne montre pas son gain ; section 4).

Brique 4 : la génération : aucune

Chaque réponse est une enveloppe (lex-v3-envelope/1) liée par empreinte au registre des opérations (registry_sha256), avec un verdict, un result typé ou un refusal typé, et un contexte qui nomme le corpus (snapshot_sha256), le code qui sert (serving_runtime_source_commit) et la fraîcheur par éditeur (age_days, maximum_data_age_days: 30). Le registre (src/Lex.V3.Contracts/Platform/V3OperationRegistry.cs) ferme l’ensemble des 27 opérations et des 20 codes de refus, chacun avec les champs que sa charge utile doit porter :

Un refus porte toujours asserts_absence_of_law: false : un trou dans Lex n’est jamais une affirmation sur le monde. Un article cité porte text_sha256, body_sha256, l’ELI officiel et un permalien qui fige la date et l’empreinte de la version ; l’opération verify rejoue ce permalien. Les champs sont vérifiés contre l’entrée : il n’y a nulle part où inventer.

3. L’assistant : un contrat de réponse typé poussé à sa limite

Le principe (spécification de référence, règles R30 à R45) : le modèle ne fait que proposer un plan. Il reçoit la question masquée (adresses électroniques, téléphones, IBAN et numéros nationaux remplacés par des points de même longueur, pour que les offsets tiennent) et des références opaques produites par les analyseurs déterministes (i1 un identifiant, d1 une date, r1 une période, a1 un article). Il rend un plan JSON d’une grammaire fermée : une ou deux parties de la question (par offsets), un verdict proposé, une à quatre étapes sur une liste blanche d’opérations (resolve, search, dossier, as_of, timeline, article_history, diff, evidence_bundle, changes_in_period), chaque argument étant un span de la question, une référence, le résultat d’une étape, un choix dans un ensemble fermé ou « aujourd’hui ». Il n’y a aucun champ de texte libre dans le plan : il ne peut pas porter de prose.

Le code valide (taille, JSON, champs connus, énumérations, liste blanche, sources admises par paramètre, spans dans les bornes et hors des masques, plafonds : au plus 6 opérations, 10 ans de comparaison, 366 jours de modifications, 5 citations de 8 000 caractères) puis exécute à travers la même dispatch que REST et MCP, de sorte que les garde-fous de périmètre et de droits s’appliquent. Puis le code, et non le modèle, calcule le verdict, biaisé vers le refus. Chaque phrase visible du dossier de réponse est l’une de trois choses :

• un gabarit relu (79 gabarits, français et anglais), rempli par du code avec des faits typés ;
• une citation textuelle avec son empreinte, son intervalle de validité, son permalien et sa source officielle ;
• un span des mots de l’utilisateur, cité tel quel.

Les verdicts, avec leurs libellés français :

• D’après le texte officiel une citation détenue et servie ;
• Non détenu par Lex : source officielle ce que Lex ne tient pas, avec le lien vers l’éditeur ; jamais une affirmation d’inexistence ;
• Il manque une précision un identifiant ou une version ambigus : une question, avec les candidats ;
• Deux questions la question se partage en deux parties de classes différentes ;
• Hors de ce que fait ce service la question demande d’appliquer le droit à une situation : la limite, en une phrase, puis le droit cité, puis vers qui se tourner.

Trois contrôles machine sont dans le chemin du code et ont chacun un contrôle d’échec délibéré : la fidélité des citations (un vérificateur indépendant relit chaque article et recalcule l’empreinte : la citation doit être la sous-chaîne exacte à son offset, seuil 1,0) ; zéro phrase hors gabarit (chaque texte visible est re-rendu depuis son gabarit, ou égal au span, ou une citation vérifiée) ; le rejeu octet pour octet de la trace sur le même instantané. Rien n’est stocké côté serveur : la trace part chez le lecteur, qui peut la rejouer. Avant l’allumage restent des choses que seules des personnes peuvent faire : une lecture juridique écrite (RGPD, règlement IA art. 50), un modèle hébergé dans l’UE sans rétention, la relecture des gabarits et du jeu d’or par un avocat luxembourgeois, un jeu de 320 questions écrites par des personnes avec un second annotateur, et la signature du propriétaire. Jusque-là : éteint, et dit comme tel.

L’assistant du guide « Vivre au Luxembourg » applique ce même contrat : réponse typée vérifiée contre le guide, passage surligné, lien, et rien d’inventé ; le modèle y est facultatif.

4. Évaluation et production

Deux publications existent. La première (v3-20261026T180319Z-8958ec5fa63f, construite le 26 octobre) est celle que le site sert le 31 octobre. La deuxième (v3-20261028T142935Z-7583e4d0032d, construite le 28 octobre à partir du commit 7583e4d0) a passé ses contrôles, a été construite deux fois à l’identique et signée ; sa promotion n’était pas enregistrée le 31 octobre. Les chiffres ci-dessous disent de laquelle ils parlent.

Les contrôles machine (fiche d’évaluation, lex-v3-evaluation-card/1)

Les cas sont dérivés de l’index monté lui-même et posés au vrai gestionnaire de requêtes, pas à une maquette. Chaque jeu est accompagné d’un contrôle par permutation : les dates sont décalées de la médiane des écarts entre dates détenues (129 jours pour le Luxembourg, 252 pour l’UE), les verdicts ou les jugements de pertinence sont mélangés avec une graine fixe ; le contrôle doit faire échouer la porte, sinon la porte ne mesure rien.

La fiche dit aussi ce qu’elle ne mesure pas : huit jeux étiquetés par des personnes (D1 à D8 : pertinence, fidélité de dérivation, refus, verdicts de l’assistant, support par span, pont lexical, temporel, accord du juge) sont not_yet_labelled et gouvernent une étape ultérieure ; et un résultat négatif est consigné : la recherche hybride « n’est pas livrée », faute de mesure sur D6, avec la condition chiffrée qui renverserait la décision (recall@10 ≥ 0,7 en anglais et en allemand, ≥ 0,5 en luxembourgeois).

Les contrôles d’une publication à l’autre : rien de perdu sans explication

Avant qu’une image soit construite, release-checks (src/Lex.V3.Ingest/Releases/) compare le montage candidat à celui de la publication qui sert, éditeur par éditeur, classe par classe (release-comparison.json). Une version perdue, une empreinte de permalien changée, une empreinte de texte d’article changée, un article perdu d’une version servie des deux côtés ou une annexe UE perdue exige une raison typée (derivation_rule_changed, rights_withdrawn, withdrawn_by_publisher, defect_corrected), chacune vérifiée contre les deux montages ; toute perte inexpliquée refuse la publication. Pour la deuxième publication : 1 730 éléments listés, 0 inexpliqué, tous du même type (version_identity_changed : la règle de lecture du contenu est passée de /2 à /3, chaque version garde son texte et prend une nouvelle empreinte), 0 article perdu, aucune baisse au-delà de dix pour cent. Le contrôle R86(2) liste les fichiers consolidés admis sans texte : 6 (4 UE sans corps XML principal, 2 LU typés), 0 inexpliqué.

Des images reproductibles et signées

Le rapport de montage (mount-report.json, deuxième publication) : 262 092 membres de corpus, builtTwiceAndEqual: true, le commit de l’outil qui a construit l’index, la liste des cinq fichiers du montage avec leur taille et leur SHA-256, et la déclaration que le chemin de dérivation « ne tient aucune session éditeur et refuse de finir avec une activité réseau ». L’image OCI (3 369 974 784 octets) et le manifeste de publication sont signés par le signataire lex-v3-release (clé P-256 dans un coffre Azure ; seule la moitié publique est sur disque) ; la page de couverture, un manifest-diff.md et les signatures sont publiés avec les actifs. Une sonde de promotion refuse une publication dont une porte ne passe pas, dont un contrôle a manqué sa permutation, ou dont les données dépassent 30 jours.

Les noms de personnes privées, retenus

Un détecteur (src/Lex.V3.Ingest/Names/) lit les intitulés et le texte des actes : sur la deuxième publication, 974 actes du catalogue luxembourgeois (954 naturalisations, 8 concessions à une personne nommée, 4 biens d’une personne nommée, 8 intitulés nommant une personne) sont retenus par classe ; 0 acte servi a été signalé ; les signaux faibles (une mention de naissance dans 66 actes, un lieu de naissance dans 2) sont comptés sans retenir. Un acte retenu répond text_withheld avec la raison names_private_individuals, reste hors recherche et hors moteurs de recherche, et renvoie à l’éditeur. La précision sur texte servi n’est pas mesurée : c’est écrit.

Les licences, fichier par fichier

Les droits luxembourgeois ont deux canaux : le catalogue de l’éditeur (SPARQL) et le bloc de licence de chaque fichier. La politique A n’admet un texte que lorsque les deux concordent ; tout le reste est retenu avec une raison typée et compté dans le rendement par classe (textYield du rapport de montage) : conflict, sparql_cc_by_in_file_silent (le fichier ne dit rien), …names_other_identity (le bloc nomme un autre fichier), …own_block_empty, catalogue_licence_scl (6 129 lois et 10 201 règlements jamais acquis). Trois décisions du propriétaire (L1, L1b, L2) sont construites et éteintes, chacune mesurée (ensemble : +3 270 fichiers, +85 059 articles) ; elles portent, si elles s’allument, une mention de droits visible par fichier jusque dans les exports.

5. Ce qui a marché, ce qui a cassé, ce que je ferais autrement

Ce qui a marché

• Le refus typé comme résultat de premier rang. Vingt codes à charge utile obligatoire, rendus par une table relue par langue, ont tenu tout le projet : le site n’a jamais eu besoin de « page d’erreur ».
• Les contrôles par permutation. Le 13 octobre, sur le premier montage combiné, les portes ont trouvé que la recherche luxembourgeoise ne répondait rien (les cellules de capacité étaient mesurées sur la date de chaque article, et aucun des 8 854 articles n’en portait : l’éditeur date le document). Une porte à 1,0 ne vaut que si son contrôle casse ; le troisième dérivé (derive-c) a passé toutes les portes et a été publié.
• Les contrôles d’une publication à l’autre. Mesurés sur le deuxième dérivé contre le premier : 1 730 permaliens changés, 0 texte changé, 0 perdu, mais 50 fichiers UE admis sans texte (48 formex_main_body_missing, 2 formex_main_body_package_rejected) que rien ne listait. Le contrôle a refusé la publication jusqu’à ce que les 48 soient corrigés et les 2 expliqués ; les 2 restent un défaut de lecteur, écrit dans release-explanations.json.
• Construire deux fois. Le dérivé, l’index et l’image sont construits deux fois et comparés. Le 28 octobre, la deuxième image est née identique à la première.

Ce qui a cassé

• Un lecteur de droits a refusé à tort 451 consolidations. La lecture /1 n’admettait un fichier que s’il portait exactement un bloc de licence ; les consolidations en portent deux (le jumeau PDF). Résultat : la première publication sert zéro consolidation luxembourgeoise, alors que 451 étaient admises par les deux canaux. Trouvé par la mesure du rendement par classe (R86(2)), corrigé par une lecture /2 qui lie le bloc dont l’uriThis est le fichier lu (la lecture /1 reste figée pour le rejeu octet pour octet) : +9 700 articles de consolidations, +14 399 au total avec 250 actes et un état de code. Leçon : compter ce qui sort de chaque étape, par classe, dès le premier jour.
• Le disque. Le 12 octobre, la dérivation du montage combiné s’est arrêtée à 398 Mo libres (le fichier d’échange avait grandi dans l’espace libre) ; le 28, une sonde d’index a été arrêtée à 2,25 Go ; cinq tests UE échouaient à 1,6 Go et passaient à 7,5 Go ; l’outil de hachage refusait les couches d’image de plus de 2 Gio. Réponses : un garde-fou de ressources qui arrête proprement, un fichier à la fois sur le disque, les constructions lourdes déplacées sur une machine Azure (environ 29,5 Gio en pic), le hachage par morceaux de 1 Gio.
• La recherche insensible aux accents est arrivée tard (le 27 octobre, la veille de la deuxième publication). Avant, « conge » trouvait 0 passage et « Congé » 11, là où « congé » en trouve 2 399 ; « reglement grand-ducal » 0 au lieu de 5 099. Le pliage (NFD sans marques, casse invariante, œ → oe, apostrophes et insécables unifiés) se fait à la requête sur une copie pliée en mémoire (26,9 Mo pour 137 614 articles), 5 à 11 ms contre 3,9 à 6,3 s pour le balayage SQL qu’il remplace. Sa revue a trouvé un défaut grave latent : une recherche UE par coordonnée de disposition servait le texte d’un acte retenu ; corrigé avant fusion.
• L’oracle des portes temporelles avait tort, pas le lecteur : il lisait l’index 9 avec la règle de l’index 8. Réécrit depuis les faits du catalogue (le 28 octobre), il ne lit plus aucune colonne dérivée que le lecteur produit.
• Des tests de parcours en Chrome sans tête ont provoqué 263 échecs de connexion Windows et un verrouillage de compte le 16 octobre. Depuis : les parcours ne tournent qu’en intégration continue, et un mode sans navigateur avec un piège qui échoue si un navigateur démarre.
• La version 2 du site est tombée avec son abonnement ; la zone DNS avait suivi. La V3 porte le risque en connaissance de cause, écrit dans le fichier d’état, avec les deux enregistrements à recréer ailleurs.

Ce que je ferais autrement

• Mesurer le rendement par classe (fichiers acquis → admis → avec texte → articles) comme première porte, avant toute porte de qualité : c’est elle qui a trouvé le plus gros défaut, et elle est arrivée après.
• Plier le texte à l’ingestion dès le premier index, avec une colonne pliée, plutôt qu’à la requête trois semaines plus tard.
• Écrire l’oracle d’évaluation depuis les faits de l’éditeur, jamais depuis une colonne que le système évalué produit.
• Dimensionner le disque et la mémoire de la machine de construction avant la première dérivation, et refuser de lancer une étape lourde sans la marge écrite.
• Allumer la recherche par mots plus tard et les identifiants plus tôt : les lecteurs arrivent avec une référence, et c’est là que le système est exact.

6. Les mêmes briques sur les sujets d’assurance