La Culture d'Astreinte Bien Faite : Réponse aux Incidents Sans Épuisement
L'astreinte est l'un des moyens les plus rapides de détruire le moral d'une équipe d'ingénierie si vous le faites mal. Et la plupart des entreprises le font mal.
Les symptômes sont prévisibles : les mêmes deux personnes reçoivent toujours les alertes parce que personne d'autre ne « connaît suffisamment le système ». Les ingénieurs redoutent leurs semaines d'astreinte. Les incidents se répètent parce que personne ne corrige les causes profondes. Les meilleurs ingénieurs partent et vous ne comprenez pas pourquoi votre rétention est terrible.
Construire une culture d'astreinte saine n'est pas compliqué. Cela nécessite une réflexion claire, quelques bons outils et un leadership qui traite l'astreinte comme une responsabilité de premier plan plutôt qu'une réflexion après coup.
SLAs vs. SLOs : Savoir Ce Que Vous Gérez Réellement
Avant de construire une rotation d'astreinte, vous devez savoir ce que vous défendez. Cela commence par comprendre la différence entre les SLA et les SLO, car la plupart des équipes les confondent.
SLA (Service Level Agreement) est un contrat avec vos clients. « Nous garantissons 99,9% de disponibilité. Si nous le violons, vous recevez des crédits de service. » Les SLA ont des conséquences légales et financières.
SLO (Service Level Objective) est un objectif interne plus strict que le SLA. Si votre SLA promet 99,9%, votre SLO pourrait cibler 99,95%. Le SLO vous donne une marge — un budget d'erreurs — avant de violer le SLA.
Si votre SLO est de 99,95% sur une fenêtre de 30 jours glissants, vous avez environ 21 minutes d'indisponibilité autorisée par mois. Quand vous êtes dans le budget, déployez des fonctionnalités agressivement. Quand vous le consommez, ralentissez et priorisez la fiabilité.
Pourquoi c'est important pour l'astreinte : vos ingénieurs d'astreinte doivent connaître les SLO qu'ils défendent et l'état actuel du budget d'erreurs. « Il nous reste 14 minutes de budget ce mois » crée de l'urgence. « Gardez le système en marche » est assez vague pour être sans sens.
Modèles de Rotation pour les Petites Équipes
L'erreur la plus courante avec l'astreinte est de la rendre trop lourde pour les individus. Voici ce qui fonctionne pour les équipes de 5-8 ingénieurs, la taille typique dans les startups :
Rotation hebdomadaire, un seul primaire. Une personne gère toutes les alertes pendant une semaine (du lundi au lundi). Simple et efficace avec suffisamment de personnes dans la rotation.
La rotation minimale viable est de 4 personnes. Moins de 4 signifie que chaque personne est d'astreinte plus de 25% du temps — insoutenable. À 5-6, vous obtenez un confortable rythme d'une semaine sur cinq.
Follow-the-sun pour les équipes distribuées. Les ingénieurs en Europe couvrent 08:00-20:00 CET, les Amériques couvrent le reste. Personne ne perd de sommeil. C'est l'un des vrais avantages des équipes distribuées.
Astreinte secondaire comme escalade. Si le primaire ne peut pas résoudre en 30-60 minutes, cela s'escalade au secondaire — quelqu'un avec une connaissance plus profonde du système. Faites tourner les deux rôles.
Règle absolue : la personne d'astreinte n'est pas censée faire le travail normal du sprint à la même capacité. Être d'astreinte signifie être interruptible. Si vous attendez aussi qu'ils ferment 8 story points, vous les configurez pour mal faire les deux.
La Base des Outils
Vous n'avez pas besoin d'un investissement massif en outils, mais vous avez besoin des bases :
Alertes et notifications : PagerDuty ou Opsgenie. Ils gèrent le routage des alertes, les politiques d'escalade, les plannings et les remplacements d'astreinte. PagerDuty est la norme du secteur. Opsgenie (maintenant partie d'Atlassian) est une alternative solide et moins chère. Ne comptez pas sur les notifications Slack ou les emails pour les alertes. Les gens réduisent Slack au silence. Les gens ratent les emails. Un appel téléphonique à 3h du matin de PagerDuty ne s'ignore pas.
Runbooks : Pour chaque alerte qui appelle quelqu'un, il devrait y avoir un runbook. Un runbook est un document qui répond à : Que signifie cette alerte ? Quelle est la cause probable ? Quelles sont les 3 premières choses à vérifier ? Comment l'atténuer ? Où sont les logs et les dashboards ? Un runbook transforme une session de panique de 45 minutes en un diagnostic de 10 minutes. Stockez-les dans votre wiki, liez-les directement dans l'alerte.
Page de statut : Statuspage (Atlassian), Instatus ou même une simple page statique. Quand quelque chose est en panne, vos clients devraient l'apprendre depuis votre page de statut, pas en essayant d'utiliser le produit et en échouant. L'ingénieur d'astreinte doit pouvoir mettre à jour la page de statut en moins d'une minute.
Canal d'incident : Un canal Slack dédié (ou équivalent) créé automatiquement pour chaque incident. Toute communication sur l'incident s'y passe. Pas de DM, pas de fils parallèles. Cela crée une chronologie automatique invaluable pour le postmortem.
Postmortems Sans Blâme : Comment en Faire un Vraiment
« Postmortem sans blâme » est devenu un mot à la mode que beaucoup d'équipes prétendent pratiquer et peu pratiquent réellement. Voici ce à quoi ça ressemble vraiment :
Timing : Dans les 48 heures après la résolution. Attendez une semaine et les gens oublient les détails.
Participants : Tous ceux impliqués dans l'incident, plus quiconque veut apprendre.
Structure :
- Reconstruction de la chronologie. Ce qui s'est passé, dans quel ordre, du premier signal à la résolution.
- Analyse de cause racine. Pas « qui a merdé » mais « qu'est-ce qui dans le système a permis que cela arrive ? » Une erreur humaine n'est jamais la cause racine — c'est le système qui l'a laissée atteindre la production.
- Facteurs contribuants. Qu'est-ce qui a ralenti la détection ? Qu'est-ce qui a rendu la résolution difficile ?
- Éléments d'action. Concrets, assignés, avec des dates limites. « Améliorer le monitoring » n'est pas un élément d'action. « Ajouter une alerte sur le taux d'erreurs de paiement dépassant 2% sur 5 minutes, assignée à Sofia, délai 15 septembre » en est un.
L'élément culturel critique : personne ne reçoit de punition pour les incidents. Si les gens craignent la faute, ils cachent de l'information. Si they cachent de l'information, vous ne pouvez pas apprendre. Si vous ne pouvez pas apprendre, les incidents se répètent.
Compenser l'Astreinte Correctement
C'est le combat que je mènerai toujours : si vous ne compensez pas les ingénieurs d'astreinte, vous n'avez pas une rotation — vous avez de l'exploitation.
Être d'astreinte contraint votre temps personnel. Vous ne pouvez pas partir camper sans réseau. Vous gardez votre laptop accessible. Prétendre que c'est « juste une partie du travail » est la façon de perdre vos meilleures personnes.
Modèles de compensation qui fonctionnent :
- Indemnité fixe par semaine d'astreinte. 200-500 EUR par semaine, que vous soyez alerté ou non.
- Prime par incident. Compensation supplémentaire pour les réponses réelles hors des heures de bureau.
- Temps libre compensatoire. Alerté à 3h pour 2 heures ? Demi-journée libre le lendemain. Non négociable.
- Combinaison. Indemnité + temps libre compensatoire est le modèle le plus courant et le plus équitable.
Ce qui compte, c'est que ce soit explicite, dans le contrat de travail et appliqué de manière cohérente.
Signes que Votre Culture d'Astreinte Est Brisée
Si l'un de ces éléments vous semble familier, vous avez du travail à faire :
- Les gens redoutent les semaines d'astreinte. Pas une légère irritation — une vraie appréhension. Ils en parlent dans les 1:1 et échangent des gardes constamment.
- La même personne reçoit toujours les alertes. Silo de connaissances ou alertes mal configurées — dans les deux cas, c'est insoutenable.
- Les incidents se répètent. La même panne toutes les quelques semaines. Les éléments d'action du postmortem ne sont jamais priorisés.
- Aucune compensation ni reconnaissance. L'astreinte est attendue mais invisible.
- L'astreinte est utilisée comme bizutage. Les nouveaux ingénieurs sont mis d'astreinte avant de comprendre le système.
- Il n'y a pas de runbooks. Chaque incident est une investigation fraîche depuis zéro.
Tout cela est réparable. Cela nécessite un leadership qui prend la santé opérationnelle aussi sérieusement que la livraison de fonctionnalités.
Chez Conectia, les ingénieurs senior que nous intégrons dans vos équipes ont vécu de bonnes cultures d'astreinte et de terribles. Ils apportent une maturité opérationnelle — rédigeant des runbooks, configurant des alertes appropriées, construisant l'automatisation qui prévient les incidents plutôt que de seulement y répondre. Quand votre équipe a des gens qui traitent la fiabilité en production comme un métier, l'astreinte cesse d'être un fardeau et devient une partie normale et bien gérée de la vie d'ingénierie.
Besoin d'ingénieurs qui construisent des systèmes fiables, pas juste des fonctionnalités ? Parlez à un CTO — nos ingénieurs senior LATAM apportent la maturité opérationnelle qui transforme l'astreinte d'une obligation redoutée en une pratique durable.
