---
title: "Migrer des clients grossistes vers les entreprises Shopify : le playbook d'agence"
description: "Deux chemins de migration, un seul a une API. Les contraintes, l'ordre des travaux, ce que coûtent 20 000 clients, et ce qui peut être annulé."
url: "https://www.quotway.com/fr/blog/migrate-wholesale-customers-to-shopify-companies"
type: "blog post"
category: "For Shopify agencies"
published: "2026-09-23"
verified: "2026-09-23"
shopify_api_version: "2026-07"
audience: "Agences Shopify et développeurs qui cadrent le passage d'un gros par tags ou d'un système hérité vers les entreprises natives"
scope: "Migrer des clients existants vers les entreprises Shopify en API 2026-07 : la migration depuis l'admin et ses contraintes, l'import de commandes via orderCreate, la chaîne entreprise–site–contact–rôle–catalogue, le débit sous limite de requêtes, la correspondance des identités, le pilote et l'annulation"
locale: "fr"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# Migrer des clients grossistes vers les entreprises Shopify : le playbook d'agence

Il y a deux façons dont des clients grossistes deviennent des entreprises Shopify, et la différence décide de tout votre plan. Si les commandes sont déjà dans Shopify en tant que commandes B2C, elles passent par l'admin : 250 clients à la fois, tout l'historique d'un client ou rien, sur exactement un site d'entreprise - et il n'y a pas d'API pour cela, parce que les mutations qui le font sont internes à Shopify. Si les commandes vivent dans un système hérité, elles entrent comme commandes importées via `orderCreate` avec un site d'entreprise dessus, ce qui est scriptable mais exige que chaque entreprise, site, contact et rôle existe d'abord.

La plupart des plans de migration qui échouent supposent que le premier chemin a une API. Ce n'est pas le cas, et le découvrir après la signature du cahier des charges coûte cher.

Cette page est le playbook de l'agence qui cadre le déplacement : quels sont les deux chemins et comment savoir sur lequel vous êtes, la chaîne de dépendances qui fixe l'ordre des travaux, un tableau de contraintes pour le cahier des charges, le débit à attendre selon la limite de requêtes de chaque offre, comment piloter, et ce qui peut ou non être annulé. Là où la page décrit le comportement d'une couche de devis pendant une migration, 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 23 septembre 2026, en version d'API 2026-07 ; les sources sont en fin de page.

## Les deux chemins
Une question décide de tout : les commandes que vous voulez rattacher à une entreprise sont-elles déjà des commandes Shopify, ou vivent-elles ailleurs ? Le premier chemin passe par l'admin et ne se script pas ; le second passe par `orderCreate` et se script.

> **L'endroit où vivent les commandes décide du chemin de migration**
>
> Un flux de décision. La question à gauche est : où vivent aujourd'hui les commandes de gros ? Si ce sont déjà des commandes B2C dans Shopify, le chemin est la migration depuis l'admin : sélectionner jusqu'à 250 clients, les ajouter à une entreprise, tout l'historique de commandes bascule sur un site d'entreprise, et il n'y a pas d'API publique parce que la mutation de migration est interne à Shopify. Si elles vivent dans un système hérité ou sur une autre plateforme, le chemin est l'import de commandes : créer d'abord l'entreprise, le site, le contact et le rôle, puis appeler orderCreate avec companyLocationId et customer.toAssociate pour chaque commande historique, ce qui est scriptable. Les deux chemins convergent vers le même état final : un arbre d'entreprises avec catalogues, conditions de paiement et historique. Un troisième cadre indique ce qu'aucun chemin ne permet : déplacer des commandes B2B entre entreprises, migrer une partie d'un historique, répartir un historique sur plusieurs sites, ou migrer des commandes annulées ou supprimées.
>
> Une question décide du plan. Les deux chemins aboutissent au même arbre d'entreprises ; un seul se script, et ce n'est pas celui que la plupart des plans supposent.

**Chemin A - les commandes sont déjà des commandes B2C Shopify.** C'est la boutique qui vend à des acheteurs professionnels via des comptes clients ordinaires, avec des tags ou un code de réduction pour tenir lieu de tarification - [la forme qui a remplacé le canal de gros](/blog/shopify-wholesale-channel), et qui veut maintenant des entreprises. L'admin de Shopify le fait : vous sélectionnez des clients sur la page Clients - « jusqu'à 250 clients B2B en même temps, ou effectuez l'opération par lots plus petits » - et vous les ajoutez à une entreprise nouvelle ou existante. Leurs commandes B2C passées les suivent.

