Sur cette page
Cette échéance compte parce que l’authentification est le point d’entrée de chaque retour ou échange en libre-service. Une migration inachevée n’empêchera pas nécessairement l’application de fonctionner, mais elle peut mettre en péril son statut Built for Shopify et l’expérience des acheteurs pendant la période de pointe des retours.
Ce guide explique la règle, indique quelles applications sont concernées, distingue les retours de la modification de commande avant traitement et propose aux agences un audit en 7 étapes à terminer avant le 1er décembre.
Ce que change l’exigence Built for Shopify relative à l’API Customer Account
À compter du 1er décembre 2026, les applications de retour et d’échange proposant un libre-service aux acheteurs devront utiliser l’API Customer Account comme principale méthode d’authentification des clients pour conserver leur statut Built for Shopify. Shopify a annoncé ce changement le 17 juin 2026, laissant aux développeurs concernés environ cinq mois et demi pour migrer.
Le journal officiel des modifications destiné aux développeurs Shopify mentionne également les applications d’abonnement. Pour les équipes chargées des retours, le critère essentiel est le libre-service destiné aux acheteurs : un client peut lancer ou gérer un retour, suivre un échange ou effectuer une action similaire sans intervention du personnel.
La conséquence est plus limitée que ne le laissent entendre certains résumés de cette échéance. Shopify indique que les applications non conformes risquent de perdre leur statut Built for Shopify. L’entreprise ne dit pas que toutes les applications concernées cesseront de fonctionner, disparaîtront du Shopify App Store ou désactiveront les processus des marchands à minuit.
| Question à vérifier | Jusqu’au 30 novembre 2026 | À partir du 1er décembre 2026 |
|---|---|---|
| Principale méthode d’authentification requise pour l’acheteur | La méthode existante peut être conservée | API Customer Account |
| Catégories concernées | Retours, échanges, abonnements | Mêmes catégories |
| Libre-service destiné aux acheteurs requis | Oui, pour que la règle s’applique | Oui, pour que la règle s’applique |
| Conséquence immédiate annoncée | La période de migration reste ouverte | Statut Built for Shopify menacé |
| Action du marchand | Demander des preuves au fournisseur | Vérifier le fonctionnement en production |
Considérez le 1er décembre comme une échéance de suivi des fournisseurs, et non comme une fermeture automatique de la boutique en ligne. Les agences doivent néanmoins s’en occuper dès maintenant : un changement de statut ou une mise en production précipitée de l’authentification peut créer des risques évitables pendant les retours de fin d’année.
Quelles applications sont concernées par l’exigence Built for Shopify ?
Une application est concernée si trois conditions sont réunies : elle appartient à la catégorie des retours, des échanges ou des abonnements ; elle propose un libre-service aux acheteurs ; et elle souhaite conserver son statut Built for Shopify après le 1er décembre 2026. L’ensemble des applications d’un marchand n’entre pas automatiquement dans le champ de cette règle.
Utilisez cette liste de vérification pour chaque application intervenant après l’achat :
- Vérifiez la catégorie de l’application. Confirmez la classification retenue par Shopify et le fournisseur, sans déduire la catégorie du nom d’une fonctionnalité.
- Repérez les parcours destinés aux acheteurs. Incluez la demande de retour, le suivi des échanges, les modifications d’abonnement et tout portail client permettant ces actions.
- Identifiez la méthode d’authentification actuelle. Demandez si l’API Customer Account de Shopify est déjà la méthode principale en production.
- Confirmez l’objectif du fournisseur concernant Built for Shopify. Une application sans le badge ne peut pas le perdre, même si la compatibilité avec les comptes clients peut rester importante sur le plan opérationnel.
- Distinguez les actions avant traitement des commandes de celles après livraison. Modifier une commande non traitée relève de la modification de commande. Renvoyer un produit livré relève du retour. Des termes semblables employés par les clients ne rendent pas ces processus identiques.
Cette dernière distinction évite l’erreur d’audit la plus fréquente. Un acheteur peut qualifier une correction de taille d’« échange », mais le remplacement d’une variante avant le traitement de la commande évite entièrement la logistique des retours. Un échange après livraison nécessite un processus de retour, des règles de réception ou d’inspection et l’expédition d’un article de remplacement.
Nos données montrent que, sur plus de 10 millions de commandes Shopify, environ 1 sur 19 (5,2 %) est modifiée après le paiement (Revize, 2026). Les agences doivent donc auditer les deux volets, tout en réservant l’exigence de décembre aux catégories effectivement citées par Shopify.
À quoi sert concrètement l’API Customer Account ?
L’API Customer Account authentifie l’acheteur et donne à une application un accès contrôlé aux données de son compte client Shopify. Une API, ou interface de programmation d’application, est un point d’accès encadré entre systèmes : l’application soumet une requête autorisée, et Shopify ne renvoie que les données auxquelles cette requête permet d’accéder.
Elle diffère de l’API Admin, avec laquelle une application agit généralement pour le compte du marchand. La documentation de référence de l’API Customer Account de Shopify précise que cette API destinée aux clients permet de lire et de mettre à jour leurs propres informations, notamment leurs commandes, profils et adresses.
Au 29 août 2026, la documentation de Shopify présente 2026-07 comme la version la plus récente. Elle décrit aussi des points de terminaison de découverte, qui permettent à une application d’obtenir les bons points de terminaison d’authentification et GraphQL pour chaque boutique au lieu de coder un domaine en dur.
L’authentification et l’emplacement de l’interface sont deux choses distinctes. Une extension d’interface des comptes clients détermine où une expérience apparaît dans les comptes clients. L’API Customer Account régit l’accès authentifié aux données du client. Une application peut disposer d’un composant soigné sur une page de compte, tout en devant faire confirmer par son fournisseur que l’API requise est sa principale méthode d’authentification.
Les agences doivent demander une réponse écrite à quatre questions techniques :
- Le parcours de l’acheteur en production utilise-t-il l’API Customer Account pour l’authentification ?
- Quels points d’entrée l’utilisent, notamment les pages de compte, les e-mails de commande, les liens directs et les portails externes ?
- La migration est-elle active pour tous les marchands ou seulement pour un groupe de test ?
- Quelles preuves figureront dans le Partner Dashboard du fournisseur après l’évaluation de la migration ?
Attention : N’acceptez pas la mention « compatible avec les nouveaux comptes clients » comme preuve suffisante. La prise en charge de l’interface et la conformité à l’exigence d’authentification sont liées, mais ne sont pas équivalentes.
La place de Revize dans l’audit de décembre
Revize prend en charge le libre-service client avant le traitement des commandes, tandis que la règle du 1er décembre vise les applications spécialisées dans les retours et les échanges après livraison. Shopify présente actuellement cette application de modification de commande comme Built for Shopify, compatible avec les comptes clients et classée dans la catégorie de la modification de commande plutôt que dans celle des retours et échanges.
Les clients peuvent utiliser son portail de modification de commande en libre-service pour modifier des adresses, des variantes, des quantités ou des commandes admissibles avant leur traitement. Ce parcours apparaît sur la page de statut de la commande Shopify, et le marchand définit la période pendant laquelle les modifications sont autorisées.
Cette distinction entre catégories est utile. Corriger une commande avant son expédition évite qu’un retour évitable n’entre dans la chaîne logistique des retours. Les retours après livraison restent une activité distincte : une boutique à fort volume peut donc associer une application de modification de commande à une plateforme spécialisée dans les retours, sans demander à l’une de remplir le rôle de l’autre.
| Besoin du client | Étape opérationnelle | Système adapté | Rapport avec la règle de décembre |
|---|---|---|---|
| Corriger l’adresse de livraison | Avant le traitement de la commande | Application de modification de commande | Non visée du seul fait de sa catégorie |
| Changer de taille avant l’expédition | Avant le traitement de la commande | Application de modification de commande | Non visée du seul fait de sa catégorie |
| Annuler une commande admissible | Avant le traitement de la commande | Application de modification de commande | Non visée du seul fait de sa catégorie |
| Renvoyer un article livré | Après le traitement de la commande | Application de retour | Concernée si elle propose un libre-service aux acheteurs |
| Suivre l’expédition d’un article de remplacement | Pendant le processus de retour ou d’échange | Application d’échange | Concernée si elle propose un libre-service aux acheteurs |
Pour les agences qui auditent des boutiques Plus, Advanced et Grow, l’essentiel est de maintenir cette distinction. Gardez les corrections avant traitement dans l’outil de modification de commande, puis demandez séparément au fournisseur de l’application de retour des preuves de conformité. Des marques comme Square Enix, Venchi, Shelly, Nude Project, AYBL et TheGameCollection utilisent ce modèle de libre-service client dans différentes catégories de produits.
Si vos outils dirigent encore les demandes de changement d’adresse ou de variante et les annulations vers le service client, ajoutez le libre-service avant traitement des commandes pendant que le fournisseur de l’application de retour termine sa migration de décembre.
Comment les agences doivent auditer l’exigence relative à l’API Customer Account
Réalisez cet audit en 7 étapes avant le 1er décembre 2026 pour chaque client proposant des retours, des échanges ou des abonnements en libre-service. Le résultat doit prouver le fonctionnement en production à chaque point d’entrée de l’acheteur, et non simplement consigner la promesse de migration d’un fournisseur.
- Recensez les applications concernées. Notez pour chacune sa catégorie Shopify, son statut Built for Shopify, ses fonctions destinées aux clients, son responsable métier, son responsable technique et sa date de renouvellement. Distinguez la modification de commande, le suivi, les retours, les échanges, les abonnements, le service client et les fonctions d’entrepôt.
- Demandez une déclaration datée au fournisseur. Vérifiez si l’application relève des catégories visées par l’annonce de Shopify et si l’API Customer Account est sa principale méthode d’authentification en production. Si ce n’est pas encore le cas, exigez une date cible de mise en production.
- Recensez tous les points d’entrée des clients. Testez la navigation dans les comptes, les pages de statut de la commande, les e-mails de confirmation, les liens de retour, le suivi des échanges, les destinations des codes QR, les navigateurs mobiles et les liens des boutiques headless. L’authentification peut sembler aboutie depuis le menu principal du compte alors qu’un ancien lien direct ouvre encore un portail distinct.
- Examinez la transition d’identité. Vérifiez ce qui se passe lorsque l’acheteur est déjà connecté, déconnecté ou revient par un ancien favori. Consignez les redirections, les demandes répétées de connexion, la perte du contexte de la commande et tout parcours qui demande des identifiants distincts pour un portail.
- Testez les parcours complets de retour et d’échange. Utilisez des commandes de test pour vérifier un retour admissible, un article non admissible, un retour partiel, un échange, une annulation et le cas d’un client qui interrompt puis reprend la démarche. Vérifiez l’état final dans Shopify et dans chaque système opérationnel en aval.
- Rassemblez des preuves des deux côtés. Conservez les enregistrements des parcours d’achat, les historiques des commandes Shopify, les notes de version du fournisseur, les confirmations de son assistance et la date de chaque test. Demandez au développeur de l’application de fournir, si elles sont disponibles, les preuves de sa propre évaluation Built for Shopify.
- Préparez un plan de retour en arrière et de remontée des problèmes. Consignez le responsable côté client, le responsable côté agence, le contact fournisseur, la procédure de secours avec le service client et la date à laquelle il faudra décider de remplacer une application incapable de fournir des preuves crédibles. Fixez cette date avant le gel des changements pendant la période de pointe.
N’attendez pas un changement de badge pour effectuer les tests. La défaillance la plus coûteuse est rarement le badge lui-même. C’est le client qui ne parvient pas à retrouver sa commande, à reprendre un échange ou à comprendre pourquoi le parcours habituel de son compte fonctionne désormais autrement.
Que risque-t-il réellement de se passer après le 1er décembre ?
La seule conséquence du 1er décembre explicitement annoncée par Shopify est qu’une application concernée et non conforme risque de perdre son statut Built for Shopify. Toute affirmation plus catégorique, notamment un retrait automatique du Shopify App Store ou une fermeture immédiate des portails de retour, va au-delà de l’annonce publiée.
Les marchands doivent néanmoins évaluer trois risques concrets :
- Risque pour la confiance : L’application peut perdre un indicateur de qualité utilisé par les marchands lors du choix et de l’évaluation de leurs outils.
- Risque lié à la mise en production : Une migration tardive de l’authentification peut entraîner des boucles de connexion, des redirections défaillantes ou une perte du contexte de la commande. Vérifiez ces points sur des commandes de test au lieu de supposer qu’ils se produiront.
- Risque pour le service client : Si un parcours en libre-service devient peu fiable, les clients peuvent se rabattre sur les e-mails ou le chat pendant la période où les retours sont les plus nombreux.
Le badge est le mécanisme d’application cité par Shopify. Le parcours de l’acheteur est ce que le marchand doit tester pour protéger son activité.
Conseil : Consignez l’affirmation du fournisseur et vos résultats de test dans le même dossier d’audit. Une date inscrite sur une feuille de route prouve une intention ; un parcours acheteur mené à terme prouve que la solution est prête.
L’essentiel pour les exploitants de boutiques Plus
À 94 jours de l’échéance, le 29 août, les agences devraient terminer le recensement en septembre, les tests en production en octobre et les décisions correctives avant le gel des changements de novembre. L’échéance du 1er décembre est précise, vérifiable et assez ciblée pour être auditée sans remplacer tous les outils utilisés après l’achat.
Voici les actions à mener cette semaine :
- Recensez chaque application de retour, d’échange et d’abonnement destinée aux acheteurs.
- Demandez à chaque fournisseur si l’authentification par l’API Customer Account est la méthode principale en production.
- Testez chaque point d’entrée de l’acheteur avec des commandes de test.
- Distinguez la modification avant traitement des retours après livraison.
- Consignez les preuves, les responsables, les échéances et une procédure de secours.
L’objectif est de disposer d’une identité client fiable tout au long du parcours après achat, étayée par des preuves que votre agence peut présenter.
Foire aux questions
Ces réponses couvrent les 10 questions que les agences et les exploitants de boutiques Plus doivent résoudre avant le 1er décembre 2026. La règle publiée est concise : il faut donc distinguer l’exigence exacte de Shopify des conclusions opérationnelles qui nécessitent encore des preuves du fournisseur et des commandes de test.
Qu’est-ce qui change le 1er décembre 2026 ?
Les applications de retour, d’échange et d’abonnement concernées doivent utiliser l’API Customer Account comme principale méthode d’authentification des clients pour conserver leur statut Built for Shopify. La règle s’applique lorsqu’une application propose un libre-service aux acheteurs. Shopify a annoncé l’échéance le 17 juin 2026.
Une application de retour cessera-t-elle de fonctionner le 1er décembre ?
Shopify n’a pas indiqué que les applications concernées cesseraient automatiquement de fonctionner le 1er décembre. La conséquence publiée est que les applications qui ne respectent pas l’exigence risquent de perdre leur statut Built for Shopify. Les marchands doivent interroger les fournisseurs sur la continuité du service, puis vérifier le parcours client sur des commandes de test au lieu de prévoir une panne.
L’exigence s’applique-t-elle à toutes les applications Shopify ?
Non, l’exigence annoncée ne s’applique pas à toutes les applications Shopify. Shopify a cité les applications de retour et d’échange ainsi que les applications d’abonnement proposant un libre-service aux acheteurs. Les applications de suivi, de service client, de modification de commande, d’entrepôt et des autres catégories ne doivent pas être considérées comme concernées sans preuve propre à leur catégorie fournie par Shopify ou par le fournisseur.
Le marchand est-il responsable de la migration de l’API ?
Le développeur de l’application réalise la migration de l’API, tandis que le marchand reste responsable des risques liés au fournisseur et à ses opérations. Les agences doivent obtenir l’état de la mise en production auprès du fournisseur, tester les parcours des acheteurs concernés et prévoir une solution de secours. Un marchand ne peut pas corriger l’architecture d’authentification d’une application tierce dans les paramètres de Shopify Admin.
Qu’est-ce que l’API Customer Account ?
L’API Customer Account est l’interface de Shopify qui permet aux acheteurs authentifiés d’accéder aux données de leur compte. Elle permet à une application d’utiliser les informations du client connecté, comme ses commandes, les détails de son profil et ses adresses. Shopify la présente comme la couche d’authentification commune aux comptes clients, aux boutiques en ligne et aux applications connectées.
L’API est-elle identique à une extension d’interface des comptes clients ?
Non, l’authentification et l’emplacement de l’interface sont deux sujets distincts. L’API Customer Account régit l’accès authentifié aux données. Les extensions d’interface des comptes clients affichent des expériences d’application dans les interfaces de compte Shopify. Une application peut avoir besoin des deux et devoir tout de même prouver que l’API est sa principale méthode d’authentification.
Faut-il déplacer tout le portail de retour ?
La règle publiée pour décembre impose précisément l’API Customer Account comme principale méthode d’authentification. Elle ne dit pas que chaque écran doit être recréé dans une seule interface Shopify. Les agences doivent demander aux fournisseurs quels composants de l’interface et du système sous-jacent changent, puis tester le parcours complet, car l’authentification influe sur toutes les étapes suivantes.
Comment tester les commandes passées sans compte client ?
Testez ces commandes avec les liens réels et dans les états d’authentification pris en charge par le fournisseur. Incluez l’accès depuis l’e-mail de confirmation, les navigateurs où le client n’est pas connecté, les sessions expirées et les visites ultérieures depuis un autre appareil. Ne supposez pas qu’un test réussi depuis un compte connecté prouve que tous les parcours sans compte ou préauthentifiés sont prêts.
Un marchand peut-il conserver son application de retour actuelle ?
Oui, à condition que le fournisseur puisse démontrer une voie crédible vers la conformité et que le parcours en production réussisse les tests. L’échéance n’oblige pas en elle-même les marchands à remplacer une application. Le remplacement devient une décision opérationnelle lorsque le fournisseur ne peut pas fournir de preuves, manque les étapes convenues ou échoue aux tests contrôlés du parcours acheteur.
Quelles preuves de conformité une agence doit-elle conserver ?
Conservez la déclaration du fournisseur, la date du test, l’enregistrement du parcours acheteur, les identifiants des commandes concernées, leurs états finaux dans Shopify et le nom du responsable de la remontée des problèmes. Ajoutez des captures d’écran du statut Built for Shopify actuel de l’application et les éléments pertinents du Partner Dashboard lorsque le fournisseur peut les partager. Le dossier doit montrer le fonctionnement observé, et pas seulement les travaux prévus.
Rassemblez les preuves dès maintenant, réservez à chaque système l’étape opérationnelle qui lui revient et abordez le 1er décembre avec un parcours client testé, plutôt qu’avec une simple supposition.