design+code
Les hôtels choisissent un logiciel de gestion hôtelière (PMS) pour la réception. Puis ils découvrent, généralement au milieu d'un projet de site web, que cette même décision a discrètement fixé les limites de ce que peut être le parcours de réservation. Voici comment les deux sont liés, et ce qu'il faut vérifier avant de signer l'un ou l'autre contrat.
Un PMS est choisi par l'exploitation. Les critères sont la gestion des tarifs, le housekeeping, l'audit de nuit, le reporting, l'effort de formation pour l'équipe. Ce sont les bons critères pour les personnes qui utilisent le système tous les jours.
Le site arrive plus tard, souvent un ou deux ans plus tard, avec une autre agence et personne autour de la table qui ait participé à la première discussion. C'est à ce moment que quelqu'un demande si le parcours de réservation peut vivre sur le site plutôt que d'envoyer les clients vers un domaine tiers. La réponse dépend d'une décision prise bien avant, par des gens à qui on n'a pas posé la question.
Ce n'est pas un argument pour laisser le site web dicter le choix du PMS. C'est l'exploitation qui doit l'emporter sur ce point. C'est un argument pour savoir ce que vous achetez côté distribution au moment où vous l'achetez côté exploitation.
Le moteur de réservation est la partie qui récupère les disponibilités et les tarifs du PMS, les montre au client et enregistre la réservation en retour. On ne le construit presque jamais de zéro, parce qu'il doit gérer un inventaire en temps réel et encaisser des paiements, et qu'une erreur à ce niveau coûte cher, bien plus que sur une page marketing.
La question n'est pas de savoir si vous le construisez. C'est de savoir quelle part vous en contrôlez. Il existe trois niveaux en pratique, et c'est le PMS qui décide lequel vous est accessible.
Le premier est un moteur hébergé sur le domaine de l'éditeur. Le client clique sur Réserver et arrive sur booking.vendor.com. Cela fonctionne, quelqu'un d'autre s'occupe de la maintenance, et c'est ce qu'utilisent la plupart des petits établissements. Ce que vous perdez, c'est la dernière étape du tunnel : le design se rompt, le domaine change, et vos outils d'analyse demandent un travail supplémentaire pour suivre le client d'un domaine à l'autre.
Le deuxième est le même moteur intégré dans votre page, généralement via une iframe ou un widget en script. Visuellement, c'est plus proche de votre site. Mais les contraintes de mise en page sont réelles, et vous héritez du comportement responsive que l'éditeur a prévu, quel qu'il soit.
Le troisième est une interface sur mesure qui dialogue avec une API de réservation. Vous concevez chaque écran, l'URL ne quitte jamais votre domaine, et les données d'analyse sont propres de bout en bout. Encore faut-il que le PMS expose une API de réservation, et cela coûte nettement plus cher à construire et à maintenir, parce que l'éditeur fera évoluer cette API et qu'il faudra suivre.
Mews est pensé API d'abord et publie une API ouverte, avec une API dédiée au moteur de réservation, en plus d'un moteur hébergé et d'une large place de marché d'intégrations. Si un parcours de réservation sur mesure est envisagé, c'est ce type de système qui le rend possible.
Apaleo pousse la même logique plus loin. Il est conçu comme une couche de données centrale autour de laquelle on assemble le reste, ce qui convient à un établissement qui sait déjà qu'il veut composer sa propre pile d'outils plutôt qu'accepter un ensemble tout fait.
Cloudbeds regroupe le PMS, le channel manager, le moteur de réservation et les paiements dans un seul produit. C'est un vrai avantage pour un établissement sans partenaire technique : un seul éditeur, un seul support. La contrepartie, c'est que vous travaillez surtout dans leur cadre. Cloudbeds propose bien une API pour connecter un moteur de réservation tiers, mais passer par là revient à contourner l'ensemble que vous avez choisi pour sa simplicité.
Little Hotelier, de SiteMinder, est conçu pour les petits établissements, les maisons d'hôtes et les B&B. Il est volontairement simple, et simple veut dire que la surface personnalisable est réduite.
Oracle Opera est ce qu'utilisent la plupart des grandes chaînes. L'intégration passe par la plateforme d'intégration hôtelière d'Oracle, très complète, mais hors de portée du budget et du calendrier d'un établissement indépendant.
Nous décrivons ici des catégories, pas une recommandation. Le bon système dépend de votre nombre de chambres, de la présence ou non d'une personne technique après le lancement, et de la part de votre activité qui vient en direct plutôt que par les OTA. Une maison d'hôtes de dix chambres qui reçoit l'essentiel de ses réservations via Booking.com n'a pas besoin d'une API ouverte. Un groupe de trois établissements avec une vraie stratégie de réservation directe en a probablement besoin.
Cinq points, et un seul email à l'éditeur suffit.
Le parcours de réservation peut-il fonctionner sur notre propre domaine, et si oui, comment. Existe-t-il une API publique pour les disponibilités, les tarifs et les réservations, et son accès est-il inclus ou facturé à part. Peut-on personnaliser le moteur au-delà d'un changement de logo et de deux couleurs. Que deviennent nos données d'analyse et la gestion du consentement quand un client passe du site au parcours de réservation. Et comment les plans tarifaires et les promotions sont-ils exposés, car une page dédiée à une offre précise n'est possible que si cette offre est accessible depuis l'extérieur du système.
C'est ce dernier point qui est le plus souvent oublié. Une page de campagne qui ne peut pas renvoyer directement vers le bon tarif avec les dates préremplies est une page de campagne qui perd des clients au moment précis où ils ont décidé d'acheter.
Quand le parcours de réservation est hébergé ailleurs, le rôle du site change. Il cesse d'être l'endroit où se fait la transaction et devient l'endroit où se prend la décision. Les chambres doivent être assez bien photographiées et décrites pour que le client ait déjà choisi avant de cliquer. Le passage vers le moteur doit se faire en une seule action depuis n'importe quelle page du site. Et la transmission doit emporter le plus de contexte possible : établissement, type de chambre, dates, tarif.
La mesure doit aussi être configurée délibérément, car par défaut vos outils d'analyse perdent le client à la frontière du domaine, et vous ne pouvez plus dire quelles pages ont généré du chiffre d'affaires. Le suivi inter-domaines n'est pas compliqué, mais il ne se fait pas tout seul, et nous avons repris bon nombre de sites d'hôtels où il n'avait jamais été configuré.
Rien de tout cela ne fait d'un moteur hébergé un mauvais choix. Cela veut simplement dire que la contrainte est connue avant que le design commence, plutôt que découverte pendant le développement.
Nous réalisons des sites pour l'hôtellerie et la restauration, et nous intégrons le système de réservation que l'établissement utilise déjà, quel qu'il soit. Nous ne vendons pas de PMS et nous n'avons aucune raison d'en préférer un. Ce que nous demandons, tôt, c'est de quel système il s'agit et ce qu'il expose, parce que cette réponse détermine ce que nous pouvons concevoir.
Si vous choisissez un PMS et voulez connaître ses conséquences sur le site avant de vous engager, ou si vous en avez déjà un et voulez savoir ce que votre site actuel laisse de côté, écrivez-nous à bonjour@dellamattia.com.