Le PM qui build : prototypage IA, vibe coding et dette méthodologique, PM Pathfinder

Le terme qui a tout changé

Le 2 février 2025, Andrej Karpathy, cofondateur d'OpenAI et ancien directeur de l'IA chez Tesla, publie sur X ce qui ressemble alors à une réflexion lancée en passant :

"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 qualifiera lui-même plus tard ce tweet de "shower of thoughts throwaway" [1]. Neuf mois après, Collins Dictionary nomme vibe coding 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 n'est pas le vibe coding en lui-même, mais ce qu'il révèle du rôle de Product Manager.

La frontière qui bouge

Commençons par un chiffre à manier avec prudence, mais difficile à ignorer : selon Jared Friedman, managing partner chez Y Combinator, environ un quart des startups de la promotion Winter 2025 avaient des codebases générées à 95 % par IA [3]. Y Combinator n'a pas publié de chiffre équivalent pour les promotions suivantes.

Les outils, eux, ont changé d'échelle. Bolt est passé de 20 à 40 millions de dollars d'ARR entre décembre 2024 et mars 2025, avec 67 % d'utilisateurs non développeurs [4] ; en mai 2026, l'entreprise revendique des utilisateurs dans 75 % du Fortune 500 [5]. Lovable, qui avait franchi les 100 millions d'ARR en huit mois [6], annonçait 600 millions en septembre 2026, pour une valorisation de 13,3 milliards [7]. Plus de 4 millions de personnes ont utilisé v0 de Vercel pour construire des prototypes [8]. Replit, valorisé 9 milliards en mars 2026 [9], décrit son public comme majoritairement composé de non-techniciens qui n'avaient jamais pu créer de logiciel auparavant [10].

Le mouvement est aussi organisationnel. En avril 2025, Tobi Lütke, CEO de Shopify, écrit à ses équipes que « l'usage réflexe de l'IA est désormais une attente de base », et qu'avant de demander des ressources supplémentaires, une équipe doit d'abord montrer pourquoi elle ne peut pas obtenir le résultat avec l'IA [11]. Toutes les entreprises n'ont pas tenu cette ligne : Duolingo, qui avait publié un mémo « AI-first » du même ordre, a renoncé en avril 2026 à évaluer ses employés sur leur usage de l'IA [12]. Le signal reste clair : explorer rapidement une idée n'est plus réservé aux profils techniques.

La frontière entre définir et construire se déplace, et le PM est assis précisément dessus. La question devient donc moins « un PM doit-il savoir coder ? » que « quelles étapes peut-il désormais réaliser lui-même, et quelles frictions doit-il au contraire conserver volontairement ? »

Construire coûtait assez cher pour imposer une friction, et cette friction obligeait aussi à réfléchir avant de produire. J'ai décrit ce mécanisme à l'échelle de l'équipe dans l'article sur l'organisation ; le PM qui build le rencontre à titre individuel, et plus tôt que les autres. Quand la vitesse d'exécution dépasse la qualité du raisonnement qui la précède, on accumule ce que j'appelle de la dette méthodologique, dont je donne la définition générale dans l'article de synthèse sur le PM Pathfinder Framework. Côté delivery, elle a une particularité : elle naît avant le build, quand la dette technique naît dedans. C'est ce qui justifie, plus loin, deux quality gates distincts.

Ce que les outils permettent réellement

Le paysage se structure autour de deux familles.

Les générateurs full-stack conversationnels (Lovable, Bolt, Replit Agent) partent d'une description en langage naturel et produisent une application déployée, front et back, sans sortir du navigateur.

Les éditeurs et agents de code (Cursor, Claude Code, v0 dans certains usages) supposent une compréhension minimale de ce qu'est une codebase, un composant, une branche ou une pull request. v0 se connecte désormais directement à des repos GitHub existants [8].

Pour un PM, la différence compte. Les premiers abaissent radicalement le coût d'un prototype fonctionnel. Les seconds abaissent le coût d'accès à quelque chose de plus rare : comprendre et manipuler directement le système existant. Construire plus vite permet de tester davantage ; comprendre plus directement permet parfois de poser de meilleures questions avant même de construire.

Ce que cela change dans le quotidien d'un PM

