JSON vs YAML vs XML : quel format de donnees utiliser ?

Tous les quelques mois, quelqu'un dans mon equipe lance un debat sur les formats de donnees. "Pourquoi on utilise JSON ici ? YAML est tellement plus propre." Ou bien, "XML a des schemas, on devrait utiliser ca."

La verite, c'est qu'il n'y a pas de format universellement meilleur. Chacun existe parce qu'il resout un ensemble specifique de problemes vraiment bien. Voyons quand chaque format a du sens.

Matrice de decision rapide

| Caracteristique | JSON | YAML | XML | |-----------------|------|------|-----| | Lisibilite humaine | Bonne | Excellente | Mauvaise | | Vitesse de parsing | Rapide | Moyenne | Lente | | Support des commentaires | Non | Oui | Oui | | Validation par schema | JSON Schema | Limitee | XSD (puissant) | | Types de donnees | Basiques | Riches | Base de chaines | | Sensibilite aux espaces | Non | Oui (attention !) | Non | | Taille des fichiers | Petite | La plus petite | Grande | | Support natif navigateur | Oui | Non | Partiel | | Ideal pour | APIs, configs | Configs, DevOps | Documents, enterprise |

JSON : la lingua franca du web

JSON a gagne le web. Chaque API le parle, chaque navigateur le parse nativement, et chaque langage a un support integre. Si vous construisez une API REST, la decision est deja prise.

Ou JSON brille :

• Reponses et requetes API
• Manifestes de paquets (package.json, composer.json)
• Echange de donnees entre services
• Partout ou un parsing rapide est necessaire

Le point faible : pas de commentaires. Vous ne pouvez pas annoter votre fichier de config JSON pour expliquer pourquoi une valeur est configuree comme elle l'est. Certains contournent ca avec des cles "_comment", mais c'est du bricolage.

YAML : l'option conviviale

YAML a ete concu pour etre lu par des humains d'abord. Pas d'accolades, pas de guillemets sur la plupart des chaines, et vous pouvez ajouter des commentaires partout. Les equipes DevOps l'adorent — Kubernetes, Docker Compose, GitHub Actions, Ansible — tous ont choisi YAML.

Mais YAML a un piege : les espaces comptent. Une mauvaise indentation et toute votre config est cassee. Et les messages d'erreur ? Souvent peu utiles. "Mapping values are not allowed here" ne vous dit pas grand-chose quand vous avez 200 lignes de config.

De plus, la conversion de types de YAML peut vous surprendre. yes devient true. 3.10 devient 3.1. Le code pays de la Norvege NO devient false. Ce ne sont pas des bugs — ce sont des fonctionnalites qui mordent quand on s'y attend le moins.

XML : le cheval de bataille de l'enterprise

XML recoit beaucoup de critiques ces jours-ci, et certaines sont meritees. C'est verbeux. Une simple paire cle-valeur en JSON fait une ligne ; en XML, c'en fait trois.

Mais XML fait des choses que les autres ne peuvent pas. Les schemas XSD fournissent une validation puissante — vous pouvez imposer des types de donnees, des patterns, des champs obligatoires, et meme des plages de valeurs. XSLT permet de transformer des documents. Les espaces de noms empechent les collisions de noms lors de la combinaison de documents de sources differentes.

Si vous travaillez dans la sante (HL7), la finance (FIXML) ou l'edition (DocBook), XML n'ira nulle part. Ces industries ont choisi XML pour sa rigueur, et cette rigueur est exactement ce dont elles ont besoin.

Quand utiliser quoi

Choisissez JSON quand :

• Vous construisez des APIs web
• Vous stockez une configuration simple
• Vous echangez des donnees entre frontend et backend
• Vous avez besoin d'un parsing rapide et d'un support linguistique large

Choisissez YAML quand :

• Vous ecrivez des pipelines CI/CD
• Vous configurez Kubernetes ou Docker
• Des fichiers de config edites par des humains ou les commentaires aident
• Vous avez besoin de chaines multi-lignes sans caracteres d'echappement

Choisissez XML quand :

• Vous travaillez avec des systemes enterprise qui l'exigent
• Vous avez besoin d'une validation par schema puissante
• Des documents avec du contenu mixte (texte avec donnees integrees)
• Vous avez besoin d'espaces de noms pour combiner des types de documents

Convertir entre les formats

La realite pratique : vous aurez souvent besoin de convertir entre les formats. Peut-etre que vous migrez une vieille config XML vers YAML, ou que vous devez transformer du YAML en JSON pour une API.

La structure se mappe assez proprement entre les trois. Les objets deviennent des maps deviennent des elements. Les tableaux deviennent des sequences deviennent des elements repetes. Les parties delicates sont les attributs en XML (pas d'equivalent direct en JSON ou YAML) et les commentaires (perdus lors de la conversion en JSON).

Vous pouvez aussi convertir entre XML et JSON ou CSV et JSON quand vous travaillez avec des donnees tabulaires.

La vraie reponse

Utilisez ce que votre ecosysteme attend. Si vous ecrivez des configs Kubernetes, utilisez YAML. Si vous construisez une API web, utilisez JSON. Si vous etes dans la sante enterprise, utilisez XML.

Ne vous battez pas contre les conventions de vos outils et de votre equipe. Le meilleur format de donnees est celui que tout le monde dans votre projet comprend deja.

---

Les debats sur les formats de donnees sont amusants, mais ils comptent rarement autant qu'on le pense. Choisissez celui qui correspond a votre cas d'utilisation, soyez coherent, et passez a la resolution de vrais problemes. Vos utilisateurs se fichent de savoir si votre fichier de config utilise des accolades ou de l'indentation.