Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

L'AFNOR explique son abstention sur la normalisation d'OOXML

afnor iso ooxmlNous nous sommes entretenus avec Olivier Peyrat, le directeur général de l’AFNOR, ainsi qu’avec Frédéric Bon, directeur de la commission de normalisation. Le sujet était bien évidemment la promotion toute neuve du format Open XML en tant que norme ISO, plus précisément la 29 500.

« Normalisation ne rime pas avec procès d’intention »

Il en ressort que le discours général de l’organisme français était clairement lénifiant. Dans une optique d’apaisement des esprits, Olivier Peyrat a tenu à rappeler que le but de « la normalisation n’est pas une guerre de religions. Nous nous sommes avant tout préoccupés des intérêts de tous les acteurs, même les plus petits : il s’agit d’un dialogue ».

Ce dialogue se retrouve dans la commission de normalisation, à laquelle d’ailleurs n’importe quel intéressé peut prétendre participer. C’est d’ailleurs cette ouverture qui a donné lors des premières réunions sur OOXML une telle variété d’avis, dont certains très tranchés et en totale opposition les uns des autres.

Une chronologie importante

La dimension historique du processus au sein de l’AFNOR est capitale. Lorsque l’ECMA International a transféré par la procédure rapide (fast track) le format OOXML à l’ISO (norme ECMA 376), une autre norme ISO dans le domaine des formats de données bureautiques existait déjà : l’ISO 26300, que l’on connaît mieux sous l’appellation d’OpenDocument Format. Les procédures ont été similaires : l’OASIS a envoyé l’ODF à l’ISO.

Ainsi donc, l’AFNOR a plongé son nez dans la proposition de l’ECMA qui, à l’époque, contenait plus de 6000 pages de spécifications. Un travail énorme qu’il a fallu élaguer. La suggestion la plus forte de l’AFNOR a été un découpage de l’OOXML en deux segments majeurs :
  • La partie Core, qui regroupe ce qui est nécessaire à la gestion des nouveaux documents
  • La partie Extensions, qui contient tout ce qui concerne la gestion des anciens documents et leur traduction
isoCe découpage était nécessaire pour plusieurs raisons. Selon Frédéric Bon, directeur de la commission de normalisation, l’objectif était de pouvoir assoir la partie Core devant l’ODF et de les faire correspondre. En l’état, l’OOXML pouvait avoir plusieurs équivalents à une fonction issue de l’ODF, ce qui compliquait largement la tâche des traducteurs de documents et ouvrait la voie à une difficile harmonisation.

Une proposition très mal accueillie

Cette proposition de l’AFNOR a été très mal accueillie par les autres pays, mais a finalement fait son chemin jusqu’à s’imposer. De fait, quand l’ECMA a proposé en janvier une nouvelle version d’OOXML, les spécifications de ce dernier étaient bien décomposées en deux ensembles :
  • OOXML Strict, correspondant à la partie Core
  • OOXML Transitionnal, correspondant à la gestion des anciens documents (Extensions), un sujet abordé dans notre conversation avec Bernard Ourghanlian aujourd’hui même
Principal intérêt de ce découpage : si un éditeur ou un développeur souhaite intégrer dans son application la possibilité de créer et lire des documents OOXML, et seulement ces documents-là, son travail en est désormais largement simplifié, car les spécifications sont plus réduites. Il faut dire que Microsoft avait créé un vaste fourre-tout incluant un grand nombre de fonctionnalités héritées de la suite Office, et donc franchement hors-sujet pour les tiers.

office 2007 ultimateC’est cette « confusion des genres » selon Frédéric Bon qui a mené l’AFNOR à préconiser ce découpage, ce qui a finalement été retenu. La simplification de l’implémentation était certes un objectif, mais la cohabitation avec l’ODF en était une autre. À ce sujet d’ailleurs, le DIN allemand (l’équivalent de l’AFNOR en France) souhaite créer un groupe de travail pour rapprocher les deux formats. Dans cette optique, l’AFNOR a été invitée à participer, et a accepté. Sont visées la convergence des deux normes, ainsi que la bijectivité : une fonction dans ODF ne peut avoir qu’une fonction équivalente au maximum dans OOXML, et réciproquement.

Du non vers l'abstention

Pourtant, l’AFNOR s’est abstenue de voter samedi. Pourquoi ? Olivier Peyrat indique que l’organisme était parfaitement « conscient que c’était la pire des réponses. Les interprétations peuvent en effet être nombreuses : manque de courage, désintéressement du sujet. Toutefois, la situation unique nous a conduit à cette issue ».

Cette fameuse « situation » peut être résumée comme suit :
  • L’AFNOR ne pouvait pas voter « non », car les progrès en 14 mois étaient conséquents
  • Elle ne pouvait pas non plus voter « oui », car la version finale de l’ECMA 376 n’était pas entre leurs mains
Sans la présence de cette version finale, l’AFNOR ne pouvait pas voter non plus aveuglément oui. Toutefois, à ce sujet, Frédéric Couchet, délégué général de l’April, nous a indiqué que l’organisme était parti initialement sur un « non », et qu’il s’est manifestement passé quelque chose d’important, comme un ordre émanant par exemple de l’Élysée ou du ministère des finances.

