Lovable avis : j'ai audité le code de mon app, voici ce qui manque pour la mise en production

Ton app tourne. L'aperçu est propre, les boutons répondent, le formulaire s'envoie. Tu l'as construite avec Lovable en quelques heures. Et une question te retient avant de l'ouvrir à de vrais clients : est-ce qu'elle tiendra ?

Tu n'es pas seul à te la poser. Selon TechCrunch, Lovable approchait les 8 millions d'utilisateurs en novembre 2025. La plupart des avis en ligne parlent de vitesse, de prix et de crédits. Presque aucun ne regarde ce qu'il y a dans le code.

J'ai donc fait l'exercice. J'ai créé une application uniquement pour tester ce que Lovable produit. J'ai exporté son code, puis je l'ai fait auditer ligne par ligne, comme je le fais avant une mise en production chez un client. Voici ce que j'ai trouvé : ce que Lovable fait très bien, et ce qu'il reste à diagnostiquer.

Mon avis sur Lovable en bref

Lovable produit une base de code plus sérieuse que sa réputation, mais pas une application prête pour la production. Sur mon app, les règles d'accès aux données sont bien en place. Ce qui manque se situe autour : qui obtient les droits, ce qui se passe quand un appel échoue, et où l'on teste avant de publier.

| Excellent pour | À diagnostiquer avant la production | Pour qui | |---|---|---| | Valider une idée en quelques heures | L'attribution des droits administrateur | Fondateurs qui veulent tester un marché | | Montrer une démo à des clients ou des investisseurs | Les erreurs qui s'affichent comme des listes vides | Équipes qui ont besoin d'une maquette fonctionnelle | | Obtenir une base React + Supabase lisible | La validation côté serveur | Projets qui seront repris par un développeur | | Poser des règles d'accès de base (RLS) | La séparation entre test et production | Pas seul, pour une app qui stocke des données clients |

Ce que j'ai construit avec Lovable

J'ai construit Villa Azur, une application de réservation pour une villa de location, sur le plan gratuit de Lovable et sans toucher au code. L'objectif n'était pas de lancer un produit. C'était de voir ce que Lovable génère quand on lui demande une vraie fonctionnalité métier.

Ma demande tenait en une phrase : une page d'accueil avec photos, un calendrier des disponibilités, un formulaire de demande et un espace réservé au propriétaire. Lovable a tout livré : quatre visuels, un calendrier cliquable, un formulaire (nom, e-mail, téléphone, voyageurs, message) et une page /proprietaire.

Pour un non-développeur, le résultat est impressionnant. L'interface est soignée et tout semble fonctionner dans l'aperçu.

Ce que l'aperçu ne montre pas. Pendant la construction, l'aperçu est devenu blanc. Lovable a appliqué un correctif, puis a écrit : « Comme l'erreur avait déjà disparu avant mon changement, je ne peux pas prouver que c'est lui qui règle le problème. » Cette honnêteté est appréciable. Mais elle résume l'enjeu : une IA peut corriger sans pouvoir vérifier. En production, quelqu'un doit le faire.

J'ai ensuite connecté le projet à GitHub, une option disponible dans Plus → Paramètres → Git. J'ai fait réaliser un audit statique du code, assisté par IA, avec une règle stricte : chaque constat doit citer le fichier, la ligne et l'extrait de code. J'ai ensuite vérifié moi-même les constats clés dans le projet.

Ce que Lovable fait vraiment bien

Sur mon app, Lovable a correctement protégé les données personnelles au niveau de la base. C'est le point le plus important, et c'est celui où les outils de vibe coding ont été le plus critiqués.

L'audit a relevé quatre choix solides :

• Des règles d'accès séparées par opération. Un visiteur anonyme peut envoyer une demande, mais pas la lire, la modifier ni la supprimer. Il ne peut même pas envoyer une demande déjà « confirmée » : la base n'accepte que le statut « en attente ».
• Un calendrier qui ne dévoile rien. Pour afficher les dates prises, l'app appelle une fonction qui ne renvoie que les dates d'arrivée et de départ. Jamais les noms, les e-mails ni les téléphones.
• La bonne clé au bon endroit. Le navigateur ne contient que la clé publique de Supabase. La clé « service », qui contourne toutes les règles, n'apparaît dans aucun fichier envoyé au visiteur.
• Des limites cohérentes. Le nom (100 caractères), l'e-mail (255), le message (1 000) et le nombre de voyageurs (1 à 12) sont contrôlés à la fois dans le formulaire et dans la base.

Ce n'était pas acquis. En mars 2025, un employé de Replit a découvert que de nombreuses apps Lovable reliées à Supabase avaient des contrôles d'accès mal configurés, ce qui rendait leurs données publiques. La faille, référencée CVE-2025-48757, a concerné plus de 170 applications. Sur mon app, ce problème précis ne se reproduit pas : les règles RLS de Supabase sont bien écrites.

Autrement dit, la serrure est bonne. La question suivante est : qui reçoit la clé ?

