Trier automatiquement les alertes Sentry avec l’IA dans n8n

Une équipe qui fait tourner plusieurs services en production reçoit vite des dizaines, parfois des centaines, d’alertes Sentry par jour : exceptions ponctuelles sans impact réel, régressions mineures sur un navigateur marginal, et — noyée au milieu — l’erreur qui signale que le paiement est cassé pour tout le monde depuis dix minutes. La littérature sur la fatigue d’alerte est sans appel sur ce mécanisme : une étude de Tariq et al. publiée en 2025 dans ACM Computing Surveys (« Alert Fatigue in Security Operations Centres », voir sur Google Scholar) montre que l’accumulation d’alertes à faible valeur informative désensibilise les opérateurs et retarde la détection des incidents réels — un mécanisme documenté aussi bien dans les salles de contrôle industrielles que dans les centres de sécurité opérationnelle. Un pipeline n8n qui trie les alertes Sentry avant qu’elles n’atteignent un humain s’attaque directement à ce problème.

Pourquoi Sentry seul ne suffit pas

Sentry regroupe déjà les événements par empreinte d’erreur et propose des règles d’alerte basées sur des seuils (nombre d’événements, taux, nouveaux utilisateurs affectés). Mais ces règles ne savent pas répondre à la question qui compte vraiment pour un humain qui reçoit la notification : est-ce que ça mérite d’interrompre ce que je fais maintenant ? Une exception NullPointerException sur un endpoint interne rarement utilisé et un timeout sur le service de paiement déclenchent le même type de notification Slack, avec la même urgence apparente. Le tri reste manuel, et c’est précisément ce que l’IA peut automatiser sans remplacer la décision finale.

Vue d’ensemble du pipeline

Le montage tient en cinq étapes :

1. Réception : un node Webhook reçoit le payload envoyé par une règle d’alerte Sentry configurée avec l’action « Send a notification via webhook » (voir la documentation officielle des webhooks Sentry).
2. Déduplication : avant tout appel IA, un lookup vérifie si la signature de l’erreur (titre + culprit + environnement) a déjà été traitée récemment.
3. Classification IA : un LLM évalue la gravité réelle, le service concerné et un résumé actionnable.
4. Routage : selon le score, l’alerte part vers un canal Slack dédié aux urgences, un canal de suivi normal, ou n’est simplement journalisée.
5. Escalade humaine : les cas critiques déclenchent une notification avec bouton d’accusé de réception, sur le modèle décrit dans notre guide sur l’approbation humaine avec Wait et Slack.

Ce découpage reprend directement la logique de tri/priorisation/digest du Pack Inbox IA (79 €), appliquée ici à un flux d’erreurs de production plutôt qu’à une boîte mail.

Étape 1 : recevoir les alertes sans polling

Dans Sentry, sur le projet concerné, créez une règle d’alerte (Alerts → Create Alert Rule) avec la condition souhaitée (« An issue is first seen », « The issue changes state to escalating », ou un seuil d’événements), puis ajoutez l’action Send a notification via an integration → Webhook en pointant vers l’URL du node Webhook n8n. Chaque déclenchement pousse un JSON contenant l’ID de l’issue, son titre, son niveau, le culprit (fonction ou fichier en cause) et les tags d’environnement — pas besoin d’interroger l’API Sentry à intervalles réguliers.

Pour des besoins d’inspection ponctuelle (lister les issues ouvertes, mettre à jour un statut), le node Sentry.io natif de n8n complète bien le webhook, mais pour du triage en temps réel, le webhook reste le point d’entrée le plus simple et le moins coûteux en requêtes.

Étape 2 : dédoublonner avant d’appeler l’IA

Une même erreur en production peut générer des dizaines d’événements en quelques minutes. Classer chacun d’eux au LLM serait à la fois coûteux et inutile : un node Data Table (voir notre guide n8n Data Tables) stocke une empreinte simple — hash du titre et du culprit — avec un horodatage. Un node IF vérifie si cette empreinte existe déjà dans la dernière heure : si oui, le workflow incrémente un compteur d’occurrences et s’arrête là ; sinon, il poursuit vers la classification et enregistre la nouvelle empreinte. Cette logique reprend les principes détaillés dans notre article sur l’idempotence des webhooks, appliqués ici à des signatures d’erreur plutôt qu’à des ID de transaction.

