le reste des utilisateurs posent de nombreuses questions sur les forums et les listes de diffusion (*mailing lists*) et les injonctions à lire le fucking *manual* qu'on y trouve traduisent les tensions générées dans la communauté par le sentiment d'abandon. Les utilisateurs de logiciels, mécontents de la façon dont ils sont traités par la maintenance officielle des vendeurs ou des développeurs se tournent massivement vers d'autres sources d'aide et de réconfort... avec plus ou moins de succès. Cette gestion des communities est à mettre en regard de la quatrième pratique décrite par Kelty qui est la coordination de collaborations. Pour qu'un projet libre soit efficace, mettre en place des collaborations dans la communauté d'une façon ou d'une autre est important. On voit bien, par opposition, qu'au logiciel « généréfié » correspond une stratégie sélective dans laquelle la gestion de la communauté consiste à écarter la majorité de celle-ci, et que cette stratégie est source de tensions, particulièrement si la communauté en question est une communauté scientifique, censée, selon ses normes mertoniennes communément admises, reposer sur l'universalité, voire le partage. Même s'il serait naïf d'invoquer l'éthique de Merton pour décrire la communauté scientifique (de même que Kelty préfère décrire des pratiques du libre plutôt que des normes), on ne peut que constater que la gestion de communauté du logiciel « généréfié » implique des tensions dans la communauté scientifique, du à un choc avec les idées d'universalisme et de communalisme, a priori plus compatibles avec la quatrième pratique de coordination de collaborations.

Pollock décrit le logiciel générique comme un blob noir (*black blob*) au lieu d'une boîte noire (*black box*) : une entité amorphe, accessible seulement aux utilisateurs les plus proches et difficile à appréhender pour les utilisateurs les plus éloignés. L'ouverture (*openness*) des logiciels est ambiguë dans le cadre de cette « générification » : dans un premier temps, ouvrir le code source est une stratégie utile pour enrôler des utilisateurs dans une communauté. Puis, quand le logiciel se développe, l'ouverture devient un inconvénient pour le processus, précisément parce qu'il est considéré comme contre-productif que les utilisateurs soient trop au fait de la machinerie du logiciel. Cette idée est encore à mettre en regard de la première pratique du libre de Kelty : partager le code source. Il est bien sûr évident que le partage du code source est l'essence même du libre, mais il est encore intéressant de noter que dans notre cas, la question est
un problème et encore une fois une source de tension. Pour un logiciel scientifique commercial, la tension existe aussi entre la tendance à protéger son code de la concurrence (pour éviter le reverse engineering) et le souhait de la communauté d'accéder à l'intérieur de la boîte noire au nom de la reproductibilité scientifique.

À cet égard, les solutions imaginées par les chimistes computationnels sont multiples, mais l'un d'entre eux, le best-seller en chimie quantique, a développé une idée unique : rendre le code source disponible, mais pas ouvert : une initiative rare d'un logiciel sous licence propriétaire avec code source partagé. Cette approche surprenante a été la source des plus hautes tensions dans la communauté d'autant plus que la licence du logiciel interdit expressément aux utilisateurs de comparer (benchmark) et de rendre publiques les performances du logiciel.

La saga du logiciel en question, de ses licences, de ses procès, depuis les années quatre-vingt jusqu'à aujourd'hui est édifiante. Elle résume les tensions et les controverses à l'intérieur de la communauté entre developpeurs et utilisateurs. D'autres logiciels ont imaginé de nombreuses autres stratégies, de nombreux autres business models. De licences annuelles renouvelables en produits d'appel gratuits mais propriétaires, code source ouvert ou code source fermé, publié ou non, aucune solution ne s'est vraiment imposée comme une norme au sein de la communauté scientifique, révélant la diversité des pratiques et la difficulté à les rendre compatibles entre elles. La troisième pratique décrite par Kelty, l'écriture de licences, prend ici tout son sens. Qu'on soit dans le cadre du libre, ou en train de développer un logiciel « générifié », c'est par l'écriture de la licence que les stratégies se développent (et s'analysent), et la multitude de choix différents dans le domaine de la chimie computationnelle illustre bien les incertitudes stratégiques dans le domaine de création de logiciels en chimie computationnelle, à l'ère du desktop modeling.

## 8. What FM ? Tensions dans la communauté

Ce qui s'est passé avec le logiciel de modélisation moléculaire au cours des années quatre-vingt et quatre-vingt-dix est unique. Le virage du desktop modelling en tant que rupture dans l'activité scientifique a été une
source de tensions chez les chimistes computationnels qui ont été les premiers à recevoir de plein fouet ce tournant. Ce qui est arrivé est caractéristique d'un contexte politique, économique, technologique et scientifique mais aussi une aventure de création de logiciels unique. La communauté (dans sa diversité et ses tensions) a façonné le logiciel, et en retour celui-ci a transformé l'activité scientifique, à l'image de la communauté, dans un contexte de promesse économique puis de crise et en l'absence de normes : les voies explorées par les développeurs reflètent ces tensions.

Les nombreuses solutions (parfois uniques) trouvées par les développeurs de logiciels de calcul de chimie pour survivre dans le monde du desktop modelling ont été conceptualisées grâce à la notion de « génération », amenés d'une part par Shinn (et Lenhard) et de l'autre par Pollock.

Les pratiques caractéristiques des communautés du libre de Kelty ont été comparées aux choix effectués dans la chimie computationnelle. Il est frappant de constater comme les cinq pratiques nécessaires à forger une communauté sont autant de tensions dans le domaine de la chimie computationnelle... une communauté loin du libre.

L'ouverture du code source, tout d'abord, est loin d'être naturelle. Elle est loin de faire l'unanimité dans le monde académique des années quatre-vingt, d'une part aux yeux des administrations universitaires pour lesquelles le « transfert de technologie » est plus important que des valeurs abstraites comme l'universalité de la science, d'autre part aux yeux des développeurs de logiciels commerciaux qui ressentent une faible reconnaissance de la part de la communauté scientifique.

L'idée d'un système ouvert, à cet égard, pour les développeurs de logiciel, est donc vue comme un avantage éventuel au début du développement d'un projet (pour enrôler une communauté d'utilisateurs rapprochés) mais devient vite un défaut quand, au contraire, il faut gérer une communauté d'utilisateurs grandissante, multiple et diversifiée, dans le cadre de la « générification » du logiciel, logiciel vu comme une marchandise.

La communauté (d'utilisateurs, de développeurs) n'est donc pas forcément un endroit où l'on collabore. Le processus de community management des logiciels en voie de « générification » consiste plutôt à diviser les utilisateurs, afin que le logiciel de plus en plus polyvalent soit utilisé par le
plus grand nombre plutôt qu'approprié de manières diverses par diverses
communautés d'utilisateurs.

Il n'y a donc pas non plus de mouvement, ni d'idée globale et partagée
de ce que doit ou devrait être la modélisation moléculaire ou la chimie
computationnelle. Une absence de normes, ou d'imaginaires communs,
couplée à la demande du marché au moment où cette science a pris son
essor ainsi qu'aux perspectives de profits à cette époque, représente les
conditions typiques pour empêcher le succès du logiciel libre dans un mi-
lieu académique.

Références

ENSMENGER, Nathan L., *The Computer Boys Take Over : Computers, Programmers, and the Politics of Technical Expertise*, Cambridge : MIT Press, 2010.

FLICHY, Patrice, « Internet ou la communauté scientifique idéale », dans : *Réseaux* 17.97 (1999), p. 77-120.

FRANCOEUR, Eric et Jérôme SEGAL, « From model kits to interactive computer graphics », dans : *Models : The Third Dimension of Science*, sous la dir. de Soraya de CHADAREVIAN et Nick HOPWOOD, Palo Alto, 2004.

GAMBARDELLA, Alfonso et Bronwyn H. HALL, « Proprietary versus public domain licensing of software and research products », dans : *Research Policy* 35.6 (2006), p. 875-892.

JOERGES, Bernward et Terry SHINN, *Instrumentation Between Science, State and Industry*, Boston : Kluwer Academic Publishers, 2001.

JOHNSON, Ann et Johannes LENHARD, « Toward a new culture of prediction : Computational modeling in the era of desktop computing », dans : *Science Transformed ? Debating Claims of an Epochal Break*, sous la dir. d'Alfred NORDMANN, Hans RADDER et Gregor SCHIE-MANN, Pittsburgh : University of Pittsburgh Press, 2011, p. 189-200.

KELTY, Christopher, *Two bits : the cultural significance of free software*, Durham : Duke University Press, 2008.

MOWERY, D. C. et al., « The growth of patenting and licensing by US universities : an assessment of the effects of the Bayh-Dole act of 1980 », dans : *Research policy* 30.1 (2001), p. 99-119.
POLLOCK, Neil, Robin WILLIAMS et Luciana D'Adderio, « Global Software and Its Provenance : Generification Work in the Production of Organizational Software Packages », dans : *Social Studies of Science* 37.2 (2007), p. 254-280.

RAYMOND, Eric S., *The Cathedral and the Bazaar*, Sebastopol, CA : O'Reilly, 2001, URL : http://www.catb.org/esr/writings/homesteading/.
<figure><img src="image_44.png" /></figure>
# VI

## Témoignages : Libre et institutions
<figure><img src="image_45.png" /></figure>
Un point d'histoire de la stratégie d'Inria sur
l'open source

Gérard GIRAUDON

Comme Monsieur Jourdain qui faisait de la prose sans le savoir, l'IRIA
puis Inria, diffusait du logiciel en code ouvert depuis la fin des an-
nées 1970. Cela a bien sûr été facilité par l'arrivée de l'application FTP sur
l'Internet à Inria au milieu des années 1980 et largement amplifié grâce
à la première connexion directe TCP/IP entre la France et les États-Unis,
réalisée en juillet 1988 entre le centre Inria à Sophia Antipolis et l'uni-
versité du Wisconsin à Madison. En fait, pour être tout à fait exact, il n'y
avait pas de position bien affirmée au niveau de la direction de l'institut et
cette diffusion était globalement laissée à la décision des chercheurs des
équipes qui l'utilisaient comme de nombreux collègues à travers le monde
pour échanger avec leur réseau de pairs, à l'instar de ce que l'on fait avec
des publications<fnref n="1" />. Cette diffusion concernait le logiciel vu comme un ob-
jet de connaissance et de recherche permettant de faire avancer la science
que l'on appelle aujourd'hui la Science du Numérique. La stratégie de
diffusion du logiciel en code ouvert vu comme un objet de transfert tech-
nologique restait à construire<fnref n="2" />.

<footnote n="1">1. On peut citer par exemple l'initiative de Pierre Weiss au début des années 1990 de l'édition d'un CD-Rom des logiciels libres de l'INRIA Rocquencourt.</footnote>

<footnote n="2">2. Il faut insister ici sur la caractéristique unique du logiciel dans l'histoire des sciences et techniques : tout à la fois objet de connaissance transmissible par l'écrit et objet techno-</footnote>
En 1994, sous l'impulsion de son PDG de l'époque, Alain Bensoussan, et de son Directeur scientifique, Gilles Kahn, Inria élabore son premier plan stratégique. On peut y lire quatre principes fondateurs <fnref n="1" /> :

1. La nécessité de l'excellence scientifique au meilleur niveau mondial couplée à une vision affirmée sur le transfert technologique et l'innovation guidée par une forte volonté d'impact.

2. Le constat est que si la domination scientifique passe naturellement par de grands médias de communications scientifiques (conférences, sociétés savantes), elle passe aussi en informatique par une stratégie « *astucieuse* de mise dans le domaine public de logiciels ou de technologies qui s'imposent alors comme des standards de fait. En fait la révolution des systèmes ouverts qui a tant bouleversé l'industrie informatique [...] trouve son origine en grande partie dans cette création de standards de fait par la communauté scientifique américaine. »

3. « La numérisation et le rôle du logiciel deviennent prédominants [...] l'informatique apparaît comme un élément clé de la compétitivité de tous les secteurs économiques, et même de l'évolution de la société [...] La réponse passe par la mise en place de systèmes complexes bien organisés, faciles à utiliser intégrant de nombreuses couches ou briques de bases. »

4. L'importance du transfert par la création d'entreprises innovantes illustrée par la performance de l'industrie du logiciel américain grâce au modèle start-up.

Ces principes allaient structurer l'action future de l'institut jusqu'à nos jours.

C'est ainsi que, dès 1995, l'institut co-fondait avec le MIT la branche européenne du W3C, étant convaincu de la révolution que le Web pouvait apporter si la préservation de son interopérabilité par des standards ouverts était assurée.

Concernant l'*open source*, l'élaboration d'un plan d'action a été plus lente. À la vision première de la diffusion de logiciel *open source* comme

<footnote>logique une fois compilé sur un ordinateur et dont le passage de l'un à l'autre est quasiment
à coût nul.</footnote>

<footnote n="1">1. http://www.inria.fr/institut/strategie/plan-strategique. PS 1994-1998, pp. 3-4-5</footnote>
diffusion de connaissance, restait posé le questionnement sur la manière
dont la diffusion de logiciel libre et ouvert permettait de créer un effet
de levier et un véhicule pour le transfert technologique et la création de
valeur. Le premier document qui traite de l'importance de la diffusion
de logiciel open source<fnref n="1" /> a été diffusé au comité de direction de l'institut
en avril 1995. Il décrit les avantages de ce mode de diffusion au regard
des quatre principes édictés ci-dessus et illustre le propos avec quelques
exemples (projet GNU de la Free Software Fondation, bibliothèque de
traitement d'image Khoros de l'université de New Mexico et son impact
notamment pour la formation, le logiciel Ptolemy de l'université de Ca-
lifornie à Berkeley et son impact vers les partenariats avec des grands
groupes industriels). La démonstration mettait en valeur le cercle ver-
tueux <fnref n="2" /> qui pouvait en découler entre l'impact sur la notoriété scientifique
et technologique, la création de la référence et la création de la demande
issue du marché, l'impact sur la collaboration entre public et privé par le
rôle de facilitateur du logiciel open source. Ainsi le texte proposait de dé-
ployer une stratégie d'action selon la nature du logiciel (langage, environ-
nement, bibliothèque, générique ou spécifique), sa cible (enseignement,
recherche, entreprises), sa qualité et sa facilité d'usage, etc. Le document
concluait sur la nécessité d'une politique affirmée, adossée à l'élaboration
de critères explicites pour faire des choix (open source ou pas) et le be-
soin d'une meilleure mise en œuvre (centralisation de l'information, choix
d'une licence, identification des auteurs, etc.). Ce texte a permis de lan-
cer le débat stratégique au sein de la direction mais sans qu'une politique
affirmée soit arbitrée.

