Avant WordPress 7.0, les extensions ajoutant des fonctionnalités d’IA devaient demander et gérer une clé API pour communiquer avec un fournisseur d’IA.

Cela présentait plusieurs inconvénients en termes de poids du code et de facilité de maintenance. Vous deviez intégrer dans vos extensions des bibliothèques SDK propriétaires et lourdes, et rédiger des requêtes cURL spécifiques à chaque fournisseur.

Ce scénario fragmenté a complètement changé avec l’intégration native de l’IA introduite dans WordPress 7.0. Aujourd’hui, WordPress dispose d’une interface centralisée permettant de configurer les identifiants pour divers fournisseurs d’IA, ainsi que d’une nouvelle API PHP. Cette nouvelle architecture vous permet d’envoyer des commandes, des instructions, des fichiers multimédias et des structures de données en toute transparence, tandis que le noyau gère les requêtes.

Cette nouvelle architecture offre des avantages considérables tant pour les administrateurs de site que pour les développeurs d’extensions.

Les administrateurs n’ont plus besoin de configurer les réglages d’IA sur plusieurs extensions. À partir de WordPress 7.0, il vous suffit d’installer et d’activer les connecteurs de vos extensions, de saisir vos clés API dans l’interface unifiée « Connecteurs », et celles-ci deviennent instantanément disponibles pour toutes les extensions basées sur l’IA de votre site. Vous pouvez facilement surveiller l’utilisation de l’IA, changer de modèle ou révoquer l’accès d’un fournisseur pour toutes les extensions d’un simple clic.

Pour les développeurs d’extensions, les avantages sont encore plus importants : ils vont de la sécurité des données à la portabilité du code, en passant par une réduction drastique de la dette technique.

Prêts à vous lancer dans cette aventure vers la nouvelle architecture IA de WordPress ? Plongeons-nous dans le vif du sujet.

Les trois couches de l’architecture IA de WordPress

Aujourd’hui, vos sites WordPress sont nativement compatibles avec l’IA. Il ne s’agit toutefois pas de fonctionnalités d’IA prêtes à l’emploi, mais plutôt des fondements permettant de créer des sites web alimentés par l’IA.

La nouvelle architecture s’articule autour de trois couches distinctes :

Connecteur IA

Avant WordPress 7.0, chaque extensions ajoutant des fonctionnalités d’IA à votre site nécessitait son propre système pour stocker et gérer vos clés API. Vos identifiants devaient être codés en dur dans l’extension ou gérés via une page de réglages personnalisée. Dans les deux cas, cette solution était loin d’être idéale pour la gestion des données sensibles.

L’interface centralisée des connecteurs IA dans le tableau de bord d’administration de WordPress.
L’interface centralisée des connecteurs IA dans le tableau de bord d’administration de WordPress.

Une interface unifiée vous permet de configurer tous vos fournisseurs de services d’IA à partir d’un emplacement central. Cette interface apporte plusieurs avantages majeurs à la gestion de votre site.

Du point de vue de la gestion et de la sécurité, le principal avantage réside dans le fait que vous n’avez à configurer vos fournisseurs qu’une seule fois dans l’interface « Connecteurs », après quoi vous n’avez plus à vous en soucier, quel que soit le nombre d’extensions qui les utilisent. Si vous devez un jour modifier vos clés API, vous n’aurez pas à reconfigurer chaque extension ; vous pourrez les mettre à jour en une seule fois depuis l’écran « Connecteurs ».

La centralisation des identifiants renforce également la sécurité de votre site en réduisant le risque d’exposition de données sensibles via des extensions tierces qui pourraient être mal codées ou peu fiables.

Un autre avantage majeur réside dans la portabilité du code. Vos extensions n’ont plus besoin de savoir quel fournisseur d’IA vous utilisez, car la nouvelle architecture dissocie l’authentification de la logique des extensions. Cela signifie que si vous changez de fournisseur d’IA, votre extension continuera de fonctionner sans qu’il soit nécessaire de modifier la moindre ligne de code.

Cependant, la véritable avancée en matière de portabilité réside dans la possibilité pour les administrateurs de site de configurer plusieurs connecteurs simultanément. Lorsqu’une extension déclenche une requête, WordPress sélectionne automatiquement le fournisseur d’IA et le modèle les plus adaptés pour générer la réponse, en fonction à la fois de la configuration spécifique de l’extension et des capacités des modèles disponibles.

Client IA

Alors que l’écran « Connecteurs » fournit l’interface utilisateur de configuration des fournisseurs d’IA, le client IA offre aux développeurs l’outil opérationnel permettant de communiquer avec les modèles d’IA.

Il s’agit d’une interface logicielle native qui normalise l’interaction avec les modèles d’intelligence artificielle via la fonction globale wp_ai_client_prompt() et un ensemble unifié de méthodes PHP.

Réduction de la dette technique

