JSON vs XML vs YAML : choisir le bon format de données

Les mêmes données, trois façons

Voici un petit objet représenté dans les trois formats. Les comparer côte à côte est le moyen le plus rapide de voir ce que chacun échange réellement.

{
  "user": {
    "name": "Ada Lovelace",
    "roles": ["admin", "editor"],
    "active": true
  }
}

user:
  name: Ada Lovelace
  roles:
    - admin
    - editor
  active: true

<user active="true">
  <name>Ada Lovelace</name>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

Trois champs identiques, trois quantités de ponctuation très différentes. Cette différence résume tout : JSON est le plus adapté aux machines, YAML le plus agréable à écrire à la main pour un humain, et XML le plus expressif quand le document lui-même exige une structure au-delà de simples paires clé/valeur.

Là où JSON gagne

JSON est le choix par défaut pour de bonnes raisons : il correspond directement aux structures de données que tous les langages mainstream possèdent déjà (objets/dicts et tableaux/listes), donc son analyse produit des types natifs sans la moindre ambiguïté. Pas de commentaires, pas de multiples façons d'écrire la même valeur, pas de sensibilité aux espaces — cela paraît limitant, mais c'est précisément ce qui le rend rapide à analyser et sûr à générer par programme.

Utilisez JSON pour tout ce qui est machine-à-machine : charges utiles d'API REST et GraphQL, données transmises entre services, tout ce qui est stocké dans une base documentaire (MongoDB, le type JSONB de PostgreSQL), et toute configuration principalement lue et écrite par du code plutôt qu'éditée à la main.

Là où YAML gagne

YAML est un sur-ensemble strict du modèle de données de JSON avec une syntaxe bien plus conviviale pour les humains : pas d'accolades fermantes à compter, des commentaires avec #, et l'indentation à la place de la ponctuation. C'est exactement ce qu'il faut pour des fichiers qu'une personne édite directement et relit dans un diff — pipelines CI (GitHub Actions, GitLab CI), manifests Kubernetes et configuration d'application.

La contrepartie, c'est que la flexibilité de YAML est aussi son plus grand piège : une erreur d'indentation produit silencieusement une structure différente au lieu d'une erreur d'analyse, et des valeurs non citées comme `no`, `yes`, `on` ou des dates peuvent être converties automatiquement en booléens ou horodatages non voulus (le fameux « problème de la Norvège », où le code pays NO devient le booléen false). Mettez vos chaînes entre guillemets dès qu'il y a une ambiguïté.

Là où XML gagne

XML peut ressembler à un héritage encombrant face à JSON, mais il fait des choses que ni JSON ni YAML ne peuvent : des attributs à côté du contenu des éléments, du contenu mixte (texte et éléments entrelacés, comme HTML), des espaces de noms pour combiner des vocabulaires de sources différentes, et des outils matures de validation par schéma (XSD) et de transformation (XSLT) qui précèdent JSON d'une décennie.

C'est pourquoi XML persiste dans les domaines centrés sur le document — API SOAP, SVG, DOCX/XLSX (des fichiers ZIP pleins de XML) et les systèmes d'entreprise (banque, santé, administration) avec leurs pipelines validés XSD existants que personne ne réécrit. Si vos données sont réellement de forme documentaire (« un paragraphe avec une portion en gras au milieu ») plutôt qu'enregistrement, XML est souvent encore le meilleur choix.

Convertir entre les formats

Puisque les trois décrivent le même modèle de données objet/tableau/chaîne/nombre/booléen/null (les attributs et le contenu mixte de XML sont la seule chose qui ne se convertit pas proprement), convertir entre JSON, YAML et XML est généralement mécanique pour tout ce qui a une forme d'enregistrement. Les outils JSON to YAML, YAML to JSON, JSON to XML et XML to JSON de JsonForge effectuent la conversion dans le navigateur — pratique pour migrer le format d'un fichier de configuration ou fournir un export JSON à un collègue qui ne jure que par YAML.