Quand tu choisis un framework JavaScript pour un nouveau projet, tu pèses un paquet de critères : performances, taille du bundle, courbe d’apprentissage, taille de la communauté, stabilité à long terme. Mais depuis qu’on code avec une IA sur l’épaule en permanence, il y a un paramètre que personne ne formalisait vraiment jusqu’ici : est-ce que l’IA connaît bien ce framework ?
C’est la question que pose Nolan Lawson dans un article publié fin octobre 2026, qui a fait beaucoup de bruit sur Hacker News. Sa thèse est simple mais dérangeante : le choix du framework a désormais un coût IA mesurable — en qualité de code généré, en consommation de tokens, et en productivité quotidienne. Et cet angle devrait changer la façon dont on raisonne ses choix de stack.
TL;DR — Les LLMs génèrent du meilleur code pour les frameworks populaires comme React que pour les plus récents comme Svelte 5 ou Solid. Ce biais crée un effet boule de neige indépendant de la qualité technique. Un paramètre concret à intégrer dans tes choix de stack si tu codes avec une IA.
L’IA sait coder ce qu’elle a beaucoup vu
Les LLMs sont entraînés sur du code existant — GitHub, npm, Stack Overflow, des millions de dépôts publics. React a été publié en 2013. Ça fait plus de 13 ans d’historique, des millions de projets en production, des dizaines de milliers de questions/réponses indexées partout. L’IA a ingurgité une masse phénoménale de code React — suffisamment pour en comprendre les patterns idiomatiques, les anti-patterns courants, et les subtilités d’évolution entre versions.
Résultat : quand tu demandes à Claude ou Copilot d’écrire un composant React avec hooks et gestion d’état complexe, le code généré est généralement solide. Il respecte les conventions, il est maintenable, il fonctionne. Quand tu fais la même demande en Solid.js ou en Svelte 5 — dont les runes sont sorties il y a moins de deux ans — tu obtiens quelque chose qui ressemble à du Svelte ou du Solid, mais avec des bugs subtils, des patterns obsolètes, ou des imports qui n’existent tout simplement pas.
Ce n’est pas que ces frameworks sont mal conçus — Solid.js est élégant, Svelte 5 a repensé la réactivité brillamment avec ses runes. C’est que l’IA n’a pas eu le temps de les apprendre suffisamment dans « la vraie vie ». Le corpus d’entraînement pour Svelte 5 est incomparablement plus mince que pour React 18, et ça se ressent immédiatement dans la qualité des suggestions.
La verbosité a un coût, et ce coût est littéral
Il y a un deuxième angle dans l’article de Lawson : le coût en tokens. Quand tu utilises un LLM via API pour coder (Cursor, Claude Code, Copilot Chat…), tu paies à la consommation. Et certains frameworks génèrent structurellement du code beaucoup plus verbeux que d’autres. Angular, avec ses décorateurs, ses modules, ses services injectés, ses interfaces TypeScript… un composant « simple » peut facilement faire 100 lignes là où le même composant en Svelte en ferait 20.
Multiplie ça par des centaines d’échanges IA par jour dans une équipe, et l’écart commence à peser. Lawson estime que la différence de verbosité entre frameworks peut créer un écart de 2x à 4x sur la consommation de tokens pour un projet équivalent. Ce n’est pas de la précision chirurgicale — il le reconnaît lui-même — mais l’ordre de grandeur suffit à mériter d’être intégré dans le calcul.
Il y a aussi un coût indirect : le temps passé à corriger le code mal généré. Si l’IA produit du Solid.js approximatif, tu passes dix minutes à déboguer ce qu’elle t’a pondu. Sur React, le même composant sort propre du premier coup. Cette friction invisible s’accumule rapidement sur la durée d’un projet.
DÉCOUVREZ NOS RÉALISATIONS
AFC Detailing
Logiciel web de planning et reservation pour un centre de preparation automobile a Saint-Berthevin (53). Application PWA sur mesure.
Voir le projet →Le « coût IA » d’un framework ne figure dans aucune comparaison technique officielle. Pourtant, si ton équipe code 6h/jour avec un assistant IA, c’est potentiellement 1 à 2h de productivité par développeur qui sont en jeu — selon le framework choisi.
L’effet boule de neige qui profite à React
Ce mécanisme crée un phénomène que les sociologues appellent l’effet Matthieu : les avantages vont à ceux qui en ont déjà. React est populaire → il y a beaucoup de code React dans les données d’entraînement → l’IA génère du meilleur code React → les devs choisissent React parce que l’IA est plus efficace avec → encore plus de code React est produit → les modèles futurs connaissent encore mieux React. Boucle fermée.
Ce qui est troublant, c’est que cet avantage n’a rien à voir avec les qualités techniques de React en 2026. On peut débattre à l’infini de si React Compiler résout vraiment les problèmes de performance, ou si les Server Components sont la bonne abstraction. Mais l’IA ne juge pas — elle reproduit ce qu’elle a vu. Et elle a surtout vu React.
Le choix d’un framework n’est plus seulement technique — c’est aussi un choix sur la qualité du code que ton IA va produire pour toi pendant les deux prochaines années.
Comment intégrer ce critère dans tes choix de stack
Pour un projet qui s’appuie fortement sur l’assistance IA, ignorer ce paramètre serait une erreur. Si tu lances une application sur mesure avec une deadline serrée et un budget contraint, la productivité de ton assistant IA fait partie de l’équation au même titre que les performances du framework ou la disponibilité des développeurs compétents sur le marché.
Ça ne signifie pas « choisis toujours React ». Ça signifie teste avant de décider. Avant de lancer un projet, ouvre Cursor ou Claude Code, génère une dizaine de composants typiques dans le framework envisagé, et évalue toi-même : est-ce que le code est idiomatique ? Est-ce qu’il compile du premier coup ? Est-ce que l’IA comprend les patterns spécifiques ou est-ce qu’elle colle des patterns React avec la syntaxe du framework ? 30 minutes de test peuvent t’éviter des semaines de friction.
Si tu construis des sites web sur des stacks plus classiques — WordPress, Next.js, Astro — la question se pose aussi. Astro a bien progressé dans les datasets d’entraînement depuis 2024, mais c’est inégal selon les modèles. Tester reste la seule façon de savoir où en est ton outil IA avec ta stack.
Ce que les mainteneurs de frameworks peuvent faire
Nolan Lawson soulève une piste concrète : les équipes core des frameworks ont un rôle actif à jouer pour améliorer leur « score IA ». Comment ? En publiant des datasets de code canonique sous licence permissive, explicitement conçus pour être ingérés par des LLMs lors des phases d’entraînement. En documentant les patterns avec des exemples complets et variés. En créant des benchmarks structurés qui permettent aux modèles de vraiment comprendre les idiomes du framework.
WESTCODE BY LEB
Studio web en Mayenne — On crée des outils numériques qui transforment
Rich Harris (créateur de Svelte) et l’équipe Solid ont tous deux évoqué cette direction en 2026. L’idée est simple : si tu veux que l’IA parle couramment ton framework, tu ne peux pas attendre que la communauté produise organiquement assez de code. Il faut enseigner activement, avec des datasets ciblés et des exemples canoniques pensés pour l’entraînement.
Mon avis sur tout ça : cet article pointe quelque chose d’important que la communauté frontend avait largement ignoré. Le coût IA d’un framework est réel, mesurable, et mérite d’être intégré dans les décisions de stack en 2026. Pas comme critère absolu, mais comme variable supplémentaire dans une équation déjà complexe.
Ce qui me dérange davantage, c’est l’aspect systémique. On risque de voir l’écosystème JavaScript se cristalliser autour de React non pas parce que c’est la meilleure solution technique, mais parce que l’IA est plus à l’aise avec. C’est une sélection naturelle biaisée par les données historiques, pas par la qualité intrinsèque — et ça, c’est un problème réel pour l’innovation dans l’écosystème.
Mon pari : d’ici 2028, les frameworks qui auront pris soin de « s’enseigner » activement aux LLMs auront un avantage compétitif significatif sur ceux qui comptent sur la sérendipité des données d’entraînement. Les mainteneurs qui l’auront compris tôt joueront dans une autre catégorie. Et React, qui n’a pas ce problème, devra compter sur autre chose que l’inertie pour rester pertinent.