Pour les développeurs, l’un des principaux avantages de la nouvelle architecture d’IA réside dans la réduction de la dette technique et des dépendances. Avant WordPress 7.0, l’ajout de fonctionnalités d’IA entraînait un coût très élevé en termes de maintenance du code. Vous deviez intégrer des SDK propriétaires tiers (tels que les bibliothèques officielles d’OpenAI ou d’Anthropic) et surveiller en permanence les versions de ces bibliothèques. Cela alourdissait considérablement la base de code des extensions et ouvrait la voie à des erreurs de compatibilité.

De plus, il fallait écrire de nombreuses lignes de code pour gérer la logique réseau et l’analyse des réponses. Pour aggraver encore la situation, le code était spécifique à chaque fournisseur ; ainsi, si vous décidiez de changer de fournisseur d’IA, vous deviez réécrire l’intégralité de l’architecture réseau de votre extension.

AI Client résout ce problème à la racine en transférant tout ce travail fastidieux au cœur de WordPress. Votre code devient totalement indépendant du fournisseur d’IA ; il vous suffit d’écrire vos instructions une seule fois, et WordPress les traduira dans le « dialecte » spécifique du modèle.

Sélection intelligente des modèles

L’une des fonctionnalités puissantes de l’interface Fluent de l’AI Client réside dans la possibilité de définir des modèles préférés via la méthode using_model_preference(), accessible par le biais de la fonction de construction wp_ai_client_prompt(). Cette méthode vous permet de déclarer une liste ordonnée de modèles pour la tâche spécifique de votre extension. Par exemple, le code suivant demande la génération de texte en ciblant trois modèles préférés :

$text_result = wp_ai_client_prompt( 'Convert the following transcript into a concise, blog-ready draft.' )
	->using_model_preference(
		'gemini-2.5-flash',
		'claude-3-5-sonnet',
		'gpt-4o'
	)
	->generate_text();

WordPress vérifiera les fournisseurs configurés sur l’écran « Connecteurs » et parcourra la liste des modèles définis dans le code de l’extension, en sélectionnant le premier connecteur également disponible sur le site. Si aucun des modèles spécifiés dans votre code n’est disponible parmi les connecteurs actifs, WordPress ignorera la liste des modèles préférés et se rabattra sur le premier modèle compatible configuré sur le site.

Ce mécanisme garantit que votre plugin fonctionnera toujours, même si l’administrateur du site passe à un autre fournisseur d’IA.

Fournisseur d’IA

Un fournisseur d’IA est l’entreprise qui possède, entraîne et héberge les grands modèles linguistiques (LLM) que nous utilisons quotidiennement. OpenAI, Google Gemini et Anthropic sont les fournisseurs d’IA les plus courants pris en charge via des connecteurs dédiés dans WordPress 7.0, mais les développeurs peuvent enregistrer d’autres fournisseurs d’IA personnalisés.

Lorsque le code de votre extension appelle la méthode generate_text()— ou toute autre méthode de génération —, WordPress compile et envoie une charge utile de données au fournisseur d’IA via le point de terminaison établi par le connecteur. Voici la séquence d’opérations qui se déroule en arrière-plan :

  • Dans un premier temps, le fournisseur d’IA reçoit le texte de la requête ainsi que les éventuels fichiers multimédias joints (charge utile).
  • Une fois la demande reçue, il la traite en appliquant les instructions du système.
  • À partir de là, il génère la sortie sous forme de texte libre ou d’objet JSON.
  • Enfin, il renvoie cette sortie à WordPress via une réponse HTTP.

Chaque fournisseur propose une grande variété de modèles aux capacités, vitesses et tarifs variés. Ceux-ci vont des modèles spécialisés exclusivement dans le traitement de texte aux modèles multimodaux acceptant des fichiers multimédias (audio, images, vidéo) en plus d’une invite textuelle, en passant par des modèles conçus pour des tâches spécifiques, telles que la génération d’images ou la conversion de la parole en texte.

La famille de modèles Gemini 3 de Google.
La famille de modèles Gemini 3 de Google.

Une fois encore, les modèles disponibles pour un site WordPress dépendent des fournisseurs d’IA que l’utilisateur configure dans l’écran « Connecteurs ». Cela signifie que votre extension ne dicte pas quel fournisseur spécifique utiliser.

Analyse approfondie de la fonction wp_ai_client_prompt()

La fonction wp_ai_client_prompt() permet aux plugins de communiquer avec les modèles d’IA de manière standardisée : vous n’aurez pas à installer de bibliothèques externes, à gérer des configurations spécifiques à chaque fournisseur, ni à coder en dur des requêtes HTTP manuelles.

Il s’agit d’une interface logicielle qui vous permet d’écrire votre code une seule fois, laissant WordPress se charger du gros du travail et traduire vos instructions dans le « dialecte » spécifique à chaque modèle.

La fonction renvoie une instance de la classe WP_AI_Client_Prompt_Builder, qui fournit une interface fluide composée de méthodes enchaînables pour personnaliser vos invites. La fonction est décrite comme suit :

