Accédez aux données sur files.opendatarchives.fr

Cela fait quelques temps que l’idée d’archiver les données publiées en opendata me trotte dans la tête. Je trouve en effet formidable qu’un projet comme archive.org permette de revenir en arrière et de retrouver des contenus aujourd’hui indisponibles ou difficilement disponibles. Malheureusement, les jeux de données opendata, ne font pas partie de ce que cette archive du web conserve actuellement.

Ces données ouvertes sont disponibles, pourquoi les archiver ?

La stabilité de publication de certaines données est malheureusement assez aléatoire et surtout sans garantie dans le temps.

On a déjà vu des jeux de données ouverts ne plus être disponibles… ou difficile à retrouver. J’ai constaté plusieurs cas de figure.

Publier uniquement la dernière version

Certains portails ne publient que les versions les plus récentes des données et suppriment au fur et à mesure les précédentes. Parfois ce ménage est fait pour des raisons de coûts (stockage, hébergement, etc), mais aussi parfois à dessein pour publier à minima ce qu’on est réglementairement obligé de publier (je pense aux contrôles d’hygiène où les textes obligent à publier le dernier contrôle pendant un an, mais n’interdisent pas de publier plus que ça !).

Ce manque de profondeur vient souvent de réutilisations préconçues présentes dans la tête du producteur des données qui ne voit pas toujours les réutilisations originales et alternatives qui peuvent en découler.

Comparer des données sur une longue série temporelle permet de faire ressortir ou mesurer certains phénomènes comme le recul du trait de côte, l’extension urbaine, l’évolution des budgets, l’évolution de l’activité d’un service public, etc.

Les données temps réel, rarement historisées

Ces données sont typiquement publiées pour un usage préconçu: l’information d’usagers sur l’état d’un service en temps réel (transport, disponibilité, etc).

Rarement une historisation est faite et publiée elle aussi. Il y a une question de volumétrie mais aussi une question de mode de fonctionnement différent entre les systèmes d’informations qui gèrent de la donnée “chaude” en temps-réel et de la donnée “froide” historisée et archivée.

La encore l’accès à des séries longues permet d’autres usages, analyses, et permet aussi, par exemple, d’alimenter ou de valider des modèles prédictifs (oui, l’IA), voire de remonter le temps.

C’est en m’intéressant aux données liées au temps dans le cadre d’OpenEventDatabase que j’ai constaté ce manque d’historisation et l’intérêt que cela pourrait avoir. OpenEventDatabase n’a donc pas été limité aux évènements en cours, mais permet d’accéder aussi à ceux passés (et à venir).

Bien sûr les données publiées uniquement par API tombent dans cette catégorie… elles sont de plus utilisables tant que l’API fonctionne.

Le changement de portail opendata

Nous avons tous été aussi victime d’un changement de site où le ménage a plus ou moins été fait lors du passage à la nouvelle version. De “vieilles” données peuvent être considérées comme n’étant plus utiles et l’intérêt de maintenir leur publication n’avait pas été perçu.

Là encore… les série longues, les comparaisons nous échappent.

Les dépublications volontaires

Elles sont rares, mais voici au moins deux exemples récents :

• les données des ventes et achats de pesticides, dépubliées sûrement sur pression des lobbys via le Ministère de l’Agriculture… puis visiblement republiées après un article de Médiapart sur le sujet qui s’est basé semble-t-il sur une archive que j’avais fait et partagé
• les données des points de captage d’eau potable et des périmètres de protection : elles étaient historiquement en opendata afin de savoir où respecter la réglementation sur l’environnement, mais “à cause de la menace terroriste” elles ont été dépubliées

Le jeu de piste

Règle du jeu simple: publier différents millésimes d’un même jeu de données, mais à des endroits différents.

Je pense au Registre Parcellaire Graphique où certaines années sont téléchargeables sur data.gouv.fr, d’autres sur le site de l’IGN, etc…

Même chose pour Corine Land Cover, certaines années sont sur un site et la dernière version ailleurs (et non signalée sur le premier bien entendu).

L’indisponibilité temporaire

Dernier cas, la coupure temporaire de service… le site sur lequel les données dont vous avez besoin ne répond pas ou bien suite à un incident technique le jeu de données est indisponible temporairement.

Avoir une copie miroir permet de répondre aussi à ces indisponibilités temporaires.

Historiser et archiver

