Reprendre un MVP Lovable : garder le code ou repartir ?

Garder le code ou repartir ne se décide pas sur l’outil qui a généré le MVP. Ça dépend de trois choses : où vit le backend, ce qui tourne encore sans l’éditeur, et qui refuse réellement un accès qu’on n’a pas le droit d’accorder. Sur GoPronos, ces réponses m’ont fait garder le React, la base Supabase et le calcul de points en SQL du prototype Lovable ; sur SimplyJury, elles ont fixé l’ordre des corrections avant toute promesse de sortie.

La réponse courte : trois questions, pas un verdict

En mai 2026, j’ai repris le prototype Lovable de GoPronos. Avant de parler de mobile ou de réécriture, j’ai regardé l’existant : une application React, une base Supabase, dix-neuf migrations et un calcul de points déjà posé en SQL. On a conservé ces pièces. La suite a demandé du travail, mais elle n’a pas commencé par une page blanche.

Si tu hésites aujourd’hui à quitter Lovable, voilà la première question que je te poserais : qu’est-ce que ton produit possède déjà, hors de l’interface qui l’a généré ? Elle se découpe en trois :

• Où vit le backend ? Ton propre Supabase, Lovable Cloud ou une plateforme qui n’exporte pas sa logique : la réponse change le chiffrage avant même qu’on ouvre le code.
• Qu’est-ce qui tourne sans l’éditeur ? Le dépôt se construit-il, les migrations rejouent-elles sur une base vide, une sauvegarde a-t-elle été restaurée au moins une fois ?
• Qui refuse vraiment un accès ? Une règle exécutée côté serveur ou dans la base, ou un bouton grisé dans l’interface.

L’étude de cas GoPronos raconte l’application iOS et Android, les règles du jeu et la publication sur les stores. Ici, je prends la décision d’avant : rester, sortir le code, migrer les données, ou reconstruire une partie.

Les signaux qui disent « garder »

Petite précision avant de commencer : les trois pages d’éditeur que je cite dans ce guide — la doc Git de Lovable, Lovable Cloud et le manuel Bubble — je les ai relues le 5 novembre 2026, et aucune n’affiche de date de révision. Si tu lis ça dans six mois, revérifie.

La documentation Git de Lovable permet d’exporter le code vers GitHub et de le synchroniser dans les deux sens. C’est une vraie porte de sortie pour le front : tu peux lire le dépôt, faire travailler quelqu’un dessus et le déployer ailleurs. Sur GoPronos, le React existant a servi de point de départ, au lieu d’être remplacé pour le principe.

Le truc, c’est qu’un dépôt n’emporte pas les comptes utilisateurs, les fichiers, les fonctions serveur ni l’histoire de la base. Je demande donc où vit le backend avant de chiffrer quoi que ce soit. Le nom « Lovable » sur la page d’accueil du projet ne répond pas : deux prototypes qui se ressemblent à l’écran peuvent demander des reprises très différentes.

Si tu as connecté ton propre projet Supabase, le code et la base sont déjà deux choses distinctes. Tu peux reprendre le développement sans déplacer d’abord les données. Ça n’enlève ni l’audit des accès ni la dette du prototype ; ça évite simplement d’ajouter une migration de base à un chantier qui n’en a peut-être pas besoin.

C’était le cas à garder sur GoPronos : le dépôt compte 293 commits depuis l’import du prototype, 53 migrations dont 19 héritées de Lovable et 78 policies RLS. Le calcul des points était déjà en SQL et ces migrations décrivaient une base réellement utilisée par l’app. Les garder a évité de refaire une logique métier qui marchait. Alors je teste toujours ce scénario-là en premier : exporter le code, reprendre le dépôt et laisser la base en place. Tu corriges et tu testes sans empiler migration de données, authentification et hébergement dans le même chantier.

Les signaux qui disent « repartir »

Avec Lovable Cloud, le backend intégré vit chez Lovable. L’éditeur indique qu’il ne déplace pas le projet vers ton propre Supabase en une étape : il faut exporter la base et la restaurer dans le nouveau projet, déplacer les fichiers et le code, puis reconfigurer l’authentification, les secrets et les services externes. Le code reste exportable, mais sa sortie et celle de la base ne sont pas le même geste.

La différence saute encore plus aux yeux avec Bubble. Bubble explique que les données et le design peuvent sortir, mais que sa logique applicative ne s’exporte pas comme un programme exécutable ailleurs. Du coup, un devis de « migration no-code » identique pour Bubble et pour Lovable mélange un portage possible avec une reconstruction de logique, et ces deux-là n’ont pas le même prix. Ce sont des reconstructions délimitées : ni l’une ni l’autre n’est une raison de jeter les données, le design ou tout le front.

L’autre signal, c’est une chaîne de migrations qui ne rejoue pas. Sur SimplyJury, 13 migrations sur 36 échouaient sur une base vide et 11 tables sur 25 étaient absentes de la chaîne. L’hébergeur gratuit du projet ne faisait aucune sauvegarde : ces migrations étaient le seul chemin pour reconstruire la base si elle tombait.

Une chaîne de migrations qui ne rejoue pas sur base vide, sans sauvegarde à côté, c’est un produit qui n’a plus de copie.

Le coût de rester compte aussi. Si chaque modification casse une autre page, si personne n’a accès à une sauvegarde, ou si un client sérieux demande une isolation que le produit ne sait pas démontrer, tu paies déjà la reprise. Mais si le produit tourne et que le défaut est localisable, une migration générale ajoute du risque sans enlever le défaut prioritaire.

