JSON vs XML : Quel format de données choisir ?

C'est probablement la question la plus courante que je vois chez les développeurs qui démarrent un nouveau projet : « Dois-je utiliser JSON ou XML ? » La réponse honnête est... ça dépend. Mais après avoir lu cet article, vous saurez exactement quand choisir l'un ou l'autre.

Comparons la syntaxe

La façon la plus simple de comprendre la différence est de voir les mêmes données dans les deux formats. Représentons un utilisateur simple :

JSON :

XML :

Remarquez que JSON est environ 40% plus petit ? Pas de balises fermantes, pas de soupe de chevrons. Ça s'accumule vite quand vous envoyez des milliers de réponses API par seconde.

La question des performances

JSON l'emporte généralement en vitesse. La plupart des benchmarks montrent que le parsing JSON est 2 à 10 fois plus rapide que le parsing XML, selon les données et la bibliothèque utilisée. La raison ? JSON a moins de fonctionnalités à gérer, donc les parseurs sont plus simples et plus rapides.

Cela dit, XML a un atout dans sa manche pour les très gros fichiers. Les parseurs SAX peuvent streamer du XML sans charger tout le document en mémoire. Si vous traitez un flux XML de 2 Go, ça compte beaucoup.

Types de données : c'est là que ça devient intéressant

JSON a des types natifs : chaînes, nombres, booléens, null, objets et tableaux. Quand vous parsez {"count": 42}, vous obtenez un vrai nombre — pas une chaîne que vous devez convertir.

XML traite tout comme du texte. Le nombre 42 dans 42 n'est qu'une chaîne tant que vous ne le convertissez pas explicitement. Vous avez besoin de définitions XML Schema (XSD) pour imposer les types, ce qui ajoute de la complexité.

Voici un exemple concret de la différence. En JavaScript :

Quand choisir JSON

• APIs REST — Ce n'est même plus un débat. La spécification OpenAPI (anciennement Swagger) utilise JSON par défaut.
• Fichiers de configuration — package.json, tsconfig.json, .eslintrc.json. L'écosystème Node.js tourne au JSON.
• Applications mobiles — Des payloads plus petits = des chargements plus rapides sur les connexions cellulaires. Vos utilisateurs vous remercieront.
• Applications temps réel — Messages WebSocket, Server-Sent Events, réponses GraphQL — tout est typiquement en JSON.

Quand choisir XML

• Données documentaires — Pensez livres, articles, documents juridiques. XML gère le contenu mixte (texte + balisage) à merveille.
• Services web SOAP — Les systèmes d'entreprise dans la banque et la santé reposent fortement sur SOAP.
• Besoins de validation robuste — XML Schema est plus puissant que JSON Schema pour les règles de validation complexes.
• Transformations XSLT — Besoin de transformer des données en HTML, PDF ou d'autres formats ? XSLT est incroyablement puissant pour ça.
• Intégrations legacy — Beaucoup de systèmes d'entreprise parlent XML, et le refactoring n'est pas toujours possible.

Le verdict

Pour la plupart des nouveaux projets web, choisissez JSON. C'est plus simple, plus rapide et universellement supporté. Mais ne rejetez pas XML — il est véritablement meilleur pour le traitement de documents, les intégrations d'entreprise et les scénarios où vous avez besoin d'une validation de schéma solide comme le roc. Beaucoup d'équipes utilisent les deux : JSON pour leurs APIs, XML pour le traitement de documents.

Besoin de convertir entre les deux ? Notre convertisseur JSON vers XML le fait en quelques secondes.

Une brève histoire des deux formats

XML est arrivé en premier, standardisé par le W3C en 1998. Il a été conçu comme une version simplifiée de SGML (le langage de balisage derrière HTML). Pendant près d'une décennie, XML a régné sur le web — les APIs SOAP, les flux RSS, XHTML, SVG et même les formats de fichiers Microsoft Office (.docx n'est qu'un fichier zip rempli de XML) reposaient dessus.

