---
title: "Intégration ERP, CRM et PIM pour les devis B2B Shopify : les patterns qui tiennent"
description: "Quel système écrit chaque champ, comment un devis atteint l'ERP en commande et le CRM en événement, les clés sur la commande, ce qui attend une API."
url: "https://www.quotway.com/fr/blog/shopify-b2b-erp-crm-pim-integration-patterns"
type: "blog post"
category: "For Shopify agencies"
published: "2026-09-22"
verified: "2026-09-22"
shopify_api_version: "2026-07"
audience: "Agences Shopify, architectes solution et développeurs d'intégration"
scope: "Qui écrit chaque champ entre PIM, ERP, CRM, Shopify et une couche de devis ; externalId des entreprises, listes de prix des catalogues, Flow et les webhooks orders/* en API 2026-07 ; ce que porte une commande issue d'un devis ; des patterns, pas des connecteurs"
locale: "fr"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# Intégration ERP, CRM et PIM pour les devis B2B Shopify : les patterns qui tiennent

Une couche de devis B2B sur Shopify ne doit pas être branchée directement sur l'ERP, le CRM ou le PIM. Elle se branche sur Shopify, et Shopify sur le reste : le devis atteint l'ERP sous la forme de la commande qu'il devient, il atteint le CRM sous la forme des événements qu'il émet, et il n'atteint jamais le PIM, parce qu'il lit les données produit dans Shopify comme toute autre partie de la boutique. Ce n'est pas un raccourci. C'est la seule disposition dans laquelle chaque champ a un seul écrivain, et c'est celle pour laquelle le connecteur Shopify-ERP que la boutique fait déjà tourner a été conçu.

Cette page expose le pattern pour l'agence qui cadre l'intégration : quel système possède quel champ, les clés d'identité à fixer avant la moindre synchronisation, les trois portes par lesquelles un devis peut sortir de la boutique aujourd'hui et ce que chacune transporte, le flux de listes de prix ERP → Shopify dont la couche de devis dépend, les modes de défaillance propres au devis, et dix questions à trancher dans le cahier des charges. Il s'agit de patterns, pas de connecteurs : la page ne déclare aucun produit « intégré » et, là où une capacité n'existe pas encore, le dit. Les exemples sont les systèmes que le marché francophone cherche : Sage 100 et X3, Cegid, Odoo, Dynamics 365 Business Central, HubSpot, Akeneo et Pimcore - sans revendiquer de connecteur prêt à l'emploi pour aucun d'eux.

Tout ce qui concerne Shopify ci-dessous a été vérifié sur les pages de Shopify le 22 septembre 2026, en version d'API 2026-07 ; les sources sont en fin de page. Là où la page décrit ce que QuotWay écrit et expose, il s'agit d'une implémentation du pattern, signalée comme telle.

## Qui possède quoi
Une intégration est une liste de champs et, pour chacun, le seul système autorisé à l'écrire. Tout le reste du projet - cadence, transport, gestion des erreurs - découle de cette liste, et la plupart des incidents d'intégration remontent à un champ qui a deux écrivains. Pour une boutique B2B Shopify avec une couche de devis, la liste tient dans un tableau.

