Industrialiser l’intégration des données administratives dans nos systèmes d’information est essentiel, compte tenu de l‘importance croissante de ce type de données dans nos processus de production statistique (Cotton et Haag, 2023). Pour relever ce défi, la solution adoptée par l’Insee est une structure d’accueil des sources offerte aux producteurs de statistiques, reposant sur un outil générique moderne et mutualisé.

Au début de l’utilisation de données administratives, ce travail d’intégration se faisait isolément d’une source à l’autre : chacun développait son propre processus, adapté à la source traitée et aux traitements en aval. Ce modèle a fonctionné pendant des décennies. Cependant, dans le courant des années 2010, ces données administratives sont devenues plus nombreuses, plus fréquentes, plus évolutives, et de surcroît susceptibles d’alimenter plusieurs chaînes de production de données. Par ailleurs, des besoins nouveaux ont émergé dans le processus d’accueil qui devait être plus « adaptable », performant, traçable, ouvert, tout en continuant d’assurer un niveau élevé de sécurité.

Le service doit être adaptable. Il doit prendre en compte au plus vite des changements de contenu ou de format de l’information transmise. De telles transformations sont inévitables, car à l’image des politiques publiques ou de leurs processus de mise en œuvre, la donnée administrative n’est pas figée et évolue en fonction des impératifs de la politique publique qu’elle accompagne.

Ces évolutions doivent pouvoir être appliquées rapidement, sans pour autant être propagées simultanément à tous les fichiers si ceux-ci proviennent d’organismes différents. Les fichiers à accueillir peuvent coexister dans plusieurs versions avec des contenus modifiés selon la date de conception.

Pour répondre à ces besoins d’adaptabilité et de réactivité, le système doit d’une part gérer et accueillir simultanément plusieurs versions de fichiers, et d’autre part proposer des traitements dits « génériques », c’est-à-dire fonctionnant sur tous les fichiers.

Aussi, les statisticiens doivent disposer dans la fonction d’accueil, d’outils pour paramétrer les traitements et mesurer l’impact des changements de paramètres sur les données.

En outre, cette fonction doit tout à la fois accueillir des fichiers dont le format et le contenu peuvent être amenés à évoluer rapidement et alimenter des chaînes statistiques utilisatrices de données stables sur le long terme. Étendre le principe de généricité de l’outil servant d’interface entre l’accueil et les applications clientes est une solution pour répondre à cette problématique.

La performance informatique devient cruciale. En effet, les données sont transmises de plus en plus souvent et doivent être valorisées rapidement. Désormais, des sources extrêmement lourdes sont reçues chaque mois par l’Insee et nécessitent d’être traitées rapidement pour assurer la pertinence des statistiques produites dans des délais toujours plus réduits (demande sociale européenne).

La traçabilité est une exigence de qualité fondamentale dans un processus de production. Plus les changements sont nombreux, plus il est indispensable d’en conserver la trace. Cela permet, si nécessaire, de reproduire le traitement, de rendre compte des opérations réalisées et ainsi d’analyser plus facilement les évolutions à mener sur les traitements en aval, et enfin de documenter le processus.

Les données administratives constituent une source importante de données. Elles alimentent depuis longtemps des processus de production mais pourraient servir à des tests de nouveaux traitements statistiques. Avec les nouveaux métiers de la science des données et la montée en puissance à l’Insee des métiers de data scientists, il est nécessaire de prévoir des mécanismes permettant d’ouvrir, de manière contrôlée, l’accès aux données brutes statistiques afin de les exploiter de façon innovante.

Enfin, la sécurité s'avère primordiale pour ce type de données, celles-ci pouvant contenir des données personnelles imposant une stricte confidentialité, tout comme la protection de leur intégrité ; l’exigence de traçabilité évoquée plus haut participe également de la sécurité d’ensemble du processus et des données traitées.

