Vibe coding : pourquoi une application qui marche n’est pas une application sûre

Le code généré par l’IA passe bien plus souvent les tests fonctionnels que les tests de sécurité. Les failles reviennent toujours aux mêmes endroits : contrôle d’accès absent, base de données ouverte, secrets dans le navigateur, entrées non validées. Elles sont invisibles à l’usage et faciles à exploiter — et se corrigent une fois repérées.

L’IA est entraînée à produire du code qui fonctionne, pas du code qui résiste à quelqu’un qui cherche à le casser. Quand vous testez votre application, vous cliquez sur ce qui est prévu. Un attaquant fait l’inverse : il change un identifiant, supprime un en-tête, appelle directement l’API.

Résultat : les mêmes familles de failles reviennent, dans les études comme dans les incidents publics. Aucune n’est exotique ; toutes se corrigent. Encore faut-il savoir où regarder.

Ce que disent les études publiques

Plusieurs travaux convergent, avec des méthodes différentes — il ne faut donc pas additionner leurs chiffres. Le rapport GenAI Code Security de Veracode a testé plus de cent modèles sur des tâches de programmation : environ 45 % des échantillons échouent à des tests tirés de l’OWASP Top 10. Le benchmark SusVibes de Carnegie Mellon montre un écart encore plus net entre code correct (autour de 61 %) et code à la fois correct et sûr (autour de 10 %).

Côté incidents, la faille répertoriée CVE-2025-48757 décrit des bases Supabase d’applications générées avec Lovable lisibles avec la clé publique, faute de politiques Row Level Security. Elle illustre un schéma général : l’outil fonctionne, la règle d’accès manque.

Les quatre familles de failles qui reviennent

Contrôle d’accès

Vérifier que l’utilisateur est connecté, pas que la ressource lui appartient. Premier poste du classement OWASP Top 10.

Base de données ouverte

Règles d’accès (RLS, règles Firebase) absentes, trop larges, ou contournées par une clé administrateur côté client.

Secrets exposés

Clés de paiement, d’IA ou d’administration dans le code envoyé au navigateur, ou dans l’historique Git.

Entrées non maîtrisées

Formulaires, uploads, paramètres et webhooks acceptés sans validation : injection, XSS, abus de fonctionnalités.

Comment réduire le risque dès aujourd’hui

Activez l’authentification sur tout ce qui n’est pas public, et vérifiez la propriété de chaque donnée côté serveur.
Activez et testez les règles d’accès de votre base avec deux comptes différents.
Cherchez vos clés : aucune clé secrète ne doit se trouver dans le navigateur ni dans Git.
Ajoutez les en-têtes de sécurité et passez les cookies en Secure, HttpOnly, SameSite.
Passez notre checklist avant la mise en ligne, puis lancez le scan gratuit.

Questions fréquentes

Qu’appelle-t-on « vibe coding » ?

Construire une application en décrivant ce que l’on veut à un assistant IA (Lovable, Bolt, Replit, Cursor, Claude Code…) et en acceptant le code produit sans le relire ligne à ligne. Le terme a été popularisé en 2025.

Les plateformes sécurisent-elles mes applications ?

En partie : elles posent des garde-fous et certaines vérifient des points précis. Mais la logique propre à votre application — qui a le droit de voir quoi — dépend de ce que vous avez demandé et de ce que l’IA a compris. Aucune plateforme ne peut la deviner à votre place.

Dois-je arrêter d’utiliser ces outils ?

Non. Ils sont excellents pour prototyper et livrer vite. La règle : avant d’ouvrir l’application à de vrais utilisateurs ou de vraies données, faire relire la sécurité par quelqu’un dont c’est le métier — ou au moins passer la checklist de nos guides.