« Le serveur ne peut pas traiter l’image » : Imagick, GD et mémoire

Le serveur ne peut pas traiter l’image. Cela peut se produire si le serveur est occupé ou ne dispose pas de suffisamment de ressources pour terminer la tâche. Téléverser une image plus petite peut aider. La taille maximale suggérée est de 2560 pixels.

En anglais : The server cannot process the image. This can happen if the server is busy or does not have enough resources to complete the task. Uploading a smaller image may help. Suggested maximum size is 2560 pixels.

Vous téléversez une photo dans la médiathèque et WordPress affiche, sur la ligne du fichier : « Le serveur ne peut pas traiter l’image. Cela peut se produire si le serveur est occupé ou ne dispose pas de suffisamment de ressources pour terminer la tâche. Téléverser une image plus petite peut aider. La taille maximale suggérée est de 2560 pixels. » Le message est volontairement vague : il couvre toute panne survenue pendant le traitement de l’image par le serveur. Il apparaît dans l’administration, dans la médiathèque classique comme dans l’éditeur de blocs, presque toujours avec de grosses photos.

Contrairement à une limite de taille, l’image a souvent atteint le serveur. C’est son traitement (redimensionnement, création des miniatures, conversion de format) qui a planté. Le diagnostic porte donc sur la mémoire, le temps d’exécution et la bibliothèque de traitement d’images.

Ce que signifie cette erreur

Une fois le fichier reçu, WordPress crée les tailles intermédiaires de l’image (wp_create_image_subsizes()). Si l’image dépasse 2 560 pixels sur un côté, il la réduit d’abord : ce seuil est la valeur par défaut du filtre big_image_size_threshold (wp-admin/includes/image.php). Le travail est confié à un « éditeur d’images », choisi par _wp_image_editor_choose() (wp-includes/media.php) parmi deux classes : WP_Image_Editor_Imagick, prioritaire, puis WP_Image_Editor_GD. Ces classes sont listées par le filtre wp_image_editors.

Pendant ce traitement, WordPress demande davantage de mémoire à PHP grâce à wp_raise_memory_limit( 'image' ) : la limite est portée à la constante WP_MAX_MEMORY_LIMIT (256 Mo par défaut) ou à la valeur de memory_limit si elle est plus haute, modifiable avec le filtre image_memory_limit. Si ce plafond ou le délai maximal d’exécution est dépassé, PHP s’arrête avec une erreur fatale et le serveur répond par un code 500. Le navigateur détecte alors l’en-tête X-WP-Upload-Attachment-ID, relance plusieurs fois la création des miniatures (action media-create-image-subsizes) et, en cas d’échec répété, affiche ce message (wp-includes/js/plupload/wp-plupload.js, chaîne http_error_image de wp-includes/script-loader.php).

Dans l’éditeur de blocs, le même scénario produit : « 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). Ne confondez pas ce cas avec les messages voisins : « Le redimensionnement de l’image a échoué. » (wp-includes/class-wp-image-editor-gd.php), « Aucun éditeur n’a pas pu être sélectionné. » (aucune bibliothèque d’images disponible) ou « Le serveur ne peut pas traiter les images au format HEIC. Veuillez les convertir au format JPEG avant de les mettre en ligne. »

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
L’erreur n’apparaît qu’avec les très grandes photos, les petites passent	Mémoire PHP insuffisante pour décompresser l’image	Dimensions en pixels, memory_limit, debug.log
« Allowed memory size of … bytes exhausted » dans le journal	Plafond mémoire atteint pendant le redimensionnement	memory_limit et WP_MAX_MEMORY_LIMIT
Échec après un long délai, parfois un code 502 ou 504	Délai d’exécution ou de passerelle dépassé	max_execution_time, délais du proxy
Aucun éditeur actif, ou refus de formats WebP, AVIF ou HEIC	Imagick ou GD absent, ou compilé sans le format	Outils, Santé du site, Informations, « Traitement des médias »
Plantage immédiat avec Imagick, sans message PHP	Limites de ressources d’ImageMagick (policy.xml) ou bibliothèque instable	Section « Limites de ressources Imagick » de Santé du site

Les causes les plus fréquentes

1. Une image aux dimensions excessives (photo d’appareil récent, scan, capture en haute résolution) : la mémoire nécessaire dépend du nombre de pixels, pas du poids du fichier.
2. Une valeur de memory_limit basse sur un hébergement mutualisé, sans marge pour le traitement d’images.
3. Un délai d’exécution ou de passerelle trop court pour une image lourde.
4. Un format que la bibliothèque installée ne sait pas lire ou écrire : WebP, AVIF et surtout HEIC.
5. Des limites de ressources imposées à ImageMagick, ou une extension Imagick défectueuse.
6. Trop de tailles d’images enregistrées par le thème et les extensions, qui multiplient le travail à chaque envoi.

Solutions pas à pas