Même quand je reconstruis, c’est par morceaux. Sur GoPronos, le dé-Lovablage a commencé le 22 mai 2026 et a tenu en 40 commits, dans une frontière précise. Le calcul des points est resté en base, là où il était déjà. Un fichier scoring.ts côté client est conservé, avec ses tests, mais il ne sert qu’à afficher un score à l’écran : il ne décide de rien. Voilà le genre de ligne que je préfère écrire dans un devis, plutôt que « on refait proprement ».

Ce que lit un audit avant de chiffrer une reprise

C’est le travail d’un audit technique. Je pars du dépôt et de trois parcours réels : créer un compte, faire l’action principale, retrouver son résultat. Pour chacun, je note ce qui dépend du front, d’une fonction serveur, d’une table, d’un fournisseur externe ou d’une configuration de déploiement. En gros, ça me dit ce que je peux reprendre seul et ce qui doit bouger d’un bloc. C’est aussi la question que pose toute architecture technique de SaaS : ce qui se défait facilement, et ce qui ne se défait pas.

Ensuite, je vérifie quatre points de continuité :

• le dépôt se construit hors de l’éditeur ;
• les migrations passent sur une base de test vide ;
• une sauvegarde existe, et quelqu’un l’a restaurée au moins une fois ;
• les secrets sont accessibles au propriétaire du produit.

Une réponse manquante n’impose pas une réécriture, mais elle change le devis. Avant ce devis, je veux le dépôt, l’accès au backend et le chemin de déploiement. Je regarde ce qui se sauvegarde, ce qui se restaure, qui a le droit de toucher quelles données, et comment on publie un correctif.

À la fin, je rends un ordre : ce qui peut rester, ce qu’il faut corriger avant d’ouvrir davantage, ce qui peut attendre. J’ai appliqué la même discipline sur SimplyJury, un MVP existant qui ne venait pas de Lovable : la stack est restée Next.js, Vercel et Supabase, et les corrections sont parties en lots. C’est le même travail de découpage que pour définir un MVP, sauf qu’ici le produit existe déjà et qu’il a des utilisateurs. Une fois posé, cet ordre continue de servir : c’est la liste de départ d’une TMA, parce qu’un produit repris est un produit qui recommence à vivre et à bouger.

La sécurité d’abord : ce que l’interface ne protège pas

Sur GoPronos, les règles de visibilité des pronostics, leur fermeture au coup d’envoi et le rôle de chacun devaient être vérifiés côté base. Le prototype avait déjà le calcul des points au bon endroit ; il fallait compléter la frontière autour. Une correction importante n’impose donc pas de changer d’outil, de langage ou de modèle de données.

Quand j’ouvre un MVP, je sépare ce qui relève du parcours affiché et ce qui relève de l’autorisation réelle. Un bouton grisé après l’échéance aide le joueur à comprendre l’écran. Seule une règle exécutée côté serveur ou dans la base refuse vraiment une écriture tardive, et si elle manque, elle part dans le premier lot. Une politique d’accès activée dans la base n’est d’ailleurs pas une politique d’accès exécutée : les deux se ressemblent vues du tableau de bord, et l’app continue d’afficher les bons écrans aux bonnes personnes.

La sortie ne se mesure donc pas en nombre de politiques écrites. Sur une reprise, j’ai posé 28 attentes testées sous un rôle sans BYPASSRLS, ce qui doit être autorisé et surtout ce qui doit être refusé. C’est ça, le livrable : savoir si le compte A peut lire ou modifier quelque chose qui appartient au compte B, et pouvoir le rejouer à chaque déploiement. Ça ne suppose pas qu’une application créée avec Lovable est vulnérable par nature : sur asap.cool, mon propre produit, l’isolation des données a aussi demandé des corrections et des tests. Le détail des scénarios que je rejoue est dans l’article sur la sécurité d’un MVP no-code.

Ce que je ne ferais pas

• Promettre une sortie rapide quand les migrations ne rejouent pas sur une base vide : c’est promettre une sortie qu’on ne peut pas rejouer.
• Chiffrer pareil une reprise Bubble et une reprise Lovable : l’une est un portage, l’autre une reconstruction de logique.
• Empiler migration de données, authentification et hébergement dans le même chantier quand le backend peut rester en place.
• Détruire des données dans une passe de correctifs quand il n’y a pas de sauvegarde. Sur SimplyJury, j’ai renoncé à une migration : un ALTER échoue si une seule ligne historique sort de la liste, et les migrations s’exécutent au déploiement.

Délais et prix d’une reprise

Je commence presque toujours par un audit technique : compte deux semaines entre l’accès au dépôt et la restitution, et de 350 à 750 € selon la taille du produit. Tu repars avec l’ordre dont je parle plus haut, que tu me confies la suite ou non.

La reprise elle-même se chiffre de 350 à 2 500 €, avec un montant définitif fixé après notre appel. Sa durée va de quelques semaines à plusieurs mois. Elle dépend moins de l’outil qui a généré le MVP que de ce que l’audit a trouvé côté backend, migrations et accès.

Du coup, la meilleure réponse à « dois-je tout jeter ? », c’est souvent « montre-moi ce que tu as ». Un export Git, un accès au backend et quelques parcours métier suffisent. Ça ne donne pas encore le prix final, mais ça sépare une correction, une reprise du code et une migration de données. C’est cette séparation qui évite de payer trois fois la même application.

Moi, je garde ce qui tient et je fais prouver ce qui protège. GoPronos avait des migrations et un calcul de points qui méritaient de survivre à Lovable ; son étude de cas raconte ce qu’on a construit ensuite. Si ton MVP commence à servir de vrais utilisateurs et que tu hésites entre le prolonger et tout refaire, je peux établir cet ordre avec toi dans le cadre d’une reprise de MVP no-code.