Cruft, pas patine

Stewart Brand, il y a trente-deux ans, a publié un livre intitulé How Buildings Learn. L’idée de fond est simple et inconfortable : un bâtiment bien conçu n’est pas celui qui reste identique à lui-même, mais celui qui sait être modifié, habité, rapiécé, réinterprété dans le temps. Brand photographie les mêmes bâtiments à des décennies d’intervalle et montre les altérations qui en racontent l’histoire. Un escalier ajouté sur un côté, une cloison abattue pour réunir deux bureaux, un toit refait après l’incendie, une façade peinte trois fois puis laissée s’écailler. La qualité architecturale, soutient Brand, ne se mesure pas au moment de l’inauguration mais à la façon dont l’objet tient à l’usage humain stratifié. Le mot qu’il utilise pour cette condition est learning : les bâtiments apprennent, au sens où leur tissu physique accumule de l’information à travers les années, et à un certain point cette quantité d’information accumulée devient elle-même partie de la valeur de l’objet.

Le logiciel n’apprend pas, en ce sens. Le logiciel accumule des commentaires qui s’excusent.

L’archéologie du vieux code

Quiconque a travaillé sur une codebase de plus de dix ans reconnaît un certain type de commentaire. // HACK: à retirer quand on migrera à l'API v2. // TODO: comprendre pourquoi ça marche. // NE PAS TOUCHER: a cassé la prod trois fois. Signatures de personnes qui ne travaillent plus là, destinées à des lecteurs futurs qui ne viendront jamais vraiment les résoudre. Sont-ils patine ? Plutôt tissu cicatriciel. La différence n’est pas seulement lexicale. Une chaise d’Alvar Aalto de 1932, si elle a été vraiment utilisée, a aujourd’hui une valeur esthétique que la chaise sortie d’usine en 32 n’avait pas. Le bois s’est foncé là où les mains se posent. La finition mate a perdu son éclat de manière non uniforme, elle a appris le corps qui s’y est assis. Il y a peut-être une réparation au point de jonction entre pied et assise, une vis changée, un renfort fait avec goût par un propriétaire intermédiaire. Tout cela ne la rend pas pire. Cela la rend plus belle, plus précieuse, plus elle-même. Un restaurateur sérieux refuse d’ôter la patine, parce que la patine est devenue partie constitutive de l’objet. La restauration est l’art de distinguer le dommage de l’histoire.

Un logiciel PHP de 1998, s’il a été vraiment utilisé, n’a aujourd’hui aucune valeur esthétique ajoutée. Il a des workarounds stratifiés pour des navigateurs qui n’existent plus. Des contrôles de validation ajoutés trois fois à trois niveaux différents parce qu’à chaque cycle de maintenance personne ne se fiait aux précédents. Des fonctions de quatre cents lignes qui gèrent des cas particuliers introduits par des clients qui ne sont plus clients depuis dix ans. Personne ne propose de préserver cette condition comme partie de la valeur du produit. On parle de dette technique, terme révélateur : dette, pas histoire. Quelque chose à éteindre, pas à honorer. Le vocabulaire avec lequel le secteur décrit son rapport au temps révèle qu’aucun concept disponible ne permet de qualifier de beau un système ancien. Au mieux on dira « solide », « battle-tested », « proven ». Vertus de résistance, pas vertus d’accumulation.

L’archéologie du vieux code est une discipline informelle que tout senior pratique sans l’avoir étudiée. Couches de compatibilité avec des navigateurs éteints : if (window.ActiveXObject) pour les vieilles versions d’IE, hacks CSS qui exploitent des bugs spécifiques à Firefox d’avant les grandes refontes, conditions qui vérifient la présence de window.attachEvent pour distinguer IE du reste à l’époque où les concurrents étaient nombreux et tous différents. Feature flags allumés pour des rollouts graduels jamais terminés, où la moitié du code est derrière un if (feature_active('new_checkout_flow')) et l’autre dans le else, et la feature est en prod à 100 % depuis sept ans mais personne n’ose retirer la branche morte. Migrations de schéma jamais terminées : deux colonnes coexistent, ancienne et nouvelle, les deux écrites « par sécurité », lues sélectivement. Fonctions nommées processOrderLegacy, processOrderLegacyV2, processOrderFinal, processOrderActuallyFinal — progression de tentatives jamais achevées. Rien de tout cela n’est patine. C’est un registre sédimentaire de promesses non tenues, d’intentions que la vie d’entreprise a dépassées avant qu’elles ne se concrétisent. Si un restaurateur trouvait dans une commode du XVIIIᵉ vingt couches de vernis superposées, chacune posée sans retirer la précédente, il ne dirait pas que l’objet a gagné en valeur — il dirait qu’il a été mal traité. Le vieux code est traité ainsi par les pros eux-mêmes, qui l’appellent legacy avec un ton qui mélange la neutralité technique au mépris voilé. Le mot vient du latin legare, léguer, mais a pris en pratique technique un sens presque opposé : quelque chose qu’on subit et dont on aimerait se débarrasser. L’héritage comme fardeau, pas comme don.

