L'écriture collective du code source informatique

L'ÉCRITURE COLLECTIVE DU CODE SOURCE INFORMATIQUELe cas du commit comme acte d'écritureStéphane Couture S.A.C. | Revue d'anthropologie des connaissances 2012/1 - Vol. 6, n° 1pages 21 à 42

ISSN 1760-5393

Article disponible en ligne à l'adresse:

--------------------------------------------------------------------------------------------------------------------http://www.cairn.info/revue-anthropologie-des-connaissances-2012-1-page-21.htm

--------------------------------------------------------------------------------------------------------------------

Pour citer cet article :

--------------------------------------------------------------------------------------------------------------------Couture Stéphane, « L'écriture collective du code source informatique » Le cas du commit comme acte d'écriture,

Revue d'anthropologie des connaissances, 2012/1 Vol. 6, n° 1, p. 21-42. DOI : 10.3917/rac.015.0061

--------------------------------------------------------------------------------------------------------------------

Distribution électronique Cairn.info pour S.A.C..

© S.A.C.. Tous droits réservés pour tous pays.

La reproduction ou représentation de cet article, notamment par photocopie, n'est autorisée que dans les limites desconditions générales d'utilisation du site ou, le cas échéant, des conditions générales de la licence souscrite par votreétablissement. Toute autre reproduction ou représentation, en tout ou partie, sous quelque forme et de quelque manière quece soit, est interdite sauf accord préalable et écrit de l'éditeur, en dehors des cas prévus par la législation en vigueur enFrance. Il est précisé que son stockage dans une base de données est également interdit.

1 / 1

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D

ocument téléchargé depuis w

ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.

Revue d’anthropologie des connaissances – 2012/1 21

dossier « Les Petites mains de La société de L’information »

L’écriture coLLective du code source informatique

Le cas du commit comme acte d’écriture

stéPhane cOuTurE

rÉSumÉ

Cet article analyse l’écriture collective du code source informatique. Le code source est l’objet de la programmation informatique et peut être défini comme l’ensemble des instructions qui décrivent le fonctionnement d’un logiciel ou d’un système informatique. L’article s’appuie sur différents travaux en sociologie des sciences et des techniques et en anthropologie de l’écriture qui ont en commun d’insister sur le travail, parfois invisible, nécessaire à la stabilité et à la vitalité des écrits et des infrastructures d’informations. Nous analysons la manière dont sont gérées les différentes versions du code source, en étudiant plus particulièrement l’acte informatique du « commit ». Nous insistons particulièrement sur les enjeux de visibilité liés à cet acte de commit, qui prend une importance grandissante comme indicateur de la contribution dans la société de l’information.

mots clés : code source informatique, infrastructures, écriture collective, travail invisible, logiciels libres

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.

22 Revue d’anthropologie des connaissances – 2012/1

INTrODucTION : La PLacE NÉGLIGÉE Du cODE SOurcE INfOrmaTIquE1

De nombreuses études ont été consacrées dans les dernières années aux différents aspects sociaux et politiques des technologies de l’information de la dite « société de l’information ». Parmi ces études, un certain nombre a plus ou moins explicitement abordé la question du code informatique. Elles se sont attachées à étudier divers aspects des logiciels libres, dont le principe repose sur le libre accès au code source des logiciels. Ces études ont par exemple abordé les valeurs hackers des acteurs impliqués dans les communautés de logiciel libre (Auray, 2000 ; Auray, 2007), les formes de régulation qui assurent la cohésion de ces communautés (Demazière, Horn, et Zune, 2006 ; 2007), ou encore l’articulation entre la production du logiciel libre et le capitalisme contemporain (Coris, 2006). D’autres études, s’inspirant des discours des militants du logiciel libre, ont insisté sur la manière dont le code (source) informatique constitue une forme d’écriture, voire une forme expressive propre à être protégée par le droit à la liberté d’expression (Doueihi, 2008 ; Coleman, 2009). Enfin, certaines études ont mobilisé la catégorie du « code » pour insister sur le caractère politique des infrastructures technologiques qui agissent à la manière d’une loi en régulant le comportement des usagers (Lessig, 2006 ; Brousseau et Moatty, 2003). Ainsi, Brousseau et Moatty (2003) écrivent que « l’écriture de lignes de code informatique commandant l’exécution de procédures revient à imposer aux utilisateurs des normes d’usages » (p. 8).

Si ces études proposent des réflexions souvent fort pertinentes, force est toutefois de constater que le code source y occupe malgré tout une place souvent inégale. Ainsi, bien que ces études permettent de comprendre différents aspects des communautés fédérées autour de logiciels libres, le code source y est abordé de façon très périphérique, voire anecdotique, s’il n’est pas simplement absent. Par exemple, dans un article où ils analysent les relations de travail dans la communauté SPIP, Demazière, Horn et Zune (2007) n’accordent que deux courtes notes à la notion de code, qu’ils définissent comme « le texte des instructions du logiciel, écrit dans un langage de programmation » et le codeur comme celui qui « écrit le texte du logiciel, i.e. les instructions du programme informatique ». De la même manière, si l’ouvrage de Doueihi (2008) compare explicitement le code à une forme d’écriture, il ne présente aucun extrait, capture d’écran ou description précise de ce qui constitue concrètement le code source et son processus d’écriture2. Par ailleurs, les analyses qui se sont focalisées sur le pouvoir régulateur du code ont également tendance à aborder de manière très abstraite la catégorie du code ou l’activité d’écriture du code. Par exemple,

1 Ce texte s’appuie sur une recherche doctorale en cours, qui a bénéficié d’un appui financier du Conseil de recherche en sciences humaines du Canada (CRSH).2 Mentionnons toutefois que l’auteur présente une capture d’écran du site ohloh.net présentant quelques statistiques sur le code source du noyau Linux (Doueihi, 2008, ill. 16).

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


les « code writers » auxquels Lessig réfère dans son ouvrage y sont parfois désignés comme des acteurs individuels, souvent des dirigeants d’entreprise ou du gouvernement, et à d’autres moments, comme des institutions telles le FBI (Lessig, 2006, p. 35). Bref, si plusieurs études assimilent souvent le code informatique, voire le code source, à un écrit et sa fabrication à une activité d’écriture, celles-ci laissent parfois complètement de côté l’analyse pragmatique de ce qui constitue le code source, en tant qu’artefact écrit, de même que les actes concrets qui participent à son écriture. Malgré leur signification sociale et culturelle grandissante et leur importance cruciale comme composantes des technologies numériques, des notions telles que « logiciel », « code » ou « code source » restent encore très peu problématisées en sciences sociales (Rooksby et Martin, 2006 ; Fuller, 2008)3. Plus important encore, la relation entre la « matérialité » de cet artefact, ou son caractère d’infrastructure, et le travail au sein d’une communauté particulière, amplement documenté dans ces études, reste encore à articuler.

