WordPress sait vous donner beaucoup de confort, y compris quand il s’agit de modifier des fichiers directement depuis le tableau de bord. C’est pratique en dépannage, mais c’est aussi une porte d’entrée que vous ne voulez pas garder ouverte. L’option qui permet de modifier les thèmes et les fichiers du site depuis l’admin (dans Apparence ou via l’éditeur) représente un risque réel si un compte est compromis, si un plugin vulnérable est exploité, ou si une session reste active alors que quelqu’un a quitté l’ordinateur.
Désactiver l’édition de fichiers depuis l’interface d’administration fait partie des mesures “simples et efficaces” en matière de sécuriser site WordPress. Ce n’est pas une solution magique, mais c’est une réduction de surface d’attaque très nette. Et, surtout, elle évite un https://gardewp.fr/securite-wordpress/ scénario classique: une personne malveillante accède à l’administration, modifie un fichier sensible, puis persiste dans le temps en installant une modification difficile à repérer.
Le problème, en pratique
Le mécanisme est connu: WordPress propose un éditeur de fichiers. Si ce module est activé, un utilisateur autorisé peut modifier du PHP dans des fichiers comme ceux d’un thème. Même si vous limitez les rôles, la réalité est plus complexe. Tout ce qui permet à un attaquant d’obtenir un accès admin ou un accès “assez haut” peut aussi déboucher sur une modification de code.
Dans un contexte pro, on voit souvent des variations de ce risque:
- un compte administrateur partagé entre plusieurs personnes, parfois avec des habitudes de session douteuses; un accès “le temps d’un changement”, puis personne ne revient vérifier les paramètres; des rôles mal configurés sur un site multisite; des plugins qui ajoutent des pages internes, parfois mal sécurisées, qui servent de relais.
La désactivation de l’édition côté admin ne corrige pas une faille de plugin, ni une faiblesse de mot de passe. Elle réduit, par contre, la possibilité de transformer une intrusion en prise de contrôle du code, sans passer par vos mécanismes habituels (déploiement, contrôle de version, validation en revue).
Qu’est-ce qui est vraiment désactivé ?
Il faut distinguer deux choses:
L’édition via l’interface WordPress, c’est le panneau qui permet de modifier des fichiers depuis l’admin. Le fichier lui-même, stocké sur le serveur, bien sûr, reste modifiable si quelqu’un a un accès au système de fichiers.Désactiver l’édition depuis l’admin n’empêche pas un attaquant qui aurait déjà un accès système (SSH, accès panneau d’hébergement, identifiants FTP). Si votre hébergement est correctement verrouillé, c’est justement ce que vous gagnez: la modification du code ne peut plus être faite “depuis l’interface” en supposant que le reste de votre environnement est maîtrisé.
En pratique, quand vous appliquez la configuration WordPress appropriée, vous privez l’éditeur d’une fonction clé, et l’accès à certaines pages d’édition devient indisponible ou échoue. Sur un site réel, c’est souvent immédiat, et vous le constatez directement dans l’interface.
Méthode recommandée: modifier la configuration WordPress
Le réglage le plus courant pour désactiver l’édition de fichiers dans le tableau de bord se fait via un paramètre PHP dans votre configuration WordPress. Dans la majorité des hébergements, il faut ajouter une ligne dans le fichier wp-config.php, à la racine du site.
L’idée est simple: vous définissez une constante qui indique à WordPress que l’édition de fichiers est interdite. Concrètement, vous cherchez la fin du fichier wp-config.php, puis vous ajoutez:
Define('DISALLOW_FILE_EDIT', true);Selon votre installation, il peut aussi exister une constante associée pour empêcher d’écrire des fichiers depuis l’admin, par exemple:
Define('DISALLOW_FILE_MODS', true);Ces deux options vont dans le sens de la restriction. La plus directe pour votre objectif est DISALLOW_FILE_EDIT.
Où placer la ligne dans wp-config.php
Vous voulez éviter toute erreur de syntaxe, même si vous êtes familier avec PHP. Le principe:
- Ajoutez la ligne dans wp-config.php en dehors des commentaires, sans casser la logique existante. Placez-la près des autres définitions, avant le “dernier bout” qui configure WordPress. Ne dupliquez pas la constante si elle existe déjà.
Avant toute modification, faites une sauvegarde du fichier. Sur des sites à fort trafic, je préfère aussi vérifier en heure calme, ou au moins préparer un retour arrière rapide.
Une mini anecdote de terrain
Sur un site client, un “petit correctif” devait être fait un soir, et la personne en charge a demandé l’accès à l’éditeur de thème, “juste pour ajuster deux lignes”. On avait pourtant mis DISALLOW_FILE_EDIT quelques semaines plus tôt. Résultat: la demande a été traitée autrement, via un déploiement standard, avec test et validation. Ce n’était pas agréable sur le moment, mais c’était un bon rappel: l’éditeur depuis l’admin n’est pas une procédure opérationnelle, c’est un bouton rouge. Quand il disparaît, l’équipe finit par suivre un flux plus sûr.
Vérifier l’effet dans l’administration
Après mise à jour de wp-config.php, connectez-vous à l’administration avec un utilisateur disposant de droits. Le point important est de tester avec un compte qui avait accès à l’éditeur auparavant. Si l’option est vraiment désactivée, les pages d’édition devraient être inaccessibles, ou l’action échouera.
Sur certains setups, l’effet peut varier légèrement selon le thème, les plugins de sécurité, ou des règles serveur. Mais le comportement attendu est clair: l’édition de fichiers depuis l’interface doit être bloquée.
Si vous utilisez un plugin de sécurité, il peut également afficher un message ou signaler une configuration “non conforme”. Ce n’est pas forcément un souci, mais ça peut vous donner un indice sur l’état réel de la restriction.
Attention aux plugins et outils qui “écrivent”
La partie délicate, c’est que certaines configurations ou plugins demandent d’écrire. Par exemple:
- des plugins qui gèrent des modèles et génèrent du code à la volée; des outils de cache agressifs qui modifient des fichiers temporaires; des environnements de staging qui utilisent un éditeur ou un “patch” en interface.
DISALLOW_FILE_EDIT bloque l’édition de fichiers via l’admin, mais pas forcément toutes les opérations d’écriture si elles sont exécutées côté PHP avec des méthodes différentes. DISALLOW_FILE_MODS, lui, interdit davantage de modifications depuis l’admin.
Le vrai sujet est opérationnel: vérifiez que votre chaîne de déploiement, vos plugins et votre méthode de maintenance restent fonctionnels. Si vous travaillez avec un environnement où certains correctifs sont faits “dans le back-office” par des membres de l’équipe, vous devez formaliser une alternative.
Une bonne règle que j’applique: quand on retire l’éditeur, on indique à l’équipe comment faire autrement. Sinon, ils contournent, ou ils perdent du temps à chercher pourquoi “ça ne marche plus”.
Cas particuliers: multisite, rôles et compatibilité
WordPress multisite a parfois des chemins différents et des capacités particulières selon les paramètres réseau. Sur un réseau, vous devez aussi penser au niveau super admin. En désactivant DISALLOW_FILE_EDIT dans wp-config.php, vous appliquez la règle à l’ensemble de WordPress, ce qui est généralement ce que vous voulez.
Concernant les rôles, un point revient souvent: “de toute façon, on ne donne pas le droit à tout le monde”. En théorie, oui. Dans la pratique, les accès admin finissent par se retrouver dans des endroits inattendus. Un collaborateur part, on oublie de retirer l’accès, un prestataire change de mot de passe sans documenter, un compte est réutilisé. Cette mesure réduit la valeur de l’erreur humaine. C’est aussi pour ça qu’elle est populaire.
Enfin, niveau compatibilité, la plupart des installations standards s’en sortent sans souci. Là où ça se complique, c’est quand on utilise des plugins qui dépendent explicitement de fonctions d’édition dans l’admin. Si vous voyez des symptômes après le changement, il faut diagnostiquer ce qui tente d’écrire ou de modifier. Ce n’est pas forcément la ligne qui est “mauvaise”, c’est parfois le fait que l’environnement attend un comportement que vous venez précisément de bloquer.
Mettre aussi un frein sur l’écriture (optionnel, mais utile)
Si votre objectif est “désactiver l’édition de fichiers depuis l’admin”, DISALLOW_FILE_EDIT répond directement. Mais, selon la posture de sécurité que vous visez, vous pouvez vouloir aller plus loin avec DISALLOW_FILE_MODS. Cette option empêche certaines modifications via l’administration.
Je le dis clairement: je ne conseille pas de tout verrouiller aveuglément si votre équipe a besoin de certaines fonctionnalités d’admin. Sur des sites simples, c’est souvent compatible. Sur des environnements très outillés, ça peut casser un flux. D’où l’intérêt d’un test sur staging ou au minimum sur une page de démo.
Si vous choisissez d’ajouter les deux constantes, vous pouvez partir sur un bloc comme:
Define('DISALLOW_FILE_EDIT', true); Define('DISALLOW_FILE_MODS', true);Le compromis à garder en tête: plus vous verrouillez, moins vous laissez de souplesse aux interventions rapides. En échange, vous gagnez en résistance aux abus.
Procédure pratique pour le faire sans stress
Voici une manière de procéder qui évite les erreurs bêtes, surtout si vous n’avez pas l’habitude de modifier wp-config.php.
- Faites une sauvegarde de wp-config.php (copie locale). Ajoutez define('DISALLOW_FILE_EDIT', true); dans le fichier, sans casser la syntaxe PHP. Uploadez le fichier de façon sûre, puis rechargez la page d’administration. Testez l’accès à l’éditeur de fichiers avec un compte ayant normalement les droits. Si un plugin ou un outil casse une fonctionnalité, identifiez ce qui dépend de l’édition et ajustez plutôt que de tout réactiver.
Cette approche vous donne un retour rapide et vous évite le grand classique: “j’ai modifié le fichier, puis ça ne marche plus, et je ne sais pas ce que j’ai cassé”.
Diagnostiquer quand l’édition reste accessible
Il arrive, rarement, que l’éditeur continue de fonctionner après modification. Les causes typiques ne sont pas “WordPress n’a pas respecté la constante”. Souvent, c’est une question de déploiement ou de fichier pas au bon endroit.
Les vérifications que je fais d’abord sont simples:
- le wp-config.php modifié est-il bien celui de l’installation concernée, pas une copie dans un autre dossier? la constante est-elle présente sans faute de frappe, y compris les majuscules et les guillemets? le fichier est-il rechargé et bien servi par l’hébergement? un autre fichier ou une autre config surcharge-t-elle la constante plus bas dans wp-config.php?
Vous pouvez aussi voir des effets si un plugin de sécurité gère déjà des restrictions. Dans ce cas, il peut afficher un comportement particulier. Mais si rien ne change dans l’admin, vérifiez d’abord que le code est bien en place et actif.
Une courte checklist de dépannage
- Confirmer que la ligne est bien dans le wp-config.php racine du site. Vérifier l’absence de duplication ou de contradiction des constantes. Tester après purge cache éventuelle (cache serveur ou CDN). Contrôler qu’un plugin ne réactive pas un éditeur via des mécanismes internes. Tester sur un compte non super administrateur, pour comprendre qui voit quoi.
Si vous avez un CDN en avant ou un cache applicatif, une page déjà chargée dans le navigateur peut donner l’impression que “rien n’a changé”. Fermez la session, forcez un rechargement, ou testez avec une session propre. C’est un détail qui fait perdre une heure, et ça vaut le coup de le traiter vite.
Pourquoi cette mesure améliore vraiment la sécurité
Désactiver l’édition de fichiers depuis l’admin est une stratégie de contrôle. Elle limite ce que peut faire un attaquant qui a déjà franchi la barrière d’accès à l’interface. Dans une intrusion, le code est ce qui permet la persistance et la collecte de données.
Vous réduisez le chemin “intrusion puis installation d’un backdoor” en coupant l’option la plus directe dans WordPress. Le reste du système reste bien sûr attaquable. Une faille sur un plugin pourrait être exploitée autrement. Mais si l’attaquant doit maintenant passer par un vecteur plus compliqué (exemple, trouver une autre fonction d’écriture, compromettre le serveur, ou exploiter une autre route), la probabilité diminue.
C’est aussi une mesure psychologique côté équipe. Quand l’éditeur disparaît, les demandes changent. Au lieu de “donnez moi l’accès admin pour bricoler”, on passe par “on fait une modification via notre processus de déploiement”. C’est là que la sécurité gagne en durabilité.
Le vrai sujet: empêcher l’accès admin inutile
Cette mesure se combine avec une hygiène de base:
- limiter le nombre de comptes ayant des droits élevés; activer la double authentification quand c’est possible; surveiller les connexions inhabituelles; gérer la rotation des mots de passe, surtout pour les comptes administrateur historiques.
Je ne détaille pas tout ici, mais il faut garder une cohérence. Désactiver l’édition est un verrou, pas l’intégralité de la serrure. Sans gestion des accès, vous bloquez un mode d’action, mais quelqu’un peut toujours tenter d’exploiter autre chose.
Dans les environnements où j’ai vu cette mesure apporter un vrai bénéfice, elle était accompagnée de règles simples, comme la réduction des comptes admin, et un processus de mise à jour clair.
Une alternative raisonnable pour les interventions
Quand on retire l’éditeur, l’équipe doit pouvoir agir. La bonne approche est de prévoir une procédure de changement rapide, sans revenir à l’édition dans WordPress.
Selon vos outils, ça peut passer par:
- un déploiement via Git et un pipeline (même léger); un accès SFTP encadré pour les fichiers de thème ou de configuration; un système de staging où on teste avant de pousser en production; une revue rapide avant publication, au moins pour les modifications PHP.
Vous gagnez un peu de temps au début, puis vous évitez les urgences. Et surtout, vous gardez une trace de ce qui a changé, ce qui est précieux quand il faut enquêter.
Vérifier aussi les droits côté serveur
Même si la demande porte sur WordPress, je termine par un point souvent oublié: la sécurité réelle se joue aussi sur la permission des fichiers. Si votre hébergeur configure des droits trop permissifs, un attaquant qui parvient à une exécution de code a moins d’obstacles. À l’inverse, des permissions cohérentes rendent certaines actions plus difficiles.
Sans entrer dans les détails de chaque environnement, gardez l’idée: verrouiller WordPress au niveau admin, puis renforcer les garde-fous côté serveur. Les deux se complètent.
Synthèse opérationnelle
Si vous voulez sécuriser site WordPress de façon concrète, désactiver l’édition de fichiers depuis l’admin est l’un des réglages les plus rentables. Vous réduisez la capacité à modifier du code depuis l’interface, ce qui diminue le risque de persistance lors d’une intrusion.
Pour y arriver, la recette est nette: ajoutez define('DISALLOW_FILE_EDIT', true); dans wp-config.php, puis testez dans l’administration. Selon votre contexte, vous pouvez compléter avec DISALLOW_FILE_MODS, mais uniquement après avoir vérifié que vos outils ne dépendront pas de ces fonctions.
Si vous appliquez cette mesure comme un changement d’organisation, pas seulement comme un paramètre technique, vous obtenez un bénéfice durable. Le site reste moins malléable, et votre équipe se réoriente vers un mode d’intervention plus sûr, plus traçable, et plus facile à auditer.