Deux dates, des conséquences différentes
Shopify a publié cette exigence le 5 novembre 2026. Les applications publiques qui utilisent les opérations groupées de l’Admin API doivent configurer et activer une liste d’IP avant le 12 novembre à 23 h 59, heure de l’Est. Passé ce délai, les requêtes et mutations groupées d’une application non configurée sont bloquées. Les autres applications publiques appelant l’Admin API ont jusqu’au 20 novembre à 23 h 59 ET : celles qui n’ont toujours pas de liste seront retirées de l’App Store et ne pourront plus recevoir de nouvelles installations. Shopify indique que les installations existantes fonctionneront jusqu’au 1er avril 2027, date à laquelle les requêtes Admin API concernées échoueront.
Le 20 novembre ne constitue pas un délai supplémentaire pour les opérations groupées : leur blocage intervient dès le 12 novembre. Shopify prévoit aussi un signalement dans les paramètres des marchands à partir du 20 novembre, puis des avertissements aux marchands le 15 janvier 2027. Ce sont des étapes distinctes ; le fonctionnement temporaire d’une installation existante ne prouve donc pas que la migration est terminée.
Applications publiques et applications personnalisées
L’exigence vise les applications publiques, y compris celles distribuées par l’App Store Shopify. Shopify précise que les applications personnalisées et celles créées par les marchands dans le Dev Dashboard ou l’administration ne sont pas concernées par cette obligation particulière. Cela ne les rend pas immunisées contre le risque lié aux identifiants : lorsqu’une plateforme le permet, restreindre les réseaux autorisés peut aussi limiter l’usage d’un jeton divulgué.
Un marchand devrait demander au fournisseur si son application appelle l’Admin API, réalise des opérations groupées et applique déjà la liste. Le marchand ne peut généralement pas fournir à la place du développeur les adresses de sortie de son service. La mise à jour relève du propriétaire de l’application, même si le marchand devra peut-être tester ses propres flux après un changement d’hébergement ou de réseau.
Adresses fixes et réseaux serverless
Une application disposant d’adresses de sortie stables peut enregistrer ces adresses ou leurs plages CIDR dans le Dev Dashboard. Un service serverless peut utiliser des adresses variables, ce qui rend une liste d’IP individuelles fragile. La mise à jour Shopify du 5 novembre ajoute l’option Networks : le développeur peut autoriser les numéros de système autonome (ASN) d’un hébergeur, limiter les pays, tester le choix sur le trafic récent puis activer la règle. Shopify documente un maximum de dix ASN et dix pays ; les requêtes hors réseau autorisé reçoivent une erreur HTTP 403.
Une règle ASN couvre davantage qu’une adresse unique et exige donc de sélectionner avec soin l’hébergeur et les zones géographiques. Elle ne justifie pas d’autoriser tous les fournisseurs ou tous les pays. Avant l’application, vérifier que les régions de production et les tâches en arrière-plan légitimes sont incluses, puis examiner le trafic récent plutôt que de deviner des adresses.
Checklist de migration pour les équipes d’applications
Commencer par inventorier les applications publiques, intégrations Admin API, tâches en arrière-plan et opérations groupées. Consigner la sortie réseau de chaque environnement sans confondre production, développement et prévisualisation. Choisir ensuite des IP/CIDR fixes ou une règle ASN et pays strictement limitée. Tester la règle sur le trafic récent, vérifier les flux habituels et groupés, puis activer l’application effective.
Après le déploiement, surveiller les réponses 403 et erreurs API, aligner la liste sur les changements d’infrastructure et attribuer un responsable des modifications. Tester une procédure de récupération avant l’échéance. Les marchands devraient contacter les fournisseurs d’applications et programmer une vérification des commandes, stocks et fonctions critiques après la migration.
Sources et références
Une erreur factuelle à signaler ou une source à suggérer ? Contacter la rédaction.
