Désactiver l’édition de plugin et thème : mode d’emploi

Désactiver l’édition de plugins et de thèmes dans WordPress, ce n’est pas un caprice de sécurité. C’est une mesure simple qui réduit fortement une catégorie de dégâts possibles quand un compte est compromis, quand un attaquant trouve une faille applicative, ou quand quelqu’un fait une modification “à l’arrache” en pensant que ça ira vite.

Dans WordPress, l’accès à l’éditeur de fichiers permet de modifier directement le code via l’interface d’administration. Un pirate ou un compte mal sécurisé peut alors tenter de déposer du code malveillant, modifier un thème actif ou corriger son propre “chemin” d’accès. En coupant l’édition, vous ne résolvez pas toutes les menaces, mais vous supprimez un levier. C’est un bon réflexe de sécuriser site WordPress, surtout si le site a des contributeurs, un historique d’anciens plugins, ou une production en ligne sans filet.

Pourquoi désactiver l’éditeur reste pertinent aujourd’hui

WordPress propose des écrans d’administration pratiques, dont l’éditeur de thème et l’éditeur de plugin. Ces écrans ont une utilité réelle quand vous dépannez rapidement un CSS, testez un snippet, ou corrigez un bug sans passer par FTP. Le problème, c’est que la commodité n’a de valeur que tant que l’environnement est maîtrisé.

Sur des sites moyens, j’ai vu plusieurs scénarios concrets.

D’abord, le cas “petite erreur”. Une personne modifie un fichier et casse une dépendance. Le site affiche ensuite une erreur blanche, puis on apprend que le correctif sera plus rapide à écrire qu’à revenir en arrière, parce que la sauvegarde n’était pas récente.

Ensuite, le cas “accès administrateur réduit”. Même si vous restreignez les rôles, WordPress reste un système vivant. Une redirection mal configurée, un cookie trop long, une session oubliée ou un plugin vulnérable peut ouvrir la porte à un acteur qui n’aurait pas eu besoin d’interface FTP. Couper l’édition réduit la surface d’attaque.

Enfin, le cas “maintenance externalisée”. Quand une agence ou un freelancing intervient, on donne parfois temporairement des accès. Si ces accès incluent la possibilité d’éditer des fichiers, on s’expose à des modifications qui ne passent ni par un workflow de versioning, ni par des validations.

Le bon équilibre consiste en général à désactiver l’édition en production et à la réactiver uniquement dans un environnement de staging, ou le temps strict de dépannage. C’est précisément ce que permettent certaines constantes de configuration.

Ce que vous bloquez exactement dans WordPress

Quand vous désactivez l’édition via la configuration, vous ne coupez pas “le site” ni “tous les fichiers”. Vous bloquez une fonctionnalité ciblée: l’écriture de fichiers à partir de l’admin, et, selon les réglages, une partie des modifications de fichiers par l’interface.

En pratique, cela se traduit par le fait que WordPress ne vous laisse plus utiliser l’éditeur de thème et de plugin, et refuse les opérations qui reposent sur cette couche d’écriture.

Autre point important: selon votre hébergeur et votre méthode de déploiement, WordPress peut aussi désactiver certains parcours d’installation ou de mise à jour, si vous forcez trop un mode d’accès aux fichiers. Le but est de trouver un réglage qui bloque l’édition sans casser vos mises à jour légitimes.

Avant de modifier quoi que ce soit

Avant d’entrer dans le fichier wp-config.php, prenez deux ou trois minutes pour éviter un incident bête. L’objectif est de faire ce changement sans vous retrouver bloqué au moment de mettre à jour un plugin.

Vérifiez la sauvegarde de wp-config.php et, si vous ne l’avez pas, faites-en une copie locale avant toute modification. Confirmez que vous avez accès à l’hébergement pour modifier des fichiers (via votre panneau d’administration, SSH, ou FTP). Prenez note de la configuration actuelle de votre WordPress (multisite ou non, et toute constante déjà présente). Testez sur un environnement de préproduction si vous en avez un, ou au moins planifiez le changement à un moment où le support peut agir rapidement.

