Slack + Discord + Telegram depuis un seul endpoint Fastify.

Brief

Un petit service qui prend un payload de notification et le distribue vers Slack, Discord et Telegram depuis un seul endpoint. Utilisé par le reste de la plateforme : ContentForge l’appelle pour le prompt de revue quotidien, FB-Media l’appelle pour les alertes de pipeline, le tableau de bord homelab l’appelle pour les dépassements de seuil.

Le brief était simple : remplacer trois clients de notification différents (un par canal) par un seul endpoint HTTP qui fait ce qu’il faut. Réduire le nombre d’identifiants que chaque projet doit connaître de trois à un.

Architecture

Un seul endpoint Fastify (POST /notify) sur Node, tournant dans CT 209 sur le nœud Proxmox services. Le payload est une enveloppe fine :

{
  "message": { "title": "...", "body": "...", "source": "..." },
  "severity": "info | success | warning | error | critical"
}

Le handler choisit le formatage par canal (attachment Slack avec couleur, embed Discord avec icône de gravité, Telegram Markdown avec emoji) depuis une seule table de lookup, ajouter un quatrième canal plus tard signifie une seule entrée, pas un switch statement par canal.

Un second endpoint (POST /telegram/webhook) écoute les messages Telegram entrants et répond via un petit backend de chat bidirectionnel pointé vers le conteneur Ollama de la station. Le chat est gardé hors de l’accès public via l’allowlist du bot Telegram (seuls les chat IDs appariés reçoivent des réponses).

Résultats

• 3 canaux (Slack, Discord, Telegram) accessibles via un seul endpoint HTTP.
• Un schéma de payload unifié, chaque projet qui appelle utilise la même enveloppe.
• Chat Telegram bidirectionnel avec un backend Ollama résident sur la station, sans coût API par message.
• Zéro panne non planifiée depuis le lancement, le service tourne comme une seule unité systemd avec auto-restart.

La suite

Deux éléments sur la liste de la prochaine itération :

1. Standardiser la correspondance gravité → formatage-canal dans une petite table de lookup dès le premier jour, le switch statement par canal actuel convient à trois canaux mais deviendrait ingérable à six. Le refactor table-de-lookup est en queue.
2. Récepteur webhook pour Prometheus AlertManager, la plateforme fait déjà tourner Prometheus + Grafana ; le consommateur naturel suivant de /notify est AlertManager déclenchant sur les dépassements de seuil Grafana.