Système de réservation directe d’hôtel : les 5 briques à régler

Un système de réservation directe d’hôtel, de gîte ou de chambre d’hôtes n’est pas un logiciel unique : c’est une chaîne de cinq briques qui se passent le relais, des pages du site jusqu’au message de confirmation reçu par le voyageur. Une réservation traverse les cinq briques : elle peut se perdre dans l’une d’elles, mais aussi à chaque passage de l’une à l’autre, là où un fournisseur s’arrête et où le suivant commence. Voici les cinq briques, une panne typique pour chacune et la question à poser à un prestataire.

Les cinq briques d’un système de réservation directe

Le voyageur ne voit qu’un parcours : il lit une page, choisit des dates, paie, reçoit un e-mail. Derrière, cinq briques travaillent à la suite, et chacune peut venir d’un fournisseur différent.

1. Les pages du site. Elles amènent à la réservation : présentation des hébergements, bouton « Réserver », conditions.
2. Le moteur de réservation. Il affiche les disponibilités et les tarifs, calcule le prix du séjour et enregistre la réservation.
3. Le paiement. Acompte, solde, empreinte de carte ou caution.
4. La synchronisation des calendriers. Elle retire des autres canaux de vente les dates prises en direct, et inversement.
5. Les messages envoyés au client. Confirmation, facture, rappels avant l’arrivée.

Pour chaque brique, les paragraphes qui suivent donnent ce qu’il faut vérifier, une panne typique et la question à poser. Les raisons de préférer la réservation directe aux plateformes, et ce qu’elle coûte, sont dans l’article sur la réservation directe d’un hôtel ; les leviers pour en obtenir davantage, dans celui sur l’augmentation des réservations directes.

Brique 1 : les pages du site qui mènent à la réservation

Avant le moteur, il y a la page où le voyageur décide de réserver. Elle doit donner de quoi décider (photos, équipements, conditions) et un chemin évident vers la réservation, depuis chaque page d’hébergement et pas seulement depuis l’accueil. Sur la page « Réservation » des Terrasses d’Antonin (chambres d’hôtes et gîtes du Luberon, un site équipé de Booky), relevée le 24 octobre 2026, une phrase indique que la réservation se fait au meilleur tarif sur le site officiel, un bouton ouvre les conditions générales de vente, et la recherche par dates (arrivée, départ, voyageurs) se trouve sur la page elle-même.

À vérifier. Le bouton « Réserver » est un vrai lien, présent dans l’en-tête et sur chaque page d’hébergement. Google indique que ses robots ne suivent de manière fiable qu’un lien écrit comme une balise <a> dotée d’un attribut href (aide de Google sur les liens explorables). La page doit aussi se charger vite et réagir sans à-coup : Google donne comme repères un plus grand élément affiché dans les 2,5 premières secondes, une réaction aux interactions en moins de 200 millisecondes et un décalage de mise en page inférieur à 0,1 (aide de Google sur les Core Web Vitals).

Panne typique. Le bouton n’est qu’un déclencheur JavaScript, ou il ouvre l’accueil du moteur sans l’hébergement ni les dates que le visiteur regardait : il doit tout ressaisir.

À demander. « Depuis la page d’une chambre, le bouton ouvre-t-il la réservation avec cette chambre et les dates déjà choisies, dans la langue de la page ? »

Brique 2 : le moteur de réservation

Le moteur est la brique qui connaît vos disponibilités, vos tarifs et vos règles de séjour (jours d’arrivée, durée minimale). Il peut être intégré au site, avec des écrans qui s’affichent dans les pages du site, ou être le module d’un autre éditeur, ouvert dans la page ou dans un nouvel onglet. Les avantages de chaque montage sont détaillés dans l’article sur le moteur de réservation d’un hôtel.

À vérifier. Le prix du séjour apparaît avec le résultat, avant la saisie des coordonnées ; les règles de séjour sont signalées dès la recherche plutôt qu’au dernier écran ; le parcours se fait au pouce sur un téléphone. Les écrans d’un tunnel de réservation sont décrits un à un dans l’article sur le tunnel de réservation.

Panne typique. Le moteur propose des dates que vos règles interdisent, ou affiche un prix différent de celui qui a été transmis à Google Hotels. Google demande que le prix transmis corresponde à celui de la page d’arrivée, pour tous les utilisateurs et tous les appareils (bonnes pratiques pour les liens de réservation gratuits) ; pour le détail, voir l’article consacré aux liens de réservation gratuits de Google Hotels.

