Vous avez lancé votre application avec Lovable ou Bolt. Les premières semaines étaient prometteuses : l'IA générait des écrans en quelques minutes, le prototype tournait, les premiers retours utilisateurs arrivaient. Puis quelque chose a changé. Un bug que l'IA corrige en en créant trois nouveaux. Des crédits qui disparaissent à une vitesse inquiétante. Une fonctionnalité critique qui reste bloquée depuis deux semaines. Et la question qui finit toujours par se poser : est-ce qu'il faut tout recommencer ou peut-on encore sauver ça ?
La bonne nouvelle : dans la grande majorité des cas, le projet est récupérable. La mauvaise : il faut savoir quoi regarder avant de décider comment intervenir.
Pourquoi Lovable et Bolt finissent par coincer
Ces outils font quelque chose de remarquable pour les phases initiales. Ils transforment une description en prose en code React fonctionnel, en quelques secondes. Pour valider une idée, montrer un prototype à des investisseurs ou tester un flux utilisateur, c'est imbattable.
Le problème n'est pas l'outil en lui-même. C'est que le modèle de travail qui l'alimente a une limite structurelle : après 15 à 20 itérations, le contexte se dégrade. L'IA commence à "oublier" les décisions prises au début du projet. Elle répare une chose en cassant une autre. Les utilisateurs de Bolt rapportent des sessions où un seul bug d'authentification a consommé plus de 20 millions de tokens sans jamais être résolu correctement. Chez Lovable, le même phénomène se traduit par une boucle de corrections qui vide les crédits sans avancer.
Ce n'est pas un bug de la plateforme. C'est une limite de l'approche : ces outils sont taillés pour la génération, pas pour la maintenance et l'évolution d'un projet complexe.
Audit rapide : ce que vaut votre code actuel
Avant toute décision, il faut regarder ce que vous avez. Lovable génère du React + TypeScript + Tailwind CSS, avec Supabase comme backend par défaut. Bolt produit des stacks similaires, souvent React ou Vue, avec une logique backend intégrée. Dans les deux cas, le code est exportable et standard.
Un audit sérieux couvre quatre axes :
La logique métier. Est-elle bien isolée dans des fonctions ou des hooks dédiés, ou est-elle dispersée dans les composants UI ? Un code généré par IA mélange souvent les deux, ce qui rend toute modification risquée.
La sécurité des données. Les projets Supabase générés automatiquement ont régulièrement des Row Level Security (RLS) mal configurées, voire absentes. Une vérification rapide des règles d'accès est non négociable avant toute mise en production réelle.
La structure de la base de données. Les tables et relations générées par l'IA sont souvent fonctionnelles pour le prototype mais difficiles à faire évoluer. Colonnes mal nommées, relations manquantes, absence d'index sur les colonnes filtrées : les problèmes de performance arrivent toujours au mauvais moment.
La dette de composants. Lovable génère parfois 40 à 60 composants pour une application de taille moyenne. Sans architecture claire, refactorer devient coûteux. Il faut cartographier rapidement ce qui peut être réutilisé et ce qui doit être réécrit.
Comment exporter votre code avant de faire quoi que ce soit
La première étape avant toute intervention externe : sortir le code de la plateforme et le mettre sous contrôle de version.
Depuis Lovable, la connexion GitHub est disponible sur tous les plans. Chaque sauvegarde dans l'éditeur Lovable est poussée vers votre repository. L'export inclut la structure React complète, la configuration Supabase, le routing, les dossiers de composants. Une fois sur GitHub, n'importe quel développeur peut cloner, installer les dépendances et lancer le projet localement. Le stack est suffisamment standard pour qu'il n'y ait pas de réaprentissage particulier.
Depuis Bolt, l'export se fait depuis l'interface : icône de projet en haut à gauche, puis Export > Download. Vous récupérez une archive ZIP avec l'intégralité du code. La subtilité : les services externes (base de données, variables d'environnement) ne sont pas inclus dans l'export. Il faudra reconfigurer ces connexions manuellement. Bolt permet aussi d'ouvrir directement le projet dans l'IDE StackBlitz, ce qui simplifie la transition vers un environnement de développement classique.
Une fois le code sur GitHub et versionné, vous avez un point de départ propre. Vous pouvez reprendre le travail dans Cursor ou VS Code, intégrer des revues de code, et arrêter de dépendre de la fenêtre de contexte d'une IA pour faire évoluer votre produit.
Ce qui est récupérable, ce qui ne l'est pas
L'expérience sur une vingtaine de projets repris montre un pattern assez constant.
Ce qui se récupère bien en général : l'interface utilisateur (les composants React sont réutilisables à 70-80 %), la logique de routing, les intégrations simples (formulaires, emails, webhooks). Si l'IA a bien compartimenté les responsabilités dans le code, on peut greffer du nouveau comportement sans tout toucher.
Ce qui nécessite presque toujours une réécriture : l'authentification et la gestion des sessions (les implémentations générées sont souvent partielles ou peu sécurisées), les workflows complexes avec plusieurs états ou conditions imbriquées, et les performances sur des données volumineuses (les requêtes générées ne sont pas optimisées pour la charge).
Ce qui est irrécupérable : rare, mais ça existe. Si le modèle de données est fondamentalement incohérent avec le besoin métier, si les relations entre tables sont impossibles à faire évoluer sans tout migrer, la réécriture partielle du backend peut être plus rapide qu'une refactorisation incrémentale.
Les scénarios de reprise possibles
Il n'y a pas un seul chemin, et le choix dépend de l'état du code et de l'urgence produit.
Reprise partielle. Un développeur intervient sur les parties bloquantes (authentification, sécurité, performances) tout en laissant le reste du code en l'état. C'est l'option la plus rapide et la moins coûteuse. Elle convient quand le cœur de l'application fonctionne et que seuls quelques points précis posent problème. Durée typique : 2 à 4 semaines.
Refactorisation progressive. Le développeur reprend le projet en main complètement, module par module. Le produit continue d'évoluer pendant la refactorisation. C'est l'approche qui maximise la continuité, mais qui demande une bonne discipline pour ne pas introduire de régression. Durée typique : 6 à 12 semaines selon la taille du projet.
Réécriture ciblée. Le front reste intact, le backend est réécrit from scratch avec une architecture propre. Utile quand la logique métier est correcte côté UI mais que le backend est un nid de problèmes. Moins traumatisant qu'une réécriture totale, plus solide qu'une rafistole permanente.
Les budgets réels en 2026
Les projets issus de Lovable ou Bolt se répartissent en trois catégories lors d'une reprise.
Pour un projet simple (landing page avec quelques formulaires, logique de base) : une reprise propre coûte entre 3 000 et 8 000 euros HT. Le développeur passe 1 à 2 semaines à auditer, sécuriser et documenter. La plupart des bugs sont résolus dans les 5 premiers jours.
Pour une application avec authentification, rôles et données : comptez 8 000 à 20 000 euros HT pour une reprise sérieuse. L'authentification seule représente souvent 30 % du travail. Si Supabase est mal configuré côté RLS, il faut réécrire toutes les règles d'accès et vérifier chaque endpoint.
Pour un SaaS avec facturation, multi-tenancy et intégrations tierces : la fourchette passe à 20 000 à 50 000 euros HT. À ce niveau, une réécriture partielle du backend est presque toujours plus rentable qu'une refactorisation du code IA.
Ces chiffres sont plus bas que les estimations de repartir de zéro, qui démarrent rarement en dessous de 40 000 euros pour un produit équivalent. La logique métier encodée dans les composants Lovable a une valeur réelle, même imparfaite.
Travailler avec un développeur qui connaît ces stacks
La reprise d'un projet IA demande un profil spécifique. Un développeur React expérimenté mais jamais confronté à du code généré par IA peut perdre beaucoup de temps à comprendre les patterns inhabituels. À l'inverse, quelqu'un qui a déjà travaillé sur des reprises Lovable ou Bolt sait directement où chercher les problèmes récurrents.
Les points à vérifier lors du briefing : est-ce qu'il a déjà exporté et audité du code Lovable ou Bolt ? Sait-il comment Supabase RLS fonctionne ? Peut-il montrer des exemples de projets repris ou refactorisés ? Un audit initial d'une journée est souvent le meilleur moyen de valider l'expertise avant de s'engager sur un contrat plus long.
Chez Noxcod, on a traité une vingtaine de ces reprises depuis 2025. Le diagnostic initial est systématiquement le même point de départ : comprendre ce que l'IA a bien fait (et ne pas le jeter), identifier précisément ce qui bloque la croissance, et proposer un plan d'action réaliste. Le code généré par IA n'est pas du mauvais code par principe. C'est du code qui a besoin d'un regard humain pour passer de "ça marche en démo" à "ça tient en production".
Si vous avez un projet Lovable ou Bolt qui stagne, la première étape est souvent un audit technique de votre application. En une journée, on peut vous dire ce qui vaut la peine d'être conservé et ce qui doit être refait. Sans engagement, sans devis préfabriqué.
FAQ
Peut-on continuer à utiliser Lovable ou Bolt après la reprise par un développeur ?
Oui, dans certains cas. Si le code a été exporté sur GitHub et que le développeur a mis en place une architecture propre, vous pouvez continuer à itérer avec Lovable pour les nouvelles fonctionnalités non critiques, pendant que le développeur gère le backend et les parties sensibles. L'important est de ne plus utiliser l'IA pour toucher à l'authentification, la gestion des paiements ou les workflows complexes.
Combien de temps dure un audit de projet Lovable ?
Un audit sérieux prend 1 à 2 jours. Il couvre la structure du code, la configuration Supabase, les dépendances, les failles de sécurité évidentes, et une estimation du travail de remise en état. Un audit bâclé en 2 heures ne sert à rien : il manquera systématiquement les problèmes de base de données et de sécurité.
Mon projet Bolt n'a pas de versioning. C'est grave ?
C'est récupérable, mais c'est la première chose à corriger. Exportez le code en ZIP, créez un repository GitHub, faites un premier commit. Vous avez maintenant un historique. Pour la suite, chaque modification passe par Git. Travailler sans versioning sur un projet en production, c'est avancer sans filet : la prochaine erreur de l'IA pourrait écraser des semaines de travail.
Faut-il réécrire complètement un projet Lovable ou Bolt pour aller en production ?
Rarement. Dans 70 à 80 % des cas, l'interface utilisateur générée est correcte et réutilisable. Ce qui bloque la production, c'est presque toujours la sécurité du backend et la robustesse des fonctionnalités critiques, pas le design ou la navigation. Une réécriture complète est justifiée quand le modèle de données est fondamentalement incohérent avec le besoin, ce qui arrive surtout sur les projets où les spécifications ont beaucoup changé pendant le développement IA.
