La sauvegarde WordPress est le filet de sécurité contre lequel tous les autres investissements en sécurité viennent s’appuyer. Un site compromis par un malware, une mise à jour qui casse la compatibilité, une erreur humaine de suppression accidentelle — sans sauvegarde récente, ces incidents deviennent des catastrophes. Les plugins de sauvegarde payants (UpdraftPlus Premium, BackupBuddy, Jetpack Backup) offrent du confort, mais une stratégie de sauvegarde robuste s’implémente entièrement avec des outils gratuits en 2026. Ce guide vous montre comment.
Les deux composantes à sauvegarder : fichiers et base de données
Une sauvegarde WordPress complète comprend deux éléments distincts. Les fichiers : le répertoire wp-content (thèmes, plugins, uploads — vos médias et personnalisations) et wp-config.php (configuration critique incluant les credentials de base de données). Les fichiers core WordPress (wp-admin/, wp-includes/) n’ont pas besoin d’être sauvegardés — ils sont identiques sur tous les sites de même version et peuvent être réinstallés en quelques secondes.
La base de données MySQL contient tout votre contenu : articles, pages, commentaires, réglages WordPress, données WooCommerce, utilisateurs, métadonnées. C’est la composante la plus critique — perdre la base de données signifie perdre tous vos articles publiés. En termes de fréquence, sauvegardez la base de données plus souvent que les fichiers : quotidiennement pour la base, hebdomadairement pour les fichiers (qui changent moins fréquemment).
La règle 3-2-1 est le standard de l’industrie : 3 copies de vos données, sur 2 supports différents, dont 1 hors site. Pour WordPress : 1 copie locale sur votre serveur (accessible rapidement), 1 copie sur un service cloud différent de votre hébergeur (Google Drive, Amazon S3, Backblaze B2), 1 copie archivée avec une rétention longue (30 jours minimum). Si votre hébergeur subit un incident, vos copies cloud restent intactes — c’est le cas qui justifie le hors-site.
WP-CLI : sauvegarder depuis la ligne de commande
WP-CLI (WordPress Command Line Interface) est l’outil le plus puissant pour les sauvegardes WordPress en ligne de commande. Disponible sur la plupart des hébergements cPanel, il permet d’exporter la base de données, de vérifier l’intégrité des fichiers et de restaurer un site entier sans passer par l’interface WordPress. Vérifiez sa disponibilité avec `wp –info` dans le terminal SSH de votre hébergeur.
Commande de sauvegarde de la base de données : `wp db export backup-$(date +%Y%m%d).sql –add-drop-table –path=/home/wami5543/public_html`. Cette commande crée un fichier SQL horodaté avec toutes les instructions DROP TABLE pour une restauration propre. Pour compresser : `gzip backup-$(date +%Y%m%d).sql`. Pour une sauvegarde complète des fichiers : `tar -czf wp-files-$(date +%Y%m%d).tar.gz /home/wami5543/public_html/wp-content/`. Ces deux commandes constituent le cœur de votre script de sauvegarde.
Script de sauvegarde complet à adapter à votre configuration :
« `bash
#!/bin/bash
BKP_DIR= »/home/wami5543/backups »
DATE=$(date +%Y%m%d-%H%M)
mkdir -p $BKP_DIR
# Base de données
wp db export $BKP_DIR/db-$DATE.sql –path=/home/wami5543/public_html
gzip $BKP_DIR/db-$DATE.sql
# Fichiers wp-content
tar -czf $BKP_DIR/files-$DATE.tar.gz /home/wami5543/public_html/wp-content
# Nettoyage des sauvegardes de plus de 30 jours
find $BKP_DIR -name ‘*.gz’ -mtime +30 -delete
echo « Backup $DATE terminé »
« `
Automatiser avec les crons cPanel
Une sauvegarde manuelle que personne n’exécute régulièrement ne sert à rien. L’automatisation via les tâches cron cPanel garantit l’exécution sans intervention humaine. Dans votre panneau cPanel, cherchez ‘Tâches cron’ ou ‘Cron Jobs’. Ajoutez une tâche avec l’expression cron `0 3 * * *` (tous les jours à 3h du matin) et la commande : `/usr/bin/wp db export /home/wami5543/backups/db-$(date +%Y%m%d).sql –path=/home/wami5543/public_html && gzip /home/wami5543/backups/db-$(date +%Y%m%d).sql`.
Pour les fichiers wp-content, une fréquence hebdomadaire suffit : expression cron `0 4 * * 0` (dimanche à 4h) avec la commande tar correspondante. Si votre hébergeur limite le temps d’exécution des crons ou la taille des fichiers générés, découpez la sauvegarde des fichiers : uploads/ une semaine, themes/ + plugins/ l’autre semaine. Pour un site avec des Go de médias uploadés, la sauvegarde complète peut dépasser les timeouts.
Activez les notifications email des crons cPanel : si la tâche produit une sortie (y compris des erreurs), cPanel vous l’envoie par email. Pendant les deux premières semaines, vérifiez ces emails pour confirmer que vos sauvegardes s’exécutent sans erreur. Vérifiez également physiquement la présence des fichiers de sauvegarde dans votre répertoire backups/ — un cron qui échoue silencieusement vous donnera une fausse impression de sécurité.
Rclone : synchroniser automatiquement vers le cloud
Stocker vos sauvegardes uniquement sur le même serveur que votre site ne protège pas contre une perte totale de l’hébergeur. Rclone est un outil open-source qui synchronise vos fichiers locaux vers plus de 40 destinations cloud : Google Drive, Amazon S3, Backblaze B2, OneDrive, Dropbox, et même un second serveur SFTP. Il s’installe sur la plupart des hébergements Linux avec `curl https://rclone.org/install.sh | sudo bash` (ou sans sudo selon vos permissions).
Configuration Rclone vers Google Drive : `rclone config`, choisissez ‘n’ (new remote), nommez-le ‘gdrive’, sélectionnez ‘Google Drive’, suivez le processus OAuth2. Une fois configuré, synchronisez votre dossier backups/ vers Google Drive avec : `rclone copy /home/wami5543/backups gdrive:WordPress-Backups –min-age 1h`. L’option `–min-age 1h` évite d’uploader des fichiers de sauvegarde en cours d’écriture. Ajoutez cette commande à votre cron, 30 minutes après le script de sauvegarde.
Pour Backblaze B2 (stockage objet à 0,006 $/Go/mois — le moins cher du marché), créez un bucket B2, générez des credentials API, et configurez Rclone de la même façon. Avec la facturation à l’usage, sauvegarder 10 Go de fichiers WordPress coûte moins de 0,07 $/mois. Configurez une règle de lifecycle sur votre bucket B2 pour supprimer automatiquement les fichiers de plus de 60 jours — sans cette règle, votre stockage cloud grossit indéfiniment.
UpdraftPlus gratuit : la solution plugin pour les non-techniciens
Si les scripts shell et les crons ne vous conviennent pas, UpdraftPlus en version gratuite reste la meilleure option plugin sans coût. Il supporte la sauvegarde automatique des fichiers et de la base de données vers Google Drive, Dropbox, Amazon S3, et email, sans limitation dans la version gratuite. Configurez une sauvegarde quotidienne de la base (légère) et hebdomadaire des fichiers (lourde).
La configuration critique dans UpdraftPlus : allez dans Settings > UpdraftPlus Backups > Settings. Fréquence des fichiers : une fois par semaine. Fréquence de la base de données : quotidienne. Nombre de sauvegardes à conserver : 4 (fichiers) et 7 (base de données). Stockage distant : Google Drive (connectez votre compte Google via OAuth). Activez les notifications email en cas d’échec. En 5 minutes, vous avez une stratégie de sauvegarde fonctionnelle et entièrement automatisée.
La limite principale d’UpdraftPlus gratuit : les sauvegardes incrémentielles (qui ne sauvegardent que les modifications depuis la dernière sauvegarde) sont réservées à la version premium. Pour les gros sites avec plusieurs Go de médias, une sauvegarde complète hebdomadaire peut être longue et solliciter les ressources serveur pendant l’exécution. Planifiez-la à 3h du matin pour minimiser l’impact sur vos visiteurs.
Tester la restauration : l’étape que 90 % des webmasters oublient
Une sauvegarde non testée est une sauvegarde de valeur inconnue. Il arrive que des fichiers de sauvegarde soient corrompus, incomplets ou incompatibles avec la version WordPress courante. La seule façon de s’en assurer est de tester la restauration au moins une fois par trimestre. Créez un sous-domaine de test (staging.votre-site.com) et restaurez votre dernière sauvegarde dessus via WP-CLI ou UpdraftPlus.
Le processus de restauration manuelle avec WP-CLI : créez une base de données MySQL vide dans cPanel, importez le dump SQL compressé (`gzip -d backup.sql.gz && wp db import backup.sql –path=/staging/`), décompressez les fichiers wp-content dans le répertoire staging, mettez à jour wp-config.php avec les nouveaux credentials de base de données, et lancez `wp search-replace ‘votre-site.com’ ‘staging.votre-site.com’ –path=/staging/` pour adapter les URLs. Si votre site s’affiche correctement sur le staging, votre sauvegarde est valide.
Documentez votre procédure de restauration et sa durée. Savoir qu’une restauration prend 20 minutes (et non 3 heures) change votre calcul de risque. Partagez cette documentation avec toute personne ayant accès au site — en cas d’incident, la panique rend les gens moins efficaces, mais une procédure documentée transforme une crise en procédure. La sauvegarde sans plan de restauration n’est que la moitié du travail.
Sauvegardes staging : protéger vos environnements de développement
Si vous utilisez un environnement staging pour tester les mises à jour avant de les déployer en production (ce que vous devriez faire), cet environnement doit également être sauvegardé — mais avec une stratégie allégée. Une sauvegarde hebdomadaire manuelle du staging suffit généralement, car c’est un environnement qu’on peut reconstruire depuis la production. L’essentiel est de ne jamais perdre de travail de développement ou de personnalisation qui n’a pas encore été déployé.
Pour les agences gérant plusieurs sites clients, standardisez votre procédure de sauvegarde avec un script partagé que vous adaptez par client. Chaque site a son propre répertoire de backups, sa propre destination cloud (un dossier par client dans un bucket S3 partagé), et ses propres fréquences selon la criticité. Documentez cette procédure dans votre CRM ou espace de travail d’équipe : quand un client appelle pour une restauration, n’importe quel membre de l’équipe doit être capable d’exécuter la procédure sans dépendre du développeur principal.
La facturation des sauvegardes : pour les clients en contrat de maintenance, incluez explicitement les sauvegardes dans le périmètre (fréquence, durée de rétention, destination) et faites-les signer. En cas d’incident, vous aurez une trace contractuelle des engagements pris. Pour les clients sans contrat de maintenance, proposez un forfait ‘Sauvegarde + Monitoring’ séparé — c’est une valeur ajoutée perçue forte et un revenu récurrent prévisible pour votre activité.
Monitoring de l’intégrité des fichiers : détecter les modifications suspectes
Les sauvegardes protègent contre la perte de données. Le monitoring d’intégrité des fichiers détecte les modifications non autorisées — signature d’une compromission malware. Wordfence (version gratuite) scanne régulièrement les fichiers core WordPress et les compare à la version officielle de référence : toute différence est signalée. Pour les fichiers de thème et de plugin, il compare les checksums avec les versions du répertoire WordPress.org.
Configurez des alertes email sur toute modification dans wp-config.php, .htaccess, et les fichiers de thème actif. Ces fichiers sont rarement modifiés légitimement par des automatismes — toute modification inattendue est un signal d’alerte. WP Activity Log (plugin gratuit) loggue chaque modification de fichier avec l’utilisateur, l’IP et l’heure. Croisez ces logs avec vos sauvegardes pour identifier exactement quand et comment une compromission a eu lieu.
Combinez sauvegardes + monitoring d’intégrité + WAF pour une défense en profondeur. Le WAF bloque les tentatives d’exploitation ; le monitoring détecte si une modification a quand même eu lieu malgré le WAF (zero-day, voie d’attaque non filtrée) ; la sauvegarde permet de restaurer proprement. Sans les trois, vous êtes soit aveugle, soit incapable de vous remettre d’un incident. Avec les trois et un budget quasi nul (outils gratuits), vous avez un niveau de protection professionnel.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.