Tribunes

Florange Telecom

L'approche radicaliste de l'architecture du Web : l'assembleur

Big Dataxe

Le Big Data individuel

La comptine du cloud

Toute les tribunes

La vidéo du moment
Actualité marchés verticaux

Huawei lance ServiceStage, sa première offre de cloud public

par Global Medias
le 21/04/2017 à 01:54

L'ITSM est d'une importance capitale pour la compétitivité de l'entreprise

par Global Medias
le 11/04/2017 à 04:04

Loumio veut devenir le 3ème opérateur wholesale sur le marché de la fibre optique

par anonyme
le 09/04/2017 à 08:40

L'accès aux marchés est toujours difficile pour 67% des entreprises du numérique

par TAMPublics
le 07/04/2017 à 04:20

Questions réponses sur le droit à la déconnexion

par Edouard de Calldoor
le 05/04/2017 à 09:38

Rechercher
Services
Logo_abonn Job Les derniers communiqués de presse Proposer un communiqué de presse
Fils RSS : Top 10 quotidien

Formats bureautiques : le consensus impossible (2)
Par Jean-Marie Gouarné

mardi 11 septembre 2007

Un "oui mais" en forme de "non" ?
Le verdict exprimé à l'issue du vote des pays membres de l'ISO sur le projet DIS 29500 Office Open XML est généralement présenté comme négatif. Compte tenu des règles de décision complexes et non intuitives de l'ISO, ce résumé abrupt ne rend pas compte de la situation réelle. Il s'agit plutôt d'un ajournement que d'un refus, sachant que la véritable décision devrait intervenir en février 2008. Ce qui a été rejeté cet été, ce n'est pas le projet OOXML, c'est l'adoption de la spécification dans son état actuel. Car selon les règles de l'ISO (1), l'approbation d'une norme sous réserve de corrections techniques ultérieures n'est pas possible ; la présence de demandes de corrections substantielles implique un vote négatif.

 

Comme je l'ai écrit dans la première partie de cet article, l'ECMA s'est engagée à traiter au travers de son "Comité Technique 45" (TC45) tous les commentaires exprimés par les pays membres de l'ISO (2). Microsoft a fortement appuyé dans ce sens en soutenant même qu'un vote favorable serait de nature à favoriser l'amélioration du standard. Cet engagement était manifestement destiné à encourager les hésitants à voter oui malgré leurs objections. Il fallait toutefois le prendre avec circonspection, car on voit mal comment l'ECMA aurait pu modifier la spécification après qu'elle ait été adoptée par l'ISO. On ne change pas une norme internationale établie sans repasser par le processus normal de décision de l'ISO ; par conséquent si l'adoption d'Open XML avait été prononcée dès septembre 2007, la spécification aurait vraisemblablement été figée pour plusieurs années avec toutes ses imperfections. Ni le secrétariat du TC45, ni Microsoft, en tant qu'habitués des couloirs obscurs de la normalisation, ne pouvaient ignorer cela, et leur insistance à solliciter un "oui avec commentaires" ne démontre qu'une seule chose : l'objectif était simplement d'obtenir un vote positif en contrepartie d'une promesse sans portée effective. S'il existe aujourd'hui une possibilité réelle d'améliorer le projet de norme, c'est bien parce qu'il a été provisoirement rejeté.

 

Dans son communiqué officiel du 4 septembre(3) , Microsoft prend son parti de la situation et annonce que les nombreux commentaires techniques recueillis vont permettre d'améliorer le standard (démontrant ainsi son extraordinaire aptitude à "positiver" un échec, et invalidant au passage la réaction maladroitement négative exprimée la veille par la filiale française face à la décision de l'AFNOR).

 

