Lovable et Supabase pour un outil interne : coûts, sécurité et limites

Lovable peut produire rapidement l'interface d'une application web. Supabase apporte une base Postgres, l'authentification, le stockage et des fonctions serveur. L'ensemble convient bien à un back-office, un portail client ou une application de saisie terrain.

La rapidité de construction ne règle pourtant pas le reste. Une application métier doit gérer des droits, conserver les données, produire un résultat fiable et pouvoir être reprise par quelqu'un d'autre. Sans ces contrôles, une interface convaincante reste une démonstration.

À quoi sert chaque outil ?

Lovable accélère la création et l'évolution de l'application. Le projet produit du code web qui peut être synchronisé avec GitHub. Un développeur peut ensuite relire ce code, le modifier localement et le déployer sur une autre infrastructure.

Supabase porte généralement la partie backend :

• ·base de données Postgres ;
• ·comptes et sessions utilisateurs ;
• ·stockage de fichiers ;
• ·API générée à partir de la base ;
• ·fonctions serveur pour les traitements qui ne doivent pas vivre dans le navigateur.

Cette séparation est utile. L'interface peut évoluer sans transformer la base en boîte noire. Elle impose aussi de traiter les permissions et les migrations proprement.

Les projets qui s'y prêtent bien

Le duo fonctionne bien quand l'équipe a besoin d'une application web avec un nombre limité de parcours métier : gérer des dossiers, suivre une production, saisir des données sur le terrain, ouvrir un espace client ou remplacer un tableur partagé devenu fragile.

Le cas devient moins évident quand le besoin porte sur une application native exigeante, un fonctionnement hors ligne complexe, des contraintes réglementaires fortes ou une charge très élevée dès le lancement. La stack peut parfois suivre, mais la décision demande alors une étude d'architecture avant de promettre un délai.

Il faut aussi comparer avec les outils existants. Si 5 personnes ont seulement besoin d'une base partagée et de 2 formulaires, Airtable peut suffire. Une application sur mesure devient intéressante lorsque les rôles, les contrôles, les documents produits ou les intégrations dépassent ce qu'un paramétrage raisonnable peut maintenir.

Ce que coûte réellement l'infrastructure

Au 14 septembre 2026, Supabase affiche 2 points de départ faciles à comprendre :

• ·Free à 0 $ par mois, avec 500 Mo de base de données par projet et sans sauvegarde automatique incluse ;
• ·Pro à partir de 25 $ par mois. Les crédits de calcul inclus couvrent un premier projet en taille Micro ; la formule comprend notamment 8 Go de base de données, 250 Go de sortie de données et des sauvegardes quotidiennes conservées 7 jours.

Ces montants ne forment pas le coût complet d'une application. Il faut ajouter, selon le cas, l'hébergement du front, les emails transactionnels, le stockage, les appels à une IA, les cartes, la transcription ou une API métier.

Le plan Hobby de Vercel est gratuit, mais ses conditions le réservent aux usages personnels non commerciaux. Un outil utilisé par une entreprise doit donc passer par une offre compatible avec l'usage commercial ou par un autre hébergeur.

Pour une petite application interne, la facture technique peut rester faible. Le bon budget ne se déduit pas du nombre d'utilisateurs seul. Un besoin de sauvegarde, une API payante ou une forte consommation de fichiers peut compter bien davantage.

La RLS protège les données ligne par ligne

Dans une application classique, l'utilisateur se connecte puis le serveur décide ce qu'il peut faire. Avec Supabase, le navigateur peut aussi interroger directement l'API de la base. Cette facilité exige une deuxième barrière : la Row Level Security, ou RLS.

Une politique RLS peut exprimer des règles comme :

• ·un collaborateur voit uniquement les dossiers de son équipe ;
• ·un client consulte uniquement les projets rattachés à son compte ;
• ·un administrateur modifie les paramètres, mais un utilisateur standard ne fait que saisir des données ;
• ·une personne non connectée n'accède à aucune ligne privée.

Activer la RLS ne suffit pas. Il faut vérifier les droits accordés aux rôles anon et authenticated, écrire les politiques puis tester les opérations autorisées et interdites. Supabase recommande ce contrôle sur toutes les tables exposées.

Les clés service_role ou secrètes contournent ces politiques. Elles restent exclusivement côté serveur. Une clé publique dans le navigateur peut être normale, à condition que la RLS et les droits minimaux soient correctement configurés.

Une recette de sécurité minimale

Avant d'ouvrir l'application, je vérifie au moins les cas suivants :

• ·un utilisateur non connecté ne lit aucune donnée privée ;
• ·un utilisateur du compte A ne peut pas ouvrir une URL ou appeler une API pour lire le compte B ;
• ·chaque rôle peut créer, modifier et supprimer uniquement les objets prévus ;
• ·les fonctions serveur refusent une session absente ou invalide ;
• ·aucun secret capable de contourner les droits n'est présent dans le code livré au navigateur ;
• ·la sauvegarde et la restauration correspondent au risque réel du client.

Ces tests sont plus importants qu'un badge de sécurité affiché par un outil. La configuration du projet décide de la protection effective.

Ce que signifie vraiment « vous gardez le code »

