Un workflow n8n qui envoie un e-mail à un client, crée une facture ou supprime des données va vite. Parfois trop vite : certaines actions ne devraient partir qu'après le feu vert d'une personne. Le workflow doit alors s'arrêter, demander, attendre la réponse, puis reprendre ou s'interrompre selon la décision.
n8n sait faire cela avec des briques natives. Cet article présente les deux principales, le nœud Wait et l'opération « Send and Wait for Response » de Slack, explique comment sécuriser l'URL de reprise et comment éviter qu'une demande reste sans réponse pour toujours. Les faits sur n8n viennent de sa documentation officielle, citée en fin d'article ; les recommandations sont notre analyse, à adapter à votre contexte.
Quand une validation humaine est justifiée
Placer une personne dans la boucle a un coût : un délai, et une interruption pour celui qui doit répondre. Elle se justifie quand l'action est difficile à annuler ou engage l'entreprise :
- un message envoyé à un client ou à un prospect ;
- une écriture comptable, un remboursement, une facture ;
- une suppression ou une modification en masse de données ;
- une décision prise à partir d'un texte produit par un modèle d'IA.
Pour les actions réversibles et à faible enjeu, mieux vaut laisser le workflow tourner et surveiller les erreurs. Nous avons détaillé la logique de décision, côté agents IA, dans Agent IA : validation humaine avant dépense ; cet article traite le côté mise en œuvre dans n8n.
Première brique : le nœud Wait
Le nœud Wait met l'exécution en pause. La documentation de n8n liste quatre manières de la reprendre :
| Option de reprise | Ce qui relance le workflow |
|---|---|
| After Time Interval | Un délai en secondes, minutes, heures ou jours |
| At Specified Time | Une date et une heure précises |
| On Webhook Call | La réception d'un appel HTTP |
| On Form Submitted | L'envoi d'un formulaire |
Pour une validation humaine, les deux dernières sont les plus utiles. Avec On Webhook Call, vous envoyez à la personne un message contenant un lien, et son clic relance le workflow. n8n met à disposition la variable $execution.resumeUrl, qui contient l'URL de reprise : elle peut donc être insérée dans un e-mail avant même d'exister. Selon la documentation, cette URL est propre à chaque exécution, ce qui permet d'enchaîner plusieurs nœuds Wait dans un même workflow.
Deux détails à connaître :
- Les exécutions en attente sont stockées en base. La documentation précise que, lorsque le workflow se met en pause, il décharge les données de l'exécution dans la base de données. Pour les attentes de moins de 65 secondes, ce n'est pas le cas : le workflow continue de tourner et reprend à l'échéance. Une validation humaine dure en général bien plus longtemps, donc elle passe par la base.
- Le suffixe de webhook. Quand un workflow contient plusieurs nœuds Wait en mode webhook, chacun reçoit un suffixe pour avoir sa propre URL. La documentation prévient que l'URL générée n'inclut pas ce suffixe automatiquement : il faut l'ajouter vous-même avant de partager le lien.
Sécuriser l'URL de reprise
Un lien de reprise est un point d'entrée dans votre workflow. Celui qui le possède peut le déclencher. Le nœud Wait, en mode webhook, propose les mêmes protections que le nœud Webhook :
- une authentification : Basic Auth, Header Auth, JWT Auth ou aucune ;
- une liste blanche d'adresses IP : les accès depuis d'autres adresses reçoivent une erreur 403.
Notre recommandation : pour une action sensible, ne laissez pas l'authentification sur « aucune ». Un lien envoyé par e-mail peut être transféré. Si l'approbation engage l'entreprise, privilégiez un canal où l'on sait qui répond, comme la solution Slack décrite plus bas. Pour aller plus loin sur l'authentification d'un point d'entrée n8n, voir Sécuriser un webhook n8n : authentification et HMAC.
Deuxième brique : « Send and Wait for Response » sur Slack
Plutôt que de construire le lien à la main, n8n propose sur certains nœuds une opération dédiée. Sur Slack, c'est Message > Send and Wait for Response. L'approbateur accepte ou refuse directement dans Slack. Selon la documentation, aucune page de navigateur ne s'ouvre : le workflow reprend dès qu'une personne répond.
Les réglages utiles, quand le type de réponse est « Approval » :
- Capture Who Responded : active les boutons interactifs de Slack et enregistre qui a répondu ;
- Restrict Who Can Approve : liste des personnes autorisées à décider ; les autres reçoivent un message privé et le workflow continue d'attendre ;
- After Decision : retirer les boutons en affichant le résultat (par défaut), retirer les boutons seuls, ou laisser le message tel quel. Dans ce dernier cas, la documentation précise que la première décision reste retenue.
En sortie, le nœud fournit notamment approved (la décision), respondedAt et un objet responder qui identifie la personne (identifiant, nom, nom d'utilisateur, e-mail). Ces champs vous permettent de brancher la suite avec un nœud If et de consigner qui a validé quoi.
Deux précautions, tirées de la documentation :
- si la liste des approbateurs est vide, n'importe qui voyant le message peut approuver ou refuser. Pour une décision sensible, utilisez un canal privé ou un message direct, et renseignez la liste ;
- la configuration demande une instance accessible publiquement en HTTPS, un identifiant Slack avec le secret de signature de l'application, et une URL de requête d'interactivité à renseigner côté Slack. Slack n'autorise qu'une URL par application : une application Slack sert donc une seule instance n8n.
Les types de réponse « Free Text » et « Custom Form » fonctionnent autrement : ils envoient des boutons-liens qui ouvrent une page de confirmation n8n. La sortie ne contient alors que approved et respondedAt, sans l'identité du répondant.
Prévoir le cas où personne ne répond
Un workflow qui attend une réponse sans limite finit par poser deux problèmes : une action qui n'arrive jamais, et des exécutions en attente qui s'accumulent. Le nœud Wait propose pour cela une option : faire reprendre automatiquement l'exécution après une limite, définie par un intervalle ou par une date précise. La documentation précise que n8n utilise toujours l'heure du serveur, quel que soit le fuseau horaire réglé dans le workflow.
Une règle simple à appliquer : décidez à l'avance ce qui se passe à l'échéance, et faites-en le chemin par défaut le plus prudent.
- Après le délai, ne pas agir : l'action sensible est abandonnée, et le workflow l'indique.
- Relancer l'approbateur une fois, par exemple après quelques heures.
- Escalader vers une autre personne si le délai est dépassé.
- Dans tous les cas, consigner le résultat : approuvé, refusé ou expiré, avec la date.
Reliez aussi ce workflow à votre système d'alerte, afin qu'un échec soit visible : voir Gérer les erreurs dans n8n : Error Trigger et alertes.
Les erreurs fréquentes
- Laisser l'URL de reprise sans authentification pour une action sensible.
- Oublier le suffixe quand plusieurs nœuds Wait coexistent, et partager un lien qui ne correspond pas au bon nœud.
- Approbateurs non restreints dans Slack : tout le canal peut décider.
- Pas de délai limite : la demande reste suspendue indéfiniment.
- Ne pas tester le refus : on vérifie le chemin « approuvé » et on découvre en production que « refusé » ne fait rien de propre.
- Valider trop de choses : si tout demande une approbation, les approbateurs cliquent sans lire. Réservez la validation aux actions qui le méritent.
Besoin d'automatisations avec des garde-fous ?
Vous voulez qu'un workflow demande l'accord d'une personne avant d'envoyer, payer ou supprimer, sans le transformer en usine à clics ? Décrivez-nous votre cas : nous identifions les étapes qui justifient une validation, mettons en place l'approbation, le délai limite et la traçabilité. Nos offres détaillent les formats d'accompagnement, et vous pouvez nous contacter directement.
Questions fréquentes
Peut-on valider un workflow n8n par e-mail ? Oui, avec le nœud Wait en mode webhook : le lien de reprise est inséré dans le message et le clic relance l'exécution. Pensez à protéger l'URL, car un e-mail peut être transféré.
Comment savoir qui a approuvé une action ? Avec « Send and Wait for Response » sur Slack et l'option « Capture Who Responded », la sortie du nœud contient un objet responder qui identifie la personne.
Que se passe-t-il si personne ne répond ? Sans limite, l'exécution reste en attente. Le nœud Wait permet de définir une limite, après laquelle l'exécution reprend automatiquement ; prévoyez dans ce cas un chemin par défaut prudent.
Une attente courte est-elle stockée en base ? Pour une attente de moins de 65 secondes, non : selon la documentation, l'exécution continue sans être déchargée en base de données.
Sources
- n8n, Wait node, documentation consultée le 24 octobre 2026.
- n8n, Slack node : Send and Wait for Response (approvals), documentation consultée le 24 octobre 2026.