Comment augmenter la limite de mémoire PHP dans WordPress (WP_MEMORY_LIMIT)

L'un des messages d'erreur WordPress les plus courants ressemble à « Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/... ». Il apparaît généralement au pire moment possible : au milieu d'une mise à jour d'extension, lors de l'enregistrement d'une longue page dans l'éditeur, pendant un téléversement de média, ou juste après être passé à un thème plus exigeant. La solution consiste presque toujours à augmenter la limite de mémoire PHP. Le piège est qu'il n'existe pas qu'une seule limite de mémoire. WordPress en a au moins trois différentes, plus une quatrième au niveau de PHP, et elles interagissent de manière qui surprend. Ce guide explique laquelle s'applique dans quelle situation et comment l'augmenter sur les diverses configurations d'hébergeurs.

De quelle « limite de mémoire » parle-t-on au juste ?

Lorsqu'une page WordPress est demandée, quatre limites entrent potentiellement en jeu :

• PHP memory_limit dans php.ini. Le plafond strict imposé par PHP lui-même. Rien à l'intérieur de WordPress ne peut jamais aller au-delà. Les valeurs par défaut typiques sur les hébergeurs modernes sont 128M ou 256M.
• WP_MEMORY_LIMIT. La constante propre à WordPress, définie dans wp-config.php. La valeur par défaut est 40M. WordPress augmente la limite PHP à cette valeur au démarrage, mais uniquement si WP_MEMORY_LIMIT est supérieur à la limite PHP actuelle. Si votre memory_limit PHP est déjà à 256M, cette constante n'a aucun effet.
• WP_MAX_MEMORY_LIMIT. Une constante distincte qui ne s'applique qu'à l'intérieur de wp-admin (le tableau de bord, les écrans d'édition, la gestion des extensions et des thèmes, la médiathèque). La valeur par défaut est 256M. Définissez-la plus haut lorsque les pages d'administration manquent de mémoire, mais que le frontend fonctionne bien.
• Surcharges de l'hébergeur. De nombreux hébergeurs mutualisés et infogérés plafonnent strictement le memory_limit PHP au niveau du serveur, quoi que disent votre php.ini ou wp-config.php. Sur ces hébergeurs, augmenter la limite vous-même échoue silencieusement et vous devez faire appel au support.

Le modèle mental pratique : WP_MEMORY_LIMIT est pour le frontend, WP_MAX_MEMORY_LIMIT est pour l'administration, et les deux sont des planchers, pas des plafonds. Ils ne peuvent qu'augmenter la limite effective, jamais la descendre en dessous du paramètre PHP. Le paramètre PHP est le véritable plafond.

De combien de mémoire un site WordPress a-t-il réellement besoin ?

Une échelle approximative utile, basée sur ce qu'InspectWP observe à travers des milliers d'analyses :

• 64M. Une installation WordPress propre avec un petit thème et cinq extensions bien tenues. Réaliste uniquement sur des sites très simples aujourd'hui, et même ainsi, c'est juste.
• 128M. Le minimum de fait pour tout site réel en 2026. Thème par défaut, dix ou quinze extensions, pas de page builder. La plupart des hébergeurs ont cette valeur par défaut.
• 256M. La cible raisonnable pour la plupart des sites. Page builders (Elementor, Divi, Bricks, Beaver Builder), WooCommerce, frameworks de thèmes plus volumineux, extensions d'optimisation d'images. C'est aussi la valeur par défaut de WP_MAX_MEMORY_LIMIT pour l'administration, ce n'est pas une coïncidence.
• 512M. Boutiques WooCommerce avec quelques centaines de commandes et de nombreuses extensions. Sites exécutant de lourdes suites SEO en plus d'un page builder. Traitement d'images sur de grandes médiathèques.
• 768M à 1024M. Boutiques WooCommerce plus grandes, sites multilingues avec WPML ou Polylang, sites d'adhésion avec une logique de rôles complexe, sites exécutant des imports planifiés.
• Au-delà de 1024M. Si vous en avez réellement besoin sur un site normal, quelque chose ne va généralement pas. Une extension spécifique fuit en mémoire, un job d'import charge toute la base de données dans un seul processus PHP, ou un thème fait quelque chose qu'il ne devrait pas. Augmenter la limite contournera le symptôme pour l'instant, mais le véritable correctif est ailleurs.