Dans ces conditions, on peut se demander pourquoi Microsoft a déployé de tels efforts de communication à l'échelle planétaire pour obtenir un oui en première instance. L'intérêt des utilisateurs, qui vivent depuis plus de 15 ans dans un univers bureautique sous le contrôle d'un "standard de fait" qui ne sera jamais une norme, n'y est pas pour grand chose. La spécification Office Open XML est de toute façon déjà ouverte ; ceux qui veulent l'implémenter sont déjà libres de le faire à leur guise. Il n'y a donc pas péril en la demeure. D'où vient donc cet acharnement à vouloir transformer aussi vite ce "standard" en "norme" ? Et pourquoi le projet Open XML, depuis son lancement (fin 2005) est-il mené à une allure qui évoque plus une charge de cavalerie qu'un processus de normalisation ?

 

Les raisons de la course à la normalisation


Du point de vue des autorités qui les édictent, les normes internationales sont des invitations adressées aux industriels en vue de favoriser une certaine rationalité économique par la convergence vers des formats et des protocoles communs. Mais cette logique est quelque peu pervertie par la perception du grand public et des décideurs, qui considèrent la reconnaissance d'une norme par l'ISO comme une certification qui s'attache non seulement à la spécification normalisée elle-même, mais aussi aux produits qui sont supposés implémenter cette spécification. Cette perception est amplifiée par la presse qui utilise des expressions aussi malheureuses qu'inadéquates telles que "certification ISO" pour qualifier l'accès d'une spécification technique au statut de norme internationale. La normalisation est donc assimilée une sorte de "labellisation", c'est-à-dire à un argument commercial.

 

La création du standard OASIS Open Document Format for Office Applications (ODF), adopté peu après en tant que norme ISO/IEC 26300, a créé un situation nouvelle, en démontrant la possibilité d'un standard "de droit" dans le domaine des formats bureautiques. Les administrations, qui sont de plus en plus nombreuses à rechercher tous les arguments possibles pour battre en brèche le monopole de fait dont bénéficie la suite Microsoft Office, ont sauté à pieds joints sur l'occasion en laissant entendre que la conformité à une norme pourrait bien devenir une condition d'accès aux marchés publics. La menace est beaucoup plus sérieuse qu'on ne l'imagine, car la perte d'un grand marché public n'est pas seulement un manque à gagner ; c'est aussi, potentiellement, le début d'une réaction en chaîne dont les conséquences ultimes pourraient être une redistribution générale des cartes au-delà du secteur public. À défaut d'urgence technologique pour les utilisateurs, il y a donc urgence stratégique, pour le géant de Redmond, à empêcher la normalisation des formats de documents de continuer à se faire sans lui. Et puisqu'il est trop tard pour prendre le contrôle de la norme ODF, la seule possibilité qui reste est de la rendre de facto inopérante en tant que standard de convergence en imposant le principe "à chacun son standard". Maintenant et à tout prix.

 

C'est ce qui explique la pression (sans précédent connu dans le domaine des normes documentaires) exercée en faveur d'une adoption accélérée du DIS 29500. Si l'objectif était seulement de mettre la spécification à la disposition des entreprises, cet objectif serait déjà atteint et Microsoft aurait une attitude beaucoup plus décontractée à l'égard de la procédure en cours.
Il serait étonnant qu'un fournisseur dont le métier consiste à vendre des logiciels et non pas des normes puisse déployer une activité promotionnelle aussi soutenue autour de l'initiative Open XML sans un objectif commercial précis. Il serait tout aussi étonnant d'ailleurs, mais c'est un autre sujet, qu'IBM ait pu mobiliser des ressources dans un sens exactement opposé sans une arrière-pensée commerciale liée, elle aussi, à une certaine concurrence commerciale avec les produits Microsoft.

 

Le lien entre Open XML et les produits Microsoft n'est pas seulement dénoncé par les détracteurs du standard de l'ECMA. Il transparaît aussi dans le discours des évangélistes de Redmond dont la fameuse lettre ouverte de février 2007 en faveur de la multiplicité des standards présentait clairement ODF comme le format d'OpenOffice.org et OOXML comme celui d'Office 2007 (4). Mieux, l'argument le plus populaire en faveur de la normalisation d'Open XML se fonde sur l'idée que ce sera de toute façon le format natif d'une suite bureautique qui représente environ 90% du marché, et qu'il vaut mieux par conséquent en faire un standard de droit.

 

