NOTE 02
AUTOMATISATION9 septembre 2026Trois sites cassés par la même ligne de code.
Le garde le plus répandu de l’écosystème WordPress ne protège de rien. Il m’a coûté trois sites en production avant que je le comprenne.
Le réflexe est connu de tous. Avant d’appeler une fonction d’un plugin tiers, on l’entoure d’un test qui vérifie qu’elle existe. Si elle est là, on l’appelle. Sinon, on ne fait rien. Cela paraît imparable.
Cela ne l’est pas. Le test répond sur la fonction, pas sur ce dont elle a besoin pour tourner. Un plugin peut être chargé sans être initialisé. Ses classes internes existent, ses dépendances non. La fonction répond présent, elle part chercher un objet qui n’est pas encore là, et le site s’arrête sur une erreur fatale.
J’ai vu ce scénario trois fois en trois mois, sur trois sites différents, avec trois fonctions différentes. Une purge de cache, une mise à jour du cœur, une routine de nettoyage. À chaque fois le même motif, du code placé en portée globale qui appelle un plugin tiers, protégé par un test qui rassure sans rien garantir.
La leçon n’est pas d’écrire un meilleur test. C’est que la protection ne pouvait pas exister à cet endroit. Une purge de cache se déclenche depuis l’administration ou en ligne de commande. Une mise à jour aussi. Rien de tout cela n’a sa place dans un bout de code qui s’exécute à chaque chargement de page.
Depuis, la règle n’est plus un texte que je relis. C’est un programme qui refuse d’écrire le fichier. Il tourne avant chaque écriture, dans tous les modes, y compris celui qui désactive toutes les autres protections. Il a déjà refusé mes propres commandes plusieurs fois, et il avait raison à chaque fois.