Shopify B2B natif, application de devis, développement sur mesure ou CPQ : un guide de décision

Entre les quatre façons de gérer les devis B2B sur Shopify, il n'y a pas de vainqueur, seulement une adéquation.

Shopify B2B natif convient quand les prix sont standard et que l'acheteur commande sur cette base. Une application de devis convient quand le prix se décide affaire par affaire sur des produits standard et que l'affaire doit devenir une commande Shopify avec son historique. Un développement sur mesure convient quand le workflow lui-même est le produit et que le marchand a des ingénieurs qui suivront les versions trimestrielles de l'API Shopify aussi longtemps que la boutique existera. Le CPQ convient quand le produit se configure à partir de règles et que l'équipe commerciale vit déjà dans une opportunité CRM. La plupart des boutiques B2B finissent avec le B2B natif pour les prix standard plus l'une des trois autres options pour les exceptions ; l'erreur est d'en choisir deux qui veulent toutes deux posséder les prix.

Ce guide s'adresse à l'agence ou à l'architecte qui doit en recommander une. Il définit les quatre options, les note sur dix-huit exigences et donne un arbre de décision en cinq questions. L'article sur l'architecture explique pourquoi la règle de propriété compte ; quand il ne faut pas d'application de devis est la version longue de la feuille « natif » ; la check-list d'évaluation est ce qu'il faut passer sur toute application ou tout développement présélectionné, et le plan de tests de mise en ligne ce qu'il faut exécuter avant que l'option choisie parte en production.

Les quatre options, définies

Shopify B2B natif. Entreprises, sites d'entreprise et contacts ; catalogues avec listes de prix, règles de quantité et prix par volume ; conditions nettes, cartes enregistrées et numéros de bon de commande au paiement ; « soumettre pour approbation » pour transformer un paiement en commande provisoire ; prix personnalisés, prix verrouillés et stock réservé sur cette commande provisoire ; acomptes et paiements partiels sur Plus. Sur tous les forfaits depuis le 2 avril 2026. Il n'a pas d'objet pour une demande de prix, une proposition, une contre-offre, une approbation ou un historique de négociation. Ce que vous exploitez : Shopify.

Une application de devis. Une application publique qui ajoute la demande, les versions de proposition, les contre-offres, les approbations et la trace d'audit par-dessus les objets natifs, lit le prix de catalogue de l'acheteur comme point de départ et crée la commande provisoire quand le prix est convenu. Installée et retirée par le marchand ; le fournisseur porte les montées de version d'API, les webhooks de conformité et les extensions de boutique. Ce que vous exploitez : un abonnement et la feuille de route du fournisseur.

Un développement sur mesure. La même couche de devis écrite pour un seul marchand, comme application personnalisée sur l'Admin API avec sa propre base de données, une extension de thème, une extension de compte client et des webhooks. Chaque comportement peut être exactement ce que veut le marchand. Ce que vous exploitez : une application, aussi longtemps que la boutique vend - les obligations sont listées plus bas, et elles ne rétrécissent pas après la mise en ligne.

CPQ. Un logiciel configure-price-quote, défini par un éditeur comme « un logiciel qui aide les équipes commerciales à configurer des produits, appliquer des règles de prix, gérer les remises et les approbations et générer des devis exacts » - configuration de produit à partir de règles, gouvernance des prix, vente guidée, approbations, documents et contrats, généralement créés depuis une opportunité CRM. Shopify n'est pas sa maison : la boutique, le compte client et la commande provisoire sont une intégration qu'un projet CPQ doit construire ou acheter. Ce que vous exploitez : une plateforme par siège et son intégration.

La matrice d'adéquation

L'adéquation est notée selon la façon dont une boutique B2B sur Shopify rencontre l'exigence, pas dans l'abstrait. « Partiel » signifie que l'option peut le faire avec un contournement ou un second outil.

