Idée principale

La crainte habituelle — les profils produit vont remplacer les développeurs — se trompe de mouvement. Ce qui peut effectivement partir ailleurs est une catégorie identifiable : l'export demandé en urgence, l'écran de consultation, le tableau de bord, l'interface temporaire, tout ce pour quoi on sort régulièrement une équipe du cœur du produit. Qu'une partie de ces demandes soit absorbée par les équipes produit, support ou métier soulage la chaîne au lieu de la réduire.

Ce qui apparaît en face n'est pas moins technique. Pour que d'autres puissent produire sans casser, il faut des API internes propres, des composants réutilisables, des conventions tenues, des environnements sûrs, des droits cadrés, des contrôles automatiques. Construire cela demande de décider ce qui doit être exposé, sous quelle forme, avec quelles garanties et quelles limites — un travail d'architecture, pas d'implémentation.

Le métier ne rétrécit donc pas : il remonte d'un cran, de la construction des fonctionnalités vers la construction de ce qui rend possible la production des autres.

Pourquoi c'est important

Cela donne une réponse à l'inquiétude autrement que par la réassurance. Dire « les développeurs ne seront pas remplacés » ne convainc personne ; montrer quelle est la charge nouvelle, et qu'elle est plus architecturale que la précédente, se vérifie.

Cela indique aussi la condition sans laquelle l'ouverture à d'autres fonctions échoue : si personne ne construit le terrain, l'ouverture produit du bricolage, et le temps prétendument économisé revient en réparations.

Nuances et limites

Le déplacement suppose que l'organisation accepte de financer un travail dont la valeur est indirecte. Une plateforme interne ne livre rien de visible au client, et c'est la première ligne qu'on coupe sous pression.

Toutes les compétences ne se transposent pas non plus : concevoir des interfaces internes destinées à être consommées par d'autres fonctions n'est pas le même métier que développer une fonctionnalité de bout en bout.

Questions ouvertes

• Une équipe qui construit des rails sans jamais construire de fonctionnalité conserve-t-elle la connaissance du terrain nécessaire pour concevoir de bons rails ?