Approbation humaine dans n8n : mettre un workflow en pause avec le node Wait et des boutons Slack

Certains workflows ne devraient jamais s'exécuter sans qu'un humain ait donné son feu vert : l'envoi d'un email sensible à un client, la validation d'une dépense, la publication d'un contenu généré par IA, ou l'exécution d'une action irréversible sur un système de production. Automatiser entièrement ces cas serait imprudent — mais revenir au tout-manuel annule l'intérêt de n8n. La bonne réponse s'appelle le human-in-the-loop : le workflow tourne normalement, s'arrête à l'étape sensible, attend une décision humaine, puis reprend exactement là où il s'était arrêté. n8n dispose de tout ce qu'il faut pour ça nativement, sans outil tiers.

Le node Wait : quatre façons de reprendre un workflow

Le node Wait (n8n-nodes-base.wait) met une exécution en pause et la persiste en base de données — elle ne consomme aucune ressource tant qu'elle attend. Il propose quatre modes de reprise :

• Après un intervalle (After Time Interval) : reprise après X secondes, minutes ou heures fixes.
• À une heure précise (At Specified Time) : reprise à une date/heure donnée, utile pour aligner une action sur les horaires d'ouverture.
• Sur formulaire soumis (On Form Submitted) : reprise quand quelqu'un remplit un formulaire n8n généré automatiquement.
• Sur appel webhook (On Webhook Call) : reprise quand une requête HTTP arrive sur une URL unique générée pour cette exécution précise.

C'est ce dernier mode qui rend possible l'approbation par bouton Slack. Quand le node Wait est configuré en On Webhook Call, n8n expose l'URL de reprise via l'expression {{ $execution.resumeUrl }} — un lien unique, imprévisible et à usage unique : la première requête qui l'appelle reprend le workflow avec le corps de sa requête comme donnée d'entrée ; toute requête suivante sur la même URL échoue.

Construire le circuit d'approbation Slack

Le schéma le plus robuste sépare la notification de la reprise, pour garder le contrôle sur ce qui se passe entre les deux :

1. Nœud Slack (Send Message) juste avant le Wait : il poste un message avec des blocks Slack contenant deux boutons interactifs (« Approuver » / « Rejeter »), chacun avec une action_id distincte. Le message inclut le contexte utile à la décision (montant, destinataire, extrait du contenu généré par IA).
2. Nœud Wait en On Webhook Call, juste après. C'est lui qui génère le resumeUrl de cette exécution précise.
3. Un webhook dédié aux interactions Slack (nœud Webhook classique, ou Slack Trigger si votre plan le permet) reçoit le payload block_actions envoyé par Slack quand quelqu'un clique sur un bouton. Slack exige une réponse HTTP 200 en moins de 3 secondes : répondez immédiatement avec un corps vide, puis traitez la suite de façon asynchrone dans le même workflow ou dans un sub-workflow.
4. Ce webhook d'interaction appelle à son tour le resumeUrl de l'exécution en pause (nœud HTTP Request, méthode POST), en transmettant la décision (approve ou reject) dans le corps de la requête. C'est cet appel qui réveille le workflow originel.
5. Le workflow initial reprend après le node Wait avec la décision reçue dans $json, et branche sur un node IF ou Switch pour exécuter l'action si c'est approuvé, ou notifier un rejet sinon.

Ce découpage en deux workflows (le processus métier qui attend, et un petit workflow « routeur d'interactions Slack » qui traite tous vos boutons) évite de dupliquer la logique de vérification de signature Slack à chaque fois que vous ajoutez un nouveau point d'approbation.

Une variante plus simple, suffisante pour un usage interne à faible enjeu : mettre directement $execution.resumeUrl (avec un paramètre ?decision=approve ou ?decision=reject ajouté à l'URL) comme lien de deux boutons de type url dans le message Slack. Cliquer ouvre un lien qui appelle directement le webhook de reprise — pas besoin de second workflow, mais vous perdez la main sur la validation et la journalisation de l'interaction.

Ne jamais oublier le timeout

Un node Wait sans limite de temps attend jusqu'à 366 jours (la limite technique de n8n) — largement assez pour qu'une approbation oubliée bloque une exécution indéfiniment. Configurez systématiquement l'option « Limit Wait Time » du node avec une durée raisonnable (quelques heures pour une dépense, 24 à 48 heures pour une validation de contenu), et branchez la sortie « limite atteinte » sur un chemin de secours : escalade vers un second approbateur, rejet automatique avec notification, ou simple rappel Slack.

Sans ce garde-fou, une équipe qui grandit finit toujours par accumuler des dizaines d'exécutions en pause, invisibles, qui ne se terminent jamais — un problème classique qu'on retrouve aussi dans la gestion générale des échecs n8n, déjà détaillée dans notre article sur Retry, Continue on Error et Error Workflow.

Sécuriser le circuit

Trois points de vigilance concrets :

• Vérifiez la signature Slack sur le webhook d'interaction (en-tête X-Slack-Signature et secret de signature de l'app Slack), sans quoi n'importe qui connaissant l'URL du webhook pourrait forger de fausses approbations.
• Ne loggez jamais le resumeUrl dans un outil de supervision externe ou un canal Slack non restreint : il est à usage unique, mais tant qu'il n'a pas été consommé, quiconque le possède peut reprendre l'exécution à votre place.
• Restreignez le canal Slack où partent les demandes d'approbation aux personnes réellement habilitées à valider — un webhook exposé n'est un rempart que si l'accès en amont l'est aussi, comme on le rappelle dans notre guide pour sécuriser un webhook n8n exposé publiquement.

Un cas d'usage naturel : la conformité

Le human-in-the-loop trouve un terrain particulièrement pertinent dès qu'il faut prouver, a posteriori, qu'une décision a bien été validée par une personne identifiée avant qu'une action sensible ne se produise — exactement l'exigence derrière une piste d'audit RGPD. Combiné à une table de journalisation Supabase append-only comme celle décrite dans notre article sur la piste d'audit RGPD avec n8n et Supabase, le pattern Wait + Slack devient un vrai mécanisme de gouvernance : chaque décision d'approbation (qui, quand, quoi) s'enregistre automatiquement au moment de la reprise du workflow. C'est précisément ce que couvre notre Pack Conformité & Audit, avec des workflows d'approbation et de journalisation prêts à importer.

Aller plus loin : sub-workflows et données de reprise

Si votre circuit d'approbation vit dans un sub-workflow appelé via Execute Workflow depuis un processus parent, assurez-vous d'utiliser une version de n8n récente : les versions antérieures avaient un bug où les données renvoyées par un sub-workflow après une reprise sur Wait (webhook, formulaire ou approbation) n'étaient pas correctement transmises au workflow appelant. Le comportement a été corrigé, mais si vous êtes sur une instance self-hosted ancienne — voir notre comparatif self-hosted vs cloud pour les implications de maintenance — testez ce scénario précis avant de le généraliser à des processus critiques.

En résumé

Le node Wait transforme n8n en véritable moteur d'orchestration humain-machine : pas besoin d'outil tiers, pas de polling, pas de cron qui vérifie toutes les cinq minutes si quelqu'un a répondu. Un webhook de reprise, un timeout bien configuré, et une vérification de signature suffisent à construire un circuit d'approbation fiable pour vos actions les plus sensibles. Si l'enjeu est la conformité et la preuve d'une validation humaine, notre Pack Conformité & Audit et notre Bundle FlowKit Complet fournissent les briques d'approbation, de journalisation et d'audit déjà assemblées et prêtes à importer.