Le site d’un cabinet comptable tournait sans souci depuis des mois avec une limite memory_limit de 256 Mo. Deux jours après l’installation d’un plugin de sécurité très répandu, les écrans blancs sont apparus sur l’espace d’administration, avec dans les journaux PHP la mention classique : « Allowed memory size of 268435456 bytes exhausted ». La tentation immédiate a été de désinstaller le plugin en bloc, ce qui aurait réglé le symptôme sans comprendre la cause, et surtout privé le site de la protection qu’il était censé apporter.
Le diagnostic a suivi une méthode simple : reproduire l’erreur de façon contrôlée, mesurer où va la mémoire, puis couper précisément ce qui n’était pas nécessaire plutôt que l’ensemble du plugin.
Reproduire le problème sans casser la production
Premier réflexe : cloner l’environnement en local avec la même version de PHP, la même configuration wp-config.php et un export récent de la base. Reproduire un pic mémoire nécessite en général de se placer dans les conditions qui le déclenchent : une page d’administration chargée, avec un nombre représentatif de contenus, plutôt qu’une installation vierge qui masquerait le problème.
Sur ce site, le pic apparaissait précisément sur l’écran des réglages du plugin lui-même et sur le tableau de bord, deux pages où le plugin de sécurité affiche des widgets de statistiques et de scan.
Query Monitor pour localiser les hooks gourmands
L’extension Query Monitor propose un onglet « Hooks & Actions » qui liste, pour une requête donnée, les fonctions accrochées à chaque hook avec leur temps d’exécution. Combiné à l’onglet mémoire, il a permis de voir qu’un module de scan de fichiers du plugin de sécurité s’exécutait sur l’action admin_init, à chaque chargement d’une page d’administration, et parcourait récursivement l’arborescence wp-content pour vérifier l’intégrité des fichiers.
Sur une installation avec plusieurs dizaines de milliers de fichiers médias, ce scan chargeait en mémoire la liste complète des chemins avant de la traiter, plutôt que de la traiter par lots. C’est ce comportement, documenté ensuite dans le changelog d’une version ultérieure du plugin comme un correctif de performance, qui expliquait le pic.
Confirmer avec un profiler avant de conclure
Pour confirmer l’hypothèse sans se fier uniquement à une lecture de code, un profil a été pris avec Blackfire sur une requête vers l’écran des réglages. Le graphe d’appels a montré sans ambiguïté qu’une seule fonction, liée au module de scan de fichiers, représentait plus de 80 % de la mémoire allouée pendant la requête, largement devant le reste du plugin et devant WordPress core.
$ blackfire run --samples=1 curl -s -o /dev/null "https://cabinet.example.com/wp-admin/admin.php?page=securite-scan"
Blackfire.io: Profile ready at https://blackfire.io/profiles/xxxxx
Peak memory: 231.4 MB
-> Security_Plugin\File_Scanner::build_file_index() : 189.2 MB (81.8%)
Le correctif : désactiver le module, pas le plugin
La plupart des plugins de sécurité sérieux exposent leurs modules indépendamment, souvent via des réglages dédiés ou des filtres. Dans ce cas précis, le plugin proposait un filtre pour exclure certains répertoires du scan de fichiers et un réglage pour repousser le scan complet en tâche planifiée nocturne plutôt qu’à chaque chargement d’écran d’administration.
add_filter( 'security_plugin_scan_exclude_paths', function ( $paths ) {
$paths[] = WP_CONTENT_DIR . '/uploads';
return $paths;
} );
add_filter( 'security_plugin_scan_on_admin_init', '__return_false' );
Après ce changement, le scan de fichiers ne s’exécutait plus qu’une fois par nuit via une tâche planifiée, avec un montant de mémoire acceptable puisqu’aucun visiteur n’attendait la réponse. Le pare-feu applicatif et les autres protections en temps réel du plugin sont restés actifs.
Faut-il quand même remonter la limite de mémoire
Même après le correctif ciblé, l’équipe a choisi de remonter la limite memory_limit de 256 Mo à 512 Mo dans la configuration PHP-FPM, par prudence face à de futurs pics ponctuels, sans en faire une solution de fond. Une limite plus haute masque les erreurs plus longtemps, elle ne les corrige pas ; elle sert de filet de sécurité, pas de stratégie principale.
- Diagnostiquer avant d’agir : reproduire, profiler, isoler le composant en cause.
- Préférer un correctif ciblé (filtre, réglage) à une désactivation totale d’une extension de sécurité.
- Traiter la limite de mémoire comme un filet de sécurité, pas comme un correctif.
Un plugin de sécurité qui consomme trop de mémoire au mauvais moment reste un plugin de sécurité utile : la première question est toujours « quel module précisément », jamais « faut-il le garder ».
Pour aller plus loin
Ce type de diagnostic se généralise à n’importe quelle extension qui hooke des traitements lourds sur des actions d’administration fréquentes. La documentation officielle sur les hooks WordPress, disponible sur developer.wordpress.org, reste la référence pour comprendre à quel moment précis du cycle de vie une action donnée se déclenche, et donc pour évaluer si un traitement y a vraiment sa place.