/**
 * Fluent builder for constructing AI prompts, returning WP_Error on failure.
 *
 * This class provides a fluent interface for building prompts with various
 * content types and model configurations. It wraps the PHP AI Client SDK's
 * PromptBuilder and adds WordPress-specific behavior including WP_Error
 * handling instead of exceptions, snake_case method naming, and integration
 * with the Abilities API.
 *
 * Only the generating methods will return a WP_Error, to not break the fluent
 * interface. As soon as any exception is caught in a chain of method calls,
 * the returned instance will be in an error state, and all subsequent method
 * calls will be no-ops that just return the same error state instance. Only
 * when a generating method is called, the WP_Error will be returned.
 */

wp_ai_client_prompt() elle n’effectue pas de requête HTTP immédiate ; elle instancie et renvoie plutôt un objet WP_AI_Client_Prompt_Builder. Plus de 50 méthodes de configuration renseignent les propriétés privées de l’objet à l’aide d’une interface fluide, ce qui rend le code très lisible et facile à écrire.

Voici une liste non exhaustive des méthodes que vous utiliserez le plus fréquemment :

  • with_text(): Ajoute du texte au message actuel.
  • with_file(): Ajoute un fichier au message en cours.
  • with_history(): Ajoute des messages de l’historique de la conversation.
  • using_model_preference(): Définit les modèles préférés à évaluer dans l’ordre.
  • using_system_instruction(): Définit l’instruction système.
  • using_max_tokens(): Définit le nombre maximal de tokens à générer.
  • using_temperature(): Définit la température pour la génération.
  • using_top_p(): Définit la valeur « top-p » pour la génération.
  • using_top_k(): Définit la valeur « top-k » pour la génération.
  • as_output_file_type(): Définit le type de fichier de sortie.
  • as_json_response(): Configure l’invite pour la sortie de la réponse au format JSON.
  • is_supported_for_text_generation(): Vérifie si la génération de texte est prise en charge par la configuration active.
  • is_supported_for_image_generation(): Vérifie si la génération d’images est prise en charge par la configuration active.
  • is_supported_for_text_to_speech_conversion(): Vérifie si la conversion texte-parole est prise en charge par la configuration active.
  • is_supported_for_video_generation(): Vérifie si la génération de vidéos est prise en charge par la configuration active.
  • generate_text(): Génère un résultat textuel à partir de la consigne.
  • generate_image(): Génère une image à partir de la consigne.
  • convert_text_to_speech(): Convertit le texte en parole.
  • generate_speech(): Génère un message vocal à partir de la consigne.
  • generate_video(): Génère une vidéo à partir de la consigne.

Pour consulter la liste complète des méthodes, veuillez vous reporter au code source du cœur de WordPress.

Supposons que vous souhaitiez transcrire avec précision le contenu d’un fichier audio. Vous pourriez utiliser la fonction comme ci-dessous :

$transcription_builder = wp_ai_client_prompt( $prompt )
	->with_file( $audio_base64, $mime_type )
	->using_temperature( 0.1 );

if ( ! $transcription_builder->is_supported_for_text_generation() ) {
	// No configured provider supports the current prompt configuration.
	return new WP_Error(
		'no_supported_model',
		'No configured AI model can process this request. Configure a provider in Settings > Connectors.',
		array( 'status' => 400 )
	);
}

$transcript = $transcription_builder->generate_text();

Voici ce que fait ce code :

  • $prompt: Représente la chaîne principale contenant vos instructions principales.
  • with_file(): Active les capacités multimodales de l’interface. Dans l’exemple ci-dessus, nous avons transmis la charge utile audio binaire pré-encodée sous forme de chaîne encodée en Base64, accompagnée de son type MIME correspondant.
  • using_temperature(): Contrôle le déterminisme de la réponse. Alors qu’une valeur faible (0,1) oblige le modèle à rester fidèle à l’audio, une valeur plus élevée permet une plus grande liberté créative. Vous pouvez combiner cette méthode avec la méthode « using_top_p() » (probabilité maximale) pour un contrôle plus précis de la sortie.
  • is_supported_for_text_generation(): Vérifie si les connecteurs actifs prennent en charge les exigences de la requête actuelle avant d’allouer des ressources à un appel réseau.
  • generate_text(): Il s’agit de la méthode de terminaison de l’interface Fluent. Elle envoie la requête HTTP unifiée au fournisseur actif et renvoie soit la chaîne de texte générée, soit un objet « WP_Error » en cas d’échec.

En résumé, nous avons transmis au fournisseur d’IA une invite textuelle et un fichier audio joint. Nous avons défini une « température » faible afin de garantir un résultat aussi déterministe que possible, vérifié que la configuration active prenait en charge la génération de texte, puis enfin exécuté la transcription de la parole en texte sur la base de la réponse de l’IA.

À l’aide d’une autre instruction, nous pouvons renvoyer la transcription brute à l’IA afin de générer une réponse structurée sous la forme d’un objet JSON :

$structured_json = wp_ai_client_prompt(
	"Convert the following transcript into a concise, blog-ready draft in American English.n" .
	"Return JSON with a post title and body sections.n" .
	"Each section must have: heading, level (2 or 3), and paragraphs (array).n" .
	"If useful, include bullet_points (array) for short actionable lists.n" .
	"Use short, clear headings and readable paragraph text.nn" .
	"Transcript:n" . $transcript
)
	->using_system_instruction( "You are a professional WordPress content editor. Always write in American English (use appropriate spelling, grammar, and conventions for that language variant)." )
	->using_temperature( 0.4 )
	->as_json_response( $schema )
	->generate_text();

