Bonjour à tous et à toutes,
Il y a un an, je vous avais soumis une proposition de méthodologie concernant les relations entre champs dans les jeux de données tabulaires sujet 3876.
Depuis cette date, une expérimentation a été mise en place (méthodologie, outil, indicateurs) sur le jeu de données IRVE (voir ici la réutilisation IRVE).
Je vous propose ci-dessous une synthèse rapide de ces travaux (permet de faire le lien avec le rapport de la mission data et territoire).
Bonne lecture ! 
Un peu de méthodologie
Un outil nécessaire
Un « schéma de données » est une description d’un jeu de données tabulaires.
Il est composé d’une partie générale concernant le jeu de données dans sa globalité et d’une partie spécifique détaillant chacun des champs du jeu de données (ex. description, exemple, type de données, contraintes).
Cette description est indispensable car elle permet de comprendre ce que contient chacun des champs du jeu de données.
mais non suffisant
Pourtant cette approche n’est pas suffisante car elle ne prend pas en compte ce qui fait la richesse d’un jeu de données tabulaires.
Pour cela, revenons sur les usages d’un jeu de données tabulaires:
On peut distinguer deux usages principaux dans les données tabulaires:
- Un usage de « caractérisation » qui consiste à préciser des propriétés intrinsèques d’une entité. Par exemple, dans un jeu de données concernant des personnes on pourra trouver les champs ‹ nom ›, ‹ prénom ›, ‹ age ›, ‹ taille › qui précisent ce qu’est une personne suivant le point de vue de ce jeu de données
- Un usage de « relations » qui consiste à préciser les relations d’une entité par rapport aux autres entités. Par exemple, pour ce même jeu de données concernant des personnes, on pourra trouver des champs ‹ père ›, ‹ mère ›, ‹ ville ›, ‹ pays ›, ‹ entreprise ›. Le champ ‹ ville › exprimera par exemple le fait que la personne habite la ville indiquée.
Dans les jeux de données, les deux usages sont présents et doivent être explicités pour que les données soient comprises et cohérentes.
Dans l’exemple précédent (qui n’est clairement pas satisfaisant d’un point de vue RGPD !), on pourrait préciser que la donnée du champ ‹ pays › est celle qui correspond au pays de la donnée du champ ‹ ville ›.
Ceci permet de détecter une erreur si on trouve un enregistrement (une ligne) avec ‹ ville › : « paris » et ‹ pays › : « france » et un autre avec ‹ ville › : « paris » et ‹ pays › : « suisse ».
qui doit être complété par un modèle de données
Il existe un outil qui permet de prendre en compte ces différents usages : le « modèle de données ».
Celui-ci explicite à la fois les entités présentes, leurs attributs (caractérisation) et les liens avec les autres entités (les relations).
Si l’on reprend l’exemple, on aura alors une entité ‹ personne › avec plusieurs attributs (‹ nom ›, ‹ prénom ›, ‹ age ›, ‹ taille ›), une entité ‹ ville › avec un seul attribut (son nom), une entité ‹ pays › avec un seul attribut (son nom).
On aura également une relation ‹ habite › entre l’entité ‹ personne › et l’entité ‹ ville › ainsi qu’une relation ‹ appartient › entre l’entité ‹ ville › et l’entité ‹ pays ›.
La relation ‹ appartient › est caractérisée par le fait qu’une entité ‹ ville › n’est liée qu’à une seule entité ‹ pays › et que réciproquement une entité ‹ pays › est liée à plusieurs entités ‹ ville ›.
Quelle application pour l’open-data ?
les jeux de données sont complexes
Les données partagées en open-data ont plusieurs caractéristiques:
- les jeux de données sont majoritairement tabulaires et correspondent à un regroupement de données selon des critères spécifiques (temporel, spatial…),
- les données peuvent être issues de sources multiples avec des producteurs différents,
- les données ont pour vocation d’être réutilisées pour des applications et des usages non définis au préalable.
Les jeux de données sont donc souvent complexes aussi bien dans leur structure que dans leur mode de production et doivent être d’une grande cohérence pour qu’ils puissent être exploitable et utilisables par les « réutilisateurs ».
mais la méthodologie est adaptée
Pour garantir cette nécessaire cohérence une méthodologie adaptée doit être mise en oeuvre.
Le guide « data.gouv » est très clair sur ce point et rappelle dans son chapitre bien documenter un jeu de données les principes à respecter:
La bonne documentation d’un jeu de données recouvre, entre autres :
- une description générale du jeu de données
- une description du mode de production des données
- une description du modèle de données
- une description du schéma de données
- une description des métadonnées
- une description des changements majeurs
Le récent rapport de la mission data et territoires fournit dans son chapitre 3 « Permettre le passage à l’échelle » plusieurs recommandations allant dans le sens d’une méthodologie renforcée :
- Recommandation n°8 : créer une Fabrique des standards, dédiée à l’industrialisation de la standardisation, de leur création à leur appropriation,
- Recommandation n°9 : créer une obligation d’alimentation des référentiels nationaux notamment par le biais de la réglementation, de la commande publique ou par le conditionnement d’aides et de subventions publiques.
- Recommandation n°10 : accompagner la mise en œuvre de nouvelles dispositions réglementaires par leur traduction en standards et schémas de données.
Anatomie d’un exemple
Le cas des IRVE
L’exemple des IRVE (Infrastructure de Recharge des Véhicules Electriques) est intéressant à plusieurs titres :
- le jeux de données est complexe (50 champs, 50 000 lignes),
- le mode de production des données est également complexe (nombreux producteurs, couplage à des dispositions règlementaires),
- il est pris en référence dans le rapport de la mission data et territoires
Il existe déjà des exemples réussis d’alimentation de référentiels nationaux dans le domaine de la santé (base nationale des défibrillateurs automatisés externes) ou de la mobilité (infrastructures de recharge de véhicules électriques). […]dans le second cas, le levier financier (conditionnement de la subvention publique de l’ADEME à l’alimentation du référentiel IRVE) a été utilisé.
Le jeu de données
La documentation du jeu de données « IRVE statique » est structurée et accessible, elle porte aussi bien sur les données que sur le processus de production (voir page spécifique transport.data.gouv).
Le jeu de données mis à disposition est consolidé quotidiennement à partir de fichiers unitaires fournis par des « producteurs ».
La structure des données est définie par un schéma de données précisant le contenu individuel de chacun des champs (mais il est assez difficle à partir de ce schéma de comprendre la structure des données).
Le mode de production consiste à vérifier si les fichiers de données proposés sont conformes au schéma de données. En cas de conformité, les données sont intégrées au jeu de données consolidé et publié le lendemain.
Mesure de la cohérence
Le premier niveau de cohérence est de s’assurer que les données respectent le schéma de données.
Le second niveau de cohérence est de s’assurer que les données respectent le modèle de données (règles d’intégrité). Cependant, malgré sa complexité, le jeu de données ne fait l’objet d’aucun modèle de données formel partagé. Pour évaluer la cohérence des données, la première étape a donc été de reconstruire a posteriori le modèle de données à partir du schéma de données, des données présentes et des informations partagées.
Celui-ci se compose de 5 entités obligatoires (et une facultative):
- PdC (point de recharge): Il correspond à la borne physique sur laquelle on se branche. Le PdC est identifié (clef primaire) par le champ ‹ id_pdc_itinerance › et comporte 11 champs obligatoires (puissance, prise, paiement, accessibilité) et 6 facultatifs. Un PdC correspond à une ligne du fichier IRVE
- Station: Elle regroupe plusieurs PdC et correspond à une gestion électrique commune de ces PdC. Elle est identifiée par le champ 'id_station_itinerance’et comporte 7 champs obligatoires (typologie, horaires, véhicules) et 4 facultatifs
- Opérateur: C’est l’exploitant de la station, il est identifié par un champ ‹ contact_operateur › qui est le seul champ obligatoire
- Enseigne: Structure qui héberge la station, elle est identifiée par un champ unique ‹ nom_enseigne ›
- Localisation: Elle est identifiée par un champ ‹ coordonnesXY › (longitude + latitude) et comporte un champ obligatoire (adresse) et un autre champ facultatif.
Les relations identifiées sur ce modèle de données permettent de définir les principales règles de cohérence du jeu de données:
- Un pdc est unique et associé à une ligne du jeu de données
- Un pdc est intégré dans une et une seule station
- Une station est opérée par un et un seul opérateur
- Une station est hébergée par une et une seule enseigne
- Une station a une et une seule localisation
- Une station a un et un seul « nom_station »
- Une station a une et une seule « implantation_station »
- Une station a un et un seul « nbre_pdc »
- Une station a un et un seule « condition_accès »
- Une station a un et un seul « horaires »
- Une station a un et un seul « station_deux_roues »
- Une localisation correspond à une et une seule « adresse_station »
Les données sont-elles cohérentes ?
L’examen des données montre que les règles de cohérence liées au schéma de données sont toutes respectées (de par leur prise en compte dans l’outil de validation).
Par contre, ce n’est pas le cas des règles « implicites » liées au modèle de données qui ne sont contrôlées ni à la validation initiale des données, ni au niveau des données consolidées.
La mesure de cohérence effectuée sur les données du 31-10-2023 donne les résultats suivants :
nombre d’enregistrements sans erreurs : 48819
nombre d’enregistrements avec au moins une erreur : 8820
taux d’erreur : 15 %
- index - id_pdc_itinerance : 3298
- contact_operateur - id_station_itinerance : 619
- nom_enseigne - id_station_itinerance : 886
- coordonneesXY - id_station_itinerance : 1426
- id_station_itinerance - id_pdc_itinerance : 2320
- nom_station - id_station_itinerance : 913
- implantation_station - id_station_itinerance : 399
- nbre_pdc - id_station_itinerance : 2523
- condition_acces - id_station_itinerance : 26
- horaires - id_station_itinerance : 36
- station_deux_roues - id_station_itinerance : 40
- adresse_station - coordonneesXY : 2678
Ce taux d’erreur de 15 % rend les données difficilement exploitables (cf échanges sur le fil de discussion du jeu de données).
La première cause d’incohérence est liée à la présence de « doublons » (règle n° 1) eux-même liés au processus d’actualisation et de mise à jour des données (les actions menées cet été ont permis de réduire le nombre de doublons mais pas de les éliminer).
Si l’on enlève ces doublons, les résultats sont les suivants:
nombre d’enregistrements sans erreurs : 50530
nombre d’enregistrements avec au moins une erreur : 4996
taux d’erreur : 9 %
- index - id_pdc_itinerance : 0
- contact_operateur - id_station_itinerance : 2
- nom_enseigne - id_station_itinerance : 261
- coordonneesXY - id_station_itinerance : 439
- id_station_itinerance - id_pdc_itinerance : 0
- nom_station - id_station_itinerance : 336
- implantation_station - id_station_itinerance : 120
- nbre_pdc - id_station_itinerance : 2203
- condition_acces - id_station_itinerance : 0
- horaires - id_station_itinerance : 20
- station_deux_roues - id_station_itinerance : 0
- adresse_station - coordonneesXY : 2203
Le taux d’erreur baisse significativement mais reste néanmoins à un niveau élevé (9 %). Le traitement des erreurs résiduelles n’est pas explicité ici mais les principales causes sont identifiées et des corrections pourraient être apportées (le taux d’erreur pourrait alors redescendre à moins de 3 %).
La « réutilisation en lien » accessible sur « data.gouv » fournit le modèle de données, les indicateurs de cohérence, leur évolution au fil des mises à jour et le détail des incohérences identifiées.
Cette mesure d’intégrité ainsi que les principaux problèmes constatés sont partagés avec l’équipe transport pour en déduire des actions correctives.
Conclusion
Même s’il est difficile d’extrapoler à partir d’un exemple unique, voici le retour d’expérience que je tire des travaux réalisés sur le jeu de données IRVE:
La première conclusion est d’ordre méthodologique.
- La description d’un jeu de données sous la forme d’un modèle de données est nécessaire pour exprimer la structure de données. Elle permet aussi bien aux « producteurs » qu’aux « consommateurs » de comprendre les données et la façon de les documenter.
- Les règles de cohérence entre champs (issues du modèle de données) peuvent être ajoutées au schéma de données (cf proposition effectuée auprès de FrictionLess - Issue TableSchema) qui intègre dans ce cas l’ensemble des contrôles à réaliser.
- Une note méthodologique précisant le passage du modèle de données au schéma de données permettrait également de rendre le processus plus robuste.
La deuxième conclusion est d’ordre technique.
- Après plusieurs mois de suivi des données IRVE, force est de constater qu’il est très difficile de corriger des données publiées. Pour garantir un niveau de cohérence satisfaisant des données, il est donc impératif d’intégrer l’ensemble des contrôles de cohérence et d’intégrité en amont (dès l’intégration des données) et dès l’initialisation du jeu de données.
- Pour cela, les outils de contrôle d’intégrité (validés sur l’expérience IRVE) doivent être mis à disposition au sein des outils de validation.
Il est à noter également que la mise en oeuvre de processus « subvention contre données » tels qu’indiqués dans le rapport de la mission data et territoires renforcent ces points.