Quand un agent IA vend en votre nom : connecter Shopify à la stack B2B

Le problème : les agents peuvent acheter, mais votre stack B2B ne peut pas répondre par un devis

Un consommateur qui fait ses achats via ChatGPT ou le Gemini de Google peut désormais découvrir des produits, les ajouter au panier et payer sans ouvrir un onglet de navigateur. L'article de Shopify sur le commerce agentique rapporte qu'au T1 2026, le trafic IA vers les boutiques Shopify a augmenté 8 fois d'une année sur l'autre et les commandes issues de recherches IA ont augmenté de près de 13 fois. Les nouveaux acheteurs passent commande via les canaux IA à un rythme presque double de celui des autres canaux. Les données enterprise de Shopify vont plus loin : les acheteurs référés par l'IA convertissent à des taux près de 50% plus élevés et portent des valeurs de commande moyennes 14% supérieures au trafic de recherche organique.

Pour une marque grand public, c'est un vent porteur. Pour un distributeur B2B de taille intermédiaire qui fait tourner Shopify ou BigCommerce en frontal et NetSuite ou Brightpearl en backend, c'est un problème différent. L'acheteur de l'autre côté de l'agent IA n'est pas un consommateur — c'est un coordinateur d'achats dans une entreprise qui a négocié des paliers tarifaires, des conditions de crédit et des remises sur volume qui n'existent pas dans le catalogue Shopify. L'agent IA voit le prix public. Le client a contractuellement droit à un prix différent. Quand l'agent paie au prix public, le distributeur absorbe la marge ou annule la commande et perd la vente.

Le deuxième problème, c'est l'inventaire. Un devis B2B n'est pas un achat d'impulsion — il passe par des approbations, parfois pendant des jours. L'inventaire en temps réel de Shopify est exact, mais non réservable. Un agent qui cite 200 unités face à un compte live de 240 peut se tromper au moment où le bon de commande arrive, parce que trois autres devis ont consommé le même stock entre-temps. Le pattern du moteur RFQ qui gère cela — réserves de disponibilité atomiques avec TTL, instantanés de politique d'annulation, verrous de taux FX — vit dans l'ERP et la couche de devis, pas dans la vitrine e-commerce.

Le troisième problème est l'attribution. La revue Shopify AI 2026 de Polar Analytics le dit crûment : « chaque outil note son propre devoir, donc le revenu attribué dépasse ce que la boutique a réellement gagné. » Quand ChatGPT, Google AI Mode, Copilot et la propre vitrine du marchand réclament tous la même commande, la ligne de revenu cesse d'être fiable. Pour une équipe financière qui doit rendre compte du mix de canaux à un conseil d'administration, le revenu non attribuable est un problème de reporting, pas un problème de vanité marketing.

Ce que la surface first-party couvre, et ce qu'elle ne couvre pas

Shopify a fait plus de travail d'agents IA first-party que toute autre plateforme de commerce. Le Storefront MCP server expose la découverte de produits, la gestion du panier, les informations de la boutique et la gestion des commandes via Model Context Protocol. Le Customer Accounts MCP server gère le suivi des commandes et les retours. L'Universal Commerce Protocol (UCP), co-développé avec Google et soutenu par Amazon, American Express, Etsy, Mastercard, Meta, Microsoft, Salesforce, Stripe, Target, Walmart et Visa, définit comment les agents IA transigent avec les marchands sur n'importe quelle plateforme et n'importe quel processeur de paiement. Google a présenté le Universal Cart à Google I/O 2026 (19 mai 2026), construit sur un Shopping Graph de plus de 60 milliards de listings de produits, avec un Agent Payments Protocol (AP2) qui permet aux agents de payer dans les limites de dépense et de marque spécifiées par l'utilisateur.

La surface first-party résout le parcours consommateur : un acheteur demande un produit à un agent IA, l'agent le trouve dans Shopify Catalog, l'ajoute au panier et paie via Shopify Checkout. Le marchand reste le marchand de référence. Aucune intégration personnalisée n'est requise pour les produits éligibles — Shopify Catalog auto-syndique les données structurées vers les plateformes IA.

Ce que la surface first-party ne résout pas, c'est le parcours B2B. Le Storefront MCP server expose les données publiques du catalogue. Il n'expose pas la tarification par segment client, les tarifs contractuels négociés, les paliers de quantité en gros, ni les conditions de crédit spécifiques à un compte. Il ne réserve pas l'inventaire — il signale la disponibilité. Il ne réécrit pas la commande acceptée dans NetSuite avec le bon codage GL, la bonne filiale et le bon nexus fiscal. Il ne génère pas un document de devis qu'une équipe d'achats peut joindre à un bon de commande. Il ne produit pas de piste d'audit qui mappe quel canal IA a originé la commande et quels appels d'outils ont exécuté le checkout.

C'est le même pattern structurel qui apparaît dans l'analyse du module MCP NetSuite : le connecteur first-party du fournisseur résout le problème de connexion. Il ne résout pas le problème de couche sémantique — l'écart entre ce que les données disent et ce que l'entreprise signifie. Pour NetSuite, l'écart sémantique est de savoir quels comptes du grand livre constituent le revenu. Pour Shopify B2B, l'écart sémantique est de savoir quel prix s'applique à quel client pour quelle quantité sous quelles conditions.

La solution B2B orchestrée par l'agent

