Bolt, Lovable, v0, Cursor : ce qui change vraiment côté sécurité
On ne va pas te sortir un classement avec des pourcentages — "X % des apps Bolt sont vulnérables" n'existe pas sans une étude statistique rigoureuse, et on n'en a pas. Ce qu'on peut comparer honnêtement, c'est comment chaque outil architecture le backend par défaut — parce que c'est ça qui détermine où ton risque se concentre, pas la marque de l'outil.
Bolt.new et Lovable : le backend "clé en main"
Les deux poussent fort vers une intégration Supabase en un clic pour la base de données, l'auth et le stockage. C'est ce qui les rend rapides : en quelques prompts, tu as un CRUD complet, une table d'utilisateurs, et souvent un flux de paiement Stripe branché dessus. Le revers, c'est que le même modèle de risque revient sur chaque projet généré cette voie : clé anon publique par design, et la sécurité réelle qui repose entièrement sur des policies RLS bien écrites — une étape que le prompt initial ne couvre pas toujours, et qu'il faut vérifier explicitement après coup.
Concrètement : sur un projet Bolt ou Lovable avec Supabase, les trois choses à vérifier en priorité sont toujours les mêmes — RLS activé sur chaque table, policies qui ne sont pas en USING (true) par accident, et aucune clé service_role ou sk_live_ qui a fui côté client.
v0 : plutôt le front, le risque dépend de ce que tu branches derrière
v0 est historiquement centré sur la génération de composants et de pages — UI d'abord. Il ne t'impose pas une backend par défaut de la même façon que Bolt ou Lovable. Ça veut dire que le risque "backend exposé" n'est pas structurel à l'outil : il apparaît au moment où toi tu connectes une base de données, une API, ou un service de paiement au composant généré. La vigilance se déplace de "le scaffold est-il sûr par défaut" vers "ce que j'ai ajouté après coup respecte-t-il les mêmes règles" — clé secrète jamais côté client, RLS si tu ajoutes Supabase toi-même, etc.
Cursor : pas de plateforme, donc pas d'architecture par défaut
Cursor est un éditeur de code assisté par IA, pas une plateforme de déploiement avec des intégrations préconfigurées. Il n'y a pas de "backend par défaut Cursor" — le résultat dépend entièrement de ce que tu lui demandes et du code existant dans ton projet. C'est à la fois plus sûr (pas de pattern répété à grande échelle) et plus risqué différemment : un assistant qui répond très vite à "ajoute l'authentification" peut générer du code fonctionnel sans relever que la clé qu'il vient d'utiliser ne devrait pas être dans un fichier client — parce que rien dans le prompt ne demandait explicitement une revue de sécurité.
Le vrai dénominateur commun
Peu importe l'outil : un LLM optimise pour "faire fonctionner la fonctionnalité demandée", pas pour "minimiser la surface d'attaque". Une clé qui marche des deux côtés (client et serveur) résout le problème immédiat plus vite qu'une architecture propre avec une API route dédiée — donc c'est souvent ce qui sort en premier jet, quel que soit l'outil utilisé pour l'écrire.
Ce qui compte, indépendamment de l'outil
- Vérifier la répartition client/serveur de chaque clé et secret, pas juste "est-ce que ça marche".
- Si Supabase (ou équivalent) est branché, auditer RLS explicitement — jamais supposer que le scaffold l'a fait correctement.
- Retester après chaque session de prompt significative, pas seulement à la fin du projet — une régression peut être réintroduite par un prompt ultérieur qui touche le même fichier.
Peu importe l'outil que tu as utilisé pour construire ton app, un scan Vetora vérifie ces points depuis l'extérieur, comme le ferait un attaquant.