Recevez des événements en temps réel avec les webhooks

Choisissez entre polling et événement selon votre besoin

Votre pipeline traite déjà les tickets qui arrivent via un formulaire web. Mais il y a un autre canal : l'outil de monitoring qui surveille l'infrastructure de l’éditeur SaaS 24h/24. Quand un service tombe, l'outil le détecte en quelques secondes. Le problème : votre workflow n'en sait rien, sauf s'il va vérifier régulièrement.

Il existe deux façons de déclencher un workflow automatiquement :

1. Le polling : votre workflow interroge régulièrement une source pour détecter les nouveautés (toutes les 5 minutes, toutes les heures). Simple à mettre en place, mais imprécis : l'alerte peut attendre jusqu'au prochain tour de vérification.

2. L'événement (webhook) : c'est la source qui vous prévient, au moment exact où quelque chose se passe. Votre workflow se déclenche en temps réel, sans délais.

Pour le monitoring d'infrastructure, le polling est insuffisant : si un incident critique arrive à 18h le soir, on ne veut pas qu'un ticket urgent attende dans la file. Le webhook est la bonne réponse.

Décryptez l'anatomie d'un webhook

Un webhook, c'est une adresse URL que vous communiquez à un outil externe. Quand un événement se produit de son côté, il envoie une requête HTTP à cette adresse et votre workflow s'exécute.

Concrètement, voici ce qui se passe :

1. Vous créez une adresse d'écoute dans n8n : le nœud Webhook génère une URL unique.

2. Vous la communiquez à l'outil externe (ici, l'outil de monitoring) dans les paramètres de notification.

3. Quand un incident est détecté, l'outil appelle cette URL avec les données de l'incident dans le corps de la requête (le payload).

4. n8n reçoit l'appel, exécute le workflow, et renvoie une confirmation (200 OK) pour indiquer que tout s'est bien passé.

C'est comme donner votre numéro de téléphone à un collègue : vous n'appelez pas toutes les heures pour savoir s'il a du nouveau. Vous attendez qu'il vous appelle.

Configurez et testez un webhook dans n8n

Dans n8n, le nœud webhook génère deux adresses distinctes :

1. Test URL : active uniquement quand vous cliquez sur Listen for test event. Parfaite pour valider le payload reçu avant de mettre en production.

2. Production URL : active dès que le workflow est activé (toggle ON). C'est cette adresse que vous communiquez à l'outil externe.

Exemple de payload JSON que vous pouvez simuler avecBruno(un outil pour envoyer des requêtes HTTP), ou tout autre outil similaire, tel que Postman par exemple :

{
  "incident_id": "INC-2024-001",
  "severity": "critical",
  "service": "api-gateway",
  "message": "Latency spike detected",
  "triggered_at": "2024-06-10T03:12:00Z"
}

n8n affiche les données reçues dans l'inspecteur d'exécution. Vérifiez la structure ; vous pouvez ensuite brancher directement votre étape de normalisation sur ce payload.

Exposez n8n en local avec un tunnel

Si vous développez avec n8n sur votre ordinateur, votre webhook est inaccessible depuis l'extérieur. Un outil de monitoring hébergé sur un serveur distant ne peut pas appeler une URL qui pointe sur votre machine locale.

La solution pendant le développement : utiliser un tunnel comme ngrok, qui crée une passerelle temporaire entre internet et votre machine. Vous obtenez une URL publique que vous communiquez à l'outil externe pour vos tests.

Sécurisez votre webhook contre les appels non autorisés

Votre adresse d'écoute est publique. N'importe qui qui la connaît peut l'appeler ; et déclencher votre workflow avec n'importe quel contenu.

Pour vous protéger, n8n propose deux mécanismes :

1. Header Auth : vous définissez un en-tête HTTP secret (ex.X-Webhook-Secret: votre_valeur). L'outil externe doit l'inclure dans chaque appel. Si l'en-tête est absent ou incorrect, le webhook rejette la requête.

2. Basic Auth : similaire, mais avec un identifiant et un mot de passe encodés dans la requête.

Dans la plupart des outils de monitoring, la configuration de cet en-tête se fait dans les paramètres de notification webhook. Consultez la documentation de votre outil.

À vous de jouer !

Consigne

Revenons à notre projet de workflow pour AgroTech !

Le pipeline que vous avez construit traite les relevés agricoles arrivant de capteurs Sol LoRaWAN, de la Station Météo Web et de la Sonde d'Humidité API.

Un quatrième canal s'ajoute : les alertes automatiques du système de supervision IoT (panne batterie, perte de signal, alerte gel automatisée). Votre mission : ouvrir une nouvelle porte d'entrée dans le pipeline via un Webhook.

Créez un nœud Webhook dans votre workflow. Simulez l'arrivée d'une alerte d'incident technique (avec Postman, cURL ou un outil similaire) et vérifiez que le relevé/ticket d'incident généré s'intègre correctement dans le pipeline normalisé.

