Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
Plusieurs critères permettent d'évaluer le niveau de qualité d'un jeu de données, notamment :
Ce guide a pour vocation de vous accompagner dans la production de jeux de données de qualité, notamment dans le cadre d'une démarche d'ouverture.
Lexique : Jeu de données Au sens de data.gouv.fr, un jeu de données est un ensemble de ressources : il contient des fichiers contenant des données (csv, json, etc.), de la documentation pour décrire le contenu de ces données, ainsi que la licence sous laquelle le jeu est publié.
Dans ce guide, vous apprendrez comment :
Les données issues d'une organisation ont été produites dans un contexte métier particulier. Un individu externe à l’organisation n’est pas forcément familier avec cet environnement métier, ce qui peut le freiner dans l’exploitation des données diffusées.
La documentation d'un jeu de données a une visée pédagogique et facilite la réutilisation des données.
Elle décrit les données et la structure des fichiers publiés.
Dans cette section, vous apprendrez comment :
Bien documenter un jeu de données
Diffuser la documentation d'un jeu de données
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.
Les jeux de données qui ont vocation à circuler seront réutilisés par des acteurs tiers qui ne connaissent pas l’environnement de votre organisation.
Il est nécessaire de proposer une structure de jeu de données compréhensible et appropriable par tous.
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.
Les préconisations pour structurer une Base Adresse Locale sont détaillées sur cette page.
Il est nécessaire de réfléchir en amont à la meilleure structure pour vos données.
Tant que les données de votre structure sont dans un environnement logiciel, leur usage reste adapté à des problématiques métiers spécifiques.
L’ouverture de ces données en dehors de leur environnement impose de structurer le jeu de données en fonction des attentes des réutilisateurs et non plus en fonction des besoins propres à l’organisation.
✨ Quelques bonnes pratiques vous permettront de bien structurer votre jeu de données :
Il est conseillé de :
Occulter l’ensemble des colonnes dont les champs contiennent des données couvertes par un secret légal (cf. Guide juridique) ;
Occulter l’ensemble des colonnes dont les champs contiennent des données à caractère personnel dont la publication n’est pas nécessaire à l’information du public (cf. Guide juridique) ;
Privilégier la présence de variables pivots : ces variables proposent des identifiants communs qui permettent de lier plusieurs jeux de données entre eux (ex. le numéro SIRET de la base Sirene) (cf. section "Lier des données à un référentiel").
Dans un fichier tabulaire, la première ligne du fichier peut être utilisée pour nommer chaque colonne et donner des informations sur les données associées.
Il est conseillé de :
Donner un nom de colonne explicite ;
Donner un nom de colonne sans majuscule, abréviation, accents, ni espaces (préférez le caractère _) afin de faciliter la manipulation des fichiers.
Il est possible que certaines occurrences d’un champ d'un fichier ne soient pas attribuées.
Il convient de :
Laisser ces occurrences vides plutôt que d’attribuer la valeur 0 (ou une autre valeur par défaut) : le zéro correspond à une valeur, qui peut dénaturer le sens de votre fichier.
Il est recommandé de choisir un titre qui doit pouvoir renseigner n’importe quel réutilisateur sur le contenu du fichier. Pour cela, il est recommandé de :
Ne pas donner un titre trop générique qui obligerait le réutilisateur à ouvrir le jeu de données pour comprendre son contenu (i.e. “liste.csv” ou encore “balance comptable” sans indiquer l’organisation concernée) ;
Ne pas donner un titre trop long qui rendrait la manipulation du fichier difficile (i.e. le titre du jeu de données “Fichiers consolidés des données essentielles de la commande publique” est suffisamment générique pour ne pas revenir sur toutes les sources de données utilisées pour agréger le jeu de données) ;
Ne pas donner un titre contenant des accents ou caractères spéciaux qui poseraient des problèmes d’interopérabilité des fichiers ;
Ne pas donner de titre trop technique issu de nomenclatures métier.
Lexique : Encodage
L’encodage d’un fichier est la norme utilisée pour coder chaque caractère par une suite de 0 et de 1 compréhensible par une machine.
Lorsque l’encodage est mal choisi, le réutilisateur des données est souvent contraint de convertir le fichier, notamment afin de faire apparaître les accents et caractères spéciaux.
Il est conseillé de :
Utiliser l’encodage UTF-8 : il permet d’encoder l’ensemble des caractères du répertoire universel de caractères codés (notamment les caractères contenant des accents ou des caractères spéciaux).
Dans un fichier tabulaire, le séparateur permet de structurer les données sous forme de cellules.
Il est conseillé d'utiliser la virgule comme séparateur.
Séparateurs décimaux
Dans un fichier CSV, la virgule n’est pas considérée comme un séparateur décimal. Si votre fichier contient des valeurs décimales, il est nécessaire d’encapsuler chaque champ entre des guillemets.
La plupart des tableurs (Excel, OpenOffice Calc, etc) proposent l’encapsulement des champs entre guillemets.
Une seconde solution consiste à convertir l’ensemble des virgules utilisées pour des valeurs décimales par un point.
Il est important de mener une réflexion sur la granularité du jeu de données.
Faut-il proposer des données fines ou agrégées ? Faut-il proposer un export quotidien, mensuel, trimestriel ou annuel ? Ces questions doivent être posées en amont de l’automatisation des exports.
Il est conseillé de mener un dialogue avec les réutilisateurs afin de comprendre leurs besoins : certains utilisateurs peuvent souhaiter manipuler des données granulaires tandis que d’autres préfèrent disposer d’agrégats qui permettent une réutilisation simple et rapide. A minima, il est conseillé de proposer un fichier complet unique qui contient l’ensemble des données historiques.
Afin qu'un maximum d’utilisateurs puisse s’approprier les données, il est conseillé de les faire circuler dans un format :
ouvert : un format ouvert n’impose pas de spécifications techniques qui entraveraient l’exploitation des données (i.e. l’utilisation d’un logiciel payant) ;
aisément réutilisable : un format aisément réutilisable sous-entend que toute personne ou machine peut réutiliser facilement le jeu de données ;
exploitable par un système de traitement automatisé : un système de traitement automatisé permet de réaliser des opérations par des moyens automatiques, relatifs à l’exploitation des données (i.e. un fichier CSV est aisément exploitable par un système de traitement automatisé contrairement à un fichier PDF).
Il est possible de choisir parmi les formats ouverts et communément acceptés suivants :
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"
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.
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 :
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).
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
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.
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.
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).
| Type de données | Formats conseillés | Description | Documentation |
|---|---|---|---|
Données tabulaires
CSV
Un fichier CSV est constitué de lignes de données, où chaque champ est séparé par une virgule. Ce format est le standard le plus réutilisable, car ouvert et facilement exploitable par une machine.
Données statiques de transport
GTFS/NeTEx
Le format GTFS est le format le plus utilisé en France par les services de mobilité d’information voyageur. Le format NeTEx est le format de référence européen qui vise l’interopérabilité des données entre États membres.
Données géographiques
GeoJSON, Shapefile, MapInfo MIF/MID, MapInfo TAB et GML, pour les vecteurs / ECW, JPEG2000 et GeoTIFF, pour les données pixelisées (raster)
Les données géographiques sont organisées sous forme d’ensemble de données hiérarchisées. Les formats proposés sont conçus spécifiquement pour être largement exploitables et être intégrés facilement dans des outils de cartographie.
Données hiérarchiques
JSON / XML / YAML
Les données hiérarchiques décrivent des relations hiérarchiques entre différentes données. Le format JSON est préconisé lorsque les données sont liées entre elles sous forme d’arbres verticaux.
indisponible
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 :
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 ;
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 ;
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.
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.
Lexique : Base Adresse Locale Fichier géré par une collectivité locale (habituellement une commune ou un EPCI) et contenant toutes ses adresses géolocalisées. Elle respecte le schéma Base Adresse Locale et une gouvernance qui prévoit que la commune est au centre du dispositif. Depuis 2019, les Bases Adresses Locales sont prioritaires dans la Base Adresse Nationale : une commune qui publie sa Base Adresse Locale devient la seule source d'adresses sur son territoire.
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.
Toute commune peut vérifier que son fichier d'adresses est conforme au schéma et qu'il pourra être intégré à la Base Adresse Nationale grâce au validateur proposé par adresse.data.gouv.fr. Il suffit de glisser le fichier contenant toutes les adresses au format .csv pour obtenir la liste des erreurs à corriger impérativement (en rouge) et des anomalies (problèmes non bloquants mais réduisant la qualité des adresses et leur utilisation).
Si vous n'avez pas déjà votre propre outil, il est recommandé d'utiliser l'éditeur "Mes Adresses", conçu pour permettre à toutes les communes de gérer directement leurs adresses/bases adresses locales en respectant les normes et le schéma sans besoin de compétences techniques. Il permet à la fois de publier et de modifier sa Base Adresse Locale. La transmission des adresses à la Base Adresse Nationale se fait en temps réel.
L'outil est gratuit, open source et simple d'utilisation.
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.
Dans cette section, vous apprendrez comment :
Il est important d'intégrer dans vos jeux de données des données pivots relevant d'un référentiel.
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 est opéré par le ministère de l'intérieur.
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.
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 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 :
| Nom du jeu de données | Variable(s) pivot(s) | Description | Producteur |
|---|
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.
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.
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 :
Cadre Commun d'Architecture des référentiels de données de l'État
Le Cadre Commun d'Architecture des référentiels de données de l'État fait spécifiquement mention de l'importance des variables pivots dans le partage et la publication de données. Il stipule notamment que :
Les données sont un bien, un actif de l’État, elles doivent être gérées et valorisées en conséquence ;
Les données doivent être standardisées, définies sur la base d’un vocabulaire commun, contextualisées, et combinables les unes aux autres ;
Les données doivent être facilement réutilisables, partageables et accessibles à travers les frontières des administrations ;
Les données publiques doivent être mises à disposition librement et ouvertement sur internet ;
La sécurité et l'archivage des données doit être assuré.
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.
Il existe des référentiels pour décrire une adresse de manière unique.
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.
Lexique : Géocodage
Le géocodage consiste à affecter des coordonnées géographiques à une adresse postale.
Le géocodage peut être en partie automatisé grâce à des outils proposés par Etalab.
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.
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.
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 :
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.
Lexique : Réutilisation
Une réutilisation désigne communément l’exploitation de données ouvertes par des tiers, à d’autres fins que celle de la mission de service public pour laquelle elles ont été produites ou reçues.
Elle peut prendre la forme d’une visualisation, d’une application, d’un article de presse, d’un papier de recherche, etc.
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 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 , 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.
Exemples :
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.
Exemple :
Réaliser des entretiens avec les principaux réutilisateurs.
Exemple
Lexique : Schéma de données
Les schémas de données (ou simplement schémas) permettent de décrire la structure d'un fichier d'un jeu de données.
Ils indiquent clairement quels sont les différents champs, comment sont représentées les données, quelles sont les valeurs possibles, leur format, etc.
Notion clef : Le cycle de vie de la donnée ouverte de qualité
Le cycle de vie de la donnée ouverte de qualité se compose de 5 étapes principales :
Fédérer une communauté ayant pour objectif de produire en open data des données aisément consolidables
Il est essentiel que des acteurs ayant pour ambition de produire le même type de données se réunissent afin de définir ensemble un standard commun : un .
Référencer le schéma de données
Une fois le schéma établi, il s’agit de le référencer, notamment sur , la plateforme nationale de référencement qui permet un accès aux schémas et facilite l’intégration avec des systèmes informatiques.
Saisir les données
Un consensus ayant été atteint sur le schéma des données, il est temps de saisir les données en elles-même conformément au schéma.
Valider les données par rapport au schéma
Pour valider la conformité de ses données par rapport à un schéma particulier, il est possible d'utiliser l'outil , développé par à l’initiative .
Publier les données en open data
Les données désormais validées, il ne reste plus qu’à les publier !
Dans cette section, vous apprendrez à réaliser l'ensemble des étapes du cycle de vie de la donnée ouverte de qualité, notamment :
Merci à eux !
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
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 :
Exemple : Description générale du
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 :
Certains jeux de données ne peuvent pas être utilisés à certaines fins ou possèdent des limitations qui rendent impossible certaines analyses.
Eclairage : Schéma de données VS Modèle de données
S'ils peuvent être utilisés dans des contextes proches, les termes "schéma" et "modèle" sont bien différents :
un schéma décrit la structure d'un fichier (ses champs et leur format).
un modèle décrit la structure logique du jeu de données sous la forme d'objets (ou entités) et de relations (ou associations). Les objets sont définis par une liste d'attributs.
Les champs d'un schéma sont la traduction physique des attributs des entités du modèle. Le modèle de données est avant tout un outil de dialogue entre les différents intervenants.
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 :
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é
Si vous publiez des données tabulaires, il est conseillé de produire un tableau récapitulatif indiquant, pour chaque colonne :
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.
Lexique : Métadonnée
Une métadonnée est une donnée qui décrit ou définit une autre donnée.
Dans la vie courante, l’étiquette d’un produit fournit des informations/métadonnées sur le produit (origine, composition, date de péremption, etc.). Appliqué aux jeux de données, les métadonnées sont des descriptions normalisées du contenu du jeu.
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 privé
La description des métadonnées apportera à un jeu de données une meilleure visibilité sur les catalogues.
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.
La date du changement
La nature du changement
Les liens associés au changement
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.
Exemple : L'identifiant unique d'une certification professionnelle est le . 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.
| Nom du jeu de données | Variable(s) pivot(s) | Description | Producteur |
|---|
| Nom du référentiel | Description | Information |
|---|
Le référentiel officiel d'adresse est la .
Le site permet de géocoder une liste d'adresse via un appel à une API ou par le dépôt de fichier csv.
Le site 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 . Des ressources sont disponibles sur pour vous aider dans l'installation de votre environnement.
--> Le géocodage est détaillé .
| Critère | Description |
|---|
Le poids de chaque critère sera ajusté en fonction de ;
A l'automne 2021, les producteurs de la (INSEE) ont sondé leurs réutilisateurs sur des questions de contenu, de format ou encore de documentation des données.
En décembre 2022, le a lancé sur l'ouverture des données publiques culturelles. Cette consultation visait à recueillir les besoins et les remarques des usagers concernant les jeux de données déjà ouverts et ceux qui auraient vocation à être ouverts.
(IGN) organise un certain nombre d'événements mettant à l'honneur les réutilisateurs. Il propose également des conférences, des webinaires de prise en main des différents services ainsi que des tutoriels d'accompagnement.
travaille étroitement avec la pour améliorer le en intégrant les retours des utilisateurs de l’outil (compétences pertinentes à retenir, celles qui sont renommées, jamais sélectionnées) et ses travaux de reformulation sémantique des compétences professionnelles.
Ce guide sur les schémas de données résulte d'une co-rédaction entre les équipes d' et d'. Il s'inspire du contenu rédigé par de nombreux partenaires, listés par ordre alphabétique :
Par exemple, précise que la réutilisation du jeu de données « » ne peut avoir ni pour objet ni pour effet de permettre la ré-identifications des personnes liés à des transactions immobilières.
Exemple : Dans le (infrastructures de recharge des véhicules électriques), on peut identifier que:
Exemple : du 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é.
Cela constituera une base solide en vue de la création d'un schéma de données, dont le processus est détaillé .
Exemple : La documentation du 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.
Exemple : La base de données de 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 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.
Exemple : du 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 :
Lexique : Phase de construction
La phase de construction consiste à implémenter techniquement le schéma de données obtenu après la phase de concertation. Pour cela, il est nécessaire de choisir un standard technique, créer les fichiers requis, les tester et les diffuser.
Durant cette phase, il est nécessaire de mobiliser des personnes possédant des compétences techniques. Cette phase consiste à transcrire les décisions prises lors de la phase de concertation en un ou plusieurs schémas de données suivant le découpage en fichiers retenu.
Lexique : Standard
On utilise les termes « normes » et « standards » pour décrire un référentiel commun et documenté destiné à harmoniser l’activité d’un secteur.
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 ;
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.
Conseil : Aller au-delà de la documentation texte
Un schéma de données décrit uniquement par du texte ou par un tableau se prive de nombreux avantages, notamment celui de l'interopérabilité entre différents systèmes informatiques.
Les schémas de données décrits par des standards techniques permettent, en plus d’une documentation textuelle ou sous forme d’un tableau, de valider que des données correspondent à un modèle de données, d’agréger des données similaires, de générer automatiquement des données respectant un schéma.
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.
Exemples à votre disposition
Pour un schéma au format Table Schema, un modèle de départ est mis à disposition pour créer un dépôt Git contenant un schéma au format Table Schema.
Pour les autres formats de schémas, il est conseillé de consulter les schémas et dépôts Git listés sur schema.data.gouv.fr.
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.
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.
À l’issue de cette phase, vous devriez :
La création d'un schéma de données se décompose en 4 phases :
Investigation : envisager de créer un schéma de données ;
Concertation : rassembler plusieurs parties prenantes pour créer un schéma de données ;
Construction : implémenter le schéma de données obtenu après la phase de concertation ;
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.
Conseil de lecture
Nous vous recommandons de lire une première fois cette section sur la création de schémas de données en intégralité afin de prendre connaissance des différentes phases. Vous pourrez ensuite vous référer aux pages pertinentes au fur et à mesure de votre avancée.
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.
SIRET, SIREN | Liste des établissements (SIRET) et unités légales (SIREN) françaises |
BAN | Référencement de l'intégralité des adresses du territoire français |
Codes et libellés | Liste des communes, cantons, arrondissements, départements, régions, pays et territoires étrangers |
Identifiant | Représentation de chacune des sections du cadastre français |
Identifiant | Base de données géographique de référence pour l'instruction des aides de la politique agricole commune (PAC) |
Identifiant | Liste des institutions régies par la Constitution de la Ve république ainsi que les administrations qui en dépendent |
Identifiant | Composantes orthophotographique, topographique et adresse, parcellaire et altimétrique des territoires de l'Etat français |
N° RNA / N° Waldec | Ensemble des associations relevant de la loi du 1er juillet 1901 relative au contrat d’association, dont le siège est en France |
Code ROME | Inventaire des dénominations d’emplois/métiers les plus courantes, analyse des activités et compétences, regroupement des emplois selon un principe d’équivalence ou de proximité |
Code NAF | Nomenclature des activités économiques productives, principalement élaborée pour faciliter l'organisation de l'information économique et sociale |
N°RNCP / N°RS | Répertoire des certifications officielles inscrites au RNCP et au RS |
N° FANTOIR | Nom des lieux-dits et des voies pour chaque commune, y compris celles situées dans les lotissements et les copropriétés |
Code Pays | Liste des états indépendants reconnus par la France |
Code PCS / Code PCS-ESE | Nomenclatures des professions et catégories socioprofessionnelles |
N°UAI | Liste des unités administratives immatriculées |
WGS84 | Coordonnées géodésiques d'un lieu |
ISO8601 | Représentation numérique d'une date et d'une heure |
Description des données | La description des données est de qualité (la description du jeu de données suffisamment longue). |
Ressources documentées | Présence d'au moins un fichier de type documentation ou description des fichiers suffisamment longue. |
Mise à jour | - La fréquence de mise à jour est renseignée. - La fréquence de mise à jour est respectée. |
Licence |
Métadonnées des ressources | Présence d’au moins une ressource avec un format ouvert déclaré. |
Couverture spatiale | - La couverture spatiale est renseignée. - La granularité spatiale est renseignée. |
Couverture temporelle | La couverture temporelle des données est renseignée. |
La pertinence de la mise en place d'un standard de données réside dans son adéquation entre les capacités de sa mise en oeuvre par les producteurs de données et les outils permettant l'automatisation des jeux de données valides par rapport à cette spécification.
Cette standardisation doit permettre de faciliter la mise en relation des jeux de données issus de différents producteurs.
Cette page détaille des recommandations, visant à faciliter la création de nouveaux schémas et leur intégration dans une chaîne de validation et de publication généralisable, notamment :
Des recommandations pour le formatage des fichiers csv
Des recommandations de formatage des données
Des recommandations de champs obligatoires
Des recommandations pour le nommage des fichiers
Des recommandations pour le nommage des champs
Des recommandations pour la mise en conformité
Un des formats privilégiés pour les standards de données est le (Comma Separated Values, valeurs séparées par des virgules). Il s'agit d'un format de données "à plat", adéquat pour les structures de données simples.
Cependant, ce format simple ne dispose pas de spécifications contraignant la saisie des données. Pour cela un schéma en Json est ajouté dont la structure est défini par le standard . TableSchema permet d'indiquer les formats des données attendus, de spécifier des contraintes (types de valeurs, cardinalité) et de documenter les différents champs composant le schéma.
L'outil de validation utilisé pour vérifier la conformité d'un fichier csv au standard auquel il fait référence s'appuie sur la structure tabulaire des données. Elles peuvent donc être contenues dans un tableur numérique au format .xls, .xlsx ou .ods ou dans un fichier texte au format .csv, .txt ou autre.
La question du séparateur utilisé pour séparer deux champs de données dans un fichier .csv n'est donc pas essentielle. Cependant, certains outils se basent sur la valeur de ce séparateur pour traiter et publier des jeux de données. Nous vous proposons donc un certain nombre de recommandations afin de favoriser la généralisation d'un usage contribuant à l'interopérabilité des données produites.
Bien que de nombreux jeux de données en CSV utilisent le point-virgule comme séparateur de champs, il a été décidé de privilégier le séparateur virgule car plus conforme à l'esprit du format csv.
Les tableurs numériques courants (Excel et Calc) peuvent produire et lire des fichiers csv. Lors de l'enregistrement d'un fichier créé avec l'outil Calc, l'utilisatrice ou utilisateur doit spécifier le format d'encodage des données ainsi que le séparateur de champs. Lorsque le séparateur de champs retenu est la virgule, il est recommandé d'utiliser les guillemets double " comme séparateur de chaîne de caractères. De cette manière, si une virgule est présente à l'intérieur d'une cellule elle ne sera pas considérée comme un séparateur de champs.
Lors de l'ouverture d'un fichier csv dans Calc, une fenêtre modale propose plusieurs options permettant de spécifier un caractère de séparation et un encodage des données.
Dans Excel, il faut aller dans l'onglet données et sélectionner l'option Fichier texte pour accéder à l'assistant d'import des données.
Pour faciliter la lecture des fichiers publiés en CSV il est recommandé d'y associer dans les outils de publication le type MIME ou Content-Type "text/csv".
Chaque ligne du fichier doit avoir le même nombre de champs, ce qui signifie que lorsqu'une cellule est vide elle doit quand même être présente soit avec la valeur Null, soit avec des crochets vides [] dans le cas des champs de type tableau (array), soit laissée vide mais apparaître à l'export avec 2 virgules qui se suivent ,, .
Ce standard dispose des types de données suivants :
string : s'applique pour toutes les chaînes de caractères
number : s'applique pour les chiffres et nombres contenant éventuellement des décimales
integer : s'applique pour les chiffres et nombres entiers
boolean : s'applique pour indiquer que la valeur d'un champs ne peut être égale qu'à "vrai" ou "faux" (ou "1" et "0" ou "oui" ou "non")
object : s'applique pour les données de type objet
array : s'applique pour les tableaux de données
Les types de données peuvent être assortis de formats de données facilitant l'automatisation de leur validation.
Pour déclarer un format de données dans un schéma JSON il est possible d'utiliser différentes propriétés permettant de le caractériser :
name : le nom du champ
title : le titre du champ
description : la description des valeurs attendues dans ce champ
format : le format du champ
type : le type du champ
Il est également possible de contraindre les valeurs autorisées dans ce champ à l'aide de plusieurs proriétés :
required : indique l'obligation de la présence d'une valeur pour ce champ dans toutes les lignes du fichier
unique : indique que chaque valeur de ce champ à l'intérieur du fichier doit être unique
minLength : indique la taille minimale des valeurs de ce champ
maxLength : indique la taille maximale des valeurs de ce champ
minimum : indique la valeur minimum autorisée pour ce champ (par exemple pour une date on peut indiquer une année en deça de laquelle les valeurs ne sont pas autorisées)
maximum : indique la valeur maximale autorisée pour ce champ
pattern : indique une expression régulière à laquelle doivent être conforme les valeurs de ce champ (par exemple pour un numéro SIRET on peut indiquer ^\\d{14}$ ce qui signifie que les valeurs de ce champ doivent contenir exactement 14 chiffres)
enum : indique une liste de valeurs autorisées pour ce champ
Le champ permettant d'indiquer le numéro SIRET d'une collectivité est spécifiée de la manière suivante :
Le champ permettant d'indiquer la date de publication d'un enregistrement du jeu de données est spécifié de la manière suivante :
Les informations ci-dessous décrivent les différents types de champs disponibles dans la spécification TableSchema.
Pour le type string, les formats de données suivants sont disponibles :
default : n'importe quelle chaîne de caractère
email : une adresse email valide.
motif de validation :
uri : une URI valide
binary : une chaîne de caractère encodées en base 64 représentant des données binaires.
uuid : une chaîne de caractère représentant un identifiant unique.
Description : Les valeurs décimales doivent utiliser le point afin d'être plus facilement exploitables par les tableurs numériques.
Type : number
Exemple : 3900.50
Type : date
Exemple : 2017-10-15
Format : "%Y-%m-%d"
Nommage : abreviation-du-schemaDate
Type : datetime
Exemple : 1997−07−16T19:20:00
Type : datetime
Exemple : 1997−07−16T08:30/17:30
Description : horaires indiquant les heures d'ouverture d'un service ou d'un commerce. Ce type de données permet de préciser les différents horaires d'ouverture pour les différents jours de la semaine. Il s'agit donc d'un type de données multi-valeur au sein duquel le nom du jour de la semaine est abrégé et suivi par les heures d'ouvertures. Les abréviations pour les jours sont en anglais (Mo, Tu, We, Th, Fr, Sa, Su) et les horaires sont sous la forme HH:MM
Type : string (chaîne de caractères)
Exemple : Mo 08:15-13:15; Tu 03:15-06:15; We 03:15-09:30; Th 02:30-07:15; Fr 01:30-05:45; Sa 00:30-05:00; Su 02:45-08:30
Nommage : abreviation-du-schemaHoraires
La possibilité est laissée de décrire les points de géolocalisation d'une donnée à l'intérieur d'un champ unique (geopoint) ou à l'aide de 2 champs (latitude et longitude).
Type : number
Exemple : 48.563433
Nommage : abreviation-du-schemaLat
Type : number
Exemple : 2.572875
Nommage : abreviation-du-schemaLon
Type : number
Exemple : "48.563433, 2.572875"
Nommage : abreviation-du-schemaGeo
Description : ce type de données permet de décrire la forme géographique d'un équipement. La forme est décrite à l'aide de paires de coordonnées, séparées par un espace vide et chaque paire séparée par une virgule. La description d'une ligne est exprimée à l'aide de 2 ou plus paires de points séparés par des virgules. La description d'un polygone est exprimée par 4 ou plus paires de points séparés par des virgules dont la dernière est identique à la première.
Type : string
Exemple : "48.563433 2.572875, 49.234933 2.134432, 49.885311 2.134003, 48.974635 2.1134567, 48.563433 2.572875"
Ce type de champ permet de décrire l'adresse postale d'un équipement. Il est décomposé entre 3 champs permettant de distinguer et de faciliter le tri à l'intérieur des informations de voirie, de code postal et de commune. Le numéro et le nom de la voie sont séparés par une virgule.
Description : ce type de champs permet de saisir le numéro et le nom de la voie
Type : string
Exemple : 34, rue de Latresne
Nommage : abreviation-du-schemaVoie
Description : ce type de champs permet de saisir le code postal (ou le code INSEE) de la commune
Type : number
Exemple : 45800
Nommage : abreviation-du-schemaCodePostal
Description : ce type de champs permet de saisir le nom de la commune
Type : string
Exemple : Saint-Jean-de-Braye
Nommage : abreviation-du-schemaCommune
Afin d'unifier la description des données au travers des différentes thématiques abordées par le propositions de standard de données, il est fortement recommandé de rendre obligatoire la présence d'un certains nombre de champs.
Ceux-ci contribuent à la portabilité des données (qui produit la donnée) ou à leur fiabilité (quand a été produite la donnée).
Pour l'identification des autorités publiques à l'origine de la production et de la publication des jeux de données, il est recommandé d'indiquer le nom et le numéro de SIRET sur chaque ligne de chaque jeu de données.
Description : ce champs permet de saisir le nom de l'autorité publique responsable de la production des données
Type : string
Exemple : Conseil départemental de la Creuse
Nommage : abreviation-du-schemaColl
Par exemple
Description : ce champ permet d'indiquer le numéro d'identification de l'autorité publique au sein de la base nationale des établissements.
Type : string
Exemple : 21330063500017
Motif : ^\d{14}$
Nommage : nom-ou-abreviation-du-schemaCollSiret
Par exemple :
Pour faciliter la réutilisation et la mise à jour des données, il est recommandé de fournir aux réutilisatrices et réutilisateurs potentiels des dates de première publication et de dernière modification pour chaque entité du jeu de données.
Ces informations au format Date avec horaire peuvent correspondre à la date de première publication et faire apparaître les dates de dernière modification pour l'ensemble des lignes ou en cas de mise à jour partielle pour une ligne de données particulière.
Il est également recommandé d'y associer un champ permettant de décrire la raison ayant entraîné une mise à jour des données depuis leur publication.
Description : ce champs permet de décrire la date de première publication de la donnée
Type : datetime
Exemple : 2020-05-11T14:08:32Z
Nommage : nom-ou-abreviation-du-schemaPublicationDate
Par exemple :
Description : ce champs permet de décrire la date de dernière modification de la donnée
Type : datetime
Exemple : 2020-05-11T14:08:32Z
Nommage : nom-ou-abreviation-du-schemaModificationDate
Par exemple :
Description : ce champs permet de décrire la raison d'une modification de la donnée depuis sa publication initiale
Type : string
Exemple : changement dû à un aléa de livraison
Nommage : nom-ou-abreviation-du-schemaModificationInfo
Par exemple :
Les fichiers doivent, sauf exception et autant que possible, respecter les règles de nommage suivantes :
AAAAMMJJ_idProducteur_nom-du-fichier.extension
AAAAMMJJ : Date de création du fichier
nom-du-fichier Chaîne de caractères dont les termes, en minuscules non accentuées, sont séparés par un tiret du milieu
.extension : Si les règles de formatage sont respectées, l'extension est .csv
Les 3 éléments constitutifs de la chaîne principale avant l'extension sont assemblés en un seul tenant et séparés par un tiret du bas.
Exemple : '20180314_213502388_prenoms-nouveaux-nes-rennes-2017.csv'
Afin d'uniformiser les fichiers produits dans le cadre de schémas de standardisation, il est recommandé de normaliser les intitulés des champs composant chaque standard.
La règle générale préconisée est l'utilisation de l'écriture camelCase où chaque mot composant l'intitulé du champ est écrit avec une majuscule à l'exception du premier.
En complément il est recommandé d'utiliser un préfixe (mot complet ou abréviation) pour l'ensemble des champs d'un standard.
En conséquence, pour le standard des menus, les intitulés des champs sont préfixés par le mot menu suivi des intitulés à proprement dit. Par exemple :
menuCollNom
menuRestaurantIdType
menuRepasType
Aucun caractère accentué ou spécial ne doit être utilisé dans l'intitulé d'un champ. Il est également préconisé de ne pas dépasser 50 caractères pour l'intitulé d'un champ et d'utiliser le singulier pour les mots composant l'intitulé du champ.
Pour garantir la conformité des jeux de données, il est demandé aux producteurs de s'assurer que la structure, les champs et les contenus attendus sont effectivement respectés.
De fait, les fichiers tabulaires doivent, autant que possible, contenir :
Toutes les colonnes, y compris celles dont les cellules ne sont pas renseignées, dans le bon ordre, et avec des en-têtes correctement nommées sur la première ligne ;
Autant de lignes que nécessaire comprenant des cellules dont les valeurs peuvent être obligatoires (elles doivent être impérativement renseignées) ou optionnelles (elles sont seulement recommandées ou soumises à condition de disponibilité / pertinence).
- La licence est renseignée. - La licence est ouverte. .
L’encodage des caractères à privilégier est l' de manière à garantir une meilleure interopérabilité des données.
Les recommandations de formatage pour les données sont généralement issues du standard , lui-même inspiré des spécifications du format , dans lequel sont exprimés les schémas de données permettant l'automatisation de leur validation.
Ci-dessous quelques exemples tirés du .
Description : date au format AAAA-MM-JJ suivant la norme internationale .
Description : date au format aaaa-mm-jjThh:mi:ssZZZZZZ suivant la norme internationale . On considérera que ZZZZZZ (+ou- décalage horaire GMT), est par défaut +01:00 en France et qu'il est inutile de le préciser dans les formats.
Description : date au format aaaa-mm-jjThh:mi/hh:mi suivant la norme internationale ISO 8601. Ce type de données s'applique pour un créneau horaire dans la même journée, sans les secondes. Pour une extension de ces conditions, voir la norme .
Un assistant graphique en ligne permet de générer simplement cette structure de données
Description : ce type de données permet de saisir la coordonnée de latitude exprimée en permettant de localiser un équipement. Le signe de séparation entre les parties entière et décimale du nombre est le point. Précision : 6 décimales maximum.
Description : ce type de données permet de saisir la coordonnée de longitude exprimée en permettant de localiser un équipement. Le signe de séparation entre les parties entière et décimale du nombre est le point. Précision : 6 décimales max.
Description : ce type de données permet de saisir les coordonnées de latitude et de longitude exprimée en permettant de localiser un équipement. Le signe de séparation entre les parties entière et décimale du nombre est le point. Précision : 6 décimales max. Le séparateur de valeur est la virgule. Il est donc nécessaire d'entourer ces valeurs de guillemets. La première valeur est la latitude
idProducteur : Numéro sur 9 chiffres pour identifier le producteur
Améliorer votre score de qualité des métadonnées
Connaître et suivre les usages d'un jeu de données
Mettre en place une stratégie organisationnelle
--> La marché à suivre est détaillée ici.
Lexique : Phase de concertation
La phase de concertation est la phase centrale de la création d’un schéma de données.
C'est l’étape où plusieurs parties prenantes (producteurs, réutilisateurs, experts métiers et techniques) se rassemblent pour définir et spécifier les éléments essentiels à la constitution du schéma.
Pour spécifier un schéma de données, il est nécessaire de définir :
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.
Il est conseillé de :
Référencer votre schéma de manière anticipée
Référencer votre schéma sur schema.data.gouv.fr vous permettra de bénéficier de conseils de la part d’Etalab et de ses partenaires institutionnels et associatifs. --> La marche à suivre pour référencer votre schéma est détaillée ici.
Pour construire un schéma de données de qualité, il est conseillé de :
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.
Exemples à votre disposition
Il est possible de retrouver des fichiers de schémas sur schema.data.gouv.fr (exemple : le schéma des lieux de stationnement).
En complément, le guide dédié à la préparation de jeux de données pourrait être utile pour définir votre schéma.
À l’issue de cette phase, vous devriez :
Lexique : Phase de maintien et de promotion
La phase de maintien est la dernière phase du cycle de vie d'un schéma. Elle consiste à itérer sur la version actuelle en prenant en compte des évolutions du terrain et des retours des producteurs et des réutilisateurs pour peaufiner la structure du schéma. Elle est étroitement liée à la promotion du schéma qui permettra, grâce à son adoption par le plus grand nombre de parties prenantes, une montée en qualité et en quantité d'utilisations.
Modifier ou commenter un schéma contribue à faire vivre l'écosystème open data et permettra de vous identifier comme contributeur.rice sur un schéma spécifique.
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 :
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.
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 :
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.
lorsqu'un accord est trouvé, mettre à jour techniquement le schéma lui-même (cf. le paragraphe ci-après);
mettre à jour la documentation du schéma ;
déployer les mises à jour sous un nouveau tag de version ;
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 :
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)
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
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.
À l’issue de cette phase, vous devriez :
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.
Qu'est-ce que schema.data.gouv.fr ?
schema.data.gouv.fr est l’initiative de data.gouv.fr de référencement des schémas de données publiques pour la France.
Cette plateforme de référencement national permet un accès aux schémas produits par différents acteurs et facilite l’intégration avec des systèmes informatiques par le biais de standards, d’URLs stables, de processus de validation et d’API.
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.
Des schémas de données décrivant des données publiques.
Les schémas de données sont acceptés dès lors que leur l’existence est justifiée par voie :
réglementaire : c'est une disposition réglementaire qui est à l'origine de la définition du schéma de données ;
d’usage : la réutilisation des données décrites par le schéma bénéficie à un grand nombre ou de nombreux producteurs sont amenés à utiliser ce schéma de données.
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.
Standards techniques supportés
Les standards techniques de schémas de données actuellement supportés 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.
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.
Lexique : Validation d’un schéma de données
La validation d’un schéma de données est l’étape qui permet de vérifier si celui-ci est conforme au standard technique sélectionné et aux prérequis de schema.data.gouv.fr. Cette étape s’intéresse uniquement au schéma de données et à la façon dont il est publié.
Il ne faut pas confondre la validation d’un schéma avec le fait de vérifier que des données correspondent à un schéma.
Pour tous les types de schéma de données, il faut que :
Critères complets de validation
Cette page présente les grands principes de validation des schémas de données.
Le détail des prérequis propres à chaque type de schéma de données, ainsi que des exemples, sont disponibles ici.
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.
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.
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.
Lexique : Phase d’investigation
La phase d’investigation est la première phase de la création d’un schéma de données. Elle permet de s’assurer que la création d’un schéma est pertinente et en confirme la nécessité.
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 :
Lire attentivement les différentes sections de ce guide ;
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 ;
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.
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.
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é.
À l’issue de cette phase, vous devriez :
