Quand le Vibe Coding dérape : Comment les applications créées par IA échappent au contrôle de la sécurité informatique

Le problème est arrivé plus vite que tout le monde ne l’anticipait

Un responsable marketing dans une PME a besoin d’un outil interne pour suivre les performances de ses campagnes publicitaires. Il ouvre Lovable, Bolt.new ou un outil similaire, décrit ce qu’il veut en quelques phrases en langage naturel, et trente minutes plus tard, il a une application web fonctionnelle. Il la déploie et envoie le lien à son équipe.

Ce qu’il ne sait pas : son application expose en clair, dans son code client, la clé API qui donne accès à la base de données clients de son entreprise. N’importe qui avec un scanner basique peut la trouver et l’exploiter.

Ce scénario n’est pas hypothétique. Il s’est produit des milliers de fois. Et en mai 2026, un rapport publié par la société de cybersécurité RedAccess a rendu la réalité de ce phénomène impossible à ignorer.

Le rapport qui a secoué l’industrie

Le document s’appelle « Shadow Builders » et il est l’un des plus importants rapports de sécurité applicative publiés depuis plusieurs années.

La méthodologie est simple et dévatatrice : RedAccess a scanné passivement le web, en cherchant des applications déployées via les principales plateformes de vibe coding : Lovable, Bolt.new, Base44, et d’autres. Pas d’attaque, pas d’intrusion, juste de la surveillance passive, le genre de scan que n’importe quel attaquant compétent effectue en permanence.

Les résultats :

• 380 000 applications déployées publiquement, construites via des outils de vibe coding
• Plus de 2 000 de ces applications présentent des vulnérabilités hautement critiques en production
• 400 secrets exposés : clés API, tokens d’accès, identifiants de bases de données en clair, accessibles sans aucune authentification
• 175 instances de données personnelles identifiables (PII), dont des dossiers médicaux et des données de paiement
• Zéro contrôle d’accès sur des milliers d’applications manipulant des données sensibles d’entreprise

Ces applications ne sont pas dans des environnements de test. Elles sont en production. Elles traitent de vraies données de vrais utilisateurs, dans de vraies entreprises.

Pour mesurer l’ampleur du problème, un chiffre de Georgia Tech’s Vibe Security Radar vient compléter le tableau : le nombre de CVE (vulnérabilités officiellement référencées) attribuables au code généré par IA est passé de 6 en janvier 2026 à 35 en mars 2026. Rien que sur un mois. La courbe est verticale.

Mais c’est quoi exactement, le « vibe coding » ?

Avant d’aller plus loin, il faut expliquer ce terme qui est apparu partout en 2025 et que beaucoup de gens utilisent sans bien le comprendre.

L’origine du terme

Le mot « vibe coding » a été inventé par Andrej Karpathy, l’un des cerveaux les plus respectés du monde de l’IA, cofondateur d’OpenAI et ancien responsable de l’Autopilot de Tesla, dans un tweet publié en février 2025. Il décrivait sa propre pratique : utiliser un assistant IA pour générer du code en lui décrivant ce qu’on veut obtenir, dans un style décontracté, presque intuitif, sans se soucier des détails techniques. Vibe en anglais, c’est l’ambiance, l’énergie, l’intuition. Le vibe coding, c’est coder à l’instinct, déléguer la technique à l’IA.

Collins English Dictionary a même désigné « vibe coding » comme son Mot de l’année 2025. Ça dit quelque chose sur la vitesse à laquelle ce phénomène s’est imposé dans la culture tech.

Comment ça fonctionne en pratique

Concrètement, le vibe coding, c’est ceci :

1. Vous décrivez en langage naturel l’application que vous voulez : « Je veux un tableau de bord qui affiche nos ventes par région, avec un export Excel et une connexion à notre base de données client »
2. L’outil IA (Lovable, Bolt.new, Base44, Cursor, Replit Agent…) génère automatiquement le code complet de l’application
3. Vous voyez le résultat en direct, demandez des ajustements (« rends l’interface plus jolie », « ajoute un filtre par date »)
4. Vous déployez en un clic

Le tout en quelques dizaines de minutes, sans jamais écrire une seule ligne de code vous-même, sans forcément comprendre ce que le code généré fait réellement.

C’est la révolution que tout le monde célébrait. Et c’est aussi, simultanément, le problème.

Des chiffres qui donnent le vertige

• Gartner prévoit que 60 % de tout le code nouveau produit en 2026 sera généré par IA
• Lovable, l’une des plateformes phares du secteur, est valorisée à 6,6 milliards de dollars et compte 8 millions d’utilisateurs
• La grande majorité de ces utilisateurs ne sont pas des développeurs professionnels

