Notes · IA, données et règles

Une réservation ne se termine pas au paiement. Elle se termine quand le client lit la confirmation.

Ce que Gmail exige des expéditeurs, ce qui a changé en novembre 2025, pourquoi une seule newsletter peut changer pour de bon les règles de vos confirmations, et comment le vérifier en un après-midi.

Daniel Esteban Feo7 min de lecture

Imaginez : un vendredi de décembre, une famille londonienne réserve une suite dans un hôtel de Gstaad sur son site. Le paiement passe sans difficulté. La confirmation part du serveur du site avec l’adresse de l’hôtel, mais ce serveur ne fait pas partie de ceux autorisés à envoyer des courriels en son nom. Gmail la classe en spam. La famille ne la trouve pas. Le samedi, elle écrit à la réception pour demander si la réservation existe. Le dimanche, par précaution, elle réserve aussi un autre hôtel sur une plateforme.

On investit beaucoup pour que le client réserve sur le site. Presque rien pour que le courriel qui le confirme arrive. Or ce courriel est la première chose que le client reçoit de vous après avoir payé.

Ce que Gmail exige.

Depuis le 1er février 2024, Google exige de quiconque envoie des courriels vers des comptes Gmail personnels une authentification SPF ou DKIM, des enregistrements DNS directs et inverses valides, une connexion chiffrée et un taux de spam inférieur à 0,3 %. À qui envoie environ 5000 messages par jour ou plus, il exige en outre SPF et DKIM à la fois, un enregistrement DMARC, même avec la politique la plus souple, un domaine d’expéditeur aligné sur le domaine authentifié et, pour les courriels marketing, une désinscription en un clic traitée en 48 heures.

Depuis novembre 2025, selon Google, Gmail durcit l’application de ces règles : les messages non conformes subissent des rejets temporaires et définitifs. Les messages non authentifiés peuvent finir en spam ou être renvoyés avec un code d’erreur. Les règles visent le courrier qui arrive sur des comptes Gmail personnels, c’est-à-dire là où se trouvent le plus souvent vos patients, vos clients et les familles qui vous écrivent.

Le détail que presque personne ne lit.

Pour Gmail, le seuil de 5000 messages par jour se compte par domaine principal : les envois de hotel.ch et ceux de news.hotel.ch s’additionnent. Et quiconque l’atteint une seule fois est classé expéditeur en masse pour toujours. Google le dit clairement : ce statut n’expire pas, et changer sa façon d’envoyer ne le change pas.

Autrement dit, une seule grosse newsletter envoyée aux anciens clients peut modifier de façon définitive les règles que doivent respecter les confirmations de réservation envoyées par votre site. Une deuxième nuance est utile. Les confirmations de réservation et de formulaire sont dispensées de la désinscription en un clic, parce que ce sont des courriels transactionnels. Elles ne sont pas dispensées d’authentification.

Ce que je ne sais pas.

Google ne publie pas combien de courriels il rejette en vertu de ces règles, et je n’ai pas de chiffre fiable sur le nombre de confirmations perdues dans les cliniques, les hôtels ou les agences immobilières. Ce que je sais, c’est que la panne est silencieuse. L’expéditeur ne voit pas le dossier spam du destinataire, et le client appelle rarement pour dire qu’il n’a rien reçu. Je soupçonne que, la plupart du temps, il ne revient tout simplement pas.

Un courriel qui n’arrive pas ne déclenche aucune erreur. Il laisse un silence.

Ma position.

Je crois que le courriel de confirmation fait partie de l’expérience, et n’est pas un détail technique à laisser à l’hébergeur. Chaque système qui écrit au nom de votre entreprise, qu’il s’agisse du site, du moteur de réservation, du CRM, de l’outil de newsletter ou du logiciel de la clinique, doit être autorisé, et quelqu’un doit lire les rapports que renvoie DMARC. Sur mon propre domaine, DMARC est réglé sur la politique la plus stricte, celle qui demande de rejeter tout ce qui n’est pas authentifié. Une réservation ne se termine pas au paiement. Elle se termine quand le client lit la confirmation.

Ce que je vérifierais.

  • Qui envoie en votre nom. Le site, le moteur de réservation, le CRM, l’outil de newsletter et le logiciel de gestion.
  • SPF, DKIM et DMARC. S’ils existent et couvrent tous ces expéditeurs, pas seulement la boîte principale.
  • L’expéditeur visible. Que l’adresse que voit le client soit sur votre domaine et corresponde à celle authentifiée.
  • Le volume. Si vous avez déjà envoyé environ 5000 courriels en un jour vers des comptes Gmail, sous-domaines compris.
  • Le vrai test. Une réservation d’essai vers un compte Gmail personnel et un compte Outlook, en regardant aussi le dossier spam.

Par où commencer.

  1. Cette semaine

    Faire le test

    Réserver ou écrire via le site depuis un compte personnel et voir où arrive la confirmation.

  2. Ce mois-ci

    Faire l’inventaire

    La liste de tous les systèmes qui envoient des courriels avec votre domaine, avec leur responsable.

  3. Ce trimestre

    Authentifier et surveiller

    SPF, DKIM et DMARC pour chaque expéditeur, et des rapports DMARC que quelqu’un lit vraiment.

  4. À chaque changement

    Refaire le test

    Chaque fois que vous changez de prestataire, de moteur de réservation ou d’outil de newsletter.

Faites de mémoire la liste de tout ce qui envoie des e-mails au nom de votre entreprise : le site, le moteur de réservation, la facturation, la newsletter, le CRM, ce formulaire que quelqu’un a installé il y a deux ans. Comparez-la ensuite avec celle de votre équipe technique.

Si les deux listes ne coïncident pas, vous tenez peut-être déjà une piste sur la raison pour laquelle certains clients disent n’avoir jamais reçu la confirmation. Et il reste un doute pire : combien ne l’ont pas dit ?

Si vous voulez que je vérifie ce que deviennent les e-mails que votre site envoie en votre nom, commencez par le Diagnostic stratégique. Les systèmes autorisés à écrire au nom de votre entreprise relèvent de votre direction et de votre équipe technique, pas d’un designer.