<figure><img src="image_1.png" /></figure>

HAL
open science

# Statistiques fondées sur des données administratives :
Esquisse d'un cadre général

Heidi Koumarianos, Pascal Rivière

► To cite this version:

Heidi Koumarianos, Pascal Rivière. Statistiques fondées sur des données administratives : Esquisse d'un cadre général. 2025. hal-05382380

HAL Id: hal-05382380

https://insee.hal.science/hal-05382380v1

Preprint submitted on 25 Nov 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Statistiques fondées sur des données administratives : Esquisse d'un cadre général

## Document de travail

N° M2025-03 – Juin 2025

<figure><img src="image_3.png" /></figure>

Heidi KOUMARIANOS
Pascal RIVIÈRE
<figure><img src="image_4.png" /></figure>
INSTITUT NATIONAL DE LA STATISTIQUE ET DES ÉTUDES ÉCONOMIQUES

Série des documents de travail « Méthodologie Statistique »
de la Direction de la Méthodologie et de la Coordination Statistique et Internationale

M 2025/03

Statistiques fondées sur des données administratives :
Esquisse d'un cadre général

Heidi KOUMARIANOS
Pascal RIVIÈRE

Insee

JUIN 2025

Remerciements :

Les auteurs souhaitent remercier Hélène Chaput, Olivier Haag, Pierre Lamarche, Joël Bizingre, Mylène Chaleix, Élise Coudin, Pascale Breuil, Éric Lesage et Corinne Prost pour leur relecture commentée et active du rapport.

<figure><img src="image_5.png" /></figure>

Direction de la méthodologie et de la coordination statistique et internationale

Département des Méthodes Statistiques -Timbre L001 -

88 Avenue Verdier - CS 70058 - 92541 Montrouge Cedex - France -

Tél. : 33 (1) 87 69 55 00 - E-mail : DG75-L001@insee.fr - Site Web Insee : http://www.insee.fr/

Ces documents de travail ne reflètent pas la position de l'Insee et n'engagent que leurs auteurs.

Working papers do not reflect the position of INSEE but only their author's views.
<figure><img src="image_6.png" /></figure>
# Résumé

La mobilisation de données administratives pour la production de statistiques et les questions qui l'accompagnent ne sont pas nouvelles dans les statistiques officielles, mais elles ne donnent pas lieu à un cadre méthodologique équivalent à ce qui existe pour les enquêtes. Cet usage peut parfois être perçu à tort comme immédiat, puisque les données « existent » déjà, et qu'elles ne nécessitent pas la mise en œuvre par le statisticien d'un processus de collecte pour les obtenir.

Cependant, cette absence de collecte n'est qu'une illusion de simplicité : elle est aussi le signe d'une perte de maîtrise sur les modalités d'obtention des données, leur temporalité, la définition des variables, des nomenclatures, les possibilités de vérification ... Au total, pour ces nouvelles sources de données, c'est tout un pan du processus de production statistique qu'il faut repenser, pour tenir compte des nouvelles questions qu'elles soulèvent.

Les données administratives sont liées, par leur nature même, à un univers particulier, avec ses objectifs, son langage, ses catégories, ses dynamiques. Sous-produits de l'activité de l'administration, elles ne sont en aucun cas « données », et peuvent se révéler très éloignées de l'univers de l'utilisateur. Leur utilisation à des fins statistiques soulève des problématiques de qualité particulières, le concept de qualité étant subordonné à l'usage. Elle requiert une transition du monde administratif au monde statistique, un détachement de l'un pour se réattacher à l'autre. Cela ne peut se faire sans difficultés, sans frottements : c'est la notion de *data friction*.

Pour effectuer cette transition rigoureusement et dans de bonnes conditions, une grille d'analyse est nécessaire. Elle se présente sous la forme de 5 axes : objet (ou unité statistique), population et champ, variable, domaine (ou catégorisation), temporalités.

On propose ici une démarche fondée sur cette grille, et qui se décompose en 3 phases : acquisition, transformation, traitement statistique.

* La phase d'acquisition part des données du SI administratif, non conçu pour les statistiques, car hétérogène, épars, mouvant, lié à un usage métier. Elle vise à rassembler, documenter, filtrer mais aussi figer, pour arriver à une « source administrative » utilisable.

* La phase de transformation vise à passer de l'univers administratif à l'univers statistique.

* La phase de traitement statistique correspond à une étape classique, que l'on retrouve aussi dans les enquêtes.

Pour chacune des phases, on met en évidence l'importance de « boucles de rétroaction », dans l'esprit du *data tracking* : pour assurer la qualité des données, donc des statistiques produites, il faut effectuer des retours arrière. C'est d'autant plus difficile que, contrairement aux enquêtes, on n'a pas la pleine maîtrise des concepts. Il en découle de nombreuses vérifications, à plusieurs niveaux : en cas d'anomalie, cela conduit à remonter en amont dans le processus, y compris jusqu'à la source. Ces boucles sont de natures très différentes selon les phases. Au total, en raison du besoin de qualité et d'explicabilité des résultats, l'enchaînement des phases n'a rien de linéaire.

Si le document propose un cadre général, sa mise en pratique peut nécessiter certains ajustements en lien avec des contraintes pratiques (de volume, ou de temps, par exemple). Adapté à une situation de mono-source administrative, il peut s'étendre : les principes proposés s'appliquent aussi en bonne partie aux données privées, avec des difficultés supplémentaires (champ, confidentialité, conventions, coût, ...). Ils peuvent aussi être replacés dans un contexte multi-sources, en associant données administratives et enquêtes, ce qui pose là aussi de nouvelles questions.

**Mots clés** : données administratives, qualification, métadonnées, processus, transformation, boucle de rétroaction, GSBPM

**Classification JEL** : C80, C40
<figure><img src="image_7.png" /></figure>
# Table des matières

<table><tr><td>Introduction</td><td>3</td></tr><tr><td>A. Caractérisation des données d'enquête et des données administratives</td><td>5</td></tr><tr><td>1. Production de statistiques à partir d'enquêtes : propriétés implicites et explicites</td><td>6</td></tr><tr><td>1.a. Représentation mathématique classique... et grille d'analyse</td><td>6</td></tr><tr><td>1.b. Appareil d'observation en deux temps</td><td>8</td></tr><tr><td>1.c. Besoin de vérifications à différents niveaux</td><td>9</td></tr><tr><td>1.d. Caractérisation des statistiques issues d'enquête</td><td>10</td></tr><tr><td>1.e. Représentation du processus : le GSBPM</td><td>12</td></tr><tr><td>2. Produire des statistiques à partir de données administratives</td><td>13</td></tr><tr><td>2.a. Quelques caractéristiques des données administratives</td><td>13</td></tr><tr><td>2.b. Notion de donnée ... et nouvelle grille d'analyse</td><td>15</td></tr><tr><td>2.c. Données administratives en vue d'un usage statistique</td><td>16</td></tr><tr><td>2.d. Statistiques issues de données administratives vs statistiques issues d'enquêtes</td><td>21</td></tr><tr><td>2.e. Conséquence sur le processus, comparé aux enquêtes</td><td>22</td></tr><tr><td>3. Système d'information administratif et sources administratives</td><td>24</td></tr><tr><td>3.a. La notion de système d'information administratif</td><td>24</td></tr><tr><td>3.b. Figer les données : une construction nécessaire, des choix décisifs</td><td>25</td></tr><tr><td>3.c. La « source administrative » : un concept fragile</td><td>29</td></tr><tr><td>3.d. La difficile transition d'un univers métier à un autre</td><td>31</td></tr><tr><td>3.e. Statistiques fondées sur données administratives : une démarche en trois phases</td><td>34</td></tr><tr><td>B. La démarche proposée</td><td>36</td></tr><tr><td>4. La phase d'acquisition : vers une source administrative qualifiée</td><td>37</td></tr><tr><td>4.a. Principes</td><td>37</td></tr><tr><td>4.b. Le temps de préparation : source, écosystème, convention</td><td>38</td></tr><tr><td>4.c. Qualité des données administratives : une notion contingente</td><td>42</td></tr><tr><td>4.d. Le temps de réception - qualification</td><td>45</td></tr><tr><td>4.e. La boucle de rétroaction avec l'entité administrative</td><td>50</td></tr><tr><td>4.f. Le cas des usages répétés et multiples</td><td>52</td></tr><tr><td>4.g. Résultat de la phase d'acquisition et passage à la phase suivante</td><td>54</td></tr><tr><td>5. La phase de transformation : passer du monde administratif au monde statistique</td><td>56</td></tr><tr><td>5.a. Principes</td><td>56</td></tr><tr><td>5.b. Les principales opérations de la phase de transformation</td><td>57</td></tr><tr><td>5.c. Un processus qui est aussi technique, et doit être réplicable</td><td>62</td></tr><tr><td>5.d. Qualifier les données transformées</td><td>63</td></tr><tr><td>5.e. Une boucle de rétroaction à deux niveaux</td><td>65</td></tr><tr><td>5.f. Résultat de la phase de transformation</td><td>67</td></tr><tr><td>6. La phase de traitement statistique</td><td>69</td></tr><tr><td>6.a. Contexte</td><td>69</td></tr><tr><td>6.b. Les traitements proprement dits</td><td>70</td></tr><tr><td>6.c. Qualification et rétroaction : l'importance de l'output editing</td><td>73</td></tr><tr><td>6.d. Résultat de la phase de traitement statistique</td><td>74</td></tr><tr><td>C. Synthèse</td><td>76</td></tr><tr><td>7. Synthèse et mise en perspective</td><td>77</td></tr><tr><td>7.a. Résumé de la démarche proposée</td><td>77</td></tr><tr><td>7.b. Mise en œuvre</td><td>81</td></tr><tr><td>7.c. Prolongements</td><td>83</td></tr><tr><td>Bibliographie</td><td>84</td></tr></table>
Annexe 1 : Typologies possibles pour les données administratives................................................95

Annexe 2 : Dimensions pour caractériser la qualité des données administratives selon Istat.....100

Annexe 3 : Liste des sources de données administratives citées en exemple..................................101
## Introduction

La formalisation de l'échantillonnage probabiliste, dans les années 1930 (Neyman 1934) a rendu possible la réalisation d'enquêtes à coûts raisonnables, car appliquées à de petites populations (Ardilly 2006). Cette démarche s'est largement répandue, devenant la norme pour les statisticiens publics, en parallèle à la pratique des recensements (Desrosières 1993). Dans le monde entier, un vaste savoir-faire s'est peu à peu échafaudé, enrichi, consolidé, autour d'un corpus de méthodes (d'échantillonnage, de conception de questionnaire, de traitement de valeurs manquantes, ...), de pratiques, reconnu par la communauté académique, officialisé dans les instances internationales de statisticiens. Un « métier de statisticien » a ainsi progressivement émergé (Volle 1980).

Parallèlement, chaque pays cherchait à exploiter ses propres données administratives à des fins de statistique publique, en complément des enquêtes. Certains, notamment les pays nordiques, les ont intégrées, historiquement, de façon massive (Wallgren, Wallgren 2007). En France, l'Insee mobilise des données administratives depuis sa création. Les déclarations de données sociales, notamment, constituent une source majeure largement et régulièrement utilisée depuis les années 50. De manière générale, dans un contexte où les enquêtes sont de plus en plus difficiles à réaliser (Meyer, Mok, Sullivan 2015), les données administratives jouent un rôle essentiel en statistique publique. Elles permettent : de construire des répertoires de référence (Wallgren, Wallgren 2016, Lefebvre 2024), d'apparier avec des données d'enquêtes et ainsi d'enrichir la palette des données (Koumarianos, Lefebvre, Malherbe 2024, Brion, 2011), de s'inscrire dans un système général d'acquisition de données pour un usage statistique (Bakker, Van Rooijen, Van Toor 2014), de pallier des non-réponses (Bycroft, Mateson-Dunning 2020), d'évaluer des sources de biais (D'Aurizio, Papadia 2019), de fournir des totaux pour réaliser un calage sur marges (Deville, Särndal 1992), d'améliorer les mesures de population à un niveau géographique fin (Zhang 2021), entre autres.

Un ensemble de données administratives peut aussi être utilisé seul pour l'élaboration de statistiques. C'est sur ce sujet précis que va se concentrer ce document, afin de bien caractériser les composantes de ce processus, en tenant compte des propriétés particulières des données administratives. On exclut donc ici toute réflexion sur les appariements, sur les combinaisons de sources, sur les contrôles, le calcul de précision... De même, on laissera de côté toute une série de thèmes régulièrement attachés aux données administratives dans la littérature académique : confidentialité, acceptabilité, éthique, cadre légal, ...

Lorsqu'on élabore des statistiques à partir de données administratives, on se trouve dans une situation étrange où « les données existent déjà », ce qui semble, en première approche, faciliter considérablement le travail en comparaison à une enquête : il n'y a ni questionnaire à construire, ni échantillon à sélectionner, ni processus de collecte à dérouler. En réalité, on se retrouve dans un contexte fondamentalement distinct, où les exigences sont d'une autre nature et où les processus génériques ne sont pas extrêmement cadrés, contrairement à ce qui se passe pour les enquêtes. Pour celles-ci, le General Statistical Business Process Model (GSBPM) propose désormais un modèle reconnu et partagé par les instituts nationaux de statistique (Unece 2019), dont seule une partie est pertinente pour le cas des sources administratives.

On constate ainsi que s'il existe de nombreux papiers parlant de statistiques produites à partir de données administratives sur des jeux de données précis<fnref n="1" />, si l'on rencontre quelques papiers très généraux (Hand 2018, Zhang 2012, Rouppert 2005), on ne trouve pas, ou peu, de véritable cadre conceptuel pour les statistiques fondées sur des sources administratives en général. Or l'utilisation de nouvelles sources en lieu et place de données d'enquête constitue un changement beaucoup plus

<footnote n="1">1 Sujet souvent abordé aux Journées de méthodologie statistique de l'Insee, par exemple.</footnote>
profond qu'il n'y paraît (Elbaum 2018), qui est susceptible d'offrir de réels avantages, mais qui présente des limites, et qui nécessite de remettre en cause des idées préconçues et une partie des méthodes de travail. On trouve ainsi chez Salgado et Oancea (2020) une comparaison poussée des différents types de sources (données d'enquête, administratives, numériques) sur le plan méthodologique, mais aussi en termes de qualité, de technologie et d'accessibilité.

Le présent document de travail propose une ébauche de réflexion en ce sens, avec d'abord trois parties posant les bases du sujet, en caractérisant données d'enquête et données administratives, puis trois autres portant sur la démarche proposée, et enfin une synthèse.

Le chapitre 1 traitera des statistiques « classiques », issues d'enquêtes, en cherchant à mettre en évidence les propriétés qu'elles embarquent, explicites ou non.

Avoir ainsi un cadre d'analyse permettra, dans un 2e chapitre, d'aborder les « données administratives» et la base de leurs principales propriétés : on pourra ainsi les mettre en regard des données d'enquête, pour mieux analyser leurs avantages et leurs limites d'utilisation. Mais ces données ne sont jamais isolées : elles font partie de ce qu'on nomme « source administrative », sans bien savoir de quoi il s'agit.

Le chapitre 3 montrera qu'une telle source découle en réalité d'un « système d'information administratif », incorporant toute une vision métier, objet méconnu, insaisissable, et pourtant décisif. Or passer de l'univers administratif à un autre univers (statistique, ou recherche, par exemple), ne se fait pas sans frictions et sans transformations, pouvant même remettre en question la pertinence de l'adjectif « brut ». On déduira de tout cela une représentation du processus de production statistique issu de données administratives en trois grandes phases : acquisition, transformation, traitement statistique.

Le 4e chapitre sera consacré à la phase d'acquisition, c'est-à-dire de récupération de sources de données administratives conformes, bien structurées, documentées. On insistera particulièrement sur la notion de qualité, la démarche de qualification pour mieux l'appréhender et la nécessaire boucle de rétroaction pour l'améliorer. L'acquisition est probablement la phase la plus méconnue et la moins formalisée dans la littérature.

Le chapitre 5 portera sur la phase de transformation, qui permet de passer de l'univers administratif (avec son langage, ses objectifs opérationnels, sa sémantique) à l'univers statistique. Il s'agit ici d'une succession d'étapes que l'on va chercher à automatiser, ce qui n'enlève pas l'intérêt de vérifications, d'une autre nature. A l'issue de cette phase, on aura donc un jeu de données qui entre parfaitement dans la logique d'un usage statistique.

La phase de traitement statistique sera décrite de manière beaucoup plus succincte dans un 6e chapitre : en effet, ce sont les traitements statistiques habituels, comme pour une enquête, et l'on devra simplement déterminer où le caractère administratif des données peut avoir quelques impacts. Enfin, dans une dernière partie, après avoir synthétisé la démarche, on s'interrogera sur ce qu'on peut tirer de tout cela sur un plan pratique, tout en ouvrant quelques pistes prospectives.
A. Caractérisation des données
d'enquête et des données
administratives
# 1. **Production de statistiques à partir d'enquêtes : propriétés implicites et explicites**

Pour Lessler et Kalsbeek (1992), une enquête est une « étude scientifique sur une population existante d'unités représentées par des personnes, institutions ou objets physiques ».

L'Insee, et plus généralement le Service statistique public (SSP), a une longue expérience des enquêtes, et de la fabrication de statistiques fondées sur des données d'enquêtes. Au fil des années, des méthodes ont été conçues, documentées, enrichies, des outils ont été développés sur cette base, des organisations ont été mises en œuvre, notamment pour la réalisation de la collecte, qu'il s'agisse d'enquêtes auprès des ménages ou des entreprises. Des connaissances pratiques, des habitudes de travail, des tours de main se sont construits.

Pour les comprendre, les mettre en évidence simplement, on va ici volontairement s'appuyer sur une représentation très simplifiée, facilitant l'explication et la comparaison entre statistiques d'enquête et statistiques issues de données administratives.

## 1.a. Représentation mathématique classique... et grille d'analyse

Le point de départ est simple : on est confronté à une situation dans laquelle on veut estimer le total d'une variable sur une certaine population. Par exemple : le chiffre d'affaires total de chaque secteur d'activité, le nombre de chômeurs par région. On a souvent à estimer une moyenne, ce qui est la même chose en divisant par le nombre d'individus (par exemple : âge moyen dans une commune), ce qui revient à un ratio d'agrégats.

Ramenons-nous pour simplifier à un total. On veut donc estimer le total d'une variable X sur une population U pour une période / date de référence t :

$$X^t = \sum_{i \in U} X_i^t \quad (1)$$

Lorsqu'on réalise une enquête, on connaît souvent la population U, pour laquelle on dispose d'une base de sondage. Dans cette base, on tire un échantillon S aléatoirement, avec des probabilités d'inclusion connues, la théorie des sondages nous permet de construire un estimateur permettant d'approcher ce total :

$$\hat{X}^t = \sum_{i \in S \subset U} w_i X_i^t \quad (2)$$

où, dans l'estimateur d'Horvitz-Thompson (1952), les pondérations $w_i$ sont les inverses des probabilités d'inclusion.

Dans les faits l'expression (1) est trop générale. En premier lieu, les statistiques calculées le sont pour une certaine « case » de tableau, par exemple toutes les personnes ayant entre 25 et 34 ans, ou bien toutes les entreprises relevant du commerce de détail : on s'intéresse donc aux entités relevant d'une certaine sous-population (ou catégorie) $C_k$. Par ailleurs, on cherche le total de X à une certaine date, par exemple le chiffre d'affaires total dans le commerce de détail en 2023, $X^{2023}$.
Le total qu'on veut approcher s'exprime donc plutôt sous la forme :

$$X_{C_k}^t = \sum_{\substack{i \in U \\ i \in C_k}} X_i^t \quad (3)$$

où t est la période, par exemple une année.

Pour l'estimer, on va tenir compte de l'échantillonnage (et introduire, donc, les poids de sondage), mais aussi du fait que certaines valeurs $X_i^t$ sont manquantes ou aberrantes, ce qui conduit à les imputer<fnref n="2" />, sur la base d'un modèle d'imputation. On note $\tilde{X}_i^t$ la valeur imputée.

L'estimateur s'écrira :

$$\hat{X}_{C_k}^t = \sum_{\substack{i \in S \subset U \\ i \in C_k}} w_i \tilde{X}_i^t \quad (4)$$

Dans cette formule très simple, $\tilde{X}_i^t = X_i^t$ si la valeur est conservée<fnref n="3" />, et s'appuie sinon sur un modèle. On pourrait évidemment complexifier, en ajoutant le calage sur marges, par exemple.

La représentation probabiliste associée aux enquêtes rend techniquement possible un calcul de variance de l'estimateur, et plus généralement un calcul de total survey error<fnref n="4" /> (Groves, Lyberg 2010 ; Lyberg, Weisberg 2016 ; Biemer et al. 2017) : ainsi, dans la formule précédente, l'échantillon S et la valeur imputée $\tilde{X}_i^t$ sont des variables aléatoires<fnref n="5" />. On peut également chercher à estimer une évolution, et là aussi on peut calculer une précision, qui fait intervenir les probabilités jointes d'inclusion : en d'autres termes, d'une manière ou d'une autre, on sait peu ou prou quantifier l'incertitude, la marge d'erreur<fnref n="6" />.

Pour matérialiser tout cela, et obtenir en pratique la population, les observations, l'appartenance aux catégories, ... on va mettre en œuvre un processus d'observation, pour approcher au mieux les différents aspects évoqués qui figurent dans la formule initiale de l'agrégat à estimer. La formule (4) montre qu'on a besoin de cinq composantes (Figure 1):

1. L'unité (i)

2. La population, le champ (U)

3. La variable (X)

4. La catégorisation (C)

5. La temporalité (t)

<caption>**Figure 1 – Grille d'analyse des données d'enquête**</caption>

<footnote n="2">2. Bien entendu on pourrait non pas imputer, mais repondérer.</footnote>

<footnote n="3">3. Elle n'est pas conservée lorsqu'on effectue une imputation, par exemple.</footnote>

<footnote n="4">4. L'idée de la *total survey error* est de construire une mesure d'erreur qui aille au-delà du calcul de la variance d'échantillonnage, mais tienne compte d'autres composantes de l'erreur (ex. erreur d'imputation). Cela mériterait un développement en soi, qui sort du cadre du présent document. On se borne ici à citer des références.</footnote>

<footnote n="5">5. On présente ici une formule simplifiée, avec des composantes majeures de l'erreur, en premier lieu l'erreur d'échantillonnage, mais la littérature académique sur le sujet en distingue bien d'autres.</footnote>

<footnote n="6">6. Hand (2018) : « statistics is the technology of extracting meaning from data and of handling uncertainty. »</footnote>
1.b. Appareil d'observation en deux temps