Cet article vise à pallier cette lacune en poursuivant un double objectif. D’abord, opérer un « renversement infrastructurel » (Bowker, 1994) en documentant ce en quoi consiste concrètement le code source informatique dans un cas particulier. Ensuite, analyser un acte d’écriture du code source, le commit, en insistant sur le travail des multiples mains qui participent au couronnement de cet acte (Fraenkel, 2006).

Le commit est un acte informatique qui consiste à valider formellement une modification du code source d’un logiciel. Étant donnée sa performativité particulière, l’acte du commit est étroitement lié à des dynamiques d’autorité et de visibilité sur lesquels nous insisterons dans cet article. L’analyse s’appuiera sur un cas empirique, le logiciel symfony, et procédera de la manière suivante : dans un premier temps, nous présenterons certains travaux récents en anthropologie de l’écriture qui inspirent notre démarche à travers la manière dont ils cherchent à réfléchir aux actes concrets et au travail parfois invisible qu’impliquent la stabilité et la vivacité des artefacts écrits et des infrastructures informationnelles (Fraenkel, 2006 ; 2007 ; Denis, 2006 ; 2009 ; Denis et Pontille, 2010a ; 2010b). Nous présenterons ensuite le cas du logiciel symfony, en insistant plus particulièrement sur son statut d’infrastructure dans le fonctionnement de certaines applications web. Après avoir mis de l’avant l’idée d’un « code source autorisé » nous analyserons alors l’acte informatique du commit en examinant une série d’interventions en ligne qui montre le travail de multiples mains participant à l’acte du commit. Nous serons alors en mesure d’étudier

3 Un certain nombre d’études réalisées récemment sous l’appellation des Software Studies et des Code Studies (Mackenzie, 2006 ; Marino, 2006 ; Rooksby et Martin, 2006) abordent beaucoup plus frontalement la question du code informatique. Ces travaux sont cependant très contemporains et nous avons préféré limiter notre positionnement dans cet article à la présentation d’études plus connues dans les milieux francophones. Mentionnons toutefois que notre démarche se distingue de ces derniers travaux par la manière dont nous abordons plus spécifiquement l’objet code source (plutôt que simplement le code au sens général) et dont nous intégrons à notre analyse certains travaux d’anthropologie de l’écriture.

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


les dynamiques de visibilité déployées autour du commit en tant qu’indicateur de la contribution à l’écriture du code source informatique.

INfraSTrucTurE D’INfOrmaTION, acTES D’ÉcrITurE ET PErfOrmaTIvITÉ DE L’ÉcrIT

La présente analyse s’inspire des récents travaux en anthropologie de l’écriture qui se sont penchés sur la performativité de l’écrit (Fraenkel, 2006 ; 2007 ; Denis, 2006 ; 2009 ; Denis et Pontille, 2010a ; 2010b). Denis et Pontille (2010b), dans leur étude sur la signalétique du métro de Paris, soutiennent ainsi que la performativité des écrits – les panneaux du métro dans leur cas – repose sur un travail de maintenance qui assure à ces écrits une permanence et une stabilité dont ils ne sont pas pourvus naturellement. Pour qu’un panneau de signalétique soit performatif, c’est-à-dire pour qu’il produise l’effet désiré, soit orienter les voyageurs dans le métro, celui-ci doit être conforme à certaines normes graphiques et être situé à des endroits significatifs. Or ces différentes propriétés ne sont pas intrinsèques à la matérialité des panneaux, mais reposent au contraire sur un incessant travail invisible qui vise à concevoir et à maintenir l’exposition de ces écrits. L’immuabilité et la stabilité apparentes de ces objets sont donc basées en bonne partie sur un travail effectué en coulisses.

Dans une perspective similaire, Fraenkel dresse les contours d’une anthropologie pragmatique de l’écriture, qui s’attache à étudier des actes courants d’écriture, comme la signature, ou l’étiquetage (Fraenkel, 2006). Dans un article où elle critique la conception de l’écrit dans la théorie de la performativité d’Austin (1962), cette auteure analyse le testament, un cas important de la théorie de la performativité d’Austin. Contrairement à ce que soutenait ce dernier, pour qui la performativité se situe principalement au moment de la lecture du testament – ou à son exécution –, Fraenkel soutient que la performativité réside également dans l’agencement de l’acte écrit dans une chaîne d’écriture. La performativité d’un testament repose donc sur le travail du ou de la notaire (et de ses assistant-es) qui doit donner une cohérence juridique à ces dernières paroles, en mettant en forme l’acte, et en apposant les sceaux et les signatures appropriés. Le testament, en tant qu’acte écrit, doit, pour être performatif, « être inséré dans un système de chaînes d’écriture, de personnes habilitées et de signes de validation, l’ensemble de ces éléments forment l’authenticité nécessaire à la performativité » (Fraenkel, 2006). Ce sont des actes d’écriture, telle l’apposition de signatures ou de tampons, qui confèrent à l’écrit une certaine matérialité nécessaire à sa performativité.

D’un point de vue méthodologique, ces approches s’appuient largement sur les travaux développés en sociologie des sciences et des techniques. Denis et Pontille citent notamment les travaux de Star qui « visent à mettre en lumière

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


le continent des activités qui composent au jour le jour l’infrastructure du monde » (Denis et Pontille, 2010a, p. 121). Il s’agit, dans cette perspective, de « faire remonter à la surface » (Star, 1999) le travail plus ou moins visible qui participe à la solidification des assemblages sociotechniques composant le monde. Cette approche est non seulement utile pour comprendre le travail de fabrication des objets, mais également pour analyser les objets eux-mêmes. Citant Latour (2004), Fraenkel note que les recherches sur la fabrique du droit montrent « qu’il existe une relation directe entre la force exemplaire de l’acte juridique et le réglage précis de ses formes textuelles, graphiques, matérielles » (Fraenkel, 2006). Elle note également que l’observation des activités d’écriture permet de pénétrer au cœur d’une institution ou, pourrions-nous ajouter dans notre cas, des infrastructures technologiques basées sur le code informatique.

Ces différentes réflexions permettent d’orienter notre regard sur le code source. En particulier, l’analyse que fait Fraenkel de la performativité des actes juridiques résonne avec la métaphore législative mobilisée par Lessig (2006) pour décrire la force régulatrice du code informatique. Suivant cette analyse, nous nous intéresserons donc à des actes concrets d’écriture, tels la signature ou l’étiquetage, qui en informatique confèrent au code source la stabilité nécessaire à sa force régulatrice. Le cas du commit est de ce point de vue exemplaire. Mais avant d’analyser le commit plus en détail, présentons d’abord le logiciel symfony, le terrain de notre étude.

