Checklist sécurité avant de déployer ton app vibe-codée

Avant de mettre ton app en ligne, il y a six choses à vérifier. Pas trente. Six. Et la plupart des apps vibe-codées en ratent au moins une, souvent la plus grave : la base de données lisible par tout le monde.

Cette checklist, c'est celle que je passe sur chaque app que je scanne. Je te la donne en clair, avec le comment pour chaque point, pour que tu la fasses toi-même avant de lancer. Compte deux minutes par point à la main, ou trente secondes pour le tout si tu passes par un scan.

Pourquoi cette checklist existe

Quand tu vibe-codes une app, l'IA optimise pour une seule chose : que ça marche. Elle branche ta base, elle pose tes clés, elle te sort une app qui tourne. Elle ne ferme pas les portes derrière elle, parce que personne ne lui a demandé de le faire.

Le résultat est concret. Sur une dizaine d'apps que j'ai scannées un matin, au hasard des pubs qui passaient sur LinkedIn et X, 8 sur 10 exposaient quelque chose. Une clé d'admin en clair, du code source accessible, des en-têtes absents. Deux seulement étaient propres. Ces six points couvrent tout ce que j'ai vu passer.

Les six points à vérifier avant de déployer

1. Aucune clé secrète ne traîne dans le code

Il y a deux familles de clés. Les publiques, faites pour être vues (la clé anon de Supabase, une clé Stripe pk), et les secrètes, qui ne doivent jamais finir côté navigateur : service_role de Supabase, sk_live de Stripe, une clé OpenAI.

Pourquoi c'est grave : une service_role exposée ignore toutes tes protections et donne un accès complet à ta base. Une sk_live Stripe, c'est ta caisse ouverte.

Comment vérifier : ouvre ton app, DevTools, onglet Sources, et cherche service_role, sk_live, sk-. Si tu tombes dessus, c'est exposé.

2. Le RLS de Supabase est activé

Le RLS (Row Level Security) est le verrou de ta base. Tant qu'il est désactivé, ta clé publique suffit à lire toutes tes tables. C'est la faille numéro un des apps vibe-codées, environ 70 % l'ont.

Pourquoi c'est grave : sans RLS, n'importe qui recopie ta base d'emails et de commandes en une requête. Si ces données sont personnelles, c'est une violation RGPD, avec notification CNIL sous 72 heures.

Comment vérifier : tu peux le voir toi-même en deux minutes avec les DevTools. Le détail de la faille est expliqué dans RLS désactivé : pourquoi ta base est lisible.

3. Les source maps ne sont pas servies en production

Les source maps reconstruisent ton code d'origine à partir du JavaScript compilé. Pratique pour déboguer, catastrophique en public.

Pourquoi c'est grave : un curieux télécharge le .map et lit la logique de ton app comme si tu lui donnais ton dépôt. Il repère tes vraies failles plus vite, et parfois des clés oubliées dans un commentaire. C'est ce que je retrouve le plus souvent.

Comment vérifier : dans l'onglet Sources des DevTools, si tu vois ton arborescence de fichiers d'origine (des .vue, .tsx lisibles), les source maps sont servies. À couper dans la config de build.

4. Les en-têtes de sécurité sont posés

CSP, HSTS, X-Frame-Options. Ce sont les serrures secondaires.

Pourquoi c'est grave : seuls, ils ne fuient pas de données. Leur absence ouvre la porte au détournement de session, à l'injection de code, à l'affichage de ton app dans une fausse page. Ils comptent aussi dans les « mesures techniques appropriées » demandées par le RGPD (art. 32).

Comment vérifier : dans l'onglet Réseau, clique sur la première requête (le document), regarde les Response Headers. Si Content-Security-Policy et Strict-Transport-Security manquent, c'est à ajouter. Attention, certains dépendent de l'hébergeur, pas du code.

5. Les pages légales obligatoires existent

Mentions légales et politique de confidentialité. En France, c'est la loi (LCEN, RGPD), pas une option.

Pourquoi c'est grave : leur absence est une non-conformité, et c'est l'un des premiers signaux de sérieux que regardent tes visiteurs.

Comment vérifier : regarde ton footer. Un lien mentions légales, un lien confidentialité. S'ils n'y sont pas, ajoute-les avant de lancer.

6. Tu as scanné l'app finale, pas la page vitrine

Nuance qui change tout. Une page de présentation ne charge pas ta base, donc elle ne montre presque jamais de faille grave.

Pourquoi c'est important : tu peux te croire propre parce que tu as testé ta landing, alors que c'est ton app, là où tes utilisateurs se connectent, qui expose la base.

Comment faire : vérifie l'URL où tes utilisateurs se connectent réellement, pas ta home marketing.

La version rapide : tout vérifier d'un coup

Passer ces six points à la main, c'est faisable, mais il faut savoir où creuser et lire ce que tu vois. Colmate passe cette revue en trente secondes depuis l'URL de ton app. Tu colles le lien, tu obtiens la liste de ce qui est exposé (clés, source maps, en-têtes, pages légales), classé par gravité, avec le correctif prêt à coller dans ton IA. Pour la base, il ne teste rien : il repère la présence de Supabase avec une clé publique exposée et te signale l'exposition probable à vérifier. En lecture seule, sans accéder à ton code ni toucher à tes données.

Scanne ton app avant de la déployer. Tu sauras tout de suite ce qui est exposé et ce qui reste à vérifier.

FAQ

Quand faut-il faire cette checklist ?

Juste avant chaque mise en ligne, et après chaque grosse modif touchant la base, l'authentification ou les paiements. Une app propre au lancement peut redevenir vulnérable après un ajout de fonctionnalité. Le réflexe : re-vérifier avant de déployer, à chaque fois.

Faut-il être développeur pour la faire ?

Non. Les points 1 à 4 se vérifient dans les outils de développeur de ton navigateur (clic droit, Inspecter), sans écrire une ligne de code. Les points 5 et 6 sont du bon sens. Si tu veux zapper la partie technique, un scan te signale directement les points exposés et ceux à vérifier.

Est-ce que ça vaut pour Lovable, Bolt, v0 et Replit ?

Oui. La checklist vaut pour toute app générée avec un outil no-code ou une IA de code, parce que le défaut est le même partout : l'app tourne sans que les portes aient été fermées derrière. Le stack change, les failles se ressemblent.

Le réflexe avant de lancer

Tu ne mettrais pas un site en ligne sans regarder à quoi il ressemble. Fais pareil pour ce qu'il expose. Passe la checklist en un scan, et lance en sachant que tu n'as pas laissé la clé sur la porte. Pour comprendre chaque faille en détail, commence par ce que ton app vibe-codée expose vraiment.