Le cadre méthodologique de la statistique d'enquête ne se limite pas à un attirail de formules mathématiques. Il s'agit, plus généralement, de réaliser un appareil d'observation, comme il en existe dans d'autres domaines : en archéologie, en biologie, en astronomie ... (Borgman 2015). Chacun de ses dispositifs présente ses propres spécificités, mais aussi ses propres fragilités, comme le soulignent (Borgman et al. 2016) pour l'astronomie, par exemple.

Qu'en est-il de l'observation de la réalité socio-économique à partir d'une démarche d'enquête ? La particularité de l'appareil d'observation statistique, c'est qu'il vise à observer des phénomènes « macro », sur toute une population (emploi, pauvreté, délinquance, santé, ...). Pour cette raison, il fonctionne en deux temps : d'abord le recueil et la mise au point d'un « grand » nombre d'observations individuelles, pour en déduire dans un deuxième temps des usages statistiques, avec en particulier des agrégats, qui sont en quelque sorte des observations macroscopiques.

Pour obtenir une observation individuelle, on utilise un *instrument d'observation* qui s'appelle le *questionnaire* (en biologie, ce serait le microscope, par exemple). Et ce qu'on va appeler ici le *système d'observation*, c'est ce qui produit l'ensemble de ces observations individuelles, pour les unités de l'échantillon.

Ce système nécessite, pour chaque enquête, un long travail préalable de conception, puis de construction (comme si on devait reconstruire un télescope à chaque fois), et enfin de mise en œuvre opérationnelle, que l'on appelle la *collecte*, cette mise en œuvre s'appliquant à la fois à la population<fnref n="7" /> et aux variables à observer.

On a ainsi :

* La conception : questionnaire (on élabore un moyen de trouver les $X_i$ via un questionnement), élaboration de la base de sondage, échantillonnage (les unités i), choix du mode de collecte ...

* La construction : réalisation du (des) support(s) de collecte, mise au point du protocole<fnref n="8" />

* La mise en œuvre : la collecte elle-même.

Le 1er niveau d'observation, c'est l'ensemble des données individuelles obtenues : c'est le résultat de la collecte, qui se matérialise par un ou plusieurs fichiers. C'est en quelque sorte un produit intermédiaire, à certains égards, caractérisé par une représentation tabulaire : un « rectangle » de $p$ variables pour $n$ individus. Pour aboutir à cela, toute une série d'itérations sont nécessaires. Bien sûr, c'est un peu plus compliqué que cela en pratique, mais on peut se limiter à cette vision simplifiée pour notre propos sans perdre en généralité.

Le 2e niveau d'observation a comme point de départ ce fichier, ce rectangle, et a comme résultat un ensemble de statistiques<fnref n="9" /> (agrégats, moyennes, ratios, quantiles, caractéristiques de distribution ...). Il s'agit en premier lieu de le compléter, de le finaliser (ou presque) : l'imputation des données

<footnote n="7">7 En toute rigueur, il faut distinguer l'unité de collecte (auprès de laquelle on collecte) et l'unité statistique (au sujet de laquelle on collecte) : pour les enquêtes auprès des entreprises, l'unité de collecte peut être un cabinet comptable.</footnote>

<footnote n="8">8 Y compris des protocoles complexes, comme c'est le cas avec le multimode (Beck et al 2022).</footnote>

<footnote n="9">9 Bien entendu il y a d'autres usages, notamment économétriques, mais dans une démarche simplificatrice, on se centre ici sur les statistiques descriptives.</footnote>
manquantes ou aberrantes, mais aussi la catégorisation ($C_k$)<fnref n="10" />, dont on a vu l'importance dans la partie précédente ; par exemple, le codage d'une cause de décès (Coudin, Robert 2024), à partir de plusieurs libellés et d'autres informations, tout cela exigeant un important travail d'interprétation. Sur cette base-là on construit ensuite les statistiques elles-mêmes, avec des méthodes statistiques d'estimation, de traitement de la non-réponse totale, de calage sur marges,...

Le fait que le processus de traitement repose sur des modèles statistiques permet, au moins en principe, d'estimer une variance, avec ses différentes composantes. En d'autres termes, ayant tous les leviers du processus d'élaboration des statistiques, ayant un cadre mathématique, on est capable de mesurer l'erreur, dans ses différentes dimensions : la statistique d'enquête permet, et c'est là sa grande force, la maîtrise de l'erreur (Deville 1997). À noter que dans le cas des statistiques en évolution, toute cette mécanique nécessite une certaine constance dans le temps de la grille d'analyse : les variables X, les unités i, les catégories $C_k$, la population U, etc.

### 1.c. Besoin de vérifications à différents niveaux

Un des aspects centraux du processus d'enquête, c'est le vaste travail de vérification, automatique et manuel, qu'il requiert, et ce à différentes étapes. Pourquoi ? Les statistiques publiques peuvent avoir de nombreux utilisateurs, qui très naturellement vont être tentés de les « mettre en regard » avec d'autres statistiques (en comparant avec des périodes antérieures, ou bien avec d'autres statistiques équivalentes). Assurer cette comparabilité dans l'espace et le temps<fnref n="11" />, et donc donner des gages de cohérence, fait partie des exigences de la statistique publique, de même que la capacité à expliquer et à justifier les statistiques, dans un souci de transparence.

Il existe donc naturellement de nombreuses vérifications, de natures et surtout de temporalités diverses, associées ou non à des imputations automatiques : c'est ce qu'on regroupe sous le terme de *data editing*<fnref n="12" /> (De Waal, Pannekoek, Scholtus 2011). On pense d'abord à la vérification à la source, qui s'effectue lors de la collecte par enquêteur : la médiation par un enquêteur permet par exemple de vérifier la bonne compréhension de la question, de voir si la personne enquêtée est bien sûre de sa réponse, ou d'effectuer la bonne interprétation quand on catégorise. Le fait de collecter par voie électronique permet aussi d'effectuer des contrôles élémentaires automatiquement (contrôles de type, de forme, voire de cohérence inter-variables), intégrés au support de collecte, et qui permettent d'éviter une partie des erreurs<fnref n="13" />.

Dans les enquêtes auprès des entreprises, la vérification par interaction avec l'enquêté peut s'effectuer ultérieurement, mais toujours dans une temporalité courte, en rappelant l'entreprise enquêtée pour vérifier des réponses qui ont pu paraître anormales. Ce travail des gestionnaires d'enquête permet d'effectuer cette mise au point, qui est essentielle.

<footnote n="10">10 Qui peut être présente dans la base de sondage (par exemple l'APE pour les enquêtes entreprises), ou obtenue via le 1er niveau d'observation.</footnote>

<footnote n="11">11 La comparabilité est l'une des dimensions du cadre qualité de la statistique européenne.</footnote>

<footnote n="12">12 Le *data editing* porte avant tout sur le travail de vérification de données, automatique ou manuel, et ce qui découle de cette vérification, à savoir la validation des données ou au contraire leur invalidation. Cette dernière situation peut conduire à des modifications manuelles, par des gestionnaires, ou à des traitements automatiques (imputation fondée sur des modèles). Ainsi, le *data editing* (qu'on peut traduire en français par contrôle redressement, peu ou prou) n'inclut les imputations que dans la mesure où elles dérivent d'une vérification infructueuse.</footnote>

<footnote n="13">13 Ces contrôles de cohérence sont rarement bloquants, mais l'outil de collecte électronique contraint le format de réponse.</footnote>
Les contrôles peuvent aussi avoir lieu bien plus tard, en phase de traitement statistique, en analysant de façon sélective les unités pour lesquelles l'impact sur les statistiques est fort, ce qui conduit à de nouvelles vérifications individuelles (Lawrence, McKenzie 2000).

Dans ces processus de data editing, les vérifications commencent en général par des contrôles automatiques, qui permettent de trouver des anomalies (une réponse en euros au lieu de k€ par exemple). Elles peuvent se poursuivre par des vérifications manuelles lorsqu'il y a anomalie dont l'ampleur est jugée statistiquement significative et pour laquelle une correction automatique serait une source d'erreur potentielle trop importante, et conduisent à rétroagir sur la valeur ... ou pas (car ce qui apparaît comme une anomalie n'est pas nécessairement une erreur). La démarche de vérification induit ainsi naturellement une « boucle de rétroaction » pouvant conduire à modifier des données. Ce principe de rétroaction, de feedback loop, présente un caractère très général et vaut pour le contrôle de tout processus (Wiener 1948). Cette idée centrale de la cybernétique, science des systèmes commandés, s'applique naturellement au processus de production statistique.

Ainsi, qu'elle ait lieu au moment de la collecte ou après<fnref n="14" />, la rétroaction s'effectue au niveau de l'unité statistique : les modifications porteront sur des micro-données. On verra que c'est tout à fait différent dans le cas des données administratives.

En toute fin d'enquête, on procède à des contrôles qui portent cette fois sur les agrégats eux-mêmes (output editing) : le fait qu'il y ait une évolution forte dans le temps de telle ou telle statistique n'est pas nécessairement une erreur, mais nécessite que cette évolution soit détectée, bien comprise et documentée, voire subdivisée en composantes (évolution des unités pérennes, évolution liée à la démographie des unités du champ, etc.). L'output editing est parfois réalisé informellement par les chargés d'études eux-mêmes lorsqu'ils sont les premiers utilisateurs de résultats et détectent des incohérences. Même dans ce cas-là, la boucle de rétroaction induira, s'il y a lieu, une modification de micro-données<fnref n="15" />.

Ces vérifications multiples, qu'il faut savoir doser (Granquist 1997), jouent un rôle indispensable dans le processus d'enquête, avec pour objectif d'améliorer la qualité des données individuelles et, partant, des agrégats. Pour les corrections automatiques (imputation notamment) il est également possible de mesurer leur impact sur la précision des agrégats fournis.

### 1.d. Caractérisation des statistiques issues d'enquête

La représentation mathématique de la partie 1a a mis en évidence différentes dimensions (unités statistiques, variables, champ, catégories, temporalités) que l'on peut reprendre ici. Au fond, ce qui caractérise le processus de production statistique d'enquête, c'est l'existence d'un certain degré de maîtrise sur les 5 éléments (Nordbotten 2010)<fnref n="16" /> de notre grille d'analyse :

* les unités statistiques à observer, définies très tôt, et qui sont souvent (mais non exclusivement) des individus, des ménages, des entreprises, ou des établissements¹⁷,

<footnote n="14">14 Ce qui peut être utilement modélisé dans le GSBPM (cf. § 1.e).</footnote>

<footnote n="15">15 Il ne faut pas imaginer pour autant que le cadre des enquêtes soit idyllique, il existe aussi des situations dans lesquelles la modification de micro-données n'est plus possible : c'est le cas par exemple lorsqu'on mobilise des données d'enquête dans des séries longues. Certains travaux (rétrogression de changement de concepts, de nomenclatures) s'effectuent de façon agrégée.</footnote>

<footnote n="16">16 En tant que piliers de base, trois de ses composantes à savoir unité, population et temps, sont un triptyque classique depuis longtemps : Nordbotten en parle dans son article de 2010, qui renvoie à un papier de sa part des années 60.</footnote>
* le champ d'observation : défini de telle sorte qu'il ait du sens, et, de préférence, afin qu'il soit accessible avant la collecte

Par exemple, pour une enquête auprès des entreprises, on peut définir le champ en fonction du secteur d'activité, de la tranche d'effectif, mais pas en fonction du montant d'investissements réalisé, ceci en fonction des informations disponibles dans la base de sondage<fnref n="18" />.

* les variables à observer : définies après concertation avec les différentes parties prenantes (utilisateurs mais aussi fournisseurs des données<fnref n="19" />), dans le cadre d'instances dédiées à cela (Anxionnaz, Maurel 2020),

* les principes de catégorisation : des nomenclatures partagées (Guibert, Laganier, Volle 1971),

Exemple : la nomenclature des professions (Amossé 2020), ou la nomenclature des infractions (Camus 2022),

* enfin, une double temporalité fixée et qui s'applique uniformément à toutes les unités : temporalité d'acquisition (période durant laquelle on effectue la collecte), temporalité de référence des données collectées (date ou période considérée<fnref n="20" />). Cette dernière caractéristique est tout à fait essentielle et représente une grande différence avec la situation des données administratives.

En termes de processus, le cadre classique de l'enquête permet :

* de maîtriser le protocole d'observation : il peut être complexe pour certains types d'enquête, par exemple les enquêtes multi-mode ou les enquêtes à carnet, ou encore l'enquête sans domicile pour laquelle on ne dispose pas de base de sondage,

* de vérifier le cas échéant les données à la source (interaction enquêteur – enquêté, gestionnaire<fnref n="21" /> – enquêté),

* d'estimer les erreurs grâce à la connaissance de la base de sondage, et du processus aléatoire d'échantillonnage, mais aussi en prenant en compte les modèles d'imputation (ou de repondération) pour les non-réponses partielles ou totales.

<footnote n="17">17 Dans les dispositifs comme les enquêtes usagers de la Drees, on s'intéresse à des séjours hospitaliers avec une triple approche (rétablissement, médecin, patient)</footnote>

<footnote n="18">18 La base de sondage est une contrainte qui peut éventuellement limiter le champ d'observation.</footnote>

<footnote n="19">19 On pense ici par exemple aux entreprises, représentées par des fédérations, ou organisations patronales.</footnote>

<footnote n="20">20 Par exemple, les enquêtes structurelles auprès des entreprises collectées l'année N portent souvent sur les valeurs de l'année N-1, et en pratique sur le dernier exercice comptable. Le chiffre d'affaires annuel n'est connu qu'en fin d'année et ne peut donc être collecté que l'année suivante.</footnote>

<footnote n="21">21 L'activité de gestionnaire d'enquête (*survey clerk* en anglais) comporte de nombreux aspects, comme la vérification manuelle des données (micro ou macro), le suivi, la relance des non-répondants, ... Les gestionnaires d'enquête jouent un rôle essentiel pour assurer la qualité des statistiques publiques.</footnote>
1.e. Représentation du processus : le GSBPM

La statistique officielle fait l'objet d'une représentation normalisée, offrant un cadre partagé au niveau international pour le processus de production des statistiques officielles : le Generic Statistical Business Process Model, ou GSBPM (Unece 2019).

Le GSBPM explicite les étapes du processus, avec un découpage en 8 phases, qui constitue un modèle de référence. Il est conçu pour que chaque institut statistique l'applique à sa manière, en fonction de son organisation et de ses contraintes, selon ce qui leur semble approprié (Erikson 2020).

Les 8 étapes sont les suivantes<fnref n="22" /> :

1. **Définition des besoins**

2. **Conception**
   *dont conception du descriptif de variables, de l'échantillon, de la collecte, des produits, du système de production*

3. **Élaboration**
   *dont élaboration de l'instrument de collecte, des composantes du processus, mise à l'essai du processus*

4. **Collecte**
   *création d'un cadre et sélection de l'échantillon, organisation, réalisation et finalisation de la collecte*

5. **Traitement**
   *dont intégration, codage, data editing, imputation, calcul des variables dérivées, finalisation du fichier de données*

6. Analyse

7. Diffusion

8. Évaluation

Si l'on se limite aux 4 premières étapes, antérieures au traitement, la fonction du processus de production statistique consiste, dans le cas des enquêtes, à traiter des difficultés de multiples natures, telles que : converger sur un besoin (et donc des variables et des classifications), prendre connaissance des conventions ou des modèles théoriques sous-jacents dans le domaine concerné, exprimer des questions cohérentes avec les buts recherchés, choisir la base de sondage la plus adaptée, sélectionner un échantillon apportant une précision suffisante pour les buts recherchés, bâtir un support de collecte efficace, mettre au point un protocole de collecte adapté à différentes sous-populations et configurations, traiter les non-réponses (partielles ou totales), affecter de façon pertinente un code de la nomenclature sur la base d'un libellé,... La maîtrise du processus permet de construire toutes les métadonnées (Sundgren 1993, Bonnans 2019) nécessaires au fur et à mesure des étapes.

Pour les données administratives, les problématiques et les difficultés rencontrées seront de toute autre nature et remettront en question ce découpage, tout du moins dans les premières phases, jusqu'au traitement, qui est la 5ᵉ étape du GSBPM.

<footnote n="22">22 En gras, celles qui concernent ce document de travail.</footnote>
## 2. Produire des statistiques à partir de données administratives

L'utilisation de vastes sources de données (y compris privées, d'ailleurs) peut apparaître à première vue comme une sorte d'eldorado pour la statistique publique : une forme d'exhaustivité, permettant d'accéder à des sous-populations plus fines, une variance réduite à zéro, un gain économique très significatif, etc. (Hand 2018) montre que cela ne va pas de soi, et qu'il serait trop rapide de considérer que l'absence de coûts de collecte justifie à lui seul l'usage de sources administratives, alors qu'il n'existe même pas de cadre théorique consensuel.

Avant toute chose, il est indispensable de mieux comprendre de quoi on parle lorsqu'on évoque les données administratives, et en premier lieu de déterminer les principales caractéristiques de ces données, ce qui va conduire à s'interroger sur leurs usages. Mais ce ne sera pas suffisant : pour appréhender la question de façon rigoureuse, il nous faudra commencer par spécifier la notion de donnée et notamment ses différentes dimensions. Celles-ci vont nous apporter un cadre conceptuel permettant d'interroger les propriétés de données administratives utilisées à des fins statistiques, cadre qui se révélera également utile dans les chapitres suivants.

### 2.a. Quelques caractéristiques des données administratives

La première dimension qui vient à l'esprit est **institutionnelle** : lorsqu'on évoque ces données, on fait allusion explicitement à leur origine et à la nature de l'unité productrice, le plus souvent une organisation gouvernementale<fnref n="23" />. L'OCDE les définit comme *l'ensemble des unités et données dérivant d'une entité administrative*, cette dernière étant définie comme *une unité organisationnelle responsable de l'implémentation d'une régulation administrative (ou groupe de régulations)*, pour *laquelle l'ensemble des unités et transactions sont vues comme une source de données statistiques* (OECD 2008). Elles présentent ainsi un caractère officiel, s'appuyant sur une assise juridique, et l'existence même de ces données peut donner des droits ou des devoirs, et avoir ainsi des conséquences très concrètes sur la vie quotidienne : paiement d'un impôt, d'une amende, attribution d'une retraite, droit à bénéficier d'une subvention, ... Contrairement aux données privées<fnref n="24" />, les données administratives sont souvent associées à des obligations (payer ses cotisations sociales par exemple) et l'administration n'a pas d'intérêt commercial ou stratégique associé aux données.

Dans la littérature académique, les auteurs insistent plus particulièrement sur l'usage qui en est fait. Hand (2018) les définit simplement comme les « données générées au cours d'une opération et conservées dans une base de données ». Une définition un peu plus précise est proposée par Alain Desrosières : « Une source administrative est issue d'une institution dont la finalité n'est pas de produire une telle information, mais dont les activités de gestion impliquent la tenue, selon des règles générales, de fichiers ou de registres individuels, dont l'agrégation n'est qu'un sous-produit, alors que les informations individuelles en sont l'élément important, notamment pour les individus ou les entreprises concernés. » (Desrosières 2004).

Dans leur essence, les données administratives se distinguent donc des données d'enquête avant tout par leur **finalité** : elles « naissent » en lien avec une intention de gestion, de mise en œuvre d'un processus administratif, alors que dans une enquête l'intention est d'observer. Pour l'administration concernée, la constitution de bases de données n'est pas un objectif en soi, elle supporte, permet de

<footnote n="23">23 Pour désigner l'institution en question, on utilisera indifféremment, tout au long du document, les termes « administration », « entité administrative », « entité publique », ou entité chargée d'une mission de service public.</footnote>

<footnote n="24">24 On pense ici aux données provenant d'entreprises privées, comme les données de caisse (Leclair 2019).</footnote>
piloter un processus opérationnel. Les données embarquent alors leur propre univers, leurs propres concepts, liés au processus supporté et à ses exigences : dans l'exemple de données hospitalières, les identifiants de personnels médicaux et soignants, les parcours patient, les nomenclatures de groupes homogènes de malades en vue de remboursement par l'assurance maladie, ...

Il en découle que la donnée administrative n'est pas nécessairement une observation : elle peut par exemple refléter une décision de gestion, comme l'attribution d'une prestation sociale.

Exemple : pour l'assurance maladie (AM), une simple consultation pour vérifier la vue chez un ophtalmologue peut se traduire par deux résultats différents dans le système d'information : une consultation en ophtalmologie, ou bien plusieurs actes médicaux (ceux que le médecin a fait pendant la consultation). Les montants associés à ces deux codifications étant différents, chaque médecin peut être amené à optimiser son codage pour avoir la meilleure rémunération. Ainsi, le médecin en secteur 2 pourra avoir tendance à enregistrer une consultation ; celui en secteur 1 les différents actes.

Ces logiques d'optimisation peuvent de plus varier dans le temps, et au sein de l'organisation. Cela s'avère d'autant plus vrai lorsque la gestion du processus administratif est déconcentrée.

Plus généralement les données administratives peuvent être vues comme des « déclencheurs d'action » et non comme des informations passives. Elles sont construites pour un usage précis (par exemple : rémunération d'un médecin, attribution d'une prestation sociale, prélèvement d'impôt à bon droit...), mais pas en première instance pour l'observation : pour Hand, elles sont finalement des **co-produits de processus opérationnels**, voire des « résidus » de ceux-ci. Il parle ainsi de « data exhaust 25 » ou « ce qui reste après que la machine administrative ait utilisé les données pour son activité propre ».

**L'usage statistique** de ces données ne constitue pas en général une finalité de ces données26, contrairement aux données d'enquête qui sont justement conçues à cette fin, mais une utilisation secondaire, une réutilisation. Il n'en demeure pas moins que certaines d'entre elles (les déclarations annuelles de données sociales ou les données fiscales notamment) ont été utilisées pour produire des statistiques durant de nombreuses années (les données fiscales sont ainsi utilisées par l'Insee depuis 1950), cet usage étant facilité, en France, par un accès garanti par la loi, pour le service statistique public27.

Les données administratives présentent également un gros défaut : **l'absence de garantie de leur pérennité**. Dépendantes des processus qu'elles soutiennent, les données administratives peuvent évoluer fortement en matière de champ d'intérêt, de concepts, et peuvent même tout simplement ne plus exister. Les modifications récentes sur la fiscalité (suppression de la taxe d'habitation – TH28 – sur les résidences principales) ont entraîné la disparition des données liées à ce processus, qui jouaient un rôle majeur pour la statistique publique : l'Insee utilisait ces informations pour définir les ménages dans la base de sondage des enquêtes. La suppression de la TH (Bach et al 2023) a donc été une grosse perte qui a, de fait, été imposée aux statisticiens publics sans qu'ils aient la possibilité d'agir, en perdant du jour au lendemain le lien entre les individus et leur logement.

<footnote n="25">25 Ce terme fait référence à l'épuisement d'une ressource, ou également aux gaz d'échappement : ce qui reste de la matière première « donnée » une fois que l'on a tiré tout ce qui était possible pour son usage premier.</footnote>

