Vibe coding : libérateur pour l'expert, risqué pour le novice

À quel moment un développeur qui ne comprend pas son code cesse-t-il d’être un développeur ? La réponse recadre ce qu’on pense du vibe coding.

Ce que ses promoteurs ont raison de défendre

Andrej Karpathy ↗, qui a inventé le terme en février 2025, ne défend pas la médiocrité. Il décrit un mode opératoire : coder en conversation avec un LLM, accepter le code sans le lire en détail, itérer sur le résultat plutôt que sur la syntaxe. Son argument implicite est sérieux : si le modèle prend en charge le volume, votre attention se concentre sur ce qui compte vraiment (le problème, l’usage, l’architecture).

Voilà ce que les défenseurs ont raison de pointer.

1. La démocratisation est réelle. Des non-développeurs créent des outils fonctionnels. Des enseignants construisent des scripts de traitement de données, des managers génèrent des tableaux de bord personnalisés, des chercheurs prototypent des interfaces sans ticket d’entrée technique. Une étude publiée en 2026 ↗ sur l’enseignement du traitement du langage naturel (NLP) montre que des étudiants sans expérience de codage arrivent à construire des pipelines fonctionnels en mode vibe coding, avec une compréhension conceptuelle supérieure à ceux qui écrivent le code ligne par ligne. Ce n’est pas une anecdote isolée : c’est le mécanisme du déplacement de friction à l’œuvre. Enlever la friction syntaxique libère de la bande passante cognitive, les étudiants pensent au problème, pas à la syntaxe. C’est mesurable, pas seulement plausible.

2. Le prototypage s’accélère. Simon Willison ↗ (co-créateur de Django) utilise régulièrement le vibe coding pour tester des idées rapidement. Il l’appelle « vibe engineering » dans ce contexte : le jugement produit prime, le code est l’exécutant. Sur des projets personnels, des outils internes ou des preuves de concept, la vitesse d’exploration a une valeur propre. Une étude de 2025 sur le prototypage UI ↗ mesure des gains significatifs de vitesse sur les phases d’exploration avec vibe coding.

3. L’analogie du dessin. J’ai appris à dessiner enfant sans cours. Là où ça coince dans l’apprentissage classique : l’écart entre ce qu’on imagine et ce qu’on produit est déconcertant, souvent décourageant (et encore, vous n’avez pas vu mes dessins). Il faut des années pour que le geste rejoigne l’intention. Avec le vibe coding, cet écart disparaît : l’intention se traduit quasi directement en artefact visible. La friction se déplace vers l’itération (« est-ce que ça correspond à ce que je voulais vraiment ? ») plutôt que vers la maîtrise technique préalable. C’est précisément ce que la littérature appelle le passage du code-centric au concept-centric.

Dans mon usage du prototypage d’interfaces, je commence souvent par la maquette générée en vibe coding, inspiré d’interface que j’aime bien. Si l’UI n’est pas là, je sais que ça ne le fera pas. C’est une décision produit appliquée directement, sans détour par les spécifications.

Andrej Karpathy (Laisse-moi kiffer la vibe avec mon dév !)

Béquille ou levier ?

L’argument le plus solide en faveur du vibe coding : il libère de la bande passante pour l’essentiel. Sauf que ce raisonnement suppose que l’essentiel soit là avant de commencer. Et cette prémisse n’est pas universelle.

Le LLM amplifie ce qui est là. Pour l’expert aguerri, il libère du temps. Pour le novice, il amplifie l’incompétence sans la rendre visible. Une étude de 2025 ↗ sur le vibe coding recense ce paradoxe : des « pertes de productivité inattendues » pour certains profils. Les gains sont conditionnés à l’expertise existante.

Ce n’est pas si surprenant. La compétence de programmation n’est pas seulement la connaissance de la syntaxe. C’est la capacité à décomposer un problème, à identifier les invariants, à anticiper les effets de bord. Ces capacités s’acquièrent par la résistance du matériau, pour reprendre un concept de Richard Sennett.

Sennett et la résistance du matériau. Dans Ce que sait la main ↗ (2008), Sennett décrit comment le menuisier, l’orfèvre ou le musicien développent leur expertise à travers des milliers d’heures de résistance physique : le bois qui cède mal, le métal qui se comporte différemment selon la température. Cette résistance n’est pas un obstacle à surmonter : c’est le vecteur de l’apprentissage. La question pour le vibe coding : que reste-t-il de cette résistance quand le LLM absorbe la syntaxe, voire davantage ?