C’est rarement plus long que quelques minutes, et ça évite le moment où, le soir, vous devez restaurer un fichier en urgence.

La méthode la plus propre: wp-config.php

Le cœur de la démarche consiste à ajouter (ou à ajuster) des constantes dans wp-config.php. C’est le mécanisme le plus standard et le plus stable, car il s’applique côté WordPress au moment où l’admin demande l’édition.

1) Bloquer l’édition de fichiers depuis l’administration

Ajoutez dans wp-config.php, idéalement avant la ligne qui définit ABSPATH (ou à proximité), des constantes du type suivant.

Define('DISALLOW_FILE_EDIT', true);

Avec cette valeur, WordPress refuse les modifications de fichiers via l’interface d’édition. Concrètement, les écrans d’édition de thème et de plugin ne sont plus utilisables comme auparavant. Sur un site classique, c’est le réglage que je recommande d’abord.

Trade-off: si vous utilisiez l’éditeur pour des retouches ponctuelles, vous devrez passer par un autre canal (FTP, SSH, Git, ou un outil de déploiement) pour modifier le code.

2) Bloquer aussi l’installation et la mise à jour par l’admin (optionnel mais fréquent)

Selon votre niveau de verrouillage souhaité, vous pouvez aussi empêcher certains traitements liés à la modification de fichiers. Une constante souvent utilisée est:

Define('DISALLOW_FILE_MODS', true);

Selon la configuration exacte du site, cela peut bloquer des actions plus larges que l’édition. Sur un site où seules des mises à jour contrôlées sont acceptées, ce verrou est cohérent.

Trade-off: si vous comptez sur l’administration pour installer ou mettre à jour des plugins sans passer par le serveur, vous allez perdre ce confort. Dans ce cas, je conseille plutôt DISALLOW _FILE_EDIT seul, et d’encadrer les mises à jour autrement.

3) Ne pas confondre blocage de l’édition et méthode de fichiers

Il existe aussi des constantes liées à la “méthode” utilisée par WordPress pour écrire des fichiers (par exemple via FTP/SSH). Forcer une méthode inadaptée peut créer un effet secondaire: WordPress croit qu’il peut écrire, mais échoue.

Le but est donc clair: commencez par les constantes de désactivation d’édition. Ensuite seulement, si vous rencontrez des problèmes de mise à jour dans un environnement particulier, ajustez la méthode de fichiers avec prudence.

Emplacement exact dans wp-config.php

Dans wp-config.php, on évite de modifier des blocs inutiles, et on place vos définitions dans la zone “configuration”.

En règle générale, vous ajoutez ces lignes dans la section où vous configurez déjà des constantes, par exemple autour de celles liées à la base de données.

Si votre wp-config.php contient déjà DISALLOW _FILE_EDIT ou DISALLOW _FILE_MODS, vérifiez les valeurs. Une double définition peut créer de la confusion, même si PHP tend à utiliser la dernière valeur lue.

Vérifier que l’éditeur est réellement bloqué

Une fois le changement appliqué, ne vous contentez pas de “penser que ça marche”. WordPress peut afficher ou masquer les menus selon d’autres états internes.

Ce que je fais généralement sur un site de test, puis sur la prod:

connecter avec un utilisateur ayant des droits d’administration, ouvrir la section Apparence puis éditeur de fichiers, ouvrir aussi la section Plugins puis éditeur, tenter d’ouvrir un fichier depuis l’admin si l’UI propose un lien.

Le résultat attendu est simple: WordPress doit refuser l’édition, ou afficher un message indiquant que l’opération n’est pas autorisée. Le détail exact dépend des versions et de la configuration, mais si vous voyez toujours l’éditeur complet, c’est que la contrainte ne s’applique pas.

Cas particuliers qui changent la donne

Multisite: attention au niveau de configuration

Sur un WordPress multisite, la configuration peut s’appliquer différemment selon le fichier de configuration global, ou les règles liées aux sites individuels. En pratique, le plus sûr est de placer le réglage dans wp-config.php du réseau (le fichier racine du WordPress multisite).

