l'essentiel
Resend pour une DX moderne, des emails conçus en React et une API propre. SendGrid pour le volume, l'historique enterprise et une plateforme qui a fait ses preuves à grande échelle. Pour un nouveau SaaS, on prend Resend. Pour un besoin enterprise ou marketing à gros volume, SendGrid reste solide.
Outil
Resend
Infrastructure email moderne pensée pour les devs, avec une API épurée et des workflows React Email.
- Prix
- Tier gratuit disponible (100 emails/jour), puis facturation au volume d'envoi.
- Ideal pour
- Les devs qui veulent une infra email moderne, propre et rapide à intégrer.
Outil
SendGrid
Plateforme email établie avec de l'envoi transactionnel, des outils marketing et une large empreinte enterprise.
- Prix
- Plans gratuits et payants. Les coûts augmentent avec le volume d'envoi et les fonctionnalités avancées.
- Ideal pour
- Les équipes qui veulent un fournisseur éprouvé avec un historique long et une surface opérationnelle large.
verdict
Comparaison rapide
Un tableau propre pour voir vite ou chaque outil prend l'avantage.
| Dimension | Resend | SendGrid | Avantage |
|---|---|---|---|
| Expérience développeur | Doc plus propre, API plus propre, workflow moderne. | Capable mais plus ancien et plus lourd. | Resend |
| Surface produit | Focalisé et plus simple. | Plateforme plus large avec plus de surface existante. | SendGrid |
| Vitesse d'intégration | Très rapide pour les stacks modernes. | Toujours simple, mais moins agréable. | Resend |
| Empreinte enterprise | Plus récent avec une empreinte plus étroite. | Plus établi et plus familier aux grandes organisations. | SendGrid |
| Fit fondateur | Excellent pour les petites équipes techniques. | Correct, mais souvent plus de plateforme que nécessaire. | Resend |
Deux générations d'infra email
SendGrid, c'est le vieux routier. Lancé en 2009, racheté par Twilio en 2019, il envoie des milliards d'emails. C'est le genre de service qu'on trouve dans les grandes entreprises, approuvé par les équipes achats et intégré dans des stacks legacy depuis des années. Ça fonctionne. C'est fiable. Et c'est un peu pénible à utiliser.
Resend, c'est le challenger. Lancé en 2023 par Zeno Rocha (ex-GitHub), construit avec l'obsession de la DX et l'idée que l'email transactionnel mérite le même niveau de soin que le reste de la stack moderne. L'API est épurée, la doc est claire, et le projet phare React Email a changé la façon dont les devs pensent aux templates d'email.
Ce n'est pas un combat de fonctionnalités. C'est un combat de génération.
React Email : le game changer
Si on a déjà essayé de coder un email en HTML, on sait que c'est un cauchemar. Tables imbriquées, CSS inline, hacks pour Outlook, incompatibilités entre clients. L'email HTML est resté bloqué en 2005 pendant que le reste du web avançait.
React Email, le projet open source de l'équipe Resend, résout ça. On écrit des emails en JSX avec des composants React. <Html>, <Head>, <Body>, <Section>, <Row>, <Column>, <Button>, <Text> -- des composants qui génèrent du HTML email compatible avec tous les clients.
Concrètement, un email Resend ressemble à ça :
import { Html, Button, Text } from '@react-email/components';
export default function WelcomeEmail({ name }) {
return (
<Html>
<Text>Bienvenue {name} !</Text>
<Button href="https://app.example.com">
Accéder au dashboard
</Button>
</Html>
);
}On code un email comme on code un composant React. On le preview en local avec npx react-email dev. On le teste sur différents clients. Et quand c'est prêt, on l'envoie via l'API Resend. Le workflow est familier pour n'importe quel dev React.
SendGrid a un éditeur de templates visuel (drag-and-drop) et des templates dynamiques avec Handlebars. Ça fonctionne, mais c'est un monde différent. Les templates vivent dans le dashboard SendGrid, pas dans le code. Le versioning est séparé du repo. Le preview est dans l'interface web, pas en local.
Pour un dev moderne qui veut que ses templates email vivent dans le repo, soient versionnés avec git, et se comportent comme du code, React Email est une révolution. Pour une équipe marketing qui veut éditer des templates sans toucher au code, l'éditeur SendGrid est plus adapté.
Design d'API : la différence se voit au premier appel
L'API Resend est minimaliste et bien pensée. Pour envoyer un email :
curl -X POST https://api.resend.com/emails \
-H "Authorization: Bearer re_123" \
-H "Content-Type: application/json" \
-d '{"from": "hello@example.com", "to": "user@test.com", "subject": "Hello", "html": "<p>World</p>"}'C'est tout. L'API a quelques endpoints : emails, domains, api-keys, audiences, contacts, broadcasts. C'est compact et chaque endpoint fait exactement ce qu'on attend.
L'API SendGrid (v3) fonctionne, mais elle porte le poids de son histoire. L'objet JSON pour envoyer un email est plus verbeux, avec des personalizations imbriquées qui déroutent au premier usage. La doc est correcte mais dense, et il y a souvent plusieurs façons de faire la même chose.
Les SDK suivent la même logique. Le SDK Resend pour Node.js est léger et typé :
import { Resend } from 'resend';
const resend = new Resend('re_123');
await resend.emails.send({
from: 'hello@example.com',
to: 'user@test.com',
subject: 'Hello',
react: WelcomeEmail({ name: 'Alice' }),
});On passe directement un composant React comme contenu. C'est élégant.
Le SDK SendGrid fonctionne, mais il est plus lourd, plus verbeux, et le typage TypeScript est moins soigné.
Pricing : le calcul réel
Le tier gratuit de Resend permet 100 emails par jour (environ 3 000 par mois). Le plan Pro commence à 20 $/mois pour 50 000 emails. Au-delà, c'est 0,00040 $ par email. Pour un SaaS qui envoie des emails transactionnels (welcome, reset password, notifications), c'est très raisonnable.
Le tier gratuit de SendGrid permet 100 emails par jour aussi. Le plan Essentials commence à 19,95 $/mois pour 50 000 emails. Le plan Pro commence à 89,95 $/mois pour 100 000 emails avec des fonctionnalités supplémentaires (IP dédié, analytics avancé).
Pour du transactionnel pur à volume modéré, les deux sont dans les mêmes eaux. La différence se creuse sur deux axes :
-
Volume élevé : SendGrid a des plans pour des millions d'emails par mois, avec des IP dédiés, de la gestion de réputation et du support enterprise. Resend monte en volume aussi, mais SendGrid a plus d'historique sur les très gros volumes.
-
Marketing email : SendGrid a une offre marketing (campagnes, listes, segmentation) intégrée. Resend a ajouté les Broadcasts et les Audiences plus récemment. Si on a besoin d'envoyer des campagnes marketing en plus du transactionnel, SendGrid couvre les deux cas depuis plus longtemps.
Délivrabilité : le critère invisible
L'email qui n'arrive pas en inbox ne sert à rien. La délivrabilité est le critère le plus important et le plus difficile à évaluer.
SendGrid a des années d'expérience sur la délivrabilité. Des IP pools dédiés, des outils de gestion de réputation, des équipes compliance, et un historique de bonnes relations avec les fournisseurs de messagerie. Pour une entreprise qui envoie des millions d'emails, cette expertise compte.
Resend est plus jeune mais sérieux sur la délivrabilité. L'intégration DKIM, SPF et DMARC est simple à configurer. Le monitoring de la réputation existe. Mais le track record est plus court, et pour des volumes très élevés, il y a moins de retour d'expérience.
Pour un SaaS qui envoie quelques milliers d'emails transactionnels par mois, les deux sont parfaitement capables. Pour une entreprise qui envoie des millions d'emails par jour et qui a besoin de garanties de délivrabilité avec des SLA, SendGrid a l'avantage de l'historique et de l'infrastructure.
Transactionnel vs marketing : où tracer la ligne
C'est un point souvent négligé dans le choix.
Les emails transactionnels (confirmation de compte, reset de mot de passe, notifications, factures) sont le coeur de métier de Resend. Tout est optimisé pour ce cas : l'API, les templates, la délivrabilité.
SendGrid couvre le transactionnel et le marketing. On peut envoyer des newsletters, des campagnes promotionnelles, des emails de re-engagement, en plus du transactionnel. C'est pratique pour les équipes qui ne veulent pas gérer deux fournisseurs d'email.
Resend a ajouté les Broadcasts (envoi de masse à des audiences) et les Audiences (gestion de contacts). C'est un pas vers le marketing, mais c'est encore jeune. Pour du vrai email marketing avec de la segmentation avancée, des templates visuels et de l'A/B testing, SendGrid est plus complet -- ou on utilise un outil dédié (ConvertKit, Mailchimp) pour le marketing et Resend pour le transactionnel.
La meilleure architecture pour la plupart des SaaS : Resend pour le transactionnel (il fait ça très bien) et un outil dédié pour le marketing si nécessaire. Essayer de tout faire avec un seul outil, c'est souvent un compromis qui dessert l'un des deux cas.
L'écosystème et la communauté
Resend a construit une communauté de développeurs engagée autour de React Email. Le projet est open source, les contributions sont actives, et la doc est un exemple de clarté. L'écosystème de composants React Email s'enrichit régulièrement.
SendGrid (Twilio) est un acteur corporate. Le support est structuré, la doc est exhaustive (parfois trop), et l'écosystème est plus large en termes d'intégrations tierces (Salesforce, HubSpot, etc.). Mais la communauté dev est moins visible et moins engagée.
Pour un dev qui veut se sentir supporté par une communauté technique, Resend a l'avantage. Pour une entreprise qui a besoin d'un support commercial structuré et d'intégrations avec des outils enterprise, SendGrid a la surface.
Quand choisir Resend
- On construit un SaaS ou une app moderne et on veut la meilleure DX pour l'email.
- On veut écrire ses templates email en React et les versionner dans le repo.
- L'email est principalement transactionnel (notifications, confirmations, onboarding).
- L'équipe est technique et valorise une API propre et une doc claire.
- Le volume est modéré (quelques dizaines de milliers d'emails par mois).
- On préfère un outil focalisé à un couteau suisse.
Quand choisir SendGrid
- Le volume d'envoi est élevé (centaines de milliers ou millions par mois).
- On a besoin d'email transactionnel et marketing dans la même plateforme.
- L'entreprise a des exigences de procurement enterprise (Twilio est un vendor approuvé).
- On a besoin d'IP dédiés et de gestion avancée de la réputation.
- L'équipe marketing veut un éditeur visuel pour les campagnes.
- L'intégration avec des outils enterprise (Salesforce, etc.) est un besoin.
Le mot de la fin
Resend est ce que SendGrid serait si on le reconstruisait en 2024 avec la DX comme priorité absolue. L'API est plus propre, la doc est meilleure, React Email change la façon de penser aux templates, et le produit est un plaisir à utiliser.
SendGrid est le vétéran qui a les cicatrices et l'expérience. Des milliards d'emails livrés, des équipes dédiées à la délivrabilité, une surface enterprise rodée. C'est moins agréable à utiliser, mais ça a fait ses preuves à des échelles que Resend n'a pas encore atteintes.
Pour un nouveau projet, Resend est le choix par défaut. L'intégration est plus rapide, le code est plus propre, et le produit évolue vite. On n'a pas besoin de l'artillerie lourde de SendGrid pour envoyer des emails transactionnels correctement.
Pour un projet qui a déjà du volume, des contraintes enterprise ou un besoin de marketing email intégré, SendGrid reste un choix défendable. Pas le plus excitant, mais fiable.
Alternatives liees
FAQ
Resend est mieux que SendGrid pour les devs ?+
Pour la majorité des équipes modernes, oui. La doc, la forme de l'API et le feeling produit sont plus propres.
Pourquoi choisir encore SendGrid ?+
Historique, volume opérationnel, surface produit plus large et familiarité des grandes organisations. Les grosses boîtes se soucient souvent de ces critères.
Lequel pour un nouveau SaaS ?+
Resend, sauf s'il y a une raison enterprise ou procurement spécifique qui impose SendGrid.