LE caS DE Symfony, uN framEWOrK WEb

Notre analyse s’appuie sur l’étude de symfony 4, un logiciel qui se définit comme un « Open-Source PHP Web Framework »5. Ce logiciel est utilisé comme infrastructure de différentes applications web, dont les plus notables sont Daily Motion, Delicious ou encore Yahoo Bookmarks. Le caractère infrastructurel de symfony apparaît assez clairement dans la manière dont le logiciel est défini par les acteurs. Ainsi, un utilisateur de symfony explique que : « En soi, symfony, ce n’est rien, c’est juste des briques, qui vont me permettre de construire mon produit » (sf06). Un autre utilisateur que nous avons rencontré parle de symfony comme « le socle qui permet de faire fonctionner un projet » (sf09). L’extrait suivant d’un entretien avec un développeur de symfony montre également bien

4 Bien que nous consacrions cet article au projet symfony, notre recherche de doctorat étudie également le cas du projet SPIP, un système de publication pour Internet assez connu dans le monde français. À des fins de clarté, nous avons cependant décidé ici de limiter notre analyse au cas de symfony. Le présent article s’appuie sur l’analyse des traces en ligne de façon à reconstituer une partie de l’activité liée à l’acte du commit dans une approche s’assimilant à une ethnographie des traces en ligne (Geiger et Ribes, 2010). L’analyse est également enrichie par des extraits d’entretiens que nous avons réalisés avec les acteurs du projet symfony, ainsi que par l’observation située de plusieurs conférences et rencontres entre les acteurs du projet, entre juin 2009 et mai 2010.5 http://www.symfony-project.org/ (consulté le 6 mars 2012)

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


le caractère infrastructurel de symfony, qui permet d’éviter de « réinventer la roue » :

« L’idée de symfony, c’est des briques logicielles cohérentes qui permettent de développer des sites web plus rapidement et mieux. Plus rapidement, c’est-à-dire qu’il y a des briques logicielles dans le framework qui permettent de répondre à des problématiques de développement web que vont avoir 90 % des sites web » (sf02).

Ces extraits d’entretiens résonnent avec la définition de l’infrastructure développée par Star (1999). Pour cette auteure, une infrastructure présente différentes caractéristiques, dont l’une des plus importantes est sa transparence, c’est-à-dire qu’elle n’a pas à être réassemblée pour chaque tâche, et qu’elle se situe toujours en arrière-plan d’autres types d’activités. L’infrastructure est ensuite, pour cette auteure, un concept fondamentalement relationnel. Ce qui est appréhendé comme une infrastructure par certains acteurs – car peu visible – devient l’objet même du travail d’autres acteurs. Star (1999) prend l’exemple du cuisinier pour qui le système de distribution d’eau fait partie de l’infrastructure (invisible) de son travail, alors qu’il est l’objet du travail du planificateur urbain ou du plombier. Dans notre étude, symfony apparaît comme une infrastructure invisible pour la plupart des usagers d’Internet, en ce sens qu’il agit comme un socle de fondation (invisible) dans le fonctionnement de services web, voire d’autres logiciels, qui sont eux davantage visibles aux usagers.

LE cODE SOurcE DE Symfony

Dans le cadre de notre étude, nous nous sommes attardé aux catégories des acteurs pour analyser, ou définir le code source. Lorsqu’interrogés sur ce qui constitue le code source de symfony, les acteurs nous ont répondu assez clairement que le code source de symfony est « celui que je peux télécharger » (sf05) ou encore, que « quand on télécharge symfony, on télécharge les sources de symfony » (sf07). Nous avons nous-même visité la page de téléchargement de symfony, dont on retrouve un extrait à la figure 1. La page de téléchargement offre deux manières de télécharger symfony : soit sous la forme d’une archive en format.zip ou .tgz, soit en réalisant un « Checkout from the Subversion Repository », c’est-à-dire en retirant le code source depuis le dépôt Subversion, aspect que nous approfondirons plus loin dans l’article.

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


Page de téléchargement de Figure 1. symfony

Fait intéressant à noter, il n’y a aucune mention des termes « code » ou encore « code source » dans cet extrait de la page de téléchargement de symfony. En effet, le langage PHP, utilisé dans des projets comme symfony, est un langage interprété et non pas compilé, ce qui signifie que le code source est directement exécuté. En d’autres termes, télécharger symfony est ici synonyme de télécharger le code source de symfony.

Quelques informations quantitatives permettent de saisir la complexité de l’archive téléchargée6. Celle-ci forme une taille totale de 14,3 méga-octets, répartie dans 788 répertoires et 2924 fichiers. Parmi ces fichiers, 2104 portent l’extension .php, ce qui signifie qu’il s’agit de fichiers écrits dans le langage informatique PHP. Les 820 autres fichiers portent des extensions comme .dat, .yml et .png. Ils constituent par exemple des fichiers servant à la configuration générale de symfony, ou bien des images utilisées comme icônes ou comme boutons par le logiciel. L’analyse plus détaillée des fichiers écrits en PHP montre que ceux-ci consistent en un total de 302 803 lignes d’instruction à la machine – le code proprement dit – et 110 773 lignes de commentaires, c’est-à-dire des lignes de texte qui ne constituent pas à proprement dit des instructions à l’ordinateur, mais qui sont plutôt des commentaires documentant telle ou telle partie du code. Les figures suivantes montrent respectivement des captures d’écran des fichiers et répertoires (figure 2), ainsi que les lignes d’instruction et commentaires (figure 3) formant le code source symfony.

6 Ces informations correspondent à la version 1.4.10 de symfony. L’analyse a été réalisée avec les logiciels Simple Directory Analyser, LocMetrics ainsi qu’avec l’explorateur de répertoires du système d’exploitation (Windows 7).

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


Fichiers et répertoires formant le code sourceFigure 2.

Extrait du code source de Figure 3. symfony

LE DÉPÔT SubvErSION, Ou LE cODE SOurcE « auTOrISÉ » DE Symfony

Ce code source, celui qui est disponible en téléchargement, ne constitue cependant pas l’ensemble du code source qui circule autour du projet. Comme mentionné plus tôt, symfony ne constitue en effet qu’un « socle » permettant de construire un projet fini, qui est un mélange de code source :

« Il y a le code source du projet, et dedans, ça inclut le code source de symfony, le code source des plugins, et le code source de l’applicatif. Un

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


projet en soi, c’est un mélange de code source […] » (sf09).

