Centraliser ses notifications multi-outils dans un digest IA unique avec n8n

Une PME qui utilise n8n pour automatiser sa relation client reçoit vite des notifications de partout : un email prioritaire classé par IA, une alerte Sentry, un ticket support noté urgent, un nouveau lead CRM à qualifier, un commentaire GitHub. Chaque système d'alerte pris isolément est raisonnable. Additionnés, ils reconstituent exactement le problème que l'automatisation devait résoudre : une attention fragmentée en dizaines d'interruptions par jour. Ce guide construit un digest IA unique dans n8n, qui absorbe ces flux hétérogènes et ne remonte que ce qui mérite vraiment une interruption.

Pourquoi regrouper plutôt que trier source par source

Nos guides sur le tri d'emails par IA ou le scoring de tickets support montrent chacun comment prioriser une source. Le problème apparaît quand on empile plusieurs de ces digests : un digest email à 8 h, un digest tickets à 9 h, un résumé Sentry à 10 h. On a remplacé le bruit continu par du bruit planifié, sans réduire le nombre d'interruptions.

Le coût de ces interruptions est documenté. Une étude de Mark, Gudith et Klocke publiée à la conférence CHI 2008 (The Cost of Interrupted Work: More Speed and Stress) a mesuré, chez des travailleurs de bureau réels, que reprendre une tâche après une interruption pousse à travailler plus vite pour compenser — au prix d'un stress et d'une frustration mesurablement plus élevés (voir l'étude sur Google Scholar). Dans le même esprit, l'étude de Kushlev et Dunn publiée en 2015 dans Computers in Human Behavior a montré, sur un protocole en conditions réelles, que limiter la consultation de sa messagerie à trois fois par jour réduit significativement le stress quotidien par rapport à une consultation illimitée (voir l'étude sur Google Scholar). La conclusion pratique est la même dans les deux cas : ce n'est pas le volume d'information qui coûte cher, c'est sa fragmentation dans le temps. Un digest unique, à heure fixe, applique ce principe à toutes vos sources d'alertes en même temps — pas seulement à l'email.

L'architecture : un pipeline en quatre étages

1. Collecte : chaque source (email, Slack, ticket, webhook CRM, flux RSS) déclenche son propre mini-workflow, qui se contente de normaliser l'événement et de l'empiler dans une file d'attente commune.
2. Normalisation : tous les événements sont ramenés au même schéma, quelle que soit leur origine.
3. Agrégation quotidienne : un Schedule Trigger relit la file une fois par jour et transmet le lot complet à un LLM.
4. Synthèse et envoi : le modèle produit une seule note structurée, triée par priorité, envoyée sur le canal de votre choix.

Étage 1 — Normaliser chaque source dans un schéma commun

C'est l'étape qui détermine si le digest final est lisible ou illisible. Peu importe que l'événement vienne d'un email, d'un ticket Zendesk ou d'une alerte Sentry (voir notre guide sur le tri d'alertes Sentry par IA) : un node Edit Fields (Set) placé juste après chaque trigger le convertit vers la même structure minimale :

{
  "source": "email | slack | ticket | crm | github",
  "titre": "résumé court de l'événement",
  "contenu": "texte brut, tronqué à 1000 caractères",
  "url": "lien direct vers l'élément d'origine",
  "horodatage": "2026-08-02T09:14:00Z",
  "urgence_declaree": true
}

Le champ horodatage mérite une attention particulière si vos sources ne sont pas dans le même fuseau : normalisez-le en UTC dès l'entrée avec le node Luxon (voir notre guide sur les dates et heures dans n8n), pour éviter qu'un événement de 23 h se retrouve classé le lendemain dans le digest.

Étage 2 — La file d'attente : Data Tables ou Supabase

Chaque événement normalisé est ensuite inséré dans une file d'attente persistante, avec un statut en_attente. Pour un volume modéré — quelques dizaines d'événements par jour, ce qui couvre la majorité des PME — les n8n Data Tables suffisent très largement : pas de projet externe à provisionner, une table typée avec les colonnes ci-dessus, et un node Data Table pour insérer chaque ligne. Si vous avez besoin d'un historique interrogeable sur plusieurs mois ou d'une piste d'audit conforme, comme dans le Pack Conformité & Audit (149 €), une table Supabase classique reste préférable — voir notre guide de connexion n8n-Supabase.

Ce découplage collecte/traitement a un deuxième avantage : si le LLM ou le canal d'envoi est temporairement indisponible, les événements s'accumulent simplement dans la file au lieu d'être perdus.

Étage 3 — L'agrégation quotidienne

Un Schedule Trigger réglé à l'heure de votre choix (voir notre guide du Schedule Trigger et des fuseaux horaires) déclenche la lecture de tous les événements au statut en_attente. Si plusieurs branches de collecte alimentent la même file, un node Merge en mode « Append » réunit leurs sorties avant l'agrégation — voir notre guide du node Merge pour les subtilités des différents modes de fusion.

Étage 4 — La synthèse par LLM avec sortie structurée

C'est ici que la valeur se joue. Plutôt que de simplement lister les événements, le LLM reçoit le lot complet et un prompt qui lui demande de les classer et regrouper, avec un Structured Output Parser en sortie :

{
  "type": "object",
  "properties": {
    "urgent": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "resume": { "type": "string" },
          "source": { "type": "string" },
          "action_suggeree": { "type": "string" },
          "url": { "type": "string" }
        }
      }
    },
    "a_traiter_aujourdhui": { "type": "array", "items": { "type": "object" } },
    "pour_information": { "type": "array", "items": { "type": "object" } }
  },
  "required": ["urgent", "a_traiter_aujourdhui", "pour_information"]
}