Pour cette deuxième instruction, nous utilisons des méthodes supplémentaires afin d’exploiter d’autres fonctionnalités de l’API :

  • using_system_instruction(): Définit le contexte opérationnel et le rôle comportemental du modèle, en séparant clairement son profil (« un rédacteur de contenu WordPress professionnel ») de la charge utile des données.
  • using_temperature( 0.4 ): Définit un niveau de « température » plus élevé que lors de la tâche de transcription précédente, ce qui permet au modèle d’utiliser un vocabulaire plus riche et de produire un contenu plus fluide.
  • as_json_response(): Oblige le modèle à renvoyer une chaîne JSON structurée qui correspond à la mise en page définie dans votre variable $schema. Cela s’avère utile lors de la préparation de contenu pour Gutenberg.

Grâce à une sortie structurée au format JSON, vous pouvez extraire des champs individuels et les mapper par programmation dans des blocs Gutenberg natifs à l’aide des fonctions principales de WordPress.

Pour un aperçu plus détaillé de l’AI Client, consultez également la note de développement « Présentation de l’AI Client dans WordPress 7.0 ».

Convertir un fichier audio en contenu compatible avec Gutenberg grâce à l’IA

Maintenant que vous comprenez mieux les trois couches de l’architecture IA de WordPress, voyons comment tout cela s’articule à l’aide d’un exemple concret. Dans cette section, vous apprendrez à mettre en place la logique centrale d’une extension alimentée par l’IA, conçue pour générer un brouillon d’article bien rédigé directement à partir d’un fichier audio.

Les cas d’utilisation de cette fonctionnalité sont nombreux et variés. Imaginez pouvoir créer un article de blog complet à partir d’une brève note vocale envoyée via votre application de messagerie préférée, ou transcrire une interview audio enregistrée sur votre smartphone.

Pour mettre en œuvre cette fonctionnalité sur votre site WordPress, vous devrez créer une extension personnalisé. Nous n’aborderons pas ici les fichiers de base ni le processus complet d’enregistrement de l’extensio ; pour les principes fondamentaux du développement d’extensions, vous pouvez vous reporter à d’autres tutoriels sur le blog Kinsta ou à la documentation officielle de WordPress.org.

Nous nous concentrerons sur la logique centrale qui permet à votre extension de communiquer avec votre fournisseur d’IA. Mais ne vous inquiétez pas, l’extension est disponible à la consultation et au téléchargement dans ce dépôt GitHub.

Fonctionnalités de ce plugin

Pour commencer, rendez-vous sur la page du projet GitHub et téléchargez l’archive ZIP de l’extension. Ensuite, connectez-vous à votre tableau de bord WordPress 7.0 et importez-la via Extensions > Ajouter > Téléverser une extension. Une fois l’extension installée et activée, vous êtes prêt à suivre ce tutoriel.

L’extension AI Content Builder génère une colonne latérale de réglages personnalisés, accessible via une icône située dans le coin supérieur droit de l’interface de l’éditeur de blocs. Cette colonne latérale comporte une interface dédiée au téléversement de fichiers audio ainsi qu’un bouton permettant à l’IA de remplacer le titre actuel de l’article.

L'extension AI Content Builder ajoute une colonne latérale de réglages personnalisés à l’éditeur de blocs.
L’extension AI Content Builder ajoute une colonne latérale de réglages personnalisés à l’éditeur de blocs.

Le bouton « Importer un fichier audio » ouvre l’outil d’importation de médias de WordPress, vous permettant d’importer un nouveau fichier audio ou d’en sélectionner un existant dans votre médiathèque.

Sélectionnez ou importez des fichiers audio dans la médiathèque de WordPress.
Sélectionnez ou importez des fichiers audio dans la médiathèque de WordPress.

Une fois le fichier audio chargé, le bouton « Générer du contenu » déclenche une requête asynchrone vers votre fournisseur d’IA actif.

La colonne latérale de l'extension avec le bouton « Générer du contenu » actif.
La colonne latérale de l’extension avec le bouton « Générer du contenu » actif.

L’image ci-dessous montre le brouillon final de l’article généré par l’IA en quelques secondes seulement.

Un brouillon d’article de blog bien formaté, généré par l’IA à partir d’un fichier audio brut.
Un brouillon d’article de blog bien formaté, généré par l’IA à partir d’un fichier audio brut.

Le contenu obtenu est structuré en blocs Gutenberg natifs, comprenant des paragraphes, des titres et des listes.

Un balisage bien structuré dans l’éditeur de code WordPress.
Un balisage bien structuré dans l’éditeur de code WordPress.

Penchons-nous maintenant sur le fonctionnement de l’extension.

Ce dont vous avez besoin pour ce plugin

