Timeout webhook n8n : pourquoi un agent IA fait échouer l'appel (et comment répondre tout de suite)

Un agent IA n8n qui enchaîne plusieurs appels d'outils — recherche documentaire, appel LLM, écriture en base — peut légitimement prendre 10, 30, parfois 60 secondes à répondre. C'est normal pour un agent. C'est en revanche largement au-delà de ce que tolèrent la plupart des appelants HTTP : Slack coupe après 3 secondes si votre commande slash n'a pas accusé réception, Cloudflare en plan gratuit ferme la connexion à 100 secondes sans exception possible, et un load balancer ou un simple client fetch() côté navigateur abandonne souvent bien avant. Résultat classique : l'exécution n8n se termine avec succès dans les logs, l'agent a bien répondu — mais l'appelant a déjà vu une erreur de timeout, ou pire, a retenté la requête et déclenché l'agent une seconde fois.

Ce n'est pas un bug de n8n ni de votre prompt. C'est une architecture synchrone appliquée à un traitement qui ne l'est pas.

Pourquoi un agent IA fait exploser les timeouts webhook

Un appel LLM simple répond en général en une à quelques secondes. Un agent avec outils (AI Agent node, voir notre guide complet du node AI Agent) enchaîne plusieurs allers-retours : le modèle décide d'appeler un outil, l'outil s'exécute, le résultat repart vers le modèle qui décide de la suite. Trois ou quatre itérations suffisent à dépasser largement la seconde de latence d'un appel isolé, sans qu'il y ait le moindre dysfonctionnement — c'est le fonctionnement normal d'un agent qui raisonne en plusieurs étapes.

Une étude de référence sur la tolérance d'attente des utilisateurs web, Nah (2004), A study on tolerable waiting time: how long are Web users willing to wait?, publiée dans Behaviour & Information Technology, situe le seuil de tolérance sans retour visuel autour de deux secondes — et montre surtout qu'un simple retour d'information (un accusé de réception, un indicateur de progression) prolonge nettement ce seuil. C'est exactement le principe du pattern décrit plus bas : ce n'est pas la durée réelle du traitement qui pose problème, c'est l'absence de réponse immédiate pendant ce délai.

Les trois modes de réponse du node Webhook

Le node Webhook de n8n propose un paramètre Respond, avec trois réglages possibles :

• Immediately — répond dès la réception de la requête, avant même l'exécution du reste du workflow. Rapide, mais impossible de renvoyer un résultat calculé.
• When Last Node Finishes — le réglage par défaut, et la cause n° 1 des timeouts avec un agent IA : la réponse HTTP n'part qu'une fois tout le workflow terminé, agent compris.
• Using 'Respond to Webhook' Node — la réponse part au moment où l'exécution atteint un node Respond to Webhook placé explicitement dans le flux, quel que soit ce qui se passe ensuite.

C'est ce troisième mode qui débloque le pattern asynchrone : il découple le moment où l'appelant reçoit une réponse du moment où l'agent termine réellement son travail.

Le pattern qui règle la majorité des cas : répondre tout de suite, traiter ensuite

Le principe tient en une phrase : accuser réception en quelques millisecondes, puis laisser l'agent travailler en arrière-plan. Concrètement dans n8n :

