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

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

Ci-dessous, un petit objet écrit dans les trois formats. En les comparant côte à côte, vous voyez ce que chacun sacrifie.

{
  "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 correspond directement aux structures de données que tous les langages courants possèdent déjà (objets/dicts et tableaux/listes), donc l'analyse produit des types natifs sans ambiguïté. Pas de commentaires, une seule façon d'écrire chaque valeur, aucune sensibilité aux espaces. Ces limites le rendent rapide à analyser et sûr à générer depuis du code.

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 agréable pour les humains : pas d'accolades fermantes à compter, des commentaires avec #, et l'indentation à la place de la ponctuation. Vous voulez cela pour des fichiers qu'une personne édite et relit dans un diff : pipelines CI (GitHub Actions, GitLab CI), manifests Kubernetes et configuration d'application.

Cette souplesse est aussi le plus grand piège de YAML. Une erreur d'indentation produit une structure différente sans la moindre erreur d'analyse, et l'analyseur peut convertir des valeurs non citées comme `no`, `yes`, `on` ou des dates en booléens ou en 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'une valeur peut se lire de deux façons.

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.

XML persiste dans les domaines centrés sur le document : API SOAP, SVG, DOCX/XLSX (des fichiers ZIP pleins de XML) et systèmes d'entreprise de la banque, de la santé et de l'administration, avec des pipelines validés XSD que personne ne compte réécrire. Si vos données ont une forme de document (« un paragraphe avec une portion en gras au milieu ») plutôt que d'enregistrement, XML convient souvent mieux.

Convertir entre les formats

Les trois décrivent le même modèle de données objet/tableau/chaîne/nombre/booléen/null (seuls les attributs et le contenu mixte de XML ne se convertissent pas proprement), donc convertir des données de forme enregistrement entre JSON, YAML et XML reste mécanique. Les outils JSON to YAML, YAML to JSON, JSON to XML et XML to JSON de JsonForge convertissent 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.