Validation du standard
Dernière mise à jour
Cet article vous a-t-il été utile ?
Fabrique des standards
Dernière mise à jour
Cet article vous a-t-il été utile ?
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 permettra 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 ),
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.
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.
La démarche à suivre est détaillée dans .
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 (Resource 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.
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
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 :
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 ,
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
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.
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.
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.
[ en construction ]
