Le coût caché de l'IA dans les frameworks JavaScript

L'agent a passé onze minutes à lire un guide de migration avant d'écrire la moindre ligne de code. Pas votre agent, mais celui qu'un collègue a lancé sur un projet SvelteKit la semaine dernière, avec le même prompt que celui que vous aviez donné à votre application React une heure plus tôt. Le vôtre a fini en huit minutes environ et quatre millions de tokens. Le sien a mis dix-sept minutes et près de dix millions, dont une grande partie a servi à ce que le modèle réapprenne patiemment une version de framework qu'il n'avait jamais vue pendant son entraînement. Cet écart a désormais un nom : le coût IA des frameworks JavaScript. Et grâce à une démarche plutôt rare dans notre secteur, quelqu'un qui mesure réellement au lieu d'affirmer, on dispose enfin de chiffres concrets.

Nolan Lawson, qui passe des années à remplacer le folklore du frontend par de vrais benchmarks, vient de faire ce que personne n'avait pris la peine de faire. Il a défini une application Pokémon petite mais non triviale (recherche, filtres, pages de détail, données issues de la PokéAPI) et a demandé à un agent de codeur de la construire de douze façons différentes : Astro, Next.js, Nuxt, SvelteKit, React Router, SolidStart, Qwik, Angular, TanStack Start, Hono avec htmx, Gracile avec Lit, et un simple Vite sans aucun framework d'interface. Chaque framework a eu cinq exécutions indépendantes avec le même prompt, chaque build a été vérifié par une suite de conformité pour que l'agent ne puisse pas tricher, et les résultats ont été évalués sur le coût, le temps, les tokens et les métriques Lighthouse. L'expérience n'est pas parfaite, et Lawson le reconnaît lui-même. Mais c'est la première tentative honnête que je vois pour chiffrer une décision que la plupart des équipes prennent à l'instinct.

Ce que le benchmark mesurait vraiment

Le protocole était volontairement neutre. L'agent recevait la spécification, devait utiliser la dernière version du framework donné, et choisissait librement son architecture (SSR ou CSR, selon son goût). Lorsqu'un framework fournit un serveur MCP officiel, un skill d'agent ou un plugin, il était mis à disposition, pour qu'aucun framework ne puisse se plaindre d'être sous-représenté dans les données d'entraînement. Les tests de conformité s'exécutaient sur l'arbre d'accessibilité plutôt que sur le DOM brut, ce qui comptait, car l'un des concurrents rend son interface via le shadow DOM. Chaque framework a eu cinq exécutions et les résultats sont présentés sous forme de médianes. Sauf pour Angular, qui n'a produit deux fois aucune application testable : certains de ses chiffres proviennent donc de trois exécutions seulement.

• Le coût de build variait d'une médiane d'environ 2,67 $ à 4,97 $ par application, soit un écart d'environ 2x entre les frameworks les moins chers et les plus chers.
• La consommation de tokens racontait la même histoire, en plus fort : environ 4 millions de tokens pour les stacks les moins chères, près de 10 millions pour les plus coûteuses.
• Le temps réel suivait de près le coût, de huit minutes environ au plus rapide à dix-sept minutes au plus lent.
• SvelteKit, Gracile+Lit et Angular ont été systématiquement les builds les plus chers. Astro et le duo Hono+htmx ont été systématiquement bon marché.
• Surprise : le build Vite sans framework a fait moins bien que plusieurs frameworks réels. Un peu de structure vaut mieux que pas de structure, même pour une machine.

Deux dollars par build, ça semble dérisoire. Et ça l'est, pour un seul build. Mais le développement agentique est itératif par nature : personne n'accepte le premier résultat. Multipliez cet écart par des dizaines de sessions d'agent par développeur et par semaine, à l'échelle d'une équipe, sur une année, et un multiplicateur de tokens de 2x sur votre stack devient un poste budgétaire bien réel. Plus important encore, les tokens sont le reflet de quelque chose qui me préoccupe davantage que l'argent : la quantité d'essais et d'erreurs dont le modèle a besoin pour produire du code correct dans votre framework. Un nombre élevé de tokens signifie généralement que l'agent est perdu, qu'il relit la documentation et tente à nouveau. C'est un signal de qualité déguisé en coût.

Pourquoi certains frameworks rendent les agents coûteux

Après des années à entraîner et évaluer des modèles, je trouve ces résultats moins mystérieux qu'ils n'en ont l'air. Trois mécanismes expliquent presque tout l'écart, et aucun ne tient à la question de savoir quel framework est « meilleur » au sens traditionnel.

