Reprendre un MVP Lovable ou Bolt : fiabiliser ou reconstruire ?
Votre prototype généré par IA fonctionne, les premiers utilisateurs arrivent — et tout commence à casser. Voici les faiblesses réelles à corriger, le critère qui tranche entre réparer et reconstruire, et comment le faire sans jeter ce que vous avez déjà payé.
Le prototype a marché. C'est là que les ennuis commencent
Lovable, Bolt, v0 : ces outils font apparaître une application en quelques heures, et c'est une vraie prouesse. Ils excellent au prototypage. Le problème n'est pas là — il est dans la marche d'après. Dès que de vrais utilisateurs arrivent et que vous encaissez de l'argent, trois faiblesses se révèlent presque toujours, et elles ne se voient pas depuis l'interface.
Bonne nouvelle : dans la plupart des cas, il n'y a pas besoin de tout refaire. On part de ce qui existe, on l'audite, on désamorce les failles et on fiabilise. Encore faut-il savoir ce qu'on regarde.
Les trois faiblesses qui reviennent toujours
1. Une sécurité approximative
C'est la plus dangereuse parce qu'elle est invisible tant que personne ne cherche. Les cas typiques : des règles d'accès à la base mal configurées (une RLS Supabase permissive qui laisse un utilisateur lire les données d'un autre), des tokens ou clés d'API exposés côté client, des points d'entrée non protégés. Tant que vous êtes seul à tester, rien ne paraît. Le jour où un utilisateur curieux — ou malveillant — regarde, la fuite est déjà là.
2. Une dette technique invisible
Le développement purement génératif produit une dette accélérée : composants dupliqués, logique non optimisée, et surtout absence de tests et déploiement fragile. Le code « marche », mais rien ne garantit qu'il continuera de marcher après la prochaine modification. Cette dette ne coûte rien tant que le produit ne bouge pas — elle se paie au premier changement.
3. Un code que chaque modification casse
C'est le symptôme que les porteurs décrivent le plus souvent : « à chaque fois qu'on ajoute une fonctionnalité, autre chose se casse ». C'est la conséquence directe des deux points précédents. Un code non structuré et non testé devient impossible à faire évoluer sereinement — et c'est exactement le moment où l'on croit, à tort, qu'il faut tout jeter.
Réparer ou reconstruire : le seul critère qui compte
La décision ne se prend pas à l'intuition, et surtout pas par principe. La règle est économique : on ne reconstruit de zéro que si la dette technique coûte plus cher à corriger qu'à refaire. Et c'est un audit qui le détermine — pas une supposition, ni l'envie du prestataire de repartir d'une page blanche.
| Situation | Décision probable | Ordre de grandeur |
|---|---|---|
| Failles de sécurité ciblées, structure globalement saine | Fiabiliser | Quelques jours à semaines |
| Dette localisée, socle réutilisable | Fiabiliser + refactor partiel | Quelques semaines |
| Code ingérable, chaque évolution casse tout | Reconstruire le socle, garder le produit | Selon périmètre |
L'essentiel : même une reconstruction ne repart pas de rien. Vous avez déjà validé un produit, des écrans, un parcours utilisateur qui fonctionne. Ce travail-là n'est pas perdu — on reconstruit le socle technique, pas le produit. Une sécurisation ciblée prend souvent quelques jours à quelques semaines et quelques milliers d'euros, très loin du « tout refaire » que l'on redoute.
Les délais et montants dépendent entièrement de l'état réel du projet. Aucun chiffrage sérieux n'est possible sans avoir vu le code — méfiez-vous de tout prix annoncé avant l'audit.
La bonne séquence pour passer en production
- Récupérer le code. Exportez votre projet vers un dépôt Git dont vous êtes propriétaire. Sans accès au code, aucune reprise n'est possible — et vous restez prisonnier de la plateforme.
- Auditer. Sécurité (accès à la base, tokens, points d'entrée), dette technique, capacité à évoluer. L'audit produit un diagnostic, pas un devis pré-écrit.
- Trancher réparer / reconstruire sur le critère économique, faille par faille.
- Sécuriser d'abord. Les failles de sécurité passent avant toute nouvelle fonctionnalité. Un produit qui fuit des données n'est pas « à améliorer », il est à arrêter.
- Fiabiliser et documenter pour que le produit devienne maintenable — par vous ou par n'importe quel développeur ensuite.
Un mot sur la propriété du code : tant que votre produit vit uniquement dans une plateforme no-code, vous ne le possédez pas vraiment. La première étape d'une reprise sérieuse, c'est toujours de récupérer la maîtrise de votre propre produit.
Comment Solutio reprend un prototype
On part de ce que vous avez déjà payé. On récupère le code, on l'audite honnêtement, et on vous dit ce qui doit être sécurisé, ce qui peut être gardé, et ce qui gagnerait à être reconstruit — avec le raisonnement économique derrière chaque choix. Puis on fiabilise pour la production, sans vous enfermer : le code reste le vôtre, maintenable par qui vous voulez.
Nous construisons des outils et des produits sur mesure pour des porteurs de projet et des PME, du cadrage à la mise en production. Reprendre un MVP no-code pour le rendre solide en fait partie.
Voir comment on construit et fiabilise un produit · Explorer la Solutio Suite en démo
Questions fréquentes
Rarement. Dans la plupart des cas, on part de la base existante, on l'audite, on corrige les failles et on la fiabilise, sans tout refaire. On ne reconstruit de zéro que si la dette technique coûte plus cher à corriger qu'à refaire, et c'est l'audit qui le détermine, pas une supposition. Même en cas de reconstruction, c'est le socle technique qui est refait, pas le produit : les écrans et le parcours validés sont conservés.
Trois reviennent presque toujours : une sécurité approximative (règles d'accès à la base mal configurées, tokens ou clés exposés), une dette technique invisible (code dupliqué, absence de tests, déploiement fragile) et un code que chaque modification casse. Ces faiblesses ne se voient pas depuis l'interface et n'ont aucun impact tant que vous testez seul. Elles se révèlent dès que de vrais utilisateurs arrivent.
Une sécurisation ciblée prend souvent quelques jours à quelques semaines, pour quelques milliers d'euros, très loin d'une reconstruction complète. Mais aucun chiffrage sérieux n'est possible avant d'avoir vu le code : le prix dépend de l'état réel de la sécurité, de la dette et de la capacité du socle à évoluer. Méfiez-vous de tout montant annoncé avant un audit.
Tant que votre produit vit uniquement dans la plateforme no-code, vous n'en avez pas la pleine maîtrise. La première étape d'une reprise sérieuse est d'exporter le code vers un dépôt Git dont vous êtes propriétaire. Sans cet accès, aucune reprise n'est possible et vous restez dépendant de la plateforme, de ses tarifs et de ses limites.
Dans l'ordre : récupérer le code dans un dépôt dont vous êtes propriétaire, faire auditer sécurité et dette technique, décider faille par faille entre réparer et reconstruire sur un critère économique, sécuriser en priorité avant toute nouvelle fonctionnalité, puis fiabiliser et documenter. Les failles de sécurité passent toujours avant les fonctionnalités : un produit qui fuit des données n'est pas à améliorer, il est à arrêter.
Votre prototype mérite un vrai diagnostic
Avant de tout refaire — ou de mettre en ligne en croisant les doigts — faites regarder le code. On vous dit honnêtement ce qui tient, ce qui fuit, et ce que ça coûte de le solidifier.