Dimanche, 2h47 du matin. Le téléphone vibre : "ALERTE CRITIQUE - Payment API". Après 45 minutes de tâtonnement sans runbook clair, vous réalisez que c'était un faux positif. Mercredi suivant, même alerte, même heure, mais cette fois c'est réel : épuisé par le réveil de dimanche, vous réagissez plus lentement.
Ce scénario n'est pas une fatalité. L'astreinte, ou on-call dans le vocabulaire anglo-saxon de l'industrie (la période durant laquelle un ingénieur reste joignable pour intervenir sur un incident de production), peut être soutenable, voire formatrice, si elle est bien conçue. Cette page s'adresse aux équipes qui gèrent déjà des services en production et veulent structurer leur garde : rotation, alertes, runbooks, compensation et bien-être, selon les principes codifiés par le SRE (Site Reliability Engineering) de Google.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Dimensionner une rotation d'astreinte selon la taille de votre équipe
- Filtrer les alertes pour ne garder que celles qui sont réellement actionnables
- Structurer un runbook efficace et un handoff sans perte d'information
- Calculer une compensation juste pour la contrainte d'astreinte
- Former les nouveaux arrivants par shadowing progressif
- Suivre les métriques qui indiquent si votre astreinte reste soutenable
Pourquoi l'astreinte (on-call) existe
Section intitulée « Pourquoi l'astreinte (on-call) 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 : coordonner la réponse quand plusieurs services interdépendants sont touchés, évaluer les risques d'un rollback aux effets de bord complexes, ou investiguer un problème jamais vu auparavant.
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 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 et documentées dans le SRE Book, consultable librement.
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 : rester disponible, sobre, à portée de son laptop a un coût psychologique qui s'accumule au fil des shifts.
Google recommande qu'une personne ne soit pas d'astreinte plus de 25 % du temps, avec au moins 50 % du temps consacré au travail d'ingénierie de fond. Concrètement, cela correspond à environ une semaine sur quatre en rotation classique. En dessous de ce seuil, la rotation reste soutenable ; au-dessus, la fatigue s'accumule et les erreurs se multiplient.
Pendant un shift (la période continue durant laquelle une personne assure la garde, généralement 8 à 12 heures), le nombre d'incidents devrait rester limité. La cible communément admise chez Google est de maximum 2 incidents actionnables 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 après coup.
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. Une alerte qui ne les remplit pas tous n'a rien à faire dans un système de pager : elle génère du bruit, use la vigilance de l'équipe, et finit par être ignorée.
| 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 compensatoire : quelques heures de récupération pour chaque nuit d'astreinte, par exemple. Google indique dans son SRE Book privilégier le temps-off-en-compensation ou une prime en numéraire, plafonnée à une proportion du salaire global. La plupart des organisations combinent les deux approches.
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 : elle ne repose jamais sur la bonne volonté ponctuelle d'un volontaire.
La taille de l'équipe détermine le rythme
Section intitulée « La taille de l'équipe détermine le rythme »Le rythme d'astreinte soutenable dépend directement du nombre de personnes disponibles pour tourner dans l'équipe. Une équipe trop petite retombe trop souvent en astreinte, sans marge pour les absences ou les imprévus.
| 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.
Certaines organisations distribuées sur plusieurs fuseaux horaires adoptent un modèle follow-the-sun : chaque site couvre ses heures de bureau locales, et personne n'est jamais réveillé la nuit. Ce modèle demande au minimum trois équipes réparties sur des fuseaux éloignés pour couvrir 24 heures sans creux, ce qui le réserve aux organisations d'une certaine taille.
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 (soldes, 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é, même après un shift totalement calme : un handoff écrit, même bref, vaut mieux qu'aucun.
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, pas juste un problème à refermer.
É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 : c'est cette confiance, plus que le volume d'alertes lui-même, qui détermine si l'astreinte est vécue comme soutenable.
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 sont ce qu'on appelle du toil en SRE : du travail manuel, répétitif, automatisable, qui n'apporte pas de valeur durable. Notre guide sur éliminer le toil détaille comment l'identifier et le réduire méthodiquement.
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.
Depuis 2025, une nouvelle couche d'outils s'ajoute à cette automatisation : des plateformes d'observabilité intègrent des agents d'IA de triage qui enrichissent une alerte, avec les logs, traces et déploiements récents corrélés, avant qu'elle n'atteigne un humain. Cela réduit le temps passé à rassembler du contexte en début d'incident. Ces outils restent jeunes : ils demandent une supervision humaine explicite et ne dispensent pas d'avoir des runbooks solides ni des alertes bien filtrées en amont, ce sont des compléments, pas des remplacements.
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 plutôt qu'un contournement répété.
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, sur un rythme qui laisse le temps d'absorber le contexte avant d'endosser la responsabilité.
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 (la roue de la malchance), un exercice 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 vient le 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, souvent avant qu'un vrai incident ne les révèle de la pire manière possible.
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, et elles relèvent de la responsabilité du management autant que de l'individu.
É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 à absorber en silence.
Les enquêtes menées régulièrement auprès des équipes SRE convergent sur un point : l'alerte non actionnable et le manque de récupération après un incident stressant sont les deux premiers facteurs cités de fatigue et d'attrition sur les rotations d'astreinte. Traiter ces deux points en priorité rapporte plus, en rétention d'équipe, que n'importe quelle prime.
Respecter le sommeil
Section intitulée « Respecter le sommeil »Le SLO (Service Level Objective, l'objectif de niveau de service qui fixe la marge de dégradation tolérée avant qu'elle ne devienne inacceptable) détermine l'urgence réelle. Notre guide SLO, SLI et Error Budgets explique comment le définir correctement. 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 décrit plus haut pour garantir qu'aucune personne n'est réveillée la nuit, à condition d'avoir la taille d'organisation nécessaire pour couvrir les trois grands fuseaux horaires.
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, qui ne coûte rien et change beaucoup dans la perception de la charge.
Métriques d'une astreinte saine
Section intitulée « Métriques d'une astreinte saine »Comment savoir si votre astreinte est soutenable ? Suivre ces indicateurs clés dans le temps permet de détecter une dérive avant qu'elle ne se traduise par des départs.
| 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 de faux positifs | < 10 % | > 25 % | Réveils inutiles, perte de confiance |
| Score de satisfaction | > 7/10 | < 5/10 | Soutenabilité perçue par l'équipe |
À retenir
Section intitulée « À retenir »- L'astreinte est nécessaire pour les systèmes critiques, mais elle doit être soutenable pour les humains qui l'assurent.
- 25 % maximum du temps d'un ingénieur en astreinte, avec au moins 50 % consacré au travail d'ingénierie de fond.
- 2 incidents maximum par shift de 12 heures : au-delà, le problème est le système, pas l'équipe.
- Chaque alerte doit être actionnable, basée sur les symptômes, non redondante et vraiment urgente.
- Des runbooks à jour, testés, avec diagnostic rapide et critères d'escalade explicites.
- Une compensation juste pour la contrainte personnelle, mais la vraie priorité reste une charge légère.
- La formation (shadowing, simulations type Wheel of Misfortune) prépare les nouveaux sans les jeter dans l'inconnu.
- Le bien-être (repos, déconnexion, support post-incident) protège les équipes déjà en poste.
- L'IA de triage aide à enrichir le contexte d'une alerte, mais ne remplace ni les runbooks ni le jugement humain.
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.