Connecter PagerDuty à n8n : recevoir les incidents en temps réel et prioriser l'astreinte avec l'IA

Une astreinte réveillée à 3 h du matin pour une alerte qui se résorbe d'elle-même en deux minutes coûte cher — pas en argent, mais en attention : la fois suivante, la même personne met un peu plus de temps à réagir à une vraie panne. PagerDuty route déjà les incidents vers la bonne personne selon un calendrier d'astreinte, mais il ne sait pas distinguer un pic de latence bénin d'une panne qui va s'aggraver — cette lecture reste humaine, et donc lente, tant qu'elle n'est pas outillée. Brancher n8n sur PagerDuty permet d'intercaler un tri automatisé entre la détection et la notification, sans toucher à la politique d'escalade elle-même.

Pourquoi un tri automatisé avant l'escalade

Une politique d'escalade PagerDuty répond à la question « qui prévenir, et dans quel délai si personne n'accuse réception ? » — pas à la question « est-ce que ça vaut la peine de prévenir maintenant ? ». Un service de monitoring mal calibré qui déclenche dix incidents par nuit sur le même seuil flou finit par désensibiliser l'équipe, exactement comme n'importe quel système d'alerte trop bavard. La bonne réponse n'est pas de durcir aveuglément les seuils au risque de rater une vraie panne, mais d'ajouter une étape de lecture contextuelle avant la notification — ce que ni PagerDuty ni l'outil de monitoring ne fait nativement.

Le node natif PagerDuty : credential et opérations

n8n embarque un node PagerDuty avec un credential API Key, généré depuis Intégrations → API Access Keys dans le tableau de bord PagerDuty (option lecture seule disponible si le workflow n'a besoin que de consulter). Ce node couvre :

• Incident — créer, récupérer, récupérer plusieurs, mettre à jour (changer le statut, réassigner, changer la priorité)
• Note — ajouter un commentaire à un incident existant, récupérer les notes
• Log Entry — consulter l'historique d'un incident (qui a acquitté, à quelle heure)
• User — récupérer les utilisateurs et leurs plannings

Ce node suffit pour toute action de gestion sur un incident déjà ouvert : ajouter une note générée par IA avec le contexte utile, réassigner selon la charge de l'astreinte, ou clore automatiquement un faux positif identifié. Il ne sert en revanche à rien pour recevoir un événement — PagerDuty ne propose pas de node Trigger officiel, il faut construire la réception soi-même.

Recevoir les incidents en temps réel avec les webhooks v3

Les abonnements webhooks v3 (Intégrations → Webhooks, au niveau service ou compte) livrent chaque changement d'état en temps réel vers une URL n8n : incident.triggered, incident.acknowledged, incident.resolved, incident.escalated, incident.priority_updated, incident.responder.added, entre autres types d'événements filtrables à la création de l'abonnement. Un node Webhook n8n reçoit ces POST — pour l'exposition HTTPS et les bonnes pratiques générales, notre guide de sécurisation des webhooks n8n couvre la base commune à tous les webhooks entrants avant d'aller plus loin ici.

Vérifier la signature avant de traiter quoi que ce soit

Chaque requête porte un en-tête x-pagerduty-signature, au format v1=<hash> — un HMAC-SHA256 calculé sur le corps brut de la requête avec le secret partagé, affiché une seule fois à la création de l'abonnement webhook. Un node Code recalcule ce HMAC côté n8n et compare la valeur reçue à celle calculée, avant même de lire le contenu de l'incident. Sans cette étape, n'importe qui connaissant l'URL de votre webhook — devinée ou fuitée — pourrait injecter de faux incidents dans votre pipeline de tri.

Trier avec l'IA avant de réveiller quelqu'un

Une fois la signature vérifiée, un node LLM (un modèle léger de type gpt-4o-mini ou Claude Haiku suffit largement) lit le titre de l'incident, la description, le service concerné et — si le node PagerDuty est appelé en complément — l'historique récent des incidents sur ce même service, pour classer l'alerte en catégories utiles : urgence réelle (escalade immédiate, aucun filtrage), probable faux positif connu (note ajoutée à l'incident via le node PagerDuty, escalade repoussée d'un délai court le temps qu'un humain confirme en horaires ouvrés) ou dégradation à surveiller (digest groupé plutôt qu'astreinte réveillée). Ce pattern de classification avant notification reprend celui déjà détaillé pour le tri des alertes Sentry avec l'IA : la logique de fond — ne pas laisser un LLM décider seul d'une action irréversible, seulement filtrer et enrichir — s'applique à l'identique ici, avec un enjeu plus sensible puisqu'une astreinte réveillée à tort a un coût humain direct.

Déclencher un incident depuis un système tiers via l'Events API v2

Dans l'autre sens, n8n peut lui-même jouer le rôle de système de supervision et déclencher un incident PagerDuty — utile quand un de vos propres workflows détecte une anomalie que rien d'autre ne surveille (un job de synchronisation qui échoue silencieusement, un seuil métier dépassé). L'Events API v2 (POST https://events.pagerduty.com/v2/enqueue, appelé via un node HTTP Request) prend une routing_key propre au service concerné, un event_action (trigger, acknowledge ou resolve) et un payload avec summary, source et severity. Le champ dedup_key mérite une attention particulière : des événements successifs portant la même valeur se regroupent dans le même incident plutôt que d'en ouvrir un nouveau à chaque exécution du workflow — un identifiant stable dérivé de la nature de l'anomalie (pas de l'horodatage) évite de spammer l'astreinte d'un incident par minute pour le même problème.

