n8n avancé : Webhook et conception de branches conditionnelles IF/Switch

Le bouton orange « Test Workflow » a été cliqué pour la dix-septième fois.

À chaque fois, il fallait appuyer manuellement pour déclencher l’exécution. Est-ce que ça ne pourrait pas fonctionner comme une vraie API — quelqu’un appelle, et le workflow part tout seul ? On découvre ensuite que n8n a une chose appelée Webhook : en gros, c’est une sonnette ; quelqu’un appuie, et le workflow se met en route.

Cet article parle de comment installer cette sonnette, et surtout de comment, une fois installée, orienter les visiteurs vers des « pièces » différentes selon qui frappe à la porte. Si vous maîtrisez déjà les nœuds de base de n8n mais que vos workflows restent dans un état « passif », en attente, ce texte devrait ouvrir de nouvelles pistes.

Au programme :

• Les paramètres du nœud Webhook qui font mal aux yeux, et comment les configurer
• IF et Switch : deux frères, et lequel choisir selon le cas
• Un cas complet de traitement de commandes, prêt à réutiliser
• Les pièges à éviter en production

1. Configuration approfondie du nœud Webhook

Une précision d’abord : Webhook et déclencheur planifié, ce n’est pas la même chose.

Le déclencheur planifié, c’est un réveil : il sonne à intervalles réguliers, qu’il se passe quelque chose dehors ou non. Le Webhook, c’est la sonnette : quelqu’un appuie, et seulement là ça réagit — c’est le modèle événementiel. L’avantage : pas besoin d’aller regarder la porte toutes les cinq minutes ; le livreur appuie, vous le savez. Les données officielles indiquent que les Webhooks peuvent réduire la charge de 90-95% réduction du polling — en clair, moins de ressources, moins de temps perdu.

1.1 Quelle méthode HTTP choisir

En ouvrant le nœud Webhook, le premier champ est HTTP Method. n8n prend en charge DELETE, GET, HEAD, PATCH, POST et PUT.

Le choix dépend de l’usage :

• POST : recevoir des données (formulaire, notification de nouvelle commande). C’est le cas le plus courant.
• GET : déclenchement simple (lien court : un clic lance le workflow).
• PUT/PATCH : mise à jour (par exemple statut de commande).

En pratique, on utilise surtout POST pour pouvoir envoyer un body.

1.2 Quatre modes de réponse

Le paramètre « Response Mode » définit comment n8n répond à l’appelant :

Attention : avec « Immediately », l’appelant reçoit 200 et part ; s’il y a une erreur plus loin, il ne le saura pas. Pour les tâches en arrière-plan, prévoir une notification d’erreur.

1.3 Paramètres de route façon REST

Le path peut être dynamique, par exemple orders/:orderId. Après les deux-points, le nom de variable est extrait automatiquement de l’URL.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Exemple : appel à /orders/12345, le workflow peut utiliser {{ $params.orderId }} et obtenir 12345. Plus propre que de tout passer en query string.

1.4 Limite de taille du payload

La taille maximale du payload Webhook est de 16MB payload maximal. Au-delà, erreur.

Si de gros fichiers sont nécessaires :

1. Modifier la variable d’environnement N8N_PAYLOAD_SIZE_MAX
2. Envoyer le fichier vers un stockage objet et ne passer qu’une URL au Webhook

En pratique, 16 Mo suffisent dans la plupart des cas. Pour de vrais gros fichiers, la deuxième option est plus fiable.

2. IF vs Switch : comment choisir le nœud de branche

Ces deux nœuds semblent proches : tous deux répartissent les données. Mal choisi, ça devient pénible — soit une cascade de IF en « spaghetti », soit un Switch surdimensionné pour deux sorties seulement.

2.1 Nœud IF : oui ou non

Le nœud IF n’a que deux sorties : true et false.

Comme à la porte : « C’est du frais ? » Oui → frigo ; non → devant la porte. Simple.

Types de conditions pris en charge : String, Number, Date & Time, Boolean, Array, Object. Exemples :

