# Encadrer les fonctions exposées par une ability WordPress avec un enum de niveaux de risque

> Avant d'autoriser un agent IA à appeler une fonction WordPress via une ability, classez-la par niveau de risque. Une simple énumération suffit à structurer la décision.

- Auteur : Clément Hadrot
- Publié le : 2025-10-05
- Mis à jour le : 2025-10-05
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/enum-niveaux-risque-abilities-wordpress/

## L’essentiel

- Toute ability n'a pas le même impact en cas d'appel malveillant ou erroné
- Un niveau de risque explicite facilite la décision d'autorisation automatique ou manuelle
- La classification doit vivre à côté du code, pas dans un tableau externe oublié

Trois catégories couvrent la quasi-totalité des cas rencontrés en pratique : une ability qui lit des données sans les modifier, une ability qui écrit mais dont l'effet reste réversible (mettre à jour un statut, ajouter une métadonnée), et une ability dont l'effet est irréversible ou coûteux à annuler (envoyer un courriel, déclencher un remboursement, supprimer un contenu). Cette hiérarchie simple change complètement la façon dont on encadre l'accès d'un agent IA à ces fonctions.

Le projet Abilities API, disponible sous forme d'extension distincte en attendant sa fusion prévue dans le cœur de WordPress avec la version 6.9, propose un mécanisme d'enregistrement structuré pour exposer des fonctions à un agent externe via un protocole comme MCP. Mais le mécanisme d'enregistrement seul ne dit rien du niveau de prudence à appliquer à chaque appel : c'est aux développeurs d'ajouter cette couche de classification.

## Pourquoi une simple liste d'abilities ne suffit pas

Un agent connecté à un site via une extension qui expose des abilities voit, du point de vue du protocole, une liste plate de fonctions disponibles avec leur nom, leur description et leur schéma d'entrée. Rien dans cette structure ne distingue nativement une fonction qui liste des articles publiés d'une fonction qui supprime un utilisateur. Sans classification explicite côté développeur, l'agent (ou l'humain qui configure les autorisations de l'agent) doit deviner l'impact de chaque appel à partir du seul nom de la fonction.

Cette ambiguïté devient un problème concret dès qu'un site expose plusieurs dizaines d'abilities : certaines proviennent du cœur, d'autres d'extensions tierces, chacune nommée selon les conventions de son auteur. Un enum de risque appliqué de façon homogène à l'enregistrement corrige ce flou.

## Définir l'énumération

Une énumération PHP native (disponible depuis PHP 8.1) convient bien à ce cas d'usage : elle limite les valeurs possibles et rend le code auto-documenté.

> L'essentiel à retenir : Toute ability n'a pas le même impact en cas d'appel malveillant ou erroné ; Un niveau de risque explicite facilite la décision d'autorisation automatique ou manuelle ; La classification doit vivre à côté du code, pas dans un tableau externe oublié

```
enum NiveauRisqueAbility: string
{
    case LectureSeule = 'lecture_seule';
    case EcritureReversible = 'ecriture_reversible';
    case EcritureIrreversible = 'ecriture_irreversible';
}
```

Chaque enregistrement d'ability porte alors ce niveau dans ses métadonnées, en plus des champs habituels de nom, description et schéma d'entrée :

```
wp_register_ability('mon-plugin/lister-commandes-recentes', [
    'label'       => __('Lister les commandes récentes', 'mon-plugin'),
    'description' => __('Retourne les 20 dernières commandes sans données de paiement.', 'mon-plugin'),
    'meta'        => [
        'niveau_risque' => NiveauRisqueAbility::LectureSeule->value,
    ],
    'execute_callback' => 'mon_plugin_lister_commandes_recentes',
]);
```

## Faire respecter la classification à l'exécution

Une classification qui n'existe que dans les métadonnées reste décorative si rien ne la contrôle réellement. Le point d'application logique se situe dans le rappel d'autorisation associé à chaque ability : avant d'exécuter la fonction, le code vérifie le niveau de risque et applique une règle différente selon le cas.

- Lecture seule : exécution automatique si l'agent dispose d'un jeton valide pour le contexte demandé
- Écriture réversible : exécution automatique avec journalisation systématique de l'appel
- Écriture irréversible : exécution refusée par défaut, validation humaine explicite requise avant chaque appel

## Le cas des abilities fournies par des extensions tierces

Une extension tierce qui enregistre ses propres abilities ne connaît pas forcément cette convention de classification. Pour éviter qu'une fonction dangereuse échappe à la règle par simple absence de métadonnée, un filtre appliqué à la liste complète des abilities enregistrées permet d'imposer un niveau par défaut prudent (écriture irréversible) à toute ability qui ne déclare rien explicitement, plutôt que de l'autoriser par défaut.

### Documenter le choix, pas seulement le coder

Un commentaire court à côté de chaque enregistrement d'ability, expliquant pourquoi ce niveau a été choisi, évite qu'un développeur suivant change la valeur sans comprendre l'enjeu. Cette classification vit dans le code source, versionnée avec lui, et non dans un tableau Excel séparé qui se désynchronise à la première évolution du plugin.

> Une ability sans niveau de risque explicite doit être traitée, par défaut, comme la plus dangereuse possible : le silence sur l'impact ne dispense jamais de la prudence.

## En résumé

Trois niveaux de risque, une énumération PHP, un rappel d'autorisation qui applique la règle en fonction de la valeur : ce dispositif reste volontairement simple à mettre en œuvre, mais il transforme une liste opaque de fonctions exposées en un ensemble d'autorisations lisibles et défendables. À mesure que le nombre d'abilities exposées par un site grandit, cette classification devient la seule façon raisonnable de garder le contrôle sur ce qu'un agent IA peut réellement déclencher.