Une participation volontaire et hybride au travail collectif de conception dans les CEL

Un des principes organisationnels forts des CEL est cette ouverture du processus de conception à une foule de participants potentiels, qui décide de s’engager volontairement dans le travail collectif au sein d’une CEL49. C’est cette ouverture qui assure l’existence même des CEL en permettant l’implication dans la communauté. Cependant, cette ouverture ne signifie pas qu’il n’existe aucune hiérarchie dans ces communautés. Je discute dans une première section le degré d’ouverture des CEL, avant de présenter le modèle dominant qui tente de rendre compte de la hiérarchie et des formes de participation au sein des CEL. J’argumente ensuite pour une approche plus hybride de la participation dans les CEL ; cette approche sera à la base de mes travaux sur ces communautés.

Des espaces qui réifient le degré d’ouverture des CEL

Dans le cas des logiciels libres, l’ouverture du processus de conception est soutenue par des licences d’exploitation qui donnent libre accès au code source des logiciels, et par un choix de conception modulaire des logiciels, choix qui permet de gérer les interdépendances de la tâche de conception (p.ex. Détienne, 2006). Le code source peut ainsi être modifié et adapté par les « utilisateurs »50 des logiciels concernés, si tant est qu’il dispose des compétences techniques pour le faire. On peut penser à un utilisateur de Firefox qui ajouterait une fonctionnalité au navigateur par exemple. Une personne souhaitant ajouter une fonctionnalité (un module) à la version du logiciel qu’elle utilise a la latitude de le faire pour son usage propre. Il n’est pas nécessaire que ce module soit intégré dans la version

distribuée du logiciel, c’est-à-dire la version du logiciel que tout un chacun peut télécharger. Ces

possibilités d’actions directes sur le code téléchargeable par tous – autrement dit d’actions dans l’espace de production – sont subordonnées à l’obtention de « droits » de modification du code, et/ou à des formes de participations actives dans l’espace de discussion des CEL. Cette relative fermeture de la CEL s’explique en partie par la complexité de l’artefact conçu, mais également par les risques associés à l’introduction d’erreurs dans le code (dont la correction pourrait représenter un coût important). Cela conduit à la distribution du pouvoir au sein des CEL du logiciel libre et à l’existence d’une hiérarchie (cf. infra).

Dans le cas de Wikipédia, le modèle de participation est plus ouvert, tout participant peut décider de modifier le contenu d’un article et le contrôle est exercé a posteriori par les autres membres, qui peuvent annuler une modification (Bryant, Forte & Bruckman, 2005). La modification n’est donc pas soumise à l’obtention de droits.

49 Pour une discussion des motivations de cet engagement, voir par exemple Détienne, Barcellini & Burkhardt (2012).

50 On voit que le terme utilisateur n’est pas totalement approprié dans ce cas.

Je décris dans la section suivante les formes de participation qui découlent de ces choix de coordination.

Le modèle « cœur-périphérie » : un modèle partiel de la participation aux CEL

Le modèle dominant de la participation est celui dit des « pelures d’oignon » (onion ring) ou modèle « cœur - périphérie » (Crowston, 2011 ; Jergensen, Sarma, & Wagstrom, 2011; Bach & Twidale, 2010; Hedberg & Livari, 2009; Jensen & Scacchi, 2007; Crowston & Howison, 2005; Ducheneaut, 2005; Nakakoji, Yamamoto, Nishinaka, Kishida, & Ye, 2002). Il s’agit d’un modèle pyramidal de participation qui décrit différents statuts déterminés par la prise en charge de telle ou telle tâche dans la CEL. La participation y est pensée principalement en lien avec la contribution à des tâches de développement de code informatique (production de code ou non, signalement de dysfonctionnement, correction de dysfonctionnement, maintenance…) (Figure 2).

Figure 2 Modèle cœur - périphérie de la participation aux projets de conception de logiciels libres

Ce modèle considère que tous les participants aux CEL du logiciel libre sont des utilisateurs par défaut (ce qui est le plus souvent le cas). Les utilisateurs dits passifs sont ceux qui « se contentent » d’utiliser le logiciel et de mobiliser les ressources disponibles en ligne, sans contribuer effectivement à la conception du logiciel. Il n’y a donc pas de traces de leur implication. Ces participants dits « utilisateurs » peuvent disposer de plus ou moins de compétences en informatique, selon le type de logiciels libres considérés (Ducheneaut, 2005). Par exemple, être utilisateur du logiciel libre Python, qui est un langage de programmation, requiert un niveau de connaissances en informatique plus important que l’utilisation du navigateur Firefox.

