# Six mois d’astreinte partagée entre deux agences sur un même parc de serveurs WordPress > Retour d'expérience sur six mois d'astreinte mutualisée entre deux agences : répartition des responsabilités, frictions rencontrées et ajustements nécessaires. - Auteur : Clément Hadrot - Publié le : 2025-11-28 - Mis à jour le : 2025-11-28 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/six-mois-astreinte-partagee-deux-agences-parc-serveurs/ ## L’essentiel - Une astreinte partagée exige des plages de responsabilité écrites, pas orales - Le principal point de friction porte sur la définition d'un incident - Un rituel de passation hebdomadaire réduit la perte d'information Depuis juin dernier, deux agences se relaient sur l'astreinte d'un même parc de serveurs WordPress, chacune assurant une semaine sur deux. Six mois plus tard, le dispositif fonctionne, mais pas de la façon dont il avait été imaginé au départ. Ce billet ne parle pas de la facturation de cette astreinte partagée, un sujet distinct traité séparément, mais de ce qui a réellement posé problème dans la répartition des responsabilités techniques au quotidien. Le contexte est simple à décrire : un client historique de la première agence a élargi son parc de sites au point de justifier une astreinte permanente, mais sans volume suffisant pour qu'une seule agence l'assure seule sans épuiser son équipe. La solution retenue a consisté à faire intervenir une seconde agence, spécialisée sur un périmètre technique complémentaire, en alternance hebdomadaire. ## Ce qui avait été prévu au départ Le principe initial semblait clair sur le papier : chaque agence assure l'astreinte une semaine sur deux, avec un accès identique à l'ensemble du parc de serveurs, aux mêmes outils de supervision et à la même documentation d'infrastructure. La passation devait se faire par une simple notification écrite le lundi matin, indiquant quelle agence prend le relais. Dans les faits, cette description théorique a rapidement montré ses limites, notamment sur la définition même de ce qui constitue un incident nécessitant une intervention d'astreinte, une notion qui s'est révélée interprétée différemment par chaque équipe. ## Premier point de friction : la définition d'un incident La première agence considérait qu'une alerte de charge CPU élevée, sans impact visible côté visiteur, ne justifiait pas un réveil nocturne, mais une simple vérification le lendemain matin. La seconde agence, habituée à un contexte différent, traitait la même alerte comme un signal à investiguer immédiatement, par prudence. Cette différence d'appréciation a généré plusieurs interventions jugées excessives par l'une, et plusieurs absences d'intervention jugées risquées par l'autre. > L'essentiel à retenir : Une astreinte partagée exige des plages de responsabilité écrites, pas orales ; Le principal point de friction porte sur la définition d'un incident ; Un rituel de passation hebdomadaire réduit la perte d'information La solution a consisté à formaliser des seuils précis et partagés, documentés dans un fichier commun, plutôt que de laisser chaque astreinte appliquer son propre jugement. Un seuil de charge CPU supérieur à 90 % pendant plus de dix minutes déclenche désormais systématiquement une investigation, indépendamment de l'agence de garde cette semaine-là, ce qui a supprimé l'essentiel des divergences d'interprétation. ## Deuxième point de friction : la perte d'information entre deux astreintes Durant les deux premiers mois, cinq incidents ont été mal transmis d'une agence à l'autre : un correctif temporaire appliqué en urgence par une agence, sans documentation écrite, que la seconde agence a découvert par hasard la semaine suivante en investiguant un comportement qu'elle ne comprenait pas. Le correctif tenait, mais personne ne savait pourquoi il avait été appliqué ni s'il devait être pérennisé ou retiré. Ce point a nécessité l'instauration d'un rituel de passation hebdomadaire, chaque vendredi, sous forme d'une réunion courte de quinze minutes entre les deux astreintes sortante et entrante, complétée par un compte rendu écrit dans un outil partagé listant chaque intervention de la semaine, même mineure, avec son statut : résolue définitivement, contournée temporairement, ou à surveiller. ## Troisième point de friction : les accès et les outils Un problème plus technique est apparu autour des accès SSH : chaque agence utilisait initialement son propre compte système sur les serveurs, ce qui rendait difficile de savoir, après coup, quelle agence avait exécuté quelle commande lors d'un incident. La solution a consisté à conserver des comptes nominatifs par intervenant, mais à centraliser les journaux de connexion dans un outil de traçabilité commun aux deux agences, consultable indépendamment de qui a assuré l'astreinte cette semaine-là. ## Ce qui fonctionne bien aujourd'hui - Un document unique de seuils d'alerte, revu tous les trimestres par les deux agences ensemble, plutôt que par chacune séparément. - Une réunion de passation hebdomadaire courte mais systématique, jamais annulée même en l'absence d'incident notable. - Une traçabilité centralisée des interventions, indépendante de l'agence qui les a menées. > Une astreinte partagée entre deux structures distinctes ne fonctionne pas parce que les compétences techniques s'additionnent : elle fonctionne parce que la définition de l'incident et la passation d'information sont écrites, pas laissées à l'appréciation de chacun. ## En résumé Six mois de mutualisation d'astreinte entre deux agences ont montré que la difficulté ne se situe pas dans la répartition du temps de garde lui-même, mais dans l'alignement des critères d'intervention et la qualité de la transmission d'information d'une semaine à l'autre. Une fois ces deux points formalisés par écrit, le dispositif tient dans la durée sans générer de tension excessive entre les deux équipes.