Standards ouverts et logiciels libres

1,952 views
1,871 views

Published on

Document de clarification des notions liées aux logiciels libres et aux standards ouverts.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,952
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
45
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Standards ouverts et logiciels libres

  1. 1. Standards ouverts et logiciel libre Clarification des notions Observatoire Technologique Centre des technologies de l’information République et Canton de Genève P. Genoud, G. Pauletto 30 septembre 2005Observatoire TechnologiqueCentre des Technologies de l’InformationRépublique et Canton de GenèveCP 2285, 1211 Genève 2, Suissehttp://www.geneve.ch/ot/ot@etat.ge.ch 1
  2. 2. Standards ouverts et logiciel libre Clarification des notionsCopyright c 2005 CTI, Observatoire Technologique.This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To viewa copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/2.5/ or send a let-ter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.You are free: • to copy, distribute, display, and perform the work • to make derivative worksUnder the following conditions: Attribution. ou must attribute the work in the manner specified by the author or licensor. Noncommercial. You may not use this work for commercial purposes. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the copyright holder.Your fair use and other rights are in no way affected by the above.This is a human-readable summary of the Legal Code (the full license http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode.Observatoire Technologique, CTI 2
  3. 3. Standards ouverts et logiciel libre Clarification des notionsTable des matières1 Introduction 52 Interopérabilité 53 Logiciel libre 7 3.1 Le modèle open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Les communautés open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Catégories de logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 Domaine public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2 Propriétaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.3 Shareware / Freeware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.4 Commercial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.5 Logiciel libre (Free Software) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.6 Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.7 Licences doubles ou multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Perspectives open source dans le secteur public . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Les standards ouverts 12 4.1 Définitions et critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Degré d’ouverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Organismes de normalisation 196 Standard ouvert vs logiciel libre 217 Politiques gouvernementales 22 7.1 Belgique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2 Brésil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3 Danemark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4 États-Unis, Massachusetts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.5 France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6 Norvège . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.7 Pays-Bas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.8 Royaume-Uni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.9 Suisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.10 Union Européenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Domaine de l’éducation et de la recherche 30Observatoire Technologique, CTI 3
  4. 4. Standards ouverts et logiciel libre Clarification des notions9 Conclusions 33Révisions Version Date / auteurs Objet de la révision 0.1 2005-02-18 / pge Version initiale 0.2 2005-06-17 / gip Ajout section logiciel libre 0.3 2005-07-04 / pge, gip Ajout autres sections 0.4 2005-07-15 / pge, gip Avant relecture finale 0.9 2005-07-21 / pge, gip Pour soumission à la direction du projet 0.91 2005-09-05 / pge, gip Modifications après retour de la direction du projet 1.0 2005-09-30 / pge, gip Après validation par la direction du projetObservatoire Technologique, CTI 4
  5. 5. Standards ouverts et logiciel libre Clarification des notions1 IntroductionAu cours de l’année 2004, plusieurs signaux ont été émis affirmant la volonté de l’administration genevoisede se tourner d’ici 2009 d’une part vers le logiciel libre, mais aussi et surtout vers les standards ouverts. Desdéclarations dans ce sens ont d’abord été émises en interne1 , puis relayées dans les médias locaux (jour-naux2 3 , télévision4 ) et également reprises par le site Web de l’IDABC5 (site de la Commission Européennedédié à l’échange de données entre les administrations).Ces annonces suscitent, et vont susciter des réactions, que ce soit au niveau des collaborateurs de l’ad-ministration genevoise, des représentants des autres cantons et de la Confédération ou des entreprisesinformatiques partenaires. Les informations fournies sont plus ou moins bien comprises et appréciées parles différents acteurs concernés. Elles suscitent de nombreuses questions auxquelles il faudra répondreclairement et rapidement si l’on entend atteindre efficacement les objectifs visés.Un travail de clarification est donc nécessaire et est à l’origine du projet « Standards Ouverts et LogicielLibre » (SOLL) confié conjointement à l’Observatoire Technologique (OT) par la Direction Générale du Centredes technologies de l’information de l’État de Genève (CTI), par la Direction Informatique de l’Université deGenève et par le Partenariat de l’OT.Les notions de logiciel libre et de standard ouvert ne sont pas aussi bien comprises qu’on pourrait l’imaginer,même au sein de la communauté informatique. Cela tient d’une part au fait que ces concepts sont relative-ment nouveaux. D’autre part, les définitions que l’on en donne varient selon les auteurs ou les communautésconcernées, surtout en ce qui concerne l’aspect plus ou moins restrictif des critères que doivent respecterles logiciels et les standards pour être qualifiés de libres et d’ouverts respectivement.Il est donc important de définir précisément ces notions afin qu’il ne subsiste pas d’ambiguïté dans lesesprits, que ce soit en interne ou en externe à l’entreprise ou à l’organisation concernées. Ce documentreprend ainsi les définitions communément proposées dans la littérature. Il met en évidence les interpréta-tions et les implications relatives aux différentes définitions d’une même notion, ceci afin de permettre auxmandants du projet SOLL d’en proposer leur propre acception en toute connaissance de cause. La notiond’interopérabilité est développée en préambule, car elle constitue le concept de base autour duquel viennentnaturellement s’articuler les standards ouverts et le logiciel libre. Un chapitre est également consacré à laclarification des relations que l’on peut pressentir entre logiciel libre et standards ouverts.Certains gouvernements se sont déjà clairement positionnés par rapport au logiciel libre et aux standardsouverts. Nous proposons dans ce document une brève description de quelques politiques gouvernementalesqui illustrent les diverses manières d’aborder cette problématique et qui peuvent servir de référence dans cedomaine. Enfin, un recensement de quelques initiatives phares dans le milieu académique est égalementproposé.2 InteropérabilitéComme le souligne un récent document de travail de la Commission Européenne6 , l’administration électro-nique n’est pas une simple administration traditionnelle à laquelle on aurait ajouté l’Internet. Elle recouvrel’utilisation de nouvelles technologies en vue de transformer les administrations publiques et d’améliorerradicalement les contacts avec leurs clients (citoyens, entreprises ou autres administrations).Ces transformations passent notamment par un décloisonnement des divers services et départements del’administration, dans la mesure où cela respecte les lois en vigueur et la sphère privée des citoyens. Mais 1 Vers les Standards Ouverts, Echo No 1, CTI, Automne 2004. 2 Article du Matin, 17 novembre 2004. 3 Article de la Tribune de Genève, 24 novembre 2004. 4 Reportage TSR Journal des Régions, 15 décembre 2004. 5 Geneva moves towards open standards, http://europa.eu.int/idabc/en/document/3528 etGeneva to switch to open source by 2009, http://europa.eu.int/idabc/en/document/3601, Sitede l’IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businessesand Citizens), Novembre 2004. 6 Interconnecter l’Europe : l’importance de l’interopérabilité des services de l’administration électronique,document de travail des services de la Commission Européenne, 2003.Observatoire Technologique, CTI 5
  6. 6. Standards ouverts et logiciel libre Clarification des notionsune transversalité croissante ne va pas sans poser des problèmes, à la fois techniques et organisationnels,lorsqu’il s’agit de faire communiquer entre eux les différents systèmes d’information concernés.Les technologies peuvent faciliter la communication et le partage de l’information pour autant qu’elles soientinteropérables. L’interopérabilité se situe alors au cœur du rapprochement des services des administrationspubliques. Elle désigne ici la capacité qu’ont les technologies de l’information et de la communication ainsique les processus qu’elles soutiennent à échanger des données et à permettre le partage de l’information etde la connaissance. Elle garantit ainsi la pérennité des données et leur accessibilité dans le futur. Elle consti-tue donc une exigence fondamentale pour développer une administration en ligne efficace, performante etpérenne. Plus généralement, elle doit être considérée comme un élément clé des architectures actuelles,qu’elles soient techniques, applicatives ou métier.La Commission Européenne a parfaitement intégré ces enjeux et a lancé le programme IDABC7 (Interope-rable Delivery of European eGovernment Services to Public Administrations, Businesses and Citizens) afinnotamment d’encourager et de faciliter l’échange d’informations et de connaissances entre les secteurs pu-blics des différents pays de l’Union Européenne.Le document de travail de la Commission Européenne insiste sur la nécessité de considérer l’interopérabilitécomme un problème global. En effet l’interopérabilité passe d’abord par la réorganisation des processusadministratifs et par la nécessité d’inclure la notion de partage de l’information. On considère ainsi troisaspects fondamentaux liés à l’interopérabilité des systèmes d’information : 1. L’interopérabilité organisationnelle qui concerne principalement la modélisation des processus mé- tiers dans le but de prendre en compte la collaboration entre services qui n’ont pas les mêmes struc- tures organisationnelles et qui ne gèrent pas des processus similaires. Pratiquement, il s’agit de s’as- surer que les processus pourront être facilement intégrés les uns aux autres et exploités par d’autres utilisateurs. L’interopérabilité organisationnelle a notamment pour objectif de prendre en compte les besoins des utilisateurs en proposant des services accessibles, aisément identifiables et orientés vers eux. Cela passe par la nécessité de rendre la complexité organisationnelle des services transparente pour les utilisateurs. 2. L’interopérabilité sémantique qui garantit que le sens exact des informations échangées peut être compris par toute application qui n’a pas été conçue initialement dans ce but. L’interopérabilité séman- tique facilite l’agrégation et la réutilisation d’informations hétérogènes (de par leur nature ou leur mode de création) et participe ainsi de manière essentielle à la valorisation du patrimoine informationnel d’une organisation. Cela va donc beaucoup plus loin que la simple connexion de différentes sources d’information, l’objectif plus fondamental étant de faciliter le passage de l’information à la connais- sance. La prise en compte de l’interopérabilité sémantique passe concrètement par une nécessaire réflexion sur la réutilisabilité et la standardisation des données, par l’utilisation de métadonnées qui renseignent sur le contexte lié à la création des données et par la mise en œuvre de technologies XML conçues pour répondre à cette problématique. 3. L’interopérabilité technique concerne les aspects liés à la connexion des systèmes et des services informatiques. Cela touche des domaines aussi variés que la définition d’interfaces et de standards ouverts, l’intégration des données, la couche middleware, la présentation et l’échange d’informations, l’accessibilité ou les services de sécurité. Le référentiel NPT8 (Nouvelles Plateformes Technologiques) réalisé par l’Observatoire Technologique du canton de Genève propose quelques pistes pour prendre en compte et mesurer l’interopérabilité technique d’une solution informatique.Prendre en compte les aspects techniques de l’interopérabilité est donc nécessaire mais pas suffisantlorsque l’on désire atteindre une interopérabilité effective. Les notions d’interopérabilité sémantique et or-ganisationnelle sont tout aussi importantes, si ce n’est plus. Lorsque l’on entend définir une politique dans ledomaine, il est essentiel de ne pas considérer l’interopérabilité comme une question uniquement technique.Une telle vision de l’interopérabilité la positionne comme un problème politique (stratégie et réglementation).Un certain nombre de pays européens l’ont bien compris et l’ont inscrit dans leur agenda. Cela se traduitnotamment par la mise en œuvre d’un cadre commun d’interopérabilité sur le modèle de ce qui a déjà été 7 Site Web du programme IDABC lancé par la Commission Européenne http://europa.eu.int/idabc/en/home. 8 Référentiel Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technolo-gique, Centre des technologies de l’information du canton de Genève, 2003, http://www.geneve.ch/ot/.Observatoire Technologique, CTI 6
  7. 7. Standards ouverts et logiciel libre Clarification des notionsréalisé par la France9 , l’Allemagne10 , le Royaume-Uni11 , la Belgique12 ou l’Union Européenne13 . Un cadre commun d’interopérabilité peut être défini comme un ensemble de politiques, de normes, de conseils et de directives décrivant comment des organisations s’accordent, ou de- vraient s’accorder, pour échanger informations et processus.C’est donc un instrument dynamique qui doit pouvoir s’adapter à l’évolution des technologies, des normeset des besoins métiers dans les domaines concernés. Chacun des cadres communs d’interopérabilité men-tionnés ci-dessus correspond à des situations et des besoins différents. Mais ils représentent, à divers titres,des modèles de référence parfaitement réutilisables. Tous reflètent la prise de conscience croissante du faitque l’interopérabilité des systèmes d’information des institutions gouvernementales constitue une conditionpréalable indispensable si l’on désire mettre en place un secteur public plus compétitif et orienté vers lesservices aux citoyens.L’approche retenue dans les exemples mentionnés ci-dessus part de principes de base (impératifs straté-giques) comme l’accessibilité, l’éthique, la sécurité ou la transversalité que l’on retrouve dans le référentiele-Société proposé par l’Observatoire Technologique du canton de Genève14 . Les administrations et les gou-vernements prennent en outre conscience de la valeur stratégique de l’information qu’ils créent et qu’ilsgèrent au quotidien, ce qui amène naturellement à revendiquer une plus grande maîtrise de leurs systèmesd’information. C’est donc logiquement que la notion d’indépendance vis-à-vis des fournisseurs constitue unprincipe de base également mis en avant.Nous verrons ci-dessous que les standards ouverts et le logiciel libre viennent répondre de façon très na-turelle à ces impératifs stratégiques. L’Union Européenne ainsi qu’un certain nombre de gouvernementsplacent d’ailleurs ces notions au cœur de leur stratégie.3 Logiciel libreLes technologies appartenant au domaine dit du logiciel libre ou « open source » sont présentes depuis uncertain nombre d’années, mais le concept n’a pris de l’ampleur dans le monde informatique que depuis peuavec notamment le succès du système d’exploitation Linux. Le logiciel libre présente des facettes multiples :c’est en partie un phénomène très médiatisé, mais aussi et surtout un mouvement social, une définition delicence et un modèle de développement. La section suivante présente une perspective très partielle de cesujet qui mériterait un éclairage bien plus conséquent. Mais la littérature consacrée au logiciel libre abondeet le lecteur trouvera sans difficulté une publication de référence. Pour n’en citer qu’une, nous mentionneronsle récent livre blanc Organisations et logiciels libres15 qui permet une première approche du secteur à la foispour un néophyte, ou un approfondissement pour un lecteur déjà averti.En 1984, la Free Software Foundation16 a introduit la notion de free software, traduit en français par logiciellibre. Malheureusement, le terme anglais « free » signifie aussi bien libre que gratuit ce qui a causé beaucoupde confusion dans les esprits. 9 CCI — Cadre commun d’interopérabilité des systèmes d’information publics, Agence pour Déve-loppement de l’Administration Électronique, France, Septembre 2003, http://www.adae.gouv.fr/rubrique.php3?id_rubrique=41. 10 SAGA — Standards and Architectures for e-Government Applications, KBSt unit, Ministère Fédéral del’Intérieur, Allemagne, Décembre 2003, http://www.kbst.bund.de/-,182/SAGA.htm. 11 E-GIF — e-Government Interoperability Framework, Office of the e-Envoy, Royaume-Uni, Avril 2004,http://www.govtalk.gov.uk/schemasstandards/egif.asp. 12 BELGIF — BELgian Governement Interoperability Framework, Belgique, http://www.belgif.be 13 EIF — European Interoperability Framework for Pan-European eGovernment Services, IDABC, Com-mission Européenne, 2004, http://europa.eu.int. 14 Référentiel e-Société, P. Genoud et G. Pauletto, Observatoire Technologique, Centre des technologiesde l’information du canton de Genève, 2002, http://www.geneve.ch/ot/. 15 Organisations et logiciels libres, Diane Revillard, Diemark SARL, France, Septembre 2005, http://www.diemark.net/. 16 FSF — Free Software Foundation, http://www.fsf.org/.Observatoire Technologique, CTI 7
  8. 8. Standards ouverts et logiciel libre Clarification des notionsIl serait faux de penser que parce qu’un logiciel est gratuit, il est libre. Il serait également erroné de croireque parce que son code source est disponible, un logiciel est libre ou encore gratuit.Le terme open source est également apparu plus récemment, en grande partie, pour éviter ce malentenduet dédramatiser les débats entre les tenants du logiciel propriétaire et du logiciel libre, en amenant une vueplus pragmatique et moins philosophique.Nous détaillons ici les définitions aussi bien de logiciel libre que de open source et leur différences de phi-losophie. Pour la suite de ce rapport les deux termes sont utilisés comme synonymes ce qui est aujourd’huilargement reconnu par les communautés d’usagers et de développeurs.Un logiciel est protégé par le droit d’auteur17 . L’auteur d’un programme peut choisir de protéger son œuvrepar une autre licence lui permettant de modifier les droits et devoirs donnés par défaut. La règle de discrimi-nation est la suivante : L’appartenance d’un logiciel à une catégorie (libre, propriétaire, etc.) est établie grâce à la licence sous laquelle le logiciel est distribué.Les catégories de licences les plus fréquemment rencontrées sont explicitées ci-après. Une présentationdétaillée de cette problématique est donnée ailleurs18 .3.1 Le modèle open sourceOn peut définir la notion de modèle open source comme l’ensemble des principes et des bonnes pratiquesrégissant le développement, le déploiement et le support de ce type de logiciel. Au cœur de ce modèleon retrouve le mouvement open source dont la préoccupation majeure est de protéger les privilèges desutilisateurs plutôt que celui des auteurs19 . dans ce domaine.3.2 Les communautés open sourceLe modèle open source s’appuie sur des communautés de développeurs qui travaillent en mode collaboratifà une échelle souvent planétaire. Les membres de ces communautés proviennent de tous les horizons :milieu académique, petites sociétés de service, passionnés du développement logiciel ou, plus récemment,poids lourds du monde informatique qui se sont positionnés dans ce domaine. Ces membres jouent souventdes rôles multiples au sein de leur communauté et se sentent très concernés par la réussite ou l’échec duprojet auquel ils participent.La communauté rassemblée autour d’un projet substitue au concept traditionnel de propriété la notion deservice. Puisqu’aucune entité ne possède le logiciel, personne ne peut le contrôler, même si un petit groupede développeurs fait office de leaders du projet. Si l’orientation donnée à un projet open source ne corres-pond pas aux aspirations d’une partie des membres de la communauté, le projet peut se scinder en unautre projet distinct (forking). Cette dynamique conduit à la création d’un écosystème de projets au seinduquel s’effectue une véritable sélection naturelle favorisant les projets de qualité qui répondent le mieuxaux besoins des utilisateurs. La taille de la communauté associée à un projet constitue en principe un bonindicateur de sa vitalité et de sa qualité. 17 Loi fédérale sur le droit d’auteur et les droits voisins, Titre 2, Article 2, Paragraphe 3, « Les programmesd’ordinateurs (logiciels) sont également considérés comme des œuvres. » http://www.admin.ch/ch/f/rs/231_1/a2.html. 18 Guide de choix et d’usage des licences de logiciels libres pour les administrations, et L’analyse dé-taillée des licences, ADAE, France, Décembre 2002, http://www.adae.gouv.fr/article.php3?id_article=172,Licences Open Source, Annexe du rapport du projet Nouvelles Plateformes Technologiques, P. Genoud etG. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève,Juin 2003, http://www.geneve.ch/ot/. 19 Open-Source Solutions Will Restructure the Software Industry, Mark Driver, Gartner Group, Février2005.Observatoire Technologique, CTI 8
  9. 9. Standards ouverts et logiciel libre Clarification des notions3.3 Catégories de logiciel3.3.1 Domaine publicLes logiciels dans le domaine public ne sont pas protégés par des droits d’auteur. Ils sont explicitementdéposés dans le domaine public par leur(s) auteur(s), car par défaut, tout programme est protégé par lecopyright attribué automatiquement à son auteur. Pour un logiciel dans cette catégorie toute modification estpossible, mais il peut basculer vers une autre licence à tout moment. De plus, rien ne garantit que le codesource soit disponible.3.3.2 PropriétaireLe logiciel propriétaire est le modèle auquel l’industrie est encore aujourd’hui le plus souvent confrontée :son utilisation, sa redistribution ou sa modification sont interdites, ou exigent une autorisation spécifique. Lesdroits de propriété sont détenus par la société qui le distribue ou par son auteur. Le code source peut êtremis à disposition ou non, mais sa protection reste garantie par le droit d’auteur et la propriété intellectuelleappartient au fournisseur du programme.3.3.3 Shareware / FreewareLa catégorie shareware / freeware est souvent confondue à tort avec l’open source. Un logiciel freewareest un logiciel gratuit qui permet l’utilisation et la redistribution de l’exécutable ; les codes sources ne sontgénéralement pas fournis et la modification n’est pas autorisée. Cette catégorie n’a en général pas de réelpoint commun avec l’open source, mise à part dans certains cas, la gratuité. Un logiciel shareware estun freeware limité dans le temps qui devient payant une fois une date limite ou un nombre d’utilisationsdépassés.3.3.4 CommercialIl faut également savoir qu’un logiciel commercial est un produit vendu par une entreprise dans le but de réa-liser un profit. Cela n’est pas incompatible avec la notion de logiciel libre : les sociétés commerciales commeRedHat, Novell et Mandriva en sont la preuve. Ces entreprises commercialisent des solutions open source ety ajoutent de la valeur en offrant des services tels que le packaging, l’intégration, le support ou la documen-tation. A contrario, il existe également des logiciels non commerciaux qui ne sont pas dans la catégorie dulogiciel libre. Il devient de plus en plus important d’utiliser le vocabulaire adéquat pour éviter les ambiguïtéscomme par exemple éviter d’utiliser l’adjectif « commercial » pour qualifier un logiciel « propriétaire ».3.3.5 Logiciel libre (Free Software)Selon la Free Software Foundation, un logiciel est considéré comme libre si sa licence garantit à l’utilisateurles quatre libertés suivantes qu’elle numérote de zéro à trois : 0. La liberté d’exécuter le programme, pour tous les usages. 1. La liberté d’étudier le fonctionnement du programme et de l’adapter aux besoins. Pour ceci l’accès au code source est une condition requise. 2. La liberté de redistribuer des copies, donc d’aider son voisin. 3. La liberté d’améliorer le programme et de publier des améliorations, pour en faire profiter toute la communauté. Pour ceci l’accès au code source est une condition requise.Observatoire Technologique, CTI 9
  10. 10. Standards ouverts et logiciel libre Clarification des notionsLa licence GNU General Public License (GPL) concrétise ces quatre libertés sous la forme d’une licencejuridique20 .Une particularité de la licence GPL est le copyleft, qui impose que les mêmes conditions se transmettentpour les œuvres dérivées. Ceci assure qu’un objet sous licence GPL reste indéfiniment couvert par cettemême licence lors de modifications. D’autres licences que la GPL possèdent cette même propriété.Il existe un effort d’adaptation de cette licence au droit français avec la création de la licence CeCILL21 .3.3.6 Open SourceL’Open Source Initiative définit pour sa part le concept de logiciel open source en 10 points : 1. Redistribution libre : La licence ne doit pas restreindre la vente ou la distribution du logiciel libre intégré dans un autre logiciel contenant des programmes de différentes origines. La licence ne doit pas exiger de compensation en échange de cette intégration. 2. Code source : Le programme doit inclure le code source, et doit autoriser la distribution du code source comme de l’exécutable compilé. Quand une forme quelconque du produit est distribuée sans le code source, il doit être clairement indiqué par quel moyen il est possible d’obtenir le code source, pour une somme qui ne doit pas excéder un coût raisonnable de reproduction, ou en le chargeant gratuitement via Internet. Le code source doit être la forme privilégiée par laquelle un programmeur modifie le programme. Un code source délibérément confus est interdit. Les formes intermédiaires de code source, telles que celles résultant d’un pré-processeur ou d’un traducteur, sont interdites. 3. Travaux dérivés : La licence doit autoriser les modifications et les travaux dérivés, et doit permettre leur distribution dans les mêmes termes que la licence du logiciel d’origine. 4. Intégrité du code source de l’auteur : La licence peut restreindre la distribution du code source modifié seulement si elle autorise la distribution de fichiers patchs avec le code source, dans le but de modifier le programme à la compilation. L’auteur peut ainsi garantir l’intégrité de son code source dans le processus de diffusion successive du logiciel. La licence doit explicitement permettre la distribution de logiciels obtenus à partir du code source modifié. La licence peut exiger que les travaux dérivés portent un nom ou un numéro de version différents du logiciel d’origine. 5. Absence de discrimination envers des personnes ou des groupes : La licence ne doit pas être discriminante à l’encontre de personnes ou de groupes de personnes. 6. Absence de discrimination envers des domaines d’activité : La licence ne doit pas restreindre ni interdire l’usage du logiciel à un quelconque domaine d’activité. Par exemple, il ne peut interdire l’usage du logiciel dans le cadre d’une activité professionnelle, ou en exclure l’usage pour la recherche génétique. 7. Distribution de licence : Les droits attachés au programme doivent s’appliquer à tous ceux à qui il est distribué sans qu’il leur soit besoin de se conformer à des termes de licence complémentaires. 8. La licence ne doit pas être spécifique à un produit : Les droits attachés au programme ne doivent pas dépendre du fait que le programme fait partie d’un logiciel en particulier. Si le programme est séparé du logiciel dans lequel il est intégré, et utilisé ou distribué selon les termes de la licence, toutes les parties à qui le programme est redistribué doivent avoir les mêmes droits que ceux accordés avec le logiciel dans lequel il est intégré à l’origine. 9. La licence ne doit pas imposer de restrictions sur d’autres logiciels : La licence ne doit pas imposer de restrictions sur d’autres logiciels distribués avec le programme sous licence. Par exemple, la licence ne doit pas exiger que les autres programmes distribués sur le même support physique soient aussi des logiciels libres. 10. La licence doit être neutre par rapport à la technologie : Aucune disposition de la licence ne doit dépendre d’une technologie ou d’une interface particulières. Par exemple, on ne peut pas obliger un utilisateur à décharger le logiciel uniquement depuis un site Web dans le but d’afficher de la publicité.La figure 1 présente quelques catégories de licences en regard des libertés accordées. 20 Le texte complet de la licence GNU GPL est donné sur http://www.fsf.org/licensing/licenses/gpl.html. 21 Voir le site Web dédié à CeCILL, http://www.cecill.info/.Observatoire Technologique, CTI 10
  11. 11. Standards ouverts et logiciel libre Clarification des notions Figure 1 – Types de licences et libertés.3.3.7 Licences doubles ou multiplesLes lois régissant le droit d’auteur permettent à ceux-ci de publier leurs œuvres simultanément sous plusieurstypes de licences. Ceci rend possible de différencier les contrats de licence appliqués selon le modèle queles utilisateurs veulent (ou parfois doivent) adopter. Cette pratique est désignée par le terme anglais (duallicensing).Ceci permet également d’envisager un modèle économique pour la distribution du logiciel. D’une part, uneutilisation à but commercial et/ou lucratif est régie par un contrat de licence propriétaire payante, alors que,d’autre part, une projet de logiciel libre peut intégrer exactement le même logiciel gratuitement en utilisantune licence open source et gratuite.Ce type de modèle est, par exemple, utilisé par la société MySQL fournissant la base de données du mêmenom ou encore par TrollTech qui maintient la librairie de construction d’interface utilisateur Qt.Par ailleurs, plusieurs organisations développant du logiciel libre recourent à ce même artifice en panachantdes licences du monde open source afin de faciliter l’intégration de composants propriétaires ou de permettreune réutilisation plus large dans la sphère commerciale. Les projets les plus connus utilisant des licencesmultiples de type libre sont OpenOffice.org, Perl et Mozilla.3.4 Perspectives open source dans le secteur publicL’intérêt du secteur public pour l’open source est aujourd’hui indéniable, en particulier parce qu’il met enœuvre des standards ouverts, qu’il brise les positions de lock-in et qu’il permet une plus grand adaptabilitéaux besoins particuliers22 .Les motivations essentielles avancées par les gouvernements sont une meilleure maîtrise de leurs propressystèmes d’information, une plus grande neutralité dans le choix de vendeurs de solutions ainsi qu’uneouverture vers les entreprises et les citoyens désirant ou devant interagir avec les administrations.De plus, on peut également voir un intérêt sociétal global car le modèle même du logiciel libre est fondé surle partage des connaissances et la réutilisation des composants. L’accessibilité des solutions open sourceest garantie pour tous : autres organismes du secteur public, entreprises privées, organisations non gouver-nementales, association ou simples citoyens.Par ailleurs, le développement économique local pour les sociétés de services informatiques peut être favo- 22 Pour une analyse plus détaillée de ces sujets voir aussi :Perspective Open Source, Rapport final du projet Nouvelles Plateformes Technologiques, P. Genoud et G.Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, Juin2003, http://www.geneve.ch/ot/Le logiciel libre dans les administrations, Annexe du projet Nouvelles Plateformes Technologiques, P. Genoudet G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève,Juin 2003, http://www.geneve.ch/ot/.Observatoire Technologique, CTI 11
  12. 12. Standards ouverts et logiciel libre Clarification des notionsrisé lors de l’adoption de technologies open source.Les solutions open source les plus mûres sont aujourd’hui encore celles touchant aux serveurs d’infrastruc-ture : web, messagerie, serveurs de fichiers et d’imprimantes, ainsi que le système d’exploitation du serveurlui-même. Plus récemment, les bases de données propriétaires classiques ont-elles aussi vu apparaître desalternatives libres crédibles.L’argumentation fondée uniquement sur une motivation de coûts est aujourd’hui dépassée : une analyse,souvent très onéreuse, ne permet généralement pas de discriminer clairement une solution propriétaire etune solution open source équivalente. Les administrations ont dans la plupart des cas compris que lesenjeux se situent au-delà du débat unidimensionnel du coût financier, même si celui-ci reste un élément dedécision non négligeable.Le logiciel libre dépasse aujourd’hui très largement un phénomène de mode passager. Le support profes-sionnel s’organise et de grandes, moyennes et petites entreprises offrent aujourd’hui leurs compétencesdans le domaine. Des projets open source d’envergure se fédèrent autour de communautés organisées quiont un mode de fonctionnement et une feuille de route clairs relativement aux produits qu’ils développent età leur processus de gestion. Le modèle même du logiciel libre est robuste aux changements économiques,car le produit ne dépend plus d’un seul acteur, mais d’un écosystème qui lui permet de vivre et d’évoluer.Les références d’utilisation de solutions open source au sein des administrations et des entreprises sont deplus en plus fréquentes, même si le domaine est encore jeune et les expérimentations souvent en cours.4 Les standards ouvertsComme le relève M. Erkki Liikanen23 , commissaire européen chargé des entreprises et de la société del’information : « Les standards ouverts sont un élément essentiel de la mise au point de solutions interopérables et abordables pour tous. En outre, ils stimulent la concurrence en établissant des conditions tech- niques égales pour tous les acteurs du marché, ce qui se traduit par des réductions de coût au profit des entreprises et, en définitive, des consommateurs. »Cette déclaration reflète le large consensus que l’on note actuellement autour des aspects positifs liés à lanotion d’ouverture. Il est cependant important d’examiner précisément quelle signification, quelles implica-tions et quelles limitations y sont associées.Du point de vue des organismes étatiques et para-étatiques, l’ouverture constitue une qualité premièrelorsque l’on désire développer une relation tournée directement vers les citoyens et les entreprises. Ellegarantit un accès large et équitable aux services proposés. Dans ce contexte, l’ouverture implique que lesservices publics garantissent un accès aux applications au travers de technologies variées qui n’imposentaucune plateforme, aucun système d’exploitation ni aucun matériels particuliers24 .L’utilisation de standards ouverts participe naturellement à cette notion d’ouverture avec pour vocation derépondre à des objectifs stratégiques tels que : – Maximiser l’indépendance des utilisateurs en augmentant leur liberté d’action, en évitant de leur im- poser des décisions technologiques et en prévenant les phénomènes de lock-in de la part des four- nisseurs informatiques. – Assurer que tous les acteurs soient au même niveau en ce qui concerne l’utilisation de ces standards, ce qui favorise l’innovation (faible coût d’entrée sur le marché). – Contribuer à la maîtrise et à la flexibilité des systèmes informatiques en garantissant leur interopéra- bilité. 23 Journée mondiale de la normalisation, 14 octobre 2003, http://europa.eu.int/rapid/pressReleasesAction.do?reference=IP/03/1374&format=HTML&aged=1&language=FR&guiLanguage=fr. 24 How Open Can Europe Get ?, Open Forum Europe, Novembre 2004, http://www.openforumeurope.org.Observatoire Technologique, CTI 12
  13. 13. Standards ouverts et logiciel libre Clarification des notions – Amener à une bonne gestion des coûts via une diminution du prix des licences due à une augmen- tation de la concurrence. L’utilisateur peut ainsi choisir le composant logiciel présentant le meilleur rapport qualité/prix. – Garantir un meilleur équilibre entre stabilité et innovation car aussi bien l’orientation que la vitesse d’évolution d’un standard ne peuvent être imposées par un seul acteur. – Favoriser la pérennité de l’information puisque l’accès à celle-ci n’est plus lié à un fournisseur infor- matique ou à un produit particuliers. – Améliorer l’échange et l’accessibilité à l’information. – Capitaliser sur le savoir en favorisant la valorisation des données et des informations. – Réduire la fracture numérique en plaçant les standards ouverts au rang de biens communs de l’hu- manité (gratuits, libres d’accès et de droits).Pour un développement détaillé de la plupart des points ci-dessus on peut se référer à l’article de ErikSliman25 qui propose un intéressant business case de la contribution des standards ouverts à l’économienumérique. A un autre niveau, le livre blanc du programme OSOSS26 lancé par le gouvernement néerlandaisconstitue une illustration de la façon de positionner certaines des contributions énoncées ci-dessus en regarddes objectifs stratégiques gouvernementaux.Michael Totschnig27 complète ce tableau en ajoutant deux points particulièrement importants en terme devision sociétale : « En comparaison avec les standards fermés et propriétaires, les standards ouverts présentent deux caractéristiques essentielles qui ont des conséquences importantes sur la possibilité d’un espace public numérique. D’une part, leur définition et leur évolution constituent les enjeux d’un débat public dans lequel peuvent intervenir un grand nombre d’acteurs concernés ; d’autre part, comme leur utilisation ne peut être contrôlée par un seul acteur, tout acteur qui veut les intégrer à de nouveaux produits peut se les approprier. Cependant, en tant que biens collectifs, ils n’appar- tiennent à personne dans le sens où aucun acteur ne peut profiter plus qu’un autre de la valeur ajoutée générée par l’adoption publique d’un standard. »Il ne faut pas négliger ces enjeux politiques et sociaux auxquels peuvent répondre les standards ouverts.Les rapports entre l’administration et les citoyens sont en effet en train de changer. Ces derniers, dans unsouci de transparence des institutions, revendiquent toujours plus vivement la possibilité de pouvoir accéderaux standards mis en œuvre. Or seul le processus d’élaboration d’un standard ouvert permet de prendre encompte valablement les intérêts de la société civile.4.1 Définitions et critèresLa notion de standard ouvert reste cependant un concept relativement flou qu’il est important de clarifier.Nous en donnons donc ci-dessous les définitions les plus communément utilisées afin de mieux comprendreles différents points de vue concernés et de pouvoir ainsi en dégager celle qui semble la mieux adaptée àla vision des différents partenaires de l’OT. Les notions générales de norme et de standard ont quant à ellesdéjà été clarifiées ailleurs28 et nous n’y reviendrons pas ici.Rappelons cependant que l’on distingue en général deux types de standards : ceux créés par le marché (defacto) et ceux validés par un organisme de normalisation (de jure). 25 Business Case for Open Standards, Erik Sliman, Mai 2002, http://www.openstandards.net/. 26 Programme for open standards and open source software in government, ICTU, Pays-Bas, 2004, http://www.ososs.nl/. 27 Les standards ouverts de l’informatique et l’espace public numérique, Michael Totschnig, Universitédu Québec à Montréal, Canada, 2001, http://commposite.uqam.ca/2001.1/articles/totsch.html. 28 Normes et standards ouverts, Annexe du rapport du projet Nouvelles Plateformes Technologiques, Pa-trick Genoud et Giorgio Pauletto, Observatoire Technologique, Centre des technologies de l’information ducanton de Genève, Juin 2003, http://www.geneve.ch/ot/.Observatoire Technologique, CTI 13
  14. 14. Standards ouverts et logiciel libre Clarification des notions Un standard de facto est introduit par un acteur du marché et s’établit de lui-même comme le ou l’un des standards dominants sans l’aval d’un organisme officiel de standardisation. Un standard de jure est établi par un organisme officiel de standardisation.Un standard de jure est habituellement le résultat d’un consensus entre les différents membres d’un orga-nisme officiel de standardisation qui est la plupart du temps composé à la fois de membres provenant d’ins-titutions publiques et d’acteurs du marché. Les processus de standardisation de ce type peuvent prendre untemps jugé excessif par certains mais ils ont le grand mérite de présenter un agenda très prévisible.Lorsque l’on parle de standard ouvert, c’est souvent par opposition au standard propriétaire. Il est alorsquestion de savoir dans quelle mesure les restrictions d’usage placées par le propriétaire du standard sontimportantes. Dans ce cas les propriétaires du standard sont ceux qui, au travers de leur savoir-faire et/oude la mise en application de brevets et de droits de propriété intellectuelle sont à même de décider qui peututiliser le standard et à quel prix. L’évolution du standard est également de leur ressort. Un standard propriétaire est caractérisé par le fait qu’il est la propriété de quelqu’un qui y met (ou peut y mettre) des restrictions d’usage et d’accès.Il est important de noter qu’un standard n’est en général jamais complètement fermé, ce qui irait à l’encontrede sa diffusion. Le propriétaire choisit en fait le degré d’ouverture qu’il accorde à son standard afin d’optima-liser ses bénéfices. Plus le standard est diffusé et plus il est attractif pour l’utilisateur, mais plus le revenu parutilisateur (en terme de licences) a tendance à baisser.Dans cette logique d’opposition au standard propriétaire, le gouvernement français, au travers de la LCEN29définit un standard ouvert comme suit : « On entend par standard ouvert tout protocole de communication, d’interconnexion ou d’échange et tout format de données interopérable et dont les spécifications techniques sont publiques et sans restriction d’accès ni de mise en œuvre. »En France on fait souvent référence à cette définition, même si elle manque selon nous de précision carelle n’aborde qu’une partie seulement des caractéristiques importantes liées à l’ouverture des standards.On y élude en effet les aspects liés au processus de validation par un organisme officiel de standardisationqui prennent une dimension essentielle lorsque l’on raisonne en termes d’indépendance et d’évolution dustandard.Une définition beaucoup plus complète des standards ouverts à laquelle on se réfère fréquemment est cellede Bruce Perens30 qui propose une perspective axée utilisateur et basée sur les six principes ci-dessous.Pour concrétiser la mise en œuvre de chacun de ces principes, une liste de meilleures pratiques (dontcertaines sont mentionnées ici) est proposée par l’auteur. 1. Disponibilité : l’accès et l’implémentation des standards sont ouverts à tous. – Le bon usage veut que la description et l’implémentation de référence d’un standard ouvert soient disponibles gratuitement en téléchargement sur Internet. – Chaque projet devrait être capable de fournir une copie sans frais excessifs. – Les licences attachées à la documentation des standards ne doivent restreindre aucune partie d’implémenter ce standard en utilisant quelque type de licence que ce soit. 29 LCEN — Loi pour la confiance dans l’économie numérique, Loi 2004-575 du 21 juin 2004, article 4,chap. Ier, titre Ier, http://www.foruminternet.org/documents/lois/lire.phtml?id=733. 30 Open Standards Principles and Practice, Bruce Perens, http://perens.com/OpenStandards/Definition.html.Observatoire Technologique, CTI 14
  15. 15. Standards ouverts et logiciel libre Clarification des notions – Le bon usage veut que les licences des plateformes de référence d’une application soient com- patibles avec toutes les formes de licences, libres ou propriétaires. 2. Maximiser le choix de l’utilisateur final : les standards ouverts créent un marché équitable et compétitif pour l’implémentation des standards. Ils ne lient pas les clients à un vendeur (ou un groupe de vendeurs) particulier. – Les standards ouverts doivent donc permettre une large gamme d’implémentations, que ce soit dans des projets métiers, académiques ou publiques. – Ils doivent supporter des solutions couvrant une large gamme de prix. 3. Pas de droits d’auteur : les standards ouverts sont libres de frais et de droits d’auteur. Seule l’émis- sion d’un certificat de conformité par l’organisme de standardisation peut impliquer des frais. – La licence des brevets contenus dans des standards doit être libre de droits et non discrimina- toire. 4. Pas de discrimination : les standards ouverts et les organismes qui les administrent ne doivent pas favoriser une implémentation plutôt qu’une autre pour une raison autre que la conformité technique de l’implémentation. Les organismes de certification doivent fournir le moyen de faire valider des implémentations à coût nul. Ils doivent également fournir des services de certification étendus. 5. Extension ou sous-ensemble : les implémentations de standards ouverts peuvent être étendues ou proposées sous forme de sous-ensembles. Cependant les organismes de certification peuvent refuser de certifier des sous-ensembles d’implémentations et peuvent imposer des exigences sur des extensions (voir Pratiques de prédateurs). 6. Pratiques de prédateurs : les standards ouverts peuvent recourir à des termes de licence qui les protègent contre des tactiques du type « englober / étendre ». Les licences attachées au standard peuvent exiger la publication d’informations de référence pour les extensions, et une licence pour la création, la distribution et la vente de software qui est compatible avec ces extensions. Un standard ouvert ne peut cependant pas interdire des extensions.Selon Ken Krechmer31 , la notion de standard ouvert peut être appréhendée en combinant les trois perspec-tives différentes que l’on peut en avoir, selon que l’on se place du point de vue du créateur du standard, decelui qui l’implémente ou de celui qui l’utilise. Chaque perspective est naturellement guidée par des consi-dérations très différentes. 1. Les organismes de standardisation qui représentent les créateurs de standards considèrent que ces derniers sont ouverts si leur élaboration suit les principes de séances ouvertes, de décisions par consensus et de processus clairement définis. 2. Les organismes qui implémentent un standard le considèrent comme ouvert lorsqu’il sert leurs marchés, lorsque son coût est nul, lorsqu’il n’empêche pas une innovation future, lorsqu’il ne rend pas obsolètes leurs implémentations précédentes et lorsqu’il ne favorise pas un concurrent. 3. Les utilisateurs de l’implémentation d’un standard le considèrent comme ouvert lorsque plusieurs implémentations (provenant de différentes sources) de ce standard sont disponibles, lorsque les im- plémentations de ce standard fonctionnent partout où nécessaire, lorsqu’elles sont supportées durant tout le cycle de vie des services utilisés et lorsque de nouvelles implémentations souhaitées par les utilisateurs sont compatibles avec les plus anciennes.Il est important de considérer ces trois points de vue afin de bien comprendre les attentes des différentsacteurs concernés. La combinaison de ces trois perspectives se traduit selon Krechmer dans dix droitsassociés à la notion de standard ouvert : 1. Séance ouverte : le processus de développement des standards est ouvert à tous. 2. Consensus : les intérêts de chacun sont discutés et pris en compte de manière équivalente. 3. Processus clairement définis : des processus de vote et de recours peuvent être utilisés pour résoudre un problème. 4. Droits de propriété intellectuelle ouverts : ils sont disponibles pour tous les implémenteurs. 5. Diffusion mondiale : pour des capacités données, un standard unique au niveau mondial. 31 The Meaning of Open Standards, Ken Krechmer, Hawaii International Conference on System Sciences,Janvier 2005, http://www.csrstds.com/openstds.html.Observatoire Technologique, CTI 15
  16. 16. Standards ouverts et logiciel libre Clarification des notions 6. Modifications ouvertes : toutes les modifications sont présentées et approuvées par un forum fonc- tionnant selon les cinq droits précédents. 7. Documentation ouverte : la documentation des standards comme de leurs avant-projets sont faci- lement accessibles, que ce soit pour leur implémentation ou pour leur utilisation. 8. Interfaces ouvertes : les interfaces doivent supporter des migrations et permettre un avantage pro- priétaire mais les interfaces standardisées ne doivent être ni cachées ni contrôlées. 9. Usage ouvert : les implémenteurs doivent pouvoir s’assurer objectivement de la conformité de leur implémentation. De leur côté les utilisateurs doivent avoir la garantie qu’elle répond à leurs besoins. 10. Suivi du support : les standards sont supportés jusqu’à ce que l’intérêt des utilisateurs cesse, et non jusqu’à ce que l’intérêt des implémenteurs diminue.On retrouve un certain nombre des critères énoncés par Perens. Mais le fait de tenir compte des pointsde vue des créateurs et des implémenteurs de standards en donne une vision plus pragmatique. Krechmery introduit également la notion de processus d’élaboration ouvert. Il a ainsi comparé les principaux orga-nismes de standardisation selon ces dix critères. Aucun n’obtient la note maximale. Selon lui, jusqu’à ceque chaque organisme de standardisation indique clairement lesquels de ces dix critères il soutient et dansquelle mesure, la notion de standard ouvert ne restera qu’un slogan publicitaire.Entre la définition succincte de la LCEN française et celles relativement complexes mais plus complètesproposées par Perens ou Krechmer il y a donc de la place pour des propositions intermédiaires, à la fois plussimples à mettre en œuvre et à communiquer. On citera ici deux définitions qui nous semblent pertinenteset qui vont dans ce sens. Celle proposée par le service gouvernemental belge Fedict32 , et celle de l’EIF, lecadre commun d’interopérabilité33 de la Commission Européenne.La définition de Fedict s’appuie sur les notions de spécification ouverte et de spécification libre pour définirun standard ouvert. Une spécification ouverte doit être gratuite, disponible en ligne et suffisante pour développer une implémentation complète. Une spécification libre doit être ouverte et ne doit pas comprendre de restrictions juridiques (à l’exception de « licences open source ») qui compliquent la diffusion et l’utilisation. Un standard ouvert est une spécification libre et doit être approuvé par une organisation de standardisation indépendante.Comme schématisé à la figure 2, cette définition permet de distinguer très directement les différents cas.Le standard PDF par exemple, qui est parfois présenté (à tort) comme un standard ouvert, y apparaît commeune spécification ouverte mais propriétaire. Elle est en effet la propriété de la société Adobe qui en contrôlel’évolution. On y retrouve les éléments clés liés à la notion d’ouverture comme l’accès gratuit à la spéci-fication, la liberté d’usage et l’adoption par une organisation indépendante et ouverte. Cette définition seconcentre sur les aspects jugés comme essentiels liés à l’ouverture du standard mais n’est pas aussi com-plète que celles proposées par Perens ou Krechmer.Avec le même souci de simplification, la Commission Européenne énonce une définition très similaire ins-pirée de celle en vigueur aux Pays-Bas (voir la section 7). Ainsi, selon l’EIF, un standard peut être qualifiéd’ouvert si : 32 Directives et recommandations pour l’usage de standards ouverts et/ou spécifications ouvertes dansles administrations fédérales, Jean Jochmans et Peter Strickx, Gouvernement fédéral de Belgique, 2003,http://www.belgium.be. 33 EIF — European Interoperability Framework for Pan-European eGovernment Services, IDABC, Com-mission Européenne, 2004, http://europa.eu.int.Observatoire Technologique, CTI 16
  17. 17. Standards ouverts et logiciel libre Clarification des notions Figure 2 – Des standards propriétaires aux standards ouverts (selon Fedict). 1. Il est adopté et maintenu par une organisation à but non lucratif. Son développement se fait sur la base d’une procédure décisionnaire ouverte disponible à toutes les parties inté- ressées (par consensus ou à la majorité par exemple). 2. Il a été publié et sa spécification est disponible soit gratuitement, soit à un coût nominal. Il doit être permis à chacun de le copier, de le distribuer et de l’utiliser soit gratuitement, soit à un coût nominal. 3. La propriété intellectuelle, c’est-à-dire les brevets éventuels, de tout ou partie du standard est cédée irrévocablement sur une base libre de royalties. 4. Il n’y a aucune contrainte à sa réutilisation.On y voit apparaître la notion de réutilisation du standard. Par contre la référence au fait que la spécifi-cation soit suffisante pour développer une implémentation complète n’y apparaît pas. On y introduit enfinla notion de coût nominal (synonyme de faible) qui peut prêter à interprétation et donc à confusion. Cettedernière notion est en effet relativement floue et n’entre d’ailleurs pas dans les critères proposés par BrucePerens. Lorsqu’un gouvernement ou une administration propose l’utilisation d’un standard ouvert à quelquesdizaines ou centaines de milliers de ses citoyens, cette notion de coût nominal peut amener des contraintesfinancières fortes selon l’interprétation qu’on lui donne.La simplicité de la définition de l’EIF a par contre le mérite de faciliter sa mise en œuvre et sa communication.Dans la mesure ou elle a été émise au niveau européen et qu’on s’y réfère dans plusieurs pays (la Norvègeet les Pays-Bas notamment, voir la section 7), on peut supposer qu’elle constituera, en Europe du moins,une définition de référence de la notion de standard ouvert.4.2 Degré d’ouverturePlusieurs standards se situent dans une zone grise entre standards propriétaires et standards ouverts. Ainsiles définitions proposées ci-dessus ne devraient pas être vues comme une exigence stricte pour qu’unObservatoire Technologique, CTI 17
  18. 18. Standards ouverts et logiciel libre Clarification des notionsstandard puisse être qualifié d’ouvert. Dans la pratique ces définitions devraient plutôt fournir les paramètresd’évaluation à utiliser pour qualifier le degré d’ouverture du standard étudié.La figure 3 illustre cette notion de zone grise. Quelques standards y sont sommairement positionnés en fonc-tion d’une part de la facilité d’accès à leurs spécifications et d’autre part du degré d’ouverture de l’organismequi l’a validé. Le schéma ne présente que deux des critères liés à la notion de standard ouvert. Si l’on s’entenait à ces deux critères uniquement, le standard ouvert idéal se situerait dans la zone en haut à droite dugraphique. Figure 3 – Degré d’ouverture d’un standard.L’exemple du coût nominal introduit dans la définition de l’EIF est illustratif. Le développement et la mainte-nance d’un standard efficace impliquent souvent des frais importants de la part du sponsor de ce standard.Ces coûts ne sont pas couverts si le standard peut être utilisé gratuitement, sauf au travers de la vente deproduits ou de services dérivés. La gratuité est donc une qualité idéale que l’on peut attendre d’un standardouvert mais qui se heurte à une vision pragmatique des choses. Dans de nombreux cas, on ne peut ainsipas s’attendre à ce que le standard ouvert idéal n’existe que parce qu’il correspond à un besoin exprimé.D’un autre côté, il est évident que la gratuité est un pré-requis nécessaire (mais pas suffisant) lorsque l’onconsidère des implémentations de logiciels libres qui doivent par essence pouvoir être redistribuées gratui-tement.On se trouve alors face à deux cas de figure. Soit l’on propose, comme l’EIF, une définition laissant unemarge d’interprétation qui permet de prendre en compte la zone grise autour du standard ouvert idéal. Maison y perd alors en terme de clarté de la définition puisque un certain nombre de termes peuvent être sujets àinterprétation. Soit l’on suit une approche similaire à celle du gouvernement danois34 qui donne une définitiondu standard ouvert dans sa forme la plus pure (propriétés fondamentales que l’on désire promouvoir) et quimet en œuvre une politique de standardisation pragmatique. Cette approche laisse une certaine marge demanœuvre par rapport à cet idéal en incluant le degré d’ouverture du standard dans les critères d’évaluation. 34 Definition of open standards, National IT and Telecom Agency, Ministry of Science, Technology andInnovation, Danemark, Juin 2004, http://www.itst.dk/.Observatoire Technologique, CTI 18
  19. 19. Standards ouverts et logiciel libre Clarification des notionsJoel West35 a étudié cette notion de degré d’ouverture et propose un certain nombre de dimensions per-mettant d’apporter une métrique lors de l’évaluation d’un standard. On peut les résumer au travers des 3questions suivantes. 1. QUI : Qui a accès au standard ? 2. QUOI : Dans quel(s) but(s) le standard est-il ouvert ? 3. COMMENT : Quel est l’accès donné au standard ?La figure 4 présente un tableau constituant un point de départ pour l’élaboration d’une telle métrique.Figure 4 – Questions permettant d’évaluer le degré d’ouverture d’un standard (selonWest).5 Organismes de normalisationCette section recense les principaux consortiums et organismes de standardisation œuvrant dans le do-maine des nouvelles technologies de l’information et de la communication. Cette liste n’est naturellementpas exhaustive. Les consortiums et organismes recensés ici travaillent à l’élaboration de standards que l’onpeut considérer à divers degrés comme ouverts.AFNOR Association Française de Normalisation. http://www.afnor.fr/ – Normalisation dans le domaine des technologies de l’information http://forum.afnor.fr/ANSI American National Standards Institute. http://www.ansi.org/ATIS Alliance for Telecommunications Industry Solutions. http://www.atis.org/ 35 What are Open Standards ? Implications for Adoption, Competition and Policy., J. West, Standards andPublic Policy Conference, Chicago, USA, Mai 2004, http://www.cob.sjsu.edu/west_j.Observatoire Technologique, CTI 19
  20. 20. Standards ouverts et logiciel libre Clarification des notionsCEN Comité Européen de Normalisation. http://www.cenorm.be/Dublin Core Dublin Core Metadata Initiative, Groupe engagé dans le développement de standards de mé- tadonnées. http://dublincore.org/ECMA European association for standardizing information and communication systems. http://www. ecma-international.org/ETSI European Telecommunications Standards Institute. http://www.etsi.org/FreeStandards.org The Free Standards Group. http://www.freestandards.org/ICTSB Information & Communications Technologies Standards Board. http://www.ictsb.org/IEC International Electrotechnical Commission. http://www.iec.ch/IEEE Institute of Electrical and Electronics Engineers. http://www.ieee.org/IETF Internet Engineering Task Force. http://www.ietf.org/ISO Organisation Internationale de Normalisation. http://www.iso.ch/ITU The International Telecommunication Union. http://www.itu.int/JCP Java Community Process. http://jcp.orgLiberty Alliance Liberty Alliance Project. http://www.projectliberty.orgLSB Linux Standard Base. http://www.linuxbase.org/NIST National Institute of Standards and Technology. http://www.nist.gov/ – Le sous-domaine ITL : Information Technology Lab. http://www.itl.nist.gov/OASIS Organization for the Advancement of Structured Information Standards. http://www.oasis-open. org/ – Liste de tous les standards de base associés aux technologies Markup Language. http:// xml.coverpages.org/coreStandards.html – Une introduction à ces standards. http://xml.coverpages.org/library.htmlODMG Object Data Management Group. http://www.odmg.org/OMA Open Mobile Alliance. http://www.openmobilealliance.org/OMG Object Management Group. Organisation internationale dont le but est de produire et de maintenir des spécifications pour des applications interopérables. http://www.omg.org/, notamment : – CORBA (Common Object Request Broker Architecture). http://www.corba.org/ – UML (Unified Modeling Language). http://www.uml.org/ – MDA (Model Driven Architecture). http://www.omg.org/mda/OpenGroup The Open Group. http://www.opengroup.org/OSGi Open Services Gateway Initiative. http://www.osgi.org/RosettaNet Open e-business process standards. http://www.rosettanet.org/TCG Trusted Computing Group. https://www.trustedcomputinggroup.org/UDDI.org Universal Description, Discovery, and Integration. http://www.uddi.org/VoiceXML Voice XML Forum. http://www.voicexml.org/W3C World Wide Web Consortium. http://www.w3.org/ – La liste de la cinquantaine de recommandations émises par le W3C. http://www.w3.org/ TR/#Recommendations – Ainsi que les domaines d’activités correspondants. http://www.w3.org/Consortium/Activities – Méthodes de travail du W3C par Alain Michard (en français). http://www.editions-eyrolles. com/livres/michard/w3c-present.aspWS-I Web Services Interoperability Organization. http://www.ws-i.org/Observatoire Technologique, CTI 20
  21. 21. Standards ouverts et logiciel libre Clarification des notions6 Standard ouvert vs logiciel libreLes chapitres précédents montrent combien les fondements des standards ouverts et des logiciels libressont basés sur des objectifs et des modes de fonctionnement similaires. Mais ces deux concepts différentmalgré tout : schématiquement, les standards ouverts concernent le contenu et l’échange d’information alorsque le logiciel libre ne relève que de l’accès au code source.Comme le souligne Jack Verhoosel36 , les développeurs de logiciels libres implémentent volontiers des stan-dards ouverts pour deux raisons. La première est que l’utilisation de standards propriétaires va à l’encontredes principes d’ouvertures et d’interopérabilité qui sont prônés par la communauté du libre et qu’ils n’ontaucun intérêt à lier les utilisateurs à leurs développements. La seconde concerne les coûts et les licencesd’utilisation éventuels des standards propriétaires qui vont à l’encontre de certaines licences open source.Il n’y a d’ailleurs pas toujours incompatibilité entre logiciel libre et standards propriétaires, pour autant queceux-ci soient publiquement accessibles, gratuits et libres d’utilisation. A l’inverse il est possible et mêmesouhaitable qu’un logiciel propriétaire implémente sans aucune restriction des standards ouverts. Ceci dé-pend fortement des conditions concurrentielles prévalant sur le marché.En principe la communauté open source préconise l’usage des standards ouverts. Mais ce n’est pas for-cément la règle. Cela peut provenir du fait qu’un standard ouvert potentiellement utilisable est incomplet,immature, de qualité insuffisante ou simplement qu’il n’existe pas. C’est parfois aussi tout bonnement liéau manque de maturité de la communauté de développeurs concernée par rapport à l’utilisation des stan-dards ouverts. Les spécialistes réunis lors de la conférence de Scottsdale37 tenue récemment sur le sujet,estiment qu’il y a encore un travail de sensibilisation à effectuer auprès de la communauté open source afinde la pousser à mieux implémenter les standards ouverts. « Le logiciel libre fait face à des défis importants, mais non insurmontables, dans son évolution actuelle. En tête de liste on retrouve les préoccupations liées à la propriété intellectuelle, à la nécessité de fournir des options de support et d’intégration aux usagers (et de les convaincre qu’ils sont fiables) et de gérer le risque tout en maximisant l’utilité des logiciels. Les standards (ouverts) proposent un outil efficace pour apporter une réponse à plusieurs de ces préoccupations. »Les logiciels libres auraient alors le double mérite d’implémenter des standards ouverts et de constituer unemétrique pour la qualité de ces standards. En effet un standard devrait de manière générale être pensé etconçu en considérant son implémentation future. Mais quel que soit son degré d’ouverture, il ne démontresa réelle utilité que dans la mesure où l’on peut se référer à des implémentations certifiées et accessibles.A ce niveau le lien entre logiciel libre et standards ouverts est manifeste car il est difficile de cacher l’implé-mentation d’un standard lorsque le code source est ouvert. Comme la communauté open source implémentegénéralement des solutions interopérables aussi conformes que possible aux standards ouverts, les logicielslibres de bonne qualité peuvent alors constituer des implémentations de référence accessibles.L’Union Européenne38 présente à cet égard le logiciel libre comme un modèle de développement idéal pours’assurer que les standards ouverts peuvent être correctement mis en œuvre et intégrés. Le cadre com-mun d’interopérabilité européen relève que : « Les logiciels libres sont, par leur nature, des spécificationspubliquement accessibles et l’ouverture de leur code source, promeut un débat ouvert et démocratique surles spécifications, ce qui les rend à la fois plus robustes et interopérables. En tant que tels, le logiciel librecorrespond aux objectifs du présent programme et devrait être évalué et considéré favorablement aux côtésd’alternatives propriétaires. »D’un autre côté, il est essentiel que les organismes de standardisation comprennent et acceptent les prin-cipes du logiciel libre. Le monde du libre aurait alors tout à y gagner. Certains comme Lawrence Rosen39 36 Open Standards and Open Source Software : Similarities and Differences, J. Verhoosel, Entschede,Pays-Bas, http://www-i4.informatik.rwth-aachen.de/~jakobs/Interop/Verhoosel.pdf. 37 Conference « Open Source, Open Standards : Maximizing Utility While Managing Exposure », 12-14Septembre 2004, Scottsdale, USA, http://www.thebolingroup.com/OSOSAnalysis.pdf 38 EIF — European Interoperability Framework for Pan-European eGovernment Services, IDABC, Com-mission Européenne, 2004, http://europa.eu.int. 39 Lawrence Rosen, http://www.rosenlaw.com/.Observatoire Technologique, CTI 21
  22. 22. Standards ouverts et logiciel libre Clarification des notionsproposent même une redéfinition de la notion de standard ouvert afin de faciliter l’alignement des deuxcommunautés. C’est principalement au niveau des droits de propriété intellectuelle et de gratuité que lesdéfinitions actuelles peuvent en effet poser problème.7 Politiques gouvernementalesPlusieurs gouvernements ont déjà pris position sur l’adoption des standards ouverts et du logiciel libre. Cespositions sont parfois très différentes et couvrent une large palette allant d’une non entrée en matière, à unevolonté politique très affirmée en passant par une attitude agnostique.La section suivante résume les prises de position gouvernementales qui nous paraissent les plus intéres-santes dans ce domaine. Cette liste n’est bien entendu pas exhaustive et évolue continuellement. Un recueilde liens est également disponible sur le site de l’IDABC40 .Le Center for Strategic and International Studies produit un document41 qui recense dans un tableau sy-noptique les politiques, les recommandations et les textes de loi considérés au niveau des administrationsnationales, régionales et locales sur la planète.Voici notre analyse en date du mois de juillet 2005.7.1 BelgiqueLe Conseil des Ministres du 25 juin 2004 a approuvé les directives et recommandations aux services publicsfédéraux pour l’usage de standards, de logiciels d’application et de logiciels libres, faits sur mesure42 :« Pour les nouveaux systèmes informatiques, les services publics fédéraux utiliseront désormais exclusive-ment des standards ouverts et/ou spécifications ouvertes pour les formats de données et les protocoles decommunication lors de l’archivage, de l’échange et de la communication de données électroniques. Pour lesapplications existantes qui, lors de l’archivage, de l’échange ou de la communication de données électro-niques à des parties externes, n’utilisent pas encore de standards ouverts et/ou de spécifications ouvertes,pour les formats de données et les protocoles de communication, les services publics fédéraux lanceront etachèveront une migration conformément à un planning convenu lors de la fixation de chaque standard ou-vert et/ou spécification ouverte. Les administrations fédérales disposeront des droits de propriété pour toutlogiciel fait sur mesure. Ce logiciel sera fourni en code source et sans droit de licence. Les services publicsfédéraux pourront mettre ce logiciel à la disposition d’autres services publics en tant que logiciel libre. »La stratégie 2005 du gouvernement belge est décrite par Peter Vanvelthoven, Secrétaire d’État à l’Informa-tisation de l’État43 . Le point 3.4 stipule clairement que toute nouvelle application informatique utilisera desstandards ouverts et que les applications existantes devront être migrées progressivement vers ceux-ci. Laliste des standards ouverts utilisés par l’État sera rassemblée au sein du Cadre Fédéral Belge d’Interopera-bilité en concertation avec les Communautés et Régions.De plus, le texte continue sur la position face au logiciel libre : « Les logiciels libres doivent être sérieusementpris en compte au sein de l’administration fédérale. Quelques services publics ont déjà commencé à migrerd’un environnement de logiciels propriétaires vers un environnement de logiciels libres. Fedict suivra cesprojets pilotes et évaluera les résultats et formulera des recommandations pour l’ensemble de l’administra-tion. »Le service gouvernemental Fedict44 définit la notion de standard ouvert comme : « une spécification gratuite, 40 Section du site Web du programme IDABC consacrée au logiciel libre : http://europa.eu.int/idabc/en/document/1677/471. 41 CSIS — Center for Strategic and International Studies, 13 décembre 2004, http://www.csis.org/tech/OpenSource/0408_ospolicies.pdf. 42 Standards et Logiciels, Chancellerie du Premier Ministre — Conseil des Ministres, Belgique, 2004,http://www.belgium.be/eportal/application?pageid=contentPage&docId=35409. 43 Note stratégique 2005, Secrétaire d’État à l’Informatisation de l’État, Peter Vanvelthoven, Belgique, 2005,http://www.belgium.be/eportal/application?pageid=contentPage&docId=36796. 44 Fedict a pour tâche d’initier, d’élaborer et d’accompagner des projets d’e-government pour l’administra-Observatoire Technologique, CTI 22
  23. 23. Standards ouverts et logiciel libre Clarification des notionsdisponible en ligne, suffisante pour développer une implémentation complète, qui ne doit pas comprendre derestrictions juridiques (à l’exception de « licences open source ») qui compliquent la diffusion et l’utilisationet qui doit être approuvée par une organisation de standardisation indépendante45 . »Cette définition est similaire à celle de la Commission Européenne, mais ne fait notamment pas intervenir lesnotions d’organisation de standardisation indépendante à but non lucratif, avec des procédures de décisionouvertes et la mise à disposition gratuite et irrévocable des droits de propriété intellectuelle contenus dansle standard. En revanche, elle précise bien que l’implémentation doit être possible ce qui ne ressort pasclairement de la définition européenne.Le gouvernement belge a défini un cadre commun d’interopérabilité46 dans lequel il concrétise sa visionrelative au logiciel libre et aux standards ouverts. La consultation de ce référentiel est largement ouverte(même aux contributions externes) dans le but de définir les standards techniques à travers un wiki 47 qui enpermet la mise à jour continue.7.2 BrésilLe président brésilien, Luís Inácio Lula da Silva, a donné le mandat le 29 octobre 2003 à l’Institut Natio-nal de Technologie Informatique (ITI) de planifier, coordonner et implémenter les projets du gouvernementconcernant le logiciel libre48 (article 1).Le ITI intègre le Comité Exécutif du Gouvernement Électronique, lequel coordonne le Comité Techniqued’Implémentation du Logiciel Libre du Gouvernement Fédéral49 .Dans son plan stratégique de mai 2004, le comité Exécutif du Gouvernement Électronique précise d’entréeque « le logiciel libre doit être utilisé comme une ressource stratégique » (page 8).La position du gouvernement brésilien face aux technologies de l’information est clairement une vision trèslarge de développement économique et social, ainsi que de diminution de la fracture numérique. Le 18 juin2004 Sérgio Amadeu da Silveira, directeur de l’ITI, déclarait : « Nous n’optons pas pour un produit, nousoptons pour un modèle de développement et d’utilisation de logiciel. C’est une décision politique, et j’insistesur ce point, fondée sur une raison économique — une réduction du paiement de royalties. Cette décisionaugmente aussi l’autonomie technologique du Brésil et renforce notre intelligence collective. »La plupart des sites web gouvernementaux brésiliens utilisent des composants libres et le gouvernementimpose aux organismes d’état ou aux compagnies privées bénéficiant de financements gouvernementauxde développer et d’éditer leurs logiciels sous licence libre GNU/GPL50 .Un autre point intéressant est que le gouvernement préfère le logiciel libre pour éviter la gestion coûteuseles licences de produits propriétaires ou le risque de piratage qui le mettrait également face à des coûts etdes poursuites judiciaires possibles.Microsoft a proposé une version moins coûteuse, mais amputée de plusieurs fonctionnalités de Windows XP(baptisée Windows Starter Edition) au Brésil. Toutefois, cette option a été finalement écartée par le gouver-nement brésilien. La décision a été très largement influencée par le rapport commandé par le gouvernementà Walter Blender, directeur exécutif du MIT MediaLab (Massachussets Institute of Technology), qui a chau-dement recommandé l’usage des logiciels libres de bonne qualité qui sont, selon lui, plus intéressants quetion fédérale. Il dépend des services publics fédéraux et de programmation dans le cadre des technologiesde l’information et de la communication http://www.belgium.be/eportal/application?pageid=indexPage&navId=9513. 45 Directives et recommandations pour l’usage de standards ouverts et/ou spécifications ouvertes dansles administrations fédérales, Jean Jochmans et Peter Strickx, Gouvernement fédéral de Belgique, 2003,http://www.belgium.be. 46 BELGIF — BELgian Governement Interoperability Framework, http://www.belgif.be. 47 Un wiki est un site web dynamique dont tout visiteur peut modifier les pages à volonté. Pour plus d’infor-mation voir http://fr.wikipedia.org/wiki/Wiki. 48 Voir le site du Gouvernement brésilien, http://www.governoeletronico.gov.br/governoeletronico/index.html. 49 Software Livre, Gouvernement du Brésil, http://www.softwarelivre.gov.br/. 50 Brazil : Free Software’s Biggest and Best Friend, Todd Benson, The New-York Times, 29 mars 2005,http://www.nytimes.com/2005/03/29/technology/29computer.html.Observatoire Technologique, CTI 23
  24. 24. Standards ouverts et logiciel libre Clarification des notionsles versions propriétaires limitées.7.3 DanemarkLe gouvernement danois (Ministère des sciences et technologies, et de l’innovation) a adopté le 13 juin 2003une stratégie relative à l’utilisation de logiciels dans le but d’accroître la concurrence du marché du logicielet d’augmenter la qualité et la cohérence des produits logiciels déployés dans le secteur public51 . Cettestratégie est déclinée selon une série de principes : 1. Valeur monétaire : Le principe gouvernant le choix, l’approvisionnement et l’utilisation de logiciels dans le secteur public est la recherche de la valeur maximale, fondée sur une approche coûts/bénéfices, indépendamment du fait d’utiliser du logiciel propriétaire ou libre. 2. Concurrence, indépendance et liberté de choix : Une concurrence effective est un pré-requis es- sentiel pour un marché du logiciel compétitif et diversifié. Les distributeurs de logiciel doivent pouvoir se concurrencer à « armes égales » et les barrières d’entrée doivent être éliminées. 3. Interopérabilité et flexibilité : La priorité doit être donnée aux logiciels qui sont construits de façon modulaire et qui peuvent s’interconnecter avec d’autres types de programmes et de systèmes. Ceci permet d’assurer que les modules du système logiciel peuvent être changés ou modifiés indépen- damment et ainsi augmenter la flexibilité et permettre la réutilisation. 4. Développement et innovation : Le secteur public doit être ouvert aux nouvelles méthodes d’approvi- sionnement et de développement de logiciel. En particulier, il existe un besoin de tester de nouvelles méthodes comme celles de développement du logiciel libre afin de les évaluer et d’en mesurer les avantages et les inconvénients à large échelle dans le cadre des administrations publiques.Pour soutenir ces objectifs stratégiques, les activités suivantes sont lancées : – Développer une signature numérique publique basée sur une solution open source. – Développer une analyse du coût total de possession (Total Cost of Ownership). – Démarrer des projets pilotes dans les administrations centrales, régionales et locales. – Suivre l’usage de standards ouverts et la définition d’un format de document ouvert. – Élargir le marché du logiciel pour le secteur public. – Favoriser la collecte et la dissémination de l’information.Un travail conséquent de standardisation des informations est entrepris. Ces résultats enrichissent un ré-férentiel XML afin de soutenir l’ensemble de la démarche. Le projet est nommé Infostructurebase52 et sonobjectif est de déterminer des standards pour l’échange de données en interne ainsi qu’entre les autoritésgouvernementales, le public et les entreprises. La standardisation est une étape nécessaire vers l’utilisationet la réutilisation des données sur le long terme en s’assurant de l’absence de blocage (lock-in) dans desoutils propriétaires ou des formats non documentés.La méthodologie de standardisation adoptée est très intéressante. Elle laisse des groupes d’utilisateurs,appelés communautés de pratique, définir les standards relatifs à leurs métiers en collaboration avec lesinformaticiens. Le rôle de ces communautés de pratique est de classifier et clarifier les termes et conceptsutilisés lors d’échanges d’informations ainsi que leurs besoins d’interopérabilité en créant des définitionsstandard d’objets informationnels. Ces standards sont ensuite proposés à un comité XML qui revoit, accepteet publie les résultats. Ces résultats forment une base de référence pour le groupe de travail technique quiest ensuite chargé de rédiger les schémas XML correspondants.Ceci permet de réconcilier les architectures métier et technique. D’une part, les communautés de pratiquedéfinissent les concepts, la terminologie, les significations et les associations ainsi que les manières detravailler avec l’information. D’autre part, ces inputs sont intégrés dans les schémas par les informaticiensqui, eux, n’ont pas toujours une compréhension complète du domaine ou un ressenti exact de l’importancedes relations spécifiques au métier. 51 ICA Country Report, Danemark, 2003, http://e.gov.dk/english/results/2003/benchmarking_ica_country_report_denmark_2003/index.html. 52 OIO — Infostructurebase, Danemark, http://isb.oio.dk/Info/Standardization/Standardization.htm.Observatoire Technologique, CTI 24
  25. 25. Standards ouverts et logiciel libre Clarification des notions7.4 États-Unis, MassachusettsLe gouvernement de l’État du Massachusetts a publié le 13 janvier 2003 deux documents concernant saposition vis-à-vis des standards ouverts et du logiciel libre.Le premier53 exige l’utilisation de standards ouverts comme critère sélectif lors de la création, de l’acquisitionou de la refonte d’applications informatiques afin d’assurer que les investissements dans les technologiesde l’information soient consacrés à des solutions suffisamment interopérables pour satisfaire aux exigencesmétier de ses départements et servir au mieux le public.L’État du Massachusetts propose la définition suivante du standard ouvert : « Une spécification qui est dis-ponible publiquement, développée par une communauté ouverte et confirmée par un organisme de norma-lisation. »Le second document54 concerne l’acquisition de logiciels et stipule que les solutions doivent être sélection-nées selon la valeur mesurée au-delà du pur aspect financier.Il est nécessaire de considérer au minimum : le coût total de possession sur la durée de vie de la solution,l’adéquation aux besoins métier, la stabilité, la performance, la scalabilité, la sécurité, les exigences demaintenance, les risques légaux, la facilité de d’adaptation et la facilité de migration.Toutes les alternatives incluant en particulier, les logiciels propriétaires, les logiciels libres ainsi que leslogiciels dont le code est partagé entre les administrations doivent être examinées.La position de cet état a eu une grande visibilité médiatique. Les déclarations de ses représentants, le CIOPeter J. Quinn et le Secrétaire d’État Eric Kriss55 ont poussé Microsoft à négocier et à proposer une version« moins fermée » du format XML des fichiers MS Office.L’état du Massachussets a pris position sur les formats de données et identifie le OASIS Open DocumentFormat comme le standard choisi pour les applications bureautiques56 . Depuis le 21 septembre 2005, leformat OpenDocument est l’un des standards de données référencés par leur modèle de référence techniquequi catalogue les standards officellement adoptés57 .Au niveau fédéral américain, l’Office of Management and Budget recommande que les agences gouver-nementales aient des politiques d’acquisition de logiciels « neutres quant aux technologies et aux fournis-seurs. »7.5 FranceL’Agence pour le Développement de l’Administration Électronique58 (ADAE) met à disposition des ministèreset des services un guide de choix et d’usage des licences de logiciels libres pour les administrations. Ceguide recommande de privilégier l’utilisation de la licence GNU GPL pour les développements en logicielslibres réalisés par ou pour les administrations. Il préconise également une démarche qui s’appuie sur lecode des marchés publics. L’ADAE a aussi largement soutenu l’information sur les solutions de logiciel libre 53 Enterprise Open Standards Policy, Commonwealth of Massachusetts, Massachusetts, USA, 13 janvier2004, http://www.mass.gov/Aitd/docs/policies_standards/openstandards.pdf. 54 Enterprise Information Technology Acquisition Policy, Commonwealth of Massachusetts, Mas-sachusetts, USA, 13 janvier 2004, http://www.mass.gov/Aitd/docs/policies_standards/itacquisitionpolicy.pdf. 55 Une retranscription officielle des commentaires informels donnés lors de la confé-rence de presse http://www.mass.gov/eoaf/open_formats_comments.html etleur traduction en français http://formats-ouverts.org/blog/2005/01/21/255-traduction-du-texte-officiel-du-massachussets-sur-les-formats-ouverts. 56 Déclaration de Peter Quinn du 29 août 2005 sur le site du http://www.mass.gov/Aitd/ et in-formations sur le site de News.com Massachusetts to adopt ’open’ desktop http://news.com.com/2102-1012_3-5845451.html. 57 Voir le document Enterprise Technical Reference Model Version 3.5 http://www.mass.gov/Aitd/docs/policies_standards/etrm3dot5/etrmv3dot5informationdomain.pdf page 18. 58 ADAE - Agence pour le Développement de l’Administration Électronique, http://www.adae.gouv.fr/.Observatoire Technologique, CTI 25

×