XML est un espéranto trop verbeux. Ce constat, partagé tant par les utilisateurs que par les industriels, nécessite de rendre le langage plus compact. Selon le contexte, l'enjeu consiste à optimiser l'espace de stockage ou à accélérer les échanges de services web qui transitent sur internet. Deux grandes solutions de compression s'imposent : l'une au niveau de l'infrastructure, l'autre au niveau applicatif. Aujourd'hui, les entreprises préfèrent la première approche, car elle seule assure la transparence nécessaire à l'exploitation de ce langage.

Le CHU de Grenoble connaît bien le problème. Très tôt, il a misé sur le format du consortium W3C. « Pour les échanges avec les personnes extérieures à l'hôpital, nous avons décidé de compresser les fichiers XML à l'aide du protocole de transport HTTP 1.1 » , précise François Talbot, architecte technique au CHU.

Cela s'avère bien pratique pour les médecins de ville, qui ne disposent généralement que d'une connexion à bas débit. Cette solution présente l'avantage de ne requérir aucun développement sur les postes clients. Au final, les temps de réponse ne sont toutefois pas meilleurs. Le temps gagné lors des transferts, dû à des fichiers moins volumineux, est perdu par les opérations de compression et de décompression.

Pour alléger les fichiers XML, il est également possible de recourir au système d'exploitation (local ou réseau selon le cas), ou encore un outil de compression qui travaille au niveau du fichier et non pas sur son contenu. C'est le cas de programmes tels que Winzip ou Gzip. Cette approche présente un inconvénient : tant que les données sont compressées, l'application cliente ignore la nature du fichier, à moins qu'elle sache reconnaître un fichier XML comprimé. « Cela ne pose pas de problème pour des besoins de sauvegarde, par exemple » , estime Jean-Marie Gouarné, directeur technique de la SSII Genicorp.

En restant au niveau de l'infrastructure, on peut aussi recourir à des matériels dédiés à l'optimisation des flux XML. Une approche développée par des start up telles que Datapower et Sarvega. Celles-ci seront bientôt rejointes par Cisco, qui compte se positionner sur ce marché naissant. A la différence des outils de compression classiques, ces boîtiers spécialisés sont suffisamment intelligents pour distinguer les balises du contenu. Ils sont ainsi capables de ne compresser que le contenu, sans toucher à la structure du document. Ce qui rend cette solution particulièrement intéressante pour alléger les services web.

L'autre façon de rendre XML moins bavard consiste à compresser ­ et décompresser ­ l'intégralité des fichiers XML au niveau applicatif, le résultat compacté restant en XML. Là encore, on réduit considérablement le volume des fichiers. Mais cette méthode souffre de grosses lacunes. Ainsi, le format d'enregistrement doit être reconnu par toute la chaîne applicative.

Ce qui n'est pas le cas aujourd'hui, à l'exception des entreprises qui travaillent avec des applications très propriétaires. Exemple. L'échange de documents XML entre la suite bureautique Open Office (ou son pendant commercial Star Office) et Office 2003, de Microsoft est impossible. Seule la première comprime les fichiers.

Une autre raison, indépendante de la compression, tient à l'utilisation de grammaires différentes pour décrire les schémas de données. La préfecture de police de Paris a été confrontée au problème. Alors qu'elle souhaite recourir à XML pour échanger et accéder à ses données, elle est pénalisée par le peu d'interopérabilité des documents bureautiques.

« Nous souhaitons progressivement convertir nos fichiers RTF en XML. Mais le premier format est mieux reconnu par les différents traitements de texte du marché » , déplore Sylvain Bellengier, responsable d'équipe du système d'information.

Autre écueil : la lourdeur de XML. Les performances se dégradent nettement dès que les fichiers dépassent 5 Mo. Résultat : la préfecture ne trouve pas, pour l'instant, de solution satisfaisante pour utiliser pleinement XML. Cette approche au niveau applicatif pénalise également la puissance de calcul. Pour exploiter un fichier, l'application doit connaître la sémantique de la structure du document. Ce qui implique de décompresser systématiquement l'intégralité du document.

D'où la naissance d'une approche, plutôt applicative. Elle consiste à compresser un document XML sans perdre sa structure. Le résultat obtenu est un fichier binaire. Et les performances s'améliorent, car l'application cible la seule donnée qu'elle doit compresser ou décompresser. Revers de la médaille : la réduction du volume du fichier est généralement moins importante que celle obtenue avec un algorithme classique.

Dans ce domaine, il existe quelques technologies peu connues, en cours de développement : Xmill, Millau, Xcomp, etc. D'autres travaux se focalisent sur cette approche de façon à améliorer les performances des services web. Ainsi, la prochaine version du serveur d'applications de Sun mettrait en oeuvre une sérialisation ­ soit la transformation d'un fichier XML en un format binaire tel que Zip, bâtie sur la technologie Fast Infoset. Solution loin d'être partagée par IBM et Microsoft.

Aujourd'hui, la sérialisation binaire convient lorsque les services web fonctionnent dans un environnement homogène, mais elle pose des problèmes dans le cas contraire. La branche Asset Management du Crédit Agricole a expérimenté cette technique. Pour ses besoins de reporting financier, l'entreprise arbitre entre la lourdeur de XML ­ en phase de création et de lecture ­ et l'absence de modularité des fichiers de type CSV (Comma Seperated Values). Un choix qui se fait au cas par cas, et souvent en faveur de XML. « Parfois, nous sérialisons les informations financières rapportées afin d'optimiser la taille des messages Soap » , détaille David Bellaiche, responsable de la gestion d'actifs. Il fonctionne bien dans la banque, car mis en oeuvre dans un environnement homogène.

Aujourd'hui, la cacophonie autour de l'approche applicative est telle, que le consortium W3C décidera, cet été, d'ouvrir ou non la création d'un format binaire de XML. S'il démarre ce chantier, les industriels devront s'entendre sur les interfaces de programmation capables de l'exploiter. Deux années, au moins, seraient alors nécessaires pour se mettre d'accord. Avec pour conséquence, de modifier la nature même de XML, aujourd'hui textuelle. Et le risque de tuer ce qui a fait son succès : l'interopérabilité des données.