Product builder : faut-il plus de bâtisseurs pour des produits déjà en surpoids ?

LinkedIn a fermé son programme d'associate product managers, la porte d'entrée historique du métier. À la place, l'entreprise forme des product builders, des profils qui savent à la fois cadrer un produit, le dessiner et le coder. Au printemps, Melissa Perri et Product Circle ont interrogé 309 dirigeants produit. Près de neuf sur dix avaient adopté des assistants de code. Un peu plus d'un tiers jugeaient que l'IA avait amélioré le fonctionnement de leur organisation.

Le marché en tire une conclusion rapide. Puisque les agents IA construisent vite, le product manager doit construire avec eux. Je posais déjà la question au printemps, et si le product builder n'existait pas ? Je vais plus loin aujourd'hui. Cette conclusion aggrave l'obésité fonctionnelle, ce produit qui grossit de fonctionnalités parce que produire ne coûte presque plus rien. Les équipes qui travaillent avec des agents construisent déjà beaucoup. Le product builder ajoute des bâtisseurs là où il y en a trop. Chaque demande, même légitime, trouve quelqu'un pour la livrer dans la semaine.

Pour voir où le product manager est utile, le plus simple est de suivre une demande, du moment où un client la formule au moment où le produit change.

Mardi, 14 h, une demande en réunion

Un éditeur vend un logiciel de gestion d'entrepôt. Mardi, en visioconférence, le responsable logistique d'un distributeur, client depuis quatre ans, demande d'exporter ses inventaires dans le format de son logiciel de gestion. La demande occupe deux minutes, vers la trente-huitième minute d'un échange d'une heure. Le commercial présent répond que c'est sûrement faisable.

L'outil de prise de notes produit le texte intégral de la réunion, huit mille mots. Ce texte entre tel quel dans la base de connaissance produit, l'endroit où l'entreprise range tout ce qu'elle sait de son produit. Il est daté et rattaché au client, à son contrat et au commercial. À ce stade, personne n'interprète rien.

Dans la nuit, un agent IA lit le texte et repère la demande. Il la compare à ce que la base contient déjà. Trois autres clients ont demandé la même chose au support depuis un an. Une note d'arbitrage d'il y a deux ans avait écarté les exports sur mesure au profit d'une connexion standard, ouverte à tous les logiciels. Le produit propose déjà un export simple, utilisé par quatre pour cent des clients. L'agent signale aussi une contradiction. La réponse du commercial va contre la note d'arbitrage.

Mercredi matin, le product manager trouve ce dossier en tête de sa liste. Il l'inscrit au comité produit du jeudi, avec trois personnes autour de la table, le commercial, un architecte et la responsable du support.

Jeudi, vingt minutes pour décider

La discussion part des faits que l'agent a rassemblés. Le commercial confirme que le client y tient. L'architecte rappelle que la connexion standard couvre déjà les principaux logiciels du marché. La responsable du support explique que les trois clients précédents ont renoncé faute de mode d'emploi.

La décision tombe en vingt minutes. Le product manager la dit à voix haute, en une phrase, pour qu'elle figure mot pour mot dans le texte de la réunion. L'équipe enrichit l'export existant d'un modèle prêt à l'emploi pour les trois logiciels les plus répandus chez les clients. Pour les autres, elle écrit le mode d'emploi de la connexion standard. La note d'arbitrage d'il y a deux ans reste valable.

Le texte du comité rejoint la base. Le product manager valide la décision. Elle devient la version de référence, avec tout ce qui l'appuie, l'échange avec le client, les trois demandes au support, la note d'arbitrage et la discussion du comité. La réponse du commercial est marquée comme remplacée. Elle reste lisible, avec un lien vers ce qui l'a remplacée.

Vendredi, une décision, tous les livrables

Je décris ici une cible. Peu d'organisations la vivent aujourd'hui. Mais c'est la direction que je vois se dessiner, et elle mérite d'être suivie jusqu'au bout.

Dans cette cible, chaque métier de l'entreprise dispose de ses propres agents IA, qui s'enchaînent sans qu'une personne relance chaque étape. J'appelle cela un socle agentique. Les développeurs ont le leur, le marketing et la vente ont le leur, le support aussi. Et tous lisent la même base.

À partir de vendredi, le product manager n'écrit donc plus rien. Les agents des développeurs produisent la description précise de l'évolution, les tests et le code. Les agents du marketing mettent à jour la documentation et la fiche commerciale, qui présente désormais la connexion standard comme la réponse aux besoins d'intégration. Les agents du support remplacent la réponse type. Le commercial reçoit pour son client une réponse qui cite ses sources, et qu'il relit avant de l'envoyer.

Une seule décision a modifié le code, la documentation, l'argumentaire et le support en même temps. Si elle avait été mauvaise, l'erreur se serait répandue de la même façon. Quand quelqu'un repère un défaut, il le corrige dans la base, et tout ce qui en dépend se régénère.

Cette cible se construit en replaçant chacun au bon endroit. Le développeur relit et valide ce que ses agents produisent. Le responsable marketing fixe les règles de la documentation et de l'argumentaire, puis relit ce qui en sort. La responsable du support valide les réponses types avant qu'elles partent chez les clients. Le commercial dépose ses échanges et signale ce qui lui paraît faux. Le product manager tient la base que tous lisent. Chacun garde une responsabilité claire, là où son jugement compte le plus.

Ce que le product builder aurait livré

Reprenons la même demande dans une équipe de product builders. Mardi soir, quelqu'un génère un export sur mesure pour le logiciel du client. Jeudi, il est en production. Le produit compte deux exports, bientôt cinq quand les trois clients du support reviendront avec leurs propres logiciels. La note d'arbitrage n'a jamais été relue. La documentation décrit l'ancien comportement. L'argumentaire promet encore autre chose.

Chaque export, pris seul, se justifie. Ensemble, ils font grossir le produit. Le product builder a répondu au client. Le product manager a répondu au produit.

La base sert aussi après coup. Six mois plus tard, le product manager regarde si les clients utilisent le nouveau modèle d'export. S'ils ne s'en servent pas, la base le montre, avec tout ce qui avait justifié la décision. Il peut proposer de retirer la fonctionnalité avec des preuves, et l'équipe en discute sur pièces. La stratégie dit ce qui mérite de rester. La base dit ce qui est vraiment utilisé.

Dans toute cette histoire, le product manager n'a rien construit. Il a réuni les bonnes personnes autour des bons faits, obtenu une décision et validé ce que tous les agents de l'entreprise devraient désormais tenir pour vrai. Les deux prochains articles regarderont comment constituer cette base à partir de ce qui existe déjà, et comment elle prépare les réunions.

Dans votre organisation, combien de temps une demande client met-elle à devenir une décision que tout le monde, agents compris, applique de la même façon ?

---

Premier article d'une série sur le product manager et la base de connaissance produit. Sources : enquête State of AI in Product 2026 (Melissa Perri et Product Circle, avril-mai 2026, 309 dirigeants produit) ; synthèse de Rian van der Merwe, How AI is changing product management (Elezea, août 2026). L'exemple de l'éditeur de logiciel d'entrepôt est fictif.