Pourquoi le logiciel ne vieillit pas

La question est pourquoi. Pourquoi les objets matériels gagnent quelque chose à travers le temps, alors que les objets numériques ne semblent pouvoir que perdre. Réponse facile : différence ontologique — le code est sémantique pure, sans substrat matériel sur lequel les marques d’usage puissent se déposer. Le bois respire, absorbe l’humidité, s’oxyde, s’use aux points de friction. Le byte ne fait rien de cela. Un fichier binaire est aujourd’hui bit-pour-bit identique à sa naissance, sauf corruption accidentelle, et ces corruptions n’ont aucune valeur sémantique. La réponse facile a le défaut de toutes les réponses faciles : fermer le débat exactement là où il devrait s’ouvrir.

Allons plus loin. Une chaise vieillit bien non parce qu’elle est en bois mais parce que son entour reste substantiellement stable. La gravité ne change pas. La physiologie humaine non plus. La fonction « soutenir un corps assis » non plus. Les modifications qu’elle subit sont internes à son tissu, en dialogue avec un environnement qui bouge bien plus lentement. La chaise et le monde autour vieillissent ensemble, à la même vitesse, et le résultat est une co-évolution domestique. Le logiciel existe dans un environnement qui bouge bien plus vite que lui. Le navigateur change de version toutes les quatre semaines. Le langage casse la rétrocompatibilité tous les deux ans. Les bibliothèques ont un cycle de vie plus court qu’un mandat parlementaire. L’OS sous lequel il tourne cesse d’exister sous la forme où il avait été compilé. Le logiciel ne vieillit pas en interne comme le bois. Il se détache progressivement de son environnement, comme un vaisseau qui n’a plus de propergol et voit la station s’éloigner. Ce qu’on appelle « software aging » n’est pas vieillissement au sens de la chaise. C’est une dérive environnementale. C’est la mesure de la distance croissante entre un artefact figé et un contexte mouvant.

Cette différence est ontologiquement pertinente. Un bâtiment et son contexte urbain vieillissent ensemble en dialogue continu, et cette co-appartenance est la condition même qu’on puisse parler de « vieillissement » au sens propre. Le logiciel n’a pas de co-appartenance : il a la compatibilité, relation bien plus pauvre. Compatibilité ne signifie que ceci : deux choses qui ne se parlent plus peuvent continuer à faire semblant de se parler pour un cycle de release de plus. Quand Brand écrit que les bâtiments apprennent, il décrit un processus où le bâtiment et ses habitants se modifient mutuellement. Quand un sysadmin ajoute un compatibility shim pour faire tourner un vieux binaire sur un nouveau kernel, il met un coin entre deux mondes qui ne se parlent plus, et il achète du temps. Le shim est l’opposé de l’apprentissage : c’est l’aveu que l’apprentissage est impossible et qu’on ne peut que simuler la communication.

Ruskin, et la vérité de l’usage

Il y a un passage de Ruskin, dans Les Sept Lampes de l’architecture, qui soutient qu’un bâtiment neuf est par nature faux, et ne devient vrai qu’à travers la fréquentation des années. Ruskin est victorien, emphatique, souvent agaçant, mais cette phrase est une des choses les plus précises jamais dites sur l’objet construit. La vérité d’un bâtiment n’est pas dans le projet mais dans l’histoire de son usage. Si l’on applique le même critère au logiciel, il faut conclure que le logiciel ne devient jamais vrai. Il reste dans un état permanent de nouveauté, même quand sa date de compilation a vingt-cinq ans, parce que l’accumulation d’histoire qui devrait le rendre réel au sens ruskinien n’est pas possible dans son médium. La seule chose qu’il accumule est l’incompatibilité croissante avec son entour, et ce n’est pas histoire : c’est érosion.