D'où un malaise profond et persistant dans la démarche de normalisation officielle, car la chose à laquelle tout le monde pense, c'est-à-dire les relations entre Open XML et Microsoft Office, est la seule dont les commissions d'experts n'ont pas le droit de parler. Il est en effet de règle, lorsqu'on étudie un projet de norme, de l'apprécier pour ses qualités intrinsèques et de ne pas s'intéresser à ses implémentations existantes. Il faudra pourtant bien un jour aborder cette question politique, en la reformulant au besoin, car elle se profile implicitement derrière la majorité des objections techniques recueillies par l'ISO à l'occasion de la phase qui vient de se terminer.

 

Erreurs de détail ou défaut de conception ?

 

Le cadre de réponse imposé par l'ISO aux pays membres est conçu de telle façon qu'il incite les comités nationaux de normalisation à décortiquer la spécification de manière séquentielle et à associer chaque commentaire à un passage précis du texte. Cette approche mène à une restitution très énumérative, située "au ras du texte", et défavorise les commentaires de portée plus générale. Elle a donc très logiquement produit un véritable tsunami de commentaires techniques détaillés (des milliers, dont plus de 600 uniquement pour la France). Ce nombre ne saurait à lui seul être considéré comme une preuve accablante de l'inadéquation du projet de norme. On peut déjà mettre de côté les commentaires à caractère cosmétique (ou "éditorial" pour employer la terminologie de l'ISO), et ceux qui ne dénoncent que des erreurs ou des ambiguïtés de détail qui peuvent être corrigées aisément et sur lesquelles un consensus général devrait pouvoir se dégager. La plupart de ce qui reste (et il en reste beaucoup) porte sur des éléments du standard qui, malgré leur variété, ont un point commun : tous portent en filigrane la marque d'une conception décousue et initialement calquée sur les caractéristiques de la suite Office.

 

Les défauts essentiellement attribués au nouveau standard sont, en résumé, de cinq natures :
« Présence d'erreurs volontaires et officiellement reconnues comme telles (dans des fonctions associées aux feuilles de calcul), justifiées par des préoccupations de compatibilité avec des applications bureautiques d'un passé parfois lointain, acceptables dans un standard de fait mais mal appropriées aux objectifs d'une norme ;
« Présence dans la partie normative du projet de fonctions dites "dépréciées", évoquées dans la première partie de cet article, dont certaines ne sont d'ailleurs décrites que par référence à des logiciels propriétaires et ne sont pas facilement implémentables par des éditeurs autres que Microsoft ;
« Méconnaissance du cadre général de la normalisation ; le DIS 29500 n'est pas seulement en conflit avec la norme ISO/IEC 26300 (ODF), dont il ne réutilise strictement rien, même pas les éléments correspondant aux fonctionnalités communes à toutes les suites bureautiques, mais aussi avec d'autres normes et standards en vigueur (exemples : représentation de dates non conforme à la norme ISO 8601, utilisation des unités de mesure anglo-saxonnes classiques au lieu du système métrique international, etc) ;
« Manque de cohérence interne de la spécification ; une même fonctionnalité est en effet très souvent mise en oeuvre selon des syntaxes et des grammaires qui diffèrent arbitrairement selon le contexte, ce qui complique les choses sans raison apparente ;
« L'absence de certaines fonctionnalités de détail par ailleurs présentes dans ODF (bien qu'OOXML soit beaucoup plus riche qu'ODF sur bien des points) et pouvant donc être considérées comme indispensables pour des raisons d'interopérabilité ; cette absence ne semble pouvoir s'expliquer que d'une seule façon : les auteurs ont limité leur analyse de l'état de l'art bureautique au périmètre des fonctionnalités de la suite Microsoft Office.

 

