Valider les courriels - pourquoi une regex ne suffit plus

Préambule

Je ne pensais pas écrire un article aujourd’hui sur la validation des courriels, mais une récente discussion m’a fait changer d’avis. Comme beaucoup, j’ai longtemps utilisé une simple expression régulière (regex) pour vérifier le format d’une adresse courriel saisie par un utilisateur. Après tout, la forme d’une adresse électronique semble facile à valider : on a tous déjà croisé la fameuse regex ^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$ pour « valider » un courriel. Pourtant, valider une adresse email de manière fiable est bien plus complexe, et se reposer uniquement sur une regex est une mauvaise idée.

Récemment, dans sa vidéo Regex for Email Validation? Think Again!, Derek Comartin a expliqué pourquoi cette approche n’est ni fiable ni suffisante. Cela m’a encouragé à approfondir le sujet et à partager les bonnes pratiques modernes en matière de validation des adresses courriel.

Les limites des regex pour les adresses courriel

Valider un email par regex atteint vite ses limites.

Voici pourquoi :

• Une regex ne couvre jamais tous les cas d’adresse valides. La norme RFC 5322 (et suivantes) autorise des variantes d’adresses bien plus larges que nos regex simplifiées. Par exemple, de nombreux caractères spéciaux sont permis dans la partie locale (avant le @) d’une adresse : !, #, $, %, &, ', _, /, =, ?, ^, `, {, |, } ou ~ peuvent théoriquement faire partie d’un courriel. Une regex « maison » oublie souvent d’en tenir compte, ce qui peut conduire à rejeter à tort des emails valides. De même, certaines adresses spéciales (contenant des guillemets, des caractères non-ASCII, un nom de domaine littéral en IP, etc.) respectent les standards mais ne passeront pas un filtre regex trop strict.
• À l’inverse, une regex peut accepter des adresses invalides. Même une expression régulière très élaborée peut laisser passer des adresses qui ne fonctionneront pas en pratique. Un exemple classique : une regex réputée “parfaite” autorisait tony@example.com. (avec un point à la fin) comme adresse valide, alors qu’aucun serveur de messagerie n’acceptera un courriel se terminant par un point. Autre cas : certaines implémentations basées sur le HTML5 considèrent test@test (sans domaine de second niveau) comme valide côté client, alors que cette adresse n’a pas de domaine complet et n’aboutirait pas. En bref, même les meilleurs patterns peuvent avoir des failles et donner un faux sentiment de sécurité.
• Une regex ne dit rien sur l’existence réelle de l’adresse. C’est le point le plus important. Une adresse peut très bien avoir la bonne forme et être acceptée par toutes vos validations syntaxiques, tout en n’existant pas du tout dans la réalité (domaine inexistant ou simplement aucune boîte à ce nom). La regex, aussi sophistiquée soit-elle, ne peut pas vérifier que le serveur de mail existe et que la boîte de réception est active. En d’autres termes, une validation purement syntaxique n’assure en rien que l’email pourra effectivement recevoir vos messages.

En plus de ces limites inhérentes aux regex, se reposer uniquement sur une validation côté client (front-end) est une pratique dangereuse. Tout contrôle JavaScript ou Angular peut être contourné par un utilisateur malintentionné. Si votre application ne valide les courriels qu’au niveau du navigateur, vous risquez d’enregistrer en base de données des adresses totalement invalides envoyées directement à votre serveur. Il est impératif de reproduire les validations critiques côté serveur, sans se fier exclusivement au contrôle du formulaire côté client.

Que proposent Angular, .NET et FluentValidation ?

Face à la difficulté de définir LA regex parfaite, les principaux frameworks et bibliothèques ont adopté des approches pragmatiques – soit en utilisant des patterns larges, soit au contraire en simplifiant la validation.

