2026 Firebase Auth : tester l’e-mail de vérification local ?

Le lien de vérification apparaît dans le terminal, mais aucun message n’arrive dans votre boîte de réception.

La solution la plus rapide : pour le développement local et les tests automatisés, utilisez Firebase Authentication Emulator et récupérez le lien qu’il génère. Vous n’avez pas besoin d’une boîte externe pour vérifier le parcours simulé. En préproduction, ajoutez un test avec une adresse de réception dédiée : l’émulateur ne prouve ni la livraison réelle, ni le bon fonctionnement de votre domaine de messagerie.

Vous trouverez ci-dessous les contrôles manuels et automatisés, les erreurs à éviter dans un gestionnaire personnalisé, puis les critères d’acceptation adaptés à chaque environnement.

Émulateur local ou réception réelle

Firebase Auth distingue le parcours simulé du parcours de livraison. Lorsqu’un test s’exécute avec Firebase Authentication Emulator, le lien de vérification généré est disponible dans la sortie du terminal. Vous pouvez donc tester la suite de votre application sans attendre un message envoyé à une boîte externe. La documentation officielle de l’émulateur Auth décrit cette sortie et les opérations prises en charge.

Cela répond à une question fréquente : l’émulateur envoie-t-il le courriel de vérification à une vraie adresse ? Non. Le lien affiché par l’émulateur sert à exercer le parcours simulé. Il ne permet pas de conclure que le service d’envoi utilisé hors émulateur fonctionne, ni que le message parviendra à une boîte de réception réelle.

Cette distinction évite trois erreurs coûteuses :

• Confondre la génération du lien et la réception du message. Un lien exploitable dans la sortie locale prouve que le scénario simulé a produit une action. Il ne valide pas la configuration de livraison du projet utilisé en préproduction.
• Ne vérifier que l’écran de confirmation. Une page qui affiche « adresse vérifiée » peut avoir un texte correct sans que l’état de l’utilisateur ait été rechargé ou actualisé dans l’application.
• Tester avec un compte non maîtrisé. Des adresses personnelles ou celles de collègues mêlent les données de test aux échanges professionnels et peuvent recevoir des messages hors du scénario prévu. Pour éviter cette exposition, définissez une règle de séparation entre données de test et informations personnelles ; le guide de confidentialité de tmp10 peut vous aider à cadrer ce choix.

Le test local répond donc à une question précise : le code de votre application sait-il traiter une action de vérification et mettre à jour l’état du compte ? Pour vérifier le transport réel, le domaine, la réception et les redirections déployées, il faut un contrôle de préproduction avec une adresse de test.

Vérification manuelle dans le navigateur

Comment obtenir localement le lien de vérification Firebase Auth ? Démarrez l’émulateur Auth, configurez votre application pour lui envoyer les opérations d’authentification, puis déclenchez une inscription avec une adresse de test. Après la demande d’envoi de vérification, consultez le terminal qui exécute l’émulateur et relevez le lien associé à l’utilisateur créé. Ce lien est destiné à la simulation : il ne faut pas le traiter comme la preuve d’un courriel reçu dans une boîte réelle.

Pour une vérification manuelle reproductible, procédez dans cet ordre :

1. Lancez votre application en mode local et confirmez qu’elle utilise bien l’émulateur Auth. Vérifiez la configuration au démarrage, plutôt que de supposer que le mode local est actif parce que l’interface indique « développement ».
2. Créez un utilisateur propre au scénario. Utilisez une adresse réservée au test, et notez un identifiant permettant de retrouver ce compte sans ambiguïté.
3. Déclenchez l’envoi de l’e-mail de vérification depuis le parcours normal de votre application. Ne sautez pas directement à l’ouverture du lien : cette étape contrôle aussi que l’inscription appelle la bonne action.
4. Récupérez le lien dans la sortie de l’émulateur. Associez-le au compte créé pour ce test. Si plusieurs scénarios s’exécutent, ne choisissez pas simplement le dernier lien apparu.
5. Ouvrez le lien dans un navigateur et observez la réponse du gestionnaire de vérification. Notez si le traitement aboutit, s’il affiche une erreur ou s’il renvoie vers une page inattendue.
6. Revenez à l’application et actualisez l’état utilisateur. Vérifiez ensuite que le compte concerné est bien marqué comme vérifié. Une page de succès seule ne valide pas ce contrôle.
7. Supprimez le compte de test ou réinitialisez l’émulateur selon votre procédure. L’objectif est de ne pas laisser d’anciens comptes influencer le résultat d’une prochaine exécution.