L'année 1996 est l'année du changement de PDG (arrivée de Bernard Larrouturou), la création d'une fonction de Délégué Général au Transfert et la création de la Direction du Développement et des Relations Industrielles. La priorité était de mettre en œuvre la stratégie autour de l'aide à la création d'entreprises innovantes qui était élaborée depuis 1994 sous l'impulsion de Jean-François Abramatic et de Laurent Kott. Cela a abouti à la création d'INRIA-Transfert et des fonds d'amorçage portés par ISourceGestion à partir de 1998.

<footnote n="1">1. Le titre exact était : « Réflexion autour des FTP anonymes pour la diffusion de logiciel » document daté du 3 avril 1995. G. GIRAUDON (archives de l'auteur).</footnote>

<footnote n="2">2. Il est fait référence à la fertilisation croisée de la trilogie Enseignement-Recherche-Industrie chère à Pierre Laffitte, fondateur de la technopole Sophia Antipolis.</footnote>
Concernant l'*open source*, l'année 1998 contient également une date importante. En effet, le 20 mars 1998, à l'occasion de la fête de l'Internet, Inria organise à la Mutualité à Paris une conférence-débat sur le thème « Logiciels libres : impact économique », avec des discours d'ouverture de Bruno Oudet et de Gilles Kahn. On notera pour l'histoire l'intervention de M. Chatelain pour Netscape et de M. Young pour une jeune entreprise encore inconnue du large public, Red Hat. C'est ce jour-là, dans ces locaux, que l'AFUL a pris naissance, association à laquelle participa un Directeur de Recherche Inria bien connu de la communauté du logiciel libre en France, Bernard Lang. 1998 est également l'année de la diffusion au Comité de direction Inria d'une deuxième version du texte de 1995. Si l'élaboration d'une stratégie claire sur l'*open source* tardait à sortir depuis lors, c'est que la question, objet du colloque mentionné ci-dessus, restait totalement ouverte. Si des modèles économiques commençaient à s'élaborer, aucun aux yeux de l'institut ne permettait d'assurer une pérennité des entreprises et des emplois en France, voire en Europe, compte tenu du contexte industriel, de la difficulté à monter une industrie du logiciel en France, conséquence du peu d'appétence des grandes entreprises ou des pouvoirs publics français pour l'innovation venue de France<fnref n="1" />.

Il était clair pour Inria que la clé était dans l'élaboration d'un écosystème « éveillé », dont les composants étaient identifiés :

- communauté de chercheurs et communauté de développeurs ;

- entreprises de l'offre technologique (briques, composants) ;

- entreprises de services aptes à customiser une solution client et à la maintenir et

- surtout les clients finaux et donneurs d'ordres aptes à exploiter les solutions (entreprises, collectivités, directions de l'État).

Le verrou, nous semblait-il, était la création de la confiance ; la confiance de chacun des acteurs de l'écosystème dans l'écosystème lui-même, au-delà de la confiance dans les autres acteurs. Nous allons voir ci-après comment Inria a contribué à lever les obstacles mais dans tous les cas, nous considérions que la création de la confiance se construisait

<footnote n="1">1. Inria avait acquis de l'expérience à travers ses *spin-off* qui se présentaient comme Éditeurs Logiciel, et notamment ses filiales de l'époque comme Simulog, Ilog, Connexité etc.</footnote>
par la prise de conscience de la part de chacun des acteurs que sa contri-
bution à l'écosystème lui-même était un investissement rentable pour lui
mais aussi pour l'écosystème ; ce que nous illustrons ici par l'adjectif
« éveillé ». Cet adjectif signifie que chaque composante de l'écosystème
est consciente qu'elle reçoit de l'écosystème mais qu'elle doit également
y contribuer.

Inria était convaincu que les écosystèmes open source pérennes étaient un formidable changement de paradigme <fnref n="1" />, mais ils ne pouvaient pas être une table ouverte où certains ne font que s'asseoir pour s'y restaurer. Enfin, Inria était convaincu que le succès en matière de transfert et d'emploi irait aux acteurs économiques les plus rapides, ceux aptes à exploiter les nouvelles opportunités et aptes à prendre des risques.

Début 2000 s'engage une nouvelle réflexion pour faire avancer la straté-
gie de l'institut sur le développement et le transfert. Cette réflexion aboutit
en 2001 à un texte fondateur présenté au Conseil d'administration d'Inria
sur le transfert et les axes de mise en œuvre et l'organisation du dévelop-
pement technologique à l'institut à travers des services explicites. La dif-
fusion de logiciels open source est mentionnée comme un axe important
et notamment à travers la création de consortiums. Cela se traduira peu
après par la création du Consortium ObjectWeb 2, la création du Consor-
tium Scilab, la création du Consortium Caml ou encore la forte participa-
tion à des initiatives comme IHE (Integrating the Healthcare Enterprise).

En parallèle, mais en retard par rapport à leurs homologues américaines, les entreprises françaises et européennes à logiciel prépondérant s'intéressent de plus en plus à l'open source, à son développement et aux écosystèmes qu'il permet de créer. C'est ainsi qu'en novembre 2001, est dif-fusé un rapport RNTL sur le logiciel libre 3 et sept ans plus tard le Cigref publie un rapport de synthèse sur l'open source 4.

<footnote n="1">1. Voir Gérard GIRAUDON, « Le logiciel libre et ouvert : révolution ou évolution ? » dans *Interstices*, 2006. URL : http://interstices.info/jcms/c_14658/le-logiciel-libre-et-ouvert-revolution-ou-evolution.</footnote>

<footnote n="2">2. Objectweb a donné naissance en 2006 à OW2.</footnote>

