---
title : Le client AI de WordPress 7.0 du point de vue du développeur - isla Studio
url : https://isla-stud.io/en/allgemein/wordpress-7-ai-client-developer/
date : 2026-03-28
---
# Le client AI de WordPress 7.0 du point de vue du développeur
WordPress 7.0 apporte un client AI intégré. Pas comme un plugin, pas comme un drapeau de fonctionnalité expérimentale, mais comme une partie du Core. C'est une déclaration.
Je développe des plugins WordPress depuis 2009 et j'ai moi-même construit un plugin AI, citelayer®, qui est directement concerné par cette décision architecturale. Voici mon analyse technique : que peut faire l'API, quels sont ses points forts et que doivent savoir les développeurs de plugins ?
Table des matières
Le point d'entrée : wp_ai_client_prompt()
Tout commence par une seule fonction :
$builder = wp_ai_client_prompt() ;
Cela renvoie un objet WP_AI_Client_Prompt_Builder - un Fluent Builder via lequel le prompt, la configuration et la méthode de génération sont enchaînés. Le principe de base : le développeur décrit ce dont il a besoin. WordPress s'occupe du comment.
Un exemple simple de génération de texte :
// Prompt directement en paramètre - pratique pour les cas simples
$text = wp_ai_client_prompt( 'Résumez les avantages de la mise en cache dans WordPress.' )
->using_temperature( 0.7 )
->generate_text() ;
// Gestion des erreurs comme partout dans WordPress : vérifier WP_Error
if ( is_wp_error( $text ) ) {
return ;
}
echo wp_kses_post( $text ) ;
Le texte de l'invite peut être défini en tant que paramètre ou via with_text() - cette dernière option est utile lorsque l'invite est assemblée de manière dynamique.
Plus que du texte : Image, voix, vidéo
L'API est multimodale. La génération d'images fonctionne selon le même modèle :
use WordPress\AiClient\Files\DTO\File ;
$image = wp_ai_client_prompt( 'Un logo WordPress futuriste dans un style néon' )
->generate_image() ;
if ( is_wp_error( $image ) ) {
return ;
}
// File DTO avec Data URI - directement utilisable
echo '' ;
Pour les variations, il y a generate_images( 4 ) et generate_texts( 4 ). S'y ajoutent convert_text_to_speech_result(), generate_speech_result() et generate_video_result(). WordPress couvre ainsi toutes les modalités courantes.
Particulièrement intéressant : la sortie multimodale dans une seule requête :
use WordPress\AiClient\Messages\Enums\ModalityEnum ;
// Texte et images dans une réponse - le résultat contient les deux
$result = wp_ai_client_prompt( 'Créez une recette avec des photos pour chaque étape.' )
->as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
->generate_result() ;
Cela ouvre la porte à des plugins qui génèrent des contenus qui vont au-delà du simple texte.
Détection des fonctionnalités : ne pas faire de suppositions
Toutes les installations de WordPress n'auront pas configuré un fournisseur d'IA. Et tous les fournisseurs ne supportent pas toutes les modalités. L'API propose des contrôles déterministes :
$builder = wp_ai_client_prompt( 'test' )
->using_temperature( 0.7 ) ;
// Pas d'appel à l'API - vérification purement logique par rapport aux fournisseurs disponibles
if ( $builder->is_supported_for_text_generation() ) ) {
// Afficher l'IU pour la génération de texte
}
if ( $builder->is_supported_for_image_generation() ) ) {
// Afficher le bouton de génération d'image.
}
La solution est propre. Les contrôles ne coûtent rien - pas d'appels à l'API, pas de latence. Les développeurs de plugins peuvent charger leur IU de manière conditionnelle et afficher une indication utile si aucune IA n'est disponible. La règle : ne jamais supposer que les fonctions AI fonctionnent parce que WordPress 7.0 est installé.
Vérifications disponibles : is_supported_for_text_generation(), is_supported_for_image_generation(), is_supported_for_text_to_speech_conversion(), is_supported_for_speech_generation(), is_supported_for_video_generation().
Préférences de modèle au lieu d'exigences
La philosophie de conception apparaît ici clairement :
$result = wp_ai_client_prompt( 'Expliquez l'histoire de l'imprimerie.' )
->using_temperature( 0.1 )
->using_model_preference(
'claude-sonnet-4-6',
'gemini-3.1-pro-preview',
'gpt-5.4'
)
->generate_text_result() ;
using_model_preference() est une préférence, pas une exigence. Le client AI prend le premier modèle disponible dans la liste - ou n'importe quel modèle compatible si aucun n'est configuré. Le code du plugin fonctionne toujours, quel que soit le fournisseur d'accès.
C'est la bonne décision. Les développeurs de plug-ins ne devraient jamais dépendre de la disponibilité d'un modèle particulier. La recommandation officielle est de trier vos modèles de manière à ce que les plus récents soient placés avant les plus anciens. Les trois plug-ins fournisseurs officiels pour le lancement font déjà cela.
Réponses structurées avec le schéma JSON
Pour les plugins qui ont besoin de données structurées - et il y en a beaucoup - c'est un point fort :
$schema = array(
'type' => 'array',
'items' => array(
'type' => 'objet',
'properties' => array(
'plugin_name' => array( 'type' => 'string' ),
'category' => array( 'type' => 'string' ),
),
'required' => array( 'plugin_name', 'category' ),
),
) ;
$json = wp_ai_client_prompt( 'Liste 5 plugins WordPress populaires avec catégorie.' )
->as_json_response( $schema )
->generate_text() ;
// Données structurées directement sous forme de tableau - pas de parsage manuel nécessaire
$data = json_decode( $json, true ) ;
Cela vaut de l'or pour les plugins SEO, les plugins de forme, et les outils d'analyse de contenu. Au lieu d'analyser un texte non structuré, on obtient directement des données utilisables.
L'architecture à deux niveaux
Sous le capot, le client AI se compose de deux couches :
PHP AI Client (wordpress/php-ai-client) - un SDK PHP agnostique pour les fournisseurs, intégré dans Core en tant que bibliothèque externe. Méthodes CamelCase, exceptions, techniquement indépendant de WordPress.
WordPress Wrapper - WP_AI_Client_Prompt_Builder enveloppe le SDK dans les conventions WordPress : méthodes snake_case, WP_Error au lieu d'Exceptions, intégration avec WordPress HTTP Transport, Abilities API, infrastructure Connectors et le système Hook.
C'est une séparation élégante. Le PHP SDK peut théoriquement être utilisé en dehors de WordPress. Le wrapper WordPress le rend idiomatique. Et l'objet GenerativeAiResult est sérialisable et peut être transmis directement à rest_ensure_response() - intégration REST-API out of the box :
function my_rest_callback( WP_REST_Request $request ) {
$result = wp_ai_client_prompt( $request->get_param( 'prompt' ) )
->generate_text_result() ;
// WP_Error ou GenerativeAiResult - les deux fonctionnent
return rest_ensure_response( $result ) ;
}
Contrôle granulaire : le filtre
Pour la sécurité et la conformité, il y a wp_ai_client_prevent_prompt :
add_filter(
'wp_ai_client_prevent_prompt',
function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ) : bool {
// Exemple : AI uniquement pour les admins
if ( ! current_user_can( 'manage_options' ) ) {
return true ;
}
return $prevent ;
},
10,
2
) ;
Si un prompt est bloqué : pas d'appel API, is_supported_*() renvoie false, generate_*() renvoie WP_Error. Propre, prévisible, pas de conditions de course.
Points forts et points faibles
Ce qui est bien résolu
L'abstraction du fournisseur. Les développeurs de plug-ins n'ont jamais à se préoccuper des clés API, des limites de taux ou des spécificités des fournisseurs d'accès.
Détection de fonctionnalités sans appels à l'API. Pas besoin de deviner si quelque chose fonctionne.
Les conventions de WordPress. WP_Error, les hooks, la compatibilité REST - cela donne l'impression d'être natif.
Le support des schémas JSON. Les réponses structurées sont prises en charge de première classe.
L'architecture à deux couches. Une séparation nette entre le SDK et l'intégration de WordPress.
Ce que je surveille d'un œil critique
La configuration des connecteurs est du ressort du propriétaire du site. Les plugins n'ont aucune influence sur la configuration d'un fournisseur. La détection des fonctionnalités intercepte cela, mais le défi UX demeure.
Le paysage des modèles évolue rapidement. L'avenir nous dira dans quelle mesure la liste des préférences vieillit lorsque de nouveaux modèles apparaissent tous les trois mois.
Les implications en termes de performance ne sont pas encore claires. Comment le système se comporte-t-il en charge lorsque 10 plugins envoient des messages d'invite en même temps ?
Ce que cela signifie pour les plugins existants
Chaque plugin qui apporte aujourd'hui ses propres intégrations AI est confronté à une décision : conserver sa propre connexion API ou migrer vers le client AI ?
Pour les plug-ins SEO, la réponse est claire - les données structurées, l'analyse de contenu, la génération de méta-descriptions se font de manière beaucoup plus propre via le client AI. Pour les plugins de formulaires, la validation intelligente des champs et l'auto-remplissage sont possibles. Pour les plug-ins de commerce électronique, les descriptions de produits générées par l'IA deviennent tout à coup banales.
Pour un plugin comme citelayer® - AI Visibility pour WordPress, qui travaille à l'interface entre WordPress et les systèmes AI, le client AI est une extension naturelle. Citelayer rend le contenu lisible pour l'IA - grâce à llms.txt, l'injection de schémas, le suivi des bots et les protocoles comme UCP et WebMCP. Le client AI pourrait compléter ces couches d'analyse par des évaluations plus intelligentes, basées sur l'AI. J'ai expliqué plus en détail dans le blog de Citelayer ce que cela signifie concrètement pour la visibilité AI.
Pas un gadget mais une infrastructure
Le client WordPress 7.0 AI n'est pas un gadget. C'est une infrastructure. Bien pensé, idiomatique à WordPress, et avec une philosophie de conception claire : le développeur décrit l'intention, le système s'occupe de l'exécution.
Quiconque développe aujourd'hui des plug-ins WordPress devrait se familiariser avec cette API. Non pas parce qu'il le faut - mais parce qu'elle est la base sur laquelle la prochaine génération de plugins WordPress sera construite.
La documentation complète de l'API est disponible sur le blog WordPress Make.