L’erreur Fatal error: Allowed memory size of X bytes exhausted signifie que PHP n’a plus de mémoire vive disponible pour exécuter WordPress. La solution la plus rapide : ajouter define('WP_MEMORY_LIMIT', '256M'); dans wp-config.php, juste avant la ligne /* That’s all, stop editing! */. Si l’erreur persiste malgré cette modification, il faut aussi ajuster la directive memory_limit dans php.ini ou .user.ini côté serveur. Dans la grande majorité des cas, l’erreur disparaît en moins de 5 minutes en combinant ces deux ajustements.

Comprendre l’erreur « allowed memory size exhausted » dans WordPress

PHP alloue par défaut entre 128 Mo et 256 Mo de mémoire vive à chaque processus. WordPress réserve une part de cette enveloppe pour son propre fonctionnement (noyau, thème actif), et chaque plugin actif consomme une portion supplémentaire. Quand la somme de ces consommations dépasse la limite autorisée, PHP interrompt l’exécution et affiche le message fatal.

Le message complet ressemble à ceci :

Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 4096 bytes) in
/home/user/public_html/wp-includes/functions.php on line 4673

134 217 728 bytes correspond à 128 Mo. La valeur varie selon la configuration serveur. Les situations les plus fréquentes qui déclenchent cette erreur sont : l’activation d’un nouveau plugin gourmand (constructeur de pages, WooCommerce, plugin de sauvegarde), une mise à jour de WordPress ou d’un plugin qui a augmenté les besoins mémoire, ou encore un pic de traitement (import CSV, génération de miniatures en masse, envoi de newsletter).

WordPress dispose de deux constantes distinctes :

  • WP_MEMORY_LIMIT : mémoire accordée aux requêtes front-end (valeur par défaut : 40 Mo pour certains hébergeurs, 256 Mo recommandés).
  • WP_MAX_MEMORY_LIMIT : mémoire accordée au tableau de bord et aux tâches d’administration (valeur par défaut : 256 Mo).

Ces constantes ne peuvent pas dépasser la valeur memory_limit définie dans php.ini côté serveur : elles sont plafonnées par la configuration du serveur.

Solution 1 : augmenter WP_MEMORY_LIMIT dans wp-config.php

C’est la méthode officielle recommandée par WordPress. Ouvrez le fichier wp-config.php à la racine de votre installation (via FTP ou le gestionnaire de fichiers cPanel) et ajoutez ces lignes avant la ligne /* That’s all, stop editing! */ :

// Augmenter la mémoire PHP pour WordPress
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Enregistrez, puis rechargez la page qui affichait l’erreur. Vérifiez la mémoire effective depuis le tableau de bord WordPress en allant dans Outils > Informations du site > PHP > Limite mémoire PHP. Si la valeur affichée n’a pas changé, cela signifie que la limite serveur (php.ini) est inférieure à ce que vous venez de définir : passez à la solution 2.

Pour vérifier rapidement la mémoire active via WP-CLI :

wp eval 'echo WP_MEMORY_LIMIT;'
# Devrait afficher : 256M

Solution 2 : modifier php.ini ou .user.ini (hébergement mutualisé)

La constante WP_MEMORY_LIMIT est plafonnée par la valeur memory_limit de PHP. Si votre hébergeur autorise un fichier php.ini ou .user.ini dans le dossier web, c’est la méthode la plus efficace pour lever ce plafond.

Cherchez un fichier php.ini ou .user.ini dans la racine de votre site. S’il existe, ajoutez ou modifiez la ligne suivante. S’il n’existe pas, créez-le :

; Augmenter la limite mémoire PHP
memory_limit = 256M
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

Chez o2switch et la plupart des hébergeurs mutualisés cPanel, le fichier .user.ini est prioritaire. Après modification, attendez 5 minutes (délai de rechargement PHP-FPM) avant de vérifier l’effet.

Sur un VPS ou serveur dédié sous Debian/Ubuntu avec PHP-FPM, modifiez directement le fichier pool concerné :

# Trouver le fichier php.ini actif
php --ini | grep "Loaded Configuration"

# Exemple pour PHP 8.2
sudo nano /etc/php/8.2/fpm/php.ini

# Modifier memory_limit
memory_limit = 256M

# Redémarrer PHP-FPM
sudo systemctl restart php8.2-fpm

Vérifiez ensuite avec php -i | grep memory_limit que la nouvelle valeur est bien prise en compte.

Solution 3 : utiliser .htaccess (serveurs Apache mutualisés)

Sur les hébergements Apache qui autorisent la directive php_value dans .htaccess (ce qui est le cas chez la majorité des hébergeurs mutualisés FR), vous pouvez augmenter la mémoire sans accès à php.ini :

