Erreur HTTP lors du téléversement d’une image dans WordPress

Le serveur a renvoyé une réponse inattendue. Cependant, le fichier a peut-être été bien téléversé. Veuillez vérifier dans la médiathèque ou actualiser la page.

En anglais : Unexpected response from the server. The file may have been uploaded successfully. Check in the Media Library or reload the page.

Vous faites glisser une image dans la médiathèque, la barre de progression démarre, puis la ligne passe au rouge avec un message d’erreur. Selon la nature du fichier, WordPress affiche « Le serveur a renvoyé une réponse inattendue. Cependant, le fichier a peut-être été bien téléversé… » pour un fichier ordinaire, ou « Le serveur ne peut pas traiter l’image… » pour une image. On parle couramment d’« erreur HTTP » pour toute cette famille de pannes. Elle apparaît dans l’administration : médiathèque, écran « Ajouter », éditeur de blocs, import d’une image à la une.

Le point essentiel à retenir : ce message ne dit pas pourquoi l’envoi a échoué. Il signale seulement que la réponse du serveur n’était pas celle d’un téléversement réussi. Le vrai diagnostic se lit dans le code HTTP et dans le journal d’erreurs, et c’est ce que ce guide vous apprend à faire.

Ce que signifie cette erreur

Dans la médiathèque classique, le fichier est envoyé par la bibliothèque Plupload vers wp-admin/async-upload.php. Lorsque la réponse n’est pas un succès (code HTTP 4xx ou 5xx, connexion coupée, réponse illisible), Plupload remonte une erreur de type « HTTP ». Le script wp-includes/js/plupload/wp-plupload.js la traduit alors en message : la chaîne http_error pour un fichier quelconque, la chaîne http_error_image pour une image (les deux sont déclarées dans wp-includes/script-loader.php).

Pour les images, WordPress a prévu un mécanisme de rattrapage. L’envoi du fichier lui-même peut réussir alors que la génération des tailles intermédiaires (miniatures) échoue, par exemple par manque de mémoire. Le serveur a déjà créé la pièce jointe et l’indique dans l’en-tête de réponse X-WP-Upload-Attachment-ID. Le navigateur relance alors, à plusieurs reprises, l’action media-create-image-subsizes pour terminer le travail. Si toutes les tentatives échouent, WordPress supprime la pièce jointe créée depuis moins de dix minutes et affiche le message d’erreur (wp-admin/includes/ajax-actions.php).

Dans l’éditeur de blocs, l’envoi passe par l’API REST (/wp/v2/media). Le comportement est voisin : en cas d’échec 5xx après création de la pièce jointe, l’éditeur affiche « Le téléversement du média a échoué. S’il s’agit d’une photo ou d’une grande image, veuillez la redimensionner puis réessayer. » (wp-includes/js/dist/api-fetch.js). Autre conséquence pratique : le fichier est parfois bien arrivé. Avant de recommencer, vérifiez toujours la médiathèque.

Diagnostic rapide

Ouvrez les outils de développement du navigateur (touche F12), onglet « Réseau », relancez le téléversement et repérez la requête vers async-upload.php (ou /wp-json/wp/v2/media dans l’éditeur de blocs). Son code de statut oriente immédiatement le diagnostic.

Symptôme / constat	Cause probable	À vérifier
Statut 413 « Request Entity Too Large »	Le fichier dépasse la limite du serveur web ou du proxy	client_max_body_size (nginx), LimitRequestBody (Apache), limite du CDN
Statut 403 ou 406, souvent avec une page de l’hébergeur	Pare-feu applicatif (ModSecurity, WAF) ou règle de sécurité	Journaux du pare-feu, règles propres à async-upload.php
Statut 500 après l’envoi d’une image	Erreur fatale PHP pendant la création des miniatures (mémoire, extension d’image)	wp-content/debug.log, memory_limit, éditeur d’images actif
Statut 502 ou 504, ou attente très longue	Délai dépassé côté PHP-FPM, proxy ou CDN	max_execution_time, délais du proxy, taille du fichier
Statut 200 mais erreur affichée, ou réponse illisible	Texte parasite avant la réponse (avertissement PHP, extension qui affiche du contenu)	Onglet « Réponse » de la requête, journal d’erreurs

Les causes les plus fréquentes

1. Une limite de taille plus basse que le fichier, côté PHP, serveur web ou CDN (voir la fiche fichier trop volumineux).
2. Un manque de mémoire PHP ou de temps d’exécution pendant la génération des miniatures d’une grosse image.
3. Un pare-feu applicatif (ModSecurity, règles de l’hébergeur, WAF d’un CDN) qui bloque la requête d’envoi.
4. Un délai de passerelle dépassé : le serveur met plus longtemps à répondre que ne l’accepte le proxy.
5. Une extension qui intervient pendant le téléversement (optimisation d’images, envoi vers un stockage distant, sécurité) et échoue.
6. Un dossier wp-content/uploads non inscriptible, ou un disque plein.

