Le fichier téléchargé n’a pas pu être déplacé vers wp-content/uploads : 8 solutions

Tu téléverses une image, un PDF ou un autre fichier dans la bibliothèque de médias WordPress et l’opération se termine par exactement ce message. Cela signifie : WordPress a accepté le fichier temporairement stocké, mais n’a pas pu le déplacer vers le dossier de destination final.

Teste d’abord un deuxième petit fichier JPG ou PNG. Vérifie ensuite l’état du site, l’espace libre et les inodes, le chemin de téléchargement configuré, les permissions et le propriétaire ainsi que le répertoire temporaire PHP. Le chemin chiffré n’est pas fixe : selon le mois il peut par exemple wp-content/uploads/2026/01, 2026/02, 2026/04 ou 2025/12 figurer. Dans ce guide nous utilisons donc /YYYY/MM.

Le message provient du traitement des téléchargements de WordPress. WordPress vérifie d’abord le statut du téléchargement, la taille et le type de fichier. Ensuite, wp_upload_dir() détermine la destination et tente de déplacer le fichier PHP temporaire vers celle-ci. Si cette dernière étape échoue, le message « The uploaded file could not be moved to … » apparaît. Cela peut être consulté dans le noyau WordPress chargé du traitement des uploads.

Une erreur de permissions de fichier lors de l’upload WordPress est une cause fréquente, mais pas la seule. Un compte d’hébergement plein, des inodes épuisés, une propriété incorrecte ou un répertoire temporaire inaccessible aboutissent pour WordPress au même résultat : le fichier cible ne peut pas être écrit.

1. Tester un autre petit fichier : Téléverse un JPG ou PNG connu de quelques kilo-octets. S’il fonctionne, vérifie séparément le type de fichier, le nom du fichier et la limite de taille du fichier initial.
2. Vérifier WordPress Site Health : Ouvre Outils > État de santé du site > Infos > Permissions du système de fichiers. L’entrée « The uploads directory » doit indiquer « Writable ». Cette section est présente dans les versions récentes de WordPress.
3. Vérifier l’espace disque et les inodes : Un gigaoctet libre ne sert à rien si le quota d’inodes est déjà atteint.
4. Contrôler le chemin de téléchargement : Vérifie si WordPress utilise réellement wp-content/uploads/YYYY/MM ou si une ancienne configuration spéciale est active.
5. Comparer permissions et propriétaire : Vérifie le dossier principal et le dossier année/mois actuel.
6. Vérifier le répertoire temporaire PHP : upload_tmp_dir doit être accessible et inscriptible par le processus PHP.
7. Contacter le support hébergement : Indique le chemin exact et un moment précis pour que l’hébergeur puisse vérifier les logs PHP et du serveur web appropriés.

Commence ici car cette cause peut être exclue sans modifier de fichiers ni de configuration. Un compte d’hébergement peut avoir atteint son disk quota même si le fichier uploadé est petit. Lors de l’upload, des miniatures sont souvent créées en plus du fichier original. De plus, caches, sauvegardes, logs et mises à jour occupent de la place.

Un inode représente simplement une entrée du système de fichiers. Si l’hébergement indique encore de l’espace libre mais pas d’inodes disponibles, PHP ne peut pas créer de nouveau fichier. Ne supprime rien à l’aveugle. Vérifie d’abord si d’anciennes sauvegardes, des fichiers de cache ou des copies de staging expliquent la consommation, et utilise le nettoyage prévu par ton hébergeur ou ton plugin.

Sur une multisite WordPress, une limite supplémentaire peut s’appliquer : le quota d’upload d’un site individuel peut être atteint alors que le serveur a encore de la place. Vérifie en tant qu’administrateur réseau la limite de stockage du site concerné.

En SSH, ces commandes en lecture seule sont utiles :

df -h
df -i

df -h montre l’espace disque utilisé, df -i l’utilisation des inodes. Sur un hébergement géré, le compte peut avoir une quote supplémentaire qui ne reflète pas totalement ces valeurs serveur. Dans ce cas, l’affichage de l’hébergeur est décisif.

Le chemin standard est wp-content/uploads. Si l’option d’organisation par année et mois est activée, WordPress ajoute le dossier de date. La structure ressemble alors à :

wp-content/
└── uploads/
    └── YYYY/
        └── MM/
            └── ton-fichier.jpg

Contrôle via SFTP, FTP ou le gestionnaire de fichiers de l’hébergement si uploads, le dossier d’année et le dossier du mois en cours existent. L’absence d’un dossier mois n’est pas automatiquement une erreur : WordPress essaie de le créer lui-même. S’il ne peut pas, c’est souvent que le dossier parent n’est pas inscriptible ou est mal assigné.