Étape 3 : classifier avec un output structuré

Un node AI Agent (ou Basic LLM Chain) reçoit le titre, le culprit, l’environnement et les premières lignes de stacktrace, avec un prompt qui demande une sortie structurée sur ce modèle :

{
  "gravite": "critique | elevee | moderee | faible",
  "service_probable": "paiement | auth | api-publique | interne | inconnu",
  "resume_actionnable": "une phrase expliquant ce qui casse et pour qui",
  "justification": "pourquoi ce niveau de gravité"
}

Comme pour tout appel LLM en production, verrouillez ce format avec un Structured Output Parser : un JSON malformé ou un champ hors énumération doit être rattrapé automatiquement, pas planter le workflow de triage lui-même. Un modèle économique (gpt-4o-mini ou équivalent) suffit largement pour cette tâche de classification courte — réservez un modèle plus coûteux à un résumé de stacktrace plus poussé sur les seuls cas classés critiques.

Écrire un prompt qui distingue vraiment les niveaux

La qualité du tri dépend presque entièrement d’exemples concrets par niveau dans le prompt, pas de la sophistication du modèle. Un barème explicite (« critique = paiement, authentification ou API publique cassée pour tous les utilisateurs » vs « faible = erreur cosmétique ou cas limite sur un navigateur marginal ») réduit nettement les faux positifs. Ce principe est le même que celui détaillé dans notre guide sur le scoring des tickets support : un champ de justification dans la sortie rend chaque décision auditable, et une erreur de classification devient visible immédiatement plutôt que de rester une boîte noire.

Étape 4 : router selon la gravité

Un node Switch dirige ensuite l’alerte enrichie :

Gravité	Destination	Comportement
Critique	Canal Slack #incidents + escalade	Notification immédiate, bouton d’accusé de réception (voir Wait + Slack)
Élevée	Canal Slack #alertes-prod	Notification standard, sans réveil
Modérée / Faible	Journalisation seule	Ligne ajoutée à une table Supabase, visible dans un digest quotidien

Le digest quotidien pour les alertes modérées et faibles reprend la même mécanique que le digest quotidien d’emails du Pack Inbox IA : un résumé groupé plutôt qu’une notification par occurrence, pour que le bruit de fond reste consultable sans interrompre personne.

Étape 5 : garder une trace de tout

Chaque alerte traitée — critique ou non — mérite une ligne dans une table de journalisation (issue, gravité attribuée, service, horodatage, lien vers l’issue Sentry). Cette piste sert à deux choses : recalibrer le prompt quand une catégorie génère trop de faux positifs, et servir de base à un post-mortem si une alerte critique a été mal classée. Les équipes qui veulent une piste plus formelle, avec conservation longue durée et rapport de synthèse automatisé, retrouveront la même logique dans le Pack Conformité & Audit (149 €), pensé au départ pour des besoins réglementaires mais directement transposable à un journal d’incidents techniques.

Suivre le coût et couvrir les pannes

Un pipeline qui tourne sur chaque nouvelle signature d’erreur, potentiellement des dizaines de fois par jour sur une instance active, doit intégrer dès le départ le suivi de son propre coût — voir notre guide sur le suivi du coût des appels IA. Et comme toute automatisation qui protège la production, ce workflow a lui-même besoin d’un Error Workflow : si le node de classification échoue (timeout API, quota dépassé), l’alerte doit basculer vers une notification Slack brute plutôt que disparaître silencieusement — le pire résultat possible pour un pipeline censé attraper les urgences.

Pour aller plus loin

Ce pipeline ne remplace ni Sentry ni la personne d’astreinte : il ajoute une couche de jugement entre le volume brut d’alertes et l’attention humaine, exactement le rôle que joue déjà le tri IA d’une boîte mail dans le Pack Inbox IA. Commencez petit — une seule règle d’alerte, deux niveaux de gravité — avant d’étendre le tri à l’ensemble des projets Sentry d’une organisation. La discipline qui compte le plus n’est pas le choix du modèle, mais la qualité des exemples de gravité dans le prompt et la rigueur du filet de sécurité en cas de panne du pipeline lui-même.