Mises à jour et sauvegardes : la routine qui évite la panne

Un site laissé sans entretien ne tombe pas en panne le lendemain. Il se dégrade lentement, puis casse un jour où personne ne s’y attendait, généralement au pire moment. Une sauvegarde WordPress correctement configurée et une routine de mise à jour régulière évitent la quasi-totalité de ces incidents, pour un investissement d’environ un quart d’heure par mois. Le sujet paraît austère et se traite en réalité comme une check-list : quelques gestes, toujours les mêmes, dans un ordre stable. Ceux qui s’y tiennent ne connaissent presque jamais de panne grave ; les autres découvrent la question le jour où leur site affiche une page blanche.

Ce qu’il faut sauvegarder, et pourquoi la moitié ne suffit pas

Un site WordPress se compose de deux ensembles indissociables : des fichiers posés sur le serveur et une base de données qui contient les textes et les réglages. Sauvegarder l’un sans l’autre produit une restauration bancale, voire inutilisable.

Les fichiers regroupent le cœur du logiciel, le thème actif, les extensions installées et l’ensemble des médias envoyés. Les médias pèsent souvent l’essentiel du volume. La base contient les articles, les pages, les menus, les comptes, les options générales et une bonne partie de la configuration des extensions. Cette répartition, détaillée dans notre panorama du fonctionnement interne de WordPress, explique pourquoi une sauvegarde partielle ne protège de presque rien.

Un exemple rend la chose concrète. Une restauration des seuls fichiers ramène un site dont l’apparence est correcte et dont tous les textes ont disparu. Une restauration de la seule base ramène des textes qui pointent vers un thème absent. Dans les deux cas, la panne persiste.

Trois notions à distinguer

La sauvegarde est une copie conservée ailleurs. La réplication automatique proposée par certains hébergements copie l’état courant, y compris une corruption survenue il y a dix minutes : ce n’est pas la même chose. L’historique, enfin, détermine jusqu’à quelle date on peut remonter. Une copie unique écrasée chaque nuit ne protège pas d’un problème découvert trois jours plus tard.

Cette distinction devient très concrète dans un cas banal. Une extension mal mise à jour dérègle l’affichage un mardi soir. Personne ne s’en aperçoit avant le vendredi, parce que la page concernée est peu visitée. Un système qui ne conserve que la copie de la nuit précédente aura recopié le site défectueux trois fois de suite : la sauvegarde existe, elle ne sert à rien. Un historique glissant de plusieurs jours résout ce problème pour un coût de stockage négligeable.

Sauvegarde WordPress : fréquence, portée et destination

Trois paramètres définissent une stratégie et se règlent en fonction du rythme réel du site.

La fréquence dépend de la vitesse à laquelle le contenu évolue. Un site vitrine modifié deux fois par an se contente d’une sauvegarde mensuelle complète, complétée par une copie avant chaque intervention. Un média qui publie chaque semaine réclame au minimum une copie hebdomadaire de la base. Un site où des visiteurs déposent des données mérite un rythme quotidien.

La portée distingue la copie complète, qui reprend tout, de la copie incrémentale, qui n’enregistre que les changements depuis la précédente. La seconde consomme beaucoup moins d’espace et permet des fréquences élevées, à condition que l’outil sache reconstruire une version complète au moment de la restauration.

La destination est le paramètre le plus souvent négligé. Une sauvegarde stockée sur le même serveur que le site disparaît avec lui. Une copie hors du serveur, sur un espace distant ou sur une machine locale, constitue la seule protection réelle contre une défaillance de l’hébergement.

Un principe simple résume l’ensemble : deux copies minimum, sur deux supports différents, dont une hors du serveur. Les offres d’hébergement incluent fréquemment une sauvegarde automatique dont la profondeur et la fréquence varient beaucoup ; vérifier ces deux valeurs fait partie des points à contrôler au moment du choix, sujet abordé dans notre article sur l’hébergement et l’installation.

Le test de restauration : la seule preuve qui compte

Une sauvegarde jamais testée est une hypothèse, pas une garantie. Les archives corrompues, les exports de base incomplets et les outils mal configurés se découvrent au moment de la restauration, c’est-à-dire au plus mauvais moment possible.

Le test de restauration consiste à reconstruire le site à partir d’une copie, sur un environnement séparé, puis à vérifier que les pages s’affichent, que les images apparaissent et que l’administration reste accessible. L’opération demande une heure et se répète utilement une à deux fois par an.

Trois vérifications suffisent pour l’essentiel. L’archive contient-elle à la fois les fichiers et un fichier d’export de la base ? Son poids correspond-il approximativement à celui du site ? La copie la plus récente date-t-elle bien de la période attendue ? Une archive de deux mégaoctets pour un site qui en pèse six cents signale un problème que personne n’aurait remarqué autrement.

