Standards ouverts et logiciels libres

Standards ouverts et logiciel libre
Clariﬁcation des notions

Observatoire Technologique
Centre des technologies de l’information
République et Canton de Genève

P. Genoud, G. Pauletto

30 septembre 2005

Observatoire Technologique
Centre des Technologies de l’Information
République et Canton de Genève
CP 2285, 1211 Genève 2, Suisse
http://www.geneve.ch/ot/
ot@etat.ge.ch

1

Standards ouverts et logiciel libre Clariﬁcation des notions

Copyright c 2005 CTI, Observatoire Technologique.

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view
a 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 works

Under the following conditions:

Attribution. ou must attribute the work in the manner speciﬁed 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


Table des matières

1 Introduction 5

2 Interopérabilité 5

3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Les standards ouverts 12

4.1 Déﬁnitions et critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Degré d’ouverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Organismes de normalisation 19

6 Standard ouvert vs logiciel libre 21

7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8 Domaine de l’éducation et de la recherche 30



9 Conclusions 33

Ré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 ﬁnale
0.9 2005-07-21 / pge, gip Pour soumission à la direction du projet
0.91 2005-09-05 / pge, gip Modiﬁcations après retour de la direction du projet
1.0 2005-09-30 / pge, gip Après validation par la direction du projet



1 Introduction

Au cours de l’année 2004, plusieurs signaux ont été émis affirmant la volonté de l’administration genevoise
de se tourner d’ici 2009 d’une part vers le logiciel libre, mais aussi et surtout vers les standards ouverts. Des
dé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éenne
dé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 entreprises
informatiques partenaires. Les informations fournies sont plus ou moins bien comprises et appréciées par
les différents acteurs concernés. Elles suscitent de nombreuses questions auxquelles il faudra répondre
clairement 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 Logiciel
Libre » (SOLL) confié conjointement à l’Observatoire Technologique (OT) par la Direction Générale du Centre
des technologies de l’information de l’État de Genève (CTI), par la Direction Informatique de l’Université de
Genè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és
concernées, surtout en ce qui concerne l’aspect plus ou moins restrictif des critères que doivent respecter
les 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 les
esprits, que ce soit en interne ou en externe à l’entreprise ou à l’organisation concernées. Ce document
reprend 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 aux
mandants du projet SOLL d’en proposer leur propre acception en toute connaissance de cause. La notion
d’interopérabilité est développée en préambule, car elle constitue le concept de base autour duquel viennent
naturellement s’articuler les standards ouverts et le logiciel libre. Un chapitre est également consacré à la
clarification 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 standards
ouverts. Nous proposons dans ce document une brève description de quelques politiques gouvernementales
qui illustrent les diverses manières d’aborder cette problématique et qui peuvent servir de référence dans ce
domaine. Enfin, un recensement de quelques initiatives phares dans le milieu académique est également
proposé.

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 recouvre
l’utilisation de nouvelles technologies en vue de transformer les administrations publiques et d’améliorer
radicalement les contacts avec leurs clients (citoyens, entreprises ou autres administrations).

Ces transformations passent notamment par un décloisonnement des divers services et départements de
l’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 et
Geneva to switch to open source by 2009, http://europa.eu.int/idabc/en/document/3601, Site
de l’IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses
and 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.



une 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 soient
interopérables. L’interopérabilité se situe alors au cœur du rapprochement des services des administrations
publiques. Elle désigne ici la capacité qu’ont les technologies de l’information et de la communication ainsi
que les processus qu’elles soutiennent à échanger des données et à permettre le partage de l’information et
de 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 et
pé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) afin
notamment 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 processus
administratifs et par la nécessité d’inclure la notion de partage de l’information. On considère ainsi trois
aspects 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 suffisant
lorsque 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 le
domaine, 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 traduit
notamment 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/.



