004 Vibe coding : Attention à la marche !

1 avril 2026

« Passé un certain seuil, l’outil, de serviteur, devient despote. Passé un certain seuil, la société devient une école, un hôpital, une prison. Alors commence le grand enfermement » – Ivan Illich, La convivialité, 1973

Aujourd’hui, l’intelligence artificielle a trouvé un cas d’usage tout à fait intéressant dans l’aide au codage. Il ne se passe pas une seule journée sans qu’on voie, sur LinkedIn ou ailleurs, quelqu’un raconter son expérience de vibe coder, lui ayant permis, en une nuit et avec Claude Code, de générer un business de plusieurs milliers de dollars. Adieu Fowler, adieu Swinnen, place à l’inspiration divine du rédacteur de specs, qui laisse une armée d’agents lui pondre un code fonctionnel en quelques heures. Quelques mésaventures ont ici et là émaillé le Web : telle société a perdu sa base de données utilisateurs et s’est aperçue que le LLM avait maquillé son erreur en regénérant 4000 faux comptes, tel autre s’est retrouvé bloqué avec un code spaghetti dégueulasse impossible à refactorer. Adieu, veaux, vaches, cochons, couvées. Les médias présentent le vibe coder comme un Sisyphe s’étant enfin débarassé de sa pierre, libéré de toute contrainte technique pour accéder enfin au monde des idées et aux montagnes de dollars promis par un marché bienveillant. Ne risque-t-il pas de lâcher la proie pour l’ombre ?

Si l’écriture du code est pénible parce qu’elle impose à notre cerveau d’humain de se plier à une syntaxe machine, l’IA agentique permet de faire sauter cette contrainte en transformant des specs écrites en langage naturel en code sonnant et trébuchant. Ne boudons pas notre plaisir : c’est fantastique ! Mais cela a fait exploser au passage la boucle itérative écriture / exécution / lecture du développement logiciel, ainsi que les coûts de relecture du code. Les code reviews deviennent d’autant plus rébarbatives, cognitivement douloureuses que l’on a délégué à un agent la boucle d’itération créatrice, masquant le coût du changement derrière une apparente simplification. Dans quelles mesures le Vibe Coding peut-il être le nouveau prête-nom du Yolo Driven Development ou une resucée de la bonne vieille méthode R.A.C.H.E ? Plongeons.

Quand les boîtes banquent, la poussière se planque

Dans un article passionnant, Is AI a silver bullet ?, Ian Cooper, architecte logiciel britannique, rappelle qu’on n’en est pas à notre coup d’essai question remèdes-miracles-pour-encapaciter-les-non-techs-à-la-tech : la productivité des développeurs comme l’outillage des métiers est un vieux serpent de mer du développement logiciel. L’industrie ne cesse de vouloir réduire le coût de la tech à l’entrée en rendant plus indolore voire invisible une nécessaire courbe d’apprentissage. Low code, no code ajoutent des couches d’abstraction pour cacher la complexité algorithmique sous de l’UX. Chaque miracle vanté par la presse généraliste arrive pourtant avec ses effets de bord, ses coûts cachés (en tokens ?), ses incidents techniques ses incidents de sécurité, ou ses difficultés d’adoption. Parfois, une commande dans un terminal suffit.

Or, si l’on en croit la Loi d’équivalence de Larry Constantine, transposée par Kent Beck dans un contexte financier, le coût total d’un logiciel est approximativement égal au coût de son changement.

Pourquoi ? Parce que les principales causes de pourrissement d’un logiciel sont :

  1. Le couplage excessif : quand une modification dans un coin du système provoque une cascade imprévisible de bugs un peu partout ;
  2. La faible cohésion : quand une fonction ou une classe essaye de résoudre trop de problèmes à la fois, devenant ainsi illisible et lourdingue.

En d’autres termes, un bon code n’est pas fait pour être exécuté mais pour être lu ; plus un code est difficile à lire, plus il est difficile à maintenir, et plus il coûte cher à maintenir. L’entropie logicielle est une loi universelle, et elle coûte une blinde. Les agents IA s’adaptent à leur compagnon humain et sont particulièrement doués pour fonctionner à la R.A.C.H.E, c’est à dire écrire un code qui ne respecte pas ces principes et empile des couches sur des couches, créant des fonctions monolithiques et des dépendances infernales. Dans le jargon, une big ball of mud ou pour nos amis aficionados de la pasta, un bon gros plat de spaghettis. La Clean Architecture, en revanche, établit une séparation claire des responsabilités, crée un code plus modulaire exécuté par isolats fonctionnels, inverse les dépendances en rendant les couches externes indépendantes des couches internes via un système de contrats (ports) sur lequel viennent se brancher l’infrastructure ou l’UI. Le contexte est porté par l’architecture du code. Sa mise en place exige une certaine technicité et la compréhension d’un certain nombre de principes fondamentaux.