Depuis quelques temps déjà, je garde des jeux de données essentiels dans un maximum de millésimes sur data.cquest.org mais a jusqu’à présent été très artisanal.

Pourquoi ne passer passer à la vitesse supérieure ? Pourquoi ne pas archiver tout ce qui peut l’être “au cas où” ?

Ceci peut se faire en attendant que les services officiellement chargés des archives prennent un jour le relais mais aussi pour avoir une archive citoyenne (souvenez vous de la rumeur de dépublication des données de l’agence américaine de l’environnement après l’élection de Donald Trump).

C’est parti pour le projet opendatarchives, un projet d’été, saison des moissons !

Comment faire ?

Mon premier problème est en effet de moissonner la multitude de portails où des données opendata sont publiées !

Le portail national data.gouv.fr permet de publier directement ses données, mais il effectue aussi un moissonnage de certains de ces portails. Pas tous car c’est au producteur de s’enregistrer et de faire le nécessaire pour que son portail soit moissonné et il n’y a pas de moissonnage pro-actif fait par data.gouv.fr.

Le moissonnage ne permet de toute façon que de répertorier les jeux de données, leurs méta-données, mais pas le contenu des jeux de données.

data.gouv.fr publie depuis quelques mois un export régulier de son catalogue des jeux de données, ce qui permet d’automatiser l’archivage de ce qui y est catalogué mais aussi d’identifier les portails de publication initiale. Il y a aussi l’API de data.gouv.fr qui permet d’interroger le catalogue entre deux exports globaux du catalogue.

En complément de data.gouv.fr, de nombreux portails fonctionnent avec l’offre SaaS d’OpenDataSoft (plus d’une centaine). Là aussi une API permet d’explorer le contenu et de transférer les données.

En archivant ce qui est publié sur ces deux plateformes, je pense qu’on peut couvrir l’essentiel du paysage de l’opendata français. Ce sera à compléter pour des sites basés sur d’autres outils ou au fonctionnement spécifique comme celui de l’INSEE qui diffuse beaucoup de données, mais pas avec la logique de catalogue habituelle aux portails dédiés à l’opendata.

Télécharger puis stocker

Le moteur d’archivage doit s’appuyer autant que possible sur les metadonnées pour ne télécharger que les jeux de données modifiés. Ceci permet d’économiser des ressources pour l’archivage, mais aussi du côté des portails où sont publiées les données. Ce n’est pas parce que la fibre est (enfin) arrivée qu’il faut abuser 😉

Une fois les données téléchargées se pose la question du stockage.

Louer des serveurs ou de l’espace de stockage dans le “cloud” revient vite cher, du coup pour ce projet un peu fou, j’envisage de commencer par du “fait maison” et je verrai ensuite en fonction des retours et de l’expérience car c’est souvent en faisant qu’on apprends.

Pour limiter les besoins de stockage, la compression doit être la règle ainsi que la déduplication, car nombreux sont les jeux de données identiques publiés sur plusieurs sites !

C’est le travail de ZFS… un filesystem du 21ème siècle qui mériterai un article pour lui tout seul 😉

Le micro-datacenter (un ou deux serveurs) qui se trouve depuis plusieurs années dans ma cave, va devenir un mini-datacenteer. L’arrivée de la fibre permet en effet bien plus de choses qu’une simple ligne VDSL même courte. J’utilise par ailleurs au maximum du matériel recyclé ou d’occasion avec une démarche autant que possible “verte”.

Quelle est la volumétrie de l’opendata disponible en France ?

En démarrant ce projet, je n’en avais vraiment aucune idée sur la faisabilité, car le volume de données à archiver est le sujet principal tant pour leur transfert que leur stockage.

Toutefois, les données les plus utiles et utilisées ne sont pas forcément volumineuses. Le fichier des codes postaux est dans le top 10 des données les plus téléchargées mais il ne pèse à peine plus de 1Mo (compressé) et sa mise à jour est peu fréquente.

Les plus gros volume que je connais, ce sont les photos aériennes et les sorties des modèles de prévision météo où là il faut rapidement aligner les téraoctets.

Par exemple, pour la moitié de la couverture en images aériennes de l’hexagone à 20cm par pixel, il faut compter environ 5To (donc 10To quand tout le territoire sera en opendata). Les ortho-photos à 10cm voire 5cm commencent à arriver, donc 4 ou 16 fois plus de données seront à stocker à l’avenir même si leur mise à jour ne se fait qu’avec un cycle de 3 à 5 ans.

