App Lovable avec des utilisateurs : continuer seul, prendre un freelance ou passer par un studio ?

Votre application Lovable a ses premiers utilisateurs, ou va les avoir dans quelques semaines. Jusqu’ici, vous avez tout fait seul : les écrans, la base, les corrections, à coups de prompts. La question qui arrive maintenant n’est plus « est-ce que ça marche ? » mais « qui s’en occupe quand ça casse ? ». Trois réponses se présentent : continuer seul avec Lovable, prendre un développeur freelance, ou confier l’application à un studio.

Aucune n’est la bonne par principe. Chacune convient à une situation précise, et chacune a un coût caché, en risques et en temps plutôt qu’en euros. Nous avons repris une douzaine d’applications générées par IA pour les amener jusqu’à la production ; parmi elles, une application RH et une messagerie chiffrée interne d’entreprise qui cumulait de nombreuses failles de sécurité. Nous sommes un studio, donc juge et partie : cet article dit aussi quand nous ne sommes pas le bon choix.

Sept questions à vous poser avant de comparer

Avant de chercher un « développeur Lovable », regardez votre situation en face. Sept critères décident presque tout.

1. Les données et l’argent en jeu. Votre application stocke-t-elle des données personnelles sensibles (santé, RH, pièces d’identité, messages privés) ? Encaisse-t-elle des paiements ? Une faille sur une liste de recettes est gênante ; sur des fiches de paie, elle expose des données personnelles protégées par le RGPD.
2. Le nombre d’utilisateurs, et qui ils sont. Dix bêta-testeurs bienveillants pardonnent une panne. Cent clients qui paient, ou trois entreprises qui ont signé, non.
3. La fréquence des régressions. Si chaque prompt casse quelque chose ailleurs, le projet a dépassé ce que l’outil gère bien seul.
4. Les compétences internes. Quelqu’un dans l’équipe sait-il lire du code React et une règle SQL, même lentement ? Ou personne ne peut vérifier ce que l’IA ou un prestataire a fait ?
5. Le besoin de continuité. Si l’application tombe un vendredi soir, quelqu’un doit-il la relever avant lundi ? Un outil interne peut attendre ; un service que vos clients utilisent pour travailler, rarement.
6. Votre budget de temps. Combien d’heures par semaine pouvez-vous passer sur le produit technique sans sacrifier la vente, le recrutement ou la levée ?
7. La propriété du code et des comptes. Le dépôt GitHub, la base, l’hébergement, le nom de domaine, Stripe : tout est-il à votre nom, ou une partie dépend-elle d’un tiers ?

Continuer seul avec Lovable

Quand c’est le bon choix

Rester seul est raisonnable plus souvent qu’on ne le dit, à condition que les sept réponses aillent dans le même sens :

• l’application ne stocke pas de données sensibles et n’encaisse pas d’argent, ou le paiement passe entièrement par une page Stripe hébergée ;
• les utilisateurs sont peu nombreux et savent qu’ils testent un produit jeune ;
• les régressions restent rares et vous les voyez avant vos utilisateurs ;
• vous cherchez encore ce que le produit doit faire, et la vitesse d’itération compte plus que la solidité.

Payer pour solidifier un produit dont le périmètre changera le mois prochain, c’est couler du béton sous une tente. Continuez, mais faites trois choses : passez la check-list de sécurité Lovable et Supabase, connectez un dépôt GitHub dès maintenant, et vérifiez où vit votre base.

Ce dernier point a changé récemment. Le backend intégré de Lovable, Lovable Cloud, est activé par défaut ; la documentation recommande de connecter votre propre projet Supabase quand vous voulez la propriété directe du backend, et précise qu’il n’existe pas de migration en un clic entre les deux (page consultée le 12 octobre 2026). Plus la base grossit, plus ce passage demande de travail : mieux vaut le décider tôt.

Ce que ça coûte en risques et en temps

Le risque principal, c’est l’angle mort. Lovable génère du code qui fonctionne, mais personne ne relit les règles d’accès de la base ni ce que fait une fonction serveur appelée sans connexion. Les scanners de sécurité intégrés aident, mais la documentation de Lovable le dit elle-même : ils ne remplacent pas une revue de sécurité approfondie (page consultée le 12 octobre 2026).

Le deuxième risque est moins connu. L’historique de versions de Lovable est un vrai filet : chaque modification crée une version, et on peut revenir en arrière. Mais la documentation est explicite, revenir à une version restaure le code seulement, pas les données de la base (page consultée le 12 octobre 2026). Un prompt qui a modifié une table ou supprimé des lignes ne s’annule pas d’un clic. Sur le plan gratuit de Supabase, il n’y a pas non plus de sauvegarde automatique : elles sont quotidiennes à partir du plan Pro, avec sept jours d’historique, et n’incluent pas les fichiers du Storage (page consultée le 12 octobre 2026).

