Opportunité d'un collectif sur de la donnée essentielle de qualité

1

Alors que je poursuis mes réflexions sur la spécification de la liste des prénoms des nouveaux-nés, je n’ai pas trouvé à mon grand désarroi, de référentiel simple contenant les communes françaises avec leur nom officiel et leur code INSEE. Vous allez immédiatement me répondre d’aller voir le COG, dont ça devrait être le rôle : quoi de plus officiel que le Code Officiel Géographique produit par l’INSEE, qui permet justement d’y trouver le fameux code INSEE ? Qui plus est, le COG est un jeu du Service public de la donnée, donc un jeu considéré, à juste titre, comme un des jeux les plus importants de l’État.

Le COG cependant, pose problème :

  1. il faut reconstituer le code commune “entier” (de type 01001) à partir du code département (01) et du code commune court (001)
  2. le nom de la commune est séparée en deux lorsqu’il y a un article (Le),Mans (deux champs) au lieu de "Le Mans"
    J’ajoute, mais c’est presque secondaire, que le jeu est en ISO-8859-1, zipé, avec l’extension .txt et dans un format ésotérique : le standard CSV pour de la donnée de référence, c’est pas un minimum ?

Du coup ça complique beaucoup de devoir dire à des acteurs : vous prenez tel fichier du COG, vous agrégez les champs DEP et COM pour obtenir le code INSEE et vous reconstituez le nom de votre commune ou vos communes en agrégeant deux champs.
Je crois qu’on pourrait avoir un fichier tout de même considérablement plus efficace avec un peu de redondance en ajoutant le code INSEE complet et le nom en clair de type “Le Mans”. Il suffirait alors de dire aux acteurs : pour remplir ce champ, reportez vous au champ XXX du COG correspondant à votre commune.

Du coup je me suis produit mon propre petit fichier en 6 lignes de commandes (voir ci-dessous). Passé cette phase je me suis posé une question existentielle : et si je faisait profiter tout le monde de mon petit fichier ? et plus globalement, est-ce que ça aurait du sens de lancer une initiative pour publier des versions retravaillées de données fondamentales, dans un objectif de qualité et de simplicité d’usage ? Il pourrait s’agir d’un collectif informel qui créerait un groupe sur data.gouv.fr et proposerait 5 à 10 jeux de données essentielles de qualité respectant quelques principes simples tournés vers les usages.

Ça vous paraît inutile/délirant/farfelu/intéressant/indispensable ? À quelle données pensez-vous ?

#update : j’ai oublié de préciser que j’ai remonté ces problèmes du COG et demandé à Etalab s’ils peuvent faire évoluer le format, ce serait bien évidemment la meilleure solution.

