Pour une application Next.js déployée sur Vercel, Resend est un choix direct pour les emails transactionnels : son API se pilote depuis une route serveur et ses modèles peuvent être écrits en composants React Email. Vérifiez surtout la durée disponible pour la fonction, le traitement des réponses du fournisseur et la façon de reprendre un travail interrompu. Gardez les clés dans les variables d’environnement, validez votre domaine d’envoi et isolez les tests des vrais destinataires. Une file externe devient utile dès que le traitement dépasse une requête courte.
Resend convient aux équipes Next.js qui veulent déclencher des emails transactionnels depuis une route serveur et conserver leurs modèles près du code de l’application. Le plan Free inclut 3 000 emails par mois, avec une limite de 100 par jour ; le plan Pro coûte 20 $ par mois pour 50 000 emails. React Email facilite la composition et la prévisualisation des messages. Pour des campagnes marketing pilotées par segments ou des tâches longues, prévoyez un outil ou une file distincte : une fonction Vercel ne remplace pas un processus d’arrière-plan permanent.
Postmark
Postmark s’intègre par API à un gestionnaire de route et sépare les flux transactionnels des messages marketing. Son offre Basic démarre à 15 $ par mois pour 10 000 emails ; les volumes au-delà du quota ont un coût supplémentaire. Il ne remplace pas un outil de campagnes avec segmentation avancée.
Loops
Loops permet de transmettre des événements produit depuis le serveur, puis de laisser les séquences liées à ces événements au service. C’est adapté aux messages d’activation qui ne doivent pas prolonger la réponse HTTP. Vérifiez que les déclencheurs et critères de sortie couvrent votre parcours ; une API seule ne définit pas les règles métier.
SendGrid
SendGrid peut être appelé depuis une fonction serveur pour envoyer confirmation de commande, reçu ou lien de connexion. Gardez la requête distante hors du chemin critique lorsqu’une panne fournisseur ne doit pas bloquer l’action utilisateur. Les options et limites dépendent de l’offre ; vérifiez le tarif correspondant à votre volume avant migration.
Customer.io
Customer.io convient lorsque l’application transmet des événements nommés — par exemple une première publication ou une échéance approchante — qui alimentent ensuite des parcours. L’intégration demande de définir un schéma stable et de traiter les événements en double. Ne faites pas dépendre l’envoi d’un traitement synchrone coûteux dans la route Next.js.
Brevo
Brevo peut recevoir les inscriptions ou changements de profil transmis côté serveur et gérer les campagnes depuis son interface. Cette séparation évite d’embarquer la logique éditoriale dans le déploiement. Vérifiez les possibilités de synchronisation et de désinscription avant de pousser des contacts ; les volumes d’envoi et les fonctions disponibles varient selon l’offre.
Mailgun
Mailgun offre une approche orientée envoi depuis le serveur, utile lorsque l’équipe veut contrôler les appels et les réponses HTTP dans ses fonctions. Prévoyez le traitement explicite des erreurs temporaires, des rejets et des reprises afin de ne pas perdre de notifications. Les fonctions de newsletter ou de gestion marketing peuvent nécessiter un service séparé.
Une route qui envoie un email attend une réponse réseau ; elle peut aussi rencontrer une latence ou une indisponibilité du prestataire. Gardez le chemin synchrone court : validez les champs, transmettez la demande, puis répondez à l’utilisateur. Pour une opération lente, déléguez le travail au lieu de multiplier les appels dans la même invocation. Vérifiez le temps maximal autorisé pour votre fonction selon le runtime et la configuration du projet.
Une route Node.js et une fonction Edge n’exposent pas nécessairement les mêmes API. Avant de choisir un SDK, repérez les dépendances à des modules natifs ou à des sockets persistantes ; testez aussi l’appel HTTP dans le runtime réellement configuré. Il est souvent plus simple d’envoyer depuis un gestionnaire serveur Node.js que depuis un middleware. Celui-ci doit rester léger et ne pas porter l’envoi lui-même.
React Email permet de composer le contenu comme une interface React, puis de produire du HTML destiné aux clients de messagerie. Gardez les composants de courriel distincts des composants de page : les contraintes de tableaux, styles intégrés et liens de désinscription sont différentes. Prévisualisez les variantes avec et sans données facultatives, et vérifiez le rendu final en texte brut. Un modèle versionné avec le code rend les changements traçables lors d’un déploiement.
Un webhook entrant peut signaler un rebond, une plainte ou une désinscription. Exposez une route dédiée, vérifiez la signature sur le corps brut si le fournisseur l’exige, puis enregistrez l’événement avant de répondre avec succès. Les fournisseurs peuvent répéter une notification : conservez son identifiant et rendez le traitement idempotent. Ainsi une reprise ne réactive pas un contact qui s’est désinscrit et ne duplique pas une mise à jour métier.
Placez la clé d’API dans les variables d’environnement du projet et lisez-la uniquement dans du code serveur. Configurez séparément développement local, prévisualisation et production ; une branche de prévisualisation ne doit pas envoyer à la vraie liste. Ne préfixez pas le secret d’un nom réservé aux variables publiques, et ne l’écrivez ni dans les journaux ni dans les réponses d’erreur. Après rotation, redéployez les environnements concernés.
Configurez un domaine d’envoi dédié ou un sous-domaine et publiez les enregistrements d’authentification demandés avant la mise en production. Vérifiez l’expéditeur, les liens et la politique de réponse. Pour transmettre une inscription à l’outil marketing, faites-le depuis une action serveur après validation du consentement, en envoyant seulement les champs nécessaires. Prévoyez aussi la remontée des désinscriptions pour que les deux systèmes ne divergent pas.
Créez un gestionnaire serveur, par exemple dans app/api/notification/route.ts, qui valide la requête puis appelle l’API du fournisseur avec une clé conservée côté serveur. Une Server Action peut convenir si l’envoi découle directement d’un formulaire. Limitez les données acceptées par le client : le destinataire et le type de message peuvent être contrôlés par le serveur à partir de l’action métier. Retournez un statut clair et ne renvoyez jamais la clé ni le détail sensible de l’erreur fournisseur.
Une fonction a une durée maximale et son cycle de vie ne garantit pas qu’un travail lancé après la réponse HTTP continuera. Attendre l’acceptation de l’API est généralement raisonnable pour un message unitaire ; lancer une boucle d’envoi puis répondre avant sa fin peut perdre des tâches. Pour tout traitement qui doit survivre à l’invocation, enregistrez le travail dans une file durable et faites-le reprendre par un consommateur. Prévoyez une clé d’idempotence ou un identifiant métier pour éviter les doublons lors des reprises.
React Email sert à décrire un message avec des composants React et à le rendre en HTML pour son envoi. Il convient aux équipes qui gardent leur code d’interface et leurs modèles dans le même dépôt, avec revue des changements et historique Git. Le rendu doit toutefois respecter les clients mail : utilisez une structure simple, prévoyez une version texte et contrôlez les styles dans l’aperçu. Le fournisseur d’envoi reste un choix distinct ; il doit accepter le HTML rendu ou le contenu correspondant.
Attribuez une configuration de test aux déploiements Preview et une autre à Production dans les réglages d’environnement Vercel. Ajoutez un garde-fou serveur qui refuse les destinataires réels hors production, ou redirige les messages vers une boîte de recette. Testez ce garde-fou avec les chemins de formulaire et les Server Actions, pas seulement avec l’interface. Lorsqu’une branche est promue, vérifiez les variables de production et le domaine autorisé avant le premier envoi à un utilisateur.
Un cron convient pour déclencher à heure connue une tâche courte, comme créer les éléments d’une édition hebdomadaire ou repérer des rappels dus. Faites vérifier son secret d’accès et rendez le déclenchement répétable sans créer deux campagnes. Si le travail concerne beaucoup de destinataires, le cron doit déposer des lots dans une file plutôt que tout envoyer lui-même. Une queue permet de reprendre les erreurs et de limiter le débit ; consignez l’état de chaque lot afin de reprendre au bon endroit après une interruption.
Créez une route dédiée aux notifications du fournisseur et vérifiez leur signature avant toute action. Selon le mécanisme choisi, la vérification peut nécessiter le corps brut de la requête : ne parsez pas puis ne reconstruisez pas le JSON avant ce contrôle. Enregistrez l’identifiant et le type d’événement, répondez rapidement, puis déclenchez les traitements métier à part. Si une notification échoue temporairement, le fournisseur peut la renvoyer ; un traitement idempotent évite de répéter deux fois la même conséquence.
Après validation du formulaire et du consentement, transmettez les champs nécessaires à l’outil marketing depuis une action serveur. Enregistrez le statut de synchronisation et gérez les erreurs sans effacer l’inscription validée : une tâche différée peut effectuer une nouvelle tentative. N’envoyez pas les valeurs de formulaire directement depuis le navigateur avec une clé privée. Prévoyez le trajet inverse pour les désinscriptions ou demandes d’opposition, afin que l’application n’ajoute pas de nouveau le contact lors d’une prochaine mise à jour.
Choisissez une adresse d’expédition sur un domaine que vous contrôlez et suivez les enregistrements DNS demandés par le service, notamment pour authentifier les messages. Faites valider les changements par la personne qui gère le DNS, puis attendez leur prise en compte avant d’activer les envois réels. Utilisez une adresse de réponse surveillée si les destinataires doivent pouvoir répondre. Séparez les notifications de compte des campagnes commerciales lorsque cela facilite le suivi des rejets et des demandes de désinscription.
Ajoutez une page ou une commande de prévisualisation réservée au développement qui rend le même composant React Email que le code d’envoi. Fournissez des données fictives couvrant les champs longs, absents et les différentes langues ; un aperçu avec un seul nom court ne révèle pas les débordements. Vérifiez aussi la version texte, les liens et le contenu de pied de page. La prévisualisation ne doit pas appeler l’API de production : séparez clairement le rendu local de l’envoi effectif.
Décidez quel système fait autorité pour l’état du consentement et documentez le sens de synchronisation. Lorsqu’un contact se désinscrit, traitez le webhook correspondant ou récupérez l’état avant tout nouvel ajout ; ne supposez pas qu’une mise à jour de profil rétablit son accord. Gardez une trace de la date et de la source du consentement selon vos besoins internes, et proposez un mécanisme d’opposition dans les messages commerciaux. Faites vérifier le processus par votre DPO ou conseil.