Autopsie d'une dataviz [9] : une carte "entonnoir" pour les régionales 2015

Retour sur la réalisation des cartes réalisées pour Rue89 Strasbourg lors des deux tours des régionales 2015. Objectif : rendre compte, sur une même interface, des résultats électoraux aux niveaux communal, département et régional.

5 200 communes, dix départements, trois régions : ce sont des chiffres-clés de l'Alsace-Champagne-Ardenne-Lorraine (ACAL), nouvelle région administrative créée fin 2014.

Les élections qui ont déterminé la composition du nouveau conseil régional ont été l'occasion de tenter de la cartographie très ambitieuse chez Rue89 Strasbourg. Je vais tenter un résumé le plus exhaustif possible des différentes étapes de ce boulot.

Le bon exemple du Huffington Post

La principale source d'inspiration de ces cartes est ce très bel exemple d'analyse électorale proposée par le Huffington Post, et codée avec la fameuse librairie D3js.

L'application du Huffington repose sur le principe d'un entonnoir : on propose à l'internaute deux niveaux de lecture, avec d'un côté le vote des 300 communes du Massachussets, et de l'autre les 14 comtés de cet Etat.

Huffington Post

Les résultats des plus grands territoires apparaissent comme une synthèse des communes qui les composent, un peu comme si on les avait lâchés dans un entonnoir.

On observe des bastions démocrates et républicains bien délimités au niveau communal, ce qui se ressent sur les résultats cantonaux.

Huffington Post

A l'échelle de l'ACAL, on passait à un niveau bien plus costaud, avec près de 5 200 villes à cartographier. L'échelle départementale d'à peine dix unités me paraissait trop faible, tandis que l'échelle cantonale, plus proche de l'application du Huffington, ne me paraissait pas la plus compréhensible.

Bref, trois niveaux commençaient à émerger pour les futures élections régionales : les communes, les départements, et les régions.

A ce stade, il était temps de se pencher sur la faisabilité technique de la chose.

Un squelette solide avant de démarrer les festivités

En furetant un peu, je suis tombé sur ce gabarit avec code source directement inspiré de la carte du Huffington. Ca m'a suffi pour commencer les tests avec mes propres fichiers géographiques, soigneusement préparés sur le logiciel QGis.

Sans faire un récap' de tous les atermoiements techniques, j'en ai appris plus sur l'option CSS "hidden", qui contrairement au "opacity" de l'exemple, permet de masquer toutes les options d'un calque.

Il y a également eu quelques lignes de code dédiées à un effet de zoom sur les communes de chaque département, directement calqué sur cet exemple publié par le créateur de D3 lui-même.

L'idée était d'encourager l'exploration des données en permettant à l'utilisateur d'accéder à des communes trop petites pour être consultées depuis la vue d'ensemble.

Une des options ajoutées à ce stade a été l'affichage des sous-préfectures seulement lorsqu'un département est zoomé pour offrir des repères supplémentaires.

Une fois le squelette prêt, le plus dur restait à faire : le connecter à des données, dans l'idée de traiter en direct les résultats de ces élections régionales.

Un parser en PHP qui a fait ses preuves

Une fois le modèle de carte prêt à être montré, je l'ai envoyé à Tom Wersinger, développeur chez Rue89, pour lui demander son avis.

Tom nous avait déjà filé un précieux coup de main au moment des élections départementales, où on avait pu apprécier la puissance d'un parser en PHP codé par ses soins.

Pour le dire vite, il permet de traduire un tableur Google en json, en paramétrant (assez) simplement quelques options comme l'identifiant de la feuille Google.

Dès que la connexion est établie entre le parser et le tableur, un petit F5 permet de générer une nouvelle version du json. Un nouveau rafraîchissement sur la carte et le tour est joué. Sans douleur, donc !

Comme on passait quand même à une échelle largement supérieure à celle des départementales, je voulais m'assurer que le parser supporterait la charge.

Tom a eu la gentillesse de m'aider dans cette tâche sur son temps libre, avec en plus :

• une refactorisation du code bien profitable. Je bosse en général en bricolant des exemples piochés à droite à gauche, et je dois avouer que mes codes source sont du coup peu optimisés
• l'utilisation de la librairie underscore.js, qui a nous a permis de calculer directement les scores départementaux et régionaux à partir des résultats communaux. Cerise sur le gâteau, la lib' nous a également servi à trier les résultats dans l'ordre décroissant. On a pu grâce à ça afficher des infobulles bien triées et simplifier la coloration de nos territoires en fonction de la liste arrivée en tête

Et après plusieurs heures de codage intensif, nous sommes arrivés à une carte du second tour de la dernière présidentielle optimale, bien reliée à une feuille de calcul Google :

Cliquez sur l'image pour l'agrandir

XML et CSV

Restait plus, à ce stade, qu'à nous assurer d'avoir des données régulièrement mises à jour le jour J. Là, ça s'est un peu compliqué, car :

• chacune des dix préfectures enverrait seulement ses résultats départementaux. Impossible que Metz envoie tous les scores des communes de Lorraine, par exemple
• chaque préf' a son propre mode de fonctionnement : celles d'Alsace envoient très régulièrement des tableurs Excel mis à jour tout au long de la soirée, mais la plupart préfère envoyer les résultats définitifs assez tard. Pas l'idéal pour une soirée live !

Mais heureusement, le Ministère de l'Intérieur allait fournis à la presse des XML mis à jour tous les quarts d'heure. La principale difficulté consistait à convertir ce format composé de balises en tableur prêt à être copié/collé dans Google Drive.

