Le vibe coding est déjà obsolète — et c'est une excellente nouvelle pour les product managers
En 2026, Andrej Karpathy — celui qui a popularisé le terme « vibe coding » — est monté sur scène pour le déclarer obsolète. Ce qu’il a proposé à la place, il l’a appelé agentic engineering, et il l’a décrit comme une liste d’activités : écrire des specs de conception, superviser des plans, inspecter des diffs, écrire des tests, construire des boucles d’évaluation (eval), gérer les permissions, préserver la qualité.
Relisez cette liste en retirant les termes propres à l’ingénierie. Décider ce qui devrait être construit. Vérifier si le résultat correspond à l’intention. Définir ce que « suffisamment bon » signifie et refuser de livrer en dessous. Ce n’est pas une nouvelle discipline. Comme l’a dit Jeff Gothelf : la version qui exige du jugement, c’est le travail — ça l’a toujours été. L’IA n’a fait qu’éliminer les endroits où on pouvait se cacher pour l’esquiver.
C’est le changement le plus important pour quiconque construit des produits aujourd’hui, et il pointe dans une direction que la plupart des gens trouvent contre-intuitive.
La compétence qui survit, ce n’est pas le code
Pendant dix ans, « apprendre à coder » était le conseil universel pour quiconque avait une idée de produit. En 2026, ce conseil s’est discrètement inversé. Quand des agents IA peuvent transformer un problème clairement énoncé en logiciel fonctionnel, la documentation cesse d’être le travail — l’intention, la clarté et le jugement deviennent le travail. Le secteur a un nom pour les personnes qui comptent maintenant, et ce n’est pas « ingénieur en prompt ». Le constat de Product School pour cette année est sans appel : les product managers IA sont les PMs qui comptent en 2026.
La mécanique concrète le confirme. À travers tout le secteur, le consensus sur ce que fait réellement un PM AI-native s’est condensé en trois verbes :
- Décrire ce que vous voulez avec suffisamment de précision pour qu’un agent capable puisse agir dessus.
- Décomposer le problème en morceaux assez petits pour être vérifiés.
- Juger si le résultat correspond à l’intention — et décider ce qui se passe dans les 15 % où ce n’est pas le cas.
Aucun de ces trois éléments ne consiste à coder. Les trois sont de la gestion de produit.
Pourquoi ne pas savoir coder peut être un avantage
Voici la partie qui semble fausse et ne l’est pas. Les personnes qui savent coder ont en tête une estimation permanente de à quel point c’est difficile à construire. Cette estimation est utile quand on est celui qui construit — et un handicap quand on décide ce qui devrait exister. L’idée se fait élaguer avant même d’être exprimée, façonnée par le coût d’implémentation plutôt que par la valeur utilisateur.
Si vous ne savez pas coder, vous n’avez pas ce réflexe. Il ne vous reste que les seules questions qui comptent au départ : de quoi l’utilisateur a-t-il réellement besoin, et cette expérience est-elle juste ? Votre travail est alors de le dire clairement. Et « exprimer l’idée clairement » est la compétence fondamentale la plus ancienne du product manager.
Ce n’est pas un plaidoyer pour l’ignorance. C’est un constat : le goulot d’étranglement a changé de place. La ressource rare n’est plus la vitesse de frappe dans un éditeur de texte ; c’est la clarté de ce que vous demandez.
« Dites-le, l’IA le construit » est une méthode, pas une intuition
Le problème, c’est que le vibe coding a mérité son faire-part pour une bonne raison. Quand on prompt sans rigueur, chaque exécution dérive : les designers ont remarqué que les prototypes IA occupent désormais l’espace des wireframes, mais chaque run du même prompt produit quelque chose de subtilement différent — une dérive sémantique qui s’amplifie rapidement. Une intention floue en entrée, un produit incohérent en sortie.
La réponse n’est donc pas de « mieux forcer » son prompt. C’est de travailler avec discipline. Cette discipline, c’est ce que nous appelons DO AI PM, et elle repose sur quelques engagements concrets :
- Haute fidélité dès le départ. Oubliez le wireframe. Construisez la vraie chose fonctionnelle — contenu réel, vrais états (chargement, vide, erreur, succès), vraies interactions — et vérifiez-la en la faisant tourner réellement. Un prototype qui fonctionne surpasse à chaque fois un prototype décrit, y compris dans la salle où se prend la décision.
- Cinq phases, petits pas. Découvrir → Définir → Concevoir → Développer → Valider. En phase Définir, faites d’abord poser des questions à l’IA avant qu’elle rédige la spec. En phase Développer, changez une seule chose à la fois.
- Un filet de sécurité. Pas de vraies clés secrètes ni de données de production dans un prototype. C’est l’humain qui appuie sur les boutons irréversibles — publier, supprimer, payer. On ne touche pas à la production. Quand on doute, on demande.
Cette dernière liste, c’est la différence entre « j’ai eu de la chance avec un prompt » et « je peux recommencer lundi matin ».
La preuve, c’est le travail
Une méthode qui ne fait que s’expliquer ne vaut rien. Tout ici découle de vrais produits, tous construits de cette façon avec Claude Code : SoloMD (un éditeur Markdown), Unterm (un terminal que les agents IA peuvent piloter), unfetch (un gestionnaire de téléchargements pour humains et IA), StoryAlter (un compagnon d’écriture IA), et Unflick (un lecteur multimédia pour humains et IA). Ce site même — huit langues, ce blog, les présentations — a été « dit » pour exister de la même façon. Pas une ligne n’a été écrite à la main.
La méthode explique les œuvres ; les œuvres prouvent la méthode.
Karpathy avait raison : le vibe coding est terminé. Ce qui le remplace n’est pas une forme d’ingénierie plus difficile — c’est la discipline de décider juste et de décrire clairement. Ça a un nom, et c’est un bon moment pour exercer ce métier.
Si vous voulez ressentir concrètement ce que « Dites-le, l’IA le construit » veut dire, commencez par le centre de méthode.
Pour aller plus loin
Discussion