Traduction de l’article https://pluralistic.net/2026/01/06/1000x-liability/#graceful-failure-modes de Cory Doctorow
Bonne lecture
Le code est un fardeau (et non un atout). Les dirigeants du secteur technologique ne le comprennent pas. Ils pensent que l’IA est formidable parce qu’elle produit 10 000 fois plus de code qu’un programmeur, mais cela signifie simplement qu’elle génère 10 000 fois plus de fardeaux. L’IA est l’amiante que nous enfouissons dans les murs de notre société high-tech :
https://pluralistic.net/2025/09/27/econopocalypse/#subprime-intelligence
Le code est un fardeau. Les capacités du code sont des atouts. L’objectif d’une entreprise technologique est de disposer d’un code dont les capacités génèrent plus de revenus que les coûts liés à son fonctionnement. Pendant longtemps, les entreprises ont entretenu la fausse croyance selon laquelle le code coûte moins cher à faire fonctionner au fil du temps : après une période initiale de rodage au cours de laquelle les bogues du code sont détectés et corrigés, le code ne nécessite plus de maintenance significative. Après tout, le code est une machine sans pièces mobiles – il ne s’use pas ; il ne s’use même pas avec le temps.
Telle est la thèse du livre de Paul Mason publié en 2015, *Postcapitalism*, un ouvrage qui a remarquablement mal vieilli (même si ce n’est peut-être pas autant que la crédibilité politique de Mason lui-même) : le code n’est pas une machine reproductible à l’infini qui ne nécessite aucun apport de main-d’œuvre pour fonctionner. Il s’agit plutôt d’une machine fragile qui nécessite des mesures de plus en plus héroïques pour la maintenir en bon état de fonctionnement, et qui finit par « s’user » (au sens où elle nécessite une refonte complète).
Pour comprendre pourquoi le code est un fardeau, il faut comprendre la différence entre « écrire du code » et « l’ingénierie logicielle ».
« Écrire du code » est un passe-temps incroyablement utile, amusant et captivant. Elle consiste à décomposer des tâches complexes en étapes distinctes décrites avec une telle précision qu’un ordinateur peut les exécuter de manière fiable, et à optimiser ces performances en trouvant des moyens astucieux de minimiser les sollicitations que le code impose aux ressources de l’ordinateur, telles que la mémoire vive et les cycles du processeur.
Par ailleurs, le « ingénierie logicielle » est une discipline qui englobe l’« écriture de code », mais qui se concentre sur le fonctionnement à long terme du système dont le code fait partie. L’ingénierie logicielle s’intéresse aux processus en amont qui génèrent les données que le système reçoit. Elle s’intéresse aux processus en aval vers lesquels le système transmet les informations traitées. Elle s’intéresse aux systèmes adjacents qui reçoivent des données provenant des mêmes processus en amont et/ou qui transmettent des données vers les mêmes processus en aval que ceux vers lesquels le système transmet.
« Écrire du code », c’est créer un code qui fonctionne bien. « L’ingénierie logicielle », c’est créer un code qui échoue bien. Il s’agit de créer un code lisible – dont les fonctions peuvent être comprises par des tiers à qui l’on pourrait demander de le maintenir, ou d’adapter les processus en aval, en amont ou adjacents au système pour empêcher celui-ci de tomber en panne. Il s’agit de créer un code qui puisse être adapté, par exemple, lorsque l’architecture informatique sous-jacente sur laquelle il s’exécute est retirée et doit être remplacée, soit par un nouveau type d’ordinateur, soit par une version émulée de l’ancien ordinateur :
https://www.theregister.com/2026/01/05/hpux_end_of_life
Car voilà le problème : tout code non trivial doit interagir avec le monde extérieur, et le monde extérieur n’est pas statique, il est dynamique. Le monde extérieur bouscule sans cesse les hypothèses formulées par les auteurs de logiciels, et chaque fois que cela se produit, le logiciel doit être corrigé. Vous vous souvenez du bug de l’an 2000 ? C’était le jour où un code parfaitement fonctionnel, tournant sur du matériel parfaitement fonctionnel, allait cesser de fonctionner – non pas parce que le code avait changé, mais parce que le temps avait passé.
Nous sommes à 12 ans du problème Y2038, lorsque les versions 32 bits d’Unix cesseront toutes de fonctionner, car elles aussi auront épuisé leur réserve de secondes calculables. Ces ordinateurs n’ont pas changé, leurs logiciels n’ont pas changé, mais le monde – à force de tourner, seconde après seconde, depuis 68 ans – finira par les user jusqu’à la corde, et ils céderont :
https://www.theregister.com/2025/08/23/the_unix_epochalypse_might_be
L’existence du « monde » est un facteur inévitable qui use les logiciels et nécessite leur reconstruction, souvent à un coût énorme. Plus le code est en service depuis longtemps, plus il est susceptible de se heurter au « monde ». Prenons le code que les appareils utilisent pour signaler leur emplacement physique. À l’origine, il servait à des fins telles que la facturation – pour déterminer le réseau de l’opérateur ou du fournisseur que vous utilisiez et si vous étiez en itinérance. Ensuite, nos appareils mobiles ont utilisé ce code pour aider à déterminer votre emplacement afin de vous fournir des indications détaillées dans les applications de navigation. Puis, ce code a été réutilisé pour nous aider à retrouver nos appareils perdus. Cela est ensuite devenu un moyen de localiser des appareils volés, un cas d’utilisation qui diverge considérablement de la recherche d’appareils perdus sur des points importants – par exemple, lorsque vous localisez un appareil perdu, vous n’avez pas à faire face à la possibilité qu’un acteur malveillant ait désactivé la fonction « trouver mon appareil perdu ».
Ces cas d’utilisation supplémentaires – en amont, en aval et adjacents – ont révélé des bogues dans le code d’origine qui n’étaient jamais apparus dans les applications précédentes. Par exemple, tous les services de localisation doivent avoir un comportement par défaut dans le cas (très courant) où ils ne savent pas vraiment où ils se trouvent. Peut-être disposent-ils d’une localisation approximative – par exemple, ils savent à quelle antenne-relais ils sont connectés, ou ils savent où ils se trouvaient la dernière fois qu’ils ont obtenu une localisation précise – ou peut-être sont-ils complètement perdus.
Il s’avère que dans de nombreux cas, les applications de localisation dessinaient un cercle autour de tous les endroits où elles pourraient se trouver, puis fixaient leur position au centre de ce cercle. Cela ne pose pas de problème si le cercle ne mesure que quelques mètres de diamètre, ou si l’application remplace rapidement cette approximation par une localisation plus précise. Mais que se passe-t-il si le cercle s’étend sur des kilomètres et des kilomètres, et que la localisation ne s’améliore jamais ? Et si la localisation de toute adresse IP sans emplacement défini était donnée comme le centre des États-Unis continentaux et que toute application ne sachant pas où elle se trouve signalait qu’elle se trouve dans une maison au Kansas, envoyant ainsi des dizaines d’inconnus furieux (parfois armés) à cette maison, affirmant que les propriétaires sont en possession de leurs téléphones et tablettes volés ?
https://theweek.com/articles/624040/how-internet-mapping-glitch-turned-kansas-farm-into-digital-hell
Il ne suffit pas de corriger ce bug une seule fois : il faut le corriger encore et encore.
En Géorgie :
https://www.jezebel.com/why-lost-phones-keep-pointing-at-this-atlanta-couples-h-1793854491
Au Texas :
Et dans ma ville de Burbank, où le service de localisation de Google nous a un jour indiqué que notre fille, alors âgée de 11 ans (et que nous ne parvenions pas à joindre au téléphone), se trouvait à 19 km de là, sur une bretelle d’autoroute dans une zone non incorporée du comté de Los Angeles (elle était en réalité dans un parc voisin, mais hors de portée, et l’application avait estimé sa position comme étant le centre de la région où elle l’avait localisée pour la dernière fois) (ce furent deux heures difficiles).
Le code sous-jacent – celui qui utilise un paramètre par défaut autrefois inoffensif pour estimer des emplacements inconnus – doit être mis à jour en permanence, car les processus en amont, en aval et adjacents qui y sont connectés changent en permanence. Plus ce code reste en place, plus ses comportements d’origine deviennent obsolètes, et plus les correctifs superposés deviennent baroques, encombrants et obscurs.
Le code n’est pas un atout – c’est un fardeau. Plus un système informatique fonctionne depuis longtemps, plus il représente une dette technique. Plus le système est important, plus il est difficile de le mettre hors service et de le refaire entièrement. Au lieu de cela, de nouvelles couches de code sont superposées par-dessus, et partout où ces couches se rencontrent, il y a des fissures dans lesquelles ces systèmes se comportent de manière incohérente. Pire encore : lorsque deux entreprises fusionnent, leurs systèmes informatiques, déjà couturés et fissurés, sont bruts-à-bruts, de sorte qu’il y a désormais des sources adjacentes de dette technique, ainsi que des fissures en amont et en aval :
https://pluralistic.net/2024/06/28/dealer-management-software/#antonin-scalia-stole-your-car
C’est pourquoi les grandes entreprises sont si vulnérables aux attaques par ransomware : elles regorgent de systèmes incompatibles qui ont été contraints à une compatibilité de façade à l’aide de diverses formes de pâte à modeler numérique, de ficelle et de fil de fer. Elles ne sont pas étanches et ne peuvent pas l’être. Même si elles ne sont pas mises hors service par des pirates informatiques, elles tombent parfois en panne et ne peuvent plus être remises sur pied – comme lorsque les ordinateurs de Southwest Airlines ont planté pendant toute la semaine de Noël 2022, bloquant des millions de voyageurs :
https://pluralistic.net/2023/01/16/for-petes-sake/#unfair-and-deceptive
Les compagnies aériennes sont particulièrement mal loties, car elles se sont informatisées très tôt et ne peuvent jamais mettre hors service les anciens ordinateurs pour les remplacer par des nouveaux. C’est pourquoi leurs applications sont de véritables merdes – et pourquoi c’est si horrible qu’elles aient licencié leur personnel du service client et obligent les voyageurs à utiliser les applications pour tout, alors que ces applications ne fonctionnent pas. Ces applications ne fonctionneront jamais.
La raison pour laquelle l’application de British Airways affiche « Une erreur inconnue s’est produite » dans 40 à 80 % des cas n’est pas (seulement) qu’ils ont licencié tout leur personnel informatique et externalisé vers des prestataires étrangers au prix le plus bas. C’est vrai, bien sûr – mais c’est aussi parce que les premiers ordinateurs de BA fonctionnaient avec des valves électromécaniques, et que tout ce qui a suivi doit être rétrocompatible avec un système qu’un des protégés d’Alan Turing a sculpté dans un tronc d’arbre à l’aide de ses propres dents de devant. Le code est un fardeau, pas un atout (la nouvelle application de BA a des années de retard).
Le code est un fardeau. Les serveurs des terminaux Bloomberg qui ont fait de Michael Bloomberg un milliardaire fonctionnent avec des puces RISC, ce qui signifie que l’entreprise est contrainte de recourir à un nombre de plus en plus restreint de fournisseurs spécialisés en matériel et en centres de données, de payer des programmeurs spécialisés et de construire des chaînes de code fragiles pour relier ces systèmes RISC à leurs équivalents moins exotiques dans le monde. Le code n’est pas un atout.
L’IA peut écrire du code, mais l’IA ne peut pas faire de l’ingénierie logicielle. L’ingénierie logicielle consiste à réfléchir au contexte : qu’y aura-t-il avant ce système ? Qu’y aura-t-il après ? Qu’y aura-t-il à ses côtés ? Comment le monde va-t-il changer ? L’ingénierie logicielle nécessite une « fenêtre contextuelle » très large, ce que l’IA n’a pas et ne peut pas avoir. L’IA a une fenêtre contextuelle très étroite et superficielle, et toute extension linéaire de cette fenêtre nécessite une expansion géométrique des ressources de calcul consommées par l’IA :
https://pluralistic.net/2025/10/29/worker-frightening-machines/#robots-stole-your-jerb-kinda
Écrire du code qui fonctionne, sans se demander comment il va échouer, est la recette d’une catastrophe. C’est une façon de créer une dette technique à grande échelle. C’est comme enfouir de l’amiante dans les murs de notre société technologique.
Les patrons ne savent pas que le code est un fardeau, pas un atout. C’est pourquoi ils n’arrêtent pas de rabâcher à propos des chatbots qui crachent 10 000 fois plus de code que n’importe quel programmeur humain. Ils pensent avoir trouvé une machine qui produit des atouts à un rythme 10 000 fois supérieur à celui d’un programmeur humain. Ce n’est pas le cas. Ils ont trouvé une machine qui produit du fardeau à un rythme 10 000 fois supérieur à celui de n’importe quel programmeur humain.
La maintenabilité n’est pas seulement une question d’expérience durement acquise qui vous apprend où se trouvent les pièges. Elle nécessite également de cultiver le « Fingerspitzengefühl » – ce « au doigt mouillé » qui vous permet de deviner raisonnablement où pourraient surgir des pièges jamais vus auparavant. C’est une forme de connaissance des processus. Elle est inéluctable. Elle n’est pas latente, même dans le plus vaste corpus de code que vous pourriez utiliser comme données d’entraînement :
https://pluralistic.net/2025/09/08/process-knowledge/#dance-monkey-dance
Nom d’un chien, les patrons du secteur tech ne comprennent vraiment pas ça. Prenez Microsoft. Leur grand pari actuel, c’est l’« IA agentique ». Ils pensent que s’ils installent sur votre ordinateur un logiciel espion qui capture chaque frappe, chaque communication, chaque écran que vous voyez et les envoie vers le cloud de Microsoft, puis qu’ils donnent accès à cette mine de données à une ménagerie de chatbots, vous pourrez dire à votre ordinateur : « Réserve-moi un train pour Cardiff, trouve l’hôtel dont Cory a parlé l’année dernière et réserve-moi une chambre là-bas », et il le fera.
C’est une idée incroyablement irréalisable. Aucun chatbot n’est même de loin capable de faire tout cela, ce que Microsoft reconnaît ouvertement. Plutôt que de faire cela avec un seul chatbot, Microsoft propose de répartir cette tâche entre des dizaines de chatbots, dont Microsoft espère porter la fiabilité à 95 % pour chacun.
C’est un niveau de fiabilité tout à fait invraisemblable en soi, mais considérez ceci : les probabilités sont multiplicatives. Un système comprenant deux processus fonctionnant avec une fiabilité de 95 % a une fiabilité nette de 90,25 % (0,95 * 0,95). Répartissez une tâche entre une vingtaine de bots précis à 95 % et la probabilité que cette tâche soit accomplie correctement tend vers zéro.
Pire encore, Microsoft a déclaré publiquement qu’il accorderait à l’administration Trump un accès secret à toutes les données stockées dans son cloud :
Ainsi, comme l’ont expliqué Meredith Whittaker et Udbhav Tiwari de Signal lors de leur incroyable intervention à la 39C3 la semaine dernière à Hambourg, Microsoft est sur le point d’abolir la notion même de confidentialité pour toutes les données stockées sur les ordinateurs personnels et d’entreprise, afin de commercialiser des agents IA qui ne peuvent jamais fonctionner :
Par ailleurs, un dirigeant de Microsoft s’est attiré des ennuis en décembre dernier lorsqu’il a publié sur LinkedIn un message annonçant son intention de faire réécrire tout le code de Microsoft par l’IA. La refonte du code source de Microsoft est tout à fait logique. Microsoft – à l’instar de British Airways et d’autres entreprises traditionnelles – possède beaucoup de code très ancien qui représente une dette technique insoutenable. Mais utiliser l’IA pour réécrire ce code revient à commencer avec une dette technique qui ne fera que s’accumuler au fil du temps :
À présent, certains d’entre vous qui lisez ceci ont entendu des ingénieurs en logiciel vanter la valeur incroyable de l’utilisation d’un chatbot pour écrire du code à leur place. Certains d’entre vous sont des ingénieurs en logiciel qui ont trouvé les chatbots incroyablement utiles pour écrire du code à leur place. C’est un paradoxe courant de l’IA : pourquoi certaines personnes qui utilisent l’IA la trouvent-elles vraiment utile, tandis que d’autres la détestent ? Est-ce que les personnes qui n’aiment pas l’IA sont « mauvaises en IA » ? Est-ce que les fans de l’IA sont paresseux et se moquent de la qualité de leur travail ?
Il y a sans doute un peu des deux, mais même si l’on formait tout le monde à devenir un expert en IA et que l’on éliminait de l’échantillon tous ceux qui ne sont pas fiers de leur travail, le paradoxe subsisterait. La véritable solution au paradoxe de l’IA réside dans la théorie de l’automatisation et dans les concepts de « centaures » et de « centaures inversés » :
https://pluralistic.net/2025/09/11/vulgar-thatcherism/#there-is-an-alternative
En théorie de l’automatisation, un « centaure » est une personne assistée par une machine. Un « centaure inversé » est quelqu’un qui a été enrôlé pour assister une machine. Si vous êtes un ingénieur logiciel qui utilise l’IA pour écrire du code de routine que vous avez le temps et l’expérience de valider, en mettant à profit votre intuition et votre connaissance des processus pour vous assurer qu’il est adapté à son usage, il est facile de comprendre pourquoi vous pourriez trouver utile d’utiliser l’IA (lorsque vous le choisissez, de la manière que vous choisissez, au rythme que vous choisissez).
Mais si vous êtes un ingénieur logiciel à qui l’on a ordonné de produire du code à un rythme 10, 100 ou 10 000 fois supérieur à votre rythme habituel, et que la seule façon d’y parvenir est d’utiliser l’IA, et qu’il n’y a aucun moyen humain pour vous de vérifier ce code et de vous assurer qu’il ne plantera pas dès son premier contact avec le monde réel, vous allez détester ça (vous le détesterez encore plus si vous avez été transformé en bouc émissaire de l’IA, personnellement responsable des erreurs de l’IA) :
https://pluralistic.net/2025/05/27/rancid-vibe-coding/#class-war
Il existe une autre situation dans laquelle les ingénieurs logiciels trouvent le code généré par l’IA incroyablement utile : lorsque ce code est isolé. Si vous travaillez sur un projet unique – par exemple, convertir un lot de fichiers dans un autre format, une seule fois – vous n’avez pas à vous soucier des processus en amont, en aval ou adjacents. Il n’y en a pas. Vous écrivez du code pour faire quelque chose une seule fois, sans interagir avec aucun autre système. Une grande partie du codage consiste en ce type de projet utilitaire. C’est fastidieux, ingrat et mûr pour l’automatisation. De nombreux projets personnels entrent dans cette catégorie et, bien sûr, par définition, un projet personnel est un projet centaure. Personne ne vous oblige à utiliser l’IA dans un projet personnel : c’est toujours à vous de choisir comment et quand vous utilisez un outil à des fins personnelles.
Mais le fait que les ingénieurs logiciels puissent parfois améliorer leur travail grâce à l’IA n’invalide pas le fait que le code est un fardeau, et non un atout, et que le code d’IA représente une production de fardeaux à grande échelle.
Dans le débat sur le chômage technologique, il y a l’idée que les nouvelles technologies créent de nouveaux emplois tout en rendant les anciens obsolètes : pour chaque forgeron mis au chômage par l’automobile, il y a un emploi qui l’attend en tant que mécanicien. Depuis que la bulle de l’IA a commencé à gonfler, nous avons entendu de nombreuses variantes de ce discours : l’IA créerait des emplois pour des « ingénieurs de prompts » – voire des emplois que nous ne pouvons pas imaginer, car ils n’existeront pas tant que l’IA n’aura pas transformé le monde au point de le rendre méconnaissable.
Je ne parierais pas sur la possibilité de trouver du travail dans un métier fantaisiste qui est littéralement inimaginable, car notre conscience n’a pas encore été suffisamment transformée par l’IA pour acquérir la capacité de conceptualiser ces nouveaux modes de travail.
Mais si vous cherchez un emploi que l’IA créera à coup sûr, par millions, j’ai une suggestion : le désamiantage numérique.
Car si le code IA – écrit 10 000 fois plus vite que n’importe quel codeur humain, conçu pour bien fonctionner, mais pas pour échouer avec élégance – est l’amiante numérique dont nous remplissons nos murs, alors nos descendants passeront des générations à extraire cet amiante des murs. Il y aura beaucoup de travail pour réparer ce que nous avons cassé à cause de la psychose la plus dangereuse de toutes en matière d’IA : la croyance hallucinatoire selon laquelle « écrire du code » revient à « faire de l’ingénierie logicielle ». Au rythme où nous allons, nous aurons le plein emploi pour des générations de désamianteurs.
