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

> « Le serveur ne peut pas traiter l’image » dans WordPress ? Voyez comment corriger Imagick, GD, memory_limit et les miniatures, avec les réglages pas à pas.

- Auteur : WordPress Développement
- Publié le : 2026-10-02
- Mis à jour le : 2026-10-02
- URL : https://www.wpmoderne.fr/erreurs-wordpress/serveur-ne-peut-pas-traiter-image/

> La création des miniatures a échoué : mémoire PHP, délai ou bibliothèque d’images (Imagick, GD) insuffisants. Réduisez l’image à 2 560 pixels, puis relevez memory_limit ou changez d’éditeur d’images.

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](https://www.wpmoderne.fr/performance/avif-wordpress-6-5-activer-mesurer-gain/) 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](https://www.wpmoderne.fr/erreurs-wordpress/memoire-epuisee/) 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](https://www.wpmoderne.fr/performance/miniatures-tailles-inutilisees-desactiver/) 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é](https://www.wpmoderne.fr/erreurs-wordpress/temps-execution-depasse/) 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](https://www.wpmoderne.fr/performance/webp-convertir-images-wordpress/) 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