Vibe coding : pourquoi ça marche en démo et plante en prod

Vous avez vu les vidéos. Un fondateur tape une phrase dans Lovable, et soixante secondes plus tard un dashboard surgit à l'écran, complet, bien designé, avec une authentification qui semble fonctionner. Impressionnant. Puis le fondateur essaie de lancer en production.

"Connect your Supabase account." "Configure RLS policies." "Debug this Netlify build error."¹

La magie s'évapore. Ce qui ressemblait à un produit fini était en fait une maquette frontend sans fondation. C'est ce qu'un analyste a appelé le Technical Cliff : le moment où le code généré par IA rencontre la réalité brutale de l'infrastructure de production.

Ce n'est pas du hype négatif. C'est simplement la limite documentée d'une catégorie d'outils utiles mais mal comprise. Et cette limite a un coût précis.

Les 70% dont personne ne parle

Tous les acteurs sérieux du secteur convergent sur le même chiffre. Lovable, Bolt.new, v0 vous amènent à 70% d'une application de production. Le premier 70% est spectaculaire : en quelques minutes, vous avez un prototype qui aurait pris des semaines à construire manuellement.²

Le problème, c'est le 30% restant. Et ce n'est pas le 30% facile.

Ce qui reste à faire après le prototype : la logique métier complexe qui ne tient pas dans un seul prompt, les cas limites sur l'authentification et les paiements, la gestion des erreurs réelle, les contraintes de performance à l'échelle. Ce n'est pas cosmétique. C'est l'application elle-même.

Un exemple concret : une équipe SaaS américaine a utilisé Lovable pour générer un portail client multi-rôles. L'interface fonctionnait. Les tests backend passaient. Au déploiement, le système s'est effondré sous la concurrence des sessions — parce que la gestion des tokens avait été inférée par l'IA, pas conçue par un architecte.³ La logique d'invalidation de session était probabiliste. Pas d'enforcement de middleware. Pas de validation des rate limits en conditions de production.

Ce genre de bug ne se voit pas en démo. Il se voit quand les vrais utilisateurs arrivent.

La faille de sécurité qui a exposé 170 applications

En 2025, le chercheur Matt Palmer a identifié une vulnérabilité systémique dans Lovable, référencée CVE-2025-48757. Le problème : une mauvaise configuration par défaut des politiques Row-Level Security (RLS) dans Supabase.⁴

Ce que ça a donné en pratique : 303 endpoints exposés sur 170 applications en production. Des attaquants sans credentials pouvaient accéder en lecture et en écriture aux bases de données de ces apps, en exploitant simplement la clé anon_key publique embarquée côté client. Des tables entières récupérables : listes d'utilisateurs, données de paiement, clés API.

Dans certains cas, des endpoints Stripe publics permettaient de modifier les paramètres de paiement ou d'injecter des paramètres non autorisés.

Lovable avait pourtant ajouté un "security scanner" pour détecter les politiques RLS manquantes. Il vérifiait l'existence d'une politique — pas si elle bloquait effectivement les accès non autorisés. Nuance importante.

La réponse de Lovable a été largement critiquée par les chercheurs en sécurité comme insuffisante et peu transparente. La leçon n'est pas que Lovable est mauvais. C'est que quand une plateforme encode une mauvaise configuration par défaut, toutes les applications construites dessus héritent du problème. Les fondateurs qui ont déployé ces apps n'avaient pas à être des experts en sécurité pour construire dessus — c'est exactement la promesse du produit. Et c'est exactement là que le problème est structurel.

Ce que coûte vraiment un refonte

Voici un calcul qui circule chez les développeurs : une startup veut un SaaS multi-tenant avec Stripe, gestion des rôles et un dashboard data.⁵

Avec Lovable : l'IA génère l'interface et une auth Supabase basique. L'intégration Stripe est fragile — les webhooks ne gèrent pas les cas limites, la gestion des abonnements est incomplète. Coût estimé de refonte pour passer en production : entre 30 000 et 60 000 €.

Avec un build supervisé dès le départ : intégration Stripe correcte avec webhooks, dunning et gestion des plans. Auth avec gestion des rôles. Dashboard en temps réel. Délai : 2 à 4 semaines. Coût : entre 15 000 et 35 000 €.

Le paradoxe : démarrer avec l'outil "rapide et pas cher" revient souvent plus cher que de partir sur une base solide. La raison est simple. Le code généré par IA doit être repris entièrement pour la production — et retravailler du code que vous n'avez pas écrit est plus coûteux qu'écrire du code propre depuis le début.

Bolt.new : l'autre côté du miroir

Bolt.new a une philosophie différente de Lovable. Là où Lovable se positionne comme un "co-fondateur IA", Bolt donne accès direct au code généré et cible plutôt les développeurs qui veulent accélérer.⁶