Le point bloquant : l'espace propriétaire revient au premier inscrit

Dans mon app, le premier compte créé sur la page propriétaire reçoit automatiquement les droits d'administrateur. Et cette page propose l'inscription à tout visiteur.

Voici le mécanisme, sans jargon :

1. L'adresse /proprietaire est publique. Sans connexion, elle affiche un formulaire de connexion et d'inscription.
2. Une règle automatique de la base donne le rôle « propriétaire » au premier compte inscrit, tant qu'aucun propriétaire n'existe.
3. Une fois ce rôle attribué, les règles d'accès lui ouvrent toutes les demandes : noms, e-mails, téléphones, messages.

J'ai vérifié dans mon projet. La table des rôles était vide : aucun propriétaire n'existait. Si j'avais publié l'app à ce moment-là, le premier inconnu inscrit aurait obtenu l'accès à toutes les demandes. Sans rien pirater : en remplissant un formulaire. L'audit relève aussi que deux inscriptions simultanées pourraient, en théorie, obtenir toutes les deux ce rôle.

C'est exactement la différence entre un prototype et un produit. La règle de sécurité existe et fonctionne. C'est la logique qui l'entoure qu'il faut diagnostiquer.

Le correctif tient en trois étapes :

1. Créer le compte du vrai propriétaire.
2. Vérifier dans la base qu'un seul compte a le rôle propriétaire, et que c'est le bon.
3. Retirer l'inscription du formulaire, puis la désactiver dans les réglages d'authentification du projet.

Le correctif prend quelques minutes. Encore faut-il savoir que le problème existe.

Quatre points à diagnostiquer avant la mise en ligne

Au-delà du point bloquant, l'audit a relevé quatre points importants : aucun n'empêche la démo, tous comptent dès que de vrais clients arrivent.

Les erreurs silencieuses

Quand la base ne répond pas, l'app ne le dit pas. Le calendrier affiche alors toutes les dates comme libres. L'espace propriétaire affiche « Aucune demande ». Le propriétaire croit que personne n'a réservé, alors que l'app ne parvient simplement pas à lire ses données. Seul l'envoi du formulaire affiche un message d'erreur.

Une validation faite surtout dans le navigateur

Le formulaire vérifie le format de l'e-mail et refuse les dates déjà prises. Mais ces contrôles vivent dans le navigateur, et n'importe qui peut les contourner en appelant la base directement. Côté base, rien n'empêche une demande sur des dates passées ou déjà confirmées.

Aucune limite au nombre de demandes

Un visiteur anonyme peut envoyer autant de demandes qu'il veut. Aucun quota n'apparaît, ni dans le formulaire, ni dans la base. Un simple script peut remplir la boîte du propriétaire en quelques minutes.

Un seul environnement, déjà nommé « prod »

Le projet n'a qu'un fichier de configuration, pointant vers une base dont l'adresse se termine par -prod. Il n'existe pas d'environnement de test séparé. Chaque essai se fait donc sur les vraies données. J'explique pourquoi c'est un risque dans mon article sur la différence entre une app de test et une app en production.

Sous le capot : le code en chiffres

Le code généré est court, lisible, mais encombré : près de 70 % des lignes appartiennent à un kit d'interface que l'app n'utilise pas.

| Mesure | Valeur | |---|---| | Lignes de code (hors dépendances) | 6 273 | | Lignes du kit d'interface ui | 4 361 (près de 70 %) | | Composants du kit utilisés par les pages | 1 sur 46 | | Composants métier | 3 (calendrier, formulaire, en-tête) | | Pages | 2 (/ et /proprietaire) | | Tables | 2, plus 3 fonctions SQL | | Tests | 1, qui vérifie seulement que la page d'accueil existe | | Bibliothèques installées sans être utilisées | 4 (dont date-fns et drizzle-orm) |

Rien de tout cela n'est dangereux. Mais un développeur qui reprend le projet doit d'abord faire le tri. Le schéma de la base, par exemple, n'est pas là où on l'attend : le fichier prévu est vide, et les vraies tables sont dans un fichier SQL de migration.

Le seul test existant ne vérifie ni le formulaire, ni la connexion, ni les droits. Rien ne garantit donc qu'une prochaine modification demandée à Lovable ne réintroduira pas un problème déjà corrigé.

Lovable est-il fait pour toi ?

Lovable est un excellent outil pour aller vite jusqu'au prototype, et un point de départ solide pour un produit, à condition de prévoir un diagnostic avant d'accueillir de vrais utilisateurs.

| Ton projet | Lovable seul suffit ? | |---|---| | Valider une idée, faire une démo | Oui | | Outil interne, sans données sensibles | Oui, avec des précautions simples | | Collecte de données clients (formulaires, comptes) | Pas sans diagnostic | | Paiements, données de santé, données de mineurs | Non : audit indispensable |

La question n'est pas « Lovable ou un développeur ». C'est « à quel moment faire intervenir un regard technique ». Pour comprendre la méthode elle-même, ses forces et ses pièges, tu peux lire notre guide complet sur le vibe coding.

