Masquer proprement des menus de l'administration selon le rôle

Une administration installée depuis quelques années présente une trentaine d'entrées de menu, dont la majorité ne concerne pas les personnes qui publient les contenus. Le rédacteur voit les réglages du serveur de cache, le commercial voit les options du thème, et tout le monde voit les quinze menus ajoutés par les extensions. Cette abondance produit deux effets indésirables : elle ralentit le travail quotidien en noyant les fonctions utiles, et elle expose des réglages que personne n'a besoin de toucher. Simplifier cette interface par profil est un travail rentable et simple, à condition de comprendre une distinction essentielle : masquer une entrée de menu ne protège absolument rien.

Masquer et interdire ne sont pas la même chose

Cette confusion est la source de la quasi totalité des erreurs commises sur ce sujet, et elle mérite d'être posée clairement avant toute manipulation.

Ce qu'un menu représente réellement

Une entrée de menu est un raccourci vers une adresse, rien de plus. Retirer l'entrée ne supprime ni l'adresse ni la page qui répond, elle devient simplement moins visible. Un utilisateur qui connaît l'adresse, ou qui l'a enregistrée dans ses favoris, y accède exactement comme avant. Les outils automatisés qui parcourent un site connaissent toutes les adresses standard et ne passent jamais par les menus. Masquer une entrée relève donc du confort d'utilisation, jamais de la sécurité. Confondre les deux produit un faux sentiment de protection particulièrement dangereux.

Ce qu'une permission représente

Le contrôle réel repose sur un système de droits attachés à chaque compte, vérifiés par la page elle même avant d'exécuter quoi que ce soit. Une page correctement écrite refuse l'accès à un utilisateur ne disposant pas du droit requis, quel que soit le chemin emprunté. Ce mécanisme fonctionne indépendamment de l'affichage des menus. Les rôles standard et les droits qu'ils portent sont détaillés dans notre article sur l'utilisateur WordPress et ses rôles. Travailler d'abord sur les droits, puis sur l'affichage, constitue le bon ordre. L'inverse produit une interface propre et une protection illusoire.

Le bon usage de chacun

Les permissions déterminent ce qu'un utilisateur peut faire, les menus déterminent ce qu'il voit. Les deux se complètent : un menu affiché vers une page interdite produit un message d'erreur frustrant, une page autorisée sans menu reste inaccessible en pratique. La règle simple consiste à faire correspondre exactement les deux : chaque droit retiré s'accompagne du retrait de l'entrée correspondante. Cette cohérence produit une interface où tout ce qui est visible fonctionne. Elle évite les tickets de support inutiles. Elle rend également l'audit beaucoup plus simple.

Les extensions qui ne vérifient rien

Une partie des extensions ajoute une page d'administration sans vérifier correctement les droits, se contentant de masquer le menu aux profils non autorisés. Cette pratique est fréquente et elle constitue une faille réelle. Tester l'accès direct à ces pages avec un compte de faible niveau révèle le problème en quelques minutes. Lorsqu'une extension présente ce défaut, la seule protection consiste à ajouter une vérification en amont ou à changer d'extension. Signaler le problème à l'auteur reste utile. Ce contrôle mérite d'être mené sur les extensions les plus sensibles.

Le cas des données affichées

Masquer un menu ne masque pas les données qu'il présentait, qui restent accessibles par d'autres chemins : liste des contenus, recherche, points d'accès de programmation. Une donnée réellement confidentielle doit être protégée à la source, dans les requêtes qui la retournent. Cette protection est nettement plus exigeante que le simple contrôle d'une page. Elle relève de la conception de l'application plutôt que de la configuration de l'interface. Sur ce type de besoin, il faut résister à la solution de facilité. Le sujet dépasse largement la question des menus.

Le principe du droit minimal

La bonne pratique consiste à attribuer à chaque compte les droits strictement nécessaires à son travail, et rien de plus. Ce principe réduit la surface d'erreur autant que la surface d'attaque, un compte compromis ne pouvant faire que ce que son propriétaire pouvait faire. Il impose un travail initial de définition des profils, qui prend une demi journée. Il évite ensuite les incidents où un contributeur désactive une extension par curiosité. Cette approche est plus confortable pour tout le monde, y compris pour les utilisateurs. Elle leur retire la crainte de casser quelque chose.

Définir les profils avant de toucher à l'interface

Le travail utile commence par une réflexion sur les usages réels, et non par une manipulation technique.

Lister les fonctions par métier

Un tableau simple, avec une ligne par personne ou par métier et une colonne par fonction de l'administration, fait apparaître ce qui sert et ce qui ne sert pas. Ce recensement se mène en interrogeant les utilisateurs plutôt qu'en supposant. Les réponses réservent souvent des surprises, certaines fonctions supposées essentielles n'ayant jamais été utilisées. Ce tableau constitue la référence de tout le travail ultérieur. Il prend une heure à construire et il évite les allers-retours. Il sert également lors de l'arrivée d'un nouveau collaborateur.

