AI 1.3.0 : contrôlez l’exposition des capacités Avant d’ouvrir l’API
AI 1.3.0 ajoute des fonctions de traduction, de génération de slugs et de nouvelles extensions pour les développeurs. Le changement le plus important pour les intégrations externes concerne toutefois l’exposition des capacités WordPress. Après la mise à jour, cinq capacités ne sont plus enregistrées automatiquement pour les usages externes. Il faut activer explicitement l’expérience Custom Abilities. Voici ce que cela change concrètement pour un site WordPress, une agence ou une intégration connectée à un agent IA.
La version 1.3.0 du plugin AI pour WordPress a été publiée le 18 août 2026. Elle reste présentée comme une version expérimentale et s’appuie sur l’Abilities API pour rendre certaines fonctions découvrables et exécutables par WordPress, des intégrations REST ou des outils compatibles avec le protocole MCP. Le sujet n’est donc pas uniquement l’ajout de boutons IA dans l’éditeur. Il concerne aussi la frontière entre les fonctions internes du site et les fonctions rendues visibles à des systèmes externes.
La nuance est importante. Une capacité peut exister dans WordPress et être utilisable en PHP sans être exposée par l’API REST. Elle peut également être soumise à un callback de permission qui vérifie les droits de l’utilisateur courant. AI 1.3.0 ajoute un réglage administratif pour éviter que ses capacités personnalisées soient exposées sans décision explicite.
AI 1.3.0 introduit un verrou d’exposition
Dans les versions précédentes, les capacités concernées par le plugin AI pouvaient être enregistrées automatiquement pour les usages prévus par l’Abilities API. Avec AI 1.3.0, elles ne sont plus enregistrées automatiquement pour les usages externes. L’administrateur doit activer l’expérience Custom Abilities dans Réglages > AI > Admin Experiments.
L’activation concerne cinq identifiants : ai/get-post-details, ai/get-post-terms, core/read-settings, core/read-users et core/read-content. Les fonctions internes du plugin AI continuent de fonctionner sans cette activation. Le bouton contrôle donc principalement l’exposition destinée aux interfaces externes, notamment l’Abilities API et les intégrations MCP.
Quelles données peuvent devenir découvrables ?
Les cinq capacités ne présentent pas le même niveau de sensibilité. Les fonctions ai/get-post-details et ai/get-post-terms concernent le contexte éditorial utilisé par les fonctionnalités IA. core/read-content donne accès à du contenu WordPress selon ses paramètres et ses permissions. core/read-users concerne les utilisateurs et prévoit des garde-fous sur les champs sensibles. core/read-settings peut révéler des informations de configuration qui méritent une analyse particulière selon le site.
L’activation de Custom Abilities ne signifie pas qu’un agent obtient automatiquement un accès administrateur. Elle rend toutefois certaines capacités disponibles pour la découverte et l’exécution selon les mécanismes d’exposition et de permissions en place. Il faut donc raisonner en deux niveaux : ce qui est visible et ce qui peut réellement être exécuté.
La checklist après installation ou mise à jour
Après la mise à jour vers AI 1.3.0, commencez par vérifier si une intégration dépendait de l’enregistrement automatique des capacités. Si c’est le cas, activez Custom Abilities uniquement sur l’environnement nécessaire, puis testez le workflow avec le compte réellement utilisé. Ne validez pas le fonctionnement avec un compte administrateur si l’intégration finale doit fonctionner avec un rôle plus limité.
Déployer la configuration entre les environnements
AI 1.3.0 ajoute aussi l’import et l’export de réglages non sensibles dans un fichier JSON. Cette fonction peut faciliter le passage d’une configuration entre un environnement local, une recette et la production. Elle ne remplace pas une procédure de déploiement contrôlée. Les identifiants, clés API, jetons et autres valeurs sensibles sont exclus des exports et ne sont pas écrasés lors d’un import.
Un export de réglages ne constitue pas une preuve que l’intégration est sûre. Après import, contrôlez les capacités réellement enregistrées, les rôles associés, les connecteurs actifs et les journaux disponibles. Vérifiez aussi que l’environnement de production ne conserve pas une autorisation temporaire activée pour les tests.
Un nouveau contrôle à intégrer dans les audits de parc
Pour une agence qui maintient plusieurs sites, le risque principal n’est pas nécessairement une attaque immédiate. C’est plutôt l’absence de visibilité sur les capacités exposées, les différences entre les environnements et les réglages laissés actifs après un test. Une fiche de maintenance devrait désormais indiquer si Custom Abilities est activé, quelles intégrations l’utilisent et quels comptes peuvent exécuter les capacités concernées.
La version 1.3.0 marque une évolution utile : l’exposition des capacités IA devient une décision administrative explicite. Pour les sites simples sans intégration externe, laisser l’expérience désactivée limite la surface fonctionnelle disponible. Pour les sites connectés à un agent, une API ou un workflow MCP, l’activation doit être accompagnée d’un inventaire, d’un test avec le bon rôle et d’une vérification des données accessibles.
Poursuivez votre lecture
Trois articles pour aller plus loin.
Besoin d’un avis clair sur votre site ?
Premier échange clair · Priorités concrètes
Je peux vous aider à comprendre la situation, identifier les points importants et définir une intervention adaptée.
Premier échange gratuit · Sans engagement · Réponse rapide