Lovable, Bolt, Replit : 7 limites de l'IA pour coder un vrai produit
Réponse rapide. Les IA générateurs de code (Lovable, Bolt.new, Replit Agent, v0, Cursor en mode agent) sortent un prototype fonctionnel en quelques heures. Mais elles butent sur 7 limites structurelles quand il s'agit de tenir un vrai produit en prod : architecture qui ne scale pas, sécurité bricolée, intégrations tierces fragiles, dette technique invisible, performance dégradée, observabilité absente, et code que personne d'autre ne peut maintenir.
Pourquoi cet article ne dit pas que l'IA est nulle
On utilise nous-mêmes Claude Code, Cursor, et v0 quotidiennement chez FreshMarkom. Ces outils nous font gagner 30 à 50% de temps sur les tâches répétitives.
Mais on voit aussi depuis 18 mois une vague de projets "vibe-codés" arriver en audit chez nous. Des founders qui ont sorti un MVP avec Lovable ou Bolt en 3 semaines, levé 200K€, puis se retrouvent bloqués au moment de scaler ou de faire intervenir une équipe technique.
Cet article décortique les 7 limites concrètes qu'on remonte sur ces projets. L'objectif n'est pas de dire "ne fais pas d'IA", mais de savoir où s'arrête le génératif et où commence le vrai produit.
Limite 1 : l'architecture qui ne tient pas la charge
Le problème. Les IA génèrent du code qui marche pour 1 à 10 utilisateurs simultanés. Au-delà, l'architecture monolithique, l'absence de cache, les requêtes N+1, et les server actions non optimisées font exploser le temps de réponse.
Pourquoi l'IA ne le voit pas. Elle n'a pas de contexte de charge. Elle code pour faire passer le cas nominal. Elle ne sait pas qu'à 200 utilisateurs simultanés, ton endpoint /api/dashboard va déclencher 200 requêtes à Supabase au lieu d'une avec batch.
Exemple récent d'audit. Un SaaS B2B vibe-codé avec Bolt, 380 utilisateurs en bêta payante. Au-delà de 50 utilisateurs simultanés, le dashboard mettait 12s à charger. Cause : chaque widget faisait sa propre requête, sans batch, sans cache, sans memoization. Refacto en 2 jours par notre équipe a ramené à 1,2s.
Coût caché. Un SaaS qui rame perd 25 à 40% de ses utilisateurs payants dans les 60 jours après le pic. Pour un produit à 50€/mois et 380 utilisateurs, c'est 5 700€/mois de churn récupérable.
Comment fixer. Audit de charge avec k6 ou Artillery sur les endpoints critiques. Identifier les goulots, ajouter du caching (Redis, edge cache), batcher les requêtes, paginer correctement.
Limite 2 : la sécurité bricolée ou absente
Le problème. Les IA appliquent des patterns de sécurité de base (HTTPS, hash de mot de passe avec bcrypt), mais ratent les couches plus avancées : Row Level Security, CSRF, validation server-side stricte, gestion des secrets, rate limiting.
Pourquoi l'IA ne le voit pas. Elle copie des patterns vus dans son training. La sécurité réelle dépend du contexte business : qui peut voir quoi, qui peut modifier quoi, comment éviter les escalations.
Cas typiques observés :
- Service role Supabase exposé dans le bundle JavaScript côté client (donne accès complet à la base)
- Aucune Row Level Security activée, n'importe quel utilisateur authentifié peut lire les données d'un autre
- Validation Zod côté client uniquement, contourné en 30 secondes avec curl
- Clés API Stripe / OpenAI / SendGrid commitées dans Git
- Aucun rate limiting, les API peuvent être pillées ou DDoS'ées
Coût caché. Variable mais peut être catastrophique. Une faille RLS qui expose les commandes des concurrents, c'est la fin du produit. Une clé Stripe exposée, c'est des transactions frauduleuses + chargebacks.
Exemple récent. Un marketplace B2C vibe-codé, 1 200 utilisateurs. Notre audit a remonté que n'importe quel utilisateur authentifié pouvait lire les emails et téléphones de tous les autres via une requête Supabase directe (RLS absente). Fuite massive de PII potentielle. Fix en 4 heures, RLS strictes + service role uniquement côté server.
Comment fixer. Audit sécurité dédié : checklist OWASP Top 10, vérification RLS pour chaque table, scan du bundle pour secrets exposés, test de rate limiting.
Limite 3 : la dette technique invisible
Le problème. Les IA génèrent du code qui marche, pas du code maintenable. Composants de 500 lignes mélangeant logique métier, UI, fetch et validation. Fonctions dupliquées 4 fois avec des variations légères. Aucune abstraction réutilisable.
Pourquoi l'IA ne le voit pas. Elle n'a pas de mémoire entre les prompts. Elle ne sait pas qu'elle a déjà créé un composant Button 12 minutes plus tôt. Elle re-crée plutôt que réutiliser.
Symptômes typiques d'un projet vibe-codé après 3 mois :
- 40 composants
Buttonlégèrement différents - 8 implémentations différentes de "fetcher les utilisateurs"
- Aucun fichier de types partagés, chaque composant redéfinit ses types
- Zéro tests automatisés
- Aucun système de design
Coût caché. Quand tu veux faire évoluer le produit, chaque modification touche 4 endroits au lieu de 1. La vitesse de dev divise par 3 après le mois 4.
Comment fixer. Refacto progressive : extraire les composants vraiment réutilisables, créer un design system minimal, mettre en place TypeScript strict, ajouter au moins des tests sur les flux critiques.
Limite 4 : les intégrations tierces fragiles
Le problème. Les IA savent appeler une API REST. Elles ne savent pas gérer les cas d'erreur réels : webhook qui arrive deux fois, paiement qui passe mais réponse qui timeout, service tiers indisponible.
Pourquoi l'IA ne le voit pas. Les intégrations robustes nécessitent d'avoir vécu les incidents : Stripe webhook signature qui change, race condition entre paiement et provisioning, idempotence des opérations.
Cas typiques observés :
- Webhook Stripe sans vérification de signature (n'importe qui peut faux-créditer des comptes)
- Pas de retry policy sur les appels OpenAI (un timeout réseau = service cassé pour l'utilisateur)
- Email transactionnel envoyé avant que la transaction soit committée en DB
- Pas de logs des intégrations, impossible de debugger en cas de problème
- Pas de fallback si le service tiers est down
Coût caché. Pour un SaaS qui dépend de Stripe et OpenAI, une heure de mauvaise intégration peut faire perdre des dizaines d'utilisateurs payants qui ne reviennent pas.
Comment fixer. Chaque intégration tierce doit avoir : signature verification (webhooks), retry logic avec backoff, idempotency keys, logs structurés, monitoring d'erreurs (Sentry), et plan de fallback.
Limite 5 : performance et SEO inadaptés au web réel
Le problème. Les IA génèrent du code qui charge tout en client. Bundle JS de 3 Mo, hydration lente, aucune optimisation d'images, pas de SSG, pas de schemas structurés, pas d'i18n, accessibilité minimale.
Pourquoi l'IA ne le voit pas. Lovable et Bolt produisent par défaut du React client-rendered. C'est plus simple à générer, mais inadapté à un site qui doit ranker en SEO ou être cité par les IA conversationnelles (GEO).
Coût caché. Pour un produit B2C ou un SaaS dont l'acquisition vient en partie du SEO, un site vibe-codé est invisible pour Google et pour ChatGPT. Tu paies tout en publicité.
Comment fixer. Passer à Next.js App Router avec Server Components, mettre en place les Core Web Vitals, ajouter les schemas (Article, Organization, BreadcrumbList), créer un sitemap propre, optimiser les images via next/image.
Limite 6 : observabilité absente
Le problème. En prod, ton site va planter. La question n'est pas si, mais quand. Sans logs structurés, sans monitoring, sans tracking d'erreurs, tu découvres les bugs quand un utilisateur t'écrit.
Pourquoi l'IA ne le voit pas. Elle code la feature, pas l'infrastructure d'observabilité. C'est un sujet ops, hors de son scope par défaut.
Ce qui manque presque toujours :
- Sentry ou équivalent pour les erreurs front et back
- Logs structurés (Pino, Winston) au lieu de console.log
- Monitoring uptime (UptimeRobot, BetterStack)
- Métriques métier (combien d'inscriptions/jour, combien d'erreurs payment/heure)
- Alerting Slack/email quand erreur critique
Coût caché. Tu mets des semaines à découvrir des bugs critiques. Pendant ce temps, tu perds des utilisateurs qui ne reviennent pas.
Comment fixer. Installation Sentry en 30 min, monitoring uptime gratuit avec UptimeRobot, logs structurés à mettre en place sur les flux critiques (auth, paiement, intégrations).
Limite 7 : impossible de faire intervenir une vraie équipe
Le problème. Tu lèves des fonds. Tu veux embaucher un CTO senior ou faire intervenir une agence pour scaler. Le développeur regarde le code, fait une grimace, et te dit "il faut tout réécrire".
Pourquoi. Le code généré sans structure, sans tests, sans documentation, sans conventions, sans architecture claire, est un repoussoir pour les développeurs expérimentés. Ils n'arrivent pas à raisonner dessus.
Coût caché. Tu paies 2 à 4 mois de réécriture pour atteindre un état "exploitable par une équipe". Pour un coût qui dépasse souvent 40 000€ à 100 000€. Pendant ce temps, tu ne fais pas évoluer le produit.
Cas réel. Un SaaS de gestion locative vibe-codé, levée seed 500K€. Le CTO recruté a refusé de continuer sur la base existante. Réécriture complète Next.js + Supabase + tests : 11 semaines, équivalent 65 000€ en interne. Pendant ce temps, perte de 3 clients enterprise impatients.
Comment fixer. À partir du moment où ton produit gagne en traction (50+ utilisateurs payants, 5 000+ visiteurs/mois), faire faire un audit indépendant avant de continuer à empiler les features.
Comment savoir si ton projet vibe-codé est en danger
Check-list rapide :
- Tu peux expliquer où sont stockés tes secrets ?
- Tu as au moins 1 type d'utilisateur authentifié qui peut tester les permissions ?
- Si tu coupes l'accès à un développeur tiers, peut-il reprendre ton code en 1 journée ?
- Tu as un monitoring qui t'alerte quand le site est down ?
- Tu peux restaurer une sauvegarde en moins de 1h ?
- Tu peux faire évoluer un endpoint sans casser 3 autres écrans ?
- Tu sais combien d'utilisateurs simultanés ton site supporte ?
Si tu réponds "non" à 3 questions ou plus, ton projet a besoin d'un audit avant le prochain palier de croissance.
FAQ
Non, ils sont excellents pour prototyper, valider une idée, sortir un MVP en quelques semaines. Ils deviennent problématiques quand le produit doit scaler, intégrer des services critiques, ou être maintenu par une équipe.
Quand tu atteins 50+ utilisateurs payants, 5 000+ visiteurs/mois, ou que tu lèves plus de 200K€. Avant, vibe coding reste pertinent. Après, le coût technique cumulé dépasse le gain de vitesse initial.
Entre 8 000€ (audit + fixes critiques) et 80 000€ (réécriture complète). Le coût dépend du niveau de dette accumulée et du périmètre fonctionnel à préserver. Chez FreshMarkom, une [refonte démarre à 1 490 €](/packages/refonte) et un [SaaS sur mesure à 9 990 €](/packages/saas-application-metier), le devis exact dépend de l'audit initial.
Oui, mais en mode "co-pilot" et plus en mode "agent autonome". Claude Code, Cursor, GitHub Copilot accélèrent un développeur expérimenté de 30 à 50%. Mais c'est le développeur qui structure, l'IA qui implémente.
Probablement oui sur 2 à 3 ans. Mais aujourd'hui, en 2026, les limites listées sont structurelles. Ils restent des outils de prototypage, pas de production.
Vibe coding si : tu veux valider une idée en moins de 6 semaines, tu n'as pas de levée à venir avant 6 mois, tu peux te permettre de tout réécrire si ça marche. Développement professionnel si : tu vises un produit utilisable en prod par 100+ utilisateurs payants dès le lancement, tu lèves des fonds, ou tu intègres des services critiques (paiement, RH, santé, finance).
En résumé
Les IA générateurs de code ont rendu le développement accessible à des dizaines de milliers de founders qui n'auraient pas pu le faire seuls. C'est une transformation positive.
Mais elles butent sur 7 limites structurelles quand il s'agit de tenir un vrai produit en prod : architecture, sécurité, dette technique, intégrations, performance, observabilité, et maintenabilité.
Si tu veux faire grandir un produit au-delà du MVP, il faut prévoir une étape de professionnalisation : audit indépendant, refactor des couches critiques, mise en place de l'infrastructure manquante. Ça coûte 8 000€ à 80 000€ selon l'ampleur. C'est toujours moins cher que la réécriture complète qu'on doit faire 12 mois plus tard si on attend.
Chez FreshMarkom, on fait régulièrement ces audits sur des produits vibe-codés. Si ton projet ressemble à un cas décrit ici, on peut te dire en 30 minutes ce qui doit être prioritaire.
Article mis à jour le 7 juin 2026 avec les tarifs officiels FreshMarkom en vigueur.