Si vous avez déjà eu un écran blanc après une mise à jour, vous savez pourquoi une sauvegarde manuelle “qui marche vraiment” vaut de l’or. WordPress 6.9.4 est stable, mais un plugin, une mauvaise manipulation FTP ou une base de données corrompue peuvent suffire à tout bloquer.
Ce qu’on va construire
Vous allez mettre en place une sauvegarde manuelle complète d’un site WordPress (WordPress 6.9.4, PHP 8.1+), composée de deux éléments :
- La base de données (vos contenus, réglages, utilisateurs, menus, liens, etc.)
- Les fichiers (thèmes, plugins, médias, fichiers de configuration)
C’est destiné aux blogueurs (site vitrine, blog, petit e-commerce) qui veulent une sauvegarde “hors plugin”, utilisable même si l’administration WordPress ne répond plus.
À la fin, vous saurez :
- Identifier précisément quoi sauvegarder (et ce qui est optionnel).
- Exporter la base proprement (sans se retrouver avec un fichier SQL inutilisable).
- Récupérer les fichiers essentiels via FTP/SFTP ou cPanel.
- Vérifier votre sauvegarde et la tester sur un environnement de test.
Résumé rapide
- Une sauvegarde WordPress = base de données + fichiers. Sans l’un des deux, la restauration est incomplète.
- La base se sauvegarde via phpMyAdmin (export SQL), ou via l’outil DB du panneau d’hébergement.
- Les fichiers à prioriser : wp-content/ + wp-config.php (le cœur WordPress peut être réinstallé).
- Vérifiez votre sauvegarde : taille cohérente, archive lisible, SQL non vide, et test de restauration.
- Stockez une copie hors serveur (ordinateur + cloud), sinon un piratage/incident serveur détruit tout.
Quand utiliser cette solution
- Votre site est instable et vous ne faites plus confiance aux plugins de sauvegarde.
- Vous migrez vers un nouvel hébergeur et vous voulez comprendre ce que vous transférez.
- Vous allez faire une opération risquée : mise à jour majeure, changement de thème, refonte Divi/Elementor, nettoyage de base.
- Vous voulez une sauvegarde “de survie” quand l’admin est inaccessible (erreur 500, boucle de redirection, fatal error).
Quand ne PAS utiliser cette solution
- Vous cherchez des sauvegardes automatiques et incrémentales (quotidiennes, avec rétention). Le manuel ne remplace pas une stratégie.
- Vous gérez un gros site (médias énormes, base de plusieurs Go) : vous risquez des exports qui time-out. Il faut des outils serveur (SSH, mysqldump, rsync) ou une solution pro.
- Vous êtes en hébergement mutualisé très limité et phpMyAdmin coupe les exports volumineux : privilégiez un plugin sérieux ou une méthode SSH si disponible.
Avant de commencer (prérequis)
Avant toute manipulation, faites une règle simple : ne testez jamais “en direct” sans sauvegarde existante. J’ai souvent vu des sites cassés parce que la personne “allait faire la sauvegarde après la mise à jour”.
Prérequis techniques
- WordPress : 6.9.4 (ou plus récent).
- PHP : 8.1 minimum recommandé (cible de ce tutoriel).
- Accès hébergement : cPanel/Plesk/Manager équivalent, et idéalement phpMyAdmin.
- Accès FTP/SFTP : via FileZilla, Cyberduck, ou le gestionnaire de fichiers de l’hébergeur.
- Thème enfant activé (si vous avez déjà des personnalisations). Ce n’est pas obligatoire pour la sauvegarde, mais c’est un marqueur important à vérifier.
Termes à connaître (simplement)
- Base de données : un “grand tableau” qui stocke vos articles, pages, réglages, utilisateurs. WordPress utilise MySQL/MariaDB.
- Fichiers : tout ce qui est sur le serveur (images, plugins, thèmes, fichiers de config).
- FTP/SFTP : protocole de transfert. SFTP (via SSH) est à privilégier : plus sûr.
- phpMyAdmin : interface web pour gérer la base MySQL (export/import).
Précautions de sécurité
- Ne modifiez jamais le core WordPress (fichiers de WordPress) “pour aider la sauvegarde”. On ne touche pas au cœur.
- Votre fichier wp-config.php et votre export SQL contiennent des informations sensibles (noms de base, parfois chemins, parfois emails). Stockez-les comme des données privées.
- Évitez d’envoyer un SQL par email. Préférez un stockage chiffré (zip avec mot de passe + cloud).
Résultat attendu à la fin de cette section
Vous avez : vos identifiants d’hébergement, un client FTP/SFTP installé, et un dossier sur votre ordinateur nommé par exemple backup-wp-2026-04-06.
Étape 1 : Faire l’inventaire (ce qui doit être sauvegardé)
Une sauvegarde WordPress exploitable, c’est :
- Base de données : 1 fichier
.sql(souvent compressé en.zipou.gz). - Fichiers : une archive ou un dossier complet du site (ou au minimum des dossiers clés).
Quels fichiers sont indispensables ?
- /wp-content/ : le plus important.
- /wp-content/uploads/ : vos images et médias.
- /wp-content/themes/ : votre thème (et surtout le thème enfant).
- /wp-content/plugins/ : vos extensions (utile pour restauration rapide à l’identique).
- /wp-content/mu-plugins/ : plugins “must-use” (souvent oubliés, parfois critiques).
- wp-config.php : configuration (connexion DB, clés de sécurité, préfixe de tables, etc.).
- .htaccess (Apache) ou config Nginx si vous l’avez : règles de réécriture, sécurité, cache.
Faut-il sauvegarder /wp-admin/ et /wp-includes/ ?
Pas obligatoire si vous restaurez sur la même version WordPress, car ces dossiers font partie du core et peuvent être réinstallés. Mais en pratique, pour un débutant, archiver tout le site évite les oublis.
Résultat attendu
Vous avez une checklist : SQL + wp-content + wp-config.php (+ .htaccess).
Étape 2 : Mettre le site en “pause” proprement (optionnel, mais recommandé)
Le problème d’une sauvegarde “à chaud”, c’est que la base de données peut changer pendant l’export (commentaires, commandes WooCommerce, cache, sessions). Sur un blog peu actif, ce risque est faible, mais je l’ai vu casser des restaurations WooCommerce.
Méthode A (sans plugin) : activer un mode maintenance via .maintenance
WordPress affiche automatiquement un message de maintenance si un fichier .maintenance est présent à la racine du site (là où se trouve wp-config.php).
Créez un fichier nommé .maintenance à la racine, contenant :
<?php
// Mode maintenance simple : WordPress affichera un message de maintenance.
$upgrading = time();
Où le mettre : via FTP/SFTP, à la racine (même niveau que wp-config.php).
Résultat attendu : en visitant le site, vous voyez un message de maintenance WordPress. L’admin peut aussi être bloquée.
Méthode B : ne rien faire (acceptable pour un blog)
Si votre site a peu de trafic et pas de transactions, vous pouvez sauter cette étape. Mais gardez en tête que la sauvegarde est une photo “à un instant T”.
Après la sauvegarde
Pensez à supprimer le fichier .maintenance pour remettre le site en ligne.
Étape 3 : Exporter la base de données (méthode phpMyAdmin)
Vous allez produire un fichier .sql (souvent compressé). C’est le cœur de votre contenu.
1) Trouver le nom de la base (sans deviner)
Ouvrez wp-config.php (via FTP ou gestionnaire de fichiers) et repérez :
<?php
// Extrait typique de wp-config.php (ne copiez pas vos vraies valeurs en public)
define( 'DB_NAME', 'nom_de_votre_base' );
define( 'DB_USER', 'utilisateur_db' );
define( 'DB_PASSWORD', 'mot_de_passe_db' );
define( 'DB_HOST', 'localhost' );
// Préfixe des tables (souvent wp_, parfois personnalisé)
$table_prefix = 'wp_';
Résultat attendu : vous connaissez DB_NAME (le nom exact de la base) et le $table_prefix.
2) Exporter via phpMyAdmin
- Connectez-vous à votre hébergeur → ouvrez phpMyAdmin.
- Dans la colonne de gauche, cliquez sur la base DB_NAME.
- Cliquez sur l’onglet Exporter.
- Choisissez Méthode : Personnalisée (évite des exports incomplets).
- Format : SQL.
- Compression :</strong gzip si disponible (pratique et plus léger).
- Dans “Options spécifiques au format”, cochez :
- Ajouter DROP TABLE / VIEW / PROCEDURE / FUNCTION (selon options disponibles)
- Ajouter IF NOT EXISTS (si proposé)
- Validez : Exécuter.
Pourquoi “Personnalisée” ?
Sur certains hébergeurs, “Rapide” peut ignorer des options utiles, et j’ai déjà récupéré des SQL sans DROP TABLE qui compliquent la restauration (tables déjà existantes).
Résultat attendu
Vous téléchargez un fichier du type :
nom_de_votre_base.sql- ou
nom_de_votre_base.sql.gz
Sa taille doit être cohérente. Un blog réel fait rarement “2 Ko”. Si votre fichier est minuscule, l’export a probablement échoué.
Étape 4 : Sauvegarder les fichiers (FTP/SFTP ou gestionnaire de fichiers)
Vous allez récupérer les fichiers du serveur sur votre ordinateur. Deux approches : télécharger tout, ou cibler l’essentiel.
Méthode A (recommandée débutant) : télécharger tout le répertoire du site
Outil :</strong FileZilla (ou équivalent). Si votre hébergeur propose SFTP, prenez SFTP.
- Ouvrez votre client FTP/SFTP.
- Connectez-vous (hôte, identifiant, mot de passe, port). Pour SFTP, port souvent 22.
- Dans la partie serveur, allez dans le dossier racine du site (souvent
public_html,www, ou un dossier de domaine). - Téléchargez tout le contenu vers votre dossier
backup-wp-YYYY-MM-DD.
Résultat attendu : vous avez sur votre ordinateur :
wp-admin/wp-includes/wp-content/wp-config.php- (souvent)
.htaccess
Méthode B (plus rapide) : ne télécharger que l’essentiel
Si vous avez une contrainte de temps ou de volume, téléchargez au minimum :
wp-content/wp-config.php.htaccess(si présent)
Vous pourrez réinstaller WordPress 6.9.4 proprement et remettre wp-content + la base.
Astuce : ne ratez pas les fichiers “cachés”
.htaccess et .maintenance sont des fichiers cachés (ils commencent par un point). Dans FileZilla : Serveur → Forcer l’affichage des fichiers cachés.
Résultat attendu
Le téléchargement se termine sans erreurs. Si vous voyez des “Permission denied” sur des fichiers dans uploads, notez-les : c’est souvent un problème de droits à corriger.
Étape 5 : Vérifier l’intégrité de la sauvegarde (avant d’en avoir besoin)
Une sauvegarde non vérifiée, c’est un faux sentiment de sécurité. Je le dis parce que je récupère régulièrement des “sauvegardes” avec un SQL vide, ou un dossier uploads incomplet.
Checklist rapide
- Votre fichier SQL est non vide (taille cohérente).
- Vous pouvez l’ouvrir (au moins les premières lignes) avec un éditeur (VS Code) ou un outil gzip.
- Votre dossier
wp-content/uploadscontient bien des sous-dossiers (année/mois). - Vous avez bien
wp-config.php.
Créer une archive ZIP (pratique pour stockage)
Sur votre ordinateur, compressez :
- Le dossier des fichiers (ou au moins
wp-content+wp-config.php) - Le fichier SQL
Nommez vos archives de façon explicite :
site-fichiers-2026-04-06.zipsite-bdd-2026-04-06.sql.gz
Résultat attendu
Vous avez deux éléments stockables et identifiables, prêts à être copiés hors serveur.
Étape 6 : Tester une restauration sur un environnement de test
C’est l’étape que les débutants sautent… puis ils découvrent le jour J que la sauvegarde ne restaure pas. Testez au moins une fois.
Option simple : un sous-domaine ou un site de staging chez l’hébergeur
Beaucoup d’hébergeurs proposent un “staging”. Sinon, créez un sous-domaine (ex: staging.votresite.com) avec sa propre base.
Processus de restauration (vue d’ensemble)
- Créer une nouvelle base + utilisateur (via cPanel/Plesk).
- Uploader les fichiers WordPress (core + votre
wp-content). - Importer le SQL dans la nouvelle base via phpMyAdmin.
- Mettre à jour
wp-config.php(DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). - Corriger les URLs si vous restaurez sur un autre domaine (cas fréquent).
Cas fréquent : URLs à corriger après restauration
Quand vous restaurez sur un sous-domaine, l’URL du site change. WordPress stocke l’URL dans la table options (options siteurl et home).
Vous pouvez ajuster temporairement via wp-config.php (pratique quand l’admin ne passe pas) :
<?php
// À placer dans wp-config.php, avant "/* That's all, stop editing! */"
// Objectif : forcer l'URL du site sur l'environnement de test.
define( 'WP_HOME', 'https://staging.votresite.com' );
define( 'WP_SITEURL', 'https://staging.votresite.com' );
Attention : retirez ces constantes après validation si vous ne voulez pas figer l’URL.
Résultat attendu
Votre site de test s’ouvre, l’administration fonctionne, vos médias sont visibles, et les pages affichent le bon contenu.
Le résultat complet
Si vous voulez une vue “tout-en-un”, voici ce que vous devez avoir à la fin (et où) :
1) Sur votre ordinateur
- Fichiers :
site-fichiers-2026-04-06.zip(ou un dossier complet du site)
- Base :
site-bdd-2026-04-06.sql.gz(ou.sql)
2) Sur un stockage hors serveur
- Une copie sur un disque externe ou NAS.
- Une copie sur un cloud (Drive/Dropbox/Backblaze/etc.) idéalement chiffrée.
3) Le seul “code” utilisé (optionnel)
Le fichier .maintenance (si vous avez choisi de mettre le site en pause) :
<?php
// Mode maintenance : à supprimer après la sauvegarde.
$upgrading = time();
Adapter pour Divi 5 / Elementor / Avada
La sauvegarde manuelle ne dépend pas du page builder, mais il y a des dossiers à surveiller car ces outils génèrent beaucoup d’assets (CSS/JS) et stockent des données en base.
Divi 5
- Vérifiez bien
wp-content/themes/(Divi + thème enfant Divi si vous en avez un). - Divi peut générer des fichiers de cache/ressources dans
wp-content/. Selon votre configuration, ils peuvent être régénérés, mais je les conserve en sauvegarde “tout le site” pour éviter les surprises. - Si vous utilisez la bibliothèque Divi (layouts), elle est en base : votre export SQL est indispensable.
Elementor
- Vos mises en page sont stockées en base (posts + postmeta). Donc : SQL obligatoire.
- Elementor génère des CSS dans
wp-content/uploads/elementor/(souvent). Ne sauvegardez pas seulement les images, sauvegardez toutuploads. - Après restauration, si le design semble “cassé”, une régénération des fichiers CSS dans Elementor peut suffire (voir section dépannage).
Avada (Fusion Builder)
- Avada stocke beaucoup d’options en base. Même remarque : sans SQL, vous perdez la configuration.
- Sur certains sites Avada, j’ai vu des tailles de base plus importantes que prévu : si phpMyAdmin time-out, passez à une alternative (section “Variante”).
Vérification finale
- Base de données : vous avez un fichier
.sqlou.sql.gznon vide, daté, stocké hors serveur. - Fichiers : vous avez
wp-contentcomplet (uploads/themes/plugins), etwp-config.php. - Test : vous avez validé au moins une restauration sur staging ou sous-domaine (même une fois).
- Site remis en ligne : si vous avez utilisé
.maintenance, il est supprimé.
Résultat attendu : vous pouvez perdre l’accès à WordPress admin et restaurer quand même.
Si le résultat n’est pas celui attendu
Voici les problèmes que je vois le plus souvent, avec une façon rapide de vérifier et corriger.
Tableau de diagnostic
| Symptôme | Cause probable | Vérification | Solution |
|---|---|---|---|
| Le fichier SQL fait quelques Ko | Export interrompu / mauvaise base sélectionnée | Ouvrir le SQL : contient-il des CREATE TABLE / INSERT ? | Re-export en “Personnalisée”, vérifiez DB_NAME dans wp-config.php |
| Il manque des images après restauration | uploads incomplet | Comparer le nombre de dossiers année/mois | Retélécharger wp-content/uploads en entier |
| Le site restauré redirige vers l’ancien domaine | URLs en base (home/siteurl) | phpMyAdmin → table options → home/siteurl | Forcer WP_HOME/WP_SITEURL temporairement ou remplacer les URLs proprement |
| Erreur “Error establishing a database connection” | Mauvais identifiants DB dans wp-config.php | Comparer DB_NAME/DB_USER/DB_PASSWORD | Corriger wp-config.php, vérifier l’utilisateur DB côté hébergeur |
| Le site reste en maintenance | .maintenance oublié | Vérifier fichier à la racine | Supprimer .maintenance |
Cas concret : vous ne trouvez pas wp-config.php
Souvent, vous n’êtes pas dans le bon dossier (ex: public_html/ vs public_html/votresite/). Repérez un dossier qui contient wp-content. Le wp-config.php est généralement au même niveau.
Cas concret : votre client FTP n’affiche pas .htaccess
Activez l’affichage des fichiers cachés. Sans ça, vous sauvegardez “presque tout” et vous perdez des règles de réécriture ou de sécurité.
Pièges et erreurs courantes
| Erreur | Cause | Solution |
|---|---|---|
| Sauvegarder uniquement les fichiers | On pense que “tout est dans wp-content” | Exporter aussi la base SQL (contenu + réglages) |
| Sauvegarder uniquement la base | On oublie les médias et le thème | Récupérer wp-content (uploads/themes/plugins) |
| Copier les fichiers au mauvais endroit | Confusion entre racine serveur et dossier WordPress | Repérer wp-content + wp-config.php pour identifier la bonne racine |
| Oublier les fichiers cachés (.htaccess, .maintenance) | Option FTP non activée | Forcer l’affichage des fichiers cachés dans le client FTP |
| Tester directement en production | Pas d’environnement de test | Créer un staging/sous-domaine, tester la restauration |
| Exporter “Rapide” et obtenir un SQL partiel | Timeout / paramètres phpMyAdmin | Exporter “Personnalisée” + compression gzip |
| Rester bloqué en maintenance | .maintenance oublié | Supprimer le fichier après la sauvegarde |
| Restaurer sur un autre domaine sans corriger les URLs | home/siteurl stockés en base | Forcer WP_HOME/WP_SITEURL temporairement ou faire un remplacement d’URL propre |
| Utiliser un vieux tutoriel avec PHP 7.x | Code/outil obsolète | Rester sur PHP 8.1+ et méthodes actuelles (WordPress 6.9.4) |
Variante / alternative
Si votre base est trop grosse pour phpMyAdmin (timeouts), ou si vous voulez du “zéro prise de tête”, voici deux alternatives réalistes.
Alternative 1 : outil de sauvegarde de l’hébergeur
Beaucoup d’hébergeurs offrent une sauvegarde “snapshot” (fichiers + base). Avantage : c’est souvent plus fiable sur gros volumes qu’un export phpMyAdmin via navigateur.
- Vérifiez la fréquence (quotidienne ?), la rétention (7 jours ? 30 jours ?), et surtout : pouvez-vous télécharger la sauvegarde ?
Alternative 2 : plugin de sauvegarde (pour automatiser)
Un plugin n’est pas “moins pro”. Sur beaucoup de sites, c’est la meilleure option pour des sauvegardes planifiées + stockage externe.
- Choisissez un plugin maintenu, compatible WordPress 6.9.4, avec export vers un stockage externe.
- Gardez quand même une sauvegarde manuelle ponctuelle avant une opération risquée (c’est votre parachute).
Conseils sécurité, performance et maintenance
- Règle 3-2-1 : 3 copies, sur 2 supports différents, dont 1 hors site (cloud).
- Chiffrez vos archives si vous les stockez sur un cloud partagé (un SQL peut contenir des emails, parfois des données sensibles selon vos plugins).
- Documentez : gardez un fichier texte dans votre dossier de sauvegarde avec :
- Version WordPress (6.9.4)
- Version PHP
- Nom du thème actif
- Liste des plugins critiques
- Date/heure de la sauvegarde
- Rythme : pour un blog, hebdomadaire peut suffire. Pour un site actif, visez quotidien.
- Ne laissez pas le fichier
.maintenancetraîner.
Pour aller plus loin
Quand vous serez à l’aise, vous pourrez améliorer votre process :
- Passer à une sauvegarde via SSH (si votre hébergeur le permet) pour éviter les limites navigateur.
- Mettre en place un staging permanent et tester chaque mise à jour avant production.
- Automatiser l’export et l’upload vers un stockage externe (S3, Backblaze, etc.).
Si vous avez accès à SSH, regardez du côté de mysqldump (documentation officielle MySQL/MariaDB) et de tar/rsync. Ce n’est pas nécessaire pour débuter, mais c’est le niveau au-dessus.
Ressources
- WordPress Developer Resources — Backups (advanced administration)
- WordPress.org Documentation — WordPress Backups
- WordPress.org Documentation — Editing wp-config.php
- Developer.WordPress.org — wp-config.php (référence)
- PHP.net — Zlib (compression gzip)
- GitHub — WordPress Core (wordpress-develop)
- WordPress Core Trac (suivi des tickets)
FAQ
Est-ce qu’une sauvegarde “fichiers seulement” suffit ?
Non. Vous récupérez le thème, les plugins et les médias, mais vous perdez le contenu (articles/pages), les réglages et les utilisateurs, car tout ça est dans la base.
Est-ce qu’une sauvegarde “base seulement” suffit ?
Non. Vous récupérez le contenu, mais vous perdez les images (uploads) et souvent le thème et les extensions, donc le site ne “ressemble” plus à rien.
Dois-je sauvegarder tout WordPress ou seulement wp-content ?
Pour un débutant, sauvegarder tout le dossier du site est le plus simple. Si vous voulez optimiser, sauvegardez au minimum wp-content + wp-config.php + la base SQL.
Pourquoi mon export phpMyAdmin échoue sur les gros sites ?
phpMyAdmin passe par le navigateur et subit des limites (timeout, mémoire). Sur gros volumes, utilisez l’outil de sauvegarde de l’hébergeur, un plugin, ou SSH si disponible.
Où trouver le nom de la base si je ne l’ai pas noté ?
Dans wp-config.php, la constante DB_NAME.
Que faire si je ne vois pas .htaccess en FTP ?
Activez l’affichage des fichiers cachés dans votre client FTP. Sur FileZilla, c’est un réglage côté menu “Serveur”.
Est-ce que je peux stocker la sauvegarde sur le même serveur ?
Vous pouvez, mais ce n’est pas une vraie stratégie. Si le serveur tombe, est compromis, ou si vous supprimez le mauvais dossier, vous perdez site + sauvegarde. Gardez au moins une copie hors serveur.
Dois-je activer un mode maintenance pendant la sauvegarde ?
Pour un blog, c’est optionnel. Pour un site avec commandes (WooCommerce) ou beaucoup d’activité, c’est recommandé pour éviter une base “entre deux états”.
Pourquoi mon site restauré redirige vers l’ancien domaine ?
Les URLs sont stockées en base. Corrigez home et siteurl (table options) ou forcez temporairement WP_HOME / WP_SITEURL dans wp-config.php.
Est-ce que Divi/Elementor/Avada change la façon de sauvegarder ?
Non sur le principe (base + fichiers). Par contre, ils stockent beaucoup de configuration en base et génèrent parfois des fichiers dans uploads. Donc : ne négligez ni le SQL ni uploads.
À quelle fréquence faire une sauvegarde manuelle ?
Avant chaque opération risquée, et ensuite selon votre activité. Si vous publiez une fois par semaine, une sauvegarde hebdo peut suffire. Si vous publiez tous les jours, visez quotidien (idéalement automatisé).