GitHub, ou la bureaucratie de l'algorithme

On présente souvent GitHub comme un simple outil de développeurs. Je crois que c'est passer à côté de l'essentiel. GitHub est d'abord une forme d'organisation, et l'une des plus fascinantes de notre époque : une organisation sans patron, sans bureau, sans frontière nationale, où des millions de personnes qui ne se rencontreront jamais construisent ensemble une part considérable du logiciel qui fait tourner le monde.

J'ai voulu comprendre comment une telle chose tient debout. Et surtout, ce qui se cache derrière l'apparence de fluidité.

Une organisation sans centre

GitHub correspond presque trait pour trait à ce que la théorie des organisations appelle l'organisation postmoderne. Linda Rouleau (2007) décrit ce modèle comme une rupture avec la pyramide classique : une structure fluide, distribuée, sans centre fixe de commandement, où la coordination ne descend plus d'une hiérarchie mais émerge des interactions elles-mêmes. C'est exactement ce qu'on observe ici. Personne ne « dirige » un projet open source au sens où un manager dirige une équipe. Le travail s'organise autrement.

Comment ? Par la technique. Sur GitHub, ce ne sont pas des chefs qui répartissent les tâches et valident le travail, ce sont des protocoles. Le dépôt (repository) contient le projet, chacun en propose une copie, travaille dessus, puis soumet ses modifications via une pull request. Avant d'être intégrée, cette contribution passe par la revue de code (code review), où d'autres l'examinent. L'interface remplace le gestionnaire. La fonction d'encadrement, normalement portée par une personne, est ici inscrite dans l'outil.

C'est ce qui rend possible le second trait de GitHub : l'ouverture radicale.

La force de l'ouverture

Le modèle ouvert repose sur un pari simple et puissant : n'importe qui peut contribuer, quel que soit son diplôme, son employeur ou sa géographie. Hila Lifshitz-Assaf (2018), dans une étude remarquable menée à la NASA, appelle ce mécanisme le démantèlement des frontières du savoir. Là où une organisation classique réserve la résolution des problèmes à ses experts internes, le modèle ouvert efface la frontière entre l'expert et l'amateur, entre le dedans et le dehors.

Son étude offre un exemple saisissant. Un problème de prévision des tempêtes solaires, sur lequel les spécialistes de la NASA butaient depuis des années, a finalement été résolu par un ingénieur radio semi-retraité, étranger à la discipline, dont l'approche venait précisément d'ailleurs. La solution n'est pas venue du centre, mais de la marge. C'est toute la promesse de l'ouverture : en abolissant les frontières, on laisse entrer des idées que l'organisation fermée n'aurait jamais produites.

GitHub fonctionne sur ce principe à l'échelle planétaire. Et ça marche : une part majeure de l'infrastructure numérique mondiale repose aujourd'hui sur des projets open source maintenus de cette façon.

Mais c'est là que les choses deviennent intéressantes. Car la force et la faille, ici, sont une seule et même chose.

La faille de l'ouverture : l'affaire XZ

En 2024, la communauté de la sécurité informatique a découvert l'une des tentatives de sabotage les plus sophistiquées de l'histoire du logiciel libre. Une porte dérobée (backdoor) avait été insérée dans XZ Utils, une bibliothèque de compression discrète mais présente dans d'innombrables systèmes Linux, jusqu'à toucher OpenSSH, l'un des outils les plus sensibles qui soient. Référencée CVE-2024-3094, cette faille aurait pu donner à son auteur un accès dérobé à des millions de machines.

Ce qui me frappe dans cette affaire, ce n'est pas la prouesse technique. C'est la méthode. L'attaquant, connu sous le pseudonyme de Jia Tan, n'a pas forcé la porte. Il l'a franchie en étant invité à l'intérieur.

Pendant près de deux ans, ce contributeur s'est montré disponible, compétent, régulier. Il a proposé des correctifs utiles, participé aux discussions, gagné progressivement la confiance du mainteneur du projet. Dans le même temps, des comptes complices faisaient pression sur ce mainteneur, déjà épuisé et seul à porter une charge colossale, pour qu'il délègue davantage de responsabilités. La manœuvre a fonctionné : Jia Tan a obtenu les droits de maintien, et a pu y déposer son code malveillant. La faille n'a été repérée que par chance, lorsqu'un ingénieur a remarqué qu'une connexion SSH mettait une fraction de seconde de trop à s'exécuter.

