Les e-mails d'authentification Supabase doivent refléter l'identité visuelle de votre produit sans perturber le parcours de connexion. Le workflow le plus sûr consiste à concevoir d'abord le design dans Migma : préparez un e-mail sobre et charté, validez son rendu HTML et son affichage en boîte de réception, puis confiez son intégration et ses tests dans Supabase à l'équipe de développement.
La principale difficulté réside dans le respect du contrat d'authentification. Un bouton élégant ne sert à rien si une variable de template est convertie en texte brut, si un paramètre de tracking altère l'URL ou si l'utilisateur atterrit sur le mauvais environnement. Ce guide fournit aux designers et aux développeurs une checklist commune pour sécuriser ce handoff.
Ce workflow est proposé par Migma. Il met l'accent sur la validation créative, la lisibilité de la mise en page et une séparation claire entre design d'e-mail et logique d'authentification. Il n'implique aucun connecteur natif Migma–Supabase et ne remplace pas la configuration de sécurité de Supabase. Les fonctionnalités produit ont été vérifiées d'après la documentation officielle le 14 octobre 2026.
Définir l'e-mail à concevoir
Commencez par une seule action : confirmation d'inscription, acceptation d'invitation, connexion, modification d'adresse e-mail, réinitialisation de mot de passe ou réauthentification. Supabase traite chacun de ces cas à travers des modèles d'e-mails d'authentification distincts. Les notifications de sécurité constituent une catégorie à part et s'activent au niveau du projet.
Résumez l'objectif du template choisi en une phrase simple. Pour une confirmation d'inscription, cela peut être : « Aider l'utilisateur à valider l'adresse saisie et à revenir dans l'application ». Cette formulation clarifie les revues. Une bannière promotionnelle, un carrousel de fonctionnalités ou une incitation à s'inscrire à une newsletter n'ont pas leur place ici.
Mettez-vous d'accord sur le nom de l'application, l'adresse de support, l'identité de l'expéditeur et le libellé exact du bouton avant de démarrer le design. Le texte doit décrire fidèlement l'action. Un e-mail de confirmation ne doit pas sous-entendre que le compte est déjà validé ; un message de réinitialisation ne doit pas affirmer que le mot de passe a déjà changé.
Créer un premier jet charté dans Migma
Vérifiez le logo extrait de votre site web, la palette de couleurs, les typographies et les informations validées dans les paramètres de marque de Migma. Demandez ensuite un e-mail d'authentification sur une seule colonne, doté d'un logo reconnaissable, d'une explication courte, d'un appel à l'action principal et d'un lien d'assistance.
Voici un exemple de brief efficace :
Conçois un e-mail de confirmation d'inscription pour notre application. Conserve le nom de produit et l'intitulé de bouton validés. Utilise une seule colonne, une typographie lisible et un en-tête sobre. Laisse les variables d'authentification intactes. N'ajoute aucune offre, aucun lien de tracking, aucun compte à rebours ni aucune allégation non fournie.
Vérifiez visuellement le résultat. Veillez à ce que le texte informatif reste sous forme de texte sélectionnable plutôt qu'intégré dans une image. Contrôlez l'action avec le chargement des images désactivé, et assurez-vous que le produit reste immédiatement identifiable sans image de fond.
Migma génère du code HTML adapté aux clients de messagerie et permet de prévisualiser l'affichage en boîte de réception. Cela simplifie la revue de design, mais ne garantit pas le bon fonctionnement du flux d'authentification. Valider la mise en page et tester la connexion restent deux étapes distinctes.
Préserver les variables lors du handoff
Reprenez scrupuleusement les noms officiels des variables Supabase. Le tableau ci-dessous sert de référence opérationnelle, mais ne dispense pas de vérifier la documentation du template concerné.
| Variable | Élément à préserver | Point de contrôle |
|---|---|---|
| `{{ .ConfirmationURL }}` | Le lien de confirmation dynamique | L'appel à l'action pointe-t-il toujours vers l'URL dynamique prévue ? |
| `{{ .Token }}` | Le code à usage unique | Reste-t-il lisible sous forme de texte et adapté à ce parcours ? |
| `{{ .SiteURL }}` | L'adresse configurée de l'application | Correspond-elle bien à l'environnement testé ? |
| `{{ .RedirectTo }}` | La destination de redirection demandée | S'agit-il d'une destination autorisée et attendue ? |
| `{{ .Data }}` | Les métadonnées utilisateur exploitées | L'absence éventuelle de données est-elle gérée correctement ? |
Le moteur de template de Supabase repose sur Go templates. Cette syntaxe lui est propre : elle n'est pas interchangeable avec les balises de fusion d'autres plateformes d'e-mailing. Ne la remplacez jamais par un merge tag générique lors d'une modification de maquette.
Conservez une version originale propre et comparez le HTML exporté avec celle-ci. Demandez au développeur d'inspecter l'orthographe des variables, les espaces, les accolades, l'emplacement des URL et les blocs conditionnels. Si un outil de design a modifié une variable, corrigez-la et retestez avant d'installer le template.
Utilisez des données fictives lors des revues. Évitez de coller de vrais jetons de connexion ou des informations client dans un brief créatif. Un rendu avec des données de test suffit pour évaluer l'impact d'une adresse très longue ou d'un nom manquant sur la mise en page, sans exposer de lien d'authentification actif.
Choisir la bonne méthode d'intégration
Le workflow d'export de Migma permet de télécharger directement le code HTML. Utilisez ce fichier validé comme base de handoff : le développeur se charge ensuite de l'adapter et de l'intégrer au template d'authentification Supabase.
Pour un projet hébergé sur Supabase, la documentation officielle oriente vers l'onglet des templates du dashboard. Pour le développement local ou les instances auto-hébergées, elle s'appuie sur des fichiers de configuration et des templates HTML locaux. Ces circuits d'installation sont distincts : une modification sur un environnement ne signifie pas qu'elle est répercutée sur un autre.
Si votre projet utilise un hook d'envoi personnalisé (custom sending hook), le développeur doit aussi vérifier les données d'entrée du hook, le template chez le prestataire et le comportement au runtime. Copier du HTML dans le dashboard Supabase ne met pas à jour un template géré par un tiers. Documentez clairement quel système produit réellement le message.
Avant tout déploiement, archivez la dernière version fonctionnelle aux côtés de la nouvelle. Précisez le type de message et l'environnement dans les noms de fichiers pour permettre à un collègue de restaurer la version adéquate sans ambiguïté.
Tester le message final et le parcours utilisateur
Lancez Migma Email Preflight pour contrôler la mise en page, les textes, les liens et les risques courants d'acheminement. Inspectez le rendu sur ordinateur, mobile, mode clair et mode sombre. Une URL d'authentification dynamique exige souvent un test distinct au runtime, car sa valeur définitive n'est générée qu'au moment de l'envoi.
Effectuez ensuite un test complet depuis l'environnement Supabase cible avec des comptes de test dédiés. Vérifiez une inscription vierge, la redirection attendue, le cas d'un nom optionnel manquant et l'affichage réel sur écran étroit. Pour un template de réinitialisation, validez l'ensemble du parcours de changement de mot de passe, pas seulement l'ouverture du message.
La documentation Supabase signale deux risques majeurs liés aux liens. Les robots d'analyse de sécurité peuvent précharger et consommer les URL de confirmation à usage unique. De plus, les fonctionnalités de tracking des routeurs d'e-mails réécrivent souvent les liens d'authentification. Supabase préconise l'utilisation d'un OTP ou d'une page de confirmation intermédiaire pour parer au préchargement, et recommande de désactiver le tracking des clics pour éviter l'altération des URL. Confiez le choix technique à l'équipe de développement : modifier le style d'un bouton ne réglera aucun de ces deux problèmes.
Consignez les éléments de preuve : version du template, environnement, messagerie testée, action vérifiée, résultat obtenu et nom du relecteur. Le fait qu'un prestataire accepte le message ne prouve ni qu'il est parvenu en boîte de réception, ni que l'utilisateur a pu finaliser son inscription.
Faciliter les prochaines mises à jour
Les évolutions graphiques ultérieures doivent rester simples. Ajustez le logo, les espacements ou le texte validé sans altérer par mégarde la logique d'authentification. Après chaque export, répétez la comparaison des variables et le test sur l'environnement cible.
Commencez par un premier template dans Migma, validez la création et transmettez le HTML en suivant cette checklist. Une fois ce message validé en production, appliquez sa charte graphique aux autres e-mails d'authentification, en examinant chaque parcours de manière indépendante.
Foire aux questions
Peut-on concevoir des e-mails d'authentification Supabase dans Migma ?
Oui. Vous préparez et validez le design dans Migma, puis téléchargez le code HTML pour qu'un développeur l'adapte et l'intègre dans le template Supabase approprié. Il s'agit d'un handoff HTML, et non d'un connecteur natif avec Supabase.
Quelles variables de template faut-il impérativement préserver ?
Conservez à l'identique les variables requises par le modèle concerné : URL de confirmation, jetons (tokens), adresses du site, URL de redirection et métadonnées. Référez-vous à la documentation actuelle de Supabase et vérifiez leurs valeurs au runtime.
Pourquoi un lien de confirmation peut-il échouer après réception de l'e-mail ?
Supabase documente deux causes fréquentes : les scanners de sécurité qui préchargent et consomment les liens à usage unique, et les outils de tracking qui réécrivent les URL. Vérifiez la méthode d'authentification retenue et la configuration du routeur ; un envoi réussi ne garantit pas la validité du parcours de connexion.
Migma Preflight remplace-t-il les tests d'authentification Supabase ?
Non. Preflight valide l'affichage en boîte de réception, le contenu, les liens et les risques d'envoi. Un test contrôlé sur l'environnement Supabase cible reste indispensable pour vérifier l'action d'authentification et la redirection effective.