---
title: "Revue de sécurité Shopify B2B : une check-list en 40 points pour les boutiques et les applications de devis"
description: "Revue de sécurité Shopify B2B neutre : accès du personnel et des collaborateurs, rôles acheteurs, intégrité des prix, jetons d'app et webhooks, dates 2026."
url: "https://www.quotway.com/fr/blog/shopify-b2b-security-review-checklist"
type: "blog post"
category: "For Shopify agencies"
published: "2026-09-25"
verified: "2026-09-25"
shopify_api_version: "2026-07"
audience: "Agences Shopify, développeurs et marchands qui passent en revue une boutique B2B et les applications qui y sont installées"
scope: "La revue de sécurité propre à la boutique en API 2026-07 : réglages du personnel, des collaborateurs et de l'authentification en deux étapes, rôles et connexion des contacts d'entreprise, chaque endroit où un prix peut être fixé, étendues d'accès (access scopes) des applications, applications personnalisées et jetons d'accès hors ligne expirants, HMAC des webhooks, proxys d'application, extensions de compte client, périmètre PCI et données clients"
locale: "fr"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# Revue de sécurité Shopify B2B : une check-list en 40 points pour les boutiques et les applications de devis

La revue de sécurité d'une boutique Shopify B2B doit répondre à quatre questions : **qui peut entrer dans l'admin et avec quel niveau d'accès, ce qu'un acheteur peut voir et faire, où un prix peut être modifié, et quels identifiants et points de terminaison existent en dehors de Shopify.** Les 40 contrôles ci-dessous couvrent ces quatre questions, plus les données dont une revue doit rendre compte, et chacun indique la règle Shopify qui le fonde et la façon de le vérifier vous-même.

Trois dates font de cette revue plus qu'un simple ménage en 2026. Les applications personnalisées ne peuvent plus être créées dans l'admin Shopify depuis le 1er janvier 2026, mais celles qui existent continuent de fonctionner. Les nouvelles applications publiques doivent utiliser des jetons d'accès (access tokens) hors ligne expirants depuis le 1er avril 2026, et toutes les applications publiques devront le faire au 1er janvier 2027, après quoi les jetons non expirants reçoivent des erreurs d'authentification. Les applications personnalisées et celles créées par le marchand en sont exemptées - après cette date, les jetons de longue durée qui restent dans une boutique sont donc précisément ceux qu'une revue doit trouver.

Cette check-list est neutre vis-à-vis des fournisseurs. C'est la revue de la *boutique* ; les questions à poser à un éditeur d'application sur sa propre gestion des données sont dans [comment évaluer une application Shopify B2B](/blog/shopify-b2b-app-evaluation-checklist), et cette page y renvoie au lieu de les répéter. Elle a été écrite par un fournisseur dont les propres réponses sont publiées à part, en lien à la fin.

Tout ce qui concerne Shopify ci-dessous a été vérifié sur les pages de Shopify le 25 septembre 2026, en version d'API 2026-07, sauf autre date indiquée ; les sources sont en fin de page.

## Comment mener la revue
1. **Exportez les faits avant la réunion.** La liste du personnel avec les permissions de chacun, la liste des collaborateurs, les applications installées avec leurs étendues d'accès accordées, chaque application personnalisée, et la liste des entreprises avec le rôle de chaque contact. Les sections A et B, et une bonne partie de la D, se répondent en lisant ces cinq listes.
2. **Testez le côté acheteur connecté comme un acheteur.** Une boutique de développement ou une entreprise de test avec deux sites, un contact sur chaque rôle, suffit pour voir ce que voit chaque rôle.
3. **Consignez la réponse et la preuve pour chaque ligne.** Une revue ne vaut que ce que vaut sa trace : le prochain réviseur doit pouvoir voir ce qui a été contrôlé, quand, et ce qui a été constaté.

