Lovable a ses limites : quand réécrire en Next.js

J'ai vu ce schéma se répéter une douzaine de fois maintenant. Un fondateur crée un prototype SaaS dans Lovable un week-end. C'est magnifique. Les investisseurs sont impressionnés. Les utilisateurs s'inscrivent. Puis la réalité frappe : Google n'indexe pas les pages marketing, le flux d'authentification se casse quand vous ajoutez les espaces de travail d'équipe, vos requêtes Supabase commencent à entrer en collision entre les locataires, et vous réalisez que vous combattez l'outil au lieu de construire votre produit.

Lovable est véritablement impressionnant pour ce qu'il fait. Mais il y a une limite, et si vous construisez un vrai produit SaaS, vous allez la heurter. Cet article détaille exactement où Lovable s'effondre, quand vous devriez planifier une migration vers un Next.js personnalisé, et comment aborder la réécriture sans perdre la raison.

Table des matières

Lovable AI Builder Limitations: When to Rewrite in Next.js

Comprendre l'architecture de Lovable

Avant de parler des limitations, soyons clairs sur ce que Lovable produit réellement. Sous le capot, Lovable génère une application Vite + React avec rendu côté client (CSR). C'est tout. Pas de rendu côté serveur. Pas de génération de site statique. Pas de régénération statique incrémentielle. Pur CSR.

Ce n'est pas un secret -- la propre FAQ de Lovable sur le rendu l'admet. Ils recommandent le prérendu comme solution de contournement pour le SEO, et ils sont honnêtes que SSR est « plus difficile avec la configuration actuelle de Lovable ».

Le code généré utilise généralement :

  • React Router pour la navigation côté client
  • Supabase pour l'authentification et la base de données
  • Tailwind CSS pour le style
  • shadcn/ui composants

Pour un outil interne, un tableau de bord derrière l'authentification, ou un prototype rapide ? Cette pile va parfaitement bien. Les problèmes commencent quand vos exigences de produit dépassent ce qu'une application monopage peut gérer.

Ce que Lovable maîtrise bien

Credit là où c'est dû. Lovable excelle à :

  • Vitesse de prototype : Vous pouvez avoir une interface fonctionnelle en quelques heures, pas des semaines
  • Qualité de conception : Les interfaces générées ont un aspect soigné dès le départ
  • Intégration Supabase : Les flux d'authentification basiques et les opérations CRUD fonctionnent rapidement
  • Qualité des composants : Les composants shadcn/ui qu'il génère sont de qualité production

Le problème n'est pas la qualité -- c'est la portée. Lovable optimise pour atteindre v0.1 aussi rapidement que possible. Il n'optimise pas pour atteindre v2.0.

Le problème SEO : CSR est une impasse pour les pages publiques

C'est la limitation la plus immédiate et la plus douloureuse, et c'est celle qui surprend les fondateurs. Si votre SaaS a des pages publiques -- un site marketing, un blog, une documentation, des pages de tarification, du contenu généré par les utilisateurs qui devrait être indexable -- l'architecture CSR de Lovable travaille activement contre vous.

Voici ce qui se passe quand un crawler accède à une page générée par Lovable :

<!-- Ce que Googlebot (parfois) voit -->
<!DOCTYPE html>
<html>
  <head>
    <title>My SaaS App</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/assets/index-abc123.js"></script>
  </body>
</html>

