WordPress « Erreur HTTP » à l'envoi d'une image : solutions

« Erreur HTTP » à l’envoi d’une image : ce que ça signifie

L’« Erreur HTTP » de la médiathèque WordPress est un message générique : le navigateur n’a pas reçu de réponse exploitable du serveur pendant l’envoi. La cause la plus fréquente est un manque de ressources lors de la création des vignettes (pixels trop nombreux, mémoire PHP, bibliothèque d’images), plus rarement un pare‑feu.

C’est gérable. Le message ne dit rien de la cause réelle, mais quelques tests, faits dans le bon ordre, la désignent en dix minutes. Un point rassurant : le fichier est parfois bien enregistré malgré l’erreur, et il manque seulement des vignettes. Actualisez la médiathèque avant de paniquer.

Pourquoi ça arrive

Voici les causes, de la plus probable à la plus rare :

• Une image trop grande en pixels (pas forcément trop lourde en Mo).
• Une mémoire PHP insuffisante pour décompresser l’image et générer les tailles.
• Une bibliothèque d’images (Imagick ou GD) bridée par l’hébergeur ou absente.
• Des droits ou un propriétaire incorrects sur wp-content/uploads, ou un disque plein.
• Un pare‑feu (mod_security, Cloudflare, plugin de sécurité) qui bloque la requête.
• Un plugin ou une version de PHP trop ancienne.

Deux termes à connaître. Imagick est une extension PHP qui s’appuie sur ImageMagick pour traiter les images, et WordPress l’utilise en priorité si elle est disponible. GD est la bibliothèque de repli de PHP : elle garde les images décompressées en mémoire, donc elle consomme davantage.

1. Lire le code HTTP de la requête

Ouvrez les outils de développement du navigateur (F12), onglet Réseau, puis renvoyez l’image. Cherchez la requête async-upload.php et regardez son code, comme le recommande le guide de DépannageWP.

Code	Sens probable	Étape à suivre
500	Erreur PHP (mémoire, Imagick, plugin)	Étapes 2, 3, 4
413	Fichier trop gros pour le serveur web	Étape 3 (limites d’envoi)
403	Refus d’un pare‑feu	Étape 6
Aucune réponse, délai long	Délai d’exécution dépassé	Étapes 3 et 4

Activez aussi le journal d’erreurs PHP (WP_DEBUG_LOG dans wp-config.php) et relisez‑le après l’échec. Une ligne « cache resources exhausted » pointe vers les limites d’Imagick, selon WPSupport.

2. Réduire l’image avant de l’envoyer

La mémoire consommée dépend du nombre de pixels, pas du poids du fichier. Estimation d’ordre de grandeur : une photo de 4000 × 3000 px compte 12 millions de pixels, soit environ 48 Mo une fois décompressée à 4 octets par pixel, avant même les vignettes.

WordPress réduit lui‑même les images dont la largeur ou la hauteur dépasse 2560 px, et ajoute le suffixe « -scaled » au fichier source : documentation WordPress, 2019. Ce traitement est justement celui qui peut saturer un serveur bridé. Les PNG sont exclus de ce redimensionnement automatique source : Trac WordPress, changeset 46834, donc un gros PNG passe sans réduction.

À faire : redimensionnez à 2000 px de large maximum, comme le conseille Sitebug, exportez en JPEG ou WebP, et renommez le fichier (sans accents ni espaces). Si l’envoi passe, la cause est trouvée.

3. Relever la mémoire PHP et les limites d’envoi

La mémoire PHP (memory_limit) désigne la quantité maximale de RAM qu’un script PHP peut utiliser. WordPress relève sa limite pour traiter les images, mais une limite fixée au niveau du serveur peut rester insuffisante source : documentation WordPress, classe WP_Image_Editor_Imagick.

Dans wp-config.php (fichier de configuration de votre site, pas un fichier du cœur de WordPress), avant la ligne « That’s all, stop editing » :

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

WP_MAX_MEMORY_LIMIT s’applique à l’administration, donc aux envois d’images. Si rien ne change, la limite est imposée plus haut : réglez‑la dans le panel de l’hébergeur ou dans php.ini / .user.ini.

