Collins Dictionary en a fait son mot de l’année 2025. Andrej Karpathy a popularisé le terme en février — et en quelques mois, des armées de product managers se sont mises à « vibe-coder » des prototypes en une après-midi.

Je vais être honnête : c’est grisant. J’ai passé des années à voir des équipes coincées sur des cycles de dev de trois mois pour livrer des features qui auraient mérité d’être testées en une semaine. Alors quand un PM peut sortir un prototype fonctionnel entre deux réunions — ou pendant une réunion, je ne juge pas — ça a de quoi faire briller les yeux.

Mais voilà le hic.

Le vibe coding rend la construction plus rapide. Il ne rend pas la réflexion plus intelligente. Et quand tout le monde construit plus vite, la seule question qui reste sur la table c’est : est-ce que vous construisez la bonne chose ?

La réponse, pour la plupart des équipes que je croise, c’est non. Et le vibe coding n’y changera rien.

Qu’est-ce que le vibe coding (et pourquoi ça excite tout le monde)

Le principe est simple. Au lieu d’écrire du code ligne par ligne, vous décrivez ce que vous voulez en langage naturel. L’IA génère le code. Vous itérez par la conversation. Karpathy décrivait ça comme un état où « vous voyez des choses, vous dites des choses, vous exécutez des choses, et ça marche — la plupart du temps ».

Pour un product manager, la promesse est énorme. Fini les semaines d’attente pour qu’un développeur touche à un prototype. Fini les wireframes statiques que personne ne comprend. Vous pouvez mettre un truc qui ressemble à un vrai produit entre les mains d’un utilisateur en une journée.

Ça s’appelle le vibe coding, et des outils comme Cursor, Lovable, Bolt et Replit le rendent accessible à n’importe quel PM — même sans background technique.

Un super pouvoir… ou une hyperbole ?

Soyons honnêtes deux secondes : c’est un vrai progrès. J’ai vu des PM construire en quatre heures des prototypes qui auraient pris quatre semaines autrement. Des gens que je respecte parlent même de lancer des MVP complets en production via le vibe coding — et il y a des réussites qui tiennent la route.

Mais voilà où le bât blesse.

Le problème que personne ne veut regarder en face

Le vibe coding accélère l’exécution. Il n’améliore pas la direction. Et c’est là que le bât blesse.

Pendant des années, le problème numéro un des équipes produit n’était pas la vélocité. C’était de construire des trucs que personne n’utilisait. Les feature factories — ces usines à fonctionnalités qui tournent à plein régime sans jamais vérifier si ce qu’elles produisent a de la valeur — existaient bien avant l’IA. Le vibe coding, dans ce contexte, ne résout pas le problème. Il le rend juste plus efficace.

La feature factory dopée aux stéroïdes

Imaginez une équipe produit qui priorise déjà mal. Qui livre des fonctionnalités parce que « le CEO l’a demandé » ou parce que « c’est dans la roadmap depuis six mois ». Donnez à cette équipe un marteau-pilon vibe-codé, et elle va construire les mauvaises choses plus vite et plus joliment qu’avant.

Ce n’est pas une théorie. C’est ce qui se passe.

J’ai un exemple qui me trotte dans la tête. Un PM chez une scale-up française a passé deux jours à vibe-coder un prototype. Validé en interne. Lancé en production en deux semaines. Résultat trois mois plus tard : zéro adoption. Zéro. Pas un utilisateur. Pourquoi ? Personne n’avait parlé aux vrais utilisateurs avant. Le prototype était joli, rapide, fonctionnel — et complètement à côté de la plaque.

Le vibe coding a transformé le « non » en « non, mais plus vite ».

30% de taux de succès : le grand tri de 2025

Les chiffres parlent d’eux-mêmes. Le rapport 2025 de ProductPlan montre que 92% des organisations sont engagées dans l’IA, mais seulement 46% l’ont adoptée pour au moins un cas d’usage concret. Et parmi les features IA lancées, seulement 30% environ ont réellement rencontré leur marché.

On appelle ça le « Great AI Cleanup » — la grande lessive des fonctionnalités IA que les entreprises ont bâclées dans l’urgence. Les unes après les autres, les boîtes taillent dans leurs roadmaps IA, retirent des features qui n’ont jamais été utilisées, et réévaluent ce qui mérite vraiment d’être construit.

Ce nettoyage n’est pas un échec de l’IA. C’est un échec de la décision produit. On a confondu « on peut le construire » avec « on devrait le construire ». Et le vibe coding a aggravé la confusion.

On ne vibe code pas une conversation client

La vérité, c’est que rien dans le vibe coding ne remplace une conversation avec un utilisateur. L’IA ne peut pas s’asseoir dans le bureau de votre client, capter le truc qu’il ne dit pas, comprendre pourquoi il contourne votre feature depuis six mois, ou sentir le moment où une question anodine révèle un problème qu’il n’avait jamais verbalisé.

