Email Verification Protocol : ce que Chrome valide vraiment et les 9 cas où ça ne vous sert à rien

Faut-il changer votre formulaire d’inscription parce que Chrome sait désormais confirmer une adresse Gmail en un clic ? Google a ouvert le 8 juillet 2026 l’origin trial d’un nouveau protocole, l’Email Verification Protocol (EVP) : l’émetteur atteste qu’une session active existe chez le fournisseur de messagerie et le navigateur transporte la preuve, sans envoi d’email de confirmation. Concrètement, ça retire une friction précise, celle du code à usage unique ou du lien de confirmation reçu par email, l’étape où votre outil d’emailing affiche tout au vert pendant que le taux de hard bounce grimpe en silence. Ce que le protocole prouve et surtout ce qu’il ne prouve pas se lit dans une grille de 12 situations de collecte.

Le mécanisme du protocole EVP, en 6 étapes

Le protocole distingue 3 rôles. Le validateur collecte l’adresse email sur son formulaire. Le fournisseur de messagerie héberge la boîte. L’émetteur, accounts.google.com pour une adresse Gmail, gère la session du compte. Posséder une adresse et avoir une session active chez son fournisseur sont deux choses distinctes : le protocole vérifie uniquement la seconde. Encore faut-il que deux conditions soient réunies. L’utilisateur doit être connecté à sa messagerie dans le même profil Chrome. Il doit aussi choisir son adresse dans l’autocomplétion plutôt que la saisir à la main. Sans elles, aucun token n’est produit. Le parcours tient en 6 étapes.

1. L’utilisateur choisit son adresse dans l’autocomplétion du navigateur, jamais en saisie manuelle.
2. Chrome interroge l’enregistrement DNS _email-verification du domaine pour identifier l’émetteur responsable.
3. L’émetteur confirme qu’une session active existe pour ce compte, sans révéler d’autre information sur l’utilisateur.
4. Il génère un Email Verification Token au format SD-JWT+KB, c’est-à-dire un jeton à divulgation sélective lié à une clé publique éphémère, signé en EdDSA ou en ES256.
5. Le token transite dans un champ caché du formulaire au moment de la soumission.
6. Le serveur du site exécute 5 contrôles : décodage du JWT, vérification de email_verified, du nonce et de l’audience, validation du key binding, interrogation DNS, puis vérification de signature via le point de terminaison well-known dédié.

Le mécanisme rappelle celui de BIMI, un autre protocole qui s’appuie sur un enregistrement DNS et une adoption fournisseur par fournisseur, jamais universelle du premier jour. Si un contrôle échoue ou si le token est absent, le site retombe sur son flux habituel. Google appelle ça une amélioration progressive.

Les méthodes de vérification actuelles obligent l’utilisateur à quitter le site, avec le risque qu’il abandonne sa session avant d’avoir terminé son inscription. Rowan Merewood, Staff Developer Relations Engineer chez Google, Chrome for Developers, 8 juillet 2026.

La grille : où le protocole répond, où il ne sert à rien

12 situations de collecte, 12 réponses différentes. Le protocole ne couvre qu’une tranche étroite du parcours d’inscription : celle où Chrome et Gmail se combinent, avec l’autocomplétion réellement utilisée sur le même profil. Sur Safari, Apple a déjà sa propre couche avec Cacher mon e-mail, un mécanisme indépendant qui redistribue les adresses de vos listes sans aucun rapport avec le protocole de Chrome.

Le cas le plus contre-intuitif tient dans une seule ligne du tableau. Une adresse jetable, hébergée chez un fournisseur qui déploierait un jour l’émetteur, passerait le contrôle EVP avec un token parfaitement valide. Le token ne mesure rien d’autre qu’une session active au moment T ; il ne dit rien sur la durée de vie prévue de la boîte, ni sur l’intention réelle derrière l’inscription. Une adresse Yopmail ou Mailinator qui disposerait de son propre émetteur signerait un token tout aussi propre qu’une adresse Gmail classique.

L’autre angle mort touche le temps. Le token confirme une possession à l’instant de l’inscription, jamais après. Sur une adresse tout juste créée, l’écart entre ce qu’affirme le protocole et la réalité de la boîte reste marginal. Passé quelques mois d’inactivité, en revanche, rien dans le mécanisme ne signale une boîte pleine ou abandonnée depuis des mois. EVP n’a d’ailleurs pas vocation à le faire : il se limite à la preuve de possession au moment de la collecte, un instantané qui se dégrade sans jamais se rafraîchir.