Prévoir un accueil transverse des données implique donc de centraliser les règles de sécurité dans le cadre d’une gouvernance des données administratives. Il s’agit par exemple de mutualiser et réaliser le plus tôt possible des processus transversaux tels que la « pseudonymisation » des données (Cotton et Haag, 2023), mettre en place une politique et des outils de gestion des droits d’accès, tout en laissant la possibilité à chaque propriétaire d’appliquer des règles spécifiques supplémentaires.

Ces exigences nécessitent des investissements significatifs ; ainsi s’est imposée la mutualisation d’un outil d’accueil de données administratives, capable de gérer des sources de natures et d’origines différentes, et d’alimenter des processus d’exploitation divers. Un tel outil repose sur un découplage de la fonction d’accueil de la donnée et de la fonction de traitement ou d’analyse de celle-ci.

Constituer le service d’accueil des données, c’est penser la phase d’accueil comme une activité à part entière, qu’il faut dissocier des traitements nécessaires à la création d’un produit statistique.

Traditionnellement, le processus d’élaboration d’un produit statistique s’appuyant sur des données externes est de type itératif. Après une étape d’appropriation, le statisticien intègre son fichier pour obtenir un résultat attendu via différentes étapes. Si ces dernières peuvent varier, on retrouve les suivantes :

Ces phases sont la plupart du temps implémentées par blocs.

Le statisticien dispose de l’intégralité des données contenues dans le fichier et, par étapes, il va le transformer en un produit statistique. Toutefois, s’il est confortable lorsqu’on le crée, ce processus devient rapidement difficile à maintenir et à exploiter s’il n’est pas développé et implémenté de façon modulaire. En cas de transformations des données, modifier la chaîne de production peut vite s’avérer complexe, si la phase de traitement est adhérente à la phase d’accueil, c’est-à-dire si les traitements s’appuient directement sur les données brutes administratives.

L’idée de découpler l’accueil des données s’est progressivement imposée (figure 1). Ainsi, l’Insee a mis en place l’accueil de la Déclaration Sociale Nominative (DSN) , et développé un outil dédié (Accueil-Réception-Contrôle, dit ARC), pour alimenter la production de statistiques sur l’emploi et les revenus d’activité (Renne, 2018). C’est également le cas dans le processus Esane (Élaboration de Statistiques Annuelles d’Entreprises) qui s’appuie d’une part sur des données d’enquêtes et d’autre part sur des données fiscales. Plus récemment, le projet de refonte de Fidéli à la suite de la disparition de la taxe d’habitation, a partagé l’application en deux : la première pour assurer l’accueil des données et la seconde pour effectuer les traitements. Réalisé ex-post au regard des expériences, séparer l’accueil de sources externes des traitements statistiques est un choix d'une utilité majeure pour les statisticiens.

Figure 1 - L’accueil, première étape de la rationalisation des traitements

Lecture :
Schéma de gauche : Les données sont accueillies plusieurs fois. Chaque pipeline gère différemment les données en entrée. Le pipeline 1 sélectionne les données utiles et modifie la forme mais aussi le contenu, qu’il stocke en base de données. Le pipeline 2 sélectionne les données et les affine avant de les stocker dans une table exploitable par un logiciel statistique (SAS ou R, par exemple). Quant au pipeline 3, il intègre en bloc le fichier dans ces traitements.
Schéma de droite : Le service d’accueil ARC restructure l’information du fichier, mais sans la modifier. Chaque pipeline peut interroger le fichier pour récupérer les données.

Avec ce découplage, le système d’information est alors plus robuste. L’accueil des sources absorbe en grande partie les chocs exogènes, si ce service a été conçu pour cela. Enlever, ajouter ou modifier des informations peut être traité dans cette phase afin d’alimenter les traitements statistiques en aval de façon quasi identique, en minimisant la maintenance de ce dernier. ARC repose sur ce principe : une phase de conceptualisation des données, c’est-à-dire de transformation des données reçues en un système de données brutes statistiquement exploitables. Cette phase permet de gérer des modifications, comme renommer des variables ou modifier leur contenu lorsque cela est possible.

