Que signifie « erreur HTTP » lors du téléversement d'images dans WordPress ?

Cela signifie que l'outil de téléversement du navigateur a envoyé votre fichier au serveur et a reçu en retour quelque chose qu'il n'a pas pu interpréter comme une réponse valide. Le message décrit le symptôme, pas la cause. Un processus PHP planté, un blocage de pare-feu, un 403 et une réponse vide produisent exactement les mêmes deux mots.

Pourquoi la même image passe parfois et échoue d'autres fois ?

Les échecs intermittents traduisent presque toujours un épuisement de mémoire ou de CPU plutôt qu'une limite de configuration. Redimensionner une grande photo demande un pic de mémoire, et sur un hébergement mutualisé la quantité disponible varie selon la charge du serveur. Une limite fixe comme post_max_size échoue de façon identique à chaque tentative.

Passer de Imagick à GD dans WordPress corrige-t-il les erreurs HTTP ?

Parfois, et seulement pour une branche précise. Sur les hébergements mutualisés, ImageMagick est souvent bridé par un fichier de politique ou des limites de ressources basses, et il échoue là où GD réussit. Mais GD consomme plus de mémoire sur les très gros fichiers : le basculement peut aggraver les échecs liés à la mémoire au lieu de les résoudre.

Comment savoir si le pare-feu de mon hébergeur bloque le téléversement ?

Ouvrez les outils réseau de votre navigateur, téléversez le fichier et regardez le code de statut renvoyé pour async-upload.php. Un 403 ou un 406 avec un corps HTML signifie qu'un pare-feu applicatif ou une règle mod_security a rejeté la requête. Un 500 ou une réponse vide indique plutôt un plantage de PHP.

Augmenter upload_max_filesize va-t-il corriger l'erreur HTTP ?

Uniquement si le fichier dépasse réellement vos limites, et post_max_size compte généralement davantage. Si le corps entier de la requête dépasse post_max_size, PHP le rejette avant même que WordPress ne s'exécute et l'outil de téléversement ne reçoit rien. Augmenter l'un sans l'autre laisse le problème exactement où il était.

Un nom de fichier peut-il provoquer une erreur HTTP dans WordPress ?

Oui, même si c'est la branche la plus rare. Les caractères accentués, les apostrophes, les esperluettes et les alphabets non latins peuvent déclencher une règle de sécurité ou casser un chemin sur un système de fichiers dont l'encodage ne correspond pas. Renommer en minuscules simples, chiffres et tirets ne coûte rien et écarte cette branche en une dizaine de secondes.

WordPress « erreur HTTP » au téléversement d'images : l'arbre de décision qui trouve vraiment la cause

« Erreur HTTP » n’est pas une cause. C’est l’outil de téléversement des médias qui admet avoir envoyé votre fichier au serveur et reçu une réponse qu’il n’a pas su interpréter comme un succès — et au moins six défaillances sans rapport entre elles produisent ces deux mots identiques. C’est parce qu’on devine au hasard entre elles qu’on passe un après-midi à augmenter upload_max_filesize sur un site dont le vrai problème est une règle de pare-feu.

La sortie la plus rapide passe par une seule observation qui sépare les six causes en deux groupes, puis une vérification par branche.

D’abord : lire la réponse réelle

Ouvrez les outils de développement de votre navigateur, allez dans l’onglet Réseau et téléversez à nouveau le fichier. Guettez la requête vers async-upload.php. Ce qui revient constitue votre diagnostic.

Ce que vous voyez	Ce que ça signifie	Aller à
403 ou 406, corps HTML	Le pare-feu ou mod_security a rejeté la requête	Branche A
500, ou réponse vide, ou corps tronqué	PHP a planté ou manqué de mémoire en cours de traitement	Branche B
413	Le corps de la requête dépasse une limite serveur	Branche C
200, mais le corps n’est pas du JSON propre	Une extension ou un thème a écrit avant la réponse	Branche D
La requête n’aboutit jamais / expire	Limite de temps d’exécution, généralement sur les gros fichiers	Branche B

