Les détails ci-dessous proviennent de la documentation de Supabase au 23 octobre 2026. Consultez-la pour les limites et réglages actuels. Pour les bases, l’envoi de vos premiers e-mails de test et la configuration d’un expéditeur, commencez par Tester les e-mails Supabase Auth.
L’e-mail n’arrive jamais
L’expéditeur intégré n’enverra pas d’e-mails à vos testeurs. Le service d’e-mail propre à Supabase ne livre qu’aux membres de l’équipe de votre projet, 2 e-mails par heure au maximum. Il fonctionne pour vous parce que vous faites partie de l’équipe, puis refuse tous les autres avec « Email address not authorized ». Configurez un SMTP personnalisé dans Authentication, Emails.
Votre fournisseur SMTP est encore en sandbox. Un nouveau compte Resend n’envoie qu’à votre propre adresse tant que vous n’avez pas vérifié un domaine, et Amazon SES seulement aux adresses que vous avez vérifiées. Supabase transmet l’e-mail, et le fournisseur l’abandonne discrètement.
Vous avez redemandé trop tôt. Par défaut, chaque utilisateur peut recevoir un e-mail de confirmation, de lien magique, de code ou de réinitialisation toutes les 60 secondes, et chaque adresse IP peut faire 30 demandes d’inscription et de connexion toutes les 5 minutes. Un test qui réessaie vite, ou une suite lancée depuis une seule machine CI, atteint ces limites et reçoit une erreur 429. Augmentez-les pour votre projet de préproduction dans Authentication, Rate Limits.
L’adresse a déjà un compte. Pour ne pas révéler qui s’est inscrit, Supabase répond à une inscription pour une adresse confirmée comme si elle avait réussi, avec un utilisateur sans identités, et n’envoie aucun e-mail. Un test qui réutilise une adresse attend un e-mail qui ne vient jamais. Utilisez une nouvelle adresse à chaque exécution.
Confirm email est désactivé. L’inscription connecte alors l’utilisateur immédiatement et n’envoie rien. Vérifiez Authentication, Sign In / Providers, Email. Ce réglage est souvent désactivé pendant le développement et jamais réactivé.
Le lien indique qu’il est invalide ou a expiré
Vous cliquez sur le lien et arrivez sur votre app avec error_code=otp_expired (« Email link is invalid or has expired ») dans la barre d’adresse.
- Il a déjà été utilisé. Les liens ne fonctionnent qu’une fois et durent une heure par défaut. Demander un autre e-mail remplace le lien précédent, utilisez donc le plus récent.
- Un scanner l’a ouvert en premier. Certains services de messagerie, et des outils de sécurité d’entreprise comme les scanners de liens, ouvrent chaque lien d’un nouvel e-mail pour le vérifier. Cela consomme un lien à usage unique avant que la personne clique dessus. Supabase conseille d’envoyer plutôt un code à 6 chiffres (
{{ .Token }}dans le modèle) ou de pointer vers votre propre page où la personne appuie sur un bouton pour confirmer. Proxy Mail QA n’ouvre jamais les liens : si un lien fonctionne dans votre test mais échoue pour de vrais utilisateurs, un scanner en est probablement la cause.
Le lien s’ouvre, mais personne n’est connecté
Il a été ouvert dans un autre navigateur. Avec le flux PKCE, qu’utilisent les helpers côté serveur de Supabase, le navigateur qui a commencé l’inscription conserve un secret dont le lien a besoin. Ouvrez le lien dans un autre navigateur, une fenêtre privée ou un autre appareil, et l’échange échoue, souvent avec « both auth code and code verifier should be non-empty ». Les testeurs doivent ouvrir le lien dans le navigateur de leur inscription. Pour des liens qui fonctionnent partout, construisez-les à partir de {{ .TokenHash }} et vérifiez-les sur votre serveur avec verifyOtp.
Rien ne termine la connexion. Le lien arrive sur votre app avec un code (ou un jeton) dans l’adresse, et une page doit l’échanger contre une session. Si cette route manque, la personne voit votre page d’accueil, déconnectée. Vérifiez que la page de destination du lien appelle exchangeCodeForSession, ou verifyOtp avec le hash du jeton.
Le serveur ne voit pas la session. Le lien par défaut place la session après un # dans l’adresse, que seul le navigateur peut lire. Les apps rendues côté serveur ont besoin du lien avec hash de jeton décrit ci-dessus.
Les liens mènent à localhost ou au mauvais environnement
La Site URL vaut d’abord http://localhost:3000, et toute redirectTo absente de la liste Redirect URLs revient à celle-ci. Définissez la Site URL sur l’app déployée et listez chaque environnement. Plus de détails dans pourquoi les e-mails pointent vers localhost ; Proxy Mail QA signale ces liens sur la ligne de l’adresse.
L’inscription échoue avec « Database error saving new user »
Quelque chose dans la base de données a refusé le nouvel utilisateur, presque toujours un trigger sur auth.users, par exemple un trigger qui crée une ligne dans profiles. Causes fréquentes : la table ou une colonne dans laquelle il écrit n’existe pas, la fonction n’est pas security definer et ne peut donc pas écrire dans public, ou une colonne qu’elle remplit est not null et l’inscription ne l’a pas envoyée. Les logs Auth et Postgres de Supabase montrent la vraie erreur.
Testez aussi avec des valeurs inhabituelles : un nom avec une apostrophe, une autre écriture ou 255 caractères peuvent casser une colonne de profil que les données de test ordinaires n’atteignent jamais. Noms et mots de passe inhabituels propose une liste à essayer.
L’e-mail de réinitialisation arrive, mais le mot de passe ne change pas
Un lien de réinitialisation connecte la personne avec une session de récupération et déclenche l’événement PASSWORD_RECOVERY. Votre app doit le détecter, afficher un formulaire pour le nouveau mot de passe et appeler updateUser avec celui-ci. Sinon, la personne se retrouve simplement connectée, avec son ancien mot de passe. Avec PKCE, le lien doit aussi être ouvert dans le navigateur qui l’a demandé. Plus de détails dans Tester les e-mails de réinitialisation de mot de passe.
Le captcha bloque vos tests automatisés
Avec la protection captcha activée (Authentication, Attack Protection), chaque inscription et connexion nécessite un jeton captcha, et un navigateur automatisé ne peut donc pas passer. Sur votre projet de préproduction, utilisez les clés de test de votre fournisseur de captcha, qui passent toujours, et gardez les vraies clés pour la production.
Cela fonctionne en local avec Supabase mais pas sur le projet hébergé
La CLI Supabase capture les e-mails locaux dans son propre visualiseur (généralement sur localhost:54324) et lit les modèles depuis supabase/config.toml. Le projet hébergé utilise les modèles, l’expéditeur et les limites de débit du tableau de bord. Testez sur un projet de préproduction hébergé avant le lancement, avec de vrais e-mails vers une adresse qui les reçoit.
Tout vérifier en une seule passe
- Créez une nouvelle adresse Proxy Mail QA pour chaque scénario : nouvel utilisateur, utilisateur existant, réinitialisation de mot de passe, lien magique.
- Suivez le parcours dans votre app. Le code ou le lien apparaît sur la ligne de l’adresse en quelques secondes.
- Regardez la ligne : un lien vers localhost est signalé, et la boîte de réception indique si l’e-mail précise quand son lien expire.
- Ouvrez le lien dans le navigateur de votre inscription, et vérifiez que vous êtes connecté sur le bon site.
Créé avec Lovable, Bolt ou v0 ? Problèmes d’inscription et de connexion dans les apps vibe-codées couvre ce que ces apps ratent généralement en plus.