Le node Wait dans n8n : mettre un workflow en pause (délai, webhook, formulaire)

Un workflow n8n n'est pas toujours une ligne droite qui s'exécute du premier au dernier node sans interruption. Certains processus ont besoin d'attendre : une validation humaine avant d'envoyer un email sensible, un délai réglementaire avant une relance, la confirmation d'un paiement qui arrivera par un webhook tiers dans les prochaines minutes, ou simplement une cadence plus lente pour ne pas saturer une API. Le node Wait est la brique native de n8n conçue exactement pour ça : suspendre une exécution, sans bloquer de ressource, jusqu'à ce qu'une condition précise soit remplie.

Les quatre façons de reprendre un workflow en pause

Le node Wait propose quatre modes de reprise, sélectionnables dans son paramètre Resume:

• After Time Interval — reprise après une durée fixe (secondes, minutes, heures ou jours), calculée à partir du moment où le node Wait est atteint.
• At Specified Time — reprise à une date et une heure précises, choisies via un sélecteur ou calculées dynamiquement par une expression.
• On Webhook Call — reprise dès réception d'un appel HTTP sur une URL unique générée pour cette exécution ($execution.resumeUrl).
• On Form Submitted — reprise dès qu'un formulaire hébergé par n8n est soumis, avec les champs de réponse injectés dans la suite du workflow.

Les deux premiers modes suffisent pour un simple cadencement ou un délai réglementaire. Les deux derniers ouvrent la porte à des workflows réellement interactifs : le n8n attend un signal externe précis plutôt qu'une simple durée.

Ce qui se passe pendant la pause

C'est le détail qui rassure le plus les instances self-hosted à ressources limitées : au-delà de 65 secondes d'attente, n8n décharge entièrement les données d'exécution en base de données. Aucun processus Node.js ne tourne en arrière-plan à surveiller une horloge — l'exécution est littéralement mise de côté, puis rechargée depuis la base au moment de la reprise. Une pause de trois jours ou de trois semaines ne coûte donc rien de plus qu'une pause de trois minutes en ressources serveur. En dessous de 65 secondes, l'exécution reste simplement en mémoire, ce qui reste négligeable.

Second détail important : le node Wait se cale sur l'heure du serveur n8n, jamais sur le fuseau horaire de votre compte ou de votre navigateur. Sur une instance Docker par défaut (souvent en UTC), une expression du type {{ $now.plus(1, 'day').set({hour: 9}) }} reprendra à 9h UTC, pas 9h heure de Paris — un décalage classique qui explique bien des relances envoyées « au milieu de la nuit ».

Reprise par webhook : le mode le plus flexible

Le mode On Webhook Call génère à chaque exécution une URL de reprise unique, accessible via $execution.resumeUrl. N'importe quel système externe capable d'envoyer une requête HTTP à cette URL peut débloquer le workflow : un webhook de confirmation Stripe, un bouton Slack (voir notre guide dédié sur l'approbation humaine avec le node Wait et Slack), un service tiers qui notifie la fin d'un traitement long, ou une simple requête déclenchée depuis un autre workflow n8n.

Le node expose directement quelques garde-fous à ne pas négliger :

• Authentification : Basic Auth, Header Auth ou JWT Auth, à activer dès que le workflow déclenche une action sensible — sans cela, toute personne qui intercepte l'URL (visible dans les logs d'exécution) peut relancer le workflow à votre place.
• Liste blanche d'IP, pour restreindre l'appel à une plage d'adresses connues (l'infrastructure d'un partenaire, par exemple).
• Mode de réponse : immédiate, à la fin du workflow, ou pilotée par un node Respond to Webhook placé plus loin — utile si la suite du traitement doit renvoyer un résultat à l'appelant plutôt qu'un simple accusé de réception.
• Limite de temps optionnelle : une durée ou une date au-delà de laquelle le workflow reprend automatiquement, même sans appel reçu — indispensable pour éviter qu'une exécution reste bloquée indéfiniment si l'événement attendu n'arrive jamais.

Reprise par formulaire : collecter une réponse humaine structurée

