Un rôle dédié plutôt qu’un compte administrateur partagé

Combien d’intégrations tierces connectées à un site WordPress utilisent encore, aujourd’hui, le même compte administrateur que celui de l’équipe éditoriale ? C’est la question qu’il vaut la peine de poser avant d’ajouter une nouvelle synchronisation avec un CRM, un outil d’emailing ou une extension de facturation. La réponse est trop souvent « toutes », par simplicité au moment de la configuration initiale, et cette simplicité coûte cher le jour où l’une de ces intégrations est compromise.

Un compte administrateur donne accès à soixante-huit capacités par défaut sur une installation WordPress standard : gestion des extensions, des thèmes, des utilisateurs, des réglages, et bien sûr la création et l’édition de tout contenu. Une intégration qui se contente de lire des commandes ou d’écrire des statuts de livraison n’a besoin, dans l’immense majorité des cas, que d’une poignée de ces capacités. Voici la checklist pour construire un rôle dédié, restreint au strict nécessaire, pour chaque intégration tierce d’un projet.

Pourquoi le compte partagé pose un problème structurel

Au-delà du risque de sécurité immédiat, un compte administrateur partagé entre plusieurs usages rend impossible toute forme de traçabilité fiable. Le journal d’activité de WordPress enregistre les actions par identifiant d’utilisateur : si l’intégration de paiement, le plugin de sauvegarde automatisé et l’équipe éditoriale partagent le même compte, il devient impossible de déterminer après coup qui, ou quoi, a modifié un réglage critique un jour donné. En cas d’incident de sécurité, cette confusion ralentit considérablement le diagnostic.

• Un compte compromis expose l’intégralité des capacités du site, pas seulement celles réellement utilisées par l’intégration.
• La révocation d’accès d’une intégration devient risquée : changer le mot de passe du compte partagé casse aussi l’accès légitime de l’équipe éditoriale.
• Aucun audit de sécurité ne peut distinguer une action automatisée d’une action humaine sur ce compte.

Créer un rôle sur mesure avec add_role()

WordPress permet de créer un rôle personnalisé, avec un jeu de capacités choisi précisément, via la fonction add_role() :

function creer_role_integration_crm() {
    add_role( 'integration_crm', 'Intégration CRM', array(
        'read'                => true,
        'edit_posts'          => false,
        'upload_files'        => false,
        'lire_commandes'      => true,
        'ecrire_statut_crm'   => true,
    ) );
}
add_action( 'init', 'creer_role_integration_crm' );

Les capacités lire_commandes et ecrire_statut_crm sont des capacités personnalisées, définies par le projet lui-même, et non des capacités WordPress natives. Elles sont ensuite vérifiées explicitement dans le code de l’intégration, par exemple dans un permission_callback d’une route REST dédiée, plutôt que de s’appuyer sur des capacités génériques comme manage_options qui ouvriraient bien plus que nécessaire.

Checklist de création d’un rôle d’intégration

1. Lister précisément les actions que l’intégration doit effectuer (lire quel contenu, écrire quelle donnée).
2. Définir une ou deux capacités personnalisées qui couvrent exactement ces actions, pas plus.
3. Créer le rôle avec add_role(), en partant d’un tableau de capacités vide plutôt que d’un rôle existant copié.
4. Créer un compte utilisateur dédié à cette seule intégration, avec ce rôle et aucun autre.
5. Vérifier dans le code de l’intégration que chaque action sensible passe par current_user_can() sur la capacité personnalisée, jamais sur un test de rôle générique.

Retirer un rôle obsolète proprement

Un rôle personnalisé mal retiré peut laisser des comptes orphelins avec des capacités qui ne correspondent plus à rien. La fonction symétrique remove_role() doit être appelée lors de la désactivation de l’intégration correspondante, généralement via un hook de désactivation d’extension :

register_deactivation_hook( __FILE__, function() {
    remove_role( 'integration_crm' );
} );

Cette symétrie entre création et suppression évite l’accumulation de rôles fantômes sur un site qui a connu plusieurs générations d’intégrations tierces au fil des années.

Un rôle qui ne peut rien faire de plus que ce pour quoi il a été créé ne peut pas non plus faire de dégâts au-delà de ce périmètre en cas de compromission de ses identifiants.

Le cas des intégrations qui imposent leur propre compte

Certaines extensions tierces imposent la création d’un compte administrateur pour fonctionner, sans offrir d’alternative documentée. Dans ce cas, la checklist reste applicable en sens inverse : documenter précisément quelles capacités administrateur sont réellement utilisées par l’extension, envisager un rôle personnalisé qui les reproduit à l’identique, et tester en environnement de recette avant de retirer les droits d’administrateur complets en production. Ce travail supplémentaire est rarement gratuit, mais il élimine un point de compromission majeur du site.

Ce qu’on retient

Le compte administrateur partagé reste une habitude difficile à déraciner, souvent héritée de la mise en place initiale d’un site sans anticipation du nombre d’intégrations à venir. Chaque nouvelle intégration tierce mérite son propre rôle, taillé sur mesure, plutôt qu’un accès total dont l’ampleur ne sera jamais réellement utilisée ni justifiée.