Le processus de normalisation d'openXML engagé à l'ISO
Eh bien c'est lancé ! le processus de normalisation du format de données openXML est désormais lancé au sein de l'ISO. Petit retour sur les dates / étapes :
- l'ECMA international a normalisé le format de document openXML (norme ECMA-376) le 7 décembre dernier (voir ci-dessous et ce lien) ;
- l'ECMA a immédiatement proposé que ce format soit normalisé ISO selon une procédure dite "fast track" (rapide). En effet, il existe un comité commun entre l'ISO et l'ECMA - le JTC-1 (Joint Technical Committee) qui permet à l'ECMA de proposer une normalisation ISO de ses propres standards. Ce processus dit de "fast track" se décompose comme suit :
- Une période d'un mois où les membres de l'ISO doivent dire s'ils perçoivent une "contradiction évidente" (percieved contradiction) avec le projet de norme ECMA proposé et des normes ISO déjà existantes. C'est cette période qui a donné lieu à un certain nombre de commentaires de différents membres de l'ISO. L'ECMA a, dans la foulée, publié sa réponse à ces commentaires. Réponse qui a été jugée satsfaisante par l'ISO, ce qui permet d'enclencher la seconde phase de la procédure "fast track".
- Cette seconde phase dure 5 mois a a débuté le 2 avril dernier ainsi que l'indique le communiqué de l'ECMA. Elle doit permettre de travailler au fond (la phase initiale de "contradiction" permet juste d'éviter d'entrer dans un processus lourd de normalisation ISO si on voit de manière claire des contradictions avec d'autres normes). Bref, cela amène à une fin des travaux le le 2 septembre -soit un gros travail pendant l'été - pas idéale comme période...
Bon, après ce petit descriptif pédagogique, la seule question à ce poser est pourquoi cette normalisation ISO est-elle nécessaire ? Qu'apporte-t-elle de plus que celle de l'ECMA ?
En fait, si l'ECMA est un organisme de normalisation international reconnu, ses normes n'ont pas le même statut que celles de l'ISO, car sa composition n'est pas la même. L'ECMA est un consortium d'entreprises créé en 1961 et comptant environ une cinquantaine de membres. L'ISO quant à lui est un réseau de 157 organisations nationales de standardisation - en France, c'est l'AFNOR qui fait partie de ce réseau. Bref, on considère souvent que l'ISO donne une force supplémentaire aux normes car engage les états. L'inconvénient ? C'est évidemment la lourdeur du processus d'élaboration d'une part et d'évolution d'autre part de ces normes. L'institution ISO est souvent vue comme inadaptée à un monde en rapide évolution comme les technologies de l'information.
Pour l'histoire de l'ECMA, suivre ce lien. Pour celle de l'ISO, celui-ci.
De manière un peu contradictoire, on pourrait donc penser qu'un acteur ayant été aux fondements de la norme openXML (en l'occurence Microsoft) n'a que peu d'intérêt à voir cette norme devenir ISO. Autant, on pourrait l'accuser de pouvoir manipuler l'ECMA (en réalité, tous ceux qui connaissent ces organismes savent que du mythe à la réalité, il y a un fossé souvent infranchissable), autant manipuler un organisme comme l'ISO devient virtuellement impossible, ne serait-ce que par le nombre de membres du réseau et leur statut semi-public. Bref, une normalisation ISO semble au final le meilleur moyen de s'assurer que Microsoft perd toute capacité à maîtriser ce format de données, donc offre une garantie supplémentaire d'ouverture, de documentation à jour et de pérenité.
Alors, pourquoi cette démarche de normalisation ISO chez Microsoft ?
On peut raisonnablement imaginer que la principale motivation est le statut de norme ISO du format concurrent (ODF), et que Microsoft reconnaît là, l'importance de cette normalisation complément indépendante. Il faut également souligner que plusieurs états recommandent désormais l'utilisation de normes ouvertes pour les besoins de leurs administrations (on ne peut qu'applaudire et c'est le cas de la France qui a posé ce principe et doit confirmer ces choix dans un document technique en préparation, le Référentiel Général d'Interopérabilité - on y reviendra). En résumé, pas le choix pour Microsoft s'il veut pouvoir fournir ses technologies pour les marchés publics.
Faut-il s'opposer à cette démarche ?
J'ai beau reposer le problème dans tous les sens, à moins de mener une croisade anti-microsoft et de voir là un moyen de bouter le géant américain hors de France (pourquoi pas, mais je suis sceptique sur ce qu'on y gagnerait), je ne vois pas l'intérêt de s'opposer à cette normalisation ISO. Bien au contraire, il me semble que tout utilisateur "moyen" a un intérêt évident que les formats de ses documents soient de réelles normes ISO ouvertes et documentées qu'un acteur particulier - fut-il aussi puissant que Microsoft - ne pourra pas refermer ultérieurement. De plus, si, d'un point de vue pragmatique, on considère que ce format va être assez largement utilisé, ne serait-ce que par les utilisateurs de la suite Office, indépendamment de son statut de norme ISO, on a un double intérêt à s'assurer que ce format -qui risque de devenir un standard "de fait"- soit normalisé ISO.
Alors, tout est-il rose ?
Non, bien évidemment, et le diable se cache toujours dans les détails. Il faut évidemment s'assurer que les spécifications d'openXML sont complètes, exhaustive, cohérentes et "implémentables". C'est le rôle de la période de 5 mois qui s'ouvre. Bon, 6000 pages en 5 mois, ça va être tonique.
Il faut également s'interroger sur les processus à mettre en oeuvre pour que les futures versions de cette norme soient également des normes ISO. En effet, il ne faudrait pas que, sous couvert d'innovation, on arrive à des évolutions qui fassent que cette norme bourgeonne à nouveau et devienne liée à un logiciel spécifique car implémentée par un seul éditeur. Au final, la seule question de fond pour laquelle la période de 5 mois doit donner une réelle réponse est donc bien : comment seront gérer les prochaines versions de cette norme ? Comment s'assurer que ni l'ECMA, ni Microsoft, ni un autre acteur ne puisse rendre les futures versions de cette norme incompatibles entre elles. Cette question me semble d'ailleurs à poser pour ODF en parallèle et PDF quand ce format sera normalisé.
En conclusion :
J'ai peur que la "communauté du libre" (je ne sais pas trop ce que signifie cette expression) se trompe de bataille. Plutôt que de s'épuiser à reprendre des arguments plus ou moins vérolés et approximatifs, et mèner un combat d'arrière garde, il vaudrait mieux que la communauté des développeurs se saisisse à bras le corps de cette nouvelle norme pour en traquer les manques / contradictions / omissions. Laissons la politique au vestiaire (IBM et Microsoft gèrent cette partie), et travaillons réellement sur le plan technique, en n'oubliant évidemment pas d'inclure dans cette réflexion les processus à prévoir d'évolution de cette norme. Bref, profitons de l'opportunité qui nous est offerte pour définitivement sortir les formats de documents des mains des Microsoft, Sun, IBM et consors - tous les utilisateurs s'en proteront mieux...
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :