Lovable et les générateurs d’app par IA : 7 défauts remontés par les utilisateurs, et nos contre-propositions

BC Badr Chentouf 21 août 2026

Près de 8 millions d’utilisateurs, plus de 200 millions de dollars de revenus annuels récurrents et une valorisation de 6,6 milliards de dollars fin 2025 : Lovable est devenu la référence des générateurs d’applications par intelligence artificielle. Et pourtant, ses avis publics dessinent une courbe très particulière : environ 64 % de cinq étoiles, 17 % d’une étoile, presque rien entre les deux.

Cette forme n’est pas celle d’un produit moyen. C’est celle d’un produit qui réussit remarquablement une chose, et qui échoue durement dès qu’on lui en demande une autre.

Nous avons lu les avis, les retours d’expérience et les rapports de sécurité publiés sur ces plateformes. Sept reproches reviennent, toujours les mêmes, quel que soit l’outil. Les voici, avec pour chacun la façon dont nous y répondons avec VisionFab, notre fabrique d’applications métier par IA.

La bonne question n’est pas « est-ce que ça marche ? ». C’est « jusqu’où ça tient ? ».

1. La boucle de correction sans fin

C’est le reproche le plus cité en usage réel. L’agent tente un correctif, échoue, réintroduit un bug déjà réglé la veille, puis recommence. Un testeur rapporte trente crédits consommés pour un seul bug. Une expression revient dans les avis : cela ressemble moins à de l’ingénierie qu’à un pari.

La cause est structurelle. La seule mémoire du projet est la conversation. Rien ne dit à l’IA ce que l’application doit être, donc à chaque tour elle redécouvre l’intention et réinvente une partie du système.

La contre-proposition Visionsoft : avec VisionFab, l’IA ne complète pas un historique de discussion, elle part d’une spécification. Entités, rôles et règles de gestion sont déclarés une fois et deviennent la référence. Chaque règle devient un test numéroté : une régénération qui casserait une règle déjà validée est refusée avant livraison. Ce qui a été validé reste validé.

2. Le coût au crédit, imprévisible par construction

C’est la plainte numéro un sur le plan commercial. Chaque prompt, chaque édition, chaque tentative ratée consomme des crédits. Le client finance donc les erreurs de l’outil. Les avis les plus durs portent sur des crédits expirés, retirés sans explication, ou sur des remboursements refusés dès la moitié du quota consommée. Résultat : aucun budget projet ne tient.

La contre-proposition Visionsoft : un prix par application et par usage, pas par tentative. Vous ne payez jamais une correction de bug de la plateforme. Le coût d’un projet se chiffre avant de commencer et il ne dépend pas du nombre d’essais nécessaires pour y arriver.

3. Le mur de complexité

Les mêmes avis sont unanimes sur le point de rupture : la première version arrive en quelques minutes, puis tout se complique dès qu’apparaissent des rôles multiples, des droits par utilisateur, un parcours en plusieurs étapes ou un calcul métier réel. Un testeur obtient un bouton de règlement dont le calcul est simplement faux. Un autre décrit un agent incapable de gérer plusieurs types de comptes sans intervention d’un développeur.

Autrement dit : l’outil s’arrête exactement là où votre application commence à avoir de la valeur pour l’entreprise. C’est précisément là que se joue une application métier sur mesure.

La contre-proposition Visionsoft : les rôles, les droits et les workflows ne sont pas improvisés à chaque projet. Ils sont déclarés dans la spécification, puis générés sur une stack unique et éprouvée. La matrice des droits se vérifie écran par écran avec le mode « Voir comme », et chaque calcul métier est livré avec ses jeux de données de test. La complexité métier cesse d’être le moment où tout se casse.

↪️ Pour aller plus loin : Vibe coding en entreprise : bonnes pratiques, limites et risques

4. La sécurité par défaut, le défaut le plus grave et le moins visible

En janvier 2025, des chercheurs en sécurité ont identifié plus de 170 applications générées dont la base de données était publiquement lisible (CVE-2025-48757). En cause : des tables créées sans sécurité au niveau des lignes, interrogeables directement avec la clé publique présente dans le navigateur. Ont fuité des noms, des adresses e-mail, des numéros de téléphone, des adresses postales, des informations de paiement et des clés d’API tierces.