La mémoire est bon marché, mais une mémoire illimitée masque les bugs. La bonne démarche est d'augmenter la limite juste assez pour que le site fonctionne confortablement, et non de la régler à 4G « au cas où ».

Option 1 : augmenter WP_MEMORY_LIMIT dans wp-config.php

C'est la modification la plus simple et la plus portable. Ouvrez wp-config.php à la racine de WordPress et ajoutez les lignes suivantes, n'importe où au-dessus du commentaire qui indique /* That's all, stop editing! Happy publishing. */ :

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

Enregistrez le fichier. WordPress applique les nouvelles limites à la requête suivante. Le frontend dispose désormais de 256M, l'administration jusqu'à 512M. Aucun redémarrage n'est nécessaire.

Mise en garde importante : cela ne fonctionne que si le memory_limit au niveau PHP est au moins aussi élevé que la valeur que vous définissez. Si PHP est plafonné à 128M par l'hébergeur, définir WP_MEMORY_LIMIT à 512M ne fait rien. WordPress essaie d'élever la limite et PHP refuse. Le message d'erreur reste le même. Continuez avec l'Option 2.

Option 2 : augmenter le memory_limit PHP au niveau de PHP

Si WP_MEMORY_LIMIT seul ne suffit pas, le paramètre PHP réel doit être relevé. L'endroit où vous le modifiez dépend de l'hébergeur :

Sur l'hébergement infogéré (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround, Pressable)

Ces hébergeurs exposent presque tous un paramètre dans leur tableau de bord. Cherchez « PHP settings », « PHP memory limit » ou similaire. La modification prend généralement effet en quelques secondes, sans redémarrage de votre côté. Certains hébergeurs (Raidboxes, WP Engine) plafonnent le maximum à 512M ou 768M pour des raisons de performance. Si vous en avez réellement besoin de plus, le support peut généralement l'augmenter sur demande, mais ils vous demanderont d'abord pourquoi, ce qui est la bonne réaction.

Sur l'hébergement mutualisé avec cPanel/Plesk (IONOS, All Inkl, Hostinger, DomainFactory, Strato)

cPanel et Plesk disposent tous deux d'un panneau de paramètres PHP où memory_limit peut être défini par domaine. Cherchez « MultiPHP INI Editor » (cPanel) ou « PHP Settings » (Plesk). Choisissez la valeur, enregistrez, c'est terminé. Certains hébergeurs cachent le paramètre derrière un sous-menu « PHP options ».

Si le panneau est manquant ou que le paramètre n'a aucun effet, déposez un fichier .user.ini à la racine de WordPress avec cette unique ligne :

memory_limit = 256M

Le mécanisme .user.ini est pris en charge par toute configuration PHP moderne fonctionnant en CGI, FastCGI ou PHP FPM, ce qui est essentiellement le cas de tous les hébergeurs aujourd'hui. PHP récupère le fichier automatiquement ; la seule particularité est un temps de cache par défaut de cinq minutes avant que les modifications ne prennent effet, après quoi la nouvelle limite s'applique à la requête suivante.

Sur un VPS ou un serveur dédié auto-géré

Modifiez directement php.ini. Trouvez le php.ini actif avec php --ini en ligne de commande ; le chemin varie selon la distribution et la version de PHP. Cherchez la ligne memory_limit, modifiez la valeur, enregistrez. Rechargez PHP FPM avec sudo systemctl reload php8.2-fpm (ajustez le numéro de version) ou redémarrez Apache si vous utilisez mod_php.

Apache uniquement : .htaccess (héritage)

