Checklist : votre application est-elle prête pour de vrais clients ?

Le risque. Sans règles, toute personne qui récupère l’adresse de votre base et la clé publique de l’app (visible dans le navigateur) peut lire vos tables. En 2025, la faille CVE-2025-48757 a montré que 170 apps Lovable sur 1 645 analysées laissaient ainsi des données lisibles sans connexion.

Comment vérifier. Ouvrez la console de votre base de données et vérifiez, table par table, que les règles d’accès sont actives. Si vous n’avez pas accès à cette console, c’est déjà une réponse : demandez cet accès (voir la section Comptes et propriété).

• Supabase Le Security Advisor (menu Advisors) signale les tables du schéma public sans RLS (Row Level Security). Dans le SQL Editor, la requête « select tablename, rowsecurity from pg_tables where schemaname = 'public'; » doit renvoyer true sur chaque ligne.
• Lovable Lancez le scan de sécurité proposé avant publication : c’est un bon premier filtre, pas une garantie. Lovable Cloud repose aussi sur Supabase : les mêmes règles s’appliquent.
• Firebase Ouvrez Firestore Database > Règles, puis Storage > Règles. « allow read, write: if true; » ouvre tout. Une règle du mode test (« request.time < timestamp.date(…) ») ouvre tout jusqu’à sa date, puis bloque l’app.
• Bolt Si l’app est reliée à Supabase, faites la vérification Supabase ci-dessus. Avec Bolt Cloud, la section base de données propose un audit de sécurité (Security Audit) : lancez-le.

Le risque. Des règles actives ne suffisent pas si elles laissent tout passer. Une règle du type « tout utilisateur connecté peut tout lire » expose les commandes, messages ou documents de vos autres clients.

Comment vérifier. Créez deux comptes de test, A et B. Avec A, créez une donnée (une commande, un profil, un document). Connecté avec B, essayez de la retrouver : recherche, listes, ou identifiant changé dans l’adresse de la page. Si B voit quoi que ce soit de A, c’est non. Ce test ne remplace pas une relecture des règles, mais il attrape les erreurs les plus graves.

• Supabase Une règle (policy) écrite « using (true) » laisse passer tout le monde. Sur une table privée, la règle doit relier la ligne à l’utilisateur, par exemple « auth.uid() = user_id ».
• Firebase « allow read: if request.auth != null » autorise n’importe quel utilisateur connecté à tout lire. La règle doit comparer request.auth.uid au propriétaire du document.

Le risque. Masquer un bouton « admin » ne protège rien : un utilisateur curieux peut interroger la base ou l’API directement. Les rôles, remises et limites doivent être contrôlés là où il ne peut pas les modifier.

Comment vérifier. Demandez à la personne qui a construit l’app : « Où est stocké le rôle admin, et qui vérifie qu’un utilisateur l’a avant de lui donner accès ? » La bonne réponse cite une règle de la base ou une fonction serveur, pas une condition dans un écran.

• Supabase Le rôle ne doit pas être rangé dans user_metadata : l’utilisateur peut modifier ce champ lui-même. Préférez app_metadata ou une table de rôles protégée par RLS.
• Firebase Utilisez des custom claims définis côté serveur (Admin SDK) et vérifiez-les dans les règles de sécurité.

Le risque. Un fichier rangé dans un espace public est accessible à toute personne qui a son lien, sans connexion. Et les liens finissent dans des emails, des captures d’écran ou des historiques.

Comment vérifier. Dans la console, vérifiez que les espaces de stockage des fichiers privés ne sont pas publics. Test simple : copiez l’adresse d’un document privé, puis ouvrez-la le lendemain dans une fenêtre de navigation privée, sans être connecté. S’il s’affiche encore, posez la question.

• Supabase Storage : un bucket marqué « Public » est lisible par tous. Les fichiers privés vont dans un bucket privé, avec des liens signés qui expirent et des règles RLS sur storage.objects.
• Firebase Vérifiez Storage > Règles : mêmes pièges que pour Firestore (« if true », mode test).

