Lovable, Bolt, v0 : jusqu'où aller seul

Ce que l’outil fait mieux que nous

Commençons par ce qu’on ne vous dira pas ailleurs : pour une première version qui sert à convaincre, un outil qui génère l’application à partir d’une phrase est meilleur qu’un développeur. Plus rapide, moins cher, et surtout il vous laisse changer d’avis dix fois par jour sans que personne ne vous facture le onzième.

Un prototype montré à vingt personnes, refait trois fois d’après ce qu’elles ont dit, mis en ligne un dimanche : aucun prestataire ne fera ça pour vous au même prix, et aucun ne devrait essayer. Le cadrage que nous facturons 500 € part de ce que vous avez appris pendant cette phase. Sans elle, il partirait de rien.

Restez donc seul tant que le produit sert à apprendre. La question n’est pas « combien j’ai de budget », c’est « qui dépend de ce que mon produit affiche ». Tant que la réponse est « personne, ou des testeurs prévenus », vous n’avez pas besoin de nous.

Les quatre seuils

Ils ne se cumulent pas. Un seul suffit, et le premier franchi est en général le bon moment.

Vous encaissez. Dès qu’un client paie, votre produit a des états qu’il n’avait pas : payé, remboursé, impayé, résilié. Un outil de génération produit une case « a payé », vraie ou fausse, et tout ce qui se passe entre deux paiements lui échappe. Le premier remboursement à la main, la première carte refusée, le premier client qui garde l’accès sans payer arrivent dans le mois. Ce seuil est le plus net, et le plus souvent franchi trop tard.

Vous tenez des données d’autres personnes. Des inscrits, des commandes, des adresses, des messages. Ce que vous devez à ces personnes ne dépend pas de votre chiffre d’affaires. En mai 2025, plus de 170 applications faites avec un outil de génération laissaient lire leur base à n’importe qui, sans qu’aucune n’affiche d’erreur. Le test pour savoir si vous en faites partie tient en dix minutes, et il est décrit sur ce site. S’il trouve quelque chose, le seuil est franchi.

Quelque chose tourne sans personne devant. Un courriel programmé, une synchronisation avec une source externe, un recalcul la nuit. Ce qui tourne sans vous doit savoir s’arrêter proprement et prévenir. Les outils de génération savent lancer un traitement ; ils ne savent pas décider ce qu’il doit faire quand la source répond n’importe quoi. Sur un comparateur de 64 boutiques que nous avons repris, la moitié des sources s’étaient arrêtées sans que le fondateur le sache, pendant trois semaines.

Un second type d’utilisateur apparaît. Un administrateur, un vendeur à côté de l’acheteur, un prestataire à côté du client. Ce n’est pas un écran de plus, c’est un jeu de droits : qui voit quoi, qui modifie quoi. Un outil de génération met la règle dans la page, où n’importe qui peut la contourner. Le seuil est franchi quand la règle a besoin d’être vraie, pas seulement affichée.

Pourquoi pas un seuil en euros

Les comparatifs donnent des chiffres : sous 5 000 € restez sur l’outil, au-dessus de 10 000 € prenez une agence. C’est commode et ça ne veut rien dire. Un produit à 3 000 € qui encaisse a besoin d’un vrai traitement des paiements ; un produit à 20 000 € qui sert à montrer des maquettes à des investisseurs n’a besoin de rien.

Le budget dit ce que vous pouvez dépenser. Il ne dit pas ce que le produit doit tenir. Et c’est la seconde question qui décide si l’outil suffit.

Ce que coûte de continuer trop longtemps

Le coût visible est le temps et les crédits : chaque correction consomme, et le compte de ce mois ressemble à celui du mois dernier. Le coût qui compte est ailleurs.

Un produit qui a franchi un seuil sans changer de méthode accumule des rustines : chaque prompt corrige le dernier symptôme et en crée un autre à côté. Au bout de trois mois, la partie à refaire est plus grosse qu’au premier jour, et elle contient des données réelles qu’il faudra reprendre sans les perdre. La reprise coûte alors plus cher que si elle avait été faite au moment du seuil, et elle se fait avec des clients dans la boucle.

Ce qui se passe ensuite

Rien n’oblige à tout jeter. Ce que vous avez construit a servi : il a validé l’idée, formé votre discours, et il dit précisément ce que la première version doit contenir. Sur une reprise, l’audit regarde ce qui tient et ce qui ne tient pas, et la brique qui casse se refait sans toucher au reste. Sur une construction, le cadrage part de votre prototype comme d’un brouillon, et il est plus court que s’il partait d’une idée.

Dans les deux cas, vous gardez la main : les comptes, les dépôts et le nom de domaine restent à votre nom, et l’outil de génération reste utile pour maquetter la suite.

Questions fréquentes

Puis-je garder Lovable pour l'interface et vous confier le reste ?

Oui, et c'est souvent la bonne découpe : l'interface est ce que l'outil fait le mieux, le serveur et les données sont ce qu'il fait le moins bien. La frontière se décide à l'audit, et elle doit être nette pour que les deux puissent évoluer sans se casser.

Mon produit a franchi deux seuils et fonctionne encore. Pourquoi changer ?

Parce qu'il fonctionne pour l'instant, et que le jour où il cesse, il le fera sans erreur visible : un paiement compté deux fois, une table lisible par tous, un traitement arrêté en silence. Franchir un seuil n'est pas une panne, c'est une exposition.

Exporter le code vers Cursor ou Claude, est-ce la même chose que faire appel à un développeur ?

Non. Vous changez d'outil, pas de méthode. Tant que la demande est « corrige ce bug », la réponse est une rustine. Un développeur commence par lire ce que fait le code et pourquoi il échoue, et c'est ça qui change le résultat.

Combien de temps un prototype peut-il rester un prototype ?

Aussi longtemps que personne n'en dépend. Nous avons vu des produits rester six mois sur un outil de génération sans problème, parce qu'ils servaient à convaincre. Et d'autres franchir un seuil la première semaine, parce qu'ils encaissaient dès le lancement.