Le PM qui build : prototypage IA, vibe coding et specs exécutables, PM Pathfinder

Le terme qui a tout changé

Le 2 février 2025, Andrej Karpathy, co-fondateur d'OpenAI, ex-directeur de l'IA chez Tesla, poste sur X ce qui ressemble à une blague de vendredi soir :

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. […] I ask for the dumbest things like 'decrease the padding on the sidebar by half' because I'm too lazy to find it. I 'Accept All' always, I don't read the diffs anymore. […] It's not too bad for throwaway weekend projects." [1]

Karpathy lui-même qualifiera ce tweet plus tard de "shower of thoughts throwaway" [1]. Neuf mois après, Collins Dictionary le nomme Mot de l'Année 2025 [2]. Le terme a traversé le cycle entier, de la provocation à l'institution, en moins d'un an.

Ce qui m'intéresse ici, ce n'est pas le terme. C'est ce qu'il révèle sur le rôle de Product Manager.

La frontière qui bouge

Commençons par un chiffre à regarder de près : selon Jared Friedman, managing partner chez Y Combinator, environ 25 % des startups de la promotion Winter 2025 avaient des codebases composées à 95 % de code généré par IA [3]. Ce n'est pas une anecdote : c'est une donnée de marché.

En parallèle, Bolt.new, l'un des outils de prototypage phares, a atteint 4 millions de dollars d'ARR en trente jours après son lancement en octobre 2024, puis 40 millions d'ARR en cinq mois [4]. Lovable (anciennement GPT Engineer) a dépassé les 100 millions d'ARR en huit mois, ce qui en ferait la croissance la plus rapide jamais enregistrée pour une entreprise de logiciel [5]. v0 de Vercel aurait atteint 4 millions d'utilisateurs uniques et génère sept applications par seconde [6].

Ces chiffres décrivent un marché, pas des gadgets. Et 67 % des utilisateurs de Bolt.new ne sont pas des développeurs [4]. 75 % des utilisateurs de Replit déclarent ne jamais écrire de code : ils décrivent ce qu'ils veulent, l'IA construit [7].

La frontière entre "définir" et "construire" est en train de se déplacer. Et le PM est exactement assis sur cette frontière.

Mon point de vue : La question n'est pas "est-ce que le PM doit coder ?" La vraie question est : jusqu'où peut-on aller en mode prompt-as-spec avant que le code produit devienne un passif plutôt qu'un actif ? La réponse détermine où se situe le quality gate humain. Et c'est une décision de méthode, pas de tooling.

Ce que les outils permettent réellement

Le paysage se structure autour de deux catégories.

Les générateurs full-stack conversationnels, Lovable, Bolt.new, Replit Agent, partent d'une description en langage naturel et produisent une application déployée, front et back, sans sortir du navigateur. Lovable se positionne explicitement comme un "co-fondateur IA" pour les fondateurs non-techniques [5]. Replit indique que 58 % de ses business builders ne sont pas ingénieurs, dont 7 % de Product Managers [7].

Les éditeurs IA pour profils semi-techniques, v0 (Vercel), Cursor, s'adressent à quelqu'un qui sait ce qu'est un composant React ou qui est à l'aise avec une pull request. v0 génère des composants UI à partir de prompts en langage naturel et les connecte désormais directement à des repos GitHub existants [6]. Cursor reste d'abord un outil de développeur, même si les PMs techniques l'utilisent.

Pour un PM, la distinction est importante. Les générateurs conversationnels abaissent radicalement la barrière d'entrée pour produire un prototype cliquable ou un POC fonctionnel. Les éditeurs IA amplifient la productivité mais supposent un niveau de confort technique préexistant.

Ce que ça change concrètement dans le quotidien PM

Alan Wright, Head of Product chez Climate Policy Radar (ex-GOV.UK, BBC), documente ses expériences sur plusieurs mois avec Lovable, Bolt, Replit et Cursor [8] :

Construction d'un "climate policy counter", outil de visualisation de données interactif résolvant un problème utilisateur connu, sans impliquer d'ingénieur.
Merge de quatre fichiers JSON de 2 000 lignes avec déduplication, en quelques minutes.
Croisement d'analytics produit avec des métadonnées documents pour identifier les types de contenus les plus visités, validation d'hypothèses avant d'investir du temps engineering.

Sa conclusion opérationnelle : "Being able to do these little things myself makes me so much faster." [8] Mais il est délibérément conservateur sur les features user-facing : il a plus de bons retours sur les outils internes que sur les capacités exposées aux utilisateurs finaux.

