Shopify : Approvisionnement des stocks dans les bacs - Quelles hypothèses les développeurs doivent-ils modifier ?
Shopify : Approvisionnement des stocks dans les bacs - Quelles hypothèses les développeurs doivent-ils modifier ?
Les développeurs doivent prévoir un modèle de stock au niveau des bacs et traiter les aperçus avec prudence.
Le système de gestion des stocks de Shopify a principalement fonctionné autour des emplacements : quel article de stock se trouve dans quel entrepôt, magasin ou lieu d’exécution, combien sont disponibles à la vente, en transit, engagés ou en stock. Pour de nombreux commerçants, ce modèle est suffisant pour soutenir les ventes en ligne et l’exécution de base.
Cependant, pour les systèmes ERP, WMS, 3PL et les applications de gestion des stocks, ce niveau de granularité est souvent trop grossier.
Ce qui se passe réellement dans un entrepôt n’est généralement pas seulement “un SKU a 100 unités dans un entrepôt”. La situation la plus courante est que ce SKU a 40 unités sur l’étagère 3 de l’entrepôt A, 20 unités dans la zone de réapprovisionnement et 5 unités dans la zone des anomalies. Les différents emplacements peuvent influencer les chemins de prélèvement, les méthodes d’inventaire, les actions de réapprovisionnement et le traitement des anomalies.
Shopify est en train de combler cette lacune.
Selon la documentation de l’API GraphQL Admin instable de Shopify.dev du 2026-07, Shopify propose un aperçu de la fonctionnalité d’inventaire physique, couvrant les bacs, les quantités, les commandes d’achat, etc. Parmi ceux-ci, un bac est défini comme un stockage nommé à l’intérieur d’un emplacement, pouvant être compris comme une étagère, un emplacement d’étagère, un compartiment, etc.
Les développeurs peuvent créer ou mettre à jour un bac via inventoryBinUpsert, et peuvent également définir la quantité disponible d’un article d’inventaire dans un bac donné via inventoryCountCreate.
Cela indique que le modèle de stock de Shopify commence à se subdiviser au niveau des emplacements. Cela ne signifie pas que Shopify a déjà fourni un WMS complet. Un jugement plus précis serait que Shopify est en train de fournir une couche d’infrastructure de stock plus proche de la réalité sur le terrain de l’entrepôt.

