En 2026, après la restriction des modèles d’e-mail des projets gratuits Supabase, comment tester les e-mails d’inscription ?

Le 3 juin 2026, Supabase a annoncé que les nouveaux projets gratuits utilisant son service d’e-mail par défaut ne peuvent plus modifier les modèles d’e-mail d’authentification (annonce officielle). La conséquence pratique est simple : pour tester une inscription, commencez par vérifier le modèle actuellement disponible, puis testez séparément le déclenchement, la réception et l’état du compte. Si l’acceptation exige une présentation personnalisée, vérifiez d’abord les règles applicables au projet avant d’évaluer SMTP personnalisé ou une formule appropriée. Une adresse de test ne peut recevoir le message que si la configuration du projet l’autorise.

Pour les développeurs indépendants qui viennent de créer un projet Supabase gratuit et doivent valider leur parcours d’inscription.
Pour les ingénieurs QA qui doivent distinguer l’envoi d’un e-mail de sa réception et de la confirmation du compte.
Pour les responsables techniques qui évaluent si la restriction du modèle nécessite une autre configuration d’envoi.

Dernière vérification : 25 octobre 2026. Les règles mentionnées ici sont vérifiées à partir de l’annonce et de la documentation officielles de Supabase ; vérifiez à nouveau leur portée dans le projet concerné avant de modifier sa configuration.

Avant le test, identifiez le projet et son mode d’envoi

Commencez par relever l’environnement testé, la date de création du projet, son offre et le service d’envoi actuellement sélectionné. Ces éléments déterminent si la limitation des modèles concerne le cas observé. L’annonce de Supabase distingue les nouveaux projets gratuits utilisant le service d’e-mail par défaut des projets gratuits créés auparavant, des projets payants, des configurations avec SMTP personnalisé et des projets autohébergés. Elle ne permet donc pas de déduire le comportement d’un projet à partir du seul fait qu’il utilise Supabase Auth.

Distinguez aussi un projet hébergé d’un environnement local. Une configuration ou un modèle testé en développement local peut vérifier le rendu et le parcours de l’application, mais ne prouve pas qu’un projet hébergé enverra le message de la même façon. Supabase décrit séparément la personnalisation des modèles en développement local. Cette séparation est importante : une expérience réussie dans un environnement ne démontre ni l’autorisation d’envoi ni la réception dans un autre.

Avant de déclencher une inscription, consignez :

• l’environnement visé et le projet concerné ;
• l’offre et la date de création du projet, si elles sont connues ;
• le service d’envoi configuré dans Supabase Auth ;
• l’adresse de test utilisée et la raison de son choix ;
• le résultat attendu : lien de confirmation, code, page de retour ou état utilisateur.

Cette fiche évite une erreur courante en QA : attribuer un refus d’envoi à la restriction du modèle alors que le destinataire n’est pas autorisé par la configuration en place. Les règles de portée et de limitation d’envoi sont documentées dans les limites actuelles d’Auth ; en cas de doute, consultez la documentation correspondant au projet au lieu de vous fier à une ancienne note de test.

Un nouveau projet gratuit peut-il encore modifier son modèle de confirmation ? Pour un nouveau projet gratuit qui utilise le service d’e-mail par défaut, l’annonce indique que la modification des modèles d’authentification n’est pas disponible dans le périmètre décrit. Les projets créés auparavant et les autres modes de déploiement ne doivent pas être assimilés à ce cas. La décision doit partir de la configuration réelle du projet, pas d’une règle générale appliquée à toutes les installations.

Au moment de cadrer l’acceptation, séparez fonction et marque

Un test fonctionnel répond à une question : l’utilisateur peut-il recevoir la confirmation et achever l’inscription prévue par l’application ? Il peut réussir même si le message utilise un modèle standard. Un test de marque répond à une autre question : le contenu, l’identité visuelle, les variables et le parcours de retour correspondent-ils aux exigences du produit ? Il peut échouer alors que le lien de confirmation fonctionne parfaitement.