Un détail pratique change beaucoup de choses le jour venu : savoir combien de temps dure la restauration. Sur un site vitrine léger, l’opération prend quelques minutes. Sur un site chargé de médias, elle peut demander une heure et se heurter aux limites d’exécution de l’hébergement. Connaître cet ordre de grandeur à l’avance évite de découvrir le problème pendant l’incident, et permet d’annoncer un délai réaliste plutôt qu’une estimation optimiste.

Conserver les informations utiles

Une sauvegarde ne se limite pas à des fichiers. Les identifiants de la base, l’adresse de l’espace de stockage distant, la liste des extensions installées et la version du thème employé font partie de ce qu’il faut pouvoir retrouver. Ces éléments tiennent dans une note de dix lignes, conservée hors du site, et ils raccourcissent considérablement une remise en route.

Mettre à jour sans casser

Les mises à jour concernent trois familles : le cœur du logiciel, le thème actif, les extensions installées. Elles corrigent des failles, des incompatibilités et des dysfonctionnements. Les repousser indéfiniment expose à des risques croissants et rend le rattrapage de plus en plus délicat.

L’ordre recommandé commence toujours par une sauvegarde fraîche. Viennent ensuite les mises à jour des extensions, une par une plutôt qu’en bloc, avec une vérification rapide du site entre chacune. Puis le thème, puis le cœur du logiciel. Cette progression permet d’identifier immédiatement le composant responsable si quelque chose se dérègle.

Les mises à jour correctives du cœur s’appliquent automatiquement par défaut, et ce comportement gagne à être conservé : elles corrigent des problèmes de sécurité et modifient rarement le fonctionnement. Les mises à jour majeures, en revanche, méritent quelques jours d’attente et une lecture des notes de version, surtout sur un site qui repose sur plusieurs extensions.

Le moment et le lieu

Une mise à jour se lance en heures creuses, jamais depuis un téléphone en déplacement, et jamais la veille d’un événement important. Sur un site professionnel, un environnement de test qui reproduit la production permet d’essayer avant d’appliquer. Beaucoup d’hébergements proposent la création d’une copie de travail en quelques clics.

La règle élémentaire évite de longues recherches : une modification à la fois, une vérification après chacune. Mettre à jour douze extensions simultanément et constater ensuite un dysfonctionnement condamne à tout défaire pour trouver le coupable, sans savoir par quel bout commencer.

Quand une mise à jour tourne mal

Le scénario le plus fréquent est le site qui n’affiche plus rien après une opération. La réaction utile tient en trois gestes calmes. Renommer le dossier de l’extension suspecte depuis l’accès aux fichiers de l’hébergement la désactive de force et rend l’administration accessible. À défaut, basculer sur un thème par défaut produit le même effet quand le thème est en cause. En dernier recours, la restauration de la sauvegarde prise juste avant ramène l’état antérieur.

Deux réflexes aggravent au contraire la situation : réinstaller le logiciel par-dessus sans savoir ce qui a cassé, et enchaîner plusieurs manipulations sans noter ce qui a été fait. Une panne documentée se répare beaucoup plus vite qu’une panne sur laquelle six actions se sont accumulées.

La routine mensuelle, en dix minutes

Un rythme mensuel suffit à la plupart des sites vitrines. La séquence tient en six gestes.

Vérifier que la dernière sauvegarde existe et qu’elle date bien du mois en cours. Appliquer les mises à jour disponibles selon l’ordre décrit plus haut. Parcourir trois ou quatre pages représentatives, dont l’accueil et une page de contact. Tester le formulaire depuis une adresse extérieure. Contrôler la validité du certificat de sécurité. Jeter un œil aux comptes utilisateurs et supprimer ceux qui n’ont plus lieu d’être.

Deux gestes annuels s’y ajoutent : le test de restauration évoqué plus haut, et une revue des extensions installées. Chaque extension inutilisée se désinstalle plutôt que de rester désactivée, car un code présent sur le serveur reste une surface d’exposition. Cette revue améliore souvent la vitesse au passage, sujet traité dans notre méthode de diagnostic d’un site devenu lent.

Une sauvegarde WordPress fiable et une routine de mise à jour tenue ne rendent pas un site invulnérable. Elles transforment un incident potentiellement définitif en une interruption d’une heure, ce qui constitue la différence entre un désagrément et une perte. Le calendrier compte plus que la sophistication de l’outil : mieux vaut une copie mensuelle réellement effectuée qu’un dispositif élaboré que personne ne surveille.