Quatre autres défauts reviennent dans presque tous les audits d’applications générées : clés secrètes écrites côté navigateur, vérification d’adresse e-mail absente, règles d’écriture laissant un utilisateur modifier les données d’un autre, en-têtes de sécurité manquants. Le même schéma se retrouve chez les autres générateurs du marché : c’est un défaut de catégorie, pas l’accident d’un éditeur.

La contre-proposition Visionsoft : l’IA écrit le code, mais ce n’est pas elle qui décide qu’il est sûr. Les briques critiques (authentification, droits, gestion des secrets) sont fournies par le Socle, pas réinventées à chaque projet. Chaque règle d’accès est doublée d’une garde côté API et d’un test, et chaque version passe un test d’intrusion automatisé, rôle par rôle, avant de pouvoir être déployée. Les contrôles sont mappés exigence par exigence sur l’OWASP Top 10, et les contrôles bloquants refusent toute version qui échoue. Vous n’auditez pas ce que l’IA a bien voulu écrire : la chaîne de fabrication le fait à chaque version.

5. Le code que personne ne veut reprendre

Les avis décrivent un code généré difficile à reprendre pour un développeur humain. C’est le vrai piège économique : au moment précis où l’IA bloque, le coût de reprise par une équipe devient supérieur à ce qu’aurait coûté un développement propre dès le départ. Les mois d’itération se transforment en dette, pas en actif.

La contre-proposition Visionsoft : le code est le vôtre, et il est fait pour être repris. Une seule stack pour toutes vos applications, une fiche « Comment ça marche » rédigée avec le code pour chaque bouton et chaque indicateur, des jeux de données de test fournis et des versions expliquées. Le développeur qui reprend l’application ne découvre pas un fichier anonyme : il trouve une spécification, des tests qui disent ce que le code doit faire, et la même structure que dans toutes vos autres applications.

6. Les régressions de plateforme

Le passage en version 2.0 a produit une vague d’avis négatifs : des prompts identiques donnant des résultats inférieurs, du contenu supprimé sans demande, des liens cassés apparus seuls, des crédits disparus. Des utilisateurs ont publiquement demandé le retour à la version précédente. Le message est clair : votre application dépend de la version courante de l’agent de votre fournisseur, et vous ne décidez pas de cette version.

La contre-proposition Visionsoft : versions maîtrisées et expliquées, analyse des impacts avant la mise en production, retour arrière possible. Le Socle installé chez vous refuse toute application dont la signature ne correspond pas : une évolution n’arrive pas dans vos applications de production sans que vous l’ayez décidé et testé.

7. Le support et la dépendance

Dernier motif récurrent dans les avis à une étoile : des réponses de robot renvoyant la même solution erronée, des délais de plusieurs jours même sur les formules payantes, un support réservé aux comptes payants, des remboursements refusés. Quand une application porte votre activité, l’absence d’interlocuteur devient un risque d’exploitation, pas un désagrément.

La contre-proposition Visionsoft : un éditeur français, des interlocuteurs identifiés et un engagement de service écrit. Surtout, une dépendance réduite au minimum : vos applications tournent sur un Socle installé chez vous, avec vos données, et le code vous est remis. Si vous changez d’outil demain, vous repartez avec.

La cause racine est unique

Ces sept reproches n’en font qu’un. Le problème n’est pas que l’IA écrive du code : c’est qu’elle l’écrive sans contrat. Entre la conversation et l’application livrée, rien ne fixe ce que l’application doit garantir, et rien ne vérifie qu’elle le garantit.

Pas de spécification durable, donc l’outil réinvente à chaque tour : c’est la boucle de correction et les régressions.
Pas de test qui bloque une version défaillante : c’est la sécurité par défaut absente.
Pas de déterminisme, donc aucun coût bornable : c’est la facturation au crédit.
Pas de cadre d’architecture ni de stack imposée : c’est le mur de complexité et la dette.

C’est précisément l’espace qu’occupe VisionFab. On garde ce que le vibe coding a apporté de meilleur, l’entrée en langage naturel et la vitesse. On y ajoute ce qui manque pour la production : une spécification durable, un contrat testé (règle, garde API, test numéroté), un test d’intrusion à chaque version et une exécution chez vous. Pour les équipes qui préfèrent ne pas manipuler de code du tout, notre studio no-code Vision reste disponible : le principe est le même, une IA qui travaille dans un cadre.

