Open XML ou comment faire d'une bonne spécification un mauvais standard, par Jean-Marie Gouarné

La guerre des formats bureautiques s'emballe. Le 14 février 2007, en réaction aux difficultés rencontrées dans le processus d'adoption du format ECMA 376 Office Open XML comme standard ISO, Microsoft a publié, sous le titre "Interoperability, Choice and Open XML"(1), un communiqué d'une rare véhémence, digne d'une polémique de campagne électorale. Ce document évite les détails techniques et place clairement le débat sur le terrain stratégique et politique.

L'exposé commence par un rappel des engagements de Microsoft en faveur de l'ouverture et de l'interopérabilité, dont le plus marquant a été la publication du format Office Open XML, adopté par l'ECMA en décembre 2006. Jusque là, rien de très nouveau.

L'histoire se corse dans la dernière partie, sous le titre "Open XML and ISO Standardization", qui démontre que les quelques oppositions rencontrées sur la route de la standardisation au cours des semaines précédentes ont été particulièrement mal digérées à Redmond. Les auteurs, Tom Robertson et Jean Paoli, se sont départis du ton très politiquement correct employé jusque là et se sont livrés à une dénonciation explicite et virulente de ce qu'ils considèrent comme un complot orchestré par IBM en vue de restreindre la liberté de choix des utilisateurs et de faire obstacle à l'innovation en imposant au marché un format unique, en l'occurrence le format OpenDocument (ODF), déjà passé au rang (décidément très recherché) de standard ISO(2).

Certains se contenteront de hausser les épaules et de dire "laissons les loups se manger entre eux". D'autres pourront trouver plaisant de voir Microsoft se poser en apôtre du libre choix et de l'innovation concurrentielle dans un marché qu'il contrôle à plus de 90% et dans lequel il s'emploie assidûment depuis plus de 15 ans à éliminer toute forme de compétition. Cependant, l'attentisme cynique et l'ironie facile ne sont pas les meilleurs moyens de comprendre les vrais enjeux de la partie et de savoir à quelle sauce on s'apprête à nous manger.

OpenDocument, Open XML et IBM

IBM est donc montré du doigt comme l'instigateur d'une opération d'influence aussi vaste que malfaisante contre Open XML. Passons sur la drôlerie de cette indignation venant d'une puissance comme Microsoft, que nul ne croit innocente et désarmée dans le maquis du lobbying, et demandons-nous plutôt quels sont les intérêts du Grand Bleu dans cette affaire.

On sait que la spécification OASIS OpenDocument (ODF) a pour origine le projet OpenOffice.org qui est lui-même, pour l'essentiel, une émanation de Sun Microsystems, c'est-à-dire d'un concurrent direct d'IBM. Il est cependant notoire que Sun apparaît de moins en moins comme le protagoniste majeur du débat actuel sur les formats bureautiques et qu'IBM est devenu le véritable chef de file du courant favorable à ODF. Cette évolution, devenue plus visible depuis la création de l'ODF Alliance(3) au début de 2006, prolonge une autre réalité : après avoir mis en orbite le projet OpenOffice.org, issu du rachat de la société hambourgeoise StarDivision, Sun ne l'a jamais véritablement intégré à sa stratégie, et ce en dépit des déclarations faites par Scott McNeally en 1999-2000. D'ailleurs, durement éprouvé par l'éclatement de la bulle internet, focalisé sur la défense de ses positions dans le monde des serveurs et du stockage, déjà très occupé à mettre de l'ordre dans le foisonnement de ses précédentes acquisitions dans le logiciel, le constructeur de Santa-Clara pouvait-il vraiment s'offrir le luxe d'une offensive de grande envergure sans espoir de rentabilité dans la chasse gardée de Microsoft ? C'est alors qu'IBM entre en scène.

