14 mois d’astreinte à 5 développeurs — les 7 règles qui ont fait tomber nos réveils nocturnes de 11 à 2

Bryan

Expert delivery et équipes offshore · 3 septembre 2026 · 15 min de lecture

À cinq développeurs, une astreinte mal conçue ne produit pas de la fatigue répartie : elle produit deux démissions. Voici les sept règles que nous avons appliquées sur quatorze mois, dans l’ordre où elles doivent l’être. Les réveils nocturnes sont passés de 11 à 2 par mois — et ce n’est pas la première règle qui a fait le travail.

L’astreinte dans une petite équipe a un problème que les grandes n’ont pas : il n’y a personne derrière. À cinq développeurs, une rotation mal conçue ne produit pas de la fatigue répartie, elle produit deux démissions et un service qui n’est plus tenu.

Ce qui suit est ce que nous avons appliqué sur quatorze mois, dans l’ordre. Les réveils nocturnes sont passés de 11 à 2 par mois. La règle qui a produit l’essentiel de la baisse n’est pas la première — c’est la quatrième.

Étape 1 — Écrire ce que vous vous engagez à tenir, et surtout ce que vous ne tenez pas

Avant la rotation, avant l’outillage, il faut une phrase que tout le monde peut citer : quel service est tenu, à quelles heures, avec quel délai de prise en charge.

Le plus important est la seconde moitié : ce que vous ne tenez pas. Sans elle, tout devient urgent par défaut, et la personne d’astreinte se lève pour un tableau de bord interne cassé un dimanche.

Nous écrivons trois lignes. Ce qui est tenu 24 h sur 24. Ce qui est tenu en heures ouvrées uniquement. Ce qui attend lundi, quoi qu’il arrive. Faites relire cette liste par la personne qui répond aux clients : c’est elle qui saura si votre découpage est crédible.

Étape 2 — Construire la rotation à l’envers, en partant de ce qui est vivable

L’erreur classique consiste à partir du besoin de couverture et à diviser par le nombre de personnes. À cinq, cela donne une semaine sur cinq, ce qui paraît raisonnable sur un tableur et ne l’est pas dans une vie.

Partez de la contrainte inverse : combien de nuits perturbées une personne peut-elle absorber par mois sans que sa qualité de travail s’effondre ? D’expérience, la réponse est deux. Au-delà de trois, nous observons systématiquement une baisse de la qualité des revues de code dans les jours qui suivent.

Ce chiffre devient votre budget. S’il est incompatible avec votre couverture annoncée, ce n’est pas la rotation qu’il faut serrer : c’est l’engagement de l’étape 1 qu’il faut revoir, ou le bruit qu’il faut réduire — voir l’étape 4.

Deux règles pratiques : une semaine entière plutôt que des journées éclatées, parce que le coût mental est dans le fait d’être joignable, pas dans le nombre d’heures ; et jamais d’astreinte la semaine d’une mise en production majeure pour la personne qui l’a portée.

Étape 3 — Rendre l’escalade explicite avant d’en avoir besoin

À cinq, la question « qui j’appelle si je n’y arrive pas ? » n’a pas de réponse évidente, et elle se pose à trois heures du matin, au pire moment pour improviser.

Écrivez une chaîne courte et nominative : la personne d’astreinte, puis un second niveau désigné à l’avance pour la semaine, puis le responsable technique. Avec pour chacun un délai au bout duquel on passe au suivant — quinze minutes fonctionne bien.

Le point qui change tout est culturel : escalader doit être un comportement attendu, pas un aveu. Nous le formulons ainsi dans notre documentation : « au bout de quinze minutes sans piste, vous réveillez le niveau 2, ce n’est pas négociable ». Retirer la décision à l’individu retire la culpabilité.

Étape 4 — Alerter sur des symptômes, jamais sur des causes

C’est l’étape qui a produit l’essentiel de la baisse de 11 à 2. Elle est aussi celle que tout le monde repousse, parce qu’elle demande de supprimer des alertes que quelqu’un a écrites avec de bonnes intentions.

