Avertissement : Cette page traduite pourrait ne pas être à jour par rapport au texte original. Merci de consulter cette page pour tout renseignement sur la manière de participer, entre autres, aux traductions.

Six questions aux organismes nationaux de normalisation

[Également disponibles au format PDF (28k)]

Les six questions suivantes sont relatives à la demande d'acceptation du format ECMA/MS-OOXML comme un standard IEC/ISO. À moins qu'une instance nationale de normalisation puisse apporter des réponses concluantes à chacune d'entre elles, toutes devraient voter non à l'acceptation de ce format dans l'IEC/ISO, et demander plutôt à Microsoft d'incorporer son travail à celui-ci : ISO/IEC 26300:2006 (le format Open Document - ODF).

Ceci est un document récapitulatif, des informations plus détaillées sont disponibles en ligne.

  1. Indépendance vis à vis des applications ?

    Aucun standard ne devrait dépendre d'un système d'exploitation, d'un environnement ou d'une application particulière. L'indépendance vis à vis des applications et des implémentations constitue l'une des plus importantes caractéristiques des standards.

    La spécification MS-OOXML est-elle libre de toute référence à des produits particuliers de quelque fournisseur que ce soit, ainsi que de leurs comportements spécifiques ?

  2. Compatibilité avec les standards ouverts existants ?

    À chaque fois que cela est applicable et possible, les standards devraient être construits à partir des efforts de normalisation précédents au lieu de dépendre de technologies propriétaires ou spécifiques à un fournisseur.

    MS-OOXML néglige de nombreux standards, comme MathML et SVG, qui sont des recommandations du W3C, et utilise à la place ses propres formats propriétaires. Cela impose une contrainte substantielle sur tous les fournisseurs, les obligeant à suivre Microsoft dans son infrastructure propriétaire construite ces vingt dernières années, pour parvenir à implémenter complètement MS-OOXML. Il semble raisonnable de se demander comment les tierces parties pourront jamais parvenir à implémenter toutes les fonctionnalités de façon équivalente.

    Quel est le bénéfice escompté si l'on accepte l'utilisation de formats aussi spécifiques à un fournisseur au détriment de la normalisation dans ces domaines ? Où les autres fournisseurs pourront-ils se procurer des implémentations concurrentielles, compatibles et complètes sur toutes les plate formes afin d'éviter l'effet anticoncurrentiel de lourds investissements ?

  3. Rétrocompatibilité pour tous les fournisseurs ?

    L'un des avantages principaux avancé en faveur de MS-OOXML est sa capacité à permettre la rétrocompatibilité, comme on peut le lire dans le communiqué de presse international de l'ECMA .

    Il est essentiel pour tout standard qu'il puisse être implémenté par n'importe quelle tierce partie sans que la coopération avec une autre entreprise soit rendue nécessaire, ou qu'il y ait besoin d'accéder à des informations complémentaires cachées, ou de signer des contrats, ou encore de verser des indemnités. Il est également essentiel de ne pas requérir la coopération d'un concurrent pour pouvoir obtenir une interopérabilité complète et comparable.

    Sur la base des spécifications existantes de MS-OOXML, peut-on affirmer que n'importe quelle tierce partie, indépendamment de son modèle d'entreprise, sans accès à aucune source d'information complémentaire et sans la coopération de Microsoft, pourrait implémenter une rétrocompatibilité complète et un mécanisme de conversion avec d'anciens documents, comparable à ce que Microsoft peut offrir ?

  4. Des extensions propriétaires ?

    Les extensions propriétaires ou spécifiques à une application constituent une technique bien connue et employée tout particulièrement par Microsoft pour mettre son monopole sur les machines de bureau à profit dans les marchés voisins. Cette technique est au cœur du comportement abusif qui a été reproché à Microsoft par la Commission Européenne en 2004, et pour lequel Microsoft refuse encore aujourd'hui de rendre publiques les informations nécessaires à l'interopérabilité.

    Pour cette raison, il est communément admis que des standards ouverts ne devraient pas admettre de telles extensions propriétaires, et que ces techniques de distorsion du marché ne devraient pas être rendues possibles par un standard ouvert.

    MS-OOXML autorise-t-il les extensions propriétaires ? L'implémentation qu'a fait Microsoft du MS-OOXML est-elle fidèle aux spécifications, c'est à dire sans extensions non documentées ? Les spécifications de MS-OOXML contiennent-elles des garde-fous contre de telles pratiques abusives ?

  5. Deux standards ?

    Le but de toute normalisation est systématiquement d'aboutir à un standard unique, puisque des standards multiples provoquent toujours des entraves à la concurrence. Le semblant de compétition sur un standard est réellement une tactique délibérée pour gagner le contrôle de certains segments de marché, comme de nombreux exemples l'ont prouvé par le passé.

    Il existe un standard ouvert pour les documents bureautiques, le format Open Document (ODF) (ISO/IEC 26300:2006). MS-OOXML et ODF sont tous deux construits sur la technologie XML. Ils emploient donc la même technologie de base et ont en fin de compte les mêmes capacités théoriques. Microsoft lui-même est membre d'OASIS, l'organisation au sein de laquelle a été développé le standard ODF et qui en assure le suivi. Il était au courant du processus et a été invité à y participer.

    Pourquoi Microsoft a-t-il refusé et refuse-t-il encore de participer à l'effort existant de normalisation ? Pourquoi ne soumet-il pas ses propositions technologiques à OASIS pour les incorporer au format ODF ?

  6. Juridiquement sûr ?

    Garantir à tous les concurrents d'être dégagés de toute poursuite judiciaire pour l'implémentation d'un standard est essentiel. Une telle garantie doit être claire, sûre et suffisamment large pour couvrir toutes les activités nécessaires à l'obtention d'une interopérabilité parfaite, et ouvrir un champ d'action offrant la possibilité d'une vraie compétition basée sur le mérite.

    MS-OOXML est accompagné d'un engagement inhabituellement complexe et étroit, un "engagement de non-poursuite", à la place de l'usuelle licence d'exploitation de brevet. Du fait de cette complexité, la protection contre des poursuites au sujet de la compatibilité n'est pas clairement garantie.

    Une étude juridique rapide montre que l'engagement ne couvre pas toutes les fonctionnalités optionnelles et les formats propriétaires obligatoires pour obtenir une implémentation complète de MS-OOXML. La liberté d'implémentation par tous les concurrents n'est donc pas garantie sur l'intégralité du format MS-OOXML, et cette question subsiste pour les composants essentiels.

    Est-ce que votre instance nationale de normalisation possède sa propre analyse indépendante sur la nature exacte de la garantie, pour certifier qu'elle couvre véritablement le spectre entier de toutes les implémentations possibles de MS-OOXML ?

Toutes ces questions devraient obtenir des réponses de la part des organismes de normalisation nationaux, à travers des experts et des conseils indépendants, et en particulier ne provenant pas de Microsoft ou de ses entreprises associées, qui entretiendraient alors un conflit d'intérêt à ce sujet.

S'il n'y a pas de réponse satisfaisante à l'une d'entre elles, un organisme national devrait voter non à l'ISO/IEC.

Lectures complémentaires