Personnaliser le tableau de bord WordPress par profil utilisateur

L'écran d'accueil de l'administration WordPress affiche la même chose à tout le monde : des actualités du projet, un résumé de l'activité, un bloc de brouillon rapide, les notifications des extensions installées. Pour un administrateur, cet ensemble a du sens. Pour une personne dont le travail consiste à publier trois articles par mois, il constitue un mur d'informations sans rapport avec sa tâche, au milieu duquel les éléments réellement utiles se perdent. Adapter cet écran, et plus généralement l'interface, au rôle de chacun coûte peu de travail et change nettement l'expérience des contributeurs, tout en réduisant le volume de questions adressées au support.

Ce qui encombre l'écran par défaut

Avant de retirer quoi que ce soit, il vaut la peine de regarder ce qui est présent et à qui cela s'adresse. L'exercice fait apparaître que la majorité des blocs affichés concernent l'administration technique du site, activité qui ne relève pas des personnes qui rédigent. Cette inadéquation n'est pas un défaut de conception : le tableau de bord a été pensé pour un site géré par une seule personne, situation qui reste majoritaire. Sur un site à plusieurs contributeurs, l'adaptation devient nécessaire. Les réglages généraux de cette interface sont présentés dans notre article sur les options écran du menu WordPress.

Les actualités du projet

Un bloc affiche les publications du blog officiel et des événements de la communauté. Cette information intéresse les personnes qui suivent l'évolution du logiciel et personne d'autre. Elle occupe une place importante sur l'écran et elle est chargée depuis un service distant, ce qui ajoute une requête externe à chaque affichage. Son retrait est le premier geste à faire et il ne suscite jamais de regret. Il accélère au passage le chargement de l'écran d'accueil. Sur un serveur dont la sortie réseau est lente, cette seule requête distante retarde parfois l'affichage de plusieurs secondes.

Le brouillon rapide

Ce bloc permet de saisir un titre et quelques lignes pour créer un brouillon. Son usage réel est très faible, la plupart des rédacteurs passant directement par l'écran de création d'article. Il occupe pourtant une colonne entière. Le conserver ne pose pas de problème et le retirer libère de la place pour un contenu réellement utile. Il peut aussi être conservé pour les seuls rédacteurs, qui sont les seuls à pouvoir y trouver un intérêt.

Le résumé d'activité

Le bloc récapitulant le nombre d'articles, de pages et de commentaires a une valeur informative limitée et il affiche également la version du logiciel et le thème actif. Cette dernière information n'a rien à faire sous les yeux d'un contributeur externe, sans être secrète pour autant. Le bloc mérite d'être remplacé par un équivalent adapté au rôle, affichant par exemple le nombre d'articles en attente de relecture. C'est un bon exemple de bloc à reconstruire plutôt qu'à supprimer. Le remplacement demande une vingtaine de lignes et il transforme une information décorative en indicateur de travail.

Les notifications des extensions

Chaque extension installée ajoute volontiers ses propres messages, invitations à passer à une version payante, demandes d'évaluation, alertes de configuration. Sur un site comptant quinze extensions, ces messages occupent parfois la moitié de l'écran. Ils s'adressent à l'administrateur et sont incompréhensibles pour un contributeur, qui s'inquiète en voyant des avertissements. Leur masquage pour les rôles non administrateurs est probablement l'intervention la plus appréciée de toutes. Elle supprime d'un coup la principale source d'inquiétude des contributeurs occasionnels, qui interprètent chaque avertissement comme une panne dont ils seraient responsables.

Les blocs ajoutés par le thème

Certains thèmes commerciaux ajoutent un bloc de promotion de leurs autres produits ou un accès à leur documentation. Ces éléments relèvent de la même logique que les notifications d'extensions et se traitent de la même manière. Ils sont parfois plus difficiles à retirer, le thème n'employant pas toujours les mécanismes standards. Un retrait par les fonctions prévues à cet effet reste la première approche à essayer. Lorsqu'elle échoue, un masquage par une règle de style constitue une solution acceptable pour ce type de bloc purement promotionnel.

Ce qui manque

L'écran ne comporte en revanche rien qui aide un contributeur à savoir ce qu'il doit faire. Ni consigne éditoriale, ni rappel de la charte, ni liste de ses propres contenus en attente. Cette absence est plus problématique que l'encombrement, car elle laisse chacun se débrouiller. Ajouter un bloc répondant à ces besoins transforme un écran subi en outil de travail. C'est la partie la plus intéressante de l'exercice. Elle change la nature du travail : il ne s'agit plus de retirer du bruit mais de construire un outil adapté à une activité précise.

Adapter les blocs affichés

Le retrait et l'ajout de blocs reposent sur des fonctions prévues par le cœur, ce qui rend l'opération simple et pérenne.

Retirer un bloc existant

