GitHub - cnigfr/cnig-template: Modèle de dépôt Github pour les standards CNIGGitHubLoading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
La rédaction d’un standard nécessite la confrontation de profils diversifiés aux points de vue souvent divergents. La prise de décision dans le groupe peut sembler difficile lorsque les désaccords sont très prononcés. La méthodologie suivante aidera l’animateur à organiser une session d’atteinte de consensus sur un sujet spécifique. Elle est issue de la littérature sur le sujet, adaptée au cas de la production d’un standard.
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.).
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.
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.
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 oeuvre ;
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.
Pour élaborer un standard il faut constituer une équipe représentative des acteurs concernés par le projet de standard.
identifier les parties prenantes au standard, personnes ou organisations,
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.
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
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.
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, etc.). D’une manière générale, il est important de veiller à ce que les connaissances “métier” et “informatique” se complètent au sein du GT.
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.),
Considérer l’accompagnement par un cabinet expert,
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.
Ressources utiles :
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
les canaux de data.gouv
les canaux spécialisés
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é.
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 :
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).
Rappel des objectifs et du périmètre,
Quelques conseils :
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.
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à réalisé des standards.
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,
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 de les communiquer sur le site 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.),
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
Tout d'abord, pour accéder au modèle de dépôt, suivez le lien suivant :
"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).
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.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 ;
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.
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
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 :
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.
Pour vous aider dans la construction de votre dépôt, nous vous recommandons de vous référer à :
Cette phase vous permet de vous projeter dans les travaux avant de lancer la construction du standard.
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 et le sérieux des travaux tout au long de la procédure garantissent généralement l’adoption du standard. Il est alors possible de poursuivre directement avec la validation par le conseil plénier sans attendre.
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 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…).
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.
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.
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 ?
Un standard de données est avant tout un standard. Mais qu’est ce qu’un standard ? Repartons des bases.
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.
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.
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.
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 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.
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.
Le processus de création d'un standard comporte 7 grandes phases, les voici détaillées :
Le groupe de travail a pour mission d'organiser un travail collaboratif pour élaborer un standard qui fasse consensus.
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.
Si besoin, des points d’étapes peuvent être faits en commission des standards.
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.
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).
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.).
Les personnes intéressées prennent connaissance de l'existant et saisissent le CNIG selon le résultat de l’exploration.
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 :
Selon les résultats de l'exploration, le porteur du sujet saisit le CNIG.
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.
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.
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 pour un animateur qui n’aurait jamais utilisé Github.
Pour les deux cas précédents, voici quelques conseils pour la prise en main.
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.
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).
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.
Github ne supporte pas les dossier 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.
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).
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 autre membre 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 familier 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.
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”, sous la forme de commentaires libres, et
les “pull requests”, 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.
Après la publication initiale, une maintenance peut être assurée pour prendre en compte les retours lors de l’appel à commentaire, 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 peut également être utile de communiquer sur la publication d’une nouvelle version pour s’assurer que celle-ci est prise en compte par les utilisateurs.
Le sollicite le secrétariat général du CNIG pour l’aider à constituer le groupe de travail de la manière suivante :
les solliciter pour rejoindre le GT en tant que ,
nommer le ou les du GT parmi les volontaires,
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 décidées ou à la participation au GT. Il doit être rédigé selon . 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 ).
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 dans la mesure du possible). La date de la prochaine réunion de la Commission peut être trouvée .
Des outils de travail sont créés. Une liste de diffusion est créée (comme décrit ). 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.).
, ou peuvent vous apporter des informations sur le respect des données personnelles dans travaux,
le guide “” de l’Open Data Institute (en anglais), et en particulier la page “”.
L’annonce est obligatoire sur le site du CNIG (contacter le secrétariat du CNIG si ce n’est pas déjà fait ). Elle est généralement relayée dans du CNIG, et peut être publiée via ses comptes sur les réseaux sociaux (Linkedin et X).
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 . Elle est aussi recommandée sur le site .
L’annonce de la création du GT 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 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 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 .
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 ).
le référencement du projet de standard sur .
Le est à respecter par l'ensemble de ses membres et par les participants aux GT. En voici un extrait :
Parmi les ressources développées par les services publics, une référence utile est la (DITP).
En s’appuyant sur les différents canaux indiqués , l’appel à participation doit être lancé avec une visée large (les GT sont ouverts à tous les participants). Les informations suivantes doivent figurer dans l’appel :
annoncer le lancement des travaux sur ,
pré-référencer le standard, même avant sa rédaction, sur le site en suivant la démarche décrite sur . Cela se fait généralement par , ou en contactant l'équipe par mail à schema@data.gouv.fr (voir ).
Utilisez un outil de gestion des listes de diffusion (comme , anciennement Framalistes), pour créer votre groupe de discussion par email.
Le service repose sur le logiciel libre Sympa. Un existe pour vous aider à prendre en main l’outil.
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 . 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.
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 de github pour plus d'infos à ce sujet). Pour un standard CNIG, voici quelques recommandations spécifiques :
schema est le dossier où l'on peut trouver le schéma au format , 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 ;
LICENSE.md est le fichier de licence du dépôt. Nous recommandons d'utiliser la , cette licence est recommandée par l'administration française pour le partage de données et de documents ;
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, peut être utile).
Modifier le fichier d'exemple CSV avec des données conformes. L'outil permet de vérifier que vos fichiers sont conformes au schéma json en ligne de commande frictionless validate --schema schema.json exemple-valide.csv ;
Modifier le modèle fichier README.md. Consulter plusieurs dépôt de standards CNIG (comme ) et schémas sur pour découvrir quelles informations sont pertinentes à indiquer.
Décrire votre schéma dans le fichier schema.json en respectant la spécification Table Schema. Le fichier d'exemple comprend des valeurs d'exemples pour toutes les métadonnées possibles. Notez que les champs d'exemple ne comprennent qu'une petite partie des types, formats et contraintes disponibles, référez-vous à pour toutes les valeurs possibles. Si certaines métadonnées ne sont pas nécessaires pour votre projet, vous pouvez les supprimer. Pour vérifier que votre schéma est conforme, vous pouvez utiliser l'outil en ligne de commande : tableschema validate schema.json.
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 afin de vérifier :
Comme résumé en deux phrases dans , 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”.
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 , 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. 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.
Le standard Schéma de Cohérence Territoriale (SCOT) a été réalisé et mis à jour par (DDU) pour tenir compte des changements réglementaires sur le sujet. Tout d’abord, 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’ relative à la modernisation des SCOT est venue ensuite modifier le contenu des SCOT, exigeant une mise à jour du standard.
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 montantau 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.
Le s’est constitué suite au constat que les photos des territoires étaient difficilement accessibles, 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.
C’est le cas par exemple du , qui s’inscrit dans . 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 numérique.
Le 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 v3 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.
Guide data.gouv sur préalable à la création d'un schéma de données.
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 , réseaux sociaux, etc.).
Votre point de contact est . Plus d'informations sur .
Les standards CNIG sont des : 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 .
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 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.
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.
Pour aller plus loin : voir (Semantic Interoperability Community de l'Union Européenne).
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 ,
Pour être référencé, le standard doit être identifié sur avec le label "en construction".
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 .
Sur la page Github de schema.data.gouv, , et sélectionner “Référencer un schéma”,
Note : pour vous familiariser avec la syntaxe markdown, peut être utile.
Via la liste des standards sur le site du ,
Via le site ,
Via un autre organisme Voir la page dédiée sur [ en construction ]
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 (). 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.
Le porteur de projet, appelé 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.
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]().
Il est nécessaire de créer un compte pour créer un dépôt Github ou y contribuer (voir ).
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 (ou pull request en anglais).
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 ) ou en repartant d’un dépôt existant de manière incrémentale (une “fork”, comme décrit ).
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.
... Le travail de rédaction
... Les sujets techniques
La modélisation des données est une compétence du domaine de l'informatique pour laquelle plusieurs concepts peuvent être utiles, tels que :
Directive INSPIRE
Voici une liste de ressources qui pourront alimenter votre réflexion, ou vous permettre de vérifier l'exhaustivité de votre standard :
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.
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.
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.
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.).
A l’issue de l’appel à commentaires, le projet de standard est soumis à validation. Il sera ensuite publié.
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 :
L’appel à commentaire est la dernière étape avant la validation du standard par la commission des standards, il ne peut ainsi avoir lieu qu’à la fin de la phase de rédaction du standard et des autres livrables éventuels (schéma, Github, annexes, documentation, etc.). L’appel à commentaire 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.
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 à commentaire et la prise en compte des retours ;
l’utilisation (conforme) des modèles proposés ;
plusieurs conditions additionnelles :
publication des documents de travail du GT (mandat, CR des réunions, etc.),
publication sur schema.data.gouv,
publication du standard sur le site du CNIG sous une licence ouverte.
Le projet de standard est soumis à validation à la Commission des Standards puis au Conseil plénier du CNIG.
Présentation à la commission des standards
Le contexte
Définir les termes si cela est nécessaires à la compréhension du sujet,
Présenter le sujet, le contexte réglementaire,
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, le jeu 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
Des questions ou demandes peuvent être formulées à l’oral par les membres du conseil. 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.
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.
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.
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 à commentaire,
Annoncer l'appel à commentaire en commission des standards et annoncer l’appel à commentaires 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 à commentaire, 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).
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 les dates de l’appel à commentaire, en prévoyant suffisamment de temps entre la fin de l’appel à commentaire 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 à commentaire (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, avec le risque de perdre des informations par manque de rigueur. Les animateurs sont libres d’utiliser tout autre outil qui leur semblerait plus approprié.
Se coordonner avec le secrétariat général, les membres du GT 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 SG du CNIG sur la page du GT,
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.
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.
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ées 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 ?
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.
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.
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.
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.
[débutant] les de l'IMT Atlantique,
[averti] le de l'IRIT,
[débutant] led'Inria sur FUN MOOC,
[débutant] le de l'UTC,
[avancé] les à l'ENSG,
le du CNIG,
Un 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 du Ministère de la Transition Écologique,
le de la Direction Interministérielle du Numérique (DINUM),
Ce glossaire précise les termes spécifiques à la Fabrique des standards. Il complète les , ainsi que celles liées à l'univers de l'open data du de la DINUM.
le standard risques - profil applicatif PPR testé par la DDT de l’Isère (voir ce ),
le standard paysage testé par plusieurs collectivités (voir le sur ). Plusieurs documents de travail du GT peuvent être utiles à titre d'exemple :
, leur donnant notamment des consignes,
visant à recueillir les résultats.
La démarche à suivre est détaillée dans .
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 trouvée, la commission doit être contactée pour inscrire la présentation du standard dans l’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 :
Indiquer si la thématique possède un lien avec ,
Le standard doit être validé par 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 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.
Une fois validé par la Commission des Standards, le standard est publié comme standard validé sur le .
Il est également référencé sur 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.
Déterminer la date de la Commission des standards visée en vous référant .
Communiquer sur le lancement : via les réseaux (Géorezo, etc.), l’organisation d’un webinaire (sur l’exemple de ), etc. Le SG du CNIG mettra en ligne l’appel sur le site du CNIG et dans l’ (la newsletter du CNIG).
Ce projet de standard a été élaboré à la fois sous l'égide du CNIG en suivant son , tout en respectant le .
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.
la publication de documents explicatifs accompagnant le standards comme une note explicative (exemple de ), une recommandation pour la mise en oeuvre (exemple des standards et Plan de sauvegarde et mise en valeur ou PSMV) ou un wiki (exemples des standards et ),
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).