On pourrait être tenté de voir dans la "croisade" contre Open XML la manifestation d'une volonté de revanche consécutive à la mésaventure humiliante subie naguère par IBM du fait de Microsoft. Une mésaventure dont la conséquence ultime a été l'abandon du marché du PC par Big Blue. Certes, les facteurs irrationnels de ce type jouent parfois un rôle, comme en témoigne l'acharnement passionnel avec lequel Ray Noorda, ancien patron de Novell, a jadis employé les ressources de son entreprise dans une lutte aussi vaine que coûteuse contre Microsoft. Ces facteurs ne sont peut-être pas totalement étrangers au militantisme d'IBM en faveur d'ODF, mais on aurait tort d'en exagérer l'influence. Le passé récent démontre d'ailleurs qu'IBM est parfaitement capable de travailler main dans la main avec Microsoft (et vice-versa) dans d'autres domaines très concurrentiels de la standardisation (notamment l'orchestration des services web, qui constitue l'un des piliers du modèle SOA). La motivation principale est ailleurs : IBM est en passe de déployer sur le marché une offre qui s'inscrit en rupture avec les concepts fondamentaux de la bureautique du siècle dernier, concepts qui sont encore au coeur de l'architecture de Microsoft Office 2007 et même, dans une large mesure, de la version actuelle d'OpenOffice.org. Mais quel rapport entre l'architecture d'un logiciel bureautique et le format dans lequel il enregistre les documents ? Dans un monde parfaitement rationnel, aucun. Mais la bureautique des années 90 est à peu près tout ce qu'on veut sauf un monde rationnel. Et c'est là que le bât blesse avec Open XML. L'un des principes essentiels (et peut-être le plus essentiel) du format proposé par Microsoft et par l'ECMA est la traduction directe et fidèle des informations jusqu'à présent mémorisées sous forme de fichiers binaires, dans des formats propriétaires, par les logiciels présents et passés de la suite Microsoft Office.

Cette fidélité au passé, quelle que soit sa valeur relativement aux usages d'aujourd'hui, s'inscrit en opposition avec la bureautique du futur, ou "Bureautique 2.0" pour reprendre l'expression de Louis Naugès(4), telle que la conçoivent IBM et quelques autres, notamment Google. Cette nouvelle bureautique, adossée à la plate-forme web, ne peut se développer que dans un monde de formats et de protocoles simples, faciles à mettre en oeuvre au moindre coût et surtout indépendants de toute référence aux plates-formes du passé. Trop lourdement marqué par l'histoire, Open XML n'est pas taillé pour cette nouvelle course, tandis qu'OpenDocument, sans avoir le profil idéal, est tout de même sensiblement mieux adapté, et surtout moins pénalisant pour les nouveaux entrants. C'est en tout cas un point de vue qui, depuis quelque temps, prévaut chez IBM, où l'on considère les fondements de l'offre bureautique de Microsoft et tout ce qui s'y rattache comme relevant d'un modèle "pré-internet", encore omniprésent mais condamné à moyen terme(5). Ce point de vue est très décalé par rapport à la réalité historique de la suite Lotus, qui n'est pas un exemple de modernité et de respect des standards ; il ne représente pas moins la stratégie déclarée d'IBM sur le front du poste de travail, une stratégie qui s'appuie désormais sur la plate-forme Lotus Workplace à base de technologies Java et Eclipse et qui, depuis peu, intègre OpenDocument.

Les limites d'une théorie du complot

Dans une certaine mesure, IBM a donc un intérêt réel à pencher pour le format de l'OASIS et contre celui de l'ECMA. Mais de là à échafauder une théorie du complot, il y a un pas que Tom Robertson et Jean Paoli franchissent un peu trop vite. D'abord, OpenDocument bénéficie du soutien d'acteurs très nombreux et dont beaucoup ne sont pas franchement suspects de soumission inconditionnelle aux diktats d'IBM. Même si IBM est le seul participant à avoir voté contre la validation au sein de l'ECMA, il est vrai également que cette même ECMA avait reçu en décembre 2005 une lettre de la Computer & Communications Industry Association (CCIA) dénonçant le projet Office Open XML comme "non conforme aux conditions fondamentales de l'ouverture"(6); il n'est pas inutile de rappeler que Google est membre de la CCIA, aux côtés de Fujitsu, de Red Hat et de quelques autres. Il est vrai que la CCIA ne pèse pas lourd, mais il serait cependant exagéré d'en conclure qu'IBM était le seul grand acteur opposé à Open XML. Ensuite et surtout, accuser ainsi IBM, sans avancer d'éléments factuels, de fausser les mécanismes de la standardisation internationale revient à soupçonner les organismes de standardisation d'être un peu trop réceptifs aux instructions de Big Blue. C'est donc, implicitement, entretenir un doute sur leurs compétences et leur impartialité. Ce terrain est extrêmement glissant, car d'autres pourraient retourner l'argument en s'intéressant aux circonstances dans lesquelles Open XML a été, à la demande de Microsoft, adopté par l'ECMA.

