TL;DR La même semaine, mon fil d'actualité a enterré le PO et sauvé le PM. Un troisième post renonçait à relire ligne à ligne le code généré par l'IA. Un quatrième affirmait qu'une personne seule peut désormais porter un produit de bout en bout. Quatre posts, un seul événement : produire n'est plus ce qui est rare. La fonction de relais — alimenter un backlog, formater des tickets, faire suivre des réponses — meurt. Le jugement produit, lui, survit, et cesse d'appartenir à un seul rôle. Les personnes restent. La fiche de poste, non.

La même semaine, mon fil d'actualité a enterré le Product Owner et l'a sauvé.

Quatre posts, quatre auteurs qui ne se connaissent pas, quatre angles. Un lead product écrivait que le poste de PO a toujours été une aberration organisationnelle et devient indéfendable à l'ère de l'IA : recruter quelqu'un pour alimenter un backlog, rédiger des tickets et faire l'intermédiaire entre le métier et les développeurs, c'est optimiser une organisation déjà obsolète. Une consultante en transformation lui répondait sans le savoir : son équipe a généré en deux heures deux jours de user stories — bien rédigées, bien découpées, et déconnectées des contraintes terrain que seuls de vrais entretiens auraient fait remonter. Sa conclusion : l'outil a fait gagner des heures de rédaction, pas une minute de compréhension ; la valeur du PM se déplace vers l'arbitrage et vers une connaissance du terrain qui ne se délègue pas. Un staff engineer reconnaissait ne plus avoir la capacité de relire tout le code produit par ses agents, et que la relecture ligne à ligne n'est probablement plus le bon combat : investir dans les spécifications, donner aux agents les moyens de tester leur travail, exiger des rapports vérifiables. Et un développeur indépendant observait qu'une personne seule peut désormais porter un produit de bout en bout — le code devenant un moyen parmi d'autres, et non plus l'activité principale.

Chacun a raison sur son segment. Simplement, ils ne décrivent pas quatre choses différentes.

Quatre angles, un seul événement : la production a cessé d'être la chose rare.

LA MÊME SEMAINE · QUATRE POSTS Quatre angles. Un événement. « Le PO est indéfendable » un lead product « Le PM reste indispensable » une consultante en transformation « Je ne relis plus ligne à ligne » un staff engineer « Un produit, une seule personne » un développeur indépendant la rareté a changé de camp quatre auteurs qui ne se connaissent pas — paraphrasés, anonymisés

J'ai écrit le versant ingénierie de cette histoire il y a quelques mois : coder n'a jamais été le métier. Voici le versant produit, vu de là où je suis — lead d'une équipe sur du logiciel de santé réglementé, de l'autre côté du mur des gens du produit. Et vu de ce côté-là, le débat sur la mort du PO se trompe de cadavre.

Ce que la semaine produit contenait vraiment

Faites l'inventaire honnête de ce qui remplissait une semaine dans la configuration courroie de transmission. Alimenter le backlog. Formater des tickets pour que les développeurs les acceptent. Relayer la réponse d'un utilisateur à la question d'un développeur, puis relayer la question suivante dans l'autre sens. Courir après les statuts pour nourrir un comité. Reformater la même information pour trois publics. Rien de tout cela n'a jamais été le métier. C'était l'emballage autour du métier, et il a fini par remplir la semaine parce qu'il fallait bien que quelqu'un le fasse et que les outils étaient mauvais.

Cet emballage, c'est ce que les agents absorbent. Dans mon équipe, ce n'est plus une expérimentation : c'est écrit comme une méthode. J'ai déjà raconté les agents qui trient les tickets entrants et les panels de personas qui débattent d'une conception avant qu'un humain ne lise la synthèse. Sur Solstice*, la boucle s'est encore refermée. L'atelier produit hebdomadaire — PO, PM, tech lead, designer — est enregistré. Dans l'heure, un agent a transformé la transcription en compte rendu, en règles métier et en issues prêtes à développer. Plus personne ne rédige de tickets après la réunion. La réunion est devenue le livrable : le contexte, les contraintes, l'arbitrage — ce qui se passe dans la pièce est la seule part que l'automatisation ne peut pas extraire en sortant. Et quand on a listé nous-mêmes les chantiers ouverts de notre propre méthode, la frontière active n'était pas le code. C'était les specs. Ce constat a fini par mériter son propre billet : la doctrine qui se capitalise quand les modèles se déprécient.