Par exemple, le fichier des déclarations de revenus POTE de la DGFiP est au format texte ; la lecture n’est donc possible que grâce à un dessin de fichier.

Ici la variable DADOKZ, qui correspond à la date de décès du référent fiscal du foyer, se lit dans le fichier de la position 247 à 254 (longueur 8). Le format indiqué est un format numérique (longueur 9), alors que la nature de la variable est de type date.

À l’issue du processus d’accueil, la donnée sera mise à disposition dans une variable date_dc (qui explicite le contenu de la variable) au format date (« YYYY-MM-DD »).

Le découplage rend possible et simplifie l’utilisation multiple des données. Lorsque l’accueil des données est intégré dans une chaîne de production d’une application de production statistique, il est difficile, voire impossible, d’ouvrir cet accès aux données à d’autres applications.

Par exemple, les données des déclarations sociales nominatives (DSN) chargées dans ARC étaient initialement destinées à la chaîne structurelle du calcul de l’emploi salarié.

Cette dernière produit les statistiques annuelles de l’emploi en matière de stock ou de répartition par statut ou activité économique. Pour cette utilisation, la chaîne structurelle est « cliente » et consommatrice des données DSN accueillies dans ARC.

Lorsque l’Insee a souhaité utiliser ces mêmes données pour réaliser des estimations conjoncturelles de l’emploi salarié, l’adaptation a été simplifiée par le découplage : à l’instar de la chaîne structurelle, la nouvelle chaîne conjoncturelle a été déclarée « cliente » de ARC. Cela aurait été quasi impossible si l’accueil de la DSN avait été intégré et couplé à la chaîne structurelle.

De plus, isoler le processus d’accueil donne l’opportunité de gérer les droits d’accès aux données par les applications clientes, chacune d’elles pouvant sélectionner les données dont elle a besoin parmi celles mises à disposition. Le partage se fait à la source sans avoir besoin de construire une « passerelle » entre les applications.

Enfin, ce découplage permet aussi d’identifier l’accueil des données comme un processus à part entière, avec tous ses avantages. Il est ainsi possible de le découpler des processus clients et donc de le faire évoluer de façon indépendante, ou encore d’ajouter un processus client supplémentaire alimenté à la source. Cela permet aussi de « cibler » les réflexions et investissements pour l’optimiser.

Sans métadonnées, les données mises à disposition sont inexploitables : en effet, elles sont issues d’une phase de transformation des données administratives en concepts statistiques. Les métadonnées servent à documenter les données produites et sont dans ce cas dites « passives ». Elles sont générées au fil des traitements et permettent de garder en mémoire les opérations sur les données, ainsi que l’utilisation des variables en interne comme en externe. Pour cela, l’Insee dispose d’un référentiel de métadonnées statistiques, RMéS, qui en permet la gestion, le partage et la diffusion (Bonnans, 2019).

Au sein du domaine des enquêtes, les métadonnées sont exploitées en entrée du processus de conception du support de collecte afin de le générer (Cotton et Dubois, 2019). Cette utilisation est possible grâce à la mise en place d’un ensemble d’outils et de services reliés à RMéS. On parle alors de métadonnées « actives », c’est-à-dire qu’elles ont une fonction autre que documentaire dans le processus statistique. Un des enjeux de l’accueil des données administratives est donc de rendre ces métadonnées « activables », à l’instar de ce qui se pratique sur les enquêtes ; cela implique de documenter le plus en amont possible les métadonnées issues des fichiers administratifs.

Fournir aux producteurs les métadonnées associées aux données statistiques brutes leur donne les éléments pour documenter leur processus et, in fine, intégrer leurs propres métadonnées au sein de RMéS. Une expérimentation récente sur des données foncières a démontré que la majeure partie des métadonnées saisies dès la phase d’accueil pouvaient être réutilisées sans modifications dans les processus ultérieurs, et ce jusqu’à la réalisation des bases de diffusion.

