La compétence était réelle. Le poste, non.

---

Quelque part dans la dernière décennie, un ensemble de compétences a été promu en ligne de paie.

Product Owner. Ingénieur QA. Ingénieur sécurité. Ingénieur DevOps. Et bien d'autres. Aucun de ces postes n'existait séparément il y a vingt ans. Aujourd'hui, la plupart des organisations d'ingénierie recrutent et budgètent comme s'ils avaient toujours existé. Chacun désigne quelque chose de réel : le jugement produit, le jugement de test, le jugement sécurité, le jugement opérationnel. Aucun n'a jamais exigé une personne incapable de faire autre chose.

Le développement et l'architecture ont connu une version du même mouvement. Dans certaines organisations, un intitulé « architecte solution » s'est détaché du développeur senior qui portait autrefois les deux. Mais cette paire a surtout résisté à la scission. Un tech lead, par défaut, porte déjà le jugement de développement et le jugement d'architecture. Ça n'a jamais été la part qui avait besoin de son propre poste.

Entre la première certification Scrum et le quarantième canal Slack dédié, les autres compétences ont reçu un poste à la place. Les postes se sont mis à agir comme si la compétence devait être protégée du reste de l'équipe.

Voici un retour d'expérience. Ce qui se passe quand on remet le poste là où la compétence est née. Ça a marché chez moi.

Je ne pense pas que la forme précise soit universelle. Le tech lead qui absorbe le product ownership par-dessus une expertise qu'il avait déjà, c'est ce qui s'est passé ici. Une équipe fintech très exposée à la sécurité atterrirait ailleurs. À juste titre.

Ce qui se généralise, en route vers 2027, c'est le diagnostic. C'est le poste, pas la compétence, qu'une organisation véloce ne peut plus financer. Si vous fonctionnez en régime IA-native, l'organigramme que vous avez hérité est désormais ce que vous avez de plus lent.

Un poste achetait de la coordination. Il achetait rarement le jugement dont il portait le nom.

Ce que la décennie a vraiment construit

Je veux être honnête sur l'histoire avant de la contester : la version cynique est aussi la version paresseuse. Trois choses se sont produites en même temps, et une seule mérite l'accusation.

La première est réelle. La complexité a grandi plus vite qu'un seul ingénieur ne pouvait la porter. La surface de sécurité, la topologie cloud, la traçabilité réglementaire — chacune est devenue assez profonde pour qu'un généraliste survolant les trois fasse pire qu'un spécialiste n'en tenant qu'une. Du moins à une certaine taille d'équipe.

La deuxième est réelle aussi. Une fois qu'une organisation dépasse une pièce où tout le monde tient, quelqu'un doit faire l'intégration entre équipes. Ce travail est réellement à temps plein, passé une certaine échelle. Des cadres conçus pour ce moment-là — le Scaled Agile Framework, par exemple — publient des catalogues entiers de rôles : Product Owner, Release Train Engineer, Solution Architect. La réponse honnête à un vrai problème de coordination, sur des centaines d'ingénieurs.

La troisième est celle que je conteste vraiment. Ces mêmes catalogues ont été installés dans des équipes dix fois plus petites. Le poste a survécu bien après que le problème de coordination qu'il résolvait s'était réduit.

Personne n'a écrit ça comme un plan. C'est arrivé une réorganisation à la fois, chacune localement raisonnable. Une promotion avait besoin d'un titre. Un titre avait besoin d'un périmètre. Un périmètre avait besoin d'une ligne d'effectif pour le protéger.

Le résultat ressemble, de là où je suis, moins à de la spécialisation qu'à une couche de pilotage. Un poste dont la production principale était du statut, pas du jugement. Son existence permettait aux gens qui faisaient le travail de cesser de se sentir responsables des parties que le poste couvrait désormais.

Cette lecture est la mienne. Aucun des cadres que je vais citer ne la fait à ma place.

Team Topologies s'approche le plus d'une version citable du mécanisme. Mais défend une thèse plus étroite que la mienne. La charge cognitive est finie, donc une équipe devrait se débarrasser de tout relais dont elle n'a pas besoin.

Les propres recherches de DORA confortent le même instinct côté systèmes. Les organisations les plus performantes sont mesurablement plus susceptibles d'adopter une architecture faiblement couplée. Précisément parce que cela retire la dépendance inter-équipes du chemin critique.

Ni l'un ni l'autre ne plaide pour fusionner le PO, la sécurité et l'expertise métier en une seule personne. Ce qu'ils défendent est plus simple : chaque relais a un coût. Une organisation qui continue d'ajouter des postes sans se demander quel relais chacun ajoute paie ce coût à l'aveugle.

Cet argument devient plus tranchant une fois les agents dans la boucle. Ils absorbent l'essentiel du travail de relais qu'un poste servait à justifier. Ce qui reste rare, ce n'est pas la production. C'est la charge cognitive finie de qui doit encore décider. Chaque poste encore debout après que son besoin de coordination a fondu est une ponction sur ce même budget limité.

