Le vibe coding accelere le developpement, c'est indeniable. Mais une etude recente de Stanford montre que le code genere par IA contient 2.74 fois plus de vulnerabilites que le code ecrit manuellement. Pire : les developpeurs qui utilisent l'IA ont tendance a surestimer la securite de leur code.
Ce n'est pas une raison pour abandonner le vibe coding. C'est une raison pour le pratiquer de maniere informee. Voici les risques concrets et comment s'en proteger.
Les vulnerabilites les plus frequentes
Injection SQL et NoSQL
Les LLM ont appris sur des millions d'exemples de code, y compris de mauvais exemples. Quand vous demandez "cree un endpoint de recherche utilisateur", l'IA peut generer une concatenation de chaine SQL au lieu d'une requete parametree.
// Code genere par IA - VULNERABLE
String query = "SELECT FROM users WHERE name = '" + userName + "'";
// Ce qu'il faut a la place
String query = "SELECT FROM users WHERE name = ?";
PreparedStatement stmt = conn.prepareStatement(query);
Le probleme est que le code vulnerable fonctionne parfaitement en dev. Il ne casse qu'en production, face a un attaquant.
Secrets en dur dans le code
Les LLM ont tendance a generer des exemples avec des cles d'API, des mots de passe et des tokens directement dans le code. Meme si vous demandez "utilise des variables d'environnement", l'IA ajoute parfois des valeurs par defaut en dur.
# Danger : secret en dur genere par IA
Cette valeur par defaut finit sur GitHub. Les bots de scraping la trouvent en quelques minutes.
Dependances non verifiees
Quand l'IA suggere npm install super-useful-lib, elle ne verifie pas si le package est maintenu, s'il a des CVE connues, ou s'il ne s'agit pas d'un package malveillant au nom similaire (typosquatting).
En 2025, plusieurs packages npm malveillants ont ete distribues specifiquement parce que les LLM les recommandaient. Les attaquants creent des packages dont le nom correspond aux hallucinations frequentes des modeles.
Gestion d'erreurs insuffisante
Le code genere par IA a une facheuse tendance a ignorer ou avaler les erreurs silencieusement :
// Pattern dangereux genere par IA
try {
const data = await fetchSensitiveData();
return data;
} catch (error) {
console.log("Error:", error);
return null; // Donnee sensible potentiellement exposee dans les logs
Le console.log(error) peut exposer des stack traces, des chemins internes, voire des tokens dans les logs de production.
Les risques specifiques au vibe coding
L'effet "ca marche, je commit"
Le vibe coding encourage la vitesse. Quand l'IA genere du code qui passe les tests, la tentation est forte de commiter immediatement. Mais les tests generent rarement les cas de securite : injection, depassement de droits, race conditions.
La confiance excessive dans le modele
Les developpeurs qui utilisent l'IA depuis longtemps developpent une confiance excessive. "Claude ne ferait pas cette erreur". Si, il la fait. Les LLM n'ont pas de notion de securite -- ils predisent des tokens, ils ne raisonnent pas sur les menaces.
Le contexte manquant
L'IA ne connait pas votre modele de menaces. Elle ne sait pas que votre application gere des donnees de sante (HIPAA), des paiements (PCI-DSS), ou des donnees personnelles (RGPD). Sans ce contexte, elle genere du code "fonctionnel" mais pas "conforme".
Checklist securite pour le vibe coding
Avant de coder
- Ajouter les contraintes de securite dans le fichier de regles (
CLAUDE.md,.cursorrules) - Preciser le modele de menaces dans le prompt : "cet endpoint est expose publiquement"
- Activer un scanner SAST dans le pipeline CI (SonarQube, Semgrep, CodeQL)
Pendant le coding
- Relire chaque bloc genere en cherchant specifiquement les injections et les secrets
- Verifier les dependances ajoutees sur npm/Maven avec
npm auditoumvn dependency:check - Demander explicitement a l'IA : "Y a-t-il des vulnerabilites dans ce code ?"
Avant le commit
- Lancer un pre-commit hook de detection de secrets (gitleaks, trufflehog)
- Verifier que les tests couvrent les cas limites de securite
- Faire une review manuelle des points d'entree (endpoints, parsers, deserializers)
En production
- Activer un WAF (Web Application Firewall) devant vos APIs
- Monitorer les patterns d'acces anormaux
- Mettre a jour regulierement les dependances (Dependabot, Renovate)
Outiller votre pipeline
Le meilleur rempart contre les vulnerabilites du vibe coding, c'est l'automatisation. Si votre CI detecte les problemes, vous pouvez coder vite sans sacrifier la securite.
Semgrep est particulierement adapte : il detecte les patterns de code dangereux avec des regles personnalisables. Vous pouvez ajouter des regles specifiques aux erreurs que font les LLM. Gitleaks en pre-commit hook empeche tout secret de passer dans le repo. C'est la mesure la plus simple et la plus efficace. Snyk ou npm audit dans le CI bloquent les dependances avec des CVE connues. Essentiel quand l'IA ajoute des packages que vous n'avez pas verifies.
Le vibe coding securise existe
La solution n'est pas d'abandonner le vibe coding, c'est de l'encadrer. Les developpeurs qui configurent leur IA avec des contraintes de securite, qui utilisent des scanners automatiques, et qui maintiennent une discipline de review produisent du code aussi sur que le code ecrit manuellement -- en allant bien plus vite.
Le vibe coding est un outil. Comme un marteau, il peut construire ou detruire. La difference, c'est la discipline de celui qui l'utilise.