La densité des données d'entraînement fait le destin

Le plus grand avantage de React à l'ère agentique n'est pas son modèle de programmation, c'est qu'une décennie de tutoriels, de dépôts GitHub et de réponses Stack Overflow a compressé ses idiomes dans les poids de chaque modèle de pointe. Un agent qui écrit du React se contente en grande partie de se souvenir. Un agent qui écrit du Gracile doit surtout découvrir : dans les exécutions du benchmark, les agents qui ne connaissaient pas le framework ont fini par cloner son dépôt ou lire son code compilé dans node_modules. Ce sont des tokens brûlés en rattrapage avant même qu'existe le moindre code utilisateur. Cette même dynamique transforme la façon dont les développeurs trouvent l'information en général. J'ai écrit sur ce qui arrive au corpus du savoir des développeurs à mesure que Stack Overflow s'éteint, et l'angle des frameworks en est un cas particulier et frappant : les outils peu populaires ne manquent pas seulement de communauté, ils manquent de présence dans le modèle lui-même.

Le renouvellement des API, une taxe récurrente en tokens

La mauvaise performance de SvelteKit a une cause précise, presque cocasse : l'agent a lu le guide de migration vers SvelteKit v3 à chaque exécution, parce que cette version était trop récente pour figurer dans les données d'entraînement du modèle. Chaque changement cassant qu'un framework livre rend obsolètes des schémas que le modèle a mémorisés et l'oblige à redériver l'API correcte à partir de la documentation au moment de l'inférence. Ce coût est payé en tokens, à chaque session, par chaque utilisateur. Les frameworks traitent les changements de version majeure comme un événement marketing. Pour les utilisateurs d'agents, c'est une surtaxe récurrente. Un framework sobre, qui n'a pas cassé son API depuis trois ans, est, selon cette mesure, une fonctionnalité premium.

La verbosité s'accumule à chaque boucle

Le coût d'Angular semblait suivre le volume brut de code : plus de lignes générées signifie plus de tokens en sortie, plus de tokens à relire à chaque modification suivante, et plus de surface où l'agent peut trébucher. Cela se généralise : toute stack avec des sorties d'outils verbeuses, des logs de build bruyants ou des commandes de test lentes oblige l'agent à parcourir plus de texte à chaque itération, et chaque lint ou vérification de types échoué déclenche un nouvel aller-retour coûteux. Les praticiens observent partout le même schéma : c'est le coût de l'itération, et non celui de la génération, qui domine les dépenses liées aux agents. Un framework doté d'une chaîne d'outils rapide, discrète et stricte coûte moins cher à exploiter qu'un framework permissif, parce que la rigueur attrape les erreurs de l'agent en un cycle au lieu de cinq.

Chaque changement cassant livré par votre framework est désormais une taxe que quelqu'un paie en tokens, et, contrairement à un humain qui lit un changelog, le modèle la paie à chaque session.

Le problème du dé dans les benchmarks d'agents

C'est ici que mes vieux réflexes d'évaluation en ML entrent en jeu, car le détail le plus important de toute l'étude se trouve dans les barres d'erreur. La sortie d'un LLM est une distribution, pas un point. Le coût médian de build de React Router était environ un dollar de plus que celui de Hono+htmx, mais la moins chère de ses exécutions est passée sous la plus coûteuse de Hono. Les plages se chevauchent largement. Les exécutions de SvelteKit ont oscillé entre environ 3,20 $ et 6,80 $. Parfois, l'agent tire simplement un mauvais numéro, part dans une digression et consomme quelques millions de tokens pour des raisons qui n'ont rien à voir avec le framework.

Les données d'usage des outils confirment le même point. Les frameworks livraient des serveurs MCP et des fichiers de skills, et les agents les utilisaient... parfois. Le serveur MCP de Nuxt n'a jamais été sollicité sur cinq exécutions. Les fichiers de skills de TanStack Start n'ont été découverts que dans deux exécutions sur cinq. Le skill de React Router a été utilisé à chaque fois. Même prompt, même harnais, comportements très différents : c'est la nature stochastique de l'outil. Ce qui signifie que chaque fil Twitter affirmant « le framework X est tellement meilleur pour les agents, j'ai réécrit toute mon app » après un après-midi de vibe coding ne mesure que du bruit. Une seule exécution est une anecdote. Si vous laissez le coût de l'IA influencer une décision d'architecture (et je pense que vous devriez), exigez des médianes sur des exécutions répétées avant de croire quoi que ce soit, y compris ce benchmark.