<footnote n="3">3. Le GT du RNTL qui a écrit ce rapport était composé de : Alain Conchon (co-animateur), Jean-Michel Dalle, Gérard Giraudon (co-animateur), Bernard Rougeot, Jean-Paul Smets, Jean-Michel Tanneau (rapport dans les archives de l'auteur).</footnote>

<footnote n="4">4. Voir la synthèse téléchargeable sur la page http://www.cigref.fr/lopен-source-en-entreprise.</footnote>
Comment en est-on arrivé là ?

Comme indiqué précédemment Inria était depuis 1995 membre fondateur du W3C, consortium international qui émettait avec le succès que l'on connaît des recommandations sur les spécifications d'évolution du Web pour en assurer l'operérabilité et l'universalité. S'appuyant sur sa propre expérience Inria a alors considéré que la bonne stratégie était de coupler standard et *open source*. De plus, Inria était convaincu que dans certains domaines où l'operérabilité était une condition première du développement et une « commodité » pour chacun, le logiciel libre était stratégique car le logiciel devenait lui-même le standard<fnref n="1" />. La vision Inria était que les utilisateurs finaux devaient être au cœur de ces consortiums car, outre leur capacité à exprimer suffisamment en amont leurs besoins, ces utilisateurs finaux devaient jouer le rôle clé du « marketing-commercial ». En effet, il était clair que le modèle économique<fnref n="2" /> d'un écosystème devait être viable s'il voulait durer. Un des intérêts financiers du modèle *open source* pour un utilisateur final est qu'il ne « paye » que pour la partie terminale du produit, celle qui correspond à son besoin personnel, à ce titre le modèle financier est extraordinaire puisque l'on peut faire du mesure au prix du prêt-à-porter. Mais si on trouve dans un écosystème *open source* les composantes pour mettre en œuvre la recherche, le développement, la documentation, la spécialisation, on ne trouve personne pour assurer le marketing et le commercial de l'écosystème lui-même. Ainsi, le rôle clé des utilisateurs finaux était celui-là, c'est-à-dire celui de faire savoir leur satisfaction (ou pas) en enclenchant ce que l'on nomme maintenant le marketing viral. Or, force a été de constater que ce n'est pas vraiment ce qui s'est passé, du moins en France. En effet, un certain nombre d'obstacles se dressaient sur le chemin, culturel en premier bien sûr, la notion de symbiose n'étant pas toujours une valeur des utilisateurs finaux, mais aussi de confort (l'acte d'achat ayant valeur de solde de tout compte voire un gage de minimisation des risques vis-à-vis de sa hiérarchie).

<footnote n="1">1. En effet, le logiciel est à la fois la spécification et son implémentation et parce qu'il est ouvert, chacun peut le lire comme une spécification et s'interfacer dans la mise en œuvre.</footnote>

<footnote n="2">2. Par économie, il faut entendre ici l'acceptation générale du mot, c'est-à-dire l'ensemble des conditions économiques et pas seulement celles qui se traduisent par un flux financier. On peut dans ce registre citer les travaux issus de financement RNTL de J. M. DALLE et N. JULLIEN publiés en 2003, « *Libre Software : Turning fads into institutions* ? », dans *Research Policy*, 32/1, pp. 1-11. URL : http://www.marsouin.org/spip.php?article79.</footnote>
Parmi ces obstacles, il y en avait un qui nous semblait pouvoir être levé. Il s'agissait du risque juridique. En effet, même si au sein de nombreuses entreprises, dont certains grands groupes, l'utilisation de l'open source était présente<fnref n="1" /> et même si on trouvait des fervents partisans de la notion d'écosystème symbiotique, la plupart des grandes décisions passaient par un avis sur le risque juridique. Or, au début des années 2000, l'analyse d'Inria était que, d'un point de vue strictement juridique, très peu de licences étaient un vrai contrat entre les parties (aucune mention de droit de référence en cas de litige et celles qui en mentionnaient étaient la plupart nord-américaines). Ce constat était un obstacle d'autant plus important que le logiciel prenait, comme on l'avait prévu au début des années 1990, un rôle clé au sein de l'entreprise voire celui de vrai différenciateur vis-à-vis des concurrents ; le rôle de la propriété intellectuelle concernant les logiciels devenant de plus en plus important. Fort de ce constat et parce que nous étions aussi demandeurs de sécurité juridique pour les logiciels diffusés par nos établissements, un petit groupe composé de scientifiques d'Inria et de juristes du CEA et du CNRS se sont lancés en septembre 2003 dans la rédaction de la famille des licences CeCILL<fnref n="2" />. Ce petit attelage avait pour but de faire converger relativement rapidement sur trois licences en adaptant au droit européen, incarné via ses directives dans le droit français, l'esprit des trois licences les plus utilisées pour la diffusion open source : la GNU GPL, la GNU LGPL et la BSD<fnref n="3" />. Nous en avons également profité pour prendre en compte les dernières tendances de l'informatique. C'est ainsi que la CeCILL fait référence à des brevets possibles, la CeCILL C essaye de clarifier la césure de l'hérédité de la licence notamment pour les bibliothèques et la CeCILL B instaure un devoir de citation. Ce dernier point nous semblait concilier l'intérêt gagnant-gagnant entre un utilisateur qui peut récupérer un logiciel diffusé sous cette licence dans tout ou partie de ses propres produits et l'intérêt de l'auteur de pouvoir être cité à l'instar d'une citation d'une publication<fnref n="4" />.

<footnote n="1">1. Linux ou les serveurs Apache en sont les archétypes.</footnote>

<footnote n="2">2. Pour Cea, Cnrs, Inria Logiciel Libre : http://www.cecill.info.</footnote>

<footnote n="3">3. Un quatrième type de licence avait été prévu initialement (il s'agissait de la CeCILL D pour Data) mais n'a finalement pas vu le jour par manque de temps avant que le groupe ne se disperse ; depuis est sortie la licence de droit français données ouvertes : http://www.data.gouv.fr/Licence-Ouverte-Open-Licence.</footnote>

<footnote n="4">4. L'idée d'un template XML a même été soumise par un industriel qui nous servait de bêta-testeur.</footnote>
Cela devait permettre à des chercheurs de pouvoir montrer, à la manière des indices bibliométriques de leurs publications, l'impact de leur logiciel et ainsi conforter leur dossier de carrière. Cela devait résoudre en partie la tension évoquée au début de l'article entre notoriété (logiciel objet de connaissance) et création de valeur (logiciel objet de transfert) y compris au sein d'un logiciel « fermé » si c'était la meilleure voie pour innover et créer des emplois.

Sur cette lancée, en 2009, Inria a établi un livre blanc intitulé *Stratégie d'Inria sur le logiciel libre*. Par les positions affirmées dans ce texte, l'institut réaffirmait son soutien à la dynamique du logiciel libre, jugé indispensable au développement de la société numérique de la connaissance. Cette prise de position met l'accent sur l'utilisation du logiciel libre comme un outil de transfert. Sont précisées les conditions dans lesquelles le recours au logiciel libre est à même de maximiser l'impact des logiciels développés à l'institut, au-delà du cercle de la recherche publique française et européenne, en inventant un nouvel espace de transfert.

Si naturellement le logiciel libre est un objet de diffusion, son enseignement, sa conception (nouvelle approche de la programmation, développement communautaire) et sa distribution (release, etc.) posent de nouvelles problématiques. Sur l'initiative de l'institut et sous la houlette de Roberto di Cosmo, Inria et les universités Pierre et Marie Curie et Paris-Diderot ont fondé en 2010 l'IRILL (Initiative pour la Recherche et l'Innovation sur le Logiciel Libre). En effet, objet aux dimensions multiples, le logiciel libre nécessite de croiser des approches et des compétences diverses et le Centre IRILL permet de réunir des acteurs de la recherche, de la formation, du transfert et de l'innovation, dans la durée et dans un lieu identifié à Paris.

Ensuite, Inria a pris l'initiative de promouvoir le logiciel libre au travers de manifestations comme fOSSa (Free Open Source Software Academia) et plus récemment le concours « Boost your Code » qui offre à un tout jeune diplômé une année de salaire pour développer son projet personnel *open source*.

Enfin, et dans la ligne directe du logiciel *open source*, une nouvelle dimension se construit autour des problématiques de l'*open data* qui est riche de promesse et où l'interopérabilité aura également un rôle majeur.
Après bientôt deux décennies de réflexion et d'action, et la transformation du monde par la révolution de l'informatique et des sciences du numérique, l'histoire du logiciel libre et ouvert – et maintenant des données ouvertes – ne s'arrête pas car nous sommes toujours convaincus qu'au-delà des clivages idéologiques, la dynamique du logiciel libre et ouvert facilite la création d'un dialogue permanent entre recherche, industrie et société.

## Remerciements

L'auteur tient à remercier P. Moreau, S. Ribas, S. Ubeda et C. Zaetta pour leur conseil et leur relecture.
<figure><img src="image_46.png" /></figure>
# La place du logiciel libre au CNRS

## Témoignage d'un ingénieur en informatique au CNRS depuis 1984

Jean-Luc ARCHIMBAUD

Cet article, rédigé en août 2012, apporte un témoignage sur presque 30 ans de vie professionnelle comme informaticien au Centre National de la Recherche Scientifique (CNRS). Son but est d'aider à comprendre pourquoi aujourd'hui les logiciels libres sont présents ou non dans les laboratoires de recherche et comment ils le sont.

Ingénieur en informatique diplômé de l'INSA de Lyon, j'ai d'abord travaillé comme ingénieur développeur pour la société BULL pendant trois ans. Je suis ensuite entré au CNRS en 1984, comme ingénieur système et réseau, et j'y suis encore avec un profil actuel de responsable de projets. Le CNRS, organisme de recherche public, regroupe plus de 1000 laboratoires, dans toutes les disciplines scientifiques. Ses spécificités en font un lieu où l'on peut avoir une vision sur l'ensemble des pratiques de recherche, dans toutes les sciences.

J'ai travaillé six années durant dans un centre de calcul pour les universités et les laboratoires, le Centre Inter-universitaire de Calcul de Grenoble (CICG), sur le campus de Grenoble, ce qui m'a permis d'avoir un contact direct de service avec des chercheurs et une vision universitaire de la recherche. Puis de 1990 à 2010, j'ai travaillé dans une unité nationale,
l'Unité RÉseaux du CNRS (UREC) <fnref n="1" />, chargée en particulier de la mise en
place des réseaux et de leurs applications dans l'ensemble des laboratoires
du CNRS. Cette mission m'a permis de visiter (et de conseiller dans mes
domaines de compétences) de très nombreux campus et laboratoires, dans
tous les domaines de recherche.

Mes activités et compétences techniques ont évolué dans le temps : dé-
veloppement de logiciel et connectivité des premiers PC, infrastructures
de réseaux informatiques (réseaux locaux, de campus, nationaux), tech-
nologies IP, applications internet, sécurité informatique, grilles de calcul,
référencement de logiciels libres (plate-forme PLUME <fnref n="2" />), qualité, portails
thématiques. J'ai monté et piloté de nombreux projets ou groupes de tra-
vail. Je ne suis pas un développeur logiciel, mais j'ai fait (ou coordonné)
de nombreux tests, référencements, recommandations sur des logiciels, et
ce, pour l'ensemble des laboratoires.

Durant ces années professionnelles, j’ai assisté, parfois participé, à
l’évolution des pratiques informatiques dans les laboratoires de recherche.
Je citerai : l’arrivée des ordinateurs personnels, la mise en place des ré-
seaux (locaux, de campus, nationaux), le déploiement des applications
internet, la problématique de la sécurité, la généralisation du calcul et de
la modélisation dans la recherche… Outre ces aspects techniques, les mé-
thodes de partage des connaissances, la création et la vie de nombreux
groupes d’échanges techniques avec les outils de travail collaboratif ont
constitué un autre volet important de mes activités. Cette évolution de
l’outil informatique et des pratiques dans les laboratoires s’est faite avec
l’utilisation, parfois le développement, de logiciels libres ou non.