Ce seul coup d’œil élimine pour vous la majorité des conseils qui circulent. Si vous ne pouvez pas accéder aux outils du navigateur, activez d’abord la journalisation dans wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduisez le téléversement, puis lisez wp-content/debug.log. Une ligne d’erreur fatale nomme directement la branche. Si la ligne est indigeste, collez-la dans le décodeur de journal d’erreurs : il fait correspondre les signatures fatales courantes à ce qui a réellement cassé.

Branche A — une règle de pare-feu ou mod_security

Un 403 avec une page HTML dans le corps signifie que la requête n’a jamais atteint WordPress. Quelque chose placé devant — mod_security, Cloudflare, Wordfence, Sucuri, ou le jeu de règles de votre hébergeur — a jugé que le POST avait l’air malveillant.

La vérification : désactivez temporairement toute extension de sécurité et téléversez à nouveau. Si rien ne change, la règle se situe au niveau du serveur, et il faut demander à votre hébergeur de consulter le journal d’audit mod_security à l’horodatage du téléversement échoué. Il pourra mettre en liste blanche l’identifiant de règle concerné.

Soyez lucide sur les conseils que vous trouverez à ce sujet. Les extraits qui vous disent de coller ceci dans .htaccess :

SecFilterEngine Off
SecFilterScanPOST Off

visent mod_security 1.x, quasiment disparu. Sur un serveur moderne, ces directives ne font rien ou renvoient un 500 qui empire la situation. Les versions actuelles de mod_security utilisent SecRuleEngine, et la plupart des hébergeurs infogérés interdisent de toute façon de le redéfinir par répertoire. Demandez à l’hébergeur ; ne collez pas.

Branche B — limites de mémoire ou d’exécution PHP

C’est la branche la plus fréquente et celle dont l’indice est le plus net : c’est intermittent. Le même fichier passe au troisième essai, ou une photo de 2 Mo échoue alors qu’un PDF de 6 Mo passe sans problème. Les limites de configuration fixes échouent de la même manière à chaque fois. Pas les échecs de mémoire, car la quantité disponible dépend de ce que le serveur fait par ailleurs.

Pourquoi les images en particulier : WordPress ne se contente pas de stocker le fichier, il le décompresse en pixels bruts pour générer chaque taille intermédiaire — medium_large, tout ce qui est enregistré via add_image_size, woocommerce_thumbnail si vous tenez une boutique, plus une copie -scaled si l’image dépasse le big_image_size_threshold. Un JPEG de 12 mégapixels pèse quelques Mo sur le disque et environ 48 Mo en mémoire, avant même le tampon de redimensionnement. Une limite de 128 Mo disparaît vite.

Relevez-la dans wp-config.php, au-dessus de la ligne « stop editing » :

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

La contrepartie réelle : WP_MEMORY_LIMIT ne peut pas dépasser ce que PHP lui-même autorise. Si votre hébergeur plafonne memory_limit à 128M, cette constante est purement décorative. Vérifiez la valeur réelle dans Outils → Santé du site → Info → Serveur, et non ce que vous avez écrit. Si c’est la limite propre à PHP qui fait plafond, seul l’hébergeur peut la déplacer.

Branche C — taille de fichier et limites de requête

Consultez les chiffres réels dans Outils → Santé du site → Info → Gestion des médias. Deux réglages comptent et les gens n’en changent jamais qu’un :

upload_max_filesize — le plafond pour un fichier isolé.
post_max_size — le plafond pour la totalité du corps de la requête.

Si l’ensemble du POST dépasse post_max_size, PHP jette la requête avant que WordPress n’exécute la moindre ligne de code. Il n’y a plus rien à renvoyer, l’outil de téléversement reçoit donc une réponse inexploitable et affiche « erreur HTTP ». post_max_size doit toujours être confortablement supérieur à upload_max_filesize.

Une nuance utile : quand un fichier dépasse uniquement upload_max_filesize, l’outil de téléversement l’intercepte généralement dans le navigateur et indique que le fichier dépasse la taille maximale autorisée — un message plus clair. Une « erreur HTTP » toute sèche pointe donc plus souvent vers post_max_size ou vers la branche B que vers le réglage que tout le monde augmente en premier.

