Au sens strict, Archéo Lex est le programme qui lit la base LEGI et la transforme en dépôts Git, qui est à la fois un format couramment utilisé en informatique pour suivre les différentes versions d’un texte et un ensemble d’outils assez puissants pour suivre les évolutions du texte. Plus exactement, Archéo Lex n’utilise plus directement la base LEGI officielle (au format XML), mais passe par l’intermédiaire du projet legi.py de Changago qui transforme la base LEGI officielle en une base de données SQL – SQLite plus exactement – c’est-à-dire un format déjà beaucoup plus manipulable (discussion sur l’intégration de legi.py). Plus généralement, la base de données SQL créée par legi.py permet de répondre à beaucoup de questions qu’on peut se poser sur les lois, sous réserve toutefois de connaître le language SQL : combien y-a-t-il de lois au total ? combien en vigueur ? combien par type de loi ? combien sur tel intervalle de temps ? combien de sections et d’articles en moyenne ? durée de vie d’une loi ? quelles sont les lois parues un 31 décembre ? etc.

Au sens large, Archéo Lex représente aussi l’interface sur le site archeo-lex.fr. Cette interface a été conçue à partir d’un logiciel libre de visualisation de dépôts Git, GitList, à l’origine utilisé pour visualiser du code informatique, transformé pour visualiser des textes de loi. Quoique qu’une première simplification de l’interface ait été faite il y a quatre ans, une deuxième passe a été faite récemment pour encore retirer certaines fonctionnalités peu utiles aux textes de loi.

Dans l’écosystème de la légistique numérique libre, Archéo Lex est désormais au milieu d’une chaîne de traitement des textes de loi : de même que legi.py agit en amont d’Archéo Lex, il y a désormais SedLex qui agit en aval, spécifiquement dans la projection d’amendement sur un texte en vigueur, issu d’Archéo Lex. Pour cette opération, SedLex a besoin d’une certaine qualité sur les textes fournis, notamment sur la numérotation des alinéas.

Avant d’aborder la liste des principales améliorations à Archéo Lex et à l’interface, mentionnons les communautés actuelles autour de la légistique numérique libre :

  • Légilibre tout d’abord, communauté de personnes et de logiciels qui s’intéressent au traitement numérique de la loi, qui s’est créée fin 2016,
  • Regards Citoyens et notamment le projet La Fabrique de la Loi qui permet de visualiser la loi en fabrication au Parlement,
  • le Bureau ouvert, rendez-vous informels à l’Assemblée nationale qui permettent (pour résumer rapidement) de discuter de la thématique de la démocratie via les outils numériques.

Améliorations apportées à Archéo Lex

Dans le programme Python créant les dépôts Git donc.

  • Performance : jusqu’à l’année dernière, les gros codes mettaient jusqu’à 60h à être calculés (=à créer le dépôt Git du code), l’ensemble des 103 codes met désormais 5h30 à être calculé. Cela s’est fait notamment en optimisant les appels SQL et en créant un cache de sections (=par exemple ne pas re-calculer la partie réglementaire si elle n’a pas changé d’une version à l’autre) ;
  • Formats de texte : il est désormais possible d’enregistrer plusieurs variations d’un même texte dans un même dépôt Git, par exemple une variation avec tout le texte dans un seul fichier et une variation avec un article par fichier (de part la compression, cela ne prend que très peu de place supplémentaire) ;
  • Abstraction du code d’Archéo Lex : c’est purement informatique, mais cela permet de pouvoir ajouter relativement facilement des variantes, que ce soit avec une syntaxe autre que Markdown ou une autre organisation des fichiers ou même un autre système de gestion de versions ;
  • Articles manquants : par le jeu des sections / sous-sections ayant des intervalles de vigueur se chevauchant, il est arrivé qu’il manque des articles, c’est désormais réparé ;
  • Articles et sections morts-nés : ce sont les articles et sections qui devaient entrer en vigueur dans le futur mais qui ont été abrogés avant, et qui n’ont donc jamais été en vigueur ; ceux-ci ont donc une date de début de vigueur postérieure à leur date de fin de vigueur, ce sont des cas particuliers à traiter correctement ;
  • Dates dans Git : étant donné que Git est à la base un outil informatique, il manipule par défaut des dates entre 1970 et 2100, ce qui est insuffisant pour les textes de loi, surtout pour la période pré-1970 (mais il faut aussi utiliser la date du 22 février 2222 qui signifie « date d’entrée en vigueur future à une date non-déterminée) ; il a fallu gérer dans Archéo Lex l’écriture bas niveau du format Git sans passer par les outils standards (pour écrire un timestamp négatif) ; toutefois les dépôts Git créés ainsi ne sont pas compatibles avec certaines plateformes comme GitHub et cela reste donc une option à activer explicitement ;
  • Amélioration de la syntaxe et de la typographie : retrait de nombreuses balises HTML qui polluent le texte, normalisation des paragraphes (afin de bien compter les alinéas notamment, quoique cela n’est pas encore garanti), nettoyage des tableaux HTML.