Le risque. Si n’importe qui peut créer un compte, une règle « réservé aux utilisateurs connectés » devient « ouvert à tous ». Sans confirmation de l’email, on peut aussi s’inscrire avec l’adresse de quelqu’un d’autre.

Comment vérifier. Essayez de créer un compte depuis une fenêtre de navigation privée, avec une adresse que l’app ne connaît pas. Pour un outil interne ou réservé à des clients invités, cela ne devrait pas être possible. Pour une app grand public, l’email doit être confirmé avant tout accès aux données.

• Supabase Les réglages d’authentification permettent de fermer les nouvelles inscriptions, d’exiger la confirmation de l’email et d’ajouter un CAPTCHA (hCaptcha ou Cloudflare Turnstile).
• Bolt Avec Bolt Cloud, Bolt recommande aussi d’activer « Prevent Leaked Passwords » dans les réglages d’authentification par email.

Le risque. Tout ce que le navigateur télécharge peut être lu par n’importe quel visiteur. Une clé secrète Supabase contourne toutes vos règles d’accès ; une clé secrète Stripe ou OpenAI permet de rembourser, facturer ou consommer à vos frais.

Comment vérifier. Ouvrez votre app dans Chrome, appuyez sur F12, puis sur Ctrl+Maj+F (Cmd+Option+F sur Mac) pour chercher dans tous les fichiers chargés. Cherchez sk_live_, rk_live_, sk-proj-, sb_secret_ et service_role. Les clés publiques sont normales : pk_live_ chez Stripe, sb_publishable_ ou la clé anon chez Supabase, apiKey chez Firebase.

• Supabase L’ancienne clé service_role est une longue chaîne qui commence par eyJ : cherchez plutôt ses 10 derniers caractères, copiés depuis les réglages API Keys du projet.
• Lovable Les variables qui commencent par VITE_ sont intégrées au code envoyé au navigateur : aucune clé secrète ne doit en faire partie. Les secrets se rangent dans les secrets Supabase ou Lovable Cloud et ne servent que dans les Edge Functions.
• Bolt Même règle pour VITE_, NEXT_PUBLIC_ (Next.js) et EXPO_PUBLIC_ (apps Expo) : ces variables sont publiques par construction.
• Firebase La clé apiKey de la configuration Firebase est faite pour être publique : votre protection, ce sont les règles de sécurité.

Le risque. Si l’app appelle OpenAI ou un service de SMS sans limite, un seul utilisateur, ou un robot, peut faire monter la facture bien au-delà de ce que vous aviez prévu.

Comment vérifier. Demandez : « Où est appelée l’API d’IA, et combien de requêtes un même utilisateur peut-il faire par jour ? » La clé doit rester sur le serveur, et une limite doit exister. Réglez aussi un budget mensuel ou des alertes chez chaque fournisseur.

• Supabase Les appels se font dans une Edge Function, avec la clé rangée dans les secrets du projet. La vérification du JWT doit rester active, pour que seuls les utilisateurs connectés puissent l’appeler.
• Firebase Les appels se font dans une Cloud Function. App Check aide à bloquer les appels qui ne viennent pas de votre app.

Le risque. Une clé partagée avec un ancien freelance, collée dans un message ou envoyée sur GitHub reste valable tant qu’on ne la change pas. Sans procédure, on hésite à le faire, de peur de casser l’app.

Comment vérifier. Faites la liste : chaque clé, le service concerné, où elle est stockée, qui la connaît, et comment la régénérer (chez Stripe, par exemple, depuis l’espace développeurs). Vérifiez aussi qu’aucun fichier .env ne se trouve dans le dépôt GitHub. Quand un prestataire quitte le projet, changez les clés qu’il connaissait.

• Supabase Vous pouvez créer plusieurs clés secrètes (sb_secret_…), une par usage, pour n’en changer qu’une en cas de fuite. Les anciennes clés anon et service_role restent valables tant que vous ne les désactivez pas dans les réglages API Keys.