En fait, derrière ces cinq types de préoccupations transparaît une seule et même cause, celle qu'on ne doit justement pas évoquer dans les comités techniques : l'adhérence étroite de la spécification Office Open XML à un modèle particulier de logiciel bureautique ainsi qu'à la culture technologique de son éditeur. Une démarche saine aurait commencé par une modélisation conceptuelle des structures de données constitutives d'un document en tant que telles et se serait poursuivie par la traduction des modèles résultants en schémas XML en s'appuyant systématiquement sur l'état de l'art (donc notamment sur les standards en vigueur).

 


Malheureusement, cette approche pourtant classique dans les projets d'ingénierie logicielle bien menés n'a pas été suivie. La spécification telle qu'elle est aujourd'hui reflète un effort (énorme mais incohérent et inachevé) de rétro-ingénierie d'un existant hétérogène auquel ont été simplement juxtaposées des fonctions d'interopérabilité et d'extensibilité, le tout assaisonné d'un balisage XML qui semble avoir été défini chapitre par chapitre par des équipes séparées sans référence à des règles de structuration et de nommage communes.

 

On retrouve dans ce patchwork la trace de l'historique des formats XML successivement introduits dans la suite Microsoft Office de 1998 à 2005. Un historique qui rappelle que Microsoft n'a pas attendu la "menace" ODF pour s'intéresser à l'utilisation de grammaires XML dans les fichiers bureautiques, ce qui est indiscutablement un bon point pour l'éditeur de Redmond. Mais quand on le réexamine dans le contexte du débat actuel sur Open XML, il dénonce aussi une méthodologie plutôt discutable.

 


Le premier né des composants essentiels d'Open XML est le format SpreadsheetML (c'est-à-dire la composante "orientée tableur") ; il apparaît avec Excel 2000 et, bien qu'il soit basé sur XML, son statut est celui d'un format propriétaire. Le langage de description d'images vectorielles VML s'invite à la même époque dans la suite Office. Vient ensuite WordML (qui sera ensuite rebaptisé WordprocessingML), introduit avec Word 2003. VML est alors supplanté par DrawingML, un nouveau langage de représentation des graphismes vectoriels plus prometteur que VML ; pourtant DrawingML ne permet pas d'assurer une reprise intégrale des possibilités de VML. On garde donc VML en plus de DrawingML ! C'est à ce moment que la pression des gouvernements en faveur des formats ouverts commence véritablement à se faire sentir et que l'état-major de Redmond sent venir le danger. Les schémas XML d'Office 2003 sont alors rendus publics. Ces schémas se réduisent essentiellement à WordML et SpreadsheetML qui demeurent, à la base, régis par des spécifications séparées. Office 2003 introduit en outre un concept de personnalisation des schémas permettant à l'utilisateur d'adapter finement les documents à des contextes de gestion spécifiques. Un supplément de fonctionnalité innovant, mais qui ne répond pas exactement aux questions les plus "basiques" et les plus immédiates d'ouverture des formats et d'interopérabilité entre logiciels concurrents. Les schémas XML d'Office 2003 sont alors rendus publics, et la presse salue avec enthousiasme la volonté d'ouverture enfin affichée par l'éditeur. Mais les conditions techniques et juridiques de cette ouverture ne parviennent pas à convaincre, et pendant ce temps OpenOffice.org ne cesse de faire parler de lui. Microsoft comprend alors qu'il faut passer à la vitesse supérieure. Le format PresentationML (qui correspond à Powerpoint) est annoncé à la mi-2005 et le tryptique ainsi complété est mis en relation avec une spécification d'enveloppe dite Open Packaging Conventions (OPC). La démarche formelle de standardisation de cet ensemble, qui constitue désormais la collection des "formats Office Open XML", est lancée à travers le "Comité 45" (TC45) de l'ECMA à la fin de la même année.

 

