Tokens hors ligne Shopify : préparer la migration de tes apps avant 2027

Les dates à retenir et la divergence documentaire à connaître

Ces dates viennent des deux annonces du 27 octobre. Shopify précise que les étapes de janvier et d’avril ne doivent pas être interprétées comme un délai supplémentaire pour migrer : l’échéance de migration reste le 1er janvier. Les nouvelles apps publiques créées à partir du 1er avril 2026 sont déjà soumises à l’exigence de tokens expirants. Périmètre de la règle d’avril 2026.

Une réserve mérite d’être gardée dans ton dossier : le guide de migration consulté le 28 octobre décrit encore un refus des requêtes dès le 1er janvier. Il n’est donc pas complètement aligné sur le calendrier d’application des annonces datées du 27. Pour le tableau ci-dessus, je retiens ces annonces récentes et explicites. Fais confirmer le calendrier au moment de ton intervention si cette divergence persiste ; elle ne justifie pas d’attendre avril pour commencer.

Le guide technique précise le contrôle sur les requêtes GraphQL Admin API. C’est ce parcours que nous examinons ici. Ne transpose pas ses paramètres aux API Storefront, au Catalog ou aux pixels de ton thème : leurs modes d’accès ne sont pas interchangeables.

Ton app est-elle réellement concernée ?

Un token, ou jeton d’accès, permet à une app d’appeler une API avec les permissions accordées. Le mot offline signifie ici que le traitement peut continuer sans session active d’un collaborateur. Il ne désigne pas le mode hors connexion Internet d’un terminal Shopify POS. Types de tokens et usages.

Le nom commercial d’une app et sa présence dans ta liste d’applications ne donnent pas son mode d’authentification. Demande une confirmation documentée. Tu n’as pas besoin de récupérer ses secrets pour comprendre si ton flux est concerné.

Pour un marchand, la fiche utile tient en quelques informations : app, éditeur, opérations dépendantes, périmètre confirmé, livraison annoncée et action éventuellement demandée à ton équipe. Une réponse « tout est sécurisé » ne remplace pas l’état de migration des installations existantes.

Si un incident est déjà actif, pars d’une opération datée et rapproche Shopify, le serveur de l’app et l’outil destinataire. Le guide de diagnostic des apps Shopify couvre cette enquête. Ce nouvel article porte la préparation de l’accès et de sa migration, pas l’ensemble des causes d’une synchronisation interrompue.

Acquisition, stockage et renouvellement : les trois points à vérifier

Le guide officiel distingue les apps construites avec les modèles Shopify et celles qui implémentent elles-mêmes les échanges d’authentification. Pour les modèles @shopify/shopify-app-remix et @shopify/shopify-app-react-router, il documente le réglage expiringOfflineAccessTokens dans la configuration de l’app. Pour les échanges directs, il indique le paramètre expiring=1 dans le parcours approprié. Choisir le parcours de migration.

Vérifie d’abord la bibliothèque, sa version, la configuration et le déploiement réellement utilisés. Un réglage trouvé dans un exemple ne démontre pas que ton serveur utilise ce modèle ni que tes anciennes installations ont acquis un nouveau token. Le guide indique que les modèles prennent en charge le stockage et le renouvellement ; ta recette doit néanmoins couvrir les tâches réelles de l’app.

Pour une implémentation directe, l’équipe doit conserver côté serveur la paire access_token et refresh_token, ainsi que les valeurs expires_in et refresh_token_expires_in. La première sert aux appels ; la seconde permet le renouvellement dans le parcours prévu. Garde ensemble les informations de boutique, de version de la paire et d’expiration qui permettent à tes processus de retrouver l’état courant. Réponse et renouvellement documentés.

Chaque renouvellement renvoie une nouvelle paire. La documentation prévoit une durée de 90 jours pour le refresh token et détaille les conditions qui mettent fin à l’usage de son prédécesseur. Ne construis pas ta reprise sur l’idée qu’un ancien refresh token fonctionnera toujours. Utilise la nouvelle valeur reçue, lis les durées retournées et conserve les secrets hors du navigateur et des journaux partagés. Rotation et conditions d’invalidation.

Le point qui mérite une attention particulière est la concurrence : deux workers ne doivent pas renouveler simultanément l’accès de la même boutique. La documentation avertit aussi qu’une acquisition de token et un renouvellement parallèles peuvent invalider leurs résultats respectifs. Je recommande une coordination par couple app-boutique et un enregistrement cohérent de la paire. Le choix du verrouillage et du stockage dépend de ton architecture ; il ne suffit pas de mettre un cache dans un seul processus si plusieurs serveurs travaillent sur le même accès.

Préparer la migration des installations en six étapes

