Que faire des rôles Drupal recopiés tels quels lors d’une migration vers WordPress

Comment savoir si un rôle recréé par prudence est encore un rôle nécessaire ? C’est la question qu’aurait dû se poser un développeur chargé de reprendre un site institutionnel initialement construit sous Drupal, avant de le migrer vers WordPress. La migration du contenu éditorial lui-même, gérée par un script d’import, ne pose pas de problème particulier et ne fait pas l’objet de cet article. Le point de friction se situe ailleurs : la gestion des permissions.

Drupal fonctionne avec un système de rôles et de permissions granulaire, où chaque rôle peut se voir attribuer des dizaines de permissions indépendantes (« administrer les blocs », « créer du contenu de type article », « voir le contenu non publié »). Le site comptait six rôles distincts : administrateur, éditeur en chef, rédacteur, modérateur de commentaires, contributeur externe et invité. Plutôt que d’analyser ce que chacun faisait réellement, le développeur a recréé six rôles WordPress équivalents, en leur attribuant par prudence un ensemble de capacités volontairement large, « pour ne rien casser ».

Le problème d’une transposition mécanique entre deux systèmes différents

Un rôle Drupal et un rôle WordPress ne se recouvrent jamais exactement, parce que les deux systèmes ne découpent pas les permissions de la même façon. Une permission Drupal comme « administrer le contenu » peut correspondre, selon le contexte, à une combinaison de plusieurs capacités WordPress (edit_others_posts, publish_posts, delete_others_posts). En recopiant l’intitulé du rôle sans analyser sa fonction réelle, on obtient souvent un rôle WordPress bien plus permissif que ce que l’équivalent Drupal accordait.

Ce que l’audit a révélé six mois plus tard

Un audit mené six mois après la migration, à l’aide d’une simple liste des rôles actifs, a montré que quatre des six rôles recréés n’étaient en réalité jamais utilisés : le rôle « contributeur externe » n’avait plus aucun compte associé depuis la migration, et le rôle « modérateur de commentaires » disposait de la capacité edit_others_posts, héritée par erreur du rôle éditeur Drupal dont il s’inspirait, alors que sa seule fonction réelle était de valider ou refuser des commentaires.

wp role list --fields=name,role

Cette commande, croisée avec un export des comptes utilisateurs actifs par rôle, a permis de repérer en quelques minutes les rôles fantômes et les capacités excessives, sans avoir à consulter la documentation Drupal d’origine.

Reconstruire les rôles à partir des besoins observés, pas des intitulés hérités

La correction a consisté à repartir des tâches réellement effectuées par chaque profil d’utilisateur observé sur les trois derniers mois d’usage réel du site WordPress, plutôt que des intitulés hérités de Drupal :

$role = get_role( 'moderateur_commentaires' );
$role->remove_cap( 'edit_others_posts' );
$role->add_cap( 'moderate_comments' );

Le rôle « contributeur externe », sans compte actif, a simplement été supprimé via remove_role(), après vérification qu’aucun contenu existant ne dépendait de son existence.

Documenter chaque capacité au moment de la création du rôle

Pour éviter de reproduire la même dérive à la prochaine migration, chaque rôle personnalisé créé sur ce site est désormais accompagné d’un court commentaire, dans le code qui le déclare, précisant la raison de chaque capacité attribuée. Ce n’est pas un luxe documentaire : c’est ce qui permettra, dans deux ou trois ans, à un autre développeur de comprendre pourquoi telle capacité a été ajoutée, plutôt que de la recopier par prudence dans un futur rôle.

Ce qu’il faut retenir d’une migration entre deux systèmes de permissions

• Un intitulé de rôle ne dit rien de ce qu’il autorise réellement : il faut comparer les capacités une par une.
• Un rôle recréé « pour ne rien casser » finit souvent par accorder plus de droits que l’original.
• Un audit des rôles actifs, quelques mois après une migration, révèle presque toujours des rôles inutilisés.

Une migration de plateforme est le moment idéal pour redéfinir des rôles au plus juste, pas pour reconduire par prudence une hiérarchie de permissions héritée d’un système différent.

En résumé

Recopier des rôles d’un système à l’autre sans les auditer revient à transposer une logique de permissions qui ne correspond à aucun des deux systèmes. Sur ce site, quatre rôles sur six se sont révélés inutiles ou trop permissifs, corrigés en quelques dizaines de lignes de code une fois le vrai usage observé.