Voici un compte-rendu de sujets discutés.
Organisation des dépôts Git
Désormais dans Archéo Lex, Sébastien va créer (qui deviendra le mode par défaut) un seul dépôt Git contenant tous les codes et lois dans des références refs/code/* et refs/lois/* (et refs/loi_organique/*) grossièrement calqué sur les URL ELI, par ex refs/code/code_pénal/texte ou refs/loi/loi_78-17/texte (ou refs/loi/78-17/texte).
Discussion rapide autour de « quels lois cloner dans Amenda pour créer un ppjl ? » : tout le dépôt des lois françaises ou seulement les lois modifiées. Sébastien et Emmanuel préfèrent la 2e, le plus petit sous-ensemble modifié. Jean-Marc avait indiqué précédemment à Emmanuel préférer la 1re pour conserver tout l’historique Git. Noter toutefois que le ppjl dans sa forme “texte modificateur” (i.e. pas dans sa forme “diff”) a un historique indépendant, et au mieux on peut indiquer par exemple dans les messages de commit une référence Git de la version du code modifié (ce qui peut par ailleurs être utile si le texte est modifié entre temps au point de briser l’action du texte modificateur).
PS : note post-rencontre de Seb : réfléchir à des merge-octopus de Git pour rassembler tous les textes modifiés.
Ajout de métadonnées dans Archéo Lex
Emmanuel souhaite avoir le nom de la loi dans des métadonnées. Ça se rapproche de ce qui est fait dans la référence refs/meta qui désormais contient un fichier YAML meta.yaml (voir cette issue), mais il faut ajouter le nom de la loi.
Noter que le nom des codes peut se déterminer avec le nom du fichier .md, en transformant les tirets bas en espaces (et si on veut en capitalisant la première lettre (qui n’est pas toujours un C à cause du Livre des procédures fiscales qui est un code)). Noter que la casse est préservée dans le titre du fichier, par exemple Mayotte conserve sa majuscule dans le nom de fichier.
Discussion sur les renommages de loi et/ou de code :
- Indiquer en titre dans le fichier Markdown Archéo Lex le nom de la loi/du code pour permettre son renommage dans des Pull Requests
- Dans les codes, il y a une dizaine de codes renommés avec des statuts divers : il faut les traiter comme des exceptions
Cas des articles modificateurs
Sébastien a implémenté le rendu des lois simples (non-publié pour l’instant, mais cette issue de legi.py en est une importante part). Le rendu est correct sur les articles autonomes, i.e. non-modificateurs, mais très mauvais sur les articles entièrement ou partiellement modificateurs car la base LEGI contient dans ses données textuellement “Modifie : article 3 du code pénal”, ce qui est clairement inexploitable. Pour parer à ce problème, le développement en cours d’Archéo Lex prend la base JORF (qui contient le texte réel, donc le texte modificateur) et, tant que l’article n’est pas modifié dans la base LEGI, il est affiché dans Archéo Lex le texte initial (complet donc). Cela limite les dégâts sans toutefois résoudre le fond du problème.
Après analyse de la situation et discussions, Emmanuel suggère (et Sébastien est presque convaincu) que les (parties d’) articles modificateurs ne sont jamais modifiés par les lois ultérieures mais seul le texte consolidé cible est modifié directement. Sous cette hypothèse, pour afficher des textes complets dans Archéo Lex, il suffirait de toujours afficher le texte des articles entièrement modificateurs (et donc d’ignorer les éventuelles modifications affirmées par l base LEGI, à vérifier s’il y en a) et d’isoler la partie texte modificateur dans les articles partiellement modificateurs (qui comprennent à la fois du texte modificateur et du texte autonome). Cette isolation pourrait se faire avec des regexes (à creuser). Il pourrait être taggé dans le texte les parties “texte modificateur” pour faciliter la lecture et par exemple que les programmes réutilisateurs interdisent (ou découragent) la modication de ces parties.
Interrogations sur la façon de faire pour modifier des textes en vigueur future (par exemple le code de l’action sociale et des familles a actuellement 4 versions en vigueur future), par exemple si on veut annuler ou modifier une parties des modifications futurement introduites. Si quelqu’un a une réponse… (on doit pouvoir trouver des exemples probablement autour des articles morts-nés (=qui ont été en vigueur future mais modifiés avant d’entrer en vigueur))
Base de donnée légistique
Sébastien indique une idée de projet consistant en la création d’une « base de données légistique » contenant tout le corpus législatif français, avec des données et métadonnées supplémentaires :
- consolidation par DuraLex des lois passées (il faudrait donc avoir les ppjl passés) et comparaison avec la consolidation effectuée
- enrichissement des liens entre textes : liens de citations, ainsi que, via DuraLex, liens de métadonnées “création”, “abrogation”, “entrée en vigueur”
Cela permettrait de donner un score d’achèvement de DuraLex en plus d’être une base de données puissante.