Ce raccourci historique montre que le standard Office Open XML n'a pas été déterminé selon un plan d'ensemble bien défini. Pour l'essentiel, il résulte d'un assemblage de formats définis à des époques différentes par des équipes différentes, en relation avec des produits différents (Excel, Word puis Powerpoint) et sans démarche de conception d'ensemble. Cette caractéristique, peu visible dans la documentation introductive (5), commence à apparaître dans la table des matières du volume de référence principal (6), et se confirme de façon flagrante à travers le contenu.

 

Les autres membres du TC45 (7) ont certainement joué un rôle actif dans la mise au point, et Open XML n'est peut-être pas un projet "strictement Microsoft", mais leur intervention n'a pas influé radicalement sur son architecture générale. D'ailleurs le nombre d'erreurs éditoriales semble montrer que l'effort consacré aux relectures croisées n'a pas été à la hauteur du nombre et de la qualité des participants. De toute manière, il ne pouvait pas matériellement en aller autrement. Les travaux du TC45 ont eu lieu entre décembre 2005 et septembre 2006. En rapportant la durée de cette période au volume des spécifications, on peut démontrer arithmétiquement que ce standard, s'il est réellement l'oeuvre du TC45, a été écrit à raison de 600 pages par mois. Cette productivité hallucinante suggère d'abord que l'urgence stratégique a prévalu sur le souci de la qualité, et ensuite que l'ECMA n'a pas vraiment eu le temps d'exercer un contrôle effectif sur l'ensemble du projet. De sorte que le coeur d'Open XML est un assemblage de matériaux épars, en grande partie préexistants et conçus à des époques où la notion de standard intégré n'était pas à l'ordre du jour.

 

Aujourd'hui le résultat est là : une spécification très fouillée sur de nombreux points, des fonctionnalités avancées, une mine d'informations de nature à satisfaire des légions de programmeurs... bref, à peu près tout ce qu'on veut sauf la vision d'ensemble et la rigueur rédactionnelle qui sont censées distinguer une norme d'un manuel de référence. Et trop de zones grises concernant les liens entre le projet de norme et le "standard de fait". Tout cela, malgré l'optimisme officiel, fait peser une lourde hypothèque sur la suite du processus.

 

L'avenir des commentaires techniques

 

Malgré l'importance symbolique de la mention "disapproved" qui vient de sanctionner le "premier tour", les seules choses qui comptent vraiment sont désormais la nature des demandes de modification et la manière dont elles seront traitées.

 

Une éventuelle (et très improbable) acceptation de tous les commentaires ou même seulement d'une grande partie d'entre eux aurait des conséquences dramatiques :
D'abord elle briserait les liens privilégiés entre le noyau des spécifications Office Open XML et les logiciels Microsoft Office actuels et passés. Ce ne serait pas une bonne nouvelle pour tout le monde. Les fonctions de compatibilité "dépréciées" et/ou non documentées, et les "bugs volontaires" sont considérées comme indispensables pour assurer une compatibilité en "haute fidélité" avec l'existant. Les promoteurs du standard devraient choisir entre deux options : détacher dans une annexe optionnelle tous les éléments de compatibilité qui fâchent (c'est-à-dire, grosso modo, adopter le découpage proposé par l'AFNOR) ou les spécifier intégralement et conformément aux règles de l'art, sans référence à aucune application spécifique ni reproduction volontaire d'erreurs de comportement. La première option donnerait peut-être satisfaction aux inconditionnels des "standards ouverts" mais réduirait à néant l'avantage supposé d'OOXML sur ODF en matière de compatibilité Microsoft. La seconde option rendrait évidemment les spécifications encore plus volumineuses et surtout obligerait Microsoft à retrouver ou à reconstituer des spécifications anciennes et qui n'ont peut-être jamais été rédigées en clair.

 


