Mettre une app Lovable en production : la check-list avant d’ouvrir aux vrais utilisateurs

Une application Lovable peut avoir des règles d’accès irréprochables et lâcher quand même le jour de l’ouverture : les e-mails de confirmation n’arrivent pas, le premier vrai paiement n’active pas l’abonnement, un prompt modifie une table pendant que des clients l’utilisent, et personne ne s’en rend compte avant le premier message mécontent. Rien de tout cela n’est une faille de sécurité. C’est de l’exploitation, et c’est ce qui sépare une démo d’un service.

Nous avons déjà publié la check-list de sécurité Lovable et Supabase : RLS, clés, fonctions, stockage. Celui-ci couvre le reste. Il 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, Supabase, Stripe et les obligations légales ont été vérifiés sur les documentations officielles en octobre 2026.

Avant de commencer : où vit votre application ?

Deux questions changent la réponse à presque chaque point de cette liste.

Lovable génère du TanStack Start pour les nouveaux projets depuis le 13 mai 2026, avec un serveur ; les projets plus anciens restent en React et Vite, sans serveur propre, leur logique serveur vivant dans des Edge Functions. Le backend intégré, Lovable Cloud, est activé par défaut, mais un projet peut être branché sur votre propre compte Supabase.

1. La sécurité, en résumé

Ce point a son propre article. Avant tout le reste, vérifiez au minimum :

• le RLS actif sur chaque table, avec des règles qui ne laissent pas tout passer ;
• aucune clé secrète (service_role, sb_secret_, OpenAI, Stripe sk_live_) dans le code envoyé au navigateur ;
• des fonctions RPC et des Edge Functions qui vérifient qui les appelle ;
• des buckets de stockage privés pour tout ce qui n’est pas public, la confirmation d’e-mail active et des redirections d’authentification qui pointent vers votre domaine.

La méthode, point par point et sans savoir coder, est dans notre check-list de sécurité Lovable et Supabase.

2. Le domaine

Une adresse fournie par Lovable convient à une bêta privée, pas à un service que vous vendez. La documentation de Lovable indique que les domaines personnalisés sont réservés aux plans payants (vérifié en octobre 2026). Ce qu’elle précise, et qu’on découvre souvent trop tard :

• la propagation DNS peut prendre jusqu’à 72 heures, même si la plupart des changements passent en quelques heures. Ne branchez pas le domaine la veille du lancement ;
• la connexion peut échouer sur le nouveau domaine si les adresses de redirection de l’authentification ne l’incluent pas. Lovable l’ajoute lui-même pour son backend intégré ; avec votre propre projet Supabase, c’est à vous de l’ajouter dans les réglages d’authentification.

À tester. Inscription, connexion, lien de réinitialisation et lien magique, sur le domaine final, depuis une fenêtre de navigation privée.

3. Les e-mails transactionnels et leur délivrabilité

C’est le premier mur d’un lancement, et il a deux étages.

Le fournisseur par défaut ne sert qu’aux tests. Avec votre propre projet Supabase et sans SMTP configuré, Supabase refuse d’envoyer des messages aux adresses qui ne font pas partie de l’équipe du projet, et plafonne l’envoi à 2 messages par heure (vérifié en octobre 2026). Autrement dit, vos vrais utilisateurs ne reçoivent rien. Une fois votre propre SMTP enregistré, Supabase envoie à toutes les adresses, mais impose d’abord une limite basse de 30 messages par heure, à relever dans la page des limites de débit.

Sur Lovable Cloud, le chemin est différent : Lovable propose d’envoyer les e-mails d’authentification et les e-mails applicatifs depuis votre propre domaine, sur les plans payants, avec 50 000 e-mails transactionnels par mois inclus par espace de travail. Pour un projet React et Vite, les e-mails applicatifs (confirmation de commande, notification) passent par le backend intégré ; un projet TanStack Start peut les envoyer depuis son propre serveur.

