Modèles WhatsApp pour hôtels : exemples approuvés en 2026

Les modèles WhatsApp existent parce que Meta n'autorise pas les entreprises à envoyer librement des messages aux clients. En dehors d'une fenêtre de 24 heures qui suit le dernier message entrant du client, chaque message sortant doit être un modèle préapprouvé. Cette seule règle façonne la manière dont les hôtels peuvent utiliser le canal, le coût de chaque message et la fréquence à laquelle Meta limitera discrètement votre numéro lorsque quelque chose semble anormal.

Meta est le gardien. WhatsApp appartient à Meta, et la WhatsApp Business Platform fonctionne avec leur système d'approbation de modèles. Votre Business Solution Provider (BSP) soumet le modèle, Meta l'examine (généralement en quelques minutes, parfois une journée), et une fois approuvé vous pouvez l'envoyer aux clients qui ont donné leur opt-in. En cas d'erreur, le modèle reste en REJECTED avec un motif comme « Content violates policy » qui ne vous apprend presque rien.

La règle des 24 heures est celle que la plupart des équipes ops manquent dès le premier jour. Si un client vous écrit à 09h00, vous pouvez répondre librement, en texte, en images, en notes vocales, jusqu'à 09h00 le lendemain. Ensuite, uniquement des modèles approuvés. Et si vous voulez initier une conversation à froid, par exemple un rappel avant arrivée deux jours avant le check-in, ce premier message doit aussi être un modèle. Pas de négociation.

Les trois catégories de modèles

Meta classe chaque modèle dans l'une des trois catégories. La catégorie détermine la tarification (consultez le pilier sur les coûts WhatsApp pour les hôtels pour les chiffres par message), le contenu autorisé et la rigueur de l'examen.

Utilitaire

Messages transactionnels liés à une action précise que le client a effectuée ou attend. Confirmations de réservation, détails de check-in, récapitulatifs de folio, validations de late check-out. Le critère appliqué par Meta : le message doit se rapporter à une transaction réelle et nommée. Pas d'upselling glissé en bas.

Marketing

Contenu promotionnel. Offres spa, restaurant week, remises pour clients de retour, formules saisonnières. Tarif plus élevé et examen plus strict. Ces modèles sont aussi rapidement plafonnés si votre note de qualité chute.

Authentification

Mots de passe à usage unique et codes de vérification. Dans l'hôtellerie, c'est rare, mais cela apparaît avec l'émission de clés numériques, l'onboarding des serrures connectées, ou la vérification de comptes de fidélité. Meta impose une structure fixe et rejette tout ce qui s'en écarte.

Modèles utilitaires qui passent l'approbation

Voici cinq exemples que des hôtels avec lesquels nous travaillons ont fait approuver sans révision. Les variables sont indiquées {{1}}, {{2}} et ainsi de suite. Gardez-les courtes, nommez une transaction réelle, et résistez à la tentation d'ajouter une ligne marketing à la fin.

1. Confirmation de réservation

2. Rappel avant arrivée

3. Détails de check-in

4. Confirmation de late check-out

5. Notification de folio

Notez ce que ces modèles ont en commun. Chacun nomme une transaction, n'utilise des variables que pour les éléments dynamiques, et se termine par une invitation discrète à répondre plutôt que par un appel à réserver ou à acheter. Ce dernier détail est ce qui maintient le modèle dans la catégorie utilitaire au moment de l'examen.

Modèles marketing : quand ils fonctionnent et quand Meta les rejette

Les modèles marketing sont là où la plupart des hôtels rencontrent leurs premiers ennuis. Le contenu est autorisé, mais l'examen est intransigeant et les modes d'échec ne sont pas toujours évidents. Deux exemples qui passent généralement :

Offre client de retour

Formule saisonnière

Et voici les schémas de rejet que nous voyons le plus souvent. La plupart des établissements en touchent au moins un sur leur première soumission marketing.

