C'est quoi le Vibe Coding, vraiment ?

Le terme « vibe coding » s'est propagé rapidement en 2024-2025 parce qu'il nomme quelque chose que beaucoup de développeurs faisaient déjà en silence : décrire ce qu'ils veulent en anglais simple à un modèle comme GPT-4, Claude, ou un outil comme Cursor ou GitHub Copilot, et laisser le modèle générer la plupart du code réel. Le programmeur reste dans la boucle, mais la boucle ressemble différemment du codage traditionnel.

La définition réelle

Andrej Karpathy a inventé la phrase, décrivant un flux de travail où vous « cédez complètement aux vibes » — vous faites un prompt, acceptez les suggestions, exécutez le code, voyez ce qui casse, et faites un prompt à nouveau. Vous ne lisez pas chaque diff ligne par ligne. Vous guidez par le résultat : l'app fait-elle ce qu'elle doit faire, le test passe-t-il, la page s'affiche-t-elle correctement. La compétence se déplace de l'écriture de syntaxe à la description claire de l'intention et à la reconnaissance quand le résultat est mauvais.

C'est différent d'utiliser simplement l'autocomplétion. Les suggestions inline au style Copilot supposent toujours que vous écrivez la fonction vous-même avec un peu d'aide pour terminer les lignes. Le vibe coding suppose que le modèle écrit la fonction, le fichier, parfois toute la feature, et vous vérifiez et réorientez plutôt que d'être auteur à partir de zéro.

À quoi ressemble une vraie session

Une boucle vibe-coding typique avec un outil comme Cursor ou le mode Agent de Replit ressemble à peu près à ceci :

1. Prompt : « Ajoute un rate limiter à cette API Express, 100 requêtes par 15 minutes par IP, retourne 429 avec un body d'erreur JSON. »
2. Le modèle édite middleware/rateLimit.js, le branche dans app.js, tire peut-être express-rate-limit.
3. Vous exécutez npm test ou frappez l'endpoint avec curl en boucle pour vérifier que 429 est réellement déclenché.
4. Quelque chose ne va pas — le limiter réinitialise à chaque déploiement parce qu'il est en mémoire. Vous le dites.
5. Le modèle échange pour un store Redis, ajoute la dépendance ioredis, met à jour le fichier docker-compose.
6. Vous re-testez, ça marche, vous commitez.

Aucune ligne de ce middleware n'a été tapée à la main. Mais six ou sept appels de jugement ont été faits par un humain : quelle devrait être la limite, que le stockage en mémoire était mauvais pour la production, que le fichier docker-compose devait aussi être mis à jour.

Où ça marche bien

Le vibe coding est fort pour le travail lourd en boilerplate : endpoints CRUD, validation de formulaires, scaffolding de tests, fichiers de config, code de glue entre deux APIs que vous comprenez déjà. C'est aussi bon pour la prototypage — monter une démo fonctionnelle d'une idée en une heure au lieu d'un jour, puis décider si ça vaut la peine de construire correctement.

C'est vraiment rapide pour les devs solo et les petites équipes expédiant des outils internes ou des MVPs où le coût d'un bug est faible et la vitesse d'itération compte plus que la pureté architecturale.

Où ça s'effondre

Le mode d'échec dont les gens ne parlent pas assez : les modèles produisent du code qui s'exécute mais est subtilement mauvais d'une manière qui ne se manifeste pas avant plus tard. Une requête SQL générée pourrait fonctionner pour le chemin heureux mais être vulnérable à l'injection parce que la concaténation de chaînes avait l'air correcte au modèle. Une vérification auth générée pourrait passer les tests mais ignorer une vérification de rôle sur une route. Si vous ne lisez pas le code, vous ne l'attraperez pas — vous verrez juste les tests passer et vous l'expédierez.

Ca compte plus dans le code sensible à la sécurité que presque partout ailleurs. Simon Willison et d'autres ont souligné que les projets vibe-coded avec de vraies données utilisateur ont besoin de la même rigueur de révision que n'importe quel autre code, probablement plus, parce que la personne qui l'a « écrit » pourrait ne pas être capable d'expliquer ce qu'il fait ligne par ligne.

Les systèmes complexes avec beaucoup d'état implicite — concurrence, transactions distribuées, n'importe quoi avec des bugs de timing subtils — sont aussi un mauvais ajustement. Les modèles tendent à générer du code qui a l'air plausible pour ces cas qui échoue d'une manière qui est dure à déboguer précisément parce que personne, humain ou modèle, n'a complètement modélisé les cas limites à l'avance.

La compétence qui compte vraiment maintenant

Si vous faites du vibe coding, la compétence précieuse n'est pas la vitesse de frappe, c'est la spécification. Les prompts vagues obtiennent du code vague et buggé. Les prompts spécifiques — avec les noms de librairie exacts, les attentes de gestion d'erreur, et les cas limites appelés — obtiennent un bien meilleur résultat. La deuxième compétence la plus précieuse est la lecture de code assez rapide pour attraper ce qui ne va pas, ce qui signifie que vous avez encore besoin de comprendre le langage et le domaine même si vous ne tapez pas chaque caractère.

Traitez le code généré par IA comme vous traiteriez une pull request d'un dev junior qui est rapide mais occasionnellement surconfiant : utile, souvent correct, mais vaut une vraie révision avant qu'il ne touche la production.

Voulez-vous approfondir l'écriture de code avec les outils IA sans perdre le contrôle de la qualité ? Consultez les segments IA et Python de Korra Studio pour des walkthroughs pratiques.