Comment corriger l’erreur max_execution_time dans WordPress

L’erreur max_execution_time dans WordPress se produit lorsqu’un script PHP dépasse la durée d’exécution maximale configurée au niveau du serveur. PHP met fin au script et renvoie une erreur fatale, que WordPress affiche sous forme d’écran blanc, d’avis d’expiration ou d’un message explicite « Maximum execution time exceeded ».

Par défaut, la plupart des environnements d’hébergement mutualisé appliquent une limite de 30 secondes. Des opérations telles que l’importation d’un CSV de produits WooCommerce, l’exécution d’une sauvegarde complète du site ou l’installation d’un ensemble de plugins volumineux peuvent facilement dépasser ce plafond. Augmenter la limite — via php.ini, .htaccess, wp-config.php, ou la couche de plugins WordPress — résout l’erreur sans compromettre la stabilité du serveur lorsque cela est fait correctement.

Comprendre pourquoi la limite existe et quand elle devient un problème

La directive max_execution_time de PHP est un mécanisme de protection des ressources, et non une restriction arbitraire. Elle empêche un script incontrôlé de monopoliser le temps CPU sur un pool de processus partagés, ce qui est particulièrement critique sur une infrastructure multi-locataires.

La limite devient un véritable obstacle dans ces scénarios :

• Importations ou exportations de bases de données volumineuses via phpMyAdmin ou WP-CLI traitant des milliers de lignes
• Installations de plugins ou de thèmes décompressant des archives dépassant 50 MB
• Opérations en masse WooCommerce — mises à jour de prix, synchronisations d’inventaire, exports de commandes
• Migrations complètes de site à l’aide d’outils comme Duplicator ou All-in-One WP Migration
• Tâches cron planifiées qui agrègent des données provenant d’APIs externes
• Plugins d’optimisation d’images traitant des centaines d’uploads non optimisés en un seul lot

Une nuance critique que la plupart des guides omettent : max_execution_time mesure le temps CPU consommé par le processus PHP, et non le temps réel. Sur un serveur fortement chargé, un script peut s’exécuter pendant 90 secondes réelles tout en ne consommant que 28 secondes de temps CPU et ne jamais déclencher la limite. À l’inverse, une boucle gourmande en CPU atteint la limite plus rapidement que prévu. Cette distinction est importante lors du diagnostic de délais d’expiration intermittents.

Comment vérifier votre valeur actuelle de max_execution_time

Avant de modifier quoi que ce soit, confirmez la limite active. Créez un fichier temporaire dans la racine de votre WordPress — ne le laissez jamais accessible publiquement après les tests :

<?php
phpinfo();

Téléchargez-le sous le nom phpinfo-test.php, visitez https://yourdomain.com/phpinfo-test.php, et recherchez max_execution_time dans la sortie. Supprimez le fichier immédiatement après vérification.

Vous pouvez également utiliser WP-CLI depuis SSH :

wp eval 'echo ini_get("max_execution_time");'

Cela renvoie la valeur actuellement active pour les requêtes WordPress, qui peut différer du php.ini global du serveur si un remplacement par répertoire est déjà en place.

Méthode 1 : Modifier le fichier php.ini (la plus fiable)

Modifier php.ini est la méthode la plus autoritaire car elle définit la directive au niveau de l’interpréteur PHP, sans rien remplacer et sans être remplacée par quoi que ce soit en dessous dans la hiérarchie de configuration — à moins qu’un appel ultérieur à ini_set() ne la supplante au moment de l’exécution.

Étape 1 : Localiser le bon fichier php.ini

C’est là que la plupart des administrateurs font une erreur. PHP peut charger plusieurs fichiers .ini selon le SAPI (Server API) utilisé :

• CLI SAPI (/etc/php/8.x/cli/php.ini) — utilisé par WP-CLI et les tâches cron
• FPM SAPI (/etc/php/8.x/fpm/php.ini) — utilisé par les stacks Nginx + PHP-FPM
• Apache mod_php (/etc/php/8.x/apache2/php.ini) — utilisé par Apache avec le module PHP

Modifier le php.ini CLI corrigera les délais d’expiration WP-CLI mais n’affectera pas les requêtes déclenchées par le navigateur. Identifiez toujours le bon SAPI en premier :

php -i | grep "Loaded Configuration File"

Pour les requêtes web, vérifiez la sortie de phpinfo() sous Loaded Configuration File.

