Coût de l’IA par framework JavaScript : comparatif et test
Dans le benchmark de Nolan Lawson, Hono+htmx affiche la médiane de coût API estimé la plus basse, et Angular la plus haute. Comparez 12 frameworks sur le coût, le temps, les tokens et les lignes de code. Distinguez l’utilisation des outils de leur effet réel, puis mesurez vos tâches en conservant les données de cache, les échecs et les tests d’acceptation.
Sommaire
Pour une application centrée sur le contenu, comparez d’abord Hono+htmx et Astro si le coût de l’IA compte. Dans le benchmark de Nolan Lawson, Hono+htmx affiche la médiane de coût API estimé la plus basse : $2.67, contre $4.97 pour Angular. Pour un projet existant, testez une modification représentative avant de changer de framework.
Quel framework a coûté le moins cher dans ce test ?
Utilisez ces résultats pour sélectionner les frameworks à essayer sur une application centrée sur le contenu. Lawson a publié l’expérience le 28 octobre 2026. Les exécutions et mesures publiées utilisent Claude Code 2.1.310 avec claude-opus-5-5 et un niveau d’effort high.
Chaque agent a créé la même application PokéAPI, avec recherche, filtres et pages de détail. Le tableau rassemble les résultats publiés au 2026-11-06. Les versions désignent les paquets testés ; elles ne constituent pas des recommandations d’installation actuelles.
| Framework et version testée | Coût API estimé, USD : médiane (min.–max.) | Minutes | Tokens, millions | Lignes de code source |
|---|---|---|---|---|
| Hono 4.13.14 + htmx 2.0.11 | $2.67 ($2.23–$3.19) | 8.6 | 4.26 | 1,370 |
| Astro 7.4.2 | $2.76 ($2.16–$3.63) | 8.2 | 4.13 | 1,461 |
| Nuxt 4.6.2 | $2.82 ($2.39–$4.25) | 9.0 | 3.85 | 1,415 |
| Vanilla avec Vite 8.3.5 | $2.98 ($2.24–$3.37) | 10.1 | 5.00 | 1,492 |
| Next.js 16.4.3 | $3.14 ($2.58–$4.13) | 10.9 | 4.99 | 1,539 |
| Qwik 1.20.2 / 1.20.3 | $3.27 ($2.35–$3.80) | 10.7 | 5.64 | 1,744 |
| TanStack Start 1.169.4 | $3.54 ($3.11–$3.96) | 10.3 | 7.07 | 1,697 |
| SolidStart 2.1.0 | $3.79 ($2.84–$4.81) | 11.2 | 7.13 | 1,630 |
| React Router 8.5.0 | $3.81 ($2.82–$3.97) | 12.5 | 7.58 | 1,564 |
| SvelteKit 3.1.0 | $4.28 ($3.59–$4.65) | 10.8 | 8.53 | 1,611 |
| Gracile 0.11.0 + Lit 3.3.3 | $4.65 ($3.92–$5.07) | 12.1 | 9.04 | 1,717 |
| Angular 22.2.3 | $4.97 ($3.19–$6.82) | 17.2 | 9.76 | 2,009 |
Chaque métrique a sa propre médiane. Le coût, le temps et les tokens couvrent cinq tentatives par framework. Pour Angular, la taille du code couvre trois applications, car les mesures des deux autres ont échoué derrière le proxy inverse.
Les tokens comprennent les entrées non mises en cache, les écritures et lectures du cache, ainsi que les sorties de toute la session. Le décompte des lignes exclut les lignes vides, JSON, lockfiles, tests, fichiers générés et copies des fichiers de conception fournis. Les commentaires comptent.
Ces montants correspondent aux coûts API indiqués par Claude Code. Lawson utilisait un abonnement ; ils ne représentent donc pas ses paiements réels pour chaque application créée. Ils excluent aussi votre facture d’hébergement et le temps de vérification manuelle.
Avec les médianes arrondies, l’écart pour Angular vaut $4.97 − $2.67 = $2.30. Son coût atteint 4.97 / 2.67 ≈ 1.86 fois celui de Hono+htmx. Il est donc environ 86% plus élevé pour cette tâche.
Next.js et Astro diffèrent de $0.38 par application créée, et leurs plages de coûts observées se recoupent. Hono+htmx et Astro ne diffèrent que de $0.09. Ces écarts justifient un petit essai ; ils ne suffisent pas à établir un classement valable pour tous les projets.
Pourquoi SvelteKit et Angular ont-ils coûté plus cher ?
Des lectures supplémentaires et davantage de code peuvent expliquer une partie du coût, mais l’expérience n’isole pas leurs effets.
Lawson a observé que l’agent SvelteKit lisait le guide de migration v3 à chaque exécution. Il a suggéré que v3 pouvait être plus récente que les données d’entraînement du modèle. Le guide de migration officiel décrit des changements réels, dont le déplacement de la configuration vers Vite. Il ne permet pas d’établir ce que le modèle a appris pendant son entraînement.
Pour Gracile, Lawson rapporte que les agents clonaient le dépôt ou inspectaient des fichiers compilés dans node_modules. Cela représente un travail de recherche supplémentaire. Le benchmark ne mesure pas la part de l’écart de coût due à ces lectures.
Angular a produit une médiane de 2,009 lignes de code source, contre 1,370 pour Hono+htmx. Le second représente environ 68% du premier, ce qui correspond à la comparaison approximative de 70% donnée par Lawson. Des fichiers plus volumineux peuvent accroître les lectures et modifications futures, mais cette expérience ne mesure pas les coûts de maintenance.
Le total de tokens demande aussi de la prudence. Nuxt affiche la médiane la plus basse, à 3.85 millions, sans avoir la médiane de coût la plus basse. L’usage du cache modifie la relation entre le total de tokens et le prix. Conservez les catégories de tokens séparées pour interpréter le coût.
Les serveurs MCP et les skills des frameworks sont-ils utiles ?
Ce benchmark ne permet pas de conclure que les serveurs MCP ou les skills réduisent le coût. L’utilisation des outils varie, sans comparaison de chaque framework avec puis sans ces outils.
Lawson a installé les outils officiels lorsqu’ils existaient. Plusieurs frameworks n’en avaient pas. Ses observations comprennent les résultats suivants :
| Framework | Utilisation observée sur cinq exécutions |
|---|---|
| Hono+htmx | Outil Skill de Hono utilisé dans 5/5 |
| SvelteKit | MCP utilisé dans 5/5 |
| Nuxt | MCP utilisé dans 0/5 |
| Next.js | Fichiers de skills lus dans 1/5 ; AGENTS.md lu dans 2/5 |
| TanStack Start | Fichiers de skills fournis avec le paquet découverts dans 2/5 |
Le fait que l’agent n’utilise pas le MCP de Nuxt ne prouve pas que cet outil soit inefficace. Le coût plus élevé de SvelteKit ne prouve pas non plus que son MCP en soit la cause. Installer un outil, l’appeler et réduire le coût d’une tâche menée à bien sont trois questions distinctes.
Les consignes actuelles de Next.js distinguent la documentation correspondant à la version installée des skills qui coordonnent le travail. Notez la ressource réellement utilisée par l’agent. Une lecture de documentation n’est pas nécessairement un appel MCP.
Pour votre propre test, vérifiez la disponibilité des serveurs avec claude mcp list ou /mcp. Examinez ensuite les appels d’outils réellement effectués. Comparez un même framework sans outils, avec les outils disponibles, puis avec une demande explicite de les utiliser. Le guide de mesure du contexte MCP approfondit ce test.
Quelles sont les limites de cette expérience ?
Utilisez ces résultats pour présélectionner des frameworks destinés à de petites applications centrées sur le contenu. Quatre limites doivent guider leur interprétation :
- Type de tâche : un catalogue peu interactif ne représente pas un éditeur complexe, un tableau de bord ou un jeu. Les agents choisissaient aussi l’architecture de rendu.
- Taille de l’échantillon : cinq tentatives donnent des exemples et des plages utiles, mais les classements serrés restent incertains. Les plages affichées sont les minima et maxima observés, pas des intervalles de confiance.
- Environnement : un seul modèle, un seul agent et un seul niveau d’effort ont été testés. Qwik est passé de
1.20.2à1.20.3après la première exécution. La combinaison Gracile+Lit demandée a aussi produit deux implémentations sans Lit. - Résultat : les mesures de chargement des pages avec Lighthouse en configuration mobile ne couvrent pas toutes les interactions ni toutes les exigences de production. Les lignes de code mesurent la taille, sans démontrer les futurs coûts de maintenance.
L’exception Angular compte également. L’archive indique que les cinq tentatives ont passé les tests d’acceptation, alors que deux mesures de la version de production ont échoué. Dans votre expérience, suivez séparément la réussite des tests et celle du déploiement.
Comment mesurer le coût de Claude Code dans votre projet ?
Commencez avec deux candidats et trois nouvelles tentatives pour chacun. Passez à cinq si les résultats sont proches. Il s’agit d’une proposition de test pilote, pas d’un résultat de benchmark supplémentaire.
1. Fixez la tâche et le point de départ
Comparez une fonctionnalité délimitée avec les mêmes tests d’acceptation. Pour un produit existant, gardez le framework actuel parmi les candidats. Préparez les deux projets de départ avant de chronométrer une modification. Pour mesurer une création à partir de zéro, incluez la mise en place dans les deux cas.
Décrivez une tâche concrète dans SPEC.md. Préparez, par exemple, des pages de catalogue équivalentes et le même jeu de données de produits, puis demandez :
Add case-insensitive name search to the catalog.
Read products from the existing fixture.
Persist the search query in the URL across reloads.
Show an accessible empty state when nothing matches.
Keep existing routes and the acceptance tests unchanged.Figez les versions des dépendances et conservez les lockfiles. Installez les dépendances avant l’essai de modification. Vérifiez que les deux projets proposent npm run build et npm test. Gardez une copie intacte des tests d’acceptation.
Pour chaque répétition, conservez le même code initial, le même prompt, le même modèle et le même niveau d’effort. Fixez aussi les permissions, les outils prévus pour chaque framework et le mode d’accès et de facturation. Démarrez une nouvelle conversation depuis une copie propre à chaque tentative. Alternez l’ordre des frameworks et relevez l’usage du cache.
Notez aussi les instructions utilisateur, hooks et plugins susceptibles de modifier le comportement. Pour reprendre l’application d’origine et ses vérifications existantes, partez du dispositif de benchmark de Lawson.
2. Enregistrez une exécution et son résultat final
Utilisez Bash avec Claude Code déjà authentifié et jq installé. Vérifiez l’authentification avec claude auth status --text. Si nécessaire, lancez claude auth login avant les essais.
Lancez l’essai dans un conteneur de développement jetable. La liste d’autorisation ci-dessous permet automatiquement les modifications de fichiers et les commandes shell. Autorisez à l’avance les appels MCP prévus avec des règles de permission chargées dans chaque environnement d’essai. Connecter le serveur ne suffit pas.
Attribuez un trial_label distinct à chaque condition. Cet exemple utilise la CLI non interactive documentée et crée un répertoire de sortie unique.
trial_label=astro-01
trial_dir=$(mktemp -d "/tmp/${trial_label}.XXXXXX") || exit 1
claude --version > "$trial_dir/claude-version.txt"
git rev-parse HEAD > "$trial_dir/commit.txt"
trial_status=0
CLAUDE_CODE_EFFORT_LEVEL=high claude -p \
--model claude-opus-5-5 \
--max-budget-usd 10 \
--allowedTools "Read,Edit,Write,Bash" \
--output-format stream-json --verbose \
"Implement SPEC.md without changing dependencies or acceptance tests. Run npm run build and npm test. Report incomplete work." \
> "$trial_dir/session.jsonl" 2> "$trial_dir/stderr.log" \
|| trial_status=$?
printf '%s\n' "$trial_status" > "$trial_dir/exit-code.txt"
jq -s '
[.[] | select(.type == "result")] | last
| if . == null then error("No final result; record an incomplete run")
else {
session_id,
subtype,
is_error,
estimated_usd: .total_cost_usd,
reported_wall_minutes: (.duration_ms / 60000),
modelUsage,
permission_denials
} end
' "$trial_dir/session.jsonl" > "$trial_dir/summary.json"
cat "$trial_dir/summary.json"
printf 'Results: %s\n' "$trial_dir"Le budget de $10 sert uniquement d’exemple. --max-budget-usd utilise une estimation du coût API, et la dépense peut dépasser ce seuil. Appliquez le même seuil à toutes les conditions et notez les arrêts dus au budget.
Au 2026-11-06, CLAUDE_CODE_EFFORT_LEVEL est prioritaire sur --effort. Les limites d’effort de l’organisation peuvent toujours plafonner le niveau choisi. Si le modèle ne se charge pas, corrigez la configuration d’Opus 5.5 avant de poursuivre la comparaison.
Le résumé doit contenir estimated_usd, reported_wall_minutes, modelUsage et les éventuels permission_denials. Le journal JSONL conserve les événements des outils pour inspection. Confirmez que le modèle prévu apparaît, puis notez tout modèle supplémentaire utilisé.
3. Comparez les résultats acceptés et conservez les échecs
Utilisez modelUsage pour compter les tokens de l’agent et de ses sous-agents. Gardez inputTokens, outputTokens, cacheReadInputTokens et cacheCreationInputTokens séparés. Le champ usage du message de résultat exclut l’activité des sous-agents.
Lisez le résultat final une seule fois. N’additionnez pas les totaux cumulés de plusieurs résultats. Ne considérez pas une session reprise comme une nouvelle tentative.
Exécutez vous-même les tests inchangés et le build de production. Vérifiez que les fichiers de dépendances et de tests n’ont pas changé. Un résultat annoncé comme réussi par l’agent ne prouve pas que l’application respecte la spécification.
Si le résultat final manque ou si son format est invalide, consultez stderr.log. Notez une exécution incomplète avec un coût inconnu. Ne saisissez pas zéro. Réglez les refus de permission avant d’attribuer l’absence d’appels MCP au comportement de l’agent.
Pour chaque framework, indiquez le nombre de tentatives acceptées sur le total. Donnez les médianes et les plages des exécutions réussies, ainsi que le coût estimé total de toutes les tentatives. Pour obtenir le coût par résultat accepté, divisez le coût estimé de toutes les tentatives par le nombre de résultats acceptés :
Total quoted cost of all attempts / Number of accepted results
Si une tentative manque de données de coût, signalez que le coût de l’ensemble est incomplet. Sans résultat accepté, rapportez un échec plutôt qu’un coût unitaire fini. Notez séparément le temps de vérification humaine.
Pour les sessions manuelles, le suivi actuel des coûts de Claude Code affiche le même type d’estimation dans /usage. La référence des commandes décrit /cost comme un alias de /usage au 2026-11-06. Les limites d’usage de l’abonnement et les montants réellement facturés par le fournisseur restent distincts de cette estimation.
Conservez votre stack actuel si le travail de vérification ou de migration dépasse le bénéfice d’une petite économie de tokens. Réévaluez ce choix si le candidat passe régulièrement les mêmes tests avec des coûts de maintenance et d’exploitation acceptables.
Après avoir choisi le framework, testez un autre modèle ou un autre mode d’accès dans une expérience séparée. Le comparatif des modèles pour le développement aide à choisir les candidats sans modifier plusieurs variables pendant le test des frameworks.
