Qu'est-ce que le vibe coding ? Définition de Karpathy, outils, risques et règles « Vibe & Verify »

En février 2025, le cofondateur d'OpenAI et ancien responsable de l'IA chez Tesla, Andrej Karpathy, a publié sur X une seule phrase qui a fait le tour du monde avec un nouveau terme : vibe coding.

"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."

Un an plus tard, en 2026, le terme se trouve au centre d'un débat polarisé. Karpathy lui-même a proposé de le renommer, les entreprises constatent une hausse des incidents de sécurité, et pourtant, pour les développeurs indépendants, les startups et les outils internes, il s'est imposé comme un style de codage standard. Cet article parcourt la définition et les derniers débats à partir de sources officielles et de données du secteur.

1. Qu'est-ce que le vibe coding ?

Le vibe coding est un style de programmation construit autour du fait de parler de ce que le code doit faire, plutôt que d'écrire ou de lire le code lui-même. Vous décrivez ce que vous voulez à une IA (Claude, GPT, Cursor Composer, etc.) en langage naturel, et vous continuez à exécuter et à demander des corrections sans lire le code généré.

Trois idées sont au cœur de la démarche :

• Lâcher l'attachement au code : abandonner le sentiment de propriété sur « le code que j'ai écrit ».
• Si ça tourne, c'est bon : une fois que ça fonctionne, comprendre l'intérieur viendra plus tard — ou jamais.
• Le piloter par la conversation : quand des bugs ou des erreurs apparaissent, dites simplement à l'IA « corrige ça ». Coller la stack trace suffit.

Un exemple typique : un développeur indépendant écrit « construis un jeu Tetris en Pygame » → Claude renvoie 500 lignes de code → il l'exécute → la balle ne tombe pas, alors il dit « les blocs ne tournent pas » → il reçoit une version corrigée. Tout cela sans écrire une seule ligne lui-même.

2. Karpathy l'a inventé — et a proposé un nouveau nom un an plus tard

L'expression « vibe coding » a été inventée par Andrej Karpathy sur X (anciennement Twitter) en février 2025. Il l'a utilisée pour décrire l'expérience d'associer Cursor Composer (qui faisait alors tourner Sonnet) à SuperWhisper (entrée vocale) pour construire des applications presque entièrement en parlant.

Ce qui s'est passé l'année suivante :

• Décembre 2025 : Karpathy a rapporté un basculement spectaculaire dans son propre flux de travail — 80 % écrit à la main en novembre, 80 % généré par l'IA en décembre.
• Février 2026 : Karpathy a proposé d'abandonner le nom « vibe coding » et de le remplacer par « ingénierie agentique ». La distinction : vibe = dire ce que vous voulez et accepter ce qui revient ; ingénierie agentique = concevoir le système, spécifier les contraintes et utiliser l'IA pour accélérer une mise en œuvre déjà réfléchie.

Le vibe coding se trouve donc dans une situation étrange — le terme qui a popularisé le concept, mais la personne qui l'a créé ne le recommande plus. Le marché continue malgré tout à l'utiliser, parce qu'aucun autre mot ne capture la même saveur de « décontracté » et « libéré de la lecture du code ».

3. Le flux de travail typique

Assez d'abstraction — voici la boucle réelle que les gens utilisent.

4. Les principaux outils

En mai 2026, voici les outils où le style vibe coding fonctionne particulièrement bien.

Si vous êtes un non-ingénieur qui l'utilise pour apprendre ou prototyper, regardez du côté de Lovable, v0 et Bolt.new. Si vous êtes un ingénieur professionnel travaillant sur du code existant, les références actuelles sont Claude Code, Cursor et Codex CLI.

5. La face sombre — la réalité de la sécurité et de la qualité

« Le vibe coding, c'est génial. Le déployer en production, c'est une autre histoire. » Cet écart est devenu impossible à ignorer en 2026, et les chiffres tiers sont sans appel.

Ce n'est pas une histoire « l'IA est mauvaise » — c'est un problème structurel d'un style de développement qui pousse du code non lu en production. La même IA, utilisée par des humains qui ajoutent revue et vérification, affiche des taux d'incidents nettement plus faibles.

Chaque étude voit des faiblesses différentes — quoi vérifier dans votre propre app, et dans quel ordre