## A. Accès à l'admin : personnel, collaborateurs et authentification en deux étapes
| # | Contrôle | Pourquoi (la règle Shopify) | Comment vérifier |
| --- | --- | --- | --- |
| 1 | Chaque utilisateur a activé l'authentification en deux étapes | « Les boutiques sur l'offre Shopify Plus peuvent exiger que tous les utilisateurs de leur organisation utilisent une méthode de connexion sécurisée » ; sur les autres offres, chaque utilisateur l'active pour son propre compte | Plus : vérifiez le réglage de sécurité de l'organisation. Autres offres : interrogez chaque utilisateur, et traitez un compte qui ne l'a pas comme une constatation |
| 2 | Personne ne dépend du SMS comme seul second facteur | Shopify ne propose plus le SMS pour les nouvelles configurations ; il reste pour les comptes existants. Applications d'authentification, clés de sécurité et authentificateurs intégrés sont les méthodes prises en charge | Demandez à chaque administrateur quelle méthode il utilise |
| 3 | Les comptes collaborateurs sont connus et délimités | Les collaborateurs sont des partenaires acceptés par le propriétaire ; ils reçoivent des rôles avec « les permissions dont ils ont besoin », et « ne comptent pas dans la limite d'utilisateurs de votre boutique », si bien qu'on les oublie facilement | Exportez la liste des collaborateurs ; pour chacun, l'agence, la personne, le rôle et la date de fin de la mission |
| 4 | Le code de demande de collaborateur ne circule pas | « Seuls les partenaires avec qui vous partagez le code peuvent demander l'accès à votre boutique » ; le code peut être régénéré | Régénérez-le à la fin d'une mission |
| 5 | Les départs sont supprimés, pas seulement désactivés dans les faits | Le personnel et les collaborateurs gardent leur accès jusqu'à leur suppression ; la suppression d'un collaborateur est définitive | Rapprochez les listes du personnel et des collaborateurs des personnes actuellement en poste |
| 6 | L'export des clients et les demandes de données sont réservés à peu de personnes | « Exporter » les clients est une permission distincte, et « Demander des données » fait partie des permissions sensibles signalées par Shopify | Listez qui détient chacune ; la réponse doit être un petit nombre, avec une raison |
| 7 | Ceux qui créent des commandes provisoires sont ceux qui doivent fixer les prix | Créer ou modifier une commande provisoire exige au moins une permission de paiement (conditions de paiement, débiter une carte, marquer comme payé) ; « Appliquer des réductions » est une permission distincte | Pour chaque utilisateur qui peut créer ou modifier des commandes provisoires et appliquer des réductions, confirmez que son rôle l'exige |
| 8 | Les commerciaux sont limités à leurs propres sites | « Restreindre les permissions aux sites d'entreprise affectés » limite un commercial aux pages Clients, Commandes, Commandes provisoires et Entreprises, filtrées sur ses sites ; jusqu'à 10 commerciaux par site | Connectez-vous comme un commercial et essayez d'ouvrir une entreprise qui ne lui est pas affectée |
| 9 | Supprimer des entreprises n'est pas une permission par défaut | La suppression d'entreprises et de sites est une permission à part entière | Listez qui la détient |
| 10 | « Gérer les paramètres » est attribué délibérément | Cette permission régit les paramètres de la boutique, dont les webhooks et Markets | Listez qui la détient ; un webhook ajouté dans l'admin envoie des données de la boutique vers une URL extérieure |