Solutions pas à pas

1. Vérifier si le fichier est arrivé

Ouvrez Médias, Bibliothèque, puis rechargez la page. Si l’image y figure avec ses miniatures, l’envoi a réussi et seule la réponse était défectueuse : rien d’autre à faire. Sinon, contrôlez par SFTP le dossier wp-content/uploads/AAAA/MM du mois en cours : un fichier présent sans miniatures confirme un échec pendant la génération des tailles.

2. Lire le code HTTP réel

Relancez l’envoi avec l’onglet « Réseau » ouvert (voir le tableau plus haut). Notez le code de statut et, dans l’onglet « Réponse », le texte renvoyé. Un fichier en erreur 413 ne se règle pas comme une erreur 500 : cette étape évite de modifier au hasard des réglages sans rapport.

3. Activer le journal d’erreurs

Pour une erreur 500 ou une réponse illisible, activez la journalisation sans afficher les erreurs aux visiteurs. Ajoutez ces lignes dans wp-config.php, avant la ligne « That’s all, stop editing ! », après avoir sauvegardé le fichier :

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

Relancez le téléversement puis lisez wp-content/debug.log : un message « Allowed memory size of … bytes exhausted » pointe la mémoire (solution 5), une erreur d’extension ou de classe pointe un conflit (solution 6). Notre guide sur les bons réflexes avec WP_DEBUG_LOG détaille la démarche. Pensez à retirer ces lignes une fois le problème réglé.

4. Lever la limite de taille

Pour un code 413 ou un fichier lourd, relevez ensemble upload_max_filesize, post_max_size et, côté serveur web, la directive nginx suivante, puis rechargez le service :

# nginx : dans le bloc server ou location concerné
client_max_body_size 72M;

nginx -t && systemctl reload nginx

La procédure complète, avec Apache et .user.ini, est décrite dans la fiche fichier trop volumineux.

5. Donner plus de mémoire et de temps à PHP

Une photo de 6 000 × 4 000 pixels occupe environ 96 Mo une fois décompressée, avant même la création des copies redimensionnées. Si le journal mentionne la mémoire, augmentez les limites dans le php.ini (ou le .user.ini de l’hébergement mutualisé) :

memory_limit = 256M
max_execution_time = 300

WordPress relève lui-même la limite de mémoire pour le traitement d’images, jusqu’à la constante WP_MAX_MEMORY_LIMIT (256 Mo par défaut). Cette hausse ne peut pas dépasser le plafond fixé par l’hébergeur. Pour aller plus loin sur les images, consultez la fiche serveur ne peut pas traiter l’image.

6. Isoler une extension ou le pare-feu

Si le journal ne montre rien et que le code est 403 ou 406, demandez à l’hébergeur de consulter le journal de son pare-feu pour l’heure de votre essai : il identifiera la règle déclenchée et pourra l’assouplir pour async-upload.php. Si le code est 500 avec une trace pointant une extension, désactivez-la (ou renommez son dossier par SFTP si l’administration est inaccessible), puis retentez :

# Lecture : lister les extensions actives
wp plugin list --status=active --fields=name,version

# Désactiver une extension précise (à vous de choisir le nom)
wp plugin deactivate nom-de-l-extension

7. Contourner l’interface pour un fichier ponctuel

Quand l’urgence prime, déposez le fichier par SFTP dans un dossier temporaire du serveur, puis enregistrez-le dans la médiathèque avec WP-CLI, qui n’est soumis ni au délai du navigateur ni aux limites de la requête web :

wp media import /chemin/vers/image.jpg --title="Titre de l’image"
wp media regenerate --only-missing

Attention, cette commande modifie votre site : réalisez une sauvegarde au préalable si vous manipulez beaucoup de fichiers. Pour mieux comprendre les blocages à l’import, voir aussi notre article sur l’erreur 413 lors d’un import de médias.

Prévenir l’erreur

• Redimensionnez et compressez les images avant l’envoi : un côté de 2 560 pixels est largement suffisant pour un site (WordPress réduit d’ailleurs lui-même les images au-delà de ce seuil).
• Documentez la chaîne complète des limites (PHP, serveur web, proxy ou CDN, pare-feu) et revérifiez-la après chaque migration d’hébergeur.
• Gardez un journal d’erreurs actif en production, sans affichage public, pour disposer de la trace au moment où le problème survient.
• Limitez les extensions qui interviennent à l’envoi des fichiers et testez-les avec une image lourde avant la mise en production.
• Pour les envois volumineux et réguliers, privilégiez WP-CLI ou un stockage objet plutôt que le navigateur.

FAQ