Open XML, la norme sans le texte
Par Jean-Marie Gouarné

Au soir du 29 mars 2008, le processus d'adoption du projet de norme ECMA Office Open XML (OOXML), soutenu par Microsoft auprès de l'ISO, était théoriquement clos. Tous les pronostics émis à ce sujet donnent le projet gagnant, malgré le refus provisoire enregistré le 2 septembre 2008. Pourtant, le lundi 31 mars, le résultat officiels n'est pas dévoilés. Ce silence est très probablement un symptôme de l'embarras dans lequel se trouve l'ISO face à un dossier qui sent le soufre.

D'abord, la norme OOXML est en concurrence directe avec la norme ODF, adoptée par l'ISO en 2006. Mais surtout, compte tenu de l'importance commerciale de l'enjeu, le processus de normalisation d'OOXML a été caractérisé par des efforts de lobbying d'une rare intensité ; bien que Microsoft ait apparemment surclassé ses adversaires, et notamment IBM, sur ce terrain, il est possible que le camp adverse fasse de la résistance. On peut donc supposer que des négociations souterraines se sont prolongées en marge de la procédure formelle et que l'état-major de l'ISO se torture encore les méninges pour élaborer une présentation politiquement correcte d'une décision qui met fin à un processus contestable de bout en bout et dont l'issue, quelle qu'elle soit, sera contestée.

Bien que cet article ne soit pas un poisson d'avril anticipé, il ne doit surtout pas être pris pour l'affirmation d'un résultat qui n'est pas encore connu. Il exprime seulement mon point de vue, au 31 mars 2008, sur les conséquences qui découleraient du résultat généralement considéré comme le plus probable. J'avoue cependant que je ne serais pas fâché que la réalité de demain permette de reclasser cet article dans la rubrique « politique-fiction ».

Le paysage des normes internationales vient de changer de manière significative. À l'issue d'un des processus les plus controversés et les plus médiatisés qu'on ait jamais vus dans les annales de la normalisation, les spécifications Microsoft/ECMA Office Open XML ont été promues au rang de norme internationale. Microsoft a ainsi effacé son échec provisoire de septembre 2007, tout en donnant au monde une démonstration remarquable de la capacité de retournement qui lui a toujours permis, sinon de prévoir les menaces, du moins de les surmonter d'une manière efficace et parfois inattendue.

La normalisation des formats de documents bureautiques, dont l'idée initiale remonte aux années 1980, avait été systématiquement boudée à Redmond jusqu'au premières années de la présente décennie, bien que l'éditeur ait participé à l'élaboration de nombreux standards dans d'autres domaines. Cela se comprend d'autant mieux qu'un acteur en position aussi largement dominante sur son cœur de marché n'est guère incité, en général, à rendre ses produits interopérables avec ceux de la concurrence, ce qui est précisément l'objectif majeur de la normalisation. Ainsi, c'est l'absence d'implication des éditeurs, et surtout du premier d'entre eux, qui a condamné la première norme applicable dans ce domaine, à savoir ODA (Open Document Architecture), alias ISO 8613. Cette norme, en effet, n'a jamais été implémentée bien que son élaboration (qui a duré 14 ans) ait commencé dès 1985.

C'est dans la période 2003-2005, avec la montée en puissance d'OpenOffice et surtout l'intérêt croissant des administrations pour la spécification ODF (Open Document Format), rejeton émancipé du projet OpenOffice.org devenu plus tard la norme ISO/IEC 26300, que l'état-major de Microsoft a compris qu'il ne pourrait pas durablement éluder le problème de la standardisation des formats bureautiques.

Trois solutions pour Microsoft

Le penchant de plus en plus marqué des gouvernements pour les normes pouvait impliquer, à terme, la nécessité de doter la suite Microsoft Office d'un niveau de compatibilité acceptable avec ODF. Cette menace était techniquement et commercialement intolérable. Elle posait d'abord un problème d'ingénierie. L'architecture des logiciels de la suite Office, élaborée par sédimentations successives et constituée d'éléments de code fortement imbriqués les uns dans les autres, n'est pas techniquement séparable de la structure des fichiers Word, Excel ou Powerpoint. La prise en charge native, sans perte de fonctionnalité, de formats de fichiers définis hors de chez Microsoft n'est donc pas concevable sans un sérieux effort de refonte. Un effort financièrement abordable compte tenu des revenus générés par la suite Office, mais peu conforme à la culture de la maison (où les ajouts fonctionnels immédiatement visibles sont plus prisés que la réingénierie des couches profondes), et surtout commercialement dangereux, puisque le monopole se nourrit d'incompatibilité.