Je reviens toujours à Teresa Torres sur ce point. Dans son travail sur la découverte continue, elle dit que la qualité de vos décisions produit dépend de la qualité de vos opportunités. Traduction : les bonnes idées, on ne les trouve pas en tapant des prompts. On les trouve en regardant des utilisateurs galérer, en écoutant ce qu’ils ne disent pas, en se plantant sur ses hypothèses jusqu’à ce que les bonnes émergent.

Le vibe coding peut vous aider à prototyper une solution en une heure. Mais si vous avez zappé la partie « quel problème on résout, et pour qui », vous venez de construire une solution rapide à un problème qui n’existe pas.

Vibe coding oui, mais avec des garde-fous

Je ne suis pas contre le vibe coding. Je suis contre le vibe coding sans réflexion. Utilisé correctement, c’est un outil formidable. La question, c’est comment.

Pour le prototypage, pas pour la production

La règle numéro un : le vibe coding est excellent pour explorer, terrible pour scaler.

Si vous testez une hypothèse, un prototype vibe-codé est parfait. Vous voulez valider qu’un parcours utilisateur fonctionne, qu’une proposition de valeur tient la route, qu’un flux de paiement est compréhensible ? Lancez-le. Testez-le. Itérez.

Mais le jour où ce prototype doit gérer des millions d’utilisateurs, respecter des contraintes de sécurité et s’intégrer à un SI legacy, remplacez-le par du code écrit par des humains. Les outils de vibe coding ne sont pas conçus pour la production critique. Et croire le contraire, c’est jouer à la roulette russe avec la fiabilité de votre produit.

La découverte reste votre seul avantage concurrentiel

Dans un monde où tout le monde vibe code, la vraie différence ne sera pas la vitesse d’exécution. Ce sera ce que vous décidez de construire.

L’IA peut générer un prototype en minutes. Elle ne peut pas décider si votre produit doit résoudre le problème A ou le problème B. Elle ne peut pas sentir que votre marché a changé parce que votre concurrent vient de pivoter. Elle ne peut pas évaluer le risque politique de lancer une feature qui cannibalise votre propre revenu récurrent.

C’est votre job. Et c’est pour ça que le product management reste — et restera — un métier profondément humain.

Ce que ça change pour le métier de PM

Si vous êtes product manager en 2025, le paysage a changé. Et pas qu’un peu.

Le grand écart du marché de l’emploi

Les données de Lenny’s Newsletter et du Product Management Hiring Trends Report le confirment : le marché du PM se polarise. D’un côté, les « Builder PMs » — ceux qui savent prototyper, coder un minimum avec l’IA, comprendre les metrics, et livrer seuls en une semaine. De l’autre, les « Coordinator PMs » — ceux qui écrivent des specs, attendent un designer, un analyste et trois ingénieurs, et déplacent du travail entre des réunions. C’est un vrai sujet de product management pour les années à venir. C’est exactement ce dont on débat dans les cercles comme le silicon valley product group : est-ce que le métier de PM devient un métier de « maker » ou de « manager » ?

Même titre de poste. Deux décennies d’écart.

Les entreprises embauchent massivement les premiers et laissent les seconds sur le carreau. Aux États-Unis, 75% des employeurs disent ne pas trouver les candidats dont ils ont besoin. Pas parce qu’il n’y a pas de PMs — parce que les PMs disponibles ne sont pas ceux qu’ils recherchent.

Le freelance head of product comme réponse

C’est là que le consulting produit prend tout son sens. Les entreprises qui traversent cette transition ont besoin de product leaders capables de poser un diagnostic stratégique en quelques semaines, pas en six mois. Un freelance head of product — ou un freelance product manager senior avec une vision stratégique — peut venir challenger les hypothèses, poser les bonnes questions, et construire une culture de découverte en quelques semaines. C’est la solution la plus pragmatique que je vois sur le marché des produit digitaux aujourd’hui.

Pas pour remplacer l’équipe. Pour lui donner la bonne direction.

Alors, on vibe code ou pas ?

Bien sûr que oui. Franchement, ce serait idiot de s’en priver. Le vibe coding est un outil de ouf pour le prototypage rapide, les tests d’hypothèses, la validation de parcours. Tout PM qui ne l’essaie pas en 2025 rate un levier puissant.

Mais pour l’amour de tout ce qui est saint, arrêtez de confondre l’outil avec la stratégie.

Vibe-coder un prototype ne remplace pas une discovery bien faite. Construire vite ne remplace pas savoir quoi construire. Et quand tout le monde construit plus vite, la seule chose qui vous différencie — vraiment — c’est votre capacité à prendre de meilleures décisions. Pas plus rapides. Meilleures.

Le vibe coding ne vous sauvera pas de construire le mauvais produit.

Votre jugement, votre curiosité et votre discipline à parler aux vrais utilisateurs — si.