Le pattern de production est un module MCP personnalisé qui se situe entre l'agent IA et la stack B2B complète — Shopify en frontal, NetSuite ou Brightpearl en backend, le graphe du catalogue fournisseur au milieu, et le moteur RFQ qui gère les devis et les réservations. Le Storefront MCP first-party gère la découverte de produits et la mécanique du panier. Le module personnalisé gère la logique commerciale que la vitrine ne connaît pas.

Considérez un distributeur qui vend des composants industriels à trois segments de clients : comptes enterprise avec tarification contractuelle négociée, comptes mid-market avec paliers de volume et acheteurs transactionnels au prix catalogue public. Un agent IA représentant le coordinateur d'achats d'un acheteur enterprise envoie une demande pour 500 unités d'un composant. L'agent ne voit pas un prix public — il voit un point de départ. Le module personnalisé intercepte la demande et fait quatre choses que la surface first-party ne peut pas :

Premièrement, il résout l'identité et le segment du client. L'agent transporte un identifiant de compte (pas une carte de crédit), et le module recherche le palier tarifaire négocié pour ce compte et ce produit. Le prix que l'agent cite est le prix contractuel, pas le prix catalogue. L'architecture du moteur RFQ gère cela via des paliers tarifaires basés sur les segments, chargés depuis le lot d'articles fournisseur et filtrés par seuils de quantité.

Deuxièmement, il acquiert une réserve de disponibilité. Le module appelle l'opération acquire_availability_hold du moteur RFQ contre le compte d'inventaire NetSuite, décrémentant atomiquement la capacité disponible et retournant un jeton de réservation avec un TTL. Le devis est désormais adossé à un stock réel réservé — pas à un compte live qui peut disparaître avant que l'acheteur n'approuve. Si l'acheteur accepte dans la fenêtre, la réserve se confirme sans second décrément. Si le TTL expire, la capacité est restaurée et le prochain devis peut l'utiliser.

Troisièmement, il capture les conditions commerciales. La politique d'annulation, le taux FX (si la monnaie de l'acheteur diffère de celle du fournisseur) et toute promotion temporelle sont gelés au moment du devis. Si le fournisseur resserre les conditions d'annulation en cours de négociation, le devis porte les conditions en vigueur à son émission. Le litige qui s'ensuivrait autrefois n'a pas lieu.

Quatrièmement, il réécrit la commande acceptée dans NetSuite via la bonne surface d'API — SuiteTalk REST pour l'enregistrement de commande, un RESTlet pour la validation personnalisée, SuiteQL pour toute lecture nécessitant des jointures — avec la limite de concurrence respectée, la signature OAuth calculée en interne, et une entrée de log d'audit pour chaque appel d'outil. L'agent ne construit jamais de signature OAuth et ne choisit pas de surface d'API. Il appelle create_order et le module fait le reste.

Où l'humain reste dans la boucle : le module route les résolutions de prix à faible confiance, les commandes sous les garde-fous de marge, et toute demande d'un nouveau compte vers un réviseur humain avant que le devis ne soit envoyé. Le champ guardrail_price_per_uom signale tout devis où une remise fait tomber le prix sous le coût du lot. L'agent propose, l'humain approuve les exceptions, et le log d'audit montre qui a approuvé quoi et quand.

Le résultat

Les améliorations mesurables sont concrètes. Le délai de devis passe de jours à minutes parce que l'agent résout produit, prix et disponibilité en une passe unique plutôt qu'en trois recherches manuelles entre Shopify, la feuille de calcul des prix et NetSuite. La réserve de disponibilité élimine le problème de sur-promesse — un devis est soit adossé à un stock réservé, soit il n'est pas émis. La tarification basée sur les segments élimine l'érosion de marge qui se produit quand un client sous contrat est coté au prix public parce que l'agent ignorait l'existence du contrat. Le log d'audit produit un enregistrement d'attribution de canal qui relie la commande à la plateforme IA d'origine, aux appels d'outils qui l'ont exécutée, et aux approbations humaines qui l'ont modifiée — le problème d'attribution que Polar Analytics identifie comme « chaque outil note son propre devoir » est résolu à la couche du module, pas en faisant confiance au crédit auto-déclaré d'une seule plateforme.

La croissance des commandes de 13 fois d'une année sur l'autre depuis les canaux IA que Shopify rapporte n'est pas une vague que les distributeurs B2B peuvent observer sans agir. Les distributeurs qui la capturent sont ceux dont la couche d'agents connaît la différence entre un checkout consommateur et un devis B2B — et qui dispose du pattern module qui rend le second possible.

Un distributeur qui exploite Shopify en vitrine, NetSuite pour l'ERP et trois catalogues fournisseurs obtient un agent qui reçoit une demande d'un canal d'achats IA, résout le palier tarifaire négocié du client, acquiert une réserve de disponibilité atomique contre l'inventaire NetSuite, capture les conditions d'annulation et de FX, et réécrit la commande acceptée dans NetSuite via la bonne surface d'API — chaque appel d'outil étant tracé et chaque exception routée vers un réviseur humain. Ce build est la Phase 2-3 de la méthode en quatre étapes et est généralement en ligne en 5 à 8 semaines.

Demandez un build cadré. Discovery d'une semaine. Vous obtenez un inventaire des systèmes, une cartographie des flux et un périmètre fixe — que vous construisiez avec nous ou non.