• String : contains, starts with, ends with, matches regex
• Number : is greater than, is less than
• Boolean : is true, is false
• Array : contains, length greater than

2.2 Nœud Switch : plusieurs chemins

Le nœud Switch peut avoir plusieurs sorties. Idéal pour « Vous êtes de quel service ? » — finance par ici, technique par là, ops ailleurs.

Deux modes :

• Rules : une condition par sortie, comme un formulaire. Intuitif pour débuter.
• Expression : expression JavaScript qui renvoie le numéro de sortie. Plus souple pour une logique complexe.

2.3 Lequel choisir ? Tableau récapitulatif

Astuce : si vous enchaînez IF après IF après IF… il est temps de passer à Switch.

2.4 Comparaisons par type de données

IF et Switch acceptent les mêmes familles :

• String : exists, is empty, contains, matches regex…
• Number : supérieur, inférieur, égal…
• Date & Time : ordre chronologique
• Boolean : vrai / faux
• Array : longueur, élément présent
• Object : exists, empty, not empty

Date & Time est pratique : par exemple vérifier si une commande a dépassé un délai en comparant directement les dates.

3. Cas pratique : traitement automatique du statut de commande

Scène réelle. Un ami tient une petite boutique en ligne : commandes, notifications et appels, tout à la main dans le back-office. « n8n peut faire ça », j’ai dit ; il était sceptique.

Deux semaines plus tard, l’entrepôt lui demandait : « Comment ça se fait qu’on n’en rate plus aucune ? »

3.1 Objectif

Besoin simple :

• Nouvelle commande (pending) → alerter l’entrepôt pour préparer
• Payée (paid) → e-mail de confirmation au client
• Expédiée (shipped) → mise à jour logistique
• Annulée (cancelled) → remboursement

Quatre statuts : Switch en quatre branches.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

3.2 Configuration Webhook

Nœud Webhook :

• HTTP Method : POST
• Path : orders/:orderId
• Response Mode : When Last Node Finishes (renvoyer le résultat du traitement)
• Authentication : Header Auth

Sécurité : Header Auth avec un header personnalisé X-Shop-Secret et une chaîne aléatoire. Seuls les systèmes qui connaissent ce secret peuvent appeler.

3.3 Logique Switch

Switch en mode Rules, quatre règles pour quatre statuts :

Règle 1 : {{ $json.status }} equals "pending" → sortie : pending
Règle 2 : {{ $json.status }} equals "paid" → sortie : paid
Règle 3 : {{ $json.status }} equals "shipped" → sortie : shipped
Règle 4 : {{ $json.status }} equals "cancelled" → sortie : cancelled

Fallback Output sur Extra Output : un statut inconnu (par ex. « unknown ») ne bloque pas le flux.

3.4 JSON du workflow complet

Import direct dans n8n :

{
  "name": "Order Processing",
  "nodes": [
    {
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "position": [250, 300],
      "parameters": {
        "httpMethod": "POST",
        "path": "orders/:orderId",
        "responseMode": "responseNode",
        "authentication": "headerAuth"
      }
    },
    {
      "name": "Switch",
      "type": "n8n-nodes-base.switch",
      "position": [500, 300],
      "parameters": {
        "mode": "rules",
        "rules": [
          { "output": "pending", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "pending" } },
          { "output": "paid", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "paid" } },
          { "output": "shipped", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "shipped" } },
          { "output": "cancelled", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "cancelled" } }
        ],
        "fallbackOutput": "extra"
      }
    },
    {
      "name": "Notify Warehouse",
      "type": "n8n-nodes-base.slack",
      "position": [750, 200]
    },
    {
      "name": "Send Confirmation",
      "type": "n8n-nodes-base.emailSend",
      "position": [750, 300]
    },
    {
      "name": "Update Tracking",
      "type": "n8n-nodes-base.httpRequest",
      "position": [750, 400]
    },
    {
      "name": "Process Refund",
      "type": "n8n-nodes-base.stripe",
      "position": [750, 500]
    }
  ],
  "connections": {
    "Webhook": { "main": [[{ "node": "Switch", "type": "main", "index": 0 }]] },
    "Switch": {
      "main": [
        [{ "node": "Notify Warehouse", "type": "main", "index": 0 }],
        [{ "node": "Send Confirmation", "type": "main", "index": 0 }],
        [{ "node": "Update Tracking", "type": "main", "index": 0 }],
        [{ "node": "Process Refund", "type": "main", "index": 0 }]
      ]
    }
  }
}