Je viens apporter un témoignage sur certains épisodes auxquels j’ai par-
ticipé dans ma vie professionnelle en lien (parfois uniquement de res-
semblance) avec le logiciel libre, à la fois dans son objet (source diffu-
sée...) mais aussi dans ses pratiques (communauté vivante...). J’essaierai
de prendre du recul pour en tirer une leçon, une vision plus globale. Je
me limiterai à ce que j’ai vécu, côtoyé de très près. De nombreux faits
beaucoup plus importants seront donc occultés. C’est ainsi une vision et

<footnote n="1">1. Voir Jean-Luc ARCHIMBAUD, « UREC 1990-2010, acteur majeur dans la mise en place des réseaux informatiques au CNRS », URL : http://hal.archives-ouvertes.fr/docs/00/64/39/33/PDF/UREC.pdf.</footnote>

<footnote n="2">2. https://www.projet-plume.org.</footnote>
une analyse tout à fait personnelles et donc incomplètes et partiales. J'en avertis le lecteur. Il est évident que cela n'engage pas le CNRS.

Ce témoignage est aussi un témoignage du terrain, donc avec un vocabulaire simplifié, celui qu'il faut adopter avec les décideurs pour ne pas les noyer dans les subtilités du monde du libre. Je n'emploierai ainsi que les termes « logiciel libre » ou « le libre » sans indiquer la définition précise.

Quand on lit un témoignage, il est important de savoir qui parle. Chacun possède sa vision en fonction de son vécu et de sa place dans l'histoire. C'est ce qui m'a conduit à décrire mon parcours professionnel en préambule, pour que vous sachiez à qui vous avez affaire.

Néanmoins, mon objectif n'est pas de « raconter mon histoire », ce qui a peu d'intérêt, mais de rapporter certains faits de ces trente dernières années qui peuvent aider à comprendre la place actuelle du logiciel libre dans les laboratoires de recherche. Comme vous le verrez dans certains paragraphes, il est difficile pour un ingénieur comme moi, personnel technique, d'influer sur la stratégie informatique, logiciel libre ou pas, d'une grande maison comme le CNRS. D'abord parce qu'il n'y a pas de stratégie ou alors plusieurs, une par direction, donc pas de lieu où argumenter. Néanmoins, un moyen d'influer est, d'un côté, de montrer que des logiciels libres de qualité existent et qu'ils sont largement utilisés, et d'un autre côté, de montrer que le modèle de développement et de diffusion du libre est performant et peut être un modèle appliqué à l'organisme. Ceci sans dénigrer systématiquement les logiciels commerciaux.

Cet article est une succession de petites histoires dans l'ordre chronologique et se termine par un essai de conclusion personnelle sur la position du libre dans la recherche.

## Quelques faits passés

*Travailler avec un système d'exploitation dont les sources sont disponibles et modifiables (1984-1986)*

À mon arrivée au Centre Inter-universitaire de Calcul de Grenoble (CICG) en 1984, ce dernier était équipé d'une grosse machine fonctionnant avec le système d'exploitation Multics. Sur cet équipement, unique
outil informatique des laboratoires du campus, entre 50 et 100 chercheurs et enseignants étaient connectés en simultané, avec des terminaux non intelligents (le PC n'existait pas). Multics venait du MIT et de nombreux concepteurs de Multics ont travaillé ensuite à la création d'Unix, version plus simple de Multics. Ce système était écrit entièrement en langage PL1 (langage structuré très lisible) et nous disposions de toutes les sources que nous pouvions modifier et ré-utiliser à des fins de développement. Ceci était naturel, tous les systèmes informatiques utilisés dans la recherche étaient ainsi (le logiciel était alors quasiment gratuit).

Lorsqu'il y avait un problème délicat, un ingénieur système allait lire le code source pour en comprendre la raison. On pouvait ainsi étudier « comment ça marche ». Par cette pratique, les connaissances techniques de chacun en étaient augmentées. De plus, adapter le système à une spécificité française (le minitel par exemple) ou à un périphérique non prévu, n'était pas bloquant : on modifiait certains modules du système. Cet environnement était très formateur, il permettait de progresser techniquement et de développer du code rapidement.

Quand on a travaillé ainsi, on comprend tout à fait ce qui a conduit Richard Stallman à se lancer dans la définition du logiciel libre puis dans sa croisade pour son utilisation. Comme il est raconté dans sa biographie <fnref n="1" />, chercheur en informatique à cette époque, il avait accès aux sources. Or, brusquement, il s'est vu interdire cet accès. Pour tous les chercheurs en informatique et plus globalement les ingénieurs en informatique, ce manque de visibilité constitua un frein très important dans le travail, une régresion.

## Participer à un groupe d'échanges techniques (1984-1986)

Multics était très peu répandu, une dizaine d'exemplaires en France, principalement pour la recherche publique et un peu privée. Le support technique du constructeur était ainsi *a minima*. Il fallait donc « se débrouiller seul ». Pas tout à fait, car les sites français qui possédaient un système Mutics s'étaient organisés pour créer des groupes d'échanges techniques. Ils se réunissaient régulièrement pour exposer les problèmes

<footnote n="1">1. Sam WILLIAMS, Richard STALLMAN et Christophe MASUTTI, *Richard Stallman et la révolution du logiciel libre. Une biographie autorisée*, Paris : Eyrolles, 2010.</footnote>
de certains, échanger des pratiques et, souvent, des petits développements logiciel. Même sans Internet et sans les outils de communication et de travail collaboratif actuels, les échanges étaient très fructueux pour avancer ensemble, s'entraider. Il me semble que les rencontres toujours en présen- tiel, où l'on se côtoyait et dînait ensemble, permettaient de vraiment se connaître, ce qui évitait les échanges par courriel parfois durs dans des listes électroniques, qui peuvent souvent saboter l'ambiance d'un groupe de travail. Personnellement, c'était toujours avec plaisir que je participais à ces rencontres, même si les déplacements en train étaient longs.

Ces pratiques de groupes d'échanges n'étaient pas spécifiques à Multics, les autres systèmes ou constructeurs comme DEC, de mémoire, avaient leur équivalent. Ainsi, les échanges et le partage techniques, pratiques à la base du développement du logiciel libre et facilitées par l'utilisation de ces logiciels, ont existé dans la recherche dans le domaine informatique (ainsi que dans d'autres domaines), avant l'invention du Libre.

## Distribuer gratuitement un logiciel sans licence, ni Internet (1986)

Multics avait un outil de messagerie local, identique au *mail* d'Unix d'ailleurs. Or, dans le monde de la recherche, beaucoup de sites étaient équipés de matériel IBM. IBM avait financé la mise en place d'un réseau académique BITNET aux États-Unis, basé sur des protocoles de communication propriétaires, et son équivalent européen, EARN, supporté aussi par le ministère de la Recherche. Il rendait de grands services en particulier pour la messagerie internationale entre les chercheurs. Les sites Multics en étaient exclus. C'est pourquoi je m'étais lancé dans le développement d'une passerelle entre la messagerie locale Multics et EARN. Grâce à l'accès aux sources en PL1, le travail avait été assez rapide et le résultat opérationnel.

Les autres sites Multics m'avaient demandé le code. Pour le diffuser, nous avions réalisé des copies du logiciel sur des bandes magnétiques et j'avais organisé une journée de présentation à Grenoble avec distribution de ces supports. Ainsi, j'avais fait une distribution d'un logiciel gratuitement sans licence et sans Internet. Certains sites avaient ensuite découvert des bugs et m'avaient proposé des corrections... Ceci pour montrer que l'objet *logiciel libre* existait avant la popularisation du terme, ainsi que
les pratiques de diffusion et d'amélioration des logiciels libres dans les laboratoires de recherche. Malheureusement, peu de temps après, l'arrêt du développement de Multics était annoncé, ce qui a limité la diffusion de mon développement à la France. Autrement, j'aurais peut-être fait de beaux voyages...

## La simplicité et l'environnement international, deux critères importants dans les choix de solutions techniques (1990-1991)

Arrivé à l'Unité REseaux du CNRS, en 1990 j'ai participé activement à la définition puis à la mise en place du réseau informatique national de la recherche et de l'enseignement supérieur RENATER <fnref n="1" />, piloté par le ministère de la Recherche et de l'enseignement supérieur. Au départ de la réflexion s'est posée la question du choix des protocoles de communication qui devaient circuler sur ce réseau. À l'époque, il y avait entre les sites de recherche des liaisons avec des protocoles de communication divers : X25 (de France Télécom), DECNET (de DEC), SNA (d'IBM), ISO (très fortement poussé par la communauté européenne) et quelques IP (très fortement poussé par les universités américaines). Aujourd'hui, nous ne connaissions qu'une seule langue pour les communications : IP, alias Internet. Cela n'a pas toujours été le cas, on parlait alors plusieurs langues. Pour la définition de RENATER, il avait été créé autant de groupes de travail que de protocoles de communication. L'objectif était de pouvoir utiliser tous ces protocoles sur un même réseau. Bien qu'étant jeune et sans vraiment d'expérience, j'avais été désigné comme animateur du groupe technique IP chargé de définir le modèle d'architecture (interconnexion des sites : équipements, routage...). Les autres groupes étaient pilotés par des seniors, avec des responsabilités importantes dans certains organismes de recherche. Je pense que le ministère de la Recherche et de l'enseignement supérieur et France Télécom ne croyaient pas du tout en cette langue inconnue en France d'où ma désignation.

À l'arrivée, RENATER n'a utilisé que le protocole IP. Pourquoi ? Le travail du groupe technique IP a été de très bonne qualité mais ce n'est pas ce qui a conduit à la décision de ce choix. Il me semble que deux éléments

<footnote n="1">1. http://www.renater.fr.</footnote>
importants ont tranché. Le premier est que IP est simple, donc il fonctionne avec tous les débits de ligne, avec des équipements peu coûteux et avec des logiciels légers. Ce sont les éléments du succès d'Internet. Le second point est que IP s'est répandu rapidement dans le monde. Et, même dans nos villages gaulois, on ne peut pas ignorer le poids du plus grand nombre, du contexte international, dirait-on actuellement. Quand un standard, un logiciel s'imposent mondialement, il est difficile de prendre une autre solution.

Mais quel rapport avec le logiciel libre ? Il existe une similitude sur le fond.

Pour que les logiciels libres se répandent, il faut qu'ils soient simples et légers, avec des fonctions de base : *keep it simple*. C'est l'efficacité du pragmatisme anglo-saxon face aux constructions intellectuelles grandioses de notre vieille France. Et il me semble que dans le libre, les outils légers et très ciblés ont beaucoup de succès.

La transcription du second point est qu'on ne peut pas lutter contre Microsoft Office. De même que IP est devenu la langue naturelle du réseau, le format .doc est le format le plus répandu dans le monde de la bureautique. On ne peut l'ignorer. Il aurait été suicidaire au niveau du CNRS de vouloir imposer OpenOffice comme première étape de la promotion du logiciel libre, ce que j'aurais pu néanmoins proposer plusieurs années après. Microsoft Office est trop répandu, au CNRS comme partout dans le monde. J'utilise personnellement LibreOffice et je recommande de l'utiliser, mais je n'ai jamais recommandé de basculer systématiquement tous les postes personnels des laboratoires sous cette bureautique libre en supprimant Microsoft Office. Le positionnement des Directions des Systèmes d'Information (DSI) centrales (voir un paragraphe plus loin) intervient aussi dans cette position pragmatique. Dans la promotion du logiciel libre, certains pensaient qu'il fallait commencer par là : le poste utilisateur sous Linux pour tous. Je ne sais pas ce qu'il en est aujourd'hui. Je pensais (et je pense toujours) le contraire, dans mon environnement professionnel.
## Le Libre, un des éléments clés du succès de l'Internet et de ses applications (1992-2000)

À partir de 1992, et pendant de nombreuses années, l'objectif principal de l'UREC fut le déploiement des applications internet dans les laboratoires et les campus universitaires. Cela avec très peu de moyens humains. Un important travail de compilation, de tests puis de diffusion d'informations fut effectué. Nous avons organisé un site Web qui a été longtemps la référence pour IP et ses applications dans le monde académique, jusqu'à 500 heures de formations ciblées (courtes ou généralistes), des conférences, des groupes de travail pour tous les administrateurs systèmes et réseaux de laboratoires. Nous avons également formé des formateurs en interne pour qu'ils puissent intervenir à leur tour. Sans modestie, ceci fut très efficace.

Ainsi, la recherche et l'enseignement supérieur ont été longtemps en avance dans le domaine de l'utilisation d'Internet (ce n'est plus le cas actuellement). Je suis moi-même très souvent intervenu dans des conférences pour les informaticiens ou décideurs de sociétés privées, parfois dans des comités stratégiques de grands groupes industriels pour expliquer pour quoi on utilisait Internet et comment. Je me souviens du cri du cœur d'un DSI d'un grand groupe disant : « Je ne comprends pas pourquoi nous dépensons autant d'argent pour notre messagerie électronique alors que vous faites tout avec des logiciels gratuits. »

