L'étrange manège de l'informatique

L'informatique est une discipline sérieuse, rigoureuse, scientifique, qui passe son temps à réinventer ce qu'elle a oublié avoir inventé vingt ans plus tôt. Et le pire, c'est que ça marche à chaque fois. On remballe le vieux truc dans un nouveau nom, on fait un logo, on lève 50 millions, et on se félicite de l'innovation. Si vous n'avez pas le tournis, c'est que vous ne faites pas assez attention.

Le manège

Il y a une loi non écrite en informatique, que personne n'enseigne en cours mais que tout le monde finit par découvrir à ses dépens : tout ce qui est nouveau est ancien, et tout ce qui est ancien reviendra. C'est un manège. Un grand manège circulaire, avec des chevaux en bois peints de couleurs différentes à chaque tour, mais qui tournent tous autour du même axe, à la même vitesse, depuis cinquante ans.

Le problème, c'est que les gens qui montent sur le manège ne voient pas qu'il tourne. Ils voient le cheval sur lequel ils sont assis, ils le trouvent formidable, et ils écrivent un article Medium pour expliquer que ce cheval est disruptif. Et pendant ce temps, le vieux monsieur assis sur le banc en face regarde tourner le même manège depuis 1975 et se demande si quelqu'un va finir par s'en apercevoir. (personne ne s'en aperçoit)

J'enseigne l'informatique. Je lis du code, j'en écris, j'en fais écrire, et je regarde tourner le manège depuis suffisamment longtemps pour avoir commencé à reconnaître les chevaux. Ce billet est un catalogue non exhaustif des tours que j'ai vus passer, avec la lassitude bienveillante d'un spectateur qui aime le spectacle malgré tout.

Centralisé, décentralisé, recentralisé

J'en ai déjà parlé dans le billet sur la fédération, mais ça mérite qu'on y revienne sous l'angle du cycle, parce que c'est le plus pur, le plus beau, le plus désespérant.

Années 60-70 : le mainframe. Un gros ordinateur central, des terminaux stupides branchés dessus. Toute la puissance est au centre. Tout le contrôle est au centre. Si le mainframe tombe, tout le monde rentre chez soi. IBM règne.

Années 80-90 : le PC. On décentralise. Chaque personne a son propre ordinateur, sa propre puissance de calcul, ses propres fichiers. La liberté ! L'individu s'émancipe du mainframe ! On imprime des trucs sur son imprimante à aiguilles et on est souverain. C'est magnifique et ça fait beaucoup de bruit.

Années 2010-20 : le cloud. On recentralise. Votre « propre ordinateur » n'est plus qu'un navigateur web branché sur les serveurs de trois entreprises californiennes. Toute la puissance est au centre. Tout le contrôle est au centre. Si AWS tombe, la moitié d'Internet rentre chez soi. Le terminal VT100 s'appelle désormais Chromebook. Le temps partagé s'appelle SaaS. La facture mensuelle à IBM s'appelle « la facture mensuelle à Amazon ». Et le bureau du service informatique qui tenait le mainframe s'appelle « la console AWS », sauf qu'il est à Seattle et que vous n'avez pas le numéro.

On est revenus au mainframe. On l'a juste renommé. Et on a payé une fortune pour le trajet.

Monopole, pas de monopole, remonopole

Le cycle des monopoles est mon deuxième préféré, parce qu'il est d'une régularité de métronome. On croirait un gag récurrent dans une sitcom, sauf que la sitcom dure depuis soixante ans et que personne ne zappe.

IBM a eu le monopole du matériel informatique dans les années 60-70. Tellement de monopole que le gouvernement américain a lancé un procès antitrust qui a duré treize ans. Et puis le PC est arrivé, IBM a perdu sa couronne, et tout le monde a dit : « Vous voyez ? Le marché s'autorégule ! »

Microsoft a pris le relais dans les années 90. Monopole du système d'exploitation, monopole du navigateur, monopole de la suite bureautique. Tellement de monopole que le gouvernement américain a lancé un procès antitrust. Et puis le web et le mobile sont arrivés, Microsoft a vacillé, et tout le monde a dit : « Vous voyez ? Le marché s'autorégule ! »

Google a pris le relais dans les années 2010. Monopole de la recherche, de la publicité en ligne, du navigateur (encore), du système mobile. Tellement de monopole que le gouvernement américain a lancé un procès antitrust. Et on en est là, en 2026, à attendre la suite en mangeant du pop-corn.

Le schéma est limpide. Un géant s'installe, écrase tout, un nouveau paradigme le déstabilise, un autre géant prend sa place, écrase tout, et on recommence. Le monopole ne disparaît jamais. Il change de logo. Et à chaque cycle, des gens très sérieux expliquent dans des conférences TED que cette fois la technologie va démocratiser les choses, que cette fois le petit va pouvoir rivaliser avec le gros, que cette fois c'est différent. C'est toujours touchant. C'est jamais vrai.

Le vieux langage, le nouveau langage, le vieux langage finalement

Celui-là, c'est celui qui me fait le plus sourire, parce que je le vis au quotidien.

COBOL. Langage des années 60. Verbeux, rigide, ennuyeux comme un formulaire des impôts en triplicate. Personne ne veut l'apprendre, tout le monde s'en moque, les étudiants ricanent quand on en parle. Et pendant ce temps, le système bancaire mondial tourne dessus. Les assurances tournent dessus. Des pans entiers de l'administration de plusieurs pays tournent dessus. Et quand il y a un bug critique dans un système de paiement, on cherche désespérément un développeur COBOL de 70 ans capable de le corriger, on le paie une fortune la journée, et on ne ricane plus du tout. (bizarrement)

C. Langage des années 70. « Dangereux. » « Bas niveau. » « Trop proche de la machine. » On a inventé C++ pour l'améliorer. Puis Java pour le remplacer. Puis Go pour le simplifier. Puis Rust pour le sécuriser. Chaque décennie apporte un nouveau langage censé être « le C, mais en mieux ». Et en 2026, le noyau Linux est en C, votre système de fichiers est en C, votre navigateur est en partie en C, le firmware de votre routeur est en C, et les satellites en orbite tournent en C. Le langage qu'on enterre depuis quarante ans est toujours le fondement de tout ce qui vous entoure. Il a survécu à tous ses successeurs désignés. C'est l'équivalent informatique du cafard : indestructible, pas très joli, et absolument partout.

SQL. Années 70, lui aussi. Relationnel, déclaratif, rigoureux. Et puis dans les années 2010, la mode a décidé que SQL, c'était rigide, c'était « pas scalable », c'était le truc de papa. On a inventé NoSQL. MongoDB, Cassandra, CouchDB. « Les bases relationnelles, c'est fini ! » ont proclamé les évangélistes sur leurs blogs hébergés sur des bases relationnelles. Deux ans plus tard, les mêmes évangélistes passaient leurs nuits à réimplémenter des jointures et des transactions par-dessus leur base NoSQL, parce qu'il s'avère que quand on a des données structurées, une base de données structurée, c'est quand même pas mal. MongoDB a fini par ajouter des transactions ACID. Autrement dit : ils ont réinventé SQL. En moins bien, en plus lent, et en se félicitant de l'innovation. (standing ovation)

JavaScript. Créé en dix jours en 1995 par Brendan Eich chez Netscape, pour ajouter un peu d'interactivité aux pages web. Dix jours. Pour un langage. Ça se sent, et ça s'est senti pendant vingt ans. C'était un langage de script bricolé à la va-vite, limité, bancal, que personne ne prenait au sérieux. Et puis, par une série d'événements qu'aucun historien sobre n'arrivera jamais à expliquer, on s'est mis à écrire des serveurs web en JavaScript (Node.js), des applications de bureau en JavaScript (Electron), des applications mobiles en JavaScript (React Native), des backends en JavaScript, des outils de build en JavaScript, et probablement des grille-pains en JavaScript. Le langage le plus méprisé de l'industrie est devenu le langage le plus utilisé au monde. Et maintenant on invente TypeScript pour corriger ses défauts, c'est-à-dire qu'on ajoute un système de types statiques par-dessus un langage qui a été explicitement conçu pour ne pas en avoir. C'est comme mettre une cravate à un chat : techniquement c'est possible, esthétiquement c'est discutable, et le chat n'a rien demandé.

Et pendant tout ce temps, quelque part dans un bunker, un développeur Lisp murmure : « On avait tout ça en 1958. » Il a raison. Personne ne l'écoute. Le manège tourne.

Les architectures qui reviennent

Le cycle des architectures est le plus rapide. Le manège tourne tellement vite qu'on peut voir les mêmes idées passer trois fois dans une seule carrière.

Monolithe, microservices, monolithe. Pendant des décennies, on a écrit des applications monolithiques. Un seul programme, un seul déploiement, un seul serveur. Ça marchait. C'était simple. C'était compréhensible. Et puis quelqu'un chez Netflix a dit : « On devrait découper ça en microservices. » Et le monde entier a suivi, parce que si Netflix le fait, ça doit être bien. Votre application de gestion de notes de frais avec trois utilisateurs ? Microservices. Votre blog ? Microservices. Votre TODO list ? Douze conteneurs Docker, un API gateway, un service mesh, un outil de tracing distribué, et un ingénieur DevOps à plein temps pour que ça tienne debout. Pour une TODO list. (Netflix a 200 millions d'utilisateurs. Vous, vous en avez trois. Dont votre mère.)

