Pourquoi WordPress demande-t-il soudain un nom d’utilisateur et un mot de passe FTP avant d’installer une simple mise à jour, alors qu’aucune configuration FTP n’a jamais été renseignée sur ce site ? Cette question revient régulièrement chez les administrateurs qui découvrent ce formulaire inattendu, souvent après un changement de configuration serveur ou une restauration de sauvegarde qui a modifié la propriété des fichiers.
Ce comportement provient de l’API Filesystem de WordPress, une couche d’abstraction qui gère les opérations d’écriture sur le système de fichiers, que ce soit pour installer une extension, mettre à jour le cœur ou modifier un thème. Cette API choisit automatiquement, à chaque opération, la méthode d’accès la plus appropriée selon ce qu’elle détecte sur le serveur, et bascule vers le mode FTP direct quand ses vérifications échouent.
Ce que l’API Filesystem vérifie avant chaque écriture
Avant toute opération d’écriture sur le système de fichiers, WordPress tente de déterminer si le processus PHP en cours d’exécution peut écrire directement dans les répertoires concernés sans passer par un protocole intermédiaire. Cette vérification passe par la fonction request_filesystem_credentials(), qui elle-même s’appuie sur un test de propriété effectif : WordPress crée un fichier temporaire et vérifie si son propriétaire correspond à l’utilisateur système sous lequel PHP s’exécute.
Si ce test réussit, WordPress opte pour la méthode direct, la plus simple, qui écrit directement sur le disque sans couche intermédiaire. Si le test échoue, WordPress considère qu’un accès direct risquerait de créer des fichiers avec une propriété incohérente par rapport au reste de l’installation, et propose alors le formulaire d’identifiants FTP, SSH ou SFTP comme méthode de repli plus prudente.
La condition précise qui déclenche la bascule
Le déclencheur le plus fréquent est un décalage entre l’utilisateur sous lequel le serveur web ou le pool PHP-FPM s’exécute, souvent www-data sur une distribution Debian ou Ubuntu, et le propriétaire réel des fichiers WordPress sur le disque, qui peut être un utilisateur différent si les fichiers ont été déposés via un compte FTP distinct ou restaurés depuis une sauvegarde effectuée sous un autre compte système.
ls -la /var/www/monsite/wp-content/
stat -c '%U:%G' /var/www/monsite/wp-content/plugins
Si cette vérification révèle que les fichiers appartiennent à un utilisateur différent de celui qui exécute PHP-FPM, la condition qui déclenche le mode FTP direct est confirmée. C’est un cas fréquent après une restauration de sauvegarde réalisée par un script qui recrée les fichiers sous l’utilisateur root ou sous un compte de sauvegarde dédié, sans rétablir ensuite la propriété attendue par WordPress.
Corriger la propriété des fichiers plutôt que subir le formulaire FTP
La correction la plus directe consiste à aligner la propriété des fichiers sur l’utilisateur qui exécute réellement PHP-FPM pour ce site, ce qui rétablit les conditions d’un accès direct sans passer par le formulaire d’identifiants :
chown -R www-data:www-data /var/www/monsite/wp-content/
Sur un hébergement où chaque site tourne sous un utilisateur système distinct plutôt que sous l’utilisateur générique du serveur web, cette commande doit évidemment cibler l’utilisateur propre à ce site précis, celui associé au pool PHP-FPM concerné, et non un utilisateur générique partagé qui romprait l’isolation entre sites.
Le rôle de la constante FS_METHOD en dernier recours
Quand la correction de propriété n’est pas envisageable, par exemple sur un hébergement mutualisé où l’administrateur ne contrôle pas l’utilisateur système du pool PHP, la constante FS_METHOD définie dans wp-config.php permet de forcer explicitement la méthode souhaitée, en contournant la détection automatique :
define('FS_METHOD', 'direct');
Cette constante force WordPress à toujours utiliser la méthode indiquée sans procéder à son test habituel. Elle ne corrige pas la cause du décalage de propriété, mais elle supprime l’affichage récurrent du formulaire d’identifiants, au prix d’un risque de fichiers créés avec une propriété incohérente si le décalage initial n’a pas été traité en amont.
- WordPress teste la propriété d’un fichier temporaire avant chaque écriture
- Un décalage entre utilisateur PHP et propriétaire des fichiers déclenche le mode FTP
- Corriger la propriété via
chownrétablit un accès direct durable - La constante
FS_METHODforce une méthode sans corriger la cause
Sur les restaurations de sauvegarde que nous traitons, vérifier la propriété du répertoire
wp-contentfait désormais partie systématique de la checklist, avant même de relancer le site en production.
En résumé
La bascule de WordPress vers le mode FTP direct n’est pas un bug mais une mesure de prudence, déclenchée par un test de propriété qui échoue lorsque l’utilisateur PHP et le propriétaire des fichiers diffèrent. Corriger cette propriété avec chown rétablit un fonctionnement direct et durable, la constante FS_METHOD restant un contournement utile uniquement quand cette correction n’est pas possible, sans remplacer la configuration d’un client FTP proprement dite.
