Commerce par agents (MCP)

STOAR embarque une surface Model Context Protocol intégrée pour que les agents d’achat IA — ChatGPT, Claude et tout autre client MCP — puissent découvrir ta boutique, parcourir son catalogue, répondre aux questions depuis tes politiques publiées, constituer un panier, chiffrer un total livré réel et remettre au client un lien sécurisé pour finaliser le paiement dans son navigateur. Avec le consentement explicite du client, un agent peut aussi consulter ensuite ses commandes.

C’est le même socle que la boutique et les API REST, exposé comme un adaptateur de protocole de plus. Rien de nouveau n’est inventé en coulisses : un panier construit par un agent est un panier invité normal, et un prix provient du même calculateur que celui de l’encaissement — le chiffre qu’un agent annonce est donc celui qui sera facturé.

Deux serveurs #

C’est l’ensemble de la couche côté acheteur. Les opérations marchand et admin — modifier des produits, rembourser des commandes, changer les stocks — ne sont délibérément pas exposées aux agents.

Opt-in, et désactivé par défaut #

Le commerce par agents est opt-in. Les deux serveurs restent désactivés tant que tu ne les actives pas, et une boutique qui n’a pas adhéré répond 404 — elle n’est même pas détectable comme hôte MCP. Active-les dans Manager → Agent Access (MCP), où tu contrôles aussi :

• lequel des deux serveurs est actif ;
• si les agents doivent s’identifier avant d’agir ;
• les plafonds de panier (quantité max par ligne, nombre de lignes, valeur max) ;
• la durée de validité d’un lien d’encaissement de transfert ;
• les limites de débit et de taille des résultats.

Les changements s’appliquent à la requête suivante — sans déploiement. Rien sur l’un ou l’autre serveur ne peut passer une commande, encaisser un paiement ou modifier une commande existante. L’argent ne bouge qu’une fois le paiement finalisé par un humain dans son propre navigateur.

Démarrage rapide #

Le serveur est monté par boutique sur le domaine de la requête, exactement comme l’API REST :

https://{ton-domaine-boutique}/mcp

Pointe n’importe quel client MCP dessus, ou liste les outils directement :

curl -s https://app.stoar.ai/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Un parcours d’achat minimal tient en cinq appels : apprendre une fois les conditions de la boutique, trouver un produit, lire ses déclinaisons, constituer un panier, puis chiffrer un total livré et remettre au client cart.continue_url.

Outils #

Catalogue

Politiques

Panier

Tous les outils de panier sont adressés par le jeton cart_id renvoyé par create_cart.

Les outils de panier sont ciblés, pas des remplacements complets : chaque appel ne nomme que ce qu’il touche, si bien qu’un agent confus peut échouer à agir mais ne peut pas perdre en silence une ligne qu’il a oublié de renvoyer. Chaque mutation renvoie le panier complet. Chaque mutation est idempotente — renvoyer la même requête restitue le résultat d’origine au lieu de l’appliquer deux fois.

Commandes

Le transfert #

Un agent construit un panier qu’il ne pourra jamais payer. cart.continue_url est la façon dont ce panier devient un achat réel : le client l’ouvre dans son navigateur, le panier se charge dans sa session, et il arrive dans l’encaissement normal. Le lien est signé, à durée limitée, restreint à une boutique et ne porte jamais qu’un panier invité — jamais le panier d’un client connecté ni ses adresses enregistrées.

Modèle de sécurité #

• /mcp est non authentifié par conception. Tout ce qu’il expose est soit déjà public (catalogue, politiques), soit adressé par un jeton impossible à deviner (un panier, ou une commande avec son jeton de suivi envoyé par e-mail). Aucun dossier client, aucun historique de commandes, aucune donnée de paiement ou d’adresse n’est accessible sans l’identifiant propre du client.
• /mcp/account exige un jeton client que le client crée lui-même, limité à une seule capacité en lecture seule. Ce n’est pas un identifiant admin et il ne peut piloter aucune autre API.
• Le suivi de commande invité est protégé par jeton, pas par e-mail + numéro. Les numéros de commande sont séquentiels : une vérification par e-mail exposée à une machine permettrait d’énumérer l’historique d’achat d’un tiers. Le jeton propre à chaque commande figure déjà dans l’e-mail de confirmation — rien de nouveau n’est émis ni divulgué.
• Les prix masqués aux invités restent masqués. Sur une boutique B2B qui masque les prix aux visiteurs non connectés, les agents voient la même occultation et la constitution du panier est désactivée plutôt que de produire un panier de valeur inconnue.
• Le locataire est résolu depuis le domaine de la requête et ne peut être remplacé par aucun argument, si bien que l’agent d’une boutique n’atteint jamais le catalogue ou le panier d’une autre.

Le mesurer #

Quand l’accès agent est activé, le tableau de bord affiche les paniers, commandes et chiffre d’affaires agents (net de remboursements) sur 30 jours, ainsi que l’agent principal par nombre de commandes — pour répondre à la première question que tout le monde se pose sur le commerce par agents : est-ce que ça vend ?

Comparaison avec Shopify #

Shopify a abandonné son MCP Storefront au profit de l’Universal Commerce Protocol, dont le paiement par agent est une préversion réservée aux partenaires. STOAR livre aujourd’hui la surface complète côté acheteur et ajoute plusieurs choses sans équivalent dans UCP :

• get_store_info — sinon les agents devinent les destinations de livraison, les moyens de paiement et la fenêtre de retour.
• estimate_shipping — un total livré issu du vrai calculateur d’encaissement, pas un simple sous-total.
• Suivi de commande invité — celui de Shopify est réservé aux connectés, donc les commandes invité (une large part du trafic réel) n’ont rien.
• Modifications de panier ciblées au lieu d’un update_cart à remplacement complet qui supprime en silence toute ligne que l’agent oublie de renvoyer.
• Idempotence sur chaque mutation, pas seulement l’annulation.
• Substituts en stock lorsqu’un article est indisponible.

Limites actuelles #

• Pas de retours, annulations ni changements d’adresse via MCP. Ce sont des actions irréversibles qui relèvent d’une confirmation humaine explicite que le transport ne peut pas encore garantir ; les agents renvoient le client vers la page de compte.
• Les lots et abonnements sont lisibles mais non achetables via un agent — les deux sont signalés pour que l’agent oriente le client vers la page produit plutôt que d’ajouter la mauvaise chose au mauvais prix.
• Le statut de commande est saisi par le marchand — un numéro de suivi par commande, sans intégration transporteur en direct, et la note de statut est signalée comme potentiellement obsolète.
• Le contenu des politiques suit les pages traduites de la boutique, donc le modifier demande un déploiement plutôt qu’une édition dans le Manager.

Voir aussi #

• Adaptateurs d’API REST — les façades Magento, Shopify, WooCommerce et BigCommerce sur le même socle
• Panier & encaissement — le panier boutique vers lequel un agent transfère
• Assistant d’achat IA — le chat en boutique qui répond directement aux clients, le pendant de cette surface côté agent