Shopify Draft Order vs Storefront Cart : le fallback B2B

Un assistant conversationnel qui prépare des paniers Shopify semble simple en surface. Le visiteur demande un produit, l'IA le trouve dans le catalogue, un lien de checkout apparaît. Affaire réglée.

Sauf que ce flux mono-chemin casse dès qu'un client professionnel entre en jeu. Il veut un devis, un tarif négocié, ou une commande de 40 unités avec une remise volume. Le lien /cart/c/... ne sait pas faire ça. Et si votre assistant n'a pas de fallback, la conversation se termine en impasse.

Cet article explique pourquoi le panier B2B Shopify exige deux chemins distincts, comment les router proprement, et ce que ça change concrètement pour un assistant IA qui veut couvrir un catalogue mixte B2C/B2B.

---

Deux API, deux philosophies de checkout

Storefront API : le checkout B2C natif

La Storefront API de Shopify expose un endpoint cartCreate qui génère un panier persistant côté serveur. Le résultat est une URL du type /cart/c/{token} que vous pouvez envoyer directement au visiteur.

Ce chemin est optimal pour le B2C standard :

• Le panier est lié à la session du visiteur.

• Le checkout Shopify natif s'affiche avec les méthodes de paiement configurées par le marchand.

• Les apps de conversion (upsell, récupération de panier abandonné) s'y branchent sans friction.

• Le visiteur clique, paie, c'est terminé.

Pour un assistant conversationnel qui gère des demandes comme « je cherche une veste imperméable taille M », c'est le chemin idéal. Rapide, sans friction, compatible avec tous les thèmes Shopify.

recommandation produits contextuelle Shopify

Draft Order : le document de vente programmable

Le Draft Order Shopify est un objet différent. Il vit dans l'Admin API, pas dans la Storefront API. C'est fondamentalement un document de vente que le marchand (ou son système) crée manuellement, avec une flexibilité totale :

• Remises fixes ou en pourcentage sur chaque ligne.

• Prix unitaire personnalisé (override du prix catalogue).

• Ajout de frais de service ou de taxes spécifiques.

• Envoi d'un lien de paiement sécurisé par email au client.

• Possibilité de convertir en commande sans que le client passe par le checkout standard.

C'est l'outil natif de Shopify pour les scénarios B2B, les devis, les commandes sur-mesure et les ventes assistées. Documentation officielle Draft Orders – Shopify Admin API

La différence clé : un cartCreate Storefront est anonyme et immédiat. Un Draft Order est nominatif et négociable.

---

Pourquoi un chatbot mono-flow casse sur le B2B

Imaginez un marchand qui vend à la fois en direct aux particuliers et aux revendeurs. Son catalogue Shopify est unique. Ses prix catalogue sont publics. Mais ses clients pro bénéficient de remises allant de 15 à 30% selon le volume.

Un assistant qui utilise uniquement la Storefront API va :

1. Trouver les bons produits dans le catalogue (ça, il sait faire).

2. Créer un panier au prix public.

3. Envoyer le lien /cart/c/... au client pro.

4. Recevoir un message : « Mais on avait convenu d'un tarif à -20%... »

Le flow est brisé. Le client doit contacter le SAV pour corriger la commande. L'assistant a créé plus de friction qu'il n'en a résolu.

Le problème n'est pas l'IA. C'est l'absence de routage conditionnel selon le profil du client et la nature de la demande.

Les signaux qui déclenchent le fallback Draft Order

Plusieurs situations justifient de basculer du chemin Storefront vers le chemin Draft Order :

• Le client demande un devis explicitement : « Vous faites des tarifs pour les professionnels ? », « Je veux commander 50 unités, quel est le prix ? »

• Le client est authentifié et tagué B2B côté Shopify (tag wholesale, pro, reseller, etc.).

• La demande implique un discount custom non disponible dans les règles de prix publiques du catalogue.

• La quantité dépasse un seuil défini par le marchand (ex. : commandes > 10 unités sur certaines références).

• Le produit est en mode « sur devis » (prix non affiché publiquement).

Chacun de ces signaux doit être détecté avant de choisir le chemin de création du panier.

---

Le routage côté Navi : deux chemins, un seul flow conversationnel

Navi gère nativement ce double chemin. Voici comment le routage fonctionne en pratique.

Chemin 1 : Storefront cart (B2C standard)

Quand aucun signal B2B n'est détecté, Navi utilise la Storefront API pour créer le panier :

1. Le visiteur décrit son besoin.

2. Navi interroge le catalogue via Storefront API (recherche vectorielle + filtres).

3. Les produits pertinents s'affichent en carrousel dans le chat.