Prototyper un truc sur un coin de table n’est pas si difficile, l’IA agentique permet de le faire en quelques minutes et de générer assez rapidement du cash si l’on se rend capable de monétiser un service. Mais, le goulot d’étranglement se déplace de la production du code à sa maintenance et son auditabilité. Si l’IA génère en dix secondes un code qu’il faut plusieurs minutes pour le comprendre, est-ce que ça ne revient pas à déplcer le problème ? En cause, la gestion de ce que Fred Brooks a formalisé dans No Silver Bullet (1986) : la complexité accidentelle, c’est-à-dire les difficultés introduites par les outils, les langages et l’environnement technique qui ont été choisis pour résoudre le problème métier devient invisible : elle est confiée à l’agent. Le discours des médias généralistes mettent cet aspect sous le tapis lorsqu’ils appellent de leurs voeux une IA boîte noire qui remplacerait les développeurs en codant à leur place et leur permettrait de se concentrer sur la complexité essentielle, celle du métier lui-même. Penser que la complexité du code disparaît grâce à l’IA ? On est dans la pensée magique.

Effet de seuil et perte de contrôle

L’automobile a remplacé avantageusement le cheval, mais impose des coûts systémiques faramineux et des externalités négatives irréversibles (infrastructures, pollution, accidents mortels, dépendances au pétrole, etc.), transformant complètement le paysage et notre rapport au monde. C’est ce qu’Ivan Illich appelle le seuil de contre-productivité dans La Convivialité (1973) : l’outil ne libère plus l’usager passé un certain seuil mais le dessaisit, le dépossède. Si l’aide au codage s’impose comme un cas d’usage majeur et évident des modèles d’IA générative, c’est bien entendu parce qu’il offre un effet de levier conséquent en matière de productivité. Un concurrent en capacité de livrer seul et en trois jours avec une IA une fonctionnalité ce qui demanderait trois semaines à une équipe de développeurs en temps normal a effectivement un fort avantage compétitif. Mais un développeur qui perd la compréhension de sa production sera plus lent, plus fragile qu’avant. Saura-t-il sortir de Vim sans l’aide de son agent ? L’outil produit un ingénieur encore moins autonome, tout comme le GPS produit des humanoïdes incapables de lire une carte routière (et de la replier du premier coup). Peut-on parler de convivialité quand, en plus, l’outil coûte des milliards de dollars à maintenir et demande une infrastructure colossale, notamment énergétique, pour fonctionner ?

Le vibe coding, tel qu’il est présenté le plus souvent, parce qu’il promet une écriture initiale rapide, presque gratuite et sans effort, offre un effet de levier qui permet effectivement de livrer rapidement. Même si aujourd’hui, IDE et agents IA ont des fenêtres contextuelles de plus en plus grandes ou implémentent du RAG, un agent IA reste un programme produisant une suite de tokens probables dans un contexte donné. Par anthropomorphisme, on dirait qu’un agent IA est un stagiaire remarquablement intelligent, extrêmement enthousiaste, mais à la rationalité fortement limitée, susceptible de faire de multiples erreurs en toute bonne foi, déborder du contexte, faire des suppositions erronées, et prendre des initiatives malheureuses même lorsqu’il est strictement cadré. Donner à ce genre d’énergumène un accès illimité et non contrôlé à l’ensemble d’une machine reste passablement dangereux. D’autant plus lorsque ce serviable individu est branché à l’extérieur sur un fournisseur de modèle à qui il envoie en continu du code source, mais aussi des données et métadonnées potentiellement sensibles.

Codeurs et programmeurs