L’objection Unix

Il faut aborder l’objection forte. Mais Unix a plus d’un demi-siècle, et non seulement il fonctionne encore, mais il est devenu plus élégant avec le temps. POSIX, TCP/IP, SQL, le système de fichiers hiérarchique, le pipe. Idées qui ont entre quarante ans et un demi-siècle. Encore au cœur de l’infrastructure numérique de la planète. Elles ne se comportent pas comme le PHP de 1998. Elles se comportent, si l’on veut, comme la chaise d’Aalto. Quelque chose dans le raisonnement précédent ne tient pas.

L’objection est sérieuse et mérite réponse sérieuse. La réponse facile : Unix est une exception, un outlier, un cas chanceux qui n’invalide pas la règle. Réponse pauvre. La réponse intéressante : Unix ne contredit pas le raisonnement, il en montre le mécanisme exact, et clarifie une distinction restée implicite. Distinction entre logiciel-comme-code et logiciel-comme-spécification.

Spécification, pas code

Ce qu’on appelle « Unix » aujourd’hui n’est pas, littéralement, le logiciel que Thompson et Ritchie ont écrit aux Bell Labs entre 1969 et 1971. Ce code est mort depuis des décennies. La branche commerciale AT&T a été vendue, démantelée, réabsorbée. BSD a été forké de nombreuses fois, et chaque fork à son tour réécrit. Linux, qui est aujourd’hui la forme dominante d’Unix dans l’infrastructure mondiale, ne partage pas une seule ligne de code avec l’Unix originel : c’est une réimplémentation indépendante, lancée par Linus Torvalds en 1991, qui expose les mêmes interfaces système (appels, structure du système de fichiers, conventions) mais a été écrite à partir de zéro. macOS dérive de NeXTSTEP, qui repose sur le micro-noyau Mach et sur des composants BSD, et là aussi le code a été réécrit et refondu tant de fois que la continuité matérielle avec le point de départ est purement rituelle. Ce qui a survécu n’est pas le corps d’Unix, mais sa forme. Son interface. Sa grammaire. Le fait qu’il y ait des appels système qui s’appellent open, read, write, close, et qu’ils fonctionnent à peu près comme en 1973, ne signifie pas que le code qui les implémente a bien vieilli. Cela signifie que la spécification qui les définit est devenue autre chose que le code : elle est devenue culture, convention, langue partagée, norme de fait puis norme de droit via POSIX.

Idem pour TCP/IP. Le protocole a survécu, l’implémentation non — pas dans sa forme originelle. Toute pile TCP/IP moderne, de Linux à Windows à iOS jusqu’à l’ESP32 d’une lampe connectée, a été réécrite ou réalignée plusieurs fois au fil des décennies. Le 4.4BSD networking code, longtemps base de référence du noyau réseau, a été progressivement absorbé, ramifié, réimplémenté au point que les codes modernes maintiennent une parenté plus historique que matérielle. Ce qui persiste, immuable, est la RFC : un document texte qui décrit, en anglais technique, comment deux machines devraient se parler. La RFC n’est pas du logiciel. Elle est plus proche d’un traité diplomatique. C’est pourquoi elle vieillit bien : elle appartient à la même classe d’objets qu’un traité, une constitution, une grammaire. Une convention partagée dont la force ne tient pas à son implémentation mais au nombre d’acteurs qui la reconnaissent comme contraignante.

SQL est le cas le plus instructif. La syntaxe SELECT ... FROM ... WHERE a été définie au milieu des années 70 par Donald Chamberlin et Raymond Boyce chez IBM. Tout le monde l’utilise aujourd’hui. Mais aucune base relationnelle en prod ne tourne sur le code original de System R. Postgres est une réimplémentation. MySQL aussi. SQLite a été écrit à partir de zéro dans les années 2000 et est aujourd’hui probablement la base la plus répandue au monde. Le code qui implémente SQL est mort et renaît tant de fois qu’il n’a plus de sens de parler de continuité matérielle. Ce qui demeure : le modèle relationnel — objet mathématique — et une certaine syntaxe — objet culturel. Les deux se sont détachés du code qui les avait initialement incarnés, et c’est précisément pour cela qu’ils ont pu traverser le temps.