ré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 normes
et 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 fait
que l’interopérabilité des systèmes d’information des institutions gouvernementales constitue une condition
préalable indispensable si l’on désire mettre en place un secteur public plus compétitif et orienté vers les
services 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érentiel
e-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’ils
gèrent au quotidien, ce qui amène naturellement à revendiquer une plus grande maîtrise de leurs systèmes
d’information. C’est donc logiquement que la notion d’indépendance vis-à-vis des fournisseurs constitue un
principe 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 gouvernements
placent d’ailleurs ces notions au cœur de leur stratégie.

3 Logiciel libre

Les technologies appartenant au domaine dit du logiciel libre ou « open source » sont présentes depuis un
certain nombre d’années, mais le concept n’a pris de l’ampleur dans le monde informatique que depuis peu
avec 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 de
licence et un modèle de développement. La section suivante présente une perspective très partielle de ce
sujet qui mériterait un éclairage bien plus conséquent. Mais la littérature consacrée au logiciel libre abonde
et le lecteur trouvera sans difficulté une publication de référence. Pour n’en citer qu’une, nous mentionnerons
le récent livre blanc Organisations et logiciels libres15 qui permet une première approche du secteur à la fois
pour 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 logiciel
libre. Malheureusement, le terme anglais « free » signifie aussi bien libre que gratuit ce qui a causé beaucoup
de 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 de
l’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 technologies
de 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/.



Il serait faux de penser que parce qu’un logiciel est gratuit, il est libre. Il serait également erroné de croire
que 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 malentendu
et dédramatiser les débats entre les tenants du logiciel propriétaire et du logiciel libre, en amenant une vue
plus 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’hui
largement 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 œuvre
par 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ésentation
détaillée de cette problématique est donnée ailleurs18 .

3.1 Le modèle open source

On peut définir la notion de modèle open source comme l’ensemble des principes et des bonnes pratiques
régissant le développement, le déploiement et le support de ce type de logiciel. Au cœur de ce modèle
on retrouve le mouvement open source dont la préoccupation majeure est de protéger les privilèges des
utilisateurs plutôt que celui des auteurs19 . dans ce domaine.

3.2 Les communautés open source

Le 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 souvent
des rôles multiples au sein de leur communauté et se sentent très concernés par la réussite ou l’échec du
projet auquel ils participent.

La communauté rassemblée autour d’un projet substitue au concept traditionnel de propriété la notion de
service. Puisqu’aucune entité ne possède le logiciel, personne ne peut le contrôler, même si un petit groupe
de 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 un
autre projet distinct (forking). Cette dynamique conduit à la création d’un écosystème de projets au sein
duquel s’effectue une véritable sélection naturelle favorisant les projets de qualité qui répondent le mieux
aux besoins des utilisateurs. La taille de la communauté associée à un projet constitue en principe un bon
indicateur 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 programmes
d’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 et
G. 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évrier
2005.



3.3 Catégories de logiciel

3.3.1 Domaine public

Les logiciels dans le domaine public ne sont pas protégés par des droits d’auteur. Ils sont explicitement
déposés dans le domaine public par leur(s) auteur(s), car par défaut, tout programme est protégé par le
copyright attribué automatiquement à son auteur. Pour un logiciel dans cette catégorie toute modification est
possible, mais il peut basculer vers une autre licence à tout moment. De plus, rien ne garantit que le code
source soit disponible.

3.3.2 Propriétaire

Le 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. Les
droits de propriété sont détenus par la société qui le distribue ou par son auteur. Le code source peut être
mis à disposition ou non, mais sa protection reste garantie par le droit d’auteur et la propriété intellectuelle
appartient au fournisseur du programme.

3.3.3 Shareware / Freeware

La catégorie shareware / freeware est souvent confondue à tort avec l’open source. Un logiciel freeware
est un logiciel gratuit qui permet l’utilisation et la redistribution de l’exécutable ; les codes sources ne sont
généralement pas fournis et la modification n’est pas autorisée. Cette catégorie n’a en général pas de réel
point commun avec l’open source, mise à part dans certains cas, la gratuité. Un logiciel shareware est
un freeware limité dans le temps qui devient payant une fois une date limite ou un nombre d’utilisations
dépassés.

