Les limites des formes de régulation des échanges informationnels

By 23 March 2013

Les limites de la formalisation

Dès lors que l’on entre un tant soit peu dans le détail de l’organisation des collectifs du « libre » – ce que nous avons tenté de faire sur les exemples de Linux, Debian, et Wikipédia –, il apparaît que chaque projet a mis en place des formes de régulation qui lui sont propres.

Avant d’aborder ces différences entre projets, arrêtons nous un instant sur ce qui leur est commun : l’existence de subtils éléments de hiérarchie, plus ou moins formalisés. En effet, loin de la pure horizontalité que connote la métaphore du bazar4, il y a dans chaque projet des individus chargés de sélectionner les contributions, de transformer les différents ajouts en un tout cohérent, ou de corriger les modifications non pertinentes (qui ne manquent pas d’intervenir dans tout projet « ouvert »). Nous sommes donc loin de l’ « auto-organisation mythifiée »1 décrite par certains discours sur la collaboration distribuée, puisque tous les projets d’envergure ont dû, à un moment donné de leur développement, se doter de structures hiérarchiques, tout simplement pour que la coopération demeure productive, et même possible.

1 Cf. Dominique CARDON, Julien LEVREL, op. cit..
2 Valérie CHANSIGAUD, « Peut-on parler de communauté sur Wikipédia ? » in Marc FOGLIA, op. cit., p. 152.
3 Cf. « Wikipédia : WikiLove », Wikipédia.fr, en ligne : http://fr.Wikipédia.org/wiki/Wikip%C3%A9dia:WikiLove (consulté le 22/06/2011).
4 La métaphore du bazar a du reste été durement critiquée [voir par exemple Nikolai BEZROUKOV, « A second look at the Cathedral and the Bazaar », First Monday, vol. 4, n° 12,
6 décembre 1999, en ligne : http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/vi ew/708/618 (consulté le 23/06/2012)]. Elle est souvent considérée comme profondément inadéquate par les partisans du logiciel libre eux-mêmes. Philippe Aigrain affirme ainsi : « Ce qui est important, c’est que les communautés dans leur immense majorité ne sont pas sur le mode du bazar, et c’est pour ça qu’Eric Raymond avait tout faux, tout simplement » (Philippe AIGRAIN, informaticien, chercheur, ancien haut-fonctionnaire à la Commission européenne, co-fondateur de La Quadrature du Net, entretien réalisé à Paris le 3 décembre 2010).

La nature de ces hiérarchies doit toutefois être précisée. Elles ne signifient pas, à de rares exceptions près (comme le statut d’ « arbitre » dans Wikipédia), que certaines personnes soient dotées d’un véritable pouvoir de coercition, ou de sanction. Elles ne correspondent pas à la possibilité pour des « chefs » d’obliger des individus à effectuer certains tâches, en vertu d’une quelconque forme de contrainte. Les divers modes d’organisation adoptés par les projets « libres » se meuvent en effet dans le cadre d’un travail volontaire et non prescrit2, où l’affectation des tâches est négociée, et où chacun a toujours la possibilité de se retirer du projet. Il existe donc bien des structures hiérarchiques, au sens où certains individus ont une puissance d’agir et un pouvoir de décision supérieurs à d’autres, mais elles demeurent profondément différentes des hiérarchies managériales ou bureaucratiques « classiques », dans la mesure où elles sont étroitement bornées par le caractère volontaire et constamment réversible de la participation individuelle à tout projet « libre ».

De plus, il est caractéristique de l’ethos minimal commun à l’ensemble de la « culture libre », que ces hiérarchies soient pensées comme d’origine purement méritocratique. Un des six principes de l’ « éthique hacker », telle que l’a présentée Steven Levy dans son livre fondateur, est ainsi qu’« il faut juger les hackers sur leur travail, et non sur des critères factices comme leur diplôme, âge, race, ou statut social »3. Ce principe se retrouve même au sein de Wikipedia, où « il n’est pas admis d’exciper dans une controverse une qualité “positive” comme ses diplômes, sa profession ou son statut d’expert »4. Par conséquent, l’acquisition d’un statut éminent au sein du collectif y dépend très peu d’un statut social préalable et officiellement attesté, mais presque exclusivement de ce qui a été individuellement accompli sous le regard scrutateur et vigilant des pairs.

1 Steven WEBER, op. cit., p. 185.
2 Précisons toutefois qu’un salarié d’une entreprise informatique peut se voir « obligé » par son employeur à travailler sur tel ou tel aspect d’un projet de logiciel libre. Mais cette obligation dérive alors d’une relation salariale classique, et ne relève pas des modes d’organisation adoptés par les projets « libres » en tant que tels.
3 Steven LEVY, op. cit., p. 43.
4 Dominique CARDON et Julien LEVREL, op. cit..