## B. Le côté acheteur : contacts, rôles et connexion
| # | Contrôle | Pourquoi (la règle Shopify) | Comment vérifier |
| --- | --- | --- | --- |
| 11 | Chaque contact a le rôle le plus restreint qui fonctionne | **« Commande uniquement »** : achète pour le site et voit ses propres commandes. **« Administrateur du site »** : voit « les commandes que tous les clients ont passées pour ce site » et peut mettre à jour les adresses de livraison et de facturation | Exportez les contacts avec leurs rôles ; « Commande uniquement » doit être la valeur par défaut, avec un administrateur du site nommé par site |
| 12 | Le rôle du contact principal a été choisi, pas hérité | « Le contact principal reçoit par défaut la permission Commande uniquement » - souvent suffisant, parfois la raison pour laquelle un acheteur ne voit pas ce dont il a besoin | Vérifiez le contact principal de chaque site |
| 13 | La boîte e-mail de l'acheteur est traitée comme l'identifiant | Les acheteurs B2B se connectent avec l'e-mail du site d'entreprise et un code à usage unique - sans mot de passe - donc qui contrôle cette boîte contrôle le compte acheteur | Confirmez que les e-mails des contacts sont ceux de personnes nommées ou d'une boîte partagée maîtrisée, pas l'adresse d'un ancien salarié |
| 14 | Les contacts sont supprimés quand des personnes quittent l'entreprise de l'acheteur | Un contact reste un contact jusqu'à sa suppression, quelle que soit la personne qui détient la boîte e-mail | Intégrez la revue des contacts à la routine du responsable de compte ; demandez à l'administrateur de l'acheteur la liste des départs |
| 15 | Les prix d'entreprise n'apparaissent qu'aux acheteurs d'entreprise connectés | Un acheteur non associé à un site d'entreprise est traité comme un client D2C même s'il se connecte, et voit les prix D2C | Connectez-vous comme un client non rattaché, puis comme un contact d'entreprise ; comparez |
| 16 | Un acheteur ne peut pas se basculer lui-même sur un autre site | Un acheteur multi-sites choisit parmi les sites où il détient un rôle | Connectez-vous comme un contact rattaché à un seul site ; confirmez qu'aucun autre n'apparaît |

## C. Intégrité des prix : où un prix peut être fixé
En B2B, la question qui compte le plus n'est pas « quelqu'un peut-il voir un prix » mais « quelqu'un peut-il en modifier un en dehors du circuit approuvé ». Une boutique Shopify B2B a une courte liste d'endroits légitimes où un prix est fixé ; tout le reste est une saisie que l'acheteur contrôle.

| Où un prix est légitimement fixé | Contrôlé par |
| --- | --- |
| La liste de prix et les paliers de volume d'un catalogue | Le personnel avec les permissions sur les catalogues |
| Les lignes et les réductions d'une commande provisoire | Le personnel avec les permissions sur les commandes provisoires et les réductions |
| Une réduction Shopify | Le personnel avec les permissions sur les réductions ; appliquée par Shopify au paiement |
| Le `lineUpdate` d'une fonction cart transform | La fonction côté serveur d'une application ; boutiques Plus et de développement uniquement |
| Le serveur propre d'une application, traduit dans l'un des cas ci-dessus | L'application, dans la limite de ses étendues d'accès |

| Où l'acheteur fournit la valeur | Ce que cela signifie |
| --- | --- |
| Propriétés de ligne (line item properties, `properties[...]` dans le formulaire produit) | Documentées comme la saisie propre du client - texte de gravure, notes, fichiers |
| Attributs de panier, champs de formulaire, paramètres d'URL | Tout ce qu'envoie le navigateur peut être modifié dans le navigateur |