WordPress prend aussi en compte en interne l’ancienne option upload_path. La constante UPLOADS dans wp-config.php peut écraser ce chemin. La documentation officielle de wp_upload_dir() décrit cet ordre. Cherche une configuration spéciale seulement si l’erreur indique un chemin inattendu ou si le site a été migré. Ne change pas le chemin sans raison.

Le dossier de date lui‑même n’est pas un problème. Si tu veux volontairement supprimer les années et mois des URL médias existantes, c’est une guide séparé pour déplacer les uploads WordPress hors des dossiers datés. Pour l’erreur actuelle, il faut d’abord rétablir la possibilité d’écriture.

Ouvre dans ton client SFTP ou ton gestionnaire de fichiers les propriétés du répertoire concerné. 755 pour les répertoires et 644 pour les fichiers sont des valeurs de départ pertinentes sur de nombreux hébergements Linux. Elles ne sont pas une règle universelle. Certains environnements d'hébergement utilisent des droits de groupe, des ACL ou un mode d'exécution PHP différent.

Vérifie les permissions du chemin de l'extérieur vers l'intérieur : wp-content, uploads, YYYY et MM. Le processus PHP a besoin d'un accès en écriture au répertoire cible et d'un accès aux dossiers parents. La documentation officielle de WordPress sur les permissions de fichiers explique les droits du propriétaire, du groupe et du public.

Si tu maîtrises SSH de manière sûre, cette commande affiche les valeurs actuelles sans les modifier :

ls -ld wp-content wp-content/uploads wp-content/uploads/YYYY wp-content/uploads/YYYY/MM

Modifie les permissions uniquement pour le chemin clairement affecté et conformément aux indications de ton hébergeur. Un chmod récursif sur l'ensemble de l'installation WordPress n'est pas nécessaire pour ce dépannage.

Permissions déterminent ce que propriétaire, groupe et autres peuvent faire. Ownership détermine quel utilisateur et quel groupe sont propriétaires. C'est pourquoi chmod 755 peut sembler correct et que l'upload échoue quand même.

Ce schéma apparaît souvent après une migration manuelle, une restauration en tant que root, un déploiement par SSH ou la copie de fichiers entre comptes d'hébergement. Le dossier appartient alors par exemple à l'utilisateur SSH tandis que PHP s'exécute sous un autre compte ou dans un autre groupe.

Compare le propriétaire et le groupe de wp-content/uploads avec un dossier dans lequel WordPress peut écrire sans problème. N'exécute pas un chownExécute la commande tant que tu ne connais pas l'utilisateur d'hébergement correct. Sur un hébergement mutualisé, le support est généralement le seul à pouvoir corriger de manière fiable l'attribution. Envoie-lui le chemin cible et demande-lui explicitement de vérifier owner, group et ACLs pour le processus PHP/serveur web.

Un téléversement depuis le navigateur atterrit d'abord dans un dossier temporaire du serveur. Ce n'est qu'ensuite que WordPress déplace le fichier vers la médiathèque. le paramètre PHP upload_tmp_dir peut définir un dossier spécifique. Si ce dossier est absent, plein ou que PHP ne peut pas le lire et l'écrire, une erreur WordPress temporary folder upload se produit.

De plus, open_basedir peut restreindre l'accès. Le dossier temporaire et le dossier final de téléversement doivent se trouver dans les chemins autorisés pour le site. Sur un hébergement géré ou mutualisé, tu devrais vérifier ces valeurs dans la zone PHP-Info du fournisseur ou contacter le support. Modifie php.ini ou .user.ini uniquement si le fournisseur documente cette méthode. Un fichier aléatoire provenant d'un tutoriel peut endommager les paramètres PHP pour tout le site.

Avec SSH ces commandes donnent des indications, sachant que la configuration PHP en ligne de commande peut différer de la version PHP utilisée par le web :

php --ini
php -i | grep -E 'upload_tmp_dir|open_basedir'

Si Site Health signale que le dossier de téléversement est inscriptible, que l'espace et les inodes sont libres et que malgré tout chaque petit fichier échoue, cette vérification vaut particulièrement la peine.

Cette solution n'a de sens que si le dossier YYYY/MMest manquant, vide ou a clairement été créé avec une mauvaise propriété. Ne supprime jamais un dossier mensuel contenant des fichiers médias existants.

1. Fais une sauvegarde complète de wp-content/uploads et de la base de données.
2. Vérifie si des fichiers se trouvent dans le dossier du mois concerné. S'il y a des fichiers, répare les droits et le propriétaire au lieu de recréer le dossier.
3. Crée seulement un dossier manquant via SFTP ou le gestionnaire de fichiers, par exemple d'abord YYYY et dedans MM.
4. Récupère les droits, le propriétaire et le groupe depuis un dossier de mois voisin fonctionnel du même compte d'hébergement.
5. Téléverse un petit fichier de test. Vérifie ensuite s'il apparaît dans la médiathèque et s'il est accessible via son URL.

