Un site qui disparaît un mardi matin, ce n’est presque jamais une attaque spectaculaire : c’est une suppression de dossier, une requête SQL sans filtre, ou un compte d’hébergement suspendu pour une facture oubliée.
La plupart des dirigeants que nous accompagnons pensent être protégés parce qu’un fichier est copié quelque part, et découvrent au pire moment que cette copie ne permet aucune remise en ligne.
Nous détaillons ici ce qui constitue une vraie sauvegarde, comment se déroule une restauration, et le piège de facturation qui peut coûter très cher sur une boutique en ligne.
À retenir
- Une sauvegarde vit ailleurs que les données d’origine, sinon elle ne compte pas.
- La synchronisation cloud réplique aussi vos suppressions et vos corruptions.
- Le RAID couvre la panne de disque, jamais l’erreur humaine.
- Restaurer la base de données peut re-facturer vos abonnés WooCommerce.
- Testez la restauration sur un site de test avant l’incident réel.
- 66 % des entreprises touchées par une perte majeure ferment sous deux ans.
Ce qui est une sauvegarde, et ce qui n’en est pas
Une sauvegarde est une copie de vos données à un instant T, stockée séparément de l’original, conservée pour permettre une récupération après perte ou endommagement.
Le critère de séparation est le seul qui tranche : une copie posée sur le même disque que le site live n’est pas une sauvegarde, c’est un doublon qui mourra avec le reste.
La synchronisation cloud, Dropbox, Google Drive ou OneDrive, répercute fidèlement vos suppressions et vos fichiers corrompus vers la copie distante, ce qui la disqualifie comme protection.
Le snapshot, pointeur vers des blocs disque figés par la couche de stockage, restaure très vite mais reste attaché au même système de stockage.
L’archive, souvent en écriture unique, sert la conformité et la rétention longue, pas la remise en ligne rapide.
| Mécanisme | Protège contre | Ne protège pas contre |
|---|---|---|
| Sauvegarde séparée | Perte, corruption, suspension de compte | Rien, si elle n’est jamais testée |
| Sync cloud | Panne du poste local | Suppression et corruption répliquées |
| Snapshot | Retour arrière rapide | Défaillance du système de stockage |
| RAID | Panne physique d’un disque | Erreur humaine, malware, impayé |
| Archive | Exigences de conservation | Reprise d’activité immédiate |
GitLab a vécu en 2017 une chaîne d’erreurs humaines avec cinq méthodes de sauvegarde en place, toutes silencieusement cassées le jour J.
Les pertes qui arrivent réellement
Sept familles de scénarios de perte existent, dont la panne matérielle, l’erreur humaine, les acteurs malveillants et les bugs logiciels.
L’erreur humaine domine largement en fréquence : suppression accidentelle de dossier, requête UPDATE sans clause WHERE, corbeille vidée trop vite.
La sanction financière n’a rien d’anecdotique, puisque 66 % des entreprises victimes d’une perte de données majeure ferment dans les deux ans qui suivent.
Un site vitrine perdu, c’est un tunnel commercial coupé, un sujet que nous abordons aussi quand nous comparons WordPress, le headless et l’IA sur mesure pour choisir un CMS en 2026.
Comment se passe une restauration en pratique
Jetpack VaultPress Backup enregistre chaque modification du site et propose une restauration en un clic vers un point antérieur.
Cette fonction est réservée aux forfaits Business et Commerce de WordPress.com, les forfaits Personal et Premium devant être mis à niveau.
Restaurer écrase le site avec le contenu du point choisi, et tout changement postérieur disparaît, sauf copie préalable, restauration sélective ou site de test créé à l’avance.
Le temps d’exécution varie de quelques minutes à plusieurs heures selon la taille du site, avec une notification par e-mail à la fin.
Pour un déménagement de site, préférez le déplacement du domaine, le clonage ou l’outil Migrate to WordPress.com, la sauvegarde n’étant pas conçue pour cet usage.
Le piège des abonnements WooCommerce
Sur une boutique équipée de WooCommerce Subscriptions, restaurer la base de données peut re-facturer des clients pour une période déjà réglée.
Le mécanisme est simple : l’enregistrement de l’abonnement revient à son état antérieur, programmé via Action Scheduler ou des post meta, tandis que les commandes, elles, restent à jour.
La séquence recommandée tient en quatre temps : prévenir les clients, mettre en pause les renouvellements automatiques, restaurer, puis vérifier et annuler les commandes de renouvellement en double.
Il existe une porte de sortie plus sûre : décocher la case Site database sur l’écran de restauration pour ne remettre que les fichiers, laissant les enregistrements d’abonnement intacts.
Sur une boutique active, testez toujours la restauration sur un site de test avant de toucher la production.
Récupérer une sauvegarde et la remonter ailleurs
Le téléchargement complet s’effectue depuis Jetpack > Backup, en choisissant une date, puis Download backup et Create downloadable file, le fichier arrivant en direct ou par e-mail.
Les composants se récupèrent séparément : thèmes, plugins, racine WordPress avec wp-config.php, dossier wp-content hors thèmes, plugins et médias, base de données et fichiers média.
Attention au couple obligatoire : pour restaurer les médias, la base de données doit être sélectionnée elle aussi.
Sur un site auto-hébergé ou local, la procédure documentée par la documentation officielle de WordPress.com sur le téléchargement des sauvegardes consiste à extraire l’archive .tar.gz, uploader wp-content par FTP, puis importer les fichiers .sql via phpMyAdmin.
Importez d’abord le fichier principal, ensuite les fichiers de mise à jour, et modifiez siteurl et home dans la table wp_options si l’adresse change.
Par où commencer cette semaine
Vérifiez d’abord où vivent vos copies : si elles partagent le disque du site, vous n’avez pas de sauvegarde.
Programmez ensuite une restauration à blanc sur un site de test, en notant la durée réelle et les étapes qui coincent.
Si votre site vend des abonnements, écrivez la procédure de mise en pause des renouvellements avant d’en avoir besoin.
Nous traitons ces sujets d’outillage et de méthode dans nos autres analyses, comme notre comparatif des plugins IA pour Obsidian en 2026, et nous accompagnons ces chantiers via nos solutions dédiées aux TPE et PME.
FAQ
Mon hébergeur fait des sauvegardes, est-ce suffisant ?
Cela dépend de leur nature et de leur emplacement. Une copie stockée sur la même infrastructure ne vous protège ni d’une suspension de compte pour facture impayée, ni d’une corruption propagée. Gardez au moins un jeu de fichiers récupérable en dehors de l’hébergeur, et vérifiez que vous savez le remonter seul, sans dépendre d’un support technique.
Combien de temps prend une restauration complète ?
De quelques minutes à plusieurs heures selon le volume du site, avec une notification par e-mail une fois l’opération terminée. Un site vitrine léger revient vite, une boutique avec des milliers de médias et une base volumineuse demande nettement plus. Mesurez cette durée sur un site de test pour annoncer un délai crédible à vos clients le jour de l’incident.
Puis-je restaurer sans écraser les données récentes ?
Oui, par la restauration sélective. Décocher la case Site database remet uniquement les fichiers, thèmes et plugins, sans toucher aux contenus et aux enregistrements enregistrés depuis la sauvegarde. C’est la méthode à privilégier après une infection de fichiers ou une mise à jour d’extension ratée, lorsque la base, elle, reste saine et à jour.