Autour du code source de symfony, on peut constater une multitude d’endroits où l’on retrouve des artefacts que l’on pourrait décrire comme du code source, défini comme des « ensemble[s] d’instructions écrites dans un langage de programmation informatique »7. Les plugins, mentionnés dans la citation précédente, sont des extensions du logiciel qui permettent de modifier ou de personnaliser son comportement. Dans symfony, on retrouve environ 900 plugins fabriqués par la communauté et dont le code source peut être téléchargé séparément. Autour du code source de symfony, « celui que je peux télécharger », et de ces multiples plugins, d’autres lieux constituent des espaces où l’on discute et échange du code source. Symfony possède par exemple un répertoire de « Code snippets » regroupant une multitude de « bouts de code source » qui peuvent par la suite être copiés-collés au besoin, à certains endroits du code source. On retrouve également, associées directement au projet symfony ou en périphérie, plusieurs listes de discussions, un canal IRC8, de même que de nombreux blogues et autres sites web, où des « bouts de code » sont publiés et discutés et qui en sont autant d’objets intermédiaires (Vinck, 2006). Pour un des acteurs que nous avons rencontrés, l’activité de coder consiste en fait à récupérer ces bouts de code source pour les copier-coller dans l’assemblage d’un projet :

« Il faut bien voir que la façon de coder, enfin c’est aussi ma façon de coder, je ne tape pas beaucoup de code. C’est énormément de copier-coller. De récupération de bouts, parce que la structure, les fautes de frappe et tout, on en enlève pas mal quand on récupère des bouts entiers » (sf04).

Le code source de symfony, « celui que je peux télécharger », pourrait être en fait appelé le « code source autorisé », en ce sens qu’il s’agit du code source autorisé par certaines personnes seulement – l’équipe de cœur, ou le Core Team, en anglais – à figurer sur la page de téléchargement. Le concept de « code source autorisé » que nous forgeons ici renvoie d’abord à la nécessité de disposer de certaines autorisations informatiques pour pouvoir modifier le code source de symfony, disponible en téléchargement. Ce concept résonne également avec celui de « langage autorisé » mis en avant par Bourdieu (1975) pour analyser les conditions sociales de la performativité du langage : un énoncé est performatif non pas uniquement parce qu’il obéit à certaines conventions, mais parce que son énonciateur est institutionnellement autorisé à le prononcer. Comme pour Bourdieu, notre notion de « code source autorisé » insiste sur le fait qu’il ne s’agit pas seulement d’écrire un bout de code pour que celui-ci agisse.

7 http://fr.wikipedia.org/w/index.php?title=Code_source&oldid=52775534 (consulté le 6 juillet 2010).8 L’IRC (Internet Relay Chat) est un protocole de communication instantanée sur Internet qui sert principalement à la communication en groupe. Voir la thèse de Laztko-Toth à ce sujet (Latzko-Toth, 2010).

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.

http://fr.wikipedia.org/w/index.php?title=Code_source&oldid=52775534


Contrairement à l’analyse de Bourdieu, toutefois, les autorisations entourant le code source autorisé ne renvoient pas seulement à la position sociale de la personne qui écrit le code, mais plutôt à l’articulation de ce bout de code avec le code source qui est autorisé à figurer sur la page de téléchargement. Pour reprendre cette citation de Fraenkel, un bout de code source, pour avoir une véritable force performative, doit être inséré dans « un système de chaînes d’écriture, de personnes habilitées et de signes de validation, éléments qui forment l’authenticité nécessaire à la performativité » (Fraenkel, 2006).

LE commit, acTE D’ÉcrITurE « auTOrISÉ » Du cODE SOurcE INfOrmaTIquE

Nous avons mentionné plus tôt que le code source de symfony pouvait être téléchargé depuis une archive (en format .zip et .tgz), mais également depuis le dépôt Subversion, qui est un système permettant, entre autres, de gérer les différentes versions du code source. De nombreux projets de développement de logiciels s’appuient aujourd’hui sur des logiciels facilitant la gestion des différentes versions du code source. Le site ohloh.net, sur lequel nous reviendrons plus loin, recense par exemple plus de 238 000 projets de logiciels libres ou open source, dont plus de 70 % utilisent différentes variantes du système Subversion. Bien qu’utilisé principalement dans le monde de l’informatique pour la gestion des différentes versions du code source, Subversion peut en fait gérer tout type de document en format texte et est, par exemple, utilisé dans symfony pour faciliter l’écriture de la documentation technique.

La transaction de base dans plusieurs de ces logiciels est la commande informatique commit. Le commit consiste à publier les changements apportés au code source, pour les rendre accessibles aux autres acteurs impliqués dans le projet, voire même, dans le cas de logiciels libres, au public en général. Ainsi, un acteur pourra travailler sur le code source du logiciel sur son ordinateur personnel, en version locale, puis rendre publics ses changements à l’aide de la commande commit. À chacun des commits est associé, dans le système de gestion de versions, un numéro de révision, le nom de l’utilisateur qui a publié le commit, de même qu’un message optionnel (appelé log, en anglais) et l’heure (timestamp) à laquelle a été réalisé le commit. Le commit décrit également chacun des fichiers du code source qui a été modifié. Ces informations sont ensuite accessibles à travers différentes interfaces et permettent de conserver l’historique des modifications apportées au code source. La figure suivante (4) montre une mise en forme des données associées au commit.

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


Le commit 20870 de Figure 4. symfony

La description de la modification réalisée par ce commit montre que certaines modifications au code source de symfony sont faites petit à petit, voire ligne par ligne, dans le temps. Plusieurs modifications peuvent donc être réalisées plusieurs fois par jour, occasionnant chacune une nouvelle révision du code source.

D’autres commandes du logiciel Subversion sont significatives et sont à mentionner ici. Il est possible dans les logiciels de gestion de versions, d’étiqueter une révision spécifique du code source pour décréter qu’il s’agit, par exemple, d’une version « stable » disponible en téléchargement. Ces actes informatiques, tels que le commit ou l’étiquetage, peuvent être appréhendés comme des actes d’écriture au sens de Fraenkel, car ce sont des actes qui ont pour effet de valider ce qui constitue le code source « autorisé ». Or, comme l’écrit Fraenkel, « la signature se présente comme un acte pris dans une action plus large. Elle suppose plusieurs actants, plusieurs auteurs, plusieurs mains » (Fraenkel, 2008). Dans la section suivante, nous nous focalisons sur le commit, en analysant plus précisément le travail des petites mains qui participent à cet acte.

buGS, ruSTINES, TIcKETS : LES PETITES maINS D’uN cOmmIT

Comme nous l’avons indiqué précédemment, le code source déposé dans le système de gestion de versions est soumis à différentes autorisations et droits d’écriture. Ainsi, seules certaines personnes ont effectivement le droit de « commiter », c’est-à-dire de modifier officiellement le code source d’un projet. Ces restrictions des droits sont souvent justifiées par le fait d’assurer une plus grande qualité et une cohérence dans les modifications au code source. Plusieurs pratiques et dispositifs sont cependant mis en place pour assurer une participation plus étendue. L’une de ces pratiques consiste à

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


