Vous avez un prototype Lovable qui fonctionne. L’interface est là, les premiers parcours sont testables, peut-être même que des utilisateurs l’ont déjà essayé.

Puis vient la question qui bloque souvent la suite : faut-il reprendre le code ou tout refaire ?

La réponse la plus honnête est rarement « tout garder » ou « tout jeter ». Un projet Lovable se juge par parties. Certaines décisions produit sont déjà validées. Certaines pages peuvent être conservées presque telles quelles. D’autres éléments, notamment les données, les permissions et les déploiements, demandent une reprise sérieuse avant d’accueillir de vrais utilisateurs.

L’objectif n’est donc pas de défendre le code existant à tout prix. C’est de prendre une décision qui protège le produit, le budget et le calendrier.

Lovable a déjà produit quelque chose de précieux

Un prototype généré avec Lovable n’est pas seulement un dossier de code. Il contient souvent plusieurs mois de réflexion condensés en quelques jours :

une première hiérarchie des écrans ;
des parcours utilisateurs concrets ;
des choix de vocabulaire métier ;
une vision des données nécessaires ;
des hypothèses déjà testées avec des prospects ou une équipe.

Même si le code doit être largement repris, cette matière a de la valeur. Repartir de zéro peut donner l’impression de repartir proprement, mais cela oblige aussi à reconstruire des décisions qui existent déjà, parfois sans s’en rendre compte.

La première étape consiste donc à séparer la valeur produit de la qualité technique. Une interface imparfaite peut être corrigée. Une architecture difficile à comprendre peut être reprise. En revanche, une règle métier mal comprise ou une donnée déjà incohérente peut modifier profondément la stratégie de reconstruction.

Les quatre scénarios possibles

Avant de parler de réécriture, il faut préciser ce que l’on entend par « reprendre le code ». Il existe au moins quatre niveaux d’intervention.

1. Nettoyer et sécuriser l’existant

Le prototype est globalement compréhensible. Les principaux parcours fonctionnent. Il manque surtout des tests, une configuration de production, une gestion d’erreurs cohérente ou quelques corrections de structure.

Dans ce cas, une reprise ciblée suffit. On documente les points sensibles, on corrige les défauts prioritaires, on ajoute les protections nécessaires et on prépare le déploiement.

2. Reprendre une partie du projet

Les écrans et une partie de la logique sont exploitables, mais certains modules sont trop fragiles. Le modèle de données, les rôles utilisateurs, les webhooks ou la facturation peuvent nécessiter une reconstruction locale.

On conserve alors les éléments qui accélèrent réellement la suite et on remplace les fondations qui empêchent de tester ou de faire évoluer le produit.

3. Migrer progressivement

Le prototype sert de référence fonctionnelle, mais la production se construit par étapes. On reprend un parcours, puis un autre, en faisant coexister temporairement l’ancien et le nouveau code.

Cette option convient quand le produit est déjà utilisé ou quand il est important de continuer à livrer pendant la reprise. Elle demande toutefois une stratégie claire pour éviter de maintenir deux systèmes trop longtemps.

4. Reconstruire le produit

Une reconstruction complète peut être nécessaire. Mais elle doit être motivée par des faits : impossibilité de vérifier les règles d’accès, données non récupérables, dépendances impossibles à maintenir, déploiement non reproductible ou architecture devenue incohérente après de nombreuses modifications.

Refaire le code n’est pas une preuve de sérieux en soi. C’est une décision coûteuse qui n’a de sens que si elle réduit un risque réel.

Ce qu’il faut examiner avant de décider

Un audit utile ne se contente pas de regarder si le code est « propre ». Il cherche à comprendre si le projet est maîtrisable.

Le projet peut-il être relancé par quelqu’un d’autre ?

Un premier signal simple est la reproductibilité. Une autre personne doit pouvoir récupérer le dépôt, installer les dépendances, configurer les variables nécessaires et lancer le projet sans dépendre d’une suite de manipulations connue d’une seule personne.

Il faut aussi vérifier ce qui se passe entre l’environnement local et la production. Les deux environnements utilisent-ils les mêmes services ? Les migrations de base de données sont-elles identifiées ? Le déploiement peut-il être relancé après une erreur ?

Si personne ne peut répondre à ces questions, le problème est peut-être moins le code Lovable que l’absence de chaîne de livraison fiable.

Les règles métier sont-elles localisables ?

Une application peut avoir une apparence correcte tout en cachant une logique difficile à suivre. Il faut retrouver où sont gérés :

les statuts et transitions ;
les calculs importants ;
les permissions ;
les notifications ;
les intégrations externes ;
les validations côté serveur.

Si une modification d’écran risque de casser une règle métier située ailleurs, une reprise structurelle est souvent préférable à une succession de corrections rapides.

Les données sont-elles fiables et récupérables ?

Le schéma de données mérite une attention particulière. Les noms de tables et de champs ne sont pas le seul sujet. Il faut comprendre les relations, les contraintes, les doublons possibles, les valeurs historiques et les données sensibles.

Une base que l’on ne sait pas sauvegarder, migrer ou restaurer constitue un risque indépendant de la qualité des composants d’interface. Dans certains projets, il est possible de conserver l’interface tout en reconstruisant la couche de données. Dans d’autres, les données existantes sont tellement incertaines qu’il faut d’abord les inventorier avant de choisir une architecture.

Les accès sont-ils vérifiables ?

