Depuis quelques mois, Product Engineer est le terme par lequel je me présente professionnellement. C'est un nouveau rôle qui prend de l'ampleur depuis 2025, popularisé côté startups américaines par PostHog, et plus largement porté par l'arrivée de l'IA dans le quotidien des équipes produit.
L'idée est simple : un même profil pense, designe et code un produit, du cadrage à la mise en production. Là où il fallait il y a encore quelques années une équipe pluridisciplinaire (Product Manager, Designer, Développeur à minima) pour livrer un projet web d'envergure, un Product Engineer peut désormais s'en charger seul.
Voilà ce que recouvre concrètement le métier : d'où il vient, comment je le pratique au quotidien, et dans quels cas faire appel à ce profil plutôt qu'à une équipe classique.
D'où vient le terme
Le terme « Product Engineer » est apparu côté startups américaines il y a plusieurs années, chez des boîtes comme Stripe, Linear ou PostHog. Il désigne un développeur qui s'occupe du produit autant qu'il code : il parle aux utilisateurs, il arbitre des choix de conception, il pousse des idées de feature plutôt que d'attendre une spec.
Ce n'est donc pas un rôle tout à fait récent, mais il gagne en popularité maintenant parce que les outils IA ont supprimé les goulots d'étranglement qui rendaient ce profil difficile à exercer.
Côté code, l'arrivée successive de Cursor, Claude Code, Lovable et Codex permet de livrer en quelques jours ce qui aurait pris plusieurs semaines auparavant. Côté design, Figma assisté par IA et des nouveaux outils comme MagicPath rendent un fondateur solo capable de livrer une interface présentable. Côté produit, ChatGPT et Claude structurent un brief, une roadmap ou une spec en quelques minutes.
Il faut bien sûr des compétences dans chaque domaine : produit, design et dev pour piloter efficacement les IA, et leur faire produire un travail qualitatif. Mais la force de travail d'une personne est totalement démultipliée par les IA. Cela amène un changement de structure d'équipe possible. Un seul profil peut désormais couvrir trois métiers en s'appuyant sur l'IA.
Product Engineer, Product Manager, Designer : trois rôles, une frontière qui bouge
Le cadre historique reste utile pour situer le Product Engineer.
- Le Product Manager pose la stratégie, priorise les sujets, aligne les équipes, mesure l'impact business. Il pense le « pourquoi » et le « quoi ».
- Le Product Designer conçoit l'expérience, l'interface, le système. Il pense le « comment l'utilisateur le vit ».
- Le Software Engineer exécute, code, déploie. Il pense le « comment ça tient en production ».
Le Product Engineer recouvre les trois sur un périmètre resserré : un produit, une feature majeure, un MVP. Il porte le « pourquoi », le « comment l'utilisateur le vit » et le « comment ça tient en production » sur le même sujet, en s'appuyant sur l'IA comme amplificateur de chaque couche.
Cette polyvalence ne remplace pas les autres rôles, elle s'y ajoute. Un PM continue de piloter une vision produit à plusieurs années, un Designer fait vivre un design system cohérent à l'échelle, un Software Engineer tient une infra critique en production. Le Product Engineer, lui, prend en charge un sujet de bout en bout et le livre.
C'est ce qui le rend utile à tous les stades. Un fondateur solo s'en sert pour passer de l'idée au SaaS en quelques semaines. Une équipe produit l'embarque pour prototyper avant d'engager le pipeline dev. Une scale-up lui confie une initiative spécifique (une couche IA, un serveur MCP, un nouveau parcours utilisateur), sans avoir à grossir l'équipe ni à mobiliser trois profils en parallèle.
Ce qui change avec l'IA, ce n'est pas que les autres métiers se réduisent. C'est qu'un quatrième rôle vient s'ajouter.
Ce qu'un Product Engineer n'est pas
Il ne faut néanmoins pas confondre ce profil avec d'autres rôles :
- Ce n'est pas un dev full-stack avec un titre cool. Un dev full-stack écrit du code à partir d'une spec. Un Product Engineer écrit la spec, puis le code, puis itère sur l'usage.
- Ce n'est pas un Product Manager qui vibe code. Un PM n'arbitrera pas un choix d'architecture et ne fera pas de refacto d'optimisation.
Ce que je fais concrètement, dans une journée
Une journée typique d'un Product Engineer alterne entre les rôles et tâches.
Le matin, je peux travailler une spec produit. Pas un PRD de 10 pages, mais une note structurée au format Markdown, avec le problème, les utilisateurs, le périmètre, et les arbitrages connus. Codex ou Claude m'aident à clarifier ce que je veux, et j'arbitre sur les choix stratégiques et structurels.
L'après-midi, je passe sur du code. Une fonctionnalité de bout en bout : composants Vue, fonctions Supabase, modélisation SQL. Cursor ou Codex écrivent la majorité du code. Je dirige, je relis, je teste, je refacto et j'améliore. La compétence centrale n'est pas « savoir tout faire », c'est savoir orchestrer l'IA pour faire chaque couche assez bien, en gardant un œil sur la qualité et la cohérence du résultat.
En fin de journée, je sors du code. Du SEO avec Claude Cowork, un post LinkedIn ou un tweet sur X : du contenu et de la distribution.
Quelques fois par semaine, je regarde les stats et le comportement des utilisateurs : sessions PostHog, taux de complétion d'un parcours, logs des appels MCP. C'est ce travail-là qui m'aide à savoir quoi coder par la suite.
Sur tout cela, j'arbitre seul scope, délai et dette technique. Pas de réunion de priorisation, pas de relais entre design et dev.
Quatre projets qui illustrent mon rôle de Product Engineer
Voilà ce que j'ai livré moi-même comme Product Engineer ces 18 derniers mois.
Begonia.pro, mon SaaS de Local SEO. Un SaaS complet, lancé seul. J'ai pensé le positionnement, designé les écrans, codé le frontend et le backend (Nuxt + Supabase), branché Stripe, mis en production.
Fude.md, un lecteur Markdown au design soigné. Une app desktop (Nuxt + Electron + Convex) pour lire confortablement ses fichiers Markdown, avec sync. J'ai réalisé la conception produit, le design, le code de l'app et son architecture backend, et l'ajout d'un serveur MCP qui ouvre Fude aux agents IA.
Un crawler web codé en 3 jours. Pour alimenter Begonia.pro en données SEO, il me fallait un crawler robuste qui sache lire les sites web des entrepreneurs locaux. En 3 jours, j'avais un crawler fonctionnel avec l'IA en dev assistant. Avant l'IA, le même projet m'aurait pris 2 à 3 semaines.
SIZR, une app macOS vibe-codée avec Codex. Une app utilitaire pour redimensionner précisément ses fenêtres. Je n'avais jamais codé en Swift ni pour macOS. Avec Codex, l'application a été créée et fonctionnelle en moins d'une heure.
Dans quels cas faire appel à un Product Engineer
Quatre situations où ce format prend du sens en pratique.
- Vous êtes fondateur non-tech et vous voulez un MVP rapidement. Un PE gère la conception, le design et le code en parallèle, sans passer par une chaîne agence design → studio dev → freelance ops. Vous économisez le temps de coordination autant que l'argent.
- Votre équipe produit veut prototyper avant d'engager le pipeline dev. Plutôt que de mobiliser 3 devs sur un POC qui sera jeté, un PE livre un prototype présentable en quelques jours. L'équipe valide ou enterre l'idée avant que la roadmap principale soit touchée.
- Vous êtes une scale-up qui veut intégrer une couche IA sans faire grossir l'équipe. Un PE arrive en renfort, prend en charge la feature IA de bout en bout (design, code, intégration au reste du produit), et part. Pas de recrutement, pas d'onboarding lourd.
- Vous avez un SaaS et vous voulez l'ouvrir aux agents IA. Brancher un serveur MCP à son SaaS est un bon exemple : c'est un nouvel outil standardisé pensé pour les agents IA, qu'un PE qui en a déjà fait gérera bien plus vite qu'une équipe qui découvre.
Les limites du rôle
Le rôle de Product Engineer a aussi ses limites.
Un PE ne remplace pas une équipe de 10 sur un produit mature. La bande passante d'un seul cerveau plafonne vite. À l'échelle d'un produit existant avec des dizaines de milliers d'utilisateurs, des intégrations multiples, des contraintes de sécurité fortes, et plusieurs roadmaps parallèles, un PE seul est sous-dimensionné.
La spécialisation reste utile pour beaucoup de sujets. La sécurité d'un produit qui manipule des paiements demande une expertise dédiée. L'infrastructure d'une plateforme qui sert des millions de requêtes par jour n'est pas un sujet PE. Le design system d'une boîte avec plusieurs produits non plus.
Un PE est aussi mono-périmètre : il prend un produit ou une feature à la fois. Demander à un PE de tenir 4 sujets en parallèle, cela ne marche pas.
Le Product Engineer est un rôle particulièrement adapté pour prendre en charge un produit, ou pour porter une initiative spécifique dans une organisation plus grande. Pas pour faire tourner toute une roadmap d'entreprise.
Pourquoi ce format va se généraliser
Les IA et modèles continuent de s'améliorer. Chaque mois, les outils gagnent en capacité, et la polyvalence devient plus accessible à des profils qui n'avaient pas le temps ou l'envie de la cultiver.
Ce qui va probablement émerger dans les prochaines années, c'est une structure d'équipe produit organisée autour de petits pôles « Product Engineer + spécialistes » : un PE qui porte un périmètre, entouré de profils spécialisés (sécurité, données, design system) consultés selon les sujets. Plutôt que des grandes équipes où chaque rôle joue sa partition à tour de rôle.
La forme du travail produit change.
Et vous ?
Comment votre équipe produit s'organise-t-elle face à l'IA ? Le format Product Engineer trouve-t-il sa place dans vos projets, ou préférez-vous garder une équipe pluridisciplinaire classique ?
📌 Si vous avez un MVP à sortir, un produit existant à brancher à l'IA, ou simplement un sujet produit à creuser, découvrez mes services de Product Engineering.