La sonde est restée verte deux jours sur un site en erreur de base

Du 14 septembre 2026 à 6h03 jusqu'au 16 en début d'après-midi, un site WordPress du parc a rendu une erreur de base sur toutes ses pages non cachées. L'accueil était en cache, et c'est l'accueil que la sonde regardait.

Un cache de page, WP Rocket, WP Fastest Cache, LiteSpeed, écrit la page rendue dans un fichier HTML et laisse le serveur web le servir par une règle de réécriture. La requête ne touche ni PHP ni la base. Une sonde posée sur cette page mesure donc le disque du serveur web.

J'ai monté un banc le 16 pour le chiffrer : WordPress 6.7 et MariaDB en conteneurs, les règles de réécriture d'un cache de page, l'accueil déjà en cache. Base arrêtée, l'accueil rend 200 en 4 millisecondes. /wp-json/wp/v2/pages, /feed/, /panier/ et /mon-compte/ rendent 500.

Deuxième cas, plus sournois. La base tourne, la table de contenu est illisible. L'accueil rend toujours 200, et /wp-json/wp/v2/pages rend 200 aussi, avec une liste vide : WordPress avale l'erreur SQL de sa boucle sans planter. Une sonde qui se contente du code HTTP passe à côté.

L'adresse qui tient :

/wp-json/wp/v2/pages?per_page=1&_fields=id

avec un mot-clé exigé dans la réponse, "id". Les paramètres la sortent du cache par construction, puisqu'une règle de cache de page exige une chaîne de requête vide. Elle pèse de 10 à 17 octets, contre 100 à 950 Ko pour une page d'accueil, et coûte 10 millisecondes au banc.

pages et pas posts. Sur les 41 WordPress du parc, posts rend une liste vide sur treize sites qui n'ont aucun article publié. pages rend un identifiant sur les 41.

J'ai essayé le reste avant. Le flux RSS répond 404 sur un site, 500 sur un autre, et du HTML sur deux de plus. L'adresse de connexion disparaît dès qu'une extension la masque. Le paramètre aléatoire collé à l'accueil pour contourner le cache marche, mais il force un rendu complet à chaque passage, environ 180 par heure et par site, sur un chemin qu'aucun visiteur ne prend. Je l'avais retiré du parc cinq jours plus tôt.

PrestaShop n'a pas ce problème. Il se connecte à la base pendant son démarrage, avant de rendre quoi que ce soit : base arrêtée, l'accueil rend 500 sur un banc PrestaShop 8 sans cache de page. Les huit boutiques du parc posent un identifiant de session PHP à chaque requête, y compris celle qui porte un cache de page : PHP tourne donc à chaque fois.

Si tu montes le même banc, l'image officielle de WordPress laisse AllowOverride à None. Ton .htaccess n'est pas lu, le cache ne sert rien, et le banc te dit que tout va bien.

retour aux notes