Qu’est-ce qu’un product engineer freelance, et quand en embaucher un ?

Si vous recrutez pour un projet web, vous avez sans doute remarqué le titre product engineer apparaître là où l’on lisait développeur frontend ou développeur full-stack. Ce n’est pas un rebranding. Il décrit une façon de travailler réellement différente, et selon votre situation, c’est peut-être exactement ce qu’il vous faut, ou plus que ce qu’il vous faut. Cet article explique la différence honnêtement.

La définition courte

Un product engineer est un ingénieur logiciel qui prend la responsabilité d’un résultat, pas d’une couche. Au lieu de « je fais le frontend React » ou « je gère l’API », l’unité de travail est : comprendre le problème, concevoir une solution, la construire à travers toutes les couches qu’elle touche, la livrer en production, et l’améliorer d’après ce que font les vrais utilisateurs.

Concrètement, sur une fonctionnalité typique, c’est une seule personne qui peut :

• questionner le besoin : quel problème résout-on vraiment ?
• esquisser l’UX et la challenger avant de rien construire
• développer l’interface, les endpoints d’API et le modèle de données derrière
• intégrer les services tiers concernés
• déployer, surveiller, et corriger ce que la réalité révèle

En quoi c’est différent d’un « développeur React »

Rien de mal à être un développeur spécialisé. Les vrais spécialistes sont exactement ce qu’il faut pour certains problèmes. La différence, c’est là où s’arrête la responsabilité.

Un spécialiste d’un framework livre ce qui a été spécifié. Quand la spécification est fausse (et les spécifications de début de projet le sont souvent), on s’en aperçoit après le développement. Un product engineer traite la spécification comme une hypothèse et pousse la discussion avant la partie coûteuse : « cette fonctionnalité existe pour réduire le churn, mais faut-il vraiment tout le dashboard, ou un seul email bien placé ? »

Cette conversation est le vrai produit. Le code en est le résidu.

Quand un product engineer freelance est le bon choix

Le profil convient le mieux quand l’ownership compte plus que le débit brut :

• Vous êtes fondateur sans co-fondateur technique. Il vous faut quelqu’un qui transforme une conversation produit en logiciel livré, sans chef de projet pour traduire au milieu.
• Votre équipe est solide mais débordée. Une personne senior capable de prendre une fonctionnalité de bout en bout, sans ticket frontend, ticket backend et réunion de coordination, ajoute de la capacité avec très peu de friction.
• Un produit existe mais patine. Application lente, base de code emmêlée, liste de fonctionnalités qui ne raccourcit jamais : quelqu’un doit profiler, prioriser et corriger à travers la stack. C’est du travail de performance et de refactoring, et il respecte rarement les frontières de couches.

Quand ce n’est pas le bon choix

Tout aussi honnêtement :

• Si vous avez des spécifications précises et besoin de nombreuses mains pour les exécuter, une équipe d’exécutants est plus rentable.
• Si votre goulot d’étranglement est un travail de spécialiste pointu (une app mobile native, de l’infrastructure ML, de l’embarqué), recrutez ce spécialiste.
• S’il vous faut vingt fonctionnalités en parallèle, il vous faut une équipe, pas un freelance.

Quoi vérifier avant d’en embaucher un

Les titres sont gratuits, vérifiez donc la substance. Les signaux qui comptent :

1. Des études de cas plutôt qu’un portfolio. Les captures d’écran montrent la production ; les études de cas montrent le jugement. Cherchez des descriptions honnêtes du contexte, des compromis et du rôle, y compris ce que la personne n’a pas fait.
2. Des questions sur votre problème, pas sur votre stack. Dès la première conversation, un product engineer devrait demander ce que vous cherchez à obtenir avant de proposer une technologie.
3. Des histoires de production. Livrer des fonctionnalités dans un vrai produit vivant, avec des utilisateurs, du legacy et des conséquences, n’a rien à voir avec des démos greenfield. Posez la question. (Pour un aperçu concret, voici mon travail sur Campus Coach.)
4. Savoir dire non. Quelqu’un qui n’a jamais dit à un client « nous ne devrions pas construire ça » est un clavier, pas un partenaire.

Où je me situe

Je travaille comme product engineer freelance avec des fondateurs et des équipes produit, principalement en React, Next.js et TypeScript. Vous pouvez lire comment je travaille ou ce que je peux faire. Si vous pesez ce type de recrutement, parlez-moi de votre produit ; je vous donnerai une réponse directe, y compris « vous n’avez pas besoin de moi pour ça » quand c’est la vérité.