Une troisième zone d’incertitude touche les adresses professionnelles. Google Workspace revendiquait plus de 11 millions de clients payants au 4e trimestre 2025, chiffre annoncé par Sundar Pichai le 4 février 2026, autant d’organisations dont les boîtes sont hébergées par Google. La documentation ne dit pas si ces domaines peuvent publier l’enregistrement _email-verification et rejoindre la première colonne de la grille. La ligne du tableau reste conditionnée à l’absence de cet enregistrement, jamais au type d’adresse.

Le token EVP peut-il servir de preuve RGPD ?

La documentation Chrome ne consacre aucune section dédiée à la vie privée. Le RGPD n’y figure pas. Le consentement marketing non plus, ni la durée de conservation prévue pour le token. Ce silence renvoie la décision au responsable de traitement plutôt qu’au navigateur.

Un garde-fou existe malgré tout du côté de l’utilisateur. Chrome affiche une invite d’autorisation la première fois qu’une adresse est fournie pour validation ; cette invite ne réapparaît plus ensuite pour la même adresse. La première validation ne se joue donc pas à l’insu de la personne inscrite. Pour cette adresse, les suivantes ne redemandent plus rien.

Le token embarque des données personnelles concrètes : l’émetteur (iss), l’adresse ou son équivalent (email), un indicateur de validité (email_verified), un horodatage (iat), une clé de confirmation (cnf), l’origine du site (aud), un nonce et un hash de confirmation (sd_hash). Le stocker comme pièce justificative revient à conserver une donnée personnelle, soumise aux principes de minimisation et de limitation de conservation. Combien de temps le garder ? La documentation ne le précise pas. C’est une question à arbitrer avec votre DPO plutôt qu’avec votre prestataire technique.

Un détail change la donne côté minimisation : la claim email peut faire l’objet d’une divulgation sélective. Configurée ainsi, elle transmet un hash au lieu de l’adresse en clair au validateur, un paramétrage à vérifier avant toute mise en production.

L’article 7.1 du RGPD impose au responsable de traitement d’être en mesure de démontrer le consentement de la personne. Le clic de confirmation du double opt-in remplit ce rôle aujourd’hui. Le token EVP ne s’y substitue pas : il atteste une possession technique de la boîte à l’instant de l’inscription, sans rien dire de l’accord à recevoir des messages ensuite. Il règle en revanche un autre problème, que le double opt-in ne couvre qu’imparfaitement, celui de l’objection « ce n’est pas moi qui ai saisi cette adresse ». Le double opt-in prouve le consentement, le token prouve la possession de la boîte au moment de l’inscription : un formulaire qui combine les deux ferme les deux angles à la fois.

Sur la confidentialité du côté de l’émetteur, Google est explicite : « L’émetteur voit uniquement une demande de vérification de l’existence de l’utilisateur, il ne voit pas quel site a initié la demande. » L’architecture du token rend cette affirmation crédible : c’est le navigateur qui construit le jeton de liaison de clé portant l’origine du site et le nonce, signé avec la clé éphémère, après avoir reçu le jeton de l’émetteur. Celui-ci n’a donc jamais besoin de connaître le site destinataire pour signer sa part du token.

Deux questions restent sans réponse dans la documentation actuelle. Le rôle juridique exact de l’émetteur dans la chaîne reste non précisé : agit-il comme responsable de traitement ou comme sous-traitant ? Les transferts hors Union européenne ne sont pas davantage documentés : l’émetteur est le fournisseur qui héberge déjà la boîte mail de la personne. Rien n’est dit en revanche du traitement du token lui-même ni de sa localisation.

Calculer votre couverture réelle du protocole

Chrome représente 65,23 % des sessions navigateur dans le monde en mai 2026, un chiffre qui grimpe à 76,39 % sur desktop seul (StatCounter, mai 2026). Cette part globale ignore votre couverture EVP réelle, qui dépend uniquement de vos propres données de trafic et d’inscription. Côté messagerie, Gmail est crédité d’environ 1,8 milliard d’utilisateurs actifs dans le monde, une estimation Statista de novembre 2024 que le secteur reprend faute de publication régulière par Google. Ce volume fixe un plafond théorique, jamais votre part réelle : une base nourrie d’adresses professionnelles et une base nourrie d’inscriptions grand public ne donnent pas du tout le même pourcentage.

