WTF est la sécurité du code Vibe ? Risques, exemples et comment rester en sécurité

Le « vibe coding » est la nouvelle tendance. Vous l'avez peut-être déjà vu à l'œuvre :

• Un commercial crée son propre outil avec l'IA.
• Un designer envoie des modifications d'interface utilisateur directement sur GitHub.
  
• Une équipe marketing développe un logiciel de campagne au lieu de renouveler un contrat fournisseur.
  

Comme l'a dit Steve Yegge dans The Pragmatic Engineer podcast, l'IA a ouvert de nouvelles perspectives. Le code ne provient plus uniquement des développeurs. N'importe qui, avec un prompt, peut livrer une application. La plupart des gens qui font cela ne savent même pas qu'ils font du « vibe coding ». Ils décrivent simplement ce qu'ils veulent en langage courant et laissent l'IA générer le code. Ce changement a modifié qui développe les logiciels et à quelle vitesse ils sont livrés. Cette rapidité est enthousiasmante, mais elle s'accompagne également d'un problème sérieux : la majeure partie de ce code fonctionne à l'aveugle, sans révision, sans tests et sans sécurité.

Qu'est-ce que le « Vibe Coding » ?

Le « vibe coding » consiste à décrire ce que l'on souhaite en langage courant et à laisser une IA générer le code pour vous. Des plateformes comme Lovable, Windsurf et Replit se présentent comme des outils permettant à quiconque de passer d'une idée à une application en quelques heures. Cela ressemble à de la magie, car vous n'avez pas besoin de syntaxe technique ni de formation formelle. Il suffit de dire ce que l'on veut, de copier-coller, de l'exécuter et de voir si cela fonctionne.

C'est rapide et sans friction, ce qui explique sa propagation en dehors des équipes d'ingénierie. Les designers, les marketeurs et les équipes commerciales peuvent désormais livrer des applications ou des fonctionnalités sans attendre les développeurs.

Le problème est que le « vibe coding » privilégie la production au détriment de la sécurité. La plupart du temps, il n'y a pas de révisions, pas de tests et aucune sécurité intégrée. C'est là que les problèmes commencent.

Quand le « Vibe Coding » tourne au vinaigre

Il existe plusieurs exemples de « vibe coding » qui ont mal tourné :

• Incident Replit : Jason Lemkin de SaaStr a fait confiance à l'agent IA de Replit pour construire une application de qualité production. Au début, c'était exaltant : des prototypes en quelques heures, des contrôles qualité, des progrès rapides. Puis les choses se sont gâtées. L'IA a commencé à mentir sur les tests unitaires, a ignoré les gels de code et a finalement supprimé l'intégralité de la base de données de production de SaaStr. Des mois d'enregistrements exécutifs soigneusement conservés ont disparu du jour au lendemain. Comme Lemkin l'a dit à ZDNet, « on ne peut pas écraser une base de données de production. Non, jamais, en aucun cas. » ‍
• Application Tea : des routes d'administration laissées déverrouillées, exposant les données des utilisateurs à quiconque tombait sur le point d'accès. Ce qui semblait être une expérience amusante est rapidement devenu une responsabilité en matière de confidentialité des données.
  

Une proportion non négligeable d'applications créées par des développeurs amateurs contiennent de sérieuses vulnérabilités avant même leur lancement ; si vous testiez dix applications construites de cette manière, il y a de fortes chances qu'au moins une soit piratable.

Ces échecs sont importants car les failles de sécurité dans les applications développées en « vibe coding » ne sont pas de simples bugs mineurs. Elles impliquent souvent des protections fondamentales comme l'authentification, l'accès aux données et la gestion des secrets. Si une application gère des paiements ou des données personnelles, les conséquences ne sont pas seulement techniques, elles sont financières, réglementaires et réputationnelles.

Mackenzie Jackson, developer advocate chez Aikido Security, le dit sans détour :

“L'IA n'écrit pas de code sécurisé par défaut. Elle se contente de générer quelque chose qui fonctionne. En coulisses, il peut être grand ouvert aux attaques.”

Pourquoi cela se propage rapidement

La principale différence avec le « vibe coding » est que tout le monde s'y met maintenant. Designers, chefs de projet, équipes commerciales et marketing déploient tous du code. Les attaquants ne se soucient pas de savoir s'il s'agit d'un projet annexe ou d'un logiciel d'entreprise. Ils ne se préoccupent que de savoir si la porte est ouverte.

La vitesse est un avantage, mais c'est aussi un problème. Une application qui prenait des semaines peut désormais être développée en un après-midi. Cela signifie qu'une équipe entière peut créer rapidement des prototypes et des outils sans attendre l'ingénierie. Le hic, c'est qu'aucun de ces nouveaux développeurs ne pense aux contrôles d'accès, à l'assainissement des entrées ou aux mises à jour des dépendances.

Willem Delbare, Fondateur et CTO d'Aikido, a qualifié cette évolution auprès de ZDNet de tempête parfaite :

« Le « vibe coding » rend le développement logiciel plus accessible, mais il crée également une tempête parfaite de risques de sécurité que même les développeurs expérimentés ne sont pas équipés pour gérer. Injections SQL, path traversal, secrets codés en dur. » 

Mackenzie Jackson prévient que la situation va s'aggraver. Comme il l'a déclaré à TechMonitor :

