Vibe coding : c'est quoi, sans hype ni mépris

Début 2025, Andrej Karpathy a posté un tweet jeté sous la douche — son mot, pas le mien — et a accidentellement nommé une pratique que tout le monde faisait déjà sans la nommer. Le « vibe coding » est devenu en quelques mois le mot que les founders adorent et que les ingénieurs séniors lèvent les yeux au ciel en entendant. Les deux camps ont à moitié raison.

Cette page pose la définition propre, montre ce que le vibe coding débloque réellement (et c’est énorme), puis liste sans complaisance ce qu’il casse quand on le sort du bac à sable. Pas de hype — ce n’est pas la fin des développeurs. Pas de mépris non plus — refuser de comprendre ce levier, c’est se priver du meilleur accélérateur de prototype de la décennie. Juste le modèle mental correct, pour quelqu’un qui veut savoir quand l’utiliser et quand ne surtout pas.

La définition honnête (et d’où vient le mot)

Vibe coding : coder en décrivant ton intention en langage naturel à une IA, et en acceptant le code généré sans tout relire ligne à ligne. Tu ne tapes plus la syntaxe — tu décris, tu lances, tu colles l’erreur quand ça casse, tu recommences. Le code existe, mais tu arrêtes de le regarder comme la matière première de ton travail.

Le terme vient d’Andrej Karpathy, cofondateur d’OpenAI et ex-directeur IA de Tesla, dans un tweet du 2 février 2025 : « une nouvelle façon de coder où tu cèdes complètement aux vibes, tu embrasses les exponentielles, et tu oublies que le code existe même ». Sa description du flux est devenue culte : « je vois des trucs, je dis des trucs, je lance des trucs, je copie-colle des trucs, et ça marche le plus souvent ».

Le point clé que beaucoup ratent : Karpathy ne décrivait pas « se servir d’une IA pour coder ». Il décrivait un mode précis où tu abandonnes volontairement la relecture. Accepter tous les diffs sans les lire, renvoyer les messages d’erreur tels quels au modèle, laisser le codebase grossir au-delà de ce que tu comprends. C’est ça, la vibe. Si tu relis, tu corriges, tu valides chaque bloc — tu utilises une IA comme assistant, ce qui est très bien, mais ce n’est plus du vibe coding au sens strict.

So what : le mot recouvre deux choses qu’on confond tout le temps. « Coder avec l’IA » (assistance, tu gardes la main) et « vibe coder » (tu lâches la main sur la compréhension). La confusion est la source de 90 % des débats stériles sur le sujet.

Pourquoi ça marche maintenant (et pas en 2022)

Le vibe coding n’est pas une mode marketing apparue de nulle part. C’est la conséquence directe d’un seuil franchi par les modèles. Trois choses ont basculé en même temps.

Les modèles sont devenus assez bons pour générer du code qui tourne souvent du premier coup. Pas parfait — souvent. Un LLM ne « comprend » pas ton code au sens humain : il prédit la suite de texte la plus probable, token par token. Sauf que sur du code, « le plus probable » s’est mis à coïncider très fréquemment avec « le correct », parce que les modèles ont avalé des milliards de lignes open source. Le code est devenu une de leurs zones de force.

La fenêtre de contexte a grossi. Les modèles peuvent désormais « voir » des fichiers entiers, plusieurs fichiers, voire un petit projet d’un coup — ce qui leur permet de rester cohérents sur un changement qui touche dix endroits. (Le détail technique de cette mémoire de travail, c’est ici : contexte et tokens.)

La boucle s’est fermée. Des outils comme Cursor, Claude Code ou Composer ne se contentent plus de cracher du texte : ils lancent le code, lisent l’erreur, corrigent, relancent. C’est exactement la mécanique d’un agent IA appliquée au développement. C’est cette boucle qui transforme « l’IA écrit une fonction » en « l’IA construit un truc qui marche pendant que tu regardes ».

So what : le vibe coding n’est pas magique, c’est arithmétique. Modèles plus forts + plus de contexte + boucle d’auto-correction = le moment où décrire devient plus rapide que taper. Tant que ces trois courbes montent, la pratique ne disparaîtra pas.

