Le ‘vibe coding’ ne supprime pas le travail : il le déplace vers la confiance, le risque et la rapidité
En février 2025, Andrej Karpathy a popularisé le terme vibe coding en décrivant une manière de développer des logiciels où le programmeur "se laisse porter par les vibrations", embrasse l'exponentialité et "oublie presque que le code existe" tandis qu'un modèle de langage génère la base du système à partir d'instructions en langage naturel. Cette phrase a capté une transition qui était déjà en cours : des outils comme GPT-4, Claude ou Sonnet transforment l'intention en implémentation avec une fluidité qui, pour de nombreuses équipes, semble plus proche de diriger que de programmer.
La promesse opérationnelle est claire : moins de friction, plus de rapidité. Une donnée souvent citée dans les analyses sectorielles, attribuée à McKinsey, suggère que les développeurs avec des assistants d'IA complètent des tâches jusqu'à 56 % plus rapidement que dans des approches traditionnelles. Parallèlement, le marché a comblé le vide entre "idée" et "produit" avec des éditeurs et environnements qui soutiennent cette logique : Cursor Composer pour la génération automatisée, Replit pour créer des applications en langage naturel, et des flux Google reliant l’idéation au déploiement, y compris Firebase Studio et l’impulsion vers le "vibe deploying" avec Cloud Run.
Cependant, le récit le plus précieux ne réside pas dans la rapidité, mais dans le déplacement du travail. L'article inspirant sur HackerNoon —un témoignage pratique sur ce qu'on a appris en faisant du vibe coding— souligne une vérité inconfortable pour toute direction : les fondamentaux restent importants. Ce qui change, c'est où apparaît le coût. Avant, c'était du temps d'ingénierie. Maintenant, chaque point de rapidité exige un prix en gouvernance, révision et clarté des responsabilités.
Lorsque le code devient « bon marché », l'adoption devient un problème de friction mentale
Dans les entreprises, l'adoption d'une nouvelle méthode de construction de logiciels échoue rarement à cause de la capacité technique. Elle échoue à cause de la psychologie organisationnelle : incertitude, perte de contrôle et peur de "mettre en production" quelque chose que personne ne se sent vraiment propriétaire. Le vibe coding accélère justement le segment où le cerveau exécutif a tendance à faillir : il confond démonstration avec produit.
Dans un flux conversationnel, l'utilisateur décrit ce qu'il veut, l'IA retourne quelque chose de fonctionnel et l’équipe itère avec des instructions. Cette dynamique produit une récompense immédiate qui réduit la sensation d'effort. Du point de vue de l’acheteur interne —produit, marketing, opérations— l’attraction est évidente : des prototypes plus rapides, moins de dépendance à des goulets d'étranglement techniques, et un récit de "enfin, nous pouvons construire". La friction cognitive diminue car le langage spécialisé du développement disparaît : il n'est plus nécessaire de naviguer dans un océan de frameworks, de dépendances et de configurations pour voir quelque chose fonctionner.
Mais cette même réduction de friction déplace l'effort vers un endroit moins visible : l'évaluation du risque. Lorsque le résultat apparaît rapidement, le cerveau suppose que le chemin est également simple. Et c'est là qu'apparaît l'asymétrie : la valeur perçue devient immédiate, tandis que les coûts réels —dette technique, sécurité, maintenance— deviennent différés et, pire encore, diffus dans la chaîne de responsabilité.
C'est le schéma que je vois se répéter : les dirigeants investissent pour "faire briller" la démo, car c'est ce que le comité comprend et applaudit. Et ils sous-investissent dans l'atténuation des peurs opérationnelles, car ces peurs ne sont visibles que lorsqu'elles se matérialisent sous forme d'incidents, de retards ou de coûts supplémentaires.
La productivité de 56 % plus rapide est réelle, mais l'unité économique change
La donnée de 56 % fonctionne comme un argument commercial, mais dans la pratique, le bénéfice n'est pas linéaire. La productivité dans le logiciel ne se mesure pas seulement par la vitesse de livraison, mais aussi par la stabilité du système, le coût des changements futurs et l'exposition au risque. Avec le vibe coding, l'entreprise achète de la vitesse avec une nouvelle monnaie : la confiance dans les résultats générés.
Des outils comme Cursor Composer, Replit ou les flux Google pour générer et déployer des applications réduisent le coût marginal de "tester". Cela peut transformer le portefeuille d'innovation : plus d'expérimentations, plus de MVP, plus de tests avec de vrais utilisateurs. Stratégiquement, c'est puissant car cela transforme des mois de préparation en heures ou en jours.
Cependant, le CFO et le COO devraient remarquer un changement dans l'architecture financière du développement : une partie du coût de l'ingénierie se déplace de la "construction" vers la "vérification". Si auparavant le contrôle qualité était implicite dans l'acte d'écrire et de réviser le code, aujourd'hui le contrôle devient une activité explicite : politiques, tests, révisions, limites de déploiement, et critères d'acceptation plus stricts.
En d'autres termes, le gain de temps existe, mais l'organisation qui ne redessine pas son système de contrôle finira par le payer sous forme de retravail. Le risque ne réside pas dans l'utilisation de l'IA ; il réside dans l’idée que l'IA élimine le besoin de design, d'architecture et de discipline. L'article de HackerNoon le suggère de manière pratique : le vibe coding fonctionne, mais les fondamentaux restent le sol qui empêche le prototype de devenir un produit fragile.
La conséquence financière est directe : le coût du "premier 80 %" se réduit et le "dernier 20 %" devient plus coûteux, ce segment où résident robustesse, sécurité et maintenance. Une équipe mature l'anticipe. Une équipe séduite par la démo le découvre trop tard.
Les quatre forces qui poussent le ‘vibe coding’ au sein des entreprises
Je vois l'avancée du vibe coding comme une négociation entre quatre forces qui concourent dans chaque décision d'adoption.
La pression vient de frustrations réelles : backlog interminable, talent cher, et dépendance à quelques ingénieurs qui "savent où tout est". Dans de nombreuses organisations, le problème n'est pas un manque d'idées, mais une incapacité à les convertir en logiciels utilisables à temps. Là, tout mécanisme qui réduit l'attente et la coordination gagne du terrain.
L'attraction est la promesse d'autonomie. Qu'une équipe commerciale puisse décrire une app et la voir naître, qu'un PM itère des écrans sans attendre un sprint, ou qu'une startup valide un flux en une après-midi. Des outils de prototypage et de génération de bout en bout amplifient cet attrait ; l’idée de "un clic pour déployer" sur Cloud Run condense le rêve de contourner les couches de DevOps et la bureaucratie.
Puis vient la peur, et c'est ici que se joue la partie. La peur n'est pas de la technologie en soi, mais de l'exposition : sécurité, conformité, échecs difficiles à déboguer, et un service informatique qui craint de se retrouver responsable d'un système qu'il n'a pas contrôlé ligne par ligne. Les analyses des fournisseurs et des sociétés de sécurité insistent sur le même point : la supervision humaine reste essentielle, surtout pour les vulnérabilités et la qualité.
Enfin, il y a l'habitude : le statu quo de l'ingénierie a des rituels qui "achètent la tranquillité" —révisions de code, normes, propriété, documentation— même s'ils sont lents. Le vibe coding défie ces rituels et exige de les remplacer par d'autres tout aussi fiables mais plus légers.
Lorsqu'une entreprise adopte le vibe coding et ensuite le "interdit" après un incident, il s'agit presque toujours d'un échec technique inévitable. C'est plutôt parce qu'elle n'a pas conçu le pont psychologique entre la rapidité promise et la sécurité requise.
La nouvelle compétence du leader produit et du CTO : gouverner les prompts et les déploiements
Si le code devient moins coûteux à produire, le différentiel se déplace vers deux compétences : bien spécifier et bien gouverner. Dans le vibe coding, le prompt n'est pas un détail ; c'est une nouvelle forme de design. L'entreprise qui ne standardise pas comment demander, comment valider et comment déployer finit par avoir un théâtre de productivité : beaucoup de démos, peu de fiabilité.
Le mouvement intelligent ici est hybride, comme le suggèrent plusieurs lectures du phénomène : utiliser le vibe coding pour accélérer l'idéation et les prototypes, mais maintenir la discipline de production. Cela implique des règles claires : quels types de systèmes peuvent être générés avec aide intensive, ce qui nécessite une révision approfondie, et où se situent les contrôles minimaux avant un lancement.
Cela implique également une honnêteté organisationnelle concernant le "coût de comprendre". Le vibe coding peut produire du code qui fonctionne sans que l'équipe le comprenne totalement. Cela semble efficace jusqu'à ce que le système tombe en panne. À ce moment-là, l'organisation paie en temps de diagnostic et en risque réputationnel. La solution n'est pas de romantiser la programmation traditionnelle ; c'est d'accepter que la rapidité nécessite des garde-fous.
Au final, cette tendance rend plus précieux le leader qui sait apaiser les peurs : celui qui réduit l'incertitude avec des processus simples, celui qui rend la révision fluide et fréquente, et celui qui définit la responsabilité sans bureaucratie. Le vibe coding ne supprime pas le travail ; il supprime le travail visible et oblige à professionnaliser celui qui est invisible.
La décision exécutive correcte : investir moins dans le brillant et plus dans le contrôle opérationnel
Le vibe coding est en train de devenir une interface compétitive : ceux qui peuvent expérimenter plus rapidement apprennent plus tôt. Mais cet avantage ne se maintient que si l'organisation évite de confondre rapidité et contrôle. L'avenir probable est une carte d'adoption inégale : des entreprises qui l'utilisent pour les prototypes et la validation précoce, et des entreprises qui en font un moteur de livraison continue avec une gouvernance solide.
Pour le C-Level, le point critique n'est pas de choisir un outil, mais de concevoir un système de confiance : critères de qualité, limites de déploiement, et contrôles qui ne ralentissent pas la vitesse. La société qui traite cela comme "un nouvel IDE" fera face à des frictions internes et à des risques accumulés. La société qui le traite comme une refonte de la manière dont on décide, on révise et on assume la responsabilité capturera l'avantage sans multiplier l'exposition.
L'erreur stratégique récurrente se manifeste lorsque le leadership investit tout son capital pour faire briller le produit avec des démos de plus en plus rapides, laissant sans budget le travail moins glamoureux d’apaiser les peurs et les frictions qui déterminent si le client, interne ou externe, l’achète réellement.