TeX, SQLite et les exceptions qui confirment

Quelques cas, rarissimes, où le code lui-même semble avoir réussi quelque chose qui ressemble vraiment à la patine, et qui éclairent par contraste la condition générale. TeX, le système de composition typographique de Knuth depuis 1978. Knuth a décidé à un certain moment que TeX était fini, au sens littéral : aucune nouvelle feature, seulement des corrections de bugs, le numéro de version convergeant asymptotiquement vers π à chaque release, l’intention explicite que la dernière version, à la mort de Knuth, prenne la valeur exacte de π et que le logiciel cesse de changer pour toujours. Knuth offre une petite récompense monétaire qui double chaque année à quiconque trouve un bug dans TeX, et personne ne la réclame plus depuis longtemps. Pas parce qu’il n’y en a pas, mais parce que le logiciel a été si massivement utilisé que les bugs résiduels vivent dans des coins jamais visités. TeX fonctionne aujourd’hui comme à la fin des années 80, compile les mêmes sources, produit la même sortie typographique. Son code, écrit en WEB (literate programming inventé par Knuth, combinant Pascal pour la logique et TeX pour la documentation), a été publié en 1986 sous le titre TeX: The Program, comme volume B de Computers and Typesetting, traité comme une œuvre littéraire. Lu, commenté, étudié. Une des rares fois où le code a dépassé le seuil de la pure implémentation pour devenir lui-même quelque chose qui ressemble à une spécification, mais sous forme concrète de programme, pas sous forme abstraite de RFC. Knuth a obtenu ce résultat en imposant à son œuvre une condition extrême : refuser toute évolution. TeX ne vieillit pas parce qu’il a choisi de ne pas vivre, en un sens. Il a accepté la momification comme prix de la permanence.

SQLite est l’autre cas intéressant, plus récent et moins mystique. Ses développeurs ont déclaré publiquement, dans la doc, l’intention de maintenir la lib jusqu’en 2050, avec rétrocompatibilité totale de l’API C et du format on-disk. Engagement non décoratif mais contrainte concrète parce que SQLite est intégré dans des systèmes avioniques (Airbus A350 entre autres), des dispositifs médicaux, des appareils militaires — tous objets aux cycles de vie de plus de quarante ans. Pour soutenir cet horizon, SQLite a construit un appareil de tests qui, selon les chiffres déclarés, atteint environ 92 millions de lignes de tests contre 150 000 lignes de la lib elle-même — un ratio de presque 600 pour 1. Chaque branchement conditionnel est couvert par tests MC/DC, le standard utilisé en avionique pour les certifications DO-178B. Le code lui-même est écrit avec une attention explicite au fait qu’il sera lu et maintenu par des personnes pas encore nées. SQLite a pris la durée comme problème de design dès le début, traitant la stabilité de son interface comme question éthique plus que technique. Résultat : un logiciel qui existe depuis plus de vingt-cinq ans, tourne sur des milliards de dispositifs, et que personne n’a jamais ressenti le besoin de réécrire. Cas où le code lui-même, et non la spec, semble avoir bien vieilli. Mais en regardant de près, on comprend que ce résultat n’a été obtenu qu’au prix d’une acceptation radicale de contraintes que le reste du secteur ne serait pas prêt à accepter. SQLite ne change presque jamais, au prix de renoncer à des features qui rendraient le code plus moderne. SQLite n’a pas de dépendances externes, presque une protestation contre la façon dont le reste du monde fait du software aujourd’hui. SQLite a une culture interne disciplinaire qui frôle le monastique. Autrement dit, SQLite vieillit bien parce qu’il s’est fabriqué une niche écologique dans laquelle l’environnement autour du code a été artificiellement stabilisé. Il a recréé, dans un petit périmètre, les conditions qui permettent à la chaise d’Aalto de devenir plus belle avec les années : un environnement qui bouge lentement, un utilisateur attentif, une culture qui reconnaît la valeur de la durée. Pas un hasard que ces exemples soient, statistiquement, des anomalies. Ce sont les exceptions qui révèlent exactement quelles sont les conditions nécessaires au vieillissement du logiciel — et confirment que ces conditions, dans le corps principal du secteur, n’existent pas.