Défaut remonté	Cause racine	Réponse Visionsoft
Boucle de correction	La conversation est la seule mémoire	Spécification durable, chaque règle testée
Coût imprévisible	Facturation à la tentative	Prix par application, pas par essai
Mur de complexité	Architecture improvisée	Stack unique, droits déclarés et vérifiés
Failles par défaut	Aucun contrôle avant livraison	Contrôles bloquants et pentest à chaque version
Code non maintenable	Code sans spécification ni tests	Code remis, documenté, sur une stack unique
Régressions	Version imposée par l’éditeur	Versions expliquées, signées, retour arrière
Support absent	Modèle en libre-service	Éditeur français, exécution chez vous

↪️ Pour aller plus loin sur la sécurité : Sécuriser une application vibecodée : le guide pratique

Et si votre projet est déjà bloqué ?

Un projet généré et arrêté en cours de route n’est pas perdu. Ce qui a de la valeur, ce sont vos écrans, votre modèle de données et vos règles métier, pas la façon dont ils ont été écrits. Nos équipes analysent le projet, en tirent la spécification, et vous montrent chiffres à l’appui ce que coûte de le corriger, ou de le régénérer dans un cadre maîtrisé, avec ses tests et ses contrôles de sécurité.

Ma conviction de CEO

Les générateurs d’applications par IA ont rendu un service considérable : ils ont prouvé qu’une idée pouvait devenir une interface en quelques minutes, et ils ont mis fin à l’idée qu’un premier prototype devait coûter des semaines. Ce n’est pas un détail, c’est un acquis.

Mais une entreprise ne vit pas d’un prototype. Elle vit d’applications qui tiennent trois ans, qui supportent un contrôle, qui se transmettent d’une équipe à l’autre. Sur ce terrain, générer du code depuis une conversation, sans contrat et sans contrôle, n’est pas une accélération, c’est un report de la facture.

L’IA peut écrire votre application. Elle ne doit pas décider seule qu’elle est prête pour la production.

Badr Chentouf CEO – Visionsoft

Glossaire : les termes clés à connaître

Crédit d’IA, sécurité au niveau des lignes, dette technique générée : ces notions décident du coût réel et du niveau de risque d’une application construite avec un générateur d’IA. Voici de quoi les comprendre avant d’engager un budget.

Générateur d’application par IA

Un générateur d’application par IA est un service qui produit une application web complète, interface et base de données comprises, à partir d’une description en langage naturel. Lovable, Bolt, v0 ou Replit Agent en sont les représentants les plus connus. Leur intérêt est réel sur la première version d’un produit : on obtient en quelques minutes une interface crédible à montrer. Leur limite ne tient pas au fait qu’ils produisent du code, mais à ce qui manque autour : aucune spécification durable, aucun test qui bloque une version défaillante, aucun contrôle de sécurité avant la mise en ligne. Le code produit doit ensuite être hébergé, sécurisé et maintenu comme n’importe quel développement classique.

Crédit d’IA

Le crédit est l’unité de facturation des générateurs d’applications par IA. Chaque échange avec l’agent en consomme une fraction, qu’il aboutisse ou non. La conséquence économique est souvent sous-estimée : les tentatives infructueuses de correction sont facturées au client, ce qui rend le coût total d’un projet impossible à annoncer à l’avance. C’est le motif de mécontentement le plus fréquent dans les avis publics de ces plateformes.

Sécurité au niveau des lignes

La sécurité au niveau des lignes, ou row level security, est le mécanisme qui définit, table par table, quelles lignes chaque utilisateur a le droit de lire et de modifier. Sans elle, une base de données accessible depuis un navigateur peut être interrogée intégralement par n’importe quel visiteur disposant de l’adresse publique de l’application. C’est l’origine exacte de la vulnérabilité CVE-2025-48757, qui a exposé les données de plus de 170 applications générées en janvier 2025.

Dette technique générée

La dette technique générée désigne le code produit par une IA que personne dans l’organisation n’a écrit, relu ni compris, et qu’il faudra pourtant maintenir. Elle se manifeste au premier incident sérieux : le développeur appelé en renfort constate qu’il coûte moins cher de tout réécrire que de comprendre l’existant. Pour l’éviter, le code généré doit arriver avec ce qui permet de le reprendre : une spécification, des tests qui décrivent ce qu’il doit faire, une documentation et une stack commune à toutes les applications. C’est le principe de VisionFab.