JSON vs XML — Lequel choisir ?

Si vous avez déjà intégré une ancienne API d'entreprise ou travaillé avec des flux RSS, vous avez rencontré XML. Si vous avez construit quoi que ce soit sur le web moderne, vous vivez en JSON. Les deux formats résolvent le même problème fondamental — représenter des données structurées sous forme de texte — mais ils le font de manières très différentes. Cet article analyse les vraies différences pour vous aider à faire un choix éclairé.

Les mêmes données, deux formats

Commençons par un exemple concret. Voici un objet utilisateur représenté en JSON :

{
  "user": {
    "id": 101,
    "name": "Bob",
    "email": "[email protected]",
    "roles": ["admin", "editor"],
    "active": true
  }
}

Et voici exactement les mêmes données en XML :

<?xml version="1.0" encoding="UTF-8"?>
<user>
  <id>101</id>
  <name>Bob</name>
  <email>[email protected]</email>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
  <active>true</active>
</user>

La version JSON fait 62 caractères. La version XML en fait 198 — 3× plus volumineuse pour les mêmes données. Sur un petit payload, ça n'a pas d'importance. Sur une API à fort trafic servant des millions de requêtes par jour, la bande passante s'accumule vite.

Là où JSON l'emporte

• Concision. Pas de balises fermantes. Moins de répétition. Des payloads plus légers sur le réseau.
• Support JavaScript natif. JSON.parse() et JSON.stringify() sont intégrés dans chaque runtime JS. Aucune bibliothèque externe requise.
• Simplicité. Six types de données, une poignée de règles. Vous pouvez lire l'intégralité de la spécification JSON en 10 minutes.
• Support des tableaux. JSON dispose de tableaux natifs. En XML, vous êtes contraint de répéter des éléments comme <role> <role> <role>.
• Outillage. Les bases de données modernes comme PostgreSQL, MongoDB et MySQL ont toutes un support JSON de premier ordre. La plupart des plateformes de logs parsent JSON nativement.
• Lisibilité. Les développeurs trouvent JSON plus facile à parcourir du regard. Moins de bruit dû aux chevrons et aux balises fermantes.

Là où XML tient encore la route

• Attributs et métadonnées. Les éléments XML peuvent porter des attributs : <user id="101" active="true">. C'est utile quand vous devez annoter des données sans ajouter d'éléments enfants.
• Espaces de noms. Les espaces de noms XML permettent de mélanger des vocabulaires dans un seul document — indispensable dans des formats comme XHTML, SVG, SOAP et Office Open XML.
• Validation par schéma. XML Schema (XSD) offre une validation puissante et standardisée incluant les types de données, les patterns et la cardinalité. JSON Schema rattrape son retard, mais XML Schema bénéficie de décennies d'outillage.
• Cas d'usage centrés sur les documents. XML a été conçu pour les documents, pas seulement les données. Des formats comme XHTML, DocBook et DITA sont construits sur XML et fonctionnent parfaitement pour du contenu mêlant texte et balisage.
• Transformations XSLT. Vous pouvez transformer du XML en HTML, d'autres XML ou du texte brut avec XSLT — un outil puissant pour les pipelines de publication.
• Commentaires. XML supporte les commentaires. JSON ne les supporte pas. Pour les fichiers de configuration où vous souhaitez expliquer pourquoi un paramètre existe, c'est important.

Performance : est-ce vraiment important ?

Pour la plupart des applications, la différence de performance de parsing entre JSON et XML est sans importance. Là où elle compte — flux de données à haute fréquence, télémétrie IoT, systèmes temps réel — JSON l'emporte confortablement. Les parseurs JSON sont plus simples et plus rapides car le format lui-même est plus simple. Un benchmark rapide : parser un fichier JSON de 1 Mo dans Node.js prend généralement 10–30 ms. Le XML équivalent, avec un parseur SAX, est souvent 2–5× plus lent, et un parseur DOM est encore pire.

Si la performance est vraiment critique, aucun des deux formats n'est idéal — vous opteriez pour un format binaire comme Protocol Buffers ou MessagePack. Mais pour un travail d'API web classique, les performances de JSON sont plus que suffisantes.

Guide de décision : quand utiliser lequel

Utilisez JSON quand :

• Vous construisez des APIs REST ou GraphQL
• Vous stockez une configuration ou des paramètres (package.json, tsconfig.json, etc.)
• Vous travaillez avec JavaScript, TypeScript, Python, Ruby, Go — tout langage moderne
• Vous communiquez avec n'importe quelle API tierce moderne
• Vous stockez des documents dans MongoDB, Elasticsearch ou des colonnes PostgreSQL JSONB

Utilisez XML quand :

• Vous intégrez des systèmes d'entreprise legacy (SAP, Salesforce SOAP APIs, etc.)
• Vous travaillez avec des formats de document : SVG, EPUB, Office Open XML (.docx, .xlsx)
• Des pipelines de publication utilisent des transformations XSLT
• Des flux RSS / Atom
• Vous échangez des données dans des industries ayant des standards XML établis (HL7 en santé, FpML en finance, etc.)

Travailler avec les deux formats

Parfois vous aurez besoin de convertir entre les deux. Peut-être consommez-vous une API XML legacy et souhaitez stocker les données en JSON, ou vous devez envoyer des données vers un service basé sur XML depuis un backend natif JSON. Vous pouvez utiliser le convertisseur XML vers JSON ou le convertisseur JSON vers XML pour gérer ces transformations. Pour inspecter des réponses XML, le Formateur XML et le Validateur XML sont bien pratiques.

Pour conclure

JSON et XML résolvent le même problème mais servent des contextes différents. JSON est le bon choix pour la grande majorité du développement moderne — il est plus simple, plus léger, et bénéficie d'un meilleur support natif dans tous les langages. XML possède des atouts véritablement uniques pour les cas d'usage centrés sur les documents et sensibles aux espaces de noms. La bonne nouvelle, c'est que vous n'avez pas besoin d'être dogmatique — les deux formats sont matures, bien supportés, et coexisteront encore longtemps. Connaissez les compromis, et choisissez le bon outil pour le travail.