XML en 2026 : Est-il toujours pertinent pour le développement moderne ?

Je vais être honnête — quand je vois « XML » en 2026, mon premier réflexe est de penser « code legacy ». Mais c'est en fait injuste. XML alimente discrètement certains des systèmes les plus critiques de la planète, et il n'est pas près de disparaître. Laissez-moi vous montrer pourquoi.

Où XML règne encore

Banque et finance : Chaque fois que vous effectuez un virement bancaire en Europe, il y a de fortes chances qu'il passe par des messages ISO 20022 — qui sont en XML. Les rapports financiers utilisent XBRL (aussi du XML). On parle de milliers de milliards de dollars qui transitent par des tuyaux XML chaque jour.

Santé : HL7 FHIR utilise à la fois JSON et XML, mais les anciens messages HL7 v2/v3 sur lesquels fonctionnent la plupart des systèmes hospitaliers ? Du XML pur. Dossiers patients, résultats de laboratoire, ordonnances — tout en XML.

Vos documents Office : Chaque fichier .docx, .xlsx et .pptx est en réalité une archive ZIP remplie de fichiers XML. Ouvrez-en un un jour — c'est fascinant (et un peu effrayant).

Développement Android : Chaque fichier de layout Android est du XML. activity_main.xml est probablement le premier fichier que chaque développeur Android crée.

Outils de build : Le pom.xml de Maven, les fichiers .csproj de .NET, les configurations Spring Framework — XML est profondément ancré dans les chaînes d'outils d'entreprise.

Ce que XML peut faire et pas JSON

Espaces de noms : Imaginez combiner des éléments de vocabulaires différents dans un seul document sans collision de noms. Les espaces de noms XML rendent cela possible. C'est essentiel pour des formats comme SVG intégré dans du HTML, ou le mélange d'en-têtes SOAP avec des payloads personnalisés.

Contenu mixte : Essayez de représenter un paragraphe où certains mots sont en gras et d'autres en italique en JSON. C'est au mieux maladroit. XML gère cela naturellement parce qu'il a été conçu pour les documents, pas seulement pour les données.

Transformations XSLT : Vous pouvez écrire une seule feuille de style XSLT qui transforme du XML en HTML, PDF, un autre format XML ou du texte brut. C'est un langage de transformation déclaratif sans véritable équivalent dans le monde JSON.

Validation de schéma : XML Schema (XSD) est plus expressif que JSON Schema dans de nombreux domaines. Il peut imposer l'ordre des éléments, des hiérarchies de types complexes et des contraintes inter-champs avec lesquelles JSON Schema a du mal.

Un exemple concret

Supposons que vous construisez un système e-commerce qui doit générer des factures. Avec XML + XSLT, vous stockez les données de facturation en XML, puis appliquez différentes feuilles de style XSLT pour générer : une version HTML pour le navigateur, une version PDF pour l'impression et une version EDI pour le système du fournisseur — le tout à partir des mêmes données source. Essayez de faire ça avec JSON.

Les espaces de noms XML en action

Les espaces de noms sont une de ces fonctionnalités XML qui semblent déroutantes jusqu'à ce que vous en ayez vraiment besoin. Voici un exemple pratique — une icône SVG intégrée dans un document XHTML :

Sans espaces de noms, l'analyseur ne saurait pas si appartient au vocabulaire HTML ou au vocabulaire SVG. Les espaces de noms vous permettent de mélanger librement les vocabulaires dans un seul document, et c'est quelque chose pour lequel JSON n'a tout simplement aucun mécanisme.

Erreurs courantes que les développeurs font avec XML

Après des années de travail avec XML dans des systèmes de production, voici les pièges que je vois le plus souvent :

1. Ignorer les déclarations d'encodage. Si votre fichier XML contient des caractères non-ASCII mais que vous oubliez la déclaration d'encodage, les analyseurs supposeront UTF-8 ou leur valeur par défaut. Déclarez-le toujours explicitement :

2. Utiliser des attributs quand les éléments sont plus appropriés. Les attributs ne peuvent pas contenir de structures complexes, ne peuvent pas se répéter et ne peuvent pas évoluer facilement. Si une valeur risque de gagner en complexité plus tard, utilisez plutôt un élément enfant.

