JSON, YAML ou XML : syntaxe, usages et conversion de l'un à l'autre

JSON, YAML et XML sont tous des formats texte pour les données structurées. Avec les mêmes informations, les trois les décrivent fidèlement, mais en pratique chacun s'est installé sur son propre terrain : JSON dans les API, YAML dans les fichiers de configuration, XML dans les documents et les systèmes d'entreprise. Comprendre pourquoi vous aide à choisir le bon format et à éviter les mauvaises surprises lors d'une conversion.

Les mêmes données dans trois formats

Voici la définition d'un petit service écrite de trois façons. D'abord en JSON :

{
  "service": "web",
  "port": 8080,
  "debug": false,
  "tags": ["api", "public"]
}

La même chose en YAML :

# web service
service: web
port: 8080
debug: false
tags:
  - api
  - public

Et en XML :

<?xml version="1.0" encoding="UTF-8"?>
<service name="web">
  <port>8080</port>
  <debug>false</debug>
  <tags>
    <tag>api</tag>
    <tag>public</tag>
  </tags>
</service>

Quelques différences sautent aux yeux :

• JSON utilise des accolades, des crochets et des guillemets. Il est strict : pas de commentaires, pas de virgule finale, des clés toujours entre guillemets doubles.
• YAML s'appuie sur l'indentation plutôt que sur les crochets et accepte les commentaires avec #. C'est le plus compact et le plus lisible au premier coup d'œil.
• XML entoure chaque valeur de balises ouvrantes et fermantes et peut attacher des attributs aux éléments (name="web"). C'est le plus verbeux, mais aussi le plus expressif.

JSON : la langue des API

JSON correspond directement aux objets et aux tableaux de presque tous les langages de programmation, ce qui en a fait le format par défaut des API web. Les analyseurs sont rapides, intégrés aux navigateurs et aux bibliothèques standard, et la grammaire est si réduite qu'il existe très peu de façons de mal interpréter un document.

Cette rigueur est un atout pour les machines et une petite gêne pour les humains. Impossible de laisser un commentaire pour expliquer un réglage, et une seule virgule manquante casse tout le fichier. C'est pourquoi JSON fonctionne le mieux quand un programme l'écrit et qu'un autre le lit : réponses d'API, journaux, exports de données, package.json.

YAML : la configuration écrite par des humains

YAML a été conçu pour être écrit et relu par des personnes. C'est pour cela que tant d'outils DevOps l'ont adopté : les manifestes Kubernetes, les workflows GitHub Actions et les fichiers Docker Compose sont en YAML. Les commentaires, les chaînes multilignes et l'absence de ponctuation rendent les longs fichiers de configuration agréables à maintenir.

La contrepartie, ce sont les subtilités. L'indentation a un sens : un espace mal placé modifie la structure. Et YAML devine le type des valeurs non entourées de guillemets, d'où ses pièges les plus célèbres :

country: NO      # YAML 1.1: false
version: 1.10    # 1.1 (number)
zip: 01234       # 1234 or octal

Selon les règles de YAML 1.1, encore appliquées par de nombreux analyseurs, NO, yes, on et off deviennent des booléens. Les nombres perdent leurs zéros finaux et les zéros initiaux peuvent être lus comme de l'octal. La parade est simple : mettez entre guillemets tout ce qui doit rester une chaîne.

country: "NO"
version: "1.10"
zip: "01234"

XML : documents, schémas et flux d'entreprise

XML est plus ancien que les deux autres et offre des fonctions qu'ils n'ont pas : les espaces de noms pour combiner des vocabulaires, les schémas (XSD) pour valider strictement la structure, les attributs et le contenu mixte où texte et balises s'entremêlent. Il est donc tout indiqué pour les documents et pour les systèmes où un contrat formel compte : flux RSS et Atom, services SOAP, normes de facturation et bancaires, images SVG, le pom.xml de Maven et les fichiers contenus dans un DOCX ou un XLSX.

Si vous démarrez un nouveau projet et devez simplement échanger des données, XML est rarement le premier choix. Mais vous continuerez à en recevoir de partenaires, de systèmes existants et de sources de données publiques : savoir le transformer en JSON reste une compétence très utile.

Comparaison rapide

• Lisibilité : YAML > JSON > XML.
• Rigueur et prévisibilité : JSON et XML sont sans ambiguïté ; YAML dépend de l'indentation et de la déduction des types.
• Commentaires : oui pour YAML et XML, non pour JSON.
• Validation : XML dispose des outils de schéma les plus aboutis ; JSON Schema est largement répandu ; YAML est généralement validé via JSON Schema lui aussi.
• Terrain de prédilection : JSON pour les API et les données, YAML pour la configuration, XML pour les documents et l'intégration en entreprise.

Convertir de l'un à l'autre : les points d'attention

Comme les trois décrivent des arbres de données, la conversion est généralement simple. Quelques détails méritent toutefois votre attention :

• Passer de YAML à JSON fait disparaître les commentaires. JSON n'a aucun endroit pour les stocker. Les ancres et les alias (& et *) sont développés en simples copies.
• Passer de JSON à YAML ne perd rien. Tout JSON valide peut s'exprimer en YAML ; en YAML 1.2, JSON en est presque un sous-ensemble.
• Les attributs XML exigent une convention. JSON n'a pas d'attributs : les convertisseurs les enregistrent comme des clés ordinaires, souvent précédées d'un préfixe comme @. Vérifiez le résultat avant de le transmettre à un autre programme.
• Élément unique ou liste. En XML, un <tag> et trois <tag> s'écrivent de la même façon. Une fois en JSON, l'un peut devenir un objet et les autres un tableau : le code qui exploite le résultat doit gérer les deux cas.
• En XML, tout est texte. 8080 et false ne sont que des caractères entre balises ; de XML vers JSON, il faudra peut-être les reconvertir en nombre ou en booléen.
• De JSON vers XML, il faut une racine unique et des clés qui soient des noms d'éléments valides (sans espaces, sans chiffre en première position).

Convertissez dans votre navigateur

Les convertisseurs de données de Azpy fonctionnent entièrement dans votre navigateur : collez votre texte ou déposez un fichier, et le résultat s'affiche instantanément sans que rien ne soit téléversé. Vous pouvez donc les utiliser sereinement avec des fichiers de configuration contenant des noms de serveurs internes ou des réponses d'API renfermant des données clients. JSON en YAML, YAML en JSON, XML en JSON et JSON en XML figurent parmi les outils.

Une règle de bon sens

Des machines qui dialoguent entre elles → JSON. Des humains qui éditent une configuration → YAML, avec des guillemets autour de tout ce qui est ambigu. Des documents, des schémas stricts ou un contrat d'entreprise existant → XML. Et quand le format dont vous disposez n'est pas celui qu'il vous faut, convertissez-le puis vérifiez les cas limites ci-dessus.