Côté temps, le coût est le vôtre. Chaque heure passée à négocier avec l’IA pour corriger une régression est une heure qui ne va pas à vos clients. Et les crédits consommés par ces allers-retours s’additionnent, comme nous l’avons détaillé dans notre article sur le prix d’une reprise.

Les signaux d’alerte

• Vous relancez trois fois le même prompt pour corriger un bug, et un autre apparaît ailleurs.
• Vous avez désactivé une règle de sécurité pour faire disparaître une erreur.
• Vous ne savez pas répondre à « qui peut lire la table des factures ? ».
• Vous passez plus de temps sur l’application que sur la vente, depuis plusieurs semaines.

Deux ou trois de ces signaux ensemble disent que le projet a changé de nature.

Prendre un freelance

Quand c’est le bon choix

Un bon freelance convient bien à une application au périmètre clair, avec un besoin ponctuel ou régulier mais limité : fermer les failles, brancher Stripe proprement, poser des tests sur le parcours principal, puis quelques jours par mois d’évolutions. C’est souvent la formule la plus directe : vous parlez à la personne qui code, sans intermédiaire.

Elle fonctionne le mieux quand vous avez, vous ou quelqu’un de votre entourage, assez de bagage pour vérifier le travail, ou quand le freelance documente assez pour qu’un autre puisse prendre le relais.

Ce que ça coûte en risques et en temps

Le risque structurel d’un freelance n’est pas sa compétence, c’est sa disponibilité. Il travaille seul : vacances, maladie, autre mission prioritaire, et votre application n’a plus personne. Pour un produit que vos clients utilisent tous les jours, c’est la question à régler avant de signer, pas après la première panne.

Le second risque est la concentration du savoir : si tout ce que sait le freelance est dans sa tête, son départ vous laisse un code que personne d’autre ne connaît.

En temps, comptez sur un rôle de pilote. Un freelance fait ce qu’on lui demande, et c’est sain ; mais quelqu’un doit décider des priorités, relire ce qui est livré, tester avant la mise en production. Si personne ne tient ce rôle, il retombe sur vous.

Les signaux d’alerte

• Il propose de reprendre le projet sur son propre compte GitHub ou son propre projet Supabase « pour aller plus vite ».
• Il annonce qu’il faut tout réécrire avant d’avoir lu le code, ou qu’il suffit de « corriger deux ou trois choses » sans l’avoir lu non plus.
• Il ne parle ni de sauvegardes, ni de tests, ni de la façon dont il met en production.
• Il continue à tout corriger par prompts dans Lovable, sans dépôt ni historique de ses propres changements.

Passer par un studio

Quand c’est le bon choix

Un studio se justifie quand plusieurs critères lourds se cumulent : données sensibles ou paiements, des clients qui dépendent du service, des régressions fréquentes, personne en interne pour vérifier, et un besoin de continuité. Il apporte une équipe plutôt qu’une personne : relecture du code par un second développeur, quelqu’un qui répond quand le premier est absent, et l’habitude d’exploiter des applications dans la durée. C’est le cas de Walettly, conçu, développé et exploité par Raicode, qui sert aujourd’hui plus de 500 commerces.

Un studio a aussi du sens quand la question n’est pas seulement « corriger » mais « décider » : garder l’application et la renforcer, ou en refaire les fondations sous une interface qui a fait ses preuves.

Ce que ça coûte en risques et en temps

Un studio est plus lourd : échanges, cadrage, parfois plusieurs interlocuteurs. Pour un petit correctif, c’est disproportionné. Et il vous demande du temps au départ pour donner les accès et expliquer le produit.

Le risque inverse du freelance existe aussi : celui d’être un petit client parmi d’autres, servi après les gros projets. Et une équipe qui préfère son propre code peut pousser vers une reconstruction ou une migration de framework que votre situation ne demande pas.

Les signaux d’alerte

• Personne ne peut vous dire nommément qui travaillera sur votre code.
• On vous propose de migrer vers une autre stack sans argument lié à votre produit.
• Le contrat ne dit rien de ce que vous récupérez en cas d’arrêt.
• On vous demande de transférer vos comptes à l’agence plutôt que de lui donner un accès.

Nous avons rassemblé les questions à poser à une agence, et les réponses qui doivent arrêter la discussion, dans notre guide pour choisir une agence MVP ou SaaS. Si votre vrai besoin est quelqu’un qui arbitre la roadmap technique dans la durée, lisez aussi ce qu’un founder achète avec un CTO externalisé.

En résumé

Évaluer un freelance ou un studio sur une app générée par IA

Une application Lovable a ses pièges propres, qu’un développeur excellent sur un projet classique peut manquer. Les questions à poser, et ce qu’une bonne réponse contient :

« Comment vérifiez-vous les règles RLS de ma base Supabase ? » Une bonne réponse parle de relire chaque table, de tester les accès sans être connecté puis avec un autre compte, et des fonctions qui contournent ces règles. Une mauvaise : « le scan de Lovable est au vert ».

