Voilà plusieurs mois que les développeurs interviewent les clients sans passer par le Product Manager.
Et il y a trois jours, j'ai poussé ma première pull request sur notre produit principal.
Ces deux phrases résument mieux que n'importe quelle analyse ce qui est en train de se passer dans les équipes produit avec l'IA. Les développeurs remontent vers le problème, le client et l'ownership produit. Les PM descendent vers le prototype, le code et parfois la production.
On pourrait y voir deux anecdotes isolées. Je pense au contraire que c'est le début d'une inversion plus profonde. Les rôles historiques du product management, du développement et du design deviennent moins nets. Les frontières bougent. Mais contrairement à ce qu'on pourrait croire, cela ne signifie pas que tout le monde va tout faire, ni que les responsabilités vont disparaître.
Le vrai sujet n'est pas que l'IA rende les équipes « plus productives ». Le vrai sujet est qu'elle augmente fortement la capacité à produire. Et quand la capacité à produire augmente, le goulot d'étranglement se déplace.
Avant, la contrainte était souvent : « Combien peut-on construire ? »
Demain, elle devient davantage : « Que faut-il construire ? Pourquoi ? Pour qui ? Dans quel ordre ? Avec quels risques ? »
C'est ce déplacement qui brouille les rôles.
Quand les développeurs produisent plus, le PM devient le goulot d'étranglement
L'un des déclencheurs du sujet est assez simple : avec l'IA, les développeurs peuvent produire plus vite.
Pas seulement écrire quelques lignes plus rapidement. Produire plus d'options, plus de variantes, plus de prototypes, plus de petits outils, plus d'initiatives. Un développeur qui était déjà autonome peut se retrouver capable d'aller trois, quatre ou six fois plus vite sur certaines tâches. Une équipe qui avait une capacité de delivery limitée peut soudainement générer beaucoup plus de choses à tester, à arbitrer, à relire, à prioriser.
Le problème, c'est que la capacité à décider n'augmente pas automatiquement au même rythme.
Si tout doit continuer à passer par le PM, celui-ci devient rapidement le nouveau point de saturation du système. Il ne s'agit plus seulement d'écrire des specs ou de suivre un backlog. La charge se déplace vers la priorisation, la cohérence produit, la validation du signal client, l'arbitrage marché, l'impact utilisateur, la stratégie et la gestion des conséquences.
Une organisation peut alors croire qu'elle a résolu son problème de vitesse parce que les développeurs produisent plus. En réalité, elle a simplement déplacé le blocage.
Il y a trois réponses possibles.
La première consiste à recruter plus de PM. C'est parfois nécessaire, mais ce n'est pas toujours la bonne réponse. Si le modèle reste le même, on ajoute seulement une couche d'arbitrage supplémentaire.
La deuxième consiste à automatiser une partie du travail opérationnel du PM : documentation, release notes, supports de lancement, analyses initiales, traductions, synthèses, vidéos de démonstration, captures d'écran, éléments de PR. Cela libère du temps, mais ne suffit pas à régler la question de fond.
La troisième consiste à redistribuer une partie de l'ownership produit vers ceux qui construisent. C'est là que les rôles commencent réellement à se brouiller.
Accélérer le code ne suffit pas
Une erreur serait de croire que l'IA transforme l'organisation uniquement parce qu'elle accélère le développement.
La vitesse locale ne crée pas automatiquement de valeur. Elle peut même créer plus de désordre si le workflow complet ne change pas. Une équipe peut générer plus de code, plus de prototypes, plus de documents et plus de tickets, tout en prenant de moins bonnes décisions.
Le flux complet doit être repensé : idée, discovery, spécification, prototypage, développement, tests, sécurité, lancement, communication, support et apprentissage.
Si on ajoute des agents IA sur un processus inchangé, on risque seulement de déplacer les goulots d'étranglement. Le code accélère, puis le product bloque. Le product accélère, puis le design bloque. Le design accélère, puis la validation technique bloque. La validation accélère, puis le go-to-market ou le support ne suit plus.
Le sujet n'est donc pas seulement : « Comment rendre les développeurs plus rapides ? »
Le sujet est : « Comment rendre le système entier capable d'absorber cette vitesse sans perdre en qualité, en cohérence et en responsabilité ? »
C'est pour cela que les nouveaux rôles ne se résument pas à « PM qui code » ou « développeur qui fait du produit ». Une partie des nouveaux besoins concerne l'orchestration des workflows, l'évaluation des sorties IA, la mémoire produit, la qualité des décisions, la lisibilité des repos et la capacité à donner aux agents un contexte fiable.
Ce que l'IA banalise dans le product management
Pendant longtemps, certains PM se différenciaient par des sensibilités ou des compétences assez distinctes.
Certains étaient très bons en rédaction. D'autres en data. D'autres en benchmark, en marketing produit, en discovery, en design d'expérience ou en coordination delivery. Ces différences ne disparaissent pas complètement. Mais une partie de leur valeur différentielle baisse.
Avec l'IA, beaucoup de capacités deviennent plus accessibles :
- écrire une spec correcte ;
- produire une première analyse data ;
- faire un benchmark ;
- rédiger une release note ;
- faire une maquette acceptable ;
- synthétiser des interviews ;
- produire une première version de parcours ;
- transformer un besoin en prototype.
Ces compétences ne deviennent pas inutiles. Un PM doit toujours savoir juger une spec, challenger une analyse, lire une maquette, comprendre une synthèse d'interviews ou évaluer un prototype. Mais la production initiale de ces artefacts devient moins rare.
Avant, un PM pouvait être fortement différencié parce qu'il savait produire rapidement une bonne spec, un benchmark clair, une synthèse exploitable ou une première maquette. Demain, ce sera davantage le niveau minimum.
Cela rend vulnérables les PM qui étaient surtout forts par leur capacité d'exécution intermédiaire. Ceux qui coordonnaient, rédigeaient, administraient, suivaient, reformulaient et produisaient des artefacts corrects sans porter un jugement produit fort risquent de perdre une partie de leur valeur.
Le métier produit ne disparaît pas. Mais son niveau minimum monte.
Ce qui reste dur : le jugement produit
Quand produire devient plus facile, choisir quoi produire devient plus critique.
C'est là que le métier de PM garde sa valeur. Pas dans la capacité à générer plus d'artefacts, mais dans la capacité à choisir, arbitrer et assumer.
Ce qui reste difficile :
- choisir le bon problème ;
- comprendre un marché ;
- lire le vrai signal derrière les demandes clients ;
- arbitrer entre court terme et stratégie ;
- dire non ;
- tenir une vision cohérente ;
- créer de l'alignement ;
- assumer les conséquences produit, business, techniques et humaines d'une décision.
Le PM stratégique augmenté ressemble de plus en plus à une forme de petit CPO. Il est moins dans l'administration du delivery, moins dans la production mécanique de livrables, et davantage dans les arbitrages où aucune option n'est parfaite.
Le rôle devient particulièrement important lorsqu'il n'y a pas de bonne solution. Seulement deux ou trois mauvaises options, avec des coûts différents, des risques différents, des effets politiques différents, des impacts client différents. Dans ces moments-là, l'IA peut aider à analyser. Elle ne peut pas assumer.
Le PM augmenté n'est donc pas simplement un PM qui va plus vite. C'est un PM qui doit mieux juger.
La différenciation se déplace vers le signal client
Si tout le monde peut construire plus vite, construire vite n'est plus un avantage suffisant.
La production brute de code devient en partie une commodité. Pas le logiciel. Pas l'ingénierie. Pas l'architecture, la sécurité ou la maintenabilité. Mais la capacité à produire rapidement une première version devient moins rare.
La vraie différenciation se déplace alors vers ce que les concurrents ne peuvent pas simplement générer :
- la qualité du signal client ;
- les données propriétaires ;
- la connaissance métier ;
- la distribution ;
- la confiance ;
- les contraintes opérationnelles ;
- les apprentissages accumulés ;
- la capacité à interpréter correctement ce que les clients demandent vraiment.
Un prototype rapide n'a de valeur que s'il teste un vrai signal. Sinon, il ne fait qu'accélérer une mauvaise direction.
La question stratégique devient donc : sur quel avantage propre construit-on ?
Une équipe augmentée par l'IA peut produire beaucoup de choses. Mais si elle ne lit pas mieux son marché, si elle ne comprend pas mieux ses utilisateurs, si elle ne sait pas distinguer un signal fort d'un bruit bien formulé, elle produira seulement plus vite des choses moyennes.
C'est une raison supplémentaire pour laquelle le PM ne disparaît pas. Le rôle se déplace vers la qualité de lecture du réel.
Les développeurs montent vers le produit
Les développeurs n'ont jamais été de simples exécutants.
Une spécification complète est une fiction. Même une bonne spec ne décrit jamais tous les comportements attendus d'un produit. Il reste toujours des zones muettes : cas limites, messages d'erreur, comportements implicites, règles de sécurité, temps d'expiration, priorités invisibles, micro-interactions, décisions de fallback.
Dans ces zones, les développeurs prennent déjà des décisions produit.
L'IA rend cette réalité plus visible. Si un agent écrit une partie du code, l'humain doit expliciter le comportement attendu, arbitrer les edge cases, définir les critères d'acceptation, vérifier le résultat. Les micro-décisions qui étaient absorbées silencieusement dans l'implémentation deviennent plus visibles, donc plus importantes à cadrer.
C'est une des raisons pour lesquelles les développeurs montent vers le produit. Ils parlent davantage aux clients, comprennent mieux les problèmes, portent plus d'ownership sur leurs fonctionnalités, prennent des décisions locales plus explicites.
Mais il y a une nuance importante : un développeur ne devient pas product engineer simplement parce qu'il utilise un agent de code ou parce qu'il livre plus vite.
S'il n'a pas accès aux clients, aux données, au contexte business et aux arbitrages, il risque seulement de devenir un opérateur d'agents de code. Plus de responsabilités, plus de pression, mais pas nécessairement plus de pouvoir produit.
Le vrai product engineer n'est pas seulement un développeur rapide. C'est quelqu'un qui porte une partie du jugement produit au plus près de la construction.
Les PM descendent vers la construction
Le mouvement inverse existe aussi.
Avec l'IA, un PM peut matérialiser une idée beaucoup plus vite qu'avant. Une maquette, un prototype, un outil interne, un dashboard, une traduction, une modification d'interface, parfois même une PR encadrée.
Cela change la nature du travail.
Avant, il fallait souvent passer par une séquence longue : formuler le besoin, écrire la spec, faire une maquette, demander une estimation, attendre un créneau, faire développer, tester, ajuster. Aujourd'hui, sur certains sujets, on peut passer beaucoup plus vite de l'intuition à un artefact manipulable.
Et parfois, il ne s'agit même plus seulement de prototyper. Sur des cas simples ou bien cadrés, on peut coder quelque chose de presque réel : un dashboard, un écran en lecture seule, une amélioration d'interface, une automatisation interne, une traduction, un support de release.
Cela ne veut pas dire que le PM devient développeur au sens classique. Cela veut dire qu'il peut intervenir dans des zones de construction qui étaient auparavant hors de son périmètre.
Il faut ici distinguer plusieurs niveaux.
Le PM ou PO prototypiste transforme une intention métier en prototype ou POC.
Le Product Builder va plus loin : il construit des artefacts tangibles, des outils internes, des dashboards, des premières versions, des contributions encadrées.
Le Product Engineer va encore plus loin : il peut porter une responsabilité produit jusqu'au livrable de production. Et ce rôle peut venir de deux trajectoires. Un développeur qui monte vers le produit. Ou un profil product suffisamment technique qui descend vers la production.
Le critère n'est donc pas le métier d'origine. Le critère est le niveau de capacité d'action.
Est-ce que la personne reste au niveau de la maquette ? Est-ce qu'elle produit un prototype ? Est-ce qu'elle ouvre une PR ? Est-ce qu'elle porte un livrable productisable ? Est-ce qu'elle comprend assez les risques pour faire valider correctement ce qu'elle produit ?
C'est ce continuum qui est nouveau.
Les rôles se brouillent, les responsabilités restent
Le risque serait de conclure que, puisque les rôles se brouillent, les responsabilités se dissolvent.
Je pense exactement l'inverse.
Plus les rôles se brouillent, plus il faut clarifier les responsabilités.
Un choix produit reste un choix produit. Il revient au product : vision, positionnement, cohérence, arbitrages, grands principes, lecture du marché, signal client.
Un choix technique reste un choix technique. Il revient à la technique : sécurité, performance, scalabilité, architecture, maintenabilité, qualité de plateforme.
Un choix d'expérience reste un choix d'expérience. Il revient au design ou au front : design system, cohérence d'usage, accessibilité, niveau d'exigence UX.
L'organisation qui fonctionne n'est pas celle où tout le monde fait tout dans son coin. C'est celle où chacun peut intervenir au-delà de son domaine initial parce que des garants posent les standards, les garde-fous et les limites.
Un PM peut pousser une PR. Mais elle est relue, acceptée, corrigée ou refusée.
Si elle est refusée dix fois d'affilée, cela dit quelque chose. Peut-être que le PM n'a pas encore le niveau pour ce type de contribution. Peut-être que le sujet est trop risqué. Peut-être aussi que l'équipe technique n'a pas encore mis en place les directives, les outils ou les garde-fous permettant à d'autres profils de contribuer de manière sûre.
La PR ou la MR devient alors un mécanisme de gouvernance. Pas seulement un outil technique.
Tout dépend du couple compétence / risque
La bonne question n'est pas : « Un PM peut-il pousser en prod ? »
La bonne question est : « Sur quel périmètre, avec quelle compétence, quel risque et quels garde-fous ? »
Il faut une gradation simple.
Faible risque : traductions, contenus, dashboards, écrans en lecture seule, outils internes non critiques.
Risque moyen : petites actions en écriture, workflows internes, modifications d'interface encadrées.
Risque fort : paiement, droits, sécurité, données sensibles, logique métier critique, produit régulé, architecture.
Même dans un produit régulé, tout n'a pas le même niveau de risque. Un dashboard ou un écran de consultation peut être relativement sûr si les règles sont claires et la validation technique présente. Inversement, un produit apparemment simple peut contenir une zone très sensible s'il touche aux données, aux droits ou à une décision métier irréversible.
L'analogie avec un développeur junior est utile. On ne donne pas les clés du moteur produit à quelqu'un dès le premier jour. On commence par des périmètres simples, puis on élargit progressivement.
Le PM augmenté peut suivre la même logique : traductions, lecture seule, dashboards, petites écritures, puis éventuellement contributions plus critiques si la compétence, le contexte et les garde-fous suivent.
La fracture entre profils PM
Tous les PM ne pourront pas devenir builders ou product engineers au même rythme.
À court terme, les PM avec un bagage technique ont un avantage. Ils savent lire un repo, comprendre une erreur, dialoguer avec un agent de code, interpréter ce qui a été généré, repérer certaines absurdités, demander une revue technique au bon endroit.
Un PM sans cette culture peut bien sûr apprendre. Mais il risque d'être limité à la maquette ou au prototype superficiel tant qu'il ne comprend pas assez ce que l'IA produit.
L'IA est encore trop peu fiable pour qu'on puisse ignorer totalement ce qui se passe sous le capot. Si l'on ne comprend pas un minimum les erreurs produites, il devient difficile de dépasser la maquette fiable.
Cela ne veut pas dire que les profils non techniques sont condamnés. À moyen ou long terme, l'inverse peut même se produire. Si les agents deviennent beaucoup plus fiables, des profils issus de la psychologie, des lettres, de la philosophie, du design, de la recherche ou du business pourraient prendre l'avantage grâce à leur capacité à exprimer finement une réalité humaine, sociale ou métier.
Mais dans l'état actuel des outils, la fracture existe.
Les PM qui ne veulent pas devenir builders devront probablement monter très fort sur d'autres dimensions : stratégie, marché, discovery, influence, compréhension humaine, qualité d'expression, capacité à dire non et à orienter une équipe.
Les nouveaux métiers ne sont pas toujours des métiers
On parle souvent de « nouveaux métiers ». Le terme est utile, mais il peut être trompeur.
Tous ces rôles ne deviendront pas forcément des titres RH stabilisés. Certains deviendront des postes. D'autres resteront des compétences distribuées dans l'équipe. D'autres encore seront absorbés par Product Ops, Design, Engineering ou QA.
Le point important n'est pas le titre. C'est la responsabilité.
Qui juge ?
Qui construit ?
Qui garantit ?
Qui évalue ?
Qui maintient la mémoire ?
Qui orchestre les workflows ?
L'IA rend visibles des responsabilités qui étaient parfois implicites ou secondaires : l'évaluation des sorties probabilistes, la documentation exploitable par agents, la mémoire produit, l'orchestration des workflows, la qualité du contexte, la lisibilité du repo, la clarté des critères d'acceptation.
Ces besoins ne sont pas périphériques. Ils deviennent centraux dès qu'une équipe travaille avec des agents.
Le PM ne disparaît pas, le niveau minimum monte
Le product management ne disparaît pas.
Mais le métier devient moins tolérant pour les profils qui vivaient surtout de coordination, de rédaction, de suivi et de production d'artefacts intermédiaires.
Demain, il y aura moins de place pour le PM administratif.
Il y aura plus de place pour deux types de profils.
D'un côté, ceux qui savent construire suffisamment pour accélérer l'apprentissage produit : prototyper, matérialiser, tester, contribuer, parfois pousser jusqu'à un livrable réel.
De l'autre, ceux qui savent juger suffisamment bien pour orienter une équipe qui peut construire beaucoup plus vite qu'avant : comprendre le marché, lire le signal, arbitrer, dire non, tenir une vision, protéger la cohérence et assumer les conséquences.
Entre ces deux pôles, beaucoup de combinaisons existeront. Mais le niveau minimum va monter.
L'IA ne supprime pas le product management. Elle force le métier à redevenir ce qu'il aurait toujours dû être : une responsabilité de création, de jugement et d'impact.
Annexe : catalogue des futurs rôles produit
Cette annexe ne cherche pas à prédire les futurs titres LinkedIn. Elle décrit plutôt les zones de responsabilité qui deviennent visibles avec l'IA.
PM stratégique augmenté
PM qui automatise une partie de l'exécution intermédiaire pour se concentrer sur la vision, les arbitrages, la cohérence produit et la lecture du signal client.
Sa valeur est de choisir les bons problèmes, trancher quand aucune option n'est parfaite, protéger le positionnement et maintenir l'alignement entre marché, stratégie, utilisateurs et exécution.
Son risque est d'être confondu avec un simple PM plus productif, ou de devenir le nouveau goulot d'étranglement si toute la décision continue à remonter vers lui.
PM ou PO prototypiste
Profil produit capable de transformer rapidement une intention métier en prototype, POC, outil interne ou premier parcours testable avec l'aide de l'IA.
Sa valeur est de réduire l'ambiguïté entre métier, product et tech.
Son risque est de rester au niveau de la maquette ou de contourner trop tôt les développeurs sur des sujets qui demandent une vraie réflexion technique.
Product Builder
Profil produit capable de transformer directement une idée en artefact testable, prototype fonctionnel, outil interne ou contribution encadrée.
Sa valeur est de réduire le temps entre intuition et démonstration.
Son risque est de confondre un prototype qui fonctionne avec un produit maintenable.
Product Engineer
Profil capable de porter une responsabilité produit jusqu'au livrable de production : compréhension utilisateur, choix de solution, construction, livraison, mesure et impact.
Il peut venir d'un background développeur ou d'un background product suffisamment technique.
Sa valeur est de redistribuer une partie du jugement produit au plus près de la construction et de réduire l'écart entre idée, prototype et production.
Son risque est double : croire qu'un développeur devient product engineer sans accès réel aux clients, aux données, au contexte business et aux arbitrages ; ou croire qu'un PM peut devenir product engineer sans capacité à comprendre, faire valider et maintenir un livrable de production.
Product Systems Designer
Rôle qui conçoit les systèmes produit alimentés par l'IA : feedback, discovery, génération de specs, routage des insights, documentation vivante et workflows de release.
Sa valeur est d'améliorer les mécanismes qui permettent à l'équipe de prendre de meilleures décisions en continu.
Son risque est de devenir une fonction trop abstraite si elle n'est pas reliée aux workflows réels de l'équipe.
AI Product Evaluator
Rôle chargé d'évaluer les sorties IA dans le produit : qualité, hallucinations, UX d'échec, robustesse, tests métier et cohérence avec l'intention produit.
Sa valeur est de rendre testable la qualité d'un produit probabiliste.
Son risque est d'être réduit à de la QA classique alors que l'évaluation porte aussi sur l'intention produit, la confiance et l'acceptabilité.
Product Knowledge Curator
Rôle qui maintient la mémoire produit sous une forme exploitable par les humains et par les agents.
Sa valeur est de rendre les décisions passées, le signal client, les contraintes, les arbitrages et la documentation réellement actionnables.
Son risque est de produire une documentation lourde au lieu d'une mémoire vivante.
Product Ops agentique
Product Ops spécialisé dans l'orchestration des outils, automatisations et agents qui soutiennent le travail produit.
Sa valeur est de maintenir les workflows IA qui traversent le product management : feedback, briefs, discovery, release notes, documentation, mesure d'impact.
Son risque est d'automatiser du bruit si les critères de qualité et l'ownership ne sont pas clairs.
Trois familles de rôles
On peut lire ces rôles en trois familles.
Les rôles de jugement : PM stratégique augmenté.
Les rôles de construction : PM ou PO prototypiste, Product Builder, Product Engineer.
Les rôles de système : Product Systems Designer, AI Product Evaluator, Product Knowledge Curator, Product Ops agentique.
Le titre importe moins que la responsabilité. Dans les équipes augmentées par l'IA, la question centrale sera moins « quel est ton rôle ? » que « qu'est-ce que tu es capable de juger, construire, garantir, évaluer ou maintenir ? »
Pour aller plus loin
Quatre jours de vibe coding dans la peau d'un PM rouillé En 8 jours, j'ai compris que le métier de Product Manager allait changer du tout au tout L'IA ne devrait pas seulement servir à produire dix fois plus. Elle devrait aussi nous obliger à comprendre dix fois mieux ce que nous produisons Dans le logiciel, l'avantage ne sera plus la technologie. Ce sera la compréhension du contexte.