Le processus de normalisation, à l'échelon national (avec des agences comme l'AFNOR en France) comme à l'échelon international (ECMA, OASIS, W3C, ISO, etc) est nécessairement imparfait et possède les défauts de ses qualités. Les fournisseurs en position dominante (dont Microsoft et IBM) y jouent un rôle essentiel, et c'est une bonne chose car il serait vain de discuter de standards qui ne tiennent pas compte de leur point de vue. Les utilisateurs (y compris les gouvernements) attendent d'eux qu'ils se mettent d'accord sur des positions communes, en sachant très bien que chacun cherche à ménager ses propres intérêts commerciaux. Cela fonctionne souvent assez bien. Mais Open XML est un dossier explosif sur lequel, manifestement, le consensus ne peut pas être atteint. Il est donc inévitable que la discussion technique s'efface devant la politique et que chacun utilise les canaux d'influence (officiels et souterrains) dont il dispose. En dénonçant une "campagne globale", Microsoft prend (et nous fait subir) le risque de déplacer le débat sur un terrain qui peut devenir très vite désagréable pour tout le monde. Doit-on reprocher à Microsoft d'avoir entre autres, en fin 2006, adressé à 2.000 directeurs techniques de collectivités locales une lettre pour "répondre à leurs questions légitimes autour de l'interopérabilité" ? Devrait-on s'indigner si Microsoft rééditait la même campagne d'information auprès d'autres organismes publics (préfectures, ministères ou autres) pour leur expliquer sa stratégie en matière d'ouverture et d'interopérabilité ? Doit-on rechercher je ne sais quelle influence occulte pour expliquer les mystérieux retards à l'entrée en vigueur du Référentiel Général d'Interopérabilité qui fait la part trop belle à ODF dans le secteur public ? Faut-il absolument voir l'ombre d'un quelconque acteur commercial derrière l'agitation qui s'est organisée dans le Massachusetts lorsque le gouvernement de cet État a cru pouvoir adopter le format OpenDocument ?

Je ne veux pas me livrer ici à un exercice d'intelligence économique et mon propos n'est pas de prendre position sur l'existence d'éventuelles manœuvres d'influence pour ou contre Open XML. Je tiens simplement à dire que Jean Paoli et Tom Robertson vont trop loin en délivrant un zéro en instruction civique à IBM sans justifier leur appréciation, qu'ils ont tort d'utiliser des arguments qui fonctionneraient aussi bien contre leur propre camp, que Microsoft aurait tort de s'engager sur ce terrain-là, et que le débat devrait rester centré sur les qualités d'Open XML et sur le processus de standardisation.

En tout cas, quel que soit le résultat de la lutte, désormais frontale, engagée entre OpenDocument et Open XML, il va falloir serrer les dents et espérer que la crédibilité de notre système de standardisation n'en souffrira pas trop, car c'est bien aussi de cela qu'il s'agit, et les dommages collatéraux ne sont pas à exclure dans les mois à venir.

À ce propos, le contexte dans lequel a été enclenchée la procédure auprès de l'ISO laisse rêveur. Comme l'a remarqué avec mauvaise humeur un représentant du Bureau Indien des Standards(7), les agences nationales de normalisation concernées étaient censées traiter 200 pages par jour pour venir à bout, dans le délai imparti pour faire connaître leurs éventuelles objections, des 6.000 pages de la spécification Open XML. Une telle performance est évidemment inimaginable. Or l'absence d'objection, dans ce contexte, valait approbation du lancement de la procédure de validation accélérée auprès de l'ISO. Tout s'est donc passé comme si on avait voulu que la spécification Open XML passe en validation accélérée sans examen préalable. Comment un tel court-circuit a-t-il pu être aussi prêt d'aboutir ? La tentative a provisoirement avorté et IBM y est sans doute pour quelque chose mais, jusqu'à nouvel ordre, rien ne permet de désigner lequel des deux principaux protagonistes de cette affaire a le plus assidûment cherché à instrumentaliser à son profit le circuit de normalisation.

