Les limites du vibe coding : quand ça marche, quand ça casse

Les limites du vibe coding sont les points de rupture où la génération de code par IA cesse d’être un avantage et devient un passif technique. Elles ne se voient pas sur le premier prototype, elles se paient en maintenance. Les articles français qui en parlent n’avancent pourtant presque jamais un chiffre sourcé. Je vends des MVP livrés en vibe coding, raison de plus pour en exposer les ruptures : un fondateur a besoin de savoir quand la limite le concerne.

Quelles sont les 5 limites du vibe coding ?

Les limites du vibe coding sont au nombre de cinq : la sécurité du code généré, l’accumulation de dette technique, l’écart entre productivité perçue et productivité réelle, le passage à l’échelle, et la responsabilité d’un code que personne n’a relu. Le tableau ci-dessous résume chacune, son symptôme et sa parade.

Ces cinq limites partagent une cause commune : la génération de code est devenue si fluide qu’elle masque ce qu’elle empile. Le détail de la méthode de production qui les neutralise est dans le guide du vibe coding.

Le code généré par le vibe coding est-il sûr ?

Le code généré par vibe coding contient une faille de sécurité dans un cas sur deux. 45 % des complétions de code par IA introduisent une vulnérabilité du top 10 OWASP, selon le rapport 2025 GenAI Code Security de Veracode, qui a testé plus de 100 modèles sur 80 tâches de sécurité. Le constat clé du rapport : les modèles plus gros ne font pas significativement mieux que les petits, ce qui en fait un problème systémique, pas un défaut que la prochaine génération de modèles corrigera.

Un test mené en décembre 2025 par la société de sécurité Tenzai chiffre le phénomène. Cinq agents de code (Claude Code, OpenAI Codex, Cursor, Replit, Devin) ont chacun construit les trois mêmes applications de test, soit 15 applications, qui contenaient au total 69 vulnérabilités : environ 45 faibles à moyennes, une douzaine élevées, et environ 6 critiques. Détail parlant : les 5 agents ont tous introduit une faille SSRF sur une fonction d’aperçu de lien qui récupère une URL fournie par l’utilisateur, et aucune des 15 applications n’avait de protection CSRF. En revanche, aucune injection SQL ni faille XSS exploitable n’a été trouvée. L’IA évite les failles génériques bien documentées, et échoue sur tout ce qui dépend de la logique métier.

C’est la distinction que tout fondateur doit intégrer : un code qui fonctionne n’est pas un code sécurisé. 61 % du code produit par les agents passe les tests fonctionnels, mais 10,5 % seulement passe aussi les tests de sécurité, selon le benchmark SUSVIBE publié sur arXiv en décembre 2025, mesuré sur 200 tâches réelles tirées de projets open source. Autrement dit, sur dix fonctionnalités qui marchent, environ huit restent vulnérables.

À grande échelle, le résultat est visible en production. Escape.tech, société française de sécurité, a scanné plus de 5 600 applications vibe-codées publiques en octobre 2025 et y a trouvé plus de 2 000 vulnérabilités, plus de 400 secrets exposés, et 175 fuites de données personnelles, dont des dossiers médicaux, des IBAN et des numéros de téléphone. Toutes en ligne, exploitables en quelques heures.

Le risque ne vient pas que de l’IA. Il vient aussi de la confiance qu’on lui accorde. Les développeurs qui utilisent un assistant IA écrivent du code objectivement moins sécurisé tout en s’estimant plus en sécurité que ceux qui codent sans, d’après une étude de Stanford de 2022 (Perry et al.). C’est l’excès de confiance qui transforme une faille en incident.

Pourquoi un projet vibe-codé devient ingérable après 6 mois ?

Un projet vibe-codé devient ingérable après environ 6 mois de développement actif parce que la dette technique s’accumule par construction. Le mécanisme est documenté : c’est le compromis flux-dette décrit dans l’étude Vibe Coding in Practice (Waseem et al., arXiv, décembre 2025). Quand la génération de code est fluide, l’IA empile des incohérences d’architecture, des failles et une charge de maintenance croissante, parce qu’elle privilégie la production rapide au détriment d’un développement itératif réfléchi.

