L'ENRACINEMENT DANS UNE COMMUNAUTÉ D'EXPÉRIENCES

10 Le logiciel SPIP est déjà le résultat d’une histoire, de plusieurs années, pendant laquelle des liens forts vont se tisser entre quelques personnes qui seront les initiateurs du projet, et qui, auparavant, partagaient des expériences entremêlant expérimentations sur internet, orientations politiques et bricolages informatiques. Les initiateurs du projet participent au milieu des années 1990 à différentes activités collectives orientées vers l’auto-publication sur Internet. Ces activités ont une composante technique puisqu’il s’agit de fabriquer des sites adéquats, permettant d’accueillir des textes et articles. Ce sont également des formes renouvelées de militantisme et de combat idéologique, car il s’agit de favoriser de nouvelles possibilités d'expression collective, en dehors des canaux médiatiques habituels, et de promouvoir ainsi un « web indépendant », une « expression libre » [5]. L'objectif est de disposer d'un outil performant et simple d'utilisation pour gérer des publications collectives, de manière à contrecarrer la montée en puissance des industries de contenu qui risque de ravaler les internautes au rang de consommateurs passifs d'informations formatées.

11 Le projet SPIP s'enracine ainsi dans une communauté d'expériences ayant des traits spécifiques : elle s'appuie sur des engagements individuels volontaires, elle se traduit dans des conduites orientées en valeurs, et elle soude des minorités actives. Il prend peu à peu sens, sans avoir été anticipé, programmé, porté sur les fonds baptismaux : « il n'y a pas de congrès fondateur dans l'arrière-salle d'un café [...].C'est juste parmi tous les projets, il y en a un, c'est SPIP. On va échanger nos bouts de codes » (un des fondateurs). Ce processus d'émergence a des conséquences décisives sur les caractéristiques du logiciel SPIP. Bien que celui-ci ne soit pas le produit d'une planification qui en aurait fixé les traits, il est néanmoins doté d'emblée d'une identité affirmée et durable. Les initiateurs de SPIP indiquent unanimement combien ce logiciel incorpore un vécu commun, comme si celui-ci avait été transféré et traduit dans un objet technique : non seulement l'interface est simple de manière à faciliter la prise en mains, mais le logiciel est économe en ressources techniques de manière à pouvoir être implanté sur des petits serveurs. Ainsi le recours à SPIP est accessible à de petites associations qui ne disposent ni de webmestres expérimentés ni d'une infrastructure informatique performante. De même les principes politiques et éthiques défendus en matière d'auto-publication s'incarnent dans les fonctionnalités du logiciel et en particulier dans les principes retenus pour l'administration des sites : limitation du nombre de niveaux décisionnels, mise en place de forums accompagnant chaque article publié, soin apporté dans les fonctionnalités typographiques, gestion du multilinguisme, absence de dispositif d'identification et de suivi des utilisateurs, etc. Ces articulations entre le projet politique originel et le produit logiciel donnent à celui-ci une identité particulièrement forte, puisque fixée dans des choix techniques, et revendiquée par les initiateurs. Obtenir une diffusion large du logiciel implique de faire partager cette identité, par des utilisateurs non chevronnés et par des contributeurs prêts à participer à son développement.

UNE CRÉDIBILITÉ TECHNIQUE ET POLITIQUE

12 La phase de lancement du logiciel a été initiée par une campagne de communication, alors que le logiciel n'est pas encore tout à fait opérationnel. Un des initiateurs multiplie les interviews et chroniques sur Internet. Il en ressort quelques messages percutants, comme « fini les webmestres avec SPIP », qui donne de la visibilité au logiciel. De plus, le contexte concurrentiel est favorable car s'il existe d'autres logiciels de conception de site web, aucun ne présente la facilité d'appropriation pour l'utilisateur et pour le contributeur, qui est au c ur de l'identité de SPIP et du projet, politique et technique, de ses concepteurs initiaux.

13 La publication du logiciel va permettre la mobilisation d'un troisième personnage-clé, engagé dans les mêmes activités de publication de webzines [6], dont les compétences informatiques sont plus pointues que celles des deux promoteurs initiaux. Ses compétences sont mobilisées par l'un des initiateurs, webmestre d'un journal mensuel de gauche, afin d'adapter le logiciel à la gestion du site Internet de ce mensuel, pionnier dans la mise en ligne de ses articles. Le passage du site de ce mensuel sous SPIP va renforcer son image et sa notoriété. Jusque là SPIP avait rencontré l'intérêt et la sympathie des webmestres d'associations de gauche et d'extrême gauche, qui participaient aux mêmes réseaux et milieux que les initiateurs du produit. Cette connivence perdure, mais s'y ajoute une crédibilité technique issue de la capacité du logiciel à fonctionner en grandeur réelle avec un site ayant beaucoup de trafic, alors qu'il a conservé sa simplicité de fonctionnement : « il tenait la charge, et ça c'était le gros, gros truc. C'était le problème que l'on avait [...] Pourquoi tout le monde faisait des systèmes compliqués avec du statique, c'est parce qu'on pensait que quand les gens viendraient visiter un site important le serveur tomberait [...] Et on a quand même bien pris la charge [...] et tout de suite ça crédibilisait ».