La documentation des modèles d’e-mail Auth décrit les modèles et les variables disponibles. Utilisez-la pour vérifier que le lien ou le code est inséré selon le mécanisme prévu, ainsi que les informations de redirection employées par le projet. Ne déduisez pas du seul rendu d’un modèle que tous les clients de messagerie afficheront le message de façon identique.

Pour une équipe produit, le risque est de marquer la tâche « e-mail validé » après avoir seulement vérifié que le serveur a accepté une demande. Une meilleure définition d’achèvement consigne séparément le résultat de l’appel, l’existence du message dans la boîte de test et le passage du compte à l’état confirmé.

Lors du déclenchement, associez la demande au compte de test

Utilisez un environnement isolé destiné aux essais de votre propre produit ou un environnement pour lequel vous êtes autorisé. N’utilisez pas le parcours pour créer en série des comptes sur des services tiers. L’objectif est de relier un événement d’inscription précis à une adresse maîtrisée, sans introduire d’informations personnelles réelles dans des données de démonstration.

Procédez ainsi :

• Créez ou choisissez un compte de test identifiable dans le projet concerné.
• Saisissez une adresse que vous pouvez réellement consulter et que la configuration actuelle autorise à recevoir.
• Notez l’heure de la demande, l’environnement, l’identifiant de test et la réponse de l’application.
• Vérifiez les journaux applicatifs et l’état de la requête sans interpréter une réponse positive comme une preuve de livraison.
• Si l’envoi est refusé, vérifiez d’abord la portée du service par défaut, la configuration d’Auth et les limites d’envoi indiquées par Supabase.

Les adresses de test ne sont pas interchangeables. Un alias de boîte personnelle, une adresse temporaire ou une boîte dédiée à la QA peuvent tous convenir à certains tests, mais leur acceptation dépend du service et des règles de réception du projet. Pour comparer les risques liés aux données de test, le guide sur la protection de la vie privée avec les adresses e-mail peut aider à éviter d’exposer une boîte professionnelle ou des données d’une personne réelle.

Pourquoi le SMTP par défaut ne peut-il pas envoyer à n’importe quelle adresse de test ? Le service d’envoi par défaut est soumis aux restrictions décrites par Supabase, notamment en matière de destinataires et de limites d’envoi. Il ne faut donc pas assimiler « inscription acceptée par l’application » à « envoi autorisé vers toute adresse ». Consultez les règles de configuration SMTP pour Auth et les limites actuelles avant d’élargir le test ; si le destinataire est hors du périmètre autorisé, le résultat n’évalue pas le modèle.

À la réception, contrôlez le message et le lien

Une fois la demande déclenchée, ouvrez la boîte de test et vérifiez que le message existe réellement. Si aucun e-mail n’apparaît, le test de réception n’est pas réussi, même si l’application a affiché un message de succès. Gardez les résultats distincts : demande effectuée, envoi accepté ou refusé, message accessible, action de confirmation exécutée.

Dans le message reçu, contrôlez les points suivants :

• le destinataire correspond bien au compte créé ;
• le sujet et le contenu sont cohérents avec le type d’événement déclenché ;
• le lien ou le code correspond à cette inscription et non à un essai précédent ;
• l’URL de retour correspond à l’environnement attendu ;
• les éléments indispensables restent compréhensibles dans la boîte de test.

Pour un test du parcours, n’évaluez pas seulement le texte visible. Suivez le lien ou saisissez le code selon le flux prévu par l’application. Les variables de modèle et les liens doivent être interprétés selon la documentation Supabase, et non à partir d’une supposition sur le comportement d’un client de messagerie. Les redirections peuvent dépendre de la configuration de l’application et du projet.

Un cas fréquent illustre cette distinction : une équipe teste d’abord l’interface d’inscription dans un environnement local, puis utilise un nouveau projet hébergé pour la recette. Le premier test confirme que l’application sait afficher les états prévus ; le second doit encore prouver que le projet hébergé envoie vers une adresse autorisée et que l’utilisateur peut terminer la confirmation. Réutiliser un seul résultat pour les deux environnements masque précisément les défaillances que la recette est censée détecter.

