Le product engineer

Une personne porte la fonctionnalité. Entièrement.

Du signal client qui la déclenche aux données d'usage une semaine après la mise en production. Compréhension, spécification, jugement de design, code, tests, sécurité, lancement, documentation. C'est un nouveau métier, et il change davantage de choses dans votre système RH que dans votre dépôt.

L'agent fait le travail. L'ingénieur tranche.

Dix étapes. Lisez la colonne de gauche pour comprendre pourquoi une seule personne peut tenir l'ensemble, et celle de droite pour comprendre pourquoi il faut toujours une personne.

Étape

Ce que fait l'agent

Ce que décide le product engineer

Compréhension

Agent Transcrit chaque appel, regroupe les avis, surveille la télémétrie et signale ce qui a changé.

Ingénieur Décide quel signal mérite un changement produit, et lequel n'est que le bruit d'un client qui parle fort.
Priorité

Agent Classe les opportunités au regard des données de résultat et lance le travail dans le cadre des objectifs convenus.

Ingénieur Fixe les objectifs, et dit non à ce qui est bien classé mais n'a pas sa place.
Spécification

Agent Écrit la spécification exécutable et les critères d'acceptation à partir du contexte partagé.

Ingénieur Lève l'ambiguïté que l'agent a remontée. Porte la raison d'être réelle de la fonctionnalité.
Design

Agent Génère les parcours, les états et les déclinaisons par appareil à partir du design system.

Ingénieur Juge si l'expérience est bonne. Celle-là ne se délègue jamais complètement.
Développement

Agent Implémente et intègre le changement sur les différents dépôts.

Ingénieur Tranche sur l'architecture, et définit ce que l'agent a le droit de décider seul.
Qualité

Agent Exécute les contrôles de régression, de sécurité et multi-appareils sur chaque changement, et bloque les échecs.

Ingénieur Fixe le niveau d'exigence. Décide ce qui est un contrôle bloquant, et à quoi ressemble un risque accepté.
Sécurité

Agent Analyse les dépendances, signale les expositions, applique les correctifs connus.

Ingénieur Porte le modèle de menace, la frontière des données et tout ce qui touche à la confiance des clients.
Mise en production

Agent Livre derrière des flags, surveille le déploiement, restaure la dernière version saine en cas d'échec.

Ingénieur Décide du moment, de l'ampleur de l'impact et des clients qui la voient en premier.
Documentation

Agent Rédige et publie guides, documentation d’API et notes de version avec le changement.

Ingénieur Tranche sur le comportement que l'agent n'a pas su décrire, ce qui est souvent un comportement à corriger.
Adoption

Agent Mesure l'usage, montre où les gens décrochent, rédige le suivi.

Ingénieur Le lit une semaine plus tard et décide si la fonctionnalité a réellement fonctionné.

Nous pensons que c'est un meilleur métier. Voici l'argument.

Pas une slide sur le moral. Quatre choses précises qui changent dans la journée.

Vous voyez tout le problème

Si les ingénieurs demandent à parler aux clients, c'est que les spécifications leur arrivent dépouillées de ce qui rendait le sujet digne d'être construit. Quand vous tenez la chaîne depuis le signal, cette information est tout simplement la vôtre. L'essentiel de la frustration du métier n'a jamais été le code.

Vous voyez la conséquence

Vous livrez, et une semaine plus tard vous lisez si quelqu'un s'en est servi. Dans un modèle avec passages de relais, ce retour arrive au PM, et la personne qui a construit la chose l'apprend par hasard. Refermer cette boucle est le changement auquel les ingénieurs réagissent le plus.

La taxe de coordination disparaît

Plus de cérémonie d'affinage pour traduire une spécification que vous auriez pu lire. Plus de trois jours d'attente sur une revue. Plus de point d'avancement dont le seul objet est de dire à quelqu'un ce qu'un système sait déjà. C'est ça, le temps récupéré, et c'est l'essentiel du gain.

