Et si le product builder n'existait pas ?

Ce que nos expérimentations internes nous ont appris sur l'organisation produit à l'ère de l'IA générative

Il y a quelques semaines, sur l'une de nos plateformes internes, un consultant signale une gêne d'usage qu'il vient de repérer. Rien d'extraordinaire à ce stade. C'est exactement le genre de friction qu'on traite habituellement sous forme de ticket — documenté, priorisé, spécifié, puis confié à une équipe de développement à l'horizon d'un ou deux sprints.

Sauf que cette fois, il ne fait pas de ticket. Il prompte. Il explique le problème à un assistant IA, le laisse coder, ajuste, recommence. Et le lendemain, il revient — non pas avec une description de besoin interprétable, discutable, à recadrer, mais avec une proposition déjà codée, fonctionnelle. « Voilà le problème que j'ai rencontré. Voilà comment je pense qu'il faut le résoudre. »

Le gain de temps est spectaculaire. Sa contribution n'a pas pu être intégrée telle quelle — notre cadre technique, nos prompts et nos garde-fous n'étaient pas encore assez matures pour absorber une contribution non technique sans la retravailler — mais l'essentiel du chemin était fait. La moitié de l'avancée livrée par quelqu'un dont ce n'est, en théorie, pas le métier.

C'est ce genre de moment qui fait naître le fantasme du « product builder ». Le terme circule désormais bien au-delà des conversations de couloir. On voit fleurir, depuis quelques mois, des offres d'emploi qui le portent en intitulé, jusque dans des organisations qui en faisaient encore tabou il y a un an. Derrière le mot, une promesse simple. Celle d'un profil unique, qui couvrirait seul tout le spectre — de l'intuition métier jusqu'au code livré, en passant par la spécification, le design et le test, sans relais, sans friction. Une personne, ses agents, et un produit qui s'écrit à la volée.

C'est séduisant. C'est, à mon sens, une fausse piste.

Le piège de la facilité multipliée

Reprenons la même scène, mais multipliée. Si un consultant peut livrer une fonctionnalité par lui-même, alors un PO — un Product Owner, qui porte les besoins métier au plus près des équipes de développement — le peut aussi. Et un référent métier. Et un business analyst un peu appétant techniquement. Et, pourquoi pas, un membre du COMEX qui rentre d'un week-end de prompting.

Cinquante personnes, cinquante bonnes idées, cinquante propositions déjà codées dans la même journée. À supposer même qu'on parvienne à traiter techniquement toutes ces contributions avec un niveau de qualité suffisant — ce qui est déjà une hypothèse héroïque — on se retrouve face à un problème plus profond.

Ce qu'on obtient au bout n'est plus un produit. C'est un asset. Un empilement de fonctionnalités. Tout est peut-être présent, mais tout est en désordre. Des boutons partout, une expérience qu'il faut rationaliser ensuite à coups d'UX design, une cohérence avec la vision initiale qui s'est diluée fonctionnalité après fonctionnalité.

Nous l'avons vécu sur nos propres expérimentations internes. La petite brique qui pousse à côté de la base de connaissances. La fonctionnalité qui dérive de la cible. Le mille-feuille fonctionnel qui s'épaissit, parce que personne n'a vraiment décidé de la direction d'ensemble. À un moment, sans cohérence et sans rationalisation, ce n'est tout simplement plus tenable.

D'où la question qui devrait, à mon sens, structurer toute réflexion sur le sujet. Parce qu'on peut le faire, est-ce qu'on doit le faire ?

La vraie question n'est sans doute pas celle-là. Elle est plutôt sous quelle condition ?. Et pour y répondre, il faut d'abord regarder ce que le geste suppose vraiment, au-delà de la promesse du builder solo.

Pourquoi l'humain seul avec ses agents ne suffira pas

La tentation, face au fantasme que la scène d'ouverture a fait naître, est de pousser la logique à son terme. Imaginer une squad réduite à une seule personne, augmentée d'agents, de skills, d'un harness complet, qui se concentre sur le problème métier pendant que la machine exécute. Le modèle est séduisant sur le papier. Il bute sur deux limites que l'IA ne lève pas.

La première est humaine et collective. Une équipe de deux ou trois personnes est trop fragile pour durer. Les congés, les absences, les départs, les passages à vide, les hauts et les bas de performance. Il faut un collectif d'au moins cinq à sept personnes sur un projet censé vivre dans le temps, pour absorber ces aléas. Cette contrainte n'a pas bougé avec la GenAI. Elle reste profondément humaine.

La seconde est plus subtile. La qualité d'un produit excellent naît aussi de la diversité des sensibilités réunies autour de la table. Un profil très porté sur la solution, un autre qui apporte au contraire de l'abstraction et refuse de penser tout de suite « livrable », un troisième ancré dans le métier, un quatrième en posture utilisateur. Ces différences ne sont pas du bruit. Elles sont une force. Un humain seul avec ses agents, aussi bien outillé soit-il, perd ce supplément d'âme qui naît du frottement des points de vue. Un produit ne se laisse pas davantage réduire à un seul cerveau qui l'aurait conçu d'un trait — pas plus qu'une identité ne se réduit à une seule appartenance.

Si l'humain seul avec ses agents ne suffira pas, et que le geste doit nécessairement se faire à plusieurs, une question se pose immédiatement. Faut-il pour autant inventer un rôle pour porter collectivement ce nouveau pouvoir ? Je crois que c'est l'erreur suivante à éviter.

Ce n'est pas un rôle, c'est une compétence

La tentation, face à ce nouveau pouvoir de production, est de créer un rôle pour le contenir. Le « product builder », nouvelle fiche de poste, nouvelle ligne dans l'organigramme, nouvelle prestation à vendre. C'est l'erreur classique qu'on a déjà connue avec le product management lui-même. J'ai écrit, il y a deux ans, sur ces entreprises traditionnelles qui tentaient de greffer un framework Product Management sur étagère et qui s'étonnaient ensuite que la greffe ne prenne pas. Le réflexe revient à l'identique aujourd'hui. On voit une accélération possible, on en fait un poste. On y plaque un titre, on rédige une fiche de mission, on espère que la transformation suivra le rôle. Elle ne suit jamais le rôle. Elle suit la culture.

Le product building n'est pas un rôle. C'est une compétence — qu'on peut raccrocher à des profils existants, qu'on active selon le besoin, et qu'on encadre selon le risque. Une compétence dont la valeur change d'ailleurs radicalement selon la phase du cycle de vie produit où elle est mobilisée — c'est un sujet à part entière, sur lequel je reviendrai dans un prochain article.

Ce que cela change pour les organisations

Le vrai chantier n'est pas de recruter des « product builders ». C'est de repenser le modèle de delivery pour décider, à chaque phase, qui mobilise quelle compétence — et où placer les garde-fous qui empêchent l'accélération de se transformer en empilement.

Le product builder, au fond, n'existe pas comme rôle. Et c'est tant mieux. Cela nous oblige à poser la seule question qui compte vraiment — non pas comment produire plus vite ?, mais comment produire plus vite sans cesser de faire un produit ?