Chaque outil de vibe coding vend la même illusion : que le coût d’une application correspond au coût de sa génération. Le premier prompt est bon marché et spectaculaire. Le budget s’épuise plus tard, dans la boucle de correction, et cette boucle n’est pas un cas particulier. C’est le mode de fonctionnement normal de tout outil de génération de code sur ce site dès qu’une application dépasse une taille triviale.
Pourquoi le 20e prompt coûte plus cher que le 1er
Le premier prompt s’adresse à une page blanche ; le modèle excelle dans cet exercice, et un seul tour suffit généralement pour obtenir des progrès visibles. Le 20e prompt, lui, doit modifier un système existant dont le modèle ne se souvient que partiellement. À mesure que la base de code s’étoffe, elle dépasse la fenêtre de contexte de l’IA, et le modèle commence à se contredire. Les corrections traitent alors les symptômes plutôt que les causes racines : un correctif à un endroit en casse un autre. C’est ce que les développeurs appellent le « whack-a-mole » du prompt. L’itération fait aussi gonfler l’artefact lui-même : le contexte limité force l’IA à réécrire des fonctions utilitaires qu’elle ne voit plus, créant des doublons de logique et un patchwork de styles qui rend chaque correction ultérieure plus difficile à implémenter.
L’économie unitaire s’inverse donc. Les premiers prompts achètent des fonctionnalités ; les derniers achètent des tentatives. Et chaque tentative est facturée.
Ce que disent les compteurs
Les chiffres de la recherche, par outil, issus de rapports d’utilisateurs documentés.
Lovable vend des crédits, l’offre Pro de base étant à 25 euros pour 100 crédits par mois. Les utilisateurs signalent que la consommation par prompt passe d’environ 1,2 crédit à 3-4, soit une inflation des coûts d’environ dix fois avec le temps, même les simples questions sur le code consommant des fractions de crédit. Les testeurs décrivent une boucle classique : des crédits dépensés dans des chats de débogage où l’agent introduit de nouvelles erreurs tout en résolvant la première, avec des rapports indiquant que l’IA prétend avoir corrigé le problème alors que ce n’est pas le cas. À 3-4 crédits par prompt, un forfait de 100 crédits permet moins de 30 tentatives par mois.
Bolt vend des jetons (tokens), 10 millions pour le forfait Pro à 25 $. Le grief principal concerne le paiement pour une absence de progrès : une modification de diff immédiatement réécrite sans le changement, « brûlant simplement des tokens sans rien modifier », ou une limite mensuelle consommée par une erreur générée, laissant le développeur attendre le mois suivant pour corriger l’erreur de l’outil lui-même. Les utilisateurs décrivent également un épuisement opaque lors de boucles complexes, sans détail sur les modifications ayant consommé les tokens.
Replit présente la courbe la plus raide car sa tarification est basée sur l’effort : la facture suit l’intensité du travail de l’agent, et rien ne fait travailler un agent plus durement que de se déboguer lui-même. Cas documentés : 25 $ de crédits consommés en moins d’une journée, 350 $ en un seul jour, 700 $ en un mois, et 1 500 $ de frais de base de données imprévus, causés en partie par des sauvegardes à chaque point de contrôle. L’analyse la plus sombre de la communauté est structurelle : plus d’erreurs signifient plus de corrections, donc plus d’exécutions facturables.
Des compteurs différents, mais la même logique. L’unité de facturation est la tentative, et le débogage est l’activité qui maximise ces tentatives.
Nommer la taxe
Appelons cela la taxe sur la boucle de correction : l’écart entre ce que vous paieriez si la génération fonctionnait du premier coup et ce que vous payez réellement. Elle possède trois propriétés notables. Elle est invisible lors de l’achat, car le prix affiché correspond au scénario idéal. Elle est régressive, frappant le plus durement les créateurs les moins capables de diagnostiquer les causes racines, car ils effectuent le plus de tours de boucle. Et elle est corrélée à l’importance du projet : les applications qui déclenchent les boucles les plus profondes sont les applications métier riches en cas particuliers et lourdes en authentification, celles dont vous avez le plus besoin, comme celles analysées dans Lovable vs Bolt.
Cette taxe ne se limite pas à la colonne des coûts. Chaque tour facturé sur une fonctionnalité liée à l’authentification relance les dés de la sécurité, comme expliqué dans ce que signifie réellement « 45 % du code IA est vulnérable », et la boucle elle-même illustre le quotidien du problème du Jour Deux : la phase de maintenance où chaque changement risque d’en briser un précédent. Le compteur n’est que la partie visible sur la facture.
Payer moins, ou pas du tout
Pour les outils de génération de code, les solutions relèvent de l’artisanat : limiter précisément la portée des prompts, commiter chaque état fonctionnel, lire les diffs avant d’accepter, et reconnaître la dérive assez tôt pour s’arrêter. Un outil à abonnement forfaitaire comme Cursor permet au moins de plafonner le pire scénario à un montant mensuel connu.
La réponse structurelle consiste à identifier les applications qui n’ont pas besoin de boucle. Un portail ou un outil interne est principalement composé d’authentification, de permissions et de CRUD ; sur une plateforme comme Softr, ce sont des configurations : on modifie un paramètre, le changement est appliqué, sans tour de régénération ni tentative facturée. Softr propose des crédits IA pour son Co-Builder, mais comme tout ce que l’IA fait peut être fait manuellement, un solde vide ne bloque jamais une correction. Pour les applications métier, la boucle de correction la moins chère est celle qui n’existe pas.