1. Faire l’inventaire sans extraire les secrets. Relève le type d’app, le parcours d’authentification, les installations à migrer et les traitements qui tournent en l’absence de session. Inclue les installations peu actives : elles peuvent n’ouvrir leur interface qu’après le déploiement. Donne un propriétaire au chantier et une preuve attendue pour chaque flux.
2. Corriger l’acquisition des nouveaux accès. Choisis la branche du guide correspondant au code réel : modèle Shopify, token exchange direct ou échange du code d’autorisation. Vérifie ensuite qu’une installation de test obtient et conserve les informations attendues. Une réponse réussie à une requête ne prouve pas encore que le prochain renouvellement utilisera la bonne paire.
3. Vérifier le renouvellement et sa persistance. Sur une cible autorisée, vérifie le traitement sans session marchande, la concurrence entre workers et le redémarrage du serveur après stockage. N’utilise pas un simple changement d’horloge en production pour provoquer une expiration. Prépare les conditions du test dans un environnement adapté avec le développeur responsable.
4. Choisir comment migrer les installations existantes. Le guide prévoit l’acquisition lors d’une interaction utilisateur et un échange direct pour ne pas attendre que chaque marchand ouvre l’app. Ce second parcours utilise l’ancien token valide et les credentials de l’app ; il couvre notamment les consommateurs de webhooks, les backends d’app proxy et les actions Flow. Ne l’applique pas à un token en ligne ou déjà expirant. Migration sans session utilisateur.
5. Basculer progressivement et conserver une procédure de reprise. La migration directe invalide définitivement l’ancien token pour les requêtes GraphQL Admin API. Une sauvegarde contenant cette ancienne valeur n’est donc pas un retour arrière fonctionnel. Avant la bascule, valide la réception et le stockage de la réponse, la continuité des tâches et le chemin d’acquisition à reprendre si l’échange ne peut pas être récupéré.
6. Clôturer sur les opérations reçues. Pour chaque installation retenue, rapproche acquisition, état stocké, renouvellement et résultat métier. Le critère est par exemple une synchronisation attendue effectivement reçue dans la cible autorisée, pas seulement l’absence d’erreur HTTP. Documente les exceptions restantes et leur propriétaire avant de généraliser.

Cette procédure est proposée pour cadrer une intervention. Aucun token de boutique, échange OAuth, redémarrage d’app cliente ou traitement marchand n’a été exécuté pour rédiger ce guide.

La grille de recette : vérifier les reprises, pas seulement le premier appel

La récupération d’une réponse de migration directe perdue possède des conditions propres : le guide documente une répétition de la demande initiale dans les sept jours, avec l’ancien token et les credentials valides, tant que la paire émise n’a pas été renouvelée ou remplacée par une acquisition ultérieure. Cette fenêtre ne doit pas devenir une règle générique pour tous les renouvellements. Récupération de la réponse de migration.

Pour le renouvellement courant, la documentation distingue les échecs transitoires des refus définitifs. Un timeout ou une erreur transitoire se traite selon la politique de reprise du parcours. Un HTTP 401 avec invalid_request et un refresh token qui ne peut plus être utilisé doit arrêter la boucle : plusieurs causes terminales renvoient le même message. N’invente pas leur cause précise à partir du seul code de réponse. Erreurs et reprises du renouvellement.

Même prudence pour un HTTP 403 : un manque de permission peut également produire ce statut. Examine le message et le parcours documenté avant de déclencher une réauthentification. Il faut distinguer un accès expiré d’un accès qui n’a jamais été autorisé pour cette opération.

Le nouvel accès par client assertion est-il une solution de secours ?

Shopify documente aussi un accès serveur au moyen d’une client assertion, signée avec une clé privée dont la clé publique est enregistrée pour l’app. Une app à distribution publique peut obtenir ainsi un accès à une boutique qui l’a déjà installée, sans session marchande ni refresh token. Accès application-only et conditions.

Ce parcours peut être étudié pour des traitements de fond et certaines reprises. Ce n’est pas une raison de considérer une app migrée sans examen. Il faut recevoir la gestion des clés, la signature, la durée de vie retournée, les permissions de l’installation et les limites du type d’app. Les autres apps restent soumises aux règles d’accès aux boutiques de leur organisation décrites dans ce guide.

Ne confonds pas cette client assertion avec le token envoyé à l’Admin API, un ID token utilisateur ou l’ajout arbitraire d’un secret dans un appel existant. Pour une équipe qui utilise déjà un modèle Shopify correctement configuré, ajouter un second système d’authentification peut augmenter le travail de maintenance. Choisis le parcours qui répond au besoin réel et fais-le vérifier dans son ensemble.

Ce que tu peux demander cette semaine à ton éditeur ou à ton développeur

Pour une app tierce, demande une réponse sur son statut, la migration des installations existantes, la date de livraison prévue avant le 1er janvier et l’éventuelle action marchande. Tu peux partager le nom du flux dépendant et ses références de diagnostic, sans joindre de token ou de données clients inutiles. Une désinstallation préventive ou une réinstallation générale n’est pas un plan de migration à elle seule.

Pour une app que ton équipe maintient, commence par un livrable vérifiable : inventaire des parcours, branche technique choisie, traitement du stockage et de la concurrence, scénarios reçus sur cible autorisée et liste des installations restant à traiter. Les journaux doivent permettre de comprendre les erreurs sans exposer les credentials.

Le guide Shopify Next Gen Events traite une autre migration : changer le système de livraison des événements ne règle pas automatiquement l’authentification des appels effectués après réception. De même, le guide Shopify CLI aide à organiser les versions et déploiements, sans remplacer la recette d’accès du backend.

Si tu ne sais pas quelles intégrations font dépendre tes commandes ou tes stocks de ces accès, un audit Shopify ciblé permet de cadrer l’inventaire et les points à examiner. Pour préciser le périmètre et les interlocuteurs, parlons de ton intégration. L’intervention doit partir du type réel d’app et de ses flux, sans promettre une migration universelle en un réglage.

Sources vérifiées le 28 octobre 2026. Analyse des deux annonces datées du 27 octobre, de l’exigence applicable aux nouvelles apps publiques et des documentations d’accès, de migration, de renouvellement et de client assertion. La divergence de calendrier encore visible dans le guide technique est explicitée. Les étapes et matrices sont des propositions éditoriales originales, pas un compte rendu d’essai marchand. Aucune relecture personnelle de Teo, conformité globale de sécurité, indexation ou citation IA n’est présumée.