Lovable : ce qu'il faut vérifier avant d'investir dessus

Lovable vous a permis de lancer en 2 semaines. Votre app tourne, vous avez vos premiers utilisateurs, et vous commencez à y croire sérieusement. Mais la question n'est pas "est-ce que ça marche". C'est "est-ce que ça tient".

Je suis auditeur technique. Je passe mes journées à ouvrir le capot d'applications construites avec Lovable, Bolt ou Cursor. Et ce que je trouve en dessous ne ressemble pas toujours à ce que le fondateur imagine.

Ce que Lovable fait bien

Soyons honnêtes : Lovable est impressionnant pour ce qu'il promet. Vous décrivez ce que vous voulez, et en quelques minutes vous avez une interface qui tourne. Connexion Supabase, authentification, formulaires — ça fonctionne. Pour un MVP ou un proof of concept, c'est redoutable.

J'ai vu des fondateurs passer de l'idée à 500 utilisateurs en moins d'un mois. Sans écrire une ligne de code. Sans recruter. C'est un avantage réel, et je ne vais pas faire semblant que ça n'existe pas.

Le problème, c'est que "ça marche" et "c'est prêt pour la suite" sont deux choses très différentes.

Ce que Lovable ne fait pas

La sécurité n'est pas configurée par défaut

C'est le point qui me fait le plus grincer des dents.

Un fondateur me contacte. Son app Lovable tourne avec environ 500 utilisateurs. Il veut lever des fonds, et un investisseur lui demande un audit technique. Je regarde le code, je regarde la base de données Supabase, et je découvre que les Row Level Security policies ne sont pas configurées. En clair : n'importe quel utilisateur connecté pouvait accéder aux données de tous les autres. Noms, emails, données métier — tout était en accès libre.

Le fondateur ne savait même pas ce qu'était le RLS. Et c'est normal — ce n'est pas son métier. Mais Lovable crée les tables dans Supabase sans activer ces règles de sécurité. L'outil part du principe que vous allez les configurer vous-même. Sauf que si vous ne savez pas que ça existe, vous ne le faites pas.

Ce n'est pas un bug de Lovable. C'est un angle mort. Et c'est le genre d'angle mort qui peut tuer votre boîte si vous manipulez des données personnelles.

Le code n'est pas fait pour durer

Lovable génère du code qui fonctionne. Mais "fonctionnel" et "maintenable", ce n'est pas la même chose.

Ce que je retrouve systématiquement dans mes audits :

• Pas de séparation entre la logique métier et l'affichage. Tout est mélangé dans les mêmes fichiers. Quand un dev veut modifier une règle de calcul, il doit déchiffrer 400 lignes de code d'interface au passage.
• Du code dupliqué partout. La même vérification écrite 6 fois dans 6 fichiers différents. Le jour où vous changez une règle, il faut penser à la modifier aux 6 endroits. Personne n'y pense jamais.
• Aucune gestion d'erreur sérieuse. Quand tout va bien, tout va bien. Quand un appel réseau échoue ou qu'un utilisateur fait quelque chose d'imprévu, l'app plante sans explication.
• Zéro test. Chaque modification devient un pari. Vous touchez un truc ici, ça casse là-bas, et vous ne le découvrez que quand un utilisateur vous envoie un message furieux.

Pour un MVP, c'est acceptable. Pour un produit qui doit évoluer avec une équipe, c'est un boulet qu'on traîne à chaque sprint.

Le test qui ne trompe pas

Vous voulez savoir si votre code Lovable est viable ? Montrez-le à un développeur senior. Sa réaction vous dira tout.

Un fondateur, content de son app Lovable qui marchait bien, recrute un développeur senior à 65K pour faire évoluer le produit. Le dev prend ses fonctions, ouvre le code source, passe trois jours à essayer de comprendre l'architecture… et pose sa démission au bout de deux semaines.

Pas parce que le dev était capricieux. Parce que le code était si enchevêtré qu'il aurait fallu plus de temps à le démêler qu'à le réécrire. Le fondateur a perdu deux mois et plusieurs milliers d'euros dans l'histoire — sans compter le temps perdu.

Ce scénario, je l'ai vu plus d'une fois. Et à chaque fois, la réaction du fondateur est la même : "Mais ça marchait pourtant."

Oui. Comme une maison sans fondations tient debout — tant qu'il n'y a pas de tempête.

