La question que nous posons systématiquement lors d'une reprise de site tient en une phrase : si votre hébergement disparaissait ce soir, avec quoi remonteriez-vous le site demain matin ? La réponse la plus fréquente consiste à citer l'option de sauvegarde proposée par l'hébergeur, activée un jour dans une interface, jamais ouverte depuis. Cette réponse suffit dans un cas sur deux, celui de la fausse manipulation. Elle ne suffit pas dans les autres, et ce sont précisément ceux qui font perdre un site.
Une sauvegarde n'a de valeur que par sa restauration. Tant que personne n'a remonté le site à partir d'une copie, vous n'avez pas une sauvegarde, vous avez un fichier dont vous supposez le contenu. Nous appliquons ce principe sur les sites que nous suivons, en France comme en Suisse, quel que soit l'hébergeur.
Ce qu'une sauvegarde WordPress doit contenir pour être restaurable
Un site WordPress repose sur deux ensembles distincts, et une copie qui n'en contient qu'un seul ne permet pas de remonter quoi que ce soit.
Le premier ensemble regroupe les fichiers : le cœur du logiciel, le thème, les extensions, et surtout le répertoire wp-content/uploads qui contient l'intégralité de vos images et de vos documents. Les réglages d'un constructeur de pages comme Elementor, les fichiers de cache et les personnalisations du thème vivent également ici. Ce répertoire est de loin le plus lourd, et c'est celui que certains scripts de sauvegarde excluent pour gagner du temps.
Le second ensemble est la base de données, généralement en MySQL ou MariaDB. Elle contient le texte de vos pages et de vos articles, les commandes d'une boutique, les comptes utilisateurs, les réglages de chaque extension et les liens vers les médias. Un export de la base sans les fichiers vous rendra un site dont toutes les images sont cassées ; une archive de fichiers sans la base vous rendra une installation vierge.
Ces deux ensembles doivent en outre être cohérents entre eux, c'est-à-dire pris au même moment. Sur une boutique active, une base capturée trente minutes après les fichiers peut référencer des médias absents de l'archive. C'est un détail invisible tant que l'on ne restaure pas, et un problème concret le jour où on le fait.
Pourquoi la sauvegarde de l'hébergeur ne remplace pas la vôtre
Les hébergeurs sérieux, Infomaniak et OVH parmi d'autres, proposent des sauvegardes de qualité. Nous les utilisons, nous ne les dénigrons pas. Elles présentent simplement trois limites structurelles.
- Elles résident dans l'infrastructure de l'hébergeur. Si votre compte est suspendu à la suite d'un impayé, d'une compromission ou d'un litige, vous perdez l'accès au site et à ses copies au même instant.
- Elles suivent le site, y compris dans ses mauvais états. Un site compromis depuis trois semaines produit trois semaines de sauvegardes contenant le code injecté, et restaurer la copie de la veille revient à réinstaller le problème. C'est exactement la situation que nous décrivons dans reprendre la main sur un WordPress piraté.
- Leur profondeur de rétention est limitée et rarement documentée par le client. Beaucoup de contrats d'entrée de gamme conservent quelques jours, ce qui est insuffisant pour détecter une dégradation lente comme un contenu supprimé par erreur ou une injection discrète.
La logique est la même que celle que nous appliquons aux parcs informatiques et que nous détaillons dans vous faites des sauvegardes, cela ne suffit pas : une copie qui partage le sort de l'original n'est pas une copie de secours.
Où déposer les copies et pendant combien de temps les garder
Une sauvegarde utile se trouve chez un autre fournisseur que celui qui héberge le site, ou au minimum sur un stockage indépendant du serveur web, avec des identifiants qui ne sont pas ceux du site. Ce dernier point est important : si le site compromis détient les accès en écriture au stockage de sauvegarde, un attaquant peut effacer les copies. Nous privilégions donc un compte dédié, en écriture seule quand la plateforme le permet.
Sur la fréquence, nous raisonnons à partir d'une question simple : combien de contenu acceptez-vous de ressaisir ? Pour un site vitrine modifié quelques fois par an, une copie hebdomadaire complète est cohérente. Pour une boutique qui enregistre des commandes chaque jour, la base de données doit être capturée quotidiennement, faute de quoi la restauration efface des commandes réelles.
Sur la rétention, nous conservons plusieurs points de retour échelonnés plutôt qu'une seule copie récente. Garder une copie de chacun des sept derniers jours, une par semaine sur le mois écoulé et une par mois sur l'année permet de revenir avant une dégradation détectée tardivement. Ce principe de dispersion des copies rejoint la règle que nous appliquons aux serveurs et que nous expliquons dans la sauvegarde 3-2-1.
Une restauration se teste sur une copie, pas sur le site en ligne
Vérifier une sauvegarde ne consiste pas à constater que la tâche s'est terminée sans erreur. Nous contrôlons trois choses. D'abord que le fichier existe et que son poids est cohérent avec celui des semaines précédentes, car une archive qui passe brutalement de huit cents mégaoctets à deux mégaoctets signale une exclusion silencieuse. Ensuite que l'archive s'ouvre et contient bien les deux ensembles, fichiers et base. Enfin, périodiquement, que le site se remonte réellement.
Ce dernier test s'effectue sur un environnement de préproduction, c'est-à-dire une copie du site isolée du public, jamais directement sur le site en ligne. Nous y restaurons l'archive, nous ouvrons la page d'accueil, une page interne, un formulaire et, sur une boutique, une commande existante. C'est le seul moyen de découvrir qu'une extension nécessite une réactivation manuelle ou qu'une table de la base manquait, à un moment où cela n'a aucune conséquence. Le fonctionnement de cet environnement fait l'objet de notre article sur la préproduction WordPress.
Ce que nous mettons en place sous contrat de maintenance
Le contrat de maintenance WordPress à 500 HT / an, même chiffre en euros et en francs, comprend cette organisation. Nous établissons d'abord un inventaire : taille des fichiers, taille de la base, fréquence réelle de modification du contenu, dispositif de sauvegarde déjà en place. Nous en déduisons une fréquence et une rétention adaptées, puis nous configurons la copie vers un stockage extérieur au serveur web, avec un compte séparé.
Nous surveillons ensuite l'exécution des tâches et le volume produit, et nous procédons à une restauration de contrôle sur un clone. En cas d'incident, cette organisation change la nature de la conversation : au lieu de chercher ce qui peut être sauvé, nous choisissons une date de retour. À défaut de contrat, la reprise après compromission relève de l'urgence, facturée 230 HT / h, pour un résultat toujours moins bon que celui d'une restauration préparée.
Retenez qu'une sauvegarde WordPress se juge sur trois critères : elle contient les fichiers et la base pris ensemble, elle réside ailleurs que sur le serveur du site, et elle a déjà été restaurée au moins une fois. Si votre seule copie est celle de votre hébergeur et que vous ignorez ce qu'elle contient, demandez-nous une vérification. Nous vous dirons si elle permet un vrai retour en arrière ou s'il faut mettre en place une copie indépendante.