Par ailleurs, livrer des métadonnées en entrée du processus de traitement permet de mettre en place des métadonnées dites de production : par opposition aux métadonnées dites de diffusion, elles permettent de tracer, configurer voire spécifier les modifications successives des données. On parle alors de lignage des données (Ouvrir dans un nouvel ongletBiseul, 2023).

Mettre en place un service d’accueil exige de spécialiser cette phase d’accueil des données. Qui dit spécialisation, dit métiers. Au regard des différentes tâches à réaliser, deux nouveaux métiers ont émergé.

Le premier est celui de modélisateur des données. Celui-ci conçoit les modèles dans lesquels seront insérées les données administratives pour les utilisateurs. Il transforme un modèle donné, sur lequel il ne peut agir, en un modèle statistiquement exploitable ; ce dernier doit être à la fois robuste aux changements et construit de telle sorte que les utilisateurs puissent utiliser simplement les données pour produire des statistiques. Il lui faut donc être compétent en matière de modélisation mais aussi être à l’écoute des utilisateurs afin que le modèle développé corresponde aux attentes.

Les données étant par nature administratives, il est parfois difficile de les transformer en concept statistique. Le modélisateur peut les segmenter par thématique : on parle alors de partitionnement vertical des données. Une modélisation technique vient compléter la modélisation sémantique.

Par exemple, le fichier des déclarations de revenus (POTE), fourni par la DGFiP, est un fichier très volumineux, tant par son nombre de lignes (45 millions) que par son nombre de variables (600 pour la partie fixe, plus du double pour la partie variable). Dans ce fichier, il est possible d’identifier plusieurs thématiques autour de l’impôt : impôt sur le revenu, contribution sociale généralisée, impôt sur la fortune immobilière, etc. Autant de « thèmes » qui peuvent être isolés. L’existence et les caractéristiques d’un impôt ne sont par nature pas pérennes : la taxe d’habitation en est un exemple. L’avantage de cette modélisation est de construire un modèle autour de thématiques pour chaque impôt. In fine, l’utilisation du fichier sera plus robuste puisque seules les parties affectées par les changements sont modifiées.

Le second métier nouveau est celui d’intendant des données. L’intendance des données est un concept pour lequel il existe plusieurs définitions, correspondant à des contours plus ou moins ambitieux. La définition retenue dans cet article est celle de Statistique Canada, à savoir : « L’intendance des données, c’est la gouvernance des données en action, c’est-à-dire la déclinaison opérationnelle de la politique en matière de données ». Il s’agit donc de la mise en œuvre effective des règles régissant la collecte, la gestion, la sécurité, la qualité et la diffusion des données au sein d’une organisation.

Ainsi, pour l’intendant, sont requises des compétences en matière d’administration des données puisqu’il assure la réception, le contrôle et la documentation des données qu’il met à disposition.

Il doit aussi posséder des compétences en matière de gestion de données, puisqu’il assure la gestion des droits d’accès aux données et suit les conventions passées avec les fournisseurs (respect des délais et du format de transmission et de conservation des données).

Concernant l’accès aux données, la diversité des utilisations possibles pour une même donnée administrative complexifie la problématique de leur sécurisation. « Pseudonymisées » et transformées en un format statistique, les données sont plus ouvertes et plus « partageables ». Cependant, ce partage doit être organisé et sélectif, selon des finalités précises et en conformité avec le principe de proportionnalité des traitements. L’intendant des données doit appliquer le droit des utilisateurs concernant leur accès aux données.

Enfin, ce spécialiste est en contact direct avec les utilisateurs et les producteurs de données administratives. Il est notamment en première ligne pour régler les problèmes de transmission de données. Des qualités relationnelles sont donc également requises.

L’intendant est légitime pour la collecte de la donnée et sa gestion mais pas sur ses usages. Il faut donc conserver une relation entre le producteur statistique et le fournisseur, apurée des questions de gestion, donc centrée sur le contenu et l’usage des données ainsi que sur leurs évolutions.

L’application informatique Accueil-Réception-Contrôle ARC assure le service d’accueil à l’Insee depuis une dizaine d’années, puisqu’elle existe depuis 2015 avec l’accueil des fichiers de la DSN.