Le corps meurt, la spécification ressuscite

Sous cet angle, Unix ne vieillit pas bien. Unix est continuellement ressuscité. Le corps meurt et est refait à zéro à partir d’une spécification entre-temps devenue assez sacrée pour mériter la réécriture intégrale du corps tous les vingt ou trente ans. C’est la structure d’une religion plus que d’un objet matériel. La chaise d’Aalto, pour rester sur la métaphore, n’a jamais été refaite à zéro : la chaise de 1932 est physiquement là, avec ses cabosses. Si l’on appliquait au bois la logique d’Unix, on dirait que le concept de « chaise Paimio modèle 41 » a survécu parce qu’Artek, depuis sa fondation en 1935, en a continué la production pendant plus de quatre-vingt-dix ans, et que les chaises de 2026 sont descendantes de celles de 1932 mais ne sont pas les mêmes chaises. Vrai, mais déplacé : ce qui nous intéresse de la chaise de 1932 c’est précisément sa durée matérielle, pas la persistance de son modèle. Dans le logiciel, c’est l’inverse. Le code originel ne nous intéresse pas, et personne ne le conserve comme relique. C’est la persistance du modèle qui nous intéresse, et cette persistance exige la destruction et la réécriture périodiques du code.

L’objection Unix, donc, ne dément pas le raisonnement, elle le redéfinit. Ce qui vieillit bien dans le numérique n’est pas du code. Ce sont des spécifications qui ont eu la chance et le capital culturel de s’élever au-dessus de leur substrat d’implémentation et de devenir autre chose. Normes. Interfaces stables. Lingua franca. La majorité du code n’atteint jamais ce niveau et ne peut l’atteindre. Le 99 % du logiciel qui tourne dans le monde aujourd’hui ne deviendra pas POSIX. Le CRM sur mesure d’une boîte de quatre cents personnes ne deviendra pas SQL. Le site e-commerce d’une chaîne de magasins ne deviendra pas TCP/IP. Pas parce qu’il est mal écrit, mais parce qu’il n’est pas ce type d’objet. Il est, structurellement, implémentation. Et l’implémentation, dans le numérique, ne peut pas vieillir bien — elle n’a aucun des prérequis : pas de substrat matériel qui enregistre l’usage, pas d’environnement stable où demeurer, pas le poids culturel qui permet la réincarnation périodique.

Réécrire n’est pas un péché

Cette distinction éclaire aussi un débat interne au secteur, mal posé depuis toujours. Joel Spolsky, en 2000, écrivit un article devenu fameux, Things You Should Never Do, Part I, soutenant que réécrire à zéro un logiciel fonctionnel est la pire erreur stratégique d’une boîte de software. L’argument était bon et précis : Netscape avait perdu le marché parce qu’elle s’était mise à réécrire le navigateur depuis zéro, laissant trois ans de fenêtre à Internet Explorer. Le problème de Spolsky : il généralise un cas particulier sans reconnaître que la majorité du logiciel doit être réécrit, tôt ou tard, parce qu’il ne peut être maintenu indéfiniment dans la forme conçue. Unix a été réécrit plusieurs fois. Linux lui-même, au niveau de sous-systèmes, est continuellement réécrit : le scheduler a été remplacé, le networking stack refait, le filesystem repensé. Ce que Spolsky appelait « ne jamais réécrire » est en réalité « ne pas perdre la continuité de la spécification durant la réécriture », chose très différente et bien plus difficile. La réécriture échoue quand elle perd contact avec ce que le code devait faire pour ses utilisateurs réels. Elle réussit quand elle conserve la spec et jette l’implémentation, comme le corps d’un catholique est enterré tandis que l’âme migre.

Une dignité interdite

