Dans ce guide, vous apprendrez comment :

Définir la qualité d'un jeu de données

Pour une donnée, la notion de qualité dépend grandement de l'usage qui en est fait.

Les jeux de données publiés sont généralement produits dans un contexte propre à un processus métier et pour un usage particulier. Cet environnement métier n'est pas toujours familier aux tiers, qu'ils soient internes ou externes à l'organisation.

Exemple : La base de données des demandes de valeur foncière est historiquement produite par la Direction générale des finances publiques pour tenir un fichier immobilier et collecter l'impôt.

Les réutilisateurs peuvent alors rencontrer des difficultés lorsqu'ils souhaitent s'approprier des données ouvertes :

• Difficultés dans la compréhension de la structure du jeu de données ;

• Difficultés dans la compréhension des données elles-mêmes ;

• Qualité non adaptée aux usages voulus (mise à jour, documentation insuffisante ou inexacte, etc.).

Il est donc indispensable de prendre en compte les pratiques des réutilisateurs en amont de la production des jeux de données.

Evaluer le niveau de qualité d'un jeu de données

Plusieurs critères permettent d'évaluer le niveau de qualité d'un jeu de données, notamment :

Dans cette section, vous apprendrez comment :

Si les données que vous souhaitez faire circuler ne sont pas structurées sous la forme d'un jeu de données, il est nécessaire de réaliser une extraction des données depuis le système d'information où elles sont stockées. L'extraction permet d'obtenir un jeu de données structuré, qui ordonne les données selon différentes caractéristiques.

Lorsque vous cherchez à extraire des données d'un système d'information, plusieurs situations peuvent se présenter :

1. Un outil permet d'exporter l'ensemble des données depuis le système d'information --> il est nécessaire de sélectionner les données éligibles à la circulation en aval de l'export ;

2. Un outil permet d'exporter l'ensemble des données ou de sélectionner un sous ensemble des données à exporter depuis le système d'information ;

3. Le système d'information ne prévoit pas d'outil d'exportation des données --> il est nécessaire de réaliser une opération technique pour exporter ces données et cette opération est directement liée aux spécificités du système d'information utilisé.

Quel que soit le mode d'export, il est recommandé d'automatiser l'opération afin de faciliter la mise à jour des données publiées. Cette automatisation instaure un processus sur le long terme et fait gagner du temps à l'organisation.

Deux approches sont possibles pour structurer un jeu de données, selon le cas de figure dans lequel la structure se situe :

• Cas 1 : La structure de vos données ne correspond à aucun schéma de données existant : un travail de modélisation est nécessaire en amont de la création du jeu de données.

• Cas 2 : La structure de vos données correspond à un schéma de données existant, comme par exemple s'il s'agit d'une Base Adresse Locale.

Cas 2

Cas 2 : La structure des données correspond à un schéma de données existant

Lexique : Schéma de données

Un schéma de données est un document qui permet de décrire de manière précise et univoque les différents champs et valeurs possibles qui composent un fichier.

Il permet notamment de valider qu’un fichier est conforme à une structure communément partagée, de générer de la documentation automatiquement, de générer des jeux de données d’exemple ou de proposer des formulaires de saisie standardisés.

Ces schémas facilitent la montée en qualité et le croisement des données proposées en open data, surtout lorsque plusieurs producteurs de données sont amenés à produire un même jeu de données.

➡️ Pour plus de détails sur les schémas de données, consultez la section "Maîtriser les schémas de données"

Identifier un schéma de données déjà existant

Il est possible d'identifier un schéma de données déjà existant en consultant le site schema.data.gouv.fr, qui référence une liste de schémas de données existants. Le site offre aussi la possibilité à tout utilisateur de soumettre de nouveaux schémas de données.

Lorsque les données que vous souhaitez faire circuler correspondent à un schéma existant, il est conseillé de l’appliquer au plus près.

Produire des données conforme à un schéma de données identifié

Si les données ne sont pas extraites d’un système d’information mais saisies manuellement, il est possible d'utiliser l’outil publier.etalab.studio qui permet, à partir d’un schéma de données sélectionné, de saisir les valeurs de chaque information et ainsi de produire un fichier exhaustif et conforme.

📖 Tutoriel : Utiliser publier.etalab.studio pour saisir, valider et publier des données de qualité

Cet outil vous permet de créer un fichier CSV en vous assurant qu'il est conforme à un schéma, c'est-à-dire que ses données sont complètes, valides et structurées.

Les étapes à suivre sont les suivantes :

1. Sélectionnez le schéma qui vous intéresse dans la liste déroulante (les schémas disponibles sont ceux référencés sur schema.data.gouv.fr).

2. Produisez vos données. Trois modes de production sont possibles :

   • Téléversez (uploadez) votre fichier si les données sont déjà consolidées au bon format ;

   • Saisissez vos données dans un formulaire à l'aide des descriptions des différents champs et des valeurs d'exemples : les champs indiqués par un astérisque rouge doivent obligatoirement être renseignés au moment de la saisie

     • Une fois votre formulaire valide, les valeurs apparaissent sous la forme d'une ligne dans un tableau récapitulatif

     • Vous pouvez alors choisir d'ajouter une ou plusieurs lignes ou télécharger le fichier CSV correspondant au tableau récapitulatif

   • Saisissez vos données sur un tableur en ligne

3. La conformité de vos données par rapport au schéma choisi est vérifiée/validée. En cas d'erreur de validation, vous pouvez les corriger.