Le mécanisme technique se mesure. Sur 211 millions de lignes de code analysées entre 2020 et 2024, la fréquence de copier-coller est passée de 8,3 % à 12,3 %, pendant que le refactoring (les lignes déplacées et réorganisées) chutait de 24 % à moins de 10 %, selon le rapport GitClear 2025. Pour la première fois en 2024, le copier-coller a dépassé le code refactorisé. C’est le mécanisme exact du plat de spaghetti : l’IA recopie au lieu de réorganiser, et la duplication s’installe.

Le problème se double d’un effet comportemental. L’IA a tendance à produire trop de code pour rien et à proposer des options sous-optimales. Tant que le projet est jeune, ça passe inaperçu. Au-delà de six mois, sans refactorisation continue, maintenir devient très difficile : une fonction de plusieurs centaines de lignes assemblée à partir de fragments, une logique d’authentification recopiée d’un fichier à l’autre, des requêtes qui s’empilent. Et la personne qui ne maintient pas proprement sa base de code aujourd’hui n’en sera pas plus capable dans un an. La dette ne disparaît pas, elle compose.

Le coût final, c’est le code qu’on finit par réécrire en partie, ou le projet qu’un nouveau développeur veut jeter pour repartir de zéro. La reprise d’un code vibe-codé en dette coûte plus cher que son écriture initiale, le repreneur devant d’abord comprendre ce que personne n’a documenté. La ventilation par palier (audit, renforcement, reconstruction) est dans le guide du prix d’un MVP.

Productivité : le vibe coding tient-il sa promesse ?

Le vibe coding ne rend pas systématiquement plus rapide, et l’écart entre la perception et la réalité est massif. Les développeurs expérimentés mettent 19 % de temps en plus pour terminer une tâche avec l’IA, alors qu’ils anticipaient un gain de 24 % et s’estimaient ensuite 20 % plus rapides, selon l’étude RCT METR de juillet 2025 (16 développeurs, 246 tâches réelles sur des dépôts qu’ils connaissaient). Le marketing de GitHub Copilot annonce +55 % de vélocité depuis 2023 ; une étude indépendante mesure l’inverse sur des experts.

L’étude a une nuance importante, ajoutée par METR en février 2026 : le résultat porte sur des développeurs expérimentés travaillant sur leur propre stack, et un biais de participation est possible. Pour un fondateur non technique qui n’a pas de stack de référence, l’écart est probablement positif. Pour un développeur senior sur son terrain, il est négatif. Le gain dépend du contexte, il n’est jamais automatique.

Le temps gagné à la génération se rattrape souvent au débogage. 45 % des développeurs déclarent que déboguer du code généré par IA prend plus de temps que déboguer le leur, selon le Developer Survey 2025 de Stack Overflow (plus de 49 000 répondants). Et le code IA produit plus de problèmes à corriger : près de 1,7 fois plus de problèmes par demande de fusion (10,83 contre 6,45) et 2,74 fois plus de failles XSS, d’après l’analyse CodeRabbit de décembre 2025 sur 470 demandes de fusion open source. La vitesse de frappe n’est pas la vitesse de livraison.

Le vibe coding survit-il au scaling ?

Le vibe coding survit mal au scaling : un produit vibe-codé tient en démonstration, puis s’effondre quand le produit dépasse ses premiers utilisateurs et que personne ne peut expliquer le code en production. Deux limites se conjuguent à ce moment : le passage à l’échelle technique et la responsabilité d’un code non relu, qui transforment un prototype prometteur en passif technique.

Au passage à l’échelle, l’IA ne voit pas ce qu’un humain repère d’un coup d’œil. Les requêtes N+1 qui font ramer la base dès quelques dizaines d’utilisateurs simultanés, les conditions de course sur les tâches d’arrière-plan, l’absence de cache ou de limitation de débit : aucun de ces problèmes n’apparaît à un agent qui regarde un point de terminaison isolé. Le schéma revient dans les retours de terrain : un produit qui tient en démonstration, puis qui s’effondre dès que le trafic réel arrive, et qui finit réécrit en partie pour atteindre les standards de production. La cause est toujours la même : l’IA optimise localement, jamais globalement.