Karpathy, l’inventeur du terme de vibe coding a un CV plutôt bien rempli dans domaine de l’IA et le déploiement de systèmes d’information en production. On peut imaginer qu’il a une vision assez fine des enjeux et des limites des outils qu’il utilise. Quand il dit “forget that the code even exists”, c’est peut être par abus d’enthousiasme : il en a intériorisé les possibilités et les limites. Il peut oublier le code : il connaît le 道 Tao du code, comme ce personnage du Zhuangzi qui plonge dans les remous d’une rivière dont il connaît si bien les mouvements parce qu’il les a intériorisés, mémorisés dans son corps (coucou Bergson !) qu’ils sont devenus une habitude, une seconde nature là où pour Confucius qui le regarde stupéfait, ils seraient sans doute mortellement dangereux. Voilà un homme qui a dû passer plus de temps que moi à se creuser la tête pour résoudre des problèmes de code. Inutile de dire qu’entre Karpathy avec Claude code et votre serviteur avec le même outil, il y a comme qui dirait un saut qualitatif.

📖 Extrait du Zhuangzi, trad. Jean-François Billeter

Confucius admirait les chutes de Lü-leang. L’eau tombait d’une hauteur de trois cents pieds et dévalait ensuite en écumant sur quarante lieues. Ni tortues ni crocodiles ne pouvaient se maintenir à cet endroit, mais Confucius aperçut un homme qui nageait là. Il crut que c’était un malheureux qui cherchait la mort et dit à ses disciples de longer la rive pour se porter à son secours. Mais quelques centaines de pas plus loin, l’homme sortit de l’eau et, les cheveux épars, se mit à se promener sur la berge en chantant.

Confucius rattrapa le nageur et l’interrogea : “Je vous ai pris pour un revenant mais, de près, vous m’avez l’air d’un vivant. Dites-moi : avez-vous une méthode pour surnager ainsi ? “

“Non, répondit l’homme, je n’en ai pas. Je suis parti du donné, j’ai développé un naturel et j’ai atteint la nécessité. Je me laisse happer par les tourbillons et remonter par le courant ascendant, je suis les mouvements de l’eau sans agir pour mon propre compte.“

“Que voulez-vous dire par : partir du donné, développer un naturel, atteindre la nécessité ?” demanda Confucius.

L’homme répondit : “Je suis né dans ces collines et je m’y suis senti chez moi : voilà le donné. J’ai grandi dans l’eau et je m’y suis peu à peu senti à l’aise : voilà le naturel. J’ignore pourquoi j’agis comme je le fais : voilà la nécessité.”

Dans les mains de quelqu’un qui sait ce qu’il fait, un projet devient plus facile à cartographier sémantiquement, plus facilement intelligible pour une IA qui devient alors un assistant aussi efficace que précieux. Ce sont les développeurs capables de construire cette structure théorique — ceux que Ian Cooper appelle les « Programmeurs » et non les « codeurs » dans un article récent — qui tirent leur épingle du jeu. Le programmeur, c’est celui qui cadre l’agent sur l’architecture et la théorie du projet, lui délègue la syntaxe, vérifie les outputs et garde la main sur la complexité essentielle. Le LLM sera peut-être une boîte noire, mais pas le code qui en sort. Le scénario le plus vraisemblable, c’est que l’intelligence artificielle encapacite davantage les ingénieurs qui ont une pratique et finisse par devenir un obstacle pour les autres qui continueront à accumuler sans le savoir une dangereuse dette technique sur le long terme.

Apprendre à l’ère du vibe coding

Tirant les leçons des grandes avancées en matière de modèles d’IA, Cooper conclut que des agents vont désormais écrire la majorité du code et résoudre les problèmes de syntaxe, compétence que beaucoup de développeurs plus senior sont ravis de déléguer, mais qui reste indispensable, de mon point de vue, pour l’apprenant. Le programmeur, lui, fait du design algorithmique, pose une architecture, décide des patterns et des structures de données. Or, si la théorie d’un programme, sa compréhension profonde relève (encore ?) de l’humain, c’est que les agents IA n’ont pas le contexte hors code d’un programme, ils sont amnésiques par conception. Un agent n’est pas membre d’une équipe, c’est l’exosquelette intellectuel du programmeur. Une théorie est une construction sociale. Déléguer la construction de cet objet social à un algorithme amnésique, c’est automatiquement se créer de la dette cognitive. Même avec BMAD ou GSD, qui orchestrent des agents spécialisés qui simulent des rôles, documentent des conclusions : c’est le chemin de réflexion qui se perd. D’autant que les humains sont facilement suggestibles par les modèles. Les effets de bord de ces raccourcis sont connus : perte de cohérence de la codebase, achat de dette technique, cognitive, mesurée par l’expérience intellectuelle du bus factor1, d’autant plus critique quand les équipes se réduisent.

