« Product engineer » ressemble à un nouveau titre pour un ancien métier, mais la différence existe bel et bien. On mesure l’ingénieur classique à sa production : tickets fermés, fonctionnalités livrées conformément aux spécifications. On mesure le product engineer aux résultats : les utilisateurs ont-ils réellement accompli l’action ? L’indicateur a-t-il évolué ? L’entreprise a-t-elle obtenu ce pour quoi elle a payé ? Le code ne change pas ; la question posée avant de l’écrire, si.
Concrètement, le product engineer aborde le travail autrement. Il demande « pourquoi » avant « comment » : quel problème résout-on, pour qui et comment vérifier que cela fonctionne ? Il remet en question une spécification lorsqu’une solution plus simple apporte la même valeur trois fois plus vite. Il pense à tout le parcours utilisateur — chargement, erreurs et états vides compris — et pas seulement au scénario idéal de la maquette. Après le lancement, il consulte les données analytiques, les tickets de support et les enregistrements de session, pas uniquement le badge CI vert.
Le rôle demande de la polyvalence. Il n’est pas nécessaire d’être le meilleur spécialiste des bases de données ou le meilleur designer, mais il faut être à l’aise tout au long du parcours : modèle de données, API, UI, déploiement, analytique et désormais IA. C’est pourquoi les ingénieurs full-stack deviennent souvent des product engineers : lorsqu’on possède une fonctionnalité de bout en bout, personne à qui déléguer le « pourquoi ». Pour moi, cela va du schéma Postgres à l’écran Next.js, puis à l’événement qui révèle si quelqu’un l’a utilisé.
Les product engineers livrent par petites étapes et apprennent vite. La première version est une action mesurée en production, derrière un feature flag — pas une plateforme lancée dans six mois. Ils savent où faire des compromis (un panneau d’administration peut être peu élégant, une étape rester manuelle un mois) et où ne pas en faire (paiements, autorisations, intégrité des données). Ce discernement constitue l’essentiel du travail et ne s’acquiert qu’en assumant les conséquences de ses décisions.
C’est aussi un rôle de communication. Le product engineer parle aux fondateurs de risques, de coûts et de délais, pas de frameworks. Aux designers, il explique ce qui coûte cher à construire et propose des options moins onéreuses. Il échange avec les utilisateurs dès que possible. Et il consigne les décisions : six mois plus tard, une courte note expliquant un choix vaut souvent plus que le code lui-même.
Je me définis comme product engineer parce que c’est la partie du travail qui compte le plus pour moi : pas la pull request, mais le moment où une vraie personne utilise ce que nous avons construit et où tout fonctionne. C’est aussi pourquoi je préfère les collaborations durables aux passations après deux semaines : impossible d’assumer un résultat sans être là pour en constater les effets. Si vous cherchez un ingénieur qui posera les questions qui dérangent puis livrera une solution, écrivez-moi.
Donnez à votre prochain produit quelqu’un qui reste.
Prêt à commencer ? Écrivez-moi — je peux démarrer immédiatement et rester dans la durée. Des collaborations à long terme, pas une passation après deux semaines. Discutons de votre projet, de vos exigences et de la meilleure façon d’avancer.