La détection des fautes d'e‑mail empêche les inscriptions perdues en repérant des erreurs comme gmail.con. Découvrez des modèles UX pratiques, des heuristiques et des étapes de validation acceptées par les utilisateurs.
Concentrez‑vous d'abord sur les fautes de domaine à haute confiance qui sont à une ou deux lettres d'un fournisseur courant, comme gmail.con → gmail.com ou hotnail.com → hotmail.com. Normalisez aussi l'entrée et corrigez les problèmes de format (espaces en début/fin, point final à la fin, ou une virgule à la place d'un point) avant de lancer la détection.
Parce que la partie locale (avant @) est souvent unique et difficile à deviner en toute sécurité, alors que la partie domaine se répète et est prévisible. Corriger le domaine est à la fois plus précis et moins susceptible de transformer une adresse correcte en une mauvaise adresse.
Affichez la correction comme une suggestion que l'utilisateur peut accepter ou ignorer. La correction silencieuse peut envoyer ultérieurement des réinitialisations de mot de passe ou des factures vers une mauvaise boîte et créer de la confusion si l'utilisateur pense s'être inscrit avec une adresse différente.
Le moment "on blur" est en général le choix calme par défaut, car il intervient quand l'utilisateur a fini le champ. Si vous voulez que ça paraisse plus rapide, utilisez une courte pause de frappe, mais réglez‑la pour éviter les déclenchements à chaque frappe. Proposer la correction à la soumission est le moins intrusif, mais les utilisateurs se sentent souvent "terminés" à ce moment, donc les corrections peuvent être perçues comme gênantes.
Restez bref et neutre, par exemple « Voulez‑vous dire gmail.com ? » et incluez une action en un clic pour appliquer la correction. Rendez‑la rémanente (dismissible) ; si l'utilisateur la ferme, ne la réaffichez pas à moins qu'il change l'e‑mail.
Utilisez une petite liste sélectionnée de domaines que vous acceptez de proposer, normalisez l'entrée (supprimer les espaces, mettre le domaine en minuscules), puis calculez une similarité (distance d'édition, par exemple). Ne suggérez que s'il y a un gagnant clair dans un seuil strict, et considérez la suggestion comme une option plutôt qu'une réécriture automatique.
Non. La logique de suggestion côté client est facile à contourner via des scripts ou des appels API directs, et l'UI ne peut pas vérifier l'existence des enregistrements MX ou si l'adresse est jetable. Exécutez la même logique côté serveur, puis suivez avec des vérifications réelles pour que le backend applique vos règles.
Évitez de suggérer si vous n'êtes pas très confiant, si plusieurs domaines sont à égalité, ou si le domaine semble être personnalisé (entreprise, école, TLD peu courant). Évitez aussi de toucher à la partie locale ; c'est de la supposition et cela peut transformer une adresse correcte en une incorrecte.
Considérez‑les comme valides. [email protected] est courant pour le filtrage. Ne les supprimez pas et ne les signalez pas à moins que votre système ne puisse vraiment pas les gérer — et si c'est le cas, expliquez la limitation clairement.
Verimail peut valider l'e‑mail soumis pendant l'inscription avec des contrôles RFC, des vérifications de domaine et MX, et la détection d'adresses jetables. Une configuration courante consiste à utiliser des suggestions de faute pour éviter les erreurs évidentes avant l'envoi, puis à exécuter Verimail côté serveur pour décider d'accepter, rejeter ou marquer une adresse selon les signaux de validation.
Une seule mauvaise frappe dans une adresse e‑mail peut stopper une inscription net. Si quelqu'un tape gmail.con au lieu de gmail.com, votre e‑mail de confirmation n'arrive jamais. L'utilisateur n'a généralement aucune idée de la raison. Il actualise, réessaie, ou part. La même faute casse plus tard les réinitialisations de mot de passe, les avis de facturation et tout message qui prouve qu'un compte est réel.
Les fautes d'e‑mail comptent parce que la plupart des gens ne considèrent pas leur adresse comme des « données ». Ils pensent : « Je l'ai tapée, donc elle doit être correcte. » Quand rien n'apparaît dans la boîte de réception, ils blâment votre produit, pas leur clavier.
L'impact s'accumule rapidement : plus d'inscriptions abandonnées parce que les utilisateurs ne peuvent pas vérifier, plus de tickets support du type « Je n'ai jamais reçu l'e‑mail », des prospects perdus et une attribution brouillée parce que les contacts ne deviennent jamais joignables, et un risque pour la délivrabilité si votre système continue d'essayer des adresses erronées.
Les fautes sont aussi prévisibles. Un petit ensemble de domaines provoque une grande part des erreurs : gmail.con, hotnail.com et yaho.com reviennent sans cesse. Les attraper tôt est l'un des rares ajustements UX qui peuvent améliorer sensiblement le taux de conversion sans changer votre offre.
Il est utile d'être clair sur ce que la détection de fautes peut et ne peut pas faire. Elle peut repérer des erreurs probables (souvent en comparant le domaine aux fournisseurs courants) et proposer une correction avant la soumission. Elle ne peut pas garantir que la boîte existe, que la personne en est propriétaire, ni que l'adresse est sûre à accepter.
Une approche pratique : suggérer quand vous êtes confiant, valider quand vous avez besoin de certitude. Par exemple, Verimail peut valider les adresses e‑mail à l'inscription en utilisant des contrôles comme la syntaxe, la vérification du domaine et MX, et la détection d'adresses jetables, tandis que les suggestions de faute évitent que des erreurs simples soient soumises.
La plupart des gens ne tapent pas leur e‑mail faux volontairement. Ils tapent vite, sur un petit clavier, ou en changeant d'application. Une bonne détection se concentre sur les erreurs fréquentes et sûres à corriger.
Les corrections les plus utiles se trouvent généralement dans la partie domaine (tout après le @). Les gens connaissent en général leur nom d'utilisateur, mais se trompent sur les fournisseurs populaires. Les motifs courants incluent des lettres manquantes (gmal.com), des lettres inversées (gmial.com) et des lettres doublées (gmaill.com). Elles sont faciles à repérer car elles sont à une ou deux modifications d'un domaine connu.
Les erreurs de TLD sont un autre cas fréquent car elles semblent valides au premier coup d'œil. Le classique est gmail.con au lieu de gmail.com, mais on voit aussi .cmo, .coom, ou un TLD de pays saisi par accident. Si le domaine correspond fortement et que seule la fin est incorrecte, une suggestion est généralement bienvenue.
Toutes les « fautes » ne sont pas orthographiques. Les problèmes de format provoquent aussi des échecs silencieux, surtout quand les utilisateurs copient‑collent. Surveillez les espaces en début ou fin, un point final à la fin ([email protected].), les doubles points ([email protected]), les virgules au lieu des points (name@gmail,com) et les @ manquants ou en trop.
Le mobile ajoute ses propres problèmes : touches adjacentes (n et m), l'autocorrect qui change un domaine, ou le clavier qui insère un espace après un point. Exemple réaliste : quelqu'un saisit [email protected] sur son téléphone. Une simple suggestion comme « Voulez‑vous dire [email protected] ? » évite un ticket support et une inscription perdue sans rendre le formulaire strict.
La détection doit être un assistant, pas un verrou. Traitez‑la comme un correcteur orthographique : rapide, discret et facile à ignorer si l'utilisateur a raison.
Les contrôles côté client doivent se produire près de la saisie afin que les gens puissent corriger avant de passer à autre chose. Gardez‑les légers : comparez la partie domaine à une courte liste de fournisseurs courants, et ne suggérez que lorsqu'il y a une très forte correspondance (par exemple gmail.con → gmail.com). Ne bloquez pas la soumission simplement parce que vous pensez avoir trouvé une faute. Certains domaines inhabituels sont parfaitement valides.
Les contrôles côté serveur sont le filet de sécurité. Les utilisateurs peuvent contourner le navigateur, des scripts peuvent poster directement, et même la meilleure UI ne peut pas arrêter toutes les mauvaises adresses. Exécutez la même logique de faute sur le backend, puis suivez par une validation réelle (syntaxe, domaine, MX, détection d'adresses jetables). Une API de validation d'e‑mail comme Verimail peut gérer les vérifications profondes pour que vous n'ayez pas à les construire et maintenir vous‑même.
Le moment d'afficher les suggestions dépend du style de votre formulaire :
Les gens qui collent un e‑mail et appuient rapidement sur Entrée sont le cas délicat. Évitez de les ralentir. Affichez la suggestion immédiatement, mais laissez Entrée soumettre normalement. Si vous avez besoin d'une seconde chance, affichez une petite invite inline après la soumission et avant la création du compte, avec deux actions claires : « Utiliser l'e‑mail saisi » et « Utiliser l'e‑mail suggéré ».
Règle simple : suggérer tôt, vérifier toujours, et ne jamais piéger l'utilisateur dans une boucle qui l'empêche d'avancer.
Une bonne vérification se concentre sur une chose : attraper les erreurs évidentes comme gmail.con et proposer la correction juste, sans contester les utilisateurs qui ont saisi quelque chose d'intentionnellement inhabituel.
Commencez par construire un petit ensemble de domaines soigneusement choisis que vous êtes prêt à suggérer. Incluez les grands fournisseurs publics (gmail.com, outlook.com, yahoo.com) et, si cela correspond à votre audience, les domaines clients que vous rencontrez souvent (par exemple si beaucoup d'inscriptions viennent de quelques entreprises). Gardez cette liste courte et révisée, car chaque domaine ajouté augmente le risque d'une suggestion erronée.
Normalisez ensuite ce que l'utilisateur a saisi avant toute comparaison. Supprimez les espaces, séparez sur @, mettez seulement la partie domaine en minuscules, et traitez prudemment les caractères Unicode trompeurs (les utilisateurs peuvent coller des lettres similaires).
Voici un flux simple qui fonctionne bien en pratique :
@ ; s'il n'y a pas de @, ne faites rien.Un petit exemple en pseudocode :
if not hasAt(email): return
local, domain = split(email)
d = normalize(domain)
if d in knownDomains: return
best = closestByEditDistance(d, knownDomains)
if best.distance \u003c= 2 and best.isUniqueWinner:
suggest(local + \"@\" + best.domain)
Soyez conservateur avec les seuils. Il vaut mieux manquer une faute rare que d'embêter beaucoup de personnes avec des invites constantes. Suggérez uniquement quand la confiance est élevée, comme hotnail.com → hotmail.com, pas quand plusieurs domaines sont à égalité.
Enfin, laissez l'utilisateur maître de la décision. Proposez un choix clair comme « Utiliser gmail.com » ou « Conserver gmail.con », et ne bloquez pas la soumission parce que vous avez montré une suggestion. Votre couche de validation (par exemple une API de validation d'e‑mail comme Verimail) peut toujours s'exécuter séparément pour attraper les domaines invalides et les adresses jetables.
Une bonne suggestion ressemble à une aide, pas à un blâme. L'objectif : aider quelqu'un à corriger gmail.con ou hotnail.com en une touche, sans interrompre son flux.
Le pattern le plus propre est un indice inline sous le champ e‑mail. Restez court et précis : « Voulez‑vous dire gmail.com ? » Ajoutez une action évidente comme « Utiliser gmail.com » pour éviter la ressaisie. Cela fonctionne mieux dès que l'adresse semble complète (après la saisie du domaine, ou au blur), pas à chaque frappe.
Quand les enjeux sont plus élevés, ajoutez une légère confirmation juste avant la soumission. Par exemple, quand l'utilisateur clique sur « Créer un compte », affichez un petit message inline près du champ e‑mail présentant les deux choix : conserver ce qu'il a saisi, ou basculer sur le domaine suggéré. Cela réduit les faux positifs et évite la sensation que le formulaire « prend le contrôle ».
Quelques détails rendent ces patterns respectueux :
Exemple : quelqu'un tape [email protected] pendant un essai gratuit. Un indice inline propose « Utiliser hotmail.com ». Sarah tape une fois, le champ se met à jour, et elle passe au mot de passe sans perdre sa place. Plus tard, vous pouvez toujours exécuter une vérification côté serveur (par exemple avec une API de validation d'e‑mail) pour attraper des problèmes plus profonds, mais le gain UX se produit immédiatement.
La détection de faute repose surtout sur la manière dont vous parlez à l'utilisateur. Le but est d'aider, pas de blâmer. Un ton neutre garde l'utilisateur en mouvement : « Voulez‑vous dire gmail.com ? » passe mieux que « Cet e‑mail est invalide. » Si vous avez besoin d'un ton plus prudent, essayez « Vérifiez le domaine : vouliez‑vous dire gmail.com ? »
Montrez la différence exacte et concentrez‑vous sur la partie modifiée. La plupart des erreurs sont dans le domaine, donc mettez en évidence seulement ce segment (par exemple, affichez name@ inchangé et insistez visuellement sur gmail.con → gmail.com). Cela réduit la confusion et rend la correction sûre.
Différenciez clairement suggestion et erreur. Une suggestion est un indice, pas un échec ; elle doit donc être visuellement plus discrète qu'une erreur sévère. Par exemple : une ligne suggestion grise sous le champ, et utilisez le rouge seulement lorsque vous bloquez vraiment la soumission (manque de @, caractères invalides, ou un domaine impossible).
L'accessibilité nécessite la même attention que l'aspect visuel. Les lecteurs d'écran doivent annoncer la suggestion et l'action disponible. Un simple schéma :
gmail.com ? »gmail.com à la place »gmail.com »Assurez‑vous aussi que la suggestion est accessible au clavier (atteignable par Tab, activable par Entrée/Espace) et que le focus ne saute pas de manière inattendue.
La localisation est facile à rater. Traduisez le texte d'accompagnement, mais ne traduisez pas le domaine lui‑même. gmail.com reste gmail.com dans toutes les langues. Si vous utilisez une API comme Verimail, conservez la cohérence des messages produits tout en laissant le domaine suggéré inchangé.
Les fautes sont fréquentes, mais des suggestions trop assertives peuvent être pires que l'inaction. Si votre formulaire « corrige » une adresse réelle, vous risquez de perdre un utilisateur qui a fait tout correctement.
Commencez par être conservateur avec les domaines inconnus. Beaucoup de gens utilisent des e‑mails d'école, d'entreprise ou des nouveaux TLD comme .dev ou .app. Si quelqu'un saisit [email protected], ce n'est pas « faux » simplement parce que vous ne l'avez pas vu avant. Traitez les domaines inconnus comme « non vérifiés pour l'instant », pas comme des fautes.
Évitez de modifier la partie locale (avant le @). Transformer jane.smith en jane-smith, ou enlever des points, c'est deviner. Suggérez des modifications sur la partie locale seulement si vous avez une règle claire et approuvée par l'utilisateur (par exemple, vous savez que votre propre domaine ignore les points). Sinon, concentrez‑vous sur le domaine.
Le plus‑addressing est un autre endroit où les équipes cassent accidentellement des e‑mails valides. Des adresses comme [email protected] sont valides et largement utilisées pour le filtrage. Si votre système les supporte, ne les avertissez pas, ne les supprimez pas et ne les bloquez pas. Si vous ne les supportez pas, expliquez clairement pourquoi, car les utilisateurs s'en servent pour des règles de boîte.
Règle simple : suggérer, ne pas forcer. Bons moments pour ne pas suggérer :
Enfin, laissez toujours la possibilité de continuer avec ce que l'utilisateur a saisi. Une option claire « Utiliser tel quel » évite la frustration, surtout quand votre validateur (par exemple, un service comme Verimail) ne peut pas confirmer la délivrabilité instantanément mais l'utilisateur sait que l'adresse est correcte.
La façon la plus simple de faire paraître la détection « intelligente » est aussi la plus simple pour se tromper : suggérer trop souvent. Si votre seuil de correspondance est trop lâche, vous ennuierez les utilisateurs avec des adresses correctes (surtout les domaines professionnels). Concentrez‑vous sur des cas à haute confiance comme les domaines populaires (gmail.com, outlook.com, yahoo.com) et sur des éditions très petites.
La correction automatique silencieuse est un autre piège classique. Remplacer gmail.con par gmail.com sans prévenir l'utilisateur semble utile, mais peut causer de vrais dégâts par la suite : réinitialisations de mot de passe envoyées au mauvais compte, ou l'utilisateur pense s'être inscrit avec une adresse différente de celle stockée. Demandez toujours confirmation quand vous proposez une correction.
Ne comptez pas uniquement sur les contrôles frontend. Une UI propre peut quand même accepter des adresses pourries si des bots ou des clients scriptés envoient directement à votre endpoint. Traitez la suggestion du navigateur comme un confort et appliquez la validation sur le serveur. Un flux pratique : suggérer dans l'UI, puis revérifier côté serveur avec la syntaxe, les enregistrements de domaine/MX (et rejeter les adresses manifestement invalides).
Pour garder cela sous contrôle, suivez ce qui se passe après une suggestion. Si vous ne journalisez pas les résultats, vous ne saurez pas si vos règles aident ou nuisent.
Enfin, ne confondez pas détection de faute et détection d'adresses jetables. Une adresse jetable peut être parfaitement orthographiée, et une faute peut se produire sur un domaine non jetable. Traitez‑les comme des signaux distincts avec des UI différentes.
Par exemple, hotnail.com est probablement une faute qui mérite un prompt « Voulez‑vous dire hotmail.com ? ». Mais mailinator.com n'est pas une faute. Si vous le bloquez, indiquez‑le clairement. Si vous utilisez une API comme Verimail, séparez les décisions : suggestions UX pour l'expérience, et détection des jetables pour protéger la qualité des inscriptions.
Avant de déployer la détection de fautes, passez un contrôle rapide sur de vrais appareils et avec de vraies habitudes de saisie. La plupart des échecs viennent de petits détails : quand la suggestion apparaît, ce qui se passe à l'appui sur Entrée, et si le serveur est d'accord avec le navigateur.
Utilisez cette checklist pour attraper les problèmes qui apparaissent souvent après le lancement :
gmail.con → gmail.com) et évitez les suppositions sur des domaines d'entreprise rares.Ensuite, ajoutez de l'analytics pour prouver que la fonctionnalité aide et ne se base pas sur des suppositions. Capturez au minimum : quand une suggestion est affichée, quand elle est acceptée, quand elle est rejetée, et quel e‑mail est finalement enregistré (stockez‑le en sécurité, et envisagez de ne journaliser que le domaine ou une valeur hachée si vous n'avez pas besoin de l'adresse complète).
Un dernier test de bon sens : faîtes volontairement une faute sur un domaine courant, acceptez la correction et terminez l'inscription. Recommencez en ignorant la correction. Dans les deux cas, le formulaire doit rester calme et prévisible, et l'e‑mail enregistré doit correspondre au choix de l'utilisateur.
Un utilisateur commence un essai gratuit et tape son e‑mail rapidement : [email protected]. À première vue ça ressemble à une adresse valide, mais elle échouera presque à coup sûr plus tard. L'utilisateur soumet, attend l'e‑mail de bienvenue, puis ouvre un ticket support : « Je ne l'ai jamais reçu. »
Avec la détection de fautes en place, le formulaire attrape l'erreur pendant que l'utilisateur est encore focalisé sur le champ. Juste sous l'entrée, une note inline apparaît (pas une popup) : « Voulez‑vous dire [email protected] ? » À côté, une action unique « Utiliser hotmail.com ».
L'utilisateur tape une fois, l'e‑mail se met à jour dans le champ, et le curseur avance comme si de rien n'était. Pas de dialogue modal, pas de saut de page, pas d'interruption. Si la suggestion est incorrecte, l'utilisateur peut l'ignorer et continuer.
Une version simple de l'interaction :
Même après une suggestion parfaite, le backend doit toujours valider l'adresse finale avant de créer le compte. Par exemple, après que l'utilisateur a accepté hotmail.com, votre serveur peut exécuter des contrôles complets (syntaxe, domaine, MX, détection des jetables et listes noires) en utilisant une API de validation d'e‑mail telle que Verimail.
Le résultat est concret : moins d'e‑mails de bienvenue en rebond, moins de tickets « Je n'ai jamais reçu », et moins d'utilisateurs d'essai perdus à cause d'une petite faute.
Une fois la détection ajoutée, traitez‑la comme tout autre changement produit : mesurez, puis ajustez selon le comportement réel. L'objectif : moins d'inscriptions ratées et moins de mauvaises adresses, sans bloquer les personnes légitimes.
Commencez par suivre un petit ensemble d'indicateurs liés à la douleur utilisateur et au coût business :
Puis itérez vos règles. Si les utilisateurs acceptent rarement une suggestion, elle est peut‑être trop agressive (par exemple suggérer gmail.com pour beaucoup de domaines rares). S'ils l'acceptent souvent, élargissez votre liste de domaines et ajustez les seuils (distance d'édition, lettres inversées, point manquant) pour coller à la production. Gardez une liste d'autorisation courte, mais apprenez aussi de votre propre trafic.
Les fautes ne sont qu'une couche. Pour réduire la fraude et protéger la délivrabilité, ajoutez des contrôles plus profonds qui confirment qu'une adresse est probablement joignable : vérifications syntaxiques conformes RFC, existence de domaine et recherche d'enregistrements MX, et correspondance avec des listes noires de fournisseurs d'e‑mail jetables et de pièges connus. Dans de nombreux produits, il est aussi utile de retourner des indicateurs de risque plutôt que des blocages stricts quand la confiance est faible.
Si vous voulez une option tout‑en‑un pour ces contrôles pendant l'inscription, Verimail (verimail.co) exécute syntaxe, domaine, MX et détection des jetables/listes noires en millisecondes et retourne un résultat clair que votre formulaire peut exploiter.
Déployez les changements progressivement. Faites un A/B test de l'UI de suggestion et des seuils de validation, ou réalisez un déploiement progressif par pourcentage de trafic. Surveillez de près les faux positifs, en particulier pour les domaines internationaux, d'entreprise et les fournisseurs moins courants. En cas de doute, laissez l'utilisateur continuer mais journalisez l'événement pour améliorer les règles avec des données.