# En finir avec la fatigue des alertes

> Fatigue des alertes : 43 alertes pour une panne, et vous finissez par tout ignorer. Regroupement, rétablissements et heures calmes y remédient.

Source: https://honk-me.app/fr/guides/fatigue-des-alertes

La fatigue des alertes ne vient pas du nombre de problèmes, mais du nombre de notifications par problème. Redis cesse de répondre pendant sept minutes, l’API de facturation réessaie toutes les dix secondes, et votre téléphone vibre 43 fois. À la troisième vibration, vous avez compris. À la vingtième, vous avez coupé les notifications, et le prochain vrai problème tombe sur un téléphone muet.

Le remède tient en quelques habitudes, valables quel que soit l’outil. Chaque section en présente une, puis montre comment l’appliquer avec Honk.

## 1. Une alerte par problème, pas par tentative

Une boucle de nouvelles tentatives ne fait pas 43 problèmes, mais un seul, survenu 43 fois. Définissez ce qu’est « le même problème », donnez-lui un nom stable et joignez ce nom à chaque événement.

Dans Honk, ce nom s’appelle la `group_key`. Les événements qui ont en commun le projet, l’environnement, la source, le canal et la `group_key` forment un groupe, et seul le premier événement d’un nouvel épisode déclenche un push.

```sh
# Before: one push per failed attempt, 43 in seven minutes
curl … -d '{"title":"Redis timeout","message":"attempt 17 failed"}'
```

```sh
# After: one group, one episode, one push, then calm updates
honk-me problem --group-key billing/redis --source billing-api \
  --title "Redis connection failed" --message "Billing API could not connect to Redis (timeout after 5 s)"
# …and when it works again:
honk-me recovery --group-key billing/redis --source billing-api \
  --title "Redis is back" --message "Connected after 7 minutes"
```

## 2. Rester discret sur les répétitions, sauf si ça empire

Tant que le problème dure, vous voulez savoir qu’il est toujours là, mais pas 43 fois. Honk envoie au plus une mise à jour toutes les 5 minutes (le délai par défaut, réglable par projet), avec le nombre d’occurrences. Si le niveau monte, par exemple d’un Coup de klaxon appuyé à un Klaxon continu, la mise à jour part aussitôt en push, car une aggravation est en soi une nouvelle.

## 3. Boucler la boucle avec un rétablissement

Une alerte qui ne se termine jamais vous laisse dans le doute. Quand tout est rentré dans l’ordre, envoyez un événement `recovery` avec la même `group_key` : Honk vous prévient, clôt l’épisode, et l’incident cesse de réclamer votre attention. N’envoyez de rétablissement qu’après un échec. En envoyer un après chaque vérification réussie, c’est encore du bruit.

Sans rétablissement, l’épisode devient inactif après une période de calme (24 heures par défaut). Inactif ne veut pas dire résolu : l’événement suivant ouvre un nouvel épisode et déclenche un nouveau push.

## 4. Reléguer la routine au récapitulatif

Tous les événements ne méritent pas un push. Un import terminé, une sauvegarde réussie, un rapport quotidien : bon à savoir, mais pas au point de vous interrompre. Envoyez-les en Petit coup de klaxon ou en Bip-bip, en priorité normale ou basse, et réglez votre seuil de push sur Haute. Tout ce qui passe sous ce seuil rejoint un récapitulatif, envoyé toutes les 15 minutes par défaut, et jamais s’il est vide.

Une règle de projet obtient le même résultat sans toucher au code. Par exemple : tout événement de la catégorie `deployments` et de gravité `success` va dans le récapitulatif.

## 5. Réserver la nuit à ce qui ne peut pas attendre

Pendant les heures calmes, les push sont retenus, puis résumés en un seul message à la fin. Décidez à l’avance de ce qui peut passer malgré tout. Dans Honk, ce sont uniquement les événements envoyés en priorité `urgent`, par une clé d’ingestion qui y est autorisée, et seulement si vos heures calmes laissent passer les messages urgents. Réservez ce droit à une seule clé, celle du service qui mérite de vous réveiller.

## 6. Choisir le niveau sans tricher

L’échelle Honk compte cinq niveaux, qui ne servent que s’ils veulent dire quelque chose. Réservez **Klaxon continu** à « quelque chose est en panne » et **Long coup de klaxon** à « quelque chose a échoué ». Si tout passe en Klaxon continu, plus rien n’est urgent.

## Liste de contrôle des clés de groupe

- **Une clé par chose que vous répareriez en une fois.** `billing/redis`, pas `billing/redis/attempt-17`.
- **Ni horodatage, ni identifiant de requête, ni valeur aléatoire dans la clé**, sauf si chaque événement est vraiment un cas à part, comme une demande client (`requests/4812`).
- **Indiquez l’emplacement dans la clé** quand le même problème sur deux machines en fait deux : `disk/app-01/var`.
- **Utilisez la même clé pour le problème et son rétablissement.** C’est ainsi que Honk sait ce qui est rétabli.
- **Gardez-la courte et lisible.** Elle s’affiche dans la boîte de réception, et les règles peuvent s’en servir comme critère.

## Comment Honk applique ces principes

Honk est construit autour de ces habitudes. Les groupes et les épisodes suivent des règles fixes, appliquées sur le serveur. Le délai entre mises à jour et le récapitulatif se règlent par projet, les heures calmes et la mise en sourdine par personne. Sur l’iPhone, l’IA peut résumer un groupe, mais jamais masquer ni retarder une notification. Toutes les règles sont détaillées sur la page [Comment fonctionne Honk](https://honk-me.app/fr/fonctionnement).