Quelles alertes de l'écran Santé du site comptent vraiment ?

L'écran Santé du site de WordPress affiche un état général, une liste de tests réussis et une liste de problèmes, et il produit chez la plupart des utilisateurs l'une de deux réactions également inutiles : l'inquiétude devant une mention orange qui ne recouvre rien de grave, ou l'indifférence complète après avoir constaté qu'un site parfaitement sain n'atteint jamais le sans faute. La vérité est entre les deux. Cet écran contient trois ou quatre signaux qui méritent une intervention le jour même, une dizaine d'observations purement informatives, et un score composite qui n'a aucune signification opérationnelle. Savoir trier prend quelques minutes une fois pour toutes, et transforme un écran décoratif en véritable outil de diagnostic, utilisable notamment à chaque reprise de site.

À quoi sert vraiment l'écran de santé

Comprendre comment cet écran est construit explique à la fois sa valeur et ses limites, et évite de lui faire dire ce qu'il ne dit pas. Il s'agit d'un ensemble de tests indépendants, ajoutés au fil des versions et enrichis par les extensions installées. Nous revenons régulièrement sur ces mécanismes dans la rubrique administration de WordPress.

Deux onglets, deux natures d'information

Le premier onglet liste des tests avec un verdict, le second présente un inventaire complet de l'environnement technique : version du serveur, modules disponibles, constantes définies, tailles des répertoires, extensions actives. Le premier est un diagnostic, le second une fiche signalétique. Dans la pratique, c'est le second qui rend le plus de services, puisqu'il donne en un écran tout ce qu'un prestataire demande avant d'intervenir, et qu'il évite une demi journée d'allers retours pour obtenir la version de la base de données ou la limite de mémoire allouée. Beaucoup de personnes ne l'ouvrent jamais, obnubilées par le score du premier onglet.

Un score qui ne veut pas dire grand chose

L'état général est calculé en pondérant les tests réussis et échoués, sans distinguer un problème de sécurité réel d'une recommandation de confort. Un site à quatre vingt dix pour cent peut tourner sur une version de PHP abandonnée, et un site à soixante dix pour cent être parfaitement à jour et sécurisé, simplement parce qu'il ne dispose pas de trois modules facultatifs. Ce chiffre n'est donc pas un indicateur de qualité et ne doit jamais servir d'objectif. Le seul usage raisonnable consiste à observer sa variation dans le temps sur une même installation, un changement brusque signalant qu'un test a basculé.

Des tests exécutés à la volée

Une partie des tests est effectuée directement au chargement de la page, une autre par des requêtes asynchrones lancées ensuite. Cela explique que la liste se complète progressivement à l'ouverture de l'écran, et qu'elle diffère parfois d'un affichage à l'autre lorsque le serveur répond lentement. Cela explique aussi que cet écran soit relativement coûteux à afficher : plusieurs tests interrogent le site lui même par le réseau, avec les délais que cela suppose. Il n'y a donc aucun intérêt à le garder ouvert en permanence, contrairement à ce que son apparence de tableau de bord suggère.

Des tests apportés par les extensions

WordPress ouvre un point d'entrée permettant à n'importe quelle extension d'ajouter ses propres tests, et beaucoup ne s'en privent pas. Une part significative des alertes affichées sur une installation chargée ne vient donc pas du cœur mais des extensions, avec une qualité très inégale : certaines signalent un vrai problème de configuration, d'autres profitent de l'emplacement pour recommander une version payante. L'origine de chaque test n'étant pas affichée clairement, la première question à se poser devant une alerte inhabituelle est de savoir qui l'a écrite, et pourquoi.

Ce que l'écran ne teste pas

Il faut surtout retenir ce qui n'y figure pas. L'écran ne teste ni l'intégrité des fichiers du cœur, ni la présence de code injecté, ni la validité du certificat, ni l'état des sauvegardes, ni les performances réelles vues par un visiteur, ni l'espace disque disponible chez l'hébergeur. Un site entièrement compromis peut afficher un état général excellent. Prendre cet écran pour un contrôle de sécurité est l'erreur d'interprétation la plus répandue, et la plus coûteuse, puisqu'elle donne un sentiment de sûreté sans aucun fondement technique.

Les alertes qui appellent une intervention immédiate

Voici la liste courte. Chacun de ces signaux correspond à un risque réel ou à une fonction du site déjà dégradée, même lorsque rien ne se voit encore côté visiteur. Certaines de ces situations mènent d'ailleurs à un WordPress devenu inaccessible quelques semaines plus tard.

Une version de PHP obsolète