Les participants sont ensuite dénommés en fonction de la tâche de développement de code informatique et de leur possibilité de transformer le logiciel. Ainsi, de la périphérie au cœur de cette hiérarchie on trouve :

• des utilisateurs dits actifs qui peuvent être des « bug reporters » (les personnes qui signalent des dysfonctionnements), des personnes qui demandent des évolutions du logiciel (« feature requester »); ou encore des « bug fixers » ou des « patchers » qui proposent des solutions de correction à ces dysfonctionnements. Suivant les études, ces derniers peuvent alors être appelés des développeurs périphériques ou co-développeurs (ils ne sont pas encore totalement développeurs, mais plus vraiment uniquement utilisateurs) ;

• viennent ensuite les développeurs, qui peuvent être les développeurs principaux d’une partie du code (d’un module ou d’un ensemble de modules) et les responsables de leur maintenance. Ils disposent des droits de modification du code source du logiciel, a minima celui dont ils ont la responsabilité. Ces développeurs représentent en général moins de 10 % des participants identifiés ; ils sont responsables de la majorité des demandes de modification, et des modifications associées (plus de 50 %, voire 80 % dans certains cas) (German, 2003 ; Capilutti, Lago & Morisio, 2003 ; Ghosh, Glot, Krieger & Robles, 2002)51 ;

• enfin, au sommet de la hiérarchie se trouvent le chef de projet (souvent le fondateur du projet, l’entrepreneur initial, appelé parfois le « benevolent dictator »), et les administrateurs, qui ont les droits de modification totale sur le code. Ils sont en général responsables de la coordination des évolutions du logiciel, de la maintenance du cœur du logiciel, de la vérification du code proposé (Mockus, Fielding & Herbsleb, 2002 ; Fitzgerald, 2006 ; Reis & Fortes, 2002). Pour qualifier ce groupe, on parle de « core developpers » ou de « core team ». Mes travaux ont mis en évidence une répartition des rôles entre chef de projet et administrateurs en fonction de leurs domaines de compétences (Barcellini, Détienne & Burkhardt, 2008a ; Barcellini et al., 2010).

Dans le cas de Wikipédia, on retrouve également une forme de hiérarchie, mais plus plate, en raison de l’ouverture plus importante de la participation (il n’y a pas de droits de modification des articles, cf. supra). On distingue alors des utilisateurs-lecteurs de l’encyclopédie, des éditeurs (qui modifient des articles), des super-éditeurs (qui sont à la tête de plus de 5000 éditions) (Panciera, Halfaker & Terveen, 2009), et les administrateurs qui sont élus et ont en charge la maintenance de l’encyclopédie, mais n’ont pas de pouvoir éditorial spécifique52.

Que ce soit dans le cas du logiciel libre ou de Wikipédia, ces hiérarchies ne sont bien évidemment pas figées : les participants peuvent évoluer – d’une position d’utilisateurs actifs à une position de développeurs par exemple – en fonction de la renommée qu’ils acquièrent sur la base des compétences techniques qu’ils donnent à voir aux autres en participant effectivement au travail collectif de conception de la communauté (qualité du code informatique, compétence à animer les discussions, fiabilité dans la maintenance du code…) (cf. infra et Ducheneaut, 2005)53.

Vers

Ce modèle est intéressant pour commencer à penser la participation au travail collectif de conception dans les CEL, cependant il présente plusieurs limites.

La première est qu’il reproduit la distinction, classique en épistémologie de la conception, entre « utilisateurs » (ici, ceux qui ne disposent pas des droits d’action dans l’espace d’implémentation), et « concepteurs » (ceux qui disposent des droits d’action dans l’espace de production) qui n’a que peu de sens dans ce contexte. Des entretiens que j’ai menés auprès des participants de la CEL concevant le langage Python (Barcellini et al., 2010) montrent par exemple que les participants n’ont pas une représentation commune de ce que peut être un développeur. Pour eux, un développeur est tantôt un participant à la liste de discussion orientée conception, tantôt un contributeur, tantôt un expert technique (appelé « gourou » dans le monde du logiciel libre), ou bien encore c’est une personne

