Archéo Lex
Archéo Lex est un de mes projets visant à offrir une visualisation des textes de lois français pratique et jolie, que je transpose en Git + Markdown.
Le dépôt Git du code est sur Github, un exemple avec le code de la propriété intellectuelle y est également disponible (dernière version du texte, un exemple de modification) et un billet de blog introductif est disponible sur mon blog.
Ci-dessous différentes choses liées au développement. Si vous comptez faire des modifs substantielles, dites-moi un peu en quoi ça consiste et je pourrai vous donner les droits en commit sur Github. Noter que la licence d’Archéo Lex est la WTFPL 2.0.
Sous-pages sur Archéo Lex :
Roadmap
Réparti en grandes thématiques. Les chiffres (1) (2) définissent une indication de priorité. Lorsque c’est marqué (README), ce point est issu du README Github, le retirer quand c’est résolu. N’hésitez pas à discuter autour de ces points (je peux ouvrir des comptes sur le wiki sur demande).
- Prise en compte des mises à jour différentielles de la base LEGI :
- (README) (1) mise à jour des nouvelles versions des textes sans recalcul de l’entièreté de la base
- (README) (2) téléchargement automatique des bases LEGI (et autres) et de leurs mises à jour incrémentales
- Étudier les réécritures d’historiques, s’il y en a (si la DILA modifie la base LEGI quand il y a des fautes de retranscription entre La Loi et ce qui est publié dans la base LEGI) :
- (README) (3) intégration des modifications d’historique (orthographe, typographie, coquilles, etc.) quand les mises à jour le demandent (à étudier)
- Problèmes et améliorations mineurs :
- (README) (3) réfléchir à une façon d’intégrer à Git les textes pré-1970 (inféfieurs à l’epoch, refusés par Git, par ex LEGITEXT000006070666)
- (README) (5) mettre les dates de commit à la date d’écriture ou de publication du texte modificateur (à réfléchir) (attention : cette 2e date peut être avant, après ou identique à la date d’entrée en vigueur) pour créer des visualisations intégrant ces différences de dates
- (3) généraliser les interfaces de création de syntaxe (pour implémenter d’autres languages que le Markdown) et d’enregistrement des versions (pour implémenter d’autres cadres de gestion de versions : svn, plusieurs fichiers avec des suffixes par date, hg, etc.)
- Qualité :
- (README) (4) vérifier plus en profondeur la qualité des résultats (par exemple dans le code des assurances il y a actuellement une différence vide vers le début)
- (README) (5) écrire la grammaire exacte du sous-ensemble Markdown utilisé et des autres éléments de syntaxe utilisés (cf points 6 et 12)
- (README) (5) documenter plus et mieux
- (README) (4) ajouter des tests unitaires
- Interactions et interface utilisateur :
- (README) (4) ajout de branches (orphelines) Git avec liens vers les autres textes (liens soit juste mentionnés en-dessous de l’article comme sur Légifrance, soit au sens Markdown+Git similairement à Légifrance)
- (README) (4) faire expérimenter la syntaxe Markdown et autres éléments de syntaxe à des publics non-informaticiens et réfléchir à l’améliorer (cf points 7 et 12)
- (README) (5) création ou adaptation d’interfaces de visualisation (cf point 16)
- Production :
- (README) (6) mise en production d’un service web qui mettrait à jour quotidiennement les dépôts Git
- (README) (6) création d’un site web permettant la visualisation des modifications, proposerait des liens RSS, etc. de façon similaire à La Fabrique de la Loi, à Légifrance, aux sites du Sénat ou de l’Assemblée nationale (cf point 11)
- Futur :
- (README) (7) travail sur les autres textes législatifs que les codes (les seuls testés actuellement), comme les Constitutions, les lois, les décrets, etc.
- (README) (7) travail sur les autres bases (KALI pour les conventions collectives, JORF pour le journal officiel -- ce dernier n’a pas de versions à ma connaissance mais demanderait juste à être transformé en Markdown)