Pourquoi les applications vibe-codées sont structurellement peu sûres

Problème #1 : Le code généré par IA ne pense pas à la sécurité

Les modèles de langage qui génèrent du code apprennent à partir d’exemples. Des milliards de lignes de code présentes sur GitHub, Stack Overflow, des tutoriels en ligne. Or, une grande partie de ce code d’exemple contient des raccourcis qui fonctionnent mais ne sont pas sûrs en production. Les modèles reproduisent ces patterns sans distinguer ce qui est « ça marche dans un exemple » de ce qui est « ça résiste à une attaque réelle ».

Les données sont accablantes :

• Entre 40 et 62 % du code généré par IA contient des vulnérabilités de sécurité, selon les études consultées
• Le code produit par IA génère des failles à un taux 2,74 fois supérieur au code écrit par des développeurs humains expérimentés
• 91,5 % des applications vibe-codées avaient au moins une faille liée à une hallucination de l’IA au premier trimestre 2026

Problème #2 : Les créateurs non-techniques ne savent pas ce qu’ils ont construit

Ami Luttwak, cofondateur et CTO de Wiz, l’une des firmes de cybersécurité cloud les plus influentes au monde a résumé le problème avec une précision chirurgicale en mars 2026 :

« Quand quelqu’un de non-technique crée cette application extraordinaire, la plupart du temps il ne pense pas à la sécurité et il ne sait même pas ce qu’il y a à l’intérieur, parce qu’il ne l’a pas créée lui-même. »

C’est ça le cœur du problème. Un développeur professionnel qui écrit du code comprend ce qu’il écrit. Il sait reconnaître un contrôle d’accès manquant, une clé API mal positionnée, une injection SQL possible. Un marketeur, un analyste financier ou un chef de projet qui génère une application via des prompts en langage naturel n’a aucun de ces réflexes pas parce qu’il n’est pas intelligent, mais parce qu’on ne lui a jamais appris à penser comme un attaquant.

Problème #3 : Les cinq failles les plus fréquentes dans le code IA

Les chercheurs en sécurité ont catalogué les vulnérabilités qui reviennent systématiquement dans les applications vibe-codées. Voici les plus critiques :

🔑 Secrets exposés dans le code client

L’IA inclut fréquemment des clés API, des tokens d’accès et des mots de passe directement dans le code JavaScript qui tourne dans votre navigateur. Ce code est public, lisible par n’importe qui. Un attaquant n’a besoin que de « Ctrl+U » (afficher le code source) pour mettre la main dessus.

Exemple : En janvier 2026, un réseau social appelé Moltbook a été lancé par un fondateur qui avait construit toute la plateforme via des prompts IA sans écrire une seule ligne de code. Trois jours après son lancement, les chercheurs de Wiz Security ont découvert une clé API Supabase exposée dans le JavaScript côté client, avec la sécurité par rangées (Row Level Security) complètement désactivée. Tout le contenu de la base de données était accessible.

🚪 Absence de contrôle d’accès

L’IA génère facilement des interfaces utilisateur attractives, mais oublie régulièrement de vérifier si l’utilisateur qui tente d’accéder à une ressource est bien autorisé à le faire. Résultat : changer l’identifiant d’un utilisateur dans l’URL permet parfois d’accéder aux données d’un autre. C’est ce qu’on appelle une BOLA (Broken Object-Level Authorization).

La plateforme Base44 a été victime exactement de ce type de vulnérabilité en juillet 2025. Des endpoints API exposés permettaient à n’importe quel utilisateur enregistré d’accéder aux applications privées d’autres utilisateurs en connaissant simplement leur app_id, un identifiant visible publiquement.

🌐 SSRF : Votre serveur comme relais d’attaque

Le Server-Side Request Forgery (SSRF) est une faille complexe mais dévastatrice. Elle permet à un attaquant de forcer votre serveur à effectuer des requêtes vers des ressources internes, y compris les métadonnées d’infrastructure cloud qui contiennent des clés d’accès maîtresses.

Dans une étude de décembre 2025 menée par Tenzai, cinq agents de coding IA majeurs ont été testés. Les cinq ont introduit une vulnérabilité SSRF dans le même type de fonctionnalité. Cinq sur cinq : 100 %. Ce n’est pas un hasard, c’est un schéma systémique dans la façon dont ces modèles génèrent du code réseau.

💉 Injections SQL et de commandes

L’IA génère du code qui construit des requêtes de base de données en concaténant directement des valeurs saisies par l’utilisateur, sans les filtrer ni les paramétrer. C’est l’une des vulnérabilités les plus anciennes d’Internet et l’une des plus exploitées. Elle figure dans le Top 3 de l’OWASP depuis des décennies.

📦 Dépendances non vérifiées