14 « produit amateur, programmé par un crétin », il devient « un produit qui tient la route ». Cette crédibilité technique ne se substitue pas à l'image politique du logiciel, elle ne la concurrence pas, mais la renforce. Cela tient principalement au fait que le premier médium important qui utilise SPIP pour son site Internet est un journal classé nettement à gauche. S'y ajoute une conjoncture favorable, issue de l'effondrement brutal de la « nouvelle économie ». Car cet épisode contribue à dissocier l'Internet de ses usages marchands, à changer l'image d'Internet dans les milieux de gauche, à démultiplier les montages ou rénovations de sites Internet : « c'est devenu un truc qui se faisait, c'était bien de faire son site soi-même. C'était bien puisqu'on avait perdu l'image des crétins de la nouvelle économie ». Si le lancement de SPIP est enraciné dans une communauté d'expériences partagées par la poignée d'initiateurs, son développement est aussi articulé à des groupes partageant des valeurs et des orientations idéologiques. Cet ancrage dans des réseaux qui ne se réduisent pas à des communautés virtuelles est un facteur favorable à la diffusion du logiciel, et cela d'autant plus que la crédibilité technique, acquise plus tardivement, pourra s'y greffer. Mais il reste que la prise de la greffe exige aussi de mobiliser des contributeurs plus nombreux et prêts à s'investir durablement dans le projet.

DES ENGAGEMENTS DIFFICILEMENT MAÎTRISABLES

15 La crédibilité acquise par SPIP n'est pas une ressource suffisante pour la construction d'une « communauté » de développeurs, même si elle en est une condition. Car la cristallisation d'une telle collectivité suppose de mobiliser et enrôler des personnes qui vont contribuer à la fabrication ­ et à l'évolution ­ du produit, quand cette crédibilité génère plutôt une demande, une clientèle. La multiplication d'utilisateurs d'un logiciel libre est un stimulant à la mobilisation de contributeurs ­ et vice-versa ­ mais elle ne s'y substitue pas, même si un des enjeux réside dans la conversion de simples utilisateurs en contributeurs ponctuels d'abord, plus réguliers ensuite. L'appui sur des réseaux de militance politique ou associative est un atout pour enclencher cette dynamique, qui mobilise nombre de webmestres de ces milieux. Cette diffusion génère rapidement un afflux de questions, demandes de conseils, sollicitations d'avis, postés sur le site du logiciel, et adressés, de fait, à la ­ petite ­ équipe initiale. Les trois personnes qui la composent sont alors contraintes d'augmenter leur investissement, qui s'ajoute à des activités professionnelles mobilisatrices même si elles ne sont pas dépourvues de liens avec leur engagement bénévole : l'une est webmestre d'un journal mensuel d'opinion qui adopte rapidement Spip, une autre effectue des missions de développement informatique avec un statut d'indépendant, la troisième est graphiste spécialisé dans l'édition d'ouvrages scientifiques, et une quatrième qui les rejoindra plus tard est enseignant-chercheur en informatique. De fait, la montée en charge, correspondant à une multiplication des utilisateurs s'accompagne ainsi mécaniquement d'une montée des charges pesant sur les initiateurs, et pilotes, du projet. Mais elle offre aussi des opportunités de sensibiliser les utilisateurs, de susciter des contributions, de les mobiliser en tant que développeurs. Elle peut alors se traduire par des demandes explicites et adressées à des interlocuteurs identifiés, portant sur des contributions mineures sur le plan du temps de travail correspondant, mais très utiles pour le développement du logiciel : déboguage, écriture de documentation, traduction dans des langues étrangères, mise à disposition des maquettes de présentation des sites réalisés.