Le risque. Si l’outil, la base, l’hébergeur ou Stripe sont au nom d’un freelance ou d’une agence, vous ne pouvez rien changer sans eux. C’est aussi l’une des premières questions d’un investisseur ou d’un repreneur.

Comment vérifier. Faites un tableau : outil de création (Lovable, Bolt…), base de données, GitHub, hébergeur, nom de domaine, Stripe, service d’emails, fournisseur d’IA, comptes développeur Apple et Google. Pour chacun : propriétaire, email de connexion (une adresse de votre domaine, que vous contrôlez), carte de paiement. Vous devez être propriétaire (Owner), pas simple invité. Chez Apple, le rôle « Account Holder » doit revenir à votre société.

• Supabase Dans les réglages de l’organisation, onglet Team : votre compte doit avoir le rôle Owner.
• Firebase Dans Google Cloud, page IAM du projet : votre compte doit avoir le rôle Propriétaire (Owner).
• Lovable Avec Lovable Cloud, la base est hébergée par Lovable et non dans votre propre compte Supabase : vérifiez comment exporter vos données si vous deviez partir.

Le risque. Un seul accès, c’est un seul point de rupture : un téléphone perdu, un départ ou un compte piraté, et plus personne ne peut intervenir sur la production.

Comment vérifier. Pour chaque compte du tableau précédent, vérifiez qu’il y a deux administrateurs (vous et une personne de confiance) et que la double authentification est activée. Rangez les codes de secours dans un gestionnaire de mots de passe.

Le risque. Tant que le code ne vit que dans l’outil qui l’a généré, vous ne pouvez ni le faire relire, ni confier le projet à un développeur, ni changer d’outil sans repartir de zéro.

Comment vérifier. Connectez-vous à GitHub avec votre compte : le dépôt doit être dans votre compte ou votre organisation, et sa dernière mise à jour doit correspondre au dernier changement de l’app.

• Lovable La synchronisation GitHub crée le dépôt dans le compte ou l’organisation de votre choix, puis le tient à jour à chaque modification.
• Bolt Bolt permet d’exporter vers GitHub ou de télécharger le projet : vérifiez que la copie est à jour après chaque évolution importante.
• Base44 L’export (ZIP ou GitHub, sur les offres payantes) donne le front React et les fichiers de fonctions, pas un back-end autonome : la base et l’authentification restent chez Base44.
• FlutterFlow Sur les offres payantes, le code Flutter se télécharge ou s’envoie vers GitHub.

Le risque. Un domaine expiré coupe le site, l’app et souvent les emails. Si votre app tourne encore sur l’adresse fournie par l’outil (…lovable.app, par exemple), passer tôt sur votre domaine évite de changer tous vos liens plus tard.

Comment vérifier. Chez votre registraire (OVHcloud, Gandi, Cloudflare…), vérifiez le titulaire, la date d’expiration et le renouvellement automatique, avec une carte bancaire valide. Si l’app n’a pas encore son propre domaine, c’est non.

Le risque. Si chaque essai se fait directement en production, un test raté peut modifier ou supprimer de vraies données clients.

Comment vérifier. Demandez : « Quand on teste une nouveauté, sur quelle base de données travaille-t-on ? » La réponse attendue : une base de test, distincte de la production.

• Lovable Avec Lovable Cloud, activez les environnements Test et Live (en bêta au moment de la rédaction) : Lovable construit alors sur la base de test. Avec votre propre projet Supabase, prévoyez un second projet pour les tests.
• Bolt Vérifiez à quelle base est relié l’aperçu de l’éditeur : si c’est celle de production, chaque test touche de vraies données.
• Firebase Créez un second projet Firebase pour les tests, ou utilisez l’Emulator Suite en local.

Le risque. Sans retour arrière simple, une erreur publiée reste en ligne jusqu’à ce que quelqu’un trouve la cause. Vos clients, eux, la voient tout de suite.

