Refonte du Booking Engine D-Edge
Moderniser, unifier et élever le moteur de réservation hôtelière le plus utilisé d'Europe.
La version courte
- Designer solo dans une squad produit dédiée, arrivé en cours de route pour refondre le Booking Engine D-Edge — utilisé par des milliers d'hôteliers en Europe.
- J'ai unifié deux versions distinctes en une expérience responsive unique, alimenté le design system et piloté le monitoring post-lancement avec des data scientists.
- Dans une organisation où le design venait tout juste d'obtenir une place formelle, une grande partie du travail consistait à légitimer la démarche autant qu'à la pratiquer.
01 — Contexte & enjeux
Un produit stratégique à la croisée des chemins
D-Edge est né de la fusion de Fastbooking et Availpro. Deux acteurs historiques de la tech hôtelière qui se consolident, ça a du sens sur le papier, mais derrière ça laisse une dette importante : deux produits, deux bases de code, deux expériences utilisateur qui ne se ressemblent pas et qu'il faut réconcilier. Le Booking Engine portait ça. C'est la seule interface D-Edge que les voyageurs voient vraiment, et elle montrait ses cicatrices.
Le problème était concret : des hôteliers partaient. D'autres menaçaient de le faire. Guesty, Mews et d'autres proposaient des expériences mobiles qui donnaient l'air moderne, et le moteur existant avait deux versions maintenues séparément (une desktop, une mobile) avec tout ce que ça implique comme incohérences accumulées. Pour un produit aussi visible, l'écart se voyait.
C'est dans ce contexte que D-Edge a recruté sa toute première Head of Design et constitué une vraie équipe autour d'elle. L'idée : faire du design quelque chose de sérieux, des deux côtés du produit, pour les voyageurs qui réservent et pour les hôteliers qui font confiance à D-Edge pour vendre leurs chambres. Le Booking Engine était le premier chantier. Et le plus exposé.
02 — Rôle & équipe
Designer seul dans une squad produit complète
Je suis arrivé en cours de route. Un designer freelance avait posé les premières fondations visuelles et structurelles du nouveau moteur, et mon rôle était de prendre le relais et d'aller jusqu'à la livraison, seul designer dans une squad produit dédiée.
En parallèle, une équipe de 2 designers et 4 intégrateurs s'occupait du design system global de D-Edge. J'ai défini et livré des composants spécifiques au Booking Engine pour alimenter ce système, tout en l'utilisant comme base au quotidien. Être à la fois contributeur et utilisateur du même système demandait une coordination constante pour ne pas créer d'incohérences.
J'ai aussi mis en place le monitoring post-lancement avec la PM et des data scientists via Microsoft Clarity. Ce n'était pas dans mon périmètre habituel, mais ça m'a permis d'ancrer les décisions dans des comportements réels plutôt que de rester sur des hypothèses.
Le design venait d'obtenir une place formelle dans l'organisation, et une bonne partie du travail consistait à la défendre autant qu'à l'exercer : convaincre les devs, les PM, les commerciaux, la direction. Documenter les décisions, mettre en place des process, montrer la valeur du design par les chiffres et les tests. C'est ce qui finissait par faire bouger les choses.
03 — Démarche
Une recherche menée en amont et en aval
La recherche s'est faite en deux temps : avant pour orienter les décisions, après pour vérifier qu'elles tenaient dans la réalité. Sur un produit aussi exposé, tester des hypothèses non vérifiées coûte cher en temps, en crédibilité, en itérations évitables.
Benchmark concurrentiel
Du benchmark ciblé sur les plus gros concurrents du marché, en fonction des fonctionnalités sur lesquelles on travaillait. Pas un grand audit général, des références concrètes au bon moment, pour ne pas designer dans le vide.
Interviews utilisateurs
Deux profils très différents : des hôteliers pour comprendre les contraintes métier et ce qu'ils essaient de vendre à leurs clients, et des voyageurs pour identifier ce qui accroche, ce qui ralentit, ce qui pousse à aller voir ailleurs. Sur un produit B2B2C, passer à côté d'un des deux revient à ne concevoir que la moitié du produit.
Tests utilisateurs sur prototype
Sessions sur prototype Figma, avec des scénarios prédéfinis et une approche think-aloud, sur plusieurs parcours différents. L'idée n'était pas de confirmer ce qu'on pensait déjà savoir, c'était de laisser les utilisateurs faire remonter ce qu'on n'avait pas vu. Et ça marchait à chaque fois.
Outil de recherche — Dovetail
04 — Insights clés
Ce que la recherche a révélé
Les apprentissages se répartissaient en deux catégories assez différentes : des problèmes qu'on pouvait résoudre, et d'autres qu'on devait simplement documenter.
La page chambre était vraiment difficile à lire. Les gens ne comprenaient pas selon quel critère les chambres étaient classées, et les tarifs n'étaient pas clairs. Le défilement horizontal ajoutait une difficulté supplémentaire : beaucoup ne réalisaient pas qu'il y avait d'autres options derrière. Le détail des chambres était dense, les packages censés simplifier le choix compliquaient souvent la lecture. Résultat : de l'hésitation, des allers-retours, des abandons sur l'étape la plus critique. On a revu la hiérarchie de l'information, la façon de présenter les tarifs et la logique de classement des options.
Les messages de réassurance imposés par les hôteliers (conditions d'annulation, garanties, mentions légales) — étaient mal compris des voyageurs, parfois perçus comme anxiogènes. Mais leur présence n'était pas négociable, c'était une contrainte métier réelle. On a proposé des améliorations de formulation là où c'était possible, documenté le reste, et assumé la limite. C'est aussi ça, le travail réel d'un designer en contexte produit.
05 — Ce qu'on a conçu
Parcours, responsive et design system
Reprise et structuration des parcours
Reprendre le travail de quelqu'un d'autre, c'est souvent plus compliqué que repartir de zéro. Il faut comprendre les décisions existantes, distinguer ce qui tient de ce qui doit changer, et avancer sans casser la cohérence déjà posée. C'est ce que j'ai fait sur les parcours du moteur, de la sélection des dates jusqu'à la confirmation. La comparaison avant/après ci-dessous donne une idée de l'amplitude du changement.
Unification responsive
Le chantier le plus lourd était l'unification responsive. Passer de deux versions maintenues séparément à une expérience unique et cohérente sur tous les formats. Le mobile n'a pas été traité comme une adaptation de la version desktop : il avait ses propres contraintes de lecture, de navigation, d'interaction, et on les a travaillées comme telles. La vue Date Selection montre cette approche, une interface conçue d'abord pour le mobile, qui tient aussi bien sur grand écran.
Design system
Sur le design system, j'ai livré des composants spécifiques au Booking Engine pour alimenter le système commun géré par l'équipe dédiée. Chaque composant devait être assez générique pour s'intégrer au système global et assez précis pour répondre aux besoins du moteur. Les vues Room/Rate Selection et Summary illustrent ce que ça donne en pratique : des écrans denses en information, mais lisibles et stables sur tous les formats.
Avant · Après
06 — Déploiement & monitoring
Un lancement progressif, suivi avec rigueur
Le déploiement s'est fait progressivement, sur une sélection d'hôtels pilotes. L'objectif était d'observer ce qui se passait en conditions réelles — pas sur prototype, pas en test contrôlé — avant d'étendre à l'ensemble du parc.
J'ai mis en place le monitoring via Microsoft Clarity avec la PM et des data scientists. Ce que les premières données ont montré était double :
- Des comportements qui confirmaient la logique des parcours qu'on avait designés — une validation concrète des décisions de conception
- Des incohérences qu'on n'avait pas anticipées : des zones de clic, des patterns d'abandon qui ne correspondaient à aucune hypothèse claire et ouvraient des questions qu'on n'avait pas vues venir
La légère progression du nombre de réservations observée sur la phase pilote était cohérente avec nos attentes : un changement produit de cette nature ne produit pas d'effets immédiats et massifs. Il installe une base. Les résultats se lisent dans la durée.
07 — Résultats & apprentissages
Ce qu'on a livré, ce que j'en retiens
Ce projet m'a autant coûté qu'appris, et c'est probablement pour ça qu'il reste le plus formateur. Travailler dans une organisation qui est encore en train de se construire, où le design vient juste d'obtenir une place formelle, ça force une discipline que les contextes plus stables n'enseignent pas vraiment.
- La nécessité de tout tracer. Dans un environnement où les décisions vont vite et où la légitimité du design n'est pas acquise, la documentation protège. Pas pour faire du reporting, pour que les décisions survivent aux changements d'équipe et aux réunions où personne ne se souvient de ce qui avait été convenu.
- Faire passer une décision design, ça ne tient pas seulement à la qualité du travail. Ça tient à comment on l'amène, à qui, dans quel ordre. J'ai appris à lire les dynamiques d'une organisation autant qu'à concevoir des interfaces.
- La pédagogie. Expliquer une démarche UX à des PM, des commerciaux ou une direction qui n'y est pas habituée, c'est un vrai exercice. Pas quelque chose d'annexe au métier, quelque chose qui est au cœur de la façon dont le design existe dans une organisation.
Le contexte était épuisant. Mais ce que j'en retiens : un designer senior ne se mesure pas seulement à ce qu'il produit. Il se mesure à sa capacité à faire exister le design là où personne ne l'attendait vraiment.