Une sauvegarde de site WordPress ne vaut que par la restauration qu'elle permet. Pour qu'elle vous sauve réellement, elle doit remplir trois conditions : être complète (les fichiers et la base de données), être stockée ailleurs que sur le serveur du site, et avoir été restaurée au moins une fois pour vérifier qu'elle fonctionne. Si l'une des trois manque, vous n'avez pas une sauvegarde : vous avez l'impression d'en avoir une.
La plupart des guides expliquent comment installer une extension de sauvegarde. Celui-ci parle de l'étape suivante, celle que presque personne ne fait : vérifier que le filet de sécurité existe vraiment. Parce que le jour où on en a besoin, il est trop tard pour le découvrir.
Le cas d'école : trois sauvegardes, aucune ne fonctionnait
En janvier 2017, un ingénieur de GitLab supprime par erreur le répertoire de données de la base sur le serveur principal au lieu du serveur secondaire. Environ 300 Go disparaissent. L'entreprise dispose alors de plusieurs dispositifs de secours. Aucun ne fonctionne : les exports de base de données ne s'exécutaient plus depuis des mois à cause d'une version d'outil incompatible, les instantanés de disque n'avaient jamais été activés, la réplication était cassée — et les emails d'alerte qui auraient dû signaler tout cela étaient rejetés par les serveurs de messagerie. Bilan : environ six heures de données perdues, et un rapport public remarquablement honnête.
Si une entreprise dont le métier est l'hébergement de code peut se retrouver dans cette situation, un site WordPress avec une extension installée il y a trois ans et jamais revérifiée n'a aucune raison d'être mieux loti. Ce qui est frappant dans cette histoire, ce n'est pas la panne : c'est que personne ne savait que les sauvegardes ne marchaient plus.
Les cinq façons dont une sauvegarde échoue en silence
Voici ce que je trouve le plus souvent en reprenant des sites existants.
| Le problème | Ce qui se passe le jour J |
|---|---|
| Seuls les fichiers sont sauvegardés, pas la base | Le site revient, mais sans articles, sans pages, sans commandes |
| La sauvegarde est stockée sur le même serveur | Serveur compromis ou perdu : la copie disparaît avec l'original |
| La tâche planifiée ne s'exécute plus | La dernière sauvegarde date de huit mois, et personne ne l'a vu |
| L'espace de stockage est saturé ou l'accès a expiré | Les sauvegardes échouent chaque nuit, en silence |
| Les emails d'alerte ne parviennent plus | Toutes les erreurs sont bien signalées… dans un dossier spam |
Le troisième point mérite une explication, parce qu'il est propre à WordPress : les tâches planifiées y dépendent des visites sur le site. Sur un site à faible trafic, elles peuvent ne jamais se déclencher à l'heure prévue, voire pas du tout. L'extension affiche une planification impeccable dans son écran de réglages, et ne sauvegarde rien.
Le cinquième renvoie à un sujet que j'ai déjà traité : si votre domaine n'est pas correctement authentifié, les notifications automatiques de votre site finissent en indésirables. C'est exactement ce qui s'est passé chez GitLab, et c'est le genre de défaut dont on ne mesure les conséquences que des mois plus tard — voir pourquoi vos emails partent en spam malgré SPF et DKIM.
La sauvegarde qui contient déjà le problème
Il existe un cas particulièrement cruel : la sauvegarde fonctionne parfaitement, mais elle contient l'infection. Quand un site est compromis, l'attaquant installe souvent des portes dérobées discrètes et attend. Pendant des semaines, le site paraît normal — et chaque sauvegarde nocturne enregistre fidèlement les fichiers malveillants.
Au moment où le piratage devient visible, restaurer « la sauvegarde d'avant » ne règle rien si la rétention ne remonte pas assez loin : vous réinstallez le même problème. C'est pour cette raison qu'une restauration ne dispense jamais de chercher la porte d'entrée, comme je l'explique dans le guide de nettoyage d'un site WordPress piraté.
Conséquence pratique : gardez un historique, pas seulement la dernière copie. Une rétention de trente jours, avec quelques copies mensuelles conservées plus longtemps, coûte peu et change tout le jour où vous devez remonter à avant l'infection.
La règle 3-2-1, traduite pour un site web
La règle classique en sauvegarde informatique tient en trois chiffres : 3 copies de vos données, sur 2 supports différents, dont 1 hors site. Pour un site WordPress, cela donne concrètement :
- Le site en production, qui est la copie de travail.
- Une sauvegarde automatique chez l'hébergeur, pratique et rapide à restaurer, mais qui vit sur la même infrastructure.
- Une sauvegarde indépendante envoyée ailleurs : espace de stockage distant, serveur tiers, ou une copie téléchargée régulièrement.
Beaucoup de sites s'arrêtent à la deuxième ligne. Les sauvegardes de l'hébergeur sont utiles, mais elles dépendent d'un seul acteur : si le compte est suspendu, si l'hébergeur a un incident, ou si vous changez de prestataire en urgence, elles ne vous appartiennent pas vraiment.
Le test de restauration : la seule preuve qui compte
C'est l'exercice qui transforme une intention en garantie. Il consiste à restaurer réellement la sauvegarde, ailleurs que sur le site de production, et à vérifier le résultat. Comptez une à deux heures la première fois.
- Créez un environnement séparé : un site de préproduction chez votre hébergeur, ou une installation locale sur votre ordinateur.
- Restaurez la sauvegarde la plus récente, fichiers et base de données, sans toucher au site en ligne.
- Vérifiez point par point : la page d'accueil s'affiche, vous pouvez vous connecter à l'administration, les articles et pages récents sont là, les images s'affichent, les formulaires s'envoient, et pour une boutique, les commandes récentes apparaissent.
- Notez le temps qu'il vous a fallu. C'est votre délai réel de remise en ligne. Si c'est une demi-journée, vous le saurez avant d'être en situation de crise, pas pendant.
- Écrivez la procédure, même en dix lignes : où sont les sauvegardes, avec quels accès, dans quel ordre restaurer. Un incident arrive rarement quand on est disponible et reposé.
Refaites ce test deux fois par an, et après chaque changement majeur : nouvel hébergeur, nouvelle extension de sauvegarde, refonte du site. C'est peu de travail au regard de ce que ça garantit.
À quelle fréquence sauvegarder ?
La bonne fréquence se déduit d'une seule question : combien de temps de travail acceptez-vous de perdre ?
| Type de site | Fréquence raisonnable | Ce que vous perdez au pire |
|---|---|---|
| Site vitrine, modifié rarement | Hebdomadaire, plus une copie avant chaque intervention | Quelques retouches |
| Blog publiant régulièrement | Quotidienne | Une journée de publication |
| Boutique en ligne | Quotidienne au minimum, base de données plus souvent | Des commandes réelles — à éviter absolument |
Pour une boutique, la base de données change en permanence : commandes, clients, stocks. Une sauvegarde quotidienne des fichiers suffit généralement, mais la base mérite un rythme plus soutenu, car ce sont des ventes qui disparaissent.
Les trois réflexes à prendre cette semaine
- Vérifiez la date de votre dernière sauvegarde réussie, pas la planification affichée. Si elle remonte à plus d'une semaine sur un site actif, vous avez trouvé votre urgence.
- Vérifiez où elle est stockée. Si la réponse est « sur le serveur », ajoutez une destination externe aujourd'hui.
- Programmez un test de restauration. Mettez-le dans votre agenda, sinon il n'arrivera jamais.
Si vous préférez déléguer ce travail, c'est typiquement ce que couvre un accompagnement technique régulier : sauvegardes vérifiées, restauration testée, mises à jour surveillées. Et si votre site a besoin d'être repris en main plus largement, cela fait partie de mes missions WordPress.
FAQ
Les sauvegardes de mon hébergeur suffisent-elles ?
Elles constituent un bon premier niveau, mais pas une protection complète : elles vivent sur la même infrastructure que votre site et dépendent d'un seul prestataire. Si le compte est suspendu, si l'hébergeur subit un incident ou si vous devez partir en urgence, vous perdez l'accès aux copies. Ajoutez toujours une sauvegarde indépendante, stockée ailleurs et sous votre contrôle.
À quelle fréquence tester une restauration ?
Deux fois par an pour un site classique, et systématiquement après un changement important : nouvel hébergeur, nouvelle extension de sauvegarde, refonte. Le test consiste à restaurer la sauvegarde sur un environnement séparé, à vérifier que le site, l'administration, les contenus récents et les formulaires fonctionnent, puis à noter le temps que l'opération a pris.
Que faire si le site est piraté et que la sauvegarde contient l'infection ?
Il faut remonter à une sauvegarde antérieure à la compromission, ce qui suppose d'avoir conservé un historique de plusieurs semaines. Si aucune copie saine n'existe, la restauration ne suffit pas : il faut nettoyer le site, supprimer les portes dérobées et corriger la faille d'origine, sans quoi l'infection reviendra quelques jours plus tard.
Je vérifie ce qui est réellement sauvegardé, je teste une restauration et je vous laisse une procédure écrite. Le premier rendez-vous est gratuit — on étudie votre besoin ensemble.
Démarrons votre projet ↗
Freelance expert No-Code, WordPress et Go High Level — 7 ans d'expérience, 100+ projets livrés pour des clients en France, au Canada et en Espagne.