pouvoir soumettre des rustines (des « patches » en anglais) et des rapports de bogues, qui peuvent être suivis dans le temps9. Ces possibilités de contribution se font par l’intermédiaire d’un logiciel nommé trac qui permet de suivre ces propositions de modification au code source, autour d’un ticket. Dans le cas de suivi de bogues, on parle alors souvent de « bug tracker ».

Dans cette section, nous décrirons l’activité distribuée de production d’un correctif, en analysant le cas du commit 20870 du logiciel symfony. L’étude de cas s’appuie sur l’analyse du système trac. L’analyse a pour objet le ticket identifié par le numéro 4152. Nous avons choisi d’analyser un ticket pour le cas de symfony puisque le système de tickets fait l’objet d’un usage important. Pour trouver le ticket en question, nous avons restreint notre choix aux tickets qui avaient été effectivement fermés par l’équipe de cœur (le core team). Parmi ces différents tickets, nous en avons choisi un qui permettait d’analyser une opération d’écriture qui mobilise plusieurs acteurs, dispositifs techniques, ainsi que plusieurs interventions dans le temps. Notre choix s’est finalement arrêté au ticket numéro 415210. Ce ticket a été ouvert le 7 août 2008 à 17 h 26 et a suscité 17 interventions s’échelonnant sur une période d’un an, soit jusqu’au 7 août 2009. Sept personnes ont participé aux discussions concernant ce ticket. Parmi celles-ci, deux étaient membres de l’équipe de cœur et avaient par conséquent les droits en écriture nécessaires pour publier des modifications au code source de symfony 11. Sans entrer dans les détails du contenu de la modification proposée (détails que nous avons nous-mêmes de la difficulté à comprendre), disons que ce ticket concerne un bogue concernant la génération automatique de code Javascript dans le navigateur Internet Explorer.

La première intervention est celle de Leonard, qui a ouvert le ticket et a ensuite proposé une série de modifications qu’il décrit comme un « patch », spécifiant les lignes du code source qui doivent être modifiées (figure 5) :

9 Une autre manière de favoriser la participation étendue est de créer un système de plugins. Comme décrit plus tôt, les plugins sont des extensions du logiciel qui permettent de modifier ou de personnaliser son comportement. Ils permettent aux acteurs ne disposant pas des autorisations d’écriture sur le cœur du logiciel, de partager d’une manière modulaire certaines améliorations ou modifications du logiciel.10 http://trac.symfony-project.org/ticket/4152 (consulté le 8 août 2011).11 Le ticket en question étant clairement accessible publiquement, et la présente analyse ne comportant à notre avis aucun risque pour les personnes citées, nous avons décidé, à des fins de clarté, de conserver tels quels les pseudonymes utilisés par les acteurs (nous les enlevons cependant à la figure 9 car les références sont trop explicites).

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.

http://trac.symfony-project.org/ticket/4152


Proposition d’une rustineFigure 5.

En même temps que son intervention, Leonard modifie les champs « statut » et « résolution » de son ticket en spécifiant respectivement « closed » et « fixed », ce qui signifie que le ticket est fermé. Trois heures plus tard, une seconde personne intervient pour obtenir une clarification concernant le statut du ticket : « Is this fixed? Or is it just ready for review? ». Ceci amène une réponse, deux jours plus tard par l’auteur du premier message (Leonard) qui spécifie avoir proposé une solution (« a fix ») pour aider d’autres personnes de la communauté à résoudre le problème. Encore deux journées plus tard, un membre de l’équipe de cœur intervient, en spécifiant que, selon lui, la proposition amenée plus tôt apparaît adéquate et pourrait être appliquée à la version 1.x.

Aucune modification du ticket n’est cependant apportée pendant plusieurs mois, jusqu’à ce qu’un autre acteur, Andromeda, s’interroge sur le fait que cette solution (« this fix ») n’a pas encore été appliquée à la version 1.2.5, alors que celle-ci pourrait être d’une grande aide. Un peu moins d’une heure plus tard, on retrouve six interventions sur une période de deux minutes de la part d’un membre du core team, disposant des droits d’écriture pour modifier le code source de symfony. Ces interventions spécifient que des commits portant les numéros 17383, 17384, 17385 et 17386 ont été réalisés, un pour chacune des branches correspondant respectivement aux versions 1.3, 1.2, 1.1 et 1.0 du code source de symfony. Cet intervenant modifie également les méta-informations concernant ce ticket, entre autres pour indiquer que le statut du ticket est désormais fermé (« closed ») (figure 6).

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


Intervention et commitsFigure 6.

La conversation reste ensuite silencieuse pendant plus de deux mois, jusqu’au 28 juin 2009, au moment où un quatrième acteur, Intru, entre en scène. Celui-ci décide d’ouvrir de nouveau le ticket, en demandant si la correction ne devrait pas être appliquée ailleurs (figure 7).

Réouverture du ticketFigure 7.

Douze jours passent encore puis le même Intru décide de soumettre en pièce jointe un fichier dont l’extension est .diff. Ce fichier, dont on retrouve une mise en forme à la figure suivante (8), présente ligne par ligne les modifications proposées. Contrairement à la proposition de rustine de la figure 5, le fichier « diff » constitue une rustine qui peut être appliquée de façon plus automatisée par des personnes disposant des droits d’écriture.

Un « diff » spécifiant la modification au code sourceFigure 8.

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


Après presque un mois de silence, un sixième acteur, Boutell, entre en scène le 6 août 2009, en indiquant que la proposition présentée plus tôt n’est pas idéale et constitue simplement un pansement temporaire. Cet acteur propose une autre solution (« a fix »), plus complexe. Le lendemain, un septième acteur, FabienLange, qui est membre de l’équipe de cœur, et qui possède donc les droits d’écriture conséquents, décide de commiter le code, et de fermer le ticket. Ceci met fin à la saga du ticket 4152. Ces changements sont connus sous le nom de le commit 20870, dont nous avons présenté une capture d’écran du commit à la figure 4. Notons par ailleurs que les informations contenues dans le ticket montrent que la « propriété » du billet a été réassignée de fabien, qui est le chef du projet symfony, à FabienLange, le membre du core team qui a effectivement fermé le ticket.

L’acTE Du cOmmIT cOmmE INDIcaTEur DE La cONTrIbuTION