Regrouper en trois ou quatre profils

Créer un profil par personne devient rapidement ingérable et il faut regrouper les usages en un petit nombre de rôles. Un site de contenu fonctionne généralement bien avec quatre profils : administration technique, responsable éditorial, rédacteur et consultation seule. Un site marchand ajoute un profil de gestion des commandes. Au delà de cinq ou six rôles, la maintenance devient une charge. Ce regroupement suppose d'accepter que certaines personnes disposent d'un droit qu'elles n'utiliseront pas. Ce compromis est presque toujours préférable à la multiplication des rôles.

Partir des rôles existants

La plateforme propose des rôles standard qui couvrent la plupart des besoins et qu'il vaut mieux ajuster plutôt que remplacer. Créer un rôle entièrement nouveau demande de déclarer chaque droit individuellement, ce qui est long et propice aux oublis. Ajouter ou retirer quelques droits à un rôle existant produit le même résultat pour une fraction de l'effort. Les extensions reconnaissent également mieux les rôles standard. Cette approche facilite aussi les mises à jour. Elle constitue le choix par défaut sauf besoin très particulier.

Documenter la matrice des droits

Le tableau croisant les rôles et les droits doit être consigné dans la documentation du site. Sans cette trace, la première personne qui interviendra ne comprendra pas pourquoi tel droit a été retiré et le rétablira. Ce document sert également lors d'un audit ou d'un changement de prestataire. Il tient sur une page et il se met à jour en même temps que la configuration. Le placer avec les autres documents techniques garantit sa disponibilité. Cette habitude vaut pour toute personnalisation structurante.

Prévoir un compte de secours

Une manipulation de droits peut priver l'administrateur principal d'un accès essentiel, situation particulièrement désagréable. Conserver un second compte avec les droits complets, dont les identifiants sont stockés hors ligne, constitue le filet de sécurité minimal. L'accès direct à la base permet également de rétablir la situation, à condition de savoir comment procéder. Documenter cette procédure avant d'en avoir besoin fait partie de la préparation. Elle sera exécutée dans l'urgence par quelqu'un qui n'aura pas le temps de chercher. Une page écrite suffit.

Tester sur un environnement de copie

Les modifications de droits produisent parfois des effets inattendus, notamment sur les extensions qui déclarent leurs propres autorisations. Les appliquer d'abord sur une copie du site permet de vérifier chaque profil sans risque. Cette vérification demande de se connecter avec un compte de chaque type et de parcourir les fonctions attendues. Elle prend une heure et elle évite les incidents en production. Sur un site utilisé quotidiennement par plusieurs personnes, elle n'est pas facultative. Le temps investi se récupère au premier problème évité.

Les méthodes propres pour retirer une entrée

Plusieurs techniques existent et elles n'ont ni la même robustesse ni les mêmes effets de bord.

Retirer le droit associé

La méthode la plus propre consiste à retirer le droit qui conditionne l'affichage de l'entrée, celle-ci disparaissant alors d'elle même. Cette approche traite simultanément la visibilité et l'accès, ce qui règle le problème à sa racine. Elle fonctionne pour toutes les entrées natives et pour les extensions correctement écrites. Elle constitue le premier réflexe à adopter avant toute autre technique. Elle demande de connaître le droit associé à chaque menu, information documentée pour le cœur du système. Pour les extensions, une lecture rapide du code suffit à l'identifier.

Utiliser la fonction de retrait dédiée

Lorsque le droit ne peut pas être retiré sans conséquence, une fonction permet de supprimer l'entrée de menu depuis le code du thème enfant. Cette suppression doit être conditionnée au rôle de l'utilisateur courant, faute de quoi elle s'appliquerait à tout le monde. Elle doit également viser précisément l'identifiant de l'entrée, qui se lit dans le code source de la page d'administration. Une erreur d'identifiant produit un retrait silencieux qui ne fonctionne pas. Cette technique est robuste et elle survit aux mises à jour de la plateforme. Elle reste sans effet sur l'accessibilité de la page.

Compléter par un contrôle d'accès

Si l'entrée a été retirée sans que le droit ne le soit, la page reste accessible et il faut ajouter une vérification. Cette vérification s'écrit en quelques lignes et intervient au chargement de la page d'administration concernée. Elle redirige ou affiche un message de refus selon le cas. Sans elle, le retrait de menu ne constitue qu'un habillage. Cette étape est celle qui est le plus souvent omise, ce qui vide le travail de son intérêt sécuritaire. Elle prend cinq minutes par page concernée.

Personnaliser le tableau de bord

Les blocs de la page d'accueil de l'administration relèvent d'un mécanisme distinct et se retirent séparément. Beaucoup d'entre eux affichent des informations sans intérêt pour les utilisateurs courants, comme les actualités de la plateforme. Les techniques de personnalisation de cet écran sont présentées dans notre article sur la manière de personnaliser le tableau de bord WordPress selon le profil utilisateur. Un tableau de bord épuré donne immédiatement une impression de site bien tenu. Il constitue souvent le premier écran vu à chaque connexion. Le soigner produit un effet disproportionné par rapport à l'effort.

