Vous avez déplacé votre site vers un hébergement et les extensions ne s’installent plus. Ou bien les fichiers média ne s’importent plus via l’administration. Ou encore une mise à jour du cœur échoue avec le message «Could not create directory.» Cela vous dit quelque chose?

La cause est presque toujours la même: des permissions incorrectes sur les fichiers et les dossiers. Un serveur local (OpenServer, MAMP) s’exécute sous l’utilisateur Windows/macOS courant et pardonne tout. Un hébergement Linux de production, non. Chaque fichier et chaque dossier possède un propriétaire et trois niveaux de permissions, et si le serveur web ne peut pas écrire dans le dossier requis, le site cesse de fonctionner, soit en silence, soit avec une erreur absconse.

Vous trouverez ci-dessous ce que signifient concrètement 755 et 644, comment les appliquer en une seule fois sur l’ensemble du site via FileZilla, et quels fichiers nécessitent un traitement particulier.

💡 Aperçu rapide:

• Ce que signifient les valeurs 755 et 644, et pourquoi 777 est une faille de sécurité
• Comment appliquer les permissions en masse via FileZilla en 2 passes: d’abord les dossiers, puis les fichiers
• Quelles permissions sont nécessaires pour wp-config.php, le .htaccess et le dossier wp-content
• Comment faire la même chose via SSH avec une seule commande en 5 secondes

Ce que signifient les permissions et pourquoi 777 est une catastrophe

Chaque fichier et dossier sur un serveur Linux stocke trois jeux de permissions: pour le propriétaire, pour le groupe et pour tous les autres. Le chiffre est une somme de bits: 4 (lecture) + 2 (écriture) + 1 (exécution, ce qui, pour les dossiers, signifie pouvoir y entrer).

755 pour les dossiers se décompose ainsi: le propriétaire peut tout faire (7), le groupe et les autres peuvent lire et entrer (5). Le dossier est accessible au serveur web pour le parcourir et y créer des fichiers et des sous-dossiers, mais personne d’extérieur ne peut le supprimer ni le renommer.

644 pour les fichiers: le propriétaire peut lire et écrire (6), les autres peuvent seulement lire (4). Les fichiers PHP sont exécutés par l’interpréteur, pas par le système, ils n’ont donc pas besoin du bit d’exécution.

777 (propriétaire+groupe+autres = tout) est une porte ouverte. N’importe quel processus sur le serveur, y compris les scripts de sites voisins sur un hébergement mutualisé, peut lire, modifier et supprimer vos fichiers. Selon les données 2025 de WPScan, les permissions incorrectes figurent parmi les cinq vecteurs d’attaque WordPress les plus courants en hébergement mutualisé. Ne mettez jamais 777. Si une extension ou un thème exige de telles permissions, c’est un signal d’alarme.

Quelles permissions WordPress considère comme correctes

La documentation officielle de WordPress définit les permissions recommandées comme suit:

Sur la plupart des hébergeurs, le propriétaire du système de fichiers correspond à l’utilisateur sous lequel PHP s’exécute (configuration suPHP/FastCGI + suEXEC). Dans cette configuration, les permissions 755/644 sont suffisantes: WordPress peut écrire dans wp-content/uploads, mettre à jour le cœur et les extensions, et installer des thèmes sans avoir besoin de passer à 777.

Vérifiez si cela s’applique à votre hébergeur: allez dans l’administration et essayez d’installer une extension gratuite quelconque. Si elle s’installe sans demander d’identifiants FTP, le schéma 755/644 fonctionne et les permissions sont déjà correctes.

Comment définir les permissions via FileZilla: étape par étape

FileZilla est un client FTP gratuit capable de modifier les permissions de manière récursive et en masse. Téléchargez-le depuis le site officiel si ce n’est pas déjà fait.

Étape 1: connectez-vous et allez à la racine de WordPress

Connectez-vous à votre hébergement via FTP (les identifiants sont les mêmes que ceux de votre compte d’hébergement, port 21). Dans le panneau de droite, naviguez jusqu’au dossier racine du site, là où se trouvent wp-config.php, wp-content, wp-admin et wp-includes.

Étape 2: appliquez 755 sur tous les dossiers

Sélectionnez tous les fichiers et dossiers à la racine (Ctrl+A). Clic droit → «Permissions du fichier».

Dans la boîte de dialogue qui s’ouvre, saisissez 755 dans le champ «Valeur numérique». Cochez la case «Appliquer récursivement aux sous-dossiers». Positionnez le bouton radio sur «Appliquer uniquement aux dossiers». Cliquez sur OK.

FileZilla va parcourir chaque dossier et sous-dossier du site et appliquer 755. Le processus prend de quelques secondes à deux minutes selon la taille du site.

Étape 3: appliquez 644 sur tous les fichiers

Sélectionnez de nouveau tout à la racine (Ctrl+A), clic droit → «Permissions du fichier».

Saisissez maintenant 644. Cochez «Appliquer récursivement aux sous-dossiers». Positionnez le bouton radio sur «Appliquer uniquement aux fichiers». OK.

Terminé. Deux passes (dossiers et fichiers) et l’ensemble du site est remis au standard.

Méthode rapide via SSH: la commande find

Si vous avez un accès SSH au serveur, la même opération tient en deux commandes et cinq secondes:

