Identity resolution mailbot : personnaliser sans se tromper

N2 : le moment où “Bonjour” devient un incident potentiel

En N1, un mailbot classe et répond avec des templates. Il peut se tromper, c’est rarement dramatique : au pire, vous demandez une info de plus.

En N2, vous faites autre chose :

• vous rattachez un e-mail à une identité,
• vous consultez des données internes (contrat, sinistre, factures, historique),
• vous déclenchez éventuellement des actions backoffice.

Et là, une erreur d’identité n’est plus une “erreur de ton”. C’est :

• un risque de confidentialité (“vous avez envoyé des infos au mauvais destinataire”),
• un risque financier (remboursement, résiliation),
• un risque réputationnel (le client vous le rappellera avec enthousiasme),
• un risque réglementaire (selon votre secteur).

Identity resolution : définition (propre) + version terrain (utile)

Définition

Identity resolution = processus qui relie un signal entrant (e-mail + thread + pièces jointes) à une entité interne (personne, organisation, compte, contrat, dossier) avec un score de confiance, puis applique une politique d’action.

Version terrain

C’est le moment où votre mailbot arrête d’être “un écrivain” et devient “un enquêteur” :

• “cet e-mail correspond-il à ce client ?”
• “ce numéro de contrat dans le PDF est-il valide ?”
• “si deux personnes partagent la même adresse mail (oui, ça existe), qui est le bon ?”
• “est-ce que le client est en train de changer son RIB, ou de signaler un sinistre ?”

Et, surtout : “est-ce que j’ai le droit d’agir avec ces informations ?”

Les signaux d’identité : du solide, du mou, et du franchement trompeur

On peut classer les signaux d’identité en trois catégories. Cette taxonomie simplifie énormément les décisions.

Le piège : “l’adresse e-mail = l’identité”

Dans un monde parfait, une adresse e-mail correspond à une personne unique. Dans le monde réel :

• des boîtes partagées (contact@, sinistre@),
• des adresses recyclées,
• des alias,
• des délégations (assistante, conjoint, courtier),
• et des forwards.

Donc oui : l’e-mail est un signal utile. Mais ce n’est pas un passeport.

Pipeline N2 : proposer un match, puis le mériter

Architecture robuste (et surtout expliquable) :

1. extraction structurée (entités),
2. recherche/match (candidats),
3. scoring + règles,
4. décision (auto / ask / step‑up / HITL),
5. réponse + actions backoffice (si autorisé),
6. traçabilité + apprentissage.

1

Extraire les entités (mail + pièces jointes)

Le modèle aide à extraire : nom, numéro de contrat, référence facture, immatriculation, adresse, IBAN, etc. Les pièces jointes passent par OCR/VLM selon le format.

2

Générer une liste de candidats

Interrogez CRM/MDM : correspondances exactes (IDs), puis fuzzy (nom+date), puis heuristiques (domaine, historique du thread).

3

Scorer et expliquer

Calculez un score : signaux forts + cohérence + fraîcheur. Gardez une explication (pour HITL et audit).

4

Décider selon le risque

Faible risque : auto. Risque moyen : demander une info. Risque élevé : step‑up + HITL. Ici, la policy est plus importante que le modèle.

5

Exécuter via tools (idempotents)

Si action backoffice : tool calling, validations métier, idempotency keys, audit logs. Le modèle ne “clique” jamais directement.

6

Apprendre (sans trahir la privacy)

Les corrections HITL alimentent la qualité : règles, datasets de matching, cas limites. Enregistrements minimisés, pseudonymisation si nécessaire, et TTL raisonnable.

Seuils et calibration : décider sans se mentir

Un score de confiance, c’est utile… à condition de savoir ce qu’il signifie.

Deux erreurs fréquentes :

• un score “magique” (0,87) sans calibration,
• un seuil unique pour toutes les actions (on traite une résiliation comme une création de ticket).

La bonne pratique :

• un seuil par classe de risque (lecture, écriture réversible, écriture sensible),
• une catégorie “je ne sais pas” explicite (unknown/ambiguous),
• un passage en ask / step-up / HITL quand on est sous le seuil.