Voici les prérequis de base pour développer une extension WordPress qui s’intègre à la nouvelle architecture d’IA afin de générer le contenu de vos articles :

  • WordPress 7.0
  • Une clé API d’un fournisseur d’IA proposant un modèle capable de convertir la parole en texte. Dans notre exemple, nous utiliserons Google AI.
  • Votre IDE préféré. Pour cette extension, nous avons utilisé VS Code.
  • Une solide maîtrise du développement WordPress et Gutenberg, des API REST, du PHP et du JavaScript.

Vous n’avez pas à vous soucier de Node.js, des processus de compilation ou de l’importation de bibliothèques externes, car cette extension s’appuie entièrement sur les API natives du cœur de WordPress. Le résultat est une extension légère et sécurisée, sans aucune dette technique.

Structure du plugin et version minimale de WordPress

L’extension AI Content Builder se compose de deux fichiers seulement :

  • ai-content-builder.php
  • editor.js.

La version minimale nécessaire de WordPress est la 7.0 ; veillez donc à la définir dans l’en-tête de l’extension :

<?php
/**
 * Plugin Name: AI Content Builder
 * Description: Gutenberg sidebar plugin that uploads audio and generates post content using the WordPress 7.0 AI Client.
 * Version: 1.0.0
 * Requires at least: 7.0
 * Requires PHP: 8.0
 * Author: Your Name
 * License: GPL-2.0-or-later
 * Text Domain: ai-content-builder
 */

Cela étant dit, examinons le processus de création d’une extension WordPress alimentée par l’IA.

Le flux de données du plugin

Avant de nous plonger dans le code, examinons comment les données circulent depuis le backend de WordPress (l’éditeur de blocs) vers le serveur PHP et le fournisseur d’IA, puis reviennent dans le sens inverse.

1. Du navigateur au serveur : appel REST asynchrone : le navigateur envoie l’identifiant audio au point de terminaison REST personnalisé de l’extension. Pour éviter que l’interface utilisateur ne se fige, nous enregistrons un point de terminaison REST qui autorise les requêtes asynchrones vers le serveur PHP.

2. Premier passage par l’IA : transcription de la parole en texte : le serveur intercepte la requête, récupère le fichier audio depuis la base de données et interroge le client IA afin d’extraire la transcription brute sous forme de texte.

3. Deuxième passage par l’IA : structuration du contenu : le serveur renvoie la transcription brute au client IA et lui demande de la formater sous la forme d’un objet JSON structuré.

4. Hydratation des données et génération de blocs : le script JavaScript (JS) reçoit l’objet JSON structuré, le normalise et mappe les champs aux blocs natifs de Gutenberg.

Examinons maintenant la logique qui sous-tend chaque phase.

1. Enregistrement d’un point de terminaison API personnalisé

La première étape de la création de l’extension AI Content Builder consiste à enregistrer un point de terminaison API. Cette étape est essentielle, car le traitement d’un fichier audio et la génération d’une réponse peuvent prendre plusieurs secondes (voire plusieurs minutes) pour le modèle d’IA. L’enregistrement d’un point de terminaison REST vous permet d’effectuer des requêtes asynchrones via les commandes de la colonne latérale, ce qui évite le gel de l’interface utilisateur.

L’enregistrement d’un point de terminaison API vous permet également d’effectuer des appels IA sécurisés sans exposer vos identifiants de connexion, en tirant parti du système d’authentification natif de WordPress.

La logique d’enregistrement et d’initialisation du point de terminaison est gérée dans le fichier PHP de l’extension à l’aide de deux méthodes de classe : init() et register_rest_routes().

public static function init(): void {

	// Register the custom REST endpoint used by the sidebar JS.
	add_action( 'rest_api_init', array( __CLASS__, 'register_rest_routes' ) );

	...
}

En associant l’appel de fonction au hook rest_api_init, l’extension n’enregistre la racine du point de terminaison que lorsqu’une requête API REST est déclenchée. Cela améliore les performances en évitant les retards inutiles lors du chargement des pages.

Vous pouvez configurer les routes à l’aide de la méthode register_rest_routes(), comme indiqué dans le code ci-dessous :

public static function register_rest_routes(): void {
	register_rest_route(
		self::REST_NAMESPACE,
		self::REST_ROUTE,
		array(
			'methods'             => WP_REST_Server::CREATABLE, // Alias for POST.
			'callback'            => array( __CLASS__, 'handle_generate_request' ),
			'permission_callback' => static function (): bool {
				// Reject unauthenticated or insufficiently privileged requests early.
				return current_user_can( 'edit_posts' );
			},
			'args'                => array(
				'audio_id' => array(
					'type'     => 'integer',
					'required' => true,
				),
			),
		)
	);
}

Cette méthode effectue les opérations suivantes :

  • La fonction register_rest_route() prend trois paramètres : l’espace de noms de la route, la route elle-même et un tableau de configuration.
  • WP_REST_Server::CREATABLE est un alias de la méthode de transport POST, utilisé pour garantir une compatibilité maximale avec l’architecture interne de WordPress.
  • permission_callback est une fonction anonyme qui limite l’accès aux utilisateurs authentifiés disposant des droits nécessaires pour créer et modifier leurs propres articles. WordPress bloque alors la requête avant de la traiter et renvoie automatiquement une erreur 401 Non autorisé ou 403 Accès interdit en cas d’accès non autorisé.
  • args Il s’agit d’un tableau facultatif de paramètres supplémentaires pouvant être utilisés pour modifier la réponse de l’API. Il vous permet de spécifier les données que la requête adressée au point de terminaison doit renvoyer.
  • audio_id est un tableau de paramètres qui spécifie le type de données nécessaire. Si le type de données renvoyé n’est pas un entier ou s’il est manquant, l’API REST interrompt son exécution et génère une erreur.