Améliorations apportées à l’interface

Sur le site archeo-lex.fr donc.

  • Épuration de l’interface : en plus de la liste des versions et de l’affichage du texte intégral d’une version, seules deux autres fonctions restent : les diffs, principale plus-value de la loi sous Git, et ce que j’ai appelé « texte annoté » (mais je ne suis pas satisfait du nom si vous avez de meilleures propositions) ; cette dernière permet de retrouver quand a eu lieu la dernière modification de chacune des lignes afin de retrouver la date de l’introduction d’une disposition (en informatique, cette fonctionnalité s’appelle « blamer », dans l’idée de retrouver qui a introduit le bug sur telle ligne, je n’aime pas ce nom qui n’est pas des plus positifs) ;
  • Diffs mot-à-mot : par défaut les diffs créés par Git sont ligne par ligne, c’est bien, mais le mot-à-mot, c’est mieux ; ceci est expérimental et ne fonctionne pas lorsqu’il y a trop de calculs à effectuer ; ces diffs sont créés avec l’algorithme de Ratcliff-Obershelp qui permet de trouver les parties communes à deux textes afin d’avoir des diffs plus lisibles qu’avec d’autres algorithmes ; toutefois certains sont encore difficiles à lire, n’hésitez pas à recenser des exemples et des propositions d’amélioration ;
  • Dates Git : en cohérence avec les dépôts Git créés avec des dates pré-1970, l’interface comprend ces dates ; c’est donc une des rares interfaces à être compatible avec ces dates.

Prochaines améliorations

Désormais, les 103 codes (73 en vigueur et 30 abrogés) sont présents sur le site archeo-lex.fr, dans une qualité très correcte. Les erreurs que j’observe désormais sont plutôt dans les données de la base LEGI que dûes à un mauvais traitement d’Archéo Lex.

Les prochaines améliorations sont :

  • une inscription des métadonnées et variations présente dans chaque dépôt Git afin de faciliter sa gestion,
  • l’ajout de liens internes voire externes avec la bibliothèque metslesliens,
  • l’ajout des quelques 3000 lois sur le site archeo-lex.fr, ainsi que de la centaine de lois organiques, de la vingtaine de lois constitutionnelles et de la Constitution,
  • l’ajout des versions initiales des lois, dont le texte est contenus dans la base JORF et non LEGI.

Utilisation par les juristes

De part les améliorations sur la qualité et la fréquence de mise à jour, le site est probablement prêt pour être réellement utilisé par les juristes, notamment afin de retrouver quand a été introduite ou modifiée une disposition donnée, en complément de Légifrance.

Les mises à jour sont programmées les jours de semaine vers 21h (la DILA fournit la base LEGI du jour vers 20h30) et, à ce qu’il semble, contiennent les textes consolidés jusqu’au JORF du jour, soit les textes en vigueur à partir du lendemain selon les délais normaux.

Amis juristes, n’hésitez pas à me faire part de vos suggestions pour améliorer l’interface ou pour demander des fonctionnalités nouvelles !