D'un autre côté, un refus d'alignement sur la norme créait un risque tout aussi grave, à savoir la perte potentielle d'une part significative des marchés publics. Or ces marchés constituent depuis toujours, sinon par leur seul volume, du moins par leurs effets d'entraînement directs et indirects, un pilier absolument essentiel du marché des suites bureautiques. Qu'un petit nombre d'administrations de gros calibre, de par le monde, bascule vers une offre bureautique alternative pour cause de conformité à une norme internationale non supportée par Microsoft, et c'est peut-être le début d'une réaction en chaîne dont nul ne sait où elle s'arrêtera. Aucune position dominante ne peut perdurer sur ce marché si son détenteur perd le contrôle du secteur public.

C'est alors que Microsoft, pratiquement mis en demeure de choisir entre deux solutions aussi détestables l'une que l'autre, a choisi la troisième. Le marché voulait une suite Microsoft Office alignée sur les normes internationales ; la réponse a consisté à aligner une norme internationale sur la suite Microsoft Office, en introduisant le projet de norme OOXML, aujourd'hui en passe de devenir la norme internationale ISO/IEC 29500.

Comment l'opération a-t-elle pu réussir malgré l'opposition de tous les concurrents de Microsoft ? C'est en soi un débat très vaste, qui ne fait que commencer et qui va sans aucun doute entraîner des changements significatifs dans la manière dont les processus de décision du JTC1 (le comité technique commun de l'ISO et de l'IEC en charge des technologies de l'information) sont perçus, conçus et organisés. À propos de cette affaire, et indépendamment du résultat désormais acquis, un des coordinateurs du JTC1, Martin Bryan, avait déjà lancé à la fin de son mandat, en novembre 2007, ce cri d'alarme : « Le temps du développement ouvert des standards est en train de disparaître ».

De son côté, la Commission Européenne a annoncé le lancement d'une enquête sur le déroulement de la procédure. Quels que soient les faits, les esprits sont encore trop échauffés pour qu'on puisse dès maintenant analyser avec sérénité les différentes facettes, officielles et non officielles, de cette procédure d'adoption accélérée dont l'étape la plus décisive s'est terminée le 29 mars 2008. Bien entendu, il faudra revenir plus tôt que tard sur ce sujet délicat. Dans l'immédiat, cette décision, quelle que soit sa validité, crée une situation nouvelle dont il convient de tenir compte.

Les trois formats bureautiques

Les trois formats de documents révisables normalisés ne se distinguent pas seulement les uns des autres par leurs  caractéristiques techniques. Chacun est en outre dans une situation unique en son genre.

1. Le format ODA n'a jamais été mis en œuvre dans des applications commerciales largement répandues, mais il est intégralement spécifié.

2. Le format ODF est, au moins en partie (car l'existence d'une implémentation intégrale ne peut jamais être prouvée pour ce type de spécification), réellement utilisé, et intégralement spécifié.

3. Le format OOXML est, lui aussi au moins en partie, réellement mis en œuvre, mais il n'est pas encore spécifié, la version finale du texte n'étant pas disponible. OOXML n'est donc pas encore une norme, c'est une annonce de norme.

Cette dernière remarque peut étonner. Comment a-t-on a pu attribuer le statut de norme internationale à un texte qui n'est pas encore écrit ? En fait, la version d'origine d'OOXML ayant été rejetée par la décision du 2 septembre 2007, des centaines de correctifs ont été décidés en fin février 2008 lors du BRM (Ballot Resolution Meeting) de Genève (Après Genève, dernière ligne droite pour Open XML ?). Seuls quelques-uns de ces correctifs ont été examinés en détail, la plupart ayant été adoptés en bloc et sans vérification de cohérence. L'application de certains de ces correctifs implique la réécriture de chapitres entiers et la restructuration complète du document, dont la version originale comportait déjà plus de 6.000 pages.

Cette chirurgie, si elle est accomplie dans le respect des exigences de qualité applicables aux normes, demandera plusieurs mois d'efforts, voire plus. Elle provoquera sans le moindre doute des débats d'interprétation et fera apparaître des contradictions qu'il faudra résoudre. Cette situation est sans précédent connu. Il n'est pas rare, en soi, que le texte d'une norme fasse l'objet de retouches éditoriales après l'adoption de la norme ; c'est un cas prévu par les règles de l'ISO. Mais ce qu'aucune règle n'a jamais prévu, c'est une refonte de cette ampleur après validation. La conséquence pratique, c'est que nous venons d'adopter une norme qui n'existe pas encore. Dans ces conditions, pourquoi n'a-t-on pas différé l'adoption juste le temps nécessaire pour terminer le travail ?

Cette question nous ramène assez brutalement à une réalité d'ordre politique. En insistant pour faire passer l'adoption du projet avant sa rédaction finale, Microsoft a implicitement admis que l'obtention du label ISO était plus urgent que le contenu de la norme. La seule explication plausible d'un tel ordre des priorités, c'est le besoin vital, pour Microsoft de contrer ODF avant qu'il ne soit trop tard. Quant à savoir pourquoi et comment les agences de normalisation membres de l'ISO, qui sont censés représenter les intérêts industriels de leurs pays respectifs et non les intérêts de Microsoft, ont adhéré à une large majorité à cette vision, c'est un vaste et épineux sujet sur lequel sur lequel il conviendra de s'interroger par ailleurs.