Ce qu'il faut savoir avant de chiffrer le travail : **il n'y a pas d'API publique pour cela.** Un membre du personnel de Shopify l'a confirmé sur le forum développeurs en décembre 2025 - « `CompanyLocationMigrateOrdersMutation` et `CompanyLocationRevertMigratedOrders` sont internes et ne sont pas exposées dans l'API publique », vérifié auprès de l'équipe produit B2B. Vous pouvez créer les entreprises, sites et contacts par l'API Admin toute la journée ; l'étape qui transporte l'historique de commandes, c'est une personne qui clique dans l'admin, 250 clients à la fois.

**Chemin B - les commandes vivent ailleurs.** Un ancien ERP, une plateforme précédente, un canal de gros retiré. Ici vous ne migrez pas à l'intérieur de Shopify, vous importez dedans, et là il *y a* une API : `orderCreate` avec `companyLocationId` et `customer.toAssociate`, que Shopify documente spécifiquement pour les données de commandes historiques. L'exigence qui fait trébucher les développements : « le client doit avoir une attribution de rôle sur le site d'entreprise indiqué. S'il n'en a pas, une erreur est renvoyée » - et plus largement : « un marchand B2B doit importer ou créer toutes les entreprises, tous les sites d'entreprise, tous les contacts d'entreprise et tous les produits pertinents dans Shopify avant de pouvoir importer des commandes B2B. »

La plupart des projets réels sont un mélange : certains comptes ont un historique Shopify, d'autres un historique dans l'ancien système, quelques-uns les deux. Triez la liste par chemin avant de séquencer quoi que ce soit, parce que les deux chemins ont un débit différent, des personnes différentes pour les exécuter et des modes de défaillance différents.

## La chaîne de dépendances
Chaque étape bloque la suivante, et c'est pourquoi les migrations qui parallélisent produisent des orphelins.

1. **Décidez l'arbre d'entreprises.** Une entreprise par organisation acheteuse ; un site par lieu ayant ses propres prix, conditions, statut fiscal ou adresse de livraison. C'est la décision coûteuse à changer plus tard, parce que chaque catalogue, condition et commande se rattache à un site.
2. **Créez entreprises et sites,** avec `externalId` sur les deux, depuis les identifiants client et adresse de livraison du système source. Ce champ est votre seule jointure vers les anciennes données, et tout ce qui suit - la synchronisation, la réconciliation, l'audit - s'y accroche.
3. **Rattachez les contacts.** `companyAssignCustomerAsContact` transforme un client Shopify existant en contact d'entreprise ; ensuite « le client devient un contact d'entreprise qui peut passer des commandes au nom de l'entreprise, avec accès aux catalogues, prix et conditions de paiement configurés pour les sites de l'entreprise ». `companyCreate` peut aussi créer l'entreprise, un site et un contact en un seul appel, la forme efficace pour un arbre neuf.
4. **Attribuez les rôles sur le site.** Commande uniquement, ou administrateur du site. Rien ne fonctionne en aval sans cela : ni la commande, ni l'import de commandes.
5. **Rattachez les catalogues.** Un site a besoin d'un catalogue avant que ses acheteurs voient des prix. Hors Plus, c'est via un marché B2B, avec trois catalogues actifs sur l'ensemble des marchés comme plafond ; sur Plus, un catalogue peut être affecté directement à une entreprise ou à un site. [D'où vient le prix de départ d'une demande](/blog/shopify-b2b-quote-starting-price) explique comment le catalogue se résout pour un acheteur connecté.
6. **Réglez conditions de paiement et fiscalité.** Les deux vivent sur le *site* - un siège à 60 jours et une succursale à 30 jours est une configuration normale, pas un contournement. [Les conditions de paiement Shopify B2B](/blog/shopify-b2b-payment-terms) donnent les types énumérés et leur comportement sur une commande.
7. **Puis l'historique,** par le chemin qui s'applique. En dernier, parce que c'est l'étape que vous ne pouvez pas annuler partiellement.

La conséquence côté acheteur de cet ordre : les étapes 1 à 6 donnent déjà une boutique B2B qui fonctionne. Prix, conditions et commandes marchent avant qu'une seule commande historique n'ait bougé. Cela compte pour le plan de bascule : l'historique est du reporting, pas une fonction.