La notion de contribution prend une place de plus en plus importante dans le travail et les échanges sur Internet au point que certains auteurs parlent aujourd’hui de la mise en place d’une véritable économie de la contribution qui se distinguerait des formes d’économie basées sur le don ou sur les transactions marchandes (Stiegler, Giffard, et Faure, 2009). Analysant le cas des questions rapides sur les messageries instantanées, Licoppe, Proulx et Cudicio (2010) définissent la contribution comme « une transaction fondée sur l’échange de messages isolables et discrets (une information, un nom, un numéro de version logicielle), orientée vers le service, l’entraide, la coopération interpersonnelle » en notant que « la contribution serait d’autant plus réussie et significative [...] qu’elle serait façonnée pour demander un effort cognitif minimal au contributeur » (Licoppe, Proulx, et Cudicio, 2010). On voit bien dans notre description du commit de la section précédente la manière dont celui-ci correspond à cette définition de la contribution. L’acteur qui, en dernière instance, effectue le commit, n’a eu en effet que peu de travail à réaliser tandis que le véritable travail de mise en forme, de vérification et d’ajustement s’est déroulé au fil de transactions plus élémentaires sur une période assez longue.

La place importante accordée à la contribution dans la littérature fait écho à la place qu’elle prend dans les pratiques des acteurs. Dans cette dynamique, le commit occupe une place privilégiée comme indicateur de la contribution. Profitant du libre accès au code source et aux systèmes de gestion des versions, de plus en plus d’initiatives émergent aujourd’hui et tentent d’exploiter et de recouper ces informations. L’une de ces initiatives les plus remarquées est le site ohloh.net qui répertorie un grand nombre de projets de logiciels libres et propose différentes mesures pour les analyser. Parmi ces mesures, on retrouve notamment le nombre de commits réalisés par chacun des développeurs, ce qui

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


permet de classer les développeurs selon leurs contributions au projet (voir figure 9).

Ohloh.net. Liste des contributeurs, classés par nombre de commitsFigure 9.

Dans un article où ils analysent les relations entre travail visible et invisible, en particulier dans le contexte des dispositifs de travail coopératif assisté par ordinateur (Computer Supported Cooperative Work - CSCW), Star et Strauss (1999) notent qu’avec l’émergence des réseaux électroniques apparaissent de nouvelles manières de retracer et de valoriser le travail. Ces représentations sont souvent inscrites dans le langage « neutre » des métriques, et sont particulièrement politiques, en ce sens qu’elles ont tendance à définir ce qui compte comme un travail à part entière.

Comme Star et Strauss (1999) l’indiquent, le travail n’est jamais complètement visible ou invisible mais est au contraire toujours « vu » à travers des indicateurs (Star et Strauss, 1999). À plusieurs reprises, le site ohloh.net nous a été indiqué par les participants aux entretiens et, dans le cadre d’une conférence publique, un des acteurs mentionnait même que de plus en plus d’employeurs utilisent ce site pour recruter des développeurs12.

Il est intéressant de constater la centralité, voire même l’unicité, du commit dans les indicateurs de la contribution, au détriment d’autres indicateurs qui pourraient être pertinents pour juger la contribution des gens à un projet donné. Nous l’avons déjà remarqué, les interventions de certains acteurs dans la modification du code source ne sont pas toujours reconnues par la seule prise en compte de l’acte du commit. Nous avons en effet vu plus tôt que la rustine constitue une forme de contribution au code source. Toutefois, il est important de noter que, du moins dans le logiciel Subversion, la personne qui contribue sous la forme de rustines n’est généralement pas celle qui va

12 Stefan Koopmanschap, « The symfony community - how you can (get) help ». Conférence Symfony Live 2010. Paris, 16 février 2010.

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


réaliser le commit du code. En fait, nous pourrions même dire que si une personne contribue sous forme de rustine, c’est précisément parce qu’elle n’a pas suffisamment de droits pour contribuer sous forme de commit. Le résultat de cette situation est que les auteurs des contributions sous forme de rustine restent invisibles dans les contributions générales au projet. La reconnaissance de la contribution va donc plutôt à la personne qui accomplit l’acte du commit, donc celle qui signe la contribution au code source.

Cette situation pourrait cependant changer avec l’adoption d’un nouveau système de gestion des versions, le logiciel GIT, qui valorise une approche beaucoup plus distribuée que dans le cas de Subversion. Sans entrer dans les détails de ce système que nous présentons ici à titre d’ouverture, mentionnons que l’une des principales conséquences de cette innovation, du point de vue de la présente analyse, est de rendre caducs la notion de rustine et le système de trac, qui ont fait l’objet de nos descriptions à la section précédente. En suivant l’évolution de GIT, il est fort à parier que les notions d’auteur et de contributeur continueront à évoluer. En effet, la page « about » du site GIT13 décrit les différents auteurs primaires et les contributeurs de GIT (qui sont qualifiés de héros), spécifiant qu’ils sont regroupés par nombre de commits. Si cette évolution peut paraître plus égalitaire et donner plus de reconnaissance aux différentes formes de contribution, on peut également constater la centralité grandissante du commit dans la reconnaissance de cette contribution.

Cependant, les interactions autour du code source ne se situent pas seulement dans l’espace que nous avons analysé, dans le système « trac » et autour de la rustine, et n’ont pas non plus toujours directement comme objet de réaliser un commit. Le développement de symfony s’appuie en effet largement sur des listes de discussion qui peuvent compter plusieurs mails par jour. Une analyse quantitative de ces listes montre que certaines personnes participent de façon importante, par exemple en donnant des suggestions concernant le développement, voire en proposant des bouts de code source pouvant être éventuellement intégrés dans le logiciel. Par ailleurs, il est intéressant de constater que l’octroi des « droits de commiter » n’est pas nécessairement corollaire de l’activité de commiter. L’autorisation de commiter est en effet parfois accordée à des personnes qui, à toute fin pratique, n’ont que très peu, voire pas du tout, commité. Ces personnes sont choisies pour participer à l’« équipe de cœur », pour des compétences non liées directement à l’écriture du code source, comme leur capacité à animer la vie de la communauté14. Ainsi, le droit de commiter est également, et peut-être surtout, un marqueur d’inclusion, voire d’autorité, dans la communauté.

La réalisation d’entretiens et l’observation, outre que d’aider à mieux comprendre le projet dans son ensemble, permettent également de saisir

13 http://git-scm.com/about (consulté le 1er décembre 2010).14 Cette dynamique est surtout le fait du projet SPIP, le second projet que nous avons étudié, et où les droits de commiter sont accordés à toute personne faisant partie de l’équipe de cœur, qu’elle réalise ou non des commits au code source du projet.

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.

http://git-scm.com/about


d’autres formes de travail, invisibles ou moins directement visibles par la seule analyse des traces en ligne. Dans le cas de symfony, l’entreprise qui commandite le projet emploie elle-même plusieurs personnes qui peuvent se retrouver au quotidien et participer de différentes façons au projet. Dans un entretien, une participante nous explique ainsi qu’au moment de son embauche, elle avait suggéré au chef de projet de symfony d’utiliser une nouvelle version du langage PHP, ce qui, selon elle, a probablement contribué à ce choix. Un autre acteur explique ainsi sa contribution au projet symfony :

