Pourquoi les formats de données ouvertes déterminent tout
Un jeu de données publié en PDF vaut peu, même si son contenu est excellent. Le format conditionne directement la réutilisabilité : un fichier exploitable par une machine sans intervention humaine a une valeur économique et analytique sans commune mesure avec un document conçu pour l'impression.
L'initiative Open Data repose sur un principe simple : publier ne suffit pas, encore faut-il publier correctement. Tim Berners-Lee a formalisé cette logique dès 2010 avec son système à cinq étoiles, où chaque niveau correspond à un degré de maturité technique croissant. Les formats standardisés sont les briques de cet édifice.
CSV : le format universel
Structure et avantages
Le CSV (Comma-Separated Values) reste le format le plus répandu dans les catalogues open data mondiaux. Sa structure est d'une simplicité radicale : chaque ligne représente un enregistrement, chaque colonne un champ, séparés par une virgule ou un point-virgule selon les conventions locales.
Ce format atteint deux étoiles dans la classification Berners-Lee, ce qui signifie des données structurées lisibles par machine, sans liens vers d'autres sources. Il s'ouvre nativement dans Excel et LibreOffice, s'importe directement dans Python avec pandas, dans R, ou dans pratiquement tout outil d'analyse de données.
Limites à connaître
Le CSV souffre d'un problème récurrent : l'absence de typage natif. Rien n'indique formellement si une colonne contient une date, un entier ou une chaîne de caractères. Les problèmes d'encodage (UTF-8 vs Latin-1) causent encore régulièrement des corruptions sur les caractères accentués.
Pour les données tabulaires simples, populations municipales, statistiques budgétaires, relevés météorologiques, le CSV reste pourtant le choix le plus accessible.
JSON : la lingua franca des APIs modernes
Un format né du web
Le JSON (JavaScript Object Notation) s'est imposé comme le standard des échanges de données en temps réel. Sa syntaxe à base de paires clé-valeur, de tableaux et d'objets imbriqués permet de représenter des structures hiérarchiques complexes qu'un CSV ne peut pas capturer.
Un fichier JSON reste lisible par un humain avec un minimum d'effort, tout en étant parsé nativement par JavaScript et pris en charge par tous les langages de programmation modernes. Les APIs gouvernementales, data.gouv.fr et api.data.gouv.fr notamment, renvoient leurs réponses en JSON.
JSON-LD : vers la donnée liée
Une extension utile pour l'open data est le JSON-LD (JSON for Linking Data). En ajoutant un contexte sémantique via la clé @context, il ancre chaque propriété dans une ontologie standardisée comme Schema.org.
Il contextualise sémantiquement les données sans rompre la compatibilité avec l'écosystème JSON existant. C'est un format pivot entre le web classique et le web des données.
RDF et ses sérialisations : le sommet du web sémantique
Le modèle en triplets
Le RDF (Resource Description Framework) marque une rupture conceptuelle par rapport aux formats tabulaires ou hiérarchiques. Chaque information s'exprime sous forme de triplets : sujet, prédicat, objet. Par exemple :
Ce modèle tisse des liens entre datasets distincts, permet d'interroger des graphes de connaissances via SPARQL, et atteint les cinq étoiles dans la classification Berners-Lee. Wikidata, DBpedia et le portail européen data.europa.eu utilisent RDF activement.
Turtle, N-Triples, RDF/XML
RDF se décline en plusieurs syntaxes concrètes. Turtle offre la meilleure lisibilité humaine avec une notation compacte. N-Triples privilégie la simplicité pour le traitement en flux ligne par ligne. RDF/XML garantit l'interopérabilité avec les outils XML existants.
Le choix entre ces sérialisations dépend du contexte : traitement en streaming, édition manuelle ou intégration dans une chaîne XML. Dans tous les cas, le modèle sous-jacent reste identique.
OWL et les ontologies
Au-dessus de RDF se trouve OWL (Web Ontology Language), qui permet de définir des classes, des propriétés et des règles d'inférence. Des raisonneurs automatiques peuvent alors déduire des informations non explicitement saisies à partir de données gouvernementales modélisées en OWL.
GeoJSON : la référence pour les données spatiales
Géographie et interopérabilité
Le GeoJSON étend le JSON avec des types géométriques standardisés : Point, LineString, Polygon, MultiPolygon. Défini par la RFC 7946, il a supplanté des formats plus anciens comme le Shapefile pour les données géographiques ouvertes sur le web.
Chaque entité géographique (Feature) combine une géométrie et des propriétés arbitraires, ce qui permet d'associer des attributs thématiques à des contours de communes, des tracés de réseaux de transport ou des points d'intérêt. Les coordonnées s'expriment en WGS84 par défaut.
Intégration native dans les outils modernes
Leaflet, Mapbox GL, OpenLayers et QGIS lisent le GeoJSON nativement. GitHub affiche automatiquement les fichiers GeoJSON sur une carte interactive. Cette adoption quasi-universelle dans l'écosystème de cartographie web en fait le format à privilégier pour toute publication de données géolocalisées.
Pour les jeux de données très volumineux, millions de polygones complexes, des alternatives comme GeoParquet ou FlatGeobuf offrent de meilleures performances tout en conservant une interopérabilité croissante.
Autres formats structurants de l'écosystème open data
XML : puissant mais verbeux
Le XML (eXtensible Markup Language) reste présent dans de nombreux systèmes patrimoniaux, notamment dans les échanges administratifs (OpenDocument, TEI pour les textes culturels). Sa validation par schéma (XSD) garantit une intégrité structurelle forte.
Son principal défaut est la verbosité : un fichier XML peut peser trois à cinq fois plus qu'un CSV ou JSON équivalent. Il reste pertinent pour les données documentaires complexes ou les échanges B2G (Business to Government) réglementés.
Parquet et formats colonaires
Apache Parquet représente une évolution notable pour les gros volumes. Ce format colonaire compresse efficacement les données répétitives et permet d'interroger uniquement les colonnes nécessaires, sans lire l'intégralité du fichier.
Des plateformes comme data.gouv.fr expérimentent Parquet pour les jeux de données dépassant plusieurs gigaoctets. Un fichier de recensement de 2 Go en CSV peut descendre à 400 Mo en Parquet, avec des temps de requête dix à cinquante fois plus rapides selon les cas d'usage.
DCAT : cataloguer les catalogues
Le DCAT (Data Catalog Vocabulary) est un vocabulaire RDF standardisé par le W3C pour décrire des catalogues de données. Il ne définit pas un format de données mais une structure de métadonnées.
DCAT-AP, son profil européen, est obligatoire pour les portails officiels des États membres de l'UE souhaitant alimenter data.europa.eu. Il uniformise les métadonnées (titre, description, fréquence de mise à jour, licence) pour permettre la moisson automatique entre catalogues.
Choisir le bon format : une grille de décision
En fonction de la nature des données
| Type de données | Format recommandé | |---|---| | Tableau simple | CSV | | Données géographiques | GeoJSON | | API temps réel | JSON / JSON-LD | | Données liées | RDF (Turtle ou JSON-LD) | | Gros volumes | Parquet / CSV.gz | | Données documentaires | XML / TEI |
Les critères déterminants
Trois questions orientent le choix : qui sont les utilisateurs finaux ? Quels outils vont consommer ces données ? Quelle volumétrie est anticipée ?
Un jeu de données destiné à des journalistes ou des citoyens gagne à être publié en CSV ou JSON. Un dataset ciblant des chercheurs en sciences sociales peut justifier RDF. Une infrastructure de données massives pour des ingénieurs data orientera vers Parquet.
La licence ouverte (ODbL, Licence Ouverte 2.0, CC BY) complète le format : sans l'une, l'autre ne suffit pas pour constituer une donnée vraiment réutilisable.
Ce qui se profile dans les standards
Le mouvement Linked Data continue de progresser, notamment avec l'essor de SPARQL 1.2 et des triplestore cloud-natifs. Les formats de tuiles vectorielles comme PMTiles changent la distribution de données cartographiques sans serveur.
L'interopérabilité reste le défi central. Des initiatives comme Frictionless Data (descripteurs de paquetage de données) ou les Data Spaces européens cherchent à standardiser non seulement les formats, mais aussi les protocoles d'échange et les contrats de données.
Les formats ne sont jamais neutres : ils cristallisent des choix architecturaux, des compromis entre performance et accessibilité, entre ouverture immédiate et richesse sémantique. Maîtriser cette grammaire technique est la condition préalable à toute stratégie open data qui fonctionne.
