Vue d’ensemble
Cette leçon éclaircit un point de sécurité central : la différence entre laisser l’IA exécuter du code PHP directement dans WordPress (via execute_php, une capacité propre à Novamira) et lui faire utiliser des abilities natives déclarées par les extensions. C’est cette distinction, et non l’IA elle-même, qui détermine le niveau de risque réel d’un site connecté à Claude.
execute_php : les clés de la caverne d’Ali Baba
Parmi les capacités de Novamira, execute_php permet à l’IA d’exécuter directement du code PHP — le langage de WordPress — sur le site. C’est un raccourci extrêmement permissif : même quand une extension ne déclare aucune ability, l’IA peut malgré tout agir dessus en devinant son fonctionnement (parcourir ses fichiers, sa base de données) et en injectant du code pour arriver à ses fins.
C’est ce type d’outil — execute_php, mais aussi par exemple wp_cli — qui explique la réputation de certains retours d’expérience négatifs sur l’IA et WordPress : la toute première expérience de connexion MCP de beaucoup d’utilisateurs, c’est justement de l’execute_php via Novamira, avec le risque de casse qui va avec. Ce n’est pas représentatif du fonctionnement d’un serveur MCP WordPress en général.
Abilities natives : un fonctionnement structurellement plus sûr
Quand une extension déclare de vraies abilities (ex. « créer un formulaire »), l’IA se contente d’appeler cet outil avec des paramètres structurés (un nom, des champs) — une opération de portée volontairement limitée qui ne peut pas, par construction, casser le site. La zone de danger se situe spécifiquement dans les super-capacités permissives type execute_php, pas dans les abilities elles-mêmes.
Démonstration : avant / après sur SureForms
Test 1 — sans abilities SureForms (via execute_php uniquement)
Conditions : les capacités MCP de SureForms ne sont pas activées (aucune ability visible dans l’Abilities Explorer pour cette extension). Prompt donné à Claude : créer un formulaire de demande de devis dans SureForms, en utilisant exclusivement execute_php, puis le publier et fournir un lien de partage instantané.
Résultat observé : le formulaire a été créé avec succès dans cet essai précis (mais un essai antérieur du même exercice, effectué par l’auteur de la leçon avant l’enregistrement, avait produit des anomalies : caractères bizarres dans les libellés de champs, lien de formulaire instantané mal formé). En déroulant l’historique des appels d’outils dans Claude, on observe de nombreux appels successifs à execute_php, chacun déversant un bloc de code conséquent : l’IA explore et devine le fonctionnement interne de SureForms (fichiers, base de données) avant de parvenir à produire le formulaire. Au total : six appels d’outils pour ce test.
Test 2 — avec abilities SureForms natives
Après restauration d’une sauvegarde du site pour repartir d’un état propre, les abilities SureForms sont activées (menu MCP des réglages SureForms, après installation du plugin officiel MCP Adapter requis par SureForms — cf. leçon 3/5). Vérification dans l’Abilities Explorer : les outils SureForms apparaissent bien, filtrables par extension.
Prompt donné à Claude : recréer le même formulaire de demande de devis, en interdisant explicitement l’usage d’execute_php — abilities SureForms natives uniquement.
Résultat : le formulaire a été créé en quelques secondes, avec un total de deux appels d’outils (contre six pour la méthode execute_php) — l’un des deux essais réalisés par l’auteur de la leçon n’a même nécessité qu’un seul appel, correspondant directement à l’ability create_form. En déroulant l’historique des appels, chaque appel correspond à un objet JSON structuré et propre (les paramètres du formulaire), sans code PHP généré à la volée.
Comparatif demandé à Claude entre les deux méthodes
Invité à comparer les deux approches, Claude a résumé les points suivants :
- Méthode execute_php : six appels d’outils, risque d’erreur élevé (mauvaise formation d’un nom, données mal insérées en base, formulaire potentiellement cassé), l’IA doit deviner le fonctionnement de l’extension à chaque étape.
- Méthode abilities natives : deux appels d’outils, risque d’erreur faible (jamais nul, mais très réduit), données envoyées sous forme structurée (JSON) que le site reçoit et traite nativement — pas de code deviné ni improvisé.
À retenir
- Le risque réel de « casser son site » avec l’IA ne vient pas de l’IA en général, mais du type d’outil utilisé : les capacités permissives comme execute_php (exécution de code arbitraire) sont la véritable zone de danger, pas les abilities natives déclarées par les extensions.
- Une ability native limite structurellement l’action de l’IA à une opération définie et validée par l’extension elle-même (ex. create_form) — elle ne peut pas improviser au-delà de ce périmètre.
- Plus l’écosystème WordPress généralisera la déclaration d’abilities natives par les extensions, plus les interactions IA ↔ WordPress deviendront stables, déterministes et prévisibles — c’est, selon la leçon, la vraie transformation à surveiller plutôt que la puissance brute d’outils comme execute_php.
- En pratique : privilégier systématiquement les abilities natives d’une extension quand elles existent, et ne recourir à execute_php qu’en dernier recours, en connaissance du risque que cela implique.