« Le fichier dépasse la taille maximale autorisée » au moment d’envoyer une image ou un thème ? Cette limite n’est pas fixée par WordPress mais par PHP, et c’est ce qui explique pourquoi tant de solutions trouvées en ligne ne fonctionnent pas. Trois valeurs doivent être relevées ensemble, et une méthode très répandue est en réalité inopérante par construction.
Connaître votre limite actuelle
Deux endroits vous l’indiquent. Dans Médias > Ajouter, une mention sous la zone d’envoi affiche la taille maximale autorisée. Dans Outils > Santé du site > Informations > Serveur, vous trouverez le détail complet des réglages PHP en vigueur.
Trois valeurs interviennent, et c’est la plus basse qui l’emporte :
upload_max_filesize— la taille maximale d’un fichier envoyé.post_max_size— la taille maximale de l’ensemble de la requête. Elle doit être supérieure ou égale à la précédente, sinon elle la plafonne silencieusement.memory_limit— la mémoire allouée à PHP. Elle doit être au moins égale àpost_max_size, faute de quoi le traitement de l’image échouera même si l’envoi aboutit.
Une configuration cohérente pour un site courant : 64 Mo, 64 Mo et 256 Mo. Relever une seule des trois valeurs ne change généralement rien, et c’est la première source de frustration sur ce sujet.
La méthode qui ne fonctionne pas
De très nombreux tutoriels recommandent d’ajouter ces lignes dans wp-config.php :
@ini_set( 'upload_max_filesize', '64M' ); @ini_set( 'post_max_size', '64M' );Cela ne marche pas, et pas par hasard. Ces deux directives appartiennent à une catégorie de réglages PHP qui ne peut être modifiée qu’au niveau du serveur ou d’un répertoire, jamais depuis un script en cours d’exécution. Au moment où WordPress lit wp-config.php, la requête d’envoi est déjà encadrée par les valeurs du serveur : il est trop tard.
L’arobase placée devant ini_set masque en plus l’avertissement, ce qui donne l’illusion que la ligne a fonctionné. Vous pouvez la laisser en place des mois sans jamais comprendre pourquoi la limite ne bouge pas. Passez directement aux méthodes qui agissent réellement.
Une nuance : memory_limit, elle, est modifiable à l’exécution. C’est pourquoi define( 'WP_MEMORY_LIMIT', '256M' ); dans wp-config.php a bien un effet — mais sur la mémoire seulement, pas sur la taille des fichiers.
Méthode 1 — Le panneau de votre hébergeur
C’est la bonne méthode dans neuf cas sur dix, et la plus rapide. La quasi-totalité des hébergeurs français propose une interface de configuration PHP, souvent nommée « Version de PHP », « Sélecteur PHP » ou « Options PHP », où les trois valeurs se modifient dans des menus déroulants.
Le changement est immédiat et survit aux mises à jour de WordPress, ce qui n’est le cas d’aucune modification de fichier. Commencez toujours par là : si l’option existe, les méthodes suivantes deviennent inutiles.
Méthode 2 — Le fichier .user.ini
Sur les hébergements modernes, qui font tourner PHP en mode FPM ou CGI, ce fichier est la voie officielle. Créez à la racine du site, à côté de wp-config.php, un fichier nommé .user.ini contenant :
upload_max_filesize = 64M post_max_size = 64M memory_limit = 256M max_execution_time = 300Un détail qui fait perdre beaucoup de temps : PHP met ce fichier en cache pendant cinq minutes par défaut. Si rien ne change immédiatement, ce n’est pas nécessairement un échec — attendez et rechargez la page Santé du site avant de conclure.
Méthode 3 — Le fichier .htaccess
Réservée aux serveurs Apache avec PHP en module. Ajoutez à la fin du .htaccess, à la racine du site :
php_value upload_max_filesize 64M php_value post_max_size 64M php_value memory_limit 256MAttention : sur un serveur qui n’accepte pas ces directives — LiteSpeed dans certaines configurations, ou PHP en FPM — ces lignes provoquent une erreur 500 et rendent le site inaccessible. Gardez une copie du fichier avant modification, et testez le site immédiatement après. Si l’erreur survient, retirez les lignes et utilisez la méthode 2.
Cas particulier — Le réseau multisite
Sur une installation multisite, WordPress ajoute sa propre limite, indépendante de PHP et souvent oubliée. Dans l’administration du réseau, à la section des réglages, un champ « Taille maximale de fichier à téléverser » exprimé en kilooctets plafonne tous les sites du réseau.
Vous pouvez relever les valeurs PHP autant que vous voulez : tant que ce champ n’est pas modifié, la limite ne bougera pas. C’est le grand classique du multisite, et il fait perdre des heures à ceux qui l’ignorent.
Faut-il vraiment augmenter cette limite ?
La question mérite d’être posée avant de toucher à la configuration. Si vous cherchez à envoyer une photo de 15 Mo sortie d’un appareil, le problème n’est pas la limite : c’est l’image. Une photo destinée au web ne devrait pratiquement jamais dépasser 300 Ko une fois redimensionnée et compressée. Envoyer l’originale ralentira vos pages et pénalisera votre référencement.
Les besoins légitimes d’une limite élevée sont plus rares qu’on ne le croit : import d’un thème premium, restauration d’une sauvegarde, envoi d’un fichier vidéo ou d’un document volumineux. Pour les vidéos, la bonne pratique reste d’ailleurs l’hébergement externe, qui évite de faire porter la bande passante à votre serveur.
Questions fréquentes
Pourquoi mon envoi échoue-t-il alors que le fichier est sous la limite ?
Deux explications. Le temps d’exécution peut être dépassé avant la fin de l’envoi, sur une connexion lente : c’est max_execution_time qu’il faut alors relever. Ou la mémoire manque pour générer les miniatures après réception, ce qui se produit avec des images de très grande dimension en pixels, indépendamment de leur poids en mégaoctets. Une image de 8000 pixels de large peut échouer alors qu’elle ne pèse que 2 Mo.
Mes modifications ont-elles un effet immédiat ?
Cela dépend de la méthode. Le panneau de l’hébergeur et le .htaccess agissent immédiatement. Le fichier .user.ini est mis en cache par PHP, généralement cinq minutes. Vérifiez toujours le résultat dans Outils > Santé du site > Informations > Serveur plutôt que dans la médiathèque, qui peut afficher une valeur enregistrée précédemment.
Une extension peut-elle faire le travail ?
Certaines le proposent, mais elles se heurtent exactement à la même limite technique : elles ne peuvent pas modifier une directive verrouillée au niveau du serveur. Au mieux, elles affichent vos valeurs actuelles, ce qui est informatif mais que la page Santé du site fait déjà. Installer une extension pour cela ajoute une dépendance sans résoudre le problème.
Mon hébergeur refuse d’augmenter la limite, que faire ?
C’est le signe d’une offre mutualisée très contrainte. Contournements possibles : envoyer le fichier par FTP dans wp-content/uploads puis l’importer avec une extension qui scanne la médiathèque, ou compresser l’image avant envoi. Si le refus concerne aussi la mémoire et le temps d’exécution, le sujet dépasse cette seule limite : votre hébergement est trop juste pour un usage WordPress normal.
Une limite élevée présente-t-elle un risque ?
Un risque modéré mais réel. Une limite très haute facilite l’envoi de fichiers volumineux par tout compte autorisé à publier, ce qui pèse sur l’espace disque et peut être exploité si un compte est compromis. Sur un site à plusieurs contributeurs, restez raisonnable : 64 Mo couvrent la quasi-totalité des besoins légitimes, et relever ponctuellement pour une restauration est préférable à laisser 512 Mo en permanence.
Que se passe-t-il si post_max_size est inférieur à upload_max_filesize ?
C’est la seconde valeur qui plafonne, sans le moindre message explicite. Vous pouvez afficher une limite de 128 Mo dans la médiathèque et voir échouer un fichier de 20 Mo si post_max_size est resté à 16 Mo. Vérifiez toujours les trois valeurs ensemble : c’est précisément ce désalignement qui explique la majorité des cas où « rien ne change ».