Qu'est-ce que le vibe coding ?

Le vibe coding est une façon de construire des logiciels où vous décrivez ce que vous voulez en langage naturel, laissez une IA générer le code, l'exécutez, et itérez sur le résultat — sans lire, relire ni comprendre le code produit par le modèle. Le terme a été forgé par le chercheur en IA Andrej Karpathy le 2 février 2025, dans un post qui décrivait un mode où l'on « se laisse totalement porter par les vibes, embrasse les exponentielles, et oublie que le code existe. » Le tweet était, selon ses propres mots plus tard, une « pensée de douche lancée à la volée » — pourtant il a nommé quelque chose que des millions de développeurs faisaient déjà et a déclenché une conversation mondiale sur ce que ressemble le développement logiciel quand écrire du code n'est plus le goulot d'étranglement. La conséquence pratique que Karpathy n'a pas développée : le vibe coding repose entièrement sur des agents de coding IA tournant dans votre éditeur ou votre terminal, et chacun de ces agents facture au token. Oublier que le code existe n'arrête pas le compteur de tokens. Il le fait tourner plus vite. Cet article couvre ce qu'est le vibe coding, en quoi il diffère du coding traditionnel et de l'agentic coding, là où il brille vraiment, là où il mord discrètement — et, la partie que la plupart des guides omettent, comment éviter que la facture en tokens transforme un hack de week-end sympa en dépense imprévue.

Comment fonctionne concrètement le vibe coding ?

Le vibe coding est une boucle conversationnelle en quatre étapes : décrire, générer, exécuter, rapporter.

Décrire. Vous rédigez un prompt en langage naturel — « construis une appli de notes markdown avec stockage local » — et le collez dans un outil comme Cursor, Claude Code ou GitHub Copilot Workspace.
Générer. Le modèle produit le code. Vous ne le lisez pas ; vous l'acceptez.
Exécuter. Vous lancez le résultat. Quelque chose fonctionne, quelque chose casse, ou quelque chose semble bizarre.
Rapporter. Vous collez l'erreur, le comportement inattendu ou la prochaine demande de fonctionnalité dans le chat. Recommencez.

Ce qui en fait du « vibe » c'est la suspension délibérée de la propriété du code. Vous n'êtes pas un développeur qui utilise l'IA en assistance ; vous êtes un directeur qui utilise l'IA comme unique réalisateur. Le modèle possède la base de code. Vous possédez l'intention. Cela n'est viable que parce que les LLM modernes — notamment les modèles frontier qui alimentent des outils comme Claude Code et Cursor — peuvent produire du code étonnamment cohérent sur des centaines de lignes en une seule génération. Karpathy a nommé la pratique en février 2025 précisément parce que les modèles venaient de franchir un seuil où cette boucle était assez rapide pour paraître productive sur de vrais logiciels, pas seulement des scripts jouets.

En quoi le vibe coding diffère-t-il du coding traditionnel ?

Le coding traditionnel implique de lire et écrire chaque ligne. Vous comprenez les abstractions, le flux de données, les cas limites. Les outils IA — autocomplétion, suggestions inline — accélèrent la frappe mais ne changent pas le modèle de propriété : vous êtes responsable de ce qui est commité. Le vibe coding inverse cela. Le modèle écrit ; vous guidez. Le compromis est explicite : vous avancez plus vite en surface et accumulez de la dette en dessous. Les bugs qu'une relecture attentive aurait détectés passent à travers les mailles, parce qu'aucune relecture attentive n'a lieu. Les failles de sécurité qu'un développeur reconnaîtrait comme dangereuses passent inaperçues. La dette technique s'accumule silencieusement parce que la base de code grandit par cycles prompt-et-acceptation, non par décisions de conception délibérées. Ce n'est pas une raison de l'éviter — c'est une raison de le cadrer correctement (plus là-dessus ci-dessous). Beaucoup de développeurs expérimentés utilisent le vibe coding pour des scripts jetables, des prototypes, et tout ce qu'ils supprimeraient sans remords en une semaine. Le problème, c'est quand le prototype devient le produit.