Le mode On Form Submitted héberge un formulaire n8n (titre, description et champs personnalisables : texte, nombre, date, liste déroulante, mot de passe) et met le workflow en pause jusqu'à sa soumission. C'est le complément naturel du Form Trigger pour les formulaires multi-étapes : là où le Form Trigger démarre un workflow, un Wait en mode formulaire permet de relancer une demande d'information au milieu d'un workflow déjà en cours — par exemple pour compléter un dossier incomplet sans repartir de zéro, comme détaillé dans notre article sur les relances de dossiers incomplets. Les réponses soumises sont injectées directement dans les données de l'exécution, exploitables par les nodes suivants exactement comme n'importe quel autre input.

Cas d'usage concrets

Cadencer des appels API IA. Un Wait de quelques centaines de millisecondes à quelques secondes, placé après chaque appel dans une boucle Loop Over Items (voir notre guide des boucles n8n), évite de saturer les limites RPM/TPM d'OpenAI ou d'Anthropic. Nous détaillons le dimensionnement précis de ce cadencement dans notre article sur les erreurs 429 et les rate limits IA : c'est exactement le mécanisme qu'utilisent en interne les workflows d'ingestion du Pack Assistant RAG.

Attendre un événement asynchrone externe. Un job de traitement long côté prestataire (génération vidéo, transcription volumineuse, traitement par lots facturé à l'heure) notifie généralement sa fin par un webhook plutôt que par une réponse HTTP immédiate. Un Wait en mode « On Webhook Call » évite de faire tourner le workflow en polling toutes les minutes en attendant que le résultat soit prêt.

Approbation humaine avant une action sensible. Envoi d'un virement, publication d'un contenu public, résiliation d'un contrat : autant d'actions où un Wait couplé à une notification Slack ou email, avec boutons interactifs, ajoute un point de contrôle humain avant l'irréversible. Une revue systématique publiée dans Entropy (Lazaros, Vrahatis & Kotsiantis, Human-in-the-Loop Artificial Intelligence: A Systematic Review of Concepts, Methods, and Applications, 2026 — voir sur Google Scholar) souligne que ces points d'arrêt sont d'autant plus efficaces qu'ils placent le point de contrôle avant une action irréversible, coûteuse ou à fort impact plutôt qu'en simple validation a posteriori — exactement la logique d'un Wait placé juste avant l'envoi ou la publication, et non après. Notre guide dédié sur l'approbation humaine couvre en détail la gestion du timeout et des boutons Slack — un pattern directement réutilisable dans les workflows d'audit du Pack Conformité & Audit.

Pièges fréquents

• Oublier la limite de temps sur les modes webhook et formulaire. Sans elle, une exécution qui n'a jamais reçu son événement reste active indéfiniment, encombrant la liste des exécutions en cours et compliquant le suivi des incidents réels.
• Ne pas distinguer une reprise normale d'une reprise par timeout. Un node IF juste après le Wait, qui teste la présence des données attendues, permet de router différemment selon qu'on a reçu une vraie réponse ou qu'on a atteint la limite de secours.
• Laisser l'URL de reprise sans authentification sur un workflow qui déclenche une action à conséquence réelle — la resumeUrl figure en clair dans les logs d'exécution, donc accessible à quiconque a les droits de consultation sur l'instance.
• Confondre fuseau horaire personnel et heure serveur pour les reprises à heure fixe, source classique de relances envoyées à un horaire décalé de plusieurs heures.
• Utiliser un Wait long sur un workflow synchrone attendu par un utilisateur en temps réel (un chatbot, par exemple) : réservez ce pattern aux traitements asynchrones, pas aux réponses interactives.

Pour aller plus loin

Le node Wait, dans ses différents modes, est déjà mobilisé dans les workflows du Pack Conformité & Audit (149 €) pour les circuits de validation, et dans ceux du Pack Assistant RAG (119 €) pour cadencer l'ingestion documentaire sans dépasser les limites des API IA. Si votre besoin est avant tout de suspendre un traitement en attendant un événement externe fiable, notre guide sur la gestion des erreurs avec l'Error Workflow complète utilement ce pattern pour capturer les cas où l'attente tourne mal plutôt que de laisser l'exécution s'éteindre en silence.