Vous avez construit votre application avec Lovable. Elle a des utilisateurs, peut-être des clients qui paient. Et depuis quelque temps, avancer devient pénible : les demandes à l'IA tournent en rond, les bugs reviennent, vous n'osez plus toucher à certaines parties. Vous vous demandez s'il est temps de faire reprendre l'application par un développeur.
La réponse courte : le bon moment n'est pas quand l'application est « finie » ou « cassée », mais quand le temps que vous passez à la maintenir dépasse celui que vous passez à la faire avancer, ou quand une panne vous coûterait plus cher que l'accompagnement. Passer la main ne veut pas dire jeter ce qui a été fait. Le code produit par Lovable est du code standard, qu'un développeur peut reprendre, à condition que la transition soit préparée.
Cet article vous aide à décider, compare honnêtement les trois options possibles, et liste ce qu'il faut réunir pour qu'un développeur reprenne vite et sans mauvaise surprise.
Les signes qu'une application Lovable a atteint son plafond
Aucun de ces signes ne suffit seul. C'est leur accumulation qui compte.
- Les corrections tournent en rond. Vous demandez une correction, elle en casse une autre. Plusieurs sociétés de reprise décrivent ce schéma, par exemple Sigosoft ou IndiaNIC, qui l'attribuent à une logique copiée à plusieurs endroits et à l'absence de tests.
- Vous ne comprenez plus ce que fait l'application. Vous savez ce qu'elle doit faire, mais plus comment elle le fait, ni ce qui se passerait si vous changiez telle règle métier.
- Vous avez des données sensibles ou des paiements. Dès qu'une erreur peut exposer les données d'un client ou fausser une facture, l'enjeu change de nature.
- Une évolution demandée dépasse ce que l'outil fait bien. Une intégration avec un logiciel métier, des traitements lourds, des rôles et droits complexes.
- Votre temps a plus de valeur ailleurs. Si vous passez vos soirées à déboguer au lieu de vendre ou de gérer votre entreprise, c'est déjà un coût, même s'il n'apparaît dans aucune facture.
À l'inverse, si l'application est simple, peu utilisée, sans données sensibles, et que vous avancez encore sans trop de casse, rien ne presse.
Trois options : continuer seul, être accompagné, déléguer
Il n'y a pas que deux choix, « tout seul » ou « tout confier ». En pratique, il y en a trois.
Continuer seul, avec un socle solide
Vous gardez la main sur les évolutions avec l'IA, mais vous ajoutez ce qui manque autour : sauvegardes, surveillance, tests automatiques qui tournent à chaque modification. C'est adapté si vous avancez encore bien et voulez surtout éviter les accidents. C'est ce que couvre l'offre Autopilote.
Continuer, mais accompagné
Vous continuez à produire avec l'IA, et un développeur senior passe régulièrement : il relit, corrige ce qui est risqué, vous apprend à mieux cadrer vos demandes, et vous dit quand une partie doit être reprise à la main. C'est le format Copilote, une journée par mois.
Déléguer le développement
Le développeur prend en charge l'application : il stabilise l'existant, priorise avec vous, et développe les évolutions. Vous restez décisionnaire sur le produit, mais vous ne codez plus. C'est l'option à envisager quand les signes ci-dessus s'accumulent, que l'application porte une part importante de votre activité, ou que vous n'avez plus le temps. C'est le rôle de l'offre Pilote.
Si vous hésitez aussi sur le besoin d'un regard plus large (choix techniques, prestataires, feuille de route), l'article CTO à temps partagé en PME peut vous aider à situer votre besoin.
Préparer la reprise par un développeur : ce qu'il lui faut
Une reprise qui démarre bien, c'est une reprise où le développeur n'attend pas trois semaines des accès. Voici ce qu'il faut réunir.
Le code, dans un dépôt GitHub qui vous appartient
Par défaut, le code d'un projet Lovable est stocké et géré sur la plateforme. Lovable permet de le synchroniser avec GitHub, et sa documentation indique que c'est l'option prévue quand vous voulez travailler avec des développeurs ou déplacer le projet. La synchronisation fonctionne dans les deux sens : ce qui est modifié dans Lovable arrive sur GitHub, et ce qui est poussé sur la branche active revient dans Lovable. Deux précautions données par Lovable : ne supprimez jamais le dépôt GitHub, cela arrête la synchronisation, et Lovable ne travaille que sur une seule branche à la fois.
Vérifiez que le dépôt est sur un compte GitHub de votre entreprise, pas sur celui d'un freelance ou d'un ancien associé.
Les accès à tous les services
Faites la liste de tout ce que l'application utilise, et vérifiez que chaque compte est au nom de l'entreprise :
- le projet Lovable lui-même ;
- la base de données (souvent Supabase) ;
- le nom de domaine et les DNS ;
- le paiement (Stripe ou autre) ;
- l'envoi d'e-mails ;
- les clés d'API externes, dont celles des services d'IA.
Donnez ensuite au développeur un accès nominatif, plutôt que vos propres identifiants. Vous pourrez le retirer proprement plus tard.
Ce que vous savez et que le code ne dit pas
C'est la partie la plus précieuse, et la plus souvent oubliée. Une page suffit :
- à quoi sert l'application, qui l'utilise, et quels sont les trois parcours qui ne doivent jamais casser ;
- les règles métier importantes (calcul de prix, droits d'accès, statuts) ;
- les bugs connus et les contournements que vous utilisez ;
- ce que vous voulez faire dans les six prochains mois.
Ce que le développeur fera les premières semaines
Méfiez-vous d'un développeur qui, sans avoir ouvert le code, annonce qu'il faut tout réécrire, ou au contraire que tout va bien. Une reprise sérieuse commence par un état des lieux.
- Sécuriser. Vérifier les sauvegardes, les accès, les règles de sécurité de la base, les secrets exposés. C'est la priorité, avant toute évolution.
- Comprendre. Lire le code, repérer les parties dupliquées, le code mort, les zones fragiles. Notre article sur l'audit d'une application codée avec l'IA détaille ce que cet examen doit couvrir.
- Protéger. Écrire des tests sur les parcours critiques, pour que les prochaines modifications ne cassent pas l'existant.
- Décider : corriger ou reconstruire. Si le code est raisonnablement organisé, on corrige et on fait évoluer. Si la duplication est partout et qu'une grande partie du code ne sert plus, une reconstruction progressive, partie par partie, peut se justifier, comme le décrit Rocking Tech. Cette décision doit reposer sur ce que montre le code, et vous être expliquée.
Dernier point : reprendre l'application ne veut pas forcément dire quitter Lovable tout de suite. On peut garder la plateforme un temps, ou migrer l'hébergement plus tard. Si cette question se pose, l'article Héberger une application Lovable ailleurs explique ce que l'export oublie.
Questions fréquentes
Un développeur peut-il travailler sur du code généré par Lovable ?
Oui. Le code exporté est du code d'application web classique. Le vrai sujet n'est pas l'outil qui l'a produit, mais son organisation : plus il y a de logique copiée et moins il y a de tests, plus la reprise demande du temps au départ.
Pourrai-je continuer à utiliser Lovable après la reprise ?
C'est possible grâce à la synchronisation GitHub dans les deux sens. Il faut alors se mettre d'accord sur qui modifie quoi et sur quelle branche, pour ne pas se marcher dessus.
Faut-il tout réécrire ?
Pas par principe. Beaucoup d'applications se stabilisent avec des tests, des corrections ciblées et un regroupement progressif du code dupliqué. La réécriture se discute au cas par cas, après examen.
Combien de temps prend une reprise ?
Cela dépend de la taille de l'application, de son état et de la qualité des accès que vous fournissez. Un développeur sérieux vous donnera une estimation après avoir regardé le code, pas avant.
Si vous sentez que votre application Lovable plafonne, parlons-en. On regarde ensemble où elle en est, et je vous dis franchement laquelle des trois options me paraît la plus adaptée, y compris si c'est de continuer seul.