Journaliser chaque événement

Une table Supabase — identifiant d'incident PagerDuty, catégorie attribuée par l'IA, action prise, horodatage — permet de mesurer après coup si le tri automatisé rate des urgences ou, à l'inverse, sur-filtre. Notre guide de connexion n8n ↔ Supabase couvre la mise en place de ce type de table. Comme PagerDuty retente la livraison d'un webhook si votre endpoint ne répond pas assez vite, une contrainte d'unicité sur l'identifiant de l'événement reste nécessaire pour éviter un double traitement — le même principe d'idempotence des webhooks déjà utile pour Stripe ou GoCardless s'applique ici.

Ce que dit la recherche sur la fatigue d'alerte

Le problème que ce pipeline cherche à résoudre est documenté au-delà de l'intuition. Une étude de Gelman, Taoufiq, Vörös et Berlin (2023), « That Escalated Quickly: An ML Framework for Alert Prioritization » (voir sur Google Scholar), a mesuré l'effet d'un système de priorisation par apprentissage automatique déployé sur un centre d'opérations réel : le temps de réponse aux incidents réellement exploitables a baissé de 22,9 %, et 54 % des faux positifs ont été supprimés du flux sans changement majeur des processus existants — la preuve qu'une couche de tri automatisée en amont d'un système d'alerte déjà en place, plutôt que son remplacement, produit un gain mesurable.

Pièges fréquents

• Ne pas vérifier la signature du webhook. Sans ce contrôle, l'URL du endpoint devient à elle seule la seule protection du pipeline.
• Confondre le node PagerDuty et l'Events API v2. Le premier gère des incidents déjà ouverts avec un credential de compte ; la seconde en crée depuis l'extérieur avec une simple routing_key — les deux ne se substituent pas l'un à l'autre.
• Un dedup_key dérivé de l'horodatage. Cela génère un nouvel incident à chaque exécution du workflow au lieu de regrouper les occurrences du même problème.
• Laisser l'IA acquitter ou résoudre un incident sans garde-fou. Une classification erronée qui referme un vrai incident est plus coûteuse qu'une astreinte réveillée à tort — réserver l'action automatique aux catégories à très faible risque, avec un Error Workflow n8n en filet de sécurité, et tester d'abord en local avec notre guide de test des webhooks n8n.

En résumé

PagerDuty décide qui prévenir ; il ne décide pas si ça vaut la peine de le faire maintenant. En interposant n8n entre les deux — vérification de signature, classification IA, journalisation — chaque réveil d'astreinte correspond à une décision qui a été relue, pas seulement déclenchée par un seuil brut. Si votre priorité immédiate est justement de tracer ce type de décision opérationnelle avec un historique exploitable, le Pack Conformité & Audit (149 €) fournit déjà le schéma Supabase et les workflows de journalisation réutilisables pour cette partie. Le Pack Inbox IA (79 €) applique la même logique de tri par IA côté boîte mail, et le Bundle FlowKit Complet (269 € au lieu de 347 € pris séparément) réunit les trois packs pour qui veut couvrir l'ensemble de la chaîne d'alerte.