Vibe coding : quels risques de sécurité ?
Le premier risque du vibe coding n’est pas une application qui plante. C’est une application qui fonctionne très bien et qui expose les données de ses utilisateurs sans que personne s’en aperçoive. L’IA écrit ce qu’on lui demande : un écran, un bouton, une option. Savoir qui a le droit de lire quoi, personne ne le lui demande, et cela reste souvent absent.
Le vibe coding désigne une façon de créer un logiciel en décrivant ce qu’on veut à une IA, qui écrit tout le code, sans que l’auteur le relise. Le terme vient d’Andrej Karpathy, en février 2025, qui proposait d’oublier que le code existe. Le dictionnaire Collins en a fait son mot de l’année 2025 (Wikipedia). Pour un prototype, c’est remarquable. Nous avons déjà expliqué pourquoi un site professionnel demande autre chose. Un cas récent montre ce que cela coûte quand de vraies personnes sont derrière les données.
Le cas : une position au mètre près, malgré l’option qui la masque
Le 10 octobre 2026, un développeur a publié sur X un signalement vu plus d’un million de fois en deux jours. Il concerne une application de rencontre fondée sur la proximité. D’après lui, le serveur renvoyait pour chaque profil :
- la position du membre, au mètre près ;
- l’heure de sa dernière activité, donc l’indication qu’il s’y trouve encore ;
- le tout même quand le membre avait activé les options « masque ma distance » et « incognito ».
Aucun piratage n’était nécessaire. Toujours selon ce signalement, il suffisait d’ouvrir les outils de développement du navigateur (touche F12) et de lire les réponses du serveur. L’auteur estime que l’application a été produite à l’IA par une personne sans formation de développeur. D’autres internautes ont relevé, dans le code livré au navigateur, des commentaires typiques d’un assistant.
Nous ne nommons pas l’application et nous ne donnons pas le lien. La faille est peut-être encore ouverte, et ses membres n’ont rien demandé. Nous n’avons pas vérifié nous-mêmes les données exposées, et ce n’est pas notre rôle. Ce qui compte ici, c’est le mécanisme, parce qu’il est banal.
Une précision, pour être juste : que le code d’une page web soit lisible n’est pas une faille. Tout navigateur reçoit le JavaScript qu’il exécute. La faille, c’est ce que le serveur accepte d’envoyer.
Pourquoi masquer dans l’interface ne protège rien
Une option « masque ma distance » peut être réalisée de deux façons. Soit le serveur continue d’envoyer la position, et l’écran se contente de ne plus l’afficher. Soit le serveur ne l’envoie plus du tout. À l’écran, le résultat est identique. Dans le premier cas, la donnée voyage quand même jusqu’à l’appareil de chaque visiteur.
L’exposition excessive de données désigne le fait qu’une API renvoie des propriétés d’un objet que l’utilisateur ne devrait pas pouvoir lire. C’est le risque numéro 3 du classement OWASP des dix principaux risques de sécurité des API, édition 2023, sous la référence API3:2023 (OWASP). Le premier scénario d’attaque que l’OWASP y donne en exemple met en scène une application de rencontre, dont une réponse contient la localisation récente d’un autre membre. Le défaut est donc connu, documenté, et il a un nom.
Il ne touche pas que les amateurs. Des chercheurs de l’université KU Leuven ont analysé 15 applications de rencontre géolocalisées : 6 permettaient de retrouver la position exacte d’un membre (USENIX Security 2024). Un professionnel n’est pas infaillible. Il sait que ce défaut existe, il le cherche avant la mise en ligne, et il répond de la correction.
Ce que l’IA écrit bien, et ce qu’elle n’écrit pas si personne ne le demande
Quatre constats, tous vérifiables.
- Le code généré contient souvent des failles. Veracode a testé le code produit par plus de 100 modèles de langage, dans quatre langages de programmation : il introduisait une faille de sécurité à risque dans 45 % des tests (Veracode, rapport 2025).
- Le contrôle d’accès est le défaut numéro un du web. Il occupe la première place du classement OWASP Top 10 2025, qui indique que 100 % des applications testées en présentaient une forme. L’OWASP précise qu’un contrôle d’accès n’est efficace que s’il est appliqué côté serveur (OWASP Top 10 2025).
- Les outils vous laissent la responsabilité. La faille CVE-2025-48757, notée 9,3 sur 10, concernait des sites générés avec Lovable : leur base de données pouvait être lue et modifiée sans authentification. L’éditeur conteste ce classement, au motif que chaque client accepte la responsabilité de protéger les données de son application (NVD).
- Leur documentation le dit noir sur blanc. Celle de Lovable écrit que l’absence de règles d’accès ligne par ligne est la cause la plus courante d’exposition des données d’une application (Lovable). Celle de Supabase écrit qu’une table exposée sans ces règles est lisible et modifiable par tout rôle qui y a accès (Supabase). Celle de Claude Code écrit que l’utilisateur est responsable de la relecture du code proposé avant de l’approuver (Claude Code).
Le bon réflexe existe : demander à l’IA de chercher les failles de ce qu’elle vient d’écrire. Claude Code a par exemple une commande /security-review, qui passe en revue les modifications en cours. Encore faut-il savoir qu’il faut le demander, puis savoir lire la réponse.
Les limites du vibe coding, point par point
Le vibe coding produit ce qui se voit. Une revue professionnelle porte sur ce qui ne se voit pas.
| Question | Ce que donne le vibe coding seul | Ce qu’ajoute une revue professionnelle |
|---|---|---|
| Qui peut lire cette donnée ? | L’écran masque l’information | Le serveur ne l’envoie pas |
| Options de confidentialité | Une case cochée dans l’interface | Une règle appliquée côté serveur, testée avec un second compte |
| Base de données | Des tables créées, des accès qui peuvent rester ouverts si rien n’est précisé | Des règles d’accès ligne par ligne, vérifiées table par table |
| Données sensibles | Stockées et renvoyées telles quelles | Réduites au nécessaire : position arrondie, pas d’horodatage précis |
| Incident | Personne ne le voit | Des journaux, une procédure, quelqu’un qui répond |
Fuite de données : ce que risque l’éditeur de l’application
Code généré ou non, la responsabilité reste à celui qui exploite l’application. Nous l’avons détaillé dans RGPD et site généré par IA : qui est responsable ? Trois points s’appliquent directement à ce cas.
- La sécurité est une obligation. L’article 32 du RGPD impose des mesures techniques et organisationnelles appropriées, pour un niveau de sécurité adapté au risque (CNIL, chapitre 4 du RGPD).
- Certaines données sont sensibles par nature. Les données concernant la vie sexuelle ou l’orientation sexuelle font partie des données sensibles, dont le traitement est interdit sauf exceptions (CNIL). Sur une application de rencontre, un profil associé à une position précise en dit long sur une personne.
- Une fuite se déclare. Quand une violation présente un risque pour les personnes, la CNIL attend une notification initiale dans les 72h si possible. Si le risque est élevé, les personnes concernées doivent aussi être prévenues (CNIL).
Les amendes prévues par le RGPD peuvent atteindre 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour un manquement aux obligations de sécurité. Elles montent à 20 millions d’euros ou 4 % pour une atteinte aux principes de base, dont les règles sur les données sensibles (CNIL, article 83).
Avant d’ouvrir une application à de vrais utilisateurs : 7 vérifications
- Ouvrez les outils de développement (F12, onglet Réseau) avec un compte de test. Lisez les réponses du serveur : contiennent-elles un champ que l’écran n’affiche pas ?
- Créez deux comptes. Le premier peut-il lire ou modifier les données du second en changeant un identifiant dans une requête ?
- Pour chaque option de confidentialité, vérifiez la réponse du serveur, pas l’écran.
- Sur la base de données, activez la sécurité au niveau des lignes sur chaque table exposée, puis écrivez les règles.
- Pour une position, arrondissez côté serveur. N’envoyez jamais de coordonnées brutes à un autre utilisateur.
- Demandez à l’IA une revue de sécurité, puis faites relire le résultat par quelqu’un qui sait le lire.
- Préparez l’incident : qui coupe l’accès, qui prévient la CNIL, sous 72h.
Si une de ces lignes vous arrête, l’application n’est pas prête pour des données réelles.
Vibe coding ou agence : où passe la ligne
Pour un prototype, une maquette, un outil interne ou un site vitrine sans comptes utilisateurs, l’IA suffit souvent. Nous avons listé les cas où un site fait à l’IA suffit, et nous les maintenons.
La ligne passe là où commencent les données des autres : comptes utilisateurs, paiements, géolocalisation, santé, tout ce qu’une fuite rendrait dangereux. À partir de là, il faut quelqu’un qui relit le code, teste ce qui ne se voit pas et répond de la correction. Une agence utilise les mêmes IA que vous. Ce que vous lui achetez, c’est la relecture, les tests et la responsabilité.
C’est un travail que nous faisons chez Peechy : nous avons raconté ce que donne la reprise d’un site Lovable au bout d’un an. Si votre projet a déjà des utilisateurs, notre reprise de site commence par un inventaire des accès et un audit, sécurité comprise.
FAQ
Le vibe coding, c'est quoi ?
C’est créer un logiciel en décrivant son intention à une IA qui écrit tout le code, sans le relire. Le terme date de février 2025. Il convient à un prototype, beaucoup moins à une application qui stocke des données personnelles.
Une application faite avec l'IA est-elle sécurisée ?
Pas par défaut. Dans l’étude de Veracode, le code généré introduisait une faille à risque dans 45 % des tests. Elle peut le devenir si quelqu’un vérifie les accès côté serveur, les règles de la base de données et les réponses de l’API.
Peut-on demander à l'IA de vérifier la sécurité de son propre code ?
Oui, et c’est utile. Claude Code, par exemple, a une commande de revue de sécurité. L’outil ne remplace pas la relecture : sa documentation rappelle que l’utilisateur reste responsable du code qu’il approuve.
Qui est responsable d'une fuite de données sur une application générée par IA ?
L’éditeur de l’application, c’est-à-dire la personne ou l’entreprise qui l’exploite. Ni l’IA ni l’hébergeur ne portent cette responsabilité à sa place. Une violation présentant un risque se notifie à la CNIL dans les 72h si possible.
Comment savoir si mon application expose des données ?
Ouvrez les outils de développement du navigateur, onglet Réseau, et lisez ce que le serveur renvoie. Tout champ présent dans la réponse est accessible au visiteur, même si l’écran ne l’affiche pas.
Contactez Peechy et vous n'aurez pas ce bug
Vous construisez un site ou une application avec l'IA ? On relit le code, on teste ce qui ne se voit pas à l'écran, accès, données, options de confidentialité, et on corrige avant la mise en ligne.
Contacter Peechy