Comment vérifier. Demandez qu’on vous montre, une fois, comment revenir à la version précédente. Chez Vercel ou Netlify, on republie un déploiement précédent en un clic. Attention : revenir en arrière sur le code ne restaure pas la base de données.

• Lovable L’historique des versions restaure une version précédente du code. Les changements faits dans la base ne sont pas annulés pour autant.
• Bolt D’après la documentation de Bolt, l’historique des versions ne restaure pas la base de données.

Le risque. Sans cet historique (on parle de migrations), impossible de recréer la base à l’identique pour un test, ni de savoir ce qui a changé quand un bug apparaît.

Comment vérifier. Demandez à voir l’historique des changements de la base. Dans le dépôt GitHub, il prend souvent la forme d’un dossier de fichiers SQL datés.

• Supabase Cherchez un dossier supabase/migrations dans le dépôt. Les changements faits à la main dans le tableau de bord n’y apparaissent pas.
• Lovable Sur un projet relié à Supabase, les changements de base demandés à Lovable sont en général écrits dans supabase/migrations : vérifiez que le dossier existe et qu’il est à jour.
• Firebase Firestore n’a pas de schéma fixe : vérifiez au moins que les règles de sécurité et les index sont dans le dépôt (firestore.rules, firestore.indexes.json).

Le risque. Une suppression par erreur, une mauvaise requête ou une migration ratée peut effacer des données. Une sauvegarde que personne n’a jamais restaurée reste une hypothèse.

Comment vérifier. Vérifiez d’abord que des sauvegardes automatiques existent, leur fréquence et leur durée de conservation. Puis faites restaurer une sauvegarde sur une base de test, au moins une fois par trimestre. Les fichiers (photos, documents) se sauvegardent à part : vérifiez qu’ils le sont.

• Supabase Sauvegardes quotidiennes à partir de l’offre Pro (conservées 7 jours), restauration à la minute près en option (PITR). Sur l’offre gratuite, Supabase recommande d’exporter vous-même la base (commande db dump de la CLI). Les fichiers du Storage ne sont pas inclus dans les sauvegardes de la base.
• Firebase Les sauvegardes planifiées de Firestore (quotidiennes ou hebdomadaires) demandent l’offre Blaze et se restaurent dans une nouvelle base. Elles ne couvrent pas les fichiers de Cloud Storage.
• Base44 La base reste chez Base44 : vérifiez comment exporter vos données, et faites-le régulièrement.

Le risque. Si l’app active l’accès quand le client arrive sur la page « merci », il suffit de connaître cette adresse pour être servi sans payer. Et un client qui ferme l’onglet trop tôt peut payer sans être servi.

Comment vérifier. Demandez : « Qu’est-ce qui déclenche l’activation après un paiement ? » La bonne réponse : un webhook Stripe, dont la signature est vérifiée par le serveur. Dans le tableau de bord Stripe, la section Webhooks doit montrer une destination active, avec des envois réussis.

• Supabase Le webhook arrive en général dans une Edge Function, pour laquelle la vérification du JWT est désactivée (Stripe n’envoie pas de jeton Supabase) : la signature Stripe doit alors être vérifiée dans le code.
• Firebase Le webhook arrive dans une Cloud Function, qui vérifie la signature Stripe avant d’écrire dans Firestore.

Le risque. Si le prix ou la remise sont envoyés par le navigateur, un visiteur peut les changer avant de payer. Le paiement passe, au prix qu’il a choisi.

Comment vérifier. Demandez comment est créée la session de paiement. Elle doit l’être côté serveur, à partir de produits et de prix définis dans Stripe ou dans votre base, jamais à partir d’un montant reçu de l’écran.

Le risque. Le paiement qui réussit marche presque toujours. Ce sont les autres cas qui créent des accès gratuits, des clients facturés à tort et des demandes au support.

Comment vérifier. En mode test Stripe, rejouez chaque scénario avec les cartes de test (4242 4242 4242 4242 pour un paiement accepté, et les cartes de refus listées dans la documentation Stripe). Vérifiez à chaque fois ce que voit le client et ce qui change dans votre base.

