Si créer un excellent logiciel demande peu de moyens, en copier un en demande encore moins. Ce qui veut dire que les conflits peuvent se résoudre de façon très intéressante et totalement impossible dans le monde réel. Pour autant que les régimes de propriété intellectuelle le permettent1, n’importe qui peut tout simplement faire une copie du logiciel et continuer à le développer de son côté. Dans le logiciel, cela s’appelle créer un fork2. Plusieurs projets peuvent également joindre leurs forces – on parle alors d’une fusion. La ressemblance avec les spin-off et les fusions dans le monde des affaires s’arrête là car les forks et les fusions dans le logiciel peuvent être des jeux à sommes non nulles.
Là où des processus démocratiques mèneraient à des impasses et ralentiraient les développements, le principe du consensus approximatif, du code qui fonctionne et la méthode RERO débouchent sur des chemins divergents les uns des autres, explorant de nombreuses possibilités en parallèle.
Cette approche de la résolution de conflits est tellement déconcertante3 qu’il a fallu presque trente ans, y compris aux hackers les plus pragmatiques, pour reconnaître que le forking était une pratique à encourager. Il s’est écoulé vingt-cinq ans entre l’apparition du terme « fork » pour désigner cette pratique (par Eric Altman, un hacker Unix, en 1980) et le développement de git (par Linus Torvalds, en 2005), un outil facilitant le forking. Git est aujourd’hui le système de gestion de code le plus utilisé au monde et a été à l’origine de GitHub, la plate-forme leader de partage de code.
Pour le développement de logiciels, ce modèle fonctionne tellement bien qu’il est en train de remplacer des méthodes de travail presque bicentenaires. Construite autour de l’idée de collaboration la plus large possible, d’une facilité de forking déconcertante et d’un recrutement ouvert par défaut, cette nouvelle méthode a tout pour plaire.
Le fonctionnement de ce modèle est particulièrement visible dans certains concours de programmation innovante comme les concours de programmation en Matlab organisés régulièrement par MathWorks.
Dans ces concours, les codes sources sont stockés dans des répertoires partagés et il est souvent permis aux candidats d’accéder autant qu’ils le souhaitent à tous les codes sources en cours de développement. Au début du concours, ce partage permet aux meilleures idées de se propager rapidement parmi tous les candidats. En se les appropriant, chacun ne fait en réalité que voter pour l’idée la plus prometteuse, quitte à travailler, temporairement, en collaboration. Garder son programme ou ses idées pour soi est en général contre-productif car il est fort probable qu’un autre concurrent butera sur les mêmes difficultés, arrivera à les améliorer de façon créative ou bien détectera une faiblesse qui lui permettra de vite échouer. Dans les étapes suivantes, ce processus crée une saine émulation où la rapidité d’exécution l’emporte sur la qualité des idées. Sans surprise, le gagnant du concours est souvent un candidat qui apporte à la dernière minute une légère modification au meilleur programme proposé.
De tels concours – qui présentent dans les grandes lignes les méthodes de la communauté de l’open source et les habitudes des entreprises leaders en la matière – ne font pas que démontrer la puissance de RERO ; ils prouvent aussi en quoi la facilité de forking et le partage aboutissent à des résultats globalement meilleurs.
Les logiciels qui prospèrent dans un tel environnement ont une caractéristique curieuse : le pire est l’ami du mieux4–5, comme a pu le dire l’informaticien Richard Gabriel. Du code qui fonctionne, favorise la simplicité d’utilisation, catalyse une collaboration productive et l’expérimentation rapide tend à se diffuser rapidement et d’une manière inattendue. Le code alambiqué des puristes, cohérent, raffiné et finalisé, est en train de mourir à petit feu.
Dans la vraie vie, les équipes se constituent autour d’un ou deux programmeurs-clé par un mécanisme de parrainage plutôt que par des concours. Typiquement, les membres se connaissent tous plus ou moins, ce qui fait que dans sa totalité l’équipe du projet ne dépasse que rarement une dizaine de personnes. Les programmeurs qui n’arrivent pas à bien s’intégrer partent rapidement. S’ils ne le font pas d’eux-mêmes, il est courant de leur demander explicitement de ne rien faire. S’ils persistent, on les ignore.
La taille idéale d’une équipe n’est pas tranchée mais la règle des deux pizzas de Jeff Bezos suggère qu’elle ne dépasse pas une dizaine de personnes6.
La qualité des logiciels développés selon le principe « le pire est l’ami du mieux » est sans comparaison avec celle du code écrit par des équipes de programmeurs anonymes et interchangeables, recrutés par procédures hiérarchiques et bureaucratiques. En paraphrasant R. Gabriel, on pourrait dire que le résultat est digne du dicton « le mieux est l’ennemi du bien » : des visions utopiques qui échouent lamentablement pour autant qu’elles aillent un jour au-delà du vaporware7 tout court.
Le projet OS/2, lancé par IBM au début des années 19908 et dont l’objectif était de remplacer le système MS-DOS qui dominait alors le marché, constitue une illustration parfaite du principe « le pire est l’ennemi du mieux ». Le projet comptait plusieurs milliers de développeurs et chacun devait concevoir, écrire, débugger, documenter et assurer le support de dix lignes de code par jour au maximum. Ecrire plus de dix lignes par jours, c’était passer pour un irresponsable. Pour dimensionner l’équipe nécessaire, on avait commencé par évaluer le nombre de lignes de codes écrites à la fin du projet et on l’avait divisé par le nombre de jours alloués au projet ; enfin, une division par dix avait permis d’arriver au nombre de développeurs à assigner au projet. Inutile de préciser qu’on considérait que les programmeurs étaient totalement interchangeables. En doublant le nombre de développeurs assignés au projet, on aurait pu diviser par deux à n’importe quel moment le « temps » de développement nécessaire pour le terminer9. Pendant ce temps-là, des dizaines de managers partout dans l’entreprise pouvaient décider de ne pas valider la nouvelle version du projet en cours selon le principe sinistrement célèbre de « non concurrence ».
Au contraire, « le pire est l’ami du mieux » peut constituer un choc culturel important pour ceux qui sont habitués aux méthodes de travail de l’ère industrielle. On lui reproche surtout de permettre aux start-up et aux projets open source de se tailler la part du lion des talents disponibles dans une région donnée à un moment donné, ce qui entrave la croissance des autres projets. La cerise sur le gâteau, c’est que cela semble parfois bénéficier aux projets les plus farfelus ou les plus improbables, tarissant les projets qui pourraient paraître plus importants. Ce phénomène, qui voit les talents les plus recherchés tout abandonner pour se jeter sur quelques opportunités, constitue l’impitoyable loi du genre. Cela permet à quelques produits exceptionnels d’émerger au milieu d’un océan de produits laissés à l’abandon, au grand dam des partisans d’un autoritarisme fort qui pensent en termes de « bonnes » et de « mauvaises » technologies.
Non content de fonctionner, ce modèle est également grandement créateur de valeur au travers des start-up et des projets open source. Des concepts comme le consensus approximatif, le pivot, les essais-erreurs, l’amélioration continue, le forking, l’opt-in et le pire est l’ami du mieux, font tache d’huile au-delà du logiciel et essaiment partout dans le monde. Où qu’ils s’imposent, ils limitent les visions autoritaires et font battre en retraite les idéologies des puristes.
Cette approche n’est certainement pas sans risques et il serait naïf de ne pas les reconnaître. Internet tel qu’on le connaît aujourd’hui est le résultat de millions de décisions pragmatiques prises rapidement par des centaines de milliers d’individus qui écrivent du code qui fonctionne, des décisions qui faisaient toutes sens quand elles ont été prises. Il ne fait aucun doute que toutes ces décisions ont contribué aux graves problèmes qui se posent aujourd’hui, du piètre niveau de sécurité des protocoles d’Internet aux débats autour de sa neutralité. Il faut cependant reconnaître que si l’approche pragmatique n’avait pas prévalu, Internet n’aurait jamais été très différent de l’ARPANET des débuts. Au lieu d’une économie numérique florissante qui ambitionne de dynamiser l’économie traditionnelle, le monde se serait sans doute fourvoyé dans des impasses comparables au mainframe de cinquième génération des puristes japonais.
De plus, avec des technologies telles que la blockchain (qui sert de base aux crypto-monnaies comme le Bitcoin), on cherche actuellement des solutions à des problèmes hérités du passé. Ces technologies sont largement plus créatives que les solutions discutées aux débuts d’Internet et représentent des solutions à des problèmes qui se sont réellement posés et non pas les états d’âmes issus des visions autoritaires modernistes. Plus important, rétrospectivement ces technologies valident le choix initial de résistance à l’optimisation prématurée et laissent autant d’espace créatif que possible aux innovateurs à venir. Naturellement, si certaines solutions émergentes s’imposent, cela fera surgir d’autres problèmes qui devront être résolus à leur tour, perpétuant ainsi la tradition pragmatique de l’éternelle beta.
Notre étude de la nature du logiciel mène à une conclusion évidente : la puissance qui s’en dégage est hautement subversive. Comme dans le Blitzkrieg, ceux qui se retrouvent du mauvais côté du manche encaissent des assauts donnés par une équipe agile parfaitement huilée et voient arriver la zemblanité : une sensation d’inéluctable débâcle.
Ce scénario s’est déjà produit suffisamment souvent qu’une atmosphère de zemblanité généralisée plane sur tous les secteurs de l’économie traditionnelle. Chaque start-up à croissance agressive est comme un commando des forces spéciales qui occupe le terrain avec ses programmes de machine learning à tuer le travail et ses robots qui arrivent dans la foulée.
L’économie dévorée par le logiciel elle-même est encore plus mue par la disruption : le temps nécessaire pour passer du rôle de prédateur au rôle de proie s’est considérablement réduit au cours des dix dernières années. Les start-up d’aujourd’hui en sont parfaitement conscientes et c’est ce qui explique l’agressivité sans concession dont elles font preuve.
Pour les acteurs de l’économie traditionnelle, il est tout à fait compréhensible que l’idée du logiciel dévorant le monde se résume à une guerre sans merci opposant la technologie à l’humanité.
Mais en réalité c’est exactement le contraire : à l’inverse de la guerre ou de la finance boursière de haut vol, le progrès technologique n’est pas un jeu à somme nulle et c’est ce qui fait toute la différence. La force prométhéenne que la technologie représente aujourd’hui est la force qui a toujours tiré l’humanité de ses pires problèmes, juste au moment où la fin de la civilisation semblait inéluctable. De l’invention de l’écriture à celle de la télévision, pour chaque progrès technologique, ceux qui n’ont pas su voir le jeu à somme non nulle qui se tramait ont prédit – à tort – la fin du monde. Utilisant à chaque fois une variante du bon vieux thème « cette fois-ci, c’est différent », ils se sont toujours trompés.
L’humanité n’a jamais eu à faire face à la fin de l’humanité, au contraire elle a toujours atteint un nouveau degré de bien-être et de prospérité.
Naturellement, cette liste d’erreurs d’appréciation ne prouve pas que ce sera différent cette fois- ci. Rien ne dit que l’avenir ne ressemblera pas au passé. Rien ne dit que notre société globalisée puisse résister là où l’empire romain et la civilisation maya ont échoué. L’évolution de l’humanité doit être reconsidérée à la lumière de chaque avancée technologique et les problèmes nouveaux, tels que le changement climatique, doivent être regardés de près.
Mais considérer que l’humanité puisse s’éteindre ne doit pas nous amener à nous limiter pour autant à des conceptions du monde que le philosophe James Carse appelle des jeux finis10 et dont le « premier prix » serait un monde idéal et utopique où rien n’aurait changé. Comme nous allons le voir dans le chapitre suivant, il faut adopter une mentalité qui relève de ce que Carse appelle le jeu infini et qui se fonde sur la volonté de poursuivre un jeu qui s’enrichirait à mesure qu’il se déroule. De ce point de vue, le logiciel dévorant le monde est bien la meilleure chose qui puisse nous arriver.
Précédent | Remonter | Suivant
[1] Ici l’auteur évoque sans le dire les licences libres et Open Source (ndt).
[2] L’expression française consacrée est « fourche », mais nous gardons ici l’expression originale qui est d’usage beaucoup plus courant (ndt).
[3] Aussi séditieux qu’il puisse paraître, le principe du forking est possible car il s’appuie sur une caractéristique propre au logiciel, un coût de copie nul (ou, pour le dire autrement, un coût marginal). En ce sens, le forking est à rapprocher de la notion de réaction silencieuse (qui se manifeste par le départ) qu’on trouve dans le fameux modèle de contesta- tion d’Albert Hirschman, et qui offre le choix entre réaction silencieuse et protestation. Une des façons de comprendre la nature du logiciel, c’est que pour exprimer une contestation, on préfère la réaction silencieuse à la protestation. Ce principe s’est étendu au-delà du logiciel. C’est ce qui a rendu célèbre la loi des deux pieds dans les anti-conférences où plutôt que de rester juste pour faire plaisir au conférencier, la coutume est de quitter la salle si la session n’est pas inté- ressante. Au cours d’une conférence datant de 2013, Balaji Srinvasan a suggéré que dans un contexte plus politique, la réaction silencieuse pourrait bien être en train de s’imposer pour manifester un mécontentement. Les commentateurs politiques établis ont alors poussé des cris d’orfraie, voyant dans cette idée une volonté sécessionniste ou un abandon de responsabilité. Comme B. Srinvasan et d’autres l’ont démontré depuis, ce n’est pas forcément le cas. Le logiciel ouvre des perspectives créatives pour des modèles politiques fondés sur la réaction silencieuse, telle que la notion d’autorités publiques fonctionnelles, a-territoriales et concurrentielles proposée par Bruno Frey ou des idées comme les charter cities aux USA, qui envisagent des équivalents de la loi des deux pieds au niveau municipal. Le boycott d’un service constitue une version atténuée de ce principe. Plus simplement, la réaction silencieuse, qui consiste à ne pas acheter un produit est mécanisme économique bien connu. Au plan politique, le choix du pays le plus favorable – qui consiste pour des individus ou des entreprises à passer d’un côté ou de l’autre d’une frontière en fonction du pays offrant le régime le plus favorable – est déjà une réalité internationale. Avec les expériences actuelles autour de nouveaux concepts de citoyenneté, tels que la proposition de e-citoyenneté en Estonie, ces dynamiques ne font que se renforcer.
[4] En anglais : worse is better (ndt).
[5] Cette expression a connu une histoire savoureuse depuis son invention par Richard Gabriel dans un article datant de 1989. Au départ il ne s’agissait pas tant d’un jugement de valeur de l’auteur que d’une remarque mi-figue, mi-raisin sur une tendance émergente en programmation. Cela a déclenché une telle polémique que l’auteur a fait amende honorable en signant sous un pseudonyme un article intitulé «Le pire est l’ami du mieux est pire», puis toute cette polémique a tourné au vinaigre et il vous sera plus aisé de la lire sous la plume même de Richard Gabriel (Voir cet article, en anglais : https://www.dreamsongs.com/WorseIsBetter.html). Le fin mot de l’histoire, c’est que R. Gabriel est resté résolument ambigu. Dans l’informatique en revanche, cette maxime a continué de faire son chemin. Pour les pragmatistes, elle a accédé au rang de principe important et qui fonctionne. Pour les puristes, c’est une source de jérémiade de plus.
[6] Voir à ce propos « Birth of a Salesman », un article du Wall Street Journal (2011) consacré à Jeff Bezos et qui fait référence à la règle des deux pizzas. Cette idée faisait cependant partie du folklore du logiciel depuis bien longtemps.
[7] Ce terme désigne un logiciel annoncé depuis longtemps mais dont la sortie se fait toujours attendre (ndt).
[8] Cet exemple s’appuie sur les souvenirs de Marc Andreessen qui travaillait chez IBM à cette époque.
[9] Dès 1975, on savait déjà parfaitement qu’ajouter des développeurs sur un projet en retard ne faisait que le retarde encore plus (ce principe est connu sous le nom de loi de Brooks). Voir à ce propos le livre de Frederick Brooks The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), Addisson-Wesley, 1995. Ironiquement, ce principe a été édicté à la suite d’un projet d’IBM.
[10] A la croisée de la poésie et de la métaphysique, le livre de James Carse, Finite and Infinite Games (Ballantine Books, 1987) n’est pas, strictement parlant, en relation directe avec les thématiques du présent travail. Pour les amateurs de philosophie cependant, ce livre illustre parfaitement ce que donneraient les différents principes que nous décrivons (pragmatistes contre puristes, hacking contre conservatisme et prométhéens contre pastoralistes) s’ils étaient appliqués à la philosophie.