Lovable vs développeur : la vraie question

La question n'est pas "Lovable ou un dev". C'est "Lovable puis quoi".

Lovable est un excellent outil de prototypage. Vous validez une idée, vous testez un marché, vous obtenez vos premiers retours utilisateurs. C'est sa force, et elle est réelle.

Mais à un moment, il faut choisir :

1. Faire auditer le code existant et corriger ce qui doit l'être pour continuer dessus
2. Réécrire proprement en utilisant le prototype Lovable comme cahier des charges vivant

Les deux approches se défendent. Ça dépend du volume de dette technique accumulée et de votre stade de développement. Ce qui ne se défend pas, c'est d'ignorer la question et de continuer à empiler des fonctionnalités sur des bases fragiles en espérant que ça tiendra.

C'est toujours le scénario qui coûte le plus cher.

Ce que Lovable fait bien vs ce qu'il faut vérifier

Ce tableau couvre les problèmes que je retrouve dans plus de 8 audits sur 10 d'applications Lovable. Ce n'est pas exhaustif, mais si vous cochez ces 6 points, vous avez déjà éliminé les risques les plus critiques.

7 points à vérifier avant d'investir sur votre app Lovable

Avant de recruter, de lever ou simplement de continuer à construire sur votre base Lovable, vérifiez ces points. Vous n'avez pas besoin d'être technique pour poser ces questions — mais vous avez besoin de quelqu'un de technique pour y répondre honnêtement.

1. Sécurité des données — Les données de vos utilisateurs sont-elles cloisonnées ? Un utilisateur peut-il voir les données d'un autre ?
2. Secrets exposés — Vos clés API et mots de passe sont-ils dans le code ou dans des variables d'environnement protégées ?
3. Validation serveur — Les vérifications se font-elles uniquement dans le navigateur (contournable en 30 secondes) ou aussi côté serveur ?
4. Maintenabilité — Un développeur extérieur peut-il comprendre le code et le modifier sans tout casser ?
5. Gestion d'erreur — Que se passe-t-il quand un service externe ne répond pas ? L'app plante, ou elle gère ?
6. Dépendances — Les bibliothèques utilisées sont-elles à jour ? Y a-t-il des failles de sécurité connues dans vos dépendances ?
7. Conformité RGPD — Si vous collectez des données personnelles en Europe, avez-vous un registre des traitements, une politique de confidentialité, une base légale pour chaque usage de données ?

Sur ce dernier point, c'est un angle mort que je vois chez presque tous les fondateurs qui utilisent Lovable ou d'autres outils de vibe coding. L'outil ne génère pas votre conformité RGPD. Et si vous avez des utilisateurs européens, c'est une obligation légale, pas une option.

Quand Lovable est le bon choix

Je ne suis pas là pour descendre Lovable. Ce serait malhonnête — et je serais le premier à le recommander dans certains cas.

• Vous validez une idée. Vous ne savez pas encore si le marché existe. Lovable vous permet de tester en 2 semaines au lieu de 3 mois. C'est exactement pour ça qu'il a été conçu.
• Vous construisez un outil interne. Peu d'utilisateurs, pas de données sensibles, pas besoin de monter en charge. Le rapport effort/résultat est imbattable.
• Vous préparez une démo pour des investisseurs. C'est du jetable assumé. Vous montrez le concept, pas l'architecture technique.

En revanche, dès que vous avez des utilisateurs payants, des données personnelles ou des ambitions de croissance, faites vérifier ce qui se passe sous le capot. Pas dans 6 mois. Maintenant.

Un audit de code à ce stade coûte une fraction de ce que coûtera une réécriture dans un an. Ou pire : une fuite de données qui fait la une.

Ce que je dis aux fondateurs qui ont construit sur Lovable

Gardez votre app. Elle fonctionne, et elle a de la valeur — ne serait-ce que comme prototype validé par le marché. Mais ne confondez pas un prototype qui marche avec un produit prêt à scaler.

Faites regarder votre code par quelqu'un qui n'a rien à vous vendre d'autre qu'un diagnostic honnête. Vous saurez exactement où vous en êtes : ce qui tient, ce qui ne tient pas, et ce que ça coûte de corriger.

C'est la décision la moins glamour que vous prendrez cette année. C'est probablement aussi la plus rentable.