Chapitre 2. Comprendre le travail collectif de conception dans les Communautés
1.3 Émergence et régulation des projets collectifs de conception dans les CEL
Le principe d’ouverture du processus de conception des CEL implique que chacun peut être acteur de leurs évolutions, par exemple en adaptant l’artefact à « un » besoin, ou en mettant en évidence, dans les discussions notamment, des besoins d’évolution de cet artefact, qui pourront aboutir à l’émergence de projets de conception au sein des CEL. C’est cette dynamique qui nous a particulièrement intéressés, en particulier les cas où des modifications, ou des intentions d’évolution d’un artefact, vont être discutées par la CEL. Ces situations sont alors considérées comme des situations potentielles de travail collaboratif de conception pour lesquelles les participants cherchent à faire évoluer l’artefact conçu de manière collective – c’est-à-dire qu’ils sont engagés dans un projet, et qu’ils s’organisent autour de ce projet. Je décris dans une première section les principes d’émergence de ces projets, avant de présenter leur mode de régulation, en lien avec les discussions (règles de
discussion), la mise en œuvre (règles de production) et la coordination des projets (règles de coordination).
Conception continue et émergence des projets dans les CEL
L’émergence des projets au sein des CEL est soutenue principalement par les actions dans les espaces d’activités. Dans le cas des logiciels libres, le signalement de dysfonctionnements, ou les demandes d’évolution des logiciels, dans l’espace de production (via les rapports de dysfonctionnement ou les demandes de nouveautés) peuvent ainsi être à l’origine d’intention d’évolution (Scacchi, 2001 ; Mockus et al., 2002 ; German, 2003 ; Reis & Fortes, 2002). D’autres peuvent être « pilotées par le haut » et résulter de choix stratégiques du chef de projet et des administrateurs. En pratique, la majeure partie des intentions de transformation est en fait exprimée et élaborée par les participants à travers les échanges sur les listes de discussion (Scacchi, 2001 ; Mockus et al., 2002 ; Barcellini, Détienne & Burkhardt, 2009).
Ce sont ces discussions qui soutiennent l’émergence des intentions de transformation et l’évolution des orientations des CEL, notamment les arbitrages entre les différents enjeux sous-jacents à la transformation. Ces enjeux peuvent être : techniques (p.ex. gestion des compatibilités avec d’autres versions du logiciel en lien avec l’introduction d’une nouvelle fonctionnalité), stratégiques (p.ex. possibilité de positionnement du logiciel libre sur un « marché » en lien avec l’introduction de telle fonctionnalité)55, ou encore politiques (p.ex. orientation d’un article de Wikipédia en fonction de l’audience visée, grand public ou scientifique). Je montrerai, en section 4, que l’émergence de ces projets peut-être relativement fluide, ou au contraire, générer des conflits entre les membres de la communauté en lien avec l’arbitrage de ces enjeux.
Du fait de ces possibilités d’émergence de projets au sein des CEL, le processus de conception est considéré comme continu : de nouvelles fonctionnalités peuvent toujours être proposées, et discutées, quel que soit l’état d’avancement du projet (Gasser, Scacchi, Ripoche, & Penne, 2003). Le processus qui émerge est donc a priori moins formellement jalonné que les processus de conception « traditionnels » (par exemple quand ils sont organisés en mode projet, Garel, 2011 et chapitre 4). Dans ces modèles traditionnels de la conception, on peut distinguer a minima des phases d’étude de faisabilité, de conception, de réalisation, et de production. La conception dans les CEL entremêle ces différentes phases et n’établit pas de critère d’arrêt de la conception. Cependant, je montrerai qu’il existe un phasage émergent du projet qu’il est possible de retracer (cf. section 3). Par ailleurs, ce processus est encadré par un ensemble de règles que je présente dans la section suivante.
55 Par exemple, certaines grandes CEL du logiciel libre (p.ex. Python) ont pour contributeurs des institutions ou des entreprises (p.ex. Google, Fujitsu…) qui peuvent « pousser » pour tel ou tel développement (et les faire réaliser par leurs développeurs au sein de la CEL) (voir par exemple Dahlander & Magnusson, 2005).
En effet, même s’il n’existe pas, a priori56, de prescriptions très fortes au sein des CEL, des règles régissent néanmoins le travail collectif autour de ces projets. Elles concernent les échanges entre participants (règles de discussion), l’émergence des projets et leur mise en œuvre effective (règles de
production), et enfin la coordination du processus de conception (règles de coordination). Ces règles
participent toutes, in fine, à la qualité de l’artefact conçu. Elles sont particulièrement prégnantes dans le monde du logiciel libre sur lequel je centre cette section.
Règles de discussion
Des règles de discussion permettent de structurer les échanges en ligne, notamment à travers le respect de la nétiquette57 : respect des thèmes abordés par le sujet de la discussion, contextualisation des réponses dans les discussions, à travers notamment l’usage systématique de la citation électronique (Herring, 1999, et infra), connaissance de l’historique des précédentes discussions. Le respect de ces règles peut paraître anecdotique, elle ne l’est pas. Il s’agit d’une garantie de l’efficacité des communications médiées qui permet : d’une part, de maintenir la cohérence des échanges et l’intertextualité qui sont des prérequis à la collaboration ; et d’autre part, de soutenir l’implication a posteriori d’autres participants. Les membres des CEL du logiciel libre portent une attention particulière au respect de ces règles, j’y reviendrai en section 4.
Règles de production soutenant l’émergence des projets
Les premières règles de production visent l’encadrement des propositions d’évolution des logiciels. Compte tenu de la taille de certaines CEL du logiciel libre, il peut être difficile de faire face à la quantité de demandes potentielles de modification qui émerge des discussions en ligne. Par ailleurs, l’introduction de certaines évolutions nécessite d’être négociée, par exemple parce qu’elle renvoie à des questions stratégiques ou à des questions techniques ayant un impact important sur l’artefact (cf. chapitre 1).
Certaines CEL ont donc mis en place des règles encadrant les propositions de nouvelles fonctionnalités. La CEL Python, que j’ai particulièrement étudiée, a été une des pionnières en la matière en définissant le processus « Python Enhancement Proposal » (PEP) (Barcellini, 2005 ; Barcellini et al., 2005 ; Barcellini, 2008 ; Barcellini et al., 2008a,b ; Barcellini et al., 2009 ; Barcellini, Détienne & Burkhardt, 2013). Le processus PEP prescrit la façon dont doit être proposée toute nouvelle idée d’évolution du langage Python (l’intégration d’un nouveau module dans le cœur du langage par exemple), sa mise en discussion dans le projet, et la documentation qui s’y rapporte (Figure 3).
56 Cette non prescription a priori est également à nuancer car certaines évolutions sont également pilotées « par le haut » – par la « core team » – par exemple. Cependant, ce pilotage reste tributaire du fait que des membres de la communauté veuillent, ou puissent, ensuite prendre en charge ces évolutions.
57 La nétiquette a été formalisée par l’Internet Engineering Task Force http://tools.ietf.org/html/rfc1855
Figure 3 Distribution du processus PEP
Le document PEP et ses différentes versions décrivent l’idée proposée pour l’évolution du langage et les évolutions de cette idée initiale.
L’idée est en général décrite par un participant à l’origine de la proposition, ce participant devient alors le « champion »58 de cette proposition. Il est responsable de sa mise en discussion, et de sa mise en œuvre éventuelle. À cette règle de production est associé ce statut de champion, qui s’apparente à un chef de projet « local » du projet de conception particulier qu’est le PEP.
L’idée décrite dans le document peut ainsi être discutée par les participants et évoluer. Ces évolutions sont transcrites dans différentes versions du document (qui décrivent une spécification de plus en plus fine de la nouvelle fonctionnalité), elles sont archivées dans l’espace de documentation, pour finalement aboutir à une implémentation « physique » de cette idée (dans l’espace de production de code ou espace d’implémentation). Le document PEP et ces évolutions constituent ainsi des objets intermédiaires caractérisant l’évolution du projet de conception. Ce document – cet objet intermédiaire – sert de base au processus de conception qui regroupe un ensemble d’activités réparties dans les espaces d’activité et en particulier dans l’espace de discussion des projets dans lequel la proposition va être discutée, négociée et travaillée (Barcellini et al., 2008a,b)59.
Règles soutenant la coordination
Une fois les modifications acceptées et validées, d’autres règles de production cadrent la coordination au sein de la CEL (Mockus et al., 2002 ; Scacchi, Feller, Fitzgerald, Hissam, & Lakhani, 2006 ; Crowston et al., 2007) :
• la règle de « paternité de code » (« code ownership »). Les membres de la core team, par exemple, ont tendance à être responsables des parties du code pour lesquelles ils ont le plus contribué, ou celles pour lesquelles leur expertise est reconnue dans le projet (Mockus et al., 2002 ; German, 2003). De même, chaque module intégré dans la version courante du logiciel est
58 Il s’agit d’un anglicisme, qui provient du verbe « to champion » défendre.
59 Cela a été ensuite repris dans d’autres projets, comme GNOME (GNOME Enhancement Proposal ou GEP), Plone (Plone Improvement Proposal ou PLIP) ou encore XMPP (Jabber Enhancement Proposal JEP). D’autres projets, comme Apache, ont mis en place des stratégies proches basées sur la recherche de consensus dans les questions de conception discutées et traitées en ligne. Les mécanismes du type des PEP permettent d’encadrer le processus de conception continu.
souvent sous la responsabilité d’un ou plusieurs développeurs, souvent la personne qui a contribué à l’ajout de cette fonctionnalité (le champion, cf. infra) ;
• la règle d’auto-attribution des tâches, c’est-à-dire la pratique qui consiste à définir une tâche à réaliser et à se proposer simultanément pour la mener à bien (Crowston et al., 2007). C’est l’intérêt du participant et sa disponibilité qui semblent motiver cette auto-attribution. L’auto-attribution semble le mécanisme de coordination le plus utilisé par les membres des CEL du logiciel libre (près de 60 % des tâches dans l’étude de Crostown et al., 2007). Pour les tâches restantes, on retrouve une organisation hiérarchique descendante classique : ce sont en général les développeurs qui attribuent des tâches aux autres participants.
Ces responsabilités ne sont souvent pas formalisées – c’est-à-dire inscrites dans des documentations des CEL qui seraient analogues à des fiches de poste –, mais elles sont connues des participants à la CEL. Dans Barcellini et al., (2010), nous montrons que les participants développent cette conscience sociale des expertises et des responsabilités au sein de la CEL.