Connecter WhatsApp Business à n8n : Cloud API, credentials et règle des 24 heures
Publié le 3 août 2026 · 10 min de lecture
Pour une PME francophone, WhatsApp a une propriété que ni l'email ni le SMS n'ont plus : les clients y répondent. Ce n'est pas qu'une impression de terrain — une étude de Church et de Oliveira présentée à MobileHCI 2013, « What's up with WhatsApp? », comparait déjà les usages de WhatsApp et du SMS et observait une messagerie perçue comme nettement plus conversationnelle, avec des échanges plus fréquents et plus informels, notamment en groupe. Un canal où la conversation est la norme, c'est exactement ce qu'un workflow d'automatisation bien conçu peut exploiter : accusé de réception immédiat, réponse aux questions fréquentes, escalade vers un humain quand il le faut.
La contrepartie : WhatsApp est le canal de messagerie le plus exigeant à brancher sur n8n. Là où un bot Telegram se crée en deux minutes avec un simple token de BotFather, la Cloud API de Meta impose une app développeur, un compte WhatsApp Business (WABA), un numéro dédié, des tokens à gérer proprement et une règle des 24 heures qui structure tout ce que votre bot a le droit d'envoyer. Ce guide couvre ces fondations : prérequis côté Meta, les deux nodes n8n (envoi et réception), la règle des 24 heures, et le passage du numéro de test à la production.
Pourquoi WhatsApp, et pourquoi ce n'est pas Telegram
Le choix du canal est un arbitrage entre audience et friction technique. Telegram offre l'API la plus simple du marché, mais votre clientèle n'y est probablement pas. WhatsApp, c'est l'inverse : l'application de messagerie dominante sur la plupart des marchés francophones, mais derrière une API d'entreprise avec ses règles, sa vérification business et sa facturation des templates.
Cette exigence n'est pas gratuite : c'est elle qui garde le canal peu pollué. Pas de bot anonyme créé en deux clics, un expéditeur rattaché à une entreprise vérifiable, des envois sortants encadrés. Un message WhatsApp bien utilisé arrive donc dans un espace que le client considère encore comme personnel — un privilège qui se perd vite en cas d'abus (Meta surveille signalements et blocages). Le calcul est simple : pour un canal interne ou un public technophile, commencez par Telegram ; pour parler à vos clients là où ils répondent, WhatsApp vaut la friction de mise en place, qui ne se paie qu'une fois.
Prérequis côté Meta : app, WABA et numéro
Avant de toucher à n8n, quatre briques doivent exister côté Meta :
- Un compte Meta développeur (developers.facebook.com), gratuit, lié à votre compte Meta.
- Une app Meta de type Business, à laquelle vous ajoutez le produit WhatsApp. C'est cette app qui porte l'App ID et l'App Secret dont le trigger n8n aura besoin.
- Un WhatsApp Business Account (WABA), créé ou rattaché lors de l'ajout du produit WhatsApp. C'est le conteneur de vos numéros, de vos templates et de votre facturation.
- Un numéro de téléphone dédié. Point crucial : un numéro ne peut pas être à la fois enregistré dans l'application WhatsApp classique et sur la Cloud API. Pour développer, ne sacrifiez aucun numéro réel : Meta fournit un numéro de test gratuit dans l'interface développeur, qui peut envoyer des messages vers une petite liste de numéros destinataires que vous déclarez. C'est amplement suffisant pour construire et tester tout le workflow.
Une fois le produit WhatsApp ajouté, l'onglet API Setup de l'app affiche les deux identifiants que n8n demandera : le Phone Number ID (identifiant technique du numéro, distinct du numéro lui-même) et le WhatsApp Business Account ID.
Credentials n8n : exigez un token permanent
Le node WhatsApp Business Cloud de n8n s'authentifie avec un access token, accompagné du Phone Number ID pour l'envoi. Et c'est ici que la plupart des installations cassent au bout d'un jour : le token affiché dans l'interface développeur Meta est un token temporaire de 24 heures. Parfait pour valider la connexion, catastrophique en production — le workflow s'arrête silencieusement le lendemain.
La solution propre est un token de System User, créé dans les Paramètres Business de Meta (Business Settings → Users → System Users) :
- Créez un System User (rôle Admin ou Employee selon votre organisation).
- Donnez-lui accès à votre app et à votre WABA.
- Générez un token avec les permissions
whatsapp_business_messagingetwhatsapp_business_management, en choisissant une expiration « never ».
C'est ce token-là qui va dans le credential n8n : il ne dépend d'aucune session personnelle et survit au départ d'un collaborateur. Traitez-le comme n'importe quel secret de production — stocké uniquement dans les credentials n8n, jamais dans un node Code ou un champ de workflow, selon les réflexes détaillés dans notre guide de sécurisation des credentials API.
Envoyer : le node WhatsApp Business Cloud
Une fois le credential en place, le node d'envoi couvre trois familles de messages :
- Texte : le message libre classique, avec le champ Recipient Phone Number au format international. C'est le format de vos réponses automatiques dans la fenêtre de 24 heures.
- Médias : image, document, audio ou vidéo, par URL publique ou par upload. Utile pour envoyer une facture PDF, une photo de produit, une confirmation visuelle.
- Template : les messages pré-approuvés par Meta, seuls autorisés hors fenêtre de 24 heures. Le node permet de choisir le template par son nom et de remplir ses variables (le
{{1}},{{2}}définis à la création du modèle dans le WhatsApp Manager).
Un envoi de texte minimal se résume à trois réglages : l'opération Send Message, le Phone Number ID de votre numéro expéditeur, et le destinataire. Le numéro de test Meta ajoute une contrainte : le destinataire doit figurer dans la liste des numéros de test déclarés dans l'interface développeur, sinon l'API rejette l'appel — une erreur classique qui n'a rien à voir avec n8n.
Recevoir : le node WhatsApp Trigger
La réception passe par le node WhatsApp Trigger, qui expose un webhook appelé par Meta à chaque message entrant. Sa configuration a deux faces :
Côté n8n, le trigger utilise un credential distinct de celui de l'envoi : App ID + App Secret de votre app Meta (l'App Secret sert à vérifier la signature des webhooks entrants — c'est votre garantie que les appels viennent bien de Meta).
Côté Meta, dans la configuration Webhooks du produit WhatsApp de votre app :
- Renseignez l'URL du webhook fournie par le node n8n et le token de vérification.
- Abonnez l'app au champ
messages— sans cet abonnement, le webhook est vérifié mais ne reçoit jamais rien, l'oubli le plus fréquent de toute la mise en place.
Le payload entrant suit la structure imbriquée des webhooks Meta. Le message du client se trouve au fond de entry[].changes[].value.messages[] :
{
"messages": [{
"from": "33612345678",
"id": "wamid.XXXX",
"timestamp": "1722672000",
"type": "text",
"text": { "body": "Bonjour, ma commande est-elle expédiée ?" }
}],
"contacts": [{ "profile": { "name": "Marie D." }, "wa_id": "33612345678" }]
}
Trois champs servent systématiquement : messages[0].from (le numéro du client, qui devient le destinataire de la réponse), messages[0].text.body (le contenu), et messages[0].type (un client peut envoyer une image ou un vocal, que le workflow doit au minimum détecter pour ne pas router du vide vers la logique de texte).
La règle des 24 heures : la contrainte qui structure tout
C'est la règle à comprendre avant d'écrire le moindre workflow. WhatsApp distingue deux situations :
- Dans les 24 heures suivant le dernier message du client : vous pouvez envoyer des messages libres — texte, médias, réponse générée par un agent IA. C'est la « fenêtre de service client ».
- Au-delà de 24 heures (ou pour initier une conversation) : seuls les messages template sont autorisés. Ce sont des modèles soumis à Meta et approuvés avant usage, classés par catégorie (utilitaire, marketing, authentification), et facturés à l'envoi — Meta est passé à un modèle de tarification par message template, dont les montants varient selon le pays et la catégorie ; référez-vous à la tarification officielle de Meta plutôt qu'à tout chiffre trouvé dans un article, le barème évoluant régulièrement.
Concrètement : tant que le client vient de vous écrire, répondez librement et gratuitement. Pour le relancer trois jours plus tard, il faut un template approuvé, et chaque envoi a un coût. Cette asymétrie a une vertu de conception : elle pousse à construire des bots qui répondent plutôt que des bots qui sollicitent — précisément ce que vos clients toléreront le mieux.
Workflow de fondation : réception, routage, escalade
Voici l'ossature que nous recommandons pour un premier workflow WhatsApp, avant toute sophistication :
- WhatsApp Trigger — réception du message, abonné au champ
messages. - Node Switch — un premier tri sur
messages[0].type: le texte continue, les médias et vocaux partent vers une réponse d'attente (« un conseiller vous répond rapidement ») et une notification interne. - Classification — un node IA léger classe le texte : question fréquente (horaires, suivi de commande, tarifs) ou demande complexe.
- Branche question fréquente — une réponse générée par un agent IA, envoyée via le node WhatsApp Business Cloud. Pour que le bot tienne une vraie conversation sur plusieurs messages, il lui faut une mémoire par client — le numéro
fromsert de clé de session, selon le mécanisme détaillé dans notre guide sur la mémoire de conversation d'un agent IA. - Branche demande complexe — pas de réponse automatique hasardeuse : notification de l'équipe sur Slack avec le contexte, et éventuellement une étape d'approbation humaine avec le node Wait si le bot propose un brouillon de réponse qu'un humain valide avant envoi.
Ce squelette est volontairement minimal : la version complète, avec un agent IA branché sur votre base de connaissances, fait l'objet de notre guide dédié au chatbot RAG sur WhatsApp. Le présent guide s'arrête là où celui-ci commence : une connexion propre, un token qui n'expire pas, un routage qui distingue ce que le bot sait traiter de ce qu'il doit escalader.
Du numéro de test à la production
Le numéro de test Meta permet de construire tout ce qui précède sans engager de numéro réel. Le passage en production ajoute deux étapes :
- Enregistrer un vrai numéro sur la Cloud API — un numéro dédié, joignable pour recevoir le code de vérification, et non utilisé dans l'application WhatsApp.
- La vérification du business par Meta (Business Verification, dans les Paramètres Business) : Meta vérifie l'existence légale de votre entreprise, documents à l'appui. Sans elle, votre numéro reste soumis à des limites strictes.
Côté volumes, Meta applique des limites progressives sur les conversations initiées par l'entreprise (celles qui commencent par un template) : un palier de départ, puis des paliers supérieurs débloqués automatiquement à mesure que le numéro envoie du volume avec une bonne qualité (peu de blocages et de signalements). Les seuils exacts ont changé plusieurs fois et sont documentés chez Meta — retenez le principe plutôt que des chiffres : la capacité d'envoi se gagne progressivement, et la qualité perçue par les destinataires en est la clé. Les réponses dans la fenêtre de 24 heures ne sont pas concernées par ces paliers.
Pièges fréquents
- Mettre le token temporaire de 24 h dans le credential n8n : tout fonctionne le jour du test, plus rien le lendemain. Générez un token de System User sans expiration dès le départ.
- Oublier l'abonnement au champ
messagesdans la configuration webhook de l'app Meta : le webhook est vérifié avec succès mais le trigger ne reçoit jamais rien. - Confondre le numéro de téléphone et le Phone Number ID : l'API attend l'identifiant technique affiché dans l'interface développeur, pas le numéro au format international.
- Tester l'envoi vers un numéro non déclaré alors que vous êtes encore sur le numéro de test : l'API rejette l'appel tant que le destinataire ne figure pas dans la liste des numéros de test.
- Ignorer la règle des 24 heures et tenter d'envoyer un message libre hors fenêtre : l'erreur API est déroutante si l'on ne connaît pas la règle ; hors fenêtre, seul un template approuvé passe.
- Ne router que le type
textsans prévoir les images, vocaux et documents que les clients envoient spontanément : le workflow doit au minimum les détecter et les escalader. - Utiliser le numéro WhatsApp existant de l'entreprise, qui serait retiré de l'application : prenez un numéro dédié à l'API.
En résumé
Connecter WhatsApp Business à n8n demande plus de préparation que n'importe quel autre canal de messagerie — app Meta, WABA, numéro dédié, token de System User, webhook abonné à messages — mais chacune de ces étapes ne se fait qu'une fois, et le résultat est un canal où vos automatisations parlent aux clients là où ils répondent réellement. La règle des 24 heures, loin d'être une simple contrainte, dessine la bonne architecture : un bot qui répond vite et bien dans la fenêtre, des templates réservés aux relances qui en valent le coût, et une escalade humaine pour le reste. Si votre premier objectif est justement de trier et traiter les demandes entrantes — sur WhatsApp comme sur votre boîte mail — le Pack Inbox IA (79 €) fournit des workflows prêts à l'emploi de classification, réponse automatique et escalade, la même logique de fond que ce guide applique au canal WhatsApp.
FAQ
Questions fréquentes
Peut-on utiliser son numéro WhatsApp actuel avec la Cloud API et n8n ?
Pas simultanément : un numéro ne peut pas être à la fois enregistré dans l'application WhatsApp (ou WhatsApp Business) et sur la Cloud API. Pour utiliser un numéro déjà actif dans l'application, il faut d'abord supprimer le compte associé dans l'app, ce qui est rarement souhaitable. La bonne pratique est un numéro dédié à l'automatisation — et pour développer, le numéro de test fourni gratuitement par Meta dans l'interface développeur suffit largement, sans engager aucun numéro réel.
Pourquoi mon workflow n8n ne peut-il plus répondre à un client sur WhatsApp après un certain temps ?
C'est la règle des 24 heures de la plateforme : vous ne pouvez envoyer des messages libres (texte, média, réponse d'un agent IA) que dans les 24 heures qui suivent le dernier message reçu du client. Au-delà, seuls les messages template — des modèles pré-approuvés par Meta, facturés à l'envoi — sont acceptés ; tout autre envoi est rejeté par l'API. Concrètement, votre workflow doit soit répondre dans la fenêtre, soit basculer sur un template pour relancer la conversation.
Quelle différence entre le token affiché dans l'interface développeur Meta et un token de System User ?
Le token temporaire généré dans l'onglet API Setup de l'app expire au bout de 24 heures : pratique pour un premier test, inutilisable en production puisque votre credential n8n cesserait de fonctionner chaque jour. Un token de System User, créé dans les Paramètres Business de Meta (Business Settings → Users → System Users) avec les permissions WhatsApp et un accès à l'app, peut être généré sans expiration : c'est celui qu'il faut coller dans le credential n8n pour un workflow durable.
Bundle FlowKit Complet
269 €