Restaurer son site après un incident : comment ça se passe vraiment

Restaurer son site est le moment de vérité d’une sauvegarde. On parle beaucoup de sauvegarder, rarement de restaurer — pourtant c’est la seule étape qui compte réellement. Une sauvegarde qui existe mais qu’on ne sait pas exploiter ne protège de rien.

Voici ce qui se passe concrètement quand un site doit être remis en état : ce qu’on peut récupérer, à quelle date, et surtout les erreurs qui transforment un incident bénin en perte définitive.

Les quatre incidents qui mènent à une restauration

Dans la pratique, les demandes de restauration se répartissent presque toujours en quatre catégories :

• La mise à jour qui casse tout. Une extension ou un thème mis à jour rend le site blanc ou inutilisable. C’est de loin le cas le plus fréquent, et le plus simple à traiter.
• La suppression accidentelle. Une page, un article, une image, une boîte mail effacée par erreur — parfois remarquée plusieurs jours plus tard.
• La compromission. Le site a été piraté, du code malveillant a été injecté. Il faut revenir à un état antérieur à l’intrusion.
• La défaillance technique. Corruption de base de données, incident matériel, migration ratée.

Chacun appelle une réponse différente. C’est précisément pour cela que la granularité de la restauration compte autant que l’existence de la sauvegarde.

Restauration complète ou partielle : deux logiques opposées

La restauration granulaire permet de ne remettre en état que ce qui doit l’être. Selon la situation, on peut restaurer :

• l’intégralité du compte d’hébergement, à une date donnée ;
• la base de données seule, en conservant les fichiers actuels ;
• les fichiers seuls, en conservant la base ;
• une boîte de messagerie ;
• un unique fichier ou un unique répertoire.

Cette souplesse évite l’écueil principal d’une restauration : écraser des données récentes qui n’avaient aucun problème. Si une seule image a été supprimée, il serait absurde de remonter tout le site à la semaine dernière et de perdre au passage les commandes des trois derniers jours.

L’erreur la plus coûteuse : restaurer trop large, trop vite

Voici le scénario que nous voyons le plus souvent, et il mérite d’être connu.

Un site fonctionne correctement lundi. Le client publie du contenu, reçoit des commandes et des messages mardi et mercredi. Jeudi après-midi, il constate un problème d’affichage, panique, et restaure la sauvegarde la plus ancienne qu’il trouve « pour être sûr de revenir à quelque chose qui marchait ».

Il vient d’effacer mardi et mercredi. Le problème d’affichage, lui, venait d’un simple cache.

Deux réflexes évitent cette situation :

• Identifiez la date exacte du dernier état correct avant de restaurer quoi que ce soit. « Ça marchait la semaine dernière » n’est pas une date.
• Restaurez le plus étroitement possible. Un fichier plutôt qu’un répertoire, un répertoire plutôt qu’un compte entier.

En cas de doute, une demande au support coûte quelques minutes d’attente. Une restauration mal ciblée coûte des jours de données.

Jusqu’à quand peut-on remonter ?

Chez CCN Technologies, nous conservons sept points de restauration glissants : une semaine complète. Chaque nuit, une nouvelle sauvegarde est créée et la plus ancienne est retirée.

Cette fenêtre est dimensionnée pour couvrir le délai réel de détection d’un incident. Un problème visible est remarqué en quelques heures ; un problème discret — un contenu supprimé, une base partiellement corrompue — met souvent plusieurs jours à se manifester. Une semaine d’historique couvre l’immense majorité des cas.

Ce que la restauration ne peut pas récupérer

Un point d’honnêteté qui évite bien des malentendus : une sauvegarde quotidienne restaure l’état du site au moment de la dernière sauvegarde, pas l’état d’il y a cinq minutes.

Concrètement, les données créées depuis la dernière sauvegarde nocturne — commandes du matin, e-mails reçus dans la journée, article publié à midi — ne figurent dans aucune copie. C’est le fonctionnement de tout système de sauvegarde périodique, quel que soit l’hébergeur.

C’est aussi la raison pour laquelle une boutique à fort volume gagne à discuter d’une fréquence renforcée : moins de temps entre deux points, moins de données exposées.

Combien de temps prend une restauration ?

Cela dépend directement du volume et de la nature de la demande. Un fichier isolé se récupère rapidement. Un compte complet, avec des milliers de fichiers et une base volumineuse, demande davantage de temps — le facteur limitant étant le transfert depuis le stockage distant et la remise en place des données.

Nous nous méfions des hébergeurs qui annoncent un délai garanti sans connaître votre situation. Le support vous communique une estimation dès la prise en charge, une fois le périmètre identifié.

Comment demander une restauration

Trois informations suffisent à traiter une demande rapidement :

• Quoi — le site, le fichier, la base ou la boîte mail concernée ;
• Quand — la date du dernier état correct, même approximative ;
• Quoi conserver — s’il y a des données récentes à ne surtout pas écraser.

Cette troisième information est celle qu’on oublie le plus souvent, et c’est celle qui nous permet de choisir la bonne stratégie de restauration.

Restaurer son site : les réflexes à garder en tête

Avant de restaurer son site, prenez quelques minutes pour qualifier l’incident : ce temps est presque toujours regagné ensuite. Une restauration ciblée, sur la bonne date, évite de perdre les commandes, messages ou articles enregistrés depuis la dernière sauvegarde.

• Identifiez précisément ce qui est cassé : fichiers, base de données ou e-mails.
• Choisissez le point de restauration le plus récent qui précède l’incident, pas le plus ancien par précaution.
• Exportez ce qui a changé depuis (commandes, formulaires) avant de restaurer son site, pour pouvoir le réintégrer.
• Après la restauration, mettez à jour WordPress, le thème et les extensions, puis changez les mots de passe si une intrusion est en cause.

Pour aller plus loin, la documentation officielle de WordPress consacre un guide aux sauvegardes et à la restauration d’un site WordPress.

Questions fréquentes sur la restauration

La restauration efface-t-elle mes données récentes ?

Elle ramène l’élément restauré à l’état du point de sauvegarde choisi. Tout ce qui a été créé après cette date, dans le périmètre restauré, est remplacé. C’est pourquoi il vaut mieux restaurer le plus étroitement possible et préciser ce qui doit être conservé.

Puis-je restaurer uniquement ma base de données ?

Oui. Fichiers et base de données peuvent être restaurés séparément. C’est particulièrement utile lorsqu’une extension a corrompu des tables sans toucher aux fichiers.

Que faire si mon site a été piraté ?

Contactez le support avant de restaurer. Restaurer sans avoir identifié la faille d’origine mène presque toujours à une nouvelle compromission quelques jours plus tard. Le nettoyage doit accompagner la restauration — c’est aussi le rôle de la protection en temps réel Imunify360 déployée sur nos serveurs.

Puis-je télécharger une sauvegarde pour la conserver moi-même ?

Oui, sur demande auprès du support. C’est une bonne pratique avant une refonte importante, une migration, ou si vous quittez notre infrastructure.

Que se passe-t-il si je résilie mon hébergement ?

Les sauvegardes sont conservées un temps limité après la fermeture du compte, puis supprimées définitivement. Demandez une copie de vos données avant la résiliation.

Une restauration bien menée transforme un incident en simple contretemps. Pour comprendre ce qui rend cette opération possible — et pourquoi tous les hébergeurs ne peuvent pas l’offrir — lisez notre article sur les cinq questions à poser à votre hébergeur sur ses sauvegardes.

Un fichier à récupérer ou une page revenue à un état antérieur ? Contactez notre support, nous nous en occupons.