“De plus en plus de personnes sans solides connaissances en ingénierie ou en sécurité utilisent ces outils pour créer des logiciels… ce qui signifie que nous nous retrouverons avec encore plus de code généré par l'IA que personne n'aura vraiment examiné attentivement.”

C'est ainsi que le « vibe coding » se transforme en ce que Mackenzie appelle la « vulnérabilité en tant que service ». Plus vite des mains non formées déploient des applications avec l'IA, plus vite les failles de sécurité se multiplient sur le web.

Sécuriser le Vibe Coding

Nous avons déjà publié une Checklist de sécurité pour les Vibe Coders destinée aux personnes qui développent. Celle-ci couvre les bases : authentification, assainissement des entrées, analyse et gestion des secrets.

Mais l'essentiel ici est la sensibilisation. Si vous ou votre équipe expérimentez avec le codage par IA, vous devez reconnaître que le prototype rutilant que vous déployez en un après-midi pourrait aussi être la porte dérobée qui permet aux attaquants de s'introduire.

Que peuvent faire les équipes ?

• Traitez le code IA comme s'il avait été écrit par un développeur junior : revoyez-le, testez-le et sécurisez-le.
  
• Externalisez l'authentification à des services conçus à cet effet plutôt que de développer votre propre solution.
  
• Éloignez les secrets du frontend et des dépôts.
  
• Ne vous contentez pas d'exécuter des analyses. Réfléchissez réellement aux failles logiques.
  

Cela semble évident, mais la plupart des « vibe coders » ne le font pas. C'est pourquoi la sécurité doit faire partie de la conversation, même pour les rôles en dehors de l'ingénierie.

Qu'est-ce que l'Agentic Coding ?

L'Agentic coding est l'étape au-delà du « vibe coding ». Au lieu de demander à une IA des extraits de code et de les coller, les agents IA prennent en charge automatiquement le processus d'écriture, d'exécution et de modification du code. Ils peuvent installer des dépendances, exécuter des tests, refactoriser des fichiers et même mettre à jour l'infrastructure.

Cette approche est davantage utilisée par les développeurs et les équipes techniques que par les utilisateurs occasionnels, ce qui la rend plus digne de confiance. Le problème est que cette confiance est mal placée. L'Agentic coding génère un code plus propre, d'apparence plus professionnelle, mais cette apparence masque les risques.

L'Agentic Coding passe à la vitesse supérieure

Là où le « vibe coding » crée souvent un code désordonné et manifestement fragile, l'Agentic coding produit un code qui semble impeccable. C'est une partie du danger. Une seule mauvaise décision peut se propager à travers un système entier et se répandre via les dépendances et les environnements avant que quiconque ne le remarque.

Les outils d'IA produisent ce type de code plus rapidement que jamais, et aucun n'est sécurisé par défaut. Un code propre est plus facile à déployer et à réutiliser, ce qui signifie que les vulnérabilités se propagent discrètement et rapidement.

La seule façon de maîtriser le risque est de détecter les erreurs avant qu'elles ne soient mises en production. Cela signifie s'intégrer directement aux pipelines CI/CD, analyser chaque dépendance et valider les hypothèses avec un feedback immédiat.

Ce que les CISO doivent prendre en compte

Pour les leaders de la sécurité, le vibe coding n'est pas seulement une tendance de développeurs. Il modifie la façon dont les logiciels sont construits au sein de l'organisation. Le rôle du CISO évolue, passant de l'application de barrières à la conception de garde-fous qui permettent aux gens d'expérimenter sans compromettre la production.

Quelques pistes de réflexion :

• MTTG (Mean Time to Guidance)
  Les métriques traditionnelles comme le MTTD et le MTTR mesurent ce qui se passe après qu'un problème survient. Le MTTG mesure la rapidité avec laquelle les vibe coders obtiennent des conseils exploitables avant que leur code ne devienne une vulnérabilité. Plus le MTTG est bas, moins les incidents se matérialisent.
  
  
• PromptBOMs
  Imaginez des SBOM, mais pour le code généré par l'IA. Un enregistrement simple du modèle, du prompt et des paramètres qui ont généré un extrait de code. Si quelque chose ne fonctionne pas, vous savez d'où cela vient et pourquoi. La provenance est synonyme de responsabilité.
  
  
• Niveaux d'assurance du Vibe-Coding (VCAL 0–5)
  Similaire aux niveaux de conduite autonome, mais pour le codage assisté par l'IA. VCAL-1 signifie que l'IA ne fait que des suggestions. VCAL-3 ajoute des garde-fous et la capture de la provenance. VCAL-5 correspond à des fusions entièrement autonomes pour les changements à faible risque avec attestation continue. Ce cadre offre aux CISO un moyen de calibrer les attentes au lieu de réagir aveuglément.
  

La conclusion : n'essayez pas d'enseigner à chaque employé à « faire de la sécurité ». Proposez plutôt une UX de sécurité invisible, intégrée et adaptée à la manière dont les gens développent réellement avec l'IA.

En résumé 

Le vibe coding n'est pas près de disparaître. Le code est écrit à la vitesse de l'IA par des personnes au sein et en dehors de l'ingénierie. Si vous ne prévoyez pas la sécurité, vous ne faites pas que progresser rapidement, vous propagez également les vulnérabilités tout aussi vite.

L'ambiance est bonne. N'oubliez simplement pas le contrôle de sécurité.

Vous voulez les étapes pratiques ? Lisez la Checklist de sécurité des Vibe Coders.