C'est de loin l'alerte la plus importante et la plus ignorée. Une version de PHP sortie du support ne reçoit plus de correctifs de sécurité, ce qui expose l'ensemble du serveur, et elle finit par empêcher la mise à jour des extensions qui exigent une version plus récente. Le changement se fait en général en une manipulation dans l'interface de l'hébergeur, et le seul risque réel concerne les sites utilisant un code ancien et non maintenu. La bonne méthode consiste à basculer d'abord une copie de recette, à parcourir les écrans principaux, puis à basculer la production.

Des mises à jour de sécurité en attente

L'écran signale les mises à jour disponibles pour le cœur, les thèmes et les extensions. Toutes n'ont pas la même urgence, mais celles qui corrigent une faille publiée sont exploitées automatiquement dans les jours qui suivent leur annonce, par des robots qui parcourent le web à la recherche des versions vulnérables. Le délai entre publication de la faille et exploitation massive se compte désormais en heures pour les extensions très répandues. Toute mise à jour marquée comme corrigeant un problème de sécurité doit donc être appliquée sans attendre le créneau de maintenance habituel.

Les tâches planifiées bloquées

WordPress s'appuie sur un ordonnanceur interne pour publier les contenus programmés, envoyer les courriels, purger les corbeilles et déclencher les traitements des extensions. Quand l'écran indique que ce mécanisme ne fonctionne pas, une partie du site s'est déjà arrêtée silencieusement : des articles programmés restent en attente, des commandes ne partent pas, des sauvegardes ne se déclenchent plus. La cause est presque toujours une constante de désactivation restée en place ou un blocage des requêtes locales par le pare feu. Le sujet est développé dans notre article sur la façon de programmer une tâche récurrente propre.

L'interface de programmation inaccessible

Un échec sur ce test signifie que le site n'arrive pas à s'interroger lui même par le réseau. Les conséquences sont larges et souvent mal attribuées : l'éditeur de blocs peut refuser d'enregistrer, les mises à jour automatiques cessent, plusieurs extensions perdent leurs fonctions dynamiques. Les causes fréquentes sont un blocage par un pare feu applicatif, une protection par mot de passe restée active sur une préproduction, ou une résolution de nom incorrecte sur le serveur qui empêche celui ci de s'atteindre par son propre domaine.

La communication sortante impossible

Si le serveur ne peut pas joindre l'extérieur, le site ne reçoit plus la liste des mises à jour disponibles et ne peut plus les télécharger. Il se fige alors dans son état actuel tout en affichant une administration parfaitement normale, ce qui en fait un des scénarios les plus dangereux : le site paraît à jour parce qu'aucune mise à jour ne lui est proposée. Ce cas se rencontre sur des hébergements où les connexions sortantes sont filtrées, et il faut alors demander l'ouverture explicite des adresses nécessaires.

Le mode de débogage actif en production

L'affichage des erreurs sur un site public révèle des chemins de fichiers, des noms de tables et parfois des fragments de configuration, autant d'informations qui facilitent une attaque et qui apparaissent en clair au milieu des pages. Le mode de débogage doit rester actif dans son écriture en journal, ce qui est utile, mais jamais dans son affichage à l'écran. Cette alerte apparaît régulièrement après une intervention technique où la constante a été modifiée puis oubliée, et elle mérite une correction dans la journée.

Les alertes que l'on peut laisser en l'état

Ces observations reviennent sur presque toutes les installations et n'appellent aucune action sur la grande majorité des sites. Les traiter par principe, pour faire monter le score, consomme du temps sans produire le moindre effet mesurable.

Les modules PHP recommandés absents

WordPress recommande une liste de modules facultatifs, dont certains ne servent qu'à des fonctions très particulières comme le traitement d'images exotiques ou des opérations sur des jeux de caractères rares. Sur un site standard, leur absence ne change strictement rien. Le seul cas à examiner concerne les modules de traitement d'images et de compression, dont l'absence peut effectivement dégrader la génération des miniatures. Pour tous les autres, la bonne réponse consiste à vérifier si une fonction attendue manque réellement, et non à demander leur installation par principe.

Le cache de pages non détecté

Ce test cherche des marqueurs laissés par les solutions de cache les plus courantes. Un site servi derrière un cache au niveau du serveur, un réseau de diffusion ou un mandataire inverse affichera un échec alors que ses pages sont en réalité servies instantanément. L'alerte est donc structurellement peu fiable, et la seule vérification qui vaut consiste à mesurer le temps de réponse depuis l'extérieur sur une page non connectée, ce qui donne une réponse en dix secondes et sans ambiguïté.

Les thèmes et extensions inactifs