Dernier détail qui change tout : mesurez vos seuils. Combien de confirmations ? Combien d’escalades ? Combien de corrections HITL ? Ajustez ensuite. C’est une optimisation produit, pas une décision “IA”.

Matching : déterministe vs probabiliste (et pourquoi vous voulez les deux)

Déterministe : quand vous avez une clé

Exemples :

• le client fournit un numéro de contrat exact,
• le mail vient d’une adresse déjà vérifiée,
• le thread contient une référence interne.

Avantage : rapide, explicable.

Limite : le monde réel n’est pas toujours aussi poli.

Probabiliste : quand vous assemblez des indices

Signaux “faibles” qui, ensemble, deviennent forts :

• nom+prénom + code postal,
• historique de conversation,
• mention d’un sinistre déjà ouvert,
• cohérence des pièces jointes (référence facture).

Deux approches :

• règles/heuristiques (souvent le meilleur ROI),
• modèles/embeddings (pratiques quand les champs sont bruités).

Golden record : le rêve… et le budget caché

Le N2 révèle une vérité simple : vos données clients ne sont pas “unifiées”. Elles sont “optimistes”.

Le concept de golden record (MDM) consiste à maintenir une version “réconciliée” d’une entité : la “meilleure vérité” disponible.

Dans un mailbot N2, le golden record devient la base pour :

• personnaliser sans incohérence (nom, langue, formule),
• éviter les doublons (deux dossiers pour la même personne),
• sécuriser les actions (bon contrat, bon statut).

Le piège : merger trop vite

Un mauvais golden record fait l’inverse du bien :

• il fusionne des personnes différentes,
• puis il distribue des infos au mauvais endroit,
• et vous passez votre temps à “dés-fusionner”.

Donc : merge avec prudence, et gardez une trace.

Hygiène data : le N2 ne peut pas compenser un CRM “créatif”

J’ai une mauvaise nouvelle : l’IA ne “nettoie” pas la dette data par magie. Elle peut la masquer… jusqu’au jour où elle la révèle.

Quelques problèmes classiques qui sabotent l’identity resolution :

• des noms stockés en majuscules, en minuscules, ou avec des accents aléatoires,
• des dates au format libre (“03/05/26” = le 3 mai ou le 5 mars ?),
• des numéros de contrat avec des espaces/traits/zeros non significatifs,
• des adresses e-mail avec des alias (+tag) ou des variations,
• et des champs “notes” qui contiennent des infos critiques… non structurées.

La parade :

• normaliser (trim, casse, accents, ponctuation),
• canonicaliser les identifiants (contrat, sinistre, facture),
• valider les formats (e-mail, IBAN, dates),
• et stocker la valeur “raw” + “normalized” pour ne pas perdre l’original.

Oui, c’est boring. Et oui, c’est exactement ce qui fait monter votre match rate.

Thread hijacking : quand l’identité “glisse” dans un fil

Autre cas sournois : l’identité ne se trompe pas parce que votre matching est mauvais… mais parce que le thread est devenu ambigu.

Ça arrive quand :

• un client forwarde l’e-mail à quelqu’un (“tu peux gérer ?”),
• une équipe répond depuis une boîte partagée,
• un Reply-To étrange redirige les réponses,
• ou un interlocuteur “s’invite” dans la conversation (courtier, conjoint, collègue).

Un mailbot N2 doit donc raisonner sur qui écrit et qui est concerné.

Les cas limites qui ruinent les jolis schémas (et comment les dompter)

En N2, les cas limites reviennent en boucle :

• boîtes partagées (contact@, compta@),
• délégations (assistant(e), conjoint, gestionnaire),
• courtiers : l’adresse est celle d’un pro, l’objet est un dossier assuré,
• homonymes et infos manquantes,
• multi-contrats (un client, plusieurs produits).

Le bon réflexe n’est pas d’être héroïque. C’est d’être précis sur ce qu’on sait.

Ces cas ne se résolvent pas avec un meilleur prompt. Ils se résolvent avec :

• une policy (quand demander une preuve),
• une UI de revue (HITL qui tranche vite),
• des parcours (step-up, formulaire) qui capturent l’identifiant manquant.

