Une interface peut afficher une coche verte alors que l’archive est incomplète, chiffrée avec une clé introuvable, stockée dans le même compte que le site ou impossible à restaurer dans le délai attendu. Le mot « sauvegarde » décrit une copie. La reprise exige une procédure, des accès, un environnement et des contrôles.
Pour restaurer une sauvegarde WordPress, il faut réunir au minimum la base de données et les fichiers correspondant au même état, connaître la destination, protéger les secrets, reproduire les étapes dans un environnement isolé et vérifier les fonctions du site. Ce test doit être planifié avant l’incident.
Sommaire
Restaurer une sauvegarde WordPress : la réponse courte
Une politique de sauvegarde WordPress répond à six questions : quoi copier, à quelle fréquence, combien de temps conserver, où stocker, qui peut restaurer et comment prouver le résultat. La fréquence dépend du volume de modifications que le site peut accepter de perdre. Un blog mensuel, une boutique active et une plateforme de réservation n’ont pas le même risque.
La documentation officielle WordPress sur les sauvegardes distingue la base de données et les fichiers. La base contient notamment les contenus, réglages et comptes ; les fichiers contiennent les médias, thèmes, extensions et éléments de configuration. Une protection complète couvre les deux ensembles.
La preuve n’est pas le courriel « tâche terminée ». C’est un site restauré, accessible dans un environnement contrôlé, avec des contenus, médias, permaliens, comptes, formulaires et fonctions critiques vérifiés.
Principes qui restent valables
Trois principes n’ont pas changé. Premièrement, une copie unique sur le même espace que la production partage une partie de ses risques. Deuxièmement, une rétention d’un seul point peut conserver une erreur déjà propagée. Troisièmement, une procédure jamais exécutée contient presque toujours des hypothèses cachées.
Ce qui a évolué est l’automatisation. De nombreuses plateformes et extensions peuvent planifier des copies, les envoyer vers un stockage distinct, chiffrer les archives et proposer une restauration guidée. Cette commodité est utile, mais elle ne supprime pas les responsabilités : contrôler le périmètre, les accès, les notifications, la rétention et la restauration.
Pour restaurer une sauvegarde WordPress en 2026, l’équipe doit aussi considérer les services situés hors de WordPress : DNS, courriels transactionnels, moteur de recherche, stockage de médias, CDN, formulaires, paiement, dépôt de code et secrets de déploiement. Tous ne sont pas contenus dans une archive WordPress.
Cartographier ce qui doit être protégé
Commencez par l’inventaire fonctionnel, puis associez chaque fonction à ses données.
Base de données
La base contient les articles, pages, commentaires, utilisateurs, réglages, taxonomies et données enregistrées par les extensions. Une boutique y conserve aussi des commandes et états transactionnels. Sa fréquence de copie doit suivre le rythme des écritures, pas seulement celui des publications.
Fichiers
Incluez la médiathèque, les extensions, thèmes et fichiers personnalisés nécessaires. Le cœur WordPress peut souvent être téléchargé de nouveau, mais une copie complète facilite la cohérence et le diagnostic. Documentez les éléments qui sont reconstruits plutôt que sauvegardés, tels que certains caches temporaires.
Configuration et dépendances externes
Notez la version PHP attendue, les tâches planifiées, les services externes, les règles de domaine et les accès nécessaires. Ne publiez pas ces informations. Stockez-les dans une documentation protégée avec un propriétaire et une date de revue.
Code et actifs sources
Le thème développé sur mesure, les extensions privées, les fichiers sources et le pipeline de construction doivent vivre dans un dépôt contrôlé. Une copie de production ne remplace pas l’historique du code.
Définir la fréquence par la perte acceptable
Demandez combien de données l’organisation peut perdre après une panne. Si un blog reçoit un article par semaine et aucun commentaire, une copie quotidienne peut être largement suffisante. Si une boutique reçoit des commandes toute la journée, une base copiée une fois par nuit peut perdre une journée d’activité.
Séparez les rythmes lorsque cela aide : base fréquente, fichiers après téléversement ou changement, copie complète avant mise à jour et point de restauration avant migration. Évitez cependant une matrice si complexe que personne ne sait quel jeu utiliser.
Pour restaurer une sauvegarde WordPress, la base et les fichiers choisis doivent former un état compatible. Une base récente avec des médias trop anciens peut contenir des références vers des fichiers absents ; des fichiers récents avec une base ancienne peuvent laisser des éléments orphelins.
Concevoir une rétention utile
Conserver uniquement la dernière copie ne protège pas contre une erreur silencieuse découverte plusieurs jours plus tard. Définissez plusieurs points dans le temps : récents et rapprochés pour les erreurs immédiates, plus espacés pour les problèmes anciens.
La bonne rétention dépend du risque, du volume, des obligations et du coût. Documentez :
- fréquence des copies ;
- nombre de points conservés ;
- durée de conservation ;
- règle de suppression ;
- chiffrement ;
- contrôle d’intégrité ;
- destination ;
- procédure si le stockage devient indisponible.
Une archive ancienne peut contenir des données qui auraient dû être supprimées. Associez la rétention technique à la politique de confidentialité et aux obligations applicables, sans conserver indéfiniment « au cas où ».
Séparer les copies de la production
Une copie située uniquement dans le même compte, la même console ou le même espace peut devenir inaccessible avec le site. Conservez au moins une copie séparée selon les risques identifiés. Les droits de suppression de cette destination ne doivent pas être accordés automatiquement à tous les comptes capables de modifier le site.
Protégez les archives comme des données de production : elles peuvent contenir comptes, commandes, adresses, réglages et secrets. Utilisez le chiffrement approprié, des accès minimaux, une authentification forte et une trace des restaurations. Ne partagez pas une archive complète par un lien public.
La séparation ne doit pas être seulement géographique ou marketing. Vérifiez quel incident elle couvre réellement : erreur humaine, compte compromis, suppression, panne de stockage ou indisponibilité d’un fournisseur.
Préparer le test de restauration
Choisissez une destination isolée qui ne reçoit pas de trafic public et ne peut pas envoyer de vrais courriels, commandes ou appels. Réduisez ou protégez les données personnelles lorsque le test n’a pas besoin de leur valeur réelle.
Avant de restaurer une sauvegarde WordPress, réunissez :
- l’archive de base et de fichiers choisie ;
- les clés ou mots de passe nécessaires ;
- un environnement compatible ;
- la procédure d’import ;
- les responsabilités et contacts ;
- une checklist fonctionnelle ;
- une méthode de nettoyage après le test.
Notez l’heure de départ. Le temps de récupération inclut l’obtention des accès, le transfert, l’import, les corrections et la validation. Il ne se limite pas au temps d’extraction d’un fichier.
Restaurer la base et les fichiers
L’ordre exact dépend de l’outil et de la destination, mais la logique reste stable.
- Créez ou préparez une destination vide et protégée.
- Restaurez les fichiers nécessaires sans mélanger une ancienne installation avec des éléments inconnus.
- Importez la base de données correspondant au point choisi.
- Ajustez uniquement les paramètres nécessaires à la destination de test.
- Empêchez l’indexation et les sorties vers des services réels.
- Recréez les caches plutôt que de leur faire confiance.
- Ouvrez le site et l’administration.
La documentation de migration WordPress rappelle que fichiers et base doivent être déplacés ensemble et que les changements d’URL exigent des précautions. Les données sérialisées ne doivent pas être remplacées par une recherche textuelle naïve.
Pour restaurer une sauvegarde WordPress vers un autre domaine de test, utilisez une méthode compatible avec WordPress pour les URL et données sérialisées, puis vérifiez les valeurs du site, les permaliens et les redirections.
Vérifier le résultat
Commencez par l’intégrité visible, puis testez les fonctions.
- page d’accueil, article, page et archive ;
- images récentes et anciennes ;
- connexion administrateur ;
- rôles et comptes de service attendus ;
- permaliens et page 404 ;
- création et prévisualisation d’un brouillon ;
- formulaire avec destination de test ;
- recherche interne ;
- tâches planifiées ;
- API ou intégrations remplacées par des environnements de test ;
- panier, commande ou espace membre si présent ;
- sauvegarde d’un nouvel état restauré.
Comparez un échantillon de contenus et d’enregistrements avec le point choisi. Une page d’accueil correcte ne prouve pas que la médiathèque ou les données récentes sont complètes.
Restaurer un article n’est pas restaurer le site
Le système de révisions WordPress peut rétablir une version antérieure d’un article ou d’une page. Il est utile après une erreur éditoriale, mais ne remplace pas une sauvegarde de la base et des fichiers. Une révision ne récupère pas une extension supprimée, une base corrompue ou une médiathèque perdue.
De même, l’export XML de WordPress aide à transférer des contenus, mais ce n’est pas une image complète du site. Distinguez révision, export, copie de fichiers, sauvegarde de base et image complète de l’environnement.
Attribuer les responsabilités
Une procédure échoue souvent parce que chacun pense qu’une autre personne possède les accès. Créez une matrice simple.
| Étape | Responsable | Preuve attendue | |—|—|—| | Surveillance des tâches | Opérations éditoriales ou techniques | Notification examinée | | Contrôle des copies | Responsable désigné | Périmètre, date, taille cohérente | | Test de restauration | Technicien autorisé | Site de test et checklist | | Validation métier | Propriétaire du parcours | Formulaire, commande ou publication testés | | Décision de reprise | Responsable d’incident | Point choisi et impact accepté | | Nettoyage du test | Technicien autorisé | Données et accès retirés |
Prévoyez un remplaçant et une procédure d’accès d’urgence. Une seule personne ne doit pas être le seul moyen de récupérer un site.
Quand exécuter un exercice
Testez après la mise en place initiale, après un changement important d’outil, avant une migration, après une modification de structure et selon un calendrier lié au risque. Une boutique ou un service critique exige une fréquence différente d’un site vitrine peu modifié.
Variez les scénarios : restaurer le dernier point, revenir avant une mise à jour, récupérer un média supprimé, reconstruire dans une destination neuve et reprendre sans le service de sauvegarde habituel. Chaque exercice doit produire une amélioration de la documentation.
Pour restaurer une sauvegarde WordPress efficacement, chronométrez aussi les étapes humaines : trouver la bonne copie, obtenir une clé, identifier l’état, joindre un responsable et valider le site.
Erreurs fréquentes
- sauvegarder uniquement la base ou uniquement les fichiers ;
- stocker toutes les copies avec la production ;
- conserver un seul point ;
- ignorer les échecs de tâche ;
- ne jamais tester la clé de chiffrement ;
- réutiliser des données réelles dans un staging public ;
- confondre révision et sauvegarde ;
- restaurer sans bloquer les courriels ou paiements ;
- ne pas documenter les services externes ;
- promettre un délai sans l’avoir mesuré ;
- supprimer le dernier environnement stable avant la validation.
Checklist pour restaurer une sauvegarde WordPress
- [ ] Base de données et fichiers sont inclus.
- [ ] Le point de restauration correspond à la perte acceptable.
- [ ] Plusieurs dates sont conservées selon une politique documentée.
- [ ] Une copie reste séparée de la production.
- [ ] Les archives et clés sont protégées.
- [ ] Les notifications d’échec ont un destinataire.
- [ ] La destination de test est privée et n’émet pas vers les services réels.
- [ ] Les données personnelles de test sont réduites ou protégées.
- [ ] Les versions nécessaires sont connues sans être publiées.
- [ ] Les URL et données sérialisées sont traitées par une méthode compatible.
- [ ] Médias, permaliens, comptes, formulaires et tâches sont vérifiés.
- [ ] Les responsables et remplaçants sont nommés en interne.
- [ ] Le temps complet est mesuré.
- [ ] La documentation est corrigée après l’exercice.
- [ ] L’environnement de test est nettoyé.
Points clés à retenir
La technologie de sauvegarde a progressé depuis 2021, mais le critère de réussite reste inchangé : la restauration fonctionne-t-elle dans les conditions prévues ? Une copie sans procédure, accès, destination et test fournit un faux sentiment de sécurité.
Pour restaurer une sauvegarde WordPress, protégez ensemble base et fichiers, conservez plusieurs points, séparez au moins une copie, testez dans un environnement isolé et validez les fonctions réelles. Mesurez le temps et corrigez la procédure avant qu’une panne n’impose la réponse.
Le guide moderniser PHP sans casser WordPress montre comment intégrer ce test à une mise à niveau. Pour évaluer une plateforme avec des critères de sauvegarde et de restauration, utilisez aussi le guide Choisir un hébergement WordPress en 2026.