Discussion : la loi sous Git

@seb35 : je discuterais bien entre autres de l’organisation des dossiers Git, avec en tête les différents usages :

  • utilisation par Amenda
  • déroulé d’une merge request GitLab (ou d’une pull request GitHub)
  • lecture sur Archéo Lex
  • boucle de consolidation automatique entre les projets et propositions de lois passés et la loi en vigueur

Si vous comptez participer à cette réunion merci de cocher bouton J’y vais ci-dessus, après vous être identifié.

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.

1 J'aime

Petite victoire sur les octopus : il est possible d’assembler les historiques de plusieurs codes pour faire des ppjls grâce à la stratégie de fusion Git “octopus” : fusion d’un certain nombre de branches. Exemple avec les codes pénal, civil et du sport sur le méta-repo.

git checkout refs/codes/code_pénal/texte
cp code_pénal.md code_pénal.md2
git checkout refs/codes/code_du_sport/texte
cp code_du_sport.md code_du_sport.md2
git checkout -b refs/codes/code_civil/texte ma-super-ppl
mv code_pénal.md2 code_pénal.md
mv code_du_sport.md2 code_du_sport.md
echo 'Nouvel alinéa dans le dernier article' >> code_pénal.md
git add .
git merge -s octopus refs/codes/code_pénal/texte refs/codes/code_du_sport/texte
git commit -m 'Ma super ppl portant sur les codes pénal, civil et du sport'
git log --oneline --graph --decorate
git show

git log montre les trois historiques réunis dans notre nouveau commit.

*-.   8a321aa (HEAD, ma-super-ppl) Ma super ppl portant sur les codes pénal, civil et du sport
|\ \  
| | * 8bcf30c (refs/codes/code_du_sport/texte) Version consolidée au 14 septembre 2018
| | * …
| | * 46eb589 Version consolidée au 1er février 2006
| * 81f6c89 (refs/codes/code_pénal/texte) Version consolidée au 12 septembre 2018
| * …
| * 3bb14ab Version consolidée au 1er septembre 1990
* 3cdc0c6 (refs/codes/code_civil/texte) Version consolidée au 6 août 2018
* …
* af72ddb Version consolidée au 14 mars 1803

git show montre le diff sur le code du sport (le seul modifié dans mon essai) :

++ #### Article L100-1
++ 
  -Les activités physiques et sportives constituent…
+++Les activités pratiques et sportives constituent…
++ 

Très très solide comme projet et comme approche !

Chapeau bas car ca n’a pas l’air d’être de la tarte et merci pour ce CR détaillé !