Enfin, assurez-vous que la colonne latérale de l’éditeur sait où envoyer les données. Pour ce faire, utilisez la fonction wp_localize_script() au sein de la méthode enqueue_editor_assets().

public static function enqueue_editor_assets(): void {
	...

	wp_localize_script(
		'ai-content-builder-editor',
		'AICBData',
		array(
			'restPath' => '/' . self::REST_NAMESPACE . self::REST_ROUTE,
			'nonce'    => wp_create_nonce( 'wp_rest' ),
		)
	);
}
  • La fonction wp_localize_script() sert principalement à associer un script enregistré à une variable JavaScript, mais ici, nous l’utilisons pour transmettre des données de PHP vers JavaScript via l’objet global AICBData.
  • restPath Il s’agit de l’adresse du point de terminaison ; en la spécifiant ici, vous évitez de la coder en dur dans le fichier JavaScript.
  • nonce définit un jeton de sécurité afin d’empêcher tout accès non autorisé.

2. Accéder au client IA pour extraire du texte d’un fichier audio

Le cœur de notre extension est la méthode handle_generate_request(). Cette méthode effectue une séquence de tâches, commençant par des contrôles de sécurité et se terminant par la génération du contenu de l’article à insérer dans l’éditeur de blocs.

Tout d’abord, elle vérifie que le client IA est disponible et que la prise en charge de l’IA n’a pas été désactivée sur le site.

public static function handle_generate_request( WP_REST_Request $request ) {
	if ( ! function_exists( 'wp_ai_client_prompt' ) ) {
		return new WP_Error(
			'ai_client_unavailable',
			'WordPress AI Client is not available. This plugin requires WordPress 7.0 .',
			array( 'status' => 500 )
		);
	}

	if ( function_exists( 'wp_supports_ai' ) && ! wp_supports_ai() ) {
		return new WP_Error(
			'ai_disabled',
			'AI support is disabled on this site.',
			array( 'status' => 403 )
		);
	}
	...
}

En cas d’échec, ces vérifications renvoient respectivement une erreur 500 ou 403.

Le bloc de code suivant effectue les actions suivantes :

  • Extrait l’identifiant du fichier audio de la requête
  • S’assure que l’identifiant du fichier audio est un entier positif
  • Vérifie le type de fichier
  • Récupère le type MIME
  • Extrait et encode le contenu du fichier en Base64
$audio_id = absint( $request->get_param( 'audio_id' ) );
if ( ! $audio_id ) {
	return new WP_Error( 'invalid_audio_id', 'Invalid audio ID.', array( 'status' => 400 ) );
}

$attachment = get_post( $audio_id );
if ( ! $attachment || 'attachment' !== $attachment->post_type ) {
	return new WP_Error( 'audio_not_found', 'Audio attachment not found.', array( 'status' => 404 ) );
}

$mime_type = (string) get_post_mime_type( $audio_id );
if ( 0 !== strpos( $mime_type, 'audio/' ) ) {
	return new WP_Error( 'invalid_audio_type', 'Attachment must be an audio file.', array( 'status' => 400 ) );
}

$audio_path = get_attached_file( $audio_id );
if ( ! $audio_path || ! file_exists( $audio_path ) ) {
	return new WP_Error( 'audio_path_missing', 'Audio file path not found on server.', array( 'status' => 404 ) );
}

$audio_bytes = file_get_contents( $audio_path );
if ( false === $audio_bytes ) {
	return new WP_Error( 'audio_read_failed', 'Unable to read audio file.', array( 'status' => 500 ) );
}

$audio_base64 = base64_encode( $audio_bytes );
Un message d’erreur est généré lorsque l’utilisateur tente de traiter un type de fichier non valide
Un message d’erreur est généré lorsque l’utilisateur tente de traiter un type de fichier non valide

Le fichier binaire a ainsi été converti en une chaîne de caractères pouvant être transmise au client IA. Nous pouvons désormais passer à l’extraction du texte :

$output_language = self::get_output_language();

$transcription_builder = wp_ai_client_prompt(
	"Transcribe this voice note accurately into $output_language. Return plain text only."
)
	->with_file( $audio_base64, $mime_type )
	->using_temperature( 0.1 );

if ( ! $transcription_builder->is_supported_for_text_generation() ) {
	return new WP_Error(
		'no_supported_model',
		'No configured AI model can process this request. Configure a provider in Settings > Connectors.',
		array( 'status' => 400 )
	);
}

$transcript = $transcription_builder->generate_text();

