Combien coûte réellement le vibe coding à grande échelle ?
À grande échelle, le vibe coding coûte bien plus cher que ne le laissent croire les démos, car le prix que vous payez n'est pas par fonctionnalité livrée — c'est par token relu, et la relecture est précisément ce que le prompting à faible supervision maximise. Un développeur seul faisant du vibe coding sur un projet de week-end dépensera peut-être quelques dollars. Le même workflow, mené par une équipe de dix personnes, huit heures par jour, pendant un trimestre, devient un poste de dépense récurrent qui peut rivaliser avec un abonnement SaaS par siège. La différence entre « amusant » et « coûteux » n'est pas la technique. C'est le multiplicateur. Je conçois des outils de réduction de tokens pour gagner ma vie, donc je passe un temps déraisonnable à fixer les transcriptions d'agents des autres. Le schéma est toujours le même : le coût ne vient pas du code que le modèle écrit. Il vient de tout ce que le modèle lit pour décider quoi écrire — et du nombre de fois où il relit la même chose parce que personne ne lui a dit d'arrêter. Cet article est le calcul de coin de table que j'aurais aimé qu'on me donne avant de déployer un workflow d'agent dans une équipe. Ce qu'une session de vibe coding facture réellement, pourquoi le coût s'emballe au lieu de s'additionner, où l'argent fuit, et ce que vous pouvez faire sans abandonner le workflow qui a rendu tout le monde plus rapide au départ. Si vous voulez d'abord la version pour développeur occasionnel, commencez par qu'est-ce que le vibe coding ; ceci est la version équipe-et-budget.Où part réellement l'argent dans une session de vibe coding ?
La quasi-totalité part dans les input tokens qui sont relus à chaque tour — pas dans l'output que le modèle génère. C'est le fait le plus contre-intuitif de l'économie des agents, et c'est celui qui ruine les budgets. Voici le mécanisme. Un agent exécute une boucle de conversation : il lit des fichiers, lance des commandes, voit le résultat, et écrit une réponse. Chaque fichier qu'il ouvre et chaque résultat de commande qu'il voit s'ajoute au context window. Au tour suivant, le modèle relit l'intégralité de ce contexte accumulé pour rester cohérent. Un module de 600 lignes — environ 6 000 à 8 000 tokens — n'est pas facturé une fois. Il est refacturé au tour deux, au tour trois, et à chaque tour jusqu'à ce que la session se termine ou se compacte. Une session de vingt tours peut payer vingt fois le même fichier. Ajoutez maintenant la tarification. Avec Claude Opus 4.8 à 5 $ par million d'input tokens et 25 $ par million d'output, et un tour d'agent typique composé d'environ 90 % d'input (contexte relu) et 10 % d'output (l'édition réelle), vous payez des tarifs output premium sur une mince tranche et des tarifs input réguliers sur une base épaisse et croissante. Le prompt caching aide — les cache reads coûtent environ 10 % du prix d'input — mais le caching ne sauve que les parties du contexte qui restent identiques octet pour octet d'un tour à l'autre. Dès qu'un fichier change, qu'une commande s'exécute ou que l'agent réordonne son contexte, le cache rate sa cible et vous repayez le plein tarif. Le vibe coding, avec son churn permanent d'édition-exécution-rapport, est particulièrement doué pour casser son propre cache. Si vous voulez les chiffres par modèle à intégrer dans votre propre tableur, le décryptage tarification des tokens d'API LLM les tient à jour ; en bref, Opus est le modèle coûteux à laisser tourner sans supervision, Sonnet 5 (2 $ / 10 $ par MTok) est le défaut raisonnable, et Haiku 4.5 (1 $ / 5 $) est celui vers lequel vous vous tournez quand la tâche est mécanique.Pourquoi le coût s'emballe-t-il au lieu de simplement s'additionner ?
Le coût s'emballe parce que le trait caractéristique du vibe coding — la faible supervision — est aussi ce qui pousse chaque tour à récupérer davantage de contexte, et le contexte récupéré à un tour est payé à chacun des tours suivants. Additionner est linéaire. S'emballer est ce qui se passe réellement. Déroulons. Quand vous donnez à un agent un objectif vague (« rends le flux de checkout plus agréable »), il ne peut pas localiser le code pertinent, alors il explore : il ouvre plus de fichiers, grep plus largement, lit plus que nécessaire pour s'orienter. Chaque fichier inutile atterrit dans le contexte de façon permanente pour le reste de la session. L'agent est maintenant plus lent et plus coûteux à chaque tour suivant, parce que cette surcharge l'accompagne. Un prompt précis qui nomme le fichier coûte une fraction de ce que coûte un « débrouille-toi » à la sauce vibe — non pas parce que l'output diffère, mais parce que l'input qui l'a produit diffère. Vient ensuite la boucle de collage d'erreurs, là où le vibe coding gagne sa réputation de fournaise à tokens. Le cycle décrire → exécuter → rapporter, quand un build échoue, peut itérer une dizaine de fois avant de converger. Chaque itération déverse le résultat brut du build — stack traces, logs de résolution de dépendances, bruit du test runner — dans le contexte. Un seul run CI en échec peut représenter des dizaines de milliers de tokens de texte que le modèle survole et ignore en grande partie, et vous payez pour la totalité, à ce tour et à chaque tour suivant, jusqu'à ce que quelque chose se compacte. Multipliez par chaque développeur tombant dans la même boucle quelques fois par jour et le « s'emballer » cesse d'être une métaphore. C'est la partie que les workflows d'agentic coding aggravent, au lieu de l'améliorer : l'autonomie signifie plus de sous-étapes par objectif, et plus de sous-étapes signifie plus de lectures qui s'empilent dans le contexte avant qu'un humain ne voie un résultat. L'autonomie est formidable pour le débit et brutale pour un budget que vous ne surveillez pas.Combien cela coûte-t-il sur une vraie équipe ? (le calcul de coin de table)
Sur une équipe de dix personnes, une habitude modérée de vibe coding atterrit dans la tranche basse à moyenne des milliers de dollars par mois, et elle évolue de façon quasi linéaire avec les effectifs — ce qui explique précisément pourquoi elle vous prend par surprise. Laissez-moi montrer l'arithmétique plutôt que d'affirmer un chiffre. Prenez un développeur faisant un travail d'agent ciblé. Une seule tâche d'agent non triviale — quelques fichiers, deux ou trois boucles d'erreur, peut-être quinze tours — peut brûler 200 000 à 500 000 tokens une fois qu'on compte le contexte relu, majoritairement de l'input. Disons 350 000 tokens, fortement pondérés vers l'input, tournant sur Sonnet pour rester réaliste quant au choix du modèle. Avec le partage 2 $ / 10 $ de Sonnet, l'essentiel étant de l'input et avec des cache hits partiels, cela représente quelque part entre 0,25 $ et 0,55 $ par tâche. Maintenant : un développeur faisant cinq à dix tâches de ce type par jour, vingt jours ouvrés par mois, fait 1 000 à 2 000 tâches par mois. Un siège atteint environ 250 $ à 1 100 $ mensuels selon le mix de modèles et la discipline des prompts. Dix sièges, et vous vous retrouvez face à deux mille cinq cents à onze mille dollars par mois pour ce qui ressemblait, au niveau individuel, à « quelques centimes par-ci par-là ». Ce sont des chiffres illustratifs construits à partir des prix par token publics ci-dessus, pas un benchmark — votre chiffre réel dépend du mix de modèles, du taux de cache hit, et de la quantité de bruit d'erreur que votre stack génère. Mais la forme est robuste, et c'est la forme qui compte : le coût par tâche est assez faible pour que personne ne le signale, et l'agrégat est assez élevé pour que la finance le fasse. Le danger du vibe coding à grande échelle n'est pas une seule requête coûteuse. C'est un millier de requêtes bon marché qui s'emballent au-delà du point où quelqu'un surveille encore. (Les données de référence pour ces fourchettes se trouvent dans coûts en tokens des agents de codage IA.)Comment empêcher les coûts du vibe coding de s'emballer ?
Vous attaquez le côté input, parce que c'est là que vit 80 à 90 % de la dépense, et vous l'attaquez en lisant moins de contexte, pas en promptant moins. Cinq leviers font l'essentiel du travail.- Remplacez les lectures de fichiers à l'aveugle par la semantic code search. Au lieu de laisser l'agent ouvrir des fichiers entiers pour trouver une seule fonction, ne récupérez que les portions pertinentes. C'est le plus gros levier unique, car il taille dans la base épaisse que chaque tour ultérieur relit.
- Filtrez le résultat des commandes avant qu'il n'atteigne le contexte. Les logs de build bruts, le bavardage d'installation et le bruit des tests sont le carburant de la boucle de collage d'erreurs. L'output filtering retire les lignes que le modèle ignore de toute façon, si bien qu'un build en échec de 30 000 tokens devient quelques centaines de tokens de signal réel.
- Compressez la structure avant le contenu. Quand l'agent a besoin de s'orienter plutôt que du détail d'implémentation, donnez-lui un squelette — signatures, types, graphe d'appel — au lieu des corps complets. La compression de contexte conserve la carte sans payer pour le territoire à chaque tour.
- Chargez les outils paresseusement. Chaque serveur MCP que vous branchez injecte ses définitions d'outils dans le contexte, que l'agent les utilise ou non. Les charger à la demande garde cette surcharge hors de la base. Voyez meilleurs serveurs MCP pour Claude Code pour savoir lesquels valent leur poids.
- Adaptez le modèle à la tâche. Les éditions mécaniques n'ont pas besoin d'Opus. Router les 70 % de tâches ennuyeuses vers Haiku ou Sonnet et réserver le modèle phare au raisonnement réellement difficile est la coupe budgétaire la moins chère disponible, et elle ne demande aucun changement de comportement au développeur.
Qu'est-ce qui tourne mal quand les équipes passent le vibe coding à l'échelle ?
Les échecs sont prévisibles, ce qui est la bonne nouvelle — chacun d'eux est une ligne mesurable sur un dashboard avant d'être une surprise sur une facture. Personne ne mesure, donc personne ne remarque. L'échec le plus courant est simplement de ne pas suivre la dépense de tokens par tâche ou par siège jusqu'à l'arrivée de la facture mensuelle. Un coût qui n'est pas mesuré ne peut pas être géré, et les coûts par tâche sont individuellement trop faibles pour attirer l'attention de qui que ce soit. Instrumentez tôt ; le playbook réduire l'usage de tokens de Claude Code couvre ce qu'il faut journaliser. Traiter Opus comme un défaut. Faire tourner le modèle phare pour chaque tâche parce que c'est le « meilleur » est le moyen le plus rapide d'arriver à un mois à cinq chiffres. Meilleur-par-token et meilleur-par-tâche sont des optimisations différentes, et la plupart des tâches de vibe coding relèvent fermement de la seconde catégorie. Laisser le contexte croître sans limite. Les sessions de longue durée qui ne se compactent jamais accumulent une base de contexte qui est relue intégralement à chaque tour. Une session qui tourne depuis trois heures peut payer pour relire toute une matinée d'exploration sans rapport. Compactez agressivement, ou démarrez des sessions fraîches par tâche. Confondre cache hits et économies. Les équipes voient le prompt caching dans la doc et supposent qu'il résout le problème. Il ne fait que remiser le préfixe identique octet pour octet ; le churn du vibe coding casse le cache en permanence. Le caching relève le plancher, il ne pose pas de plafond, et la discipline qui crée un contexte stable et cachable est le context engineering — qui est le vrai correctif, pas la fonctionnalité de cache elle-même. Le fil conducteur : le vibe coding à grande échelle n'est pas coûteux parce que la technique est gaspilleuse. Il est coûteux parce que ce qui le rend agréable — ne pas réfléchir à ce que l'agent lit — est exactement ce qui fait grimper la facture. Vous n'avez pas à abandonner le workflow. Vous devez arrêter de payer pour relire le même contexte un millier de fois par jour. Une fois cela automatisé, la sensation décontractée et la facture raisonnable cessent d'être un compromis.Voir aussi (hub-and-spoke) :
- Réduire l'usage de tokens des agents de codage IA — le pilier avec chaque levier en profondeur.
- Stanford et Michigan ont chiffré le coût des agents — la mesure académique derrière les anecdotes.
- Qu'est-ce que le vibe coding ? — la version développeur individuel de ce sujet.
- Context engineering pour agents IA — la discipline qui fait travailler les agents avec moins.
- Coûts en tokens des agents de codage IA — les données de prix derrière le calcul ici.
- Qu'est-ce qu'un token ? — l'unité dans laquelle tout est facturé.
Classé n°1 au Token-Harness Optimizer Leaderboard.
Tokenade est classé n°1 au Token-Harness Optimizer Leaderboard — un benchmark de bout en bout des optimiseurs de tokens, mesuré sur de vraies sessions de code. Installez-le une fois, il agit sur chaque prompt. Compatible avec Claude Code, Cursor, Codex, Copilot et plus.