Mon app Lovable peut-elle tenir ma feuille de route ? La grille pour décider entre faire évoluer et refaire

L’application tourne, les premiers clients l’utilisent, et la feuille de route des six prochains mois est écrite : des rôles pour les équipes, une facturation par entreprise plutôt que par personne, deux intégrations demandées par vos plus gros comptes, peut-être une API et une application mobile. La question n’est plus de savoir si l’app marche. C’est de savoir si la base actuelle peut porter tout cela, ou si chaque nouvelle fonctionnalité va coûter plus cher que la précédente.

Cet article ne traite ni de qui fera le travail (voir continuer seul, prendre un freelance ou passer par un studio), ni du changement de framework (voir migrer une app Lovable vers Next.js). Il donne une grille à appliquer vous-même en une demi-journée, avec le dashboard Supabase, un terminal et votre feuille de route. Elle s’appuie sur une douzaine d’applications générées par IA que nous avons reprises et mises en production, dont une application RH et une messagerie chiffrée interne d’entreprise où il a fallu corriger de nombreuses failles de sécurité. Les faits sur Lovable et Supabase ont été vérifiés sur leurs documentations officielles en octobre 2026.

Ce qu’on évalue : les fondations, pas l’interface

Les écrans d’une app Lovable sont presque toujours la partie la plus solide du projet. Ce qui décide de la suite ne se voit pas en démo. Une fonctionnalité de roadmap coûte cher dans deux cas : quand elle oblige à changer la forme des données déjà en production, et quand personne ne peut vérifier qu’elle n’a rien cassé ailleurs. La grille mesure ces deux risques.

Étape 1 : traduire la roadmap en exigences techniques

Avant de regarder le code, écrivez ce que chaque fonctionnalité prévue demande à la base. Les cinq qui reviennent le plus sur une feuille de route SaaS :

Si aucune de ces lignes n’est sur votre roadmap, la grille sera indulgente : une app qui doit seulement gagner des écrans et des utilisateurs se fait évoluer presque toujours. Si trois ou quatre y sont, lisez la suite attentivement.

Étape 2 : la grille en sept points

Pour chaque point, notez vert, orange ou rouge. Les requêtes SQL se collent dans le SQL Editor de Supabase ; les commandes se lancent à la racine du dépôt GitHub de l’application. Si le code n’est pas encore dans un dépôt à votre nom, c’est le premier chantier, avant toute évaluation.

1. Le modèle de données

Un modèle sain relie ses tables par des clés étrangères, interdit les doublons par des contraintes d’unicité et refuse les valeurs absurdes. Un modèle généré par prompts successifs a souvent des tables qui se référencent par un identifiant stocké en texte, sans que la base garantisse le lien.

select conrelid::regclass as table_name,
       count(*) filter (where contype = 'f') as cles_etrangeres,
       count(*) filter (where contype = 'u') as contraintes_unicite,
       count(*) filter (where contype = 'c') as contraintes_check
from pg_constraint
where connamespace = 'public'::regnamespace
group by conrelid
order by 1;

Une table qui n’apparaît pas du tout n’a même pas de clé primaire. Cherchez ensuite les types qui coûteront cher plus tard :

select table_name, column_name, data_type
from information_schema.columns
where table_schema = 'public'
  and data_type in ('real', 'double precision', 'timestamp without time zone', 'json', 'jsonb');

Des montants en nombres à virgule flottante, des dates sans fuseau ou des données métier rangées dans une colonne JSON fourre-tout : chacun se corrige, mais chaque correction est une migration de données en production.

• Vert : clés étrangères sur les relations, contraintes d’unicité là où un doublon serait un bug, montants en entiers ou en numeric.
• Orange : quelques relations non contraintes, quelques types à corriger.
• Rouge : des relations portées par l’interface plutôt que par la base, ou des entités métier entières stockées en JSON.

2. L’isolation entre clients

