Un ingénieur DevOps exporte une configuration Kubernetes en YAML mais doit l'envoyer à une API qui n'accepte que du JSON. Un analyste reçoit des données d'API en JSON mais a besoin d'un tableur. Un data scientist exporte un CSV depuis une base de données mais a besoin de JSON structuré pour un tableau de bord web.
La conversion de format n'est pas qu'une opération mécanique. Chaque format fait des compromis différents, et comprendre ce qui se perd dans la traduction est tout aussi important que savoir convertir.
Trois formats, trois philosophies
Chaque format a été conçu pour un public et un problème différents :
| Format | Naissance | Conçu pour | Philosophie |
|---|---|---|---|
| CSV | ~1972 | Échange de données entre programmes | Simplicité maximale — juste des lignes et des colonnes |
| JSON | 2001 | Échange de données web | Données structurées lisibles par les machines avec des règles strictes |
| YAML | 2001 | Fichiers de configuration | Données structurées lisibles par les humains avec une syntaxe minimale |
CSV considère que vos données sont une table plate. Chaque valeur est du texte. Il n'y a aucun concept d'imbrication, de typage ou de métadonnées.
JSON considère que vos données ont une structure — objets, tableaux, types (chaînes, nombres, booléens, null). Il est strict et non ambigu, ce qui le rend idéal pour les machines mais verbeux pour les humains.
YAML considère qu'un humain lira et modifiera le fichier. Il utilise l'indentation au lieu des accolades, supporte les commentaires et a une syntaxe plus souple. Techniquement, le YAML est un surensemble du JSON — tout document JSON valide est aussi du YAML valide.
Le YAML est un surensemble du JSON Vous pouvez coller un document JSON directement dans un parseur YAML et il fonctionnera. L'inverse n'est pas vrai — les fonctionnalités YAML comme les commentaires, les ancres et les chaînes multiligne n'ont pas d'équivalent JSON.
Scénarios de conversion concrets
Migration de configuration (JSON vers YAML, YAML vers JSON)
C'est la conversion la plus courante. Différents outils attendent différents formats de configuration :
- Docker Compose, Kubernetes, GitHub Actions, Ansible utilisent le YAML
- package.json, tsconfig.json, ESLint utilisent le JSON
- Migrer entre outils signifie souvent convertir des configs
Cette conversion est sans perte dans les deux sens pour le contenu des données — mais les commentaires YAML sont perdus lors de la conversion vers JSON, puisque JSON n'a pas de syntaxe de commentaire.
Analyse de données (JSON vers CSV)
Les réponses d'API arrivent en JSON. Les analystes ont besoin de tableurs. Cette conversion fonctionne bien pour les tableaux JSON plats — les tableaux d'objets avec des clés identiques se traduisent naturellement en lignes et colonnes.
Mais elle échoue avec les données imbriquées. Un objet JSON avec un champ address.city et un tableau skills n'a pas de représentation CSV naturelle. Le convertisseur doit choisir : aplatir les clés imbriquées (address.city devient une colonne), sérialiser les valeurs imbriquées en texte, ou les ignorer.
Import de données (CSV vers JSON)
Le scénario inverse : importer des données de tableur dans une application web ou une API. La conversion CSV vers JSON crée un tableau d'objets, avec les en-têtes de colonnes comme clés. Le piège : le CSV n'a pas d'information de type — le nombre 42, la chaîne "42" et le booléen true sont tous du simple texte en CSV. Le convertisseur doit deviner les types.
Lisibilité humaine (JSON vers YAML)
Parfois, on a juste besoin de rendre un fichier JSON dense plus lisible. Convertir en YAML donne une indentation propre et la possibilité d'ajouter des commentaires pour documenter. C'est particulièrement précieux pour les gros fichiers de configuration maintenus par une équipe.
Ce qui se perd dans la conversion
C'est la connaissance essentielle qui épargne du temps de débogage :
| Conversion | Ce qui se perd |
|---|---|
| YAML vers JSON | Commentaires (JSON n'a pas de syntaxe de commentaire) |
| JSON vers CSV | Imbrication (le CSV est plat), types (tout devient du texte), tableaux |
| CSV vers JSON | Rien (mais les types doivent être inférés — "42" vs 42) |
| CSV vers YAML | Rien (même problème d'inférence de type) |
| JSON vers YAML | Rien (le YAML est un surensemble du JSON) |
| YAML vers CSV | Commentaires, imbrication, types, ancres/alias |
Le schéma est clair : les conversions vers le CSV perdent le plus d'information, car le CSV est le format le plus simple. Les conversions entre JSON et YAML sont quasiment sans perte. Et les commentaires YAML sont toujours perdus en quittant le YAML.
Bidirectionnel vs sens unique JSON vers YAML et YAML vers JSON sont effectivement bidirectionnels (aller-retour sûr, sauf pour les commentaires). JSON vers CSV et YAML vers CSV sont à sens unique pour les données complexes — impossible de reconstituer l'imbrication à partir d'un CSV plat.
Les pièges courants lors de la conversion
Les pièges de typage du YAML
Le YAML interprète automatiquement certaines chaînes comme des types non-texte. Le mot no devient le booléen false. Le mot yes devient true. La chaîne 1.0 devient un nombre flottant. Les codes pays comme NO (Norvège) ont causé des bugs célèbres. Il faut toujours encadrer les valeurs ambiguës avec des guillemets en YAML.
Confusion de séparateur et d'encodage en CSV
Tous les CSV n'utilisent pas la virgule. Les CSV européens utilisent souvent le point-virgule (car la virgule est le séparateur décimal dans de nombreux formats numériques européens). Les valeurs séparées par des tabulations (TSV) sont une autre variante. Et les incompatibilités d'encodage (UTF-8 vs Latin-1) produisent des caractères accentués illisibles.
Le problème de la virgule finale en JSON
Le JSON n'autorise pas les virgules finales. Ceci est valide en JavaScript : {"a": 1, "b": 2,} — mais c'est du JSON invalide. Une seule virgule finale provoque une erreur d'analyse.
Performance sur les gros jeux de données
Pour les jeux de données de millions de lignes, le CSV est significativement plus efficace que le JSON ou le YAML. Le JSON ajoute des accolades, des crochets et des guillemets pour chaque valeur. Un CSV de 1 million de lignes peut faire 50 Mo ; le JSON équivalent peut en faire 150 Mo.
Choisir le bon format dès le départ
Plutôt que de convertir après coup, choisir le bon format en amont évite la perte d'information :
- Données tabulaires pour tableurs ou bases de données — CSV
- Données structurées pour API ou applications web — JSON
- Configuration que des humains vont modifier — YAML
- Données imbriquées complexes avec commentaires — YAML
- Échange de données entre systèmes — JSON
Pour aller plus loin
Convertissez entre JSON, YAML et CSV instantanément avec des outils dans le navigateur :
- Convertir entre formats de données — collez vos données, choisissez le format cible, téléchargez le résultat
- Formateur JSON — valider, formater et minifier du JSON
- Convertisseur JSON vers CSV — convertir des tableaux JSON en CSV prêt pour le tableur
- Convertisseur YAML-JSON — convertir entre YAML et JSON