Reprise de projet Lovable : ce que personne ne vous dit

Vous avez créé votre prototype avec Lovable en quelques heures. L'app avait l'air bien. Vous l'avez montrée à vos premiers utilisateurs, ils ont aimé le concept. Vous vous êtes dit : "Il suffit de corriger quelques bugs et on est bons."

Sauf que trois mois plus tard, vous êtes toujours en train de corriger des bugs. Et chaque correction en crée deux nouveaux.

Ce n'est pas votre faute. C'est la nature même du vibe coding.

Ce que Lovable fait très bien

Soyons honnêtes : Lovable est un outil remarquable. En quelques heures, vous obtenez un prototype fonctionnel avec une UI propre. Pour valider une idée auprès de vrais utilisateurs, c'est imbattable.

Le problème, ce n'est pas Lovable. C'est de croire que le prototype peut aller en production tel quel.

Ce que le code Lovable a vraiment sous le capot

J'ai repris plusieurs projets Lovable. Voici ce que je trouve systématiquement :

Pas de gestion d'erreurs

Quand tout va bien, l'app fonctionne. Mais dès qu'une API renvoie une erreur, qu'un utilisateur fait quelque chose d'imprévu, ou que la connexion est lente... crash silencieux. L'utilisateur voit un écran blanc ou des données incohérentes.

Pas de tests

Zéro test automatisé. Ça veut dire que chaque modification peut casser n'importe quelle autre partie de l'app. Et vous ne le saurez qu'en production, quand un utilisateur vous envoie un screenshot de bug.

Architecture inexistante

Des composants géants de 500 lignes qui mélangent la logique métier, l'affichage et les appels API. Pas de séparation des responsabilités. Résultat : impossible de modifier une fonctionnalité sans toucher à tout le reste.

State management chaotique

Les données se perdent entre les écrans. Un utilisateur remplit un formulaire, navigue, revient : tout a disparu. Ou pire : les données d'un utilisateur s'affichent chez un autre.

Sécurité basique

Pas de validation côté serveur, pas de rate limiting, tokens stockés en clair. Pour un prototype, ça passe. Pour une app en production avec des données utilisateur, c'est un risque juridique.

Le cas Vread : 3 refus Apple, puis App Store

Tanguy, fondateur de Vread, avait exactement ce problème. Son app de suivi de lecture, créée avec Lovable, fonctionnait visuellement mais était instable.

Apple a refusé l'app 3 fois : crashs au lancement, non-respect des guidelines, problèmes de performance.

Ce qu'on a fait

Audit (3 jours) : On a analysé tout le code. Identifié 47 bugs critiques, 12 failles de sécurité, et une architecture qui rendait toute correction risquée.

Reprise technique (3 semaines) : Refactoring de l'architecture React Native, correction de la gestion d'état, ajout d'error boundaries et de tests sur les parcours critiques.

Refonte UX/UI (1 semaine) : Harmonisation du design, système de composants cohérent.

Résultat : App validée par Apple du premier coup après la reprise. Code maintenable, testable, prêt pour les futures évolutions.

→ Lire l'étude de cas complète

Les 5 signaux que votre projet Lovable a besoin d'une reprise

1. Chaque modification crée de nouveaux bugs. Vous corrigez un formulaire, le panier casse. Vous ajoutez un écran, la navigation plante. C'est le signe d'une architecture couplée.

2. Apple ou Google refusent votre app. Les stores ont des critères stricts : pas de crashs, pas de contenus chargés sans placeholder, performances correctes. Le code Lovable ne passe souvent pas ces filtres.

3. Les utilisateurs signalent des bugs que vous ne pouvez pas reproduire. Sans logging et sans tests, vous êtes aveugle. Les bugs intermittents sont les pires.

4. Vous avez peur de toucher au code. Quand modifier une ligne vous stresse, c'est que l'architecture ne vous protège pas. Un bon code est un code qu'on peut modifier en confiance.

5. Le temps de développement augmente au lieu de diminuer. Avec un code bien structuré, les fonctionnalités s'ajoutent de plus en plus vite. Avec de la dette technique, c'est l'inverse.

Combien ça coûte ?

Soyons transparents :

• Audit technique : 1 500€ - 3 000€ (3-5 jours). Vous savez exactement ce qui ne va pas et combien ça coûtera à corriger.
• Reprise & stabilisation : 5 000€ - 15 000€ (2-8 semaines). On garde ce qui marche, on corrige ce qui casse.
• Refonte complète : à partir de 10 000€ (2-4 mois). Quand le code est irrécupérable.

Dans 70% des cas, on n'a pas besoin de tout refaire. On garde la base et on corrige les parties critiques.

La bonne stratégie : prototype + développeur

Lovable (ou Bolt, Cursor, V0) n'est pas le problème. Le problème, c'est de s'arrêter au prototype.

La bonne stratégie :

1. Valider l'idée avec Lovable (budget : 0-50€)
2. Faire reprendre le code par un développeur senior (budget : 5 000-15 000€)
3. Itérer en production avec un code maintenable (budget : au fur et à mesure)

C'est moins cher que de tout faire développer de zéro. Et beaucoup moins cher que de perdre 6 mois à essayer de patcher du code vibe-codé.

→ Voir le service Vibe Coding Cleanup

→ Lovable vs Développeur : quand faire le switch ?