La fatigue des alertes est bien réelle : comment les bons développeurs s'en sortent

Ça porte un nom : la fatigue des alertes. C'est ce qui se passe quand vos outils de monitoring envoient tellement de notifications que votre cerveau commence à les filtrer automatiquement — même celles qui comptent vraiment.

Ça commence généralement petit. Vous configurez des alertes email pour chaque erreur 5xx. Ensuite des notifications Slack pour chaque build raté. Puis des pings Datadog, des emails Sentry, des SMS d'UptimeRobot. En un mois, votre téléphone vibre 50 fois par jour et rien ne semble urgent. Le pire dans tout ça ? Quand quelque chose casse vraiment, vous vous êtes déjà conditionné à ignorer les alertes.

La fatigue des alertes détruit le temps de réponse. Et un mauvais temps de réponse détruit les produits.

Pourquoi la plupart des setups de monitoring génèrent plus de bruit que de signal

Le problème fondamental, c'est que la plupart des outils d'alerte traitent tous les événements de la même façon. Un test instable qui échoue 10 % du temps reçoit le même format de notification que « l'API de paiement renvoie des 500 pour tous les utilisateurs ». L'un nécessite un appel téléphonique à 2h du matin. L'autre devrait figurer dans un résumé hebdomadaire.

Quand tout reçoit le même traitement, les humains finissent par tout ignorer.

La solution n'est pas moins d'alertes — c'est une livraison plus intelligente. Le même événement avec des niveaux de sévérité ou de fréquence différents devrait produire des niveaux d'urgence différents sur votre téléphone.

L'approche à trois niveaux

Echobell propose trois modes de livraison, et bien les utiliser tous les trois, c'est toute la différence :

Actif (Normal) : Notification push standard. Bien pour les événements informatifs qui n'exigent pas d'action immédiate.
Urgent : Passe outre le Mode Concentration d'iOS. Adapté pour les choses qui nécessitent une attention dans l'heure ou les deux heures qui suivent.
Appel : Fait sonner votre téléphone comme un appel entrant. Réservez ça pour « corrigez ça maintenant ou il y aura de vraies conséquences ».

L'objectif est de réserver le niveau appel aux événements où une réponse tardive a des conséquences réelles — revenus perdus, pannes en cascade, données utilisateurs à risque. Tout le reste passe en urgent ou moins.

Sentry : arrêtez d'être alerté pour chaque exception Python

Sentry est l'exemple canonique de fatigue des alertes. Par défaut, il envoie un email pour chaque nouveau type d'issue. Sur une base de code active pendant une semaine normale, c'est un véritable déluge.

Voici un setup plus intelligent :

Dans Sentry : Alertes → Créer une alerte → Alerte d'issue
Ajoutez une condition : L'issue a été vue plus de 10 fois en 1 heure
Ajoutez une action : Envoyer une notification via webhook → collez l'URL de votre canal Echobell
Configurez le type de notification du canal sur urgent

Pour les chemins vraiment critiques — exceptions non gérées dans les flux de paiement, échecs d'authentification, corruption de données — créez une alerte séparée avec un seuil plus bas et un canal Echobell en niveau appel. Ce canal ne sonne que quand quelque chose dans ce chemin spécifique casse.

Résultat : les issues routinières s'accumulent silencieusement dans votre tableau de bord Sentry. Les problèmes qui cassent la production vous appellent.

Prometheus et AlertManager : router par sévérité

Si vous utilisez Prometheus, vous avez déjà AlertManager pour le routage. Vous pouvez envoyer des alertes directement à Echobell en l'ajoutant comme récepteur webhook.

Dans votre alertmanager.yml :

receivers:
  - name: echobell-critical
    webhook_configs:
      - url: https://hook.echobell.one/YOUR_CHANNEL_ID
        send_resolved: true

  - name: slack-warnings
    slack_configs:
      - api_url: YOUR_SLACK_WEBHOOK

route:
  group_by: ['alertname', 'job']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: slack-warnings
  routes:
    - match:
        severity: critical
      receiver: echobell-critical