Les chiffres ci-dessus ne mesurent pas la même chose. Veracode a étudié des tâches de code isolées, pour voir si un LLM choisit la façon sûre d'écrire le code ; il n'a pas empêché le XSS dans 86 % des cas (communiqué de Veracode). Tenzai, lui, a demandé à cinq agents de code (Cursor, Claude Code, Codex, Replit, Devin) de construire les trois mêmes applications. Aucune des 15 applications obtenues ne contenait d'injection SQL ni de XSS exploitable, mais les cinq agents ont introduit du SSRF, et une mauvaise autorisation dans l'accès aux API (qui peut toucher à quelles données) figurait parmi les problèmes les plus fréquents (article de SecurityWeek). Et quand Escape.tech a examiné de l'extérieur des applications déjà en ligne, il a trouvé des clés exposées et des données personnelles divulguées (rapport d'Escape.tech).

Autrement dit, maintenant que les agents assemblent des applications entières, ce qui reste le plus souvent, ce ne sont pas les failles de manuel mais celles qu'on ne peut juger qu'en sachant comment l'application est censée fonctionner. Avant de publier une application faite en vibe coding, il est efficace de vérifier dans cet ordre.

1. Des clés sont-elles visibles de l'extérieur ? Ouvrez le code source de la page et le trafic réseau dans les outils de développement du navigateur, et cherchez des clés d'API ou des informations de connexion à la base de données. Vérifiez aussi qu'aucun fichier .env ne se trouve dans un dépôt public.
2. Peut-on voir les données de quelqu'un d'autre ? (autorisation) Créez deux utilisateurs, restez connecté avec l'un et essayez de remplacer l'identifiant dans l'URL ou la requête par celui de l'autre.
3. Une fonction va-t-elle chercher des URL externes ? (SSRF) S'il existe une fonction du type « collez une URL pour importer une image ou une page », saisissez des adresses internes (comme http://localhost ou 169.254.169.254) et vérifiez qu'elles sont refusées.
4. La saisie s'affiche-t-elle telle quelle à l'écran ? (XSS) Saisissez dans un champ de commentaire ou similaire une chaîne contenant <script> et vérifiez qu'elle s'affiche comme du texte au lieu de s'exécuter.

Chaque vérification prend quelques minutes et ne demande pas de savoir lire du code. Si l'une échoue, demandez à l'IA de « corriger cette faille et d'expliquer pourquoi la correction fonctionne », puis refaites la même vérification après la correction.

6. Vibe vs ingénierie agentique

La proposition de renommage de Karpathy en 2026 mérite d'être comprise — elle clarifie le choix opérationnel à faire.

Vous pouvez utiliser les mêmes outils (Claude Code, Cursor) et les transformer en vibe coding ou en ingénierie agentique selon la posture que vous adoptez. L'important est de savoir consciemment « dans quel mode suis-je en ce moment ? » et de basculer délibérément.

7. « Vibe & Verify » — les règles pour le mettre en pratique

La meilleure pratique qui se standardise en 2026 est « Vibe & Verify » : conserver la légèreté de laisser l'IA écrire, mais toujours insérer une vérification en aval.

(1) Changez de mode selon les enjeux

• Faibles enjeux (outils personnels, apprentissage, scripts) : le vibe complet convient.
• Enjeux moyens (outils internes, MVP, prototypes jetables) : vibe + un test de fumée + un scan de sécurité rapide.
• Forts enjeux (production, données client, tout ce qui est public) : le mode ingénierie agentique est obligatoire. Même si vous l'avez écrit en mode vibe, ne poussez pas sans revue humaine + scans de sécurité automatisés + tests ajoutés.

(2) Trois choses à toujours faire avec du code généré par IA

1. Regardez le diff : sauter chaque ligne convient pour du code jetable. Pour du code partagé, jetez au moins un coup d'œil au diff.
2. Lancez un linter de sécurité : semgrep, bandit, truffleHog, etc. Les vérifications mécaniques pour les secrets, le SSRF et le XSS ne sont pas négociables.
3. Faites écrire les tests par l'IA : ajoutez toujours « maintenant écris des tests pour ça » à la même IA. Du code sans tests ne compte même pas comme du vibe coding.

(3) Ne perdez pas la compétence de lecture du code

Habituez-vous trop au vibe coding et au moment où l'IA se trompe — ou au moment où vous devez reprendre le code de quelqu'un d'autre — vous découvrirez que vous ne savez plus le lire. Karpathy lui-même a souligné à plusieurs reprises que la capacité à comprendre le code généré par IA au niveau du détail compte. Même en vibant, prenez l'habitude de vous arrêter de temps en temps pour lire réellement le code ; sur le long terme, c'est là que se forme le véritable écart de compétence.

(4) Ne vibez pas vos secrets

Clés API, mots de passe de base de données, tokens d'accès en production — ne les confiez jamais à l'IA et ne la laissez pas les écrire dans le code. La discipline .env + .gitignore + variables d'environnement n'est pas négociable, vibe ou pas. Les 400 expositions trouvées par Escape.tech correspondaient exactement aux cas où cette hygiène de base s'effondrait.

