Une démonstration filmée, un écran partagé, une application qui tourne à l'issue d'un après-midi. La séquence est devenue un argument de vente. Elle vend une promesse que les mots eux-mêmes n'ont jamais portée : le terme « vibe coding » désignait à l'origine un prototype jetable, pas un logiciel livrable.
Le décalage entre ce qu'un mot voulait dire et ce qu'on lui fait dire mérite qu'on s'y arrête, parce que des décisions d'investissement et des feuilles de route produit reposent désormais dessus. Quand un dirigeant entend « application en un jour », il entend un actif. Ce qu'il regarde, le plus souvent, est une maquette qui fonctionne tant qu'on ne s'écarte pas du scénario prévu.
Ce que Karpathy a réellement écrit
Le mot a une date de naissance précise. Le 2 février 2025, Andrej Karpathy — co-fondateur d'OpenAI, ancien responsable de l'IA chez Tesla — publie sur X une définition qui tient en quelques lignes.
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's not really coding — I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works.
— Andrej Karpathy — Co-fondateur d'OpenAI — 2 février 2025
« It mostly works » — ça marche à peu près. La nuance est dans le tweet d'origine, et elle est entière. Karpathy décrit un mode opératoire où l'on cesse de relire ce que la machine produit, où l'on copie-colle les erreurs dans le modèle jusqu'à ce que l'écran affiche le résultat attendu. Il ne parle pas d'une méthode de production. Il parle d'un projet du week-end, d'une expérimentation où le code devient un déchet acceptable parce que l'enjeu est nul.
Simon Willison, développeur et observateur attentif de l'écosystème, a fixé la définition canonique le 19 mars 2025. Le vibe coding, écrit-il, c'est « construire un logiciel avec un LLM sans relire le code qu'il écrit ». La précision qui suit a été largement ignorée par le marketing qui s'est emparé du terme.
Si un LLM a écrit chaque ligne de votre code mais que vous l'avez relue, testée et entièrement comprise, ce n'est pas du vibe coding — c'est utiliser un LLM comme assistant de frappe.
— Simon Willison — Développeur, créateur de Datasette — 19 mars 2025
La frontière tracée par Willison est nette. Dès qu'il y a relecture, test et compréhension, on quitte le vibe coding pour entrer dans l'ingénierie assistée. Et il ajoute une mise en garde que personne ne reprend dans les démonstrations commerciales : « faire du vibe coding jusqu'à une base de code de production est clairement une très mauvaise idée ».
Du concept au produit de consommation
Le mot a connu une fortune que son auteur n'avait pas anticipée. Merriam-Webster l'a ajouté à son dictionnaire en mars 2025. Collins l'a sacré mot de l'année 2025 le 6 novembre. En neuf mois, une expression lancée à la volée est devenue un objet culturel — et un argument commercial.
C'est dans ce passage que s'opère le glissement. Karpathy décrivait l'abandon volontaire du contrôle sur le code ; le discours de vente a retenu la vitesse et oublié l'abandon. « Vibe coding » est devenu synonyme de « rapide », puis de « rapide et fini ». La distorsion sémantique est documentée : le concept d'origine était un prototype assumé comme jetable, sans relecture ; sa version marketing promet un produit en une journée. Les deux propositions n'ont en commun que les outils.
L'écart se mesure le plus simplement avec la table de la maturité d'un logiciel.
| Dimension | Prototype | Produit |
|---|---|---|
| Chemin couvert | Le scénario heureux, prévu | Tous les cas, y compris les erreurs |
| Données | Jeu d'exemple maîtrisé | Données réelles, sales, imprévisibles |
| Charge | Un utilisateur, l'auteur | Trafic concurrent, pics, abus |
| Sécurité | Hors sujet | Authentification, secrets, surface d'attaque |
| Pérennité | Jetable | Maintenu, corrigé, repris par d'autres |
| Temps | Heures | Semaines à mois |
Une démonstration « en un jour » coche la première colonne. Elle prouve qu'un parcours fonctionne quand tout se passe comme prévu. Elle ne dit rien de ce qui arrive quand un utilisateur entre une adresse mal formée, quand mille personnes arrivent en même temps, ou quand quelqu'un cherche délibérément la faille. Ces questions appartiennent à la seconde colonne, et c'est là que se joue le vrai travail — un sujet que Pourquoi une vraie application prend des semaines explore en détail.
L'exception qui ne fait pas la règle
Il existe un cas que tout le monde cite, et il mérite d'être raconté correctement, parce qu'on le brandit souvent comme une preuve. Pieter Levels, développeur indépendant connu sous le pseudonyme @levelsio, a prototypé un jeu de vol — fly.pieter.com — en environ trois heures sur l'éditeur Cursor, sans expérience préalable en développement de jeux. Le résultat est passé de zéro à un million de dollars de revenu annuel récurrent en dix-sept jours, soit près de 87 000 dollars de revenu mensuel.
L'histoire est vraie. Elle est aussi exceptionnelle, au sens statistique du terme. Le média 404 Media, qui l'a documentée, a titré son enquête sans ambiguïté : « Yours Probably Won't » — le vôtre n'y arrivera probablement pas. Le titre est l'analyse.
Levels réunissait des conditions que la démonstration moyenne ignore : une audience déjà constituée de centaines de milliers d'abonnés, une décennie d'expérience dans le lancement de produits, et un format — un jeu gratuit et viral — où l'imperfection technique ne coûte rien à l'usage. Et la suite a rappelé la seconde colonne du tableau. Quand il a ajouté un micro-paiement au jeu, l'infrastructure a encaissé une attaque par déni de service d'environ 120 millions de requêtes, neutralisée par Cloudflare. Le moment où le prototype a touché à l'argent réel est exactement le moment où les 90 % difficiles ont resurgi.
Quand l'auteur relativise sa propre formule
Un détail récent éclaire tout le reste. En février 2026, Karpathy est revenu sur son tweet fondateur pour le qualifier de « throwaway » — une formule lancée sans intention de fonder une méthode. Il n'a jamais promis un produit. Il a décrit un état d'esprit pour bricoler le week-end, et le marché en a fait une promesse de livraison.
La précision compte parce qu'elle déplace la responsabilité. Le problème n'est pas le vibe coding tel que Karpathy l'a défini — un outil honnête pour explorer vite et jeter sans regret. Le problème est la confusion entretenue entre cet outil et un processus d'ingénierie. Confusion qui a un coût : les outils de mesure du code l'enregistrent déjà.
La même étude GitClear de 2024 montre que le refactoring — le travail de consolidation qui transforme un empilement de code en architecture tenable — est passé de 25 % à moins de 10 % des modifications. Le code produit s'accumule sans être retravaillé. C'est le symptôme d'une dette qui s'installe pendant qu'on regarde la démonstration, et c'est précisément ce que Le code IA qui revient vous hanter examine de près.
Ce que la démonstration ne montre jamais
La nuance s'impose, parce que rien de tout cela ne condamne les outils. Un prototype construit en un jour a une valeur réelle : il valide une intuition, il aligne une équipe sur une vision, il évite des semaines passées à spécifier ce qui se voit en cinq minutes d'usage. Le vibe coding, dans son acception d'origine, est un excellent moyen de répondre à la question « est-ce que cette idée mérite qu'on s'y investisse ? ».
Le malentendu commence quand on confond la réponse à cette question avec la réponse à une autre : « est-ce que ce logiciel peut servir des clients ? ». La première se règle en heures. La seconde se règle en mois, et aucune accélération de la première n'écourte la seconde, parce que les deux travaux n'ont presque rien à voir. L'un explore, l'autre durcit. L'un peut ignorer les cas limites, l'autre n'existe que pour eux.
Les modèles vont continuer de gagner en puissance, et la frontière entre prototype et produit se déplacera — un peu. Elle ne disparaîtra pas, parce qu'elle ne tient pas à la vitesse de génération du code mais à la nature des problèmes que pose le monde réel : des utilisateurs qui font l'inverse de ce qu'on attend, des données qui mentent, des adversaires qui cherchent la faille. Tant que ces problèmes existeront, il faudra quelqu'un qui ait relu, testé et compris. Willison appelait déjà ça autre chose que du vibe coding.
Sources
- Andrej Karpathy, tweet du 2 février 2025 : https://twitter.com/karpathy/status/1886192184808149383
- Simon Willison, « Not all AI-assisted programming is vibe coding », 19 mars 2025 : https://simonwillison.net/2025/Mar/19/vibe-coding/
- Merriam-Webster, entrée « vibe coding » (mars 2025) : https://www.merriam-webster.com/slang/vibe-coding
- Collins Dictionary, Word of the Year 2025 (6 novembre 2025) : https://blog.collinsdictionary.com/language-lovers/collins-word-of-the-year-2025-ai-meets-authenticity-as-society-shifts/
- 404 Media, « This AI "Vibe Coding" Game Makes $50,000 a Month. Yours Probably Won't » : https://www.404media.co/this-game-created-by-ai-vibe-coding-makes-50-000-a-month-yours-probably-wont/
- Tom Cargill, Bell Labs, règle 90/90 (citée par Jon Bentley, « Programming Pearls », Communications of the ACM, 1985)
- GitClear, « AI Copilot Code Quality » (données 2020-2024) : https://www.gitclear.com/ai_assistant_code_quality_2025_research
