Tout le monde ne devrait pas mettre en production le logiciel qu'il construit.
Il y a un moment qui revient dans chaque session de vibe coding. Vous tapez quelque chose comme « construis-moi un système de connexion avec des paiements Stripe » dans Cursor ou Lovable, l'IA produit une application fonctionnelle, et vous vous sentez invincible. Le code tourne. Les boutons cliquent. Les paiements passent. Vous êtes développeur maintenant.
Sauf que non. Et les personnes qui utiliseront votre application sont sur le point de le découvrir à leurs dépens.
Qu'est-ce que le vibe coding, exactement ?
Le terme a été inventé par Andrej Karpathy début 2025 et est rapidement devenu le mot de l'année du Collins Dictionary. L'idée est simple : vous décrivez ce que vous voulez en langage courant, une IA génère le code, et vous le mettez en production sans lire chaque ligne. « Laissez-vous porter par les vibes », comme l'a formulé Karpathy, « et oubliez que le code existe. »
En 2026, 92 % des développeurs américains utilisent quotidiennement des outils de codage par IA. GitHub rapporte que 46 % de tout le nouveau code est désormais généré par IA. Parmi la promotion Winter 2025 de Y Combinator, une startup sur cinq avait des bases de code générées à plus de 91 % par l'IA.
L'accélération est réelle. Le problème, c'est qui accélère — et vers où.
Les victimes ne sont pas celles qui écrivent les prompts
Voici ce que la plupart des discussions sur le vibe coding comprennent mal : elles se concentrent sur le développeur. « Est-ce que les vibe coders apprendront à coder correctement ? » est la mauvaise question. La bonne question est : qu'arrive-t-il aux personnes qui téléchargent l'application, saisissent leur carte bancaire et lui confient leurs données ?
Parce qu'en ce moment, la réponse est : rien de bon.
En janvier 2026, une plateforme appelée Moltbook a été lancée en tant que réseau social pour agents IA. Le fondateur a publiquement déclaré qu'il n'avait pas écrit une seule ligne de code — l'ensemble avait été réalisé en vibe coding. En trois jours, des chercheurs en sécurité ont découvert que l'application avait exposé 1,5 million de tokens d'authentification API, 35 000 adresses e-mail et des milliers de messages privés sur l'internet ouvert. La cause première n'était pas un piratage sophistiqué. C'était une base de données mal configurée que l'IA avait mise en place avec un accès public pendant le développement, et que personne n'avait jamais modifié.
Ce n'est pas un cas isolé. Une étude d'Escape.tech a analysé 5 600 applications créées par vibe coding et a trouvé plus de 2 000 vulnérabilités, plus de 400 secrets exposés (API keys, identifiants, tokens lisibles dans le code) et 175 cas de fuites de données personnelles via les endpoints de l'application. Près de la moitié de tous les échantillons de code générés par IA échouent aux tests de sécurité de base.
Les utilisateurs de ces applications ne se sont pas inscrits pour être des bêta-testeurs de l'expérience du week-end de quelqu'un. Ils se sont inscrits pour utiliser un produit. Et ce sont leurs données qui en ont payé le prix.
Comment l'IA produit du code qui fonctionne mais n'est pas sûr
Comprendre pourquoi cela se produit nécessite de comprendre ce pour quoi les outils de codage par IA sont optimisés : faire fonctionner les choses. Pas les rendre sûres. Pas les rendre maintenables. Juste faire disparaître le message d'erreur.
Quand vous dites à une IA « j'obtiens une erreur Permission Denied sur ma base de données », elle ne réfléchit pas aux implications de sécurité. Elle cherche à faire disparaître l'erreur. Elle peut donc générer une politique de base de données qui accorde un accès public à tout. L'erreur a disparu. L'application fonctionne. Et toute votre base de données utilisateurs est désormais lisible par quiconque possède un navigateur.
Voici les schémas qui se répètent dans pratiquement chaque catastrophe de vibe coding :
Secrets codés en dur. Les assistants IA génèrent régulièrement du code avec des API keys, des mots de passe de bases de données et des tokens écrits directement dans les fichiers sources. Quand ce code arrive dans un dépôt — même privé — ces secrets ne sont qu'à une fuite d'être exploités. La faille de Moltbook a commencé exactement de cette manière.
Contrôles d'accès manquants. Dans un cas documenté, du code généré par IA pour plus de 170 applications en production avait inversé la logique de contrôle d'accès : les utilisateurs authentifiés étaient bloqués tandis que les visiteurs non authentifiés avaient un accès complet. Le code passait l'examen visuel. Il semblait correct. Seul un test de sécurité rigoureux aurait pu le détecter.
Sécurité côté client. Une startup appelée Enrichlead avait construit toute sa plateforme avec des outils IA. L'interface était soignée et professionnelle. Mais toute la logique de sécurité résidait dans le navigateur. Dans les 72 heures suivant le lancement, les utilisateurs ont découvert qu'ils pouvaient contourner l'abonnement payant en modifiant une seule valeur dans la console développeur de leur navigateur. Le projet a été définitivement arrêté.
Valeurs par défaut dangereuses. Les modèles d'IA sont entraînés sur un immense corpus de code et gravitent vers ce qui fait fonctionner les choses le plus vite. Cela signifie utiliser dangerouslySetInnerHTML sans assainissement, désactiver la vérification SSL ou configurer CORS pour tout accepter. Ces raccourcis sont acceptables dans un tutoriel. Ils sont catastrophiques en production.
Le vrai coût : ce n'est pas de la dette technique
La dette technique est un terme d'ingénieurs. Le vrai coût des applications vibe-codées non sécurisées se mesure en quelque chose de bien plus tangible : l'argent des gens, les données des gens et la confiance des gens.
Quand un fondateur solo met en production un SaaS vibe-codé et que la clé API Stripe de quelqu'un est exposée, de vraies cartes bancaires sont débitées par de vrais escrocs. Quand une application de santé fuit des informations de patients parce que l'IA n'a pas implémenté les autorisations correctement, de vraies personnes subissent de vraies conséquences. Quand un outil B2B expose l'intégralité de sa base de données clients parce que la route admin était « protégée » en cachant simplement le lien dans l'interface, de vraies entreprises perdent de vraies informations concurrentielles.
Le fondateur passe au projet suivant. Les utilisateurs gèrent les conséquences.
Un chercheur en sécurité qui avait démontré une vulnérabilité zero-click sur la plateforme de vibe coding Orchids — une faille qui lui donnait un accès à distance complet à l'ordinateur portable d'un journaliste de la BBC — avait envoyé douze messages d'avertissement à l'entreprise avant de rendre l'affaire publique. L'entreprise a déclaré avoir « probablement raté » les messages parce que leur équipe était « submergée ».
Submergée par la vitesse de construction. Pas par la sécurité.
« Mais je n'ai qu'à demander à l'IA de corriger »
C'est l'hypothèse la plus dangereuse du vibe coding : que le même outil qui a créé la vulnérabilité peut la corriger. Mais les assistants de codage IA n'ont pas de contexte de sécurité. Ils ne connaissent pas votre modèle de menace. Ils ne comprennent pas quelles données sont sensibles dans votre application spécifique. Ils optimisent une seule chose : faire tourner le code.
Demander à une IA de « rendre ça sécurisé », c'est comme demander à un ouvrier du bâtiment qui ne sait que couler du béton de faire aussi le câblage électrique. Il fera quelque chose. Ça pourrait même avoir l'air correct. Mais vous ne voudriez probablement pas actionner cet interrupteur.
La recherche le confirme. Une analyse de décembre 2025 portant sur 470 pull requests open-source a révélé que le code co-écrit par l'IA contenait 1,7 fois plus de problèmes majeurs que le code écrit par des humains, avec des vulnérabilités de sécurité apparaissant à un taux 2,74 fois supérieur. Du code qui compile et s'exécute avec un taux de réussite de 90 % — mais la sécurité de ce code n'a pas progressé au même rythme.
Alors, que devraient faire concrètement les créateurs non-techniques ?
Je ne vais pas vous dire d'arrêter d'utiliser l'IA pour construire des choses. Ce navire a quitté le port, et franchement, il ne devrait pas revenir. Les outils de codage par IA sont véritablement puissants et ne cessent de s'améliorer. Mais si vous construisez quelque chose que d'autres personnes utiliseront — surtout si elles lui confieront leurs données ou leur argent — voici le minimum :
Ne mettez pas en production ce que vous ne comprenez pas. Si vous ne pouvez pas expliquer ce que votre code fait avec les données des utilisateurs, vous n'êtes pas prêt à le mettre en production. Utilisez l'IA pour construire. Utilisez un humain pour vérifier.
Faites un scan de sécurité avant le lancement. Des outils comme GitGuardian et TruffleHog peuvent détecter automatiquement les secrets exposés dans votre code. Ils ne sont pas parfaits, mais ils repèrent les catastrophes les plus évidentes. Cela prend des minutes, pas des jours.
Traitez votre IA comme un stagiaire, pas comme un ingénieur senior. Elle écrit du code vite. Elle n'écrit pas du code de manière sûre. Chaque sortie nécessite une revue, surtout tout ce qui touche à l'authentification, l'accès aux bases de données ou le traitement des paiements.
Payez pour une revue de sécurité. Si votre application gère des données utilisateur, un audit de sécurité professionnel n'est pas optionnel — c'est le coût de faire des affaires. C'est moins cher qu'une faille.
Utilisez des variables d'environnement pour les secrets. Ne codez jamais d'API keys en dur. Jamais. Ajoutez .env à votre .gitignore avant votre premier commit. C'est de l'hygiène de base que les outils d'IA se trompent systématiquement.
En résumé
Le vibe coding a démocratisé la création de logiciels, et c'est véritablement enthousiasmant. Mais démocratiser la création sans démocratiser la responsabilité, c'est ainsi qu'on obtient un million d'applications avec des bases de données exposées, des identifiants qui fuient et des utilisateurs qui n'ont jamais consenti à faire partie de la courbe d'apprentissage de quelqu'un.
L'IA n'a pas trahi ces utilisateurs. Ce sont les personnes qui ont mis en production du code non vérifié qui les ont trahis.
Construisez vite. Mais livrez de manière responsable. Les personnes qui utilisent votre application comptent sur vous.
Note de l'auteur : je crois que l'IA est l'avenir du développement logiciel. Ces outils continueront d'évoluer, les pratiques de sécurité mûriront, et beaucoup des problèmes décrits ici seront finalement résolus par une meilleure IA, de meilleurs outils et une meilleure éducation. Mais « finalement » n'aide pas les personnes dont les données sont exposées aujourd'hui. Être optimiste quant à la direction que prend l'IA ne signifie pas que nous devions ignorer ses lacunes actuelles. Au contraire, être honnête sur les limites d'aujourd'hui est la façon la plus rapide d'arriver à un meilleur demain.
Ion Anghel est le fondateur de TEN INVENT, un cabinet de conseil en logiciels et studio produit spécialisé en Laravel, Next.js, AWS et applications propulsées par l'IA. Fort de 20 ans d'expérience dans la tech, il construit des solutions qui fonctionnent — et s'assure qu'elles sont sûres avant leur mise en production.
Publié à l'origine sur teninvent.ro