Les limites du vibe coding (et quand tu as besoin d'un vrai dev)

Un fondateur me contacte. Son app tourne. Interface propre, fonctionnalités en place, trois mois de vibe coding avec Cursor. Il veut ajouter un système de paiement récurrent.

Sauf que chaque modification sur le module de paiement casse l’authentification. L’IA propose un fix. Le fix casse autre chose. Deux heures plus tard, il a cramé toute sa fenêtre de contexte et son app est dans un état pire qu’au départ.

“Je ne comprends plus mon propre projet.”

J’entends ça tout le temps. Jamais au jour 1. Toujours autour du jour 90, quand les limites du vibe coding deviennent très concrètes.

Et les articles que tu trouves en français sur les problèmes du vibe coding ne t’aident pas. Ils listent en vrac : “ça bugge, c’est pas sécurisé, il y a de la dette technique.” OK. Merci. Dire qu’un marteau peut te taper sur les doigts n’a jamais aidé personne à construire une maison.

Le vrai travail, c’est de comprendre pourquoi ça casse. Les hallucinations de code et le slopsquatting ne sont pas le même problème que le biais d’automatisation ou l’illusion de compétence. Les premières sont des limites de l’outil. Les secondes sont des limites du pilote. Et les solutions n’ont rien à voir.

Je construis des MVPs en vibe coding avec Claude Code au quotidien. Je vois ces limites se manifester chez mes clients, parfois chez moi. Ce guide te donne ce que personne n’a encore écrit en français : une cartographie précise de ce qui casse, pourquoi, et surtout à quel moment exact tu as besoin de passer la main à un vrai développeur.

Les 4 limites techniques que l’IA ne résoudra pas toute seule

Les hallucinations de code et le piège du slopsquatting

L’IA ne “se trompe” pas comme un humain se trompe. Un développeur qui fait une erreur sait qu’il a fait un compromis. L’IA, elle, hallucine. Elle génère du code avec une confiance totale, y compris quand ce code est complètement faux.

Trois mécanismes différents, trois niveaux de danger.

1. Les packages fantômes. L’IA te recommande d’installer une bibliothèque. Tu fais confiance, tu lances l’installation. Sauf que cette bibliothèque n’existe pas. L’IA l’a inventée de toutes pièces. Des chercheurs de l’UTSA, Virginia Tech et de l’Université d’Oklahoma ont voulu mesurer l’ampleur du phénomène. Ils ont testé 16 modèles de langage sur 576 000 échantillons de code. Les chiffres sont accablants :

• Les modèles open source hallucinent des noms de bibliothèques dans 21,7% des cas
• Les modèles commerciaux type GPT-4 : 5,2% (un import sur vingt qui pointe vers le vide)
• Au total : 205 474 noms de bibliothèques fantômes inventés par les IA
• 43% de ces hallucinations sont reproductibles : face au même prompt, l’IA invente le même faux nom

Ce dernier point est franchement flippant. Les hackers l’ont compris avant tout le monde. Ils repèrent les noms les plus fréquemment hallucinés et créent de vrais logiciels malveillants portant ces noms exacts sur les plateformes de téléchargement (npm, PyPI). Le terme pour ça : slopsquatting. Tu copies le code de l’IA, tu lances l’installation, tu télécharges un malware sans le savoir. Trend Micro et Cloudsmith ont documenté cette attaque sur la chaîne d’approvisionnement logicielle dès 2025.

2. Les failles de sécurité silencieuses. Le code fonctionne, il fait exactement ce que tu as demandé, mais l’IA a laissé des portes ouvertes. Par exemple : des données accessibles sans mot de passe, un accès administrateur non protégé, ou des informations sensibles écrites en clair dans le code. Pourquoi ? Parce que l’IA optimise pour “ça marche”, pas pour “c’est sécurisé”. Elle ne protège ton app que si tu le lui demandes explicitement. Et toi, fondateur non-technique, tu ne sais pas quoi demander.

3. L’hallucination sémantique. Le code a l’air parfait. Les tests passent. Mais la logique métier est fausse. L’IA a compris ta demande légèrement de travers. Ce genre de bug reste invisible pendant des semaines, jusqu’au jour où un vrai utilisateur tombe dessus et où tu réalises que les calculs sont faux depuis le début.

Le “Context Rot” : quand l’IA perd le fil

Les modèles de langage ont une contrainte physique : la fenêtre de contexte. En gros, c’est la quantité d’information que l’IA peut garder en tête simultanément. Passé une certaine taille, elle commence à oublier le début de la conversation. Et quand elle oublie, elle comble les trous. Mal.

Un développeur sur le forum Weights & Biases a décrit le cercle vicieux mieux que je ne pourrais le faire :

“Quand on vibe code, le modèle tente une approche. Ça rate. On le corrige. Ça rate encore. Une heure plus tard, on a brûlé la moitié de la fenêtre de contexte avec des tentatives ratées. Le modèle n’a appris qu’une chose de cette conversation : il est censé échouer, puis être corrigé, puis échouer à nouveau.”

C’est ce que j’appelle le Context Rot. Au fil d’une session de travail, le contexte se pollue avec des tentatives ratées, des bouts de code abandonnés, des instructions contradictoires. La qualité des suggestions se dégrade. Et toi, tu ne le vois pas, parce que la dégradation est progressive.

Concrètement, dans mes projets, la qualité chute systématiquement au-delà d’une quinzaine de fichiers interconnectés. L’IA modifie un composant sans se souvenir qu’il est utilisé par trois autres. Tu corriges la fonctionnalité A, la fonctionnalité B casse en silence. Bon courage pour trouver d’où vient le problème quand tu n’as pas écrit le code toi-même.

Un développeur front-end a raconté exactement ça sur Medium :

“L’IA n’écrit pas du mauvais code. Elle écrit du code qui a l’air parfait au premier coup d’œil, mais qui s’effondre sous la pression. J’ai expédié une fonctionnalité générée en 90 secondes. Trois jours plus tard, un collègue senior m’a fait remarquer que le code rechargeait toute la page à chaque action utilisateur et envoyait des centaines de requêtes inutiles au serveur. La vitesse est réelle, mais le désordre caché l’est aussi.”

Le paradoxe du test circulaire

Tu as peut-être entendu le conseil : “demande à l’IA d’écrire des tests pour vérifier son code.” Ça semble logique. C’est un piège.

Si l’IA écrit le code ET les tests, elle valide sa propre compréhension du problème. Un cas limite oublié dans le code ? Il sera oublié dans le test aussi. Une interprétation bancale de ta demande ? Le test va confirmer cette interprétation bancale. C’est un test circulaire : l’IA s’auto-évalue et, surprise, elle se donne toujours une bonne note.

Les tests passent au vert. Le fondateur se rassure. Le bug, lui, est déjà en production.

Imagine un étudiant qui rédige son propre examen et sa propre correction. 20/20 à chaque fois. Et ça ne prouve strictement rien.

Le piège se referme quand cette fausse sécurité te pousse à vérifier de moins en moins. Des tests verts, ça rassure. Tu baisses la garde. La boucle de correction entre l’IA et elle-même finit par créer une bulle où tout a l’air solide mais où personne n’a réellement vérifié quoi que ce soit.

L’effondrement de la maintenabilité

Le code IA fonctionne le jour où il est généré. Trois mois plus tard ? C’est une autre histoire.

Le rapport GitClear de février 2026 met des chiffres sur ce que beaucoup de développeurs pressentaient. L’équipe a analysé 211 millions de lignes de code sur cinq ans. Ce qu’ils ont trouvé n’est pas rassurant :

• Le code IA contient 4 fois plus de blocs dupliqués que le code humain
• La proportion de code copié-collé est passée de 8,3% à 12,3% dans les projets analysés
• Le refactoring (restructurer et nettoyer le code) s’est effondré : de 25% des modifications à moins de 10%

Bref, l’IA produit du code. Beaucoup de code. Mais du code répétitif, jamais nettoyé, qui s’accumule comme des couches de peinture les unes sur les autres. Au début, ça va. Après quelques mois, tu veux ajouter un simple formulaire et tu réalises qu’il faut toucher à dix fichiers parce que la même logique est dupliquée partout.

Les données qui existaient déjà sur la qualité du code IA pointaient un problème de bugs et de failles. GitClear révèle un problème plus profond : le code IA pourrit plus vite que le code humain. La base de code enfle, se rigidifie, et chaque nouvelle modification devient un peu plus risquée que la précédente.

Les limites cognitives : le vrai danger, c’est le pilote

Les limites techniques, on peut les contourner avec de la rigueur et de la méthode. Les limites cognitives, c’est une autre paire de manches. Parce que le pilote ne sait pas qu’il est en train de se faire avoir.

Le biais d’automatisation

Tu connais peut-être le concept en aviation : un pilote fait tellement confiance à ses instruments qu’il ignore ce que ses yeux lui disent. En médecine, c’est le médecin qui suit aveuglément le diagnostic de la machine même quand les symptômes du patient racontent une autre histoire. En développement logiciel, c’est exactement pareil. Ça s’appelle le biais d’automatisation.

Le CSET de Georgetown University a mesuré l’effet en 2025. 68% à 73% des échantillons de code générés par IA contenaient des vulnérabilités qui passaient les tests automatiques mais explosaient en conditions réelles. Jusque-là, pas de surprise. Mais voilà le vrai résultat : les développeurs qui utilisaient l’IA écrivaient du code nettement moins sécurisé que ceux qui codaient à la main. Et ils étaient paradoxalement plus convaincus que leur code était sûr.

Le rapport Snyk va dans le même sens et chiffre le déni à grande échelle : 56,4% des professionnels admettent que les suggestions de code IA non sécurisées sont “fréquentes”. Et malgré ça, 80% des équipes continuent de faire confiance aux outils les yeux fermés.

Le mécanisme est simple. L’interface est fluide. Le code compile. Les tests passent au vert. Ton cerveau fait le raccourci : “ça a l’air de marcher, donc ça marche.” Sauf que quand le code gère des données utilisateurs ou des paiements, ce raccourci peut te coûter très cher.

David Mytton, fondateur d’Arcjet et spécialiste de la sécurité applicative, a tiré la sonnette d’alarme début 2026 sur les risques d’incidents majeurs liés aux applications vibe-codées en production. Son constat est limpide : le problème, ce n’est pas que l’IA génère du mauvais code. C’est que personne ne prend le temps de vérifier ce qu’elle génère.

L’illusion de compétence

Le fondateur a écrit les prompts. L’IA a généré le code. L’app fonctionne. Alors il se dit : “je suis développeur, finalement.”

Non. L’écart entre savoir décrire ce qu’on veut et savoir évaluer ce qu’on obtient, c’est un gouffre. Et le vibe coding est pile au milieu de ce gouffre : il donne assez de résultat pour que tu te sentes en contrôle, mais pas assez de visibilité pour que tu mesures ce qui manque.

Ce témoignage sur Reddit r/vibecoding résume tout :

“Mon CTO a décidé de ‘vibe coder’ lui-même la refonte du système la nuit parce qu’il trouvait l’équipe trop lente. Il a pondu un truc énorme sans le faire relire. Quand on lui a parlé de la maintenance, il a littéralement répondu : ‘Je ne veux pas maintenir ça’. Il dit que ça marche parce que les pages s’affichent, mais il a ignoré tout ce qui se passe côté utilisateur. C’est un cauchemar pour l’équipe.”

Ce n’est pas un cas isolé. C’est systémique. Et l’illusion de compétence est le piège le plus coûteux de tous, parce qu’elle retarde le moment où tu décides de chercher de l’aide. Plus tu attends, plus la facture de reprise grimpe.

Les garde-fous qui changent la donne

Lister les problèmes sans donner de solutions, c’est de l’alarmisme. Voici ce que je mets en place concrètement avec mes clients. Aucun de ces garde-fous n’est compliqué. La plupart prennent quelques secondes par prompt.

Contre le slopsquatting : vérifie chaque bibliothèque que tu ne reconnais pas. Une recherche rapide sur Google avec le nom exact, 10 secondes chrono. Si la bibliothèque n’existe nulle part, l’IA l’a inventée. Supprime la ligne et reformule ton prompt.

Contre le Context Rot : travaille par sessions courtes. Une fonctionnalité par session, un fichier à la fois. Dès que les réponses de l’IA commencent à tourner en rond, ouvre une nouvelle conversation avec un contexte propre. Et avant chaque session, décris en trois lignes ce que tu veux obtenir pour cadrer l’IA.

Contre les tests circulaires : ne demande jamais à l’IA de tester ce qu’elle vient de coder dans la même conversation. Écris toi-même ce qui doit être vérifié, en français, pas en code. Par exemple : “quand l’utilisateur clique deux fois sur Payer, il ne doit pas être débité deux fois.” Pour tout ce qui touche à la connexion utilisateur ou aux paiements, utilise des services spécialisés et éprouvés (Stripe, Auth.js, Supabase) au lieu de laisser l’IA les coder elle-même.

Contre la dette de code : impose des conventions dès le premier prompt. Un fichier par fonctionnalité. Des noms clairs. L’IA suit les règles si tu les lui donnes. Sans règles, elle improvise, et chaque improvisation ajoute une couche de complexité.

Contre le biais d’automatisation : pars du principe inverse. Le code est cassé tant que tu n’as pas prouvé qu’il marche. Teste chaque fonctionnalité toi-même comme un vrai utilisateur, avec des vrais scénarios, avant de passer à la suivante.

Le détail des prompts et du workflow complet est dans le guide comment faire du vibe coding.

Quand tu as (vraiment) besoin d’un développeur

Les signaux qui ne trompent pas

Le vibe coding ne casse pas d’un coup. La dégradation est lente, ce qui la rend traître. Voici les signaux que je guette quand un client me contacte après avoir vibe-codé son MVP.

• Tu corriges plus que tu ne crées. Tu ouvres ton outil le matin et tu réalises que tu passes plus de temps à demander des corrections de bugs qu’à ajouter de nouvelles fonctionnalités. C’est le symptôme le plus fiable d’un Context Rot avancé.
• Effet château de cartes. Tu modifies la page de profil et le formulaire d’inscription casse. L’IA ne sait pas t’expliquer pourquoi, sauf en proposant de réécrire cinq fichiers. Si tu en es là, ton code a perdu toute cohérence interne.
• L’app atteint un plafond de charge. Dix testeurs, ça tourne nickel. Cent utilisateurs en simultané, ça rame ou ça plante. L’IA génère du code qui fonctionne, pas du code rapide. L’optimisation, c’est un métier.
• L’IA bloque sur le code existant. Le vibe coding brille sur un projet neuf, une page blanche. Dès qu’il faut modifier ou intégrer du code dans un système existant avec des contraintes métier et des conventions établies, l’IA tourne en boucle. Elle ne comprend pas les règles implicites d’un projet qui a déjà un historique.

Un dev sur Reddit r/webdev résume la trajectoire mieux que moi :

“Si vous n’avez pas d’expérience en ingénierie logicielle, le vibe coding vous amènera jusqu’au prototype. Après ça, laissez faire les devs. Sinon, vous allez payer un développeur pour réparer les erreurs exponentiellement complexes que vous avez demandé à l’IA de corriger, jusqu’au point où le dev vous dira qu’il faut tout réécrire depuis zéro.”

Ce qu’un dev apporte (et que l’IA ne remplacera pas)

Quand je reprends un projet vibe-codé, je ne “code” pas au sens où la plupart des fondateurs l’imaginent. Voilà ce qu’un dev apporte concrètement :

• L’architecture. Décider comment les différentes parties de l’app communiquent entre elles, comment les données circulent, comment le système tient la charge. L’IA sait coder des fichiers. Un dev construit un système.
• La sécurité proactive. Pas la sécurité qu’on demande à l’IA d’ajouter : celle qu’on va chercher soi-même. Les failles silencieuses, les données exposées sans qu’on le sache. C’est un travail défensif que l’IA ne sait pas initier seule.
• Le diagnostic de performance. Quand l’app rame, le problème n’est presque jamais “il faut plus de serveur” mais un souci dans la façon dont le code interroge la base de données.
• L’archéologie de code. Reprendre un projet que personne ne comprend, le cartographier, décider ce qu’on sauve et ce qu’on jette.

Un dev coûte 2 à 3 fois plus cher s’il doit déterrer l’architecture d’un code IA non documenté plutôt que reprendre un prototype propre.

Le bon timing

L’erreur la plus coûteuse que je vois, c’est d’embaucher quand tout est déjà cassé. À ce stade, le dev passe des jours à comprendre un système que personne n’a conçu intentionnellement avant même de pouvoir toucher à quoi que ce soit. La facture explose.

Le bon moment, c’est quand ton MVP a prouvé sa traction. Tu as des utilisateurs. Tu as du feedback. Tu sais ce qui doit scaler. Le dev reprend un prototype qui a déjà fait ses preuves et il le transforme en quelque chose de solide. C’est un ordre de grandeur plus efficace.

Pour les seuils de revenus et la structuration de l’équipe technique, j’ai détaillé tout ça dans le guide vibe coding pour startups. Retiens le principe : embauche au moment de la traction, pas au moment du crash.

Foire aux questions

Quand le vibe coding ne suffit-il plus ?

Surveille quatre choses. Est-ce que tu passes plus de temps à corriger qu’à créer ? Est-ce que modifier une fonctionnalité en casse une autre ? Est-ce que l’app rame dès qu’il y a du monde ? Est-ce que l’IA tourne en boucle quand tu veux toucher à du code existant ? Un seul oui et il est temps de faire appel à un développeur professionnel.

Les hallucinations du code généré par IA sont-elles fréquentes ?

Oui, et elles sont mesurées. L’étude UTSA/Virginia Tech/Oklahoma sur 576 000 échantillons chiffre le taux d’hallucination de packages à 21,7% pour les modèles open source, 5,2% pour les commerciaux. 205 474 noms de packages fantômes ont été inventés. Le pire : 43% sont reproductibles, ce qui en fait une cible idéale pour les hackers via le slopsquatting. Les hallucinations sémantiques (le code compile, mais il fait la mauvaise chose) sont encore plus dures à repérer.

Faut-il un développeur pour mettre en production une app vibe-codée ?

Pour un prototype ou un test de marché, non. Pour de la production avec de vrais utilisateurs, des paiements ou des données sensibles, oui dans la grande majorité des cas. Le vibe coding est redoutable en exploration. Mais la mise en production demande de l’architecture, de l’audit sécurité, de l’optimisation, et la capacité à maintenir le système sur la durée. L’idéal : l’approche séquentielle - vibe coding pour explorer, dev classique pour construire.

Comment détecter les limites du vibe coding dans son propre projet ?

Le premier indicateur, c’est le ratio entre tes prompts de création et tes prompts de correction. Si plus de la moitié de tes échanges avec l’IA sont des demandes de fix, c’est que la complexité a dépassé ce qu’elle gère. Un autre test : demande-lui d’expliquer l’architecture globale de ton projet. Si sa réponse est vague ou incohérente, le Context Rot a fait son travail.

Le vibe coding est-il dangereux pour la sécurité ?

Pas dangereux, mais non sécurisé par défaut. L’étude du CSET de Georgetown chiffre ça : 68 à 73% du code IA contient des vulnérabilités que les tests standard ne détectent pas. L’IA optimise pour la fonctionnalité. La sécurité, elle ne l’ajoute que si tu la demandes explicitement. Pour les parties critiques, utilise des services tiers éprouvés et fais auditer le code avant de déployer.