Formater XML

XML (Extensible Markup Language) existe depuis plus de 25 ans, mais il reste tissé dans l'infrastructure des logiciels modernes : des documents Office et mises en page Android aux APIs SOAP, flux RSS, fichiers de configuration et workflows de préservation numérique. Ce n'est plus le favori—cette couronne est allée à JSON—mais XML reste critique là où la structure rigide, les métadonnées riches et l'interopérabilité à long terme comptent. L'objectif de cet article est d'expliquer XML en profondeur : d'où il vient, comment il fonctionne, comment nous le traitons et le validons, comment il se compare aux formats plus récents et comment l'utiliser de manière sûre et efficace en 2025 et au-delà.

1. Ce qu'est vraiment XML

XML est un langage de balisage simplifié pour représenter des données et documents structurés en utilisant des éléments et attributs imbriqués. Il est défini par la Recommandation Extensible Markup Language (XML) 1.0 du World Wide Web Consortium, qui spécifie la syntaxe pour les documents XML bien formés et décrit comment les processeurs doivent les traiter.

La spécification XML décrit XML comme un sous-ensemble restreint de SGML (Standard Generalized Markup Language), conçu pour être plus simple à implémenter tout en préservant le pouvoir central de SGML : représenter du texte structuré avec un balisage explicite.

Quelques propriétés clés rendent XML distinctif :

• Basé sur le texte et conscient d'Unicode. Les documents XML sont du texte brut et s'appuient sur les jeux de caractères Unicode/ISO 10646, ce qui les rend portables et indépendants de la langue.
• Auto-descriptif. Les noms de balises et attributs portent du sens. Aucun schéma séparé n'est requis pour comprendre fondamentalement la structure (bien que les schémas la rendent beaucoup plus puissante).
• Hiérarchique. La structure arborescente de XML correspond directement aux données imbriquées, documents et hiérarchies de configuration.
• Extensible. Vous inventez vos propres balises et vocabulaires; XML lui-même ne fixe pas l'ensemble des éléments autorisés.

2. Une brève histoire : de SGML à XML au web moderne

Les racines de XML se trouvent dans SGML, une norme ISO des années 1980 utilisée massivement dans l'édition et la documentation technique. Au milieu des années 1990, le HTML du web (lui-même basé sur SGML) était partout mais trop limité et étroitement couplé à la présentation.

Vers 1996–1997, un groupe de travail comprenant Jon Bosak, Tim Bray, C. M. Sperberg-McQueen, James Clark et d'autres a commencé à concevoir un sous-ensemble plus simple et adapté au web de SGML qui pourrait être analysé facilement et fiablement. La première Recommandation XML 1.0 a été publiée en 1998, et XML est rapidement devenu la base de nombreuses normes et protocoles du web précoce, notamment SOAP, WSDL, SVG, XSLT et de nombreux vocabulaires spécifiques à l'industrie.

Plus tard, XML 1.1 a affiné certains cas limites de gestion des caractères et caractères de contrôle, mais XML 1.0 reste la variante dominante en pratique.

3. Syntaxe XML centrale : documents bien formés

La spécification XML 1.0 définit une syntaxe précise pour les documents bien formés. Au minimum, un document XML bien formé :

• A exactement un élément racine.
• Utilise des balises de début et de fin correspondantes.
• Imbrique correctement les éléments (pas de balises qui se chevauchent).
• Utilise des valeurs d'attribut entre guillemets.
• Utilise des caractères et encodages légaux.

Un document minuscule mais valide pourrait ressembler à :

<?xml version="1.0" encoding="UTF-8"?>
<note>
  <to>George</to>
  <from>Adam</from>
  <message>Hello XML!</message>
</note>

La déclaration XML est optionnelle, mais c'est la manière conventionnelle d'indiquer la version et l'encodage des caractères. L'élément de document <note> est la seule racine. Les nœuds texte, éléments, attributs, commentaires, instructions de traitement et références d'entités forment ensemble la structure arborescente décrite dans la spécification.

XML distingue également entre les documents bien formés et valides :

• Un document bien formé suit les règles de syntaxe.
• Un document valide se conforme en outre à une DTD ou un schéma qui contraint sa structure et son contenu.

4. Espaces de noms : mélanger les vocabulaires en toute sécurité

Alors que les vocabulaires XML se multipliaient, les collisions de noms sont devenues un problème : un vocabulaire pourrait utiliser <title> pour un titre de livre ; un autre pour un titre de poste. Pour éviter les conflits, XML a introduit les espaces de noms, définis dans la Recommandation W3C Namespaces in XML.

