Dette technique Shopify B2B : les décisions qui coûtent cher plus tard

La dette technique d'un projet Shopify B2B se présente sous deux formes, et elles ne se traitent pas de la même façon. La première est structurelle : des décisions dont Shopify dit lui-même qu'elles sont difficiles à défaire - une boutique mixte ou une boutique B2B dédiée, la répartition des acheteurs en entreprises et en sites, l'endroit où vivent les prix permanents, les clés d'identité qui relient Shopify à l'ERP. La seconde a une échéance : du code bâti sur une surface que Shopify retire selon un calendrier publié - checkout.liquid (13 août 2024 et 28 août 2025), Shopify Scripts (désactivé le 30 juin 2026), les anciens comptes clients (dépréciés le 26 février 2026) et chaque version d'API, chacune prise en charge au moins 12 mois.

La dette structurelle se rembourse en décidant avant que la moindre donnée existe. La dette datée se rembourse en notant les dates et en confiant à quelqu'un la tâche de les surveiller. Les deux sont documentées par Shopify avant le début du projet ; ce qui les rend chères, c'est de les découvrir après sa fin.

Cette page s'adresse à l'agence qui cadre ou reprend un projet : les décisions qui coûtent cher plus tard et pourquoi, les surfaces datées dans un seul calendrier, l'endroit où l'application des règles doit vivre, les sept façons dont un projet dérape, et le registre de dette à remettre avec le projet. Là où la page décrit une couche de devis, il s'agit d'une implémentation, signalée comme telle.

Tout ce qui concerne Shopify ci-dessous a été vérifié sur les pages de Shopify le 24 septembre 2026, en version d'API 2026-07, sauf autre date indiquée ; les sources sont en fin de page.

Deux types de dette

Critère	Dette structurelle	Dette datée
Ce que c'est	Une décision de modélisation à laquelle tout le reste se rattache	Du code sur une surface que Shopify a annoncé retirer
Exemples	Type de boutique, arbre d'entreprises, emplacement des prix, clés d'identité, emplacement de l'état des négociations, dépendances à Plus	checkout.liquid, Shopify Scripts, anciens comptes clients, versions d'API et champs dépréciés
Quand elle coûte peu	Avant que la première entreprise, le premier catalogue ou la première commande existe	Avant la date - Shopify la publie des mois à l'avance
Ce qui la rend chère	Les données s'y rattachent : commandes, catalogues, conditions, historique	La date passe et le code cesse de tourner, parfois sans bruit
Comment la rembourser	Décider délibérément, consigner la raison	Un registre des surfaces avec leurs dates et un responsable pour chacune

Les deux s'alimentent l'une l'autre. Une boutique qui gardait ses prix de gros dans Shopify Scripts portait une dette datée (Scripts a pris fin le 30 juin 2026) par-dessus une dette structurelle (les prix n'ont jamais été dans un catalogue), et rembourser la première obligeait à rembourser la seconde.

Les décisions qui coûtent cher plus tard

Six décisions, chacune avec la contrainte Shopify qui la rend difficile à changer. Prenez-les dans cet ordre, avant que la première entreprise existe.

1. Boutique mixte ou dédiée. Les recommandations de Shopify sont sans détour : « Vous devez prendre cette décision avec soin, car il n'est pas facile d'en changer plus tard. Si vous configurez un type de boutique puis voulez passer à l'autre, vous devrez refaire la plus grande partie de votre configuration, y compris les entreprises, les catalogues et les personnalisations de la boutique en ligne. » Une boutique B2B dédiée est une boutique distincte : « le stock est séparé par défaut pour les commandes et les clients B2B », ses applications doivent être « configurées et payées à nouveau », et entre boutiques d'expansion « les paramètres de boutique, les produits, les collections et le stock ne sont pas synchronisés » - c'est le travail d'une application ou de l'ERP. Sur une organisation Plus, les règles des boutiques d'expansion incluent une boutique B2B gratuite par contrat. Rien de tout cela n'est une erreur ; c'est un choix qui a un coût récurrent, et il doit être fait parce que l'entreprise a besoin d'une vitrine séparée, pas parce que c'est ainsi que le gros se gérait autrefois.