Ce que ça débloque vraiment (le côté lumineux)

Soyons clairs : le vibe coding n’est pas un gadget. Sur le bon terrain, c’est le plus gros gain de vitesse que le développement ait connu depuis l’arrivée des frameworks. Concrètement, il débloque trois choses.

Le prototype en heures, pas en semaines. L’idée que tu griffonnais sur un coin de table, tu peux la voir tourner le soir même. Pour un founder, c’est décisif : tu testes une hypothèse produit sur du vrai code cliquable au lieu d’un Figma mort. Le coût de « essayer pour voir » s’effondre, donc tu essaies dix fois plus de choses.

L’accès au code pour les non-codeurs. Un product manager qui bricole un outil interne, un designer qui monte une démo, un marketeur qui se code un script de scraping. Ce qui demandait avant de mobiliser un dev, certaines personnes le font maintenant seules. Une analyse de 2026 estime que ~63 % des utilisateurs d’outils de vibe coding sont des non-développeurs. Le périmètre de « qui peut fabriquer un logiciel » vient de s’élargir massivement.

La vélocité, même pour les ingénieurs confirmés. Contre-intuitif mais documenté : ce ne sont pas que des débutants. Garry Tan (Y Combinator) a rapporté qu’environ 25 % des startups de la promo Winter 2025 avaient un codebase généré à 95 % par IA — et il insistait : des fondateurs parfaitement capables d’écrire ce code à la main, qui ont choisi l’IA pour la vitesse. Pour eux, le vibe coding n’est pas une béquille, c’est un turbo.

So what : quand le but est d’apprendre vite si une idée tient, le vibe coding est sans rival. La vitesse de l’itération bat la propreté du code — à ce stade précis. Le problème, c’est ce qui se passe quand ce stade s’arrête.

Les pièges : dette technique et sécurité (le côté sombre)

Le piège du vibe coding n’est pas que « le code est moche ». C’est qu’il est invisiblement faux. Tu acceptes ce que tu ne comprends pas, donc tu ne peux pas repérer ce qui cloche. Quatre dangers reviennent systématiquement.

La dette technique cachée. Le code généré marche en démo. Sous le capot, il accumule des choix bancals — pas de gestion d’erreur, des cas limites ignorés, des dépendances en doublon, une architecture qui ne tiendra pas le dixième écran. Tant que tu vibes, tu ne vois rien. Le mur arrive d’un coup, le jour où il faut modifier quelque chose et que personne — toi y compris — ne comprend comment le truc tient debout.

Les failles de sécurité, et elles sont massives. Ce n’est pas un détail théorique. Le rapport Veracode 2025 sur la sécurité du code généré par IA estime que près de 45 % du code IA contient au moins une faille de sécurité connue. Pire : confronté au choix entre une méthode sûre et une méthode vulnérable, le modèle prend souvent la mauvaise, parce que « le plus courant dans les données d’entraînement » n’est pas « le plus sûr ».

Les fuites de secrets. Le cas le plus brutal. Une étude de scan sur des milliers d’apps construites au vibe coding a trouvé des centaines de secrets exposés — clés API, credentials, tokens — en clair. Quand tu ne relis pas, tu ne vois pas que l’IA a collé une vraie clé dans le front, ou laissé ta base de données ouverte au public. Des fuites réelles de centaines de milliers de clés ont eu exactement cette origine.

Le bug que tu ne peux pas réparer. Un LLM peut halluciner une fonction, une API qui n’existe pas, une logique fausse — avec le même aplomb que quand il a raison. Si tu n’as pas lu le code, tu n’as aucun moyen de distinguer le solide du fragile. Et quand ça casse, tu colles l’erreur à l’IA… qui tourne parfois en rond sur son propre bug.

So what : le vibe coding déplace le risque du visible (ça ne compile pas, tu le vois) vers l’invisible (ça compile, ça marche en démo, et ça fuit tes données en silence). C’est précisément ce qui le rend dangereux en prod : le pire scénario ressemble exactement au scénario qui marche.