À demander. « Où se saisissent les tarifs et les règles de séjour, et le même tarif sert-il au site et à l’envoi à Google Hotels ? »

Brique 3 : le paiement, l’acompte et la caution

Le paiement relie le moteur à la banque du voyageur. En ligne, il couvre en général trois choses : l’acompte ou le règlement du séjour à la réservation, le solde plus tard, et parfois une garantie, sous la forme d’une empreinte de carte ou d’une caution.

Ce qui complique la chose, c’est l’authentification forte du porteur de la carte, exigée par la DSP2, la directive européenne qui encadre les services de paiement. La note de l’Observatoire de la sécurité des moyens de paiement du 16 avril 2021, publiée sur le site de la Banque de France, distingue deux situations : les paiements que le voyageur déclenche lui-même sur le site, soumis à l’authentification forte sauf exemption, et ceux que le commerçant déclenche plus tard, hors de la présence du client, qui n’y sont pas soumis mais doivent porter la trace d’une authentification faite quand le client s’est engagé.

Parmi ces seconds, la note cite les sommes dues au titre de la garantie d’une réservation quand le client ne se présente pas. L’engagement doit préciser ce que le client accepte : le montant, le nombre de débits, leur fréquence et la durée de validité de l’accord.

Pour le cas d’usage « paiement associé à une réservation », qui couvre aussi le client qui ne se présente pas (le « no show »), la note prévoit une authentification forte au moment de la réservation, sur le montant maximal s’il est connu ou sur un montant nul sinon ; puis, quand le montant définitif est connu, une demande d’autorisation sans nouvelle authentification, accompagnée de la preuve de la première (note de l’OSMP, 16 avril 2021).

À vérifier. Faites un paiement d’essai, ou demandez le mode d’essai du prestataire, pour voir l’écran d’authentification de la banque sur un téléphone. Regardez ce qui est enregistré quand le voyageur abandonne à cet écran, et où s’affichent, avant le paiement, l’acompte, le solde et la caution.

Panne typique. L’authentification est abandonnée ou refusée, et le système enregistre une réservation sans paiement, ou un paiement sans réservation. Selon la note, un commerçant qui n’initie pas d’authentification s’expose à devoir traiter les refus (soft decline) envoyés par les banques ; elle invite le commerçant qui veut recourir aux exemptions à utiliser le protocole EMV 3-D Secure, dit « 3-D Secure v2 », qui sert aussi à gérer les authentifications que la banque déclenche.

À demander. « Quelle passerelle de paiement, avec quelle version de 3-D Secure, et comment sont traités l’acompte, le solde et la caution ? »

Brique 4 : la synchronisation des calendriers

Dès que vous vendez ailleurs (plateformes, agence, téléphone), cette brique décide si le site vend un hébergement déjà pris. Elle peut être faite par le moteur seul ou confiée à un channel manager distinct, relié par une connexion directe entre logiciels ou par un calendrier partagé. La différence entre les deux, et ce qu’elle change pour le délai, est expliquée dans l’article sur les channel managers ; les causes et les parades de la double réservation, dans celui sur les surréservations. Si vous ne vendez que par le site, cette brique se réduit au calendrier de votre propre moteur.

À vérifier. Les calendriers se mettent à jour dans les deux sens ; une annulation reçue d’une plateforme rouvre les dates ; une réservation prise ailleurs apparaît dans votre tableau de bord.

Panne typique. Une réservation arrive sur une plateforme alors que le calendrier du site n’a pas encore été mis à jour : le même hébergement est vendu deux fois. Le délai entre les deux mises à jour est la fenêtre de risque.

À demander. « Dans quel sens et à quel rythme les calendriers sont-ils mis à jour, et que se passe-t-il quand une annulation arrive d’une plateforme ? »

Brique 5 : les messages de confirmation et de suivi

Une réservation n’est terminée que lorsque le voyageur a reçu la preuve et les informations dont il a besoin : récapitulatif, conditions d’annulation, modalités d’arrivée, facture, rappels avant le séjour, message après.