Exigence	B2B natif	Application de devis	Sur mesure	CPQ
Listes de prix par entreprise, par site	Oui - catalogues	Les lit ; ne les possède jamais	Les lit ; ne les possède jamais	Partiel - son propre référentiel de prix, synchronisé vers les catalogues
Paliers de volume	Oui - jusqu'à 10 paliers par produit	Les lit	Les lit	Oui - ses propres règles
L'acheteur commande et paie à échéance	Oui	Oui - via la commande provisoire convertie	Oui - via la commande provisoire que vous créez	Partiel - la capture de commande est l'intégration
Un tour de vérification avant la commande	Oui - soumettre pour approbation	Oui	Oui	Partiel
Demande de prix d'un invité	Non - les prix exigent un contact d'entreprise	Oui	Oui	Non - les devis partent d'une fiche CRM
Prix propre à l'affaire, négocié	Aucun objet	Oui	Oui	Oui
Contre-offre de l'acheteur	Non	Oui	Oui	Partiel - généralement piloté par le commercial
Approbation d'une remise, appliquée	Non - les permissions du personnel délimitent des comptes, pas des prix	Oui	Oui, si vous construisez l'application de la règle	Oui
Lignes personnalisées ou de service avec leurs propres indicateurs de taxe et d'expédition	Oui - sur une commande provisoire, à la main	Oui	Oui	Oui
Produit configuré à partir d'options et de règles	Non	Non - contient une ligne personnalisée, ne la calcule pas	Possible	Oui - c'est le rôle du CPQ
Produit d'ingénierie complexe, piloté par nomenclature	Non	Non	Possible, à un coût réel	Oui
Fret tarifé par affaire	Commande provisoire, à la main	Oui	Oui	Oui
Présentation multidevise	Oui - Markets	Oui, si l'application devise dans la devise de présentation	Oui, si construit	Partiel - devise CPQ contre devise Shopify
Acompte sur la commande	Sur Plus	Sur Plus, via la commande provisoire	Sur Plus	Sur Plus, une fois arrivé dans Shopify
Devis dans le compte client	Commandes provisoires seulement	Extension d'interface de compte client	Extension d'interface de compte client	Non - les portails CPQ sont à part
L'ERP possède les prix	Synchronisation vers les catalogues	Lit les catalogues	Lit les catalogues	Sa propre synchronisation vers le CPQ et vers les catalogues
Devis créé depuis une opportunité CRM	Non	Partiel - événements via Flow	Possible	Oui - natif
Délai jusqu'au premier devis	Heures	Jours	Mois	Mois
Ingénierie continue	Aucune	Celle du fournisseur	La vôtre	Celle du fournisseur, plus votre intégration
Propriété des données et sortie	Shopify	Shopify + export	La vôtre	Fournisseur + Shopify

Lisez les colonnes, pas les lignes. Le natif a le plus de cases « oui » pour une boutique qui ne négocie jamais et le plus de cases « non » dès qu'elle le fait. Une application de devis et un développement sur mesure ont la même forme de colonne ; la différence est qui l'exploite. La colonne CPQ est la plus forte exactement là où les autres sont les plus faibles - configuration et CRM - et la plus faible là où elles sont les plus fortes - la boutique et la commande Shopify.

Shopify B2B natif : quand il suffit

Le natif est la réponse quand la question 1 est oui pour chaque acheteur et chaque commande : le prix est sur le catalogue du site avant que quiconque demande, les paliers sont des ruptures de quantité qui s'appliquent à tous sur ce catalogue, et la seule vérification que veut le marchand est un coup d'œil à la commande provisoire avant qu'elle devienne une commande. Depuis le 2 avril 2026, c'est disponible sur Basic, Grow et Advanced ; Plus ajoute des catalogues illimités, l'attribution directe d'un catalogue à une entreprise ou à un site, les acomptes et les paiements partiels. Les huit situations que le natif couvre, chacune reliée à la fonctionnalité qui la couvre, sont dans quand il ne faut pas utiliser d'application de devis Shopify.

