Mémoire PHP épuisée sur WordPress : augmenter la limite

Le message qui bloque tout : « Allowed memory size exhausted »

Ce matin type : un site WooCommerce affiche une page presque blanche, avec une seule ligne en haut, du style Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes). Le back-office ne charge plus, l’éditeur de pages tourne dans le vide, et parfois même la page d’accueil publique renvoie une erreur.

Ce message veut dire une chose précise : PHP, le langage qui fait tourner WordPress, a une limite de mémoire vive allouée pour exécuter le site. Quand un script (un plugin, un thème, un import) demande plus de mémoire que cette limite autorisée, PHP arrête tout net pour ne pas faire planter le serveur entier. C’est une sécurité, pas un bug aléatoire.

La bonne nouvelle : c’est l’une des pannes WordPress les plus faciles à corriger une fois qu’on sait où toucher. Il n’y a presque jamais besoin de tout réinstaller. Il faut juste comprendre trois choses : où se règle cette limite, pourquoi elle est atteinte, et jusqu’où on peut la monter avant que ce soit l’hébergeur lui-même qui bloque.

Cette erreur est cousine d’autres messages fatals de WordPress. Si le site affiche plutôt un écran blanc sans message clair ou une erreur 500, le diagnostic mémoire reste une des premières pistes à vérifier.

Pourquoi ça arrive : ce qui pèse sur la mémoire PHP

La mémoire ne s’épuise jamais « toute seule ». Il y a toujours une cause identifiable, souvent cumulative :

• Trop de plugins actifs en même temps, chacun chargeant son propre code à chaque page vue, même sur les pages où il n’est pas utile.
• Un thème ou un constructeur visuel lourd (Elementor, WPBakery, Divi) qui recalcule des dizaines de composants à chaque chargement, surtout en mode édition.
• Un import ou export volumineux : migration de contenus, import CSV de produits WooCommerce, génération de PDF de facture, export de commandes.
• Des boucles de requêtes mal optimisées dans un plugin ou un thème mal codé, qui chargent toute la base de données en mémoire au lieu de la paginer.
• Des images non optimisées traitées en PHP au moment de l’affichage (redimensionnement à la volée, génération de miniatures).
• Un cache absent ou mal configuré, qui force WordPress à tout recalculer à chaque visite au lieu de servir une version déjà prête.
• Un hébergement mutualisé avec une limite basse par défaut (souvent 64 Mo ou 128 Mo), pensée pour des sites simples, pas pour un WooCommerce avec 30 plugins.
• Des mises à jour cumulées non suivies : un plugin devenu plus gourmand version après version, sans que personne ne surveille l’évolution des besoins.

Le point commun à toutes ces causes : la mémoire manquante n’est presque jamais « le vrai problème », elle révèle un problème en amont. Augmenter la limite peut suffire à débloquer le site dans l’immédiat, mais ne traite pas toujours la cause.

1. Lire précisément le message d’erreur

Avant de toucher à quoi que ce soit, note le chemin de fichier indiqué dans le message d’erreur. WordPress affiche souvent une ligne du type :

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /wp-content/plugins/nom-du-plugin/fichier.php on line 245

Ce chemin /wp-content/plugins/nom-du-plugin/ est une information précieuse : il pointe souvent vers le plugin responsable du pic de consommation. Si le message n’apparaît pas à l’écran (WordPress cache parfois les erreurs en production), regarde le fichier wp-content/debug.log si le mode debug est activé, ou les logs d’erreurs PHP accessibles depuis le panel de ton hébergeur.

2. Augmenter la limite dans wp-config.php

C’est le réglage le plus simple et le plus courant. Ouvre le fichier wp-config.php, à la racine de l’installation WordPress, via FTP ou le gestionnaire de fichiers de ton hébergeur. Ajoute ces deux lignes juste avant /* That's all, stop editing! */ :

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

WP_MEMORY_LIMIT définit la mémoire allouée pour l’affichage normal du site (front et back-office classique). WP_MAX_MEMORY_LIMIT définit la mémoire allouée pour les opérations lourdes en admin, comme les imports ou l’édition avec un constructeur de pages. 256 Mo est une valeur de départ raisonnable pour un site WordPress standard avec quelques plugins ; 512 Mo si le site tourne sous WooCommerce avec un catalogue conséquent.

