Le vibe coding produit du code qui marche. Ça ne veut pas dire du code sûr. Ce que personne ne vous dit avant de mettre votre prototype en production.
Une appli construite en trois heures, qui tourne, qui fait exactement ce qu'on lui demande. C'est la promesse du vibe coding, et elle est tenue. Mais « ça marche » et « c'est sûr » sont deux choses différentes — et la deuxième ne se voit pas à l'écran.
Le mois dernier, Cloudflare — qui opère environ 20 % de l'infrastructure d'internet — a publié un retour qui devrait faire réfléchir tout le monde. Avec un accès anticipé à un nouveau modèle, dans le cadre du projet Glasswing, ils lui ont demandé de chercher des failles dans leurs propres outils. Là où les modèles précédents trouvaient des failles isolées, celui-ci a su les enchaîner en une attaque complète.
Si une IA peut enchaîner les failles de votre application en une attaque complète, partez du principe qu'un attaquant le peut aussi.
Pourquoi le code généré est une passoire par défaut
Le modèle optimise ce que vous lui demandez : une fonctionnalité qui marche. Vous ne lui avez pas demandé de penser à l'attaquant — alors il n'y pense pas. Résultat, les mêmes trous reviennent à chaque fois : des clés d'API en clair dans le code envoyé au navigateur, une base de données accessible sans authentification, des données client qui transitent sans contrôle, un bucket de stockage laissé public. Rien de tout ça n'apparaît quand vous testez l'appli : elle marche parfaitement. La faille est invisible jusqu'au jour où quelqu'un la cherche.
Et le non-tech qui a construit l'appli n'a aucun moyen de le savoir. Ce n'est pas un reproche — c'est précisément le point aveugle du vibe coding. La friction entre l'idée et le produit a disparu ; la friction entre le produit et le produit sûr, elle, est toujours là. Elle est juste devenue invisible.
Le vibe coding n'est pas le problème
Soyons clairs : je passe mes journées à construire avec ces outils. Le problème n'est pas le vibe coding. Le problème, c'est de mettre un prototype vibe-codé en production sans passe de sécurité, comme s'il était fini. Le prototype prouve que l'idée tient. Il ne prouve pas qu'elle résiste aux utilisateurs, aux audits et aux gens mal intentionnés.
Ce qu'on fait, concrètement
- Les secrets côté serveur, jamais dans le navigateur. Une clé d'API dans le front, c'est une clé donnée à tout le monde.
- L'authentification avant les données. On ne branche aucune donnée réelle tant que l'accès n'est pas verrouillé — pas « plus tard », tout de suite.
- Retourner l'arme de Cloudflare contre la faille : faire auditer son app par l'IA. Le même modèle qui sait enchaîner des failles sait les trouver dans votre code avant l'attaquant. C'est un réflexe, pas un luxe.
- Une couche sécurité présente partout, pas une phase « sécurité » bricolée à la fin. C'est exactement ce que formalise notre méthode V2P : la qualité et la sécurité traversent les cinq phases, elles ne sont pas un sprint qu'on ajoute quand il reste du temps.
Le vibe coding a démocratisé la construction. Tant mieux. Mais entre un prototype qui marche et un système qu'on expose à de vrais utilisateurs, il y a un métier — et c'est précisément là qu'on intervient. La vitesse sans la sécurité, ce n'est pas de la vitesse. C'est une dette qu'on paiera, avec les intérêts.
François est CTO de Dotika. Il écrit sur ce qui tient, ce qui pète, et ce que personne ne dit quand un prototype passe en production.