La version quotidienne a la même forme. Vingt minutes d'assemblage de contexte par quelqu'un qui connaît le domaine, trente secondes de génération, puis la conversation qui compte vraiment — ce brouillon contredit la politique de rétention, on le tue ; ces deux stories supposent le même écran, on les fusionne.

Le brief est devenu le travail. La rédaction n'a jamais été que l'emballage.

LA SEMAINE PRODUIT, DÉCOMPOSÉE · ILLUSTRATIF La rédaction part. Le jugement reste. ce que les agents absorbent backlog tickets relais & statuts arbitrage terrain refus ce qui reste — et devient le métier proportions illustratives — un modèle, pas une mesure

Un point, quand même, que les fossoyeurs ratent. Le PO greffier de tickets n'est pas né greffier. Marty Cagan répète depuis dix ans que « product owner » désigne un ensemble de responsabilités dans un processus de livraison, pas une profession — et que les usines à features ont fabriqué des administrateurs de backlog par construction : des roadmaps d'output, des parties prenantes par procuration, aucun mandat pour parler aux utilisateurs. Gardez sa taxonomie, gardez votre scepticisme — il vend l'alternative « empowered » depuis vingt ans. Mais le diagnostic tient. C'est l'organisation autour du rôle qui l'a déguisé en guichet de relais. Ce que l'IA supprime, ce n'est pas la personne. C'est l'excuse de cette configuration.

Ce qui survit — et qui le signe

De quoi est faite la part jugement, concrètement ? Trois choses, vues du côté ingénierie du mur.

L'arbitrage. Quand un agent génère dix hypothèses plausibles en trente secondes, l'acte rare, c'est choisir : ce qu'on garde, ce qu'on teste, ce qu'on jette. Un choix qui tient quand le client fait remonter — donc un choix dont quelqu'un répond, nommément.

Le refus. La phrase la plus précieuse qu'une personne produit dit à mon équipe, c'est non. Non, cette exigence générée contredit la gestion de la rétention du module certifié. Non, on ne livre pas ça pour satisfaire le contournement d'un seul établissement. Refuser exige de savoir pourquoi, et de pouvoir le dire dans une langue qu'un auditeur accepte.

Le terrain. Les agents interpolent à partir des tickets, et les tickets mentent par omission. Aucun backlog ne contient le fait que l'infirmière de nuit utilise le logiciel debout, avec des gants, interrompue toutes les quatre-vingt-dix secondes. Il faut que quelqu'un ait regardé. Ce savoir-là ne sort pas d'un modèle de langage : il n'a jamais été écrit nulle part où un modèle aurait pu le lire.

Mon secteur ajoute une quatrième chose, celle que le débat LinkedIn ne touche jamais. Dans le logiciel de santé réglementé, une exigence n'est pas une tâche à faire. C'est un artefact de conformité. La chaîne qui va du besoin utilisateur à l'exigence, à l'architecture, au test de vérification n'est pas de la bureaucratie : c'est ce que l'auditeur lit, et chaque maillon porte une signature humaine qui veut dire quelque chose. Un agent peut rédiger chaque maillon de cette chaîne. Il ne peut en posséder aucun. « C'est l'agent qui l'a générée » n'est pas une provenance qu'un audit accepte — les questions restent : qui a relu, quand, selon quelle procédure.

SANTÉ RÉGLEMENTÉE · LA CHAÎNE DE TRAÇABILITÉ L'agent rédige. L'humain signe. un agent peut rédiger chaque maillon… besoin utilisateur exigence architecture test de vérification …il ne peut en posséder aucun : qui a relu, quand, selon quelle procédure le maillon généré le plus dangereux est celui qu'on approuve sans le lire

Et là, l'accélération est à double tranchant. Un PO qui rédigeait douze exigences les avait lues. Un PO qui approuve soixante exigences générées par sprint est un risque de tampon automatique. Le mode de défaillance n'est pas nouveau. Je me suis déjà fait avoir par une case à cocher que tout le monde validait et que personne ne lisait ; la même case attend désormais au milieu de la chaîne de traçabilité. L'IA rend cette chaîne moins chère à produire et plus dangereuse à tamponner. Le piège a même une forme reconnaissable : une story générée, intérieurement parfaite — testable, bien découpée, conforme à INVEST — et fausse, parce qu'elle suppose modifiable un champ verrouillé après signature pour des raisons légales. Tous les tests passent. Seule la personne qui connaît le domaine tique. Cette personne est le miroir exact de l'ingénieur que je décrivais dans le post sur le code : celle qui remarque que quelque chose cloche quand tout est vert.