L’IA suggère des librairies tierces pour résoudre des problèmes spécifiques, sans vérifier si ces librairies ont des versions à jour ou des vulnérabilités connues (CVE). Le code généré inclut des dépendances sans verrouillage de version, ce qui signifie qu’une mise à jour automatique peut introduire une faille le lendemain.

Le cas Lovable : 48 jours de vulnérabilité ouverte, rapport ignoré

Le cas de Lovable illustre à lui seul l’ampleur systémique du problème et pas seulement sur le plan technique.

Lovable est l’une des plateformes de vibe coding les plus populaires : 6,6 milliards de dollars de valorisation, 8 millions d’utilisateurs, des milliers d’applications déployées chaque jour. Entre début 2026 et mai 2026, trois incidents de sécurité documentés ont frappé la plateforme.

Le dernier en date, et le plus inquiétant, concerne une vulnérabilité BOLA (Broken Object-Level Authorization) qui a été :

1. Découverte par un chercheur en sécurité
2. Signalée via un programme de bug bounty
3. Fermée sans escalade par les équipes de Lovable
4. Laissée ouverte pendant 48 jours
5. Finalement corrigée après que la presse spécialisée s’en soit emparée

Ce n’est pas qu’une défaillance technique. C’est une défaillance de gouvernance. La structure d’incitation du secteur : croissance rapide, valorisations astronomiques, pression sur les nouvelles fonctionnalités, est structurellement opposée à la rigueur de sécurité.

Le problème de la « Shadow IT » version 2026

La situation décrite dans le rapport RedAccess n’est pas simplement un problème de code mal écrit. C’est un problème de gouvernance organisationnelle qui dépasse largement la technique.

Quand l’application n’existe pas officiellement

Voici comment ça se passe dans une entreprise aujourd’hui :

1. Un employé non-technique a besoin d’un outil → il le crée en vibe coding en 45 minutes.
2. L’application n’est jamais soumise au service IT → elle ne passe par aucun workflow d’approbation.
3. Elle n’est jamais enregistrée dans le CMDB (la base d’inventaire des actifs informatiques).
4. Elle ne passe jamais dans un scanner de vulnérabilités.
5. L’équipe sécurité ne sait pas qu’elle existe.
6. L’entreprise passe son prochain audit de conformité, pendant que l’exposition est active en production

Un chercheur de RedAccess résume cela d’une formule frappante : « L’artefact a migré depuis un prompt IA vers un endpoint public exposé, sans jamais toucher aucune des couches de sécurité existantes. »

C’est ça le vrai défi. Le problème n’est pas que les outils de sécurité sont insuffisants. C’est que les applications vibe-codées contournent entièrement les canaux où ces outils auraient pu les intercepter.

Le CISO face à un mur

Le CISO (Chief Information Security Officer) ou le responsable de la sécurité informatique d’une organisation, se retrouve dans une position intenable.

Il a investi dans un EDR (protection des endpoints), un DLP (prévention des fuites de données), un CASB (broker de sécurité cloud), un pare-feu, un SSE (Security Service Edge). Son stack de sécurité est complet, à jour, bien configuré. Et pourtant, 2 000 applications d’entreprise exposent des données sensibles en production sans qu’il le sache.

Pourquoi ? Parce que tous ces outils ont été conçus pour protéger les applications qu’il connaît. Pas les applications créées la nuit dernière par un stagiaire enthousiaste qui a découvert Bolt.new.

Ce que les entreprises peuvent faire concrètement

Face à ce tableau, quelles sont les mesures pratiques disponibles aujourd’hui ?

✅ Instaurer un registre des outils IA autorisés

La première mesure, la plus immédiate, est de définir une liste d’outils de vibe coding approuvés au niveau de l’entreprise, et d’interdire (ou de surveiller étroitement) l’usage d’autres plateformes pour créer des applications manipulant des données d’entreprise.

Ce n’est pas suffisant en soi, les employés trouveront toujours des moyens de contourner mais c’est le point de départ d’une gouvernance réelle.

✅ Intégrer le scan de sécurité dans le déploiement

Pour les applications vibe-codées déployées via des outils approuvés, intégrer des scanners SAST (Static Application Security Testing) dans le pipeline de déploiement, c’est-à-dire avant que l’application soit accessible publiquement.

Mise en garde importante : les outils SAST traditionnels sont peu efficaces sur le code généré par IA. Ils sont calibrés pour des modèles de code humain et ratent fréquemment les vulnérabilités spécifiques à la génération automatique. Des solutions adaptées au vibe coding commencent à émerger (Escape.tech, Wiz, Snyk pour le code IA) mais le marché est encore en construction.

✅ Appliquer le principe du moindre privilège

