2026 : e-mails de test Supabase Auth non reçus ? Que vérifier en développement, en QA et avant la mise en production

L’e-mail de confirmation n’apparaît pas dans la boîte de réception et le test semble bloqué.

Action immédiate : identifiez d’abord l’environnement. En local, les e-mails de test sont capturés au lieu d’être envoyés à une boîte externe ; dans un projet hébergé, vérifiez la configuration d’envoi, les limites applicables aux destinataires et les journaux Auth. Pour prouver une réception réelle, testez votre propre produit dans un environnement de préproduction avec une adresse de test adaptée. Une capture locale ne prouve pas la remise à l’extérieur.

Cet article s’adresse aux développeurs qui mettent en place une confirmation d’inscription ou une connexion par e-mail avec Supabase Auth.
Il aide les équipes QA à distinguer la vérification d’un modèle, d’un parcours et d’une réception réelle, puis à consigner les éléments reproductibles.
Il est aussi destiné aux responsables de préproduction qui doivent décider ce qui constitue une validation suffisante avant le déploiement.

Développement local ou projet hébergé : deux parcours à ne pas confondre

Le premier contrôle consiste à savoir où la requête Auth s’exécute. Un e-mail qui n’apparaît pas dans une boîte personnelle n’indique pas forcément un défaut : en développement local, Supabase capture les e-mails de test au lieu de les expédier vers Internet. Il faut donc consulter l’interface locale de capture. Ce résultat confirme que le message a été généré et capturé dans cet environnement ; il ne démontre ni une remise externe ni la qualité de réception chez un fournisseur de messagerie.

Où consulter une confirmation émise pendant un test local ? Ouvrez l’interface de capture lancée avec votre environnement local, puis recherchez le message au moment où vous déclenchez l’inscription ou l’action Auth concernée. Si le message y figure, inspectez son destinataire, son contenu et ses liens. Si rien n’y apparaît, remontez d’abord à l’action déclenchante, à la réponse de l’application et à l’environnement réellement utilisé. La documentation officielle des tests locaux et des e-mails capturés permet de distinguer cette capture d’un envoi vers une boîte externe.

Ce contrôle évite trois confusions fréquentes. Premièrement, la requête peut ne pas avoir déclenché l’événement attendu. Deuxièmement, l’application peut viser un projet différent de celui affiché dans l’outil de développement. Enfin, un message visible dans la capture locale peut avoir un lien incorrect ou un modèle incomplet. « Le message existe » et « le parcours fonctionne » sont deux résultats distincts.

Pour le développement local, vérifiez également les valeurs et les services définis dans la configuration de l’environnement. Une configuration de projet locale n’est pas interchangeable avec celle du projet hébergé : une variable absente, une mauvaise référence de projet ou une configuration restée périmée peut envoyer le test vers le mauvais endroit. La documentation de configuration du développement local décrit les paramètres à contrôler. L’objectif n’est pas de supposer que tout échec vient du courrier, mais de prouver quelle configuration et quel parcours ont été utilisés.

QA : modèle, parcours Auth ou réception externe ?

La QA doit commencer par définir ce que le test cherche à prouver. Un seul scénario ne valide pas nécessairement le rendu du message, le fonctionnement du lien et sa remise dans une boîte externe. Ces objectifs nécessitent des contrôles différents, même s’ils partent tous d’une inscription.

Pour vérifier le contenu, utilisez la capture locale : contrôlez le sujet, le texte, les variables injectées et l’adresse de destination. La documentation Supabase consacrée aux modèles d’e-mail en environnement local précise comment examiner les modèles dans ce contexte. Cette approche est adaptée à une revue rapide après modification du texte ou d’une variable, mais ne renseigne pas sur la remise réelle par un service d’envoi.

Pour vérifier le parcours, ouvrez le lien ou utilisez le code prévu par votre application, puis confirmez que l’état Auth évolue comme attendu. Le test doit contrôler ce que fait l’application après l’ouverture : confirmation réussie, erreur compréhensible ou retour vers l’écran prévu. Un message bien formé ne prouve pas à lui seul que le lien est valide, que la session est correctement traitée ou que l’utilisateur arrive sur la bonne page.

Enfin, pour vérifier la réception externe, réalisez le test dans un environnement hébergé dont l’envoi est autorisé et correctement configuré. Choisissez un destinataire que l’équipe peut consulter, déclenchez un parcours représentatif, puis notez le résultat observé dans la boîte et dans les journaux du projet. Une adresse de test distincte de la messagerie de travail aide à éviter de mélanger les messages d’essai et les échanges professionnels. Notre guide sur le choix d’une adresse pour les tests peut aider à comparer les options selon la durée d’usage et le besoin d’accès ultérieur.