En quoi le vibe coding diffère-t-il de l'agentic coding ?

La distinction est importante pour comprendre le coût en tokens, il vaut donc la peine d'être précis. Le vibe coding est un état d'esprit : faible supervision, langage naturel en premier, accepter ce qui vient. Vous pouvez le pratiquer avec n'importe quel outil qui génère du code. L'IA reste largement réactive — elle répond à vos prompts, un échange à la fois. L'agentic coding est un mode de fonctionnement : l'agent IA planifie une tâche en plusieurs étapes, exécute des actions (lit des fichiers, lance des commandes, écrit des tests, modifie du code), observe les résultats, et boucle — de façon autonome, sans qu'un prompt humain pilote chaque étape. Vous donnez un objectif à l'agent ; il décide comment l'atteindre. La plupart du vibe coding aujourd'hui est alimenté par des outils agentiques — Claude Code, Composer de Cursor, Codex — mais les outils sont plus capables que ce que la pratique exige. Vous pouvez utiliser un agent comme interface de vibe coding (prompt → accepter → prochain prompt) ou comme véritable exécuteur autonome (objectif → l'agent planifie → l'agent livre). L'agentic coding, c'est quand vous utilisez le second mode délibérément, avec supervision. Le vibe coding, c'est quand vous utilisez l'un ou l'autre sans aucune supervision. La raison pour laquelle cela importe pour les coûts : une boucle agentique, même courte, peut exécuter des dizaines de sous-étapes avant de remonter un résultat. Chaque sous-étape lit des fichiers, lance des outils, et réécrit les sorties dans le context window. Chaque token utilisé dans ces étapes — entrée et sortie — est facturé. Le vibe coding amplifie cela parce que la faible supervision donne des objectifs vagues à l'agent, qui compense en lisant plus de contexte pour s'orienter.

Où le vibe coding brille-t-il ?

Utilisé délibérément, le vibe coding est genuinement puissant pour un ensemble spécifique de problèmes : Prototypage et validation d'idées. Vous voulez savoir si quelque chose est faisable avant d'investir un vrai effort d'ingénierie. La vitesse importe plus que la qualité. Un prototype vibe-codé qui vous dit en une après-midi que l'idée ne fonctionne pas vaut bien plus qu'une base de code soignée sur laquelle vous avez passé deux semaines. Automatisation ponctuelle et scripts. Des outils que vous exécuterez une fois, ou des utilitaires qui ne verront jamais un serveur de production. Si ça casse, vous le supprimez. Le profil de risque du code correspond aux enjeux. Traduire une connaissance non-code. Les designers, chefs de produit, chercheurs et experts métier qui peuvent décrire ce qu'ils veulent en détail mais ne codent pas sont le public naturel du vibe coding. Pour eux, le fossé entre « je peux décrire ça » et « je peux le livrer » s'est effondré en 2025. Apprendre en lisant la sortie générée. Certains développeurs utilisent le vibe coding comme mode d'apprentissage — générer une solution, puis étudier ce que le modèle a produit pour comprendre le pattern. Cela ne fonctionne que si vous lisez effectivement le code, ce qui rompt le contrat pur du vibe coding, mais c'est un hybride utile. Builds de jam compétitifs. Projets de hackathon, participations à des game jams, démos sous délai court — tous des contextes où « est-ce que ça tourne ? » est le seul critère d'acceptation.

Où le vibe coding mord-il ?