Un e-mail envoyé n’est pas un e-mail reçu. Les règles de Gmail s’appliquent à tous les expéditeurs depuis février 2024 : SPF ou DKIM configuré pour le domaine d’envoi, et un taux de spam signalé inférieur à 0,3 % ; au-delà de 5 000 messages par jour, SPF, DKIM et DMARC sont tous trois exigés. Lovable crée par défaut un sous-domaine notify et gère lui-même SPF, DKIM et DMARC, mais prévient qu’un domaine neuf part d’une réputation neutre : les premiers envois peuvent finir en spam, et la délivrabilité s’améliore sur des semaines.

À tester. Inscrivez-vous avec une adresse Gmail, une adresse Outlook et une adresse professionnelle. Vérifiez que l’e-mail arrive en boîte de réception, que le nom d’expéditeur est le vôtre, que les liens mènent à votre domaine et pas à localhost. Faites-le une semaine avant l’ouverture, pas le jour même.

4. Une base de test séparée de la production

Lovable a proposé en bêta une séparation entre une base de test et une base de production. Sa documentation indique qu’elle retire cette séparation au 5 octobre 2026, remplacée par des brouillons qui permettent de prévisualiser plusieurs versions de l’application avant publication, mais sans seconde base de données (vérifié en octobre 2026).

Conséquence : par défaut, chaque prompt qui touche au schéma ou aux données travaille sur la base où vivent vos clients. Les options pour séparer :

• un second projet Supabase pour la préproduction, avec ses propres clés, ses propres utilisateurs de test et ses propres réglages d’authentification ;
• les branches Supabase, qui créent des environnements isolés à partir du projet principal. La documentation présente les branches persistantes comme adaptées à la préproduction, et précise qu’une branche démarre sans les données de production, sauf fichier d’amorçage ou option dédiée ;
• côté Stripe, un environnement de test distinct : chaque mode a ses propres clés, et les objets d’un mode ne sont pas accessibles dans l’autre.

Une préproduction qui partage la base de production n’en est pas une. Vérifiez que les deux environnements n’ont en commun aucune clé, aucune adresse de webhook, aucun compte d’envoi d’e-mails.

5. Les migrations : plus de modification à la main en production

Pendant le prototypage, on modifie la base depuis le SQL Editor ou l’éditeur de tables, ou on laisse un prompt le faire. Une fois des données réelles dedans, la documentation de Supabase est sans ambiguïté : modifier le schéma directement sur la base distante contourne l’historique des migrations, et la consigne pour une équipe est de ne jamais modifier la base distante à la main. Chaque changement de schéma devient un fichier de migration versionné dans le dépôt (supabase migration new, ou supabase db diff pour capturer un changement fait localement), appliqué d’abord sur la préproduction, puis en production (supabase db push).

Vous savez ainsi quel schéma tourne en production, et vous pouvez le reconstruire. Le retour arrière de Lovable, lui, ne vous sauvera pas : revenir à une version restaure le code seulement, et redéploie les Edge Functions en conséquence, mais n’annule pas les modifications de données faites par des migrations entre-temps (vérifié en octobre 2026).

À vérifier. Le dossier supabase/migrations du dépôt existe-t-il, et décrit-il vraiment la base de production ? Un supabase db diff contre la production qui renvoie des différences signale des modifications faites à la main.

6. Sauvegardes : savoir restaurer, pas seulement sauvegarder

L’article sécurité rappelle l’essentiel : rien sur le plan gratuit de Supabase, une sauvegarde quotidienne à partir du plan Pro, sans les fichiers du Storage. Trois précisions de la documentation des sauvegardes Supabase comptent (vérifié en octobre 2026) :

• une restauration rend le projet inaccessible, et l’interruption s’allonge avec la taille de la base. Ce n’est pas une opération à découvrir pendant un incident ;
• le Point-in-Time Recovery, qui restaure à la seconde près avec une perte de données de deux minutes au pire, est une option payante des plans Pro et supérieurs, qui demande au moins une instance Small. Une fois activé, il remplace les sauvegardes quotidiennes ;
• pour le plan gratuit, Supabase recommande des exports réguliers avec supabase db dump, conservés hors de la plateforme.

