De nouvelles visualisations pour le projet RICardo

Le site a été créé en 2016 pour accompagner la publication de la première version des données. Une communication (voir les slides) à la conférence Digital Humanities 2016 explicite les choix qui ont été faits à l’époque pour proposer une exploration progressive du commerce international aux XIXe et début XXe siècles.

Il propose tout d’abord une vue agrégée du commerce au niveau mondial (page World), puis une vue détaillée du commerce d’un pays (page Country) et, à un niveau encore plus fin, permet de comparer le commerce d’une paire de pays afin de mettre en perspective les divergences entre leur statistique (page bilateral). Une nouvelle vue a été apportée à cet ensemble afin de documenter les sources des données utilisées et de visualiser le degré de complétude de la base (page Metadata).

Ce site a été développé en angularJS à l’aide de D3.js pour les visualisations et de Python Flask pour l’API qui sert les données stockées dans une base SQLite (code source).

Pour aider Béatrice Dedinger (responsable scientifique du projet) à concevoir et prioriser les évolutions à mener, nous avons proposé une prestation en mode agile. À l’instar du mode au forfait, nous facturons le temps passé et non la réalisation d’une fonctionnalité qui doit dans ce cas être spécifiée en détail a priori. Le mode agile a en effet l’avantage de permettre de concevoir ensemble ce qui doit être fait en prenant en compte les contraintes scientifiques, techniques et design. Notre objectif est simple : apporter aux utilisateurs le meilleur outil possible pour un budget fixe et une liste d’idées comme points de départ. Nous avons commencé le projet par un atelier de co-conception durant lequel nous avons discuté une à une chaque idée d’évolution venant de Béatrice mais aussi celles que nous avions en tête. Cette étape est très importante car échanger nos points de vue permet non seulement une meilleure conception mais aussi d’assurer un meilleur partage des enjeux et contraintes de chacun. Cette acculturation est un socle très précieux pour la suite du projet quand il faudra faire face aux imprévus.

Une fois les idées d’évolutions précisées (conception et niveau de difficulté), Béatrice a pu nous indiquer un ordre de priorité. La suite est "simple", un rendez-vous hebdomadaire permet de rendre compte de ce qui a été fait en combien de temps afin de décider ensemble des nouvelles priorités (itérations inspirées des méthodes agiles).

Dans la suite de ce texte, nous détaillons, les principales évolutions que nous avons apportées à RICardo en précisant les enjeux en termes de visualisation et de design interactif. Nous n’entrerons pas dans le détail des évolutions techniques comme par exemple notre toute première tâche qui a consisté à mettre à jour les versions des dépendances techniques et à moderniser la méthode d’empaquetage du code client afin de partir sur des bases saines pour accueillir les évolutions.

Un site d’exploration visuelle permet de générer de nombreuses visualisations en fonction des choix faits par l’utilisateur quant aux différents paramètres de filtrage. Chaque vue (World, Country, Bilateral et metadata) est une application de visualisation à part entière qui peut être appliquée sur une multitude d’objets de la base de données (les entités dans le cas de RICardo). Par ailleurs chaque page propose des moyens de filtrage afin de préciser chaque point de vue (filtrage temporel dans le cas de RICardo). Ainsi une vue n’est pas une page web mais bien une multitude de pages possibles. C’est le modèle des Single Page Web App. Pourtant l’utilisateur visite bien un site web, et ses actions (choix dans les vues) le guident dans diverses pages. Aussi il est préférable de refléter les actions de sélection/filtrage dans l’URL de la vue afin de signifier à l’utilisateur et à son navigateur qu’il a bien changé de page (même si c’est un changement de page virtuel car le contenu HTML est géré par le JavaScript dans le navigateur).

Au-delà du respect des principes de la navigation web, refléter les actions dans l’URL permet de tout simplement bénéficier de ce qu’est une URL où chaque vue :

Cette dernière fonctionnalité est aussi appelée permalien^[1] et est particulièrement utile afin de partager des visualisations entre collègues ou depuis des publications.

