Adresses e-mail internationalisées : ce qui casse en production

Pourquoi des e-mails apparemment valides cassent en production

Une adresse e-mail peut sembler normale et pourtant échouer dès qu'elle arrive dans un vrai système. La raison principale est que ce que les gens voient comme un caractère peut être stocké sous des octets différents, traité différemment par des bibliothèques ou rejeté par des serveurs de mail anciens.

Un exemple courant est quelque chose comme søren@exämple.com. Ça peut être une adresse légitime, mais elle touche plusieurs points fragiles à la fois : Unicode dans la partie locale, un nom de domaine internationalisé, et une infrastructure de mail qui peut ou non le supporter.

Les erreurs apparaissent aussi loin de votre formulaire d'inscription. Vous pouvez accepter l'adresse, puis échouer à envoyer une réinitialisation de mot de passe parce que votre fournisseur d'e-mail (ou un relais intermédiaire) ne supporte pas SMTPUTF8. Ou votre regex l'accepte, mais votre étape de « mettre en minuscules et couper les espaces » la transforme en quelque chose de différent de ce que l'utilisateur voulait.

Les rejets silencieux coûtent cher : les gens abandonnent l'inscription, réessaient avec une autre adresse, ou ouvrent des tickets support difficiles à reproduire. Si vous avez une audience globale, rejeter des adresses internationalisées peut aussi donner l'impression que vous ne supportez pas leur langue.

Les acceptations erronées coûtent différemment. Les mauvaises adresses entraînent des rebonds, une délivrabilité réduite et des listes encombrées. Certaines saisies apparemment valides sont délibérément malveillantes : domaines jetables, comptes de rôle utilisés pour l'abus, ou pièges à spam qui abîment la réputation d'envoi.

L'objectif n'est pas « tout accepter » ni « tout bloquer ». C'est d'accepter de vrais utilisateurs tout en stoppant les entrées manifestement mauvaises, en utilisant des contrôles qui correspondent à la façon dont le courrier fonctionne réellement : séparer affichage et stockage, vérifier l'atteignabilité du domaine (pas seulement la présence d'un @), et éviter des transformations agressives qui réécrivent silencieusement ce que l'utilisateur a tapé.

Qu'est-ce qu'une adresse e-mail internationalisée

Une adresse e-mail a deux parties séparées par @ : la partie locale (avant @) et le domaine (après @). Les adresses e-mail internationalisées peuvent inclure des caractères Unicode dans l'une ou l'autre partie, et le support réel varie selon le côté qui utilise l'Unicode.

Le cas le plus courant est un nom de domaine internationalisé (IDN). L'utilisateur voit un domaine écrit dans son alphabet, comme maria@bücher.example ou li@例子.公司. En coulisses, beaucoup de systèmes convertissent ce domaine en une forme ASCII (souvent appelée punycode) pour que les recherches DNS et les vérifications MX fonctionnent de manière fiable.

Le cas plus délicat est l'Unicode dans la partie locale, comme jó[email protected] ou ユーザー@domain.com. Cela relève de l'Email Address Internationalization (EAI) et s'achemine généralement via SMTPUTF8. Même si l'adresse est valide selon les normes modernes, certains serveurs de mail, bibliothèques anciennes et outils en aval la rejettent encore. Vous pouvez donc l'accepter à l'inscription et échouer plus tard quand vous essayez d'envoyer.

Une façon pragmatique de penser au support aujourd'hui :

• Les domaines Unicode sont largement utilisables car ils peuvent être représentés en ASCII pour le DNS.
• Les parties locales Unicode sont moins uniformément supportées de bout en bout (formulaire d'inscription, base de données, CRM, fournisseur d'e-mail et boîte de réception doivent tous les gérer).
• Les scripts mixtes et les caractères ressemblants augmentent le risque de fraude.
• L'affichage et le stockage cassent quand le logiciel suppose « un caractère = un octet ».

C'est pourquoi une simple regex oui/non ne suffit pas. Une regex peut rejeter des utilisateurs légitimes (par exemple en bloquant tout non-ASCII), ou accepter des adresses que vous ne pourrez pas livrer.

Une meilleure validation traite chaque côté séparément. Pour le domaine, normalisez et convertissez en ASCII pour les vérifications DNS. Pour la partie locale, il faut une décision de politique : supportez-vous SMTPUTF8 totalement, l'autorisez-vous avec un avertissement, ou la bloquez-vous parce que votre stack e-mail ne peut pas la délivrer de façon fiable ?

