Le format XML a beau être régulièrement déclaré obsolète au profit de JSON, il continue d’alimenter des flux critiques dans la plupart des projets data. Fichiers Office Open XML, flux RSS, manifestes Android, échanges SOAP entre systèmes legacy : parse XML using Python reste une opération courante, y compris en 2026.
La vraie question n’est pas de savoir si XML va disparaître, mais si les outils Python actuels sont à la hauteur des exigences de sécurité et de performance qu’imposent les pipelines de données modernes.
Vulnérabilités récentes du parsing XML Python : ce qui a changé en 2026
L’actualité sécurité de l’été 2026 a mis en lumière des failles concrètes dans les bibliothèques de parsing XML les plus utilisées en Python. Deux bulletins méritent une attention particulière pour quiconque manipule du XML dans un projet data.
La vulnérabilité référencée CVE-2026-6879 concerne directement xml.etree.ElementTree, le module standard de Python. Des requêtes XPath contenant des prédicats d’index peuvent provoquer une consommation CPU quadratique lorsque le document XML comporte un grand nombre de nœuds frères portant le même nom. Sur un pipeline data qui filtre du XML non fiable (flux partenaires, imports tiers), ce type de faille ouvre la porte à un déni de service sans qu’aucune attaque sophistiquée ne soit nécessaire.
Côté lxml, un bulletin IBM Security publié début août 2026 a signalé une vulnérabilité d’accès local à des fichiers via la configuration par défaut du parseur. La note de publication Python du 13 août 2026 a intégré des correctifs sur parsers.expat pour le XML profondément imbriqué. Ces deux éléments confirment que le parsing XML Python reste une surface d’attaque active, pas un sujet clos.
defusedxml comme point de départ pour parser du XML externe en Python
La recommandation technique s’est nettement durcie en 2026. Avant même de choisir entre ElementTree et lxml, les retours terrain convergent vers un prérequis : utiliser defusedxml pour tout XML provenant d’une source externe. Cette bibliothèque désactive par défaut les entités externes (XXE), limite la profondeur d’imbrication et bloque les constructions DTD potentiellement dangereuses.
La logique est simple. ElementTree et lxml sont des parseurs, pas des outils de sécurité. Leur configuration par défaut autorise des comportements qui, appliqués à du XML non contrôlé, peuvent exposer des fichiers locaux ou saturer les ressources serveur.
Un projet data qui ingère du XML devrait suivre un minimum de précautions :
- Passer systématiquement par
defusedxmlpour le parsing initial, avant tout traitement métier sur les données extraites - Désactiver explicitement la résolution des entités externes, même si le parseur sous-jacent est
lxmlavec ses bindings C - Valider les flux entrants contre un schéma XSD quand la structure est connue, pour rejeter les documents malformés avant qu’ils n’atteignent la couche d’extraction
- Limiter la profondeur d’imbrication et la taille maximale du document au niveau du parseur, pas seulement au niveau réseau
Performance du parsing XML Python : ElementTree, lxml et les alternatives C++
Pour les petits fichiers (quelques centaines d’éléments), xml.etree.ElementTree reste fonctionnel. Le module est intégré à la bibliothèque standard, ne nécessite aucune dépendance et couvre les cas simples de lecture et d’extraction de données.
En revanche, dès que le volume augmente, ElementTree devient un goulot d’étranglement. Le module construit un objet Python complet pour chaque nœud, chaque attribut et chaque nœud texte de l’arbre. Sur un fichier XML volumineux, la consommation mémoire et le temps de parsing grimpent de façon linéaire, voire pire avec certaines requêtes XPath (cf. la vulnérabilité CVE-2026-6879 mentionnée plus haut).
lxml, qui encapsule la bibliothèque C libxml2, offre des performances nettement supérieures et un support XPath complet. Le compromis : une dépendance binaire supplémentaire et une chaîne de compilation qui peut compliquer le déploiement sur certains environnements contraints.
Pour les cas où la vitesse de parsing est le facteur limitant du pipeline, des wrappers C++ existent et ciblent l’ingestion de flux XML massifs en batch avec une empreinte mémoire réduite.
Quel parseur pour quel usage data
| Parseur | Inclus en standard | Support XPath | Adapté aux gros fichiers |
|---|---|---|---|
| xml.etree.ElementTree | Oui | Partiel | Non |
| lxml | Non | Complet | Oui |
| defusedxml | Non | Via backend | Sécurité avant performance |
XML face à JSON dans les projets data Python : une coexistence durable
Le débat XML contre JSON est souvent posé comme un choix binaire. Dans la réalité des projets data, les deux formats coexistent et le choix du format dépend rarement du développeur. Les API REST modernes privilégient JSON. Les systèmes legacy, les flux réglementaires, les formats documentaires (DOCX, SVG, JATS XML pour l’édition scientifique) imposent XML.
JSON est plus léger à parser, plus lisible pour un humain, et mieux intégré à l’écosystème Python via le module standard json. XML, en contrepartie, supporte nativement les espaces de noms, les schémas de validation (XSD, RelaxNG) et les requêtes de traversée complexes via XPath. Pour un projet data qui doit valider la conformité structurelle d’un document avant ingestion, XML offre des garanties que JSON Schema n’atteint pas encore avec la même maturité.
La question pertinente pour un projet data en 2026 n’est donc pas « faut-il parser du XML » mais « comment le parser sans introduire de dette technique ni de risque de sécurité ». Les retours disponibles montrent que négliger le durcissement du parseur est le premier facteur de dette technique XML dans les pipelines Python.
Checklist de durcissement pour parser du XML en Python en 2026
Pour un pipeline data qui consomme du XML, la configuration du parseur mérite autant d’attention que le code d’extraction lui-même. Voici les points à vérifier :
- Installer et utiliser
defusedxmlcomme couche d’entrée pour tout flux XML externe, avant de transférer les données verslxmlouElementTreepour le traitement - Mettre à jour Python vers les versions corrigées les plus récentes, qui patchent les vulnérabilités sur
parsers.expat - Auditer les requêtes XPath utilisées dans le pipeline : les prédicats d’index sur des documents à nœuds frères nombreux sont un vecteur de consommation CPU excessive
- Définir des limites explicites de taille et de profondeur au niveau du parseur, pas uniquement au niveau du reverse proxy ou du serveur web
Parser du XML en Python en 2026 reste une compétence opérationnelle, pas un archaïsme. Ce qui a changé, c’est le niveau d’exigence sur la sécurité du parsing. Les failles documentées cet été montrent que traiter le parseur XML comme un composant transparent, sans configuration de durcissement, expose les projets data à des risques concrets et documentés.
