Vibe coding : quand l'IA crée des vulnérabilités

Le vibe coding mise sur l'interaction intuitive avec l'IA pour générer des logiciels. Mais il génère aussi un risque. Une compréhension limitée du code généré peut en effet créer des vulnérabilités.

Après le pair programming assisté par IA, une nouvelle pratique s’impose chez les développeurs, le vibe coding. Cette approche est centrée sur l’interaction intuitive avec les modèles d’IA via des requêtes en langage naturel pour produire du code rapidement. Mais derrière cette agilité apparente émerge un nouveau champ de vulnérabilités. Le manque de compréhension du code, en particulier lorsqu’il est généré ou refactoré par une IA, représente un risque métier majeur.

Le principe du vibe coding est séduisant : il suffit de discuter avec l’IA jusqu’à obtenir un code qui marche. Le développeur devient alors une sorte de chef d’orchestre qui dialogue avec la machine pour atteindre un résultat fonctionnel. Mais cette simplification a un prix, car les risques de sécurité qu’elle introduit sont bien différents et souvent plus immédiats, que ceux du simple codage assisté par IA. Là où l’usage traditionnel de l’IA pour écrire du code soulève déjà des problèmes connus (schémas non sécurisés, dépendances hallucinées, violations de licences), le vibe coding amplifie ces risques à cause de la manière dont les utilisateurs interagissent avec l’IA, et non seulement à cause de ce que l’IA génère.

Dans cette approche, le dialogue en langage naturel remplace la logique de développement classique, contournant souvent les garde-fous essentiels : revue de code par des pairs, linting, validation manuelle. Résultat : une confiance aveugle dans le code proposé, intégré plus vite mais sans contexte ni traçabilité. Ce phénomène est accentué par le profil des vibe coders, souvent non développeurs ou peu expérimentés, qui valident du code qu’ils ne maîtrisent pas. La sécurité logicielle ne se joue plus ainsi uniquement sur la qualité du code, mais sur la capacité à en garantir la compréhension et la traçabilité.

Le paradoxe du backlog : produire plus, corriger moins

Sous prétexte de productivité, le vibe coding crée un effet pervers. Si les équipes livrent du code plus vite, elles alimentent aussi sans le savoir les backlogs de vulnérabilités. Les corrections deviennent superficielles, appliquées sans analyse des causes profondes, et les pipelines CI/CD se remplissent de code non sécurisé ou testé trop tard. Le shift left, pourtant pilier du DevSecOps, perd toute son essence, les équipes passant plus de temps à trier du bruit qu’à corriger les véritables failles. Résultat : le gain de vitesse se transforme en dette technique et en dette de sécurité.

Le vibe coding tend à générer un code qui “fonctionne” en apparence, mais qui contourne des étapes essentielles (tokens stockés en clair, durées de sessions mal configurées, absences de vérification de l’identité, validations d’entrées incomplètes ou incohérentes). Ces failles, souvent invisibles, sont des portes ouvertes aux attaques par injection, usurpation de session ou élévation de privilèges.

Même phénomène du côté des journaux applicatifs : les logs produits automatiquement peuvent divulguer des informations sensibles (clés API, données personnelles, détails d’architecture) ou révéler des schémas d’erreurs exploitables. Ces pratiques, cumulées à la génération non contrôlée de dépendances open source, alimentent les risques de compromission de la chaîne d’approvisionnement logicielle.

Le risque de l’incohérence : quand chaque “vibe” produit sa propre logique

Le vibe coding souffre d’un autre défaut majeur : l’inconstance. Pour une même requête, un modèle d’IA peut générer plusieurs variantes de code, chacune avec ses propres logiques internes.

Cette incohérence structurelle marque une rupture avec la rigueur historique du développement logiciel. Le vibe coding génère aussi une illusion de simplicité. Parce que le code est « fonctionnel », il semble prêt à être déployé. Cette approche nie l’un des fondements de l’ingénierie logicielle qui est qu’un code fiable est un code compris, audité et testé tout en contournant la logique d’apprentissage du développeur, qui n’analyse plus ses erreurs ni ses dépendances. À terme, cette perte de compétence produit un appauvrissement collectif de la qualité du code et une dépendance accrue à l’IA qui fragilise les pratiques de sécurité.

Réintégrer la sécurité dans le développement

Face à cette dérive, les RSSI doivent repenser la manière dont la sécurité s’intègre au développement comme un accompagnement continu de la création logicielle. En transformant la façon dont les équipes interagissent avec le code, le vibe coding impose de rapprocher la sécurité des environnements de travail des développeurs et de renforcer la visibilité sur ce que l’IA produit.

C’est dans cette logique qu’émergent les AI Coding Security Assistance (ACSA), des solutions qui combinent intelligence artificielle et sécurité applicative pour agir directement au cœur de l’IDE. Ces outils analysent le code en temps réel, vérifient la cohérence des dépendances, repèrent les failles d’authentification, empêchent les fuites de secrets et garantissent l’application de bonnes pratiques de journalisation. En d’autres termes, ils ramènent la sécurité au moment même où le code est écrit.

Aucun outil, aussi intelligent soit-il, ne peut remplacer la compréhension humaine. Le rôle du RSSI est désormais d’instaurer une culture où la rapidité d’exécution ne se fait pas au détriment de la maîtrise, où la collaboration entre développeurs et experts sécurité devient un réflexe, et où chaque ligne de code générée par l’IA reste compréhensible, traçable et vérifiable. Car produire du code sans en comprendre la logique, c’est un peu comme piloter un avion en suivant uniquement le GPS de l’IA, tout va bien jusqu’au moment où le signal se brouille.