• Variables vagues. Les modèles avec {{1}} comme corps entier sont rejetés parce que Meta ne peut pas voir ce que vous envoyez. Les variables ont besoin de contexte autour.
• Catégorie mixte. Une « confirmation de réservation » avec une offre spa en bas se lit comme du marketing déguisé en utilitaire. Meta soit la requalifie (vous payez alors les tarifs marketing), soit la rejette.
• Langage promotionnel dans un modèle utilitaire. Des mots comme « exclusif », « offre spéciale », « à ne pas manquer » dans ce qui prétend être un message transactionnel. Déplacez-les vers un modèle marketing ou supprimez-les.
• Pas de contexte d'opt-in clair. Si le modèle suppose une relation à laquelle le client n'a jamais consenti (« Bon retour ! » envoyé à quelqu'un qui n'a jamais séjourné), il sera signalé dès que le volume augmente.
• URL raccourcies. Bit.ly et similaires sont systématiquement rejetés. Utilisez votre propre domaine.

Modèles d'authentification

L'authentification est la plus petite catégorie pour les hôtels et la plus simple à réussir, principalement parce que Meta vous fournit une structure fixe et que vous remplissez les champs. Deux scénarios où elle apparaît :

• OTP de clé numérique. Le client reçoit un code à usage unique pour activer la clé mobile dans votre application ou via le flux de votre fournisseur de serrures.
• Appairage de serrure connectée. Codes pour les coffres-forts en chambre, accès secondaire pour les suites ou remises de check-in autonome après les heures d'ouverture.

Les modèles d'authentification sont les moins chers dans la plupart des régions et obtiennent l'approbation rapidement si vous limitez le corps à une seule phrase contenant la variable de code et une expiration. Tout ce qui dépasse, et Meta le bascule en utilitaire.

Ce que Meta rejette le plus souvent

En regroupant les motifs de rejet, voici la liste que nous parcourons avec les nouveaux établissements avant qu'ils ne soumettent leur premier modèle :

• Variables sans texte autour ({{1}} seul sur une ligne).
• Langage marketing dans des modèles utilitaires.
• Catégorie mal alignée (demande utilitaire, contenu lu comme marketing).
• URL raccourcies via des services tiers.
• Corps surchargés d'emojis sur des modèles utilitaires (un ou deux passent généralement, dix se lit comme du spam).
• Modèles génériques de type « Hi {{1}}, click here » sans référence à une transaction.
• Modèles dans une langue différente de celle déclarée à la soumission.
• Pieds de page ou boutons faisant référence à WhatsApp lui-même (« Message us on WhatsApp »). Meta n'autorise pas les CTA auto-référentiels.

Mais la cause la plus fréquente de rejet est plus simple que toutes celles-ci : un examinateur humain ne peut pas déterminer, à partir du seul modèle, quel événement réel a déclenché le message. Si votre modèle ne le rend pas évident, réécrivez-le.

Schémas de substitution de variables

Les variables sont positionnelles. {{1}} est le premier emplacement, {{2}} le second, et ainsi de suite. Elles ne peuvent pas être réutilisées dans un même modèle, et Meta attend désormais que vous fournissiez une valeur d'exemple pour chacune lors de la soumission. Quelques schémas qui tiennent la route en production :

• Nom + établissement. Hi {{1}}, this is {{2}}... Deux variables, le rôle de chacune est immédiatement clair.
• Paires de dates. Envoyez toujours les dates dans un format régional que le client comprend. Un client allemand qui voit 03/05 le lira comme le 3 mai ; un client américain ne lira « 3 May » correctement que si vous écrivez le nom du mois.
• Devise. Incluez le code ou le symbole de devise dans la variable : {{1}} = « EUR 240,00 », pas « 240,00 ». Moins d'ambiguïté au moment de l'évaluation de la qualité.
• Références de réservation. Gardez-les dans le corps, pas dans une variable d'en-tête séparée. Les variables d'en-tête sont tronquées sur certaines versions Android.

