# Ce qu’un développeur doit garder sous la main pendant une garde serveur WordPress

> Accès, commandes et contacts à préparer avant de prendre une astreinte serveur WordPress, pour ne pas chercher un mot de passe à trois heures du matin.

- Auteur : WordPress Développement
- Publié le : 2020-10-27
- Mis à jour le : 2020-10-27
- Catégorie : Hébergement &amp; serveurs
- URL : https://www.wpmoderne.fr/hebergement/preparer-garde-serveur-wordpress-accents-commandes/

## L’essentiel

- Les accès doivent être testés avant la garde, jamais pendant
- Une fiche de commandes évite d'improviser sous pression
- Les contacts d'escalade doivent inclure hébergeur et registrar

Qui décroche si un site tombe à deux heures du matin, et avec quels accès ? C'est la question à laquelle une astreinte serveur bien préparée doit répondre avant même que le téléphone ne sonne. Une garde mal outillée transforme un incident de dix minutes en une nuit blanche passée à chercher un mot de passe ou à réveiller la mauvaise personne.

Préparer une garde WordPress ne se limite pas à noter un numéro de téléphone d'astreinte. Il s'agit de rassembler, tester et documenter en amont tout ce dont la personne de garde aura besoin, dans l'ordre où elle en aura besoin, pour intervenir sans dépendre de quelqu'un d'autre au milieu de la nuit.

## Les accès à vérifier avant, jamais pendant

Un accès qui fonctionne en journée peut échouer la nuit pour des raisons triviales : un jeton expiré, une clé SSH révoquée, un compte verrouillé après trop de tentatives. La règle la plus simple reste la plus efficace : la personne de garde teste elle-même chaque accès avant le début de son tour, pas seulement au moment de la crise.

- Accès SSH au serveur ou aux serveurs concernés, avec la bonne clé et le bon utilisateur
- Accès à la base de données MySQL ou MariaDB, en lecture et en écriture
- Accès au panneau de l'hébergeur, y compris le second facteur d'authentification
- Accès à la zone DNS du domaine, chez le registrar ou chez l'hébergeur DNS
- Accès au dépôt de code source, pour un déploiement d'urgence ou un rollback

## Une fiche de commandes prête à l'emploi

Sous pression, personne ne se souvient d'une syntaxe exacte. Une fiche de commandes, préparée à froid, évite l'improvisation et les fautes de frappe qui coûtent cher. Elle doit couvrir les gestes les plus fréquents : redémarrer un service, consulter les journaux récents, vérifier l'espace disque, désactiver une extension WordPress fautive.

```
systemctl status php7.4-fpm nginx mariadb
tail -n 200 /var/log/nginx/error.log
df -h
wp plugin list --status=active
wp plugin deactivate nom-extension
```

> L'essentiel à retenir : Les accès doivent être testés avant la garde, jamais pendant ; Une fiche de commandes évite d'improviser sous pression ; Les contacts d'escalade doivent inclure hébergeur et registrar

## Les contacts d'escalade, au-delà de l'équipe technique

Une astreinte bien pensée liste aussi les contacts qui ne dépendent pas de l'équipe elle-même : le support de l'hébergeur, avec le numéro de contrat sous la main, et le registrar du nom de domaine, dont l'intervention peut être nécessaire en cas de panne DNS ou de certificat expiré. Ces informations se périment vite si elles ne sont pas révisées régulièrement.

Il faut aussi prévoir un contact côté client ou côté produit, pour les décisions qui dépassent le strict cadre technique : faut-il afficher une page de maintenance, faut-il couper une fonctionnalité qui cause l'incident, faut-il prévenir les utilisateurs. La personne de garde ne doit jamais avoir à deviner qui a l'autorité pour trancher ce genre de question à trois heures du matin.

## Documenter l'état normal du site

Diagnostiquer une anomalie suppose de savoir à quoi ressemble la normale. Une fiche de référence, tenue à jour, doit indiquer le temps de réponse habituel des pages principales, le nombre de processus PHP-FPM généralement actifs, l'espace disque disponible en temps normal et la volumétrie de trafic attendue selon l'heure et le jour de la semaine.

> La meilleure astreinte que nous ayons préparée n'avait presque rien de spectaculaire : une page unique, avec les commandes, les accès et les contacts, mise à jour à chaque changement d'infrastructure.

Sans ce point de référence, un pic de charge normal peut être confondu avec une attaque, ou une lenteur habituelle peut masquer un vrai problème qui se développe en parallèle. La documentation de l'état normal est aussi précieuse que celle des procédures d'urgence elles-mêmes.

## Prévoir la sortie de crise, pas seulement l'entrée

Une astreinte efficace prépare aussi ce qui se passe après l'intervention : à qui transmettre l'information le lendemain matin, comment consigner ce qui s'est passé, et quelles actions correctives lancer pour éviter que l'incident ne se reproduise. Un incident traité en urgence sans compte-rendu écrit finit par se répéter, faute d'avoir été analysé à froid.

1. Noter l'heure de début et de fin de l'incident
2. Décrire les symptômes observés et les actions entreprises
3. Identifier la cause probable, même si elle reste à confirmer
4. Lister les actions correctives à planifier hors astreinte

## En résumé

Une garde serveur WordPress bien préparée repose sur trois piliers : des accès vérifiés à froid, une fiche de commandes prête à l'emploi et des contacts d'escalade à jour, hébergeur et registrar compris. Ce travail de préparation, souvent perçu comme secondaire, fait toute la différence entre une astreinte qui rassure et une astreinte qui angoisse.
