62 % des ingénieurs en astreinte connaissent un épuisement professionnel dans les 12 mois (PagerDuty 2026). Ce n’est pas un problème humain. C’est un problème de conception technique. Trois causes racines communes à toute rotation épuisée : 1. Alertes basées sur les symptômes plutôt que sur les causes Pointes de CPU, profondeur de file, taux de requêtes — aucun de ces éléments ne constitue un incident. Tous réveillent les personnes à 3 h du matin. 2. Guides d’exploitation obsolètes Une alerte est déclenchée. Le guide pointe vers un service renommé. L’ingénieur reverse-engineer le système sous l’effet de l’adrénaline et sans sommeil. 3. Plannings symétriques pour une charge asymétrique Les week-ends sont le Super Bowl. Les jours ouvrables, un sprint. Le même planning traite les deux de la même manière. Quatre solutions mises en œuvre par les meilleures équipes : 1. Budget d’erreurs Limitez le travail d’astreinte non planifié à 25 % de la semaine. Au-delà, le développement de fonctionnalités s’arrête. Google SRE a défini la méthode. 2. Alertes liées aux SLO Si cela ne correspond pas à une violation observable par l’utilisateur des SLO, c’est du bruit. 23 % du temps d’astreinte sont des faux positifs (Blameless 2026). 3. Guide d’exploitation ou suppression Chaque alerte de production est accompagnée d’un guide d’exploitation à jour, sinon elle est supprimée. Vous perdrez la moitié de vos alertes. C’est l’objectif. 4. Rotations adaptées à la charge Les périodes de pointe nécessitent une couverture plus importante ou des créneaux plus courts. Le modèle unique pénalise celui qui tombe sur la période de pointe. Si vous dirigez une équipe technique, la conception de l’astreinte relève de votre responsabilité. Pas du RH. Pas de votre EM. De vous. Cette semaine : ouvrez le tableau de bord, comptez les alertes, et demandez-vous combien auraient dû être gérées par la plateforme et non par un humain. #EngineeringLeadership #OnCall #SRE