Le chaînon manquant
Concevoir avant de coder
Le Product Engineer transforme une intention produit en expérience claire.
Le propos
Entre la posture et le pixel
Deux décisions tiennent le métier de Product Engineer. La première est une posture — passer d'exécutant de tickets à quelqu'un qui comprend le problème, arbitre, mesure et porte le résultat. La seconde est un savoir-faire d'exécution — hiérarchie, espace, typographie, couleur, détails, mouvement. Entre les deux, il manque le chaînon : comment on passe d'une intention produit à une décision d'interface.
Avant d'écrire du code, il faut savoir ce que l'on cherche à rendre possible. Le Product Engineer ne part pas d'un ticket, d'un composant ou d'une maquette. Il part d'une situation réelle : une personne, un contexte, une difficulté, une décision à prendre. Marty Cagan le formule à l'échelle de l'équipe : on ne confie pas des fonctionnalités à livrer, on confie des problèmes à résoudre.
Son travail consiste à traduire cette situation en décisions concrètes : par où la personne passe, ce qu'elle voit en premier, ce qui se passe quand rien ne va comme prévu, et à quoi on saura que ça marche. L'IA peut accélérer la réalisation. Elle ne choisit pas ce qui mérite d'être construit. Le jugement reste humain. Une bonne solution n'ajoute pas le plus de fonctionnalités : c'est celle qui rend l'action évidente.
Le code peut être généré.
La clarté, elle, se conçoit.
Le parcours
Du problème réel à l'effet mesuré
Concevoir, ce n'est pas dessiner ; c'est décider. Sept gestes mènent d'une situation à une interface qui aide vraiment — et chacun écarte une paresse.
Partie 01
Partir du moment utilisateur
La première erreur n'est pas de mal dessiner : c'est de partir du mauvais endroit. « Faire un tableau de bord » n'est pas un problème, c'est déjà une solution — et souvent un calque de la base de données. Le bon point de départ est un moment : l'instant précis où une personne est bloquée et doit décider quoi faire. Chez Edumapper, ce moment a un nom — l'élève qui ouvre l'app et se demande : « Que dois-je faire maintenant ? »
Teresa Torres pose le garde-fou : ne pas confondre une opportunité (le besoin) avec une solution (une seule façon d'y répondre). On part du résultat à atteindre, puis des opportunités qui y mènent — pas de la première fonctionnalité qui vient à l'esprit.
À éviter
- Ouvrir sur un écran qui liste tout, au cas où.
- Partir d'une fonctionnalité avant d'avoir compris la décision à prendre.
- Calquer l'écran sur la structure de la base de données.
À faire
- Ouvrir sur la seule question que se pose la personne à cet instant.
- Identifier la décision que l'utilisateur doit prendre maintenant.
- Nommer la prochaine action, pas la donnée à afficher.
Partie 02
Formuler l'intention
Une fois le moment tenu, on l'interroge avec quatre questions, dans cet ordre : qui utilise ? Dans quel contexte ? Quelle action doit devenir plus simple ? Quel résultat réel attend-on ? L'intention n'est pas un titre de fonctionnalité — c'est une phrase qui tient sans mentionner d'écran : « un élève hésitant, sur mobile, le soir, doit voir d'un coup d'œil la seule chose qui compte ce soir, et la faire en moins d'une minute. »
Guillermo Rauch le rappelle à l'ère de l'IA : savoir quoi construire a toujours compté plus que le code. Ce qu'on obtient d'un outil — ou d'un modèle — dépend de la qualité de la demande. Formuler, c'est déjà la moitié du travail.
Partie 03
Cadrer le périmètre
Cadrer, ce n'est pas rédiger une spec longue : c'est fixer les bonnes décisions et les renoncements. Ryan Singer distingue l'appétit de l'estimation — combien ce problème vaut qu'on y consacre, décidé avant de dessiner. Le budget devient une contrainte créative : il force à choisir.
À éviter
- Tout traiter dès la v1, « tant qu'on y est ».
- Une spec exhaustive qui fige avant d'avoir compris.
- Laisser le périmètre s'étendre au gré des envies.
À faire
- Écrire ce qu'on construit — et ce qu'on ne construit pas.
- Distinguer ce qui doit être évident de ce qui peut attendre.
- Poser un appétit, et arbitrer dedans.
Partie 04
Dessiner le parcours
Un parcours ne se résume pas à l'écran « heureux ». Il faut dessiner tous les moments réels : le premier usage, l'état vide, le chargement, l'erreur, le succès, le retour arrière, le mobile, l'accessibilité. Brian Lovin reconnaît un bon profil à cela : il pense d'emblée aux états, à l'ordre des éléments, au clavier — pas seulement au cas idéal.
Le soin porté à ces états oubliés n'est pas cosmétique. Rauno Freiberg le défend dans le détail : une interface se juge à ce qu'elle fait quand rien ne se passe comme prévu — et le soin, là, rend l'action évidente.
À éviter
- Ne dessiner que l'écran plein, quand tout va bien.
- Un état vide blanc qui n'explique rien.
- Renvoyer « une erreur est survenue » sans quoi faire ensuite.
À faire
- Traiter l'état vide comme un onboarding : il enseigne quoi faire.
- Montrer, chaque erreur mène à une action
- Confirmer le succès par la prochaine étape, pas par une alerte.
Partie 05
Hiérarchiser l'interface
Une fois le parcours posé, l'écran doit guider le regard : une action principale, une information dominante, et le reste atténué. Moins d'options, moins de bruit. Shreyas Doshi le dit en termes d'effort : on met son perfectionnisme là où le rendement est dix fois supérieur — le cœur du parcours — et l'on sous-investit le reste. Il faut penser simplicité et clarté, et privilégier un parcours où on a pas de clics inutiles. Apple en fait un principe : l'interface aide à comprendre le contenu ; elle ne lui fait jamais concurrence.
À éviter
- Trois boutons de même poids : rien ne dit lequel compte.
- Tout mettre en avant, donc ne rien mettre en avant.
À faire
- Une action principale claire ; le reste devient secondaire.
- Une seule information domine l'écran à la fois.
Partie 06
Utiliser l'IA
sans lui déléguer le jugement
L'IA produit vite : elle écrit le squelette, les motifs évidents, une interface convaincante au premier regard. Addy Osmani parle des « 70 % » : le modèle fait la part facile ; les 30 % qui restent — cas limites, sécurité, cohérence, jugement — et la responsabilité restent humains. Le Product Engineer garde la main : il choisit, coupe, teste, affine.
Le danger a changé de nature. Il n'est plus de coder lentement ; c'est de construire vite la mauvaise chose. Quand tout le monde peut générer une interface, la différence se fait au goût produit et à la discipline d'ingénierie — pas à la vitesse de frappe.
Partie 07
Mesurer l'effet réel
Livrer une fonctionnalité n'est pas produire un effet. La bonne question n'est pas « est-ce en ligne ? » mais « est-ce que ça change quelque chose pour la personne ? ». L'utilisateur comprend-il plus vite ? Fait-il moins d'erreurs ? Termine-t-il son action ? Revient-il ? Pose-t-il moins de questions ? John Cutler résume le remède à l'usine à features : tout tient à la cohérence — savoir tracer et porter l'intention, du travail jusqu'au résultat.
Karri Saarinen le tire jusqu'à l'organisation : pas de « passation au dev ». Dans une équipe connectée, chacun est responsable de la qualité, et la spec est un point de départ, pas la ligne d'arrivée. C'est exactement le terrain du Product Engineer — là où produit, design et ingénierie ne se passent plus le relais, mais courent ensemble.
Pour finir
Construire juste,
pas seulement vite.
- Pars du moment où la personne est bloquée, pas de l'écran à remplir.
- Formule l'intention avant la solution : qui, contexte, décision, résultat.
- Décide ce qu'on retire. La clarté vient autant de ce qu'on cache que de ce qu'on affiche.
- Dessine le parcours entier : vide, erreur, succès, retour, mobile, accessibilité.
- Une action principale, une information dominante. Atténue le reste.
- L'IA accélère la production ; le jugement décide quoi construire.
- Mesure l'effet réel, pas le volume livré.