Publier des données ne suffit pas, la forme choisie conditionne usage, performance et coûts. Avec des arbitrages techniques ou éditoriaux mal posés, une base utile peut devenir inexploitée, voire incomprise.
CSV, JSON, XML ou Parquet ne racontent pas la même histoire aux analystes, aux développeurs et aux décideurs. Votre choix de format influence la publication de jeux de données et l’adoption de des standards ouverts, jusqu’à déterminer qui pourra réutiliser, quand, et comment. Avec le format open data et l’interopérabilité des données, vous orientez l’effort de transformation et le coût d’usage, immédiatement.
Pourquoi le choix du format open data compte pour la réutilisation
Publier un bon jeu open data ne se limite pas à déposer un fichier. La manière de structurer influence la découverte, les jointures et la transformation des tables. Pour un service public ou une collectivité, préciser l’encodage, les séparateurs et le dictionnaire de données renforce la réutilisation des données et la qualité des exports au quotidien.
Ce choix se mesure dans la durée, quand les traitements s’automatisent et que les scripts tournent sans retouche. Une documentation claire du schéma, assortie de métadonnées, améliore la lisibilité machine et sécurise la pérennité des fichiers, tout en réduisant les coûts d’intégration. À la clé: moins d’incidents, des mises à jour fiables, et des produits dérivés publiés plus vite.
Comparatif rapide : CSV, JSON, XML et Parquet
Quatre formats dominent la publication open data: CSV, JSON, XML et Parquet. Pour poser un comparatif des formats lié aux cas d’usage fréquents, gardez ces repères en tête:
- CSV — tables plates, compatibilité bureautique.
- JSON — structures imbriquées et APIs web.
- XML — validations XSD et échanges institutionnels.
- Parquet — stockage colonnaire et analytics distribués.
Chaque choix a son revers.
Le terrain révèle des écarts marqués entre outils et volumes.
Un CSV se lit partout; un Parquet se lit vite là où l’analytique se joue.
Sur disques parquetés, la performance en lecture grimpe pour l’analytique, tandis que la complexité de schéma oriente vers JSON ou XML lorsque l’on transporte des hiérarchies et des métadonnées validées. Votre pipeline dicte le format, pas l’inverse.
CSV pour les données tabulaires simples et massives
Un fichier CSV se lit partout, du tableur au pipeline ETL, ce qui en fait un format robuste pour un large public. Pour lever toute ambiguïté lors de l’import, mentionnez clairement l’encodage utf-8 dans la fiche du jeu et dans la notice technique, et faites figurer le séparateur de colonnes choisi dans l’exemple d’ouverture.
La cohérence des types et des contraintes gagne à être décrite avec un table schema publié à côté du jeu de données, permettant des validations automatiques et des conversions fiables. Pour des volumes très lourds, proposez aussi un fichier compressé gzip en parallèle de la version brute, en indiquant la taille avant et après compression, afin d’aider les réutilisateurs à estimer le temps de téléchargement et la charge réseau.
JSON pour l’API et l’interopérabilité web
Les applications clientes attendent des réponses prédictibles et bien documentées, servies avec des codes HTTP explicites. Précisez le format d’échange web (Content-Type, versioning) et offrez des exemples concrets, tout en gardant une structure stable qui supporte l’évolution. Pour les données imbriquées, décrivez des structures hiérarchiques compréhensibles par les consommateurs.
Un guide d’implémentation réduit les erreurs côté intégrateurs lorsqu’il présente des modèles de sérialisation json complets, avec types, nullabilité et valeurs par défaut. Pour limiter la charge serveur et faciliter la navigation, documentez les mécanismes de pagination api (limit, offset ou curseurs) et fournissez des liens HATEOAS next/prev, afin d’encourager des requêtes efficaces et prévisibles pour tous les clients.
XML quand la structure et les métadonnées priment
XML s’adresse aux jeux de données où la hiérarchie doit être lisible et stable, par exemple pour des référentiels publics ou des échanges interservices. Vous décrivez des éléments, des attributs et des cardinalités, puis vous publiez un guide de production pour les producteurs et les réutilisateurs. Dans cette approche, un schéma XSD formalise les contraintes, et l’usage d’espaces de noms distingue proprement plusieurs vocabulaires.
Avant diffusion sur un portail, validez automatiquement chaque fichier contre le modèle prévu et remontez des erreurs précises sur les champs et les occurrences. Cette validation structurée évite des surprises côté consommateurs. XML facilite aussi la documentation détaillée : annotations, liens et identifiants permettent d’associer des métadonnées riches sur la licence, l’horodatage, les unités et la provenance.
Parquet pour les gros volumes et l’analytique
Parquet convient aux lacs de données et aux pipelines analytiques qui lisent des colonnes ciblées à grande échelle. Les requêtes bénéficient d’une lecture sélective, d’un cache efficace et d’une bonne locality sur stockage objet. Grâce au stockage colonnaire vous limitez les E/S et optimisez les agrégations massives, y compris avec des partitions temporelles ou thématiques.
| Propriété | Valeur |
|---|---|
| Année d’introduction | 2013 |
| Extension de fichier | .parquet |
| Mode de stockage | Columnar |
| Magic bytes | PAR1 |
| Longueur des magic bytes | 4 |
| Taille par défaut d’un row group | 128 Mo |
| Taille par défaut d’une page | 1 Mo |
| Codecs usuels | Snappy, GZIP, ZSTD, Brotli |
| Predicate pushdown | Oui |
| Types imbriqués | Oui |
Sur cluster ou cloud, le traitement distribué profite du découpage en row groups et pages. La compatibilité Spark assure une intégration directe avec DataFrame/Dataset, et une compression efficace (Snappy, GZIP, ZSTD) réduit les coûts tout en accélérant les transferts réseau. Des administrations et instituts statistiques publient déjà des microdonnées en Parquet pour accélérer les analyses publiques.
Formats géographiques : GeoJSON, KML, GPX en pratique
GeoJSON, KML et GPX couvrent des usages distincts pour la cartographie ouverte. Quelques repères pour choisir :
- GeoJSON pour l’affichage web, l’édition rapide et l’API JavaScript
- KML/KMZ pour Google Earth et l’annotation partageable
- GPX pour traces, itinéraires et points GPS issus du terrain
- GeoPackage ou Shapefile si vous passez en SIG avancé
Dans tous les cas, vérifiez la cohérence des coordonnées WGS84 et la validité des géométries polygonales afin d’éviter des erreurs d’affichage et des surfaces incohérentes au téléchargement.
Pour publier en open data, préparez des fichiers compacts, documentés et testés dans un visualiseur. Pensez à harmoniser la projection spatiale avec votre fond de carte, puis exposez des champs clairs pour les attributs géographiques tels que le nom, le code, l’aire ou la longueur. Un échantillon de contrôle réduit les surprises, qu’il s’agisse de tuiles web, d’un SIG de bureau ou d’une application mobile utilisée sur le terrain.
SDMX pour les séries statistiques normalisées
SDMX décrit un modèle commun pour exposer des séries temporelles et leurs métadonnées via fichiers et APIs. Les instituts nationaux et organisations internationales l’utilisent pour publier des indicateurs cohérents. Les identifiants des observations combinent des clés de dimensions (par exemple pays, indicateur, fréquence), ce qui facilite la requête paramétrée et la comparaison entre sources.
Côté pratique, un point d’accès SDMX propose des dataflows, des codelists et des structures de jeu. Les producteurs regroupent les observations en jeux de séries, décrits par un dictionnaire de concepts partageant définitions et unités, afin d’assurer une diffusion statistique claire vers tableaux, graphiques et exports. Vous obtenez ainsi des mises à jour automatisées, des agrégations traçables et une interopérabilité stable entre plateformes analytiques.
Quel format pour partager en open data xlsx ou ods ?
XLSX et ODS rassurent les équipes métiers grâce aux feuilles, formules et filtres, mais ces artefacts gênent l’ingestion automatique. Pour un jeu réutilisable, publiez un export tabulaire propre et traçable, puis joignez le classeur en annexe. Cette combinaison clarifie le format de fichier opendata attendu et évite les surprises lors des imports. Elle préserve aussi la lisibilité locale tout en assurant la compatibilité bureautique sur les postes des utilisateurs.
Astuce : fournissez CSV UTF-8 + schéma, puis ODS/XLSX pour la consultation et les filtres.
Une publication solide indique la feuille source, décrit les colonnes et précise les conversions. Pour minimiser les erreurs, veillez à un export vers CSV sans cellules fusionnées ni lignes d’en-tête multiples. Vous conservez ainsi l’accessibilité dans les tableurs pour la lecture manuelle, tout en offrant un format plat fiable pour les pipelines et les scripts d’analyse à grande échelle.
Métadonnées et schémas : JSON Schema, Table Schema, XSD
Les schémas jouent le rôle de contrat entre producteurs et réutilisateurs. JSON Schema décrit des structures hiérarchiques, Table Schema formalise des colonnes de CSV, XSD borne le contenu XML. On y déclare la validation de champs (présence, formats, motifs) et des contraintes de types explicites, utiles pour bloquer les dates ambiguës, les codes manquants ou des entiers interprétés comme du texte par un tableur.
Pour accélérer l’adoption, accompagnez vos fichiers d’un dictionnaire de données clair avec définitions, unités et valeurs autorisées. Documentez l’URI du schéma, sa version et son cycle de vie dans une documentation technique courte, avec liens vers des validateurs publics. Résultat tangible : contrôles reproductibles, erreurs détectées tôt, et intégration plus fluide côté ETL et clients d’API.
Référentiels et conformité : RGI, schema.data.gouv.fr et Validata
Le Référentiel général d’interopérabilité oriente vers des formats ouverts et des protocoles éprouvés pour des échanges durables. Les modèles publiés sur schema.data.gouv.fr réduisent l’ambiguïté et accélèrent la production de jeux de données réutilisables. Dans ce cadre, la conformité au RGI se vérifie plus facilement, et l’usage de schémas nationaux harmonise les colonnes, les types et les identifiants.
Validez avant de publier : une erreur détectée en amont coûte 10× moins cher qu’une correction après diffusion.
Validata compare vos fichiers aux schémas officiels et produit des rapports lisibles par humains et machines. Après corrections successives, l’outil atteste d’un contrôle de qualité satisfaisant, ce qui facilite une publication standardisée sur data.gouv.fr et limite les écarts de structure entre territoires ou services, tout en assurant une traçabilité claire des vérifications effectuées.
APIs REST et format partage opendata côté serveur
Une API open data stable repose sur des ressources versionnées, des réponses cacheables et une documentation vivante. Pour guider l’intégration, décrivez la structure des routes, les paramètres, les erreurs et les exemples d’appels. La seconde couche porte sur la découvrabilité : indiquez précisément vos endpoints http et le format de partage opendata disponible par ressource, avec les en-têtes et statuts attendus.
La robustesse côté serveur passe par des contrats clairs, des limites de débit et une compression adaptée. Pour les clients, gérez la négociation de contenu via Accept et proposez une authentification api proportionnée aux risques, tout en gardant un accès public aux jeux ouverts.
- Pagination, tri et filtrage cohérents sur toutes les collections.
- Codes d’erreur normalisés et messages actionnables.
- Versionnement explicite (v1, v2) et calendrier de dépréciation.
- Caching côté serveur et ETag pour des réponses conditionnelles.
Compression des fichiers : gzip, zip et impacts sur les CSV
Pour des fichiers CSV publiés en open data, compresser le flux réduit la bande passante et facilite les téléchargements. Sur les colonnes textuelles redondantes, le taux de compression atteint des niveaux élevés avec gzip. Ce choix améliore aussi le temps de transfert pour les usagers sur réseaux contraints. Indiquez .csv.gz, Content-Type text/csv et l’en-tête HTTP Content-Encoding: gzip pour éviter des lectures incorrectes par certains clients.
Le format .gz se prête bien au streaming, tandis que .zip sert à l’archivage multi-fichiers et à la diffusion de lots. Côté API, la décompression serveur via Content-Encoding: gzip permet de délivrer des réponses compactes sans changer les URLs. Ajoutez un hash SHA-256 et publiez la taille non compressée afin de faciliter la vérification et la planification du stockage après extraction.
Qualité des données : validations, encodage et séparateurs
Un jeu open data fiable se prépare par des contrôles systématiques sur les types, les clés et les contraintes. Intégrez l’analyse des valeurs manquantes pour distinguer absence d’information et zéro. Un contrôle de cohérence détecte des anomalies comme des dates inversées, des codes pays hors norme ou des unités mélangées. Publiez un rapport reproductible afin que les réutilisateurs vérifient les corrections au fil des versions.
Astuce pratique : testez l’import du CSV dans deux outils différents avant publication.
Le format doit être explicite sur l’encodage, les séparateurs et l’échappement. Adoptez une normalisation d’encodage en UTF-8 sans BOM et indiquez l’ordre des colonnes. Pour les nombres, fixez un séparateur décimal cohérent avec le public visé, puis précisez le délimiteur de champs, le caractère de guillemet, et le saut de ligne, en plus d’un dictionnaire de données clair.
Choisir en fonction des usages : lecture humaine, machine, et pérennité
Selon l’usage visé, vous ne publierez pas le même fichier. Un tableau consultable par un agent ou un citoyen requiert une structure lisible, des libellés clairs et un export stable. Pour la consultation sans réseau, pensez à la lecture hors ligne avec des CSV encodés en UTF‑8. Pour les intégrations web, choisissez un format de partage opendata documenté et versionné.
Pour les machines, privilégiez des structures normalisées, des clés stables et des schémas publics. Cette discipline facilite l’automatisation des traitements dans vos pipelines et réduit les régressions lors des mises à jour. Anticipez la migration future en publiant des identifiants pérennes, des mappings de colonnes et des exemples de conversions entre CSV, JSON et Parquet, avec scripts reproductibles.
FAQ à propos des formats open data
Pour des tableaux, le format open data par défaut reste le CSV: léger, lisible par les tableurs et les langages. JSON convient aux échanges via API et aux structures hiérarchiques. XML s’applique quand des métadonnées riches et des schémas XSD sont requis. Parquet cible les gros volumes et l’analyse en colonnes. Orientez le choix selon usages, taille, fréquence de mise à jour et public visé, et publiez idéalement un couple CSV + JSON pour couvrir plus de réutilisations.
Un format fichier opendata CSV représente des lignes et colonnes plates, sans imbrication; il se lit avec Excel, LibreOffice, pandas et SQL. JSON transporte des objets et listes imbriquées, pratique pour le web et les APIs. CSV est plus compact et rapide à charger en masse; JSON décrit mieux des structures variées. Pensez à l’encodage UTF-8, au séparateur clair (virgule ou point-virgule), et à publier un Table Schema pour documenter types et contraintes.
Un format partage opendata compressé (.gz, .zip) réduit les temps de téléchargement pour les gros fichiers CSV, JSON ou Parquet. Indiquez l’extension dans l’URL et, si possible, les en-têtes HTTP Content-Type et Content-Encoding. Conservez une version non compressée quand le public cible utilise surtout des tableurs. Évitez les archives imbriquées, publiez un checksum (SHA-256) et un court README décrivant la structure interne afin de faciliter l’automatisation des traitements.
Le choix d’un format open data gagne à suivre des standards reconnus. Le RGI français privilégie les formats ouverts. Pour des tables: Table Schema sur schema.data.gouv.fr. Pour JSON: JSON Schema. Pour XML: XSD. Pour la statistique: SDMX. Pour les données géo: GeoJSON en WGS84. Pour le web de données: RDF et des URIs pérennes. Ces repères facilitent la validation, la compatibilité entre outils et le respect des obligations européennes sur les données de forte valeur.
La qualité d’un format fichier opendata se construit avec des schémas et des tests. Validez vos CSV avec Validata, décrivez types, unités et listes de codes. Utilisez UTF-8, des en-têtes clairs et des valeurs manquantes explicites. Fournissez une documentation, un changelog et une version de schéma. Testez le chargement dans un tableur, un notebook Python et via une API. Versionnez les fichiers et signalez la fréquence de mise à jour dans les métadonnées.
Parquet convient à l’open data orienté analytics: stockage colonnaire, compression efficace, requêtes sélectives et partitionnement par date ou zone. L’usage demande des outils data (Arrow, pandas, Spark) et ne s’ouvre pas directement dans un tableur ou un navigateur. Pour un format partage opendata inclusif, proposez Parquet pour la performance et un CSV de référence pour l’accessibilité. Documentez le schéma, le dictionnaire de variables et fournissez un exemple léger pour prise en main rapide.