Étape 2 : Modifier ou créer php.ini dans la racine web

Sur un hébergement mutualisé où vous n’avez pas accès root, vous pouvez placer un php.ini au niveau utilisateur dans le répertoire racine de votre site (public_html). Accédez-y via le gestionnaire de fichiers cPanel, FTP ou SSH :

nano ~/public_html/php.ini

Ajoutez ou mettez à jour la directive :

max_execution_time = 300

300 secondes (5 minutes) est suffisant pour la plupart des opérations. Pour les migrations très volumineuses, envisagez temporairement 600 secondes, puis revenez à la valeur précédente une fois la tâche terminée.

Étape 3 : Vérifier que la modification a pris effet

Après l’enregistrement, relancez la vérification phpinfo() ou la commande WP-CLI précédente. Si la valeur n’a pas changé, votre hébergeur applique peut-être une limite stricte via max_execution_time dans un php.ini au niveau serveur qui supplante votre fichier utilisateur. Dans ce cas, passez à la Méthode 4.

Étape 4 : Redémarrer PHP-FPM (VPS et serveurs dédiés)

Sur un VPS ou un serveur dédié où vous contrôlez l’environnement, un redémarrage de PHP-FPM est nécessaire pour que la modification se propage aux requêtes web :

sudo systemctl restart php8.2-fpm

Remplacez php8.2-fpm par votre version PHP installée. Apache avec mod_php nécessite un rechargement d’Apache à la place :

sudo systemctl reload apache2

Méthode 2 : Modifier le fichier .htaccess (Apache uniquement)

La méthode .htaccess fonctionne exclusivement sur les serveurs Apache où AllowOverride autorise les directives de configuration PHP. Elle ne fonctionne pas sur Nginx, LiteSpeed avec certaines configurations, ou toute stack où PHP s’exécute en FastCGI/FPM avec AllowOverride None.

Étape 1 : Afficher et accéder au fichier .htaccess

Le fichier .htaccess est masqué par défaut. Dans le gestionnaire de fichiers cPanel, cliquez sur Paramètres dans le coin supérieur droit et activez Afficher les fichiers cachés (dotfiles). Le fichier se trouve dans public_html.

Via SSH :

nano ~/public_html/.htaccess

Étape 2 : Ajouter la directive PHP

Insérez la ligne suivante. La position est importante — placez-la en dehors de tout bloc <IfModule> pour qu’elle s’applique globalement :

php_value max_execution_time 300

Si votre serveur exécute PHP-FPM (identifiable par PHP/x.x.x (fpm-fcgi) dans phpinfo()), cette directive provoquera une erreur 500 Internal Server Error car php_value n’est pas valide dans ce contexte. Utilisez php_admin_value uniquement si l’hébergeur l’autorise explicitement, ou passez à la Méthode 1.

Étape 3 : Tester les erreurs 500

Après l’enregistrement, chargez immédiatement votre page d’accueil. Une erreur 500 signifie que la directive est incompatible avec la configuration de votre serveur. Supprimez la ligne et utilisez une méthode alternative.

Méthode 3 : Modifier wp-config.php en utilisant set_time_limit()

La fonction set_time_limit() réinitialise le minuteur d’exécution à partir du point où elle est appelée. Il s’agit d’un appel au moment de l’exécution PHP, et non d’une directive de configuration, ce qui signifie qu’elle fonctionne indépendamment du fait que le serveur autorise les remplacements php.ini ou .htaccess — tant que la liste disable_functions de PHP ne l’inclut pas.

Étape 1 : Localiser wp-config.php

Le fichier se trouve dans la racine de l’installation WordPress, un niveau au-dessus de public_html sur certaines configurations serveur, ou directement à l’intérieur sur d’autres.

find ~/public_html -maxdepth 2 -name "wp-config.php"

Étape 2 : Ajouter la directive

Ouvrez wp-config.php et ajoutez la ligne suivante avant le commentaire /* That's all, stop editing! Happy publishing. */ :

set_time_limit(300);

Appeler set_time_limit(0) désactive entièrement la limite pour cette requête. Utilisez ceci uniquement comme mesure de diagnostic temporaire — jamais en production — car cela supprime le filet de sécurité contre les boucles infinies.

Mise en garde importante : set_time_limit() n’affecte que l’exécution du script en cours. Cela ne modifie pas la configuration PHP à l’échelle du serveur. Si un plugin génère en interne un sous-processus ou effectue une requête HTTP bloquante, ce sous-processus n’est pas couvert par cet appel.

