Corriger l’erreur « Allowed memory size exhausted » sur WordPress

Ton site WordPress affiche brusquement une page blanche, une erreur critique, ou un message qui ressemble à ça :

Fatal error: Allowed memory size of 268435456 bytes exhausted 
(tried to allocate 20480 bytes) in /home/ton-site/wp-includes/...

Le chiffre change d’un site à l’autre (134217728, 268435456, 536870912 selon ta limite actuelle), mais le message est toujours le même : PHP n’a plus assez de mémoire pour exécuter ce que ton site lui demande. Sur les versions récentes de WordPress, tu verras parfois seulement « Une erreur critique est survenue sur votre site », c’est la même cause cachée derrière un message plus poli.

Ça arrive presque toujours au pire moment : pendant l’installation d’un plugin, un import WooCommerce, le téléversement d’une image lourde, ou juste après une mise à jour. Le serveur atteint son plafond et s’arrête net.

Je gère de la maintenance WordPress depuis plus de 10 ans et cette erreur revient chaque semaine sur au moins un site. Dans 90 % des cas, elle se règle en moins de 10 minutes une fois qu’on sait où regarder. Dans les 10 % restants, c’est qu’un plugin tourne en boucle et le problème est ailleurs. Ce guide couvre les deux.

Avant de modifier quoi que ce soit, regarde ce que ton serveur alloue déjà. Dans ton tableau de bord WordPress, va dans Outils > Santé du site > Info, puis déroule la section Serveur. Cherche la ligne Limite mémoire PHP.

Si tu vois 64M ou 128M, tu as trouvé ton problème. Si tu vois déjà 512M ou plus et que l’erreur persiste, la mémoire n’est pas en cause. Un plugin tourne probablement en boucle et consomme tout ce que tu lui donnes, peu importe la valeur. Dans ce cas, saute directement à la section « Quand augmenter la mémoire ne suffit pas ».

Pour te donner un repère, voici les valeurs adaptées selon ton installation. Ces valeurs supposent que tu tournes sur PHP 8.1 minimum. Si tu es encore sur PHP 7.4, compte environ 20 à 30 % de mémoire consommée en plus pour le même site. C’est une bonne raison de mettre PHP à jour si ce n’est pas encore fait.

La méthode à utiliser dépend directement de ton hébergeur. Toutes les méthodes ne fonctionnent pas partout, et certaines sont simplement ignorées selon la configuration serveur. Voici ce qui marche vraiment, hébergeur par hébergeur.

C’est la méthode la plus fiable sur o2switch, et c’est celle que j’utilise systématiquement sur les sites clients que je maintiens chez cet hébergeur. Depuis ton cPanel, tape Sélectionner une version de PHP dans la barre de recherche en haut ou retrouve le dans la rubrique Logiciel. Ce réglage s’appliquera à tous les domaines de l’hébergement. Dans l’onglet Options, modifie la valeur de memory_limit selon le tableau ci-dessus.

Le changement est immédiat, pas besoin de vider le cache ni de redémarrer quoi que ce soit. Pour vérifier que c’est bien pris en compte, retourne dans Outils > Santé du site > Info > Serveur dans ton WordPress. La ligne Limite mémoire PHP doit afficher la nouvelle valeur.

Sur OVH, la mémoire PHP se configure via le fichier .ovhconfig qui se trouve à la racine de ton hébergement, au même niveau que ton wp-config.php. Connecte-toi en SFTP ou via le gestionnaire de fichiers de ton espace client OVH et ouvre ce fichier.

Il ressemble à ça :

,

container.image=stable64
http.firewall=security
ovhconfig.version=1
php.memory_limit=512M
php.upload_max_filesize=256M
php.post_max_size=256M

>

Modifie la ligne php.memory_limit avec la valeur qui correspond à ton installation (tableau ci-dessus). Si la ligne n’existe pas encore, ajoute-la. Enregistre le fichier et la modification est prise en compte en quelques minutes.

Si ton hébergeur ne propose pas d’interface dédiée, la méthode universelle sur mutualisé c’est le fichier .user.ini. Crée ce fichier à la racine de ton site (là où se trouve wp-config.php) et ajoute simplement :

memory_limit = 256M

Ce fichier est lu directement par PHP en mode CGI/FastCGI, qui est la configuration standard de tous les hébergeurs mutualisés. La modification prend effet en quelques minutes.

