Shopify et votre ERP : une commande transmise deux fois doit-elle créer deux opérations ?

9 h 02 : une commande payée arrive dans votre logiciel de gestion. 9 h 03 : la même commande apparaît une seconde fois dans la file de préparation. Le client n’a pourtant acheté qu’une fois.

Dans ce scénario fictif, l’ERP a bien créé la première commande, mais la liaison s’est interrompue avant que le connecteur ait enregistré sa confirmation. Lors de la reprise, celui-ci a recommencé la création. Deux messages techniques ont ainsi produit deux opérations commerciales.

La réponse n’est pas de désactiver les reprises : sans elles, une panne peut laisser une vraie commande de côté. Il faut rendre la reprise capable de reconnaître ce qui a déjà été fait. Pour un marchand, cela se vérifie avec des références et des résultats dans l’ERP, pas avec un voyant vert « synchronisation terminée ».

Le message n’est pas la commande

Un webhook est une notification envoyée par Shopify lorsqu’un événement intéresse une application. Il permet au connecteur de réagir sans interroger continuellement la boutique. Shopify précise qu’une même livraison peut être reçue plusieurs fois, notamment après un délai d’attente dépassé ou une nouvelle tentative.

Ce comportement ne prouve ni un double achat ni une anomalie du paiement. Il impose au destinataire de supporter la répétition. Le terme technique est *idempotence* : pour une même opération, rejouer la même demande ne doit pas créer un nouvel effet métier.

« Pour une même opération » est essentiel. Créer la commande dans l’ERP, réserver ses articles, transmettre un ordre de préparation et enregistrer un remboursement sont des effets différents. Un connecteur peut éviter la double création de commande tout en réservant deux fois le stock. La promesse « nous gérons les doublons » doit donc préciser ce qu’elle protège réellement.

Dans une PME lyonnaise qui vend en ligne et prépare depuis un dépôt, commencez par dessiner le trajet réel : Shopify, connecteur, ERP, puis éventuellement entrepôt ou facturation. Entourez chaque étape qui écrit quelque chose. Ce schéma rend le périmètre des intégrations de votre boutique e-commerce beaucoup plus concret qu’une liste de logiciels compatibles.

Deux identifiants Shopify, deux usages

La documentation consultée le 6 octobre 2026 distingue :

• X-Shopify-Webhook-Id, utilisé pour reconnaître les répétitions d’une livraison ;
• X-Shopify-Event-Id, utilisé pour rapprocher les livraisons issues d’une même action du marchand.

Si plusieurs abonnements couvrent le même sujet, Shopify peut adresser une livraison par abonnement : leurs identifiants de webhook diffèrent, mais leur identifiant d’événement est commun. Ne compter que les premiers ne suffit donc pas à comprendre pourquoi deux chemins techniques demandent la même création ERP.

Ces en-têtes ne constituent pas, à eux seuls, une garantie d’unicité dans votre logiciel de gestion. L’intégrateur doit expliquer comment il relie boutique, événement, opération visée et référence distante. Deux boutiques peuvent aussi afficher un même numéro commercial de commande : le contexte boutique ne doit pas disparaître du rapprochement.

La détection des doublons ne remplace pas non plus la vérification de provenance. Pour les livraisons HTTPS classiques, Shopify demande de vérifier la signature HMAC avant de faire confiance au contenu. L’identité du message et le droit de le traiter sont deux contrôles distincts.

Le moment décisif : « créé là-bas, pas confirmé ici »

Revenons à notre incident fictif. Le connecteur a envoyé la commande ; l’ERP l’a créée ; la réponse s’est perdue. Côté connecteur, le résultat est inconnu, pas nécessairement « échec ».

Deux raccourcis échouent dans cette situation. Marquer une opération « terminée » avant son exécution peut faire perdre une commande si le processus s’arrête ensuite. Enregistrer « terminé » uniquement après la réponse laisse une fenêtre pendant laquelle l’ERP a déjà agi sans que le connecteur le sache. Un simple indicateur « déjà vu » n’explique pas comment fermer cette fenêtre.

La question à poser au prestataire est précise : avant de recréer après cette coupure, comment retrouvez-vous l’éventuelle opération déjà présente dans l’ERP ? Selon ses possibilités, la réponse peut s’appuyer sur une clé d’idempotence acceptée par l’ERP, une référence externe unique, ou une procédure de rapprochement suivie d’une décision contrôlée. Ce sont des pistes d’architecture, pas un algorithme universel à appliquer à tous les logiciels.

