Framework Fatigue – Pourquoi les devs continue d’utiliser une stack qu’ils critiquent ?

Les devs passent leur temps à râler sur leur Stack. Et pourtant, dès qu’ils ont l’occasion de changer, on entend plus personne se plaindre. Le phénomène s’appelle la “framework fatigue”. 

Il est courant dans l’écosystème Web, mais peut toucher tous les secteurs d’activité.
Pensez à ce développeur qui ne peut plus sortir de sa config Emacs. Où ce sysadmin qui ne jure que par une distribution exotique même pas GNU. 

On pourrait croire qu’ils vivent pour se plaindre ou font des choix avec cet objectif en tête. Mais je vous rassure, ce n’est pas du tout le cas. La framework fatigue est en réalité bien plus simple une fois qu’on a mis le projecteur dessus.

Les développeurs râlent toujours sur leur framework.

Je pense qu’Astro c’est vraiment le bon exemple. Dans le dernier State of JS, il a un score de désirabilité remarquable. Et pourtant ! Essayez de convaincre un dev React ou Next de faire un petit projet avec Astro. C’est plus dur que de faire manger des épinards à un enfant de 2 ans en pleine phase du non.

Alors que Next est un des frameworks les plus détestés de nos jours. N’importe quelle conférence peut voir ses couloirs transformés en réunions de développeurs Next anonymes qui se plaignent des évolutions du framework.

Et pourtant c’est pas Next qui m’a fait comprendre le sujet. J’ai pu observer Camille Roux sur Linkedin qui fait du contenu autour du Vibecoding en ce moment, et il a fait quelques petits projets avec Rails. Et ça m’étonne, parce que oui, y’a 10-15 ans, on faisait tous du Rails dans le monde Startup. Il y avait cette catchphrase : “Tu l’as fait avec PHP ? Tu aurais pu le faire en 2h au lieu de 2 jours avec Rails”.

Et quand je lui demande pourquoi il fait faire du Rails à son Claude Code : “C’est la techno que je maitrise le mieux”.

C’est à dire que même s’il a pas besoin de l’écrire, ça reste une techno où il va pouvoir faire la relecture rapidement. Et c’est vrai que sur mes projets web, même en node, j’avais fini par remplacer le templating Pug par Handlebars. Le premier est à la mode, mais je n’y comprends rien. Le second me servait déjà il y a dix ans et m’est facile à relire.

La framework fatigue est un phénomène largement documenté.

La framework fatigue est surtout documentée sous forme de JavaScript Fatigue. Et c’est probablement l’épiphénomène.

On en parle aujourd’hui comme d’un fait accompli. Mais, c’est aussi documenté.

L’étude State Of JS est très populaire, recompilée chaque année et mesure sur différents indicateurs la désirabilité des frameworks. C’est vraiment très précis. Et ils font un gros travail de représentation visuelle également !

Et surtout, chaque année, il montre la dissonance : les frameworks, les outils les plus aimés ne sont pas les plus utilisés.

Et dans l’absolu, l’étude Stackoverflow fait la chose à l’échelle de l’ensemble des développeurs, sur tous leurs outils. Est-ce que les développeurs aiment Go ? Pourtant ils font du Java.
Chaque année on voit des classements de popularité des bases de données, des langages de programmation ou des IDEs.

Au-delà de la tech, le phénomène framework fatigue trouve des explications organisationnelles, et psychologiques.

Pourquoi les devs ne changent pas de stack ?

Dans la gestion des SI, migrer de Java à DotNet serait compliqué. Il faudrait réécrire tout le code, probablement changer toute l’infrastructure. Former les développeurs ou en recruter des nouveaux.

Changer d’outil a un coût. Changer de stack a un coût énorme.

Sauf que maintenant, notre ami Claude peut réécrire toute une code base dans la semaine, pourvu qu’on paye ses tokens. Cloudflare a dépensé plus d’un millier de dollars pour faire un clone de Next.js.

Et pour autant, ce n’est pas gratuit. Admettons que vous ayez une codebase en PHP et que vous décidiez de la remplacer par une codebase en Rust parce que… vous avez vos raisons que j’ignore.
Et bien le cerveau des développeurs ne va pas se recâbler pour lire le Rust aussi vite que Claude Opus peut inférer la base de code.