Les modes d'échec sont prévisibles une fois que vous comprenez le compromis : Sécurité en production. Un flux d'authentification, un gestionnaire d'upload de fichiers, ou une intégration API vibe-codé a presque certainement des vulnérabilités. Non pas parce que le modèle est mauvais en sécurité — il connaît souvent les patterns sécurisés — mais parce que la boucle de feedback n'inclut jamais « est-ce que ça valide correctement les entrées ? » Le modèle optimise pour faire passer le cas de test, pas pour le cas limite qu'un attaquant sonderait. Débogage à l'échelle. Quand un projet vibe-codé grandit jusqu'à plusieurs milliers de lignes, le context window du modèle commence à peiner. Vous n'avez aucun modèle mental de la base de code, donc vous ne pouvez pas diagnostiquer les bugs vous-même. Vous collez les erreurs dans le chat, le modèle fait une correction locale, autre chose casse, vous recollez. La boucle peut tourner des heures sur un problème qu'un développeur expérimenté aurait repéré en minutes en lisant la stack trace. Maintenance et passation. Si vous devez confier le projet à un autre développeur — ou y revenir six mois plus tard — l'absence de toute compréhension humaine rédigée est une vraie contrainte. Le code est suffisamment cohérent pour tourner mais souvent pas assez cohérent pour être raisonné. La facture en tokens. Celle-ci est quantifiable, et c'est ce que la plupart des vibe coders découvrent trop tard.

Pourquoi le vibe coding est-il coûteux en tokens ?

Chaque outil de coding IA — Claude Code, Cursor, Codex, GitHub Copilot Workspace, Windsurf, Cline, Aider — facture au token. Le prix varie selon le modèle et le fournisseur, mais la structure est la même : tokens en entrée (le contexte que vous envoyez) plus tokens en sortie (le code que le modèle génère), l'entrée étant le côté fort en volume et la sortie étant facturée environ 5 fois plus par token. Le vibe coding fait grimper l'utilisation de tokens de plusieurs façons cumulatives : Des prompts vagues produisent des agents exploratoires. Quand vous décrivez ce que vous voulez de façon floue, l'agent compense en lisant davantage de la base de code pour s'orienter. Chaque fichier qu'il ouvre — même les fichiers dont il n'a pas besoin — entre dans le contexte. Un module de 600 lignes représente environ 6 000–8 000 tokens, repayés à chaque tour suivant jusqu'à la fin ou la compaction de la session. Voir comment réduire l'utilisation de tokens des agents de coding IA pour les mécanismes. Longues sessions sans compaction. L'historique de conversation grossit à chaque échange. Le modèle relit le transcript entier à chaque tour. Une session de vibe coding de trois heures peut accumuler des centaines de milliers de tokens de contexte relu — dont la majorité est la sortie acceptée des tours précédents, sans rapport avec la tâche en cours. Amplification de la boucle erreur-collage. Le cycle décrire → exécuter → rapporter, quand il déraille, peut boucler de nombreuses fois avant de converger. Chaque itération ajoute la sortie d'erreur, le diagnostic du modèle et la correction proposée au contexte. La sortie brute d'un build en échec représente souvent des dizaines de milliers de tokens de bruit que le modèle ignore largement. (Consultez les données de coûts sur Coûts en tokens des agents de coding IA.) Pas de discipline d'élagage. Un développeur qui comprend la base de code demande à l'agent de regarder exactement le bon fichier. Un vibe coder prompte souvent « regarde le code pertinent » et l'agent, faute de l'intuition de navigation du développeur, en ouvre trop. L'écart entre ce que l'agent lit et ce dont il a besoin est le principal moteur de coûts. Les retours terrain de développeurs qui ont suivi cela sont frappants : des sessions qui ont brûlé des millions de tokens en une seule journée, des runs individuels à 30–50 € en coûts d'API avant que la fonctionnalité soit terminée, des projets où la facture d'API dépassait la valeur du logiciel. Un développeur écrivant sur Medium a documenté l'utilisation de millions de tokens sur Claude Code en quelques jours, qualifiant ensuite le vibe coding de « piège » — non parce que le résultat était mauvais mais parce que la facture était invisible jusqu'à ce qu'elle ne le soit plus. Le développeur et blogueur Russ White, écrivant en mai 2026, a documenté les coûts de session en détail, constatant que les sessions de vibe coding non gérées coûtaient systématiquement bien plus que l'équivalent réalisé avec un contrôle de contexte explicite (source).

Comment garder le vibe coding abordable ?