Méthode 4 : Utiliser un plugin WordPress

Pour les utilisateurs qui préfèrent ne pas modifier directement les fichiers serveur, plusieurs plugins exposent les valeurs de configuration PHP via l’interface d’administration WordPress. Cette approche convient aux propriétaires de sites non techniques sur un hébergement géré.

Options recommandées :

• WP Maximum Execution Time Exceeded — cible spécifiquement cette erreur et tente plusieurs méthodes de remplacement
• PHP Settings — fournit une vue tableau de bord des directives PHP actives et permet des remplacements sécurisés là où l’hébergeur le permet

Pour installer : accédez à Extensions > Ajouter dans le tableau de bord WordPress, recherchez le nom du plugin, installez et activez. Suivez la page de paramètres du plugin pour définir le temps d’exécution souhaité.

Limitation : Les plugins ne peuvent appeler que set_time_limit() ou ini_set() au moment de l’exécution. Si l’hébergeur a verrouillé max_execution_time via des restrictions open_basedir ou une configuration serveur codée en dur, le plugin échouera silencieusement à augmenter la limite. Vérifiez toujours la modification en utilisant phpinfo() après l’activation.

Méthode 5 : Contacter votre hébergeur

Si aucune des méthodes ci-dessus ne produit un changement vérifié dans la sortie phpinfo(), la limite est appliquée au niveau du serveur par votre hébergeur. C’est courant sur les plans d’hébergement mutualisé d’entrée de gamme où le fournisseur fixe un plafond strict pour protéger les ressources partagées.

Lors du contact avec le support, fournissez :

• Le message d’erreur exact et l’action WordPress qui le déclenche
• La valeur actuelle de max_execution_time depuis phpinfo()
• La valeur dont vous avez besoin (par exemple, 300 secondes) et la raison (par exemple, importation WooCommerce volumineuse)

Les hébergeurs réputés ajusteront soit la limite pour votre compte, soit vous indiqueront une option dans le panneau de contrôle (comme un sélecteur PHP dans cPanel) où vous pouvez la configurer vous-même.

Comparaison des cinq méthodes

Diagnostic des délais d’expiration persistants après augmentation de la limite

Si vous avez confirmé que la nouvelle limite est active dans phpinfo() mais que l’erreur persiste, le goulot d’étranglement n’est probablement pas max_execution_time. Considérez ces causes alternatives :

Directives de délai d’expiration FastCGI ou Nginx — Nginx possède sa propre directive fastcgi_read_timeout, distincte de PHP :

fastcgi_read_timeout 300;

Cela doit être défini dans le bloc serveur Nginx et nécessite un rechargement de Nginx.

Directive Apache TimeOut — Le délai de connexion propre à Apache peut mettre fin à une requête avant que la limite de PHP ne soit atteinte :

TimeOut 300

PHP-FPM request_terminate_timeout — Dans la configuration du pool PHP-FPM (/etc/php/8.x/fpm/pool.d/www.conf), cette directive tue indépendamment les processus worker :

request_terminate_timeout = 300

MySQL wait_timeout et interactive_timeout — Les requêtes de base de données à longue durée d’exécution peuvent provoquer la chute de la connexion MySQL en cours d’exécution, que PHP présente comme un échec de script plutôt qu’une erreur de base de données. Vérifiez avec :

SHOW VARIABLES LIKE '%timeout%';

Délais d’expiration au niveau de WooCommerce ou des plugins — Certains plugins implémentent leur propre logique de délai d’expiration interne en utilisant set_time_limit() de PHP avec une valeur inférieure, ce qui réinitialise le compteur et peut remplacer votre configuration.

Considérations de performance et bonnes pratiques

Augmenter max_execution_time est une correction ciblée, et non une solution architecturale permanente. Si une opération spécifique dépasse régulièrement 30 à 60 secondes, le processus sous-jacent doit être optimisé ou restructuré :