C’est le point qui décide le plus souvent. Une app Lovable construite pour des utilisateurs individuels filtre ses données par user_id. Le jour où la roadmap parle d’équipes, chaque table, chaque règle RLS et chaque requête doit passer à une notion d’organisation. Cette requête liste les tables qui n’ont aucune colonne de rattachement à une organisation (adaptez les noms à votre vocabulaire) :

select t.table_name
from information_schema.tables t
where t.table_schema = 'public'
  and t.table_type = 'BASE TABLE'
  and not exists (
    select 1 from information_schema.columns c
    where c.table_schema = 'public'
      and c.table_name = t.table_name
      and c.column_name in ('organization_id', 'org_id', 'team_id', 'workspace_id')
  );

La facturation suit la même pente. L’intégration Stripe de Lovable rattache les abonnements aux utilisateurs par leur adresse e-mail, et n’utilise pas de webhooks par défaut : l’application interroge Stripe pour connaître l’état d’un abonnement (vérifié en octobre 2026). Pour un abonnement individuel, cela fonctionne. Pour une entreprise qui paie quinze sièges, il faut un abonnement rattaché à l’organisation, des événements Stripe reçus côté serveur, et des droits qui en découlent. Nous avons détaillé pourquoi ces deux décisions se rattrapent mal dans multi-tenant et facturation par abonnement.

• Vert : une table d’organisations, une table d’appartenance, des règles RLS qui passent par elle.
• Orange : tout est en user_id, mais il y a peu de tables et peu de données.
• Rouge : tout est en user_id, des dizaines de tables, des données réelles, et des équipes sur la roadmap à trois mois.

3. Où vit la logique métier

Dans une app Lovable en React et Vite, le navigateur parle directement à Supabase. La tentation est alors d’écrire les règles dans les composants : un calcul de prix, une vérification de quota, une transition de statut. Elles fonctionnent tant que tout le monde passe par l’interface, et deviennent contournables dès qu’on appelle l’API avec la clé publique. Elles bloquent aussi l’application mobile et l’API publique, qui devront réécrire chaque règle.

Comptez les fichiers qui écrivent directement dans la base :

grep -rlE "\.(insert|update|upsert|delete)\(" src | wc -l
grep -rnE "\.(insert|update|upsert|delete)\(" src | cut -d: -f1 | sort | uniq -c | sort -rn | head

Quelques fichiers de services qui concentrent les écritures, c’est sain. Des écritures réparties dans quarante composants signifient que la règle métier existe en plusieurs exemplaires, et qu’une modification en oubliera un.

• Vert : les écritures sensibles passent par des fonctions Postgres, des Edge Functions ou, sur TanStack Start, par du code serveur ; les composants appellent des services.
• Orange : logique dans le front, mais regroupée dans quelques fichiers.
• Rouge : logique dupliquée dans les composants, et des règles d’argent ou de droits qui ne sont vérifiées que dans le navigateur.

4. Les tests

Sans tests, chaque fonctionnalité se paie deux fois : pour la construire, puis pour réparer ce qu’elle a cassé. Lovable écrit de petits tests pour les règles que vous ajoutez ou modifiez, avec Vitest, rangés le plus souvent dans src/test, et les lance avant de déclarer le travail terminé. Mais les tests backend automatiques ne concernent que les applications TanStack Start créées depuis le 13 mai 2026, et les tests des Edge Functions ne sont écrits que sur demande (vérifié en octobre 2026). Un projet plus ancien peut n’avoir aucun test.

find . -path ./node_modules -prune -o \( -name "*.test.*" -o -name "*.spec.*" \) -print | wc -l

Le nombre compte moins que la couverture : un test vérifie-t-il qu’un utilisateur ne peut pas lire les données d’une autre organisation ? Un autre traverse-t-il le paiement ?

• Vert : des tests sur les parcours critiques et sur les droits, lancés automatiquement à chaque modification du dépôt.
• Orange : quelques tests unitaires, aucun sur les droits ni le paiement.
• Rouge : aucun test, et chaque prompt casse quelque chose ailleurs.

