Camille Louis
Un PM monte un prototype en quelques heures. Un autre synthétise 20 interviews en une après-midi. Un troisième pousse une PR en autonomie. Ces scénarios ne sont pas hypothétiques : ils ont lieu chaque jour dans nos équipes Produit et transforment déjà notre métier. L'IA sera-t-elle au PM ce que la Discovery a été au Chef de Projet ? La Discovery avait élargi le rôle, de l'exécution vers la décision produit. L'IA trace une nouvelle rupture : le PM ne décide plus seulement ce qu'il faut construire, il construit lui-même. Deux modes émergent : le PM augmenté, qui démultiplie ses capacités, et le Product Builder, plus radical, qui repousse les frontières du rôle jusqu'au design et au code.
Pendant des années, l'équation était simple : le PM pense, les devs buildent. Le rythme du produit était dicté par la capacité de développement : une bonne idée prenait parfois des semaines à être prototypée, des mois à être développée.
Aujourd'hui, les IA génératives font sauter ce verrou. Lovable permet de builder un prototype complet en quelques prompts. Claude Code génère des applications fonctionnelles sans écrire une ligne de code.
Mais l'IA amplifie ce qui existe, en bien comme en mal. Sans la friction d'un sprint, une mauvaise vision s'exécute à grande échelle. Des fonctionnalités sont déployées sans répondre à des problèmes utilisateurs. Une étude MIT Sloan / NBER (Demirer, Musolff & Yang, 2026) le confirme : depuis l'arrivée des agents de code, les soumissions d'apps iOS ont bondi de près de 200%, mais le nombre d'applications utilisées, lui, baisse.
L'IA rouvre un vieux piège que nous connaissons bien : le réflexe de l'output. Quand builder devient aussi rapide, et grisant, l'instinct naturel est de builder plus. Et pourtant, notre métier PM s'est justement construit contre ce réflexe. « Fall in love with the problem, not the solution » disait Uri Levine, le créateur de Waze.
Décider quoi construire devient ainsi une compétence irremplaçable. L'IA explore les options, mais elle ne tranche pas : le jugement reste humain. Cela remet au centre le cœur de notre métier : choisir les bons problèmes utilisateurs, ceux qui génèrent un impact business démontrable.
Le PM augmenté est un Product Manager qui utilise l'IA pour décupler ses capacités en stratégie, discovery et delivery, dans le périmètre qui a toujours été le sien.
Le PM a toujours orchestré des équipes dev et design. Avec l'IA, le PM augmenté sait aussi orchestrer des agents spécialisés : rédaction de user stories, tests automatisés, génération de PRD à partir de maquettes Figma. Bien utilisés, ces agents compressent la charge opérationnelle et libèrent du temps pour le jugement : arbitrer entre des signaux contradictoires et trancher.
Le modèle d'équipe, lui, ne bouge pas. Le PM augmenté reste au sein du Product Trio, ce triptyque PM, designer, tech lead où chacun tient son métier. Ce qui change, ce n'est pas la composition de l'équipe, mais le fait que chaque membre soit augmenté par l'IA.
En stratégie, l'IA devient un accélérateur de réflexion : benchmarks concurrentiels en quelques minutes, identification fine de signaux marché, exploration de scénarios alternatifs. En discovery, la synthèse d'interviews, le clustering de verbatims et l'analyse de volumes importants de données deviennent accessibles sans y passer des journées entières.
Mais l'IA analyse, elle ne juge pas. Lire une hésitation dans la voix d'un client, creuser un non-dit, sentir qu'une réponse est socialement désirable : cela reste humain, et cela le restera encore longtemps. Teresa Torres le rappelle : aucun outil ne remplace le contact direct avec ses utilisateurs.
Reste un autre facteur déterminant : le contexte. Deux PM avec les mêmes outils ne produisent pas les mêmes résultats. Ce qui les différencie, c'est le contexte qu'ils ont construit. Le premier ouvre une fenêtre vierge à chaque tâche et re-décrit son produit à chaque fois. Le second, lui, a encodé ses personas, ses règles métier et ses décisions passées dans un système réutilisable : ses savoir-faire encodés en skills, ses données connectées par MCP, sa mémoire produit historisée. La vraie question n'est plus "comment j'utilise l'IA pour accélérer ?", mais "comment je construis un contexte qui rend mes prochaines décisions meilleures ?". Et demain, l'enjeu dépassera le PM seul : les organisations qui prendront de l'avance sont celles qui feront de ce contexte un bien commun, accessible à toute l'équipe.
Pour certains PM, l'IA change la nature même du rôle. Le Product Builder est un Product Manager qui, grâce à l'IA, étend son périmètre au design et au code. Il ne se contente plus de coordonner l'exécution, il s'implique directement dans la création.
Marty Cagan (SVPG) parle de "Product Creator". Dans "The Era of the Product Creator", il observe que le périmètre s'élargit dans les deux sens : des PMs qui s'étendent vers le code, mais aussi des designers et des ingénieurs qui prennent le rôle produit. Chez WeFiiT, on a toujours cru au concept de "Product Full Stack" : ce PM qui couvre la stratégie, la discovery et la delivery, avec un ownership complet sur son produit. Le Product Builder, c'est cette vision poussée un cran plus loin avec un PM qui étend son rayon d'action jusqu'au design et au dev.
Mais un Product Builder seul ne suffit pas. La vraie question n'est pas de savoir s'il sait tout faire, mais de quelles compétences son produit a besoin autour de lui. C'est là que le modèle d'équipe bascule. On connaissait le Product Trio : un PM, un designer, un tech lead qui se coordonnent, chacun dans son métier. La squad de Product Builders fonctionne différemment : un ou plusieurs builders couvrent chacun une large partie de la chaîne produit/design/tech, entourés des expertises spécifiques que le projet réclame.
Parmi ces expertises, l'engineering reste au premier plan. Le piège serait de revenir à un mode projet, en séparant le build du run, en confiant les protos à une autre équipe pour les faire vivre. C'est l'inverse qu'il faut : la même squad construit son produit puis le fait tourner.
Mais cette extension de périmètre a un coût. Le premier est individuel. Un PM qui code est un PM qui ne parle pas à ses utilisateurs : chaque heure passée à débugger une PR est une heure de discovery en moins. Le Product Builder peut glisser, sans s'en rendre compte, du « je décide quoi construire » vers le « je suis occupé à construire », exactement le réflexe output que le métier a mis vingt ans à désapprendre. Le périmètre élargi n'a de valeur que si le jugement reste la priorité, jamais l'exécution.
Le second coût est technique. Un prototype généré par IA n'est pas un produit : le code sort vite, mais il arrive avec sa dette. Failles de sécurité, architecture non tenable à l'échelle, maintenabilité incertaine. Sans vigilance, les protos s'empilent plus vite qu'on ne les industrialise : un embouteillage de solutions à moitié finies. C'est pour ça que les ingénieurs sont dans la squad dès le départ : non pas pour traduire les specs, mais pour transformer un proto crédible en produit fiable.
Le troisième coût sera probablement collectif. Dans les grandes organisations, ce modèle Product Builder ouvrira un chantier RH structurant : comment former ces nouveaux profils, et accompagner la transition des équipes en place vers des tailles d'équipes plus resserrées ?
PM augmenté ou Product Builder, faut-il vraiment choisir ? Aucun de ces deux modes n'est supérieur à l'autre dans l'absolu. Le bon choix dépend du produit, du contexte et de la culture d'entreprise.
Le Product Builder sera certainement à son meilleur sur les petites équipes autonomes, des produits à cycles courts et forte orientation client. On l'imagine aisément, par exemple, sur des parcours front en ecommerce. Le PM augmenté, lui, reste pertinent sur les produits complexes, réglementés ou critiques, là où la séparation nette des rôles et des responsabilités est nécessaire. Un PM sur un parcours de virement bancaire, par exemple. Et entre les deux, la frontière n'est pas figée : un même PM peut être builder sur un sujet, augmenté sur un autre.
Dans les deux cas, l'essence du métier ne change pas : résoudre des problèmes qui valent la peine d'être résolus. L'IA élargit la surface d'action du PM, mais elle ne désigne pas les problèmes qui méritent d'être résolus. C'est là, sur ce choix que rien n'automatise, que se loge la valeur du Product Manager, et c'est là qu'elle restera.