Si un dossier vide est défectueux, renomme-le d'abord en backup avec l'aide de l'hébergeur au lieu de l'écraser immédiatement. Ainsi la modification reste réversible.

Les plugins de sécurité, un pare-feu d'application web, ModSecurity ou une règle d'hébergement peuvent bloquer les téléversements. C'est plus probable si seules certaines extensions, certains noms de fichiers ou certaines requêtes sont concernées. Une extension bloquée génère dans WordPress généralement un message différent du déplacement échoué. Traite-la donc comme une classe d'erreur distincte.

Teste un petit fichier JPG standard. S'il fonctionne, compare l'extension, le type MIME, le nom du fichier et la taille avec le fichier problématique. Vérifie les journaux d'événements ou de blocage de l'outil de sécurité en place. Ne désactive pas les plugins au hasard. Si un test temporaire est nécessaire, fais d'abord une sauvegarde, utilise une fenêtre de maintenance et désactive uniquement le composant de sécurité concerné.

Pour des erreurs répétables note l'instant précis en secondes. L'hébergeur pourra ainsi croiser précisément les logs WAF, ModSecurity, PHP et du serveur web.

Un message général comme « les téléversements ne fonctionnent pas » entraîne souvent des questions supplémentaires. Copie plutôt cette checklist et remplace les espaces réservés :

Joins l’extrait Site Health mais supprime les adresses IP publiques, les chemins serveur et autres informations dont le support n’a pas besoin. Chez un hébergeur sérieux ces données suffisent généralement pour distinguer quota, ownership et configuration PHP.

• Ne définis pas de permissions 777 permanentes. Elles rendent wp-content/uploads inutilement trop accessibles en écriture et masquent souvent une erreur d’ownership.
• Ne rends pas accessible l’ensemble de wp-content. Pour un upload média le chemin d’upload précis est pertinent.
• Ne modifie pas les fichiers core de WordPress. Le message d’erreur est un symptôme de la configuration du serveur ou des chemins.
• Ne colle pas de snippets aléatoires dans wp-config.php. Une nouvelle UPLOADSconstante peut créer un second mauvais chemin.
• Ne désactive pas d’abord tous les plugins. Mémoire, inodes, Site Health, chemin et propriétaire peuvent être vérifiés plus vite et avec moins de risques.
• Ne désactive pas le dossier par date pour contourner l’erreur. Un dossier parent non inscriptible reste non inscriptible.

WordPress peut organiser les uploads automatiquement par année et mois. C’est pourquoi le message indique le dossier cible actuel, par exemple wp-content/uploads/2026/04. Le mois suivant la valeur numérique change. Le diagnostic reste identique, aussi une seule instruction intemporelle avec /YYYY/MM suffit.

755 pour les répertoires et 644 pour les fichiers sont un bon point de départ sur de nombreux hébergements Linux. Mais les éléments décisifs sont le propriétaire, le groupe, les ACL et la manière dont PHP est exécuté. Si ton hébergeur documente d’autres valeurs, suis ses recommandations.

chmod modifie les permissions mais pas le propriétaire ni le groupe. Si PHP tourne sous un autre utilisateur, un quota plein ou bloqué open_basedir le chemin, le dossier reste inutilisable pour le processus effectif malgré 755.

Oui. Un quota d'inodes saturé ou une quota multisite peut empêcher WordPress de créer le fichier cible. Un fichier de 50 Ko peut ainsi échouer alors qu'il nécessite peu d'espace.

Normalement non. Un dépassement de upload_max_filesize ou post_max_size génère généralement son propre message. « Could not be moved » apparaît plus tard dans le processus, après que le fichier temporaire a déjà été accepté. Si seules les grosses fichiers échouent, tu devrais vérifier ces deux classes d'erreur.

Oui. WordPress tente de créer le chemin de téléversement nécessaire et, si la structure par date est activée, les dossiers année et mois. Si cela échoue, c'est souvent parce que le dossier parent n'est pas inscriptible ou qu'un chemin personnalisé est incorrect. Crée les dossiers manuellement uniquement si tu peux appliquer correctement droits et propriétaire.

Téléverse le même petit fichier de test après chaque modification. Ainsi tu sais quelle étape a résolu l'erreur. Vérifie ensuite le fichier dans la Media Library, ouvre son URL et contrôle si WordPress a généré les miniatures attendues.

Si le téléversement fonctionne de nouveau, tu peux nettoyer la médiathèque tranquillement. neo Rename aide à renommer et déplacer des médias et met à jour les références dans WordPress. Pour de grandes bibliothèques, neo Library complète la recherche et l'organisation, sans que tu aies à parcourir les dossiers serveur manuellement.

Sources : WordPress _wp_handle_upload(), WordPress wp_upload_dir() et WordPress File Permissions.