Quand la confiance devient l'angle d'attaque

Pourquoi cette histoire est-elle aussi instructive ? Parce qu'elle montre que la vulnérabilité de l'organisation ouverte n'est pas technique. Elle est relationnelle.

Beth Schinoff et ses collègues (2020) ont étudié comment se forment les relations de confiance dans le travail virtuel, là où les collègues ne se voient jamais physiquement. Leur concept central est celui de cadence relationnelle : la confiance se construit moins par la rencontre que par la régularité prévisible des interactions, par ce rythme partagé qui fait qu'on finit par anticiper comment l'autre va se comporter. À distance, on ne fait pas confiance à un visage. On fait confiance à une régularité.

C'est exactement ce que Jia Tan a fabriqué. Il n'a pas piraté un système, il a construit une cadence. Deux ans de contributions régulières et fiables ont produit l'apparence de la fiabilité elle-même. Le mécanisme qui permet à l'organisation ouverte de fonctionner, la confiance accordée à un inconnu sur la seule base de son comportement dans le temps, est précisément celui qui a été retourné contre elle.

Lifshitz-Assaf, dans son étude de la NASA, décrit un phénomène troublant qu'elle nomme l'adoption simulée : certains professionnels faisaient mine d'embrasser le modèle ouvert, participaient en apparence, mais protégeaient en réalité leurs frontières et n'intégraient jamais ce qui venait de l'extérieur. L'apparence de participation masquait son contraire. L'affaire Jia Tan en est le miroir inversé. Là où le professionnel de la NASA simulait l'ouverture tout en restant fermé, Jia Tan simulait l'appartenance et la loyauté tout en préparant une trahison. Dans les deux cas, ce qui se donne à voir n'est pas ce qui se joue. Et dans un système qui n'a, par construction, aucun moyen de vérifier les intentions, l'apparence est tout ce qui reste.

La bureaucratie de l'algorithme

Comment une organisation sans patron peut-elle alors se défendre ? La réponse, elle aussi, est inscrite dans l'outil.

Face à la pression et aux contributions douteuses, ce ne sont pas des décisions de chefs qui font barrage, mais des règles : la revue de code obligatoire, les protocoles de validation, les automatismes qui vérifient chaque modification. C'est ce que j'appellerais une bureaucratie de l'algorithme. Le mot bureaucratie n'est pas péjoratif ici. Il désigne, comme chez les théoriciens de l'organisation, un mode de contrôle qui passe par des règles impersonnelles plutôt que par l'autorité d'une personne. Sur GitHub, ce contrôle s'est simplement déplacé : de la hiérarchie humaine vers le protocole technique.

Mais il faut résister à l'idée que ces protocoles seraient neutres. Paul Leonardi et Stephen Barley (2010) ont précisément montré que la matérialité de la technique n'est jamais un détail neutre : les contraintes et les possibilités qu'un outil offre orientent l'action et y inscrivent des rapports de pouvoir. Décider qui peut valider une pull request, quelles vérifications sont automatiques, à quel moment un mainteneur peut déléguer ses droits, ce ne sont pas des choix techniques anodins. Ce sont des décisions d'organisation, et donc de pouvoir, simplement traduites en code. L'affaire XZ n'est pas le récit d'une technologie qui a failli. C'est le récit d'une organisation dont les règles de confiance et de délégation comportaient un angle mort.

Ce que j'en retiens

GitHub m'intéresse parce qu'il rend visible une tension que toute organisation virtuelle et ouverte devra affronter : on ne peut pas avoir l'ouverture sans la vulnérabilité qui l'accompagne. Ce sont les deux faces d'une même pièce. Abaisser les frontières pour laisser entrer la valeur, c'est aussi les abaisser pour laisser entrer le risque.

Ce constat dépasse largement le logiciel. À l'heure où tant d'organisations, publiques comme privées, adoptent des modèles plus distribués, plus collaboratifs, plus dépendants de la confiance à distance, la question n'est pas de savoir s'il faut s'ouvrir. C'est de savoir comment penser, en même temps que l'ouverture, les protocoles qui la rendent soutenable. Car au bout du compte, ce qui protège une organisation ouverte, ce n'est ni un chef ni un mur. C'est la lucidité avec laquelle elle conçoit ses propres règles.