Les retours d'usage en production sont similaires sur les points de friction : l'authentification avec Supabase est décrite comme "notoriously problematic" par de nombreux utilisateurs, avec des sessions pouvant consommer des millions de tokens pour résoudre des bugs basiques d'auth. Les projets de plus de 15-20 composants subissent une dégradation de contexte — l'IA oublie les patterns, crée des doublons, perd la cohérence architecturale.⁷

Le déploiement one-click fonctionne pour les apps simples. Pour tout ce qui implique du routage complexe ou de l'authentification réelle, les blancs à l'écran sont fréquents.

Ce n'est pas un procès. Ce sont des outils de prototypage, bons dans leur registre. Le problème est quand ils sont présentés — et parfois utilisés — comme des outils de production.

Le bon workflow : deux étapes, pas une

La pratique qui émerge chez les équipes sérieuses n'est pas "vibe coding ou développement traditionnel". C'est les deux, dans le bon ordre.⁸

Étape 1 : valider avec Lovable ou Bolt. Construire le prototype en une journée. Le montrer aux utilisateurs potentiels, obtenir du feedback, tuer les mauvaises idées vite. Le vibe coding excelle là-dedans. C'est son cas d'usage légitime.

Étape 2 : construire la production avec supervision. Repartir sur une base propre — ou auditer et refondre l'existant — avec des développeurs seniors qui pilotent les modèles IA sur chaque couche critique : authentification, gestion des sessions, intégrations tierces, tests end-to-end.

Sur Empreinte Fiscale, on a livré 14 modules et 78 écrans en une semaine. Pas parce qu'on a tapé des prompts dans Lovable et espéré que ça tienne. Parce que chaque décision d'architecture — session management, contraintes Prisma, middleware de validation — a été prise par un développeur senior qui supervisait la génération IA, pas par l'IA seule.

La différence n'est pas visible en démo. Elle est visible quand les premiers vrais utilisateurs arrivent avec des comportements que le prototype n'avait pas prévus.

Ce que les outils ne peuvent pas encore générer

Il y a des catégories entières de logique applicative où les outils de vibe coding actuels échouent systématiquement, quel que soit le prompt.⁹

La gestion des paiements Stripe en production : le happy path est simple à générer. Les webhooks de renouvellement échoué, les downgrades avec proratisation, les changements de siège en cours de cycle, les périodes de grâce d'annulation — c'est là que l'IA génère du code fonctionnel en apparence, qui casse à la première vraie situation limite.

La performance à l'échelle : le code généré a souvent des requêtes N+1, des index manquants, des re-renders non optimisés. Ça tient à 10 utilisateurs. À 1 000, ça s'effondre.

La sécurité multi-tenant : la segmentation des données entre clients dans une architecture multi-tenant nécessite des décisions d'architecture que l'IA ne peut pas prendre seule, parce qu'elles dépendent du modèle de données entier, pas d'un prompt isolé.

Ce n'est pas une critique des LLMs. C'est une limite de l'approche "décris ce que tu veux et l'IA construit tout". La supervision humaine n'est pas un filet de sécurité — c'est l'endroit où les vraies décisions se prennent.

Pourquoi le marché va bifurquer

En 2026, le marché des outils de vibe coding ressemble à celui du no-code en 2019 : beaucoup de promesses, des cas d'usage réels mais circonscrits, et une tendance à overpromiser sur la production readiness.¹⁰

La bifurcation qui se dessine : d'un côté, les outils de prototypage rapide (Lovable, Bolt, v0) qui vont consolider leur position sur la validation et les démos. De l'autre, les studios IA supervisés qui gèrent la production réelle — avec le code, les tests, la sécurité et l'architecture qu'un SaaS réel exige.

Le CEO de Bolt, Eric Simons, décrit exactement ce mouvement dans un webinar récent avec Supabase : des équipes innovation dans de grandes entreprises qui utilisent les outils IA pour construire des applications réelles et internes, mais dans un cadre de gouvernance strict, avec supervision technique.¹¹ Ce n'est pas "n'importe qui peut construire un SaaS en une heure". C'est "des équipes avec du contexte technique peuvent aller beaucoup plus vite avec l'IA".

Nuance importante. Et elle change tout à la façon d'évaluer ces outils.

---

Si vous avez validé une idée et que vous avez besoin d'un produit qui tient en production, notre méthode est construite exactement pour cette étape. Ou si vous voulez estimer ce que ça représente, l'estimateur de coût donne une base de travail en quelques minutes.

---

Sources

"You've seen the demos. A founder types 'build me a SaaS dashboard' into Lovable, and 60 seconds later, a beautiful UI appears. Magic. Then they try to launch it. 'Connect your Supabase account.' 'Configure RLS policies.' 'Debug this Netlify build error.' The magic evaporates." https://getmocha.com/blog/best-ai-app-builder-2026/{:target="_blank" rel="noopener noreferrer"}

