---
title: "Architecture des devis Shopify B2B : ce qui reste dans Shopify et ce qui revient à la couche de devis"
description: "Ce qui reste dans Shopify, ce qu'une couche de devis possède, comment un prix négocié atteint la commande provisoire, et pourquoi une liste copiée échoue."
url: "https://www.quotway.com/fr/blog/shopify-b2b-quote-architecture"
type: "blog post"
category: "For Shopify agencies"
published: "2026-09-20"
verified: "2026-09-20"
shopify_api_version: "2026-07"
audience: "Agences Shopify, développeurs et architectes de solution"
scope: "Les objets natifs de Shopify B2B, une couche de devis (application, développement sur mesure ou CPQ) et les deux passages entre les deux"
locale: "fr"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# Architecture des devis Shopify B2B : ce qui reste dans Shopify et ce qui revient à la couche de devis

Laissez Shopify rester le système de référence pour tout ce dont il possède déjà un objet - produits, variantes, stock, clients, entreprises, sites, prix de catalogue, conditions de paiement, commandes provisoires et commandes - et ne donnez à la couche de devis que ce dont Shopify n'a pas d'objet : la demande de l'acheteur, les propositions du vendeur et leurs versions, les contre-offres, les approbations, la trace d'audit de la négociation, et les prix au moment où ils ont été convenus.

La couche de devis lit Shopify en direct, stocke des références et des instantanés datés plutôt que des copies, et remet à Shopify une seule commande provisoire quand le prix est arrêté. C'est toute l'architecture ; le reste de cette page en est le raisonnement et la mécanique, vérifiés par rapport à la documentation de Shopify.

Ce texte s'adresse à l'agence ou au développeur qui cadre un projet B2B, pas au marchand qui choisit une application. Il s'applique que la couche de devis soit une application, un développement sur mesure ou un CPQ - choisir entre les trois est le rôle du [guide de décision](/blog/shopify-b2b-native-vs-quote-app-vs-custom-vs-cpq) ; là où une section décrit comment QuotWay procède, c'est donné comme un exemple du modèle, pas comme le modèle lui-même.

## La règle : pas de seconde base de données commerce

Chaque projet de devis B2B rencontre tôt la même tentation. Les devis ont besoin de titres de produits, de prix, de noms de clients, de données d'entreprise et de niveaux de stock, alors le système de devis se met à tenir ses propres tables de produits, de prix et de clients, et un trimestre plus tard la boutique a deux catalogues, deux listes de prix et deux fiches client qui ne concordent pas. Le modèle B2B natif de Shopify possède déjà chacun de ces objets, et il les modifie sans prévenir personne : un marchand édite un prix de catalogue, un site reçoit un second catalogue, une variante est supprimée, un contact change de site.

La règle qui évite cela est courte. Shopify possède tout objet qu'il a ; la couche de devis ne possède que les objets qui manquent à Shopify. Là où la couche de devis doit conserver une valeur venue de Shopify - un titre sur le PDF de proposition, le prix d'où est partie une négociation - elle la conserve comme un instantané daté avec l'identifiant Shopify à côté, pour que l'enregistrement dise « voici ce que disait le catalogue le 14 mars », jamais « voici le prix ».

Le modèle natif est plus étroit qu'il n'y paraît, et c'est ce qui rend la séparation nette. Les objets B2B de Shopify sont les entreprises, les sites d'entreprise, les contacts d'entreprise, les catalogues (une sélection de produits plus une liste de prix, des règles de quantité et des prix par volume) et les commandes provisoires, et le site est l'entité à laquelle on vend réellement : catalogues, conditions de paiement, exonérations fiscales et réglages de paiement s'y rattachent tous. Aucun de ces objets ne peut contenir une demande de prix, une proposition avec un numéro de version, une contre-offre, une approbation ou l'historique de qui a changé quoi. Une commande provisoire est l'enregistrement d'une commande en attente de paiement ou d'approbation, pas de la négociation qui l'a produite. La [référence technique Shopify B2B](/reference/shopify-b2b) liste le modèle d'objets en entier.

## Quel système possède quoi

La table est l'architecture. Chaque ligne nomme le propriétaire, ce que la couche de devis a le droit de conserver, et pourquoi.