ARC couvre fonctionnellement certaines des phases du GSBPM (figure 2). Ce dernier est un cadre standard des organismes statistiques qui leur permet d'adopter une terminologie commune pour décrire le cycle de vie d'une opération statistique (Erikson, 2020).

Figure 2 - Le champ fonctionnel d’ARC au regard du modèle générique de description des processus de production statistique (GSBPM)

Le statisticien s’appuie sur l’opération transverse de gestion des métadonnées pour élaborer la conception des produits finaux de diffusion et la conception de la description des variables utilisées. Pour cela, il utilise directement l’implémentation proposée dans l’application ARC ou lui soumet une modélisation DDI (Dondon et Lamarche, 2023) réalisée via l’outil Colectica Designer.

Les phases de conception de la collecte et de conception du cadre et de l’échantillon sont hors du champ de l’application ARC et sont élaborées en accord avec le fournisseur de données.

Les fonctionnalités couvrant les phases de conception du traitement et de l’analyse, de conception de système de production et du déroulement des travaux et les trois phases d’élaboration modélisent la fonction d’accueil dans ARC et posent le cadre des configurations possibles pour le statisticien. Elles ont été construites lors de la conception de l’application et constituent le pipeline d’ARC (figure 3).

Figure 3 - Le pipeline de la Déclaration Sociale Nominative (DSN)

Le statisticien a toutefois la main pour configurer le déroulement de travaux pour les phases de l’étape « Traitement » ; il peut tester ses configurations sur de petits volumes de données, dans des espaces dédiés, disjoints des espaces de production et appelés « bacs à sable ». Les bacs à sable dans ARC permettent la mise à l’essai du système de production sur un nombre réduit de fichiers sources. Lorsque la mise au point est terminée, le statisticien applique ses configurations sur le flux de fichiers réels et procède à la finalisation du système de production.

Dans le cadre d’un traitement statistique utilisant une fonction d’accueil, ARC couvre les étapes « conception », « élaboration » et « collecte » du GSBPM et partage avec les applications utilisatrices des données, certaines phases de l’étape « Traitement ». Par exemple, ARC intervient sur la phase d’édition et imputation des données pour publier certaines données afin de les rendre exploitables statistiquement (correction de modalités, mise en conformité au format ou aux valeurs attendues), alors que les transformations statistiques au sens métier (imputations de valeurs manquantes ou détection de valeurs aberrantes) sont déportées sur les applications de traitement des données.

Il n’y a pas à ce jour de production automatisée d’un bilan qualité de l’accueil d’une source (nombre d’enregistrements lus, nombre de valeurs erronées, etc.), qui correspond à la phase de recueil des produits d’évaluation du GSBPM. Celle-ci est actuellement prise en charge par le système d’information (SI) client. Le produit ARC devra évoluer afin de proposer une implémentation de ce recueil pour les traitements le concernant (et notamment le respect des normes annoncées), car l’assurance qualité est une composante essentielle de la fonction d’accueil.

La DSN est une déclaration en ligne obligatoire, permettant aux employeurs de transmettre aux organismes de protection sociale les informations relatives aux salariés (Humbert- Bottin, 2018). En décembre 2023, l’Insee a reçu environ 2,5 millions de fichiers d’employeurs avec les données salariales de leurs employés. Il en recevait 1,8 million en 2016.

Les DSN sont converties en données statistiques par le traitement informatique ARC. Ce traitement est architecturé en « pipeline », c’est- à-dire constitué d’une succession de modules fonctionnels, chaque module réalisant une opération précise. Les modules de ARC sont préalablement paramétrés par le statisticien. ARC suit une logique de document : chaque fichier est traité individuellement et indépendamment des autres, et son nom est conservé comme identifiant pour chaque donnée.

La phase GSBPM d’intégration des données est couverte dans ARC par les deux premiers modules du pipeline de traitement.