Le coût du vibe coding est presque entièrement une fonction de la quantité de contexte que l'agent lit, et non du code qu'il écrit. C'est le levier. Voici comment l'actionner : Réduisez la portée avant de prompter. « Corrige le bouton de connexion cassé » brûle bien moins de tokens que « regarde le système d'auth et corrige-le. » La précision est gratuite et restreint immédiatement la surface de lecture de l'agent. L'agent récupère moins, écrit moins de diagnostic, et résout plus vite. Utilisez la récupération sémantique plutôt que les lectures de fichiers entiers. Les outils qui permettent à l'agent de chercher dans la base de code par sens — trouver la fonction qui gère un comportement spécifique — remplacent les lectures larges de fichiers par des extractions ciblées de symboles. Au lieu de lire cinq fichiers pour trouver une fonction, l'agent lit la fonction. C'est le levier le plus puissant pour les sessions à forte navigation : bien exécuté, une tâche qui aurait coûté 25 000 tokens de lectures de fichiers n'en coûte plus que 2 000. Filtrez la sortie des commandes avant qu'elle n'entre dans le contexte. Ne laissez pas un npm install en échec ou un test run bruyant déverser sa sortie complète dans le context window. L'agent a besoin de l'erreur, pas du transcript de 10 000 tokens qui y mène. Pipeez les commandes bruyantes à travers un filtre ; les flags concis (--porcelain, --quiet) sur git et outils similaires ne coûtent rien et économisent en permanence. Compactez agressivement. La plupart des outils de coding IA ont un mécanisme de compaction de contexte. Utilisez-le entre les tâches, pas quand vous êtes déjà hors contexte. Compacter après une tâche discrète — « j'ai ajouté la fonctionnalité de connexion, maintenant occupons-nous du flux de réinitialisation » — empêche le transcript croissant de s'accumuler. Auditez vos outils MCP. Si vous faites tourner plusieurs serveurs MCP, chaque définition d'outil connecté est renvoyée au modèle à chaque tour, que vous l'utilisiez ou non. Supprimer les outils que vous n'utilisez pas activement, ou les charger paresseusement uniquement quand c'est pertinent, supprime un coût récurrent invisible qui évolue avec le nombre d'intégrations ajoutées. Gardez le contexte stable en cache. Les instructions, conventions du projet et matériaux de référence qui ne changent pas au cours d'une session devraient se trouver dans un préfixe stable que le prompt cache du modèle peut servir à une fraction du coût d'une lecture fraîche. Sur Claude, les tokens en entrée mis en cache coûtent environ 10 % des tokens non mis en cache. Si appliquer tout cela manuellement vous semble aller à l'encontre de l'attrait décontracté du vibe coding, c'est précisément le fossé que Tokenade comble. Il applique ces leviers automatiquement — semantic search, output filtering, lectures structure-first, chargement d'outils à la demande — sans vous demander de changer votre façon de prompter. La surcharge de l'efficacité des tokens disparaît, ce qui vous permet de garder l'aspect libre et exploratoire du vibe coding sans la facture qui l'accompagne habituellement. Gratuit jusqu'à environ 20 millions de tokens, puis Pro à 9,90 €/mois TTC.

Ce qui tourne mal (anti-patterns)

Accepter du code cassé et itérer au feeling. La boucle « exécuter → coller l'erreur → accepter la correction → réexécuter » peut converger vers un code fonctionnel, mais elle peut aussi s'emballer. Chaque itération ajoute du contexte, chaque correction peut introduire de nouvelles casses, et sans modèle mental de la base de code, vous ne pouvez pas dire si vous progressez ou dérivez. Fixez un budget de tours : si l'agent n'a pas résolu une erreur en trois tentatives, arrêtez et lisez l'erreur vous-même. Traiter le code généré comme du code relu. Particulièrement dangereux pour tout ce qui touche à l'authentification, aux E/S de fichiers, aux API externes, ou aux entrées utilisateur. « Ça fonctionne dans mon test » n'est pas une revue de sécurité. Les chemins vibe-codés vers la production devraient passer par au moins un audit manuel des surfaces qui comptent. Laisser la session tourner trop longtemps. Plus une session tourne sans compaction, plus vous payez pour relire de l'ancien contexte. Les longues sessions corrèlent aussi avec une dégradation de la qualité de sortie à mesure que le context window se remplit d'instructions antérieures, potentiellement contradictoires. Coupez aux frontières naturelles des tâches. Connecter chaque serveur MCP jamais installé. Plus d'intégrations n'est pas mieux si vous ne les utilisez pas. Chaque définition d'outil chargée gonfle chaque tour, pour chaque tâche, que cet outil soit pertinent ou non. Soyez délibéré dans ce qui est chargé. Optimiser la sortie, pas l'entrée. Demander au modèle d'« être concis » ou d'« écrire moins d'explications » est réel mais modeste. La sortie est coûteuse par token mais faible en volume ; l'entrée est moins chère par token mais le volume est tout le problème. Réduire ce que vous envoyez en entrée est le vrai levier ; réduire ce que le modèle écrit est une erreur d'arrondi.

