Echobell en pratique : cas d'usage et intégrations qui fonctionnent vraiment

Les alertes sont cassées. Pas la technologie — le comportement autour d'elles. Quand tout vibre, rien n'attire vraiment l'attention. La plupart des gens se sont entraînés à ignorer les badges de notification, à mettre leur téléphone en silencieux et à vérifier les choses "quand ils auront le temps".

Echobell a été conçu pour les moments où "quand tu auras le temps" c'est déjà trop tard. Voici comment différentes personnes l'utilisent — et les intégrations concrètes qui le rendent possible.

Développeurs : savoir immédiatement quand votre API tombe

Le cas d'usage classique du développeur : vous avez une API en production. Vous avez un outil de monitoring. Mais quand quelque chose déraille à 2h du matin, l'alerte reste sans réponse dans un canal Slack jusqu'au matin.

Echobell se connecte à votre stack de monitoring via webhook. Quand un health check échoue, votre téléphone sonne — pas une notification push qu'on peut réduire au silence, mais un vrai appel qui retentit.

curl -X POST https://hook.echobell.one/VOTRE_CHANNEL_ID \
  -H "Content-Type: application/json" \
  -d '{
    "title": "API DOWN : payment-service",
    "body": "Erreurs 500 depuis 02:17 UTC",
    "notificationType": "calling"
  }'

Ça marche avec tout ce qui peut envoyer des requêtes HTTP : Datadog, Better Uptime, Freshping, UptimeRobot, scripts de health check maison — au choix.

Pour les services moins critiques, passez notificationType à time-sensitive. Ça perce quand même le Mode Concentration d'iOS, mais sans la sonnerie complète.

Pipelines CI/CD : arrêtez de surveiller. Laissez-vous notifier.

Attendre qu'un build se termine en actualisant GitHub Actions toutes les 30 secondes n'est pas une bonne utilisation du temps. Mais vous ne voulez pas non plus changer complètement de contexte et rater l'échec du déploiement.

Configurez une étape webhook à la fin de votre pipeline. Quand le job se termine — succès ou échec — Echobell envoie le résultat directement sur votre téléphone.

- name: Notification Echobell
  if: always()
  run: |
    curl -X POST https://hook.echobell.one/VOTRE_KEY \
      -H "Content-Type: application/json" \
      -d "{
        \"title\": \"${{ github.workflow }} ${{ job.status }}\",
        \"body\": \"${{ github.repository }} @ ${{ github.sha }}\",
        \"notificationType\": \"time-sensitive\"
      }"

C'est une de ces petites choses qui évite discrètement beaucoup de changements de contexte sur une semaine.

Monitoring serveur et uptime : Grafana, Upptime et compagnie

Si vous utilisez déjà Grafana, vous pouvez router les notifications d'alerte directement vers Echobell via son point de contact webhook. Créez un canal, configurez l'URL webhook, c'est fait. Quand une alerte se déclenche, votre téléphone sonne.

Les utilisateurs d'Upptime peuvent faire la même chose avec quelques lignes dans .upptimerc.yml :

notifications:
  - type: webhook
    endpoint: https://hook.echobell.one/VOTRE_CHANNEL_ID

Ce qui est bien avec ces deux intégrations, c'est qu'elles utilisent vos règles d'alerte existantes. Pas besoin de tout redéfinir — vous ajoutez simplement Echobell comme sortie.

Zapier et automatisations sans code

Tout n'est pas un problème de développeur. Zapier dispose de milliers de déclencheurs : soumissions de formulaires, mises à jour CRM, événements de paiement, modifications de tableurs. N'importe lequel peut déclencher une notification Echobell.

Configurez une action Webhook Zapier pointant vers votre canal Echobell, et vous pouvez connecter des notifications à presque n'importe quel événement métier imaginable :

Un lead de haute valeur arrive depuis votre formulaire web
Un paiement échoue dans Stripe
Une ligne est ajoutée à une feuille Google
Une tâche est en retard dans votre outil de gestion de projet