## Contraintes pour le cahier des charges
| Contrainte | Détail | Conséquence pour le plan |
| --- | --- | --- |
| Quelles commandes bougent | Commandes B2C uniquement. « Les commandes B2B restent avec l'entreprise pour laquelle elles ont été créées et ne peuvent pas être migrées vers une autre » | Une mauvaise affectation d'entreprise ne se corrige pas en remigrant. Faites d'abord le bon arbre |
| Quelle part d'historique | « Vous ne pouvez ajouter que l'historique complet des commandes d'un client à une entreprise, la migration partielle n'est pas prise en charge » | Vous ne pouvez pas amener deux ans et laisser le reste. Tout ou rien, par client |
| Où atterrit l'historique | « Les commandes ne peuvent pas être réparties sur plusieurs sites » | Un client qui achetait pour trois succursales atterrit sur un site. Décidez lequel, et consignez-le |
| Commandes exclues | « Vous ne pouvez pas migrer des commandes annulées ou supprimées » | Vos comptages de réconciliation ne colleront pas à la source si vous ne les excluez pas d'abord |
| Taille de lot | « Jusqu'à 250 clients B2B en même temps » | 20 000 clients, c'est 80 lots dans l'admin, à la main |
| Automatisation | Les mutations de migration et d'annulation sont internes à Shopify | Pour le chemin A, budgétez du temps d'admin, pas du temps de script |
| Ce qui suit le client | Commandes passées, exonérations de taxe, « autoriser les clients à se faire livrer à n'importe quelle adresse », « soumettre toutes les commandes en commandes provisoires pour revue », conditions de paiement | Ce sont des réglages migrés : posez-les donc sur le client source quand vous le pouvez |
| Ce qui ne suit pas | Les exonérations « définies en désactivant Percevoir la taxe ne sont pas migrées » | Reposez-les comme de vraies exonérations sur le site |
| Annulation - nouvelle entreprise | Supprimer l'entreprise | Annulation propre tant que l'entreprise est neuve et sans commandes B2B |
| Annulation - entreprise existante | Retirer le client, avec « une option pour retirer les commandes d'origine que vous avez migrées » | L'annulation est par client, pas par commande |
| Prérequis | Des clients B2C existants dans l'admin | Le chemin A ne s'applique pas aux comptes qui n'ont jamais été clients Shopify |

## Débit : ce que coûtent vraiment 20 000 clients
Deux réponses différentes, une par chemin.

**Le chemin A, ce sont des personnes, pas du débit.** 250 clients par lot est le seul levier. Vingt mille clients, ce sont quatre-vingts passages dans l'admin, chacun demandant à quelqu'un de sélectionner les bons clients et de choisir la bonne entreprise - la vraie contrainte est donc la qualité de préparation de votre fichier de correspondance, pas la vitesse de Shopify. Construisez la correspondance en tableur, clé sur le même `externalId` que vous avez posé sur les entreprises, triez-la pour que chaque lot soit les clients d'une seule entreprise, et le clic devient mécanique au lieu d'être un jugement répété 20 000 fois.

**Le chemin B, c'est la limite de requêtes.** Les mutations d'entreprise ne figurent pas dans la liste des opérations en masse : il n'y a donc pas d'import JSONL pour les entreprises, ce sont des appels d'API ordinaires contre le budget de points de l'offre. L'API Admin GraphQL restaure **100 points par seconde sur Standard, 200 sur Advanced, 1 000 sur Plus et 2 000 sur Commerce Components**, aucune requête seule ne peut dépasser 1 000 points, et dépasser le budget renvoie `429 Too Many Requests`. Calculez votre coût par entreprise - un `companyCreate` qui crée aussi un site et un contact, plus l'attribution de rôle, plus l'affectation de catalogue -, multipliez, divisez par le taux de restauration. Cela donne un chiffre défendable pour le plan ; plus précis que cela relève de la devinette tant que vous n'avez pas mesuré le coût de vos propres mutations sur une boutique de développement.

L'import de commandes du chemin B suit la même arithmétique par commande, et les commandes sont le grand nombre : une boutique avec 20 000 clients et cinq ans d'historique importe des centaines de milliers d'enregistrements - un travail planifié sur plusieurs jours, avec une idempotence fondée sur l'identifiant de commande source pour qu'une reprise ne double pas les écritures.

## L'identité : la partie que personne ne budgète
La migration est un projet de nettoyage de données déguisé en API. Trois questions décident de sa durée, et aucune n'est technique :