La maîtrise de la syntaxe devient une compétence obsolète, et avec elle, la capacité à débugger. C’est certes une tâche pénible, décourageante, fortement créatrice d’ascenseurs émotifs qui font passer en un instant de la dépression la plus profonde à une totale euphorie, mais c’est comme ça qu’on apprend, que l’on acquiert le geste artisanal, qu’on se forme une banque de souvenirs et de réflexes qui donnent une intuition précieuse et une connaissance technique brute. Si la pratique du vibe coding se généralise dans la formation, elle ne permettra pas aux juniors de développer les indispensables compétences de base qui leur donneront une maîtrise fine de l’agent et des couches logicielles. Le principal risque est que la connaissance se perde. Le parcours de formation des apprentis en entreprise est d’autant plus crucial que ce qui est souvent visé reste la productivité au détriment de l’acquisition d’un savoir solide. Peut-on être programmeur sans être passé par l’étape codeur ? Être pianiste sans gammes ? La solution pour les juniors n’est pas moins d’IA, mais une IA utilisée comme tuteur structuré plutôt que comme assistant aveugle. Exemple : suivre un parcours comme roadmap.sh avec l’IA en guide de chaque étape, plutôt que de lui demander de faire le boulot à la place.

Conclusion

Plus que jamais, l’intervention de l’humain dans cette boucle créatrice (Human in the loop) reste indispensable. La review du code est extrêmement pénible, mais indispensable (y compris assistée par un autre modèle que celui utilisé pour coder). Cadrer l’agent par une suite de tests est absolument nécessaire pour éviter les multiples régressions que l’agent ne manquera pas d’introduire (amnésique, on dit, même s’il peut avoir une compréhension assez fine du code quand les patterns sont nommés et quand la sémantique est juste). Il faut aussi ajouter des linters et des outils d’analyse de complexité cyclomatique comme Ruff pour éviter les fonctions à rallonges et les raccourcis qui rendront le code illisible. J’aime bien passer à mon agent les titres des bouquins de ma bibliothèque : Clean Code et Clean Architecture de Robert Martin, Patterns of Enterprise Application Architecture et Refactoring de Martin Fowler, Domain-Driven Design de Eric Evans ou The DevOps Handbook de Gene Kim. Les auteurs du Manifeste agile. Ça permet de partager une culture commune : bien ou mal, l’agent a sans doute mieux digéré que moi ces bouquins.

Vibe coder en faisant confiance à son intuition et à l’IA pour livrer, c’est se créer de la dette : dette technique, dette cognitive et, bientôt, de la dette financière. Les fournisseurs de modèles brûlent des milliards en subventionnant l’accès à pas cher pour créer une dépendance. Et si le cadre lui-même repose sur un outil propriétaire opaque, utiliser Claude Code ou Gemini, c’est déléguer non seulement la syntaxe, mais progressivement ses modèles mentaux à Anthropic ou Google. C’est leur faire cadeau de notre souveraineté intellectuelle. Il suffit que l’API change, que le prix triple, ou que le modèle soit retiré, et le développeur reste seul face à un code qu’il ne maîtrise plus, dans un système qu’il comprend de moins en moins. La Némésis n’est pas seulement la régression introduite en production, mais la perte de souveraineté totale sur l’outil de production tout en nourrissant les géants de l’IA avec nos données, nos processus, notre intelligence.

L’IA agentique permet d’aller vite, mais c’est le programmeur qui place les garde-fous nécessaires à la pérennité des applicatifs. Il faut donc mettre l’IA à son service. Des modèles comme Qwen ou Mistral, qui tournent localement via Ollama, permettent d’assister le développement sans céder ni les données, ni le modèle mental du projet, ni la souveraineté sur l’outil. À chacun ensuite de déterminer son flux de travail, de définir des plages de refacto, d’apprentissage ou de gestion de la dette.

Tout écart, tentative de partir dans le flow et de coder sans garde-fous (hubris) finira tôt ou tard par appeler le châtiment des dieux (nemesis). À terme, c’est ce qui fait la différence entre confier les clefs de la boîte à un ingénieur… ou à Madame Irma.

🔗 Références

Footnotes

  1. Soit le nombre de personnes de l’équipe pouvant passer sous un bus sans nuire à la continuité de l’activité ↩

Retour au blog