Voici une explication détaillée du fonctionnement du code ci-dessus.

  • get_output_language() est une méthode statique définie ailleurs dans le script qui renvoie les réglages régionaux du site. (Voir GitHub.)
  • wp_ai_client_prompt() initialise une nouvelle requête en transmettant l’invite principale.
  • with_file() indique au client IA que nous envoyons une requête multimodale ; il accepte le contenu du fichier au format Base64 ainsi que le type MIME.
  • using_temperature() vous permet de spécifier le niveau de déterminisme de la réponse. Nous définissons une valeur faible afin d’obtenir une transcription fidèle de l’audio.
  • La méthode is_supported_for_text_generation() vérifie si le fournisseur d’IA est capable de générer du texte à partir des données fournies ; si le fournisseur ne prend pas en charge les entrées multimodales, l’extension s’arrête et renvoie un message d’erreur.
  • La méthode generate_text() lance la requête HTTP.

3. Conversion de la transcription audio en contenu structuré

Maintenant que nous disposons de la transcription, l’extension doit à nouveau communiquer avec le fournisseur d’IA afin d’obtenir une réponse JSON structurée. Pour cela, nous devons définir un tableau structuré au format JSON.

$schema = array(
	'type'       => 'object',
	'properties' => array(
		'title'    => array( 'type' => 'string' ),
		'sections' => array(
			'type'  => 'array',
			'items' => array(
				'type'       => 'object',
				'properties' => array(
					'heading'    => array( 'type' => 'string' ),
					'level'      => array(
						'type' => 'integer',
					),
					'paragraphs' => array(
						'type'  => 'array',
						'items' => array( 'type' => 'string' ),
					),
					'bullet_points' => array(
						'type'  => 'array',
						'items' => array( 'type' => 'string' ),
					),
				),
				'required'   => array( 'heading', 'level', 'paragraphs' ),
			),
		),
	),
	'required'   => array( 'title', 'sections' ),
);

Grâce à cette structure, l’IA répondra par un objet JSON contenant un titre et un tableau de sections. Chaque section doit comporter un en-tête, un niveau d’en-tête, au moins un paragraphe et des puces.

Le schéma étant désormais défini, nous pouvons passer à la configuration de la deuxième requête adressée au client IA :

$structured_json = wp_ai_client_prompt(
	"Convert the following transcript into a concise, blog-ready draft in $output_language.n" .
	"Return JSON with a post title and body sections.n" .
	"Each section must have: heading, level (2 or 3), and paragraphs (array).n" .
	"If useful, include bullet_points (array) for short actionable lists.n" .
	"Use short, clear headings and readable paragraph text.nn" .
	"Transcript:n" . $transcript
)
	->using_system_instruction( "You are a professional WordPress content editor. Always write in $output_language (use appropriate spelling, grammar, and conventions for that language variant)." )
	->using_temperature( 0.4 )
	->as_json_response( $schema )
	->generate_text();

if ( is_wp_error( $structured_json ) ) {
	return $structured_json;
}

Analysons les points clés de ce code :

  • using_system_instruction() définit la personnalité du modèle.
  • using_temperature( 0.4 ) définit une valeur de « température » plus élevée, ce qui donne à l’IA une plus grande liberté créative pour générer une réponse et produire un texte plus fluide et plus riche.
  • as_json_response( $schema ) demande au client de fournir la réponse dans un format structuré.
  • L’extension s’arrête en cas d’erreur.

L’étape suivante consiste à décoder et à nettoyer les données.

$structured = json_decode( (string) $structured_json, true );

if ( ! is_array( $structured ) ) {
	return new WP_Error(
		'invalid_ai_json',
		'Could not parse structured AI response.',
		array( 'status' => 500 )
	);
}

$normalized = self::normalize_structured_post( $structured );

if ( '' === $normalized['title'] && empty( $normalized['sections'] ) ) {
	return new WP_Error(
		'empty_structured_content',
		'The AI provider returned empty structured content.',
		array( 'status' => 500 )
	);
}

Dans le code ci-dessus :

  • La fonction json_decode() convertit la chaîne JSON en un tableau associatif PHP.
  • Si le JSON est mal formé, la vérification suivante renvoie un code d’état 500 accompagné d’un message d’erreur clair.
  • La méthode statique normalize_structured_post() nettoie et normalise la sortie du fournisseur avant de la transmettre à JavaScript (voir la définition de cette fonction sur GitHub).

Il ne reste plus qu’à transmettre le résultat obtenu à JavaScript afin de générer des blocs Gutenberg natifs.

4. Génération d’une sortie compatible avec Gutenberg

L’étape suivante consiste à mapper la sortie JSON aux blocs Gutenberg natifs. Cette phase s’effectue côté client et est gérée par le fichier editor.js.

Lorsque l’utilisateur sélectionne un fichier audio, le code suivant est déclenché :

function AIContentBuilderSidebar() {

	const [ audioId, setAudioId ] = useState( 0 );
	...

	const onSelectAudio = function ( media ) {
		if ( ! media || ! media.id ) {
			return;
		}
		setAudioId( media.id );
		setAudioLabel( media.title || media.filename || ( 'Audio #'   media.id ) );
		setNotice( null );
	};
	...
}

