Le vibecoding, c’est décrire l’intention; et c’est plus dur qu’écrire le code
Pendant des années, j’ai tapé chaque ligne moi-même. Aujourd’hui, la plupart du temps, je décrisce que je veux, je lis ce qui sort, et je tranche. Le clavier sert moins ; la tête, davantage.
C’est ça, le vibecoding : produire du logiciel en décrivant l’intention plutôt qu’en écrivantle code d’abord. Être architecte au lieu de maçon. Une conversation, pas une commande. Etcontrairement à ce que le mot laisse entendre — « vibe », l’ambiance, le feeling —, ce n’est pasla version paresseuse du métier.
Ce qui se déplace, exactement
Le travail ne disparaît pas. Il change de nature, et il vaut la peine de nommer où il atterrit :
Avant : traduire une intention en syntaxe. Tu savais ce que tu voulais, et l’essentiel del’effort partait dans la mécanique — la bonne fonction, le bon ordre, le point-virgule.
Maintenant : formuler l’intention avec assez de précision pour qu’elle soit exécutable, puisjuger ce qui revient. Orchestrer, relire, décider ce qui est assez bon pour rester — et ce quidoit disparaître. L’architecte ne pose pas les briques, mais c’est lui qui répond du bâtiment.
Le déplacement est réel, et il est moins confortable qu’il n’en a l’air. La syntaxe, au moins,te disait quand tu avais tort : ça compilait ou pas. Une intention floue, elle, produit du codequi fonctionne parfaitement — en faisant autre chose que ce que tu voulais.
Décrire est plus dur qu’écrire
C’est le point que je défendrais le plus volontiers. Quand tu écris le code toi-même, tudécouvres ce que tu veux en l’écrivant : la moitié des décisions se prennent en chemin, sansque tu aies jamais eu à les formuler.
Quand tu décris, cette béquille disparaît. Tu dois savoir très précisément ce que tu veux —ou accepter de le découvrir par allers-retours, ce qui reste la bonne méthode mais demanded’être honnête sur le fait que tu ne le savais pas.
Une bonne partie des bogues que j’ai vus naître en vibecoding ne venaient pas du modèle. Ilsvenaient de mes propres incertitudes, ou de mon ignorance du domaine : une phrase qui pouvaits’interpréter de deux façons parce que je n’avais pas tranché, ou une contrainte que j’ignoraiset que je n’ai donc jamais énoncée. Le modèle, lui, a fait exactement ce que j’ai dit.
Les cinq règles qui font tenir la chose
De ma pratique, et de la veille que j’accumule là-dessus depuis un moment :
- Découper en micro-demandes. Un petit changement à la fois, dont tu peux vérifier lerésultat immédiatement. Un gros prompt qui décrit une fonctionnalité entière produitinvariablement quelque chose que tu ne peux ni vérifier ni corriger sans tout défaire.
- Copier les designs plutôt que les décrire. Une capture d’écran et « fais-moi la mêmechose » vaut trois paragraphes d’explications sur les marges et les couleurs.
- Choisir un outil et apprendre ses particularités au lieu de sauter de nouveauté ennouveauté. Tous les outils sérieux font le travail ; c’est ta connaissance de celui que tuutilises qui fait la différence.
- Lire le code. Pas nécessairement tout comprendre — mais savoir où les choses sepassent. Sans ça, tu ne peux plus juger, et juger est devenu ta partie du travail.
- Refactoriser souvent, en visant des fichiers courts. Un fichier compact est plus facile àtenir en tête, pour toi comme pour le modèle qui doit le relire.
Le malentendu à dissiper
« Vibecoding » sonne comme une invitation à ne plus réfléchir. Dans les faits, c’est l’inverse :il déplace tout l’effort vers la partie que personne n’aime, la formulation claire de ce qu’onveut, et il retire celle qui servait d’excuse pour retarder ce moment.
C’est aussi pour ça que je continue de relire ce qui sort, y compris quand ça marche du premiercoup. Le danger n’a jamais été que l’IA se trompe — il est de croire que la vigilance n’est plusnécessaire. J’en ai fait l’expérience de la façon la plus bête qui soit, en collant un mot depasse par réflexe en pleine session : la leçon de sécurité que le vibecoding m’a apprise à mesdépens.
Par où commencer si tu n’as jamais essayé
Prends quelque chose de petit et de réel : un script qui renomme des fichiers, une page quiaffiche un tableau, un utilitaire que tu remets à plus tard depuis des mois.
Puis formule ton intention comme tu l’expliquerais à un collègue compétent qui ne connaît paston contexte. Ce qui reste ambigu dans cette phrase-là est exactement ce qui produira un résultatà côté de la plaque — et c’est un excellent révélateur de ce que tu n’avais pas encore décidé.
Et si ça ne marche pas du premier coup : ne reformule pas tout. Corrige un point, relance,regarde. La conversation est la méthode.
En résumé
- Le vibecoding, c’est décrire l’intention plutôt qu’écrire le code d’abord : architecte au lieude maçon, une conversation plutôt qu’une commande.
- Le travail ne disparaît pas : il glisse vers l’orchestration, la relecture et le jugement —décider ce qui reste et ce qui doit disparaître.
- Décrire est plus exigeant qu’écrire, parce qu’on ne peut plus découvrir ce qu’on veut en coursde route.
- Cinq règles tiennent l’ensemble : micro-demandes, copier les designs, maîtriser un outil,lire le code, refactoriser souvent.
- La plupart des bogues viennent de nos incertitudes ou de notre ignorance du domaine, pas dumodèle.
Toi, tu écris encore ton code ligne par ligne, ou tu décris et tu relis ? Dis-le-moi encommentaire.
Cet article reprend, en version écrite, ma vidéo « le vibecoding, c’est décrire l’intention »publiée sur TikTok. Si tu veux la version courte, elle est ici.
Si le sujet t’intéresse, j’ai aussi écrit sur ce qu’est un harnais IA— le cadre qu’on construit autour d’un agent pour qu’il travaille bien. Abonne-toi au blog pourla suite : une série sur ma pratique quotidienne de l’IA commence en août.