3. Ne pas valider contre un schéma. Faire circuler du XML non validé est la recette pour des échecs silencieux. Si vous avez un XSD, utilisez-le. Il détecte les problèmes de données au moment de l'analyse plutôt que de laisser les données erronées se propager dans votre système.

4. Construire du XML par concaténation de chaînes. Ne faites jamais ça — c'est une vulnérabilité d'injection qui n'attend que de se produire. Utilisez toujours une bibliothèque XML appropriée ou un constructeur DOM.

Conseils de performance pour le traitement XML

Les analyseurs XML se présentent sous deux formes principales, et choisir le bon est crucial pour la performance :

• Les analyseurs DOM chargent l'intégralité du document en mémoire sous forme d'arbre. Parfait pour les documents petits à moyens où vous avez besoin d'un accès aléatoire. Mauvais pour les gros fichiers — un fichier XML de 100 Mo peut consommer 1 Go+ de RAM sous forme d'arbre DOM.
• Les analyseurs SAX/StAX traitent le document comme un flux, un élément à la fois. Ils n'utilisent presque pas de mémoire et sont beaucoup plus rapides pour les gros fichiers. Le compromis est que vous ne pouvez pas naviguer dans le document.

Voici la règle d'or : si votre XML fait moins de 10 Mo, le DOM convient. Au-delà de 10 Mo, envisagez sérieusement le streaming. Au-delà de 100 Mo, le streaming est obligatoire, sauf si vous aimez regarder votre serveur manquer de mémoire.

XML vs JSON : Référence rapide

Une brève histoire de XML

XML a été publié comme recommandation du W3C en février 1998. Il a été conçu comme un sous-ensemble simplifié de SGML (Standard Generalized Markup Language), qui existait depuis les années 1980 mais était notoirement complexe. L'objectif était de créer un format à la fois lisible par les humains et analysable par les machines, suffisamment strict pour éviter les ambiguïtés, et suffisamment flexible pour n'importe quel domaine. Pendant la première décennie des années 2000, XML était *le* format d'échange de données. Services web SOAP, flux RSS, flux Atom, XHTML — tout était en XML. Puis JSON est arrivé et a pris le contrôle de l'espace des API web, mais XML a conservé chaque domaine où ses fonctionnalités uniques (espaces de noms, schémas, transformations) sont vraiment importantes.

Le développeur XML moderne

La plupart des développeurs travaillent aujourd'hui dans des environnements hybrides. Ils utilisent JSON pour les API web et la communication en temps réel, et XML pour le traitement de documents, l'intégration d'entreprise et la conformité réglementaire. Connaître les deux formats — et savoir quand utiliser chacun — est une compétence véritablement précieuse.

Sécurité XML : XXE et autres pièges

S'il y a une chose dans XML qui empêche les ingénieurs en sécurité de dormir, c'est XXE — les attaques XML External Entity. Et honnêtement, cela devrait vous préoccuper aussi. XXE figure sur la liste OWASP Top 10 pour de bonnes raisons, et cela continue de piéger des développeurs en 2026.

Voici comment fonctionne XXE : XML vous permet de définir des « entités » — essentiellement des variables — dans la déclaration de type de document (DTD). Une entité *externe* peut référencer une URL ou un chemin de fichier sur le serveur. Si l'analyseur est configuré pour résoudre les entités externes (beaucoup le sont par défaut), un attaquant peut créer du XML qui lit des fichiers arbitraires depuis votre serveur :

Quand l'analyseur traite ceci, il remplace &xxe; par le contenu de /etc/passwd. Comme ça, un attaquant lit des fichiers sensibles de votre système. Dans des attaques plus avancées, ils peuvent même faire des requêtes HTTP sortantes depuis votre serveur (Server-Side Request Forgery), ou provoquer un déni de service avec la fameuse attaque « billion laughs » — une expansion récursive d'entités qui consomme toute la mémoire disponible.

La solution est simple : désactivez le traitement des entités externes. Voici comment dans deux langages populaires :

