Livraison Shopify par Markets : recetter la migration
Préparez la livraison Shopify pilotée par Markets : impacts sur les tarifs, applications, retraits, commandes fractionnées et plan de recette.
La livraison Shopify pilotée par Markets ne doit pas être activée comme un simple changement de menu. La configuration marchande passe d’une hiérarchie centrée sur les profils de livraison à une organisation par marché, option de livraison, conditions de produit et localisations de préparation. Une application qui lit ou modifie les profils du marchand peut devoir évoluer ; une application qui gère uniquement son propre profil peut continuer à fonctionner sans changement.
La bonne décision consiste donc à inventorier les dépendances, construire une boutique de test, comparer les tarifs et les promesses sur des paniers représentatifs, puis ouvrir la migration par étapes. La matrice Anakyos marché → contexte → produit → localisation → option → application → effet → preuve transforme l’annonce de plateforme en recette métier vérifiable.
Ce qui change dans la livraison Shopify par Markets
Dans le modèle historique, la configuration suit principalement cette chaîne : profil de livraison, groupe de localisations, zone, puis tarif. Dans le nouveau modèle, le point de départ devient le marché. Le marchand définit les options visibles dans ce marché, puis fait varier leurs tarifs selon les produits et les localisations concernées.
La documentation officielle de la préversion Market-driven shipping résume ce déplacement et précise une différence importante : la configuration possédée par le marchand migre vers l’API Markets, tandis que les profils possédés par une application continuent d’utiliser l’API existante des profils de livraison.
Le changement est utile lorsqu’une boutique vend dans plusieurs pays, sous-régions, contextes B2B ou réseaux de préparation. Il permet aussi de regrouper des variations dans une même option. Si deux tarifs « Standard » de cette option correspondent au panier, Shopify peut retenir le plus élevé plutôt que les additionner. Cela ne signifie pas que tous les frais de port vont baisser : le résultat dépend de la manière dont les options, collections et localisations sont reconstruites.
Shopify a ouvert la préversion aux développeurs le 1er juillet 2026. L’opt-in marchand a commencé le 1er octobre 2026 et la plateforme annonce une généralisation au 1er juillet 2027. Shopify indique que ces dates sont des objectifs susceptibles d’évoluer. La fenêtre actuelle sert donc à prouver la compatibilité, pas à promettre un calendrier immuable.
Qui doit agir — et qui peut d’abord observer
La migration ne crée pas le même travail pour toutes les boutiques.
| Situation observée | Risque principal | Première décision |
|---|---|---|
| aucun outil ne lit ni ne modifie les profils du marchand | configuration mal transposée au moment du passage | comparer les marchés, options, collections et tarifs migrés |
| application utilisant seulement son propre profil | coexistence mal comprise entre tarifs marchands et tarifs applicatifs | vérifier l’affichage conjoint et les paniers couverts |
| application lisant les profils du marchand | données incomplètes après le passage à Markets | migrer le chemin de lecture et tester les deux modèles pendant la transition |
| application écrivant dans les profils du marchand | règle ou tarif non appliqué après l’activation | choisir un profil possédé par l’application ou une écriture via Markets |
| OMS, ERP ou 3PL raisonnant uniquement au niveau de la commande | préparation ou statut incohérent lorsque la commande se fractionne | recetter chaque ordre de traitement et sa réconciliation |
| boutique combinant expédition et retrait | option absente, doublon ou disponibilité partielle mal interprétée | tester les combinaisons par produit, lieu et éligibilité du plan |
Le guide de mise à niveau de Shopify propose un test concret pour les applications : rechercher les lectures et mutations liées à deliveryProfile, deliveryProfiles, deliveryProfileCreate, deliveryProfileUpdate et deliveryProfileRemove, puis identifier si elles ciblent un profil appartenant au marchand ou à l’application.
Cette étape évite deux raccourcis. Le premier serait de conclure que toute application de livraison doit être réécrite. Le second serait de croire qu’une boutique peut activer la nouvelle architecture parce que son thème et son checkout semblent normaux sur un seul panier.
Établir une référence avant la migration
Une recette compare deux états. Avant d’activer la préversion ou l’opt-in, conservez une référence assez précise pour expliquer un écart sans recopier inutilement toutes les données de la boutique.
Inventoriez au minimum :
- les marchés actifs, leurs pays et leurs éventuelles sous-régions ;
- les profils, zones, groupes de localisations et tarifs actuels ;
- les collections ou familles de produits qui portent une règle particulière ;
- les localisations capables de préparer chaque famille ;
- les tarifs calculés par Shopify, un transporteur ou une application ;
- les seuils de gratuité, poids, valeur et délais affichés ;
- les retraits, livraisons locales et fractions de commande autorisés ;
- les applications, fonctions, webhooks, automatisations, OMS, ERP et 3PL qui lisent ou modifient ces données ;
- les paniers et adresses qui représentent les ventes réelles ;
- la procédure de retour au réglage précédent pendant la phase où Shopify l’autorise.
Photographier seulement l’écran de réglage ne suffit pas. La référence doit relier la configuration au résultat vu par l’acheteur et à l’ordre de traitement reçu par les opérations. Notre guide sur la supervision d’une application Shopify détaille cette continuité entre signal technique, impact métier, diagnostic et reprise.
La matrice Anakyos des huit preuves de livraison
Créez une ligne par scénario de panier et d’adresse. La matrice ne cherche pas à reproduire toutes les commandes possibles ; elle protège les combinaisons qui peuvent modifier un prix, une promesse, une disponibilité ou une opération.
| Preuve | Question de recette | Élément à conserver | Signal d’arrêt |
|---|---|---|---|
| Marché | quel marché et quelle sous-région gouvernent l’adresse ? | marché résolu, statut actif et règle héritée | aucun marché ne couvre une adresse vendue |
| Contexte | s’agit-il d’un acheteur grand public, B2B, POS ou d’un autre contexte pris en charge ? | contexte attendu et droits associés | une règle grand public remplace silencieusement une règle B2B |
| Produit | quelle collection ou condition porte le tarif ? | variantes du panier et collection effective | un nouveau produit échappe à la condition prévue |
| Localisation | quels lieux peuvent réellement préparer les lignes ? | stock, priorité, disponibilité et lieu choisi | le tarif dépend d’un lieu incapable de traiter la commande |
| Option | quel tarif, délai ou retrait l’acheteur doit-il voir ? | options affichées, prix, devise et promesse | absence, doublon ou somme inattendue |
| Application | qui lit, calcule ou écrit la règle ? | propriétaire du profil, appel utile et réponse | deux systèmes pensent posséder la même configuration |
| Effet | quels ordres, réservations et notifications sont produits ? | état du checkout, ordre de traitement et état aval | le bon prix crée un mauvais flux opérationnel |
| Preuve | peut-on comparer, expliquer et annuler le résultat ? | capture, identifiants non sensibles, état avant/après et décision | le verdict repose sur « cela semble fonctionner » |
Cette matrice est volontairement plus large qu’un test d’API. La valeur d’une règle de livraison apparaît au checkout, mais son coût réel peut se révéler dans l’entrepôt, le service client, le remboursement ou la réconciliation comptable.
Dix scénarios à rejouer sur une boutique de test
Shopify recommande d’utiliser une nouvelle boutique de développement avec la préversion activée pour vérifier les intégrations. Préparez les résultats attendus avant d’observer la nouvelle configuration.
| Scénario | Variation à introduire | Résultat à vérifier |
|---|---|---|
| marché principal | produit courant, stock local, adresse habituelle | option, tarif, délai et lieu identiques à la référence |
| autre marché | même produit et autre pays ou sous-région | marché correct, devise et option autorisée |
| panier mixte | produits relevant de deux conditions | consolidation prévue, sans addition ni gratuité accidentelle |
| plusieurs localisations | stock disponible dans deux lieux | tarif cohérent avec le lieu réellement sélectionnable |
| seuil de gratuité | paniers juste sous, au-dessus et au niveau du seuil | bascule exacte, arrondis et devise contrôlés |
| produit récemment ajouté | variante entrée après la migration | appartenance à la collection et tarif attendus |
| tarif fourni par une application | règle marchande et règle applicative simultanées | options lisibles, propriétaire identifiable et absence de doublon |
| expédition et retrait | produits disponibles dans des lieux différents | choix permis uniquement dans les contextes éligibles |
| fractionnement | lignes préparées à des dates ou lieux distincts | nombre de colis, coût et promesse compréhensibles |
| panne d’un service | transporteur, application, OMS ou ERP indisponible | repli borné, alerte, aucune promesse inventée et reprise sans doublon |
Rejouez aussi les remboursements partiels, annulations et modifications de commande qui touchent vos opérations. Un checkout correct ne prouve pas que les systèmes aval savent encore interpréter chaque ordre de traitement.
Tester la consolidation des tarifs sans promettre une économie
Le nouveau modèle peut retenir le tarif le plus élevé parmi plusieurs variations appartenant à une même option. Il faut vérifier la frontière de cette option : deux tarifs portant le même libellé commercial ne sont pas nécessairement regroupés s’ils proviennent de configurations différentes.
Pour chaque panier mixte, conservez :
- les options candidates et leur propriétaire ;
- les conditions de produit et de localisation qui correspondent ;
- le prix final affiché, la devise et les éventuelles taxes ;
- le nombre de colis annoncé ;
- le coût réellement supporté après préparation ;
- la règle commerciale décidée par le marchand.
Une baisse des frais affichés peut améliorer la continuité du parcours, mais elle peut aussi transférer un coût vers la marge. Le guide sur la performance et la conversion e-commerce reste propriétaire de l’optimisation globale du parcours. Ici, la décision porte d’abord sur l’exactitude de la configuration et la capacité à l’exploiter.
Relier le checkout aux applications, à l’OMS et à l’ERP
La compatibilité déclarée par une application ne remplace pas la recette de la boutique. Elle prouve au mieux que l’éditeur a traité un périmètre annoncé. Vos collections, marchés, localisations, règles tarifaires et systèmes aval restent propres à votre activité.
Vérifiez trois frontières :
La lecture de la configuration
Une application de catalogue ou de canal de vente peut avoir besoin d’estimations contextualisées par pays et région. Shopify recommande, selon le type d’application, les flux produits contextualisés ou la lecture du champ de livraison de Markets. Pendant la transition, certaines intégrations doivent encore distinguer les boutiques migrées du modèle historique.
L’écriture des tarifs
Une application qui modifiait les profils du marchand doit choisir une nouvelle trajectoire. Shopify présente le profil possédé par l’application comme l’option recommandée lorsque ce modèle représente correctement ses tarifs ; l’écriture via Markets reste une autre voie lorsque ce n’est pas le cas. Le choix modifie les droits, la propriété de la règle et le coût de maintenance.
Les effets opérationnels
Les ordres de traitement, routages, réservations, étiquettes, statuts et notifications doivent rester reliés au résultat du checkout. Une intégration qui raisonne seulement au niveau de la commande peut manquer une fraction, une localisation ou une méthode de remise. Le protocole de migration de Content API vers Merchant API illustre la même discipline : cartographier les dépendances, vérifier les écritures et conserver un repli au lieu de changer un connecteur à l’aveugle.
Déployer par quatre portes plutôt qu’en une fois
Une migration réussie réduit le nombre de variables modifiées simultanément.
| Porte | Périmètre | Preuve attendue | Autorisation suivante |
|---|---|---|---|
| 1 — inventaire | configuration, dépendances et paniers réels | propriétaire et résultat attendu pour chaque scénario | construire la boutique de test |
| 2 — préversion | marchés et intégrations sur données contrôlées | scénarios nominaux, limites et pannes expliqués | préparer l’opt-in |
| 3 — exposition limitée | marché ou période bornée, surveillance renforcée | prix, marge, traitement et support restent dans les seuils | élargir progressivement |
| 4 — exploitation | marchés éligibles et procédures documentées | alertes, reprise, responsables et contrôle daté | retirer le double chemin devenu inutile |
Avant chaque porte, décidez qui peut arrêter la migration. Une date de plateforme ne justifie pas de contourner une erreur de prix ou de traitement ; elle indique seulement quand le modèle historique cessera d’être une solution durable.
Exemple fictif : deux entrepôts et un retrait magasin
L’exemple suivant est fictif. Une boutique vend en France et en Belgique. Les produits courants partent de deux entrepôts, une collection fragile part d’un seul lieu, et le retrait existe dans un magasin français. Une application calcule le tarif express ; l’OMS reçoit ensuite les ordres de traitement.
La recette commence par douze paniers : produit courant, fragile et mixte dans chaque marché, avec stock présent ou partiel, seuil de gratuité, express, retrait et panne simulée de l’application. Pour chaque cas, l’équipe conserve l’option affichée, le prix, le lieu pressenti, le nombre de colis, l’ordre reçu par l’OMS et la décision attendue.
La nouvelle configuration affiche le bon tarif sur onze scénarios. Sur le panier mixte belge, le prix semble correct mais l’OMS regroupe les deux lignes dans un ordre destiné à l’entrepôt qui ne traite pas la collection fragile. Le verdict n’est pas « migration réussie à 92 % ». L’effet opérationnel bloque l’ouverture de ce marché.
La correction cible alors la frontière entre routage et ordre de traitement. Le scénario est rejoué avec un panier réservé que l’équipe n’a pas utilisé pendant le réglage. La migration ne passe à l’exposition limitée qu’après vérification du deuxième ordre et de la reprise en cas de panne.
Les limites à rendre visibles dans la décision
Le calendrier, l’éligibilité des boutiques et le comportement des préversions peuvent évoluer. Vérifiez les documents Shopify au moment de l’activation. Distinguez aussi trois changements voisins : la livraison pilotée par Markets, l’expédition et le retrait dans une même commande, puis l’affichage par défaut des expéditions fractionnées pour les checkouts éligibles. Ils partagent des flux, mais pas toujours les mêmes plans, dates ou conditions.
La présentation Shopify destinée aux marchands, publiée le 24 août 2026, décrit ces trois évolutions et recommande de tester les applications qui touchent la livraison, le traitement ou la commande. Le billet destiné aux partenaires, publié le 7 juillet 2026, précise les jalons techniques et les systèmes concernés.
Ne déduisez pas d’une préversion que la configuration observée restera identique jusqu’en juillet 2027. Ne promettez ni baisse des frais, ni hausse de conversion, ni disparition du support. Mesurez plutôt les écarts capables de changer une décision : options absentes, tarif inattendu, marge dégradée, fraction incorrecte, échec de traitement ou reprise manuelle.
Décider avant l’opt-in
La livraison Shopify par Markets mérite une migration lorsque la boutique sait relier chaque marché aux options, produits, localisations, applications et effets qu’elle doit protéger. L’activation n’est pas la preuve ; elle commence la preuve.
Une petite boutique sans intégration particulière peut se limiter à quelques paniers et à une vérification attentive de la configuration migrée. Une activité multirégionale avec OMS, ERP, 3PL, retrait et tarifs calculés a besoin d’un jeu de recette versionné, de traces et de responsables nommés.
Le guide de décision Shopify ou PrestaShop reste propriétaire du choix de plateforme et du coût du changement. Le service e-commerce d’Anakyos peut cadrer la recette, adapter une intégration et sécuriser le déploiement sans transformer chaque nouveauté Shopify en projet obligatoire. La prochaine étape utile tient parfois dans un inventaire et douze paniers bien choisis.
Sources principales
- Shopify Developer Changelog — Market-driven shipping now available in feature preview, publié le 1er juillet 2026 ; changement d’architecture, périmètre des applications et calendrier annoncé.
- Shopify Dev — Feature preview for market-driven shipping, consulté le 10 octobre 2026 ; hiérarchie Markets, conditions, consolidation des tarifs et expérience marchande.
- Shopify Dev — Upgrade your app for market-driven shipping, consulté le 10 octobre 2026 ; applications concernées, chemins de lecture et d’écriture, test et compatibilité.
- Shopify Partner Team — The next generation of Shopify fulfillment is coming, publié le 7 juillet 2026 ; livraison et retrait, expéditions fractionnées, systèmes concernés et jalons.
- Shopify Enterprise — Shopify’s fulfillment: more ways to sell, publié le 24 août 2026 ; présentation marchande, déploiement annoncé et contrôles recommandés.