La seconde limite est la responsabilité. Le vibe coding au sens strict, c’est accepter du code qu’on ne pourrait pas expliquer à un tiers, selon la définition de Simon Willison. Tant que c’est un prototype jetable, aucun problème. Dès que des utilisateurs réels, des paiements ou des données personnelles entrent en jeu, la question devient : qui assume ce code quand il casse à 3 heures du matin ? La responsabilité juridique d’une fuite de données retombe sur l’entreprise qui exploite l’application, pas sur l’outil qui a généré le code. Et 97 % des organisations ayant subi une brèche liée à l’IA en 2025 manquaient de contrôles d’accès appropriés, selon le rapport IBM Cost of a Data Breach 2025. Un code que personne ne comprend est un code que personne ne peut sécuriser.

Faut-il fuir le vibe coding pour autant ?

Non, fuir le vibe coding serait une erreur. Il excelle là où il est le meilleur, et se gère là où il casse. Le vibe coding est imbattable pour prototyper vite et explorer des solutions ; il devient dangereux dès qu’il construit seul un produit de production sans méthode. La limite se gère, elle ne s’évite pas en s’abstenant.

Pour quels usages le vibe coding reste-t-il imbattable ?

Le vibe coding excelle au prototypage et à l’exploration de solutions. Quand tu cherches encore la bonne approche, générer trois versions d’une fonctionnalité en une après-midi pour comparer ce qui tient est un accélérateur réel face au développement manuel. Tester des idées, valider une hypothèse de marché, montrer un produit fonctionnel à des utilisateurs avant d’écrire une ligne de code définitive : c’est là que la fluidité de génération devient un atout au lieu d’un piège. Le coût d’un prototype tombe à quelques heures, et un prototype révèle un marché bien plus vite qu’un cahier des charges.

Comment garder le contrôle du code que l’IA génère ?

Garder le contrôle repose sur quatre principes, pas sur un développeur senior. Le premier est l’œil conceptuel constant : tu n’as pas à relire chaque ligne, mais tu gardes la main sur les choix d’architecture que fait l’IA et tu écartes les options sous-optimales avant qu’elles s’installent. Le deuxième est une architecture à forte abstraction et à bonne isolation, où chaque partie est séparée des autres, de sorte qu’une panne se localise dans un module au lieu de se propager partout. Le troisième est l’usage des tests, que l’IA écrit très vite et bien, pour remonter à la source d’un bug, à condition de les valider plutôt que de leur faire aveuglément confiance. Le quatrième est une relecture humaine ciblée sur les seules parties critiques : authentification, paiement, contrôle d’accès, gestion des secrets, traitement des données personnelles. C’est tout à fait possible de laisser l’IA générer du code non relu partout ailleurs, à condition que l’isolation permette de circonscrire les dégâts. Le choix de la stack pèse aussi : un socle qui garde la sécurité dans le code source plutôt que dans des règles configurées par prompt réduit la surface de risque, comme expliqué sur la page Notre stack.

Un MVP de production peut-il tenir en vibe coding ?

Oui, un MVP de production tient en vibe coding quand la méthode encadre l’outil. La condition n’est pas le niveau d’expérience de qui pilote, c’est la discipline : périmètre figé, architecture isolée et testable, relecture sur le critique, refactorisation avant que la dette compose. Avec Ary, ton MVP est livré en 4 semaines pour 5 000 à 25 000 €, piloté par un fondateur identifiable qui garde cet œil conceptuel sur chaque choix de l’IA, avec un renfort humain ponctuel sur les composants sensibles. Le vibe coding sans méthode produit un prototype qui casse ; le vibe coding avec méthode produit un MVP qui tient.

Si tu veux discuter de ton projet directement avec moi, je suis Parham, fondateur de mon agence MVP à Paris. Pour la méthode de production complète, voir le guide du vibe coding.

Foire aux questions