Les trois portes du product manager à l'ère des squads agentiques

Ce que j'avais promis dans mon précédent article — trois convictions qui se précisent, pas encore un retour d'expérience

Je terminais mon dernier article sur un aveu d'incertitude. Je ne savais pas encore si les trois portes que je voyais se dessiner — spécifier, arbitrer, garantir — étaient le bon découpage du rôle produit dans une squad augmentée par des agents. J'avais promis d'y revenir.

Le voici. Une précision d'abord, parce qu'elle change la nature de ce texte : ce n'est pas un retour d'expérience. Je n'ai pas encore piloté une squad entière selon ce découpage. Ce que je pose ici, ce sont des convictions qui se précisent au fil des missions, des lectures et des conversations — des intuitions assez solides pour être écrites, pas assez pour être vendues comme méthode.

Spécifier : une porte à deux vitesses

La première intuition, c'est qu'une spécification ne vaut plus pour tout le monde à la fois. Ce n'était déjà pas tout à fait vrai avec des humains — un ticket écrit pour un développeur junior n'est pas celui qu'on écrit pour un senior qui connaît le produit par cœur. Avec un agent, l'écart devient un gouffre.

D'un côté, un cadrage général qui reste une conversation. Le problème, l'utilisateur, la métrique qui prouve que ça vaut la peine. On brainstorme, on tâtonne, on accepte l'ambiguïté d'un premier jet. Pooya Golchian, dont je citais le cadre AIDLC dans l'article précédent, appelle ça Frame. De l'autre, une spécification d'une précision presque contractuelle, destinée à un lecteur qui ne demandera aucune clarification en retour. Un agent construit sur ce qu'on lui donne, même quand ce qu'on lui donne est flou — et il le fait avec une assurance parfaite.

Si cette intuition tient, le product manager ne rédige plus une spécification mais deux, de natures très différentes. La première reste un exercice de discovery classique. La seconde devient un métier en soi — écrire pour un lecteur qui n'a ni bon sens ni mémoire du contexte implicite de l'équipe. Reste à vérifier, en conditions réelles, si ce dédoublement s'installe vraiment ou si les outils finiront par absorber la seconde spec.

Arbitrer : des frontières autant qu'une roadmap

On pense l'arbitrage produit comme une question de priorité — quoi faire d'abord, quoi repousser. C'est vrai, mais probablement plus suffisant dès qu'on introduit du parallélisme agentique.

Quand plusieurs agents avancent en même temps, la question n'est plus seulement quoi construire mais où poser les frontières entre les domaines qu'on leur confie. Trop de granularité, et on multiplie les points de recollement. Pas assez, et un seul agent gère un périmètre trop large pour rester cohérent. J'évoquais dans mon article précédent les équipes AWS revenues à deux pizzas, en plus petit encore — la taille des équipes se resserre partout où l'exécution s'automatise, et ce resserrement rend le découpage en domaines d'autant plus structurant. Découper un produit en territoires assez autonomes pour tourner en parallèle et assez reliés pour ne pas se contredire, c'est un geste d'architecture autant que de priorisation. Et il me semble que personne d'autre que le product manager n'est légitime pour le tenir, parce que lui seul porte la vision d'ensemble.

Il faut sans doute aussi, au-dessus de ce découpage, une instance qui réconcilie — une couche de cohérence. Quand cinq agents avancent sur cinq domaines, quelqu'un doit vérifier à intervalles réguliers que l'ensemble raconte toujours la même histoire. Aujourd'hui, ce quelqu'un est un humain. Je ne sais pas si ça durera.

Garantir : une porte qui apprend de ses propres écarts

La troisième porte est celle que je décrivais le plus vaguement dans mon article précédent — la validation avant mise en production, la responsabilité finale. En creusant, un angle mort m'est apparu.

Garantir, ce n'est pas seulement vérifier qu'un livrable correspond au plan. C'est aussi capturer ce qui a dévié — pas pour blâmer, mais pour que le prochain cycle en ait un peu moins besoin. Comparer ce qui était prévu à ce qui a été livré, en tirer des règles qui enrichissent le contexte donné à l'agent, pour que la revue suivante soit plus légère que la précédente. Une forme de capitalisation qui rappelle l'artisan n'écrivant jamais deux fois la même remarque à son apprenti.

Sans cette boucle, garantir reste un geste isolé, répété à l'identique à chaque livraison, sans jamais s'alléger. Avec elle, la troisième porte cesse d'être un contrôle qualité pour devenir ce qui fait qu'une équipe augmentée s'améliore vraiment dans la durée — plutôt que d'aller simplement plus vite au même niveau d'erreur. C'est la conviction qui me séduit le plus intellectuellement. C'est aussi celle qui exige la discipline la plus constante, et je me demande combien d'équipes la tiendront au-delà des trois premières semaines.

L'objection qu'on me pose déjà

Une objection revient presque à chaque fois que j'expose ce découpage : si l'exécution ne coûte presque plus rien et que les agents tournent en parallèle, qu'est-ce qui empêche le produit de partir dans tous les sens ? Trois portes, c'est bien peu face à une couche médiane qui peut grossir sans limite. Je comprends la crainte — j'ai raconté dans un article précédent ce qui arrive quand personne ne tient la cohérence d'ensemble pendant que l'exécution tourne à plein régime.

Mais la réponse n'est peut-être pas de ralentir la couche médiane, ni de restreindre qui a le droit d'y contribuer. Elle serait plutôt de muscler les trois portes. Une équipe où les propositions peuvent venir de partout, mais où rien ne se construit sans passer par une spécification à deux vitesses, un découpage en domaines arbitré et une validation qui capitalise ses écarts, n'a pas besoin de filtrer à l'entrée. Le cadre fait le tri du chaos, pas le pedigree de celui qui contribue.

Ce que je ne sais toujours pas

Ce découpage tient sur le papier. Je ne sais pas s'il survivra à l'épreuve d'une équipe de taille réelle, sur plusieurs trimestres. Je ne sais pas non plus si une quatrième porte ne va pas s'imposer, quelque part entre arbitrer et garantir, le jour où les agents commenceront à proposer des arbitrages plutôt qu'à seulement les exécuter.

C'est le même principe que j'appliquais à la sandwich team elle-même : sur un terrain qui bouge tous les six mois, la meilleure preuve de sérieux n'est pas de trancher trop tôt, c'est de dire précisément où s'arrête ce qu'on sait — et où commence ce qu'on pressent seulement.

Si vous avez commencé à tester un découpage de ce genre, laquelle de ces trois portes a craqué en premier chez vous ?

---

Article nourri d'observations de mission anonymisées et de l'article précédent de ce cluster (Le rôle du product manager, ce qui bouge, ce qui reste, ce qui se renforce, juillet 2026). Ces convictions sont posées comme hypothèses de travail, à confirmer ou à corriger au prochain terrain.