Comment augmenter la taille maximale des fichiers téléversés dans WordPress

Vous glissez une vidéo de 60 Mo dans la médiathèque WordPress, attendez quelques secondes, et obtenez en retour l'un des trois messages d'erreur : « The uploaded file exceeds the upload_max_filesize directive in php.ini », « 413 Request Entity Too Large », ou simplement « HTTP error » sans plus d'explications. La solution consiste presque toujours à augmenter la taille maximale de téléversement, mais comme pour la plupart des sujets de limites WordPress, il n'existe pas qu'une seule limite. Il y en a quatre, elles vivent à des endroits différents, et la plus basse l'emporte. Ce guide explique quelle limite cause quel message d'erreur et comment relever chacune d'entre elles sur les diverses configurations d'hébergeurs.

Quelle limite est responsable de quelle erreur ?

Quatre paramètres distincts peuvent bloquer un téléversement. Savoir lequel vous a piégé évite beaucoup d'essais et d'erreurs.

PHP upload_max_filesize. Le plafond strict sur la taille d'un seul fichier téléversé. Par défaut sur la plupart des hébergeurs, c'est 2M à 64M. Si votre fichier dépasse cette valeur, WordPress affiche le message explicite « uploaded file exceeds the upload_max_filesize directive ».
PHP post_max_size. La taille maximale de la requête POST entière, incluant le fichier plus tous les autres champs de formulaire. Doit être au moins aussi grande que upload_max_filesize ; sinon le téléversement échoue silencieusement avant même que WordPress ne le voie. La valeur par défaut est typiquement de 8M à 64M.
PHP max_execution_time et max_input_time. Limites de temps en secondes. Un gros téléversement sur une connexion lente peut atteindre la limite de temps avant la fin du transfert du fichier, même si les limites de taille sont correctes. La valeur par défaut est généralement de 30 à 60 secondes. Symptôme : le téléversement démarre, la barre de progression atteint 80 %, puis échoue avec « HTTP error ».
Limite de corps de requête du serveur web. nginx a une directive client_max_body_size (par défaut 1M, douloureusement basse pour les téléversements de médias). Apache ne plafonne rarement par défaut, mais les proxys inverses, les répartiteurs de charge et les CDN (Cloudflare, en particulier, a un plafond de 100M sur les forfaits gratuits, 200M sur Pro, 500M sur Business) imposent tous leurs propres plafonds. Symptôme : une page « 413 Request Entity Too Large » qui ne ressemble pas du tout à WordPress, parce que WordPress n'a jamais reçu la requête.

La taille maximale réelle de téléversement est la plus basse des quatre. WordPress affiche la limite effective sur la page de téléversement elle-même : ouvrez Médias, Ajouter dans l'administration et cherchez la petite ligne « Taille maximale de fichier téléversable » sous la zone de téléversement.

De combien avez-vous réellement besoin ?

Un modèle mental pratique :

32M. Suffisant pour les images typiques, les PDF et les petits fichiers audio. Valeur par défaut sur les hébergeurs mutualisés conservateurs.
64M. Confortable pour la plupart des sites éditoriaux. Gère les rafales de photos d'un appareil moderne, les PDF plus volumineux et les courts clips vidéo.
128M à 256M. La bonne plage pour les sites qui téléversent régulièrement de la vidéo, de gros fichiers PSD, des ressources graphiques, ou des fichiers zip de thèmes et d'extensions pour une installation auto-gérée.
Au-delà de 256M. Surtout pertinent pour les sites riches en vidéo, les flux de podcasts avec de gros fichiers audio, ou les plateformes de cours avec du matériel de cours téléchargeable. Il vaut la peine de se demander si le fichier doit réellement vivre sur le serveur WordPress, ou si un service comme Vimeo, YouTube, Bunny Stream ou un bucket S3 dédié serait mieux adapté. WordPress n'est pas optimisé pour servir de gros fichiers médias à grande échelle.

Un détail que les gens ratent : WordPress a aussi son propre plafond interne. Par défaut, il n'impose pas de limite de taille au-delà de ce que PHP autorise, donc sur la plupart des hébergeurs, les paramètres PHP sont la seule chose en jeu. Le filtre upload_size_limit existe si vous voulez définir un plafond spécifique au projet (utile en multisite pour donner à différents rôles différentes limites), mais il ne peut qu'abaisser la limite effective, jamais la relever au-delà de PHP.

Option 1 : augmenter les limites PHP via le panneau de votre hébergeur

C'est presque toujours le bon point de départ. La plupart des hébergeurs en 2026 exposent les paramètres pertinents dans leur tableau de bord, et les modifications prennent effet en quelques secondes.

cPanel (IONOS, Hostinger, de nombreux revendeurs)

Allez dans MultiPHP INI Editor, sélectionnez votre domaine, et ajustez :

