Idée principale

Un développeur qui utilise un agent de code et livre trois fois plus vite ne change pas de rôle pour autant. S'il n'a accès ni aux clients, ni aux données d'usage, ni au contexte business, ni aux arbitrages de priorité, ce qu'il gagne est une charge : plus de fonctionnalités portées, plus de pression sur les délais, plus de décisions locales à prendre dans le flou — sans le pouvoir produit qui permettrait de trancher autrement que par défaut.

C'est la différence entre porter une part du jugement produit au plus près de la construction et piloter une machine à produire. La première suppose un accès ; la seconde ne suppose qu'un outil.

Une organisation qui annonce redistribuer l'ownership produit vers ceux qui construisent, sans ouvrir en même temps l'accès au client, aux données et aux arbitrages, redistribue donc la responsabilité et garde le pouvoir. La montée en rôle est nominale.

Pourquoi c'est important

Cela donne un test à poser à toute redistribution annoncée : qu'est-ce que la personne a obtenu le droit de voir et de trancher, en plus de ce qu'elle a obtenu le droit de livrer ?

Et cela nomme un risque de dégradation silencieuse : l'équipe est plus productive, les indicateurs de livraison s'améliorent, et le travail devient moins tenable pour ceux qui le font.

Nuances et limites

L'accès ne suffit pas non plus. Rencontrer des clients sans le temps de digérer ce qu'on y entend, ou assister aux arbitrages sans y peser, reproduit le même effet avec une apparence d'ouverture.

Et tous les développeurs ne souhaitent pas ce déplacement : certains veulent construire, pas arbitrer, et leur imposer un ownership produit dégrade le travail au lieu de l'enrichir.

Questions ouvertes

• Quel niveau d'accès aux clients et aux arbitrages suffit à rendre l'ownership réel, sans transformer l'équipe de développement en équipe de discovery ?