Reprendre un MVP fait avec Lovable ou Bolt : audit, décision, checklist

Que génèrent vraiment Lovable et Bolt ?

Les deux outils transforment des instructions écrites en langage courant en une application web qui tourne. Ce qu'ils produisent est du code standard, que vous pouvez sortir de la plateforme. C'est ce qui rend une reprise possible.

Lovable génère une application React. D'après sa documentation, les projets créés depuis le 13 mai 2026 reposent sur TanStack Start, avec un rendu côté serveur ; les plus anciens sont en React et Vite, rendus dans le navigateur. Les données sont stockées dans PostgreSQL, soit via le backend intégré (Lovable Cloud : base gérée, connexion des utilisateurs, stockage de fichiers), soit via votre propre projet Supabase. Le code se synchronise avec un dépôt GitHub, GitLab ou Bitbucket, et les offres payantes permettent de le télécharger en archive.

Bolt.new s'en tient aux technologies web JavaScript : un framework front qui tourne dans le navigateur, Node.js côté serveur, Expo pour le mobile. PHP et Python ne sont pas pris en charge (documentation Bolt). Les nouveaux projets utilisent par défaut une base de données Bolt, que Supabase peut remplacer. Une connexion GitHub sauvegarde le projet avec tout son historique et permet de continuer le travail hors de Bolt.

Vous ne partez donc pas d'une boîte noire : un développeur JavaScript ou TypeScript lit ce code sans difficulté particulière. Reste à savoir dans quel état il se trouve.

Où ces MVP coincent-ils en production ?

Pour faire apparaître une interface et un parcours, ces outils vont très vite. Nous codons nous-mêmes avec des assistants IA tous les jours, et l'expérience se répète : le code arrive vite, la relecture reste à faire. Les ennuis commencent quand arrivent les vraies données et les premiers paiements. Voici ce qu'il faut examiner en priorité.

Les droits d'accès aux données

Le risque le plus sérieux d'un MVP généré par IA se trouve rarement dans le code visible. Il se cache dans la configuration de la base. Dans une architecture Supabase, l'application web interroge souvent la base directement, avec une clé publique présente dans le navigateur de chaque visiteur. Ce qui protège alors les données, ce sont les règles de sécurité au niveau des lignes (Row Level Security, ou RLS). La documentation de Supabase le dit sans détour : une table d'un schéma exposé sans RLS est lisible et modifiable par tout rôle qui dispose d'un droit sur elle. Lovable écrit lui-même, dans sa page consacrée à la sécurité, que des règles RLS mal configurées sont une cause fréquente de fuites de données. Le test de base est simple : créez deux comptes, essayez de lire les données de l'un depuis l'autre, puis recommencez sans être connecté.

Les secrets et les contrôles faits dans le navigateur

Une clé d'API de paiement, d'e-mail ou d'IA placée dans le code front est lisible par n'importe quel visiteur. La retirer du code ne suffit pas : une clé exposée se révoque et se régénère. Même logique pour les contrôles : un prix, un quota ou une vérification de droit calculés dans le navigateur se contournent avec les outils de développement. Ils doivent s'exécuter côté serveur, dans une fonction serveur ou une API.

Les tests et la structure du code

Un prompt peut modifier plusieurs fichiers d'un coup. Sans tests automatisés, personne ne sait ce qui a cassé ailleurs. Au fil des demandes, le code s'épaissit : composants de plusieurs centaines de lignes, logique copiée à trois endroits, dépendances ajoutées puis oubliées. L'application fonctionne, mais chaque évolution coûte un peu plus cher que la précédente.

Les performances et les comptes

Une liste sans pagination ou une requête relancée à chaque écran passent inaperçues avec vingt lignes en base. Avec vingt mille, l'application rame. Dernier point, souvent oublié : qui possède la base, l'hébergement, le domaine et le compte d'envoi des e-mails ? Le jour où vous voudrez changer d'outil ou de prestataire, la réponse comptera.

Garder, consolider ou réécrire : comment décider ?

Reprendre un MVP fait avec Lovable ou Bolt mène à l'une de trois décisions. Garder, c'est conserver le code et corriger quelques points précis : c'est possible quand les données sont bien protégées, que le code reste lisible et que le produit sert encore peu d'utilisateurs. Consolider, c'est garder l'interface et les parcours validés, puis reprendre ce qui ne tient pas en production : règles d'accès, logique côté serveur, tests, structure, déploiement. C'est souvent le bon compromis pour un prototype qui a trouvé ses premiers utilisateurs. Réécrire, c'est repartir d'une base propre en se servant du prototype comme d'un cahier des charges cliquable. On le choisit quand le modèle de données ne correspond pas au métier, quand la logique est éparpillée dans le front, ou quand le produit doit faire ce que la stack générée permet mal : mobile hors-ligne, conformité stricte, intégrations lourdes. Si vous repartez de zéro, prévoyez le délai de développement d'un MVP classique.

