L'imaginaire d'une infrastructure numérique auto-entretenue immuable
Edit 1er avril 2024, après le désastre évité de xz – voir par exemple ce post, juste pour qu'on se rende compte à quel point on est dépendants de choses assez compliquées.
A chaque fois qu'on discute blockchain/NFT/web 3/... et maintenant IA avec des informaticiens ou non, j'ai envie d'ajouter un argument qui me vient de mon passé de recherche sur les systèmes critiques. Pour une analyse approfondie de la famille blockchain je conseille comme toujours Promesses et (dés)illusions. Une introduction technocritique aux blockchains de Pablo Rauzy.
Tous les discours techniquement infondés sur ces objets reposent sur un non-dit, un sous-entendu constant, un imaginaire d'infrastructures numériques auto-entretenues, autonomes, immuables pour le reste des temps, et donc par nature plus fiables que les organisations humaines (et moins coûteuses). Cela peut venir de la science-fiction, mais c'est aussi l'expression profonde d'une position politique qui tend à la défiance envers toute organisation humaine. Promouvoir le numérique partout a évidemment des motivations économiques (qu'on pense à la destruction systématique des services publics sous prétexte de “dématérialisation” qui s'accompagne systématiquement de désintermédiation), mais au fond il y a aussi cet élément de défiance. Et pour finir sur ces imaginaires, c'est assez cocasse que des gens qui n'ont que l'innovation à la bouche défendent aussi fermement l'immuabilité prétendue de solutions à base de blockchains.
Je ne discuterai pas plus politique ici. Pour un regard décidément critique et politique voir No Crypto. Comment Bitcoin a envoûté la planète. de Nastasia Hadjadji.
Voilà quelques arguments techniques sur la (non) possibilité de telles infrastructures auto-entretenues immuables. TL;DR : Cela n'existera jamais.
Développement initial, bugs, sécurité
Le premier argument non technique que j'oppose en général aux adeptes du bitcoin comme système bancaire qui permet de s'affranchir des banques, c'est qu'on déplace sa confiance dans les banques et les états vers une confiance aveugle en des développeurs de code que par ailleurs on ne maîtrisera jamais soi-même. Même sans les soupçonner de malversations délibérées, ils feront comme tous les développeurs de tous les temps : des bugs. En particulier des bugs qui se traduisent par des trous de sécurité. Voir à quelle fréquence les systèmes de ce type sont attaqués avec succès : Web3 is going just great de Molly White.
La mode des smart contracts qui se doivent d'être turing-complets (sinon c'est petit joueur) emmène le domaine à de nouvelles altitudes. Dans mon expérience de validation de systèmes critiques, quand un domaine permet des retours en arrière on saute à pieds joints et avec grand soulagement sur cette possibilité. C'est la différence entre un système bancaire (quand ça se plante c'est très ennuyeux et coûteux mais on peut revenir à un état antérieur correct) et un système de contrôle dans une fusée (quand le bug est détecté c'est trop tard. Voir le vol initial de Ariane 5 pour ceux qui s'en souviennent). L'idée de s'attacher sciemment les mains derrière le dos en inventant un système “bancaire” immuable, c'est... disons curieux.
Et la maintenance ?
Mais il ne s'agit pas que de devoir faire confiance aux développeurs initiaux. Le numérique ne fonctionne que parce qu'on le surveille comme le lait sur le feu, alors même que la maintenance est totalement invisibilisée. Sur ce sujet je conseille l'article The care of things (and Gephi) de Mathieu Jacomy ainsi que le livre qui y est commenté : Le soin des choses – Politiques de la maintenance. De Jérôme Denis et David Pontille. Comment les “solutions” à base de blockchains pourraient-elles échapper à cette règle générale sur le besoin de maintenance ? Et qui s'en occupe ?
[Edit 1er avril 2024 ] : quand on pense que la sécurité des échanges sur internet tient à une brindille quelque part, et à tous les aspects sociaux de l'écosystème du logiciel, l'idée de faire confiance “à du logiciel”, plutôt qu'à des êtres humains, apparaît pour ce qu'elle est : une grosse bêtise totalement dénuée de sens.
Durée de vie effective des solutions numériques
Pensez à tous les logiciels qui vous viennent à l'esprit, en cherchant lequel marche quasiment sans intervention, depuis le plus longtemps. Sur quel matériel tourne-t-il ? Quelle est sa durée de vie ? 30, 20, 10, 5, 1 an ?
Comme exemple récent, les grandes envolées sur la science reproductible avec des articles “exécutables”, tout ça basé sur du Python : As of 2024, this project is archived and unmaintained. While is has achieved its mission of demonstrating that unifying computational reproducibility and provenance tracking is doable and useful, it has also demonstrated that Python is not a suitable platform to build on for reproducible research.
Inversement il existe du code qui tourne depuis longtemps (~ 30 ans), mais dans des contextes très critiques (comme des centrales nucléaires). Ce sont des systèmes fermés, conçus à l'origine avec des méthodes très contraignantes et des contraintes matérielles très fortes, sans prétention à l'extensibilité. Leur durée de vie s'accompagne de la nécessité de stocker des pièces “détachées”, c'est-à-dire les processeurs pour lesquels elles avaient été développées et validées. Je mentionnais récemment ces exemples dans une remise en cause de l'extensibilité ici : Revisiting “Good” Software Design Principles To Shape Undone Computer Science Topics.
La simple obsolescence du matériel nécessaire aux “mineurs” de la blockchain suffit à démonter les arguments d'immuabilité.