La question que je pose à chaque nouveau client qui a un site : « si votre hébergeur disparaissait cette nuit, où est la copie du site ? » Neuf fois sur dix, la réponse est un silence gêné, ou « chez l’hébergeur, justement ». Ce qui revient à ne pas avoir de sauvegarde du tout.
La règle des trois copies, sans jargon
La règle 3-2-1 vient du monde professionnel de l’informatique, mais elle se résume simplement : trois copies des données, sur deux supports différents, dont une hors site. Appliquée à un site vitrine ou à une boutique en ligne, cela donne : la version en ligne (une copie), une sauvegarde stockée chez l’hébergeur ou par le plugin de sauvegarde (deuxième copie, souvent sur le même support physique que la première, donc fragile si le serveur tombe en panne totale), et une troisième copie ailleurs — un espace de stockage cloud distinct, un disque externe, peu importe, tant que ce n’est pas la même machine.
Ce qui vieillit vite avec les hébergeurs, c’est de croire que leur sauvegarde automatique suffit. Elle est utile, elle rattrape la majorité des incidents courants (mise à jour ratée, fausse manipulation), mais elle ne protège pas contre une faillite d’hébergeur, un piratage qui chiffre aussi les sauvegardes accessibles depuis le même compte, ou une erreur de facturation qui coupe l’accès du jour au lendemain.
Le risque qui justifie le plus la copie hors site reste le piratage par rançongiciel, une menace sur laquelle l’ANSSI publie régulièrement des recommandations : un attaquant qui prend le contrôle d’un serveur cherche en priorité à chiffrer ou effacer tout ce qui est accessible depuis ce même compte, sauvegardes comprises, avant de réclamer une rançon pour la restitution. Une copie stockée sur un service distinct, avec des identifiants différents de ceux du site, échappe à ce scénario et reste le seul filet de sécurité vraiment fiable dans ce cas de figure.
Ce qu’il faut sauvegarder, et ce qu’on oublie
Un site, ce n’est pas qu’un dossier de fichiers. C’est aussi une base de données qui contient les articles, les pages, les commandes, les réglages — et c’est souvent elle qu’on oublie. Un plugin de sauvegarde correctement configuré prend les deux : les fichiers (thème, images, extensions) et un export de la base de données, sous forme de snapshot daté, à un instant précis. Une sauvegarde qui ne contient que les fichiers, sans la base, ne permet de reconstruire qu’une coquille vide.
Le rythme dépend de l’activité : un site vitrine mis à jour deux fois par an peut se contenter d’une sauvegarde hebdomadaire, une boutique qui encaisse des commandes chaque jour a besoin d’un rythme quotidien, sans quoi une commande perdue lors d’une restauration devient un vrai litige avec un client.
Le nombre de copies conservées compte presque autant que la fréquence : garder uniquement la dernière sauvegarde expose au même problème qu’une absence de sauvegarde si l’incident (une mise à jour ratée, par exemple) n’est repéré que plusieurs jours plus tard, une fois cette unique copie déjà écrasée par la suivante. Conserver un historique glissant de quelques semaines, avec plusieurs points de restauration possibles, coûte très peu en espace de stockage et évite ce piège précis.
La seule sauvegarde qui compte : celle qu’on a déjà restaurée
C’est le point que je répète le plus souvent au comptoir : une sauvegarde qu’on n’a jamais testée n’est qu’une hypothèse. J’ai vu des dossiers de sauvegarde corrompus depuis des mois sans que personne ne le remarque, simplement parce que la tâche automatique tournait sans erreur visible tout en produisant des fichiers inutilisables. Une restauration testée, une fois tous les six mois, sur un site de test ou un sous-domaine temporaire, est le seul moyen de savoir si la sauvegarde fonctionne réellement, combien de temps prend l’opération, et si l’équipe sait qui appeler le jour où il faut vraiment s’en servir.
Pour une petite structure sans service informatique, cette vérification ne demande pas de compétence particulière : la plupart des extensions de sauvegarde proposent un bouton « restaurer » utilisable en quelques clics sur un environnement de test. Le vrai effort n’est pas technique, il est organisationnel : il faut simplement le mettre au calendrier, comme un rendez-vous chez le comptable, plutôt que d’attendre l’incident pour découvrir qu’il n’existait qu’un seul exemplaire du site, et qu’il vient de disparaître avec le serveur.
Une association ou un artisan qui gère aussi ses ventes en ligne a d’autant plus intérêt à soigner ce point : une commande perdue ou une base de données corrompue touche directement la relation avec les clients, pas seulement la vitrine.
Sur le plan budgétaire, la sauvegarde reste l’un des postes les plus rentables de la gestion d’un site : quelques euros par mois pour un stockage externe, contre le coût, en temps et en image, de devoir reconstruire un site vitrine à partir de rien après une panne totale. C’est aussi, souvent, le seul filet de sécurité qui permette de dormir tranquille avant une mise à jour un peu risquée du thème ou d’une extension : savoir qu’un point de restauration récent existe change complètement la façon d’aborder ce genre d’opération.
Pour qui veut comprendre plus en détail les différentes méthodes de sauvegarde (complète, incrémentielle, différentielle) et leurs usages respectifs, l’article Sauvegarde (informatique) de Wikipédia pose des bases claires, transposables sans difficulté à l’échelle d’un site web.