3.3.4 Commercial

Il 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 comme
RedHat, Novell et Mandriva en sont la preuve. Ces entreprises commercialisent des solutions open source et
y 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 du
logiciel libre. Il devient de plus en plus important d’utiliser le vocabulaire adéquat pour éviter les ambiguïtés
comme 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’utilisateur
les 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.



La licence GNU General Public License (GPL) concrétise ces quatre libertés sous la forme d’une licence
juridique20 .

Une particularité de la licence GPL est le copyleft, qui impose que les mêmes conditions se transmettent
pour les œuvres dérivées. Ceci assure qu’un objet sous licence GPL reste indéfiniment couvert par cette
mê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 Source

L’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/.



Figure 1 – Types de licences et libertés.

3.3.7 Licences doubles ou multiples

Les lois régissant le droit d’auteur permettent à ceux-ci de publier leurs œuvres simultanément sous plusieurs
types de licences. Ceci rend possible de différencier les contrats de licence appliqués selon le modèle que
les utilisateurs veulent (ou parfois doivent) adopter. Cette pratique est désignée par le terme anglais (dual
licensing).

Ceci permet également d’envisager un modèle économique pour la distribution du logiciel. D’une part, une
utilisation à 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 utilisant
une 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ême
nom 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 panachant
des licences du monde open source afin de faciliter l’intégration de composants propriétaires ou de permettre
une réutilisation plus large dans la sphère commerciale. Les projets les plus connus utilisant des licences
multiples de type libre sont OpenOffice.org, Perl et Mozilla.

3.4 Perspectives open source dans le secteur public

L’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 propres
systèmes d’information, une plus grande neutralité dans le choix de vendeurs de solutions ainsi qu’une
ouverture 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é sur
le partage des connaissances et la réutilisation des composants. L’accessibilité des solutions open source
est 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, Juin
2003, http://www.geneve.ch/ot/
Le logiciel libre dans les administrations, Annexe du projet Nouvelles Plateformes Technologiques, P. Genoud
et G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève,
Juin 2003, http://www.geneve.ch/ot/.



risé 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 serveur
lui-même. Plus récemment, les bases de données propriétaires classiques ont-elles aussi vu apparaître des
alternatives 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 et
une solution open source équivalente. Les administrations ont dans la plupart des cas compris que les
enjeux se situent au-delà du débat unidimensionnel du coût financier, même si celui-ci reste un élément de
dé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étences
dans le domaine. Des projets open source d’envergure se fédèrent autour de communautés organisées qui
ont 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 de
plus en plus fréquentes, même si le domaine est encore jeune et les expérimentations souvent en cours.

4 Les standards ouverts

Comme le relève M. Erkki Liikanen23 , commissaire européen chargé des entreprises et de la société de
l’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 à la
notion 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ère
lorsque l’on désire développer une relation tournée directement vers les citoyens et les entreprises. Elle
garantit un accès large et équitable aux services proposés. Dans ce contexte, l’ouverture implique que les
services publics garantissent un accès aux applications au travers de technologies variées qui n’imposent
aucune 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 de
ré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.



– 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 Erik
Sliman25 qui propose un intéressant business case de la contribution des standards ouverts à l’économie
numérique. A un autre niveau, le livre blanc du programme OSOSS26 lancé par le gouvernement néerlandais
constitue une illustration de la façon de positionner certaines des contributions énoncées ci-dessus en regard
des objectifs stratégiques gouvernementaux.

Michael Totschnig27 complète ce tableau en ajoutant deux points particulièrement importants en terme de
vision 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 un
souci de transparence des institutions, revendiquent toujours plus vivement la possibilité de pouvoir accéder
aux standards mis en œuvre. Or seul le processus d’élaboration d’un standard ouvert permet de prendre en
compte valablement les intérêts de la société civile.

