Regex pour la validation d'e-mail : des patterns qui fonctionnent vraiment

La validation d'e-mail est l'un des cas d'utilisation les plus courants des regex — et l'un des plus mal compris. La spécification RFC 5321 pour les adresses e-mail est étonnamment complexe, et aucune regex unique ne peut la valider entièrement. Mais des patterns pratiques qui couvrent 99,9 % des adresses e-mail réelles sont à la fois réalisables et utiles.

Le pattern simple (suffisant)

Pour la plupart des applications, ce pattern fonctionne bien :

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

Ce qu'il correspond : Un ou plusieurs caractères autorisés, suivis de @, suivis d'un domaine avec au moins un point et un TLD de 2+ lettres.

JavaScript :

const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
emailRegex.test('user@example.com');  // true
emailRegex.test('user@.com');          // false

Testez ce pattern avec notre Testeur de Regex.

Pourquoi une validation parfaite par regex est impossible

La spécification e-mail (RFC 5321/5322) autorise des structures qui sont valides mais essentiellement jamais utilisées en pratique :

"john..doe"@example.com           // Quoted local part with consecutive dots
user@[192.168.1.1]                // IP address as domain
"very.(),:;<>[]".VERY."very@\ "very".unusual"@strange.example.com

Une regex qui gère toutes les adresses valides selon la RFC fait des milliers de caractères et peut encore ne pas couvrir chaque cas limite. L'approche pratique : utiliser une regex simple pour la validation basique du format, puis vérifier que l'e-mail existe réellement en envoyant une confirmation.

Décomposition du pattern

Partie locale (avant @)

[a-zA-Z0-9._%+-]+

• Lettres (majuscules et minuscules)
• Chiffres
• Points, underscores, pourcentage, plus, tiret
• Un ou plusieurs caractères

Erreurs courantes :

• Autoriser les points au début ou à la fin (techniquement invalide)
• Autoriser les points consécutifs (techniquement invalide sans guillemets)
• Être trop restrictif (bloquer des caractères valides comme + utilisé dans les alias Gmail)

Partie domaine (après @)

[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

• Caractères alphanumériques, points, tirets
• Au moins un point
• TLD de 2+ caractères alphabétiques

Erreurs courantes :

• Restreindre la longueur du TLD à 3-4 caractères (.museum, .photography existent)
• Ne pas autoriser les tirets dans les noms de domaine
• Ne pas gérer les sous-domaines (user@mail.example.co.uk)

Meilleurs patterns

Standard HTML5

La spécification HTML5 définit ce pattern pour <input type="email"> :

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$

Celui-ci est plus permissif dans la partie locale et plus strict sur la longueur des labels de domaine.

Pattern pratique recommandé

^[^\s@]+@[^\s@]+\.[^\s@]{2,}$

Ce pattern minimal vérifie simplement : pas d'espaces, un @, au moins un point après @, TLD de 2+ caractères. Il est intentionnellement permissif — capturant les entrées manifestement erronées sans rejeter les adresses inhabituelles mais valides.

Implémentation par langage

JavaScript

function isValidEmail(email) {
  // Basic regex check
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/;
  if (!regex.test(email)) return false;
  
  // Additional checks
  if (email.length > 254) return false;  // RFC 5321 limit
  const [local] = email.split('@');
  if (local.length > 64) return false;   // RFC 5321 limit
  
  return true;
}

Python

import re

def is_valid_email(email: str) -> bool:
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    if not re.match(pattern, email):
        return False
    if len(email) > 254:
        return False
    local, domain = email.rsplit('@', 1)
    if len(local) > 64:
        return False
    return True

Au-delà de la Regex : une validation d'e-mail correcte

La regex n'est que la première ligne de défense. Une stratégie de validation complète :

1. Vérification du format (regex) : Rejeter les formats manifestement invalides
2. Vérification de longueur : Partie locale ≤ 64 caractères, total ≤ 254 caractères
3. Vérification DNS : Vérifier que le domaine possède des enregistrements MX
4. Détection d'e-mails jetables : Bloquer les services d'e-mail temporaires si nécessaire
5. E-mail de confirmation : Le seul moyen de véritablement vérifier un e-mail — envoyer un message et confirmer que l'utilisateur le reçoit

// DNS MX record check (Node.js)
const dns = require('dns');
const [, domain] = email.split('@');
dns.resolveMx(domain, (err, addresses) => {
  if (err || !addresses.length) {
    console.log('Domain has no email server');
  }
});

Erreurs courantes à éviter

1. Patterns trop restrictifs : Bloquer user+tag@gmail.com (adressage plus) ou user@subdomain.example.com
2. Sensibilité à la casse : Les parties locales d'e-mail peuvent être sensibles à la casse selon la RFC, mais en pratique, traitez-les comme insensibles à la casse
3. Suppression des espaces : Toujours supprimer les espaces avant la validation — " user@example.com " devrait passer
4. Domaines internationaux : .münchen et 用户@例え.jp sont valides dans les e-mails internationalisés

Pour plus de patterns regex, consultez notre Aide-mémoire Regex.

FAQ

Dois-je valider l'e-mail avec une regex côté client ou côté serveur ?

Les deux. La validation côté client offre un retour instantané (meilleure UX). La validation côté serveur est obligatoire pour la sécurité (les vérifications côté client peuvent être contournées). Ne faites jamais confiance uniquement à la validation côté client.

Pourquoi certains sites web rejettent-ils mon adresse e-mail valide ?

Les patterns regex trop restrictifs en sont la cause habituelle. Les adresses avec + (alias Gmail), les TLD longs (.technology) ou les sous-domaines sont souvent rejetés par une mauvaise validation. Si vous maintenez un site web, utilisez une regex permissive et vérifiez avec un e-mail de confirmation à la place.

Ressources associées

• Testeur de Regex — Testez vos patterns de validation d'e-mail en temps réel
• Aide-mémoire Regex — Référence complète des patterns regex
• Guide de validation de schéma JSON — Validez les champs e-mail en JSON avec format: email