# Augmenter la mémoire PHP via .htaccess
php_value memory_limit 256M
php_value max_execution_time 300

Ajoutez ces lignes au début de votre fichier .htaccess (à la racine de WordPress), avant le bloc # BEGIN WordPress. Cette méthode ne fonctionne pas sur les serveurs Nginx (pas de .htaccess) ni sur les configurations PHP-FPM strictes.

Si vous obtenez une erreur 500 après modification, retirez les lignes ajoutées : votre hébergeur n’autorise pas php_value dans .htaccess. Passez à la solution 2 (php.ini/.user.ini).

Solution 4 : identifier le plugin ou thème qui consomme la mémoire

Augmenter la limite mémoire règle le symptôme, pas nécessairement la cause. Si l’erreur revient régulièrement ou si vous atteignez des limites inhabituelles (512 Mo, 1 Go), un plugin ou un thème est probablement en cause.

Méthode de diagnostic rapide : désactivez tous les plugins depuis le gestionnaire de fichiers FTP (renommez le dossier wp-content/plugins en plugins_disabled), rechargez la page, puis réactivez les plugins un par un depuis le tableau de bord pour identifier le fautif.

Pour un diagnostic plus précis, installez le plugin Query Monitor ou utilisez le code suivant dans functions.php (à retirer après diagnostic) :

// Afficher la consommation mémoire en bas de page (admin uniquement)
add_action( 'shutdown', function() {
    if ( ! current_user_can( 'manage_options' ) ) return;
    $mem_usage = memory_get_peak_usage( true );
    echo '<p style="background:#fff;padding:10px;">';
    echo 'Pic mémoire : ' . round( $mem_usage / 1024 / 1024, 2 ) . ' Mo';
    echo ' / Limite : ' . ini_get( 'memory_limit' );
    echo '</p>';
} );

Les plugins les plus gourmands en mémoire sont généralement les constructeurs de pages (Elementor, WPBakery, Divi), les plugins de sauvegarde (UpdraftPlus sur de gros sites), les plugins d’optimisation d’images qui traitent des lots, et WooCommerce avec de nombreuses extensions activées.

Voir aussi notre article sur les erreurs critiques WordPress et comment les diagnostiquer pour une méthodologie de débogage complète.

Solution 5 : optimiser WordPress pour réduire la consommation mémoire

Plutôt que de toujours augmenter la limite, quelques optimisations permettent de réduire structurellement la consommation mémoire :

  • Désactiver les révisions d’articles : ajoutez define('WP_POST_REVISIONS', 3); dans wp-config.php pour ne conserver que 3 révisions au lieu de toutes.
  • Vider les transients expirés : les transients accumulés encombrent la base de données et ralentissent les requêtes qui consomment plus de mémoire.
  • Utiliser un cache d’objets : Redis ou Memcached réduit les requêtes répétées en mémoire vive.
  • Limiter le nombre de plugins actifs : chaque plugin actif est chargé en mémoire à chaque requête, même s’il n’est utilisé que sur une seule page.
// wp-config.php : optimisations mémoire
define( 'WP_POST_REVISIONS', 3 );
define( 'EMPTY_TRASH_DAYS', 7 );
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

// Désactiver le Heartbeat en dehors de l'admin (réduit la charge serveur)
add_action( 'init', function() {
    if ( ! is_admin() ) {
        wp_deregister_script( 'heartbeat' );
    }
} );

Si l’erreur survient uniquement lors de l’administration ou des mises à jour, consultez notre guide erreur 500 WordPress : diagnostic complet, qui couvre les cas où une mauvaise configuration PHP déclenche des erreurs en cascade dans wp-admin.

Cas particuliers : WooCommerce, multisite et cron WordPress

WooCommerce recommande officiellement un minimum de 256 Mo de mémoire PHP, et idéalement 512 Mo pour les boutiques avec de nombreux produits ou extensions. Si l’erreur survient à la caisse, lors de la génération de rapports ou de l’import de produits, augmentez WP_MAX_MEMORY_LIMIT à 512 Mo en priorité.

WordPress Multisite : chaque sous-site partage la même instance PHP mais peut charger des plugins et thèmes différents. Si l’erreur apparaît uniquement sur certains sous-sites, vérifiez les plugins réseau activés et les thèmes individuels qui peuvent se cumuler.

Erreur uniquement dans wp-admin : si le front-end fonctionne mais que l’erreur apparaît dans le tableau de bord, c’est WP_MAX_MEMORY_LIMIT qui est en cause (pas WP_MEMORY_LIMIT). Augmentez spécifiquement cette constante à 512 Mo.