« Où sont mes sauvegardes, et quand avez-vous fait un essai de restauration ? » Une sauvegarde jamais restaurée reste une hypothèse. Le prestataire doit savoir sur quel plan est votre projet Supabase et ce que couvrent ses sauvegardes, fichiers compris.

« Mes comptes restent-ils à mon nom ? » La réponse attendue est oui, sans détour : dépôt GitHub, organisation Supabase, hébergement, nom de domaine, Stripe et fournisseur d’e-mails vous appartiennent, et le prestataire y est invité. Ce n’est pas un détail administratif. Lovable indique qu’on ne peut pas changer le compte GitHub lié à un projet existant : il faut le déconnecter et le reconnecter, ce qui crée un nouveau dépôt. Et chez Supabase, transférer un projet vers une autre organisation suppose d’être propriétaire de l’organisation d’origine (pages consultées le 12 octobre 2026). Un projet créé sur les comptes d’un prestataire vous rend dépendant de sa bonne volonté pour en sortir.

« Quels tests allez-vous écrire en premier ? » On ne demande pas une couverture exhaustive, mais des tests sur ce qui fait votre chiffre d’affaires : inscription, paiement, action principale. Un prestataire qui n’en écrit aucun vous laisse la même roulette qu’avec les prompts.

« Comment mettez-vous en production, et comment revient-on en arrière ? » Un déploiement reproductible, une préproduction séparée de la production, des variables d’environnement distinctes. Si la réponse est « je publie depuis Lovable », demandez ce qui se passe le jour où une publication casse un parcours client.

« Puis-je continuer à utiliser Lovable ? » C’est possible : la synchronisation GitHub de Lovable fonctionne dans les deux sens, sur une branche à la fois. Mais il faut convenir d’une règle, sinon une génération peut défaire une correction. Un prestataire sérieux vous propose cette règle ; il ne vous interdit pas l’outil par principe.

« Que se passe-t-il si vous disparaissez demain ? » La question met mal à l’aise, et c’est le but. La bonne réponse décrit ce qui existe déjà : le code dans votre dépôt, une documentation de mise en production, la liste des accès et des secrets, et qui peut reprendre. Nous avons détaillé les clauses à écrire dans notre article sur la réversibilité et la propriété du code.

Demandez enfin ce qu’il a déjà repris comme code généré par IA, et ce qu’il y a trouvé. Les défauts typiques sont connus (nous les avons listés dans ce qu’il faut reprendre sur un MVP codé par IA).

Quand Raicode n’est pas le bon choix

Soyons clairs sur les cas où nous ne sommes pas la bonne réponse :

• Votre application n’a pas encore trouvé son usage. Si le produit change de forme chaque semaine, continuez seul avec Lovable. Revenez quand le parcours principal tient.
• Vous avez besoin d’une petite correction ponctuelle. Un bug d’affichage, un champ à ajouter : un freelance de confiance le fera plus simplement.
• Vous avez quelqu’un en interne qui sait coder. Il lui manque peut-être une relecture de sécurité, pas une équipe extérieure.
• Vous êtes sur Bubble. Il n’y a pas de code exporté à reprendre ; c’est une reconstruction, qui relève d’un développement de MVP SaaS.
• Vous cherchez un associé technique. Un studio ne remplace pas quelqu’un qui partage le risque et le capital.

Et à l’inverse, ne cherchez pas de prestataire qui vous promet une sécurité absolue : personne ne peut la garantir. Ce qu’un prestataire sérieux peut faire, c’est dire ce qui est ouvert aujourd’hui et dans quel ordre le fermer.

Trancher sans s’engager : l’audit de reprise

Ce choix dépend de choses que vous ne voyez pas : l’état des règles d’accès, la solidité du modèle de données, ce qui manque pour la production. Sans les connaître, on choisit à l’aveugle.

C’est pour cela que notre audit de reprise d’application Lovable existe comme une étape à part. Il a un prix fixe, communiqué sur WhatsApp avant de commencer, et rend un verdict écrit sous 48 h après réception des accès : sécurité (règles RLS, clés et secrets, authentification, fonctions exposées), qualité du code, ce qui manque pour la production, et une estimation de la reprise par ordre de priorité. Le verdict dit s’il faut garder et renforcer l’application, ou la refaire, en partie ou en totalité, avec les critères qui fondent ce choix.

Surtout, il ne vous engage à rien au-delà. Le rapport vous appartient : vous pouvez continuer seul en sachant quoi corriger d’abord, le confier à un freelance comme cahier des charges, ou nous confier la reprise. Pour une application construite avec un autre outil que Lovable, Bolt ou v0, la même démarche existe dans notre offre de reprise de projet IA.

Envoyez le lien de votre application sur WhatsApp ou décrivez-la via le formulaire : vous recevez le prix de l’audit, puis le verdict sous 48 h. Le détail de la démarche est sur notre page reprise d’app Lovable, Bolt et v0.