Vibe Coding
Pourquoi c’est important
En profondeur
La description originale de Karpathy était délibérément provocante : il parlait d'utiliser la saisie vocale plutôt que le clavier, d'appuyer sur « tout accepter » à chaque changement proposé sans lire les différentiels, et de corriger les bogues en recollant les messages d'erreur au modèle jusqu'à ce qu'ils disparaissent. Retirez la provocation et le flux de travail est simple — décrire, générer, exécuter, réagir — l'humain agissant comme gestionnaire de produit et testeur plutôt que comme auteur. Ce qui a rendu ça viable en 2025, ce n'est pas que l'IA pouvait écrire du code — les assistants de codage le faisaient depuis des années — mais que les grands modèles de langage sous-jacents sont devenus assez bons pour tenir ensemble tout un petit projet à travers de nombreux tours de cette boucle. En quelques mois, le terme avait complètement débordé des cercles technologiques, apparaissant dans les grands médias et sur la liste des mots de l'année du dictionnaire Collins, et il est devenu le raccourci par défaut pour un véritable déplacement de qui peut bâtir du logiciel.
Les outils qui le rendent possible
Le vibe coding est devenu praticable quand les assistants de codage se sont dotés de modes agents. Au lieu de compléter une ligne à la fois, des outils comme Cursor, GitHub Copilot et Windsurf peuvent maintenant modifier plusieurs fichiers d'un coup, en créer de nouveaux, exécuter des commandes shell, lancer le programme, lire la sortie et itérer — ce qui est exactement la boucle qu'un adepte du vibe coding veut déléguer. De longues fenêtres de contexte permettent au modèle de garder en tête l'équivalent d'un petit projet d'un coup, et un meilleur suivi des instructions fait qu'une description approximative de l'intention produit habituellement quelque chose d'exécutable. Des outils plus autonomes comme Devin poussent la même idée plus loin, prenant une description de tâche et y travaillant pendant de longues périodes avec une supervision minimale.
Là où le vibe coding brille
Le créneau idéal, c'est le logiciel utile mais jetable : projets de fin de semaine, outils personnels, scripts de données ponctuels, prototypes, démonstrations et tableaux de bord internes. Le cadrage même de Karpathy visait les projets de fin de semaine jetables — des choses que vous ne vous seriez jamais donné la peine d'écrire à la main parce que l'effort dépassait le bénéfice. Pour les non-programmeurs, l'attrait est encore plus direct : un enseignant, un spécialiste du marketing ou un propriétaire de petite entreprise peut décrire une petite application et en obtenir une version fonctionnelle en un après-midi, ce qui exigeait auparavant d'embaucher un développeur ou d'apprendre à programmer. Les ingénieurs d'expérience utilisent le même mode pour le code passe-partout, les migrations et le code de liaison, là où la forme de la solution est évidente et où lire chaque ligne apporte peu. Dans tous ces cas, le coût d'un bogue subtil est faible, donc sauter l'étape de révision est un échange rationnel.
La dette de révision et de sécurité
Les risques sont le revers du même choix. Un modèle peut halluciner des fonctions de bibliothèque, choisir des API dépréciées ou brancher l'authentification de travers, et si personne ne lit le différentiel, ces erreurs sont livrées. Des chercheurs en sécurité ont trouvé à répétition que le code généré par IA porte un taux non négligeable de vulnérabilités — failles d'injection, vérifications d'autorisation manquantes, secrets codés en dur — et 2025 a vu une série d'incidents où des applications vite montées en vibe coding ont exposé des données d'utilisateurs ou des clés d'API en production. Il y a aussi un coût structurel plus lent : une base de code que personne ne comprend pleinement est difficile à déboguer, et une fois qu'elle dépasse ce qui entre dans la fenêtre de contexte du modèle, même l'IA commence à faire des changements incohérents. Les critiques rangent le pire de cette production sous l'étiquette slop — du code qui a l'air plausible, qui fonctionne à peu près, et qui pourrit en silence.
Ce n'est pas la même chose que la programmation assistée par IA
Une idée fausse répandue veut que le vibe coding soit juste un nouveau nom pour toute programmation assistée par IA. Ce n'est pas le cas. Le terme désigne précisément l'abandon de l'étape de révision : si le modèle a écrit le code mais que vous l'avez lu, compris et assumé, c'est du développement assisté par IA ordinaire avec un meilleur outillage — une distinction que des auteurs comme Simon Willison ont tracée tôt et nettement. L'idée fausse inverse, c'est que l'humain ne contribue rien. En pratique, le bon vibe coding est une compétence : décrire l'intention avec précision, savoir quoi demander ensuite et reconnaître quand la sortie sent mauvais comptent tous, et c'est pourquoi la discipline recoupe l'ingénierie de prompts et l'ingénierie du contexte.
Comment les professionnels s'en servent vraiment
La plupart des équipes en exercice aboutissent à un motif mixte. Le prototype se fait en vibe coding — rapide, jetable, jugé sur la qualité de la démonstration — et tout ce qui est destiné à la production passe par une révision normale, les tests et l'intégration continue jouant le rôle de filet de sécurité qui remplace la lecture de chaque ligne au départ. Une frontière courante, c'est le risque : les outils et scripts internes sont de bon jeu, tandis que l'authentification, les paiements et tout ce qui touche aux données d'utilisateurs passent sous un regard humain peu importe comment ça a été écrit. Les développeurs chevronnés tirent le plus de ce style, parce que leurs réflexes attrapent vite une sortie qui cloche; les juniors qui s'y appuient trop tôt risquent de livrer du code qu'ils ne peuvent ni expliquer ni corriger. Traiter le code généré comme une demande de tirage d'un collègue junior rapide mais négligent — utile, bienvenu, et jamais fusionné sans être lu — est le modèle mental vers lequel bien des équipes ont convergé.