Détecter les doublons approximatifs dans n8n avec des embeddings

Le node Remove Duplicates de n8n, couvert dans notre guide dédié, règle la grande majorité des doublons stricts — mais il a une limite structurelle : sa comparaison est exacte. Deux fiches « Jean Dupont, jean.dupont@acme.fr » et « J. Dupont, jdupont@acme.fr » désignent presque certainement la même personne, et pourtant aucun champ n'est identique. Ce sont des doublons approximatifs (ou quasi-doublons), et ils prolifèrent partout où des données viennent de sources multiples : formulaires web, imports CSV, CRM synchronisés, avis clients recopiés à la main. Ce guide montre comment les repérer dans n8n avec des embeddings, la même technologie déjà utilisée sur ce blog pour le RAG documentaire et le cache sémantique.

Où le matching exact échoue

Le matching exact — même normalisé en minuscules et sans espaces superflus — reste aveugle à trois familles de variations très courantes :

• Fautes de frappe et de saisie : « Martn » pour « Martin », un email mal recopié depuis une carte de visite ;
• Variantes d'écriture légitimes : « Société Générale » vs « SG » vs « Societe Generale SA », un même contact avec ou sans particule ;
• Reformulations : deux tickets support qui décrivent le même bug avec des mots différents, deux avis clients qui expriment la même plainte sans partager un seul champ identique.

Dans ces trois cas, il faut comparer non pas des chaînes de caractères, mais un sens — exactement le problème que les embeddings résolvent déjà pour la recherche documentaire.

Le principe : embeddings et similarité cosinus

Le principe reprend celui du cache sémantique déjà décrit sur ce blog, appliqué à des fiches plutôt qu'à des questions :

1. Les champs discriminants d'une fiche (nom, email, entreprise, ou le texte d'un ticket) sont concaténés en une chaîne courte.
2. Cette chaîne est transformée en embedding via un modèle comme text-embedding-3-small — voir notre guide de choix de modèle d'embeddings pour arbitrer entre coût, qualité et hébergement.
3. Le vecteur obtenu est comparé par similarité cosinus à ceux déjà indexés pour les fiches existantes.
4. Au-dessus d'un seuil, la nouvelle fiche est traitée comme un doublon probable ; en dessous, elle est insérée normalement et son vecteur vient enrichir l'index pour les comparaisons futures.

Cette approche s'appuie sur des travaux bien établis en traitement du langage. L'article de Nils Reimers et Iryna Gurevych, Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks (EMNLP, 2019), montre que la similarité cosinus entre embeddings de phrases produits par un modèle entraîné pour cet usage reflète fidèlement le jugement humain de proximité sémantique — c'est exactement ce qu'on exploite ici pour rapprocher deux fiches formulées différemment. Sur le terrain plus spécifique de l'appariement de fiches (entity matching), Sidharth Mudgal et ses coauteurs, dans Deep Learning for Entity Matching: A Design Space Exploration (SIGMOD, 2018), comparent systématiquement des architectures à base d'embeddings aux méthodes classiques de dédoublonnage et confirment leur avantage net sur les données textuelles bruitées — le cas typique d'un CRM alimenté par plusieurs sources.

Construire le pipeline dans n8n

Le workflow s'insère avant l'écriture en base, sur le flux d'ingestion d'un lead, d'un contact ou d'un ticket :

1. Trigger — webhook de formulaire, node Google Sheets/Airtable en polling, ou email entrant.
2. Node Edit Fields — normalisation basique (minuscules, suppression des espaces superflus) et concaténation des champs clés en une seule chaîne (${nom} ${email} ${entreprise}).
3. Node Embeddings — vectorisation de cette chaîne.
4. Recherche vectorielle (KNN) — requête sur l'index existant (pgvector ou Qdrant, voir plus bas) pour récupérer le ou les candidats les plus proches et leur score.
5. Node If / Switch à trois branches selon le score :
   • Au-dessus du seuil haut → doublon quasi certain : la fiche est fusionnée ou rejetée automatiquement, comme documenté dans notre article sur les CRM synchronisés ;
   • Zone grise → score ambigu : envoi vers une approbation humaine via Slack avant décision ;
   • En dessous du seuil bas → nouvelle fiche : insertion en base et indexation de son embedding pour les comparaisons suivantes.