L’étude des modes d’organisation adoptés par les projets « libres » fait également ressortir que les différentes formes de régulation se sont toujours construites progressivement, afin de répondre à des difficultés concrètes. Ainsi, c’est pour faire face à la croissance du nombre de contributions à superviser que Linus Torvalds a commencé à s’appuyer sur des « lieutenants »; pour répondre à un afflux soudain et massif de contributeurs que Debian a mis en place le New Maintainer Process; pour pouvoir lutter plus efficacement contre le « vandalisme » que Wikipédia a permis à certains membres de bloquer ou d’exclure des utilisateurs. Autrement dit, les modes d’organisation propres à chacun de ces projets ont ceci de commun, qu’ils se sont tous construits par petites touches, par « bricolages » successifs, afin d’essayer de répondre au mieux aux problèmes auxquels les collectifs étaient confrontés. Comme le remarquent Steven Weber et Christopher Kelty, les pratiques ont dans la plupart des cas précédé, et excédé toute forme de théorie unifiée1. Les modes d’organisation adoptés doivent donc moins être considérés comme les expressions d’un modèle d’organisation qui leur préexisterait, que comme des formes singulières d’expérimentation en matière organisationnelle.

Ces expérimentations ont été menées dans des directions qui apparaissent tout compte fait relativement diverses. Le noyau Linux est développé par un collectif de développeurs, dont un grand nombre sont rémunérés pour leur travail, et au sein duquel Linus Torvalds occupe toujours une position privilégiée de manager. Debian est un grand rassemblement de bénévoles, qui se caractérise par un égalitarisme fort (quoique non absolu) obtenu au prix d’une forme de clôture communautaire. Wikipédia se singularise par une ouverture très forte, dont les effets pervers imposent des procédures complexes de négociation, de surveillance et de sanction, et dont la pérennité requiert une forme de « neutralité » libérale. Il est certain que la prise en compte d’autres projets ferait apparaître encore d’autres modes d’organisation2. On notera de surcroît qu’au sein même d’un projet comme Wikipédia, il existe presque autant de variantes organisationnelles qu’il existe de versions différentes de l’encyclopédie. Florence Devouard, ancienne présidente de la Wikimedia Foundation, note ainsi que le Wikipedia français est « plus républicain » que son pendant anglo-saxon, lequel serait (encore) plus « procédural », c’est-à-dire reposerait sur un plus grand nombre de règles explicitement formalisées3.

1 Steven Weber écrit : « La logique de ce que font les programmeurs open source n’a pas émergé à partir d’une théorie. Personne n’a déduit une série de tâches ou de procédures d’un argument formel sur la manière dont on pérennise une collaboration étendue et décentralisée. Il s’agit plutôt d’un jeu d’essais/erreurs. Mais un jeu joué par des gens qui ont une compréhension profonde et fine, bien que souvent implicite, de la texture de la communauté qu’ils entendent mobiliser » (Steven WEBER, op. cit., p. 73). Christopher Kelty affirme lui à propos de Linux :

« Les projets, les outils, les gens et le code qui étaient fun, étaient ceux qui n’étaient pas l’expression de règles ou d’idées préexistantes. […] Une grande part de cette activité eut lieu en l’absence de toute théorisation explicite » (Christopher KELTY, Two Bits, op. cit., p. 213).
2 Un autre exemple intéressant est le processus de développement du serveur Apache. Sur ce sujet, voir par exemple : Steven WEBER, op. cit., p. 186 et suivantes; Christopher KELTY, Two Bits, op. cit., p. 22 et suivantes.
3 Florence DEVOUARD, intervention à une table ronde sur « le facteur humain », Open World Forum, Paris, 2 octobre 2009.

Même quand elles ne tombent pas dans l’écueil du mythe (voir chapitre précédent), les différentes tentatives de formalisation – le modèle du bazar, le modèle de l’intelligence collective, le modèle de l’innovation distribuée – proposées pour rendre compte des processus de collaboration dans les projets « libres » se heurtent donc à trois limites importantes : elles tendent systématiquement à minorer l’importance des structures hiérarchiques permettant à la collaboration d’être fructueuse; elles occultent la manière dont les modes d’organisation se construisent de façon empirique, selon une logique de « bricolage » bien davantage que comme des applications d’un modèle théorique préexistant; elles éclipsent la singularité des différentes organisations existantes, lesquelles renvoient à chaque fois aux spécificités et à l’histoire d’un projet particulier.

L’utopie du logiciel libre, le mouvement du free software
Thèse pour l’obtention du grade de docteur de l’Université Paris 1 – Discipline : sociologie
Université Paris 1 Panthéon/Sorbonne – École doctorale de philosophie