16 Ce processus d'émergence d'une collectivité mobilisée autour du développement, de l'amélioration, de la mise à jour, de la diffusion, du perfectionnement, des logiciels libres correspond à une étape obligatoire, faute de quoi la différenciation reste trop marquée entre une minorité active, limitée au cercle des producteurs initiaux, et un cercle, de taille variable, d'utilisateurs. Car la production des logiciels libres récuse, précisément, la césure radicale entre producteurs et clients. Les initiateurs de SPIP soulignent tous la montée rapide d'un besoin et d'une évidence : « on a besoin que les gens s'investissent, s'investissent de leur temps », « c'est apparu évident qu'il nous fallait des gens qui s'engagent avec nous ». Les termes utilisés sont particulièrement significatifs de ce qui est attendu : à la fois une mobilisation fondée sur une adhésion au projet et au produit et impliquant d'y consacrer du temps, et un engagement qui soit aussi un investissement placé dans une entreprise collective et au service de celle-ci. En ce sens, la figure qui est invoquée n'est pas seulement celle du militant ou du bénévole qui soutient gratuitement une cause, c'est aussi celle du travailleur qui apporte sa pierre à une production collective. Ces travailleurs requis sont d'ailleurs caractérisés normativement par des traits relativement précis sinon classiques : ils doivent être « en mesure de se débrouiller », « capables de prendre des initiatives », mais aussi « fiables », « capables de tenir dans le temps ».

17 Le contributeur idéal est par conséquent un travailleur autonome et fidèle, ce qui signifie que son engagement individuel ne doit pas être le produit d'un travail de mobilisation, mais qu'il est conçu - rêvé - comme la conséquence automatique d'une adhésion au projet. Cependant, il s'agit bien d'une figure rêvée, voire mythique, dans la mesure où la conversion d'utilisateurs en contributeurs est marquée par l'incertitude, et où les engagements et investissements des développeurs ne sont pas si prévisibles. Les propos tenus par les membres du noyau qui pilotent le projet sont émaillés de commentaires exprimant ces écarts : « mon impression c'est que les gens ils ont peur de s'investir [...] ils demandent tout de suite à être confortés », « il y a un manque d'autonomie là-dedans, d'autodétermination, qui est flagrant », « même ceux qui font, ils sont toujours à s'excuser d'être là, c'est très étonnant », « beaucoup ne font que passer, ils sont enthousiastes, et puis, pfft, ça s'épuise vite ».

18 Dès que le cercle des contributeurs s'élargit au-delà du périmètre, étroit, des initiateurs, le travail de production du logiciel devient plus hétérogène, mêlant des travailleurs historiques dont la stabilité est nécessaire à la réussite de l'entreprise, et des intermittents qui fournissent un travail peu prévisible, mais aussi des collaborateurs plus réguliers qui produisent des contributions attendues. Le terme de « communauté » ne rend pas compte de ce caractère gradué des participations, qui n'est pas contradictoire avec une identification partagée au produit. Surtout la question se pose de savoir comment ces différenciations sont appréhendées, prises en compte, organisées et maîtrisées, de manière à piloter dans la durée une production collective du logiciel libre.

DIFFÉRENCIATION INTERNE ET DÉLÉGATION

20 Le déséquilibre entre un faible nombre de contributeurs ayant un investissement important et un grand nombre de contributeurs ayant un investissement limité s'auto-entretient, et même a tendance à s'aggraver, puisque les contributions des seconds sont adressées aux premiers, qui doivent les gérer et y répondre. D'une certaine manière la constitution d'une collectivité active provoque un épuisement du noyau, par accumulation de tâches. Cette tension est d'autant plus sensible que la dynamique collective est largement dépendante de la réactivité à ces demandes. Car fournir des réponses rapides n'est pas considéré comme une activité mineure, mais a un caractère stratégique, comme l'indique un des fondateurs : « animer la communauté c'est surtout répondre à des mails. Et ça c'est quand même une activité qui prend un temps absolument fou dès que le système a une certaine notoriété ». La délégation de certaines activités s'impose comme une nécessité à mesure que grossit le flux d'informations et sollicitations remontant vers les initiateurs qui pilotent le projet. Elle concerne des échanges avec des utilisateurs et des développeurs sur des questions réputées peu cruciales mais pourtant chronophages : répondre à des demandes d'aide, donner des conseils, donner un avis sur une contribution, évaluer une traduction, proposer une documentation, etc. Elle suppose de s'appuyer sur des animateurs, dont la tâche est de susciter l'entraide mutuelle, de stimuler des contributions, de lancer des projets, d'organiser les échanges, de structurer des discussions, de réguler les interactions, voire de trancher dans les désaccords. Ces activités acquièrent une reconnaissance officielle dès lors qu'elles débouchent sur la différenciation de listes de discussion et de sites spécialisés sur certains aspects de SPIP, dont la gestion est confiée à ces animateurs, qui en deviennent les administrateurs dotés de droits spécifiques. La délégation de responsabilités s'accompagne ainsi d'une sectorisation du développement du logiciel et d'une multiplication des espaces de travail (cf. encadré).