Les trois possibilités pour les acteurs

En tout cas, dans le futur immédiat, et jusqu'à la date de publication d'OOXML (non connue à ce jour), ODF reste le seul format bureautique à la fois normalisé et opérationnel. Pour les différents acteurs concernés, la situation peut donc se résumer ainsi :

1 - Pour Microsoft, un double chantier s'annonce. Il s'agit d'une part de mettre au point, en collaboration avec l'ECMA, une version finale conforme à tous les commentaires validés du BRM, et d'autre part, compte tenu des engagements pris, de mettre Office 2007 (ou au moins une version future de la suite Office) en conformité avec cette version finale. L'une des conséquences techniques de cette évolution sera, à terme, de rendre obsolète l'actuel format d'Office 2007 qui, après avoir été présenté comme la première implémentation de la norme, n'est plus qu'un nouveau format propriétaire.

2 - Pour les éditeurs de logiciels bureautiques, le statu quo est maintenu. L'espoir d'un ralliement futur de l'éditeur dominant au format ODF s'éloigne, et le problème de la compatibilité Microsoft se pose dans les mêmes termes que par le passé. Cette compatibilité ne peut être traitée que par analyse empirique des formats d'Office 2007. Il est à noter que la parution de la version finale d'OOXML ne changera pas grand chose sur ce plan, car la conformité à OOXML n'a en soi aucun intérêt pratique ; la seule nécessité vitale pour les acteurs de la bureautique (IBM, Google et les autres), c'est la compatibilité avec les formats réels de Microsoft, et non avec la représentation théorique de ces formats à travers OOXML. La future spécification, en effet, comportera un tel assortiment de fonctionnalités optionnelles qu'il ne sera pas économiquement raisonnable, pour un éditeur ne disposant pas de la base de codes de Microsoft Office, de produire une solution capable de prendre en charge toutes les combinaisons possibles.

D'autre part, la complexité rédactionnelle et le volume des documents seront telles que l'analyse des fichiers générés par Word, Excel et Powerpoint demandera beaucoup moins d'énergie et suscitera moins de risques d'erreurs que l'étude systématique des spécifications. OOXML est potentiellement un outil de travail adapté à l'écosystème Microsoft, permettant à des partenaires de développer des solutions complémentaires susceptibles de mettre en valeur la suite Office, mais ne présente aucune utilité directe pour la concurrence. Ce n'est d'ailleurs pas par hasard si OOXML n'a été développé et soutenu par aucun éditeur de logiciel concurrent de Microsoft, alors qu'ODF, initialement issu de Sun, a obtenu le ralliement d'acteurs tels qu'Adobe, IBM, Google ou KDE.

3 - Pour les utilisateurs, il n'y a aucun changement à court terme. La base documentaire bureautique installée est encore associée dans sa très grande majorité aux formats Microsoft classiques. Les spécifications OOXML ne fournissant aucun moyen de reprise de l'existant (il n'existe en effet aucun « mapping » public entre les anciens formats et la nouvelle norme), seuls les outils de compatibilité fournis par Microsoft permettent d'assurer une traduction totalement fiable. En d'autres termes, c'est à travers Office 2007 et ses successeurs, et non avec le secours de la norme OOXML, que les utilisateurs gèreront l'hétérogénéité des formats Microsoft Office, une hétérogénéité qui pourrait encore s'accroître dans un proche avenir.

En fait, le passage du statut de standard ECMA à celui, plus prestigieux, de norme ISO est, dans le cas des spécifications Open XML, un événement plus politique que technologique. À la limite, la date à laquelle sortira le texte stabilisé n'a peut-être pas grande importance. Le point réellement important concerne maintenant les gouvernements au sens large. Ceux qui avaient cru naïvement que la normalisation allait permettre à elle seule de réaménager le marché du logiciel bureautique en imposant la mise en concurrence de tous les fournisseurs sur la base d'un standard ouvert sont désormais fixés : le cadre organisationnel d'élaboration des normes, tel qu'il est conçu aujourd'hui, n'est tout simplement pas approprié à un tel objectif.

En agitant trop souvent l'argument « exigeons ODF parce que c'est la norme » comme un chiffon rouge sous le nez de Microsoft, on n'a fait que pousser l'éditeur (qui en avait les moyens) à faire le nécessaire pour obtenir un match nul en poussant sa propre norme. La balle est maintenant dans le camp des donneurs d'ordres publics ; pour eux, et pratiquement dans tous les pays du monde, la loi reste la même : ils peuvent exiger ODF et éliminer OOXML ou inversement, ou encore n'en adopter aucun des deux ; ils peuvent aussi faire le pari très aléatoire des convertisseurs et choisir les deux. Mais ils peuvent aussi bien imposer leur propre définition d'un format ouvert, assortie ou non de références à l'ISO. La décision de s'affranchir du monopole ou de s'en accommoder leur appartient. Comme avant.