Nick Stanchenko, PM chez Snowplow (avec un background d'ingénieur), a poussé en production une réécriture complète de l'UI d'un outil utilitaire interne via des prompts générés entre deux réunions [9]. Il documente aussi les limites : les détails fins d'UI (alignement de bordures, correspondance de tailles de police) coincent l'IA, qui produit des "solutions absurdes" et peut "gaslighter" sur la question de savoir si deux éléments sont identiques. Sa conclusion : l'IA vaut pour la recherche, les prototypes, et les correctifs UX mineurs, mais vibe-coder une feature complète distrait le PM de son travail central.

Mon point de vue : Ces deux retours convergent vers le même pattern : l'IA est excellente pour réduire le coût de validation d'une hypothèse (prototype, POC, croisement de données). Elle est risquée quand elle devient le chemin vers la production, surtout sur des surfaces exposées aux utilisateurs. Le PM qui build doit savoir distinguer ces deux cas avant de commencer, pas après.

Les specs qui deviennent exécutables

L'un des glissements les plus silencieux de cette période : le prompt est en train de devenir une spec.

Dans le flow "vibe coding", la spécification fonctionnelle n'est plus un document de 15 pages dans Confluence. C'est la séquence de prompts qui a produit le prototype. C'est ce que les chercheurs commencent à appeler des "specs exécutables" : des descriptions en langage naturel suffisamment précises pour qu'un agent les traduise directement en code fonctionnel.

Le PM qui sait formuler un prompt précis, qui peut itérer dessus, qui comprend ce que la sortie doit démontrer (et ce qu'elle ne démontre pas), ce PM a un avantage réel. Pas parce qu'il code, mais parce qu'il contrôle le cycle de définition-validation sans dépendre d'un tiers à chaque itération.

La compétence clé ici n'est pas technique au sens traditionnel. C'est la clarté de l'intention + la rigueur de l'évaluation de la sortie. Ce qui est, au fond, exactement ce qu'on attend d'un bon PM.

Où le quality gate devient non-négociable

C'est là que l'enthousiasme mérite d'être tempéré par les données.

Le rapport Veracode 2025 sur la sécurité du code GenAI, testé sur plus de 100 LLMs dans 4 langages, indique que le code IA est 2,74 fois plus susceptible d'introduire des vulnérabilités de type XSS (cross-site scripting) que le code humain, et que des failles sont présentes dans 45 % des échantillons testés [10]. La Cloud Security Alliance note que les commits assistés par IA exposent des secrets (clés API, credentials) à plus du double du taux des commits humains : 3,2 % contre 1,5 % [11].

Un scan de 5 600 applications "vibe-codées" a révélé plus de 2 000 vulnérabilités et plus de 400 secrets exposés [12]. Ces chiffres ne parlent pas de code expérimental en sandbox : ils parlent d'applications déployées.

Sur la dette technique, les données sont comparables. Des sources sectorielles estiment que sur environ 10 000 startups ayant utilisé des outils de vibe coding pour construire des apps en production, plus de 8 000 ont eu besoin d'un rebuild partiel ou d'un rescuing engineering d'ici mi-2026, pour un coût moyen estimé entre 50 000 et 500 000 dollars par entreprise [12]. Le taux de rework dans les équipes utilisant massivement ces outils augmenterait de 30 à 60 % dans les six mois suivant l'adoption.

La racine du problème est structurelle, pas accidentelle : Karpathy lui-même l'écrit dans son tweet fondateur, "The code grows beyond my usual comprehension" [1]. Le vibe coding produit du code qui fonctionne, mais que le PM (ou parfois même l'ingénieur) ne comprend pas réellement. Quand ça casse en production, personne n'a la connaissance pour déboguer vite.

Mon point de vue : Le quality gate humain n'est pas une option de prudence rétroactive. C'est une décision d'architecture qui se prend avant de commencer à builder. La question n'est pas "est-ce que ce prototype fonctionne ?" mais "est-ce que je suis en capacité d'assumer ce qui est dans cette boîte noire ?" Pour un POC interne non critique : la réponse peut être oui sans grande revue. Pour une feature user-facing ou une surface qui touche des données sensibles : la réponse est presque toujours non, sans revue de code dédiée.

L'impact réel sur le rôle PM

Les données de marché pointent vers une bifurcation. Le rôle PM est en train de se diviser en deux archétypes distincts [13] :

Le Builder-PM : à l'aise avec les outils IA, capable de produire des prototypes, de valider des hypothèses sans dépendre du cycle engineering, de comprendre suffisamment l'output technique pour évaluer ce qu'il délègue. Les salaires des AI PM roles atteignent 245 000 dollars en moyenne aux États-Unis contre 123 000 pour les PM traditionnels [13].

L'Integrator-PM : focalisé sur l'alignement stratégique, la gestion de la complexité organisationnelle, la synthèse des insights utilisateurs à grande échelle. Compétences relationnelles et système-level thinking au premier plan.

Le généraliste intermédiaire, le PM "classique" sans différenciation technique ni positionnement stratégique fort, est le profil le plus exposé.

LinkedIn a remplacé son programme APM (Associate Product Manager) par un programme "Product Builder" formant des généralistes simultanément en product, design et engineering [13]. Ce n'est pas un signal anodin venant de l'une des plus grandes plateformes mondiales de carrières.

L'étude Productboard 2025 (379 professionnels produit) indique que 94 % des PMs utilisent l'IA fréquemment, et que près de la moitié l'ont intégrée profondément dans leurs workflows quotidiens [14]. Les deux compétences les plus citées comme prioritaires pour les 2-3 prochaines années : la maîtrise des données et la synthèse des insights utilisateurs [14]. Pas le prompt engineering. Pas le code.

Ce qui suggère une chose : les PMs qui utilisent les outils IA de façon productive ne sont pas ceux qui "vibent" le plus fort. Ce sont ceux qui savent le mieux ce qu'ils cherchent à apprendre, et qui utilisent l'IA pour réduire le coût de cette découverte.

Mon point de vue : La frontière PM/engineering ne disparaît pas, elle se déplace. Et la compétence qui détermine de quel côté vous vous trouvez n'est pas "est-ce que je sais coder ?" C'est "est-ce que je sais évaluer ce que l'IA produit ?" Un PM qui génère un prototype sans savoir le critiquer a juste externalisé sa pensée à un outil. Un PM qui sait formuler l'intention, évaluer la sortie, et décider où placer le gate humain, celui-là a reconstruit une méthode, pas juste adopté un outil.

De la théorie à la pratique : les cinq gestes du PM qui build

Tout ce qui précède reste abstrait tant qu'on ne l'a pas posé sur un clavier. J'ai conçu et animé pour la formation Noé deux ateliers Tech & Claude Code où des PMs, majoritairement non-techniques, passent de la lecture d'API au déploiement en production en deux jours. Ce que j'en retiens tient en cinq gestes concrets, ordonnés du moins au plus engageant. Aucun ne demande de savoir coder. Tous demandent de savoir décider.

Geste 1, interroger une API plutôt que de subir sa doc

Premier atelier, premier réflexe : avant de builder, comprendre ce que la technique permet. On donne à un PM le brief d'un catalogue d'abonnements (Free, Pro, Enterprise, plus un essai gratuit de 14 jours et une remise annuelle de 20 %) et on lui demande d'explorer l'API Stripe avec Claude, sans écrire une ligne de code. En vingt minutes, il sait ce qu'est un objet Price, pourquoi un plan gratuit n'a souvent pas besoin d'abonnement Stripe du tout, et quel est l'arbitrage entre coder la remise dans le prix ou passer par un coupon. Il arrive en réunion eng avec des décisions, pas des questions. La doc technique cesse d'être un mur : elle devient une conversation.

Geste 2, se construire une lecture d'architecture

On monte d'un cran : à partir d'une user research (« les gens quittent la page restaurant parce qu'ils ne connaissent pas le délai de livraison »), le PM utilise Claude pour esquisser lui-même une architecture de la feature ETA, produire un premier exemple de requête/réponse d'API, et surtout formuler trois ou quatre questions précises pour son lead tech. Le livrable n'est pas le schéma. C'est la capacité à entrer dans la discussion technique avec un point de vue, à repérer les risques d'architecture avant qu'ils ne deviennent des tickets.

Geste 3, demander au code ce qu'il fait vraiment

Deuxième atelier, on bascule dans Claude Code sur une vraie codebase que le PM n'a jamais vue. L'exercice est brutalement révélateur : on pose une question métier en apparence anodine (« pourquoi cette utilisatrice obtient le plan Progression et pas Elite ? ») et on découvre, en interrogeant le code, une logique de scoring cachée que personne n'avait documentée. C'est le geste le plus sous-estimé : le code est la source de vérité la plus proche du produit réel. Un PM qui sait l'interroger connaît ses edge cases mieux que sa spec.

Geste 4, corriger un bug de bout en bout, Pull Request comprise

Ici le PM exécute le workflow développeur complet, piloté par lui : repérer un bug dans l'app, créer une branche, décrire précisément le correctif à Claude Code (jamais « corrige les bugs », toujours « le sous-total ignore la quantité, ligne 3 de Cart.jsx »), commiter, pousser, et ouvrir une Pull Request avec Claude en reviewer senior. Le point pédagogique qui fait mouche : la qualité du correctif dépend de la précision de la description, exactement comme avec un ingénieur humain. Le prompt flou produit du code flou. Le PM apprend à cadrer, pas à coder.

Geste 5, de la spec au déploiement

Le geste le plus complet, et celui qui boucle tout l'article. Le PM écrit une spec en markdown, la donne à Claude Code en mode plan, itère sur le plan avant qu'une ligne soit écrite, lance le build, puis déploie sur Vercel pour obtenir une URL publique testable par de vrais utilisateurs. C'est la spec exécutable de la section précédente, rendue littérale : l'intention écrite avec assez de rigueur pour qu'un agent la traduise en produit vivant, et le quality gate humain matérialisé par la revue du plan avant l'exécution.

Mon point de vue : Ces cinq gestes ne forment pas une échelle vers « devenir développeur ». Ils forment une échelle vers l'autonomie de décision. À chaque marche, le PM réduit sa dépendance à un intermédiaire pour comprendre, valider ou tester, sans jamais se substituer à l'ingénierie sur ce qui compte : la robustesse, la sécurité, la maintenabilité. Ce que la formation rend évident, c'est que la ligne de partage n'est pas technique. Elle est méthodologique. Le PM qui progresse sur cette échelle n'apprend pas à coder ; il apprend à savoir précisément ce qu'il demande, et à évaluer ce qu'on lui rend.

Conclusion : méthode d'abord, outil ensuite

Le vibe coding est le révélateur, pas le sujet. Ce qu'il révèle, c'est que la vitesse de production n'a jamais été le vrai bottleneck du Product Management. Le bottleneck, c'est la clarté de l'intention et la rigueur de la validation.

Les outils IA compressent le temps entre "idée" et "prototype fonctionnel" de façon spectaculaire. Mais ils amplifient aussi bien les bonnes intentions que les mauvaises : un PM qui ne savait pas ce qu'il cherchait à tester sans IA ne le sait toujours pas avec. Il produit juste plus vite quelque chose qui ne répond pas à la bonne question.

Le PM qui build, dans ce cadre, n'est pas celui qui remplace l'ingénieur. C'est celui qui est capable d'accélérer le cycle de discovery-validation, de livrer un prototype de qualité suffisante pour l'objectif (pas plus), et de poser le quality gate humain au bon endroit, avant que la dette technique et les vulnérabilités de sécurité ne deviennent le problème de quelqu'un d'autre.

C'est une compétence de méthode. Et elle précède toujours le choix de l'outil.

Sources

Andrej Karpathy, Tweet original sur le "vibe coding" (X, 2 février 2025), Origine du terme, définition fondatrice, citation directe.
Collins Dictionary, Word of the Year 2025, Confirmation du statut WOTY 2025 pour "vibe coding".
TechCrunch, A quarter of startups in YC's current cohort have codebases that are almost entirely AI-generated (6 mars 2025), Chiffre Jared Friedman/YC W25 sur les codebases 95 % IA.
Indie Hackers, The story behind Bolt.new reaching $40M ARR in 5 months, Croissance ARR Bolt.new, statistique des 67 % d'utilisateurs non-développeurs.
TechCrunch, Eight months in, Swedish unicorn Lovable crosses the $100M ARR milestone (23 juillet 2025), Croissance Lovable, vitesse de passage à 100M ARR.
VentureBeat, Vercel rebuilt v0 to tackle the 90 percent problem, Fonctionnalités v0, statistique des 4M utilisateurs et 7 apps/seconde.
Index.dev, Replit Usage Statistics 2026, Données sur la composition non-développeur de la base utilisateurs Replit.
Alan Wright, Vibe coding as a product manager: risks and opportunities (6 avril 2026), Retour d'expérience détaillé d'un Head of Product sur Lovable, Bolt, Replit, Cursor.
Nick Stanchenko, Product manager attempts vibe-coding straight to production (Medium, 21 octobre 2025), Retour d'expérience d'un PM chez Snowplow sur la mise en production via vibe coding.
Veracode, 2025 GenAI Code Security Report, Données sur les vulnérabilités du code IA (2,74x XSS, 45 % des échantillons).
Cloud Security Alliance, AI-Generated Code Security: Vibe Coding Credential Sprawl, Taux d'exposition de secrets dans les commits IA vs humains (3,2 % vs 1,5 %).
Pixelmojo, Vibe Coding Technical Debt Crisis 2026-2027, Données sur les rebuilds forcés, vulnerabilités dans apps vibe-codées déployées.
Userpilot, 6 Product Management Trends in 2026: The PM Role Is Splitting (17 mai 2026), Bifurcation Builder-PM / Integrator-PM, données salariales AI PM vs PM traditionnel, programme LinkedIn Product Builder.
Ant Murphy, How Product is Changing in 2026 (23 décembre 2025), Synthèse Productboard AI Survey 2025 (n=379), compétences PM prioritaires.