Après l’ouverture du lien, comment confirmer que l’adresse est vérifiée ? Contrôlez l’état de l’utilisateur dans l’application après actualisation des données d’authentification. Dans le SDK JavaScript, reload(user) permet de recharger les informations de l’utilisateur ; la propriété emailVerified indique alors l’état de vérification. La référence officielle du SDK JavaScript documente également applyActionCode, utilisé pour appliquer le code d’action.

Le contrôle doit relier trois éléments : le compte créé pour le scénario, le lien qui lui correspond et l’état observé après traitement. Si le lien s’ouvre correctement mais que l’application affiche toujours l’adresse comme non vérifiée, cherchez d’abord un défaut de rechargement ou une confusion entre plusieurs comptes. Ne modifiez pas le résultat attendu pour le faire correspondre à un texte de confirmation.

Automatisation par code d’action

En test automatisé, le lien visible dans une sortie de terminal peut être difficile à associer de façon fiable au scénario qui vient de s’exécuter. Firebase fournit une interface REST réservée à l’émulateur pour consulter les codes d’action en attente. La référence officielle de l’API REST Auth décrit la route de l’émulateur GET /emulator/v1/projects/{projectId}/oobCodes et la réponse contenant notamment les champs email, oobCode, oobLink et requestType.

Vous pouvez intégrer ce mécanisme à votre scénario automatisé sans dépendre d’une boîte réelle :

• créez l’utilisateur dans l’émulateur avec une adresse réservée au test ;
• déclenchez l’envoi de la vérification par le même parcours que celui utilisé par l’application ;
• interrogez l’interface de l’émulateur configurée pour le projet de test ;
• sélectionnez le code dont l’adresse et le type d’action correspondent à ce scénario ;
• transmettez le code au flux de l’application, puis appliquez-le avec la méthode prévue par le SDK ;
• rechargez l’utilisateur et vérifiez emailVerified ;
• supprimez le compte de test ou remettez l’environnement dans l’état attendu.

Cette association par adresse et par type d’action limite les faux positifs. Si un test récupère seulement « le dernier code disponible », un résultat d’une exécution précédente ou d’un autre scénario peut être pris pour le sien. C’est particulièrement risqué lorsque les tests sont relancés sans nettoyage ou lorsque plusieurs comptes sont créés pendant une même suite.

Le code doit également vérifier le résultat, pas seulement l’absence d’exception. Une assertion utile porte sur l’identité du compte concerné et sur son état après rechargement. Si vous faites passer l’opération par votre interface, vérifiez aussi que l’écran correspondant à l’utilisateur courant reflète le nouvel état. Ainsi, le test détecte aussi bien un défaut de traitement du code qu’un défaut d’actualisation de l’interface.

Pour la stabilité, gardez l’adresse, l’identifiant du compte et le code d’action dans le même contexte de test. Ne partagez pas une boîte ou un utilisateur entre scénarios qui peuvent se chevaucher. Enfin, nettoyez explicitement les comptes créés : la répétition de tests sur un émulateur conservant des données peut rendre le diagnostic trompeur, surtout si la suite sélectionne un code à partir d’un résultat ancien.

Gestionnaire personnalisé et liens d’action

Une application peut utiliser une page de traitement personnalisée pour présenter les actions par e-mail. Dans ce cas, tester seulement l’ouverture du lien par défaut ne suffit pas. Vérifiez que votre page récupère le code d’action, identifie le type d’action attendu, applique le traitement approprié et restitue un résultat compréhensible.

La documentation Firebase consacrée au gestionnaire d’e-mail personnalisé fournit les repères d’implémentation. Pour le test de vérification, contrôlez au minimum :