5. La dépendance aux Edge Functions

Pour un projet React et Vite, les Edge Functions sont le seul code serveur. Parfaites pour un appel d’API, un webhook ou un e-mail, elles le sont moins pour ce que demandent les intégrations : synchroniser un CRM, importer un gros fichier, rejouer une tâche échouée. Supabase fixe leurs limites : 256 Mo de mémoire, 2 secondes de temps CPU par requête (hors attente d’entrées-sorties), 150 secondes de durée maximale sur le plan gratuit, 400 secondes sur les plans payants (vérifié en octobre 2026). Et aucune file d’attente n’est intégrée : une reprise sur échec s’écrit à la main.

ls supabase/functions
grep -n "verify_jwt" supabase/config.toml

• Vert : quelques fonctions courtes, chacune avec un rôle clair, qui vérifient qui les appelle.
• Orange : beaucoup de fonctions, du code copié de l’une à l’autre, mais des traitements courts.
• Rouge : des intégrations lourdes prévues sur la roadmap, et tout le serveur concentré dans des fonctions qui atteignent déjà leurs limites ou dupliquent leur logique.

6. Les migrations

Lovable enregistre les migrations qu’il exécute, après votre approbation, dans le dossier supabase/migrations/ du projet (vérifié en octobre 2026). C’est une bonne base, à une condition : que personne n’ait modifié la base à la main entre-temps, depuis l’éditeur de tables ou le SQL Editor. Sinon, le dossier ne décrit plus la production, et chaque évolution du schéma devient un pari.

ls supabase/migrations | wc -l
supabase db diff --linked

La seconde compare les migrations du dépôt au projet Supabase lié : des différences signalent des modifications faites hors migrations. La méthode pour remettre les deux d’accord est dans notre check-list de mise en production.

• Vert : le dossier décrit la production, la base de test se reconstruit à partir de lui.
• Orange : quelques écarts identifiés, rattrapables par une migration de remise à niveau.
• Rouge : pas de dossier de migrations, ou des écarts que personne ne sait expliquer.

7. Où vit le backend

Le backend intégré, Lovable Cloud, est activé par défaut. La documentation précise que Lovable ne déplace pas un projet entre son backend intégré et votre propre projet Supabase en une étape, dans un sens comme dans l’autre : il faut exporter les données, connecter le nouveau backend et reconstruire le schéma (vérifié en octobre 2026). Et l’export de la base n’inclut ni les fichiers stockés, ni le code des Edge Functions, ni les secrets.

Ce n’est pas un défaut en soi. Cela devient un critère si la roadmap demande un contrôle direct sur la base : région de données imposée par un client, outils tiers branchés sur Postgres. Plus la base grossit, plus ce passage coûte.

• Vert : votre propre projet Supabase, à votre nom, ou Lovable Cloud sans exigence de la roadmap qui l’impose.
• Orange : Lovable Cloud, et une exigence client qui pointe vers un backend à votre nom.
• Rouge : cette exigence, plus des données volumineuses et des fichiers stockés à déplacer.

Étape 3 : confronter la grille à la roadmap

La grille seule ne décide rien. Un rouge sur l’isolation ne pèse pas si votre roadmap ne parle jamais d’équipes. Croisez chaque fonctionnalité prévue avec les points qui la conditionnent.

Les rôles dépendent des points 2 et 3. Supabase documente un modèle précis : une table user_roles, une table role_permissions, un hook d’authentification qui ajoute le rôle au jeton, et une fonction authorize() appelée par les règles RLS (vérifié en octobre 2026). Ce modèle s’ajoute bien sur une base qui a déjà des organisations. Sur une base en user_id avec la logique dans le front, il faut d’abord refaire l’isolation, puis réécrire les règles une à une.

La facturation par entreprise dépend des points 2, 4 et 5 : un abonnement rattaché à l’organisation, des webhooks signés et idempotents, et des tests qui prouvent qu’un abonnement résilié coupe bien l’accès.