"All three tools share a fundamental limitation: they get you about 70% of the way to a production application. The first 70% is magic [...]. But the remaining 30% is where things get difficult: Complex business logic, edge cases in authentication, payments, and data validation." https://freeacademy.ai/blog/v0-vs-bolt-vs-lovable-ai-app-builders-comparison-2026{:target="_blank" rel="noopener noreferrer"}

"A U.S. SaaS team used Lovable to generate a multi-role client portal. The interface worked. The backend logic passed tests. Deployment failed under session concurrency because token handling was inferred, not engineered." https://www.toolient.com/2026/02/lovable-vs-bolt-vibe-coding-tools-product-hunt.html{:target="_blank" rel="noopener noreferrer"}

"CVE-2025-48757 shows how a single platform misconfiguration can fan out into hundreds of live vulnerabilities. The vulnerability touched 303 endpoints across 170 of the tested apps. This allowed unauthenticated attackers to read and write to the databases of Lovable apps." https://www.superblocks.com/blog/lovable-vulnerabilities{:target="_blank" rel="noopener noreferrer"}

"A founder wants a multi-tenant SaaS product with Stripe billing, role-based access, and a data dashboard. Lovable: Estimated rebuild cost to production: $30K-$60K. Expert-supervised build: Production-grade from day one. Cost: $15K-$35K." https://www.chronoinnovation.com/resources/lovable-vs-bolt-vs-built{:target="_blank" rel="noopener noreferrer"}

"Bolt's deployment works for simple apps but often fails with complex routing or authentication. Projects with 15-20+ components experience severe context loss. The AI forgets patterns, creates duplicates, and loses consistency as projects grow." https://www.p0stman.com/guides/bolt-limitations/{:target="_blank" rel="noopener noreferrer"}

"Their Supabase-only constraint, lack of SDLC management, missing enterprise security features, and limited deployment options make them suitable for prototypes and MVPs—but not for applications that businesses actually depend on." https://blog.tooljet.com/bolt-vs-lovable/{:target="_blank" rel="noopener noreferrer"}

"Stage 1: Validate with Lovable or Bolt. Build the demo in a day. Show potential users, get feedback. Kill bad ideas fast. Stage 2: Build production with Cursor + Foundation. Start with a production-ready base. Use Cursor/Claude Code to add custom features." https://makerkit.dev/blog/saas/best-vibe-coding-tools{:target="_blank" rel="noopener noreferrer"}

"Stripe integration looks easy until you handle: failed payments, subscription downgrades, proration, cancelation grace periods, seat-based billing changes. AI tools generate the happy path; production needs all paths. Performance at scale. Generated code often has N+1 queries, missing indexes, unoptimized re-renders." https://makerkit.dev/blog/saas/best-vibe-coding-tools{:target="_blank" rel="noopener noreferrer"}

"In 2026, there isn't one 'best' AI coding assistant. There are different tools optimized for different parts of the development lifecycle, and most teams mix them without a clear framework." https://www.qodo.ai/blog/best-ai-coding-assistant-tools/{:target="_blank" rel="noopener noreferrer"}

"Something strange is happening in large enterprises. Non-technical employees are building production software. CEOs are shipping features. And companies are canceling SaaS contracts worth millions." https://supabase.com/events/enterprise-innovation-with-bolt{:target="_blank" rel="noopener noreferrer"}

Footnotes

1. "Best AI App Builder 2026: Lovable vs Bolt vs v0 vs Mocha" — Mocha, février 2026. ↩

2. "v0 vs Bolt vs Lovable 2026: Best AI App Builders & Vibe Coding Tools Compared" — FreeAcademy AI, février 2026. ↩

3. "Lovable vs Bolt: Vibe Coding Tools Taking Over Product Hunt" — Toolient, février 2026. ↩

4. "Lovable Vulnerability Explained: How 170+ Apps Were Exposed" — Superblocks, septembre 2025. ↩

5. "Lovable vs. Bolt vs. Built: 2026 Comparison" — Chrono Innovation, février 2026. ↩

6. "Bolt Limitations: What Bolt Can't Do (2026 Guide)" — p0stman, janvier 2026. ↩

7. "Bolt.new vs Lovable: Which AI app builders dominates 2026?" — ToolJet Blog, janvier 2026. ↩

8. "Best Vibe Coding Tools for SaaS Development (2026)" — MakerKit, janvier 2026. ↩

9. "Best Vibe Coding Tools for SaaS Development (2026)" — MakerKit, janvier 2026. ↩

10. "Top 15 AI Coding Assistant Tools to Try in 2026" — Qodo, février 2026. ↩

11. "Vibe Coding, Done Right: AI Development in Production" — Supabase Events, février 2026. ↩