Traiter la barre d'outils

La barre affichée en haut du site pour les utilisateurs connectés contient elle aussi des raccourcis qui peuvent être retirés. Elle relève encore d'un mécanisme différent, avec ses propres fonctions de suppression. Certains profils n'ont aucun besoin de cette barre, qui peut alors être désactivée entièrement pour eux. Cette désactivation supprime également le décalage qu'elle provoque sur l'affichage du site. Elle constitue un gain de confort et de performance modeste. Elle complète utilement le travail sur les menus.

Éviter le masquage par feuille de style

La tentation existe de simplement cacher visuellement les entrées avec quelques lignes de style. Cette méthode est la pire de toutes : l'entrée reste présente dans le code, accessible en désactivant les styles, et la page demeure entièrement fonctionnelle. Elle donne l'illusion du résultat sans aucun bénéfice réel. Elle casse également l'accessibilité pour les personnes utilisant un lecteur d'écran, qui entendront des entrées invisibles. Aucune situation ne justifie cette approche. Elle doit être retirée partout où elle a été employée.

Vérifier et maintenir dans la durée

Une configuration de droits se dégrade si personne ne la surveille, et les vérifications à mener sont peu nombreuses.

Se connecter avec chaque profil

Le seul test valable consiste à ouvrir une session avec un compte de chaque rôle et à parcourir l'interface. Les fonctions attendues doivent être présentes et opérationnelles, les autres absentes. Cette vérification révèle immédiatement les incohérences entre les droits et les menus. Elle doit être menée après chaque modification et après chaque mise à jour importante. Créer un compte de test par rôle, conservé en permanence, facilite grandement l'exercice. Ces comptes doivent avoir des mots de passe robustes comme les autres.

Tester l'accès direct aux pages retirées

Saisir directement l'adresse d'une page dont l'entrée a été masquée vérifie que le contrôle d'accès fonctionne. Un affichage normal signale que la protection n'existe pas. Ce test doit couvrir chaque page retirée, ce qui suppose d'en tenir la liste. Il prend quelques minutes et il constitue le contrôle le plus important de tout le dispositif. Il révèle régulièrement des extensions qui ne vérifient rien. Son omission est la cause habituelle des fausses protections.

Contrôler après l'ajout d'une extension

Chaque extension installée ajoute ses menus et parfois ses propres rôles, ce qui défait progressivement le travail effectué. Un contrôle systématique après installation permet de traiter immédiatement les ajouts. Cette discipline évite de se retrouver deux ans plus tard avec une administration aussi encombrée qu'au départ. La liste des menus par rôle peut être comparée automatiquement à une référence enregistrée. Ce contrôle automatisé demande un développement modeste. Il se justifie sur les sites comptant de nombreux contributeurs.

Revoir les comptes périodiquement

Les comptes des personnes ayant quitté l'entreprise ou terminé leur mission doivent être désactivés, ce qui est régulièrement oublié. Une revue trimestrielle de la liste des utilisateurs, avec vérification de leur rôle, prend un quart d'heure. Elle révèle presque toujours des comptes obsolètes ou surdimensionnés. Sur les prestataires externes, prévoir une date de fin dès la création évite l'accumulation. Cette hygiène élémentaire dépasse largement en efficacité les mesures techniques sophistiquées. Elle constitue le point de départ de toute politique de sécurité.

Journaliser les actions sensibles

Enregistrer les changements de rôle, les activations d'extension et les modifications de réglages permet de comprendre ce qui s'est passé après un incident. Plusieurs extensions fournissent cette journalisation sans développement. La conservation doit rester limitée dans le temps et les journaux protégés d'une suppression. Ces traces servent aussi à identifier un besoin de formation plutôt qu'une malveillance, les erreurs étant bien plus fréquentes que les actes délibérés. Cette lecture bienveillante des journaux est celle qui produit le plus de valeur. Elle améliore les pratiques plutôt que de chercher des coupables.

Prévoir une page d'options dédiée

Lorsque plusieurs réglages personnalisés doivent rester accessibles à un profil précis, les regrouper dans une page unique vaut mieux que de multiplier les entrées. La construction d'une telle page est décrite dans notre article sur la manière de créer une page d'options d'administration avec l'API Settings. Cette page porte son propre contrôle de droits, ce qui simplifie la gestion. Elle permet également de présenter les réglages avec un vocabulaire compréhensible par les utilisateurs. Ce travail de présentation réduit sensiblement les sollicitations au support. Il constitue l'aboutissement naturel d'une administration bien pensée. Il suppose de reprendre les libellés fournis par les extensions, souvent traduits mot à mot et incompréhensibles pour qui ne connaît pas l'outil d'origine.