Comment consigner une vérification QA pour qu’elle soit reproductible ? Notez l’environnement, le projet concerné, l’action déclenchée, l’adresse destinataire utilisée, l’heure du test selon les pratiques de votre équipe, le résultat visible et toute erreur pertinente. Conservez une capture de l’interface locale ou un extrait de journal utile, en retirant les jetons, liens sensibles et données personnelles avant de le partager. Si une personne différente ne peut pas retrouver le même parcours à partir de ces éléments, le rapport décrit un symptôme, mais pas encore un test reproductible.

Un cas courant : le modèle a été modifié pour une démonstration produit, puis la QA constate que le bouton ramène vers une page inattendue. La capture locale permet de voir le lien réellement produit ; un test du parcours dans l’application permet ensuite de savoir si la destination est acceptée et traitée. Répéter l’inscription sans examiner le message ne localise pas le défaut.

Maintenance du projet : rejet d’envoi ou problème de remise ?

Dans un projet hébergé, vérifiez si un serveur SMTP personnalisé est configuré et si le destinataire du test est autorisé par la configuration d’envoi en place. Les restrictions du service d’envoi par défaut peuvent empêcher certains tests vers des adresses arbitraires. Elles évoluent : ne vous fiez pas à une ancienne note d’équipe ou à une valeur recopiée d’un autre projet. Consultez la documentation actuelle sur SMTP pour Auth et comparez ses indications avec les paramètres effectifs du projet.

Que faire si Supabase Auth indique que l’adresse destinataire n’est pas autorisée ? Traitez ce résultat comme une restriction ou une configuration à vérifier, et non comme une preuve que le message est arrivé dans la boîte. Confirmez que le test utilise le projet attendu, que l’adresse est permise pour le mode d’envoi configuré et que le serveur SMTP personnalisé, s’il existe, est celui destiné à cet environnement. Ensuite, relevez l’erreur Auth exacte et vérifiez les consignes officielles applicables au projet. Évitez de modifier une règle d’envoi en production uniquement pour faire passer un essai de développement.

Les journaux aident à séparer l’échec de traitement ou de remise au service d’envoi d’un problème qui survient après la prise en charge du message. Commencez par l’erreur Auth, son contexte et l’opération qui l’a déclenchée. La documentation des codes d’erreur Auth aide à interpréter les erreurs sans les réduire à un simple « e-mail non reçu ». Les recommandations Supabase pour les e-mails Auth absents orientent aussi vers les journaux et les contrôles adaptés.

Comment savoir si l’e-mail a été remis au service d’envoi ? Consultez les journaux Auth et l’état associé à la requête, puis vérifiez si l’erreur indique un rejet avant la prise en charge ou si le traitement a progressé au-delà de cette étape. Un journal qui montre un refus ou une erreur de configuration pointe vers le projet ou son mode d’envoi. Si le service a accepté le message, cela ne prouve toujours pas qu’il est visible dans la boîte de réception : il peut encore être filtré, différé ou refusé plus loin dans la chaîne. Ne déduisez pas la remise finale de la seule absence d’une erreur Auth.

Le point important pour la maintenance est de conserver une frontière claire entre ces étapes : événement Auth déclenché, configuration d’envoi utilisée, acceptation ou rejet observable, puis résultat chez le destinataire. Si un incident est transmis à une autre personne, incluez l’erreur exacte et l’environnement ; une capture d’écran de la boîte vide ne suffit pas à identifier le composant responsable.

Modèles et redirections : contenu généré ne signifie pas parcours validé

Un lien de confirmation contient une destination et des paramètres qui doivent correspondre au parcours prévu par l’application. Vérifiez les variables utilisées par le modèle, le lien produit et le résultat après ouverture. Un message peut être généré correctement tout en pointant vers une adresse qui n’est pas autorisée, ou vers une page que l’application ne sait pas traiter.

La documentation Supabase explique les modèles d’e-mail Auth et leurs variables. Comparez le modèle avec les valeurs observées dans le message capturé ou reçu, plutôt qu’avec le texte attendu dans le code. Pour les redirections, vérifiez à la fois les URL autorisées dans le projet et le traitement effectué par l’application ; les deux contrôles sont nécessaires. La documentation sur les URL de redirection Auth décrit les règles de configuration à appliquer.

