React Email et Resend : la stack moderne pour les emails transactionnels en TypeScript en 2026

Pendant des années, écrire un email transactionnel signifiait composer manuellement des tableaux HTML pour Outlook, jongler avec les styles inline et croiser les doigts pour que le rendu tienne dans Gmail mobile. En 2026, le duo React Email plus Resend a complètement renversé cette expérience : on écrit ses emails en composants React typés, on les envoie via une API HTTP minimaliste, et l'on récupère un suivi de délivrabilité digne d'un service moderne. Pour les équipes TypeScript et les développeurs freelance qui livrent des SaaS, c'est devenu la stack par défaut.

Pourquoi React Email change la donne sur les emails HTML

React Email est une bibliothèque open source qui fournit un ensemble de composants React (Section, Container, Heading, Button, Text, Tailwind, Hr, Img, Link...) compilés à la volée vers du HTML compatible avec les principaux clients mail. Là où des outils plus anciens comme MJML imposaient un DSL spécifique, React Email reste dans le langage que toute l'équipe connaît déjà : JSX et TypeScript. Le rendu est exécuté côté serveur via la fonction render fournie par le package, ce qui permet d'inclure ces emails aussi bien dans une route Next.js que dans une fonction Hono déployée sur Cloudflare Workers. Cerise sur le gâteau, un mode preview local lance une UI web où l'on parcourt ses templates, l'on inspecte le HTML produit et l'on simule différents jeux de props pour valider le rendu sans envoyer un seul email réel.

Resend : l'API email pensée pour les développeurs TypeScript

Là où SendGrid ou Mailgun arrivent avec une décennie de fonctionnalités empilées, Resend a fait le choix d'une API minimaliste, entièrement typée, et d'une expérience développeur calquée sur celle de Stripe ou Vercel. Le SDK officiel resend pour Node.js, Bun et Deno expose à peine quelques méthodes — emails.send, batch.send, broadcasts, contacts, audiences — toutes documentées avec des types TypeScript précis. La configuration DNS DKIM, SPF et DMARC se fait depuis le dashboard en quelques clics, le suivi de délivrabilité (delivered, bounced, complained, opened) est exposé via webhooks, et la facturation reste prévisible. Pour les freelances qui jonglent entre plusieurs SaaS clients, configurer un nouveau projet email se fait littéralement en moins de dix minutes.

Composer et envoyer un email de bienvenue type

L'écriture d'un template suit la même logique qu'un composant React classique : on déclare une interface de props, on assemble les composants fournis par react-email/components, et l'on style soit avec des props inline soit avec le composant Tailwind qui évalue les classes utilitaires en styles inline compatibles email. Côté backend, le SDK Resend prend en charge directement un composant React via la propriété react, ou un HTML déjà rendu via la propriété html — le choix dépend de l'environnement d'exécution. Voici un exemple condensé qui envoie un email de bienvenue avec un lien d'activation typé :

import { Resend } from 'resend';
import WelcomeEmail from '@/emails/welcome';

const resend = new Resend(process.env.RESEND_API_KEY);

await resend.emails.send({
  from: 'Studio2B <hello@studio2b.io>',
  to: user.email,
  subject: 'Bienvenue sur Studio2B',
  react: WelcomeEmail({ firstName: user.firstName, activationUrl }),
});

Les types remontent jusqu'aux props du composant, ce qui élimine la classe entière de bugs liés aux variables de template manquantes. En cas d'erreur, Resend retourne un objet error structuré que l'on peut router vers Sentry ou un canal Slack.

Templates partagés, branding et tests : organiser une vraie production

Sur un projet sérieux, la stack ne s'arrête pas à un template isolé. On organise généralement un dossier emails dédié à la racine du repo, exposant un layout commun (header, footer, palette de couleurs basée sur Tailwind) consommé par tous les templates : welcome, password reset, magic link, factures, alertes produit. La preview locale fournie par react-email dev devient alors l'éditeur de référence pour les designers et le product owner, qui peuvent valider chaque variation sans toucher au code. Côté tests, on combine Vitest pour vérifier la sortie HTML produite par render, et MSW ou un compte Resend de sandbox pour les tests d'intégration end-to-end. Enfin, l'observabilité passe par les webhooks Resend stockés dans une table dédiée, ce qui permet de bâtir un mini tableau de bord de délivrabilité directement dans l'admin du SaaS — un gros plus pour rassurer les clients sur la fiabilité des notifications critiques.