Récupérer une clé API Shopify prend cinq minutes. Le faire correctement — sans ouvrir une porte que vous ne pourrez plus fermer — demande de comprendre trois notions. Elles sont simples, et les ignorer est la cause de la plupart des incidents que je rencontre en reprise d'existant.
D'abord : de quelle clé avez-vous besoin ?
Shopify distingue plusieurs cas, et les gens choisissent souvent le mauvais.
Application personnalisée (custom app) — c'est ce qu'il vous faut dans 90 % des cas. Une intégration pour votre boutique uniquement : connecter un CRM, alimenter un outil interne, brancher n8n ou Zapier.
Application publique — pour distribuer une application à d'autres marchands via l'App Store. Si vous n'êtes pas éditeur de logiciel, ce n'est pas votre cas.
Storefront API — pour un site vitrine découplé qui lit le catalogue. Portée en lecture, publiable côté navigateur.
La procédure : deux chemins depuis 2026
Lequel vous concerne dépend d'une seule question : l'application existe-t-elle déjà ?
Elle existe déjà
Elle a été créée dans l'admin avant 2026. Elle continue de fonctionner, son jeton reste valable, et vous n'avez rien à faire. Vous la retrouvez dans Paramètres → Applications et canaux de vente → Développer des applications.
Vous en créez une
Le chemin par l'admin est fermé. Il faut passer par le Dev Dashboard, définir les portées, publier une version, puis installer l'application sur la boutique.
Le chemin historique, pour une application déjà en place
1. Dans l'admin Shopify : Paramètres → Applications et canaux de vente → Développer des applications.
2. Ouvrez l'application concernée. Vous y retrouvez ses portées et ses identifiants.
3. Le jeton d'accès Admin API n'est affiché qu'une fois, à l'installation. Si vous l'avez perdu, la seule façon d'en obtenir un autre est destructive — voir plus bas.
Le chemin actuel, pour une nouvelle intégration
1. Dans le Dev Dashboard, Create app en haut à droite, puis Start from Dev Dashboard. Nommez l'application explicitement : Intégration HubSpot vous dira quelque chose dans un an ; Test ne vous dira rien, et vous n'oserez plus la supprimer.
2. Définissez les portées d'accès (scopes). C'est l'étape qui compte, j'y reviens.
3. Créez une version et publiez-la. C'est ce qui rend l'application installable.
4. Depuis Home, descendez jusqu'à Install app, choisissez la boutique, installez.
5. Pour une application destinée à votre propre boutique, le plus simple est le client credentials grant : dans Settings, relevez le Client ID et le Client secret. Le jeton ne s'affiche plus nulle part — votre code le demande quand il en a besoin.
Le jeton qui expire : ce que ça change vraiment
C'est le point que je vois le plus mal anticipé, parce qu'il ne ressemble pas à une nouveauté technique mais à un détail d'implémentation. Il n'en est pas un.
Avec le client credentials grant, on obtient le jeton par une requête POST sur https://votre-boutique.myshopify.com/admin/oauth/access_token, avec trois paramètres : grant_type=client_credentials, votre client_id et votre client_secret. La réponse contient le jeton et un champ expires_in qui vaut toujours 86 399 secondes, soit 24 heures.
Une limite à connaître : le client credentials grant ne marche que si l'application et la boutique appartiennent à la même organisation Shopify. Sinon, Shopify répond shop_not_permitted, et le message ne dit pas pourquoi.
Les portées : le seul vrai enjeu
Shopify vous demande de cocher ce que l'application peut lire et écrire. La tentation est de tout cocher pour ne pas y revenir. C'est exactement ce qu'il ne faut pas faire.
Une clé avec toutes les permissions qui fuite — dans un dépôt Git, une capture d'écran, un ticket de support — donne accès à l'intégralité de votre boutique : données clients, commandes, remboursements. Une clé limitée à read_products ne donne accès qu'au catalogue.
Les portées les plus courantes : read_products et write_products pour le catalogue, read_orders et write_orders pour les commandes, read_customers pour les fiches clients — celle-là mérite une réflexion particulière, elle donne accès à des données personnelles.
Où stocker le jeton
C'est là que ça dérape le plus souvent.
Jamais dans le code. Un jeton committé reste dans l'historique Git même après suppression du fichier. Il faut réécrire l'historique et révoquer la clé.
Jamais dans une variable d'environnement publique. Tout ce qui est préfixé PUBLIC_, NEXT_PUBLIC_ ou VITE_ finit dans le navigateur de vos visiteurs.
Dans le gestionnaire de secrets de votre plateforme. Variables d'environnement chiffrées, coffre-fort de votre hébergeur, ou stockage de secrets de votre outil d'automatisation. n8n et Zapier ont tous deux un espace prévu pour ça.
Avec le client credentials grant, ce que vous stockez n'est plus le jeton mais le client_secret. La règle ne change pas ; ce qui change, c'est que le secret stocké ne se périme jamais de lui-même, donc sa fuite est plus grave, pas moins.
Si une clé a fuité
Ne cherchez pas à évaluer le risque, révoquez d'abord.
1. Supprimez l'application dans l'admin Shopify. Le jeton est immédiatement invalide, et c'est irréversible dans le bon sens.
2. Recréez-en une avec les mêmes portées et mettez à jour vos intégrations.
3. Vérifiez ensuite les journaux d'activité de la boutique pour repérer d'éventuels accès anormaux.
Une intégration cassée pendant dix minutes est un désagrément. Une clé compromise laissée active est un incident de sécurité, avec des données clients à la clé — et donc une obligation de notification si elles ont été exposées.
Pourquoi il n'existe pas de rotation propre
C'est une question qui revient, et la réponse est frustrante : on ne peut pas faire tourner les identifiants d'une application personnalisée créée dans l'admin. La documentation de Shopify est explicite — il faut supprimer l'application et en créer une nouvelle, ou la désinstaller puis la réinstaller. Dans les deux cas, un nouveau jeton est émis et l'ancien meurt.
Et Shopify le dit sans détour : les requêtes et les webhooks de l'application sont interrompus tant que le code n'a pas été mis à jour avec les nouveaux identifiants.
Concrètement, une rotation se planifie comme une petite mise en production : on prévient qui doit l'être, on prépare l'endroit où le nouveau jeton sera collé, et on fait la bascule à un moment où une interruption de quelques minutes n'a pas de conséquence. Ce n'est pas une opération à faire un vendredi à 18 h en découvrant la fuite.
Le client credentials grant règle ce problème par construction : il n'y a plus de jeton à faire tourner, seulement un secret client à remplacer si besoin.
Le piège des versions d'API
Un jeton valide ne suffit pas à ce qu'une intégration continue de fonctionner. Shopify publie une nouvelle version d'API tous les trois mois, au début du trimestre, sous la forme d'une date : 2026-04, 2026-07. Chaque version stable est supportée au minimum douze mois, avec au moins neuf mois de recouvrement entre deux versions consécutives.
La conséquence pratique : notez la version d'API que chaque intégration utilise, en même temps que ses portées. Douze mois passent vite, et le changelog Shopify est le seul endroit où l'échéance est annoncée.
Le point qu'on oublie toujours
Documentez quelle clé sert à quoi. Un tableau suffit : nom de l'application, portées accordées, version d'API visée, intégration qui l'utilise, date de création.
Sans ça, dans dix-huit mois, vous aurez six applications personnalisées dans votre admin, aucune idée de ce que chacune fait, et personne n'osera en supprimer une. C'est l'état dans lequel je trouve la plupart des boutiques que je reprends — et le nettoyage coûte alors bien plus cher que la documentation qu'on n'a pas faite.
Questions sur cette page
Peut-on encore créer une application personnalisée depuis l'admin Shopify ?
Non. Depuis le 1ᵉʳ janvier 2026, Shopify ne permet plus de créer de nouvelle application personnalisée depuis l'admin de la boutique. Les applications créées avant cette date ne sont pas affectées et continuent de fonctionner normalement. Pour une nouvelle intégration, il faut passer par le Dev Dashboard : y créer l'application, définir ses portées, publier une version, puis l'installer sur la boutique.
Combien de temps un jeton d'accès Shopify reste-t-il valable ?
Cela dépend du chemin par lequel il a été obtenu. Le jeton d'une application personnalisée créée dans l'admin avant 2026 est permanent : il reste valable tant que l'application est installée. Le jeton obtenu par le client credentials grant, lui, expire au bout de 24 heures — le champ expires_in de la réponse vaut toujours 86 399 secondes. Votre code doit donc en redemander un avant l'expiration.
Comment utiliser un jeton qui expire dans n8n, Zapier ou Make ?
Il faut un appel préalable qui va chercher un jeton frais avant les autres. Concrètement : une requête POST sur https://votre-boutique.myshopify.com/admin/oauth/access_token avec grant_type=client_credentials, votre client_id et votre client_secret, dont on réutilise le jeton pour les appels suivants du même scénario. C'est faisable dans les trois outils, mais ça se conçoit à l'avance — ce n'est pas un champ de connexion qu'on remplit une fois pour toutes.
Comment faire tourner une clé API Shopify sans couper la boutique ?
Pour une application personnalisée créée dans l'admin, ce n'est pas possible proprement : la documentation de Shopify indique qu'on ne peut pas faire tourner les identifiants, et qu'il faut supprimer l'application puis en créer une nouvelle, ou la désinstaller et la réinstaller. Les requêtes et les webhooks sont interrompus tant que le code n'a pas reçu les nouveaux identifiants. Une rotation se planifie donc comme une petite mise en production. Le client credentials grant supprime le problème : il n'y a plus de jeton à faire tourner.
Quelles portées faut-il cocher ?
Le minimum qui fait fonctionner l'intégration, puis on ajoute au besoin. Les plus courantes sont read_products et write_products pour le catalogue, read_orders et write_orders pour les commandes, read_customers pour les fiches clients. Cette dernière mérite une réflexion particulière : elle donne accès à des données personnelles, avec les obligations qui vont avec. Ajouter une portée après coup prend trente secondes ; en retirer une à une clé déjà déployée suppose de savoir partout où elle est utilisée.
Que faire si le jeton d'accès a été perdu ?
Il n'est affiché qu'une seule fois, à l'installation, et Shopify ne permet pas de le réafficher. Pour une application de l'admin, la seule issue est de désinstaller puis réinstaller l'application, ou de la supprimer et d'en créer une nouvelle — ce qui invalide l'ancien jeton et interrompt l'intégration le temps de la mise à jour. C'est aussi la raison pour laquelle il faut le copier immédiatement dans son gestionnaire de secrets, et pas dans un fichier temporaire.
Pourquoi Shopify répond-il « shop_not_permitted » ?
Parce que le client credentials grant ne fonctionne que si l'application et la boutique appartiennent à la même organisation Shopify. Si vous tentez de l'utiliser sur une boutique extérieure à votre organisation, Shopify refuse avec ce message, qui n'explique pas la cause. Dans ce cas, il faut passer par le parcours OAuth classique.
Mon intégration Shopify peut-elle casser sans que rien ne l'annonce ?
Oui, et c'est le piège des versions d'API. Shopify publie une nouvelle version tous les trois mois et supporte chacune au minimum douze mois. Passé ce délai, une requête qui vise une version retirée ne renvoie pas d'erreur : elle est servie avec la plus ancienne version stable disponible. L'intégration continue donc de répondre, mais avec des champs qui ont pu changer de forme ou disparaître. La panne se manifeste par des données subtilement fausses, pas par une alerte — d'où l'intérêt de noter la version visée par chaque intégration.
Faut-il une application publique pour un usage interne ?
Non, et c'est un raccourci coûteux. Une application publique sert à distribuer un logiciel à d'autres marchands via l'App Store : elle impose un processus de validation, des contraintes de conformité et une architecture OAuth complète. Pour une intégration destinée à votre seule boutique, l'application personnalisée est le bon objet.