Idée principale

Quand produire et maintenir des documents, des tickets et des comptes rendus absorbe la majorité des journées d'un Product Manager, cette production finit par définir le poste : on recrute dessus, on l'évalue dessus, on la décrit dans les fiches de poste. Non parce qu'elle a été jugée essentielle, mais parce qu'elle occupait la place.

Le coût agit ici comme une preuve trompeuse : ce qui est lourd paraît important. Une tâche qui prend six heures par semaine devient un objet de reporting, une compétence affichée, une identité professionnelle.

La démonstration se fait à l'envers, et elle est brutale : quand le coût de cette couche s'effondre, on découvre qu'elle n'était pas le métier. Rien d'autre n'a changé — ni le produit, ni le marché, ni ce qu'on attendait vraiment du rôle.

Le mécanisme ne s'arrête pas à la définition d'un poste existant : il en fabrique de nouveaux. Quand la couche devient assez lourde, on lui dédie un intitulé — Product Owner — et une fiche de poste construite autour de la transmission d'information. Le poste hérite alors du même sort que la définition : il se justifiait par un coût, et il devient difficile à défendre quand ce coût tombe.

Couche apportée par « Le PO n'est pas un métier, c'est une fonction » (2026-08-03).

Couche apportée par « PM, développeurs et IA : les rôles se brouillent, les responsabilités restent » (2026-08-01). Le mécanisme joue aussi à l'intérieur d'un métier, sur ce qui distinguait ses praticiens les uns des autres. Écrire une spécification correcte, produire une première analyse de données, monter un benchmark, rédiger une release note, faire une maquette acceptable, synthétiser des entretiens : ces productions différenciaient les Product Managers entre eux tant qu'elles restaient coûteuses. Quand elles deviennent accessibles, elles ne quittent pas le métier — elles passent du rang de signe distinctif à celui de niveau minimum, et ceux dont la valeur tenait à cette exécution intermédiaire la perdent sans que rien du produit ni du marché n'ait changé.

Pourquoi c'est important

Cela explique pourquoi une automatisation est vécue comme une menace identitaire plutôt que comme un gain : elle ne retire pas seulement des heures, elle retire ce sur quoi la compétence était visible.

Et cela donne un test rétrospectif utile : ce qui disparaît sans que personne ne cherche à le rétablir n'était pas le cœur du métier.

Nuances et limites

L'effondrement du coût ne prouve pas à lui seul que la couche était accessoire. Certaines tâches lourdes sont lourdes parce qu'elles sont réellement décisives, et les automatiser en dégrade silencieusement le résultat.

Et une couche accessoire peut porter des effets secondaires réels : rédiger une spécification à la main oblige à la lire, et ce détour disparaît avec la corvée.

Questions ouvertes

• Comment distinguer, avant de l'automatiser, une tâche lourde et accessoire d'une tâche lourde parce que décisive ?