Alternatives à Resend pour ceux qui ont besoin de plus qu'une belle API

Pourquoi les fondateurs cherchent des alternatives à Resend

Resend a débarqué en 2023 et s'est rapidement taillé une réputation chez les fondateurs techniques pour avoir la plus propre API d'email transactionnel du marché. Zeno Rocha et son équipe ont construit exactement ce que les fondateurs techniques voulaient : une API moderne, React Email pour écrire des templates sous forme de composants, des SDK TypeScript-first, et une documentation qui ne donne pas envie de fermer l'onglet.

Alors pourquoi chercher ailleurs ?

C'est une plateforme encore jeune. Resend est en production depuis quelques années, mais n'a pas le track record de plus de dix ans de SendGrid, Postmark ou Mailgun. Pour les fondateurs qui envoient des emails critiques (codes 2FA, reçus de paiement, notifications légales), la maturité de la plateforme pèse dans la balance. Un service qui a survécu à plusieurs Black Fridays, géré des pannes avec grâce et maintenu une délivrabilité constante au fil des ans inspire une confiance différente d'un nouvel entrant.

Le plan gratuit est minuscule. Cent emails par jour, plafonné à 3 000 par mois. Pour un builder solo qui teste son app, ca passe. Pour un produit en production avec un peu de traction, on explose ce plafond en un rien de temps. Un SaaS avec 200 utilisateurs actifs quotidiens qui envoie un email de bienvenue, un reset de mot de passe et un digest hebdo est déjà à la limite. La plupart des alternatives offrent des plans gratuits plus généreux ou des paliers d'entrée plus bas.

On paie un premium par rapport au SES brut. Resend est construit sur Amazon SES. A 50 000 emails par mois, Resend coûte 20 $. Le même volume directement via SES coûte environ 5 $. On paie 15 $ par mois pour une API plus propre, une meilleure doc et le support React Email. C'est un échange honnête pour beaucoup de développeurs, mais à mesure que le volume grimpe, l'écart se creuse. A 500 000 emails par mois, Resend facture 100 $ tandis que SES revient à environ 50 $.

Des manques pour les cas d'usage non-transactionnels. Resend a ajouté le support broadcast, mais il n'y a pas de gestion d'abonnés, pas de builder d'automatisations, pas d'analytics au-delà du suivi de livraison, et pas de formulaires d'inscription. Si les besoins email débordent du transactionnel pur, il faut un second outil. Certains fondateurs préfèrent une plateforme unique qui gère tout dès le départ.

La délivrabilité est une boîte noire. Parce que Resend est au-dessus de SES, la délivrabilité dépend de la réputation du domaine, des limites d'envoi SES, et de la manière dont Resend gère l'infrastructure partagée vs. dédiée. Postmark, en comparaison, publie ses métriques de livraison en temps réel. SendGrid fournit des analytics de délivrabilité détaillés. Avec Resend, on fait confiance que les emails arrivent mais on a peu de visibilité sur pourquoi un email n'arriverait pas.

Rien de tout ca ne signifie que Resend est mauvais. Pour un développeur qui construit une app Next.js et qui a besoin d'envoyer des resets de mot de passe et des confirmations de commande avec des templates React joliment designés, Resend est excellent. Mais si les besoins sont différents — plus de volume, budget plus serré, email marketing, ou un track record prouvé — les alternatives ci-dessous valent l'évaluation.

Analyse détaillée : ce que chaque alternative fait de mieux

SendGrid — le workhorse enterprise qui fait tout

SendGrid envoie des emails depuis 2009. Twilio l'a racheté en 2019, et même si l'acquisition a amené quelques difficultés de croissance (qualité du support en baisse, UI qui stagne), l'infrastructure de base reste solide comme un roc. Si Resend est le café de spécialité artisanal, SendGrid est la torréfaction industrielle.

Le plus gros avantage par rapport à Resend, c'est le périmètre. SendGrid gère le transactionnel et le marketing dans une seule plateforme. On peut envoyer des resets de mot de passe via l'API transactionnelle et lancer des campagnes newsletter via l'interface marketing, avec des pools d'IP séparés pour protéger la délivrabilité transactionnelle de la réputation des envois marketing. Avec Resend, il faut un second outil pour tout email marketing.

L'écosystème d'intégrations est imbattable. Chaque CMS, framework et plateforme SaaS a une intégration SendGrid. WordPress, Django, Rails, Laravel, Express — quel que soit le stack, il y a un SDK officiel ou maintenu par la communauté. Ca compte quand on intègre l'email dans un stack existant plutôt que de construire from scratch.

