Article
Convertir entre CSV, XML, JSON et YAML : guide pratique
CSV, JSON, XML et YAML sont les quatre formats que les développeurs rencontrent le plus souvent dans les pipelines de données, les fichiers de configuration et les API. La conversion entre eux est directe quand les modèles de données correspondent, et étonnamment destructrice quand ce n'est pas le cas. Ce guide explique ce que chaque format peut ou non représenter, où l'information disparaît lors de la conversion, et les pièges d'encodage qui provoquent une corruption silencieuse. L'outil data-converter de ce site gère trois des quatre formats (CSV, JSON et YAML) entièrement dans le navigateur ; les sections consacrées au XML servent de repère si vous déplacez des données à la main ou avec un autre outil.
Les quatre formats et leurs modèles de données
CSV organise les données sous forme d'une grille plate de lignes et de colonnes. La première ligne nomme généralement les colonnes ; chaque ligne suivante est un enregistrement. Il n'y a ni imbrication, ni type, ni standard au-delà du texte brut dans les cellules. Toute valeur est une chaîne de caractères, sauf si l'application qui la consomme impose un type. JSON modélise les données comme un arbre d'objets (associations clé-valeur) et de tableaux. Les valeurs peuvent être des chaînes, des nombres, des booléens, null, des objets imbriqués ou des tableaux à n'importe quelle profondeur. Un seul document JSON peut ainsi représenter un client avec un objet adresse imbriqué, un tableau de lignes de commande et des totaux numériques typés. XML modélise les données comme un arbre d'éléments. Chaque élément peut porter des attributs nommés et contenir des éléments enfants ou du contenu textuel. Il n'y a pas de type numérique ou booléen natif ; tout est du texte. Des schémas comme XSD peuvent imposer des types à la validation, mais le format de transmission est toujours des données de caractères. YAML utilise l'indentation pour exprimer le même modèle objet-et-tableau que JSON, avec une syntaxe plus lisible par un humain. YAML est un sur-ensemble de JSON : tout document JSON valide est aussi du YAML valide. Il ajoute les chaînes multi-lignes, les commentaires et les références d'ancrage pour les blocs répétés. YAML est courant dans les fichiers de configuration ; JSON est courant dans les réponses d'API.
Conversions avec perte : aplatissement et ambiguïté XML
La conversion avec perte la plus courante est l'aplatissement d'un JSON ou XML imbriqué vers CSV. Un objet JSON avec un champ d'adresse imbriqué ne peut pas être mappé proprement sur une ligne CSV. La solution habituelle consiste à utiliser des noms de colonnes en notation pointée : customer.address.city devient sa propre colonne. Cela fonctionne pour un niveau d'imbrication, mais échoue complètement dès qu'un tableau apparaît. Un client avec trois numéros de téléphone nécessite soit trois colonnes séparées (en fixant le maximum en dur), soit un fractionnement en un second fichier CSV, soit l'encodage du tableau comme chaîne délimitée dans une seule cellule. Aucune de ces options ne permet de revenir au JSON d'origine sans métadonnées supplémentaires. XML introduit une ambiguïté distincte : le choix entre attribut et élément enfant. La valeur Paris peut être stockée comme attribut (<city name="Paris">) ou comme élément enfant (<city><name>Paris</name></city>). Lorsqu'un convertisseur lit du XML et produit du JSON, il doit décider comment mapper les attributs. Les conventions courantes incluent le préfixe @ sur les clés d'attributs ou leur regroupement sous une clé "_attributes". Ce choix n'est pas standardisé, ce qui signifie que deux convertisseurs lisant le même XML peuvent produire un JSON structurellement différent. Si vous devez faire des allers-retours entre XML et JSON, fixez une convention avant de commencer.
Pièges CSV : délimiteurs, guillemets et encodage
Le CSV n'a pas de standard formel unique, seulement la RFC 4180 comme référence largement citée. Le délimiteur le plus courant est la virgule, mais les points-virgules (courants dans les locales européennes où la virgule sert de séparateur décimal), les tabulations (TSV) et les barres verticales apparaissent aussi dans la pratique. Un fichier nommé .csv peut utiliser n'importe lequel de ces délimiteurs sans l'indiquer. Lorsqu'une valeur de champ contient le délimiteur lui-même, la RFC 4180 exige d'entourer le champ de guillemets doubles : "San Francisco, CA". Un guillemet double à l'intérieur d'un champ entre guillemets doit être échappé en le doublant : "Il a dit ""bonjour""". Un champ contenant un saut de ligne littéral doit aussi être mis entre guillemets. Les analyseurs qui négligent cette étape produisent des erreurs de comptage de lignes difficiles à localiser. L'encodage est un piège distinct. Les fichiers CSV issus d'outils Windows portent souvent un BOM UTF-8 (marqueur d'ordre des octets : les trois octets EF BB BF au début du fichier). Le BOM aide Excel à identifier l'encodage, mais de nombreux analyseurs de langages de programmation traitent le BOM comme une partie du premier nom de colonne, produisant une colonne nommée "id" au lieu de "id". Cela casse tout code en aval qui recherche des colonnes par nom. Lors de la lecture programmatique d'un fichier CSV, supprimez le BOM avant l'analyse, ou utilisez une bibliothèque qui le gère explicitement.
Choisir un format : configuration, échange et tableurs
Le choix du format est généralement dicté par le contexte, pas par la préférence. JSON est le format par défaut pour les API REST et les échanges navigateur-serveur. Il est compact, nativement analysé dans tous les langages de programmation, et porte des informations de type pour les nombres et les booléens. Son point faible est l'absence de commentaires, ce qui le rend inadapté aux fichiers que les développeurs lisent et modifient à la main. YAML est préféré pour les fichiers de configuration (manifestes Kubernetes, définitions de pipelines CI, playbooks Ansible) parce qu'il autorise les commentaires en ligne et est plus lisible que JSON avec de nombreux niveaux d'indentation. Son principal risque est que les erreurs d'indentation sont silencieuses : une clé mal indentée passe dans une portée différente sans aucune erreur d'analyse. XML reste le standard dans les anciens systèmes d'entreprise, les services web SOAP, les formats de documents (DOCX, SVG, RSS) et les contextes nécessitant une validation de schéma ou une désambiguïsation d'espaces de noms. Il est verbeux, mais les outils XPath et XSLT sont matures. CSV est le bon choix quand les données sont réellement plates et que le consommateur est un tableur ou un analyste de données. Il ne convient pas à la configuration ou aux échanges API, car il n'a ni système de types ni imbrication.
Convertir localement avec data-converter
L'outil data-converter de ce site analyse et convertit entre CSV, JSON et YAML entièrement dans le navigateur ; il ne lit ni n'écrit de XML. Aucune donnée n'est transmise à un serveur à aucun moment. La conversion s'exécute dans votre moteur JavaScript local, et le résultat est disponible pour le téléchargement ou la copie sans que rien ne quitte votre appareil. Cela compte pour les données que vous n'avez pas le droit de partager : réponses d'API contenant des informations personnelles, fichiers de configuration avec des noms d'hôtes internes, ou exports CSV de bases de données internes. Coller ces données dans un convertisseur web qui tourne sur un serveur signifie que le contenu est envoyé sur le réseau et traité sur du matériel que vous ne contrôlez pas. Avec data-converter, l'onglet du navigateur est l'environnement de traitement. L'outil applique les guillemets RFC 4180 en lecture comme en écriture du CSV, et attend un tableau plat d'objets pour convertir du JSON ou du YAML vers CSV : une valeur objet ou tableau imbriquée sous une clé ne bénéficie d'aucun aplatissement automatique en notation pointée, donc aplatissez ces champs vous-même avant la conversion si vous en avez besoin comme colonnes séparées. Si vous devez déplacer des données vers ou depuis le XML, convertissez-les d'abord en JSON ou en YAML avec un outil XML dédié, puis importez le résultat ici.
Outils mentionnés dans cet article
Questions fréquentes
Puis-je faire un aller-retour JSON vers CSV et retrouver l'original ?
Seulement si le JSON est un tableau plat d'objets sans champs imbriqués ni tableaux comme valeurs. Dès qu'il y a un objet imbriqué ou un tableau comme valeur, la représentation CSV nécessite une décision structurelle (colonnes en notation pointée, lignes multiples ou chaînes encodées) qui ne peut pas être inversée automatiquement. Si vos données ont de l'imbrication, JSON, XML ou YAML font des allers-retours propres ; CSV ne le permet pas.
Pourquoi mon CSV s'affiche mal dans Excel après un export d'une application européenne ?
Les locales européennes utilisent souvent des points-virgules comme délimiteur CSV, car les virgules sont réservées à la notation décimale. Excel en locale européenne attend des points-virgules. Si le fichier utilise des virgules, Excel traite toute la ligne comme une seule colonne. La solution consiste soit à changer le délimiteur dans les paramètres d'export, soit à utiliser l'assistant d'importation de données d'Excel, qui permet de spécifier le délimiteur manuellement. Le problème du BOM UTF-8 est distinct : sans BOM, Excel peut aussi mal lire les caractères accentués et les afficher de manière incorrecte.
Quelle est la différence entre YAML et JSON en pratique ?
Les deux représentent le même modèle de données sous-jacent : objets, tableaux, chaînes, nombres, booléens et null. YAML ajoute les commentaires (lignes commençant par #), les littéraux de chaînes multi-lignes et les références d'ancrage pour les blocs répétés. JSON est strictement un sous-ensemble du YAML valide, mais les analyseurs JSON ne lisent pas le YAML. La règle pratique : utilisez JSON pour les charges utiles d'API et le stockage de données ; utilisez YAML pour les fichiers de configuration que les humains modifient et qui bénéficient de commentaires en ligne.