Foire aux questions

Qu'est-ce que le vibe coding ?

Le vibe coding est une approche du développement logiciel où vous décrivez ce que vous voulez à une IA en langage naturel et acceptez ce qu'elle produit, sans lire ni maintenir le code généré. Le terme a été forgé par Andrej Karpathy le 2 février 2025 et est rapidement devenu le raccourci dominant pour le développement IA à faible supervision, piloté par l'intention.

Le vibe coding est-il bon ou mauvais ?

Cela dépend du cas d'usage. Le vibe coding est genuinement efficace pour le prototypage rapide, les scripts jetables, et les contextes où la vitesse de livraison importe plus que la qualité du code. Il est risqué pour tout ce qui atteint des utilisateurs en production, traite des données sensibles, ou doit être maintenu dans le temps. La réponse honnête est que c'est un outil avec un profil de risque spécifique — puissant à l'intérieur de ce profil, dangereux en dehors.

Pourquoi le vibe coding est-il coûteux ?

Le vibe coding est coûteux parce que les agents IA sur lesquels il s'appuie facturent au token, et le style peu supervisé et exploratoire du vibe coding pousse les agents à lire plus de contexte que nécessaire. Des objectifs vagues entraînent de larges lectures de fichiers ; les longues sessions accumulent un historique relu ; les boucles erreur-collage compoundent le coût à chaque itération. La facture est invisible jusqu'à ce qu'elle ne le soit plus — des développeurs ont rapporté avoir dépensé des dizaines à des centaines d'euros en une seule session productive sans s'en rendre compte. Le remède est de contrôler ce que l'agent lit, pas de changer comment vous promptez.

Le vibe coding requiert-il d'apprendre à coder ?

Non, et c'est à la fois son attrait et sa limite. Vous pouvez construire des logiciels fonctionnels avec la seule intention en langage naturel — le cadrage original de Karpathy était que les LLM étaient devenus assez bons pour que l'écriture de code ne soit plus le goulot d'étranglement. Mais l'absence de connaissances en code supprime aussi la capacité à diagnostiquer les échecs, évaluer la sécurité, ou maintenir le résultat. Le vibe coding sans background technique fonctionne jusqu'à ce que ce ne soit plus le cas, et quand ce n'est plus le cas, le chemin vers l'avant est opaque.

Quels outils sont utilisés pour le vibe coding ?

N'importe quel assistant de coding IA peut supporter l'approche vibe coding. Les choix populaires incluent Claude Code, Cursor, GitHub Copilot Workspace, Windsurf, Codex CLI, et Cline. Les outils diffèrent dans l'autonomie qu'ils offrent, la façon dont ils gèrent le contexte, et leur mode de facturation — mais la boucle décrire → générer → exécuter → rapporter fonctionne sur tous. Voir meilleurs outils de coding IA pour une comparaison.

À lire aussi :

Agentic coding — comment les agents autonomes étendent ce que le vibe coding peut faire, et ce que ça coûte.
Comment réduire l'utilisation de tokens des agents de coding IA — les mécanismes derrière chaque levier mentionné ci-dessus.
Context engineering pour les agents de coding IA — la discipline qui fait fonctionner les agents avec moins.
Coûts en tokens des agents de coding IA — les prix derrière le calcul de tokens.
Qu'est-ce qu'un token ? — l'unité sur laquelle tout est facturé.