« Combien d’articles ont été publiés cette semaine dans la catégorie Actualités ? » Répondre à cette question sans quitter une interface de chat suppose qu’un modèle de langage puisse interroger directement l’API REST de WordPress. Aucun protocole standard ne permet aujourd’hui de décrire ces capacités de façon uniforme à un LLM : chaque intégration se construit encore à la main, route par route.
Ce tutoriel décrit la mise en place de function calling pour relier un modèle à six routes REST WordPress existantes, sans traiter l’authentification de ces appels, déjà gérée par ailleurs via un jeton d’application dédié.
Le principe du function calling
Le function calling consiste à décrire au modèle, dans un schéma JSON, la liste des fonctions qu’il peut « appeler », avec leurs paramètres attendus. Le modèle ne les exécute jamais lui-même : il renvoie une intention structurée, à charge pour le code applicatif de l’exécuter réellement et de renvoyer le résultat au modèle pour qu’il formule sa réponse finale.
Pour ce test, six routes ont été retenues parmi celles déjà exposées par l’API REST native de WordPress : la liste des articles récents, la recherche par mot-clé, le détail d’un article, la liste des catégories, le comptage d’articles par catégorie, et la liste des commentaires en attente de modération.
Décrire les routes au modèle
Chaque route est décrite comme une fonction indépendante, avec un nom explicite et des paramètres typés :
$fonctions_disponibles = array(
array(
'name' => 'compter_articles_par_categorie',
'description' => 'Compte les articles publiés dans une categorie sur une periode donnee',
'parameters' => array(
'type' => 'object',
'properties' => array(
'categorie' => array( 'type' => 'string' ),
'depuis' => array( 'type' => 'string', 'format' => 'date' ),
),
'required' => array( 'categorie' ),
),
),
);Cette description reste entièrement manuelle : rien n’automatise aujourd’hui la génération de ce schéma à partir des routes existantes de l’API REST WordPress. Ajouter une septième route suppose de rédiger sa description à la main, avec le même soin.
Exécuter l’appel réel
Lorsque le modèle renvoie une intention d’appel, le code applicatif traduit cette intention en requête vers l’API REST WordPress interne :
function executer_appel_fonction( $nom, $arguments ) {
if ( 'compter_articles_par_categorie' === $nom ) {
$reponse = wp_remote_get( rest_url( 'wp/v2/posts' ) . '?' . http_build_query( array(
'category_name' => $arguments['categorie'],
'after' => $arguments['depuis'] ?? '',
'per_page' => 1,
) ) );
$total = wp_remote_retrieve_header( $reponse, 'X-WP-Total' );
return array( 'total' => (int) $total );
}
return array( 'erreur' => 'fonction inconnue' );
}Le résultat brut, ici un simple nombre, est ensuite renvoyé au modèle dans un second appel, à charge pour lui de formuler une phrase compréhensible pour l’utilisateur final plutôt que d’afficher le JSON tel quel.
Les limites observées
- Chaque nouvelle route ajoutée nécessite une description manuelle et un test dédié, sans réutilisation possible d’un projet à l’autre.
- Le modèle choisit parfois la mauvaise fonction quand deux descriptions se ressemblent trop, par exemple entre « compter » et « lister » les articles.
- Aucune norme commune n’existe entre fournisseurs de LLM pour ce schéma de fonctions, obligeant à en maintenir une version par fournisseur testé.
Décrire une API à un modèle de langage, route par route, fonctionne, mais ressemble à écrire une documentation qu’on ne relira jamais soi-même : le jour où un standard commun apparaîtra pour ce genre de description, il fera gagner un temps considérable.
Pour aller plus loin
En l’état, cette approche reste artisanale mais fonctionnelle pour un nombre limité de routes. Elle demande une maintenance manuelle à chaque évolution de l’API sous-jacente, ce qui en limite la scalabilité au-delà d’une dizaine de fonctions décrites. La documentation officielle de l’API REST WordPress, sur developer.wordpress.org, reste la référence pour identifier les routes candidates à ce type d’exposition.
