WordPress 7.0 apporte un client AI intégré. Pas en tant que plugin, pas en tant que fonctionnalité expérimentale, mais en tant que partie du core. C'est une déclaration.
Je développe des plugins WordPress depuis 2009 et j'ai travaillé avec citelayer® construit moi-même un plug-in AI 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 plug-ins ?
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 donne un WP_AI_Client_Prompt_Builder-un constructeur fluide par lequel l'invite, la configuration et la méthode de génération sont enchaînées. Le principe de base : le développeur décrit, ce que il a besoin. WordPress s'occupe de comme.
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 envoyé en tant que paramètre ou via with_text() ce qui est utile lorsque le prompt est assemblé 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 '<img src="' . esc_url( $image->getDataUri() ) . '" data-no-translation="" data-no-auto-translation="">';Pour les variations, il y a generate_images( 4 ) et generate_texts( 4 ). A cela s'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 : une sortie multimodale dans une seule demande :
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.
Feature Detection : ne pas faire de suppositions
Toutes les installations WordPress n'ont pas forcément un fournisseur d'IA configuré. 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 plug-ins peuvent charger leur IU de manière conditionnelle et afficher une indication utile lorsqu'aucune IA n'est disponible. La règle : Ne jamais supposer que les fonctions AI fonctionnent simplement parce que WordPress 7.0 est installé.
Chèques 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 du design 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 d'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 : triez 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 plug-ins SEO, les plug-ins 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 niveaux :
- Client PHP AI (
wordpress/php-ai-client) - un SDK PHP agnostique pour les fournisseurs, intégré à Core en tant que bibliothèque externe. Méthodes CamelCase, exceptions, techniquement indépendant de WordPress. - Enveloppeur WordPress —
WP_AI_Client_Prompt_Builderdéveloppe le SDK dans les conventions WordPress : méthodes snake_case,WP_Errorau lieu d'exceptions, l'intégration avec WordPress HTTP Transport, l'API Abilities, l'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 le GenerativeAiResult-est sérialisable et peut être envoyé directement à l'objet 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 oder GenerativeAiResult — beides funktioniert
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 une invite est bloquée : pas d'appel API, is_supported_*() donne false en arrière, generate_*() fournit WP_Error. Propre, prévisible, pas de conditions de course.
Points forts et points faibles
Ce qui est bien résolu :
- L'abstraction des fournisseurs. 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 WordPress.
WP_Error, hooks, compatibilité REST - cela donne l'impression d'être natif. - Support du schéma JSON. Les réponses structurées bénéficient d'un soutien de premier ordre.
- L'architecture à deux niveaux. Une séparation nette entre le SDK et l'intégration de WordPress.
Ce que j'observe de manière critique
- La configuration du connecteur est du ressort du propriétaire du site. Les plugins n'ont aucune influence sur ce point, si un fournisseur d'accès est configuré. Feature Detection 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 Plugins 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 beaucoup plus proprement via le client AI. Pour Plugins de formulaire s'ouvre la validation intelligente des champs et l'auto-remplissage. Pour Plugins de commerce électronique les descriptions de produits générées par l'IA deviennent soudain triviales.
Pour un plugin comme citelayer® - Visibilité AI pour WordPress, Le client AI est une extension naturelle de Citeitelayer, qui travaille à l'interface entre WordPress et les systèmes d'intelligence artificielle. 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é ce que cela signifie concrètement pour la visibilité AI. sur le blog de Citelayer..
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 site WordPress Make Blog.
0 commentaires