- **Qu'est-ce qu'une entreprise ?** Les fiches clients du système source mélangent le plus souvent organisations, succursales et adresses de livraison, et la réponse à « est-ce une entreprise avec quatre sites ou quatre entreprises ? » change les catalogues, les conditions et le reporting. Tranchez-la avec la finance et les ventes du marchand avant de construire.
- **Qui est contact, et sur quel site ?** Une même personne achète souvent pour plusieurs succursales. Le modèle de Shopify permet à un contact de détenir un rôle sur un site ; savoir si vos données source peuvent dire pour quels sites chaque personne achète est la question à régler tôt, parce que l'attribution de rôle conditionne l'import de commandes.
- **Quels doublons sont réels ?** Deux fiches avec le même e-mail sont une personne ; deux avec le même nom d'entreprise et des e-mails différents peuvent être deux succursales, ou une succursale et une faute de frappe. Résolvez sur l'`externalId` du système source plutôt que sur la ressemblance des noms, et gardez les rapprochements rejetés dans un fichier - on vous les demandera.

Une règle pratique qui évite les reprises : **ne décidez dans le script de migration rien qu'une personne devrait décider.** Le script crée ce que dit le fichier de correspondance ; c'est dans ce fichier que vit le jugement, et il peut être relu par quelqu'un qui connaît les comptes.

## Piloter, puis basculer
Pilotez avec **une entreprise ayant au moins deux sites et un contact qui achète pour les deux.** Ce seul jeu d'essai exerce toutes les contraintes du tableau : l'historique ne peut atterrir que sur l'un des deux sites, les conditions peuvent différer par site, le contact a besoin d'un rôle sur chacun, et l'annulation doit être testée depuis un état où des commandes ont déjà bougé.

Faites-le d'abord sur une boutique de développement, puis en production sur un compte réel mais à faible volume. Vérifiez, dans cet ordre : l'acheteur se connecte et voit ses prix ; une commande de test porte les bonnes conditions ; les commandes historiques apparaissent sur le bon site ; l'annulation ramène le client et ses commandes migrées ; et votre requête de réconciliation colle, une fois exclues les commandes annulées et supprimées.

Seulement ensuite, lancez les lots. Tenez un journal de quels clients sont partis dans quel lot et vers quelle entreprise - l'admin ne vous en donne pas, et c'est l'artefact dont vous aurez besoin quand, dans trois mois, quelqu'un demandera pourquoi l'historique d'un compte paraît court.

## Où se place une couche de devis pendant tout cela
Signalé comme une implémentation. Une couche de devis qui lit Shopify au lieu de garder sa propre copie de la liste clients est insensible à la migration dans un sens et dépendante dans l'autre : elle a besoin de l'arbre d'entreprises et des catalogues (étapes 1 à 6) avant de pouvoir chiffrer un prix propre à une entreprise, et elle n'a besoin de rien de l'étape historique. Le devis peut donc partir en production dès que l'identité et les prix sont en place, souvent des semaines avant le dernier lot dans l'admin.

QuotWay fonctionne ainsi : la proposition faite à un contact d'entreprise connecté part du prix catalogue de son site d'entreprise, résolu au moment de la demande, et le devis accepté se convertit en [commande provisoire](/features/convert-to-orders) portant `purchasingEntity` et les conditions de paiement du site. Il ne stocke ni liste clients ni liste de prix à lui : il n'y a donc rien à migrer de son côté. Les devis liés à l'entreprise sont sur le forfait Enterprise ; la page dédiée est la [page de la fonctionnalité devis B2B Shopify](/features/b2b), l'architecture derrière ce choix est dans [ce qui vit dans Shopify et ce qui appartient à la couche de devis](/blog/shopify-b2b-quote-architecture), et les forfaits sont sur la [page des tarifs](/pricing).

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

## Questions fréquentes

### Puis-je migrer des clients grossistes vers les entreprises Shopify par l'API ?

Vous pouvez créer les entreprises, sites et contacts par l'API Admin, mais pas déplacer l'historique de commandes Shopify existant d'un client : le personnel de Shopify a confirmé en décembre 2025 que les mutations de migration et d'annulation sont internes et non exposées publiquement. Cette étape se fait dans l'admin, jusqu'à 250 clients à la fois. Les commandes historiques venant de l'extérieur de Shopify sont un autre travail et disposent bien d'une API - `orderCreate` avec un site d'entreprise sur la commande.

