Seulement cette pageToutes les pages
Propulsé par GitBook
1 sur 15

Fabrique des standards

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

En chantier

Cette espace est en création.

La version actuelle est en cours de relecture par le groupe de travail du CNIG sur la Fabrique des standards. Elle peut contenir des informations inexactes, et n'a pas vocation à être utilisée en l'état, mis à part pour certains tests ciblés et encadrés.

Émergence d'un besoin ou d'une évolution

Une communauté de professionnels ou un porteur de politiques publiques s'interroge sur l'existence ou le besoin d'un standard.

Une communauté de professionnels ou un porteur de politiques publiques s'interroge sur l'existence ou le besoin d'un standard.


La création d’un standard de données peut résoudre certaines difficultés expérimentées par des acteurs pour produire des données, les documenter, les partager, les agréger ou encore pour les utiliser. Toutefois, cette liste n’est pas exhaustive, et un standard ne sera pas toujours la solution pertinente dans chacun de ces cas. Alors dans quelles situations la création d’un standard de données est-elle une solution adaptée ?

Comme résumé en deux phrases dans un cahier de l’observatoire Data Publica, la standardisation “réduit les frictions en facilitant la découverte de données similaires ouvertes dans différents territoires et en permettant de consolider les données produites localement dans une base nationale exploitable facilement. Les standards, en tant qu’ensemble de recommandations préconisées par un groupe d’utilisateurs, permettent à différents outils numériques de communiquer pour construire un tout cohérent au service d’un ou plusieurs objectifs”. Votre besoin spécifique pourrait ne pas correspondre exactement à cette description générale, voici donc plus bas quelques exemples de situations plus particulières. Tout d’abord, avant de vous interroger sur son utilité, revenons sur ce que recoupe le terme de “standard de données”.

Les standards de données

Un standard de données est avant tout un standard. Mais qu’est ce qu’un standard ? Repartons des bases.

Dans le langage commun, un standard correspond à une règle qui fixe un seuil d’exigence ou un cahier des charges, et cherche à uniformiser et à stabiliser des pratiques dans le temps et dans l’espace. Le terme de standard en français est dérivé du terme anglais standard, le français effectue ainsi une distinction avec la norme qui n’existe pas en anglais (et est souvent source de confusions). La différence entre ces deux termes réside dans le caractère prescriptif de la norme. Comme décrit par l’Observatoire du SIG, les standards de facto s’imposent par des utilisations répandues dans la communauté des fournisseurs et des utilisateurs. Le format SHP ou le DWG en sont deux exemples bien connus. Les normes gouvernementales sont élaborées pour répondre à des usages souvent limités à un écosystème national, comme le sont les spécifications du CNIG pour les métiers. Elles peuvent alors avoir un statut réglementaire, comme dans le cas des documents d’urbanisme. Enfin, les normes formelles sont élaborées par le biais d'un processus plus rigide, géré par un organisme de normalisation patenté, tel que l’ISO, l’AFNOR ou l’OGC. Nous parlons donc ici de standards puisque le CNIG n’a pas d’accréditation pour la production de normes, et bien que certains standards du CNIG soient rendus obligatoires par des textes réglementaires. La valeur des standards du CNIG provient de leur processus d’élaboration fondé sur le travail collectif et de leur validation par la communauté large et représentative de ses membres et utilisateurs.

Les standards peuvent porter sur différents types d’objets : produits, procédés (de production, organisationnelles, etc.), techniques, données, etc. Les standards produits par le CNIG sont des standards de données, mais ils ont en réalité une portée plus large. Ils portent toujours sur les données et leurs métadonnées, en indiquant leur structure (grâce à un modèle conceptuel, à un schéma de données, etc.) et leur contenu (grâce à une ontologie, un catalogue d’objets, une description des types, des règles de qualité, etc.). Ils peuvent aussi porter, selon les cas, sur les méthodes de collecte et d’utilisation des données, et même prescrire des outils pour cela. Les données concernées par les standards du CNIG sont généralement des données géographiques, on parle alors de géostandards.

Ainsi, un standard élaboré par un groupe de travail (GT) du CNIG pourra contenir diverses informations, en complément d’une structure commune, en fonction du besoin auquel le GT cherche à répondre.

Exemples de besoin

→ Une réglementation qui impose de recourir à un standard ou de le faire évoluer.

Le standard Schéma de Cohérence Territoriale (SCOT) a été réalisé et mis à jour par le groupe de travail sur la Dématérialisation des Documents d’Urbanisme (DDU) pour tenir compte des changements réglementaires sur le sujet. Tout d’abord, l'ordonnance n°2013-1184 du 19 décembre 2013 relative à l’amélioration des conditions d’accès aux documents d’urbanisme et aux servitudes d’utilité publique vise à créer le Géoportail national de l’urbanisme en tant que plateforme légale de publication et de consultation des documents d’urbanisme, et des servitudes d’utilité publiques. Ce guichet unique d’informations sur l'urbanisme en France implique une totale standardisation des données numérisées. L’ordonnance n°2020-744 du 17 juin 2020 relative à la modernisation des SCOT est venue ensuite modifier le contenu des SCOT, exigeant une actualisation du standard.

→ Des acteurs se disent : « il faut s’entendre entre nous »

Constatant que l’existence, le contenu et l’accès à la donnée sur l’éclairage extérieur sont très inégaux en fonction des territoires, un ensemble d’acteurs s’est emparé du sujet en montant le groupe de travail Eclairage Extérieur au CNIG. Ce GT s’est ensuite élargi autour d’autres acteurs, privés notamment, pour élaborer le standard. Le groupe restreint à l’origine du projet a su convaincre le reste de l’écosystème qu’un standard permettrait de lever les freins à l’avancement de travaux opérationnels pour lesquels les données de points lumineux constituent une matière première quasi indispensable.

→ Un projet commun qui nécessite le passage par un standard

Le groupe de travail sur les vues immersives et les vues de terrain issues de l’acquisition terrestre s’est constitué suite au constat d'un manque d'accès souverain aux photos des territoires, bien qu’elles soient un élément incontournable pour appréhender et décrire le monde. Animé par la startup d’Etat Panoramax, ce GT organise la concertation et la coordination des acteurs dans l’objectif de standardiser les données liées aux vues immersives en tant que géocommun et afin d’en faciliter l’appropriation et la réutilisation.

