Par Geoffrey Medina, fondateur de PandiWeb, développeur web fullstack depuis 2015
TL;DR : Une sauvegarde WordPress complète contient deux parties indissociables : la base de données et les fichiers. On sauvegarde la base d’abord, les fichiers ensuite, et on restaure dans l’ordre inverse. La fréquence dépend du rythme des modifications, pas de la taille du site. Gardez 3 à 5 copies récentes, dont au moins une hors du serveur. Une sauvegarde jamais testée ne protège de rien : essayez la restauration sur un environnement de test. Un export XML de contenu n’est pas un backup WordPress.
Vendredi, 17 h. Imaginez : depuis la mise à jour de midi, votre page d’accueil renvoie une erreur 500 et le back-office est bloqué. Vous ouvrez le dossier d’hébergement. La dernière sauvegarde disponible date de 22 jours. Le site a encaissé des commandes pendant ces 22 jours, et personne ne sait ce qui a changé entre-temps.
Le problème n’est presque jamais l’absence d’outil : c’est la sauvegarde qu’on n’a jamais ouverte, jamais testée, jamais complétée.
Ce qu'une sauvegarde WordPress doit contenir
WordPress fait tourner 39,6 % des sites web dans le monde et 58,3 % des sites dont le CMS est connu (W3Techs, 22 octobre 2026). Cette popularité explique le volume d’incidents, et pourquoi les sauvegardes incomplètes passent inaperçues si longtemps.
Une sauvegarde WordPress complète est une copie restaurable de deux éléments distincts : la base de données et les fichiers du site. Un site WordPress ne tient pas dans un seul dossier.
La base de données d'abord
Le contenu réel du site vit dans MySQL ou MariaDB, en dehors du dossier WordPress. Articles, pages, menus, réglages, comptes utilisateurs, commandes WooCommerce : tout est en base. La documentation officielle recommande de sauvegarder la base avant les fichiers (doc WordPress).
Le préfixe des tables est wp_ par défaut, ou celui défini par table_prefix dans wp-config.php. Un téléchargement FTP du dossier ne récupère rien de tout cela, et c’est la première cause de perte de données que l’on rencontre dans ce type de situation.
Les fichiers ensuite, et la restauration dans l'ordre inverse
Le périmètre des fichiers comprend le cœur de WordPress, les thèmes, les plugins, les médias et wp-config.php (doc WordPress). Le dossier wp-content concentre l’essentiel du poids, souvent plusieurs gigaoctets de photos et de PDF. Le fichier wp-config.php contient les identifiants de connexion à la base : sans lui, une base parfaitement restaurée reste inutilisable. Ajoutez aussi .htaccess, qui porte les redirections et une partie des règles de sécurité.
À la restauration, on remet d’abord les fichiers en place, puis on réimporte la base. Cet ordre évite qu’une base à jour pointe vers des fichiers encore absents. Une sauvegarde faite dans le bon ordre mais restaurée dans le mauvais produit un site qui s’affiche à moitié, avec des erreurs difficiles à isoler.
Fréquence et stockage : les deux décisions qui comptent
Une sauvegarde utile répond à deux questions : à quel rythme la produit-on, et où vit-elle une fois produite ? Les deux se règlent avant l’incident, jamais pendant.
À quelle fréquence sauvegarder
La fréquence ne dépend pas du nombre de pages mais du rythme des modifications. WordPress recommande une sauvegarde hebdomadaire pour un petit site et quotidienne pour un site à forte activité (doc WordPress). Dès qu’une commande, une réservation ou un formulaire entre en jeu, ce rythme se resserre : une journée de données perdues sur une boutique, c’est une journée de commandes à reconstituer à la main. Le tableau plus bas donne un repère par profil de site.
Les planifications standard d’UpdraftPlus couvrent ces besoins : manuel, toutes les 2, 4, 8 ou 12 heures, quotidien, hebdomadaire, tous les quinze jours, mensuel (doc UpdraftPlus). La sauvegarde automatique doit rester doublée d’une copie manuelle avant toute opération sensible : mise à jour majeure, changement de thème, migration d’hébergeur. C’est d’ailleurs un réflexe de base dans une maintenance WordPress sérieuse.
Combien de copies, et où les stocker
La documentation WordPress donne une règle simple : conserver au moins 3 à 5 sauvegardes récentes, réparties dans des emplacements différents, serveur, cloud et poste local (doc WordPress). Une copie qui vit sur le même disque que le site disparaît avec le site. Panne matérielle, compte suspendu, suppression accidentelle : le scénario le plus fréquent emporte le site et sa sauvegarde dans le même mouvement.
La sauvegarde de l'hébergeur : un filet, pas une stratégie
Beaucoup d’hébergeurs annoncent des sauvegardes automatiques. Elles sont utiles pour revenir en arrière après une erreur de manipulation, mais elles restent sur la même infrastructure et avec une rétention courte. Considérez-les comme un filet de sécurité opérationnel, pas comme votre stratégie de sauvegarde. Demandez par écrit la durée de rétention réelle avant de bâtir quoi que ce soit dessus.
Les destinations distantes d'un plugin
UpdraftPlus accepte plusieurs destinations distantes : UpdraftVault, Dropbox, Google Drive, Amazon S3, FTP, OpenStack, DreamObjects, S3-compatible, ou l’envoi par email. Les destinations OneDrive, Azure, SFTP/SCP, Google Cloud, Backblaze, WebDAV et pCloud sont réservées à la version premium (comparatif UpdraftPlus). L’envoi par email reste une fausse bonne idée dès que le site dépasse quelques centaines de mégaoctets, les boîtes mail limitant la taille des pièces jointes.
Protéger vos archives
Une archive de sauvegarde contient wp-config.php, donc les identifiants de la base, et parfois des données clients. Un dossier de sauvegardes lisible publiquement est une fuite en attente. Vérifiez qui a accès aux copies et où elles sont réellement stockées.
Quelle fréquence pour quel type de site
| Profil de site | Fréquence minimale | Rétention | Point de vigilance |
|---|---|---|---|
| Site vitrine de 5 pages, contenu figé | 1 fois par semaine | 4 semaines | Sauvegarder aussi avant chaque mise à jour |
| Site vitrine avec blog actif | Quotidienne | 30 jours | La base change à chaque publication |
| WooCommerce ou réservation en ligne | 2 fois par jour, idéalement après chaque commande | 30 jours | Commandes et stocks vivent en base |
| Formulaire métier, espace membre | Quotidienne, plus une copie avant chaque mise à jour | 30 jours | Les saisies ne sont pas dans les fichiers |
| Catalogue de plus de 5 000 médias | Quotidienne, complète chaque semaine | 60 jours | Poids élevé, restauration à tester en amont |
Les 4 méthodes pour sauvegarder un site WordPress
Quatre familles de solutions coexistent, et on les combine souvent. La bonne méthode est celle qui produit une archive que quelqu’un sait restaurer un dimanche soir. Le tableau reprend les tarifs publics constatés en octobre 2026, avec leur source.
| Méthode | Coût constaté | Points forts | Limites |
|---|---|---|---|
| Sauvegarde de l’hébergeur | Incluse, variable selon l’offre | Restauration rapide, rien à maintenir | Rétention courte, même infrastructure |
| Plugin UpdraftPlus | Gratuit, puis 84 $/an pour 2 sites et 114 $/an pour 10 sites en Premium | Destinations multiples, planification fine, restauration guidée | La version gratuite ne couvre pas wp-config.php |
| WP-CLI | 0 €, hors temps de mise en place | Script en cron, adapté aux sites de plus de 5 Go | Ligne de commande, à tester avant l’incident |
| Jetpack VaultPress Backup | 4,95 €/mois la première année, 8,95 €/mois ensuite | Archive de 30 jours, 10 Go, restauration en un clic | Non compatible multisite |
| BlogVault | 49,50 $/site/an en tarif remisé, 149,50 $/site/an en Business | Copies hors serveur, deux passages quotidiens en Business | Facturation en dollars, prix par site |
| WP Umbrella | 1,99 €/site/mois, sauvegardes horaires en option à 2,49 €/site/mois | Suivi multi-sites, alertes d’échec | La sauvegarde est une option payante |
Sources tarifaires : UpdraftPlus, Jetpack, BlogVault, WP Umbrella.
L'hébergeur et le plugin
La sauvegarde de l’hébergeur est le point de départ, jamais le point d’arrivée. Elle dépanne vite après une fausse manipulation, mais elle ne protège pas d’une perte de compte ni d’une migration ratée.
Le plugin est la solution la plus répandue chez les PME, et elle convient bien jusqu’à quelques gigaoctets. UpdraftPlus, Duplicator ou BackWPup apportent une interface claire, une planification et des destinations distantes. Deux réserves : la version gratuite d’UpdraftPlus sauvegarde wp-content mais pas wp-config.php ni les personnalisations du cœur (comparatif), et une restauration par plugin sur un site lourd se heurte vite au timeout PHP.
WP-CLI et services managés
Sur un serveur avec accès SSH, WP-CLI fait la sauvegarde en deux étapes. La commande wp db export génère un fichier SQL à partir des identifiants de wp-config.php, avec des options pour inclure ou exclure des tables (doc WP-CLI). L’archive des fichiers se fait ensuite en tar ou zip, puis le tout part vers un stockage distant, le plus souvent via un script en cron. Attention : wp db import ne crée pas la base de données, il faut la créer avant (doc WP-CLI).
Jetpack VaultPress Backup, BlogVault et WP Umbrella stockent les copies hors de votre serveur et alertent quand une sauvegarde échoue. L’alerte est l’argument principal : une sauvegarde qui échoue en silence pendant trois semaines est plus dangereuse qu’une absence de sauvegarde, parce qu’elle entretient une fausse confiance.
Comment restaurer sans casser le site
La restauration est l’étape que personne ne prépare. Voici l’ordre à suivre.
- Qualifiez l’incident. Notez l’heure, la dernière action connue, le message d’erreur. Sans cela, vous risquez de réimporter une sauvegarde qui contient déjà le problème.
- Sauvegardez l’état actuel, même cassé. La copie du site planté peut contenir des commandes récentes absentes de la sauvegarde saine.
- Travaillez sur un environnement de test quand il existe, pour valider la restauration avant de toucher à la production.
- Remettez les fichiers : thème, plugins, médias. Ne remplacez pas
wp-config.phppar celui de l’archive si la base a changé de serveur, les identifiants seraient faux. - Réimportez la base. Pour un dump de plus de 50 Mo, oubliez phpMyAdmin et passez par
mysqldumpou WP-CLI (doc WordPress). - Corrigez les URLs et les chemins si le domaine a changé, puis videz les caches du plugin, du CDN et du navigateur.
- Testez pour de vrai : page d’accueil, une page interne, un formulaire, un paiement test, une connexion administrateur, les permaliens. Un site qui s’affiche n’est pas un site qui fonctionne.
- Basculez en production, puis relancez immédiatement une sauvegarde propre.
Le timeout gâche la moitié des restaurations. max_execution_time limite le temps d’exécution du code PHP, pas celui des requêtes MySQL. max_input_time gère la durée de transfert, et post_max_size doit être supérieur ou égal à upload_max_filesize, sinon PHP rejette la requête (doc WordPress). Sur un hébergement mutualisé, ces valeurs sont souvent non modifiables : restaurez alors par SSH ou via l’interface de l’hébergeur, pas par l’upload du plugin. Si la situation est déjà bloquée, notre guide de dépannage WordPress détaille les premiers réflexes.
Les 6 erreurs qui rendent une sauvegarde inutile
- Oublier la base de données. C’est l’erreur numéro un : un dossier
wp-contentcopié à la main ne contient aucune commande, aucun article, aucun réglage. - Laisser la seule copie sur le serveur. Même disque, même compte, même sort.
- Ne jamais tester la restauration. Une archive corrompue ne se voit qu’au moment où l’on en a besoin. Testez-la au moins une fois par trimestre, sur un environnement de test.
- Ignorer les échecs silencieux. Un timeout PHP en fin de script peut laisser une archive tronquée, sans message. Activez les notifications d’échec et lisez-les.
- Restaurer dans le mauvais ordre ou écraser un
wp-config.phpvalide : base d’abord à la sauvegarde, fichiers puis base à la restauration. - Mal calibrer la rétention. Trop courte, elle efface la bonne copie avant que l’erreur soit détectée. Trop longue sur un site qui grossit, elle sature le quota et fait échouer les sauvegardes suivantes.
Faites relire le plan de restauration par une deuxième personne : le jour de l’incident, celui qui a écrit le script est parfois absent. Un diagnostic rapide de votre dispositif, comme notre audit WordPress gratuit, suffit généralement à repérer les trous.
Notre retour d'expérience
Notre principe est simple : une copie n’est fiable qu’après avoir été restaurée au moins une fois. Dans notre plan d’assurance sécurité, les sauvegardes sont quotidiennes, conservées 30 jours et redondantes, avec une restauration visée sous 24 heures. La question à se poser n’est donc pas « quel plugin utilisez-vous ? » mais « quand avez-vous restauré une sauvegarde pour la dernière fois ? ». Si la réponse est « jamais », c’est par là qu’il faut commencer.
Besoin de vérifier votre dispositif ? Écrivez-nous.
Questions fréquentes sur la sauvegarde WordPress
Comment restaurer un site WordPress sans sauvegarde ?
Trois pistes existent. La sauvegarde de l’hébergeur, souvent activée par défaut et accessible depuis son panneau. Les fichiers résiduels sur le serveur, si le site n’a pas été supprimé. Les données encore en cache chez un prestataire ou dans l’index d’un moteur de recherche, pour le contenu textuel. Sans aucune de ces sources, il reste une reconstruction, avec les textes récupérés et les médias perdus : la restauration devient alors un projet de refonte, pas une opération technique.
Où se trouvent les sauvegardes de mon site WordPress ?
À trois endroits possibles : le panneau de l’hébergeur, le plugin installé sur le site, et la destination distante configurée dans ce plugin (Google Drive, Dropbox, S3, FTP). Commencez par le plugin : il indique la date de la dernière archive et sa destination. Si aucune destination distante n’est configurée, la copie est sur le serveur, donc précaire.
Une sauvegarde WordPress automatique suffit-elle ?
Elle suffit pour revenir en arrière après une erreur de manipulation, mais pas comme stratégie complète, pour trois raisons : la copie peut être stockée au même endroit que le site, l’échec peut passer inaperçu, et personne n’a validé la restauration. Automatisez la production des copies, mais testez la reprise.
L'export de contenu WordPress fait-il office de backup ?
Non. L’outil d’export génère un fichier XML avec les contenus, les catégories et les commentaires. Il ne contient ni les thèmes, ni les plugins, ni les médias, ni les tables de commandes WooCommerce, ni les réglages. C’est un outil de migration de contenu, pas une sauvegarde.
Combien de temps prend une restauration WordPress ?
Cela dépend surtout du poids de l’archive, de la vitesse de transfert et de la méthode utilisée. À titre indicatif, comptez de l’ordre de la demi-heure pour un petit site vitrine avec une sauvegarde récente, et plusieurs heures pour une boutique avec plusieurs gigaoctets de médias. Le temps se joue sur trois postes : le téléchargement de l’archive, l’import SQL et les vérifications. Un site dont la restauration n’a jamais été testée prend presque toujours plus longtemps que prévu.
Vos sauvegardes sont-elles vraiment restaurables ?
Indiquez-nous votre hébergeur et votre solution actuelle. Nous vérifions votre dispositif de sauvegarde et nous vous disons s’il tiendrait le jour de l’incident.