Ce vide <div id="root"> est l'intégralité de votre contenu de page du point de vue de la plupart des crawlers. Le Web Rendering Service (WRS) de Google peut exécuter JavaScript et rendre du contenu CSR, mais il y a de vrais problèmes avec cela :

  1. Ce n'est pas garanti. Google peut ou ne peut pas rendre votre JavaScript. Quand il le fait, il peut y avoir un délai de quelques heures à quelques jours entre la découverte et le rendu.
  2. Tous les autres crawlers échouent. Les crawlers LLM (GPTBot, ClaudeBot, PerplexityBot), les dérouleurs de médias sociaux (Facebook, LinkedIn, Twitter/X, Slack, Discord), le rendu de Bing (moins fiable que celui de Google) -- aucun d'eux n'exécute de manière fiable du JavaScript.
  3. Le partage social est cassé. Partagez une page Lovable sur LinkedIn et vous obtenez une carte d'aperçu vide. C'est une terrible première impression pour un produit que vous essayez de développer.
  4. La visibilité dans la recherche IA est nulle. C'est de plus en plus important en 2026. Si Perplexity, ChatGPT Search, ou Claude ne peuvent pas voir votre contenu, vous n'existez pas dans les réponses générées par l'IA.

Comme Nati Elimelech l'a souligné dans un post LinkedIn très partagé : « L'architecture de Lovable (Vite + React CSR) est fondamentalement incompatible avec les exigences des crawlers modernes. »

La solution de contournement du prérendu de Lovable

Lovable offre bien le prérendu comme solution de contournement. Cela convertit votre application React dynamique en HTML statique au moment de la compilation. Cela fonctionne pour les pages véritablement statiques -- une simple page d'accueil, une page à propos. Mais c'échoue pour :

  • Le contenu de blog qui se met à jour fréquemment (vous devriez reconstruire à chaque publication)
  • Les pages de produits dynamiques (par exemple, galeries de modèles, listes de marché)
  • Les profils publics générés par les utilisateurs
  • La documentation avec versioning
  • N'importe quelle page où le contenu change plus d'une fois par jour

Comparez cela avec Next.js, où vous obtenez un contrôle du rendu par route :

// Génération statique au moment de la compilation (comme un article de blog)
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

// Rendu côté serveur à chaque requête (comme un profil utilisateur)
export const dynamic = 'force-dynamic';

// Régénération statique incrémentielle (revalider chaque 60 secondes)
export const revalidate = 60;

Cette flexibilité par route est quelque chose que Lovable ne peut tout simplement pas offrir. Quand nous construisons des projets Next.js pour les clients, ce contrôle granulaire du rendu est souvent la seule plus grande raison pour laquelle ils ont migré d'un outil CSR-only.

Complexité d'authentification au-delà de la connexion basique

L'intégration Supabase de Lovable gère les bases : connexion par email/mot de passe, liens magiques, peut-être OAuth avec Google. C'est suffisant pour un prototype. Ce n'est pas suffisant pour un SaaS production.

Voici où l'authentification devient compliquée et Lovable ne peut pas suivre :

Contrôle d'accès basé sur les rôles (RBAC)

Les vraies applications SaaS ont besoin de rôles. Une hiérarchie propriétaire, administrateur, membre, observateur au minimum. Quand vous êtes dans Lovable, implémenter RBAC signifie :

  • Écrire des politiques Supabase RLS (Row Level Security) personnalisées à la main
  • Gérer l'état des rôles côté client (ce qui est intrinsèquement non sécurisé pour les décisions d'autorisation)
  • Construire votre propre logique de type middleware dans les composants React

Dans Next.js, vous gérez l'autorisation au niveau du serveur avant que tout contenu ne soit envoyé :

// middleware.ts -- s'exécute avant le rendu de la page
import { NextResponse } from 'next/server';
import { createServerClient } from '@supabase/ssr';

export async function middleware(request) {
  const supabase = createServerClient(/* config */);
  const { data: { user } } = await supabase.auth.getUser();
  
  if (!user) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  const { data: membership } = await supabase
    .from('team_members')
    .select('role')
    .eq('user_id', user.id)
    .eq('team_id', extractTeamId(request.url))
    .single();

  if (membership?.role !== 'admin' && request.nextUrl.pathname.includes('/settings')) {
    return NextResponse.redirect(new URL('/dashboard', request.url));
  }

  return NextResponse.next();
}