<footnote n="26">26 Il en résulte que toutes les données ne sont pas utiles à la statistique, très loin de là, et qu'il existe donc de nombreuses données dites « secondaires ».</footnote>

<footnote n="27">27 Article 7 bis, Loi n° 51-711 du 7 juin 1951 sur l'obligation, la coordination et le secret en matière de statistiques.</footnote>

<footnote n="28">28 Les différentes sources évoquées dans ce document sont décrites succinctement dans l'annexe 2.</footnote>
Sans suppression totale d'une source, il peut arriver qu'une variable soit supprimée ou modifiée alors qu'elle est centrale dans un processus.

Exemple : l'exonération fiscale des heures supplémentaires peut impliquer qu'elles ne sont plus déclarées dans le salaire net fiscal<fnref n="29" />... or c'est une variable de base pour produire les évolutions de salaire.

De façon générale, le fait que ces données ne soient évidemment pas sous la responsabilité du système statistique conduit à un **déficit de maîtrise** : on ne peut les placer sur le même plan que les données d'enquête. Dans ce qui suit, on va préciser en quoi, en commençant par formaliser les différents aspects de la notion de donnée, dans l'optique d'un usage statistique.

## 2.b. Notion de donnée ... et nouvelle grille d'analyse

Il existe de nombreuses définitions de la notion de donnée dans la littérature, par exemple (Kitchin 2014), (Borgman 2015), ou (Caron et al 2020). Mais on va plutôt utiliser ici la définition, plus opérationnelle, de Thomas Redman (1997), qui se base lui-même sur une définition traditionnelle en informatique.

On peut définir une donnée comme étant un triplet (concept, domaine, valeur)<fnref n="30" />.

Le **concept** représente la signification de la donnée, que l'on va décrire par un libellé : par exemple, « la hauteur de la tour Eiffel », « le genre d'une personne », « la date de début d'un contrat », « l'activité principale d'une entreprise ». Il est décrit comme l'attribut d'un **objet**, ou, pour reprendre un terme plus traditionnel, par une **variable** associée à un objet. Dans ces exemples, les objets sont la Tour Eiffel, une personne (une personne bien précise), un contrat (idem), une entreprise. Et les attributs, ou variables, sont ici : hauteur, genre, date de début, activité principale.

On appelle **domaine** l'ensemble de valeurs possibles associées au concept, avec explicitation du sens. Par exemple, pour la hauteur, ce sera un nombre entier positif, exprimé en mètres, mettons. Pour le genre, ce sera par exemple l'ensemble {0, 1}, lui-même complété d'explications (par exemple 0 = homme, 1 = femme), ou {0, 1, 2} avec un genre « autre ». Pour la date, il faudra déterminer dans quel calendrier on se situe, et intégrer dans la définition du domaine les diverses contraintes (ex : le jour est inférieur ou égal à 31, ...). Soulignons ici que le format n'est qu'une implémentation de la représentation d'un domaine de valeurs. Pour une date par exemple, il existe plusieurs formats possibles (JJMMAA, JJ/MM/AAAA, ...), et le choix de format ne change rien au domaine.

Et la **valeur** ... c'est la valeur, et c'est ce qu'on a tendance à appeler « donnée » habituellement.

Concept et domaine font ainsi, et c'est le point essentiel ici, partie intégrante de la notion de donnée : si on lit « 324 », par exemple, ce n'est pas une donnée, c'est juste un nombre. On peut lui associer le concept « hauteur de la tour Eiffel », « nombre d'habitants de tel village », « poids de telle moto », et dans ce cas on a affaire à des données différentes, mais on a besoin de la caractérisation du domaine, avec par exemple l'unité de mesure de la hauteur (pieds ? mètres ?).

<footnote n="29">29 En pratique, les consignes de déclaration évoluent dans le temps : ainsi les heures supplémentaires étaient incluses avant 2020, puis ne l'étaient plus entre 2021 et 2023, et le sont à nouveau en 2024.</footnote>

<footnote n="30">30 Voir aussi à ce sujet (Rivière 2020).</footnote>
Si l'on a en tête un usage statistique, et les caractérisations proposées dans la partie sur les données d'enquête, deux autres dimensions de la notion de donnée vont jouer un rôle important.

En premier lieu, le **champ**, c'est-à-dire une restriction de l'ensemble des possibles pour l'objet considéré : on aura, par exemple, une mesure administrative qui ne s'appliquera qu'aux entreprises de moins de 20 salariés créées après telle date, ou aux transactions de tel type effectuées telle année, ou aux retraites versées à telle période, inférieures à tel seuil, pour des personnes ayant telles caractéristiques (âge, durée de cotisation, ...).

En second lieu, les **temporalités** : une donnée se caractérise souvent par une *date (ou période) de référence* (par exemple, tel arrêt maladie a eu lieu tel jour), qui est en soi une métadonnée (Gartner 2016)<fnref n="31" /> fort utile. Mais cette date de référence est différente de la *date (ou période) d'acquisition*, i.e. la date à laquelle l'information a été obtenue : par exemple, une enquête auprès des entreprises menée en 2024 au sujet de l'exercice 2023.

Pour mieux appréhender les données administratives, on va, au total, s'appuyer sur une grille semblable à celle des données d'enquête, et comportant comme elle 5 dimensions (Froeschl et Grossmann 2000)<fnref n="32" /> :

1. L'objet

2. Le champ

3. La variable

4. Le domaine de valeurs

5. Les temporalités

<caption>**Figure 2 - Grille d'analyse des données administratives**</caption>

Cette grille présente de légères différences celle relative aux enquêtes : on ne parle plus d'unité d'observation mais d'objet<fnref n="33" /> ; la variable est ici un attribut de l'objet ; le domaine de valeurs ne se réfère pas toujours à une nomenclature ; la notion de champ est similaire à ce qui se passe pour une enquête, mais elle est ici spécifique aux besoins de l'administration ; enfin, les temporalités sont, dans la majorité des cas, très différentes de celles d'une enquête.

## 2.c. Données administratives en vue d'un usage statistique

Pour chacune des cinq dimensions proposées (objet, variable, domaine, champ, temporalité), on va indiquer les spécificités d'une donnée administrative et comparer avec les données d'enquête. On trouvera aussi dans (De Broe et al 2020) une comparaison de type avantages – inconvénients entre ces deux approches.

<footnote n="31">31 On peut définir une métadonnée comme une « donnée fournissant de l'information sur une donnée, ou des données ».</footnote>

<footnote n="32">32 Les auteurs effectuent une distinction similaire, en étant à mi-chemin entre mondes statistique et administratif : populations and populations units, variables and value sets, coverage, data production dynamics.</footnote>

<footnote n="33">33 Objet spécifique à l'administration, mais qui ne sera pas nécessairement associé à une démarche d'observation.</footnote>
• **Objet**

L'objectif d'une administration est de mener à bien différents processus opérationnels, permettant de rendre des services à des usagers, de collecter des impôts, d'octroyer des droits, de verser des prestations, ce qui conduit à enregistrer les évènements correspondants. Les objets associés, parfois simples, peuvent se révéler complexes, en raison de nombreuses liaisons entre ces objets : ainsi dans un hôpital, le parcours patient fait intervenir plusieurs « objets » en plus du patient lui-même, ayant chacun sa propre dynamique et ses propres attributs : médecin, prescription, diagnostic, établissement, ... Ce sont des objets « de gestion », différents des objets « d'étude » statistique.

Les objets doivent être créés dans le système d'information (nouveau patient, nouveau médecin, nouvel établissement). Cela peut passer par la déclaration d'un évènement simple, comme une naissance, cet événement physique conduisant à créer un nouvel enregistrement dans le répertoire des individus. Dans le cas d'une entreprise, c'est à l'inverse la création de l'objet entreprise dans le système d'information (dans le répertoire) qui va officialiser la naissance de l'entreprise.

Souvent, les données administratives vont porter sur des individus<fnref n="34" />, ce qui peut donner une illusion de simplicité : car en tant que support d'un processus administratif, les données portent plutôt sur un **rôle** d'un individu.

Exemples : une personne physique pourra être considérée, selon les domaines administratifs, les usages et les personnes, comme un usager, un électeur, un contribuable, un bénéficiaire de prestation, un étudiant, un professionnel de santé, un garant... avec dans chaque cas, un angle d'analyse différent et des variables différentes.

Ainsi, le lien n'est pas nécessairement bijectif entre objet administratif et unité statistique.

Un individu, par exemple, peut correspondre à plusieurs contribuables, dans plusieurs départements, en lien avec le niveau de gestion administratif. Et inversement, un individu peut en représenter plusieurs avec les notions d'ouvrant-droit / ayant-droit par exemple.

La multiplicité des objets considérés dans un processus administratif entraîne aussi des possibilités d'exploitation statistique variées.

On pense aux exploitations diverses des données cadastrales, qui selon les sources peuvent être relatives à différents objets : propriétaire, logement, transaction, ... (André, Meslin 2022). Mobilisées dans Résil (Lefebvre 2024) ou Fidéli (Lamarche, Lollivier 2021) à des fins de localisation des logements, elles peuvent également servir dans l'évaluation du patrimoine immobilier (André, Arnold, Meslin 2021).

À l'inverse, dans le cas des enquêtes, dans une majorité de cas le contexte est simple<fnref n="35" /> : l'« objet » est l'individu / le ménage / l'entreprise interrogé (e), qui est « créé » dans le système d'information à travers la base de sondage et le tirage d'échantillon. La question des rôles, des liens entre objets, est moins prégnante, même si elle existe (parent – enfant, entreprise – établissement).

<footnote n="34">34 Bien entendu on a aussi des données administratives sur des entreprises, établissements, administrations, ...</footnote>

<footnote n="35">35 Mais pas toujours : on peut avoir des objets plus complexes comme les entreprises profilées (Moreau 2024).</footnote>
• Champ

Les processus administratifs concernent souvent une partie seulement de la population : par exemple, l'ensemble des personnes *assujetties à tel impôt*, ou bien l'ensemble des entreprises éligibles à telle subvention.

On définit le champ « en intention », par ses caractéristiques : l'ensemble des objets vérifiant telle propriété ; par exemple, l'ensemble des établissements ayant moins de 10 salariés. Ce champ, exprimable de façon simple, permet de déduire une liste d'objets « en extension », ce qui présuppose de connaître la population totale : par exemple, le répertoire Sirene des entreprises, le répertoire national d'identification des personnes physiques (RNIPP) pour les individus (Espinasse, Roux 2022). Dans un contexte administratif, la définition du champ peut évoluer dans le temps, tout simplement parce que la législation évolue (telle mesure s'appliquait aux moins de 10 salariés, après changements elle ne s'applique plus qu'aux moins de 5).

Exemple : la Déclaration sociale nominative (DSN) porte sur tous les employeurs, publics ou privés, qui doivent déclarer des informations de paie pour l'ensemble de leurs salariés (Humbert-Bottin 2018). Son champ a évolué ces dernières années, puisqu'il ne concernait que le secteur privé jusqu'en 2021.

Mais, on l'a vu, les processus peuvent porter sur plusieurs objets, et le champ peut aussi être défini sur ces différents objets. Lié à des objectifs de gestion, le champ du processus administratif peut donc différer du champ d'intérêt statistique, même lorsqu'il concerne des objets de même nature.

Exemples : le champ de la source GMBI<fnref n="36" /> (Gérer mes biens immobiliers) porte sur tous les locaux, mais ses usages statistiques envisagés ne portent que sur le champ des locaux d'habitation (logements<fnref n="37" />).

*Last but not least*, le champ supposé n'est pas nécessairement intégralement couvert par le processus. Différentes raisons peuvent conduire à des défauts de couverture : des exonérations particulières, une sous déclaration d'individus concernés etc.

• Variable

L'écart entre les variables « administratives » et « statistiques » est probablement le sujet le plus classique, le plus connu : on sait que les variables administratives n'ont aucune raison de coller aux besoins statistiques, car rien n'assure que les objectifs soient les mêmes.

Exemple 1 : le revenu, à mettre en regard de la variable administrative « revenu imposable ». A titre d'illustration, les revenus d'un stagiaire sont non imposables, ils ne sont donc pas pris en compte dans les revenus d'un ménage pour l'administration fiscale.

Exemple 2 : dans la DSN, la distinction des différentes rémunérations ne couvre pas tous les besoins statistiques. Ainsi, il n'est pas possible de distinguer précisément les primes régulières et irrégulières, ou encore les rémunérations liées aux astreintes.

Une même variable peut avoir des définitions différentes d'une source à l'autre ce qui complique leur comparaison et leur utilisation à des fins statistiques. Pour la construction d'un bateau qui sera

<footnote n="36">36 Voir (Desforges 2021), p. 1110.</footnote>

<footnote n="37">37 L'usage d'un terme identique ne signifie pas que les concepts sont rigoureusement équivalents.</footnote>
exporté par exemple, les avances peuvent faire partie du chiffre d'affaires à l'exportation des années
qui précédent son envoi à l'étranger pour la DGFIP alors que pour les douanes, c'est le prix total du
bateau au moment où il quitte le territoire français qui sera considéré comme le CA à l'exportation.

• Domaine

Le domaine est l'ensemble des valeurs admissibles de la variable, ce qui doit pouvoir être caractérisé de façon formelle, mathématisée : le *definition domain* de (Batini, Scannapieco 2016)<fnref n="38" />. On pense aux intervalles, pour des valeurs quantitatives, aux listes de valeurs, aux sélections par rapport à une vaste liste existante,...

Il faut préciser que c'est un ensemble *commenté*. Par exemple, il ne suffit pas de dire que pour la variable genre, la liste des valeurs possibles est {0, 1}, il faut aussi associer une signification à ces deux valeurs (0=homme et 1=femme, ou l'inverse ?). Dans le cas des données quantitatives, il faut indiquer l'unité de mesure : euros ou milliers d'euros, habitants ou milliers d'habitants, mètre ou kilomètre, ...

Comprendre le domaine, pour des données administratives, c'est aussi comprendre de quelle manière ont été notées les valeurs manquantes (-1 ? 99 ? 9999 ? NA ?), ce qui est souvent peu documenté. C'est également connaître les « valeurs refuge », i e. celles que l'on utilise quand on ne sait pas trop quoi dire (attention, ce n'est pas la même chose que les valeurs manquantes).

Dans GMBI par exemple, la variable « le local est-il meublé » est par défaut à non.

Dès lors on ne peut faire la différence entre un vrai « non » (ou une autre valeur refuge) et une non-réponse. Par ailleurs, les consignes pour ces valeurs refuge ne sont pas forcément les mêmes pour tout le monde<fnref n="39" />.

Enfin, il arrive souvent que les « domaines » associés aux données soient des nomenclatures, celles-ci jouant un rôle essentiel dans l'activité administrative : nomenclature de catégories juridiques, d'établissements, d'activités, de grades ... (Bowker, Star 2000) le soulignent ainsi : « L'attribution de catégories aux choses, aux personnes ou à leurs actions à des catégories est un élément omniprésent du travail dans l'État moderne et bureaucratique. »

La difficulté va être de bien comprendre la caractérisation du domaine (existence de documentation encore ...) et de spécifier les différences avec les éventuelles nomenclatures statistiques proches. Les classifications administratives ont des finalités de gestion : par exemple, un découpage en régions reflétera simplement un découpage organisationnel. Paradoxalement, le fait que l'administration emploie une « nomenclature Insee » ne facilite pas nécessairement les choses : il peut s'agir d'une version ancienne, ou en partie agrégée, en partie transformée ... il ne faut pas prendre pour argent comptant la référence annoncée à la statistique publique.

• Temporalités

La double temporalité d'une enquête statistique est en général très claire : on effectue une collecte pendant une certaine période (période d'acquisition, ici période de collecte), connue, affichée,

<footnote n="38">38 Voir pp. 24-25.</footnote>