Et puis en 2023, Amazon lui-même a publié un article expliquant qu'ils avaient migré un de leurs services de microservices vers un monolithe et réduit les coûts de 90 %. Amazon. L'entreprise qui vous vend l'infrastructure pour faire des microservices. Qui vous facture chaque appel réseau entre vos 47 micro-conteneurs. Cette entreprise-là a dit : « En fait, un monolithe, c'est mieux. » Le manège a fait un tour complet si vite qu'on a tous eu la nausée.

Client lourd, client léger, client lourd, client léger. Les applications de bureau ont été remplacées par des applications web. Et puis les applications web sont devenues tellement complexes qu'elles sont redevenues des applications de bureau déguisées en navigateur. Electron, c'est littéralement Chrome empaqueté avec votre application. Slack pèse 300 Mo. Pour un chat. Le client IRC de 1999 faisait la même chose en 2 Mo, mais il n'avait pas de GIF animés, alors évidemment c'est incomparable. (ironie au premier degré) Et puis on s'est dit que c'était trop lourd, et on a inventé les Progressive Web Apps, qui sont des applications web qui essaient de ressembler à des applications de bureau. La boucle est bouclée. Le serpent se mord la queue. Le chat en cravate n'est pas impressionné.

REST, GraphQL, REST. REST était trop simple, pas assez flexible. On a inventé GraphQL pour « résoudre les limites de REST ». Et puis on a découvert que GraphQL avait ses propres limites (performances, sécurité, complexité, cache), et les articles « Why we moved back to REST » ont fleuri comme des pâquerettes au printemps. Pendant ce temps, un développeur SOAP des années 2000 se racle la gorge poliment pour signaler que les contrats stricts, la validation de schéma et la gestion d'erreurs standardisée, ça existait déjà. Mais bon, SOAP c'est pas sexy, et le XML c'est verbeux, alors on préfère ne pas en parler. (on préfère réinventer)