Je tiens à préciser ici que je n'accuse pas d'obésité la spécification Open XML et que je ne lui reproche pas, dans l'absolu, ces 6.000 et quelques pages systématiquement invoquées par ses détracteurs inconditionnels. Je ne vois en effet aucun chapitre superflu dans ce document que je considère comme un bon dossier technique (je reviendrai sur ce point). Je soutiens simplement qu'une procédure d'adoption rapide, voire précipitée, ne convient pas à un dossier aussi riche dans un système de normalisation bien ordonné.

Pour compléter ce tour d'horizon sur les charges invoquées contre IBM dans le communiqué du 14 février, Microsoft signale que la suite IBM Lotus n'est pas capable de supporter Open XML(8) et sous-entend clairement que ce "défaut" n'est pas pour rien dans l'opposition d'IBM au nouveau standard. Étrange argument qui, lui aussi, peut être immédiatement retourné, car la suite Microsoft Office 2007, quant à elle, ne supporte toujours pas le format OASIS OpenDocument, pourtant largement antérieur à Open XML et déjà validé par l'ISO. Certes, on parle beaucoup en ce moment du module de compatibilité ODF pour Word, mais j'ai déjà dit dans ces colonnes, il y a plus de six mois, ce que j'en pensais(9), et les analyses récentes ne sont pas plus optimistes que mes prévisions(10). Clairement, ODF n'est pas supporté par Office 2007 et, en choisissant de sponsoriser le développement par des sociétés tierces, en open source, d'un convertisseur externe, approximatif et anti-ergonomique, Microsoft a implicitement confirmé son absence d'engagement technique et contractuel sur cette fonctionnalité qui n'est d'ailleurs pas couverte par les contrats de support de la maison. Une compatibilité ODF réellement opérationnelle passerait par une modification du code de la suite Office, ce à quoi Microsoft se refuse. Sur quelle base, dans ces conditions, reprocher à la suite Lotus de ne pas supporter Open XML, sachant qu'une telle fonctionnalité serait jusqu'à nouvel ordre sans intérêt pratique pour les utilisateurs ? Les promoteurs d'Open XML seraient-ils emportés par leur enthousiasme militant au point de considérer la prise en charge de ce format comme un impératif en soi indépendant de toute expression de besoin ? La seule compatibilité Microsoft utile pour maintenant, c'est la compatibilité avec les anciens formats binaires d'Office, qui correspondent au paysage bureautique actuel ; tant qu'Open XML n'a pas supplanté les formats traditionnels dans la base installée, le fait de le supporter est tout bonnement inutile pour les utilisateurs d'un produit non-Microsoft.

Héritage et interopérabilité

À propos de base installée, j'ai brièvement évoqué, quelques paragraphes plus haut, la marque du passé dans la spécification Open XML. Cette marque se fait lourdement sentir tout au long des 6.000 pages de la documentation (ne serait-ce que par la récurrence du mot "legacy"). Et c'est là sans doute que réside l'essentiel du malentendu qui fait de ce débat un dialogue de sourds. Le paradoxe majeur d'Open XML, c'est d'être pensé simultanément comme un nouveau format, unifié et rationnel, et comme la transposition syntaxique de la galaxie hétérogène des formats anciens (et encore largement dominants) de Word, Excel et Powerpoint. L'objectif déclaré est de parvenir à l'interopérabilité tout en préservant l'héritage d'une époque à laquelle les formats bureautiques n'étaient pas pensés indépendamment des applications (ce qui revient à dire, au fond, qu'ils n'étaient pas pensés du tout). Mais quelle est la portée pratique de cette profession de foi ? Proposer un nouveau format, c'est de toute façon s'engager dans un scénario de rupture, avec toute la problématique de conduite du changement que cela suppose, et dès lors qu'il faut migrer, le degré de ressemblance technique entre l'ancien format et le nouveau ne change pas grand chose au coût de la migration. Dans ce cas, pourquoi faire les choses à moitié et continuer à traîner un boulet qui ne cesse de s'alourdir depuis un quart de siècle ? L'accès aux documents du passé est l'affaire des logiciels bureautiques ; il suffit qu'Office 2007 et ses successeurs continuent à supporter les anciens formats ; Open XML est destiné aux nouveaux documents et sa "ressemblance" avec les anciens formats n'a aucune valeur d'usage pratique. Vouloir absolument lier les futurs formats aux anciens procède d'une logique qui, si elle était vraiment appliquée, nous ferait reprocher à Gutenberg d'avoir inventé l'imprimerie sans tenir compte des travaux des moines copistes du Moyen-Âge et des scribes de l'Antiquité. Il nous suffit de conserver les moyens nécessaires pour accéder aux anciens documents, sans pour autant hypothéquer les techniques documentaires du futur.

