index.md 14KB
title: Méritocratie - 2
url: https://www.blog-libre.org/2016/04/21/meritocratie-2/
hash_url: 8c1736e8dd
Introduction
Ce billet fait suite au précédent (lien). Il aborde de façon rapide et non-exhaustive quelques uns des problèmes qui semblent intrinsèquement liés à la méritocratie.
La collusion
Le mérite découle de l’observation de faits par des pairs, qu’elle soit directe ou médié par la technique elle-même par exemple à travers la gouvernance par les nombres. Ces faits sont portés au crédit de celui dont le mérite est évalué. Ils sont donc une manifestation de sa capacité opérationnelle, donc de sa puissance. Il en résulte un lien causal indirect entre la puissance comme capacité d’agir et la légitimité au pouvoir, à travers les faits que la première réalise puis la visibilité de ces faits aux yeux des pairs. En d’autre terme, c’est la loi du plus fort : celui qui est plus fort peut faire davantage que celui qui est plus faible, son mérite sera donc perçu comme plus grand, en conséquence de quoi davantage de pouvoir lui sera confié. Cette loi du plus fort liée à la collusion entre puissance et pouvoir est intrinsèquement liée à la nature même de la méritocratie.
Il est à ce titre éclairant de constater que dans leurs sens communs, “puissance” et “pouvoir” sont considérés comme synonymes. Cette confusion dans la langue française se retrouve également derrière le terme anglophone “power”, en tant que “influence” et en tant que “autonomy”, qui sont tout sauf équivalents. C’est le “puissance/autonomy” vers lequel le désir s’oriente premièrement, et uniquement ensuite qu’il considère le pis-aller “pouvoir/influence” (lien). À défaut de pouvoir faire advenir l’environnement que nous souhaitons pour nous-mêmes, nous désirons que d’autres travaillent à cette réalisation à notre place. Autrement dit, la seule possibilité de prendre l’un pour l’autre est de considérer que l’Autre est une chose extérieure à soi mais sous influence et dont la mission est de travailler à ce que cet extérieur soit tel que désiré par soi. Cette absence de la frontière du soi témoigne d’une tendance à la toute-puissance qui, mécaniquement, réduit l’Autre au statut d’effecteur, donc au conflit de volonté avec lui ou en lui, qui résulte donc tout aussi mécaniquement de la collusion. Que la langue soit ambigüe n’est pas neutre : s’il nous est impossible de distinguer les deux par les mots, nous avons le plus grand mal à penser la différence, qui est aussi la différence entre un système équilibré à contre-pouvoir et la loi du plus fort, à un degré qui permettrait l’apparition du premier.
Dans le monde du libre, les projets démarrent la plupart du temps sous l’impulsion d’une seule personne, qui est donc à la fois gouverné et gouvernant. Seul maître à bord, sa maîtrise est totale. Il est l’autonome dictateur silencieux de lui-même. Si une personne particulièrement brillante arrive dans un projet existant ou interagit avec ce dernier, il risque de polariser les échanges : brillant, donc méritant, du pouvoir lui sera confié, qu’il exercera comme bon lui semble et de façon autonome, sans nécessité de rendre des comptes. Les exemples sont légions, comme par exemple systemd. Pour simplifier, le chef est respecté non pas parce qu’il est chef, mais parce qu’il est le plus fort et qu’il l’a démontré. D’ailleurs, les légendes respectées sont très nombreuses, de Richard Stallman le “gourou” à Linus Torvalds, le “dictateur bienveillant”.
La technique
La technique est une extension de l’humain qui augmente sa puissance. Dans une méritocratie, elle est donc un enjeu essentiel, car celui qui la maitrise augmente ainsi mécaniquement ses chances d’accéder au pouvoir. La méritocratie favorise donc l’introduction de la technique dans la légitimation du pouvoir. Elle est donc un régime particulièrement favorable à ceux qui disposent d’une maitrise technique. Il ne s’agit plus seulement d’être pour participer à la gouvernance, mais il faut également avoir la possibilité d’utiliser voire idéalement de concevoir des techniques.
Dans le monde du logiciel libre, la dimension technique est essentielle. Par exemple, les différentes stacks logicielles sont très différentes dans ce qu’elles permettent, tant sur le plan qualitatif que sur le plan quantitatif. Certaines étant plus adaptées que d’autres suivant les usages, il est essentiel pour un développeur d’effectuer une veille stratégique afin de pouvoir se saisir des technologies les plus efficaces, qui en retour augmentent sa puissance, donc le mérite duquel il sera crédité, ainsi que le pouvoir (et le salaire).
L’absurde
L’irruption de la technique dans la légitimation du pouvoir permet de s’assurer que les gouvernants ne lui sont pas étrangers. Le temps qu’ils y consacrent et qui leur vaut légitimité à travers ce qu’elle permet, par la maitrise qu’ils en acquiert, ne peut que se faire au détriment d’autres tâches qui leurs sont également dévolues. Dit autrement, la technique impose un tempo de gouvernance dont le rythme est fonction des transitions techniques. Plus les évolutions techniques sont fréquentes, plus le risque est grand de voir le mérite attribué à ceux qui arrivent à en gérer l’immédiateté productive plutôt qu’à ceux qui sont capables d’anticiper et de prendre du recul – deux vertus difficilement mises en pratique dans le contexte d’une course technique, et très difficilement évaluable par des métriques objectives. Il en résulte que ceux qui seraient les plus capables de gouverner – au sens de “gouverner c’est prévoir” – sont plus difficilement reconnus comme méritant par leurs pairs, et qu’ils accèdent moins à la gouvernance. Dès lors, la gouvernance par des experts de l’immédiateté risque de se borner à de simples ajustements par réaction à des stimuli extérieurs, perdant ainsi l’impulsion initiale liée à la mise en place de la méritocratie. Dans ce cas là, c’est ultimement l’existence même du projet qui risque d’être remise en cause, faute de vision globale. Faire de la technique une fin, c’est rejeter les finalités à la périphérie (lien).
Dans le cas du libre, l’irruption de la technique dans la légitimation du pouvoir permet de s’assurer que les leaders de communauté ont une base technique suffisante pour pouvoir comprendre les enjeux qui lui sont liés. La maitrise de la technique est grisante et peut faire perdre de vu l’objectif initial, la vision première. C’est par exemple le cas de ceux qui contestent Lennart Poettering pour systemd. L’excellente technique de la solution est parfois discutée, mais jamais autant que les fondamentaux sous jacents dont il est coutume de dire qu’ils semblent avoir été oubliés : “Write programs that do one thing and do it well”. Si demain un nouveau langage ou un nouveau “génie” décide de “refaire systemd en mieux”, toute l’énergie qu’il pourra investir le sera au détriment de l’évolution des systèmes existants, quitte à réinventer la roue. Ce phénomène fortement lié à la recherche technique se manifeste dans les disruptions des environnements de bureau par exemple, de KDE 3 à KDE 4 par exemple, ou de Gnome 2 à Gnome Shell. Ces disruptions témoignent du caractère difficilement compréhensible de certaines décisions qui, sur la base d’une évolution technique, semble – ne serait-ce que temporairement – perdre les visions dont elles étaient porteuses.
L’inégalité
Contrairement à la démocratie dans laquelle chacun est, par sa simple existence, – en principe – appelé à participer également à la gouvernance de tous, la méritocratie induit une discrimination sur la base du rapport à la technique. Ceux qui ne sont pas en mesure de s’approprier la technique, faute d’occasion, d’aptitude ou de formation, ont très peu de chance d’accéder à des fonctions de gouvernance. Ils sont donc de nouveaux exclus du pouvoir sans possibilités de recours, laissés pour compte. Cette inégalité irréductible limite l’extension de la méritocratie, sauf à alimenter les rangs de ceux qui se révèleront inévitablement contestataires. Le degré de civilisation de la méritocratie, c’est à dire la façon dont les plus faibles sont considérés et traités, prend le risque d’être particulièrement bas. La méritocratie n’est d’ailleurs pas si distante d’une lecture dévoyée (lien) du slogan Darwiniste “Survival of the fittest”.
Dans le cas de l’informatique, l’inégalité est celle de l’accès à la technologie, de son usage, et à sa compréhension. Cette inégalité était initialement très forte pour des raisons de coûts. Elle le reste tant pour des raisons d’éducation (qui forme davantage à l’utilisation de logiciels qu’elle n’ouvre à une appréhension systémique de l’informatique comme outils), politiques (la censure), économiques (les DRMs) voire simplement techniques (les logiciels privateurs dont le fonctionnement n’est pas intelligible). Le logiciel libre apporte là un élément décisif et singulier à travers ses quatre 4 libertés fondamentales. Installés sur des systèmes peu coûteux comme les Raspberry Pi par exemple, les barrières s’abaissent considérablement.
La rivalité
La puissance appelle le pouvoir, le pouvoir permet de mettre en œuvre une puissance qui légitime encore davantage le pouvoir. L’un et l’autre s’alimentant donc mutuellement, la gouvernance est exercée par un petit groupe au sein de la communauté initiale qui, par cooptation, dispose de pouvoir grandissants. La communauté initiale s’appuie donc principalement sur un entre-soi qui ne favorise guère la rencontre avec l’altérité, facteur d’humilité de régulation des égos essentiels dans les interactions de la communauté avec l’écosystème dans lequel elle s’intègre. Lorsque le travail mené par la communauté initiale fédère des contributeurs, ces derniers peuvent déstabiliser la gouvernance initiale. Il s’agit pour cette dernière de déléguer progressivement certaines de ses responsabilités pour se focaliser sur d’autres. Cette transition est difficile car elle implique un progressif abandon volontaire de son pouvoir, ne serait-ce que partiel. Or, cette dernière peut y être réticente.
Que le projet rencontre ensuite du succès et que d’autres y contribuent, et des problèmes de légitimités peuvent se poser rapidement. Les licences libres permettent des forks qui potentiellement assurent la pérennité du projet initial, personne ne pouvant en revendiquer un droit exclusif. Dans les forges logicielles, ces forks sont comme des soupapes de sécurité qui organisent et structurent la rivalité de façon à ce qu’elle devienne une force orchestrant le développement lui-même.
Les forks sont néanmoins des pis-aller : l’impossibilité de se fédérer autrement que par des luttes de puissances qui visent à établir des faits qui établiraient un mérite de façon indiscutable, les égos prennent facilement le dessus, et la communauté se fragmente, la collaboration – qui produit un commun – s’effrite en compétition qui peut dégénérer en jeu à somme nulle à cause des inévitables frictions qu’elle entraine. Pire, la compétition entraine l’émergence d’un vainqueur, lequel est plus facilement enclin à tricher lors du round suivant (lien). Finalement, ce mécanisme de rivalité égotique diminue l’impact et la crédibilité tant vis-à-vis de l’intérieur que de l’extérieur.
Dans le logiciel libre, le projet Gnome est un exemple. Le passage de Gnome 2 à Gnome Shell et GTK3 a été difficile, au point qu’une partie de la communauté est restée sur GTK2 (Mate), qu’une autre est partie sur une alternative en GTK3 (Cinnamon), limitant d’autant plus la masse critique de développeurs impliqués dans Gnome Shell, dont l’impact se trouve affaibli.
L’absence de possibilité de contre-pouvoir
La dynamique précédente nécessiterait, pour ne pas advenir, la présence de contre-pouvoirs. Or, si le pouvoir se fonde sur la puissance, il est impossible de voir émerger un contre-pouvoir. En effet, un contre-pouvoir ne pourrait être reconnu comme tel sur la base de sa contre-puissance. Un même espace de gouvernance dans lequel se rencontreraient une puissance et une contre-puissance serait de fait divisé. Donc l’unité du groupe remise en question avant même d’arriver à identifier un partage du pouvoir.
Dans le cas de l’intersection entre le libre et le numérique, les territoires sont multipliables à l’infini par l’intermédiaire des forks, qui permettent de faire bourgeonner un projet, une communauté, à partir d’un projet ou d’une communauté existante. Ces forks apparaissent comme des solutions en cas de conflits de personne (lien). Parfois, un simple climat de défiance peu suffire (lien).