Le terme est arrivé le 2 février 2025 dans un tweet d'Andrej Karpathy. En quelques mois, "vibe coding" est devenu un mot-clé qu'on voit dans les threads LinkedIn, dans les démos sur YouTube, dans les CV. En novembre 2025, le dictionnaire Collins l'a même désigné mot de l'année. La définition d'origine, celle de Karpathy : "fully give in to the vibes, embrace exponentials, and forget that the code even exists". En clair, tu décris ce que tu veux, l'IA code, tu acceptes presque sans regarder.
La scène est devenue banale. Quelqu'un ouvre Cursor ou Claude Code, demande "fais-moi une app de gestion de tâches en Next.js", et l'IA sort 2000 lignes en cinq minutes. Au test, ça marche à moitié. Il faut modifier un détail, impossible de trouver où. Le projet finit à la poubelle, sans qu'on comprenne pourquoi.
La discussion publique est polarisée. D'un côté, les enthousiastes qui annoncent la fin du dev classique et prédisent que dans deux ans plus personne n'écrira de code à la main. De l'autre, les sceptiques qui dénoncent une mode dangereuse, productrice de code de qualité variable, formant une génération de devs incapables de lire ce qu'ils livrent.
Cet article te donne une vue posée : ce que le vibe coding recouvre exactement, ce qu'il sait faire et ce qu'il ne sait pas faire, où il a sa place dans une pratique sérieuse, et où il devient un piège. Pas de hype, pas de panique. Juste le point en 2026.
Le problème : tout le monde parle de vibe coding sans le définir pareil
Le mot recouvre au moins trois pratiques différentes, qu'on confond systématiquement dans les débats.
Définition 1, la version Karpathy : tu pilotes une IA en langage naturel, tu ne lis pas le code, tu testes le résultat, tu corriges par "regénère mais avec X". C'est du prototypage rapide, ou du code jetable. C'est ce que faisait Karpathy quand il a inventé le terme, se fabriquer des petits outils perso le weekend.
Définition 2, la version product : un non-tech qui construit une appli avec Lovable, v0, Bolt, ou Cursor. Le but n'est pas d'apprendre à coder, c'est de produire un livrable sans passer par un dev. Cette pratique a explosé en 2025 et 2026, elle est utile pour valider une idée vite, et terrible pour ceux qui essaient de la mettre en prod sans comprendre ce qui a été généré.
Définition 3, la version pro : un dev expérimenté qui utilise un agent IA (Claude Code, Cursor ou Windsurf en mode agent) pour accélérer son travail, en relisant et validant chaque modification. Au sens strict ce n'est plus du vibe coding, parce que le dev contrôle ce qui rentre dans le repo. Mais le terme est souvent employé par confusion.
Quand on parle de "vibe coding", la première chose à faire est de demander de laquelle de ces trois pratiques on parle. Sans cette précision, le débat reste flou et chacun défend une position sur un objet différent de celui de son interlocuteur.
Le principe : où le vibe coding tient la route
Le vibe coding au sens strict (tu pilotes l'IA, tu ne relis pas en profondeur) a un domaine d'efficacité réel, mais limité. Voici les cas où il livre sans casse.
Le prototypage et la validation d'idée
Tu veux tester si une idée de produit accroche avant de l'engineerer sérieusement. Tu génères un prototype en deux jours, tu le mets devant trois utilisateurs cibles, tu apprends. Si l'idée part à la poubelle, tu n'as pas perdu deux semaines à coder proprement quelque chose qui ne marche pas. Si elle accroche, tu refais sérieusement, avec architecture et tests.
Ce cas est légitime, c'est même un excellent usage. Le risque commence quand le prototype passe en production sans réécriture, parce que "il marche".
Les outils personnels et les scripts jetables
Un script qui scrape une page pour un usage perso, un outil de tâches qui ne tourne que sur ta machine, un petit dashboard interne pour une équipe de cinq personnes. Tout ce qui n'est pas critique, ne touche pas de données sensibles, et dont le coût d'échec est faible.
Le vibe coding excelle ici parce que le ratio temps gagné sur risque est très favorable. Une heure de prompt vaut mieux qu'une journée de code propre pour ce niveau d'enjeu.
L'apprentissage exploratoire
Tu veux comprendre comment une techno marche, tu demandes à l'IA un exemple, tu le lis, tu modifies, tu refais. C'est de la pédagogie par l'exemple, accélérée par l'IA, à condition de prendre le temps de comprendre ce qui sort. Si tu te contentes de copier sans lire, tu n'apprends rien.
L'écriture de code répétitif
Migrations de schémas SQL, configuration de webhooks, écriture de DTO, classes mappers, fichiers de seed. Tout le code ennuyeux mais standard. L'IA en génère bien plus vite qu'un humain, et les erreurs sont faciles à détecter.
C'est plutôt de l'assistance ciblée que du vibe coding au sens strict, mais c'est le cas d'usage où l'IA donne le plus de rendement immédiat sans risque majeur.
Où le vibe coding craque
Les bases de code longues à maintenir
Une appli qui doit vivre trois ans, évoluer, accueillir cinq devs successifs. Si elle a été vibe-codée, personne ne comprend les choix d'architecture, parce qu'il n'y en a pas eu : l'IA a improvisé localement à chaque fonctionnalité. Au bout de six mois, le code est ingérable.
Une architecture cohérente demande des décisions humaines explicites, prises avec une vision d'ensemble. C'est exactement le contraire d'une improvisation locale répétée à chaque écran.
La sécurité
L'IA génère du code qui marche, pas forcément du code sûr. Failles XSS, injections SQL, secrets en dur, permissions trop larges, validation absente. Plusieurs incidents publics en 2025 et 2026 ont montré des applis vibe-codées exposer des données sensibles parce que personne n'avait relu la couche d'authentification.
Dès que tu manipules de la donnée utilisateur, de l'authentification, du paiement, le vibe coding au sens strict est dangereux. Un humain compétent doit relire et valider. Le sujet rejoint directement les cinq failles de sécurité qu'on retrouve dans presque tous les projets juniors, celles qu'un scanner repère en quelques minutes.
Le débogage complexe
Tu as vibe-codé ton appli. Un bug apparaît. Tu demandes à l'IA de le corriger. L'IA modifie cinq endroits, le bug initial disparaît, mais trois nouveaux apparaissent ailleurs. Tu retombes dans une boucle où chaque correction casse autre chose.
Pour déboguer efficacement, il faut comprendre le code. Si tu ne l'as jamais lu, tu es spectateur de tes propres bugs, et c'est ce qui pousse beaucoup de vibe coders à finir par tout réécrire à la main.
L'apprentissage pur (le paradoxe)
Si tu débutes et que tu vibe-codes dès le départ, tu n'apprends pas à coder. Tu apprends à prompter une IA pour qu'elle code à ta place. Ces deux compétences sont différentes, et seule la première te rend autonome quand l'outil change ou que le bug devient tordu.
Le piège que l'article sur le syndrome du tutoriel infini identifie sur les cours, le vibe coding le reproduit sur le code : sentiment de productivité immédiate, absence d'apprentissage durable.
La pratique saine en 2026 : assistance IA, pas vibe coding
La plupart des devs sérieux qui ont adopté l'IA dans leur workflow ne font pas du vibe coding au sens strict. Ils font de l'assistance IA contrôlée. La différence tient en quatre principes.
Tu lis toujours ce que l'IA génère. Avant d'accepter une modification, tu regardes le diff. Tu te poses la question "qu'est-ce qui change, est-ce que je peux le justifier ?". Si tu ne sais pas pourquoi le code est ainsi, tu demandes à l'IA d'expliquer, ou tu réécris.
Tu pilotes l'architecture. Les décisions d'architecture (organisation du code, choix de design pattern, structure de la base) restent des décisions humaines. Tu peux demander à l'IA des avis, mais le choix final t'appartient, parce que tu vas vivre avec.
Tu testes activement. Tu écris, ou tu fais écrire, des tests qui couvrent le comportement attendu, et tu les lances à chaque modification. C'est exactement ce que couvre l'article sur les tests fiables, et ça devient encore plus important quand une partie du code est générée par une machine que tu ne relis pas ligne à ligne.
Tu sais réécrire à la main. Si demain l'IA ne fonctionne plus, ou si tu changes d'outil, tu dois pouvoir continuer à livrer. Tu maintiens cette compétence en codant régulièrement à la main des parties non triviales, même quand tu pourrais déléguer.
Fait notable, Karpathy lui-même a pris ses distances avec le mot qu'il a lancé. Début 2026, il a proposé de renommer cette pratique sérieuse "agentic engineering" : tu n'écris plus le code directement la plupart du temps, tu orchestres des agents et tu fais le contrôle. Le glissement de vocabulaire dit bien où va la profession.
Pièges classiques à éviter
Mettre un prototype vibe-codé en production
Le prototype marche, tu te dis "pourquoi réécrire, je le mets en prod direct". Trois mois plus tard, première fuite de données, et le constat tombe : le code n'a jamais été pensé pour la prod.
Un prototype valide une idée. Une appli de production demande une autre rigueur : tests, sécurité, observabilité, gestion d'erreur, performance. Ce sont deux objets différents, qui ne se construisent pas pareil.
Croire que le vibe coding remplace l'apprentissage
"Je n'ai plus besoin d'apprendre les bases, l'IA fait tout." Sauf que pour piloter l'IA correctement, il faut savoir lire son output et le critiquer. Sans bases, tu ne peux ni juger ni corriger, donc tu acceptes tout ce qui sort, et tu produis du code de mauvaise qualité.
Les meilleurs utilisateurs d'IA sont aussi les meilleurs devs. Ce n'est pas un hasard, c'est mécanique : la compétence humaine se transforme en capacité de jugement face à l'IA.
Confondre vitesse de génération et productivité
L'IA génère 2000 lignes en cinq minutes, tu te crois cent fois plus productif. Sauf qu'il faut compter le temps de relire, tester, débugger, corriger les erreurs subtiles, réécrire les parties mal pensées. Au bilan honnête, tu gagnes peut-être 20 à 40% sur le code routinier, et il arrive que tu perdes du temps sur le code complexe.
La productivité se mesure sur la valeur livrée, jamais sur le nombre de lignes générées.
Vibe-coder du code dont tu seras responsable
En entreprise, tu es responsable du code que tu mergues. Si une faille apparaît parce que tu as accepté un patch IA sans le lire, tu ne peux pas dire "c'est l'IA". Le code que tu signes est ton code.
Cette règle simple devrait suffire à freiner les usages les plus dangereux. Tu ne mets dans le repo que ce que tu serais capable d'expliquer à un collègue en revue.
Mépriser ou idolâtrer l'outil
Deux postures stériles. "L'IA c'est nul, je code mieux à la main" te prive d'un levier réel de productivité. "L'IA est magique, je ne code plus à la main" te prépare des problèmes graves à moyen terme.
Le bon réflexe est d'évaluer outil par outil, cas par cas. Quand l'IA aide, tu l'utilises. Quand elle te ralentit ou te met en danger, tu reprends la main. C'est de l'artisanat appliqué à un nouveau levier.
Pour aller plus loin
Le vibe coding s'inscrit dans le contexte plus large de l'assistance IA au développement. L'article sur les agents IA en 2026 couvre le paysage global, et le décryptage du dossier .claude montre comment un workflow IA mature s'organise dans un projet réel. Si le sujet qui t'inquiète, c'est l'emploi, l'analyse sur le vibecoding et le poste de dev junior regarde les chiffres de près.
Côté formation, pour exploiter l'IA de manière saine dans ton développement, la formation Prompt Engineering API LLM donne les bases pour interagir avec ces outils sans subir leurs limites. La formation Création d'une application IA avec Python s'adresse à ceux qui veulent construire eux-mêmes les agents qu'ils utiliseront.
