Avanies administratives et théorie des ensembles (Quantilille 2021)
Cette année, l’École d’été méthodes quantitatives en sciences sociales a proposé un module Analyse textuelle et un module Cartographie. Première nouveauté de l’école 2021, le recours au logiciel de gestion de versions décentralisé git pour diffuser les ressources utilisées pendant la formation —supports de présentation, scripts, données…—. Ce qui nous a ensuite permis de rendre ces ressources accessibles en ligne grâce au gitlab de l’Université de Lille.
De plus, même si les deux thèmes sont des classiques de l’école, l’édition de cette année a été l’occasion de les aborder d’une façon un peu différente. Le module Analyse textuelle a bien sûr traité l’analyse de données à la française au travers de l’ACM ou de la méthode Reinert. Mais il a aussi été l’occasion de présenter d’autres approches comme les modèles thématiques (Topic Models), l’apprentissage supervisé (Active learning) ainsi que les chaînes de traitement telles que le package R Quanteda.
Avanies et organisation administrative française
Le module Cartographie a lui principalement porté sur l’utilisation de QGIS et du package R sf (et un peu PostGIS, l’extension spatiale pour l’indispensable SGBD relationnel PostgreSQL). Mais au–delà des mises en pratique, le module a aussi été l’occasion d’essayer d’appréhender le traitement de l’information géographique un peu plus dans sa globalité. Car, ne serait–ce que faire des cartes, c’est se trouver au croisement des disciplines très diverses comme la géodésie, les mathématiques, l’informatique ou encore la sémiologie graphique mais aussi, de façon peut–être moins attendue, l’analyse des politique et de l’action publique. Et c’est notamment sur ce point que l’accent à été mis au travers de la présentation du Code officiel géographique (COG)1.
La connaissance des politiques conduisant à la définition des codes et normes géographique est ici fondamentale car l’information géographique est souvent calée sur des divisions administratives qui sont le produit de politiques anciennes —deux siècles et plus pour la France— et rarement congruentes sur le long terme. Les politiques publiques menées et surtout les empilements qu’elles produisent, ont donc des conséquences très concrètes lorsqu’on manipule des données géographiques, notamment du fait que le COG n’est pas une mappe injective. Ainsi, un code peut correspondre à plusieurs entités et une entités peut avoir plusieurs codes. But it’s not a bug, it’s a —legal— feature.
Les exemples les plus caractéristiques du COG concernent les communes. Il en existe en effet plusieurs types. Tout d’abord, différents textes distinguent ainsi les communes à arrondissements (Paris, Lyon et Marseille). Les informations les concernant peuvent donc être diffusées à la commune ou à l’arrondissement —parfois dans un fichier à part— ou, plus rarement, au deux niveaux.
Mais il existe des distinctions plus pernicieuses :
- les communes associées —loi no 71–588 du 16 juillet 1971 dite loi Marcellin—
- et déléguées —loi no 2010–1563 du 16 décembre 2010—
Ces textes s’inscrivent dans des politiques anciennes visant à réduire le nombre de communes en France. Ces politiques sont distinctes de celles visant à développer les coopérations intercommunales —même si elles ont fini par converger ces dernières décennies— car les lois de 1971 et de 2010 ont pour objet d’inciter les communes non pas à coopérer mais bien à fusionner.
Les conséquences pratiques de ces politiques sur le traitement de l’information géographique ont été abordées dans plusieurs présentations mais aussi dans des scripts manipulant les données du COG. Ce qui permet, en passant, d’illustrer l’utilité de maîtriser les notions élémentaires de théorie des ensembles —union, intersection, différence,…— lorsqu’on travaille avec des données et pas uniquement géographiques.
Les différentes ressources —présentations, scripts— traitant du COG dans le dépôt gitlab de l’école sont les suivantes :
- le code officiel géographique ainsi que les éléments réglementaires afférents sont présentés ici
- les rudiments utiles de la théorie des ensembles sont sommmairement présentés là
- ces rudiments sont illustrés dans dans la première partie de ce fichier de scripts R (la version html qui inclue les sorties est téléchargeable ici)
-
enfin, la manipulation du COG est illustrée à la suite du même fichier au travers de deux exemples :
- la génération d’une variable dichotomique distinguant collectivités de la Métropole et collectivités d’Outre–mer —sans utiliser de branchements ou des expressions régulières—
- l’appariement entre deux fichiers du COG : le fichier des communes et le fichier de composition des EPCI pour relier à chaque commune à son EPCI
Les données se trouvent, elles, dans ce dossier.
Un exemple donné dans la présentation du COG mais non inclus dans les scripts concerne le géoréférencement d’adresses. Du fait des fusions de commune, un même nom de voie peut correspondre à plusieurs voies différentes dans une même commune composite. Malheureusement, les différentes bases adresses disponibles ne distinguent pas toujours très clairement les communes associées-déléguées et les voies homonymes. À cela s’ajoute le fait que plusieurs communes peuvent avoir le même code postal mais différent du code postal des autres communes associées–déléguées. C’est par exemple le cas pour Lille qui compte deux communes associées —Lomme et Hellemmes— :
En mélangeant tout ça, on peut donc facilement obtenir des résultats défiant la géographie telle qu’on croyait la connaître si on n’y prend pas garde. Ce qui vérifie une fois de plus empiriquement la loi d’Audiard qui établit que les avanies ne s’additionnent pas, elles se multiplient. Traiter l’information géographique, c’est très vite s’aventurer dans l’enfer vert des référentiels et des données géographiques. Bien évidemment, l’Insee qui gère le COG ou encore l’IGNF ne sont pas en cause ici. Ils ne font que se conformer à la réglementation en application et à ses conséquences. D’où l’importance, ici comme ailleurs, de bien se familiariser avec la réglementation et les référentiels en application ainsi qu’aux politiques publiques à leur origine. Et de toujours bien lire la documentation…
Le fichier de scripts se termine par le développement d’un autre point abordé lors de la présentation sur PostGIS concernant las tables de hachage. Ces développements visaient à illustrer la notion d’indexation des données comme ceux utilisés par PostGIS ou sf. Certes, les index spatiaux utilisent des arborescences mais le fonctionnement des tables de hachage paraissait plus simple à expliquer dans un temps aussi limité. Le script montre aussi qu’on peut réaliser des opérations de bas niveau —manipulation d’octets— avec un langage de très haut niveau (R) lorsqu’on s’en donne la peine.
Enquête de recensement
La présentation traitant du COG aborde aussi une autre particularité de l’information géographique en France. En effet, depuis la loi no 2002-276 du 27 février 2002 relative à la démocratie de proximité, le recensement général de population (RGP) est officiellement devenu une enquête par sondage probabiliste.
Cette réfection du RGP est devenue effective à partir 2004, date de la première enquête annuelle de recensement. Dans les grandes lignes, la collecte est désormais étalée sur cinq ans selon des modalités différentes pour les communes de plus ou moins 10 000 habitants :
- les communes en dessous de ce seuil sont intégralement recensées un fois par cycle de cinq ans
- pour les autres communes, 8% des adresses sont enquêtées chaque année, soit un total 40% des adresses d’une commune à la fin d’un cycle
Toutes tailles de communes confondues, environ 70% des logements seront concernés par une enquête de recensement au bout de 5 ans pour un échantillon de plus de 40 millions de personnes. De plus amples détails sur la méthode de tirage des communes et des adresses ainsi que sur certains calculs se trouvent dans la présentation.
Les données issues du RGP diffusées par l’Insee sont donc désormais des estimations et non plus de simples additions2. En conséquence de quoi, ne soyez pas étonnés si parfois certains totaux ne sont pas répresentés par des entiers mais par des nombres flottants…Mais, surtout, il faut bien faire attention aux millésimes des fichiers. En effet, la méthode de collecte fait qu’on ne peut pas calculer les quantités d’intérêt de façon instantanée3. Ces quantités sont donc calculées pour l’année médiane d’un cycle, c-à-d en t_{-3}. Par exemple, les populations légales en vigueur en 2021 sont en fait des estimations de la population des commune en 2018. Toutefois, certains fichiers sont datés de l’année médiane. Ainsi, les données portant sur la structure de la population à la commune de 2016 ont été publiées en 2019 mais concernent bien 2016 tout en étant diffusées dans le découpage des communes de 2019 —puisque, comme on l’a vu précédemment, le nombre de communes change tous les ans…—.
D’où l’intérêt, là comme ailleurs, de se familiariser avec les normes, nomenclatures, méthodes,… à l’œuvre dans la production de données pour les utiliser à bon escient.
- Le COG est un répertoire maintenu par l’Insee qui renseigne notamment le code des différentes entités administratives françaises —communes, EPCI, cantons,…— [↩]
- C’est pourquoi les fichiers reportent souvent les coefficients de variation qui mesurent la précision de l’estimateur. On notera toutefois que si les chiffres issus des recensements précédents n’étaient pas, à proprement parler, des estimations, ils pouvaient, eux aussi, être entachés d’erreurs. [↩]
- À l’exception des communes de moins de 10 000 habitant l’année où elles ont été recensées [↩]
OpenEdition suggests that you cite this post as follows:
Thomas Soubiran (July 30, 2021). Avanies administratives et théorie des ensembles (Quantilille 2021). NUMA. Retrieved March 28, 2025 from https://doi.org/10.58079/sgp0