Auparavant, il y avait des ingénieurs logiciels, des chefs de produit et des designers. Aujourd'hui, ces rôles fusionnent : une même personne est responsable du produit et du code, comprend les utilisateurs et assume la responsabilité des résultats.
Mais jusqu'à il y a environ un an, l'organigramme et ses intitulés de poste restaient inchangés. L'été dernier, un changement s'est opéré, et les entreprises ont commencé à recruter un nouveau type de profil : l'ingénieur produit.
Aujourd'hui, le terme « ingénieur produit » est mentionné 100 fois par semaine. C'est une augmentation d'environ 335 % depuis juin 2020, mais cette croissance ne s'est vraiment accélérée qu'à partir de mai 2025.
Alors, en quoi consiste ce nouveau rôle ?
Qu'est-ce qu'un ingénieur produit ?
Dans les entreprises d'aujourd'hui, l'ingénieur produit est exactement ce que son nom indique : quelqu'un qui combine le sens du produit avec une expertise technique pour prototyper, construire et itérer rapidement.
Voici ce qu'a déclaré notre Chief AI Officer, Zain Lakhani :
« Traditionnellement, un ingénieur livre quelque chose, un chef de produit parle aux utilisateurs pour voir si c'était viable ou non, et cette boucle se répète. Mais à mesure que nous nous rapprochons du centre du spectre — ce que j'appellerai les "ingénieurs produit" — c'est un one-man-band. Quelqu'un qui livre, itère, collecte les retours utilisateurs et itère à nouveau, le tout en une seule personne, plutôt que de répartir cela entre l'ingénierie, le produit et le design. »
Parce qu'ils peuvent passer moins de temps à écrire du code grâce à Codex, Claude Code ou leur agent préféré, ce rôle se concentre sur des tâches à plus haute valeur ajoutée : la résolution créative de problèmes, les échanges avec les utilisateurs, et les réponses aux « et si » qui trottent dans un coin de leur tête.
Si cela peut sembler être une menace pour les designers ou les chefs de produit, c'est en réalité une promesse de collaboration. Voici ce que dit Productengineer.org dans une lettre ouverte aux product designers :
« Vous entendez peut-être parler d'"ingénierie produit" et vous demandez si nous cherchons à empiéter sur vos plates-bandes… Mais la vérité, c'est que c'est surtout écrit pour nous-mêmes. C'est un rappel d'arrêter de coder et de commencer à réfléchir. De regarder au-delà du ticket Jira et de se demander : est-ce que ça semble juste ? Est-ce intuitif ? Serions-nous fiers de livrer ça ? »
Ce que les entreprises attendent des ingénieurs produit
Les ingénieurs produit sont bien plus que de simples développeurs. Ils allient jugement et sens esthétique, orientation data et exécution technique pour identifier les problèmes fondamentaux, comprendre les utilisateurs et donner vie aux solutions.
Dans cette offre d'emploi pour un ingénieur produit, le rôle équilibre l'ingénierie technique et le sens du produit : développer des outils propulsés par des LLM et livrer des fonctionnalités, tout en échangeant avec le public cible, en façonnant la direction de la plateforme et en maintenant un excellent sens du produit.
Le rôle reste également ancré dans l'ingénierie, et les entreprises orientées produit et destinées aux développeurs défendent ce concept.
En quoi est-ce différent du rôle de PM qui existe depuis des décennies ?
Ingénieur produit vs. chef de produit : ce qui change, et ce qui reste
Voici une autre façon d'envisager cette répartition du travail entre les PMs et les ingénieurs produit : les PMs sont propriétaires du « pourquoi » et du « quoi », tandis que les ingénieurs produit gèrent la boucle complète, en agissant eux-mêmes sur les retours.
Voici comment nous envisageons cette répartition du travail :
| Product Managers | Product Engineers | |
|---|---|---|
| Primary focus | What to build, and why | What to build, how to build it, and if it worked |
| Feedback ownership | Partial. Collects feedback and hands it off to developers | End-to-end. Ships and learns themselves |
| Code ownership | None | Writes and ships it |
| User relationship | Interviews, research, and synthesis | Direct: reads product data and iterates in real-time |
| Works through | Backlogs, PRDs, and handoffs | Coding agents Analytics and product agents Judgement |
Voici où ils se rejoignent : définir les problèmes des utilisateurs, orienter la direction du produit et prioriser ce qui doit être développé. Mais posséder cette boucle complète implique ses propres compromis.
3 défis fondamentaux auxquels font face les Product Engineers
À mesure que ce rôle prend forme dans les organisations, voici quelques défis fondamentaux auxquels font face les product engineers :
- Moins de garde-fous. La rapidité est la priorité (et l'objectif). Mais passer du prototype à la production avec moins de temps pour tester, réfléchir à la stratégie et itérer signifie qu'il y a plus de risques derrière ce que vous livrez.
- Des analytics réactives. Parce que vous livrez à un rythme totalement nouveau, les plateformes traditionnelles d'analytics produit et de mesure peinent à suivre. Les PMs définissaient autrefois ce qu'il fallait mesurer, mais désormais les Product Engineers ont besoin d'insights proactifs : des outils qui font remonter les signaux comportementaux et vous indiquent ce qu'il faut développer ensuite et où vous êtes déjà efficace (comme Slack).
- L'instrumentation reléguée au second plan. L'observabilité, la recherche et les tests peuvent sembler fastidieux, mais c'est ce qui distingue un produit passable d'un excellent produit. Sur le marché actuel, cela est généralement traité comme une deuxième étape alors que cela devrait être la première, et nous avons commis la même erreur lors de la création de Novus.
Ce que cela signifie pour vous
Tout cela pointe vers un changement plus large : les généralistes sont en train de gagner. Vous devez être capable de penser comme un product manager, de parler aux utilisateurs, d'analyser des données et de livrer du code sans le traditionnel processus de passation en trois réunions.
La question n'est plus « devrais-je recruter un product engineer ? » Si vous lisez ceci, vous connaissez probablement déjà la réponse : un oui retentissant. La vraie question est plutôt : comment vous donner les bonnes bases pour fonctionner de cette façon ?
La partie la plus difficile maintenant est de savoir quoi développer ensuite, et si ce que vous avez livré fonctionne réellement.
Cela nécessite de rester proche de vos utilisateurs et de vos données, et c'est ce qui distingue un Product Engineer de quelqu'un qui livre n'importe quoi.
Bonne nouvelle : c'est exactement pour cela que nous avons créé Novus. C'est gratuit, alors vous pouvez commencer dès aujourd'hui.