51 Ces chiffres sont toutefois à nuancer car nous verrons que les administrateurs peuvent soumettre du code pour un autre participant ne disposant pas des droits.

52 http://fr.Wikipedia.org/wiki/Wikip%C3%A9dia:Administrateur

53 Outre la maîtrise des compétences techniques et discursives, cette évolution potentielle requiert que les participants dépassent un certain nombre de barrières à la participation, comme leur disponibilité temporelle, la possibilité de se construire une histoire des projets de la communauté, une conscience sociale des divers participants. Dans ce contexte technologiquement médié, cette possibilité est indissociable de la qualité des outils proposés aux participants (voir Détienne, Barcellini et Burkhardt, 2012, pour une discussion de ce point).

« qui dispose des droits de modification du code informatique », ou qui contribue « de manière significative à l’implémentation du langage ».

Une deuxième limite tient au fait que l’analyse de la participation se limite souvent à l’analyse d’un seul des espaces potentiels d’activité (l’espace d’implémentation), ou à l’analyse d’une grande masse de données décontextualisées – par exemple l’analyse des réseaux sociaux d’acteurs impliqués dans la conception d’un logiciel, uniquement sur la base de l’analyse des modifications de code enregistrées en ligne (Madey, Freeh, & Tynan, 2002 ; Crowston & Howison, 2006; Ripoche & Sansonnet, 2006; Gonzales-Barahona, Lopes & Robles, 2004; de Souza, Froelich, & Dourish, 2005 ; Sowe, Stamelos & Angelis, 2006, 2008; Hendry, 2008).

Il y a ainsi peu d’études qui :

• identifient les données relatives à des projets spécifiques qui animent réellement les CEL;

• adoptent une position hybride en s’intéressant à la participation aux espaces de production et de discussion (Barcellini et al., 2008a) ;

• s’intéressent aux activités effectivement déployées par les participants, notamment dans l’espace de discussion qui, on l’a vu, est le lieu où une partie de l’orientation des projets et le travail collaboratif de conception se déroulent préférentiellement. Si des études se focalisent sur ce dernier espace, elles mettent souvent en œuvre des analyses du niveau de participation (nombre de messages postés par participant) ou des analyses structurelles (taille des fils de discussions, éventuellement formes) et ceci sur une masse de données décontextualisées, c’est-à-dire sur tous les messages échangés sur telle ou telle liste de discussion, sans différencier le thème des messages ou les buts poursuivis par les participants à la discussion54. Ce type d’études ne permet donc pas d’analyser les contributions effectives des participants, car elles mettent de côté les buts poursuivis et les contextes dans lesquels leurs discussions ont lieu. Ainsi, la nature située des activités des participants n’est pas prise en compte.

Dans ce contexte, un apport de mes travaux sur les CEL a été de caractériser la distribution des activités et, par conséquent, de la participation effective et située aux espaces d’activité autour de projets clairement identifiés. Ainsi, ces travaux ont permis de proposer un modèle plus hybride de la participation, c’est-à-dire qui prenne en compte ses différentes facettes (Ducheneaut, 2005; Sack et

al., 2006; Crowston & Howison, 2006; Crowston et al., 2012) : le travail collaboratif réel en lien avec la

participation aux discussions relatives à l’artefact en cours de conception et à son usage, la production et maintenance de documents relatifs à cet artefact, et la réification de cet artefact en code informatique dans l’espace d’implémentation.

C’est donc dans cette même perspective que se situe le propos de ce chapitre. Ces travaux ont nécessité de s’interroger sur l’émergence des projets au sein des CEL, et sur leurs régulations. On verra que ce sont ces formes de régulation qui vont conférer des propriétés capacitantes à l’organisation des CEL.

54 Sowe et al. (2006 ; 2008) mettent ainsi en évidence la présence de participants – qu’ils nomment des agents de connaissances (knowledge brokers) – qui participent à plusieurs listes d’une même CEL. Cependant, rien n’est dit sur le contexte de ces participations, ni sur l’activité des participants dans ces listes. Ainsi, la supposée contribution de ces participants à la « circulation de la connaissance » ou au transfert d’informations n’est pas démontrée. On peut seulement dire que leur forme de participation présente une composante (la participation à plusieurs listes) qui en font des bons candidats pour transférer des informations d’une liste à l’autre par exemple.