À vérifier. Le message arrive en boîte de réception, testé sur deux messageries, dans la langue de la réservation. Il reprend les dates, l’hébergement, les montants réglés et le reste dû, ainsi que les conditions d’annulation. Regardez aussi d’où il est envoyé : depuis le 1^er février 2024, Google exige de tout expéditeur vers des comptes Gmail personnels que ses messages soient authentifiés par SPF ou DKIM ; au-delà de 5 000 messages par jour, il faut SPF, DKIM et DMARC (règles de Google pour les expéditeurs). Un petit établissement relève du premier niveau : le domaine d’expédition doit être authentifié.

Panne typique. La confirmation part dans les indésirables, ou est rejetée, parce que l’adresse d’expédition n’est pas authentifiée : le voyageur ne sait pas si sa réservation est faite.

À demander. « Depuis quelle adresse partent les messages, leur domaine est-il authentifié (SPF, DKIM), et peut-on modifier ou traduire les textes ? »

Comment relier les cinq briques sans rien perdre en route

Chaque brique peut fonctionner seule et la réservation se perdre pourtant au passage de l’une à l’autre. Le tableau récapitule les quatre jonctions à contrôler.

Le moyen le plus sûr de les contrôler est de parcourir la chaîne entière, comme le ferait un voyageur, avec une réservation d’essai.

1. Partir d’une page d’hébergement, sur téléphone. Touchez « Réserver » : les dates, l’hébergement et la langue arrivent-ils dans le moteur ?
2. Aller jusqu’au paiement. En mode d’essai, en passant par l’écran d’authentification de la banque, ou avec une réservation réelle que vous annulez ensuite.
3. Contrôler les calendriers. Les dates sont-elles bloquées dans le moteur, puis sur les autres canaux de vente ?
4. Ouvrir la confirmation sur deux messageries. Est-elle reçue, lisible, complète, avec les conditions d’annulation ?
5. Annuler. Les dates se rouvrent-elles, et le paiement est-il annulé ou remboursé ?
6. Recommencer dans chaque langue du site. Mêmes écrans, mêmes contrôles.

Ce qu’il faut demander avant de choisir

Les cinq questions des briques se résument en une demande : voir la chaîne fonctionner avant de signer. Concrètement, demandez :

• une réservation d’essai complète, de la page du site au message de confirmation, paiement compris ;
• la liste des messages envoyés au voyageur (confirmation, facture, rappels) et l’adresse d’expédition ;
• le sens et le rythme de la synchronisation des calendriers, par écrit ;
• la passerelle de paiement, et la façon dont l’acompte, le solde et la caution sont traités ;
• la sortie : pouvez-vous exporter vos réservations et vos clients, et que devient le paramétrage à la fin du contrat ? Cette question est développée dans l’article sur le moteur de réservation.

Booky, le moteur de réservation et de gestion de Hotel Web Design, couvre le moteur, le paiement, la synchronisation des calendriers et les messages pour les petites structures (gîtes, chambres d’hôtes, appartements, locations saisonnières et hôtels allant jusqu’à une vingtaine de chambres) : la recherche et la réservation se font dans le site, le paiement en ligne couvre l’acompte et le solde, avec une empreinte de carte pouvant faire office de caution, et la synchronisation des calendriers fonctionne dans les deux sens avec des plateformes telles que Booking, Airbnb et Homelidays.

Les factures sont automatiques, des e-mails planifiés partent avant l’arrivée du client et après son séjour, et la commission est de 0 % sur les réservations prises avec Booky. Avant la mise en ligne, des réservations et des paiements d’essai sont effectués. Le détail est sur la page de l’offre Booky.

Si votre établissement a déjà un moteur, ou si vous préférez un autre éditeur, le site s’y relie : voir l’intégration d’Octorate, d’Eviivo, de D-EDGE, de Reservit ou de MisterBooking. Les cinq briques, et les questions ci-dessus, restent les mêmes.

Sources consultées le 24 octobre 2026

Documents relus ce jour-là : Observatoire de la sécurité des moyens de paiement, note sur les cas d’usage de la DSP2 (16 avril 2021) ; Google, liens explorables ; Google, Core Web Vitals ; Google, bonnes pratiques pour les liens de réservation gratuits ; Google, règles pour les expéditeurs ; service-public.gouv.fr, droit de rétractation d’un achat à distance. Le site des Terrasses d’Antonin (page « Réservation ») a été consulté en ligne le 24 octobre 2026.

Questions fréquentes