Un site WordPress qu’on ne met plus à jour ne s’éteint pas. Il continue de s’afficher, de recevoir des visiteurs, parfois pendant des années. C’est là tout le problème : la dégradation ne se voit pas depuis la page d’accueil, et le moment où elle devient visible est rarement le moment où elle a commencé.
Une mise à jour de sécurité rend la faille publique
C’est le point que l’on comprend le plus tard. Quand WordPress ou une extension publie un correctif de sécurité, la note de version décrit ce qui a été corrigé. Autrement dit, le jour de la publication, la faille cesse d’être connue de quelques spécialistes pour devenir un mode d’emploi accessible à tous.
Les sites qui appliquent le correctif dans la foulée sortent du jeu. Ceux qui ne l’appliquent pas deviennent, à partir de cette date précise, plus faciles à atteindre qu’ils ne l’étaient la veille. Ne pas mettre à jour n’est donc pas rester au même niveau de risque : c’est le voir augmenter à chaque publication.
Ce qui balaie le web à la recherche de ces versions n’est pas un attaquant qui vous a choisi, mais un programme qui teste des adresses en série. Une petite entreprise n’est pas moins exposée qu’une grande : elle est simplement moins susceptible de s’en apercevoir.
Ce qui se dégrade, et dans quel ordre
La perte de contrôle est progressive, et suit à peu près toujours la même pente.
D’abord les extensions abandonnées. Un module qui n’a pas reçu de mise à jour depuis deux ans n’est pas nécessairement dangereux, mais plus personne ne corrigera la prochaine faille qui y sera trouvée. Le repérer demande d’aller regarder ; rien dans l’administration ne le signale spontanément.
Ensuite la version de PHP. C’est le langage sur lequel tourne WordPress, et chaque version cesse un jour d’être maintenue par ses auteurs. Un hébergeur qui la met à jour peut casser un site trop ancien pour la suivre ; un hébergeur qui ne la met pas à jour laisse tourner une base qui ne reçoit plus de correctifs. Les deux situations se résolvent d’autant plus facilement qu’on les anticipe.
Puis l’écart de versions lui-même. Passer d’une version à la suivante est une opération de routine. Rattraper trois ans de retard en une fois est un projet, avec des incompatibilités entre extensions, un thème qui n’a pas suivi, et des heures difficiles à estimer à l’avance. Le report a un coût, et ce coût grandit tout seul.
Un site compromis fonctionne normalement
On imagine volontiers le piratage comme une page noire annonçant que le site a été pris. C’est l’exception. Le cas courant est invisible pour le propriétaire : des pages parasites ajoutées discrètement pour profiter de la réputation du domaine, des redirections qui ne se déclenchent que pour les visiteurs venus d’un moteur de recherche, ou un serveur d’envoi de courrier détourné. Le site continue de s’afficher normalement quand vous le consultez. C’est le but.
Le moment où ça devient visible est le plus coûteux
Quand la compromission finit par se voir, elle se voit rarement en premier par vous. Un navigateur affiche un avertissement rouge avant d’ouvrir la page. Un client signale un message étrange reçu depuis votre adresse. Ou les visites s’effondrent parce que Google a retiré les pages de son index le temps de faire le ménage.
La remise en état se règle rarement en une fois. Il faut nettoyer, puis identifier par où c’est entré, sans quoi le nettoyage ne tiendra pas. Restent ensuite à remonter les versions, à demander un réexamen aux moteurs, et à attendre. Pendant ce temps, le site ne travaille plus. Pour une activité dont les contacts viennent en partie du web, c’est souvent cette interruption qui coûte le plus cher, bien plus que la réparation elle-même. Un site brutalement absent des résultats met par ailleurs beaucoup plus de temps à revenir qu’à disparaître.
Une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde
C’est la fausse sécurité la plus répandue. Une case cochée quelque part indique que des sauvegardes ont lieu, et l’on considère le sujet réglé. Trois questions suffisent pourtant à s’en assurer : depuis combien de temps la dernière restauration a-t-elle été testée, où les copies sont-elles stockées, et combien de jours en arrière permettent-elles de remonter ? Stockées sur le même serveur que le site, elles disparaîtront avec lui. Une compromission découverte au bout de six semaines rend inutile une sauvegarde qui ne conserve que sept jours.
Ce que demande réellement l’entretien
Rien d’héroïque : appliquer les correctifs dans un délai raisonnable, vérifier après coup que le site fonctionne toujours, surveiller qu’il répond, tester une restauration de temps en temps, et se débarrasser des extensions que plus personne ne maintient. Une heure par mois y suffit largement.
La difficulté n’est pas technique, elle est de régularité. Ces gestes ne produisent rien de visible quand ils sont faits, et leur absence ne se remarque pas non plus, jusqu’au jour où elle se remarque beaucoup. C’est le genre de tâche qu’on repousse sans jamais décider de l’abandonner, et c’est pour cette raison que confier l’entretien à quelqu’un dont c’est le métier règle le problème plus sûrement qu’une bonne résolution.
Reste que ce raisonnement ne s’applique qu’à WordPress. Un site sans base de données ni interface d’administration exposée présente une surface d’attaque nettement plus réduite, et c’est un argument qui pèse au moment de choisir : toutes les activités n’ont pas besoin d’un CMS.