• Angular (Front-end) – Le validateur d’email intégré d’Angular utilise une expression régulière inspirée de la spécification HTML5 (WHATWG) avec quelques ajustements basés sur les RFC. Concrètement, Angular va vérifier que l’adresse respecte le format général (présence d’un @ et d’un point, pas de point au début/à la fin de la partie locale, longueur maximale de 254 caractères, etc.). Ce choix couvre la majorité des cas courants tout en évitant des erreurs grossières. Cependant, même cette regex “améliorée” reste une solution générique : elle peut ne pas satisfaire tous les besoins métier, surtout pour des cas extrêmes ou des domaines moins standards. Angular permet d’ailleurs de la remplacer par un pattern personnalisé si nécessaire. En somme, Angular offre une première couche de validation utile côté client, mais n’élimine pas le besoin de validations supplémentaires côté serveur.
• .NET (Back-end) – Du côté .NET, l’évolution est intéressante. Historiquement, la classe d’attribut EmailAddressAttribute (dans System.ComponentModel.DataAnnotations) utilisait une énorme expression régulière pour valider les emails (dans les versions .NET Framework 4.x et antérieures). Cette regex « monstrueuse » couvrait un grand nombre de cas, mais elle alourdissait la validation et restait imparfaite. Depuis .NET Core, Microsoft a changé d’approche : l’attribut se contente désormais de vérifier que la chaîne contient un @ qui n’est ni en première position ni en dernière position. En clair, si un texte a au moins un caractère avant et après un @, il passe la validation de base. Par exemple, "code.maze.com" sera jugé invalide (pas de @), "code@maze" invalide (le @ est en fin de chaîne après “maze”?), et "code@[email protected]" valide (même si ce n’est pas une adresse fonctionnelle). Ce choix peut surprendre, mais il est volontairement minimaliste. L’objectif de .NET ici est juste d’éliminer les entrées grossièrement incorrectes, sans tenter de capturer toutes les subtilités du RFC. Microsoft assume que la véritable validation doit se faire autrement (via un workflow d’activation, etc.), plutôt que de maintenir une regex complexe et faillible. Résultat : on évite de fausses erreurs sur des adresses valides mais un peu atypiques, en attrapant seulement les cas évidents (absences de @, etc.).
• FluentValidation (Back-end, .NET) – FluentValidation, une bibliothèque populaire de validation en .NET, aligne sa stratégie sur celle de .NET Core. Son validateur intégré EmailAddress() réalise par défaut la même vérification simplifiée : présence d’un @ non situé au début ni à la fin de la chaîne. Cette démarche est assumée pour coller au comportement d’ASP.NET Core et à l’attribut EmailAddressAttribute. Dans la documentation officielle, les auteurs expliquent que le check est intentionnellement naïf, car “faire quelque chose d’infaillible est très difficile”. Ils recommandent de valider réellement l’adresse en envoyant un email de confirmation, la validation logicielle n’ayant pour but que d’attraper les valeurs grossièrement erronées destinées à l’UI. FluentValidation offre bien la possibilité d’utiliser l’ancien mode de validation (une regex héritée de .NET 4.x) via EmailAddress(EmailValidationMode.Net4xRegex), mais cette option est désormais dépréciée et génère un avertissement – signe que la validation basée sur une regex exhaustive n’est plus recommandée. En pratique, si vous utilisez FluentValidation, le conseil est donc le même : ne faites qu’une validation de format très basique, puis déléguez le reste du travail.

En résumé, les frameworks modernes tendent à assouplir la validation syntaxique des emails plutôt qu’à la renforcer outre mesure. Angular propose une regex large couvrant les cas usuels, tandis que .NET/FluentValidation optent pour un contrôle minimal. L’idée sous-jacente est la suivante : plutôt que d’essayer de tout valider parfaitement avec du code statique (regex), mieux vaut attraper le 90% d’erreurs évidentes, et traiter le 10% restant via des mécanismes dynamiques.

Valider l’existence de l’adresse (sans envoyer de mail)

Attraper les erreurs de format, c’est bien – mais ça ne suffit pas, on l’a vu. La vraie question est : cette adresse existe-t-elle réellement ? Autrefois, certains systèmes envoyaient un email de confirmation à l’adresse fournie, espérant qu’un message invalide “reviendrait à l’expéditeur” si l’adresse n’existe pas. Mauvaise idée ! Envoyer un courriel juste pour vérifier qu’il arrive peut nuire à votre réputation : si vous envoyez en masse à des adresses invalides, les serveurs destinataires peuvent vous classer comme spammeur. De plus, vous risquez de froisser vos nouveaux utilisateurs en les obligeant à une confirmation pénible, ou pire, d’envoyer des emails non sollicités. Derek Comartin le mentionnait dans sa vidéo : cette approche n’est pas la meilleure non plus.

La solution moderne consiste à déléguer la validation réelle à un service externe spécialisé. Il existe aujourd’hui des services SaaS de vérification d’adresses email (NeverBounce, ZeroBounce, Mailfloss, Kickbox et bien d’autres) qui font ce travail de manière efficace sans envoyer de courriel au destinataire. Comment est-ce possible ? Ces services effectuent une série de contrôles techniques :

• Vérification du domaine : ils examinent si le nom de domaine de l’adresse existe et possède des enregistrements MX (serveurs de mail) configurés. Pas de serveur mail = adresse forcément invalide. Ce premier filtre permet déjà d’éliminer les domaines fantaisistes ou désactivés.
• Réponse du serveur de messagerie : le service contacte le serveur de messagerie du domaine via le protocole SMTP (comme s’il allait envoyer un message) et interroge s’il peut accepter l’adresse destinataire donnée. En simulant cette conversation avec le serveur (un ping de la boîte mail), on peut savoir si l’adresse est reconnue sans envoyer réellement de mail. Si le serveur répond “boîte inexistante” (code d’erreur 550 par ex.), on sait que l’adresse est invalide. Si au contraire on obtient une réponse positive (250 OK), c’est bon signe – l’adresse semble valide et prête à recevoir du courrier.
• Détection avancée : ces services ajoutent souvent d’autres filtres utiles, comme l’identification des adresses jetables (fournisseurs de mails temporaires), des spam traps (adresses pièges qui ne servent qu’à piéger les spammeurs), ou des adresses ayant un historique d’abus. Par exemple, ZeroBounce signale si une adresse appartient à un domaine connu pour être toxique ou si c’est un alias “catch-all” qui accepte tous les mails sans garantir la délivrabilité. Ce sont des informations importantes pour maintenir la propreté de vos listes de diffusion.