| Données | Système de référence | Ce que la couche de devis conserve | Pourquoi |
| --- | --- | --- | --- |
| Produits et variantes | Shopify | Les identifiants de produit et de variante, plus un instantané du titre rafraîchi à chaque version de proposition | Une proposition de mars doit encore se lire correctement en septembre ; l'identifiant la garde liée au vrai produit |
| Stock | Shopify (alimenté par l'ERP quand il y en a un) | Rien. Lu au moment de la conversion, écart signalé | Le stock change toutes les heures ; une copie est fausse dès qu'elle est écrite |
| Identité et connexion du client | Comptes clients Shopify | L'identifiant client ; pour un invité, un e-mail et un rattachement ultérieur à une fiche client | Shopify possède l'authentification ; les acheteurs B2B se connectent avec un code à usage unique aux comptes clients actuels |
| Entreprise, site, contact | Shopify B2B | Les trois identifiants | Catalogues, conditions et exonérations fiscales sont accrochés au site dans Shopify ; dupliquer l'entreprise, c'est tous les dupliquer |
| Prix standard, règles de quantité, prix par volume | Catalogues Shopify | Le prix d'où est partie la négociation, résolu pour le site de l'acheteur au moment de la proposition, avec l'identifiant du catalogue comme provenance | Les prix de catalogue changent et le plus bas de plusieurs catalogues l'emporte ; une copie stockée ne peut pas le savoir |
| Conditions de paiement | Shopify B2B | Une référence au modèle de conditions choisi pour l'affaire, appliquée à la création de la commande provisoire | Les conditions appartiennent à la commande, et Shopify encaisse selon elles |
| Acompte | Shopify (Plus) | Le pourcentage négocié pour l'affaire, versionné avec la proposition | Encaissé par le paiement Shopify sur la commande provisoire convertie |
| Taxes | Shopify | Une estimation sur la proposition, recalculée par Shopify à la conversion et au paiement | La taxe dépend des exonérations du site et de l'adresse de livraison au moment du paiement |
| Demande de devis | Couche de devis | Tout : lignes, quantités, prix demandés, message de l'acheteur, champs personnalisés, numéro de bon de commande | Shopify n'a pas d'objet de demande |
| Propositions et versions | Couche de devis | Chaque version, immuable une fois envoyée | Les lignes d'une proposition envoyée sont verrouillées ; un changement est une nouvelle version ou une contre-offre, jamais une modification sur place |
| Contre-offres | Couche de devis | Chaque contre-offre comme sa propre version, avec son auteur | La négociation est le produit ; son historique est la preuve |
| Approbations | Couche de devis | Les politiques, la chaîne parcourue par chaque proposition, chaque décision avec son auteur | Les permissions du personnel Shopify délimitent quels comptes un commercial voit, pas si une remise peut partir |
| Trace d'audit | Couche de devis | Chaque changement d'état, acteur et horodatage | On demandera à l'agence « qui a approuvé ce prix » un an plus tard |
| Commande acceptée | Commande provisoire Shopify, puis commande | Les identifiants de la commande provisoire et de la commande, réécrits sur le devis | La commande est à Shopify ; le devis pointe vers elle |
| Expédition | Shopify et l'ERP | Rien | Le travail de la couche de devis s'est terminé à la commande |

Deux lignes méritent un second regard, parce que c'est là que les projets échouent : les prix et l'identité.

> **Architecture des devis Shopify B2B**
>
> Trois colonnes. À gauche, Shopify possède les produits et variantes, le stock, les clients et entreprises, les catalogues avec leurs prix, les conditions de paiement et les acomptes. Au centre, la couche de devis possède la demande, les versions de proposition, les contre-offres, les approbations et la trace d'audit. À droite, Shopify possède la commande provisoire, la commande et l'expédition, avec l'ERP derrière. Deux flèches traversent la frontière : le prix de catalogue entre dans la couche de devis via contextualPricing quand une proposition est rédigée, et le prix négocié sort comme priceOverride sur la ligne de commande provisoire quand le devis est accepté. Une troisième flèche renvoie l'identifiant de commande via le webhook orders/create.
>
> La frontière et ses deux passages : un prix de catalogue entre quand une proposition est rédigée, un prix négocié sort quand le devis est accepté.

## Pourquoi la couche de devis ne doit pas posséder les prix

L'erreur d'architecture la plus courante dans les devis Shopify B2B est une application de devis qui tient sa propre liste de prix, importée de Shopify ou de l'ERP, « pour pouvoir négocier à partir d'elle ». Trois propriétés des catalogues Shopify en font une copie fausse en quelques jours.

D'abord, un site d'entreprise peut avoir plusieurs catalogues, et quand le même produit figure dans plus d'un, Shopify affiche le prix le plus bas. Il n'y a pas de réglage de priorité à reproduire ; la seule réponse correcte est celle que Shopify calcule pour ce site à cet instant. Ensuite, les prix par volume fixent le prix d'un produit et désactivent l'ajustement global en pourcentage du catalogue pour lui, si bien que le « tarif moins 20 % » qu'une copie calculerait n'est pas ce que l'acheteur voit. Enfin, les catalogues sont modifiés en permanence - par le marchand, par une synchronisation ERP, par Shopify lui-même quand un marché ou une devise change. Hors Plus, une boutique est limitée à trois catalogues actifs sur l'ensemble de ses marchés B2B et ne peut pas en attribuer un directement à un site, donc ces trois-là changent souvent. Le [guide des catalogues](/blog/shopify-b2b-catalogs) parcourt le côté marchand de la question.

L'API donne à la couche de devis la bonne primitive plutôt qu'une copie. `ProductVariant.contextualPricing` prend un contexte `companyLocationId`, `country` ou `locationId` et renvoie « le prix final après application de tous les ajustements », avec la règle de quantité et les paliers qui s'appliquent dans ce contexte. Le bon schéma est le suivant :

1. Quand une proposition est rédigée, résoudre le prix de chaque variante via `contextualPricing` pour le site d'entreprise de l'acheteur, dans la devise du devis.
2. Stocker ce nombre sur la ligne de proposition comme prix de base d'où la négociation est partie, avec l'identifiant du catalogue à côté comme provenance.
3. Négocier à partir de ce prix de base. Les prix demandés, proposés et finaux sont les données propres de la couche de devis, parce que Shopify n'a pas d'objet pour eux.
4. Ne jamais réécrire le prix négocié dans le catalogue. Le catalogue est le prix standard du site ; l'affaire est une commande.

Le [devis par entreprise](/features/b2b) de QuotWay fait exactement cela : le prix de catalogue du site d'entreprise est résolu côté serveur à l'envoi de la proposition et stocké sur la ligne comme prix de base dans la devise du devis, et l'identifiant du catalogue Shopify est enregistré sur la version. Il n'importe jamais de liste de prix. La même règle répond à la question « l'ERP doit-il pousser les prix dans l'application de devis ? » - non ; l'ERP pousse les prix dans les catalogues Shopify, et la couche de devis les y lit comme tout autre canal.

## Comment le prix négocié atteint la commande

C'est le passage dans l'autre sens, et il comporte deux détails qui piègent les équipes à leur première conversion.

Le premier : la commande provisoire est créée pour l'entreprise, pas pour la personne. `draftOrderCreate` prend une `purchasingEntity` de la forme `{ purchasingCompany: { companyId, companyLocationId, companyContactId } }`, et la documentation Shopify des commandes provisoires dit qu'une commande provisoire avec un client B2B et un site d'entreprise assigné « reflète automatiquement les réglages de cette entreprise » - prix, conditions de paiement et options de paiement. Cette phrase décrit une commande provisoire créée dans l'administration. Ne la lisez pas comme « l'API va tarifer mes lignes depuis le catalogue » : une ligne créée avec un `variantId` est tarifée par Shopify, et un fil de la communauté Shopify qui recueille la même question depuis septembre 2023 montre le résultat habituel - un produit à 8 $ dans le catalogue de l'entreprise qui arrive sur la commande provisoire à son prix produit de 10 $.

Le second détail est le champ qui porte le nombre convenu. `DraftOrderLineItemInput.priceOverride` est « le prix de remplacement de la ligne », exprimé dans la devise de présentation, et c'est le champ par lequel un prix négocié doit passer sur une ligne de variante ; `originalUnitPrice` est déprécié, et `title`, `taxable` et `requiresShipping` sont ignorés quand un `variantId` est présent. Une ligne personnalisée (sans variante) est l'inverse : elle porte son propre titre, son prix, son indicateur de taxe et son indicateur d'expédition.

Le chemin de conversion est donc :

1. Construire l'entrée de la commande provisoire à partir de la version de proposition acceptée : `purchasingEntity` d'après les identifiants d'entreprise, de site et de contact du devis ; chaque ligne acceptée avec son `variantId`, sa quantité et un `priceOverride` au prix unitaire final ; les lignes personnalisées avec leur propre prix ; le numéro de bon de commande ; les conditions de paiement choisies pour l'affaire ; le pourcentage d'acompte sur Plus.
2. Exécuter d'abord `draftOrderCalculate` et comparer le sous-total, la taxe et l'expédition de Shopify avec les chiffres de la proposition. La taxe et l'expédition diffèreront légitimement - Shopify les calcule contre les exonérations du site et l'adresse de livraison maintenant, pas au moment où la proposition a été rédigée - donc l'objectif est d'enregistrer l'écart et de repérer les cas qui demandent une personne : une variante qui n'existe plus, une ligne que Shopify tarifie autrement, un stock qui n'est plus là.
3. Créer la commande provisoire sous une clé d'idempotence, pour qu'une requête rejouée ou un second worker ne puisse pas produire deux commandes provisoires pour une seule acceptation.
4. Envoyer la facture avec `draftOrderInvoiceSend`, ou laisser l'acheteur payer via l'URL de paiement que Shopify renvoie. Une commande provisoire devient une commande quand elle est payée ou finalisée avec `draftOrderComplete` ; elle ne retient pas le stock et ne verrouille pas ses prix tant que vous ne le demandez pas.
5. Réécrire l'identifiant de la commande provisoire sur le devis à la création, et l'identifiant de la commande quand le webhook `orders/create` arrive. À partir de là, le devis pointe vers l'enregistrement de Shopify et cesse d'être la source de quoi que ce soit.

Le service de conversion de QuotWay est construit ainsi : un aperçu via `draftOrderCalculate` avec les écarts de taxe, d'expédition et de stock enregistrés par rapport aux chiffres du devis, une clé d'idempotence et une réservation contre la création concurrente avant `draftOrderCreate`, `priceOverride` sur les lignes de variante et `originalUnitPriceWithCurrency` sur les lignes personnalisées, et l'identifiant de commande alimenté par le webhook `orders/create`. Ce qui peut mal tourner entre le moment du devis et celui de la conversion est un sujet à part ; [l'article sur les limites des commandes provisoires](/blog/shopify-draft-order-limits) en couvre aujourd'hui le côté Shopify, le [plan de tests de mise en ligne](/blog/shopify-b2b-launch-test-plan) contient les tests qui l'attrapent, et un article dédié aux modes de défaillance est prévu.

