Repenser un outil de négociation pour deux métiers de l’achat.

Le Should Cost Model est un outil d’aide à la négociation pour les équipes achats d’un groupe de distribution. Il concerne deux métiers : acheter les produits vendus sous la marque de l’enseigne et négocier ceux des marques de fabricants. La recherche devait comprendre les limites de l’application existante et les besoins d’équipes qui ne l’utilisaient pas encore.

J’ai préparé un protocole adapté aux utilisateurs actuels et futurs : des entretiens à distance de 45 à 60 minutes sur le métier, les pratiques et les difficultés. Avec les utilisateurs actuels, j’observais leur utilisation naturelle de l’outil, puis nous faisions un retour critique. Avec les autres, l’entretien comprenait une présentation de l’application pour discuter de son intérêt et de leurs besoins.

J’ai ensuite synthétisé les usages, les difficultés et les besoins par métier. Les entretiens montraient notamment comment les équipes préparaient leurs argumentaires et complétaient leurs analyses sur tableur. La restitution distinguait les problèmes de données, les fonctions manquantes et les améliorations de l’interface : ces constats appelaient des réponses différentes.

Un besoin commun ressortait : voir l’ensemble des achats avant d’approfondir un produit. L’outil existant était centré sur le détail produit. La synthèse faisait aussi apparaître des besoins de comparaison et de suivi des évolutions dans le temps, avec des différences selon le métier.

J’ai regroupé les demandes dans une liste commune, puis préparé des priorités par équipe. La vue d’ensemble et le passage entre les niveaux d’analyse figuraient parmi les premiers sujets à traiter. La grille RICE aidait à discuter cet ordre : personnes concernées, bénéfice attendu, confiance dans l’estimation et effort nécessaire. Il s’agissait d’hypothèses de priorisation.

La Product Review que j’ai préparée rendait le chemin lisible : observations → besoins → propositions → priorités à discuter. Elle fournissait un cadre pour la suite : valider les priorités avec chaque équipe, préparer les maquettes, puis les ajuster avec les utilisateurs en ateliers de co-conception.

Les retours sur les écrans demandaient des repères plus clairs : quels produits, quelle période et quelle comparaison ? Ils soulevaient aussi des questions sur les informations disponibles et leur fiabilité.

J’en retiens deux travaux distincts : rendre l’écran compréhensible et vérifier les données avec les responsables métier. Comprendre ce que l’on regarde avant de s’en servir pour décider devient ainsi un critère pour évaluer les propositions.

J’ai construit un prototype fonctionnel en React et TypeScript, avec l’aide de l’IA. On peut y enchaîner les actions, changer de contexte et retrouver les informations dans le parcours. Les utilisateurs et les développeurs disposent ainsi d’un support concret pour discuter du comportement attendu.

Mon rôle couvre la recherche, la conception de l’expérience et la construction du prototype. Le modèle d’analyse métier existait avant la mission. Le livrable présenté est un prototype de conception ; la mise en production et les gains à l’usage ne sont pas documentés ici.