Alan Wright, Head of Product chez Climate Policy Radar, documente plusieurs mois d'expérimentation avec Lovable, Bolt, Replit et Cursor [13]. Parmi ses exemples :

un outil interactif de visualisation de données, construit pour résoudre un problème utilisateur connu, sans mobiliser d'ingénieur ;
la fusion de quatre fichiers JSON de 2 000 lignes chacun, avec déduplication, en quelques minutes ;
le croisement d'analytics produit et de métadonnées documentaires pour tester une hypothèse avant d'engager du temps engineering.

Sa conclusion opérationnelle : "Being able to do these little things myself makes me so much faster." [13] Il reste pourtant délibérément conservateur sur les features exposées aux utilisateurs : ses meilleurs résultats concernent des outils internes, de l'exploration ou des tâches ponctuelles, pas des briques durables du produit.

Nick Stanchenko, PM chez Snowplow avec un background d'ingénieur, a poussé en production une réécriture complète de l'interface d'un outil interne à l'aide de prompts [14]. Il documente aussi les limites : détails fins d'UI mal reproduits, itérations absurdes, et un agent qui affirme avoir corrigé ce qui ne l'est pas. Sa conclusion : ces outils créent beaucoup de levier pour comprendre, rechercher, prototyper ou corriger ponctuellement, mais vibe-coder une feature complète détourne le PM de son travail principal.

Les deux retours convergent. L'IA réduit fortement le coût de validation d'une hypothèse, et devient risquée quand elle sert de chemin direct vers la production. Ce gain n'a toutefois de valeur que si une hypothèse existe avant de commencer. Sinon, l'IA réduit seulement le coût de production d'une solution.

Le prompt ne remplace pas la spec : il la met à l'épreuve

On entend souvent que « le prompt devient la spec ». La formule est séduisante, mais incomplète. Une séquence de prompts peut remplacer une partie du document fonctionnel traditionnel ; une instruction assez claire pour générer quelque chose n'est pas pour autant une bonne spécification.

Le vrai changement est ailleurs : la spécification peut désormais être confrontée presque immédiatement à son exécution. Tant qu'une spec reste dans Confluence, ses ambiguïtés restent silencieuses. Quand un agent doit la transformer en comportement, elles deviennent concrètes : quel état initial, quel utilisateur, que se passe-t-il si la donnée manque, que signifie « rapide », qu'attend-on dans ce cas limite, et à quoi reconnaîtra-t-on un résultat acceptable ?

Le prompt ne fait donc pas disparaître le travail de spécification ; il le rend plus exigeant. Une spec devient intéressante moins parce qu'elle est exécutable que parce qu'elle devient testable. C'est un mécanisme direct de réduction de la dette méthodologique : obliger l'intention à devenir assez explicite pour qu'on puisse vérifier si ce qui a été construit correspond à ce qu'on voulait apprendre.

Le PM y gagne une boucle définition, exécution, observation beaucoup plus courte. Mais une boucle plus rapide amplifie autant la qualité du raisonnement que ses erreurs.

Le vrai danger : confondre ce qui fonctionne avec ce qui valide

Les outils génératifs produisent très vite quelque chose de convaincant : l'interface fonctionne, le parcours paraît crédible, le résultat ressemble déjà à un produit. C'est précisément ce qui peut tromper. Un prototype réaliste ne valide pas une hypothèse. Une feature fonctionnelle ne prouve pas qu'elle répond à un problème important. Une URL déployée ne dit pas qu'on a appris quoi que ce soit.

Côté recherche, j'ai décrit dans l'article sur la discovery un effet voisin : un prototype généré par IA est haute fidélité par défaut, et attire des retours sur la couleur du bouton quand on avait besoin de retours sur l'intention. Côté construction, le risque est plus large : produire une excellente réponse à une question que personne n'avait vraiment posée.

Mon point de vue : la facilité de production crée une illusion d'avancement, et c'est à mes yeux la forme la plus coûteuse de dette méthodologique introduite par le vibe coding. Elle ne se voit dans aucun indicateur de vitesse : le nombre de prototypes monte, le nombre de démos monte, et rien ne signale qu'aucune décision n'a réellement progressé. C'est le même écart entre impression de vitesse et vitesse réelle que documentent les études détaillées dans l'article sur la mesure.

