XML n'est pas mort (malheureusement) — Convertissez-le en JSON comme un adulte

Vous avez appris REST. Vous avez embrassé JSON. Vous croyez que l'ère XML est terminée, comme Flash ou IE6 — quelque chose que vous racontez à vos développeurs juniors comme une histoire de feu de camp. Puis votre nouveau client vous donne les identifiants d'API pour leur intégration bancaire, et là, il y a : un enveloppe SOAP de 400 lignes qui vous regarde en face.

Bienvenue de retour dans l'XML. Il n'est jamais parti.

Pourquoi l'XML est encore partout

Pour beaucoup de développeurs qui construisent des applications modernes, l'XML semble être un reliquat. Mais dans le monde réel — particulièrement dans les logiciels d'entreprise, le secteur bancaire, la santé et les systèmes gouvernementaux — l'XML est une infrastructure fondamentale. Voici où vous allez y faire face :

• Des services web SOAP – Il reste le standard pour les institutions financières, les plateformes d'assurance et les grands systèmes ERP. Votre intégration fintech passe probablement par un tel service.
• Des APIs bancaires – Les messages ISO 20022, les messages SWIFT et de nombreuses APIs bancaires de base communiquent en XML. Il n'y a pas d'option REST.
• Les données gouvernementales – HMRC, l'IRS et la plupart des portails gouvernementaux acceptent ou retournent des données en XML. Cela ne changera pas bientôt.
• Des middleware d'entreprise – SAP, Oracle et les systèmes d'ancienne génération d'ESB parlent nativement XML. Si vous intégrez avec un système d'entreprise, il est probable que vous rencontriez de l'XML.
• Des flux RSS et Atom – Ils restent en XML. De nombreuses chaînes de contenu, les agrégateurs d'actualités et les outils de surveillance en dépendent.

La vérité inconfortable : l'XML n'ira nulle part parce que les systèmes sur lesquels il est construit ne disparaîtront pas. Remplacer l'infrastructure centrale d'une banque n'est pas une tâche de sprint. Alors, vous adaptez.

XML vs JSON : Les différences structurelles qui vous font vraiment mal

Avant de commencer la conversion, il est utile de comprendre pourquoi la conversion XML vers JSON n'est pas simplement un simple échange de format. Les deux formats modélisent les données différemment, et ces différences créent de véritables problèmes.

Côte à côte : Les mêmes données dans les deux formats

Prenons une simple commande client. Voici l'exemple en XML :

<order id="ORD-1042" currency="GBP">
  <customer>
    <name>Alice Martin</name>
    <email>alice@example.com</email>
  </customer>
  <items>
    <item sku="PRD-001">
      <description>Wireless Keyboard</description>
      <quantity>1</quantity>
      <price>49.99</price>
    </item>
    <item sku="PRD-007">
      <description>USB-C Hub</description>
      <quantity>2</quantity>
      <price>29.99</price>
    </item>
  </items>
</order>

Et voici l'équivalent en JSON :

{
  "order": {
    "@id": "ORD-1042",
    "@currency": "GBP",
    "customer": {
      "name": "Alice Martin",
      "email": "alice@example.com"
    },
    "items": {
      "item": [
        {
          "@sku": "PRD-001",
          "description": "Wireless Keyboard",
          "quantity": "1",
          "price": "49.99"
        },
        {
          "@sku": "PRD-007",
          "description": "USB-C Hub",
          "quantity": "2",
          "price": "29.99"
        }
      ]
    }
  }
}

Vous pouvez déjà voir les points de friction structurels. Examinons-les.

Attributs vs Clés

Les éléments XML peuvent porter des attributs (id="ORD-1042") en plus des éléments enfants et du contenu texte. Le JSON n'a pas de concept d'attributs — tout est une paire clé-valeur. La convention la plus courante est de préfixer les attributs avec @ lors de la conversion, ce qui vous donne "@id": "ORD-1042". Certains parsers utilisent $ ou les fléchissent entièrement. La convention importe parce que votre code consommateur doit savoir quel préfixe attendre.

Les tableaux vs éléments répétés

C'est un point qui fait mal aux développeurs constamment. En JSON, un tableau est explicite : [...]. En XML, il n'y a pas de distinction — des éléments frères répétés sont implicitement une liste. Un parser qui voit un seul <item> élément retourne un objet. Deux <item> éléments ? Il retourne un tableau. Votre code casse quand l'API retourne un seul résultat.

La solution est de forcer les tableaux pour les champs connus en liste, ou d'utiliser une bibliothèque qui préserve l'information de type. Quand vous convertissez des données isolées, vérifiez si un champ qui semble être un objet unique pourrait parfois être une liste dans les données de production.

Les nœuds texte et le contenu mixte

Les éléments XML peuvent contenir à la fois du contenu texte et des éléments enfants (contenu mixte). Le JSON ne peut pas représenter cela de manière propre. Les parsers le gèrent différemment — certains utilisent une #text clé, d'autres utilisent _, d'autres simplement suppriment le contenu mixte. Si vous convertissez un XML avec du contenu mixte, vérifiez manuellement la sortie.

Les espaces de noms

