Vérifier les engagements des hôtels envers les marques de boissons partenaires.
Accor développe un outil pour vérifier automatiquement les cartes de ses bars et restaurants. J'ai conçu les parcours permettant aux hôtels de vérifier l'analyse, de signaler une erreur ou de demander une dérogation, puis à l'équipe Accor d'examiner ces demandes. Le travail a abouti à un prototype React fonctionnel dont le frontend a été repris par le développeur du client.
La situation de départ
Les hôtels doivent proposer certaines boissons de marques partenaires selon des règles définies par Accor. Une opératrice vérifie chaque année les cartes de plus de mille hôtels à partir d’un fichier Excel. L’équipe veut automatiser ce contrôle ; son product manager a déjà construit un prototype. La commande : challenger l’UX et appliquer le design system du groupe. Le cadrage révèle deux usages : une vérification annuelle côté hôtel, une revue quotidienne côté back-office.
J’ai conçu ces parcours avec l’opératrice, les équipes métier et les hôteliers, pendant que le développement démarrait côté client. Entre le 20 et le 30 juillet, sept hôteliers ont commenté le prototype à voix haute, écran par écran, pendant que je pilotais la démonstration. Ces retours sur le prototype ont fait évoluer les attestations avant analyse, les types de points de vente et la visibilité des lignes dépliables.
Corriger l’analyse et expliquer ce qui manque
Sur une règle qui attend deux produits, l’hôtel peut n’en déclarer qu’un : il conteste ce qu’il a et justifie ce qui manque. J’ai séparé ces deux réponses. Le commentaire porte sur le produit déclaré ; la justification porte sur celui qui manque.
Mon premier formulaire utilisait un champ unique qui changeait de nature selon la déclaration. La revue métier l’a remis en cause : son intitulé changeait sous le curseur et ne parlait plus du produit que l’on venait de cocher.
Deux segments, deux façons de vérifier
Dans les hôtels économiques, ne rien faire reste une réponse légitime quand l’analyse est correcte. Dans le luxe, répondre est obligatoire sur chaque règle. Les demandes des hôteliers ont conforté cette distinction : ils voulaient pouvoir confirmer qu’un produit était effectivement absent. J’ai gardé deux libellés stables pour répondre à l’analyse, quel que soit le type de règle.
Avant l’analyse : annoncer l’irréversibilité
L’opératrice a demandé une seule tentative pour éviter qu’un hôtel modifie sa carte après avoir découvert le résultat. Elle a rédigé l’avertissement. Les hôteliers ont ensuite fait remplacer le mot à taper par deux attestations : le contenu a été relu et l’impossibilité de revenir en arrière est comprise.
Trancher chaque demande, avec le bon motif
Accepter une correction et dispenser d’une règle sont deux décisions différentes. J’ai distingué leurs actions et leurs motifs : rejeter une contestation exige une explication, accorder une dispense laisse le motif facultatif. La clôture du dossier reste impossible tant qu’une demande attend une décision.
Le valideur doit pouvoir expliquer son refus au référent de l’hôtel. Rendre un motif obligatoire partout aurait aussi imposé d’écrire lorsque l’on accordait une dispense. Le formulaire suit donc la décision prise.
Ce qu’un rejet ne doit pas changer
Une contestation rejetée ne retire pas ce que l’analyse avait déjà trouvé. Le détecté reste le plancher : refuser une déclaration n’efface pas un produit reconnu sur la carte. Des tests dédiés vérifient la concordance du verdict et du détail de la règle.
Voir aussi les hôtels qui n’ont rien envoyé
J’avais conçu l’accueil autour des dossiers à arbitrer. L’opératrice doit pourtant répondre sur tout le parc hôtelier, y compris sur les hôtels qui n’ont rien soumis. J’ai reconstruit l’accueil autour des marques : réponses reçues, conformité, dossiers à traiter et absences restent visibles ensemble.
« En fait, j’ai besoin de tout voir. » En revue, l’opératrice a déplacé le besoin : suivre l’ensemble des hôtels pour répondre aux établissements, aux groupes de franchisés et à sa direction.
Le parc doit aussi être couvert par les règles
Le parc hôtelier fournit le dénominateur du suivi. Une campagne dont le cahier laisserait une marque sans règles produirait des hôtels impossibles à évaluer. Le prototype bloque donc sa création et indique ce qui manque. Ce garde-fou est couvert par un test dédié ; la vidéo ci-dessus montre le suivi par marque.
Livraison et résultats observés
Le développeur du client a repris le frontend et travaille sur le backend et les données réelles. L’opératrice a aussi présenté elle-même le prototype à sa hiérarchie.
Le livrable comprend les parcours, le design system adapté à React et le contrat de données attendu par le front.
« Franchement c'est hyper fluide, c'est vraiment top parce que je n'ai pas vraiment beaucoup de temps à passer sur le front, je récupère tout. Ça permet vraiment d'avoir un prototype qui est exactement la même chose que l'application au final. »
Le dépôt et les vérifications transmis
React 19, TypeScript et Vite, un mode démo et un contrat d’API pour l’équipe backend. Le dépôt transmis contient 555 cas de test dans 100 fichiers. Ces vérifications se rejouent par une commande ; leur nombre ne démontre pas à lui seul la qualité de tous les parcours.
Vingt-six primitives ont été réimplémentées depuis les spécifications Figma du design system. Les audits de fin de mission documentent les corrections et les points encore ouverts. Les modifications demandées à la bibliothèque du groupe restent hors de mon périmètre vérifié.
Les limites
Prototype fonctionnel, sans backend ni authentification réelle, avec analyse simulée. Le développeur reprend l’affichage et doit implémenter la logique métier côté serveur.
Ce que je referais autrement
Je ferais intervenir les hôteliers plus tôt. Ils sont arrivés en cinquième semaine et ont fait bouger des écrans après le démarrage du développeur. Les rencontrer une semaine avant aurait placé ces retours avant cette reprise.