Si ton app est déjà construite et que tu bloques au moment du lancement, je détaille les causes les plus fréquentes dans pourquoi une app créée avec l'IA bloque avant la production.

Comment passer d'une app Lovable à une app en production (sans tout refaire)

Dans mon cas, la base est saine : on corrige, on ne reconstruit pas. Voici l'ordre que je suis :

1. Exporter le code vers GitHub. C'est gratuit, et ça te donne un historique de chaque modification.
2. Faire auditer le code. Chaque constat doit être prouvé par un fichier et une ligne. Sinon, ce n'est qu'une opinion.
3. Sécuriser les accès. Rôles, inscriptions, règles RLS vérifiées sur la base réellement en ligne, pas seulement dans les fichiers.
4. Rendre les erreurs visibles. Une panne doit s'afficher comme une panne, jamais comme une liste vide.
5. Séparer test et production. Une base pour essayer, une autre pour les vrais clients.
6. Ajouter les tests essentiels. Le formulaire, la connexion, et le fait qu'un compte sans droits ne voit rien.
7. Mettre en ligne, puis surveiller les premières semaines.

Pour faire le point toi-même, j'ai réuni ces vérifications dans une checklist en 6 points avant la mise en production.

Conclusion

Lovable mérite une partie de sa réputation. En quelques échanges, sans toucher au code, j'ai obtenu une application crédible, avec des règles d'accès mieux écrites que ce que la faille de 2025 laissait craindre.

Mais l'audit montre aussi la limite : l'outil écrit des règles correctes, sans vérifier la logique qui les entoure. Une table de rôles vide, une inscription ouverte, des erreurs qui se font passer pour des listes vides. Rien de spectaculaire. Rien que l'aperçu ne révèle. Et tout ce qui compte le jour où de vrais clients arrivent.

Ton app Lovable n'a probablement pas besoin d'être refaite. Elle a besoin d'être diagnostiquée, sécurisée, puis mise en production.

Tu as une app construite avec l'IA qui bloque avant le lancement ? Faisons le point sur ton application.

Questions fréquentes sur Lovable

Lovable est-il sécurisé ?

Lovable pose de bonnes bases. Sur mon app, les règles d'accès Supabase (RLS) étaient correctes et seule la clé publique figurait dans le navigateur. En revanche, l'outil ne vérifie pas la logique autour : chez moi, le premier inscrit devenait administrateur. Un audit reste nécessaire avant de stocker des données clients.

Une app Lovable peut-elle aller en production ?

Oui, et souvent sans tout refaire. Il faut d'abord diagnostiquer les points que l'aperçu ne montre pas : attribution des droits, gestion des erreurs, validation côté serveur, environnement de test et tests automatisés. Sur mon app, la base était saine : les corrections étaient ciblées, pas une reconstruction.

Peut-on récupérer le code d'une app Lovable ?

Oui. Dans Lovable, le menu Plus → Paramètres → Git connecte le projet à GitHub, GitLab ou Bitbucket, avec une synchronisation dans les deux sens. Je l'ai fait sur le plan gratuit. Attention : selon Lovable, les clés API et les secrets ne sont pas inclus dans l'export et doivent être reconfigurés.

Faut-il savoir coder pour utiliser Lovable ?

Pour construire, non : j'ai obtenu une application complète sans toucher au code. Pour juger si elle est prête pour de vrais clients, oui. Aucun des problèmes relevés dans mon audit n'était visible dans l'aperçu. Ils n'apparaissent qu'en lisant le code et la configuration de la base.

Lovable est-il gratuit ?

Lovable propose un plan gratuit. Selon sa documentation, il donne 5 crédits de construction par jour, dans la limite de 30 par mois, plus de petites allocations pour le cloud et l'IA. C'est suffisant pour tester l'outil sur une petite application. Pour un projet plus ambitieux, il faut passer à un plan payant.

Lovable permet-il de revenir à une version précédente ?

Oui. Lovable conserve un historique des versions dans son éditeur. Et une fois le projet connecté à GitHub, chaque modification faite dans Lovable est enregistrée sous forme de commit. C'est une raison de plus de connecter GitHub dès le début, avant d'en avoir besoin.

Où sont hébergées les données d'une app Lovable ?

Selon sa page sécurité, Lovable Cloud propose un hébergement régional des données dans l'Union européenne, aux États-Unis et en Asie-Pacifique. Pour une app soumise au RGPD, vérifie la région choisie pour ton projet et consulte l'accord de traitement des données de Lovable avant de collecter des données clients.

Faut-il tout refaire pour passer d'une app Lovable à la production ?

Rarement. Le code généré par Lovable est un projet React et Supabase standard, qu'un développeur peut reprendre. Dans mon audit, aucun constat n'imposait de reconstruire : il fallait fermer une inscription, rendre les erreurs visibles, renforcer la validation et séparer test et production.