Idée principale

Un écran de consultation, un export, un tableau de bord, un requêteur monté par une équipe produit se situent à côté du produit : ils consomment des API, agrègent de l'information, et produisent une interface utile à celui qui l'a faite ou à son équipe. Ce qu'ils cassent en cassant, c'est eux-mêmes.

Un module, un parcours ou une variation fonctionnelle construits sur la codebase de l'entreprise se situent dans son prolongement. Ils réutilisent les briques existantes, le langage métier du code, les composants maison — et ils s'inscrivent dans le même dépôt, avec les mêmes dépendances et les mêmes clients au bout. Ce qu'ils cassent en cassant, c'est le produit.

La distinction n'est pas une différence de taille ni d'ambition : c'est une différence de surface d'impact, et c'est elle qui devrait décider du régime d'exigence, pas le fait qu'un profil produit ou un développeur tienne le clavier.

Pourquoi c'est important

Cela donne un critère opérationnel là où la discussion reste d'ordinaire sur le niveau de la personne. « À côté » ou « dans le prolongement » se constate en regardant où le code atterrit et qui en dépend ; « assez compétent » ne se constate pas.

Cela dessine aussi deux trajectoires distinctes et non équivalentes : soulager les développeurs des petits outils internes est un objectif modeste et atteignable ; permettre à des profils produit de contribuer au produit lui-même est un autre sujet, avec d'autres conditions.

Nuances et limites

La frontière n'est pas étanche. Un outil construit à côté qui écrit dans la base de production a la surface d'impact d'un objet du prolongement, quelle que soit sa localisation dans le dépôt.

Et l'écart de risque ne dit rien de l'écart de valeur : l'objet le plus utile n'est pas toujours celui qui touche le produit.

Questions ouvertes

• Jusqu'où une organisation peut-elle laisser des profils produit construire dans le prolongement du produit sans perdre la maîtrise technique, la cohérence et la sécurité de l'ensemble ?