Dans le module réception, les documents reçus sont référencés dans ARC. Cette étape est essentielle, d’autant plus pour la DSN pour laquelle le nombre de fichiers reçus au fil de l’eau se compte en millions. Chaque document de la DSN correspond à la déclaration d’une entreprise (au sens large, y compris les employeurs publics désormais). Ce module permet donc de vérifier qu’aucune déclaration n’est en double ou oubliée.

Puis vient le chargement. Les fichiers sont d’abord lus, puis leurs données et leur structure définie dans le modèle XML de la DSN sont stockées dans la base de données. C’est lors de cette étape que les fichiers sont associés à leur « norme », laquelle identifie la source et le millésime, selon des règles définies par le statisticien. Ces deux critères de norme et de millésime déterminent quelle sera la suite du traitement.

Les documents de la DSN sont des fichiers XML dont la structure et l’arborescence sont documentées dans le cahier technique de la DSN, de manière très complète. Ce format est adapté aux logiciels de gestion utilisés par les entreprises, mais beaucoup moins à la statistique. Le but du pipeline dans ARC est de transformer les données de la DSN en tables exploitables par les statisticiens.

Une fois intégrées, les données des fichiers sont structurées dans le module de structuration. Le XML ne fournit que des relations d’ordre hiérarchique entre les différentes données : par exemple, dans la DSN, une entreprise contient un ou plusieurs établissements, desquels dépendent un ou plusieurs individus, qui sont associés à un ou plusieurs contrats de travail. Or certaines règles de gestion ne peuvent pas être représentées par simple relation hiérarchique, comme les lieux de travail. Ces derniers ne dépendent pas hiérarchiquement de l’entreprise, mais il existe une relation entre un contrat de travail et le lieu où il est exercé. Cette relation est documentée formellement dans le cahier technique de la DSN. L’étape de structuration permet donc d’ajouter autour des données, un ensemble de règles de gestion pour créer des liens entre données et faciliter les opérations statistiques.

L’étape suivante est le contrôle. Ce module implémente les traitements relevant des phases d’examen et validation et d’édition et imputation. Le statisticien peut définir des contrôles de conformité, des redressements de forme, des filtres sur les données. Ainsi, il est possible de contrôler le format d’un champ, compléter des dates non renseignées, ou filtrer sur les dates de déclaration.

Le module de mapping vient ensuite mettre au format les données dans le modèle conçu par le statisticien pour l’exploitation statistique : cela correspond au calcul de nouvelles variables et unités.

Les fichiers de la DSN évoluent d’un millésime à l’autre. Le statisticien peut modifier les règles utilisées dans le mapping pour gérer ces changements, mais indépendamment du modèle statistique qui peut rester inchangé. Pour les applications en aval, cette constance permet de comparer les données d’une année sur l’autre sans maintenance. Le modèle statistique lui-même peut évoluer, mais marginalement et de façon maîtrisée par le statisticien.

Cette étape de mapping requiert la construction préalable du modèle statistique appelé dans ARC « famille de norme ». Ce modèle permet de mettre en relation des entités statistiques et peut être soit défini directement dans l’application ou importé d’une spécification DDI. Le modèle de la DSN va contenir des tables, comme la table Employeur, avec les champs d’adresse de l’employeur, d’activité principale de l’entreprise ou le numéro d’immatriculation au répertoire Sirene (Siret) ou encore la table Individu avec les champs du prénom ou du pays de résidence.

Tous ces modules de transformation peuvent s’appuyer sur des données externes intégrées par le statisticien, telles que des tables de nomenclatures, des référentiels ou des tables de correspondance. Par exemple, pour la DSN, les codes de pays de naissance des salariés sont recodés selon le code officiel géographique. ARC implémente ainsi en partie la phase de classification et codage.

À l’issue du mapping, ARC finalise les fichiers de données. Les fichiers de la DSN, fraîchement transformés en tables de données exploitables, sont mis à disposition pour être récupérés par les applications clientes. L’application permet de gérer les clients de chaque source de données. Chaque livraison de données est horodatée et une seule récupération des données est autorisée par client, ceci afin d’éviter de doublonner des données. Une fois les fichiers téléchargés par les clients déclarés, ARC les supprime après un laps de temps défini par le statisticien.