Relation des objets de stock de Shopify : L’emplacement reste le niveau d’agrégation des stocks, le bac complète l’expression des emplacements internes de l’entrepôt. Source de l’image : Shopify.dev
L’emplacement reste le niveau central
Pour comprendre ce changement, il faut d’abord revenir à la relation existante des objets de stock de Shopify.
Dans la documentation de Shopify, le ProductVariant est responsable des informations sur les variantes de produits destinées aux clients ; l’InventoryItem représente les biens physiques utilisés pour le stock, le transport et l’exécution ; l’InventoryLevel relie un InventoryItem à un Location, afin de suivre l’état du stock de cet article à cet emplacement.
L’InventoryLevel implique des états de quantité tels que disponible, en main, entrant, engagé, etc. L’emplacement est le lieu géographique ou commercial où le commerçant exerce son activité, comme un magasin de détail ou un entrepôt.
La relation centrale de ce modèle a toujours été :
Un InventoryItem, à un Location, a un ensemble d’états de stock.
Avec l’ajout de l’aperçu de la fonctionnalité d’inventaire physique, cette relation n’a pas été renversée. Le bac se trouve à l’intérieur de l’emplacement, l’emplacement continue de jouer le rôle d’agrégation des stocks, de disponibilité à la vente, de lieu d’exécution et de lieu commercial.
Dans la documentation de l’aperçu de la fonctionnalité, Shopify a donné une relation de calcul clé :
quantité totale en main de l’emplacement = unbinnedQuantity + somme de toutes les quantités des bacs.
Cela signifie que le bac permet une distribution physique plus fine des quantités en main à l’intérieur de l’emplacement, mais le total au niveau de l’emplacement reste présent. L’existant inventorySetQuantities continue également de fonctionner ; lorsque les développeurs définissent les stocks au niveau de l’emplacement, cette quantité entre dans la quantité non attribuée.
Ce design est crucial pour les développeurs. Shopify n’a pas remplacé l’emplacement par le bac, mais a ajouté un niveau qui peut exprimer les emplacements physiques sous l’emplacement.
Le bac résout le problème des “emplacements internes de l’entrepôt”
Dans la portée de la documentation publique actuelle, le bac peut être compris comme un stockage nommé à l’intérieur de l’emplacement. Sa valeur réside principalement dans la gestion interne de l’entrepôt, et non dans la logique de vente au détail.
Pour les WMS et ERP, le bac influencera au moins trois types de conception de systèmes.
Premièrement, la synchronisation des stocks ne peut pas se limiter à l’item + l’emplacement.
Dans le passé, de nombreux systèmes ne maintenaient que la relation entre SKU, InventoryItem, Location et quantité. Avec l’ajout du bac, si une application veut exprimer le stock réel à l’intérieur de l’entrepôt, elle devra maintenir une relation de quantité supplémentaire entre item + location + bin.
Deuxièmement, l’inventaire sera plus proche de la réalité sur le terrain de l’entrepôt.
L’aperçu de la fonctionnalité d’inventaire physique couvre les quantités. Le inventoryCountCreate donné dans la documentation peut définir la quantité en main d’un article d’inventaire dans un bac donné. Cela montre que Shopify réserve une sémantique API pour “l’inventaire par emplacement”, et pas seulement pour modifier un total d’emplacement.
Troisièmement, les stocks anormaux ont un point d’ancrage plus clair.
Dans un modèle sans bac, les quantités dans plusieurs emplacements de l’entrepôt, zones de stockage temporaire, zones de retour et zones d’attente de contrôle qualité ne peuvent souvent être enregistrées que par un WMS externe, puis les résultats agrégés synchronisés avec Shopify. Avec l’apparition du niveau de bac, les développeurs ont la possibilité d’exprimer une partie de la distribution des emplacements physiques du côté de Shopify.
Il est important de contrôler les attentes. La documentation actuelle parle d’aperçu de fonctionnalité et se trouve dans une API instable. Elle convient aux développeurs pour tester, pré-rechercher et ajuster les modèles de données, mais ne doit pas être utilisée comme dépendance unique d’un système de production.
Ce n’est pas encore un WMS complet
La page publique de résumé des éditions Shopify Winter ‘26 indique que Shopify prend en charge l’attribution de bacs aux SKU via l’éditeur en masse CSV ou l’application Order Printer, afin d’améliorer l’efficacité de prélèvement.
En mettant cette information en relation avec l’aperçu de la fonctionnalité de Shopify.dev, on peut voir une direction : Shopify intègre les “emplacements de bacs” dans un plus grand éventail de capacités officielles.
Cependant, d’après les informations vérifiées, cela ne peut pas être interprété comme signifiant que Shopify a déjà intégré un WMS complet.
D’après les informations vérifiées, Shopify mentionne publiquement les bacs, les quantités, les commandes d’achat, ainsi que l’attribution de bacs aux SKU pour améliorer l’efficacité de prélèvement. Ces informations suffisent à montrer que Shopify renforce les capacités de base liées aux stocks et aux emplacements internes, mais ne suffisent pas à soutenir la conclusion que “Shopify a déjà fourni un WMS complet”.
Un jugement plus prudent serait que Shopify renforce l’infrastructure de stock, fournissant une base plus standard pour les ERP, WMS, 3PL et applications. Cela réduira certaines personnalisations entre systèmes concernant les “emplacements internes de l’entrepôt”, mais ne peut pas encore remplacer les capacités de processus complètes d’un WMS professionnel.
Impact sur les développeurs d’ERP, WMS et d’applications
Ce sur quoi les développeurs doivent se concentrer maintenant, ce n’est pas de lancer immédiatement la fonctionnalité de bac, mais de corriger à l’avance les hypothèses du modèle.
Si le système continue de supposer par défaut “un item dans un emplacement n’a qu’une seule quantité de stock”, il sera très facile de se retrouver bloqué par la suite. Un design plus sûr consiste à décomposer le stock en deux niveaux :
• La synchronisation externe et le jugement d’exécution restent basés sur item + location ;
• La distribution interne et les enregistrements d’inventaire prévoient item + location + bin.
Il doit y avoir une frontière claire entre ces deux niveaux. La quantité en main au niveau de l’emplacement est un résultat agrégé ; la quantité au niveau du bac est une distribution physique. L’unbinnedQuantity signifie qu’il reste une partie du stock de l’emplacement qui n’a pas été attribuée à un bac spécifique.
Cela soulève un problème pratique : lors de la synchronisation entre systèmes, qui est le système principal des données de bac ?
Si le WMS est le système principal, les données de bac de Shopify peuvent simplement être le résultat de la synchronisation. Si le backend de Shopify ou l’application Shopify permet d’éditer les bacs, le WMS devra également gérer l’écriture, les conflits et l’audit. Les développeurs doivent concevoir à l’avance plusieurs types de frontières :
• Qui contrôle les règles de création et de nommage des bacs ;
• Comment les ID de bac sous un même emplacement se mappent aux codes d’emplacement des entrepôts externes ;
• Comment les ajustements de stock au niveau de l’emplacement entrent dans l’unbinnedQuantity, et comment les systèmes externes traitent cela ;
• L’inventaire couvre-t-il un bac spécifique ou l’ensemble de l’emplacement ;
• Lorsque l’API est encore dans un état instable / d’aperçu de fonctionnalité, si l’environnement de production nécessite un interrupteur de fonctionnalité.
Ces questions sont plus importantes que “peut-on faire fonctionner une mutation”.
En particulier, le fait que inventorySetQuantities reste disponible signifie que les anciennes et nouvelles méthodes d’écriture des stocks coexisteront. Les développeurs ne peuvent pas supposer que tous les stocks tomberont naturellement dans les bacs. De nombreuses données historiques, applications tierces, opérations manuelles et anciens processus peuvent encore n’écrire des quantités qu’au niveau de l’emplacement.
Impact sur les commerçants et les prestataires de services
Pour les commerçants, la capacité des bacs a la valeur la plus directe de rendre le prélèvement et l’inventaire plus clairs.
Si un entrepôt a peu de SKU et que le chemin de prélèvement est simple, le stock au niveau de l’emplacement peut encore suffire. L’introduction des bacs augmentera le coût de maintenance des données de base, y compris le codage des emplacements, le lien SKU, les règles d’inventaire et les normes d’opération des employés.
Si un commerçant a déjà plusieurs entrepôts, plusieurs zones de prélèvement, ou si le même SKU est dispersé sur plusieurs étagères, les bacs auront plus de sens. Ils peuvent aider le système à exprimer “où se trouve la marchandise”, et pas seulement “si cet entrepôt a de la marchandise”.
Les prestataires de services doivent également éviter de faire des promesses excessives lors de la proposition de solutions aux commerçants. Les bacs peuvent être intégrés dans la planification en tant qu’orientation vers la précision des stocks, mais il ne faut pas présenter un aperçu de fonctionnalité instable comme une capacité de livraison stable. La disponibilité dépendra également du backend du magasin du commerçant, de la version de l’API, des autorisations d’application et de la documentation officielle ultérieure de Shopify.
Le résumé de la page publique des éditions Spring ‘26 mentionne également que le champ permitsSkuSharing a été supprimé, permettant à tout service d’exécution d’avoir des stocks dans plusieurs emplacements. Cette direction est liée à la flexibilité de l’exécution au niveau des emplacements, indiquant que Shopify continue d’ajuster les frontières des services d’exécution et des stocks multi-emplacements. Les changements d’API spécifiques doivent toujours être vérifiés dans la documentation de la version correspondante.
Que faire maintenant
Pour les développeurs, une approche plus prudente consiste en trois étapes.
D’abord, ajustez le modèle de données pour qu’il puisse accueillir les bacs. Même si vous ne les activez pas temporairement, ne codifiez pas l’hypothèse d’un stock unique item + location dans la structure de table centrale et la logique de synchronisation.
Ensuite, créez un adaptateur. Traitez séparément le stock au niveau de l’emplacement de Shopify, le stock au niveau du bac, l’unbinnedQuantity et le stock des emplacements WMS externes, afin d’éviter de lier directement l’API d’aperçu en profondeur dans le lien principal de production.
Enfin, établissez un interrupteur de fonctionnalité et une isolation des versions. L’inventaire physique est actuellement un aperçu de fonctionnalité / instable, adapté aux magasins sandbox, aux magasins de test et à la recherche interne. Les systèmes de production peuvent d’abord conserver un point d’entrée compatible, et élargir leur utilisation lorsque Shopify passe à une version plus stable.
Pour les commerçants, à ce stade, il est conseillé de commencer par organiser les données de base de l’entrepôt : l’emplacement est-il clair, le SKU est-il stable, le nom des emplacements est-il uniforme, est-il vraiment nécessaire de prélever et d’inventorier par emplacement ? Lorsque les données de base sont confuses, activer les bacs à l’avance ne fera que transférer la confusion dans le système.
Shopify est en train de faire avancer son système de gestion des stocks vers une granularité plus fine. L’emplacement reste le noyau de l’agrégation des stocks et du jugement d’exécution, tandis que le bac complète l’expression des emplacements physiques internes. Pour les développeurs, ce n’est pas un champ à ignorer, mais un signal que les frontières du système de gestion des stocks vont devenir plus fines.
L’action la plus appropriée maintenant n’est pas de se précipiter, mais de garder le modèle flexible, de clarifier les frontières de synchronisation et de considérer l’aperçu comme un objet de recherche. Une fois que l’état de l’API sera stabilisé, les véritables modifications ne concerneront pas l’ensemble de l’infrastructure de gestion des stocks.