La recommandation de supprimer les thèmes et extensions inactifs est fondée sur un raisonnement de surface d'attaque, mais un code non chargé n'est exploitable que dans des scénarios très particuliers, où l'attaquant peut déjà atteindre directement un fichier. Conserver un thème par défaut récent est même une bonne pratique, puisqu'il sert de recours lorsqu'un thème principal casse. La règle raisonnable consiste à garder un thème de secours à jour et à supprimer tout le reste, sans faire de cette tâche une urgence.

La compression de sortie non détectée

Comme pour le cache, ce test observe la réponse telle que le site se la sert à lui même, et non telle que la reçoit un visiteur. La compression est très souvent appliquée en amont, par le serveur web ou par le réseau de diffusion, sans que le site en ait connaissance. Un contrôle depuis un navigateur en observant les en têtes de réponse tranche immédiatement, et l'alerte peut être ignorée dès lors que la compression est confirmée à ce niveau.

L'écriture de fichiers désactivée

Sur les installations où les mises à jour sont gérées par un outil de déploiement, l'écriture directe est volontairement interdite, ce qui provoque une alerte. Il s'agit dans ce cas d'un choix d'architecture et non d'un défaut, et la corriger reviendrait à affaiblir le dispositif. Il faut simplement s'assurer qu'un processus de mise à jour existe réellement par ailleurs, car la même alerte apparaît sur les sites où les droits ont été mal réglés et où plus aucune mise à jour n'est possible.

En faire un outil de suivi plutôt qu'un tableau de bord

L'écran prend toute sa valeur lorsqu'il est consulté à des moments précis plutôt que régulièrement, et lorsque ses informations sont conservées pour être comparées.

Relever l'état à la reprise d'un site

À la reprise d'une installation inconnue, le second onglet donne en une capture la version du serveur, celle de la base de données, les limites de mémoire et de téléversement, la liste des extensions et l'occupation disque des répertoires. Ce relevé, archivé avec la date, constitue le point de départ de tout diagnostic ultérieur et permet de dater précisément les évolutions. C'est le premier geste que nous effectuons avant toute intervention sur un site que nous ne connaissons pas.

Vérifier après chaque intervention

Une migration, un changement d'hébergement ou une mise à jour majeure font régulièrement basculer les tests de communication réseau et de tâches planifiées, sans aucun signe visible sur le site public. Ouvrir l'écran après l'intervention, et non le lendemain, permet d'attribuer immédiatement la régression à sa cause. Passé quelques jours, le lien devient impossible à établir et le diagnostic prend dix fois plus de temps pour un résultat identique.

Le rapport d'informations pour le support

Le bouton de copie des informations produit un rapport complet en texte, prêt à être transmis à un hébergeur ou à un éditeur d'extension. Il évite la série de questions et de réponses qui précède habituellement toute prise en charge, et il fait gagner un jour entier sur un incident traité par un support externe. Une relecture rapide s'impose avant l'envoi, ce rapport contenant des chemins de fichiers et la liste complète des extensions, informations qu'il vaut mieux ne pas diffuser largement.

Surveiller depuis l'extérieur

Les signaux vraiment critiques, la disponibilité du site, la validité du certificat, le temps de réponse et l'apparition d'un contenu inattendu, ne peuvent pas être observés depuis l'intérieur de l'installation. Ils demandent un contrôle externe, indépendant du serveur, qui alerte quand le site ne répond plus. L'écran de santé ne remplace en rien ce dispositif, et un site correctement exploité dispose des deux, chacun couvrant ce que l'autre ne voit pas.

Masquer l'écran aux profils non techniques

Sur un site confié à une équipe éditoriale, cet écran génère des questions et parfois de l'inquiétude sans qu'aucune action ne soit possible du côté des personnes qui le consultent. Le retirer des menus pour les rôles qui ne peuvent de toute façon rien corriger relève du bon sens, à condition que quelqu'un le consulte effectivement par ailleurs. Un écran de diagnostic que personne n'ouvre ne vaut pas mieux qu'un écran qui inquiète tout le monde sans motif.

Ce qu'il faut surveiller à côté

Un dispositif de suivi complet comprend le contrôle externe de disponibilité, la vérification des sauvegardes par une restauration réelle et non par la seule présence des fichiers, le suivi des journaux d'erreurs du serveur, et l'espace disque disponible. Ces quatre points couvrent l'essentiel de ce qui provoque une panne durable, et aucun ne figure dans l'écran de santé. Le considérer comme un complément, et non comme le tableau de bord de l'exploitation, est la seule façon d'en tirer quelque chose d'utile. Une note d'une page décrivant qui contrôle quoi, à quelle fréquence et par quel moyen suffit à rendre ce dispositif durable, y compris lorsque la personne qui l'a mis en place n'est plus celle qui l'exploite.