Les analytics sont complets. Taux de livraison, raisons de bounce, signalements spam, tracking de clics, tracking d'ouvertures et gestion des désinscriptions — tout est intégré. Resend donne un statut de livraison basique. SendGrid donne un dashboard plein de données actionnables sur pourquoi les emails arrivent ou non en inbox.

L'expérience développeur, c'est là que SendGrid montre son âge. L'API fonctionne, mais la documentation est tentaculaire et incohérente. Le dashboard est lent et la navigation entre transactionnel (Email API) et marketing (Marketing Campaigns) ressemble à deux produits distincts collés ensemble. En venant de Resend, on ressent la différence immédiatement.

Tarification à grande échelle : Essentials à 19,95 $/mois couvre 50 000 emails. Pro à 89,95 $/mois couvre 100 000 avec IP dédiée et fonctionnalités avancées. A comparer avec Resend à 20 $/mois pour 50 000 — à peu près équivalent à ce palier, mais SendGrid inclut le marketing que Resend n'a pas.

Idéal pour : Les fondateurs qui ont besoin du transactionnel et du marketing dans une seule plateforme, veulent des analytics poussés, et préfèrent la largeur d'intégration à l'élégance de l'API.

Postmark — l'obsédé de la délivrabilité

Si la délivrabilité est ce qui empêche de dormir la nuit, Postmark est la réponse. Construit par Wildbit (maintenant chez ActiveCampaign), Postmark a passé plus de dix ans à optimiser une seule métrique : faire arriver les emails en inbox le plus vite possible.

Postmark publie ses statistiques de livraison en temps réel sur son site. Leur temps de livraison médian est régulièrement sous la seconde. Pour les emails transactionnels sensibles au temps — codes 2FA, resets de mot de passe, confirmations de paiement — cette différence de vitesse est mesurable et significative. Resend est rapide aussi, mais Postmark a le track record plus long et les données publiques pour étayer ses claims.

La fonctionnalité Message Streams sépare le transactionnel et le broadcast en flux distincts avec des réputations indépendantes. Si on envoie un broadcast marketing qui génère des plaintes spam, ca ne fait pas baisser la délivrabilité de l'email transactionnel. C'est une décision architecturale intelligente qui protège les emails que les utilisateurs attendent activement.

Le traitement d'email entrant est une fonctionnalité que Resend ne propose pas. Postmark peut recevoir des emails sur le domaine, les parser (headers, body, pièces jointes) et transmettre les données parsées à l'app via webhook. Si le produit a besoin de traiter des emails entrants — tickets de support, features email-to-task, gestion des réponses — Postmark gère les deux directions.

Le système de templates est fonctionnel mais moins élégant que React Email. Postmark utilise une syntaxe de templating maison avec des variables et des layouts. Ca marche, mais si on a pris l'habitude de construire des templates comme des composants React avec Resend, la transition donne l'impression de reculer en termes de DX.

Tarification à grande échelle : 15 $/mois pour 10 000 emails, 50 $/mois pour 50 000, 100 $/mois pour 125 000. Plus cher par email que SES ou Resend à la plupart des paliers, mais on paie pour l'infrastructure de délivrabilité et la confiance qui va avec.

Idéal pour : Les fondateurs qui envoient du transactionnel sensible au temps et veulent le meilleur taux de placement en inbox possible, sans besoin de marketing dans le même outil.

Amazon SES — le coup de l'infrastructure brute

Voilà le truc avec Resend : c'est construit sur Amazon SES. Chaque email envoyé via Resend passe in fine par la même infrastructure SES. La question est de savoir si on veut payer Resend pour une interface plus agréable ou aller directement à la source.

Amazon SES coûte 0,10 $ par 1 000 emails. Pas de minimum mensuel. Pas de paliers de plans. Juste du pay-as-you-go pur qui fait paraître tous les autres providers chers à grande échelle. A 100 000 emails par mois, SES coûte environ 10 $. Resend coûterait entre 20 $ et du pricing custom. SendGrid Pro coûte 89,95 $. L'avantage coût n'est pas marginal — il est radical.