• FlutterFlow App mobile : la vente de contenus ou de fonctions numériques passe en général par les achats intégrés d’Apple et de Google. Vérifiez leurs règles pour votre cas avant de soumettre une mise à jour.

Le risque. Beaucoup d’utilisateurs ne signalent pas un bug : ils abandonnent. Sans suivi des erreurs, vous découvrez les problèmes des jours plus tard, sans savoir ce qui s’est passé.

Comment vérifier. Un outil de suivi des erreurs (Sentry, par exemple, a une offre gratuite) doit être branché sur l’app et vous envoyer une alerte. Test : demandez qu’on déclenche une erreur volontaire, et vérifiez que vous recevez bien l’alerte.

• Supabase Les journaux (Logs) du projet montrent les erreurs de la base, de l’authentification et des Edge Functions : quelqu’un doit les consulter, ou recevoir des alertes.
• Firebase Sur mobile, Crashlytics remonte les plantages des apps iOS et Android.

Le risque. Un hébergeur en panne, un certificat expiré ou un projet mis en pause peuvent couper l’app pendant des heures sans que personne ne s’en aperçoive.

Comment vérifier. Un service de surveillance (UptimeRobot ou Better Stack, qui ont des offres gratuites) teste votre adresse toutes les quelques minutes et vous prévient en cas de panne. Surveillez la page d’accueil et une page qui interroge la base.

• Supabase Un projet sur l’offre gratuite est mis en pause après une période d’inactivité : à éviter pour une app de production.

Le risque. Abonnements, crédits, base de données, IA, emails : les coûts montent avec l’usage, parfois brutalement. Sans alerte, vous l’apprenez à la facture.

Comment vérifier. Listez chaque service avec son coût actuel, puis estimez-le à dix fois plus d’utilisateurs. Chez chaque fournisseur qui facture à l’usage, réglez une alerte de budget envoyée à une adresse que vous lisez.

• Supabase Sur l’offre Pro, le plafond de dépenses (Spend Cap) limite les dépassements : vérifiez s’il est actif.
• Firebase L’offre Blaze facture à l’usage, sans plafond automatique. Créez une alerte de budget dans Google Cloud Billing : elle prévient, elle ne coupe pas.
• Lovable Les crédits Lovable (ou Bolt) font partie du coût : notez combien vous en consommez chaque mois pour faire évoluer l’app.

Le risque. Un client qui ne reçoit pas son lien de connexion ne peut pas utiliser l’app, et il ne vous le dira pas toujours. Les services d’email fournis par défaut sont souvent prévus pour les tests.

Comment vérifier. Créez un compte puis demandez un nouveau mot de passe, avec une adresse Gmail et une adresse Outlook. Vérifiez la boîte de réception et les spams. Les emails doivent partir de votre domaine, configuré avec SPF, DKIM et DMARC : votre service d’envoi (Brevo, Resend, Postmark…) vous guide.

• Supabase Le service d’email intégré n’envoie qu’aux membres de votre équipe Supabase, avec une limite de quelques messages par heure. En production, branchez votre propre service (SMTP personnalisé).
• Firebase Les emails d’authentification partent par défaut d’une adresse en firebaseapp.com : personnalisez le domaine d’envoi dans les modèles d’Authentication.

Le risque. Les apps générées par Lovable ou Bolt construisent souvent les pages dans le navigateur. LinkedIn, WhatsApp ou Slack affichent alors le même aperçu pour toutes vos pages, et Google les lit avec des limites.

Comment vérifier. Collez l’adresse de trois pages différentes dans le LinkedIn Post Inspector : chacune doit afficher son propre titre, sa description et son image. Pour Google, utilisez l’outil « Inspection de l’URL » de Search Console : testez la page en direct et regardez la capture obtenue.

