Connexion entre boutique et outil métier : éviter les commandes en double
Traitez une commande grâce à un identifiant stable et prévoyez les reprises. Une notification reçue deux fois ne doit pas déclencher deux préparations.
Séparer la notification de l’opération métier
Une notification indique qu’un événement s’est produit dans un outil. Elle ne doit pas être confondue avec l’ordre de préparer une nouvelle commande à chaque réception. Une connexion doit identifier le dossier concerné et savoir si l’action attendue a déjà été réalisée.
Cette distinction devient essentielle lorsqu’un service réessaie un envoi après une interruption. Deux messages identiques peuvent correspondre à une seule commande. À l’inverse, deux événements différents peuvent concerner deux étapes légitimes du même dossier.
Utiliser les bons identifiants
| Identifiant | Rôle à définir |
|---|---|
| Événement | Reconnaître une notification déjà reçue |
| Commande | Retrouver le dossier commercial concerné |
| Opération | Éviter de déclencher deux fois la même préparation |
| Version ou état | Vérifier que la modification reste applicable |
Un horodatage seul ou le nom d’un client ne constitue pas forcément un identifiant suffisant. Plusieurs opérations peuvent arriver très près les unes des autres, et une même personne peut passer plusieurs commandes différentes.
Concevoir le traitement pour les reprises
La documentation des webhooks Stripe illustre des comportements à prévoir : des événements peuvent être reçus plusieurs fois et leur ordre de livraison n’est pas garanti. Les garanties exactes doivent être vérifiées pour chaque service connecté ; il ne faut pas les déduire d’un autre outil.
Le principe métier est de rendre une répétition sans effet supplémentaire lorsqu’une opération a déjà été validée. Un système doit pouvoir répondre « déjà traité » sans créer une nouvelle expédition, un nouveau document ou une seconde notification commerciale.
Ne pas annoncer une réussite avant de pouvoir reprendre
Une réponse technique positive peut être envoyée alors que l’opération longue sera exécutée ensuite. Dans ce cas, la file de traitement, les erreurs et les reprises doivent être organisées. L’acceptation de la notification ne prouve pas que la préparation de commande a été terminée.
Conservez des états distincts : reçu, à traiter, terminé, en erreur et repris, selon la conception. Précisez ce que la personne chargée du suivi doit faire et ce qu’elle ne doit pas relancer manuellement. Une action humaine non suivie peut recréer les doublons que le code cherchait à éviter.
Tester des scénarios moins parfaits que la démonstration
Rejouez une même notification, simulez une interruption avant et après l’opération, puis vérifiez le résultat dans l’outil destinataire. Testez aussi deux traitements proches sur un même dossier et l’arrivée d’une annulation après la création.
La preuve attendue est le résultat métier : une préparation, le bon état et une trace des tentatives. Le guide sur Shopify et l’ERP complète la répartition des données. Celui sur la personnalisation aide à conserver les informations que cette connexion doit transmettre sans les perdre ni les dupliquer.
Sources
Documentation consultée le 22 octobre 2026.