Ce que nous avons appris lors des journées de l’open data par principe

[:fr]Photo prise à la fondation Mozilla lors de l’atelier consacré à data.gouv.fr

La semaine dernière, Etalab a participé aux journées de l’open data par principe. Nous avons organisé trois ateliers : le premier portait sur l’élargissement du service public de la donnée, le second traitait de l’aspect éditorial de data.gouv.fr, et le dernier était consacré au futur de la plateforme data.gouv.fr.

Ces ateliers nous ont permis d’aller à la rencontre des producteurs de données, des administrations, des journalistes, des utilisateurs, des membres d’associations et des citoyens. Merci à celles et ceux qui ont fait le déplacement pour venir échanger des idées avec nous.

Retour sur les trois ateliers

Élargissement du service public de la donnée

Nous avons demandé aux participants de réfléchir aux jeux de données qui pourraient intégrer le service public de la donnée, qui compte aujourd’hui 9 jeux de données de de référence.

La discussion a permis de répertorier plus d’une cinquantaine de jeux de données importants, potentiellement essentiels. Mais, parmi ceux-ci, seule une petite dizaine remplissait les trois critères qui permettent de parler de données de référence, critères définis dans la loi pour une République numérique :

  • des données qui servent à identifier ou nommer ;
  • des données fréquemment utilisées par des tiers ;
  • des données dont la qualité et la disponibilité est critique.

Voici les jeux de données qui remplissent a priori les trois critères évoqués plus haut :

  1. La base FINESS (fichier national des établissements sanitaires et sociaux) ;
  2. Base de référence des bâtiments (à constituer) ;
  3. Base des équipements sportifs (RES) ;
  4. Répertoire national des établissements (RNE) avec code UAI ;
  5. Base des numéros internationaux normalisés du livre (ISBN) ;
  6. Codes banques et guichets ;
  7. Données essentielles de la commande publique (DECP) ;
  8. Répertoire national des élus (RNE) ;
  9. Annuaire des services publics locaux produits par la DILA ;
  10. Système d’immatriculation des véhicules (SIV) ;
  11. Codes UPC/ GTIN (codes barres).

Nous avons aussi évoqué la possibilité d’intégrer dans le programme du service public de la donnée, des données qui ne répondent qu’à 2 des 3 critères établis par la loi. Une des pistes serait de développer un « incubateur de données », c’est-à-dire un programme d’accompagnement qui viserait à rendre ces jeux de données davantage réutilisables en travaillant sur plusieurs aspects : formats, documentation, interfaces de visualisation et téléchargement, croisement et enrichissement avec les neuf premières données de référence, et ainsi de suite…

L’aspect éditorial de data.gouv.fr

Nous avons sondé les participants pour savoir ce qu’ils espéraient trouver dans la description d’un jeu de données et quelles étaient les informations qui leur permettaient de gagner du temps dans leurs réutilisations.

Au terme de la présentation introductive, la discussion a tourné autour des thèmes suivants :

  • les fonctionnalités qui permettraient de mieux décrire les données (bien définir les titres des colonnes par exemple) ;
  • la difficulté de séparer le bon grain de l’ivraie dans le stock de données de data.gouv.fr ;
  • les idées pour inciter les réutilisateurs à référencer leurs créations sur data.gouv.fr (simplifier la démarche) ;
  • l’importance de montrer aux producteurs que leur données sont réutilisées par d’autres acteurs ;
  • les différents moyens de faire connaître des jeux de données peu utilisés (les mettre en avant selon l’actualité).

L’avenir de data.gouv.fr

Nous avons présenté l’architecture de data.gouv.fr, nos différentes façons de collecter des données à différents endroits. Puis les participants ont formé trois groupes pour parler des territoires, des schémas de données et des formats de données exotiques.

Après le diaporama de présentation de data.gouv.fr, les questions qui sont revenues le plus souvent concernaient :

  • la collecte et la traçabilité des données ;
  • les schémas de données et leur structuration ;
  • les obligations des territoires en matière d’open data ;
  • le rôle d’Etalab vis-à-vis des collectivités ;
  • la publication des codes sources.

Photo prise à la fondation Mozilla lors de l’atelier consacré à data.gouv.fr

Ce que nous avons appris

Lors des ateliers, des thèmes nous ont semblé revenir de manière assez récurrente. Les voici.

L’importance de l’accompagnement

Il n’est pas toujours évident de savoir par où commencer en matière d’ouverture des données publiques. Le sujet est vaste, il concerne les ministères comme les mairies, les développeurs comme les journalistes, les chercheurs comme les entrepreneurs, les experts comme les curieux. Une documentation claire autour de l’open data permettrait à ce sujet de toucher davantage de personnes, à l’intérieur mais aussi à l’extérieur des administrations, quelle que soit leur taille.

Par exemple, certaines municipalités aimeraient publier des données sur data.gouv.fr, mais elles ne savent pas par où commencer, elles auraient besoin d’être guidées, formées.

Les liens entre producteurs et réutilisateurs

Le site data.gouv.fr met en relation des producteurs de données et des utilisateurs de données, en ce sens il est une plateforme. Pour que cette plateforme fonctionne, il faut que les deux parties qu’elle met en relation (producteurs et réutilisateurs) puissent s’entendre sur ce qu’ils attendent les uns des autres. L’open data est un succès quand les producteurs mettent leurs données en ligne, pas uniquement pour respecter la loi, mais aussi pour en favoriser l’utilisation par des tiers — ce qui implique incontestablement un effort supplémentaire.

Par exemple, nombre de réutilisateurs de données publiques aimeraient avoir plus de contexte sur les données mises en ligne : d’où viennent-elles ? comment ont-elles été collectées ? la nomenclature utilisée correspond elle à un standard ? qui contacter en cas de question ?

Les ateliers ont déjà débouché sur des nouveautés

Du côté de data.gouv.fr, nous avons dépoussiéré le dépôt GitHub qui permet aux utilisateurs de nous signaler un bug ou de proposer une idée de fonctionnalité au moyen de tickets, sorte de messages qui nous permettent de déterminer ce sur quoi nous devons encore progresser.

Deux modèles de tickets ont été ajoutés, qui vous permettent de nous écrire sans rien avoir à improviser, comme si vous remplissiez un petit formulaire. Pour créer un ticket, vous n’avez besoin que d’un compte Github, dont la création est gratuite.

Comment rattraper si vous n’avez pas pu assister aux ateliers

Si vous n’étiez pas dans les parages la semaine dernière, vous pouvez tout de même vous faire une idée de ce qui s’est raconté. Nous avons publié les diaporamas de nos présentations sur GitHub.

Vous pouvez aussi suivre @datagouvfr et @etalab sur Twitter pour garder un œil sur notre prochains ateliers.[:]