21 La double dynamique de structuration d'un cercle d'animateurs-administrateurs et de spécialisation des activités présente plusieurs avantages. Distinguer des espaces de travail spécialisés permet de réduire l'hétérogénéité des participants, qui croit rapidement avec leur nombre. 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 discussions risque de cantonner les échanges à des polémiques peu productives (des trolls  [8]). La spécialisation favorise le rassemblement de pairs, ou quasi-pairs, dans des espaces de travail bien différenciés. Par ailleurs ce mode de structuration a aussi une fonction de rétribution symbolique de certains travailleurs, puisque ceux qui sont désignés comme administrateurs de ces espaces bénéficient ainsi d’une reconnaissance de leur travail, de leur rôle, de leurs compétences, et se voient octroyer par délégation un pouvoir de régulation dans ces espaces. Cette différenciation des positions, qui se caractérise par la formation d'un cercle intermédiaire entre le noyau stratégique et les cercles périphériques (Demazière et al. 2006), est aussi un levier de mobilisation des participants les plus engagés, un moyen de stabilisation de ces fidèles, toujours exposés à la lassitude, un instrument pour officialiser la valeur de leur apport. Les rôles ainsi distribués ne se cristallisent pas dans des échelons hiérarchiques et n'alimentent pas des relations de subordination. Pourtant ils peuvent être considérés comme des quasi-statuts, et sont souvent vécus comme extrêmement valorisants. Mais ils définissent d'abord des responsabilités vis-à-vis du devenir du projet. C'est pourquoi la question du repérage des animateurs potentiels et de leur recrutement est un enjeu si important.

LES DIFFICULTÉS DU RECRUTEMENT

22 Les façons de recruter et la production de jugements de compétences sur les travailleurs sont marqués par de fortes incertitudes (Eymard-Duvernay, Marchal, 1997), car si les épreuves de jugements s'appuient sur des instruments d'évaluation multiples, l'interprétation des résultats et des indices qui en résultent demeure problématique (Bureau, Marchal, 2006). Ces difficultés sont décuplées dans le cas de la mobilisation de contributeurs à la production de logiciels libres, notamment parce que l'absence de codification de la prestation (absence de rémunération, de contrat, de règle juridique...) rapproche celle-ci des participations à des actions bénévoles faiblement institutionnalisées, volontaires et révisables à tout moment. Le contrôle social des engagements pesant habituellement sur les participants est d'ailleurs d'autant plus faible que les interactions sont médiatisées par le réseau Internet, que l'interconnaissance est très limitée, que le recours à des pseudonymes ou diminutifs est fréquent. La défection est donc peu coûteuse, et nombre de participations sont, de fait, ponctuelles, irrégulières ou erratiques. Mais les contraintes de l'activité sont différentes pour les animateurs et administrateurs, car leur fonction exige une certaine stabilité de leur participation. Et c'est pour cela que leur mobilisation, et en amont leur repérage par les membres du noyau stratégique, peut être considérée comme un protocole de recrutement. Ce recrutement est particulièrement délicat, puisque le caractère distant des relations complique la construction du jugement.

23 Une caractéristique constante de ce recrutement est qu'il prend la forme de promotions, dans le sens où les personnes concernées participent préalablement à la production du logiciel. C'est cette participation qui informe sur l'engagement et sur la compétence, c'est le travail réalisé qui fournit des indices de jugement. Pour autant la délégation de responsabilité ne se réduit pas à la reconnaissance de ce qui a été déjà fait ; car il ne s'agit pas de distribuer des « bons points », des « sucettes », des « médailles », mais d'engager quelqu'un sur qui compter à l'avenir, de faire un pari raisonné sur un travail futur. L'évaluation doit s'accrocher à des activités constatées, et la capacité à avancer dans la concrétisation d'un projet semble ici décisive. Ainsi plusieurs des animateurs de différents espaces de travail font le récit de cheminements parallèles : ils ont eu une idée susceptible d'améliorer l'organisation du travail, ils l'ont exposée aux membres du noyau, ils ont eu en retour une incitation à la mettre en pratique, ils ont montré leur capacité à le faire, et finalement ils ont été intronisés comme administrateurs du nouvel espace de travail : « au début on m'a dit'si tu veux participer il y a une liste de trucs à faire'. J'ai commencé à regarder un peu, mais le code de SPIP, c'est un peu hermétique pour moi [...] Et puis j'ai eu l'idée de monter un site pour les contrib., parce que ce n'était pas bien organisé [...]. Et donc on nous a dit, parce qu'on était deux à avoir cette idée, “et ben allez-y, faites-le”. Et alors on a avancé, et on l'a fait. [...] et alors c'est devenu officiel, l'espace pour les contrib., et c'est comme ça qu'après on est devenus les administrateurs ». La capacité à faire, et à réussir un projet, est un indice important dans l'évaluation, même si celle-ci ne préserve jamais du risque de défection soudaine et imprévisible de personnes jusque là fortement impliquées dans la conduite de projet et la coordination d'espaces de travail.