Un piège qui surprend les équipes : si votre PMS alimente le modèle via votre BSP, chaque variable a besoin d'un champ source mappé. Une source manquante sur {{4}} enverra silencieusement « {{4}} » au client. Demandez-moi comment je le sais. (Pour en savoir plus sur la circulation propre des données PMS, consultez les intégrations et API dans la stack tech hôtelière.)

Impact sur la note de qualité et comment se rétablir

Chaque numéro WhatsApp Business porte une note de qualité : verte, jaune ou rouge. Elle est calculée à partir de la manière dont les clients réagissent à vos messages. Bloquer, signaler, ignorer ou répondre, chacun ayant un poids différent. Vert signifie que vous pouvez envoyer jusqu'à la limite de votre niveau actuel. Jaune est un avertissement. Rouge signifie que Meta s'apprête à abaisser votre niveau, ce qui peut faire passer de 100 000 conversations par jour à 10 000 du jour au lendemain.

Les deux moyens les plus rapides de plomber une note : envoyer un modèle marketing à un client qui n'a pas donné son consentement, ou envoyer le même modèle trop souvent. Les sollicitations promotionnelles quotidiennes mènent rapidement au rouge.

Si vous chutez, le plan de redressement n'a rien de glamour. Suspendez tous les modèles marketing. Envoyez uniquement des modèles utilitaires déclenchés par des actions réelles des clients pendant deux à trois semaines. La qualité remonte généralement au vert en moins d'un mois si votre comportement sous-jacent était sain. Sinon, le numéro lui-même peut être signalé et vous devrez en discuter avec votre BSP. C'est le mode de défaillance qui vous coûte un samedi matin.

Liste de contrôle pratique pour la mise en place

Si vous partez de zéro, l'ordre compte plus qu'on ne le croit.

1. Choisissez un BSP. Twilio, 360dialog, MessageBird, Infobip, et une longue liste d'acteurs plus petits. Les tarifs varient sensiblement. Notre article sur les coûts Twilio et WhatsApp Business pour les hôtels en 2026 propose une analyse détaillée.
2. Vérifiez l'entreprise. La Meta Business Verification prend de 24 heures à deux semaines. Lancez-la avant d'en avoir besoin.
3. Soumettez vos premiers modèles. Confirmation de réservation, avant arrivée et détails d'enregistrement. L'approbation arrive généralement en quelques minutes ; comptez jusqu'à 24 heures.
4. Mappez les variables PMS. Chaque variable de modèle a besoin d'un champ source dans le PMS ou le CRM. Testez avec de vraies réservations avant la mise en production.
5. Définissez la gouvernance. Décidez qui peut soumettre un nouveau modèle. Nous avons vu des établissements se retrouver avec 40 modèles quasi-identiques parce que trois services ajoutaient chacun les leurs.
6. Suivez la qualité chaque semaine. La plupart des BSP affichent la note de qualité dans leur tableau de bord. Mettez-la dans l'agenda de quelqu'un.

Pour conclure

Les modèles ne sont pas la partie passionnante de WhatsApp pour les hôtels. C'est la partie qui décide si le canal fonctionne ou non. Les établissements qui prennent au sérieux l'hygiène des modèles (catégories claires, transactions nommées, comptes de variables raisonnables, pas de marketing dans l'utilitaire) finissent par envoyer plus de messages, payer moins par conversation et se faire rarement limiter.

Le reste relève du workflow. Savoir quel modèle déclencher et quand, garder les textes à jour sans tout resoumettre toutes les deux semaines, et s'assurer que le bon événement PMS déclenche le bon message. C'est la couche que l'AI Operator de Viqal gère pour les hôtels : sélection des modèles, remplissage des variables, suivi des opt-ins et surveillance de la qualité sur l'ensemble de votre portefeuille. Si vous souhaitez avoir une vue complète des coûts avant de décider de l'agressivité de votre stratégie sur ce canal, le pilier sur les coûts WhatsApp pour les hôtels couvre en détail la tarification par message, les limites de niveau et les marges des BSP.