L'objectif est de savoir que votre système est défaillant avant que vos utilisateurs vous le disent. Une bonne observabilité vous permet de répondre à des questions que vous n'aviez pas anticipées, pas seulement de vérifier un ensemble fixe de tableaux de bord. En tant que tech lead, vous mettez cela en place avant l'incident, pas pendant.
Pagez sur ce que l'utilisateur ressent, pas sur les variations internes. Ancrez les alertes aux SLOs : taux d'erreur, latence (p95/p99) et disponibilité. Un pic CPU n'est pas un incident ; le paiement échouant pour 2 % des utilisateurs en est un.
| Alertez sur | N'appelez pas sur |
|---|---|
| Taux d'erreur dépassant l'SLO | Un pic CPU isolé |
| Latence p99 au-delà du budget | Une requête lente |
| Contrôles de santé échoués | Disque à 60 % |
Chaque alerte doit être urgente, réelle et actionnaire — elle nomme ce qui ne va pas et pointe vers une prochaine étape. Les alertes qui se déclenchent constamment habituent l'équipe à les ignorer ; la fatigue d'alerte est la façon dont les vrais incidents sont manqués. Ajoutez des contrôles de santé et des tableaux de bord qui montrent les signaux d'or en un coup d'œil.
Les équipes qui n'observent qu'après un incident volent à l'aveugle : elles en apprennent sur les pannes par des clients en colère et déboguent par devinettes. Investir dans l'observabilité dès le départ transforme les mystères de 3 heures du matin en diagnostics de 5 minutes, réduit les temps d'arrêt et libère l'équipe pour livrer plutôt que combattre les incendies.