Transformation & IA · Vibe coding 2026
Grâce à l’IA, n’importe qui peut désormais coder une fonctionnalité en un après-midi. Le problème, c’est que plus personne ne décide si elle mérite d’exister.
Le vibe coding en entreprise ne pose pas un problème de technologie. Il pose un problème de tri, de responsabilité et de management.
Le vibe coding en entreprise est passé en quelques mois du gadget de hackathon à la stratégie officielle. On décrit ce qu’on veut en langage naturel, un assistant IA génère le code, on clique, ça tourne. Designers, product managers, marketeurs, et même certains managers se retrouvent capables de livrer une application fonctionnelle sans écrire une ligne de code à la main. Les directions adorent : enfin une IA qui produit quelque chose de visible.
Sauf que Jeff Gothelf, coauteur de Lean UX, vient de poser la question qui fâche dans un article publié fin octobre 2026, « How to manage the inevitable mess of running a company where everyone is a builder ». Son constat : l’IA a supprimé le filtre qualité qui empêchait les mauvaises idées d’arriver en production. Et quand tout le monde devient « builder », plus personne n’a pour mission de dire non.
Chez Corporate Mavericks, on se méfie autant de la bureaucratie que du chaos. Le vibe coding est une formidable nouvelle façon de coder et de valider une idée. Mais si votre organisation le traite comme une machine à fonctionnalités, vous allez fabriquer à grande vitesse un produit que vos utilisateurs ne comprendront plus. Voici pourquoi, et comment l’éviter.
Qu’est-ce que le vibe coding (et pourquoi tout le monde en parle en 2026) ?
Le terme a été lancé en février 2025 par Andrej Karpathy, cofondateur d’OpenAI et ancien responsable de l’IA chez Tesla. Il décrivait une manière de programmer où l’on « se laisse porter par les vibes » : on formule une intention dans un prompt, l’intelligence artificielle produit le code, on teste le résultat et on itère, sans forcément lire ni comprendre chaque ligne de code générée. Le développeur ne tape plus, il dirige.
En 2026, les outils de vibe coding ont rendu cette pratique accessible bien au-delà des équipes techniques. Cursor, Claude Code, GitHub Copilot et une foule d’éditeurs d’applications web permettent de créer une application complète (interface, base de données, authentification) à partir de quelques phrases. Les agents IA vont plus loin encore : ils travaillent de manière autonome sur plusieurs fichiers, modifient le code existant, lancent les tests et poussent le résultat sur GitHub.
Pour un développeur expérimenté, c’est un gain de temps réel sur les tâches répétitives. Pour les débutants et les profils non techniques, c’est une porte ouverte : ils peuvent enfin coder un prototype fonctionnel sans attendre trois sprints qu’une équipe soit disponible. Sur le papier, tout le monde gagne. Dans les faits, le vibe coding change surtout une chose : il rend la production de code presque gratuite. Et quand quelque chose devient gratuit, on en produit beaucoup trop.
Vibe coding en 2026 : du prototype du vendredi au poste de « builder »
Gothelf raconte une scène très ordinaire. Lors d’une fête de famille, il discute avec deux cousins qui travaillent dans la tech : l’une est designer dans une entreprise d’environ 100 personnes, l’autre group product manager dans une structure de 4 000 salariés. Leurs réponses sont presque identiques. Dans les deux entreprises, comme LinkedIn l’avait annoncé l’année précédente, on fusionne les rôles de designer UX et de product manager en un seul poste. Ici on l’appelle « creator », là-bas « builder ». Dans les deux cas, cette personne doit emmener une idée de la conception jusqu’à la production. Et dans les deux cas, personne n’a vraiment réfléchi à la manière dont ça allait fonctionner.
À 100 personnes, avec une dizaine de profils produit et design, le risque reste gérable. À 4 000 personnes, avec une équipe produit et UX de 350 personnes, c’est une autre histoire : 350 nouveaux builders capables de coder et de pousser du code généré vers vos clients. Et dans les grands groupes qui comptent 1 000 ou 5 000 personnes côté produit ? Gothelf pose la question sans détour : comment garder un minimum de discipline sur ce qui est réellement livré, et pourquoi ?
« Beaucoup d’entreprises se débarrassent du rôle produit en disant que tout le monde sera simplement builder. Je pense que c’est une très mauvaise idée. Oui, vous savez utiliser Excel, mais vous ne pouvez pas pour autant travailler dans l’équipe finance. »Andrew Ambrosino (OpenAI), sur le podcast de Lenny Rachitsky, cité par Jeff Gothelf
Tout est dit. Savoir générer du code ne veut pas dire savoir quoi construire. Le vibe coding démocratise la fabrication, pas le jugement.
Le processus de livraison n’a jamais été que de la bureaucratie
On adore taper sur les processus. Nous les premiers : la bureaucratie qui transforme chaque décision en parcours du combattant tue l’initiative et ralentit tout le monde. Mais il faut être honnête sur ce que faisait réellement la chaîne de développement logiciel classique. Revue de code, QA, contrôles de sécurité, tests de performance, déploiements progressifs : tout cela coûtait cher et prenait du temps. Et c’est précisément parce que c’était lent et coûteux que beaucoup de mauvaises idées n’arrivaient jamais jusqu’au client.
Le vibe coding a fait sauter ce filtre. Le chemin vers la production est devenu plus simple, plus rapide, plus accessible. Résultat, selon Gothelf : une pression écrasante pour sortir toujours plus de fonctionnalités et « voir ce qui marche », avec du code plus risqué qui n’a pas toujours atteint le niveau de qualité d’avant. Concrètement, cela veut dire :
Des failles de sécurité introduites par du code que personne n’a vraiment relu, notamment sur l’authentification et les accès à la base de données ;
Des données personnelles manipulées par des applications créées hors de tout cadre de conformité ;
De la dette technique qui s’accumule plus vite que les équipes ne peuvent la rembourser ;
Des bugs que plus personne ne sait corriger, parce que celui qui a « vibe codé » la fonctionnalité ne comprend pas le code généré.
Et le gain de productivité lui-même commence à se tasser. InfoQ rapportait en octobre 2026, à partir de l’enquête Developer Experience d’Atlassian, que la part des développeurs déclarant gagner plus de dix heures par semaine grâce à l’IA était tombée de 68 % à 26 % en un an : corriger ce que produit l’IA ajoute de la friction, et seuls 42 % des dirigeants disent disposer des bons indicateurs. Nous avions déjà décortiqué ce paradoxe dans notre article sur la productivité des développeurs avec l’IA : accélérer le code ne sert à rien si l’organisation autour ne suit pas.
Le vrai angle mort
La plupart des entreprises ne suppriment jamais rien.
En 2019, bien avant l’IA générative, le rapport Feature Adoption de Pendo estimait que 80 % des fonctionnalités d’un logiciel moyen étaient rarement ou jamais utilisées. Le vibe coding multiplie la capacité à livrer, pas la capacité à retirer.
Quand Gothelf demande à ses cousins à quelle fréquence leur entreprise supprime une fonctionnalité, la réponse est la même : jamais. L’un d’eux cite une fonctionnalité livrée sans soutien de l’équipe produit, qui rapporte un million de dollars de revenu récurrent par an. Elle coûte plus cher à maintenir qu’elle ne rapporte. Mais allez proposer de tuer une fonctionnalité « à un million ».
Chaque fonctionnalité livrée doit ensuite être maintenue, documentée, sécurisée, migrée, expliquée et vendue. Pour toujours. Que quelqu’un l’utilise ou non.
Tu veux plus d’analyses comme celle-ci, sans la hype IA ?
Chaque semaine, on décortique ce que l’IA change vraiment pour les managers et les organisations.
Discovery automatisée : quand l’IA trouve toutes vos idées « viables »
Le détail le plus inquiétant de l’article de Gothelf concerne la product discovery. Dans l’une des entreprises de ses cousins, des équipes ont construit des skills Claude censées « faire la discovery » à leur place. L’agent fouille les offres des concurrents, les données analytiques internes, les bases de verbatims clients et un stock de profils utilisateurs synthétiques, puis rend son verdict sur la viabilité de l’idée. Avec, en prime, des maquettes cliquables générées en quelques minutes.
Le verdict ? Gothelf le résume d’une parenthèse cinglante : l’idée est toujours viable. Évidemment. Un outil d’IA à qui l’on demande de justifier une idée trouvera toujours des arguments pour la justifier. Le vibe coding ne s’arrête donc plus au code : il s’étend à la décision elle-même. On ne valide plus une idée auprès de vrais utilisateurs, on la fait valider par une machine qui ne dit jamais non.
C’est exactement le piège que nous décrivions à propos du workslop, ce contenu généré par IA qui a l’air sérieux mais déplace le vrai travail sur quelqu’un d’autre. Ici, le « workslop » ne finit pas dans une boîte mail : il finit dans votre produit, sous les yeux de vos clients. Un MVP n’a de valeur que s’il sert à apprendre quelque chose. Un prototype qu’on livre sans hypothèse ni critère de succès n’est pas un MVP, c’est une fonctionnalité de plus à maintenir.
5 garde-fous pour qu’un projet vibe coding ne tourne pas au chaos
Gothelf ne plaide pas pour revenir en arrière. Les rôles évoluent, et c’est très bien. Il propose cinq principes pour que le rôle de builder réussisse. Les voici, avec notre lecture Corporate Mavericks.
1. Séparer le droit de construire du droit de livrer
Tout le monde peut coder un prototype. Parfait, laissez faire. Mais l’exposition aux clients suit un chemin précis : d’abord sur sa machine devant quelques utilisateurs potentiels, puis auprès d’utilisateurs internes ou d’une petite cohorte, et seulement ensuite en disponibilité générale. À chaque étape, on présente des preuves pour justifier d’aller plus loin. Le risque augmente uniquement quand l’évidence augmente.
2. Rien ne part en production sans hypothèse, critère de succès et date de revue
Avant de livrer, le builder écrit pourquoi il a construit cette fonctionnalité, qui va l’utiliser et quel impact il en attend pour l’utilisateur et pour le business. Le format importe peu. Ce qui compte : une date fixée pour revenir dessus et décider de tuer, pivoter ou persévérer. C’est la logique de « Who does what by how much? », le livre de Gothelf sur les OKR : mesurer un changement de comportement, pas une livraison.
3. Organiser une revue de retrait chaque trimestre
Une fois par trimestre, l’équipe passe en revue ce qui a été livré, comment ça a performé, ce que ça coûte à construire et à maintenir. Tout ce qui n’a pas atteint ses critères de succès, ou qui n’a plus de propriétaire, doit être corrigé, réattribué ou retiré de la production. Supprimer devient un acte normal de gestion, pas un drame politique.
4. Construire avec l’ingénierie des chemins de déploiement rapides et guidés
Si la mise en production reste un chemin séparé, il doit être rapide. L’objectif : qu’un builder conforme passe les étapes en quelques heures, ou reçoive immédiatement un retour exploitable. Tests automatiques, contrôles de sécurité, vérification de conformité intégrés au pipeline. Sinon, les gens contourneront le process, et vous aurez recréé du shadow IT avec un éditeur de code en plus.
5. Arrêter de mesurer le succès au nombre de fonctionnalités livrées
Si vos builders sont évalués sur le volume livré, vous aurez du volume, et donc encore plus de déchets générés par IA en production. Tenez-les responsables de ce qui compte vraiment : le changement de comportement des clients, l’impact business, la stabilité. Ce qui aurait toujours dû être la règle.
Ce que le vibe coding change vraiment pour le management
Le réflexe de beaucoup de directions sera de répondre au chaos par un comité. Un comité d’architecture, un comité IA, un comité de validation des fonctionnalités. Mauvaise idée. Vous aurez la lenteur de l’ancien monde sans en avoir la qualité, et les équipes vibe coderont quand même, en douce. Nous l’avons montré à propos de la bureaucratie en entreprise : chaque règle ajoutée ralentit, sans forcément protéger.
Le vrai sujet est ailleurs. Grâce au vibe coding, le coût de fabrication s’effondre, donc la rareté se déplace. Ce qui devient rare, c’est le jugement : savoir quoi construire, pour qui, et quand s’arrêter. Trois conséquences pour les managers :
La responsabilité doit être explicite. Chaque fonctionnalité a un propriétaire humain nommé, qui répond de son succès comme de son retrait. Même principe que pour les agents IA en entreprise : pas de propriétaire, pas de production.
Les compétences techniques ne disparaissent pas, elles changent de place. Vos développeurs deviennent les garants de la qualité, de la sécurité et de l’architecture. Les débutants et les profils non techniques ont besoin d’une formation structurée pour comprendre ce qu’ils livrent : lire un diff, repérer une donnée sensible, savoir quand demander une revue.
La discovery redevient un travail humain. Utiliser l’IA pour préparer des entretiens ou synthétiser des retours, oui. Lui déléguer la décision de ce qui mérite d’exister, non. Le contact avec de vrais utilisateurs reste le seul antidote à la machine qui dit oui à tout.
Autrement dit : le vibe coding n’est pas un problème d’outillage. C’est un test grandeur nature de la maturité produit de votre organisation. Les entreprises qui savaient déjà dire non vont décoller. Celles qui livraient pour livrer vont simplement livrer plus vite dans le mur.
Par où commencer lundi matin ?
Pas besoin d’un grand programme de transformation. Quatre gestes simples suffisent pour reprendre la main sur votre projet vibe coding :
Faites l’inventaire. Combien de fonctionnalités ou d’applications ont été créées par IA ces six derniers mois ? Qui en est propriétaire ? Qui les utilise ?
Ajoutez trois lignes obligatoires à toute demande de mise en production : hypothèse, critère de succès, date de revue.
Bloquez une première revue de retrait dans le calendrier du trimestre, avec un objectif explicite : supprimer au moins une fonctionnalité.
Changez un indicateur. Remplacez « nombre de fonctionnalités livrées » par un indicateur de résultat client dans vos revues d’équipe.
Le vibe coding est une chance réelle : il permet de tester plus d’idées, plus vite, avec moins de gaspillage en amont. À condition de ne pas confondre la capacité de livrer avec l’obligation de livrer.
Questions fréquentes sur le vibe coding en entreprise
L’expression a été popularisée en février 2025 par Andrej Karpathy, cofondateur d’OpenAI. Elle décrit une façon de coder où l’on décrit ce que l’on veut en langage naturel et où l’on se laisse porter par les propositions de l’IA, en testant le résultat plutôt qu’en écrivant et relisant chaque ligne de code.« Vibe » signifie ambiance, ressenti. Dans vibe coding, l’idée est de programmer à l’intuition : on suit le ressenti du résultat obtenu plutôt qu’une conception technique détaillée. C’est efficace pour un prototype, risqué pour une application en production.Séparez le droit de construire du droit de livrer : tout le monde peut prototyper, mais la mise en production exige une hypothèse, un critère de succès, un propriétaire nommé et une date de revue. Ajoutez une revue trimestrielle pour retirer ce qui ne sert pas, et mesurez l’impact client plutôt que le nombre de fonctionnalités.Il n’y a pas de meilleur outil universel. Cursor, Claude Code ou GitHub Copilot conviennent aux développeurs qui travaillent sur du code existant, tandis que des générateurs d’applications web visent les profils non techniques. Pour une entreprise, le critère décisif n’est pas l’outil mais le cadre : revue de code, sécurité, conformité et propriétaire de chaque fonctionnalité.Pas par défaut. Le code généré peut contenir des failles de sécurité, mal gérer l’authentification ou exposer des données personnelles. Il faut l’encadrer avec des tests automatisés, des contrôles de sécurité dans le pipeline de déploiement et une revue humaine avant toute exposition aux clients.Non. Il déplace leur rôle. Les développeurs deviennent les garants de l’architecture, de la qualité et de la sécurité, et ils restent indispensables pour comprendre, corriger et maintenir le code généré. Ce qui devient rare, ce n’est pas la capacité à produire du code, c’est le jugement sur ce qui mérite d’être construit.
L’IA sans le bullshit, chaque semaine
Une newsletter pour les managers qui veulent profiter de l’IA sans transformer leur produit en cimetière de fonctionnalités. Zéro hype, que du concret.