Dans les trois cas, le prototype a déjà rempli son rôle : il a validé un parcours auprès de vrais utilisateurs.

Combien de jours prévoir pour une reprise ?

Tout dépend de l'état du code, et c'est précisément ce que l'audit mesure. Pour vous situer en attendant, voici des ordres de grandeur calculés avec un TJM senior de 500 à 700 €, un repère courant pour un développeur freelance expérimenté en France.

• Audit de reprise : 3 à 5 jours, soit environ 1 500 à 3 500 €.
• Corrections ciblées, si vous gardez le code : 3 à 10 jours, soit 1 500 à 7 000 €.
• Consolidation : 10 à 40 jours selon l'ampleur des reprises, soit 5 000 à 28 000 €.
• Réécriture : le budget d'un MVP neuf. Les repères du marché vont de 20 000 à 60 000 € selon le type de produit (détail dans combien coûte un MVP), soit 30 à 120 jours environ.

Ces chiffres ne sont pas un devis. Ils supposent un périmètre de MVP : une plateforme avec plusieurs rôles, du paiement et des intégrations en sort.

Comment se déroule l'audit d'un projet Lovable ou Bolt ?

Il commence par les accès : le dépôt Git, un accès en lecture à la base et la liste des comptes (plateforme, hébergement, domaine, paiement). Un accord de confidentialité peut être signé avant d'ouvrir quoi que ce soit.

Nous lisons ensuite le code et nous le faisons tourner hors de la plateforme, depuis le dépôt. Nous testons les règles d'accès avec plusieurs comptes, nous cherchons les secrets dans le code et dans l'historique Git, nous listons les dépendances et leurs failles connues. Le modèle de données reçoit le plus d'attention : c'est lui qui fait le plus souvent pencher la balance entre consolider et réécrire.

La restitution se fait de vive voix. Vous recevez un rapport qui classe chaque problème par impact et par effort, avec une recommandation et un chiffrage. C'est le format de notre audit de code : votre équipe peut exécuter le plan seule, avec ou sans nous.

Quelle checklist suivre avant la mise en production ?

Cochez ces points avant d'ouvrir le produit à plus de monde. Si plusieurs lignes restent vides, la consolidation n'est pas terminée.

1. Le code est dans un dépôt Git au nom de l'entreprise, et non sur le compte personnel d'un associé ou d'un freelance.
2. L'entreprise possède les comptes : plateforme, base de données, domaine, e-mails transactionnels, paiement.
3. Le projet se construit et démarre hors de l'outil, depuis le dépôt, avec une procédure écrite.
4. La RLS est activée sur chaque table exposée, et testée avec un second compte puis sans compte.
5. Aucun secret dans le code front ni dans l'historique Git ; les clés déjà exposées ont été révoquées et régénérées.
6. Les contrôles qui engagent l'entreprise (droits, prix, quotas) s'exécutent côté serveur.
7. Des tests automatisés couvrent les parcours critiques : inscription, connexion, paiement, action principale.
8. Une préproduction existe, avec sa propre base, séparée de la production.
9. Les sauvegardes de la base sont actives, et une restauration a déjà été essayée.
10. Les erreurs et les temps de réponse sont suivis, avec une alerte quand quelque chose casse.
11. Les dépendances sont à jour et sans faille connue.
12. Les données personnelles sont recensées pour le RGPD : où elles sont stockées, qui y accède, combien de temps on les garde.

Faut-il arrêter d'utiliser Lovable ou Bolt ?

Non. Pour tester une idée ou montrer un parcours à des utilisateurs et à un premier investisseur, ces outils font gagner des semaines. Le risque vient du glissement : un prototype qui accueille de vrais clients sans que personne ait relu ce qu'il fait de leurs données. Lovable le rappelle dans sa documentation : vous restez responsable de la sécurité de votre application, et une revue de sécurité professionnelle est conseillée dès qu'elle traite des données sensibles.

Et chez Neodev ?

Nous auditons et reprenons des applications existantes pour les amener en production, et nous développons des MVP sur mesure quand il vaut mieux repartir d'une base propre. Que vous vouliez faire développer votre MVP à partir de votre prototype ou consolider celui que vous avez, nous commençons par un audit court. Si votre application a déjà quelques années, notre démarche de refonte progressive s'applique aussi. Pour choisir entre améliorer et remplacer, lisez refonte ou refactoring ; si le code est irrécupérable, regardez le coût d'une refonte avant de décider.

Décrivez-nous votre projet : nous répondons sous 24 h, le devis détaillé suit sous 48 h, et le code reste à vous.