Directive	Rôle	Symptôme si trop basse	Valeur de départ
memory_limit	RAM max par script	Erreur HTTP, page blanche, 500	256M
upload_max_filesize	Poids max d’un fichier	Message de taille dépassée, 413	32M
post_max_size	Taille max de la requête	Envoi vide ou refusé	64M
max_execution_time	Durée max d’un script (secondes)	Coupure en milieu de traitement	120
max_input_time	Durée max de réception des données	Échec sur connexion lente	120

Gardez post_max_size supérieur ou égal à upload_max_filesize. Détails dans notre guide des directives PHP, et pour la mémoire seule dans mémoire PHP épuisée sur WordPress. Un code 413 est traité dans l’article sur l’erreur 413.

4. Vérifier Imagick et GD

Allez dans Outils > Santé du site > Info > Médias : WordPress y indique la bibliothèque active. Sans Imagick ni GD, l’envoi réussit mais sans vignettes.

Sur un mutualisé, l’hébergeur limite souvent les ressources et les threads d’Imagick, ce qui provoque l’erreur source : Kinsta. Le contournement documenté consiste à limiter Imagick à un thread, dans .htaccess (serveurs Apache) :

SetEnv MAGICK_THREAD_LIMIT 1

Si cela ne suffit pas, forcez GD avec un extrait ajouté dans un plugin de code ou le thème enfant :

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

GD est plus gourmand en mémoire : revenez à l’étape 3 si l’erreur persiste. Pour désactiver le redimensionnement automatique, un filtre big_image_size_threshold renvoyant false existe, mais il ne règle pas le fond du problème et laisse passer des images énormes.

5. Contrôler les droits du dossier uploads

Le dossier wp-content/uploads doit être accessible en écriture par l’utilisateur du serveur web. Valeurs courantes : 755 pour les dossiers, 644 pour les fichiers, avec le bon propriétaire. Corrigez‑les depuis le gestionnaire de fichiers de l’hébergeur ou en SFTP (si la connexion pose problème : FTP refusé sur FileZilla). Vérifiez aussi l’espace disque : un disque plein donne le même symptôme (erreur 507).

6. Écarter le pare‑feu

Un code 403 sur async-upload.php signale un blocage. Mod_security, un pare‑feu applicatif (WAF), Cloudflare ou un plugin de sécurité peuvent rejeter une image à cause de son nom ou de ses métadonnées. Désactivez temporairement le plugin de sécurité, ou demandez à l’hébergeur de lire les journaux de mod_security. La procédure complète : erreur 403 sur WordPress.

7. Isoler un plugin ou une vieille version de PHP

Désactivez les plugins d’optimisation d’images et de sécurité, puis testez. Méthode complète dans conflit de plugins WordPress. Vérifiez enfin que PHP est à jour dans le panel de l’hébergeur, après sauvegarde.

FAQ

L'image est dans la médiathèque malgré l'erreur : est‑ce grave ?

Non. Le fichier d’origine est enregistré, mais la génération des vignettes a échoué. Les tailles manquantes peuvent donner des images floues ou lourdes sur le site. Renvoyez l’image réduite ou régénérez les vignettes avec un plugin dédié.

Pourquoi une image de 500 Ko fait‑elle planter l'envoi ?

Parce que la mémoire utilisée dépend des dimensions en pixels, pas du poids. Un fichier léger mais très grand en pixels demande beaucoup de RAM une fois décompressé.

Faut‑il passer d'Imagick à GD ?

Seulement après avoir essayé de limiter les threads d’Imagick et de relever la mémoire. GD consomme plus de mémoire, donc il règle le problème dans certains cas et l’aggrave dans d’autres.

Dois‑je modifier les fichiers de WordPress ?

Non. Ne touchez jamais au cœur de WordPress : il est écrasé à chaque mise à jour. Utilisez wp-config.php, .htaccess, le panel de l’hébergeur ou un plugin de code.

Quand passer la main à un pro

Si le code reste 500 ou 403 après les étapes 2 à 6, la cause se trouve côté serveur : limites imposées par l’hébergeur, module Imagick défaillant, règles de pare‑feu que vous ne pouvez pas lire. Envoyez à votre hébergeur ou à votre prestataire le code HTTP, la ligne du journal d’erreurs et la bibliothèque active. Sur un site en abonnement avec maintenance, ce diagnostic fait partie du travail courant, et la maintenance d’un site web évite d’y passer l’après‑midi.