Pour les autres hébergeurs courants :

• Hostinger : hPanel > Avancé > Configuration PHP, modifie memory_limit directement.
• Infomaniak : panneau d’administration > Hébergement Web > PHP > Configuration.
• SiteGround : Site Tools > Devs > PHP Manager, onglet PHP Variables.

Tu trouveras souvent cette solution en premier dans les tutoriels. Elle consiste à ajouter dans wp-config.php :

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

Ce que cette ligne fait vraiment : elle indique à WordPress combien de mémoire il peut demander à PHP. Mais PHP ne peut pas dépasser la limite que ton serveur lui impose. Si ton hébergeur limite à 128M et que tu mets 256M dans wp-config.php, WordPress verra 256M dans ses paramètres internes mais PHP continuera à s’arrêter à 128M.

Elle est donc utile en complément d’une modification côté serveur, pour s’assurer que WordPress utilise bien toute la mémoire disponible. Mais elle ne remplace pas les méthodes ci-dessus.

Pour augmenter aussi la mémoire dans l’administration WordPress (utile notamment lors des imports WooCommerce), ajoute en dessous :

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

J’interviens régulièrement sur des sites où le client a déjà monté la mémoire à 1024M, voire 2048M, sans résultat. L’erreur revient systématiquement. Dans ces cas-là, ce n’est pas un problème de limite : c’est un plugin ou un script qui tourne en boucle et consomme tout ce qu’on lui donne, quelle que soit la valeur configurée.

Pour identifier le coupable, la méthode est simple :

1. Désactive tous tes plugins en les renommant via SFTP (renomme le dossier).wp-content/plugins en plugins-off
2. Recharge ton site. Si l’erreur disparaît, un plugin est en cause.
3. Remets le nom du dossier d’origine, puis désactive les plugins un par un depuis l’administration jusqu’à retrouver le fautif.
4. Si l’erreur persiste même sans plugins, teste avec un thème par défaut WordPress (Twenty Twenty-Four).

Pour aller plus vite dans le diagnostic, active les logs WordPress et consulte le fichier wp-content/debug.log. Tu verras exactement quel fichier déclenche l’erreur et à quelle ligne. Mon guide sur comment trouver les logs WordPress t’explique comment faire.

Si tu dois monter à 2 Go de mémoire PHP juste pour qu’un site WordPress fonctionne, et que malgré ça l’erreur revient régulièrement, le problème n’est plus la mémoire. Trois pistes à examiner dans cet ordre :

1. Audite tes plugins. Un plugin mal codé peut à lui seul saturer un serveur correctement dimensionné. C’est le cas le plus fréquent que je rencontre en maintenance.
2. Vérifie ta version PHP. Un site sur PHP 7.4 consomme sensiblement plus qu’un site sur PHP 8.2 ou 8.3. La mise à jour est souvent le premier levier avant de changer d’hébergeur.
3. Ensuite seulement, regarde ton hébergeur. Si tu es sur un mutualisé low-cost et que ton site est une boutique WooCommerce active, tu as peut-être atteint les limites structurelles de l’offre. Dans ce cas, passer sur une offre avec plus de ressources allouées (Cloud d’o2switch, par exemple) résoudra le problème à la racine.

En résumé : avant de payer plus cher, vérifie ce qui consomme vraiment la mémoire sur ton site actuel.

Et si tu veux éviter de vivre ce genre de situation à chaque mise à jour, regarde ma maintenance WordPress. C’est exactement pour ça qu’elle existe.

Une fois l'erreur corrigée, quelques réflexes pour ne pas y revenir :

• Limite le nombre de plugins actifs. Chaque plugin ajoute du poids. Désactive ceux que tu n'utilises pas vraiment.
• Optimise tes images avant de les téléverser. Les images non compressées consomment beaucoup de mémoire lors du traitement par PHP. Un outil comme Squoosh ou un plugin comme Imagify fait l'affaire.
• Mets PHP à jour. Les versions inférieures à 8.0 consomment sensiblement plus de mémoire que les versions récentes. Consulte mon guide pour mettre à jour PHP sur WordPress.
• Nettoie ta base de données régulièrement. Une base alourdie par des révisions, des transients expirés ou des logs de plugins peut provoquer des pics mémoire au chargement.
• Surveille les mises à jour. Une mise à jour de plugin ou de thème ratée est souvent le déclencheur d'une première apparition de cette erreur.