Comparer les achats d'un hôtel aux tarifs négociés par Accor.
À partir d'une facture, l'outil propose des produits du catalogue Accor et calcule les économies possibles. J'ai repensé le parcours avec les acheteurs et les commerciaux pour permettre de vérifier les produits proposés, de corriger la comparaison et de choisir quand la valider. J'ai ensuite livré un prototype React repris par le développeur.
La situation de départ
Accor négocie des prix auprès de fournisseurs. Pour convaincre un hôtel à partir de sa facture, les commerciaux doivent pouvoir lui montrer des économies crédibles. L’outil existant est difficile à parcourir ; une commerciale l’utilise uniquement pour transformer la facture en tableur, puis compare les produits à la main.
Le product manager a déjà construit un prototype plus lisible. Le brief attend des maquettes et un design system. En quatre semaines sur site, j’ai rencontré deux acheteurs et une commerciale, conçu et codé un prototype React sur la stack cible, puis transmis le dépôt au développeur. Les entretiens ont fait de la vérification des produits proposés le cœur du parcours.
Corriger la facture avant de comparer
Les données extraites de la facture servent ensuite à comparer les produits et les prix. J’ai placé la facture originale à gauche et sa lecture à droite, avec les valeurs corrigeables dans la ligne. La comparaison ne démarre qu’après cette vérification.
L’utilisateur garde la source sous les yeux pendant qu’il corrige. Cette disposition remplace une vérification dans un autre onglet ou dans une fenêtre superposée à l’outil.
Comparer les produits dans les mêmes colonnes
Le prototype du product manager présentait les produits sous forme de cartes. J’ai choisi un tableau compact : les informations facturées sont au-dessus de celles du produit proposé, dans les mêmes colonnes. Les prix et les quantités se comparent sans passer d’une carte à l’autre.
Les deux acheteurs interrogés préféraient une vue dense pour parcourir davantage de lignes à la fois, comme dans leur tableur. Cette préférence a guidé l’organisation du tableau.
Corriger une proposition sans fausser le bilan
Un produit proposé peut ne pas convenir. L’acheteur peut choisir une autre alternative ou conserver la ligne sans lui attribuer d’économie. Lorsque le catalogue est plus cher, l’écart reste visible. Le bilan conserve ainsi les produits sans équivalent et les prix moins avantageux.
Les entretiens ont déplacé le problème : une comparaison lisible peut rester trompeuse si les produits ne sont pas équivalents. Un acheteur préférait que l’outil reconnaisse l’absence d’alternative plutôt que de forcer une mauvaise correspondance.
Repérer les lignes moins avantageuses
Changer de critère de comparaison
Produit identique, référencé ou moins cher : les profils reclassent des alternatives déjà trouvées et les totaux suivent. Le product manager a précisé que ce changement devait être pré-calculé. J’ai supprimé l’idée de relancer la recherche à chaque changement de critère.
Quand l’acheteur trouve lui-même une alternative
Au test du 16 juin, l’acheteur a expliqué qu’il doit parfois demander lui-même un prix au fournisseur. Le prototype permet d’ajouter cette proposition dans les alternatives d’une ligne existante, puis de la choisir pour la comparaison. On complète une ligne de facture ; on ne crée pas un achat qui n’y figure pas.
Limite du prototype : l’alternative ajoutée peut être perdue lorsque les lignes sont réinitialisées, notamment au changement de profil. Ce comportement doit être traité à l’intégration.
Exporter en cours de travail, valider à la fin
Exporter et terminer sont deux actions distinctes. J’ai laissé l’utilisateur choisir au moment de l’export : conserver un benchmark modifiable ou le valider. Une fois validé, le résultat passe en lecture seule et les outils qui permettraient de modifier la comparaison disparaissent.
Au test, l’acheteur a refusé la validation automatique à l’export : il retravaille souvent une comparaison après l’avoir exportée. La validation doit correspondre au moment où il considère son travail terminé.
Exporter et continuer
« Still working on it » exporte une copie. Le benchmark reste modifiable.
Exporter et valider
« I’m done » valide le résultat. Le benchmark passe en lecture seule.
Les trois états de l’application
À benchmarker
- Facture importée
- Lignes vérifiées
- Fournisseur cible choisi
Benchmarké
- Produits comparés
- Alternatives et édition
- Drapeaux et notes
Validé
- Lecture seule
- Export direct
- Drapeaux éditables
Signaler un écart à renégocier
Une ligne peut être marquée « à renégocier » avec un commentaire destiné au category manager ou au client. Le marquage reste éditable dans un benchmark validé : il sert à communiquer, sans modifier les chiffres. La persistance des annotations reste une limite du livrable.
Livraison et résultats observés
Le responsable des ventes a validé la direction en début de mission. Le développeur web a repris le dépôt remis la veille de mon départ, avec le backend et la donnée réelle à intégrer. Avant la fin de cette mission, le même client avait commandé un second prototype : Drink Menu Compliance.
Un test utilisateur enregistré a été réalisé avec un acheteur, et ses retours intégrés le lendemain. Sa réaction porte sur un prototype avec données fictives, pas sur l’usage du produit en production : « Si c’est aussi simple que ça à chaque fois, c’est canon. »
La structure transmise au développeur
React 19, TypeScript et Vite, sur les tokens du design system client. Onze fichiers de tests couvrent la logique de calcul. Cinq notes de décision, les états d’erreur et les points ouverts accompagnent le dépôt. Un seul module d’accès aux données indique au développeur où brancher le moteur réel.
- Écransdes composants qui ne touchent jamais aux données
- Hooksl'état de l'application, lectures et écritures
- api.tsle seul module qui parle au backend, une fonction par appel, latence simulée
- Backendle moteur de comparaison du client, à brancher
Les limites
Données fictives, comparaison simulée, aucun backend ni authentification réelle. Le score de confiance par ligne n’est pas construit. Les annotations et les alternatives ajoutées ont des limites de persistance. Un seul test utilisateur est documenté, sans commercial terrain.
Ce que je referais autrement
Je mettrais un commercial terrain devant l’écran dès la deuxième semaine. Le test documenté a été fait avec un acheteur, plus tard dans la mission.