Et oui, saison 3 car c’est le troisième billet quasi annuel sur le sujet… celui de l’évolution anarchique du découpage administratif français. (lire les premier et second épisode)

Le niveau le plus fin de ce découpage est la commune et chaque année des communes fusionnent, se regroupent, voire se séparent.

Ce mouvement s’est accéléré en 2016 avec des dispositions poussant les communes à se regrouper, en particulier avec une incitation financière (maintien de leurs dotations qui sinon ont tendance à baisser).

Chaque année ces modifications provoquent un grand bazar dans tout un ensemble de bases de données et de systèmes informatiques, car plutôt que d’organiser tout ceci et d’avoir une date fixe pour effectuer ces changements, on laisse encore les communes et les préfectures gérer ça à leur guise ce qui ne permet aucune coordination en la matière.

Bilan 2016

Le bilan 2016 n’est pas meilleur que 2015. On a bien sûr une grosse vague au 1er janvier, mais des changements se sont poursuivis tout au long de l’année, à commencer le… 12 janvier 2016 !

Les derniers et sûrement les plus ridicules sont des fusions avec date d’effet au 15 décembre 2016 et le grand gagnant est la commune nouvelle de Doué-en-Anjou effective au 30 décembre 2016… plutôt que d’attendre 48h de plus et faire ça au 1er janvier 2017.

Toponymes non conformes

A ce bazar, s’ajoute un second bazar, celui des toponymes… car l’an passé de nombreux nouveaux noms de communes ne respectaient pas les règles de toponymie. La commission nationale de toponymie avait d’ailleurs réagi (un peu tard) auprès du Ministère de l’Intérieur pour faire rectifier avant le mois de juin ces noms par un simple arrêté préfectoral rectificatif, car ensuite il faut passer par le Conseil d’État pour ce genre de changements (et à ma connaissance rien n’a été fait).

Malgré ce rappel des règles de toponymie (les espaces sont remplacés par des traits d’union dans les nom officiels sauf après un éventuel article en début de nom) les préfectures n’en ont tenu visiblement assez peu compte car on a encore de très nombreux noms de communes nouvelles incorrects.

Peu de progrès

Comme l’an passé, nous serons nombreux à fouiller les sites des préfectures pour trouver les arrêtés, mettre à jour nos données.

Comme l’an passé, bien peu de monde collaborera pour collecter ces informations et les partager.

Comme l’an passé, l’INSEE nous sortira un Code Officiel Géographique au mois de mars ou avril… et on ne peut pas leur jeter la pierre vu le manque d’organisation et l’anarchie qui règnent.

Côté services publics, le seul progrès notable se trouve du côté de l’IGN qui publie désormais “ADMIN EXPRESS” mensuellement en tenant compte des évolutions sans attendre la mises à jour du COG. On devrait donc avoir vers le 15 janvier l’état des communes au 1er janvier si tout va bien.

Données libres disponibles

La source libre la plus complète reste aujourd’hui wikipédia, où ce travail de fourmis a été réalisé avec la collaboration de contributeurs OpenStreetMap. Du côté OpenStreetMap, les fusions de 2016 ont toutes été intégrées (et les découpages précédents conservés car ils restent utiles) et celles de 2017 sont désormais disponibles sur data.gouv.fr

Afin d’automatiser les contrôles pour finaliser la mise à jour dans OpenStreetMap, j’ai transformé le contenu de l’article wikipédia en données au format json. Le projet est sur github, ainsi que les données.

Pour une meilleure organisation

Dans mon premier billet, je proposais un rétro-planning, le voici remis à jour:

  • publication au JORF au plus tard le 1er octobre avec date d’effet UNIQUEMENT au 1er janvier
  • mise à jour des référentiels au plus tard le 1er novembre (ça laisse 1 mois à l’INSEE pour mettre à jour le COG et l’IGN peut préparer ADMIN EXPRESS par anticipation pour le 1er janvier suivant)
  • mise à jour par les utilisateurs de leurs données : ils ont ainsi 2 mois pour être prêt avant la date d’effet
  • au 1er janvier tout le monde est déjà à jour ou plutôt n’a plus d’excuse pour ne pas l’être

Ce rétro-planning a d’ailleurs été imposé de fait par la DGFiP qui ne prend en compte que les modifications publiées par un arrêté préfectoral publié avant le 1er octobre. Toute autre modification n’est prise en compte par les services des impôts que l’année suivante et ceci a des impacts sur le calcul des taxes foncières, taxes d’habitation, le cadastre, etc.

Service Public de la Donnée

Ce type d’organisation devrait être définit par des textes réglementaires et s’inscrire dans le futur “Service Public de la Donnée”.

Il faut en effet non seulement organiser la diffusion de données de référence comme celle-ci, mais aussi mettre en place les conditions pour qu’elles puissent être produites en temps et en heure.

Actuellement ce n’est pas le cas et ce rétro-planning est de mon point de vue la meilleure solution pour améliorer la situation.

Dans les premières ébauches de ce SPD (basée sur l’étude d’impact de la loi pour une République Numérique), le COG n’avait même pas été identifié comme un jeu de données majeur. Il est pourtant utilisé dans la majorité des autres jeux de données qui avaient été inscrits comme relevant du SPD (le cadastre, la base d’adresse nationale, le référentiel à grande échelle, le registre des entreprises, le registre national des associations). Tous en effet se réfèrent au COG directement ou indirectement.

Donc encore un espoir que voir un réel progrès arriver en 2017… rendez-vous dans un an ?

Written by

40 ans d'informatique + 33 de base de données + 25 d'internet + 11 de cartographie = #OpenStreetMap + #opendata + #logiciel_libre

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store