Personnalisation : l’art de ne pas devenir creepy

La personnalisation “N2” n’est pas “mettre le prénom”.

C’est :

• reconnaître le contexte (“vous aviez ouvert un dossier hier”),
• adapter la réponse (garanties, procédure),
• faire gagner du temps (pré-remplir, lister les pièces manquantes).

Pattern robuste : template + slots + preuves

Au lieu de laisser un LLM écrire librement :

• template (structure stable),
• slots (variables : contrat, statut),
• preuves (CRM, ticket, pièce jointe).

Résultat : ton cohérent, moins d’hallucination, revue HITL plus simple.

Step-up : plus l’action est sensible, plus il faut une preuve forte

On ne change pas un RIB sur un simple e-mail, même si le ton est convaincant.

Vous avez besoin d’un mécanisme de step‑up :

• lien vers espace authentifié,
• OTP,
• signature électronique,
• intervention humaine.

Les guides d’identité numérique (comme NIST SP 800‑63B) documentent précisément l’idée d’augmenter le niveau d’assurance selon le risque.¹

Privacy-by-design : minimiser, séparer, tracer

Le N2 manipule des données personnelles. Trois pratiques rendent le système plus simple :

1. minimisation : ne chargez pas tout le profil,
2. séparation : si pseudonymisation, gardez la ré‑identification séparée,
3. traçabilité : décisions loggées (avec parcimonie) et rejouables.

L’EDPB a publié des lignes directrices sur la pseudonymisation et ses implications.²

Cas d’usage : assurance (où N2 devient une arme… ou un risque)

En assurance, l’identité est rarement “juste un contact”. C’est :

• un contrat,
• un dossier sinistre,
• un statut,
• parfois plusieurs assurés sur le même contrat.

Exemple : “je renvoie la facture, remboursez-moi”.

Le N2 doit :

1. rattacher au bon contrat,
2. lire la facture (OCR/VLM),
3. vérifier les garanties,
4. demander step‑up si nécessaire,
5. déclencher action backoffice (ou escalader).

La personnalisation n’est pas “bonjour Pierre”. C’est “voici ce qu’il manque, voici le délai, voici le statut”.

Conclusion : un N2 robuste préfère la prudence au spectacle

L’identity resolution n’est pas une feature “IA”.

C’est un système :

• extraction structurée,
• matching (déterministe + probabiliste),
• scoring explicable,
• step‑up selon le risque,
• HITL quand c’est ambigu,
• audit/replay.

Faites ça bien, et votre mailbot N2 peut répondre vite, agir proprement, et augmenter la satisfaction.

Faites ça vite, et vous construisez un mailbot qui confond des gens — ce qui est une façon moderne de fabriquer des incidents.

Checklist “identity-ready”

• Signaux forts identifiés (IDs, contrat, liens authentifiés)
• Matching multi-source (CRM + dossiers + historiques)
• Score + explication (pas seulement un chiffre)
• Step‑up selon le risque (actions sensibles)
• HITL sur ambiguïté + demandes irréversibles
• Logs minimisés + replay (debug + audit)

FAQ

Questions frequentes

Peut-on faire du N2 uniquement avec un LLM ?+

Vous pouvez tenter, mais vous perdez le contrôle. Le LLM aide à extraire et à raisonner, mais l’identité et les actions doivent être encadrées par des règles, un scoring, et du tool calling sécurisé.

Quand demander un step-up ?+

Dès que l’action est sensible (coordonnées bancaires, résiliation, paiement) ou que l’identité est ambiguë. Le step‑up est un mécanisme de sécurité et de confiance, pas un échec du mailbot.

Comment éviter de devenir creepy en personnalisation ?+

Utilisez des informations utiles au dossier (statut, pièces manquantes, délais) et évitez d’exposer des détails inutiles. Template + slots + preuves = personnalisation utile, pas intrusive.

Sources et references

1. [1]NIST — SP 800-63B : Digital Identity Guidelines (Authentication and Lifecycle Management) :
2. [2]EDPB — Guidelines 01/2025 on Pseudonymisation (consultation) :