Si cette lecture est juste, alors la tristesse sous-jacente d’une bonne partie du travail technique quotidien a une explication structurelle, pas psychologique. Nous n’écrivons pas mal. Nous écrivons des objets qui ne peuvent pas vieillir, parce que nous n’appartenons pas à la classe restreinte des artefacts qui peuvent s’élever à la spécification culturelle. Le 99 % de ce que nous écrivons est destiné à mourir sans laisser de traces, non par défaut de fabrication mais par propriété du médium. Un maçon du XIIIᵉ savait que si son mur était bien fait, il serait là au XVIᵉ, et probablement au-delà. Un plombier du XXᵉ savait que ses tuyaux, avec un peu d’entretien, serviraient trois générations. Une développeuse de 2026 sait que le code qu’elle écrit aujourd’hui sera, avec bonne probabilité, démantelé d’ici cinq à sept ans. Pas parce qu’elle écrit moins bien que les tuyaux. Parce que le tuyau et le mur appartiennent à un régime où le vieillissement est possible, et le code non.

Cela change la nature éthique du métier d’une façon qu’on n’a pas encore métabolisée. Construire quelque chose de durable a été pendant des millénaires une des plus hautes dignités du travail humain. La cathédrale, le pont, le livre imprimé, le violon. Objets faits dans la conscience de durer au-delà de la vie de qui les construit. Le développement logiciel est un des rares métiers à haute qualification où cette dignité est structurellement interdite. Pas parce que personne ne travaille bien, mais parce que le médium n’admet pas ce type de durée. La dette technique évoquée au début, vue de cet angle, n’est pas un défaut gérable par meilleures pratiques, plus de discipline, tests plus rigoureux, revues plus attentives. C’est la forme spécifique que prend le détérioration inévitable d’un artefact qui n’a pas d’autre façon de se détériorer. C’est la manière dont le logiciel vieillit mal parce qu’il ne sait pas vieillir autrement.

La lampe de la mémoire

Lecture plus large, qui sort du strictement technique. Ruskin, encore, identifiait sept vertus de l’architecture, qu’il appelait lampes. Sacrifice, vérité, puissance, beauté, vie, mémoire, obéissance. La lampe de la mémoire était, pour lui, la vertu des bâtiments qui se laissent traverser par le temps sans lui résister, qui conservent les traces de qui les a habités, qui deviennent à leur manière des archives biographiques du passage humain. Une civilisation qui ne sait construire des objets capables de mémoire, disait Ruskin, est une civilisation qui a renoncé à une de ses fonctions fondamentales : se transmettre à travers ses choses.

Le numérique est, sous cet angle, l’opposé exact de l’architecture ruskinienne. Une culture matérielle, si l’on peut encore l’appeler ainsi, où la mémoire ne s’accumule pas dans les choses mais les quitte. Le logiciel d’il y a cinq ans est déjà une antiquité. Le site web d’il y a dix ans n’est plus accessible, son domaine est expiré, ses liens cassés, ses images pointent vers des serveurs démantelés. Les archives numériques n’existent que par des efforts héroïques et marginaux : Internet Archive est un point unique de défaillance pour la mémoire de trois décennies de culture en ligne, et personne n’a vraiment compris comment le remplacer. Nos photos sont sur des serveurs que nous ne possédons pas, dans des formats peut-être illisibles dans vingt ans, protégés par des CGU modifiables unilatéralement. Notre correspondance est dans des boîtes qui disparaîtront quand la boîte qui les héberge changera de modèle. La continuité matérielle du patrimoine humain, garantie pour des millénaires, fût-ce imparfaitement, par la durée physique des objets, est devenue précaire d’une façon qu’aucune civilisation précédente n’avait connue.

Cette précarité n’est pas un effet collatéral mais une propriété structurelle du médium. Et le logiciel, cœur de cette nouvelle condition, hérite et amplifie la précarité. Il ne vieillit pas parce qu’il ne sait pas accumuler de mémoire dans ses fibres. Il n’a pas de fibres. Sa seule forme de continuité est la réécriture, qui est l’opposé exact de la mémoire : la production périodique d’un nouvel objet qui feint d’être le même.

Quelqu’un objectera ici que je dramatise, que chaque époque a eu sa précarité, que le papyrus se décomposait, que le parchemin était gratté pour être réutilisé, que le livre imprimé brûle. Vrai, mais la différence quantitative devient qualitative. La durée moyenne d’un livre imprimé bien conservé se mesure en siècles. La durée moyenne d’un fichier numérique se mesure en années, peut-être en décennies dans les cas heureux. Le delta est d’un ou deux ordres de grandeur. Une civilisation où les objets culturels durent cent fois moins est une civilisation structurellement différente, pas seulement quantitativement. Elle a un autre rapport au temps. Produit une autre subjectivité chez qui l’habite. Une développeuse sait, d’une façon qu’un typographe du XVIᵉ ne savait pas, que son travail ne lui survivra pas.

L’objection de l’éphémère

Il y a une lecture moins tragique, qui mérite d’être traversée. L’objection : la permanence n’est pas nécessairement une vertu, et le logiciel pourrait représenter une forme de production culturelle délibérément éphémère, au sens où une performance théâtrale ou un concert de jazz sont éphémères, et leur éphémérité n’est pas un défaut mais une caractéristique constitutive. Une fonction lambda qui tourne pendant 37 millisecondes puis disparaît n’est pas un objet raté parce qu’il ne dure pas : c’est un objet pleinement réalisé parce qu’il a fait exactement ce qu’il devait faire au moment juste. La métaphore du monument, héritée de l’architecture, pourrait être inadaptée au médium, et insister sur le fait que le logiciel « ne vieillit pas bien » pourrait revenir à se plaindre qu’un orage ne vieillit pas bien : confondre une catégorie qui ne s’applique pas.

L’objection est intéressante mais se brise quand on la prend au sérieux. Le problème n’est pas le code qui tourne 37 ms. Cela, c’est vraiment un événement, pas un objet. Le problème : la quasi-totalité du logiciel dont nous dépendons quotidiennement n’est pas un événement en ce sens — c’est de l’infrastructure. Le système avec lequel notre banque gère les comptes n’est pas une performance jazz. Le software médical qui contrôle le respirateur en réa n’est pas un orage. La base anagraphique de la mairie n’est pas une fonction éphémère. Ce sont des objets qui prétendent être infrastructure, que nous traitons comme infrastructure, que les institutions inscrivent dans leurs processus comme s’ils l’étaient — mais qui ont les propriétés de durée et de mémoire d’un nuage. Cette discordance entre la fonction sociale du logiciel et ses propriétés matérielles de durée est le point où la question cesse d’être philosophique et devient civile. Une société qui confie ses fonctions vitales à des objets qui ne savent pas vieillir transfère silencieusement le coût de la maintenance de sa propre continuité à un substrat technique qui ne sait pas le soutenir.

Infrastructure précaire, droit qui court derrière

Le Cyber Resilience Act européen, adopté comme Règlement (UE) 2024/2847, en pleine application à partir de décembre 2027, la nouvelle PLD (UE) 2024/2853, les obligations NIS2, sont, sous cet angle, des tentatives maladroites mais indicatives de forcer le logiciel à se comporter comme infrastructure sérieuse. Ils obligent les producteurs à définir une période de support reflétant le cycle de vie attendu (au moins cinq ans dans la plupart des cas), à maintenir des SBOM à jour, à répondre des vulnérabilités introduites dans le produit même après vente. C’est en un sens la tentative législative d’imposer à l’objet logiciel les propriétés de durée qu’il n’a pas par nature. Que ces règles existent et soient perçues par le secteur comme un coût supplémentaire plutôt que comme une reconnaissance de responsabilité civile dit quelque chose sur le fait que qui produit du logiciel a intériorisé l’éphémère comme privilège. Le maçon sait qu’il doit répondre de son mur pendant de nombreuses années. La développeuse est habituée à répondre de son code jusqu’au terme de la garantie contractuelle, en général douze ou vingt-quatre mois. Les deux figures professionnelles ont des horizons temporels de responsabilité qui diffèrent d’un ordre de grandeur — différence invisible dans le langage avec lequel on les décrit.

Une éthique de la durée

