# WP_MEMORY_LIMIT ou memory_limit PHP : lequel arbitre en cas de fatal error

> Deux réglages qui portent presque le même nom, mais qui n'agissent ni au même niveau ni avec la même priorité.

- Auteur : Clément Hadrot
- Publié le : 2026-08-02
- Mis à jour le : 2026-08-02
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/wp-memory-limit-memory-limit-php-fatal-error/

## L’essentiel

- memory_limit est un plafond dur imposé par PHP lui-même
- WP_MEMORY_LIMIT ne peut jamais dépasser ce plafond
- Modifier la constante sans toucher php.ini ne change souvent rien

`Fatal error: Allowed memory size of 268435456 bytes exhausted`. Ce message persiste malgré une constante `WP_MEMORY_LIMIT` relevée à 512M dans `wp-config.php`, ce qui laisse penser à une configuration ignorée ou à un cache non vidé. En réalité, le chiffre affiché dans le message d'erreur, 268 435 456 octets, correspond très précisément à 256 Mo : c'est la limite réellement appliquée par PHP lui-même, indépendamment de ce que WordPress demande.

## Deux réglages qui ne vivent pas au même niveau

`memory_limit` est un réglage de PHP, défini dans `php.ini` ou dans la configuration du pool PHP-FPM, qui impose un plafond dur à tout script PHP exécuté sur le serveur, quel que soit le logiciel qui tourne dessus. `WP_MEMORY_LIMIT`, à l'inverse, est une constante propre à WordPress, qui ne fait qu'appeler la fonction native `ini_set( 'memory_limit', ... )` en coulisses.

```
// wp-includes/default-constants.php (comportement simplifié)
if ( function_exists( 'ini_set' ) ) {
    ini_set( 'memory_limit', WP_MEMORY_LIMIT );
}
```

## La règle qui explique tout : ini_set ne peut jamais dépasser un plafond serveur

La fonction `ini_set()` permet d'augmenter `memory_limit` à l'exécution, mais uniquement si la configuration du serveur l'autorise. Certains hébergeurs mutualisés verrouillent ce réglage au niveau du pool PHP-FPM avec la directive `php_admin_value`, qui rend tout appel ultérieur à `ini_set()` totalement sans effet :

```
; dans le pool PHP-FPM
php_admin_value[memory_limit] = 256M
```

Quand cette directive est présente, relever `WP_MEMORY_LIMIT` à n'importe quelle valeur dans `wp-config.php` ne change strictement rien : le plafond serveur reste absolu et prioritaire.

> L'essentiel à retenir : memory_limit est un plafond dur imposé par PHP lui-même ; WP_MEMORY_LIMIT ne peut jamais dépasser ce plafond ; Modifier la constante sans toucher php.ini ne change souvent rien

## Diagnostiquer la vraie limite appliquée

Le moyen le plus fiable de savoir quelle limite est réellement active consiste à l'interroger directement depuis WordPress, plutôt que de se fier à ce qui est écrit dans les fichiers de configuration :

```
wp eval 'echo ini_get( "memory_limit" );'
```

Si la valeur retournée ne correspond pas à celle attendue dans `wp-config.php`, la cause se trouve presque toujours dans la configuration du pool PHP-FPM, accessible uniquement avec un accès serveur, ou dans une limite imposée globalement par l'hébergeur sur les offres mutualisées.

### WP_MAX_MEMORY_LIMIT : la deuxième constante souvent oubliée

WordPress distingue en réalité deux constantes : `WP_MEMORY_LIMIT`, appliquée au chargement normal du site, et `WP_MAX_MEMORY_LIMIT`, appliquée uniquement dans l'administration et lors des tâches lourdes comme les mises à jour d'extensions. Oublier la seconde explique pourquoi une page classique fonctionne alors qu'une mise à jour groupée échoue toujours :

```
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
```

## Ce qu'il faut vérifier dans l'ordre

- La valeur réellement active via `ini_get( 'memory_limit' )`, pas la constante déclarée ;
- La présence éventuelle d'un `php_admin_value` verrouillé dans le pool PHP-FPM du serveur ;
- La distinction entre `WP_MEMORY_LIMIT` et `WP_MAX_MEMORY_LIMIT` selon le contexte de l'erreur ;
- Le rôle de l'extension elle-même : une fuite mémoire réelle dans le code ne se résout jamais en augmentant simplement les limites.

> Un réflexe qui fait gagner du temps sur ce diagnostic précis : toujours lire le chiffre exact du message d'erreur en octets, le convertir en mégaoctets, et le comparer à la valeur attendue avant de modifier quoi que ce soit.

## Quand augmenter la limite ne fait que masquer le problème

Relever indéfiniment `memory_limit` face à une erreur récurrente traite le symptôme, jamais la cause. Une fuite mémoire dans une boucle mal écrite, par exemple une requête qui charge tous les articles d'un site volumineux en une seule fois via `get_posts()` sans limite explicite, continuera de consommer toujours plus de mémoire à mesure que le contenu du site grandit, quelle que soit la limite fixée :

```
// à éviter sur un site volumineux
$articles = get_posts( array( 'numberposts' => -1 ) );

// préférable : traiter par lots
$articles = get_posts( array( 'numberposts' => 200, 'offset' => $decalage ) );
```

### Le cas particulier des tâches WP-CLI en ligne de commande

Une commande WP-CLI exécutée en SSH ne suit pas toujours la même configuration `memory_limit` que les requêtes web servies par PHP-FPM, car elle peut utiliser un binaire PHP en ligne de commande configuré séparément. Il est donc possible qu'un import fonctionne sans erreur en SSH alors que la même opération échoue depuis l'interface d'administration, un écart qui surprend souvent la première fois qu'il est observé.

## En résumé

`memory_limit` défini côté serveur prime toujours sur `WP_MEMORY_LIMIT` défini côté WordPress, jamais l'inverse. Une erreur fatale de mémoire qui persiste malgré une constante relevée signale presque systématiquement un plafond imposé plus bas dans la pile, au niveau du pool PHP-FPM, que seul un accès serveur permet de corriger.