Par exemple :

<book xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:title>XML in Depth</dc:title>
</book>

Ici, dc:title est distingué en toute sécurité de tout autre élément <title> en liant le préfixe dc à l'URI de l'espace de noms Dublin Core. Les espaces de noms sont cruciaux dans les écosystèmes XML modernes : XSD, XSLT, SOAP, RSS et Office Open XML s'appuient fortement sur eux.

5. Validation : DTDs, XML Schema et plus

5.1 DTDs

La spécification XML originale incluait Document Type Definitions (DTDs) comme méthode canonique pour définir la structure autorisée des documents—éléments, attributs, entités autorisés, etc. Les DTDs sont compactes et bien intégrées dans le prologue XML, mais elles sont limitées : elles utilisent une syntaxe non-XML, ont un typage faible et peinent avec les espaces de noms.

5.2 XML Schema (XSD)

Pour répondre aux limitations des DTD, le W3C a standardisé XML Schema Definition (XSD), maintenant en version 1.1, dans XML Schema Definition Language (XSD) 1.1 Part 1: Structures. XSD est lui-même écrit en XML, supporte les espaces de noms et fournit un typage riche (chaînes, nombres, dates, listes, unions), des contraintes d'occurrence et des modèles de contenu complexes.

D'autres langages de schéma existent—comme RELAX NG et Schematron—mais XSD reste le standard de facto dans de nombreux environnements d'entreprise et basés sur des normes.

5.3 Pourquoi la validation compte

La validation transforme XML de texte structuré en contrats entre systèmes. Par exemple :

• Les spécifications de messagerie financière définissent des schémas stricts pour les instructions de paiement.
• Des normes comme Office Open XML et RSS formalisent leurs formats de document avec des schémas.
• Les outils de construction et de configuration valident des fichiers comme pom.xml ou web.config pour détecter les erreurs tôt.

6. Traitement XML : DOM, SAX et streaming

XML en lui-même n'est que du texte. Pour faire quelque chose d'utile, le logiciel doit l'analyser dans un modèle. Les deux modèles de traitement classiques sont DOM et SAX.

6.1 DOM : arbre en mémoire

La spécification DOM Level 3 Core du W3C définit un modèle d'objets neutre en langage représentant un arbre de document complet, avec des nœuds pour les éléments, attributs, texte, commentaires et plus. DOM est convivial pour l'accès aléatoire, facile à raisonner et largement supporté dans les bibliothèques, mais il nécessite que tout le document soit maintenu en mémoire.

6.2 SAX : streaming basé sur les événements

La Simple API for XML (SAX) est une API basée sur les événements qui analyse XML comme un flux et déclenche des callbacks pour des événements comme "début d'élément" ou "fin d'élément". Elle est décrite sur le site du projet SAX et dans le tutoriel Oracle SAX.

SAX traite les documents en une seule passe sans stocker tout l'arbre, ce qui le rend extrêmement efficace en mémoire et idéal pour les grands flux comme les journaux, le traitement de messages ou les transformations par lots. Les APIs de streaming basées sur pull comme StAX suivent des principes similaires.

7. XPath, XSLT et XQuery : interroger et transformer XML

7.1 XPath

XPath est un langage de requête compact pour adresser des parties d'un document XML en utilisant des expressions de type chemin comme /bookstore/book[1]/title. La dernière version, définie dans XPath 3.1, étend le modèle pour également gérer les données JSON via les maps et arrays et est soutenue par un grand ensemble de fonctions standard.

XPath est intégré dans de nombreux outils : XSLT, XQuery, assertions XML Schema et APIs dans les langages de programmation populaires.

7.2 XSLT

XSL Transformations (XSLT) est un langage déclaratif pour transformer XML en d'autres formats—XML, HTML, texte ou même JSON dans les processeurs modernes. La Recommandation XSLT 3.0 du W3C définit un système basé sur des modèles qui s'appuie sur XPath pour la correspondance de motifs et la sélection.

Les feuilles de style sont elles-mêmes des documents XML utilisant l'espace de noms XSLT. XSLT 3.0 ajoute des capacités de streaming pour d'énormes documents et une intégration améliorée avec JSON et les maps.

7.3 XQuery

XQuery est un langage de requête complet pour les dépôts XML, défini dans XQuery 3.1. Il est conçu pour interroger et transformer des collections de données XML, souvent stockées dans des bases de données XML natives ou des magasins de documents, et utilise des expressions FLWOR (for, let, where, order by, return) pour générer des ensembles de résultats puissants.

