Product Manager, CTO, ou fondateur qui build avec l’IA, c’est Lundi et ce post est pour vous.
La méthode Job To Be Done n’a jamais été aussi pertinente qu’aujourd’hui. Et pourtant, elle est souvent traitée comme un exercice théorique qu’on coche une fois en début de projet, avant de revenir aux bons vieux réflexes.
Avec l’IA, on peut désormais construire une fonctionnalité générique très vite. Trop vite. On livre quelque chose qui « marche », on coche les cases, et on passe au sprint suivant.
Le problème n’est pas la vitesse. C’est ce qu’on a oublié de questionner avant de construire.
Ce que la user story classique ne dit pas
Prenons cet exemple :
« En tant qu’utilisateur, je veux pouvoir discuter avec mon document de façon sécurisée et confidentielle. »
Un développeur sait quoi construire. Mais cette formulation a trois angles morts :
Elle ignore la situation. Dans quel contexte précis l’utilisateur en a-t-il besoin ? Sous quelle contrainte de temps ? Seul ou en présence d’un client ?
Elle ignore les anxiétés. Qu’est-ce qui pourrait l’empêcher d’utiliser la fonctionnalité, même si elle est bien conçue ? Une crainte que ses données soient réutilisées ? Une incertitude sur la conformité réglementaire ?
Elle couple l’implémentation aux motivations. Et c’est le piège le plus subtil. Si la fonctionnalité échoue, impossible de savoir si c’est le code qui est en cause, ou l’hypothèse de départ sur le besoin réel. On a lié les deux sans le remarquer.
Ce que la Job Story révèle à la place
La Job Story ne remplace pas la user story. Elle va chercher plus haut en amont. Elle s’intéresse à la causalité. Qu’est-ce qui pousse vraiment l’utilisateur à agir, dans quelle situation, avec quelles tensions ?
La structure change :
Quand [situation précise]… je veux [motivation réelle]… afin de [résultat attendu].
Ce n’est pas une reformulation. C’est une hypothèse de comportement, qui suppose d’avoir d’abord observé comment les gens résolvent le problème aujourd’hui, avec quels outils de fortune, et avec quelles frustrations.
Le cas Hilti
Hilti, fabricant d’outils professionnels pour le BTP, est l’un des exemples les plus documentés de cette bascule.
User story classique :
« En tant qu’ouvrier, je veux acheter une perceuse performante et fiable pour percer des trous sur mon chantier. »
Cette formulation a guidé l’industrie pendant des décennies : puissance du moteur, autonomie de la batterie, ergonomie de la poignée. Des améliorations réelles, mais toutes centrées sur l’objet.
En remontant à la situation réelle, un chantier sous délai, un outil tombé en panne, une intervention impossible à l’arrêter, Hilti a reformulé le job différemment :
Job Story :
« Quand je suis sur un chantier et que j’ai besoin de percer un trou conforme aux spécifications, je veux avoir l’assurance qu’un outil fonctionnel est disponible à tout moment, sans avoir à gérer moi-même l’entretien ou le remplacement, afin de ne jamais bloquer l’avancement du chantier. »
L’anxiété centrale n’était pas « et si la perceuse est mauvaise ? » mais « et si elle tombe en panne et que je ne peux pas continuer ? »
Ce glissement a changé la nature du produit. Hilti n’a pas construit une meilleure perceuse. Il a construit un service de gestion de flotte d’outils, avec maintenance et remplacement inclus. C’est son offre Fleet Management, toujours en activité aujourd’hui.
Le lien avec l’IA
L’IA ne change pas la méthode. Elle en révèle l’urgence.
Avant, construire une mauvaise fonctionnalité coûtait des mois de développement. Aujourd’hui, elle peut sortir en quelques jours. Les erreurs d’hypothèse se propagent plus vite, à plus grande échelle, et sont plus difficiles à tracer, précisément parce qu’on a couplé l’implémentation aux motivations sans s’en rendre compte.
Une user story classique répond à « quoi construire ». Une Job Story répond à « pourquoi l’utilisateur en a besoin, dans quel contexte, et quelles anxiétés l’empêchent d’y aller ».
Avec l’IA, écrire du code devient plus rapide. Comprendre le job à accomplir devient plus indispensable que jamais.
Sources
- Intercom — Using Job Stories to design features
- Usabilis — Job To Be Done
- La Grande Ourse — La méthode Job To Be Done
Leave a Reply