IDN et punycode : le côté domaine du problème

Un IDN (Internationalized Domain Name) est un domaine utilisant des caractères non-ASCII, comme des accents ou des scripts non latins. Les gens voient et tapent la forme Unicode, mais le DNS est construit autour de l'ASCII. Ce décalage est souvent la source des bugs en production.

Pour rechercher des enregistrements MX, vérifier un domaine ou même faire une vérification DNS basique, vous devez généralement la forme ASCII du domaine. Cette conversion suit les règles IDNA et produit du punycode, qui commence souvent par xn--. Ainsi, un utilisateur peut saisir un domaine qui lui semble normal, mais vos logs, votre base ou votre fournisseur en amont peuvent montrer une version xn--... à la place.

Le punycode apparaît dans des endroits où vous devez vous y attendre et le gérer :

• Recherches DNS et MX
• Appels API vers des services de validation ou de délivrabilité
• Logs et outils de sécurité (pour que les analystes puissent copier-coller sans erreur)
• Stockage et déduplication (pour que le même domaine ne soit pas stocké deux fois sous des formes différentes)

Deux erreurs communes :

• Valider uniquement le domaine Unicode en tant que chaîne et ne jamais le convertir avant les vérifications DNS.
• Rejeter tout domaine contenant des caractères non-ASCII, ce qui bloque des utilisateurs légitimes.

Il y a aussi un angle sécurité. Les scripts mixtes et les caractères confusibles peuvent servir à créer des domaines visuellement ressemblants à une marque de confiance. Vous ne devriez généralement pas bloquer tous les IDN pour cette raison, mais il est raisonnable de les considérer comme plus risqués dans des contextes sensibles comme les paiements, les réinitialisations de mot de passe ou les accès admin.

Une approche pragmatique est d'accepter ce que l'utilisateur tape, puis de normaliser en interne :

• Acceptez le domaine Unicode dans le champ d'entrée.
• Convertissez le domaine en ASCII (punycode) pour les vérifications DNS et MX.
• Stockez les deux formes quand c'est possible : Unicode pour l'affichage, ASCII pour les vérifications techniques et une correspondance cohérente.
• Signalez les motifs suspects (scripts mixtes, confusables) pour une revue supplémentaire ou une vérification renforcée.

Normalisation Unicode : pourquoi le même texte n'est pas toujours le même

Unicode permet de taper des noms et mots de nombreuses langues, mais cela signifie aussi qu'un même « caractère » peut être représenté de plusieurs façons. Si vous comparez les chaînes octet à octet, ou stockez une forme puis en recevez une autre, vous pouvez avoir des doublons, des connexions échouées et des erreurs déroutantes « e-mail déjà utilisé ».

Un exemple simple concerne les caractères accentués. La lettre « é » peut être un seul point de code (U+00E9), ou deux points de code : « e » (U+0065) plus un accent combinant (U+0301). Ils paraissent identiques à une personne, mais votre base de données peut les traiter comme différents.