Le natif cesse de suffire à la première réponse. Une commande provisoire peut porter un prix personnalisé, mais elle n'a pas d'état pour « l'acheteur a demandé moins », pas de version, pas d'approbation et pas de trace de l'échange. Les marchands qui tentent de mener la négociation sur des commandes provisoires finissent avec la conversation dans l'e-mail et la commande provisoire périmée - c'est le moment où l'une des trois autres options est choisie, que quelqu'un l'ait dit ou non.

Une application de devis : quand elle convient

Une application de devis convient quand le prix se décide affaire par affaire sur des produits que Shopify connaît déjà : l'acheteur demande, le vendeur propose depuis le prix de catalogue, l'une ou les deux parties bougent, quelqu'un approuve la remise, et la version acceptée devient une commande provisoire aux prix convenus. Elle convient aussi à l'acheteur que le natif ne peut pas servir - l'invité qui veut un chiffre avant d'avoir un compte d'entreprise.

Les conditions qui en font le bon choix plutôt qu'un développement sur mesure sont pratiques. Le workflow dont le marchand a besoin est celui que l'application modélise ; le marchand n'a pas d'équipe d'ingénierie, ou en a une qui a mieux à faire que suivre les versions trimestrielles de l'API Shopify ; le délai jusqu'au premier devis compte ; et l'application passe la check-list d'évaluation - avant tout les questions d'adéquation native, parce qu'une application qui tient sa propre liste de prix a recréé le problème pour lequel on l'a achetée. Ce que cela coûte, c'est l'abonnement et une dépendance à la feuille de route du fournisseur : un comportement que l'application ne modélise pas est une demande de fonctionnalité, pas un ticket.

QuotWay est une application de ce type et l'exemple pour lequel ce site peut parler : son devis par entreprise démarre une proposition depuis le prix de catalogue du site de l'acheteur, versionne chaque proposition et chaque contre-offre, applique les approbations côté serveur et convertit les lignes acceptées en commande provisoire native avec les conditions de paiement du site ; le forfait Lite exécute toute cette boucle gratuitement à dix devis par mois, ce qui est un moyen moins coûteux de savoir si une boutique a un volume de devis que n'importe laquelle des trois autres colonnes. Passez la check-list dessus comme vous le feriez pour n'importe qui d'autre.

Un développement sur mesure : quand il se justifie, et ce qu'il doit faire tourner

Un développement sur mesure se justifie quand les deux moitiés de la question 4 sont vraies : il y a un workflow qu'aucune application ne modélise - une règle d'achat, un document sectoriel, une négociation de prix qui suit la logique propre d'un contrat - et le marchand financera des ingénieurs pour exploiter une application aussi longtemps que la boutique vend. La première moitié est plus courante que la seconde, et on demande généralement aux agences de ne chiffrer que la première.

Ce qu'une couche de devis sur mesure sur Shopify doit faire tourner, d'après les pages d'obligations de Shopify :