24 Or une des qualités attendues des administrateurs est leur capacité à tenir le rôle dans la durée, car leur stabilité, ou plus exactement celle de leur engagement et de leur investissement, est une ressource pour la réussite de l'action collective : « c'est difficile de juger, alors c'est vrai que de repérer des gens très actifs, très présents, qu'on connaît au bout d'un certain temps, qui ne font pas que passer. C'est un moyen de pas trop, enfin, en fait on ne sait jamais je crois » (un des fondateurs). En effet, l'anticipation des comportements d'autrui est irrémédiablement fragile. Et si l'observation de l'activité antérieure peut fournir des indications, il faut trouver le bon compromis entre un temps d'observation suffisamment long pour minimiser les risques de défaillance après l'accès au cercle des administrateurs et une mise à l'épreuve suffisamment courte pour minimiser les risques de défection précoce pour défaut de reconnaissance, ou par découragement. Aussi la rencontre directe supplée dans nombre de cas l'incertitude inhérente au jugement à distance, d'autant qu'elle permet d'introduire un nouveau registre d'évaluation. Plus les positions concernées sont proches du noyau stratégique, plus le recours à des interactions face à face est systématique. Ces contacts directs permettent de vérifier une convergence de points de vue sur les orientations du projet logiciel, 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, bref un ensemble d'affinités en valeurs, sinon une communauté d'expériences comparable à celle qui caractérise le petit groupe des initiateurs : « 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. C'est un peu tout ce qui est derrière, même si on n'a pas besoin d'être d'accord sur tout, mais dans les grandes lignes, oui. 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 possibles 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.

25 La délégation des responsabilités ne s'effectue pas seulement à partir du noyau stratégique, mais elle est aussi initiée par des administrateurs d'espaces spécialisés qui, eux aussi, sont débordés par leurs tâches. Dans ce cas, c'est l'intensité et la qualité de l'activité réalisée dans l'espace de travail considéré qui fonctionnent comme signal : « j'avais moins le temps, alors quand j'ai vu qu'il avait proposé un certain nombre de choses que, il y avait quatre ou cinq articles, alors je me suis dit, ce gars il traduit bien. Alors je lui ai donné les droits d'administration de la zone en espagnol ». La procédure d'évaluation qui sous-tend le recrutement est ici faiblement outillée, et le risque de faire de mauvais recrutements semble élevé : « les gens attendent d'être administrateurs, et puis en fait quand ils deviennent administrateurs, ils ne font plus rien parce qu'ils ont le privilège et puis ça leur suffit. Il y en a plein des comme ça, il y en a même majoritairement des comme ça ». C'est dans les espaces de travail organisés autour de l'activité de programmation, d'écriture du logiciel, que ces erreurs de recrutement semblent les plus fréquentes, parce que la reconnaissance du travail fourni est, ici plus qu'ailleurs, susceptible d'être utilisée et reconvertie dans la sphère marchande : « On a fait des mauvais recrutements, des mauvais choix, on ne sait pas, il y a des gens qui étaient admin et puis en fait ça n'a servi qu'à favoriser leur carrière personnelle ou professionnelle. C'est juste une carte de visite, donc pas très intéressant. »

LA GESTION DES DÉFAILLANCES