1
find /path/to/wordpress -type d -exec chmod 755 {} \;
2
find /path/to/wordpress -type f -exec chmod 644 {} \;

La première parcourt tous les dossiers (-type d) et applique 755. La seconde parcourt tous les fichiers (-type f) et applique 644. Remplacez /path/to/wordpress par le chemin réel de la racine de votre site (généralement /home/username/public_html).

Ensuite, renforcez séparément wp-config.php:

1
chmod 600 /path/to/wordpress/wp-config.php

Et .htaccess, si vous en avez un (serveur Apache):

1
chmod 644 /path/to/wordpress/.htaccess

Si votre site tourne sous Nginx, il n’y a pas de fichier .htaccess, vous pouvez donc sauter cette étape.

Que faire si les permissions sont réinitialisées

Situation: vous avez appliqué 755/644, tout fonctionnait, et une semaine plus tard vous retrouvez la même erreur. La cause est généralement un processus qui s’exécute sous un utilisateur différent.

Coupables typiques:

• Tâches cron de l’hébergement. Certains hébergeurs exécutent des scripts de maintenance en tant que root, et ceux-ci créent des fichiers avec des permissions que le serveur web ne peut plus modifier par la suite. Solution: demandez au support de configurer le cron pour qu’il s’exécute sous votre utilisateur.
• Extension de sauvegarde tierce. Elle écrit des dumps et des archives dans wp-content sous l’utilisateur avec lequel elle s’exécute. Vérifiez les journaux de l’extension. Si elle crée des fichiers sous un utilisateur différent du propriétaire du site, passez à une alternative.
• Extension de cache. Elle crée des dossiers de cache avec des permissions incorrectes. Allez dans les paramètres de l’extension et cherchez un bouton «Vider le cache» ou «Réinitialiser les permissions».

Solution rapide universelle: répétez la procédure de la section précédente (FileZilla en 2 passes ou les deux commandes find). Cela ne résoudra pas la cause racine mais remettra le site en état de marche.

⁉️🤔 Questions fréquentes

Que faire si le site tombe sur un «écran blanc de la mort» après avoir modifié les permissions?

Un écran blanc (WSOD) après un changement massif de permissions est extrêmement rare mais possible. Premièrement: activez WP_DEBUG dans wp-config.php pour voir le texte de l’erreur au lieu d’un écran blanc. Deuxièmement: vérifiez si vous n’avez pas accidentellement appliqué 644 sur les dossiers (les dossiers ont besoin du bit d’exécution, c’est-à-dire un 5 à la fin). Corrigez avec une commande find: find /path -type d -exec chmod 755 {} \;. Cela suffit dans la plupart des cas. Si le site ne fonctionne toujours pas, restaurez à partir d’une sauvegarde et modifiez les permissions progressivement: d’abord sur wp-content, puis sur la racine, en observant les réactions.

Puis-je définir les permissions via le gestionnaire de fichiers intégré de l’hébergement?

Oui, mais uniquement pour des fichiers et dossiers individuels. Les hébergements cPanel proposent un gestionnaire de fichiers avec «Modifier les permissions» dans le menu contextuel. En revanche, appliquer récursivement des permissions sur des centaines ou des milliers de fichiers via une interface web est pratiquement impossible. Pour les opérations de masse, utilisez FileZilla ou SSH.

Quelles permissions le dossier wp-content/uploads doit-il avoir?

Le standard 755, comme tous les autres dossiers. Si une extension ou un thème crée des sous-dossiers dans uploads et rencontre des problèmes, vérifiez le propriétaire du processus (il doit correspondre au propriétaire du dossier) plutôt que d’augmenter les permissions à 777. Parfois, le problème se résout en ajoutant define('FS_METHOD', 'direct'); dans wp-config.php.

Dois-je définir les permissions sur les fichiers à l’intérieur de wp-admin et wp-includes?

Oui, le standard 644 pour les fichiers et 755 pour les dossiers, comme pour le reste du site. La procédure FileZilla (tout sélectionner à la racine) les traite automatiquement.

Mon hébergeur exige 777 sur certains dossiers. Est-ce normal?

Non. Exiger 777 est le signe que PHP sur le serveur s’exécute sous un utilisateur différent du propriétaire des fichiers (par exemple, mod_php sans suEXEC). Dans cette configuration, WordPress ne peut pas écrire dans les dossiers sans un accès «monde». Options: passez à un hébergeur qui utilise suPHP/FastCGI (la plupart des hébergeurs modernes le font), ou ajoutez define('FS_METHOD', 'direct'); dans wp-config.php, ce qui suffit parfois.

Des permissions correctes sont un fondement, pas une option

Appliquer 755 sur les dossiers et 644 sur les fichiers ferme le canal le plus courant d’erreurs «mystérieuses» lors de la migration d’un site. Deux minutes dans FileZilla ou deux commandes SSH vous épargnent des heures à éplucher les journaux.

Si votre site est sur un bon hébergement avec suPHP/FastCGI, ces permissions suffisent pour tout: installer des extensions, importer des médias et effectuer les mises à jour automatiques du cœur. N’augmentez pas les permissions à 777, même si la documentation d’une vieille extension le demande. Et ajoutez wp-config.php comme élément séparé: chmod 600. Il contient le mot de passe de la base de données, et les tiers n’ont pas besoin d’y accéder.