Ainsi il est dorénavant possible de référencer le commerce de la France entre 1821 et 1870 et notamment la comparaison des valeurs de commerce avec ses trois principaux partenaires de l’époque (Royaume-Uni, États-Unis et Belgique) à l’aide d’une URL :

Certes la lisibilité de cette URL n’est pas optimale mais c’est le prix à payer pour l’exhaustivité !

Pour permettre d’analyser le commerce international à partir de nombreuses sources venant de pays du monde entier, il faut pouvoir comparer les valeurs rapportées. Or chaque pays relève les flux de commerce dans sa propre monnaie. Une opération de conversion de toutes les valeurs de commerce en une monnaie commune est donc nécessaire. Pour la faciliter, Béatrice a recueilli les taux de change en pound sterling d’une centaine de devises sur la période c.1800-1938.

Cette importante base de taux de change n’était jusqu’ici pas explorable et nous avons décidé de la mettre en valeur en ajoutant une nouvelle vue qui a pour objectif de :

Nous avons donc opté pour une série de petites courbes (small-multiple) permettant de lister toutes les devises d’un coup. On répond ainsi au premier objectif surtout en ajoutant un champs permettant de filtrer le nom des devises.

Nous avons ensuite choisi de représenter chaque devise sous la forme d’une courbe indiquant la valeur de son taux de conversion par année afin de répondre aux objectifs deux et trois.

La courbe a l’avantage d’être automatiquement perçue comme une valeur qui change dans le temps. Puisque nous devons faire avec la contrainte de la hauteur fixe induite par l’empilement des devises, elle a l’inconvénient d’utiliser la hauteur en pixel pour représenter la valeur de chaque point^[2].

Nous ne pouvons pas utiliser plus de pixels pour représenter des taux de très grande valeur comparés à d’autres. Il faut abandonner l’idée que les courbes soient comparables en valeur absolue. Concentrons-nous plutôt sur notre objectif de comparer les évolutions internes des taux plutôt que de les comparer entre eux.

Pour représenter aux mieux les évolutions des taux nous avons choisi de casser une règle classique de visualisation de courbes : l’axe des ordonnées ne commence pas à 0^[3] !

En période de stabilité monétaire, les taux stables vont osciller autour d’une valeur moyenne qui peut être très éloignée de zéro.

Aussi pour voir au mieux les évolutions, même mineures, mieux vaut adapter l’échelle localement, c’est-à-dire l’adapter aux plages de valeurs de chaque devise.

Il faut cependant veiller à bien indiquer que cet espace des possibles est unique pour chaque courbe, ce que nous faisons ici en indiquant systématiquement en graduation de l’axe des ordonnées le minimum et le maximum. L’axe des ordonnées étant placé à gauche de la courbe il se trouve juste en dessous du label de la devise. Ainsi la lecture d’un nouveau bloc se fait naturellement d’abord par le nom de la devise puis par les valeurs minimales et maximales du taux de change. On pose ainsi le contexte de lecture au plus tôt.

Et comme toujours ces visualisations permettent de découvrir des valeurs qui semblent incohérentes comme le taux de change de la roupie indienne en 1828 !

Un nouveau jeu de données appelé GeoPolHist a été construit afin d’ajouter une dimension politique à la base RICardo. Il liste toutes les entités géopolitiques du monde et leurs liens de dépendance politique depuis 1816 jusqu’à nos jours^[4]. Un site d’exploration visuelle spécifique a été créé pour GeoPolHist par Arnaud Pichon au médialab de Sciences Po.

Ces données pourraient permettre de contextualiser l’histoire commerciale des entités commerçantes de RICardo en donnant accès à leur trajectoire politique au long des XIXe et XXe siècles. Telle entité était-elle indépendante ou sous le contrôle d’une autre à cette date ? À l’inverse est-ce que cette entité en contrôlait d’autres à telle date ? Pourquoi le commerce du "Royaume des deux Siciles" s’arrête en 1860 ? Etc.

Ici notre mission était de trouver une manière de représenter ce contexte politique le plus brièvement possible pour inciter les visiteurs à visiter le site GeoPolHist qui explore en détail tous ces liens politiques historiques.