Ce filtrage vectoriel intervient en aval d'un premier tri exact et bon marché : normalisation stricte de l'email ou du domaine, comparable au node Remove Duplicates déjà en place. Réserver la recherche vectorielle — plus coûteuse en calcul et en appels API — aux fiches qui survivent à ce premier filtre garde le pipeline rapide sur le volume, tout en captant les cas fins.

Où stocker et interroger les vecteurs

Deux options couvrent la majorité des cas déjà documentés sur ce blog. Pour une infrastructure déjà bâtie autour de Supabase, pgvector avec un index HNSW répond en quelques millisecondes même sur plusieurs centaines de milliers de fiches, et cohabite naturellement avec les autres tables (contacts, tickets, commandes). Pour un volume plus élevé ou une isolation dédiée à la recherche vectorielle, Qdrant offre un filtrage par métadonnées plus riche — utile pour ne comparer, par exemple, que les fiches d'un même client dans un contexte multi-tenant. Dans les deux cas, l'id de la fiche source doit être stocké aux côtés du vecteur, pour remonter directement à l'enregistrement complet une fois un candidat trouvé.

Calibrer le seuil : plus délicat que pour un cache sémantique

Sur un cache sémantique de questions-réponses, un seuil trop permissif fait au pire répondre à côté. Ici, un seuil trop permissif fusionne deux personnes ou deux entreprises distinctes — une erreur bien plus coûteuse à corriger a posteriori dans un CRM. À l'inverse, un seuil trop strict laisse passer les vrais doublons qu'on cherchait justement à intercepter.

Un point de départ raisonnable se situe entre 0,88 et 0,93, sensiblement plus bas que les 0,95-0,97 utilisés pour un cache de questions — car l'objectif ici est justement de capter les variantes orthographiques que le cache sémantique, lui, cherche à éviter de confondre. Constituez un petit échantillon de vrais doublons connus et de quasi-doublons trompeurs (deux collaborateurs différents d'une même entreprise, par exemple) et ajustez le seuil dessus avant tout déploiement, en suivant la même discipline de test que celle décrite dans notre article sur les évaluations n8n pour workflows IA.

Cas concret : dédupliquer des leads entrants

Une PME qui reçoit des leads depuis un formulaire web, un salon (import CSV) et un partenaire commercial (API) accumule vite des fiches qui désignent la même personne sous des formes différentes. Le pipeline décrit ici s'intercale naturellement dans le flux d'enrichissement automatique de leads ou de qualification par IA : avant d'enrichir et de scorer un lead, on vérifie s'il n'est pas déjà connu sous une autre forme. Le bénéfice est double — un commercial ne relance pas deux fois la même personne, et les métriques de qualification ne sont pas polluées par des doublons qui gonflent artificiellement le volume.

Pièges fréquents

• Concaténer trop de bruit dans le texte embeddé : inclure un ID technique ou un horodatage dans la chaîne vectorisée dilue le signal utile et fausse la similarité — ne gardez que les champs réellement discriminants.
• Un seul candidat comparé : chercher uniquement le voisin le plus proche (top-1) masque les cas où deux ou trois fiches existantes sont toutes plausibles ; récupérer les 3 à 5 meilleurs candidats donne un contexte bien plus sûr pour la décision, humaine ou automatique.
• Ignorer le changement de modèle d'embeddings : comme pour un pipeline RAG classique, changer de modèle invalide les vecteurs déjà indexés — il faut ré-embedder tout l'historique, pas seulement les nouvelles fiches.
• Fusionner sans trace : conserver l'identifiant de la fiche fusionnée (et le score qui a motivé la fusion) permet de revenir en arrière en cas d'erreur — une fusion silencieuse et irréversible est le pire scénario en cas de faux positif.

Pour aller plus loin

L'infrastructure de vectorisation décrite ici — modèle d'embeddings, index pgvector, recherche par similarité — est la même que celle mise en place dans le Pack Assistant RAG (119 €) pour l'ingestion documentaire : une fois ce socle en place pour un cas d'usage, il se réutilise directement pour la déduplication de leads, de contacts ou de tickets, sans nouvelle brique d'infrastructure à opérer. Si votre priorité immédiate est plutôt le tri et la priorisation des emails entrants, le Pack Inbox IA (79 €) couvre ce premier maillon avant même de se poser la question des doublons.