4. Une fois les données conforme au schéma correspondant, publiez-les sur data.gouv.fr grâce à un formulaire de publication simplifié permettant une authentification tierce.

Valider la conformité d’un fichier avec un schéma de données

Pour valider la conformité d'un fichier avec un schéma de données, il est possible de :

• Utiliser la solution Validata : vous pouvez valider la conformité de votre fichier à un schéma parmi la liste déroulante ou via une URL. Vous pouvez ensuite faire valider ce fichier, soit en l'important au format csv, soit en renseignant également son URL.

Sur l'interface d'administration de data.gouv.fr, il est possible d'indiquer que votre fichier correspond à un schéma.

• Lorsque vous déposez ou éditez une ressource, vous pouvez sélectionner le schéma correspondant à vos données dans une liste déroulante.

• Le fait d'indiquer que votre ressource est censée respecter un schéma permet de bénéficier de vérifications de la qualité des données, d'indiquer aux réutilisateurs que vos données respectent un référentiel, ainsi que de contribuer aux fichiers agrégés (i.e. pour les données IRVE).

D'autres solutions en dehors de data.gouv.fr existent : des solutions disponibles en anglais comme goodtables.io ou CSV Lint proposent des validateurs de jeux de données.

Il est aussi possible d’intégrer une fonction de validation d’un jeu directement dans la procédure de publication (exemple : les données d’adresses locales qui font l’objet d’une validation directement sur le site adresse.data.gouv.fr).

Respecter le schéma de données

Les Bases Adresses Locales correspondent à un schéma de données établi. Il est conseillé de le suivre au plus près. Le respect de ce schéma garantit une intégration réussie des Bases Adresses Locales dans la Base Adresse Nationale.

Une seule Base Adresse Locale est publiée par commune.

Suivre les bonnes pratiques

• voie_nom, numero, suffixe : le nom de la voie et de son complément sont rédigés en toutes lettres, en minuscules accentuées, la première lettre de la voie et du nom seulement étant écrites en majuscules. Le complément est réservé aux hameaux et lieux-dits historiques. Il est conseillé de limiter le champ suffixe aux indices de répétition du type bis, ter.

• cad_parcelles : la commune délivrant un certificat de numérotage associe une numérotation à une parcelle. Le registre de filiation parcellaire de DGFiP, disponible en open data, permet de connaître les parcelles associées à une adresse.

• Voies sans adresse : le numéro attendu pour les voies sans adresse est 99999.

• Mettre à jour vos données !

Pour aller plus loin, un guide des bonnes pratiques de l'adressage ("Comment constituer et établir une adresse ?") est disponible. Il détaille les règles et les normes en vigueur.

Exemple : Mon jeu de données est une liste d'actions culturelles menées par ma région. Certaines de ces actions sont gérées par des associations. Il peut être intéressant de publier un jeu de données recensant ces actions avec un champ correspondant à l'identification des associations. Cet identifiant existe et est standardisé, il s'agit du numéro RNA, identifiant national des associations dont le répertoire est opéré par le ministère de l'intérieur.

Pourquoi intégrer des données pivots dans un jeu de données ?

L'intégration dans un jeu de données de données pivots qui correspondent à un référentiel présente plusieurs avantages :

• Une meilleure formalisation : en se basant sur un référentiel, le producteur de données a l'assurance d'utiliser un format de données standard et partagé par un grand nombre de jeux de données ;

• Une meilleure synthèse : en se basant sur un référentiel, le producteur évite l’abondance de détails et va à l’essentiel. L’obtention d’informations complémentaires se fera par le biais de la consultation du référentiel lui-même ;

• Une meilleure compréhension : en intégrant dans son jeu de données des données correspondant à un référentiel, le producteur facilite la compréhension de celui-ci par les utilisateurs car il se réfère à un standard largement adopté ;

• Une meilleure réutilisation : intégrer des données liées à un référentiel facilitera la réutilisation du jeu de données et permettra son enrichissement avec d'autres données partageant la même donnée pivot ;

• Une meilleure interopérabilité : intégrer des données pivots facilite le lien avec des données de référence fiables et à jour.

Quels référentiels utiliser pour intégrer des données pivots ?

Voici une liste non exhaustive de référentiels sur lesquels il est possible de s'appuyer pour l'intégration de variables pivots :

Le service public de la donnée

Le service public de la donnée (SPD) vise à mettre à disposition avec un haut niveau de qualité les jeux de données de référence qui présentent un fort impact économique et social.

À ce jour, 9 jeux de données ont été identifiés comme des données de référence :

Exemple : Afin de lister l'ensemble des actions culturelles de ma région, nous avons vu que le numéro RNA pouvait être utile pour identifier les associations. Grâce à celui-ci, il est également possible de récupérer le numéro SIRET de l'association si celle-ci en possède un. Il est également possible de détailler dans le jeu de données le code commune et le code département de chaque action. Pour cela, il convient de se référer au Code officiel géographique. Attention à bien respecter celui-ci. Par exemple, le code département de l'Ariège est le "09" et pas le "9". Ce type d'erreur pourrait entraîner des difficultés lors de la réutilisation des données.

Autres référentiels

Des jeux de données standardisées et communément partagées avec le plus grand nombre peuvent aussi être utilisés comme référentiels.

Exemple : L'identifiant unique d'une certification professionnelle est le numéro RNCP. Ce jeu de données ne fait pas partie du service public de la donnée mais est largement partagé par les acteurs du domaine de la formation professionnelle.

Référentiels métiers

Référentiels techniques