La frontière se dissout — et le piège accélère

Rassemblez maintenant les deux côtés du mur. Mes ingénieurs, qui pilotent des agents toute la journée, prennent des micro-décisions produit toutes les heures : ce cas limite compte, celui-là non, ce message d'erreur va perdre une infirmière. Les gens du produit, qui briefent des agents rédigeant leurs spécifications, font de la conception. La recherche 2025 de DORA décrit le même flou à partir de ses données d'enquête — les PM et analystes utilisent l'IA pour faire un travail technique qui leur était inaccessible, les ingénieurs absorbent du travail produit. Prenez les pourcentages avec la prudence des données déclaratives ; la direction, elle, est symétrique. Sur Solstice, notre propre méthode le dit dans son tableau d'impact : le développeur devient orchestrateur d'agents ; le designer garantit un design system au lieu de produire des maquettes ; le PO nourrit le contexte par les ateliers ; le PM pilote sur des métriques mesurées au lieu d'estimations. Quatre rôles augmentés, aucun supprimé. Les deux côtés du mur n'échangent pas des tâches. Ils convergent vers la même chose rare.

L'IA a accéléré la production. Elle n'a pas accéléré la compréhension du problème. Elle en a fait la seule chose chère.

COÛT DE PRODUCTION vs COÛT DE COMPRÉHENSION · CONCEPTUEL L'écart, c'est le nouveau métier. coût de production d'une fonctionnalité coût de savoir quoi construire ce qui remplit l'écart : arbitrage, terrain, refus 2023 → 2026 coût diagramme conceptuel — des formes, pas des mesures

C'est exactement pour ça que l'accélération est dangereuse. Dix hypothèses en trente secondes, ce n'est pas dix fois plus de compréhension ; c'est dix fois plus d'output face au même déficit de découverte. Melissa Perri a nommé ce piège des années avant l'arrivée des agents : une équipe mesurée à l'output livre des fonctionnalités dont personne n'a besoin, consciencieusement et pour toujours. Une usine à features avec des agents est une usine à features plus rapide. J'ai fait le même constat pour mon propre métier dans le post sur DORA : l'IA amplifie le système que vous avez. Si votre organisation produit était une courroie de transmission, l'automatisation fait tourner la courroie plus vite. Elle ne vous dit pas que le tapis est braqué vers le mauvais mur.

Le piège a un deuxième étage, et il se trouve dans mon propre bureau — mon équipe est le contre-exemple de toute histoire trop propre. On a grandi cette année — alternants et stagiaires compris. Le jugement produit distribué est un luxe d'équipe senior. Un ingénieur senior avec des années de domaine peut absorber de l'arbitrage ; un alternant à qui on confie le même rôle fusionné produit des décisions confiantes, bien formatées et fausses — plus vite qu'avant, parce que l'agent met magnifiquement en forme l'erreur. Et le travail de relais, quel que soit son gaspillage, était accidentellement une école : écrire des tickets, même mal, c'était apprendre le domaine. Supprimez le relais et vous supprimez la rampe d'accès avec. Le remplacement doit se construire délibérément — des juniors dans les entretiens utilisateurs, des juniors qui relisent les exigences à côté d'un senior qui explique son non. C'est le même problème de vivier junior que j'ai signalé pour les ingénieurs, transposé au produit. Personne n'hérite du jugement. Quelqu'un l'enseigne.

Ce qui reste aux humains

La liste, dite simplement, parce que c'est la section que les posts-nécrologies sautent.

La responsabilité nommée. Le jugement peut se répartir dans une équipe ; la responsabilité, non. Quelqu'un signe toujours l'arbitrage, l'exigence, le refus — quelqu'un reste le nom que l'auditeur note et la personne que le client appelle à 8 h. « Le produit appartient à tout le monde » est le chemin le plus court pour qu'il n'appartienne à personne.