Avec cette configuration, les alertes severity: critical vont vers Echobell et font sonner votre téléphone ; les avertissements vont vers Slack où ils peuvent attendre jusqu'au lendemain matin. Vous n'avez pas besoin de changer une seule règle Prometheus — ajoutez simplement la couche de routage dans AlertManager.

Configurez le canal Echobell lui-même sur Appel. Si AlertManager l'appelle critique, ça mérite une vraie sonnerie.

AWS CloudWatch : SNS → Lambda → Echobell

CloudWatch n'a pas de sortie webhook native, mais vous pouvez y arriver en quelques minutes avec SNS et une petite fonction Lambda.

Créez un topic SNS et attachez-le à votre alarme CloudWatch
Créez une fonction Lambda abonnée à ce topic :

import json
import urllib.request

def lambda_handler(event, context):
    message = json.loads(event['Records'][0]['Sns']['Message'])
    alarm_state = message.get('NewStateValue', 'UNKNOWN')

    payload = {
        "title": f"AWS: {message['AlarmName']}",
        "body": message.get('NewStateReason', 'Pas de détails'),
        "notificationType": "calling" if alarm_state == "ALARM" else "active"
    }

    req = urllib.request.Request(
        'https://hook.echobell.one/YOUR_CHANNEL_ID',
        data=json.dumps(payload).encode(),
        headers={'Content-Type': 'application/json'},
        method='POST'
    )
    urllib.request.urlopen(req)

Ce pattern fonctionne pour tout service AWS qui supporte SNS : événements RDS, échecs de service ECS, alertes de seuil de facturation, changements d'état d'instances EC2. Une Lambda configurée, connectée à SNS, et chaque alarme CloudWatch devient un appel téléphonique quand elle se déclenche vraiment.

Faire du routage des alertes une décision d'équipe

Le vrai levier avec les alertes hiérarchisées, c'est de rendre la décision de routage explicite — pas quelque chose que quelqu'un a configuré une fois et que personne ne retrouve.

Une structure pratique pour une petite équipe d'ingénierie :

Canal	Type	Qui s'abonne
`production-api-critical`	Appel	Ingénieur d'astreinte
`production-api-warnings`	Urgent	Toute l'équipe dev
`staging-all`	Actif	Équipe dev (optionnel)
`background-jobs`	Actif	Les intéressés

Quand la rotation d'astreinte change, la personne sortante se désabonne du canal critique et la personne entrante s'y abonne. C'est tout le processus de passation — pas de fichiers de config à modifier, pas de panneau d'administration.

Les canaux Echobell sont partageables par lien, s'abonner prend environ 10 secondes pour chaque nouveau membre de l'équipe.

Le test signal-sur-bruit

Avant d'ajouter une nouvelle alerte, posez-vous une question : si ça se déclenche à 3h du matin un vendredi, qu'est-ce que je fais vraiment ?

« Je me lève et je règle ça immédiatement » → Appel
« Je m'en occupe dès le lendemain matin » → Urgent ou Actif
« Probablement rien, je me rendors » → reconsidérez si l'alerte devrait exister du tout

La plupart des setups de monitoring ont trop de choses dans la première catégorie et pas assez dans la deuxième. La bonne réponse pour la majorité des événements, c'est « gérer ça demain » — et une notification urgente qui apparaît silencieusement sur l'écran de verrouillage est exactement le bon outil pour ça.

Un changement à la fois

Si votre configuration actuelle génère de la fatigue des alertes, la solution la plus rapide n'est pas une refonte complète. Choisissez votre source la plus bruyante — probablement les emails Sentry ou un canal Slack que tout le monde a mis en sourdine — et catégorisez chaque type d'événement en appel, urgent ou actif.

Une source. Une semaine. Voyez si le bruit diminue sans perdre de signal.

Puis passez à la suivante.

Un setup d'alertes bien réglé, c'est une de ces choses qui améliore silencieusement votre quotidien au travail, sans faire de bruit. Vous arrêtez de redouter votre téléphone. Vous commencez à faire confiance au fait que quand il sonne, ça compte vraiment.