Sur des configurations Apache plus anciennes avec mod_php (rares sur l'hébergement moderne), php_value memory_limit 256M dans .htaccess peut fonctionner. Si votre hébergeur exécute PHP via FastCGI ou PHP FPM, cette directive est tout simplement ignorée. Utilisez plutôt .user.ini.

Comment vérifier quelle limite est réellement active

Savoir laquelle des quatre limites s'applique prend trente secondes :

1. Dans l'administration WordPress, ouvrez Outils, Santé du site, Info (allemand : Werkzeuge, Website Zustand, Bericht).
2. Développez la section Serveur. Vous voyez le memory_limit PHP actif.
3. Développez la section Constantes WordPress. Vous voyez WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT, avec leurs valeurs actuelles.

Si les constantes WordPress affichent vos nouvelles valeurs mais que le memory_limit PHP est toujours plus bas, l'hébergeur le plafonne au niveau du serveur. Parlez au support ou utilisez le panneau de l'hébergeur de l'Option 2.

Pour une vérification précise depuis l'extérieur du tableau de bord, déposez ce fichier temporaire à wp-content/mu-plugins/check-memory.php :

<?php
add_action('init', function () {
    if (current_user_can('manage_options') && isset($_GET['check_memory'])) {
        wp_die('PHP memory_limit: ' . ini_get('memory_limit'));
    }
});

Ouvrez ensuite https://votredomaine.com/?check_memory=1 en étant connecté en tant qu'administrateur. La page affiche la limite que PHP applique réellement pour cette requête. Supprimez le fichier lorsque vous avez terminé.

Que faire si augmenter la limite ne corrige pas l'erreur ?

Si « Allowed memory size exhausted » persiste après avoir augmenté chaque limite à une valeur raisonnable, le problème n'est plus « WordPress a besoin de plus de mémoire ». Cherchez l'une de ces causes :

• Une extension spécifique est responsable. Désactivez les extensions une par une et rechargez. L'erreur identifie l'extension dans le chemin de fichier : /wp-content/plugins/NOMEXTENSION/.... Cette extension a soit une fuite de mémoire, soit elle fait réellement quelque chose de gourmand en mémoire qui devrait être divisé en jobs plus petits.
• Opérations en masse. Importer des milliers de produits via l'importateur CSV de WooCommerce, régénérer les vignettes pour toute une médiathèque, ou exécuter un audit SEO complet peuvent tous atteindre n'importe quelle limite de mémoire. La bonne réponse est généralement de passer à WP CLI pour ces tâches. La CLI a une limite de mémoire séparée, généralement beaucoup plus élevée, et traite les tâches par lots sans la surcharge complète du cycle de vie d'une requête WordPress.
• WP Cron bloqué sur une tâche lourde. Les jobs en arrière-plan exécutés via wp-cron.php partagent la même limite de mémoire qu'une requête normale. Si une tâche planifiée tente de traiter une énorme file d'attente d'un seul coup, elle échoue à plusieurs reprises sans aucun symptôme visible côté frontend. Désactiver le WP Cron interne et l'exécuter via le cron système aide généralement.
• Mauvaise configuration du cache d'objets. Une instance Redis ou Memcached sous-dimensionnée combinée au cache d'objets persistant de WordPress peut causer une étrange pression mémoire sous charge. À vérifier si vous en utilisez un et que le problème ne se manifeste que sous trafic.

Erreurs courantes à éviter

• Définir WP_MEMORY_LIMIT en dessous de la valeur par défaut PHP. Inutile. WordPress n'augmente la limite que ; il ne la diminue jamais. define('WP_MEMORY_LIMIT', '32M') sur un hébergeur avec PHP à 256M ne fait rien.
• Définir WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT à la même valeur. Cela fonctionne, mais vous abandonnez la possibilité de laisser à l'administration plus de mémoire qu'au frontend, ce qui est tout l'intérêt d'avoir deux constantes.
• Mettre la valeur sous forme de nombre. define('WP_MEMORY_LIMIT', 256) définit la limite à 256 octets, et non 256 mégaoctets. Citez toujours avec l'unité : '256M'.
• Modifier le mauvais wp-config.php. Si votre installation est dans un sous-répertoire, à la fois le répertoire d'installation et le parent peuvent avoir un wp-config.php. Vérifiez depuis le répertoire WordPress en remontant et modifiez celui que WordPress charge réellement.

Pour la grande majorité des sites, deux lignes dans wp-config.php plus un memory_limit PHP raisonnable depuis le panneau de l'hébergeur résolvent l'erreur de manière permanente. Si ce n'est pas le cas, le problème n'est pas la mémoire elle-même, et augmenter la limite ne fera que repousser la prochaine défaillance.