Le travail qui reste est celui qui en vaut la peine

Ce que les agents prennent, c'est la part répétitive, mécanique et procédurale. Ce qui reste, c'est le jugement : quoi construire, à quoi ressemble le bon, quel risque est acceptable, quoi dire au client. Un métier plus difficile, et bien plus intéressant.

Nous énonçons ici une conviction, pas un benchmark. Elle correspond à ce que nous observons dans les squads que nous avons menées, et c'est la partie du modèle que vous devriez éprouver auprès de vos propres équipes avant de vous engager.

Six choses que cela casse dans votre système RH

Une nouvelle chaîne de production demande un nouveau système de gestion des personnes. Voici les éléments qui cessent de fonctionner en premier, dans l'ordre où ils apparaissent généralement.

Architecture des emplois

Six familles deviennent une seule filière.

Product manager, product owner, frontend, backend, QA et une partie du rôle de rédacteur convergent en une seule famille de métiers. Vous gardez un product lead et un designer par squad, et vous déplacez l'expertise QA, documentation et marketing vers un pôle partagé qui sert plusieurs squads. Attendez‑vous à un catalogue d'emplois plus court et à un référentiel de niveaux plus difficile à écrire.

Recrutement

Vous cessez d'évaluer la production pour évaluer le jugement.

Un test technique où le candidat ne peut pas utiliser d'agents mesure désormais une compétence que le métier ne demande pas. Évaluez plutôt la clarté à l'écrit, la capacité à décomposer un problème ambigu, le goût dans une décision produit, et la façon dont quelqu'un relit un travail qu'il n'a pas écrit. Ce dernier point est le meilleur prédicteur que nous ayons trouvé.

Séniorité

Les niveaux cessent de désigner un périmètre de code pour désigner un périmètre de conséquence.

Quand un agent écrit l'implémentation, les années d'expérience ne séparent plus un profil intermédiaire d'un senior. Ce qui les sépare, c'est l'ampleur de l'impact : la quantité d'ambiguïté absorbée sans remonter, l'étendue de la surface qu'on peut leur confier, et la qualité de leur jugement sur les arbitrages qui ne s'automatisent pas. Réécrivez le référentiel avant de promouvoir qui que ce soit selon l'ancien.

Performance

Les tickets fermés et les lignes écrites deviennent activement trompeurs.

Les deux augmentent quand les agents arrivent, et ni l'un ni l'autre ne vous apprend quoi que ce soit. Mesurez le résultat que l'ingénieur a porté : la fonctionnalité est‑elle partie, a‑t‑elle fonctionné, a‑t‑elle demandé un retour arrière, les clients l'ont‑ils adoptée. Mesurez-le par fonctionnalité, par responsable nommé, et rendez-le visible. C'est plus honnête que le système que cela remplace, et certains trouveront cela inconfortable.

Rémunération

Un rôle qui couvre trois anciennes familles casse vos grilles.

Un product engineer fait un travail qui relevait à la fois d'une grille PM et d'une grille ingénierie. Si vous plaquez le nouveau rôle sur l'ancienne grille ingénierie, les meilleurs partent en moins d'un an. Prévoyez la refonte des grilles comme une partie de la transition, pas comme un rattrapage dix-huit mois plus tard.

La transition

Personne n'est réaffecté par un algorithme.

La plupart des développeurs deviennent product engineers, et la plupart le souhaitent. Certains PO deviennent product leads, d'autres product engineers, et certains ne voudront ni l'un ni l'autre, ce qui est une réponse légitime qui mérite une vraie conversation. La capacité que le modèle libère va à la squad qui l'attend depuis un an. Nous ne touchons à aucune conclusion sur les effectifs tant que les chiffres ne sont pas là.

Ce que vos équipes vont demander

Ces questions arrivent dès la première semaine, à chaque fois. Les réponses ci-dessous sont celles que nous donnons dans la salle.

