Le routage des commandes Shopify peut attribuer une commande à un entrepôt qui semble idéal sur le papier, mais qui complique sa préparation. La dernière mise à jour destinée aux développeurs permet aux fonctions de routage des commandes de classer les emplacements pour plusieurs groupes de traitement dans les API instables. Pour les marchands disposant de plusieurs lieux de traitement, une question se pose : quels groupes doivent partager la même préférence d’emplacement, et lesquels nécessitent une approche différente ? Voici comment nous évaluerions cette évolution avant d’engager du temps de développement ou de modifier le routage en production.
Qu’est-ce qui change dans le routage des commandes Shopify ?
Dans son journal des mises à jour développeurs du 5 novembre, Shopify a annoncé que les fonctions de routage des commandes peuvent désormais appliquer un classement des emplacements à plusieurs groupes de traitement dans les API instables de Shopify Functions.
Un classement partagé exprime la même préférence d’emplacement pour plusieurs groupes de traitement. Cela ne signifie pas, à lui seul, que ces groupes seront réunis dans une seule expédition. Privilégier un entrepôt ne garantit pas qu’il puisse traiter l’ensemble des articles.
Cette distinction est importante. Les marchands évaluent généralement le routage à partir de ses résultats : quel entrepôt a reçu la commande, si le client a reçu plusieurs colis et combien a coûté la livraison. Les développeurs doivent aussi tenir compte des groupes transmis à une fonction et de la façon dont son classement interagit avec le reste de la configuration du routage.
Notre avis : cette mise à jour mérite d’être étudiée si votre activité nécessite une préférence d’emplacement cohérente entre les groupes. L’arrivée d’une nouvelle fonctionnalité API ne justifie pas, à elle seule, de remplacer un routage qui fonctionne.
Une API instable appelle une évaluation, pas une mise en production précipitée
Cette annonce concerne explicitement les API instables. Elle ne fixe aucune date de disponibilité dans une version stable et n’impose aucune migration aux marchands.
Demandez à votre développeur d’examiner le schéma actuel et de confirmer le comportement pris en charge dans un environnement de développement. Avant de planifier un déploiement en production, vérifiez la disponibilité dans la version d’API visée ainsi que l’éligibilité de votre application et de votre boutique. L’annonce ne constitue pas, à elle seule, une spécification de mise en œuvre complète.
Partez de la décision logistique, pas de la fonction
Avant d’écrire du code, décrivez la décision que votre équipe logistique souhaite prendre. « Privilégier l’entrepôt principal » reste trop vague. Dans quelles circonstances ? Que se passe-t-il lorsqu’un magasin dispose de stock, mais doit le conserver pour ses clients sur place ?
Prenons l’exemple fictif d’un marchand de vêtements qui prépare ses commandes depuis un entrepôt central et ses magasins. Un panier contient des vêtements d’extérieur et un accessoire, et les données transmises au routage comportent plusieurs groupes de traitement. Le marchand peut souhaiter que chaque groupe privilégie l’entrepôt central dès lors que celui-ci peut traiter les articles concernés.
Une préférence commune peut être pertinente dans ce cas. Mais si l’accessoire n’est disponible qu’en magasin, le classement partagé ne créera pas de stock à l’entrepôt. L’équipe ne doit pas non plus supposer que cette préférence regroupera les expéditions.
Prenons maintenant un produit qui exige une manutention spécifique. S’il doit être expédié depuis un site particulier, cette obligation doit être préservée. Une préférence générale pour un entrepôt ne doit pas prendre le pas sur une contrainte opérationnelle.
Distinguez les critères qui rendent un emplacement admissible de ceux qui le rendent préférable parmi les emplacements admissibles. Demandez ensuite au développeur quelles règles peuvent être exprimées par l’extension de routage et lesquelles relèvent d’autres paramètres de traitement des commandes.
Quand partager le classement des emplacements dans Shopify ?
Le cas d’usage le plus pertinent est celui de règles métier répétées. Si différents groupes doivent suivre la même préférence d’entrepôt, l’exprimer de façon cohérente peut rendre la mise en œuvre plus facile à comprendre et à maintenir. C’est un bénéfice technique potentiel, pas la preuve d’une baisse des frais de livraison.
Privilégier l’entrepôt central
Un marchand peut vouloir donner la priorité à son entrepôt central parce qu’il dispose d’une équipe dédiée aux expéditions, les magasins ne prenant le relais qu’en cas de besoin. Le classement partagé mérite d’être étudié si cette préférence s’applique réellement à tous les groupes concernés.
La contrepartie est la concentration de l’activité. Envoyer davantage de commandes vers l’entrepôt privilégié peut le mettre sous pression. Votre politique de routage doit tenir compte des capacités opérationnelles, plutôt que de considérer une hiérarchie d’entrepôts établie comme immuable.
Maintenir une cohérence régionale
Un marchand peut également souhaiter que les groupes d’une même commande suivent la même préférence régionale d’emplacement. Cette décision peut s’appuyer sur un service de livraison éprouvé ou sur un processus d’expédition plus prévisible.
Vérifiez les données que la fonction reçoit réellement avant de vous engager sur des règles régionales. Ne construisez pas une politique fondée sur les tarifs transporteurs en temps réel ou sur les capacités des entrepôts sans avoir confirmé comment ces informations alimentent la décision.
Qui peut se passer d’un développement sur mesure ? Les marchands dont les paramètres de routage existants couvrent déjà le comportement souhaité, ainsi que les entreprises qui ont rarement un véritable choix à faire entre plusieurs lieux de traitement. Le code sur mesure implique des responsabilités de maintenance et de test. Il doit résoudre un problème observable.
Documentez les exceptions avant de choisir un classement
Une préférence d’emplacement devient risquée lorsque tout le monde connaît la règle par défaut, mais que personne ne se souvient des exceptions. Nous demanderions à l’équipe logistique de documenter les cas suivants avant de lancer le développement :
- Produits soumis à des restrictions : identifiez les articles qui nécessitent un site ou un processus de manutention particulier.
- Préservation du stock magasin : précisez dans quels cas le stock doit rester disponible pour les clients sur place.
- Contraintes d’expédition : consignez les situations dans lesquelles l’emplacement privilégié ne peut pas tenir la promesse de livraison.
- Emplacements indisponibles : définissez le comportement acceptable lorsque l’entrepôt habituel ne peut pas prendre en charge la commande.
Ce document doit décrire les besoins métier, sans présumer que chaque exigence correspond à une donnée d’entrée prise en charge par la fonction. Le développeur devra ensuite associer chaque exigence à un comportement vérifié de la plateforme.
Si les informations nécessaires ne sont pas disponibles, simplifiez la politique ou adaptez les processus associés. Une règle de routage fondée sur des hypothèses obsolètes peut être moins efficace qu’une règle par défaut simple, bien comprise par l’équipe de l’entrepôt.
Testez les décisions de routage sur des profils de commandes réels
La bonne exécution d’une fonction ne suffit pas. Le véritable test consiste à vérifier que sa décision correspond à un résultat métier validé.
Dans un environnement de développement, utilisez des compositions de paniers représentatives de votre historique, après suppression des données clients. Incluez aussi bien des commandes traitées sans difficulté que des commandes ayant nécessité une réaffectation manuelle. Pour chaque scénario, consignez l’état des stocks concerné et la préférence d’emplacement attendue avant de lancer le test.
Votre jeu de tests doit inclure :
- Des groupes dont tous les articles sont disponibles dans l’entrepôt privilégié.
- Un groupe qui ne peut pas être traité par l’entrepôt privilégié.
- Des articles soumis à une contrainte de manutention propre à un emplacement.
- Un emplacement habituellement privilégié, mais indisponible.
- Des groupes qui nécessitent légitimement des préférences différentes.
- Un profil de commande qui impose actuellement une intervention manuelle.
Pour chaque cas, examinez le classement, puis suivez le résultat du traitement de la commande en aval. Conservez ces observations séparément. Un classement correct peut malgré tout produire une répartition des expéditions indésirable si une autre contrainte régit le traitement.
Demandez à l’équipe logistique de valider les résultats avec le développeur. Un test peut réussir sur le plan technique tout en attribuant des commandes à un site dont l’équipe d’expédition ne peut pas les prendre en charge.
Mesurez les résultats sans promettre moins de colis
Le classement partagé est une fonctionnalité de routage. La réduction du nombre de colis est un résultat métier possible, qui reste à démontrer.
Avant toute modification en production, mesurez la fréquence des réaffectations manuelles et identifiez leurs causes. Suivez séparément les expéditions fractionnées. Intégrez le coût réel du traitement des commandes lorsque vos outils de reporting le permettent, au lieu de considérer l’emplacement privilégié comme systématiquement le moins cher.
Comparez des profils de commandes similaires après le changement. Les variations de disponibilité des stocks peuvent fausser les résultats : si l’entrepôt principal est réapprovisionné pendant l’évaluation, le routage peut sembler s’améliorer alors que la nouvelle logique y contribue peu.
Nous examinerions aussi les performances d’expédition. Une politique qui réduit les réaffectations mais surcharge l’entrepôt privilégié peut dégrader l’expérience client. Décidez à l’avance quel résultat opérationnel justifierait de conserver le changement et lequel déclencherait un retour à la configuration précédente.
Anticipez les incidents avant d’activer les règles
Désignez un responsable de la mise en œuvre et documentez la procédure de restauration de l’ancienne configuration de routage. Conservez la politique métier validée avec la configuration technique, afin que les équipes d’assistance puissent distinguer une exception prévue d’un dysfonctionnement.
En cas d’incident, consultez Shopify Status, qui fournit des informations sur l’état de la plateforme et oriente les marchands vers l’état détaillé de leur boutique. Utilisez-le comme un élément de diagnostic parmi d’autres. Un incident sur la plateforme ne prouve pas que votre fonction est en cause, et une page de statut indiquant un fonctionnement normal ne garantit pas que votre logique sur mesure est correcte.
Examinez ensuite le contexte de routage de la commande concernée et les outils de diagnostic disponibles dans l’application. Évitez les réaffectations manuelles répétées tant que personne n’a identifié si le problème vient d’un manque de stock, d’une préférence inadaptée ou d’un échec d’exécution.
Pour une fonctionnalité d’API instable, la première étape est une étude en environnement de développement, avec des résultats documentés. Ne modifiez pas la politique de routage en production tant que les conditions de déploiement prises en charge et le comportement métier ne sont pas clairement établis. Vous tirerez davantage parti de cette nouveauté ainsi qu’en introduisant précipitamment une logique expérimentale dans un service d’expédition déjà très sollicité.
À retenir
- La nouvelle fonctionnalité Shopify applique un classement des emplacements à plusieurs groupes de traitement dans les API instables de Shopify Functions.
- Un classement partagé ne garantit ni le regroupement des expéditions ni une baisse des coûts de traitement.
- Distinguez l’admissibilité d’un emplacement de sa priorité et documentez les exceptions avant le développement.
- Testez des commandes représentatives et vérifiez la prise en charge en production avant de modifier le routage actif.
Sources
- Les fonctions de routage des commandes peuvent désormais classer les emplacements pour plusieurs groupes de traitement dans les API instables de Shopify Functions.
- Shopify Status
Vous préférez nous confier le sujet ?
ZAGO est Shopify Premier Partner. Performance, optimisation du taux de conversion et création de boutiques rentables : c’est notre métier au quotidien. Réservez un audit gratuit de votre boutique : nous vous présenterons les trois améliorations que nous mettrions en œuvre en priorité.
Questions fréquentes
Qu’est-ce qui a changé dans le routage des commandes Shopify en novembre 2026 ?
Shopify a annoncé que les fonctions de routage des commandes peuvent appliquer un classement des emplacements à plusieurs groupes de traitement dans les API instables de Shopify Functions. Les marchands doivent vérifier la prise en charge dans une version stable de l’API avant de planifier une mise en production.
Le classement partagé des emplacements regroupe-t-il les expéditions Shopify ?
Pas à lui seul. Un classement partagé exprime une préférence d’emplacement commune à plusieurs groupes. La disponibilité des stocks et les autres contraintes de traitement déterminent toujours si les articles peuvent être expédiés ensemble.
Toutes les boutiques Shopify doivent-elles développer un routage des commandes sur mesure ?
Non. Un développement sur mesure mérite d’être étudié lorsque le routage existant ne permet pas de répondre à un besoin métier documenté. Les boutiques dont les paramètres actuels fonctionnent bien risquent de tirer peu de bénéfices de cette maintenance supplémentaire.
Comment tester une fonction de routage des commandes Shopify ?
Utilisez des profils de commandes représentatifs dans un environnement de développement et définissez au préalable le résultat attendu. Incluez des ruptures de stock, des produits soumis à des restrictions et des exceptions liées aux emplacements. Examinez à la fois le classement et le résultat du traitement de la commande en aval.