Pourquoi le lien reçu peut-il échouer alors que le message est bien arrivé ? Parce que la réception et la navigation sont deux étapes différentes. Le lien peut avoir une destination inattendue, ne pas correspondre aux URL permises, ou aboutir à une page qui ne finalise pas le parcours. Reproduisez le clic dans le même environnement que le test, observez l’URL de destination et vérifiez la réaction de l’application. Ne concluez pas à un défaut de livraison lorsque le message est présent et que l’échec apparaît seulement après son ouverture.

Cette distinction est utile aussi lors de la revue d’un modèle de connexion par e-mail. Une variable incorrecte peut créer un lien incomplet ; une redirection mal configurée peut, elle, faire échouer le retour vers l’application malgré un message correct. Pour approfondir la validation du parcours, notre article sur les boîtes de réception de navigateur pour les tests traite des usages où l’inspection du message et l’ouverture de ses liens font partie de la vérification.

Mise en production : ce que la capture locale ne peut pas certifier

Avant un déploiement, le responsable doit définir le niveau de preuve correspondant au risque du parcours. Si l’objectif est de vérifier le texte du modèle, une capture locale peut suffire. Si l’objectif est de démontrer qu’un utilisateur reçoit une confirmation dans une boîte externe et termine son inscription, il faut tester le parcours dans un environnement hébergé représentatif, avec une configuration d’envoi prévue pour cet usage.

Ne généralisez pas le résultat d’un essai isolé à l’ensemble des destinataires. Une réception observée établit que le parcours testé a fonctionné pour cet environnement, cette configuration et cette adresse. Elle ne garantit ni une livraison universelle ni un comportement identique pour tous les domaines de messagerie. Consignez l’adresse de test, le projet, le modèle, le résultat et les erreurs éventuelles. Utilisez des données de test plutôt que les informations personnelles d’un utilisateur réel ; pour choisir une boîte dédiée aux essais, notre guide sur la protection de la vie privée lors des tests par e-mail présente les compromis à examiner.

Liste de contrôle avant de déclarer le test réussi

• [ ] Confirmer si le parcours s’exécute en local ou dans un projet hébergé.
• [ ] En local, ouvrir l’interface de capture et chercher le message généré.
• [ ] Vérifier que l’action Auth a bien été déclenchée et que l’application vise le projet attendu.
• [ ] Examiner le destinataire, le sujet, les variables et le lien dans le modèle rendu.
• [ ] Dans un projet hébergé, contrôler le mode SMTP et les autorisations applicables au destinataire.
• [ ] Lire l’erreur ou l’état correspondant dans les journaux Auth avant de relancer le scénario.
• [ ] Si la réception externe fait partie des critères, effectuer un essai dans l’environnement de préproduction prévu à cet effet.
• [ ] Ouvrir le lien et vérifier la destination ainsi que le traitement côté application.
• [ ] Consigner les preuves utiles en masquant les jetons et les données personnelles.

Pour trier rapidement les incidents, associez le symptôme à son premier interlocuteur. Si aucun message n’apparaît dans la capture locale, le développement vérifie l’action déclenchée, la configuration locale et le modèle. Si le projet refuse le destinataire, la maintenance examine la configuration SMTP et les restrictions actuelles. Si le service a pris en charge le message mais que la boîte reste vide, l’équipe vérifie le résultat côté destinataire sans confondre ce constat avec un succès de remise. Si le lien s’ouvre sur une mauvaise page, le développeur responsable du modèle et des redirections examine la destination et le traitement applicatif.

Cette répartition évite de relancer mécaniquement le même scénario. Avant chaque nouvelle tentative, conservez l’environnement, l’action, l’adresse de test et l’erreur observée. Une comparaison entre deux essais n’est utile que si l’équipe sait ce qui a changé. La capture locale, les journaux Auth et la boîte externe sont des sources de preuve différentes ; les réunir dans un rapport permet de localiser l’étape fautive sans transformer un problème de redirection en incident de réception.

Pour un test externe ponctuel de votre propre produit, une adresse temporaire peut servir de destinataire isolé, à condition que la configuration du projet autorise cet envoi et que le parcours ne nécessite pas de conserver la boîte à long terme. SendTmp permet d’ouvrir une boîte temporaire sans inscription, immédiatement, sans exposer la messagerie principale aux messages d’essai. C’est une option pour une confirmation ou un contrôle de préproduction, pas pour un compte important qui exige récupération durable, échanges ultérieurs ou accès pérenne.