4. Le visiteur sélectionne ses articles.

5. Navi appelle cartCreate et retourne un lien /cart/c/{token} cliquable directement dans la conversation.

6. Un seul clic amène le visiteur sur le checkout Shopify natif de la boutique, prêt à payer.

Pas d'étape intermédiaire, pas de redirection inutile. Le checkout conversationnel Shopify est aussi fluide qu'un bouton « Ajouter au panier » classique.

Chemin 2 : Draft Order (fallback B2B)

Dès qu'un signal B2B est détecté (tag client, demande de devis, quantité seuil), Navi bascule sur le chemin Draft Order via l'Admin API :

1. Les mêmes produits sont identifiés dans le catalogue.

2. Navi crée un Draft Order avec les lignes de commande, les quantités, et les remises applicables.

3. Le Draft Order apparaît dans l'admin Shopify du marchand, comme s'il l'avait créé à la main.

4. Un lien de paiement sécurisé est généré et envoyé au client (par email ou directement dans le chat).

5. Le marchand peut ajuster le Draft Order avant validation si nécessaire.

Le client pro reçoit un document de vente propre. Le marchand garde la main sur la validation finale. Et l'assistant n'a jamais quitté la conversation.

authentification OTP et accès commandes temps réel

La logique de routage en pseudocode

si client_tag inclut ["wholesale", "pro", "b2b"]

→ Draft Order

sinon si intent contient ["devis", "tarif pro", "commande en volume"]

→ Draft Order

sinon si quantité_demandée > seuil_marchand

→ Draft Order

sinon

→ Storefront cart

Ce routage est transparent pour le visiteur. La conversation ne change pas d'apparence. Seul le chemin technique diverge en arrière-plan.

---

Cas d'usage concrets

Un revendeur qui commande en volume

On peut imaginer un marchand dans la verticale beauté qui vend à la fois aux particuliers et aux instituts. Un gérant d'institut ouvre le chat et écrit : « Je veux commander 30 flacons du sérum X pour mon stock, vous avez des tarifs professionnels ? »

Sans routage B2B, l'assistant crée un panier Storefront à prix public. Le gérant voit le total, est surpris, et abandonne.

Avec le routage Draft Order, Navi détecte la quantité et le mot « tarifs professionnels », crée un Draft Order avec la remise volume configurée par le marchand, et envoie un lien de paiement personnalisé. La commande est validée sans intervention humaine.

Un client qui demande un devis pour un projet custom

Un acheteur en maison d'édition veut commander des carnets personnalisés avec logo. Il écrit : « Vous faites du sur-mesure ? Je voudrais un devis pour 200 carnets. »

Le Storefront cart ne peut pas gérer ce cas (pas de prix catalogue pour du sur-mesure). Navi bascule sur Draft Order, crée une ligne avec le produit de base et une note « personnalisation logo à confirmer », et le marchand reçoit le Draft Order dans son admin pour le compléter et l'envoyer.

L'assistant a capturé le lead et structuré la demande. Le marchand n'a plus qu'à finaliser.

flow retours automatisés et gestion SAV Shopify

---

Ce que ça change pour les développeurs Shopify

Si vous développez ou configurez un assistant conversationnel sur Shopify, voici les points techniques à retenir.

Permissions API nécessaires

• Storefront API : access token public (read_products, read_inventory). Pas besoin de token Admin.

• Draft Orders : Admin API avec scope write_draft_orders. Ce scope nécessite une app Shopify avec OAuth, pas un simple token Storefront.

Cette différence de permissions est souvent sous-estimée. Un chatbot qui n'a qu'un token Storefront ne peut pas créer de Draft Orders. Il faut prévoir les deux dès l'architecture.

Idempotence et gestion des doublons

Un visiteur qui clique deux fois sur « Créer mon devis » ne doit pas générer deux Draft Orders. Côté Navi, chaque Draft Order est créé dans une transaction atomique avec vérification d'idempotence par conversation ID. C'est un détail d'implémentation qui évite des situations embarrassantes côté admin marchand.

Webhooks et cycle de vie du Draft Order

Un Draft Order peut rester ouvert des jours. Il faut gérer les webhooks draft_orders/update et draft_orders/delete pour maintenir la cohérence entre l'état dans votre système et l'état dans Shopify. Sans ça, votre assistant peut référencer un Draft Order que le marchand a déjà supprimé ou converti en commande.

Webhooks Draft Orders – Shopify Developer Documentation

---

Bénéfices pour le marchand mixte B2B/B2C

Gérer les deux chemins de panier n'est pas un luxe technique. C'est une condition pour qu'un assistant conversationnel soit réellement utile sur une boutique mixte.