WhatsApp Flows et n8n : capter des données structurées sans quitter la conversation
Publié le 24 août 2026 · 6 min de lecture
Un message WhatsApp qui renvoie vers un formulaire Typeform ou Google Forms fait perdre une partie des répondants au moment précis où ils quittent l'application pour ouvrir un navigateur. Une étude de Soni et al., publiée en 2022 dans Frontiers in Digital Health, a comparé un agent conversationnel et un formulaire en ligne classique pour la même collecte de données de santé : 69,9 % des participants ont préféré l'agent conversationnel, avec un Net Promoter Score nettement supérieur (24 contre 13) — un écart qui tient largement au fait de rester dans un seul environnement plutôt que de basculer d'une appli à une autre (Soni et al., 2022, Google Scholar). Les WhatsApp Flows de Meta appliquent ce même principe à la messagerie professionnelle : un formulaire natif qui s'affiche à l'intérieur même de la conversation, sans lien sortant. Le rendre dynamique, en le connectant à n8n, demande de comprendre une brique moins courue que les autres intégrations WhatsApp : le chiffrement de bout en bout imposé sur chaque échange.
Qu'est-ce qu'un WhatsApp Flow, concrètement
Un Flow est déclenché par un bouton d'appel à l'action inséré dans un message template approuvé par Meta. Au clic, WhatsApp ouvre un écran natif — pas une WebView, pas un navigateur — construit à partir d'un JSON déclarant des composants standard : champs texte, listes déroulantes, cases à cocher, sélecteurs de date. L'utilisateur navigue d'écran en écran sans jamais quitter l'application, et l'écran final envoie les réponses collectées vers votre système.
Deux modes existent :
- Flow statique : tous les écrans et leur enchaînement sont fixés à la conception. À la soumission finale, WhatsApp délivre les données par un simple message webhook classique — le même mécanisme que pour recevoir un message texte, déjà couvert dans notre guide de connexion WhatsApp Business.
- Flow dynamique (
data_exchange) : chaque transition d'écran interroge votre propre endpoint pour décider du contenu suivant — utile pour préremplir un champ, valider une saisie en temps réel, ou n'afficher un créneau de rendez-vous que s'il est réellement disponible. C'est ce mode qui impose le chiffrement, et c'est lui qui rend n8n vraiment utile ici : sans logique métier à interroger à chaque écran, un simple Flow statique suffit largement.
Le chiffrement de bout en bout : la vraie difficulté
Dès qu'un Flow utilise data_exchange, Meta chiffre systématiquement les échanges avec votre endpoint, dans les deux sens. La mise en place se fait en trois temps :
- Générer une paire de clés RSA de 2048 bits et uploader la clé publique via l'API Graph, rattachée à votre numéro WhatsApp Business.
- Recevoir des requêtes hybrides : chaque appel à votre endpoint contient une clé AES chiffrée avec votre clé publique RSA (algorithme RSA-OAEP), et le payload réel chiffré avec cette clé AES en mode AES-128-GCM, accompagné de son vecteur d'initialisation.
- Répondre en respectant le même schéma : déchiffrer la clé AES avec votre clé privée, déchiffrer le payload, produire la réponse métier, puis la rechiffrer avec la même clé AES — en inversant chaque bit du vecteur d'initialisation reçu, une exigence précise de la spécification Meta.
Le node Crypto natif de n8n, déjà détaillé dans notre guide sur le hachage et les signatures, sait déchiffrer un contenu RSA — ce qui couvre l'étape de récupération de la clé AES. Mais il ne propose pas le mode AES-GCM nécessaire pour le payload principal. Il faut donc passer par un node Code utilisant le module crypto natif de Node.js (crypto.privateDecrypt puis crypto.createDecipheriv('aes-128-gcm', ...)), ce qui suppose d'autoriser ce module intégré via NODE_FUNCTION_ALLOW_BUILTIN=crypto sur votre instance self-hosted — la variable exacte détaillée dans notre guide sur les modules npm et natifs du node Code.
Construire l'endpoint dans n8n
Le montage type ressemble à ceci :
- Webhook — en mode
Raw Bodyactivé, pour recevoir le payload chiffré tel quel, sans que n8n ne tente de le parser en JSON. - Code (déchiffrement) — récupère la clé AES et l'IV depuis le corps de la requête, déchiffre la clé avec la clé privée RSA, puis déchiffre le payload avec AES-128-GCM. Le résultat est un JSON classique contenant l'action demandée (
ping,INIT, ou le nom de l'écran en cours) et les données déjà saisies. - Switch sur le type d'action — un embranchement immédiat pour le health check (
ping), qui ne doit déclencher aucune logique métier et renvoyer directement{ "data": { "status": "active" } }. - Logique métier — pour un Flow de qualification de leads par exemple, une requête vers votre CRM ou votre base Supabase pour vérifier une disponibilité, enrichir une donnée, ou calculer l'écran suivant à afficher, sur le même principe que nos guides pour qualifier les leads entrants avec l'IA ou planifier un rendez-vous automatiquement.
- Code (rechiffrement) — reconstruit la réponse JSON attendue par WhatsApp, la chiffre avec la même clé AES et l'IV inversé bit à bit, encode le résultat en base64.
- Respond to Webhook — renvoie ce texte base64 brut, avec un
Content-Type: text/plain. C'est le piège le plus fréquent : n8n force souvent une réponse JSON par défaut, alors que Meta attend une chaîne de caractères pure, sans aucun enrobage{ }.
Isoler les étapes 2 et 5 dans un sub-workflow réutilisable évite de dupliquer la logique de chiffrement dans chaque workflow de Flow que vous construisez ensuite — une pratique déjà recommandée dans nos guides sur la piste d'audit RGPD et les évaluations de workflows IA.
Vérifier que la requête vient bien de Meta
Comme pour n'importe quel webhook exposé publiquement, chaque requête WhatsApp Flow porte un en-tête X-Hub-Signature-256, une signature HMAC calculée avec le secret de votre application Meta sur le corps brut de la requête. La vérifier avant même de tenter le déchiffrement RSA évite de dépenser du temps de calcul sur une requête forgée — le même réflexe que la vérification de signature déjà détaillée pour les webhooks Stripe ou GitHub.
Cas d'usage concrets pour une PME francophone
- Prise de rendez-vous : un Flow à trois écrans (service souhaité, créneau, coordonnées) qui n'affiche que les créneaux réellement libres, interrogés en temps réel via
data_exchange— l'équivalent conversationnel de notre guide sur la planification de rendez-vous par IA. - Qualification de leads : quelques questions structurées avant transfert vers un commercial, avec un score calculé à la volée par n8n plutôt qu'après coup.
- Enquête de satisfaction post-achat : les échelles de notation d'un Flow ont un taux de complétion nettement supérieur à un lien externe envoyé par SMS, sur le même principe que notre analyse des réponses NPS par IA.
Pièges fréquents
- Oublier le health check : un endpoint qui ne traite pas l'action
pingséparément du reste de la logique métier peut échouer ce contrôle et voir son Flow suspendu, même si les vraies soumissions fonctionnent. - Renvoyer du JSON structuré au lieu d'une chaîne chiffrée : Meta attend systématiquement une chaîne base64 en texte brut, jamais un objet.
- Timeout côté n8n : chaque transition d'écran attend une réponse rapide ; une logique métier trop lente (appel API tiers non optimisé) dégrade l'expérience jusqu'à faire échouer l'échange, un risque déjà documenté dans notre guide sur les retries et timeouts du node HTTP Request.
- Tester uniquement en développement : le Flow Builder de Meta propose un mode de prévisualisation sans passer par l'endpoint réel ; ne validez le chiffrement de bout en bout qu'avec de vraies requêtes envoyées à votre webhook n8n en production ou en préversion.
Pour aller plus loin
Un Flow de qualification de leads ne vaut que par ce qui se passe après la soumission : tri, priorisation, réponse. C'est exactement le rôle du Pack Inbox IA (79 €), qui prend le relais une fois la donnée structurée récupérée — classification, score d'urgence, digest quotidien. Si votre pile IA couvre aussi la conformité ou un assistant documentaire, le Bundle FlowKit Complet (269 €) réunit les trois packs sur cette même logique de traitement automatisé.
FAQ
Questions fréquentes
Faut-il coder pour utiliser un WhatsApp Flow avec n8n ?
Pour un Flow statique (des écrans fixes qui se terminent par un simple envoi de données), non : un Webhook n8n classique suffit à récupérer la soumission. Dès que le Flow est dynamique (data_exchange, plusieurs écrans qui dépendent des réponses précédentes), l'endpoint doit déchiffrer et rechiffrer chaque échange, ce qui demande un node Code avec le module crypto natif de Node.js — quelques dizaines de lignes, mais bien du code.
Peut-on utiliser le node Crypto natif de n8n pour tout l'échange chiffré ?
Partiellement. Le node Crypto sait déchiffrer un contenu RSA, ce qui couvre la clé AES glissée par Meta dans chaque requête. Mais le payload principal est chiffré en AES-128-GCM avec cette clé, un mode que le node Crypto ne propose pas nativement : il faut passer par un node Code avec crypto.createDecipheriv du module intégré de Node.js.
Pourquoi mon endpoint WhatsApp Flow renvoie-t-il une erreur alors que le déchiffrement fonctionne ?
La cause la plus fréquente est le format de la réponse : Meta attend une chaîne base64 brute en text/plain, pas un objet JSON. Un node Respond to Webhook laissé en mode JSON par défaut, ou un node Code qui retourne { status: 'ok' } au lieu du texte chiffré attendu, fait échouer l'échange même quand toute la logique de déchiffrement est correcte.
Meta vérifie-t-il que mon endpoint fonctionne avant de publier le Flow ?
Oui, par une requête de health check ({ "action": "ping" }) envoyée à intervalles réguliers, à laquelle l'endpoint doit répondre par un payload chiffré contenant { "data": { "status": "active" } }. Un Flow dont l'endpoint ne répond pas correctement à ce ping peut être suspendu automatiquement, même si les échanges réels fonctionnaient la veille.
Bundle FlowKit Complet
269 €