JSON, XML ou CSV ? Choisir le Bon Format de Données pour la Tâche
13 octobre 2026
JSON, XML et CSV existent tous pour déplacer des données structurées entre systèmes, mais les traiter comme interchangeables est la façon dont les projets d'intégration finissent avec des données perdues, des imports cassés, ou des fichiers surdimensionnés. Chaque format a fait de vrais compromis de conception pour les problèmes et les époques qu'il a été construit pour résoudre, et connaître ces compromis rend le choix du bon format simple pour une tâche donnée.
En quoi le CSV est-il réellement bon, et où montre-t-il ses limites ?
Le CSV (valeurs séparées par des virgules) est à peu près aussi simple qu'un format structuré puisse l'être — du texte brut, une ligne par enregistrement, des valeurs séparées par des virgules — ce qui le rend universellement lisible par les logiciels de tableur, les bases de données, et pratiquement tous les outils de données jamais créés. Il est excellent pour les données plates et tabulaires : une liste d'enregistrements où chaque ligne a les mêmes champs. Il montre ses limites dès que les données ont une véritable structure au-delà d'un simple tableau plat — objets imbriqués, relations un-à-plusieurs, ou champs contenant légitimement des virgules ou des sauts de ligne (gérés de façon incohérente selon les implémentations de CSV) poussent tous le CSV au-delà de ce pour quoi il a été conçu.
Pourquoi JSON est-il devenu le standard par défaut spécifiquement pour les API web ?
La structure objet-et-tableau de JSON correspond presque directement à la façon dont la plupart des langages de programmation modernes représentent déjà les données en mémoire, ce qui signifie qu'une charge utile JSON peut souvent être analysée directement en une structure de données native avec un travail de traduction minimal — un avantage pratique majeur pour les API web où la rapidité et la simplicité de production et de consommation des données comptent. Il est aussi comparativement compact et lisible par un humain, trouvant un équilibre qui en a fait le choix naturel par défaut à mesure que les API web se multipliaient, supplantant largement le XML pour la conception de nouvelles API même si le XML est arrivé en premier.
Que peut faire le XML que le JSON ne peut structurellement pas faire ?
Le XML prend en charge les attributs sur les éléments (métadonnées attachées à une balise elle-même, distinctes de son contenu), les espaces de noms (évitant les collisions de nommage lors de la combinaison de vocabulaires provenant de sources différentes), et un écosystème mature de validation formelle par schéma (XSD) pour définir et faire respecter rigoureusement exactement ce qu'un document valide doit contenir — des capacités que le modèle objet/tableau plus simple de JSON ne fournit pas nativement (JSON Schema existe mais est arrivé plus tard et est moins universellement adopté). C'est pourquoi le XML persiste dans les domaines exigeant une validation stricte des documents, des documents à vocabulaire mixte, ou des standards de données d'entreprise et gouvernementaux de longue date antérieurs à la montée de JSON.
Pourquoi convertir le CSV vers un format imbriqué comme JSON nécessite-t-il plus qu'une conversion mécanique ?
Le CSV n'a aucune notion d'imbrication — chaque ligne est plate — donc convertir des données CSV vers un format qui prend en charge la hiérarchie (comme JSON représentant, par exemple, une commande avec plusieurs lignes d'articles) nécessite une véritable décision sur la façon dont les lignes plates correspondent à une structure imbriquée : chaque ligne devient-elle un objet distinct de premier niveau, ou plusieurs lignes partageant un identifiant sont-elles regroupées en un seul objet avec un tableau imbriqué ? Cette décision de correspondance n'est pas récupérable à partir des seules données CSV — elle dépend de la compréhension des relations réelles des données, ce qui explique pourquoi « convertis juste mon CSV en JSON » produit parfois un résultat techniquement valide mais pratiquement inutilisable si la structure n'a pas été précisée.
La taille de fichier ou la vitesse d'analyse diffèrent-elles significativement entre les trois formats ?
Le CSV est généralement le plus compact pour des données véritablement plates et uniformes puisqu'il n'a presque aucune surcharge structurelle — pas de noms de balises ni de noms de clés répétés par enregistrement. JSON est plus compact que XML pour les mêmes données imbriquées parce qu'il n'a pas la redondance des balises de fermeture du XML, mais inclut plus de surcharge que le CSV en raison des noms de clés répétés dans chaque objet, sauf si un encodage plus compact basé sur des tableaux est utilisé. XML est généralement le plus volumineux des trois pour des données équivalentes en raison de balises d'ouverture et de fermeture verbeuses, bien que ce soit rarement le facteur décisif comparé aux capacités structurelles et à l'écosystème d'outils dont une intégration donnée a réellement besoin.