Cadre juridique et technique de l'ouverture des données de subventions

L’arrêté du 17 novembre 2017 est le principal cadre de l’ouverture des données des conventions de subvention.

Il se traduit par la création d’un modèle de fichier tabulaire publié et documenté sur un dépôt Github créé à cet effet.

Vos questions et commentaires sont les bienvenus, je tâcherai d’y répondre.

3 Likes

Je viens de publier une version majeure du format de données des subventions (1.0.0). Au menu :

  • noms de colonnes corrigés
  • données exemples
  • précisions sur les modalités de saisie
  • lien vers l’arrêté

>> https://github.com/etalab/format-subventions

2 Likes

Suite à de nombreux retours, le format des données de subventions a été simplifié, anticipant une mise à jour de l’arrêté.

Ainsi, la version 1.1.0 apporte les modifications suivantes :

  • Pour des raisons de praticité, et contrairement à la lettre de l’arrêté qui va être amendée, la mission Etalab a décidé d’utiliser le point comme séparateur des décimales
  • Pour les mêmes raisons, le séparateur du champ nature en cas de valeurs multiples est maintenant le point-virgule, et non plus la virgule
4 Likes

Bravo pour avoir ouvert cet espace de discussion. J’espère qu’il inspirera toute la mission Etalab pour les projets de spéc futurs.

À l’avenir ce serait bien de l’ouvrir en amont.
Ici on a un peu l’impression d’arriver après la bataille :

  • dès le départ la spéc était perfectible et peu discutable puisqu’imposée par décret
  • les améliorations n’ont pas non plus fait l’objet d’une discussion, puisqu’on se retrouve avec des changements motivés par d’obscurs « nombreux retours » et se justifiant « pour des raisons de praticité »

La mission Etalab sait ô combien j’apprécie son travail, mais sur ce sujet j’en attends un peu plus :wink:

Plus concrètement je suis d’accord avec l’essentiel des recommandations – je les explicite ici : http://infolabs.io/prod-csv
Cependant certaines sont questionnables.

Je pense tout d’abord que le sujet du séparateur décimal n’a pas été assez instruit : je ne dis pas que c’est un mauvais choix mais je dis qu’il doit être instruit. Beaucoup de petites communes vont produire ce tableau à la main et il se trouve, par exemple dans LibreOffice, que le point du pavé numérique produit nativement une virgule, comme c’est l’usage depuis des centaines d’années en typographie française, en particulier dans l’administration. Vu de ma fenêtre on pourrait penser que le choix du point n’arrange que les informaticiens. Je pense que c’est plus compliqué que ça et c’est pourquoi ce serait utile de rationnaliser votre choix avec de vrais arguments à charge et à décharge.

