Refaire son application ou l'améliorer : 30 000 dollars pour une reconstruction inutile

Un prestataire qui a livré plus de soixante applications raconte avoir vu des fondateurs dépenser 30 000 dollars à reconstruire un outil qu'il aurait fallu arrêter. Refaire son application ou l'améliorer se tranche avec trois questions, posées avant le premier devis.

Refaire son application ou l'améliorer : un prestataire qui dit avoir livré plus de soixante applications Bubble et autant en code écrit sur Reddit (r/Bubbleio, mai 2026) avoir vu trop de fondateurs dépenser 30 000 dollars à reconstruire une application qu'ils auraient dû arrêter. La reconstruction se justifie, mais moins souvent qu'on ne vous la vend.

Le devis arrive toujours dans le même ordre

Un fondateur raconte sur Reddit (r/nocode, juin 2026) avoir consulté plusieurs prestataires pour faire évoluer son application, et avoir reçu partout la même réponse : on repart de zéro, voici un montant à six chiffres, voici un délai en mois, et l'application reste gelée pendant les travaux. Un des devis était à 60 000. Il est resté bloqué trois mois après les avoir reçus. L'ordre est toujours celui-là parce qu'il arrange le prestataire : reconstruire se chiffre, se planifie et se facture, alors que reprendre le code de quelqu'un d'autre est un travail ingrat dont personne ne connaît la durée à l'avance.

Le mur n'est presque jamais là où on le croit

Quand une application no-code coince, la cause est souvent une seule demande précise, pas l'outil dans son ensemble. Un fondateur décrit sur Reddit (r/nocode, juillet 2026) une application Softr reconstruite en entier parce qu'un client voulait des droits d'accès ligne par ligne que l'outil ne savait pas faire : tout le reste fonctionnait. Avant de signer une reconstruction, écrivez la liste des choses qui vous manquent, et regardez combien tiennent dans une seule ligne. Si c'est une, vous payez une reconstruction pour une fonctionnalité, et le mur des droits d'accès mérite d'être regardé de près avant tout devis.

Trois questions avant de signer

La première porte sur ce que votre application vous rapporte par mois aujourd'hui. Le prestataire cité plus haut place un seuil sous lequel il déconseille toute reconstruction, et beaucoup d'outils qu'on refait à grands frais n'ont jamais trouvé leurs utilisateurs. Une application qui ne rapporte rien ne devient pas rentable parce qu'elle est mieux écrite. La deuxième porte sur l'origine de la gêne : la lenteur, la facture mensuelle, une règle métier que l'outil refuse, ou des écrans devenus laids. Trois de ces quatre réponses se traitent sans repartir de zéro. La troisième porte sur ce que devient l'application pendant les travaux. Un gel de quatre mois coûte plus cher que le devis, en clients qui n'attendent pas et en habitudes que vos utilisateurs prennent ailleurs pendant ce temps.

Améliorer se mesure, reconstruire se croit

Le même prestataire donne un ordre de grandeur utile : une modification d'interface qui prend dix minutes dans un outil no-code demande deux à trois heures au minimum dans du code écrit. Vous ne rachetez donc pas de la vitesse en reconstruisant, vous rachetez de la maîtrise, et cela ne vaut le coup que si vous butez sur quelque chose que l'outil actuel ne fera jamais. Une amélioration, elle, se mesure : vous listez cinq gênes, vous en traitez une, vous regardez si les gens s'en servent, et vous décidez pour la suivante. C'est la même façon de faire que pour un logiciel métier vieillissant ou une base Access qui tourne encore.

Quand reconstruire se justifie

Trois cas honnêtes. Votre outil actuel ne peut pas faire une chose dont dépend votre chiffre d'affaires, vérifiée auprès de son éditeur et pas supposée. Votre facture mensuelle grimpe avec le nombre d'utilisateurs au point de manger votre marge. Ou l'éditeur ferme, rachète, change ses conditions, et vous n'avez aucun moyen de sortir. Dans ces trois cas, la reconstruction achète une liberté réelle, et elle se prépare : on écrit d'abord ce que l'outil doit faire, on migre les données, on bascule par morceaux, et l'ancien reste consultable le temps que le nouveau fasse ses preuves.

Estimer votre cas

Prenez une feuille et écrivez les cinq choses qui vous font dire que l'application doit être refaite. En face de chacune, mettez le nom de la personne qui s'en plaint et ce que cela coûte par mois. Si la colonne des coûts reste vide ou tient en une ligne, gardez votre application et traitez cette ligne. Si trois lignes sur cinq chiffrent, faites écrire un cahier des charges de la version suivante avant de demander un devis : vous compareriez sinon des propositions qui ne parlent pas du même produit.