Article de démonstration. Ce texte est généré et sert à tester le workflow de contenu. À relire, adapter ou supprimer avant la mise en ligne.
Sur une carte de visite, « product engineer » ressemble à un développeur full-stack avec un meilleur marketing. Dans la pratique, la différence est plus grande — et plus inconfortable. Il ne s’agit pas de savoir plus de choses. Il s’agit d’assumer la responsabilité du résultat, pas seulement du code.
La différence n’est pas dans la stack
Un développeur reçoit un ticket : « Ajoute un filtre à la liste des projets. » Un product engineer demande : « Quelle décision la personne doit-elle prendre après avoir filtré ? » Peut-être qu’elle n’a pas besoin d’un filtre, mais d’un meilleur tri. Peut-être que la liste est trop longue parce que les contenus ne sont pas assez sélectionnés. Peut-être que le vrai problème est que personne ne sait quels projets sont pertinents.
Ce n’est pas de l’arrogance envers le ticket. C’est la question de savoir si le ticket décrit le bon problème. Parfois la réponse est oui. Alors on construit le filtre — rapidement et bien. Parfois la réponse est non. Alors le travail le plus important est de le dire.
Trois questions qui changent tout
Avant de prendre une décision technique, je pose trois questions :
- Pourquoi maintenant ? Que se passe-t-il si on ne le fait pas ? Quelle décision ou quel processus en dépend ?
- Pour qui ? Qui utilise le résultat, dans quelle situation, avec quelles connaissances préalables ?
- Quel est le plus petit pas utile ? Quelle version résout le problème sans construire les trois problèmes suivants ?
Ces questions ralentissent le démarrage de dix minutes et font souvent gagner des semaines. Elles sont aussi la raison pour laquelle le product engineering ne fonctionne pas sans communication. Celui qui ne voit que le code ne peut pas répondre à ces questions.
Un exemple : la fonctionnalité que nous n’avons pas construite
Un client voulait un « rappel automatique » pour les tâches ouvertes. Le besoin était clair, le ticket était petit. Lors de la discussion, nous avons découvert que les rappels ne manquaient pas : les tâches n’étaient tout simplement pas clairement attribuées. Chaque matin, l’équipe cherchait à la main qui devait prendre quoi.
Nous n’avons pas construit de logique de notification. Nous avons ajouté à la liste des tâches une responsabilité claire et une vue quotidienne synthétique. Le nombre de tâches ouvertes a diminué parce que le passage de relais est devenu visible. La fonctionnalité initialement demandée aurait été techniquement simple — et aurait seulement rendu le vrai problème plus bruyant.
Ce n’est pas une histoire héroïque. C’est le travail normal quand on prend le contexte au sérieux.
Rendre les décisions visibles
Le product engineering consiste aussi à rendre les décisions compréhensibles. Un court journal de décisions suffit :
## Décision : liste des tâches plutôt que rappels
- Contexte : tâches ouvertes sans responsabilité claire
- Options : rappels automatiques, vue quotidienne, les deux
- Décision : vue synthétique avec responsabilité
- Raison : le problème était la visibilité, pas l'attention
- Vérification : dans deux semainesCe journal n’est pas de la bureaucratie. Il évite la résurrection silencieuse d’idées abandonnées et aide les nouveaux membres de l’équipe à comprendre les raisons. Les bonnes décisions sont rarement évidentes.
Ce que le product engineering n’est pas
Ce n’est pas « designer et développeur en une seule personne ». Les bons produits naissent rarement seuls. Ce n’est pas non plus « product manager avec des compétences en programmation ». Le rôle ne remplace ni la stratégie produit ni la décision de design.
Ce qui le caractérise, c’est la connexion : une profondeur technique, une compréhension du contexte d’usage et la volonté de traduire les deux en décisions. Parfois cela signifie construire un prototype pour tester une hypothèse. Parfois cela signifie ne pas construire une fonctionnalité. Et parfois cela signifie écrire le code qui fait exactement ce qui a été convenu — sans drame.
Conclusion
Le product engineering n’est pas un intitulé qu’on se donne. C’est la décision de ne pas seulement livrer du code, mais d’assumer la responsabilité du résultat. La stack est le plus petit des problèmes.