NFC vs NFKC (et pourquoi cela a de l'importance)

La normalisation convertit le texte en une forme cohérente.

• NFC (Normalization Form C) compose les caractères quand c'est possible. Elle conserve généralement l'intention de l'utilisateur tout en rendant les comparaisons d'égalité plus fiables.
• NFKC va plus loin en convertissant des caractères de compatibilité en équivalents plus simples (par exemple certaines formes plein-chant). Cela peut améliorer la cohérence, mais aussi changer le sens et interagir mal avec les attaques de spoofing et les confusables si vous l'appliquez de manière aveugle.

Pour la gestion des e-mails, NFC est souvent le choix le plus sûr pour les comparaisons « rendre égal ».

Gestion de la casse : quoi mettre en minuscules (et quoi ne pas toucher)

Les règles de casse diffèrent entre les deux côtés d'une adresse :

• Partie domaine (à droite du @) : il est sûr de la traiter comme insensible à la casse. La mise en minuscules est standard.
• Partie locale (à gauche du @) : techniquement sensible à la casse, même si beaucoup de fournisseurs l'ignorent. La mettre en minuscules peut fusionner deux adresses distinctes sur certains systèmes.

Approche pratique : mettez en minuscules et normalisez le domaine ; gardez la partie locale telle que l'utilisateur l'a saisie, tout en stockant une forme canonique pour les comparaisons.

Quand normaliser (et quand préserver)

Normalisez aux moments où la cohérence compte :

• À l'entrée : normalisez en NFC avant la validation et avant la vérification « déjà enregistré ».
• Au stockage : conservez la chaîne originale (pour l'affichage et le support) et une forme canonique (pour la recherche et la déduplication).
• À la comparaison : comparez en utilisant la forme canonique, pas l'entrée brute.

Même avec un bon service de validation, votre application a besoin d'une politique claire de normalisation et de casse pour éviter que des utilisateurs légitimes soient bloqués par des différences de caractères invisibles.

Où les systèmes en production échouent généralement

La plupart des bugs liés aux adresses e-mail internationalisées se produisent aux jonctions, où un système fait une hypothèse différente de la suivante. L'adresse semble correcte pour un utilisateur, mais quelque chose dans la chaîne la change, la rejette ou traite deux valeurs visuellement identiques comme différentes.

Un échec courant commence dans le formulaire d'inscription. Les règles côté client n'autorisent souvent que A-Z, 0-9 et quelques symboles. Les claviers mobiles insèrent une ponctuation intelligente, et l'autocomplétion ajoute un espace final invisible. La mise en minuscules automatique peut aussi se comporter de façon étrange en dehors de l'ASCII de base.

Côté backend, de petites étapes de nettoyage peuvent être destructrices. Couper les espaces est utile, mais supprimer les caractères « non imprimables » peut effacer des signes Unicode valides. Les limites de longueur posent aussi problème : les domaines internationalisés peuvent s'allonger une fois convertis en punycode, et vous pouvez atteindre une limite inattendue.

Les bases de données ajoutent leurs propres pièges. Les règles de collation et de comparaison décident si deux chaînes sont égales. Si un système stocke une forme composée et qu'un autre envoie plus tard une forme décomposée, les vérifications d'unicité peuvent échouer. Cela peut créer des comptes dupliqués ou bloquer un utilisateur parce que votre requête « existe déjà » ne correspond pas à ce qui a été stocké.

Les problèmes apparaissent le plus souvent dans :

• La validation côté client et les widgets d'entrée
• L'assainissement côté serveur, le trimming et les limites de longueur
• La collation de la base de données et les index uniques
• Les intégrations (CRM, analytics, outils support, processeurs de logs)
• Les systèmes d'envoi sortant qui ne supportent pas SMTPUTF8

L'envoi sortant est là où cela devient inévitable. Si votre serveur mail ou un relais aval ne supporte pas SMTPUTF8, il peut refuser d'envoyer vers une boîte avec des caractères non-ASCII dans la partie locale. Les utilisateurs peuvent s'inscrire, mais ne jamais recevoir d'e-mail de vérification.

Une chaîne d'échec réaliste ressemble à ceci : un utilisateur s'enregistre avec un domaine Unicode, votre appli le stocke, votre CRM le normalise différemment, et votre fournisseur d'e-mail refuse SMTPUTF8. Vous vous retrouvez avec un utilisateur, deux chaînes qui ne correspondent pas et un e-mail de bienvenue qui n'arrive jamais.

Étape par étape : un workflow de validation plus sûr

Un workflow sûr commence par séparer deux objectifs : ne pas bloquer de vrais utilisateurs à l'inscription, et stocker quelque chose que vous pouvez comparer, envoyer et dépanner plus tard.

1. Préservez la saisie de l'utilisateur. Conservez l'adresse exactement comme tapée, puis supprimez seulement les espaces entourants évidents. Évitez les modifications « utiles » comme changer la casse, enlever des accents, supprimer des points ou retirer les plus-tags. Ces changements peuvent silencieusement transformer une adresse en une autre.

2. Faites une vraie vérification de syntaxe. Traitez-la comme « est-ce structurellement possible », pas « le mail va-t-il définitivement arriver ». Les règles modernes sont plus larges que la plupart des regex, surtout quand des caractères internationaux sont impliqués.

3. Décidez de la normalisation et de l'unicité. Stockez l'adresse brute plus une forme canonique (souvent NFC) pour les contrôles d'égalité. Si l'e-mail est une clé unique dans votre système, précisez si des entrées visuellement identiques mais encodées différemment doivent compter pour le même compte.

4. Traitez correctement le domaine. Normalisez le domaine et convertissez-le en ASCII (punycode) avant tout travail DNS. Puis vérifiez le domaine et recherchez les enregistrements MX (et éventuellement un fallback A/AAAA si votre politique l'autorise).

5. Définissez une politique pour les local-parts Unicode. Si votre fournisseur sortant ne peut pas délivrer SMTPUTF8 de façon fiable, acceptez l'inscription seulement si vous avez un plan de secours (vérification in-app, méthode de contact alternative, ou un avertissement clair avant de promettre la livraison d'e-mails).

Conservez un petit ensemble de logs sur les résultats de validation pour que le support puisse dépanner les cas limites sans deviner.

Validation vs délivrabilité : ce que vous pouvez prouver

On dit souvent « validation d'e-mail » quand on veut dire « mon message atteindra-t-il une vraie personne ». C'est la délivrabilité, et vous ne pouvez pas la prouver complètement à l'inscription. Avec les adresses internationalisées, il est encore plus facile de confondre « ça paraît valide » avec « ça marchera partout ».

La validation peut néanmoins fournir de bons signaux avant de stocker une adresse ou d'envoyer :

• La syntaxe est acceptable (en incluant les règles SMTPUTF8 quand pertinent)
• Le domaine existe et se résout
• Des enregistrements MX sont présents (ou le domaine est configuré pour recevoir du mail)
• L'adresse ou le domaine semble risqué (par exemple fournisseurs jetables)

Mais la validation ne garantit pas que la boîte existe ou acceptera votre message. Beaucoup de fournisseurs bloquent le probing de boîte, acceptent le mail pour des utilisateurs inconnus puis renvoient un bounce, ou changent de politique sans prévenir.

Une approche plus sûre est en deux étapes :

• Validez à l'inscription pour attraper les problèmes évidents, réduire les fautes de frappe et prévenir les inscriptions de faible qualité.
• Confirmez la propriété avec une étape de vérification par e-mail (un message cliquable). C'est ce qui prouve que l'utilisateur peut recevoir du courrier et contrôle l'adresse.

Pour les résultats « à risque », les blocages durs créent souvent des faux négatifs. La friction légère fonctionne généralement mieux : autorisez l'inscription, exigez la confirmation avant les actions sensibles, ou demandez un signal supplémentaire seulement quand le risque est élevé.

Erreurs courantes qui bloquent des utilisateurs légitimes

La façon la plus rapide de perdre de vraies inscriptions est de traiter tout ce qui est hors ASCII comme invalide. Beaucoup de fournisseurs légitimes supportent des domaines internationalisés, et certains utilisateurs en dépendent réellement.

Erreur 1 : règles « ASCII seulement » trop strictes

Beaucoup de code en production suppose encore que e-mail = A-Z, 0-9, points et une courte liste de symboles. Cela casse pour les domaines IDN et garantit des rejets pour des produits globaux.

Erreur 2 : mettre tout l'adresse en minuscules ou normaliser entièrement

Mettre le domaine en minuscules va, mais mettre la partie locale en minuscules peut être risqué.

La normalisation aide, mais la faire aveuglément peut surprendre les utilisateurs. Normalisez intentionnellement, conservez l'entrée originale et testez le comportement des systèmes en aval.

Transformations « utiles » qui échouent souvent :

• Couper trop agressivement (ou supprimer des caractères que vous croyez invisibles)
• Mettre toute l'adresse en minuscules
• Appliquer une forme de normalisation unique partout sans tester les exports et intégrations
• Supprimer automatiquement les points ou les plus-tags (comportement spécifique aux fournisseurs)

Erreur 3 : afficher le punycode aux utilisateurs

Votre backend peut avoir besoin du punycode pour les vérifications DNS, mais votre UI devrait en général afficher le domaine dans l'écriture de l'utilisateur. Afficher xn--... dans des confirmations ou messages d'erreur paraît souvent suspect, même si l'adresse est correcte.

Erreur 4 : supposer que les local-parts Unicode fonctionnent toujours

Même si une adresse est valide selon la spécification, tous les serveurs mail ne supportent pas SMTPUTF8. Si vous acceptez des local-parts Unicode, préparez-vous à des différences de délivrabilité selon les fournisseurs.

Erreur 5 : ignorer les artefacts de copier-coller

Le copier-coller introduit des espaces insécables, des caractères zéro-largeur et des espaces superflus autour du @. Les utilisateurs ne voient pas ces problèmes, mais votre validation síera.

Exemple : un utilisateur colle name@пример.рф avec un espace final. Si vous validez avant de trim, vous le rejetez. Si vous sur-nettoyez, vous pouvez modifier la partie locale.

Contrôles rapides avant mise en production

Les adresses e-mail internationalisées peuvent fonctionner de bout en bout, mais seulement si chaque couche s'accorde sur ce qu'elle acceptera, stockera et enverra. Avant la mise en production, exécutez des vérifications qui correspondent au comportement réel en production, pas seulement des tests unitaires.

Checklist pratique avant déploiement

• Confirmez que le formulaire d'inscription accepte l'Unicode là où vous le souhaitez (domaine, partie locale ou les deux). Si vous ne supportez pas les local-parts Unicode, indiquez-le clairement au point d'entrée.
• Choisissez une règle de normalisation (souvent NFC) et appliquez-la de façon cohérente dans le navigateur, l'API, les jobs en arrière-plan et les outils admin.
• Convertissez le domaine en ASCII (punycode) avant tout travail DNS, et stockez une forme comparable pour que les recherches ne dérivent pas.
• Faites en sorte que l'unicité des comptes corresponde aux règles de connexion et de recherche. Décidez si des adresses visuellement identiques mais encodées différemment doivent correspondre au même utilisateur.
• Testez l'envoi sortant sur votre chemin d'e-mail réel (fournisseur, relais, bibliothèque) en utilisant des exemples avec un domaine IDN et une partie locale Unicode.

Vérifications que l'on oublie (jusqu'aux tickets support)

Assurez-vous que les logs et outils admin peuvent afficher la version conviviale sans la transformer en mojibake ou casser les exports. Confirmez aussi que chaque système qui touche l'adresse peut la gérer : événements analytics, synchronisation CRM, payloads webhook, exports CSV et ingestion dans un entrepôt de données. Beaucoup d'échecs se produisent à l'export, pas à l'entrée.

Un test concret : faites passer la même adresse par inscription, connexion, réinitialisation de mot de passe et tout flux de fusion de compte. Si elle passe l'inscription mais échoue ensuite, vous avez une divergence dans la normalisation, le stockage ou les comparaisons.

Scénario exemple et étapes suivantes

Un utilisateur s'inscrit avec marta@bücher.example. Cela paraît normal car le domaine est écrit en Unicode. Votre système doit traiter le domaine comme un IDN.

Côté domaine, conservez l'affichage convivial mais validez la forme DNS-safe. Convertissez bücher.example en punycode (xn--bcher-kva.example) avant d'effectuer des recherches MX. Si vous ne vérifiez que la forme Unicode, certaines bibliothèques DNS échoueront ou se comporteront de manière incohérente.

Maintenant la partie subtile : la même adresse peut être tapée de différentes manières qui paraissent identiques. Supposons que l'utilisateur entre márta@bücher.example, mais le « á » peut être composé en un seul caractère ou en « a » plus un accent combinant. Si vous ne stockez que l'entrée brute, un utilisateur peut se retrouver avec deux comptes qui semblent identiques dans votre UI.

La normalisation corrige cela. Normalisez en NFC avant de comparer, stocker, limiter le taux ou dédupliquer, et appliquez les mêmes étapes partout où l'adresse est manipulée.

La partie locale (tout avant @) est l'endroit où vous devez avoir une politique claire. SMTPUTF8 autorise des local-parts Unicode, mais pas tous les fournisseurs les supportent de bout en bout. Une politique pratique pour beaucoup de produits :

• Acceptez les local-parts ASCII par défaut.
• Si la partie locale contient de l'Unicode, acceptez-la mais exigez une confirmation ou affichez un avertissement clair.
• Si votre produit dépend fortement de la livraison d'e-mails (réinitialisations, factures), bloquez les local-parts Unicode sauf si vous avez testé le support SMTPUTF8 sur toute la chaîne d'envoi.

Si vous voulez un endroit unique pour exécuter des vérifications de syntaxe, de domaine et MX (et filtrer les domaines jetables), une API de validation d'e-mails comme Verimail (verimail.co) peut fournir ces signaux sans s'appuyer sur une regex fragile.

Étapes suivantes pour rester sûr sans rejeter de vrais utilisateurs :

• Rédigez votre politique sur les local-parts Unicode (accepter, avertir ou bloquer) et appliquez-la de façon cohérente sur le web, mobile et les outils admin.
• Normalisez en NFC avant de stocker, comparer ou dédupliquer.
• Testez les cas limites : domaines IDN, scripts mixtes, caractères composés vs décomposés et saisies collées.
• Surveillez les indicateurs : taux de confirmation, rebonds et erreurs « e-mail déjà utilisé » après normalisation.
• Conservez assez de logs sur les décisions de validation pour déboguer rapidement les rejets erronés.