La découverte. Aucun agent ne parle à vos utilisateurs. Les entretiens, l'observation, le workflow regardé sur place — rien de ce qui précède n'y touche.

L'arbitrage politique. Quand le directeur médical d'un client veut une fonctionnalité que l'analyse de risque déconseille, cette négociation repose sur une relation de confiance construite sur des années. Aucune spec générée ne la tranche.

La transmission. Le chemin d'apprentissage du jugement produit, maintenant que les tâches sur lesquelles les juniors apprenaient sont automatisées.

Et ce que ce texte ne dit pas : qu'il faut moins de gens produit. Les heures libérées ont une destination — la découverte, le terrain, le travail réglementaire qui a toujours été sous l'eau. Couper dans les effectifs, ce serait couper le jugement dont tout cet article vient d'expliquer qu'il est la seule chose chère qui reste. Les équipes qui gagneront sont celles qui réinvestissent les heures, pas celles qui les moissonnent.

Lundi matin

  1. Auditez une semaine. Prenez une vraie semaine de temps produit et classez chaque heure : transmission ou jugement. Pas pour tailler dans l'équipe — pour savoir quoi automatiser et quoi protéger.
  2. Confiez une boucle de relais à un agent. La rédaction de stories à partir d'un brief est la candidate évidente. Avec un relecteur humain nommé en sortie, et une règle : approuver sans lire est le mode de défaillance que vous surveillez.
  3. Faites du brief le livrable. Le contexte, les contraintes, ce qui est interdit et pourquoi. Jugez la semaine à la qualité des briefs, pas au volume de tickets.
  4. Faites participer un ingénieur à un entretien utilisateur par sprint. Et un junior à côté de lui. Le mur tombe plus vite quand on le traverse dans les deux sens.
  5. Réécrivez une epic en énoncé de problème. Pas une liste de tickets — la description de qui a mal, quand, et comment vous saurez que ça a cessé.
  6. Nommez qui signe. Pour chaque chaîne de décision produit, un nom responsable. Si vous ne trouvez pas le nom, vous avez trouvé le problème.

Lire la suite de la série : Le SDLC est mort — pourquoi le processus a toujours été du gaspillage. Coder n'a jamais été le métier — le versant ingénierie de ce même argument. L'IA est devenue un réflexe d'équipe — à quoi ressemble une équipe IA-native un mardi. DORA vient de confirmer ce que mon équipe a déjà vécu — l'amplificateur, mesuré. 100 % du code écrit par des agents — six mois d'agents, notés. La doctrine se capitalise. Les modèles, non. — où vivent les règles qui survivent aux modèles. Les tests passent. Il ne se passe rien. — le défaut sans symptôme, et ce qui l'attrape à la place de la lecture. La compétence était réelle. Le poste, non. — à quoi ressemble la diffusion de ce billet une fois l'équipe assez petite pour s'effondrer sur un seul nom.

Sources

  • SVPG — Product Manager vs. Product Owner : la distinction, vieille de dix ans, entre le rôle Scrum et la profession. Cagan vend le modèle « empowered » — gardez la taxonomie, gardez votre scepticisme.
  • SVPG — AI Product Management: 2 Years In : le texte de janvier 2026 qui sépare PO d'équipe de livraison, PM d'usine à features et PM « empowered », et prédit l'heure des comptes pour les deux premiers.
  • Melissa Perri — Escaping the Build Trap : le cadre output contre outcome sur lequel ce post s'appuie. Écrit avant les agents ; plus pertinent depuis.
  • DORA — 2025 State of AI-assisted Software Development : le flou des rôles, dans les deux sens. Données déclaratives d'enquête — des directions, pas des décimales.
  • Mind the Product — What the data tells us about tech and PM layoffs : les chiffres de départs seniors. Personne ne sait proprement séparer l'IA de la correction post-2021, et les sources honnêtes le disent.
  • Solstice* — la méthode IA-native écrite de l'équipe : le cycle d'atelier hebdomadaire, le tableau d'impact par rôle, la liste des chantiers ouverts qui nomme les specs comme frontière active. Document interne, pas de lien : le nom de code est fictif et le projet réel, ses produits et son éditeur sont anonymisés.
  • Quatre posts LinkedIn, paraphrasés anonymement, leurs arguments intacts. Leurs auteurs ne se connaissent pas, et ne me connaissent pas. C'est un peu tout le sujet.