Ma contribution, ma petite contribution dans symfony, ça a plus été de fédérer et monter une communauté de développeurs motivés plutôt que de participer par exemple au code et à la génération de plugins, où je me sens moins à l’aise (sf10).

D’une certaine manière, ces deux types de travail, « fédérer une communauté » et « participer au code », pourraient correspondre à la distinction faite par plusieurs auteurs et mise en avant par Star et Strauss, entre le travail d’articulation et le travail de coopération. Pour ces auteurs, le travail d’articulation – fédérer une communauté – consiste à gérer la nature distribuée du travail tandis que le travail de coopération – participer au code – entrelace des tâches distribuées (Star et Strauss, 1999, p. 10). Mais le plus significatif pour ces auteurs est que le travail d’articulation reste invisible aux modèles rationalisés du travail (Star et Strauss, 1999, p. 10). L’important ici est donc de rappeler que si le commit constitue un acte central conférant une stabilité au code source, cet acte lui-même repose sur de multiples mains dont le travail présente différents degrés de visibilité. Si l’ouverture d’un ticket ou la proposition d’une rustine sont moins visibles que le commit, ils sont néanmoins des actes isolables qui peuvent être analysés en tant que tels. La question qui se pose est cependant : comment analyser le travail beaucoup moins visible d’articulation en regard de la stabilité du code ?

cONcLuSION

Dans le cadre de cet article, nous avons tenté d’articuler la stabilité et la vitalité du code informatique au travail d’écriture. Notre analyse s’est principalement focalisée sur l’acte informatique du commit, que nous avons appréhendé comme un acte d’écriture qui participe à la performativité du code. Cette démarche nous renseigne sur plusieurs choses. D’abord, l’analyse de l’acte du commit nous permet d’étudier plus frontalement ce qui constitue le code source informatique, un objet encore peu analysé dans la littérature, malgré une prolifération d’études sur les logiciels libres et les différents aspects d’Internet. L’analyse de l’acte du commit permet également d’ouvrir la voie à une meilleure articulation pragmatique entre l’activité d’écriture du code et sa

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


force régulatrice ou performative. Finalement, cette analyse permet d’explorer les dynamiques d’autorité et de visibilité à l’œuvre dans les projets de logiciels libres. Nous avons insisté, dans la dernière partie du texte, sur la place centrale que prend l’acte du commit dans les indicateurs de la contribution, centralité qui peut laisser invisible un certain éventail d’activités, de même que la contribution de certaines catégories d’acteurs qui ne participent pas directement à l’écriture de bouts de code. Un exemple des conséquences de cette écologie de la visibilité est le sondage en ligne réalisé en 2002 dans le cadre de l’enquête européenne FLOSS, qui a révélé une proportion de 1,1 % de femmes parmi les « développeurs de logiciels libres » (Ghosh et al., 2002). Si ce chiffre est significatif d’une faible présence des femmes dans le monde du logiciel libre, il est également significatif de leur faible visibilité dans l’indicateur utilisé par l’enquête. En effet, l’enquête de Ghosh et al. ne retenait que les répondant-es dont le nom figurait effectivement comme auteur-e dans le code source d’un logiciel, approche occultant plusieurs formes de participation au développement du logiciel libre qui ne relèvent pas directement de l’écriture du code source. Comme le souligne Haralanova (2010), les femmes sont souvent engagées dans différentes activités liées au développement de logiciels, des activités qui sont souvent occultées, voire dévalorisées, étant donné qu’elles ne sont pas liées directement à l’écriture du code source.

Comme le notent Star et Strauss (1999), l’objectif n’est cependant pas ici de soutenir que tout travail doit être pleinement visible à tous. L’invisibilité d’un travail peut, par exemple, parfois être une occasion pour éviter certaines formes de surveillance ou de contrôle. Cependant, comme le notent également ces auteurs, l’invisibilité peut avoir un effet de cascade dans les infrastructures d’information, et l’invisibilisation du travail de certaines personnes peut entraîner davantage d’invisibilité, ce qui soulève des enjeux de justice sociale et d’iniquité. Dès lors, pour revenir à notre analyse du code source et du commit, l’enjeu à la fois théorique et politique consisterait à saisir des actes qui, sans nécessairement être des actes d’écriture du code source proprement dit, seraient néanmoins des actes qui participeraient à la stabilité et à la vitalité du code source, et qui permettraient de saisir un éventail d’activités plus large.

remerciements

L’auteur remercie Jérôme Denis et David Pontille, ainsi que les réviseurs anonymes pour leurs relectures et commentaires. Merci également à Geneviève Szczepanik

pour son soutien et la relecture des différentes épreuves. Merci finalement aux acteurs des projets symfony et SPIP qui ont participé à cette étude.

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.


rÉfÉrENcES