Lovable permet de synchroniser le projet vers GitHub et les changements peuvent circuler dans les 2 sens. Le client peut cloner le projet, le faire relire et déployer le front ailleurs.

La base Supabase repose sur Postgres et peut être exportée. Lovable documente aussi des scénarios avec un Supabase géré, un Postgres équivalent ou une infrastructure auto-hébergée.

Cette portabilité réduit la dépendance sans la supprimer. Une migration peut demander de reprendre :

• ·l'authentification et les comptes ;
• ·le stockage des fichiers ;
• ·les secrets et variables d'environnement ;
• ·les fonctions serveur ;
• ·les domaines, certificats et règles de déploiement ;
• ·les sauvegardes, journaux et alertes.

L'éditeur et l'agent Lovable restent un service géré qui ne peut pas être auto-hébergé. Le code exporté peut être repris hors de Lovable, mais les services gérés encore utilisés doivent être conservés ou remplacés. Le mode d'édition assisté change également.

La réversibilité se vérifie donc dans les livrables : dépôt GitHub, migrations, schéma de données, liste des services, procédure de déploiement et accès administrateur. « Zéro dépendance » ne décrit pas la réalité d'une application moderne.

Un exemple de production sur le terrain

Une entreprise spécialisée dans la transformation, l'isolation et la restauration de fenêtres anciennes devait convertir des prises de cotes en données structurées, puis en documents exploitables par l'atelier. L'application web permet de choisir la configuration d'une fenêtre, saisir ou dicter les mesures, corriger les informations puis générer un PDF.

La recette technique sur un chantier de référence a vérifié les 13 fenêtres dans un PDF de 5 pages, sans doublon ni disparition. La version déployée permet aussi d'utiliser plusieurs comptes et de synchroniser les chantiers partagés.

Le test terrain a fait remonter un autre type de sujet : certaines dictées sur iPhone avec AirPods ont semblé trop longues ou sans résultat. Une requête serveur retrouvée s'est terminée en 12,877 secondes, sans expliquer les attentes de plus de 5 minutes rapportées. La cause reste à reproduire et à mesurer sur le terrain.

Ce cas résume bien la différence entre une démo et une application métier. Le parcours peut être techniquement validé tout en gardant un problème d'usage réel à mesurer et corriger.

Les limites à décider avant de construire

Le mode hors ligne

Une PWA peut garder certaines données dans le navigateur, mais la synchronisation après plusieurs modifications concurrentes demande des règles précises. « Fonctionne hors ligne » ne doit pas être ajouté en fin de projet comme une case à cocher.

La reprise des données

Importer un tableur demande bien plus que copier ses lignes. Il faut traiter les doublons, les valeurs libres, les statuts historiques et les relations entre feuilles. La qualité de la reprise peut dépasser le temps consacré aux écrans.

Les permissions

Les rôles doivent être décrits avec des exemples concrets. Qui voit un dossier archivé ? Qui corrige une donnée après validation ? Un client peut-il supprimer une pièce jointe ? Les réponses deviennent des politiques testables.

L'exploitation

Une V1 a besoin d'un propriétaire, d'une méthode de sauvegarde et d'un point de contact en cas d'erreur. Sans cela, l'application rejoint simplement la liste des outils que personne n'ose modifier.

Une grille de décision rapide

Choisissez d'abord Airtable, Notion ou un SaaS existant si le processus change encore chaque semaine, si les droits restent simples et si les documents produits sont standards.

Envisagez une application sur mesure si le processus est stable, si plusieurs profils ont des droits différents, si les erreurs de ressaisie coûtent réellement du temps ou si le résultat doit suivre une logique métier absente des logiciels disponibles.

Avant de choisir Lovable et Supabase, vérifiez 6 points :

1. 01Le parcours principal peut être décrit sur un dossier réel.
2. 02Une personne chez le client peut trancher les règles métier.
3. 03Les rôles et les données sensibles sont identifiés.
4. 04Le budget couvre une infrastructure autorisée pour l'usage commercial.
5. 05La recette inclut les refus d'accès et les résultats produits.
6. 06Le client reçoit les éléments nécessaires pour faire reprendre le projet.

Ce que Studio Sentai livre

Je construis la première version sur un périmètre fermé, puis je la teste avec des dossiers réels. Le livrable comprend l'application, la base, les rôles, les intégrations convenues, les tests critiques et la documentation de reprise. Le détail de la démarche figure sur l'offre Application métier sur mesure.

Le cadrage peut aussi conclure qu'un outil existant suffit. Le développement commence seulement quand le processus et le résultat attendu sont assez précis pour être testés.

Sources officielles

• ·Tarifs Supabase : https://supabase.com/pricing
• ·Checklist de mise en production Supabase : https://supabase.com/docs/guides/deployment/going-into-prod
• ·Sécuriser les données avec Supabase : https://supabase.com/docs/guides/database/secure-data
• ·Conditions du plan Hobby de Vercel : https://vercel.com/docs/plans/hobby
• ·Synchronisation GitHub de Lovable : https://docs.lovable.dev/integrations/github
• ·Hébergement, propriété et migration avec Lovable : https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership