Product Engineer : pourquoi l'IA fusionne le product manager et le développeur en un seul rôle

Imaginez une chaîne de production produit classique. Le product manager passe des semaines à collecter des données et à défendre son idée devant la direction, le designer dessine les maquettes, le développeur reçoit un cahier des charges prêt à l'emploi, le testeur vérifie, l'analyste examine l'A/B test. Chacun est responsable de son morceau, et l'utilisateur n'est vu, au mieux, que par une seule personne. Aujourd'hui, une offre d'emploi apparaît sur le marché qui tente de condenser toute cette chaîne en un seul rôle : Product Engineer.

Il s'agit de l'opinion d'un praticien, et non d'une étude. L'auteur travaille dans l'IT depuis plus de 20 ans, a développé Marketplace VKontakte (14 millions d'utilisateurs actifs mensuels) et lance actuellement son propre produit. Mais les signaux sur lesquels il s'appuie sont tout à fait vérifiables.

En quoi consiste ce rôle

Dans les offres de Y Combinator, de PostHog et dans l'article de l'équipe MWS/MTS, les exigences se ressemblent. Il faut un sens du produit, la capacité à parler aux utilisateurs, à formuler un problème métier, ainsi que des compétences full-stack pour réaliser soi-même la solution et la mener jusqu'à la production.

La principale différence avec un développeur ordinaire tient au périmètre de responsabilité. Le développeur classique prend une tâche déjà formulée et ne voit souvent jamais l'utilisateur final. Le Product Engineer trouve lui-même le problème, décide lui-même de ce que doit être le résultat, écrit le code, le déploie et vérifie systématiquement l'impact sur les métriques. En somme, c'est un product manager et un ingénieur en une seule personne.

L'idée n'est pas nouvelle : les entreprises rêvent depuis longtemps de tels profils polyvalents. Mais réunir chez une même personne l'esprit d'ingénieur et l'esprit entrepreneurial est presque impossible, tant les compétences et les tempéraments diffèrent. L'IA comble la partie manquante de la pile.

Pourquoi maintenant

L'auteur avance plusieurs signaux.

Usage massif de l'IA. Selon les données officielles, 11 millions de développeurs utilisent Claude Code chaque semaine, 8,5 millions Gemini et 5 millions Codex. En Russie, selon la HSE (École des hautes études en sciences économiques), l'IA est utilisée par 4,8 % des petites organisations et par 71 % des grandes entreprises informatiques. Il faut toutefois noter que l'échantillon est biaisé vers des entreprises de 500 à plus de 10 000 personnes ; les chiffres des grandes entreprises sont donc à lire avec prudence.

La routine passe à l'IA. Les product managers l'utilisent pour rechercher de l'information, analyser des données et générer des spécifications. Les développeurs, d'après l'enquête de Stack Overflow, l'emploient pour générer et refactoriser du code, déboguer, écrire des tests et de la documentation. Aux humains restent la communication, la responsabilité du résultat (vérifier, choisir la date de livraison, corriger un incident) et le leadership.

Les agents deviennent des spécialistes. Le système SKILLS.md transforme un agent en assistant spécialisé, avec instructions, mémoire et scénarios. Il existe des frameworks d'orchestration : CrewAI, Google ADK, OpenAI Agents SDK, Claude Agent SDK. L'auteur utilise lui-même l'ensemble de skills de Garry Tan, le dirigeant de YC, qui remplace en partie son équipe de développement.

Les Big Tech réduisent leurs effectifs. Oracle, Amazon, Dell, Cisco et Atlassian ont licencié des centaines de milliers de personnes. La demande pour ceux qui se contentent de taper du code à la main diminue.

Quelles compétences sont nécessaires

La liste de l'auteur peut se résumer en cinq points :

• Travailler avec l'agent comme avec un collègue. La documentation et les accès du projet sont nécessaires non seulement aux humains, mais aussi à lui ; il faut donc concevoir l'environnement pour les deux.
• Déléguer. L'agent exécute la tâche, mais la responsabilité reste la vôtre. Pour cela, il faut poser les bonnes questions et savoir évaluer le résultat.
• Savoir négocier. Auparavant, le product manager et le lead technique le faisaient à la place des techniciens ; désormais, il faudra s'en charger soi-même.
• Regard marketing. Un tiers des gens écrivent du code ; la valeur réside désormais dans la compréhension des besoins des utilisateurs et dans la proposition de valeur.
• Architecture. Une architecture solide reste nécessaire, tandis que la saisie manuelle de code perd de sa valeur.

Que faire de tout cela

Si vous êtes développeur, commencez par ce que la chaîne ne vous donnait pas : faites quelques entretiens avec des utilisateurs, mettez en place des métriques pour votre fonctionnalité et examinez-la après la mise en production. Si vous êtes product manager, essayez de construire vous-même un prototype avec un agent et de le mener jusqu'au déploiement. Si vous êtes fondateur ou si vous recrutez, vérifiez dans vos offres que vous ne demandez pas un « profil universel » sans comprendre comment il combinera les rôles.

Il existe aussi des limites. Il s'agit d'une hypothèse de l'auteur, et non d'une tendance confirmée : les offres portant cet intitulé sont encore rares, et dans les projets de plus de 100 participants, comme l'intégration de VKontakte avec Ozon, une seule personne ne suffit pas. En outre, l'IA accélère la routine mais ne supprime pas la responsabilité.

Il est probable que le Product Engineer apparaisse dans les petites équipes et les startups, où chacun a un large périmètre de tâches, tandis que dans les grandes entreprises la chaîne subsistera. L'idée elle-même reste utile : plus le chemin est court entre le problème de l'utilisateur et la métrique, moins on perd de temps et de sens dans les transmissions entre les rôles.