Faut-il encore vérifier une adresse email avant de l’ajouter à une liste, si Chrome s’en charge déjà à l’inscription ? Non. Le protocole Email Verification Protocol (EVP), testé par Google depuis juillet 2026, confirme qu’un utilisateur contrôle une session active chez son fournisseur de messagerie au moment du formulaire ; il ne dit rien sur ce que devient l’adresse ensuite, ni sur ce qui atterrit vraiment en boîte de réception. Le brouillon IETF coécrit par Google et Hellō, draft-hardt-email-verification-01 (juillet 2026), décrit un jeton cryptographique signé, transmis au site sans envoi d’email. Gmail a rejoint l’essai le 10 juillet 2026, selon les informations rapportées par Piunikaweb.
Qu’est-ce que l’Email Verification Protocol de Google ?
L’Email Verification Protocol formalise un rôle que jouaient jusqu’ici les liens magiques et les mots de passe à usage unique : prouver qu’une personne contrôle l’adresse qu’elle vient de saisir. Rowan Merewood, ingénieur chargé des relations développeurs Chrome chez Google, présente le protocole comme une réponse à un problème de conversion précis, documenté dans le billet officiel de Chrome for Developers publié le 8 juillet 2026 : chaque étape qui oblige l’utilisateur à quitter le site augmente le risque d’abandon de session. Le brouillon IETF associé distingue le validateur, qui collecte l’adresse, le fournisseur de messagerie comme gmail.com et surtout l’émetteur, le service qui gère réellement la session du compte (accounts.google.com), une distinction que beaucoup de sites confondent. L’essai tourne sous forme d’origin trial dans Chrome 150. Gmail y participe déjà, ce qui couvre une base d’utilisateurs considérable pour un test encore expérimental.
Comment le protocole vérifie une adresse sans envoyer d’email ?
Un utilisateur ouvre un formulaire d’inscription sur un site participant à l’essai. Chrome lui propose son adresse Gmail via l’autocomplétion ; il clique une fois et rien ne se passe ensuite à l’écran, sinon la validation du formulaire. Derrière cette apparente simplicité, le protocole exécute une séquence en 9 étapes définies dans le brouillon IETF. Le navigateur découvre d’abord les comptes de messagerie disponibles sur le profil, puis lie la session à un nonce généré par le site. Une fois l’adresse choisie, Chrome envoie une requête POST vers l’endpoint /issuance de l’émetteur ; celui-ci vérifie que les cookies de session correspondent bien à un utilisateur connecté et propriétaire de l’adresse demandée, puis crée un jeton signé appelé EVT (Email Verification Token). Le navigateur y ajoute un second jeton, un KB-JWT, qui empêche le rejeu de la preuve, avant de transmettre l’ensemble au site validateur. Deux garde-fous limitent l’abus. La première utilisation d’une adresse déclenche une invite d’autorisation explicite, affichée une seule fois par adresse. Et l’ensemble du flux exige que l’utilisateur soit connecté à son fournisseur de messagerie sur le même profil de navigateur que celui utilisé pour le formulaire.
Ce que ça change réellement pour les expéditeurs
Sur le papier, EVP ressemble à un simple argument de conversion pensé par une équipe produit. Le protocole traite pourtant un problème adjacent à celui des équipes deliverability, sans jamais le résoudre : il confirme une identité au moment de la capture, jamais la délivrabilité au moment de l’envoi. Une adresse validée par EVP en janvier peut devenir un spam trap reconverti six mois plus tard ou tout simplement un compte fermé après le départ d’un salarié. Le complaint rate, le taux de plainte mesuré par Gmail, reste totalement étranger au protocole ; un rejet (bounce) survient toujours au moment de l’envoi, jamais à l’inscription. Ce que EVP change, c’est le volume d’adresses collectées : moins d’abandon de formulaire signifie plus d’adresses à surveiller dans le temps. Le protocole résout un problème d’entrée mais laisse le suivi dans le temps à d’autres mécanismes ; chacun intervient à un moment différent du parcours d’envoi.
Trois mécanismes, trois moments de vérification
Authentifier un expéditeur (SPF, DKIM, DMARC) et vérifier un destinataire (EVP, double opt-in) ne se jouent ni au même moment ni avec les mêmes outils.
| Critère | EVP (Chrome) | Double opt-in | SPF / DKIM / DMARC |
|---|---|---|---|
| Moment de vérification | À l’inscription, côté navigateur | Après l’inscription, par email | À chaque envoi, côté serveur |
| Ce qui est vérifié | Session active chez le fournisseur de messagerie | Réception effective et clic de confirmation | Autorisation d’expédition, intégrité du message |
| Ce qui n’est pas couvert | Délivrabilité, engagement, validité dans le temps | Rapidité du parcours d’inscription | Propriété réelle de l’adresse destinataire |
L’angle mort que Google reconnaît lui-même
Google ne prétend pas qu’EVP résout la délivrabilité. Rowan Merewood le formule sans détour dans le billet officiel :
La vérification d’email confirme que l’utilisateur a une session active chez son fournisseur de messagerie. Elle ne confirme pas que votre email a atteint le destinataire. (Rowan Merewood, Chrome for Developers, 2026)
L’aveu est rare pour un document qui vante son propre protocole. Il rejoint une érosion de signaux déjà entamée ailleurs, une hygiène de liste qui devient plus difficile à mesurer à mesure que les indicateurs d’engagement disparaissent : Apple Mail Privacy Protection tue le taux d’ouverture comme métrique fiable depuis 2021, sans qu’aucun remplaçant équivalent n’émerge depuis. Le clic de confirmation du double opt-in disparaît à son tour si EVP se généralise, ce qui prive les équipes deliverability d’un signal d’engagement de plus, au profit d’un signal d’identité qui ne mesure rien côté boîte de réception. Le protocole suppose aussi une session active côté fournisseur de messagerie, dans le même profil de navigateur que le formulaire. Hors Chrome ou sans session active chez le fournisseur de messagerie, le flux retombe simplement sur les méthodes actuelles. Un alias transféré vers une autre boîte échappe lui aussi à la vérification. Les données agrégées par Google Postmaster Tools restent, à ce jour, le seul indicateur agrégé de réputation IP disponible côté expéditeur ; EVP ne les remplace pas. Le filtre qui reste pertinent s’applique après l’inscription : mesurer le rejet réel d’un échantillon de liste avant chaque campagne capture ce qu’EVP ne verra jamais, l’état d’une adresse plusieurs mois après sa collecte. Le compte émetteur de démonstration fourni par Google reproduit ce même scénario côté fournisseur de messagerie, sans nécessiter de compte Gmail réel pour les équipes qui veulent auditer le flux avant de l’intégrer.
L’EVP remplace-t-il le double opt-in et la vérification de liste ?
Non, selon Google lui-même. Le protocole confirme une identité à l’instant T. Il ne mesure ni un consentement ni la validité d’une adresse encore active six mois plus tard. Les équipes qui supprimeraient leur email de bienvenue perdraient le seul signal prouvant qu’un message a réellement été reçu.
Quels navigateurs et fournisseurs participent à l’essai en 2026 ? Chrome 150 héberge le test sous forme d’origin trial depuis le 8 juillet 2026. Gmail a rejoint l’expérimentation début juillet. Aucun autre navigateur majeur n’a annoncé de support à cette date.
Un site peut-il tester EVP dès maintenant ? Oui, via inscription à la phase d’essai sur developer.chrome.com et intégration d’un jeton sur la page du formulaire. Google fournit un compte émetteur de démonstration et un compte validateur pour tester le flux sans compte Google réel.
Un formulaire peut désormais reconnaître une adresse en une fraction de seconde. Il ne saura jamais si, de l’autre côté, quelqu’un a encore envie d’ouvrir la boîte de réception.