### L'historique de commandes suit-il quand un client devient contact d'entreprise ?

Seulement si vous le migrez délibérément. Ajouter un client à une entreprise via la migration depuis l'admin amène son historique de commandes B2C ; attribuer un client comme contact via l'API ne transporte pas d'historique en soi. Les commandes B2B ne changent jamais d'entreprise.

### Puis-je migrer une partie de l'historique d'un client ?

Non. La documentation de Shopify est explicite : « vous ne pouvez ajouter que l'historique complet des commandes d'un client à une entreprise, la migration partielle n'est pas prise en charge ». Les commandes annulées et supprimées sont exclues entièrement.

### L'historique d'un client peut-il être réparti sur deux sites d'entreprise ?

Non. Les commandes ne peuvent pas être réparties sur plusieurs sites : un acheteur qui a commandé pour trois succursales atterrit sur un site. Consignez lequel vous avez choisi et pourquoi - sinon le reporting par site paraîtra faux à qui héritera de la boutique.

### Comment migrer 20 000 clients grossistes ?

Triez d'abord la liste par chemin. Pour les comptes dont les commandes sont déjà des commandes B2C Shopify, ce sont quatre-vingts lots de 250 dans l'admin : le travail est dans la préparation d'un fichier de correspondance qui rend chaque lot mécanique. Pour les comptes dont l'historique vit dans un système hérité, c'est scripté : créez l'arbre par l'API Admin dans la limite de requêtes de votre offre, puis importez les commandes avec `orderCreate`, idempotent sur l'identifiant de commande source.

### Une migration peut-elle être annulée ?

En partie. Une entreprise nouvellement créée peut être supprimée, ce qui ramène le client et ses commandes migrées. Retirer un client d'une entreprise existante propose de reprendre les commandes migrées avec lui. Aucun des deux ne donne une annulation par commande, et c'est la raison pour laquelle l'historique passe en dernier.

### Faut-il Shopify Plus pour migrer vers les entreprises ?

Non. [Le B2B est sur toutes les offres Shopify](/blog/shopify-b2b-without-plus) : entreprises, sites, contacts et conditions de paiement sont disponibles quelle que soit l'offre. Plus change le côté catalogue - catalogues actifs illimités et affectation directe à une entreprise ou à un site, contre trois catalogues actifs sur l'ensemble des marchés B2B en dessous - et l'offre fixe aussi votre limite de requêtes API, ce qui détermine la vitesse d'un import scripté.

## Sources

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

- [Migrer des clients vers le B2B](https://help.shopify.com/en/manual/b2b/getting-started/migrating-customers) - la règle B2C uniquement, l'historique entier ou rien, pas de répartition sur les sites, le lot de 250, ce qui suit le client, les voies d'annulation et l'exclusion des commandes annulées et supprimées
- [Historic orders linking to Company / Customer](https://community.shopify.dev/t/historic-orders-linking-to-company-customer/26587) - Shopify Staff, 2 décembre 2025 : les mutations de migration et d'annulation sont internes
- [Importer des commandes B2B](https://shopify.dev/docs/apps/build/b2b/import-orders) - `orderCreate` avec `companyLocationId` et `customer.toAssociate`, et l'exigence d'attribution de rôle
- [companyCreate](https://shopify.dev/docs/api/admin-graphql/latest/mutations/companyCreate) et [companyAssignCustomerAsContact](https://shopify.dev/docs/api/admin-graphql/latest/mutations/companyAssignCustomerAsContact)
- [Start building for B2B](https://shopify.dev/docs/apps/build/b2b/start-building) - l'ordre de création et le prérequis de catalogue
- [Limites de requêtes de l'API Admin GraphQL](https://shopify.dev/docs/apps/build/apis/graphql-admin/rate-limits) - les taux de restauration par offre et le plafond de 1 000 points par requête
- [Imports en masse](https://shopify.dev/docs/api/usage/bulk-operations/imports) (lu le 22 septembre 2026) - la liste des mutations prises en charge, qui n'inclut pas les mutations d'entreprise
- Règles de catalogue, de conditions de paiement et de fiscalité : la [référence Shopify B2B](/reference/shopify-b2b#migration), revérifiée les 22 et 23 septembre 2026

Le comportement de QuotWay pendant une migration est décrit d'après sa propre architecture et la documentation liée ci-dessus.