Une fonction permet de retirer un bloc en indiquant son identifiant, sa colonne et son contexte. Les identifiants des blocs natifs sont documentés et stables depuis longtemps. Le code se place dans le fichier de fonctions du thème enfant ou dans une extension maison, accroché à l'action appropriée. Quelques lignes suffisent à nettoyer l'écran, et l'opération est immédiatement réversible. Les identifiants se retrouvent facilement en inspectant le code de la page, chaque bloc portant le sien comme attribut.

Conditionner au rôle

Le retrait ne doit pas s'appliquer aux administrateurs, qui ont besoin de certaines de ces informations. Un test sur les capacités de l'utilisateur courant, plutôt que sur le nom de son rôle, constitue la bonne pratique. Raisonner en capacités permet au code de continuer à fonctionner lorsque des rôles personnalisés sont créés, ce qui arrive fréquemment. C'est une habitude à prendre dès la première intervention de ce type. Elle évite aussi les erreurs sur les rôles multiples, un utilisateur pouvant en cumuler plusieurs dans certaines configurations.

Ajouter un bloc utile

Une fonction symétrique permet d'enregistrer un bloc personnalisé, avec son titre et une fonction produisant son contenu. Un bloc affichant les consignes éditoriales, les contacts utiles et un lien vers la charte de publication répond à un besoin réel. Sa production ne demande que du HTML simple. Il peut être différencié selon le rôle, en affichant des informations techniques aux administrateurs et éditoriales aux rédacteurs. Un contenu modifiable depuis une page de réglages, plutôt qu'écrit en dur, permet au responsable éditorial de le tenir à jour sans intervention technique.

Afficher les contenus de l'utilisateur

Un bloc listant les articles de la personne connectée, avec leur statut, lui donne immédiatement une vue de son travail en cours. Cette information n'existe nulle part ailleurs sous cette forme et elle est celle qu'un rédacteur cherche en priorité. Sa construction demande une requête filtrée sur l'auteur et une boucle d'affichage. Y ajouter les commentaires en attente sur ces articles, lorsque le site en accepte, complète utilement la vue. C'est le bloc le plus rentable à développer, dans la lignée des personnalisations décrites dans notre article sur la manière d'ajouter une colonne personnalisée à la liste des articles.

Réorganiser les colonnes

L'ordre et la disposition des blocs sont mémorisés par utilisateur et modifiables par glisser déposer. Il est possible de définir une disposition par défaut pour les nouveaux utilisateurs, ce qui évite qu'ils ne découvrent un écran désordonné. Cette définition passe par les métadonnées de l'utilisateur et elle mérite d'être posée à la création du compte. Les personnes concernées restent libres de réorganiser ensuite. Cette liberté doit être préservée, une disposition imposée sans possibilité de modification étant mal vécue.

Masquer les notifications

Les messages des extensions s'affichent par une action commune, qu'il est possible de vider pour les utilisateurs non administrateurs. Cette intervention doit rester ciblée : masquer les notifications pour tout le monde reviendrait à ignorer des alertes de sécurité réelles. La bonne approche masque pour les rôles qui ne peuvent rien en faire et conserve pour ceux qui le peuvent. C'est un cas où la nuance compte. Il vaut mieux passer dix minutes à écrire une condition correcte que de masquer globalement et de découvrir six mois plus tard qu'une alerte importante n'a jamais été vue.

Filtrer les menus et l'écran d'arrivée

Le tableau de bord n'est qu'une partie du sujet. Le menu latéral et la page sur laquelle arrive l'utilisateur après connexion comptent autant dans la perception de l'interface.

Retirer les entrées inutiles

Le menu affiche des entrées que les capacités de l'utilisateur rendent parfois inopérantes, ainsi que des entrées ajoutées par des extensions dont il n'a pas l'usage. Une fonction permet de retirer une page de menu ou une sous page en indiquant son identifiant. Cette opération relève de l'ergonomie et non de la sécurité : retirer une entrée ne ferme pas l'accès à la page correspondante. La restriction réelle passe par les capacités, jamais par la disparition d'un lien. Cette confusion produit régulièrement des situations où l'on croit avoir sécurisé un accès en l'ayant simplement rendu moins visible.

Ne pas confondre avec les droits

Ce point mérite d'être insisté, car la confusion est fréquente et lourde de conséquences. Un utilisateur qui saisit directement l'adresse d'une page retirée du menu y accède si ses capacités le lui permettent. Le menu est une commodité d'affichage, le contrôle d'accès se fait ailleurs. Toute restriction réellement nécessaire doit passer par un ajustement des capacités du rôle, ce qui est un travail distinct. Les extensions de gestion de rôles rendent cet ajustement accessible sans écrire de code, à condition de savoir précisément ce que l'on veut interdire.

Choisir la page d'arrivée

