# Restreindre une ability par rôle plutôt que par une permission globale unique

> Exposer une action à un agent IA ne veut pas dire l'ouvrir à n'importe quel rôle. Comment restreindre finement l'accès à une ability déjà déclarée selon le rôle de l'appelant.

- Auteur : Clément Hadrot
- Publié le : 2025-10-31
- Mis à jour le : 2025-10-31
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/restreindre-ability-par-role-plutot-que-permission-globale/

## L’essentiel

- Une ability doit vérifier le rôle réel de l'appelant, pas seulement sa capacité générique
- Un permission_callback trop permissif rend l'ability exploitable par tout compte connecté
- Restreindre par rôle limite la surface d'action d'un agent IA mal configuré

Une ability qui expose une action à un agent d'intelligence artificielle ne devrait jamais reposer sur la même logique de permission qu'un simple bouton d'administration cliqué par un humain. La différence tient à un détail souvent négligé : un agent IA appelle une ability de façon autonome, potentiellement en enchaînant plusieurs actions sans supervision humaine directe à chaque étape, ce qui rend une permission trop large bien plus risquée qu'elle ne le serait pour un clic isolé.

L'Abilities API, disponible depuis l'été 2025 sous forme d'extension officielle avant son intégration prévue au cœur de WordPress avec la version 6.9, permet de déclarer des actions structurées qu'un agent peut découvrir et invoquer. Ce billet ne traite pas la déclaration du schéma d'une ability elle-même, mais la façon de restreindre finement qui peut l'invoquer, une fois qu'elle existe déjà.

## Le piège d'une permission générique

Un premier réflexe consiste à protéger une ability avec une capacité générique déjà existante, par exemple `edit_posts`, sans se demander si cette capacité couvre réellement le contexte précis de l'action exposée. Une ability qui republie un article via une capacité aussi large que `edit_posts` devient invocable par n'importe quel compte auteur, alors que la republication d'un contenu déjà validé devrait rester réservée à un rôle éditorial plus restreint.

```
wp_register_ability( 'mon-extension/republier-article', [
    'label'       => 'Republier un article',
    'description' => 'Republie un article existant après relecture.',
    'permission_callback' => function () {
        return current_user_can( 'edit_posts' ); // Trop permissif
    },
    'execute_callback' => 'republier_article_callback',
] );
```

## Restreindre selon le rôle réel de l'appelant

> L'essentiel à retenir : Une ability doit vérifier le rôle réel de l'appelant, pas seulement sa capacité générique ; Un permission_callback trop permissif rend l'ability exploitable par tout compte connecté ; Restreindre par rôle limite la surface d'action d'un agent IA mal configuré

La correction consiste à vérifier explicitement le rôle attendu, plutôt qu'une capacité générique partagée par plusieurs rôles distincts. WordPress expose le rôle d'un utilisateur via son objet `WP_User`, ce qui permet une vérification précise, indépendante des capacités individuelles qui peuvent varier selon des extensions tierces installées sur le site.

```
wp_register_ability( 'mon-extension/republier-article', [
    'label'       => 'Republier un article',
    'description' => 'Republie un article existant après relecture éditoriale.',
    'permission_callback' => function () {
        $utilisateur = wp_get_current_user();
        return in_array( 'editor', (array) $utilisateur->roles, true )
            || in_array( 'administrator', (array) $utilisateur->roles, true );
    },
    'execute_callback' => 'republier_article_callback',
] );
```

## Aller plus loin : restreindre selon le contexte de l'appel, pas seulement le rôle

Le rôle seul ne suffit pas toujours. Une ability qui modifie une commande ne devrait être invocable, même par un éditeur, que sur des commandes qu'il est censé traiter — pas sur l'ensemble du site. Le `permission_callback` peut recevoir les arguments transmis à l'ability et vérifier une relation précise entre l'appelant et la ressource ciblée, plutôt qu'une simple appartenance à un rôle.

```
'permission_callback' => function ( $arguments ) {
    $utilisateur = wp_get_current_user();
    if ( ! in_array( 'gestionnaire_commandes', (array) $utilisateur->roles, true ) ) {
        return false;
    }
    $commande_id = absint( $arguments['commande_id'] ?? 0 );
    return $commande_id && current_user_can( 'edit_post', $commande_id );
},
```

## Pourquoi cette granularité compte davantage avec un agent IA

Un agent IA qui découvre les abilities disponibles sur un site peut, selon la façon dont il est instruit, enchaîner plusieurs invocations à la suite pour atteindre un objectif donné, sans qu'un humain ne valide chaque étape individuellement. Une permission trop large sur une seule ability suffit alors à élargir la surface d'action réelle de l'agent bien au-delà de ce que son opérateur avait anticipé. Restreindre chaque ability à son strict périmètre fonctionnel réduit ce risque, même si l'agent lui-même se comporte de façon parfaitement légitime — la restriction protège aussi contre une mauvaise configuration de l'agent, pas seulement contre une intention malveillante.

## Journaliser les invocations refusées

Pour détecter une tentative d'invocation inappropriée, même refusée, une journalisation dédiée aux appels rejetés par un `permission_callback` facilite le diagnostic a posteriori, en particulier lorsque plusieurs agents ou intégrations partagent le même site.

```
'permission_callback' => function ( $arguments ) {
    $autorise = verifier_permission_republication( $arguments );
    if ( ! $autorise ) {
        error_log( 'Ability refusée : republier-article pour utilisateur ' . get_current_user_id() );
    }
    return $autorise;
},
```

## Notion à retenir

Une ability bien conçue distingue toujours deux questions : qui a le droit d'invoquer cette action en général, et sur quelle ressource précise ce droit s'applique-t-il réellement. Se contenter d'une capacité générique existante répond à la première question de façon approximative, sans jamais traiter la seconde. Pour une extension qui expose des actions à un agent IA, cette granularité n'est pas un excès de prudence : elle correspond au niveau de contrôle que mériterait n'importe quelle action automatisée capable de s'enchaîner sans supervision directe.