Vibecoder son SaaS puis le vendre : ce que personne ne vous dit

Vibecoder une app en un week-end, c'est possible. Encaisser des clients avec, sans contrôler ce que l'IA a produit, c'est prendre un risque que vous n'avez pas mesuré.

Soyons clairs : on ne vient pas taper sur le vibecoding. Lovable, Bolt, Cursor, Replit... ces outils font gagner des semaines, et tout le monde s'en sert pour prototyper.

Le sujet est ailleurs. Il commence le jour où votre prototype devient un produit. Le jour où des vrais utilisateurs y mettent leurs emails, leurs données, parfois leur carte bancaire. À ce moment-là, "ça marche" ne suffit plus. Il faut que ça tienne.

Votre plateforme de conformité dopée à l'humain BASILIS

Moltbook : une case non cochée, toute la base ouverte

Fin janvier 2026, Moltbook, un réseau social pour agents IA, devient viral en quelques jours. Son créateur l'assume publiquement : il n'a pas écrit une seule ligne de code, l'IA a tout fait.

Les chercheurs de Wiz regardent le site comme n'importe quel visiteur. En quelques minutes, ils trouvent une clé Supabase dans le JavaScript côté navigateur.

Cette clé n'est pas dangereuse en soi. Elle le devient parce que le Row Level Security (les règles qui disent qui peut lire quoi dans la base) n'a jamais été activé. Résultat : lecture et écriture sur toute la base de production, sans authentification.

Ce qui était accessible :

1,5 million de tokens d'API
35 000 adresses email
des milliers de messages privés, dont certains contenaient des clés OpenAI partagées par les utilisateurs

La faille a été corrigée en quelques heures après le signalement. Mais retenez le mécanisme : pas un hacker de génie, juste un paramètre que l'IA n'a pas posé et que personne n'a vérifié. Wiz précise que c'est un schéma qu'ils retrouvent régulièrement dans les apps vibecodées.

Enrichlead : du lancement à la fermeture en une semaine

Mars 2025. Leo Acevedo lance Enrichlead, un outil de génération de leads. Sur X, il explique fièrement que son SaaS a été construit avec Cursor, sans une seule ligne de code écrite à la main. Il a des clients qui paient.

Deux jours plus tard, il poste qu'il est attaqué. En clair :

Des inconnus utilisent ses clés d'API... et c'est lui qui paie la facture. Les clés des services payants étaient visibles dans le code du site, donc copiables par n'importe qui.
Des utilisateurs accèdent à la version payante sans payer. La vérification de l'abonnement se faisait dans le navigateur, pas sur le serveur.
N'importe qui peut écrire dans sa base de données. Sans contrôle d'accès, des données bidon sont injectées au hasard.

Il essaie de corriger avec l'IA. Chaque correctif casse autre chose. Une semaine après le lancement, il ferme l'app, en reconnaissant qu'il n'aurait pas dû mettre du code non sécurisé en production.

Ce qui a tué Enrichlead, ce n'est pas une attaque sophistiquée. Ce sont trois erreurs de base qu'une relecture humaine aurait repérées avant la mise en ligne.

Lovable : quand la plateforme elle-même est la faille

On pourrait se dire que ces cas concernent des fondateurs isolés. Avril 2026 montre que non.

Lovable est une des plateformes de vibecoding les plus utilisées, valorisée 6,6 milliards de dollars et utilisée par des entreprises comme Uber, Zendesk ou Deutsche Telekom. Un chercheur démontre qu'avec un simple compte gratuit, on pouvait accéder au code source, aux identifiants de base de données et aux historiques de chat de projets d'autres utilisateurs.

La cause : des API qui ne vérifiaient pas si l'utilisateur était bien propriétaire du projet demandé. Signalée le 3 mars, la faille n'a été corrigée qu'après sa révélation publique, 48 jours plus tard : les signalements avaient été clôturés par le prestataire de bug bounty, qui pensait ce comportement normal.

