Pourquoi la visualisation des données ouvertes est une discipline à part entière
Les données ouvertes brutes ne valent rien sans interprétation. Un fichier CSV de 200 000 lignes publié par une collectivité territoriale ne devient utile que traduit en représentation visuelle lisible. Cette transformation mobilise des compétences techniques, sémantiques et éditoriales bien distinctes.
La montée en puissance des portails open data (data.gouv.fr recense plus de 50 000 jeux de données actifs) a créé une demande croissante pour des outils capables de traiter des volumes hétérogènes. Reste à choisir le bon outil selon le contexte : analyse exploratoire, publication éditoriale ou dashboard interactif n'obéissent pas aux mêmes contraintes.
Les grandes familles d'outils de visualisation
Outils no-code pour explorateurs débutants
Plusieurs plateformes permettent de charger un fichier et d'obtenir une visualisation sans écrire une seule ligne de code.
Datawrapper est aujourd'hui la référence pour les rédactions data européennes. Il prend en charge les formats CSV, JSON et XLS, propose une trentaine de types de graphiques et génère des embeds responsives prêts à l'emploi. Son plan gratuit couvre la majorité des usages éditoriaux.
Flourish (racheté par Canva en 2022) se distingue par ses templates animés et ses visualisations de type « race bar chart » ou cartographie choroplèthe. Il convient particulièrement aux jeux de données temporels issus de sources comme Eurostat ou l'INSEE.
OpenRefine, bien que centré sur le nettoyage de données, intègre des fonctions d'aperçu visuel utiles pour repérer les anomalies avant toute publication.
Bibliothèques JavaScript pour développeurs
À l'échelon programmatique, trois bibliothèques dominent le marché francophone et international.
D3.js reste la référence pour la visualisation sur mesure. Créée par Mike Bostock (ex-New York Times), elle offre un contrôle au pixel près sur chaque élément SVG. Sa courbe d'apprentissage est élevée, mais elle permet de représenter n'importe quelle structure de données, des graphes de réseau aux cartogrammes.
Chart.js adopte une philosophie opposée : simplicité, documentation exemplaire. Huit types de graphiques natifs, une API déclarative et un poids léger (60 Ko en production) en font le choix par défaut pour les dashboards internes ou les portails open data municipaux.
Vega-Lite, issu de l'Université de Washington, propose une grammaire déclarative en JSON. Un graphique complexe s'écrit en vingt lignes là où D3.js en nécessiterait cent cinquante. Il s'intègre nativement dans Observable et dans les notebooks Jupyter via Altair, son équivalent Python.
Outils Python pour l'analyse exploratoire
L'écosystème Python s'est imposé comme le terrain naturel de l'analyse de données ouvertes, notamment dans les administrations et la recherche.
Matplotlib reste le socle historique, mais sa syntaxe verbeuse pousse souvent vers Seaborn pour les statistiques descriptives et Plotly Express pour l'interactivité. Plotly génère des visualisations HTML autonomes partageables sans serveur, ce qui simplifie la diffusion de résultats issus de jeux de données publics.
Pandas couplé à .plot() permet de passer de l'ingestion CSV à la visualisation en moins de dix lignes. Idéal pour les prototypes rapides sur des données de data.gouv.fr ou de l'Open Data de Paris.
Cartographie et données géospatiales ouvertes
Des formats standardisés à maîtriser
Les données ouvertes à dimension géographique forment une catégorie à part. Les formats courants (GeoJSON, Shapefile, GeoPackage) nécessitent des outils dédiés.
Leaflet.js est la bibliothèque JavaScript de cartographie interactive la plus répandue. Légère (42 Ko), extensible via plugins, elle s'interface directement avec les tuiles OpenStreetMap, elles-mêmes issues de l'open data géographique. De nombreux portails institutionnels l'utilisent pour cartographier des données de mobilité, de santé ou d'urbanisme.
Kepler.gl (développé par Uber) monte en puissance pour les jeux de données géospatiaux massifs. Sa capacité à afficher des millions de points en WebGL le rend pertinent pour les données de trajectoires ou les flux urbains.
QGIS, côté desktop, reste la référence pour la cartographie analytique avancée. Son plugin QuickOSM permet d'importer directement des données OpenStreetMap en quelques clics.
Bonnes pratiques pour les cartes de données ouvertes
Trois règles structurent une carte de données ouvertes efficace. D'abord, sourcer explicitement : indiquer le millésime, le producteur et la licence (ODbL, Licence Ouverte 2.0) dans la légende ou les métadonnées. Ensuite, choisir la projection adaptée : une carte de la France métropolitaine doit utiliser Lambert-93 (EPSG:2154), pas le Web Mercator qui déforme les superficies. Enfin, intégrer le contexte territorial, car une donnée isolée sur une carte sans fond de référence génère des erreurs d'interprétation.
Bonnes pratiques transversales
Choisir le bon type de graphique selon la donnée
L'erreur la plus fréquente en visualisation de données ouvertes consiste à imposer un type de graphique à une structure de données incompatible. Quelques règles empiriques :
- Comparaison entre catégories : barres horizontales (plus lisibles que les barres verticales quand les libellés sont longs)
- Évolution temporelle : courbes linéaires, jamais de camemberts
- Distribution statistique : histogramme ou violin plot
- Corrélation entre deux variables : nuage de points (scatter plot)
- Composition d'un tout : graphique en barres empilées plutôt que camembert dès que le nombre de catégories dépasse 4
Accessibilité et lisibilité
Une visualisation publiée sur un portail open data s'adresse à des publics hétérogènes. Pour les organismes publics français, l'accessibilité est une exigence légale fixée par le RGAA 4.1.
Concrètement : éviter les palettes rouge/vert (le daltonisme touche 8 % des hommes), utiliser des palettes testées comme ColorBrewer ou Viridis, ajouter des textures en complément des couleurs, et toujours inclure un tableau de données alternatif. Le contraste texte/fond doit respecter un ratio minimal de 4,5:1 selon les WCAG 2.1 AA.
Documentation et reproductibilité
Une visualisation de données ouvertes sans code source reproductible a une valeur limitée. Publier le script de traitement (Python, R ou SQL) aux côtés de la visualisation permet à d'autres utilisateurs de vérifier, corriger ou étendre l'analyse. Des plateformes comme Observable ou GitHub Pages facilitent cette pratique en hébergeant gratuitement des notebooks interactifs.
La traçabilité de la chaîne de traitement, depuis le fichier brut téléchargé jusqu'au graphique final, garantit aussi la crédibilité éditoriale. Chaque transformation (agrégation, filtrage, normalisation) doit être documentée.
Intégrer des APIs open data dans ses visualisations
Connecter directement les sources
Nombre de portails open data exposent des APIs REST qui permettent d'alimenter une visualisation en temps réel plutôt que de travailler sur des snapshots statiques. L'API de data.gouv.fr, celle de l'INSEE (Sirene, Filosofi) ou les APIs SNCF Open Data répondent au format JSON et s'intègrent directement dans D3.js, Chart.js ou React avec Recharts.
Cette approche garantit que les visualisations reflètent les dernières données publiées, sans intervention manuelle. Elle impose toutefois une gestion rigoureuse des erreurs : les APIs publiques peuvent être indisponibles, versionner sans préavis ou changer de schéma.
Gérer les licences dans les visualisations publiées
Tout graphique fondé sur des données ouvertes hérite des conditions de leur licence source. La Licence Ouverte / Open Licence 2.0 (Etalab) exige la mention du producteur et du millésime. La licence ODbL (Open Database License, utilisée par OpenStreetMap) impose de partager les bases modifiées sous la même licence.
Ignorer ces obligations expose à des risques juridiques réels, y compris pour des acteurs publics ou académiques. Mentionner systématiquement la source dans le titre ou le sous-titre du graphique est à la fois une bonne pratique et une obligation légale selon la licence applicable.
Construire un pipeline de visualisation durable
Un projet de visualisation de données ouvertes sérieux repose sur quatre couches : ingestion (téléchargement ou connexion API), nettoyage (OpenRefine, Pandas), transformation (agrégation, jointure) et rendu (bibliothèque de visualisation). Séparer clairement ces couches facilite la maintenance et la mise à jour quand les données sources évoluent.
Des outils comme dbt pour la transformation SQL et Airflow pour l'orchestration commencent à entrer dans les pratiques des équipes data des collectivités les plus avancées. Pour des projets plus modestes, un script Python versionné sur Git et une GitHub Action planifiée suffisent à automatiser la mise à jour quotidienne d'un dashboard.
La visualisation de données ouvertes rend la transparence publique concrète et utilisable par les citoyens, les journalistes et les décideurs.