Le framework du mois

Il faut qu'on parle de l'écosystème JavaScript, parce que c'est un cas d'école. C'est le seul écosystème au monde qui reproduit le cycle entier de l'informatique en accéléré, comme un hamster sous amphétamines dans une roue qui tourne à la vitesse de la lumière.

J'ai vu, de mes propres yeux, en moins de dix ans : Angular est le futur. Non, React est le futur, Angular c'est has-been. Non, Vue.js est le futur, React c'est compliqué. Non, Svelte est le futur, Vue c'est pareil que React en fait. Non, SolidJS est le futur, Svelte compile trop. Non, HTMX est le futur, on n'a peut-être jamais eu besoin d'un framework côté client. Non, en fait, un site statique avec du HTML et trois lignes de CSS, c'était pas si mal depuis le début.

On est revenus au point de départ. En dix ans. Avec huit frameworks, quinze outils de build, trois mille articles de blog, et un dossier node_modules qui pèse plus lourd que le programme Apollo. (je n'exagère qu'à peine)

Et quelque part, un développeur PHP regarde tout ça depuis son serveur qui n'a pas bougé depuis 2009, avec son WordPress moisi et sa base MySQL, et il sourit. Parce que son site marche, que ses clients sont contents, et que personne ne lui a jamais demandé de migrer vers un monorepo Turborepo avec des Server Components hydratés en streaming. Il ne sait pas ce que ça veut dire. Personne ne sait vraiment ce que ça veut dire. Mais ça fait vachement bien sur un CV.