Ensemble, XPath, XSLT et XQuery forment une boîte à outils riche pour travailler avec XML à grande échelle, en particulier dans les contextes de publication, humanités numériques, e-gouvernement et intégration de données.

8. Utilisations réelles de XML aujourd'hui

Même si JSON domine les APIs web, XML est toujours profondément intégré dans de nombreux systèmes et normes.

8.1 Formats et normes de documents

• Office Open XML (OOXML). Les documents Microsoft Office modernes (.docx, .xlsx, .pptx) sont des packages ZIP de fichiers XML définis par ECMA-376 Office Open XML et les normes ISO connexes.
• Préservation numérique. Des institutions comme la Bibliothèque du Congrès traitent XML (en particulier XML 1.0) comme un format stable et favorable à la préservation pour représenter du contenu numérique structuré.
• Balisage académique et technique. TEI, DocBook et d'autres vocabulaires spécifiques au domaine sont basés sur XML, permettant un balisage sémantique et un archivage à long terme.

8.2 Messagerie et services web

• SOAP. La spécification SOAP 1.2 du W3C définit une enveloppe basée sur XML pour échanger des messages structurés sur des protocoles comme HTTP.
• RSS et syndication. La spécification RSS 2.0 définit un format XML pour la syndication de flux, encore largement utilisé pour les blogs, actualités et flux de produits.

8.3 Configuration et systèmes de construction

• POMs Maven. Le Project Object Model d'Apache Maven (pom.xml) est un fichier XML décrivant les métadonnées du projet, dépendances, plugins et configuration de construction, documenté dans la Référence POM et Introduction au POM.
• Configuration XML Spring Framework. Les applications Spring traditionnelles définissent souvent des beans et le câblage dans des fichiers applicationContext.xml ou beans.xml, une approche encore décrite dans la documentation de référence Spring et des tutoriels comme Java Guides.
• Configuration .NET. ASP.NET et WCF s'appuient sur des fichiers web.config et app.config formatés en XML pour configurer les points de terminaison, liaisons et comportements, comme décrit dans la documentation web.config de Microsoft et la guide de configuration WCF.

Plus généralement, XML reste un format de configuration commun lorsque la validation et les outils sont importants, en particulier avec des schémas soutenus par XSD.

8.4 Mises en page mobiles et UI

Dans Android, les mises en page UI sont typiquement déclarées dans des fichiers XML sous res/layout. La documentation de Google explique que vous écrivez des mises en page en utilisant le vocabulaire XML d'Android pour imbriquer des vues de manière similaire à HTML, chaque fichier de mise en page contenant un seul élément racine.

9. XML vs JSON vs YAML

En 2025, JSON a clairement gagné le concours de popularité pour les APIs web : un article de comparaison récent estime JSON à environ 87% des réponses d'API web, avec XML à 9% et YAML à 4%.

9.1 Forces de XML

Comparé à JSON et YAML, XML brille quand vous avez besoin de :

• Schémas riches et validation forte. XSD vous permet de spécifier des types complexes, contraintes et relations, et a un écosystème mature d'outils et validateurs.
• Contenu mixte et documents. XML a été construit pour des documents riches en texte où le balisage et le texte s'entrelacent ; JSON et YAML sont meilleurs pour les données purement structurées.
• Métadonnées profondes et extensibilité. Les espaces de noms et schémas permettent des documents tolérants aux versions où des éléments et attributs optionnels peuvent être ajoutés sans casser les consommateurs plus anciens.

9.2 Forces de JSON et YAML

JSON est plus simple à lire et écrire, mappe naturellement aux objets JavaScript et est plus petit sur le fil. Les tutoriels indiquent fréquemment que JSON omet les balises de fin, est plus concis et peut être analysé nativement dans les navigateurs sans un analyseur XML dédié.

YAML met l'accent sur la lisibilité humaine pour la configuration et est populaire dans les outils DevOps comme Kubernetes et Ansible, bien que sa complexité et sa sensibilité à l'indentation puissent introduire des erreurs.

9.3 Choisir le bon format

Les conseils modernes tendent à être :

• Utilisez JSON pour la plupart des APIs web et la communication client-serveur.
• Utilisez YAML pour la configuration centrée sur les développeurs dans les environnements cloud/DevOps.
• Utilisez XML lorsque vous avez besoin de documents basés sur des schémas, de contenu mixte, d'écosystèmes XML existants (SOAP, OOXML, WCF, mises en page Android) ou d'archivage à long terme où la standardisation et les outils sont matures.

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