Ceci s'exécute sur le serveur. L'utilisateur non autorisé ne verra jamais la page des paramètres, ne recevra jamais le HTML, n'obtiendra jamais le bundle JavaScript. Dans une application CSR, vous livrez le code et le cachez avec des vérifications côté client -- ce que n'importe quel utilisateur motivé peut contourner.

Gestion des sessions entre sous-domaines

Si votre SaaS utilise des sous-domaines (comme acme.votreapp.com), vous avez besoin de cookies qui fonctionnent entre sous-domaines, une logique d'actualisation des jetons qui gère les cas limites, et une validation de session qui ne fuit pas entre les locataires. Lovable ne vous donne pas l'infrastructure côté serveur pour gérer cela. Vous finissez par bricoler des solutions qui se cassent en production.

SSO d'entreprise (SAML/OIDC)

Une fois que vous vendez à des entreprises de plus de 50 salariés, quelqu'un demandera une intégration SAML ou OIDC. Cela nécessite une gestion des rappels côté serveur, un échange de jetons, et la création sécurisée de sessions. C'est fondamentalement un flux côté serveur. Essayer de l'implémenter dans une application CSR-only, c'est lutter contre la gravité.

Lovable AI Builder Limitations: When to Rewrite in Next.js - architecture

Données multi-locataires : où Lovable n'a pas de réponse

Multi-tenancy est le défi architectural définisseur du SaaS. Chaque requête doit être limitée à la bonne organisation. Chaque requête doit filtrer par locataire. Chaque donnée doit avoir des garanties d'isolation.

Lovable vous donne Supabase, qui peut gérer la multi-tenancy via les politiques RLS. Mais les modèles au niveau de l'application -- routage, contexte, récupération de données -- sont entièrement sur vous, et l'IA de Lovable ne génère pas de code conscient de la multi-tenancy.

Les deux modèles

Modèle Exemple Avantages Inconvénients
Basé sur le chemin app.com/[team]/dashboard Hébergement simple, pas de config DNS Moins de marque pour les clients
Basé sur le sous-domaine team.app.com Meilleure white-labellisation, URLs plus propres Nécessite SSL wildcard, config DNS, routage middleware

Next.js supporte les deux nativement. L'App Router avec ses segments dynamiques gère élégamment le routage basé sur le chemin :

app/
  [teamSlug]/
    dashboard/
      page.tsx
    settings/
      page.tsx
    billing/
      page.tsx

Pour le routage basé sur le sous-domaine, le middleware Next.js peut extraire le sous-domaine et résoudre le locataire avant que n'importe quel code de page ne s'exécute :

// middleware.ts
export function middleware(request) {
  const hostname = request.headers.get('host');
  const subdomain = hostname?.split('.')[0];
  
  // Réécrire l'URL pour inclure le contexte du locataire
  if (subdomain && subdomain !== 'www' && subdomain !== 'app') {
    return NextResponse.rewrite(
      new URL(`/${subdomain}${request.nextUrl.pathname}`, request.url)
    );
  }
}

Dans Lovable, vous fileriez cela avec React Router et des hooks personnalisés, feraient des appels de récupération côté client pour résoudre le locataire, et géreriez les flashs du mauvais contenu de locataire pendant les états de chargement. J'ai vu ça se mal passer. Ce n'est pas joli.

Préoccupations concernant l'isolation des données

Le bug de multi-tenancy le plus effrayant est une fuite de données -- afficher les données du Locataire A au Locataire B. Dans une architecture rendue côté serveur, vous pouvez appliquer la limitation de la portée du locataire au niveau de la couche de données avant que la réponse ne soit envoyée. En CSR, vous faites confiance au code côté client pour passer le bon ID de locataire à votre API, et vous espérez que vos politiques RLS rattrapent tout le reste.

RLS est votre filet de sécurité, pas votre défense primaire. Votre défense primaire devrait être un middleware côté serveur qui valide le contexte du locataire à chaque requête. Lovable ne vous donne pas cette couche.

Mise à l'échelle au-delà du SaaS de démarrage

