Versionnage du code américain : une base de données législative traçable
Sommaire
En bref
- Un chercheur a reconstruit neuf titres du code américain avec l'historique complet de chaque modification, en reliant chaque amendement à la loi qui l'a introduit et à sa date d'effet.
- Cette approche répond à un problème réel : les modèles de langage ne maîtrisent pas la validité temporelle des lois et appliquent souvent des règles obsolètes ou erronées.
- Le projet est présenté comme un outil de consultation pour juristes et chercheurs, distinct d'une demande de passage complet du Congrès à Git.
Ce que dit la source
L'auteur constate que les juristes ne disposent pas d'un outil équivalent à Git pour consulter l'historique du droit fédéral américain. Contrairement aux développeurs qui peuvent pointer une ligne de code et voir son auteur, sa date et l'état antérieur du fichier, les avocats doivent fouiller les notes de bas de page des statuts pour reconstituer les modifications. Ce vide affecte particulièrement les modèles de langage, qui selon des études récentes échouent sur les questions impliquant des règles temporellement valides : un modèle répondait juste à 24 % des questions post-entraînement seul, mais à 87 % quand le texte pertinent lui était fourni. L'auteur propose une base de données reconstruite où chaque modification du code est datée, reliée à la loi qui l'a introduite, et vérifiable.
- Le projet couvre neuf titres du code américain depuis 2017, avec 365 changements tracés ; 361 ont reproduit exactement la version officielle suivante, les quatre autres étant explicitement signalés.
- Chaque modification porte le texte de la loi qui l'a introduite et la date de prise d'effet : 261 par défaut (jour de l'adoption), 72 via note d'effet différé, 29 par date spécifiée dans l'amendement lui-même.
- Les études mentionnées montrent que le même modèle appliquant des amendements allemands au texte antérieur produit une similarité de 93 à 99 % avec le texte officiel, mais seulement la moitié des amendements simples et un cinquième des chaînes d'amendements correspondent exactement.
- L'interface permet de consulter le texte en vigueur à une date donnée, avec les passages modifiés en évidence et coloriés selon l'acte qui les a écrits.
- Les limites reconnues : le système ne montre pas encore comment une loi ultérieure s'applique rétroactivement, les notes d'effet différé sont analysées par motif (ce qui rate les formulations inhabituelles), et chaque modification majeure renvoie au texte original de la loi.
Dans les commentaires
Débat partagé entre admiration de l'idée et doutes méthodologiques. Plusieurs commentateurs saluent l'utilité pour la transparence législative et l'aide aux modèles de langage, mais d'autres soulèvent des objections importantes : Git n'est pas la bonne abstraction pour le droit, les gouvernements ont déjà des workflows de versioning (imparfaits mais existants), et imposer la pratique des développeurs aux rédacteurs législatifs risque de rester un projet académique.
- Plusieurs commentateurs ayant de l'expérience en gestion documentaire gouvernementale contestent que Git soit la solution adéquate. Un développeur ayant travaillé 15 ans avec des entités publiques rappelle que le Congrès utilise déjà un workflow de versioning (posté sur Congress.gov), même s'il est moins transparent, et que forcer Git sur des rédacteurs législatifs sans UX adaptée répond mal au besoin réel : plus de détail, d'auteur des changements, de traçabilité de la source et de justification, plutôt qu'une couche de données logicielle.
- L'idée de Git pour le Congrès n'est pas nouvelle : un commentaire cite un article du New York Times de 2007 prônant exactement cela. Un autre note qu'une approche similaire existe pour le droit français (La Fabrique de la Loi), avec peu de suivi, suggérant que l'adoption ne suit pas l'intention.
- Deux commentateurs signalent des projets parallèles en cours : un travail open source sur le versioning des lois amendables mondialement (finnois, estonien, USA, UK), et un autre sur la différenciation légale en général, qui reconnaissent tous deux que diffser et tracer le droit diffère substantiellement de Git et recèle des cas ambigus irréductibles.
- Un commentateur demande si le projet est réellement implémenté ou juste un concept ; un autre note que beaucoup de législation majeure est rédigée en secret, ce qui rend un tel historique incomplet de facto.
Alternatives citées : Le débat cite plusieurs alternatives ou projets parallèles : la base de données suisse (Fedlex avec diffing HTML depuis 2020), la Fabrique de la Loi française (versioning des projets de loi en Git), le projet allemand Grundgesetz sur Github, et une initiative open source globale de versioning du droit amendable (lawvm) en cours de développement.
Notre lecture
Le projet adresse un problème réel pour les juristes et les systèmes d'IA : la traçabilité temporelle et fiable des modifications législatives améliore la capacité à appliquer la bonne règle au bon moment. La reconstruction de neuf titres avec 361/365 changements vérifiés est un travail technique rigoureux. Cependant, le débat HN révèle un hiatus entre l'utilité du résultat (une base de données interrogeable et fiable) et le choix de Git comme cadre de travail : c'est une confusion entre format de stockage et interface d'édition. Pour qu'un tel projet prenne à l'échelle fédérale, il faudrait intégrer le workflow de versioning dans l'outillage du Congrès lui-même (ce qui relève du politique et du procédural, pas du technique). À court terme, l'outil est utile pour les chercheurs en droit et pour l'évaluation des LLM sur les régimes légaux temporels. Mais la généralisation reste bloquée sur la question non technique : les institutions législatives adopteront-elles ce type de traçabilité proactive ? Aucune action urgente pour une DSI généraliste, sauf pour les organisations (cabinet juridique, think tank, systèmes d'IA pour le droit) qui traitent la législation américaine comme donnée métier.