n8n : éviter les doublons avec Remove Duplicates

Un client reçoit deux e-mails de confirmation. Une facture est créée en double. Un lead apparaît deux fois dans le CRM. Dans les trois cas, le même événement a traversé votre workflow n8n deux fois, et chaque passage a produit son effet. Ce n'est pas un bug de n8n : c'est une propriété normale des systèmes qui s'échangent des événements, qu'il faut prévoir dans la conception.

Cet article explique d'où viennent les doublons, ce que fait le nœud Remove Duplicates de n8n, et comment construire une protection qui tient quand un événement est rejoué ou reçu en parallèle. Les faits sur n8n et Stripe viennent de leur documentation officielle, citée en fin d'article ; les recommandations sont notre analyse, à adapter à votre contexte.

D'où viennent les doublons

Trois situations reviennent souvent.

• Le service émetteur renvoie l'événement. Stripe l'écrit dans sa documentation : un endpoint de webhook peut occasionnellement recevoir le même événement plusieurs fois. Stripe tente aussi de livrer un événement pendant jusqu'à trois jours, avec un délai croissant entre les essais, en mode réel, si votre endpoint ne répond pas avec un code de succès (2xx). Un workflow trop lent à répondre s'expose donc à des rejeux.
• Deux événements distincts décrivent la même chose. Stripe précise que, dans certains cas, deux objets événement différents sont générés. Pour les repérer, la documentation recommande de comparer l'identifiant de l'objet contenu dans data.object et le type de l'événement.
• Votre propre planification relit les mêmes données. Un workflow déclenché toutes les heures qui relit « les commandes récentes » traite à nouveau celles de l'heure précédente si rien ne mémorise ce qui a déjà été vu.

Dans tous ces cas, la solution n'est pas d'espérer que l'événement n'arrive qu'une fois, mais de rendre le traitement idempotent : le rejouer ne doit pas répéter l'effet.

Ce que fait le nœud Remove Duplicates

Le nœud Remove Duplicates de n8n propose trois opérations, d'après la documentation. Sa documentation précise qu'il a été refondu dans la version 1.64.0.

Opération	Ce qu'elle fait
Remove Items Repeated Within Current Input	Supprime les doublons présents dans les éléments reçus à cette exécution, en comparant tous les champs ou une sélection
Remove Items Processed in Previous Executions	Compare les éléments reçus à ceux des exécutions précédentes, et ne garde que ceux qui n'ont pas déjà été vus
Clear Deduplication History	Vide la mémoire des éléments déjà traités

Le premier cas règle les doublons à l'intérieur d'un même lot, par exemple deux lignes identiques dans un tableau lu. Le deuxième cas est celui qui protège d'un rejeu entre deux exécutions.

Le critère de comparaison

Pour l'opération « exécutions précédentes », le paramètre Keep Items Where définit ce qui compte comme « nouveau » :

• Value Is New : l'élément est conservé si sa valeur n'a jamais été vue. C'est le bon choix avec un identifiant unique, comme l'identifiant d'un événement ou d'une commande.
• Value Is Higher than Any Previous Value : l'élément est conservé si sa valeur dépasse toutes les précédentes, utile pour un compteur croissant.
• Value Is a Date Later than Any Previous Date : l'élément est conservé si sa date est postérieure à toutes celles déjà vues, au format ISO.

Le champ Value to Dedupe On désigne ce qui sert de clé : un champ, ou une combinaison de champs qui forme un identifiant unique.

La portée et la taille de l'historique

Deux options méritent l'attention.

• Scope : avec la valeur Node (par défaut), l'historique est propre à ce nœud. Avec Workflow, il est partagé avec les autres nœuds Remove Duplicates du workflow réglés sur cette portée. Choisissez Workflow si plusieurs branches doivent s'accorder sur ce qui a déjà été traité.
• History Size (avec Value Is New) : la documentation indique que n8n conserve par défaut 10 000 éléments pour détecter les doublons. Si votre volume dépasse ce nombre sur la période où un rejeu est possible, ajustez ce réglage et vérifiez le comportement sur votre version.

Pour repartir de zéro, par exemple après un changement de format d'identifiant, l'opération Clear Deduplication History supprime les données stockées pour la portée choisie.

Mettre en place la protection sur un webhook

Voici une construction simple pour un workflow déclenché par un webhook, avec un identifiant d'événement.