Où le quality gate devient non négociable

À la dette méthodologique peut s'ajouter la dette technique, et sur ce terrain les données imposent la prudence.

Le rapport Veracode 2026 sur la sécurité du code généré par IA mesure un taux de réussite sécurité de 56 %, quasiment inchangé en un an : dans environ 44 % des tâches, le code produit introduit une faille. Sur les vulnérabilités XSS, le taux de réussite tombe à 15 % [15]. GitGuardian recense 28,6 millions de nouveaux secrets exposés dans les commits publics de GitHub en 2025, en hausse de 34 %, et observe que les commits co-écrits par Claude Code fuient environ deux fois plus de secrets que la moyenne [16].

Les applications elles-mêmes suivent. Escape a recensé 5 600 applications publiques construites avec des outils de vibe coding ; sur les 1 400 qu'il a analysées en détail, il relève 2 038 vulnérabilités hautement critiques, plus de 400 secrets exposés et 175 cas de données personnelles accessibles, dont des dossiers médicaux et des IBAN [17]. L'étude RedAccess, relayée par VentureBeat en mai 2026, a recensé 380 000 assets publics construits avec Lovable, Base44, Replit ou Netlify : environ 5 000 d'entre eux exposaient des données sensibles d'entreprise [18].

Ces chiffres ne disent pas que le code généré est intrinsèquement mauvais. Ils montrent qu'il devient très facile de produire plus de code que nos mécanismes de revue ne peuvent en absorber. LinearB le mesure directement : sur 8,1 millions de pull requests analysées en 2026, les PR assistées par IA sont 2,6 fois plus volumineuses, ne contiennent presque aucun refactoring, et sont fusionnées dans 32,7 % des cas contre 84,5 % pour les PR manuelles [19]. Sur la dette technique à long terme, en revanche, les données solides manquent encore.

Karpathy décrivait déjà le mécanisme dans son tweet initial : "The code grows beyond my usual comprehension." [1] La question n'est plus de savoir si le logiciel fonctionne, mais qui est capable d'en assumer les conséquences quand il ne fonctionne plus. Cela suppose deux gates distincts.

Avant le build : le gate méthodologique

Quelle décision cherche-t-on à prendre ?
Quelle hypothèse veut-on tester, et quelle information manque réellement ?
Quel est le niveau minimal de produit nécessaire pour l'obtenir ?
À quoi saura-t-on que l'hypothèse est validée ou invalidée ?

Avant la production : le gate technique

Le code a-t-il été revu, et les tests sont-ils suffisants ?
Les données sont-elles protégées ?
Le comportement est-il observable en production ?
Quelqu'un comprend-il réellement ce qui a été construit, et l'équipe est-elle capable de le maintenir ?

Mon point de vue : la dette méthodologique naît avant le build, la dette technique naît dans le build, et l'IA accélère les deux. La plupart des équipes ont déjà des pratiques pour le second gate : revue de code, tests, sécurité. Le premier, lui, n'a souvent pas de responsable, parce qu'il n'était pas nécessaire tant que construire coûtait cher. Pour un POC interne jetable, le gate technique peut rester léger. Le gate méthodologique, jamais : c'est lui qui décide si le POC méritait d'exister.

Ce que les PM en font déjà

Les PM n'ont pas attendu pour s'emparer de ces outils. Dans l'enquête menée par Lenny's Newsletter fin 2025 auprès de 1 750 répondants, le prototypage ne représente encore que 19,8 % des usages actuels de l'IA par les PM, mais 44,4 % des usages qu'ils souhaiteraient développer [20]. Le PM qui build n'est donc pas une figure marginale : c'est la direction dans laquelle une bonne partie du métier veut aller.

Ce que cela fait au rôle, entre builder-PM et integrator-PM, et quels profils en sortent exposés, est traité dans l'article sur les compétences. Ici, la question est plus pratique : une fois qu'on build, comment le faire sans contracter de dette méthodologique ?

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

Tout cela 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 PM, majoritairement non techniques, passent de la lecture d'API au déploiement en deux jours. Ce que j'en retiens tient en cinq gestes, ordonnés du moins au plus engageant. Chacun réduit une forme différente de dette méthodologique.