JSON est apparu vers 2001-2002, porté par Douglas Crockford. La spécification officielle du format est remarquablement courte — une seule page. Il a surfé sur la vague AJAX (Asynchronous JavaScript and XML — qui, ironiquement, a fini par utiliser JSON au lieu de XML dans la plupart des cas). Au début des années 2010, JSON avait dépassé XML pour l'utilisation dans les APIs web, et il n'a pas regardé en arrière.

Comparaison du monde réel : Un catalogue de produits

Regardons un exemple plus complexe. Voici un produit avec des données imbriquées dans les deux formats :

JSON :

XML :

Remarquez quelque chose d'intéressant ? XML a des attributs (comme id="PRD-001" et currency="USD" sur les balises elles-mêmes). JSON n'a pas de concept d'attributs — tout est une paire clé-valeur. Les attributs XML peuvent être très pratiques pour les métadonnées, mais ils ajoutent aussi une couche de complexité lors du parsing.

Erreurs courantes lors de la conversion entre formats

Si vous migrez de XML vers JSON (ou vice versa), attention à ces pièges :

1. Perte des attributs XML. Lors de la conversion de 29.99 en JSON, beaucoup de convertisseurs naïfs produisent simplement {"price": "29.99"} et perdent entièrement l'attribut de devise. Les bons convertisseurs utilisent des conventions comme {"price": {"_value": "29.99", "_currency": "USD"}}.

2. Ambiguïté des tableaux. En XML, si vous avez un seul enfant , il n'est pas clair s'il doit correspondre à une valeur JSON ou à un tableau à un seul élément. Si vous ajoutez plus tard un deuxième , la structure change. JSON est explicite : [item] est toujours un tableau.

3. Perte de types. XML n'a pas de types natifs, donc convertir 42 pourrait donner {"count": "42"} (une chaîne) au lieu de {"count": 42} (un nombre). Les convertisseurs intelligents tentent l'inférence de types, mais ce n'est pas toujours fiable.

Comparaison fonctionnalité par fonctionnalité

Quand utiliser les deux ensemble

Beaucoup de systèmes du monde réel n'utilisent pas exclusivement un seul format. Voici des approches hybrides courantes :

• Modèle API gateway : Votre API REST publique parle JSON, mais en interne vos services communiquent avec des systèmes legacy basés sur XML. La gateway gère la conversion.
• Pipeline de données : Ingérer des flux XML (comme RSS, ATOM ou des formats spécifiques à l'industrie comme HL7 en santé), transformer et stocker en JSON pour votre couche applicative.
• Génération de documents : Stocker les données structurées en JSON dans votre base de données, mais générer du XML quand vous devez produire des PDFs, des fichiers DOCX ou d'autres formats de documents via XSLT.

Performance de parsing : Des vrais chiffres

Voici un exemple pratique en JavaScript qui montre la différence d'approche :

La version JSON n'est pas seulement du code plus court — JSON.parse() est implémenté en C++ natif dans chaque moteur de navigateur, ce qui le rend extrêmement rapide. Le parsing XML implique la construction d'un arbre DOM complet avec des éléments, des attributs, des nœuds de texte et des espaces de noms — beaucoup plus de travail sous le capot.

Essayez par vous-même

Prêt à travailler avec les deux formats ? Voici les outils qui vous faciliteront la vie :

• JSON Formatter — Formatez et embellissez vos données JSON.
• XML Formatter — Nettoyez du XML désordonné avec une indentation correcte.
• JSON to XML Converter — Passez d'un format à l'autre instantanément, avec une gestion intelligente des attributs et des tableaux.

Quel que soit le format que vous choisissez, le plus important est la cohérence au sein de votre projet. Choisissez le format qui correspond le mieux à votre cas d'utilisation, documentez votre décision et tenez-vous-y.