8. Qui devrait faire du vibe coding, sur quoi et jusqu'où

Résumé

• Le vibe coding est le style « laisser l'IA s'en occuper sans lire le code » proposé par Karpathy en février 2025.
• Karpathy lui-même a depuis proposé de le renommer en « ingénierie agentique » en 2026 — le travail de production exige conception, contraintes et jugement humain.
• Outils principaux : Claude Code, Cursor Composer, Codex CLI, Lovable, v0, Bolt.new, Devin.
• Réalité de la sécurité : les LLM ont choisi l'option non sûre dans 45 % des tâches qui en permettaient une sûre (Veracode), les 5 agents testés ont introduit du SSRF (Tenzai) et les CVE issues de code généré par IA ont été multipliées par environ 6 entre janvier et mars 2026.
• Vibe & Verify : changez de mode selon les enjeux, regardez les diffs, lancez les scans de sécurité, faites écrire les tests par l'IA, ne vibez jamais vos secrets.
• Ne perdez pas « la capacité à lire le code » — plus vous vibez, plus le fait de s'arrêter occasionnellement pour comprendre ce qui se passe devient le différenciateur de compétence à long terme.

Une fois quelque chose façonné vite avec le vibe coding, il est temps de figer la spécification pour la production. Lisez ensuite spec-driven development (SDD) pour maîtriser la répartition « vibe pour explorer, spec pour livrer ».

Pour des analyses de sécurité dédiées, consultez notre guide de configuration, tarifs et interprétation des résultats de Codex Security.

FAQ

Q1. Si Karpathy l'a renommé, le « vibe coding » est-il déjà un terme mort ?

Il reste largement utilisé sur le marché, parce qu'aucune autre expression ne capture la saveur « laisser tranquillement l'IA s'en charger ». La démarche pragmatique est de les traiter comme complémentaires : « mode exploration décontractée = vibe coding », « mode production = ingénierie agentique ».

Q2. Est-ce qu'un débutant peut commencer par le vibe coding ?

Oui — mais lisez aussi le code. Si vous ne faites que viber, vous n'aurez aucun jugement de secours quand l'IA se trompera. Une trajectoire réaliste est d'utiliser au début la joie de « j'ai du code qui marche » comme motivation, puis d'augmenter progressivement la part du temps consacré à comprendre réellement le code.

Q3. Comment vendre le vibe coding à mon patron au travail ?

Apportez trois choses : (1) des règles opérationnelles Vibe & Verify, (2) un scan de sécurité intégré à la CI et (3) des revues de code aussi strictes qu'avant. Une fois que vous pouvez dire clairement « nous augmentons la vitesse sans baisser les garde-fous », la plupart des organisations donneront leur feu vert.

Q4. En quoi le vibe coding diffère-t-il de l'ancien « codage assisté par IA » (Copilot, etc.) ?

La différence, c'est qui est aux commandes. Copilot suit un modèle de « pair programming » — l'humain écrit le code pendant que l'IA le complète. Le vibe coding rend l'IA principale, l'humain se contentant de converser et de confirmer. La frontière est floue, et en pratique de nombreux développeurs vont et viennent entre les deux.

Q5. Avec quel outil devrais-je commencer ?

Pour le développement indépendant ou l'apprentissage, essayez Lovable, Bolt.new ou v0 (uniquement dans le navigateur, rien à installer). Pour le développement logiciel sérieux, essayez Claude Code ou Cursor — Claude Code est en CLI, Cursor est intégré à l'IDE, choisissez selon vos goûts. Le choix de Karpathy est Cursor Composer.

Q6. Qu'en est-il du droit d'auteur sur le code écrit par IA ?

En mai 2026, la base aux États-Unis comme au Japon est que le code généré uniquement par IA n'est pas protégé par le droit d'auteur. Le code qu'un humain a substantiellement modifié ou organisé peut devenir protégeable. Le risque commercial le plus important est la contamination de licence — l'IA réémettant du code GPL ou autrement licencié dans votre base de code — ajoutez donc un vérificateur de licences à votre CI.

Q7. Le vibe coding va-t-il « prendre le travail des ingénieurs » ?

Le tarif du marché pour les « ingénieurs qui ne font qu'écrire du code » est en baisse. En revanche, la valeur de la conception de specs, des décisions d'architecture, de la sécurité et des opérations en production a, si tant est, augmenté à cause de la diffusion du vibe coding. Les personnes capables de « lire, juger et corriger » la grande quantité de code que produit l'IA sont en pénurie en 2026.

À lire aussi : outils d'IA pour le développement de jeux.