Il existe un ensemble de problèmes qui ne se manifestent que lorsque vous avez de vrais utilisateurs, de vraies données, et de vraies exigences métier. Le code généré par Lovable n'est pas conçu pour ces scénarios.

Performance à l'échelle

Une application Lovable livre votre application entière en tant que bundle JavaScript. Au fur et à mesure que votre application grandit, le bundle aussi. React Router charge tout dans la mémoire du client. Les utilisateurs sur des connexions plus lentes ou des appareils plus anciens sentent cela.

Next.js vous donne un fractionnement de code automatique au niveau de la route. Naviguez vers /dashboard et vous chargez seulement le code du dashboard. Naviguez vers /settings et seulement le code des paramètres se charge. C'est automatique -- vous ne le configurez pas.

Tâches en arrière-plan et logique côté serveur

Les vrais applications SaaS ont besoin :

  • De gestionnaires de webhook (Stripe, SendGrid, intégrations tierces)
  • De tâches planifiées (cycles de facturation, génération de rapports, nettoyage des données)
  • Envoi d'emails avec modèles côté serveur
  • Génération de PDF
  • Traitement de fichiers

Aucun de ceci n'est possible dans une application CSR-only. Vous auriez besoin d'un backend séparé. Avec Next.js, vous pouvez gérer les webhooks et la logique côté serveur directement :

// app/api/webhooks/stripe/route.ts
export async function POST(request: Request) {
  const body = await request.text();
  const sig = request.headers.get('stripe-signature');
  
  const event = stripe.webhooks.constructEvent(body, sig, webhookSecret);
  
  switch (event.type) {
    case 'customer.subscription.updated':
      await updateSubscription(event.data.object);
      break;
    case 'invoice.payment_failed':
      await handleFailedPayment(event.data.object);
      break;
  }
  
  return Response.json({ received: true });
}

C'est un vrai endpoint API exécutant du code côté serveur, dans la même base de code que votre frontend. Pas de serveur Express séparé. Pas de déploiement séparé.

Tester et CI/CD

Les projets générés par Lovable ne viennent pas avec l'infrastructure de test. Pas de tests unitaires, pas de tests d'intégration, pas de tests E2E. Pour un prototype, c'est bien. Pour un SaaS production qui gère les paiements des clients et les données sensibles, c'est une responsabilité.

Les projets Next.js s'intègrent naturellement avec Jest, Vitest, Playwright, et Cypress. Vous pouvez tester les composants serveur, les routes API, et le middleware isolément.

Quand migrer : le cadre de décision

Pas tous les projets Lovable ont besoin d'une réécriture. Voici un cadre pratique :

Rester sur Lovable si :

  • Vous êtes pré-product-market fit et validez encore
  • Votre application est entièrement derrière l'authentification (aucune page publique nécessaire pour le SEO)
  • Vous avez un modèle mono-locataire (un utilisateur, un compte)
  • C'est un outil interne ou un panneau administrateur
  • Votre équipe n'a pas de ressources développeurs

Planifiez une migration si :

  • Vous avez besoin du trafic de recherche organique vers les pages publiques
  • Vous ajoutez des espaces de travail d'équipe/organisation
  • Les clients d'entreprise demandent SSO
  • Vos politiques Supabase RLS deviennent un fouillis de spaghetti
  • Vous avez besoin d'intégrations côté serveur (webhooks, traitement des paiements)
  • Les temps de chargement des pages augmentent à mesure que votre application grandit
  • Vous passez plus de temps à combattre Lovable qu'à construire des fonctionnalités

Migrer immédiatement si :

  • Vous avez eu (ou avez presque eu) une fuite de données multi-locataires
  • Google Search Console affiche des défaillances d'indexation sur les pages importantes
  • Vous perdez des contrats en raison des exigences de SSO/sécurité
  • Votre bundle client dépasse 500 Ko compressé

Comment aborder la réécriture

La pire chose que vous puissiez faire est de tenter une réécriture big-bang où vous reconstruisez tout de zéro et basculez le commutateur. C'est comme ça que les réécritures meurent.

