{"id":160,"date":"2026-06-15T09:00:00","date_gmt":"2026-06-15T09:00:00","guid":{"rendered":"https:\/\/antoineriquiez.fr\/?p=160"},"modified":"2026-09-17T09:22:15","modified_gmt":"2026-09-17T09:22:15","slug":"job-story-vs-user-story-ia","status":"publish","type":"post","link":"https:\/\/antoineriquiez.fr\/en\/job-story-vs-user-story-ia\/","title":{"rendered":"User story vs Job Story : la diff\u00e9rence qui change beaucoup, surtout avec l’IA"},"content":{"rendered":"\n

Product Manager, CTO, ou fondateur qui build avec l’IA, c’est Lundi et ce post est pour vous.<\/p>\n\n\n\n

La m\u00e9thode Job To Be Done n’a jamais \u00e9t\u00e9 aussi pertinente qu’aujourd’hui. Et pourtant, elle est souvent trait\u00e9e comme un exercice th\u00e9orique qu’on coche une fois en d\u00e9but de projet, avant de revenir aux bons vieux r\u00e9flexes.<\/p>\n\n\n\n

Avec l’IA, on peut d\u00e9sormais construire une fonctionnalit\u00e9 g\u00e9n\u00e9rique tr\u00e8s vite. Trop vite. On livre quelque chose qui \u00ab\u00a0marche\u00a0\u00bb, on coche les cases, et on passe au sprint suivant.<\/p>\n\n\n\n

Le probl\u00e8me n’est pas la vitesse. C’est ce qu’on a oubli\u00e9 de questionner avant de construire.<\/p>\n\n\n\n

Ce que la user story classique ne dit pas<\/h2>\n\n\n\n

Prenons cet exemple :<\/p>\n\n\n\n

\n

\u00ab\u00a0En tant qu’utilisateur, je veux pouvoir discuter avec mon document de fa\u00e7on s\u00e9curis\u00e9e et confidentielle.\u00a0\u00bb<\/em><\/p>\n<\/blockquote>\n\n\n\n

Un d\u00e9veloppeur sait quoi construire. Mais cette formulation a trois angles morts :<\/p>\n\n\n\n

Elle ignore la situation.<\/strong> Dans quel contexte pr\u00e9cis l’utilisateur en a-t-il besoin ? Sous quelle contrainte de temps ? Seul ou en pr\u00e9sence d’un client ?<\/p>\n\n\n\n

Elle ignore les anxi\u00e9t\u00e9s.<\/strong> Qu’est-ce qui pourrait l’emp\u00eacher d’utiliser la fonctionnalit\u00e9, m\u00eame si elle est bien con\u00e7ue ? Une crainte que ses donn\u00e9es soient r\u00e9utilis\u00e9es ? Une incertitude sur la conformit\u00e9 r\u00e9glementaire ?<\/p>\n\n\n\n

Elle couple l’impl\u00e9mentation aux motivations.<\/strong> Et c’est le pi\u00e8ge le plus subtil. Si la fonctionnalit\u00e9 \u00e9choue, impossible de savoir si c’est le code qui est en cause, ou l’hypoth\u00e8se de d\u00e9part sur le besoin r\u00e9el. On a li\u00e9 les deux sans le remarquer.<\/p>\n\n\n\n

Ce que la Job Story r\u00e9v\u00e8le \u00e0 la place<\/h2>\n\n\n\n

La Job Story ne remplace pas la user story. Elle va chercher plus haut en amont. Elle s’int\u00e9resse \u00e0 la causalit\u00e9. Qu’est-ce qui pousse vraiment l’utilisateur \u00e0 agir, dans quelle situation, avec quelles tensions ?<\/p>\n\n\n\n

La structure change :<\/p>\n\n\n\n

Quand [situation pr\u00e9cise]\u2026 je veux [motivation r\u00e9elle]\u2026 afin de [r\u00e9sultat attendu].<\/em><\/p>\n\n\n\n

Ce n’est pas une reformulation. C’est une hypoth\u00e8se de comportement, qui suppose d’avoir d’abord observ\u00e9 comment les gens r\u00e9solvent le probl\u00e8me aujourd’hui, avec quels outils de fortune, et avec quelles frustrations.<\/p>\n\n\n\n

\n\n\n\n

Le cas Hilti<\/h2>\n\n\n\n

Hilti, fabricant d’outils professionnels pour le BTP, est l’un des exemples les plus document\u00e9s de cette bascule.<\/p>\n\n\n\n

User story classique :<\/strong><\/p>\n\n\n\n

\n

\u00ab\u00a0En tant qu’ouvrier, je veux acheter une perceuse performante et fiable pour percer des trous sur mon chantier.\u00a0\u00bb<\/em><\/p>\n<\/blockquote>\n\n\n\n

Cette formulation a guid\u00e9 l’industrie pendant des d\u00e9cennies : puissance du moteur, autonomie de la batterie, ergonomie de la poign\u00e9e. Des am\u00e9liorations r\u00e9elles, mais toutes centr\u00e9es sur l’objet.<\/p>\n\n\n\n

En remontant \u00e0 la situation r\u00e9elle, un chantier sous d\u00e9lai, un outil tomb\u00e9 en panne, une intervention impossible \u00e0 l’arr\u00eater, Hilti a reformul\u00e9 le job diff\u00e9remment :<\/p>\n\n\n\n

Job Story :<\/strong><\/p>\n\n\n\n

\n

\u00ab\u00a0Quand je suis sur un chantier et que j’ai besoin de percer un trou conforme aux sp\u00e9cifications, je veux avoir l’assurance qu’un outil fonctionnel est disponible \u00e0 tout moment, sans avoir \u00e0 g\u00e9rer moi-m\u00eame l’entretien ou le remplacement, afin de ne jamais bloquer l’avancement du chantier.\u00a0\u00bb<\/em><\/p>\n<\/blockquote>\n\n\n\n

L’anxi\u00e9t\u00e9 centrale n’\u00e9tait pas \u00ab\u00a0et si la perceuse est mauvaise ?\u00a0\u00bb mais \u00ab\u00a0et si elle tombe en panne et que je ne peux pas continuer ?\u00a0\u00bb<\/p>\n\n\n\n

Ce glissement a chang\u00e9 la nature du produit. Hilti n’a pas construit une meilleure perceuse. Il a construit un service de gestion de flotte d’outils<\/strong>, avec maintenance et remplacement inclus. C’est son offre Fleet Management, toujours en activit\u00e9 aujourd’hui.<\/p>\n\n\n\n

Le lien avec l’IA<\/h2>\n\n\n\n

L’IA ne change pas la m\u00e9thode. Elle en r\u00e9v\u00e8le l’urgence.<\/p>\n\n\n\n

Avant, construire une mauvaise fonctionnalit\u00e9 co\u00fbtait des mois de d\u00e9veloppement. Aujourd’hui, elle peut sortir en quelques jours. Les erreurs d’hypoth\u00e8se se propagent plus vite, \u00e0 plus grande \u00e9chelle, et sont plus difficiles \u00e0 tracer, pr\u00e9cis\u00e9ment parce qu’on a coupl\u00e9 l’impl\u00e9mentation aux motivations sans s’en rendre compte.<\/p>\n\n\n\n

Une user story classique r\u00e9pond \u00e0 \u00ab\u00a0quoi construire\u00a0\u00bb. Une Job Story r\u00e9pond \u00e0 \u00ab\u00a0pourquoi l’utilisateur en a besoin, dans quel contexte, et quelles anxi\u00e9t\u00e9s l’emp\u00eachent d’y aller\u00a0\u00bb.<\/p>\n\n\n\n

Avec l’IA, \u00e9crire du code devient plus rapide. Comprendre le job \u00e0 accomplir devient plus indispensable que jamais.<\/p>\n\n\n\n

Sources<\/h3>\n\n\n\n