Vibe coding, données exposées : la face cachée de la révolution du code sans compétences
Le "vibe coding" est un phénomène en forte croissance depuis 2025, popularisé par des plateformes comme Bolt, Lovable, v0, et plus récemment Codex d'OpenAI. Ces outils permettent à des non-développeurs — cadres, directeurs, entrepreneurs — de créer des applications web et mobiles en décrivant leurs besoins en langage naturel. La vitesse de création (une application en quelques heures) et la réduction des coûts associés ont alimenté un engouement massif. Mais les utilisateurs de ces outils n'ont généralement aucune formation en sécurité applicative, et les outils eux-mêmes ne génèrent pas systématiquement de contrôles d'accès robustes, de gestion des secrets ou de chiffrement adéquats.
1. L'ampleur est documentée et systémique, pas anecdotique
WIRED et Axios ne parlent pas de cas isolés — leurs investigations portent sur des milliers d'applications exposées, consultables sur le web ouvert sans authentification. C'est un phénomène de masse qui reflète la démocratisation du développement sans démocratisation des pratiques de sécurité.
2. Les données exposées concernent directement les entreprises
Au-delà des données personnelles d'utilisateurs individuels, les rapports mentionnent des données d'entreprise sensibles : informations clients, données propriétaires, potentiellement des identifiants de services tiers intégrés dans le code généré. Ce dernier point est particulièrement critique : les apps vibe-codées intègrent parfois des clés API, des credentials de base de données ou des tokens d'authentification directement dans le code front-end.
3. Le modèle de menace est nouveau pour les RSSI
Jusqu'ici, la surface d'attaque applicative était largement délimitée par le nombre de développeurs qualifiés dans l'organisation. Le vibe coding efface cette barrière : n'importe quel salarié peut déployer une application connectée à des systèmes d'entreprise sans passer par les processus de revue de sécurité habituels. C'est un vecteur d'attaque de shadow IT à une échelle inédite.
4. Les plateformes de vibe coding n'assument pas la responsabilité de la sécurité
Les conditions d'utilisation de Bolt, Lovable et des outils similaires délèguent la responsabilité de la sécurité à l'utilisateur. Ce modèle est structurellement incompatible avec les obligations réglementaires des entreprises (RGPD, SOC 2, ISO 27001) qui ne peuvent pas déléguer la conformité à des utilisateurs non formés.
5. Apple bloque certaines apps de vibe coding depuis l'App Store - pour de mauvaises raisons
En parallèle, Apple est critiquée pour bloquer des applications de vibe coding de son store — non pas pour des raisons de sécurité, mais à cause de la clause interdisant l'exécution de code arbitraire. Ce conflit réglementaire crée une asymétrie : les apps les plus risquées (web, sans revue d'Apple) prolifèrent, tandis que les outils mobiles font face à des frictions supplémentaires.
Implications
Sur le plan business : les entreprises dont des salariés utilisent des outils de vibe coding dans un cadre professionnel s'exposent à des violations de données non maîtrisées et potentiellement non détectées. La responsabilité légale en cas d'exposition (RGPD, NIS2) incombe à l'entreprise, pas à la plateforme de vibe coding.
Pour les RSSI : il est urgent de cartographier les usages de vibe coding dans l'organisation, d'établir des politiques claires sur les plateformes autorisées, et d'intégrer une revue de sécurité dans les processus de déploiement même pour les outils no-code/low-code.
Pour les fournisseurs de sécurité : le marché des solutions de SAST (Static Application Security Testing) et de DAST (Dynamic Application Security Testing) adaptées aux applications générées par IA représente une opportunité commerciale émergente. Les acteurs comme Snyk, Veracode ou Check Point devraient intégrer des modules spécifiques au code IA-généré.
Le vibe coding est une réalité organisationnelle, pas une tendance passagère — les chiffres d'adoption le confirment. Mais la démocratisation du développement sans sécurité intégrée crée un risque systémique que les entreprises ne peuvent plus ignorer. Pour les DSI et RSSI, la question n'est plus "est-ce que nos collaborateurs font du vibe coding ?" mais "que font-ils avec les données qu'ils exposent, et le savons-nous ?"
TL;DR
Des milliers d'applications créées par IA sans compétences de développement exposent des données d'entreprise sur le web ouvert — et personne ne le sait.
- Le vibe coding permet à n'importe quel salarié de déployer des applications connectées à des systèmes d'entreprise sans revue de sécurité : c'est du shadow IT à grande échelle.
- Les données exposées incluent des identifiants, des clés API et des données clients — directement dans le code généré par l'IA.
- Les entreprises supportent la responsabilité réglementaire (RGPD, NIS2) de ces expositions, indépendamment de la plateforme utilisée.
Questions fréquentes
Comment identifier si des applications vibe-codées ont été déployées dans mon organisation sans revue de sécurité ?
Un audit de shadow IT ciblé sur les domaines nouvellement enregistrés, les applications Render/Vercel/Netlify non référencées dans le catalogue IT, et une revue des accès API accordés depuis des applications non inventoriées permettent un premier état des lieux. Des outils de CASB (Cloud Access Security Broker) peuvent aider à détecter ces déploiements non maîtrisés.
Les plateformes de vibe coding comme Bolt ou Lovable font-elles quelque chose pour adresser ce risque ?
Certaines plateformes commencent à intégrer des avertissements ou des contrôles basiques, mais la responsabilité reste contractuellement chez l'utilisateur. Aucune plateforme de vibe coding grand public n'offre à ce jour un niveau de contrôle de sécurité équivalent aux pipelines DevSecOps des équipes professionnelles.
Quelle politique adopter face au vibe coding en entreprise ?
Une politique binaire d'interdiction totale est illusoire — le phénomène est trop répandu. Une approche pragmatique consiste à établir une liste de plateformes autorisées, à exiger que tout déploiement utilisant des données d'entreprise passe par une revue de sécurité allégée (checklist de 15 minutes), et à former les utilisateurs sur les risques d'exposition des credentials et des données personnelles.