| # | Contrôle | Pourquoi | Comment vérifier |
| --- | --- | --- | --- |
| 17 | Aucune application ni aucun thème ne lit un prix dans une saisie de l'acheteur | Les propriétés de ligne sont définies par le client ; un prix tiré de là, d'un attribut de panier ou d'une URL est un prix choisi par l'acheteur | Demandez à chaque application de prix ou de devis d'où vient le prix d'une ligne ; lisez tout code de thème qui envoie des données au panier |
| 18 | Les remplacements de prix au panier ne se font que dans une fonction côté serveur | Le `lineUpdate` de cart transform peut « remplacer le prix, le titre et l'image d'une ligne du panier », et uniquement sur les boutiques Plus ou de développement | Listez les fonctions cart transform installées et ce sur quoi chacune fonde son prix |
| 19 | Les règles qui protègent la marge s'exécutent sur le serveur | La Cart and Checkout Validation Function API s'exécute côté serveur sur le paiement B2B et sur les commandes provisoires ; le code du thème s'exécute dans le navigateur de l'acheteur | Rattachez chaque règle (minimums, bon de commande obligatoire, restrictions par site) à un catalogue, à des règles de quantité ou à une fonction de validation |
| 20 | Les intégrations qui créent des commandes réappliquent les règles | Les fonctions de validation ne s'exécutent ni sur l'API de création de commande ni sur la modification de commande | Pour chaque intégration qui écrit des commandes, demandez où elle applique les règles de l'acheteur |
| 21 | Une réduction négociée a un approbateur | Une commande provisoire porte le prix que lui a donné le membre du personnel qui détient la permission, quel qu'il soit | Vérifiez qui peut appliquer des réductions, et si quoi que ce soit au-delà d'un seuil exige une seconde personne |
| 22 | Le lien de facture a été testé, pas supposé | La page de Shopify sur les factures décrit l'envoi du lien de paiement par e-mail ou sa copie dans un message, et met en garde contre le marquage de la commande comme payée avant ; elle ne dit pas qui d'autre peut ouvrir le lien ni s'il expire | Ouvrez un lien de facture déconnecté, dans une fenêtre privée, sur un autre appareil ; notez ce que vous voyez et décidez si c'est acceptable pour vos acheteurs |
| 23 | Les commandes provisoires ne sont jamais marquées comme payées avant le paiement | « Marquer comme payé » est une permission de paiement ; marquer une commande provisoire comme payée avant que l'acheteur ne paie casse le lien de facture et enregistre de l'argent qui n'est pas arrivé | Listez qui détient « Marquer comme payé » |

## D. Applications, identifiants et points de terminaison
| # | Contrôle | Pourquoi (la règle Shopify) | Comment vérifier |
| --- | --- | --- | --- |
| 24 | Les étendues d'accès accordées à chaque application correspondent à ce qu'elle fait | Les étendues d'accès (access scopes) « contrôlent quelles données de la boutique votre application peut lire et écrire » ; Shopify demande aux applications de « ne demander que les données dont votre application a besoin » ; les étendues d'écriture incluent la lecture | Lisez les étendues de chaque application sur ses écrans d'installation et d'accès aux données ; interrogez toute étendue `write_` que la fonction de l'application n'explique pas |
| 25 | Ce sont les étendues accordées qui ont été vérifiées, pas celles configurées | Les étendues optionnelles sont « accordées séparément, après l'installation », donc ce que détient une application peut différer de sa configuration | Pour les applications personnalisées, interrogez les étendues accordées ; pour les applications publiques, lisez la page d'accès aux données dans l'admin |
| 26 | Les applications qui accèdent à un long historique de commandes ont une raison | `read_all_orders` (au-delà des 60 jours par défaut) exige l'approbation de Shopify | Demandez pourquoi, application par application |
| 27 | Chaque application personnalisée est inventoriée, avec un responsable | Les applications personnalisées ne peuvent plus être créées dans l'admin depuis le 1er janvier 2026, mais celles qui existent « continuent de fonctionner » ; les nouvelles applications personnalisées se construisent dans le Dev Dashboard | Listez les applications personnalisées, qui a construit chacune, ce qu'elle fait et si elle sert encore |
| 28 | Les jetons de longue durée sont connus et peuvent être révoqués | Un jeton hors ligne non expirant accorde un « accès permanent jusqu'à la désinstallation de l'application ou la révocation du secret » ; les applications personnalisées et celles créées par le marchand sont exemptées de la règle d'expiration de 2027 | Pour chaque application personnalisée : où le jeton est-il stocké, qui peut le lire, et comment le révoqueriez-vous aujourd'hui |
| 29 | Les applications publiques utilisent des jetons expirants, ou ont un plan | Nouvelles applications publiques depuis le 1er avril 2026 ; toutes les applications publiques au 1er janvier 2027, après quoi les jetons non expirants « reçoivent des erreurs d'authentification ». Les jetons expirants durent une heure, avec un jeton d'actualisation (refresh token) de 90 jours | Demandez à chaque éditeur d'application publique s'il a migré |
| 30 | Les webhooks sont vérifiés par HMAC | Chaque livraison porte `X-Shopify-Hmac-SHA256`, un HMAC en base64 du corps brut calculé avec le secret client de l'application ; vérifiez sur le corps brut, comparez en temps constant, renvoyez 401 en cas d'échec | Pour vos propres points de terminaison, lisez le gestionnaire ; pour les éditeurs, c'est une question de la [check-list d'évaluation des applications](/blog/shopify-b2b-app-evaluation-checklist) |
| 31 | Les gestionnaires de webhooks sont idempotents | Les livraisons peuvent se répéter ; dédupliquez sur `X-Shopify-Webhook-Id` | Rejouez une livraison sur une boutique de développement et vérifiez que rien ne se produit deux fois |
| 32 | Les points de terminaison de proxy d'application vérifient la signature et le propriétaire | Les requêtes de proxy d'application (app proxy) portent une `signature` calculée sur les autres paramètres ; `logged_in_customer_id` doit être rapproché du propriétaire des données demandées après vérification ; Shopify retire les cookies | Pour chaque route de proxy d'application qui renvoie des données acheteur, confirmez les deux contrôles |
| 33 | Les extensions de compte client prouvent qui fait la demande | Les appels réseau des extensions partent avec CORS `*` depuis une origine à laquelle on ne peut pas se fier ; c'est le jeton de session qui prouve l'identité du client | Pour chaque backend d'extension, confirmez qu'il vérifie le jeton de session et ne se fie jamais à un identifiant de client ou d'entreprise envoyé dans le corps |
| 34 | Les webhooks de boutique ajoutés dans l'admin sont identifiés | Un webhook créé dans l'admin envoie des données de la boutique à l'URL saisie, quelle qu'elle soit | Listez les webhooks créés dans les paramètres de l'admin ; chacun doit avoir un responsable et une finalité |