Le grand avantage de ces services est qu’ils effectuent toutes ces vérifications en temps réel via des API, généralement en quelques centaines de millisecondes, et ce de manière transparente pour l’utilisateur final. Par exemple, vous pouvez intégrer l’API de validation de NeverBounce ou ZeroBounce directement lors de l’inscription de vos utilisateurs : dès qu’ils soumettent leur adresse, une requête API vérifie en arrière-plan l’adresse et indique si elle est valide, sans que vous ayez à envoyer un seul courriel de test. Si l’adresse s’avère invalide, vous pouvez inviter l’utilisateur à la corriger, évitant ainsi d’enregistrer des contacts erronés dans votre base de données.

Exemple de service SaaS : NeverBounce est l’un de ces outils de validation très fiables et rapides. Il s’intègre facilement à vos applications via API et peut vérifier des listes entières d’emails en quelques minutes. Lors d’un test comparatif, NeverBounce a pu vérifier 800 adresses en 5 minutes, identifiant correctement plus de 650 emails valides. Ce type de service assure une vérification complète de vos courriels (domaine actif, serveur répondant, adresse existante) sans effort de votre part. L’investissement en vaut la chandelle si la qualité de vos emails est critique (campagnes marketing, envois transactionnels, etc.), car il en va de votre taux de délivrabilité et de votre réputation d’expéditeur.

En utilisant un service de validation externe, le workflow de validation “idéal” d’un courriel ressemble à ceci :

1. Validation syntaxique légère (ex. via un contrôle Angular en front-end, puis une vérification minimale côté serveur avec .NET/FluentValidation) pour attraper les erreurs de frappe grossières immédiatement.
2. Validation d’existence via un service externe pour vérifier que l’adresse existe et est opérationnelle (domaine OK, serveur OK, boîte OK), sans envoyer de mail de confirmation.
3. Prise en compte dans votre logique métier : par exemple, marquer l’adresse comme “vérifiée” dans votre base de données ou votre CRM, permettre l’inscription du compte associé, etc. Si le service retourne un statut négatif (adresse inexistante, jetable ou autre), décider du traitement (demander une autre adresse, alerter l’utilisateur, refuser l’inscription, etc.).

Ce processus à plusieurs couches assure une validation robuste tout en offrant une bonne expérience utilisateur : on ne bloque pas l’internaute sur des détails de format exotiques, mais on s’assure en coulisse que l’adresse fournie est exploitable.

Conclusion

La validation des adresses courriel ne doit plus se résumer à trouver LA regex miracle. Les pratiques ont évolué : entre les spécifications extensibles du format email et les enjeux de délivrabilité, il est clair qu’une simple regex côté client ne suffit plus pour garantir la validité d’une adresse. Il faut adopter une approche en plusieurs étapes, combinant tolérance sur le format et fermeté sur l’existence réelle.

En 2025, le bon workflow pour valider un courriel est :

• ✅ Vérifier légèrement le format (juste assez pour éviter les entrées absurdes, sans exclure à tort des adresses valides)
• ✅ Vérifier l’existence via un service externe (s’assurer que le domaine et la boîte sont valides, sans vous faire passer pour un spammeur)
• ❌ Ne plus s’acharner à écrire des regex compliquées, ni se fier uniquement à la validation du navigateur. Une regex peut filtrer le gros des erreurs, mais pas toutes, et certainement pas la délivrabilité réelle.

En appliquant ces principes, vous améliorerez la qualité des données collectées et réduirez les problèmes d’emails invalides (bounces, plaintes, etc.) qui peuvent nuire à votre plateforme.

Enfin, n’hésitez pas à documenter ce choix technologique dans votre registre de décisions interne. La manière dont vous validez les courriels est un choix d’architecture applicative important, qui mérite d’être tracé noir sur blanc. Comme le souligne Derek Comartin, garder un log de toutes les décisions clés d’un projet évite bien des devinettes par la suite, en fournissant le contexte du pourquoi chaque décision a été prise. Inscrire dans votre registre de décisions que “la validation des emails se fait via une vérification syntaxique minimale + service externe X, pour telles raisons” permettra aux futurs développeurs de comprendre et de respecter cette approche cohérente.

En somme, valider un courriel aujourd’hui, ce n’est pas chercher la perfection avec une regex interminable, c’est mettre en place un processus intelligent : souple sur le format, strict sur l’existence, et toujours documenté. Adoptez ce workflow moderne – vos utilisateurs, votre équipe et votre serveur mail vous en remercieront.