Sur ce point, la position de Microsoft est parfois expliquée par une conception particulière de la notion (décidément très chahutée) d'interopérabilité. L'interopérabilité, en matière de fichiers bureautiques, comporte au moins deux niveaux. L'interopérabilité de premier niveau consiste à permettre à toutes sortes d'applications d'accéder aux données contenues dans un document indépendamment du logiciel ayant servi à créer ce document. Sa raison d'être est le besoin d'assurer la jonction entre bureautique et applications d'entreprise. Ses conditions sont la publicité du format et la levée des obstacles technologiques et juridiques à son utilisation. On peut considérer, à quelques gros détails près, que chacun des deux formats rivaux, OXML et ODF, répond à ces conditions. Mais le marché (et les compétiteurs de Microsoft) attendaient aussi autre chose, l'interopérabilité de deuxième niveau, celle qui implique la convergence du marché autour d'un format commun supporté de façon native par les différents éditeurs en présence et permettant à des utilisateurs équipés de logiciels bureautiques différents d'échanger des documents sans perte de contenu ou de présentation. Depuis peu, cette interopérabilité-là est nommée substituabilité car elle est censée faciliter le remplacement d'un logiciel par un autre pour travailler sur les mêmes documents (le mot n'est pourtant pas très heureux car ce n'est pas le document lui-même qui est "substituable"). Selon ses partisans, ODF correspond parfaitement aux deux niveaux de l'interopérabilité. Selon Microsoft, ODF est trop limité pour permettre une représentation correcte de toutes les possibilités offertes par l'état de l'art en matière de logiciel bureautique. Une telle objection est parfaitement recevable, à condition toutefois qu'elle soit assortie d'un inventaire précis des lacunes fonctionnelles du standard. Or, là aussi, l'impasse semble avoir été faite sur le débat technique. Plutôt que de publier la liste des défaillances reprochées à OpenDocument et, en tant que membre de l'OASIS, de proposer les extensions et aménagements adéquats, Microsoft a préféré développer une spécification entièrement distincte en relation avec un autre organisme de standardisation, et soutient à présent l'idée que deux standards valent mieux qu'un. Tout cela parce que, au fond, le vrai problème n'a rien à voir avec les richesses comparées des deux formats ; ce problème découle d'un désaccord sur la définition et le rôle des standards.

Dans le logement d'un ménage français moyen, la fourniture d'électricité est généralement assurée sous une tension alternative de 220 volts à 50 hertz en distribution monophasée. Cette uniformité représente certainement une perte de fonctionnalité. L'exploitation optimale de certains types d'équipements électriques justifierait par exemple du 380 volts triphasé, tandis que des prises murales à 12 volts en courant continu nous dispenseraient d'utiliser des adaptateurs pour recharger nos divers appareils électroniques portatifs. Devons-nous pour autant faire cohabiter deux ou trois standards de distribution électrique dans nos foyers ? Évidemment non. À la base de toute standardisation, il y a une recherche de compromis entre diversité et simplicité, entre fonctionnalité et économie. Or la philosophie qui sous-tend Open XML semble refuser ce compromis ; l'objectif recherché semble en effet être la richesse fonctionnelle à tout prix, sans considération du coût d'implémentation, et sans le moindre effort de réutilisation des éléments fondamentaux du standard OpenDocument. Une telle approche est-elle réellement compatible avec l'esprit de la standardisation ?

