Alors que les résultats ne devaient pas être dévoilés officiellement avant mercredi 2 avril, un membre de l'instance de normalisation néerlandaise a lâché le morceau : l'ISO a finalement adopté Office OpenXML comme standard international.
Le format de fichier ouvert de Microsoft, déjà normalisé par l'Ecma, avait de sérieux adversaires, tels que IBM, Sun ou Google, qui soutiennent un format bureautique déjà normalisé par l'ISO, ODF (Open Document Format).
Au final, sur les 87 pays ayant voté, 61 ont approuvé le standard, 10 ont voté contre et 16 (dont la France) se sont abstenus. Surtout, sur un total de 32 pays participants (ayant le statut de 'P-member') ayant voté, 24 ont approuvé, ce qui est au-delà de la majorité des deux tiers requise pour valider un standard.
Les résultats détaillés sont rassemblés dans un fichier PDF, téléchargeable.
CIO-Online.com : Vous venez de recevoir un appui surprenant...
Marc Gardette :Ce n'est pas la première fois que Patrick Durusau, éditeur des évolutions d'ODF au sein de l'Oasis, publie un papier dans ce sens sur son blog. Il rappelle avec à propos que l'objectif est d'améliorer le texte de la norme finale. Et c'est un succès de ce côté, avec une amélioration notable de la qualité du texte. Il souligne également l'opportunité de s'inviter à la table de discussion et de prendre le contrôle d'une spécification quand Microsoft en donne la possibilité.
C'est une preuve de bon sens dans le psychodrame de la guerre de religions qui se livre actuellement. Nous avons fait toutes les démarches dans la transparence, ce serait dommage que l'on s'arrête là ! En revanche, on ne peut que déplorer la querelle que nous livre la blogosphère.
Où en est la démarche de l'ECMA vers la normalisation d'OOXML ?
Dans le cadre du Fast Track [procédure accélérée, NDLR], l'objectif du RM [réunion de conciliation, NDLR] est la validation de propositions qui dans l'état n'impactent pas le projet de résultat final. Il y a eu beaucoup de commentaires éditoriaux, en particulier par l'Afnor. Au delà de ces questions de virgules dans un document, plus de 200 commentaires répartis en 43 lots ont été discutés. Pour le BRM [Ballot resolution meeting, conférence de résolution du vote, NDLR], beaucoup de questions ont été résolues, et 98,44% des commentaires ont été approuvés. Seulement 4 votes formels ont été refusés.
Le BRM a joué son rôle pour améliorer le texte de la norme technologique. Les pays ont un mois pour infléchir leur première décision s'ils le souhaitent et envoyer, nous l'espérons, un courrier officiel de reconnaissance du processus.
Vous pensez donc arriver à un consensus qui vous sera profitable ?
Tous les commentaires ne permettent pas d'arriver à une spécification parfaite dès sa version 1.0. Mais la 1.1, et même la 1.2 sont déjà dans les tuyaux. De plus, tous les commentaires non résolus ne sont pas productifs.
Nous sommes sereins dans la mesure où nous estimons que tous les commentaires importants ont été résolus. Cependant, si aucun pays ne change son vote, OOXML n'ira pas à la norme ISO. La question est de savoir s'ils estiment qu'ils disposent de suffisamment de changements pour changer de vote. On ne peut que constater qu'il n'y a pas beaucoup de standards qui ont été autant placés sous la loupe. Ce qui est sûr, c'est que cette opposition s'est traduite par des améliorations apportées au texte.
Que va-t-il en ressortir pour votre format de fichiers Office ?
Nous avons identifié les fonctions transitoires et séparé deux schémas. Les schémas stricts apportent le 'pure core' de OOXML et sont identifiés par des clauses de conformité. Nous avons également défini les schémas transitionnels. C'est à celui qui crée sous Office de déclarer son document selon le schéma retenu.
Les discussions tournent autour des modifications apportées au texte soumis à la normalisation. Mais avez-vous modifié votre code ?
Nous allons être amenés à modifier le code. D'ailleurs nous l'avons déjà fait pour être en conformité avec la norme ECMA.
Pour certaines entreprises clientes de Microsoft, le processus de normalisation d'OpenXML, le format de document ouvert proposé par l'éditeur, est un non-événement. Les Autoroutes du Sud de la France (ASF) ont ainsi fait le choix de s'appuyer sur OpenXML pour mettre en oeuvre un processus métier, dans la mesure où la suite bureautique Office était de toute façon déjà déployée sur les postes des utilisateurs.
Les ASF proposent aux usagers des autoroutes des produits commerciaux, dont les abonnements au télépéage. Les hôtesses, dans les boutiques recevant la clientèle, doivent saisir les informations sur les clients et éditer les contrats. Un travail qui imposait une double saisie, dans Word d'une part, et dans le back-office d'autre part via une interface Web. Or, qui dit double saisie dit risque d'erreur accru et temps perdu.
Automatiser le flux de données entre Word et l'application back-office
« Nous avons voulu automatiser, explique Alain Metge, architecte logiciel au sein des ASF. En prévision notamment de notre projet de gestion de la relation client : nous souhaitons pouvoir fournir aux gens un contrat pré-rempli à nous renvoyer, afin qu'ils puissent s'inscrire en ligne. »
La première idée d'Alain Metge est d'installer Word sur un serveur, afin de générer automatiquement le document. « Nous avons fait des essais, explique-t-il, mais cela ne fonctionne pas en tâche de fond. Nous avons aussi essayé de générer du PDF à partir de Word avec un utilitaire ActiveX, mais c'était assez statique, le modèle PDF était lourd à modifier. Puis est arrivé OpenXML. »
La possibilité d'échanger des données en XML entre le back-office (un développement maison sur base Oracle) et le front-office (Word 2003) séduit les ASF. Autre bénéfice attendu et permis par cette solution : « la possibilité de visualiser et de modifier les documents avant l'envoi au client », indique Alain Metge.
[[page]]
Les développements sont réalisés par un prestataire « qui ne connaissait pas OpenXML », précise Alain Metge, en un peu plus d'un mois. Le framework .Net est installé sur le serveur, afin de pouvoir y exécuter le service applicatif chargé de prendre le modèle de document et d'y fusionner les données, au moyen de commandes XML classiques (telles que des requêtes Xpath). Les modèles sont quant à eux créés par le service commercial d'ASF, équipé pour l'occasion de la dernière version du traitement de texte de Microsoft, Word 2007. Les modèles prévoient un certain nombre de champs qui accueilleront les données et sur lesquels les utilisateurs en boutique ne peuvent intervenir. En revanche, ces utilisateurs peuvent déplacer ces champs au sein du document pour personnaliser les contrats avant de les imprimer ou de les envoyer.
Un service adapté aux besoins, non soumis à des contraintes de montée en charge
Toutes ces manipulations peuvent être effectuées par les hôtesses avec la version 2003 de Word installée sur leur poste. « Comme Word 2007 génère du Docx, nous avons installé l'add-in d'Office 2003 pour ouvrir et sauvegarder en 2007, raconte Alain Metge. En attendant de migrer les postes sous Word 2007. » Au final, l'hôtesse saisit donc les données dans le formulaire Web, et reçoit en quelques secondes le document Word à éditer. Un module permet au besoin de transformer le document en PDF.
Etant donné que les ASF disposent d'un contrat entreprise auprès de Microsoft, le coût de la solution est minime. Cela se limite au prix d'un prestataire pendant un mois et à la licence du générateur de PDF. Mais il est vrai, reconnaît volontiers Alain Metge, que le service applicatif considéré ne pose pas de souci de volumétrie ou de montée en charge. Du côté des évolutions, l'architecte des ASF attend juste que la fusion des données soit plus simple, « surtout en ce qui concerne les tableaux ». De même, dit-il, « nous avons manqué d'un peu de documentation, mais cela commence à s'étoffer ».
