Pourquoi mon MVP no-code ne se termine jamais : le jour 9 et les 20 % qui restent

Les écrans existent, la démonstration passe, le paiement de test fonctionne. Puis le projet s'arrête et personne ne sait dire pourquoi. Le récit d'un prestataire qui livre des MVP no-code, ce que contient le dernier cinquième, et pourquoi ce cinquième se paye au prix fort quand il arrive après l'annonce d'une date de lancement.

Un prestataire qui livre des MVP no-code écrit sur Reddit (r/nocode, juillet 2026) que les sept premiers jours donnent l'impression d'être magicien et que le neuvième casse tout : cas limites de connexion, écrans vides que personne n'a dessinés. Votre MVP ne se termine jamais parce que le dernier cinquième ne ressemble pas aux 80 % qui l'ont précédé.

Les sept jours qui donnent raison au no-code

Ces sept jours sont réels et ils méritent d'être défendus. En une semaine, un outil comme Bubble ou Softr donne des écrans qui s'enchaînent, une base de données qui garde ce qu'on y met, un paiement de test qui passe. Un développeur classique aurait consommé le même temps à installer son environnement. Pour montrer une idée à un associé ou à un premier client, cette semaine suffit, et nous le disons ailleurs : le prototype d'une soirée a sa place. Le malentendu commence quand cette semaine sert d'unité de mesure pour la suite.

Ce qui attend au jour 9

Le prestataire cite quatre choses, et elles reviennent dans la même colonne du tableau : ce qui se passe quand un utilisateur fait autre chose que ce qui était prévu. Un mot de passe oublié pendant qu'un compte est en cours de création. Une liste vide au premier jour, avant qu'un seul client n'existe, que personne n'a dessinée parce qu'elle ne se voit jamais en démonstration. Un clavier de téléphone qui recouvre le champ à remplir. Une fonction qui paraissait donnée parce qu'elle existe sur toutes les applications du téléphone. Aucune de ces quatre choses n'apparaît dans le récit de départ. Toutes les quatre bloquent la mise en ligne, et chacune demande une décision de votre part avant de demander du travail à quelqu'un. Un utilisateur qui abandonne devant une liste vide ne revient pas expliquer pourquoi.

Pourquoi le dernier cinquième coûte plus cher

Les 80 % faits sont ce que quelqu'un avait décrit : les écrans, le parcours principal, la vente. Ils se construisent vite parce qu'ils sont écrits quelque part, même en une phrase. Les 20 % restants sont ce que personne n'a décrit, et chacun demande une décision que l'outil ne peut pas prendre à votre place : que voit un utilisateur qui n'a pas encore de données, que devient une commande annulée, qui reçoit le message quand un paiement échoue. Le prestataire raconte avoir fini par se faire payer ce dernier cinquième en parts de capital, faute de budget restant. Le budget avait été calculé sur la vitesse des sept premiers jours, et le client avait déjà annoncé une date à ses propres clients.

Une seule règle d'accès peut tout faire reconstruire

Un autre témoignage du même forum va plus loin (r/nocode, juillet 2026) : son auteur a vu une agence reconstruire une application Softr entière parce qu'un client voulait des droits de lecture différents ligne par ligne, ce que l'outil ne savait pas faire. Tout le reste convenait. Ce point-là, non. Une plateforme no-code fixe ses limites au moment où vous choisissez, et vous ne les rencontrez qu'au sixième mois, sur une demande qui paraît anodine. La question à poser avant de choisir un outil porte donc moins sur ce qu'il affiche que sur ce qu'il refusera de faire plus tard.

Ce que change un découpage en étapes vérifiées

La parade tient dans l'ordre du travail. Chez Maestro, Marcel découpe le cahier des charges validé en étapes qui tiennent chacune debout toute seule, et Félix écrit les tests d'une étape avant qu'Amélie ne la construise. Un cas limite oublié se voit alors au moment du découpage, quand il coûte une phrase, plutôt qu'au jour 9, quand il coûte une reprise. Le décompte reste honnête : le nombre d'étapes est visible dès le départ et il ne bouge pas en douce. Cela ne rend pas les 20 % gratuits, ils restent le travail le plus lent du projet. Cela les rend visibles avant que vous n'annonciez une date à quelqu'un.

Par où commencer

Avant de relancer votre MVP, écrivez la liste de ce qui n'a jamais été décrit : chaque écran quand il n'y a rien à afficher, chaque parcours qui échoue (paiement refusé, mot de passe perdu, client supprimé), chaque droit de lecture différent d'un utilisateur à l'autre. Comptez les lignes. Si la liste dépasse ce que vous pensiez rester à faire, votre estimation reposait sur la vitesse des sept premiers jours. Reprenez-la à partir de cette liste, et comptez le temps réel plutôt que la vitesse du début.