En un peu plus d’un an, l’écosystème WordPress est passé de premières expérimentations MCP isolées à un registre natif de capacités avec l’Abilities API, puis à des intégrations concrètes comme celle d’Elementor permettant à un agent de composer directement des pages. Cette évolution rapide a un revers : de plus en plus de sites exposent désormais, souvent sans audit formel, un ensemble de capacités à des agents IA capables d’agir en autonomie partielle sur le contenu, les réglages ou les données des visiteurs. Ce dernier article de notre série sur l’IA appliquée à WordPress fait le point sur les garde-fous à poser avant d’aller plus loin.
Trois couches de contrôle se dégagent des retours d’expérience accumulés depuis l’apparition des premiers connecteurs MCP : les permissions, la journalisation, et la conformité au RGPD dès que des données personnelles entrent dans le périmètre de l’agent.
Permissions : ne jamais dépasser les droits humains
Le principe qui doit rester non négociable, quel que soit le protocole utilisé, est simple : un agent IA ne doit jamais disposer de droits supérieurs à ceux de l’utilisateur ou du jeton d’authentification qui l’a connecté au site. Chaque ability déclarée via wp_register_ability() doit porter un permission_callback restrictif et spécifique à l’action concernée, plutôt qu’une vérification générique comme current_user_can( 'read' ) appliquée par facilité à toutes les capacités du site.
wp_register_ability( 'mon-extension/supprimer-commentaire', array(
'label' => __( 'Supprimer un commentaire', 'mon-extension' ),
'execute_callback' => 'mon_extension_supprimer_commentaire',
'permission_callback' => function ( $params ) {
return current_user_can( 'moderate_comments' )
&& ! mon_extension_action_sensible_bloquee( 'suppression' );
},
) );Cette dernière condition illustre un réflexe recommandé pour les actions les plus sensibles : au-delà de la capacité WordPress classique, prévoir un interrupteur global qui permet de désactiver temporairement certaines catégories d’actions déclenchables par un agent, sans devoir désinstaller l’intégration entière en cas de doute.
Journalisation : la confiance se construit sur la traçabilité
Contrairement à une action déclenchée manuellement par un administrateur, une action initiée par un agent IA mérite une journalisation systématique, distincte des journaux WordPress classiques : quelle capacité a été invoquée, avec quels paramètres, par quel agent ou quelle session, et avec quel résultat. Cette traçabilité, absente de beaucoup des premières intégrations expérimentales, devient indispensable dès qu’un agent dispose de capacités qui modifient des données plutôt que de simplement les consulter.
add_action( 'wp_ability_executed', function ( $ability_id, $params, $resultat, $contexte ) {
error_log( wp_json_encode( array(
'ability' => $ability_id,
'agent' => $contexte['agent_id'] ?? 'inconnu',
'horodatage'=> current_time( 'mysql' ),
'succes' => ! is_wp_error( $resultat ),
) ) );
}, 10, 4 );Au-delà du simple débogage, ce journal sert de base à une revue régulière des actions effectuées par les agents connectés, un contrôle a posteriori qui complète la vérification a priori des permissions, sans s’y substituer.
RGPD : l’agent n’échappe à aucune obligation existante
Dès qu’une capacité exposée à un agent IA donne accès à des données à caractère personnel — coordonnées de commentateurs, adresses de livraison, historiques de commande — les obligations du RGPD s’appliquent exactement comme pour tout autre traitement automatisé, sans exception liée à la nature IA du mécanisme. Plusieurs points méritent une attention particulière dans ce contexte spécifique :
- Vérifier si les données transmises au modèle transitent par un service situé hors de l’Union européenne, et documenter cette base légale de transfert le cas échéant
- Limiter strictement le périmètre des données personnelles accessibles à une ability à ce qui est nécessaire à sa fonction, conformément au principe de minimisation
- Prévoir la possibilité d’exclure certaines catégories de données du contexte fourni à un agent, en particulier pour les capacités de type recherche ou résumé qui pourraient autrement inclure des informations sensibles sans discernement
- Documenter ces traitements dans le registre des activités de traitement, au même titre que toute autre intégration tierce du site
Un agent IA qui accède aux données de vos visiteurs reste un sous-traitant au sens du RGPD, même quand l’interface donne l’impression d’une simple conversation.
En résumé
L’essor rapide des agents IA capables d’agir sur un site WordPress, porté par l’Abilities API et les connecteurs MCP apparus depuis 2025, impose de traiter ces intégrations avec la même rigueur qu’une API exposée publiquement : permissions strictes et spécifiques à chaque action, journalisation systématique des actions effectuées, et conformité RGPD dès que des données personnelles entrent dans le périmètre. Ces trois couches ne ralentissent pas l’innovation, elles la rendent simplement soutenable dans la durée, à mesure que ces agents gagnent en autonomie sur des sites en production.