Effectivement, cela nous paraissait naturel, mais tout a été basé sur du logiciel libre qu'on a pu étudier, tester, utiliser sans problème pour les formations, rediffuser dans les laboratoires... Toute cette mise en place des applications internet s'est effectuée sans aucun investissement en achat de licence logicielle ! Outre l'aspect financier, la liberté offerte par le libre a permis cette efficacité de diffusion avec très peu de moyens humains.

Ainsi, il est évident que tous les logiciels libres ont contribué de manière fondamentale au succès d'Internet, et pas uniquement dans la recherche.
## Regrouper les personnes qui savent et qui pratiquent pour être efficace dans le domaine de la sécurité informatique (1995-2006)

Parallèlement à mon travail sur le réseau et ses applications, de 1990 à 2006, j'ai été chargé de mission Sécurité Informatique à temps partiel auprès du fonctionnaire de Sécurité défense (FSD) du CNRS. Les premières années, j'étais le seul référent technique national sur la sécurité informatique au CNRS, un peu l'équivalent d'un Responsable de la Sécurité des Systèmes d'Information (RSSI). Le terme n'existait pas à l'époque, ni le poste au CNRS (le premier poste de RSSI n'a été créé au CNRS qu'en 2011).

Un travail urgent s'est rapidement imposé : verrouiller les accès internet. Pour les 1 300 laboratoires du CNRS de l'époque, tous connectés à l'Internet, il n'y avait aucune organisation pour la sécurité informatique, dans un environnement peu réceptif à ces problèmes et, pour la majorité, réfractaire aux règlements et aux contraintes. Ces laboratoires CNRS (on retrouvait la même situation dans les universités) avaient été connectés à Internet (plus concrètement à RENATER) lorsqu'il était encore uniquement académique et que quasiment tous les sites étaient des universités ou des laboratoires de recherche. On était membre de la même communauté de recherche, on se connaissait et on se faisait confiance. Il n'y avait donc aucun filtrage, aucune limitation d'accès à l'entrée des laboratoires et des campus, sans compter de très nombreux serveurs ou applications sans suivi des mises à jour logicielles, avec des mots de passe triviaux. Avec l'explosion d'Internet et son ouverture, il a fallu rapidement convaincre puis aider tous les laboratoires à mettre en place une architecture réseau sécurisée, des limitations d'accès avec une bonne configuration et un suivi de tous les serveurs. Il fallait également convaincre les utilisateurs et les informaticiens, habitués à une liberté complète, de se préoccuper de sécurité, et d'agir pour limiter cette liberté, cela rapidement. Ce n'était pas gagné.

Avec très peu de moyens, l'UREC a monté un réseau de correspondants laboratoire de sécurité informatique avec un niveau régional de coordination. Ce réseau a fonctionné jusqu'en 2006 et a compté jusqu'à 720 correspondants. Grâce à lui, nous avons pu réagir rapidement en cas d'intrusion, diffuser des recommandations, des avis de sécurité et des outils libres de
protection ou de détection et surtout sensibiliser et former. Un volume très
conséquent de formations nationales, régionales... avec des formations de
formateurs internes, a été maintenu pendant près de 10 ans.

Nous sommes alors arrivés au début des années 2000 à une situation
saine concernant les risques Internet. La sécurité n’était pas sans faille (ce
qui n’existe pas) mais satisfaisante du point de vue architecture, filtrage,
administration des serveurs.

Outre l'utilisation de logiciels libres pour la protection ou la détection,
un point important dans cette organisation fut la décision selon laquelle les
correspondants sécurité seraient des administrateurs systèmes et réseaux
dans les laboratoires, des personnes de terrain, proches des utilisateurs. Ils
pouvaient donc les convaincre et changer leurs habitudes sans les heurter
avec une attitude trop autoritaire. De plus, ils comprenaient les aspects
techniques qu'il fallait mettre en place et ils pouvaient le faire.

Ce réseau était loin de faire l'unanimité à la direction du CNRS car il ne
s'appuyait pas sur la hiérarchie organisationnelle de l'organisme : directeurs de laboratoire, délégations régionales, services centraux de l'organisation... Néanmoins il a prouvé son efficacité. Depuis 2006, il a été remplacé par une organisation beaucoup plus formelle qui suit l'organisation administrative du CNRS, avec des désignations officielles... donc lourde. Celle-ci s'est focalisée sur la rédaction de politiques de sécurité plus que sur les aspects architecture et protection opérationnelle. Mais les éléments techniques étant en place, il n'y avait plus urgence.

Une fois de plus : quel rapport avec les logiciels libres ? Outre l'utilisation d'outils libres de sécurité, la communauté des correspondants sécurité avait toutes les caractéristiques d'une communauté de développeurs : des personnes motivées (volontaires), compétentes techniquement et utilisatrices sur le terrain. On retrouve là les caractéristiques des contributeurs dans le développement des logiciels libres. Comme pour l'organisation sécurité, ce sont des éléments déterminants pour le succès.
Suite à l'élaboration d'une stratégie CNRS de diffusion des logiciels développés, quelques points faibles des logiciels conçus dans les laboratoires (2004-2006)

J'aborde ici une spécificité des laboratoires de recherche dans le développement de logiciels.

Autour de 2005, j'étais directeur de l'UREC et donc un membre actif du Comité d'Orientation des Moyens Informatiques (COMI) du CNRS. Ce comité était chargé d'élaborer et de mettre en œuvre la politique de l'informatique scientifique au CNRS en finançant des projets structurants. Au sein de ce COMI nous avions fait le constat que de très nombreux logiciels, souvent techniquement pointus et innovants, étaient conçus dans le cadre de recherches dans les laboratoires. Certains d'entre eux ont une valeur importante car ils mettent en œuvre des résultats de recherche récents, des algorithmes novateurs, ils résolvent les problèmes techniques de demain et n'ont pas d'équivalent commercial. Mais souvent confiés à des thésards, personnel temporaire et dont le métier n'est pas le développement de logiciels très (trop) rapidement écrits pour résoudre un problème scientifique précis, dans l'urgence d'un projet, d'un contrat, ils sont impossibles à diffuser, même libres en bêta. Nous avions décidé de commencer par financer la « finalisation » de certains logiciels de laboratoire après un petit appel à projets. Ce fut un succès malgré un budget modeste. Ensuite, nous avions proposé la création d'une unité (équivalent d'un service) spécifique pour le travail d'aide au développement, de finalisation et de diffusion de certains logiciels au CNRS. L'action s'est arrêtée là, car début 2006, la direction du CNRS a changé et le COMI a été supprimé sans être remplacé par un équivalent.

À travers cette expérience, on peut lister les points faibles qui rendent très difficile la diffusion des logiciels de laboratoire même s'ils sont innovants et opérationnels :

- Il est très difficile de choisir ce qu'il faut diffuser, ce qui a une valeur. En effet, les développements sont très nombreux, donc on ne peut en finaliser (c'est-à-dire « rendre propre ») et en diffuser qu'une très faible partie. De plus, ils touchent des domaines scientifiques très divers et pointus. Il faut des compétences scientifiques spécifiques dans chaque science pour évaluer leur pertinence. Il faut également juger
de la qualité du code. Comment trier ce qui va être intéressant, ce qui est bien développé ? Qui va faire ce tri ? Dans le projet COMI, nous ne nous étions pas encore posé la question sachant que la solution ne serait pas facile à trouver.

- Les développements sont très souvent de mauvaise qualité. Comme je l'ai déjà dit, ce sont souvent des thésards scientifiques et non des informaticiens qui les développent sans méthodologie ni conseil et dans l'urgence. Ils ne peuvent pas être bien documentés, structurés... De plus, ces personnes sont de passage et laissent leur développement en l'état à leur départ sans former quiconque pour les reprendre.

- L'ergonomie et l'interface utilisateur d'un logiciel de recherche sont loin d'être une priorité et sont souvent minimalistes. Or ces aspects sont très importants dans l'adoption d'un logiciel.