3 chiffres suffisent. La part de trafic Chrome sur votre formulaire d’inscription, lisible dans Google Analytics ou Matomo. La part d’adresses Gmail parmi vos inscriptions récentes, en extrayant le domaine depuis votre base ESP. Et la part de ces inscriptions où l’autocomplétion a réellement rempli le champ plutôt qu’une saisie manuelle, un chiffre qu’aucune API ne remonte nativement et qu’il faut instrumenter soi-même, par exemple en comparant les événements input et change déclenchés sur le champ email.

Multiplier les deux premiers chiffres donne un plafond haut. Le troisième, presque toujours ignoré, le fait redescendre.

Le montage à 3 étages, du token à l’envoi

Le réflexe immédiat, une fois le mécanisme compris : si Chrome valide déjà l’adresse à l’inscription, à quoi bon continuer de payer une vérification avant l’envoi ? La réponse tient dans le périmètre du token, qui s’arrête exactement là où la grille l’indique.

Le token permet de sauter l’étape du clic sur le lien de confirmation, pour les inscriptions Gmail passées par Chrome. Le double opt-in garde ainsi son rôle propre, décrit plus haut : la preuve d’un consentement actif, horodaté en pratique pour être en mesure de le démontrer comme l’exige l’article 7.1 du RGPD. Un token EVP ne remplace ni la case cochée ni l’horodatage conservés en base au moment du consentement.

Google fixe depuis 2024 un seuil de complaint rate à 0,3 % pour les envois en masse, sous peine de voir les messages marqués comme spam ou rejetés côté Gmail, un chiffre déjà visible dans les tableaux de Google Postmaster Tools par domaine expéditeur. Une adresse jetable ou une boîte fermée qui reçoit malgré tout la campagne pousse ce taux vers le haut, y compris en pleine phase d’IP warmup, indépendamment de ce qu’affichait le token à l’inscription. La délivrabilité se joue au moment de l’envoi, quand la collecte est déjà loin derrière. Ce n’est pas le premier protocole technique qui redessine un maillon de la chaîne sans supprimer les autres : DKIM2 a suivi la même logique côté authentification des messages.

Le contrôle qui vérifie la syntaxe, le domaine MX et parfois l’historique de délivrabilité avant l’envoi, celui que fait CaptainVerify, se glisse logiquement entre la collecte et la campagne. La seule façon de savoir si votre base a besoin de ce filtre, c’est de la faire passer sur un échantillon avant le prochain envoi.

Ce qu’il faut garder en base, au minimum : la trace d’opt-in RGPD, le statut du dernier contrôle de list hygiene et la date de la dernière campagne envoyée sans rebond. Le token EVP, lui, n’a pas vocation à être stocké au-delà de la session d’inscription.

Gmail reste aujourd’hui le seul émetteur grand public. Le protocole, lui, est porté par les navigateurs Chromium : Chrome depuis sa version 150, Edge via son propre origin trial côté Microsoft. Sa trajectoire de normalisation est déjà tracée : un Internet-Draft signé Dick Hardt et Sam Goto est déposé à l’IETF depuis le 17 juin 2026, dans une révision datée du 4 juillet, en soumission individuelle, sans groupe de travail ni validation à ce stade. Validity estime dans son analyse de juillet 2026 que le double opt-in fait perdre 20 à 35 % des inscrits au moment de la confirmation, une friction qu’EVP pourrait effectivement réduire côté Gmail. Si Outlook ou Yahoo déploient un jour leur propre émetteur, la première colonne de la grille s’élargira ; sans eux, elle reste circonscrite à Gmail.

Questions fréquentes sur l’Email Verification Protocol

Le protocole EVP fonctionne-t-il sur mobile ou dans une application ?
La documentation ne tranche pas explicitement ce point. Le protocole suppose l’autocomplétion du navigateur, ce qui exclut de fait les contextes où elle n’est pas disponible, notamment certains navigateurs in-app.

Quels navigateurs supportent EVP en 2026 ?
Chrome depuis la version 150, via l’origin trial ouvert le 8 juillet 2026. Edge suit avec son propre origin trial, listé dans la section Implementation Status du draft IETF : même mécanisme Chromium, avec un jeton à enregistrer côté Microsoft, distinct de celui de Chrome. Côté Safari, aucune annonce à ce jour.

Le protocole fonctionne-t-il avec Outlook ou Yahoo ?
Pas encore. Gmail est le seul fournisseur de messagerie à émettre des tokens au lancement. L’API destinée aux autres fournisseurs de messagerie reste en développement chez Google.

Faut-il activer l’origin trial dès maintenant ?
Seulement si Chrome et Gmail représentent une part mesurable de vos inscriptions. Le trial impose des limites de trafic et un fallback obligatoire vers l’email de confirmation classique en cas d’échec.