Idée principale

Un écart de capacité se creuse entre les Product Managers issus d'un parcours technique et les autres. Il ne porte ni sur la compréhension du marché, ni sur la qualité du jugement, ni sur la capacité à nommer un problème — les terrains où le métier se joue habituellement.

Il porte sur un accès. Celui qui sait lire un dépôt, suivre des merge requests et interroger un historique de commits peut travailler directement sur la matière du produit : générer un artefact depuis elle, vérifier qu'un document dit vrai, contredire une affirmation en montrant le code. Celui qui ne le sait pas doit passer par quelqu'un, et l'aller-retour coûte assez cher pour qu'il y renonce dans la plupart des cas.

L'écart est donc un écart d'outillage et non de valeur. C'est une distinction importante, parce que les deux appellent des remèdes opposés : un déficit d'aptitude se recrute, un déficit d'accès s'apprend ou s'outille.

Couche apportée par « PM, développeurs et IA : les rôles se brouillent, les responsabilités restent » (2026-08-01). L'écart d'accès se creuse encore quand le Product Manager se met à construire. Lire un dépôt, comprendre une erreur, dialoguer avec un agent de code, repérer une absurdité dans ce qui a été généré et demander la bonne revue technique conditionnent tout ce qui dépasse la maquette : tant que les outils restent faillibles, on ne peut pas ignorer ce qui se passe sous le capot. La frontière est datée, et elle peut s'inverser — si les agents deviennent nettement plus fiables, des profils venus de la psychologie, des lettres, du design ou de la recherche reprendraient l'avantage par leur capacité à exprimer finement une réalité humaine et métier.

Pourquoi c'est important

Cela évite la lecture identitaire — « les PM techniques sont meilleurs » — qui ferme la discussion, et lui substitue une question traitable : de quel accès un PM non technique a-t-il besoin, et à quel prix peut-il l'acquérir ?

Cela dit aussi ce qui se passe si rien n'est fait : l'écart ne se résorbe pas tout seul, parce qu'il se cumule. Chaque vérification faite directement affine la compréhension du produit, qui rend la vérification suivante plus rapide.

Nuances et limites

L'accès n'est pas un avantage sans revers : le PM technique peut se mettre à traiter les problèmes qu'il sait résoudre par le code, au détriment de ceux qui relèvent du marché.

Et la frontière bouge. Les outils qui rendent un dépôt interrogeable en langage naturel abaissent le coût de l'accès sans le supprimer — la culture technique reste nécessaire pour savoir quoi demander et pour juger de la réponse.

Questions ouvertes

• Quelle forme d'apprentissage donne à un PM non technique l'accès utile sans en faire un développeur ?