Standards et interopérabilité sont évidemment ici, comme toujours, des armes utilisables contre toute position dominante et il est donc parfaitement logique qu'un acteur dominant cherche à en circonscrire les effets. Mais en plus, dans le cas de Microsoft, la conception même d'Open XML et le discours tenu à l'égard d'ODF ont leurs racines dans la culture et la technologie de l'entreprise.

Faut-il un standard pour chaque produit ?

Selon Paoli et Robertson, ODF est étroitement lié au logiciel OpenOffice.org et à ce qu'ils appellent les "produits en relation avec OpenOffice.org"(11), ces derniers n'étant pas définis (ce qui donne peut-être à penser que les auteurs considèrent tout logiciel compatible OpenDocument comme "lié à OpenOffice" quelle que soit sa provenance). Par comparaison, Open XML est présenté comme le reflet de toute la richesse de la suite Microsoft Office 2007(12), tout en assumant l'héritage des versions précédentes (et en apportant au passage des fonctionnalités se situant dans un périmètre plus large que la bureautique traditionnelle). Le message exprime de manière explicite et presque naïve un véritable credo Microsoftien : quoi qu'on fasse, un standard documentaire reste lié de manière indissoluble avec un "logiciel bureautique préféré". Cette philosophie, poussée à ses limites, mène immanquablement à justifier autant de standards qu'il existe d'offres bureautiques majeures en compétition (et pas seulement deux). Malheureusement, il ne s'agit pas seulement d'une philosophie, mais de la conséquence logique d'une adhérence inconditionnelle aux soubassements techniques de la "vieille bureautique".

La suite Microsoft Office, rappelons-le, est un assemblage de composants qui ont toujours été disponibles sous forme séparée et qui sont autant de programmes exécutables indépendants dont chacun gère toutes les fonctions dont il a besoin. Ainsi, Word, Excel et Powerpoint gèrent chacun son interface graphique, sa logique documentaire et ses fonctions de lecture et d'enregistrement de fichiers. Autrement dit, chaque application est intégrée verticalement, son format natif d'enregistrement est inextricablement lié à sa logique générale et étranger aux formats des autres composants de la suite. Cette architecture se reflète directement dans la spécification Open XML, où le format de Word (WordprocessingML), celui d'Excel (SpreadsheetML) et celui de Powerpoint (PresentationML) sont spécifiés séparément, bien qu'il existe évidemment aussi des chapitres transversaux. Par exemple la description des tableaux statiques occupe 34 pages dans la partie consacrée à WordprocessingML, et 9 pages dans la partie SpreadsheetML (sans compter le chapitre consacré aux tableaux croisés dynamiques d'Excel), tout cela parce que, historiquement, Word et Excel ne mémorisent pas les tableaux de la même manière. Par comparaison, dans la spécification OpenDocument, l'essentiel de la description d'un tableau obéit à une sémantique commune, que ce tableau soit une feuille de tableur ou qu'il appartienne à un document d'une autre classe (texte ou présentation).

On touche ici à un problème très ancien d'ingénierie logicielle. En termes de normes de fabrication, Microsoft est toujours resté fidèle, consciemment ou non, au modèle de l'imbrication verticale. De même que l'environnement Windows associe étroitement le système d'exploitation à l'interface graphique (et à beaucoup d'autres choses), de même chaque module de la suite Office imbrique les fonctions à tel point que les capacités opérationnelles du logiciel sont réputées indissociables de la sémantique de ses formats d'enregistrement. En dépit de toutes les innovations que nous devons à Microsoft (notamment dans le domaine des standards), la culture technologique fondamentale de l'éditeur de Redmond porte toujours la marque des environs de 1980, tant il est difficile de renoncer à des procédés sur lesquels on a bâti un empire.