<footnote n="39">39 Par exemple, dans le système d'information de l'assurance-maladie, pour que les patients sans médecin traitant (parce qu'ils ne parviennent pas à en trouver un du fait de la pénurie) ne soient pas pénalisés dans leur parcours de soins, les caisses primaires (CPAM) entrent un numéro de médecin traitant fictif. Les consignes ne sont pas les mêmes d'une CPAM à l'autre et ne sont pas forcément connues au niveau national.</footnote>
période pendant laquelle on prend connaissance des informations. Elle s'effectue relativement à une période, ou date (période, ou date, de référence). Le standard de métadonnées DDI<fnref n="40" /> (Data Documentation Initiative), cadre international largement utilisé en statistique, effectue clairement cette distinction. Pour les enquêtes, ces deux dates et/ou périodes sont, de préférence, relativement proches, et valent de façon uniforme pour toutes les unités.

Dans le cas des données administratives, la différence réside simplement dans le fait que, dans la majorité des cas, il n'y a pas de collecte (au sens d'une double temporalité uniforme). Il existe un contre-exemple à cela : les déclarations administratives, qui se caractérisent par une période déclarative et une période de référence sur laquelle portent les déclarations. Le processus déclaratif (déclaration d'impôts, déclaration sociale nominative) est donc similaire au processus de collecte en termes de temporalités.

Pour le reste, les données administratives sont dépendantes d'événements externes qui peuvent se dérouler à n'importe quel moment : naissance, décès, changement d'adresse, demande de départ à la retraite, demande de prestation, ... Ainsi, la date de référence n'est absolument pas maîtrisée, et la date d'acquisition, ou son équivalent ici, est souvent complètement dépendante du bon vouloir de l'usager (on peut très bien transmettre sa feuille de soins très en retard ...).

A noter que ces événements administratifs peuvent être des événements internes à l'administration, par exemple la décision d'attribution d'une prestation, d'une subvention, la décision de donner une amende, ... Là aussi, le fonctionnement de la gestion administrative ne garantit pas toujours une bonne maîtrise des dates, ici les dates de décision (ex : décisions de justice).

Pour un usage statistique, la non-maîtrise des deux temporalités pose problème : il n'y a pas de garantie qu'on dispose de l'exhaustivité des événements, parce que ceux-ci sont connus avec un fort décalage, ou tout simplement parce que ceux-ci ne sont pas déclarés.

## Synthèse

In fine, si l'on cherche à estimer le total évoqué en première partie, l'usage de données administratives nous donnera implicitement une expression très différente du cas d'une enquête, avec une formulation du type :

$$ \hat{\tilde{X}}_{\tilde{C}_k}^t = \sum_{\substack{i \in \tilde{U} \\ i \in \tilde{C}_k}} \tilde{X}_i^{t_i} \quad (5) $$

* où l'univers $\tilde{U}$, la catégorisation $\tilde{C}$, la variable $\tilde{X}$, spécifiques à l'entité administrative, n'ont pas de raison de correspondre à U, C et X

* où, pour chaque unité i, les temporalités de référence $t_i$, supposées approcher t, n'ont pas de raison d'être toutes égales

* où, enfin, aucun élément de l'expression ne relève d'un modèle aléatoire prédéfini, ce qui empêche un calcul « classique » de l'erreur d'échantillonnage<fnref n="41" />. Il n'est pas non plus possible

<footnote n="40">40 Voir https://ddialliance.org/ddi-codebook_v2.5. Cela correspond aux balises <referencePeriod> ou <timePeriodCovered> d'une part, et <collectionDate> ou <dataCollectionPeriod> d'autre part.</footnote>

<footnote n="41">41 Plus généralement, on s'intéresse à une erreur totale : dans le cadre d'une enquête, cela comprend l'erreur d'échantillonnage, mais aussi l'erreur de non-réponse (que l'on peut modéliser à partir des informations connues sur la base de sondage)... Mais tout n'est pas parfait non plus dans le contexte d'une enquête : certaines erreurs (comme l'erreur de mesure) sont difficiles à estimer.</footnote>
de calculer classiquement l'erreur liée à la non réponse, en l'absence de connaissance de la base de sondage. D'autres méthodes permettent toutefois d'évaluer le défaut de couverture (méthodes de capture-recapture).

L'estimation d'une erreur totale (à l'instar de l'erreur d'enquête totale, ou *total survey error*) est complexe, mais peut être envisagée. (Reid et al 2017) proposent un cadre permettant d'identifier différents types d'erreurs. Il est toutefois difficile de modéliser celles-ci. (Berkovsky et al 2025) proposent un *total data quality paradigm*, prenant en compte les défis spécifiques aux données administratives, en s'autorisant à sortir du cadre probabiliste.

## 2.d. Statistiques issues de données administratives vs statistiques issues d'enquêtes

Vis-à-vis des données d'enquête, les données administratives offrent plusieurs avantages évidents pour le statisticien (De Broe et al 2020) :

* disparition du coût de collecte ... tout du moins pour la statistique publique

* disparition de la charge d'enquête<fnref n="42" />

* possibilité d'analyses à granularité très fine (au niveau géographique, sectoriel, tranches d'âge)

* de meilleures possibilités d'appariement : si un identifiant commun (le NIR ou le Siren par exemple) n'est pas présent, des éléments d'identification (nom/ prénom / date de naissance, ou adresse / raison sociale) le seront souvent et permettront un rapprochement des fichiers.

Mais comme on vient de le voir, la donnée administrative a un statut, une finalité et un cycle de vie (liés à son usage) très différents d'une donnée issue d'une enquête, ce qui a des conséquences sur les propriétés des statistiques qui en découlent. Si l'on reprend les 5 dimensions de notre grille d'analyse, il apparaît surtout que la statistique publique en **perd la maîtrise**, en bonne partie.

* Le champ, les variables, les domaines de valeurs sont décidés par et pour la gestion administrative, la plupart du temps sans prise en compte des besoins d'information statistique. Toute la difficulté sera donc de comprendre comment ces éléments sont caractérisés pour se donner la possibilité ultérieure de transformer les données en vue d'un usage statistique. La qualité de ce travail est aussi fortement liée aux métadonnées des sources administratives qui ne sont pas toujours bien documentées ou difficilement accessibles<fnref n="43" />.

* Les données ne portent pas toujours sur les objets de connaissance habituels du statisticien (individu, ménage, entreprise, établissement), mais sur des objets de gestion (transaction, facture, local, compteur électrique, ...).

* Il arrive souvent qu'on perde la maîtrise et l'homogénéité de la double temporalité (temporalité de référence / d'acquisition), à l'exception notable des données administratives issues de déclarations à période déclarative fixée.

Plus globalement c'est le protocole d'obtention des données qui échappe aux statisticiens, y compris la capacité à vérifier les données auprès de leur émetteur, puisqu'on perd le lien avec l'enquêté⁴⁴. N'ayant pas défini *a priori* de cadre probabiliste (plan de sondage, modèles d'imputation, ...), on

<footnote n="42">42 ... mais la charge administrative (remplissage de formulaire) peut s'y substituer.</footnote>

<footnote n="43">43 Par exemple, le secret fiscal empêche parfois d'avoir une vision précise des traitements mis en œuvre pour calculer certaines caractéristiques.</footnote>
perd aussi la possibilité de mesurer des erreurs à partir de tels cadres ... ce qui n'empêche pas d'en définir d'autres, mais cette fois *a posteriori*. C'est là un point-clé.

## 2.e. Conséquence sur le processus, comparé aux enquêtes

Préalable : le but de cette partie est de mettre en parallèle simplement le processus d'enquête et le processus de traitement des données administratives pour un usage statistique, en s'appuyant sur le GSBPM. Mais il faut souligner que plusieurs travaux ont eu lieu au niveau européen sur l'adaptation du GSBPM aux données administratives, au moins sur certains aspects. Des projets d'Eurostat ont ainsi cherché à mettre en regard les étapes du GSBPM et le traitement de données administratives (Eurostat 2017c<fnref n="45" />).

Les premières étapes du GSBPM étaient : définition des besoins, conception, élaboration, collecte.

Dans le cas des données administratives, la collecte au sens habituel disparaît, ce qui fait disparaître également la conception de l'échantillon et celle du protocole de collecte, l'élaboration du support de collecte, et la collecte elle-même. Cela n'empêche pas qu'il y ait un travail de définition des besoins (même si celui-ci est contraint par le contenu des données administratives), la conception de quelque chose, et l'élaboration de ce quelque chose.

Si l'on présente les deux possibilités, enquête ou acquisition de sources administratives, on obtient, pour le processus de production statistique, une forme « **en Y** », où :

* la branche du Y en haut à gauche correspond aux 4 premières étapes du GSBPM,

* la branche commune du Y en bas représente les étapes suivantes du processus, en commençant par « traitement »,

* la branche du Y en haut à droite correspond, pour les sources administratives, au processus préalable au traitement statistique, qu'il s'agit d'expliciter dans le présent document.

Le processus à concevoir et élaborer consistera, pour le statisticien public, à se ramener à « ses » objets, champs, variables, domaines, temporalités. Il s'agira donc de construire un processus de *conditionnement* des données à partir de ce que fournit l'administration, à savoir des fichiers sur lesquels la statistique n'a que très peu (ou pas du tout) de maîtrise, et qui sont ... tels qu'ils sont : les « *it is what it is* » data sets (Lothian, Holmberg, Seyb 2019).

Ce nouveau processus s'applique non pas à une donnée isolée, mais à un ensemble de données plus vaste : une « **source administrative** ». Mais existe-t-il une vision partagée de ce qu'on entend par là, une définition reconnue du concept ? Le chapitre suivant va nous montrer que cela ne va nullement de soi.

<footnote n="44">44 Y compris l'existence même des données, car rien ne garantit que la source administrative va rester disponible ad vitam aeternam. Ce qui a des conséquences sur la pérennité / comparabilité des statistiques.</footnote>

<footnote n="45">45 La partie 2 s'intitule justement « *Applying the GSBPM to the usages characterised by integrated administrative data* ». La partie 3 détaille l'étape de traitement.</footnote>
## Processus de production de statistiques

à partir de données produites
à l'aide d'un instrument d'observation
(enquête)

à partir de données administratives

## Définir les besoins

**Concevoir**

Produits
Variables
Traitement
Système de production

Base de sondage
Echantillon
Collecte

**Construire**

Outils de traitement
Diffusion

Outils de collecte

**Collecter**

Base de sondage et échantillon
Organisation, Réalisation,
Finalisation
de la collecte

**Traiter**

**Analyser**

**Diffuser**

**Evaluer**

?

Ce schéma représente les phases du GSBPM, en mettant en exergue quelques sous-phases. On distingue les sous-phases liées aux statistiques envisagées (la finalité) des sous-phases plus concentrées sur les moyens d'y parvenir. Et notamment, pour ces dernières, celles liées à la conception, la construction et la mise en œuvre de l'instrument d'observation dans un contexte d'enquête (en jaune sur le schéma). Ce sont ces sous-phases pour lesquelles on va chercher à décrire ce qui se passe dans le contexte d'utilisation de données administratives à des fins statistiques.
### 3. Système d'information administratif et sources administratives

Dans une administration, les données ne découlent pas d'un processus de collecte à l'issue duquel elles seraient conservées quelque part. Non : elles sont en réalité dans un système d'information, qui est en quelque sorte leur habitat naturel. C'est un environnement complexe dans lequel les données ne cessent d'évoluer, en fonction des activités de gestion. La notion de source est alors plutôt une construction, une invention du statisticien pour ses propres besoins.

Dans ce qui suit, on va décrire brièvement en quoi consiste en système d'information (SI) administratif, puis on essaiera de comprendre comment on peut « figer » les données, avant de tenter une caractérisation de la source administrative comme découlant du SI. On verra ensuite que le fait de changer d'univers, i.e. de passer d'un univers métier (ici administratif) à un autre (ici, statistique) est une opération délicate. Ceci nous conduira à une démarche en plusieurs temps.

#### 3.a. La notion de système d'information administratif

Un système d'information (SI) est un ensemble organisé de ressources (matérielles, logicielles, humaines, procédurales) qui permet de collecter, classifier, traiter, stocker, diffuser et rendre accessible l'information au sein d'une organisation. Il a pour vocation de soutenir et améliorer le fonctionnement, la prise de décision, la coordination et le contrôle des activités, afin d'atteindre les objectifs stratégiques et opérationnels de l'organisation (Kalika et al 2023).

Dans une administration, dans une entreprise, un système d'information se décompose en de multiples sous-systèmes d'information (ex : SIRH, SI des achats, SI de la relation client, ...) ayant chacun des finalités, et au sein desquels s'opèrent des processus opérationnels (par exemple, dans un SIRH, le processus de recrutement), souvent interconnectés.

C'est donc un monde en soi, complexe, enchevêtré, évolutif, et hétéroclite du fait de sa construction au fil du temps. Il embarque avec lui une certaine technicité, des notions métier, un jargon, une culture, des objectifs ... et va naturellement générer et mobiliser de nombreuses données, pour ses propres besoins. Ces données, imbriquées dans le SI, sont pour l'essentiel inutilisables telles quelles pour un usage de recherche, d'analyse, de statistique, et notamment parce que ces données évoluent en permanence, en lien avec la gestion de tel ou tel processus administratif. Elles sont là en tant que support d'un processus métier.

Ainsi, il faut garder à l'esprit que les données administratives ne sont pas, du moins pour l'essentiel, des données immuables, fixes, mais au contraire des données vivantes, subissant des modifications de diverses natures, de façon continue (ajout d'un objet, suppression d'un objet, modification d'un attribut d'un objet, évènement concernant un ou plusieurs objets...)46. Elles se trouvent à l'intérieur de bases de données, qui sont justement des structures permettant de supporter des évolutions permanentes sans compromettre l'intégrité de l'ensemble (Elmasri, Navathe 2016). Dès lors, sans transformation préalable, on ne peut s'en servir à des fins statistiques : en raison de leur caractère évolutif, n'importe quelle agrégation produirait un résultat différent, pertinent uniquement pour le moment où il a été produit47.

<footnote n="46">46 Il faut toujours distinguer les évolutions au niveau « instance » (ajout, suppression de tel individu) et évolutions au niveau du modèle de données, donc au niveau « définition » (ajout de la notion d'ayant-droit, par exemple).</footnote>

<footnote n="47">47 On peut simplement souligner qu'il y a toujours peu ou prou un sous-système d'information dédié au pilotage, qui contient des données figées et rejoint pour partie des préoccupations statistiques.</footnote>
On parle ici de SI *d'une entité publique*. C'est cette entité qui, *via* des unités opérationnelles qui sont chargées de cela, va transmettre ce que l'on nomme « sources » administratives. Il ne s'agit en général pas d'une collecte, et les données ne sont pas nécessairement des observations : les statisticiens publics peuvent avoir tendance ici à projeter leurs propres représentations, à tort.

Le SI administratif, vaste, protéiforme, souvent évolutif, ne peut à aucun moment être une telle
source, et il est pratiquement toujours inconnu des statisticiens : pour que ceux-ci puissent travailler,
il faut un fichier, comportant des données figées. Afin de produire des statistiques, et une fois
assimilé les aspects importants du SI, il faudra qu'aient été définies des modalités pour **figer** les
divers ensembles de données pertinents du SI.

A l'inverse, dans un processus d'enquête, on organise un processus d'observation ponctuel, produisant par construction même un jeu de données figé, comportant le plus souvent une valeur unique et datée pour chaque variable d'intérêt.

Mais alors, comment figer ce qui peut bouger en permanence ? Et en partant de quoi ?

3.b. **Figer les données : une construction nécessaire, des choix décisifs**

Pour produire des statistiques, on ne peut pas partir de données dont les valeurs sont susceptibles de
changer tout le temps. D'une manière ou d'une autre il faut disposer d'un fichier, dans lequel les
données sont donc fixes, et il est ainsi impératif de savoir « prendre une photo » de ces données
mouvantes, c'est-à-dire de **figer** les données. Si cette photo n'a pas vocation à être prise par les
statisticiens publics, il leur faut en revanche comprendre comment elle a été prise, car elle implique
un certain nombre de choix<fnref n="48" />.

On propose de distinguer 4 cas de figure pour ce figeage<fnref n="49" />, dépendant de l'organisation du SI, en allant du plus simple au plus complexe :

* *Lorsque la source administrative repose sur des déclarations administratives à temporalité maîtrisée*

Dans un processus déclaratif (une déclaration sociale, par exemple), le figeage des données est naturel, au sens où ce processus fournit par construction, indépendamment des besoins des statisticiens, des données qui ne bougent pas : ce qui est déclaré à une date t<fnref n="50" />.

Un sous-produit naturel de ce processus est le fichier contenant l'ensemble des déclarations et des déclarants pour la période de collecte, telle qu'elle est définie par le processus de collecte. Il s'agit en quelque sorte d'un processus de **figeage** « **canonique** », qui a lieu pour chaque période déclarative, en lien avec l'organisation de la gestion, sans aucune autre considération.

<footnote n="48">48 ... comme une véritable photo, d'ailleurs : sujet, date, lieu, éclairage, orientation, précision, ...</footnote>

<footnote n="49">49 Le figeage est donc l'action de figer. C'est un terme qu'on trouve dans d'autres domaines, en chimie par exemple, et qu'on va utiliser dans le reste du document. On pourrait aussi parler de « gel » des données. Le mot « extraction » pourrait aussi être employé mais il ne met pas assez en évidence l'action de fixer / figer la temporalité et tout ce que ceci implique.</footnote>

<footnote n="50">50 Même si on peut imaginer d'avoir des déclarations rectificatives ou des décalages de paie (par exemple des primes versées en décalé que l'on pourrait avoir besoin de rapprocher de la bonne période d'activité).</footnote>
Dans la pratique, la photo n'est pas non plus parfaite ; d'une période de collecte à l'autre, il peut y avoir des modifications rétrospectives (c'est le cas pour la DSN) ; mais cela reste marginal, et pour l'essentiel la valeur relative à une période est unique. Les données déclarées sont par essence figées, conditionnellement au processus déclaratif.

Exemple : dans la source mensuelle Pasrau (Prélèvement A la Source - Revenus Autres), qui correspond aux déclarations de revenus « de remplacement » de type allocation chômage, retraites etc. (Berthelot 2020), on constate que pour obtenir 100 % des versements relatifs à un mois donné, il faut prendre en compte les 5 livraisons mensuelles consécutives.

Autre exemple : les données de l'impôt sur le revenu proviennent d'une opération suivant un calendrier précis (la période de déclaration 2024 commence le 11 avril et finit le 6 juin 2024), une population bien définie<fnref n="51" />, une période de référence claire (année 2023)... Un ensemble de données figé issu de cette source peut être obtenu « simplement » par agrégation des déclarations parvenues à l'administration pendant la période de collecte<fnref n="52" />.

Le processus de déclaration, au sein duquel différents éléments sont définis *ex ante* et de manière rigoureuse (période de référence, population d'intérêt, les concepts...) est donc un bon cas de figure (Rivière 2018), dans lequel **la définition du figeage ne souffre (presque) pas d'ambiguïtés**. On parle bien ici de déclarations à l'initiative de l'administration (déclarations fiscales par exemple), avec un processus de collecte organisé.

C'est l'entité administrative qui envoie le « fichier », concatenant les déclarations, à la statistique publique, et qui en porte la responsabilité. Mais même dans ce cas idéal, tout n'est pas aussi simple en pratique : on peut avoir plusieurs livraisons, chacune caractérisée par des temporalités, un périmètre, et même parfois plusieurs fournisseurs, ce qui complique encore. C'est donc tout un **processus de livraison** qui est à mettre en place, avec tout ce que cela suppose de conventions.

* **Lorsque l'entité concernée produit déjà régulièrement, pour ses propres besoins, des jeux de données figées**

Une administration, ou une entreprise, a très souvent besoin d'avoir une vision claire de son propre fonctionnement : effectifs, achats, budget, production réalisée... Les bases de données de gestion, vivantes, ne permettent pas telles quelles de disposer cette vue d'ensemble. L'entité est donc fréquemment amenée à produire de manière récurrente des « états », des photographies d'une situation, à partir de ces bases vivantes.

Il existe donc d'une certaine manière des « produits sur étagère», des data products (Meierhofer, Stadelmann, Cielibak 2019), dans lesquels on peut piocher s'il y a accord entre les deux parties. Ils peuvent parfois faciliter le travail du statisticien, à plusieurs conditions : en connaître l'existence, avoir un accord d'utilisation (convention), disposer d'un minimum de documentation, et bien sûr

<footnote n="51">51 On peut en trouver une définition ici : https://www.economie.gouv.fr/particuliers/declaration-revenus-reponses-questions#</footnote>

<footnote n="52">52 On note que si le figeage ici semble simple (ce qu'il n'est pas, d'ailleurs), il ne garantit pas que les données soient adéquates à un usage statistique.</footnote>
que leur contenu soit utile. La gamme de ces data products<sup>53</sup> est très variée, mais on peut citer en particulier deux types très classiques.

Il peut s'agir tout d'abord d'informations de « stock », d'états de lieux calculés à partir de bases de données de gestion, en fixant la date ou la période : par exemple la liste des agents au 31/12, ou bien, pour une bibliothèque, la liste des prêts effectués au cours d'une année donnée. Dans ces exemples, le processus de figeage peut paraître relativement simple.

Mais ce processus peut prendre une forme bien plus élaborée, résultant non pas d'une « photo » mais de calculs complexes à partir d'une grande variété de données : on pense naturellement aux états comptables (compte de résultat, bilan), ou à tous les types de tableaux de bord d'activité, incluant des indicateurs de production, RH, financiers, ... Dans ce cas, l'organisme produit en quelque sorte des statistiques pour ses propres besoins, ici des besoins de reporting et de pilotage. Cela va donc bien au-delà du strict figeage de données vivantes : on a affaire à des données résultant de transformations, d'agrégations, de calculs élaborés.

Ces jeux de données « sur étagère », construits, sont définis par l'entité détentrice des bases de données. Ceci permet au statisticien de récupérer un ensemble de données qui n'est pas mouvant ... mais en même temps, celui-ci se voit imposer la manière de figer *et de transformer* les données, qui parfois n'est pas nécessairement bien documentée.

On va prendre ici un exemple en dehors du domaine des données administratives, avec des données privées, mais c'est illustratif : lors de la crise sanitaire de 2020, Orange a décidé de partager gratuitement l'exploitation de ses propres données. L'Insee a utilisé ces données déjà travaillées par l'opérateur (il ne s'agissait pas des micro-données) pour effectuer des estimations de population présente sur le territoire (Tavernier 2020).

* Lorsque la source administrative repose sur des déclarations administratives événementielles

L'exemple paradigmatique de la déclaration administrative est celle qui permet de calculer l'impôt, dans laquelle la période déclarative est fixée, décidée par l'administration, de même que la période de référence. Mais beaucoup d'autres déclarations échappent à ce cadre, car liées à un événement.

On pense naturellement aux événements d'état-civil, tels que naissance (Brumberg, Dozor, Golombek 2012 ; Espinasse, Roux 2022), mariage, décès (Coudin, Robert 2024), mais aussi à ceux relatifs aux entreprises, comme un changement d'adresse ou de raison sociale.

Dans ces déclarations, aucune des deux temporalités n'est maîtrisée. En effet, la temporalité de référence correspond à la date à laquelle l'événement se produit, ce qu'on ne peut décider dès lors qu'il s'agit d'un événement « du monde réel ». Quant à la temporalité de connaissance de l'événement, elle est souvent liée à la volonté de déclarer... or on peut tout à fait décider de le faire avec un grand retard, par exemple pour transmettre à l'assurance maladie une feuille de soins.

<footnote n="53">53 Il faut souligner ici que le principe des data products va en réalité bien plus loin, au-delà des données elles-mêmes : "A data product is defined as the application of a unique blend of skills from analytics, engineering & communication aiming at generating value from the data itself to provide benefit to another entity." Le concept de data product est aussi associé au concept de data contract qui reprend et développe l'idée de contrat d'interface historiquement utilisée dans les systèmes d'échange.</footnote>
Ainsi, avec les déclarations événementielles, si l'on obtient bien des données figées (l'événement que l'on décrit ne va pas changer, il est fixé une fois pour toutes), la non-maîtrise des temporalités a de fortes conséquences sur la maîtrise du champ : si la personne oublie de déclarer, on ne le sait pas (à l'inverse, dans un processus organisé et décidé par l'entité administrative, on pouvait repérer l'absence d'une déclaration « attendue »).

Exemple : la cessation d'activité d'une entreprise. Un tel événement peut être connu du répertoire Sirène plusieurs mois / années après la réelle fin d'activité de la société. En effet les procédures légales de liquidation d'une société peuvent être extrêmement longues.

Exemple similaire sur les décès : le RNIPP contient des individus de plus de 120 ans. En effet si la personne décède à l'étranger et que l'acte de décès n'est jamais envoyé en France, cette personne n'aura jamais le statut de décédé dans le RNIPP.

On observe ainsi une fréquente dissymétrie, dans les répertoires, entre naissances et cessations / décès. Pour pallier ces problèmes de couverture, le statisticien va devoir créer des concepts de « cessations statistiques » qui vont permettre de ne pas prendre en compte dans le champ des unités statistiques encore administrativement « vivantes » mais que l'on considère comme décédées ou sans aucune activité économique pour le cas des entreprises.

Au-delà même de ces questions de retard de déclaration, il faut toujours avoir en tête que les finalités de la gestion administrative sont différentes de celles de la statistique, et en particulier visent rarement une cohérence à l'instant t (voire même ne visent pas de cohérence du tout)<fnref n="54" />.

* Les autres situations dans lesquelles les modalités de figeage ne sont pas univoques

Dans le dernier cas de figure, complémentaire des trois autres, on ne dispose pas de déclaration administrative, et il n'y a pas de produits sur étagère prêts à l'usage qui convienne : il faut donc construire le jeu de données figées utile à l'étude statistique, à partir de bases de données de gestion. C'est probablement le cas le plus fréquent dès lors qu'il n'y a pas de déclaration.

Cela concerne les statistiques de la justice par exemple, où il faut passer « d'une donnée de gestion vivante à une donnée statistique millésimée » (Chambaz 2018), mais aussi le domaine médico-social par exemple (Berthe 2025).

Cette fois, la définition des modalités de figeage, voire des modalités de transformation, va résulter d'une **concertation** entre entité fournisseuse et entité statistique. Pour les statisticiens, il est essentiel de comprendre dans un premier temps quelles sont les données existantes dans les bases, leur signification, leur cycle de vie, leur logique d'utilisation dans les processus métier. On peut alors déterminer celles qui sont les plus pertinentes, jusqu'à aboutir à une convention entre les deux entités. Il existe ainsi en France de nombreuses conventions entre services statistiques publics (Insee ou SSM) et administrations.

La convention explicite les variables à sélectionner, le périmètre pertinent, les temporalités, et les transformations à effectuer. On arrive ainsi à des data products qui ne sont plus sur étagère, mais

<footnote n="54">54 Par exemple, en cas d'arrêt maladie, les heures non travaillées seront supprimées du décompte d'heures pour le mois concerné par l'absence. En revanche, si la rémunération a été versée dans son intégralité, les éventuelles corrections ne seront pas portées sur le mois concerné (rémunération réellement versée) mais plutôt sur le mois réel de prélèvement. D'où un décalage temporel possible heures travaillées vs rémunération associée, ce qui est gênant pour calculer un salaire horaire.</footnote>
**sur mesure**, issus d'une spécification partagée entre statistique publique et fournisseur de données.
On ne dépend donc plus de ce que l'administration a décidé de construire ... mais le travail
préalable est beaucoup plus long : la **convention**<fnref n="55" /> qui en résulte donne un cadre contractuel aux
échanges, une description formelle qui sera utile aux comparaisons dans le temps.
L'élaboration de ces conventions peut prendre beaucoup de temps, et on peut l'illustrer clairement
... avec des exemples de données privées : les données de caisse, pour lesquelles 10 ans auront été
nécessaires (Leclair 2019), et les données de comptes bancaires (Bonnet, Loisel 2024).

Le cas des données privées : quelques remarques

On a évoqué ici aussi bien les données publiques que privées, mais il existe cependant des différences notables, qu'on ne va pas détailler ici (Lesur 2025). L'utilisation de données privées soulève des questions de confidentialité spécifiques, peut engendrer des coûts significatifs (les entreprises voulant vendre leurs données, cf. le cas de la téléphonie mobile), et nécessite une organisation particulière (Chaleix, Mikol 2024).

Par ailleurs, le risque de disparition de la source, ou de non-comparabilité dans le temps (car les
structures de données ont changé), est probablement plus important que pour les données
publiques, qui, si elles sont loin d'offrir des garanties absolues, bénéficient malgré tout d'un peu
plus de stabilité. Symétriquement, la notion de déclaration, avec ce qu'elle implique d'obligation
formelle, est plutôt spécifique des données administratives.

3.c. La « source administrative » : un concept fragile

Le passage d'un système d'information vivant à un fichier de données structuré, associé à une période / date de référence et à une population d'intérêt déterminée, est indispensable à la production de statistiques. Mais en pratique, les systèmes d'information sont souvent complexes, enchevêtrés, mouvants, partiellement redondants, ce qui complexifie le figeage. Même les processus qui semblent les plus proches d'une enquête, comme ceux fondés sur des déclarations administratives, combinent souvent les données de déclarations avec des données plus anciennes qui décrivent la population d'intérêt.

Exemple : le fichier d'imposition des personnes, fourni chaque année par la DGFiP. Celui-ci contient, outre les personnes ayant fait une déclaration d'impôt l'année précédente (champ d'intérêt statistique), les personnes ayant fait une déclaration lors des 3 dernières années.

Autre exemple : les demandes d'aides européennes des agriculteurs. Les données de la PAC (politique agricole commune) comportent à la fois des déclarations relatives à une période donnée et des informations structurelles sur les exploitations pouvant être d'une origine plus ancienne (et pas toujours à jour).

Ainsi, le fait de figer les données fait souvent intervenir, même dans les cas les plus simples, des informations de filtrage pouvant opérer sur un champ plus large que les seuls déclarants.

<footnote n="55">55 On détaillera ce sujet au chapitre 4, dans la partie 4.b.</footnote>
De manière générale, le processus de figeage est mis en œuvre pour aboutir à une « source » à partir du SI, mais il n'y a pas nécessairement unicité du processus (plusieurs démarches sont possibles), ni permanence dans le temps (la structure des données dans le SI évolue). Une conséquence importante est que **plusieurs sources peuvent découler d'un même système d'information**<sup>56</sup>. L'opération consistant à figer peut intervenir à différents moments, mettre en œuvre des filtres, des sélections d'information, des agrégations ou regroupements. Elle peut apparaître comme une « projection » d'un SI vivant vers une photo d'un état daté et souvent partiel de ce SI.

De multiples projections sont possibles, les sources issues d'un même système d'information pouvant différer sur un grand nombre de critères :

* champ d'intérêt (sélection des objets et des informations),

* fréquence de mise à disposition de la source,

* fraîcheur des informations,

* périodicité des informations,

* période de référence,

* granularité des informations,

* transformations opérées sur les données.

La notion de transformation<sup>57</sup> recouvre ici un spectre assez large, et comporte entre autres les changements d'« objet » de référence. En effet, comparés aux enquêtes portant généralement sur un petit nombre d'objets (souvent un seul objet : l'individu, l'entreprise ; ou deux objets en lien comme un ménage et les individus qui le composent), les systèmes d'information administratifs possèdent généralement plusieurs dimensions, et portent sur de nombreux objets. Par exemple, pour la DSN, les objets entreprise, salarié, contrat, versement, lieu de travail, base assujettie... et pour le cadastre, les objets propriétaire, local, transaction... La multiplicité de ces objets, et la non-unicité des liens entre eux (par exemple, un salarié peut avoir plusieurs contrats) peut ainsi rendre complexe et non univoque le processus de figeage<sup>58</sup>.

> On convient d'appeler « source de données administratives » un ensemble de données figées, caractérisé temporellement, se présentant sous forme de fichier(s) déduit(s) d'un système d'information administratif par un ensemble de règles de sélection, transformations, filtres, plus ou moins explicites et maîtrisés.

L'existence de plusieurs sources issues du même SI pose différents problèmes et rend cette notion de « source » assez fragile. Ainsi, on peut trouver de la redondance dans les informations, mais aussi des divergences : les figeages étant différents, les informations a priori communes aux deux sources peuvent également diverger. La mobilisation de plusieurs sources issues d'un même SI par le service statistique public demande donc une argumentation, et une évaluation des coûts et avantages des différentes possibilités. La « source » n'existe pas à l'état naturel<sup>59</sup>, c'est une construction qui requiert de nombreuses opérations<sup>60</sup>.

<footnote n="56">56 Il peut aussi arriver qu'une source découle de plusieurs SI.</footnote>

<footnote n="57">57 On utilise ici le mot « transformation » pour le passage de données du SI à des données administratives figées. On le retrouvera après pour parler du passage de ces données administratives figées à des données brutes statistiques.</footnote>

<footnote n="58">58 Ce qui montre au passage qu'en toute rigueur, l'existence même d'un figeage canonique dans certains cas, notamment pour les déclarations administratives, n'est possible que sous certaines conditions.</footnote>

<footnote n="59">59 On peut d'ailleurs se demander si ce terme, très utilisé en pratique, est bien approprié...</footnote>

<footnote n="60">60 Voir (Denis 2018), ainsi que l'interview de l'auteur à propos de son livre : https://www.nonfiction.fr/article-9517-entretien-avec-jerome-denis-a-propos-de-son-livre-le-travail-invisible.htm</footnote>
Tout ceci explique la grande difficulté que pose la constitution d'un catalogue des sources administratives. Le site Dataactivist, qui promeut une culture générale des données citoyenne, met en évidence ces difficultés : dans sa section « L'écosystème des sources de données publiques »<fnref n="61" />, il pointe la nécessité de distinguer les sources, en fonction de l'entité productrice, en fonction de leur caractère primaire ou secondaire. Il stigmatise également la « jungle des sigles ».

On constate que même le nommage d'une source ne va pas de soi : la connaissance du SI administratif d'origine ou même d'un nom général n'est souvent pas suffisante pour que ce nommage soit univoque.

Exemple : la « source POTE » produite par la Direction générale des finances publiques à partir des déclarations de l'impôt sur le revenu se décline en réalité en quatre sources utilisées par le système statistique public, certaines portant sur un échantillon seulement ou étant déjà agrégées par l'administration.

Lorsqu'on cherche à décrire et à urbaniser les processus statistiques d'un institut, il est alors nécessaire de décrire finement les sources utilisées, afin de distinguer s'il s'agit d'une unique source ou de sources différentes, et de leur associer un millésime. Et, surtout, la notion de source est étroitement liée à l'usage envisagé pour les données qu'elle contient.

Le système statistique public utilise différentes sources de données issues du système d'information de la CNAF. Celles-ci relèvent de périodicités et dates de consolidation différentes : périodicité annuelle, consolidé 6 mois ou 2 mois après fin année n-1, sur tout le champ ; ou périodicité mensuelle, consolidé 6 mois après fin mois m-1, sur tout le champ, ou bien sur un échantillon tiré par l'Insee pour un panel de la Drees.

Ces extractions et transmissions ne sont pas sans coût pour l'administration qui les produit. Par ailleurs, elles peuvent évoluer dans le temps.

Ainsi, la CNAF a fait évoluer sa transmission de sources, en abandonnant d'abord les livraisons consolidées à 2 mois, puis en ne conservant qu'une seule livraison de données mensuelles à l'Insee, en charge de les transmettre aux différents services du SSP.

Au total, il apparaît donc que la notion de source est délicate à caractériser, et que selon les circonstances de « naissance » de la donnée, selon les modes de figeage, il existe toute une palette de sources possibles. On trouvera en **annexe 1** une présentation de typologies de sources administratives existant dans la littérature et une proposition de nouvelle typologie.

### 3.d. La difficile transition d'un univers métier à un autre

Déplacer les données d'un environnement administratif au contexte de la statistique publique peut être perçu comme une opération purement technique de transmission de fichiers<fnref n="62" />. C'est pourtant bien plus que cela : il s'agit plus généralement d'un changement d'univers, d'écosystème, qui ne va nullement de soi contrairement à des idées préconçues. Considérée dans toute sa généralité, cette question a suscité depuis une quinzaine d'années une vaste littérature.

<footnote n="61">61 https://open.dataactivist.coop/docs/culture-generale-donnees-section-4</footnote>

<footnote n="62">62 ... transmission qui ne va pas de soi non plus : dans Informatique, normes et, temps (1999), Isabelle Boydens reprend une citation d'un général américain, lors de la première guerre du Golfe en 1990, où celui-ci regrette amèrement que « la transmission des bases de données soit moins rapide que celle des objets physiques ».</footnote>
Dans un récent article, (Borgman, Groth 2025) sont allés jusqu'à développer la métaphore de la « distance » entre le créateur de la donnée et l'utilisateur de la donnée, et les différentes dimensions de cette distance (méthodes, domaines, objectifs,...).

• Un cliché : il faut transmettre des « données brutes »

L'idée selon laquelle certaines données (administratives, notamment) doivent être accessibles à tous, sans restrictions majeures, pour promouvoir la transparence, l'innovation et le développement socio-économique a été centrale dans le mouvement de l'Open data. Un moment clé dans l'histoire de l'Open Data fut la réunion tenue à Sebastopol, en Californie, en décembre 2007⁶³. Cette conférence a rassemblé des militants, des chercheurs et des praticiens pour définir un cadre initial pour les données ouvertes, qui s'est articulé en huit principes fondamentaux : des données complètes, **primaires**, opportunes, accessibles, lisibles par des machines, non discriminatoires, sans licence restrictive, durables.

Le deuxième principe insiste sur le fait que les données doivent être rendues disponibles sous leur **forme primaire**, c'est-à-dire non transformées, directement issues de la source, et sous forme détaillée. Tim Berners-Lee, l'un des promoteurs majeurs du mouvement<fnref n="64" />, a particulièrement insisté sur ce point dans une conférence Ted restée célèbre, en février 2009, dans laquelle il fait répéter à son public « *Raw data now!* »<fnref n="65" />.

Mais ce principe a été rapidement battu en brèche, en particulier dans l'ouvrage collectif « Raw Data is an Oxymoron » (Gitelman 2013) : les auteurs y remettent en question l'idée de données brutes existant de manière « pure » ou « objective ». Outre le fait que les données sont toujours contextualisées par les choix humains dans leur collecte, leur structuration et leur interprétation, ils pointent une illusion de neutralité : présenter les données comme « brutes » masque les biais implicites dans les processus de création et d'analyse des données. Enfin, de façon évidente, les données ont besoin de métadonnées et d'une interprétation pour être significatives et utiles.

Dans « La fabrique des données brutes », (Denis, Goëta 2014) remettent également en cause le mythe des données brutes, qui masque les transformations nécessaires pour rendre les données utilisables, en soulignant que les données sont toujours le produit d'un travail humain et technologique. Ils vont même plus loin, en introduisant le concept de « brutification » des données : mise au format standard, nettoyage et désindexicalisation pour les rendre compréhensibles et utilisables par des tiers. Ils montrent que le processus d'ouverture des données ne consiste pas seulement en un transfert technique, mais nécessite une coordination entre acteurs institutionnels, des ajustements techniques, des compromis.

Ainsi, la notion de « donnée brute » n'a rien d'absolu : par exemple, en statistique d'entreprise, on récupère des données comptables, la statistique publique voyant ces données comme « brutes ». Si l'on se place maintenant du point de vue de l'entreprise, c'est tout l'inverse, les données comptables sont issues d'un long processus de construction, de mise au point, elles découlent de multiples calculs. Les données, de façon générale, sont donc au contraire extrêmement transformées – voir aussi le plaidoyer de (Christen, Schnell 2024) à ce sujet. Pour illustrer cela simplement, il suffit de prendre l'exemple des capteurs (de température, de pollution, ...): la donnée la plus brute possible

<footnote n="63">63 Voir (Goëta 2024) pour une présentation de l'histoire de l'open data.</footnote>

<footnote n="64">64 A l'origine du web, en étant l'inventeur du protocole http, et plus récemment promoteur du web sémantique.</footnote>

<footnote n="65">65 Voir https://www.youtube.com/watch?v=OM6XIICm_qo, vers 11' – 11'30. Tim Berners-Lee évoque bien d'autres choses dans son discours, notamment l'importance de la standardisation des formats et l'idée d'un système de données liées (linked data).</footnote>
serait ... une impulsion électrique localisée et datée, donc tout à fait inutilisable telle quelle. *In fine,*
on va donc paradoxalement *construire* le caractère « brut » de la donnée, en conditionnant les
données précisément pour l'usage prévu.

Changer d'univers ne va pas sans frictions

Paul N. Edwards, dans « A Vast Machine » (2010), montre le rôle central des données dans la science climatique, décrivant leur collecte, leur transformation et leur utilisation pour modéliser et comprendre le climat global. Il insiste sur le fait que les données climatiques ne sont pas des "faits bruts" mais des "produits" créés à travers un processus d'interprétation et de transformation ... processus qui différeront entre météorologues et climatologues, qui n'ont pas les mêmes objectifs.

Les météorologues vont en effet se concentrer sur la prévision à court terme, avec des données très précises et localisées, alors que les climatologues étudient les tendances à long terme du système climatique, avec des moyennes et agrégats sur longues périodes, en cherchant à comprendre des interactions globales (atmosphère, océans, cryosphère,...).

Il souligne que ces différences conduisent à des attentes divergentes quant à la nature et à
l'utilisation des données, ce qui peut générer des incompréhensions. Les météorologues produisent
ainsi des données d'observation essentielles pour les climatologues, mais qui posent plusieurs
problèmes dans leur utilisation à long terme, notamment des biais instrumentaux (changements
dans les capteurs ou leur emplacement) et des discontinuités (réseaux d'observation non uniformes
dans le temps et l'espace, laissant des lacunes importantes dans les archives climatiques).

Ceci nécessite que les climatologues modifient, complètent et homogénéisent les données météorologiques, un processus que certains météorologues perçoivent comme une altération ou une manipulation des "faits bruts".

Dans le même ouvrage, Edwards introduit le concept de "**data friction**", largement repris depuis
lors (Bates 2017, Lehuede 2024) : cette notion fait référence aux obstacles, tensions et efforts
nécessaires pour collecter, harmoniser, partager et interpréter des données dans des environnements
complexes, ce qui se complexifie encore au niveau international. Il emprunte l'idée de "friction"
aux sciences sociales et à la physique, où elle décrit la résistance au mouvement.

La *data friction* se produit à l'interface<fnref n="66" /> de deux « surfaces » de données, et restreint, au même titre qu'un frottement en physique, le mouvement des données, augmentant le coût et l'effort nécessaire pour les déplacer (Lombardo 2023)<fnref n="67" />. Les mouvements sont en effet entravés par les incohérences entre formats et standards, les biais méthodologiques dans la collecte des données, les limites des infrastructures techniques, ou les tensions institutionnelles.

(Courmont 2021) retrouve des idées similaires dans un autre contexte, hors domaine scientifique : celui de l'ouverture des données du Grand Lyon, à des fins citoyennes, par exemple la mise à disposition de données de mobilité à partir de sources administratives. Il constate la très fréquente inadéquation de ces sources administratives (par exemple celles de la voirie), et la nécessité d'organiser un « détachement » de leur environnement initial pour effectuer un « réattachement » pour un futur usage. Donc, à nouveau, tout un travail de conditionnement des données.

<footnote n="66">66 Une interface certes technique, mais aussi sémantique, ce qui est central dans le propos du présent document.</footnote>

<footnote n="67">67 Pages 5 à 7.</footnote>
• Qu'en est-il de l'usage statistique ?

Le passage de l'univers administratif à l'univers statistique est une illustration parmi d'autres de la transition, du mouvement des données entre différents domaines métier : la nécessité de conditionner les données, l'existence de *data frictions*, le besoin de se détacher de l'écosystème de départ pour se réattacher au nouveau, tout cela reste valable.

On peut cependant ajouter des spécificités, l'une en amont de ce mouvement côté fournisseur, l'autre en aval côté utilisateur.

Côté fournisseur de données, il faut souligner que la notion de *data friction* a été introduite dans le domaine scientifique (Edwards et al 2011), où on peut considérer, certes en simplifiant pour les besoins du propos, qu'on dispose de données figées, car représentant des résultats d'expériences. Or les données administratives, susceptibles d'évoluer régulièrement en fonction d'événements (événements d'état-civil, demandes de l'usager, décisions de l'administration), n'ont pas, dans de nombreux cas, cette propriété. Le détachement de l'univers d'origine va donc nécessiter, en plus du reste, un travail de fageage des données.

Côté utilisateur, l'usage statistique est un usage à des fins d'information, structuré par la grille d'analyse du premier chapitre (unités, variables, champ, temps, catégories) : si les questions relatives aux unités et variables apparaîtront peu ou prou pour n'importe quel usage, la question de la complétude du champ va jouer un rôle majeur, de même que la qualité de catégorisation. Un travail fin sur les doubles temporalités sera également nécessaire. Enfin, l'usage statistique se caractérise par l'idée d'une « marge d'erreur » possible, et même mesurable, à l'opposé par exemple d'un usage comptable (où l'on doit pouvoir vérifier les choses à l'euro près), ou d'usages avec implications opérationnelles (montant d'une retraite, par exemple).

Dans tous les cas, il s'agira au bout du compte de parler un langage commun, de se doter de conventions partagées, et de traquer l'implicite.

### 3.e. Statistiques fondées sur données administratives : une démarche en trois phases

La statistique n'est pas la finalité première de ces données, et requiert leur déplacement hors de leur système d'information d'origine. Les fondements même des estimations statistiques disparaissent, et un ensemble de transformations sont donc nécessaires pour rendre possible la pertinence des estimations. Par ailleurs une évaluation détaillée de la qualité des données administratives se révèle essentielle : (Statistics New Zealand 2016) propose pour cela une démarche très complète, sous forme de guide, en analysant les sources possibles d'erreur.

Pour passer des données administratives « initiales » à des données équivalentes à ce qui sortirait d'une enquête, on propose ici une démarche en trois phases, chacune cherchant à résoudre prioritairement une ou plusieurs des difficultés rencontrées.

La première phase, la phase **d'acquisition**, vise à constituer ce qui sera notre « vraie » source administrative de référence. Cette phase incorpore la définition et la réalisation du fageage dont on a parlé précédemment. Elle s'achève par une étape de qualification, qui permet un « go-no go » pour la suite. A la fin de cette phase 1 on a affaire à des données compréhensibles par l'entité
administrative, ce qui permet justement des vérifications, des questions. Soulignons que dans la
conception même de cette phase d'acquisition, il faut avoir en tête ce qu'on veut en faire derrière,
i.e. quel genre de statistiques on veut produire. La phase d'acquisition sera l'objet du chapitre 4.

Dans la 2e phase, dite de **transformation**, on va délibérément se détacher du monde administratif, pour se réattacher (au sens de Courmont) au monde statistique. On se situe toujours dans une branche séparée du Y (cf. partie 2.e), avec un travail spécifique aux données administratives, qui ne va pas de soi : on l'a vu (Borgman, Groth 2025), on ne passe pas impunément d'un créateur de données à un utilisateur, d'un univers métier à un autre.

La phase de transformation, qui sera l'objet du chapitre 5, s'achève naturellement par une étape de qualification, mais qui n'a plus rien à voir avec celle de la phase 1 : on est cette fois passés au monde statistique, avec des objets, des variables, un champ, ... compréhensible par les statisticiens. Cette fin de phase 2, c'est donc le nœud du Y, à la suite duquel les traitements seront communs avec ce que l'on fait dans le cas d'une enquête. Si l'on se positionne vis-à-vis du GSBPM, ces deux premières phases, d'acquisition et de transformation, sont parallèles aux phases de conception, élaboration et collecte qui prévalent pour les enquêtes.

Elles permettent de passer d'un monde à l'autre, ce qu'on peut résumer dans le tableau qui suit:

Ce qui existe
dans le monde administratif

Système d'information vivant

Système d'information très riche,
disparate

Pas de période de collecte

Pas de période de référence

Listes de codes administratifs

Objets administratifs

Concepts administratifs

Champ réel administratif

Ce dont on a besoin
dans le monde statistique

Jeu de données figé

Observations et informations utiles pour
répondre au besoin statistique

Période de référence associée à une donnée

Nomenclatures

Unité(s) statistique(s)

Variables d'intérêt

Appartenance au champ statistique

Représentativité du champ statistique

<figure><img src="image_8.png" /></figure>

Etant désormais dans un monde statistique, on pourra passer à la phase 3, dite de **traitement statistique**, qui est très similaire à ce qui se fait dans les enquêtes (c'est donc très exactement la phase de traitement qu'on trouve dans le GSBPM). Elle présente quelques particularités pour les données administratives (y compris des fonctions qui disparaissent et qui étaient présentes pour les enquêtes) qu'il faut préciser, et qui seront présentées au chapitre 6.
B. La démarche proposée
# 4. La phase d'acquisition : vers une source administrative qualifiée

## 4.a. Principes

Lors de cette première phase, on va évacuer plusieurs défauts inhérents au système d'information administratif, en vue de faciliter l'exploitation statistique future des données<sup>68</sup>. On vise ainsi à traiter les questions suivantes :

* le caractère vivant du SI d'origine ;

* la très grande taille, et complexité, du SI d'origine ;

* le manque de clarté des temporalités (période d'obtention, période de référence) ;

* l'hétérogénéité des fichiers récupérés.

L'acquisition va donc conduire à figer les données administratives, en s'appuyant sur la temporalité connue des informations, à travers des opérations du type : filtrages sur les objets ou sur les attributs (on ne prend pas tout ce qui est disponible), jointures entre plusieurs tables du SI d'origine, des fusions de fichiers (par exemple des fichiers par département rassemblés en un seul), mais pas de transformation de données.

La source ainsi produite, issue de cette phase 1, restera ainsi dans la logique de l'entité administrative, avec ses propres concepts, objets, domaines, ... C'est là une propriété décisive de cette phase : grâce à cela, les statisticiens parleront le même langage que les représentants de l'entité administrative, pourront échanger, alors que ce ne sera pas possible une fois les transformations opérées.

La phase d'acquisition ne peut se limiter à « « récupérer une source figée et bien délimitée ». On veut aussi avoir une bonne compréhension de sa qualité. La phase d'acquisition incorpore donc naturellement tout un travail de qualification, et des itérations avec l'entité administrative. On produit à la fin de cette phase une source administrative bien cadrée et qualifiée... alors que le vrai point de départ, le SI, était particulièrement nébuleux.

Pour cela, la démarche proposée comporte deux temps, s'inspirant de (Cerroni, Bella, Galie 2014) et (Daas 2009). Ces auteurs séparent d'une part l'analyse de la source et celle des métadonnées, d'autre part le travail sur les données elles-mêmes (cf. annexe 2, pour l'application à Istat).

Le premier temps est celui de la préparation. Il comporte une découverte de l'univers administratif considéré, de sa signification, de son fonctionnement, de son cadre juridique : les données ne sont pas des abstractions, elles emportent avec elle un domaine métier, des objectifs, un langage, des pratiques, et il faut en saisir les codes. Tout cela nécessite l'accès à des documentations détaillées, et requiert la connaissance des métadonnées (sur les domaines de valeurs, par exemple), qui vont être indispensables pour la suite<sup>69</sup>. La préparation inclut également l'élaboration concertée d'une organisation de la transmission de données : protocole, contrat d'interface, data contract, ...

La réception – qualification a lieu dans un second temps. Cette fois, on récupère les données elles-mêmes, mais on effectue aussi toute une série de contrôles automatiques (voire manuels). Ceci exige d'avoir formalisé au préalable ce que l'on entend par qualité.

<footnote n="68">68 Il faut souligner qu'on parle ici des données individuelles, mais qu'il peut exister des cas où certaines données arrivent sous forme agrégée. On ne développe pas cette question dans le présent document.</footnote>

<footnote n="69">69 Voir aussi (Bonnans 2019) pour les métadonnées utilisées dans le système statistique public français.</footnote>
Cette subdivision en deux temps ne veut pas dire qu'on se limite à un enchaînement linéaire : la qualification peut conduire à repérer des problèmes de diverses natures (valeur de code imprévue, incohérences, distribution de valeurs non plausibles, ...), ce qui va entraîner des discussions avec l'entité administrative. On introduira ainsi l'idée de « boucles de rétroaction », qui peuvent permettre d'améliorer les fichiers produits. Ceux-ci seront à la fois un *output* de la phase d'acquisition et un *input* de la phase de transformation.

Enfin, le processus ainsi décrit, avec les deux temps et les boucles de rétroaction, se déroule nécessairement de façon différente lorsqu'on utilise plusieurs fois la même source : c'est le cas pour des usages répétés de la même source par le même producteur statistique, ou pour des usages mutualisés entre producteurs. On en expliquera l'impact sur le processus d'acquisition.

## 4.b. Le temps de préparation : source, écosystème, convention

La littérature sur les données administratives souligne l'importance d'adopter une approche globale, qui s'intéresse non seulement aux données elles-mêmes, mais aussi au processus qui les produit et à l'organisme qui en a la charge, qu'on va appeler « fournisseur ».

* **Le fournisseur**

Il se caractérise par un statut, une position, et un cadre juridique dans lequel son activité s'inscrit.

Ainsi, la DGFIP a naturellement en charge les données fiscales, qui sont au centre de son activité. Les données peuvent aussi être détenues par un opérateur, qui n'a pas de responsabilité métier, mais assure la gestion de flux de données : c'est le cas du GIP-MDS, qui a en charge un très vaste ensemble de déclarations sociales, en premier lieu la DSN, mais aussi la déclaration préalable à l'embauche (DPAE) de la MSA et de l'Urssaf, ou le Pasrau.

Face à une source potentielle de données, une fois qu'on a déterminé quel organisme est légitime pour cette fonction de fournisseur, il faut déterminer si cet organisme, *dans ce rôle*, est fiable. Dans le cas des déclarations administratives, cette fiabilité va découler de l'existence d'obligations légales pour les déclarants.

> C'est le cas pour la déclaration sociale nominative, mais aussi pour le répertoire d'établissements de santé FINESS, pour lequel toute modification doit avoir une base légale (Bensoussan, Bizingre, Courvalin 2023).

On se posera également la question de la pérennité de la source, ce qui ne va pas de soi (cf. la disparition de la taxe d'habitation), voire du fournisseur.

* **La source potentielle, l'écosystème**

Mais on ne « fournit » pas des données comme on le ferait pour des tables et des chaises, par exemple. On l'a vu au chapitre 3 : avant toute obtention de fichier, il est essentiel de prendre connaissance de manière approfondie de l'univers dans lequel naissent les données, de la raison de leur existence, des problématiques rencontrées par l'administration à l'origine des données.
Un minimum de curiosité, d'ouverture de la part du service statistique, s'impose ici. Cet effort est indispensable pour comprendre la façon dont sont gérées les données, les objets concernés, les liens entre eux, les concepts, l'histoire de leur mise en place, etc. Tous ces échanges nécessitent du temps (cf. la *data friction*). Ils peuvent aller jusqu'à une démarche d'immersion d'un statisticien au sein de l'administration détentrice des données.

La pratique de l'immersion, plus intensive, est notamment envisagée par l'institut de statistique britannique (ONS), sur plusieurs mois. L'ONS peut ainsi participer à la co-construction de la source produite à l'issue de la phase 1 (Fermor-Dunman, Parsons 2022).

Bien comprendre, c'est aussi cerner la dynamique d'élaboration des données. Zhang (2012) propose ainsi de chercher à identifier les différents types d'erreur<sup>70</sup> pouvant survenir dans la naissance et le cycle de vie des données (Shah et al 2021)<sup>71</sup> : il s'agit d'identifier en quoi la mise en œuvre du processus administratif pourrait s'éloigner de son objectif théorique. Cette analyse est précieuse, elle contribue à bien identifier les critères qui seront mis en œuvre dans la qualification des données.

La nécessité de développer la connaissance de l'environnement, de la source, reste une constante. Elle vaut tout au long de la phase de préparation, mais aussi ultérieurement. Attention cependant, il ne s'agit pas de le faire dans l'absolu, mais dans l'optique **de répondre à un besoin statistique défini**. On retrouve ainsi, mais de façon différente, la **définition des besoins**, première phase du GSBPM : simplement, celle-ci est étroitement mêlée à la découverte de la source. En pratique, soit ce besoin existe et on s'assure que la source possède de données pertinentes pour y répondre, au moins partiellement, soit les données elles-mêmes apportent des opportunités nouvelles<sup>72</sup>.

Quoi qu'il en soit, l'analyse approfondie des objets administratifs et des concepts associés, ainsi qu'une compréhension (au moins superficielle) des processus métier se révélera très utile pour bien définir le futur fichier figé et sa structure, y compris lorsque celui-ci n'existe pas par défaut dans l'administration d'origine. Notons qu'il existe aussi, heureusement, des situations où les données administratives, leur environnement, leurs usages métier, sont très bien maîtrisés côté statistique : c'est notamment le cas lorsque les sources sont utilisées depuis longtemps (mais rien n'est acquis, et elles peuvent aussi évoluer dans le temps).

* **Récupérer les métadonnées sur la source**

Ayant bien appréhendé les tenants et aboutissants de la source, on passe à une analyse d'une toute autre nature, plus pratique : on va rechercher toutes les informations, parfois techniques, permettant de mieux comprendre ce que contient la source, comment elle est construite. On veut avoir des données sur les données, i.e. des métadonnées. Dans cette chasse aux documentations, les pépites que l'on recherche renvoient à notre grille d'analyse : définition des objets mobilisés, des variables, formalisation des domaines de valeurs, description du champ, temporalités.

<footnote n="70">70 Voir page 43. L'auteur se place naturellement du point de vue d'un statisticien. Mais on pourrait gloser sur le sens du mot erreur, qui n'est pas toujours le même selon l'observateur.</footnote>

<footnote n="71">71 Il faut être vigilant sur la notion même de « cycle de vie de données », qui ne fait nullement l'objet d'une standardisation ou même d'un consensus. L'article de 2021 cité en référence en dénombre 76 modèles ...</footnote>

<footnote n="72">72 Dans le domaine des données privées on peut citer l'utilisation des données de téléphonie mobile pour évaluer les départs d'Ile-de-France lors des confinements, ou dans le cas des données administratives, l'utilisation de la DSN pour évaluer le chômage partiel : https://blog.insee.fr/suivre-la-conjoncture-lorsque-les-entreprises-repondent-moins-aux-enquetes/.</footnote>
Le cas de la DSN, à travers son « cahier technique »<sup>73</sup>, constitue à cet égard un exemple complet et rigoureux. Le champ déclaratif et les temporalités (de déclaration, de référence) sont ainsi décrits dans la partie introductive de cette documentation. Les concepts dérivent d'un modèle conceptuel de données et donnent lieu à des « blocs » déclaratifs. On y explicite les variables, appelées « rubriques », qui sont des attributs de ces concepts. Et pour chaque variable, le domaine de valeurs est caractérisé, de différentes manières : typage, liste de valeurs, appartenance à un référentiel externe, voire utilisation d'une expression régulière formalisant la structure d'une chaîne de caractères (Friedl 2006). L'ensemble de ces éléments constitue une « norme d'échange », versionnée annuellement<sup>74</sup>, partagée par les différents partenaires, et associée à un outillage dédié (Dubrulle, Rosec, Sureau 2023). Soulignons simplement qu'en toute rigueur, il s'agit là d'une documentation du flux, et non de la source qu'on peut construire à partir de là. Par ailleurs, la description formelle est importante mais ne prémunit pas de sujets de qualité liés à des pratiques déclaratives (sur la déclaration des heures par exemple).

Séparer chronologiquement compréhension de la source et obtention de métadonnées est quelque peu artificiel : souvent, les travaux portant sur les métadonnées débutent dès la découverte de la source, et se poursuivent avec le contact avec le fournisseur. Le travail de découverte peut s'appuyer sur les métadonnées lorsqu'elles existent, et surtout sur un dialogue fructueux avec le fournisseur (Eurostat, 2017b).

Si l'on compare avec le GSBPM, cette étape a des points communs avec l'étape de conception.

• Établir les modalités pratiques de l'échange

In fine, le but de la phase de préparation est d'organiser la transmission d'une « source » entre un service administratif « fournisseur » et un service statistique « récepteur » de celle-ci ... et qui sera lui-même producteur de statistiques.

Pour cela, de nombreux échanges vont avoir lieu avec le fournisseur des données : responsables métier, mais aussi responsables informatiques. Il faut en effet mettre en place des processus d'échange sécurisés et robustes, les données étant souvent volumineuses et confidentielles<sup>75</sup>.

On va donc organiser le fonctionnement d'une **coopération** entre producteur de statistiques et entité publique (Chaleix, Vanderschelden 2023), dans laquelle l'aspect relationnel ne doit pas être négligé. Cela peut revêtir différentes formes non exclusives, des échanges d'information par mail aux réunions ponctuelles, en passant par des processus de négociation. Considérer l'entité administrative uniquement comme un « fournisseur de données », c'est faire fi d'une chose : on n'a pas vraiment défini ce qui devait être fourni et ce que cela signifiait, et c'est bien là tout le problème. De telles discussions peuvent être facilitées si l'interaction se fait avec une équipe statistique de l'entité administrative<sup>76</sup>.

<footnote n="73">73 https://www.net-entreprises.fr/media/documentation/dsn-cahier-technique-2024.1.pdf</footnote>

<footnote n="74">74 Un autre élément remarquable est que l'évolution de la norme se fait dans un calendrier très précis chaque année ce qui permet à la statistique publique d'adapter ses systèmes d'information aux évolutions de la norme dans des délais très confortables.</footnote>

<footnote n="75">75 Cela ne va pas toujours de soi, et il peut arriver qu'une transmission par support physique soit encore une solution de repli en 2024...</footnote>

<footnote n="76">76 Il arrive aussi que le service statistique soit lui-même client de sa propre entité administrative, et est alors lui-même confronté aux difficultés de figeage de l'information notamment.</footnote>
En France, certaines entités publiques disposent de leur propre service statistique : c'est le cas en particulier des caisses nationales de sécurité sociale, comme la Cnaf, la Cnam, ou la Cnav<sup>77</sup>. Celui-ci joue alors souvent un rôle utile d'intermédiaire dans les échanges entre producteurs de statistiques et entité administrative fournisseuse : la communication se faisant « entre statisticiens », la compréhension s'en trouve facilitée, et l'on réduit ainsi la *data friction*.

La question du cadre légal de cette transmission de données se posera aussi. En France, avec l'article 7bis de la loi de 1951, un tel cadre existe pour les données administratives, mais tout ne passe pas par lui. De plus, un problème de gestion de la confidentialité va se poser (Redor 2023).

Tout cela conduit petit à petit à mettre en place une **contractualisation** entre l'administration qui détient ou fournit les données et le ou les services utilisateurs, ce qui se matérialise par une convention entre les parties. Elle permet de décrire précisément ce qui est transmis, par qui, quand, comment, selon quelles modalités, dans quel format, ...

On peut citer notamment la convention entre l'Insee et la DGFIP pour l'usage des données fiscales (avec une annexe pour chaque source).

D'une certaine façon, la contractualisation est une manière pour la statistique publique de regagner un peu de maîtrise sur la donnée administrative. Pour cela, l'existence de conventions est indispensable : elles doivent être très précises, notamment quant aux dates de livraison (au jour près) lorsque la source est input d'un processus de production statistique lui-même contraint.

Exemple : la DSN est utile pour la production de données conjoncturelles, dont les délais de publication sont imposés par Eurostat. Tout retard de livraison peut se traduire par un retard dans la publication des données et un non-respect des engagements vis à vis d'Eurostat.

Soulignons cependant que dans le cas d'un usage ponctuel des données, il peut aussi ne pas y avoir de transmission formalisée, pas de convention du tout : c'est la situation dans laquelle le statisticien (ou le data scientist) essaie de « faire au mieux » avec les jeux de données qu'il découvre au fur et à mesure. C'est une situation courante dans les « pôles data » des inspections, dont le travail est limité dans le temps : l'essentiel des données ne présentent plus d'intérêt une fois la mission achevée (Bolliet et al 2025, Berthe 2025).

## Résultat du temps de préparation

Concrètement, le travail de préparation a pour résultat :

* un jeu de métadonnées,

* une documentation,

* une forme de contractualisation,

* ... et la décision de poursuivre le processus ou non.

En effet, l'un des choix opérationnels possibles à l'issue de cette évaluation est de décider ... de ne pas poursuivre le projet d'exploitation, parce que la source ne sera pas en mesure de répondre aux besoins. Les raisons peuvent être multiples : il peut s'agir de considérations statistiques (concepts ou objets trop différents des unités d'intérêt, champ théorique de la source trop restreint, délai

<footnote n="77"><sup>77</sup> Cnaf = Caisse nationale des allocations familiales, Cnav = Caisse nationale d'assurance vieillesse, Cnam = Caisse nationale d'assurance maladie.</footnote>
d'obtention des données trop long), mais également de raisons éthiques (manque de proportionnalité dans l'usage de données personnelles, acceptabilité du projet par la société civile).

On peut prendre l'exemple du programme Résil qui a décidé de ne pas mobiliser des données de santé (utilisation de la carte vitale) ou du RNCPS (répertoire utilisé à des fins de lutte contre la fraude) ou de données sur les titres de séjour pour une meilleure acceptabilité sociale de son traitement au détriment d'une meilleure qualité statistique qui avait été prouvée par des expérimentations sur des échantillons de données (Dupont et alii, 2024).

Si au contraire on décide la poursuite du projet, le temps de préparation aura rendu possible la suite, i.e. le temps de réception-qualification. Celui-ci vise ainsi à obtenir, pour les phases ultérieures, des données dont on connaît le niveau de qualité.

Mais avant même d'expliciter la qualification d'une source, qu'entend-on vraiment par « qualité » ?

### 4.c. Qualité des données administratives : une notion contingente

* Notion de qualité de données

La qualité n'est pas une notion absolue : elle s'évalue **par rapport à un usage** : « *Quality is fitness for use.* » (Juran 1951). Dans le cas d'un véhicule par exemple, la qualité ne sera pas appréhendée de la même manière selon qu'on l'utilise pour partir en vacances en famille ou pour faire de la vitesse sur circuit.

Cela s'applique à la qualité des données : « *Quality is not a property of the dataset itself, but of the interaction between the dataset and the use to which it is put.* » (Hand 2018). Ainsi, même si certaines caractéristiques sont générales (ex : la conformité à un format), on ne peut pas parler de qualité de données « en soi ». On peut ainsi aboutir à un paradoxe : avoir des données jugées bonnes pour un usage, et non pour un autre. (Edwards 2010) pointe cette difficulté lorsqu'il évoque les incompréhensions entre météorologues et climatologues, qui n'ont pas du tout la même utilisation des données, et donc des critères de qualité très différents.

Deuxième idée importante : la qualité des données est multidimensionnelle. Dans la littérature académique sur le sujet, on retrouve peu ou prou les mêmes composantes de la qualité.

(Di Ruocco et al 2012) définissent des familles d'indicateurs : pertinence, exactitude, complétude, consistance, précision temporelle, accessibilité, interprétabilité, unicité, cohérence, conformité à un standard. (Bontems, Goulin 2013) se limitent à 6 dimensions : pertinence, exactitude, rapidité de diffusion de l'information<sup>78</sup>, accessibilité, possibilité d'interprétation, cohérence. (Batini, Scannapieco 2016) introduisent la notion de qualité du schéma de la base de données, et soulignent la nécessité de faire des compromis entre les différentes dimensions. (Loshin 2011) distingue dimensions intrinsèques (exactitude, *lineage* ou traçabilité, cohérence et homogénéité des formats, cohérence sémantique – existence de définition, unicité du nommage) et des dimensions contextuelles (complétude, cohérence, actualité et ponctualité,...). Au passage, on retrouve des idées similaires pour caractériser la qualité *des données statistiques*, dans le code de bonnes pratiques de la statistique européenne (Eurostat 2017a).

<footnote n="78"><sup>78</sup> Cette rapidité, du point de vue du statisticien, c'est en réalité l'écart entre la temporalité de référence et la temporalité d'acquisition. Pour l'utilisateur, la qualité d'une statistique produite comporte un élément d'actualité, et se réfère donc à la temporalité de diffusion, qui sera ultérieure à l'acquisition.</footnote>
• Quid de la qualité des données administratives ?

Comme n'importe quelles données, les données administratives ont été conçues pour des usages particuliers, et répondent aux critères de qualité associés, différents de ceux des statisticiens publics.
Les déplacer dans l'univers statistique nécessite de vérifier leur adaptation à ces nouveaux usages.

Il s'agit à la fois de s'assurer de la qualité pour ses dimensions intrinsèques puisque le processus est réalisé par un tiers, mais également pour ses dimensions contextuelles puisque les données sont « détachées » de leur usage premier, et réutilisées pour un objectif statistique.

Au Royaume-Uni, l'autorité statistique (UK Statistics Authority) a ainsi mis en place des piliers de Quality Assurance of Administrative Data (QAAD) incluant aussi bien le contexte opérationnel du recueil de données dans l'administration que la communication avec les fournisseurs de données ou les principes d'assurance qualité de ceux-ci (Babb 2017). Plus récemment, un cadre général d'assurance qualité a été défini en commission statistique à l'ONU, subdivisé en 10 exigences critiques (United Nations 2025).

Le fait que les données administratives servent à supporter l'activité d'une administration n'est pas une garantie de qualité pour les besoins statistiques. Ainsi, elles peuvent ne pas avoir été mises à jour depuis longtemps, par exemple parce que les intéressés n'ont pas transmis l'information.

C'est le cas par exemple pour la variable adresse dans les données administratives de santé en Irlande du Nord : (Foley et al 2018), après analyse d'un vaste échantillon, montrent que certaines sous-populations sont moins enclines que d'autres à informer l'administration de leur changement d'adresse (les jeunes, par exemple), ce qui engendre beaucoup d'erreurs.

Les données peuvent parfois comporter un **biais**, un risque d'erreur dû au fait qu'on a « intérêt » à déclarer à l'administration telle valeur, pour obtenir une allocation, une subvention, par exemple : on ne parle pas ici de mensonge délibéré, mais plutôt de choix d'interprétation favorable.

Exemple : l'activité principale d'une entreprise (APE) peut avoir dans certaines situations des impacts très opérationnels, et jouer un rôle dans l'éligibilité à certaines aides.

Plus généralement, contrairement à ce qui se passe en statistique, ou dans des expériences scientifiques, la donnée n'est nullement une fin en soi pour l'administration. Comme on l'a vu au chapitre 2, elle n'existe le plus souvent que comme déclencheur d'actions, comme intermédiaire, comme co-produit. Dès lors, du point de vue administratif, il n'y a pas de problème de qualité si la donnée permet de déclencher les actions adéquates de manière opportune.

Exemple : une « carrière » est vue par une caisse de retraite comme déclencheur de l'action « calcul des droits à retraite ». Si elle est incomplète, mais que ses manques ne changent rien aux droits à retraite, la carrière est « de qualité », pour l'administration. Elle ne l'est pas pour un chercheur qui veut avoir la totalité de l'information pour ses analyses longitudinales.

Par conséquent, des données peuvent tout à fait être jugées de qualité suffisante pour un usage administratif, alors que ces mêmes données sont considérées comme de mauvaise qualité pour un usage statistique.
En d'autres termes, « qualité » n'est pas synonyme d'absence ou de faible nombre d'erreurs : sans la moindre erreur, sans le moindre dysfonctionnement de la part de l'administration, les données administratives peuvent présenter, pour un regard statisticien, différents défauts.

## Quelques exemples de divergence entre qualités statistique et administrative

Dans les exemples qui suivent, différentes dimensions de la qualité peuvent être concernées.

### Des informations approximatives

Le fait que les données soient précises n'est pas toujours une exigence indispensable pour une administration, en particulier sur des périodes anciennes.

Exemple : l'année de construction des bâtiments dans le fichier du cadastre présente des pics de distribution pour les années multiples de 10 au XIXe siècle. On peut imaginer que ce soit dû aux modalités d'enregistrement de l'information à l'époque. Il n'y a pas de problème de qualité pour les services du cadastre, en l'absence d'impact opérationnel direct. Mais si l'on voulait effectuer une analyse temporelle fine, avec par exemple l'impact des événements de l'époque (1830, 1848, 1870), la qualité serait jugée très insuffisante.

### Un format d'information inadapté à l'usage statistique

L'information présente dans les sources peut être exacte mais avec un format qui rend difficile son exploitation, et qui ne facilite donc pas une utilisation sur des volumes importants.

Exemples : dans le fichier des cartes grises, l'information sur les noms des propriétaires figure dans un seul champ, entraînant une complexité de traitement lorsqu'un véhicule est détenu par plusieurs personnes.

Il peut aussi arriver que des informations soient récupérées sous forme de document scanné en PDF et qu'on soit obligé d'utiliser des techniques de reconnaissance optique de texte sur des images (OCR) pour retrouver les données. (Denis 2018) illustre cette question avec les données de localisation des pistes cyclables dans les villes.

### Des conventions pouvant être mal interprétées

Dans la manière d'attribuer des valeurs à des données, une administration adopte des conventions qui lui sont propres, quitte à ce que, vues de l'extérieur, elles paraissent un peu étranges.

Exemple : les étages de locaux dans les données du cadastre réservent des surprises. Une analyse de la distribution de cette variable<fnref n="79" /> montre un pic à ... 81 ! Y aurait-il tant d'immeubles méconnus de plus de 80 étages ? Non : il s'agit simplement d'une convention pour désigner l'étage -1, ce qui est le droit le plus strict du concepteur de la base de données. On peut imaginer que le champ était prévu pour un entier positif, et que pour éviter de tout réécrire, on a choisi des valeurs grandes et rarissimes pour coder les étages négatifs.

<footnote n="79">79 On verra plus loin qu'il est toujours instructif de regarder les distributions *effectives* des variables dans un fichier qu'on récupère.</footnote>
## Des mises à jour non effectuées

Il existe des situations dans lesquelles il n'y a eu aucune erreur lors de l'enregistrement de l'information, mais où, simplement, celle-ci n'a pas été mise à jour. Et si l'on y réfléchit, c'est même tout à fait normal.

Exemple : un établissement change de numéro de téléphone, ou d'adresse e-mail de contact. En pratique, rien n'assure que cette information soit prise en compte dans le SI<fnref n="80" /> : on ne peut pas demander à l'administration d'être sur le qui-vive pour faire des vérifications auprès de tous les établissements, en envoyant des questionnaires tous les jours.

Il en résulte inévitablement des décalages liés à ces problèmes de temporalités. Ils peuvent être dus à l'administration (qui ne peut pas tout vérifier tout le temps), mais aussi à l'usager.

Exemple fréquent : les personnes qui envoient leur feuille de soins avec beaucoup de retard. Tant qu'elle n'a pas été reçue, tout se passe comme si le soin n'avait jamais eu lieu, car elle n'existe pas dans le système d'information.

De façon générale, cette situation se présente fréquemment pour l'enregistrement des sorties d'un répertoire. Les mises à jour sont souvent asymétriques, les entrées étant toujours connues, notamment lorsqu'elles sont indispensables pour accéder à certains droits (comme exercer une activité), alors que l'absence d'information sur la sortie n'a pas de conséquence pour la personne.

## Les valeurs refuges, ou la gestion d'une information incomplète

Il peut arriver que l'entité administrative soit placée dans une situation où l'information dont elle dispose est incomplète, imprécise, voire absente. Et elle peut gérer cela de différentes manières, qui ne sont pas toujours très cadrées.

Exemple : une administration qui ne connaît pas la date de naissance d'une personne. En pratique, cela peut la conduire à saisir des valeurs hors du domaine : 00/00, 99/99, ou WW/WW. Elles représentent l'absence (ou imprécision) de l'information, mais souvent sans normalisation, et varient ainsi parfois d'une source à l'autre. On peut aussi se servir de valeurs qui appartiennent au domaine, mais cela complexifie leur repérage : par exemple mettre le 1er janvier (01/01) lorsqu'on ne connaît pas la date. Dans ce cas on ne sait pas distinguer cela d'une « vraie » date au 1er janvier.

## 4.d. Le temps de réception - qualification

Après le temps de préparation, qui nous a permis de mieux comprendre la source de données, de disposer de documentation et de métadonnées, on entre dans le vif du sujet, les données elles-mêmes : (Cerroni, Bella, Galie 2014) soulignent qu'il faut « évaluer » les données administratives issues de leur univers de naissance, avant toute transformation statistique<fnref n="81" />. Mais nous venons de voir à quel point la qualité des données administratives était difficile à cerner.

<footnote n="80">80 Sauf si de tels changements nécessitent une déclaration à l'administration.</footnote>

<footnote n="81">81 Attention, cela ne veut pas dire que les données ne sont pas transformées, qu'elles sont « brutes » : on a vu plus haut, avec (Gitelman 2013) ou (Denis, Goëta 2014), que c'était un oxymore. De toute façon on aura affaire à des données transformées, d'une façon ou d'une autre, mais *au sein de l'entité administrative*.</footnote>
On a donc un service administratif « fournisseur » qui transmet à un service statistique « récepteur »
un jeu de données, qui se présente techniquement sous forme d'un ou plusieurs fichiers. Selon les
cas, ce jeu de données a été construit par l'administration seule ou en collaboration entre le service
statistique. En pratique, la transmission de données de la part de l'entité administrative ne se résume
pas à un fichier : chaque envoi<fnref n="82" /> peut contenir plusieurs fichiers, et la livraison de l'ensemble des
données prévues peut se subdiviser en plusieurs envois.

Exemple : les déclarations administratives DSN et Pasrau sont transmises en plusieurs
livraisons : deux fois par mois pour la première<fnref n="83" />, ou quotidiennement pour la seconde, les
périodes de référence de ces déclarations étant mensuelles.

Dans la réception – qualification, on veut valider le bon déroulement technique de la phase 1 dans son ensemble, de la constitution du jeu de données à sa transmission, pour préparer les phases suivantes dans de bonnes conditions. Pour cela, on met en œuvre des mesures quantitatives pour qualifier les données. L’idéal est que celles-ci aient été définies au préalable, en s’appuyant sur la connaissance du processus administratif et l’expression du besoin statistique.

• Conformité de la livraison

On veut s'assurer que les fichiers transmis, dans leur ensemble, correspondent à ce qui est attendu<fnref n="84" />,
et en premier lieu sur un plan quantitatif. On peut chercher à valider la livraison de plusieurs
manières et notamment en s'intéressant à des indicateurs de volume des données :

○ le nombre de fichiers transmis (conformité à la convention, ou encore à une connaissance en extension d'une liste de fichiers attendus),

o le nombre d'enregistrements : il permet de donner une indication sur la conformité de la livraison mais aussi de vérifier des ordres de grandeur relativement au champ prévu. Par exemple, on est supposé recevoir des données sur 1,2 million de déclarants, on vérifie qu'à l'issue de tous les envois, on est proche de cette quantité.

En pratique, de nombreuses sources administratives sont en effet transmises sous forme de plusieurs
fichiers : il peut s'agir de fichiers correspondant à des unités administratives (une direction d'une
administration, une agence régionale) ou à un ensemble de traitements périodiques. Le nombre de
fichiers attendus, tel que communiqué au départ par l'administration, est ainsi une information
importante : on va vérifier que cela concorde avec le nombre de fichiers effectivement transmis.

Par exemple, si l'administration transmet un fichier par département, une livraison de 50
fichiers serait partielle. Il arrive aussi que l'administration indique directement le nombre de
fichiers attendus, voire, de façon bien plus précise, une liste de noms.

L'intérêt de ces premières vérifications très basiques réside dans leur rapidité de mise en œuvre. On
épargne ainsi un temps précieux : il n'est pas souhaitable de dérouler intégralement un processus
coûteux de chargement de données lorsque, par exemple, un tiers seulement des données a été
correctement transmis. L'objectif est d'être réactif et de retourner rapidement vers le fournisseur en
cas de problème dans la transmission des données (corruption d'un fichier pendant l'envoi) ou dans
la confection des fichiers par le fournisseur (un fichier a été tronqué au moment de sa création), afin

<footnote n="82">82 On retrouve cette notion d'envoi dans le cahier technique de la DSN.</footnote>

<footnote n="83">83 A partir de 2025.</footnote>

<footnote n="84">84 C'est là un problème tout à fait classique de définition de protocole d'échange.</footnote>
que ce dernier puisse procéder rapidement à une nouvelle livraison complémentaire le cas échéant. En outre, cette réactivité est vitale dans le cas où les données administratives sont l'input d'un processus statistique conjoncturel très contraint dans les délais (c'est le cas pour la DSN).

Lors de ce contrôle de conformité de livraison, on contrôlera également un certain nombre de *paradonnées* : on pense ici à des informations portant sur le bon déroulement du processus de transmission, d'accueil et de chargement des données, produites éventuellement par les services en charge de l'accueil des données.

## • Conformité du contenu : domaine

Pour chaque envoi, on va procéder à d'autres contrôles automatisés, consistant à :

* vérifier le format : dessin de fichiers, typage (alphanumérique, texte, entier, date, ...),

* vérifier, pour chaque *variable* jugée d'intérêt pour un usage statistique<sup>85</sup>, si le *domaine* indiqué dans la convention / documentation est bien respecté : appartenance à une liste de valeurs<sup>86</sup>, à un intervalle, respect d'une certaine structure de la chaîne de caractères<sup>87</sup>, ...

Tous ces contrôles sont donc réalisés automatiquement, les sources administratives représentant en général des volumes beaucoup plus conséquents que les enquêtes - parfois quelques millions d'individus / objets, contre quelques milliers. L'automatisation est indispensable.

Ainsi, le système d'accueil et de mise à disposition des données démographiques et sociales développé dans le cadre du programme Résil, utilise un outil générique d'accueil-réception-contrôle des données administratives nommé ARC (Lefebvre, Soulier, Tortosa 2023), permettant des traitements automatisés.

Avec de gros volumes, on ne peut en effet se payer le luxe d'un processus élaboré de vérification manuelle (*manual editing*) sur des micro-données, comme c'est le cas pour les enquêtes auprès des entreprises, où l'on affine la répartition entre contrôles automatiques et manuels (Hedlin 2003).

Un non-respect de ces règles de contrôle, dans des conditions définies par la convention, conduira à un échec du chargement des données. Suite à cela, le service statistique pourra donc être amené, en tant que de besoin, à demander à l'entité publique des correctifs, des explications, voire une deuxième livraison des données.

## • Plausibilité des distributions

On passe ici à une part plus subtile de la qualification, qui cette fois ne sera pas pleinement automatisable, et nécessitera un travail d'interprétation. En étudiant la distribution des valeurs prises par les différentes variables, on va regarder s'il ne se passe rien d'anormal. Notre sujet est donc à nouveau le domaine, et dans les exemples qui suivent on se limitera au cas où le domaine est une liste prédéfinie de valeurs.

<footnote n="85">85 Ce qui suppose de les avoir définies. On ne va donc pas contrôler toutes les données administratives, ce serait une perte de temps, mais uniquement celles susceptibles d'intéresser la statistique.</footnote>

<footnote n="86">86 On considère ici la modalité qui signifie « manquant » (par exemple, 9999) comme faisant partie du domaine.</footnote>

<footnote n="87">87 Par exemple, un NIR, ou une date, sont des successions de caractères organisées d'une manière précise. Voir à ce sujet (Dubrulle et al 2023) pour des exemples ou (Friedl 2006) pour une explication des « expressions régulières ».</footnote>
## Valeur non atteinte

On peut isoler un premier cas de figure qui ne requiert pas de connaissance métier. Supposons que le domaine d'une variable X soit {a, b, c, d}, et que dans le fichier transmis on ne trouve en pratique que a et d. Les valeurs b et c ne sont pas atteintes, et cela interroge, même si ce n'est pas la manifestation indubitable d'une erreur.

Exemple : la première transmission des données GMBI comportait uniquement des locaux dont la variable « Nature de l'occupation » prenait la valeur « Local occupé ». L'absence d'autres valeurs a montré une erreur sur la sélection des données transmises.

## Pics de distribution

Il peut arriver que des valeurs du domaine soient non pas absentes, mais que leur fréquence observée soit excessivement haute.

La date de naissance, déjà évoquée, est un exemple évident : on constate que certaines dates sont plus fréquentes qu'attendues, comme le 01/01, ou le 31/12. L'année 00 est aussi un pic. Tout cela traduit probablement une méconnaissance de la véritable date par l'administration, ou même par l'administré, comme on l'a vu. Ce n'est donc pas vraiment une erreur, mais une information utile à conserver pour les usages ultérieurs.

## Vraisemblance des distributions

Plus difficile, et encore moins automatisable, on va vérifier la vraisemblance des distributions des variables « intéressantes ». Dans un contexte de primo-acquisition, il n'est pas toujours simple d'avoir des points de comparaison ou des *a priori* solides sur la distribution des informations. Mais on peut par exemple s'attendre à disposer de données dans tous les départements, à avoir une distribution par âge ou par sexe relativement proche de celles de la population totale lorsque la source couvre toute la population. Il est donc toujours utile de consulter les distributions de variables connues pour s'assurer qu'elles ne sont pas aberrantes.

On verra que les contrôles sur les distributions peuvent être utilisés bien plus tard dans le processus, en phase 3, pour évaluer la nécessité de redressements.

## Le champ : sur-couverture et sous-couverture

S'il est complexe de s'assurer que le champ prévu (on parle ici du champ de la source, tel qu'il est défini par l'administration) est bien couvert par le ou les fichiers transmis, on peut au moins vérifier qu'il n'y a pas de problème manifeste.

Cela commence par de simples contrôles sur les volumes (nombre d'objets), en s'intéressant notamment aux évolutions d'une période sur l'autre : si la source n'est pas nouvelle et qu'on dispose de données sur des périodes antérieures, on peut alors comparer les agrégats entre les livraisons, ce qui permet de détecter d'éventuels problèmes ou changements dans les données.
Exemple : lors du passage à GMBI, l'administration fiscale a décidé d'immatriculer toutes les dépendances qui étaient par le passé rattachées au local dont elles dépendaient. Le nombre de locaux immatriculés avait donc explosé entre deux années de livraison. Cette augmentation était « normale », elle reflétait simplement un artefact de gestion, mais a conduit à l'ajout d'un filtre afin de retrouver la population d'intérêt statistique.

On peut aussi se rendre compte qu'une part du champ théorique est absente du fichier, simplement en observant que des types d'objets sont manquants, ou en quantité anormalement faible. On parle alors de sous-couverture du champ. La sous-couverture est toujours difficile à repérer en pratique, car « on ne sait pas ce qu'on ne sait pas ».

Exemple : il est arrivé que dans des données relatives à des équipements (Helfenstein 2022), on trouve des départements dans lesquels il n'existe aucune station d'essence, ce qui révèle une invraisemblance.

A l'inverse, il arrive aussi que le fichier comporte des unités hors du champ théorique administratif : c'est la *sur-couverture*. De façon symétrique au cas précédent, on peut le détecter avec des types d'unités non prévus.

La présence de *doublons* est un cas très particulier de sur-couverture : on va au-delà du champ car on compte la même unité deux fois. Ainsi, dans un système d'information où une opération déclenche une action, on peut rencontrer des comportements conduisant à reproduire deux fois la même opération (pour déclencher l'action), ce qui n'a pas d'importance dans le système d'origine mais crée des doublons, et pose problème pour les usages statistiques ultérieurs.

## • Outiller la qualification

L'ensemble des traitements à réaliser sur des données (vérification des formats, contrôles inter-variables, contrôles de distribution, ...) est synthétisé dans la notion de *data profiling*, ou profilage, bien décrite dans (Olson 2003). Les techniques de profilage, mais aussi les fonctions de standardisation et de dédoublonnage, sont mises en œuvre dans des *data quality tools* (Van Dromme et al 2007, Boydens 2021), disponibles dans des outils du marché ou en open source. Comme l'indiquent (Boydens, Hamiti, Van Eeckhout 2021), ces outils relèvent d'une approche curative de la qualité des données<sup>88</sup>.

On soulignera néanmoins que pour déterminer la qualité effective des fichiers administratifs reçus, le statisticien travaille un peu « sans filet » car il n'a pas grand-chose avec quoi comparer. Intuitivement, cette qualité effective mixerait la conformité des valeurs, la plausibilité de la distribution (pour chaque variable), la plausibilité « macro » (taux de non déclaration, valeurs manquantes), l'absence (ou le faible taux) de doublons, voire la vraisemblance des distributions croisées.

La comparaison de données est fréquente dans le monde statistique, mais à cette étape du processus, on se place encore totalement dans l'univers administratif. L'évaluation de la qualité mobilisant des données individuelles ou agrégées issues d'une autre source sera évoquée dans la phase ultérieure.

<footnote n="88"><sup>88</sup> Elle est complémentaire d'une approche préventive de la qualité, que (Boydens et al 2021) développent dans leur article : c'est une approche tout à fait intéressante si on se place du point de vue de l'administration, mais qui est hors du champ du présent papier.</footnote>
• Commentaires

Dans ce travail de qualification, il faut aussi anticiper que tout est indéfiniment améliorable, et éviter, par conséquent, l’effet « tonneau des Danaïdes ». C’est pourquoi il importe de bien expliciter au départ le besoin statistique, i.e. les attentes en matière de qualité des futures statistiques envisagées : quelle granularité de diffusion souhaitée ? Quelle attente des utilisateurs en matière de fraîcheur des données ? Que prévoit-on en matière d’unités statistiques et de variables d’intérêt ?

Ainsi, et cela peut paraître contre-intuitif, qualifier le jeu de données transmises ne consistera pas à caractériser l’ensemble de ses anomalies, invraisemblances, erreurs, mais plutôt à s’assurer d’un niveau de qualité suffisant *pour répondre aux objectifs des produits statistiques* que l’on imagine. Ainsi, dans l’exemple des dates de construction évoqué plus haut (beaucoup d’années multiples de 10), il existe de nombreux usages pour lesquels cette imprécision n’aura aucune importance.

Ce n’est qu’après avoir défini ces attentes qu’on pourra les décliner, autant que possible, en indicateurs mesurables, en cibles de qualité à atteindre, ce qui permet de se donner un cadre, d’autant plus utile qu’il sera réutilisable en cas d’usages répétés, cadre qu’on déclinera en outils.

4.e. La boucle de rétroaction avec l’entité administrative

Dans la mesure où les données administratives présentent toujours des défauts, d'une manière ou
d'une autre, le travail de qualification va le plus souvent révéler un certain nombre d'anomalies.
Mais contrairement aux enquêtes, on ne peut pas vérifier auprès de l'unité (individu, entreprise)
concernée : la seule rétroaction possible a lieu avec l'entité publique, et se fait non pas au niveau de
chaque individu (i.e. chaque enregistrement), mais à un niveau plus macro, celui de la livraison, ou
du fichier. Cela change fondamentalement la nature de la vérification.

Ce qu'on nomme ici « boucle de rétroaction », c'est tout le processus d'échange entre entité administrative et service statistique, qui va éventuellement conduire à de nouveaux envois (de données, ou de métadonnées) ou à une amélioration de la qualité de la source administrative pour les années futures (Renne, 2018).

• *Un préalable : qualifier les données administratives dans leur univers propre*

Dans tout ce qu’on vient de voir, la qualification s’appuie encore sur les objets et variables tels qu’ils sont définis et connus par le fournisseur. On se situe entièrement dans un monde administratif et non statistique, et ce n’est pas un détail. Car une fois les données transformées pour des besoins statistiques (ce qu’on verra avec la phase 2), elles deviendront illisibles pour l’entité publique et la discussion deviendra impossible<fnref n="89" />. Adopter le langage de l’autre entité (*contribuable* plutôt qu’individu, *foyer fiscal* plutôt que ménage…) peut sembler limitant voire artificiel pour les statisticiens, mais l’expérience montre que c’est une condition nécessaire pour échanger avec elle de manière constructive<fnref n="90" />. Il s’agit d’un point-clé.

Et pour cela, c'est au monde statistique de s'adapter au monde administratif, non l'inverse.

<footnote n="89">89 C'est le sujet de la continuité sémantique entre émetteur et récepteur des données, ce qui rejoint le sujet « data friction » (quand il y a discontinuité). On retrouve aussi la notion de distance entre producteur et utilisateur, évoquée plus haut à propos de (Borgman, Groth 2025).</footnote>

<footnote n="90">90 Ce n'est pas uniquement une question de terminologie, c'est aussi la sémantique portée par le langage.</footnote>
Une telle démarche permet :

* de mieux distinguer les origines des problèmes dans les données (changement de qualité des données, problèmes de transmission, problèmes de traitement) ;

* d'échanger avec le fournisseur en utilisant un vocabulaire, des concepts, objets, variables communs. Or cette discussion est indispensable pour comprendre la signification des éventuelles bizarreries dans les données transmises.

En effet, il est fréquent que cette étape de qualification comporte son lot de surprises, d'a priori formulés sur les données qui ne sont pas confirmés. Comme on l'a vu sur plusieurs exemples, la production de statistiques descriptives simples (distributions, fréquences, totaux etc.) permet d'aller plus loin dans la compréhension des métadonnées, et suscite des questions adressées au fournisseur.

C'est précieux : lors de l'exploitation de données administratives, on dispose en réalité de peu d'occasions de rétroagir sur les données. La phase 1, et en particulier la qualification, est « le » moment où l'on peut revenir vers l'administration. Cela permet aussi d'engager des échanges constructifs pour faire évoluer à plus long terme les processus administratifs et les données livrées.

* Une boucle de rétroaction « macro »

Le premier chapitre (en 1.c) a montré l'importance de l'activité de vérification dans le processus d'enquête, en particulier avec le concept de data editing. On avait bien affaire à une boucle de rétroaction, associée à des contrôles automatisés préalables, qui avaient détecté des anomalies. Mais celle-ci conduisait à des modifications de micro-données, donc au niveau de l'unité statistique : à travers le travail de l'enquêteur, qui échange avec l'enquêté (boucle de rétroaction immédiate, « en direct »), ou via l'intervention du gestionnaire d'enquête, qui contacte a posteriori l'unité enquêtée, l'itération étant donc différée (manual editing).

L'anomalie, utilisée pour la boucle de rétroaction était par exemple : pour telle entreprise, la valeur de la variable Activité principale, 47.21A, est hors domaine (en l'occurrence celui de la NAF, nomenclature d'activité française). Et l'on vérifiera pourquoi auprès de l'entreprise enquêtée, pour arriver à constater, par exemple, une erreur de saisie. Le déclencheur de la rétroaction porte ainsi sur une micro-donnée, et son résultat aussi.

Dans le cas des données administratives, l'étape de qualification va permettre de la même manière de détecter des situations surprenantes, anormales, d'avoir un regard critique, mais le déclencheur de la boucle de rétroaction<fnref n="91" /> et son résultat se situeront cette fois à un niveau macro.

L'anomalie sera cette fois, par exemple : dans 5 % des cas, les entreprises du fichier ont une activité principale 47.21A. On s'en ouvrira auprès de l'administration fournisseuse. Et on constatera peut-être que l'administration a délibérément introduit un nouveau code d'activité, pour ses propres besoins. Il n'y a donc aucun retour vers l'unité (ici l'entreprise), et le résultat de la rétroaction sera, par exemple, une modification de la documentation.

Les anomalies macro sont de plusieurs types (cf 4.d) : non-conformités fréquentes au domaine, domaine non couvert, distribution des valeurs non plausible, champ non couvert (pour des raisons de volume ou de types d'objet), unités hors-champ obtenues, temporalités non respectées.

<footnote n="91">91 Rendue possible par l'adoption du langage de l'entité publique.</footnote>
La rétroaction, donc la discussion avec l'administration, va ainsi porter sur les explications de ces anomalies. On peut les diviser en trois catégories :

1. Incompréhensions de la part du service statistique,

2. Erreur ou insuffisance dans les métadonnées transmises (et la documentation),

3. Erreur ou insuffisance dans les données transmises.

Le premier cas se règle par des explications, et c'est aux statisticiens d'améliorer leur propre documentation. Ainsi, l'anomalie « étage 81 » n'était pas un problème de données transmises : il manquait simplement l'information selon laquelle le code 81 signifiait l'étage -1.

Dans le second cas, on va constater qu'une valeur non prévue dans le domaine apparaît (par exemple un code activité), ou que le champ est un peu plus large que ce qui avait été expliqué. La boucle de rétroaction va donc se matérialiser par l'envoi de nouvelles versions de documentation (parfois de simples mises à jour), sans nouvelle transmission de données. On est assez proche du premier cas de figure.

Reste le 3e cas : la documentation n'est pas en cause, et il y a effectivement un problème avec les données livrées. Ainsi, le fait que le champ soit incomplet peut montrer que la livraison n'est en réalité pas achevée (il manque des départements) ; la présence de doublons peut mettre en évidence des incohérences dans le système d'information et conduire l'entité publique à un travail en profondeur ; idem pour une distribution de valeurs anormales dans un domaine. Cela peut engendrer des envois complémentaires, ou qui « annulent et remplacent » des envois déjà réalisés.

Notons simplement qu'il n'est pas toujours possible d'intégrer toutes les modifications nécessaires dans le délai souhaité<fnref n="92" />.

On constate ainsi que les modifications possibles ne vont pas porter sur des données individuelles, et qu'elles auront une dimension plus systémique, vertueuse, car conduisant indirectement à améliorer les données administratives, ce qui sera très utile en cas d'usages répétés. On trouvera ainsi dans (Boydens 1999) une démarche d'utilisation « positive » des anomalies dans les données de sécurité sociale belge, généralisée depuis (Boydens 2018). Le terme utilisé pour désigner la boucle de rétroaction est celui de back tracking, issu du « data tracking » de Redman (1997), et il s'inscrit dans une logique d'amélioration continue de la qualité des données de l'administration, légèrement différente de notre cadre d'analyse, centré sur l'usage statistique.

Pour finir sur cette boucle de rétroaction, soulignons qu'elle peut avoir lieu à plusieurs reprises : la qualification des données est en réalité une opération progressive, itérative, qui se déroule tout au long du processus de découverte et d'acquisition des données administratives, et même après.

### 4.f.Le cas des usages répétés et multiples

* Qualifier une source dans le cas d'un usage répété

Si la qualification est indispensable lors de la première acquisition d'une source, elle l'est aussi dans un contexte d'acquisition répétée. Le temps de la découverte est révolu, la source est connue des statisticiens qui l'utilisent. Une bonne documentation des premiers travaux est bien sûr indispensable et contribue à la transmission de la connaissance.

<footnote n="92">92 Dans le contexte d'une acquisition répétée, la détection d'anomalies peut conduire à modifier la livraison ultérieurement, et nécessiter des traitements correctifs de niveau statistique pour la période courante.</footnote>
Ainsi, dans le cas d'une périodicité annuelle, le processus d'acquisition la 2ᵉ année devrait être plus simple : l'acculturation à l'univers administratif ayant eu lieu, les étapes de préparation et de réception-qualification ont été en principe rodées, documentées, outillées. Certes, on devra toujours contrôler le processus d'extraction et de transmission des données, effectuer les vérifications de conformité et plausibilité, les boucles de rétroaction, mais l'investissement initial aura été fait.

Cependant, de nouvelles questions vont apparaître, relatives aux évolutions : y a-t-il eu des changements législatifs ? Des modifications de nomenclatures, de concepts ? Un nouveau logiciel de gestion, de nouveaux formats ?

Répondre à ces interrogations implique des travaux plus approfondis : tout d'abord une **veille législative**, enjeu essentiel ; également des échanges réguliers avec le fournisseur, une attention aux métadonnées fournies avec la source, mais aussi, et c'est un point qu'on oublie souvent, une attention particulière aux évolutions des distributions des variables importantes. La mobilisation de plusieurs occurrences temporelles d'un même jeu de données permettra d'introduire des contrôles de cohérence temporelle dans la qualification, ce qui enrichira ... et complexifiera le processus.

L'exigence de satisfaction des critères de qualité peut évoluer avec la maturité de l'exploitation statistique : lors d'une primo-acquisition, l'évaluation fera le bilan de la qualité de la source, sa capacité à répondre au besoin à court terme, mais pourra aussi dessiner les évolutions nécessaires pour répondre à l'ensemble des besoins dans un délai plus long. La qualité n'est pas invariable dans le temps, et il faut pouvoir le repérer : le taux de couverture d'une source peut s'améliorer ; le délai d'obtention d'une source peut se réduire ; ou a contrario, une source dont la finalité est de disparaître va voir sa qualité se dégrader.

Exemple : la disparition annoncée de la taxe d'habitation (TH) s'est traduite par une baisse de couverture du lien entre les foyers fiscaux et leur logement. Il y avait 37 millions de foyers rattachés à un logement en 2022, 27 millions en 2023 et un peu moins de 7 millions en 2024. Des mesures palliatives ont donc été mises en place pour adapter le système d'information. La dégradation de la qualité de la localisation des individus avait ainsi été anticipée pour que ces millésimes soient exploitables, avec l'utilisation de la source GMBI.

Le caractère répété dans le temps de la qualification a une autre conséquence : il faut s'assurer de la traçabilité des traitements, de leur reproductibilité (Pérignon et al 2019). Cela renvoie à la qualité des développements (lisibilité, versionnage), mais aussi à l'importance accrue de la documentation.

Enfin, dans la mesure où des modifications sont inévitables (changements législatifs, par exemple), il faut veiller à ce qu'on n'aboutisse pas à un processus automatisé (de type pipeline) trop rigide, trop difficile à faire évoluer. Il doit être suffisamment souple pour qu'on puisse en modifier des éléments : nouvelles variables, nouveaux domaines, nouveaux indicateurs de qualité, etc. Ce qui est en jeu ici, c'est la mise en place d'une autre boucle de rétroaction, cette fois intertemporelle, qui va porter non pas sur le processus de livraison, mais sur le processus d'acquisition lui-même.

* Qualifier une source pour plusieurs usages ?

Si la qualité est liée à l'usage, alors qualifier une source pour plusieurs usages semble contradictoire : certains objectifs peuvent s'avérer antinomiques (arbitrage classique entre fraîcheur et complétude des données), ou la prise en compte de différents usages peut amener à des analyses trop poussées. Cependant, lorsqu'une source est utilisée fréquemment dans différents processus de
production, il peut être intéressant de mutualiser une partie des travaux de qualification, et surtout d'en partager les résultats (par exemple, les collaborations entre Drees et Insee sur la source Pasrau) : partager les nouvelles connaissances, la compréhension de la source, ou automatiser la production d'indicateurs quantitatifs. Cette question se pose aussi dans un contexte de centralisation de l'accueil des données, pour différents utilisateurs.

La mutualisation peut prendre différentes formes, comme des échanges dans un groupe de travail ou le partage des travaux de qualification sur des domaines d'intérêt différents. Lorsqu'un nouvel usage potentiel apparaît, il peut être nécessaire d'effectuer des travaux complémentaires sur une source déjà connue et qualifiée.

Exemple : les données du cadastre déjà utilisées pour la localisation des locaux d'habitation ont fait l'objet de nouvelles analyses lorsqu'elles ont été mobilisées dans le projet Fidelimmo (André et Meslin, 2022). En effet, le projet s'intéressait à la variable de surface, qui, n'étant pas utile pour les usages précédents, n'avait pas été qualifiée.

### 4.g. Résultat de la phase d'acquisition et passage à la phase suivante

La phase d'acquisition s'avère particulièrement inconfortable pour les statisticiens, car ne faisant pas appel à leurs compétences traditionnelles, à leur cursus académique. Elle comporte une large part d'immersion dans un métier qui leur est étranger, avec la découverte de tout un lexique, d'une sémantique, de processus opérationnels, et d'objectifs qui ne sont pas particulièrement connus.

Elle comporte une part de logistique, en quelque sorte, avec l'organisation des mécanismes de livraison, leur contrôle, leur suivi, et l'élaboration de contrats pour mieux assurer leur bon fonctionnement. Elle inclut également une dimension de négociation, de mise au point, d'itérations, se matérialisant par des boucles de rétroaction.

Le résultat de cette phase peut être caractérisé ainsi :

* des fichiers de données, par essence figés

* des métadonnées, une documentation permettant d'en comprendre le sens, facilitant leur usage : définition des objets, domaines, champs, variables, temporalités

* une convention de transmission des données<sup>93</sup>

* une analyse de la qualité des fichiers de données reçus : en effet, on n'a pas nécessairement des fichiers d'excellente qualité, mais des fichiers « dont on connaît les défauts » (incomplétude, non conformité, ...)

Tout le travail effectué lors de cette phase s'exprime **dans le langage de l'administration**, avec ses objets, variables, ... et **aucune modification de données** ne peut être faite par l'équipe statistique.

Une précision s'impose ici au sujet des boucles de rétroaction avec l'administration : il peut tout à fait arriver, en pratique, qu'il n'y ait aucune rétroaction, i.e. que l'entité administrative ne renvoie ni nouveaux fichiers, ni nouvelles documentations, ni explications, par exemple pour des raisons de manque de temps. On voit alors tout l'intérêt de la qualification : elle aura permis de pointer les défauts de la source, et l'on saura que les phases suivantes devront tenir compte de ces défauts, voire les « rattraper ». Mais pour cela, il faut d'abord passer dans un univers adapté au travail statistique : c'est tout l'objet de la phase 2, phase de transformation.

<footnote n="93">93 C'est un *output* dans le cas d'une primo-acquisition. Pour les suivantes, elle existe déjà, mais on peut adjoindre des avenants.</footnote>
<figure><img src="image_9.png" /><figcaption>**Figure 4 - Phase 1 - Acquisition de données administratives**</figcaption></figure>
## 5. La phase de transformation : passer du monde administratif au monde statistique

Le fait même que les données issues de la phase 1 relèvent de l'univers administratif constitue une limite. On ne peut les utiliser telles quelles : il faut les transformer pour qu'elles s'écrivent désormais dans un langage, un cadre approprié pour les statisticiens. On va donc devoir, pour reprendre la terminologie de (Courmont 2021), après les avoir « détachés » de leur univers d'origine, les « réattacher » à l'univers statistique. C'est un changement de référentiel, une projection de l'univers administratif sur des dimensions statistiques choisies.

L'objectif de la phase 2, dite de transformation, c'est d'obtenir un ensemble de données adaptées à un usage statistique, dans le sens où ces données reflètent les unités et les variables identifiées lors de l'expression des besoins.

Cette transformation consiste en une mise en œuvre concrète d'une succession d'opérations sur les fichiers, souvent conçues très en amont<sup>94</sup>. Les données obtenues à l'issue de cette phase auront ainsi un « statut » similaire aux données issues d'enquêtes, ce qui sera essentiel pour la phase suivante.

Dans cette partie, on va commencer par détailler les différentes opérations que l'on peut trouver dans une transformation. On se posera ensuite la question de la réplicabilité de la chaîne ainsi produite, puis on verra qu'un travail de qualification (avec boucle de rétroaction associée) est toujours nécessaire, mais qu'il n'est pas de même nature.

### 5.a. Principes

Pour passer de l'administratif au statistique, il faut passer d'une grille d'analyse à l'autre : en particulier, on veut un résultat de transformation :

* partant d'une vision claire des objets, champs, variables, domaines, temporalités des fichiers transmis, selon la sémantique administrative ;

* permettant d'appréhender convenablement les unités statistiques, champs, variables, catégories, temporalités choisis pour l'usage statistique. On va donc systématiquement se référer à ces différentes dimensions, en soulignant simplement que la temporalité a été en bonne partie réglée lors de la phase 1.

Il faut donc concevoir ce processus de transformation, en ayant en tête quelques points de vigilance :

1. Les données ainsi produites pourront être utiles à d'autres services statistiques, à d'autres usages. Si c'est le cas, on devra tenir compte de ces enjeux de mutualisation dès le départ (c'est une question importante pour la DSN, par exemple), et prendre en compte les différents usages identifiés ;

2. Selon les choix opérés, la transformation peut conduire à rendre impossibles d'autres usages. En effet, le fait même qu'un tel processus conduise à supprimer de l'information (exclusion d'enregistrements), ou à agréger des informations (unités statistiques fusionnant des

<footnote n="94">94 Ce qui peut d'ailleurs impacter la conception de la phase 1.</footnote>
enregistrements), implique une perte d'informations dans les données post-transformation, éventuellement préjudiciable à d'autres utilisations.

3. La transformation n'est pas juste un programme, c'est un objet d'intérêt en soi qui doit être lisible, qu'il faut pouvoir faire évoluer, dont on doit assurer la maintenance.

## 5.b. Les principales opérations de la phase de transformation

Le processus sera décomposé en étapes, qui vont transformer les données dans leurs différentes caractéristiques : objet, champ, attribut (ou concept), domaine et parfois également valeur. Elles seront le plus souvent déterministes, mais pas toujours réversibles. (Cotton, Haag 2023) proposent par exemple un découpage en six étapes<fnref n="95" />.

* De l'objet administratif à l'unité statistique

Restructurer les données par unité statistique

Les données administratives sont relatives aux objets d'intérêt pour l'administration, en lien avec la finalité d'un processus. Ces objets peuvent être complexes, il y a souvent des liens entre différents objets (des individus, des établissements, des évènements ...).

La statistique publique s'intéresse souvent à des données portant sur des **individus**, des **ménages**, des **entreprises**, des **unités légales** ou des **établissements**. Elle utilise également des données évènementielles, le plus souvent en lien très fort avec ces unités « habituelles » (naissances, décès, créations, cessations, restructurations etc.).

Le passage d'objets administratifs aux unités statistiques est souvent complexe et requiert une bonne connaissance des données. A partir d'une même source de données, on peut construire différents jeux de données, fondés sur des unités statistiques différentes.

Les données de la DSN, que l'on peut définir comme des *lignes de fiches de paie*, permettent de construire des données *par poste de travail*, mais aussi *par salarié*.

Il arrive qu'on doive utiliser plusieurs objets, et liens entre eux, pour aboutir à une unité statistique.

Dans les données fiscales, les liens entre un logement et ses occupants sont utilisés pour définir un ménage. Autre exemple : en statistique d'entreprises, les liens capitalistiques entre unités légales vont permettre de créer des groupes de sociétés.

Le passage des objets aux unités n'est pas nécessairement bijectif : il peut y avoir scission ou à l'inverse fusion d'objets, ou encore sélection de certains liens uniquement. Dans le cas où une unité statistique est constituée de plusieurs objets, cela conduit, de fait, à une sorte de dédoublonnage qui n'est pas « technique », mais lié aux concepts.

<footnote n="95">95 A savoir : filtrage des enregistrements utiles, renommage, restructuration en unités statistiques, recodage, calcul de variables dérivées, pseudonymisation.</footnote>
Exemple : l'utilisation des données du DRM<fnref n="96" /> par la Drees vise à suivre dans le temps les revenus de certains individus. Cette source comporte par exemple des lignes de revenus ou prestations, versées par un payeur à un bénéficiaire. La Drees est intéressée par le caractère pérenne ou nouveau de ces liens payeur-bénéficiaire, afin d'avoir un suivi temporel des revenus ou prestations. Or en pratique, certaines administrations créent pour chaque versement une nouvelle relation, i.e. un nouvel objet « prestation », plutôt que modifier un objet existant. Il y a donc tout un travail pour distinguer les enregistrements relevant de la même unité statistique, i.e. du même couple (bénéficiaire, payeur) donnant lieu à versement.

Le fait que l'unité statistique soit très différente de l'objet administratif peut avoir des conséquences sur l'identification de ces unités.

Dans le cas du cadastre, on trouve des données relatives aux transactions. Dans certaines situations, l'objet administratif est le local concerné par la transaction, auquel seront associés les noms des individus participant à la transaction, mais ceux-ci ne sont pas toujours décrits de façon suffisamment précise pour qu'on puisse bien les identifier. Ceci rend difficile le passage à l'unité statistique « individu » (André, Meslin 2022).

## Pseudonymiser l'unité statistique

Passer de l'objet à l'unité statistique, c'est aussi faire en sorte que cette dernière ait les bonnes propriétés pour un usage statistique : dans le cas des données sur les personnes notamment, une propriété visée est d'empêcher l'accès à des informations individuelles, i.e. la possibilité de faire le lien entre une personne et les données à son sujet. Il existe de nombreuses méthodes visant ainsi à préserver la confidentialité des données (Matthews, Harel 2011). On parle désormais de *Privacy-Enhancing Technologies* (PET), qui abordent la question dans toute sa généralité, avec des développements récents dans le domaine des statistiques officielles (Ricciato 2024).

La pseudonymisation est l'une des approches possibles. Elle consiste à enlever, dans les fichiers et pour chaque individu, ses traits d'identité et identifiants directs. Il faut bien la distinguer de l'anonymisation (Esayas 2015). Pour la Commission nationale informatique et libertés (CNIL), « L'anonymisation est un traitement qui consiste à utiliser un ensemble de techniques de manière à rendre impossible, en pratique, toute identification de la personne par quelque moyen que ce soit et de manière irréversible. »

En d'autres termes, l'anonymisation est beaucoup plus exigeante, et peut conduire à enlever délibérément une grande quantité d'informations.

La pseudonymisation, en revanche, est une opération « relativement » simple (au moins conceptuellement), et qui peut s'effectuer automatiquement<fnref n="97" /> : elle a donc toute sa place dans la succession d'opérations de la phase 2 de transformation. Dans le système statistique public français, le service rendu par le CSNS, ou Code statistique non signifiant (Benichou, Espinasse, Gilles 2023), est une façon de la mettre en œuvre.

<footnote n="96">96 DRM = Dispositif de Revenus Mensuels. Voir https://net-entreprises.custhelp.com/app/answers/detail/a_id/2362/~/donn%C3%A9s-dsn-et-pasrau-par-le-dispositif-de-ressources-mensuelles-%28drm%29. Pour un développement sur son utilisation dans la sphère sociale, voir (Puche 2022).</footnote>

<footnote n="97">97 Voir aussi (Girard-Chanudet 2023), qui apporte un éclairage tout à fait original sur l'automatisation de la pseudonymisation, dans un cadre totalement différent de celui de la statistique publique.</footnote>
• Du champ administratif au champ statistique

Lorsqu'on évoque le champ, il convient de bien préciser de quel champ on parle : il peut s'agir du champ des données administratives elles-mêmes, ou du champ statistique d'intérêt. Dans la phase de transformation, on effectue le passage de l'un à l'autre, sachant que le champ administratif est imposé par la source. Ainsi, rien ne garantit qu'on pourra couvrir le champ statistique souhaité. Dans la transformation, on va donc surtout veiller à éliminer les enregistrements qui ne relèvent pas du champ d'intérêt. En d'autres termes, dans cette phase, on va traiter la question de la *sur-couverture* et non celle de la *sous-couverture*<fnref n="98" /> : il n'est pas question de chercher à compléter le champ (ce sera un sujet de la phase 3).

Le dédoublonnage

Traiter la sur-couverture, c'est en premier lieu éliminer les **doublons** : idéalement, les doublons dans l'univers administratif ont dû être détectés en phase 1. Mais il est possible qu'ils n'aient pas été pris en compte par l'entité administrative dans la boucle de rétroaction, voire qu'il n'y ait pas eu de rétroaction du tout. Il s'agit d'un dédoublonnage « technique », visant à détecter des doublons d'objets administratifs, sur la base de leurs traits d'identité, et pour lequel il existe des outils et méthodes : on en trouvera une large revue dans (Malherbe 2023).

Il est très différent du dédoublonnage « conceptuel » qui peut avoir lieu, postérieurement, dans le passage objets – unités (par exemple, plusieurs liasses donnent une seule entreprise).

Le filtrage du champ statistique

Il s'agit aussi, en s'appuyant sur les catégories disponibles, d'éliminer du champ ce qui n'est pas pertinent pour le champ statistique visé.

Ainsi, on pourra décider d'exclure du champ des unités de certains secteurs d'activité économiques (secteurs non marchands, par exemple), ou des individus présents dans les données administratives mais n'appartenant pas à la population résidente, ou encore des locaux qui ne sont pas des logements, ... tout cela en fonction de l'usage visé.

Autre exemple : chaque mois la CAF envoie à l'Insee un fichier des personnes qui ont eu une allocation au cours des dernières années. Mais on veut se limiter à ceux qui ont réellement reçu une prestation légale le mois considéré : il faut donc filtrer le fichier sur une modalité particulière de la variable qui définit leur « noyau dur ».

Les filtres sont définis à partir de variables disponibles dans la source. Ils sont calculés sur les enregistrements présents dans les données, à partir d'informations existantes et peuvent conduire à sélectionner des objets, des unités ou seulement certaines composantes des objets ou unités.

Par exemple, les données fiscales comportent des informations sur des locaux d'habitation. Ce concept ne correspond pas exactement à la notion de logement. Il faut donc faire des choix pour passer d'un concept à l'autre. Dans ce cas précis, on pourra exclure les parkings, les dépendances ... qui sont des locaux d'habitation mais ne sont pas des logements.

<footnote n="98">98 Sur ces questions, voir (Wallgren, Wallgren 2016).</footnote>
Les filtres peuvent être plus ou moins complexes. Il est essentiel de bien expliciter les filtres et leur position relative dans le processus : l'enchaînement des traitements n'est pas neutre. Soulignons ici qu'une telle description fait l'hypothèse a priori de l'exactitude de la variable de filtre.

La qualité des variables de filtrage doit être très soigneusement évaluée : les erreurs sur le champ peuvent ultérieurement avoir un très gros impact sur la qualité des statistiques, et c'est d'ailleurs une explication fréquente de problèmes rencontrés. Les évolutions de ces variables doivent également faire l'objet d'un suivi rigoureux : la connaissance du processus administratif et sa législation, de modifications dans la mise en œuvre.

On peut citer une évolution administrative récente : l'inscription obligatoire à France Travail « des personnes qui demandent le bénéfice du RSA, des jeunes accompagnés par les missions locales et des personnes qui, en situation de handicap, sollicitent un accompagnement spécialisé ». Celle-ci modifie la définition du champ des demandeurs d'emploi et a donc un impact majeur sur les statistiques correspondantes, conduisant mécaniquement à une augmentation significative difficilement interprétable. La situation est à ce point problématique qu'un groupe de travail (sous l'égide du Cnis) y a été dédié. Il a proposé de nouvelles catégories, « en miroir » des nouvelles catégories administratives : les personnes inscrites « en parcours social » (catégorie F) et les demandeurs du RSA en instance d'orientation (catégorie G). Disposant de ces catégories il devient envisageable de reconstruire le champ de façon appropriée, mais tout un suivi est nécessaire<fnref n="99" />.

L'évolution du champ en lien avec une décision administrative peut avoir été repérée en amont, comme dans l'exemple précédent, ce qui permet d'en anticiper les conséquences. Il arrive aussi, symétriquement, que ce soient de fortes évolutions de volume qui permettent de détecter la modification du champ de la source, et donc la mesure administrative sous-jacente.

Exemple : la mise en œuvre du prélèvement à la source a entraîné un changement dans la population présente dans les sources fiscales. Ce changement a été détecté, lorsqu'on a observé ses conséquences sur le nombre d'individus présents dans les bases de sondage construites par l'Insee. La complexité des traitements effectués sur les données fiscales a rendu délicate l'analyse des évolutions des données en volume.

Autre exemple : on observe des bonds spectaculaires dans les nombres de licences sportives, qui sont simplement dus à des changements dans les pratiques de gestion des fédérations. Ainsi, on va subordonner la pratique de telle activité non compétitive à la prise d'une licence. La fédération française de canoë-kayak a ainsi quasiment doublé son nombre de licences de 2016 à 2019, et on peut l'expliquer par de tels changements (Vicard 2023).

## Des variables administratives aux variables statistiques

Il arrive souvent que les variables disponibles dans la source administrative soient différentes de ce qui est souhaité, mais qu'il soit possible d'approximer les variables d'intérêt à partir d'elles. Il y a donc en premier lieu tout un travail sur le sens des données (administratives et statistiques), avant d'arriver opérationnellement à une formule de calcul et de nommer les choses.

<footnote n="99">99 Cf. la synthèse du rapport du GT du Cnis "Conséquences de la mise en place de la loi « Pour le plein emploi » sur les statistiques de demandeurs d'emploi" : https://www.cnis.fr/wp-content/uploads/2024/09/rapport-cnis-166.pdf</footnote>