- Ce n'est pas le rôle d'un chercheur de faire du développement logiciel (sauf si c'est un chercheur en informatique). Cela n'entre pas dans les éléments qui évaluent son travail et assurent des promotions. Donc ce n'est pas prioritaire.

- Un laboratoire de recherche n'est pas organisé pour diffuser du logiciel et en assurer le support. Ce n'est pas non plus sa mission. Et le transfert de ces tâches à une société commerciale est souvent délicat car les logiciels sont très spécifiques, n'intéressent que des clients très ciblés et les sociétés informatiques classiques sont mal adaptées.

Donc, même si le CNRS, organisme public national, a un fonds de logiciels très intéressant, la mise en pratique de leur diffusion est loin d'être simple, malgré la mission nationale et d'utilité publique qui lui permettrait de diffuser en libre ce qui est développé dans ses laboratoires.

## La politique gouvernementale, élément déterminant dans l'utilisation ou non du logiciel libre dans la fonction publique (2006)

Mi-2006, nous avons lancé le projet national PLUME sur les logiciels à grande majorité libres, dont le porteur est le CNRS. Le point suivant décrit le projet. Ici, je voudrais mettre en exergue un élément fondamental pour le déploiement du logiciel libre dans les administrations et les organismes publics.
Au démarrage de PLUME, il existait une structure nationale, l'Agence pour le Développement de l'Administration Électronique (ADAE) avec un volet promotion du logiciel libre dans les administrations. Je ne me souviens plus des missions exactes qu'avait cette agence ni de ses réalisations. Mais en 2006, nous leur avions présenté le projet PLUME. Ils avaient été très intéressés et nous avaient encouragés à le lancer en nous donnant des conseils et des contacts très précieux. Ce soutien avait été important pour nous car c'était une recommandation officielle d'une agence gouvernementale. La direction du CNRS avait immédiatement accepté le projet.

Mais l'ADAE a rapidement disparu ainsi que la promotion du logiciel libre dans les administrations. Cela a considérablement ralenti le projet. Sans ce soutien, il fallait régulièrement convaincre les directions du CNRS, ainsi que d'autres décideurs, de son intérêt. Nous y gagnâmes un budget et des ressources minimalistes. PLUME n'allait pas dans le sens de la politique gouvernementale concernant le logiciel.

Dans les organismes publics et les administrations, un message fort du gouvernement vers le logiciel libre est obligatoire pour vraiment faire adopter le libre, ce qui n'a pas été le cas au cours de ces dernières années, jusqu'en 2012 (depuis, l'orientation gouvernementale semble avoir changé). Le CNRS est un organisme public sous tutelle d'un ministère et en conséquence il n'a pas d'engagement vers le libre. De plus, à cause de la structure des laboratoires qui sont pour la plupart mixtes – CNRS-universités et d'autres entités –, le CNRS ne peut pas seul, imposer un choix technique comme le libre pour le logiciel. Il faut que la décision soit prise au moins au niveau de tous les organismes de recherche et des universités.

## Quelques éléments intéressants révélés par la mise en place de la plate-forme PLUME (2006-2012)

Le projet PLUME « Promouvoir les Logiciels Utiles Maîtrisés et Économiques dans l'enseignement supérieur et la recherche » a consisté à mettre en place une plate-forme Web contenant des descriptifs de logiciels utilisés ou développés dans les laboratoires et les universités, ainsi que des descriptions de ressources (cours, sites Web, services...) liées aux
logiciels. Ces fiches sont rédigées par des contributeurs utilisateurs ou
développeurs de logiciel dans l'enseignement supérieur et la recherche.
L'ensemble est indexé par des mots-clés avec une mise à jour régulière.
Le but est de proposer un catalogue à jour de logiciels, à 95 % libres, uti-
lisés en production dans la communauté. Ils sont donc installables « sans
problème ». Le catalogue recense aussi des logiciels développés par cette
communauté pour les faire connaître (une fonction de valorisation au sens
large). Fin août 2012, ce serveur propose plus de 1 100 fiches descrip-
tives, avec près de 850 contributeurs et le nombre de nouvelles fiches est
d'environ 4 à 5 par mois.

J'ai été le responsable de ce projet et le rédacteur en chef (je relisais
tout ce qui était publié) de la plate-forme jusqu'en avril 2012. C'était un
bon poste d'observation. Outre les éléments décrits ci-dessus et qui sont
ré-apparus avec PLUME (pas d'appui officiel du CNRS au logiciel libre,
difficulté de la diffusion en libre de logiciels de laboratoires...), j'ai essayé
ci-dessous de lister quelques observations qui me paraissent intéressantes,
un peu en vrac :

- PLUME n'est pas une promotion des logiciels libres mais des logi-
ciels utiles, maîtrisés et économiques comme le dit l'acronyme. En ef-
fet, le CNRS n'étant pas engagé dans une démarche vers le libre, nous
n'avons pas affiché le terme libre dans le nom du projet. Je ne le re-
grette pas. Il est « naturel » qu'un organisme mette en place une plate-
forme pour présenter les logiciels utiles aux laboratoires, que ces der-
niers maîtrisent (c'est-à-dire que des personnes de la communauté
connaissent bien et dont le source est disponible) et qui sont econo-
miques (pour diminuer les dépenses). Personne ne peut remettre en
cause ces objectifs et on pourrait dire que tout organisme / adminis-
tration / entreprise devrait les afficher. Ces buts seraient certainement
mieux acceptés que ceux qui se focalisent sur l'étiquette libre. C'est
une attitude pragmatique, responsable et non doctrinale. Le succès
de cette plate-forme nous a confortés dans ce sens : nous avons fait
le bon cadrage. La plate-forme contient ainsi quelques descriptions
de logiciels non libres, de shareware..., mais en fait très peu. Dans
l'organisation de PLUME, pour faire un tri des logiciels à présenter,
il est convenu que lorsqu'un contributeur propose de décrire un logi-
ciel non libre, on regarde s'il existe un produit libre similaire et de
bonne qualité : si ce n'est pas le cas, on accepte la proposition. Sinon, on regarde de plus près et on discute avec le contributeur pour savoir pourquoi il utilise le logiciel non libre... Et nous ne nous sommes jamais fâchés avec un contributeur.

- Il y a beaucoup de compétences techniques sur les logiciels dans les laboratoires et les universités. Le nombre de contributions dans PLUME est révélateur : il y a des gens qui connaissent les logiciels dans la communauté et dans des domaines très variés. Dans ce contexte privilégié, il faut tout faire pour mutualiser ces compétences. C'est là-dessus qu'est basé PLUME, sur l'agrégation de ces compétences variées qui fait l'intérêt de la plate-forme.

- Dans un projet coopératif, il est nécessaire que les personnes qui participent en retirent quelque chose. Sur PLUME, le fait que chaque fiche soit signée permet au contributeur d'être connu, donc reconnu par ses pairs. De plus, des personnes peuvent le contacter pour travailler avec lui dans le cadre de développements logiciels, de projets, cela peut influer dans son dossier de carrière, il peut être invité à des conférences pour présenter le logiciel qu'il a décrit... Et c'est ce qui se passe !

- Dans les choix de logiciel, il faut faire confiance aux personnes du métier. Au départ de PLUME, une tendance de l'équipe technique a été de juger elle-même de la qualité des logiciels, car en tant qu'informaticiens de métier, nous savions ! Mais nous n'étions pas utilisateurs. Nous avons vite abandonné. Ce principe de jugement était une erreur. Il faut faire confiance au choix des personnes du métier qui utilisent un logiciel dans leur travail quotidien, d'autant plus si elles sont prêtes à rédiger et à signer un document descriptif du logiciel, ce qui est un engagement public de leur part.

- Un logiciel a souvent des utilisations par des métiers, des domaines scientifiques différents. En effet, il est régulièrement apparu qu'un logiciel utilisé en physique était aussi utilisé en sciences humaines mais avec une pratique et une finalité différentes. Cela a surpris les membres de l'équipe PLUME mais a augmenté leurs connaissances en voyant comment d'autres utilisent différemment le même logiciel qu'eux. Il ne faut pas trop cloisonner le domaine des logiciels.
- Le logiciel n'est pas un objet simple. De nombreuses fiches PLUME en décrivent les licences, les droits d'auteurs, patrimoniaux.... Car il y a un besoin d'information et d'explications. Le logiciel n'est pas une entité simple et tout chercheur ou responsable de laboratoire qui veut le diffuser doit se poser de nombreuses questions juridiques devant lesquelles il est incompétent et souvent peu intéressé par ce sujet. Ce sont autant de freins à la diffusion. Ils se demandent : est-ce que tout cela en vaut la peine ? Surtout lorsque ce n'est pas pris en compte dans l'évaluation de leur travail.

- En présentant dans PLUME les développements des laboratoires, on a travaillé très régulièrement avec les services de valorisation du CNRS. Pour ces services, le critère de réussite et d'efficacité est basé sur la quantité d'argent rentrée dans les caisses du CNRS. Il est ainsi très difficile de faire comprendre qu'un laboratoire qui distribue un logiciel gratuitement et pour une utilisation internationale acquiert une grande image de marque et donc apporte de la valorisation. Cette image permet au laboratoire d'avoir des coopérations-contrats industriels, car sa réussite logicielle inspire confiance. De plus, j'ai souvent essayé de démontrer à ces services qu'un laboratoire pouvait gagner beaucoup plus d'argent en donnant des formations sur un logiciel libre qu'il a conçu, en faisant quelques développements spécifiques autour... qu'en essayant de vendre quelques licences. Le modèle économique du libre n'est pas compris et sa mise en œuvre n'est pas intégrée dans le catalogue des solutions de valorisation de la recherche.

- L'anonymat des auteurs Wikipédia, la possibilité de modifier les articles de cette encyclopédie et d'en faire commerce semblent être devenus le modèle universel pour la diffusion d'article. *A contrario*, les fiches PLUME sont signées avec le nom du laboratoire ou de l'université de l'auteur, et leur licence Creative Commons est BY NC ND<fnref n="1" />. C'est un choix délibéré. Dans une fiche PLUME, une personne décrit un logiciel qu'elle utilise dans son travail, donne son avis, indique les problèmes qu'elle rencontre, le critique. Si la fiche n'était pas signée mais anonyme, si on ne connaissait pas l'environnement de travail de cette personne, ces informations auraient peu de valeur. De même,

<footnote n="1">1. C'est-à-dire l'obligation d'indiquer l'auteur, pas d'utilisation commerciale et pas de modification.</footnote>
une fiche est un tout, avec une partie fonctionnalités, une partie utilisation, une partie critique, etc. Si elle pouvait être librement modifiée, les critiques seraient rapidement effacées par les promoteurs du logiciel, et si elle était découpée, le résultat serait de piètre valeur. D'où le choix de la clause ND (pas de modification). Quant à la clause NC (pas d'utilisation commerciale), c'est un engagement vis-à-vis des contributeurs. PLUME ne veut pas qu'un contributeur découvre son travail sur un site commercial avec son nom encadré par un ensemble de bandeaux publicitaires.