upload_max_filesize à votre valeur cible (par exemple 128M)
post_max_size à la même valeur ou supérieure (par exemple 128M)
max_execution_time à au moins 300 secondes pour les gros fichiers
max_input_time à la même valeur
memory_limit à 256M ou plus (les téléversements se chargent brièvement en mémoire pendant le traitement)

Enregistrez. La modification est active immédiatement.

Plesk (All Inkl, DomainFactory, de nombreux hébergeurs allemands)

Ouvrez le domaine dans Plesk, cliquez sur PHP Settings, faites défiler jusqu'à « Performance and security settings ». Les champs sont les mêmes que pour cPanel. Enregistrez et les valeurs s'appliquent à la requête suivante.

Hébergement WordPress infogéré (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Ces hébergeurs sont presque toujours livrés avec des valeurs par défaut raisonnables (typiquement 64M à 128M). Si la limite est encore trop basse pour votre cas d'usage, le tableau de bord propose généralement un curseur ou un champ de saisie. Quelques hébergeurs (WP Engine, Pressable) plafonnent le maximum absolu et exigent un ticket de support au-delà d'une certaine taille, généralement parce que leur pipeline de téléversement pré-valide les fichiers contre un CDN. Ces tickets reçoivent une réponse en quelques heures, pas en jours.

Option 2 : .user.ini à la racine de WordPress

Si votre hébergeur exécute PHP via FastCGI ou PHP FPM (ce qui est essentiellement le cas de tout hébergeur moderne), mais n'expose pas de panneau de paramètres, vous pouvez déposer un fichier .user.ini directement à la racine de WordPress :

upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

PHP récupère .user.ini automatiquement. La seule particularité est un temps de cache par défaut de cinq minutes (contrôlé par le paramètre user_ini.cache_ttl), donc les modifications ne prennent pas toujours effet à la requête suivante immédiate.

Vérifiez avec la page Santé du site WordPress : Outils, Santé du site, Info, Serveur affiche les upload_max_filesize et post_max_size actifs. Si les valeurs correspondent toujours aux anciennes valeurs par défaut après dix minutes, l'hébergeur désactive la prise en charge de .user.ini ou exécute PHP dans un mode qui l'ignore. Continuez avec l'Option 3.

Option 3 : php.ini sur un serveur auto-géré

Sur un VPS ou un serveur dédié où vous contrôlez PHP directement, modifiez le php.ini actif. Trouvez-le avec php --ini en ligne de commande. Le chemin varie selon la distribution et la version de PHP (typiquement /etc/php/8.2/fpm/php.ini sur Debian ou Ubuntu, /etc/php.ini sur CentOS ou RHEL).

Ajustez les mêmes cinq valeurs que dans l'Option 1, puis rechargez PHP FPM :

sudo systemctl reload php8.2-fpm

(Ajustez le numéro de version pour correspondre à votre installation.) Sur Apache avec mod_php, redémarrez plutôt Apache. La modification s'applique immédiatement, aucune autre action nécessaire.

Option 4 : nginx client_max_body_size

C'est celui qui piège beaucoup de gens sur du nginx auto-géré. PHP peut être configuré pour accepter des téléversements de 1 Go, mais si nginx est toujours plafonné à 1M (la valeur par défaut), le téléversement n'atteint jamais PHP. Le navigateur affiche une erreur générique « 413 Request Entity Too Large », souvent sans aucune indication que nginx en est responsable.

Ajoutez la directive au bloc server de votre site, ou globalement dans le bloc http de nginx.conf :

client_max_body_size 128M;

Rechargez nginx avec sudo nginx -t && sudo systemctl reload nginx. La valeur doit correspondre ou dépasser votre post_max_size PHP. Il n'y a aucun mal à la régler légèrement plus haut ; la limite réelle reste PHP.

Option 5 : Apache avec .htaccess (héritage)

Sur des configurations Apache plus anciennes exécutant mod_php (rares sur l'hébergement moderne, courantes sur les serveurs hérités), vous pouvez placer les directives PHP directement dans .htaccess à la racine de WordPress :

php_value upload_max_filesize 128M
php_value post_max_size 128M
php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M

Si votre hébergeur exécute PHP via FastCGI ou PHP FPM (ce qui est essentiellement le cas de tout hébergeur moderne), cette directive lance une erreur 500 ou est silencieusement ignorée. Utilisez plutôt .user.ini de l'Option 2.

Option 6 : quand la limite est au niveau du CDN ou du proxy

Si vous avez configuré PHP et le serveur web pour autoriser des téléversements de 256M, mais que le téléversement échoue toujours à, disons, 100M, le goulot d'étranglement est quelque part en amont du serveur WordPress. Coupables courants :

Cloudflare plafonne la taille du corps par forfait : 100M en Free, 200M en Pro, 500M en Business, 500M en Enterprise (relevé sur demande). Pour des téléversements plus importants, soit passez à un forfait supérieur, soit excluez l'administration WordPress du proxy en réglant l'enregistrement DNS sur « DNS only » pour /wp-admin/ via une Page Rule, soit utilisez un sous-domaine direct qui contourne Cloudflare pour les téléversements.
Cloudways a une couche varnish qui a par défaut une limite de taille de corps faible. Leur tableau de bord expose le paramètre sous « Application Settings, Server Configurations ».
Les proxys inverses configurés devant nginx (HAProxy, Traefik) ont tous leurs propres limites de taille de corps qui doivent être augmentées dans leurs fichiers de configuration respectifs.
Certains pare-feu et extensions de sécurité au niveau WAF (Sucuri, Wordfence Premium avec WAF cloud) plafonnent les tailles de téléversement par défaut. Leur panneau de paramètres a une option distincte pour cela.

L'astuce de diagnostic : essayez le téléversement depuis l'intérieur du serveur lui-même en utilisant curl avec un fichier local. Si le téléversement fonctionne localement mais échoue via l'URL publique, la limite est sur une couche proxy ou CDN, pas dans PHP.

Comment vérifier que les nouvelles limites sont actives

Ouvrez Outils, Santé du site, Info dans l'administration WordPress.
Développez la section Serveur. Cherchez upload_max_filesize, post_max_size, max_execution_time et memory_limit. Ils devraient tous refléter les nouvelles valeurs.
Pour une vérification plus rapide, ouvrez Médias, Ajouter. La ligne « Taille maximale de fichier téléversable » au bas de la zone de téléversement doit afficher la nouvelle limite effective.
Essayez le téléversement réel qui a déclenché le problème. S'il échoue toujours, notez exactement quel message d'erreur vous obtenez ; cela indique laquelle des quatre limites est encore trop basse.

Que faire lorsque le fichier est réellement trop volumineux pour un téléversement HTTP

Au-delà de 500M à 1 Go, les téléversements via le navigateur cessent d'être pratiques quels que soient les paramètres du serveur. La connexion TCP devient instable, les proxys intermédiaires expirent, et un seul hoquet réseau signifie tout recommencer. Deux alternatives plus saines :

Téléverser via SFTP et importer via WordPress. Placez le fichier directement dans wp-content/uploads/ANNEE/MOIS/ via SFTP, puis utilisez une extension comme Add From Server ou Media Sync pour l'enregistrer dans la médiathèque. WordPress génère les métadonnées et les vignettes comme si vous l'aviez téléversé normalement.
Services médias externes. Pour la vidéo en particulier, Vimeo, Bunny Stream, Cloudflare Stream et YouTube gèrent tous l'hébergement et le streaming adaptatif bien mieux que le cœur de WordPress. La plupart des thèmes et page builders modernes les intègrent nativement, y compris les vignettes générées automatiquement. Même logique pour l'audio (Soundcloud, Spotify for podcasters) et les téléchargements de fichiers volumineux (S3 avec un CloudFront ou un Bunny CDN devant).

Héberger une vidéo brute de 5 Go sur un hébergement WordPress mutualisé et la servir directement est techniquement possible mais rarement la bonne décision. Les coûts de bande passante, l'absence de débit binaire adaptatif et la pression sur un seul worker PHP par spectateur simultané pointent tous vers un hébergement média dédié.

Erreurs courantes à éviter

Augmenter upload_max_filesize sans augmenter post_max_size en même temps. Le téléversement échoue silencieusement parce que la requête POST entière dépasse la plus basse des deux. Modifiez-les toujours ensemble.
Définir des valeurs absurdement élevées « par sécurité ». Une limite de téléversement de 4G sur un serveur avec 4 Go de RAM totale est un vecteur de déni de service. PHP charge des parties du téléversement en mémoire pendant le traitement. Choisissez une valeur qui reflète ce que vous téléversez réellement, plus une marge.
Oublier max_execution_time. Un téléversement de 500 Mo sur une connexion à 10 Mbit/s prend environ sept minutes. Si max_execution_time est à la valeur par défaut de 30 secondes, la requête est tuée en plein téléversement quelles que soient les limites de taille.
Modifier le mauvais php.ini. Erreur courante sur les systèmes avec plusieurs versions de PHP installées (par exemple 7.4 et 8.2 toutes deux présentes, mais une seule active). La commande php --ini en ligne de commande peut pointer vers un php.ini différent de celui que PHP FPM utilise pour le serveur web. Santé du site est la source faisant autorité.

Pour la plupart des cas, deux minutes dans le panneau de l'hébergeur pour augmenter cinq valeurs à des valeurs par défaut raisonnables résolvent le problème de manière permanente. Les messages d'erreur autour des limites de taille de téléversement sont malheureusement formulés de manière à ressembler à des problèmes techniques obscurs, mais le vrai correctif est mécanique et bien documenté. Une fois les limites dimensionnées à votre charge de travail réelle, c'est l'un des sujets WordPress qui n'a plus besoin de revenir.