Séparer l’identité du contact et son adresse

Un identifiant contact sert à reconnaître la même fiche dans le temps. L’adresse e-mail sert à acheminer un message. Ces deux fonctions peuvent coïncider dans un petit fichier, mais les distinguer devient utile lorsque plusieurs outils échangent des informations.

La documentation de Twilio Segment recommande un identifiant utilisateur unique et stable, et déconseille d’utiliser une adresse e-mail changeante comme identifiant principal. Elle permet de conserver cette adresse comme attribut. Source : Twilio Segment, identification des utilisateurs.

Ce principe d’architecture ne vous oblige pas à relier toutes les activités d’une personne. Il peut simplement aider à corriger une adresse, conserver la cohérence des préférences et éviter qu’un import réintroduise des données anciennes.

Définir le périmètre avant de créer un numéro

Commencez par préciser ce que représente une fiche. Est-ce une personne, un compte d’entreprise, une adresse de contact ou une inscription à une publication ? Mélanger ces objets conduit à des rapprochements difficiles à expliquer.

Deux personnes peuvent participer à la même association. Une personne peut représenter deux organisations. Une boîte générique peut être consultée par plusieurs collègues. Votre modèle doit pouvoir accueillir ces situations sans prétendre que chaque adresse correspond nécessairement à une personne unique.

Nous proposons de documenter trois objets lorsqu’ils sont nécessaires : le contact, ses coordonnées et ses inscriptions. Gardez le modèle plus simple si votre usage ne demande pas cette distinction, mais notez clairement ses limites.

Choisir une source de référence par information

Une synchronisation fiable ne repose pas seulement sur un identifiant. Elle doit préciser qui a le droit de modifier chaque champ.

Information Règle de travail possible
Adresse actuelle Modification confirmée dans le parcours prévu
Préférences Dernier choix explicite applicable
Nom d’organisation Source métier désignée
Statut de désinscription Registre d’opposition de référence
Origine d’inscription Historique conservé, sans écrasement silencieux

Il s’agit d’un exemple de gouvernance à adapter. Évitez la règle générale « le dernier fichier importé gagne ». Un export récent peut contenir une information métier ancienne et contredire un choix exprimé entre-temps.

Pour chaque échange, conservez la distinction entre la date de transfert et la date de l’information. Elles répondent à deux questions différentes.

Organiser trois résultats possibles à l’import

Avant de charger un fichier dans l’outil d’envoi, préparez une simulation. Chaque ligne devrait conduire à une création, une mise à jour ou un conflit à examiner.

Une création signifie que le fichier propose un contact absent du référentiel retenu. Une mise à jour suppose que le rapprochement est suffisamment établi et que le champ peut être modifié par cette source. Un conflit signale qu’une décision humaine reste nécessaire.

Ne traitez pas les conflits comme des erreurs gênantes à faire disparaître rapidement. Ils révèlent souvent une ambiguïté utile : deux identifiants, une adresse partagée, un changement d’organisation ou une préférence contradictoire.

Exemple fictif : un atelier utilise deux outils

Imaginons un atelier qui gère ses inscriptions aux cours dans un outil et sa newsletter dans un autre. Une participante corrige son adresse dans le parcours d’inscription. Le fichier de newsletter contient encore l’ancienne adresse.

L’atelier retrouve le contact grâce à son identifiant interne. Il examine la modification et applique la nouvelle coordonnée selon la procédure prévue. Il ne crée pas automatiquement un deuxième abonnement et ne réinitialise pas les préférences.

Quelques semaines plus tard, un export ancien réapparaît. La simulation indique que l’adresse proposée est antérieure à la correction. L’équipe bloque l’écrasement et conserve la fiche actuelle.

Le résultat recherché est une relation cohérente. Cet exemple ne suppose pas de suivre les visites, les clics ou les ouvertures de la participante.

Rapprocher avec prudence

Une égalité approximative entre deux noms ne suffit pas toujours à établir une identité. Une orthographe proche peut désigner deux personnes différentes. À l’inverse, une même personne peut changer de nom ou employer une autre adresse.

Préparez des règles distinctes pour les cas certains et les cas à revoir. Un identifiant partagé entre outils peut permettre un rapprochement déterminé. Un nom similaire doit plutôt produire une proposition de vérification.

Évitez également les transformations agressives des adresses. Retirer arbitrairement des caractères ou modifier la partie située avant l’arobase peut réunir des coordonnées qui ne sont pas équivalentes dans le contexte utilisé. Documentez les normalisations appliquées et testez-les avec des cas fictifs.

Préserver les choix lors d’une fusion

Quand une fusion est justifiée, préparez le résultat avant de l’exécuter. Quelle adresse restera active ? Quel historique sera conservé ? Quelles inscriptions seront encore valides ? Comment les oppositions seront-elles reprises ?

Nous conseillons de produire un aperçu compréhensible des deux fiches et du résultat envisagé. La personne chargée de la décision doit pouvoir repérer une information qui serait perdue.

Conservez une trace de la décision de fusion, avec un accès adapté. Une fusion erronée peut être difficile à expliquer si votre équipe ne sait plus quelles fiches ont été rapprochées. Prévoir le retour arrière au moment de la conception évite de découvrir cette difficulté après un incident.

Contrôler la synchronisation avec des cas représentatifs

Créez un petit jeu de données fictives : changement d’adresse, prénom absent, opposition récente, boîte partagée et identifiant manquant. Exécutez le parcours complet et examinez le fichier qui serait utilisé pour l’envoi.

Comparez les volumes attendus de créations, de mises à jour et de conflits. Une différence doit entraîner une explication avant validation. Un compteur global « import réussi » ne décrit pas le sens des modifications.

Vous pourrez ensuite relire les mêmes cas après une évolution des règles. La qualité du référentiel dépend de décisions explicites et reproductibles, plus que du nombre de champs réunis dans une seule fiche.