[DuraLex] avancement 07/04/17

Jean-Marc_Le_Roux · Avril 7, 2017, 7:31

Bonjour,

voilà les derniers progrès/changement dans le développement de DuraLex, le programme qui analyse les projets de loi pour les transformer en code informatique pour produire le texte de loi final avec le suivi des modifications et votable.

Intégration de « La Fabrique de la Loi »

Avant, il fallait installer/récupérer les données d’un projet de loi via the-law-factory-parser avant de pouvoir l’utiliser dans DuraLex.

Maintenant, le code de the-law-factory-parser qui permet d’analyser le projet de loi pour extraire la liste/le texte des alinéas a été intégré dans DuraLex et on peut directement passer l’URL d’un projet de loi au programme. Exemple :

duralex --url http://www.assemblee-nationale.fr/14/propositions/pion1561.asp

va automatiquement télécharger et analyser ce projet de loi pour décrire informatiquement les changements apportés au texte de loi original (la loi n° 77‑729 du 7 juillet 1977).

Tests unitaires

Jusqu’ici, les tests consistaient à comparer le résultat du programme avec des résultats pré-enregistrés sur une série de projets de loi. En cas de régression, il était très long de savoir quel bout/changement de code causait la régression.

Maintenant, le projet utilise des tests unitaires et chaque fonction est testée séparément en gérant un maximum de cas. Si une syntaxe n’est pas/plus correctement gérée, il devrait être simple de l’ajouter dans les tests et de réparer le problème. Exemple de tests pour les différentes syntaxes décrivant une référence à un alinéa:

github.com

Legilibre/duralex/blob/master/tests/ParseAlineaReferenceTest.py

# -*- coding: utf-8 -*-

from DuralexTestCase import DuralexTestCase

import duralex.alinea_parser as parser

class ParseAlineaReferenceTest(DuralexTestCase):
    def test_alinea(self):
        self.assertEqualAST(
            self.call_parse_func(
                parser.parse_alinea_reference,
                u"l'alinéa 42"
            ),
            {'children': [
                {
                    'type': u'alinea-reference',
                    'order': 42
                }
            ]}
        )

Ce fichier a été tronqué. afficher l'original

C’est important car si on veut gérer de plus en plus de syntaxes différentes dans chaque projet de loi traité, il faut être efficace et ne pas casser l’existant.

Les tests passent maintenant à chaque soumission de modification du code et peuvent être suivis ici, et il est donc possible d’accepter/refuser les contributions des développeurs en fonction.

Gestion de nouvelle(s) syntaxe(s)

La syntaxe suivante est maintenant gérée (exemple : proposition N° 1561, Article 2, I) :

un {header1} et un {header2} ainsi rédigés :
{contenu du header1}
{contenu du header2}

Et maintenant ?

Nous allons travailler pour que ce projet de loi soit complètement automatisé dés la semaine prochaine :

génération d’un dépôt git avec le texte de loi original venant de Legifrance via ArcheoLex
récupération et analyse du projet de loi pour créer le patch correspondant via DuraLex
application du patch et soumission pour le visualiser via GitHub

Ca sera donc le premier projet de loi avec un traitement automatisé et le suivi des modifications. Nous essaierons également d’y insérer le bouton de vote et nous aurons un exemple complet sur un cas réel de ce que nous proposerons aux citoyens.

francoise_69 · Avril 7, 2017, 9:35

@Jean-Marc_Le_Roux Bravo pour ce travail énorme! Un outil fondamental pour le projet MAVOIX.
En l’etat du projet, en n’en maîtrisant absolument pas les éléments techniques, j’aurais deux questions ingénues:
1- Pourra-t-on garantir une retranscription exacte du texte?

Les textes en cours d’examen sont amenés à être modifiés, amendés, et il arrive que le délai soit court entre ces propositions de modification et le vote de la loi. Dans ces conditions, mais peut être j’anticipe un peu trop sur les étapes de construction de ce projet:
2- Pourra-t-on intégrer les modifications apportées aux textes ainsi que les amendements au fur et à mesure du travail des commissions ou des assemblées plénières? Et si c’est le cas est ce que cela nécessitera une intervention humaine ou y a t il un moyen de l’automatiser?

Jean-Marc_Le_Roux · Avril 7, 2017, 10:41

C’est le but.

Ca ne sera surement pas le cas au début, mais plus ça ira plus l’analyse sera efficace.
C’est pour ça que les tests sont importants : ils permettent de garantir que telle ou telle syntaxe est gérée, et qu’une modification du code ne cassera pas toutes les syntaes déjà supportées.

Il y’a un nombre « relativement limité » de syntaxes possible. Donc ça n’est pas irréaliste.

Les amendements sont rédigés avec la même syntaxe. Donc oui.

RegardsCitoyens a mis en ligne une API pour suivre le processus législatif :

http://parlapi.fr/

ainsi que des packages permettant de récupérer les documents (amendements, projets de loi) correspondants :

anpy
senapy

En ajoutant tout ça dans DuraLex, on devrait pouvoir faire en sorte que les modifications diverses soient récupérées et prises en compte en temps réel. On devrait par exemple pouvoir appeler DuraLex en lui passant l’identifiant du projet de loi et la date jusqu’à la quelle toutes les modifications doivent être récupérées. Tous les jours, un robot ferait cette opération en passant la date du jour et voilà…

francoise_69 · Avril 7, 2017, 11:47

@Jean-Marc_Le_Roux merci pour tes réponses limpides, c’est un magnifique outil de travail. N’ayant aucune compétence pour t’accompagner dans ce travail, je ne peux que t’adresser ainsi qu’à tout ceux qui oeuvrent sur ce projet encouragements et gratitude. Si toutefois il est possible d’aider en tant que néophyte pour effectuer des tests ce sera bien volontiers.

ColinMaudry · Avril 7, 2017, 3:24

Le chantier de la plateforme de dons est sur le point de commencer, et s’y ajoute un outil de recueil d’engagement des groupes locaux. Du coup, mis à part pour la partie FranceConnect je ne serai pas trop dispo.