Auray, N. (2000). Politique de l’informatique et de l’information. Les pionniers de la nouvelle frontière électronique. Thèse de doctorat, EHESS (Paris). http://ses.telecom-paristech.fr/auray/Auray%20These.pdf (consulté le 29 novembre 2010).Auray, N. (2007). Le modèle souverainiste des communautés en ligne : impératif participatif et désacralisation du vote. Paroles publiques : Communiquer dans la cité. Hermès. (47), 137-144.Austin, J. L. (1962). How to Do Things with Words. (2d ed.). Oxford : Oxford University Press.Bourdieu, P. (1975). Le langage autorisé note sur les conditions sociales de l’efficacité du discours rituel. Actes de la recherche en sciences sociales. 1 (5-6), 183-190.Bowker, G. (1994). Information Mythology and Infrastructure, in Lisa Bud-Frierman (éd.). Information Acumen: The Understanding and Use of Knowledge in Modern Business. London: Routledge, 231-347. Brousseau, E. et Moatty F. (2003). Perspectives de recherche sur les TIC en sciences sociales: Les passerelles interdisciplinaires d’Avignon. Sciences de la société. (59), 3-33.Coleman, G. (2009). Code is speech: Legal Tinkering, Expertise, and Protest among Free and Open Source Software Developers. Cultural Anthropology. 24 (3), 420-454.Coris, M. (2006). Chronique d’une absorption par la sphère marchande : les Sociétés de Services en Logiciels Libres. Gérer & Comprendre. (84), 12-24.Demazière, D., Horn F. et Zune M. (2006). Dynamique de développement des communautés du logiciel. Conditions d’émergence et régulations des tensions. Revue Terminal. (97-98), 71-84.Demazière, D., Horn F. et Zune M. (2007). Des relations de travail sans règles, l’énigme de la production des logiciels libres ? Sociétés contemporaines. 66 (2), 101-125.Denis, J. (2009). Le travail invisible de l’information, in C. Licoppe (éd.). L’évolution des cultures numériques, de la mutation du lien social à l’organisation du travail. Paris : FYP, 117-123.Denis, J. (2006). Les nouveaux visages de la performativité. Études de communication. (29), 7-24.Denis, J. et Pontille D. (2010a). Performativité de l’écrit et travail de maintenance. Réseaux. 163 (5), 105-130. Denis, J. et Pontille D. (2010b). Petite sociologie de la signalétique : Les coulisses des panneaux du métro. Paris : Presses de l’École des mines.Doueihi, M. (2008). La Grande Conversion numérique. Paris : Seuil.Fraenkel, B. (2006). Actes écrits, actes oraux : la performativité à l’épreuve de l’écriture. Études de communication. (29), 69-93. http://edc.revues.org/index369.html (consulté le 9 août 2011) Fraenkel, B. (2007). Actes d’écriture : quand écrire c’est faire. Langage et société. 121-122 (3-4), 101-112. http://dx.doi.org/10.3917/ls.121.0101 (consulté le 9 août 2011)Fraenkel, B. (2008). La signature : du signe à l’acte. Sociétés & Représentations. 25 (1), 13-23. http://dx.doi.org/10.3917/sr.025.0013 (consulté le 9 août 2011).Fuller, M. (2008). Software Studies: A Lexicon. Cambridge (MA): The MIT Press.Geiger, R. S. et Ribes D. (2010). The work of sustaining order in wikipedia: the banning of a vandal. Proceedings of the 2010 ACM conference on Computer supported cooperative work - CSCW’10. New York : ACM. 117-126. http://portal.acm.org/citation.cfm?id=1718941 (consulté le 30 novembre 2010).Ghosh, R. A., Glott R., Krieger B. et Robles G. (2002). Free/Libre and Open Source Software : Survey and Study. University of Maastricht, The Netherlands: International Institute of Infonomics. http://www.flossproject.org/report/FLOSS_Final4.pdf (consulté le 8 août 2011).

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.

http://ses.telecom-paristech.fr/auray/Auray These.pdf

http://edc.revues.org/index369.html

http://dx.doi.org/10.3917/sr.025.0013

http://portal.acm.org/citation.cfm?id=1718941


Haralanova, K. (2010). L’apport des femmes dans le développement du logiciel libre. Mémoire de maîtrise, Université du Québec à Montréal.Latour, B. (2004). La fabrique du droit : Une ethnographie du Conseil d’État. Paris : La Découverte.Latzko-Toth, G. (2010). La co-construction d’un dispositif sociotechnique de communication : le cas de l’internet relay chat. Thèse de doctorat, Université du Québec à Montréal.Lessig, L. (2006). Code: And Other Laws of Cyberspace, Version 2.0. New York: Basic Books.Licoppe, C., Proulx S. et Cudicio R. (2010). L’émergence d’un nouveau genre communicationnel dans les organisations fortement connectées : les « questions rapides » par messagerie instantanée. Études de communication. (34). 93-108. http://www.cairn.info/revue-etudes-de-communication-2010-1-page-93.htm (consulté le 9 août 2011).Mackenzie, A. (2006). Cutting code: software and sociality. New York: Peter Lang.Marino, M. C. (2006). Critical code studies. Electronic book review. http://www.electronicbookreview.com/thread/electropoetics/codology (consulté le 8 août 2011).Rooksby, J. et Martin D. (2006). Ethnographies of Code. TeamEthno-online. (2), 1-2.Star, S. L. (1999). The Ethnography of Infrastructure. American Behavioral Scientist. 43 (3), 377-391Star, S. L. et Strauss A. (1999). Layers of Silence, Arenas of Voice: The Ecology ofVisible and Invisible Work. Computer Supported Cooperative Work, 8 (1-2), p. 9-30Stiegler, B., Giffard A. et Faure C. (2009). Pour en finir avec la mécroissance : quelques réflexions d’Ars Industrialis. Paris : Flammarion.Vinck, D. (2006). Dynamique d’innovation et de conception et rôle des objets intermédiaires. Ecole d’été du GDR TIC et Société. Autrans. http://gdrtics.u-paris10.fr/pdf/ecoles/sept2006/VINCK.pdf (consulté le 8 août 2011).

Stéphane cOuTurE est doctorant (en cotutelle) à l’Université du Québec à Montréal et à Télécom ParisTech. Il est membre du Laboratoire de communication médiatisée par ordinateur (LabCMO) et membre étudiant du Centre interuniversitaire de recherche sur la science et la technologie (CIRST).

Adresse Laboratoire de communication médiatisée par ordinateur Faculté de communication Université du Québec à Montréal C.P. 8888 Succ. Centre-Ville Montréal (Québec) H3C 3P8 Canada

Courriel [email protected]

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.

http://gdrtics.u-paris10.fr/pdf/ecoles/sept2006/VINCK.pdf


abstract: the coLLective writing of software source code

This article analyzes the collective writing of software source code. Software source code is a set of textual documents that formally specify the behavior of software – its script. The article draws on work in the sociology of science and technology and in the anthropology of writing, which insist on the (sometimes invisible) work that is necessary to the stability and vivacity of written artifacts and information infrastructures. We analyze the ways in which different versions of software source code are managed, and focus particularly on the computer act of « committing ». We insist on issues of visibility related to the act of committing, issues that are taking a growing importance as an indicator of one’s contribution in the information society.

Keywords: infrastructures, collective writting, Invisible work, free software

resumen: La escritura coLectiva de código fuente informático

Este artículo trata de la escritura colectiva de código fuente informático. El código fuente es el objeto de la programación informática que puede ser definido como el conjunto de instrucciones que describen el funcionamiento de un software o un sistema informático. Este artículo se apoya sobre diferentes trabajos de la sociología de la ciencia y la técnica, y en la antropología de la escritura; que tienen en común la insistencia sobre el trabajo, a veces invisible, necesario a la estabilidad y a la vitalidad de los escritos y de las infraestructuras de la información. Analiza la manera en la cuál las diferentes versiones del código fuente se administran, refiriéndose más particularmente al acto informático del “commit”. Insistiendo en especial sobre las cuestiones de visibilidad ligadas a este acto de “commit”, que toma una gran importancia como indicador de la contribución en la sociedad de la información.

Palabras claves: código fuente informático, infraestructura, escritura colectiva, trabajo invisible, software libre

Doc

umen

t tél

écha

rgé

depu

is w

ww

.cai

rn.in

fo -

-

- 13

8.73

.1.3

6 -

30/0

4/20

13 1

6h15

. © S

.A.C

. D


ww

.cairn.info - - - 138.73.1.36 - 30/04/2013 16h15. © S

.A.C

.

Documents

L'écriture collective du code source informatique