Les réponses SOAP sont pleines d'espaces de noms : <ns2:getOrderResponse xmlns:ns2="http://...">. Selon votre parser, ces espaces sont soit supprimés, soit regroupés dans le nom de la clé (ns2:getOrderResponse), soit mappés vers une URI. La plupart du temps, vous voulez les supprimer, mais si deux espaces de noms partagent un nom d'élément, vous perdez la distinction. Connaître ce que vous travaillez est essentiel avant d'assumer que la sortie est propre.

Le chemin rapide : Convertir l'XML en ligne sans écrire un parser

Si vous déboguez une réponse d'API, explorez un schéma inconnu ou effectuez une conversion ponctuelle, écrire un parser est trop lourd. Utilisez le Convertisseur XML vers JSON — collez votre XML, obtenez rapidement du JSON propre et inspectez la structure avant d'écrire du code.

Il gère les attributs (avec la convention de préfixe @ ), les éléments imbriqués, les éléments répétés comme des tableaux, et préserve le contenu texte — ce qui couvre la majorité des payloads d'API réels. Utile pour comprendre rapidement ce que ressemble une réponse SOAP une fois que l'enveloppe est retirée.

Conversion programmée : Quoi utiliser en production

Pour du code de production intégrant des APIs XML, vous voulez une bibliothèque appropriée plutôt que de réécrire un parser. Voici les options principales selon la langue :

JavaScript / Node.js

import { XMLParser } from 'fast-xml-parser';

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: '@',
  isArray: (name) => ['item', 'product', 'order'].includes(name),
});

const result = parser.parse(xmlString);

fast-xml-parser est la meilleure option pour Node.js. Utilisez isArray pour forcer le traitement en tableau pour les éléments connus en liste — cela évite le problème de l'objet unique / tableau qui vous frappera finalement en production.

Python

import xmltodict

with open('response.xml') as f:
    data = xmltodict.parse(f.read())

import json
print(json.dumps(data, indent=2))

xmltodict est la solution standard en Python. Elle utilise la convention @ pour les attributs et #text pour les nœuds texte. Notez que cela retourne un OrderedDict, qui sert bien avec json.dumps.

PHP

$xml = simplexml_load_string($xmlString);
$json = json_encode($xml);
$data = json_decode($json, true);

PHP’s simplexml_load_string + json_encode est le chemin rapide, mais il gère les attributs de manière incohérente et peut perdre des données dans des cas extrêmes. Pour des travaux de production sur des réponses SOAP, envisagez DOMDocument avec LIBXML_NOBLANKS ou une bibliothèque dédiée.

Les pièges courants à surveiller

• Les nombres sortent sous forme de chaînes. L'XML n'a pas de type numérique — tout est texte. Votre champ prix sera "49.99", et non pas 49.99. Convertissez explicitement après la conversion.
• Les valeurs booléennes restent sous forme de chaînes. <active>true</active> devient "active": "true". Vérifiez avant d'utiliser dans des conditions.
• Les éléments vides deviennent null ou des objets vides. <middleName/> peut être converti en null, "", ou {} selon le parser. Testez le cas limite.
• Les sections CDATA peuvent être préservées ou non. Si l'API utilise des CDATA pour échapper au contenu HTML, vérifiez que votre parser le gère et ne le supprime pas silencieusement.
• L'ordre n'est pas garanti. L'ordre des éléments XML peut être significatif dans certains schémas ; l'ordre des clés dans un objet JSON ne l'est pas. Si la séquence est importante pour le système consommateur, gérez-la explicitement.

Travailler avec SOAP spécifiquement

SOAP ajoute une couche supplémentaire sur XML : chaque réponse est enveloppée dans un <Envelope> avec un <Body>, souvent décorée avec des déclarations d'espace de noms et un <Header> block. Avant de convertir en JSON, vous voulez généralement extraire uniquement le contenu du corps.

En Python avec zeep (le client SOAP), vous obtenez directement des objets Python et n'avez pas besoin de parser l'XML vous-même. En Node.js, soap et strong-soap faites de même. Si vous appelez un point d'entrée SOAP brut avec fetch ou axios, vous devrez manuellement retirer l'enveloppe avant d'exécuter votre convertisseur XML vers JSON.

Pour une inspection rapide des réponses SOAP, le Convertisseur XML vers JSON est utile — collez l'enveloppe complète, voyez la structure complète et déterminez quel chemin mène à vos données.

Acceptez la réalité et passez à l'action

Il y a un type de douleur particulier qui survient quand on réalise que votre projet de départ a besoin d'intégrer une API SOAP construite en 2003. Permettez-vous de ressentir cela, puis passez à l'action. L'XML est un problème résolu — les parsers sont matures, les outils de conversion existent, et les pièges sont bien documentés. Vous n'êtes pas le premier développeur à faire face à une enveloppe de 400 lignes.

Utilisez la bonne bibliothèque pour votre langue, gérez explicitement les conversions de type, forcez les tableaux pour les champs connus en liste, et testez avec des données réelles plutôt que les exemples idéalisés dans les documents d'API. Les documents montrent une seule entrée ; en production, vous recevrez cinquante.

Et pour les travaux d'exploration — comprendre un schéma XML inconnu, valider une conversion avant d'écrire du code — gardez le Convertisseur XML vers JSON bookmarké. C'est plus rapide que de lancer un script chaque fois que vous avez besoin d'inspecter un payload.

Vous aimerez peut-être aussi