26 Les défaillances correspondent à des cas de figure où le travail attendu n'est pas ­ ou mal ­ réalisé, ce qui indique que cette catégorisation est produite par des personnes qui ont la légitimité de juger, et donc qui occupent dans le collectif de projet une position plus centrale que celle de la personne évaluée. Être défaillant c'est ne pas remplir ses engagements, lesquels sont plus implicites et moins impératifs à mesure que l'on passe du noyau stratégique au cercle intermédiaire et aux zones périphériques. En pratique, la défaillance est tolérable quand le travail est distribué entre un grand nombre de personnes qui contribuent chacune de manière limitée à la production collective. La question de la défaillance se pose donc pour ceux qui occupent des positions de responsabilité. En l'absence de rapports contractualisés ou salariaux, les instruments de sanction sont rares, et l'éviction, sorte d'équivalent du licenciement dans les collectifs d'engagements volontaires, est un levier peu opératoire car dangereux : du fait de la faible institutionnalisation de l'action organisée, elle risque de détériorer la cohésion interne, indispensable à la production collective du logiciel. Pour les administrateurs, même les conduites les plus opportunistes, jugées déviantes par rapport aux règles, implicites, attachées à la participation et a fortiori à la prise de responsabilité, sont délicates à sanctionner : « il est arrivé une fois que, des gens qui se sont vus admins, ils ont commencé par s'autovalider, enfin valider leurs contribs à eux. [...] On n'a pas gueulé mais, on a dit c'est pas le but du jeu. Devenir administrateur pour valider ses contrib., c'est un peu puéril ». Les sanctions effectives, tel le retrait de droits d'administration, se sont souvent révélées inefficaces, en raison du caractère distribué des prérogatives : «  on a dit'tiens toi tu fais rien donc on t'enlève tes droits' (...(et puis il a dit'ça sert à rien' [...] C'est-à-dire, ça sert à rien de lui retirer les droits. [...] Il avait retrouvé un copain parmi la trentaine d'admin qui lui avait redonné ses droits. [...] Parce qu'un admin peut transformer quelqu'un en admin ».

27 Aussi la gestion des défaillances passe rarement par la sanction directe des défaillants, mais utilise deux autres leviers. Le premier vise à redynamiser un espace de travail dans lequel les administrateurs sont faiblement investis, en faisant l'annonce publique d'un retrait, manifestant un ras le bol face à la charge de travail et destiné à provoquer une remobilisation des animateurs défaillants. Le second levier, plus indirect encore, consiste à créer de nouveaux espaces de travail, dont les fonctions sont proches, mais pas similaires, à un espace existant qui est déréglé ou n'apporte plus de contribution suffisante au projet. L'objectif est d'ouvrir un nouvel espace d'engagement, quitte à ce que cela se fasse à partir d'un écrémage des participants défaillants, qui par le jeu de la multiplication des nouveaux espaces sont repoussés, de fait, dans des positions plus périphériques, moins stratégiques : « une idée pour essayer de bouger la communauté, c'est Spip-zone [...] avoir en tout cas un endroit technique où les gens peuvent committer [9], faire évoluer des choses, et par exemple des grosses contribs, qui sont en train de végéter dans l'espace privé de Spip-contrib » (un fondateur d'un nouvel espace de travail).

28 Ces observations montrent le caractère fluide des relations de travail au sein des collectifs de production de logiciels, et indiquent que leur fonctionnement ne peut être retracé sans une mise en perspective temporelle. Car, ces actions organisées étant dépourvues des ressources mobilisables ordinairement pour la gestion des organisations de travail, elles sont l'objet de reconfigurations continues, qui en modifient la structuration interne et les contours externes. Compte tenu de ces processus, se posent avec acuité les questions du maintien dans le temps de l'identité du logiciel et de la consolidation de l'action collective qui le produit.

ÉVALUER LE TRAVAIL ET SÉLECTIONNER LES PRODUCTIONS

30 les bugs, et, si possible, de proposer des ajustements du code permettant de les résoudre. La fiabilité du produit repose en effet sur la mutualisation rapide des résultats d'un grand nombre de tests en situation d'usage. Si les corrections de bugs sont prises en compte, de manière quasi-automatique, d'autres contributions sont évaluées et font l'objet d'une sélection. Ce sont celles qui sont destinées à enrichir le logiciel, à le compléter, à ajouter des fonctionnalités. Ces contributions ont un tout autre statut : elles risquent d'affecter l'identité du produit, et sont, la plupart du temps rejetées par les leaders. Ceux-ci constituent un petit noyau formé par les trois fondateurs de SPIP, rejoints par des nouveaux membres qui ont apporté des contributions importantes, et qui adhèrent sans restriction aux principes sous-jacents au logiciel et partagent des orientations idéologiques proches. Ce noyau a le monopole de la validation des contributions et des droits d'écriture. Le rejet est souvent argumenté au motif que les contributions concernent des usages spécifiques et des applications particulières : « ce sont des grosses modifications qui n'intéressent qu'une fraction des utilisateurs ». Parce qu'elles sont importantes et exigent un travail de conception conséquent, ces contributions sont souvent proposées par des entreprises de services informatiques qui ont fait des développements pour un client et qui demandent leur intégration dans SPIP. Le refus est alors systématique : « une entreprise qui développe du SPIP, elle le développe pour ses clients et des besoins très spécifiques [...] nous on s'enquiquine systématiquement à généraliser tous les problèmes et donc les rapports deviennent assez rapidement tendus parce qu'une bonne idée pour un client n'est pas forcement une bonne idée pour les autres » (un des fondateurs).

31 et n'est jamais accepté d'emblée, car sa compatibilité avec les développements envisagés ou engagés par le noyau stratégique doit être préalablement vérifiée. Cela suppose une concertation et une collaboration avec des membres du noyau, ce qui correspond à un long processus d'ajustements rendant la prise en compte de la contribution in fine évidente et indiscutable. Ce processus est particulièrement visible dans un cas, qualifié par certains de « parcours du combattant », par d'autres de « contre-exemple », qui concerne une contribution « majeure », proposé par une personne qui a ensuite été intégrée au noyau stratégique et est devenue, au terme de ce processus, le « quatrième mousquetaire ». À partir du moment où celui-ci propose un compilateur, s'engage une série d'échanges avec des membres du noyau qui s'étale sur une année, pendant laquelle il fait évoluer sa contribution, travaille avec acharnement, propose six versions successives, ce qui fait dire à un des animateurs du site de contributions « je crois que pendant un an en fait, enfin il a eu le courage et la force de re-proposer à chaque fois sa contrib et, voilà, pour finir ça a été intégré au noyau ». Finalement, à partir du moment où le principe de sa contribution est retenu, il travaille plus de six mois avec un des membres du noyau pour réécrire le code proposé, « la tête dans le guidon », « comme des dingues ».

32 Différents mécanismes conduisent à ce que le noyau stratégique exerce une sorte de monopole sur le développement : validation des contributions mineures, contrôle de l'accès en écriture, implication dans la production des contributions externes jugées significatives. La différenciation entre ce noyau et l'ensemble des autres participants apparaît ainsi très tranchée, même si le noyau n'est pas un cercle fermé puisque de nouveaux membres y sont intégrés. Ce clivage apparaît comme un moyen de préserver l'identité du logiciel dans un contexte de croissance et de diversification des participants. Mais il conduit à poser le problème, conjoint, de la cohésion du groupe.

LES CIRCUITS DE DÉCISION ET DE DISCUSSION

33 La sélection des contributions, ou le monopole des droits d'accès en écriture, ne sont pas des leviers suffisants pour maintenir l'identité du logiciel produit, car celle-ci est également dépendante de l'adhésion de membres à un produit et à un projet. En ce sens, la fabrication d'une « communauté » est une dimension aussi importante que la fabrication d'un logiciel. Une part non négligeable de la participation se traduit dans des échanges, débats, discussions (sur les mailing list, les forums, le chat...), de sorte que le travail réalisé ne se réduit pas à l'addition de contributions individuelles, mais que sa signification réside aussi dans sa dimension délibérative. La mobilisation et la participation sont composites : à la fois du débat et de la délibération, et en même temps de la production et de la fabrication, ce que certains participants résument en différenciant les « trolleurs » et les « codeurs ». Les « communautés » sont traversées par cette tension (qui peut aussi cliver les individus eux-mêmes), et la recherche de compromis et d'équilibres est indispensable au maintien de ces collectifs.

34 Dans le cas de SPIP la fabrication de la cohérence du logiciel et de la cohésion du collectif s'articule à une gestion très fine des débats et discussions, qui peut être formulée ainsi : « tout est public, sauf ce qu'il faut vraiment pas que ce soit public. C'est plutôt ça que l'inverse, que tout est privé et de temps en temps on fait une annonce de comm ». (un des fondateurs). Toutes les listes de discussion, c'est un principe général dans la production des logiciels libres, sont publiques (n'importe qui peut s'y inscrire) et archivées, ce qui garantit la « transparence ». Mais ces listes ne sont pas les seuls vecteurs d'échanges, d'autres canaux, privés, peuvent être utilisés : échanges de mails personnalisés, coups de téléphones, rencontres directes. Les échanges non publics sont fréquents à l'intérieur du noyau stratégique : « on participe à des conversations, à des discussions qui ne sont pas, qui sont... comment dire, secrètes, qui sont en avance, qui ne sont enfin pas secrètes mais discrètes ». Les justifications qui en sont produites sont toutes orientées vers l'objectif de préservation de la « communauté » et de son projet. Il s'agit d'abord d'un moyen de régler des désaccords internes, de traiter de « divergences », de « re-synchroniser un peu nos objectifs », sans étaler publiquement les différends, afin de montrer l'unité du noyau. Il s'agit de produire des décisions collectives (entre membres du noyau) concernant le pilotage stratégique du projet, les développements futurs du logiciel, les chantiers à engager, les options à privilégier : « il y a beaucoup, beaucoup de discussions effectivement en interne [...] Y compris sur liste privée, enfin ce n'est pas une liste dont on va parler. Il y a pas mal de choses sur les grandes orientations, de choses vraiment lourdes, enfin des choses qu'il faut mettre en chantier. Et il faut qu'on sache si on va le faire, si on va pas le faire, si on va s'orienter vers là, parce que c'est lourd ». Cette discrétion est congruente avec le monopole des membres du noyau dans les procédures de décision de prise en compte de contributions externes. Elle est aussi un élément de gestion de l'action organisée, dans la mesure où elle est destinée à éviter tout risque de démobilisation lié à des effets d'annonce sans lendemain, au renoncement à des pistes perçues par certains comme passionnantes : « si on lance ça sur les sites publics tout de suite on va faire du vaporware [10], on va avoir des gens qui vont s'enthousiasmer pour un truc qui va pas être, qu'on va laisser peut-être en plan plus tard ». conduire à modifier le produit. La mise en discussion publique de pistes de travail est un moyen d'obtenir une large adhésion par élargissement du socle des personnes informées et concernées avant l'annonce de la décision : « alors après il y a des moments où on se dit : “tiens, cette discussion-là, en fait ce serait plus intéressant qu'elle ait lieu en public, sur la liste des développeurs ; et effectivement celle-là il vaut mieux qu'elle reste privée parce que c'est une perspective qui est beaucoup trop lointaine et ça ne sert à rien d'aller polluer la liste avec ça”. Mais après, il ne s'agit pas d'aller faire des cachotteries entre utilisateurs ou aux autres contributeurs » (un membre du noyau). Les échanges ouverts et publics, parfois assortis de consultations discrètes de tel ou tel administrateur ou développeur, alimentent la réflexion des membres du noyau, et participent à la légitimation de leurs décisions, en amont de celles-ci ou du moins de leur annonce publique. Celle-ci est aussi un moment privilégié d'explication et justification des décisions, en particulier en mobilisant l'argument de la cohérence du produit : « nous on insiste pour avoir une certaine cohérence et une logique d'intégration et que c'est un produit intégré, les gens comprennent assez bien. On a pas de gros choc, après que le type débarque, trollant sur la liste pour dire : “c'est de la merde, ça fait pas ça”. Tout le monde s'en fout [...] grosso modo la communauté comprend qu'il y a une logique, un produit à préserver » (un des fondateurs). Cette méthodologie de la décision est destinée à entretenir l'adhésion du plus grand nombre au projet, à répondre aux objections enracinées dans des positions particulières, à situer les choix effectués au sein d'une stratégie globale qui les justifie. Le noyau stratégique est à la fois au point d'origine et au point d'arrivée, il est à la source des débats et à leur conclusion, il encadre, dans tous les sens du terme, la décision, selon une figure qu'un administrateur, observateur extérieur mais privilégié de ce fonctionnement, décrit de manière suggestive : « Je dirai d'une certaine manière ça se passe de manière totalement autocratique en définitive quelque part. Mais il faut bien le justifier, mais il faut bien le discuter, mais discuter publiquement donc, il ne faut pas être en contradiction avec tout ce qu'on dit. Donc en fait, c'est comme les décisions à la japonaise où finalement le chef il a le pouvoir de tout mais, mais il doit le faire émerger de sa base, il ne peut pas prendre une position qui soit totalement contraire à l'ensemble des gens qui sont autour sinon il est tout seul. »

35 Une caractéristique constante de la « communauté » SPIP au cours du temps et au long de sa croissance réside dans l'autorité et la légitimité du noyau stratégique. Ce crédit, technique et politique, lui permet de jouer, et de tenir dans le temps, un rôle décisif dans le pilotage du projet, c'est-à-dire à la fois la production du logiciel et la mobilisation des acteurs. Cette coordination présente des traits apparemment contradictoires : elle est centralisée tout en sollicitant les membres à travers les listes ouvertes, elle est directive tout en s'appuyant sur des débats publics, elle est autocratique tout en s'alimentant à des consultations démocratiques. Cette alchimie improbable permet à la fois de maintenir dans le temps la cohérence et l'identité du produit logiciel, et d'autoriser une collectivité ­ caractérisée par une hétérogénéité croissante des contributeurs ­ à s'approprier cette production et à s'y identifier.