Ensuite seulement, testez avec un compte administrateur du réseau, puis avec un administrateur de site. Si vous avez des rôles variés, vérifiez que personne ne peut accéder à l’édition depuis un espace où vous pensiez avoir fermé la porte.

Hébergeur et outils de déploiement

Certains hébergeurs gèrent des mises à jour via des boutons dans leur panneau, et ils n’ont pas besoin que WordPress écrive depuis l’admin. Ça joue en votre faveur.

En revanche, d’autres setups reposent sur l’interface WordPress pour installer rapidement un plugin. Si votre équipe s’appuie sur ces raccourcis, l’approche “verrouillage maximal” peut casser le flux de travail. Dans ce cas, vous pouvez appliquer DISALLOW _FILE_EDIT, puis garder DISALLOW _FILE_MODS pour plus tard, le temps que l’équipe s’habitue à un process de déploiement plus propre.

Authentification et rôle: ce verrou ne remplace pas le durcissement

Désactiver l’édition réduit un type d’attaque, mais cela ne dispense pas de vérifier:

la qualité des mots de passe, l’usage d’une authentification forte (selon votre contexte), la limitation des comptes administrateurs, les permissions des fichiers sur le serveur.

Le verrou sur l’édition est un verrou “local”. Il s’ajoute aux autres couches.

J’ai déjà vu un site où l’éditeur était désactivé, mais où un compte admin utilisait un mot de passe trop simple. L’attaquant n’avait pas besoin d’éditer des fichiers, il a pris le contrôle d’un autre levier. Autrement dit: c’est une bonne mesure, mais pas un bouclier unique.

Procédure de déploiement recommandée: garder le confort ailleurs

Si votre objectif est la sécurité, mais que vous voulez garder une maintenance fluide, je recommande un schéma simple: staging ouvert, production verrouillée.

Sur staging, vous pouvez maintenir l’éditeur disponible si votre équipe en a réellement besoin, ou le désactiver aussi, mais alors assurez-vous que vous avez une méthode fiable de modification du code (Git + déploiement, ou accès serveur).

Sur production, verrouillez l’édition via wp-config.php, et passez par un workflow de versioning. Dans beaucoup d’organisations, les retouches légères se font en CSS via un thème enfant ou un plugin de snippets, déployés via un système de code. Les modifications de PHP, elles, se traitent comme du code, pas comme un bricolage d’interface.

Le gain, c’est aussi la traçabilité: vous savez ce qui a changé, quand, et pourquoi.

Exemple de configuration “production classique”

Voici une configuration typique, adaptée à beaucoup de sites, sans tomber dans l’excès.

Define('DISALLOW_FILE_EDIT', true);

Si vous gérez tout depuis le serveur et que personne ne doit installer ou modifier depuis l’admin, vous pouvez ajouter:

Define('DISALLOW_FILE_MODS', true);

Je préfère vous donner ce repère mental: DISALLOW _FILE_EDIT est le verrou minimal sur l’édition. DISALLOW _FILE_MODS élargit le blocage aux modifications plus générales. Plus vous ajoutez de constantes, plus vous imposez un process de maintenance strict.

Symptômes quand quelque chose ne colle pas

Parfois, après modification, les mises à jour échouent, ou WordPress vous demande des identifiants FTP. Ces messages ne sont pas forcément liés à l’édition, mais à la manière dont WordPress tente d’écrire.

Voici les cas les plus fréquents que j’ai rencontrés:

L’éditeur n’est plus accessible, mais les mises à jour via l’admin échouent avec un problème d’écriture de fichier. WordPress affiche un message invitant à entrer des identifiants FTP ou des paramètres de connexion. Les menus “éditeur” disparaissent, mais des actions d’installation de plugins échouent aussi, signe que le verrou est plus large que prévu.

Dans ces situations, il faut distinguer ce que vous avez verrouillé (édition) de ce que WordPress essaye de faire (écrire des fichiers). Le diagnostic demande de regarder le message exact, puis d’ajuster prudemment.

Comment gérer les retouches urgentes sans réactiver l’éditeur