## E. Données clients et paiements
| # | Contrôle | Pourquoi (la règle Shopify) | Comment vérifier |
| --- | --- | --- | --- |
| 35 | Les numéros de carte n'entrent jamais ailleurs que dans le paiement Shopify | « Shopify est certifié conforme PCI DSS de niveau 1 », et la certification couvre « votre boutique, son panier et l'hébergement web » - pas un formulaire de devis, un fil d'e-mails ou un fichier téléversé | Cherchez dans les formulaires de devis, les champs personnalisés et les champs de téléversement tout ce qui invite à saisir des données de carte ; supprimez-le |
| 36 | Les applications qui détiennent des données clients sont approuvées pour cela | Nom, adresse, e-mail et téléphone sont des données clients protégées, auxquelles les applications publiques ont besoin de l'approbation de Shopify pour accéder | Couvert par les questions aux éditeurs dans [la check-list d'évaluation des applications](/blog/shopify-b2b-app-evaluation-checklist) |
| 37 | L'effacement à la désinstallation est compris | `shop/redact` arrive 48 heures après la désinstallation ; `customers/redact` 10 jours après une demande, ou six mois après la dernière commande du client ; les applications ont 30 jours pour agir | Consignez le comportement documenté de chaque application face à ces délais |
| 38 | Les fichiers téléversés sont validés et leur accès contrôlé | Les acheteurs joignent plans, spécifications et bons de commande à leurs demandes ; un fichier est une donnée que la boutique détient désormais | Demandez quelle validation reçoit un fichier (type, taille, contenu actif), où il est stocké et qui peut le télécharger |
| 39 | Les exports de clients laissent une trace | L'export et les demandes de données sont des permissions, pas des paramètres, donc le contrôle porte sur qui les détient | À relier au contrôle 6 ; décidez où les fichiers exportés peuvent être stockés |
| 40 | La revue est datée et planifiée | Deux des lignes ci-dessus changent à des dates publiées (1er janvier 2027 pour les jetons) et Shopify livre des changements B2B chaque trimestre | Inscrivez la prochaine revue au calendrier ; relancez-la après chaque changement de personnel dans l'admin, chaque nouvelle application et chaque Shopify Edition |