Produire un fichier “nom de commune officiel + code INSEE” en 6 lignes de commandes (il faut installer csvkit (mais vous l’avez tous :wink: ; devrait fonctionner sous Linux et Mac, je ne garanti rien sur windows)

wget https://www.insee.fr/fr/statistiques/fichier/2666684/comsimp2017-txt.zip ; unzip comsimp2017-txt.zip
csvclean -t -e CP1252 comsimp2017.txt # conversion en CSV standard, UTF-8
csvcut -c DEP,COM,ARTMIN,NCCENR comsimp2017_out.csv > c3.csv # sélection des colonnes suffisantes pour obtenir le code commune et le nom de commune
perl -n -a -F, -e 'print "$F[0]$F[1],$F[2],$F[3]"' c3.csv > c4.csv # Fusion des colonnes DEP et COM pour obtenir le code INSEE complet
perl -p -e "s/ARTMIN,NCCENR/ARTMIN_NCCENR/; s/,\(/,/g; s/\),/ /g; s/\' /\'/g; s/,,/,/g" c4.csv > COG_communes_INSEE.csv
rm comsimp2017_out.csv c3.csv c4.csv
3 « J'aime »
2

Bonjour,

Il y a effectivement un gros déficit à ce niveau. Pour moi ce n’est pas à Etalab de faire le boulot de l’INSEE et de rendre les données accessible dans un format / protocole correct, c’est l’INSEE qui devrait mettre ce référentiel en place.

Le pire dans l’histoire c’est que les formats des données sont souvent propriétaires, durement réutilisables (fichier excel avec plein d’onglet et les données qui commencent a la cellule C6 par exemple), sans parler des métadonnées souvent au format PDF.

Il y a un troisième problème avec la manière dont le COG est publié : il faut faire la mise à jour à la main le 1er janvier de chaque année. On ne peut même pas créer un traitement périodique, on ne sait pas à quelle adresse le fichier sera publié. Pour info celui de l’année d’avant était disponible à cette adresse : https://www.insee.fr/fr/statistiques/fichier/2114819/comsimp2016-txt.zip. On peut imaginer incrémenter le nombre avant le nom du fichier de 55000 pour la prochaine fois pour trouver celui de l’année prochaine, mais a mon avis ça ne sera pas bon :). Le FTP de la DILA, bien que rudimentaire, a au moins le mérite d’être un peu structuré.

Pour info je suis entrain de revoir notre référentiel de données territoriales qui permet de récupérer les informations d’une ou plusieurs divisions administratives par API et je doit refaire des traitements particuliers pour chaque fichier pour les réagréger aux données déjà rentrées dans le référentiel. Les
données que je compte réimporter dans l’ordre de priorité :

  • Contours des territoires, pour la carto. Un bon boulot a été fait ici déjà : https://github.com/gregoiredavid/france-geojson/ mais le repo n’est pas a jour avec les nouvelles communes 2018
  • Le COG, pour avoir les libellés.
  • L’historique des divisions administrative, pour pouvoir redresser les autres données avec un code INSEE à jour. Vu comment les territoires bougent en ce moment (fusions de communes et régions), beaucoup de données ne sont plus à jour et donc pas projetables sur une carte actuelle. La base Sirene a par exemple des établissements avec le code commune 22123 alors que cette commune a été fusionnée depuis le 1er janvier 2018 et n’existe plus.
  • Le recensement de la population, la encore pour des besoins de carto et pouvoir ramener des données par rapport à la population
  • la fiscalté : tout est dans un gros fichier tabulaire avec 800 colonnes (REI)
1 « J'aime »
3

Christian Quest avait écrit quelques billets de blog (impossible de remettre la main dessus…) à ce sujet éminemment stratégique mais dont les pouvoirs publics n’ont visiblement pas encore pris la mesure.
J’avais à cette suite donné mon opinion dans un billet sans prétention https://donatrobaux.wordpress.com/2016/01/02/reforme-des-collectivites-territoriales-le-grand-capharnaum/

Avec OpenStreetMap, nous mettons un point d’honneur à ce que toutes les modifications de frontière soient fait dans les plus brefs délais (en général 2-3 jours après) et cette histoire de COG publié à M+3 nous mine le moral.
Au-delà du COG, c’est tout le système qui est à revoir, mais effectivement l’INSEE pourrait faciliter la réutilisation du fichier en apportant des modifications de base en attendant que cette histoire de décalage de la MaJ soit résolue.

2 « J'aime »
4

La proposition de créer un collectif informel via un groupe sur data.gouv.fr afin de centraliser les versions retravaillées de données fondamentales : je dis OUI :ok_hand:
L’idée étant de veiller collectivement à la mise à jour de ces dites versions retravaillées.

2 « J'aime »
5

Christian Quest avait écrit quelques billets de blog (impossible de remettre la main dessus…)



Au-delà du COG, c’est tout le système qui est à revoir

Pourquoi pas mais ça risque de prendre beaucoup de temps, c’est pourquoi je suggère d’avancer avec des choses simples et faisables.

2 « J'aime »
6

Pourquoi pas mais en attendant on fait quoi ? Le coeur de métier de l’INSEE c’est peut-être plus la collecte et la production que l’éditorialisation de données. Peu importe, rien ne nous dit que les producteurs de données essentielles vont se mettre à produire de la donnée ultra propre et facile à réutiliser.

J’entends bien vos remarques sur la mise à jour du COG mais ça alourdirait pas mal le process de production. Commençons peut-être par des choses simples : une version plus utilisable du COG communes à partir des données INSEE. La chaîne qui compare données OSM-wikipedia (à jour mais risquées) et données INSEE (pas à jour mais “certifiées”) pour en produire LE fichier idéal, ce n’est peut-être pas pour tout de suite.

Qu’est-ce que vous entendez par là ?

7

Nous utilisons le COG pour avoir un libellé à partir d’un code commune. Même si on retrouve les libellés dans pas mal de fichiers de l’INSEE, c’est celui la qui fait référence pour nous. J’avais oublié de dire que nous utilisons aussi le COG pour remonter dans la hiérarchie et par exemple agréger des données commune à un niveau région ou département. Apres ce que j’appelle COG par abus de langage est le fichier dans que vous utilisez dans votre script, ainis que les autres fichiers pour les autres niveaux de la hierachie.

Pour le “en attendant on fait quoi”, on pourrait mutualiser des scripts sur un repo github. Pour donner un coté officiel, ces scripts de redressement pourraient être hébergés dans le repo d’Etalab par exemple : https://github.com/etalab. On pourrait leur demander d’initialiser le repo et de fonctionner par merge request. On pourrait avoir pour le COG quelque chose similaire au cadastre : https://github.com/etalab/cadastre

Cette proposition contredit un peu ce que j’ai dit avant, mais l’idée d’accepter les contribution externes permettrait d’alléger en grande partie le boulot pour Etalab.

8

Je pense que la proposition de @CharlesNepote est pragmatique, et permet de montrer que les réutilisateurs se prennent en main. Et ça fera probablement bouger les producteurs et/ou Etalab (qui doit être aussi triste que nous).
Partant pour aider sur les données électorales, par exemple (pour lesquelles on a le même type de problème).

1 « J'aime »
9

(par ailleurs pour ton besoin spécifique, il est probablement plus aisé de partir de ce fichier-là par exemple : https://www.insee.fr/fr/information/2028028)

10

Même si ça ne remplace pas le COG, l’IGN publie les données mensuellement au niveau communal via http://professionnels.ign.fr/adminexpress. Des agrégations par EPCI sont aussi faîtes.
On peut avoir la donnée sous forme millésimée c’est à dire officielle pour une année. Cela permet de faire des jointures avec les données statistiques sans s’arracher les cheveux.

Pour les archives contours communaux, voir aussi le GeoFLA http://professionnels.ign.fr/geofla qui permet d’avoir des années plus anciennes (jusqu’à 2011).

1 « J'aime »
11

J’imagine que vous vous tapez l’agrégation des (Le), (La), etc., pour reconstituer le libellé complet… Pour pouvoir “remonter dans la hiérarchie” il suffirait probablement d’ajouter un peu de redondance dans le fichier des communes non ? La redondance n’est pas forcément mauvaise quand elle conduit à faciliter l’usage.

Oui, des scripts, voire des recettes et aussi des données retravaillées.

Je ne suis pas sûr qu’Etalab le souhaite et/ou le peuve compte-tenu de leur charge. Gérer des pull request est aussi un travail non négligeable. Notre collectif informel pourrait agir comme un bac à sable : lorsqu’une chaîne de conception/production/édition d’un jeu est solide et utile alors il sera toujours temps de proposer à Etalab de l’adopter (ou qu’ils nous le demandent avant).

Il faudrait commencer par se mettre d’accord :

  • sur quelques objectifs et règles simples
  • sur un process de travail simple
  • sur 2-3 jeux pour démarrer

L’objectif majeur de ce collectif seraient d’éditer des jeux de données essentielles de qualité, impliquant :

  • des jeux clairement sourcés et documentés (documentation intrinsèque et du process de production (scripts))
  • des jeux de données qui respectent les standards élémentaires en matière de données : UTF8, format CSV “officiel”
  • des jeux de données très opérationnels dont l’objectif est la simplicité d’usage : des données disjointes ou non-agrégées réunies au format tabulaire quitte à un peu de redondance ; des jeux plus allégés lorsqu’ils s’agit de très gros jeux inutilisables (découpage ou suppression de colonnes peu utiles (exemple de SIRENE))
  • des jeux éventuellement corrigés d’erreurs simples (en documentant)

Sur le process de travail :

  • Un repos Github pour chaque jeu : le responsable du repos est le responsable de l’édition
  • Chaque repos comprend une documentation du jeu, les scripts de production et le jeu (sauf très gros jeux (limite de Github ?))
  • Chaque jeu est ensuite publié sur data.gouv.fr sous l’appellation du collectif

Par quels jeux commencer ? Je pense qu’il faut démarrer par des choses TRÈS simples et utiles, en montrant qu’on peut améliorer significativement la publication de données très basiques :

  • une version du COG communes avec deux colonnes : code INSEE complet et libellé long
  • éventuellement une version du COG plus complète intégrant pour chaque commune la “hiéarchie” géographique en clair
  • la base des codes postaux avec des libellés COG (Sainte-Marie-de-Ré et pas STE MARIE DE RE) - https://www.data.gouv.fr/fr/datasets/base-officielle-des-codes-postaux/
  • autres ? SIRENE simplifiée ?

On peut commencer à plusieurs chacun gérant son repos Github. Je veux bien commencer avec le COG.

Si ça prend, il faudra trouver un nom.

3 « J'aime »
12

Oui et non. Le fichier en lui-même est pas mal du tout, mais je lui reproche plusieurs choses pour mon usage (un référentiel de libellés) :

  • c’est inutilisable par une machine
  • il y a plein de données, on s’y perd un peu, d’autant qu’elles ne sont pas sur le même plan et qu’elles sont disséminées dans des tas d’onglets : ça fait un peu peur lorsqu’on veut seulement avoir les communes françaises avec leur code INSEE, leur libellé et basta
13

pour le nom : la #TeamOpenData ? :wink:
sinon suis partant pour ce que tu proposes, je veux bien faire les résultats électoraux. Par contre mes scripts seront en R, pas en bash, désolé :wink:

14

@ThomasG77 : oui les données de l’IGN sont très bien sur le fond et plus à jour que celles de l’INSEE, mais vous avez vu leur format ? Ce n’est pas utilisable par un secrétaire de mairie lambda par exemple. Pour moi l’accessibilité et la simplicité d’usage sont primordiales.

1 « J'aime »
15

Je ne trouve pas gênant qu’ils soient en R ou en tout ce que vous voulez du moment que les traitements soient bien documentés (pas seulement le code). L’utilisateur doit pouvoir trouver des réponses claires à la question “mais comment ont-ils obtenu ce fichier ? ces données ?”.

1 « J'aime »
16

Cela dépend de l’usage: si c’est l’association code INSEE avec le nom, d’accord sinon pas d’accord: les données COG sont aussi merdiques à exploiter dans le cas où ce qui nous intéresse c’est la parenté entre communes (indépendamment que le format soit du CSV)

17

Si le but c’est trouver pour le nom le code INSEE ou l’inverse à la date courante, la GeoAPI https://docs.geo.api.gouv.fr/ remplace avantageusement le COG
Il faut une surcouche (formulaire d’autocomplétion) pour ne pas effrayer les utilisateurs non spécialistes

18

Oui oui, j’en conviens, la GeoAPI est aussi très bien, mais il faut une bonne culture informatique pour l’utiliser.

Je pense que nous devrions viser des publics plus larges : journalistes, secrétaires de petite marie, étudiants ou chercheurs “non-informaticiens”. Comment ces publics là peuvent-ils accéder à ce référentiel ultra-basique : le libellé des communes et leur code INSEE (sans préjuger trop de leur usage). Une version très accessible de ce(s) référentiel(s) pourra aussi servir aux spécialistes, mais ce n’est pas la cible première je pense.

Dans le titre de mon message, j’aurais peut-être du préciser “donnée essentielle accessible”.

19

À titre d’exemple, forcément à retravailler, j’ai publié mon COG simplifié (ou devrais-je dire « COG accessible » ou « COG facile »).

Le fichier est ultra-léger. Peut-être pourrais-je y ajouter quelques données sans trop complexifier.

Dans le readme.md j’ai essayé de documenter en partant du moins technique vers le plus technique. Idéalement le rubricage pourrait être même pour toutes les données du collectif :

  • Titre et description
  • Téléchargement
  • Licence
  • Motivation
  • Source des données
  • Process de production

Si on le fait au nom d’un collectif, il faudrait ajouter une partie « auteur » ou « éditeur » avec une explication du genre :
" Données accessibles est un collectif qui propose des données de référence rendues accessibles au plus grand nombre, dans le respect des standards internationaux. Retrouvez nos données en ligne sur le portail data.gouv.fr (lien vers la page du collectif sur datagouvfr)".

Pour le nom du collectif, comme les données s’adresseraient au plus grand nombre, je serais favorable de lui donner un nom sans anglicisme, un truc bien basique et facile à comprendre du type « Données pour tous ».

2 « J'aime »
20

É qué sapelorio “Qualidata”. :wink:

Plus sérieusement, pourquoi pas pusher sur Datahub ? La philosophie me paraît proche de l’idée “core data”