Members vs Kakapo Roles : gérer des droits qui tiennent vraiment

Un plugin de gestion des droits se juge à une seule question : le droit tient-il aussi quand personne ne passe par l'administration ? Une grande partie de ce qu'on appelle « masquer » ne modifie que l'affichage — les données restent exposées, à un appel de l'API REST près. Ce comparatif classe Members et Kakapo Roles selon ce critère.

La réponse courte

Members est un plugin de gestion des droits gratuit et bien établi : créer et modifier des rôles, attribuer des droits, protéger des contenus par rôle. Il est léger, répandu et suffisant pour la plupart des cas simples.

Kakapo Roles intervient à un niveau plus profond. Il ne gère pas seulement les rôles et les droits, mais aussi ce qu'un utilisateur voit tout court dans l'administration — menu d'administration, médiathèque, widgets, shortcodes —, et il applique explicitement les règles de visibilité dans l'API REST également. S'y ajoutent un journal des modifications, une corbeille pour les rôles supprimés et l'import/export.

En bref : qui veut créer des rôles et protéger des contenus ira loin avec Members, sans rien payer. Qui veut offrir à un client une administration épurée, documenter les droits de manière traçable ou éviter qu'une règle ne touche que l'interface sera mieux servi par Kakapo Roles.

Ce que les deux savent faire

• Créer, renommer et supprimer des rôles personnalisés
• Définir les droits par rôle, y compris ceux des types de contenu personnalisés
• Accorder des droits supplémentaires à certains utilisateurs ou leur en retirer
• Réserver des contenus à certains rôles
• Plusieurs rôles par utilisateur

Jusqu'ici, le choix est une affaire de goût. C'est en dessous que cela devient intéressant.

Où les deux diffèrent

La différence qui compte : masquer n'est pas verrouiller

Quand un article ne doit être visible que « pour certains rôles », il existe deux façons de le mettre en œuvre. La première le masque dans les listes et sur le site public. La seconde refuse l'accès — partout, y compris là où personne ne clique.

Cette différence n'est pas un détail. L'API REST de WordPress est accessible par défaut ; un appel à /wp-json/wp/v2/posts renvoie les articles en JSON, sans connexion. Une règle qui ne modifie que l'affichage y est sans effet — le contenu prévu « pour les membres uniquement » figure en clair dans la réponse.

C'est pourquoi Kakapo Roles applique aussi la règle de visibilité dans l'API REST. Cette seule ligne est ce qui permet de vérifier un plugin de gestion des droits : appelez une fois votre adresse protégée en JSON, en étant déconnecté. Si le contenu s'affiche, la règle ne protège rien.

Vous pouvez faire ce test avec n'importe quel plugin, y compris celui que vous utilisez actuellement : protéger un article, se déconnecter, appeler /wp-json/wp/v2/posts?search=…. Il prend une minute et en dit plus que n'importe quelle liste de fonctionnalités.

Le second piège : qui peut attribuer des droits ?

Un plugin de gestion des droits qui permet à quiconque a accès à son interface de s'attribuer davantage de droits s'annule lui-même. WordPress prévoit pour cela un garde-fou : get_editable_roles() détermine quels rôles une personne a le droit de modifier. Un plugin qui le contourne ouvre précisément la voie qu'il est censé fermer.

En mode réseau, une seconde question s'ajoute : les rôles y sont en partie définis à l'échelle du réseau. Qui les écrase depuis un sous-site les modifie pour tous les sites. Kakapo Roles respecte les deux — le garde-fou et la frontière entre site et réseau.

Quand Members est le meilleur choix

• Vous avez besoin de rôles et de droits, rien d'autre
• Le budget est de zéro
• Vous travaillez sur un seul site avec peu d'utilisateurs
• Vous voulez un plugin qui fait exactement une seule chose

Quand Kakapo Roles est le meilleur choix

• Vous confiez une administration à un client et voulez l'épurer — menu, médiathèque, widgets
• Les contenus protégés doivent l'être aussi via l'API REST
• Vous devez pouvoir prouver qui a reçu quel droit et quand
• Vous voulez construire une structure de droits une fois et la transférer vers d'autres sites
• Vous utilisez de toute façon d'autres plugins Kakapo et voulez une seule facture au lieu de cinq

Changement d'outil : ce qu'il faut faire

1. Notez quels rôles personnalisés existent et quels droits leur sont associés — une capture d'écran de la matrice suffit.
2. Créez une sauvegarde. Les droits sont stockés dans la base de données, et une fausse manœuvre touche tous les utilisateurs à la fois.
3. Installez Kakapo Roles et saisissez la clé de licence.
4. Recréez les rôles et comparez la matrice ligne par ligne avec vos notes.
5. Connectez-vous avec un utilisateur de test par rôle et vérifiez ce qu'il voit réellement.
6. Faites le test REST sur un contenu protégé.
7. Ce n'est qu'ensuite que vous désactivez l'ancien plugin — sans le supprimer, pendant deux semaines.

Deux plugins de gestion des droits actifs en même temps, c'est une mauvaise situation : les deux écrivent dans les mêmes rôles, et c'est le dernier à enregistrer qui l'emporte. Gardez la période de transition courte et, pendant ce temps, ne modifiez quelque chose que dans l'un des deux.

Questions fréquentes