Sur la qualité du résultat, tout converge vers le correct

Le résultat le plus surprenant est ce qui n'a pas varié. Les scores Lighthouse de performance, d'accessibilité et de décalage cumulé de mise en page (CLS) étaient presque saturés sur les douze stacks : des 99 et des 100 presque partout. Avec une spécification claire et une suite de conformité, les agents modernes produisent de petites applications compétentes et accessibles dans à peu près n'importe quel framework. Le plancher de qualité a tellement monté que le framework différencie à peine le résultat sur un site orienté contenu.

La seule métrique de qualité présentant un réel écart était le volume de JavaScript livré : zéro Kio pour les builds Astro et Hono+htmx basés sur des îlots, jusqu'à environ 142 Kio pour la sortie la plus lourde en SPA. Le Total Blocking Time est resté négligeable partout, et le LCP était trop bruité pour en tirer grand-chose. Deux réserves honnêtes s'imposent. L'application de test ressemble plus à Wikipédia qu'à Figma, ce qui avantage les architectures multi-pages, et Lighthouse est structurellement défavorable aux SPA. Le résultat du JavaScript vanilla mérite tout de même une pause : l'agent chargé d'utiliser Vite nu, sans framework, a obtenu de moins bons scores que plusieurs frameworks réels, avec le plus fort décalage de mise en page de tous les builds. Les frameworks encodent des conventions, et les agents s'appuient fortement sur elles. Donnez au modèle une ornière bien tracée, il y reste ; donnez-lui un champ vierge, il improvise, pas toujours bien.

Ce que ce benchmark ne peut pas vous dire

Avant que quiconque réécrive son application de production à partir d'une démo Pokémon, soyons honnêtes sur le périmètre. Il s'agit d'une petite application, surtout axée sur le contenu, avec peu d'état transversal, pas de localisation, pas de formulaires complexes, et aucune équipe humaine pour la maintenir pendant cinq ans. C'est une vraie limite, et c'est le piège sur lequel je reviens sans cesse dans ce blog : les benchmarks IA passent systématiquement à côté de l'essentiel du travail réel. Les qualités qui rendent un framework bon pour les agents sur un jouet vierge (familiarité, simplicité, structure statique) ne sont pas celles qui comptent au dix-huitième mois d'un produit complexe.

Il y a aussi un point plus profond, que les sceptiques des frameworks ont bien saisi dans la discussion. Une grande partie de la valeur historique d'un framework n'a jamais tenu à ce qu'il permet de faire, mais à ce qu'il interdit. Java a conquis le développement d'entreprise en partie parce qu'il forçait des milliers de programmeurs à écrire un code qui se ressemble. Les frameworks sont des systèmes de contraintes pour des équipes humaines qui arrivent, partent et se comprennent mal. Un agent n'a pas besoin de garde-fous contre l'ennui ou le développement motivé par le CV ; il a besoin d'une spécification claire et d'une suite de tests. Un praticien a rapporté exactement cette inversion avec htmx : l'agent passait les pages simples sans encombre, mais s'empêtrait dans un formulaire complexe à état, perdant des données et cassant des bascules, des problèmes que React aurait réglés du premier coup, jusqu'à ce que suffisamment de tests existent pour le garder honnête. La contrainte qui compte pour les agents n'est pas le framework. C'est la suite de conformité.

Et oui, le build le moins cher n'est pas la base de code la moins chère. Payer deux dollars de plus par session d'agent pour une stack que votre équipe comprend en profondeur et peut maintenir pendant des années est évidemment le bon choix. Mais remarquez ce que cet argument suppose : des chiffres. Le but de mesurer le coût de l'IA n'est pas de désigner un vainqueur, c'est de remplacer « ce framework est meilleur pour les agents » par une quantité que vous pouvez peser face au vivier de recrutement, à la maturité de l'écosystème et à la taille du bundle. Les impressions ont perdu le débat sur l'expérience développeur ; elles ne devraient pas gagner par défaut le débat agentique.

Comment mesurer le coût IA de votre propre stack

N'extrapolez pas le résultat de qui que ce soit, y compris celui-ci, à votre base de code. Votre dépôt, votre spécification et le modèle que vous choisissez produiront leur propre distribution. La bonne nouvelle, c'est que mesurer le coût IA est vraiment simple, car les agents de code fournissent déjà toutes les données nécessaires. Si vous voulez comprendre comment la boucle, le contexte et les permissions interagissent avant de les instrumenter, notre article sur le fonctionnement réel d'une CLI de code agentique est une bonne base. Ensuite, faites ceci :