1. Réduire l’image avant l’envoi

C’est la solution la moins invasive, et celle que WordPress recommande dans son message. Redimensionnez l’image pour que son plus grand côté ne dépasse pas 2 560 pixels (1 920 suffisent pour presque tous les affichages), exportez-la en JPEG, WebP ou PNG puis téléversez-la de nouveau. Une photo de 6 000 × 4 000 pixels occupe environ 96 Mo une fois décompressée ; réduite à 2 560 pixels de large, elle en demande moins de 20.

2. Vérifier l’éditeur d’images actif

Ouvrez Outils, Santé du site, onglet « Informations », section « Traitement des médias » : vous y lisez l’« Éditeur actif », la version d’Imagick et ses limites de ressources. En WP-CLI, ces commandes sont en lecture seule :

wp eval 'echo extension_loaded( "imagick" ) ? "Imagick actif" : "Imagick absent", PHP_EOL;'
wp eval 'echo extension_loaded( "gd" ) ? "GD actif" : "GD absent", PHP_EOL;'
wp eval 'var_dump( wp_image_editor_supports( array( "mime_type" => "image/webp" ) ) );'

Si aucun éditeur n’est actif, demandez à l’hébergeur d’activer l’extension PHP imagick ou gd. Notre article sur la prise en charge de l’AVIF par WordPress détaille comment vérifier qu’un format est géré.

3. Augmenter la mémoire disponible

Relevez memory_limit dans le php.ini ou le .user.ini de l’hébergement, puis, si besoin, la limite propre à WordPress pour l’administration et les images, dans wp-config.php :

; php.ini ou .user.ini
memory_limit = 256M

// wp-config.php (avant « That's all, stop editing! »)
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Ces valeurs ne peuvent pas dépasser le plafond de l’hébergeur. Si le journal affiche « Allowed memory size… », la fiche mémoire épuisée détaille toutes les façons de relever cette limite.

4. Alléger le travail demandé à WordPress

Deux leviers réduisent la charge à chaque envoi : abaisser le seuil de réduction automatique et supprimer les tailles d’images inutiles. Placez ce code dans un plugin spécifique au site (wp-content/mu-plugins/) ou dans le functions.php d’un thème enfant :

<?php
// Réduire au-delà de 1 920 px au lieu de 2 560 px.
add_filter( 'big_image_size_threshold', function () {
	return 1920;
} );

// Ne pas générer une taille inutilisée (ici « medium_large »).
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
	unset( $sizes['medium_large'] );
	return $sizes;
} );

Retourner false dans big_image_size_threshold désactive la réduction automatique : n’y recourez pas sur un serveur à court de mémoire. Notre article sur les tailles de miniatures inutilisées à désactiver explique comment choisir celles à supprimer.

5. Changer d’éditeur d’images

Si Imagick plante sans trace ou si ses limites de ressources sont trop basses, forcez GD, qui peut consommer moins de ressources sur un hébergement mutualisé :

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

À l’inverse, GD gère moins bien certains formats récents (AVIF, WebP selon les versions) : vérifiez le résultat avec les commandes de la solution 2. Si vous contrôlez le serveur, vous pouvez aussi relever les limites memory, map, area et disk du fichier policy.xml d’ImageMagick (son emplacement dépend de la distribution), puis relancer PHP-FPM.

6. Donner plus de temps au traitement

Relevez max_execution_time (par exemple à 300 secondes) et, derrière un proxy, ses délais de lecture : sous nginx, fastcgi_read_timeout 300;. Voyez les fiches temps d’exécution dépassé et erreur 504 pour les détails.

7. Convertir les formats non gérés

Un fichier HEIC (iPhone), un WebP ou un AVIF refusé par la bibliothèque installée se convertit en JPEG ou PNG avant l’envoi. Le message dédié de WordPress précise : « Le serveur web ne peut pas générer de tailles d‘image responsive pour cette image. Convertissez-la en JPEG ou PNG avant de la téléverser. » L’article convertir ses images en WebP présente les options côté serveur.

8. Régénérer les miniatures manquantes

Quand l’image est arrivée mais sans miniatures, une fois la cause corrigée, recréez-les en WP-CLI (action qui écrit dans le dossier d’envois : sauvegardez d’abord) :

wp media regenerate --only-missing

Prévenir l’erreur

• Fixez une consigne simple pour les contributeurs : images de 2 000 pixels maximum côté long, au format JPEG ou WebP.
• Dimensionnez memory_limit pour le traitement d’images, pas seulement pour l’affichage des pages.
• Supprimez les tailles d’images que votre thème n’emploie pas.
• Contrôlez après toute migration la présence d’Imagick ou de GD et les formats pris en charge, idéalement en reproduisant le serveur cible dans un environnement local avant la bascule.
• Conservez un journal d’erreurs actif en production pour retrouver la trace exacte d’un plantage.

FAQ