## Identité : client, contact, invité

Shopify possède la connexion de l'acheteur. Les acheteurs B2B se connectent aux comptes clients actuels avec l'e-mail d'un site d'entreprise et un code à usage unique ; les anciens comptes clients ont été dépréciés le 26 février 2026 et n'ont jamais pris en charge le B2B, donc une couche de devis ne devrait porter ni base de mots de passe, ni chemin « anciens comptes », ni modèle d'identité propre. Un acheteur rattaché à plusieurs sites en choisit un avant de voir les prix, et chaque prix affiché par la boutique est le prix d'un site.

Ce que la couche de devis conserve, c'est l'identifiant client et, pour les devis par entreprise, les trois identifiants d'entreprise. Le seul cas où elle en détient légitimement davantage est l'invité : un acheteur qui demande un devis avant d'avoir un compte, ou depuis une boutique qui n'a pas activé les comptes clients. La couche de devis a alors besoin d'un e-mail et d'un moyen de joindre l'acheteur - un lien signé, un code à usage unique à elle - et d'un moyen de rattacher le devis au client Shopify une fois qu'il existe. QuotWay dirige les acheteurs connectés vers une extension d'interface de compte client dans leur compte Shopify et les invités vers un portail hébergé, et rattache les devis de l'invité à sa fiche client quand il se connecte plus tard ; le choix se fait par boutique d'après ce que Shopify indique, pas par le marchand.

