Connecter votre propre domaine à un moteur de réservation
Le site est prêt. Le logo est le bon, les marges sont réglées, une réservation test est passée sur le sous-domaine de la plateforme, et quelqu'un à l'agence a déjà envoyé le lien à trois clients. Puis vient la question évidente : pourquoi l'adresse porte-t-elle encore le nom de quelqu'un d'autre ? Ce guide explique comment connecter votre propre domaine à un moteur de réservation sans faire appel à personne : ce que vous modifiez réellement, les deux ou trois enregistrements en jeu, pourquoi le cadenas apparaît plus tard que prévu, et le réglage qui casse en silence la messagerie de l'agence si vous y touchez.
Inutile de maîtriser le DNS en profondeur. Une seule idée suffit : votre nom de domaine est un panneau indicateur, et vous l'orientez vers un nouveau bâtiment. Tout ce qui suit n'est que le détail de cette idée.
Où vit réellement votre domaine
Jusqu'à trois sociétés différentes peuvent être concernées, et la plupart des dirigeants d'agence n'en connaissent qu'une. Le registrar est l'endroit où vous avez acheté le nom et où vous payez le renouvellement annuel. L'hébergeur DNS est l'endroit où l'on modifie les enregistrements de ce nom — souvent la même société que le registrar, parfois non, surtout si un webdesigner a tout installé il y a des années et déplacé le nom vers un service DNS séparé. L'hébergeur web, enfin, est l'endroit où tourne votre site actuel.
Les enregistrements que vous allez ajouter vont chez l'hébergeur DNS. Avant toute chose, identifiez-le. Connectez-vous chez le registrar et regardez les serveurs de noms (nameservers) indiqués sur le domaine. S'ils appartiennent au registrar, vous modifiez les enregistrements chez lui. S'ils pointent ailleurs, c'est là que vous travaillez. Quelques minutes passées ici évitent un après-midi à modifier des enregistrements dans un panneau que personne ne lit.
Domaine racine ou sous-domaine : décidez avant de toucher à quoi que ce soit
Le domaine racine (apex, ou domaine nu) est votremarque.fr, sans rien devant. Un sous-domaine est tout ce qui porte un préfixe : www.votremarque.fr, reservation.votremarque.fr, voyages.votremarque.fr. La plateforme accepte les deux, mais le choix détermine l'enregistrement à ajouter.
La raison est ancienne et non négociable. Le domaine racine porte déjà les enregistrements qui définissent le domaine lui-même, et le DNS n'autorise pas un CNAME à partager un nom avec quoi que ce soit d'autre. Un domaine racine se pointe donc avec un enregistrement A directement vers une adresse IP, tandis qu'un sous-domaine se pointe avec un CNAME vers un autre nom d'hôte.
| Racine (votremarque.fr) | Sous-domaine (reservation.votremarque.fr) | |
|---|---|---|
| Enregistrement à ajouter | Un enregistrement A vers une adresse IP | Un CNAME vers un nom d'hôte de la plateforme |
| Ce que tape le client | L'adresse la plus courte possible | Un mot de plus, qui pèse moins quand le client arrive par un lien |
| Votre site actuel | Doit quitter la racine, sinon le site de réservation le remplace | Reste exactement où il est |
| Messagerie de l'agence | Intacte tant que les enregistrements MX ne sont pas touchés | Intacte |
| Convient à | Une agence dont le site EST le site de réservation | Une agence qui veut garder son site vitrine, son blog ou son CMS |
La plupart des agences qui ont déjà un site devraient commencer par un sous-domaine. La ligne qui fait débat est la deuxième : certains dirigeants trouvent qu'un sous-domaine fait moins établi. L'avis se défend, et il pèse moins quand la plupart des clients arrivent par un lien WhatsApp ou Instagram plutôt qu'en tapant l'adresse.
Les enregistrements à ajouter, et à quoi sert chacun
L'étape DNS guidée affiche les valeurs exactes pour votre domaine. Copiez-les depuis cet écran, jamais depuis un article — celui-ci compris. Voici à quoi sert chaque enregistrement, pour que l'écran ait du sens quand vous le verrez.
- CNAME, pour un sous-domaine. Nom : le préfixe choisi, par exemple
reservation. Valeur : le nom d'hôte de la plateforme fourni par l'étape DNS. Il dit « ce nom est un alias de celui-là » ; si les serveurs de la plateforme déménagent, votre enregistrement continue de fonctionner sans que vous y touchiez. - Enregistrement A, pour un domaine racine. Nom :
@, que la plupart des interfaces DNS utilisent pour désigner le domaine nu. Valeur : l'adresse IP fournie par l'étape DNS. Il dit « ce nom habite à cette adresse ». - TXT, parfois. Certaines configurations d'hébergement demandent aussi un enregistrement de vérification : une longue chaîne aléatoire sous un nom précisé par l'étape DNS. Il ne fait rien pour les visiteurs. Il prouve que la personne qui contrôle le domaine a accepté la connexion. Si l'étape en affiche un, ajoutez-le ; sinon, rien ne manque.
Deux erreurs expliquent la plupart des échecs. La première consiste à saisir le domaine complet dans le champ Nom. Beaucoup d'interfaces ajoutent votre domaine automatiquement : reservation.votremarque.fr saisi à cet endroit devient reservation.votremarque.fr.votremarque.fr, qui ne mène nulle part. Saisissez uniquement le préfixe. La seconde consiste à laisser un ancien enregistrement en place. Si reservation a déjà un enregistrement A issu d'un ancien projet, un CNAME ne peut pas coexister avec lui, et certaines interfaces conservent l'ancien sans prévenir. Supprimez d'abord l'ancien enregistrement portant exactement ce nom.
Si votre hébergeur DNS propose un interrupteur de proxy sur l'enregistrement — Cloudflare l'affiche sous la forme d'un nuage orange — passez-le en mode DNS uniquement pendant la connexion. Un proxy répond aux visiteurs à la place de la plateforme, ce qui masque la plateforme au contrôle décrit ci-dessous.
Pourquoi le cadenas arrive en dernier
C'est l'étape qui fait croire aux dirigeants que quelque chose est cassé. Les enregistrements sont enregistrés, le domaine semble correct, et le navigateur affiche « connexion non sécurisée » — ou le site ne s'ouvre pas du tout. Rien n'est cassé. L'ordre est simplement imposé.
Un certificat TLS, le cadenas, est délivré par une autorité de certification qui doit d'abord vérifier que le domaine pointe réellement là où la demande l'affirme. Elle vérifie en interrogeant le DNS public et, dans la plupart des configurations, en envoyant une requête au domaine en attendant que la plateforme réponde. Tant que votre enregistrement n'a pas atteint les résolveurs qu'utilise cette autorité, la vérification échoue, et cliquer davantage n'y change rien. Dès que l'enregistrement se résout, la plateforme demande le certificat automatiquement. Vous ne l'achetez pas, ne le téléversez pas, ne le renouvelez pas.
Le temps nécessaire dépend surtout du TTL de l'enregistrement qui existait auparavant : la durée pendant laquelle les autres serveurs ont été autorisés à mémoriser l'ancienne réponse. Un nom tout neuf apparaît généralement vite. Un nom qui pointait ailleurs hier peut continuer à renvoyer l'ancienne adresse pendant un moment. Si vous savez que vous remplacez un enregistrement existant, baisser son TTL la veille raccourcit l'attente.
Sinon, patientez, puis vérifiez. Ne modifiez pas l'enregistrement en boucle : chaque modification donne aux serveurs qui ont mis en cache une mauvaise réponse une raison de plus de la servir. Les sites publics de consultation DNS montrent ce que le reste du monde voit pour votre nom ; quand ils affichent la valeur de l'étape DNS, le certificat est la prochaine chose qui se produit.
Ce que coûte une erreur
Les erreurs coûteuses ne sont pas dans le site de réservation. Elles sont dans tout ce qui est rattaché à votre domaine.
La pire consiste à changer les serveurs de noms alors qu'il suffisait d'ajouter un enregistrement. Déplacer les serveurs de noms confie tout le domaine à un nouvel hébergeur DNS, et chaque enregistrement non recréé là-bas disparaît — y compris les enregistrements MX qui acheminent la messagerie. Une agence peut perdre une journée d'e-mails clients, de confirmations fournisseurs et d'avis de changement d'horaire des compagnies aériennes avant que quiconque remarque que la boîte de réception s'est tue. Rien, dans la connexion d'un site de réservation, n'exige de déplacer les serveurs de noms. Ajoutez des enregistrements ; laissez le reste tranquille.
La deuxième consiste à pointer la racine vers le site de réservation alors que l'ancien site contient encore des pages utilisées : une page visas bien classée sur Google, une page contact imprimée sur les cartes de visite. Ces liens aboutissent désormais sur un site de réservation qui ne les a pas. Déplacez d'abord l'ancien site vers un sous-domaine, ou connectez plutôt le site de réservation à un sous-domaine.
La troisième ne coûte que des nerfs : annoncer la nouvelle adresse avant l'apparition du cadenas. Un navigateur qui éloigne vos clients de votre site le jour même où vous en faites la promotion, c'est une mauvaise entrée en matière. Annoncez une fois le certificat actif, pas une fois l'enregistrement sauvegardé.
Gardez le domaine de la plateforme : c'est votre solution de repli
Le sous-domaine de la plateforme sur lequel votre site a démarré ne disparaît pas quand vous connectez votre propre domaine. Il ne peut pas être supprimé, et c'est voulu.
C'est l'adresse depuis laquelle tester pendant que le domaine personnalisé se stabilise, et celle qui fonctionne encore si un renouvellement expire chez le registrar ou si quelqu'un modifie le DNS par erreur. Le moteur de réservation derrière les deux adresses est le même : réservations, clients et rapports ne se soucient pas de la porte empruntée. Notez cette adresse quelque part qui ne dépend pas du bon fonctionnement de votre propre domaine.
Elle fixe aussi le bon ordre pour un nouveau site, le même que pour lancer une OTA en une journée : mettez en ligne sur le sous-domaine que l'assistant d'inscription crée sans demander de carte, et connectez votre domaine quand le site mérite d'être montré. Ce que le site couvre une fois l'adresse à vous, c'est l'objet de ce qu'apporte vraiment un site de voyage en marque blanche.
Check-list : connecter votre propre domaine à un moteur de réservation
- Identifiez qui héberge votre DNS. Les serveurs de noms du domaine vous le disent.
- Choisissez racine ou sous-domaine. Si vous avez un site à conserver, choisissez un sous-domaine.
- Notez tous les enregistrements existants, surtout les MX, avant de changer quoi que ce soit. Une capture d'écran suffit.
- Supprimez tout ancien enregistrement portant exactement le nom que vous allez utiliser.
- Ajoutez l'enregistrement de l'étape DNS : CNAME pour un sous-domaine, A pour une racine, plus TXT si l'étape en affiche un. Saisissez seulement le préfixe dans le champ Nom.
- Passez tout proxy sur cet enregistrement en mode DNS uniquement.
- Attendez que l'enregistrement se résolve publiquement. Ne le modifiez plus.
- Vérifiez le cadenas, faites une réservation test sur la nouvelle adresse, puis prévenez vos clients.
L'essentiel de cette liste, c'est de l'attente. La seule étape qui peut vraiment vous nuire est celle qui n'y figure pas : déplacer les serveurs de noms.