- PLUME est un producteur d'information. En effet, chaque fiche est une rédaction personnelle, et non un copier-coller d'une documentation ou de pages Web de Wikipedia ou d'ailleurs. On veille à cette ligne éditoriale lors des relectures. D'autres sites font uniquement de l'agrégation d'informations existantes. Ce sont souvent les plus visibles et ils sont cités comme autant de modèles. Pour notre vie de citoyen du monde, il est important qu'il y ait des sites de production d'information et de création. Dans le cas contraire, on retrouve les mêmes informations partout. Actuellement, par exemple, on assiste à la reproduction sans fin des mêmes dépêches d'actualités dans tous les médias d'information : quelle tristesse et quel danger pour la diversité et la liberté !

- PLUME est-il utile et a-t-il une influence sur l'utilisation des logiciels libres dans les laboratoires ? Il est difficile d'apporter une réponse ferme à base d'éléments chiffrés indiscutables. Néanmoins, le nombre d'accès n'a cessé d'augmenter depuis le début du projet et les contributions continuent. Un autre fait récent est venu concrétiser un des objectifs de PLUME. Au niveau du ministère de l'enseignement supérieur et de la recherche, un groupe d'experts négocie des tarifs de licences d'utilisation auprès des distributeurs de tous types de logiciels utilisés dans les universités et les laboratoires de recherche. Début 2012, ce groupe a contacté PLUME pour qu'un de ses membres participe à leur travail (afin d'apporter une connaissance de l'existant en libre). Sur leur site Web, ce groupe a décidé qu'à côté des licences commerciales, il y aurait des pointeurs vers les fiches PLUME décrivant les logiciels libres équivalents. C'est un objectif de PLUME : indiquer aux laboratoires les logiciels libres qu'ils peuvent utiliser à
la place des logiciels commerciaux et leur donner toutes les informations pour leur permettre de choisir. D'après ces éléments, on peut penser que PLUME a un effet positif sur l'utilisation et le développement de logiciels libres dans la recherche.

## Le prix et l'accès aux documents qui décrivent les standards (2012)

Pour changer de domaine et être plus léger, en 2011-2012, j'ai été chargé de mission qualité (au sens large) à temps partiel dans un gros laboratoire. Ce domaine est très intéressant si on sait prendre du recul. J'ai fait commander un document qui décrit la norme ISO 9001, c'est-à-dire 30 à 40 pages dont la moitié en références, non relié. Coût : 78 €. La documenta-liste était stupéfaite et moi aussi. Par comparaison, les RFC (*Requests for Comments* – demande de commentaires), qui sont les documents qui dé-crivent les standards Internet, sont des documents gratuits, disponibles en ligne (j'en ai lu attentivement certains pour comprendre et faire des cours). En sachant cela, on comprend mieux ce qui a fait le succès d'Internet : les standards et autres documents de référence sont publics et gratuits.

## La DSI des organismes de recherche est souvent un frein au Libre

Pour terminer, signalons une caractéristique de l'immense majorité des Directions des Systèmes d'Information de toutes les administrations et en-terprises. Au CNRS, une DSI a en charge toute l'informatique concernant la gestion administrative, financière et les ressources humaines. Comme dans la plupart des cas, ses choix techniques sont Oracle, SAP, Micro-soft. Les laboratoires utilisent obligatoirement certains logiciels de gestion fournis par cette DSI. Souvent, ils ne tournent que sous Windows et imposent Internet Explorer comme unique navigateur. Donc, chaque laboratoire doit avoir au moins un équipement Windows. Cela ne facilite pas le passage aux logiciels libres.

## Conlusion personnelle

Les faits racontés ci-dessus sont extraits de mon parcours professionnel. Ils sont donc divers, disparates et partiaux. Mais ils ont été choisis
comme des coups de projecteurs sur l'histoire et sur des spécificités de l'environnement recherche, en lien avec le logiciel libre. Chaque fait essaie de donner un éclairage différent, d'apporter une idée différente. Ces petites histoires peuvent aider à comprendre pourquoi les laboratoires de recherche utilisent partiellement les logiciels libres et diffusent très modérément leur production logicielle. Les faits sont multiples car la réponse est un ensemble de raisons diverses. Il n'y a donc pas vraiment de conclusion à cet article.