WP-Cron et tâches planifiées : les crons WordPress s’exécutent avec la même limite mémoire que les requêtes normales. Une tâche de sauvegarde ou d’envoi d’emails en masse peut épuiser la mémoire en arrière-plan, générant des erreurs dans les logs serveur sans page d’erreur visible. Vérifiez le log PHP (wp-content/debug.log si WP_DEBUG_LOG est activé) pour détecter ces erreurs silencieuses.

# Activer les logs de debug dans wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // logs dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // ne pas afficher en front-end

# Surveiller le log en temps réel
tail -f /home/user/public_html/wp-content/debug.log | grep -i memory

Pour les migrations ou imports volumineux (nouvelle installation WordPress, migration de serveur), consultez notre article sur l’erreur de connexion à la base de données WordPress : les deux types d’erreurs apparaissent souvent ensemble après une migration ratée, la mémoire insuffisante pouvant provoquer une interruption de la requête MySQL.

Vérifier que la correction est effective

Après avoir appliqué l’une ou plusieurs des solutions ci-dessus, vérifiez la mémoire réelle allouée :

# Vérification via WP-CLI
wp eval 'echo "WP_MEMORY_LIMIT : " . WP_MEMORY_LIMIT . PHP_EOL;'
wp eval 'echo "WP_MAX_MEMORY_LIMIT : " . WP_MAX_MEMORY_LIMIT . PHP_EOL;'
wp eval 'echo "memory_limit PHP : " . ini_get("memory_limit") . PHP_EOL;'
wp eval 'echo "Pic mémoire actuel : " . round(memory_get_peak_usage(true)/1048576, 2) . " Mo" . PHP_EOL;'

Si WP_MEMORY_LIMIT affiche 256M mais que ini_get('memory_limit') affiche toujours 128M, la configuration php.ini n’a pas été prise en compte. Attendez le rechargement PHP-FPM (5 min) ou contactez votre hébergeur pour vérifier les limites autorisées sur votre offre.

Sur cPanel (o2switch, OVH WebHosting), la limite mémoire maximale autorisée figure dans Logiciels > MultiPHP INI Editor : les valeurs sont plafonnées par l’offre d’hébergement. Si votre offre autorise 256 Mo maximum et que WooCommerce en réclame 512, il faudra envisager une montée de gamme ou une migration vers un VPS.

Sources

FAQ : fatal error allowed memory size exhausted WordPress

Quelle valeur de WP_MEMORY_LIMIT faut-il définir dans wp-config.php ?

Pour un site WordPress standard, 256 Mo (256M) est la valeur recommandée par l’équipe WordPress. Pour WooCommerce, visez 512 Mo. La valeur définie dans wp-config.php ne peut pas dépasser la limite fixée dans php.ini par votre hébergeur : si votre offre autorise 256 Mo maximum, définir 512 Mo dans wp-config.php n’aura aucun effet.

L’erreur « allowed memory size exhausted » peut-elle survenir uniquement dans wp-admin ?

Oui, c’est fréquent. WordPress distingue WP_MEMORY_LIMIT (front-end) et WP_MAX_MEMORY_LIMIT (administration et tâches en arrière-plan). Si l’erreur n’apparaît qu’en tableau de bord ou lors de mises à jour, augmentez en priorité WP_MAX_MEMORY_LIMIT à 512M dans wp-config.php.

Comment identifier quel plugin provoque l’erreur mémoire sur WordPress ?

Renommez temporairement le dossier wp-content/plugins en plugins_disabled via FTP (WordPress désactive alors tous les plugins), puis réactivez-les un par un depuis le tableau de bord. Quand l’erreur réapparaît, le dernier plugin activé est le fautif. Vous pouvez aussi utiliser le plugin Query Monitor pour voir la consommation mémoire par plugin en temps réel.

Mon hébergeur mutualisé limite PHP à 128 Mo : que faire ?

Vérifiez d’abord si un fichier .user.ini ou php.ini personnel est autorisé sur votre offre (le cas chez la plupart des hébergeurs cPanel). Si la limite de votre offre est bloquée à 128 Mo et ne peut pas être relevée, envisagez une montée de gamme ou une migration vers un VPS où vous contrôlez entièrement php.ini. 128 Mo est insuffisant pour WordPress avec WooCommerce ou Elementor.

L’erreur « allowed memory size exhausted » peut-elle causer une page blanche dans WordPress ?

Oui. Quand PHP épuise la mémoire avant de terminer l’exécution, la page s’affiche vide (White Screen of Death) sans message d’erreur visible, surtout si WP_DEBUG est désactivé. Activez le mode debug avec WP_DEBUG=true et WP_DEBUG_LOG=true pour voir les erreurs dans wp-content/debug.log et confirmer que c’est bien une erreur mémoire qui cause la page blanche.

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.