Passer votre application Lovable en production
Cliquer sur Publish met votre app en ligne, pas en production. Nous sécurisons votre base Supabase, reprenons la main sur le code et outillons l'app pour accueillir de vrais clients, sans repartir de zéro.
Vous vous reconnaissez ?
Ces situations reviennent chez la plupart des porteurs de projet qui nous arrivent avec une app Lovable :
- Votre app est publiée, mais vous ne savez pas si elle est prête à accueillir de vrais clients
- Vous n'êtes pas sûr que les règles RLS de vos tables Supabase empêchent un utilisateur de lire les données d'un autre
- Une clé Supabase à privilèges complets se trouve peut-être dans le code envoyé au navigateur
- Le scan de sécurité de Lovable a remonté des alertes que vous ne savez pas corriger, ou n'a rien remonté et vous doutez
- Chaque nouvelle demande faite au chat casse une fonctionnalité qui marchait
- Vous testez vos modifications sur la même base que vos clients
- Un client B2B vous demande où sont hébergées ses données, et vous ne savez pas quoi répondre
Aucune de ces situations n'est un échec : Lovable est fait pour aller vite. La mise en production est une étape à part entière, que la plateforme ne peut pas faire à votre place.
Ce que Lovable fait déjà, et ce qui reste à votre charge
Lovable couvre une partie du chemin : l'hébergement de l'app, un backend intégré avec Lovable Cloud (base de données, authentification, stockage, fonctions serveur) et un scan de sécurité lancé à chaque publication, complété par un scan approfondi à la demande.
Ce que la plateforme ne peut pas décider pour vous, c'est qui a le droit de voir quoi dans votre métier. Elle ne teste pas non plus les parcours dont dépend votre chiffre d'affaires, ne vous alerte pas quand un client ne peut plus se connecter, et ne remplit pas vos obligations RGPD. Lovable le rappelle lui-même : chaque client de la plateforme reste responsable de la protection des données de son application.
Ce que nous vérifions en priorité sur une app Lovable
Les règles d'accès Supabase (RLS), table par table. Une règle activée mais trop large laisse la table ouverte : nous relisons chaque politique et testons avec plusieurs comptes, en appelant l'API directement et pas seulement via l'interface.
Les clés et les secrets. La clé publique de Supabase peut être dans le navigateur, la clé à privilèges complets jamais. Toute clé exposée est retirée du code puis changée, car elle a pu être copiée.
Les contrôles côté serveur. Un prix, une remise ou un droit d'accès vérifié uniquement à l'écran se contourne. Nous déplaçons ces contrôles sur le serveur et limitons les appels aux fonctions qui coûtent de l'argent, comme les appels à une API d'IA ou l'envoi d'emails.
Les données et le code. Sauvegardes vérifiées par un test de restauration, migrations de la base relues avant publication, synchronisation Git activée pour que le code vous appartienne, tests automatisés sur les parcours critiques et environnement de recette séparé de la production.
Rester sur Lovable ou en sortir : nous vous aidons à décider
Mettre en production ne veut pas forcément dire quitter Lovable. Pour une bêta ou un usage interne avec des données peu sensibles, rester sur la plateforme est souvent le bon choix. Avec des clients payants, plusieurs développeurs sur le code ou des exigences contractuelles d'hébergement, en sortir progressivement devient pertinent.
La sortie peut se faire par étapes : déployer d'abord l'interface chez un autre hébergeur grâce à Git, puis connecter un projet Supabase qui vous appartient. Deux points sont souvent oubliés. Les secrets stockés dans Lovable ne suivent pas le code et doivent être reconfigurés chez le nouvel hébergeur. Et la région d'hébergement d'une base Lovable Cloud est fixée à l'activation : si vos clients exigent l'Europe et que ce n'est pas le cas, la base doit être migrée.
Ce qui est inclus
Audit du code existant
Architecture, qualité du code, dépendances et failles de sécurité — un état des lieux écrit avant tout développement.
Sécurisation
Secrets sortis du code, authentification vérifiée, dépendances à jour, conformité RGPD si des données personnelles sont en jeu.
Mise en production
Tests automatisés, CI/CD, hébergement dimensionné et monitoring — pour déployer sans craindre chaque mise à jour.
Questions fréquentes
Oui. Lovable génère une base technique moderne, React côté interface et Supabase côté backend. Ce n'est pas l'outil qui pose problème en production, mais l'absence de relecture des règles d'accès, de tests et de surveillance. C'est précisément ce que nous mettons en place.
Non, mais c'est un bon point de départ. Le scan détecte les erreurs de configuration les plus courantes. Il ne peut pas savoir qui, dans votre métier, doit avoir accès à quelle donnée : ces règles demandent une relecture humaine, table par table.
Pas nécessairement. Nous évaluons avec vous ce qui justifie de rester ou de partir : volume d'utilisateurs, sensibilité des données, taille de l'équipe, exigences d'hébergement. Si une sortie est pertinente, elle se fait par étapes, sans interruption de service.
Oui, si vous restez sur Lovable. La synchronisation Git fonctionne dans les deux sens. Nous définissons avec vous les garde-fous, comme les tests à faire passer avant chaque publication, pour qu'une modification faite via le chat ne défasse pas ce qui a été sécurisé.
La région d'une base Lovable Cloud ne peut pas être modifiée après son activation. Si vos clients ou vos obligations exigent un hébergement en Europe, il faut migrer les données vers un projet Supabase situé dans la bonne région. Nous préparons et testons cette migration sur une copie avant toute bascule.
Chaque projet est chiffré sur devis après l'appel découverte et l'audit du code, selon la taille de l'app, l'état des règles d'accès et le périmètre visé. Le devis est fixé avant le démarrage.
Le détail complet de la méthode et du déroulé du projet est sur la page Vibe to Prod.
Pour préparer le terrain vous-même, lisez notre guide Mettre en production une app Lovable, la checklist.