L'IA, ou le plus long des cycles

J'ai déjà écrit un billet entier sur l'IA, donc je ne vais pas tout redire. Mais impossible de parler de cycles informatiques sans mentionner le plus ancien, le plus régulier, et le plus richement financé d'entre tous.

Années 60 : l'IA va tout résoudre. Financement massif. Années 70 : ça ne marche pas. Hiver. Années 80 : les systèmes experts vont tout résoudre. Financement massif. Années 90 : ça ne marche pas non plus. Re-hiver. Années 2010 : le deep learning va tout résoudre. Financement démentiel. Années 2020 : les LLMs vont tout résoudre. Financement cosmique.

Le cycle est toujours le même : enthousiasme, surinvestissement, promesses absurdes, déception, hiver, et puis on recommence avec un nouveau mot-clé. La seule variable qui change, c'est le montant des levées de fonds, qui augmente exponentiellement à chaque tour, comme si l'argent pouvait compenser le fait qu'on promet toujours la même chose depuis soixante ans.

Est-ce que les LLMs sont utiles ? Oui. Ce billet a d'ailleurs été rédigé avec l'aide d'un. Est-ce qu'ils vont « tout résoudre » ? Laissez-moi consulter l'historique des soixante dernières années de prédictions en IA et je vous reviens.

Pourquoi ça tourne

La vraie question n'est pas « est-ce que ça tourne ». Ça, c'est évident. La vraie question, c'est pourquoi on ne s'en rend pas compte.

La mémoire courte, d'abord. L'industrie tech a la mémoire d'un poisson rouge sous caféine. Les développeurs changent de poste tous les deux-trois ans, les startups naissent et meurent en dix-huit mois, les frameworks sont obsolètes avant d'être stables. Personne ne reste assez longtemps au même endroit pour voir le cycle se compléter. Alors on redécouvre les mêmes leçons, on les emballe dans un vocabulaire neuf (« serverless » au lieu d'hébergement mutualisé, « container » au lieu de chroot, « edge computing » au lieu de « mettre un serveur plus près du client »), et on les vend comme des innovations. Et ça marche, parce que les acheteurs non plus ne sont pas restés assez longtemps pour se souvenir du tour précédent.

L'argent, ensuite. Chaque tour de manège est financé par des gens qui ont besoin de vendre quelque chose de nouveau. On ne lève pas 50 millions de dollars en disant « on va faire la même chose qu'avant, mais correctement ». On les lève en disant « on va disrumpter le marché avec une approche radicalement nouvelle ». Même si l'approche en question est un mainframe avec un meilleur logo. Le venture capital ne finance pas la continuité. Il finance la nouveauté. Et quand la nouveauté n'existe pas, on la fabrique en rebaptisant l'ancien. (c'est un business model en soi)

Et l'ego, enfin. Chaque génération de développeurs veut croire qu'elle est la première à résoudre les vrais problèmes. Que les anciens n'avaient pas compris. Que cette fois, avec ces outils, on va faire les choses correctement. C'est humain, c'est même touchant, et je le dis sans condescendance parce que je suis passé par là moi aussi. J'ai cru, à un moment, que Docker allait tout changer. Que Node.js était la réponse. Que les microservices étaient l'avenir. Et puis le manège a fait un tour, et j'ai vu le même cheval repasser avec une peinture fraîche. Ça calme.

Et donc ?

Et donc rien. Le manège va continuer à tourner. Dans dix ans, quelqu'un inventera un paradigme révolutionnaire qui sera, en fait, du temps partagé sur mainframe avec un meilleur marketing. Les langages fonctionnels feront leur quatrième comeback. Une startup lèvera 200 millions pour réinventer le RSS. Et un vieux développeur quelque part secouera la tête en murmurant : « Je l'avais bien dit. »

La seule chose qu'on peut faire, c'est en être conscient. Savoir que le cheval sur lequel on est monté tourne en rond. Apprécier le paysage qui défile, reconnaître les trucs qu'on a déjà vus au tour précédent, et surtout ne pas écrire d'article de blog pour expliquer que ce tour-ci est différent.

Ce que je viens de faire, évidemment.