Lovable à l’essai

Lovable est le constructeur d’applications qui a fait du vibe coding un modèle d’affaires. Vous décrivez une application dans un chat, et Lovable écrit le code, installe une base de données et la connexion des utilisateurs, puis publie le résultat en ligne. L’entreprise de Stockholm a démarré en novembre 2024. En août, elle a levé 400 millions de dollars sur la base d’une valorisation de 13,3 milliards, et en septembre, son cofondateur Fabian Hedin a indiqué que le chiffre d’affaires annualisé avait dépassé 600 millions de dollars.

Construire des applications web et mobiles est notre métier, nous regardons donc Lovable sous deux angles : comme un outil que nous aimons utiliser, et comme le point de départ d’applications qui devront plus tard porter de vrais clients et leurs données. Voici ce qu’il fait bien, où il montre ses limites, et ce qu’il en coûte d’y rester.

Ce qu’il fait bien

Pour une première version, Lovable est vraiment impressionnant. Dans notre usage, une phrase devient en un après-midi une application qui fonctionne, avec ses écrans, la connexion, une base de données et un lien public, sans ouvrir le moindre éditeur. Une idée peut être essayée auprès de vraies personnes avant que quiconque n’écrive un cahier des charges, et cela change la façon dont on teste les idées naissantes.

C’est exactement ce que beaucoup de gens recherchent. Lovable affirme que ses utilisateurs ont créé plus de 60 millions de projets depuis le lancement, que les applications construites avec lui reçoivent plus de 900 millions de visites par mois, et que des employés de près des deux tiers des entreprises du Fortune 500 l’utilisent. Dans une enquête menée auprès de ses utilisateurs, près de huit sur dix ont déclaré construire une entreprise ou un projet parallèle dont ils espèrent tirer un revenu.

Lovable a aussi investi dans la sécurité. Depuis juin, une analyse de base vérifie la configuration, le schéma de la base de données et ses règles d’accès à chaque publication d’une application, et les administrateurs peuvent bloquer la publication tant que des problèmes critiques subsistent. Lovable est franc sur la limite : l’analyse de base n’examine pas le code de l’application à la recherche de failles logiques.

Tout se ressemble

Notre principale réserve porte sur le goût, et c’est un avis d’utilisateurs plutôt qu’une mesure. Les applications construites avec Lovable ont tendance à se ressembler : les mêmes mises en page, les mêmes cartes, les mêmes dégradés doux, un style que l’on reconnaît après quelques lancements. Pour un prototype, cela n’a pas d’importance. Pour une marque, si, car la première chose que remarque un client, c’est que personne n’a décidé de ce que le produit devait faire ressentir.

De bons prompts, des références et un système de design permettent de l’orienter. Mais le résultat par défaut tend vers la moyenne, et la plupart des gens s’en tiennent au résultat par défaut.

Qui répond de la sécurité

La question la plus sérieuse est celle de la sécurité. En mars 2025, Matt Palmer, alors chez le concurrent Replit, a découvert qu’un site construit avec Lovable exposait les données de ses utilisateurs, parce que les règles de la base de données qui décident qui peut lire quelles lignes manquaient ou étaient erronées. En analysant 1'645 projets de la vitrine même de Lovable, lui et ses collègues chercheurs ont trouvé 303 points de terminaison vulnérables dans 170 d’entre eux, qui exposaient des noms, des adresses e-mail, des données de paiement et des clés d’API de développeurs. La faille a été enregistrée sous la référence CVE-2025-48757, avec un score de gravité de 9,3 sur 10. Lovable la conteste, au motif que chaque client est responsable de la protection des données de sa propre application.

En avril 2026, un chercheur a montré que n’importe quel compte Lovable pouvait lire le code source et l’historique des conversations avec l’IA des projets publics d’autres utilisateurs. Lovable a d’abord écrit sur X : « Soyons clairs : nous n’avons pas subi de violation de données. » Deux jours plus tard, l’entreprise a publié un compte rendu plus complet : une modification apportée en février avait rouvert un accès fermé en 2025, des signalements adressés à son programme de bug bounty avaient été clos sans escalade, et son produit comme sa première réaction avaient été insuffisants. The Register a qualifié l’épisode de « leçon sur la manière de ne pas répondre aux signalements de vulnérabilités ».

Le phénomène dépasse Lovable. En septembre, la société de sécurité UpGuard a trouvé environ 16'000 bases de données sur Supabase, le service de bases de données derrière les applications Lovable, dont les tables étaient lisibles par tous, beaucoup contenant des données personnelles, et TechCrunch a relié cette vague à des applications construites rapidement avec l’IA. Supabase affirme que ses projets sont sécurisés par défaut et que les clients maîtrisent leur propre configuration. Les deux peuvent être vrais. Entre les deux, il y a souvent un fondateur qui n’a jamais eu à apprendre ce qu’est une règle de base de données.

Dépendance et coûts

Le code, lui, peut partir. Selon la documentation de Lovable, les applications, le code et les contenus que vous créez vous appartiennent, chaque abonnement peut se synchroniser avec un dépôt GitHub, et le frontend peut être hébergé n’importe où. Le backend est une autre affaire. Si une application tourne sur Lovable Cloud, les voies de sortie prises en charge sont Supabase en version gérée ou auto-hébergée. Migrer la base de données seule ne déplace ni la connexion, ni le stockage de fichiers, ni le temps réel, ni les fonctions edge, et pour un simple PostgreSQL ou un autre fournisseur, Lovable indique ne pas prendre en charge la migration. L’éditeur et son agent ne peuvent pas du tout être auto-hébergés.

Les coûts reposent sur des crédits. La formule Pro démarre à 25 dollars par mois pour 100 crédits et Business à 50 dollars, et toutes deux montent jusqu’à 10'000 crédits ; 1'200 crédits en Pro coûtent 294 dollars par mois. Tant qu’une application reste sur Lovable, son hébergement, ses fonctions d’IA et ses connecteurs puisent dans les mêmes crédits que la construction.

Une première version coûte peu. Ce qui est difficile à prévoir, selon notre expérience, c’est le coût de chaque modification une fois que l’application a grandi. Chaque prompt modifie du code que personne de votre côté n’a écrit ni lu, et avec des dizaines d’écrans, de rôles et de parcours de paiement, une correction à un endroit peut en casser un autre, et la réparation se paie elle aussi en crédits.

Notre verdict

Lovable est l’un des moyens les plus rapides de mettre une idée sous les yeux des gens, et c’est un plaisir de s’en servir. Utilisez-le pour des prototypes, des pitchs et des outils internes qui ne contiennent aucune donnée sensible. Avant l’arrivée de vrais clients et de leurs données, connectez GitHub dès le premier jour, faites vérifier chaque règle de base de données par quelqu’un qui connaît la sécurité, et décidez si l’application doit rester sur Lovable Cloud.

C’est pour cette étape suivante que Werk existe. Nous construisons des applications web et mobiles avec nos clients sur la plateforme que nous avons bâtie pour nos propres produits, où comptes, rôles et paiements sont conçus une fois pour toutes et testés, où des personnes relisent chaque version publiée, et où le code source vous appartient. Un prototype Lovable constitue un bon brief.