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 ;

• 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.

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.

Recommandations pour le formatage des fichiers csv

Un des formats privilégiés pour les standards de données est le CSV (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. 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.

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.

Format de fichier csv

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.

L’encodage des caractères à privilégier est l'UTF-8 de manière à garantir une meilleure interopérabilité 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 ,, .

Recommandations de formatage des données

Les recommandations de formatage pour les données sont généralement issues du standard TableSchema, lui-même inspiré des spécifications du format Json, dans lequel sont exprimés les schémas de données permettant l'automatisation de leur validation.

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

Ci-dessous quelques exemples tirés du schéma des menus de la restauration collective.

Le champ permettant d'indiquer le numéro SIRET d'une collectivité est spécifiée de la manière suivante :

{
    "name": "menuCollSiret",
    "title": "Code SIRET de la collectivité qui produit les données.",
    "description": "Identifiant du Système d'Identification du Répertoire des Etablissements (SIRET) de la collectivité qui commandé le menu. Ce code doit obligatoirement être composé de 9 chiffres SIREN + 5 chiffres NIC d’un seul tenant.",
    "type": "string",
    "examples": "21330063500017",
    "constraints": {
        "required": true,
        "pattern":	"^\\d{14}$"
    }
}

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 :

{
    "name": "menuPublicationDate",
    "title": "Date de publication de l'enregistrement d'un menu",
    "description": "Lors de la publication ce champ d'horodatage permet d'indiquer la date de publication de la donnée présente dans le fichier.",
    "type": "datetime",
    "examples": "2020-05-11T14:08:32Z",
    "constraints": {
    "required": true
    }
}

Les informations ci-dessous décrivent les différents types de champs disponibles dans la spécification TableSchema.

Données de type string

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.

Données de type décimal

• 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

Données de type date

• Description : date au format AAAA-MM-JJ suivant la norme internationale ISO 8601.

• Type : date

• Exemple : 2017-10-15

• Format : "%Y-%m-%d"

• Nommage : abreviation-du-schemaDate

Données de type date avec heure

• Description : date au format aaaa-mm-jjThh:mi:ssZZZZZZ suivant la norme internationale ISO 8601. 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.

• Type : datetime

• Exemple : 1997−07−16T19:20:00

Données de type date avec heure de début et de fin

• 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 ISO 8601.

• Type : datetime

• Exemple : 1997−07−16T08:30/17:30

Données de type horaires d'ouverture

• 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

Données de type géolocalisation

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).

Latitude

• Description : ce type de données permet de saisir la coordonnée de latitude exprimée en WGS 84 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.

• Type : number

• Exemple : 48.563433

• Nommage : abreviation-du-schemaLat

Longitude

• Description : ce type de données permet de saisir la coordonnée de longitude exprimée en WGS 84 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.

• Type : number

• Exemple : 2.572875

• Nommage : abreviation-du-schemaLon

Geopoint

• Description : ce type de données permet de saisir les coordonnées de latitude et de longitude exprimée en WGS 84 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

• Type : number

• Exemple : "48.563433, 2.572875"

• Nommage : abreviation-du-schemaGeo

Geoshape

• 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"

Données de type adresse

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.

Voie

• 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

Code postal ou Code INSEE

• 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

Commune

• Description : ce type de champs permet de saisir le nom de la commune

• Type : string

• Exemple : Saint-Jean-de-Braye

• Nommage : abreviation-du-schemaCommune

Recommandations de champs obligatoires

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).

Identification du producteur

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.

Nom de la collectivité

• 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

{
    "name": "menuCollNom",
    "title": "Nom de la collectivité qui produit les données",
    "description": "Nom officiel de la collectivité ou de l'établissement public responsable de l'offre de restauration collective et qui produit les données.",
    "type": "string",
    "examples": "Grand Poitiers Communauté urbaine",
    "constraints": {
        "required": true 
    }
}

SIRET de la collectivité

• 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 :

{
    "name": "menuCollSiret",
    "title": "Code SIRET de la collectivité qui produit les données.",
    "description": "Identifiant du Système d'Identification du Répertoire des Etablissements (SIRET) de la collectivité qui commandé le menu. Ce code doit obligatoirement être composé de 9 chiffres SIREN + 5 chiffres NIC d’un seul tenant.",
    "type": "string",
    "examples": "21330063500017",
    "constraints": {
        "required": true,
        "pattern":	"^\\d{14}$"
    }
}

Horodatage des données

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.

Date de création/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 :

{
    "name": "menuPublicationDate",
    "title": "Date de publication de l'enregistrement d'un menu",
    "description": "Lors de la publication ce champ d'horodatage permet d'indiquer la date de publication de la donnée présente dans le fichier.",
    "type": "datetime",
    "examples": "2020-05-11T14:08:32Z",
    "constraints": {
        "required": true
    }
}

Date de dernière modification

• 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 :

{
    "name": "menuModificationDate",
    "title": "Date de dernière modification de l'enregistrement d'un menu",
    "description": "Lors de la modification ce champ d'horodatage permet d'indiquer la date de dernière modification de la donnée présente dans le fichier.",
    "type": "datetime",
    "examples": "2020-05-11T14:08:32Z",
    "constraints": {
    "required": false
    }
}

Information sur les modifications

• 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 :

{
    "name": "menuModificationInfo",
    "title": "Information sur la modification ayant entraîné une mise à jour de la donnée",
    "description": "Afin de renseigner les usagers de la donnée, il est possible de préciser dans ce champ la raison de la mise à jour effectuée.",
    "type": "string",
    "examples": "changement dû à un aléa de livraison",
    "constraints": {
        "required": false
    }
}

Recommandations pour le nommage des fichiers

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

• idProducteur : Numéro SIREN sur 9 chiffres pour identifier le producteur

• 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'

Recommandations pour le nommage des champs

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.

Recommandations pour la mise en conformité

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 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.

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.

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 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 :

• 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.