On recrute un développeur sur sa technique. On le garde sur sa capacité à livrer vite, propre, sans bug. Après quinze ans à construire des produits et à diriger des équipes techniques en startup, j'ai vu la même chose mission après mission : le développeur qui crée le plus de valeur est rarement celui qui code le mieux. C'est celui qui comprend pourquoi il code. Cette différence, vous la payez tous les mois sans la voir passer.
J'ai vu ce contraste sur la plupart de mes missions. Deux développeurs du même niveau technique, interchangeables sur le papier, produisent des résultats qui n'ont rien à voir. L'un fait avancer le produit. L'autre fait avancer le backlog. La différence coûte cher.
Ce qui sépare un développeur coûteux d'un développeur rentable
Cette compétence s'appelle le product sense. Elle consiste à comprendre le problème derrière une demande au lieu d'exécuter seulement ce qui a été formulé.
J'ai vu le même cas plusieurs fois. Une équipe lance un chantier ambitieux : un système complet de filtres, de tags et de catégories pour aider les utilisateurs à retrouver leurs informations. Plusieurs semaines de travail sont prévues. Le développeur sans product sense ouvre son éditeur et commence à construire. L'autre va d'abord parler à quelques utilisateurs. Ce qu'il apprend change souvent la décision : le problème vient d'une recherche lente et imprécise, pas d'un manque de filtres. Une refonte ciblée de la recherche remplace alors plusieurs semaines de chantier et règle la majorité des frustrations.
Les deux développeurs auraient passé le même temps à travailler. Un seul aurait résolu le problème. L'autre aurait livré un système à maintenir pendant des années pour un bénéfice marginal. C'est la différence entre construire correctement une fonctionnalité et construire la bonne.
Les équipes tech appellent ce profil le Product Engineer. Ce développeur comprend les utilisateurs, le produit et le business autant que la technique. Le marché recherche ce profil parce que la compétence reste rare. Elle sépare un coût d'un investissement.
Pourquoi cette différence pèse sur votre burn rate
Tant que votre produit est petit, l'écart reste invisible. Peu de fonctionnalités, peu d'utilisateurs, peu de dette. Une fonctionnalité de trop ne se remarque pas. Le problème, c'est que cet écart grossit avec votre produit, et qu'il grossit plus vite que votre chiffre d'affaires.
Chaque fonctionnalité que vous expédiez a un coût qui ne s'arrête pas le jour de la livraison. Elle se maintient, elle génère du support, elle ajoute de la complexité à toutes les fonctionnalités qui viendront après elle, et elle alourdit la base de code que chaque nouveau développeur devra comprendre. Construire la mauvaise fonctionnalité ne coûte pas une semaine de développement. Ça coûte une semaine de développement, plus des mois de maintenance, plus l'opportunité que vous n'avez pas saisie pendant ce temps. Dans une startup qui brûle du cash, c'est souvent l'erreur la plus chère que personne ne facture.
Comme je l'explique ailleurs, une fonctionnalité ne se résume pas à son code. Le cadrage, les tests, le déploiement et la maintenance comptent aussi. Avant tout cela, il faut comprendre ce qu'il faut construire et ce qu'il vaut mieux laisser de côté.
Le développeur qui reformule la demande ne gagne pas du temps en codant plus vite. Il remplace un mauvais chantier par une réponse plus juste. Un développeur rentable réduit la quantité de code que votre entreprise doit porter au lieu de l'augmenter proprement.
Comment repérer ce profil dans votre équipe et à l'embauche
Vous n'avez pas besoin d'être technique pour le repérer. Votre regard sur le résultat business peut même être plus utile que celui d'un recruteur concentré sur l'élégance du code.
Le signal tient en une réaction. Face à une demande, le développeur sans product sense cherche d'abord comment construire la fonctionnalité. Celui qui en a cherche d'abord pourquoi elle doit exister. En entretien, décrivez-lui une demande volontairement floue, comme un vrai fondateur la formulerait, et observez par quoi il commence. Vous n'avez pas besoin de comprendre son code pour entendre la différence.
Dans votre équipe actuelle, le signal est tout aussi lisible. Repérez qui revient vers vous pour comprendre l'intention avant de coder, et qui vous propose parfois de ne pas construire ce que vous avez demandé. Ce développeur-là n'est pas difficile, il vous protège. Méfiez-vous de l'inverse : celui qui dit toujours oui, qui livre tout sans jamais challenger, est souvent celui qui vous coûte le plus cher, parce qu'il transforme chaque mauvaise idée en dette.
Reste un point que vous contrôlez directement : les conditions. Le product sense ne s'exprime que si vous laissez vos développeurs parler aux utilisateurs et accéder à l'intention derrière les décisions. Un développeur enfermé dans un tunnel de tickets n'a aucune chance de le développer, même s'il en a le potentiel. Si vous coupez vos équipes du contexte business, vous fabriquez vous-même des exécutants.
La décision que ça implique pour vous
La bascule se joue dans votre façon de mesurer la valeur d'un développeur. Si vous évaluez l'équipe au volume de code livré, aux tickets fermés ou à la vélocité, vous récompensez le mauvais comportement : produire plus sans vérifier l'utilité. C'est pour cela que mesurer la productivité de vos développeurs au volume mène presque toujours au mauvais endroit.
Mesurez un développeur aux problèmes qu'il résout plutôt qu'aux fonctionnalités qu'il livre. Vous valoriserez ceux qui gagnent du temps en construisant moins. Vous paierez davantage les profils rares qui le méritent et cesserez de surpayer la vitesse d'exécution, désormais facile à remplacer. Cette décision appartient au dirigeant. Elle améliore à la fois le produit et la trésorerie.
Ce qu'il faut retenir
- Votre développeur le plus précieux n'est pas celui qui écrit le meilleur code, c'est celui qui comprend le problème derrière chaque demande.
- Cette compétence est invisible quand votre produit est petit et décisive quand il grandit, parce que chaque mauvaise fonctionnalité se paie en maintenance et en dette pendant des années.
- Le levier est entre vos mains : arrêtez de mesurer vos développeurs au volume livré, mesurez-les aux problèmes résolus.
Questions fréquentes
Comment savoir si un développeur a du product sense sans être technique soi-même ?
Donnez-lui une demande volontairement floue et regardez par quoi il commence. S'il enchaîne directement sur la construction, il exécute. S'il s'arrête sur l'usage et l'utilisateur visé, il réfléchit produit. Vous n'avez pas besoin de comprendre son code pour entendre la différence.
Faut-il recruter un développeur senior ou un Product Engineer ?
Ce ne sont pas les mêmes axes. La séniorité mesure la maîtrise technique, le product sense mesure le jugement. Un senior sans product sense construira très bien la mauvaise chose. Pour une startup early-stage, où chaque semaine compte, le jugement produit prime souvent sur la pure expertise technique.
Le product sense peut-il s'apprendre ?
Il se développe, mais seulement dans les bonnes conditions. Un développeur qui parle aux utilisateurs, lit les retours clients et comprend les décisions business le muscle avec le temps. Enfermé dans un tunnel de tickets, il ne le développera jamais, quel que soit son potentiel.
Conclusion
La valeur d'écrire du code est déjà en train de s'effondrer. L'IA en produit de plus en plus, de mieux en mieux, et cette tendance ne fera que s'accélérer. Ce qui prend de la valeur, à l'inverse, c'est de savoir quel problème mérite d'être résolu. Cette compétence-là ne s'automatise pas.
Pour vous, dirigeant, la conséquence est concrète : l'avantage ne se jouera plus sur la quantité de code que votre équipe produit, mais sur sa capacité à construire les bonnes choses. Le développeur qui comprend cette différence est déjà le profil le plus rentable de votre équipe. Savoir le repérer, c'est votre prochaine décision.
Vous structurez votre équipe technique en ce moment et vous voulez savoir qui, chez vous, crée vraiment de la valeur ? Parlons-en directement, un échange de 30 minutes suffit souvent à y voir clair.