Revenons à la question initiale, pourquoi le logiciel ne sait pas vieillir, on peut donner une réponse moins lapidaire. Il ne sait pas vieillir parce qu’il est fait d’un matériau sans grain, dans un environnement qui bouge plus vite que lui, dans une culture productive qui a renoncé à considérer la durée comme dimension de la valeur. Chacun de ces trois facteurs est cause suffisante du résultat ; sommés, ils le rendent quasi inévitable. Le premier est ontologique et probablement irrésoluble : le code ne deviendra jamais bois. Le second est systémique et pourrait être atténué si la culture technique apprenait à traiter la stabilité comme qualité plutôt que signe d’arriération. Le troisième est purement culturel, et c’est le seul sur lequel on peut agir vraiment.

Agir comment ? Probablement dans des directions que le secteur considère aujourd’hui régressives. Ralentir les cycles de release. Préférer la rétrocompatibilité à l’élégance. Écrire moins de code et plus de spec. Traiter les interfaces stables comme des monuments — c’est-à-dire des objets dont la valeur tient à leur résistance au changement. Accepter que la majorité du code ne devienne pas Unix, et précisément pour cela, l’écrire avec une certaine conscience de son destin de transitoire — sans l’ambition fausse de la durée et sans le désespoir nihiliste de son absence. Un métier qui sait qu’il ne construit pas de cathédrales mais qui refuse de bâtir des baraques. Une dignité intermédiaire, qu’on n’a pas encore de bon mot pour décrire, et qui est peut-être une des choses que cette génération de techniciens devrait essayer de formuler.

S’il y a une consolation dans le fait que le logiciel ne vieillit pas bien, c’est que cette caractéristique nous oblige à mettre au point, par contraste, ce que vieillir bien signifie en général. Elle nous force à reconnaître que la patine de la chaise d’Aalto n’est pas un fait automatique du bois, mais le résultat d’une longue relation entre un objet bien fait, un environnement stable, une utilisatrice attentive et une culture qui sait reconnaître la valeur de cette triangulation. Quand l’un de ces termes manque, la patine ne se forme pas. Le bois laissé sous la pluie ne prend pas patine, il pourrit. Le bois enfermé dans un dépôt ne prend pas patine, il sèche. La patine est une œuvre collective qui exige temps, soin, contexte. Le logiciel, en l’état, n’a aucun des trois, et l’idée même qu’il pourrait les avoir sonne comme une rêverie nostalgique.

Ce n’est pas une rêverie. C’est une question de design. Que voudrait dire écrire du code en sachant qu’il doit durer comme un mur ? On ne le sait pas encore vraiment, parce qu’on ne s’y est presque jamais essayés sérieusement, et quand on l’a fait, ce fut presque toujours dans des domaines marginaux par rapport au mainstream : avionique, contrôle industriel, systèmes bancaires legacy, où la durée est imposée de l’extérieur comme contrainte normative plus que comme choix culturel. Le software civil — qui construit la vie publique et privée de la majorité des gens — a été bâti sur l’hypothèse implicite que la durée n’est pas son problème. Cette hypothèse devient insoutenable au moment même où la société délègue au logiciel des fonctions de plus en plus vitales. Parmi les responsabilités de cette génération de techniciens, commencer à formuler une éthique de la durée pour le métier est probablement l’une des plus sérieuses, et l’une des moins reportables.

Reste, à la fin, la question de fond. Le logiciel ne vieillit pas bien. Cette phrase, au début, ressemblait à une plainte technique. Arrivés ici, on comprend que c’est autre chose. C’est une description exacte du type d’artefacts que nous avons décidé, collectivement, de mettre au centre de notre vie commune, et une demande implicite de tirer les conséquences de cette décision. Les objets que nous mettons au centre d’une civilisation devraient, dans la mesure du possible, savoir l’accompagner dans le temps. S’ils ne le savent pas, il faut soit les changer, soit changer la place qu’ils occupent. Jusqu’ici nous n’avons fait ni l’un ni l’autre. Nous avons laissé qu’ils occupent le centre en se comportant comme s’ils étaient à la périphérie, et nous avons appelé cette condition « progrès ». Il vaut la peine de commencer à l’appeler par un nom plus précis.

L'auteur

Andrea MargiovanniMétier

J'écris du logiciel depuis assez longtemps pour le considérer comme un métier, pas comme un pipeline. Ce qui m'intéresse, c'est la différence entre un choix technique et un défaut hérité sans en mesurer le coût.

Voir le parcours →