Le précédent le plus net pour la disparition réelle d'un poste — pas juste la réduction de ses relais — c'est la disparition d'un intitulé « opérations » dédié. Werner Vogels l'a décrit en 2006. Donner aux développeurs d'Amazon la responsabilité opérationnelle de ce qu'ils construisaient a fait monter la qualité des deux côtés d'un vieux mur. Le mur entre construire un logiciel et l'exploiter. Les deux moitiés de ce jugement — bien construire, bien exploiter — n'avaient en réalité jamais eu besoin de deux personnes différentes.

Netflix a écrit le même mouvement une décennie plus tard, sous le nom de « full-cycle developers ». Les postes séparés de SRE et de test, repliés dans la personne qui écrit le changement.

Le test et la sécurité vivent le même mouvement en ce moment. Ça s'appelle « shift left ». Au lieu d'un poste QA qui attrape en aval ce qu'un développeur a manqué, ou d'un poste sécurité qui verrouille une livraison à la fin, la compétence revient à qui est déjà le plus proche du changement au moment où il est fait.

Un retour d'expérience, pas un modèle

Sur Solstice*, je suis tech lead côté ingénierie d'un ERP hospitalier. J'ai passé assez d'années dans ce domaine pour connaître les tenants et aboutissants du parcours patient — la gestion de son identité, ses spécificités — avant même de toucher un backlog.

Le titre de tech lead impliquait déjà que je possédais le jugement d'architecture et le jugement de développement. Ça n'a jamais été en question. Ce n'est pas ce qui a changé.

Ce qui a changé, c'est le troisième : le jugement métier. Comprendre ce dont un hôpital a réellement besoin, et le transformer en priorité. Ça repose, d'ordinaire, sur un PO séparé.

Dès le début du projet Solstice, j'ai pris la responsabilité du produit. Nous avons construit une équipe très restreinte, sans PO séparé : je prends les décisions produit moi-même, dans la même conversation où je prends la décision technique. L'atelier hebdomadaire se termine avec les tickets déjà écrits, parce que la personne qui décide ce qu'on construit, et la personne qui comprend pourquoi le module certifié gère la rétention d'une certaine façon, sont la même personne. Même réunion. Même moment.

Dire pourquoi cette organisation tient compte plus que le fait qu'elle existe. Le travail de relais qu'un PO séparé aurait porté — alimenter le backlog, formater des tickets, courir après les statuts pour un comité de pilotage — c'est exactement le travail que les agents absorbent, comme je l'ai décrit dans un billet précédent.

Cette absorption n'est pas l'argument de ce billet-ci. Elle en est la condition. Elle libère assez d'heures dans une semaine pour qu'une seule personne porte le jugement produit et la profondeur métier en même temps, sans doubler sa charge de travail.

Avant que les agents ne fassent ce travail d'emballage, fusionner les deux rôles voulait dire qu'un des deux côtés devenait superficiel — le produit ou le technique. Maintenant, ce n'est plus obligatoire.

Je veux être direct sur ce qui, dans mon cas, ne se généralise pas. Ça a marché parce que j'avais déjà dix ans dans ce domaine avant d'ajouter la compétence produit par-dessus. Je ne demandais pas à un généraliste de devenir expert sur deux sujets à la fois. Je demandais à quelqu'un qui maîtrisait déjà à moitié l'une des deux compétences d'assumer formellement les deux.

« Promouvoir votre meilleur ingénieur pour qu'il gère aussi le backlog » est une recette d'épuisement — si la seconde compétence n'est pas déjà à moitié construite. C'est un problème de bus factor si cette personne devient la seule capable de traduire une nuance métier en contrainte technique.

Passé environ quinze à vingt ingénieurs, ou plus d'un périmètre produit, je m'attendrais à ce que cette forme précise se casse. La fusion devient deux métiers à temps plein sous un seul badge. Pas un métier avec une meilleure ergonomie.

Ce qui se généralise, ce n'est pas « faites faire ça à votre tech lead ». C'est ceci : arrêtez de supposer qu'une compétence a besoin de son propre poste, avant d'avoir vérifié si elle vit déjà à côté de la responsabilité qu'il vous faut.

Ça précise quelque chose que je n'avais qu'à moitié dit

J'ai écrit, il y a deux billets, que le jugement produit survit et se diffuse à travers les rôles. L'ingénieur qui prend des micro-décisions à l'heure. Le PM qui pilote sur des métriques de livraison. Le PO qui nourrit le contexte par l'atelier.

C'est toujours vrai à l'échelle que ce billet décrivait : une équipe multi-rôles, le mur entre produit et ingénierie qui se dissout des deux côtés à la fois.

Ce que je n'ai pas assez clairement dit à l'époque : la diffusion a une forme. Et cette forme dépend de la taille de l'équipe. Sur une équipe assez petite pour qu'une seule personne porte déjà tout le contexte, la diffusion ne reste pas répartie. Elle s'effondre sur un seul nom.

Ce n'est pas un échec de l'argument précédent. C'est ce à quoi il ressemble une fois qu'il ne reste qu'une seule personne à qui diffuser.

