# WordPress 7.0 resserre les permissions du Site Editor : la revue à refaire

> WordPress 7.0 affine le contrôle d'accès à l'éditeur de site par capacité plutôt que par rôle global. Ce que cela change concrètement pour les sites multi-rôles.

- Auteur : Clément Hadrot
- Publié le : 2026-06-19
- Mis à jour le : 2026-06-19
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/wordpress-70-permissions-site-editor/

## L’essentiel

- Le contrôle passe par des capacités plus granulaires que par le passé
- Un rôle personnalisé mal audité peut perdre un accès qu'il avait auparavant
- La revue des rôles doit précéder la mise à jour, pas la suivre

WordPress 7.0 fait évoluer le contrôle d'accès à l'éditeur de site vers un système de capacités plus granulaire, en complément du contrôle par rôle qui prévalait jusqu'ici. Cet article ne couvre pas les changements PHP 8.4 du cœur apportés dans la même période, uniquement ce qui concerne directement les permissions d'accès au Site Editor.

Pour un site qui distribue des accès différenciés — un rédacteur qui ne doit toucher qu'au contenu des articles, un intégrateur qui gère les gabarits, un administrateur qui garde la main sur les styles globaux — cette évolution demande une revue explicite des rôles avant la mise à jour, pas seulement une vérification après coup.

## Nouveautés classées par impact

### Impact élevé : la séparation entre édition de contenu et édition de gabarit

Historiquement, l'accès à l'éditeur de site reposait largement sur la capacité `edit_theme_options`, qui donnait un accès global à l'ensemble de ses fonctionnalités — gabarits, parties de gabarit, styles globaux — sans distinction fine. WordPress 7.0 introduit des capacités plus spécifiques, permettant par exemple d'autoriser un rôle à modifier des parties de gabarit sans lui donner accès aux styles globaux du site. Un rôle personnalisé construit avant cette version, qui s'appuyait uniquement sur `edit_theme_options` pour donner un accès complet à l'éditeur de site, doit être revu pour vérifier qu'il conserve bien l'étendue d'accès prévue à l'origine, ni plus restreinte, ni plus large que voulu.

> L'essentiel à retenir : Le contrôle passe par des capacités plus granulaires que par le passé ; Un rôle personnalisé mal audité peut perdre un accès qu'il avait auparavant ; La revue des rôles doit précéder la mise à jour, pas la suivre

### Impact moyen : l'audit des rôles personnalisés existants

Les extensions de gestion de rôles qui définissent des capacités personnalisées autour de l'éditeur de site doivent être revues pour vérifier leur compatibilité avec ce système plus fin. Une extension qui vérifiait uniquement la présence de `edit_theme_options` pour autoriser une action continue de fonctionner, mais peut désormais autoriser des actions plus larges que prévu si le rôle a été redéfini entre-temps avec les nouvelles capacités plus fines sans que l'extension en tienne compte.

### Impact faible : l'affichage de l'interface selon les capacités

Les onglets et panneaux de l'éditeur de site s'affichent désormais de façon plus cohérente avec les capacités réellement accordées à l'utilisateur connecté : un onglet auquel l'utilisateur n'a pas accès n'apparaît simplement plus, plutôt que d'apparaître puis de refuser l'action au clic. Ce changement améliore l'expérience utilisateur sans modifier le comportement de fond attendu par les extensions déjà correctement vérifiées côté capacités.

## Ce qu'il faut vérifier avant de mettre à jour un site multi-rôles

- Lister tous les rôles personnalisés du site et les capacités précises qui leur sont attribuées en lien avec l'éditeur de site.
- Identifier les extensions qui contrôlent elles-mêmes l'accès à certaines fonctionnalités de l'éditeur de site par une vérification de capacité codée en dur.
- Tester, sur un environnement de test mis à jour vers WordPress 7.0, la connexion avec chaque rôle concerné pour confirmer que l'étendue d'accès reste celle prévue.

## Un exemple concret de revue à faire

Sur un site où un rôle « intégrateur » avait été créé avec la capacité `edit_theme_options` pour lui permettre de modifier les gabarits sans toucher aux styles globaux — une distinction jusque-là purement conventionnelle, non appliquée techniquement — la mise à jour vers WordPress 7.0 est l'occasion de rendre cette séparation réelle, en attribuant les capacités plus fines correspondant exactement à cette intention plutôt qu'en conservant l'ancienne capacité globale par habitude.

> Sur les sites à plusieurs rôles qu'on gère, le principe qu'on applique à chaque montée de version majeure touchant les permissions : revoir les rôles avant la mise à jour, jamais après un incident d'accès signalé par un client.

## En résumé

WordPress 7.0 ne retire pas d'accès par surprise, mais offre un contrôle plus fin qui redistribue les capacités liées à l'éditeur de site. Sur un site qui gère plusieurs rôles avec des besoins d'accès différenciés, cette évolution mérite une revue explicite avant mise à jour, pour transformer une distinction jusque-là seulement conventionnelle en une séparation réellement appliquée par le système de permissions.