JSON, CSV ou XML : choisir un format de données que vous ne regretterez pas

Trois formats, trois missions différentes. Ce que chacun peut et ne peut pas exprimer, les conversions qui perdent de l'information, et comment choisir sans le regretter.

Mis à jour le 11 août 20265 min de lecture

Ces trois formats sont moins des concurrents que des réponses à des questions différentes. Le CSV est un tableau. Le JSON est un graphe d'objets. Le XML est un document balisé. L'essentiel de la douleur en traitement de données vient de demander à un format d'être ce qu'il n'est pas — de l'imbrication dans du CSV, des tableaux dans du XML, des commentaires dans du JSON — et le remède est généralement de changer de format plutôt que de lutter contre lui.

Ce que chacun sait exprimer

	CSV	JSON	XML
Forme	Lignes et colonnes plates	Objets et tableaux imbriqués	Éléments imbriqués
Types	Aucun — tout est du texte	Chaîne, nombre, booléen, null	Aucun nativement ; un schéma peut en ajouter
Commentaires	Non	Non	Oui
Attributs vs contenu	Sans objet	Pas de distinction	Oui — une vraie différence
Taille	La plus petite	Moyenne — les clés se répètent	La plus grande — les balises se répètent deux fois
Traiter d'énormes fichiers en flux	Trivial	Pénible	Faisable

La ligne qui surprend le plus est celle des commentaires en JSON. La spécification n'en prévoit aucun, et une ligne // rend le fichier invalide — d'où le fait que tant d'outils aient inventé leurs propres dialectes (JSON5, JSONC) pour contourner le problème. Si un fichier de configuration a besoin d'être expliqué, c'est une vraie raison de préférer autre chose.

Choisir d'après la destination

1Destination : tableur, base de données ou outil d'analyse ? CSV. Universellement pris en charge, compact, et la forme tabulaire est ce que ces outils attendent.
2Destination : une API ou une application web ? JSON. Il porte les types, exprime l'imbrication, et tous les langages l'analysent sans avoir à choisir une bibliothèque.
3Vous dialoguez avec un système d'entreprise ou d'administration ? Probablement du XML, parce que c'est ce que dira la spécification. Ne luttez pas.
4Un fichier de configuration que des humains modifieront à la main ? Pas du JSON — pas de commentaires et une syntaxe impitoyable. YAML ou TOML sont plus cléments.
5Des millions de lignes ? CSV, traité ligne par ligne. Analyser en entier un document JSON de plusieurs gigaoctets est un problème de mémoire.

Ce que chaque conversion perd

Conversion	Ce qui est perdu
CSV → JSON	Rien structurellement, mais tout arrive en chaînes de caractères si les types ne sont pas déduits
JSON → CSV	L'imbrication. Objets et tableaux doivent être aplatis ou abandonnés
XML → JSON	La distinction attribut/élément, les commentaires, les garanties d'ordre
JSON → XML	Rien, mais le résultat est verbeux et exige une convention de nommage
Excel → CSV	Formules, mise en forme, feuilles multiples — voyez Excel vers CSV et JSON

La ligne JSON vers CSV est celle qui mord. Aplatir {customer: {name, address: {city}}} en colonnes exige une convention — customer.address.city est courant — et tout ce qui est une liste n'a aucune bonne réponse. Si votre JSON est réellement imbriqué, l'exporter en CSV est une décision avec perte, pas un changement de format.

Le problème de types dans l'autre sens est plus discret et tout aussi nuisible. Le CSV n'a pas de types, donc 007 peut arriver comme le nombre 7, 2026-04-03 peut devenir une date dans la mauvaise langue, et TRUE peut devenir un booléen ou non. Ce sont les mêmes échecs décrits dans convertir Excel en CSV et JSON, et ils tiennent au format plutôt qu'à un outil particulier.

Mettez en forme, validez et explorez — sur votre appareil. Données clients et charges utiles d'API ne sont jamais envoyées.

Mettre en forme et inspecter du JSON

Habitudes pratiques

Validez avant de livrer. Une virgule en trop ou un guillemet non échappé est rejeté par le système receveur avec une erreur qui pointe rarement la vraie ligne. Le validateur la trouve en quelques secondes.
Utilisez des dates ISO partout. 2026-04-03 est sans ambiguïté dans toutes les langues et se trie correctement en texte brut. Rien d'autre ne l'est.
Encodez en UTF-8, toujours. Tout le reste transforme les noms accentués et les symboles monétaires en charabia sur un autre système.
Gardez les identifiants en chaînes. Codes postaux, numéros de téléphone et numéros de compte sont des étiquettes, pas des quantités — les traiter comme des nombres supprime les zéros initiaux et arrondit les valeurs longues.
Triez les clés pour les comparaisons. Deux exports des mêmes données avec des clés dans un ordre différent produisent un diff plein de bruit. Le trieur de clés rend les changements lisibles.

Minifier ou mettre en forme ?

Les deux, à des moments différents. Le JSON mis en forme — indenté, une valeur par ligne — est fait pour la lecture humaine et pour le contrôle de version, où les diffs ligne à ligne sont tout l'intérêt. Le JSON minifié supprime chaque espace inutile et sert à la transmission, où il économise typiquement 20 à 30 % avant compression.

L'erreur est de committer du JSON minifié dans un dépôt. Chaque changement apparaît alors comme une seule énorme ligne modifiée, et la relecture devient impossible. Stockez-le lisible, minifiez à la construction ou à l'envoi.

Tous ces outils tournent localement sur votre appareil, ce qui compte particulièrement pour le travail sur données : une charge utile JSON ou un export CSV est souvent le fichier le plus sensible que manipule une organisation, et en envoyer un à un formateur en ligne est une divulgation, quoi que le service promette d'en faire.

Questions fréquentes

Faut-il utiliser JSON ou CSV ?

CSV pour des données tabulaires destinées à des tableurs, des bases de données ou des outils d'analyse — c'est compact et universellement pris en charge. JSON quand les données sont imbriquées ou que les types comptent, comme pour une charge utile d'API, car le CSV ne peut pas exprimer une liste dans un enregistrement et traite chaque valeur comme du texte.

Le JSON remplace-t-il le XML ?

Pour les API web, largement oui — le JSON est plus léger et correspond directement aux structures de données que les langages utilisent déjà. Le XML reste la norme en entreprise, dans l'administration, l'édition et les formats documentaires, où ses schémas, ses espaces de noms et son modèle d'attributs font un vrai travail.

Le JSON peut-il contenir des commentaires ?

Non. La spécification ne prévoit aucune syntaxe de commentaire, et en ajouter un rend le fichier invalide. C'est pourquoi des variantes comme JSON5 et JSONC existent. Si des humains doivent modifier et comprendre le fichier à la main, YAML ou TOML sont de meilleurs choix pour de la configuration.

Qu'arrive-t-il aux données imbriquées quand je convertis du JSON en CSV ?

Elles doivent être aplaties, généralement en noms de colonnes pointés comme `customer.address.city`, et les listes à l'intérieur d'un enregistrement n'ont aucune représentation propre. Si votre JSON est réellement imbriqué, l'exporter en CSV est une décision avec perte plutôt qu'un simple changement de format.