L’endroit où les modifier dépend de votre configuration. Sur Apache avec mod_php, .htaccess fonctionne :

php_value upload_max_filesize 64M
php_value post_max_size 128M

Sur PHP-FPM, LiteSpeed ou NGINX — c’est-à-dire la majorité des hébergements modernes — ces lignes ne font rien et peuvent provoquer un 500. Utilisez plutôt le panneau de réglages PHP de l’hébergeur ou un fichier .user.ini. NGINX applique en outre son propre client_max_body_size, que seul l’hébergeur peut relever.

Branche D — la bibliothèque d’édition d’images (Imagick contre GD)

WordPress privilégie ImageMagick lorsque l’extension PHP est présente, et se rabat sur GD sinon. Sur les hébergements mutualisés, ImageMagick est fréquemment le problème : son fichier de configuration de politique restreint la mémoire, le disque et la surface autorisée par opération, et quand un redimensionnement dépasse l’une de ces limites, le processus meurt sans message exploitable. Vous observerez souvent cela sur les grandes images alors que les petites passent — ce qui ressemble à la branche B sans en être.

Forcez GD pour tester l’hypothèse :

add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD' );
} );

Placez ce code dans functions.php ou dans une petite mu-extension, retentez le téléversement, puis retirez-le si rien ne change.

L’arbitrage honnête : GD n’est pas strictement meilleur. Il conserve l’intégralité du bitmap décompressé dans la mémoire de PHP, si bien que sur de très gros fichiers il peut heurter memory_limit là où ImageMagick — qui travaille en partie hors de l’allocation PHP — serait passé. Le basculement peut échanger une panne contre une autre. Considérez-le d’abord comme un diagnostic, ensuite seulement comme un correctif.

Branche E — permissions du dossier uploads

Rare en hébergement infogéré, courant juste après une migration ou un déplacement manuel de serveur. Si wp-content/uploads n’est pas accessible en écriture par l’utilisateur du serveur web, ou si un sous-dossier année/mois fraîchement créé a hérité du mauvais propriétaire, l’écriture échoue.

ls -ld wp-content/uploads
ls -ld wp-content/uploads/2026/07

Les répertoires devraient typiquement être en 755 et appartenir à l’utilisateur sous lequel PHP s’exécute. Ne mettez pas 777 parce qu’un forum vous l’a dit : cela corrige le symptôme en rendant le dossier inscriptible par tous les comptes du serveur, ce qui sur un mutualisé constitue une véritable exposition.

Branche F — le nom du fichier

La vérification la moins coûteuse de la liste, faites-la donc tôt même si c’est la moins probable. Renommez le fichier en lettres minuscules simples, chiffres et tirets — sans accents, apostrophes, esperluettes, #, ni caractères non latins — et téléversez à nouveau. Les caractères spéciaux déclenchent parfois une règle de sécurité ou cassent sur un système de fichiers dont l’encodage ne correspond pas. Dix secondes pour écarter la piste.

Ce qu’il ne faut pas faire

Ne commencez pas par désactiver toutes vos extensions. C’est perturbant et cela ne teste que les branches A et D. La réponse réseau vous en dit plus en cinq secondes.

N’ajoutez pas une ligne de handler .htaccess au hasard. Les extraits qui circulent avec une directive SetHandler ou AddHandler supposent la configuration PHP d’un hébergeur précis. Sur la mauvaise pile, ils mettent tout le site à terre avec un 500.

N’acceptez pas « ça a marché à la deuxième tentative » comme une réparation. Le succès intermittent est la signature de la branche B, et le problème reviendra dès que le serveur sera chargé ou que quelqu’un téléversera plus gros.

Toujours bloqué ?

Si la réponse est un 200 propre avec du JSON valide et que le téléversement échoue quand même, la rupture se produit après l’arrivée du fichier — généralement une extension accrochée à la chaîne de traitement des fichiers joints qui lève une erreur fatale, ou une extension d’optimisation qui envoie sa propre requête vers un service externe qui expire. Activez WP_DEBUG_LOG, reproduisez, et passez l’erreur fatale obtenue dans le décodeur de journal d’erreurs pour voir quel fichier et quel hook sont réellement responsables.