Accueil Chantiers

Données publiques des communes : une fiche avant chaque script

Avant d'exploiter les données publiques de data.gouv.fr pour les sites de communes, nous décrivons chaque source dans une fiche. Le pourquoi de cette méthode.

Le chantier des données publiques pour les communes

Population, élus, logement, équipements sportifs : data.gouv.fr publie des jeux de données qui concernent directement une commune et ses habitants. Nous en exploitons déjà deux familles sur des sites en service. L'annuaire des associations s'alimente au répertoire national des associations, le RNA. Les pages consacrées au tourisme puisent dans la base DATAtourisme. Le chantier en cours vise à étendre ce modèle aux autres données publiques utiles à une commune. Depuis la mi-septembre, le travail a porté sur le cadre : un document qui fixe le rôle du projet et ses conventions, un fichier qui décrit les territoires suivis, un modèle de fiche pour chaque source, puis un premier inventaire. C'est ce choix de commencer par décrire plutôt que par programmer que nous expliquons ici.

Pourquoi une fiche par source avant le moindre script ?

Parce qu'un chiffre affiché sur le site d'une commune doit pouvoir être justifié. La fiche dit d'où vient la donnée, sous quelle licence elle est publiée, à quel rythme elle change et à quelle échelle elle existe. Sans ces réponses, un script ne fait que déplacer des chiffres.

Chaque fiche renseigne ainsi huit rubriques :

  • l'identifiant du jeu de données sur la plateforme
  • sa licence
  • sa fréquence de mise à jour
  • son mode d'accès
  • les champs qu'il contient
  • les échelles auxquelles il est publié
  • les publics à qui il peut servir
  • les usages envisagés sur un site

L'autre voie existait : brancher directement un programme sur un jeu de données, afficher le résultat, et documenter ensuite. Elle va plus vite la première fois. Elle laisse surtout des questions sans réponse le jour où un élu demande d'où sort un nombre, ou quand le producteur change le format de son fichier. Le modèle de fiche retenu oblige à répondre à ces questions une fois pour toutes, source par source, avant d'écrire une ligne de code. La licence décide de ce que l'on a le droit de republier. La fréquence décide du moment où une page devient fausse : une donnée annuelle affichée sans date vieillit sans que personne ne s'en aperçoive. Les publics et les usages, enfin, servent de filtre. Un jeu de données qui ne sert personne sur un site communal n'a pas à être intégré, même s'il est disponible.

Échelle communale ou intercommunale ?

De toutes les rubriques, l'échelle est celle qui pèse le plus sur la suite. Une donnée publiée pour chaque commune ne se traite pas comme une donnée publiée seulement à l'échelle de l'intercommunalité ou du département. Le fichier des territoires en tient compte : il recense les communes suivies, les intercommunalités auxquelles elles appartiennent, et des territoires composés sur mesure. Le premier inventaire a donc été dressé à deux niveaux à la fois, pour une petite commune rurale et pour son intercommunalité. Il a été réalisé avec le serveur MCP de data.gouv.fr, qui permet d'interroger le catalogue de la plateforme depuis un assistant de programmation. Cet inventaire reste brut. Il recense ce qui existe, il ne dit pas encore ce qui mérite d'être affiché.

Trois étapes encore devant nous

La prochaine est un script d'extraction. Il produira une première comparaison chiffrée entre plusieurs communes de montagne, chaque chiffre accompagné de sa source et de sa date. Cette comparaison doit ensuite devenir un article, publié sur un autre des sites que nous animons. Viendra alors le bilan, qui tient en une question : la chaîne complète, de la source à la fiche, de la fiche à l'extrait, de l'extrait à la publication, fonctionne-t-elle ? Nous n'avons pas de date à annoncer pour ces étapes.