Le modèle de la figue étrangleuse

L'approche la plus intelligente est incrémentale. Déployez votre application Next.js aux côtés de votre application Lovable et migrez les routes une à la fois.

  1. Commencez par les pages publiques. Déplacez votre site marketing, blog, et documentation vers Next.js avec SSR/SSG approprié. Cela vous donne des gains SEO immédiats.
  2. Migrez la couche d'authentification. Implémentez votre flux d'authentification dans le middleware Next.js. C'est la partie la plus difficile -- faites-la en premier.
  3. Migrez feature par feature. Commencez par les pages les plus simples et avancez vers les plus complexes.
  4. Réutilisez vos composants. Lovable génère des composants React. La plupart fonctionneront dans Next.js avec des modifications minimales -- principalement en supprimant les dépendances de React Router et en convertissant vers le routage basé sur les fichiers.

Il y a même un outil CLI (NextLovable) qui automatise une partie de la conversion structurelle :

npx @nextlovable/cli convert ./src/components/ -f app-router

Il gère la conversion de la structure des fichiers du répertoire des composants plat de Lovable vers le modèle de mises en page imbriquées de l'App Router de Next.js. Il ne gérera pas votre logique métier, mais cela vous économise des heures de déplacement de fichiers fastidieux.

Quoi budgétiser

Une chronologie de migration réaliste pour un SaaS de complexité moyenne (10-20 pages, authentification, multi-tenancy basique) :

Phase Chronologie Effort
Pages publiques + SEO 1-2 semaines Faible
Authentification + middleware 2-3 semaines Élevé
Migration du dashboard 3-4 semaines Moyen
Routes API + webhooks 1-2 semaines Moyen
Test + QA 1-2 semaines Moyen
Total 8-13 semaines --

Si vous préférez ne pas passer trois mois sur la migration, c'est exactement le type de projet que nous gérons. Nous en avons assez fait pour connaître les zones de mines.

Lovable vs Next.js personnalisé : comparaison côte à côte