Si vous n’êtes pas codeur ou codeuse, imaginez que c’est comme lire du néerlandais alors que vous connaissez l’allemand. Chaque ligne de code demande un effort cognitif. On a le cerveau qui chauffe, les oreilles qui deviennent rouges.

C’est une dette cognitive. La DSI n’a pas acheté que le code. Elle a acheté la connaissance des développeurs pour le maintenir, leur compréhension du métier pour faire évoluer l’applicatif. Sinon il suffirait d’externaliser le projet à l’autre bout du monde.

Le biais de coût irrécupérable est un pilier de la framework fatigue.

Imaginez que vous avez une vieille voiture. C’est la votre depuis 10 ans. À force vous connaissez tous ses défauts et vous avez même appris à changer certaines pièces d’avance.
Cette voiture coûte de l’argent chaque jour et vous fait perdre du temps. À chaque fois qu’elle cale, à chaque fois qu’elle tombe en panne.

Vous pourriez la remplacer par une voiture moderne en location, elle ne vous couterai pas plus chère et la maintenance serait comprise dans le prix. Mais vous ne pouvez pas parce que vous avez déjà dépensé votre argent dans l’entretien de la vieille voiture.

C’est un coût irrécupérable. Un “sunk cost” en anglais. Chaque jour où vous avez travaillé avec Next, investi du temps pour vous intéresser au framework est irrécupérable.

Et pourtant c’est à chaque fois une journée que vous auriez pu investir dans un framework qui vous rendrait heureux.

Et puis pragmatiquement, aujourd’hui votre sécurité de l’emploi c’est d’avoir 4-5 ans d’expérience sur Next et React. Si vous changez de stack du jour au lendemain, il est probable que cet argument de vente devienne caduque.

Pourtant votre connaissance du build d’une application web, de typescript, du navigateur reste utile que vous utilisiez Next ou Astro ?
Avec 5 ans d’expérience sur Next, vous serez plus efficace sur Astro qu’un développeur sans expérience ?

Innovation ou stabilité : c’est comme le sucre, il faut doser.

Toute la semaine, vous vous dites que si vous aviez fait les choix d’architecture, vous n’en seriez pas là.

Et pourtant, sur ce projet auquel vous allez consacrer quelques heures ce weekend, vous allez reprendre le même outil que la veille au bureau. Pourquoi ? Parce que c’est efficace. En 2 heures, vous aurez fini. Commencer avec un autre outil, c’est se lancer dans l’inconnu.

Les développeurs ne sont pas irrationnels ni fous. Ils ont besoin de développer. Le langage, le framework, ce sont des outils pour cette fin. Peu importe que ce site web soit fait avec PHP, Ruby ou Node, tant qu’il tourne, tant que les utilisateurs l’utilisent.
Vous avez fait une librairie super pointue, sophistiquée, performante, mais personne ne l’utilise ? Est-ce que ça valait le coût ?

On ne change pas de stack comme on arrête la cigarette. On tente les choses une à la fois. Au début, on fait des POCs. Pour cela, on prévoit du temps pour expérimenter. Réciproquement, on prévoit aussi du temps pour faire marche arrière quand ça ne fonctionne pas.

Alors oui, l’important, c’est de faire des logiciels qui servent à quelque-chose. Mais c’est aussi important de ne pas être en permanence à flux tendu, à 2 heures près par feature. Prévoyez du temps pour expérimenter, pour prendre des risques. C’est de la dette technique gérée, mesurée. À l’inverse, rester toujours sur les mêmes outils, c’est risquer une migration “big bang” dans quelques années.

Je me risquerais même à une chose : vous devez avoir une codebase hétérogène. Je préfère une maison Frankenstein, avec au moins un truc bien fait, où l’on peut jeter et remplacer chaque brique facilement, plutôt qu’une maison uniforme où, dès qu’on touche un bout, tout s’effondre.

Les devs râlent quand qu’ils ont pris la bonne stack pour le problème, pas celle qui leur aurait fait plaisir.

En réalité, et c’est ma conclusion, si les devs râlent sur leur stack, c’est qu’ils ont fait les bons choix.
Ils ont pris le Kangoo pour aller faire les courses en ville. Et oui, il est moins bien que la Lamborghini. Il est pas beau, il est pas agréable. Mais, il fait le job et il a un grand coffre pour tout ramener.

Alors autant leur amener une tasse de thé et leur apprendre à pratiquer la méditation pour faire passer ce moment en toute sérénité.