Je dois reconnaître que ce n'est pas franchement mon domaine, contrairement au camarade Ettore Rizza. Ettore a écrit un script directement taillé pour les XML de l'ACAL.

Une fois digéré par Open Refine, on obtenait grâce à ce script des données bien propres et prêtes à être téléchargées au format CSV.

Plus qu'à mettre en oeuvre tout ça le grand soir venu 🙂

Les limites de l'exercice

Dans l'ensemble, tout s'est passé sans encombre, mais il faut quand même signaler quelques embûches et aspects perfectibles, notamment :

• les XML de tests contenaient l'ensemble des communes de chaque département, alors que lors de la soirée ils ne contenaient que les communes dont les résultats étaient complets. Ça paraît être un détail, mais ça a été bien emmerdant sur le coup parce qu'on ne pouvait pas faire un banal copié/collé de nos données sans risquer de décaler toutes les communes et de fausser complètement la carte finale. Still (1 800 habitants) se retrouvant avec les résultats de Strasbourg (275 000 habitants), ça le fait moyen quand même ! Heureusement, l'ami Joël Matriche, ceinture noire en manipulation d'Exel, m'a filé une petite formule magique pour repérer facilement les villes manquantes lors du second tour !
• les XML du tour 2 contenaient les résultats du tour 1, cas que nous avions pas anticipé. Les CSV générés avaient du coup le double des lignes (une pour le tour 1, une pour le tour 2), mais un simple tri permettait de séparer très vite les résultats de chaque tour
• techniquement, la carte du premier tour mettait beaucoup (beaucoup) de temps à se charger, sur fixe comme sur mobile. Le problème venait évidemment de la taille de la matrice générée (environ 5 200 lignes fois une vingtaine de colonnes), et je n'ai pas trouvé de méthode pour vraiment pallier à ce souci. Ça ne veut évidemment pas dire qu'il n'y a pas de solution envisageable. Du coup, si une belle âme a une suggestion, qu'elle n'hésite pas à la faire dans les commentaires 🙂
• certains bêta-testeurs ont suggéré un champ de recherche pour directement afficher sa commune et les résultats qui vont avec. L'idée était très bonne, mais la mise en œuvre technique me paraissait un poil coton, sans compter le fait que ce champ aurait dû être seulement actif pendant l'affichage des communes. Il aurait fallu presque tout recommencer à zéro, et on n'avait franchement plus le temps pour ça. Ceci dit, je pense que la possibilité d'explorer les communes département par département compensait assez bien l'absence de champ de recherche

Le bilan

Ce travail de longue haleine a payé avec des audiences plutôt bonnes pour ce genre d'événements sur Rue89 S : 18 000 vues pour le premier tour, et à peu près la moitié pour le second.

Nous avons également réussir à corriger le tir pour les faiblesses repérées lors du premier tour (notamment les villes manquantes) pour pouvoir optimiser le traitement live.

J'ai également codé une nouvelle version de la carte pour le second tour, en intégrant un dégradé selon le pourcentage du vainqueur. Concrètement, cela nous a permis de passer de ça :

Cliquez sur l'image pour accéder à la page du premier tour

A ça :

Cliquez sur l'image pour accéder à la page du second tour

Petite fierté strictement perso : notre carte du premier tour s'est retrouvé dans le Top 10 hebdomadaire du Global Investigative Journalism Network. Pour la petite histoire, c'est la seconde fois de l'année 🙂 !

Le template codé avec Tom va maintenant nous permettre d'étudier en profondeur l'ACAL, territoire plein de disparités comme en témoignent ces "cartes de force" du PS, du FN et des Républicains :

Bref, ça promet pour 2016 !

J'en profite pour remercier une nouvelle fois les excellents Tom, Ettore et Joël pour leur précieuse aide !

PS : le code source de la carte du premier tour sera bientôt publié.

Comments

Comment by Tom Courant on 2016-01-07 12:42:22 +0100

Tout d'abord bravo pour cette carte, c'est un des module de résultats les plus intéressant et aboutis que j'ai put voir pour ces élections. Et je suis conscient des taches a mettre en oeuvre pour ce type de carte ayant travailler sur ce type de projet pour plusieurs élections.

Voici mes quelques suggestions si elles peuvent être utile :

• la page sur rue 89 prend beaucoup de temps a charger, alors que la carte seul est beaucoup plus rapide, peut être éviter de publier votre carte sur une page qui contient déja un fil d'actualité avec beaucoup de ressources (vidéos, images...)
• l'utilisation de topojson au lieu de geojson permet un gain de poids considérable (je pense a votre fichier communes_acal.json) et est parfaitement adapté aux cartes avec d3, car developper par le créateur de d3. https://github.com/mbostock/topojson.
• pour éviter de multiplier les scrips et les outils (Open Refine, Google doc) pourquoi ne pas convertir les xml du ministère directement en json.
• Avez vous eu en votre possession le guide technique pour le téléchargement des fichiers xml publier par le ministère? Le ministère les distribue pendent les réunion technique avant chaque élections ou les envoie en pdf. Très utile, il décrivais notamment que seule les communes dont les résultats étaient complets serais publier (contrairement au jeux de tests) et que les résultats du tours 2 contenaient un rappel des résultats du tour 1.

Beau travail en tout cas!

Comment by Raphi on 2016-01-07 12:56:17 +0100

Un grand merci pour ces suggestions et remarques Tom 😉 !