1. Webhook — mode de réponse « Using Respond to Webhook Node ».
2. Génération d'un identifiant de tâche (un node Code ou Set, un UUID) et enregistrement d'une ligne « en cours » dans une table Supabase — voir notre guide de connexion Supabase à n8n si ce n'est pas encore en place.
3. Respond to Webhook — renvoie immédiatement { "status": "processing", "jobId": "..." } (HTTP 202 Accepted, plus honnête qu'un 200 pour un traitement encore en cours). L'exécution n8n continue normalement après ce node : envoyer la réponse HTTP ne met pas fin au workflow.
4. AI Agent — s'exécute ensuite sans aucune contrainte de temps liée à l'appelant d'origine.
5. Mise à jour de la table Supabase avec le résultat final, puis livraison par l'un des trois canaux ci-dessous.

Livrer le résultat : callback, message édité ou statut interrogeable

• Callback URL — si l'appelant est lui-même un système (une API tierce, un autre workflow n8n), il fournit une URL de rappel dans sa requête initiale ; un node HTTP Request en fin de traitement y poste le résultat.
• response_url Slack — pour une commande slash ou un bouton interactif, Slack fournit un response_url valable plusieurs minutes : accusez réception en moins de 3 secondes, puis postez le message final sur cette URL une fois l'agent terminé. Ce mécanisme complète bien le pattern d'attente humaine décrit dans notre article sur l'approbation via boutons Slack, pour le cas où c'est l'IA, et non un humain, qui prend du temps à répondre.
• Point de terminaison de statut — pour une API publique, le client interroge GET /statut/{jobId} (un second workflow n8n, déclenché par un webhook, qui lit simplement la table Supabase) jusqu'à ce que le statut passe à « terminé ». C'est le pattern adapté à une API de questions-réponses RAG exposée à des clients externes, où la latence de recherche documentaire plus génération peut varier fortement d'une requête à l'autre.

Le node Wait avec reprise par webhook : l'autre sens du problème

À ne pas confondre : le node Wait de n8n propose lui aussi une option « Resume: On Webhook Call », mais dans le sens inverse. Là où le pattern ci-dessus répond vite pour ensuite laisser le temps à l'agent, le Wait en mode webhook met en pause un workflow déjà lancé jusqu'à ce qu'un système externe rappelle une URL de reprise — utile par exemple quand un bot de questionnaire guidé attend la validation d'un humain à une étape intermédiaire, ou quand un service tiers doit terminer un traitement long avant que la suite du workflow ne puisse continuer. Les deux mécanismes se combinent bien dans les workflows d'agents conversationnels multi-étapes, mais ils répondent à des besoins différents : le premier protège l'appelant d'un timeout, le second protège votre workflow d'une attente active inutile.

Ne vous contentez pas d'augmenter les timeouts du reverse proxy

Le réflexe le plus courant face à un timeout webhook est de monter proxy_read_timeout sur Nginx, d'ajuster Traefik ou d'espérer que Cloudflare laisse passer plus longtemps — voir notre guide sur l'exposition de n8n en HTTPS derrière Traefik ou Caddy pour ces réglages quand ils sont pertinents. C'est un pansement, pas une solution : Cloudflare plafonne la durée d'une requête HTTP à 100 secondes en plan gratuit, sans aucun moyen de la relever, et Slack ne négociera jamais son délai de 3 secondes quel que soit votre serveur. Dès que plusieurs agents tournent en parallèle sous forte charge, ces exécutions longues bloquées en attente de réponse consomment aussi davantage de workers — notre article sur le mode queue avec Redis détaille comment n8n répartit la charge quand le volume d'exécutions simultanées augmente. Le pattern asynchrone règle le problème à la racine : la durée de l'agent cesse d'être contrainte par qui que ce soit d'autre que vous.

Pièges fréquents

• Le node Respond to Webhook n'est jamais atteint. Si l'agent plante avant ce node (erreur API, credential invalide), l'appelant reste bloqué jusqu'à son propre timeout sans aucune réponse. Placez l'accusé de réception avant l'agent, pas après, et ajoutez un Error Workflow pour marquer la tâche en échec en base si la suite du traitement échoue.
• L'appelant retente après un faux timeout perçu. Si votre accusé de réception met lui-même plus de quelques centaines de millisecondes à partir (file d'attente saturée, cold start), certains clients relancent la requête et déclenchent l'agent deux fois pour la même demande — le réflexe à adopter est décrit dans notre article sur l'idempotence des webhooks n8n.
• Le point de terminaison de statut exposé sans protection. Un jobId séquentiel ou devinable permet à n'importe qui de consulter les résultats des autres ; générez des identifiants non prévisibles (UUID v4) et appliquez les mêmes principes que dans notre guide pour sécuriser un webhook n8n exposé publiquement.

Pour aller plus loin

Ce pattern accusé de réception immédiat puis traitement asynchrone est exactement celui qui équipe le Pack Conformité & Audit (149 €) pour son bot de questionnaire guidé, où chaque échange peut mobiliser l'agent plusieurs secondes sans jamais faire attendre l'utilisateur en silence, ainsi que l'API de questions-réponses du Pack Assistant RAG (119 €). Si votre agent est encore en mode « When Last Node Finishes » et que vous voyez des timeouts apparaître dès que les réponses se complexifient, c'est le premier réglage à changer avant d'aller chercher plus loin.