Ensuite, la mise en cohérence des différents formats (WordprocessingML, SpreadsheetML, PresentationML) imposerait à elle seule une refonte complète. Avec d'importants dommages collatéraux du côté des logiciels Office, qui devraient eux aussi être retravaillés en profondeur pour suivre l'évolution du standard.

 

Autant dire qu'on n'échapperait pas à une réécriture complète, dont le résultat serait comparable à une sorte d'ODF étendu. Ce résultat serait catastrophique pour Microsoft, dont la suite Office ne serait plus directement favorisée, et qui se serait donc battu pendant deux ans pour un résultat honorifique. Cette voie-là ne sera donc certainement pas suivie. Elle ne serait pas plus économique et aurait moins de sens que la fusion avec ODF.
Il est donc pratiquement certain qu'une grande partie des objections techniques, voire la plupart d'entre elles, passeront à la trappe. Nul ne sait, en septembre 2007, si le peu qui en ressortira sera suffisant ou non pour permettre au projet Open XML de déboucher sur une norme internationale en 2008. À moins que Microsoft ne renonce au projet, il faudra trouver un compromis plus ou moins bancal et forcément politique pour que le "non provisoire" de l'ISO se transforme en "oui". La recherche de ce compromis sera une rude épreuve pour la crédibilité de l'ISO.

 

Des doutes sur le système de normalisation

 

 

Quelle que soit l'issue de cette bataille, elle a déjà fait un perdant : le système de normalisation mondial.
La plupart des objections techniques élevées contre Open XML étaient connues avant le lancement du cycle d'adoption par l'ISO, mais elles n'étaient pas revêtues du sceau d'autorités formellement qualifiées. Ces objections, désormais validées par des instituts de normalisation, ont pris un caractère officiel (ce qui autorise d'ailleurs consultants et journalistes à en parler plus librement que par le passé sans risquer de se mettre en situation "politiquement incorrecte"). Il est donc grand temps de laisser de côté l'hypocrisie et la langue de bois qui ont trop longtemps obscurci le débat, et de constater l'étendue des dégâts.

 

Le projet Office Open XML, quelle que soit la validité à long terme de ce qu'il représente, n'aurait jamais dû parvenir dans son état présent à un stade aussi avancé de la normalisation. Dans des conditions qui restent assez obscures, l'ISO a cru pouvoir compter sur la garantie de sérieux apportée par l'ECMA, et a accepté d'engager sur cette base une procédure de validation accélérée. Or, pour des raisons qui restent elles aussi à expliquer, l'ECMA n'a manifestement pas été à la hauteur de ce qu'on peut attendre d'un consortium de standardisation de cette importance, et semble avoir un peu trop vite apposé son sceau sur un parchemin dont la plus grande partie a été écrite hors de son contrôle. Résultat : si on voulait vraiment obtenir en 2008 un document digne d'une norme internationale, il faudrait pratiquement refaire ce que l'ECMA était censée faire. Le pire de tout cela étant que le résultat du vote aurait quand même pu être positif, que tous les commentaires techniques auraient donc pu être enterrés (avec ou sans les honneurs de la guerre) et que ce document serait aujourd'hui la norme ISO/IEC 29500 ! Serions-nous entrés dans l'ère des normes de complaisance ?

 

Si des doutes s'élèvent sur la fiabilité du système de normalisation en matière de formats bureautiques, ils ne peuvent que porter atteinte au crédit de la norme existante, ODF. Bien que certains souhaitent voir ODF et OOXML figurer côte à côte au catalogue des normes internationales, je pense qu'une telle cohabitation serait bien pire que l'absence de norme dans ce domaine, et que, plutôt que de suivre une telle voie, il aurait mieux valu se contenter d'un standard OASIS et d'un standard ECMA, et éviter de mettre le feu à l'ISO.
Ce n'est pas seulement Open XML qui mérite une revue de détail ; c'est aussi le processus de décision de l'ISO. Ce processus a montré des faiblesses auxquelles il est urgent de remédier sous peine d'une perte de crédibilité qui serait dommageable à toute la communauté même si quelques acteurs peuvent en tirer avantage.

 

Derrière l'ISO, il y a aussi, bien entendu, les pays membres.
Chaque pays prend sa décision comme il l'entend ; l'ISO ne peut imposer aucune règle relative au fonctionnement interne des instances nationales de normalisation. Certaines d'entre elles ont adopté un mécanisme de décision apparemment "démocratique" mais qui peut très vite devenir pervers dans les situations très politiques : le vote à la majorité des entreprises représentées ; ce mécanisme est de nature à inciter certains acteurs (partisans ou adversaires d'un projet de norme) à faire du "bourrage de comité" en faisant intervenir des entreprises alliées moyennant une rétribution directe ou indirecte. La France évite cet écueil dans la mesure où, en cas d'absence de consensus, c'est en principe l'administration, soit la direction de l'AFNOR (sous le contrôle du Délégué Interministériel aux Normes (8)), qui tranche. Ce n'est malheureusement pas le cas partout, de sorte les comités de normalisation de certains pays peuvent être pris d'assaut. Certains incidents de parcours survenus peu avant le 2 septembre (notamment dans un pays membre de l'Union Européenne qui a finalement décidé d'invalider son propre vote) démontrent que cette remarque n'est pas de la politique-fiction ; on peut espérer que de tels exemples inciteront les gouvernements et les opinions publiques à plus de vigilance.

 