À noter, pour être juste : Lovable conteste le terme de fuite de données. L'entreprise explique que le problème concernait les projets en visibilité "publique", reconnaît une documentation peu claire, et admet avoir réouvert l'accès par erreur en février.

La leçon est plus large que Lovable : même si vous faites tout bien, la plateforme sur laquelle vous construisez peut être le maillon faible. C'est un fournisseur comme un autre, et il se choisit et se surveille comme tel.

Le vrai risque n'est pas technique, il est commercial

Dès que vous facturez, vous devenez responsable de traitement au sens du RGPD. "C'est Lovable qui a généré le code" ne vous protège de rien : les plateformes renvoient d'ailleurs la responsabilité des réglages de sécurité à leurs utilisateurs.

Concrètement, trois choses vous attendent :

La fuite elle-même. Une violation de données personnelles se notifie à la CNIL dans les 72 heures après en avoir pris connaissance, et un retard doit être justifié. Pour une jeune boîte, c'est aussi un email très désagréable à envoyer à chaque client.
Le questionnaire sécurité du premier gros client. Gestion des accès, chiffrement, journalisation, gestion des secrets... Si vous ne savez pas ce que votre code fait, vous ne pouvez pas y répondre honnêtement. Et le deal attend.
La due diligence. Levée de fonds, rachat, partenariat : quelqu'un finira par ouvrir le capot. Une base sans contrôle d'accès, c'est une décote, voire un deal qui tombe.

Le vibecoding ne crée pas ces obligations. Il vous permet juste d'arriver plus vite au moment où elles s'appliquent, souvent sans l'avoir vu venir.

La checklist avant de facturer votre premier client

Pas besoin d'une équipe sécu pour éviter les erreurs les plus fréquentes. Ces sept points couvrent l'essentiel de ce qu'on retrouve dans les incidents cités plus haut.

Row Level Security activé sur chaque table (Supabase, Firebase...). Testez avec un compte lambda : il ne doit voir que ses propres données.
Aucun secret dans le code front. Clés Stripe, OpenAI, service_role : côté serveur, en variables d'environnement.
Un scan de secrets et de dépendances à chaque commit, pas une fois par an. Les recommandations de la CSA vont exactement dans ce sens.
Vérifier que chaque package installé existe vraiment. Environ 20 % des échantillons de code IA référencent des paquets inexistants, que des attaquants enregistrent ensuite sous le même nom (source CSA, d'après USENIX Security 2025).
Relecture humaine obligatoire sur l'authentification, les droits d'accès et les paiements. C'est là que l'IA se trompe le plus, et c'est là que ça coûte le plus cher.
Des logs exploitables. Si vous ne savez pas qui a accédé à quoi, vous ne pourrez ni qualifier une fuite, ni tenir les 72 heures.
Une revue des accès à vos outils (GitHub, Supabase, Vercel, Stripe) : qui a quels droits, et est-ce toujours justifié ?

Les trois derniers points ne sont pas du code. C'est du contrôle continu, et c'est exactement ce qu'un auditeur ou un client Grand Compte vous demandera de prouver.

Vibecoder, oui. Vendre sans vérifier, non

L'IA vous fait gagner des mois sur le produit. Elle ne sait pas ce que votre client a le droit de voir, ni ce que la CNIL attend de vous.

La bonne approche tient en une phrase : l'IA écrit, un humain vérifie, et des contrôles automatiques surveillent en continu ce qui a changé.

C'est la logique qu'on applique chez Basilis. La plateforme se branche sur vos outils (GitHub, Google Workspace, AWS...) pour détecter en continu les écarts, comme un accès qui n'aurait jamais dû rester ouvert. Et un expert cyber humain valide ce que l'automatisation ne peut pas juger seule.

Votre app a été construite en quelques semaines ? Très bien. Assurez-vous maintenant qu'elle peut passer le questionnaire sécurité de votre premier gros client.