Néanmoins, un point important n'a pas été abordé : par ses propriétés, le logiciel libre est vraiment très bien adapté à la recherche publique et à la démarche scientifique. En effet, une des missions fondamentales du CNRS est la diffusion des connaissances. Si on l'applique aux logiciels développés dans un laboratoire, cela impose de les diffuser en libre (avec le source...). Ensuite, concernant la démarche scientifique, il faut pouvoir vérifier toutes les expériences de manière à les reproduire. Pour l'outil informatique, cela impose d'utiliser uniquement des logiciels dont le source est accessible (pour vérifier ce qu'ils font réellement) et qui peuvent être ré-utilisés (et éventuellement adaptés) autant de fois qu'on veut pour reproduire l'expérience.

Dans les laboratoires de recherche publique, on ne devrait produire et utiliser que des logiciels libres.
<figure><img src="image_47.png" /></figure>
Annexe
<figure><img src="image_48.png" /></figure>
## Liste des auteurs

**Adrienne ALIX** Directrice des programmes de Wikimédia France (Paris), s'occupant notamment de définir, coordonner et suivre les différents programmes de l'association : soutien et valorisation des projets Wikimédia dont Wikipédia, soutien à la contribution et à la libération de contenu. Contributrice sur Wikipédia depuis 2006 et historienne de formation.

**Jean-Luc ARCHIMBAUD** Ingénieur en informatique (CNRS) diplômé de l'INSA Lyon, actuellement responsable de projets et directeur adjoint technique de l'unité CNRS Mathdoc. Il a lancé (et en a été responsable pendant 5 ans) la plate-forme PLUME (https://www.projet-plume.org). Voir aussi http://jl.archimbaud.free.fr.

**Sébastien BROCA** Docteur en sociologie (Cetcopra, Université Paris 1 Panthéon-Sorbonne). Auteur d'une thèse intitulée *L'utopie du logiciel libre. La construction de projets de transformation sociale en lien avec le mouvement du free software*. (dir. Ph. Breton, 2012).

**Jonathan CHIBOIS** Membre du IIAC – LAIOS (UMR 8177), École des Hautes Études en Sciences Sociales, Paris. Doctorant en anthropologie politique, il prépare une thèse sur l'évolution des pratiques numériques des députés de l'Assemblée nationale française. Carnet de recherche en ligne : http://laspic.hypotheses.org.

**Damien DJAOUTI** Maître de conférences en informatique à l'IUFM de l'Université Montpellier II - laboratoire LIRDEF (http://www.lirdef.fr). Il travaille sur la question des *Serious Games*, ces jeux
vidéo destinés à d'autres finalités que le divertissement : éducation, communication, santé... Co-fondateur de l'association Ludoscience (http://www.ludoscience.com) dédiée à l'étude du jeu vidéo.

**Primavera DE FILIPPI** Chercheure associée au CERSA / CNRS / Université Paris II. Experte légale à Creative Commons France et co-fondatrice du chapitre français de l'Open Knowledge Foundation.

**Séverine GIORDAN** Docteure en sciences de l'information et de la communication. ATER à l'Université d'Avignon dans le Master stratégie du développement culturel mention « médiations de la culture et du patrimoine ». Elle s'intéresse aux espaces sociaux et culturels reposant sur des processus de gouvernance partagée. Spécialiste du *Data Curation*, elle porte son attention principalement sur la constitution des mémoires collectives des ces groupes sociaux et leurs diffusions entre espaces présentiels et virtuels (fictions, expositions, débats, délibérations).

**Pierre-Amiel GIRAUD** Membre de l'UMR 5185 ADES – CNRS / Université de Bordeaux. Agrégé de géographie, il prépare une thèse sur les lieux et les territoires de la mouvance du Libre, en optant pour une démarche comparative des pratiques aquitaines et québécoises. Il cherche notamment à y montrer qu'Internet, en tant qu'espace géographique, ne rend visible qu'une partie des phénomènes essentiels à la compréhension de la mouvance du Libre.

**Gérard GIRAUDON** Directeur de Recherche Inria, spécialiste de Vision par Ordinateur, actuellement directeur du Centre de Recherche Inria, Sophia Antipolis – Méditerranée. Il a été pendant une dizaine d'années en charge du Développement et des Relations Industrielles d'Inria. Il a contribué à structurer la stratégie de l'Institut sur l'open source et la mise en œuvre de sa politique comme outil de transfert notamment à travers la création de consortium (ObjectWeb, SciLab, etc.). Il est l'un des co-auteurs des licences de la famille CeCIL. Il a publié en 2006 une tribune dans *Les Échos*, intitulée « Le logiciel libre et ouvert : révolution ou évolution ? », dont on peut trouver une version longue à http://interstices.info/jcms/c_14658/le-logiciel-libre-et-ouvert-revolution-ou-evolution.

**Patrick GUILLAUD** En charge des relations entre STIC et société à la direction du développement technologique d'Inria. Il pilote le
concours *Boost your code*. Son cursus professionnel l'a mené de l'industrie à l'enseignement et la recherche. Ayant une formation en automatique, architecture de systèmes, gestion, et un doctorat en sciences de l'information et de la communication, ses recherches portent sur la créativité et l'innovation technologique. Il enseigne à l'INSA de Lyon.

**Alexandre HOCQUET** Université de Lorraine & EHESS, Nancy & Paris. Professeur des Universités en Chimie (http://hocquet.eeigm.eu), étudiant en Histoire des Sciences et des Techniques à l'EHESS, entraîneur de Football sur Internet.

**Thibaud HULIN** Université de Montpellier 2, maître de conférences en sciences de l'information et de la communication, Laboratoire Interdisciplinaire de Recherche en Didactique, Éducation et Formation. Philosophe de formation, développeur occasionnel de logiciel libre.

**Benjamin JEAN** Membre de l'équipe du CUERPI (Centre Universitaire d'Enseignement et de Recherches en Propriété Intellectuelle), confondateur de la société Inno³, consultant au cabinet Gilles Vercken et maître de conférences à Sciences Po. Cofondateur de l'association Veni, Vidi, Libri et du cycle de conférences European Open-Source & Free Software Law Event (EOLE).

**Nicolas JULLIEN** Maître de conférence en économie à Télécom Brétagne. Il travaille sur les communautés en ligne, et notamment le logiciel libre depuis 1998. Il a publié une dizaine d'articles scientifiques sur le sujet.

**Hervé LE CROSNIER** Enseignant-chercheur à l'Université de Caen, il dispense des enseignements sur les technologies du Web (informatique) et la culture numérique (sciences de l'information). Ses recherches portent sur les relations entre l'Internet (et plus généralement le numérique) et la société. Il travaille également sur la théorie des biens communs et sur la communication scientifique. Il a publié dans la collection Les Essentiels d'Hermès deux ouvrages: *La Neutralité de l'internet* (avec V. Schafer et F. Musiani) et *La propriété intellectuelle: Géopolitique et mondialisation* (avec M. Dulong de Rosnay).
**Christophe MASUTTI** Docteur en histoire des sciences et des techniques, chercheur associé au SAGE / UMR 7363 (Sociétés, Acteurs, Gouvernements en Europe) à l'Université de Strasbourg, responsable des affaires européennes à la Direction Générale des Hôpitaux Universitaires de Strasbourg. Président de l'association Framasoft depuis janvier 2012.

**Camille PALOQUE-BERGES** Docteure en sciences de l'information et de la communication et actuellement post-doctorante LabEx HAS-TEC - DICEN (CNAM). Travaille sur l'histoire d'Internet et des pratiques de communication en réseau. Membre des associations WebArchivists.org et Patrimoine Belfortain de l'industrie informatique (PB2i). Auteure de *Poétique des codes* (Paris : Archives contemporaines, 2009).

**Isabelle RAMADE** Isabelle Ramade, Professeure agrégée affectée à l'université Paris-Sud 11. Chargée de mission C2i (Certificat Informatique et Internet) et Responsable Ressources Pédagogiques Numériques à la Faculté des Sciences d'Orsay. Responsable des Ressources Éducatives Ouvertes à Creative Commons France. Elle promeut la culture numérique à travers le C2i, et une culture libre à travers ses engagements personnels depuis 2005 (AFUL, Parinux, FDN et Wikimedia France), et depuis 2012 avec Creative Commons France.

**Stéphane RIBAS** Passionné par la collaboration en mode distribué dans le domaine du développement logiciel, il travaille à la direction du développement technologique d'Inria, ou il assure la promotion des méthodes de management de communautés auprès des équipes de recherche de l'institut. Il est l'organisateur des conférences fOSSa (Free Open Source Software for Academia) et il aime faire partager son expérience du libre auprès des étudiants grenoblois.

**Pascal ROBERT** Professeur en sciences de l'information et de la communication à l'ENSSIB/Université de Lyon et membre du laboratoire Elico. Il a récemment publié *Mnémotechnologies, une théorie générale critique des technologies intellectuelles* (Paris : Lavoisier, 2010) et l'Impensé informatique, critique du mode d'existence idéologique des TIC. Vol. 1. Les années 1970-1980 (Paris : Archives contemporaines, 2012).
**Valérie SCHAFER** Chargée de recherche, Institut des sciences de la com-munication du CNRS (Paris). Historienne. Auteur de *La France en réseaux (années 1960/1980)* (Paris : Nuvis, 2012) et *Le Minitel, l'enfance numérique de la France* avec Benjamin Thierry (Paris : Nuvis, 2012). Organisatrice avec Fanny Georges du séminaire *Histoires de l'Internet* à l'ISCC.

**Stéphane UBÉDA** Professeur des universités à l'Institut National des Sciences Appliquées de Lyon, il met sur pied et dirige pendant 10 ans un laboratoire de recherche en télécommunications et systèmes distribués. Associé à Inria comme chef d'une équipe mixte pendant cette période, il entre en 2009 au comité de direction de cet institut comme directeur scientifique en charge du développement technologique.

**Robert VISEUR** Assistant à la Faculté Polytechnique de l'Université de Mons, en Belgique, et Ingénieur de recherche au CETIC (Centre d'Excellence en Technologies de l'Information et de la Communi-cation). Ingénieur civil et Docteur en sciences appliquées de for-mation, il travaille principalement sur la valorisation des logiciels libres (modèles d'affaires, licences, etc.) et sur la mise en œuvre des technologies libres de recherche d'information.

**Jean-Benoît ZIMMERMANN** Directeur de Recherche CNRS, GRE-QAM, Université d'Aix-Marseille, Aix-Marseille School of Eco-nomics. Économiste, il travaille sur l'approche des interactions comme fondements de la coordination des agents économiques. Travaux sur l'industrie informatique, le logiciel et le logiciel libre depuis 1999 (une douzaine d'articles publiés).
<figure><img src="image_49.png" /></figure>
Table des matières

Préface

Hervé Le Crosnier .................................................... v

Introduction générale

Camille Paloque-Berges et Christophe Masutti ...................... xiii

Notes à propos de l'ouvrage .................................... xx

Remerciements......................................................xxiii

I (Pré-) histoire 1

Des réseaux ouverts, pour quoi faire ?

Valérie Schafer .................................................... 3

1. Les réseaux seront ouverts ou ne seront pas .................... 5

2. Du réseau « libertaire » au réseau « libéral » .................... 16

Conclusion................................................................ 25

Ingénieurs, hackers : naissance d'une culture

Christophe Masutti .................................................... 31

1. À propos d'ordinateurs et de temps partagé .................... 32

2. Moufettes et canard sauvages.................................... 38

3. Le travail hacker .................................................... 47

4. Réseau .................................................................... 55

5. Une contre-culture ?.................................................... 61
Esquisse d'une archéologie de l'informatique communicante
Pascal Robert.................................................. 67

1. L'augmentation et le bootstrapping.................. 68

2. La modélisation, la résolution de problèmes et le réseau...... 79

Conclusion.................................................... 90

Sharing Source Code
Christopher Kelty (trad. Camille Paloque-Berges)............ 93

II Économie du Libre 97

Les modèles économiques du logiciel libre et leur évolution
Stéphane Ribas, Patrick Guillaud, Stéphane Ubéda............ 99

1. Années 1960 et 1970, les débuts de l'informatique : des modèles économiques basés sur le matériel.................. 103

2. Années 1980, l'époque des pionniers du Libre.................. 105

3. Années 1990, naissance de GNU/Linux : du logiciel libre à l'Open Source Initiative (OSI).................. 108

4. Première décennie 2000, professionnalisation de l'open source et structuration d'un nouveau secteur économique...... 114

Conclusion.................................................... 131

Le logiciel libre : un renouveau du modèle industriel coopératif de l'informatique
Nicolas Jullien et Jean-Benoît Zimmermann.................. 135

1. Le modèle coopératif de production du logiciel, des origines au renouveau porté par Internet.................. 138

2. Les modèles industriels du Libre.................. 147

Conclusion.................................................... 162

Les RMLL, haut lieu mobile du libre francophone
Pierre-Amiel Giraud........................................ 165

1. Les RMLL, de l'ancrage aquitain au lieu mobile.................. 167

2. Un haut lieu du Libre, point d'entrée de la mouvance mondiale sur les territoires.................. 180

3. Conclusion : les RMLL, lieu privilégié d'observation de la mouvance.................................................. 190
III Trajectoires du Libre 195

Influence du Libre dans l'histoire du jeu vidéo

Damien Djaouti 197

1. Le Libre comme philosophie originelle des jeux vidéo ? 198

2. Du shareware au modding 207

3. La création amateur de jeu vidéo : de l'open source au Jeu 2.0 214
Conclusion 221

Brève histoire de l'identité visuelle du Libre

Thibaud Hulin 227

1. Les quatre registres de libertés et de contraintes 228

2. L'énonciation éditoriale dans la mythologie Mozilla 231

3. Y a-t-il une ergonomie propre au libre ? Le cas KDE 237

4. OpenOffice et l'apprentissage de la grammaire visuelle 239

5. Comment Ubuntu ordonne-t-il le « fatras sémiotique » de ses utilisateurs 243

Free software et open source : utopie et idéologie

Sébastien Broca 253

1. Le mariage de raison entre GNU et Linux 254

2. La naissance du mouvement open source 257

3. Le pragmatisme contre l'idéologie 262

4. L'idéologue n'est pas nécessairement celui qu'on croit 267

5. Un débat obsolète ? 269

IV Licences libres 275

L'évolution des licences libres et open source : critères, finalités et complétude ?

Benjamin Jean 277

1. La distribution des cartes : le processus d'apparition des licences libres 281

2. La consolidation et l'harmonisation des outils juridiques (depuis 2007) 309
Conclusion 335
Libre choix ou choix du Libre ?

Primavera De Filippi et Isabelle Ramade 341

1. Genèse des licences libres 342

2. Du libre à l'ouvert ? 349

3. Une question de liberté 365

Perspectives et conclusion 374

V Études de cas

379

Mozilla : histoire d'une libération

Robert Viseur 381

1. 1993 – 1997 : héritage de Mosaïc et percée de Netscape 383

2. 1998 – 2002 : libération de Netscape et victoire de Micro-soft 385

3. 2003 – 2007 : fin de Netscape et succès de Firefox 389

4. 2008 – 2012 : la concurrence de Webkit 395

5. Discussion 398

Conclusion 401

Pure data, logiciel libre de productions créatives

Séverine Giordan 407

1. Pure Data, un logiciel de programmation visuelle 408

2. Dialogue entre scientifiques et artistes 409

3. Questions de licences 413

4. La Communauté 416

5. Les atouts de Pure Data 423

Conclusion 426
Wikipédia et le monde du Libre

Adrienne Alix .................................................. 431

1. De Nupedia et GNUpedia à Wikipédia, un projet né sur les bases du logiciel libre .................................................. 433

2. Les Wikipédiens, une communauté issue du monde du Libre .................................................................................. 437

3. Des règles de vie au sein d'un des plus grands projets laboratifs du monde .................................................... 446

4. Wikipédia, un projet libre au-delà du Libre .................... 450

5. Wikipédia, un projet politique ? .................................... 454

Conclusion ................................................................................ 459

Du logiciel libre pour l'Assemblée Nationale

Jonathan Chibois .................................................. 461

1. Genèse ................................................................................ 463

2. Réalisations ................................................................................ 468

3. Confrontations ................................................................................ 472

4. Usages .................................................................................... 477

En conclusion ................................................................................ 482

RTFM! La chimie computationnelle : une communauté scientifique loin du libre

Alexandre Hocquet .................................................. 487

1. RTFM! What FM ? .................................................... 487

2. La chimie computationnelle ................................................ 489

3. Le terminal graphique .................................................... 492

4. Cinq pratiques caractéristiques du Libre ............................ 494

5. Trois contraintes à la pérennité du Libre ............................ 496

6. La rupture du desktop modeling ........................................ 498

7. La « générification » des logiciels ........................................ 503

8. What FM ? Tensions dans la communauté ............................ 506
VI Témoignages : Libre et institutions 511

Un point d'histoire de la stratégie d'Inria sur l'open source
Gérard Giraudon 513

La place du logiciel libre au CNRS
Jean-Luc Archimbaud 523

Quelques faits passés 525

Conlusion personnelle 540

Annexe 545

Liste des auteurs 545

Table des matières 556