đź““
Guide DataSud
  • Bienvenue
  • âť“Foire aux questions
  • Documentation de datasud.fr
    • CrĂ©er un compte utilisateur, un groupe et rejoindre une organisation
    • Organisation
      • CrĂ©er une organisation
      • Suivre l'activitĂ© et modifier son organisation
      • GĂ©rer les membres de son organisation
      • Groupes d’organisations
      • Configuration de permissions particulières des jeux de donnĂ©es
      • Supprimer une organisation
    • Jeux de donnĂ©es
      • Publier un jeu de donnĂ©es
      • Utiliser diffĂ©rents modes de publication de vos ressources
      • GĂ©rer un jeu de donnĂ©es
        • ParamĂ©trer le jeu de donnĂ©e
        • Consulter les statistiques de vos jeux de donnĂ©es
      • Explorer un jeu de donnĂ©e
      • Indexer un catalogue de donnĂ©es existant
    • RĂ©utilisations
      • Publier une rĂ©utilisation
    • Moissonnage
      • Les limites du moissonnage
      • Correspondance des champs entre les catalogues
      • Mettre en place un moissonneur entre DataSud et Data.gouv
      • Analyser le rapport de moissonnage
    • Les Carte : MAPS
      • Consulter les cartes de DataSud
      • CrĂ©er une carte dans DataSud
      • Partager sa carte dans un espace de travail
  • Guides open data
    • Guide juridique
      • Producteurs de donnĂ©es
        • Comprendre la notion d'open data
        • Qui est concernĂ© ?
        • Quelles sont les obligations ?
      • RĂ©utilisateurs de donnĂ©es
        • Comprendre la notion d'open data
        • Respecter les conditions de rĂ©utilisation
      • Chronologie de l'open data
    • Guide qualitĂ©
      • Evaluer le niveau de qualitĂ© d'un jeu de donnĂ©es
      • PrĂ©parer un jeu de donnĂ©es de qualitĂ©
        • Extraire un jeu de donnĂ©es d'un système d'information
        • Structurer un jeu de donnĂ©es
          • Structurer une Base Adresse Locale
        • Lier des donnĂ©es Ă  un rĂ©fĂ©rentiel
      • Documenter des donnĂ©es
        • Bien documenter un jeu de donnĂ©es
        • Diffuser la documentation d'un jeu de donnĂ©es
      • AmĂ©liorer la qualitĂ© d'un jeu de donnĂ©es en continu
        • AmĂ©liorer le 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
      • MaĂ®triser les schĂ©mas de donnĂ©es
        • Comprendre les bĂ©nĂ©fices d'utiliser un schĂ©ma de donnĂ©es
        • CrĂ©er un schĂ©ma de donnĂ©es
          • Etape 1 : Phase d'investigation
          • Etape 2 : Phase de concertation
          • Etape 3 : Phase de construction
          • Etape 4 : Phase de promotion et de maintien
          • Focus : Construire un schĂ©ma TableSchema
        • IntĂ©grer un schĂ©ma de donnĂ©es Ă  schema.data.gouv.fr
        • Produire des donnĂ©es en conformitĂ© avec un schĂ©ma
        • Indiquer et vĂ©rifier qu'une ressource respecte un schĂ©ma de donnĂ©es
  • RĂ©utiliser des donnĂ©es
    • Utiliser les API gĂ©ographiques
      • Utiliser l'API Adresse
        • Rappel sur les donnĂ©es adresses
        • GĂ©ocoder des adresses - thĂ©orie
        • GĂ©ocoder des adresses - cas pratiques
        • FAQ Adresse
      • Utiliser l'API DĂ©coupage administratif
      • Utiliser les tuiles vectorielles
    • Utiliser les donnĂ©es du cadastre
      • Comprendre les donnĂ©es du cadastre et leurs usages
      • Manipuler les donnĂ©es du cadastre
      • Foire aux questions sur le cadastre
    • Prendre en main l'API "Adresse" portĂ©e par l'IGN
  • Autres ressources utiles
    • Lexique de l'open data
    • DonnĂ©es de la commande publique
      • Publier les donnĂ©es essentielles d’attribution des marchĂ©s
      • DĂ©claration d’un profil d’acheteur
    • DonnĂ©es de forte valeur : mĂ©tadonnĂ©es obligatoires et modalitĂ©s de rapportage
    • Ressources OpenDataFrance
    • Documentation de transport.data.gouv.fr
Powered by GitBook
On this page
  • Promouvoir un schĂ©ma de donnĂ©es
  • Maintenir un schĂ©ma de donnĂ©es
  • Points de sortie
  1. Guides open data
  2. Guide qualité
  3. Maîtriser les schémas de données
  4. Créer un schéma de données

Etape 4 : Phase de promotion et de maintien

PreviousEtape 3 : Phase de constructionNextFocus : Construire un schéma TableSchema

Last updated 1 year ago

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.

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 :

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

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. lorsqu'un accord est trouvé, mettre à jour techniquement le schéma lui-même (cf. le paragraphe ci-après);

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

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

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

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

faire une nouvelle 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 .

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 (après validation des modifications)

publier.etalab.studio
data.gouv.fr
données IRVE
schema.data.gouv.fr
phase de concertation
issue sur le dépôt Github de schema.data.gouv.fr
pull request