• Lovable Lovable génère une app React affichée dans le navigateur. Si le référencement compte, deux pistes : pré-générer les pages publiques, ou mettre le site vitrine sur un outil fait pour ça (Next.js, Webflow, Framer) et garder l’app sur un sous-domaine.
• Bolt Si le projet est en Next.js ou en Astro, les pages peuvent être générées côté serveur : vérifiez que c’est bien le cas des pages publiques.

Le risque. Sans Search Console, vous ne savez ni quelles pages Google connaît, ni pourquoi il en ignore certaines. Des pages sans adresse propre, ou une copie de l’app sur l’adresse de l’outil, brouillent votre référencement.

Comment vérifier. Ajoutez votre domaine dans Search Console (gratuit), envoyez le fichier sitemap.xml et consultez le rapport sur l’indexation des pages. Tapez « site:votredomaine.fr » dans Google pour voir ce qui remonte. Si l’adresse fournie par l’outil (…lovable.app, par exemple) apparaît aussi, faites-la rediriger vers votre domaine ou déclarez votre domaine comme adresse principale (balise canonique).

Le risque. Une page lente fait partir les visiteurs avant qu’ils lisent votre offre, et Google tient compte de la vitesse dans son classement.

Comment vérifier. Testez la page sur pagespeed.web.dev, onglet mobile, et regardez l’indicateur LCP (temps d’affichage du contenu principal). Faites de même pour vos pages les plus visitées. Causes fréquentes d’un LCP lent : images trop lourdes, polices et scripts tiers.

Le risque. Une politique copiée d’un modèle ne vous aidera pas le jour où un client ou la CNIL pose une question précise. Les mentions légales, elles, sont obligatoires en France : vérifiez au passage qu’elles sont en ligne.

Comment vérifier. Relisez la politique de confidentialité avec la liste de vos services (base de données, emails, IA, mesure d’audience) : chaque donnée collectée, son usage, sa durée de conservation et chaque prestataire qui la traite doivent y figurer.

Le risque. Déposer ces cookies avant le consentement est un manquement que la CNIL contrôle et sanctionne régulièrement. Refuser doit en outre être aussi simple qu’accepter.

Comment vérifier. Ouvrez le site dans une fenêtre de navigation privée, appuyez sur F12, onglet Application > Cookies, sans toucher au bandeau. Aucun cookie _ga (Google Analytics), _fbp (Meta) ou équivalent ne doit apparaître. Vérifiez ensuite que le bouton « Refuser » est aussi visible que « Accepter ». Certains outils de mesure configurés selon les recommandations de la CNIL peuvent être exemptés de consentement.

Le risque. Vos clients professionnels vous poseront la question, souvent avant de signer. En cas de fuite, vous devez aussi pouvoir la notifier à la CNIL dans les 72 heures, ce qui suppose de savoir qui détient quoi.

Comment vérifier. Pour chaque service qui traite des données personnelles, notez la région d’hébergement et récupérez son DPA (accord de traitement des données), souvent disponible dans les réglages ou sur le site du fournisseur. Tenez un registre des traitements : la CNIL propose un modèle.

• Supabase La région est choisie à la création du projet (des régions européennes existent) et ne se change pas ensuite sans migration.
• Firebase L’emplacement de Firestore est choisi à la création de la base et ne peut pas être modifié ensuite.
• Base44 Demandez à Base44 où sont hébergées vos données et quel contrat de sous-traitance s’applique.

Le risque. Le RGPD vous laisse un mois pour répondre à une demande d’accès ou de suppression. Sur mobile, Apple et Google exigent en plus qu’un compte créé dans l’app puisse être supprimé.

Comment vérifier. Faites le test vous-même avec un compte de test : demandez l’export de ses données, puis leur suppression. Notez le temps que cela prend, et vérifiez que les données disparaissent aussi des outils connectés (emails, CRM, mesure d’audience).

• Supabase Supprimer un utilisateur dans Authentication ne supprime pas forcément ses lignes dans vos tables : vérifiez les liens entre tables (on delete cascade) ou prévoyez une fonction de suppression.
• FlutterFlow App mobile : un bouton de suppression de compte doit être accessible depuis l’app elle-même.