Capacité Lovable (Vite + React CSR) Next.js personnalisé
Temps de prototype Heures Jours à semaines
SSR / SSG / ISR ❌ Aucun (prérendu seulement) ✅ Plein support, par-route
SEO pour les pages publiques ⚠️ Mauvais (dépend du rendu JS de Google) ✅ Excellent
Visibilité dans la recherche IA ❌ Invisible aux crawlers LLM ✅ Entièrement visible
Cartes d'aperçu social ❌ Cassées ✅ Images OG dynamiques
Multi-tenancy ⚠️ Manuel, côté client uniquement ✅ Middleware + côté serveur
Authentification (basique) ✅ Intégration Supabase ✅ Plusieurs fournisseurs
Authentification (SSO d'entreprise) ❌ Pas de support côté serveur ✅ Support SAML/OIDC
Routes API ❌ Besoin d'un backend séparé ✅ Intégré
Fractionnement de code ⚠️ Manuel ✅ Automatique par-route
Infrastructure de test ❌ Aucun généré ✅ Écosystème complet
Flexibilité de déploiement Hébergement Lovable ou Netlify/Vercel (statique) Vercel, AWS, Docker, auto-hébergé
Coût à l'échelle $20-50/mo (Lovable) + Supabase L'hébergement varie ($0-200+/mo)

FAQ

Puis-je utiliser Lovable pour mon site marketing SaaS et Next.js pour l'application ?

Vous pouvez, mais cela crée une surcharge de maintenance. Vous aurez deux bases de code, deux pipelines de déploiement, et potentiellement un design incohérent. Une meilleure approche est de tout construire dans Next.js -- utilisez la génération statique pour les pages marketing et les composants serveur pour l'application. Si vous êtes déjà sur Lovable, commencez par migrer seulement les pages accessibles au public vers Next.js et gardez l'application sur Lovable jusqu'à ce que vous soyez prêt pour une migration complète.

Le prérendu de Lovable résout-il le problème SEO ?

Partiellement. Le prérendu génère du HTML statique au moment de la compilation, que les crawlers peuvent lire. Cela fonctionne pour les pages qui changent rarement -- une page à propos, une page de tarification. Mais cela ne fonctionne pas pour le contenu dynamique comme les articles de blog qui se mettent à jour fréquemment, le contenu généré par les utilisateurs, ou les listes de marché. Vous devriez déclencher une reconstruction chaque fois que le contenu change, ce qui devient impraticable rapidement. L'ISR de Next.js (Régénération Statique Incrémentielle) gère cela élégamment en revalidant les pages selon un horaire ou à la demande.

Combien coûte généralement une migration Lovable-vers-Next.js ?

Pour un prototype simple (5-10 pages, authentification basique), attendez-vous à 2-4 semaines de temps développeur. Pour un SaaS de complexité moyenne avec multi-tenancy, flux d'authentification personnalisés, et intégrations API, budgétez 8-13 semaines. Aux tarifs d'agence, c'est environ $15,000-$50,000 selon la complexité. Vous pouvez vérifier notre tarification pour les spécificités, ou nous contacter pour un devis limité basé sur votre base de code réelle.

Est-il possible de migrer progressivement de Lovable vers Next.js ?

Absolument, et c'est l'approche recommandée. Utilisez le modèle de la figue étrangleuse : déployez Next.js aux côtés de votre application Lovable, migrez les routes une à la fois en commençant par les pages accessibles au public, et utilisez un proxy inverse ou un routage DNS pour servir les deux applications du même domaine. Les outils comme le CLI de NextLovable peuvent automatiser certaines parties de la conversion structurelle.

Qu'en est-il d'Astro à la place de Next.js pour les pages publiques ?

Astro est excellent pour les sites riches en contenu avec une interactivité minimale. Si vos pages publiques sont surtout du contenu marketing statique et que votre application est une SPA séparée, Astro est un excellent choix. Mais si vous voulez une seule base de code unifiée pour à la fois les pages marketing et votre application dynamique, Next.js est l'option plus pratique. Nous construisons avec les deux selon les besoins du client -- tout se résume à la quantité d'interactivité que vos pages publiques nécessitent.

Mes composants React Lovable fonctionneront-ils dans Next.js ?

La plupart fonctionneront avec des modifications mineures. Les changements principaux sont : suppression des imports React Router et utilisation de Link et useRouter de Next.js à la place, ajout de directives 'use client' aux composants qui utilisent des hooks comme useState ou useEffect, et remplacement des utilitaires spécifiques à Lovable. La logique des composants et le style (classes Tailwind, composants shadcn/ui) se transfèrent directement.

Si je ne suis pas développeur -- puis-je toujours m'éloigner de Lovable ?

Oui, mais vous aurez besoin d'aide développeur. La migration est un projet technique. Vous pouvez embaucher un développeur freelance Next.js, utiliser une agence de développement headless comme nous, ou utiliser le CLI NextLovable pour bien démarrer puis apporter de l'aide pour les parties complexes. La bonne nouvelle est que le code généré par Lovable est propre et bien structuré, ce qui le rend plus facile pour un développeur à travailler que la plupart des bases de code générées par IA.

Quand Lovable est-il toujours le bon choix en 2026 ?

Lovable est idéal pour les outils internes, les panneaux administrateurs, les tableaux de bord qui vivent derrière l'authentification, les MVPs que vous montrez aux investisseurs, et les prototypes rapides pour les tests utilisateur. Si personne en dehors de votre équipe n'a besoin de trouver votre application par la recherche, et vous n'avez pas besoin d'authentification complexe ou de multi-tenancy, Lovable peut vous porter étonnamment loin. La clé est d'être honnête avec vous-même sur quand vous avez dépassé -- et de ne pas attendre que la dette technique vous écrase avant de commencer à planifier la migration.