9. Sociabilité et contrôle social dans les collectifs de développement de logiciels libres
p. 117-126
Texte intégral
1Le développement de logiciels libres est une activité collective résultant de la participation volontaire d’individus dispersés et reliés par le réseau Internet, qui proposent des contributions d’ampleur variable (depuis l’écriture de parties importantes du programme informatique jusqu’au signalement de bogues, en passant par la documentation du logiciel, etc.). Le principe au fondement des logiciels libres – à savoir la mise à disposition du code source (texte du programme écrit dans un langage de programmation compréhensible par l’être humain), avec autorisation de le modifier et le distribuer librement – se traduit par la coopération de développeurs qui participent ainsi à la conception d’une œuvre commune.
2Collective, cette activité est fondée sur le bénévolat des participants, qui y consacrent une part, variable, de leur temps, et ne perçoivent aucune rétribution directe, à proportion de leur contribution. En ce sens, leur participation est orientée vers autrui, c’est-à-dire les autres contributeurs avec lesquels ils coopèrent, et les utilisateurs effectifs ou potentiels du logiciel. Cette activité est également orientée en valeurs. Si la production de logiciels libres est éclatée en milliers de projets, les références et préférences idéologiques des participants – du moins les plus engagés – convergent dans la lutte contre les monopoles, au premier rang desquels Microsoft. Et le travail collaboratif au fondement de la production des logiciels libres incarne les valeurs d’entraide et de mutualisation des efforts individuels1.
3Surtout, les collectifs qui se forment autour des projets de logiciels s’alimentent à un référentiel partagé, même s’il est flou : la notion de « communauté » est utilisée de manière systématique par les participants. Selon le vocabulaire indigène, chaque logiciel libre fédère une « communauté » travaillant à son développement, qui se désigne par le nom du logiciel (communauté Linux par exemple). Le terme « communauté » a une valeur métaphorique, et surtout normative : il suggère que ces collectifs parviennent à attirer des participants mobilisés dans l’accomplissement d’un objectif partagé, et qu’ils forment des groupes suffisamment soudés pour que les contributions volontaires s’articulent dans un produit cohérent. Il n’informe aucunement sur la manière dont ces collectifs fonctionnent, se maintiennent dans le temps, développent une action collective2.
4Cette vision enchantée est persistante, parce qu’elle est entretenue par une littérature endogène, pour qui la participation volontaire ne repose sur aucun dispositif d’organisation structuré (décentralisation, ouverture, absence de cahier des charges, d’injonctions temporelles, de coordination particulière), mais sur un ensemble de principes d’action communément partagés : méritocratie basée sur la mise en acte des seules compétences, leadership participatif, liberté d’implication, etc.3. Pourtant, seule une infime fraction des projets engagés (plus de 100 000 sont référencés sur le site de développement communautaire SourceForge) parvient à fédérer suffisamment de développeurs et d’utilisateurs pour aboutir à la production d’un logiciel efficace, cohérent et utile. L’attraction de participants volontaires et la fidélisation de ces bénévoles constituent donc des enjeux – et difficultés – récurrents. Ces difficultés sont renforcées par les contraintes que l’objectif de fabrication d’un logiciel induit sur le fonctionnement du collectif. En effet, un logiciel est un texte numérique actif un texte qui agit dans la mesure où il se compose d’un ensemble d’instructions qui seront exécutées automatiquement par une machine – ce qui nécessite une cohérence extrêmement forte des différentes parties de ce texte4. Ainsi les activités individuelles doivent être marquées par une interdépendance très grande, issue de l’orientation du collectif vers la production et le perfectionnement du logiciel. Par nécessité fonctionnelle les engagements doivent être fiables et durables, complémentaires et ajustés les uns aux autres.
5Toutefois, ni les nécessités techniques issues des propriétés des logiciels, ni la référence à un idéal communautaire, ne suffisent à souder des collectifs orientés vers le développement de logiciels libres, à asseoir leur cohésion interne, à tisser les liens entre participants. Aussi nous avons mené une ethnographie approfondie d’un collectif constitué autour d’un logiciel de publication dynamique sur internet appelé Spip, afin d’en analyser le fonctionnement, de caractériser les relations nouées entre les participants, d’examiner comment la cohésion est produite, d’explorer ce qui fait collectif. Le projet Spip est emblématique de l’idéal promu par les partisans du logiciel libre : les fondateurs partagent des affinités idéologiques anticapitalistes ainsi que des expériences militantes tournées vers la promotion d’un « web indépendant » ; le logiciel lui-même est un outil d’auto-publication sur internet destiné à favoriser la « libre expression ». Aussi Spip bénéficie d’une forte image dans les milieux associatifs alternatifs. À l’issue d’une enquête étalée sur deux années, nous avons identifié trois ensembles de processus qui contribuent de manière décisive à soutenir et structurer les engagements, à agencer et hiérarchiser les contributions, à contrôler et valoriser les participants. Nous envisagerons successivement ces mécanismes, diversifiés, de sociabilité, de reconnaissance et de contrôle, qui sont destinés à lutter contre les risques d’assèchement ou de dispersion de collectifs soumis à de fortes contraintes de cohérence et de cohésion internes.
Une sociabilité diversifiée
6Les modalités de participation aux projets de logiciels libres sont spécifiques, parce que les échanges et la coopération s’effectuent pour l’essentiel à distance, à travers les réseaux informatiques. Ces relations virtuelles favorisent plutôt des échanges fonctionnels qui sont compatibles avec un anonymat des participants. Toutefois des échanges plus personnels sont également noués, même à distance et à travers des pseudonymes. De plus, des rencontres face-à-face sont organisées, dans le but de favoriser la cohésion du groupe et de renforcer les affiliations des participants.
7Les participants au projet Spip sont dispersés géographiquement, et communiquent entre eux à partir de leur ordinateur. La poursuite de leur projet n’implique aucune rencontre physique ni aucune réunion, mais passe par la fréquentation, souvent asynchrone, d’espaces de travail dédiés sur le réseau Internet : sites, listes de diffusion, forums, etc. Grâce à ces commodités techniques la mobilisation de participants compétents et intéressés peut s’affranchir des contraintes de mobilité, à condition, bien sûr, que le projet soit suffisamment visible et jugé attractif et crédible. C’est le cas du collectif fédéré autour de Spip, qui a atteint une taille critique, avec plusieurs dizaines de développeurs réguliers, plusieurs centaines de contributeurs occasionnels ou ponctuels, plusieurs milliers d’utilisateurs5.
8La distance entre ces membres rend impossible des interactions directes régulières. Toutefois ils partagent suffisamment d’intérêts, de valeurs, ou d’objectifs pour entretenir des relations suivies, du moins pour la fraction d’entre eux qui sont les plus engagés, tant en termes de temps consacré que de durée de la participation. Au cours de nos enquêtes nous avons souvent rencontré des participants qui échangeaient de manière très régulière, voire avaient collaboré étroitement sur telle ou telle partie du code, sans qu’ils ne se soient jamais vus. Cela confirme que les groupes, virtuels, se caractérisent généralement par une faible densité relationnelle, ce qui ne signifie pas que les interactions ne sont pas répétées, mais plutôt que leur contenu est peu personnel, peu affectif, abstrait6. Cette caractéristique n’est pas seulement une restriction dans les relations ; elle peut aussi être un atout, comme l’affirment certains participants, qui valorisent les échanges purement fonctionnels, focalisés sur la résolution de questions techniques et orientés vers le « faire ».
9Une fraction des participants, notamment ceux qui ont les connaissances informatiques les plus pointues, dénonce en effet la propension de certains autres à discuter sans fin, à multiplier les échanges improductifs, à développer des polémiques sans fondement, autant de pratiques dénoncées comme des « trolls ». Pour eux, l’anonymat n’est pas un obstacle à la relation et à la participation. Ils y voient au contraire une ressource, qui, en dépersonnalisant les échanges, les rendrait plus efficaces. Car il devient alors possible d’évaluer les contributions produites indépendamment de l’identité – inconnue – du contributeur et de formuler ainsi des jugements techniques ou « objectifs » sur son apport au projet, par exemple les lignes de code informatique qu’il a écrites.
10Les échanges à distance constituent, par rapport aux interactions directes en co-présence, un support relationnel moins solide. Et les retraits ou défections sont plus aisés et moins coûteux quand les participants ne se connaissent pas, ni de vue ni de nom. Toutefois l’interconnaissance peut se développer à distance. Le recours, systématique, à des pseudonymes en constitue un vecteur, même si de prime abord ils présentent peu de points d’appui pour développer les échanges dans la mesure où ils gomment les éléments qui dans une relation face à face constitueraient des repères d’identification (l’âge, le sexe, l’apparence physique7…). D’ailleurs les participants les moins impliqués ou insérés dans le groupe désignent les autres par ce qu’ils ont fait ou produit : selon nos observations un tel est « celui qui a fait le compilateur », tel autre est « un codeur hyper balèze », tel autre est « à l’origine du mag », etc. Mais pour les participants plus réguliers le pseudonyme – conservé dans la durée – est un signe d’identification, qui permet de réguler et soutenir les échanges au cours du temps.
11Ces échanges se nouent autour de l’activité de développement technique du logiciel. Et celle-ci a été progressivement organisée, à mesure que le collectif grossissait et que les intérêts et compétences des participants se diversifiaient, en sous-espaces de travail. Or cette spécialisation permet de réduire l’hétérogénéité des participants, et de favoriser les interactions. Car une trop grande disparité dans les attentes et les compétences a des effets démobilisateurs : les préoccupations d’un novice en informatique et d’un expert des langages de programmation ont peu de points d’intersection, et leur participation à une même liste de discussion risque de provoquer des incompréhensions réciproques, sources d’insatisfactions. La spécialisation permet de réunir des pairs, ou quasi pairs, dans des espaces (sites spécialisés, forums de discussion) bien différenciés. Cela renforce l’interconnaissance entre participants, qui nouent ainsi des contacts réguliers, échangent sur des sujets variés et rompent au moins partiellement l’anonymat initial.
12Le support technique qui favorise le plus l’interconnaissance est l’IRC – un dispositif technique d’interaction en temps réel –, car les échanges y sont synchrones, ont la forme de conversations, et autorisent la participation (passive ou active) de toutes les personnes connectées. La finalité de ces IRC est clairement inscrite dans l’objectif plus global de production logicielle, comme l’indique la différenciation de ces fils de discussion entre développeurs (plus ou moins chevronnés) et utilisateurs (plus ou moins incompétents). Mais les échanges portent sur de nombreux sujets, ancrés dans le développement du logiciel (discussion sur la pertinence de travailler à telle ou telle fonctionnalité), liés au monde des logiciels en général (discussion sur la nouvelle version de tel ou tel produit), relatifs à la vie privée (confidences sur la vie de famille), ou basculant dans le registre humoristique qui crée une autre forme de complicité (échanges de blagues, adresses de vannes à tel ou tel). Ces échanges renforcent les liens entre les participants, parce qu’ils y introduisent des repères et des signes qui organisent et orientent les interactions ordinaires (opinions, idées, informations personnelles, plaisanteries, etc.).
13Toutefois la spécialisation des espaces d’échange, et de travail, comporte un risque d’érosion de la cohésion d’ensemble, chaque participant pouvant s’identifier au segment dans lequel il investit son activité plutôt qu’au projet dans son ensemble, à la « communauté Spip ». Ainsi des initiatives ont été lancées, qui contribuent à améliorer la cohésion et à renforcer les relations entre les participants. Elles sont transversales aux espaces de travail spécialisés, et sont basées sur la co-présence. Il s’agit d’abord de réunions décentralisées et récurrentes dont la finalité première est la rencontre et l’objectif le développement de la sociabilité, comme l’indique clairement leur nom : « apérospip » ou encore « spip-partys ».
14Ces rencontres permettent de connaître les personnes derrière les pseudonymes, puisqu’elles sont l’occasion de livrer des informations sur soi-même (ne serait-ce qu’à travers sa tenue vestimentaire, son attitude, sa façon de parler) et d’en glaner sur les autres. Les activités qui y sont réalisées sont très diverses, depuis de l’écriture collective de code informatique jusqu’à des conférences ou des débats sur des sujets relatifs aux logiciels libres. S’y nouent aussi des relations plus informelles et interpersonnelles. Enfin, quel que soit le format des rencontres directes, les interactions qui s’y déroulent sont aussi pour partie asymétriques, dans la mesure où ces réunions permettent aux leaders du projet Spip (pour l’essentiel ceux qui l’ont initié) de distiller des informations relatives à la stratégie de développement et destinées à mobiliser autour des orientations privilégiées, à légitimer les options favorisées, et donc à piloter le projet et le collectif.
Des reconnaissances différenciées
15La reconnaissance des engagements et des participations est un autre levier de consolidation du collectif, permettant à la fois de resserrer des appartenances, d’éviter des défections, et de diffuser des attentes normatives à l’égard des participants. Cette reconnaissance se traduit dans des délégations de responsabilités, à des contributeurs à qui sont confiées l’animation de sous-espaces de travail ou la coordination de certaines tâches. Si la qualité, technique, des contributions au logiciel est une composante importante de cette reconnaissance, celle-ci s’ordonne aussi en fonction de la stabilité des engagements et des orientations idéologiques des participants.
16La délégation de responsabilités est pour partie une conséquence mécanique du succès du logiciel, qui a drainé vers les initiateurs (trois personnes à l’origine) des flux croissants de demandes d’aide de la part d’utilisateurs peu avertis ou de contributions excessivement hétérogènes, autant d’éléments exigeant un traitement rapide. Elle participe aussi à la gestion du groupe et de ses participants. Et elle est vécue comme une reconnaissance des efforts et des apports fournis, comme une valorisation des contributions pour lesquelles les individus ont payé de leur personne : « je trouve normal qu’à un moment, ben on te dise : voilà ce que tu fais est valable, alors tu vas avoir plus pour organiser les choses quoi ». Elle est même parfois considérée comme l’obtention de véritables postes marquant une progression dans l’organisation du projet, symbolisant une promotion : « on fait ça bénévolement, mais ça veut pas dire qu’il faut pas aussi une reconnaissance, bon de dire de grimper un peu dans le truc quoi ».
17Qu’est-ce qui, dans les contributions et les engagements individuels, est reconnu et valorisé ? Les rétributions répondent systématiquement à des contributions significatives, ce qui signifie que celles-ci combinent plusieurs qualités : elles correspondent à des réalisations techniques importantes, elles impliquent une dépense temporelle élevée, elles s’étalent sur une durée suffisamment longue. Ces qualités sont des propriétés continues, de sorte que leur identification implique une activité de jugement et d’évaluation. Il n’est jamais aisé de les apprécier avec précision, et les estimations qui en sont faites peuvent s’avérer erronées, comme l’indique un des fondateurs du projet : « pour les gens, c’est un peu comme une sucette, c’est plus qu’une récompense, c’est être un chevalier anobli. Nous ce n’est pas notre esprit, mais c’est vécu comme ça ». Quoi qu’il en soit, les contributeurs les plus compétents en ce qui concerne la programmation informatique font l’objet d’une attention toute particulière, parce que leur production est précieuse, même si le sens de leur engagement n’est pas clairement lisible. Des positions leur sont attribuées, où ils peuvent exercer leur créativité : certains espaces essentiellement techniques leur sont dédiés (Lab, Dev, Zone). Ils font donc l’objet de processus spécifiques de reconnaissance et de valorisation.
18Au-delà des qualités des contributions, c’est la fiabilité du contributeur qui fait l’objet de jugements, et qui constitue une information pertinente, voire décisive, pour la délégation de responsabilité. Cette fiabilité se rapporte à la posture adoptée à l’égard du projet, qui se décline en deux dimensions distinctes et largement indépendantes. La première renvoie à la participation à la production, à la capacité à concrétiser des contributions ou mener à bien des projets qui exigent de la ténacité. La fiabilité signifie ici tenir ses engagements, même implicites, et avoir assez d’autonomie pour produire des apports tangibles : « celui qui s’investit beaucoup, tu le repères vite. Même si ce n’est pas un as de l’informatique, quelqu’un qui s’accroche, qui va au bout de ses intentions, c’est très important […] La question c’est de savoir si on peut compter dessus, et jusqu’où » (un des fondateurs). La seconde dimension concerne le sens de l’engagement, et non plus son résultat. Elle renvoie à l’adéquation à l’esprit du projet – et non plus à sa production –, dont, en l’espèce, la coloration et l’identité idéologique sont affirmées. La fiabilité est traduite ici dans des affinités idéologiques, en particulier l’accord explicite avec les principes d’un web indépendant à l’origine du projet Spip : « et alors aussi, avoir des gens en accord avec l’esprit du projet, c’est quelque chose qui compte » (un des fondateurs). Cela n’implique aucunement des engagements et participations dans des organisations militantes ou politiques, mais cela suppose l’expression d’orientations en valeur justifiant la participation au projet.
19Cette régulation des reconnaissances par les valeurs n’est pas toujours exprimée explicitement, mais elle se traduit par la volonté de mieux connaître des contributeurs qui, par leur production, apparaissent fiables. Sont alors organisés des contacts informels ou privés avec des membres du noyau des fondateurs qui pilote le projet (conversations téléphoniques, rencontres directes, déjeuners, etc.) permettant d’apprécier – ou plus exactement de vérifier-quelles valeurs sous-tendent l’engagement : « quelqu’un qui fait un tel boulot peut pas non plus être un gratos et tout, ça ne peut pas être une enflure dangereuse. Enfin, il a fait le gros truc […] Alors là, on essaye de se faire une bouffe, on se rencontre, pour voir les gens quoi » (un des fondateurs). Cette deuxième épreuve, après celle de la contribution, est d’autant plus affirmée que les responsabilités à déléguer sont importantes.
20Ainsi l’incertitude inhérente au jugement à distance est réduite par la rencontre directe. Ces contacts directs permettent de vérifier une convergence de points de vue sur les orientations du projet, une adhésion aux principes de fonctionnement collectif, un partage de l’attachement à l’identité du logiciel, une proximité des significations associées à la participation à l’entreprise collective, bref un ensemble d’affinités en valeurs : « c’est important de pouvoir avoir un peu plus de profondeur dans la relation, pour voir un peu si on a la même vision des choses, la philosophie de SPIP du moins. Sinon on va aller au conflit avec des personnes qui ont des responsabilités, et ça va rejaillir sur toute la communauté » (un des fondateurs). La rencontre directe est donc un moyen d’informer l’engagement dans le projet des éventuels futurs administrateurs, non plus à partir des traces concrètes et matérielles de cet investissement telles qu’enregistrées dans les sites, forums de discussion, listes de messages, mais à partir de traces symboliques et immatérielles, renvoyant aux significations subjectives de cet investissement.
Un contrôle social diffus
21Un autre mécanisme de structuration des engagements s’appuie sur la production discursive de jugements – et non sur l’attribution de positions dans l’organisation – et débouche sur la construction de réputations – et non la délégation de responsabilités. Le projet Spip est soutenu par des orientations idéologiques anticapitalistes et contestataires. Or cette visée participe à la construction d’ordres de légitimité qui servent de référence pour la valorisation différentielle des attitudes et conduites des contributeurs : l’enracinement dans une mouvance militante de gauche est à cet égard renforcé par l’affirmation d’un principe de désintéressement, qui dévalorise ipso facto les usages commerciaux du logiciel. Nous avons pu observer plusieurs leviers destinés à maintenir ce cadre normatif et à contrôler les participants qui s’en écartent.
22Le référentiel originel du projet est rappelé, publiquement, en de multiples circonstances, afin de socialiser des participants, nouveaux ou peu au fait des soubassements idéologiques de Spip. Par exemple, le lancement en 2005 d’un nouvel espace de développement (Spip-zone) est l’occasion de mettre l’accent sur les valeurs originelles, qui sont explicitées dans une charte destinée à encadrer la participation et à réaffirmer nettement l’identité du projet. Cette initiative, lancée par quelques proches du noyau, vise à contrecarrer la place croissante prise par des contributeurs qui affichent explicitement leur statut de consultants et leur intérêt commercial à participer au développement du logiciel. Ainsi cette charte précise :
« la participation à la SPIP Zone doit être faite dans le cadre […] de la liberté d’expression de tous sur Internet […] Cela implique, entre autres […] une priorité accordée aux besoins associatifs sur les besoins marchands, etc. Ce site n’est pas une plateforme de développement pour des versions militaires ou business-oriented de SPIP qui viendraient en changer la nature. Il n’a pas non plus vocation à servir de support de communication ou de publicité pour consultants ».
23D’autres règles émergent progressivement, dont l’objectif est explicitement de freiner l’intervention de « marchands », ceux dont l’intérêt est « de se faire mousser » en multipliant les signatures personnelles dans tous les fils de discussion. Le dispositif interdit ainsi l’usage de noms commerciaux ou de référence à des sites d’entreprises. Plus globalement, il s’agit d’éliminer les comportements pouvant être apparentés à des opérations de marketing, car « enfin on essaie d’avoir une communauté pour aider les gens et que pour monter un site on n’a pas besoin d’appeler une SSII et de sortir son carnet de chèques » (l’un des fondateurs).
24Les éventuelles utilisations du logiciel Spip à des fins marchandes, comme la vente de services associés, sont ainsi dévalorisées et disqualifiées. Cette condamnation est effectuée en toute généralité, car elle vise à cadrer les participations tout en évitant de possibles retraits. Il s’agit de maintenir l’identité du logiciel, et la survie du projet, en préservant les apports de contributeurs qui s’investissent dans le projet tout en développant leurs propres activités commerciales de vente de services informatiques autour du logiciel. Ainsi la participation n’est jamais réductible à la contribution. Elle est soutenue par un engagement, elle se traduit dans des postures et attitudes, qui sont perceptibles dans les interventions sur les forums ou les mailing lists.
25Aussi les échanges entre participants sont autant d’occasions de dévaloriser et sanctionner les conduites jugées en contradiction avec les principes sous-jacents au projet. Ainsi certains contributeurs refusent de fournir de l’aide à d’autres contributeurs réalisant des projets pour des causes politiques opposées (industrie de l’armement, sites de parlementaires ou de partis de droite, etc.), font connaître leur position sur les mailing lists, et contribuent ainsi à exercer une sorte de contrôle social diffus. Réciproquement, d’autres contributeurs ayant une activité de consultant indépendant autour de Spip, expérimentent le sens des limites à ne pas dépasser, et adoptent par exemple des stratégies de participation prudente et contrôlée :
« par rapport à la communauté, il y a des aspects qui ont été mal perçus […] comme si mon comportement était de chercher de la clientèle à tout va, partout, en permanence, de rêver clientèle, de dormir clientèle, de manger clientèle, d’écrire clientèle. Donc, quand j’ai compris que ça gênait un peu trop la communauté, j’ai diminué ma signature dans le groupe des développeurs ».
26Un autre mécanisme de production de jugement est à la fois plus collectif et plus personnalisé : il est actionné par une pluralité de contributeurs au cours d’échanges publics, et il est orienté vers certains participants expressément ciblés. Les forums de discussion (IRC) constituent à cet égard une ressource importante pour la diffusion de valeurs et de règles de conduite, la production de jugements et de réputations. Les cibles de ces échanges sont invariablement ceux qui sont soupçonnés de s’écarter des cadres de l’engagement, de déroger aux règles implicites, de transgresser les valeurs communes. Par exemple quand un participant, par ailleurs consultant indépendant, propose une contribution permettant de visionner des photos sur les sites faits sous Spip grâce à un logiciel gratuit de Google, il est vertement critiqué par cinq participants (dont deux ont une position forte dans la communauté) : « fils de pub », « on a dit pas de pub », « t’es l’agent de qui », « tu pues le fric », etc.
27Un risque inhérent à ces recadrages est de provoquer le retrait des développeurs stigmatisés, comme l’indique en creux l’un d’entre eux : « ça m’a appris une première leçon, c’est : pour participer à la communauté Spip, il faut beaucoup d’abnégation. C’est-à-dire, accepter de prendre des baffes, et continuer quand même ». Une telle défection représenterait une perte d’autant plus importante pour le groupe que les consultants ont souvent des compétences techniques pointues. C’est pourquoi ces recadrages s’effectuent souvent sur un registre humoristique et, surtout, peuvent à tout moment être atténués par d’autres membres, plus sensibles au risque de défection, puisqu’ils sont effectués sur des forums ouverts à tous les participants.
28En général, ces recadrages sont ciblés sur des conduites, peu répandues et assez concentrées, qui manifestent des usages marchands, profitables, du logiciel Spip. Elles sont le fait de contributeurs qui ont des activités de consultants en informatique, et dont les contributions, même très solides, sont fréquemment interprétées comme des instruments de leurs propres stratégies marchandes plutôt que comme des apports désintéressés au projet collectif. L’un de ces contributeurs rend compte de ce qui est perçu par les autres comme une contradiction, une incompatibilité : « je suis amoureux de la communauté Spip […] Mais je suis un marginal dans la communauté parce que je n’ai pas encore réussi à trouver les mots pour faire comprendre que je suis à la fois à fond pour la participation à ce projet et que, en même temps, j’ai besoin de pépettes ». Ainsi la signification des engagements est aussi une production collective car elle interagit avec les valeurs associées à l’action collective, car elle fait l’objet de perceptions, interprétations, jugements, produits par les autres participants.
29Le collectif étudié présente deux caractéristiques saillantes : il est orienté vers la production d’un logiciel, et il fonctionne au quotidien – mais pas de manière exclusive – à partir d’échanges médiatisés par internet. La réussite du projet dépend directement de la capacité à attirer et retenir des contributeurs. Si cela interdit l’instauration de filtres à l’entrée, l’observation prolongée des échanges entre participants met en évidence une multiplicité de processus qui soutiennent et structurent les engagements individuels. D’abord, les participants sont reliés par les fils d’une sociabilité diversifiée qui contribue à renforcer la cohésion du collectif. Parallèlement des reconnaissances différenciées de leurs activités sont distribuées, qui prennent en compte leurs apports techniques mais aussi leurs orientations en valeurs. Enfin la production de jugements discursifs soutient un contrôle social diffus permettant de contenir les conduites déviantes par rapport aux visées idéologiques supportant le projet.
30Dès lors, participer ce n’est pas seulement contribuer au développement d’un logiciel, c’est aussi s’inscrire dans des flux d’échanges multiples, réglés par des normes et valeurs collectives. Certes, la production du logiciel suppose de maintenir, à travers l’agencement de contributions éparses, l’identité et la cohérence du produit. Mais elle implique aussi de soutenir et cadrer les engagements individuels, afin de fabriquer un collectif cohérent. La cohésion du collectif n’est donc pas donnée d’emblée, comme l’idéologie indigène valorisant le référentiel communautaire le laisse entendre. Elle est produite, entretenue et renforcée dans les cours d’action et des interactions entre participants.
Notes de bas de page
1 Demazière D., Horn F., Jullien N., « Le travail des développeurs de logiciels libres. La mobilisation dans des communautés distantes », Cahiers lillois d’économie et de sociologie, 45, 2005, p. 171-194.
2 Proulx S., Latzko-Toth G., « La virtualité comme catégorie pour penser le social : l’usage de la notion de communauté virtuelle », Sociologie et sociétés, XXXII-2, 2001, p. 99-122.
3 Raymond E. -S., La cathédrale et le bazar, 1998. [Traduction de Blondeel S.] ; http://www.lifl.fr/~blondeel/traduc/Cathedral-bazaar/Main_file.html ;. Hertel G., Niednet S., Herrmann S., « Motivation of software developers in Open Source projects : an Internet-based survey of contributors to the Linux kernel » Research policy, vol. 32, 2003, p. 1159-1177. Moon J., Sproull L., « Essence of distributed work : The case of the Linux kernel. » in Hinds P., Kiesler S. (eds.), Distributed Work, Cambridge, MIT Press, 2002, p. 381-404.
4 Horn F., L’économie des logiciels, Paris, La Découverte, 2004.
5 Demazière D., Horn F., Zune M., « Des relations de travail sans règles ? L’énigme de la production des logiciels libres », Sociétés contemporaines, 66, 2007, p. 101-123.
6 Etzioni A., Etzioni O., « Face-to-Face and Computer-Mediated Communities. A Comparative Analysis », The Information Society, 15-4, 1999, p. 241-248.
7 Velkovska J., « L’intimité anonyme dans les conversations électroniques sur les webchats », Sociologie du travail, 44-2, 2002, p. 193-213.
Auteurs
Le texte seul est utilisable sous licence Licence OpenEdition Books. Les autres éléments (illustrations, fichiers annexes importés) sont « Tous droits réservés », sauf mention contraire.
La proximité en politique
Usages, rhétoriques, pratiques
Christian Le Bart et Rémi Lefebvre (dir.)
2005
Aux frontières de l'expertise
Dialogues entre savoirs et pouvoirs
Yann Bérard et Renaud Crespin (dir.)
2010
Réinventer la ville
Artistes, minorités ethniques et militants au service des politiques de développement urbain. Une comparaison franco-britannique
Lionel Arnaud
2012
La figure de «l'habitant»
Sociologie politique de la «demande sociale»
Virginie Anquetin et Audrey Freyermuth (dir.)
2009
La fabrique interdisciplinaire
Histoire et science politique
Michel Offerlé et Henry Rousso (dir.)
2008
Le choix rationnel en science politique
Débats critiques
Mathias Delori, Delphine Deschaux-Beaume et Sabine Saurugger (dir.)
2009