Votre site WordPress pendant les vacances : le protocole avant de partir

Vous fermez trois semaines en août. Votre site, lui, ne ferme pas : il continue de recevoir vos prospects, les robots de Google, et les tentatives d’intrusion. Voici le protocole qu’on déroule avant chaque départ, en sept points.

Le vrai risque de l’été pour un site WordPress n’est pas la panne elle-même, mais la panne que personne ne voit. Un incident qui démarre le 4 août et que vous découvrez le 25 coûte trois semaines de visiteurs perdus.

Le reste de l’année, un problème se voit vite. Un formulaire en panne, une page en erreur, un site qui rame : quelqu’un s’en aperçoit dans la journée. Vous consultez le site, un client appelle, les demandes arrivent. En août, cette vigilance s’arrête. Le bureau est fermé. Personne n’ouvre le tableau de bord. Et l’e-mail qui recevrait l’alerte répond « absent jusqu’au 25 ».

Le vrai risque de l’été, ce n’est pas la panne elle-même : en août, elle est aussi fréquente et aussi grave qu’en mars. Le risque, c’est la panne que personne ne voit. Celle qui démarre le 4 août et que vous découvrez le 25, après trois semaines de visiteurs perdus. Vos clients, eux, ne partent pas tous en même temps que vous. Et Google continue de passer.

Pendant vos congés, l’activité continue sur votre site WordPress : les attaques par rançongiciel se multiplient les jours fériés et week-ends (alerte FBI/CISA), WordPress 7.1 est annoncée le 19 août 2026, et les pannes silencieuses n’attendent pas la rentrée.

Trois faits, mesurables.

Les attaques choisissent les moments creux. Dès 2021, le FBI et la CISA (l’agence américaine de cybersécurité) alertaient officiellement sur une recrudescence d’attaques par rançongiciel à fort impact. Ces attaques frappent pendant les jours fériés et les week-ends : précisément « au moment où les bureaux sont normalement fermés ». Rien d’étonnant : un attaquant préfère opérer quand personne ne répond aux alertes. Trois semaines de congés offrent la même fenêtre, en plus large.

WordPress ne prend pas de congés. La version 7.1 est annoncée pour le 19 août 2026, en plein cœur de l’été. Les extensions, elles, publient leurs correctifs de sécurité chaque semaine, août compris. Un site laissé sans mise à jour pendant un mois accumule du retard exactement au moment où personne ne surveille.

Les pannes silencieuses n’attendent pas la rentrée. Fin juin, sur notre parc, la supervision a sonné un mardi à 7 h 15 : plusieurs sites tombés d’un coup. Le coupable ? Les sauvegardes d’un seul site, configurées pour une copie complète toutes les heures, sans règle de conservation : 606 archives, 101 Go, un disque plein à 100 %. Il y avait quelqu’un de garde ce matin-là : tout est rentré dans l’ordre dans la matinée. La même panne un 14 août, sur un site que personne ne surveille, aurait patienté jusqu’à la rentrée, sous les yeux de vos visiteurs.

Une panne d’août est une panne ordinaire : ce qui coûte cher, c’est sa durée, pas sa gravité. Elle s’aggrave par l’addition de deux absences : personne pour la voir, personne pour agir. Sans responsable désigné, le moindre pépin devient sérieux.

La cause racine des étés ratés n’est presque jamais technique. Une panne d’août est une panne ordinaire ; ce qui la rend coûteuse, c’est l’addition de deux absences : personne pour la voir, personne pour agir. Un site sans surveillance ni responsable désigné, c’est un patient dont personne n’est de garde. Le moindre pépin devient sérieux : pas par sa gravité, par sa durée.

Le protocole se déroule la semaine qui précède le départ, jamais la veille : mises à jour, sauvegardes testées, échéances vérifiées, formulaires, comptes sécurisés, surveillance et personne de garde. Les six premiers points réduisent la probabilité d’un incident ; le septième réduit sa durée.

À dérouler la semaine qui précède le départ. Pas la veille au soir : on y revient.

1. Mises à jour. WordPress, thème et extensions à jour à J-7, pour observer le comportement du site quelques jours ouvrés.
2. Sauvegardes. Une copie complète stockée hors du serveur, et un test de restauration réel. Vérifiez la règle de conservation : limitez le nombre d’archives gardées.
3. Échéances. Nom de domaine, certificat, hébergement : rien n’expire pendant l’absence, et la carte bancaire de renouvellement est valide.
4. Formulaires. Un envoi de test réel, et une réponse automatique qui annonce vos délais plutôt que le silence.
5. Comptes. Double authentification activée sur les comptes administrateurs, comptes inutilisés désactivés.
6. Surveillance. Un monitoring de disponibilité qui alerte un téléphone joignable, pas une boîte mail en réponse automatique.
7. La garde. Une personne nommée, capable d’agir, avec les accès nécessaires : hébergeur, agence ou prestataire.

Le point 7 est celui qui change tout. Les six premiers réduisent la probabilité d’un incident ; seul le septième réduit sa durée. Une alerte qui tombe dans une boîte mail que personne ne lit ne protège rien. Elle doit aboutir chez quelqu’un qui peut se connecter et intervenir.

Sources : alerte conjointe FBI / CISA sur les attaques pendant les jours fériés et week-ends (AA21-243A, août 2021) ; calendrier officiel des versions WordPress (roadmap wordpress.org) ; incident sauvegardes mesuré sur notre parc, juin 2026.