• out_source  : "monitoring_iot"

• out_subject  : texte de l'alerte (ex. "Alerte Gel - Sonde Parcelle Nord")

• out_message  : détail de l'incident (ex. "Chute de température sous -2°C détectée")

• out_priority  : déduit de severity (critical → high, warning → medium, autre → low)

• out_device_email  : null (pas d'email client/exploitant dans une alerte technique système)

• out_created_at  : valeur de  triggered_at  (ou date actuelle ISO si absent)

Contraintes :

• Si le champ severity est absent du payload du webhook,  out_priority  doit valoir "medium" par défaut ;

• Le workflow ne doit pas s'arrêter si l'email ou la date sont absents.

Corrigé

Voici un exemple de ce que vous pouviez faire pour y arriver :

Capture d’écran d’un workflow n8n intitulé 'Webhook Monitoring AgroTech'.

• Structure du workflow (sur fond marron) :

  • Nœud 1 : 'Webhook Alerte IoT' (déclencheur, icône verte).

  • Nœud 2 : 'Normalisation Alerte IoT - Edit Fields' (modification des champs).

  • Nœud 3 : 'Normalisation Alerte IoT - Code JS' (traitement via JavaScript).

  • Nœud 4 : 'Respond to Webhook' (réponse au webhook).

• Description textuelle (à gauche) :

  • Webhook :POST /webhook/agri-monitoring-alert(mode test :/webhook-test/agri-monitoring-alert).

  • Normalisation : Deux variantes side-by-side (Edit Fields et Code JS).

  • Réponse : Répondre avec les champsout_*normalisés via 'Respond to Webhook'.

  • Commande de test : Exemple decurlavec un payload JSON pour simuler une alerte.

• Logs (en bas) : Exécution réussie en 36.558s pour tous les nœuds.

• Bouton 'Execute workflow' en orange.

Capture d’écran des paramètres du nœud 'Normalisation Alerte IoT - Edit Fields' dans n8n :

• Input (à gauche) : Données brutes du webhook avec :

  • Headers :x-forwarded-for,x-forwarded-proto,host: n8n.aura-al.fr, etc.

  • Body :

    • alert_title: Alerte Gel - Sonde Parcelle Nord

    • triggered_at: 2026-03-15T05:00:00Z

    • incident_details: Chute de température sous -2°C détectée à 05:00

    • severity: critical

    • webhookUrl: <https://n8n.aura-al.fr/webhook-test/agri-monitoring-alert>.

• Paramètres (au centre) :

  • Mode : Manual Mapping.

  • Fields to Set :

    • out_source:monitoring_iot(valeur statique).

    • out_subject: Expression JavaScript pour extraire le titre de l’alerte.

    • out_message: Expression pour extraire les détails de l’incident.

    • out_priority: Logique conditionnelle pour mapperseverity(critical/high→high,warning/medium→medium, etc.).

    • out_device_email: Vide (null).

• Output (à droite) : Données normalisées avec les champsout_*(ex:out_source: monitoring_iot,out_priority: high).

• Bouton 'Execute step' en orange en haut à droite.

Capture d’écran du nœud 'Respond to Webhook' dans un workflow n8n :

• Input (à gauche) : Données provenant du nœud 'Normalisation Alerte IoT - Edit Fields' avec :

  • out_source: monitoring_iot

  • out_subject: Alerte Gel - Sonde Parcelle Nord

  • out_message: Chute de température sous -2°C détectée à 05:00

  • out_priority: high

  • out_device_email: null

  • out_created_at: 2026-03-15T05:00:00.000Z.

• Paramètres (au centre) :

  • Respond With : 'First Incoming Item'.

  • Options : Aucune propriété ajoutée.

  • Avertissement en orange : *'Verify that the "Webhook" node's "Respond" parameter is set to "Using Respond to Webhook Node". More details'.

• Output (à droite) : Même structure que l’input, avec 1 item exécuté avec succès.

• Bouton 'Execute step' en orange en haut à droite.

En résumé

• Il existe deux façons de déclencher un workflow : le polling (vous interrogez la source à intervalles réguliers) et l'événement webhook (la source vous prévient en temps réel). Privilégiez le webhook quand la réactivité est critique.

• Un webhook est une URL d'écoute que vous communiquez à l'outil externe. Quand un événement se produit, il appelle cette URL avec les données de l'événement.

• n8n génère deux adresses : une pour les tests (active à la demande) et une pour la production (active quand le workflow est activé).

• En développement local, utilisez un tunnel (ngrok) ou simulez les appels avec Bruno ou Postman ; ne donnez jamais l'URL temporaire à un outil de production.

• Sécurisez toujours votre webhook avec un en-tête secret pour empêcher les appels non autorisés.

Dans la deuxième partie de ce cours, vous allez rendre ce pipeline fiable en production. Mais avant, passez le quiz pour valider vos acquis, bonne chance !