Sur l’échappement des guillemets je m’interrogeais. La RFC 4180 propose de doubler les guillemets mais ne mentionne pas l’échappement avec une barre oblique inverse ("). Tous les outils gèrent-ils l’échappement par barre oblique inverse ? Pourquoi ne pas spécifier seulement ce qui est conforme à la RFC qui a tendance à devenir la référence en matière de CSV ? Au sein des milliers de jeux de données publiés sur data.gouv.fr, seriez-vous en mesure d’analyser le nombre de fichier qui utilisent des doubles guillemets et ceux qui utilisent des échappements ?

Vous l’aviez d’ailleurs très bien fait pour les marchés publics :
https://forum.etalab.gouv.fr/t/atelier-1-elaboration-d-un-referentiel-national-de-donnees-standardisees-format-pivot/

Comme vous le savez, l’écosystème du CSV est très divers, nous avons donc fait des choix. Ceux qui s’appuient sur RFC4180 sont motivés par l’envie d’aller dans le sens de la standardisation, tandis que d’autres sont des choix pour lesquels li y avait plusieurs façons de faire, chacune ayant ses avantages et ses inconvénients.

Pour prendre l’exemple du séparateur des décimales, est-il plus pratique pour l’attribuant d’utiliser le point ou de mettre la valeur entre guillemets afin que la virgule des décimales ne soient pas traitée comme un séparateur de colonne ? Ou bien doit-on passer aux point-virgules, moins reconnus par les outils, pour séparer les colonnes ? A mon sens il n’y avait pas de spec idéale, si ce n’est une spec claire qui lève toute ambiguïté sur sa mise en pratique.

Je n’ai plus les dates en tête, mais nous avons dû produire l’arrêté et le format attenant dans des délais très courts, ce qui n’a malheureusement pas permis l’organisation d’une consultation digne de ce nom, comme cela a été fait pour le schéma des données essentielles des marchés publics. Il est difficile de mobiliser les parties prenantes à répétition, car chacun doit dégager du temps, tant du côté des facilitateurs que du côté des participants. Le sujet étant moins chaud (PGO, engagements politiques, impact potentiel, écosystème préexistant plus riche…) que celui de la transparence des marchés publics (pour prendre un exemple), il a avancé plus discrètement.

Enfin les évolutions ont fait l’objet d’une discussion, c’est juste que vous auriez aimé y être convié :wink: Et les personnes qui ont contribué n’ont pas nécessairement envie de le faire en public. Après, cet espace de discussion est justement ouvert pour que la critique s’exprime. Et je vous remercie d’y contribuer.

1 Like

Damn, je ne pensais pas que le sujet était si sensible !

Merci pour toutes ces informations

L’arrêté stipule qu’une période de versement = AAAA-MM-JJ_AAAA-MM-JJ
Soit 2 dates exprimées en ISO 8601 et séparées par « _ »

Or dans le standard ISO 8601 (auquel se réfère l’arrêté), le séparateur de date est « / »
Est-ce une erreur ? Un choix délibéré ?

Bonjour,

La référence au standard ISO 8601 s’applique aux dates, mais pas au séparateur.

Lorsque j’ai rédigé le schéma, j’ai observé plusieurs façons de représenter des périodes, et je suis passé à côté de la standardisation du séparateur.

Edit : j’ai ctéé un issue sur Github https://github.com/etalab/format-subventions/issues/2

Bonjour,

La mise en place de ce format réglementaire est une excellente initiative ! Le choix du CSV plutôt que du JSON ou XML me paraît aussi très bon et bien adapté pour favoriser la publication de telles données.

J’imagine développer une application permettant de consommer de manière générique de telles données et je vais avoir besoin pour y arriver de données de test. Existe-t-il des fichiers ayant ce format plus volumineux que celui donné en exemple sur le repo ? Si ce n’est pas le cas, je vais essayer d’en constituer un. Je suis prêt le cas échéant à faire un peu de transformation de données, et si vous connaissez des jeux de données bien adaptés, je suis preneur. J’ai par exemple vu celui la mais j’ai l’impression que ça ne va pas etre simple de reconstituer les idBénéficiaire (les sirets ne correspondent pas à ce que j’ai dans la base Sirene).

Il y a par exemple ce jeu de données réel et qui se conforme à ce schéma :

https://data.haute-garonne.fr/explore/dataset/datalocale-subventions-du-conseil-departemental-haute-garonne/table/

1 Like

Une petite remarque/question : le format préconise l’usage de la virgule comme séparateur de champ. Mais sur certains portails qui reposent sur un format de données sous-jacent (je pense à OpenDataSoft), l’export des données en CSV se fait à la volée. Or OpenDataSoft, à ma connaissance, exporte en CSV avec des points virgule comme séparateur (uniquement sur les instances françaises j’imagine ?). Est-ce qu’on peut configurer ça en back office ? Sinon ça va être compliqué pour toutes les collectivités équipées avec ODS…

@OpenDataSoft vous en pensez quoi ?

J’ai fait un peu le tour d’Etalab aujourd’hui pour parler données subventions (@CharlesNepote a fait une étape en ma compagnie), et tous les voyants sont au vert pour une mise à jour de l’arrêté et donc du schéma. En effet, la situation aujourd’hui est confuse, et il serait préférable de repartir sur des bases saines avec une V2.

L’idée serait de partir de l’arrêté existant, de le modifier pour coller aux besoins, et de le soumettre à @Perica pour validation/signature. Ensuite on met à jour le Github, etc. Les contributions argumentées sont les bienvenues. Je pense qu’il faut voir cette « seconde chance » comme l’opportunité de créer un schéma qui rassemble les bonnes pratiques en la matière :

  • appui sur des standards
  • consultation des parties prenantes
  • documentation, etc.

Cette semaine je suis pris par la publication des données de la commande publique sur data.gouv.fr, mais la semaine prochaine je pourrai y consacrer du temps.

cc @loichay