Masapalu

Le problème

Les clients d’un hôtel jonglent entre la réception, les menus imprimés, le comptoir des réservations et les guides de la ville — et l’expérience est la même pour tout le monde. Nous avons formulé le défi ainsi : How might we offrir un accès simple à tous les services de l’hôtel, pour que chaque séjour soit agréable et personnalisé ?

Deux utilisateurs très différents

Nous avons conçu pour les extrêmes, afin de couvrir tous ceux qui se situent entre les deux :

• Hildegard, 68 ans — enseignante à la retraite, peu à l’aise avec la technologie. Elle veut un contact direct, des conseils culturels et aucun coût caché. « S’il vous plaît, ne m’embêtez pas avec de la technologie compliquée. »
• Marcus, 44 ans — responsable commercial, très à l’aise avec la tech, futur papa. Il veut un check-in sans contact, un room service sans avoir à téléphoner et des options adaptées aux familles.

Nous avons cartographié une trentaine de jobs-to-be-done répartis en quatre clusters (restauration & boissons, détente & loisirs, conciergerie, explorer & se déplacer) ainsi qu’une stakeholder map allant des clients au housekeeping, à l’IT et aux plateformes de réservation.

Scope

Inclus : check-in/check-out, réservation d’activités, recommandations personnalisées, restaurants, transports, facturation, événements locaux. Exclus : réservation de vols et d’hôtels, paiements réels, statut VIP — utiles, mais pas nécessaires pour prouver le concept.

L’IA là où elle apporte de la valeur

Nous n’avons pas construit un chatbot. Chaque agent remplit une seule mission utile au client, avec des règles métier inscrites dans les prompts :

Agent	Mission
Concierge	Attribue une chambre au check-in et surclasse quand c’est possible (penthouse → suite → deluxe …)
Conseiller activités	Choisit cinq activités adaptées à l’âge, aux besoins d’accessibilité et aux particularités du client — n’invente jamais d’activité
Coordinateur de réservations (mon crew)	Décline le séjour en dates et ne renvoie que les créneaux qui ne chevauchent pas des réservations existantes
Gastronomie	Recommande un établissement de l’hôtel selon les préférences, le régime alimentaire et les horaires d’ouverture — pas de bar pour les moins de 18 ans

Un modèle local plutôt qu’une API payante. Les agents tournent sur Llama 3.1 via Ollama. Les petits modèles locaux sont moins fiables, nous les avons donc cadrés avec des contrats de sortie JSON stricts et des règles explicites — et la récupération des données se faisait de manière déterministe en Python avant de transmettre le contexte au modèle.

16 agents prévus, 4 livrés

Le concept prévoyait cinq crews et environ 16 agents. Nous avons livré quatre crews à agent unique qui fonctionnent de bout en bout. J’ai moi-même fusionné les crews « explore » et « relax » en un seul crew activités — mieux vaut moins d’agents, mais meilleurs, que beaucoup d’agents à moitié fonctionnels.

Ma contribution

• Mise en place du repository et de la structure du projet pour l’app et le backend.
• Développement du crew coordinateur de réservations (utility) et du crew explore, puis fusion d’explore et relax dans le crew activités.
• Mise en place de la base de données et des API chambres et activités.
• Dans l’app : l’écran d’accueil (météo, rendez-vous, recommandations), le détail et l’annulation des rendez-vous, l’espace profil et la barre de navigation sur mesure.
• Intégration des retours de nos tests utilisateurs dans la version finale.

Ce que j’en retiens

Les fonctionnalités IA sont des fonctionnalités produit : il leur faut une mission claire, des garde-fous et une solution de repli. Et à quatre, les issues, les branches et les pull requests n’étaient pas de la bureaucratie — c’était notre façon de garder une vision commune du produit.