## Conditions, acompte, bon de commande, devise et taxes

Ce sont les champs qui ressemblent aux données de la couche de devis et n'en sont pas.

- Les conditions de paiement appartiennent au site dans Shopify (7 à 90 jours nets, à l'expédition, à date fixe, ou aucune), et la commande encaisse selon elles. La couche de devis stocke une référence au modèle de conditions choisi pour cette affaire et l'applique à la création de la commande provisoire ; elle ne gère jamais ses propres créances.
- Un acompte est une fonctionnalité Shopify Plus - un pourcentage dû au paiement, le solde selon les conditions - défini via `DraftOrderInput.deposit` depuis l'API 2026-07. Le rôle de la couche de devis est de négocier le pourcentage et de le versionner avec la proposition. QuotWay le fait sur les boutiques Plus à partir du [forfait Professional](/pricing), et jamais hors Plus.
- Le numéro de bon de commande est saisi sur la demande et transmis à la commande provisoire, où Shopify l'affiche sur la commande.
- La devise est fixée à la création du devis, dans la devise de présentation de l'acheteur pour le marché, et chaque prix de chaque version est dans cette devise ; un instantané du taux de change à la création est conservé pour le reporting, pas pour la tarification. Shopify ne convertit rien pour le compte de la couche de devis.
- La taxe sur une proposition est une estimation. Shopify calcule le vrai chiffre à `draftOrderCalculate` puis de nouveau au paiement, contre l'exonération du site et l'adresse de livraison, ce qui explique que la proposition doive dire « estimée » et que l'étape de conversion doive enregistrer l'écart plutôt que tenter de l'empêcher. Le [guide de l'exonération fiscale](/blog/shopify-b2b-tax-exemption) couvre la configuration côté marchand.

