Cet article évoque un nouveau modèle, celui de l’open data-flow : des flux de données, de traitements et d’enseignements qu’un lecteur saisit pour créer à son tour de la connaissance. Dans le domaine statistique, l’open data traditionnel ce sont des producteurs qui mettent des données en ligne. Avec l’open data-flow, le focus se déplace vers des acteurs qui s’immergent dans des flux d’analyse qu’ils peuvent modeler et enrichir à leur guise, en temps réel.
Ce rêve n’est plus réservé aux experts et aux outils traditionnels de la data-science. Il devient accessible grâce à la convergence de diverses technologies, en particulier autour du navigateur web. Pédagogie, créativité et exigence sémiologique sont ses valeurs directrices.
Cet article explicite le concept d’open data-flow et commente deux exemples. Un second article[1] présente un cas pratique d’analyse d’une source de données ouverte et évolutive sur les plateformes territoriales open data.
Ouverture à tous les étages !
Le nombre de fichiers téléchargeables sur les plateformes open data ne cesse de croître, tout comme les API de mise à disposition. Ces nouveaux modes de diffusion permettent d’alimenter des tableaux de bord, connectés à des données vivantes, et donc toujours à jour des derniers relevés.
La pandémie de Covid19 a stimulé les flux de données ouvertes, par exemple en France ceux de Santé Publique France ou de l’Insee. Ils ont nourri en 2020 des datavisualisations éclairantes et souvent novatrices.
Comment ne pas être admiratif face à la formidable créativité de chercheurs, mais aussi de data-journalistes, d’étudiants mêmes, créativité affinée au fil des mois de rebondissements et de confinements ! Il y a cependant ceux qui gardent pour eux leur cuisine interne, et d’autres pour qui enseigner le « how-to » est aussi important que diffuser les résultats.
Il est possible aujourd’hui de mettre en scène dans un simple navigateur web un flux complet qui part des données source, expose les algorithmes de retraitement, et délivre les enseignements majeurs au travers de visualisations élaborées. Mieux encore, si le concepteur en décide, ce flux va totalement s’ouvrir à la curiosité et l’intelligence de son spect-acteur. Ce dernier accédera alors aux données à toutes les étapes de leur affinage, aux algorithmes eux-mêmes pour les ajuster en temps réel dans le flux. Il pourra réutiliser tout ou partie de cet open data-flow dans une page web personnelle ou un processus d’étude parallèle.
Ainsi s’incarne, grâce au web et ce logiciel à la fois simple, universel et ultra-puissant qu’est devenu le navigateur, le rêve d’un partage fluide de l’information et du savoir, et de la meilleure façon de le produire. Nous sommes des utilisateurs engagés et pouvons devenir nous aussi producteurs et diffuseurs de données retraitées et analysées sous de nouveaux angles.
Un open data-flow peut se rejouer et s'affiner en direct
Le web et les réseaux sociaux regorgent de datavisualisations spectaculaires, récemment inspirées par la pandémie. Elles se présentent encore trop souvent sous la forme d’images, voire de gif animés ou de vidéos. Il n’est pas toujours facile d’accéder à tout le processus de leur élaboration : l’auteur répondra par exemple qu’il a assemblé de multiples sources et technologies, éparses sur son ordinateur ; que tout est resté un peu « en vrac », que certains traitements longs et complexes sont difficiles à exposer, surtout pour un large public.
Le remarquable langage RMarkdown a popularisé la notion de flux commenté et reproductible[2]. Il s’agit de mettre ensemble programmes, explications et datavisualisations pour établir la rigueur d’une démonstration et faciliter son appropriation. Le flux a un début et une fin, il reproduira le même résultat à partir des mêmes inputs, il est indépendant de toute autre influence extérieure.
Dans le cas de RMarkdown, il faut toutefois distinguer l’environnement de travail (un script et les données d’entrée) du résultat publié (html, doc, pdf…) Le document généré est le produit d’une compilation, d’un tricotage comme on dit joliment en anglais (to knit). Il ne montre que ce que le concepteur a choisi d’exposer. Je me demande parfois : par où accéder aux données source ? Comment cette jolie carte a-t-elle été générée ? Puis-je récupérer les données finales en CSV ? La réponse n’est pas toujours là immédiatement sous la main.
Un open data-flow « full-web » élimine la phase de compilation puisque tout se déroule, de l’acquisition des données à la production graphique, dans le navigateur.
L’open data-flow web
en 12 bonnes pratiques
Le modèle d’open data-flow que je valorise ici donne toute sa force au concept d’ouverture, qui permet de voir les opérations et d’interagir. C’est un facteur clé d’engagement et d’appropriation que de pouvoir modifier et réexécuter le flux, et vérifier qu’il s’écoule toujours avec fluidité ! Tentons ici de préciser les critères d’un « open data-flow abouti » :
- les données sont exportables à toutes les étapes du flux, y compris celles affinées pour les graphiques ;
- Les données font l’objet de traitements visant à les synthétiser, à en exprimer la quintessence. On ne se contente pas de les exposer, brutes, sous une forme vaguement graphique. Sous le feu de traitements statistiques exigeants, les défauts de qualité des données peuvent être détectés, et donc corrigés ;
- les datavisualisations s’exportent (en PNG et aussi en format éditable SVG), elles se partagent aisément sur le web ;
- leurs paramètres de construction sont accessibles : styles, couleurs, variables…
- les règles de sémiologie sont respectées, il ne s’agit pas de vouloir en mettre plein la vue si cela « ne rime à rien » ;
- Les algorithmes sont accessibles, modifiables. Ils s’exécutent en temps réel. Mieux encore : de façon visuelle, progressive, animée[3], pour en exprimer la logique de déploiement ;
- les commentaires peuvent être révisés, en fonction de la mise à jour des données d’entrée. La modélisation du flux est toutefois suffisamment robuste pour que les opérations et représentations prévues gardent leur pertinence, même si les données ont évolué de façon inattendue ;
- le flux s’exécute avec un outillage standard, ne requérant aucune installation de logiciel ou de plugin, typiquement le navigateur web moderne. Le serveur met à disposition les données et programmes du flux. Il n’intervient pas dans l’exécution du flux lui-même ou la préparation des données. Il n’a pas à héberger de logiciels spécialisés ;
- les bibliothèques utilisées sont libres d’usage « by design » et leur code ouvert (rappel toujours utile, vu l’actualité…)
- le code est lisible et commenté. Il suit si possible les principes de la programmation fonctionnelle : séparation claire entre données et opérations, opérations décomposées en actions élémentaires, lisibles, chaînées dans un pipeline. Séparer fonctions et données permet de réutiliser des fonctions à valeur ajoutée dans un autre cadre, avec d’autres données ;
- les règles de l’accessibilité aux personnes avec handicap sont, autant que faire se peut en datavisualisation, respectées : données accessibles, couleurs utilisées, contrastes et polices adaptés, textes traduisibles ;
- un open data-flow peut intégrer TP ou quiz, soit des outils d’apprentissage et de contrôle des connaissances.
Traduit en français, l’open data-flow est bien plus qu’un flux de données ouvertes, c’est un flux ouvert de données et de connaissance.
Nombre de ces principes, les connaisseurs l’auront déjà relevé, sont professés depuis plusieurs années par Mike Bostock, le créateur de D3.js et Observable[4].
Plusieurs technologies convergent pour faire du navigateur
une alternative crédible
Plusieurs facteurs interviennent fin 2020 pour favoriser l’éclosion de « web open data-flows » :
- des navigateurs devenus extraordinairement véloces, avec des mécanismes puissants de compilation à la volée. Ils présentent désormais une efficacité comparable d’un éditeur à l’autre (V8/Chrome, SpiderMonkey/Firefox, JavaScriptCore/Safari). La rapidité des calculs s’étend aux affichages, une carte riche par exemple apparait désormais bien plus vite dans un navigateur que dans certains logiciels statistiques…
- une très large base installée de navigateurs compatibles avec la norme JavaScript ES6, qui permet de charger à la volée des modules spécialisés (statistiques, cartographiques, etc.), et est particulièrement agréable à utiliser ;
- une version de la plateforme ouverte Observable et du cadre de référence D3.js compatible ES6, pour un code encore plus robuste, ouvert et flexible,
- l’arrivée (septembre 2020) de la librairie Arquero[5] de Jeffrey Heer, grammaire de manipulation de jeux de données, une sorte de Tidyverse en JavaScript, étonnamment flexible et rapide. Avec elle, tout devient possible : agrégations, filtres, transpositions, recodages, calculs statistiques, window-queries… Arquero est parfaitement complémentaire de Vega-Lite, librairie graphique créée aussi par Heer, au maniement comparable à R/ggplot2 ;
- la maturité du format de données Apache Arrow[6]. désormais publié en version 2.0.0 (octobre 2020). Ce format binaire « in-memory » encode des tables de données potentiellement volumineuses, les modélise par colonnes précisément typées. Il se charge très vite en mémoire vive[7], car il élimine les opérations de sérialisation / désérialisation. Un navigateur peut le lire avec la librairie apache-arrow.js.
Avantages et inconvénients d'un navigateur
Rappelons les avantages spécifiques du navigateur web :
- il est gratuit et accessible à tous, un flux web peut s’exécuter sur n’importe quel media,
- il n’interfère pas (ou de façon cadrée/sécurisée) avec la machine locale et son système de fichiers,
- il s’appuie sur un langage très largement utilisé et en évolution constante : JavaScript,
- il peut ingérer un bel éventail de formats de données statistiques : CSV, Json, XML, Apache Arrow et même des paquets compressés de ces formats,
- avec CSS, il met en page de façon élégante et adaptative,
- son moteur de rendu, avec un battement de 60 cycles par seconde et des animations différées en fonction du « scroll », permet un dévoilement progressif, fluide et contrôlé du flux.
Mesurons-en aussi les inconvénients :
- une page web ne peut pas écrire dans le système de fichiers local, comment donc sauvegarder un résultat de flux ?
- les contraintes de chargement cross-domain (CORS) peuvent compliquer l’accès à certaines ressources open data.
Ces inconvénients sont aisément surmontables. L’utilisateur pourra toujours sauvegarder un résultat issu du flux, le navigateur demande simplement une action explicite (cliquer sur un bouton) de l’usager pour ce faire.
S’agissant des accès cross-domain, d’une part une plateforme open data devrait par principe les permettre, comme le rappelle le W3C, et c’est le cas dans la plupart des situations. D’autre part, il n’est pas très difficile de les contourner, avec un proxy.
Deux exemples commentés d'open data-flows sur le web
En cette fin 2020, la source « données Covid » reste la principale utilisée. Ce premier exemple s’appuie sur des données de Santé Publique France qui met à disposition sur data.gouv.fr des données quotidiennes et aussi hebdomadaires. Nicolas Lambert a conçu un élégant tableau de bord qui se met à jour tout seul, à chaque fois que l’on visite son article. Il comprend une carte (superbe) et un graphique, que j’insère ici (c’est facile, avec la technologie Observable). Il est toujours vivant et connecté à sa source de données CSV, présentée sur cette page, il se rafraîchit donc régulièrement.
Comme la mention sous le graphique l’indique, le document original est un « notebook Observable », qui, dans la logique open data-flow, expose l’ensemble du flux et ses opérations internes :
- chargement du CSV de données (32 000 lignes, données départementales, par âge et semaine),
- affichage rendu plus explicite des tranches d’âge,
- agrégation du jeu de données pour toute la France,
- construction du graphique « heatmap » ci-dessus.
- améliorer la lisibilité des chiffres, les textes blancs sur fond clair posant problème, ou optimiser les couleurs pour les Daltoniens,
- factoriser le programme de construction du graphique pour pouvoir l’appliquer à une autre source de données, avec des axes ou des noms de variables éventuellement différents.
Ce second exemple nous emmène aux États-Unis, il porte toujours sur le thème Covid. Les données sont quotidiennes, par État, compilées par le New-York-Times. Le propos de Michael Freeman est plus didactique encore, avec une visée sémiologique : il compare les mérites de différentes représentations pour ce diagramme en barres.
La modularité d’Observable me permet d’insérer ici la dataviz originelle avec sa barre de choix de représentation (Choose stacking). Le graphique ci-dessous reste connecté à sa source de données, mise à jour quotidiennement.
New COVID 19 Cases Per day (top 10 states)
Freeman a utilisé la librairie Arquero pour transformer le jeu de données d’origine, en lui appliquant un « pivot » (une transposition) comme on peut le faire dans R avec Tidyverse. Arquero[8] est une (superbe) librairie JavaScript inspirée par ce célèbre package R. La transposition est ainsi menée très élégamment, en 3 lignes.
Freeman a ensuite fait l’effort de factoriser son programme de génération des 3 variantes de graphique, de telle sorte qu’il puisse s’appliquer à bien d’autres jeux de données, sans rapport avec le Covid. Et surtout, il explicite sa démarche, expliquant concrètement comment faire. Pour en savoir plus, cliquez sur le lien au bas du graphique !
Le concept de « flow »
Ce n’est pas vraiment un hasard si je reprend ici le terme de « flow », concept forgé par le psychologue hongrois Mihály Csíkszentmihályi. Il désigne une expérience optimale, une sorte d’état de grâce, tel que que peut le vivre un sportif par exemple, lors de la réalisation d’une séquence parfaite. Je me plais à imaginer que Jeffrey Heer, l’auteur de la remarquable démonstration dont le 1er graphique de cet article est extrait, a éprouvé quelque chose d’analogue en la réalisant !Références - Pour aller plus loin
[1] Open data-flows : une approche récursive avec des données ouvertes sur l’open data (2/2)
[2] Putting the R into Reproducible Research (Anna Krystalli, 2019)
[3] Visualizing algorithms (Mike Bostock, 2014)
[4] Observable en Observable (Alain Roan, 2019)
[5] Introducing Arquero (Jeffrey Heer, 2020)
[6] Apache Arrow: A cross-language development platform for in-memory analytics
[7] Apache Arrow & Arquero: strategies for fast flat file processing (Éric Mauvière, 2020)
Bravo pour ce billet ! Et merci.
Merci pour votre lecture attentive et cette expression !