2. L'arbre d'entreprises. Qu'est-ce qu'une entreprise, et qu'est-ce qu'un site ? Catalogues, conditions de paiement, exonérations de taxe et adresses de livraison se rattachent tous au site, et l'historique ne pardonne pas : « les commandes B2B restent avec l'entreprise pour laquelle elles ont été créées et ne peuvent pas être migrées vers une autre », et les commandes migrées d'un client ne peuvent pas être réparties sur plusieurs sites. Un arbre calqué ligne pour ligne sur la liste clients d'un ancien système, sans décider quelles fiches sont des organisations et lesquelles sont des succursales, ne se corrige pas en remigrant les commandes - il se corrige en reconstruisant l'arbre. Le playbook de migration décrit l'ordre des travaux qui l'évite.

3. Où vivent les prix permanents. Depuis le 2 avril 2026, entreprises, catalogues et conditions de paiement sont disponibles sur toutes les offres Shopify : les raisons de garder les prix de gros dans des tags clients, des codes de réduction ou des produits « gros » dupliqués ont disparu. Chacun de ces contournements a sa propre maintenance : les produits dupliqués sont, par construction, des fiches de stock et de reporting distinctes, et la logique par tags vit dans le thème ou une application plutôt que dans ce que lit le paiement. Les catalogues sont ce que lisent le paiement B2B, les règles de quantité et la tarification par volume. Dimensionnez le nombre de catalogues dès le départ : hors Plus, le plafond est de trois catalogues actifs sur l'ensemble des marchés B2B, donc un plan qui suppose un catalogue par client est un plan Plus. Prix de gros et de détail sans dupliquer les SKU couvre le côté prix, et les lignes catalogue de la référence les règles de priorité.

4. Les clés d'identité. Company.externalId et CompanyLocation.externalId existent pour une seule raison : un « identifiant unique fourni de l'extérieur » qui relie les fiches de Shopify aux numéros de client et d'adresse de livraison de l'ERP, et la requête companies sait filtrer dessus. Renseigné le premier jour, il ne coûte rien. Ajouté un an plus tard, il oblige à faire correspondre des milliers de fiches par leur nom, et chaque synchronisation construite entre-temps s'appuie sur une autre clé. Les patterns d'intégration ERP, CRM et PIM indiquent qui possède quel champ.

5. Où vit l'état des négociations. Une commande provisoire est une commande convenue en attente de paiement ou d'approbation : trois statuts (OPEN, INVOICE_SENT, COMPLETED), pas de versions, et draftOrderUpdate remplace l'entrée en bloc. Les commandes provisoires créées à partir du 1er avril 2025 sont supprimées après un an sans modification. Un projet qui garde la négociation dans des commandes provisoires - la demande, la contre-offre, l'historique de qui a proposé quoi - la stocke dans un endroit qui ne peut ni la contenir ni la conserver. Une commande provisoire Shopify n'est pas un devis met les états de la commande provisoire en regard de ceux dont une négociation a besoin.

