Les données publiées sur le portail data.gouv.fr peuvent facilement être présentées sur une page web, en particulier sur une des pages du site institutionnel d’une collectivité.
Source : OpenDataFrance - Licence : CC-BY-SA
Version : v2.0, date : juillet 2022
La plateforme « data.gouv.fr » offre plusieurs moyens plus ou moins avancés d’intégrer les données disponibles en open data sur vos propres sites :
de manière unitaire si vous souhaitez n’afficher qu’un ou quelques jeu(x) de données particulier(s) ;
de manière plus générale si vous souhaitez afficher tous les jeux de données relatifs à un territoire ou à une organisation ;
pour une gestion fine de l’habillage et des données affichées, nous vous recommandons l’API ;
pour avoir votre propre portail fondé sur le moteur de la plateforme.
Ces différents cas d’intégration correspondent généralement à différents profils :
un journaliste traitant d’une problématique donnée va être intéressé par l’inclusion de jeux de données directement au sein de son article ;
une mairie va être intéressée par l’intégration des jeux de données relatifs à son territoire sur son site internet ;
une association pourrait être intéressée par la création d’une page personnalisée compilée à partir de données issues de sources multiples ;
un pays se lançant dans l’open data va chercher à créer son propre portail.
Celles-ci ont été décrites initialement dans la documentation de data.gouv : https://doc.data.gouv.fr/jeux-de-donnees/integrer-des-donnees/
Chaque jeu de données est intégrable sur n’importe quelle page en ajoutant quelques lignes de HTML, deux versions existent :
ET En remplaçant l’IDENTIFIANT DU JEU DE DONNÉES par l’identifiant disponible sur sa page dédiée, dans l'onglet Métadonnées sous la rubrique ID :
La première version de code proposée est accessible directement depuis l'onglet Action du jeu de données souhaité. Il suffit de copier le code proposé dans la rubrique "INTÉGRER SUR VOTRE SITE"
Selon le code utilisé, vous verrez apparaître l'une ou l'autre des versions d'intégration sur votre site. Sur cet exemple le premier cartouche correspond à la première version du code proposé et le second à la seconde version. Ces cartouches contiennent les informations relatives au jeu de données choisis de la manière suivante :
Voici un autre exemple d’intégration sur le blog d’Etalab, ici avec les données de consommation d’électricité des ministères. Il est possible d’intégrer plusieurs jeux de données à la fois en dupliquant la ligne correspondant à l’élément <div> avec un nouvel identifiant. Vous pouvez personnaliser l’apparence du rendu du cartouche grâce à la classe CSS dataset-card.
Le mécanisme pour afficher tous les jeux de données relatifs à une organisation ou un territoire est le même que celui pour l’intégration d’un seul jeu de données décrit précédemment. Cet usage est recommandé si vous êtes responsable de cette organisation ou de ce territoire et souhaitez faire la promotion des jeux de données associés. Par exemple dans la cadre de la loi Notre, il est demandé aux communes de plus de 3500 habitants de rendre accessible en open data certaines données. L’usage de la plateforme « data.gouv.fr » pour déposer ces données puis les intégrer sur son propre site est rendue possible par cette solution.
En remplaçant l’IDENTIFIANT DE L’ORGANISATION par l’identifiant disponible sur sa page dédiée (l'ID se trouve en bas de page de description de l'organisation, dans les informations techniques, rubrique ID). Vous devriez alors voir apparaître sur votre site un cartouche contenant les informations relatives aux jeux de données de cette organisation. Optionnellement, il est possible d’afficher une barre de recherche pour laisser la possibilité au visiteur de filtrer la liste des jeux de données affichés. Cela est activé en passant l’option {withSearch: true} à la méthode loadOrganization() ci-dessus.
L'exemple ci-dessous montre l'intégration des jeux de données de la ville de Grenoble sur une page web avec cette méthode et l'option de filtrage activée :
METACLIC : Une bibliothèque JavaScript a été développée en open source par la société DATAKODE pour faciliter la personnalisation de l’affichage des jeux de données sur un site tiers. Un système de gabarit permet d’intégrer les données que vous souhaitez issues de l’API à vos couleurs et selon la disposition qui vous convient. Il s’agit d’un moyen de créer votre propre page open data à coûts réduits au sein de votre site.
Voici un exemple de restitution :
Données publiées sur data.gouv.fr :
Données vues sur le site web de Castelnaudary.fr via métaclic
Les outils développés sont disponibles en open-source. Ils sont le fruit d’un effort international pour créer des synergies autour de la donnée ouverte et mutualiser nos efforts de développement. La gouvernance est inclusive et la licence est permissive. Nous participons à l’animation autour du développement de la plate-forme car nous souhaitons produire un bien commun réutilisable par tous.
L’intégration d’un portail open data complet demande des compétences en administration système, en développement Python et JavaScript ainsi qu’un temps non négligeable de prise en main de la plateforme. C’est un choix qui doit être mûrement réfléchi et nous vous recommandons de passer directement par « data.gouv.fr » si vous avez des données issues de territoires francophones.Si vous souhaitez néanmoins vous lancer dans cette aventure, vous pouvez commencer par analyser le code source ainsi que la documentation dédiée. Vous pouvez également venir en discuter avec la communauté (en anglais).
Exemple de publication des données de Castelnaudary : https://www.ville-castelnaudary.fr/fr/mairie/open-data
Le code est alors :
> via l’API METACLIC
> Via l’API data.gouv
Ce document détaille les étapes de préparation d’un jeu de données
Source : OpenDataFrance - Licence : CC-BY-SA
Version : v2.0, date : juillet 2022
Cela exige de procéder par de multiples approches car il est rare d'avoir un inventaire exhaustif des données. Les services les plus compétents pour aider dans cette démarche sont les services d'archive, de documentation, d'informatique, d'information géographique, du numérique, d'observatoire, de pilotage, de dgs, de communication. On sera vigilant à récupérer des données brutes et non des données travaillées, comme par exemple sous forme de statistiques.
OpenDataFrance propose le Socle Commun des Données Locales, il s’agit des données que les collectivités doivent publier en priorité, dans un format normalisé.
Un premier périmètre de données “prioritaires” a été établi autour des données suivantes :
Catalogue : dictionnaire des données publiées
Délibérations : données déclaratives (date, objet, type), sans données personnelles
Marchés Publics : date, nature, montant et identification des tiers bénéficiaires
Subventions : date, nature, montant et identification des tiers bénéficiaires
Équipements Collectifs Publics : inventaire géolocalisé des équipements collectifs publics implantés sur un territoire
État Civil : statistiques sur les prénoms des nouveaux-nés
Base Adresse Locale : correspondance entre l'adresse et la géolocalisation précise
Infrastructures de Recharge de Véhicules Électriques : localisation géographique et caractéristiques techniques des stations et des points de recharge pour véhicules électriques
Normalisation des éléments de base : codification normalisée des champs habituellement utilisés
Pour aller plus loin se reporter au Socle Commun des Données Locales.
Si une standardisation existe vous devrez essayer de l’appliquer au plus près. Cette opération peut être plus ou moins facile.
Si il n’y a pas de standardisation, vous devrez au moins appliquer les préconisations faites sur les intitulés de colonnes usuels tel l’adresse, la date, le nom de l’acteur… Le document “Normalisation des éléments de base” du Socle Commun des Données Locales (SCDL) peut vous y aider.
Votre modèle d’extraction est l’occasion de faire un premier niveau de nettoyage, autrement dit, l’occasion de sortir les données qui n’apportent rien au fichier tels que des identifiants techniques internes, ou des données qui font l’objet d’une législation qui empêchent leur publication.
Ensuite, vous devrez savoir sur quel(s) format(s) doivent être présentés vos données. Les attendus de la loi pour une République numérique sont “dans un format ouvert, aisément réutilisable et exploitable par un système de traitement automatisé”. Le format le plus répandu est le format .csv. La fiche Produire un fichier CSV de qualité est rédigée pour vous aider à ce travail.
Certains acteurs choisissent de publier leurs données dans plusieurs formats, comme le fait par exemple Bordeaux métropole qui pour ses données géographiques a choisi les formats suivants : ESRI Shapefile RGF93/CC45, ESRI Shapefile RGF93/Lambert93, Google KMZ, WebService OGC WMS, WebService OGC WFS, Fichier CSV, AutoCAD DWG.
En ce qui concerne la licence, elle aura été probablement choisie en amont et annoncée dans la délibération donnant le cadre de l’ouverture des données. Mais il est toutefois utile de se poser la question avant la publication de chaque jeu de données.
Il arrive que les données qui sont dans des fichiers, pour en faciliter les lectures et traitements sont "esthétisées": les cases des tableurs sont esthétisées, des cellules sont fusionnées, des textes sont en italique ou graissés... Certains fichiers de type tableur, peuvent être organisés en onglets ou bénéficier de "macro" plus ou moins complexes.
L'ensemble de ces aménagements spécifiques éloignent le fichier de son potentiel de réutilisation. Un fichier qui aurait au moins une de ces “fantaisies” ne répond pas aux standards de l'ouverture.
Chaque base de données ou application métier a ses opérations préalables à l'exportation. Parfois, il y a aura un bouton ou un menu “exporter les données”, dans d'autres cas il sera possible de présélectionner les données avant de les exporter, dans d'autres cas encore, rien n'est prévu nativement pour exporter les données. Dans cette hypothèse, il faudra mettre en place une opération technique qui réalise l'export, opération souvent désignée comme "moulinette" ou "patch". La "moulinette" peut être une simple ligne de commande ou bien réalisée par un programme ou un outil d'extraction tels que les ETL (Extract, Transform, Load) : Talend, Knime, Pentaho Data Integration...
Ces derniers outils permettent d'extraire des données de n'importe quel format (fichiers, bases de données, pages html...) pour ensuite les traiter si besoin (changer le nom des entêtes, corriger les formats de dates, uniformiser les différences de nommage de certains champs, croiser des données entre-elles...) pour ensuite les réinjecter dans un entrepôt de données spécifique pour l'opendata, dans des fichiers csv ou tout autre format.
Certains standards, comme GTFS, demandent beaucoup de rigueur pour répondre à leurs exigences. L'export des données va exposer les données sous une nouvelle réalité. En effet, tant que les données sont dans leur environnement logiciel, elles ont une cohérence utile aux exploitations quotidiennes, mais sorties de leur contexte usuel, elles peuvent faire apparaître des "défauts" de qualité. Dans cette phase, il est vraiment important de faire un travail avec les agents qui s'occupent de l'alimentation des données à la source pour que les erreurs repérées puissent être corrigées au plus prés de l'alimentation source.
Si possible, on organisera le SI de sorte à ne pas activer la “moulinette” manuellement mais à appliquer des procédés automatisés. La solution usuellement retenue est la mise en place d’API, simple à mettre en place et appréciée des réutilisateurs.
Lorsque les données viennent d'être exportées, il faut avoir un regard général pour cette nouvelle forme de présentation. Dans certains cas, il y a aura des défaut des formes; par exemples, les caractères accentués s'afficheront mal. Dans d'autres cas, il y aura des habitudes de services, les agents, dans leur travail quotidien, utilisant des abréviations ou diverses expressions, sorte d'argot professionnel. Une personne extérieure au service, n'aura pas facilement les significations des différents termes utilisés, à moins qu'ils soient documentés. Dans d'autres cas, la nouvelle mise en forme des données fait apparaître des notions dérangeantes : un lieu est privilégié, un élu est sur ou sous exposé, les effets des politiques du moment ne se voient pas dans les données qui sont représentatives des mois antérieurs.... La diffusion des données pourraient venir perturber les missions de services publics. Par exemple, diffuser les sections des tuyaux des réseaux d'assainissement pourrait favoriser des explorations dans les tuyaux dans lesquels il est possible de tenir debout. Enfin, l'ouverture des données pourrait être contrainte pour une disposition réglementaire spécifique.
Enfin, des doublons ou des incohérences pourraient apparaître; ainsi, souvent, c’est une nouvelle occasion de faire des opérations de nettoyage. Elles seront facilités par des outils tels que les ETL ou d'autres comme Openrefine
Il peut y avoir certaines transformations du texte, des intitulés des colonnes, des abréviations pour rendre les données lisibles par toutes les personnes extérieures au service producteur de données. Une documentation viendra compléter cette mise en visibilité des données. Pour rédiger la documentation, il est possible de s’appuyer sur la trame type rédigée par OpenDataFrance : Documenter les données avant publication C’est l’occasion, de mettre en place les métadonnées. Dans bien des cas, ces dernières s’appuient sur un dictionnaire des métadonnées. C’est à ce moment qu’on décide de la fréquence de mises à jour des données.
Le fichier de données brutes pour répondre aux attendus d’intelligibilités des humains et des machines a subit de nombreuses transformations. Certaines transformations sont des transformations de mises à niveau pour une ouverture facilitée. Il est souhaitable qu'elles soient le plus nombreuses possibles et qu'il ne soit plus obligé de revenir dessus pour chaque mises à jour. Les transformations de mises à jour sont le minimum des transformations qu'il faut opérer pour publier la nouvelle version du jeu de données. Par exemple, il est souhaitable que la publication mensuelle du fichier des marchés publics ne demande qu'un changement de date dans le nom du fichier. Cette étape peut être l'objet d'une réorganisation plus ou moins profonde du travail de production de données ou peut révéler un besoin de formation…
Dans bien des cas, avant l'ouverture du jeu de données, l'agent producteur aura validé les données prêtes pour l’application. Et à son tour, il aura fait valider le fichier à un de ses responsables hiérarchiques. C’est l’occasion de conforter le rythme des mises à jour.
Il faudra produire un texte qui présente le service producteur et les données afin de mettre en avant le jeu de données sur le site internet ou les éventuels messages dans les communiqués de presse ou sur les réseaux sociaux.
Il faudra également savoir si le jeu de données est présenté ou non sous forme de datavisualisation.
Il existe peut-être un événement ou un document qui est en lien avec l’ouverture de ces données. Par exemple, l’ouverture des données des vélos en libre service peut être présentée dans un encadré sur le flyers de la semaine de la mobilité.