La flexibilité de XML vient avec des bords tranchants, particulièrement autour des entités externes et DTDs. La Feuille de référence de prévention XML External Entity (XXE) d'OWASP documente comment les vulnérabilités XXE permettent aux attaquants de lire des fichiers locaux, effectuer une falsification de requête côté serveur ou causer un déni de service en exploitant l'expansion d'entité.

Les vecteurs d'attaque courants incluent :

• Entités externes référençant des ressources locales ou distantes.
• Entités de paramètre dans les DTDs qui s'étendent en charges utiles énormes.
• Récupération de DTD sur des réseaux non fiables.

Les conseils de mitigation recommandent généralement :

• Désactiver les DTDs et entités externes dans les analyseurs chaque fois que possible.
• Utiliser des paramètres d'analyseur durcis ou des bibliothèques sécurisées qui suivent les recommandations OWASP.
• Valider contre les schémas sans activer les fonctionnalités risquées.

D'autres considérations de sécurité incluent des documents surdimensionnés (épuisement des ressources), l'injection XPath/XQuery dans les systèmes qui construisent des requêtes à partir de l'entrée utilisateur, et les fichiers de configuration basés sur XML mal configurés menant à l'escalade de privilèges ou l'exécution de code.

11. Conception et meilleures pratiques pour XML

Utilisé judicieusement, XML reste un moyen propre et robuste de modéliser les données et documents. Quelques lignes directrices pratiques :

• Modélisez un arbre clair. Concevez votre XML autour d'un arbre conceptuel stable (par exemple, <invoice> → <lineItems> → <lineItem>) plutôt que de refléter directement un schéma relationnel.
• Choisissez éléments vs attributs intentionnellement. Utilisez des éléments pour le contenu principal et les structures ; utilisez des attributs pour les métadonnées et les drapeaux.
• Utilisez des espaces de noms dès le début. Même pour de petits vocabulaires, assigner un espace de noms (par exemple, xmlns="https://example.com/ns/invoice") évite des migrations douloureuses plus tard.
• Soutenez votre format avec un schéma. Fournissez XSD (ou un autre langage de schéma) et traitez-le comme faisant partie de votre contrat public. Utilisez la validation de schéma dans CI et aux points d'intégration.
• Gardez-le inspectable par les humains. Le formatage joli et les commentaires aident au débogage, à la configuration et à la maintenance à long terme.
• Séparez les données de la présentation. Utilisez XML pour la structure et le sens, et transformez-le en HTML, PDF ou d'autres formats avec XSLT ou d'autres outils.
• Choisissez des modèles de traitement appropriés. Pour les documents petits à moyens et les requêtes complexes, DOM + XPath/XSLT peut être idéal ; pour les très grands flux ou environnements contraints, utilisez SAX, StAX ou le traitement basé sur les événements.
• Durcissez les analyseurs. Suivez les conseils de prévention XXE d'OWASP et les meilleures pratiques de sécurité de votre langage lors de l'analyse d'entrée non fiable.

12. Le rôle futur de XML

Dans le développement web quotidien, XML a largement cédé le centre de la scène à JSON et YAML. Mais dans de nombreux domaines—intégration d'entreprise, normes de documents, gestion de configuration, préservation numérique et systèmes hérités—réécrire tout en formats plus récents est soit inviable soit indésirable.

Les organismes de normalisation comme W3C et Ecma maintiennent toujours des spécifications basées sur XML comme XML 1.x, XML Schema, XPath, XSLT, XQuery, SOAP et OOXML, et des institutions comme la Bibliothèque du Congrès continuent de traiter XML comme un cheval de bataille d'archivage.

Pour les développeurs, cela signifie que vous interagirez probablement avec XML chaque fois que vous touchez des fichiers Office, des mises en page Android, de nombreuses piles d'entreprise Java, la configuration .NET, des services SOAP/WSDL plus anciens ou l'échange de données basé sur des normes. Comprendre la syntaxe, les espaces de noms, les schémas et les modèles de traitement de XML reste une compétence précieuse, surtout si vous travaillez dans l'intégration, l'infrastructure ou les systèmes de longue durée.

XML n'est peut-être plus la star des APIs web modernes, mais c'est toujours une base solide, bien spécifiée et fortement outillée pour une énorme quantité de logiciels. L'apprendre en profondeur paie chaque fois que vous avez besoin de schémas forts, de documents riches ou de naviguer dans le vaste paysage des normes existantes basées sur XML.