Vibe coding : pourquoi c'est surestimé en 2026

« Vibe coding » : c'est le terme consacré pour décrire le workflow où tu balances tes idées en langage naturel à un agent (Claude Code, Cursor, Lovable, v0), tu regardes le résultat, tu ajustes en temps réel, tu ne lis plus vraiment le code. Tu codes à l'instinct, au feeling, à la « vibe ». Tous les influenceurs dev m'ont expliqué que c'était l'avenir. Après 4 mois à essayer honnêtement, je pense exactement l'inverse : le vibe coding est un piège pour les devs moyens, et il produit du code qui s'écroule dans 6 mois. Voici mon argumentation, avec des chiffres, et ce que j'utilise à la place.

Ce qu'on appelle « vibe coding »

Le vibe coding, dans sa version la plus pure, ressemble à ça :

> « Fais-moi une app de todo avec auth OAuth, une base de données, un design sombre, et deploy sur Vercel. »

L'agent génère 40 fichiers, tu n'en lis aucun, tu testes l'app dans le navigateur, tu dis « non c'est pas ça, mets plutôt un thème rose pastel et ajoute les sous-tâches », il régénère, et ainsi de suite. Le code est produit, jamais compris, jamais audité. C'est de l'« anti-craftmanship » assumé — on ne cherche plus à comprendre le code, seulement à ressentir s'il correspond à ce qu'on voulait.

Les défenseurs disent : « mais ça marche ! » Oui, dans les deux premières semaines. Non, après.

Mon test honnête : 4 projets en vibe coding

J'ai pris 4 projets persos que j'aurais normalement codés manuellement, et je les ai faits en vibe coding pur sur 4 mois. Voici ce qui s'est passé.

Projet 1 : un bot Telegram météo (2 semaines de dev, 4 mois de suivi)

Vibe coded en 3h. Marche parfaitement au déploiement. Au bout de 3 semaines, l'API météo change son format de réponse. Le bot crashe. Je rouvre le code. C'est illisible : 12 fonctions, aucune nommée clairement, 4 fichiers de config différents, un mélange de dotenv et de variables hardcodées. Je passe 2 heures à comprendre ce que j'ai moi-même (avec Claude) produit. J'aurais mis 3h à coder proprement + 10 minutes à fixer. Temps total vibe : 5h. Temps total propre (estimé) : 3h10.

Projet 2 : un dashboard analytics (1 mois de dev, 3 mois de suivi)

Vibe coded en 2 jours. Au bout de 6 semaines, un utilisateur signale un bug : les nombres en pourcentage sont tronqués. Je rouvre le code : il y a 3 endroits différents où l'affichage des pourcentages est fait, chacun avec une logique légèrement différente, aucune factorisée. Je passe 4 heures à harmoniser. J'aurais factorisé dès le départ en mode classique.

Projet 3 : un blog statique avec CMS (3 semaines, 4 mois de suivi)

Vibe coded. Au bout de 2 mois, je veux ajouter une fonctionnalité (tags). Je me rends compte que le schéma de données initial ne prévoit pas de relation many-to-many. L'agent a choisi un schéma simple qui marche pour le MVP mais pas pour l'évolution. Migration complète requise. 6 heures de travail + risque de perdre des données.

Projet 4 : un outil CLI de backup (1 semaine, 3 mois de suivi)

Vibe coded en 4 heures. Le code est relativement propre (tâche simple). Au bout de 3 mois, je trouve une faille de sécurité (le tool appelait subprocess.run avec shell=True sur des inputs utilisateurs). Aurait été caught par une review humaine. Là, le vibe coding l'a ignoré.

Le vrai coût : la dette technique invisible

Sur mes 4 projets, voici le bilan temps total (dev + maintenance) :

Le vibe coding me fait perdre 26% de temps total quand on regarde le cycle de vie complet du projet. Sur les 2 premières semaines, on me gagne 40-50%. Sur 6 mois, je perds.

Pourquoi tout le monde dit le contraire

Trois raisons :

1. 1.Les démos sont toujours sur 2 semaines max. Les influenceurs montrent « j'ai créé cette app en 2h ». Ils ne montrent pas « et voici ce qu'elle est devenue 3 mois plus tard ». Ce qui est normal — leur boulot c'est de faire des démos, pas de maintenir.
2. 2.Le biais de survivance. Les projets vibe codés qui plantent au bout de 2 mois, on n'en entend jamais parler. Seuls ceux qui survivent (souvent parce qu'ils sont rejetés ou très simples) font du bruit.
3. 3.Les devs moyens préfèrent le feeling au craft. Comprendre le code, c'est un effort intellectuel. Ressentir si « ça marche », c'est facile. Le vibe coding flatte la paresse — et c'est probablement ce qui le rend si populaire.

Ce que je fais à la place (depuis 2 mois)

J'appelle ça la Ralph Loop disciplinée. Voici les règles :

Règle 1 : lire chaque ligne de ce que l'agent produit

Oui, chaque ligne. Pas « survoler ». Lire. Ça prend 20-40% de temps en plus, mais ça attrape 80% des bugs qui causent les dettes techniques décrites plus haut.

Règle 2 : refuser de déployer du code que tu ne saurais pas refaire à la main

Si tu ne comprends pas ce que fait le code (même en gros), tu es le propriétaire d'une dette. Demande une explication à l'agent, relis, comprends. Si tu ne peux pas, refuse et demande une version plus simple.

Règle 3 : toujours commiter en petites unités lisibles

Un vibe coding produit un commit monstre de 40 fichiers. Je refuse. Je casse en 8-10 commits qui racontent une histoire — « add schema », « add migration », « add query layer », « add API route », etc. C'est de la discipline classique, ça prend 10 minutes de plus, ça vaut chaque minute.

Règle 4 : jamais de code IA sur un truc que je ne pourrais pas réécrire en 1h

Si je ne saurais pas coder le module à la main en 1h, je ne laisse pas l'IA le générer sans supervision. La supervision, c'est : je lis, je comprends, je demande des clarifications, je refactor.

Ce qu'il faut retenir

1. 1.Le vibe coding marche sur les démos de 2 semaines et s'écroule sur les projets de 6 mois.
2. 2.Mon delta mesuré : -40% en phase de dev, +26% sur le cycle de vie complet.
3. 3.Les 3 vrais coûts cachés : illisibilité, choix d'architecture pauvres, failles de sécurité subtiles.
4. 4.La Ralph Loop disciplinée (lire chaque ligne, refuser l'incompréhensible, commiter petit) remplace le vibe coding avec un meilleur ROI.
5. 5.Le vibe coding est une solution de confort pour devs moyens — pas une révolution méthodologique.

Pour la discipline complète Ralph Loop qui me permet d'aller vite sans sacrifier la compréhension, j'ai écrit un livre entier :

La Boucle Ralph

Guide Pratique du Coding Autonome par IA.

Découvrir →