Indépendamment des comités d'experts, les administrations centrales (qui ont généralement un rôle-clé à jouer dans le processus) sont et seront inévitablement l'enjeu d'une guerre d'influence sans merci. Ce sont souvent elles qui jouent le rôle essentiel dans les pays qui s'opposent à la normalisation du format OOXML. À défaut de pouvoir les "convertir" dans les pays qui espèrent ne pas être des républiques bananières, les tenants du nouveau standard peuvent être tentés de mettre les décideurs en difficulté au travers de la "vox populi" stimulée par les circuits d'influence appropriés. C'est ainsi que des associations de collectivités locales ou d'usagers des services publics, qui ne prétendent pas avoir de compétences informatiques pointues, peuvent néanmoins se découvrir une passion soudaine et prioritaire pour l'austère domaine des formats documentaires, et fustiger les "technocrates" coupables de vouloir imposer une norme unique (ODF) de nature à compromettre la gestion communale, à empoisonner la vie des administrés ou à alourdir le fardeau des contribuables. Le domaine des formats bureautiques est décidément un beau sujet pour les amateurs d'intelligence économique ! Mais tout ceci nous éloigne des considérations relatives à l'intérêt pratique des normes.

 

Et tout ça pourquoi ?

 

La véritable motivation, pour un utilisateur pragmatique (mais pas forcément averti), de militer en faveur de la normalisation d'Open XML, c'est le souci de la compatibilité Microsoft. On a dit et répété que, grâce à cette spécification, les formats de fichiers de la suite Office étaient enfin ouverts et que, par les vertus de la normalisation, cette ouverture allait être pérennisée et ne serait plus soumise au contrôle exclusif de l'éditeur.

 