Vibe coding ≠ ingénierie : où passe la frontière

La règle simple, celle qui évite 90 % des accidents : le vibe coding et l’ingénierie logicielle ne sont pas la même activité, et la frontière, c’est la conséquence d’une erreur.

Karpathy lui-même l’a précisé après coup : le vibe coding est « pas mal pour des projets jetables du week-end ». La nuance est tout sauf anecdotique. Sur un projet jetable, une erreur ne coûte rien — tu jettes, tu recommences. Sur un système avec de vrais utilisateurs, de vraies données, de vrais paiements, une erreur que tu n’as pas vue coûte des clients, de l’argent, parfois la confiance ou la conformité légale.

La ligne de partage, en pratique :

• Côté sûr (vibe à fond) : prototypes, démos, scripts perso, outils internes sans données sensibles, apprentissage, exploration d’une idée. Si ça casse, personne ne saigne.
• Côté à risque (relecture obligatoire) : tout ce qui part en production, touche des données réelles d’utilisateurs, gère de l’authentification, de l’argent, ou des informations personnelles. Là, accepter sans comprendre n’est plus du courage, c’est de la négligence.

Le glissement dangereux est connu : tu vibe codes un prototype le week-end, il marche, des gens commencent à l’utiliser… et le « jetable » devient ta prod sans que personne n’ait jamais relu une ligne. C’est le piège n°1. Le prototype qui réussit est précisément celui qu’il faut s’arrêter pour auditer.

So what : la question n’est jamais « vibe coding, bien ou mal ? ». C’est « quelle est la conséquence si ce code se trompe sans que je le voie ? ». Réponse anodine → vibe. Réponse sérieuse → quelqu’un relit, teste, et endosse ce code avant qu’il ne touche un vrai utilisateur.

Le bon usage pragmatique (vue founder, ship en prod)

Position assumée, du côté de quelqu’un qui ship en prod toutes les semaines : le vibe coding est un excellent serviteur et un très mauvais maître. La bonne pratique n’est ni de l’idolâtrer ni de le refuser — c’est de savoir précisément quel chapeau tu portes à chaque instant.

Un workflow qui tient la route :

1. Vibe la première version, sans culpabiliser. Pour explorer, prototyper, voir si l’idée a du sens : lâche les vibes, va vite, ne relis rien. C’est là que le levier paie.
2. Décide consciemment quand le prototype « passe en vrai ». C’est le moment charnière. À cet instant précis, le mode change : tu arrêtes de vibe, tu relis, tu comprends, tu testes ce que tu vas mettre en prod. Tu peux toujours faire écrire le code par l’IA — mais tu valides chaque chose qui touche la sécurité, les données, l’argent.
3. Traite l’IA comme un dev junior très rapide et trop confiant. Brillant, productif, et capable de t’envoyer une clé API en clair sans broncher. Tu ne mets pas un junior en prod sans relire son code sur les parties sensibles. Même chose ici.
4. Garde les fondamentaux non négociables. Gestion des secrets hors du code, relecture humaine du code critique, tests sur les chemins sensibles. Ces réflexes ne deviennent pas optionnels parce que l’IA a écrit le code — ils deviennent plus importants, parce que personne d’autre n’a regardé.

Et si tu intègres l’IA dans ton produit plutôt que juste la coder, le vibe coding n’est qu’une porte d’entrée. Pour faire répondre un modèle sur tes données, le levier n’est pas un meilleur prompt, c’est le RAG. Pour cadrer ce que produit le modèle, c’est le prompt engineering. Le vibe coding t’amène au prototype ; il ne remplace pas la compréhension de ce que tu construis.

So what : le vibe coding ne supprime pas le métier de développeur. Plus exactement : le vibe coding ne supprime pas le travail d’ingénieur : il le déplace du « écrire le code » vers le « décider si ce code a le droit d’exister ». Il en supprime la partie pénible (taper la syntaxe) et amplifie la partie qui compte vraiment (décider ce qui est bon, sûr, et a le droit d’exister). Le jugement n’a jamais valu aussi cher. Si tu veux creuser le reste de l’IA sans jargon, le guide complet est là.