Geste 1 : interroger une API plutôt que de subir sa documentation

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, 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 de code. En vingt minutes, il comprend ce qu'est un objet Price, pourquoi un plan gratuit peut se passer d'abonnement Stripe, et quelles options existent pour gérer la remise annuelle. Il arrive ensuite en discussion avec les ingénieurs avec de meilleures questions et quelques arbitrages déjà posés. La documentation technique cesse d'être un mur : elle devient un objet que le PM peut interroger.

Dette évitée : construire une solution sur une compréhension approximative des contraintes techniques.

Geste 2 : se construire une lecture d'architecture

On monte d'un cran. À partir d'une user research (« les utilisateurs quittent la page restaurant parce qu'ils ne connaissent pas le délai de livraison »), le PM utilise Claude pour esquisser une architecture possible de la feature ETA, produire un premier exemple de requête et de réponse d'API, et surtout identifier les questions qu'il devra poser à son lead tech. Le livrable important n'est pas le schéma, mais la capacité à repérer plus tôt ce qu'on ignore encore, avant que les hypothèses techniques ne deviennent des tickets.

Dette évitée : traiter comme des faits des hypothèses techniques jamais explicitées.

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. On pose une question métier en apparence anodine : « pourquoi cette utilisatrice obtient-elle le plan Progression et pas Elite ? » En interrogeant le code, on découvre une logique de scoring que personne n'avait documentée. C'est, à mon sens, le geste le plus sous-estimé. La documentation décrit ce que le produit était censé faire ; le code décrit ce qu'il fait réellement. Un PM capable d'interroger cette source de vérité repère beaucoup plus vite l'écart entre les deux.

Dette évitée : prendre une représentation obsolète du produit pour le produit lui-même.

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

Le PM exécute ici un workflow développeur complet, piloté avec Claude Code : repérer un bug, créer une branche, décrire le comportement attendu, produire le correctif, commiter, pousser, puis ouvrir une Pull Request avec Claude en reviewer. Le point pédagogique apparaît très vite. « Corrige le panier » produit rarement un résultat fiable. « Le sous-total ignore la quantité quand elle dépasse 1 ; le comportement attendu est prix × quantité » produit un résultat contrôlable. La qualité du correctif dépend directement de la formulation du problème, exactement comme avec un ingénieur humain. Le PM n'apprend pas à coder : il apprend à rendre un comportement attendu observable et vérifiable.

Dette évitée : confondre demande vague et critère d'acceptation.

Geste 5 : de la spec au déploiement

Le PM rédige une spec en markdown, la donne à Claude Code en mode plan, puis itère sur ce plan avant qu'une ligne soit écrite. Viennent ensuite le build, puis le déploiement sur Vercel, et une URL testable. Mais le moment important se situe juste avant : quand l'agent produit son plan, les ambiguïtés deviennent visibles, et une bonne partie du travail consiste à corriger l'intention avant que le logiciel existe. C'est là que la promesse du spec-to-product devient intéressante pour le Product Management. Non parce qu'elle supprimerait l'ingénieur, mais parce qu'elle fait apparaître beaucoup plus tôt ce qu'on n'avait pas assez pensé.

Dette évitée : découvrir après le build que personne n'avait la même compréhension de ce qu'il fallait construire.

Mon point de vue : ces gestes ne forment pas une échelle vers le métier de 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 se substituer à l'ingénierie sur ce qui compte : robustesse, sécurité, maintenabilité. Le paradoxe que la formation rend évident, c'est que plus le PM devient autonome, moins il peut se permettre d'être approximatif : quand une première version coûte quelques minutes, les moments d'arrêt que le coût du build imposait doivent être reconstruits volontairement, geste par geste.

Conclusion : méthode d'abord, outil ensuite

Le vibe coding est un révélateur, pas le sujet. Ce qu'il révèle pour le PM, c'est qu'il peut désormais franchir lui-même la frontière entre définir et construire, et qu'il emporte avec lui deux dettes au lieu d'une.

La dette technique est visible, connue, et les ingénieurs ont des pratiques pour la gérer : c'est le second gate, celui de la revue avant la production. La dette méthodologique est plus discrète. Un prototype convaincant donne l'impression qu'une hypothèse est bonne, une feature fonctionnelle donne l'impression qu'un problème est résolu, une URL déployée donne l'impression qu'une décision est plus avancée qu'elle ne l'est. Elle se règle au premier gate, avant le build, et c'est d'abord au PM de le tenir.

Le PM qui build n'est pas celui qui remplace l'ingénieur, ni celui qui produit le plus vite. C'est celui qui construit uniquement ce qui est nécessaire pour apprendre, et qui place les deux quality gates au bon endroit. C'est une illustration directe du pilier Méthode avant Outil du PM Pathfinder Framework : savoir quelles frictions l'IA permet de supprimer, et lesquelles il faut volontairement conserver pour protéger la qualité de la décision.

Sources

Andrej Karpathy, Tweet original sur le "vibe coding" (X, 2 février 2025), origine du terme, définition fondatrice, citations directes.
Collins Dictionary, Word of the Year 2025, confirmation du statut de mot de l'année 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 de Jared Friedman sur le batch W25 ; pas d'équivalent publié pour les promotions suivantes.
Contrary Research, Bolt Business Breakdown (mis à jour le 2 mai 2025), ARR de 20 M$ en décembre 2024 et 40 M$ en mars 2025, 67 % d'utilisateurs non développeurs.
Bolt, annonce du partenariat avec Microsoft (5 mai 2026), utilisateurs dans 75 % du Fortune 500 (donnée d'entreprise).
TechCrunch, Eight months in, Swedish unicorn Lovable crosses the $100M ARR milestone (23 juillet 2025), passage à 100 M$ d'ARR en huit mois.
TechCrunch, Lovable's annualized revenue crosses $600M as vibe coding takes off (24 septembre 2026), 600 M$ d'ARR, valorisation de 13,3 Md$ (août 2026).
VentureBeat, Vercel rebuilt v0 to tackle the 90 percent problem (3 février 2026), plus de 4 millions d'utilisateurs de v0, connexion aux repos GitHub existants.
TechCrunch, Replit snags $9B valuation 6 months after hitting $3B (11 mars 2026), série D de 400 M$, valorisation de 9 Md$.
TechCrunch, Replit's Amjad Masad on the Cursor deal, fighting Apple, and why he'd rather not sell (1er mai 2026), public majoritairement non technique selon le CEO de Replit.
Tobi Lütke, "Reflexive AI usage is now a baseline expectation at Shopify" (X, 7 avril 2025), mémo interne publié par son auteur : usage réflexe de l'IA attendu, justification requise avant toute demande de ressources.
Fortune, Duolingo CEO Luis von Ahn drops AI usage requirement from employee performance evaluations (13 avril 2026), retour sur le mémo « AI-first » d'avril 2025.
Alan Wright, Vibe coding as a product manager: risks and opportunities (6 avril 2026), retour d'expérience d'un Head of Product sur Lovable, Bolt, Replit et 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 une mise en production par vibe coding.
Veracode, 2026 GenAI Code Security Report (28 juillet 2026), taux de réussite sécurité moyen de 56 %, 15 % sur le XSS.
GitGuardian, State of Secrets Sprawl 2026, 28,6 millions de nouveaux secrets exposés sur GitHub en 2025 (+34 %), fuites environ deux fois plus fréquentes dans les commits co-écrits par Claude Code.
Escape, The State of Security of Vibe Coded Apps et sa méthodologie (29 octobre 2025), 5 600 applications vibe-codées recensées, 1 400 analysées en détail : 2 038 vulnérabilités hautement critiques, 400+ secrets exposés, 175 cas de données personnelles accessibles.
VentureBeat, étude RedAccess sur les applications vibe-codées exposées (8 mai 2026), étude RedAccess : 380 000 assets publics construits avec des outils de vibe coding, dont environ 5 000 exposant des données sensibles.
LinearB, 8 million pull requests reveal where engineering productivity breaks down (4 mai 2026), 2026 Software Engineering Benchmarks Report : PR assistées par IA 2,6 fois plus grosses, refactoring quasi nul, taux de merge 32,7 % contre 84,5 %.
Lenny's Newsletter, AI tools are overdelivering (Noam Segal et Lenny Rachitsky, 23 décembre 2025), enquête auprès de 1 750 répondants : le prototypage passe de 19,8 % des usages actuels de l'IA à 44,4 % des usages souhaités.