Le compromis, c'est tout le reste. La console SES est une console AWS, ce qui signifie qu'elle a été designée par des ingénieurs qui pensent que "intuitif" veut dire "a de la documentation." La vérification de domaine implique de naviguer les policies IAM, la gestion d'identités SES et les enregistrements DNS sans aucun flow de setup guidé. Pas d'éditeur de templates. Les analytics se résument à des métriques CloudWatch basiques. La gestion des bounces et des plaintes nécessite de configurer des topics SNS et des fonctions Lambda.

Si on est à l'aise avec AWS et que l'infrastructure tourne déjà là-bas, SES est un choix naturel. L'envoi d'email cohabite avec les autres services AWS, utilise la même facturation et bénéficie de la même infrastructure. Si AWS donne des maux de tête, SES ne changera pas ce sentiment.

La délivrabilité sur SES est sous la responsabilité de l'utilisateur. Pas de réputation partagée — la réputation du domaine est la sienne, pour le meilleur et pour le pire. Les nouveaux comptes SES démarrent en sandbox avec des limites d'envoi. On demande l'accès production, et à partir de là la délivrabilité dépend entièrement des pratiques d'envoi, de l'authentification du domaine et de l'hygiène de liste. C'est en fait un avantage pour les expéditeurs responsables : la réputation n'est pas tirée vers le bas par d'autres clients sur une infrastructure partagée.

Tarification à grande échelle : 10 000 emails = ~1 $. 50 000 = ~5 $. 100 000 = ~10 $. 1 000 000 = ~100 $. Rien d'autre n'approche en coût brut.

Idéal pour : Les fondateurs techniques sur AWS qui veulent le coût d'envoi d'email le plus bas possible et sont prêts à construire leur propre outillage autour de l'infrastructure brute.

Mailgun — le juste milieu fiable

Mailgun est dans le business de l'API email depuis 2010. Maintenant détenu par Sinch, il occupe l'espace entre la rudesse de SES et le polish de Resend. L'API est bien documentée, l'infrastructure est battle-tested et la délivrabilité est solide. Ce n'est pas excitant, mais ca fonctionne.

L'API de validation d'email est un atout que Resend ne propose pas. Avant d'envoyer à une adresse, Mailgun peut vérifier que la boîte mail existe, détecter les typos (gmail.com au lieu de gmial.com ?) et signaler les adresses email jetables. Pour les produits SaaS qui doivent vérifier les adresses email à l'inscription, ca élimine le besoin d'un service de validation séparé.

Le routage d'email entrant est une autre fonctionnalité absente chez Resend. Mailgun peut recevoir des emails sur le domaine, parser le contenu et transmettre les données structurées à l'app. Combiné avec l'envoi sortant, on obtient la gestion email bidirectionnelle dans un seul provider.

Les outils de logs et debug sont pratiques. Chaque email a un journal d'événements détaillé : accepté, livré, ouvert, cliqué, bouncé, signalé. Quand un utilisateur dit "je n'ai pas reçu l'email", on peut tracer le chemin de livraison exact et voir où ca s'est arrêté. Resend fournit un statut de livraison basique, mais Mailgun donne le détail forensique.