• Une version de l'Admin API, montée au rythme trimestriel de Shopify. Chaque version est prise en charge au moins 12 mois ; une requête vers une version non prise en charge « bascule vers l'avant » silencieusement vers la plus ancienne prise en charge, et c'est ainsi qu'un projet que personne n'a touché casse au treizième mois. Les nouvelles applications sont GraphQL uniquement ; l'API REST Admin est héritée depuis le 1er octobre 2024.
• Les trois webhooks de conformité - customers/data_request, customers/redact, shop/redact - et les garde-fous des données clients protégées pour tout nom, e-mail, adresse ou téléphone que le projet stocke. Une application personnalisée n'est pas examinée pour cet accès comme l'est une application publique, mais les exigences sont les mêmes.
• Une gestion des webhooks qui survit au modèle de livraison de Shopify : signatures vérifiées, doublons ignorés via X-Shopify-Webhook-Id, nouvelles tentatives (8 sur 4 heures, puis l'abonnement est supprimé), et une tâche de réconciliation parce que la livraison « n'est pas toujours garantie ».
• Un usage de l'API conscient des limites de débit : 100 points par seconde sur Standard, 200 sur Advanced, 1 000 sur Plus, avec un plafond de 1 000 points par requête.
• Une extension d'application de thème pour la boutique et une extension d'interface de compte client pour le compte de l'acheteur, chacune avec ses propres limites de taille et son propre chemin de mise à jour ; une vitrine headless exige un troisième chemin.
• Une conversion idempotente vers la commande provisoire, avec le prix négocié sur chaque ligne comme priceOverride, l'entreprise comme purchasingEntity, et des contrôles d'écart contre draftOrderCalculate.
• Si le comportement du paiement fait partie du workflow - une règle de numéro de bon de commande, une validation - les Shopify Functions ; et « seules les boutiques sur un forfait Shopify Plus peuvent utiliser des applications personnalisées contenant des API Shopify Functions ».

Deux raccourcis ressemblent à des développements sur mesure et n'en sont pas. Modéliser le devis en métaobjets vous donne un type d'enregistrement personnalisé dans l'administration et sur la Storefront API, mais un enregistrement, pas un workflow : ni états, ni versions, ni approbations, ni application de règles. Et un montage Flow plus commandes provisoires - des automatisations Flow qui font avancer une commande provisoire par des tags - est un tour de vérification avec des étapes en plus, et s'arrête à la même réponse que le natif.

Un développement sur mesure cesse de se justifier quand le workflow pour lequel il a été construit se révèle être celui que toute application de devis modélise. Cela arrive plus souvent que l'inverse, et il vaut la peine de poser la question avant le développement, pas après ; l'article sur l'architecture est la spécification que l'une ou l'autre voie doit satisfaire, et la check-list d'évaluation est le test qui dit si une application existante la satisfait déjà.

CPQ : quand il se justifie, et quand c'est trop

Le CPQ se justifie quand la question 2 est oui et la question 3 est oui : le prix sort de règles de configuration produit plutôt que d'une conversation, et les personnes qui devisent travaillent depuis des opportunités CRM avec des contrats, des renouvellements et de la vente guidée autour. Dans ce monde, Shopify est la surface de capture de commande et d'expédition, le CPQ est la surface de devis, et l'intégration entre les deux - produit configuré vers ligne Shopify, devis CPQ vers commande provisoire, commande Shopify de retour vers l'opportunité - est un projet en soi que le CPQ ne livre pas.

Un CPQ complet est excessif pour la boutique dont les produits sont standard, dont les prix sont négociés plutôt que calculés, et dont les commerciaux vivent dans Shopify plutôt que dans un CRM. C'est le cas de la plupart des boutiques Shopify B2B. Le signe révélateur, ce sont les règles de configuration : si les lignes d'une proposition sont des variantes à prix négociés plus une ligne personnalisée à l'occasion, un configurateur n'a rien à configurer, et la boutique paie par siège les deux composants dont elle a besoin - approbations et documents - livrés avec plusieurs dont elle n'a pas besoin. L'article sur Shopify CPQ sépare les deux tâches ; QuotWay face au CPQ d'entreprise est la comparaison côte à côte pour une boutique qui hésite entre les deux.

Le cas intermédiaire - produits configurés, pas de CRM - est la feuille en pointillés de l'arbre : un outil d'options produit calcule le prix configuré, et une couche de devis (application ou sur mesure) le négocie et le convertit. Ce sont deux outils parce que ce sont deux tâches.

Les combiner

Toute combinaison qui fonctionne a un seul propriétaire du prix standard, et c'est le catalogue Shopify.

• Natif plus application de devis : le choix par défaut pour une boutique avec des prix standard et des exceptions négociées. Les catalogues tarifient la boutique et les réassorts ; l'application devise depuis le prix de catalogue et rend une commande provisoire.
• Natif plus développement sur mesure : la même forme, pour la boutique dont les exceptions suivent des règles qu'aucune application n'a.
• Natif plus CPQ : le CPQ possède la configuration et le devis côté CRM ; l'ERP ou le CPQ synchronise les prix standard vers les catalogues ; Shopify capture la commande. Le devis lui-même ne vit pas dans le compte client, sauf si quelqu'un le construit.
• La combinaison qui échoue : deux options qui tiennent chacune une liste de prix. Une application de devis avec ses propres prix à côté des catalogues, ou un référentiel de prix CPQ et des catalogues tous deux édités à la main, produisent deux chiffres pour un même acheteur en quelques semaines.

Questions fréquentes

Shopify B2B peut-il gérer des prix négociés sans application ?

Pour un tour, oui : réglez le site pour soumettre les commandes en commandes provisoires, ajustez les prix sur la commande provisoire, verrouillez-les et envoyez la facture. Il n'y a pas d'objet pour la réponse de l'acheteur, une seconde version ou une approbation, donc une négociation à plus d'un échange exige une couche de devis d'une forme ou d'une autre - application ou sur mesure.

Peut-on mettre en place une demande de devis sans Shopify Plus ?

Oui. Entreprises, catalogues, règles de quantité, conditions de paiement et commandes provisoires sont sur tous les forfaits depuis avril 2026, et une application de devis ou une application personnalisée sur l'Admin API fonctionne sur tous. Les dépendances à Plus sont celles de Shopify : acomptes et paiements partiels, catalogues illimités et attribués directement, et - pour un développement sur mesure - les Shopify Functions, qui exigent une boutique Plus quand elles sont livrées dans une application personnalisée.

Shopify a-t-il un CPQ ?

Non. Il a des catalogues, des règles de quantité, des commandes provisoires et le paiement B2B ; les règles de configuration, la vente guidée et le devis natif CRM viennent de plateformes CPQ qui s'intègrent à Shopify, et la négociation sur des produits standard vient des applications de devis. Laquelle une boutique nécessite est la question 2 de l'arbre.

Comment estimer le coût d'un développement sur mesure ?

Chiffrez les obligations, pas la mise en ligne : la montée de version d'API chaque trimestre, les webhooks de conformité et les garde-fous de données, la gestion des webhooks et des limites de débit, les deux extensions et leurs mises à jour, et la logique de conversion - chacune pour la durée de vie de la boutique. Une estimation de projet qui s'arrête à la mise en ligne est une estimation de la moitié la moins chère.

Quelle option garde les données dans Shopify ?

Le natif y garde tout. Une application de devis ou un développement sur mesure garde la négociation - demande, versions, approbations, trace d'audit - dans son propre stockage et tout le reste dans Shopify, ce qui est la bonne séparation ; la commande est toujours à Shopify. Le CPQ garde le devis dans le CPQ et la commande dans Shopify, avec un lien entre les deux aussi bon que l'intégration.

Une application de devis et un CPQ peuvent-ils coexister ?

Seulement avec une frontière nette : l'un des deux possède la proposition pour une ligne de produits donnée. Deux systèmes qui peuvent tous deux proposer un prix au même acheteur, c'est la défaillance des deux listes de prix sous une autre forme.

Sources

Pages Shopify, toutes lues le 20 septembre 2026 :

• Fonctionnalités B2B par forfait et B2B for all - annonce, 2 avril 2026
• Paiement et comptes et créer des commandes B2B avec des commandes provisoires
• Shopify Functions et métaobjets
• Gestion des versions de l'API, API REST Admin - avis d'obsolescence, limites de débit de l'API GraphQL Admin
• Conformité aux lois sur la protection des données - webhooks obligatoires et données clients protégées
• Webhooks - vérification des livraisons, délais et nouvelles tentatives et webhooks - aperçu
• Extensions d'application de thème et extensions d'interface de compte client
• Commandes provisoires pour le B2B et DraftOrderLineItemInput
• Définition du CPQ, par un éditeur : What is CPQ? (Salesforce)