À partir d’un octogone,
emboîtement de polygones étoilés mis en abyme
Ce n’est pas tous les jours que l’on peut jouer avec de solides données open data sur l’open data. Grâce aux efforts parallèles de Loïc Haÿ (FNCCR) et Jean-Marie Bourgogne (ODT), c’est désormais possible. Suivant de près les plateformes open data territoriales, ils ont chacun mis en ligne des fichiers de données interrogeables via une API. Cette ouverture s’avère particulièrement intéressante car ce recueil évolue en permanence.
Dans un précédent article, j’introduis la notion de « web open data-flows[1] », des flux d’analyse ouverts et créatifs avec lesquels chacun peut interagir, dans son navigateur. C’est l’occasion d’en expérimenter les joies, sous forme d’un cas d’école, une petite mise en abyme de l’open data. Elle nous amènera à quelques considérations sur ce que veut dire en pratique « se brancher sur une API ».
Il s’agit dans les deux cas d’une liste, mise à jour en continu, d’un peu plus de 200 plateformes. Une API REST permet de l’interroger, et en l’occurrence de la charger intégralement dans le navigateur. Les variables descriptives localisent les plateformes, identifient leur support juridique, leur vocation, les technologies utilisées… Elles renseignent aussi les diverses URL d’accès, à la page d’accueil ou aux APIs.
L’API AirTable n’est pas triviale. Pour interroger ces tables, il faut :
- créer un compte AirTable,
- créer une copie synchronisée de la base source (ce qui suppose que son gestionnaire en ait ouvert les droits, c’est bien le cas ici, merci aux deux auteurs),
- tester l’API sur cette copie avec une clé personnelle, gérant une limite de 100 lignes par appel en chaînant 3 requêtes.
Ouf, ça marche ! Comme le montre le tableau ci-dessus qui interroge en direct, selon votre bon vouloir l’une ou l’autre de ces bases.
Pour information, ou rappel, le tableau est un aperçu vivant d’un « Notebook Observable », consultable par le lien figurant dans le pied.
Analyse graphique des corrélations entre variables
À titre d’exemple et sur la première source, ce graphique de type Parallel Sets permet de croiser deux critères qualitatifs, à gauche le mode de collaboration, à droite la thématique du portail. L’épaisseur des segments reflète le nombre de plateformes pour chaque croisement. On peut voir ce graphique comme la juxtaposition de deux décompositions, respectivement à gauche et à droite, chacune triée par effectif décroissant, mais avec en plus les corrélations entre l’une et l’autre.
Ce graphique est vivant, puisque connecté à une source de données externe qui s’enrichit en continu. Mais il est figé sur 3 paramètres : la source (ODT), les deux variables de croisement. Et accessoirement les couleurs.
Plateformes open data régionales : croisement de la technologie et du mode de collaboration
Que nous apprend ce diagramme ? Par exemple qu’OpenDatasoft est la première technologie utilisée. Ou que les plateformes partenariales fonctionnent très majoritairement avec GeoNetwork.
Notre flux d’analyse se doit d’être davantage flexible pour permettre tous les types de croisement. Je profite de cette petite étude pour affiner et généraliser ce graphique. J’en fais un module plus générique, dénommé Parallel Sets chart et publié sur la plateforme Observable.
Chacun pourra ainsi l’appliquer à n’importe quel jeu de données, dans le cadre de ses propres open data-flows. Il comprend 3 paramètres d’entrée : le jeu de données, les 2 variables de croisement et quelques options.
En voici une illustration, vous pouvez jouer vous même avec ces paramètres pour poser vos propres croisements à partir de la base de votre choix :
Dans l’esprit des bonnes pratiques de l’open data-flow, j’ajoute des boutons d’accès aux données retraitées et d’export du graphique dans différents formats.
Un mot sur CORS : Cross-origin resource sharing
Pour poursuivre cette mise en abyme de l’open data sur l’open data, étudions l’accessibilité de ces portails, et notamment de leur API quand ils en proposent une. L’intérêt avec une API, c’est de pouvoir l’utiliser avec un programme, pour automatiser des interrogations. Ce peut être un script R, Python, ou même … Javascript, au sein de la présente page web, dans la logique de l’open data-flow !
Mais ce qui fonctionne bien avec un appel manuel n’est pas si évident à partir d’un module JavaScript, car les navigateurs ont des mécanismes de sécurité qui contrôlent les appels qu’une page web peut faire à un autre site. CORS est un des protocoles pour encadrer cela. https en est un autre.
CORS est généralement compris comme une contrainte, mais c’est une question de perspective. CORS ne veut pas dire « contrainte » mais « partage de ressources ». Partant du constat que, par défaut, les navigateurs empêchent, pour des raisons de sécurité, deux sites web de communiquer entre eux, CORS est une façon d’ouvrir la porte à une telle communication.
Comme l’explicite le W3C :
« Permettre l’accès CORS pour les données ouvertes liées (linked OpenData) et les services connexes est spécialement important ; sans cela, nos données ne sont tout simplement pas ouvertes à tous les clients. »
Le recensement de Loïc Haÿ présente l’intérêt de lister les URL d’API. Le processus de gestion des erreurs propre à JavaScript (comme tous les langages) nous permet de détecter une impossibilité d’accès. Celle-ci a plusieurs origines possibles :
- l’adresse appelée est invalide (par ex elle a récemment changé),
- l’API nécessite une authentification (ce n’est pas l’esprit de l’open data mais cela arrive), et n’est pas claire sur la nature du retour à faire à l’utilisateur,
- l’API n’est pas compatible avec https (protocole non supporté ou certificat invalide),
- l’API ne permet pas le CORS.
Ces problèmes sont minoritaires, mais concernent, à la date du 14 décembre 2020, une bonne vingtaine de portails. Vous pouvez relancer vous-même l’analyse, ci-dessous, pour voir si le constat s’est amélioré !
Extension du recueil
Ces 2 recensements vont certainement se rejoindre et constituent une précieuse ressource sur l’open data en France. Il serait fort appréciable qu’ils puissent s’étendre :
- aux plateformes d’envergure nationale,
- à de nouvelles variables descriptives : année de création, nb. indicatif de jeux de données, qualité de l’accès distant (Cors, https, authentification), liens avec data.gouv.fr, etc.
Récursivité
Pour illustrer le modèle d’open data-flow, l’exemple utilisé ici s’appuie sur de l’open data sur l’open data : des sources de données qui recensement elles-mêmes des sources de données. Joie de la mise en abyme, vaste source d’inspiration des mathématiciens et des artistes. Les exemples sont innombrables. Quelques-uns servent ici d’illustrations : la spirale de Fibonacci en introduction, un polygone étoilé un peu plus haut dans cette page ou le triangle de Sierpiński ci-contre. La mise en abyme est un procédé très utile en informatique et programmation, où l’on parlera alors de récursivité. Un dicton anglais énonce : « to iterate is human, to recurse divine ! »
Pour aller plus loin
[1] Open data-flows sur le web : c’est fou ce qu’un navigateur moderne sait faire ! (1/2)
[2] teamopendata : Inventaire des plateformes de données territoriales
[4] fil twitter de Loïc Haÿ présentant sa démarche
Bon ok vous voulez une approche plus collaborative dans la #màj des données ? Je peux cuisiner 🥘 une #WikiTable éditable par tous pour modifier/compléter les enregistrements existants ou en ajouter de nouveaux 🥳 ça vous dit ?
— Loïc Haÿ (@LoicHay) October 21, 2020