Pour une application bâtie sur Firebase, Resend convient bien aux messages transactionnels déclenchés par Cloud Functions ; gardez à part les campagnes destinées aux personnes ayant accepté de les recevoir. Firebase Authentication peut envoyer les vérifications d’adresse, réinitialisations de mot de passe et liens de connexion, avec des modèles, un domaine et un expéditeur à configurer. Firestore sert ensuite à synchroniser les préférences utiles vers votre outil d’emailing. Avant le premier envoi, séparez les flux, protégez les clés et authentifiez votre domaine d’expédition.
Resend est un choix cohérent pour envoyer depuis une application Firebase, car une Cloud Function peut appeler son API transactionnelle après un événement Authentication ou Firestore. Son offre Free comprend 3 000 emails par mois, avec une limite de 100 par jour ; le plan Pro coûte 20 $ par mois pour 50 000 emails. Cette approche demande du code et ne remplace pas un outil de campagnes avec gestion complète du consentement.
Postmark
Postmark peut isoler les messages importants comme les liens de connexion et les reçus dans un flux transactionnel. Son plan Basic commence à 15 $ par mois pour 10 000 emails ; la facturation supplémentaire dépend du volume. Il faut toujours vérifier que les modèles Auth et vos campagnes marketing restent gérés au bon endroit.
SendGrid
SendGrid peut servir lorsque plusieurs fonctions et services doivent envoyer des messages par API. Reliez chaque appel à un type d’email explicite et surveillez les erreurs de quota. Son éventail de fonctions implique davantage de réglages que le simple envoi d’un lien de vérification ; comparez aussi les conditions de tarification avant de prévoir une montée en charge.
Customer.io
Customer.io devient pertinent si les événements applicatifs et les attributs synchronisés pilotent des parcours d’adoption. Une fonction peut transmettre les changements retenus depuis Firestore, mais il faut définir les événements utiles et leur fréquence. La plateforme ajoute un système à maintenir en plus de Firebase ; ne lui envoyez jamais les champs sensibles par commodité.
Mailgun
Mailgun s’adresse aux équipes qui veulent piloter l’envoi et les événements de livraison depuis leur code. Une Cloud Function peut appeler son API, tandis que Firestore conserve les états métier. Cette liberté suppose de construire soi-même la synchronisation marketing et les règles d’exclusion ; une API d’envoi ne constitue pas à elle seule une gestion du consentement.
Brevo
Brevo peut réunir les campagnes et les contacts marketing dans une interface accessible à une petite équipe produit. Envoyez uniquement les champs nécessaires depuis Firestore et prévoyez le retour des désinscriptions vers votre base. Les automatismes disponibles et les limites d’envoi dépendent de l’offre choisie : vérifiez-les selon votre volume réel.
MailerLite
MailerLite peut convenir si votre besoin principal est d’informer les utilisateurs consentants sur les nouveautés du produit. Le raccordement à Firebase demandera un connecteur ou un export contrôlé plutôt qu’une dépendance implicite aux documents Firestore. Gardez une procédure de suppression et de désinscription, et vérifiez les limites incluses dans le plan retenu.
Recensez les messages gérés par Firebase Authentication : validation d’adresse, réinitialisation du mot de passe et connexion par lien envoyé par email. Leurs modèles se personnalisent dans la console Firebase, avec le texte, la langue et les URL de redirection adaptés à votre parcours. Vérifiez aussi le domaine d’action et l’adresse d’expédition affichée ; un outil marketing ne modifie pas automatiquement ces réglages Auth. Testez chaque lien sur mobile et après expiration.
L’extension Firebase Trigger Email surveille une collection Firestore et transmet les documents ajoutés à un serveur SMTP configuré ; une Cloud Function peut aussi appeler directement l’API d’un prestataire transactionnel. Dans les deux cas, définissez un schéma de document minimal, traitez les reprises sans envoyer deux fois le même message et consignez les erreurs sans y écrire de secret. Choisissez une seule autorité pour déclencher chaque type de message afin d’éviter les doubles envois.
Ne copiez pas chaque document utilisateur dans votre outil d’emailing. Dressez d’abord la liste des attributs nécessaires aux messages autorisés, par exemple la langue choisie ou le nom du forfait, puis filtrez et normalisez les données dans une fonction dédiée. Prévoyez les changements d’adresse, la suppression de compte et les échecs temporaires de synchronisation. Vérifiez l’existence d’un connecteur natif, d’un lien Zapier ou Make, ou seulement d’un export CSV.
Le compte Firebase et l’accord pour recevoir des offres sont deux informations distinctes. En prospection B2C, recueillez le consentement préalable et conservez dans Firestore sa date, son origine, le texte présenté et les choix de catégories. Propagez le retrait sans délai vers les listes marketing, et vérifiez le statut avant tout envoi déclenché par une fonction. Pour les clients existants, l’exception des produits ou services analogues exige notamment un moyen d’opposition dans chaque email.
Distinguez le volume des emails transactionnels du nombre de contacts auxquels vous adressez des campagnes : les fournisseurs ne facturent pas tous la même unité. Resend propose Free avec 3 000 emails mensuels et une limite de 100 par jour, puis Pro à 20 $ par mois pour 50 000 emails. Comptez les vérifications, liens de connexion et reprises de fonction dans votre prévision, sans supposer qu’un palier marketing les inclut.
Configurez l’expéditeur avec un sous-domaine dédié et publiez les enregistrements DNS demandés par le prestataire, notamment SPF, DKIM et une politique DMARC cohérente. Le domaine utilisé par les liens d’action Authentication et celui qui signe les emails peuvent être différents : contrôlez les deux. Commencez par des messages attendus, surveillez les rebonds et plaintes, puis augmentez progressivement les envois légitimes sans mélanger réinitialisations et newsletters.
Créez une fonction côté serveur qui reçoit un événement précis, vérifie que l’état du compte permet l’envoi, puis appelle l’API transactionnelle avec un modèle identifié par son nom. Pour éviter les doublons après une nouvelle tentative, enregistrez un identifiant d’événement traité ou utilisez une clé d’idempotence si le prestataire le permet. Retournez une erreur exploitable et mettez les échecs temporaires en file de reprise plutôt que de relancer sans limite.
Oui. Dans les modèles d’email de la console Firebase, adaptez le nom du produit, le texte, la langue et l’URL vers laquelle l’utilisateur revient après une action. Les messages de vérification, de récupération de compte et de connexion par lien ont chacun leur propre parcours : testez-les séparément, y compris lorsque le lien est ouvert sur un autre appareil. Le domaine et l’adresse d’expédition suivent les réglages disponibles pour votre projet et doivent être contrôlés avant la mise en production.
Le lien d’action inclut un domaine utilisé pour ramener la personne dans votre application. Configurez un domaine autorisé et les URL de retour dans les paramètres Authentication, puis vérifiez que les liens de développement et de production ne se croisent pas. Le domaine de lien n’est pas forcément le même que le domaine d’expédition du prestataire. Une fois les DNS configurés, validez le parcours depuis un email réel avant de remplacer le comportement par défaut.
Cette extension est conçue pour transmettre les emails représentés par des documents Firestore via un serveur SMTP configuré. Elle peut simplifier des notifications applicatives, mais ne remplace pas à elle seule la gestion des abonnements, des désinscriptions et des listes marketing. Pour une campagne, utilisez un outil qui conserve les choix de consentement et applique les exclusions. Évitez d’écrire un document d’envoi à partir d’un simple changement de profil sans vérifier la préférence du destinataire.
Limitez la synchronisation à l’adresse nécessaire à l’envoi, à la langue, aux préférences déclarées et aux quelques attributs qui justifient une segmentation. Ne transférez ni jetons d’authentification, ni contenu privé, ni historique brut d’activité par défaut. Écrivez une fonction de transformation avec une liste de champs autorisés, puis prévoyez comment elle traite la suppression d’un compte et la correction d’une adresse. Une copie réduite est plus simple à auditer et à effacer.
Vous pouvez conserver le choix dans Firestore, à condition qu’il soit rattaché au bon compte et modifiable par l’utilisateur. Gardez la date, la source de collecte, la formulation présentée et les catégories acceptées, puis consignez aussi le retrait. Un booléen isolé ne permet pas de comprendre le contexte du choix. Pour la prospection B2C, le consentement préalable est la règle ; faites valider votre formulaire et vos durées de conservation par votre DPO ou conseil.
Traitez l’état de désinscription comme une préférence prioritaire, et non comme un champ recalculé depuis le profil Firebase. Lors d’une synchronisation, une adresse déjà présente ne doit jamais être réabonnée automatiquement. Recevez si possible les événements de désinscription du prestataire et mettez à jour Firestore ; avant chaque campagne, appliquez la liste d’exclusion. Le lien de désinscription doit rester accessible dans chaque email commercial et son effet doit être testé de bout en bout.
Gardez la clé dans la configuration sécurisée utilisée par vos fonctions serveur et ne la transmettez jamais au client web ou mobile. Accordez-lui uniquement les permissions nécessaires, séparez les clés de test et de production, et remplacez-la immédiatement si elle apparaît dans un dépôt ou un journal. Évitez également d’inclure les en-têtes d’autorisation dans les traces d’erreur. Après rotation, vérifiez qu’aucune ancienne fonction ne dépend encore du secret révoqué.
Un afflux d’inscriptions peut déclencher de nombreux messages presque en même temps. Contrôlez les limites de débit de l’API et les plafonds journaliers de votre plan ; Resend Free, par exemple, est limité à 100 emails par jour. Si la fonction reçoit une réponse temporaire de limitation, placez le travail dans une file avec reprise différée et délai croissant. Ne renvoyez pas aveuglément une demande après un délai réseau, car le premier envoi a peut-être déjà été accepté.
Attribuez un flux et une identité d’expéditeur clairement reconnus aux messages qui débloquent l’accès au compte, et un autre aux communications commerciales. Cette séparation aide à diagnostiquer les rebonds et évite qu’une désinscription marketing bloque un lien de récupération indispensable. Conservez toutefois des règles cohérentes pour le domaine et surveillez la réputation des deux flux. Une newsletter ne doit pas être envoyée depuis le déclencheur Authentication simplement parce que l’adresse est déjà disponible.