WhatsApp dans Salesforce Marketing Cloud : le guide Summer ’26

WhatsApp est devenu le canal conversationnel par défaut d’une grande partie de vos clients, et la release Summer ’26 fait enfin de Salesforce Marketing Cloud une plateforme capable de l’orchestrer sérieusement : contacts WhatsApp disponibles dans les flux événementiels, mapping du consentement SMS et WhatsApp généralisé depuis le 17 août 2026, et suivi des conversions issues des publicités Click-to-WhatsApp de Meta. Ce guide vous montre comment structurer un canal WhatsApp propre dans SFMC : architecture de données, gestion du consentement, templates approuvés par Meta, déclenchement depuis Journey Builder ou Marketing Cloud Next, et mesure. Avec les requêtes et les appels API que vos équipes utiliseront réellement.

Pourquoi WhatsApp change la donne dans SFMC en 2026

Pendant longtemps, WhatsApp dans Marketing Cloud Engagement relevait du projet à part : un partenaire intermédiaire, une base de contacts parallèle, un consentement géré dans un coin de Data Extension. La release Summer ’26 réduit fortement cet écart. WhatsApp devient un contact point de première classe, au même titre que l’email ou le SMS, avec trois conséquences concrètes pour vos équipes.

Un canal, pas un silo

Les flux événementiels acceptent désormais SMS et WhatsApp comme points de contact. Autrement dit, le même événement métier — panier abandonné, colis expédié, rendez-vous confirmé — peut déclencher un message sur le canal préféré du client sans dupliquer la logique dans trois automatisations distinctes.

Un consentement enfin modélisé

Le mapping de consentement SMS et WhatsApp déployé progressivement jusqu’au 17 août 2026 aligne le modèle de données sur ce que le RGPD exige déjà de vous : une preuve d’opt-in par canal, horodatée, réversible. C’est la brique qui manquait pour industrialiser WhatsApp sans risque juridique.

Une mesure jusqu’à la conversion

Les conversations issues des publicités Click-to-WhatsApp de Meta sont désormais rattachables : les données de referral sont ingérées dans Data 360, ce qui permet enfin d’attribuer un chiffre d’affaires à un budget publicitaire social, et non plus seulement un volume de conversations.

WhatsApp n’est pas un canal d’envoi de plus : c’est un canal conversationnel soumis à des fenêtres de service de 24 heures et à des templates pré-approuvés. Toute architecture qui le traite comme un « SMS plus riche » finira bloquée par Meta, pas par Salesforce.

Préparer le socle : compte, numéro et templates

La mise en place se fait intégralement depuis l’outil d’inscription intégré de Marketing Cloud Engagement. C’est un point que beaucoup d’équipes découvrent trop tard : les actions réalisées directement dans Meta Business Manager ne remontent pas dans SFMC. Créez donc le compte WhatsApp Business (WABA) et enregistrez le numéro depuis Salesforce, sinon vous repartirez de zéro.

Trois points d’attention avant de lancer :

Un numéro dédié, jamais un numéro déjà rattaché à un compte WhatsApp personnel ou à un standard téléphonique.
Une vérification d’entreprise Meta finalisée en amont, faute de quoi vos limites d’envoi resteront très basses.
Une intégration Cloud API directe plutôt qu’un intermédiaire historique, désormais l’option recommandée pour la performance et la maintenance.

Les templates : la contrainte structurante

Tout message envoyé hors fenêtre de 24 heures doit passer par un template approuvé par Meta, avec une catégorie déclarée (marketing, utilitaire, authentification). Les variables sont numérotées, pas nommées : c’est cette numérotation qui dicte votre modèle de données.

Bonjour {{1}}, votre commande {{2}} a ete expediee.
Suivi : {{3}}
Repondez STOP pour ne plus recevoir ces messages.

Concrètement, chaque template devient un contrat entre votre Data Extension et Meta. Documentez-le : un tableau de correspondance évite les erreurs d’ordre de paramètres, qui sont la première cause d’échec en production.

Variable	Champ source	Type	Obligatoire
{{1}}	FirstName	Text (50)	Oui
{{2}}	OrderNumber	Text (20)	Oui
{{3}}	TrackingUrl	Text (255)	Oui

Modéliser le consentement WhatsApp proprement

Le consentement WhatsApp est distinct de l’opt-in email et distinct de l’opt-in SMS. Le confondre avec l’un des deux vous expose à la fois à une sanction CNIL et à une suspension de votre WABA par Meta. La structure minimale que nous déployons chez nos clients :

-- DE : WhatsApp_Consent
-- Cles : SubscriberKey (PK), MSISDN (PK)
-- Champs : OptInStatus, OptInDate, OptInSource, OptOutDate, LocaleCode

SELECT
    s.SubscriberKey,
    s.MSISDN,
    s.OptInStatus,
    s.OptInDate,
    s.OptInSource
FROM WhatsApp_Consent s
WHERE s.OptInStatus = 'OptedIn'
  AND s.OptOutDate IS NULL
  AND s.MSISDN IS NOT NULL

