Douze boutiques WooCommerce, six développeurs, soixante-douze heures à couvrir sans interruption : c’est le format que nous avons retenu en agence pour le week-end du Black Friday, après une première édition où l’astreinte reposait sur une seule personne disponible « en cas de souci ».
Cette première tentative avait mal vieilli au bout de dix-huit heures : fatigue de décision, alertes noyées dans un canal de discussion générique, et un correctif appliqué en urgence sur la mauvaise boutique parce que deux onglets de terminal se ressemblaient trop. L’édition suivante a donc été construite autour de rotations courtes et de seuils d’alerte écrits noir sur blanc avant le début de l’opération.
Découper l’astreinte en créneaux de quatre heures
Au-delà de quatre heures consécutives à surveiller des tableaux de bord et à réagir à des alertes, la qualité de décision baisse nettement, même chez des développeurs expérimentés. Nous avons donc découpé les soixante-douze heures en dix-huit créneaux, chacun couvert par un binôme : une personne en astreinte active sur les tableaux de bord, une seconde en astreinte de recours, joignable sous quinze minutes si le premier créneau doit remonter un incident.
Chaque changement de créneau démarre par un point de dix minutes, jamais sauté même à trois heures du matin, où la personne sortante transmet l’état des lieux : incidents en cours, correctifs appliqués, boutiques sous surveillance renforcée.
Des seuils d’alerte qui déclenchent une action, pas une notification
Le principal défaut de notre première astreinte tenait à des alertes qui informaient sans indiquer quoi faire. Nous avons reconstruit chaque seuil autour d’une action précise, documentée à l’avance :
- Taux d’erreur au paiement supérieur à 5 % sur dix minutes glissantes : vérifier en priorité le webhook du prestataire de paiement, avant toute autre hypothèse.
- File de commandes en attente de traitement dépassant deux cents éléments : identifier la boutique concernée et vérifier la charge du serveur de base de données avant d’agir sur le code.
- Temps de réponse moyen du tunnel d’achat supérieur à trois secondes sur cinq minutes : basculer la boutique concernée sur une page d’attente plutôt que de laisser le tunnel se dégrader silencieusement.
Chaque seuil renvoie vers une fiche courte, avec la commande ou l’action exacte à exécuter, plutôt que vers une longue procédure à relire sous pression.
Préparer l’astreinte une semaine avant, pas la veille
La semaine précédant le Black Friday, chaque boutique reçoit une revue courte : extensions à jour, clé d’API de paiement valide, seuils de stock cohérents avec les prévisions marketing, et surtout un accès de secours documenté pour chaque prestataire externe (hébergeur, passerelle de paiement, service d’e-mail transactionnel).
La checklist envoyée à chaque binôme
- Accès admin WordPress vérifié pour les deux membres du binôme
- Accès hébergeur (SSH, tableau de bord) testé la veille
- Numéro de support prioritaire du prestataire de paiement noté
- Procédure de bascule en mode maintenance testée sur un environnement de recette
- Liste des extensions récemment mises à jour, avec date de mise à jour
Cette checklist paraît excessive tant qu’aucun incident ne survient. Elle a pourtant permis, lors d’un incident réel sur une passerelle de paiement tierce en fin de nuit, de retrouver en moins de deux minutes le contact support prioritaire plutôt que de fouiller une boîte mail partagée.
Le rôle du binôme de recours
Le binôme de recours ne reste pas passif : il consulte en continu, sur un canal dédié distinct du canal d’astreinte active, les métriques agrégées des douze boutiques. Cette double lecture a permis, à deux reprises, de détecter un ralentissement progressif avant qu’il ne franchisse le seuil d’alerte automatique, simplement parce qu’un regard humain repérait une tendance que le seuil binaire ne captait pas encore.
Une astreinte qui ne prévoit qu’une personne réactive à des alertes automatiques finit toujours par être prise de vitesse par un problème progressif : la vigilance humaine en parallèle reste irremplaçable sur un pic commercial de cette ampleur.
Ce que nous changerions encore
Deux points restent perfectibles après cette édition : la documentation des correctifs appliqués en urgence manquait parfois de contexte pour l’équipe de développement qui reprend le lundi suivant, et le point de passation de dix minutes a parfois dépassé son créneau lors d’incidents en cours, retardant légèrement la relève.
En résumé
Ce format en créneaux courts, avec seuils d’alerte actionnables et checklist de préparation une semaine avant l’événement, a transformé une astreinte auparavant anxiogène en un dispositif prévisible. La rotation évite l’épuisement, et la documentation préalable évite de découvrir un accès manquant au pire moment. Le dimensionnement du serveur lui-même reste un sujet distinct, traité en amont avec l’hébergeur bien avant que l’astreinte ne commence.
