Une notification reçue deux fois ne doit pas créer deux actions
Une boutique peut envoyer deux fois la notification qui déclenche une tâche dans le CRM. Si les deux réceptions concernent le même événement, le scénario doit retrouver l'action déjà créée au lieu d'en ajouter une seconde.
C'est le principe d'idempotence : répéter la demande conserve le résultat attendu. Il faut toutefois pouvoir reconnaître l'événement et savoir jusqu'où son premier traitement est allé.
Le message est arrivé deux fois, la commande n'existe qu'une fois
Prenons une situation fictive : une boutique envoie une notification de commande à une automatisation chargée de créer une tâche de préparation. La tâche est créée, puis la connexion s'interrompt avant que l'expéditeur reçoive la confirmation. Une nouvelle notification arrive. Si le scénario crée systématiquement une tâche à chaque réception, l'équipe peut préparer deux fois la même commande.
Il faut distinguer la livraison du message de l'action métier. Recevoir à nouveau un message ne signifie pas qu'une nouvelle commande existe. Inversement, deux messages semblables ne sont pas forcément des doublons : une commande peut réellement être modifiée.
La documentation Shopify sur les webhooks traite la vérification des livraisons et l'identification des doublons. Dans votre scénario, utilisez les identifiants documentés par la source et précisez ce que chacun identifie. Ne choisissez pas une clé à partir du seul nom du client ou du montant : deux achats légitimes peuvent partager ces valeurs.
Trois moments où la reprise peut déraper
| Moment de l'interruption | Ce qui reste incertain | Question avant de relancer |
|---|---|---|
| Avant la création de la tâche | L'action a-t-elle commencé ? | Existe-t-il une trace côté destination ? |
| Après la création, avant l'accusé | La tâche existe peut-être déjà | Peut-on la retrouver par sa référence métier ? |
| Après une première reprise | Plusieurs traitements peuvent se chevaucher | La règle empêche-t-elle deux créations concurrentes ? |
Cette grille est un scénario de conception. Elle ne prouve pas qu'un outil donné couvre ces trois cas par défaut.
Une simple recherche « la tâche existe-t-elle ? » peut être insuffisante si deux exécutions la font au même moment avant de créer chacune leur tâche. Le mécanisme qui réserve ou garantit l'unicité doit être adapté à la destination. Pour une petite équipe, cette question mérite d'être posée à l'intégrateur, même si le scénario est construit dans une interface sans code.
Définir ce qu'une seconde réception doit produire
Pour une action déjà confirmée, le traitement peut retrouver la tâche existante et enregistrer que l'événement a déjà été traité. Pour une action dont le résultat est inconnu, il doit d'abord rechercher le résultat. Ces comportements sont différents d'un simple abandon du message.
Écrivez aussi la règle pour une véritable modification. Si l'adresse de livraison change après la création de la tâche, ignorer toute notification portant la même référence de commande peut faire perdre une information utile. La clé de dédoublonnage doit correspondre à l'événement ou à l'opération que vous protégez, pas à une définition trop large de « même client ».
Testez ces distinctions avec des données fictives : même livraison rejouée, modification légitime et interruption après création. Le résultat attendu doit être décrit avant l'essai. Vous pourrez alors demander une correction précise si le journal confond une tâche retrouvée, une tâche créée et un résultat encore incertain.
Définir l'identité de l'événement
Avec la personne qui construit le scénario, choisissez la référence permettant de reconnaître l'événement reçu. Utilisez les identifiants documentés par le service, sans inventer une clé à partir du seul nom du client ou de l'heure approximative.
Prévoyez ces cas dans le workflow CRM dès sa conception, avec un état visible pour les traitements interrompus.
Tester des incidents contrôlés
Préparez une notification de test, rejouez-la, puis simulez une interruption à une étape autorisée. Vérifiez le nombre et le contenu des actions obtenues, pas seulement la couleur du scénario.
La gestion des erreurs dans n8n propose des mécanismes de traitement des échecs. Ils aident à organiser la réaction, mais ne créent pas automatiquement une garantie contre les doublons.
Distinguer création, doublon et résultat incertain
Le journal doit distinguer une nouvelle action, un événement déjà traité et un résultat incertain. Évitez d'y recopier inutilement des données personnelles.
Avant l'extension, rejouez un événement déjà traité et un traitement interrompu. Le journal doit permettre de comprendre pourquoi une action a été créée, ignorée ou laissée en attente de vérification.