Si l’ERP ne permet pas de conclure, le flux doit faire remonter un état « à rapprocher » avec un responsable. Un arrêt explicable vaut mieux qu’une deuxième expédition déclenchée pour faire disparaître une alerte. Cette limite doit figurer dans le périmètre du connecteur, avec la procédure et les délais de traitement convenus.

Autre point à faire démontrer : deux traitements simultanés. S’ils lisent tous les deux « pas encore traité » avant d’écrire, un contrôle correct en apparence peut laisser passer deux créations. L’intégrateur doit prouver que l’unicité tient aussi en concurrence, au niveau où l’effet est produit, et pas seulement lors d’une démonstration séquentielle.

Une fiche de rapprochement que l’exploitation peut lire

Le journal technique est utile, mais la personne qui prépare les colis doit pouvoir retrouver la bonne commande sans lire un serveur. Pour notre exemple fictif, une fiche minimale peut prendre cette forme :

La fiche n’a pas besoin de recopier le nom, l’adresse et le panier complet du client. Conservez les identifiants et éléments nécessaires au diagnostic, avec des accès et une durée de conservation adaptés. Un export destiné à un prestataire peut être expurgé ; des journaux contenant des données clients ne doivent pas être envoyés dans un formulaire public.

Pour vérifier la cohérence commerciale, rapprochez aussi les éléments qui définissent l’opération : devise, lignes, quantités, montants et traitement de TVA selon le flux concerné. Deux documents du même montant ne sont pas nécessairement des doublons ; une seule référence présente ne prouve pas que ses lignes sont exactes. Sur un commerce français en euros, testez notamment les arrondis et les montants de livraison qui traversent le connecteur.

Enfin, séparez les états : reçu, en attente de traitement, confirmé dans l’ERP, à rapprocher. Shopify attend une réponse HTTPS rapide ; la documentation recommande notamment la mise en file pour absorber les pointes de trafic. Un accusé de réception peut donc précéder le travail métier. Il ne faut pas le présenter à l’exploitation comme la preuve que tout est terminé.

La recette : provoquer la répétition, puis compter les effets

Les essais suivants sont proposés, non exécutés. Ils se déroulent avec des données fictives dans un environnement de test, sans paiement, remboursement, email client ou expédition réels. L’intégrateur organise les interruptions ; le responsable métier valide le résultat distant.

Première scène : le même message arrive deux fois. Rejouez une livraison classique identifiée, puis cherchez la commande dans l’ERP. Il faut retrouver deux réceptions reliées à une seule création, avec sa référence. Vérifiez séparément la réservation de stock si elle dépend d’un autre traitement. Un total global de commandes inchangé n’est pas une preuve suffisante : une commande manquante peut masquer un doublon.

Deuxième scène : la réponse disparaît. Interrompez la liaison après la création ERP mais avant la confirmation locale. La reprise doit retrouver l’existant avant toute nouvelle création, ou s’arrêter explicitement pour rapprochement si la preuve manque. Conservez les traces de coupure, la référence distante et la décision de reprise. C’est le test central : une répétition sans panne ne couvre pas cette situation.

Troisième scène : deux chemins, puis deux traitements en parallèle. Inventoriez les abonnements et les autres entrées, y compris un import manuel ou un rattrapage planifié qui peut toucher la même commande. Faites converger deux chemins sur une seule opération, puis testez leur exécution simultanée. La preuve attendue reste une seule création distante, avec une explication du chemin retenu et du traitement de l’autre. Désactiver un abonnement dans le test ne démontre pas que le système résistera à une concurrence réelle.

Quatrième scène : un remboursement rejoué, puis un autre réellement distinct. Rejouer la même demande de remboursement de test ne doit pas créer un deuxième mouvement pour cette demande. Ensuite, créez deux remboursements partiels distincts et autorisés sur la même commande : ils doivent tous deux être traités. Une protection fondée uniquement sur le numéro de commande risquerait de bloquer le second remboursement légitime. Faites valider les références et les effets par le responsable finance, sans confondre écriture ERP et exécution chez le prestataire de paiement.

Pour chaque scène, le compte rendu conserve l’attendu, l’observé, les références expurgées, l’horodatage, le responsable et la décision. Tant que ces éléments manquent, la ligne reste « non exécutée » ou « preuve insuffisante », jamais « validée par principe ».