Au-delà de XXE, méfiez-vous de l'injection XML — où l'entrée utilisateur est insérée dans du XML sans échappement approprié. C'est l'équivalent XML de l'injection SQL. Utilisez toujours une bibliothèque de construction XML appropriée au lieu de la concaténation de chaînes (ce que j'ai mentionné dans la section des erreurs courantes, mais ça vaut la peine de le répéter parce que c'est *vraiment* important).

La règle d'or : ne parsez jamais du XML non fiable avec les paramètres par défaut de l'analyseur. Désactivez toujours explicitement la résolution des entités externes, le traitement DTD et le traitement XInclude. Traitez le XML provenant du monde extérieur avec la même méfiance que vous accorderiez à une entrée utilisateur dans une requête SQL.

XPath : Interroger XML comme un pro

Si vous travaillez régulièrement avec XML et que vous n'utilisez pas XPath, vous vous compliquez la vie. XPath est un langage de requête spécialement conçu pour naviguer dans les documents XML, et il est incroyablement puissant une fois qu'on en a pris le coup.

Pensez à XPath comme les sélecteurs CSS mais pour XML. Au lieu de parcourir le DOM manuellement avec des boucles imbriquées, vous écrivez une expression concise qui sélectionne exactement les nœuds que vous voulez. Voici quelques exemples pratiques :

Voici comment utiliser XPath en JavaScript et Python — les deux langages vers lesquels la plupart des développeurs se tournent :

Une chose qui mérite d'être soulignée : JSON n'a pas de langage de requête intégré. L'équivalent le plus proche est jq, qui est fantastique mais reste un outil externe plutôt qu'une partie standardisée du format. XPath est intégré dans l'écosystème XML — supporté nativement par les navigateurs, disponible dans pratiquement tous les langages de programmation, et standardisé par le W3C. C'est l'un des véritables avantages concurrentiels de XML.

XPath forme également la base de XSLT (qui sélectionne les nœuds à transformer) et de XQuery (un langage de requête complet pour les bases de données XML). Une fois que vous maîtrisez XPath, vous avez déverrouillé toute une famille de technologies XML.

XML dans les standards spécifiques aux industries

J'ai mentionné la banque et la santé plus tôt, mais la portée de XML dans les standards industriels va bien plus loin. Voici un tour d'horizon des domaines où XML n'est pas seulement utilisé — il est *obligatoire* :

Juridique : L'industrie juridique s'appuie fortement sur XML pour les dépôts judiciaires et la gestion des dossiers. LegalXML, développé par OASIS, standardise le dépôt électronique, les citations juridiques et les métadonnées des dossiers. Aux États-Unis, de nombreux systèmes judiciaires étatiques imposent des formats de dépôt électronique basés sur XML. Si vous construisez de la legal tech, vous construisez sur XML.

Édition : Celle-ci surprend beaucoup de monde — chaque ebook EPUB que vous avez lu est construit sur XML. Les fichiers EPUB sont des archives ZIP contenant des fichiers de contenu XHTML (qui sont du XML), un descripteur de paquet OPF (XML) et un document de navigation (XML). DocBook, un autre format XML, est le standard de la documentation technique depuis les années 1990. O'Reilly Media a utilisé DocBook pendant des années pour produire leurs livres dans plusieurs formats de sortie à partir d'une seule source XML.

Science et mathématiques : MathML est le standard W3C pour la représentation de la notation mathématique en XML. Il est supporté par tous les navigateurs modernes et est essentiel pour les publications scientifiques sur le web. Il y a aussi Chemical Markup Language (CML) pour les structures moléculaires, Astronomical Markup Language pour les données stellaires, et des dizaines d'autres vocabulaires XML scientifiques. Quand la précision et la représentation non ambiguë des données comptent — et en science, c'est toujours le cas — XML est à la hauteur.

Gouvernement et marchés publics : Universal Business Language (UBL) est un standard OASIS utilisé par les gouvernements du monde entier pour les marchés publics, la facturation et la gestion de la chaîne d'approvisionnement. La directive de facturation électronique de l'Union européenne impose essentiellement du XML basé sur UBL pour la facturation entreprise-gouvernement. Si vous vendez à des gouvernements européens, vous envoyez des factures XML.