Les référentiels techniques n'ont pas de significations métiers mais ils permettent de décrire une donnée de manière standardisée. Ces standards permettent aux utilisateurs et aux algorithmes de pouvoir interpréter automatiquement la donnée de manière correcte.

Voici deux exemples de référentiels techniques :

Partager ses propres référentiels

Les acteurs sont encouragés à mettre en place leurs propres référentiels internes ou à les partager s'ils existent déjà pour favoriser au mieux le partage et l'interopérabilité des données.

Il est pertinent de diffuser, en même temps qu'un jeu de données, la liste des valeurs possibles correspondant à votre propre référentiel métier. Celui-ci sera connu et potentiellement réutilisé par d'autres acteurs.

La mise en place de référentiels fait partie d'une stratégie de montée en qualité de la donnée. Néanmoins ce n'est souvent pas suffisant : il est ensuite nécessaire de diffuser, former et vérifier que les données produites intègrent ces référentiels et n'en dérivent pas (à partir d'un contrôle humain ou de tests automatiques).

Exemple : J'utilise en interne un numéro unique permettant d'identifier chaque type d'action culturelle (arts du spectacle, cirque, arts plastiques...). Il peut être pertinent de diffuser en parallèle à la diffusion de mon jeu de données la liste de mon référentiel. Des communes de ma région pourraient potentiellement le réutiliser pour décrire leurs actions culturelles à une maille plus fine.

Comment intégrer des adresses dans un jeu de données ?

Il existe des référentiels pour décrire une adresse de manière unique.

Le référentiel officiel d'adresse est la Base Adresse Nationale (ou BAN).

• Si vous partez de zéro pour constituer un jeu de données --> il est pertinent de partir de la Base Adresse Nationale pour décrire vos adresses.

• Si vous travaillez sur un jeu de données qui contient déjà des adresses saisies --> il peut s'avérer fastidieux de corriger manuellement l'ensemble des adresses erronées et vous pouvez obtenir une base d'adresse normalisée grâce à la méthode décrite ci-dessous.

Le géocodage

Le géocodage peut être en partie automatisé grâce à des outils proposés par Etalab.

Le site https://adresse.data.gouv.fr/ permet de géocoder une liste d'adresse via un appel à une API ou par le dépôt de fichier csv.

Il permet aussi, à partir d'un jeu de données contenant des adresses déjà saisies, de retourner un jeu de données enrichi :

• de coordonnées géographiques (longitude/latitude) ;

• des adresses « corrigées » récupérées de la BAN.

