Supprimer les doublons dans n8n : le node Remove Duplicates et sa mémoire entre exécutions

Les doublons sont la maladie chronique des workflows : un flux RSS qui renvoie les mêmes articles à chaque lecture, un webhook rejoué, un export qui chevauche le précédent, deux sources qui citent le même contact. Et chaque doublon non intercepté coûte — un appel IA payé deux fois, un email envoyé deux fois, une ligne dupliquée en base. n8n consacre un node entier au problème, Remove Duplicates, dont la fonction la plus précieuse est aussi la moins connue : une mémoire persistante entre exécutions. Ce guide couvre ses trois opérations, ses pièges, et les cas où une autre stratégie le remplace avantageusement.

Opération 1 — Dédupliquer au sein de l'exécution courante

« Remove Items Repeated Within Current Input » compare les items du flux entre eux et ne garde qu'un exemplaire de chaque. Trois modes de comparaison :

• All Fields : deux items identiques champ pour champ sont des doublons ;
• All Fields Except : ignorer les champs parasites (horodatage de collecte, ID technique) qui rendraient chaque item faussement unique ;
• Selected Fields : ne comparer que les champs discriminants — email pour des contacts, url pour des articles.

C'est l'outil du cas « deux sources fusionnées » : après un node Merge qui rassemble des listes venues d'Airtable et d'un CSV, un Remove Duplicates sur l'email nettoie la réunion. Piège classique : la comparaison est exacte. « Dupont » et « dupont » (avec majuscule et espace final) sont deux valeurs distinctes — normalisez en amont dans un node Edit Fields (.toLowerCase().trim()) avant de comparer.

Opération 2 — La mémoire entre exécutions : « Remove Items Processed in Previous Executions »

La fonction qui change tout pour les workflows planifiés : n8n mémorise dans sa base de données les valeurs déjà rencontrées, d'une exécution à l'autre. Vous désignez un champ clé, et trois modes s'offrent :

• Value Is New : ne passe que si la clé n'a jamais été vue — le mode universel (URL d'article, ID de commande, email) ;
• Value Is Higher than Any Previous Value : pour les curseurs croissants — ID auto-incrémenté, numéro de facture — n8n ne retient que le maximum vu, plus économe qu'une liste ;
• Value Is a Date Later than Any Previous Date : même logique sur un horodatage (updated_at).

C'est le node qui rend triviale la veille RSS (« quels articles sont nouveaux depuis hier ? »), le polling d'une API sans paramètre since fiable, ou la reprise incrémentale d'une table. L'option History Size borne le nombre de valeurs conservées en mode « Value Is New » : dimensionnez-la au-delà du nombre d'items qu'un flux peut raisonnablement renvoyer entre deux passages, sinon les plus anciennes valeurs sortent de la mémoire et réapparaissent en « nouveautés ».

Deux propriétés à connaître absolument : l'historique est propre à chaque node (deux Remove Duplicates ne partagent rien, même configurés à l'identique), et il survit aux redémarrages puisqu'il vit dans la base n8n — mais pas à un changement de champ clé, qui repart de zéro. Après des tests, pensez à l'opération « Clear Deduplication History » du même node : sans ce nettoyage, les valeurs vues pendant les tests trouent silencieusement la production.

Ce que Remove Duplicates ne règle pas

Le node déduplique ce qui passe par lui. Trois angles morts, chacun avec sa parade :

• Le webhook rejoué : deux livraisons du même événement arrivent dans deux exécutions simultanées — la seconde peut passer avant que la première n'ait écrit son historique. Pour les webhooks, la vraie réponse est la clé d'idempotence vérifiée en base, atomique par construction ;
• Le doublon déjà en base : Remove Duplicates ne connaît que son historique, pas l'état de votre CRM. La garantie finale est l'upsert sur clé unique côté destination — INSERT ... ON CONFLICT en Postgres, upsert par External ID dans Salesforce, recherche-avant-écriture dans HubSpot/Pipedrive ;
• Le doublon approximatif : « Jean Dupont / jean.dupont@ » et « J. Dupont / jdupont@ » désignent la même personne, mais aucune égalité de champ ne le dira. C'est le territoire du record linkage — normalisation agressive, comparaison floue, voire jugement par LLM sur les paires candidates. Le sujet est un champ de recherche à part entière : la synthèse de référence d'Ahmed Elmagarmid, Panagiotis Ipeirotis et Vassilios Verykios, « Duplicate Record Detection: A Survey » (IEEE Transactions on Knowledge and Data Engineering, 2007, voir sur Google Scholar), cartographie ces techniques de détection de doublons non identiques — et rappelle utilement qu'aucune méthode exacte ne les attrape tous.

En pratique, l'architecture saine superpose les niveaux : dédupliquer tôt dans n8n pour ne pas retraiter ni repayer (chaque doublon écarté avant un appel IA est un appel économisé), verrouiller en base pour l'intégrité finale.

Les alternatives selon le contexte

• Node Code : pour une logique de doublon vraiment spécifique (fenêtre glissante, doublon « au sens métier »), un Set JavaScript sur la clé calculée fait l'affaire en dix lignes — voir expressions et node Code ;
• SQL à la source : si les données viennent d'une base, un SELECT DISTINCT ON (...) ou un GROUP BY déduplique avant même d'entrer dans n8n — toujours moins cher que de transporter des doublons ;
• Comparaison de datasets : le node Compare Datasets identifie ajouts, suppressions et modifications entre deux listes — quand la question n'est plus « quels doublons ? » mais « qu'est-ce qui a changé ? ».

En résumé

Remove Duplicates a deux visages : nettoyeur d'une exécution (comparaison sur les champs choisis, après normalisation) et mémoire entre exécutions (« Value Is New » sur une clé stable, History Size bien dimensionné, historique purgeable). Il économise les retraitements et les appels payants ; il ne remplace ni la clé d'idempotence pour les webhooks concurrents, ni l'upsert en base pour l'intégrité finale, ni le record linkage pour les doublons approximatifs. Superposez les trois niveaux et les doublons cessent d'être une fatalité pour devenir un cas géré.