Un backup WordPress bien pensé ne sert pas seulement à rassurer. Il vous permet de repartir vite après une mise à jour ratée, une extension défectueuse, une intrusion ou une simple erreur humaine. Je vais vous montrer ce qu’il faut vraiment sauvegarder, quelle méthode choisir selon votre site, à quelle fréquence le faire et comment vérifier qu’une restauration fonctionne réellement.
Les points clés à retenir avant de choisir une méthode
- Une sauvegarde utile contient toujours les fichiers et la base de données.
- La règle la plus robuste reste trois copies, sur deux supports différents, dont une hors site.
- Les sauvegardes automatiques sont pratiques, mais elles doivent être testées.
- Pour un site éditorial, une fréquence quotidienne ou hebdomadaire suffit souvent; pour une boutique, il faut descendre beaucoup plus bas.
- Conserver 3 à 5 versions récentes évite de remplacer une bonne sauvegarde par une copie déjà corrompue.
Ce qu’une sauvegarde complète doit vraiment contenir
Je distingue toujours deux blocs. Le premier, ce sont les fichiers du site: le cœur de WordPress, les thèmes, les extensions, les médias, le fichier wp-config.php et, selon les cas, .htaccess. Le second, c’est la base de données MySQL ou MariaDB, là où vivent les articles, les pages, les menus, les widgets, les réglages du thème et la plupart des paramètres des extensions.Une archive de fichiers sans base de données ne suffit pas. L’inverse non plus. Si vous perdez seulement l’un des deux, vous récupérez un site incomplet, parfois cassé, parfois vide de son contenu utile. C’est pour cela que je conseille de penser en termes de site complet, pas en termes de simple copie de répertoire.
- À sauvegarder systématiquement : fichiers du thème, plugins, médias, configuration, export de base de données.
- À ne pas négliger : les réglages spécifiques du thème et des extensions, souvent stockés dans la base.
- À relativiser : les fichiers du cœur WordPress peuvent être retéléchargés, mais je préfère quand même garder une copie cohérente de l’ensemble.
Quand cette base est claire, on peut comparer les méthodes sans se tromper sur ce qu’elles couvrent vraiment. C’est précisément ce duo que je compare ensuite aux autres approches, parce qu’un bon outil ne compense jamais une mauvaise couverture.
Les méthodes qui tiennent la route selon votre niveau de confort
Il existe plusieurs façons de faire une sauvegarde, mais toutes ne se valent pas. En pratique, j’en vois quatre qui reviennent souvent: le plugin dédié, la sauvegarde fournie par l’hébergeur, la méthode manuelle via SFTP et export SQL, et les snapshots ou points de restauration proposés par certaines plateformes d’hébergement géré.
| Méthode | Avantage principal | Limite principale | Je la recommande si |
|---|---|---|---|
| Plugin de sauvegarde | Automatisation simple, restauration souvent guidée, gestion centralisée | Dépendance à l’extension et à sa configuration | Vous voulez un dispositif accessible sans passer par le serveur |
| Sauvegarde de l’hébergeur | Pratique, parfois incluse dans l’offre, rapide à déclencher | Rétention et restauration parfois limitées, dépendance à la plateforme | Vous utilisez un hébergement géré avec un vrai historique de points de restauration |
| Méthode manuelle SFTP + base de données | Contrôle total, très portable, peu de dépendance logicielle | Plus lente, plus technique, plus exposée aux oublis | Vous voulez une copie d’urgence ou préparer une migration propre |
| Snapshot de plateforme | Retour arrière rapide sur un environnement précis | Souvent lié à un seul hébergeur ou à un seul environnement | Votre site tourne sur une infra gérée et vous avez besoin d’un rollback rapide |
Pour un site vitrine ou un blog, le plugin suffit souvent très bien, à condition de stocker les fichiers en dehors du serveur. Pour un site plus sensible, je préfère mixer les approches: un outil automatisé pour le quotidien, plus une copie manuelle ponctuelle avant une intervention lourde. Une fois la méthode choisie, la cadence et la rétention deviennent les vrais leviers.
La fréquence qui évite de perdre du contenu inutilement
La bonne cadence dépend du rythme de publication et du volume de changements. Un blog éditorial qui publie quelques fois par semaine n’a pas les mêmes besoins qu’une boutique WooCommerce qui enregistre des commandes toute la journée. En pratique, je raisonnerais ainsi.
| Type de site | Cadence minimale | Ce que je viserais en plus |
|---|---|---|
| Blog éditorial | Sauvegarde complète hebdomadaire, base de données quotidienne si le site bouge souvent | Une copie avant toute mise à jour majeure |
| Site vitrine actif | Sauvegarde complète hebdomadaire, base quotidienne si le contenu est modifié régulièrement | Une copie manuelle avant tout changement de thème ou de plugins |
| Boutique ou membership | Base de données très fréquente, idéalement horaire ou plus courte selon l’activité | Automatisation renforcée et test de restauration plus régulier |
La documentation officielle de WordPress recommande de conserver 3 à 5 sauvegardes récentes et de les répartir sur plusieurs emplacements. C’est une bonne règle de bon sens: garder plusieurs versions vous protège autant d’une panne que d’une copie déjà abîmée. Je garde aussi l’habitude de lancer une sauvegarde manuelle avant une mise à jour de cœur, d’extension ou de thème, parce que c’est exactement le moment où les problèmes apparaissent.
La règle 3-2-1, souvent résumée comme trois copies, sur deux supports différents, avec une copie hors site, reste un repère simple. Elle ne remplace pas la discipline, mais elle évite de tout mettre au même endroit. Reste le point que beaucoup repoussent à plus tard: la restauration réelle.
Tester la restauration avant que le problème n’arrive
Une sauvegarde n’a de valeur que si elle se restaure vite et proprement. J’insiste là-dessus, parce qu’un site peut afficher des archives impeccables et échouer au moment où il faut remonter la boutique, reconnecter les médias ou réimporter la base. Le bon réflexe consiste à tester la restauration sur un environnement de préproduction, ou au minimum sur une copie locale.
- Je restaure d’abord une version de test, jamais le site de production en premier.
- Je vérifie que les fichiers et la base sont cohérents entre eux.
- Je contrôle les pages clés, le menu, le formulaire de contact, les médias et la page d’accueil.
- Si le site vend quelque chose, je teste le tunnel de commande, le compte client et les e-mails transactionnels.
- Je vérifie enfin les permaliens, le cache et les éventuels réglages propres au thème ou aux extensions.
Je préfère un test mensuel de quinze minutes à une confiance abstraite dans un bouton “restaurer”. C’est aussi là qu’on repère les plugins qui exportent bien mais restaurent mal, ou les sauvegardes d’hébergeur qui exigent une procédure de support avant d’être utilisables. Une sauvegarde testée révèle vite la différence entre un vrai plan de reprise et un simple stockage de fichiers.
Les erreurs qui rendent une sauvegarde presque inutile
Les incidents sérieux viennent rarement d’un seul problème. Ils viennent surtout d’un dispositif mal pensé. La plupart des échecs que je vois tiennent à quelques erreurs répétées, faciles à corriger une fois qu’on les identifie.
- Tout stocker sur le même serveur que le site.
- Ne garder qu’une seule version, souvent la plus récente.
- Oublier la base de données ou le fichier wp-config.php.
- Faire confiance à une sauvegarde sans jamais l’ouvrir ni la tester.
- Penser que l’hébergeur couvre automatiquement tous les scénarios, alors que la rétention ou la restauration peut être limitée.
- Lancer une sauvegarde après une grosse mise à jour au lieu de la faire avant.
- Confondre archive et reprise d’activité: une archive existe, mais rien ne garantit qu’elle permet de repartir en quelques minutes.
Le vrai gain vient souvent de corrections très simples: séparer les emplacements, multiplier les versions, vérifier l’intégrité et documenter la procédure de restauration. Avec ces garde-fous, on peut bâtir un plan simple sans tomber dans la sur-ingénierie.
Le dispositif simple que je recommande pour la plupart des sites WordPress
Si je devais protéger un site WordPress sans multiplier les outils, je partirais sur un socle assez sobre. Une sauvegarde complète hebdomadaire, une sauvegarde de base de données plus fréquente si le site vit, une copie hors site sur un stockage distant, et un test de restauration régulier. Ce cadre couvre déjà l’essentiel sans rendre la maintenance pénible.- Une sauvegarde complète à intervalle fixe, au moins une fois par semaine pour la majorité des sites.
- Une sauvegarde de base de données quotidienne, voire horaire si les données changent vite.
- Une copie hors site sur cloud ou stockage externe, pour ne pas dépendre du même point de défaillance.
- Une restauration testée au moins une fois par mois, sur staging ou en local.
- Une copie manuelle avant toute opération sensible, comme un changement de thème, un gros lot d’extensions ou une migration.
Ce schéma reste assez souple pour un blog, un site vitrine ou une boutique modeste, et assez sérieux pour éviter les mauvaises surprises. Pour moi, une bonne stratégie de sauvegarde n’est pas celle qui promet tout; c’est celle qui permet de repartir proprement, sans improviser, le jour où le site tombe.