## Le calendrier des identifiants
| Date | Ce qui a changé | Ce qu'il faut vérifier |
| --- | --- | --- |
| 1er janv. 2026 | Les applications personnalisées ne peuvent plus être créées dans l'admin Shopify ; celles qui existent continuent de fonctionner | Les inventorier (contrôle 27) |
| 1er avr. 2026 | Les nouvelles applications publiques doivent utiliser des jetons d'accès hors ligne expirants | Rien pour la boutique ; concerne les éditeurs |
| 1er janv. 2027 | Toutes les applications publiques doivent utiliser des jetons expirants ; les jetons non expirants reçoivent des erreurs d'authentification | Interroger les éditeurs (contrôle 29) ; les applications personnalisées et celles créées par le marchand sont exemptées, donc le contrôle 28 compte davantage après cette date, pas moins |

Les surfaces de paiement retirées - checkout.liquid, scripts supplémentaires, Shopify Scripts - sont aussi une question de sécurité, parce que du code que personne ne maintient est du code que personne ne relit ; leurs dates sont dans [la dette technique Shopify B2B](/blog/shopify-b2b-technical-debt#due-dates).

## Où sont les réponses de QuotWay
Publiées à part plutôt qu'imprimées ici, pour que cette check-list reste utilisable pour n'importe quelle boutique et n'importe quelle application : [sécurité et protection des données](/security) couvre la gestion des données, la conservation et les webhooks de QuotWay, la [liste des sous-traitants](/sub-processors) indique qui traite quoi, [ce que QuotWay peut faire et ne peut pas faire](/capabilities) répond aux questions d'application des règles et de permissions forfait par forfait, et la façon dont les approbations de remise sont acheminées et appliquées est sur la [page de la fonctionnalité approbations](/features/approvals). Les questions à poser à toute application de devis ou de prix sont dans [la check-list d'évaluation des applications](/blog/shopify-b2b-app-evaluation-checklist), et la [check-list de 50 tests avant mise en ligne](/blog/shopify-b2b-launch-test-plan) couvre le côté fonctionnel. Les forfaits sont sur la [page des tarifs](/pricing).

Les faits Shopify de cet article sont tenus à jour dans la [référence Shopify B2B](/reference/shopify-b2b#sales-staff).

## Questions fréquentes

### Puis-je exiger l'authentification en deux étapes pour tout le personnel Shopify ?

Seulement sur Shopify Plus, où l'organisation peut exiger une méthode de connexion sécurisée pour chaque utilisateur. Sur les autres offres, chaque utilisateur l'active pour son propre compte, donc la revue doit interroger chaque personne. Les comptes collaborateurs sont différents : les partenaires doivent activer l'authentification en deux étapes pour pouvoir en utiliser un.

### Les comptes collaborateurs comptent-ils dans ma limite de personnel ?

Non. Shopify indique que « les collaborateurs ne comptent pas dans la limite d'utilisateurs de votre boutique », ce qui est l'une des raisons pour lesquelles on les oublie. Ils sont demandés avec un code à 4 chiffres que vous donnez au partenaire, délimités par rôle, et supprimés définitivement quand vous les retirez.

### Les jetons d'accès Shopify expirent-ils ?

Les jetons d'accès (access tokens) hors ligne expirants durent une heure et s'accompagnent d'un jeton d'actualisation valable 90 jours. Les nouvelles applications publiques doivent les utiliser depuis le 1er avril 2026 et toutes les applications publiques devront le faire au 1er janvier 2027, après quoi les jetons non expirants reçoivent des erreurs d'authentification. Les applications personnalisées et les applications créées par les marchands dans le Dev Dashboard ou dans l'admin en sont exemptées, et leurs jetons non expirants durent jusqu'à la désinstallation de l'application ou la révocation du secret.

### Comment vérifier un webhook Shopify ?

Calculez un HMAC-SHA256 en base64 du corps brut de la requête avec le secret client de l'application et comparez-le, en temps constant, à l'en-tête `X-Shopify-Hmac-SHA256`. Vérifiez avant qu'un parseur ne touche au contenu, renvoyez 401 s'il ne correspond pas, et ignorez les livraisons dont vous avez déjà traité le `X-Shopify-Webhook-Id`.

### La conformité PCI de Shopify couvre-t-elle mon processus de devis B2B ?

Shopify est certifié conforme PCI DSS de niveau 1, et la certification couvre la boutique, son panier et l'hébergement web. Les données de carte collectées ailleurs - dans un formulaire de devis, un e-mail ou un fichier téléversé - sont en dehors de ce que décrit cette certification. Gardez le paiement dans le paiement Shopify ou dans la facture de la commande provisoire.

### Un acheteur peut-il modifier un prix par le panier ?

Pas par quoi que ce soit que Shopify traite comme un prix. Les propriétés de ligne et les attributs de panier sont la saisie propre de l'acheteur, donc le risque est une application ou un thème qui y lit un prix. Les remplacements de prix au panier passent par l'opération `lineUpdate` d'une fonction cart transform, qui s'exécute côté serveur et uniquement sur les boutiques Plus ou de développement.

### Que peut voir un administrateur du site qu'un contact « Commande uniquement » ne voit pas ?

Un administrateur du site voit toutes les commandes passées pour le site d'entreprise, par n'importe quel contact, et peut mettre à jour les adresses de livraison et de facturation du site. Un contact « Commande uniquement » voit les commandes qu'il a passées. Le contact principal démarre en « Commande uniquement ».

## Sources

Pages Shopify, lues le 25 septembre 2026 en version d'API 2026-07 sauf date contraire :

- [Authentification en deux étapes](https://help.shopify.com/en/manual/your-account/account-security/two-step-authentication) et [comptes collaborateurs](https://help.shopify.com/en/manual/your-account/users/security/collaborator-accounts)
- [Descriptions des permissions du personnel](https://help.shopify.com/en/manual/your-account/staff-accounts/staff-permissions/staff-permissions-descriptions)
- [Contacts d'entreprise](https://help.shopify.com/en/manual/b2b/companies/contacts), [connexion et comptes clients en B2B](https://help.shopify.com/en/manual/b2b/customer-login-and-accounts) et [équipe commerciale](https://help.shopify.com/en/manual/b2b/sales-staff) (les deux dernières lues du 20 au 23 septembre 2026)
- [Étendues d'accès (access scopes)](https://shopify.dev/docs/api/usage/access-scopes) et [données clients protégées](https://shopify.dev/docs/apps/launch/protected-customer-data) (lues le 20 septembre 2026)
- [Jetons d'accès hors ligne](https://shopify.dev/docs/apps/build/authentication-authorization/access-tokens/offline-access-tokens), les entrées du changelog pour [les nouvelles applications publiques (1er avril 2026)](https://shopify.dev/changelog/expiring-offline-access-tokens-required-for-public-apps-april-1-2026) et [toutes les applications publiques (1er janvier 2027)](https://shopify.dev/changelog/expiring-offline-access-tokens-required-for-all-public-apps-as-of-january-1-2027), et [les anciennes applications personnalisées ne peuvent plus être créées après le 1er janvier 2026](https://changelog.shopify.com/posts/legacy-custom-apps-can-t-be-created-after-january-1-2026)
- [Livraison des webhooks en HTTPS](https://shopify.dev/docs/apps/build/webhooks/subscribe/https) et [authentification des proxys d'application](https://shopify.dev/docs/apps/build/online-store/app-proxies/authenticate-app-proxies)
- [Capacités des extensions de compte client](https://shopify.dev/docs/apps/build/customer-accounts/capabilities) (lue le 22 septembre 2026)
- [Cart transform](https://shopify.dev/docs/api/functions/latest/cart-transform), [Cart and Checkout Validation](https://shopify.dev/docs/api/functions/latest/cart-and-checkout-validation) (lue le 24 septembre 2026) et [propriétés de ligne](https://shopify.dev/docs/storefronts/themes/architecture/templates/product#line-item-properties)
- [Envoyer des factures pour les commandes provisoires](https://help.shopify.com/en/manual/fulfillment/managing-orders/create-orders/send-draft)
- [Conformité PCI de Shopify](https://www.shopify.com/security/pci-compliant)