Quelles sont les limites de Lovable AI à connaître avant de commencer ?

Par défaut, le HTML servi est minimal : le contenu est rendu en JavaScript côté navigateur. Google sait crawler le JS depuis plusieurs années, mais beaucoup d'autres robots (LLMs, agrégateurs, certains outils de veille) ne l'exécutent pas et ne voient qu'une page vide.

La parade : pré-rendre les routes publiques en HTML statique au build, ou ajouter un service de pré-rendu en amont (ex. Prerender.io). Lovable Web Agency le met en place systématiquement sur ses livrables via un script de pré-rendu post-build.

Lovable produit très bien des règles métier standards (permissions, workflows d'approbation simples, calculs de tarification classiques) via des edge functions et des policies RLS Supabase. La limite apparaît sur des moteurs de règles imbriquées avec dizaines d'exceptions (tarification dynamique multi-facteurs, moteurs de conformité réglementaire évolutifs).

Contournement possible : isoler la logique complexe dans un service dédié (edge function dédiée, microservice externe) appelé par l'app Lovable comme une brique métier autonome, testée et versionnée séparément.

Sur Supabase (Postgres managé), les performances restent bonnes jusqu'à plusieurs millions de lignes avec des index corrects. Les limites apparaissent sur des agrégations temps réel massives (tableaux de bord analytiques sur des dizaines de millions d'événements) ou sur du streaming à très haut débit.

Contournement possible : dénormaliser via des vues matérialisées, déporter l'analytique lourde vers un entrepôt dédié (BigQuery, ClickHouse) interrogé en asynchrone, ou paginer/agréger côté edge function plutôt que côté client.

Non directement : Lovable génère du web, pas d'application iOS/Android native. Il est néanmoins possible d'envelopper l'app web dans une PWA installable, ou de la wrapper avec Capacitor pour publier sur l'App Store et Google Play.

Contournement possible mais partiel : Capacitor donne accès aux capteurs (caméra, notifications push, biométrie) via des plugins, mais les animations et performances restent celles d'une webview, pas d'un rendu natif Swift/Kotlin pur.

Par défaut non : l'app dépend d'une connexion à Supabase pour l'auth et les données. Un mode offline complet avec synchronisation bidirectionnelle (conflits, résolution automatique) n'est pas un scénario natif de la plateforme.

Contournement limité : un service worker peut mettre en cache les assets statiques et permettre une consultation hors ligne des données déjà chargées, mais l'écriture offline avec sync différée nécessite une architecture spécifique (ex. RxDB, PouchDB) rarement justifiée pour un projet web/SaaS standard.

Pour la santé (HDS en France), la finance réglementée (DSP2, hébergement bancaire) ou certains marchés publics, l'hébergement et l'architecture par défaut de Lovable Cloud (Supabase) ne couvrent pas automatiquement les certifications sectorielles exigées.

Contournement possible avec audit : Supabase propose des offres Enterprise avec BAA (HIPAA) et options de résidence des données ; pour une certification HDS stricte, il faut généralement migrer l'hébergement vers un prestataire certifié et adapter l'architecture (chiffrement, journalisation, RLS renforcée), ce qui sort du périmètre standard d'un forfait Lovable Web Agency.

Lovable applique Tailwind et un design system cohérent. Pour un design ultra-spécifique (motion design lourd, WebGL, expériences créatives sur-mesure), il faut souvent écrire du code à la main par-dessus la génération.

C'est l'un des rares moments où l'expérience d'un développeur senior reste indispensable, et où le forfait standard doit être complété par un avenant dédié.

Lovable n'est pas le bon choix pour : une application mobile native exigeant des performances graphiques poussées (jeu vidéo, réalité augmentée) ; un produit offline-first pour des zones sans réseau fiable (terrain industriel isolé) ; un système soumis à une certification HDS ou bancaire stricte dès le premier jour ; un moteur de calcul scientifique ou de machine learning propriétaire consommant l'essentiel des ressources produit.

Dans ces cas, la bonne stratégie est souvent hybride : prototyper le produit et son marketing sur Lovable pour valider vite, puis confier la brique critique (natif mobile, moteur de calcul, certification) à une équipe spécialisée qui la connecte à l'app Lovable par API. Une agence honnête doit le dire avant la signature, pas après.

Pré-rendu pour le SEO, edge functions pour la logique sensible, Capacitor pour le mobile, services tiers pour les workloads spécialisés, audit dédié pour la compliance : presque toutes les limites ont une parade documentée et éprouvée.

Le rôle d'une agence Lovable est précisément d'identifier ces limites dès le cadrage et de proposer la bonne architecture en amont, plutôt que de les découvrir en cours de projet.