Conseils TI pour PME

Sauvegarde WordPress : la différence entre avoir une copie et pouvoir restaurer

Le tableau de bord indique que la copie de la nuit dernière est terminée. C’est rassurant, mais ce n’est pas encore une preuve que le site reviendra correctement après une panne, une erreur de mise à jour ou un compte compromis. Une sauvegarde WordPress PME devient utile seulement lorsqu’on sait quoi restaurer, où le faire et combien de temps l’opération prend.

Gros plan sur du code HTML coloré affiché sur un écran sombre

Une sauvegarde WordPress PME doit couvrir plus que les pages

Un site WordPress est un ensemble de pièces. Les fichiers contiennent le thème, les extensions et les médias. La base de données contient notamment les pages, les réglages, les comptes et, selon le site, les formulaires ou les commandes. Copier seulement le dossier des images ne suffit donc pas. Sauvegarder uniquement la base de données ne permet pas non plus de reconstruire le site à l’identique.

Il faut aussi connaître les éléments qui vivent ailleurs : configuration DNS, boîte courriel qui reçoit les formulaires, licence d’une extension, certificat, compte du registraire et paramètres du serveur. Ils ne doivent pas tous se trouver dans la même archive, mais leur emplacement et leur responsable devraient être documentés.

Commencez par une question concrète : si le serveur disparaissait ce matin, quels fichiers, accès et renseignements faudrait-il pour remettre le site en ligne sur un autre environnement? La réponse expose rapidement les trous dans une copie automatique trop limitée.

Choisir la fréquence selon ce qui change

La bonne fréquence dépend du rythme réel du site. Un site vitrine modifié quelques fois par mois n’a pas les mêmes besoins qu’une boutique qui reçoit des commandes chaque heure. Les contenus, la base de données et les fichiers peuvent d’ailleurs suivre des fréquences différentes.

Déterminez la quantité de travail que l’entreprise accepte de perdre. Si une journée de demandes de soumission doit être ressaisie, vérifiez si les formulaires sont inclus et à quel moment la base de données est copiée. Si les demandes arrivent aussi par courriel, confirmez que cette boîte relève d’une stratégie distincte.

Prévoyez également une rétention assez longue pour remonter avant un problème discret. Une extension malveillante ou une erreur de contenu peut passer inaperçue plusieurs jours. Dix copies identiques créées après l’incident n’aident pas à retrouver un état sain.

Garder une copie hors du même hébergement

Une archive stockée sur le même compte que le site peut disparaître avec lui. Une suspension, une erreur administrative, une panne de stockage ou un accès compromis peut toucher la production et ses sauvegardes au même endroit. Conservez au moins une copie dans un emplacement distinct, avec des accès séparés et contrôlés.

Distinct ne veut pas seulement dire un autre dossier sur le serveur. Il peut s’agir d’un stockage infonuagique indépendant ou d’un service de sauvegarde géré séparément. Chiffrez les copies lorsqu’elles contiennent des renseignements sensibles et limitez les personnes capables de les supprimer.

La page sur l’hébergement web d’Infotech Canada présente l’accompagnement disponible pour les PME qui veulent clarifier la maintenance, la surveillance et la continuité de leur site.

Tester la restauration dans un environnement isolé

Le test le plus utile ne se fait pas directement sur le site public. Restaurez une copie dans un environnement temporaire ou de staging, puis ouvrez les pages importantes. Vérifiez la navigation, les images, la connexion, les formulaires et les fonctions propres à l’entreprise. Un formulaire qui affiche « envoyé » sans livrer le courriel reste une restauration incomplète.

Notez la date du test, la copie utilisée, le temps requis et les erreurs rencontrées. Vérifiez aussi la version de PHP, la base de données et les dépendances : une archive valide peut refuser de démarrer sur un environnement devenu incompatible. Après le test, supprimez proprement l’environnement temporaire pour éviter qu’il devienne une copie oubliée et exposée.

Un test réaliste révèle souvent de petits obstacles : le compte du registraire appartient à un ancien fournisseur, l’authentification multifacteur dépend du téléphone d’une seule personne ou personne ne connaît la clé de licence d’une extension essentielle. Ces détails déterminent le délai réel de retour en service.

Attribuer les responsabilités avant l’incident

Écrivez qui surveille les échecs, qui peut lancer une restauration et qui autorise le basculement. Le propriétaire du site, l’agence web et l’hébergeur n’assument pas toujours les mêmes tâches. Une phrase précise dans le contrat ou la procédure vaut mieux qu’une supposition partagée par trois fournisseurs.

Le dossier devrait indiquer où se trouvent les sauvegardes, la durée de conservation, les coordonnées utiles et les étapes prioritaires. N’y collez pas les mots de passe : référencez plutôt un coffre d’entreprise accessible aux personnes autorisées. Révisez cette information lorsqu’un employé part, qu’un domaine est transféré ou que l’hébergement change.

Enfin, fixez un prochain test. Pour une sauvegarde WordPress PME, le calendrier, la copie hors site et la procédure ne remplacent pas l’exercice de restauration. C’est lui qui transforme une promesse technique en capacité opérationnelle.

À confirmer

Fichiers, base de données, médias, formulaires, DNS, licences et accès de récupération.

À séparer

La production, les copies hors site et les comptes capables de modifier ou supprimer les archives.

À tester

Pages clés, formulaires, connexions, médias, dépendances techniques et temps réel de remise en ligne.

Valider une restauration avant d’en avoir besoin

Si vous voulez vérifier vos copies, les accès et la procédure de restauration sans toucher au site public, Infotech Canada peut vous aider à préparer un test contrôlé et une courte liste de corrections.

Planifier une rencontre

Une question précise sur votre situation? Écrivez-nous.