Cette croyance relève typiquement de l'utopie et du faux bon sens.
Il convient de rappeler que les normes de l'ISO sont purement indicatives. Elles peuvent être invoquées comme des arguments commerciaux, mais elles n'engagent pas pour l'avenir ceux qui les ont introduites. Le promoteur d'une norme internationale la respecte tant qu'elle lui semble utile. L'adoption éventuelle de la norme ISO 29500 n'interdit en aucun cas à Microsoft d'adopter d'autres formats. Il s'agit d'une réalité, et non d'une simple éventualité. En effet, en parallèle avec Open XML, Microsoft a déjà créé un nouveau format propriétaire pour Excel 2007. Ce format réputé plus performant qu'Open XML crée un doute précoce sur la pérennité du standard ECMA, qui est considéré implicitement par les ingénieurs de Microsoft eux-mêmes comme non optimal pour le tableur le plus utilisé au monde. De plus, si jamais un jour l'ouverture de la spécification permettait réellement à un concurrent de développer une suite bureautique complète et entièrement compatible, la norme deviendrait même nuisible pour Microsoft, que rien n'empêcherait alors de réintroduire des incompatibilités. Naturellement, il est peu probable que l'état-major de Redmond fasse une déclaration officielle d'abandon du standard au risque de déclencher la fureur des gouvernements, le standard peut être insidieusement contourné et dépassé par l'usage de formats "optionnels" apportant des gains de performances et de fonctionnalités.

 

Bien sûr, le fait qu'ODF soit une norme ISO ne garantit pas non plus que ses actuels supporters (dont OpenOffice.org) lui resteront éternellement fidèles. Ce que je veux signaler ici, c'est que la valeur pratique d'une norme est largement déterminée par les rapports de force dans lesquels évoluent les fournisseurs concernés. La pérennité d'ODF est assurée avant tout par le fait qu'aucun éditeur de logiciel compatible ODF ne contrôle 90% du marché global de la bureautique, tandis que celle d'OOXML est suspendue à la stratégie d'un fournisseur unique.

 


Un deuxième élément doit tempérer l'ardeur des optimistes : les macro-instructions ne sont pas dans le périmètre du standard. Par conséquent, la spécification ne permet pas de développer, par exemple, un tableur compatible OOXML capable de traiter des macros Excel. Sur ce plan, les possibilités de reprise de l'existant ne sont guère meilleures que celles d'ODF.

 


Les spécifications Office Open XML ont bien une utilité réelle dès aujourd'hui et, à défaut de susciter la création de produits concurrents de Word, d'Excel et de Powerpoint, elles facilitent largement l'exploitation des documents par des applications d'entreprise exécutées dans des environnements techniques variés. Elles représentent donc un progrès certain, et l'enthousiasme qu'elle suscite auprès d'un certain public de développeurs est largement justifié. Mais leur utilité ne sera pas augmentée par l'existence d'une norme ISO 29500. Surtout si la vocation de cette norme est avant tout de servir de contrepoids politique à une autre norme.

 

Formats bureautiques : le consensus impossible (1ere partie)
Par Jean-Marie Gouarné

____________
1 ISO/IEC JTC 1 Directives, 5th Edition, Version 3.0, section 9.8
2 After the ballot closes, TC45 will continue its very active involvment by supporting the ISO/IEC DIS 29500 Editor which will be tasked to produce a proposed disposition of all comments received during the ballot period.", voir http://www.ecma�international.org/memento/TC45-M.htm
3 ttp://www.microsoft.com/presspass/press/2007/sep07/09-04OpenXMLVotePR.mspx
4 ODF is closely tied to OpenOffice and related products, and reflects the functionality in those products. [...] Open XML, on the other hand, reflects the rich set of capabilities in Office 2007 [...]", voir http://www.microsoft.com/interop/letters/choice.mspx
5 ffice Open XML Overview, réf. Ecma/TC45/2006/374, ECMA International, décembre 2006
6 ffice Open XML, Part 4, "Markup Language Reference", décembre 2006
7 ctuellement: Apple, Barclays Capital, BP, The British Library, Essilor, The Gnome Foundation, Intel, The Library of Congress, Microsoft, NextPage, Novell, Statoil, Toshiba.
8 f. décret n° 84-74 du 26 janvier 1984 fixant le statut de la normalisation

SQ 250-300

Les commentaires

Merci pour cette analyse remarquable, qui, enfin, évite la confusion des genres et le parti pris. Cette fois nous sommes éclairés !

Par jack le 12/09/2007 à 09:58

Les 10 derniers articles mis en ligne