Si un produit comme OpenOffice.org a pu si facilement basculer vers un format ouvert simple, c'est surtout parce que son ancêtre StarOffice (dont le format de fichiers natif était encore, en 1999, aussi propriétaire que les autres) avait été conçu dès l'origine selon une architecture modulaire qui découplait la logique de formatage des fichiers de celles du moteur documentaire et de l'interface graphique et qui, d'un autre côté, mutualisait la logique commune aux différentes applications bureautiques. A priori, rien n'a jamais empêché Microsoft, dont les moyens financiers étaient immenses et qui disposait de toutes les compétences requises, de refondre et d'unifier l'architecture de la suite Office en accord avec les normes de qualité en vigueur depuis la fin du siècle. Sur ce plan, on peut dire que le monopole a produit un effet dévastateur : faute de vision alternative, le marché n'a jamais su imposer une telle refonte, de sorte que l'éditeur a pu se borner, d'une version à l'autre, à empiler des fonctionnalités supplémentaires et à développer autour d'elles une cosmétique de plus en plus sophistiquée sans jamais entreprendre de remise en question fondamentale. La bataille des formats ouverts met aujourd'hui en évidence l'une des limites de cette stratégie : l'adhésion à un vrai format commun, même si elle était politiquement acceptée (ce qui est actuellement très improbable), impliquerait pour Microsoft une réingénierie profonde de la suite Office, c'est-à-dire un effort technique et financier qui ne serait jamais payé par le marché puisque son premier effet serait, grâce à la "substituabilité", de favoriser des fuites de clients et des baisses de prix !

Si la suite Office requiert vraiment un format de fichiers qui ne peut être ni l'actuel OpenDocument ni même une extension future d'OpenDocument, c'est parce que le logiciel repose sur des bases qui étaient acceptables il y a 20 ans mais qui sont maintenant en contradiction avec les bonnes pratiques du génie logiciel. La difficulté à s'adapter à un nouveau format procède à cet égard des mêmes causes fondamentales que les failles de sécurité qu'on découvre par hasard mais qui n'ont rien à voir avec la malchance. En tant que laboratoire de logiciel, Microsoft a persisté dans des choix fondamentaux de conception basés sur l'imbrication alors que d'autres pariaient sur la modularisation. Aujourd'hui, Office 2007 offre une panoplie de fonctions bien plus riche qu'OpenOffice.org. Hélas, contrairement à ce que soutiennent Paoli et Robertson, ce n'est pas la richesse fonctionnelle d'Office 2007 que reflète Open XML, c'est la faiblesse originelle de son architecture et le fardeau de son histoire.

Standards redondants

Puisque OpenDocument et Open XML correspondent à des objectifs différents, Microsoft estime qu'ils sont complémentaires et que le second mérite de rejoindre le premier dans la panoplie des standards de l'ISO. Là aussi, il y a un malentendu. Les deux formats sont complémentaires en tant que spécifications, mais il sont concurrents en tant que standards.

Comme spécification, Open XML est une oeuvre d'une utilité considérable, qui annonce la fin de deux décennies d'obscurité et offre à tous les développeurs une description exploitable des formats Microsoft Office de demain. Ce travail est en effet utile parce que, standard ou pas et que cela plaise ou non, Open XML est un format avec lequel il faudra vivre. Sur ce point, les 6.000 pages de la spécification (tant décriées par ailleurs) sont les bienvenues. Il convient de signaler que cette spécification est non seulement normative, mais aussi explicative. Elle est plus complète à cet égard que la documentation d'OpenDocument, un peu sèche et dépourvue de support pédagogique. Open XML mériterait le titre de "Manuel de référence des formats Microsoft Office 2007 pour les développeurs", et c'est dans ce rôle qu'il peut prendre toute sa valeur. Mais, par conception, il ne possède pas les caractéristiques d'un standard. S'il parvient malgré tout à franchir avec succès les étapes du processus de normalisation, cela ne pourra être qu'au terme d'un processus politique qui remettra en question la notion de standard telle qu'elle est généralement comprise. Si l'éditeur de Redmond déploie une telle énergie pour faire adopter Open XML, en l'état, en tant que standard, c'est pour tenter de faire face à la dangereuse pression qu'exercent sur lui un nombre croissant d'administrations publiques de s'aligner sur le standard bureautique en vigueur ; la standardisation d'Open XML équivaudrait à reconnaître officiellement qu'il existe un standard pour le monde Microsoft et un standard pour tous les autres logiciels bureautiques, c'est-à-dire à annuler purement et simplement les effets pratiques de la standardisation. Open XML serait donc une esquive, et pas une réponse à la question prioritaire, celle de l'interopérabilité de niveau 2 que j'ai mentionnée plus haut. Mais peut-on vraiment accepter de son plein gré, quand on est le premier fournisseur de la planète, un modèle d'interopérabilité qui ne peut que faciliter la migration d'un fournisseur à un autre ? N'est-il pas un peu naïf de demander à Microsoft de montrer lui-même le chemin de la sortie à ses clients ?

