Les erreurs de normalisation des e-mails peuvent provoquer des collisions de comptes. Découvrez ce qu'il est sûr de normaliser (et ce qu'il ne faut pas) pour les points, les +tags et la casse.
La normalisation d'e-mail consiste à récrire ce qu'un utilisateur a saisi pour obtenir une forme plus cohérente à stocker ou comparer, comme enlever les espaces ou mettre une partie en minuscules. Cela devient risqué quand la normalisation change l'identité, par exemple en supprimant des points ou en ôtant des +tags, car deux adresses différentes peuvent alors paraître identiques dans votre base.
Couper les espaces en début et fin et supprimer les caractères invisibles introduits par un copier-coller sont généralement sûrs parce qu'ils corrigent des artefacts d'entrée, pas l'identité. Mettre uniquement la partie domaine en minuscules est aussi généralement sans risque, car les domaines sont en pratique traités comme insensibles à la casse.
Mettre en minuscules la partie domaine est un bon choix par défaut. Mettre en minuscules la partie locale (avant @) est risqué parce que la norme autorise la sensibilité à la casse, et certains systèmes peuvent traiter [email protected] différemment de [email protected], même si beaucoup de fournisseurs ne le font pas.
Ne supprimez pas les points par défaut. Le comportement « point » de Gmail n'est pas universel, et de nombreux serveurs mail d'entreprise ou auto-hébergés considèrent les points comme significatifs. Ainsi [email protected] et [email protected] peuvent être des personnes différentes.
Ce n'est pas sûr comme règle globale. Beaucoup de fournisseurs livrent [email protected] à la même boîte que [email protected], mais d'autres considèrent la partie locale entière comme distincte, et des organisations peuvent router les messages différemment selon le tag.
Considérez les correspondances normalisées comme un indice, pas comme une preuve. Conservez les comptes séparés tant que l'utilisateur n'a pas prouvé qu'il contrôle l'adresse (par exemple en vérifiant la propriété par e-mail) et mettez en place un workflow délibéré pour résoudre les adresses ressemblantes au lieu de les rattacher silencieusement à un compte existant.
Stockez l'e-mail brut exactement tel que saisi pour les audits, le support et l'envoi. Stockez une valeur nettoyée séparée pour la recherche et les comparaisons afin de pouvoir ajuster les règles plus tard sans perdre l'historique ni réécrire ce que l'utilisateur a réellement fourni.
Utilisez-la seulement comme commodité pour trouver un compte, pas comme identifiant unique. Si vous autorisez une recherche insensible à la casse ou un appariement relaxé, assurez-vous que l'étape finale vérifie toujours la propriété avant de permettre une réinitialisation de mot de passe ou l'accès au compte.
Supposez qu'ils peuvent être différents sauf si vous avez des preuves fortes et spécifiques au domaine et un plan de secours sûr. Traiter [email protected] comme identique à [email protected] (ou supposer que des alias renvoient toujours à une seule boîte) relève de la supposition et peut fusionner des utilisateurs sans lien.
Validez la délivrabilité séparément des règles d'identité. Utilisez des contrôles comme la validation de la syntaxe, la vérification du domaine et des enregistrements MX, et la détection d'e-mails jetables sans réécrire l'adresse. Outils comme Verimail (verimail.co) se concentrent sur ces étapes de validation tout en vous laissant conserver l'adresse originale de l'utilisateur.
"Normaliser un e-mail" signifie prendre ce qu'un utilisateur a saisi et le réécrire dans une forme plus cohérente avant de le stocker ou de le comparer. Cela peut être aussi simple que couper les espaces, ou aussi agressif que supprimer les points, ôter les +tags, ou appliquer des règles propres à certains fournisseurs.
Le risque est simple : une petite réécriture peut transformer deux adresses différentes en une même valeur stockée. Quand cela arrive, votre système peut fusionner des identités par accident. Les réinitialisations de mot de passe peuvent arriver dans la mauvaise boîte, un utilisateur peut se retrouver dans le compte d'un autre, et votre piste d'audit devient difficile à faire confiance.
Une collision typique ressemble à ceci : l'utilisateur A s'inscrit avec [email protected] et l'utilisateur B s'inscrit avec [email protected]. Si votre système supprime les points dans la partie locale (avant le @), les deux deviennent la même chaîne, alors que beaucoup de systèmes de messagerie les traitent comme des boîtes différentes.
Ces collisions sont difficiles à repérer car elles échouent rarement de manière évidente :
L'objectif n'est pas de deviner l'adresse "réelle". L'objectif est d'éviter les erreurs évidentes et les fautes de frappe sans changer l'identité. Un défaut plus sûr est de stocker l'adresse originale telle qu'elle a été saisie, d'appliquer uniquement un nettoyage conservateur pour les comparaisons, et de gérer les vérifications de délivrabilité séparément.
La normalisation consiste à rendre les adresses suffisamment cohérentes pour le stockage et la mise en correspondance. Le piège est de confondre "cohérent" et "même personne".
Deux travaux différents sont souvent mélangés :
Une adresse e-mail a deux parties : la partie locale (avant @) et la partie domaine (après @). La plupart des surprises viennent de la partie locale, car les fournisseurs et les serveurs de messagerie d'entreprise peuvent l'interpréter différemment.
Les équipes essaient souvent des choses comme couper les espaces, tout mettre en minuscules, supprimer les points et ôter les +tags. Le problème clé est qu'il n'existe pas de forme canonique "sûre" et universelle valable pour tous les fournisseurs. Certains ignorent les points, d'autres non. Certains supportent le plus addressing, d'autres traitent + comme un caractère normal. Même la sensibilité à la casse est définie d'une manière par les standards et traitée différemment en pratique.
Un schéma plus sûr consiste à : conserver la valeur brute, créer une clé de comparaison séparée avec seulement les transformations que vous pouvez défendre, et ne jamais laisser cette clé fusionner silencieusement des comptes.
Quelques étapes de nettoyage résolvent de vrais problèmes d'entrée sans changer le sens de l'adresse.
Les plus sûrs sont :
Conserver les deux versions est important. Utilisez la version nettoyée pour les recherches et la validation, mais gardez la chaîne saisie par l'utilisateur afin de pouvoir répondre : "Qu'est-ce que l'utilisateur a tapé ?" et "Qu'avons-nous modifié ?"
Un mythe répandu est que les points dans les adresses e-mail n'ont jamais d'importance. Cette idée vient surtout de Gmail.
Gmail traite les points dans la partie locale comme optionnels, donc [email protected] et [email protected] arrivent dans la même boîte. Certains déploiements Google Workspace se comportent de la même manière, mais vous ne pouvez pas l'assumer pour tous les domaines.
En dehors de Gmail, les points peuvent absolument être significatifs. Beaucoup de systèmes mail traitent la partie locale comme du texte exact, donc [email protected] et [email protected] peuvent être des personnes différentes.
Recommandation : ne retirez pas les points sauf si vous êtes réellement certain que le domaine suit les règles de type Gmail et que vous êtes à l'aise avec le risque d'identité. Si vous cherchez à réduire les doublons, considérez les correspondances sans points comme une "correspondance possible" qui nécessite toujours une preuve utilisateur.
Les +tags (plus addressing) ressemblent à [email protected]. Les gens les utilisent pour suivre des inscriptions, router des reçus et filtrer le courrier.
Le piège est de supposer que alex+news@... est toujours la même chose que alex@.... Certains fournisseurs ignorent le tag et livrent à la boîte de base. D'autres traitent l'adresse complète comme distincte, ou des entreprises peuvent router les messages différemment selon le tag.
Si vous supprimez les +tags lors du nettoyage, vous pouvez créer des collisions que les utilisateurs n'avaient pas prévues. Par exemple, quelqu'un peut créer délibérément des comptes séparés [email protected] et [email protected]. Si vous stockez les deux comme [email protected], vous risquez de fusionner des profils et d'envoyer des réinitialisations ou des notifications au mauvais destinataire.
Règle prudente :
+... à moins d'avoir une raison étroite et bien testée pour un domaine spécifique.Les standards permettent que la partie locale soit sensible à la casse, ce qui signifie que [email protected] et [email protected] pourraient être des boîtes différentes.
Dans la pratique, beaucoup de grands fournisseurs traitent la partie locale comme insensible à la casse, ce qui explique pourquoi le mélange des majuscules fonctionne souvent. Mais vous ne pouvez pas supposer ce comportement partout.
Approche conservatrice :
Beaucoup d'échecs de normalisation commencent par : "Ce fournisseur fonctionne comme Gmail." Cette hypothèse casse vite.
Même dans l'écosystème Google, le comportement n'est pas toujours aussi simple qu'on le croit. Et quand vous sortez de gmail.com, les règles peuvent changer complètement.
Les alias, le transfert et les sous-domaines ajoutent encore de la confusion. Une personne peut s'inscrire avec un alias qui transfère vers sa boîte. Une autre peut posséder réellement l'adresse qui vous semble équivalente. Traiter [email protected] comme identique à [email protected] est une supposition.
Si vous pensez devoir appliquer des transformations spécifiques à un fournisseur, collectez d'abord des preuves : regardez vos cas réels de collision, limitez la règle à des domaines précis, et gardez l'adresse brute disponible pour le support et les audits.
Si vous normalisez trop agressivement, vous pouvez fusionner deux vraies personnes en un seul compte. L'approche plus sûre consiste à séparer stockage, affichage, validation et identité.
Un flux pratique :
Exemple : une personne s'inscrit comme [email protected], puis plus tard essaie [email protected]. Chez un fournisseur cela peut être la même boîte, chez un autre ce peut être deux boîtes distinctes. Considérez cela comme une invitation à vérifier, pas comme une raison de fusionner.
La plupart des collisions se produisent lorsqu'une règle vraie pour un fournisseur est appliquée à toutes les adresses.
Erreurs fréquentes :
Quand deux inscriptions mappent à la même chaîne canonique, vous pouvez refuser des inscriptions valides, envoyer des réinitialisations de mot de passe à la mauvaise personne, et mélanger facturation ou permissions entre utilisateurs.
Avant de déployer une règle de normalisation, répondez à deux questions : qu'essayez-vous d'optimiser (propreté, moins de doublons ou sécurité), et que se passe-t-il si vous vous trompez ?
Un socle sûr :
Si les doublons vous posent problème, considérez l'e-mail comme une information de contact, pas comme une clé d'identité parfaite. Conservez l'adresse originale pour l'envoi et le support, et maintenez une valeur "normalisée pour la recherche" que vous pouvez modifier plus tard sans perdre l'historique.
Pour réduire les inscriptions indésirables sans réécriture risquée, validez les adresses lors de l'inscription et vérifiez la propriété avant d'attacher une adresse à un compte. Si vous souhaitez une API pour cette couche, Verimail (verimail.co) se concentre sur des contrôles de validation d'e-mails comme la syntaxe, la vérification du domaine et des MX, et la détection d'e-mails jetables, sans vous obliger à réécrire les adresses d'une manière qui pourrait fusionner des utilisateurs.
Mesurez ce qui change : taux de rebond, taux d'e-mails confirmés, et à quelle fréquence des e-mails ressemblants s'avèrent appartenir à des personnes différentes. Laissez ces chiffres guider votre prochaine règle, pas le folklore des fournisseurs.