→ Une contrainte ou une opportunité nouvelle (comme la refonte d’un système d'information, un plan national, etc.)

C’est le cas par exemple du Standard Paysages, qui s’inscrit dans un chantier national de transformation de l’action publique en faveur des paysages. Ce chantier vise à la production d’un référentiel national des atlas de paysages pour accompagner les collectivités, les élus et leurs partenaires dans la production de la connaissance. Le standard vient compléter ce livrable lié à la connaissance, par une dimension cartographie numérique.

→ Une évolution technique tierce ou des retours montrant la nécessité de mettre à jour un standard

Le standard GraceTHD vise à faciliter le recensement, la cartographie, et les échanges d’informations sur les réseaux de télécommunication Très Haut Débit (THD). Depuis la demande initiale en 2009, le standard a connu plusieurs évolutions. Bien que la version 3 du standard adoptée en 2020 ait permis son adoption large par les acteurs, leurs retours ont montré que le standard pouvait encore être amélioré. Ces réflexions ont conduit à la rédaction de la version 3.0.1 adoptée en décembre 2024.

Besoin d'un temps de réflexion ?

Si le besoin est encore mal défini, le CNIG peut dans certains cas apporter une aide en mettant en place un groupe de travail exploratoire au sein de la commission besoins et usages (exemples GT données géolocalisées en santé, GT Assurances, …).

Le rôle du secrétariat général du CNIG

Lors de l'émergence d'un besoin, le secrétariat général vous accompagne pour :

  • solliciter les bons interlocuteurs (si besoin),

  • identifier la procédure adaptée à votre cas.


Ressources utiles

  • Guide data.gouv sur la phase d'investigation préalable à la création d'un schéma de données.


Foire aux questions ↓

Comment trouver d'autres personnes ayant le même besoin que moi ?

Si vous identifiez un besoin, il est probable que vous ne soyez pas seul dans votre cas. Pour identifier ces personnes, trois cercles doivent être visés :

  • Vos interlocuteurs directs (collègues, prestataires, institutions partenaires, membres de fédérations auxquelles vous participez, etc.). Vous êtes le plus à même de les contacter.

  • Les acteurs de votre domaine (institutions similaires à la vôtre localisées dans d’autres territoires ou juridictions, concurrents, acteurs distants dans la chaîne de valeur, instances nationales, etc.). Les canaux de communication thématiques (forums spécialisés, newsletter, conférences, etc.) sont les plus adaptés pour contacter ces personnes.

  • Les acteurs qui sortent de votre horizon thématique. Afin de les identifier, le secrétariat général du CNIG peut vous venir en aide. L’utilisation de canaux de communication plus larges (forums généralistes comme forum.data.gouv, réseaux sociaux, etc.).

Dans quels cas l’évolution d’un standard peut-elle être nécessaire ?

A moins d’une perte de compatibilité importante ou d’un problème important identifié dans le standard, il peut être difficile de juger si une mise à jour du standard est opportune. Les cas évoqués plus haut pour l’identification d’un besoin s’appliquent pour cela : s’agit-il d’une obligation réglementaire ? Un consensus sur le besoin d’une évolution existe-il suite à une évolution technique et/ou l'émergence d'un nouveau besoin des utilisateurs ? Pouvez-vous profiter d’un calendrier favorable ?

Que faire si je veux faire évoluer un standard existant ?

De même que pour la création d’un standard, le besoin d’une évolution doit être caractérisé. Une fois la nécessité d’une évolution bien identifiée, le groupe de travail s'il existe, sinon le secrétariat du CNIG, vous accompagnera pour identifier le bon processus, qui peut dépendre de l’ampleur de la mise à jour à effectuer.


Retour à la page d'accueil ↓

Page précédente et page suivante ↓

La fabrique des standards

Initialisation des travaux

Cette phase vous permet de vous projeter dans les travaux avant de lancer la réalisation du standard.


Quelques repères sur la durée et la complexité du processus

Pour vous projeter dans la réalisation du standard, voici quelques repères temporels pour chacune des étapes.

  • Émergence d'un besoin, exploration de l'existant - durée variable

La durée de ces phases exploratoires dépend beaucoup des situations. Votre présence sur cette page montre qu’elle a d’ailleurs certainement débutée (ou même qu’elle touche à sa fin).

  • Initialisation des travaux et cadrage du GT - de 1 à 6 mois

Après la validation du besoin par la commission besoin et usages, il faut généralement compter de 1 à 6 mois pour obtenir la validation du mandat du GT par la commission des standards. C’est principalement la disponibilité de l’animateur qui va dimensionner cette étape lors de laquelle il doit identifier et contacter les participants et rédiger le mandat du GT.

En cas de demande urgente, le secrétariat général du CNIG peut valider une demande d’élaboration d’un standard en informant a posteriori la commission « Besoins et usages ».

  • Réalisation du Standard - de quelques mois à plusieurs années

La réalisation du standard est une étape plus ou moins exigeante selon la complexité du sujet et la disponibilité des membres du GT. Le travail de rédaction peut être retardé par des difficultés à obtenir un consensus sur des sujets de désaccord entre les membres. Identifier ces sujets en amont peut vous permettre de mieux planifier les travaux.

  • Validation du standard - de quelques jours à quelques semaines

Une présentation bien préparée devant la commission des standards, le suivi rigoureux du processus CNIG et le sérieux des travaux tout au long de la procédure garantissent généralement l’adoption du standard. La validation formelle de la commission des standards sera suivie de la validation définitive par le conseil plénier du CNIG, qui se réunit deux à trois fois par an.

Dans le cas d'un conflit de calendrier, le Secrétariat Général peut vous accompagner pour identifier des solutions en lien avec le président ou la présidente de la commission des standards.

  • Déploiement du standard - variable

Le déploiement du standard sort du cadre du GT du CNIG. La durée de cette étape dépendra des situations à mettre en œuvre et peut se poursuivre dans le temps avec l’arrivée de nouveaux acteurs à former, des évolutions à apporter au standard, le développement de nouveaux outils, etc.

En résumé, les standards sont réalisés en 18 mois en moyenne, bien que la durée du processus soit assez variable : de 9 mois pour les plus rapides à plusieurs années pour les plus complexes (selon le nombre d’acteurs impliqués, le périmètre des travaux, les difficultés de calendrier…).

Note : Ces durées sont purement indicatives et fondées sur les pratiques observées avant la création de la Fabrique des standards, qui vise à optimiser le processus. Dans un objectif “d’industrialisation” des standards, nous espérons permettre aux porteurs d’améliorer l’efficacité du processus.

Avant de se lancer : le rôle du pilote

Le pilote est un organisme qui accepte de supporter les travaux par un soutien qui peut prendre différentes formes. Il voit généralement un intérêt direct pour lui-même dans l'élaboration du standard (ou dans le cadre d'une politique qu'il est en charge de mettre en œuvre), et décide ainsi de s'impliquer directement dans sa création. En pratique, son rôle peut être :

  • d'assurer la cohérence avec les politiques publiques,

  • d'apporter sa légitimité et sa visibilité aux travaux, notamment en mobilisant son carnet d'adresse (pour trouver des participants au GT, des testeurs, des utilisateurs, etc.),

  • de coordonner les travaux avec ses équipes métiers (futures utilisatrices du standard en projet ou en charge d'élaborer la réglementation ayant conduit au besoin de standard par exemple),

  • de financer ou d'identifier un sponsor pour financer les travaux.

Le rôle du secrétariat général du CNIG

Lors de l'initialisation des travaux, le secrétariat général vous accompagne pour :

  • la planification des travaux, en vous apportant davantage d'informations sur la procédure.


Retour à la page d'accueil ↓

Page précédente et page suivante ↓

La fabrique des standards

Ressources utiles

Modéliser des données

La modélisation des données est une compétence du domaine de l'informatique pour laquelle plusieurs concepts peuvent être utiles, tels que :

  • [débutant] les ressources du cours "Bases de données" de l'IMT Atlantique,

  • [averti] le support du cours "UML et les bases de données" de l'IRIT,

  • [débutant] le cours en ligne "Web sémantique et Web de données" d'Inria sur FUN MOOC,

  • [débutant] le module "Introduction à la modélisation conceptuelle de données avec UML" de l'UTC,

  • [avancé] les ressources produites par Stéphane Pelle à l'ENSG,

Directive INSPIRE

  • le guide de saisie des éléments de métadonnées INSPIRE du CNIG,

Outils

[🚧 en construction 🚧]

Besoin d'inspiration ?

Voici une liste de ressources qui pourront alimenter votre réflexion, ou vous permettre de vérifier l'exhaustivité de votre standard :

  • Un fil de discussion sur TeamOpenData sur la documentation des données. Les références listées fournissent un cadre généraliste pour la documentation des données et peuvent vous faire penser à de nouveaux sujets ayant vocation à être précisés dans le standard.

  • Le guide sur les principes généraux de qualité des données du Ministère de la Transition Écologique,

  • le référentiel général d'interopérabilité de la Direction Interministérielle du Numérique (DINUM),

Glossaire de la Fabrique des standards

Ce glossaire précise les termes spécifiques à la Fabrique des standards. Il complète les définitions du le site du CNIG, ainsi que celles liées à l'univers de l'open data du lexique de l'open data de la DINUM.

Animateur, animatrice

L’animateur a les missions suivantes :

  • Gérer la liste des participants au GT,

  • Organiser les réunions : fixer les dates, lieux (lien visio), et l’ordre du jour,

  • Animer les réunions, organiser les travaux,

  • Rédiger et diffuser les compte-rendus,

  • Organiser avec le secrétariat général la communication autour du GT,

  • Alerter le secrétariat général en cas de difficulté.

Il est recommandé de prévoir un binôme d’animateurs, en particulier "numérique" et "métier" lorsque les deux compétences ne sont pas maîtrisées par la même personne. Le secrétariat général peut apporter son soutien aux animateurs pour certaines actions et tout au long des travaux du GT.

Participant, participante

Le participant s’engage à prendre part aux travaux en assistant a minima aux réunions organisées par le GT. Il est attendu qu’il ou elle apporte son expertise à l’oral lors des réunions, ou sur les livrables (par la rédaction, la relecture, les suggestions,etc.) dans la mesure de sa disponibilité.

Son activité est volontaire, elle requiert l'accord de son organisme notamment parce qu'elle n'est pas rétribuée.

Pilote

L’objectif du pilote est de mener à bien la production du standard, dans le délai prévu, en s’assurant :

  • De la composition et de la bonne participation des différentes parties prenantes au GT,

  • Du respect des procédures de la Fabrique de standards.

Le pilote peut être animateur du Groupe de travail, ou confier l’animation à un ou des animateurs.

Standards de données

D’une manière générale, un standard de données est une exigence qui est destinée à établir une compréhension commune de la sémantique des données entre producteurs et utilisateurs, afin d'en assurer la qualité et l’interopérabilité. Appliquer un standard peut permettre en pratique de mettre en commun des données provenant de différentes sources, de répliquer un projet d’une base de données à l’autre, ou encore d’uniformiser les méthodes de collecte des données.

Toutefois, il n’existe pas de règle précisant le formalisme ou le périmètre des standards de données, le terme peut ainsi désigner des documents relativement différents en pratique. Ce qui est entendu dépend généralement de l’émetteur du standard (CNIG, ISO, W3C, etc.), des données sur lesquelles il porte (relevés scientifiques, éléments du paysage, typologie de documents, pathologies médicales, etc.), ou encore des pratiques du domaine (techniques et outils comme le langage informatique utilisé, méthodologie de travail, pratiques en sources ouvertes, etc.).

Atteindre un consensus

La rédaction d’un standard nécessite la confrontation de profils diversifiés aux points de vue potentiellement divergents. La prise de décision dans le groupe peut sembler difficile lorsque les désaccords sont très prononcés. Lorsque le consensus n'est pas atteint dans le fil de discussion portant sur un sujet spécifique, la méthodologie suivante aidera l’animateur à organiser une session d’atteinte de consensus sur ce sujet. Elle est issue de la littérature sur le sujet, adaptée au cas de la production d’un standard.

1

Définir et énoncer précisément l'objectif

Lors de la session de prise de décision, la question doit être claire pour l’ensemble des participants, en tenant compte des informations dont ils disposaient auparavant. Clarifier la question posée, définir les termes du sujet et l’enjeu de la réunion aidera chacun à se former un avis. Il est aussi utile de préciser le cadre de la prise de décision pour que les contraintes soient bien comprises et favoriser les comportements bienveillants (comme la durée de la séance, les étapes, etc.).

2

Explorer et exposer les différentes pistes

Les pistes déjà identifiées et les points de vue des participants doivent être posées sur la table avec leurs qualités et défauts. Cette étape se doit d’être exhaustive pour que la prise de décision soit éclairée et que chacun énonce son point de vue dans un premier temps. Une pré-sélection des pistes possibles peut ensuite avoir lieu pour écarter les solutions remportant le moins l’adhésion. Il faut en revanche attendre la fin du tour de table pour discuter des solutions et éviter d’orienter le débat qui va suivre.

3

Évaluer les solutions

Dans cette phase de débat, les points d’adhésion et de divergence doivent être notés, et l’animateur doit encourager les participants à identifier des pistes pour solutionner les désaccords.

4

Construire une première proposition

A partir des discussions précédentes, la piste pour laquelle les désaccords semblent résolvables est approfondie et détaillée dans une proposition. On cherche à en peaufiner tous les aspects, et notamment les points de divergence restants. La solution doit essayer de répondre aux besoins des parties prenantes pour lever les blocages. Un délai de réflexion peut être utile pour une décision complexe.

5

Soumettre la proposition

Une fois que tous les points ont été débattus, la proposition peut être proposée à l’adoption du groupe. Les participants doivent exprimer leur accord ou leur désaccord selon plusieurs types :

  • accord : le participant accepte la proposition sans réserve ;

  • réserves : le participant n'est pas convaincu par la proposition, mais ne s’y oppose pas et s'impliquera dans sa mise en œuvre ;

  • retrait : le participant ne cautionne pas la décision pour des raisons qui peuvent être diverses - faute de temps, désaccord total avec la proposition, etc. - mais ne veut pas empêcher le groupe d'avancer. Il laisse la décision se prendre, mais ne s'impliquera pas dans sa mise en œuvre.

  • blocage : le participant n'adhère pas du tout à la proposition et demande la recherche d'une nouvelle proposition. Le groupe devra soit accepter le blocage et trouver une nouvelle proposition ou bien solutionner les points qui bloquent le consensus.

La proposition est considérée comme adoptée lorsqu'il n'y aura que peu de réserves et/ou de retraits et aucun blocage. Avant cela, il peut être nécessaire de revoir la proposition et d’apporter des modifications pour lever les points de blocage.

Alors ... on vote ?

Contrairement à la démarche précédente, qui (si elle aboutit) conduit à une solution pour laquelle tous les points de blocage ont été levés, le vote peut être insatisfaisant pour certains participants. Sans débat sur la proposition, elle reste figée à son stade initial avec ses avantages et désavantages. Le vote permet d’obtenir une solution mais oppose alors deux camps. Il reste possible en fin de processus pour aboutir à une solution, ou pour mieux identifier les oppositions. Enfin, le vote peut être une approche démocratique si chacun est suffisamment représenté parmi les votants dont chaque voix équivaut à un vote. Au contraire, il peut être déséquilibré si un parti est surreprésenté dans le groupe. Dans le cas où un vote a lieu, il est donc important de veiller à la présence des participants et à ce qu’un camp ne soit pas surreprésenté.

Gérer un dépôt Github

Pourquoi un dépôt Github

Utiliser un dépôt github est nécessaire pour que le standard soit référencé sur le site schema.data.gouv, qu’il contienne un schéma de données ou non. C’est donc obligatoire pour la publication d’un standard CNIG. Les étapes à suivre pour créer le dépôt et l’alimenter sont décrites dans [le modèle de dépôt Github](https://github.com/cnigfr/cnig-template).

Github peut également être un outil collaboratif utile pour la réalisation du standard. Il est prévu pour travailler en commun sur du code informatique principalement, mais il est tout à fait pertinent pour travailler sur des documents texte, à condition d’utiliser le format markdown, qui est le mieux géré par l’outil (les formats textuels habituels comme le word ou le pdf sont sauvegardés au format binaire, ce qui rend plus difficile la gestion des versions). Sa prise en main n’est pas très exigeante lorsqu’on est à l’aise avec l’informatique, mais cette option est tout de même déconseillée sans un minimum d'initiation ou de formation pour un animateur qui n’aurait jamais utilisé Github.

Voici quelques conseils pour la prise en main.

Comment fonctionne Github

Github propose à titre gratuit (à condition de respecter une limite de mémoire) l’hébergement et le suivi de fichiers en ligne. Il s’agit d’un gestionnaire de version collaborative, c'est-à-dire qu’il permet de travailler en communauté sur des fichiers dont les modifications sont traçables et réversibles. Les fichiers sont mis à jour version par version, sur proposition de la communauté et après approbation des administrateurs d’un dépôt. Il permet également de réaliser des tests automatisés (procédure d’intégration et de développement continus, ou “CI/CD pipeline” en anglais) et s’intègre très bien avec un grand nombre d’outils informatiques.

Il est nécessaire de créer un compte pour créer un dépôt Github ou y contribuer (voir la procédure documentée par Github).

Important : toutes les modifications apportées doivent être validées par un “commit”. Les commits sont des actions réversibles qu’il est possible de tracer dans le temps. C’est pourquoi il est utile de les décrire autant que possible dans leur titre et dans leur description. Pour une utilisation simple de Github (une seule branche de travail), le niveau de connaissance sur le versionnage nécessaire est très faible (le contenu de cette page devrait suffire). Pour une utilisation plus poussée, il peut être utile de se référer à une documentation plus complète comme celle de Github sur les demandes de tirage (ou pull request en anglais).

Créer un dépôt

Il est généralement conseillé de partir de l’existant pour créer un dépôt Github, en utilisant un modèle (comme le modèle de dépôt du CNIG) ou en repartant d’un dépôt existant de manière incrémentale (une “fork”, comme décrit sur cette page).

Le dépôt possède un fichier README.md où il est décrit. Son organisation est laissée libre après cela. L’utilisation de Github peut se faire en ligne sur l’interface Web, via des éditeurs intégrant Github, ou encore par ligne de commande (mais cela est réservé aux utilisateurs avancés et généralement réservé aux dépôts de code).

Créer ou modifier un fichier

Plusieurs méthodes existent pour créer un fichier. Il est possible d’en créer un de toutes pièces pour les formats de fichier simples (textuels comme .md, .txt, etc. ou d’échange de données comme .json, .yaml, etc.), en précisant le format du fichier en suffixe de son nom lors de sa création. Les fichiers peuvent également être importés. Dans les deux cas, il faudra cliquer sur le bouton “Add a file” après s’être placé dans le dossier de destination, sélectionner l’option souhaitée (“Create” ou “Import”), réaliser l’action et la valider par un commit.

Créer un dossier

Github ne supporte pas les dossiers vides. L’unique solution pour créer un dossier est donc de créer un fichier. Pour créer un fichier dans un nouveau dossier, il faut cliquer sur “Add a file”, puis “Create”, et enfin créer le nouveau dossier dans le nom du fichier. Dans le nom du fichier, commencer par taper le nom du nouveau dossier “Dossier1”, puis faites suivre ce nom d’une barre oblique “/”. L’interface devrait interpréter directement ce symbole et vous verrez qu’un dossier a été ajouté dans le chemin conduisant au fichier.

Une bonne pratique est de créer un fichier “README.md” pour chaque dossier.

Déplacer un fichier

Les fichiers ne peuvent être déplacés que via l’interface d’édition de fichier. Il faut donc cliquer sur “Edit” sur le fichier cible, et modifier le chemin vers le fichier dans son nom (la touche retour arrière permet d’éditer le chemin précédent le nom du fichier).

Gérer un dépôt

La documentation de Github pour la gestion de projet est une référence utile, à compléter au cas par cas par des recherches en ligne, sur des forums dédiés par exemple.

La gestion des droits

Par défaut, un dépôt public ne peut être modifié que par son administrateur bien qu’il soit visible de tous. Pour permettre à un co-animateur, par exemple, de le modifier, il faut l’ajouter en tant que contributeur (Settings/Access/Contributors/Add people). Il est recommandé de privilégier les “issues” pour les membres du GT moins familiers avec Github, où ils peuvent faire des retours sous la forme de commentaires. Il n’est pas nécessaire de les inscrire en tant que “contributeurs” pour cela.

La gestion des contributions

Les membres de la communauté n'ayant pas de droit de modification sur le dépôt peuvent utiliser deux méthodes pour proposer des modifications :

  • les “issues” (ou "contribution"), sous la forme de commentaires libres, et

  • les “pull requests” (ou "demande de tirage"), où les modifications sont réalisées dans une version de travail des fichiers.

Pour les besoins d’un standard, les issues sont généralement suffisantes, mais les pull requests peuvent permettre de proposer des modifications plus précises. Le rôle de l’administrateur est de relire ces issues et pull requests et d’en vérifier le contenu. L’administrateur modifie les fichiers pour prendre en compte une issue. Pour une pull request, il n’a pas besoin de prendre la plume et peut directement accepter les suggestions (ce qui entraîne une modification des fichiers, bien qu’elle soit toujours réversible) ou les refuser.

Maintenir un dépôt

Après la publication initiale, une maintenance peut être assurée pour prendre en compte les retours lors de l’appel à commentaires, mais aussi sur le plus long terme si le standard doit être mis à jour.

Il est recommandé de ne mettre à jour la branche principale “master” (c’est-à-dire la version utilisée par le public) que lorsqu’une nouvelle version est prête pour publication. Le nom du commit doit alors indiquer le numéro de version correspondant.

Les modifications sont automatiquement répercutées sur schema.data.gouv, il faut donc être prudent dans les changements apportés. Il est nécessaire de communiquer sur la publication d’une nouvelle version pour s’assurer que celle-ci est prise en compte par les utilisateurs.

Réaliser un appel à commentaires

1

Avant l’appel à commentaires

  • Déposer le projet de standard et les éventuels documents associés sur lesquels porte la consultation (guide, annexes, etc.) sur un espace partagé avec le GT,

  • Finaliser une version du projet de standard et demander l'approbation du GT pour le soumettre à l'appel à commentaires,

  • Annoncer l'appel à commentaires en commission des standards et au sein du CNIG (secrétariat général, GT et Commissions concernées par le standard). Il est aussi recommandé de réaliser un point d’avancement en commission des standards avant l’appel à commentaires, en se concentrant sur les décisions prises et les consensus atteints au sein du GT (la présentation du contenu du standard interviendra après l’appel à commentaires).

2

Préparer l'appel à commentaires

  • Prendre en compte les dernières modifications et finaliser le standard. Entre autres :

    • Finaliser les documents :

      • supprimer les derniers commentaires, marques de révision, et les surlignages,

      • éditer les propriétés du document pour supprimer les informations personnelles (sous Microsoft Word : “Fichier”/”Informations”, “Vérifier l’absence de problèmes” puis “Supprimer tout” si l’analyse est positive pour “propriétés du document et informations personnelles”),

      • vérifier le nombre de pages,

      • vérifier haut et bas de page,

      • actualiser l'index.

    • Les exporter au format pdf,

    • Les déposer sur un espace partagé public,

  • Préparer une "note de création (ou de révision) du standard" à l’intention de la Commission des Standards,

  • Déterminer la date de la Commission des standards visée en vous référant à son calendrier.

  • Déterminer les dates de l’appel à commentaires, en prévoyant suffisamment de temps entre la fin de l’appel à commentaires et la date de la Commission des standards pour traiter les retours, tout en respectant un délais d'au moins un mois entre le début et la fin de l'appel.

Il peut être utile de prendre en compte les événements qui pourraient causer une perte ou un gain de visibilité de l’appel à commentaires (conférence, assises, événements politiques, élections, vacances scolaires, etc.).

  • Préparer le tableau de recueil des commentaires vierge (voir le modèle proposé ci-dessous). A noter que la transmission des retours par ce tableau n’est pas toujours idéale car elle nécessite un traitement manuel pour agréger l’ensemble. Les animateurs sont libres d’utiliser tout autre outil qui leur semblerait plus approprié.

Choisir le type de commentaire :

Quatre types de commentaires existent : général, métier, technique ou éditorial. Les participants à l'appel à commentaires indiquent le type de commentaire en inscrivant la première lettre du type (G, M, T ou E) dans la colonne dédiée. Ces types ont les significations suivantes :

  • Général : ce sont les commentaires portant sur la démarche du GT, l'objectif du standard, ou qu'il peut être difficile d'assigner aux trois autres catégories ;

  • Métier : correspond à un commentaire sur le fond du sujet, et dont le traitement pourrait requérir des compétences métier davantage que techniques ;

  • Technique : à l'inverse des commentaires métier, ces commentaires portent sur les sujets liés à des compétences numériques ;

  • Éditorial : ces commentaires portent sur des modifications rédactionnelles ou syntaxiques à apporter au document.

Ces informations peuvent être transmises aux participants lors de l'appel à commentaire.

31KB
GT CNIG - Modèle de tableau de réponse à l'appel à commentaire.docx
Modèle de tableau de réponse à l'appel à commentaires
3

Lancer l'appel à commentaires

  • Se coordonner avec le secrétariat général, les membres du groupe de travail et les partenaires pour communiquer sur l’appel à commentaires. Le projet de standard, les éventuels documents associés soumis à consultation, ainsi que le tableau de recueil des commentaires sont déposés par le secrétariat général du CNIG sur la page du groupe de travail,

  • Communiquer sur le lancement : via les réseaux (GeoRezo par exemple sur le forum portant sur la thématique des données, etc.), l’organisation d’un webinaire (sur l’exemple de celui tenu pour le standard risque), etc. Le SG du CNIG communiquera sur l'appel à commentaires sur le site du CNIG et dans l’info-CNIG (la newsletter du CNIG).

4

Recevoir et traiter les retours

  • Instruire les commentaires,

  • Demander au secrétariat général de faire un rappel 2 semaines avant la fin de l’appel,

  • Éventuellement transmettre certains commentaires aux bureaux métier de vos institutions d'appartenance en demandant une décision lorsque c'est nécessaire,

  • A l'échéance, envoyer un mail aux contributeurs pour accuser bonne réception et les remercier,

  • Élaborer un tableau de synthèse et y inscrire les décisions prises pour chaque commentaire,

  • Présenter la synthèse des commentaires et les résultats de l’instruction au GT CNIG, et finaliser ensemble le standard avant sa validation,

  • Transmettre le tableau de synthèse des commentaires aux contributeurs.

Communiquer sur l'appel à commentaire

L'appel à commentaires doit préciser plusieurs informations :

Ce projet de standard a été élaboré à la fois sous l'égide du CNIG en suivant son processus, tout en respectant le référentiel schema.data.gouv.fr.

Modèle de mail d’information sur l’appel à commentaire

Bonjour à tous,

J'ai le plaisir de vous informer que le standard CNIG <thematique> <version> a été présenté à la Commission des Standards du <date>, qui l'a validé avec/sans réserve.

Le standard permettra d'alimenter en données le <portail national (ou autre cas d'usage : donner des informations sur l'utilité du standard)>.

Nous pouvons nous enorgueillir ensemble de cette œuvre de standardisation menée en <durée en mois>, au bénéfice des collectivités, des développeurs de solutions numériques, et de toutes les parties prenantes sur le sujet de la <thématique>.

Il s'agit d'une première étape importante. Le standard sera très probablement amené à évoluer en fonction de l'expression des besoins de sa communauté d'utilisateurs, de son écosystème technique applicatif, et des évolutions réglementaires.

Je tiens à souligner que rien n'aurait été possible sans les <parties prenantes> et leur volonté commune de travailler conjointement à l'élaboration du standard national.

Chaleureusement, merci à tous pour le travail accompli et la vitalité de notre collectif !

Cordialement,

<l'animateur du GT CNIG>

Validation du standard

Avant sa publication le standard doit encore franchir différentes étapes, décrites ci-dessous.


Actions de la phase

1

TEST DU STANDARD (facultatif)

Identifier un acteur volontaire pour tester concrètement le standard. Il est conseillé de vérifier que le test permet de vérifier de bout en bout l’efficacité et la clarté du standard (sa compréhension par les équipes métier, son implémentation par les équipes numérique, son intégration dans les outils, etc.). Ces tests doivent permettre de vérifier que le stade de “produit minimum viable” a été atteint, mais ne permettront pas de vérifier des objectifs plus poussés (comme des améliorations dans la découvrabilité des données, la réplicabilité des solutions, etc.). Les résultats de ces tests doivent être documentés.

Exemples :

  • le standard risques - profil applicatif PPR testé par la DDT de l’Isère (voir ce retour d’expérience dans une présentation),

  • le standard paysage testé par plusieurs collectivités (voir le Compte-rendu GT du 19 mars 2024 sur la page du GT Paysages). Plusieurs documents de travail du GT peuvent être utiles à titre d'exemple :

    • une présentation à destination des testeurs, leur donnant notamment des consignes,

    • un modèle de rapport pour les testeurs visant à recueillir les résultats.

2

APPEL A COMMENTAIRES

L’appel à commentaires est une consultation publique. Il s'agit d'une étape indispensable avant la validation du standard par la commission des standards. L'appel à commentaires CNIG ne peut se dérouler qu’à la fin de la phase de rédaction du standard et des autres livrables éventuels (schéma, Github, annexes, documentation, etc.). L’appel à commentaires doit viser un public large, en s’assurant que les principaux intéressés en sont informés (parfois avant même le lancement pour s’assurer que cela sera pris en compte dans leur calendrier). Le traitement des commentaires peut représenter une charge importante pour les animateurs qu’il est préférable d’anticiper.

La démarche à suivre est détaillée dans une page dédiée.

3

DERNIÈRES VÉRIFICATIONS

Faire valider un standard : synthèse des conditions à respecter

S’il est impossible de donner tous les critères de validation d’un standard étant donné la particularité de chacune des situations, une “obligation de moyens” est à respecter. Ces obligations sont les suivantes :

  • le respect de la procédure du CNIG décrite ici ;

  • l’ouverture et la représentativité du groupe de travail et l’atteinte d’un consensus sur le standard obtenu ;

  • la soumission du standard à un appel à commentaires et la prise en compte des retours ;

  • l’utilisation (conforme) des méthodes et modèles proposés par la Fabrique des standards ;

  • plusieurs conditions additionnelles :

    • publication des documents de travail du GT (mandat, CR des réunions, etc.),

    • publication du standard sur le site du CNIG sous une licence ouverte,

    • publication sur schema.data.gouv.

4

VALIDATION DU STANDARD

Le projet de standard est soumis à validation à la Commission des Standards puis au Conseil plénier du CNIG.

  • Présentation à la commission des standards

La commission des standards se réunit environ une fois par trimestre, il est donc préférable d’anticiper la date visée dans votre calendrier. Une fois la date identifiée, la commission doit être contactée pour inscrire la présentation du standard à son ordre du jour. Pour cela, il convient d’envoyer une demande à la présidente de la commission ou au secrétariat général en indiquant le lien vers le standard. Il sera également demandé de préparer une présentation. Aucun modèle n'est proposé pour cette présentation car nous vous encourageons à utiliser une identité visuelle pour le standard, ou à utiliser celle de votre institution d'appartenance. Voici les informations qu'il est conseillé de faire figurer dans cette présentation :

  • Le contexte

    • Définir les termes si cela est nécessaires à la compréhension du sujet,

    • Présenter le sujet, le contexte réglementaire,

    • Indiquer si la thématique possède un lien avec la directive INSPIRE,

    • Exposer les enjeux, problématiques et objectifs opérationnels du standard.

  • Le groupe de travail

    • Présenter le pilote, les animateurs, les participants et les autres acteurs impactés par la thématique,

    • Revenir sur le déroulement des travaux du GT et le calendrier suivi en donnant les dates les plus importantes (saisie du CNIG, passage dans les différentes commissions, appel à commentaire etc.),

    • Présenter succinctement les outils utilisés.

Utiliser les phases détaillée dans cette documentation dans la mesure du possible (émergence d'un besoin, exploration de l'existant, etc. jusqu'à la validation du standard). Cela permettra de vérifier leur pertinence, de donner des indications sur la durée de chacune des phases, et d'améliorer la procédure.

  • Le projet de standard

    • Décrire le standard, à qui il s'adresse et ses cas d'usage,

    • Lister les interactions avec les standards et normes existants ou en projet,

    • Indiquer les limitations du standard (ce qu'il ne couvre pas par exemple),

    • Présenter le modèle conceptuel de données dans les grandes lignes, le catalogue d'objet, le schéma de données éventuel, l'éventuel jeu de données de test construit et comment trouver ces documents,

    • Indiquer les ressources documentaires complémentaires.

  • La démarche suivie et les suites prévues

    • Décrire les décisions et partis pris par le GT lors de l'élaboration du standard présentant un intérêt pour la commission,

    • Revenir sur l'appel à commentaire en décrivant la démarche suivie, les retours obtenus (leur nombre, leur contenu) et les conclusions tirées,

    • Donner les perspectives du GT pour la suite (comme les projets à venir fondés sur le standard, le travail de maintenance du standard, l'accompagnement au déploiement, etc.).

Suite à la présentation, la commission vote l’adoption du standard ou demande à ce que certaines modifications soient effectuées. Ces modifications ne nécessitent pas toujours un nouveau passage devant la commission avant la présentation au plénier (n’entraînant ainsi pas de retard pour l’adoption finale).

  • Présentation au conseil plénier du CNIG

Le standard doit être validé par le conseil plénier pour être formellement adopté par le CNIG. Lors du plénier, le standard n’est pas toujours présenté, mais il doit être décrit dans un dossier transmis en amont au conseil. Ce dossier est rédigé par le secrétariat général en lien avec l'animateur du GT (il se présente sous la forme du modèle proposé plus bas pour information). Ce dossier sera transmis au conseil plénier par le secrétariat du CNIG, avec l'ensemble des pièces, 2 semaines avant la séance.

Des questions ou demandes peuvent être formulées à l’oral par les membres du conseil. S'ils participent au conseil plénier, les animateurs du GT sont invités à répondre aux questions à ce moment-là, ou à prendre note des demandes pour modification ultérieure. Ici encore, si la présentation a été suffisamment anticipée, les retours du conseil ne bloquent généralement pas l’adoption du standard.

5

PUBLICATION DU STANDARD

Une fois validé par la Commission des Standards, le standard est publié comme standard validé sur le site du CNIG.

Il est également référencé sur schema.data.gouv.fr sous le label « publié » qui remplace le label « en construction ». Pour cela, le dépôt Github doit être finalisé avant de solliciter l'équipe de schema.data.gouv qui réalisera le référencement.

Le rôle du secrétariat général du CNIG

Lors de la validation du standard, le secrétariat général vous accompagne pour :

  • la coordination avec la commission des standards pour la validation du standard (si besoin),

  • la rédaction du dossier de présentation au plénier en lien avec les animateurs,

  • la présentation au plénier.


Ressources utiles

Modèle de dossier de présentation en plénier

Ce modèle de document vise à indiquer les informations attendues par le plénier, mais c'est au Secrétariat Général et non à l'animateur du GT de le remplir.

51KB
GT CNIG - Modèle de dossier de présentation au plénier.docx
Modèle de dossier de présentation pour le conseil plénier

Retour à la page d'accueil ↓

Page précédente et page suivante ↓

Utiliser le modèle de dépôt Github

Tout d'abord, pour accéder au modèle de dépôt, suivez le lien suivant :

Le modèle de dépôt Github du CNIG contient les fichiers nécessaires pour démarrer la création d'un dépôt de standard, il est également conforme à ce qui est demandé par schema.data.gouv pour un schéma au format Table Schema. A noter que la création d'un schéma n'est pas obligatoire pour la création d'un standard CNIG. En revanche, il est obligatoire de créer un dépôt Github afin que le standard soit référencé sur schema.data.gouv.

Utiliser le modèle

Si vous créez votre dépôt sur GitHub, il vous suffit d'appuyer sur le bouton vert "Use this template" en haut à droite (consultez la documentation de github pour plus d'infos à ce sujet). Pour un standard CNIG, voici quelques recommandations spécifiques :

  • "Include all branches" : laisser décoché,

  • "Repository name" : le nom choisi doit commencer par "Standard" suivi d'un espace et du nom du standard,

  • "Public/Pivate" : choisir "Public" pour que le dépôt soit visible par tous (vous seul pouvez le modifier pour le moment, mais il vous sera possible d'ajouter des collaborateurs comme décrit plus bas).

L'organisation du dépôt

Ce dépôt contient un ensemble de dossiers et fichiers utiles pour le dépôt d'un standard.

  • README.md est le point d'arrivée sur le dépôt, c'est un fichier terme au format markdown. Dans le modèle de dépôt, il s'agit d'un modèle de fichier à adapter, mais à terme, il devra présenter votre standard ;

  • schema est le dossier où l'on peut trouver le schéma au format Table Schema, ainsi qu'une documentation pour la rédaction du schéma. Ce dossier peut être supprimé si le standard ne possède pas de schéma. Dans ce cas, il faut conserver le fichier schema.yml suivant ;

  • schema.yml est un fichier qui remplace le schéma de données lorsque le standard ne possède pas de schéma. Il doit être supprimé si le standard possède un schéma. Sinon, il doit être complété ;

  • ressources contient les fichiers utiles pour l'utilisation du standard élaborés par le groupe de travail ou provenant de sources tierces ;

  • groupe_de_travail_CNIG est le dossier de travail du GT, dans lequel peuvent être référencés les comptes-rendus de réunion et tous les documents de travail (ce dossier peut être supprimé si le GT choisit un autre outil que github pour collaborer) ;

  • CHANGELOG.md contient la liste des changements entre les différentes versions de votre standard ;

  • exemple-valide.csv est un fichier CSV d'exemple conforme ;

  • LICENSE.md est le fichier de licence du dépôt. Nous recommandons d'utiliser la Licence Ouverte, cette licence est recommandée par l'administration française pour le partage de données et de documents ;

  • requirements.txt liste les dépendances Python nécessaires pour effectuer des tests en intégration continue sur votre dépôt (il n'est pas nécessaire de modifier ce fichier) ;

  • .gitignore : fichier généré automatiquement par github pour le suivi des versions de documents. Vous pouvez ignorer ce fichier.

A noter : Il est conseillé de se familiariser avec la syntaxe markdown utilisée dans les documents ".md" avant de se lancer dans leur rédaction (pour cela, la documentation de Github peut être utile).

Étapes à suivre

Nous détaillons ci-dessous les étapes que nous vous conseillons de suivre après avoir créé votre dépôt Github, tout en utilisant les fichiers d'exemples.

Si votre standard ne possède pas de schéma

Si votre standard possède un schéma

Intégration continue

Ce dépôt est configuré pour utiliser de l'intégration continue, si vous utilisez GitHub. À chaque commit, une suite de tests sera lancée via GitHub Actions afin de vérifier :

  • que votre schéma est valide à la spécification Table Schema ;

  • que vos fichiers d'exemples sont conformes au schéma.

Si vous n'utilisez pas GitHub, vous pouvez lancer ces tests sur votre machine ou sur un autre service d'intégration continue comme Gitlab CI, Jenkins, Circle CI, Travis etc. Consultez la configuration utilisée dans .github/workflows/test.yml.

Localement, voici la procédure à suivre pour installer l'environnement de test et lancer les tests :

# Création d'un environnement virtuel en Python 3
python3 -m venv venv
source venv/bin/activate

# Installation des dépendances
pip install -r requirements.txt

# Test de la validité du schéma
frictionless validate --type schema schema.json

# Test de la conformité des fichiers d'exemples
frictionless validate --schema schema.json exemple-valide.csv

Lien avec la page sur Schema.data.gouv

Le dépôt github est la source depuis laquelle la page sur schema.data.gouv prend son contenu. Les correspondances suivantes sont effectuées :

  • le fichier README.md apparaît dans l'onglet d'accueil "Informations",

  • le fichier CHANGELOG.md apparaît dans l'onglet "Changements",

  • les onglets "Documentation" et "Réglementation" sont générés automatiquement.

Les boutons au sommet de la description du standard permettent de réaliser plusieurs actions :

  • "Saisir ou valider mes données" : renvoi vers la page "publier.etalab.studio" qui accompagne l'utilisateur pour la production de données conformes à votre standard,

  • "Schéma" : renvoie vers une visualisation du schéma au format JSON (ou YAML quand le standard ne possède pas de schéma de données),

  • "Données" : renvoie vers la page de data.gouv référençant toutes les données conformes au schéma qui y sont publiées,

  • "RSS" : permet de s'abonner au flux RSS lié au schéma par lequel des informations sur ses évolutions peuvent être communiquées,

  • "Git" : renvoie vers ce dépôt Github.

Documentation

Pour vous aider dans la construction de votre dépôt, nous vous recommandons de vous référer à :

  • Le guide pour la création de schémas

  • Le guide pour l'intégration de schémas à schema.data.gouv

  • la documentation de Github pour le langage markdown utilisé dans les fichiers ".md", comme ce README.md

  • La documentation de schema.data.gouv.fr

  • La spécification Table Schema

  • Les règles Semver de numérotation des versions

Réalisation du standard

Le groupe de travail a pour mission d'organiser un travail collaboratif pour élaborer un standard qui fasse consensus.


Actions de la phase

1

PROCESSUS D'ÉLABORATION DU STANDARD

  • Le standard prend la forme d'un document sur la base du modèle de standard proposé par le CNIG dans . Il est accompagné d'un dépôt Github suivant , et il peut éventuellement contenir un schéma au format attendu par le site schema.data.gouv, comme décrit par .

  • Les modalités de travail pour la rédaction du standard sont libres. Généralement, il s’agit de réunions plénières et régulières lors desquelles les avancées sont présentées et les points de fond sont discutés. Entre ces réunions, les membres contribuent à la rédaction du document de leur côté ou lors de réunions organisées en sous-groupes.

  • Les comptes-rendus des travaux réalisés en groupe de travail doivent être publiés à la suite de chaque réunion plénière sur . L’animateur du groupe de travail veille à leur bonne publication. Cela n’est pas obligatoire pour les réunions en sous-groupes : les conclusions de ces réunions sont généralement présentées lors des réunions plénières du GT et figurent donc dans leur compte-rendus.

  • Des tests peuvent être réalisés en cours d’élaboration du standard. Un dispositif de prototypage est alors créé par des membres du groupe de travail grâce à la création de jeux de données et d'un protocole pour tester les standards auprès des personnes qui les consultent. Certains outils comme (créé par OpenDataFrance et Etalab) peuvent être utiles lors de cette phase.

  • Si besoin, des points d’étapes peuvent être faits en commission des standards.

Comment nommer un standard ?

Le CNIG impose uniquement que le nom du standard soit au format "standard CNIG <nom de la thématique>". Ce format insiste sur le fait qu'il s'agit d'un standard, c'est à dire qu'il résulte d'un consensus, et qu'il a été adopté par le CNIG. Le nom de la thématique est libre, mais il convient de garder en tête qu'il doit :

  • être suffisamment évocateur pour être facilement retrouvé,

  • reprendre les termes communs sur la thématique pour faciliter la découvrabilité du standard (en reprenant le nom d'un plan national, d'un texte réglementaire, d'un système d'information, etc.),

  • être assez clair pour que l'on comprenne de quoi il s'agit.

Versionner un standard

La réflexion sur la gestion des versions doit avoir lieu dès la réalisation du standard. Vous pouvez vous inspirer de la méthodologie de gestion sémantique des versions utilisée par schema.data.gouv.

Quelques conseils sur …

La cohérence sémantique : une évolution à prendre en compte

Il s’agit ici de répondre au besoin d'interopérabilité sémantique. Il convient d’urbaniser les standards de données, dans l’objectif de résoudre les conflits et incompatibilités avec d’autres standards ou logiciels métiers développés pour manipuler des données dont la modélisation est conforme à certains standards.

En effet, le rôle de chaque organisation métier est de produire des modélisations de données propres à leurs vues métiers. Mais les standards ont vocation aussi à structurer une connaissance partagée de manière transverse aux métiers, et à en organiser la traduction dans les différentes modélisations (bases de données relationnelles, classes d’objet et données attributives, modèle clé-valeur, etc.) présentes au sein des infrastructures de données afin d’en faciliter le partage, la circulation et la réutilisation.

S'arrêter à une seule vue métier ne permet pas une réelle capitalisation de la connaissance entre standards, ni ne permet de mesurer ou minimiser pour un métier particulier les surcoûts liés une modélisation unifiée.

Par exemple, mettre en évidence qu’un point de prélèvement d’eau en nappe est en même temps : un équipement pouvant faire l’objet d’une description technique et d’un acte administratif, un point d’alimentation en eau potable, objet de surveillance sanitaire, et un générateur de servitudes, objet d’actes réglementaires, permet d’articuler de manière optimum la gestion et l’utilisation des données issues de ces différents points de vue métiers, qui nomment et structurent différemment la même réalité.

La démarche de standardisation doit donc permettre de faire converger ou articuler plusieurs standards en s’appuyant sur une analyse sémantique. Cette démarche s'appuie sur des référentiels sémantiques (des vocabulaires et des ontologies normalisés) aidant à l’analyse et à la conception des relations et des propriétés dans les modèles.

Le niveau sémantique ajouté en chapeau du niveau conceptuel (modélisation UML, ou équivalent) permettra de communiquer, capitaliser et mettre en cohérence les standards (mise en évidence des redondances, des concepts sous-entendus, des choix d’agrégation et de représentation implicites, etc.).

Concrètement il s’agit de décrire la correspondance entre les informations structurelles de chaque entité. Cette correspondance ne se limite pas à un simple renommage des propriétés, mais explicite les liens entre informations qui peuvent être réparties différemment dans les entités. On peut aller jusqu'à déterminer des règles de transformation ou de calcul pour certaines propriétés.

En contrôlant grâce à cette méthode la réversibilité de l’information entre différents modèles métier (la préservation de la sémantique), il devient également possible de détecter et gérer les incohérences entre modèles, de mesurer les impacts en cas d’évolution d’un modèle, et de décider d’une renormalisation directe ou différée.

Une fois cette étape réalisée, il devient possible de garantir que les ensembles de données provenant de différentes sources conformément aux différents standards urbanisés puissent être combinés et utilisés de manière cohérente.

L'adoption des principes de données liées à l'aide de normes du Web sémantique telles que RDF (Ressource Description Framework), SPARQL et OWL (Web Ontology Language) permettra de rendre les ensembles de données standardisés lisibles par machine et interconnectés, facilitant ainsi une intégration plus poussée et la découverte automatisée des données.

Pour aller plus loin : voir (Semantic Interoperability Community de l'Union Européenne).

Bonnes pratiques bonus :

  • Concevoir le standard de telle sorte à ce qu’il permette de limiter l’empreinte environnementale des données (en utilisant une maille géographique et un pas temporel adaptés, en évitant les champs redondants, en utilisant des types de données frugaux, etc.). Plus d’informations dans ,

  • Documenter les étapes en vue de la présentation à la Commission des standards où un retour sur la démarche sera attendu (cela permettra de cibler les étapes où cette procédure peut être améliorée).

2

CAHIER DES CHARGES A RESPECTER

Le standard doit respecter le modèle proposé (cf. les ressources utiles de cette page) et suivre les indications qui y sont données. Plus généralement, voici plusieurs recommandations ci-dessous.

Les standards du CNIG doivent obligatoirement détailler :

Additionnellement, le standard peut être complété par :

3

PROCESSUS DE RÉFÉRENCEMENT DU STANDARD

Dès son lancement, un standard peut être référencé sur le site du CNIG et sur le site schema.data.douv.fr .

Pour être référencé, le standard doit être identifié sur avec le label "en construction".

Le rôle du secrétariat général du CNIG

Lors du cadrage du GT, le secrétariat général vous accompagne pour :

  • la création du dépôt Github (si besoin),

  • le maintien de la page du GT sur le site du CNIG (publication des compte-rendus, annonce des réunions, etc.).


Ressources utiles

Modèle de standard proposé par le CNIG

Modèle de compte rendu de réunion

Exemple de données de test

Les schémas répertoriés sur schema.data.gouv sont généralement pourvu d'un échantillon de données de test, comme c'est le cas pour le .


Foire aux questions ↓

Comment référencer le standard sur schema.data.gouv ?

L'annonce sur schéma.data.gouv n’est pas automatique. Il est nécessaire de demander à l’équipe de la DINUM de le réaliser en suivant les étapes suivantes :

  • Sur la page Github de schema.data.gouv, , et sélectionner “Référencer un schéma”,

  • Remplir le modèle fourni (sans modifier les titres indiqués par les symboles #),

Note : pour vous familiariser avec la syntaxe markdown, peut être utile.

  • Cliquer sur “Create”,

  • Attendre le retour de la DINUM en commentaire de l’issue créée et prendre en compte les suggestions (il peut être nécessaire de mettre à jour votre abonnement aux alertes de Github dans l'onglet "Notifications" des paramètres de votre compte, ou de vous connecter régulièrement au site).

Comment publier un compte rendu (CR) de réunion ?

Le compte rendu de réunion est rédigé par l'animateur du GT quelques jours après la réunion (voir le modèle proposé plus haut). Il est d'abord soumis au groupe de travail pour relecture sous un délai raisonnable (une semaine convient) à indiquer aux membres.

A l'heure actuelle le CNIG ne propose pas d’outils de travail collaboratif en ligne. Les outils gratuits de type suite bureautique en ligne ou autres permettent généralement de répondre aux besoins des GT lorsque les institutions d’appartenance des animateurs ne peuvent pas mettre ces services à disposition (en prêtant attention à la protection des données confidentielles avec ces outils).

Après avoir tenu compte les retours de ses relecteurs, le CR est publié dans sa version finale dans l'espace de travail du GT (Github ou autre espace partagé) et sur la page du GT du site du CNIG, par le secrétariat général du CNIG à qui il aura été transmis

L'animateur informe ensuite sur la publication du CR :

  • le GT,

  • les personnes à informer au sein du CNIG,

  • les personnes externes concernées (comme la hiérarchie des animateurs).


Retour à la page d'accueil ↓

Page précédente et page suivante ↓

La fabrique des standards
les ressources utiles de cette page
le modèle proposé
ce modèle
le site du CNIG
Validata
Semver
les ressources du SEMIC
le référentiel GreenData d’OpenDataFrance
schema.data.gouv.fr
613KB
GT CNIG - Modèle de standard.docx
Modèle de standard
48KB
GT CNIG - Modèle de CR de réunion.docx
Modèle de compte-rendu de réunion de GT
schéma Friches
créer une “issue”
ce guide publié par Github

... Le travail de rédaction

... Les sujets techniques

La fabrique des standards

Déploiement du standard

Le déploiement n’est pas nécessairement du ressort du groupe de travail d’élaboration du standard au CNIG, mais ce dernier tient parfois un rôle dans son adoption.


Actions de la phase

1

ACCOMPAGNER LE DÉPLOIEMENT

L’accompagnement au déploiement est important mais n’est pas du ressort du groupe de travail d’élaboration du standard. Néanmoins, les membres du GT ayant généralement tout intérêt à poursuivre les efforts lors du déploiement, voici quelques pistes de réponses aux questions que vous pourriez vous poser :

  • Pourquoi ?

Le déploiement du standard est essentiel à son appropriation par l’ensemble des producteurs de données. Tous n’ayant pas participé au GT, l’accompagnement à sa compréhension et à sa prise en main sont nécessaires à son utilisation. Il s’agit aussi de mobiliser plus largement sur les enjeux portés par une politique publique lors de cette phase.

A cette étape, les services de communication des entités portant le standard peuvent être contactés pour établir une stratégie de diffusion.

  • Quand ?

Le déploiement peut être initié avant la validation du standard, pour susciter l’intérêt, bénéficier de la visibilité donnée par l’adoption en conseil plénier, et se laisser le temps de planifier une stratégie de communication. Il peut être bénéfique d’attendre le référencement du schéma et la publication de l’ensemble des documents utiles à son utilisation.

  • Pour qui ?

Le déploiement doit viser l’ensemble des acteurs concernés :

  • Avec qui ?

La communauté d’acteurs impliqués dans le GT doit être mobilisée en premier lieu. Le CNIG peut également venir en aide grâce à ses outils de communication, ou grâce à son lien avec les territoires. Le peut être contacté à cet effet.

Une fois les acteurs identifiés, un groupe de travail dédié à l’accompagnement peut être constitué.

  • Comment ?

Plusieurs moyens d’actions s’offrent à vous :

  • Avec quel budget ?

La question du budget peut être un obstacle lors de cette phase, il faut généralement prévoir le coûts liés à :

- l’ingénierie interne lié à l’hébergement des données, outils et supports liés à la thématique,

- la publication dans des revues spécialisées parfois payantes,

- l’animation de sessions, ateliers, etc.,

- la formation de l’animateur pour le déploiement s’il ne dispose pas de compétences en géomatique ou au domaine métier, qui lui seraient nécessaires pour le déploiement.

DU CÔTÉ DU PILOTE

Le pilote peut :

  • S'assurer qu'il y a une assistance utilisateurs.

  • Faire des recommandations pour le déploiement.

  • Alerter le commanditaire sur les conditions et modalités de déploiement du standard.

La commission des standards du CNIG pourrait faire régulièrement une revue des standards, assortie d'éventuelles recommandations.

2

MESURER L'ADOPTION D'UN STANDARD

Afin d’évaluer l’adoption d’un standard, plusieurs bonnes pratiques existent :

  • Utiliser les outils de référencement de la DINUM :

    • schéma.data.gouv pour le standard ce qui permet d’y faire référence lorsque des données s’y conforment (ce référencement est obligatoire),

    • data.gouv pour les données conformes au standard.

3

ÉVOLUTION DU STANDARD ♾️

Lorsque le groupe de travail sur le déploiement, le commanditaire, la communauté d’utilisateurs ou tout autre usager du standard identifie un besoin d’évolution, une demande d’évolution peut être proposée.

Pour identifier quand une évolution est nécessaire, il est utile d’assurer une veille sur les technologies employées (stockage et traitement des données) et sur les autres standards de données du même écosystème ou du CNIG.

Retours d'expérience

Le standard Accessibilité

Ces propos ont été recueillis auprès des animateurs du GT Accessibilité

Pour se déplacer, les personnes en situation de handicap ont besoin d’information sur la façon dont l’accessibilité se présente dans les transports et en voirie. C’est pourquoi la loi d’orientation des mobilités (LOM) du 24 décembre 2019 impose aux autorités organisatrices de la mobilité et aux collectivités territoriales de collecter des données sur l’accessibilité des transports et de la voirie. L’arrêté commun du 28 mai 2024 impose la collecte selon des modèles normalisés, NeTEx accessibilité France pour les transports et le standard CNIG « accessibilité des cheminements en voirie » et d’utiliser un seul format d’échange, NeTEx accessibilité France.

Le standard est en réalité le fruit d’une réflexion plus longue entamée dès 2018 entre le Cerema et plusieurs métropoles. Son élaboration s’est ensuite poursuivie et accélérée au niveau national à partir de 2020 au sein du groupe de travail du CNIG sur l’accessibilité réunissant une grande variété d’acteurs (collectivités, services de l’État, associations d’usagers et de personnes handicapées, entreprises spécialisées dans la collecte et/ou la diffusion de données sur l’accessibilité, etc.). Le standard a fait l’objet d’une consultation publique suivie d’une consolidation. Il a été validé par la Commission des standards du CNIG en octobre 2021. Son objectif est de collecter et mettre à disposition des données ouvertes interopérables qui viendront alimenter des services numériques de guidage. Ces bases de données servent également au diagnostic du territoire qui permet d’actualiser les Plans de mise en Accessibilité de la Voirie et des Espaces publics (PAVE, obligatoire depuis 2009) et de programmer les travaux d’accessibilité sur le territoire communal ou intercommunal. Lorsque les données n’existent pas encore, l’enjeu principal est de convaincre les acteurs locaux à collecter les données sous le bon format.

Le standard est accompagné d’un guide méthodologique de collecte, dont la rédaction est collaborative, pour expliciter des points techniques particuliers et fournir des consignes favorisant les bonnes pratiques de collecte.

L’État a financé le développement de l’outil Accèslibre Mobilités, suite logicielle open source mise gratuitement à disposition des utilisateurs (Collectivités territoriales, bureaux d’études…). Il s’appuie sur le modèle de données défini dans le standard CNIG et permet aux acteurs de préparer et de réaliser la collecte. Il a été testé par de nombreuses collectivités de façon à améliorer ses fonctionnalités et son ergonomie. Accèslibre Mobilités est utilisé de façon opérationnelle depuis mi-2024 par trois collectivités dans le cadre d’appels d’offre de collecte de données d’accessibilité qui serviront aussi à la programmation de travaux dans le cadre des PAVE.

En parallèle, La plateforme nationale collaborative Accèslibre s’appuie également sur le modèle CNIG et recense l’accessibilité des établissements recevant du public grâce à des contributions individuelles ou collectives. Certaines collectivités impulsent ainsi la démarche de collecte des données d’accessibilité par l’entrée « PAVE » pour ensuite alimenter les services de guidage. Pour ces collectivités pionnières, le GT CNIG Accessibilité est un lieu de ressources, d’échanges entre pairs, qui permet de discuter à la fois objectifs, méthodes, outils… Plusieurs membres du GT CNIG ont par exemple produit un outil de collecte reposant sur le logiciel QGis, libre et gratuit d’utilisation, qui propose, en plus de la collecte, des analyses automatiques de type PAVE à partir des données collectées.

Nous accompagnons ces acteurs locaux investis dans le test des outils avec l’aide des administrations centrales concernées. Les ministères de la transition écologique et des transports animent, depuis courant 2024, 5 groupes de travail régionaux, chacun centré autour d’une collectivité utilisant Accèslibre Mobilités, et rassemblant la région (ou son syndicat de transport), le Centre Régional d’Information Géographique (CRIGE), la DREAL, (via le service SIG, Observatoire régional des Transports, ou service transport), et d’autres collectivités intéressées. Ces groupes de travail œuvrent avec l’appui des acteurs de l’écosystème national tant du côté transport public (Transport.data.gouv, GT7 Information voyageurs, services de mobilité de l’AFNOR/BNTRA) que du côté de la donnée géographique (CGDD, Afigéo, réseau des CRIGEs, membres d’autres GT du CNIG). Ces groupes de travail régionaux sont l’occasion de créer une dynamique locale, d’identifier les difficultés, les stratégies, de travailler des outils…. Ils sont complétés, depuis octobre 2024, par des groupes de travail interrégionaux thématiques, animés par la Fabrique des Mobilités, pour approfondir des problématiques communes et aboutir au printemps 2025 à des livrables rassemblant conseils et recommandations pour tous les nouveaux acteurs se lançant dans le chantier. L’expression des besoins des utilisateurs permet également de régulièrement actualiser le standard.

La Fabrique des Mobilités anime deux groupes de travail « express » de trois réunions chacun visant la production de un à deux livrables par GT pour faciliter l’arrivée des nouveaux entrants : le « GT collecte » sur la collecte, les liens entre les activités et les outils, les ressources documentaires et le « GT réutilisation de la donnée » travaillant sur la conduite de projet, l’intégration des données, les calculateurs d’itinéraires et l’expérience utilisateur.

Par ailleurs, les réunions du GT CNIG Accessibilité, quatre par an, comprennent systématiquement des retours d’utilisateurs.

Aux ressources apportées par le CNIG s’ajoutera prochainement un modèle de projet géomatique open-source sous QGIS, exemplaire du modèle de données CNIG, assorti de jeux de données exemples.

A qui s’adresse votre standard, et, en quelques mots, quels sont les enjeux principaux de la phase de déploiement dans votre cas ?

Instruire et outiller les nouvelles exigences réglementaires (LOM) concernant l’accessibilité du cheminement en voirie espace public pour en assurer l’effectivité sur l’ensemble du territoire, en cohérence avec les exigences analogues dans le domaine des transports en commun.

Quels outils recommandez-vous aux porteurs de futurs projets de standardisation ?

Il est en général primordial d’associer en un binôme une compétence métier avec une compétence géomatique/numérique. Le projet doit également être en mesure de s’associer des ressources pour traduire le modèle de données en un ensemble de schémas JSON pour schema.data.gouv.fr, également pour développer un projet géomatique illustrant la structure de données, des jeux-test et des cas d’utilisation.

Le cas du standard CNIG Accessibilité exige également des ressources particulières pour assurer la conversion entre le modèle de collecte CNIG pour les données du cheminement en voirie) et le format d’échange et de diffusion normalisé NeTEx pour les données relatives au cheminement en voirie et aux transports en commun.

Quel calendrier avez-vous suivi pour l’accompagnement du déploiement ?

Le déploiement se fait au rythme d’amélioration de la maturité des outils et des utilisateurs sur la thématique du cheminement accessible. Rythme accéléré par la réglementation et la politique volontariste de la DMA pour qu’elle soit appliquée dans les meilleurs délais.

Avez-vous des conseils à mettre en place par anticipation, dès la phase d’élaboration du standard pour ensuite faciliter le déploiement ?

  • Créer le binôme métier / géomatique et impliquer la communauté d’utilisateur dès le démarrage du projet.

  • S’inspirer des démarches gagnantes dans d’autres thématiques métier

  • Fédérer toutes les parties prenantes tout au long du projet

  • Dégager des ressources permettant de concrétiser l’utilisation du standard de données (dans certains cas, une preuve de concept peut être très utile. S’appuyer sur les startups d’État.


Ressources utiles

Lien vers les Standards CNIG


Foire aux questions ↓

A qui dois-je m'adresser pour proposer ma demande d'évolution d'un standard ?

La procédure pour faire évoluer un standard est similaire à celle pour la création d'un nouveau standard. Elle est décrite dans la page "", où il est indiqué de contacter le secrétariat général du CNIG par message sur la du site du CNIG ou à . Il peut également être utile de contacter les rédacteurs du standard en question (leurs organismes d'appartenance, a minima, et parfois leurs noms, sont indiqués dans le standard lui-même).


Retour à la page d'accueil ↓

Page précédente et page suivante ↓

pôle de coordination avec les territoires du CNIG
StarEau
GraceTHD
StarEau
Paysages
Émergence d'un besoin ou d'une évolution
page contact
[email protected]
La fabrique des standards
schema-friches/fichier-valide.csv at main · cnigfr/schema-frichesGitHub
Exemple de données de test pour le standard Friches
GitHub - cnigfr/cnig-template: Modèle de dépôt Github pour les standards CNIGGitHub
lien vers le modèle de dépôt
Logo
Logo
Les Standards CNIGConseil national de l’information géolocalisée

Cadrage du groupe de travail

Pour élaborer un standard il faut constituer une équipe représentative des acteurs concernés par le projet de standard.


Actions de la phase

Le pilote sollicite le secrétariat général du CNIG pour l’aider à constituer le groupe de travail de la manière suivante :

  • identifier les parties prenantes au standard, personnes ou organisations,

  • les solliciter pour rejoindre le GT en tant que participant,

  • nommer le ou les animateur(s) du GT parmi les volontaires,

  • s’il s’agit d’une mise à jour d’un standard existant, contacter les participants au groupe de travail ayant élaboré la version précédente du standard,

  • lancer un appel à volontaires pour participer aux travaux.

Le cadrage du groupe de travail comprend différentes phases :

1

RÉDACTION DU MANDAT

Le mandat du groupe de travail est un document précisant l’objectif des travaux et les besoins auxquels un nouveau standard cherche à répondre. Il cadre le groupe de travail en définissant un plan d’action et les modalités des travaux. Il n’a pas de valeur contraignante (notamment pour les participants qui y sont listés), et n’engage pas juridiquement au respect des échéances envisagées ou à la participation au GT. Il doit être rédigé selon le modèle proposé. Il donne un certain nombre d'indications sur les travaux à venir (il peut ainsi être utile de s'approprier certaines notions avant la rédaction, comme celle de "schéma de données").

  • Choix du rédacteur du mandat

Selon les cas, un projet de mandat est rédigé par le porteur initial de la demande et/ou une autre personne volontaire et/ou une personne déléguée au sujet. Le secrétariat apporte son aide pour la rédaction du projet de mandat et le valide sur la forme avant sa présentation en commission des standards.

  • Présentation du projet de mandat

Le projet de mandat est présenté pour validation à la Commission des Standards lors de l’une de ses réunions (dont la fréquence est trimestrielle). La date de la prochaine réunion de la Commission peut être trouvée sur sa page web.

La présentation doit reprendre les éléments du mandat et dure généralement une quinzaine de minutes. Un résumé du projet de mandat doit être fourni en amont de la réunion pour être ensuite publié dans son compte-rendu.

  • Validation du mandat

Le mandat est validé par la Commission des Standards au cours de la réunion après sa présentation.

2

CONSTITUTION DU GROUPE DE TRAVAIL

Le groupe de travail doit être représentatif des acteurs concernés par le projet de standard. Le pilote a la responsabilité d’y veiller. Parmi les participants peuvent se trouver des producteurs ou utilisateurs de données, ou d’autres parties prenantes (fournisseurs de services intermédiaires, fournisseurs de logiciels traitant les données, métiers liés à la connaissance, à la régulation, aux politiques publiques, grands acteurs de l'information géographique et de la donnée, etc.). D’une manière générale, il est important de veiller à ce que les connaissances “métier” et “numérique / géomatique / informatique” se complètent au sein du groupe de travail.

Voici quelques recommandations pour la constitution du GT :

  • Veiller à l’efficacité de la gouvernance (dans le processus de décision notamment) et à la représentativité (associations/fédérations),

  • Obtenir le soutien des acteurs tiers (utilisateurs de données, éditeurs de logiciels, etc.)

  • Organiser des consultations et des points d'information réguliers (en présentiel et en visioconférence), ainsi que des réunions de travail pour les acteurs sous-représentés dans le GT ou défavorisés par des décisions collectives.

Des outils de travail sont créés ainsi qu'une liste de diffusion (comme décrit dans la FAQ plus bas). Une page dédiée au groupe de travail est créée sur le site du CNIG par le secrétariat général. Cette page donnera des informations à jour sur les travaux et hébergera les ressources du GT (mandat, compte-rendus de réunions passées, ordre du jour et agenda des réunions à venir, etc.).

Ressources utiles :

  • le site de la CNIL, ou la page d'information du ministère de l'économie peuvent vous apporter des informations sur le respect des données personnelles dans travaux,

  • le guide “Data Landscape Playbook” de l’Open Data Institute (en anglais), et en particulier la page “Create an ecosystem map”.

3

ANNONCE EN LIGNE DE LA CRÉATION DU GT

La création du GT est l’opportunité de communiquer et d’attirer de potentiels participants. L'annonce se fait via :

  • les canaux du CNIG

L’annonce est obligatoire sur le site du CNIG (contacter le secrétariat du CNIG si ce n’est pas déjà fait via le formulaire dédié). Elle est généralement relayée dans l’infolettre mensuelle du CNIG, et peut être publiée via ses comptes sur les réseaux sociaux (Linkedin et X).

  • les canaux de data.gouv

Plus généralistes, les outils de data.gouv touchent une communauté d’acteurs très impliqués dans les évolutions des données et sont ainsi des canaux privilégiés. La publication d’une annonce est obligatoire dans la catégorie “Schémas et standards de données” de forum.data.gouv. Elle est aussi recommandée sur le site TeamOpenData.

  • les canaux spécialisés

L’annonce de la création du groupe de travail est plus efficace si elle vise directement les personnes les plus concernées. Il peut s’agir d’une expertise liée à la thématique métier du standard (les réseaux, fédérations, ou regroupements d’acteurs du domaine par exemple), à la nature de la donnée (l’information géographique, satellitaire, RADAR, statistique, comptable, etc.), ou encore à l’informatique (réseaux ou associations de professionnels, groupes d’utilisateurs d’un logiciel, etc.). La publication est vivement recommandée sur le forum GeoRezo qui compte parmi ses membres des experts de la donnée géographique mais également de nombreuses personnes ayant contribué à l’élaboration de standards. Quand la thématique concerne une compétence des collectivités territoriales, il est également pertinent de communiquer vers le forum SIG-Topo de l’AITF. Toutefois, ce forum étant réservé aux acteurs des collectivités territoriales, il faut contacter l’un des animateurs sur le site de l'AITF.

La participation à un GT du CNIG est libre et ouverte. Les demandes de participation peuvent être faites sur le site du CNIG ou directement auprès de l’animateur. Il est demandé à un nouveau participant de se présenter, de présenter ses liens d'appartenance ou d’intérêt en lien avec le domaine étudié.

4

RÉUNION DE LANCEMENT

La première réunion du GT est l'occasion de faire connaissance et de cadrer les travaux. Pour vous lancer, voici un exemple d’ordre du jour à adapter :

  1. Présentation de l’animateur et des membres (organismes a minima) du GT

Quelques conseils :

  • demander à chacun de présenter son rôle en lien avec les données visées par le standard, ses attentes pour le GT et ses capacités de contribution (disponibilités et compétences),

  • être attentif à ne pas exclure certains participants : toutes les compétences peuvent être utiles,

  • cadrer dès le départ les prises de paroles (limitation et égale répartition de la durée des interventions, règles de bienséance).

  1. Rappel des objectifs et du périmètre,

Quelques conseils :

  • En parcourant le mandat du GT, expliquer l’émergence du besoin, les problématiques observées, et le cadre réglementaire,

  • Construire l’image de la situation “idéale” à atteindre avant de discuter des livrables pour y aboutir,

  • Utiliser des exemples, notamment pour illustrer ce qu’est un standard CNIG, son contenu et comment il est utilisé,

  • Ouvrir la discussion.

  1. Modalités de travail

Quelques conseils :

  • Présenter les outils du GT, proposer certaines modalités pour les travaux (en plénier/ en sous-groupe, l’utilité des réunions et au contraire ce qui doit être fait hors-ligne, etc.),

  • Discuter de ce sujet en amont, et s’inspirer de l’expérience de personnes ayant déjà participé à l'élaboration de standards.

  1. Définir un calendrier

Quelques conseils :

  • Tenir compte des contraintes (réglementaires, en termes de disponibilité, etc.) et adapter le calendrier à l’ambition des travaux et au potentiel du groupe de travail,

  • Rappeler le processus du CNIG, lister les points d’étape,

  • Prévoir des points d’étape,

  • Garder en tête le calendrier du CNIG (et notamment des réunions de la Commission des standards et des réunions du Conseil Plénier). Communiquer au secrétariat général les dates des réunions afin qu'elles soient communiquées sur le site du CNIG.

Comme pour toutes les réunions du groupe de travail, un compte-rendu doit être rédigé et publié à l'issue de la réunion de lancement (plus d'informations sur la page "Réalisation du standard").

Le rôle du secrétariat général du CNIG

Lors du cadrage du GT, le secrétariat général vous accompagne pour :

  • la constitution du groupe de travail (si besoin),

  • la rédaction du mandat (si besoin),

  • l'annonce en ligne de la création du GT,

  • la création de la page du GT,

  • la tenue de la page web du GT (annonce des réunions, publication des compte-rendus, etc.),

  • le référencement du projet de standard sur le site du CNIG.


Ressources utiles

Modèle de mandat spécifique au groupe de travail

34KB
GT CNIG - Modèle de mandat.docx
Modèle de mandat de GT

Le règlement intérieur du CNIG

Le Règlement intérieur du CNIG est à respecter par l'ensemble de ses membres et par les participants aux GT. En voici un extrait :

La participation aux pôles, commissions, groupe de travail et toute autre réunion de travail du CNIG implique le respect des règles suivantes :

  • Principes légaux : Respecter toutes les lois, règles et réglementations applicables en France notamment en termes de probité, de discrimination, d’injure, de diffamation

  • Déontologie : les participants doivent informer des liens d’appartenance ou d’intérêt qu’ils ont avec les entreprises, entités ou organismes en lien avec le domaine traité.

  • Professionnalisme : les participants doivent maîtriser les connaissances fondamentales de leur domaine d’intervention ou d’expertise

  • Transparence des débats : les participants acceptent que les échanges tenus lors des réunions des commissions et groupes de travail fassent l’objet de compte-rendu publics diffusés sur le site du CNIG. Des enregistrements audio ou vidéo des réunions peuvent éventuellement être réalisés, dans ce cas un accord explicite des participants sera demandé.

  • Respect des personnes : La politesse, la ponctualité et la courtoisie sont de rigueur dans les réunions et dans tous les échanges entre membres


Foire aux questions ↓

Comment animer une réunion de travail ?

Animer une réunion de travail est une compétence qui s’acquiert, de nombreuses ressources existent sur internet pour se former.

Parmi les ressources développées par les services publics, une référence utile est la boîte à outils de la Fabrique à projet (DITP).

Comment lancer un appel à participation ?

En s’appuyant sur les différents canaux indiqués plus haut, l’appel à participation doit être lancé avec une visée large et rappeler que les GT sont ouverts à tous les participants. Les informations suivantes doivent figurer dans l’appel :

  • qui sont les acteurs à l’origine de l’appel,

  • quel est le périmètre de la thématique du GT et son objectif,

  • à qui s’adresse l’appel,

  • quel intérêt les participants peuvent trouver aux travaux (prise en compte du standard dans leurs systèmes d’informations existants, transition vers l’interopérabilité, respect de la réglementation, etc.),

  • les liens vers le mandat (ou le projet) et la page du GT sur le site du CNIG,

  • les modalités de travail prévues (fréquence des réunions, présence souhaitée, durée du mandat, lien vers les outils de travail publics envisagés).

Voici un modèle d'appel à participation qui peut être réutilisé :

Quelques acteurs impliqués dans la thématique …. ont sollicité le CNIG pour élaborer un standard de (géo)données relatif aux données des … .

Pour prendre en compte l’existant dans vos systèmes d’information, les besoins d’interopérabilité entre les système (et éventuellement tenir compte de la législation), nous vous sollicitons pour travailler collectivement dans un groupe de travail animé par … .

Le mandat du GT est disponible ici [insérer le lien].

Pour atteindre ces objectifs, le groupe de travail organisera ... réunions pendant la durée du mandat, avec accès via un système de visioconférence. Il est possible de s’engager ponctuellement en fonction de l’ordre du jour des réunions.

Pour participer aux échanges, les acteurs disposeront d’une plateforme collaborative comprenant un espace de dépôt accessible en lecture/écriture aux membres du groupe.

Les travaux seront publiés régulièrement sur la page dédiée du GT [insérer le lien vers la page du GT].

Nous vous invitons à rejoindre le GT si vous travaillez dans le domaine de … et êtes motivés par l'émergence d'un standard dans le cadre d'une démarche institutionnelle et collaborative.

Comment assurer le lien avec data.gouv.fr ?

Pour annoncer le lancement des travaux auprès des utilisateurs de schema.data.gouv, plusieurs actions sont recommandées :

  • annoncer le lancement des travaux sur forum.data.gouv,

  • pré-référencer le standard, même avant sa rédaction, sur le site en suivant la démarche décrite sur cette page. Cela se fait généralement par la création d'une issue sur Github, ou en contactant l'équipe par mail à [email protected] (voir le guide dédié).

Comment créer une liste de diffusion ?

Une liste de diffusion par mail permet de transmettre les invitations, ordres du jour et compte-rendus de réunion au groupe de travail CNIG que vous animez.

Il existe (au moins) deux méthodes pour créer une liste de diffusion :

La méthode basique

Constituez votre liste de diffusion dans un simple fichier texte en séparant les adresses mails par une virgule, ou dans un tableur. Copiez simplement ce texte dans le champ adapté (“pour :”, “copie à :”, “copie cachée à :”).

Avantages de cette méthode :

  • la souplesse d’utilisation : il est facile de faire évoluer cette liste, et notamment de gérer le groupe de travail et ses sous-groupes,

  • vous pouvez réserver une partie de la liste pour les invitations, pour la relecture des participants à la dernière réunion, et la liste entière pour les annonces importantes et l’envoi des compte-rendus,

  • le choix entre les trois options “pour :” ou “copie à :” ou “copie cachée à :” (voir un, mix des trois)

Chaque destinataire peut résilier son abonnement en vous le demandant explicitement.

La méthode automatisée

Utilisez un outil de gestion des listes de diffusion (comme Framagroupes, anciennement Framalistes), pour créer votre groupe de discussion par email.

Framagroupes permet de créer des listes de diffusion par mail : toute personne s'abonnant à votre liste pourra recevoir les emails qui y sont envoyés, et y participer à son tour. À vous de choisir si cette liste est publique, semi-privée ou privée. Cette méthode offre d’autres fonctionnalités décrites dans la documentation (gestion des droits, création d’une liste blanche pour l’inscription, modération des messages, formatage, etc.).

Avantages de cette méthode :

  • l’automatisation, puisque Framagroupes gère la liste pour vous (ce qui peut également faciliter la coordination dans le cas où le GT possède plusieurs animateurs),

  • Chaque abonné peut résilier son abonnement comme il le souhaite.

Le service repose sur le logiciel libre Sympa. Un tutoriel vidéo existe pour vous aider à prendre en main l’outil.


Retour à la page d'accueil ↓

Page précédente et page suivante ↓


La fabrique des standards

La fabrique des standards

La fabrique des standards désigne le processus de création d'un standard CNIG avec ses différentes phases et la documentation associée à destination des différents acteurs de l'élaboration d'un standard (pilotes, animateurs ou participants aux GT). Elle est documentée dans ce guide.

Le CNIG

Le Conseil National de l'Information Géolocalisée organise la coordination et accompagne l'évolution de l'information géolocalisée en France. Instance consultative placée auprès du ministre en charge du développement durable, le CNIG rassemble en un lieu unique la très grande variété d’acteurs qui composent l’écosystème de la géo-donnée en France : ministères, établissements publics, collectivités territoriales, entreprises privées, associations professionnelles, organisations syndicales, association de citoyens, qui peuvent se rencontrer, décider et coproduire ensemble.

Votre point de contact est le secrétariat général du CNIG. Plus d'informations sur son site web.

Les standards CNIG

Les standards CNIG sont des standards de données : il s'agit d'une manière générale d'une exigence destinée à établir une compréhension commune de la sémantique des données entre producteurs et utilisateurs, afin d'en assurer la qualité et l’interopérabilité.

Ils sont créés au sein de groupes de travail mandatés du CNIG. Ce sont des préconisations nationales compatibles avec le contexte européen, mais aussi des guides qui proposent des modélisations sur lesquelles on peut s’appuyer pour anticiper les évolutions de l’information géographique. Ils prennent un caractère obligatoire quand la règlementation y fait référence. Dès lors, ils sont mis à jour pour en suivre les évolutions. Les standards CNIG sont des standards ouverts.

Le processus de création ou d'évolution d'un standard CNIG est représenté ci-dessous, de l'émergence au déploiement. Il décrit toutes les phases à passer pour faire émerger ou faire évoluer un standard. Vous retrouverez chaque phase détaillée à la suite de ce schéma récapitulatif.

Schéma du processus de création d'un standard

Les phases détaillées

Le processus de création d'un standard comporte 7 grandes phases, les voici détaillées :

Exploration de l'existant et saisie du CNIG

Initialisation des travaux

Cadrage du groupe de travail

Réalisation du standard

Validation du standard

Déploiement du standard

Cover
Cover
Cover
Cover
Cover

Exploration de l'existant et saisie du CNIG

Les personnes intéressées par la prise en charge d'une nouvelle thématique prennent connaissance de l'existant et saisissent le CNIG selon le résultat de l’exploration.


Actions de la phase

1

PRENDRE CONNAISSANCE DE L'EXISTANT

Avant de saisir le CNIG, il revient aux personnes à l’initiative du projet d’explorer ce qui existe afin de vérifier qu’un standard permet bien de répondre au besoin identifié. Pour éviter de reproduire l’existant, il est important de s’assurer qu’aucun standard (CNIG ou non, français ou international), ou projet de standard, ne répond déjà au besoin. Cette exploration permet également d’identifier certaines briques pouvant servir de base pour les travaux (comme une ontologie, un schéma, une norme, etc.). Cette exploration peut se faire :

  • Via la liste des standards sur le site du CNIG,

  • Via le site schema.data.gouv,

  • Via un autre organisme Voir la page dédiée sur le site du CNIG [🚧 en construction 🚧]

2

SAISINE DU CNIG

Selon les résultats de l'exploration, le porteur du sujet saisit le CNIG.

Le traitement de la demande par le Secrétariat Général du CNIG est une étape préliminaire lors de laquelle ce n’est pas tant la recevabilité de la demande qui est discutée que la meilleure méthode pour y répondre. Le CNIG est organisé en commissions appartenant à trois pôles : innovation et prospective, expertise et coordination avec les territoires (plus d’information sur la page détaillant le fonctionnement du CNIG). Ainsi, la cible de l’accompagnement peut être plus large que le standard en lui-même, et vise aussi à assurer la cohérence avec les standards existants, l’inclusion des collectivités territoriales, ou encore le respect des règles nationales et européennes.

Après une phase d’évaluation de la maturité du sujet avec le pilote, le secrétariat du CNIG programmera le passage en commission et les suites à donner :

  • Saisie de la commission Besoins et usages pour la création d’un GT exploratoire : cas des sujets qui nécessitent un travail préalable de recueil des besoins, pratiques, etc.,

  • saisie de la commission Besoins et usages pour la création d’un GT standard : le sujet est prêt à être démarré,

  • Saisie de la commission des standards pour le lancement des travaux : le projet de GT est prêt, animateurs et parties prenantes identifiées, ou bien il s’agit de réactiver un GT existant pour une évolution ou mise à jour du standard.

Le porteur de projet, appelé pilote dans la suite, présente son projet à la commission mobilisée. Le temps dédié est l’opportunité de mobiliser l’expertise des membres de la commission et d’insister sur les interrogations que le porteur pourrait avoir. Il est conseillé de clarifier tout ce qui relève de la procédure avant cette étape pour se focaliser sur les enjeux liés à la thématique.

Le rôle du secrétariat général du CNIG

Lors de l'exploration de l'existant, le secrétariat général vous accompagne pour :

  • l'instruction de la demande,

  • la coordination avec les commissions concernées.


Foire aux questions ↓

Comment saisir le CNIG ?

Un message peut être envoyé sur la page contact du site du CNIG ou à [email protected]

A la suite du message le secrétariat du CNIG prendra contact, organisera éventuellement une réunion avec le porteur du projet, et si l’exploration semble suffisante programmera le passage en commission.

Qui sont les autres producteurs de standards et où les trouver ?

[🚧 en construction 🚧] Une cartographie des organismes producteurs de standards ou de spécifications est en cours d'élaboration et sera publiée sur le site du CNIG.


Retour à la page d'accueil ↓

Page précédente et page suivante ↓

La fabrique des standards
Cover
Cover
Logo