Après l’ouverture du message, validez l’état du compte

Suivez le lien reçu ou saisissez le code attendu, puis revenez dans l’application. Vérifiez que l’utilisateur est maintenant dans l’état prévu : confirmation effectuée, accès autorisé ou page de retour cohérente. Contrôlez également que l’application ne traite pas une simple ouverture du message comme une confirmation achevée si son flux exige une action supplémentaire.

Enregistrez chaque preuve séparément dans le rapport QA. Une trace utile peut contenir l’identifiant du test, l’environnement, l’adresse utilisée sous une forme protégée, la réponse de l’application, la présence du message et le résultat de la transition de compte. Évitez de conserver le contenu complet du message ou un lien de confirmation actif dans un ticket accessible à toute l’équipe : ce lien peut permettre d’agir sur le compte de test.

Cette précaution relève aussi de l’hygiène des données. Un e-mail de test peut contenir un jeton, une adresse personnelle ou une URL de retour interne. Pour les créations de comptes de démonstration, privilégiez des données synthétiques et un accès restreint aux boîtes de réception. Un guide sur la durée de vie des boîtes de réception peut aussi aider à déterminer si une boîte temporaire est adaptée à un test ponctuel ou si une adresse durable est nécessaire pour les reprises et les audits.

Pour choisir la suite, appliquez les conditions au besoin réel

Une fois le parcours fonctionnel testé, décidez séparément si le modèle standard suffit. La documentation ne permet pas de déduire qu’un changement de SMTP garantit une livraison ; il modifie la configuration d’envoi, mais la réception doit toujours être vérifiée dans l’environnement réel. Supabase décrit les paramètres pertinents dans sa documentation SMTP personnalisée.

Choisissez selon ces conditions :

• Si l’objectif est de valider le parcours d’inscription et que le modèle actuel contient l’action de confirmation requise, conservez la configuration pour ce test et documentez que l’identité visuelle n’a pas été évaluée.
• Si l’acceptation exige un texte ou un modèle de marque, vérifiez d’abord l’éligibilité du projet et les règles d’offre applicables ; évaluez ensuite SMTP personnalisé ou une formule appropriée.
• Si le message est refusé avant d’atteindre la boîte, vérifiez destinataire, configuration et limites avant de conclure à un blocage du modèle.
• Si le message arrive mais que le lien échoue, examinez le lien, les variables et le retour configuré dans le projet ; ne changez pas le modèle sans avoir localisé le point de rupture.
• Si le test se déroule en local, utilisez-le pour vérifier le contenu et le flux de développement, puis répétez les contrôles d’envoi et de réception dans le projet hébergé avant la recette.
• Si l’adresse doit recevoir des messages sur une longue période ou permettre des échanges, choisissez une boîte dédiée ou un alias durable plutôt qu’une adresse temporaire.

Cette approche évite deux dépenses inutiles : modifier la configuration SMTP alors qu’un test fonctionnel peut être réalisé avec le modèle disponible, ou consacrer du temps à la présentation du message avant d’avoir prouvé que l’inscription se termine correctement. Elle aide aussi à transmettre des critères clairs entre développement, QA et produit : « envoi déclenché », « message reçu », « confirmation achevée » et « marque validée » sont des résultats distincts.

Pour un essai ponctuel, un code de confirmation ou une recette de démonstration, une adresse de réception temporaire peut éviter d’exposer la boîte principale et de la remplir de messages de test. Il faut toutefois vérifier que le projet autorise son destinataire, puis conserver une adresse durable pour tout compte important qui nécessiterait une récupération ou des échanges ultérieurs. OrbSend peut être envisagé comme une option de réception temporaire pour ce type de vérification ; le choix de l’adresse ne contourne pas les restrictions d’envoi de Supabase. Pour examiner cette option, consultez OrbSend en français.