Aviation : L'Aeronautical Information Exchange Model (AIXM) définit des schémas XML pour les données aéronautiques — aéroports, espaces aériens, aides à la navigation, procédures. Chaque système de gestion de vol, chaque mise à jour du contrôle du trafic aérien, chaque NOTAM (Notice to Airmen) touche des données AIXM. C'est un domaine où « passons simplement à JSON » n'est pas une conversation que quiconque a, car les implications de sécurité d'une migration de format seraient énormes.

Le fil conducteur dans toutes ces industries ? Elles ont choisi XML parce qu'elles avaient besoin d'une validation forte, d'espaces de noms pour combiner des vocabulaires, et d'un format capable d'évoluer sur des décennies sans casser la rétrocompatibilité. Ces exigences n'ont pas changé.

SOAP vs REST : Pourquoi les API XML existent encore

Si vous avez commencé votre carrière dans la dernière décennie, vous pourriez penser que toutes les API sont REST avec JSON. Mais entrez dans n'importe quelle grande banque, compagnie d'assurance, opérateur télécom ou agence gouvernementale, et vous trouverez des services web SOAP gérant la logique métier critique. Et il y a de bonnes raisons à cela.

SOAP (Simple Object Access Protocol) est un protocole de messagerie basé sur XML avec certaines fonctionnalités que REST+JSON n'offre tout simplement pas d'emblée :

Contrats forts via WSDL : Un fichier WSDL (Web Services Description Language) décrit *tout* sur un service SOAP — opérations, structures de messages d'entrée/sortie, types de données, endpoints. Vous pouvez auto-générer du code client à partir d'un WSDL en Java, C#, Python ou pratiquement n'importe quel langage d'entreprise. Les API REST ont OpenAPI/Swagger, mais l'adoption est volontaire. Avec SOAP, le contrat est le service.

Gestion des erreurs intégrée : SOAP a un élément fault standardisé avec des codes d'erreur, des chaînes d'erreur et des éléments de détail. Chaque client SOAP sait exactement comment parser les erreurs. Les API REST ? Chaque API invente son propre format d'erreur.

WS-Security : SOAP a un standard de sécurité complet qui supporte le chiffrement et la signature au niveau du message — pas seulement au niveau du transport (TLS). Cela signifie qu'un message SOAP peut transiter par des serveurs intermédiaires tout en restant chiffré de bout en bout. C'est très important dans les services financiers où les messages transitent par plusieurs systèmes.

Transactions et fiabilité : WS-AtomicTransaction et WS-ReliableMessaging fournissent le support des transactions distribuées et la livraison garantie. Ce sont des problèmes difficiles que REST laisse entièrement au développeur de l'application.

Cela dit, SOAP a de vrais inconvénients : les messages sont verbeux, la courbe d'apprentissage est raide, le débogage est pénible, et la surcharge XML le rend plus lent que JSON pour les opérations CRUD simples. Pour les nouvelles API web et les microservices, REST+JSON est presque toujours le bon choix. Mais pour les intégrations d'entreprise complexes — surtout dans les industries réglementées — l'application des contrats et les fonctionnalités de sécurité intégrées de SOAP restent véritablement précieuses.

Migrer de XML vers JSON : Un guide pratique

À un moment de votre carrière, quelqu'un vous demandera de migrer un système basé sur XML vers JSON. Avant de dire « bien sûr, facile », laissez-moi vous montrer les pièges qui surprennent tout le monde.

Perte d'attributs : Les éléments XML peuvent avoir à la fois des attributs et des éléments enfants. Les objets JSON n'ont que des propriétés. En convertissant Dune, où va id ? Où va format ? Où va le contenu textuel ? Les conventions courantes utilisent des préfixes @ pour les attributs et #text pour le contenu textuel, mais il n'y a pas de standard universel — et quel que soit votre choix, l'autre système doit comprendre votre convention.

Coercition de types : XML est intrinsèquement basé sur du texte. La chaîne "42" en XML pourrait être un entier, un flottant, une chaîne ou un code postal. JSON a des types distincts. Lors de la migration, vous avez besoin de règles de mapping de types explicites, sinon vous vous retrouverez avec des chaînes là où vous vouliez des nombres (ou pire, des nombres là où vous vouliez des chaînes — adieu les zéros en tête dans les codes postaux).

