Recevoir chaque nuit un message « sauvegarde terminée » est rassurant. Ce message ne répond pourtant pas à la question décisive : combien de temps faudra-t-il pour remettre votre site WordPress en service, avec ses contenus et ses fonctions ? Une archive peut être incomplète, stockée au mauvais endroit ou impossible à restaurer avec les accès disponibles. Le bon contrôle consiste à reconstruire une copie isolée du site et à vérifier les usages qui comptent réellement pour votre activité.
Définir ce que vous cherchez à récupérer
Commencez par une liste des éléments dont la perte serait problématique : pages, médias, formulaires, commandes, réservations, comptes et réglages. Une vitrine rarement modifiée et une boutique active n’ont pas la même tolérance à la perte de données. Demandez combien de travail peut être ressaisi et quelles informations ne pourraient pas être reconstituées. Cette discussion permet de fixer une fréquence de sauvegarde fondée sur l’activité, plutôt que sur une option cochée par défaut.
Ajoutez les dépendances extérieures : gestion du domaine, DNS, service d’email, paiement, licences et stockage séparé. Elles ne sont pas nécessairement contenues dans la sauvegarde WordPress. Un site peut s’afficher correctement sans envoyer ses messages, ou sans pouvoir joindre son service de réservation. Consignez le propriétaire de chaque compte et la procédure d’accès d’urgence. Évitez que toutes les possibilités de récupération reposent sur une seule boîte email ou une personne absente.
Réunir fichiers et base de données
La documentation WordPress sur les sauvegardes distingue les fichiers et la base de données. Les fichiers portent notamment les extensions, thèmes et médias ; la base contient les contenus et de nombreux réglages. Pour reconstruire un site typique, les deux parties sont nécessaires. Télécharger uniquement le répertoire du site ne récupère généralement pas sa base, qui réside dans un système séparé.
Pour chaque sauvegarde, relevez la date, le périmètre, l’emplacement et la procédure de restauration. Vérifiez que les médias volumineux et les tables ajoutées par vos extensions sont inclus. Conservez une copie hors de l’environnement qui héberge le site : un incident sur ce compte ne doit pas rendre simultanément le site et sa seule sauvegarde inaccessibles. Limitez l’accès aux archives, car elles peuvent contenir des données de clients et des paramètres sensibles.
Créer un environnement de test sans effets réels
La restauration doit se faire dans un espace séparé, jamais en écrasant le site public pour « voir si cela marche ». Préparez un domaine de test protégé et une base distincte. Bloquez les envois d’emails, les prélèvements, les synchronisations commerciales et les tâches automatiques avant de lancer la copie. Une boutique dupliquée peut sinon contacter de vrais clients ou transmettre deux fois une opération à un outil externe.
Ne vous contentez pas d’une demande de non-indexation pour protéger cet environnement. Une authentification ou une restriction d’accès adaptée réduit le risque de consultation accidentelle. Utilisez des comptes de test et remplacez les identifiants de services externes par leurs équivalents de test lorsque cela existe. Notez les modifications spécifiques à la copie afin de ne pas les réappliquer au site public lors d’une intervention ultérieure.
Mesurer le temps avec honnêteté
Démarrez le chronomètre au moment où l’intervenant reçoit la demande de restauration. Incluez la recherche des accès, le téléchargement des archives, la préparation de l’hébergement et la recette. Mesurer uniquement le temps de décompression donne une estimation trompeuse. Relevez les attentes et les questions non résolues : ce sont souvent elles qui expliquent pourquoi une opération supposée rapide prend finalement une demi-journée.
Vérifier des parcours, pas seulement des pages
Une page d’accueil visible valide surtout le rendu initial. Préparez plutôt quelques parcours représentatifs. Sur un site de services : ouvrir une prestation, télécharger un document, envoyer une demande vers une adresse de test, puis retrouver cette demande dans l’outil prévu. Sur un site éditorial : se connecter, modifier un brouillon, prévisualiser un média et vérifier les liens internes. Chaque contrôle doit produire une observation explicite.
Pour une boutique, utilisez les moyens de paiement de test et vérifiez une commande, une variation de produit et son traitement administratif. Comparez les totaux d’objets importants avec ceux attendus à la date de l’archive. Une différence n’est pas forcément une erreur : elle peut correspondre à une activité postérieure. En revanche, elle doit être comprise avant de conclure que la restauration est complète et utilisable.
Préparer les mises à jour avec le même protocole
WordPress recommande de disposer de sauvegardes avant une mise à jour. Sa procédure de mise à niveau fournit les points de repère techniques. Votre procédure interne doit préciser les parcours à vérifier après le changement et le moment où un retour arrière devient préférable à une réparation. Cette décision doit être prise avant l’incident, quand l’équipe peut encore raisonner calmement.
Attention au retour de la base : remettre une archive ancienne peut supprimer des commandes ou demandes reçues depuis sa création. Sur un site transactionnel, le plan doit distinguer le retour du code et la récupération des nouvelles données. Un prestataire doit pouvoir expliquer cette distinction avec vos outils concrets. Une promesse de restauration « en un clic » ne décrit pas la manière dont les écritures récentes seront préservées.
Transformer l’essai en procédure transmissible
Rédigez un compte rendu court comprenant les archives utilisées, les accès nécessaires, les étapes suivies, la durée observée et les anomalies rencontrées. Associez chaque blocage à une action : renouveler un accès, inclure un dossier manquant, corriger une dépendance ou préciser un contrôle. Le document doit permettre à une autre personne compétente de reproduire l’essai sans demander où se trouve chaque information.
Fixez ensuite une nouvelle vérification après une évolution significative : changement d’hébergeur, extension de réservation, ajout d’une boutique ou externalisation des médias. Entre ces essais, surveillez les échecs de sauvegarde et la disponibilité du stockage. Un dispositif qui fonctionnait avant une modification importante peut devenir incomplet. Le maintien de la procédure fait partie de la maintenance du site, au même titre que les mises à jour.
Reconnaître une sauvegarde réellement utilisable
Vous disposez d’une preuve solide lorsque la copie restaurée fonctionne, que ses données correspondent à la date annoncée et que les étapes sont documentées. Vous connaissez aussi ce qui reste hors périmètre et le temps réellement nécessaire. Ce résultat vaut davantage qu’un grand nombre d’archives jamais ouvertes. Il aide à discuter sereinement des moyens de maintenance et du niveau de disponibilité attendu.
Notre page maintenance et reprise WordPress présente les interventions possibles sur un site existant. Pour organiser un essai de restauration, décrivez les fonctions critiques et l’hébergement via notre formulaire de contact, sans transmettre de mot de passe dans le message. Le premier livrable utile sera une procédure adaptée à votre site et accompagnée d’une recette concrète.
Pour approfondir : Refonte de site au Mans : que faut-il vraiment améliorer ?.
Pour approfondir : Refonte à Hennebont : préparer la migration de votre site.