Ici l’analogie a ses limites. Sennett parle de résistance physique, sensorielle. La syntaxe n’est pas du bois. L’analogie est commode mais elle ne se démontre pas directement. Ce que Sennett reconnaîtrait probablement comme formateur, c’est précisément la résistance conceptuelle que le vibe coding préserve (à condition de s’y confronter) : décomposer le problème, anticiper les effets de bord, évaluer l’architecture. C’est là que la main de Sennett retrouve son équivalent cognitif.

La réponse nuancée : le vibe coding absorbe la résistance syntaxique, mais préserve la résistance conceptuelle, à une condition. Cette condition est que le professionnel s’engage réellement avec le problème, pas juste avec les prompts.

Il y a une objection sérieuse ici. Si le LLM rend également le conceptuel trop facile (en proposant des architectures, en décomposant les problèmes, en suggérant les invariants), alors même la résistance conceptuelle disparaît. L’apprenti codeur paresseux peut déléguer le raisonnement autant que la syntaxe. Dans ce cas, Sennett perdrait aussi la deuxième manche. C’est précisément pourquoi l’engagement actif avec le problème n’est pas une option morale, c’est la condition technique pour que le déplacement de friction reste formateur. Sur ce sujet, et celui de la méta-cognition, la vidéo de Micode, La Fabrique à Idiots ↗, est exemplaire : claire, bien scénarisée, et souligne l’essentiel (en 38 minutes quand même, on l’excuse pour le titre un peu racoleur).

Micode, mi-robot ? (vignette de la vidéo retouchée)

Le code sans compréhension. Une étude de 2025 sur les interactions étudiants-IA ↗ met en évidence un écart significatif entre maîtrise perçue et maîtrise réelle chez les novices en vibe coding. Les étudiants intermédiaires font mieux : ils ont suffisamment de repères pour questionner le code produit. Les novices acceptent sans comprendre. Ce n’est pas un problème de génération : c’est une mécanique d’apprentissage (exactement celle que Stuart Dreyfus décrivait dans son modèle d’acquisition des compétences, 1980) : l’apprenti avancé reconnaît assez de patterns pour se sentir à l’aise, mais pas encore le contexte qui détermine quand ces patterns s’appliquent. C’est ce que j’ai remarqué ces deux dernières années : pour l’essentiel, les supports sont meilleurs mais, sauf pour le groupe de tête, les progressions sont moins importantes. C’est un peu paradoxal ou décourageant : un meilleur niveau moyen sur le papier, pas dans les têtes.

Et il y a les vulnérabilités. Fu et al. (2023, mis à jour 2025) ↗ ont analysé 733 snippets de code générés par des outils IA dans des projets GitHub : 29,5 % du code Python et 24,2 % du JavaScript contenaient des vulnérabilités couvrant 43 catégories CWE. Ce chiffre ne condamne pas l’IA-assisté en général, mais il questionne directement le vibe coding sans relecture : qui valide ce qu’on ne comprend pas ? Jusqu’où le cadre d’exécution (harness) peut-il stopper cela ?

Dave Farley ↗, expert senior de l’ingénierie continue (Modern Software Engineering), est direct : l’IA sans discipline d’ingénierie produit des coûts cachés et une dette non maîtrisable. Son argument n’est pas que le vibe coding soit inutile, mais qu’il est incomplet comme pratique exclusive. Une blague circulait encore, il y a quelques semaines : « le vibe coding permet d’obtenir en 1 heure la dette technique d’un an de développement ! ».

La synthèse : la friction se déplace mais ne disparaît pas

La friction ne disparaît pas avec le vibe coding.

En codage classique, si on met (un peu) de côté l’architecture applicative, la friction est syntaxique : apprendre le langage, maîtriser les patterns, comprendre les erreurs, identifier ses bugs… En vibe coding, la friction devient plus conceptuelle : est-ce le bon problème ? est-ce la bonne architecture ? est-ce que le code produit tient ses promesses sur le long terme ?

Ce déplacement est libérateur pour celui qui avait déjà internalisé les réponses à ces questions conceptuelles. Il est risqué pour celui qui comptait sur l’apprentissage syntaxique pour construire ces réponses progressivement.

Willison, dans son article fondateur ↗ trace la frontière utile : le vibe coding pur (accepter le code sans le lire, sans tests, sans revue) est différent de l’usage professionnel des LLMs pour accélérer le développement. La deuxième pratique garde la revue, les tests, la compréhension. La première les abandonne. Ce qui change : la capacité à maintenir, à corriger, à faire évoluer.

