Les détails ci-dessous proviennent de la documentation de Firebase au 23 octobre 2026. Consultez-la pour connaître les limites actuelles. Pour les bases, ce qu’envoie Firebase et comment le tester, commencez par Tester les e-mails de Firebase Authentication.
L’e-mail n’arrive jamais
Rien ne l’a demandé. createUserWithEmailAndPassword crée le compte et n’envoie aucun e-mail. Votre code d’inscription doit appeler sendEmailVerification pour le nouvel utilisateur. Sinon, le compte reste non vérifié et le testeur attend pour rien.
L’adresse n’a pas de compte. Avec la protection contre l’énumération des e-mails, activée par défaut pour les projets créés à partir du 15 septembre 2023, sendPasswordResetEmail n’envoie que si l’adresse appartient à un compte, et ne renvoie aucune erreur sinon. Un test de réinitialisation avec une adresse jamais inscrite réussit dans votre app et ne reçoit rien. Inscrivez-vous d’abord, puis réinitialisez.
Une limite quotidienne est atteinte. Avec le forfait gratuit Spark, Firebase envoie 5 connexions par lien e-mail par jour, 150 réinitialisations de mot de passe et 1 000 e-mails de vérification. La connexion sans mot de passe s’arrête après le cinquième test de la journée. Ajoutez la facturation (Blaze) pour la préproduction, ou testez la connexion par lien e-mail avec parcimonie.
Il est dans les spams. Par défaut, les e-mails viennent de l’adresse firebaseapp.com de votre projet noreply@, dont certaines boîtes de réception se méfient. Configurez votre propre domaine dans les modèles d’e-mail de la console. Une adresse Proxy Mail QA les reçoit dans tous les cas, vous pouvez donc distinguer « non envoyé » de « envoyé dans les spams ».
Vous utilisez l’émulateur. L’émulateur Auth n’envoie pas d’e-mail : il affiche chaque lien de vérification, de réinitialisation et de connexion dans le terminal où il tourne et dans l’onglet Logs de l’Emulator Suite, et les expose sur un endpoint REST pour les tests. Testez sur un vrai projet de préproduction avant le lancement.
L’inscription échoue
auth/email-already-in-use: l’adresse a déjà un compte. La protection contre l’énumération ne masque pas ce cas. Utilisez une nouvelle adresse à chaque exécution.- Trop d’inscriptions : Firebase autorise 100 nouveaux comptes par heure depuis une même adresse IP. Une suite de tests exécutée depuis une seule machine CI peut dépasser ce seuil. Vous pouvez planifier une augmentation temporaire dans la console Firebase.
- Règles de mot de passe : si une politique de mot de passe est activée, un mot de passe faible échoue avec
auth/password-does-not-meet-requirements. Vérifiez que votre formulaire en indique la raison. - Protection contre les bots : la protection reCAPTCHA ou l’application d’App Check sur Authentication peut refuser les navigateurs automatisés. Pour App Check, fournissez un jeton de débogage à vos exécutions de test.
La connexion échoue avec auth/invalid-credential
Avec la protection contre l’énumération, un mauvais mot de passe et une adresse inconnue donnent la même erreur (INVALID_LOGIN_CREDENTIALS, que le SDK web signale comme auth/invalid-credential). Les tests qui attendent auth/user-not-found ou auth/wrong-password se mettent à échouer, tout comme les apps qui affichent un message différent pour chaque cas. Vérifiez plutôt l’erreur unique.
Le lien a été cliqué, mais l’app affiche toujours « vérifiez votre e-mail »
L’objet User que détient votre app garde la valeur emailVerified qu’il avait à la connexion de la personne. Après qu’elle a cliqué sur le lien dans un autre onglet, appelez user.reload(), et user.getIdToken(true) si vos règles de sécurité ou votre backend lisent la revendication email_verified. D’ici là, l’app et vos règles voient encore un utilisateur non vérifié.
Le lien échoue
auth/invalid-action-codeouauth/expired-action-code: le lien a déjà été utilisé ou a expiré. Demandez un nouvel e-mail et utilisez le plus récent.auth/unauthorized-continue-uri: l’URL de redirection transmise par votre code n’est pas sur un domaine autorisé. Ajoutez chaque environnement dans Authentication, Settings, Authorized domains. Les déploiements de prévisualisation reçoivent de nouveaux domaines, il faut donc ajouter chacun d’eux, ou utiliser un domaine de préproduction fixe.- Il mène à localhost : l’URL de redirection vient de votre code. Construisez-la à partir d’un paramètre d’environnement plutôt que d’un
http://localhostcodé en dur. Plus de détails dans pourquoi les e-mails renvoient vers localhost.
La connexion par lien e-mail redemande l’e-mail
La connexion par lien e-mail se termine dans le navigateur qui a demandé le lien : votre app y stocke l’adresse (généralement dans localStorage) et la relit à l’ouverture du lien. Si le lien est ouvert sur un autre appareil ou navigateur, Firebase recommande lui-même de redemander l’adresse, pour éviter la fixation de session. C’est le comportement attendu. Les testeurs doivent ouvrir le lien là où ils ont commencé. Dans une app mobile, le lien doit aussi ouvrir l’app, ce qui fonctionne différemment depuis l’arrêt de Dynamic Links : voir Connexion par lien e-mail Firebase pour les apps mobiles.
Tout vérifier en une seule passe
- Créez une nouvelle adresse Proxy Mail QA pour chaque scénario : nouvel utilisateur, réinitialisation du mot de passe (sur une adresse inscrite), connexion par lien e-mail.
- Suivez le parcours dans votre app. Le lien apparaît sur la ligne de l’adresse en quelques secondes, ou jamais, ce qui vous indique que rien n’a été envoyé.
- Regardez la ligne : un lien vers localhost est signalé, et la boîte de réception affiche l’expéditeur et les vérifications de chaque e-mail.
checkEmailavecexpectHostfait échouer un test dont le lien mène ailleurs que sur votre site. - Ouvrez le lien dans le même navigateur, puis vérifiez que votre app affiche l’utilisateur comme vérifié sans déconnexion ni reconnexion.
Créé avec Antigravity ou un autre outil d’IA ? Problèmes d’inscription et de connexion dans les apps vibe-codées décrit ce que les apps générées font souvent mal en plus de ces points.