N'est‑ce pas trois métiers pour un seul salaire ?

Ce le serait, si le volume restait. Il ne reste pas. Les agents absorbent l'implémentation, les tests, la première revue, la mécanique de mise en production et la documentation. Ce qui arrive sur l'ingénieur, c'est la couche de décision de chaque étape, soit une fraction des heures et l'essentiel de l'intérêt. Si une squad atteint le niveau 4 et que les gens travaillent plus longtemps, le workflow est mauvais et nous le dirons.

Que deviennent ceux qui adoraient écrire du code ?

Ils en écrivent toujours, sur les parties qui comptent : l'architecture, le bug difficile, ce que l'agent a subtilement raté. Ce qu'ils arrêtent, c'est le troisième endpoint CRUD de la semaine. Dans toutes les squads où nous l'avons mis en place, cet échange est bien accueilli. Les ingénieurs en difficulté sont ceux qui aimaient la prévisibilité d'une file de tickets, et cela vaut la peine de le nommer tôt plutôt que de le découvrir au troisième mois.

Perd‑on les spécialistes pointus ?

Non, vous les déplacez. L'expertise QA, sécurité, documentation et marketing produit sort de la squad pour rejoindre un pôle partagé qui définit les standards que les agents appliquent et traite les cas que les standards ne couvrent pas. Leur levier augmente, parce qu'un standard qu'ils écrivent est désormais appliqué automatiquement à chaque changement, dans chaque squad.

Et les ingénieurs juniors ?

C'est la question honnête la plus difficile du modèle. Le parcours junior classique consistait à apprendre en écrivant les tickets faciles, et ce sont désormais les agents qui les écrivent. Le parcours qui fonctionne, c'est la responsabilité d'une petite surface à faible impact dès le premier jour, avec la relecture de la production des agents comme formation principale. Cela demande plus d'attention des seniors, pas moins, et il faut le budgéter.

Qui est responsable quand un agent casse la production ?

Le product engineer nommé sur la fonctionnalité. C'est tout l'intérêt d'en nommer un. L'agent est un outil dont vous avez défini le périmètre, exactement comme une chaîne d'intégration continue. La responsabilité ne se déplace ni vers le fournisseur, ni vers le modèle, ni vers l'équipe plateforme.

Est‑ce que cela veut dire des licenciements ?

C'est votre décision, pas la nôtre, et nous ne la prendrons pas à votre place en publiant un objectif d'effectifs. Ce que nous produisons, c'est une mesure : le même périmètre tenu avec moins de personnes, ou un périmètre plus large tenu à effectif constant. La plupart des CTO avec qui nous travaillons choisissent la seconde option, parce qu'ils ont un arriéré de travail pour lequel ils n'ont jamais eu de capacité.

Le travail sur les personnes, c'est la moitié de la mission.

Deux chantiers avancent en parallèle pendant les 30 jours. Le premier est l'outillage : un dépôt prêt pour les agents, des signaux connectés, des agents réutilisables, des accès restreints, un retour arrière testé. Le second, c'est cette page, appliquée à votre squad. Nous travaillons aux côtés de votre PM, de votre designer et de vos ingénieurs, nous répondons aux doutes avec des preuves issues de leur propre dépôt, et nous coachons la squad jusqu'à ce qu'elle opère le workflow sans nous.

Nous ne sommes pas un cabinet RH et nous ne réécrivons pas votre référentiel de niveaux à votre place. Ce que nous faisons, c'est mettre le nouveau rôle sous les yeux de vraies personnes sur du vrai travail, pour que la conversation que votre équipe RH doit avoir porte sur quelque chose qu'elle a vu, plutôt que sur quelque chose qu'on lui a raconté.

Comment la squad est composée → Les six niveaux →

Découvrez où en est déjà votre squad.

Douze questions, quatre minutes. Vous obtenez votre niveau, un score par phase, et les trois étapes qui vous freinent.

Faire l'évaluation Réserver 30 min →