Sur des projets personnels ou des explorations à durée de vie courte, le vibe coding pur est défendable. Sur un système en production avec des utilisateurs, c’est une bombe à retardement documentée : une étude de 2025 ↗ sur les pratiques terrain identifie la dette et la compréhension partielle comme obstacles principaux. Et comme le note HackerNoon ↗, les incohérences architecturales se cumulent, et le ralentissement post-gain initial est prévisible.

Ce que ça change selon votre profil. Un pair technique expérimenté trouvera dans le vibe coding un accélérateur d’exploration. Le code produit est son point de départ, pas son livrable final. Un consultant peut l’utiliser pour des PoC (preuves de concept) ou des outils internes rapides, en acceptant la limite de durée de vie. Pour un étudiant ou un novice en développement, la prudence s’impose : le risque n’est pas de produire du mauvais code, c’est de ne pas développer le jugement pour reconnaître le bon.

Le profil le plus exposé n’est pas le novice complet. L’étude sur les interactions étudiants-IA ↗ montre que les niveaux intermédiaires sur-estiment leur maîtrise plus que les novices : ils ont suffisamment de repères pour se sentir à l’aise, pas assez pour détecter les dérives architecturales que le LLM introduit sans les signaler. Ce que j’en déduis (sans que l’étude le mesure directement) : le novice sait qu’il ne sait pas. L’apprenti avancé croit qu’il contrôle. C’est là que la dette se constitue sans signal d’alerte.

« Le novice sait qu’il ne sait pas. L’apprenti avancé croit qu’il contrôle. C’est là que la dette se constitue sans signal d’alerte. »

Et si vous gérez une équipe traversée par ces pratiques, la question n’est pas « autoriser ou interdire le vibe coding » mais « à quelle étape du cycle de vie ce code va-t-il, et qui le maintient ? ». Mais la vraie réponse nécessite une discussion approfondie si on ne veut pas se limiter à charrier des lieux communs.

Ce que j’en retiens

Le LLM ne supprime pas la friction : il la déplace. Cette phrase est le cœur de l’article, tout le reste en est la conséquence. Si votre niveau conceptuel est élevé, le déplacement vous libère. Si votre niveau conceptuel est en construction, le déplacement vous prive d’un apprentissage que vous ne saurez pas que vous avez manqué.

Voici où je me situe sur ce sujet, terrain et lectures confondus.

La démocratisation est réelle et précieuse. Que des non-développeurs puissent construire des outils qui répondent à leurs besoins, c’est un élargissement du champ des possibles. Ni l’IA ni les outils ne doivent rester réservés aux initiés.

L’apprentissage par le vibe coding pur est risqué parce qu’il crée un raccourci entre la conception et le résultat. Réchauffer un plat surgelé ne fait pas de vous un cuisinier, mais ça peut être très bon. Les résistances (syntaxique, architecturale…) ont une valeur propédeutique qui ne se récupère pas facilement une fois le geste devenu automatique. Si vous débutez, codez aussi sans LLM, régulièrement. Si vous vous croyez assez avancé pour “contrôler” le vibe coding, c’est précisément le moment d’être vigilant.

La distinction qui compte n’est pas « vibe coding / pas vibe coding » mais « compréhension maintenue / compréhension abandonnée ». Utiliser un LLM pour aller vite et garder la relecture : acceptable. Accepter du code qu’on ne peut pas expliquer dans un système dont on est responsable : le risque ne se mesure pas de la même façon.

La réponse à la question de l’accroche : un développeur qui ne comprend pas son code reste un développeur, mais il n’est plus en mesure de se porter garant de ce qu’il livre. C’est moins une question d’identité qu’une question de responsabilité. Le vibe coding ne supprime pas cette responsabilité. Il la rend plus difficile à tenir.

Je ne sais pas où se situe le seuil exact de compétence à partir duquel l’apport du vibe coding devient positif. Les études suggèrent que les intermédiaires sur-évaluent leur maîtrise, et je ne suis pas certain que ma propre évaluation échappe à ce biais.

L’article frameworks-vibe-coding-ia traite des structures (BMAD, Spec-kit) qui encadrent le vibe coding pour le rendre soutenable en production : le déplacement de friction est gérable quand le cadre absorbe une partie des risques que la compréhension individuelle ne couvre plus. Et l’article sur le paradoxe productivité-IA documente le revers de la médaille : l’accélération du code peut ralentir le développeur sur le long terme.

Et je terminerai par une phrase fréquemment citée par Didier Girard, directeur général de Sfeir : « le bûcheron n’est pas moins bûcheron parce qu’il utilise une tronçonneuse. » Avec malice, on pourrait lui répondre que toute personne qui utilise une tronçonneuse n’est pas bûcheron pour autant.