Le webhook fonctionne en test mais pas en production : la checklist

Un webhook n8n qui se déclenche de manière fiable en test mais ne reçoit plus de requêtes en production a presque toujours l'une de ces trois causes : le workflow n'a pas été activé, si bien que l'URL de production n'a jamais été enregistrée ; la variable d'environnement WEBHOOK_URL est mal configurée ou pas du tout définie derrière un reverse proxy ; ou il y a une confusion entre l'URL de test et l'URL de production, que n8n génère séparément pour chaque nœud webhook. La recherche d'erreur suit logiquement un ordre fixe : vérifier d'abord laquelle des deux URL est enregistrée dans l'application externe, puis le statut d'activation du workflow, puis la configuration du proxy et des variables d'environnement. Situation en juillet 2026.

Pourquoi l'URL de test et l'URL de production sont-elles différentes ?

n8n crée deux URL distinctes pour chaque nœud webhook, qui se comportent différemment sur le plan technique. L'URL de test ne devient active que lorsque vous cliquez sur « Listen for test event » dans l'éditeur, et elle reste prête à recevoir pendant seulement 120 secondes selon la documentation n8n, les données entrantes apparaissant directement dans l'éditeur. L'URL de production, elle, ne s'enregistre que lorsque le workflow est publié et activé. Elle fonctionne ensuite en permanence, mais n'affiche plus les données entrantes dans l'éditeur, seulement dans l'onglet Executions. Quiconque connecte par erreur une application externe telle qu'un CRM, un outil de formulaire ou une plateforme de paiement à l'URL de test ne reçoit plus de réponses après 120 secondes au plus tard, alors que tout fonctionnait en test.

Le workflow est-il réellement activé ?

La raison la plus fréquente d'un webhook de production silencieux est un workflow qui n'est pas activé. L'URL de production ne s'enregistre que lorsque vous enregistrez le workflow et le publiez via le bouton d'activation dans l'éditeur ; ce n'est qu'à partir de ce moment que n8n accepte les requêtes à cette adresse. Si le workflow est modifié plus tard, désactivé pour un test ou éteint par accident, l'URL de production disparaît sans avertissement, sans message d'erreur pour l'application externe ; l'appel se perd simplement. Vérifiez donc d'abord le statut d'activation en haut à droite de l'éditeur de workflow, avant de chercher plus loin dans les paramètres de proxy ou de réseau.

Un conflit de chemin ou de méthode bloque-t-il la requête ?

Une deuxième raison, moins souvent remarquée, se trouve dans l'attribution du chemin et de la méthode. Selon la documentation, n8n n'autorise l'enregistrement que d'un seul webhook par combinaison de chemin et de méthode HTTP ; si deux workflows actifs sont configurés sur le même chemin, celui enregistré en premier bloque le second. Une méthode HTTP incorrecte entraîne également une erreur : par défaut, un nœud webhook n'accepte que GET ou POST, pas les deux en même temps, sauf si vous activez l'option « Allow Multiple HTTP Methods » dans les paramètres du nœud. Si le service externe change sa méthode de requête, la connexion s'interrompt sans message d'erreur identifiable dans le workflow.

WEBHOOK_URL est-elle correctement définie derrière le reverse proxy ?

Lorsque n8n est autohébergé et fonctionne derrière un reverse proxy tel que Nginx, Traefik ou Caddy, une WEBHOOK_URL mal définie est la cause technique la plus fréquente. n8n construit normalement l'adresse du webhook automatiquement à partir des variables N8N_PROTOCOL, N8N_HOST et N8N_PORT ; selon la documentation n8n, cela ne fonctionne pas derrière un proxy, car n8n s'exécute en interne sur le port 5678, tandis que le proxy expose l'application en externe sur le port 443. Vous devez donc définir WEBHOOK_URL manuellement, définir en plus la variable N8N_PROXY_HOPS sur le nombre de proxys en amont, et transmettre sur le dernier proxy les en-têtes X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Proto. Si N8N_PROXY_HOPS est absent, les règles de liste blanche d'IP pour les webhooks peuvent également échouer, car n8n ne détecte pas correctement l'IP réelle de l'expéditeur. Pour les entreprises qui ne veulent pas maintenir cette configuration elles-mêmes en continu, NordFlux prend en charge la configuration du serveur et du proxy dans le cadre d'un projet à prix fixe au sein de son offre automatisation n8n.

Dans quel ordre faut-il vérifier les causes ?

Avant d'entrer dans le détail, une brève comparaison des quatre causes les plus probables dans un ordre logique est utile.

• Type d'URL : L'URL réellement enregistrée dans l'application externe est-elle bien l'URL de production, et non l'URL de test ?
• Activation : Le workflow est-il activé dans l'éditeur et a-t-il été à nouveau enregistré après la dernière modification ?
• Conflit de chemin : Aucun autre workflow actif n'utilise-t-il le même chemin et la même méthode HTTP ?
• WEBHOOK_URL : La variable d'environnement est-elle définie manuellement en cas d'exécution derrière un reverse proxy, et correspond-elle au domaine public ?

C'est seulement lorsque ces quatre points sont confirmés et que le webhook ne répond toujours pas qu'il vaut la peine de chercher du côté des règles de pare-feu, des entrées DNS ou de l'hébergeur.

Questions fréquentes sur les webhooks n8n en production

Pourquoi le webhook cesse-t-il de répondre aux requêtes après environ deux minutes ?

Probablement parce que l'URL de test est encore utilisée : elle ne reste prête à recevoir que 120 secondes après avoir cliqué sur « Listen for test event ». Pour un fonctionnement permanent, il vous faut l'URL de production, qui n'est enregistrée qu'après l'activation du workflow. Remplacez l'URL enregistrée et vérifiez le statut d'activation dans l'éditeur.

Dois-je enregistrer le workflow avant que l'URL de production ne fonctionne ?

Oui, l'URL de production ne s'enregistre que lorsque le workflow a été enregistré et activé, c'est-à-dire publié. Sans cette étape, n8n n'accepte aucune requête à cette adresse, même si le workflow fonctionnait déjà sans erreur en test. Après chaque modification du contenu du nœud webhook, vous devez à nouveau enregistrer le workflow et vérifier l'activation.

Deux workflows peuvent-ils utiliser le même chemin de webhook ?

Non, n8n n'enregistre qu'un seul webhook par combinaison de chemin et de méthode HTTP. Si un deuxième workflow actif est configuré sur le même chemin et la même méthode, le workflow enregistré en premier bloque le second. Dans ce cas, attribuez des chemins uniques ou désactivez le workflow qui n'est plus nécessaire.

Que faire si n8n fonctionne derrière Nginx ou Traefik et que l'URL de webhook affichée est incorrecte ?

Définissez manuellement la variable d'environnement WEBHOOK_URL sur le domaine accessible publiquement, car sinon n8n construit l'adresse en interne à partir du protocole, de l'hôte et du port, en utilisant le port interne 5678 au lieu de l'adresse publique. Définissez en complément N8N_PROXY_HOPS sur le nombre de proxys en amont et assurez-vous que le dernier proxy transmet les en-têtes X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Proto. Après la modification, n8n doit être redémarré.