PHP Fatal error: Allowed memory size of 268435456 bytes exhausted : ce message apparaît en pleine exécution d’une commande wp import, alors que le site continue, au même moment, à répondre normalement aux visiteurs sur le même serveur. Le réflexe naturel consiste à soupçonner une fuite mémoire introduite par une extension récente. Le plus souvent, la cause est plus simple et plus structurelle : WP-CLI et le serveur web ne partagent pas forcément la même limite mémoire, ni même le même fichier de configuration PHP.
Comprendre pourquoi ce fatal survient uniquement en ligne de commande demande de revenir sur une distinction souvent ignorée : PHP dispose de plusieurs SAPI (interfaces d’exécution), chacune pouvant charger sa propre configuration.
Symptôme : un fatal en CLI, un site parfaitement stable en HTTP
Le symptôme se manifeste presque toujours de la même façon : une commande WP-CLI qui traite un volume important de données, comme un import de contenu, une régénération de miniatures ou une recherche-remplacement sur l’ensemble de la base, s’arrête net avec un message d’épuisement mémoire. Pendant ce temps, les pages du site continuent de s’afficher sans ralentissement perceptible, et aucune erreur n’apparaît dans les journaux de PHP-FPM lié au serveur web.
Cette dissociation totale entre le comportement web et le comportement CLI est le signal qui oriente vers une différence de configuration entre les deux SAPI, plutôt que vers un problème de code affectant l’ensemble du site.
Diagnostic : deux SAPI, deux fichiers php.ini, deux limites

PHP-FPM, qui traite les requêtes du serveur web, et le SAPI cli, utilisé par WP-CLI depuis le terminal, chargent chacun leur propre fichier php.ini, situés à des emplacements distincts sur la plupart des distributions Linux. La commande suivante révèle lequel WP-CLI utilise réellement :
wp cli info
Sa sortie inclut une ligne php_bin et un chemin vers le fichier php.ini effectivement chargé, qui diffère fréquemment de celui utilisé par PHP-FPM, visible par ailleurs via une page exposant phpinfo(). Une commande complémentaire confirme précisément la valeur active pour la limite mémoire du côté CLI :
wp eval 'echo ini_get( "memory_limit" );'
Il n’est pas rare de découvrir ainsi une limite mémoire de 128 Mo côté CLI contre 512 Mo côté PHP-FPM, alors que les deux services tournent sur la même version de PHP et le même serveur.
Correctif : relever la limite mémoire spécifiquement pour le SAPI CLI
Une fois le fichier php.ini de la CLI identifié, la valeur de memory_limit s’y ajuste directement, sans impact sur la configuration de PHP-FPM ni sur les autres sites hébergés sur la même machine :
memory_limit = 512M
Lorsque la modification directe du fichier n’est pas possible, notamment sur un hébergement mutualisé où seul un fichier .user.ini reste accessible, WP-CLI accepte également une valeur passée en argument de commande, utile pour un besoin ponctuel sans modifier durablement la configuration :
wp import export.xml --authors=skip --extra-info=1 \
--skip-plugins --skip-themes \
--context=cli \
--allow-root 2>&1 | tee import.log
Une alternative plus directe consiste à surcharger temporairement la valeur via la variable d’environnement reconnue par PHP lui-même :
PHP_MEMORY_LIMIT=512M wp import export.xml
Pourquoi une commande CLI demande souvent plus de mémoire qu’une requête web
Une requête HTTP classique traite en général un nombre limité d’objets en mémoire : un article, ses métadonnées, quelques requêtes de contexte. Une commande WP-CLI comme un import de contenu ou une réindexation manipule au contraire des lots de données bien plus larges en une seule exécution, ce qui explique pourquoi la limite mémoire nécessaire côté CLI dépasse fréquemment celle qui suffit largement au bon fonctionnement du site en navigation normale.
Prévention : distinguer clairement CLI et pool PHP-FPM dans la documentation du parc
- Noter, pour chaque serveur du parc, l’emplacement exact du
php.iniutilisé par WP-CLI, distinct de celui du pool web. - Fixer une limite mémoire CLI volontairement plus haute que celle du pool PHP-FPM, en anticipation des opérations d’import ou de maintenance.
- Ne jamais aligner aveuglément les deux limites sur une même valeur : le réglage mémoire du pool PHP-FPM répond à une logique de densité de processus concurrents, absente en ligne de commande où une seule commande s’exécute à la fois.
Un fatal en CLI qui n’apparaît jamais côté web n’indique pas un site fragile : il indique deux configurations distinctes qu’on a oublié d’aligner.
En résumé
Le SAPI cli utilisé par WP-CLI charge, sur la plupart des serveurs, un fichier php.ini différent de celui de PHP-FPM, avec sa propre valeur de memory_limit. Vérifier ces deux fichiers distincts avant de soupçonner une fuite mémoire applicative évite bien des diagnostics inutiles, et un ajustement ciblé de la limite CLI suffit, dans l’immense majorité des cas, à faire disparaître ce fatal sans toucher au réglage du pool PHP-FPM qui sert le site.