Rediriger un rédacteur vers la liste de ses articles plutôt que vers le tableau de bord lui fait gagner un clic à chaque connexion et le place immédiatement dans son contexte de travail. Cette redirection se pose par un filtre sur la destination après connexion, en testant le rôle. Elle est probablement l'intervention au meilleur rapport entre effort et bénéfice perçu. Elle demande simplement de vérifier que la destination reste accessible en cas de changement de rôle. Un repli sur le tableau de bord, lorsque la destination souhaitée n'est pas accessible, ferme proprement ce cas.

Simplifier la barre d'administration

La barre affichée en haut du site public comporte des entrées techniques dont un contributeur n'a pas l'usage. Elle se nettoie par des fonctions dédiées, en conservant les liens réellement utiles comme la modification du contenu en cours de consultation. Ce lien est d'ailleurs l'une des fonctions les plus appréciées des rédacteurs, ce qui plaide pour ne pas masquer la barre entièrement. Le nettoyage doit rester sélectif. Retirer les entrées de mise à jour et de personnalisation, tout en conservant celle de modification, constitue un bon compromis pour un contributeur.

Les options d'écran

Chaque écran de liste propose des options permettant de choisir les colonnes affichées et le nombre d'éléments par page. Ces préférences sont mémorisées par utilisateur et il est possible d'en définir de meilleures par défaut. Un rédacteur découvrant une liste affichant vingt colonnes n'ira pas chercher ce réglage, alors qu'une valeur par défaut adaptée lui épargne le problème. Ce détail participe beaucoup à l'impression de simplicité. Il se règle une fois pour toutes en enregistrant les métadonnées correspondantes à la création des comptes.

Le pied de page de l'administration

La mention de la version du logiciel et le lien de remerciement peuvent être remplacés par une information plus utile, coordonnées du prestataire ou rappel de la procédure de demande d'assistance. Ce remplacement se fait par deux filtres simples. Il est apprécié des clients et il évite qu'une demande d'aide ne parte au mauvais endroit. C'est une touche discrète et efficace. Elle rappelle en permanence à qui s'adresser en cas de difficulté, ce qui évite les demandes envoyées à une adresse personnelle.

Mettre en place sans se piéger

Les personnalisations de ce type s'accumulent au fil des années et finissent par produire des comportements que plus personne n'explique. Quelques précautions évitent cette dérive.

Un seul emplacement

L'ensemble des personnalisations doit vivre au même endroit, extension maison ou fichier dédié inclus depuis le thème enfant. Les répartir entre le thème, une extension et un bout de code ajouté par une interface rend le diagnostic impossible. Cette discipline est facile à tenir dès le départ et très coûteuse à rétablir ensuite. Elle facilite aussi le transfert du site vers un autre prestataire. Un dossier unique contenant l'ensemble des adaptations se lit en dix minutes, là où des modifications dispersées demandent une journée d'exploration.

Préférer une extension maison

Placer ces personnalisations dans une petite extension plutôt que dans le thème garantit qu'elles survivent à un changement de thème. Une refonte graphique n'a aucune raison de faire réapparaître les actualités du projet sur le tableau de bord. Cette séparation entre présentation et comportement d'administration est une bonne pratique générale. Elle demande dix minutes de mise en place. Une extension d'une centaine de lignes, nommée explicitement, remplit parfaitement ce rôle et se désactive en un clic pour tester un comportement.

Tester avec chaque rôle

Une personnalisation conditionnée au rôle doit être vérifiée en se connectant réellement avec un compte de chaque type. Les extensions permettant de basculer temporairement d'identité rendent ce test immédiat. Les erreurs de condition, retirant un bloc aux administrateurs ou le laissant aux rédacteurs, sont fréquentes et invisibles depuis un compte administrateur. Ce test doit être refait après chaque modification. Il prend deux minutes et il évite de livrer une personnalisation qui ne fonctionne que pour son auteur.

Surveiller les alertes de sécurité

Masquer les notifications comporte un risque réel : un message signalant une extension vulnérable peut passer inaperçu. La parade consiste à ne masquer que pour les rôles non administrateurs et à consulter régulièrement l'écran dédié à la santé du site. Ce point est développé dans notre article sur la façon de lire les alertes de santé du site WordPress qui comptent vraiment.

Documenter les choix

Une note listant ce qui a été retiré, ajouté ou redirigé, et pour quels rôles, évite qu'un intervenant ultérieur ne cherche longtemps pourquoi l'interface ne ressemble pas à celle qu'il connaît. Cette note se place à côté du code, dans un commentaire en tête de fichier ou dans un fichier de documentation du projet. Elle tient en quinze lignes. Son absence transforme chaque reprise de site en enquête.

Demander leur avis aux utilisateurs

Les personnalisations les plus utiles ne sont pas celles que l'on imagine mais celles que les personnes concernées réclament. Une conversation de vingt minutes avec deux rédacteurs produit une liste de besoins précis, souvent très différente de ce qu'un développeur aurait supposé. Cette étape est la plus rentable de tout l'exercice et elle est presque toujours sautée. Elle a aussi le mérite de faire accepter les changements par ceux qui les subissent.