Coller ce JSON dans n8n pour importer. Remplacer la configuration Slack, Email, HTTP Request et Stripe par la vôtre.

3.5 Tests et mise en production

n8n expose deux URL :

• Test URL : développement ; exécution seulement lors des tests manuels
• Production URL : active après activation du workflow ; service réel

Déroulé type :

1. Appeler la Test URL, vérifier l’ordre des nœuds et le flux de données
2. Si tout est bon, activer le switch « Active » en haut à droite
3. Donner la Production URL à la plateforme e-commerce (ou passer par Zapier)

Test avec curl :

curl -X POST https://your-n8n-instance.com/webhook/orders/12345 \
  -H "Content-Type: application/json" \
  -H "X-Shop-Secret: your-secret-key" \
  -d '{"status": "paid", "customer_email": "[email protected]"}'

Réponse 200 et logs d’exécution : c’est bon.

4. Production : pièges à éviter

Un workflow qui tourne en test n’est pas encore prêt pour la prod. Quelques erreurs déjà vécues.

4.1 Ne pas négliger l’authentification

Header Auth, c’est la base. Si l’IP de l’appelant est fixe, ajouter une liste blanche IP renforce la sécurité.

Dans les options avancées du nœud Webhook, paramètre « IP Whitelist » : liste des IP autorisées. Les autres sont refusées avant même le déclenchement du workflow.

JWT Auth est plus robuste mais plus lourd à configurer. Pour un système maîtrisé en interne, Header Auth + IP Whitelist suffisent souvent.

4.2 Les erreurs doivent remonter

En cas d’échec du Webhook, l’appelant peut ne voir qu’un 500 sans détail côté n8n.

Ajouter un nœud Error Trigger qui envoie une notification Slack en cas d’erreur :

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Error Trigger → Slack (message d'erreur + ID d'exécution)

Un problème la nuit apparaît sur le téléphone, sans attendre les plaintes du lendemain matin.

4.3 Astuce performance

Si le workflow enchaîne beaucoup d’API externes (stock, e-mail, paiement), la réponse peut être lente ; l’appelant peut time-out.

Dans ce cas, mode Immediately : 200 tout de suite, traitement en arrière-plan. Inconvénient : l’appelant n’a pas le résultat final sans autre canal.

Adapté : tâches batch, notifications non critiques. Peu adapté : confirmation de paiement, requêtes temps réel.

4.4 Déboguer avec les logs Execution

n8n enregistre chaque exécution. Menu « Executions » à gauche : entrées/sorties, durée par nœud, erreurs.

Détail : par défaut environ 1000 exécutions conservées. Fort volume : variable EXECUTIONS_DATA_MAX_AGE ou export périodique.

Les logs Test URL et Production URL sont séparés — ne pas les mélanger.

Synthèse

Le Webhook, c’est la sonnette de n8n : quelqu’un appuie, le workflow travaille. À la configuration, soigner HTTP Method et Response Mode ; utiliser les paramètres de route quand c’est possible, plutôt que d’alourdir la query string.

IF ou Switch ? Deux branches → IF ; trois ou plus → Switch. Éviter les IF imbriqués.

Le workflow commandes est réutilisable tel quel ; adapter Slack, Email et Stripe. Tester avec la Test URL avant d’activer.

Enfin, sécurité : Header Auth au minimum, IP Whitelist si possible, et notification d’erreur — sinon une panne peut passer inaperçue.

Des questions en commentaire, ou cherchez dans la communauté n8n : il y a beaucoup d’expérience partagée là-bas.