• Le code manquant ou invalide. La page ne doit pas afficher une réussite si aucun code valable n’a été appliqué.
• Le code expiré ou déjà utilisé. Le retour doit expliquer que l’action ne peut pas aboutir et proposer une suite cohérente, par exemple revenir à la connexion ou demander un nouvel e-mail.
• Le type d’action. Une page destinée à la vérification doit traiter la vérification comme telle et ne pas confondre cette opération avec une autre action de compte.
• La destination après traitement. Si le lien contient une destination de continuation, vérifiez qu’elle renvoie vers une page autorisée et pertinente pour le scénario.
• La cohérence de l’état. Une fois l’action appliquée, retournez dans l’application et vérifiez l’état actualisé, plutôt que de vous fier uniquement au message de la page.

Lorsqu’un état doit être transmis dans un lien d’action, vérifiez également le comportement prévu pour le retour vers l’application. La documentation officielle sur la transmission d’état dans les actions par e-mail explique les paramètres de continuation à prendre en compte. En test, incluez une destination valide, puis une valeur absente ou incorrecte si votre application en accepte une. Le but est de vérifier le comportement réellement déployé, pas de considérer qu’une URL présente dans le lien est sûre par défaut.

Ne transformez pas les détails de page en contrat implicite avec l’utilisateur. Un code rejeté doit produire un état d’échec, et une destination de continuation doit être traitée selon les règles de votre application. Si votre interface accepte des paramètres de lien, vérifiez qu’ils ne conduisent pas à une page inattendue et que le parcours reste compréhensible lorsque l’action ne peut pas être appliquée.

Critères selon l’environnement

Les attentes varient selon l’endroit où vous exécutez le test. En local et dans l’intégration continue, l’objectif principal est le traitement du code et l’état du compte simulé. En préproduction, il faut aussi vérifier qu’un message réel arrive, que le lien cible le bon gestionnaire et que le retour dans l’application fonctionne. Une adresse de test dédiée protège mieux vos comptes personnels, mais son acceptation par un service dépend de la configuration et des règles de ce service : ne présumez pas que toutes les adresses temporaires sont acceptées.

Comment vérifier avant la mise en ligne que le courriel Firebase Auth arrive réellement ? Déclenchez une inscription dans l’environnement de préproduction avec une boîte de test contrôlée. Confirmez la réception du message, ouvrez le lien reçu — et non un lien copié depuis la sortie locale — puis vérifiez le domaine cible, le traitement de l’action et l’état du compte dans l’application déployée. C’est cette séquence qui teste la chaîne réelle.

Pour la préproduction, consignez le résultat comme un contrôle distinct : message reçu ou non, lien ouvert ou non, action appliquée ou non, état final correct ou non. Évitez une seule mention « e-mail vérifié », qui ne permet pas de savoir à quelle étape le parcours a échoué. Si le message n’arrive pas, examinez la configuration et le trajet de livraison dans cet environnement ; un test réussi dans l’émulateur ne permet pas d’écarter un défaut d’envoi réel.

Pour choisir l’adresse de test, considérez aussi la confidentialité et la durée pendant laquelle vous devez pouvoir retrouver les messages. Une boîte temporaire peut convenir à un contrôle ponctuel, tandis qu’un compte durable ou une adresse d’équipe est préférable si plusieurs personnes doivent consulter les résultats ou si les messages doivent être conservés. Le guide de tmp10 sur la durée de vie des adresses aide à réfléchir à cette limite sans confondre réception ponctuelle et conservation durable. Si vous devez recevoir des messages de suivi ou garder un accès stable, prenez en compte les limites d’une adresse temporaire avant d’en faire le compte de référence de l’équipe.

Pour un test isolé de livraison en préproduction, tmp10 peut aussi servir de boîte de réception de test, afin de ne pas exposer votre adresse personnelle à un parcours de validation. Utilisez cette option comme un contrôle de réception distinct, jamais comme une dépendance de Firebase Authentication Emulator. Si le message doit être conservé, si vous devez répondre ou récupérer durablement le compte, choisissez plutôt une adresse maîtrisée par votre équipe. Pour un contrôle ponctuel, vous pouvez ouvrir tmp10 sans inscription et vérifier le message reçu sans encombrer votre boîte principale.

Conseil produit TMP10 · Passer à l’action

Jetez la boîte à codes, transférez ce qui doit durer

Pour un code de vérification ponctuel, générez une boîte temporaire : elle s’autodétruit à l’échéance. Pour les comptes qui continueront d’écrire, isolez votre vraie adresse derrière un alias de transfert privé.

Générer une boîte de réception temporaireAccéder au transfert privé