Après plusieurs cycles de discussion au sein de l’équipe IA du projet, WordPress 7.0 marque une étape concrète : les fondations posées avec l’Abilities API dans la version 6.9 trouvent leur prolongement dans des fonctionnalités livrées directement dans le cœur, plutôt que dans des propositions encore expérimentales. Cet article ne revient pas sur l’Abilities API elle-même, déjà détaillée lors de sa sortie en 6.9 : il se concentre sur ce que la version 7.0 change concrètement pour un développeur d’extensions ou de thème.
Une interface d’administration pour gérer les abilities déclarées
Jusqu’à présent, une ability déclarée par une extension restait invisible dans l’administration : seul le code source ou un appel technique permettait de savoir ce qu’un site exposait réellement. WordPress 7.0 introduit un écran dédié listant l’ensemble des abilities déclarées par le cœur et les extensions actives, avec leur description, leur schéma et leur statut d’activation. Pour un développeur, cela signifie une meilleure visibilité de ce qui est réellement exposé sur un site, utile en particulier lors d’un audit de sécurité avant de connecter un agent externe.
Un contrôle d’activation par ability, pas seulement par extension
Deuxième changement notable : un administrateur peut désormais désactiver une ability précise sans désactiver l’extension entière qui la déclare, directement depuis cette nouvelle interface. Pour les développeurs, cela impose une vigilance nouvelle : une extension doit être écrite pour fonctionner correctement même si l’une de ses abilities se retrouve désactivée en cours de route, sans provoquer d’erreur fatale ailleurs dans le code.
Une convention renforcée pour les schémas d’entrée et de sortie
La version 7.0 impose une validation plus stricte des schémas déclarés par les abilities, refusant désormais l’enregistrement d’une ability dont le schéma d’entrée ou de sortie ne respecte pas un format JSON Schema valide, alors que la version précédente se contentait d’un avertissement silencieux dans les journaux. Les développeurs qui avaient des schémas approximatifs dans leurs extensions doivent désormais les corriger sous peine de voir leur ability tout simplement rejetée au chargement.
Ce que cela implique en pratique
Nous avons dû revoir deux extensions maison sur ce point précis, l’une avec un schéma de sortie qui omettait un champ pourtant toujours retourné, l’autre avec un type de paramètre mal déclaré qui fonctionnait par tolérance dans l’ancienne version mais échoue désormais à l’enregistrement.
Une meilleure intégration avec le MCP Adapter
Le MCP Adapter, jusqu’ici maintenu comme extension séparée, se rapproche du cœur avec 7.0 sans y être totalement intégré : la configuration de base pour exposer les abilities via MCP devient accessible directement depuis l’écran d’administration natif, réduisant le nombre d’étapes de configuration manuelle qu’un développeur devait auparavant documenter pour son client.
Ce que les développeurs doivent anticiper
Concrètement, tout projet qui déclare des abilities doit être audité avant la montée vers WordPress 7.0, pour vérifier la conformité stricte des schémas et le comportement de repli en cas de désactivation individuelle d’une ability par un administrateur. Ce n’est pas un chantier lourd sur un projet bien structuré dès le départ, mais un oubli fréquent sur les intégrations réalisées rapidement lors des premiers mois de l’Abilities API.
- Auditer la conformité stricte des schémas de chaque ability déclarée avant la montée de version
- Prévoir un comportement de repli propre en cas de désactivation individuelle d’une ability
- Vérifier la nouvelle interface d’administration pour identifier ce qui est réellement exposé sur chaque site client
- Simplifier la configuration MCP existante grâce à la meilleure intégration native
Une fondation posée dans une version mineure ne prend tout son sens que lorsqu’une version majeure vient la rendre visible et utilisable par les administrateurs eux-mêmes.
En résumé
WordPress 7.0 ne bouleverse pas les concepts posés par l’Abilities API, mais les rend enfin visibles et gouvernables depuis l’administration, avec une exigence de rigueur accrue sur les schémas déclarés. Pour les développeurs, l’enjeu principal des prochains mois tient dans l’audit des abilities existantes avant la montée de version, plutôt que dans l’apprentissage d’un concept entièrement nouveau.
