# Les usages métiers de VTL à l'Insee

## Introduction à VTL

*VTL est un langage standard permettant de définir des règles de validation et de transformation (ensemble d'opérateurs, leur syntaxe et leur sémantique) pour tout type de données statistiques. VTL s'appuie sur la section "Transformation" du modèle d'information SDMX, en reprenant les parties communes de GSIM, SDMX et DDI pour la représentation des concepts et des données. L'hypothèse est qu'une telle formalisation logique des règles de validation et de transformation fournit une expression "technologiquement neutre" du traitement réalisé directement écrite par le statisticien, par rapport à laquelle diverses implémentations et langages de programmation spécifiques peuvent permettre l'exécution. [Source : extrait de [smdx.org](https://sdmx.org/?page_id=5096) - traduction unité Qualité]*

La Task Force for the Validation and Transformation Language (VTL), créée en 2013 sous l'initiative du secrétariat SDMX, a publié la première version de VTL (1.0) en 2015. La dernière version publiée (2.0) date de 2018, mise à jour en 2020.
Au delà du portage par la communauté SDMX, Eurostat promeut l'usage de VTL au sein de la communauté statistique européenne en mettant en avant des usages à la fois pour les données statistiques (micro-données ou données agrégées, quantitative ou qualitative) que pour les répertoires [[Eurostat](https://ec.europa.eu/eurostat/web/sdmx-infospace/sdmx-explained/what-and-why) ou [CROS](https://ec.europa.eu/eurostat/cros/content/data-and-metadata-exchange-standards_en) ou [ESSnet I3S](https://github.com/I3S-ESSnet)]. VTL est également utilisé par les banques centrales.

**Pourquoi utiliser le langage VTL à l'Insee ?**

- **Un langage orienté utilisateur**
Utiliser VTL à l'Insee, c'est tout d'abord documenter uniformément les traitements de base des données. Cela facilitera la transmission des savoirs en interne voire une meilleure appropriation des données par des utilisateurs experts (exemple du chercheur souhaitant connaître les traitements opérés sur un jeu de données) ainsi que la documentation, la réutilisation et le lignage de la transformation des données.
Le modèle de données de VTL intègre directement le concept de métadonnées, en particulier en s'appuyant sur le modèle conceptuel GSIM.

- **Un rôle actif pour les traitements**
De plus, reposant sur une grammaire formelle[^1], VTL est dit "machine-actionable". Autrement dit, documenter/spécifier, c'est aussi savoir exécuter le traitement (sous réserve de disponibilité du moteur de transformation). C'est donc l'opportunité d'aller plus loin dans le principe de métadonnées actives.

[^1]:Alors qu'un langage est un ensemble de mots, qui sont simplement des séquences de symboles choisis dans un ensemble (en général fini) appelé alphabet. Un langage peut s'appuyer sur une grammaire formelle (par exemple : Java, JavaScript, Python), mais pas toujours (par exemple : R ou SAS).)

- **Une interopérabilité accrue**
VTL offre la possibilité de formaliser les algorithmes de validation (ou de transformation) des données pour le partage des règles de validation (ou de transformation) dans la communauté statistique, par exemple entre producteurs et diffuseurs ou entre Eurostat et les INS fournisseurs de données. Cela contribue à spécifier les exigences de qualité attendues sur les données échangées dans le SSE et facilite la validation avant l'échange de données. **Technologiquement neutre**, c'est aussi l'opportunité, de savoir reproduire nos traitements plus durablement dans le temps.

## VTL et les cas d'usage dans la production statistique de l'Insee

VTL permet l'écriture de règles pour des contrôles, des redressements "simples"[^2], des agrégations, des recodifications de variables, la création de nouveaux jeux de données...
[^2]:Hors traitements statistiques complexes de type économétrie, calcul de repondérations...

L'analyse présentée dans cette note, est structurée selon les grands projets en cours à l'Insee collaborant avec l'équipe *Métadonnées statistiques* à la construction des filières de métadonnées actives (Metallica, Résil, Aïda-Archimed-Mélodi).
Les cas d'usage mentionnés s'appuient sur des contributions des projets partenaires et/ou l'expérience acquise par l'équipe *Métadonnées statistiques*.
Des références au [GSBPM](https://statswiki.unece.org/display/GSBPM/GSBPM+v5.1) sont également proposées pour la phase de traitement, le lecteur trouvera en annexe 3 le contenu des sous-phases.

:::info
NB : cette première synthèse a été réalisée par l'unité Qualité à partir du matériau existant et de contributions des programmes Métallica et Résil. Elle devra être enrichie avec l'expérience des métiers (producteurs ou diffuseurs).
:::

### Zoom : Filière de collecte d'enquêtes (projet Metallica)
*Thomas Dubois - Unité Qualité*
*Eric Sigaud - Programme Métallica*
*Benoit Werquin - Programme Métallica* (retour d'expérience)

#### Retour d'expérience sur le choix de VTL dans la filière de collecte d'enquête

Dans la filière de collecte des enquêtes entreprises (Pogues-Eno-Coltrane), les questionnaires reposent actuellement sur des technologies XML. Une syntaxe a été mise en oeuvre afin de permettre au concepteur de spécifier dans Pogues ses filtres et contrôles de cohérence. La syntaxe retenue est "inspirée" de XPath (langage de requête pour localiser une portion d'un document XML), elle est adhérente à la technologie des questionnaires Coltrane (XForms). Les métadonnées du questionnaire, au format DDI, sont dans ce cas enrichies de règles écrites en *pseudo-XPath* pour préciser les formules de filtres et de contrôles. Cet enrichissement n'est que récipendiaire et abstrait de la sémantique/documentation contenue dans les formules, celles-ci sont transmises directement au logiciel en charge de l'exécution de ces formules. Si cette modélisation a fonctionné pour les questionnaires issus de Coltrane, son principal défaut est l'adhérence à la technologie retenue à l'époque.

Dans le cadre de la mise en place de la filière de collecte des enquêtes auprès des ménages portée par le programme Metallica, des investissements ont été menés pour faire évoluer et rénover l'atelier de conception. Les questionnaires sont désormais implémentés dans des technologies plus conformes à l'état de l'art (Javascript/React) et permettent à la fois de produire des questionnaires web et des questionnaires administrés par des enquêteurs. La syntaxe de description des filtres et contrôles de la filière de collecte historique en pseudo-Xpath ne fonctionne plus nativement dans cette nouvelle version.

Lors de ces évolutions, une réflexion a été menée pour choisir un nouveau langage répondant aux critères suivants :
- privilégier un langage de spécifications techniquement neutre et accessible aux concepteurs d'enquête, et non un langage technique (XPath, XQuery, Java, Javascript, R, Python...) afin d'éviter les migrations techniques inhérentes à la vie des systèmes d'information. La spécification d'un filtre ou d'un contrôle doit être indépendante de la technologie d'exécution, notamment dans un environnement complexe où cette même règle peut être exécutée dans différents contextes d'exécution (application hors ligne pour l'enquêteur, API, ...).
- privilégier un langage disposant d'une grammaire formelle afin qu'il soit à la fois "machine-actionable" et qu'il permette de s'inscrire dans la logique de métadonnées actives où la documentation/spécification des règles (métadonnées) soit aussi exécutable (active) sans être réécrite. De plus, l'usage d'une grammaire formelle, offre la perspective de disposer plus facilement d'outils disposant de fonctionnalités telles qu'un analyseur syntaxique ou l'autocomplétion pour une aide à la saisie dans une interface de conception telle que Pogues.

Dans un contexte où Eurostat pousse le standard VTL et les investissements sur la pile technique l'accompagnant (par exemple, l'ESSnet I3S 2019-2020 ), le choix de VTL a été fait de préférence au langage *maison* LSE développé lors du programme Resane sur les statistiques structurelles d'entreprises (DSE) en 2004-2012.

À noter que d'autres produits *maison* ont été mis en place pour permettre au statisticien de spécifier des contrôles et algorithmes simples sur des jeux de données avec une mise en oeuvre automatisée en production. On pourra citer ARC (accueil, réception mise au format statistique de données) et sa syntaxe inspirée de SQL développé en 2013-2015 dans le cadre du projet Pirénés d'évolution du système d'information sur l'emploi et les revenus d'activité.

#### Un besoin d'un langage de "métadonnées fonctionnelles"
*Un même langage pour toutes les métadonnées fonctionnelles*
La filière d'enquête est conçue sur le principe des métadonnées actives, en particulier le pilotage de processus d'enquête par des métadonnées. Or ces métadonnées, de "processus d'enquête", sont d'une certaine complexité et nécessitent, non pas seulement la captation de chaînes de texte ou de descriptions de variable, mais également la définition d'algorithmes.
Outre les contrôles et filtres des questionnaires, il y a également :
* des contrôles post-collecte,
* des fonctions "règles de remise en collecte",
* des fonctions "scores de complétude d'un questionnaire",
* des fonctions de réconciliation/priorisation de questionnaires en provenance de différents modes de collecte (doublons, réponses multiples...),
* de préparation du fichier en entrée des traitements statistiques à partir des données de différents modes de collecte, de collectes antérieures ou enrichies avec les données de la base de sondage,
* etc.

Ainsi lorsqu'un concepteur doit spécifier de telles métadonnées "fonctionnelles", il y a un intérêt certain à proposer le même langage pour chacune d'entre elles (compétence homogène, expérience utilisateur homogène, documentation/diffusion homogène, etc.).

*Des investissements déjà effectués*
L'investissement sur VTL a déjà été effectué pour de premières métadonnées fonctionnelles, les contrôles et filtres des questionnaires dans l'atelier de conception d'enquête (Produit Concevoir).

*Une surface d'application maîtrisable et maîtrisée*
VTL est conçu comme un langage spécifique centré sur la validation et la transformation de données statistiques. Cette surface fonctionnelle réduite - par opposition à des langages complets comme R ou Python - en simplifie la compréhension pour le statisticien comme il en simplifie l'implémentation dans des environnements divers (un questionnaire web, un traitement de masse distribué, etc.).

#### Un besoin de métadonnées activées tout au long d'un processus
VTL est un langage statistique, à ce titre, il comprend le concept même de métadonnées dans la structure de son modèle de données.
Ainsi, ces métadonnées sont facilement mobilisables, au travers du modèle SMDX et de la grammaire formelle du langage VTL, tout au long du processus et des moteurs d'exécution.
Par exemple, il est nécessaire de mobiliser une même réponse à une question quand il s'agit de calculer un contrôle de questionnaire, une règle de calcul de remise en collecte, ou encore lors de contrôles post-collecte, ou de "reprise de questionnaire". Il s'agit d'autant de fonctions devant mobiliser la même "variable" mais exécutées dans différents contextes (navigateur, application smartphone, chaine en back-office, etc.), caractéristiques supplémentaires du langage VTL exploitées par la filière d'enquête.
De même, un même contrôle doit être exécuté dans un environnement de spécification d'un questionnaire, dans un environnement d'exécution d'un questionnaire, ou encore dans un poste de reprise de questionnair, là aussi, caractéristique du langage VTL (une grammaire formelle indépendante des moteurs d'exécution) exploitée par la filière d'enquêtes.

### Zoom : Traitement des données administratives (Résil)
*Olivier Haag- programme Résil*
Dans le cadre du programme Résil, VTL devrait être utilisé essentiellement pour 3 fonctionnalités bien distinctes :
• pour définir le champ des population d‘intérêt (sous-processus 5.1 du GSBPM, cf annexe 2) ;
• pour calculer des variables qui nous permettront de définir nos population de référence (probabilité de présence, calcul de l’adresse de référence etc. (sous-processus 3.2 et 5.5) ;
• pour calculer des indicatrices qualité (sous-processus 8.2) ;

L’idée est d’utiliser le VTL pour les parties du processus de production qui peuvent nécessiter de nombreux tests afin d’arriver à la situation la plus optimale possible et également pour les parties qui vont évoluer dans le temps.
L'objectif du recours à VTL est donc de faciliter le travail du statisticien en le rendant plus autonome et d'éviter les allers-retours de mise au point avec l’équipe informatique. Cela permettra de mettre du self en production dans un cadre standardisé dont ne disposait pas le LSE.

### Zoom : Filière de diffusion
*Florian Vucko - Unité Qualité*

Dans le cadre des trois projets de refonte engagés par la DDAR, on pourrait utiliser VTL pour 4 fonctionnalités bien distinctes :

- contrôler la conformité des fichiers livrés par les producteurs à l'entrée de la dataplatform, que les données soit individuelles ou agrégées (sous-processus 7.1) ;
- effectuer des contrôles de vraisemblance sur les données. Par exemple en comparant les données d'un nouveau millésime à celles des millésimes précédents (sous-processus 5.3 et 6.2) ;
- sélectionner un champ de données (variables et enregistrements) dans la dataplatform en fonction de canaux de diffusion (fichier FPR, fichier détail sur insee.fr, fichier GEN, fichier pour le CASD...) (sous-processus 7.2) ;
- enrichir les données livrées avec d'autres variables, par exemple, en ajoutant le code du département pour un jeu de données disposant d'un code commune (sous-processus 7.2).

Le recours à VTL permettrait de disposer d'un même langage pour documenter et spécifier les contrôles et transformations effectuées en diffusion. La reproduction des traitements en cas de re-livraison des données par le producteur, et l'adaptation pour les livraisons des millésimes suivants seraient ainsi facilitées.
L'utilisation du moteur *Trevas* pourrait par ailleurs rendre la description en VTL des contrôles et transformations directement utilisable pour exécuter les traitements en production.

### Zoom : Census 2021
*Extrait avis du comité des investissements sur la note de cadrage opérationnelle du projet Census 2021*

Le projet Census 2021 a pour objectif, dans le cadre de réglements européens de mettre à disposition via un portail et des outils gérés par Eurostat des des données annuelles relatives aux individus, aux ménages et aux logements aux niveaux communal et supra-communal ainsi que des données à la maille de carreaux de 1 km², les données restant sous la responsabilité de chacun des états-membres.
VTL a été retenu pour la transformation des données en s'appuyant sur le moteur *Trevas-Spark* (adapté au traitement de grands volumes), le comité des investissements pose la question du recours à VTL pour la constitution des cubes et recommande la clarification du positionnement de l'institut sur l'usage de VTL et des moyens consacrés à l'entretien des moteurs d'exécution associés.

## Comment continuer ?

VTL pourrait être ajouté aux standards internationaux suivis par l'unité Qualité (veille, participation à des communautés) qui en ferait la promotion dans le cadre des filières de métadonnées actives et du rôle central que pourrait/devrait jouer RMéS sur la centralisation/la mutualisation/la cohérence des contrôles, validation ou recodification des variables.

Il sera également nécessaire d'offrir des formations (en interne ou avec Eurostat), l'animation d'une communauté de praticiens.

## Annexes

## Annexe 1 : opérateurs et fonctions principales de VTL

## Annexe 2 : les utilisations de VTL en Europe
*[Séminaire Experts SDMX (2021)](https://www.imf.org/en/News/Seminars/Conferences/2021/01/25/10th-statistical-data-and-metadata-exchange) - Consultation Eurostat (retours partiels)*
:::info
Validation en cours, en attente retours
:::
**Banques centrales**
Banque centrale d'Italie (pour le réseau des banques centrales) : éditeur et moteur VTL - Matrix model and Expression Language (EXL)
Banque centrale européenne (projet Valice pour la validation des données transmises par les banques nationales)

**Eurostat**
Recours à VTL pour l'outillage de validation des données (COMVAL VRM) lors de la transmission des données par les états membres (environnement SDMX).

**Instituts de statistiques**
Istat (Italie) : VTL Istat Framework
Statistics Finland : Editing and imputatation service – (SAS engine)
Statistics Poland : VTL - SQL translation

**CASD**
Implémentation en cours (en remplacement partiel de SAS pour des manipulations de données et de jeux de données).

## Annexe 3 Phases et sous-processus du GSBPM cités dans la note

**Phase Construire**
#### Réutiliser ou construire des composants d'analyse (3.2)
Ce sous-processus décrit les activités de réutilisation des composants existants ou de construction de nouveaux composants nécessaires aux phases "Processus" et "Analyse", tels que conçus dans la phase "Conception". Les services peuvent comprendre des fonctions et des caractéristiques de tableaux de bord, des services d'information, des fonctions de transformation, des services de données géospatiales, des cadres de flux de travail, des services de gestion des fournisseurs et des métadonnées.

**Phase Traiter**
#### Intégrer les données (5.1)
Ce sous-processus intègre les données provenant d'une ou de plusieurs sources. C'est là que sont combinés les résultats des sous-processus de la phase "Collecte". Les données d'entrée peuvent provenir d'un mélange de sources externes ou internes, et d'une variété d'instruments de collecte, y compris des extraits de données administratives et d'autres sources de données non statistiques. Les données administratives ou d'autres sources de données non statistiques peuvent se substituer à tout ou partie des variables directement collectées par l'enquête. Ce sous-processus comprend également l'harmonisation ou la création de nouveaux chiffres qui concordent entre les sources de données.

#### Classifier et coder (5.2)
Ce sous-processus permet de classifier et de coder les données d'entrée. Par exemple, les routines de codage automatique peuvent attribuer des codes numériques aux réponses textuelles selon une classification statistique prédéterminée afin de faciliter la saisie et le traitement des données.

#### Examiner et valider (5.3)
Ce sous-processus examine les données afin d'identifier les problèmes, les erreurs et les écarts potentiels tels que les valeurs aberrantes, les non-réponses aux questions et les erreurs de codage.

#### Editer and imputer les données (5.4)
Lorsque les données sont considérées comme incorrectes, manquantes, peu fiables ou obsolètes, de nouvelles valeurs peuvent être insérées ou des données obsolète peuvent être supprimées dans ce sous-processus.

#### Calculer de nouvelles variables et unités (5.5)
Ce sous-processus permet de dériver des données pour des variables et des unités qui ne sont pas explicitement fournies dans la collecte, mais qui sont nécessaires pour fournir les résultats requis.

#### Calculer des agrégats (5.7)
Ce sous-processus permet d’obtenir des données agrégées et des totaux de population à partir de microdonnées ou de plus petits agrégats. Il inclut la mise en commun des données dans les cas où les enregistrements partagent certaines caractéristiques, la détermination des mesures de moyenne et de dispersion, et l’application des coefficients de pondération issus du sous-processus 5.6 pour le calcul des totaux appropriés.

**Phase Analyser**
#### Valider les résultats (6.2)
C’est au cours de ce sous-processus que les statisticiens valident la qualité des produits obtenus, conformément à un cadre général d’évaluation de la qualité et aux attentes exprimées.

**Phase Diffuser**
#### Mettre à jour les systèmes de diffusion (7.1)
Ce sous-processus gère l’actualisation des systèmes par lesquels les données et métadonnées sont stockées, prêtes à être diffusées.

#### Produire les produits de diffusion (7.2)
Ce sous-processus permet de produire les produits de diffusion afin de répondre aux besoins des utilisateurs.

**Phase Evaluer**
#### Conduire l'évaluation
Ce sous-processus analyse les données d'entrée de l'évaluation, les compare aux résultats de l'analyse comparative attendus/visés (lorsqu'ils sont disponibles) et les synthétise dans un rapport d'évaluation ou un tableau de bord de contrôle.