Ce code récupère l’identifiant du fichier audio enregistré dans la base de données WordPress.

Lorsque l’utilisateur clique sur le bouton « Générer du contenu », la fonction onGenerate() utilise apiFetch() pour envoyer une requête POST au point de terminaison de l’API, en incluant notamment l’identifiant du fichier audio.

const onGenerate = async function () {

	...

	try {
		const response = await apiFetch( {
			path: AICBData.restPath,
			method: 'POST',
			headers: {
				'X-WP-Nonce': AICBData.nonce,
			},
			data: {
				audio_id: audioId,
			},
		} );
		...
	}
	...
}
  • await met temporairement la fonction en pause afin d’éviter que le navigateur ne se bloque pendant l’attente de la réponse de l’IA.
  • Une fois reçu, l’objet JSON est stocké temporairement dans la variable response.

Le contenu de la variable response sera un objet structuré comme suit :

{
	title: "Two Wheels to the Medina: ...",
	sections: [
		{
			heading: "A Well-Deserved Rest in the Red City",
			level: 2,
			paragraphs: [ "On April 24th, our group of seven motorcyclists..." ],
			bullet_points: []
		},
		{
			heading: "Diving into the Medina and Jemaa el-Fnaa",
			level: 2,
			paragraphs: [ "We spent the day exploring the historic Medina..." ],
			bullet_points: [ 
				"Navigating the vibrant, maze-like alleys of the ancient Medina", 
				"Tasting traditional Berber tagines and Moroccan mint tea",
				"Shopping for handmade leather goods, spices, and lanterns in the souks" 
			]
		},
		{...}
	],
	content: "Fallback plain text...",
	transcript: "Full transcript..."
}

Cet objet fournit les données nécessaires à la création des blocs. Cependant, le script peut recevoir soit une chaîne JSON, soit un objet JSON imbriqué dans un autre objet. Par conséquent, une étape de normalisation supplémentaire est nécessaire avant d’extraire les données pour la génération des blocs :

const normalizedSections = normalizeSectionsPayload( response.sections );
  • La fonction normalizeSectionsPayload() normalise les charges utiles incertaines de sections en un tableau. (Voir le code sur GitHub.)

Ensuite, la variable normalizedSections est transmise en tant qu’argument à la fonction qui convertit les champs sections en blocs Gutenberg natifs :

const structuredBlocks = buildBlocksFromSections( normalizedSections );

Voici un extrait de la fonction buildBlocksFromSections() :

function buildBlocksFromSections( sections ) {
	if ( ! Array.isArray( sections ) ) {
		return [];
	}

	const blocks = [];

	sections.forEach( function ( section ) {
		if ( ! section || 'object' !== typeof section ) {
				return;
			}

			const heading =
				( 'string' === typeof section.heading )
					? section.heading.trim()
					: '';

			const level = ( 3 === section.level ) ? 3 : 2;

			if ( heading ) {
				blocks.push(
					createBlock( 'core/heading', {
						content: heading,
						level: level,
					} )
				);
			}

			...

		} );
	return blocks;
}

Dans le code ci-dessus, la boucle forEach() parcourt le tableau de données, en extrayant les champs section.heading et section.level qui seront utilisés par la fonction native createBlock().

Pour connaître le mappage des champs section.paragraphs et section.bullet_points, veuillez vous reporter au code source sur GitHub.

Des possibilités d’extension infinies

L’introduction de l’IA dans WordPress ouvre de tout nouveaux horizons tant pour les administrateurs de sites que pour les développeurs. Alors qu’auparavant, vous deviez construire une infrastructure réseau complète à partir de zéro simplement pour intégrer des fonctionnalités d’IA à votre site WordPress, l’automatisation de votre flux de travail éditorial et l’ajout de fonctionnalités basées sur l’IA sont désormais remarquablement simples.

L’extension présentée en exemple dans la deuxième partie de cet article n’illustre qu’un seul cas d’utilisation. Cependant, elle démontre clairement comment vous pouvez désormais créer des outils qui simplifient considérablement la gestion du site et l’édition de contenu. De plus, cette architecture débloque des fonctionnalités avancées qui étaient auparavant soit trop complexes à mettre en œuvre, soit trop coûteuses.

Et pourtant, nous n’en sommes qu’au début. L’intelligence artificielle est une réalité en pleine évolution qui va sans aucun doute déclencher une vague massive d’innovation.

En parlant d’innovation… Avez-vous déjà essayé l’hébergement Kinsta ? Si vous souhaitez doter votre site web de la meilleure technologie disponible aujourd’hui pour WordPress, essayez Kinsta sans risque ou contactez notre équipe commerciale pour en savoir plus.

Carlo Daniele Kinsta

Carlo est un passionné de webdesign et de développement frontend. Il joue avec WordPress depuis plus de 10 ans, notamment en collaboration avec des universités et des établissements d'enseignement italiens et européens. Il a écrit des dizaines d'articles et de guides sur WordPress, publiés à la fois sur des sites web italiens et internationaux, ainsi que dans des magazines imprimés. Vous pouvez trouver Carlo sur X et LinkedIn.