Dimanche, 2h47 du matin. Votre téléphone vibre. L’écran affiche “ALERTE CRITIQUE - Payment API”. Vous sortez du lit, l’esprit embrumé, vous ouvrez votre laptop. Vous cherchez le dashboard, vous cherchez les logs, vous cherchez le runbook. Après 45 minutes de tâtonnement, vous réalisez que c’était un faux positif — un pic de charge transitoire qui s’est résorbé tout seul.
Mercredi suivant. Même alerte, même heure. Cette fois, c’est réel. Mais épuisé par le réveil de dimanche, vous mettez plus de temps à réagir. Et le runbook est incomplet — il ne couvre pas ce cas précis.
Ce scénario n’est pas une fatalité. L’astreinte peut être soutenable, voire formatrice, si elle est bien conçue. C’est ce que Google a codifié dans leurs pratiques SRE, et c’est ce que nous allons explorer.
Pourquoi l’astreinte existe
Section intitulée « Pourquoi l’astreinte existe »Un système en production vit. Il reçoit du trafic, traite des données, communique avec des services externes. Et parfois, il rencontre des situations que l’automatisation seule ne peut pas gérer.
L’automatisation excelle pour les problèmes prévisibles. Un service qui dépasse sa limite mémoire peut être redémarré automatiquement. Une base de données qui approche de la saturation peut déclencher un auto-scaling. Mais certaines situations nécessitent un jugement humain.
Quand un incident implique plusieurs services interdépendants, quelqu’un doit coordonner la réponse. Quand une décision de rollback pourrait avoir des effets de bord complexes, quelqu’un doit évaluer les risques. Quand un problème n’a jamais été vu auparavant, quelqu’un doit investiguer et trouver une solution créative.
L’astreinte existe pour fournir cette capacité de réponse humaine quand l’automatisation atteint ses limites. Sans elle, un incident à 2h du matin attend 9h — et sept heures de dégradation peuvent coûter très cher, en argent comme en réputation.
Les principes d’une astreinte saine
Section intitulée « Les principes d’une astreinte saine »Google SRE a établi des principes pour que l’astreinte reste soutenable sur le long terme. Ces principes ne sont pas des idéaux théoriques — ce sont des règles opérationnelles testées à l’échelle de milliards d’utilisateurs.
L’équilibre entre charge et repos
Section intitulée « L’équilibre entre charge et repos »Une personne en astreinte ne peut pas être en astreinte “tout le temps”. L’astreinte est une contrainte sur la vie personnelle — vous devez rester disponible, sobre, à portée de votre laptop. Cette contrainte a un coût psychologique qui s’accumule.
Google recommande qu’une personne ne soit pas d’astreinte plus de 25% du temps — soit environ une semaine sur quatre. En dessous de ce seuil, la rotation reste soutenable. Au-dessus, la fatigue s’accumule et les erreurs se multiplient.
Pendant un shift d’astreinte, le nombre d’incidents devrait rester limité. La recommandation est de maximum 2 incidents par shift de 12 heures. Cela peut sembler peu, mais chaque incident représente du stress, de l’interruption de sommeil potentielle, et du temps de récupération cognitive.
Si votre équipe reçoit régulièrement plus de 2 incidents par shift, c’est un signal d’alarme. Le problème n’est pas que l’équipe “n’est pas assez réactive” — le problème est que le système n’est pas assez fiable pour être supporté dans ces conditions. L’investissement doit aller dans la stabilité, pas dans l’endurance humaine.
Après un shift particulièrement chargé — plusieurs incidents, réveil en pleine nuit, stress élevé — la personne d’astreinte devrait bénéficier d’au moins un jour de récupération. Pas de réunions obligatoires le lendemain d’une nuit blanche.
Des alertes actionnables uniquement
Section intitulée « Des alertes actionnables uniquement »Chaque alerte qui sonne sur le téléphone d’une personne d’astreinte devrait remplir quatre critères stricts :
| Critère | Description | Exemple conforme | Exemple non conforme |
|---|---|---|---|
| Urgente | Nécessite une action dans les minutes/heures | ”Payment API down” | Problème qui peut attendre lundi |
| Actionnable | La personne sait quoi faire | ”Runbook: wiki/payment-errors" | "CPU élevé sur server-42” |
| Basée sur les symptômes | Ce que l’utilisateur voit | ”Latence > 2s" | "CPU à 90%“ |
| Non redondante | 1 incident = 1 alerte | Alerte unique par incident | 10 alertes pour le même problème |
Des runbooks à jour
Section intitulée « Des runbooks à jour »Un runbook est la documentation pas-à-pas pour répondre à une alerte spécifique. Sans runbook, la personne d’astreinte improvise à 3h du matin, sous stress, avec un cerveau qui n’est pas à son meilleur.
Un bon runbook contient 4 sections :
-
Contexte : Quel service est concerné, son rôle, l’impact utilisateur. Permet de comprendre la gravité et de prioriser.
-
Diagnostic rapide (5 premières minutes) : Quel dashboard consulter, quels logs regarder, quelles métriques vérifier. Objectif : catégoriser le problème.
-
Actions correctives organisées par diagnostic :
- Si symptôme X → faire Y
- Si symptôme Z → faire W
- Actions concrètes et testées (ex:
kubectl get pods -l app=payment)
-
Critères d’escalade : Quand appeler du renfort, qui appeler, comment les joindre.
Une compensation juste
Section intitulée « Une compensation juste »L’astreinte est une contrainte réelle sur la vie personnelle. Être d’astreinte un week-end, c’est renoncer à partir en randonnée, à boire du vin au restaurant, à être déconnecté. Cette contrainte mérite une compensation.
Les modèles de compensation varient. Certaines organisations optent pour un paiement : une prime forfaitaire par semaine d’astreinte, ou un tarif horaire pour le temps effectivement passé sur les incidents. D’autres préfèrent le temps off : quatre heures de récupération pour chaque nuit d’astreinte, par exemple. La plupart combinent les deux.
Mais la meilleure compensation, au fond, est une charge d’astreinte légère. Une équipe préfère une astreinte tranquille — peu d’alertes, incidents rares et bien documentés — à une astreinte bien payée mais épuisante. L’investissement dans la fiabilité du système est la vraie façon de respecter les personnes d’astreinte.
Concevoir une rotation
Section intitulée « Concevoir une rotation »La rotation d’astreinte est la façon dont vous répartissez la charge entre les membres de l’équipe. Une bonne rotation est prévisible, équitable, et soutenable.
La taille de l’équipe détermine le rythme
Section intitulée « La taille de l’équipe détermine le rythme »| Taille d’équipe | Fréquence d’astreinte | Confort | Notes |
|---|---|---|---|
| 4-5 personnes | 1 semaine sur 4-5 | ⚠️ Tendu | Peu de marge pour vacances/maladies |
| 6-8 personnes | 1 semaine sur 6-8 | ✅ Confortable | Marge pour les imprévus |
| 8+ personnes | Système Primary/Secondary | ✅✅ Optimal | Formation intégrée |
Primary et Secondary
Section intitulée « Primary et Secondary »Le système à deux niveaux offre plusieurs avantages. Le primary gère les incidents de routine — ceux qui sont documentés, qui suivent les runbooks, qui se résolvent en quelques minutes. Le secondary intervient quand le primary est débordé (plusieurs incidents simultanés), injoignable (problème de réseau, urgence personnelle), ou dépassé (incident complexe hors de ses compétences).
Le rôle de secondary est aussi un excellent outil de formation. Un nouvel arrivant peut commencer en secondary, observer comment le primary gère les incidents, intervenir progressivement, avant de passer primary lui-même.
Le handoff structuré
Section intitulée « Le handoff structuré »Le passage de relais entre deux shifts est un moment critique. Un handoff bâclé crée des trous dans la couverture et perd de l’information.
Un bon handoff couvre quatre points. D’abord, les incidents en cours : y a-t-il des problèmes non résolus, des actions en attente, des fils à reprendre ? Ensuite, l’état des systèmes : y a-t-il eu des déploiements récents, des changements de configuration, des dégradations observées ? Puis les informations spéciales : fenêtre de maintenance prévue, événement business (Black Friday, lancement produit), contexte particulier à connaître. Enfin, la confirmation explicite : l’astreinte sortante confirme que le handoff est terminé et que l’astreinte entrante est opérationnelle.
Ce handoff peut prendre 5 minutes ou 30 minutes selon ce qui s’est passé. Il ne devrait jamais être sauté.
Réduire la charge d’astreinte
Section intitulée « Réduire la charge d’astreinte »L’objectif n’est pas de “tenir” une astreinte difficile. L’objectif est de rendre l’astreinte légère. Chaque incident est une occasion d’amélioration.
Éliminer les alertes bruyantes
Section intitulée « Éliminer les alertes bruyantes »Après chaque shift, passez en revue les alertes reçues. Celles qui n’ont nécessité aucune action — juste une vérification que tout allait bien — sont candidates à la suppression ou à la conversion en log. Celles qui se sont résolues d’elles-mêmes en quelques minutes peuvent nécessiter un délai avant déclenchement, ou un seuil plus élevé. Celles qui reviennent plusieurs fois par semaine sans qu’on corrige la cause méritent qu’on investisse dans un fix permanent.
Le but est d’arriver à un état où chaque alerte qui sonne est une vraie alerte qui nécessite une vraie action. La personne d’astreinte doit faire confiance au système d’alerting.
Automatiser les réponses répétitives
Section intitulée « Automatiser les réponses répétitives »Si le runbook dit “redémarrer le service”, pourquoi un humain le fait-il à 3h du matin ? Les actions répétitives et sans risque peuvent souvent être automatisées.
Un service qui crashe par manque de mémoire peut être configuré avec un auto-restart. Une file de messages qui s’accumule peut déclencher un auto-scaling. Un batch qui échoue peut être retenté automatiquement avant d’alerter un humain.
L’automatisation ne supprime pas l’astreinte — elle la réserve aux cas où un jugement humain est vraiment nécessaire.
Investir dans la fiabilité
Section intitulée « Investir dans la fiabilité »Chaque incident d’astreinte devrait générer un item d’amélioration. Un bug récurrent justifie un ticket de correction. Un manque de monitoring justifie une amélioration de l’observabilité. Une procédure manquante justifie un nouveau runbook. Un problème récurrent justifie un investissement dans un fix permanent.
Si votre équipe passe son temps à éteindre les mêmes feux encore et encore, le problème n’est pas l’équipe — c’est l’absence d’investissement dans la prévention.
Former les nouveaux à l’astreinte
Section intitulée « Former les nouveaux à l’astreinte »L’astreinte ne s’improvise pas. Jeter quelqu’un dans le grand bain sans préparation, c’est garantir du stress, des erreurs, et potentiellement des incidents mal gérés.
Le shadowing progressif
Section intitulée « Le shadowing progressif »La méthode éprouvée est le shadowing : le nouveau membre observe puis prend progressivement les commandes.
La première semaine, le nouveau observe. Il reçoit les alertes en même temps que le primary, mais n’intervient pas. Il pose des questions, prend des notes, comprend les systèmes et les procédures. L’objectif est d’absorber le contexte sans la pression de la responsabilité.
La deuxième semaine, le nouveau prend les commandes sous supervision. Il est le premier à diagnostiquer, à proposer des actions, mais un membre expérimenté valide avant exécution. C’est le moment des erreurs sans conséquences — mieux vaut se tromper maintenant, sous filet de sécurité.
La troisième semaine, le nouveau est primary avec un secondary expérimenté en backup. Il gère les incidents de routine seul, mais sait qu’il peut escalader rapidement si quelque chose le dépasse.
Les exercices de simulation
Section intitulée « Les exercices de simulation »Google pratique la “Wheel of Misfortune” — une roue de la malchance où des incidents passés sont rejoués en conditions réalistes. Un “game master” choisit un scénario d’incident passé, l’équipe est alertée comme en vrai (pager, même heure simulée), la personne d’astreinte diagnostique et répond pendant que le game master simule les réponses du système. Ensuite, debrief : qu’est-ce qui a marché, qu’est-ce qui manquait, que faut-il améliorer ?
Ces exercices préparent aux incidents réels sans le risque d’impact production. Ils révèlent aussi les trous dans les runbooks et les compétences de l’équipe.
Le bien-être de l’astreinte
Section intitulée « Le bien-être de l’astreinte »L’astreinte, même bien conçue, a un impact sur le bien-être. Des pratiques protectrices sont nécessaires.
Éviter le burnout
Section intitulée « Éviter le burnout »Pas d’astreinte consécutive : au minimum une semaine off entre deux shifts. Le droit à la déconnexion hors astreinte doit être réel — pas de messages “au cas où”, pas de sollicitations informelles. Si le nombre d’incidents explose soudainement, c’est un signal d’alarme pour le management, pas un problème individuel.
Respecter le sommeil
Section intitulée « Respecter le sommeil »Le SLO détermine l’urgence réelle. Si votre SLO tolère 30 minutes de dégradation, la personne d’astreinte n’a pas besoin de répondre en 2 minutes. Un temps de réponse réaliste (15-30 minutes) permet de ne pas dormir avec le téléphone sous l’oreiller.
Les équipes réparties géographiquement peuvent pratiquer le “follow-the-sun” : l’équipe européenne couvre les heures européennes, l’équipe américaine prend le relais. Personne n’est jamais réveillé la nuit.
Support post-incident
Section intitulée « Support post-incident »Après un incident stressant — panne majeure, pression business, durée longue — la personne d’astreinte mérite du temps de récupération. Pas de réunions obligatoires le lendemain. Un debrief de soutien si l’incident était traumatisant. Une reconnaissance explicite de l’effort fourni.
Métriques d’une astreinte saine
Section intitulée « Métriques d’une astreinte saine »Comment savoir si votre astreinte est soutenable ? Voici les indicateurs clés à suivre :
| Métrique | Seuil sain | Seuil d’alerte | Pourquoi ça compte |
|---|---|---|---|
| Incidents / semaine | < 5 | > 10 | Charge permanente = burnout |
| MTTR (temps de résolution) | < 1h | > 2h | Runbooks incomplets ou systèmes trop complexes |
| % alertes actionnables | > 80% | < 50% | Confiance dans le système |
| Taux faux positifs | < 10% | > 25% | Réveils inutiles, perte de confiance |
| Score satisfaction | > 7/10 | < 5/10 | Soutenabilité perçue par l’équipe |
Ce qu’il faut retenir
Section intitulée « Ce qu’il faut retenir »L’astreinte est nécessaire pour les systèmes critiques, mais elle doit être soutenable pour les humains qui l’assurent.
Les principes fondamentaux sont simples : 25% maximum du temps d’un ingénieur en astreinte, 2 incidents maximum par shift de 12 heures, des alertes actionnables avec des runbooks à jour, une compensation juste pour la contrainte personnelle.
L’objectif n’est pas de supporter une astreinte difficile — c’est de la rendre légère. Chaque incident est une occasion d’améliorer le système pour qu’il n’y ait plus besoin d’intervention humaine.
La formation (shadowing, simulations) prépare les nouveaux. Le bien-être (repos, déconnexion, support) protège les anciens.
Une bonne astreinte est une astreinte ennuyeuse — peu d’alertes, résolutions rapides, nuits tranquilles. C’est le signe d’un système fiable et d’une équipe qui investit dans la bonne direction.