Pour les événements métier où le timing compte, recevoir une vibration (ou un appel pour les vriment critiques) est beaucoup plus fiable qu'espérer remarquer un message Slack.

Déclencheurs email : transformez les emails en alertes d'appel

Certains systèmes ne supportent que la sortie par email — anciens outils de monitoring, plateformes SaaS legacy, systèmes métier internes. Echobell dispose d'un déclencheur email intégré.

Chaque canal reçoit une adresse @echobell.app unique. Les emails envoyés à cette adresse déclenchent une notification. L'objet devient le titre, le corps devient le message.

Transférez les alertes depuis vos outils de monitoring, connectez-le via une règle de filtre email, ou utilisez-le directement. La notification se déclenche de la même façon que n'importe quel autre déclencheur Echobell.

Workflows IA et tâches asynchrones

Vous lancez de longs jobs IA, du traitement par lots, ou quoi que ce soit qui prend plus de quelques minutes ? Au lieu de fixer un terminal, utilisez Echobell Direct pour vous notifier quand le job se termine.

import httpx

def notify_complete(task_name: str, result: str):
    httpx.post(
        "https://hook.echobell.one/d/VOTRE_KEY",
        json={
            "title": f"{task_name} terminé",
            "body": result,
            "notificationType": "time-sensitive"
        }
    )

Ça s'intègre bien avec WebhookMCP si vous travaillez avec Claude ou d'autres agents IA — l'agent peut déclencher une notification Echobell quand il termine une longue tâche.

Astreintes d'équipe : canaux partagés

Le modèle de canaux d'Echobell fonctionne pour les équipes, pas seulement les individus. Créez un canal pour un service, partagez le lien d'abonnement avec votre équipe, et tous ceux qui s'abonnent reçoivent l'alerte.

C'est pratique pour les rotations d'astreinte :

Celui qui est d'astreinte s'abonne au canal de production
Quand quelque chose se déclenche, les bonnes personnes reçoivent l'appel — pas un canal Slack rempli de gens qui ne sont pas de service
Quand la rotation change, l'ancienne personne d'astreinte se désabonne et la nouvelle s'abonne

Pas besoin de configuration PagerDuty complexe pour les petites équipes.

Jobs cron et scripts planifiés

Les jobs cron échouent silencieusement. Un script qui tourne la nuit et rencontre une erreur va juste... ne rien faire, et personne ne s'en rendra compte avant que quelque chose soit visiblement cassé en aval.

Ajoutez une notification Echobell à la fin de vos scripts :

#!/bin/bash
# votre script ici
python process_data.py

if [ $? -ne 0 ]; then
  curl -s -X POST https://hook.echobell.one/d/VOTRE_KEY \
    -H "Content-Type: application/json" \
    -d '{"title": "Cron échoué", "body": "process_data.py a quitté avec erreur", "notificationType": "time-sensitive"}'
fi

Une minute de configuration par script évite beaucoup de débogage plus tard.

Choisir le bon niveau d'urgence

Echobell a trois types de notification, et utiliser le bon est important :

Type	Comportement	Quand utiliser
`active`	Notification push classique	Mises à jour informatives, non urgentes
`time-sensitive`	Perce le Mode Concentration	Important mais pas immédiatement critique
`calling`	Le téléphone sonne comme un appel entrant	Pannes de production, défaillances critiques

Le type calling nécessite un abonnement premium, et ça vaut la peine de le réserver pour les choses qui nécessitent vraiment une action immédiate. Utilisez time-sensitive pour le reste — c'est toujours fiable et ne créera pas de fatigue d'alerte.

Commencez petit

La première intégration la plus simple est généralement un job cron ou un pipeline CI — petit, autonome, facile à tester. Faites-en fonctionner un, voyez ce que ça donne, et étendez à partir de là.

Echobell est le plus utile quand il remplace une notification que vous ratez actuellement. Pensez à la dernière fois où vous avez appris un problème plus tard que vous n'auriez dû — c'est l'intégration à construire en premier.