Sur Lovable Cloud, la page du backend intégré ne décrit ni la fréquence ni la durée de conservation des sauvegardes, mais prévient que supprimer la base efface aussi ses sauvegardes, les comptes utilisateurs et les fichiers stockés. Faites vos propres exports.

À faire une fois. Restaurez une sauvegarde sur un projet de test, chronométrez l’opération, notez les étapes. Vous saurez combien de temps votre service serait coupé.

7. Savoir quand ça casse

Sans supervision, vos utilisateurs sont votre système d’alerte. Trois niveaux suffisent pour commencer :

1. Les erreurs côté navigateur et côté serveur, remontées dans un outil de suivi d’erreurs (Sentry ou équivalent), avec une alerte par e-mail ou messagerie sur toute nouvelle erreur.
2. Une surveillance de disponibilité qui appelle toutes les quelques minutes une page ou une fonction qui interroge vraiment la base, pas seulement la page d’accueil statique.
3. Les journaux de la plateforme. Supabase sépare les journaux par service : passerelle d’API, Postgres, authentification, stockage, Edge Functions. Leur conservation dépend du plan, un jour sur le plan gratuit et sept jours sur le plan Pro (vérifié en octobre 2026) : un incident signalé lundi matin sur un projet gratuit a perdu ses traces. Lovable Cloud a son propre outil de journaux dans le projet.

Ajoutez une alerte sur les webhooks Stripe en échec (voir le point suivant) et sur chaque fonction qui coûte à l’appel, comme une API d’IA ou un envoi de SMS.

8. Stripe en mode live

Un paiement qui marche avec la carte de test ne dit presque rien du mode live. La documentation de l’intégration Stripe de Lovable donne plusieurs pièges, vérifiés en octobre 2026 :

• l’aperçu n’a pas d’environnement de test séparé : le projet utilise une seule clé à la fois, donc avec une clé live, un paiement fait depuis l’aperçu est réel ;
• les identifiants de prix changent entre le mode test et le mode live. Il faut recréer produits et prix en live et faire basculer l’application sur les nouveaux identifiants ;
• les webhooks sont désactivés par défaut : l’application interroge Stripe directement pour connaître l’état d’un paiement. Avec des abonnements, un prélèvement échoué doit pouvoir couper l’accès sans attendre que l’utilisateur revienne, ce qui suppose un webhook ;
• les abonnements sont rattachés aux utilisateurs par leur adresse e-mail : vérifiez ce qui se passe quand un client change d’adresse.

Pour les webhooks eux-mêmes, la documentation de Stripe pose les règles :

• vérifier la signature de chaque événement avec le corps brut de la requête et le secret de l’endpoint ;
• le secret est différent en test et en live, et l’endpoint doit être en HTTPS en production ;
• répondre vite par un code 2xx, avant tout traitement long ;
• ne pas compter sur l’ordre d’arrivée des événements, qui n’est pas garanti, et repérer les doublons par l’identifiant d’événement.

En live, Stripe retente une livraison échouée pendant trois jours au maximum. Au-delà, c’est à vous d’aller récupérer les événements non livrés : un webhook en panne pendant un long week-end se remarque.

À tester. Un vrai paiement avec votre propre carte sur l’application publiée, puis un remboursement. Une résiliation. Un webhook rejoué deux fois, qui ne doit pas créditer deux fois.

9. Les limites et les coûts qui montent avec l’usage

Une application Lovable coûte peu tant que personne ne l’utilise. Les limites à connaître avant d’ouvrir, d’après la grille tarifaire de Supabase et la documentation de facturation (vérifiées en octobre 2026) :

Sur le plan Pro, le plafond de dépense est activé par défaut ; on le désactive pour payer l’usage au-delà des quotas.

