01 ÉTUDE DE CAS

une nuit de réception à l'Hôtel Molitor Paris

Handozio

Un produit d'opérations hôtelières pour garder le fil quand un bien passe d'une équipe à l'autre.

En ligne Produit, UX et implémentation web Opérations hôtelières

Le site produit est en ligne ; Handozio est actuellement en démarche commerciale.

Tableau de bord Handozio montrant les priorités opérationnelles, les tickets ouverts et les responsables.

Une idée née entre deux équipes

Après plusieurs saisons en réception de nuit à l’Hôtel Molitor Paris, certains problèmes n’avaient rien de spectaculaire. Un bagage laissé en consigne, une voiture confiée au valet, un incident à transmettre : le point fragile apparaissait souvent après, quand une autre équipe devait reprendre le fil.

Je ne cherchais pas à ajouter un logiciel de plus. Je cherchais à rendre visible ce qui se passait déjà, surtout lorsque la personne qui avait pris la demande n’était plus là.

Le problème n’était pas le bagage

Le problème était la continuité de la responsabilité. Qui a pris le bien en charge ? Dans quel état était-il ? Qu’est-ce qui a déjà été fait ? Que doit savoir l’équipe suivante ? Ces questions existent dans beaucoup de gestes de service, mais elles deviennent coûteuses lorsqu’elles restent dispersées dans un cahier, un message ou la mémoire d’un collègue.

Handozio est né de cette question : comment transformer une remise ponctuelle en trace utile sans imposer un processus plus lourd que l’opération elle-même ?

Ce qui a réellement été construit

Le cœur du produit prend la forme d’un ticket opérationnel. Un bagage, un véhicule ou un incident peut être créé, attribué, documenté et retrouvé dans une timeline. Les photos et observations gardent la preuve au même endroit que la responsabilité.

Le produit ajoute ensuite ce qui devient nécessaire pendant un service : des accès d’équipe, des notes internes, des messages, une passation entre shifts et des fiches exploitables pour les véhicules. Ce sont des prolongements d’un même fil, pas une collection de fonctionnalités séparées.

Handozio ne cherche pas à remplacer le PMS. Il prend en charge une couche plus précise : ce qui se passe entre la remise d’un bien et sa restitution, quand plusieurs personnes doivent agir sans partager le même moment de travail.

Une idée venue d’ailleurs

Le QR code est un bon exemple de la manière dont le produit a évolué. Pendant une réflexion autour de Logejri, j’ai réalisé qu’Handozio n’avait pas forcément besoin d’une application mobile dédiée pour certains usages. Un accès QR pouvait ouvrir le produit web au bon endroit, avec moins de friction d’adoption et moins de surface à maintenir.

Le lien entre les deux projets compte autant que la décision elle-même : une question posée dans un univers de découverte a amélioré un outil d’opérations hôtelières.

Notes en marge

Certaines décisions prennent un autre relief lorsqu'on se souvient d'où elles viennent.

Le QR code n'est pas né ici

Logejri → Handozio

Une idée peut changer de projet

L'idée du QR code est apparue pendant une réflexion autour de Logejri, pas pendant une session dédiée à Handozio.

Cette association a permis de voir qu'une partie de l'expérience Handozio pouvait passer par le web ouvert depuis un QR code — et qu'une application mobile dédiée n'était peut-être pas nécessaire pour ces usages.

Une passation n'est jamais seulement une phrase

Hôtel Molitor → Handozio

La nuit a laissé une question opérationnelle

Trois saisons d'été en réception de nuit à l'Hôtel Molitor m'ont placé devant des situations qui restaient ouvertes au changement d'équipe. L'information circulait, mais une petite imprécision pouvait tenir jusqu'au matin.

Handozio est né ensuite de cette observation : entre une interface idéale et un service réel, il faut une trace qui survive au shift.

Le produit s'est dessiné autour de la continuité

Quatre choix ont transformé une friction de service en système lisible.

  1. Commencer par le ticket, pas par le tableau de bord

    La plus petite unité utile est une opération identifiable : un bagage, un véhicule ou un incident, avec un statut, une responsabilité et un historique. Le tableau de bord vient ensuite, pour lire les traces plutôt que pour les remplacer.

  2. Faire de la passation une sortie produit

    Une passation n'est pas une note ajoutée à la fin. Elle doit transmettre le dernier état, les observations et la prochaine action à l'équipe qui reprend le service.

  3. Préférer l'accès QR à une application séparée

    L'idée est née pendant une réflexion autour de Logejri : un accès QR peut amener le produit web directement dans l'opération, sans ajouter une installation mobile à un workflow déjà chargé.

  4. Garder la preuve proportionnée

    Photos, observations, responsable et timeline répondent aux questions concrètes du service. La preuve aide l'équipe à reprendre le fil ; elle ne transforme pas l'outil en système juridique ou en dispositif de surveillance.

Handozio — Aujourd'hui

Handozio est en ligne et fait actuellement l'objet d'une démarche commerciale. Le site public présente le produit et ses usages ; cette étude de cas reste volontairement centrée sur les choix de conception, sans métriques clients ni résultats commerciaux inventés.

Le fil opérationnel, de la liste à la passation

Les écrans actuels montrent comment Handozio garde une opération lisible lorsqu'elle change de main.

Interface Handozio montrant des tickets bagages et véhicules avec statuts, responsables et priorités.
Les opérations ouvertes restent lisibles au changement d'équipe.Handozio
Vue Handozio de passation regroupant problèmes, actions immédiates et tickets à surveiller.
La passation transforme les urgences de service en ordre d'action.Handozio
Détail d'un ticket Handozio avec responsable, informations connues, photo et historique.
Le ticket garde responsabilité, preuve et prochaine action au même endroit.Handozio