4.1 Définitions et critères

La 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 comprendre
les 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 à elles
dé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é (de
facto) 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 du
canton de Genève, Juin 2003, http://www.geneve.ch/ot/.



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 un
temps 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 alors
question de savoir dans quelle mesure les restrictions d’usage placées par le propriétaire du standard sont
importantes. Dans ce cas les propriétaires du standard sont ceux qui, au travers de leur savoir-faire et/ou
de la mise en application de brevets et de droits de propriété intellectuelle sont à même de décider qui peut
utiliser 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’encontre
de 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 par
utilisateur (en terme de licences) a tendance à baisser.

Dans cette logique d’opposition au standard propriétaire, le gouvernement français, au travers de la LCEN29
dé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 car
elle 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 standardisation
qui prennent une dimension essentielle lorsque l’on raisonne en termes d’indépendance et d’évolution du
standard.

Une définition beaucoup plus complète des standards ouverts à laquelle on se réfère fréquemment est celle
de 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 (dont
certaines 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.



– 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, de
celui 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érents
acteurs concernés. La combinaison de ces trois perspectives se traduit selon Krechmer dans dix droits
associé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.



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 points
de vue des créateurs et des implémenteurs de standards en donne une vision plus pragmatique. Krechmer
y 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’à ce
que chaque organisme de standardisation indique clairement lesquels de ces dix critères il soutient et dans
quelle 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ètes
proposées par Perens ou Krechmer il y a donc de la place pour des propositions intermédiaires, à la fois plus
simples à mettre en œuvre et à communiquer. On citera ici deux définitions qui nous semblent pertinentes
et qui vont dans ce sens. Celle proposée par le service gouvernemental belge Fedict32 , et celle de l’EIF, le
cadre 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éfinir
un 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 comme
une spécification ouverte mais propriétaire. Elle est en effet la propriété de la société Adobe qui en contrôle
l’é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 se
concentre 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 dans
les administrations fédérales, Jean Jochmans et Peter Strickx, Gouvernement fédéral de Belgique, 2003,
http://www.belgium.be.
33



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 enfin
la notion de coût nominal (synonyme de faible) qui peut prêter à interprétation et donc à confusion. Cette
dernière notion est en effet relativement floue et n’entre d’ailleurs pas dans les critères proposés par Bruce
Perens. Lorsqu’un gouvernement ou une administration propose l’utilisation d’un standard ouvert à quelques
dizaines ou centaines de milliers de ses citoyens, cette notion de coût nominal peut amener des contraintes
financiè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ège
et 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’ouverture

Plusieurs standards se situent dans une zone grise entre standards propriétaires et standards ouverts. Ainsi
les définitions proposées ci-dessus ne devraient pas être vues comme une exigence stricte pour qu’un



standard puisse être qualifié d’ouvert. Dans la pratique ces définitions devraient plutôt fournir les paramètres
d’é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’organisme
qui 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’en
tenait à ces deux critères uniquement, le standard ouvert idéal se situerait dans la zone en haut à droite du
graphique.

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 de
produits ou de services dérivés. La gratuité est donc une qualité idéale que l’on peut attendre d’un standard
ouvert mais qui se heurte à une vision pragmatique des choses. Dans de nombreux cas, on ne peut ainsi
pas 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’on
considè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 une
marge d’interprétation qui permet de prendre en compte la zone grise autour du standard ouvert idéal. Mais
on 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éfinition
du standard ouvert dans sa forme la plus pure (propriétés fondamentales que l’on désire promouvoir) et qui
met en œuvre une politique de standardisation pragmatique. Cette approche laisse une certaine marge de
manœ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 and
Innovation, Danemark, Juin 2004, http://www.itst.dk/.



Joel 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 3
questions 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 ﬁgure 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 (selon
West).

5 Organismes de normalisation

Cette 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 naturellement
pas exhaustive. Les consortiums et organismes recensés ici travaillent à l’élaboration de standards que l’on
peut 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 and
Public Policy Conference, Chicago, USA, Mai 2004, http://www.cob.sjsu.edu/west_j.



CEN 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.org
Liberty Alliance Liberty Alliance Project. http://www.projectliberty.org
LSB 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.html
ODMG 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éciﬁcations pour des applications interopérables. http://www.omg.org/, notamment :
– CORBA (Common Object Request Broker Architecture). http://www.corba.org/
– UML (Uniﬁed 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.asp
WS-I Web Services Interoperability Organization. http://www.ws-i.org/



6 Standard ouvert vs logiciel libre

Les chapitres précédents montrent combien les fondements des standards ouverts et des logiciels libres
sont basés sur des objectifs et des modes de fonctionnement similaires. Mais ces deux concepts différent
malgré tout : schématiquement, les standards ouverts concernent le contenu et l’échange d’information alors
que 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’encontre
des principes d’ouvertures et d’interopérabilité qui sont prônés par la communauté du libre et qu’ils n’ont
aucun intérêt à lier les utilisateurs à leurs développements. La seconde concerne les coûts et les licences
d’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 que
ceux-ci soient publiquement accessibles, gratuits et libres d’utilisation. A l’inverse il est possible et même
souhaitable 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 afin
de 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 une
métrique pour la qualité de ces standards. En effet un standard devrait de manière générale être pensé et
conçu en considérant son implémentation future. Mais quel que soit son degré d’ouverture, il ne démontre
sa 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émente
généralement des solutions interopérables aussi conformes que possible aux standards ouverts, les logiciels
libres 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 pour
s’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écifications
publiquement accessibles et l’ouverture de leur code source, promeut un débat ouvert et démocratique sur
les spécifications, ce qui les rend à la fois plus robustes et interopérables. En tant que tels, le logiciel libre
correspond aux objectifs du présent programme et devrait être évalué et considéré favorablement aux côtés
d’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-14
Septembre 2004, Scottsdale, USA, http://www.thebolingroup.com/OSOSAnalysis.pdf
38
39
Lawrence Rosen, http://www.rosenlaw.com/.



proposent même une redéfinition de la notion de standard ouvert afin de faciliter l’alignement des deux
communautés. C’est principalement au niveau des droits de propriété intellectuelle et de gratuité que les
définitions actuelles peuvent en effet poser problème.

7 Politiques gouvernementales

Plusieurs gouvernements ont déjà pris position sur l’adoption des standards ouverts et du logiciel libre. Ces
positions sont parfois très différentes et couvrent une large palette allant d’une non entrée en matière, à une
volonté 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 recueil
de 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 administrations
nationales, régionales et locales sur la planète.

Voici notre analyse en date du mois de juillet 2005.

7.1 Belgique

Le Conseil des Ministres du 25 juin 2004 a approuvé les directives et recommandations aux services publics
fé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 de
communication lors de l’archivage, de l’échange et de la communication de données électroniques. Pour les
applications 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 et
achè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 tout
logiciel fait sur mesure. Ce logiciel sera fourni en code source et sans droit de licence. Les services publics
fé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 des
standards ouverts et que les applications existantes devront être migrées progressivement vers ceux-ci. La
liste 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érieusement
pris en compte au sein de l’administration fédérale. Quelques services publics ont déjà commencé à migrer
d’un environnement de logiciels propriétaires vers un environnement de logiciels libres. Fedict suivra ces
projets 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-



disponible en ligne, suffisante pour développer une implémentation complète, qui ne doit pas comprendre de
restrictions juridiques (à l’exception de « licences open source ») qui compliquent la diffusion et l’utilisation
et 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 les
notions d’organisation de standardisation indépendante à but non lucratif, avec des procédures de décision
ouvertes et la mise à disposition gratuite et irrévocable des droits de propriété intellectuelle contenus dans
le standard. En revanche, elle précise bien que l’implémentation doit être possible ce qui ne ressort pas
clairement 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 vision
relative 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 en
permet la mise à jour continue.

7.2 Brésil

Le 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 gouvernement
concernant le logiciel libre48 (article 1).

Le ITI intègre le Comité Exécutif du Gouvernement Électronique, lequel coordonne le Comité Technique
d’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ée
que « 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ès
large de développement économique et social, ainsi que de diminution de la fracture numérique. Le 18 juin
2004 Sérgio Amadeu da Silveira, directeur de l’ITI, déclarait : « Nous n’optons pas pour un produit, nous
optons pour un modèle de développement et d’utilisation de logiciel. C’est une décision politique, et j’insiste
sur ce point, fondée sur une raison économique — une réduction du paiement de royalties. Cette décision
augmente 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 gouvernement
impose aux organismes d’état ou aux compagnies privées bénéficiant de financements gouvernementaux
de 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ûteuse
les licences de produits propriétaires ou le risque de piratage qui le mettrait également face à des coûts et
des 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 que

tion fédérale. Il dépend des services publics fédéraux et de programmation dans le cadre des technologies
de 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 dans
les 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.



les versions propriétaires limitées.

7.3 Danemark

Le gouvernement danois (Ministère des sciences et technologies, et de l’innovation) a adopté le 13 juin 2003
une stratégie relative à l’utilisation de logiciels dans le but d’accroître la concurrence du marché du logiciel
et d’augmenter la qualité et la cohérence des produits logiciels déployés dans le secteur public51 . Cette
straté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 son
objectif est de déterminer des standards pour l’échange de données en interne ainsi qu’entre les autorités
gouvernementales, le public et les entreprises. La standardisation est une étape nécessaire vers l’utilisation
et la réutilisation des données sur le long terme en s’assurant de l’absence de blocage (lock-in) dans des
outils 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 les
informaticiens. Le rôle de ces communautés de pratique est de classifier et clarifier les termes et concepts
utilisés lors d’échanges d’informations ainsi que leurs besoins d’interopérabilité en créant des définitions
standard d’objets informationnels. Ces standards sont ensuite proposés à un comité XML qui revoit, accepte
et publie les résultats. Ces résultats forment une base de référence pour le groupe de travail technique qui
est 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 pratique
définissent les concepts, la terminologie, les significations et les associations ainsi que les manières de
travailler avec l’information. D’autre part, ces inputs sont intégrés dans les schémas par les informaticiens
qui, eux, n’ont pas toujours une compréhension complète du domaine ou un ressenti exact de l’importance
des 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.



7.4 États-Unis, Massachusetts

Le gouvernement de l’État du Massachusetts a publié le 13 janvier 2003 deux documents concernant sa
position 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’acquisition
ou de la refonte d’applications informatiques afin d’assurer que les investissements dans les technologies
de l’information soient consacrés à des solutions suffisamment interopérables pour satisfaire aux exigences
mé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 de
maintenance, 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 les
logiciels 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 CIO
Peter 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 Document
Format comme le standard choisi pour les applications bureautiques56 . Depuis le 21 septembre 2005, le
format OpenDocument est l’un des standards de données référencés par leur modèle de référence technique
qui 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 France

L’Agence pour le Développement de l’Administration Électronique58 (ADAE) met à disposition des ministères
et des services un guide de choix et d’usage des licences de logiciels libres pour les administrations. Ce
guide recommande de privilégier l’utilisation de la licence GNU GPL pour les développements en logiciels
libres réalisés par ou pour les administrations. Il préconise également une démarche qui s’appuie sur le
code 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 janvier
2004, 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 et
leur 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/.



à travers ses publications et colloques59 .

Notons également que depuis la rédaction du guide du choix de licences, le CEA, le CNRS et l’INRIA ont
élaboré CeCILL60 , la première licence reprenant les principes de la GNU GPL et qui définit les principes
d’utilisation et de diffusion des logiciels libres en conformité avec le droit français.

A travers l’ADAE, le gouvernement propose de créer et développer une plate-forme de services destinée aux
organismes publics, visant le développement des technologies de l’information et de la communication. L’un
des objectifs est de mettre en place un entrepôt d’informations pour la diffusion de la connaissance relative
notamment aux méthodes, aux chartes et aux guides et d’en assurer la gestion. Il s’agit par ailleurs de pro-
poser un espace de développement collaboratif qui sera également un point d’entrée pour le référencement
des logiciels et des composants réutilisables.

L’un des résultats de cette démarche est AdmiSource61 , une plate-forme collaborative proposée à l’ensemble
des administrations françaises pour leurs développements de logiciels libres. Chacun est le bienvenu pour
utiliser, participer et contribuer à la hauteur de ses intérêts. Ce portail permet de fédérer et partager les
développements réalisés par les administrations françaises en leur offrant un outil de gestion de projet ouvert
et collaboratif.

Un démarche très similaire est proposée par l’ADULLACT62 , une association sans but lucratif, dont l’objectif
est de soutenir et coordonner l’action des administrations et des collectivités territoriales pour promouvoir,
développer, mutualiser et maintenir un patrimoine commun de logiciels libres utiles aux missions de service
public63 .

On peut également citer la loi 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique
(LCEN), qui précise une définition de standard ouvert dans son article 4 : « 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. »

Au cours d’une interview dans l’émission de Stéphane Paoli sur France Inter le 26 mai 2004, l’ancien premier
ministre Jean-Pierre Raffarin a brièvement évoqué l’idée que l’administration française pourrait utiliser des
logiciels libres au lieu d’acheter des logiciels propriétaires. Seul l’aspect économique a été invoqué : M. Raf-
farin veut « faire en sorte que les communications inter-administrations passent par internet et l’utilisation
des logiciels libres. » Il juge ainsi qu’il y aurait plus de 100 millions d’euros à économiser.

7.6 Norvège

Dans son plan stratégique pour le gouvernement électronique eNorway200964 le ministre norvégien de la
modernisation, Morten Andreas Meyer, a annoncé que le secteur public devra utiliser des standards ou-
verts dans ses systèmes informatiques : « Les formats propriétaires ne seront plus acceptables dans les
communications entre les citoyens et le gouvernement. »

Le calendrier suivant est proposé65 :
– D’ici 2006, un ensemble de standards administratifs et de gestion devront être établis pour les échanges
de données et de documents.
– D’ici 2006, tous les services du secteur public devront avoir établi des plans pour l’introduction de
standards ouverts, d’architecture orientée services et de logiciels libres.
– D’ici 2008, tous les échanges de données et de documents du secteur public devront satisfaire les
standards administratifs et de gestion.
59
Réutilisation des logiciels et bouquet du libre, http://www.adae.gouv.fr/spip/rubrique.php3?
id_rubrique=33.
60
Voir le site Web dédié à CeCILL, http://www.cecill.info/.
61
Voir le site Web http://admisource.gouv.fr/.
62
ADULLACT — Association des Développeurs et des Utilisateurs de Logiciels Libres pour les Adminis-
trations et les Collectivités Territoriales, http://adullact.net/.
63
AdmiSource et ADULLACT.net utilisent d’ailleurs le même outil libre GForge http://www.gforge.
org/.
64
Voir http://europa.eu.int/idabc/en/document/4415/194 et http://www.odin.dep.no/
mod/english/bn.html.
65
Voir http://europa.eu.int/idabc/en/document/4403/469.


Standards ouverts et logiciels libres

Standards ouverts et logiciels libres

Recomendados

Recomendados

Más contenido relacionado

Similar a Standards ouverts et logiciels libres

Similar a Standards ouverts et logiciels libres (20)

Más de Genève Lab

Más de Genève Lab (20)

Standards ouverts et logiciels libres