Évolution de la chaîne de nettoyage des données brutes de l'Assemblée

Tricoteuses
1

Situation actuelle

Les types bruts (raw_types) servent à valider les données brutes récupérées de l’Assemblée nationale.

Si les types bruts valident les dernières données brutes récupérées de data.assemblee-nationale.fr, les données brutes sont converties en données nettoyées, qui sont elles-mêmes validées avec les types nettoyés (on n’est jamais trop prudent :smile:).

Ces types bruts sont générés par quicktype puis légèrement retravaillés à la main afin de les rendre un peu plus génériques.

Ces types bruts ne sont pas mis à jour tant qu’un problème de validation des données ne se produit pas.

Quand une erreur de validation se produit, le type brut concerné est mis à jour (par quicktype, plus quelques opérations manuelles), puis le type nettoyé est mis à jour en appliquant manuellement les différences trouvé dans le nouveau type brut par rapport à sa version précédente

Avantages

Avoir des types bruts générés automatiquement d’après les données permet de s’assurer qu’ils sont à jour.

Quand une validation par les types bruts échoue, c’est un indice que le format des données brutes a évolué et qu’il faut mettre à jours les types bruts ainsi peut-être que les types nettoyés.

Inconvénients

Comme les données brutes sont toujours validées avec les types bruts et que ces types bruts sont fragiles (plus fragiles que les types nettoyés), une erreur de validation se produit fréquemment alors que les données auraient quand même pu être converties en données nettoyées valides.

Du coup, plusieurs fois par mois, la mise à jour des données est bloquée jusqu’à ce qu’un débogage manuel permette de mettre à jour les différents types et de relancer la conversion et la publication des données. Comme les données de l’Assemblée sont principalement mises à jour la nuit, ce débogage retarde la mise à jour des données jusqu’au milieu de matinée dans le meilleur des cas et de plusieurs jours dans le pire des cas.

Or dans la majorité des cas, les données auraient pu être converties sans problème si on ne les avait pas validées avec les types bruts.

Ce processus n’est pas soutenable, car il entraine des contraintes de disponibilité sur les rares personnes capables d’actualiser les types (1 seule personne actuellement) et il retarde de plusieurs heures la mise à disposition de données actualisées, ce qui est un problème majeur pour certaines informations comme les réunions, les actualisations de dossiers législatifs, etc.

Solution envisagée

Ne plus mettre la validation des données brutes par les types bruts dans la chaîne de production des données nettoyées. Mais la mettre dans une chaîne parallèle.

Comme cela, quand les types bruts ne valident pas les données brutes, mais que les données nettoyées sont quand mêmes produites, les développeurs ont toute leur temps pour actualiser les types bruts et éventuellement nettoyés.

2 « J'aime »
2

La solution envisagée parait saine. D’autant plus que la validation des données brutes version N+1 avec les types bruts déduits de la version N est effectivement fragile, puisque quicktype produit des enumérations assez restrictives dans certains cas. Et qu’il suffit de l’apparition d’une nouvelle valeur pour que ça échoue.

Je n’arrive pas à imaginer de cas concrets ou des données nettoyées version N+1 et validées par les types nettoyés version N sont en fait non utilisables.

Mais dans le cas ou une nouvelle valeur apparait dans une énumération, ou bien un nouveau champ apparait dans une structure, les données nettoyées ne vont pas valider et les données brutes non plus. Alors ma question est: dans quel cas concret les données brut ne valident pas mais les données nettoyées valident ? Ca pourrait etre un champ ajouté dans une structure qui est supprimée dans les données validées, par exemple. Est-ce que ce cas s’est présenté dans l’import de ces derniers jours ? Un autre cas ?

3

Par exemple, en ce moment, les données brutes du dossier législatif contiennent :

  • PurpleImprimerie

    export interface PurpleImprimerie {
    prix:    null | string;
    ISSN?:   null;
    ISBN?:   null;
    DIAN?:   null | string;
    nbPage?: null | string;
}

  • FluffyImprimerie

    export interface FluffyImprimerie {
    prix: string;
}

Tandis que les données nettoyées contiennent seulement Imprimerie qui fusionne (après nettoyage) à la fois PurpleImprimerie et FluffyImprimerie :

export interface Imprimerie {
  dian?: string
  nbPage?: string
  prix?: string
}

Dans les prochains jours, il se peut qu’une donnée avec un DIAN ou un 'nbPage` non vide apparaisse dans une donnée validée par FluffyImprimerie. Dans ce cas, les données brutes ne seront plus validées, mais les données nettoyées le seront toujours.

1 « J'aime »
4

Ca veut dire que quicktype a trouvé au moins un champ DIAN avec une valeur non nulle, ou bien je me trompe ?

5

Oui, c’est bien cela.

1 « J'aime »
6

Ok, c’est clair maintenant, merci :slight_smile: Donc pas d’objection, c’est tout bon.

7

Cette solution est maintenant mise en place dans la chaîne d’intégration continue de Tricoteuses-Assemblée.

8

Ce serait bien d’avoir pour archive quelque pointeurs qui expliquent la chaîne de production. En incluant Pipeline Schedules · Tricoteuses / tricoteuses-assemblee · GitLab et .gitlab-ci.yml · master · Tricoteuses / data / assemblee-nettoye / Dossiers_Legislatifs_XV_nettoye · GitLab et https://git.en-root.org/tricoteuses/data/assemblee-brut/Dossiers_Legislatifs_XV_nettoye/blob/master/.gitlab-ci.yml et .gitlab-ci.yml · master · Tricoteuses / tricoteuses-assemblee · GitLab parce que c’est pas trivial de s’y retrouver, en particulier parce que les noms de projets portent des numéros (11, 50) qui ne sont pas visibles depuis l’interface web de GitLab :slight_smile:

1 « J'aime »
9