Une alerte sur une cause dit « le processeur dépasse 85 % depuis cinq minutes », « la mémoire dépasse 90 % », « la file d’attente dépasse 200 messages ». Le problème est que la moitié de ces états sont parfaitement normaux et n’affectent aucun utilisateur. Ils réveillent quelqu’un qui constate que tout va bien, puis se rendort mal.

Une alerte sur un symptôme dit « le taux d’erreurs 5xx dépasse 2 % », « la commande n’aboutit plus », « la latence au 95^e centile dépasse trois secondes ». Si ça sonne, quelqu’un souffre. Donc ça mérite un réveil.

La méthode de nettoyage est brutale et efficace : reprenez les alertes des trois derniers mois, et pour chacune posez une seule question — « un utilisateur s’en est-il aperçu ? ». Si la réponse est non deux fois sur trois, l’alerte passe en notification silencieuse consultable le matin. Nous avons supprimé 60 % de nos alertes ainsi, sans perdre un seul incident réel.

Étape 5 — Écrire les fiches d’intervention pendant la journée, pas pendant l’incident

Une alerte qui n’a pas de fiche associée est une alerte qui coûte trente minutes de plus. À cinq personnes, personne ne connaît tous les services : la personne d’astreinte tombera forcément sur un composant qu’elle n’a jamais touché.

Une fiche utile tient sur un écran et répond à quatre questions : qu’est-ce que cette alerte signifie en une phrase, quelle est la première vérification, quelle est l’action d’atténuation immédiate, et qui prévenir si ça ne marche pas.

Ce qu’il ne faut surtout pas y mettre : l’explication de l’architecture. La personne est fatiguée, elle a besoin d’une action, pas d’un cours. Le contexte se lit le lendemain.

La règle qui rend le système auto-entretenu : toute nouvelle alerte arrive avec sa fiche, sinon elle n’est pas déployée. C’est une contrainte de revue de code, pas une bonne intention.

Étape 6 — Faire un post-incident court, systématique et sans coupable

Les post-mortems meurent d’un excès d’ambition : un modèle de document de six pages garantit qu’aucun ne sera écrit. Nous utilisons quatre champs, quinze minutes maximum, dans les 48 heures.

Ce qui s’est passé, en trois phrases. Comment on l’a su — et si la réponse est « un client nous a écrit », c’est le vrai sujet du post-mortem. Ce qui a rallongé la résolution : fiche manquante, accès manquant, doute sur l’escalade. Une seule action, avec un nom et une date.

Une seule action, pas cinq. Une action réalisée vaut mieux qu’une liste exhaustive abandonnée. Et interdisez formellement le nom d’une personne dans la colonne des causes : la question n’est jamais « qui a fait l’erreur » mais « pourquoi le système a permis que l’erreur ait cet effet ».

Étape 7 — Compenser explicitement, et mesurer trois chiffres

L’astreinte est du travail. Une équipe qui la traite comme un service rendu à l’entreprise finit par la traiter comme facultative.

La compensation peut prendre plusieurs formes — forfait, récupération, les deux — et le montant importe moins que le fait qu’elle soit écrite et automatique. La règle qui compte le plus, et qui ne coûte rien : une nuit interrompue donne droit à une matinée, sans avoir à la demander. Devoir demander suffit à ce que personne ne prenne.

Enfin, trois indicateurs revus chaque trimestre. Le nombre de réveils hors heures ouvrées par personne, qui est le seul indicateur de soutenabilité. La part des alertes suivies d’une action réelle — en dessous de 50 %, votre problème est le bruit, pas la rotation. Et le délai entre le début de l’incident et sa détection, qui mesure si vous apprenez par vos sondes ou par vos clients.

Si vous montez une équipe et que ces sujets se posent, nos guides sur les outils métier sur mesure et sur le recours à des profils externes abordent la question du dimensionnement en amont. Sur le volet supervision et sécurité de la chaîne, les pratiques décrites par nos confrères en audit de sécurité se combinent bien avec cette approche, tandis que l’outillage d’automatisation permet de réduire la part des interventions manuelles.

Questions fréquentes