Et si un événement n’arrive pas du tout ?

Empêcher les doublons ne garantit pas l’exhaustivité. Shopify évoque aussi un rapprochement périodique au moyen de ses API pour retrouver les données éventuellement manquées. Le même contrôle est utile entre la boutique et l’ERP : commandes attendues, opérations confirmées, exceptions encore ouvertes.

Prévoyez un périmètre temporel explicite, un délai acceptable avant alerte et une personne qui traite les écarts. Le rattrapage doit utiliser les mêmes protections que le flux courant ; sinon, l’outil conçu pour retrouver les commandes manquantes devient une deuxième source de doublons.

La supervision et maintenance technique doit ainsi surveiller autre chose que la disponibilité du serveur : ancienneté de la file, opérations bloquées et écarts de rapprochement. Un site peut répondre normalement alors qu’aucune commande ne rejoint plus la préparation.

Events change les abonnements, pas la preuve dans votre ERP

Le 1er octobre 2026, Shopify a annoncé la disponibilité générale de Next Gen Events avec l’API 2026-10, sur 18 sujets. Cette évolution permet de cibler les changements utiles et de définir les données reçues via une requête GraphQL, avec un filtre sur ses résultats. Elle peut réduire des livraisons inutiles ou des appels complémentaires selon le flux.

Une nuance de l’annonce mérite d’être conservée : le résultat de la requête reflète l’état au moment où elle s’exécute. Shopify distingue fields_changed, qui décrit le changement, et data, qui apporte le contexte courant. Il ne faut pas présenter ce dernier comme une photographie immuable de l’instant initial.

Les intégrations classiques continuent de fonctionner, précise également Shopify. Il n’y a donc pas, dans cette annonce, d’obligation de migrer immédiatement. Ne transposez pas sans vérification les en-têtes et règles des webhooks classiques au nouveau flux Events. Et ne déduisez pas d’abonnements plus ciblés que l’ERP ne pourra plus créer de doublons : la reprise après un effet distant reste à concevoir et à tester.

Les questions qui restent après le diagnostic

Deux notifications signifient-elles deux commandes à supprimer ?

Non. Commencez par identifier l’opération réellement répétée et son état dans chaque système. Deux notifications peuvent n’avoir créé qu’une commande. Deux commandes ERP peuvent aussi avoir déjà déclenché des effets distincts. Ne supprimez pas une écriture pour nettoyer l’affichage sans vérifier préparation, stock, facturation et éventuelles corrections nécessaires avec leurs responsables.

Un connecteur du marché doit-il aussi passer cette recette ?

Oui, sur les parcours utilisés par votre entreprise. Demandez sa procédure documentée de reprise, les preuves disponibles et les limites de responsabilité entre l’éditeur du connecteur et celui de l’ERP. Une fonctionnalité annoncée n’établit pas le comportement de votre configuration.

Faut-il tout reconstruire si une preuve manque ?

Non. La restitution peut conclure à un flux traçable, une anomalie reproductible à corriger, ou une preuve insuffisante à obtenir. Ces conclusions n’appellent pas le même chantier. Commencez par un flux et une opération bien définis, puis élargissez seulement si les résultats le justifient.

Le bon livrable : une décision de reprise explicable

À la fin du diagnostic, votre équipe doit savoir répondre à une question simple : « Si cette opération revient maintenant, que va-t-il se passer, et comment le vérifier ? » Une cartographie, des références rapprochées et des essais documentés permettent de décider quoi corriger avant d’ajouter de l’automatisation.

Faites examiner un flux commande–ERP avec 1Design : le cadrage porte sur ses points de reprise, les preuves manquantes et une recette anti-doublon. La correction, la migration éventuelle et leur chiffrage restent des étapes distinctes. Pour démarrer, un schéma des outils et une description expurgée du problème suffisent ; ne transmettez ni clés API, ni accès ERP, ni données clients dans le formulaire.

Sources

Sources primaires consultées le 6 octobre 2026 :

• Shopify — Verify webhook deliveries : répétitions, distinction des identifiants, vérification HTTPS, réception et rapprochement.
• Shopify — More control over commerce updates with Next Gen Events, annonce du 1er octobre 2026 : API 2026-10, périmètre, contexte des requêtes et maintien des webhooks classiques.

Les scénarios, la fiche et les critères de recette constituent des recommandations 1Design. Ils ne décrivent ni un incident client réel ni des tests effectués sur un ERP particulier.