Deux règles non négociables. D’abord, stockez le MSISDN au format E.164 (indicatif pays inclus, sans espace ni zéro initial) : c’est le seul format accepté par l’API et la source la plus fréquente d’erreurs silencieuses. Ensuite, conservez la source de l’opt-in — formulaire web, Click-to-WhatsApp, borne en magasin — car c’est cette information que vous devrez produire en cas de contrôle.

Normaliser les numéros avant l’envoi

Un contrôle en amont coûte moins cher qu’un lot rejeté. En SSJS, dans Automation Studio :

<script runat="server">
Platform.Load("Core", "1.1.1");

function toE164(raw, defaultCc) {
    if (!raw) { return null; }
    var digits = String(raw).replace(/[^0-9+]/g, "");
    if (digits.indexOf("+") === 0) { return digits; }
    if (digits.indexOf("0") === 0) { digits = digits.substring(1); }
    return "+" + defaultCc + digits;
}

// Exemple : "06 12 34 56 78" -> "+33612345678"
var normalized = toE164("06 12 34 56 78", "33");
Write(normalized);
</script>

Déclencher un message WhatsApp depuis un parcours

Dans Marketing Cloud Engagement, une fois le template approuvé, vous créez le message dans Content Builder puis vous l’utilisez dans Journey Builder comme une activité d’envoi classique. Dans Marketing Cloud Next, la logique passe par les flux événementiels et la sélection du point de contact.

Pour les usages transactionnels à fort volume, l’appel direct à l’API REST reste la voie la plus fiable :

POST /messaging/v1/whatsapp/messages
Host: YOUR_SUBDOMAIN.rest.marketingcloudapis.com
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "definitionKey": "order_shipped_fr",
  "recipients": [
    {
      "contactKey": "CTC-948213",
      "to": "+33612345678",
      "attributes": {
        "1": "Camille",
        "2": "CMD-2026-88431",
        "3": "https://suivi.example.com/CMD-2026-88431"
      }
    }
  ]
}

Prévoyez systématiquement le traitement de la réponse asynchrone : WhatsApp renvoie des statuts sent, delivered, read et failed via webhook. Sans persistance de ces statuts dans une Data Extension dédiée, votre reporting sera aveugle sur la moitié du cycle de vie du message.

La fenêtre de 24 heures

Dès qu’un client vous répond, une fenêtre de service de 24 heures s’ouvre pendant laquelle vous pouvez envoyer des messages libres, hors template. Passé ce délai, retour obligatoire au template approuvé. Modélisez cette fenêtre dans vos parcours avec une date d’expiration calculée, sinon vos agents ou vos automatisations enverront des messages qui seront simplement rejetés.

Mesurer : du coût par conversation au chiffre d’affaires

WhatsApp est facturé à la conversation, pas au message. Un reporting construit sur le volume de messages envoyés vous donnera donc une vision fausse de votre coût réel. Trois indicateurs à mettre en place dès le premier mois :

Coût par conversation par catégorie (marketing, utilitaire, authentification), les tarifs différant fortement.
Taux de réponse entrante, meilleur signal de qualité de vos templates que le taux de lecture.
Chiffre d’affaires attribué aux conversations initiées par Click-to-WhatsApp, via les données de referral ingérées dans Data 360.

C’est ce dernier point qui transforme la conversation avec la direction. Tant que WhatsApp reste un centre de coût mesuré en volume, l’arbitrage budgétaire vous sera défavorable. Dès qu’il devient un canal attribué, il rejoint l’email dans les discussions de performance.

Les pièges que nous voyons le plus souvent

Sur les projets WhatsApp que nous accompagnons, quatre erreurs reviennent presque systématiquement. La première est de réutiliser l’opt-in SMS pour WhatsApp : juridiquement fragile, opérationnellement risqué. La deuxième est de multiplier les templates quasi identiques, ce qui allonge les délais d’approbation Meta et rend le reporting illisible. La troisième est d’oublier la gestion du désabonnement dans le corps du message, alors que Meta pénalise les comptes dont le taux de blocage grimpe. La quatrième, plus insidieuse, est de ne pas prévoir de canal de repli : quand un envoi WhatsApp échoue, votre parcours doit basculer sur SMS ou email, pas s’arrêter silencieusement.

À retenir

Créez tout depuis Salesforce. Le compte WABA et l’enregistrement du numéro doivent passer par l’outil intégré de Marketing Cloud Engagement ; ce que vous faites dans Meta Business Manager ne remonte pas.

Isolez le consentement WhatsApp. Une Data Extension dédiée, un MSISDN en E.164, une source d’opt-in tracée : c’est la condition d’un canal conforme et durable.

Traitez le template comme un contrat. Les variables numérotées imposent une table de correspondance documentée entre vos champs et les paramètres Meta.

Persistez les statuts webhook. Sans stockage des retours delivered / read / failed, votre reporting ignore la moitié du cycle de vie du message.

Mesurez en conversations, pas en messages. La facturation et l’attribution Click-to-WhatsApp sont ce qui rendra le canal défendable en comité budgétaire.

Vous préparez le lancement d’un canal WhatsApp dans Salesforce Marketing Cloud, ou vous souhaitez auditer une implémentation existante avant de passer à l’échelle ? Parlons-en avec les équipes CGC-Agency.