Le site adresse.data.gouv.fr est limité à des utilisations ponctuelles et des volumétries de données considérées faibles (moins d'un million de lignes).

Pour géocoder davantage de données (plusieurs millions de lignes), il est recommandé d'installer votre propre environnement de géocodage, en utilisant par exemple le géocodeur Addok. Des ressources sont disponibles sur GitHub pour vous aider dans l'installation de votre environnement.

Quelle que soit la méthode utilisée, le processus de géocodage retournera une liste d'adresses standardisées avec leurs coordonnées géographiques associées. Il donne aussi accès à une information geo_score correspondant au score de confiance que le géocodeur accorde à l'adresse retournée. Cet indicateur peut être utile à garder dans un jeu de données final, il donnera une indication aux utilisateurs sur la performance du géocodage de chaque adresse.

Dans cette section, vous apprendrez comment :

Description générale du jeu de données

Il est conseillé de commencer la documentation par une description synthétique du jeu de données qui donne un aperçu rapide des informations mises à disposition.

La description générale peut couvrir les points suivants :

• Une description générale des données ;

• La liste des fichiers mis à disposition ;

• La description du format des fichiers ;

• La fréquence de mise à jour.

Exemple : Description générale du jeu de données du Répertoire national des élus

Description du mode de production des données

La structure d'un jeu de données et son contenu sont liés au contexte de production des données. La description de l'environnement métier est donc indispensable.

La description du mode de production du jeu de données permet au réutilisateur de comprendre la structure du jeu, la nature des données et les possibles manques ou incohérences du fichier.

Il est donc conseillé de préciser :

• comment les données ont été produites (saisie manuelle, collecte automatique, etc.) ;

• qui sont les acteurs producteurs des données et si les données sont produites par plusieurs acteurs, le modèle de gouvernance mis en place pour centraliser les données ;

• si les données sont exhaustives et si elles présentent des limites dans leur qualité ;

• les points d'attention et précautions d'usage pour manipuler ces données.

Description du modèle de données

Exemple : Dans le jeu de données des IRVE (infrastructures de recharge des véhicules électriques), on peut identifier que:

• les champs "id_station_itinerance" et "nom_station" correspondent à des attributs d'une même entité "station",

• les champs "id_pdc_itinerance" et "puissance nominale" correspondent à des attributs d'une même entité "point de charge".

Une "station" contient un ou plusieurs "point de charge" (relation entre les deux entités).

Il est conseillé de :

• Faire apparaître le modèle de données à l’aide de schémas et de tableaux

• Si le jeu de données se compose de plusieurs entités, faire apparaître les relations entre elles.

Une fois le modèle établi, il convient de définir le découpage en fichiers. Il est possible de :

• regrouper des entités dans un même fichier

• créer un fichier par entité

Exemple : La documentation du jeu de données des opérations de sauvetage en mer décrit le modèle de données utilisé. Ce modèle de données permet de comprendre rapidement les relations qui unissent les différentes entités du jeu de données. Dans cet exemple, il a été choisi d'associer un fichier par entité.

Description du schéma de données

Si vous publiez des données tabulaires, il est conseillé de produire un tableau récapitulatif indiquant, pour chaque colonne :

• le nom de la colonne

• son type de données (entier, chaîne de caractères, nombre décimal, etc.)

• la description de la donnée contenue dans cette colonne

• une ou plusieurs valeurs d’exemple

Cela constituera une base solide en vue de la création d'un schéma de données, dont le processus est détaillé ici.

Exemple : La documentation du jeu de données des opérations de sauvetage en mer présente un tableau récapitulatif des différentes colonnes. La description des champs permet de faire le lien avec le fichier de données, ce qui facilite la lecture des données.

Les termes employés dans un jeu de données sont propres à un environnement métier.

S’il existe des termes complexes ou des énumérations, il est conseillé de :

• Fournir un lexique de ces valeurs

Cet effort de définition fait gagner un temps considérable au réutilisateur et permet de prévenir des contre-sens dans l’exploitation des données.

Exemple : La base de données de demande de valeur foncière recense l’ensemble des transactions immobilières intervenues au cours des cinq dernières années. Le vocabulaire utilisé dans ce jeu de données est issu d’un environnement administratif, parfois difficile à appréhender. La Direction générale des Finances publiques met à disposition une documentation qui comprend notamment un lexique de définition des termes rencontrés. Ce lexique facilite l’appropriation et la réutilisation des données par des acteurs tiers.

Description des métadonnées

Des formats standards de métadonnées existent afin de faciliter leur collecte, leur recherche et leur traitement automatique.

Sur data.gouv.fr, il est possible de renseigner directement les métadonnées d’un jeu de données. Les métadonnées retenues sont les suivantes :

• Titre

• Sigle

• Description

• Licence

• Fréquence de mise à jour

• Mots clés

• Couverture temporelle

• Couverture spatiale

• Granularité spatiale

• Mode brouillon

La description des métadonnées apportera à un jeu de données une meilleure visibilité sur les catalogues.

Description des changements majeurs

En pratique, il est souhaitable que le modèle de données et la nature de vos données n’évoluent pas au fil du temps.

Toutefois, des changements dans la structure des données, dans le mode de collecte ou dans les dispositions réglementaires peuvent affecter le jeu de données.

Dans cette situation, il est conseillé de tenir une liste de ces changements

Cette liste peut faire figurer :

• la date

• la version des données (si vous versionnez vos données)

• la nature du changement

Si nécessaire, il est possible d’indiquer des liens, comme par exemple lorsque des changements sont introduits par une modification du code de transformation des données.

Exemple : La documentation du jeu de données des opérations de sauvetage en mer comporte une section “Changement sur le jeu de données”. Cette section référence les changements du jeu de données en renseignant les informations suivantes :

• La date du changement

• La nature du changement

• Les liens associés au changement

Points de contact

Les réutilisateurs des données peuvent avoir des questions à propos des fichiers mis à disposition.

Il est conseillé de proposer un espace d’échange entre les producteurs et réutilisateurs des données : il est préférable que cet espace d’échange soit public afin qu’il puisse bénéficier aux personnes qui auraient des questions similaires.

La collecte des retours d’usage permettra d’améliorer votre documentation de manière incrémentale.

Il est conseillé de proposer votre documentation en ligne et non sous format PDF : une documentation en ligne permet de s’assurer que les réutilisateurs des données disposent toujours de la version la plus à jour.

Des portails de données, tels que data.gouv.fr, proposent des espaces dédiés à la documentation du jeu de données.

Vous pouvez également héberger votre documentation sur des sites web statiques.

Si le jeu de données a pour vocation de circuler en interne de votre organisation, nous vous conseillons a minima de proposer une documentation dans un fichier séparé des données :

• Le fichier contenant les données doit être réservé à la manipulation de ces dernières ;

• Le fichier contenant la documentation a lui pour vocation d’informer sur la nature des données et sur la structure des fichiers.

Exemple : Dans le cadre de la publication des données de sauvetage en mer (opérations coordonnées par les CROSS), un site statique a été créé afin de présenter la documentation du jeu de données.

Dans cette section, vous apprendrez comment :

Un score de qualité des métadonnées a été mis en place sur data.gouv.fr pour répondre principalement à deux problématiques :

• Les réutilisateurs de données peinent à identifier les jeux de données de qualité et à évaluer si tel ou tel jeu de donnée est digne d’intérêt ;

• Les producteurs de données ne sont pas suffisamment incités et accompagnés à améliorer la qualité de leurs données.

Grâce à ce score de qualité des métadonnées, il est possible d'identifier les axes sur lesquels travailler pour améliorer la qualité de vos données.

🧭 Les critères sont les suivants :

Ce score est encore en phase d’expérimentation :

• Le poids de chaque critère sera ajusté en fonction de vos retours ;

• De nouveaux critères seront ajoutés progressivement notamment pour intégrer la notion de schéma de données.

Bien souvent, la qualité de données que vous proposez, bien qu'adaptée aux utilisations internes à votre structure, peut être améliorée pour les usages nouveaux engendrés par l'ouverture, qu'il s'agit alors de mieux connaître.

Suivre et mesurer les usages d'un jeu de données

Il est possible de combiner approches quantitatives et qualitatives pour cerner les usages d'un jeu de données.

Selon les moyens disponibles, plusieurs leviers sont disponibles :

• Mesurer les volumes d'usage : en suivant les métriques des jeux de données publiés proposés par data.gouv.fr ou sur son propre portail (nombre de consultations, nombre de téléchargements, nombre de réutilisations, etc.).

• Répondre aux commentaires et aux questions soumis sur data.gouv.fr, dans lesquels les réutilisateurs font régulièrement remonter leurs besoins. D'après l'analyse réalisée par des étudiantes et des étudiants de l'Université Bordeaux Montaigne, sur data.gouv.fr, de nombreux commentaires peuvent être catégorisés comme relevant de problématiques d'accessibilité, suivie de celles d'actualisation des données puis des questions de fiabilité et d'exploitabilité des données.

• Suivre les réutilisations ajoutées sur ses jeux de données sur data.gouv.fr et inciter au référencement.

• Réaliser des enquêtes auprès des réutilisateurs.

• Animer des communautés de réutilisateurs, notamment en organisant régulièrement des ateliers de discussions entre producteurs et réutilisateurs ou en proposant un espace d'échange en ligne.

• Réaliser des entretiens avec les principaux réutilisateurs.

Pour être en capacité d'améliorer la qualité des données en continu, il convient d'adapter sa stratégie organisationnelle. Il est notamment conseillé de :

• Identifier une personne coordinatrice de la démarche d'ouverture des données : elle a pour mission de publier les jeux de données, de s'assurer que leurs mises à jour sont effectuées et d'animer la vie des jeux de données sur la plateforme (répondre aux commentaires, etc.). La personne coordinatrice travaille en lien direct avec les équipes métiers afin de comprendre les problématiques techniques.

• Elaborer un processus de rétroaction : lors de l'exploitation des jeux de données, les réutilisateurs peuvent identifier des anomalies ou des problèmes de qualité ou encore proposer des améliorations. Il est nécessaire d'instaurer un canal de rétroaction afin d'intégrer ces remarques dans les processus métiers et ainsi améliorer la qualité des jeux de données.

Dans cette section, vous apprendrez à réaliser l'ensemble des étapes du cycle de vie de la donnée ouverte de qualité, notamment :

Ce guide sur les schémas de données résulte d'une co-rédaction entre les équipes d'Etalab et d'OpenDataFrance. Il s'inspire du contenu rédigé par de nombreux partenaires, listés par ordre alphabétique :

• Charles Nepote

• Datactivist

• La FING

• OpenDataFrance

Merci à eux !

La production de données en conformité avec un schéma de données existant présente de nombreux bénéfices :

• Croisement : les données créées peuvent être facilement croisées avec d’autres données conformes au schéma de données utilisé ;

• Intéropérabilité : l’interopérabilité des données et leur croisement est simplifié ;

• Facilité d'agrégation : si le jeu de données créé est une agrégation de plusieurs fichiers produits par différents acteurs, la formalisation et le partage d’un schéma de données facilite le travail d’agrégation des données --> ce schéma devient un standard pour votre communauté ;

• Pérennité : la formalisation d’un schéma de données assure une pérennité des fichiers dans le temps ;

• Documentation : la documentation d’un schéma de données existant est déjà rédigée et accessible ;

• Ouverture : la présence d'un schéma de données existant peut faciliter l'ouverture des données, les producteurs ayant directement une procédure claire à suivre ;

• Qualité : la conformité d'un fichier vis à vis d'un schéma de données, qu'il est possible de vérifier, permet de valider un premier niveau de qualité.

Il est aussi possible de générer des jeux de données d’exemple ou de proposer des formulaires de saisie standardisés.

La création d'un schéma de données se décompose en 4 phases :

1. Investigation : envisager de créer un schéma de données ;

2. Concertation : rassembler plusieurs parties prenantes pour créer un schéma de données ;

3. Construction : implémenter le schéma de données obtenu après la phase de concertation ;

4. Maintien et promotion : faire la promotion d'un schéma auprès d'autres parties prenantes et le faire évoluer si besoin.

Dans cette section sont proposés pour chaque phase un processus à suivre, des bonnes pratiques et des outils.

Marche à suivre

Pour déterminer s’il est nécessaire de créer ou non un schéma de données, il est recommandé de suivre les étapes suivantes :

1. Lire attentivement les différentes sections de ce guide ;

2. Organiser une réunion réunissant des acteurs métiers, techniques et de potentiels réutilisateurs : vous débattrez de la pertinence de la création de votre schéma de données ;

3. Référencez votre schéma pour entrer en contact avec les équipes d'Etalab et leurs partenaires et bénéficier de conseils pour sa création, d'une visibilité accrue et d'une assistance d'experts.

Exemples d'illustration

✅ Situations favorables à la création d’un schéma de données

Exemple 1 : Le ministère chargé des transports souhaite consolider une base nationale des lieux pouvant servir de points de covoiturage. Les collectivités territoriales sont en charge de la création, du recensement et de l'aménagement de ces lieux.

--> Il est pertinent de créer un schéma de données car un grand nombre de producteurs de données doivent produire des données dans un format homogène. Un schéma facilitera la diffusion des prérequis, permettra la validation des données et facilitera l’agrégation nationale.

Exemple 2 : L’INSEE souhaite diffuser le Code Officiel Géographique. Il rassemble des données sur des communes, des cantons, des arrondissements, des départements, des régions et des pays. Ce fichier est actualisé tous les ans.

--> Il est pertinent de créer un schéma car ces données sont des données de référence. Un grand nombre de réutilisateurs est susceptible d’utiliser ces données. Il est primordial que ces réutilisateurs aient accès à une documentation de qualité, que la structure des fichiers des données reste stable dans le temps et que les données publiées soient de bonne qualité.

Le cas des schémas de données en interne Bien qu’il ne paraisse pas nécessaire dans certaines situations de créer et de diffuser un schéma, vous pouvez choisir de le faire. En effet, les schémas de données comportent de nombreux avantages (documentation, montée en qualité, réutilisations, etc.) qui sont bénéfiques, même lorsque les données sont utilisées uniquement en interne.

❌ Situations dans lesquelles la création ou la diffusion d'un schéma de données ne semble pas nécessaire

Une administration centrale diffuse des statistiques d’activité d’un bureau, en open data, de manière annuelle.

--> Avec ces seules informations, il ne semble pas nécessaire de créer un schéma : il n’y a qu’un seul producteur et le potentiel de réutilisation semble limité.

Points de sortie

À l’issue de cette phase, vous devriez :

• Connaître les schémas de données ;

• Être en mesure de décider si votre projet requiert la création d’un schéma de données ;

• Savoir si votre schéma de données devra être référencé à terme sur schema.data.gouv.fr.

Spécifier un schéma de données

Pour spécifier un schéma de données, il est nécessaire de définir :

• les champs ;

• les types associés de ces champs (une date, un nombre, une chaîne de caractère, etc.) ;

• les contraintes de chaque champ (entier positif, texte dans une liste fermée, etc.) ;

• la description de chaque champ ;

• une documentation associée au schéma de données décrivant le contexte, les acteurs, les cas d’usage.

Pour obtenir ce résultat, il peut être utile de réaliser au préalable un modèle de données qui présente la structuration des informations. La modélisation ne prend pas en compte les contraintes d'implémentation, elle est un outil de dialogue entre les différents intervenants.

Organiser la collaboration entre les différentes parties prenantes autour d'un schéma de données

Il est conseillé de :

• travailler sur un document partagé, accessible en ligne, tel qu'un Framapad ou Google Doc : l'important est que plusieurs contributeurs puissent contribuer (modifier ou mettre des commentaires) sans avoir besoin d'être présents physiquement ou de recevoir des versions intermédiaires par email.

• en complément du document partagé, organiser plusieurs réunions afin de débattre du schéma de données à produire (et de l'éventuel modèle de données construit).

• impliquer une multitude d'acteurs : vous devez rassembler des producteurs, experts métiers, experts techniques et réutilisateurs. La richesse des profils et des enjeux permettra d’aboutir à la solution la plus adaptée.

Construire un schéma de données de qualité

Pour construire un schéma de données de qualité, il est conseillé de :

• Construire un modèle de données. Il est important de disposer d'un outil visuel qui présente les entités "métier" mais surtout les dépendances et relations entre ces "entités". Ce modèle peut être enrichi de tous les attributs nécessaires au fur et à mesure de la concertation.

• Profiter de l’existant. De nombreux standards existent déjà, qu’ils concernent des formats de données ou des formats de champs. Certains standards sont devenus incontournables aujourd’hui, comme ISO-8601 pour les dates ou WGS 84 pour les coordonnées géographiques.

• Identifier et associer l’écosystème. Les personnes/organisations que vous associez sont la meilleure garantie d’un schéma de données efficace et largement adopté, permettant d'aboutir à un véritable standard :

• D'un côté les producteurs, qui connaissent la réalité de leurs données, de la collecte, etc. et qui ont leurs propres usages.

• De l'autre les réutilisateurs, avec leurs besoins et leurs difficultés, qu’ils soient déjà connus, « sous le radar » ou en devenir.

• Prendre le temps. Un schéma de données est susceptible de concerner beaucoup de producteurs et d’usagers. Sa modification peut avoir un impact important. Il est donc crucial de prendre le temps d’obtenir tous les retours avant de publier un schéma utilisable par le plus grand nombre. Un schéma de données devrait être publié quand il est prêt, non pas en fonction d’un impératif de délai.

• Lever les implicites et les ambiguïtés. Toutes les spécifications d’un schéma de données doivent être les plus claires possibles, y compris pour des cas/données qui n’existent pas encore mais pourraient apparaître à l’avenir.

• Éviter la redondance mais sans l’exclure absolument. Trois champs pour définir une latitude et une longitude (latitude, longitude, lat-lon) est inutilement redondant. Toutefois, préciser le nom d’une commune en plus de son code INSEE rend les données plus faciles à lire et à exploiter.

• Utiliser des données pivot relevant d’un référentiel ouvert pour relier les données à d’autres données, par exemple l’utilisation du numéro SIREN pour identifier des organisations. Ce principe permet aussi d’éviter l’abondance de détails et d’aller à l’essentiel : l’obtention d’informations complémentaires se fera par le biais d’un autre référentiel.

Points de sortie

À l’issue de cette phase, vous devriez :

• Avoir réuni différents partenaires afin de collaborer sur votre schéma de données ;

• Avoir décidé des différents champs de votre schéma de données, leurs types et définitions et produit une documentation associée.

Choisir un standard technique pour la description d'un schéma de données

Il existe plusieurs standards techniques pour les schémas de données.

Le standard est à choisir en fonction :

• de la nature des données concernées ;

• des habitudes de l’écosystème produisant ou réutilisant les données liées au schéma.

Les principaux standards techniques sont les suivants :

• Table Schema : adapté pour la description de données tabulaires (sous forme de tableurs ou de CSV). Ce standard technique utilise le format JSON. NB : il est possible de contraindre les colonnes avec des formats spécifiques et des corrélations ;

• JSON Schema : adapté pour la description de données avec une notion de hiérarchie. Ce standard utilise le format JSON ,

• XML Schema Definition (XSD) : adapté pour la description de données avec une notion de hiérarchie. Ce standard utilise le format XML.

Tous ces standards techniques sont supportés par schema.data.gouv.fr.

Créer un schéma de données

Une fois un standard technique choisi, il faudra créer les fichiers requis pour modéliser les données.

La documentation de chaque standard technique décrit le contenu des fichiers à renseigner. Reportez-vous aux documentations respectives pour tirer parti des fonctionnalités avancées offertes : types de données et contraintes sur les valeurs en particulier.

Il est possible de vérifier qu’un fichier correspond à un standard à l’aide d’outils en ligne ou en ligne de commande. Utilisez ces outils pour vérifier que vos productions correspondent au standard.

Documenter un schéma de données

En complément du fichier du schéma de données, il est recommandé de rédiger a minima deux documents complémentaires :

• Une documentation générale qui indique le contexte, les modalités de production des données, le cadre juridique, la finalité, les cas d’usage etc. Ce fichier est traditionnellement rédigé en Markdown et nommé README.md ;

• Un fichier répertoriant les changements permettant de suivre les modifications, d’une version à une autre. Ce fichier est traditionnellement rédigé en Markdown et nommé CHANGELOG.md.

La présence de ces fichiers représente un package complet (documentation, liste des changements et schéma de données décrit dans un standard technique), apprécié des réutilisateurs. schema.data.gouv.fr se repose sur ces éléments pour intégrer votre documentation et votre liste de changements sur une page web.

Exemple : La documentation et la liste des changements du schéma des lieux de stationnement.

Publier et diffuser un schéma de données

Une fois votre schéma de données créé, il est nécessaire de le publier et de le diffuser pour que d’autres personnes puissent en bénéficier.

Il est recommandé de publier vos schémas de données en tant que logiciels libres, sur votre forge de développement ou par le biais de GitLab ou GitHub.

Vous bénéficierez alors des avantages habituels des dépôts de code Git en ligne :

• Historique des modifications

• Fonctionnalités de tickets

• Demandes de modifications.

• etc.

Il est conseillé d'utiliser un compte d’organisation (dédié à votre entreprise, direction, service, ministère) et non un compte personnel afin d’assurer une URL stable dans le temps.

Exemples à votre disposition : Plusieurs dépôts Git de schémas sont disponibles sur schema.data.gouv.fr (exemple : le dépôt Git décrivant les lieux de stationnement à l’aide d’un schéma TableSchema sur GitHub).

Pour faciliter la découverte de votre schéma de données et des données sous-jacentes, il est recommandé de le faire référencer sur schema.data.gouv.fr. La marche à suivre est détaillée ici.

Points de sortie

À l’issue de cette phase, vous devriez :

• Avoir implémenté votre schéma de données dans un des standards reconnus ;

• Avoir publié votre travail en ligne, dans un répertoire Git dédié ;

• Avoir pris contact avec les équipes de schema.data.gouv.fr dans le but de référencer votre schéma de données si nécessaire.

Promouvoir un schéma de données

De nouveaux acteurs peuvent vouloir publier des données qui rentrent dans le cadre de votre schéma, mais peuvent ne pas en avoir connaissance, ou ne pas avoir les compétences techniques pour se l'approprier.

Pour faciliter l'adoption d'un schéma de données, il est possible de :

• diffuser ses travaux à ses partenaires et au grand public, sur ses réseaux sociaux ou newsletters, pour mettre en valeur sa proactivité et susciter de l'intérêt ;

• utiliser son réseau de connaissances pour inciter d'autres parties prenantes à publier leurs données, par exemple via la plateforme publier.etalab.studio, que ce soit sous son schéma ou dans d'autres domaines, qui pourront donner lieu à d'autres schémas ;

• aider des acteurs souhaitant utiliser son schéma, en leur faisant bénéficier de son expérience, par exemple en leur répondant directement dans les commentaires sur data.gouv.fr ;

• interagir avec les réutilisateurs afin de mieux cerner leurs besoins, des améliorations possibles ou des champs d'investigation.

Des scripts ont été mis au point par les équipes d'Etalab pour permettre de vérifier et d'agréger toutes les données publiées par type de schéma et ainsi créer des fichiers consolidés à l'échelle nationale (i.e. données IRVE). Cela permet à des solutions à grande échelle d'émerger.

Maintenir un schéma de données

Aussi exhaustive qu'ait été la phase de concertation, il est probable que des corrections ou des évolutions du schéma soient nécessaires afin de le rendre plus précis ou plus accessible par exemple.

Clarifications de la documentation, corrections d’erreurs, évolutions du cadre réglementaire, etc. sont autant de raisons où il est indispensable de mettre en œuvre une nouvelle version.

schema.data.gouv.fr récupère le contenu de votre dépôt via des releases de celui-ci, c'est à dire des versions packagées de votre code (schéma + documentation). Avec ce système, il est alors possible pour schema.data.gouv.fr de suivre l'évolution formelle de votre schéma et d'en référencer les différentes versions au cours du temps. Cela permet également aux contributeurs de considérer les branches du dépôt Github qui héberge le schéma (main ou autre) comme un espace de développement participatif qui reste dissocié du référencement sur schema.data.gouv.fr tant qu'une nouvelle version n'est pas publiée.

Une fois que l'état de votre branche principale, main par exemple, vous conviendra, vous pourrez sur Github ou Gitlab créer une release. Pour cela, il suffit d'ajouter un tag et une version correspondant à la nouvelle version que vous souhaitez publier. Celle-ci sera par la suite automatiquement récupérée par schema.data.gouv.fr et publiée (généralement sous 24h).

Si un schéma que vous maintenez doit être modifié, la marche à suivre peut être la suivante :

1. faire une nouvelle phase de concertation afin d'évoquer les problématiques qui imposent un changement et de trouver la solution la plus adaptée. Si vous n'avez pas d'espace pour cela, nous vous conseillons de publier une issue sur le dépôt Github de schema.data.gouv.fr.

2. lorsqu'un accord est trouvé, mettre à jour techniquement le schéma lui-même (cf. le paragraphe ci-après);

3. mettre à jour la documentation du schéma ;

4. déployer les mises à jour sous un nouveau tag de version ;

5. communiquer sur cette mise à jour.

Lorsque les modifications à faire à un schéma font consensus, il est nécessaire de les implémenter et de déployer une nouvelle version. La marche à suivre peut être la suivante :

1. répertorier tous les changements à faire avant de les implémenter : anticiper l'impact sur les fichiers techniques et sur la documentation (notamment l'incrémentation de la version)

2. faire les modifications listées à l'étape précédente :

   • en local, puis pousser les changements avec les commandes git (add, commit et push)

   • ou directement sur Github

3. créer une release (nouvelle version) :

   • sur la page Github de votre schéma, cliquer sur X tags (à côté des branches) : ici sont listées toutes les versions du schéma

   • cliquer sur Releases puis Draft a new release

   • indiquer le nom de la nouvelle version dans Choose a tag : par exemple si la version actuelle est v1.0.1, la nouvelle sera v1.0.2 (dans certains cas, il sera opportun de passer en 1.1.1 ou en 2.0.1)

   • la branche cible (target) doit être la branche principale, si des développements ont été faits sur d'autres branches, il est nécessaire de les fusionner - merge - avec la branche principale via une pull request (après validation des modifications)

   • documenter la nouvelle version : ajouter un titre et une description exhaustive des changements dans les champs dédiés, juste avant la publication

   • publier la release (Publish release)

Que ce soit pour des considérations techniques ou "conceptuelles", il est possible de solliciter les équipes de schema.data.gouv.fr qui pourront vous accompagner dans le processus de mise à jour de votre schéma.

Points de sortie

À l’issue de cette phase, vous devriez :

• Comprendre l'importance de la proactivité dans la promotion, la diffusion et le maintien d'un schéma ;

• Avoir des pistes d'actions concrètes pour porter un schéma auprès d'autres parties prenantes ;

• Savoir pourquoi, quand et comment mettre à jour un schéma de données.

Qui peut référencer des schémas de données ?

Tout acteur est libre de proposer le référencement de schémas sur schema.data.gouv.fr : administration, entreprise privée, association, citoyen, etc.

Quels schémas de données sont acceptés ?

Schémas de données acceptés sur schema.data.gouv.fr

• Des schémas de données décrivant des données publiques.

• Des schémas de données décrits par un standard technique (cf. page "Phase de construction") : les schémas de données décrits uniquement par de la documentation textuelle ou des tableaux ne sont pas acceptés.

Prérequis de validation des schémas de données sur schema.data.gouv.fr

Pour tous les types de schéma de données, il faut que :

• le schéma de données soit sur un dépôt Git, à raison d’un dépôt par schéma. Ce dépôt doit pouvoir être cloné depuis Internet sans authentification préalable ;

• le dépôt Git doit comporter des tags indiquant les versions du schéma de données. Ces versions doivent respecter la gestion sémantique de version semver, sous la forme 1.3.2 par exemple ;

• le dépôt doit comporter un fichier README.md à la racine contenant une documentation du schéma de données indiquant par exemple le contexte de production, la gouvernance ;

• passer avec succès les tests spécifiques au type de schéma de données que le dépôt contient.

Etalab se réserve le droit de refuser le référencement de schémas en motivant son refus. Il est encouragé d'initier une discussion préalablement à l’ouverture d’une pull request.

Quand référencer un schéma de données ?

Il est recommandé de référencer un schéma de données le plus tôt possible, dès la phase d’investigation.

En référençant celui-ci en amont, vous bénéficierez de l’accompagnement d’Etalab et de partenaires tout au long de la création de votre schéma de données : de l'investigation au référencement sur schema.data.gouv.fr.

Comment référencer un schéma de données ?

Pour référencer un schéma de données, vous pouvez :

• ouvrir un ticket sur GitHub

• entrer en contact avec notre équipe par e-mail

Une page dédiée détaille la procédure.

Une liste de schémas de données actuellement en phase d'investigation ou de construction est tenue à jour sur cette même page.

--> La marché à suivre est détaillée ici.

Une fois qu'un schéma est finalisé et référencé sur schema.data.gouv.fr, il est temps de produire des données conformes à ce schéma.

data.gouv.fr propose de multiples intégrations avec schema.data.gouv.fr permettant de spécifier qu'une ressource présente sur data.gouv.fr est censée être conforme à un schéma.

Il est ensuite possible de procéder à la validation de la ressource par rapport au schéma ou de consulter la documentation du schéma à partir de la page d'un jeu de données.

Il est possible d'indiquer qu'une ressource d'un jeu de données correspond à un schéma depuis l'interface d'administration de data.gouv.fr.

• Lorsque vous déposez ou éditez une ressource, vous pouvez sélectionner le schéma correspondant à vos données depuis une liste déroulante.

• Le fait d'indiquer que votre ressource est censée respecter un schéma permet de bénéficier de vérifications de la qualité des données et d'indiquer aux réutilisateurs que vos données respectent un référentiel.