Je le dis directement, parce qu'un lecteur de la série remarquera le glissement avant que je ne le lui signale. Le billet précédent défendait que le jugement ne devrait pas se concentrer sur un seul rôle — pas sans une réponse qui nomme qui signe, et comment les juniors l'apprennent. Les deux réponses deviennent plus difficiles, pas plus faciles, quand le rôle est une personne au lieu de quatre.

Je ne pense pas que cela rende la fusion fausse. Je pense que cela rend la section honnête ci-dessous non négociable. Pas facultative.

Le jugement n'a pas migré vers un titre. Il est allé vers qui portait déjà la responsabilité et avait encore de la place dans sa semaine.

Là où le poste garde sa raison d'être

Rien de tout cela n'argumente pour moins de monde. Mon équipe a grandi cette année, alternants et apprentis inclus. Les heures qu'un poste fusionné libère ne disparaissent pas dans une ligne d'effectif plus courte. Elles vont vers le terrain, la profondeur métier et le travail réglementaire — ce que chaque billet de cette série a déjà qualifié de sous-financé. Même logique que le billet DORA : la valeur est dans le réinvestissement, pas dans l'extraction.

Une partie de ce que faisait un poste n'a rien d'un coût. C'est un fait légal sur la façon dont le logiciel régulé doit être construit. Aucune refonte de titre ne le change. Sur Solstice*, la personne qui écrit un changement critique pour la sécurité des patients ne peut pas être la seule à relire sa propre vérification. Ce n'est pas une préférence de management. C'est la séparation des tâches qu'un auditeur vérifie nommément. La revue de sécurité indépendante reste indépendante.

Un alternant ou un apprenti a toujours besoin de quelqu'un à observer, et d'un poste vers lequel grandir. Fusionner un titre ne fusionne pas le besoin d'enseigner la compétence à quelqu'un qui ne l'a pas encore.

Et passé la taille d'équipe où une seule personne peut porter tout le contexte, le management produit en tant que fonction cesse d'être optionnel. Il redevient réellement un temps plein. Je n'essaierais pas cette forme à dix fois la taille de mon équipe. J'aurais tort de la recommander à cette échelle.

La liste honnête, dite sans détour : la vérification indépendante sur tout ce qui touche à la sécurité des patients ou à la sûreté, un signataire responsable nommé pour chaque chaîne de décision, et une voie d'apprentissage pour qui doit hériter de la compétence ensuite. Aucun de ces trois ne survit à une fusion. Tout le reste de l'organigramme est candidat.

Deux façons de se tromper de moment

Fusionnez trop tôt, et la qualité baisse des deux côtés — le même échec qu'un généraliste trop dilué. Ne fusionnez jamais, et les relais continuent de tourner par habitude — même ceux dont l'équipe n'a plus besoin. La fenêtre entre les deux est étroite : elle s'ouvre une fois la seconde compétence déjà à moitié construite, pas avant.

Lire la suite de la série : Le SDLC est mort — pourquoi le processus a toujours été du gaspillage. Coder n'a jamais été le métier — ce que devient l'ingénieur quand la syntaxe disparaît. Le backlog n'a jamais été le métier — le billet que celui-ci précise : le jugement se diffuse à travers les rôles, jusqu'à ce que l'équipe soit trop petite pour ça. La doctrine capitalise. Pas les modèles. — où vivent les règles qui survivent à un rôle fusionné. Les tests passent. Il ne se passe rien. — l'autre compétence qui a cessé d'avoir besoin de son propre poste. DORA vient de confirmer ce que mon équipe a déjà vécu — la logique de réinvestissement que ce billet réutilise.

---

Sources

• Scaled Agile Framework — Glossaire : Product Owner, Release Train Engineer et Solution Architect sont des rôles SAFe officiels et nommés. Cité pour l'existence du catalogue de rôles, pas comme un aval du modèle de mise à l'échelle lui-même.
• Team Topologies (Skelton & Pais, 2019) : l'argument de la charge cognitive pour se débarrasser des relais inutiles au niveau de l'équipe. Plaide pour restructurer des équipes, pas fusionner des rôles individuels — j'étends sa logique plus loin que les auteurs, et je le dis plus haut.
• DORA — Loosely coupled teams : les organisations les plus performantes sont mesurablement plus susceptibles de faire tourner une architecture qui retire la dépendance inter-équipes du chemin critique. Concerne les systèmes, pas les intitulés de poste — l'analogie est mienne.
• Jim Gray, A Conversation with Werner Vogels (ACM Queue, 2006) : l'origine de « you build it, you run it » — les développeurs d'Amazon prenant la responsabilité opérationnelle de ce qu'ils construisaient.
• Full Cycle Developers at Netflix (Netflix Tech Blog, 2018) : Netflix repliant les postes séparés de SRE et de test dans le développeur, une décennie après Vogels.
• Solstice* — le cycle d'atelier et les chiffres de taille d'équipe viennent de la pratique de l'équipe elle-même. Interne, sans lien : le nom de code est fictif et le projet réel, ses produits et son éditeur sont anonymisés.