Chaque rôle doit pouvoir accéder uniquement à ce qui lui est destiné. Cela concerne l’interface, mais surtout les vérifications effectuées côté serveur et les règles appliquées à la base de données.

Un bouton masqué n’est pas une permission. Pour décider de conserver ou non un module, il faut pouvoir expliquer comment l’application protège les ressources quand un utilisateur appelle directement une route ou une API.

Les parcours critiques sont-ils testables ?

Il n’est pas nécessaire d’avoir une couverture de tests parfaite avant toute mise en production. En revanche, les parcours qui portent le risque principal doivent être vérifiables : création de compte, connexion, paiement, création d’un objet métier, invitation d’un utilisateur, export ou suppression de données.

Sans ce filet minimal, chaque reprise devient une nouvelle source d’incertitude. On ne sait plus si une correction a réglé un problème ou déplacé le problème ailleurs.

Une matrice simple pour prendre la décision

Voici une première grille de lecture. Elle ne remplace pas l’analyse du dépôt, mais elle aide à cadrer la discussion.

Élément	À conserver	À reprendre	À reconstruire
Écrans et navigation	Le parcours est compréhensible et cohérent	Les écrans fonctionnent mais sont difficiles à faire évoluer	L’interface ne correspond plus au produit validé
Logique métier	Les règles sont identifiées et testables	Les règles sont dispersées ou partiellement documentées	Les résultats sont incohérents et impossibles à expliquer
Données	Le modèle est compris, sauvegardé et migrable	Le modèle doit être nettoyé ou normalisé	Les données critiques ne sont pas fiables ou récupérables
Authentification et permissions	Les contrôles sont vérifiables côté serveur	Les rôles doivent être redéfinis	La sécurité ne peut pas être auditée correctement
Déploiement	Le déploiement est reproductible	Il faut revoir la configuration et l’observabilité	Le projet dépend d’un environnement impossible à reproduire

La bonne question n’est pas « est-ce que le code est joli ? ». C’est plutôt : « quelle partie puis-je modifier sans perdre le contrôle du produit ? »

Les signes qui justifient une reprise partielle

Une reprise partielle est souvent le scénario le plus réaliste lorsque :

l’interface permet déjà de valider le produit ;
le périmètre métier est encore en évolution ;
la base de données est récupérable mais mal structurée ;
les rôles et les permissions doivent être sécurisés ;
certaines intégrations sont fiables et d’autres non ;
les erreurs viennent surtout de quelques modules identifiés.

Dans cette situation, il faut éviter de réécrire tout le projet par réflexe. On peut isoler les éléments à risque, établir une frontière claire entre le code conservé et le code remplacé, puis avancer par parcours critiques.

Cette méthode permet aussi de vérifier les hypothèses au fil du travail. Un module qui semblait simple peut révéler une dépendance cachée. Un écran qui paraissait inutilisable peut au contraire devenir une bonne base après quelques corrections.

Quand reconstruire devient le choix raisonnable

La reconstruction complète est cohérente lorsque les fondations ne permettent plus de prendre de décision fiable. Par exemple :

personne ne sait quelles données sont réellement utilisées ;
les permissions reposent uniquement sur des éléments visuels ;
les changements récents ont créé des régressions impossibles à isoler ;
le déploiement dépend d’un compte personnel ou d’une configuration inconnue ;
les règles métier sont dupliquées avec des résultats différents ;
le produit a changé de périmètre et le prototype ne correspond plus aux parcours actuels.

Même dans ce cas, « reconstruire » ne signifie pas oublier le prototype. Les écrans, les retours utilisateurs, les cas limites et les erreurs déjà observées doivent alimenter la nouvelle version. Le prototype devient une source de connaissance, pas nécessairement une base technique.

Ce que doit livrer un vrai audit

Avant de demander plusieurs semaines de développement, vous devriez obtenir une réponse lisible sur trois listes :

À conserver : écrans, composants, logique ou données qui peuvent rester en place avec un risque acceptable.
À reprendre : éléments à corriger, documenter, tester ou isoler avant la production.
À reconstruire : fondations dont le risque est supérieur au bénéfice d’une conservation.

Cette analyse doit être accompagnée d’un ordre de priorité. Il ne sert à rien de refaire une page secondaire si l’authentification ou la migration des données n’est pas maîtrisée.

Elle doit aussi produire une trajectoire concrète : première version de production, risques restants, dépendances externes et estimation des étapes. Un audit qui se termine par « le code est mauvais » ne vous aide pas à décider. Un audit utile explique ce qui peut sortir, à quelles conditions et avec quel niveau de confiance.

Ma recommandation

Ne faites pas réécrire votre projet Lovable avant d’avoir fait cartographier ses parties. Commencez par les parcours critiques, les données, les permissions et le déploiement. Ce sont eux qui déterminent si l’on peut reprendre le projet sereinement.

Dans beaucoup de cas, la meilleure trajectoire est hybride : conserver la valeur produit et les éléments lisibles, reprendre les modules sensibles, puis reconstruire uniquement les fondations qui bloquent la production.

Dans mon article sur le passage d’un prototype à la production, je détaille les vérifications à faire avant d’ouvrir un prototype à de vrais utilisateurs. Et si vous voulez une décision précise sur votre dépôt, réservez un échange de 30 minutes avec TechSprint. Nous identifierons ce qui est récupérable, ce qui doit être sécurisé et la prochaine étape la plus raisonnable.

Fabrice Payet, fondateur de TechSprint, La Réunion.

Reprendre ou refaire le code d’un projet Lovable ?