Plan de maintenance WordPress : mises à jour et sécurité

Il y a quatre parties. Mettre à jour, c'est faire passer le logiciel de base, les extensions et le thème à de nouvelles versions. Sauvegarder, c'est conserver en lieu sûr une copie à la fois des fichiers et de la base de données. La sécurité consiste à refermer les failles connues, à passer en revue les comptes utilisateurs et les droits, et à rechercher les activités suspectes. La surveillance consiste à vérifier que le site est disponible, que les formulaires fonctionnent et comment tiennent des indicateurs comme la vitesse.

Ces quatre parties dépendent les unes des autres. Si aucune sauvegarde n'est faite avant une mise à jour, une mise à jour défectueuse peut être impossible à annuler. Sans surveillance, une panne causée par une mise à jour n'est remarquée que lorsqu'un visiteur se plaint. Le plan doit donc être pensé dans son ensemble, et non partie par partie.

Le noyau de WordPress, les extensions et les thèmes publient régulièrement des mises à jour, et certaines referment des failles de sécurité. Laisser des mises à jour en attente longtemps, c'est laisser ouverte une faille connue. En pratique, l'intervalle dépend de la criticité du site ; les sites très fréquentés qui prennent des commandes justifient des intervalles plus courts.

Les mises à jour ne sont pas appliquées directement au site en ligne. Une sauvegarde est d'abord faite, la mise à jour est essayée si possible sur une copie de test de même structure, et ce n'est que si rien ne casse qu'elle passe en ligne. Cet ordre compte surtout sur les sites comptant de nombreuses extensions interdépendantes, où la nouvelle version d'une extension peut entrer en conflit avec une autre.

Une courte liste de contrôle après chaque mise à jour fait partie du travail : la page d'accueil s'ouvre-t-elle, le formulaire de contact envoie-t-il un message, le parcours de paiement fonctionne-t-il ? Ces trois questions montrent si une mise à jour a discrètement cassé quelque chose.

Une bonne sauvegarde a trois qualités : elle est faite régulièrement, elle est conservée à part du serveur propre du site, et sa restauration a été testée. Une sauvegarde qui reste sur le même serveur disparaît avec le site si le serveur tombe en panne ou est attaqué. Elle doit se trouver à un autre endroit.

La fréquence des sauvegardes dépend de la fréquence à laquelle le site change. Pour un site vitrine mis à jour quelques fois par an, des sauvegardes espacées peuvent suffire ; pour une boutique qui prend des commandes chaque jour, la base de données doit être sauvegardée bien plus souvent. Le critère est la durée que vous pouvez vous permettre de perdre.

Le test de restauration est l'étape la plus souvent sautée. Si une sauvegarde existe mais ne s'ouvre pas, il n'y a pas de sauvegarde. Restaurer à intervalles fixes dans un environnement de test et voir le site démarrer est la seule preuve que le plan fonctionne.

La sécurité n'est pas un réglage fait une fois pour toutes, mais un contrôle répété à intervalles. La plupart des attaques entrent par des failles connues d'extensions obsolètes ou par des comptes d'administrateur aux mots de passe faibles. La liste des tâches de routine est donc courte et concrète ; les points ci-dessous forment la base pour la plupart des sites.

La surveillance commence par un contrôle extérieur de la disponibilité du site. Lorsque le site tombe ou affiche une page d'erreur, quelqu'un doit être prévenu. S'y ajoute le test régulier du formulaire de contact et, s'il existe, du parcours de paiement, car un formulaire peut échouer en silence même lorsque le site est ouvert.

La vitesse ainsi que les dates d'expiration du domaine et du certificat font aussi partie de la surveillance. Un certificat expiré affiche aux visiteurs un écran d'avertissement. Relier ces dates à un calendrier est l'une des étapes de surveillance les plus simples et les plus utiles.

• Supprimer les extensions et thèmes inutilisés
• Passer en revue les comptes d'administrateur et les droits
• Imposer des mots de passe robustes et la vérification en deux étapes
• Analyser le code malveillant
• Limiter les tentatives de connexion

L'erreur la plus courante est de repousser la maintenance jusqu'à l'arrivée d'une crise. Les mises à jour s'accumulent, les extensions se désaccordent et une seule grosse mise à jour finit par casser le site. De petites étapes régulières sont plus sûres que de rares grandes étapes.

La deuxième erreur est de laisser en place des extensions inutilisées. Une extension désactivée mais toujours installée peut elle aussi receler une faille. La troisième est de faire confiance à une sauvegarde qui n'a jamais été testée. La quatrième est de laisser flou qui assure la maintenance : si chacun suppose qu'un autre s'en charge, personne ne le fait. Le plan doit être écrit et chaque tâche doit avoir un responsable.

Enfin, considérer la surveillance comme inutile est une erreur courante. Si le site tombe la nuit et que personne ne s'en aperçoit avant le matin, les visiteurs et les commandes de ces heures sont perdus. Même une simple surveillance de disponibilité réduit nettement ce risque.

La maintenance a du sens sur des fondations saines. Si le site repose sur un vieux thème, des extensions abandonnées et un code personnalisé désordonné, un entretien régulier retarde le problème sans le résoudre. Sur un tel site, chaque mise à jour est un risque, et le coût de l'entretien se rapproche avec le temps de celui d'une nouvelle construction.

Le lien entre le site et l'activité doit aussi être réexaminé. Si WordPress a cessé de répondre aux besoins du site, par exemple parce qu'une logique produit complexe ou des flux de travail sur mesure sont nécessaires, revoir la structure peut valoir mieux que de continuer à la maintenir. Cette décision peut aussi naître du plan de maintenance lui-même : dès qu'il produit des rapports réguliers, on voit où les problèmes se concentrent.