Benchmarking des coûts des agents IA sur les frameworks JavaScript

En octobre 2026, le développeur Nolan Lawson a publié une comparaison basée sur les données concernant la performance des frameworks JavaScript modernes lorsqu'ils sont développés par des agents IA. Cette étude remet en question la prise de décision « intuitive » (« vibes-based ») qui prévaut dans le développement frontend en mesurant des indicateurs concrets de coût, de temps et de qualité. En utilisant Claude Opus 5.5, Lawson a chargé un agent IA de construire la même application Pokémon à travers douze stacks technologiques différents afin de déterminer quels outils optimisent réellement les workflows agentiques.

Ce qui s'est passé

Lawson a conçu un benchmark pour tester l'hypothèse selon laquelle certains frameworks seraient intrinsèquement plus adaptés au codage assisté par IA. Il a sélectionné un projet non trivial mais bien défini : une application annuaire de Pokémon utilisant PokéAPI. L'application devait lister les Pokémon, afficher leurs types et leurs attaques, et implémenter des fonctionnalités de recherche et de filtrage. Pour garantir l'équité, chaque framework était associé à son serveur officiel Model Context Protocol (MCP) ou à ses compétences d'agent (« agent skills ») lorsque disponibles, évitant ainsi des désavantages liés aux lacunes des données d'entraînement.

L'expérience consistait à faire tourner l'agent cinq fois pour chaque framework afin de tenir compte de la nature stochastique des grands modèles de langage. La seule exception fut Angular, qui n'a pas réussi à produire une application mesurable lors de deux instances, ne laissant que trois itérations valides pour certaines métriques. L'agent opérait dans un environnement sandbox sans savoir qu'il serait évalué sur les scores de performance Lighthouse, bien qu'il ait été fourni avec une suite de tests de conformité pour empêcher toute triche. L'objectif était de mesurer des résultats réels plutôt que l'expérience développeur théorique.

Les résultats ont révélé une variance substantielle tant en termes de coût que d'efficacité. Hono combiné à htmx s'est avéré l'option la plus économique, avec un coût médian de 2,67 $ par exécution. En revanche, Angular s'est montré le plus coûteux à 4,97 $, tandis que SvelteKit ainsi que Gracile plus Lit figuraient également parmi les plus chers. Fait intéressant, JavaScript vanilla avec Vite a sous-performé plusieurs frameworks, suggérant que les abstractions structurées peuvent aider les agents IA davantage que l'infrastructure brute. L'étude souligne que les affirmations concernant la supériorité des frameworks pour l'IA manquent souvent de fondement empirique, et ce benchmark fournit une base concrète pour l'évaluation.

Comment cela fonctionne

Le benchmark repose sur une spécification stricte et un pipeline d'évaluation automatisé. Lawson a instruit l'agent IA, Claude Opus 5.5, de construire l'application en utilisant des paramètres à haute intensité (« high-effort settings »). L'agent n'a reçu aucune directive architecturale spécifique, telle que le choix entre le rendu côté serveur ou le rendu côté client, lui permettant de prendre des décisions basées sur les conventions du framework. Cette approche teste la capacité de l'agent à naviguer dans l'écosystème sans guidance humaine lourde.

L'évaluation s'est concentrée sur quatre dimensions clés : le temps de développement, la consommation de tokens, le nombre de lignes de code et les métriques de qualité. La qualité a été assessée via Lighthouse pour les scores de performance et d'accessibilité, ainsi qu'avec une suite de conformité personnalisée qui vérifie l'arbre d'accessibilité plutôt que le DOM brut. Cette méthode prend en charge des frameworks comme Lit qui utilisent le shadow DOM, garantissant que les différences structurelles ne pénalisent pas le score. En mesurant les valeurs médianes sur plusieurs exécutions, l'étude atténue l'impact des outliers aléatoires inhérents aux sorties de l'IA générative.

Détails clés

• Hono+htmx était le framework le moins cher à construire, coûtant une médiane de 2,67 $ par exécution.
• Angular était le plus coûteux avec une médiane de 4,97 $ et a pris le plus de temps, soit 17,2 minutes.
• JavaScript vanilla avec Vite coûtait 2,98 $, sous-performant plusieurs frameworks structurés en termes d'efficacité.
• Les agents SvelteKit consultaient fréquemment le guide de migration v3, augmentant l'utilisation de tokens due à sa nouveauté dans les données d'entraînement.
• L'utilisation des serveurs MCP et des compétences par l'agent était incohérente, le MCP de Nuxt n'ayant jamais été utilisé et les compétences de Next.js rarement consultées.
• Les métriques Lighthouse favorisaient les frameworks d'applications multi-pages en raison de biais inhérents contre les applications monopages (SPA).

Pourquoi c'est important

Pour les responsables techniques et les fondateurs, cette étude souligne les implications financières du choix de framework dans un workflow agentique. À mesure que les agents IA prennent en charge davantage de tâches de codage, le coût par fonctionnalité devient une métrique tangible plutôt qu'une préoccupation abstraite. Les frameworks nécessitant moins de tokens et moins de temps pour générer du code correct réduisent directement les dépenses opérationnelles. La variance observée, telle que le taux d'échec et le coût plus élevés d'Angular, suggère que certains écosystèmes ne sont pas encore optimisés pour l'interaction avec l'IA, pouvant entraîner des dépassements de budget dans les projets à grande échelle.

De plus, les résultats remettent en cause la notion selon laquelle le code « vanilla » est toujours la voie la plus efficace pour l'IA. Les données montrent que les frameworks fournissent des garde-fous et des conventions qui aident les agents à éviter les pièges courants, réduisant le besoin de chargement de contexte extensif. Cette information est cruciale pour les équipes décidant d'adopter de nouveaux méta-frameworks ou de rester fidèles aux bibliothèques établies. Elle suggère que la bonne abstraction peut réduire la charge cognitive sur l'IA, conduisant à des sorties plus rapides et plus fiables.

Ce que vous pouvez faire

• Benchmark votre framework actuel en faisant construire un petit composant standardisé par un agent IA et en mesurant l'utilisation de tokens.
• Assurez-vous que les outils IA de votre équipe sont configurés pour utiliser les serveurs MCP officiels ou les compétences afin de maximiser la pertinence du contexte.
• Prenez en compte le coût total de possession, y compris la consommation de tokens IA, lors de l'évaluation de nouveaux frameworks JavaScript.
• Exécutez plusieurs itérations de code généré par IA pour tenir compte de la variance stochastique avant de prendre des décisions architecturales.
• Utilisez des tests basés sur l'arbre d'accessibilité plutôt que l'inspection du DOM pour évaluer équitablement les frameworks utilisant le shadow DOM.
• Surveillez le comportement de l'agent pour voir s'il utilise efficacement la documentation disponible et les fichiers de compétences durant le développement.