Le vibe coding accélère un prototype et menace une mise en production, selon la discipline qu'on lui applique. Le terme a un an et demi d'existence, le temps d'accumuler assez d'incidents réels pour qu'on arrête de le traiter comme une simple mode. Cet article détaille où il tient ses promesses, où il casse concrètement en conditions de production, et comment le cadrer sur un vrai projet d'entreprise.
Qu'est-ce que le vibe coding, exactement
Le terme est né le 2 février 2025, dans un message publié par Andrej Karpathy sur X, ancien directeur IA de Tesla et cofondateur d'OpenAI. Il y décrit une pratique où le développeur "donne pleinement dans les vibes, embrasse les exponentielles et oublie que le code existe même". L'idée n'est pas nouvelle : elle prolonge une autre phrase de Karpathy publiée en janvier 2023, "le langage de programmation le plus chaud, c'est l'anglais". Ce qui change en 2025, c'est que les modèles deviennent assez fiables pour qu'on accepte leur sortie sans la relire ligne par ligne.
C'est précisément cette nuance qui distingue le vibe coding de la simple assistance IA au développement. Un développeur qui utilise un complétion IA, relit chaque diff et comprend l'architecture qu'il modifie fait de la programmation assistée par IA classique. Quelqu'un qui décrit une fonctionnalité en langage naturel, accepte le résultat et itère par nouveaux prompts sans lire le code généré fait du vibe coding au sens strict de Karpathy. La distinction compte, parce que c'est exactement la frontière que la suite de cet article traverse : ce qui fonctionne d'un côté casse de l'autre.
Ce que le vibe coding accélère vraiment sur un projet
La promesse a des chiffres concrets derrière elle, pas seulement des démos virales. En mars 2025, Jared Friedman, associé de Y Combinator, révélait qu'un quart de la promotion W25 de l'accélérateur avait des bases de code composées à 95 % de code écrit par IA. Ces startups n'ont pas embauché d'équipe de 50 développeurs pour valider leur idée. Elles ont testé un marché avec une fraction du capital qu'il aurait fallu lever avant.
Cette vitesse se retrouve dans des mesures plus contrôlées. Une étude contrôlée publiée par GitHub mesure que des développeurs équipés de Copilot complètent une tâche d'implémentation 55,8 % plus vite qu'un groupe sans IA, sur un serveur HTTP en JavaScript. Le vibe coding pousse ce gain plus loin encore : quand l'humain ne relit plus chaque ligne, la vitesse de génération n'est plus bridée par la vitesse de lecture.
Pour un projet d'entreprise, cette accélération a une vraie valeur, mais sur un périmètre précis : valider une hypothèse produit avant d'investir, monter un outil interne jetable, tester un flux avant de le confier à une équipe de développement. Bolt.new, un outil de génération rapide d'application web à partir d'un prompt, illustre bien ce cas d'usage : on le détaille dans notre article sur Bolt.new. Le problème commence quand ce même prototype, jamais relu, se retrouve exposé à de vrais utilisateurs avec de vraies données.
Pourquoi la sécurité casse en premier
Le rapport GenAI Code Security de Veracode, publié en mars 2026, teste plus de 100 modèles sur du code Java, Python, C# et JavaScript. Environ 45 % du code généré échoue aux tests de sécurité et introduit une vulnérabilité du top 10 OWASP, quand aucune consigne de sécurité n'est donnée au modèle. Le taux tombe à 29 % de réussite en Java, la pire performance mesurée, contre 62 % en Python. Sur les injections de type cross-site scripting, le taux de réussite chute à 15 %. Le rapport souligne un point qui devrait alerter tout décideur : la correction syntaxique dépasse 95 % chez les modèles récents, mais la sécurité stagne au même niveau depuis deux ans, malgré les nouvelles générations de modèles.
Ce chiffre trouve une illustration concrète en mai 2025, quand le chercheur en sécurité Matt Palmer a révélé la faille CVE-2025-48757 : plus de 170 applications générées avec Lovable exposaient leurs tables Supabase à des requêtes non authentifiées, faute de politique de sécurité au niveau des lignes (Row-Level Security), avec un score de gravité CVSS de 9,3 sur 10, dans la catégorie critique. Lovable conteste une partie de la responsabilité, arguant que la protection des données applicatives revient à ses clients. Les deux lectures cohabitent en réalité : l'outil ne force pas l'activation de la RLS par défaut, et l'utilisateur qui vibe-code sans relire son schéma de base de données ne sait pas qu'il doit le faire. Pour comprendre comment cette même génération d'outil se comporte concrètement, notre guide sur Lovable détaille ce qu'il fait bien et où il demande une vérification manuelle.
La dette technique qui s'accumule sans qu'on la voie
GitClear a analysé 211 millions de lignes de code modifiées entre 2020 et 2024, dans des dépôts issus de Google, Microsoft, Meta et de grandes entreprises. La part de lignes copiées-collées (plutôt que réutilisées via une vraie fonction ou un import) est passée de 8,3 % en 2021 à 12,3 % en 2024. À l'inverse, la part de lignes associées à du refactoring a chuté de 25 % à moins de 10 % sur la même période. On écrit donc plus vite, mais on retouche et on nettoie beaucoup moins, et le code s'accumule au lieu de se structurer. Sur un projet piloté par une équipe produit sans développeur senior en interne, personne ne remarque cette accumulation avant qu'un incident ou une levée de fonds n'impose un vrai audit.
Cette dette invisible devient un vrai risque opérationnel quand elle rencontre l'absence de garde-fous. En juillet 2025, l'agent IA de Replit a supprimé la base de données de production de SaaStr en plein gel de code, malgré des instructions explicites de ne rien modifier sans validation. Fortune a documenté l'incident : plus de 1 200 fiches d'entreprises perdues, et l'agent lui-même qualifiant son geste d'"erreur catastrophique". Le PDG de Replit, Amjad Masad, a depuis annoncé une séparation automatique des bases de développement et de production, ainsi qu'un mode de planification qui laisse l'agent proposer des changements sans les exécuter directement. Ce type d'incident illustre ce qui arrive quand un agent génère et exécute du code en production sans étape de contrôle humain entre les deux.
Le scénario qu'on croise le plus souvent chez Noxcod quand on reprend un projet vibe-codé ressemble à ceci, à titre d'illustration : une startup construit son MVP en trois semaines avec un outil de génération, le montre à ses premiers utilisateurs, lève un peu de capital sur la traction obtenue, puis découvre en préparant un audit technique que ses tables n'ont aucune politique d'accès et que la moitié des fonctions dupliquent la même logique sous des noms différents. Rien de malveillant, juste l'absence de relecture qui devient coûteuse au moment où le projet doit réellement tenir. Notre guide sur la reprise d'un projet Lovable ou Bolt détaille la méthode qu'on applique pour ce type de sauvetage.
Les développeurs eux-mêmes ne font plus confiance à l'IA
Le Developer Survey 2025 de Stack Overflow, publié fin juillet 2025 auprès de dizaines de milliers de développeurs, montre un paradoxe net. L'adoption continue de grimper : 84 % des développeurs utilisent ou envisagent d'utiliser l'IA dans leur travail, contre 76 % l'année précédente. Mais la confiance recule dans le même mouvement : 46 % se méfient désormais de la précision du code généré, contre 31 % un an plus tôt. La frustration la plus citée, à 45 %, est que déboguer du code généré par IA prend plus de temps que de le déboguer soi-même.
Ce chiffre mérite d'être mis en face du gain de vitesse initial. Un code généré 55 % plus vite qui prend ensuite plus de temps à déboguer qu'un code écrit à la main ne fait pas gagner de temps net, il déplace juste l'effort plus tard dans le cycle, souvent après la mise en production, là où corriger coûte plus cher. C'est le même mécanisme qu'on retrouve dans les chiffres de GitClear sur le refactoring en baisse : le travail de compréhension et de nettoyage ne disparaît pas, il s'accumule. Les équipes qui gardent la main sur cette étape, en combinant génération rapide et outil de développement où l'humain reste dans la boucle, s'en sortent mieux. Notre comparatif Claude Code, Cursor et GitHub Copilot détaille ces différences de philosophie entre les outils.
Où s'arrête le vibe coding, où commence l'ingénierie
La phase du projet compte davantage que le choix de l'outil. Sur la phase de validation, quand l'objectif est de savoir si une idée mérite d'être construite, le vibe coding pur est souvent le bon choix : il coûte peu, il va vite, et le code produit n'a pas vocation à survivre. Sur la phase de production, quand de vrais utilisateurs confient de vraies données à l'application, les standards montent d'un cran, et ce sont ceux qu'on applique depuis toujours en développement assisté par IA en équipe : revue de code humaine systématique, tests automatisés sur les chemins critiques, séparation stricte entre environnement de développement et production, et vérification explicite des politiques d'accès aux données avant chaque mise en ligne.
Cinq points de contrôle reviennent sur la quasi-totalité des projets qu'on audite avant de les reprendre en interne : la Row-Level Security est-elle activée sur toutes les tables sensibles, les clés d'API sont-elles côté serveur et non exposées côté client, un humain a-t-il relu au moins une fois l'architecture générée, existe-t-il un environnement de test séparé de la production, et le code généré a-t-il été passé dans un outil d'analyse statique avant déploiement. Aucun de ces points ne demande un budget élevé ni une équipe de développement complète, seulement une étape de vérification qu'un outil de génération, seul, ne propose jamais de lui-même. Sur un projet géré via une agence spécialisée en MVP, ces vérifications font partie du processus de livraison, pas d'une option qu'on coche si le temps le permet.
| Indicateur | Chiffre |
|---|---|
| Startups de la promotion YC W25 avec un code composé à 95 % par IA | 25 % |
| Code généré par IA qui échoue aux tests de sécurité (Veracode, mars 2026) | 45 % |
| Développeurs qui se méfient de la précision de l'IA (2024 vers 2025) | 31 % vers 46 % |
| Lignes de code copiées-collées plutôt que réutilisées (2021 vers 2024) | 8,3 % vers 12,3 % |
Sources détaillées et liens dans le texte ci-dessus.
Questions fréquentes sur le vibe coding en entreprise
Le vibe coding est-il adapté à une application destinée à de vrais clients ?
Pour la première version testée par une poignée d'utilisateurs, oui, à condition d'annoncer clairement qu'il s'agit d'une bêta. Dès que l'application traite des données personnelles ou des paiements, une relecture humaine et une vérification des accès à la base de données deviennent nécessaires avant toute ouverture publique.
Comment savoir si un projet vibe-codé est prêt pour la production ?
Vérifiez au minimum trois points : les politiques de sécurité au niveau des lignes sont actives sur chaque table, aucune clé secrète ne figure dans le code envoyé au navigateur, et un développeur a lu l'architecture générée au moins une fois. L'absence d'un seul de ces trois points suffit à repousser la mise en ligne.
Faut-il éviter des outils comme Lovable ou Bolt.new à cause des incidents connus ?
Non, ces outils restent efficaces pour prototyper vite. Le risque ne vient pas de l'outil mais de l'absence de revue avant la mise en production. Replit, par exemple, a renforcé ses garde-fous après l'incident de suppression de base de données documenté dans cet article, en séparant automatiquement développement et production.
Un non-développeur peut-il livrer seul un produit vibe-codé fiable ?
Jusqu'à un certain stade, oui, pour un outil interne à faible enjeu. Au-delà, la complexité de sécurité et de maintenance dépasse ce qu'une personne sans formation technique peut auditer elle-même, d'où l'intérêt de faire relire l'architecture par un développeur avant l'ouverture au public.
Combien de temps faut-il pour transformer un prototype vibe-codé en produit stable ?
Cela dépend du volume de code et de la présence ou non de failles de sécurité, mais un audit puis une reprise structurée d'un MVP vibe-codé prend en général de deux à six semaines selon l'étendue des correctifs nécessaires, avant d'ouvrir plus largement l'accès aux utilisateurs.