On me pose souvent la question: “Et si un bug arrive un dimanche, je fais quoi si l’éditeur est fermé?”

C’est là que l’organisation joue. Vous pouvez prévoir une procédure de secours.

En pratique, le scénario le plus courant consiste à utiliser un accès serveur rapide et contrôlé (SSH ou panneau hébergeur) et à appliquer la correction via un fichier versionné. Si vous n’avez pas cette capacité, l’option la plus sûre n’est pas de réactiver l’éditeur pour tout le monde.

Au lieu de ça, définissez une fenêtre de dépannage très courte, avec une procédure claire. Par exemple, vous réactivez temporairement l’édition uniquement sur votre environnement de travail ou sur un compte dédié, vous corrigez le problème, puis vous refermez immédiatement. Cette pratique est plus rigoureuse que de laisser l’éditeur ouvert “par défaut”, et elle réduit les oublis.

Impact sur l’équipe et la collaboration

Désactiver l’édition est aussi un sujet d’usage. Une fois le réglage en place, certaines personnes vont chercher la modification “au même endroit qu’avant”.

C’est pour ça qu’il faut anticiper la communication interne. Une phrase suffit, et un point très concret: “Les modifications PHP se font via le dépôt et le déploiement, pas via l’interface.” Si votre équipe sait déjà comment elle déploie, l’adoption est rapide.

Si au contraire vous avez une équipe qui bricolait depuis l’éditeur, vous allez sentir la friction. Ce n’est pas un problème technique, c’est un ajustement de pratiques. À mon avis, c’est un ajustement utile, parce que les modifications manuelles dans l’admin sont rarement reproductibles et difficiles à auditer.

Vérifier sur le long terme: ne pas oublier les mises à jour

Les constantes DISALLOW _FILE_EDIT et DISALLOW _FILE_MODS sont généralement stables. Mais votre site évolue: nouveaux plugins, nouveaux thèmes, migrations, changement d’hébergeur, passage à une architecture Git.

À chaque étape importante, gardez l’habitude de vérifier:

que l’éditeur reste désactivé sur production, que vos mises à jour continuent de fonctionner selon votre process, que les comptes administrateurs restent limités.

Si vous avez un contrôle automatisé, c’est encore mieux. Sinon, un contrôle manuel périodique suffit, surtout si le site est maintenu activement.

En pratique, quelle stratégie choisir

Le choix entre DISALLOW _FILE_EDIT seul et DISALLOW _FILE_MODS dépend de votre mode opératoire.

Si vous souhaitez avant tout “sécuriser site WordPress” en réduisant le risque le plus direct, commencez par DISALLOW _FILE_EDIT. Vous supprimez l’accès à l’éditeur, sans forcément tout casser côté installation.

Si votre objectif est de verrouiller davantage, et que vous n’installez ni ne modifiez rien depuis l’interface, DISALLOW _FILE_MODS prend du sens. Dans un contexte où la maintenance est automatisée ou faite via accès serveur, ce verrou est cohérent.

Et si vous tenez à l’éditeur pour des cas exceptionnels, prévoyez plutôt une procédure de déblocage très courte et encadrée. Le pire scénario, c’est celui où l’éditeur reste réactivé “juste pour voir”, pendant plusieurs semaines.

Récapitulatif opérationnel (sans jargon)

Vous voulez désactiver l’édition de plugin et de thème. Le chemin le plus fiable consiste à:

1. faire la modification dans wp-config.php, 2) choisir le niveau de verrouillage selon votre process, 3) tester sur un compte admin, 4) vérifier l’impact sur les mises à jour, 5) documenter la procédure pour l’équipe.

Une fois fait, vous gagnez un levier de sécurité concret. Et surtout, vous forcez votre maintenance à passer par un canal plus contrôlé, ce qui réduit à la fois les incidents accidentels et les opportunités en cas de compromission.

Si vous me dites votre configuration (site simple ou multisite, méthode de déploiement actuelle, et si vous installez des plugins depuis l’admin), je peux vous proposer une configuration cible, au bon niveau https://gardewp.fr/securite-wordpress/ de verrouillage, sans casser votre rythme de maintenance.