Félicitations. Votre app générée en douze minutes par un prompt a aussi généré un fichier client en accès libre. La clé publique Supabase traîne dans le bundle JavaScript, la table répond en lecture ouverte, et n'importe quel script de dix lignes aspire tout. Sans mot de passe. Sans trace. Sans que vous le sachiez. Bienvenue dans le vibe coding.
Le RLS n'est pas un bug, c'est un interrupteur que vous n'avez pas touché
Rappel pour ceux qui ont découvert Postgres la semaine dernière : Supabase, c'est une base Postgres avec une API auto-générée. La clé dite « anon » est publique par design, c'est écrit noir sur blanc dans la doc, personne n'a triché. Le problème n'est pas la clé. Le problème, c'est le Row Level Security — la couche qui décide qui a le droit de lire quoi — qui est désactivé par défaut à la création d'une table.
Traduction pour les décideurs : par défaut, votre API répond « oui » à tout le monde. Tant que personne ne pense à activer RLS et à écrire des politiques, votre base est un buffet à volonté avec une porte grande ouverte et un panneau « merci de ne pas voler ».
Et ne venez pas pleurer sur le dos de Supabase : l'éditeur sort un Security Advisor, flashe des avertissements, te met un bandeau rouge dans le dashboard. Tu l'as ignoré. Comme le message de ta banque.
Le prompt n'a pas de case « sécurité »
Voilà le vrai coupable, et il n'a pas de nom de marque : l'optimisation pour la démo. Un modèle de code génère ce qui se voit — le schéma, le CRUD, la jolie page qui scrolle. Il ne génère pas les politiques de permissions, parce que personne ne les lui a demandées, et parce qu'une politique RLS, ça ne fait bander personne dans une vidéo produit.
L'IA ne pense pas « qui doit accéder à cette ligne ? ». Elle pense « est-ce que ça compile ? ». Et ça compile. Magnifiquement. Ça compile tellement bien que la faille passe en production le jour de la démo.
Suivez l'argent : personne n'est payé pour vos permissions
Supabase : open source, communauté, valo autour des 2 milliards de dollars, une Series C de 80 millions bouclée fin 2024. Les outils de vibe coding : des levées à neuf chiffres, Lovable et ses 200 millions annoncés à l'été 2025 sur une valo de 1,8 milliard, pour une boîte qui a mis huit mois à faire 100 millions d'ARR. Les fonds : des milliards déployés sur la promesse qu'un non-développeur peut shipper une app en un après-midi.
Cherchez « RLS activé » dans un pitch deck. Cherchez « conformité RGPD » dans un thread de lancement. Bonne chance. La sécurité est gratuite, invisible, et n'a jamais fait lever un seul tour de table. Elle n'est donc pas dans la roadmap. Elle n'est dans la roadmap de personne.
Les régulateurs dorment, les utilisateurs paient
Une table exposée, c'est une violation de données au sens du RGPD. Notification à la CNIL sous 72 heures. Vous voyez la file d'attente des notifications ? Moi non. Parce que le fondateur qui a poussé trois prompts et facturé deux clients ne sait même pas que sa base fuit. On ne déclare pas ce qu'on ignore.
Le coût de la fuite est intégralement transféré sur l'utilisateur final — celui dont l'e-mail, l'adresse et le numéro de téléphone sont maintenant dans un dataset scrappé quelque part. Il n'a pas cliqué sur « j'accepte d'être vibe-codé ».
Ce qu'il faut faire, et pourquoi presque personne ne le fera
Activer RLS. Écrire des politiques par table. Tester son API avec la clé publique en se prenant pour un attaquant, pas en se prenant pour un client. Faire tourner un scanner avant chaque déploiement. Coût réel : un après-midi d'un dev qui sait ce qu'il fait. Coût de l'alternative : un avocat, une amende, et une réputation en miettes.
Alors oui, continuez à générer des apps en douze minutes. Mais arrêtez de confondre vitesse de production et absence de conséquence. La sécurité n'est pas une vibe. C'est une ligne de code que quelqu'un doit écrire. Et ce quelqu'un, ce n'est pas le prompt.