Côté prompt, donnez des règles de tri explicites plutôt que de laisser le modèle deviner :

Tu reçois une liste d'événements provenant de plusieurs outils (email, Slack, tickets, CRM, GitHub).
Classe chaque événement dans une seule catégorie :
- "urgent" : nécessite une action dans l'heure (incident, client furieux, échéance du jour).
- "a_traiter_aujourdhui" : important mais pas bloquant, à traiter avant ce soir.
- "pour_information" : rien à faire, juste à connaître.
Pour "urgent" et "a_traiter_aujourdhui", propose une action suivante en une phrase.
Regroupe les événements manifestement liés au même sujet en un seul point.

Cette dernière consigne — regrouper les doublons thématiques — est ce qui distingue un vrai digest d'une simple concaténation : trois notifications sur le même incident Sentry ne doivent produire qu'une seule ligne dans la synthèse finale.

Envoi et bouclage de la file

Le digest structuré est ensuite formaté (un node Code ou un second appel LLM léger transforme le JSON en Markdown lisible) et envoyé par email, Slack ou Telegram. Dernière étape, souvent oubliée : un node Data Table (ou une requête Supabase) repasse chaque événement traité au statut envoye, pour ne jamais le réinjecter dans le digest du lendemain.

Les pièges classiques

• Un digest qui devient lui-même une notification stressante. Si la section « urgent » contient dix items chaque matin, le seuil de classification est mal calibré ailleurs dans vos workflows sources — le digest ne fait que révéler un problème de tri en amont, il ne le corrige pas.
• Pas de filet de sécurité en temps réel. Le digest ne doit jamais être le seul canal pour un incident réellement bloquant : conservez une alerte immédiate en parallèle pour ce qui dépasse un seuil de gravité, avant que l'événement n'attende son tour dans la file.
• Coût et volume. Avec un modèle économique (gpt-4o-mini ou équivalent) et un lot quotidien de 50 à 100 événements tronqués, la synthèse coûte typiquement quelques centimes par jour — voir notre guide de suivi du coût des appels IA pour instrumenter précisément ce chiffre sur votre volume réel.
• Sources qui dépassent les limites de débit. Si une des collectes interroge une API à haute fréquence (webhooks CRM en rafale, par exemple), appliquez les bonnes pratiques de notre guide sur les erreurs 429 avant que ce goulot ne fasse échouer toute la chaîne.

Partir d'une base déjà en place

Le Pack Inbox IA (79 €) contient déjà le cœur de ce pipeline pour la source email : classification IA avec sortie structurée et digest quotidien Slack/Telegram, prêts à importer. Étendre ce socle aux autres sources revient à répéter le même schéma de normalisation pour chaque nouveau trigger, puis à les faire converger vers une seule file et un seul appel LLM de synthèse — quelques heures de travail pour transformer une dizaine de flux de notifications séparés en une habitude unique : un point le matin, et le reste de la journée sans interruption.