1. Choisissez une tranche verticale représentative de votre travail réel : une fonctionnalité qui touche à votre couche de données, à votre gestion d'état et à votre interface, pas une simple page d'accueil.
2. Écrivez d'abord les tests de conformité. Ils servent à la fois de porte de qualité et de dispositif anti-triche ; un agent sans tests déclarera victoire trop tôt.
3. Lancez le même prompt au moins cinq fois par stack ou configuration candidate. Présentez des médianes et des plages, jamais des exécutions isolées.
4. Journalisez le total des tokens (ventilé entre lectures de cache, entrée et sortie), le temps réel, le coût, ainsi que le nombre d'appels d'outils et de boucles de nouvelle tentative.
5. Suivez la part des tokens consacrée aux lectures de documentation : guides de migration, changelogs, exploration de node_modules. C'est votre taxe de déficit de données d'entraînement, mesurée directement.
6. Relancez le benchmark après chaque mise à niveau majeure du framework. Le coût IA évolue au gré des renouvellements d'API et des dates de coupure des modèles.

Le harnais lui-même peut se réduire à un après-midi de scripts. Voici le squelette que j'ai utilisé : les options précises de la CLI dépendront de votre agent, mais la forme reste universelle :

import json
import statistics
import subprocess
FRAMEWORKS = ["astro", "react-router", "sveltekit"]
RUNS = 5
SPEC = open("spec.md").read()
def build_once(framework: str) -> dict:
"""One full agent session: build the app, return usage stats."""
result = subprocess.run(
[
"agent-cli", "run",
"--prompt", SPEC,
"--context", f"Build this with the latest {framework}.",
"--output-format", "json",
],
capture_output=True,
text=True,
check=True,
)
return json.loads(result.stdout)
for framework in FRAMEWORKS:
runs = [build_once(framework) for _ in range(RUNS)]
costs = [r["cost_usd"] for r in runs]
tokens = [r["tokens_total"] for r in runs]
print(
f"{framework}: "
f"median ${statistics.median(costs):.2f} "
f"(range ${min(costs):.2f}-${max(costs):.2f}), "
f"median {statistics.median(tokens) / 1e6:.1f}M tokens"
)

Surveillez le nombre de tentatives d'aussi près que le total de tokens. Selon mon expérience, les tokens par test accepté constituent la métrique la plus honnête : elle regroupe coût, confusion et exactitude en un seul chiffre, et elle pénalise le mode d'échec qui fait vraiment mal, celui où l'agent enchaîne cinq boucles d'erreurs de compilation avant d'aboutir à un résultat qui passe. Un framework où l'agent réussit proprement dès la première ou la deuxième tentative battra à chaque fois un framework nominalement « moins cher » qui exige des corrections constantes.

La conclusion pragmatique

Faut-il donc réécrire votre application Angular en Astro parce que les agents la trouvent moins chère ? Non. Les écarts en dollars sont faibles, la variance est grande, l'application de test est un jouet, et votre migration coûterait plus de tokens d'agents que vous n'en économiseriez en une décennie. Quiconque vous vend une migration de framework « pour les agents » fait le même raisonnement à l'intuition que l'industrie pratique depuis toujours, avec simplement une nouvelle justification greffée dessus.

Mais le coût de l'IA mérite désormais une place à la table des décisions, à côté du vivier de recrutement, de la profondeur de l'écosystème et de la taille du bundle. Pour les projets neufs, les données vont dans une direction cohérente : choisissez des stacks bien représentées dans les données d'entraînement, à renouvellement d'API lent, dotées de chaînes d'outils strictes et discrètes, et s'appuyant sur des conventions que le modèle a vues dix mille fois. La technologie éprouvée a toujours été le choix pragmatique ; les agents ont simplement rendu cet éprouvé mesurable. Figez les versions de vos frameworks, car chaque mise à niveau est désormais aussi une taxe d'inférence, jusqu'à ce que les modèles rattrapent leur retard. Et investissez dans les tests de conformité quel que soit le framework choisi : ce sont le seul actif qui rend chaque agent moins coûteux, qui le garde honnête quand il patauge, et qui reste rentable bien après que le modèle que vous utilisez aujourd'hui sera devenu obsolète. Les frameworks continueront de changer. Ce qui survit, ce sont les tests, et l'habitude de mesurer.