Navigation – Plan du site

AccueilNumérosVol. 62 - n° 3Prix du jeune auteurDes biens industriels publics. Ge...

Prix du jeune auteur

Des biens industriels publics. Genèse de l’insertion des logiciels libres dans la Silicon Valley

Premier prix ex-aequo
Industrial public goods: A genesis of the insertion of free software in Silicon Valley
Gabriel Alcaras

Résumés

Cet article analyse l’insertion des logiciels libres dans l’industrie informatique, en retraçant la genèse d’un logiciel nommé CVS au sein des pratiques de travail et de marchandisation de la Silicon Valley dans les années 1980 et 1990. En mobilisant le concept de bien industriel public, nous montrons que la création de ce logiciel avait pour but d’affranchir les ingénieurs de certaines injonctions de l’informatique marchande qui pesaient sur leurs outils de travail. L’autonomie conquise n’est toutefois que relative, puisqu’elle est conçue comme une condition nécessaire à l’amélioration de la production logicielle, y compris marchande. L’article montre par ailleurs que, même dans les années 1990, les logiciels libres n’étaient pas qu’affaire de bénévoles, puisque la majorité des contributions à CVS étaient rémunérées ou s’effectuaient dans le cadre d’un emploi à temps plein. C’est d’ailleurs contre cette image de bénévolat et de gratuité, figure repoussoir pour les cadres de la Silicon Valley, que se sont élevés des ingénieurs-entrepreneurs. Ils ont cherché à montrer que la production de ces biens industriels publics avait une valeur pour l’informatique marchande en leur attribuant un prix, engageant un effort de traduction pour chiffrer un travail gratuit et mesurer l’impact de biens publics sur une industrie.

Haut de page

Notes de la rédaction

Premier manuscrit reçu le 1er octobre 2019, article accepté le 1er juin 2020.

Texte intégral

1. Introduction

1Heartbleed, le « cœur qui saigne » : la faille de sécurité informatique ainsi baptisée, révélée en 2014, s’avère aussi spectaculaire que son nom dans ses répercussions. Depuis bientôt trois ans, elle rendait vulnérable le chiffrement des données sur internet, signalé par la présence d’un petit cadenas vert sur les navigateurs. Devant la débâcle de ce dispositif essentiel pour, entre mille autres usages, masquer les identifiants bancaires des internautes, l’affaire fait le tour de la presse spécialisée puis généraliste. Surtout, elle propulse au centre de la tourmente l’infrastructure en charge du chiffrement, OpenSSL, ainsi que l’ingénieur responsable du fiasco.

2Outre qu’elle extirpe l’infrastructure de son invisibilité caractéristique (Star, 1999), la faille attire les regards sur les conditions de production du logiciel libre OpenSSL. Il s’agit d’un de ces programmes dont le code est librement accessible, modifiable et redistribuable, parfois désignés comme faisant partie intégrante des « communs numériques » (Broca, 2013). Face à la pluie d’invectives, un ingénieur reproche aux entreprises de s’appuyer sur OpenSSL pour garantir leur sécurité sans y contribuer en retour :

  • 1 Sauf mention contraire, les citations en anglais sont traduites par mes soins.

