« Quelles données un agent conversationnel peut-il réellement voir sans qu’on lui ait rien configuré de spécial ? » C’est la question posée par un développeur qui prépare la connexion d’un assistant à une boutique existante, avant même de penser au prompt ou au modèle utilisé. La réponse tient dans une brique déjà présente sur toute installation récente de WooCommerce : la Store API.
Contrairement à l’API REST classique protégée par des clés, la Store API a été conçue pour les blocs Panier et Paiement affichés côté visiteur, donc accessible sans authentification pour les opérations de consultation et de panier. C’est justement ce qui la rend intéressante, et sensible, pour un agent IA relié à une boutique.
Ce que la Store API expose sans authentification
La Store API repose sur le préfixe /wp-json/wc/store/v1/. Les routes principales accessibles en lecture couvrent le catalogue, la recherche, les catégories, le panier de la session en cours et les informations de livraison disponibles. Un agent qui interroge /wc/store/v1/products obtient la liste des produits publiés avec leur prix affiché, leur description, leur image et leur statut de stock, exactement ce qu’un visiteur anonyme verrait sur la boutique.
/wc/store/v1/productset/wc/store/v1/products/{id}: catalogue et fiche produit./wc/store/v1/products/categories: arborescence des catégories./wc/store/v1/cart: contenu du panier lié au cookie de session en cours./wc/store/v1/cart/items: ajout, modification et suppression de lignes de panier./wc/store/v1/cart/coupons: application d’un code promo existant./wc/store/v1/cart/shipping-rates: options de livraison calculées pour l’adresse renseignée./wc/store/v1/checkout: initialisation du paiement, avec authentification requise pour aller au-delà de la simple lecture./wc/store/v1/order/{id}: suivi d’une commande, mais uniquement avec la clé associée à la session ayant créé cette commande.
Ce qui reste hors de portée sans clé applicative
Un point rassure souvent les développeurs qui découvrent cette API : elle ne donne accès ni à la liste des clients, ni à l’historique global des commandes, ni aux coordonnées bancaires évidemment. Un agent qui n’utilise que la Store API sans clé d’application WooCommerce ne peut pas non plus modifier un prix, créer un produit ou consulter le chiffre d’affaires. Ces opérations relèvent de l’API REST d’administration, sous /wp-json/wc/v3/, protégée par des clés consommateur et secrète générées dans Réglages puis Avancé puis API REST.
La distinction est structurante pour concevoir une intégration : la Store API convient à un agent qui aide un visiteur à chercher un produit, comparer un prix ou finaliser un panier déjà commencé. Elle ne convient pas à un agent chargé de piloter la boutique côté back-office, qui a besoin de l’API REST classique et d’une authentification explicite.
Le format des réponses, pensé pour un affichage, pas pour un modèle de langage
Les réponses de la Store API contiennent des champs formatés pour l’affichage : prix déjà mis en forme avec devise, image redimensionnée, texte HTML échappé pour l’insertion dans une page. Un agent qui consomme brut ce format doit filtrer ce bruit avant de le transmettre à un modèle de langage, sous peine de gaspiller du contexte sur des balises inutiles. Un exemple de traitement côté serveur relais :
function extraire_produit_utile( array $produit ) {
return array(
'id' => $produit['id'],
'nom' => $produit['name'],
'prix' => $produit['prices']['price'] / (10 ** $produit['prices']['currency_minor_unit']),
'stock' => $produit['is_in_stock'],
);
}
Ce filtrage évite d’envoyer au modèle des champs comme permalink, images en pleine résolution ou les métadonnées de mise en page, qui n’apportent rien à une réponse conversationnelle et alourdissent inutilement les jetons consommés.
Le panier de session, un piège fréquent en intégration
La Store API attache le panier à un jeton de session transmis dans un en-tête de réponse, le fameux Cart-Token. Un agent qui interroge l’API sans conserver et renvoyer ce jeton à chaque appel crée, sans le savoir, un nouveau panier vide à chaque requête. C’est l’erreur la plus fréquente observée lors des premières intégrations : le produit semble bien ajouté selon la réponse, mais le panier réellement affiché au client reste vide, car la session utilisée n’est pas la même.
Bonne pratique de conservation du jeton
Le jeton reçu dans l’en-tête Cart-Token de la première réponse doit être renvoyé dans l’en-tête Cart-Token de chaque appel suivant pour cette même conversation. Un agent qui gère plusieurs conversations simultanées doit donc stocker ce jeton par utilisateur, jamais de façon globale.
En résumé
La Store API donne à un agent conversationnel exactement ce qu’il faut pour aider un client à chercher, comparer et finaliser un achat déjà engagé, sans jamais lui ouvrir les portes du back-office. Le vrai travail d’intégration ne se joue pas sur les routes disponibles, déjà bien définies, mais sur la gestion du jeton de panier et le filtrage des champs avant de les transmettre au modèle de langage.