Sur Lovable Cloud, la logique est celle des crédits. Lovable utilise une seule réserve de crédits pour construire, héberger et faire tourner le backend. Les plans Free, Pro et Business reçoivent une enveloppe mensuelle pour l’usage du Cloud, que Lovable présente comme temporaire ; au-delà, l’hébergement et le backend consomment les crédits généraux. Quand l’espace de travail n’a plus de crédits, le site publié reste en ligne, mais les fonctions d’IA s’arrêtent et les applications qui reposent sur le backend intégré peuvent être mises en pause jusqu’à un rechargement. Sur les plans Pro et Business, une recharge automatique avec plafond mensuel limite ce risque. Pour le poste qui dérape le plus souvent, les appels d’IA, lisez notre article sur les factures d’API LLM qui explosent.

10. RGPD, mentions légales, cookies

Une application ouverte au public a les obligations d’un site d’entreprise. Les fiches de Service Public, mentions obligatoires et cookies et traceurs, mises à jour le 13 octobre 2026 et consultées en octobre 2026, donnent la liste :

• mentions légales : identité de la société, coordonnées, numéro RCS ou RNE, numéro de TVA le cas échéant, directeur de la publication, et l’hébergeur (nom, adresse, téléphone). Pour une application Lovable, identifiez qui héberge réellement le site et la base ;
• politique de confidentialité distincte des CGU ou CGV : responsable du traitement, finalités, base légale, durée de conservation, droits des personnes ;
• CGV accessibles si vous vendez à des particuliers ;
• cookies : consentement recueilli avant le dépôt, refus aussi simple que l’acceptation, retrait possible à tout moment. Les cookies strictement nécessaires (authentification, panier, langue) en sont dispensés ; certains outils de mesure d’audience aussi, mais seulement sous conditions, notamment s’ils servent exclusivement à produire des statistiques anonymes ;
• résiliation en ligne : la fiche mentionne une fonctionnalité gratuite de résiliation en ligne pour les contrats d’abonnement. Vérifiez si elle s’applique à votre clientèle.

Un point technique rejoint le juridique : la région des données. Sur Lovable Cloud, un projet utilise l’une des trois régions Amériques, Europe ou Asie-Pacifique, et on ne peut plus la changer une fois le backend activé. Si vos clients attendent des données hébergées en Europe, vérifiez-le avant d’y mettre des données réelles.

11. Le support et le retour arrière

Le jour de l’ouverture, quelque chose finira par mal se passer. Prévoyez qui le voit et comment revenir en arrière.

• Un canal de support lu tous les jours : une adresse e-mail visible dans l’application, et quelqu’un qui la relève.
• Une version connue comme bonne. Dans l’historique Lovable, la version en ligne porte un badge Published. Notez-la avant chaque publication importante. Revenir à une version précédente restaure le code, pas les données : un retour arrière se prépare donc avec une sauvegarde récente.
• Une page d’exploitation. Une seule page qui dit qui a accès à quoi (Lovable, Supabase, Stripe, DNS, fournisseur d’e-mails), comment restaurer la base, comment revenir à la version précédente, et qui prévenir. Tous ces comptes doivent être à votre nom ; nous avons expliqué pourquoi dans continuer seul, prendre un freelance ou passer par un studio.
• Une ouverture progressive : quelques dizaines d’utilisateurs d’abord, puis le reste, plutôt que tout le monde le même jour.

La check-list en un tableau

Par où commencer

Si vous n’avez qu’une journée : les e-mails (testés sur de vraies boîtes), Stripe en live avec un vrai paiement, une restauration de sauvegarde sur un projet de test, et un outil de suivi d’erreurs branché.

Si la liste est longue et que vous ne savez pas par où commencer, c’est ce que couvre notre audit de reprise d’application Lovable : sécurité, qualité du code, ce qui manque pour la production, et un verdict sous 48 h, garder et renforcer ou refaire. Pour savoir ce qui fait varier le budget de ces travaux, lisez ce que coûte la reprise d’une app Lovable, Bolt ou v0. Et si votre question est plutôt de quitter Lovable, migrer une app Lovable vers Next.js explique quand ce chantier se justifie, et pourquoi il ne remplace aucun des points ci-dessus.