Depuis ses débuts, le système de capacités de WordPress répond à une question précise et une seule : cet utilisateur a-t-il le droit de faire cette action ? La fonction current_user_can( 'edit_posts' ) vérifie un rôle, une capacité, parfois un contexte via map_meta_cap pour des vérifications plus fines (l’auteur de l’article, son statut de publication). Ce modèle a fait ses preuves pendant deux décennies parce qu’il correspondait à une réalité stable : une personne, connectée avec son compte, agit directement sur le site.
L’arrivée d’agents IA capables d’agir au nom d’un utilisateur, que ce soit via un plugin d’automatisation, un serveur MCP connecté au site, ou une fonctionnalité native intégrée au cœur de WordPress, introduit une situation que ce modèle n’a jamais eu à couvrir : l’action est techniquement exécutée avec les droits d’un utilisateur humain, mais la décision de l’exécuter n’a pas été prise par cet humain, elle l’a été par un agent interprétant une consigne, avec une marge d’erreur ou d’interprétation que le système de capacités ne mesure jamais.
Ce que current_user_can ne demande jamais
La fonction current_user_can ne pose que la question du « qui ». Elle ignore complètement trois autres dimensions, devenues critiques dès qu’un agent agit dans la boucle : le « comment » (cette action a-t-elle été demandée explicitement, ou déduite par l’agent d’une consigne plus large), le « quand » (cette action fait-elle partie d’une séquence anormalement longue ou rapide, révélatrice d’une dérive), et le « pourquoi » (quelle tâche originelle, formulée par un humain, a conduit à cet appel précis).
Un administrateur connecté qui clique lui-même sur « supprimer 300 articles » a pris une décision consciente, action par action, avec la possibilité de s’arrêter à tout moment en observant le résultat. Un agent auquel on a donné accès aux mêmes capacités administrateur et à qui l’on a dit « fais le ménage » peut exécuter la même suppression de 300 articles en une fraction de seconde, sans qu’aucun des garde-fous cognitifs qui ralentissent un humain (la relecture, l’hésitation, le doute) n’intervienne jamais.
Premier ajout : le contexte de la demande
Le premier élément à ajouter au modèle de capacités est la traçabilité du contexte qui a mené à l’action : quelle tâche, formulée en langage naturel par un humain, a conduit l’agent à appeler cette fonction précise. Cette information ne se substitue pas à current_user_can, elle s’y ajoute, sous la forme d’un journal structuré associé à chaque appel :
function monsite_verifier_capacite_agent( $capacite, $agent_id, $tache_origine ) {
if ( ! current_user_can( $capacite ) ) {
return false;
}
// On journalise systématiquement le contexte, même quand l'action est autorisée.
monsite_journaliser_action_agent( array(
'capacite' => $capacite,
'agent_id' => $agent_id,
'tache_origine' => $tache_origine,
'horodatage' => current_time( 'mysql' ),
) );
return true;
}Sans cette traçabilité, une action problématique exécutée par un agent est indiscernable, dans les journaux natifs de WordPress, d’une action identique effectuée directement par l’humain propriétaire du compte. Reconstituer un incident devient alors presque impossible : le journal d’activité montre « admin a supprimé l’article X », sans jamais révéler que cette suppression provenait en réalité d’une interprétation erronée d’un agent.
Deuxième ajout : la confirmation explicite au-delà d’un seuil
Le deuxième ajout consiste à introduire une notion que current_user_can ne connaît pas : le volume et la fréquence des actions. Une capacité accordée pour « modifier un article » ne devrait pas s’exercer implicitement de la même façon pour un article isolé que pour trois cents articles enchaînés en quelques secondes. Un compteur simple, associé à un seuil, permet de distinguer ces deux situations :
function monsite_action_depasse_seuil( $agent_id, $capacite ) {
$compte = monsite_compter_actions_recentes( $agent_id, $capacite, MINUTE_IN_SECONDS * 5 );
return $compte > 20; // seuil à ajuster selon le contexte du site
}Au-delà de ce seuil, l’action bascule d’une exécution automatique à une mise en attente de confirmation humaine, exactement comme on le ferait pour un virement bancaire dépassant un certain montant. Ce n’est pas la capacité elle-même qui change, c’est le mode d’exécution qui s’adapte à l’ampleur de ce qui est demandé.
Troisième ajout : des capacités dédiées aux agents, distinctes de celles des humains
Le troisième ajout, plus structurel, consiste à ne jamais faire agir un agent avec les capacités brutes d’un compte administrateur humain, même quand cet agent a été connecté par un administrateur. La bonne pratique consiste à créer des capacités spécifiques, nommées explicitement pour un usage agentique, plutôt que de réutiliser manage_options ou delete_posts tels quels :
| Capacité humaine existante | Capacité agent équivalente et restreinte |
|---|---|
edit_posts | agent_edit_posts_draft_only (jamais de publication directe) |
delete_posts | absente : un agent ne supprime jamais, il propose une liste à valider |
manage_options | absente : aucun agent ne modifie les réglages globaux du site |
Le système de capacités de WordPress a été pensé pour ralentir un humain qui outrepasserait son rôle. Il n’a jamais été pensé pour ralentir un agent qui exécute une consigne mal interprétée en une fraction de seconde.
Notion à retenir : ce que ces ajouts ne remplacent pas
Ces trois ajouts, contexte, seuil de confirmation, capacités dédiées, ne remplacent à aucun moment le système de capacités natif de WordPress : ils s’y superposent, comme une couche de contrôle supplémentaire spécifique aux agents. La vérification current_user_can reste indispensable comme première barrière, mais elle ne suffit plus, seule, à couvrir un scénario où l’exécutant de l’action n’est plus un humain conscient de chacun de ses gestes, mais un système qui interprète une intention et agit en conséquence, potentiellement à grande vitesse et à grande échelle.
Pour aller plus loin
Cette réflexion rejoint des travaux plus larges en cours dans l’écosystème WordPress autour de l’exposition de capacités aux agents, qui viseraient une déclaration plus explicite des actions qu’un site expose à des consommateurs externes, humains ou agents. Le modèle de capacités hérité, construit pour des humains, n’est pas caduc, mais il doit désormais être complété par une couche consciente de la spécificité des agents : leur vitesse d’exécution, leur absence d’hésitation, et la distance qui sépare la consigne donnée de l’action réellement exécutée.