La DX, c'est là que Mailgun perd face à Resend. L'API est fonctionnelle mais sent le 2015 (parce qu'elle date de 2015). Le dashboard a besoin d'un rafraîchissement visuel. La documentation est correcte mais n'offre pas l'expérience polie de Resend. En venant de Resend, Mailgun donne l'impression de troquer l'intérieur d'une Tesla pour celui d'une Toyota — tout fonctionne, rien ne ravit.

Tarification à grande échelle : Le plan Flex est en pay-as-you-go. Foundation à 35 $/mois couvre 50 000 emails avec les fonctionnalités de base. Scale à 90 $/mois couvre 100 000 emails avec les outils de délivrabilité avancés et IP dédiée. Comparé à Resend à 20 $/mois pour 50 000, Mailgun est plus cher mais inclut la validation, l'email entrant et des analytics plus détaillés.

Idéal pour : Les fondateurs qui veulent une infrastructure email fiable et éprouvée avec validation d'email et traitement entrant, et qui préfèrent la stabilité à la DX moderne.

Plunk — l'option open source

Plunk est l'alternative pour les développeurs qui veulent posséder entièrement leur infrastructure email. C'est une plateforme email open source qui gère le transactionnel et le marketing basique, avec une UI propre qui ne ressemble pas à un projet auto-hébergé bâclé.

Le modèle auto-hébergé signifie zéro markup par email. On déploie Plunk sur son propre serveur, on le connecte à SES ou un service SMTP, et on ne paie que les coûts d'envoi sous-jacents. A 100 000 emails par mois via SES, le coût total est environ 10 $ pour SES plus le coût du serveur — radicalement moins que n'importe quelle alternative hébergée.

Le dashboard est étonnamment poli pour un projet open source. Gestion des contacts, édition de templates, triggers d'email transactionnel et analytics basiques — tout est là. Ca n'atteint pas l'élégance de l'API Resend ni les outils de délivrabilité de Postmark, mais les fondamentaux sont couverts.

Pour les fondateurs philosophiquement engagés dans l'infrastructure open source, ou qui opèrent dans des secteurs régulés où la souveraineté des données compte, l'auto-hébergement de l'email est un vrai avantage. Chaque email, chaque contact, chaque template vit sur une infrastructure qu'on contrôle. Aucun vendor ne peut changer les prix, déprécier des fonctionnalités ou arrêter le service.

Les risques sont réels cependant. Plunk est un projet early-stage avec une petite équipe. L'auto-hébergement signifie gérer les mises à jour, les patchs de sécurité, les sauvegardes et le scaling. La communauté grandit mais reste petite, ce qui signifie moins d'intégrations, moins de tutoriels et des corrections de bugs plus lentes que les plateformes établies.

Tarification : L'auto-hébergement est gratuit (on paie le serveur et les coûts SES/SMTP). La version cloud hébergée démarre gratuitement jusqu'à 1 000 emails par mois, avec des plans payants à partir de 10 $/mois.

Idéal pour : Les fondateurs-développeurs qui veulent la pleine propriété de leur infrastructure email et sont à l'aise pour gérer du logiciel auto-hébergé.

Loops — la plateforme email SaaS

Loops adopte une approche fondamentalement différente de Resend. Là où Resend fournit une API d'envoi et laisse tout construire le reste, Loops offre une plateforme email complète conçue spécifiquement pour les produits SaaS.

L'idée de base : l'app envoie des événements à Loops (user.signed_up, trial.started, feature.activated, payment.failed), et Loops déclenche le bon email en fonction de l'événement et de la position de l'utilisateur dans son lifecycle. Ce modèle event-driven signifie que les séquences d'onboarding, les nudges de conversion trial et les emails de prévention du churn vivent tous dans un seul système, déclenchés par ce que les utilisateurs font réellement dans le produit.

C'est exactement ce qu'on construirait soi-même en utilisant Resend : une base de données d'événements utilisateur, de la logique pour déterminer quels emails envoyer, et des templates pour chaque message. Loops package tout ca dans un produit pour qu'on n'ait pas à le construire. Pour les fondateurs SaaS qui veulent se concentrer sur leur produit plutôt que sur leur infrastructure email, ce compromis a du sens.

Loops gère le transactionnel et le marketing. Resets de mot de passe, séquences d'onboarding, annonces de features et campagnes de ré-engagement vivent tous dans une seule plateforme. Avec Resend, il faudrait Resend pour le transactionnel plus un outil séparé comme Mailchimp ou ConvertKit pour le marketing.

Le modèle de tarification est différent. Loops facture par contact (49 $/mois pour 5 000), pas par email. Si on a 3 000 utilisateurs et qu'on envoie 10 emails à chacun par mois, Loops coûte 49 $ quel que soit le volume. Resend facturerait en fonction des 30 000 emails envoyés. A des volumes par utilisateur modérés, Loops peut revenir moins cher. A des volumes élevés par contact, le modèle par email de Resend gagne.

Idéal pour : Les fondateurs SaaS qui veulent de l'email déclenché par le produit (transactionnel + lifecycle) dans une seule plateforme sans construire leur propre infrastructure de gestion d'événements.

Comparatif de coûts : les vrais chiffres

Voici ce qu'on paie réellement à trois paliers de volume courants. Les prix reflètent le plan le plus adapté à chaque niveau de volume.

10 000 emails par mois :

50 000 emails par mois :

100 000 emails par mois :

Le pattern est clair : SES et Plunk auto-hébergé sont les moins chers à chaque palier. Resend et SendGrid sont compétitifs au niveau 50 000. Postmark, Mailgun et Loops coûtent plus cher mais incluent des fonctionnalités (outils de délivrabilité, validation d'email, automatisation lifecycle) qui justifient le premium pour des cas d'usage spécifiques.

Quand rester sur Resend

Resend reste le bon choix quand :

• On construit avec React ou Next.js et on veut des templates email qui vivent dans le codebase sous forme de composants React. Aucun autre provider n'égale le workflow React Email.
• Le volume est sous 50 000 emails par mois. A 20 $/mois, Resend Pro est compétitif en prix avec SendGrid et moins cher que Postmark ou Mailgun. Le premium de DX est minime à cette échelle.
• L'expérience développeur est la priorité absolue. Si on valorise une API propre, une doc excellente et des SDK modernes par-dessus les fonctionnalités brutes ou le prix le plus bas, Resend reste le meilleur de sa catégorie.
• On est développeur solo et on veut shipper de l'email transactionnel en un après-midi, pas passer une semaine à configurer SES ou lutter avec le dashboard SendGrid.

Le coût de switching depuis Resend est faible. L'email transactionnel est essentiellement stateless — on remplace un appel API, on ne migre pas des bases de données d'abonnés. Si Resend fonctionne aujourd'hui, il n'y a pas d'urgence à partir. Mieux vaut évaluer les alternatives quand les besoins dépassent ce que Resend offre, pas avant.

Conseils de migration : quitter Resend

Migrer de provider d'email transactionnel est plus simple que migrer une plateforme d'email marketing, mais il y a des étapes à ne pas sauter.

1. Mettre à jour les enregistrements DNS

C'est l'étape la plus importante. Les enregistrements d'authentification email du domaine (SPF, DKIM, DMARC) pointent vers le provider actuel. Au moment du switch :

• Retirer les enregistrements DKIM de Resend du DNS
• Ajouter les enregistrements DKIM du nouveau provider
• Mettre à jour l'enregistrement SPF pour inclure les serveurs d'envoi du nouveau provider
• Garder la politique DMARC telle quelle — elle fonctionne indépendamment du provider

Ne pas retirer les anciens enregistrements avant que les nouveaux soient propagés. Les changements DNS peuvent prendre jusqu'à 48 heures pour se propager complètement, même si la plupart se font en quelques heures. Faire tourner les deux providers en parallèle pendant la transition.

2. Vérifier le domaine chez le nouveau provider

Chaque provider exige une vérification de domaine. Ca implique typiquement d'ajouter un enregistrement TXT ou des enregistrements CNAME au DNS. Commencer ce processus avant de planifier le switch — la vérification peut prendre de quelques minutes à un jour selon le provider et l'hébergeur DNS.

3. Remplacer les appels API dans le code

Si on utilise le SDK Resend, le remplacer par le SDK du nouveau provider. La logique d'envoi est similaire entre providers — on passe une adresse from, une adresse to, un subject et un body HTML. Si les templates ont été construits avec React Email, on peut continuer à l'utiliser : render les composants React en strings HTML, puis passer ce HTML à l'API de n'importe quel provider.

// Avant : Resend
const resend = new Resend('re_xxx');
await resend.emails.send({ from, to, subject, html });

// Après : n'importe quel provider
// Rendre React Email en HTML d'abord, puis envoyer via le nouveau SDK

4. Tester avant de basculer

Envoyer des emails de test vers plusieurs providers (Gmail, Outlook, Yahoo, Apple Mail) depuis le nouveau service avant de router le trafic de production. Vérifier que :

• Les emails arrivent en inbox, pas en spam
• Les liens et images s'affichent correctement
• Les headers de désinscription fonctionnent
• Les adresses reply-to sont correctes

5. Surveiller la délivrabilité après le switch

Surveiller les taux de livraison de près pendant les deux premières semaines. Un nouveau provider signifie que les emails viennent d'adresses IP différentes, pour lesquelles les fournisseurs de messagerie (Gmail, Microsoft) doivent construire une réputation. Si on observe une baisse du placement en inbox, réduire le volume temporairement et remonter progressivement — c'est la procédure de warmup standard pour toute nouvelle infrastructure d'envoi.

6. Garder Resend actif pendant la transition

Ne pas supprimer le compte Resend immédiatement. Le garder en fallback pendant au moins 30 jours. Si le nouveau provider a des problèmes de délivrabilité ou une panne, on peut re-router le trafic vers Resend le temps de diagnostiquer. Le plan gratuit ne coûte rien à maintenir.

La migration d'email transactionnel est l'un des changements d'infrastructure les plus simples qu'un fondateur aura à faire. Les emails sont stateless, les patterns d'API sont similaires entre providers, et les changements DNS sont réversibles. Compter une demi-journée pour une migration directe, une journée complète s'il faut convertir les templates React Email vers un nouveau format.