6. Les dépendances à Plus. Certaines fonctionnalités B2B sont réservées à Shopify Plus : l'affectation directe d'un catalogue à une entreprise ou à un site, les catalogues actifs illimités, les acomptes, les paiements partiels, une demande de paiement par exécution et - facile à manquer - les applications personnalisées qui contiennent des API Shopify Function, que Shopify documente comme utilisables uniquement sur les boutiques Plus (les applications publiques de l'App Store avec des fonctions tournent sur toutes les offres). Aucun de ces choix n'est une erreur. Chacun lie le projet à l'offre, et le marchand doit le savoir avant d'en dépendre. Faut-il Shopify Plus pour le B2B ? détaille l'offre ligne par ligne.

La dette à échéance

Shopify publie ses dates de retrait des mois à l'avance. La dette n'est pas l'ancienne surface ; c'est d'ignorer que le projet l'utilise.

Surface	Date	Ce qui s'est passé	Ce qui la remplace
checkout.liquid, étapes du paiement	13 août 2024	A cessé de fonctionner pour Informations, Livraison et Paiement	L'extensibilité du paiement
checkout.liquid et scripts supplémentaires, pages de remerciement et de statut de commande (Plus)	28 août 2025	Retirés ; le champ des scripts supplémentaires est passé en lecture seule	Extensions de paiement, blocs, pixels web et d'application
Pages de remerciement et de statut de commande (hors Plus)	26 août 2026	Échéance de mise à niveau	Les mêmes
API REST Admin	Héritée le 1er oct. 2024 ; 1er avr. 2025 pour les nouvelles applications publiques	Les nouvelles applications publiques doivent être GraphQL uniquement	API GraphQL Admin
Anciens comptes clients	Dépréciés le 26 févr. 2026 ; date de retrait à annoncer	Plus de nouvelles boutiques, plus de mises à jour ; n'ont jamais pris en charge le B2B	Les comptes clients et leurs extensions d'interface
Shopify Scripts	Modification close le 15 avr. 2026 ; désactivés le 30 juin 2026	Les scripts publiés « ne fonctionnent plus »	Shopify Functions
DraftOrderInput.customerId, marketRegionCountryCode	Dépréciés en 2026-07	Toujours acceptés, en voie de retrait	purchasingEntity (un client ou une entreprise acheteuse)
DraftOrderLineItem.grams	Retiré en 2026-07	Disparu	weight
Chaque version d'API	Trimestrielle ; chacune prise en charge 12 mois ou plus	Une version non prise en charge « bascule vers l'avant » vers la plus ancienne version stable accessible, sans bruit	Monter de version chaque trimestre, ou au moins une fois par an

Deux lignes méritent un second regard pour le B2B en particulier. checkout.liquid n'a jamais fonctionné pour le paiement B2B - Shopify range les personnalisations checkout.liquid parmi ce que le B2B ne prend pas en charge - donc une boutique B2B n'a jamais porté cette dette, mais le paiement D2C d'une boutique mixte peut la porter, et la correction touche les deux. Et la ligne des versions d'API est celle qui mord sans bruit. Une application personnalisée qui cite une version que Shopify ne prend plus en charge n'échoue pas : Shopify répond avec la plus ancienne version encore prise en charge, et un champ déprécié entre-temps peut tout simplement ne plus être là. Une application publique de l'App Store a une échéance plus dure : « Si votre application continue d'utiliser des ressources non prises en charge après la date limite de mise à niveau, elle est retirée de l'App Store Shopify », les nouvelles installations étant bloquées pendant au moins sept jours.

La ligne Scripts est l'exemple récent le plus net des deux types de dette arrivant en même temps. Une boutique dont les remises de gros ou les règles de livraison B2B vivaient dans Scripts avait jusqu'au 30 juin 2026 pour les déplacer ; le passage à Functions est aussi le moment de se demander si ces prix n'ont pas plutôt leur place dans un catalogue, ce qui est structurel. Notez la règle d'offre de Functions au moment de cadrer : une application personnalisée avec des fonctions ne tourne que sur Plus, donc un marchand hors Plus qui remplace Scripts choisit entre une application publique et les fonctionnalités natives. L'article sur les limites des commandes provisoires couvre la seule réserve documentée des discount functions sur les commandes provisoires.

L'application des règles appartient au serveur

La forme la plus discrète de dette est une règle qui paraît appliquée et ne l'est pas. Le code du thème s'exécute dans le navigateur de l'acheteur ; il peut afficher ou masquer un bouton, mais un acheteur déterminé, une page en cache ou une deuxième vitrine ne l'exécutent pas. La règle qui compte pour l'argent doit vivre là où Shopify la vérifie.

Shopify vous donne trois endroits côté serveur. Les catalogues décident du prix que voit un site d'entreprise connecté. Les règles de quantité - minimum, maximum et incrément par variante - sont appliquées au panier et au paiement, pas seulement affichées. Et la Cart and Checkout Validation Function API exécute des contrôles côté serveur « pour s'assurer que les commandes répondent à des critères précis avant de permettre aux clients de continuer », sur le paiement B2B et sur les commandes provisoires dans l'admin et au paiement, avec le purchasingCompany de l'acheteur disponible pour la fonction ; une boutique peut en activer jusqu'à 25.

Connaissez les deux endroits qu'elle n'atteint pas : l'API de validation ne s'exécute ni sur l'API de création de commande ni sur la modification de commande. Une intégration qui écrit des commandes directement via orderCreate - un import ERP, un script de migration - contourne les règles auxquelles un acheteur est soumis : ces règles doivent donc aussi être appliquées dans l'intégration. C'est une note de conception pour le cahier des charges, pas un défaut.

Sept façons dont un projet B2B dérape

Chacun de ces cas est un schéma rattaché à une contrainte de cette page, pas une fréquence mesurée - personne ne publie de tels chiffres, et nous ne revendiquons aucun classement. Chacun est l'une des décisions ci-dessus, prise tard ou par défaut.

1. Le type de boutique a été choisi pour la vitesse de lancement. Une boutique dédiée parce que c'est ainsi que le gros se gérait autrefois, puis synchronisation du stock, double facturation des applications et reporting éclaté aussi longtemps que la boutique existe. Shopify dit que changer implique de refaire entreprises, catalogues et personnalisations.
2. L'arbre d'entreprises a copié l'ancienne liste clients. Des succursales sont devenues des entreprises, ou des organisations sont devenues des sites, et les commandes ne peuvent pas passer d'une entreprise à l'autre pour corriger cela.
3. Les prix sont restés dans les tags après l'arrivée des catalogues. Le contournement a survécu à sa raison d'être (le B2B sur toutes les offres depuis le 2 avril 2026) et exige désormais sa propre maintenance, à côté d'un système de catalogues que le paiement lit déjà.
4. Personne n'a renseigné externalId. La synchronisation ERP s'appuie sur des noms ou des e-mails, et chaque doublon devient un ticket de support.
5. La négociation vivait dans les commandes provisoires. Pas de versions, pas de contre-offre, une mise à jour remplace toute l'entrée, et une commande provisoire inactive est supprimée au bout d'un an.
6. La logique de paiement reposait sur une surface en voie de retrait. Scripts, checkout.liquid ou scripts supplémentaires, avec une date connue et non suivie.
7. Personne n'était responsable de la montée de version d'API. Une application personnalisée fixée sur une version qui a ensuite basculé vers l'avant, et un champ qu'elle lisait n'était plus là.

Aucun de ces cas n'est un bug de Shopify. Chacun est une contrainte documentée avant le projet et découverte après.

Le registre de dette à remettre

Le remboursement le moins cher est une page du document de passation qui énonce chaque décision et sa raison. Elle coûte une heure en fin de projet et évite à l'équipe suivante de tout redécouvrir.

• Type de boutique - mixte ou dédiée, et la raison métier. Si dédiée : ce qui est synchronisé entre boutiques, et par quoi.
• Règle de l'arbre d'entreprises - ce qu'est une entreprise, ce qu'est un site, et qui l'a validé côté marchand.
• Où vit chaque prix - catalogues (lesquels, et le nombre d'actifs face au plafond de l'offre), règles de quantité, paliers de volume, tout ce qui reste dans des tags ou des réductions et pourquoi.
• Clés d'identité - le schéma externalId des entreprises et des sites, et le champ du système source auquel chacun correspond.
• Où vit l'état des négociations - quel système possède les demandes, propositions, contre-offres et approbations, et ce qu'il transmet à Shopify.
• Dépendances à Plus - chaque fonctionnalité du projet qui n'existe que sur Plus, pour qu'un changement d'offre soit un coût connu.
• Surfaces avec une date Shopify - toute extension, fonction, tout script, bloc de thème ou API dont dépend le projet et qui fait l'objet d'une dépréciation annoncée, avec la date.
• Version d'API - la version que fixe chaque application personnalisée, la date à laquelle cette version sort du support, et le responsable nommé de la montée trimestrielle.
• Carte d'application des règles - quelles règles sont appliquées par les catalogues, les règles de quantité ou les fonctions de validation, et lesquelles seulement dans le thème.
• Intégrations qui contournent le paiement - tout ce qui écrit des commandes via orderCreate, et l'endroit où cela réapplique les règles acheteur.

La check-list de 50 tests avant mise en ligne en est le complément : le registre consigne ce qui a été décidé, le plan de tests prouve que cela fonctionne.

Où se place une couche de devis

Signalé comme une implémentation. Une application de devis ajoute un système de référence pour la négociation, et peut donc ajouter sa propre dette. La question qui en décide l'ampleur est ce qu'elle stocke : des références aux fiches de Shopify, ou des copies. Une liste clients ou une liste de prix copiée est une seconde source de vérité que quelqu'un doit tenir synchronisée ; une référence est lue dans Shopify au moment voulu.

QuotWay stocke des références : un devis contient les identifiants Shopify du client, de l'entreprise, du site, du contact, du produit et de la variante, un instantané des titres de produits à chaque version, et les prix négociés - le prix catalogue de référence, la demande de l'acheteur, l'offre et le prix final. Il ne garde aucune liste de prix permanente ; la proposition faite à un contact d'entreprise part du prix catalogue de son site d'entreprise, résolu au moment où la demande arrive. L'état de la négociation reste dans le devis - versions, contre-offres, approbations, et propositions envoyées dont les lignes sont verrouillées, si bien qu'un changement passe par une nouvelle version ou une contre-offre plutôt que par une modification. Seul le résultat convenu devient une commande provisoire, créée avec purchasingEntity plutôt qu'avec le customerId déprécié et, sur le forfait Enterprise, avec les conditions de paiement du site. Les devis liés à l'entreprise sont sur le forfait Enterprise - les forfaits sont détaillés sur la page des tarifs - et le côté entreprise est sur la page de la fonctionnalité devis B2B Shopify ; l'architecture derrière ce partage est dans ce qui vit dans Shopify et ce qui appartient à la couche de devis.

Quelle que soit l'application que vous évaluez, posez directement la question du stockage ; comment évaluer une application Shopify B2B la range parmi les 52 autres.

Les faits Shopify de cet article sont tenus à jour dans la référence Shopify B2B.

Questions fréquentes

Qu'est-ce que la dette technique dans un projet Shopify B2B ?

Deux choses. Des décisions structurelles dont Shopify dit qu'elles sont difficiles à défaire - boutique mixte ou dédiée, l'arbre d'entreprises, l'endroit où vivent les prix permanents, les clés d'identité - et du code sur une surface qui a une date de retrait publiée, comme checkout.liquid, Shopify Scripts, les anciens comptes clients et les versions d'API. La première se rembourse en décidant tôt ; la seconde en suivant les dates.

Puis-je passer plus tard d'une boutique de gros séparée à une seule boutique mixte ?

Oui, mais c'est une reconstruction, pas un réglage. Les recommandations de Shopify sur le type de boutique disent que le choix « n'est pas facile à changer plus tard » et que changer implique de refaire « la plus grande partie de votre configuration, y compris les entreprises, les catalogues et les personnalisations de la boutique en ligne ». Les boutiques d'expansion ne synchronisent entre elles ni les paramètres, ni les produits, ni les collections, ni le stock.

Shopify Scripts fonctionne-t-il encore pour les prix B2B ?

Non. Shopify Scripts a été déprécié le 30 juin 2026 et les scripts publiés ont été désactivés ; la modification avait déjà pris fin le 15 avril 2026. Le remplaçant est Shopify Functions. Une application personnalisée contenant des fonctions ne tourne que sur les boutiques Plus ; les applications publiques de l'App Store avec des fonctions tournent sur toutes les offres.

La dépréciation de checkout.liquid touche-t-elle le B2B ?

Pas le paiement B2B lui-même, qui n'a jamais pris en charge les personnalisations checkout.liquid. Elle touche le paiement D2C d'une boutique mixte : checkout.liquid a cessé de fonctionner pour les étapes Informations, Livraison et Paiement le 13 août 2024, et pour les pages de remerciement et de statut de commande le 28 août 2025 sur Plus. Les boutiques hors Plus avaient jusqu'au 26 août 2026 pour mettre ces deux pages à niveau.

Que se passe-t-il si une application personnalisée utilise une ancienne version d'API ?

Rien de visible au début. Chaque version stable est prise en charge au moins 12 mois ; au-delà, une requête qui la cite « bascule vers l'avant » vers la plus ancienne version stable accessible, si bien que les champs retirés entre-temps ne sont plus renvoyés. Les applications publiques qui continuent d'utiliser des ressources non prises en charge sont retirées de l'App Store, les installations étant bloquées pendant au moins sept jours. Fixez une version et confiez à quelqu'un la montée trimestrielle.

Les prix de gros par tags sont-ils désormais de la dette technique ?

C'est un contournement dont la raison d'origine a disparu. Depuis le 2 avril 2026, entreprises et catalogues sont sur toutes les offres Shopify, et les catalogues sont ce que lisent le paiement B2B, les règles de quantité et la tarification par volume. Une configuration par tags fonctionne encore, mais c'est une logique de plus à maintenir à côté d'un système natif - déplacez-la la prochaine fois que vous touchez aux prix, et dimensionnez le nombre de catalogues face au plafond de trois catalogues actifs en dessous de Plus.

Une commande B2B peut-elle être déplacée vers une autre entreprise ?

Non. Shopify indique que les commandes B2B « restent avec l'entreprise pour laquelle elles ont été créées et ne peuvent pas être migrées vers une autre ». C'est pourquoi l'arbre d'entreprises est la décision à prendre correctement avant que la moindre commande existe.

Sources

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

• Choisir un type de boutique pour votre activité B2B - mixte ou dédiée, et « pas facile à changer plus tard »
• Boutiques d'expansion - le type de boutique B2B et ce qui n'est pas synchronisé entre boutiques
• checkout.liquid, le changelog du 13 août 2024 et la mise à niveau des pages de remerciement et de statut de commande
• Exigences et limites de Shopify Scripts - déprécié le 30 juin 2026 ; la fin de la modification au 15 avril 2026 d'après le changelog, lu le 22 septembre 2026
• Shopify Functions - la règle d'offre pour les applications personnalisées avec des fonctions
• Cart and Checkout Validation Function API - surfaces prises en charge, purchasingCompany, 25 par boutique
• Gestion des versions de l'API - rythme, prise en charge de 12 mois, bascule vers l'avant, retrait de l'App Store
• API REST Admin - héritée depuis le 1er octobre 2024, lue le 20 septembre 2026
• Les anciens comptes clients sont désormais dépréciés et connexion et comptes clients en B2B, lus du 20 au 22 septembre 2026
• DraftOrderInput et les notes de version 2026-07, lus du 20 au 22 septembre 2026
• Migrer des clients vers le B2B, lu le 23 septembre 2026
• CompanyInput et CompanyLocationInput, lus le 22 septembre 2026
• Règles d'offre, de catalogue, de commande provisoire et de limites : la référence Shopify B2B, revérifiée du 20 au 23 septembre 2026

Le modèle de stockage de QuotWay est décrit d'après son propre schéma de données.