Pourquoi la qualité des données ouvertes conditionne leur réutilisation
Publier des données ouvertes ne suffit pas. Un jeu de données mal structuré, sans contexte ni documentation, restera lettre morte : les développeurs l'ignoreront, les chercheurs le contourneront, les journalistes n'y toucheront pas.
Selon l'Open Data Barometer, moins de 30 % des datasets publiés par des organisations publiques atteignent un niveau de réutilisation significatif. La cause principale : une qualité insuffisante, pas un manque de demande.
Le schéma est systématique. Les producteurs de données pensent avoir accompli leur mission en rendant un fichier accessible. Les utilisateurs, eux, attendent autre chose : cohérence, fiabilité, lisibilité immédiate.
Les fondamentaux d'un jeu de données exploitable
Choisir le bon format dès le départ
Le format de publication détermine directement l'accessibilité technique du dataset. Les fichiers PDF sont à proscrire pour des données tabulaires : ils cassent toute chaîne de traitement automatisé.
Les formats recommandés suivent une hiérarchie claire. Le CSV reste le standard universel pour les données tabulaires, lisible par n'importe quel outil, de Python à Excel. Le JSON et le GeoJSON couvrent les données structurées et géographiques. Le Parquet gagne du terrain pour les gros volumes dépassant plusieurs gigaoctets.
Tim Berners-Lee a formalisé cette logique dans son système des 5 étoiles de l'open data. Chaque étoile supplémentaire représente un niveau d'ouverture : données sur le web, format ouvert, format non-propriétaire, URI pour identifier les ressources, liens vers d'autres données.
Normaliser la structure interne des données
Un fichier CSV bien formaté respecte des règles simples mais souvent négligées. Une ligne d'en-tête claire, des noms de colonnes sans espaces ni caractères spéciaux, un encodage UTF-8 systématique.
Les types de données doivent être cohérents colonne par colonne. Une colonne de dates ne doit contenir que des dates, dans un format ISO 8601 standardisé (YYYY-MM-DD). Mélanger « 01/01/2024 », « 1er janvier 2024 » et « 2024-01-01 » dans la même colonne rend tout traitement automatique impossible.
Les valeurs nulles méritent une attention particulière. Définissez une convention explicite : vide, « NA », « NULL » ou « 0 » ne signifient pas la même chose. Cette convention doit apparaître dans la documentation.
Gérer les valeurs aberrantes et les doublons
Un dataset propre suppose un processus de nettoyage documenté. Les doublons identiques sont à supprimer ; les doublons suspects (mêmes champs principaux, dates différentes) doivent être signalés dans la documentation.
Les valeurs aberrantes ne doivent pas être effacées silencieusement. Si un relevé de température affiche 999°C dans votre dataset climatique, notez-le plutôt que de le supprimer sans explication. La transparence sur les anomalies renforce la confiance des utilisateurs.
Documenter ses données : le travail invisible qui fait tout
Rédiger un fichier README efficace
La documentation est l'élément le plus sous-estimé de tout projet open data. Un README bien construit réduit drastiquement le temps qu'un réutilisateur doit consacrer à comprendre et exploiter un dataset.
Ce fichier doit répondre à six questions : qui a produit les données, quand, comment, pourquoi, pour couvrir quelle période et avec quelle méthodologie de collecte. Chaque réponse manquante freine la réutilisation.
Incluez systématiquement un exemple de requête ou de code minimal. Montrer comment charger le fichier en Python avec pandas, ou comment l'importer dans QGIS pour des données géographiques, réduit la friction d'entrée à presque zéro.
Construire un dictionnaire de données structuré
Le dictionnaire de données est le document de référence pour comprendre chaque champ. On le présente généralement sous forme de tableau : nom de la colonne, type de donnée, description, valeurs possibles, unité de mesure, taux de remplissage.
Un taux de remplissage par colonne est particulièrement utile. Savoir qu'un champ est renseigné à 60 % permet à l'utilisateur d'anticiper les biais potentiels de son analyse avant même de charger le fichier.
Les abréviations et codes internes doivent être décodés. Une colonne « type_EQ » avec des valeurs « A », « B », « C » est inutilisable sans la table de correspondance. Ne présumez jamais que l'utilisateur partage votre contexte organisationnel.
Versionner et tracer les modifications
Les données changent. Une variable est ajoutée, une méthodologie est révisée, une erreur est corrigée. Sans versionning, ces modifications rendent les analyses antérieures non reproductibles.
Adoptez un système de versioning sémantique simple : v1.0.0 pour la première publication, v1.1.0 pour l'ajout d'un champ, v2.0.0 pour un changement de schéma incompatible. Chaque version doit rester accessible, pas seulement la plus récente.
Un changelog daté, listant précisément chaque modification, est le minimum. Les producteurs sérieux y ajoutent l'impact attendu sur les réutilisations existantes.
Accessibilité : rendre les données trouvables et utilisables
Choisir la bonne licence ouverte
La licence est le contrat légal qui définit ce qu'un réutilisateur peut faire avec vos données. Une donnée sans licence explicite n'est techniquement pas une donnée ouverte, même si elle est publiquement accessible.
Les licences les plus utilisées dans l'écosystème open data francophone sont la Licence Ouverte / Open Government Licence (Etalab) et les Creative Commons CC0 et CC-BY. La CC0 maximise la réutilisation en supprimant toute obligation ; la CC-BY exige simplement la citation de la source.
Évitez les licences non commerciales (NC) si votre objectif est une réutilisation large. Elles bloquent de nombreux cas d'usage légitimes, notamment les startups et les PME qui exploitent des données ouvertes dans leurs produits.
Publier sur des plateformes indexées et interopérables
Un dataset hébergé sur un serveur obscur sans métadonnées ne sera jamais trouvé. Les plateformes spécialisées comme data.gouv.fr, OpenDataSoft ou les portails CKAN offrent une indexation automatique et une exposition aux moteurs de recherche thématiques.
Les métadonnées de découverte doivent suivre des standards reconnus. Le Dublin Core et le schema.org permettent aux moteurs de recherche et aux agrégateurs d'indexer correctement vos jeux de données. Google Dataset Search, par exemple, s'appuie entièrement sur ces balises structurées.
Un identifiant persistant (DOI ou URI pérenne) garantit que les citations dans des publications académiques ou journalistiques restent valides dans le temps. Les URL qui changent cassent la chaîne de référencement. Simple, mais rarement respecté.
Proposer plusieurs niveaux d'accès technique
Les profils des réutilisateurs sont hétérogènes : chercheur en sciences sociales, développeur d'application, journaliste data, décideur public. Un seul mode d'accès ne peut pas convenir à tous.
L'idéal est d'offrir simultanément un téléchargement direct en masse (bulk download), une API REST pour les accès dynamiques et une interface de prévisualisation en ligne pour les utilisateurs non techniques. Ces trois couches couvrent 95 % des cas d'usage réels.
La mise à disposition d'un endpoint SPARQL pour les données liées, ou d'un accès OGC WFS pour les données géographiques, s'adresse à des communautés plus spécialisées mais très actives dans la réutilisation de données complexes.
Maintenir et améliorer dans la durée
Mettre en place un processus de mise à jour
Des données obsolètes nuisent autant que des données absentes. Précisez clairement la fréquence de mise à jour dans les métadonnées : quotidienne, mensuelle, annuelle, ou « archive » pour un dataset figé.
Automatisez les pipelines de publication quand c'est possible. Un script qui génère et publie automatiquement le fichier mensuel est plus fiable qu'un processus manuel dépendant d'une personne. Des outils comme Apache Airflow ou les GitHub Actions permettent d'industrialiser ce type de workflow à coût réduit.
Collecter les retours des réutilisateurs
Les utilisateurs de données ouvertes signalent régulièrement des erreurs, des incohérences ou des besoins non couverts. Un canal de feedback simple (formulaire, dépôt GitHub, adresse email dédiée) transforme ces signaux en améliorations concrètes.
Certains producteurs vont plus loin en maintenant un registre public des réutilisations connues. Cette visibilité valorise l'effort de publication et motive les équipes internes à maintenir la qualité.
Un producteur réactif aux signalements construit une réputation de fiabilité qui attire davantage de réutilisateurs. Les datasets sérieux attirent les projets sérieux : c'est mécanique.
