Apprendre WordPress
Une sauvegarde WordPress ne se résume pas à copier quelques fichiers sur un ordinateur. Un site repose sur deux ensembles complémentaires : les fichiers présents sur le serveur et la base de données. Pour restaurer le site dans un état cohérent, ces deux parties doivent être disponibles et suffisamment récentes.
Les fichiers contiennent le cœur de WordPress, les extensions, les thèmes, les médias téléversés et certains fichiers de configuration. Le dossier wp-content est particulièrement important, car il rassemble généralement les extensions, les thèmes et les fichiers envoyés depuis la médiathèque. Le fichier wp-config.php, lorsqu’il est inclus dans la procédure de sauvegarde, contient notamment les paramètres de connexion à la base de données. Il doit être manipulé avec une grande prudence.
La base de données conserve le contenu éditorial et une grande partie des réglages : articles, pages, catégories, comptes utilisateurs, commentaires, menus, widgets et options des extensions. Une copie des fichiers sans export de la base ne permet donc pas de récupérer les modifications récentes du contenu. À l’inverse, une base seule ne contient pas les images ni le code du thème.
Cette distinction permet de comprendre trois objectifs différents :
Une sauvegarde peut être utile après une erreur humaine, une mise à jour défaillante, une compromission, un problème d’hébergement ou une migration. Elle ne protège toutefois que si elle est accessible, intègre et exploitable dans une situation réelle.
La fréquence de sauvegarde doit correspondre à la fréquence des changements. Un site vitrine rarement modifié n’a pas les mêmes besoins qu’un site éditorial publié chaque jour ou qu’une boutique dont les commandes évoluent en permanence. Le bon repère consiste à se demander quelle quantité de données il serait acceptable de perdre après un incident.
Deux notions aident à cadrer cette décision :
Ces objectifs influencent le choix de l’outil, la fréquence des copies et le lieu de stockage. Une sauvegarde quotidienne peut convenir à certains sites, alors qu’un site très actif devra envisager des copies plus rapprochées de la base de données. Il faut aussi tenir compte des opérations sensibles : mise à niveau de WordPress, changement de thème, installation d’une extension, modification du serveur ou import massif de médias.
Une stratégie robuste sépare les sauvegardes des fichiers de production. Conserver une unique copie sur le même hébergement expose à sa perte en cas de panne, de suppression accidentelle ou de compromission du compte. Une copie locale chiffrée et une copie sur un stockage distinct peuvent compléter le dispositif. Les accès à ces emplacements doivent être protégés par des mots de passe uniques et, lorsque cette fonction existe, par une authentification multifacteur.
La conservation mérite également une règle claire. Garder uniquement la dernière sauvegarde peut enfermer dans une mauvaise version si une erreur n’est détectée qu’après plusieurs jours. Il est préférable de conserver plusieurs points dans le temps, avec une durée adaptée à l’activité du site et à l’espace disponible.
Plusieurs familles d’outils peuvent être utilisées. Aucun choix ne dispense de vérifier le contenu de la sauvegarde et de tester sa restauration.
| Approche | Éléments couverts | Atouts | Points de vigilance |
|---|---|---|---|
| Extension de sauvegarde | Fichiers, base de données ou les deux selon la configuration | Planification, archivage et restauration depuis l’administration | Consommation de ressources, stockage externe et compatibilité à contrôler |
| Outils de l’hébergement | Fichiers, bases et parfois instantanés du compte | Accès indépendant du tableau de bord WordPress | Rétention, périmètre exact et procédure de récupération variables |
| Export manuel | Fichiers via SFTP ou gestionnaire de fichiers, base via outil d’administration | Contrôle précis et absence de dépendance à une extension | Procédure plus technique et davantage exposée aux oublis |
| Outils en ligne de commande | Base et fichiers selon les commandes utilisées | Automatisation et efficacité sur les sites volumineux | Accès sécurisé au serveur et maîtrise des commandes nécessaires |
Une extension peut convenir à une personne qui souhaite planifier les copies depuis l’administration WordPress. Avant de l’installer, il faut vérifier sa compatibilité avec la version de WordPress, son mode de stockage, la possibilité d’exporter une archive lisible et la présence d’une procédure de restauration. Une extension de sécurité ou de mise en cache ne remplace pas nécessairement une solution de sauvegarde complète.
Les fonctions proposées par un hébergeur peuvent constituer un filet de sécurité utile. Elles ne doivent pas être confondues avec une copie indépendante si elles restent stockées sur la même infrastructure. La documentation du service doit préciser ce qui est capturé, la durée de conservation et la méthode de récupération.
La méthode manuelle demande davantage d’attention, mais elle permet d’identifier précisément les composants du site. Elle peut servir de secours avant une opération importante ou de solution lorsque le tableau de bord WordPress n’est plus accessible.
Un accès SFTP est préférable à un transfert FTP non chiffré. Depuis le répertoire racine de l’installation, téléchargez les fichiers vers un emplacement local réservé aux sauvegardes. Vérifiez la présence de wp-content, du fichier de configuration et des éventuels fichiers personnalisés situés à la racine.
Les fichiers temporaires et les caches peuvent parfois être exclus pour réduire le volume, mais cette décision doit être prise en connaissance de cause. Pour une première sauvegarde ou avant une migration, conserver une copie complète diminue le risque d’oubli. Notez le chemin d’origine et la date de la copie dans un fichier de suivi.
Depuis l’outil d’administration de la base fourni par l’hébergement, sélectionnez la base utilisée par WordPress, puis lancez un export au format SQL. Le nom de la base et le préfixe des tables peuvent être vérifiés dans wp-config.php. Ne publiez jamais ce fichier et ne le déposez pas dans un répertoire accessible par une adresse web.
Lors de l’export, les options de compatibilité proposées par l’outil doivent rester cohérentes avec le serveur de destination. Une archive compressée peut réduire l’espace nécessaire. Après l’opération, vérifiez que le fichier SQL existe, que sa taille n’est pas nulle et qu’il peut être ouvert avec un éditeur adapté ou réimporté dans un environnement de test.
Associez à chaque sauvegarde la date, la version de WordPress, les versions importantes du thème et des extensions, ainsi que l’adresse de l’environnement concerné. Cette documentation accélère le diagnostic lorsqu’il faut choisir une copie antérieure à une mise à jour.
L’automatisation réduit le risque d’oubli, mais elle peut aussi créer une fausse impression de sécurité. Une tâche planifiée peut échouer faute d’espace, de droits suffisants, de temps d’exécution ou de connexion au stockage distant. Le système doit donc signaler les erreurs et permettre une vérification régulière.
Lors de la configuration d’une extension ou d’un outil d’hébergement, contrôlez les points suivants :
Les sauvegardes automatiques doivent être déclenchées avant les changements à risque lorsque l’outil le permet. Une copie planifiée selon un calendrier ne remplace pas une copie ponctuelle juste avant une mise à jour majeure, une modification du thème ou une intervention sur la base.
Il est également pertinent de séparer le stockage des sauvegardes des comptes utilisés pour administrer WordPress. Si un compte compromis donne accès au site et à toutes ses archives, l’attaquant peut supprimer les moyens de récupération. Des droits limités, une authentification renforcée et une surveillance des connexions réduisent ce risque.
Une sauvegarde réussie dans un journal ne garantit pas que l’archive est exploitable. Après la première configuration, ouvrez l’archive et contrôlez sa structure. Pour une copie complète, vérifiez la présence des fichiers du site et d’un export de base exploitable. Si l’outil propose une somme de contrôle, conservez-la avec l’archive afin de détecter une altération lors d’un transfert.
La confidentialité est un enjeu important, car une sauvegarde peut contenir des adresses électroniques, des données de comptes, des réglages internes et des clés d’accès. Les archives doivent être stockées dans un emplacement protégé, avec un chiffrement lorsque le service ou l’outil le permet. Les fichiers de configuration et les exports SQL ne doivent pas être accessibles depuis le répertoire public du site.
Limitez aussi les droits d’accès au stockage. Une personne qui n’a pas besoin de restaurer le site ne devrait pas pouvoir télécharger l’intégralité des archives. Les anciennes copies doivent être supprimées selon une politique définie, en tenant compte des obligations de conservation applicables au site et à son activité.
Un contrôle périodique peut porter sur la date de la dernière sauvegarde, la taille de l’archive, le volume de stockage restant, le résultat de l’export SQL et la réception des alertes. Ces vérifications sont plus utiles lorsqu’elles sont inscrites dans une procédure récurrente plutôt que laissées à la mémoire de l’administrateur.
La restauration doit être conduite avec méthode. Avant toute action, identifiez la cause probable de l’incident et préservez l’état actuel du site lorsque cela est possible. Une copie réalisée après une compromission peut contenir des fichiers modifiés ou du code malveillant. Si le site reste accessible, placez-le en maintenance et empêchez les modifications concurrentes pendant l’opération.
Après un incident de sécurité, restaurer une archive ne clôt pas le problème. Les mots de passe des comptes WordPress, de l’hébergement, de la base de données, du SFTP et des services connectés doivent être renouvelés. Il faut également examiner les extensions et thèmes, supprimer les éléments inutiles et vérifier les journaux disponibles.
Lorsque l’administration WordPress ne répond plus, la restauration peut passer par l’hébergement, un accès SFTP et un outil de gestion de base de données. La procédure dépend de l’infrastructure, mais les principes restent identiques : sauvegarder l’état actuel, remettre les fichiers, importer la base, puis corriger la configuration.
Une extension de sauvegarde peut fournir un script ou une archive de récupération autonome. Ce type de mécanisme doit être conservé dans un emplacement sécurisé et supprimé dès que l’opération est terminée, car un fichier de restauration accessible publiquement pourrait permettre une prise de contrôle du site.
La ligne de commande peut aider sur un serveur administré avec rigueur. Des outils comme WP-CLI permettent d’exporter ou d’importer une base, de vérifier certains réglages et de gérer les extensions. Les commandes doivent être exécutées avec le bon utilisateur et sur le bon répertoire. Une erreur de chemin ou de base peut modifier un autre site hébergé sur le même serveur.
Pour une restauration sur un nouveau domaine, les anciennes adresses présentes dans la base peuvent encore pointer vers l’environnement précédent. Les remplacements doivent être réalisés avec un outil qui comprend les données sérialisées de WordPress. Une recherche et un remplacement textuels non adaptés peuvent endommager des réglages d’extensions ou des options stockées dans un format structuré.
Le test de restauration est le moyen le plus fiable de savoir si une sauvegarde répond réellement au besoin. Il peut être réalisé sur un environnement de préproduction, un serveur temporaire ou une installation locale suffisamment proche de la production. L’objectif n’est pas de modifier le site public, mais de reproduire la procédure avec une archive.
Le test doit vérifier les éléments fonctionnels et techniques :
Un environnement de test peut contenir des données personnelles. Il doit donc être protégé comme le site de production. Les envois de courriels et les paiements doivent être désactivés ou dirigés vers des services de test afin d’éviter une action réelle pendant la vérification.
Consignez la durée de la restauration, les difficultés rencontrées et les étapes nécessaires. Cette documentation devient un plan d’intervention. Elle permet aussi d’identifier les améliorations à apporter, par exemple une archive plus complète, un accès de secours ou une procédure de changement de DNS.
Plusieurs erreurs reviennent dans les incidents de récupération :
La meilleure procédure reste celle qui est écrite, testée et accessible aux personnes autorisées. En situation d’urgence, les décisions prises sous pression augmentent le risque d’écrasement ou de mauvaise archive.
Une routine de sauvegarde efficace tient dans une procédure compréhensible. Elle peut commencer par une sauvegarde complète avant chaque changement important, puis s’appuyer sur une planification adaptée à l’activité du site. Les copies doivent être envoyées vers un emplacement distinct, protégées et conservées selon une durée définie.
À intervalles réguliers, vérifiez la réussite des tâches, l’espace disponible et la présence des archives attendues. À intervalles plus espacés, effectuez une restauration de test. La fréquence dépend du niveau de risque et du coût d’une indisponibilité, mais l’absence de test pendant une longue période réduit fortement la confiance que l’on peut accorder au dispositif.
Le document de procédure peut contenir :
Cette organisation transforme la sauvegarde en véritable plan de continuité. Elle protège le contenu, mais aussi le temps nécessaire à la remise en ligne et la capacité à reprendre les opérations avec un minimum d’incertitude.
Non. Elle récupère les contenus et les réglages enregistrés dans la base, mais pas les images, les extensions, les thèmes ni les fichiers de configuration. Une sauvegarde complète doit associer la base et les fichiers nécessaires.
Elle peut constituer une protection utile, mais il faut vérifier son périmètre, sa durée de conservation, son emplacement et sa méthode de restauration. Une copie indépendante et un test périodique apportent une sécurité supplémentaire.
Une copie récente est fortement recommandée avant une mise à jour de WordPress, d’un thème ou d’une extension, surtout lorsque le changement touche des fonctions essentielles. Il faut aussi conserver les informations sur les versions installées afin de pouvoir choisir un point de retour cohérent.
Vérifiez les identifiants et le nom de la base dans le fichier de configuration, les droits de l’utilisateur, le préfixe des tables et la compatibilité du serveur. Travaillez sur une copie de l’archive et évitez de multiplier les imports sur la base de production sans comprendre l’erreur.
Elle aide à revenir à un état antérieur, mais ne prévient pas une intrusion et ne garantit pas que l’archive est saine. Après une compromission, il faut rechercher la cause, renouveler les accès, contrôler les fichiers et restaurer une copie dont l’intégrité est aussi fiable que possible.
