Cette situation inquiétante s'est dénouée en quelques mois :
- Dénonçant des irrégularités dans la procédure de décision, quatre pays ont fait appel de la décision de l'ISO : le Venezuela, l'Afrique du Sud, le Brésil et l'Inde ;
- Microsoft a annoncé que la prochaine mise à jour de sa suite bureautique Microsoft Office utiliserait nativement le seul format vraiment ISO OpenDocument (ODF) et ne prendrait plus en charge MS-OOXML ;
- Suite aux appels des quatre pays sus-mentionnés, l'ISO a alors suspendu la publication de la norme MS-OOXML.
Acte premier : OpenDocument, enfin une norme de format bureautique.
Mai 2005 : L'OASIS (association d'entreprises pour la promotion de formats ouverts basés sur XML) normalise OpenDocument Format.
Ce format est issu d'OpenOffice.org, mais a été rédigé par un comité ouvert. C'est donc le premier format de bureautique ouvert de l'histoire, ce qui met fin à des décennies de cauchemars d'incompatibilités et de conservation des documents. De nombreuses entreprises soutiennent ce format, qui est utilisé par d'autres suites bureautiques, notamment IBM Lotus Symphony, KDE KOffice, Gnome Office avec Gnumeric/Abiword et plus récemment Microsoft Office, par l'ajout d'un greffon.
Mai 2006 : l'ISO normalise ODF (OpenDocument Format, créé par OpenOffice.org).
OpenDocument devient ainsi le premier format bureautique normalisé de l'histoire, ISO 26300:2006. Le chemin est tout tracé vers un unique format commun à toutes les suites bureautiques.
De plus en plus d'organisations et pays demandent en effet un format normalisé et ouvert pour les échanges de documents.
Acte II : OpenXML, un concurrent !
Décembre 2006 : l'ECMA normalise Office OpenXML, de Microsoft.
MS-OOXML, issu d'un développement interne de Microsoft, est ainsi le second format bureautique ouvert. Il est utilisé nativement par Microsoft Office 2007, dernière version de la suite bureautique la plus utilisée au monde. En revanche, aucune suite bureautique ne l'utilise, ce qui n'est pas surprenant pour un jeune développement interne.
Novell, éditeur d'une distribution Linux et partenaire de Microsoft, rédige un greffon de prise en charge de MS-OOXML pour OpenOffice.org. Ce greffon utilise la technologie Microsoft .Net, qui s'éloigne de celles utilisées par OpenOffice.org. Ce greffon n'est mis à disposition que pour les systèmes de Microsoft et de Novell, et ne sera jamais inclus dans le développement principal d'OpenOffice.org. De plus, ce logiciel qui mériterait un grand rayonnement n'est pas mis en valeur, ne dispose ni d'un site dédié, ni d'une documentation accessible, et il semble difficile de d'en obtenir les sources, et même de connaître la licence sous lequel il est publié.
Mars 2007 : Microsoft présente MS-OOXML à l'ISO, pour une normalisation accélérée. La guerre des formats bureautique commence donc vraiment.
<http://linuxfr.org/2007/03/13/22209.html>
Septembre 2007 : MS-OOXML est refusé par l'ISO. De nombreuses irrégularités de la part de Microsoft sont dénoncées dans la procédure de vote. La procédure de normalisation continue plus lentement, en tenant compte des avis émis par les organismes membres de l'ISO.
Avril 2008 : l'ISO accepte MS-OOXML. Encore plus d'irrégularités sont à déplorer, notamment des changements d'avis au dernier moment d'organismes pourtant partisans de la non-normalisation.
Maintenant, deux formats bureautiques normalisés et ouverts s'opposent ouvertement, ce qui nous éloigne de l'objectif d'un format commun interopérable.
Acte trois : la chute d'OpenXML
Mai 2008 : Microsoft annonce que la prochaine mise à jour de Microsoft Office apportera une gestion native d'ODF et un retrait de celui de MS-OOXML.
Mai 2008 : en une semaine, le Vénézuela, l'Afrique du Sud, le Brésil et l'Inde font appel sur la décision de l'ISO.
Juin 2008 : suite à ces appels, l'ISO interrompt la publication de la norme MS-OOXML. MS-OOXML sera peut-être publié en tant que norme après résolution de ces appels, donc dans plusieurs mois.
Juin 2008 : un représentant de Microsoft, Stuart McKee, explique qu'ODF a gagné la guerre des normes de formats ouverts de bureautique.
Épilogue : la victoire de l'interopérabilité
La situation actuelle correspond donc précisément à l'objectif initial d'OpenDocument : un unique format bureautique ouvert et normalisé, destiné à être utilisé par toutes les suites bureautique du marché. Cela garantit donc, au moins dans ce domaine, une concurrence loyale et une garantie de pérennité des documents.
Aller plus loin
- DLFP : Le format OpenDocument approuvé par l'ISO (5 clics)
- DLFP : Open XML en force (7 clics)
- DLFP : La guerre des formats de bureautique normalisés ISO commence (7 clics)
- Microsoft Office 2007 to Support ODF - and not OOXML (4 clics)
- ISO puts standard for Microsoft's OOXML document formats on hold (3 clics)
- Red Hat Summit panel: Who 'won' OOXML battle? (2 clics)
# Mais bien sûr ...
Posté par Julien (site web personnel) . Évalué à 10.
http://www.theinquirer.net/gb/inquirer/news/2008/06/20/odf-clearly-won-microsoft-exec
Microsoft n'est pas près de lâcher le morceau. Encore un peu de graissage de patte et l'OOOXML sera reparti de plus belle ...
[^] # Re: Mais bien sûr ...
Posté par HoloAddict (site web personnel) . Évalué à 3.
Dans tout les cas, c'est un bon point pour l'ODF, c'est indéniable.
Sinon, par contre, j'ai pas tout compris quand au support du "peut-être futurement normalisé" OOXML. Il garde leur implémentation non standard ou feront un effort pour supporter la version ISO (si elle sort) ?
[^] # Re: Mais bien sûr ...
Posté par pasBill pasGates . Évalué à 5.
MS ne va rien enlever du tout, ils ont simplement annonce que l'update de Office pour supporter la version ISO viendra dans la prochaine version et pas dans le service pack.
[^] # Re: Mais bien sûr ...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
[^] # Re: Mais bien sûr ...
Posté par thierry talbert (site web personnel, Mastodon) . Évalué à 10.
De toute façon je crois qu'il faudra juger sur les faits et non sur des effets d'annonce.
Si la prochaine version n'implémente que ODF alors oui c'était vrai sinon si il a les 2 et bien là faudra voir comment ils l'ont implémenté (partiel ou total), si ils dénigrent ou pas ODF ou OOXML etc. etc.
patience, patience...
mais surtout vigilance...
Thierry
[^] # Re: Mais bien sûr ...
Posté par Jean-Michel Philippe (site web personnel) . Évalué à 5.
[^] # Re: Mais bien sûr ...
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Inkscape rajoute des informations qui lui sont propres dans les svg par défaut, mais ils n'empêche en rien l'intopérabilité, on peu enregistrer dans un format svg uniquement.
Bref, dans ton cas avec illustrator, soit inkscape ne gère pas bien le SVG, soit c'est illustrator, ou les deux. \o/
Mon avis partiale et totalement infondé c'est que illustrator ne gère pas bien le svg.
[^] # Re: Mais bien sûr ...
Posté par Psychofox (Mastodon) . Évalué à 3.
[^] # Re: Mais bien sûr ...
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Tiens il n'existe pas de validateur svg à l'instar du validateur (x)html ?
[^] # Re: Mais bien sûr ...
Posté par Rémi Hérilier . Évalué à 10.
yapluka comme dirait l'autre :-)
# Et le RGI ?
Posté par Grumbl . Évalué à 0.
[^] # Re: Et le RGI ?
Posté par Houbaa . Évalué à 0.
[^] # Re: Et le RGI ?
Posté par Jean M. . Évalué à 4.
Un document qui donne les règles de création, de diffusion et d'archivage des documents émis par l'administration.
Il n'est pas respecté et de nombreux responsables des services informatiques n'en n'ont pas connaissance.
Actuellement, à la DGI les poste de travail sont obligatoirement sous Windows XP avec Office 2000 et IE6.
Il est préconisé dans le RGI de faire des document en HTML ou et PDF... il sont fait en RTF.
Un partie de l'IntraNet (application interne) avait été développé en utilisant SVG ... la dernière version a été corrigé et utilise dorénavant VML (compatible uniquement avec IE).
Le RGI ne semble pas avoir évolué depuis 2006.
J'en ai récupéré une version sur Internet il y a quelques mois (dans un format inconnu tout juste lisible)
[^] # Re: Et le RGI ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
Pour ceux qui n'auraient pas tout suivi, un résumé et les liens essentiels vous attendent sur http://pjarillon.free.fr/rgi/
[^] # Re: Et le RGI ?
Posté par Earered . Évalué à 4.
Il est interdit de migrer vers un format bureautique autre que odf à partir des format traditionnellement utilisé.
PDF concerne les documents informatif, pas les document de travail
HTML est déconseillé XHTML est recommandé
>Un partie de l'IntraNet (application interne) avait été développé en utilisant SVG ... la dernière version a été corrigé et utilise dorénavant VML (compatible uniquement avec IE).
Quel logiciel exactement? Parce que je n'ai pas souvenir d'un marché sans une compatibilité IE/Firefox (à moins que ça ne soit un développement 100% interne, mais ça c'est comme les poissons volant, ça existe, mais ça n'est pas la majorité).
>Le RGI ne semble pas avoir évolué depuis 2006.
Putain, si: le passage de la recommandation de xmlshema à relaxng pour les spécifications de format xml
>J'en ai récupéré une version sur Internet il y a quelques mois (dans un format inconnu tout juste lisible)
En PDF....
[^] # Re: Et le RGI ?
Posté par croux . Évalué à 3.
Il est interdit de migrer vers un format bureautique autre que odf à partir des format traditionnellement utilisé.
Si le document a été créé originellement en RTF et qu'il est resté en RTF alors il n'y a pas eu de migration. Et si un document d'un autre format a été converti en RTF, tant que ce nouveau document n'en constitue pas la nouvelle version officielle, on ne peut pas parler de migration.
Enfin à quoi bon avoir établi les préconisations du RGI si elles ne deviennent pas des obligations accompagnées de sanctions en cas de violation ?
[^] # Re: Et le RGI ?
Posté par Jean M. . Évalué à 1.
Un partie de l'IntraNet (application interne) avait été développé en utilisant SVG ... la dernière version a été corrigé et utilise dorénavant VML (compatible uniquement avec IE).
Quel logiciel exactement? Parce que je n'ai pas souvenir d'un marché sans une compatibilité IE/Firefox (à moins que ça ne soit un développement 100% interne, mais ça c'est comme les poissons volant, ça existe, mais ça n'est pas la majorité).
Il s'agit d'un développement purement interne, LEONARD, qui permet de documenter les chaines de logiciels tournant sur Grands Systèmes. C'est un produit sympa (avec quelques manques), il impose une certaine rigueur entre les études et la recette pour mise en exploitation, et c'est bien ! Ce logiciel, s'il était portable, pourrait servir à d'autres service de développement Grands Systèmes, comme il s'agit d'un développement payé par le contribuable, il devrait (à mon avis) être mis en "open source" pour aussi bénéficier des évolutions proposées par la communauté, la DGI restant chef de projet.
C'est hors sujet, mais sait-on s'il y a des contributions extérieures sur le logiciel SPIP dans sa version AGORA développée par l'administration ?
Cordialement,
[^] # Re: Et le RGI ?
Posté par Earered . Évalué à 3.
Maintenance jusqu'en mai 2008 (sic), et analyse post mortem de ce qu'il ne faut pas faire:
http://www.agora2spip.agora.gouv.fr/Modes-de-contribution-a-(...)
[^] # Re: Et le RGI ?
Posté par Earered . Évalué à 4.
Pour l'État, la mise à disposition à d'autres services (concrètement, c'est surtout ça) passe par admisource: http://admisource.gouv.fr/ (tient, y'a encore un terme adèle qui traine).
Ensuite les contributions extérieures ne viennent pas exactement spontanément, ce serait plutôt des services pour qui le logiciel est déjà utile (donc non portable et spécifique IE, ça exclut pas mal de chose), et qui ont la même démarche sur leur contributions (puisque ça demande du temps de transférer le développement spécifique, l'intérêt étant de ne pas maintenir une branche séparé comme spip-agora (même si le fork est parfois utile, quand le chef de projet a tendance a prendre de mauvaise décision par exemple)).
# ODF pose certains problèmes
Posté par croux . Évalué à 4.
On nous parle de norme ISO pour ODF, mais celle-ci ne s'applique pour le moment qu'à la version 1.0 du format ODF qui a déjà été supplantée dans OpenOffice.org par la 1.1 depuis un an. Et voilà que depuis quelques temps déjà on nous parle de la future version 1.2...
Un format pour devenir une norme exploitable, devrait au moins perdurer quelques années sans évoluer, il me semble.
[^] # Re: ODF pose certains problèmes
Posté par vida18 . Évalué à 7.
[^] # Re: ODF pose certains problèmes
Posté par groui . Évalué à 3.
http://iw-linux.over-blog.com/
[^] # Re: ODF pose certains problèmes
Posté par IsNotGood . Évalué à 7.
Notons bien que ODF 1.1 et ODF 1.2 ont la compatibilité ascendante avec ODF 1.0. C'est trivial pour convertir du ODF 1.[12] en ODF 1.0 et encore plus pour convertir du ODF 1.0 en ODF 1.[12] (il n'y a pratiquement rien à faire).
Il ne faut pas se laisser abuser par la succession de versions d'ODF. ODF est un format bien né dont la pérennité ne peut être remise en cause (en tout cas aujourd'hui)
Mais ODF a aussi besoin d'évoluer. ODF 1.2 sera normalisé ISO. Il sera facile (et FIABLE !) de convertir les fichiers ODF 1.0 en ODF 1.2. Les programmes qui supportent ODF 1.2, supporteront "naturellement" ODF 1.0 (c'est facile à faire).
Convertir du .doc en MS-OOXML, c'est la merde. Mais ça n'a rien à voir avec ODF.
> On nous parle de norme ISO pour ODF, mais celle-ci ne s'applique pour le moment qu'à la version 1.0 du format ODF qui a déjà été supplantée
Non. ODF 1.1 n'est qu'une extension d'ODF 1.0. ODF 1.1 ne remplace pas ODF 1.0, il l'ettend.
[^] # Re: ODF pose certains problèmes
Posté par IsNotGood . Évalué à 4.
ODF ne pose pas de problème, il gère très très bien les évolutions.
Tous les standards évoluent. Fort heureusement.
Ce qui compte, c'est comment l'évolution est prise en compte, es-ce que la base du format est solide, etc.
Pour ODF, ça roule.
[^] # Re: ODF pose certains problèmes
Posté par croux . Évalué à 2.
Notons bien que ODF 1.1 et ODF 1.2 ont la compatibilité ascendante avec ODF 1.0.
Cela ne veut pas pour autant dire qu'un fichier ODF 1.2 sera correctement interprété par OpenOffice.org version 2.0.0 par exemple, même si ça n'est pas un problème en soit je l'avoue.
Par contre apprendre que seul ODF 1.0 est une norme ISO d'un côté et de se rendre compte qu'OpenOffice.org n'utilise pas cette norme est tout de même plus problématique. Quelle est l'utilité d'avoir des normes si les logiciels les plus répandus ne les mettent pas en œuvre complètement ?
Mais peut-être que j'attache trop d'importance à cet organisme qu'est l'ISO...
[^] # Re: ODF pose certains problèmes
Posté par Julien (site web personnel) . Évalué à 4.
Dans d'autres secteurs les normes évoluent aussi rapidement (agro-alimentaire par exemple.)
[^] # Re: ODF pose certains problèmes
Posté par IsNotGood . Évalué à 5.
Ce que tu ne comprends pas, est que ODF 1.1 (ou 1.2) utilise ODF 1.0 !
OOo 2.0 ouvrira du ODF 1.2. Il n'interprétera pas ce qu'il ne comprend pas (accessibilité, nouvelle formule, signature, etc). C'est comme le web (et les navigateurs).
Oui, tout n'est pas parfait. Mais c'est un mal nécessaire.
Il n'en sera peut-être pas de même pour ODF 2.0 (qui n'est toujours pas planifié).
> Mais peut-être que j'attache trop d'importance à cet organisme qu'est l'ISO...
Je ne crois pas. La standardisation est très importante (ISO ou pas).
Par contre, la certification ISO n'est pas un élément suffisant. MS-OOXML est certifié (ou presque), ce n'est pas suffisant. La pérennité du format est mise en cause, sa solidité, son évolutivité, la capacité à se l'approprier, etc aussi.
[^] # Re: ODF pose certains problèmes
Posté par croux . Évalué à 4.
"utilise" certes oui puisque ODF 1.x vient compléter cette norme, mais quelle est l'intérêt de se référer à une norme quand on ne s'y tient pas strictement et que pour des raisons légitimes, je le reconnais, il est nécessaire de l'étendre afin de mettre en œuvre de nouvelles fonctionnalités (dans OpenOffice.org par exemple).
Ce qui me gène, c'est que de nombreux outils se prétendent ainsi de la norme ODF mais qu'en réalité ils l'agrémentent à leur sauce, pour aboutir à des documents qui au final ne sont pas transposables à 100% quand on change d'outil. Ce devrait pourtant être l'objectif premier de l'implémentation d'une norme, assurer une compatibilité parfaite et totale.
Certes ODF a peut être été rédigé trop rapidement, et même si on peut espérer une stabilisation d'ici quelques temps, il est quand même regrettable que ce processus ne soit pas plus rapide.
Quelques reproches faits par les développeurs de Gnumeric à l'encontre de l'ODF (en milieu de page): http://www.gnome.org/projects/gnumeric/announcements/1.8/gnu(...)
[^] # Re: ODF pose certains problèmes
Posté par IsNotGood . Évalué à 3.
Si t'as une solution non simpliste à ce problème (mauvais exemple : faut faire de suite un format parfait pour les 30 ans à venir), donne la.
> Certes ODF a peut être été rédigé trop rapidement
Non. Il suffit de regarde MS-OOXML pour s'en convaincre. Rapporté au nombre de page, ODF a été ratifié ISO 20 fois moins vite !
> Quelques reproches faits par les développeurs de Gnumeric à l'encontre de l'ODF
Il n'y a jamais eu, Il n'y a pas, il n'y aura jamais de format parfait. Évidemment les critiques doivent être prise en compte afin de faire les choses au mieux (et non parfaitement car c'est impossible).
[^] # Re: ODF pose certains problèmes
Posté par croux . Évalué à 3.
Il serait peut être temps qu'au niveau international, les Etats s'investissent davantage dans ce problème afin de construire une société de l'information qui soit à même de pérenniser ce qu'elle produit et ce qui fera son histoire.
> Certes ODF a peut être été rédigé trop rapidement
Non. Il suffit de regarde MS-OOXML pour s'en convaincre. Rapporté au nombre de page, ODF a été ratifié ISO 20 fois moins vite !
Comparer ODF à OOXML ne constitue sans doute pas un bon argument :-)
Mais si on se réfère aux besoins que vient combler ODF 1.2, n'étaient-ils déjà pas à envisager lors de la conception de ODF 1.0 ? Par exemple la signature de document. Mais d'autres limitations ont été soulevées: http://fr.wikipedia.org/wiki/OpenDocument#Limitations
Il n'y a jamais eu, Il n'y a pas, il n'y aura jamais de format parfait.
Non bien sûr, mais certains formats imparfaits perdurent plus que d'autres: ASCII. C'est ce que j'attends d'un format de fichier: qu'il me facilite la vie. Mais on peut reporter les reproches sur les logiciels qui utilisent souvent la dernière version d'un format de fichier lors de la phase d'enregistrement sans proposer de le stocker dans une version plus ancienne toute aussi compatible...
[^] # Re: ODF pose certains problèmes
Posté par abramov_MS . Évalué à 3.
# acid test pour odf?
Posté par cram51 . Évalué à 10.
Parce que odf est un standard iso soit. Mais si tout le monde s'amuse a l'implémenter "à sa sauce" ca risque de devenir le bordel le plus complet.... et se retrouver avec un odf MSOffice illisible sur OOo et inversement. Après on peut toujours dire c'est la faute a machin, mais l'utilisateur s'en fout tout ce qu'il voit c'est que son fichier texte/tableur est illisible par son voisin/amis/client/fournisseur.
Il serrait bon, je trouve, d'avoir un document pour chaque extension (une pour le fichier texte, une pour le tableur, etc.) a ouvrir pour tester la compatibilité du format qui est normalisé iso avec celui implémenté dans le soft en question.
De plus on se retrouve avec un argument de vente : c'est plus "je supporte tel ou tel format". C'est "j'ai un score de xxxxx points au test odf". Ca permettrai en plus a l'utilisateur de voir quand quel mesure il risque, ou non, d'avoir des problèmes de compatibilité.
[^] # Re: acid test pour odf?
Posté par cdeblesson . Évalué à 4.
Je crains qu'il nous refasse le coup du HTML, si c'est pour que l'ODF Ms Office ne passe pas parfaitement sous OOo, on va encore se faire avoir.
Embrace, extend and extinguish, le retour...
[^] # Re: acid test pour odf?
Posté par cram51 . Évalué à 4.
Bein justement non M$ Office va supporter odf. Je suppose qu'il vont le supporter parce que une grande quantité d'administration le réclame et qu'il ne vont pas le faire parce qu'une envie soudaine d'interopérabilité les démanges. Il vont implanter odf dans leur suite ca va leur permettre de dire "gardez nous on supporte un format standard". Mais s'il se pointe avec une suite qui a 2 sur 10 a odf, on va leur répondre "non mais vous vous fouttez ne notre gueule?"
Et grace a ca je pense qu'on gagne sur les deux tableaux :
1/ M$ Office obtient un truc genre 2/10 :
On leur dis non ca c'est pas une implémentation correcte et on passe a OOo
2/ M$ Office obtient un truc genre 9/10 :
Certaine administration/société/particulier vont garder M$ Office parce qu'il est standard mais au moins s'il m'envoie un fichier texte je le lis parfaitement sur mon OOo qui lui a eu une note de 8 ou 9 sur 10 aussi. Et réciproquement si moi j'envoie un fichier a quiconque.
Dommage que je n'ai aucune compétence dans le domaine sinon je m'y serrai bien essayé.
[^] # Re: acid test pour odf?
Posté par abramov_MS . Évalué à 2.
[^] # Re: acid test pour odf?
Posté par stephwww . Évalué à 9.
Il supporteront 100% ODF, mais les utilisateurs utiliseront tellement d'extensions MSWord involontairement que d'autres traitements de texte ne pourront pas les relire. MS pourra tout lire mais pas les autres.
Comme la suite MS est majoritaire, les utilisateurs seront convaincus que les autres sont buggués.
Mais j'ai peut être simplement un mauvais fond...
[^] # Re: acid test pour odf?
Posté par Mildred (site web personnel) . Évalué à 7.
[^] # Re: acid test pour odf?
Posté par Jean M. . Évalué à 1.
"une suite de tests que tous les lecteurs ODF...", Oui, c'est une solution, mais de repasser par l'organisme de normalisation pour chaque évolution est un frein à l'innovation.
Il faudrait un comité restreint qui reçoit les propositions d'évolution nombre pair de participants, le proposant n'ayant pas le droit de vote qui doit accepter les amendements proposés pat une majorité de votants. (les temps de réponses devant être inférieur à 6 mois, alors qu'il faut souvent plusieurs années pour une normalisation)
[^] # Re: acid test pour odf?
Posté par cram51 . Évalué à 5.
Je vois pas ou on a parler de repasser par l'organisme de normalisation ni d'évolution.
On parle la de créer un outil qui vérifie que le logiciel est bien conforme à la norme. Je ne vois pas pourquoi on devrais retourner devant l'organisme. Ou alors si, peut etre pour valider l'outil de test, comme ca c'est l'organisme qui dis que pour qu'un logiciel soit déclaré conforme il doit passer le test truc.
Dans l'industrie on a des normes (je pense aux norme anti-feu par exemple) dans lesquelles il y a des tests a réaliser. Pour un produit, il ne suffit pas de dire "je suis conforme" pour avoir le droit de porter le logo qui va bien. Le produit doit passer les test décrits dans la norme dans un laboratoire indépendant pour etre qualifié.
Si OOo ou MS Office prétendent supporter odf qui vérifie?
Pour reprendre l'exemple de ma norme anti-feu:
On peut imaginer prendre une barre de matière de 200mm de diamètre apporter la flamme d'un briquet et dire : " ha, vous voyez ? ca brule pas ! je suis conforme" alors que le norme parle elle d'une éprouvette de diamètre 10mm et d'une flamme de chalumeau ( en fait je sais plus j'ai plus les chiffres en tete mais c'est dans l'idée. on est d'accord?)
Je vois pas ou se trouve le "frein" a l'évolution.
On réinvente rien, on vérifie que le logiciel xxx respecte le document qui est déja validé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.