Pour un SaaS développé en solo, Resend constitue un point de départ cohérent lorsque les messages partent du code : son offre Free inclut 3 000 emails par mois, avec une limite de 100 par jour et trois domaines. Avant de choisir, séparez les emails indispensables au produit des newsletters, puis vérifiez l’API, le relais SMTP, les webhooks et le prix au volume réellement envoyé. Un seul service peut suffire au lancement, à condition de garder les modèles, les consentements et les événements compréhensibles sans équipe marketing. React Email ou MJML permettent de versionner les gabarits avec le reste du projet.
Resend convient aux développeurs indépendants qui veulent déclencher les emails du SaaS depuis leur application et garder les modèles près du code. Free couvre 3 000 emails par mois, 100 par jour et trois domaines ; Pro coûte 20 $ par mois pour 50 000 emails. Cela permet de commencer sans abonnement payant, mais cette offre est centrée sur l’envoi : prévoyez un outil distinct si vous avez besoin d’une vraie gestion de newsletter ou de campagnes complexes.
Postmark
Postmark peut isoler les confirmations, reçus et liens de connexion du flux marketing. Son offre Free plafonne à 100 emails par mois ; Basic coûte 15 $ par mois pour 10 000 emails. Ce plafond convient à une intégration en préproduction ou à un très petit lancement, mais atteint vite sa limite avec les notifications d’usage.
Brevo
Brevo peut gérer une liste de contacts et quelques séquences autour des annonces du produit, sans imposer une architecture API à chaque envoi. Son offre Free est limitée à 300 envois par jour. Vérifiez si les événements de votre application arrivent proprement par API ou webhook avant d’en faire le centre des messages transactionnels.
Loops
Loops réunit des messages liés au cycle de vie du produit et une audience d’inscrits, pratique pour automatiser bienvenue et activation sans monter un dispositif marketing complet. Early Stage Plan est gratuit ; Growing Audience Plan coûte 48 $ par mois pour 4 788 contacts. Le coût dépend des contacts abonnés, pas seulement des emails envoyés.
Mailgun
Mailgun fournit API et SMTP, ce qui permet de choisir entre appels depuis le serveur et relais existant. Free autorise 100 emails par jour ; Basic coûte 15 $ par mois pour 10 000 emails. La rétention des journaux Free est courte, aussi prévoyez de conserver les identifiants d’événement utiles à votre propre support.
MailerLite
MailerLite peut convenir si la liste d’inscrits et les campagnes éditoriales deviennent aussi importantes que les emails applicatifs. Il s’agit d’un outil de marketing par contacts, pas du choix API-first le plus direct pour les reçus ou réinitialisations de mot de passe. Examinez les limites du forfait retenu et évitez d’y faire transiter des messages critiques du SaaS.
Customer.io
Customer.io s’adresse aux parcours déclenchés par les événements et attributs d’un produit, par exemple une inscription sans première action. Il demande de définir soigneusement événements, propriétés et règles de sortie ; pour un SaaS minuscule, cette modélisation peut coûter plus de temps que quelques appels API directs.
Un produit qui démarre envoie peu de messages, mais une boucle de notifications peut croître avec les inscriptions et les actions. Comparez une tarification par email à une tarification par contact : la première suit l’activité, la seconde peut coûter même si la liste dort. Estimez séparément reçus, alertes, invitations et campagnes, puis regardez les limites journalières autant que le plafond mensuel annoncé.
Pour les emails de compte, gardez les modèles dans le dépôt afin que les changements de texte suivent les revues de code et les déploiements. React Email convient à un projet React ; MJML peut servir à produire une mise en page responsive sans écrire tout le HTML à la main. Vérifiez le rendu texte brut, les liens et les variables de personnalisation, puis prévoyez une méthode de prévisualisation qui ne divulgue pas de données réelles.
Définissez quelques événements stables, comme compte créé, paiement confirmé ou export terminé, plutôt que d’envoyer depuis chaque écran de l’application. L’API déclenche l’email et le webhook de retour peut signaler livraison, rebond ou plainte à votre système. Vérifiez la signature des webhooks, la politique de nouvelle tentative et la déduplication : une répétition réseau ne doit pas envoyer deux reçus identiques.
Utilisez un sous-domaine dédié aux envois du produit afin de distinguer sa réputation de celle du courrier personnel. Publiez les enregistrements SPF et DKIM demandés par le prestataire, puis configurez DMARC avec une politique adaptée à votre étape de déploiement. Contrôlez les en-têtes reçus et la boîte de rebonds après un envoi réel ; une configuration DNS correcte ne remplace pas le suivi des plaintes et des adresses invalides.
Une réinitialisation de mot de passe répond à une action du compte ; une annonce commerciale suit une autre finalité. Ne conditionnez pas l’accès au service à l’inscription à une newsletter. Stockez la preuve et la date du consentement marketing, proposez un désabonnement simple et excluez ces personnes des campagnes après retrait. Cette séparation évite qu’un envoi promotionnel soit déclenché par erreur par un événement transactionnel.
Commencez par un message de bienvenue après création de compte, une relance si une étape produit manque et un avis avant une échéance importante. Ajoutez une condition d’arrêt quand l’utilisateur termine l’action ou se désabonne des messages marketing. Gardez les règles dans un endroit documenté et testez les cas de double événement, compte supprimé et adresse modifiée ; une automatisation courte se dépanne plus facilement seul.
Traitez les deux flux comme des usages distincts, même si un prestataire propose les deux. Un reçu ou un lien de connexion suit une action nécessaire au compte ; une newsletter promotionnelle demande une base légale et une gestion de désabonnement adaptées. Utilisez des catégories ou flux séparés, des expéditeurs identifiables et des règles d’accès différentes dans le code. Ainsi, une plainte sur une campagne ne doit pas empêcher l’envoi d’un message indispensable, et un événement de compte ne doit jamais réinscrire quelqu’un au marketing.
L’API s’intègre naturellement à un backend qui crée déjà des événements métier et permet de transmettre des variables structurées. SMTP peut être plus simple si votre application ou un service existant sait déjà remettre les messages par relais. Dans les deux cas, gardez les identifiants et clés hors du navigateur, prévoyez une file d’attente pour les pannes et consignez un identifiant de message. Faites un essai sur une boîte de développement avant de brancher reçus ou alertes sur les comptes réels.
Ils permettent de faire remonter au produit des changements survenus après la demande d’envoi : livraison, rebond ou plainte, selon les événements proposés par le fournisseur. Vous pouvez alors marquer une adresse en échec, éviter de répéter une notification inutile et aider le support à comprendre un email manquant. Validez la signature reçue, répondez rapidement au webhook et traitez les doublons de façon idempotente. Ne faites pas dépendre une action critique de l’arrivée instantanée d’un événement externe.
Rendez le modèle avec des données fictives couvrant les cas courts et longs : nom absent, montant élevé, adresse complète et texte traduit. Examinez la version HTML et la version texte, puis ouvrez le message dans plusieurs clients de courrier courants. Vérifiez particulièrement les liens d’action, le contraste, les images distantes et le comportement sur mobile. Évitez les vraies données d’abonnés dans les captures de développement et faites correspondre les variables requises du modèle au schéma validé côté serveur.
Un sous-domaine comme mail.exemple.fr ou notifications.exemple.fr rend la fonction de l’expéditeur lisible et permet de gérer séparément les enregistrements DNS. Le nom importe moins que la cohérence entre le domaine visible, les liens du message et l’infrastructure d’envoi. Ajoutez SPF et DKIM selon les instructions du service, puis publiez une politique DMARC maîtrisée. Vérifiez aussi que les réponses arrivent à une adresse suivie : les utilisateurs peuvent répondre aux reçus ou signaler une erreur de compte.
Calculez les messages réellement déclenchés par un compte actif, puis distinguez ce volume des contacts inscrits à une newsletter. Resend Free comprend 3 000 emails mensuels et une limite de 100 par jour ; Postmark Free en comprend 100 par mois, tandis que Mailgun Free en autorise 100 par jour. Les offres gratuites ont donc des unités et plafonds différents. Surveillez les envois de test et les tâches planifiées, qui peuvent consommer le quota sans correspondre à un usage client.
Identifiez quelles données partent dans les champs de personnalisation, où elles sont hébergées et comment elles sont supprimées à la fermeture d’un compte. Examinez le contrat de sous-traitance prévu à l’article 28 du RGPD, les sous-traitants ultérieurs et les options de transfert ; demandez conseil à votre DPO ou conseil pour les points incertains. Limitez les attributs envoyés à ceux nécessaires au message, restreignez les accès au tableau de bord et évitez de placer des secrets ou données sensibles dans les événements.
Commencez par l’email qui aide un nouvel utilisateur à accomplir une action utile dans le produit, par exemple créer son premier projet ou inviter un membre. Déclenchez-le sur un événement explicite, ajoutez un lien direct vers l’étape et arrêtez la séquence dès que l’action est terminée. Gardez une branche pour les comptes qui n’ont pas confirmé leur adresse. Cette logique apporte une aide liée à l’usage, sans transformer chaque événement en campagne répétitive ni envoyer des relances après désactivation du compte.
La séparation devient utile lorsque les volumes, les règles d’accès ou les conséquences d’une panne diffèrent nettement entre reçus et campagnes. Un service marketing peut gérer consentements, désabonnements et segmentation ; un service transactionnel peut rester proche du backend et de ses événements. Deux fournisseurs ajoutent toutefois DNS, surveillance et configuration à maintenir. Avant de scinder, assurez-vous de savoir quel système est responsable des rebonds, des plaintes et de la suppression d’une adresse sur chaque flux.
Attribuez une clé idempotente à l’événement métier ou enregistrez une clé unique composée de l’événement et du destinataire avant l’envoi. Si le serveur reprend une tâche après un délai réseau, il peut vérifier si la demande a déjà été acceptée au lieu de créer un second email. Conservez l’identifiant du fournisseur pour rapprocher les webhooks ultérieurs. Pour les reçus, relancez une opération de paiement ou d’envoi avec prudence et distinguez clairement l’échec de la demande de l’incertitude sur son résultat.