Les données mises à disposition subissent d’autres transformations par les applications clientes de ARC : restructuration des données par unité statistique, calcul de variables dérivées, etc.

L’intégration des données administratives (Cotton et Haag, 2023) de la DSN passe par toutes ces étapes, de l’accueil réalisé par ARC jusqu’à leur transformation par les applications clientes. Le Répertoire Statistique des Individus et des Logements (Résil) utilise le même schéma d’intégration et ARC a été choisi pour mettre en œuvre la fonction d’accueil.

L’application informatique ARC a été conçue dans le cadre de la construction d’un Système d’Information sur l’Emploi et les Revenus d’Activité (SIERA) alimenté par diverses sources de données administratives. Il coordonne plusieurs applications et prend en charge l’ensemble des traitements produisant des indicateurs statistiques structurels et conjoncturels sur l’emploi et les salaires. Plus précisément, ARC avait pour objectif, au sein de ce SI, d’accueillir dès 2015 les fichiers mensuels de la Déclaration Sociale Nominative envoyés par la Cnav. Ce fut un challenge pour la maîtrise d’ouvrage et l’équipe de développement : le flux des données à traiter mensuellement était massif et concentré (à l’origine, 1,8 million de fichiers par mois, reçus entre le 18 et le 22 de chaque mois). Les dessins de fichiers n’étaient pas stabilisés et les délais de mise en œuvre courts !

En matière de fonctionnalités, le produit devait répondre à deux besoins a priori orthogonaux : être suffisamment performant pour traiter tous les mois l’ensemble des fichiers en une semaine (la contrainte telle qu’elle s’exprimait au début), et pouvoir s’adapter rapidement à des changements de ces fichiers. Pour cela, il doit être optimisé en permanence, tant sur le plan de la pertinence que de la rapidité des traitements. Cela implique souplesse et réactivité dans la mise au point des changements liés au contenu ou au format des données source, tout en minimisant l’impact sur les performances.

L’option prise est de laisser la main aux statisticiens pour programmer, tester et reprogrammer, dans un « bac à sable » les traitements d’accueil en fonction de l’évolution des sources et des attentes des traitements statistiques en aval. Par ailleurs, l’application est conçue de manière à ce que les réglages mis au point par les statisticiens ne s’appuient que sur des paramétrages des différentes phases de l’accueil, sans influer sur les traitements, et donc sans risque d’altérer les performances du système. Le statisticien peut ainsi se concentrer sur les aspects « métier » et son collègue en charge de l’exploitation informatique fait l’économie d’une phase d’optimisation.

Développer rapidement cette fonction d’accueil a permis la conception du projet ARC en mode agile. D’un point de vue métier, ce besoin de souplesse était également très fort. En effet, les maintenances adaptatives pour absorber les changements de normes des fichiers source réalisées sur d’autres chaînes de traitement du SIERA comme le traitement de la N4DS, s’avéraient très coûteuses. ARC devait répondre à ce problème de façon générique pour être réutilisable et pouvoir accueillir d’autres sources que la DSN.

ARC fut ainsi déployé en 2015 pour l’accueil des fichiers XML de la DSN puis réutilisé dans le SIERA pour accueillir les fichiers des Déclarations Annuelles de Données Sociales (DADS), qui devaient « coexister » jusqu’en 2021 avec la DSN. L’application a également été utilisée pour l’accueil de fichiers déjà produits par l’Insee, dans une optique de mise dans un format commun. Dans cette première version, le produit était déjà capable de prendre en charge l’accueil de fichiers XML, CSV et clé-valeur.

Les contraintes auxquelles il a fallu faire face pour développer un outil d’accueil de la DSN ont conduit à lui conférer les « bonnes propriétés » pour le désigner comme l’outil central d’un processus d’accueil des sources administratives découplé des traitements en aval. L’usage d’ARC s’est alors progressivement développé.