Ambiguïté des tableaux : Celui-ci est particulièrement vicieux. En XML, si un élément a un enfant, c'est un élément unique. S'il a plusieurs enfants avec le même nom, ils forment naturellement une collection. Mais JSON doit savoir à l'avance si quelque chose est un tableau ou une valeur unique. Considérez : Widget — item est-il une chaîne ou un tableau à un élément ? Si une autre commande a trois items, la structure change. Votre consommateur JSON doit gérer les deux cas.

Étapes pour une migration réussie :

• Étape 1 : Inventoriez tous les schémas XML et documentez exactement quelles fonctionnalités vous utilisez (espaces de noms, attributs, contenu mixte, sections CDATA, instructions de traitement).
• Étape 2 : Concevez d'abord votre schéma JSON, en décidant explicitement comment gérer les attributs, le contenu mixte et les tableaux. Documentez chaque décision.
• Étape 3 : Construisez une couche de conversion (pas une réécriture totale). Faites tourner les deux formats en parallèle et comparez les sorties.
• Étape 4 : Migrez les consommateurs un par un, en gardant les endpoints XML actifs jusqu'à ce que tout le monde ait basculé.
• Étape 5 : Faites tourner les systèmes en parallèle pendant au moins un cycle métier complet (mois, trimestre ou année selon votre domaine) avant de décommissionner XML.

Quand NE PAS migrer : Si votre XML utilise intensivement le mélange de namespaces, les transformations XSLT ou les règles métier basées sur XPath, le coût de migration peut dépasser les bénéfices. Aussi, si votre XML est imposé par un standard réglementaire (HL7, ISO 20022, UBL), vous maintiendrez XML quoi qu'il arrive — ajouter JSON ne fait qu'ajouter un second format à supporter.

Outils XML que tout développeur devrait connaître

Travailler avec XML ne doit pas être douloureux si vous avez les bons outils. Voici ceux sur lesquels je compte :

xmllint : Livré avec libxml2 et probablement déjà sur votre système. Il valide le XML contre des schémas, formate (pretty-print) le XML et évalue des expressions XPath — le tout depuis la ligne de commande. C'est le curl du monde XML : simple, rapide et omniprésent.

Saxon : La référence absolue pour le traitement XSLT et XQuery, développé par Michael Kay (qui a littéralement édité les spécifications XSLT 2.0 et 3.0). Si vous faites des transformations XSLT sérieuses, Saxon est ce qu'il vous faut. L'édition Home open-source gère XSLT 3.0 et XPath 3.1.

XMLSpy (Altova) : Un IDE XML commercial populaire en entreprise. Il dispose d'éditeurs visuels de schémas, de débogueurs XSLT et d'intégration de bases de données. C'est cher mais puissant — particulièrement utile quand vous travaillez avec des schémas XSD massifs qui sont impossibles à modifier à la main.

oXygen XML Editor : Mon favori personnel pour le travail intensif avec XML. Il supporte le débogage XSLT avec exécution pas à pas, l'évaluation XPath, l'édition schema-aware avec auto-complétion, et a un excellent support DITA et DocBook. Si vous écrivez régulièrement du XSLT, oXygen se rentabilise en une semaine.

xmlstarlet : Un toolkit XML en ligne de commande qui vous permet d'interroger, modifier, valider et transformer du XML directement depuis le terminal. Pensez-y comme sed et awk mais pour XML. C'est parfait pour les scripts shell et les pipelines CI/CD où vous devez extraire des valeurs de fichiers de configuration XML ou modifier du XML à la volée.

Visual Studio Code avec les extensions XML : Si vous êtes déjà dans VS Code, l'extension « XML » de Red Hat vous offre la validation de schéma, l'auto-complétion et le formatage. Combinée avec l'extension « XSLT/XPath », c'est un setup gratuit étonnamment capable pour le travail occasionnel avec XML.

Essayez par vous-même

Besoin de faire le pont entre les deux mondes ? Notre Convertisseur XML vers JSON gère la transformation tout en préservant la structure et les types de données. Si vous déboguez du XML, le XML Formatter rend lisible même le XML le plus laid. Et avant de déployer du XML en production, passez-le dans le XML Validator pour détecter les problèmes structurels en amont.