Ce n'est pas tout, car les difficultés potentielles ne s'arrêtent pas là. Quoi qu'on en dise, Open XML n'est pas seulement un deuxième format bureautique "riche", c'est aussi une enveloppe dont le contenu redéfinit silencieusement mais effectivement d'autres standards. Un document bureautique est une structure complexe qui est susceptible d'héberger des contenus et des fonctionnalités multiformes dont beaucoup relèvent de catégories déjà couvertes par d'autres standards. L'OASIS a conçu OpenDocument comme un standard relativement simple parce qu'il réutilise très largement les standards déjà définis. En revanche, la contrainte de fidélité à l'égard des anciens formats bureautiques a amené l'ECMA à valider, à travers Open XML, plusieurs sous-formats (concernant notamment les images vectorielles, la notation mathématique, les animations multimédia ou la sécurité) qui entrent en collision directe avec des standards déjà définis par l'ISO ou le W3C. La standardisation bien comprise se construit (tout comme le logiciel de bonne qualité) par capitalisation et réutilisation ; redéfinir tout ce qui, de la cave au grenier, peut apparaître dans un document bureautique, n'est pas conforme à l'esprit de l'ISO. En validant Open XML, celle-ci transformerait une bonne spécification en un mauvais standard et donnerait sa bénédiction à une créature hybride tenant à la fois de la boîte de Pandore et du cheval de Troie. Quelles que soient les arrière-pensées d'IBM, les propos publiés par Jean Paoli et Tom Robertson sont outranciers et ne parviennent pas à masquer une autre vérité : tel qu'il est mené actuellement, le "projet" Open XML est un brûlot lancé contre les efforts de standardisation en cours, et une tentative pour imposer au marché des normes redondantes dont il n'a pas besoin. Si les chiens de garde de la normalisation se laissaient endormir, nous verrions l'excellent dossier technique qu'est Open XML devenir une arme de déstandardisation massive.

________________________

1 - http://www.microsoft.com/interop/letters/choice.mspx
2 - ISO/IEC 26300:2006
3 - http://www.odfalliance.org
4 - http://nauges.typepad.com/my_weblog/2006/10/bureautique_20_.html
5 - http://www-306.ibm.com/software/swnews/swnews.nsf/n/nhan6n3ktr?OpenDocument&Site=lotus
6 - http://www.ccianet.org/filings/ip/ECMA_letter_12705.pdf
7 - http://www.technewsworld.com/story/55608.html
8 - "It is not a coincidence that IBM’s Lotus Notes product, which IBM is actively promoting in the marketplace, fails to support the Open XML international standard."
9 - http://www.itrmanager.com/article.php?oid=54721
10 - http://www.itwriting.com/blog/?p=116
11 - "ODF is closely tied to OpenOffice and related products, and reflects the functionality in those products."
12 - "Open XML, on the other hand, reflects the rich set of capabilities in Office 2007, offers a platform for exciting user productivity scenarios through user-defined schema, and was designed to be backwards compatible with billions of existing documents."

___________________
Jean-Marie Gouarné est consultant en SI et directeur technique de Genicorp (membre de l'ODF Alliance). Il est par ailleurs partenaire associé chez Ars Aperta (www.arsaperta.com), une société de conseil indépendante intervenant sur les questions liées à l'usage de Logiciel Libre dans les organisations."