Source files of fsfe.org, pdfreaders.org, freeyourandroid.org, ilovefs.org, drm.info, and test.fsfe.org. Contribute: https://fsfe.org/contribute/web/
Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.

eifv2-01.fr.xhtml 22KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400
  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <html>
  3. <head>
  4. <meta name="author-name-1" content="Hugo Roy" />
  5. <meta name="author-link-1" content="/about/roy/roy.html" />
  6. <meta name="publication-date" content="2009" />
  7. <title>FSFE - EIFv2 : Suivre et mesurer la perte d'interopérabilité</title>
  8. <style type="text/css">
  9. .colonne {
  10. margin-top:20px;
  11. font-size:0.9em;
  12. max-width:30%;
  13. min-width:25%;
  14. border:0;
  15. float:left;
  16. padding:0px 10px;
  17. }
  18. .nettoyeur { clear: both; height: 0; margin: 0; padding: 0; border: 0; line-height: 1px; font-size: 1px; }
  19. .frame {
  20. min-width:800px;
  21. overflow-x:scroll;
  22. }
  23. </style>
  24. </head>
  25. <body>
  26. <p align="right">[ <a href="eifv2.en.pdf">version PDF (en anglais) (76k)</a> ]</p>
  27. <h1 align="center">EIFv2&#160;: suivre et mesurer la perte d'interopérabilité</h1>
  28. <p class="indent"><em>Note de traduction&#160;: les liens hypertextes conduisent généralement à des documents rédigés en anglais, comme c'est souvent le cas des documents de travail internationaux. Les traductions faites des extraits de ces textes ne proviennent pas du service de traduction de l'Union Europenne. De plus, nous faisons ici référence à la notion de <strong>norme</strong> lorsque nous parlons d'"Open Standards" en anglais.</em></p>
  29. <p class="indent"><em>Ce document présente une analyse comparative de l'évolution du Cadre européen d'interopérabilité (EIF&#160;: European Interoperability Framework) basée sur les <a href="http://ec.europa.eu/idabc/en/document/7732">commentaires</a> formulés vis-à-vis de la <a href="http://ec.europa.eu/idabc/en/document/7733">deuxième version de l'EIF</a> (EIF v2). Il met en lumière les changements apportés entre la première mouture, sur laquelle une consultation publique avait été organisée durant l'été 2008, et <a
  30. href="http://blog.webwereld.nl/wp-content/uploads/2009/11/European-Interoperability-Framework-for-European-Public-Services-draft.pdf">la version actuelle</a> du document de travail, qui a fui dans la presse.</em></p>
  31. <p>Table des matières</p>
  32. <ul>
  33. <li><a href="#about">Qu'est-ce que le Cadre européen d'interopérabilité&#160;?</a></li>
  34. <li><a href="#one">1.Les normes sont le cœur de l'intéropérabilité</a></li>
  35. <li><a href="#two">2. S'affranchir de l'utilisation des standards propriétaires</a></li>
  36. <li><a href="#three">3. Le continuum de l'Ouverture</a></li>
  37. </ul>
  38. <h2 id="about">Qu'est-ce que le Cadre européen d'interopérabilité&#160;? (EIF en anglais)</h2>
  39. <blockquote>
  40. <p>L'EIF est un ensemble de lignes directrices pour l'interopérabilité et d'initiatives menées sous les auspices du programme IDABC (<em>Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens</em>, livraison aux administrations publiques, aux entreprises et aux citoyens de services d'«&#160;e-gouvernement&#160;» européens interopérables). L'EIF complète les différents cadres nationaux d'interopérabilité au niveau paneuropéen.</p>
  41. </blockquote>
  42. <p><em><a href="http://ec.europa.eu/idabc/servlets/Doc?id=31597">Extrait du document de travail initial, section 2/3.</a></em></p>
  43. <p> Le texte ci-dessous analyse certains changements que le texte a connus entre la consultation publique organisée durant l'été 2008 et le document de travail qui en résulta en novembre 2009. À l'occasion de cette consultation, de nombreux groupes et particuliers ont soumis <a href="http://ec.europa.eu/idabc/en/document/7732">leurs commentaires</a>. D'après notre analyse, nous pouvons conclure que la Commission Européenne, dans des domaines clés, n'a pris en compte que les <a href="http://ec.europa.eu/idabc/servlets/Doc?id=31903">commentaires proposés</a> par la <a href="http://www.bsa.org">«Business Software Alliance»</a>, un groupe de lobbying agissant pour le compte des entreprises de logiciels propriétaires. Quant aux commentaires proposés par les groupes travaillant en faveur du Logiciel Libre et des Standards Ouverts, ils ont été négligés. Parmi eux se trouvent ceux de l'<a href="http://openforumeurope.org/">Open Forum Europe</a>.
  44. </p>
  45. <h2 id="one">1. «&#160;Les normes sont le cœur de l'intéropérabilité&#160;»</h2>
  46. <div class="frame">
  47. <div class="colonne">
  48. <h3>A. Document de consultation de l'EIFv2</h3>
  49. <blockquote>
  50. <p>«&#160;<span style="background:#ffff00">Les normes sont le cœur de l'interopérabilité.</span> La stratégie de l'Union Européenne pour la croissance et l'emploi a identifié une normalisation forte et dynamique comme un instrument crucial pour favoriser l'innovation. La normalisation a une dimension d'intérêt public, en particulier en matière de sécurité, de santé, d'environnement et de performance.&#160;» (p.35)</p>
  51. <p>«&#160;Le rôle des administrations nationales dans ce processus est de
  52. <span style="background:#1e90ff">choisir la norme appropriée.</span>&#160;»</p>
  53. </blockquote>
  54. <p>Le document de consultation souligne le fait que les normes sont parmi les outils les plus efficaces pour réaliser l'interopérabilité sans nuire à la compétition ou à l'innovation. De plus, en se référant à la «&#160;norme appropriée&#160;», il indique que si plusieurs normes existent pour un même usage, un choix doit être fait. Ce choix, comme expliqué ensuite, doit favoriser les Standards Ouverts.</p>
  55. </div>
  56. <div class="colonne">
  57. <h3>B. Commentaires de la <em>Business Software Alliance</em></h3>
  58. <blockquote>
  59. <p>«&#160;<span style="background:#ffff00">S'il est vrai que les Standards Ouverts jouent un rôle critique pour permettre l'interopérabilité</span>, <span style="background:#ffa500">ce sont souvent nombre de mécanismes complémentaires qui, fonctionnant ensemble, concrétisent l'interopérabilité totale.</span>&#160;»</p>
  60. </blockquote>
  61. <p>Dans cette phrase, la BSA mentionne explicitement les Standards Ouverts, mais cette affirmation suggère de remettre en cause le rôle même que jouent les normes dans l'interopérabilité.</p>
  62. <blockquote>
  63. <p>«&#160;Finalement, l'EIFv2.0 devrait se retenir de recommander que les appels d'offres promeuvent les Standards Ouverts. À la place, l'EIF devrait adopter les principes et les règles exprimés dans les directives 2004/18 et 98/34, et encourager les États membres à baser leur décision d'appel d'offres sur le mérite.&#160;»</p>
  64. </blockquote>
  65. <p>Alors que le document de consultation arguait que le rôle des administrations nationales était de choisir des Standards Ouverts et appropriés, la BSA s'oppose clairement à ces décisions, qui devraient exclusivement être basées «&#160;sur le mérite&#160;».</p>
  66. <blockquote>
  67. <p>&#160;«Quatrièmement, le <span style="background:#1e90ff">brouillon de l'EIFv2.0 suggère à tort</span> que la convergence vers un unique ensemble de normes profite davantage aux autorités publiques qu'une utilisation de normes multiples se concurrençant l'une l'autre.
  68. <span style="background:#1e90ff">En effet, le document conclut que l'utilisation de normes équivalentes et multiples pourrait mener à un manque d'interopérabilité. La convergence vers un ensemble unique de normes est, dans la plupart des cas, une approche très risquée</span> car il est impossible de prédire l'impact qu'une solution spécifique aura sur le marché.&#160;»</p>
  69. </blockquote>
  70. </div>
  71. <div class="colonne">
  72. <h3>C. Le document de l'EIFv2 non définitif (fuite)</h3>
  73. <blockquote>
  74. <p>&#160;«<span style="background:#ffff00">S'il existe une corrélation entre transparence et interopérabilité</span>, <span style="background:#ffa500">il est également vrai que l'interopérabilité peut être obtenue sans transparence, par exemple grâce à <strong>l'homogénéité</strong> des systèmes informatiques, ce qui implique que tous les partenaires utilisent et se mettent d'accord sur l'emploi de la même solution pour les services publics européens.</span>&#160;»</p>
  75. </blockquote>
  76. <p>En se référant au «&#160;mécanismes complémentaires&#160;» décrits par la BSA, le document qui a fui explique que l'interopérabilité peut aussi être obtenue sans normes, par exemple si tout le monde utilise la même solution propriétaire.</p>
  77. </div>
  78. <div class="nettoyeur"></div>
  79. </div>
  80. <p><strong>Conclusion&#160;:</strong> Le document de travail original défendait les normes comme élément fondamental de l'interopérabilité et requérait que le cadre définisse les lignes de conduite qui favoriseraient l'utilisation des normes et, ce faisant, permettrait l'interopérabilité des systèmes. En conséquence, il y aurait eu une forte préférence vis-à-vis des Standards Ouverts. Cependant, la version du document qui a fui, absorbant les recommandations du BSA, minimise l'importance des normes. En outre, elle suggère que tous les états «&#160;se mettent d'accord sur l'emploi de la même solution pour les services publics européens.&#160;»</p>
  81. <p>Cela entraverait la concurrence et renforcerait le statu quo en faveur du modèle économique des solutions propriétaires.</p>
  82. <h2 id="two">2. «&#160;Éradiquer l'utilisation de standards propriétaires&#160;»</h2>
  83. <div class="frame">
  84. <div class="colonne">
  85. <h3>A. Document de consultation de l'EIFv2</h3>
  86. <blockquote>
  87. <p>«&#160;Les administrations publiques et les institutions européennes comme la Commission européenne devraient <span style="background:#90ee90">promouvoir activement les efforts envers l'éradication des standards et des solutions propriétaires</span> au sein des administrations publiques, en participant aux efforts de normalisation, particulièrement par la formulation et la communication des besoins et des nécessités, en accord avec la nouvelle approche.&#160;»</p>
  88. <p>«&#160;rendre l'accès aux services publiques aussi abordable que possible.&#160;»</p>
  89. <p>«&#160;Les administrations doivent faire en sorte que <span
  90. style="background:#ffc0cb">les solutions et/ou les produits soient choisis par un processus dans lequel la concurrence entre les fournisseurs est juste. [...] sans les enfermer</span> et contraindre leurs choix ultérieurs.&#160;»</p>
  91. <p>«&#160;Cette section préconise une <span
  92. style="background:#90ee90">migration systématique vers l'utilisation des normes ouvertes</span> ou des spécifications techniques [...] qui garantissent l'interopérabilité, facilitent la réutilisation ultérieure à long terme tout en minimisant les contraintes. Après avoir précisé la définition des normes et standards ouverts ou des spécifications techniques, cette section aborde la sélection des normes ou spécifications techniques et présente un ensemble de recommandations.&#160;» (p. 51)</p>
  93. <p>«&#160;<span
  94. style="background:#ffc0cb">L'accès aux normes ou spécifications techniques doit être facile et à un coût raisonnable, sans barrières relatives à leur implémentations</span> de telle sorte qu'une grande variété de produits puissent être disponibles sur le marché&#160;;&#160;»</p>
  95. </blockquote>
  96. <p>Ces extraits mettent en lumière l'intention originale du cadre d'interopérabilité. En plus de promouvoir les normes, préférer les normes ouvertes aux standards propriétaires est perçu comme le meilleur moyen de garantir que l'interopérabilité soit un succès et contribue à la concurrence. <a href="#not1" id="anc1">[1]</a></p>
  97. <blockquote>
  98. <p>«&#160;considérant une norme ouverte selon la définition de l'EIF version 1&#160;:</p>
  99. <ol>
  100. <li>La norme ouverte sera adoptée et sera maintenue par une organisation sans but lucratif, et son développement se fera sur la base d'une <span
  101. style="background:#ffc0cb">procédure de décision ouverte à toutes les parties intéressées (par consensus ou par voie de majorité, etc.)</span>.</li>
  102. <li>La norme ouverte sera publiée et le document de spécifications sera disponible soit <span
  103. style="background:#ffc0cb">gratuitement ou contre une redevance nominale. Il doit être permis de le copier, le distribuer et l'utiliser gratuitement ou en échange d'une redevance nominale</span>.</li>
  104. <li>La propriété intellectuelle – par exemple <span
  105. style="background:#ffc0cb">la possible présence de brevets – de la norme ouverte sera irrévocablement rendue disponible et libre de droits</span>.</li>
  106. <li>Il n'y a <span
  107. style="background:#ffc0cb">aucune contraite sur la réutilisation</span> de la norme.&#160;»</li>
  108. </ol>
  109. </blockquote>
  110. <p>Cette définition d'une norme ouverte a déjà été approuvée avec la première version du Cadre européen d'interopérabilité (EIF).</p>
  111. </div>
  112. <div class="colonne">
  113. <h3>B. Commentaires de la BSA</h3>
  114. <blockquote>
  115. <p>"Deuxièmement, l'EIF v2.0 ainsi que le CAMSS <span
  116. style="background:#ffc0cb">ne devraient pas définir les normes ouvertes
  117. </span>, ou devraient admettre une définition plus consistante avec
  118. l'utilisation commune du terme [...] «&#160;ouvert&#160;»&#160;:</p>
  119. <p>(1) la spécification est disponible publiquement <span
  120. style="background:#ffc0cb">sans coût ou en échange d'une redevance
  121. raisonnable</span> pour n'importe quelle [FIXME: interested party]</p>
  122. </blockquote>
  123. <p>Ce point équivaut au deuxième critère de la définition de l'EIFv1. Cependant,
  124. il y a des différences substantielles. Alors que l'EIFv1 arguait en faveur de
  125. conditions «&#160;libre de droit ou moyennant une redevance nominale&#160;», la
  126. BSA défend des conditions «&#160;en échange d'une redevance raisonnable&#160;»,
  127. ce qui a pour conséquence d'exclure les Logiciels Libres d'utiliser ces normes.
  128. («&#160;Raisonnable&#160;» fait référence aux termes RAND, <em>Reasonable and
  129. Non-Discriminatory</em>, qui en fait ne sont pas raisonnables pour le Logiciel
  130. Libre. En effet, avec de tels termes, la personne qui implémente la norme doit
  131. habituellement payer l'ayant-droit une redevance <strong>par copie</strong> de
  132. logiciel distribué. Cela est incompatible avec la plupart des licences de
  133. Logiciel Libre, qui interdisent de telles restrictions à la distribution. <a
  134. href="#not2" id="anc2">[2]</a></p>
  135. <blockquote>
  136. <p>(2) n'importe quel droit sur un brevet nécessaire à l'implémentation
  137. du standard est mis à disposition de tous les participants à des
  138. conditions <span style="background:#ffc0cb">raisonnable et
  139. non-discriminante (RAND), avec ou sans le payement d'une charge
  140. raisonnable ou d'une redevance</span>; et</p>
  141. </blockquote>
  142. <p>La définition de l'EIFv1 requiert que les ayant-droit d'un brevet mettent à
  143. disposition irrévocablement leurs droits sans charges. Ceci allait clairement a
  144. l'opposé de cette affirmation de la BSA.</p>
  145. <blockquote>
  146. <p>(3) la spécification doit être suffisamment détaillée pour permettre
  147. une compréhension totale de son spectre d'application et de son but et
  148. permettre des implémentations concurrentes par des fournisseurs
  149. multiples.</p>
  150. </blockquote>
  151. </div>
  152. <div class="colonne">
  153. <h3>C. Le document de l'EIFv2 divulgué sans publication</h3>
  154. <blockquote>
  155. <p>«&#160;<span style="background:#90ee90">Il appartient aux créateurs d'une spécification particulière de décider du degré d'ouverte qu'ils souhaitent pour leur spécification.</span>&#160;»</p>
  156. <p>«&#160;Si le principe d'ouverture s'applique en entier&#160;:</p>
  157. <ul>
  158. <li><span style="background:#ffc0cb">Tous les participants
  159. peuvent contribuer à l'élaboration d'une spécification et une
  160. revue publique est organisée</span>&#160;;</li>
  161. <li>Le document de spécification est disponible librement à tous
  162. pour être étudié et partagé avec d'autres&#160;;</li>
  163. <li>La spécification peut être implémentée selon les approches
  164. de développement du logiciel différentes [19].</li>
  165. </ul>
  166. <p>[19] Par exemple utilisant des technologies Open Source ou
  167. propriétaire. Il s'agit aussi de permettre aux fournisseurs de pourvoir
  168. selon divers modèles économiques, des technologies et services basé sur
  169. de telle sorte de spécifications.&#160;»</p>
  170. </blockquote>
  171. <p>La définition des Normes Ouvertes de la première version de l'EIF qui était
  172. présente dans le document de consultation indiquait aussi que «&#160;les
  173. administrations publiques en Europe [...] doivent activement soutenir les
  174. efforts d'élimination des standards propriétaires&#160;». En réaction aux
  175. commentaires de la BSA, le document [FIXME: fuité] renverse totalement cette
  176. position, notamment avec une description extrêmement vague du «&#160;principe
  177. d'ouverture&#160;» qui peut être appliqué en entier ou non.</p>
  178. </div>
  179. <div class="nettoyeur"></div>
  180. </div>
  181. <h2 id="three">3. The Openness Continuum</h2>
  182. <div class="frame">
  183. <div class="colonne">
  184. <h3>A. Consultation Draft</h3>
  185. <blockquote>
  186. <p>"The difficulty in limiting the selection of standards or
  187. technical specifications only to <span style="background:#d09cf0">the "most
  188. open</span>"<br />
  189. The definition of open standards presented above should be
  190. considered as part of <span style="background:#d09cf0">a broader approach</span>, as openness touches upon
  191. many aspects of the definition, adoption and use of standards or
  192. technical specifications. First of all, openness might address
  193. additional process-related characteristics such as being subject to
  194. a non-discriminatory conformance process.</p>
  195. <p>On the other hand, the characteristics of an open standard or
  196. technical specification, as presented in the previous section,
  197. might be fulfilled by some technical specifications only in part.
  198. It is useful to consider some specific
  199. "shadings" of openness such as
  200. technical specifications that are:</p>
  201. <ul>
  202. <li>"freely available" (meaning that their contents are not
  203. secret),</li>
  204. <li>"available for free" (without charge), or</li>
  205. <li>"free of use restrictions" (i.e., of legal restrictions on
  206. their use).</li>
  207. </ul>
  208. <p>The interest in such additional categorisations is
  209. straightforward: <span style="background:#d09cf0">Open standards or technical specifications are
  210. preferred (for all the reasons given above), but if there is no
  211. suitable, feasible open standard or technical specification, one
  212. can investigate some of the "less
  213. open" alternatives</span>. Whereas the goal is to ensure real
  214. and fair competition through the selection of open standards or
  215. technical specification, it is however <span style="background:#d09cf0">difficult at this time to
  216. limit the selection of standards or technical specifications only
  217. to the "most open"</span> as prevailing
  218. conditions must be taken into account, including the current market
  219. conditions.</p>
  220. <p>However, <span style="background:#d09cf0">such choices must be revisited on a regular basis in
  221. order to ensure that a systematic migration towards the use of open
  222. standards</span> or technical specifications takes place, as quickly as is
  223. practical."</p>
  224. </blockquote>
  225. </div>
  226. <div class="colonne">
  227. <h3>B. BSA</h3>
  228. <blockquote>
  229. <p>"In defining openness in a manner that is inconsistent with
  230. common industry practice, the EIF v2.0 excludes many <span style="background:#d09cf0">leading
  231. standards</span> widely recognised as open from its scope
  232. including such well-known standards as DVB,
  233. GSM and MP3. (We have attached a list of excluded standards to our
  234. comments at Appendix A). If Member States implement this
  235. definition, they will effectively be restricted from utilizing a
  236. wide range of <span style="background:#d09cf0">leading technologies that implement these popular
  237. standards</span>. This would represent a dramatic shift at national level,
  238. given that virtually every single Member State now has policies
  239. that are far more flexible. "</p>
  240. </blockquote>
  241. <p>Against Open Standards and specifications, the BSA promotes "leading or popular standards." It seems difficult to have any relevant guideline or definition about what makes a "leading standard." Moreover, there are no connections in terms of interoperability and competition.</p>
  242. </div>
  243. <div class="colonne">
  244. <h3>C. Leaked Draft</h3>
  245. <blockquote>
  246. <p>"Specifications, software and software development methods that
  247. promote collaboration and the results of which can freely be
  248. accessed, reused and shared are considered open and lie at one end
  249. of the spectrum while <span style="background:#d09cf0">non-documented, proprietary specifications,
  250. proprietary software and the reluctance or resistance to reuse
  251. solutions, i.e. the "not invented here" syndrome, lie at the other
  252. end</span>.</p>
  253. <p>The spectrum of approaches that lies between these two extremes
  254. can be called the openness continuum."</p>
  255. </blockquote>
  256. <p> The consultation document already included the idea of an "openness continuum". This continuum, however, only covered a range from "open" to "most open". In the leaked draft, the continuum suddenly includes proprietary standards and specifications.
  257. </p>
  258. <blockquote>
  259. <p>"Within the context of the EIF, openness is the willingness of
  260. persons, organisations or other members of a community of interest
  261. to share knowledge and to stimulate debate within that community of
  262. interest, having as ultimate goal the advancement of knowledge and
  263. the use thereof to solve relevant problems. In that sense, openness
  264. leads to considerable gains in efficiency."</p>
  265. </blockquote>
  266. </div>
  267. <div class="nettoyeur"></div>
  268. </div>
  269. <p><strong>Conclusion:</strong> Based on the above analysis, we can only conclude that the European Commission is giving strong preference to the viewpoint of a single lobby group. Regarding interoperability and open standards, key places of the consultation document were modified to comply with the demands of the BSA. Input given by other groups was not considered on this issue. Beyond ignoring this input, the Commission has apparently decided to ignore the success of the first version of the EIF, and to abandon its efforts towards actually achieving interoperability in eGovernment services.
  270. </p>
  271. <hr />
  272. <p><a id="not1" href="#anc1">[1]</a>. This is a stark contrast with the European Commission's policy on this subject. See <a href="http://europa.eu/rapid/pressReleasesAction.do?reference=SPEECH/08/317&amp;format=HTML&amp;aged=0&amp;language=EN&amp;guiLanguage=en">this speech by European Commissioner for Competition, Ms. Neelie Kroes</a>:</p>
  273. <blockquote>“I know a smart business decision when I see one - choosing open standards is a very smart business decision indeed.”</blockquote>
  274. <p><a id="not2" href="#anc2">[2]</a>. Indeed, instead of the vague notion of "reasonable fee," a nominal fee permits Free Software projects to implement standards. See as a similar case the <a href="http://www.samba.org/samba/PFIF/">agreement between Samba and Microsoft</a>.
  275. </p>
  276. </body>
  277. <timestamp>$Date: 2009-12-10 12:50:10 +0000 (Thu, 10 Dec 2009) $ $Author: hugoroy $</timestamp>
  278. <translator>Nicolas JEAN, Hugo Roy, Jil Larner (Mont Blanc, France)</translator>
  279. </html>
  280. <!--
  281. Local Variables: ***
  282. mode: xml ***
  283. End: ***
  284. -->