« La gratuité peut vous faire saigner. […] Pensez-y, OpenSSL ne dispose que de deux personnes pour écrire, maintenir, tester et évaluer 500 000 lignes de code essentielles à [votre] commerce » (John Walsh, « Free Can Make You Bleed », billet publié le 30 avril 2014 sur le blog « SSH Communications Security » et archivé sur https://web.archive.org/web/20161202163921/http://blog.ssh.com/​free-can-make-you-bleed, consulté le 23 septembre 2019)1.

  • 2 En 2018, Microsoft a fait l’acquisition de l’entreprise Github, basée à San Francisco et devenue ce (...)
  • 3 Lionel Maurel, « Les Communs numériques sont-ils condamnés à devenir des “Communs du capital” ? », (...)

3L’actualité informatique est émaillée d’événements comme Heartbleed, qui révèlent l’ampleur de cette partie immergée des infrastructures marchandes et leur recours systématique aux logiciels libres. Ces derniers, que le directeur de Microsoft avait acerbement qualifiés de « cancer communiste » (Berry, 2008), font maintenant l’objet d’investissements massifs de la part de cette même firme, à concurrence de plusieurs milliards de dollars2. Tandis que certains ingénieurs saluent les nombreuses entreprises qui emboîtent le pas à Microsoft, bien des militants craignent que cet engagement transforme les logiciels libres en « communs du capital »3.

4À cette première opposition entre le monde marchand du capital et celui non marchand des communs s’ajoute la tension entre travail et hors travail. En effet, les logiciels libres sont souvent présentés comme s’étant historiquement développés en dehors des entreprises et du rapport salarial, sur le mode du bénévolat. Ils apparaissent tantôt comme le résultat d’une activité militante, dont la finalité est d’accroître le domaine des communs, tantôt comme une activité de bricolage pratiquée pour elle-même, pour s’amuser (Lallement, 2015). Même si les licences libres empêchent les entreprises de s’approprier les codes, elles peuvent légalement se servir des logiciels comme infrastructures de production, ce qui pose la question de l’exploitation d’un travail gratuit (Simonet, 2018). Les investissements récents des grandes firmes du numérique ne font qu’attiser cette peur ancienne des logiciels libres comme la « main armée d’un capitalisme intriguant » (Berrebi-Hoffmann et al., 2018, p. 327). Comment expliquer que ces infrastructures libres, relevant d’un régime juridique et économique apparemment étranger à la sphère marchande, soient insérées à ce point dans l’informatique marchande ?

  • 4 La revue française Terminal a été précurseuse en la matière, avec son numéro spécial de 1999 : « Lo (...)

5La littérature scientifique n’ignore pas les rapports entre logiciels libres et entreprises, mais elle les a rarement pris pour objet principal4. Ces travaux s’intéressent en priorité aux conceptions politiques et esthétiques de la technique, aux pratiques militantes ainsi qu’aux modes de gouvernance, à l’instar des travaux fondateurs des anthropologues Biella Coleman (2012) et Chris Kelty (2008), sans oublier ceux du sociologue Nicolas Auray (2013). Du reste, ces recherches ont privilégié l’étude de projets, parfois explicitement politiques, qui vilipendent volontiers l’informatique propriétaire et la recherche du profit. Entre autres exemples, l’enquête fouillée sur le logiciel SPIP (Demazière et al., 2007) montre que le peu de personnes qui aspirent à se professionnaliser et à tirer un profit direct de leur activité sont perçues comme illégitimes dans ce milieu bénévole. Cette condamnation morale s’effectue au motif du « principe de désintéressement » qui guide le projet, destiné avant tout au secteur associatif ou militant (Demazière et al., 2013, p. 38).

6Alors que l’intégration des logiciels libres aux infrastructures marchandes paraît plus claire chaque jour, les sciences sociales peinent ainsi à expliquer ce phénomène autrement qu’en le caractérisant comme une ambiguïté, une contradiction non résolue ou une récupération. Cette difficulté analytique est due selon moi à ce que Viviana Zelizer (2001) a appelé la vision des « mondes antagonistes » en parlant des transactions intimes. Tant que nous continuerons de penser le monde du libre comme originellement protégé du monde marchand, tant que nous ferons de la rationalité économique un obstacle, voire un danger pour la logique des communs, notre compréhension de l’informatique libre et marchande restera incomplète. Voilà pourquoi, plutôt que de les séparer, j’envisage l’ensemble comme un système cohérent, que j’appelle l’industrie informatique, et j’analyse la position des logiciels libres au sein de cette dernière à la lumière d’un nouveau concept, les biens industriels publics.

7L’économie de l’innovation a parfois fait usage d’une notion similaire pour caractériser des situations de coopération entre firmes concurrentes d’un même secteur. Sous la plume de Paul M. Romer, les « industry-specific public goods » désignent tous les biens non-rivaux et non-excluables que des entreprises d’une même industrie auraient intérêt à produire dans un cadre coopératif (Romer, 1993, p. 370). Ces biens regroupent des codes sources, des solutions d’ingénierie ou encore des résultats de recherche fondamentale. L’économiste insiste surtout sur les mécanismes institutionnels qu’un gouvernement pourrait mettre en place pour encourager cette coopération, tout en protégeant la concurrence sur les produits finaux. Vingt ans plus tard, deux économistes traduisent l’expression de P. M. Romer par « bien public industriel » pour l’appliquer aux logiciels libres qu’ils appellent « plate-forme », comme Linux (Jullien et Zimmermann, 2013, p. 159). Pour réduire leurs coûts, différentes entreprises coopèrent par le biais d’une entité légale, comme une fondation, au développement de ces logiciels qui fournissent les briques de base de leurs produits.

8Dans cet article, je propose de sociologiser ce concept de bien public industriel et d’en montrer la pertinence pour l’étude des logiciels libres en particulier et de l’industrie informatique en général. Je parlerai pour ma part de « bien industriel public », à la fois pour le distinguer de son sens initial dans la théorie économique et pour insister sur l’insertion du libre dans l’industrie. La notion originelle insiste opportunément sur deux aspects essentiels que je reprendrai à mon compte : le régime juridique et économique de biens publics, et la coopération qui peut s’organiser au-delà des frontières d’une même entreprise. C’est là que s’arrêtent les ressemblances et ici que se dessinent les différences, dont voici les trois majeures. Premièrement, les économistes emploient souvent ce terme à des fins prescriptives, pour encourager un fonctionnement optimal de l’innovation. Dans ma compréhension des biens industriels publics, l’optimalité n’est pas donnée mais disputée : ce qui est optimal pour un groupe ne l’est pas pour un autre. Deuxièmement, les théories économiques mettent en scène des firmes, envisagées comme des entités homogènes qui opèrent selon des stratégies rationnelles. Ce parti pris ne rend pas compte des intérêts divergents qui coexistent au sein d’une entreprise, par exemple entre ingénieurs et managers. Surtout, si la coopération entre firmes est motivée par une stratégie rationnelle de réduction des coûts, pourquoi les entreprises auraient-elles refusé de se comporter rationnellement pendant si longtemps ? Les biens industriels publics, tels que je les conçois, constituent une ressource clef pour une pluralité d’acteurs de tailles différentes : les entreprises, bien sûr, mais aussi les ingénieurs à la fois en tant qu’individu et en tant que profession. Troisièmement, la notion originelle ne décrit qu’une partie des logiciels libres, ceux où l’implication des entreprises est la plus visible et où la coopération est très formalisée. À l’inverse, je défends l’idée que tous les logiciels libres sont des biens industriels publics, insérés dans une même industrie informatique où ils occupent des positions différenciées.

  • 5 Par exemple, les effectifs des pompiers sont composés à 78 % de « volontaires », ceux-ci dépassant (...)

9Par industrie informatique, j’entends donc l’ensemble du système productif numérique, qui ne se résume pas à l’informatique marchande, incarnée par le salariat, le marché et les logiciels propriétaires, mais s’étend également au travail gratuit produit par le bénévolat, à la coopération et aux logiciels libres. L’étude d’une industrie ainsi définie offre plusieurs avantages. Tout d’abord, cette définition ne réduit pas la sphère économique au seul phénomène marchand, ce que Karl Polanyi (1977, p. 6-18) appelle l’écueil de « l’économisme », une condition sine qua non pour comprendre la position du libre dans l’économie du numérique. Ensuite, examiner la production m’amène à croiser sociologie du travail et sociologie économique (Bidet et al., 2003) pour expliquer en quoi l’activité de programmation, c’est-à-dire le rapport opératoire au code source, détermine en partie le recours aux biens industriels publics. S’intéresser aux opérations concrètes des ingénieurs, c’est donc s’inscrire dans une approche sociologique soucieuse des techniques (Desrosières, 2013 ; Dagiral et Martin, 2017) et ouvrir une fenêtre sur l’expérience de production des logiciels et ses conséquences. Enfin, cette perspective invite à comparer le logiciel libre et l’informatique à d’autres mondes productifs, comme l’artisanat ou l’ingénierie, et à d’autres industries où le bénévolat constitue l’une des formes incontournables du travail5.

  • 6 Je précise que mon usage du masculin dans le texte n’obéit pas à une règle de primauté du masculin (...)

10Cet article revient sur la genèse des premiers biens industriels publics et de leur insertion dans l’informatique marchande des années 1980 et 1990. En suivant les ingénieurs qui ont contribué à ces logiciels libres alors qu’ils travaillaient pour des entreprises, principalement de la Silicon Valley, je montrerai comment leur conception et leur utilisation prennent tout leur sens dans l’activité de production marchande6. Cette recherche s’inscrit dans une enquête sociologique plus large, consacrée aux gestionnaires de versions, des outils essentiels à la coordination de l’écriture collective des programmes, et aux enjeux contemporains des biens industriels publics. Dans ce petit milieu d’experts, j’ai rencontré des ingénieurs qui produisent ce type d’outils depuis les années 1980. À ma grande surprise, leurs propos témoignaient déjà d’une forte intégration au monde de l’entreprise, battant en brèche le mythe d’une origine purement bénévole du libre. Étudier la genèse de l’insertion des logiciels libres dans l’industrie informatique permet ainsi de ne pas exagérer la nouveauté du phénomène et de préciser leur statut de biens industriels publics. Voilà pourquoi cet article se concentre sur l’un des premiers gestionnaires de versions libres, le logiciel Concurrent Versions System (CVS).

  • 7 Certains cumulent les positions ou passent de l’une à l’autre au cours de leur carrière, c’est pour (...)
  • 8 Lorsque je cite les propos des développeurs, je précise entre parenthèses leur statut, leur employe (...)

11Étudier les collectifs du logiciel libre pose un défi singulier à l’enquête, car ils ne partagent pas un même espace physique et s’organisent selon des règles informelles. L’approche ethnographique, particulièrement pertinente pour analyser le logiciel en train de se faire (Demazière et al., 2011), était dans mon cas inaccessible, puisque CVS est aujourd’hui un logiciel obsolète. Fort heureusement, je ne m’intéresse pas ici aux pratiques internes du projet mais aux relations que ses contributeurs entretiennent avec l’informatique marchande. Pour ce faire, je croise différents matériaux. Premièrement, j’ai mené dix entretiens auprès de personnes liées à CVS qui ont occupé divers rôles dans l’informatique marchande, principalement des ingénieurs (n=6), des managers (n=3), des entrepreneurs (n=3) et des universitaires (n=2)7. Au moment des entretiens, menés entre octobre 2018 et août 2019, pour partie en face-à-face dans la Silicon Valley (n=4) et pour partie par téléphone (n=6), ces hommes avaient entre 45 et 65 ans8. Seul l’un d’entre eux, qui se décrit ouvertement comme un millionnaire, a pris sa retraite ; les autres exercent encore une activité professionnelle. Deuxièmement, je fais un traitement quantitatif des 466 contributions effectuées par 42 personnes entre la première version officielle de CVS en 1990 et la fin de son développement actif en mai 2000, en identifiant les employeurs grâce à des entretiens ou aux archives du logiciel. Enfin, deux entrepreneurs m’ont communiqué certaines de leurs archives personnelles : factures, contrats, supports publicitaires et correspondance avec des clients.

12Mon propos s’organisera en deux temps, qui correspondent schématiquement à deux phases dans le cycle de vie du logiciel. Dans une première partie, je reviendrai sur la généalogie technique de CVS pour montrer que les ingénieurs utilisent les biens industriels publics certes pour s’affranchir de l’informatique marchande, mais surtout pour mieux produire. Dans une seconde partie, j’expliquerai en quoi les ingénieurs paient le prix de cette indépendance des normes marchandes, en examinant de près les conditions de la maintenance de CVS.

2. S’affranchir de l’informatique marchande pour mieux produire

13Dans cette partie, je montrerai que les gestionnaires de version répondent à un même problème industriel : l’écriture collective des programmes (2.1). Ce problème se manifeste dans l’activité productive des ingénieurs sous la forme de tâches vécues comme un sale boulot manuel ; pour s’en libérer, ils créent des logiciels qui automatisent ces routines de travail (2.2). Parce qu’ils sont produits en entreprise, ces outils appartiennent de facto à leur employeur : en les plaçant sous licence libre, les ingénieurs s’approprient ces outils qu’ils peuvent désormais utiliser tout au long de leur carrière (2.3). Au-delà d’une appropriation individuelle, les biens industriels publics comme CVS constituent une ressource stratégique pour l’ensemble du groupe professionnel des ingénieurs dans le contrôle de leur expertise (2.4).

2.1. De l’université à la start-up, un problème d’écriture industrielle

14La généalogie technique de CVS nous amène dans les départements universtaires d’informatique, au tournant des années 1980. Walter Tichy, professeur fraîchement recruté à Purdue dans l’Indiana en 1979, conçoit le premier gestionnaire de version libre et le rend public en 1982. À l’époque, W. Tichy écrit un programme en collaboration avec un de ses étudiants — une expérience frustrante à l’en croire, car chaque nouvelle version de l’un efface la précédente de l’autre, de manière irréversible. Il cherche donc avec son Revision Control System (RCS) à se doter d’une « assurance contre les erreurs ».

15Quatre ans plus tard, Dick Grune, professeur à la Vrije Universiteit Amsterdam, écrit la première version de CVS sous la forme d’une collection de petits programmes, appelés scripts, en s’appuyant sur RCS. Si D. Grune veut, lui aussi, faciliter la collaboration avec deux de ses étudiants, le problème provient cette fois du désajustement des rythmes et des lieux de travail :

« Nous avions des horaires extrêmement différents, l’un avait un rythme stable de 9h à 17h, l’autre était irrégulier et je ne pouvais travailler sur ce projet qu’en soirée » (Dick Grune, Lecturer, Vrije Universiteit Amsterdam, 47 ans en 1986).

16La première version de CVS se fonde donc sur l’idée qu’un logiciel doit pouvoir être développé « en parallèle », par plusieurs personnes qui travaillent « de façon indépendante », tout en s’assurant que leurs versions concurrentes pourront être finalement fusionnées en une seule version cohérente — d’où le nom de Concurrent Versions System.

17La création de CVS s’enracine ainsi dans deux expériences communes de l’écriture collective des programmes et des frustrations qu’elle engendre. Elle débute également avec la collaboration académique, qui caractérise les premiers logiciels libres (Kelty, 2008, p. 127-142). Les deux chercheurs ne mentionnent toutefois pas l’idéal scientifique du communalisme, auquel l’ethos du libre est souvent comparé (Le Crosnier, 2018), comme moteur premier de leur action. La création de RCS est d’abord motivée par le manque d’outils abordables pour des professeurs. Le principal gestionnaire de version utilisé à l’époque, Source Code Control System (SCCS), est destiné aux très grandes entreprises et largement hors de portée des bourses universitaires.

18Les recherches de Dick Grune et Walter Tichy s’inscrivent en outre dans les branches appliquées de la discipline informatique et se préoccupent des problèmes concrets du développement industriel. La thèse du second a été fortement influencée par les travaux de Frank DeRemer, professeur à l’Université de Californie Santa Cruz, qui a fondé en 1979 sa société pour vendre des outils aux programmeurs de la Silicon Valley. F. DeRemer, resté célèbre pour son concept de Programming-in-the-Large, a théorisé la nécessité pour l’industrie de s’équiper de systèmes techniques qui soutiennent une division du travail en équipes. Dans cette perspective, W. Tichy oriente ses recherches vers la création d’outils « utiles » qui, comme il le dit en entretien, s’intéressent « à la structure du code, et pas seulement au code lui-même » — d’où l’idée de le décomposer en versions.

19Mieux encore, la proximité des deux professeurs avec l’informatique marchande ne se limite pas à leurs recherches, puisqu’ils y ont occupé des emplois. D. Grune, après avoir obtenu son master de physique en 1967, a travaillé pendant plusieurs années comme administrateur système avant d’obtenir son doctorat en informatique. Quant à W. Tichy, il s’engage dès la fin de sa thèse dans une activité de consultant. En 1979, il décroche son premier contrat avec International Telephone and Telegraph (ITT), pour conseiller l’entreprise sur sa gestion de versions. C’est dans ce contexte que naît l’idée de RCS :

« Ils avaient un système de gestion de versions complètement dément, c’était en gros une bibliothèque où les développeurs stockaient des cassettes avec leur version, et à chaque fois qu’ils produisaient une nouvelle version, il fallait envoyer un disque dans cet endroit, je crois que c’était en Belgique ou aux Pays-Bas. C’était complètement impraticable ! Donc c’est là-bas que j’ai développé l’idée de départ de RCS » (Walter Tichy, Assistant Professor, Purdue University, 25 ans en 1979).

20Enfin, ces systèmes se construisent et se diffusent grâce à un acteur majeur de l’industrie informatique. Après avoir diffusé des cassettes de RCS à des collègues, Walter Tichy reçoit en 1981 une lettre de Bill Joy, qui fondera un an plus tard Sun Microsystems, une société emblématique de la Silicon Valley. B. Joy est alors employé par l’Université de Berkeley et jouit déjà d’une belle réputation pour son travail sur le système d’exploitation libre Berkeley Software Distribution (BSD), qui sert de base à d’autres systèmes payants. Dans sa missive, il propose à W. Tichy d’intégrer RCS dans la prochaine version de BSD, mais à une condition : il exige une gestion des versions parallèles d’un même logiciel, appelées « branches », utilisées pour décliner un logiciel selon les machines auxquelles il est destiné. Alléché par la perspective de diffuser son programme dans le monde entier, W. Tichy s’exécute, même s’il avoue « ne pas avoir vu l’intérêt de ces fonctionnalités » quand il collaborait avec son étudiant.

21Le CVS issu des universités n’est toutefois pas celui dont se rappellent les milliers d’ingénieurs qui l’ont utilisé dans les années 1990. La première version largement diffusée a été complètement reprise en main par un jeune ingénieur, Brian Berliner, à la fin des années 1980, qui travaille alors pour Prisma, une start-up « très agressive » selon ses dires, qui construit un super-calculateur. B. Berliner est affecté à l’équipe qui en développe le système d’exploitation. La tâche est monumentale et implique de « toucher à toutes les parties du système », le tout à un rythme particulièrement intense. Malgré le recours à RCS, l’équipe peine à atteindre ses objectifs à cause du principe central organisant l’écriture collective, le verrouillage (lock), qui s’apparente à un système de réservation :

« À l’époque, dans une équipe de développement logiciel, tu verrouillais un fichier, puis tu le modifiais, et pendant que tu le verrouillais, personne d’autre ne pouvait y toucher, donc les gens attendaient leur tour. Tu vois ? Les gens attendaient vraiment : “Hey Joe, quand est-ce que tu vas terminer ton code, parce que ça fait deux semaines que t’as verrouillé TCP/IP, moi aussi j’ai des trucs à faire !” […] Tout le monde devait travailler sur son code en cachette et dans son coin, et quand tu déverrouillais, les autres devaient trouver ce que tu avais changé, voir la différence entre tes changements et leurs changements » (Brian Berliner, ingénieur, start-up, 24 ans en 1989).

22Le verrouillage empêche donc deux personnes de modifier simultanément la même partie d’un fichier, ce que les programmeurs appellent un conflit. Dans les grandes entreprises, où chacun s’occupe d’un territoire délimité, ce principe de réservation fonctionne correctement et suscite au pire une irritation liée à l’attente. Mais dans le cas d’une start-up comme Prisma, où les développeurs « touchent à toutes les parties du noyau à la fois » et « bossent comme des fous », la patience n’est pas de mise et les relations interpersonnelles en pâtissent quand ils finissent par « se marcher sur les pieds ». Sous une forme exacerbée, le problème reste fondamentalement le même, à savoir la gestion de flux d’écrits industrialisés.

2.2. S’outiller : passer du sale boulot « manuel » au vrai travail d’automatisation

23Jusqu’à une période récente, la plupart des équipes de développement déléguaient à une personne la charge dite de la « gestion de configuration ». Cette activité, délicate mais nécessaire pour coordonner et harmoniser les écrits, est d’autant plus difficile et cruciale dans le contexte du rythme effréné de la start-up. Parce qu’il est l’ingénieur le plus junior et parce qu’il l’a déjà endossé dans ses postes précédents, B. Berliner écope de ce rôle informel. Mais « garder un œil sur le code source et où ça en est » pour s’assurer que les versions fusionnent convenablement est pour lui une expérience harassante.

« Il fallait comparer les versions à la main, c’était vraiment compliqué. […] Je le faisais quand j’avais le temps, pendant mon temps libre. […] J’étais devenu LE mec de la gestion de conflits ; ce n’était pas mon vrai travail [day job] mais bon, je me suis retrouvé coincé dans cette position à Prisma » (Brian Berliner, ingénieur, start-up, 24 ans en 1989).

24L’irruption du travail manuel dans le champ lexical a de quoi étonner : après tout, que font les mains du programmeur si ce n’est manipuler un clavier ? Il n’est pas question du rapport aux périphériques, bien que ces derniers soient au centre de savoir-faire, de pratiques virtuoses et d’achats spécialisés qui mériteraient leur propre analyse. Brian Berliner fait ici référence à une expérience interne de l’activité de programmation et à la répétition de milliers d’opérations concrètes pour manipuler le matériau écrit du code. Cette activité ne s’inscrit donc ni dans la conception abstraite d’un logiciel ni dans le recours aux savoirs formels de l’algorithmique, mais plutôt dans un rapport opératoire aux outils et à la matière de l’ingénierie informatique, le code source.

25La sociologie de l’activité artisanale éclaire ce rapport aux outils et à la matière. Elle distingue l’automatisme, répétition machinale qui échappe à la conscience et peut s’avérer aliénante (Gaborieau, 2017), de la routine, répétition réflexive attentive au corps, aux outils et aux matériaux (Jourdain, 2014a, p. 145-179). Le travail du code et la gestion de configuration en particulier peuvent être décrits comme une série de routines car, en dépit de leur caractère répétitif, les développeurs doivent être très attentifs pour déceler les différences et les réconcilier. C’est dans ce rapport opératoire au code qu’il convient d’interpréter le champ lexical de la main. B. Berliner et bien d’autres le mobilisent pour évoquer, parfois avec nostalgie, une époque technique révolue.

« C’étaient vraiment des outils très rudimentaires, du genre qu’on utilise pour fouiner à droite à gauche et voir les choses. […] Mais c’était une manière très différente de faire, beaucoup plus intense en travail manuel [manually intensive]. On prend tout ça pour acquis maintenant, parce que nos outils sont tellement meilleurs maintenant ! […] Je veux dire, pour toi, c’est sûrement automatique, mais à l’époque, les outils étaient un peu différents, les outils étaient manuels quoi » (Brian Berliner, ingénieur, start-up, 24 ans en 1989).

26Une opposition entre « manuel » et « automatique » se précise autour de l’emploi des outils, mais comment les distinguer ? Les artisans qui, contrairement à une idée tenace, ont largement intégré machines et ordinateurs dans leurs pratiques (Perrin, 2017), enrichissent leurs outils en les personnalisant (Schwint, 2005). De la même manière, Brian Berliner va chercher à enrichir les outils à sa disposition en portant une attention réflexive à ses routines de travail, c’est-à-dire aux séquences répétitives qu’il met en œuvre pour gérer les flux d’écrits.

27C’est justement dans cette perception de la répétition que s’opère un déplacement vers une autre dimension de l’ingénierie informatique, l’activité intellectuelle de conception des programmes. L’ingénieur observe alors sa propre routine sous l’angle d’un problème logique, en repérant ses séquences répétitives et en les codifiant et les automatisant sous forme logicielle. C’est ainsi qu’une routine essentielle de la programmation inclut la production d’outils qui automatisent d’autres routines.

  • 9 Le terme de « main » ne désigne évidemment pas le corps des informaticiens, pas plus que l’adjectif (...)

28Les ingénieurs entretiennent d’ailleurs avec ces routines « manuelles » un rapport ambivalent9. Une fois qu’elles sont automatisées, les réaliser soi-même plutôt que les déléguer à son ordinateur semble inefficace. En ce sens, B. Berliner aurait l’impression de faire le sale boulot à la place de sa machine. D’un autre côté, c’est uniquement grâce à son expérience intime de la routine qu’il est en mesure d’en comprendre les séquences répétitives et de les automatiser — bref, de faire son vrai travail de programmeur, engagé subjectivement dans un rapport opératoire et une activité intellectuelle auxquels il aspire, à la manière des opérateurs téléphoniques dont le « vrai boulot » les engage dans leur monde-écran (Bidet, 2011).

29C’est donc pour transformer cette routine répétitive en vrai travail que B. Berliner propose à ses supérieurs de produire un nouvel outil qui supprime les interruptions dues au verrouillage. Durant les deux semaines qui lui sont accordées, il travaille sur les scripts de D. Grune pour en faire un programme complet, cohérent et rapide. L’outil final paraît d’autant plus merveilleux qu’il épouse parfaitement ses propres routines, affinées et raffinées à force de répétition.

« J’ai mis dans CVS tous les petits trucs que j’avais toujours voulu avoir. Donc CVS a rendu tous ces trucs vraiment plus simples, tous les trucs que je devais gérer manuellement à Prisma. […] CVS, par exemple, on pouvait lui demander : montre-moi les différences entre le premier septembre et le premier octobre, et puis comme par magie, il allait parcourir toute l’arborescence et construire un patch, tu vois ? » (Brian Berliner, ingénieur, start-up, 24 ans en 1989).

  • 10 Brian Berliner publie la première version officielle de CVS en 1989, sur le groupe USENET com.sourc (...)
  • 11 Par exemple, « je fais ça comme ça parce que c’est BEAUCOUP plus efficace… Faites-moi confiance ».

30Le code de la première version officielle de CVS comporte les traces de ce travail d’automatisation10. Les « petits trucs » de la routine s’illustrent à travers des commentaires11, tandis que le vrai travail d’automatisation s’incarne dans une fonction qui trie différents cas de figure, certains étant pris en charge par l’outil et d’autres destinés à la résolution humaine, la fameuse gestion de conflits.

2.3. Libérer les codes pour s’approprier son outil de travail

31La création de CVS a beau s’ancrer dans les routines de production professionnelle, ce simple fait n’explique pas que Walter Tichy, Dick Grune ou Brian Berliner en fassent un bien industriel public. Pourquoi faire le choix du libre partage plutôt que conserver CVS dans sa boîte à outils personnelle ? La littérature scientifique a déjà montré en quoi le partage des codes s’accompagne de valeurs politiques associées au libéralisme (Coleman, 2012) ou à l’édification d’un espace public (Kelty, 2008). Ces travaux rappellent, à juste titre, que le mouvement du libre initié par Richard Stallman en 1983 ne s’apparente pas à une rupture des pratiques de programmation ; au contraire, l’enjeu est de revenir à un état antérieur de libre circulation des codes, en résistant aux appropriations (enclosure) des biens informationnels (Boyle, 2003) et aux vagues successives de législation qui privatisent les codes entre 1969 et 1982 (Broca et Coriat, 2015, p. 267-268).

  • 12 Sources : Angel, 1991, et les chiffres de l’American Electronics Association rapportés dans « Turno (...)

32J’offre ici une explication complémentaire à l’adoption de licences libres, qui permet aux ingénieurs de résoudre une tension entre trois éléments : la création routinière d’outils personnels dans l’industrie informatique, le régime de propriété qui régit la production logicielle au sein d’une firme et la forte mobilité professionnelle qui caractérise l’informatique marchande. À la manière du retoucheur Demarcy mis en scène par Robert Linhart (1981), qui confectionne et bricole son établi avec soin pour l’adapter à son activité, un programmeur comme Brian Berliner adapte son poste de travail en créant ses propres outils, dont CVS. Or, les ingénieurs changent très régulièrement d’entreprises. Dans la Silicon Valley des années 1980, le turnover annuel est élevé : les estimations varient entre 13 % et 30 % selon les enquêtes, les périodes et les entreprises12. B. Berliner lui-même occupe à Prisma son troisième emploi, quatre ans seulement après la fin de ses études.

33Tout logiciel produit dans le cadre de l’activité salariée appartient légalement à l’employeur, ainsi que le précisent les contrats. Tous les deux ans en moyenne, un ingénieur se voit donc obligé de laisser derrière lui son poste de travail entièrement configuré, adapté à ses propres routines et équipé d’outils qui les automatisent, pour en adopter un nouveau avec lequel il faudra tout reprendre à zéro.

34Jim Blandy, qui a contribué à CVS à partir du milieu des années 1990, se rappelle de la frustration que ses pairs et lui éprouvaient en laissant derrière eux leur boîte à outils.

« Je crois que les gens n’ont aucune idée d’à quel point on était près d’avoir juste plein de petits logiciels enfermés dans plein de petites entreprises, et où cette entreprise-ci ne connaît que ses trucs à elles, et cette entreprise-là ne connaît que les siens ; où si tu veux partager ou emporter quelque chose, il faut appeler tes avocats » (Jim Blandy, ingénieur, fondateur de Cyclic, 22 ans en 1995).

35Faire le choix d’une licence libre, c’est donc extraire stratégiquement son outil de travail du portefeuille technique de son employeur. Voilà pourquoi les ingénieurs insistent autant sur la dichotomie entre les logiciels libres et leur position dans l’industrie. Par exemple, quand je fais remarquer à Walter Tichy qu’il a ébauché CVS pendant qu’il conseillait ITT sur sa gestion de version, il s’empresse de séparer les deux et de préciser qu’il n’a pas utilisé une ligne de code payée par son client. Brian Berliner, qui veut garder la main sur CVS, emploie la même stratégie dichotomique pour convaincre ses employeurs de placer l’outil sous licence libre :

« Environ un an après que j’ai fini CVS, ma start-up a plié bagage. C’est là que je suis retourné voir mes patrons, et je leur ai dit que je voulais rendre CVS public et, en gros, le posséder [to basically own it], si tu veux. Je voulais m’assurer que Sun ne pourrait pas mettre la main dessus, parce que Sun rachetait Prisma et toutes nos technologies. Donc pendant que ma start-up coulait, j’ai dû faire une petite acrobatie juridique pour leur dire : “CVS ne fait pas partie de ça, c’est du logiciel libre, on l’a fait en utilisant le travail de Dick”. Et ça, ça m’a aidé à montrer que voilà, même si on l’a construit, c’est tangentiel à notre modèle économique, ça ne fait pas partie du cœur de nos technologies, c’est juste un outil » (Brian Berliner, ingénieur, start-up, 24 ans en 1989).

36Le vocabulaire de la propriété semble à première vue cocasse dans le contexte d’un logiciel libre, que chacun peut télécharger, modifier et redistribuer librement. L’usage est pourtant répandu : les ingénieurs parlent de les « posséder » (own), d’« en avoir la propriété » (have ownership of it) ou d’« avoir des droits dessus » (have a right to it). Ce sentiment de possession, distinct de la propriété, rappelle l’appropriation du travail par des ouvriers qualifiés qui cherchent à « reprendre une partie de la fonction technique qui, réglementairement, [leur] échappe », par exemple en retirant les pignons d’une boîte de vitesse pour accélérer la production (Bernoux, 1979, p. 78). À cette possession perçue correspond une appropriation effective, puisqu’une fois libre l’outil devient portatif légalement mais aussi techniquement : l’accès au code source permet d’adapter le logiciel à n’importe quel poste de travail.

2.4. Les biens industriels publics, un enjeu professionnel de contrôle de l’expertise

37À l’évidence, le partage des outils libres suggère que les biens industriels publics participent à une forme de propriété collective au-delà de l’appropriation individuelle de l’appareil productif. Mais après tout, les logiciels libres ne sont pas les seuls outils disponibles : les entreprises qui en ont les moyens offrent à leurs employés des outils propriétaires. Face au CVS libre, les géants AT&T et IBM vendent des gestionnaires de version, respectivement SCCS et Clearcase. Pourquoi ces ingénieurs préfèrent-ils les biens industriels publics aux logiciels propriétaires, même quand ils ont accès à ces derniers ?

38Outre l’appropriation qu’offre l’ouverture du code, le motif de la supposée supériorité technique des logiciels libres revient régulièrement dans les entretiens — ce qui a de quoi surprendre quand leurs rivaux propriétaires, vendus à prix d’or, sont conçus dans des entreprises prestigieuses de la Silicon Valley. En examinant la question, ce qui déplaît vraiment dans les gestionnaires propriétaires est qu’ils sont « orientés business », c’est-à-dire élaborés pour convaincre les acheteurs qui sont rarement des ingénieurs, mais plutôt des cadres. L’un décrit leurs fonctionnalités comme « une liste de cases à cocher pour rassurer les managers » ; un autre s’énerve face à leurs « limitations complètement arbitraires ».

39Ces programmes propriétaires, optimaux pour les « commerciaux », sont trop lourds, trop lents et trop peu efficients au goût des informaticiens, car trop éloignés de l’optimisation de leurs routines. Un développeur devenu entrepreneur, amené à fréquenter des cadres qui ne viennent pas de l’ingénierie, ressent une forme de dédain de la part de ces personnes qui « ne savent même pas taper au clavier, et pensent que l’informatique est une tâche de secrétaire améliorée ». Les outils propriétaires symbolisent ainsi une forme d’ingérence illégitime dans ce que les acteurs rencontrés perçoivent comme leur domaine d’expertise, tandis que les logiciels libres intègrent des routines plus proches de leur activité. En définitive, ils affirment une supériorité de la norme technique au sein de l’espace productif.

40Les motivations de ces ingénieurs sont claires, mais cette importation de logiciels libres dans les entreprises n’est-elle pas d’une part empêchée par le droit et, d’autre part, contrariée par leurs supérieurs ? Sur le plan juridique cette importation est parfaitement licite, car les licences libres encadrent la circulation du code, non celle du logiciel. Cette distinction légale reste néanmoins subtile ; dans les faits, les managers peu familiers de la programmation considèrent que tout emploi du libre est dangereux. Comme me le raconte un ancien employé de Sun, leurs avocats « se chient dessus [scared shitless] » à l’idée qu’un de leurs employés puisse inclure, même involontairement, du code libre dans un de leurs produits propriétaires, les exposant à un potentiel procès.

41En dépit de sa légalité, l’importation du libre reste donc étonnante dans la mesure où de nombreux cadres y sont hostiles. Les managers donnent parfois un accord tacite ou explicite, comme les supérieurs de Brian Berliner — une exception, m’explique-t-il, due à leur passé d’ingénieurs qui les rend capables de comprendre son argumentaire. La plupart du temps, à vrai dire, la question de l’accord des managers ne se pose pas. Le portage des logiciels libres se fait en catimini, au nez et à la barbe des cadres. Outre la distance hiérarchique — « ils ne sont pas dans les tranchées », résume un ingénieur —, l’activité informatique reste difficile à contrôler car elle paraît opaque à un regard extérieur, surtout s’il ne sait pas quoi observer. Or la visibilité est un des enjeux majeurs dans le contrôle du travail, par exemple quand des ouvriers du bâtiment surveillent du coin de l’œil les allées et venues des supérieurs pour se mettre en scène le cœur à l’ouvrage au moment opportun (Brochier, 2006). À l’inverse d’un atelier physique, où l’établi singulier d’un ouvrier n’échappe pas à la surveillance du contrôleur qui peut ainsi lui infliger l’usage d’un établi normalisé (Linhart, 1981), le poste de travail des ingénieurs se dérobe aux regards des managers, d’autant plus que les instruments de management du code sont peu développés dans les années 1990. Cette importation discrète des logiciels libres entérine l’hypothèse d’une « entrée par la petite porte », observée en France dans les années 2000 (Vicente, 2015), par laquelle les développeurs confirment le contrôle de leurs outils de travail.

42Les biens industriels publics constituent donc pour les ingénieurs une ressource stratégique dans une lutte de juridiction, c’est-à-dire une lutte pour le contrôle légitime de leur expertise (Abbott, 1988). Ils créent les conditions nécessaires d’un espace propre au sein de l’industrie informatique, où l’expertise est négociée entre pairs, où le rapport opératoire au code n’est pas entravé par une norme étrangère. Les ingénieurs sont nombreux à exprimer leur enthousiasme face aux perspectives qu’ouvrent à cette époque les biens industriels publics pour équiper leur profession.

« Je pense que l’important c’est d’avoir une scène, et comme il y a une scène artistique, une scène rock, une scène musicale, c’est important d’avoir une scène du code. Et [le logiciel libre] c’était cette scène ; bien sûr qu’on voulait y participer » (Jim Blandy, ingénieur, fondateur de Cyclic, 22 ans en 1995).

43En résumé, envisager les logiciels libres comme des biens industriels publics révèle leur pleine intégration à la production logicielle en entreprise, qu’il s’agisse des problèmes d’organisation du travail d’écriture, du rapport artisanal aux codes sources ou des stratégies des ingénieurs pour s’approprier leurs outils et, à travers eux, délimiter le contrôle légitime de leur expertise. Ces biens publics leur ouvrent ainsi un espace d’autonomie professionnelle dans l’industrie, non pas pour affronter l’informatique marchande mais pour mieux y faire leur travail. À la manière des ouvriers étudiés par Philippe Bernoux, qui bravent les règlements et la rationalité de leurs supérieurs au nom de l’optimisation de la production (1972, p. 435), les biens industriels publics comme CVS affranchissent les ingénieurs des contraintes de l’informatique marchande pour mieux produire.

3. L’introuvable valeur marchande des biens industriels publics

44C’est donc pour s’affranchir des normes marchandes que les ingénieurs font le choix de construire des biens industriels publics. Dans cette partie, j’étudierai le revers de la médaille de cette autonomisation qui, si elle augmente la valeur productive des outils, dévalorise son travail pour les entreprises. Je commencerai par examiner les conditions de maintenance de CVS, en différenciant l’importance du travail gratuit selon qu’on parle des contributions ou des contributeurs (3.1). Je discuterai alors de la difficulté de séparer le travail gratuit du travail rémunéré, en ce qui concerne le temps et les ressources utilisées (3.2). Ensuite, je proposerai deux pistes explicatives pour éclairer le refus des cadres d’adopter les logiciels libres et gratuits, une décision a priori irrationnelle du point de vue économique. Je reviendrai d’abord sur le manque d’institutions marchandes identifiables, qui encourage les ingénieurs qui veulent vivre du libre à se constituer en entreprises (3.3). Enfin, j’évoquerai la difficulté pour les ingénieurs de valoriser leur production quand le fruit de leur travail est gratuit (3.4).

3.1. Travail gratuit et logiciels libres : règle ou exception ?

45Pour comprendre dans quelles conditions de travail s’effectue la maintenance de CVS, j’ai utilisé le journal des modifications du logiciel (changelog) afin de passer en revue les 466 contributions effectuées entre 1990, date de la première version officielle, et 2000, quand un autre logiciel libre nommé SubVersion (SVN) a pris la relève. Le journal se compose de plusieurs entrées, chacune datée et attribuée à un auteur individuel, que j’appelle ici contributions. Les entrées comportent aussi un bref message rédigé par l’auteur qui liste les modifications que sa contribution introduit. Pour chacun des quarante auteurs, j’ai repéré l’employeur principal, ce qui permet d’établir un lien entre les contributions et la position des contributeurs dans l’industrie informatique.

46Afin de présenter des résultats synthétiques (tableau 1), j’ai regroupé les employeurs en trois catégories : les universités (seulement 6 contributions en dix ans), les entreprises dont le modèle économique repose sur la vente de logiciels propriétaires (58 contributions, soit 12 %) et les entreprises qui proposent des services en lien avec les logiciels libres (402 contributions, soit 87 %). L’une d’entre elles, la start-up californienne Cygnus, est d’ailleurs la première à avoir mis en œuvre ce modèle économique dès sa création en 1989, en proposant des services variés (installation, support technique, correction de bogues, améliorations spécifiques) en lien avec des outils libres, comme des éditeurs ou des compilateurs. La start-up a connu une importante croissance économique, culminant dix ans plus tard avec son acquisition pour plusieurs millions de dollars par une entreprise similaire, RedHat. Au sein des entreprises du libre qui emploient des contributeurs de CVS, la petite entreprise Cyclic se distingue nettement, puisque ses employés sont responsables des trois quarts des contributions. Créée au milieu des années 1990 par d’anciens employés de Cygnus, Cyclic vend uniquement des services liés à CVS.

Tableau 1. Répartition entre employeurs des contributions à CVS de 1990 à 2000

Tableau 1. Répartition entre employeurs des contributions à CVS de 1990 à 2000

Lecture : entre 1990 et 2000, 4 contributeurs employés par des universités (soit 9 % de l’ensemble) ont effectué 6 contributions ponctuelles à CVS (soit 1 % de l’ensemble), apportant chacune 2,67 changements au logiciel en moyenne (contre 2,38 pour l’ensemble des contributions).

47Bien sûr, le rôle et la place de l’employeur dans le processus de contribution diffèrent considérablement selon les entreprises. Plus des trois quarts des apports à CVS sont le fruit du travail des sept ingénieurs de Cyclic, qui travaillent à temps plein sur cette tâche. Les trois plus productifs sont également les patrons de l’entreprise, dont Jim Blandy et Jim Kingdon. Quant aux quatre autres, ils ont été embauchés pour de plus courtes durées, le plus souvent en tant qu’indépendants. En ce qui concerne les onze autres employés d’entreprises du libre, dont huit travaillent pour Cygnus, leurs contributions se font majoritairement durant leur temps de travail et dans le cadre de leur activité professionnelle. Même si ces entreprises ne proposent pas de services en lien direct avec CVS, leurs employés utilisent tous le gestionnaire libre comme outil de travail et participent ainsi à son amélioration. En entretien, les fondateurs de Cygnus confirment que leurs employés procédaient à ces modifications avec leur accord. Enfin, les 13 % de contributions restantes, réalisées par des salariés d’entreprises au modèle économique propriétaire et d’universités, relèvent probablement pour la plupart du travail gratuit. Mais même dans ces cas-là, les messages échangés sur la liste de discussion et les entretiens soutiennent l’hypothèse d’une continuité avec la pratique professionnelle, le cas typique étant celui du bogue que l’ingénieur rencontre au travail et règle sur son temps libre. D’une manière générale, un grand nombre de développeurs découvrent CVS dans les années 1990, notamment parce que des outils libres populaires l’adoptent pour leur gestion de version.

48Cette analyse révèle que la production de CVS est le fruit d’une combinaison de travail rémunéré et de travail gratuit, de contributions régulières d’une entreprise qui l’a placé au centre de son modèle économique et de corrections ponctuelles d’ingénieurs d’autres firmes qui l’utilisent comme un outil. De plus, cette combinaison a connu plusieurs configurations qui évoluent au cours du temps, comme l’indique la figure 1.

Figure 1. Évolution des contributions à CVS de 1990 à 2000. Analyse des 466 contributions

Figure 1. Évolution des contributions à CVS de 1990 à 2000. Analyse des 466 contributions

Source des données : Changelog CVS ; auteur de la figure : G. Alcaras.

49Quatre phases semblent se dégager. Entre 1990 et 1993, les contributions sont réalisées par des employés d’entreprises de la Silicon Valley ; elles sont peu régulières mais comportent chacune beaucoup de modifications. C’est principalement Brian Berliner, désormais employé de Sun Microsystems après le rachat de Prisma, qui coordonne la maintenance sur son temps libre. Ses contributions personnelles sont rares, car il n’utilise CVS qu’occasionnellement chez Sun ; il collecte toutefois les apports que d’autres ingénieurs lui envoient. À partir de 1993, les contributions deviennent majoritairement le fait d’employés de Cygnus qui utilisent CVS comme outil de production. En 1995, deux de ces ingénieurs décident de fonder Cyclic en imitant le modèle économique de leur ancien employeur, à savoir proposer des services autour d’outils libres, mais en se concentrant exclusivement sur CVS. C’est sous l’impulsion de Cyclic que CVS connaît son rythme de croissance le plus régulier. Enfin, en 1998, le rythme des contributions s’essouffle. Cyclic met la clé sous la porte en 1999, tandis que trois de ses anciens développeurs sont recrutés pour créer SubVersion, le successeur de CVS.

50Ces éléments quantitatifs brossent le portrait d’une collaboration entre ingénieurs de plusieurs entreprises, rappelant l’un des sens originels du concept de bien industriel public. S’ils mettent en cause le mythe d’un logiciel libre fondé sur le bénévolat, force est de constater qu’au moins la moitié des contributeurs n’ont pas été directement rémunérés. Dès lors, comment déterminer si le travail gratuit constitue la règle ou l’exception ? Pour ce faire, l’interprétation des résultats doit tenir compte de la distribution des tâches dans un groupe donné. Dès 1992, des chercheurs montrent qu’en ligne, cette distribution suit une loi de puissance (Hill et al., 1992), un phénomène maintes fois confirmé depuis lors. À ce titre, les logiciels libres n’ont donc rien de particulier : un petit noyau de personnes, souvent au cœur de l’organisation du travail, est responsable de la majeure partie de l’activité effective (Demazière et al., 2007). Ainsi, même si au moins 87 % des contributions à CVS ont été rémunérées, cela représente seulement 43 % des contributeurs. Un bien industriel public peut donc être essentiellement construit par du travail rémunéré, tout en mobilisant des professionnels qui, eux, fournissent en général un travail gratuit.

3.2. Les ressources marchandes au service des logiciels libres

51L’utilisation des logiciels libres en entreprise est fréquemment étudiée sous l’angle de l’exploitation de ressources produites bénévolement. J’aimerais compléter ce questionnement en proposant de considérer un instant le phénomène inverse : comment les ingénieurs utilisent-ils les ressources de leur entreprise et leur temps salarié pour contribuer à la production de biens industriels publics ?

52J’ai insisté dans la première partie de ce texte sur l’intérêt de la portabilité des logiciels libres pour les ingénieurs. Un ingénieur habitué à EMACS, un éditeur de code qui intègre CVS, raconte comment il a emporté cet outil avec lui dans son nouvel emploi.

« Ils voulaient que je bosse sur une station de travail Sun Microsystems. Donc une des premières choses que j’ai faites, c’est de trouver une version open source d’EMACS qui pourrait tourner vite et simplement sur cette machine standard. J’ai commencé à chercher autour de moi. Je n’avais pas accès à Internet à l’époque, j’ai donc demandé aux gens autour de moi, dans le coin, et j’ai trouvé quelqu’un qui était prêt à me donner une cassette de la version 18 point… 7 je crois, quelque chose comme ça, avec le code source d’EMACS, et je pouvais essayer de le porter par moi-même. Et c’est ce que j’ai fait » (Mark Baushke, ingénieur, entreprise de Télécom, 32 ans en 1992).

53Personnaliser sa station de travail requiert d’adapter le code de l’outil lui-même. Une fois le portage réalisé, Mark Baushke le partage sur la liste de discussion dédiée pour en faire bénéficier les autres personnes qui souhaiteraient utiliser EMACS sur leur poste Sun. Sans accès à ce système payant fourni par l’employeur de M. Baushke, l’éditeur de code libre n’aurait sans doute pas bénéficié de ce gain de portabilité. Bon nombre de contributions substantielles aux biens industriels publics sont dues à cette importation de logiciels libres dans un système propriétaire. De plus, les ingénieurs réalisent ces contributions à l’aide des ressources matérielles de leurs employeurs, surtout à une époque où les machines puissantes, l’accès au réseau et les adresses email sont encore relativement rares. De la même façon que l’emploi de code libre a tendance à être invisibilisé dans les entreprises, le contexte de production industriel tend à disparaître du logiciel libre.

54L’insertion du libre dans l’informatique marchande suscite un double mouvement : d’un côté, des salariés cherchent à optimiser leurs routines en important des outils gratuits ; de l’autre, l’accès aux infrastructures propriétaires de leur employeur motive et rend possible leur contribution au libre, à titre personnel et bénévole. Ainsi cette importation se présente-t-elle tantôt comme un avatar de la « perruque » ouvrière (Certeau, 1990), tantôt comme sa forme inversée.

55Définie comme « l’utilisation de matériaux et d’outils par un travailleur, sur le lieu de travail et pendant le temps de travail, dans le but de fabriquer un objet en dehors de la production de l’entreprise », la perruque a pour finalité de produire un objet destiné au monde privé des ouvriers, ce qui pour l’entreprise s’apparente à un vol de temps et de ressources (Anteby, 2003). Au premier abord, le portage des biens industriels publics se présente comme une perruque inversée : apporter dans l’entreprise un outil développé en dehors des normes marchandes de celle-ci, afin de mieux travailler. Dans le cas de Mark Baushke, cette importation demande de prendre sur son temps libre, ne serait-ce que pour se procurer une copie d’EMACS. En même temps, il détourne sans conteste les ressources de son employeur, à commencer par le poste de travail, et consacre une partie de son temps salarié à améliorer un logiciel que son employeur ne pourra pas commercialiser. Démêler le travail gratuit du salariat s’avère impossible dans la situation d’importation, aussi bien dans son expérience subjective — M. Baushke poursuit-il ses intérêts, ceux de son groupe professionnel ou bien ceux de son entreprise ? — que dans ses propriétés objectives, comme le temps de travail ou les ressources matérielles. Cette constatation ne met pas en cause l’existence de formes plus franches de travail gratuit ou rémunéré, mais souligne à mon sens tout l’intérêt d’envisager leurs continuités et leurs coexistences au sein de l’industrie informatique.

3.3. Marchander pour exister

56Ce même thème de l’exploitation du travail gratuit se heurte à une difficulté supplémentaire : l’absence d’intérêt presque totale ou, pis encore, l’hostilité avouée des exécutifs de la Silicon Valley envers le logiciel libre. Si, comme l’expliquent certains travaux d’économie, les outils libres sont au moins aussi efficaces que leurs concurrents propriétaires, une analyse coût-bénéfice simple ne recommanderait-elle pas d’adopter le logiciel libre en masse pour baisser les coûts de production et capter la valeur du travail gratuit ?

57À la fin des années 1990, l’entreprise de Mark Baushke abandonne CVS et le remplace par un concurrent propriétaire, Clearcase, édité par IBM. En sa qualité de contributeur à CVS et d’expert technique de la gestion de versions, l’ingénieur est invité aux réunions qui précèdent cette prise de décision.

« La boîte avait commencé à abandonner CVS, pourquoi pas, ils passaient à Clearcase. Je l’avais évalué et je pensais qu’ils avaient pris leur décision trop vite. À l’époque, le code de Clearcase était fermé, ça allait demander beaucoup de matériel et la flexibilité qu’on aurait eue avec un projet open source n’était pas là. [...] Bon, ce que j’en dirai, c’est que c’était un choix business, ils avaient beaucoup d’argent qu’ils pouvaient dépenser pour du vrai support, ils n’aimaient pas l’idée que des bénévoles pourraient avoir une place clé dans ce qui était la maintenance du code très, très fermé de leur système. Donc leur raisonnement business, sur le papier, ça faisait sens. Ils disaient : “Bon, si notre contrat à un million de dollars se passe mal on pourra toujours rejeter la faute sur eux, mais on ne peut pas faire ça si c’est open source, parce qu’on maintient notre propre copie”. Et donc ils ont dépensé beaucoup d’argent pour avoir le matériel dont ils avaient besoin, je ne sais pas exactement combien de millions de dollars ça a fait à la fin, mais c’était plusieurs millions de dollars pour le support de Clearcase et pour le matos qu’il fallait pour le faire tourner. C’étaient pas des sommes qu’on aurait eues avec un projet open source » (Mark Baushke, ingénieur, entreprise de Télécom, 39 ans en 1999).

58Loin d’être interprétée comme un coût nul, la gratuité de CVS signale que l’outil s’inscrit en dehors de l’économie marchande et de ses garanties incarnées par le fameux contrat de support. Je ne reviens pas ici sur les raisons pour lesquelles l’ingénieur préfère manifestement CVS à Clearcase, car elles recoupent celles que j’ai évoquées précédemment (voir notamment les parties 2.3 et 2.4). S’il est clair que M. Baushke désapprouve la décision, il ne disqualifie pas la justification donnée par les cadres, peut-être parce qu’il est entre-temps devenu lui-même un manager. Dans de nombreuses entreprises, des ingénieurs sont prêts à voir leur firme adopter officiellement des infrastructures libres, ce qui dépasse largement le cadre de l’importation personnelle. Mais pour cela, il faut convaincre les cadres dont l’exigence d’assurances attendues sur le marché du logiciel propriétaire n’est pas satisfaite par les logiciels libres. L’absence perçue d’obligations contractuelles formelles, d’ingénieurs dédiés et d’une institution marchande empêche encore le libre d’entrer dans l’informatique marchande par la grande porte.

59C’est pour combler ce fossé que se forment les entreprises du libre comme Cygnus et Cyclic. Pour faire officiellement exister les biens industriels publics, des ingénieurs choisissent d’entrer dans le jeu marchand, non sans difficulté. Les fondateurs de Cygnus, qui poursuivent un modèle de croissance rapide, peuvent rapidement investir dans une équipe de vente dédiée. À l’inverse, les fondateurs de Cyclic souhaitent avant tout pouvoir vivre décemment du seul développement de logiciels libres. Dans la petite entreprise, ce sont donc les ingénieurs qui assurent eux-mêmes le processus de vente.

  • 13 Parfois traduit par « argumentaire éclair » en français, le pitch est une pratique ritualisée de l’ (...)

60Comme pour les artisans d’art, l’apprentissage des compétences et des normes marchandes n’est pas chose aisée (Jourdain, 2014b). Après plusieurs expériences décourageantes auprès de cadres, Jim Kingdon se trouve si mal à l’aise avec la pratique du pitch13 qu’il décide de s’adresser plutôt à ses semblables :

« Le processus de vente partait d’en bas, tu vois, en gros j’essayais de convaincre les ingénieurs qui ensuite vont convaincre leur boss que c’est bon » (Jim Kingdon, ingénieur, patron de Cyclic, 24 ans en 1995).

61Il rencontre des ingénieurs lors de conventions, par des connaissances ou via son site web. Quand ils ne connaissent pas CVS, il leur vante la qualité et l’ouverture du code. À ceux qui s’en servent déjà discrètement ou qui voudraient convaincre un manager récalcitrant, J. Kingdon présente son entreprise comme un moyen de rassurer leurs supérieurs. Cyclic assume le rôle de vitrine institutionnelle de CVS, même si celui-ci est développé en pratique par un ensemble bien plus large de contributeurs. Surtout, Cyclic propose un contrat de support pour venir à l’aide de ses clients en cas de problème technique — ou, du moins, un semblant de support.

« Ça, c’était la théorie, c’était ce qui était écrit [dans le contrat] : “vous nous envoyez un rapport de bug et on le réparera ; vous nous demandez comment l’utiliser et on vous l’expliquera”, des choses de ce genre. En pratique, ce qu’on faisait surtout, c’était donner [aux ingénieurs] un moyen pour que leur employeur fasse un don à [ce logiciel libre] qui pour eux le valait bien, ou alors c’était une forme d’assurance, un moyen de se sentir bien, ou encore c’était une manière de dire à ton entreprise : “ça va, on peut utiliser ce truc, c’est pas comme si quand quelque chose va casser, on sera sans recours”. Finalement il s’est avéré que la majorité des gens qui voulaient ces contrats de support technique ne les ont jamais utilisés comme ça » (Jim Kingdon, ingénieur, patron de Cyclic, 24 ans en 1995).

62Ce modèle économique du service proposé autour du logiciel libre joue sur les normes marchandes, en effectuant un étonnant tour de passe-passe. Cyclic vend aux cadres un contrat de support qui les convainc d’adopter un logiciel, peu importe qu’il soit libre ou non. Mais pour les ingénieurs qui l’utiliseront, c’est justement l’ouverture du code qui fait son intérêt, alors que le support est secondaire et presque superflu. Par conséquent, les ingénieurs sollicitent peu Cyclic pour cette tâche et, in fine, l’argent récolté au nom du support finance le vrai travail de développement de CVS, une tâche que les cadres associent au bénévolat et n’auraient pas voulu rémunérer au départ. Aux yeux des ingénieurs, ce jeu sur les normes du marché logiciel n’est pas assimilable à une arnaque, car il finance un bien industriel public qui, certes, n’a pas de valeur marchande, mais a une valeur productive certaine.

3.4. Les biens industriels publics dans l’impasse de la gratuité

63Munis du sésame du contrat de support, les premiers entrepreneurs du libre sont persuadés d’avoir tous les arguments pour entrer dans les entreprises de la Silicon Valley par la grande porte. Les créateurs de Cygnus fondent initialement leur stratégie commerciale sur un argument coût-bénéfice selon eux incontestable. Puisque les outils libres sont gratuits, ils envisagent de casser les prix du marché avec un service bien moins coûteux, pour une prestation jugée équivalente, voire supérieure. Mais ils sont rapidement confrontés aux moqueries ou à l’incompréhension des potentiels clients :

« Les gens pensaient qu’on essayait de leur vendre quelque chose qui ne valait rien, c’est-à-dire une arnaque, ou que nos produits et nos services ne valaient rien », raconte John Gilmore, l’un des fondateurs.

64Quelques années plus tard, le terme de free software (logiciel libre) disparaît définitivement de leurs brochures publicitaires pour échapper au stigmate de la gratuité.

65Là où la gratuité de CVS inquiète, le prix élevé de Clearcase rassure. Face à l’opacité du code propriétaire, ce sont les prix et leurs différentiels qui guident l’estimation de la valeur (Boltanski et Esquerre, 2016), y compris pour Jim Kingdon, l’ingénieur alors à la tête de Cyclic et l’un des principaux contributeurs de CVS :

« À l’époque, mon état d’esprit c’était : “Oh punaise, je dois rattraper Clearcase” et purée, rétrospectivement, j’étais tellement hors sujet. […] J’étais super inquiet : “Mais comment je vais bien pouvoir construire un truc comme ça ? C’est tellement de travail”. Et puis j’en ai parlé à des clients potentiels et ils étaient en mode “Ouais non, on n’a jamais réussi à faire fonctionner ce truc” […] C’était un cas classique du gorille de quatre cents kilos qui est nu. Quand tu vois une étiquette avec un prix aussi élevé, tu te dis “Ben ça doit être solide” » (Jim Kingdon, ingénieur, patron de Cyclic, 24 ans en 1995).

66Contraintes de fixer un prix de vente pour leurs contrats de support, les deux entreprises sont rapidement confrontées à la difficulté de traduire la valeur technique en termes marchands. Au départ, les deux entreprises adoptent des tarifs plus bas que leurs concurrents. Objets d’une stratégie commerciale pour les fondateurs de Cygnus, ces tarifs reflètent au contraire pour les développeurs de Cyclic leur difficulté à affirmer que leur travail, dont le produit est gratuit et qui a toujours été perçu comme bénévole, vaut autant que celui d’un ingénieur d’une grande firme comme Sun.

67Près de 25 ans plus tard, la valeur productive des biens industriels publics s’accompagne d’une forte valeur marchande, comme en attestent les investissements de plusieurs milliards de dollars que je mentionnais dans l’introduction. Pendant notre entretien, Jim Kingdon est revenu, non sans amertume, sur ses évaluations monétaires de l’époque, qu’avec le recul il juge trop basses. Tiraillé entre l’évidence rétrospective qu’il aurait pu valoriser davantage son propre travail et la certitude que cette évolution était alors impensable, il s’exclame :

« Mais c’est quoi la valeur des choses ? [But, what is anything worth?] C’est seulement des années plus tard que j’ai compris que le nom Cyclic, ou que le fait que j’étais d’une certaine façon responsable de CVS, valait quelque chose » (Jim Kingdon, ingénieur, patron de Cyclic, 24 ans en 1995).

4. Conclusion

68Ces considérations sur le chemin parcouru par les logiciels libres m’amènent à envisager les prolongements de cette recherche et, plus largement, les possibilités qu’ouvre l’étude de biens industriels publics. J’ai montré que ces derniers sont d’ores et déjà intégrés à l’industrie informatique des années 1980 et 1990, surtout en ce qui concerne l’activité de production de logiciels marchands et le contrôle de l’expertise. En la matière, Git, le principal gestionnaire de version libre actuel, s’inscrit plus que CVS ne l’a jamais été dans les pratiques des ingénieurs, tant il est devenu un véritable standard de la collaboration logicielle, utilisé ouvertement par Microsoft et Google.

69En revanche, force est de constater que l’insertion des biens industriels publics est beaucoup plus visible aujourd’hui. Tandis qu’une faille comme Heartbleed révèle l’étendue de leur emploi dans les infrastructures numériques, les milliards de dollars investis par Microsoft rassurent sur leur valeur marchande, encore introuvable dans les années 1980, et leur confère ainsi une nouvelle légitimité dans l’informatique marchande. Même si les ingénieurs de Cygnus ou de Cyclic parviennent à vivre du développement libre, c’est au prix de négociations ardues et de stratagèmes alambiqués. Aujourd’hui, Microsoft et d’autres rémunèrent directement des ingénieurs pour développer et maintenir Git, sans s’embarrasser de la question du support. C’est ce renversement remarquable qu’il faudrait explorer dans de futures recherches, en gardant à l’esprit les enjeux identifiés par les premiers biens industriels publics : rapport opératoire aux codes, appropriation de l’appareil productif, contrôle de l’expertise technique, continuité entre travail gratuit et rémunéré, reconnaissance de la valeur d’une production non marchande.

70À cette piste historique s’ajoute celle de l’exploration d’autres types de biens industriels publics. Si j’ai fait le choix d’étudier ici des outils libres de programmation, il serait tout aussi intéressant d’analyser des logiciels libres qui ne sont pas destinés aux ingénieurs, en interrogeant leurs rapports à l’informatique marchande depuis leur position dans l’industrie informatique. Par exemple, dans le cas de SPIP que je mentionnais en introduction, l’intérêt du « principe de désintéressement » pourrait être utilement éclairé par les positions et les expériences des différents membres du projet dans l’industrie informatique. Au-delà des logiciels libres, le concept de bien industriel public pourrait utilement informer les enquêtes sur le régime de production de valeurs de l’open science ou des données massives ouvertes de l’open data (Didier, 2018).

 

Haut de page

Bibliographie

Abbott, A., 1988, The System of Professions: An Essay on the Division of Expert Labor, University of Chicago Press, Chicago.

Angel, D. P., 1991, « High-technology agglomeration and the labor market: The case of Silicon Valley », Environment and Planning A: Economy and Space, vol. 23, n° 10, p. 1501-1516.

Anteby, M., 2003, « La “perruque” en usine : approche d’une pratique marginale, illégale et fuyante », Sociologie du travail, vol. 45, n° 4, p. 453-471.

Auray, N., 2013, « Enquête sur les institutions. Le hacker, l’État et la politique », Mémoire pour l’habilitation à diriger des recherches, Télécom ParisTech, Paris.

Bernoux, P., 1972, « Les O.S. face à l’organisation industrielle », Sociologie du travail, vol. 14, n° 4, p. 410-436.

Berrebi-Hoffmann, I., Bureau M.-C., Lallement, M., 2018, Makers. Enquête sur les laboratoires du changement social, Le Seuil, Paris.

Berry, D., 2008, Copy, Rip, Burn: The Politics of Copyleft and Open Source, Pluto Press, Londres.

Bidet, A, 2011, L’engagement dans le travail. Qu’est-ce que le vrai boulot ?, Presses universitaires de France, Paris.

Bidet, A., Boutet, M., Le Bianic, T., Minh Fleury, O., Palazzo, C., Rot G., Vatin F., 2003, « Le sens de la mesure », Terrains & travaux, vol. 4, n° 1, p. 207-214.

Boltanski, L., Esquerre A., 2016, « L’énigmatique réalité des prix », Sociologie, vol. 7, n° 1, p. 41-58.

Boyle, J., 2003, « The second enclosure movement and the construction of the public domain », Law and Contemporary Problems, vol. 66, n° 1, p. 33-74.

Broca, S., 2013, Utopie du logiciel libre. Du bricolage informatique à la réinvention sociale, Le Passager clandestin, Neuvy-en-Champagne.

Broca, S., Coriat, B., 2015, « Le logiciel libre et les communs. Deux formes de résistance et d’alternative à l’exclusivisme propriétaire », Revue internationale de droit économique, vol. 29, n° 3, p. 265-284.

Brochier, C., 2006, « Le contrôle du travail par les ouvriers : analyses à partir d’observations participantes », Sociologie du travail, vol. 48, n° 4, p. 525-544.

Certeau, M. de, 1990, L’invention du quotidien. Volume 1, Gallimard, Paris.

Coleman, G., 2012, Coding Freedom: The Ethics and Aesthetics of Hacking, Princeton University Press, Princeton.

Dagiral, É., Martin, O., 2017, « Liens sociaux numériques. Pour une sociologie plus soucieuse des techniques », Sociologie, vol. 8, n° 1, en ligne : http://journals.openedition.org/sociologie/3149.

Demazière, D., Horn, F., Zune, M., 2007, « Des relations de travail sans règles ? L’énigme de la production des logiciels libres », Sociétés contemporaines, vol. 66, n° 2, p. 101-125.

Demazière, D., Horn, F., Zune, M., 2011, « Ethnographie de terrain et relation d’enquête. Observer les “communautés” de logiciels libres », Sociologie, vol. 2, n° 2, p. 165-183.

Demazière, D., Horn, F., Zune, M., 2013, « Concilier projet militant et réussite économique du produit. Le cas des logiciels libres », Réseaux, n° 181, p. 25-50.

Desbois, D., Jullien, N., Pénard, T., Poulain-Maubant, A., Vétois, J., Zimmermann, J.-B., 1999, « Logiciels libres : de l’utopie au marché », Terminal, n° 80-81, p. 3-8.

Desrosières, A., 2013, « Chapitre 1. La statistique, outil de gouvernement et outil de preuve. Introduction », in Desrosières, A., Pour une sociologie historique de la quantification. L’Argument statistique I, Presses des Mines, Paris, p. 7-20.

Didier, E., 2018, « Open-access genomic databases: A profit-making tool? », Historical Studies in the Natural Sciences, vol. 48, n° 5, p. 659-672.

Gaborieau, D., 2017, « Quand l’ouvrier devient robot. Représentations et pratiques ouvrières face aux stigmates de la déqualification », L’Homme et la société, n° 205, p. 245-268.

Hill, W., Hollan J., Wroblewski, D., McCandless T., 1992, « Edit wear and read wear », Proceedings of the SIGCHI conference on Human factors in computing systems – CHI ‘92, p. 3-9.

Jourdain, A., 2014a, Du cœur à l’ouvrage. Les artisans d’art en France, Belin, Paris.

Jourdain, A., 2014b, « L’origine sociale de la vigilance entrepreneuriale. Quand les artisans d’art se font entrepreneurs », Sociologie du travail, vol. 56, n° 3, p. 279-297.

Jullien, N., Zimmermann, J.-B., 2013, « Le logiciel libre : un renouveau du modèle industriel coopératif de l’informatique », in Paloque-Berges, C., Masutti, C., Histoires et cultures du Libre. Des logiciels partagés aux licences échangées, Framasoft, p. 135-164.

Kelty, C., 2008, Two Bits: The Cultural Significance of Free Software, Duke University Press, Durham.

Lallement, M., 2015, L’âge du faire. Hacking, travail, anarchie, Le Seuil, Paris.

Le Crosnier, H., 2018, « Communs numériques et communs de la connaissance. Introduction », TIC & société, vol. 12, n° 1, p. 1‑12.

Linhart, R., 1981, L’Établi, Les Éditions de Minuit, Paris.

Perrin, C., 2017, « Un ordre économique sans machine ? Penser et repenser l’artisanat et la société française au XXe siècle », L’Homme et la société, n° 205, p. 185-209.

Polanyi, K., 1977, The Livelihood of Man, Academic Press, New York.

Pudal, R., 2016, Retour de flammes, La Découverte, Paris.

Romer, P. M., 1993, « Implementing a national technology strategy with self-organizing investment boards », Brookings Papers on Economic Activity, Microeconomics, vol. 1993, n° 2, p. 345-399.

Schwint, D., 2005, « La routine dans le travail de l’artisan », Ethnologie française, vol. 35, n° 3, p. 521-529.

Simonet, M., 2018, Travail gratuit : la nouvelle exploitation ?, Textuel, Paris.

Star, L., 1999, « The Ethnography of Infrastructure », American Behavioral Scientist, vol. 43, n° 3, p. 377-391.

Vicente, M., 2015, « Les parcours des développeurs de logiciels libres : vecteur de diffusion d’une innovation sociale », Sociologies pratiques, vol. 31, n° 2, p. 55-64.

Zelizer, V., 2001, « Transactions intimes », Genèses, n° 42, p. 121-144.

Haut de page

Annexe

Annexe 1 : Glossaire

— Logiciels —

BSD : Berkeley Software Distribution, un système d’exploitation.

Clearcase : Un gestionnaire de version propriétaire, créé en 1992, aujourd’hui propriété d’IBM.

CVS : Concurrent Versions System, un gestionnaire de version libre fondé sur RCS, publié par Brian Berliner en 1989 à partir de scripts réalisés par Dick Grune en 1986.

EMACS : Editor MACroS, un éditeur de texte et de code source, intégrant CVS.

Git : Un gestionnaire de version libre créé en 2005, devenu le standard actuel de l’industrie informatique.

OpenSSL : Un logiciel libre de chiffrement des communications sur Internet.

RCS : Revision Control System, un gestionnaire de version libre créé en 1982 par Walter Tichy, sert de base à CVS.

SCCS : Source Code Control System, un gestionnaire de version propriétaire publié en 1977.

SPIP : Système de Publication pour l’Internet, un logiciel libre de publication de sites web.

SVN : SubVersion, un gestionnaire de version libre qui prend la relève de CVS au début des années 2000.

TCP/IP : Transmission Control Protocol / Internet Protocol, un ensemble de protocoles permettant à une machine de se connecter à un réseau.

— Sociétés —

AT&T : American Telephone & Telegraph, une entreprise de télécomunnications.

Cyclic : Une petite entreprise créée en 1995, vend des services associés à CVS, présidée par Jim Blandy puis Jim Kingdon.

Cygnus : Une start-up pionnière dans la vente de service associée aux logiciels libres, co-fondée en 1989 par John Gilmore.

IBM : International Business Machines Corporation.

ITT : International Telephone and Telegraph, une entreprise de télécommunications, embauche brièvement Walter Tichy en 1979 pour améliorer sa gestion de versions.

Prisma : Start-up de la fin des années 1980, emploie Brian Berliner pendant la création de CVS.

Sun : Sun Microsystems, co-fondée en 1982 par Bill Joy. En entretien, les ingénieurs la présentent souvent comme « le Google des années 80 » pour souligner son prestige.

Annexe 2 : Personnes citées

Mark Baushke : Ingénieur, contributeur puis mainteneur de CVS dans les années 1990 et 2000.

Brian Berliner : Ingénieur, employé de Prisma puis de Sun Microsystems, crée la première version officielle de CVS en 1989 à partir des scripts de Dick Grune.

Jim Blandy : Ingénieur, employé de Cygnus, fonde sa propre société Cyclic en 1995, contributeur clef de CVS, participe à la création de son successeur SVN.

Frank DeRemer : Professeur d’informatique, s’intéresse à l’industrialisation de l’informatique, influent auprès de W. Tichy.

John Gilmore : Ingénieur, militant, fonde la société Cygnus en 1989.

Dick Grune : Professeur d’informatique, crée les premiers scripts de CVS en 1986.

Bill Joy : Ingénieur, célèbre pour son travail sur le système BSD, fonde la société Sun Microsystems en 1982.

Jim Kingdon : Ingénieur, passé par la Free Software Foundation, employé de Cygnus, puis patron de sa propre société Cyclic.

Richard Stallman : Fondateur du mouvement du logiciel libre et de la Free Software Foundation dans les années 1980.

Walter Tichy : Professeur d’informatique, crée le premier gestionnaire de version libre RCS en 1982.

Haut de page

Notes

1 Sauf mention contraire, les citations en anglais sont traduites par mes soins.

2 En 2018, Microsoft a fait l’acquisition de l’entreprise Github, basée à San Francisco et devenue centrale dans les mondes du libre et de l’entreprise, pour la coquette somme de 7,5 milliards de dollars.

3 Lionel Maurel, « Les Communs numériques sont-ils condamnés à devenir des “Communs du capital” ? », publié le 24 juin 2018 sur le blog « Scinfolex », https://scinfolex.com/2018/06/24/les-communs-numeriques-sont-il-condamnes-a-devenir-des-communs-du-capital/, consulté le 16 avril 2019.

4 La revue française Terminal a été précurseuse en la matière, avec son numéro spécial de 1999 : « Logiciels libres : de l’utopie au marché » (Desbois et al., 1999).

5 Par exemple, les effectifs des pompiers sont composés à 78 % de « volontaires », ceux-ci dépassant donc largement les effectifs de pompiers fonctionnaires et militaires (Pudal, 2016).

6 Je précise que mon usage du masculin dans le texte n’obéit pas à une règle de primauté du masculin sur le féminin, mais reflète la composition exclusivement masculine de l’échantillon étudié, qu’il s’agisse des entretiens ou de la collecte de données.

7 Certains cumulent les positions ou passent de l’une à l’autre au cours de leur carrière, c’est pourquoi les effectifs entre parenthèses dépassent les dix entretiens annoncés.

8 Lorsque je cite les propos des développeurs, je précise entre parenthèses leur statut, leur employeur et leur âge au moment des faits relatés. J’utilise également leur véritable nom. Étant donné la spécificité des situations techniques que je présente et le degré d’interconnaissance de ce petit milieu, l’anonymisation ne résisterait pas longtemps à l’examen. Enfin, contrairement à d’autres activités en ligne réputées pour leur anonymat ou leur pseudonymat, les développeurs de logiciel libre utilisent souvent leur nom réel, parfois même leur adresse électronique professionnelle. Habitués à s’exprimer publiquement en leur nom propre, au moins par écrit, les ingénieurs que je rencontre refusent presque systématiquement ma proposition d’anonymiser leur parole.

9 Le terme de « main » ne désigne évidemment pas le corps des informaticiens, pas plus que l’adjectif « manuel » ne suggère une manipulation physique de leur part. Il s’agit plutôt de ce qu’ils perçoivent comme « manuel » parmi les tâches qu’ils effectuent sur l’ordinateur, celles qui ne sont pas encore automatisées.

10 Brian Berliner publie la première version officielle de CVS en 1989, sur le groupe USENET com.sources.unix. Consultées en avril 2020, les sources sont accessibles sur l’archive suivante : http://sources.vsta.org/comp.sources.unix/volume22/cvs-berliner/.

11 Par exemple, « je fais ça comme ça parce que c’est BEAUCOUP plus efficace… Faites-moi confiance ».

12 Sources : Angel, 1991, et les chiffres de l’American Electronics Association rapportés dans « Turnover rate down: AEA », Computerworld, édition du 6 août 1984.

13 Parfois traduit par « argumentaire éclair » en français, le pitch est une pratique ritualisée de l’entrepreneuriat dans la Silicon Valley. Il consiste à présenter son produit ou son entreprise auprès d’un potentiel client ou investisseur, le tout en un temps limité — parfois en moins d’une minute.

Haut de page

Table des illustrations

Titre Tableau 1. Répartition entre employeurs des contributions à CVS de 1990 à 2000
Légende Lecture : entre 1990 et 2000, 4 contributeurs employés par des universités (soit 9 % de l’ensemble) ont effectué 6 contributions ponctuelles à CVS (soit 1 % de l’ensemble), apportant chacune 2,67 changements au logiciel en moyenne (contre 2,38 pour l’ensemble des contributions).
URL http://journals.openedition.org/sdt/docannexe/image/33283/img-1.jpg
Fichier image/jpeg, 109k
Titre Figure 1. Évolution des contributions à CVS de 1990 à 2000. Analyse des 466 contributions
Crédits Source des données : Changelog CVS ; auteur de la figure : G. Alcaras.
URL http://journals.openedition.org/sdt/docannexe/image/33283/img-2.png
Fichier image/png, 102k
Haut de page

Pour citer cet article

Référence électronique

Gabriel Alcaras, « Des biens industriels publics. Genèse de l’insertion des logiciels libres dans la Silicon Valley »Sociologie du travail [En ligne], Vol. 62 - n° 3 | Juillet-Septembre 2020, mis en ligne le 12 septembre 2020, consulté le 22 mai 2025. URL : http://journals.openedition.org/sdt/33283 ; DOI : https://doi.org/10.4000/sdt.33283

Haut de page

Auteur

Gabriel Alcaras

Centre Maurice Halbwachs (CMH), UMR 8097 CNRS, EHESS, ENS et INRAE
48, boulevard Jourdan, 75014 Paris, France
gabriel.alcaras[at]ehess.fr

Articles du même auteur

Haut de page

Droits d’auteur

CC-BY-NC-ND-4.0

Le texte seul est utilisable sous licence CC BY-NC-ND 4.0. Les autres éléments (illustrations, fichiers annexes importés) sont « Tous droits réservés », sauf mention contraire.

Haut de page
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search