| Champ | Écrivain (système de référence) | Où il atterrit dans Shopify | Qui le lit | Cadence typique |
| --- | --- | --- | --- | --- |
| Contenu produit : titres, descriptions, médias, attributs | PIM (ou Shopify lui-même en l'absence de PIM) | `Product`, `ProductVariant`, métachamps | Vitrine, couche de devis, ERP par SKU | Lot, à la modification |
| Existence de la variante et SKU | PIM ou fichier articles de l'ERP | `ProductVariant.sku` | Tout | Lot, à la modification |
| Prix de base | ERP | `ProductVariant.price` | Vitrine, catalogues, couche de devis | Lot, quotidien ou à la modification |
| Prix spécifiques au client et règles de quantité | ERP | Listes de prix des catalogues (`PriceList`), règles de quantité | Vitrine pour le site connecté, couche de devis comme prix de départ | Lot, à la modification |
| Stock | ERP ou WMS | `InventoryLevel` par emplacement | Vitrine, paiement, pré-vérification de la conversion | Quasi temps réel |
| Entreprise, sites, adresses, numéro fiscal, exonérations, conditions de paiement, réglages de paiement | Fichier clients de l'ERP | `Company`, `CompanyLocation` (avec `externalId`), `BuyerExperienceConfiguration` | Vitrine, paiement, couche de devis via `purchasingEntity` | Lot, à la modification |
| Contacts et leurs rôles | CRM ou ERP, un des deux | `CompanyContact`, `Customer` | Connexion, couche de devis | À la modification |
| Le prix et les conditions négociés d'une affaire | **La couche de devis** - la version scellée acceptée | La commande provisoire qu'elle crée à la conversion | Le paiement Shopify, puis l'ERP en tant que commande | Une fois, à l'acceptation |
| La commande et son état | Shopify | `Order` | L'ERP via le connecteur ; le CRM comme issue de l'affaire | Événement, webhooks `orders/*` |
| Statut d'expédition et d'encaissement | ERP ou WMS écrivant en retour dans Shopify | `Fulfillment`, transactions | Compte client, notifications | Événement |
| Pipeline : affaire, étape, responsable, prévision | CRM | Rien - cela reste dans le CRM | Direction commerciale | Événement, depuis les événements de devis |

Deux choses dans ce tableau font le travail. La couche de devis possède exactement une ligne - l'enregistrement de ce que les deux parties ont convenu - et lit tout le reste. Et Shopify est le point de rencontre de chaque autre ligne : le PIM y écrit les produits, l'ERP y écrit les prix, le stock et les entreprises, et l'ERP y lit les commandes. Rien n'écrit dans la couche de devis, et la couche de devis n'écrit dans rien d'autre que Shopify. Un devis n'est pas quelque chose que l'ERP reçoit ; une commande, si.

Cela répond aussi à une question que les données de recherche sur ce sujet font remonter sans cesse : Shopify n'est pas un ERP. C'est le système de référence des produits tels qu'ils sont vendus, des clients tels qu'ils achètent et des commandes telles qu'elles sont passées, et il ne détient délibérément rien sur les achats, la comptabilité générale, les coûts ou la production. L'ERP reste le maître des prix, du stock et de l'identité commerciale du client, et le tableau ci-dessus le fait écrire ces éléments dans Shopify, jamais l'inverse.

## Les clés d'identité avant tout
Une synchronisation qui ne sait pas dire « cette entreprise Shopify *est* ce client ERP » finit avec une table de correspondance que personne ne maintient. Shopify donne à chaque objet B2B un champ prévu exactement pour cela, donc on fixe les clés d'abord.

- **Entreprises et sites.** `CompanyInput.externalId` est « un identifiant unique fourni de l'extérieur pour l'entreprise », et `CompanyLocationInput.externalId` la même chose pour le site. Mettez le numéro client de l'ERP sur l'entreprise et l'identifiant de l'adresse de livraison ou de facturation de l'ERP sur chaque site. La requête `companies` filtre sur `external_id`, donc le connecteur retrouve l'enregistrement dont il a besoin sans table à lui. Pour tout ce que l'ERP a besoin d'ajouter au-delà d'un identifiant - un groupe tarifaire, un code représentant, une limite de crédit - utilisez les métachamps : `COMPANY` et `COMPANY_LOCATION` sont des types de propriétaire de métachamp, et la même requête filtre sur `metafields.{namespace}.{key}`.
- **Produits.** Ne rapprochez sur le SKU que si l'ERP garantit qu'il est unique sur toutes les variantes qu'il exporte ; sinon, portez l'identifiant article de l'ERP dans un métachamp de variante et rapprochez dessus. Une ligne de devis référence une variante Shopify, donc la clé que l'ERP utilise pour l'article doit se résoudre en une variante avant que la couche de devis n'intervienne.
- **Commandes issues de devis.** C'est la clé que la couche de devis doit fournir, parce que rien dans Shopify ne marque une commande comme issue d'un devis. QuotWay écrit deux tags sur chaque commande provisoire qu'il crée - `quotway` et `quotway-<référence>`, par exemple `quotway-QW-1042` - et Shopify reporte les tags de la commande provisoire sur la commande « lorsque vous créez une commande à partir d'une commande provisoire ». Les tags de commande sont limités à 40 caractères et aux lettres, chiffres et traits d'union, ce qu'une référence par défaut respecte ; un préfixe de référence personnalisé doit le respecter aussi. La commande provisoire porte également un attribut de commande visible par l'acheteur, `quotway_conversion_group_id`, que QuotWay lui-même relit dans la charge utile de `orders/create` pour rattacher la commande au devis - c'est donc la clé à utiliser pour le même usage dans l'ERP.

La seule clé à ne pas utiliser est `sourceName`. Une commande finalisée depuis la section des commandes provisoires de l'admin rapporte `shopify_draft_order` ; la même commande provisoire finalisée par l'acheteur depuis la facture rapporte `web` ; finalisée par une application, elle rapporte l'identifiant de l'application. C'est la description que Shopify donne lui-même du comportement du champ, et elle signifie qu'un filtre sur `sourceName` trouvera certaines commandes issues de devis et manquera les autres selon qui a cliqué.

## Les trois portes
> **Un écrivain par champ : comment le PIM, l'ERP, le CRM et la couche de devis se relient via Shopify**
>
> Shopify est au centre et détient les produits, les catalogues et listes de prix, le stock, les entreprises et sites, et les commandes. À gauche, le PIM écrit le contenu produit dans les produits Shopify et l'ERP écrit les prix dans les catalogues, le stock dans les niveaux de stock et le fichier clients dans les entreprises et sites. En bas, la couche de devis lit les variantes, les prix catalogue et les entreprises dans Shopify et écrit une seule chose : une commande provisoire à la conversion, taguée avec la référence du devis. À droite, trois portes sortent de la boutique. Porte 1 : les commandes Shopify vont à l'ERP par le connecteur existant, avec les tags, la note, les attributs, l'entité acheteuse, les conditions de paiement et la devise. Porte 2 : les événements de devis vont par Shopify Flow au CRM ou à n'importe quel point de terminaison HTTP, avec des champs au niveau du devis mais sans lignes. Porte 3 : un export CSV des devis part vers la finance ou la BI par lots. Une flèche en pointillés marquée « nécessite une API - pas encore » va des lignes de la couche de devis vers l'ERP.
>
> Le PIM et l'ERP écrivent dans Shopify ; la couche de devis y lit et écrit une commande provisoire ; l'ERP, le CRM et la finance reçoivent chacun le devis par la porte qui correspond à leur besoin.

Un devis peut sortir de la boutique par trois portes aujourd'hui. Chacune transporte une forme de données différente, et choisir la mauvaise porte pour une exigence est la façon dont un projet finit par construire quelque chose que la boutique ne peut pas porter.

### Porte 1 : l'ERP reçoit la commande
L'ERP a besoin du devis à un seul moment - quand il devient quelque chose à expédier et à facturer - et à ce moment-là, c'est une commande Shopify. L'ERP le prend donc par ce qui déplace déjà les commandes : un connecteur certifié, un connecteur tiers pour Sage, Cegid ou Odoo tel que le marché les cherche, une plateforme iPaaS, ou un abonnement aux webhooks `orders/create`, `orders/updated`, `orders/edited`, `orders/paid`, `orders/cancelled` et `orders/fulfilled`. La couche de devis ne change rien à ce chemin ; ce qu'elle ajoute, c'est l'identification sur la commande, pour que l'ERP distingue une commande issue d'un devis d'une commande de la vitrine et la relie à l'affaire.

Ce que porte une commande issue de QuotWay, telle que sa conversion la crée en API 2026-07 :

| Sur la commande | Valeur | Visible par | Usage dans l'ERP |
| --- | --- | --- | --- |
| Tag | `quotway` | Admin, connecteur | Router les commandes issues de devis vers leur propre flux |
| Tag | `quotway-<référence>`, par ex. `quotway-QW-1042` | Admin, connecteur | Le numéro de devis, comme clé |
| Note (marchand seulement) | `QuotWay quote QW-1042 v3`, puis l'éventuelle note interne | Admin, connecteur | Le numéro de la version acceptée, pour l'audit |
| Attribut de commande | `quotway_conversion_group_id` | Acheteur et admin | La clé d'idempotence d'une conversion ; dédoublonner dessus |
| Attributs de commande | `Special requests`, puis chaque champ de formulaire renseigné en `libellé : valeur` | Acheteur et admin | Les instructions de l'acheteur et tout champ collecté par le formulaire, comme une référence qu'il a saisie |
| Propriété de ligne | `Customer note` sur les lignes annotées par l'acheteur | Acheteur et admin | Instructions par ligne |
| `purchasingEntity` | Entreprise, site, contact - pour les devis liés à une entreprise | Connecteur | Le client ERP, via l'`externalId` du site |
| `paymentTerms` | Les conditions du site telles qu'appliquées à la commande provisoire | Connecteur | Échéance et créances |
| `presentmentCurrencyCode`, `currencyCode`, `totalPriceSet` | La devise du devis, la devise de la boutique, les totaux dans les deux | Connecteur | Comptabiliser dans la bonne devise (voir les modes de défaillance) |
| `poNumber` | Seulement si le marchand l'a ajouté à la commande provisoire ou si l'acheteur l'a saisi au paiement ; la conversion ne l'écrit pas | Connecteur | Rapprochement du bon de commande |

Deux remarques sur ce tableau. La couche de devis ne renseigne pas `poNumber`. Le formulaire de demande de QuotWay a un champ intégré pour le numéro de bon de commande ; la valeur reste sur le devis et s'affiche dans l'admin, mais la conversion ne la transmet pas à la commande provisoire aujourd'hui - ni dans `DraftOrderInput.poNumber` ni en attribut ; seul un champ de formulaire *personnalisé* atteint la commande, en attribut sous son libellé. Un marchand qui a besoin du bon de commande sur la commande Shopify l'ajoute à la commande provisoire avant d'envoyer la facture, et une correspondance ERP ne doit pas l'attendre du devis. Et les attributs sont le mécanisme sur lequel QuotWay s'appuie pour sa propre comptabilité - son gestionnaire lit `quotway_conversion_group_id` dans la charge utile de `orders/create` pour marquer le devis converti - donc une correspondance ERP construite sur le même attribut repose sur le comportement dont l'application dépend en production.

Quel connecteur transporte la commande est la décision de la boutique, pas celle de la couche de devis. Le Global ERP Program de Shopify liste aujourd'hui cinq applications certifiées - Dynamics 365 Business Central, Brightpearl by Sage, NetSuite ERP Connector, Acumatica Cloud ERP et Infor eCommerce Connector - et a décrit le périmètre du programme à son lancement comme « stock, produits, commandes et informations client ». Sur le marché francophone s'ajoute ce que montrent les données de recherche : Sage 100, Sage X3, Cegid, Odoo. Qu'un connecteur donné écrive aussi les entreprises, les sites et les listes de prix des catalogues est une question propre à chaque connecteur, et la réponse décide si les lignes ERP → Shopify du tableau de propriété passent par le connecteur ou par l'API Admin. La note de Shopify dans l'Edition Spring '26, selon laquelle QuickBooks synchronise les commandes B2B, les numéros de bon de commande et les données d'entreprise, est le genre de phrase à chercher dans la documentation d'un connecteur avant de le supposer.

### Porte 2 : le CRM reçoit des événements
L'objet d'un CRM est l'affaire, et une affaire change par événements : créée, proposition envoyée, en négociation, gagnée, perdue. C'est la forme du cycle de vie d'un devis, et c'est ce que transporte Shopify Flow. QuotWay expose dix déclencheurs à Flow à partir du forfait Professional - soumis, proposition envoyée, contre-offre, accepté, refusé, expiré, converti, approbation demandée, accordée et rejetée - chacun avec des champs au niveau du devis : l'identifiant, le numéro, un lien profond vers le devis dans l'admin, le statut, le total et la devise, qui a agi et quand, l'identifiant client Shopify (vide pour les demandes invités) et l'e-mail de l'acheteur, toujours présent. Certains déclencheurs ajoutent le numéro de tour, si l'acceptation était totale ou partielle et le total accepté, l'identifiant de la commande provisoire à la conversion, et si une approbation était celle du marchand ou celle de l'acheteur.

Depuis un déclencheur, le workflow atteint le CRM de deux façons. Les connecteurs intégrés de Flow (Slack, e-mail, Google Sheets et les applications qui ont enregistré des actions) couvrent directement les cas de notification. Pour un CRM sans action Flow, **Envoyer une requête HTTP** poste les champs du déclencheur vers n'importe quel point de terminaison - l'API du CRM ou le webhook d'une plateforme iPaaS - en GET, POST, PUT, PATCH et DELETE, avec une fenêtre de 30 secondes pour la réponse et une politique de nouvelle tentative par classe de statut qui peut réessayer jusqu'à 24 heures. Flow lui-même est gratuit sur Basic, Grow, Advanced et Plus ; l'action HTTP nécessite Grow, Advanced ou Plus.

La correspondance, sous forme de tableau que l'administrateur du CRM peut vérifier :

| Événement de devis | Effet dans le CRM |
| --- | --- |
| Devis soumis | Créer ou mettre à jour l'affaire ; rattacher le contact par e-mail, ou par identifiant client s'il est présent |
| Proposition envoyée | Étape : proposition ; montant : le total de la proposition |
| Contre-offre | Étape : négociation ; noter le numéro de tour |
| Approbation demandée / accordée / rejetée | Activité sur l'affaire ; brancher sur le type d'approbation pour distinguer la chaîne du marchand de celle de l'acheteur |
| Devis accepté | Étape : gagnée, montant : le total accepté ; une acceptation partielle est un gain pour les lignes acceptées, le reste reste ouvert |
| Devis refusé, devis expiré | Étape : perdue, avec le motif |
| Devis converti | Rattacher l'identifiant de la commande provisoire ; le numéro de commande suit par la porte 1 quand l'acheteur paie |

Ce que la porte 2 ne peut pas transporter, ce sont les lignes. Les déclencheurs ne contiennent ni lignes, ni quantités, ni prix par ligne, et un workflow qui les voudrait n'aurait encore rien d'où les récupérer. Un CRM qui doit afficher les lignes du devis a besoin de l'API ci-dessous, pas d'un contournement sur Flow.

### Porte 3 : la finance reçoit un fichier
Certaines exigences relèvent du reporting, pas de l'intégration : la finance veut les devis du mois avec leur statut et leurs totaux en face des commandes qu'ils sont devenus ; un outil de BI veut la valeur du pipeline dans le temps. L'export analytique de QuotWay (Professional et au-dessus) télécharge les devis derrière les indicateurs en CSV pour la période et les filtres appliqués. Il est par lots, il est au niveau du devis, et c'est la bonne porte quand personne n'a besoin des données avant la fin du mois. C'est la mauvaise porte dès qu'un système, plutôt qu'une personne, attend de l'autre côté.

### Ce qui attend l'API
Trois exigences ne passent par aucune porte aujourd'hui, et la réponse honnête au cadrage est de le dire plutôt que de les approximer : pousser les lignes d'un devis dans l'ERP avant sa conversion, créer un devis depuis l'ERP ou le CRM, et un statut bidirectionnel entre le devis et une affaire. Chacune nécessite une API permettant à un système de lire et d'écrire des devis, et QuotWay n'a pas encore d'API publique ni de webhooks sortants. D'ici là, la correspondance de la porte 1 est l'endroit où l'ERP rencontre le devis, et il vaut la peine de la concevoir pour qu'elle n'ait pas à changer à l'arrivée de l'API : le numéro de devis, le numéro de version et l'identifiant du groupe de conversion resteront les mêmes clés.

## Listes de prix : l'ERP écrit, Shopify résout, le devis lit
La ligne du tableau de propriété qui dérape le plus souvent est la tarification spécifique au client, parce que trois systèmes ont un avis dessus. Le pattern qui tient est un seul sens : l'ERP écrit les prix dans les catalogues Shopify, Shopify résout quel prix un site donné voit, et la couche de devis prend ce prix résolu comme point de départ de la négociation.

Côté Shopify, un catalogue est une publication (quels produits) plus une liste de prix (à quel prix). Une liste de prix accepte des prix fixes par variante via l'API Admin - `priceListFixedPricesAdd` « crée ou met à jour des prix fixes sur une PriceList », avec ses homologues pour mettre à jour par produit, supprimer et gérer la liste - ou via l'import CSV de l'admin, qui ne transporte que les prix fixes et retire le prix fixe d'une variante quand la ligne est importée avec un prix vide. Les prix fixes l'emportent sur l'ajustement en pourcentage du catalogue, donc un ERP qui exporte les groupes tarifaires clients en montants fixes et laisse les règles en pourcentage dans Shopify a une séparation nette. Quand un site atteint la même variante par plus d'un catalogue, Shopify applique d'abord le catalogue le plus spécifique puis le prix le plus bas, les règles de quantité et la tarification par volume suivant le catalogue gagnant ; hors Plus, trois catalogues actifs sur l'ensemble des marchés B2B est le plafond. Les lignes à jour sont dans la [référence Shopify B2B](/reference/shopify-b2b#catalogs).

Deux règles rendent cette ligne sûre. Ne laissez jamais la couche de devis détenir un prix à elle pour un produit - son prix de départ doit être [dérivé de ce que Shopify montre à l'acheteur connecté](/blog/shopify-b2b-quote-starting-price), pour qu'un changement de prix dans l'ERP atteigne le prochain devis par le catalogue sans seconde synchronisation. Et n'écrivez jamais automatiquement un prix négocié dans une liste de prix : un prix d'affaire est l'issue d'une affaire, et un traitement qui le promeut en prix de liste du client a transformé chaque concession d'un commercial en remise permanente sans que personne ne l'ait décidé.

## Entreprises et sites : le fichier clients, dans un seul sens
La seconde ligne qui attire deux écrivains est l'entreprise. Shopify permet à un marchand de créer des entreprises dans l'admin ou par l'API Admin, et un parcours d'inscription sur la vitrine peut alimenter le même objet ; l'ERP a un fichier clients avec numérotation, crédit et conditions. Choisissez-en un. Si l'ERP est le maître, il crée la `Company` et chaque `CompanyLocation` avec `externalId` renseigné, le `taxRegistrationId`, `taxExempt` et `taxExemptions` du site, et une `buyerExperienceConfiguration` portant le modèle de conditions de paiement, si les commandes du site partent en commande provisoire pour revue et si l'acheteur peut saisir une adresse de livraison ponctuelle ; et il les met à jour à chaque changement. Si Shopify est le maître - typique quand les comptes viennent d'un parcours d'inscription - l'ERP s'abonne à `companies/create`, `company_locations/create` et leurs sujets `update`, crée son client depuis le webhook, et écrit le numéro ERP en retour dans `externalId` pour que l'événement suivant soit rapproché. Dans les deux cas, un système crée ; l'autre réagit.

Les contacts suivent la même règle avec un autre candidat : un CRM détient souvent les personnes tandis que l'ERP détient les comptes. Le système qui possède la personne écrit le `CompanyContact` ; les sujets `company_contacts/*` et `company_contact_roles/*` disent à l'autre côté ce qui s'est passé. Une couche de devis avec des [devis liés à l'entreprise](/features/b2b) lit alors le site de l'acheteur au moment de la demande et le porte dans la commande provisoire en `purchasingEntity`, ce qui est la façon dont les conditions, les réglages fiscaux et l'identité du site atteignent la commande et, par la porte 1, l'ERP.

## Les modes de défaillance propres au devis
Les modes de défaillance ordinaires entre Shopify et l'ERP - livraisons de webhooks en double, arrivée dans le désordre, un connecteur qui mappe mal un champ - s'appliquent ici comme partout. Voici ceux que le devis ajoute.

| Mode de défaillance | Ce qui se passe | Conception |
| --- | --- | --- |
| Filtrer sur `sourceName` | La valeur dépend de qui a finalisé la commande provisoire : `shopify_draft_order` depuis l'admin, `web` depuis la facture, un identifiant d'application depuis une application | Identifier les commandes issues de devis par le tag `quotway` ou le tag de référence |
| Un devis, plusieurs commandes | L'acceptation partielle et la conversion fractionnée créent une commande provisoire par groupe de conversion, donc un devis peut devenir deux commandes ou plus pendant que les lignes non acceptées restent ouvertes | Dédoublonner sur `quotway_conversion_group_id`, pas sur le numéro de devis ; attendre N commandes par référence |
| Devise mal comptabilisée | La commande provisoire est créée dans la devise du devis (`presentmentCurrencyCode`) ; `currencyCode` est la devise de la boutique ; `totalPriceSet` porte les deux | Décider quelle devise l'ERP comptabilise et lire ce côté du montant ; voir [le B2B multidevise sur Shopify](/blog/multi-currency-b2b-shopify-markets) |
| Commande modifiée après conversion | Le marchand modifie la commande ; `orders/edited` se déclenche ; la version scellée du devis ne change pas | Après conversion, la commande est la vérité pour l'expédition et la facturation ; le devis est la trace de ce qui a été convenu, pas une seconde copie à réconcilier |
| Tag de référence rejeté ou tronqué | Les tags de commande sont limités à 40 caractères et aux lettres, chiffres et traits d'union | Garder un préfixe de référence personnalisé dans ces règles |
| Webhook reçu deux fois, en retard ou jamais | La livraison est au moins une fois, avec huit nouvelles tentatives sur quatre heures ; l'ordre n'est pas garanti | Gestionnaires idempotents à clé sur l'identifiant de commande ; un traitement de réconciliation qui interroge Shopify, la même conception que [celle dont la conversion a besoin](/blog/quote-to-draft-order-failure-modes#pourquoi-la-conversion-doit-tre-idempotente) |
| Sites en revue de commandes provisoires | Sous « soumettre toutes les commandes en commandes provisoires pour revue », chaque commande de la vitrine depuis ce site arrive aussi en commande provisoire, à côté de celles créées par la couche de devis | Les distinguer par le tag ; ne pas traiter chaque commande provisoire comme un devis |
| Devis invités | Une demande d'un acheteur sans client Shopify porte un identifiant client vide dans le déclencheur Flow | Rapprocher le contact CRM sur l'e-mail de l'acheteur, que le déclencheur porte toujours |
| Entreprise créée des deux côtés | Inscription dans Shopify et client créé dans l'ERP pour le même acheteur | Un seul maître ; l'autre vérifie `externalId` avant de créer |
| Un réimport de prix efface un prix | Une ligne de CSV catalogue importée avec Fixed Price et Compare At tous deux vides retire le prix fixe de cette variante | Exporter avant d'importer ; ne jamais faire circuler un fichier partiel |
| Numéro de bon de commande attendu sur la commande | La conversion n'écrit pas `poNumber` ; le champ intégré reste sur le devis, seul un champ personnalisé atterrit en attribut | Ajouter le numéro à la commande provisoire avant la facture, ou le collecter en champ personnalisé et mapper l'attribut |

## Dix questions avant le cahier des charges
1. Pour chaque ligne du tableau de propriété, quel système l'écrit, et le client l'a-t-il validé par écrit ?
2. Quelle est la clé ERP d'un client, d'une adresse de livraison et d'un article, et quel champ Shopify porte chacune (`externalId`, un métachamp, le SKU) ?
3. Le connecteur que la boutique utilise, ou utilisera, écrit-il les entreprises, les sites et les listes de prix des catalogues, ou seulement les produits, le stock, les clients et les commandes ?
4. Comment les prix spécifiques au client sortent-ils de l'ERP - en montants fixes par variante, en groupes en pourcentage, ou les deux - et le plafond de trois catalogues actifs hors Plus convient-il ?
5. Quelle devise l'ERP comptabilise-t-il, et la couche de devis établit-elle le devis dans la devise du marché du site ?
6. L'ERP est-il prêt à recevoir plusieurs commandes par référence de devis, et dédoublonne-t-il sur le groupe de conversion ?
7. De quels événements de devis le CRM a-t-il besoin, et le forfait de la boutique autorise-t-il Envoyer une requête HTTP si le CRM n'a pas d'action Flow ?
8. Quelqu'un a-t-il besoin des lignes de devis dans un autre système avant la conversion ? Si oui, c'est l'exigence qui attend une API, et le cahier des charges doit le dire.
9. Qui possède la création des entreprises, et comment l'autre côté l'apprend-il ?
10. Que doit ajouter le [plan de test de lancement](/blog/shopify-b2b-launch-test-plan) pour l'intégration - un devis par porte, sur une boutique de développement, avant la mise en production ?

## Comment QuotWay s'inscrit dans le pattern
Signalé comme une implémentation, pour que le pattern ci-dessus puisse être vérifié contre quelque chose de concret. QuotWay possède la version scellée acceptée et rien d'autre : il lit les variantes, les prix résolus par catalogue et, sur le forfait Enterprise, le site d'entreprise de l'acheteur dans Shopify, et il écrit une commande provisoire par conversion, taguée et attribuée comme dans le tableau de la porte 1, avec `purchasingEntity` et les conditions de paiement du site quand le devis est lié à une entreprise, et la devise du devis comme devise de présentation. Sa conversion est [idempotente et réconciliée](/blog/quote-to-draft-order-failure-modes), ce qui rend la règle « N commandes par devis » sûre à exploiter. Il expose les dix déclencheurs Flow à partir de Professional et trois actions sur Enterprise, ainsi qu'un export CSV des devis à partir de Professional. Il n'a pas de connecteur ERP ou CRM à lui, et pas encore d'API publique ni de webhooks sortants. Les forfaits sont sur la [page des tarifs](/pricing), la surface Flow sur la [page de la fonctionnalité Shopify Flow](/features/shopify-flow), et la référence des champs des déclencheurs dans la [documentation](/docs/integrations/shopify-flow-reference).

Les faits Shopify de cet article sont tenus à jour dans la [référence Shopify B2B](/reference/shopify-b2b#automation).

## Questions fréquentes

### Shopify est-il un ERP ?

Non. Shopify est le système de référence des produits tels qu'ils sont vendus, des clients tels qu'ils achètent et des commandes telles qu'elles sont passées. Il ne détient aucune donnée d'achat, de comptabilité générale, de coûts ou de production, ce qui est le rôle d'un ERP. Dans une boutique B2B, l'ERP reste le maître des prix, du stock et de l'identité commerciale du client et écrit ces éléments dans Shopify ; Shopify reste le maître de la commande et la transmet à l'ERP.

### Quels ERP ont un connecteur Shopify certifié ?

Le Global ERP Program de Shopify liste cinq applications certifiées au 22 septembre 2026 : Dynamics 365 Business Central, Brightpearl by Sage, NetSuite ERP Connector, Acumatica Cloud ERP et Infor eCommerce Connector. Les autres ERP, dont Sage 100, Sage X3, Cegid ou Odoo sur le marché francophone, se connectent par des applications partenaires, une plateforme iPaaS ou l'API Admin. Qu'un connecteur écrive aussi les entreprises B2B et les listes de prix des catalogues est à vérifier dans sa documentation, connecteur par connecteur.

### Comment un devis arrive-t-il dans Sage, Business Central ou Cegid ?

Sous la forme de la commande qu'il devient. La couche de devis convertit le devis accepté en commande provisoire Shopify taguée avec la référence du devis ; quand l'acheteur paie ou que le marchand la finalise, la commande passe à l'ERP par le connecteur que la boutique utilise déjà, et l'ERP la reconnaît par le tag et la relie à l'affaire par la référence. Rien ne pousse un devis ouvert dans l'ERP, et rien ne devrait le faire.

### Shopify Flow peut-il envoyer les données d'un devis à HubSpot ou Salesforce ?

Oui, au niveau du devis. Les déclencheurs Flow partent à la soumission, à l'envoi de la proposition, à la contre-offre, à l'acceptation, au refus, à l'expiration, à la conversion et aux trois événements d'approbation, avec le numéro, le statut, le total, la devise, l'e-mail de l'acheteur et le lien admin. Un CRM disposant d'une action Flow les reçoit directement ; tout autre CRM les reçoit par Envoyer une requête HTTP sur les forfaits Grow, Advanced et Plus. Les lignes ne sont pas dans les déclencheurs.

### Comment synchroniser les listes de prix de l'ERP vers Shopify B2B ?

En les écrivant dans les listes de prix des catalogues, par les mutations de prix fixes de l'API Admin ou par l'import CSV de catalogue de l'admin, et en gardant un seul sens. Les prix fixes l'emportent sur l'ajustement en pourcentage du catalogue, un prix vide à l'import retire le prix fixe, et hors Plus la limite est de trois catalogues actifs sur l'ensemble des marchés B2B. La couche de devis prend ensuite le prix que Shopify résout pour le site comme prix de départ.

### Faut-il Shopify Plus pour tout cela ?

Pas pour le pattern. Flow est sur tous les forfaits, l'action Envoyer une requête HTTP nécessite Grow, Advanced ou Plus, et le plafond de catalogues hors Plus est de trois catalogues actifs sur les marchés B2B. Plus ajoute l'affectation directe des catalogues aux entreprises et aux sites, un nombre illimité de catalogues actifs et les acomptes.

### Où se place un PIM ?

En amont de Shopify et nulle part près du devis. Le PIM - Akeneo ou Pimcore dans les recherches du marché francophone - écrit le contenu produit, les attributs et les médias dans les produits Shopify ; la couche de devis référence des variantes Shopify et ne détient aucune donnée produit à elle. Si le PIM et l'ERP ne sont pas d'accord sur l'existence d'une variante, cela doit être réglé avant d'atteindre Shopify, parce que la ligne de devis a besoin d'une variante vers laquelle pointer.

## Sources

Pages Shopify, toutes lues le 22 septembre 2026 en version d'API 2026-07 sauf date contraire :

- Objets [DraftOrder](https://shopify.dev/docs/api/admin-graphql/latest/objects/DraftOrder) et [Order](https://shopify.dev/docs/api/admin-graphql/latest/objects/Order)
- [Utiliser les tags](https://help.shopify.com/en/manual/shopify-admin/productivity-tools/using-tags)
- [CompanyInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/CompanyInput), [CompanyLocationInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/CompanyLocationInput), [BuyerExperienceConfigurationInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/BuyerExperienceConfigurationInput), la [requête companies](https://shopify.dev/docs/api/admin-graphql/latest/queries/companies) et [MetafieldOwnerType](https://shopify.dev/docs/api/admin-graphql/latest/enums/MetafieldOwnerType)
- [priceListFixedPricesAdd](https://shopify.dev/docs/api/admin-graphql/latest/mutations/priceListFixedPricesAdd) et [personnaliser la tarification B2B avec les catalogues](https://help.shopify.com/en/manual/b2b/catalogs/creating-catalogs)
- [Imports en masse](https://shopify.dev/docs/api/usage/bulk-operations/imports)
- [WebhookSubscriptionTopic](https://shopify.dev/docs/api/admin-graphql/latest/enums/WebhookSubscriptionTopic) et [webhooks](https://shopify.dev/docs/apps/build/webhooks) (lus le 20 septembre 2026)
- [Shopify Flow](https://help.shopify.com/en/manual/shopify-flow) et l'action [Envoyer une requête HTTP](https://help.shopify.com/en/manual/shopify-flow/reference/actions/send-http-request)
- [Shopify lance le Global ERP Program](https://www.shopify.com/news/the-best-in-commerce-joins-the-best-in-enterprise-shopify-launches-global-erp-program) et la [collection du Global ERP Program](https://apps.shopify.com/collections/global-erp-partners)
- [Créer des commandes B2B avec des commandes provisoires](https://help.shopify.com/en/manual/b2b/checkout-and-orders/draft-orders) et [gérer les réglages de paiement en B2B](https://help.shopify.com/en/manual/b2b/checkout-and-orders/checkout-settings)
- [source_name vs sales channel](https://community.shopify.com/c/shopify-apis-and-sdks/source-name-vs-sales-channel/m-p/1752511), Shopify Staff, Shopify Community, 28 septembre 2022
- [Shopify Editions Spring '26](https://www.shopify.com/editions/spring2026) pour les intégrations QuickBooks et Mailchimp (lu le 20 septembre 2026)

Ce que QuotWay écrit sur une commande provisoire, relit sur la commande et expose à Flow est décrit d'après son code source et ses tests ; le compte rendu côté marchand est dans la documentation liée ci-dessus. La façon dont le marché francophone nomme ce sujet vient du sondage d'autocomplétion de la recherche de mots-clés du site, le 22 septembre 2026.