Les applications vibe-codées ont tendance à demander des accès bien trop larges par défaut parce que l’IA génère du code qui fonctionne, pas du code optimisé pour la sécurité. S’assurer que chaque application ne peut accéder qu’aux données strictement nécessaires à sa fonction.

L’ISACA a documenté qu’une gouvernance à trois niveaux (outil approuvé, scan intégré, RBAC strict) permet une réduction de 36 % du temps de remédiation sans ralentir significativement la productivité des développeurs citoyens.

✅ Former réellement

Pas une session de sensibilisation en ligne de vingt minutes avec un quiz à la fin. Une formation pratique qui enseigne les bases du threat modeling (modélisation des menaces) à tout employé qui utilise des outils de génération de code. Qu’est-ce qu’une clé API ? Pourquoi ne doit-elle jamais être dans le code client ? Qu’est-ce qu’un contrôle d’accès ? Ces concepts ne sont pas ou plus réservés aux développeurs.

✅ Scanner l’existant en urgence

Si votre organisation laisse des employés créer et déployer des applications via des outils IA depuis plusieurs mois, ce qui est probable, il est urgent d’auditer ce qui existe déjà en production. Des outils comme ceux qu’utilise RedAccess font exactement ça : scanner passivement les applications exposées pour identifier les vulnérabilités critiques avant que quelqu’un d’autre le fasse à votre place.

L’innovation sans garde-fous est une bombe à retardement

Il y a quelque chose de profondément paradoxal dans la situation que ce rapport décrit.

Les outils de vibe coding représentent une démocratisation réelle et précieuse de la création technologique. Pendant des décennies, construire une application nécessitait des années de formation en développement, un budget de développeur, et du temps. Ces outils brisent cette barrière. Un directeur commercial qui comprend parfaitement son problème métier peut maintenant construire l’outil dont il a besoin, sans dépendre d’une équipe IT surchargée. C’est une libération créatrice authentique.

Mais cette même libération, sans cadre de sécurité, crée ce qu’on appelle en sécurité une surface d’attaque incontrôlée. Des milliers de portes ouvertes sur l’infrastructure d’entreprise, créées par des personnes qui ne savaient pas qu’elles les ouvraient.

Le vrai coupable n’est pas l’employé

On pourrait être tenté de blâmer les employés non-techniques qui déploient des applications non sécurisées. Ce serait injuste et contre-productif.

Le responsable marketing qui utilise Bolt.new pour créer un dashboard n’est pas négligent. Il fait son travail avec les outils disponibles. Il ne sait pas que son code expose une clé API et pourquoi le saurait-il ? Personne ne le lui a appris, et les outils qu’il utilise ne l’en avertissent pas.

Les vrais coupables sont au nombre de trois.

Les plateformes de vibe coding d’abord : elles ont une responsabilité directe dans la sécurité par défaut de ce qu’elles génèrent. Un outil qui produit du code avec des clés API exposées côté client devrait bloquer ce déploiement ou au minimum alerter avec une frappante rouge impossible à ignorer. La croissance à tout prix, les 8 millions d’utilisateurs, les valorisations à 6 milliards, tout cela ne dispense pas d’une responsabilité produit fondamentale.

Les directions d’entreprise ensuite : qui ont adopté ces outils sans construire simultanément le cadre de gouvernance qui aurait dû les accompagner. L’enthousiasme pour la productivité IA est compréhensible, les gains sont réels. Mais autoriser tacitement des employés à déployer des applications en production sans aucune supervision de sécurité, c’est une décision managériale qui a des conséquences.

L’écosystème de sécurité enfin : qui n’a pas anticipé assez vite la rapidité avec laquelle ce phénomène allait proliférer. Les outils de sécurité traditionnels n’étaient pas prêts. L’adaptation est en cours mais la courbe des CVE liés au vibe coding monte bien plus vite que celle des solutions.

La vraie question de fond

Ce rapport pose, en filigrane, une question qui dépasse largement la cybersécurité : à quelle vitesse peut-on démocratiser la création technologique sans mettre en danger ceux que ces technologies sont censées servir ?

L’analogie avec l’automobile est pertinente. On n’a pas commencé à vendre des voitures à tout le monde sans concevoir simultanément des ceintures de sécurité, des code de la route, des permis de conduire et des assurances obligatoires. La technologie automobile était suffisamment dangereuse pour justifier un cadre. Les applications qui traitent des données médicales, des informations financières, des données personnelles de millions d’utilisateurs, elles le sont au moins autant.

L’heure n’est pas à freiner l’innovation. Elle est à construire, rapidement et sérieusement, les garde-fous qui permettront à cette innovation de tenir ses promesses sans laisser des millions d’utilisateurs exposés dans son sillage.