## Où se place l'ERP

La documentation B2B de Shopify traite les connexions ERP, comptabilité et PIM comme une partie de l'architecture B2B, et la plupart des projets d'agence en ont une. La question du placement est plus simple qu'il n'y paraît une fois la table de propriété fixée : l'ERP s'intègre à Shopify, pas à la couche de devis.

- Le stock va de l'ERP vers Shopify. La couche de devis lit le stock Shopify à la conversion et jamais l'ERP directement.
- Les prix standard vont de l'ERP vers les catalogues Shopify, au rythme choisi par le marchand. La couche de devis résout les prix depuis le catalogue via `contextualPricing`, donc un changement de prix dans l'ERP atteint une nouvelle proposition dès qu'il atteint le catalogue.
- Les commandes vont de Shopify vers l'ERP, par le connecteur que le marchand utilise déjà pour ses commandes D2C. Un devis converti est une commande Shopify ordinaire avec un numéro de bon de commande, une entreprise, des conditions de paiement et éventuellement un acompte ; l'ERP la voit comme n'importe quelle autre commande. L'Edition Spring ’26 de Shopify a ajouté une synchronisation native QuickBooks des commandes B2B, des numéros de bon de commande et des données d'entreprise, qui a la même forme.
- La négociation elle-même reste dans la couche de devis. Si l'ERP ou un CRM doit savoir qu'un devis a été envoyé, contre-proposé ou accepté, c'est un événement, pas un enregistrement à dupliquer : les déclencheurs Shopify Flow sont la surface native pour cela, et une couche de devis qui les émet laisse le marchand câbler le reste sans intégration sur mesure. QuotWay expose des déclencheurs Flow à partir du forfait Professional et des actions Flow sur Enterprise ; il n'a aucun connecteur ERP ou CRM direct, et cette architecture est la raison pour laquelle il n'en a pas besoin pour s'intégrer.

La seule variante pilotée par l'ERP qui mérite d'être nommée est le marchand dont les prix contractuels vivent dans l'ERP et changent par client chaque semaine. Ce marchand synchronise quand même les prix dans les catalogues Shopify - parce que la boutique, le paiement et les commandes provisoires lisent tous les catalogues - et la couche de devis lit au même endroit. Une couche de devis qui irait chercher les prix dans l'ERP serait la seconde base de données commerce que la règle existe pour empêcher.

## Ce que la couche de devis conserve quand même, et pourquoi ce n'est pas une copie

Trois choses dans la colonne centrale ressemblent à des doublons de données Shopify. Ce sont des instantanés, et la distinction compte.