Face à un changement de norme pour les liasses fiscales utilisées dans le processus Esane (Élaboration de statistiques annuelles sur les entreprises), il a été envisagé d’utiliser ARC plutôt que de développer un nouveau système spécifique à ce processus.

L’instruction technique menée a mis plusieurs points en évidence : la nécessité d’une évolution fonctionnelle d’ARC, puis l’intérêt de cet outil pour les utilisateurs et enfin le fait que l’utilisation de l’application représentait l’option la moins coûteuse pour prendre en charge cette évolution.

La couverture fonctionnelle d’ARC n’était cependant pas complètement suffisante pour prendre en charge les fichiers hiérarchiques complexes que sont les fichiers fiscaux. La normalisation du processus d’accueil proposé par l’application a néanmoins permis de réaliser les évolutions rapidement et d’enrichir l’offre du produit. ARC a donc pour la première fois été réutilisé hors SIERA en 2019 pour l’accueil des fichiers fiscaux dans Esane.

En 2020, dans le cadre d’un groupe de travail du système statistique européen sur le partage d’outils statistiques, ses fonctionnalités ont une nouvelle fois été étendues et cela dans deux directions. La première permettait de déployer l’application sur des infrastructures conteneurisées, permettant notamment une scalabilité accrue. La seconde rendait possible l’appel des étapes d’accueil de fichier en mode web-service. ARC devenait alors capable de traiter des invocations à la demande, unitaires, en complément des traitements de masse initialement développés. SIRENE4 a ainsi intégré l’application dans ce mode d’utilisation de machine à machine pour contrôler de façon automatique la conformité des liasses d’immatriculation provenant du Guichet Unique (Alviset, 2020).

ARC a donc évolué progressivement, pour devenir une application robuste et performante (encadré).

L’extension progressive des fonctionnalités et des usages d’ARC ainsi que son caractère incontournable dans différentes productions ont conduit à une prise en charge adaptée à ces enjeux. Il s’agissait d’une part de piloter la mise en œuvre et le déploiement d’investissements transverses (amélioration des performances, traitement des métadonnées, maintien en conditions opérationnelles et de sécurité, etc.), et d’autre part d’animer la communauté des utilisateurs (communication sur le produit et ses évolutions, recueil et priorisation des besoins, formations, etc.). Ces actions sont essentielles pour un produit mutualisé comme ARC afin de conserver un champ fonctionnel et de prendre en compte les besoins des divers utilisateurs.

En 2021, le programme Résil est devenu maîtrise d’ouvrage du produit ARC du fait de son positionnement central dans le système d’information, mais aussi en raison de la diversité des sources qu’il accueille.

Le monde de la donnée, comme celui de l’informatique, est en perpétuelle évolution. Pour répondre aux défis informatiques, les entreprises ont développé des stratégies comme la mise en place de l’agilité et du DevOps. Cette idée a été reprise par l’univers de la data avec le développement du DataOps, qui vise notamment à concilier automatisation, reproductibilité, interactivité et traçabilité en matière de traitement des données, tout en réunissant différents métiers de la data autour d’outils communs. L’Insee, en proposant dans ses développements l’agilité, intègre déjà beaucoup de recettes du DataOps. Le service d’accueil que rend ARC s’inscrit pleinement dans cette démarche, de par la souplesse et le découplage des traitements qu’il met en œuvre.

ARC est une application qui a su évoluer au cours du temps en fonction de besoins multiples et variés. Une application désormais facile à déployer, adaptée à un chargement souple et performant de données externes, en amont d’applications statistiques. Une application qui devient centrale dans la mise en œuvre de la stratégie d’utilisation des données administratives visant à la fois la diversification des sources, la rapidité de leur traitement, la capacité à les mettre au service de processus statistiques différents, et cela en toute sécurité.

L’ouvrir vers des utilisations plus exploratoires, réalisés en « self service » par des statisticiens, peut permettre d’explorer plus facilement le potentiel de nouvelles sources de données, au service de l’innovation statistique.