Skip to main content
Deux personnes restaurent une maquette de site à partir d’une boîte de sauvegarde contenant des fichiers et des données, puis vérifient qu’elle fonctionne.

Une sauvegarde WordPress ne suffit pas

Une sauvegarde WordPress peut sembler rassurante dans une interface d’hébergement ou d’extension. Mais tant que personne n’a vérifié son contenu et sa restauration, elle reste une promesse non testée.

Une sauvegarde n’a de valeur que si elle peut être restaurée rapidement et intégralement. Pour le vérifier, il faut examiner trois choses : ce qui est copié, où la copie est conservée et si elle permet réellement de remettre le site en état.

Deux éléments sont indispensables

Une restauration WordPress complète ne repose pas uniquement sur les fichiers du site. Elle nécessite généralement deux ensembles complémentaires :

  • Les fichiers : les fichiers WordPress, les médias envoyés dans la bibliothèque, le thème actif, les extensions et les fichiers de configuration utiles au fonctionnement du site.
  • La base de données : elle contient notamment les pages, les articles, les réglages, les comptes et une partie des données utilisées par les extensions.

Une copie des fichiers sans base de données peut laisser un site sans ses contenus ni ses réglages. À l’inverse, une base de données sans les fichiers correspondants ne suffit pas à retrouver les médias, le thème ou les extensions nécessaires. Un export de contenus n’est donc pas équivalent à une sauvegarde complète : il peut permettre de récupérer certains textes, mais pas nécessairement de remettre le site en ligne tel qu’il fonctionnait.

La liste exacte des éléments à inclure dépend de la configuration du site. Il faut au minimum savoir où se trouvent les fichiers, la base de données et les paramètres nécessaires à leur association. Si cette réponse dépend entièrement d’un prestataire ou d’un compte auquel l’équipe n’a pas accès, la sauvegarde est difficilement exploitable en autonomie.

La bonne fréquence dépend de ce que vous pouvez perdre

Un site vitrine rarement modifié, un site éditorial publié chaque semaine et une boutique qui enregistre des commandes n’ont pas le même niveau d’exigence. Appliquer la même fréquence à tous les sites n’a donc pas beaucoup de sens.

Commencez par une question concrète : quelle quantité de données récentes accepteriez-vous de perdre si le site devait être restauré ? Pour un site qui évolue peu, une sauvegarde après chaque changement important peut faire partie de la routine. Pour un site qui reçoit régulièrement des contenus, des demandes ou des commandes, les copies doivent suivre davantage son activité.

Cette décision doit aussi tenir compte des opérations à risque : mise à jour importante, modification du thème, changement d’extension ou intervention technique. Une sauvegarde réalisée avant une modification ne remplace pas une stratégie régulière, mais elle peut fournir un point de retour identifiable.

Une copie sur le même serveur n’est pas une vraie séparation

Si les sauvegardes sont stockées uniquement sur le serveur qui héberge le site, un incident touchant ce serveur peut aussi les rendre indisponibles. La copie doit être conservée dans un emplacement distinct du site principal, avec des accès connus et maîtrisés.

Évitez également de dépendre d’un seul compte ou d’un seul interlocuteur. L’équipe doit savoir :

  • où se trouvent les copies ;
  • qui peut y accéder ;
  • quel compte ou quelles informations sont nécessaires ;
  • comment récupérer une copie sans devoir retrouver un prestataire dans l’urgence.

Cette question relève de la continuité opérationnelle. Elle ne se confond pas avec la préparation d’un changement d’agence ou la récupération de ses accès, sujets traités dans le kit de réversibilité numérique. Dans les deux cas, toutefois, une information essentielle reste la même : une copie inutilisable ou inaccessible ne protège pas le site.

Les contrôles rapides à faire maintenant

Ouvrez l’historique des sauvegardes et vérifiez quelques éléments simples :

  • La date : la dernière copie correspond-elle au rythme réel d’activité du site ?
  • Le périmètre : les fichiers et la base de données sont-ils tous les deux présents ?
  • La taille : une variation inhabituelle ou une archive vide mérite-t-elle une vérification ?
  • L’historique : les exécutions précédentes ont-elles abouti ou certaines ont-elles échoué silencieusement ?
  • L’accès : une autre personne sait-elle retrouver et télécharger la copie ?

Ces contrôles donnent des indices, pas une preuve. Une archive qui porte une date récente et une taille cohérente peut malgré tout être incomplète ou impossible à restaurer. Le seul contrôle décisif consiste à essayer une restauration.

Le test qui tranche : restaurer hors production

Ne testez pas une sauvegarde directement sur le site en ligne. Utilisez une copie du site, un environnement de préproduction ou un domaine temporaire prévu pour ce type de vérification. L’objectif est de repartir d’une sauvegarde et de constater ce qui revient réellement.

Avant le test, protégez les données et les visiteurs :

  • utilisez une copie anonymisée lorsque c’est possible ;
  • restreignez l’accès à l’environnement de test ;
  • désactivez les envois sortants de formulaires et d’e-mails afin de ne pas contacter de vrais destinataires.

Une restauration réussie ne se limite pas à l’affichage de la page d’accueil. Vérifiez que :

  • le site est accessible ;
  • les pages et les articles attendus sont présents ;
  • les images et autres médias s’affichent ;
  • le thème et les fonctions essentielles se comportent normalement ;
  • les formulaires peuvent être contrôlés sans déclencher d’envoi réel ;
  • les fonctions importantes pour l’activité du site sont disponibles.

Notez la date du test, la sauvegarde utilisée et les problèmes rencontrés. Une restauration qui fonctionne aujourd’hui doit pouvoir être reproduite plus tard, par une autre personne si nécessaire.

La fiche de reprise à garder sous la main

Pour éviter de transformer une panne en recherche d’informations, consignez sur une fiche courte :

  • l’emplacement des sauvegardes ;
  • la date de la dernière copie considérée comme valide ;
  • les éléments inclus : fichiers, base de données et configuration nécessaire ;
  • les accès indispensables à l’hébergement, au stockage et au site ;
  • la procédure ou les étapes connues pour lancer une restauration ;
  • le nom de la personne qui sait effectuer ou piloter l’opération ;
  • le délai dans lequel une décision doit être prise en cas d’incident.

Si personne ne sait répondre à ces questions, vous avez peut-être des copies, mais pas encore une capacité de reprise vérifiée. La question utile n’est donc pas seulement « avons-nous une sauvegarde ? », mais plutôt : pouvons-nous restaurer une copie complète, récente et accessible, puis vérifier que le site fonctionne réellement ?

Cette page est générée par le template Breakdance