- Les titres et SKU sur les lignes de proposition. Un PDF de proposition envoyé en mars est un document commercial ; si la variante est renommée en juin, le document de mars doit toujours se lire tel qu'il a été envoyé. Le titre est donc rafraîchi à chaque nouvelle version et figé avec elle.
- Le prix de base. Le chiffre d'où est partie la négociation fait partie de l'historique de la négociation, et le catalogue aura bougé. Il est stocké avec la date et l'identifiant du catalogue, et il n'est jamais réutilisé pour tarifer quoi que ce soit après cette version.
- Les prix finaux. Ce ne sont pas des données Shopify du tout tant que la commande provisoire n'existe pas ; ils sont le résultat de la négociation.

Le test pour savoir si une chose est un instantané ou une copie : un instantané a une date et un identifiant à côté et n'est jamais lu pour répondre à « quel est le prix maintenant » ; une copie est lue comme si elle était à jour. Chaque valeur de la couche de devis devrait passer ce test.

## Désinstallation, effacement et localisation des données

Comme la couche de devis ne possède rien de ce que Shopify a, la désinstaller ne retire rien de la boutique : produits, clients, entreprises, catalogues, commandes provisoires et commandes restent intacts. Ce que la couche de devis détient - demandes, versions, approbations, messages, documents - suit les webhooks de conformité obligatoires de Shopify, que toute application de l'App Store doit implémenter : `shop/redact` arrive 48 heures après une désinstallation et l'application doit effacer les données de la boutique ; `customers/redact` arrive 10 jours après une demande de suppression, ou une fois six mois écoulés depuis la dernière commande du client ; `customers/data_request` demande les données que l'application détient sur un client. Une agence qui évalue une couche de devis devrait demander où ces enregistrements sont stockés, quelle est la durée de conservation et quel est le comportement à la réinstallation pendant cette période - la [check-list d'évaluation](/blog/shopify-b2b-app-evaluation-checklist) contient ces questions avec la façon de vérifier chacune. Les réponses de QuotWay sont dans sa documentation sur la [conservation des données et la désinstallation](/docs/privacy/data-retention-and-uninstall) et sur le [RGPD](/docs/privacy/gdpr-data-requests-and-erasure).

## Questions fréquentes

### Cette architecture exige-t-elle Shopify Plus ?

Non. Depuis le 2 avril 2026, les entreprises, sites, catalogues, règles de quantité, prix par volume, conditions de paiement et cartes enregistrées sont sur Basic, Grow et Advanced comme sur Plus. Plus ajoute des catalogues illimités, l'attribution directe d'un catalogue à une entreprise ou à un site, les acomptes et les paiements partiels. Une couche de devis qui lit les prix de catalogue via `contextualPricing` et crée des commandes provisoires avec une `purchasingEntity` fonctionne sur tous les forfaits ; seule la ligne de l'acompte change. La [matrice des forfaits](/reference/shopify-b2b) détaille chaque différence.

### Faut-il utiliser les commandes provisoires comme objet de devis ?