Parmi les raisons qui ont poussé l’AFNOR à revoir sa position, Olivier Peyrat a cité des documents qui sont arrivés dans les mains des membres de la commission de normalisation à la dernière minute. Microsoft et HP, entre autres, se sont engagés à participer activement à l’évolution de la norme. Des engagements pris très au sérieux par l’organisme national, Olivier Peyrat expliquant à ce sujet que tout changement ultérieur de position « grillerait » les intéressés dans le futur. Un argument que réfute d’ailleurs Frédéric Couchet, qui précise qu’une société comme Microsoft n’a que faire de ce genre de menace éventuelle.

Il reste malgré tout des doutes et des zones d’ombre dans le processus de normalisation. Interrogés à ce sujet, Olivier Peyrat n’a pas souhaité faire de commentaires, tandis que Frédéric Bon a estimé qu’il n’avait subi aucune pression. Selon lui, le déroulement du processus à la commission de normalisation a été conforme.
12 commentaires
Avatar de WereWindle INpactien
Avatar de WereWindleWereWindle- 07/01/20 à 09:26:15

Xiaomi a confirmé le bug auprès de plusieurs de nos confrères, en précisant qu’il est la conséquence d’une mise à jour du 26 décembre sur la gestion du cache.

Du coup, peut-on en déduire que c'est un cache centralisé chez Xiaomi (puisque des flux d'utilisateurs différents se retrouvent mélangés) ? On ne perd pas un peu l'utilité/l'intérêt du cache dans ce cas-là (ie cache non local) ?

Avatar de felinix INpactien
Avatar de felinixfelinix- 07/01/20 à 09:33:39

Est-ce que cela signifie que ceux qui avaient le Google Hub pouvaient accéder aux images des caméra Xiaomi qui n'étaient pas connectées à des Google Hub ? Car si c'est le cas, c'est plutôt grave, ça va encore accroître ma suspicion envers les objets connectés.

Avatar de brice.wernet Abonné
Avatar de brice.wernetbrice.wernet- 07/01/20 à 09:39:12

C’est tellement commun de sacrifier des tests pour vendre à Noël…
Tout comme le fait de prendre l’équipe qui n’a que faire des aléas du réseau et qui va développer un truc qui ne sait pas gérer/reprendre sur réseau «instable».
Tous les appareils semblent conçus maintenant sans considération que internet n’est pas dispo H24, que l’on peut choisir d’arrêter régulièrement les appareils et que les appareils ne sont pas seuls sur le réseau et pas prioritaires.
 
 

Avatar de pv_le_worm Abonné
Avatar de pv_le_wormpv_le_worm- 07/01/20 à 09:57:08

brice.wernet a écrit :

C’est tellement commun de sacrifier des tests pour vendre à Noël…

C'est pas tant pour vendre à Noël que de proposer des caméras connectées à prix ultra compétitifs. A force de toujours vouloir des produits bon marché, voilà ce qu'il se passe.

Avatar de Jossy Abonné
Avatar de JossyJossy- 07/01/20 à 12:17:11

Il n'y a jamais eu (et il n'y aura jamais) de faille sur des produits chers ? :mdr: :mad2:

Avatar de gg40 INpactien
Avatar de gg40gg40- 07/01/20 à 13:21:31

Cisco ? :oops:

Avatar de WereWindle INpactien
Avatar de WereWindleWereWindle- 07/01/20 à 13:24:34

gg40 a écrit :

Cisco ? :oops:

it's not a bug, it's a feature :fumer:

:transpi:

Avatar de gg40 INpactien
Avatar de gg40gg40- 07/01/20 à 13:27:45

WereWindle a écrit :

it's not a bug, it's a feature :fumer:

:transpi:

 Apple ! :bravo:

Édité par gg40 le 07/01/2020 à 13:28
Avatar de misterB Abonné
Avatar de misterBmisterB- 07/01/20 à 13:48:18

gg40 a écrit :

Apple ! :bravo:

Au départ c'était attribué a MS cette vanne, mais les temps changent :D:D

Avatar de WereWindle INpactien
Avatar de WereWindleWereWindle- 07/01/20 à 14:36:16

après une rapide recherche (c'était MS dans ma tête aussi), ça date de bien plus loin
-> It's not a bug it's a missing feature
-> it's not a bug, it's an undocumented feature
-> It's not a bug, it's IBM Standard
(ces trois là semblent les plus anciennes

Ensuite effectivement ça a été raccroché à MS (facile quand ça touche une part non négligeable des utilisateurs informatiques :mdr:) au point de faire croire qu'ils en étaient à l'origine.

(Maintenant c'est applicable à quiconque qui nierait l'importance d'un bug - Bethesda, Ubi, EA, Blizzard... un peu tout le monde en fait)

Abraham Lincoln a écrit :

Le problème sur Internet c'est qu'on n'est jamais sûr des sources

fin de la digression culturelle :transpi:

Il n'est plus possible de commenter cette actualité.
Page 1 / 2