Attention : ces constantes ne peuvent jamais dépasser la limite fixée par le serveur lui-même. Si l’hébergeur bride PHP à 128 Mo au niveau système, écrire 512M dans wp-config.php ne changera rien.

3. Relever la limite côté serveur : php.ini ou panel hébergeur

La vraie limite, celle qui prime sur tout le reste, se trouve dans la configuration PHP du serveur. Elle se règle différemment selon le type d’hébergement :

• Sur un VPS ou serveur dédié, on modifie directement le fichier php.ini, généralement dans /etc/php/8.x/fpm/php.ini, en changeant la ligne memory_limit = 256M, puis on redémarre le service PHP-FPM.
• Sur un hébergement mutualisé, l’accès direct au php.ini est rarement possible. Il faut passer par le panel d’hébergement (cPanel, Plesk, interface propriétaire) qui propose souvent une section « Sélecteur de version PHP » ou « Réglages PHP » avec un curseur pour memory_limit.
• Certains hébergeurs acceptent un fichier .user.ini déposé à la racine du site, qui surcharge localement la configuration PHP sans accès admin complet.

Si aucune de ces options n’est disponible depuis le panel, c’est le signe que la limite de l’hébergement est un vrai plafond, pas juste un réglage par défaut. On y revient au point 7.

4. Passer par .htaccess si le serveur tourne sous Apache

Sur les hébergements Apache (la majorité des mutualisés français), une autre option consiste à ajouter cette ligne dans le fichier .htaccess à la racine du site :

php_value memory_limit 256M

Cette méthode fonctionne uniquement si le serveur utilise le module mod_php et si l’hébergeur autorise la surcharge de directives PHP via .htaccess. Si la ligne provoque une erreur 500 dès l’enregistrement, c’est que cette directive n’est pas autorisée à cet endroit sur ce serveur : il faut revenir au panel d’hébergement ou au wp-config.php.

5. Identifier le plugin réellement gourmand

Augmenter la limite débloque le site, mais si un plugin consomme anormalement plus de mémoire à chaque mise à jour, le problème reviendra. L’outil Query Monitor, installable gratuitement, affiche la consommation mémoire réelle par requête et aide à repérer le composant fautif. La méthode complète est détaillée dans trouver le plugin qui ralentit WordPress avec Query Monitor.

Si plusieurs plugins se chevauchent sur les mêmes fonctions (deux caches, deux plugins SEO, deux constructeurs de page), le nettoyage passe aussi par une méthode sûre pour identifier un conflit de plugins.

6. Faire le tri dans les plugins actifs

Un site accumule souvent des plugins installés « pour tester » et jamais retirés. Chaque plugin actif charge du code à chaque requête, même sans usage visible. Si le nombre de plugins dépasse la trentaine, la question mérite d’être posée directement : combien de plugins WordPress, est-ce trop ? Désactiver ce qui n’est plus utilisé libère de la mémoire sans rien coder.

7. Quand c’est l’hébergeur lui-même qui plafonne

Certains mutualisés bloquent la mémoire PHP à 128 ou 256 Mo, sans possibilité d’aller plus haut, quel que soit le plan souscrit. C’est un choix technique de l’hébergeur pour préserver la stabilité de l’ensemble des sites mutualisés sur le même serveur. Si le site nécessite structurellement plus de mémoire (catalogue produit important, constructeur de page lourd, forte fréquentation), la solution durable n’est pas de bricoler des contournements, mais de changer d’environnement. Le passage vers un VPS donne un contrôle total sur php.ini et supprime ce plafond. La démarche est expliquée dans passer d’un mutualisé à un VPS : quand et comment.

Tableau récapitulatif des directives

FAQ

Quand passer la main à un pro

Si après avoir ajusté wp-config.php, vérifié le panel d’hébergement et désactivé les plugins suspects le message persiste, ou si l’erreur revient de façon aléatoire sans cause évidente, il est temps de faire intervenir un professionnel. Un diagnostic serveur complet (logs PHP-FPM, configuration Apache/Nginx, requêtes SQL lentes) permet de trancher entre un simple réglage insuffisant et un besoin réel de changement d’infrastructure — avant que le site ne tombe en pleine période de trafic.