Utilisez-les pour ce qu'elles sont : l'enregistrement d'une commande convenue en attente de paiement ou d'approbation. Une commande provisoire n'a aucun état de demande, de proposition, de version ou de contre-offre, et ses prix et son stock ne sont pas retenus tant que vous ne les verrouillez pas et ne les réservez pas. Si les affaires du marchand ne comportent qu'un tour - l'acheteur soumet, le marchand ajuste, l'acheteur paie - le réglage « soumettre pour approbation » du paiement Shopify crée la commande provisoire nativement et une couche de devis est inutile ([quand il ne faut pas d'application de devis](/blog/when-not-to-use-a-shopify-quote-app) liste les autres cas). Dès qu'il y a négociation, approbation ou historique à conserver, modélisez cela dans une couche de devis et créez la commande provisoire à la fin.

### Qu'est-ce qu'une purchasing entity ?

L'acheteur B2B pour lequel une commande provisoire ou une commande est établie. Sur `draftOrderCreate`, elle est transmise sous la forme `purchasingEntity: { purchasingCompany: { companyId, companyLocationId, companyContactId } }` - l'entreprise, le site auquel on vend et le contact qui passe la commande. C'est ce qui fait de la commande provisoire une commande provisoire B2B : les conditions de paiement, l'exonération fiscale et les réglages de paiement du site s'y appliquent, et l'acheteur la voit dans son compte d'entreprise.

### Une couche de devis entre-t-elle en conflit avec les catalogues ?

Pas si elle ne stocke jamais de liste de prix. Le conflit apparaît quand une application tient ses propres prix et qu'ils divergent du catalogue affiché par la boutique. Lisez le prix du site via `contextualPricing` au moment de la proposition, négociez à partir de lui, et écrivez le prix convenu sur la ligne de commande provisoire comme `priceOverride`. Le catalogue reste intact et la commande correspond au devis. Le prix d'où doit partir une demande quand un site a plusieurs catalogues est traité dans le [guide des catalogues](/blog/shopify-b2b-catalogs).

### Un acheteur peut-il modifier un devis après son envoi ?

Pas celui qui a été envoyé. Une proposition est une version numérotée, immuable une fois partie, parce que le document reçu par l'acheteur est un enregistrement commercial. Le geste de l'acheteur est une contre-offre, qui devient une nouvelle version ; celui du vendeur est une nouvelle proposition. Modifier une version envoyée sur place empêcherait la trace d'audit de dire ce que chaque partie avait accepté.

### Les devis expirent-ils automatiquement, et la commande provisoire ?

Une couche de devis peut faire expirer une proposition à une date et désactiver le lien d'acceptation ; c'est l'état de la couche de devis. Une commande provisoire a sa propre horloge : elle ne retient pas le stock et ne verrouille pas les prix sauf demande, et Shopify supprime les commandes provisoires après une période d'inactivité - voir [l'article sur les limites des commandes provisoires](/blog/shopify-draft-order-limits). Créez la commande provisoire quand le prix est convenu, pas quand le devis est envoyé.

### Qu'advient-il de nos devis si nous désinstallons l'application de devis ?

Rien n'arrive aux données de Shopify. Les données propres de l'application - demandes, propositions, approbations, messages - sont effacées quand Shopify envoie `shop/redact`, 48 heures après la désinstallation, sous réserve de la fenêtre de récupération documentée par l'application. Exportez ce dont vous avez besoin avant.

## Sources

Pages Shopify, toutes lues le 20 septembre 2026 :

- [Créer des applications B2B - modèle d'objets](https://shopify.dev/docs/apps/build/b2b) et [commandes provisoires pour le B2B](https://shopify.dev/docs/apps/build/b2b/draft-orders)
- [Catalogues B2B](https://help.shopify.com/en/manual/b2b/catalogs) et [règles de quantité et prix par volume](https://help.shopify.com/en/manual/b2b/catalogs/quantity-pricing)
- [Créer des commandes B2B avec des commandes provisoires](https://help.shopify.com/en/manual/b2b/checkout-and-orders/draft-orders)
- [ProductVariant.contextualPricing](https://shopify.dev/docs/api/admin-graphql/latest/objects/ProductVariant), [ProductVariantContextualPricing](https://shopify.dev/docs/api/admin-graphql/latest/objects/ProductVariantContextualPricing), [ContextualPricingContext](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/ContextualPricingContext)
- [DraftOrderLineItemInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/DraftOrderLineItemInput)
- [Connexion et comptes clients en B2B](https://help.shopify.com/en/manual/b2b/customer-login-and-accounts) et [comptes clients pour les applications](https://shopify.dev/docs/apps/build/customer-accounts)
- [Conditions de paiement](https://help.shopify.com/en/manual/b2b/checkout-and-orders/payment-terms) et le [changelog des champs d'acompte](https://shopify.dev/changelog/draft-order-deposit-fields-now-available-in-the-admin-and-customer-account-graphql-apis)
- [Conformité aux lois sur la protection des données - webhooks obligatoires](https://shopify.dev/docs/apps/build/compliance/privacy-law-compliance)
- [B2B for all - annonce, 2 avril 2026](https://www.shopify.com/news/b2b-for-all) et [fonctionnalités B2B par forfait](https://help.shopify.com/en/manual/b2b/getting-started/plan-features)
- [Shopify Editions Spring ’26](https://www.shopify.com/editions/spring2026)
- Témoignage de praticien, pas une source de faits : [How to fetch prices from a catalog when creating B2B draft orders using APIs?](https://community.shopify.com/t/how-to-fetch-prices-from-a-catalog-when-creating-b2b-draft-orders-using-apis/250177) (communauté Shopify, septembre 2023 - septembre 2026)