Les intégrations dépendent des points 5 et 7. Une synchronisation qui dépasse les limites d’une Edge Function demande un vrai serveur ou un service de tâches. Sur TanStack Start, le serveur existe déjà ; sur React et Vite, c’est une brique à ajouter.

L’API publique est le cas où l’on est le plus tenté de réutiliser l’existant, et où il faut le moins le faire. Supabase génère une API REST à partir de la base, mais sa documentation rappelle que les nouveaux objets du schéma public deviennent accessibles par cette API même quand on ne voulait pas les exposer, et recommande de définir la surface exposée dans un schéma dédié, comme api (vérifié en octobre 2026). Une API publique, c’est un contrat avec vos clients : vous ne pouvez plus renommer une colonne sans casser leurs intégrations. Il lui faut une couche à part, avec ses clés, ses limites et ses versions.

Le mobile dépend surtout du point 3. Lovable ne génère pas d’application native ni de projet React Native : sa documentation propose une application web installable, ou un habillage de l’application publiée avec un outil comme Capacitor, hors de Lovable (vérifié en octobre 2026). Si cela suffit à vos utilisateurs, la base actuelle porte le mobile sans effort. Si vous voulez une vraie application native, toute règle écrite dans un composant web devra être réécrite, ou déplacée côté serveur.

Les signaux qui disent « refaire »

Un rouge isolé se corrige. Ce qui fait basculer vers une reconstruction, c’est la combinaison. Refaire les fondations se justifie quand au moins deux de ces signaux sont présents :

• la roadmap impose des organisations, et le modèle n’en a pas, avec des dizaines de tables et des données réelles à migrer ;
• les règles d’argent ou de droits ne vivent que dans le navigateur, dupliquées dans de nombreux composants ;
• aucun test, et des régressions à chaque modification, au point que vous n’osez plus toucher à certains écrans ;
• les migrations ne décrivent plus la production, et personne ne sait reconstruire la base à partir du dépôt ;
• les entités métier principales sont stockées en JSON ou reliées sans clés étrangères ;
• la roadmap demande une API publique ou une app native, et le point 3 est rouge.

À l’inverse, faites évoluer l’existant quand le modèle de données est vert ou orange, que l’isolation est pensée ou inutile, et que les écarts se corrigent un par un sans toucher à la forme des données : refaire serait payer deux fois ce que vous avez déjà. À quiconque propose une reconstruction, demandez quels points de la grille et quelles fonctionnalités de la roadmap la justifient. « Le code est sale » n’est pas une réponse.

Refaire ne veut pas dire tout jeter

Le verdict « refaire » porte presque toujours sur les fondations, pas sur le produit. Les écrans, le parcours validé par vos utilisateurs et vos contenus se gardent. On reconstruit le modèle de données avec l’isolation, la couche des règles métier, les migrations et les tests, souvent sur la même pile React et Supabase : changer de framework est une décision séparée.

Refaire peut aussi être partiel : une application dont seule la facturation est mal conçue se reprend module par module, avec ses tables et ses tests. La grille sert à délimiter ce qui doit l’être. Pour ce qui fait varier la facture, lisez ce que coûte la reprise d’une app Lovable.

Par où commencer

Écrivez d’abord la roadmap en exigences avec le tableau de l’étape 1, puis lancez les requêtes des points 1 et 2 : ce sont elles qui tranchent le plus souvent. Verts tous les deux, vous ferez évoluer l’existant en comblant les autres points au fil des fonctionnalités. Rouges tous les deux, avec des équipes et une facturation par entreprise à trois mois, reconstruisez les fondations avant de construire la suite.

Si vous ne savez pas lire les résultats, ou si la grille donne un mélange d’orange difficile à trancher, c’est la question que tranche notre audit de reprise d’application Lovable : sécurité, modèle de données, qualité du code, ce qui manque pour la production, et un verdict écrit sous 48 h, faire évoluer ou refaire, rapporté à votre feuille de route.