• Traitement par lots : Divisez les importations volumineuses en morceaux plus petits en utilisant le découpage basé sur AJAX (comme WP All Import le fait nativement) plutôt que de tout traiter dans une seule requête HTTP
• Traitement en arrière-plan : Utilisez WP-Cron ou une file d’attente de tâches appropriée (Action Scheduler, utilisé par WooCommerce) pour déplacer les travaux de longue durée hors du cycle de vie des requêtes web
• WP-CLI pour les opérations en masse : L’exécution CLI n’est pas soumise aux délais d’expiration du serveur web et est l’outil approprié pour les importations de bases de données, les opérations de recherche-remplacement et le traitement de médias en masse
• Optimiser les requêtes lentes : Utilisez le plugin Query Monitor pour identifier les requêtes de base de données consommant un temps d’exécution disproportionné
• Mettre à niveau le niveau d’hébergement : Si votre charge de travail nécessite régulièrement des temps d’exécution prolongés, un VPS avec cPanel vous donne un contrôle total sur la configuration PHP et des ressources dédiées qui n’entrent pas en concurrence avec d’autres locataires

Pour les charges de travail à haute intensité de calcul telles que les recommandations de produits basées sur l’IA ou les pipelines de traitement d’images à grande échelle, l’hébergement GPU décharge entièrement le calcul intensif de la couche PHP.

Liste de contrôle pratique

Utilisez cette liste de contrôle avant et après l’application de tout correctif :

• Confirmez la valeur actuelle de max_execution_time via phpinfo() ou WP-CLI avant d’effectuer des modifications
• Identifiez votre stack serveur (Apache + mod_php, Apache + FPM, Nginx + FPM) avant de choisir une méthode
• Appliquez une seule méthode à la fois — empiler simultanément des modifications php.ini, .htaccess et wp-config.php rend le débogage impossible
• Après avoir appliqué une modification, revérifiez la valeur active dans phpinfo() — ne supposez pas que la modification a fonctionné
• Testez en reproduisant l’action défaillante d’origine, pas seulement en chargeant la page d’accueil
• Si l’erreur est résolue, déterminez si l’opération sous-jacente peut être optimisée pour s’exécuter dans la limite d’origine
• Définissez un rappel calendrier pour annuler toute augmentation temporaire de limite (par exemple, set_time_limit(0)) après la fin de la tâche ponctuelle
• Sur l’hébergement mutualisé, documentez ce que l’hébergeur a confirmé comme valeur maximale autorisée pour votre plan
• Si les délais d’expiration persistent après confirmation que la limite PHP est augmentée, auditez indépendamment Nginx fastcgi_read_timeout, Apache TimeOut et PHP-FPM request_terminate_timeout

FAQ

Quelle est la valeur la plus sûre à définir pour max_execution_time dans WordPress ?

300 secondes (5 minutes) couvre la grande majorité des opérations WordPress gourmandes en ressources, y compris les installations de plugins volumineux, les importations WooCommerce et les mises à jour de thèmes. Les valeurs supérieures à 600 secondes doivent être traitées comme temporaires et annulées après la fin de la tâche spécifique.

Pourquoi ma modification de max_execution_time n’apparaît-elle pas dans phpinfo() après avoir modifié php.ini ?

Vous modifiez très probablement le mauvais fichier php.ini. PHP charge différents fichiers de configuration pour CLI, Apache mod_php et PHP-FPM. Exécutez php -i | grep "Loaded Configuration File" pour CLI et vérifiez la ligne Loaded Configuration File dans une page phpinfo() accessible par navigateur pour identifier le bon fichier pour les requêtes web.

L’augmentation de max_execution_time affecte-t-elle tous les utilisateurs de mon serveur ?

Sur un serveur partagé, modifier un php.ini au niveau utilisateur dans votre racine web n’affecte que votre compte. Modifier le php.ini global du serveur (qui nécessite un accès root) affecte tous les processus PHP sur ce serveur. Sur un serveur dédié, vous contrôlez la configuration globale et êtes entièrement responsable de son impact.

La méthode .htaccess fonctionnera-t-elle sur un serveur Nginx ?

Non. Le fichier .htaccess est un mécanisme spécifique à Apache. Nginx ne traite pas les fichiers .htaccess. Sur les stacks Nginx + PHP-FPM, vous devez modifier la configuration du pool PHP-FPM ou le php.ini au niveau serveur, ce qui nécessite tous deux un accès SSH.

Un plugin WordPress peut-il augmenter définitivement max_execution_time ?

Non. Les plugins s’exécutent dans le runtime PHP et ne peuvent appeler que set_time_limit() ou ini_set(), qui n’affectent que la requête en cours. Ils ne peuvent pas écrire dans php.ini ni persister les modifications de configuration entre les requêtes. Pour une augmentation permanente, vous devez modifier php.ini, .htaccess, ou un fichier de configuration de pool PHP-FPM au niveau du serveur.