Les prévisions météo sont moins volumineuses (quelques dizaines de Go), mais mise à jour toutes les 6h ! C’est donc leur historisation qui crée la volumétrie, mais cela cause aussi le problème d’accès concurrent en téléchargement car l’essentiel des réutilisations se fait sur les dernières données disponibles, et le plus rapidement possible (avant qu’elles ne passent du statut de prévision dans le futur à prévision mais dans le passé). Leur mode de diffusion est d’ailleurs problématique… serveur saturé, là où il faudrait passer à une diffusion en peer2peer. Une archive de ces données existe déjà, je vais donc mettre ça de coté pour démarrer.

Premier jet pour “opendatarchives“

J’ai travaillé cet été sur une première mouture très “alpha” qui a déjà archivé les portails suivants :

• data.gouv.fr et ses verticales (geo, adresse, cadastre, transport)
• ceux hébergés par OpenDataSoft
• le Géoportail de l’Urbanisme qui sert à publier les données d’urbanisme (PLU, etc)

Au dernier comptage on est à environ 5To.

Comment organiser l’archive des données ?

C’est sûrement l’aspect le plus instable du projet.

Le besoin est double pour avoir une organisation simplifiant le processus d’archivage et permettant une exploration logique de l’archive.

Pour l’instant l’organisation de l’archive des portails ODS est la suivante:

Chaque portail contient:

• un fichier CATALOGUE.csv.gz : avec le dernier contenu du catalogue archivé
• pour chaque jeu de données, un fichier XXX-meta.json avec ses métadonnées
• pour chaque jeu de données, un fichier XXX.csv.gz avec le contenu du jeu de données au format CSV
• pour les jeux de données contenant des informations géographiques un fichier XXX.geojson.gz est aussi archivé
• un dossier archives contient les anciennes versions des meta données et du contenu du jeu de données
• le CATALOGUE est traité avec le même principe pour être lui aussi archivé

Certains jeux de données contiennent par ailleurs des pièces jointes (documentation, mais aussi vrai jeu de données comme les GTFS). Elles sont indiquées dans leurs métadonnées.

Ces pièces jointes sont elles aussi archivées dans un dossier “attachments” du dossier d’archive du jeu de données :

Une autre variante concerne les jeux de données qui font référence à des documents (PDF, bureautique, etc), des média (images ou autre) voire à des fichiers de données. Là il faut explorer le contenu du jeu de données pour repérer les liens et archiver le contenu correspondant qui est stocké dans un dossier “files” du dossier d’archive du jeu de données :

L’organisation de l’archive liée à data.gouv.fr et du géoportail de l’urbanisme n’est pas encore stabilisée, mais l’objectif est de se rapprocher si possible de l’organisation ci-dessus.

Limiter la duplication pour économiser transferts et stockage

La duplication de données a plusieurs causes:

• il n’est pas toujours facile de détecter les changements sur les metadonnées ou sur le contenu des jeux de données, les dates de dernière modification changent parfois sans qu’il y ait eu de modification
• certains jeux de données sont des reprises ou extraits de données publiées ailleurs

Pour le premier cas, les metadonnées récupérées à chaque passage par le moteur d’archivage sont comparées à la dernière version et ne sont conservées qu’en cas de véritable changement.

Pour le second cas, une liste d’exclusion évite que certains jeux de données très souvent republiés ne soit dupliqués.

Cette liste contient en particulier les jeux de données du “Service Public de la Donnée de Référence” (SPD), parfois bien volumineux comme:

• SPD: base SIRENE, Base Adresse Nationale, Registre Parcellaire Graphique
• hors SPD: Geofla, prévisions de météo france, répertoire national des élus

Étapes suivantes…

Après un peu de recul (dans quelques semaines), il faudra vérifier le résultat de l’archivage, en particulier sur la déduplication et la gestion des erreurs de téléchargement très perfectible.

La réorganisation de l’archive des données publiées sur data.gouv.fr est à faire, ainsi que pour la partie géoportail de l’urbanisme.

Une interface moins austère qu’un listing est aussi à prévoir !

Étendre l’archivage à d’autres portails de publication.

Vos retours sont les bienvenus sur le fil de discussion ouvert sur le forum teamopendata ou sur le projet github !