Un site piraté, un serveur qui crashe, une mise à jour ratée : ce jour-là, la seule chose qui compte, c’est de pouvoir revenir en arrière. Sauf que la plupart des sauvegardes WordPress ne servent à rien, faute d’avoir été pensées comme un vrai plan de reprise. Fréquence adaptée, méthodes combinées, stockage externalisé et restauration testée : voici comment construire un système sur lequel on peut réellement compter le jour où tout part en vrille.
Définir sa fréquence de sauvegarde selon le type de site
Bon, une question revient souvent : à quelle fréquence sauvegarder son site WordPress ? La réponse honnête, c’est : ça dépend. Du volume de changements sur votre site, et surtout de la criticité des données. Perdre un article de blog publié il y a deux jours, c’est embêtant. Perdre 50 commandes clients avec paiement, c’est une autre paire de manches !
Ici intervient une notion utile à connaître : le RPO, ou Recovery Point Objective. Concrètement, c’est la quantité de données que vous acceptez de perdre en cas d’incident. Si votre dernière sauvegarde date d’hier soir et que le site plante ce matin, vous perdez tout ce qui s’est passé entre les deux. Plus ce délai est court, plus votre RPO est bon (et plus vous dormez tranquille).
La règle simple à retenir : plus la perte de données récentes coûte cher (en argent, en réputation, en temps perdu), plus la fréquence de sauvegarde doit être élevée. Voyons ça concrètement selon les types de sites.
Site vitrine ou blog peu mis à jour
Pour un site vitrine ou un blog qui publie quelques articles par mois, pas besoin de sortir l’artillerie lourde. Une sauvegarde hebdomadaire fait largement l’affaire dans la plupart des cas.
Je recommande néanmoins une sauvegarde ponctuelle avant chaque mise à jour importante : changement de thème, mise à jour majeure d’un plugin, ou modification de code. Ça ne prend que quelques minutes et ça évite bien des sueurs froides si quelque chose tourne mal. Pour ce type de site, l’enjeu principal reste la disponibilité (éviter que le site soit down), pas tant la fraîcheur absolue des données.
E-commerce et sites à fort trafic
Là, on change complètement de logique. Sur un e-commerce, chaque commande, chaque paiement, chaque mise à jour de stock a une valeur directe en euros. Perdre quelques heures de transactions peut représenter une perte financière réelle, sans parler du casse-tête pour retrouver quel client a payé quoi.
Ma préconisation : sauvegarder la base de données toutes les heures, voire en temps réel via un plugin dédié ou un système de réplication (certains hébergeurs proposent ça nativement). En complément, prévoyez une sauvegarde complète, fichiers et base de données confondus, une fois par jour. Ça permet de restaurer rapidement l’état exact du site, y compris les images produits ou les fichiers uploadés récemment. Pour les sites à fort trafic, cette fréquence élevée n’est pas du luxe, c’est une nécessité opérationnelle.
Sites avec contenu généré par les utilisateurs
Forums, sites avec avis clients, plateformes communautaires avec commentaires actifs : ici, le contenu généré par les utilisateurs change constamment, et souvent, on ne peut pas le recréer facilement (un commentaire perdu, c’est perdu pour de bon).
Je conseille donc de sauvegarder la base de données à intervalles rapprochés, toutes les 30 minutes à quelques heures selon l’activité réelle du site. Un forum très fréquenté n’a pas les mêmes besoins qu’un blog avec deux commentaires par semaine. L’idée, c’est d’observer le rythme de publication de vos utilisateurs et d’adapter la fréquence en conséquence : mieux vaut sauvegarder un peu trop souvent que de devoir annoncer à votre communauté que ses contributions ont disparu !
Choisir la bonne méthode de sauvegarde
Une fois la fréquence définie, reste la question de l’outil. Et là, on a l’embarras du choix : ligne de commande, plugin dédié, sauvegarde automatique côté hébergeur… Chaque méthode a ses forces et ses limites. Pas de solution miracle unique, mais plutôt une combinaison intelligente selon vos besoins et vos compétences techniques.
Solutions natives : WP-CLI et export manuel
Pour les utilisateurs à l’aise avec la ligne de commande, WP-CLI reste une valeur sûre. Léger, rapide, entièrement scriptable : c’est l’outil idéal pour automatiser des sauvegardes via cron sans dépendre d’un plugin.
Quelques commandes essentielles :
wp db export backup.sql: exporte la base de données dans un fichier SQLwp core download: retélécharge les fichiers core (utile en cas de restauration partielle)- Combiner avec un archivage manuel du dossier
wp-contentpour récupérer thèmes, plugins et médias
On peut aussi utiliser wp package pour étendre les fonctionnalités et automatiser l’export complet (fichiers + base) dans un seul script cron.
Avantages : rapidité d’exécution, aucune surcharge sur le site (pas de plugin actif en permanence), automatisation totale possible.
Limites : nécessite un accès SSH (donc un hébergement compatible), pas d’interface graphique, et une bonne connaissance des commandes shell. Pas franchement adapté aux débutants, mais redoutablement efficace pour qui maîtrise l’outil.
Plugins de sauvegarde dédiés
Pour la majorité des utilisateurs WordPress, les plugins de sauvegarde restent la solution la plus accessible. Ils offrent généralement une interface graphique claire et des fonctionnalités qu’on retrouve chez la plupart des solutions sérieuses du marché :
- Planification automatique : sauvegardes quotidiennes, hebdomadaires ou selon vos besoins
- Stockage externe : envoi automatique vers un espace cloud (Google Drive, Dropbox, ou un stockage S3 par exemple)
- Sauvegarde incrémentale : ne sauvegarde que les modifications depuis la dernière sauvegarde complète, ce qui allège considérablement le processus
- Notifications d’échec : alerte par email si la sauvegarde n’a pas pu s’exécuter correctement
Bon point : ces plugins simplifient énormément la restauration, souvent en un clic. Par contre, ils ajoutent une charge supplémentaire sur le serveur (surtout lors des sauvegardes complètes) et nécessitent une configuration initiale rigoureuse pour éviter les mauvaises surprises.
Sauvegardes côté hébergeur
De nombreux hébergeurs proposent des sauvegardes automatiques intégrées à leur offre. C’est pratique, transparent, et ça ne demande aucune configuration de votre part. Franchement, pour un site vitrine simple, ça peut suffire au quotidien.
Attention néanmoins à ne pas s’en contenter aveuglément. Ces sauvegardes dépendent entièrement du prestataire : si son infrastructure tombe (incendie, panne majeure, faillite), vos sauvegardes disparaissent avec le reste. La rétention est aussi souvent limitée dans le temps (7, 15 ou 30 jours selon les offres), ce qui peut poser problème si vous détectez un incident tardivement.
En clair : c’est un filet de sécurité appréciable, mais jamais une solution autosuffisante.
Combiner plusieurs méthodes pour plus de fiabilité
La règle d’or en matière de sauvegarde ? Ne jamais dépendre d’un seul point de défaillance. Un bon plan de reprise combine idéalement au moins deux méthodes indépendantes : par exemple, un plugin dédié pour les sauvegardes automatiques quotidiennes, associé à un export WP-CLI mensuel stocké sur un support totalement différent (disque externe, autre service cloud).
Ainsi, si votre hébergeur rencontre un problème ou si votre plugin échoue silencieusement, vous disposez toujours d’une copie de secours accessible. C’est un peu plus de travail à mettre en place au départ, mais ça change tout le jour où un incident survient réellement.
Stocker ses sauvegardes en dehors du serveur principal
On a beau avoir la meilleure stratégie de sauvegarde du monde (fréquence adaptée, méthode fiable), tout ça ne sert à rien si les fichiers restent stockés au même endroit que le site. C’est un peu comme garder le double de ses clés à l’intérieur de la maison qu’elles sont censées protéger : en cas de pépin, on perd les deux en même temps.
Pourquoi éviter de stocker les sauvegardes sur le même serveur
C’est LA règle de base, et pourtant elle est souvent négligée : ne jamais garder ses sauvegardes uniquement sur le serveur qui héberge le site. Pourquoi ? Parce qu’un serveur, ça tombe en panne, ça se fait pirater, et parfois on supprime accidentellement un dossier entier (ça arrive, même aux plus expérimentés).
Si vos sauvegardes vivent au même endroit que votre site, un incident serveur détruit les deux simultanément. Piratage avec suppression malveillante des fichiers, panne de disque dur, erreur humaine lors d’une manipulation… Dans tous ces cas, si la sauvegarde est locale, elle disparaît en même temps que le site. Donc autant dire qu’elle ne sert à rien.
La solution ? Externaliser systématiquement le stockage des sauvegardes, sur un support physiquement et logiquement distinct du serveur de production.
Stockage sur S3 ou équivalent compatible
Amazon S3 (ou ses alternatives compatibles comme Backblaze B2, Wasabi ou DigitalOcean Spaces) reste une solution solide pour externaliser ses sauvegardes WordPress. Le principe : un stockage objet, hautement durable (on parle de 99,999999999% de durabilité chez AWS), à un coût dérisoire pour quelques gigaoctets de données.
L’avantage principal, c’est la standardisation de l’API S3. Elle est supportée nativement par de nombreux plugins WordPress (UpdraftPlus, BackWPup) et par des scripts WP-CLI personnalisés. On peut donc automatiser l’envoi des sauvegardes sans réinventer la roue.
Pour la configuration, rien de sorcier : on crée un bucket dédié, on génère une paire de clés API avec des permissions restreintes (accès en écriture seule pour le serveur, par exemple), et on configure son plugin ou script avec ces identifiants. Petite précision entre parenthèses : évitez d’utiliser vos clés AWS « root », créez toujours un utilisateur IAM dédié avec des droits limités au strict nécessaire.
Réplication vers un second serveur ou VPS
Tout le monde n’a pas envie de dépendre d’un service cloud tiers, et c’est totalement compréhensible. Si vous préférez garder la main sur votre infrastructure, la réplication vers un second serveur ou VPS distinct est une alternative tout à fait valable.
Concrètement, on met en place une synchronisation automatisée via rsync (rapide, incrémental, économe en bande passante) ou via SFTP scripté. L’idée : le serveur principal génère la sauvegarde, puis un cron déclenche le transfert vers le serveur secondaire, hébergé chez un autre prestataire si possible (histoire de ne pas dépendre du même datacenter).
Cette méthode demande un peu plus de configuration initiale (clés SSH, scripts de synchronisation, gestion des erreurs), mais elle offre un contrôle total sur ses données. Et niveau coût, un petit VPS suffit largement pour stocker des archives compressées.
Pour retenir tout ça simplement, on utilise souvent la règle du « 3-2-1 » : 3 copies de vos données, sur 2 supports différents, dont 1 copie hors site. C’est simple, actionnable, et ça couvre la majorité des scénarios de sinistre. Que vous choisissiez S3 ou un second serveur, l’essentiel est de respecter ce principe.
Tester ses restaurations et réagir en cas d’incident
Une sauvegarde qu’on ne teste jamais, ce n’est pas une sauvegarde : c’est un pari. Combien d’admins WordPress découvrent, le jour où tout plante, que leur fichier de sauvegarde est corrompu, incomplet, ou tout simplement inutilisable ? Trop, malheureusement. Donc avant de se sentir tranquille avec sa stratégie de sauvegarde, il faut la mettre à l’épreuve. Concrètement.
Mettre en place une procédure de test de restauration régulière
L’idée est simple : restaurer, périodiquement, une sauvegarde sur un environnement qui n’est pas la production. Tous les trimestres, c’est un bon rythme pour la plupart des sites (à ajuster selon la criticité, évidemment). Plusieurs options s’offrent à vous :
- Local by Flywheel : rapide à mettre en place, idéal pour tester en local sans toucher au serveur.
- Docker : plus technique, mais reproductible et scriptable si vous voulez automatiser le process.
- Sous-domaine de test : pratique pour vérifier le comportement en conditions proches du réel (DNS, SSL, etc.).
Une fois la restauration effectuée, on vérifie trois choses : l’intégrité des fichiers (rien de manquant ou tronqué), le fonctionnement général du site (pages qui s’affichent, plugins actifs, thème correct), et la cohérence de la base de données (contenu à jour, pas d’erreurs SQL au chargement).
Documentez cette procédure ! Une checklist écrite, avec le temps nécessaire estimé (comptez 30 à 60 minutes selon la taille du site) et le nom de la personne responsable du test. Sans ça, ce test finit toujours par passer à la trappe, noyé dans les urgences du quotidien.
Check-list à suivre en cas d’incident réel
Le jour J, pas de place pour l’improvisation. Voici l’ordre des opérations à suivre :
- Isoler le site : activer le mode maintenance ou couper l’accès public, histoire d’éviter que le problème empire.
- Identifier la cause : piratage, erreur suite à une mise à jour, panne serveur ? Le diagnostic oriente la suite.
- Choisir la bonne sauvegarde : la plus récente et surtout la plus saine (une sauvegarde d’il y a 2 jours mais propre vaut mieux qu’une d’hier déjà compromise).
- Restaurer sur un environnement de test si possible, avant de toucher à la production. Ça évite d’empiler les erreurs.
- Vérifier le site après restauration : mêmes contrôles que lors des tests réguliers (fichiers, fonctionnement, base de données).
- Communiquer si nécessaire, notamment auprès des utilisateurs impactés (site e-commerce, espace membre, etc.).
- Analyser l’incident a posteriori : qu’est-ce qui a causé le problème, la stratégie de sauvegarde était-elle adaptée, faut-il resserrer la fréquence ou changer d’outil.
Bon, on ne va pas se mentir : gérer un incident, ça reste stressant, même avec un plan en poche. Mais la différence, elle se fait bien avant que le problème n’arrive. Une procédure testée et documentée, c’est ce qui transforme une panique de plusieurs heures en une restauration maîtrisée de quelques minutes.