Le 7 mai 2026, la société de cybersécurité RedAccess a révélé que des milliers d'applications créées avec des outils de « vibe coding » comme Lovable, Replit, Base44 ou Netlify étaient ouvertes à n'importe qui, données comprises : dossiers médicaux, chiffres financiers, présentations de stratégie. La sécurité du vibe coding ne se joue pas dans l'outil, mais avant lui. Votre prototype peut aller en production le jour où vous avez décidé qui doit voir quelle donnée, et vérifié que c'est bien le cas.
L'essentiel
- RedAccess dit avoir trouvé 380 000 applications et ressources publiquement accessibles, créées avec Lovable, Base44, Replit et Netlify, dont environ 5 000 contenaient des données d'entreprise sensibles.
- Selon WIRED, environ 40 % des applications sans protection examinées par les chercheurs exposaient des données sensibles, soit près de 2 000.
- Les plateformes répondent qu'une application publique est un choix de l'utilisateur, pas une faille. Elles ont en partie raison, et c'est précisément le problème.
- Une IA écrit le code que vous lui demandez. Si personne n'a décidé qui a le droit de voir quoi, elle ne le décidera pas à votre place.
- Avant la mise en production : un cahier des charges qui le dit, puis un test simple, depuis une fenêtre de navigation privée.
Ce qui se passe : la sécurité du vibe coding prise en défaut
On appelle vibe coding le fait de créer une application en la décrivant à une IA, sans écrire le code soi-même. Ces outils permettent à un responsable marketing, à un commercial ou à un fondateur sans formation technique de mettre en ligne un outil en un après-midi.
L'équipe de Dor Zvi, cofondateur de RedAccess, a cherché ces applications avec de simples requêtes sur Google et Bing. C'était facile : Lovable, Replit, Base44 et Netlify hébergent les applications de leurs utilisateurs sur leurs propres noms de domaine. Les chercheurs ont communiqué leurs résultats à WIRED et à Axios, qui les ont publiés le 7 mai 2026.
Les chiffres ne sont pas décrits de la même façon par les deux médias, et je préfère vous donner les deux versions :
- Axios : RedAccess a trouvé 380 000 ressources publiquement accessibles créées avec ces quatre outils, dont environ 5 000 contenaient des données d'entreprise sensibles.
- WIRED : plus de 5 000 applications n'avaient pratiquement aucune sécurité ni authentification ; environ 40 % d'entre elles, près de 2 000, semblaient exposer des données privées.
Dans les deux cas, les exemples sont les mêmes : les affectations de travail d'un hôpital avec les données personnelles de médecins, les achats publicitaires détaillés d'une entreprise, une stratégie commerciale, les conversations complètes du chatbot d'un détaillant avec ses clients, noms et coordonnées compris. Certaines applications n'exigeaient qu'une connexion avec n'importe quelle adresse e-mail. Dans quelques cas, selon Dor Zvi, elles auraient permis de prendre des droits d'administrateur. La page de présentation du rapport de RedAccess retient le même ordre de grandeur : 40 % des applications d'entreprise créées par IA examinées exposaient des données sensibles.
Il faut aussi rapporter les limites. WIRED n'a pas pu confirmer que toutes les données étaient réelles ; certaines applications pouvaient être des essais remplis de données fictives. Et les plateformes ont contesté la méthode. Pour Replit, « les applications publiques accessibles sur Internet, c'est le comportement attendu ». Lovable rappelle que la configuration d'une application est « en définitive la responsabilité de son créateur ». Wix, propriétaire de Base44, parle d'un « choix de configuration de l'utilisateur, pas d'une vulnérabilité de la plateforme ».
Un chercheur cité par WIRED, Joel Margolis, résume le fond du problème : les outils de codage par IA « font ce que vous leur demandez. Et à moins que vous leur demandiez de le faire de façon sûre, ils ne feront pas d'effort particulier pour cela ».
Ce que ça change pour vous
Pour une PME, ces outils sont une vraie chance : un outil interne qui coûtait des semaines de développement peut exister en quelques heures. Mais ils déplacent la décision de mettre en ligne. Elle ne passe plus par un informaticien qui se demande qui a accès à quoi ; elle se prend en un clic, par la personne qui a besoin de l'outil.
RedAccess décrit d'ailleurs ce phénomène comme une nouvelle forme de shadow AI : après les employés qui collent des dossiers clients dans ChatGPT, ceux qui construisent des applications, les relient aux données de l'entreprise et les publient sans que personne ne le sache.
Deux conséquences concrètes :
- Vous ne savez peut-être pas ce qui tourne. Un tableau de bord des ventes, un formulaire de candidature ou un suivi de chantier créé par un collaborateur peut être en ligne, à une adresse que n'importe qui peut trouver par un moteur de recherche.
- La responsabilité reste la vôtre. Les plateformes le disent sans détour : le réglage de visibilité appartient au créateur. Si l'application contient des données de clients ou d'employés, c'est votre entreprise qui en répond, comme pour n'importe quel autre fichier.
Et pour le fondateur qui a un prototype généré par IA et se demande s'il peut le lancer, la réponse honnête est : pas encore, tant que vous ne savez pas répondre à la question « qui voit quoi ».
Ce que j'en ai appris
J'ai développé TSFind, un annuaire de prestataires, avec l'aide de Claude Code, un assistant de programmation par IA. L'un des problèmes centraux du projet était justement celui-ci : exposer des données publiques, les fiches et les avis, sans exposer les données privées, les preuves, les contacts et les abonnements.
J'ai d'abord laissé le navigateur interroger la base de données directement, protégée par des règles qui décident, ligne par ligne, qui peut lire quoi. Plus le modèle de données s'enrichissait, plus ces règles devenaient difficiles à garder justes : il a fallu plusieurs corrections successives pour traiter, un par un, les avertissements de sécurité de la base. J'ai fini par changer d'architecture : toutes les lectures et écritures passent désormais par le serveur, qui choisit précisément ce qu'il renvoie, et les règles restent actives en seconde ligne.
Ce que j'en retiens : l'IA m'a fait gagner beaucoup de temps sur le code, mais aucune sur cette décision. C'est moi qui ai dû comprendre le risque, décider de l'architecture et vérifier le résultat. Une IA livre ce qu'on lui décrit ; elle ne pose pas d'elle-même la question de savoir ce qui doit rester privé.
C'est aussi le conseil que j'ai donné à Justin Gary, créateur de jeux et dirigeant de Stone Blade Entertainment, lors d'un hackathon sur l'IA : commencez par un cahier des charges, ce que les Anglo-Saxons appellent un PRD. Il l'a raconté dans son article : 45 minutes pour écrire le cahier des charges avec Claude, 15 minutes pour le relire, puis 2 heures pour obtenir un prototype fonctionnel avec Lovable. Le cahier des charges est l'endroit où l'on écrit, entre autres, quelles données l'application stocke et qui doit y accéder. C'est la méthode que j'applique sur mes projets d'applications : le cahier des charges d'abord, le code ensuite. J'en parlais déjà, avant l'IA, à propos des outils no-code et de l'improvisation.
Que faire concrètement
1. Faire l'inventaire
Demandez à vos équipes quelles applications elles ont créées avec un outil d'IA, sur quelle plateforme, et avec quelles données. Promettez qu'il n'y aura pas de reproche : vous voulez une liste complète, pas des coupables.
2. Faire le test de la fenêtre privée
Ouvrez l'adresse de chaque application dans une fenêtre de navigation privée, sans être connecté. Si vous voyez des données, tout le monde les voit. Créez ensuite un deuxième compte de test : s'il voit les données du premier, l'application ne cloisonne pas ses utilisateurs.
3. Écrire qui doit voir quoi
Pour chaque application, une page suffit : quelles données elle contient, et pour chacune, qui y a droit (tout le monde, les utilisateurs connectés, seulement leur propriétaire, l'administrateur). C'est le cœur du cahier des charges. S'il n'existe pas, écrivez-le maintenant.
4. Corriger les réglages, ou retirer l'application
Passez en privé ce qui n'a pas à être public, exigez une vraie authentification, et vérifiez qu'aucune clé secrète ne se trouve dans le code envoyé au navigateur. Si l'application contient des données réelles qu'elle ne sait pas protéger, retirez-la le temps de la corriger.
5. Décider ce qui reste un prototype
Un prototype avec des données fictives est un excellent outil de discussion. Un outil qui manipule des données de clients mérite une architecture pensée, une relecture par quelqu'un d'autre que son auteur, et un responsable désigné. Décidez, application par application, de quel côté elle se trouve.
Questions fréquentes
Puis-je mettre en production une application créée par IA ?
Oui, si vous savez quelles données elle contient, qui doit y accéder, et si vous l'avez vérifié vous-même, au minimum avec le test de la fenêtre privée et un deuxième compte. L'origine du code compte moins que la vérification.
Les plateformes de vibe coding sont-elles responsables ?
Elles fournissent des réglages de visibilité et d'accès, et considèrent que leur usage relève de l'utilisateur. Quoi qu'on en pense, c'est vous qui répondez des données de vos clients : ne comptez pas sur les réglages par défaut.
Faut-il interdire ces outils dans l'entreprise ?
Non. Ils sont utiles, et l'interdiction pousse à les utiliser en cachette. Mieux vaut une règle simple : on prototype librement avec des données fictives, et rien ne touche des données réelles sans cahier des charges ni vérification.
Pour aller plus loin
Je conçois et développe des applications et automatisations sur mesure, en commençant par le cahier des charges, et je peux aussi relire un prototype existant avant sa mise en production. Pour en parler sur votre cas : un appel de 20 minutes.
Sources
- Thousands of Vibe-Coded Apps Expose Corporate and Personal Data on the Open Web, Andy Greenberg, WIRED, 7 mai 2026.
- AI vibe-coding apps leak sensitive data, Sam Sabin, Axios, 7 mai 2026.
- Report: The Shadow Builders Inside Your Organization, RedAccess, 8 octobre 2026.
- A Game Designer's Guide to Vibe Coding, Justin Gary, Substack, 3 juin 2025.
Photo de couverture : Kelly Sikkema / Unsplash, licence Unsplash.
Tags : vibe coding, sécurité des applications, IA générative, protection des données, cahier des charges, applications sur mesure