Éviter les doublons dans n8n : identifiants, déduplication et reprises

Un formulaire est envoyé deux fois. Un événement est rejoué après une coupure. Vous relancez une exécution échouée. Dans chacun de ces cas, une automatisation peut créer deux lignes ou envoyer deux notifications pour la même opération.

Éviter les doublons commence par définir ce qui doit être unique. Ajouter un filtre sans réfléchir à cette règle risque de supprimer des événements légitimes. Ce guide propose une méthode de conception et un scénario de validation ; il ne décrit pas un workflow ayant été exécuté sur votre instance.

Distinguer un doublon d’une nouvelle information

Deux événements concernant la même commande ne sont pas forcément identiques. « Commande créée » et « commande expédiée » sont deux événements utiles, même si leur numéro de commande est le même.

Choisissez donc une clé adaptée à l’action : l’identifiant d’événement fourni par le service, ou une combinaison du type d’événement et de l’identifiant métier. Évitez les noms de personnes et les heures de réception : les premiers ne sont pas uniques, les secondes changent lors d’un renvoi.

Exemple illustratif Pour une notification de commande, la clé fictive commande-creee:CMD-204 identifie l’action attendue. commande-expediee:CMD-204 correspond à une autre action et doit pouvoir passer.

Si un identifiant manque, dirigez l’élément vers une branche de contrôle. Traiter une clé vide comme une clé normale peut faire considérer des événements sans rapport comme identiques.

Comprendre les deux filtres de n8n

Le nœud Remove Duplicates distingue les répétitions dans les données de l’exécution actuelle et les éléments déjà rencontrés lors d’exécutions précédentes. Le premier mode ne suffit donc pas à arrêter deux appels séparés d’un webhook.

La documentation décrit notamment les opérations « Remove Items Repeated Within Current Input » et « Remove Items Processed in Previous Executions ». Pour comparer une clé déjà reçue, le second mode propose la logique « Value Is New ». Vérifiez les libellés dans votre version.

Sur un flux de notifications peu critique, vous pouvez préparer une structure de ce type :

Réception de l’événement
→ Vérification des champs obligatoires
→ Construction de la clé de déduplication
→ Filtrage des clés déjà rencontrées
→ Action attendue

C’est une protection pratique, avec une mémoire limitée. Elle ne constitue pas une garantie générale qu’une action distante se produira exactement une fois.

Prévoir l’échec après le filtrage

Supposons que le filtre accepte un événement, puis que le service de messagerie soit indisponible. À la tentative suivante, la clé peut déjà figurer dans l’historique : la notification risque alors d’être bloquée.

La question à résoudre est donc aussi : comment sait-on que l’action a réellement abouti ? Pour un traitement important, conservez un état durable : reçu, en cours, terminé ou échoué. Un événement déjà terminé peut être ignoré ; un événement échoué doit suivre une procédure de reprise explicite.

Quand l’API destinataire propose une clé d’idempotence, utilisez une clé stable conforme à sa documentation. Cette fonction permet au destinataire de reconnaître certaines requêtes répétées. Son comportement et sa durée de conservation dépendent du service.

Tenir compte des exécutions simultanées

Un simple scénario « rechercher la clé, puis créer la ligne si elle manque » comporte une course : deux exécutions peuvent faire la recherche avant que l’une écrive.

Pour un registre en base de données, une contrainte d’unicité sur la clé empêche deux lignes portant cette clé. Il faut aussi gérer le conflit d’insertion dans le workflow. Cette contrainte protège le registre ; elle ne rend pas automatiquement atomique l’ensemble « enregistrer puis appeler un autre service ».

Les workflows de facturation ou d’autres actions difficiles à annuler demandent donc une conception plus complète qu’un nœud de filtrage. Commencez par un journal de traitement et une stratégie de reprise avant d’activer ces actions.

Valider avec quatre scénarios

Utilisez des données fictives et une destination de test.

Scénario	Résultat attendu
Même événement reçu deux fois	Une seule action réussie
Deux événements différents pour une commande	Les deux actions prévues
Échec temporaire du destinataire	Échec visible et reprise possible
Deux réceptions simultanées	Aucun doublon dans le registre unique

Inspectez l’historique des exécutions n8n et le résultat dans le service destinataire. Le succès affiché par un nœud ne remplace pas ce dernier contrôle.

Enfin, documentez la durée de conservation des clés et les conséquences d’un effacement de l’historique. Pour comprendre pourquoi les événements arrivent séparément, commencez par notre explication des webhooks.