1. Répondre vite. Dans le nœud Webhook, l'option de réponse « Immediately » renvoie le code de succès et le message « Workflow got started » sans attendre la fin du workflow. Stripe demande de renvoyer un code 2xx avant toute logique complexe, justement pour éviter les dépassements de délai qui déclenchent des rejeux. Si l'émetteur attend une réponse qui dépend du traitement, utilisez le nœud Respond to Webhook, en veillant à ce que l'ensemble reste rapide.
2. Vérifier l'authenticité. Un événement rejoué par un tiers malveillant produit aussi un doublon. Notre article sur la signature HMAC des webhooks n8n détaille cette étape.
3. Dédupliquer sur l'identifiant de l'événement. Placez un nœud Remove Duplicates avec l'opération « Processed in Previous Executions », le critère Value Is New et l'identifiant de l'événement comme clé. Les éléments déjà vus sortent par la branche des éléments retirés, que vous laissez sans suite.
4. Exécuter l'effet. Seuls les éléments conservés poursuivent vers l'envoi d'e-mail, la création de facture ou l'écriture dans le CRM.

Le choix de la clé est déterminant. Un identifiant d'événement fourni par l'émetteur est préférable à une valeur calculée par vos soins. À défaut, combinez des champs qui identifient réellement l'objet, par exemple l'identifiant de l'objet et le type d'événement, comme le recommande Stripe pour les événements en double.

Les limites à connaître

Remove Duplicates réduit fortement les doublons, mais ne remplace pas tout.

• Deux exécutions simultanées. Si le même événement arrive deux fois à quelques millisecondes d'écart, chaque exécution peut interroger l'historique avant que l'autre n'y ait écrit. La documentation du nœud ne décrit pas ce cas : testez-le en envoyant deux fois le même événement en parallèle avant de vous y fier, et prévoyez un garde-fou côté système cible si l'enjeu est élevé (facturation, expédition), par exemple une contrainte d'unicité dans la base de destination. Notre article sur le mode queue et les workers explique pourquoi la concurrence augmente avec le passage à l'échelle.
• L'effet partiel. Si une exécution échoue après le nœud de déduplication mais avant l'effet, l'événement a peut-être déjà été enregistré comme vu : vérifiez ce comportement sur votre version en provoquant une erreur volontaire, et décidez ce que vous voulez dans ce cas, avec l'alerte qui vous prévient : voir notre article sur la gestion des erreurs avec Error Trigger.
• L'ordre des événements. Stripe indique ne pas garantir l'ordre de livraison des événements. Un workflow qui suppose « création avant paiement » doit pouvoir gérer l'inverse, par exemple en relisant l'objet auprès de l'API.
• Le volume d'historique. Au-delà de la taille conservée, la mémoire n'est plus illimitée : dimensionnez-la par rapport à la fenêtre de rejeu réelle.

Les erreurs fréquentes

• Dédupliquer sur un champ qui change (horodatage de réception, par exemple) : chaque rejeu paraît nouveau.
• Dédupliquer trop tard, après l'envoi de l'e-mail ou la création de l'objet : le doublon est déjà produit.
• Vérifier avec un seul test séquentiel et conclure que tout fonctionne, sans essayer deux envois simultanés.
• Ne pas répondre rapidement au webhook, ce qui provoque soi-même les rejeux qu'on cherche à filtrer.
• Vider l'historique sans y penser : après un Clear Deduplication History, les anciens événements rejoués redeviennent nouveaux.

Un test simple avant la mise en production

Avant d'activer le workflow, envoyez deux fois de suite le même événement de test, puis deux fois en parallèle. Contrôlez le nombre d'effets obtenus : un seul e-mail, une seule ligne créée. Vérifiez ensuite que l'événement suivant, bien différent, passe normalement. Ce test de quelques minutes évite la plupart des mauvaises surprises.

Besoin d'automatisations qui ne se répètent pas ?

Vos workflows n8n créent des doublons dans vos outils, ou vous n'êtes pas sûr de ce qui se passe quand un événement est rejoué ? Décrivez-nous votre situation : nous identifions les points où un rejeu produit un effet, mettons en place la déduplication adaptée à vos volumes et ajoutons l'alerte qui manquait. Nos offres détaillent les formats d'accompagnement, et vous pouvez nous contacter directement.

Sources

• n8n, Remove Duplicates node, documentation consultée le 26 octobre 2026.
• n8n, Webhook node, documentation consultée le 26 octobre 2026.
• Stripe, Receive Stripe events in your webhook endpoint, documentation consultée le 26 octobre 2026 : sections « Handle duplicate events », « Automatic retries », « Event ordering » et « Quickly return a 2xx response ».