Angular coûte deux fois plus cher à un agent IA que Hono+htmx : 4,97 $ contre 2,67 $ par application

Lorsqu'une équipe choisit un framework, elle pense généralement aux habitudes des développeurs, à l'écosystème et au recrutement. Un nouveau facteur s'ajoute désormais : combien coûtera le travail d'un agent IA qui écrit le code à la place d'un humain. Le développeur Nolan Lawson a décidé de le mesurer en dollars et en minutes.

Comment l'expérience a été conçue

La tâche était la même pour tous : un catalogue de Pokémon avec recherche, filtres et données réelles issues de PokéAPI. Elle a été confiée à Claude Code, avec le modèle Opus 5.5 et un niveau de raisonnement élevé. Lawson a testé 12 variantes, dont du JavaScript pur sans framework d'interface. Il a lancé chaque variante cinq fois et retenu la médiane, afin qu'un coup de chance ou un échec isolé ne fausse pas le tableau. L'agent recevait la même description de tâche et des tests fonctionnels servant à vérifier le résultat.

La méthode est simple, et on peut donc lui accorder plus de crédit qu'à des impressions isolées du genre « Claude écrit bien en React ». Ici, il y a un critère commun et de la répétabilité.

Résultats

Angular obtient les pires résultats sur les deux métriques à la fois : 17,2 minutes et 4,97 dollars par application. Astro est le plus rapide, avec 8,2 minutes. Le duo Hono et htmx est le moins cher : 2,67 dollars et 8,6 minutes. Angular met environ deux fois plus de temps et coûte environ deux fois plus cher que les meilleurs.

Le JavaScript pur s'en sort correctement, sans être le meilleur : 2,98 dollars et 10,1 minutes. Il ne devance ni Astro, ni Hono avec htmx. La thèse « moins d'abstractions, donc plus simple pour l'agent » ne se confirme pas ici. Ce qui aide l'agent, ce n'est apparemment pas l'absence de framework, mais des conventions claires et un code compact qu'il n'a pas besoin de longuement analyser.

Côté tokens, l'écart est le suivant : Nuxt en a dépensé 3,85 millions, Angular 9,76 millions, soit 2,5 fois plus. L'essentiel de la dépense venait de la relecture répétée du contexte mis en cache. Plus la boucle « écrire, lancer, corriger » est longue, plus souvent l'agent relit l'historique accumulé, et la facture grimpe presque toute seule.

La qualité n'en souffre presque pas

Le résultat inattendu est que les applications finales diffèrent peu. La performance médiane Lighthouse se situe entre 97 et 100 points, et l'accessibilité est à 100 partout. Un framework coûteux n'a donc pas produit un meilleur produit. Il a seulement exigé plus d'étapes et de tokens pour le même résultat.

Que faire de ces données

Il ne faut pas choisir sa stack uniquement sur ces chiffres. Il s'agit d'une seule application, d'un seul modèle et d'un seul scénario. Un catalogue avec recherche et filtres se prête facilement à une approche server-first, alors qu'un front-end d'entreprise complexe, avec formulaires, état et des dizaines d'écrans, peut donner un tout autre tableau. De plus, les prix des tokens et le comportement des modèles évoluent vite.

Pour autant, il y a des enseignements pratiques :

• Si vous lancez des agents sur un grand volume de tâches, comme des prototypes, des outils internes ou des landing pages dynamiques, un écart d'un facteur 2 se traduit en argent réel. Cela vaut la peine de faire tourner votre propre benchmark sur vos tâches types.
• Pour des prototypes rapides confiés à un agent, il est raisonnable d'envisager Astro ou Hono avec htmx. Ils ont offert le meilleur temps et le meilleur prix à qualité égale.
• Si Angular est déjà adopté dans votre équipe, ce n'est pas une raison d'y renoncer. Il suffit de prévoir dans le budget que l'agent travaillera plus longtemps et à un coût plus élevé, et de surveiller la taille du contexte.
• La métrique doit être calculée dans son ensemble : tokens, minutes et part des relectures répétées du contexte. Optimiser uniquement le prix par requête ne suffit pas.

L'enseignement principal : le framework influe désormais aussi sur le coût du développement automatisé. Ce coût mérite d'être mesuré au même titre que la vitesse de build ou la taille du bundle.