Vérification d’e-mail dans Chrome : où placer l’API dans un parcours d’inscription

Pour un site qui crée des comptes, l’API de vérification d’adresse e-mail de Chrome promet de confirmer qu’un visiteur contrôle l’adresse saisie sans lui envoyer de code ni de lien de confirmation. InfoQ rapporte que l’essai a commencé dans Chrome 150 sur ordinateur, avec Gmail comme premier fournisseur participant.

Son article du 28 octobre 2026 décrit toutefois une proposition encore expérimentale, pas une solution à considérer comme universellement disponible.

Le compte rendu d’InfoQ sur l’Email Verification API fournit le point de départ pour cadrer un éventuel essai.

La décision utile n’est donc pas de remplacer immédiatement la confirmation classique. Elle consiste à déterminer si ce mécanisme peut simplifier un parcours précis, quels contrôles restent à la charge du site et comment l’inscription continue lorsque le navigateur ou le fournisseur ne participe pas.

Un jeton entre le navigateur, le site et le fournisseur

Le modèle décrit distribue les rôles entre le site vérificateur, le fournisseur émetteur et le navigateur qui relaie le jeton. Si l’utilisateur est déjà connecté à son fournisseur, le navigateur récupère un jeton signé et l’ajoute au formulaire ; le serveur du site vérifie ensuite ce jeton lors de la soumission. Le mécanisme vise ainsi à éviter le détour par la boîte de réception pour cette étape de vérification.

Le formulaire demande notamment une indication d’autocomplétion sur le champ e-mail et un champ caché transportant un nonce lié à la session. Le contrôle déterminant reste côté serveur : le serveur doit vérifier la signature à partir des clés du fournisseur. InfoQ rapporte aussi un exemple Next.js et un paquet npm présentés par Phil Nash de Resend ; leur existence ne dispense pas une équipe de vérifier leur adéquation au contrat technique retenu.

Cette séparation a une portée précise. InfoQ rapporte que Google présente la médiation du navigateur comme empêchant le fournisseur de savoir quel site a fait la demande. Ce point ne suffit pas à conclure que l’ensemble du parcours est anonyme : le même compte peut ensuite recevoir des messages de bienvenue ou de suivi. L’article rapporte des commentaires qui soulèvent cette réserve ; ce sont des objections exprimées dans la discussion, pas une mesure indépendante de confidentialité.

Chronologie technique rapportée

1. Chrome 150 : l’essai initial est décrit sur ordinateur, avec Gmail comme premier fournisseur participant.

2. Chrome 154 : le compte rendu mentionne l’ajout d’Android et d’essais d’origine avec des fournisseurs tiers, ainsi qu’un changement de valeur pour Sec-Fetch-Dest vers email-verification.

3. Chrome 156 : InfoQ indique que l’adresse renvoyée est alors celle exactement soumise par l’utilisateur.

Ces versions sont celles rapportées dans l’article d’InfoQ ; elles ne constituent pas, à elles seules, une garantie de disponibilité dans l’environnement d’une entreprise. Une équipe qui expérimente doit vérifier le contrat applicable à sa version de navigateur et suivre les changements susceptibles de casser l’intégration.

Démonstrateur fictif : décider avant de modifier l’inscription

Considérons un démonstrateur explicitement fictif : une PME veut réduire les abandons pendant la création de comptes sur son extranet client. Aucun résultat de conversion n’est supposé ici. L’équipe commence par cartographier le parcours actuel : saisie de l’adresse, envoi du message, ouverture de la boîte de réception, retour au site, puis activation du compte.

Elle peut alors isoler la question à tester : le détour par le message constitue-t-il un irritant assez important pour justifier un mécanisme expérimental ?

Le périmètre du pilote reste volontairement limité à un parcours et à un navigateur configuré pour l’essai. Le parcours existant demeure accessible à tous les autres cas. Cette approche évite de faire dépendre la création d’un compte d’un fournisseur participant ou d’une version particulière de Chrome, situations pour lesquelles InfoQ décrit un retour à la confirmation par e-mail classique.

Ces options ne se substituent pas mécaniquement les unes aux autres. InfoQ indique que les contrôles de syntaxe, MX et SMTP établis restent utiles pour les adresses que l’API ne couvre pas. Pour diagnostiquer spécifiquement un problème d’envoi vers un serveur, un test SMTP en ligne ou Swaks selon l’endroit où l’envoi échoue relève d’un besoin complémentaire, pas du même parcours de vérification de possession.

Arbitrer les coûts et les risques

Le coût du pilote ne se résume pas à l’ajout du champ dans le formulaire. Le travail serveur de validation de la signature est explicitement présenté comme la partie la plus lourde. Avant de chiffrer, l’équipe peut faire estimer séparément l’intégration du formulaire, la récupération et la gestion des clés du fournisseur, la validation du jeton, le parcours de repli, les tests et la maintenance lors des évolutions du contrat. Aucun montant ne peut être déduit des éléments rapportés.

Trois risques méritent une décision explicite. D’abord, un comportement différent selon le navigateur ou le fournisseur peut créer des inscriptions inégales : le repli doit donc être testé, et pas seulement prévu sur le papier. Ensuite, les adresses utilisant un alias que le fournisseur ne peut pas attester peuvent imposer le parcours classique.

Enfin, la promesse de confidentialité doit rester limitée à la relation entre l’émetteur et le site au moment de la demande ; les messages envoyés ensuite par le site relèvent d’autres flux et d’autres choix.

Pour un responsable métier, le bénéfice attendu doit être formulé sans promettre un gain de conversion. Les commentaires rapportés par InfoQ évoquent la friction du changement de contexte et les messages parfois bloqués ou classés comme indésirables. Ce sont des motifs plausibles à vérifier dans son propre parcours, non des résultats mesurés pour une PME donnée.

Un pilote peut comparer les étapes atteintes et les échecs observés, à condition de définir auparavant son périmètre, ses critères et les données nécessaires.

Livrables à demander avant le pilote

• Un schéma du parcours avec les conditions d’usage de l’API et le chemin de repli par e-mail.

• Une description du contrôle serveur : données reçues, validation de signature, clés utilisées et traitement d’un jeton invalide.

• Une matrice de tests couvrant les cas avec et sans fournisseur participant, les adresses alias et les erreurs de soumission.

• Un protocole de mesure défini avant le lancement, sans confondre évolution observée et causalité démontrée.

• Une note de maintenance indiquant comment suivre les changements de versions et qui décide de suspendre ou poursuivre l’essai.

La bonne décision peut être de ne rien intégrer tant que le parcours actuel n’est pas documenté ou que le repli n’est pas maîtrisé. Si un essai est justifié, conserver la confirmation classique et isoler l’API comme amélioration progressive permet d’évaluer le mécanisme sans en faire une dépendance critique. Le critère de sortie est simple : l’équipe doit pouvoir expliquer qui atteste l’adresse, qui valide le jeton et ce qui se passe lorsque l’un des acteurs manque.