Nous avons donc réfléchi à une synthèse graphique de GeoPolHist pouvant trouver une place dans les pages du site RICardo déjà très chargées en informations visuelles et qui propose un lien vers le site dédié pour découvrir le détail.

L’idée a été d’ajouter une frise politique pour chaque entité commerciale présentant deux informations agrégées :

Ce premier prototype^[5] propose les deux informations sur deux lignes : les hachures représentent les périodes de non-souveraineté, la densité de rouge le nombre de dépendances; on réutilise le principe des pages qui prennent la largeur comme axe temporel.

Pour cette frise en carte de chaleur, nous avons créé des blocs par période et non par année. En effet ce qui importe le plus ici sont les moments de rupture. Ces blocs permettent en effet de représenter deux variables : l’évolution du nombre (variation de l’opacité du rouge) et surtout la fréquence des changements (répartition horizontale des barres blanches).

Cela répond aux objectifs en laissant les détails de la liste précise des dépendances ou des entités souveraines ainsi que les types de liens (colonie, occupation, annexion…​) à l’outil dédié dont le lien est ajouté dans le titre du bloc.

Problème: il est très courant qu’une entité ait une des deux barres totalement vide car toujours souveraine ou sans aucune dépendance. Or cet empilement prend de la place en hauteur, ce qui est critique dans une page déjà très longue. Aussi nous avons tenté de la passer sur une seule ligne.

Grâce aux motifs en hachure on peut superposer les deux ! Sauf que le fond étant une carte de chaleur, son opacité variable rend des hachures noires difficiles à distinguer sur fond rouge à faible opacité, et des hachures blanches invisibles s’il n’y aucune dépendance. Le problème ainsi posé la solution paraît évidente : des doubles hachures noire/blanche !

Voici le code créant le motif à double hachure noire/blanche en SVG avec d3.js (voir ce code sans son contexte).

Cette frise politique a été ajoutée aux deux pages centrées sur des entités (Reporting et Partner) qui ont été créées en refondant la page Country.

La dernière page sur laquelle nous sommes intervenus est Country. Créée pour la première version du site, cette page permettait d’explorer le commerce de certaines entités de la base RICardo, celles dites ‘reporting’. Un reporting est une entité dont le commerce est décrit exhaustivement par les statistiques qu’il publie. Ainsi, le commerce de toutes les autres entités commerçantes qui sont désignées dans les tableaux de commerce des reportings mais qui ne publient pas elles-mêmes de statistiques commerciales ne pouvait pas être exploré dans cette page Country. Une évolution majeure a été de franchir un nouveau pas dans l’exploitation du potentiel de la base RICardo en créant une nouvelle page, la page Partner, ce qui a par là-même conduit à rebaptiser la page Country en Reporting. La page Partner exploite toutes les données collectées par les reportings afin de reconstituer de façon indirecte le commerce bilatéral d’une entité partner^[6].

Nous avons en quelque sorte dupliqué la page Reporting pour l’adapter au cas particulier des partners. La page Partner propose une vision qui reste partielle du commerce de l’entité puisqu’elle est recréée à partir des données des seuls reportings qui l’enregistrent dans leurs tableaux statistiques. Nous n’avons accès qu’à quelques reflets de son commerce vus dans les miroirs des reportings. Le commerce bilatéral du partner ainsi reconstitué ne pouvant prétendre à l’exhaustivité, trois décisions ont été prises :

Pour le point 1. aucune autre conséquence que de supprimer une visualisation. Travailler les points 2 et 3 sur la page Partner nous a permis d’améliorer aussi la page Reporting puisque nous y avons ajouté ce même histogramme du nombre de citations de partenaires (3.), et retravailler la liste des partenaires (2.) a abouti à améliorer également celle de la page Reporting.

En gérant cette prestation en mode agile, nous avons pu engager une collaboration fructueuse tant sur la partie conception que sur les parties techniques. Un enjeu particulièrement important pour des projets de recherche notamment en Humanités Numériques où la complexité des données et l’exigence du cadre interprétatif demandent des solutions spécifiques à chaque situation.

Nous espérons que ce partage d’expérience pourra aider d’autres équipes dans leur propre projet !