Loops ou Resend : lequel doit envoyer les e-mails de votre produit ?

Ce que l’argent achète

Les deux chiffres ne sont pas comparables terme à terme, ce que la plupart des comparatifs passent sous silence. Les offres de Resend se mesurent en e-mails : 20 $ couvrent 50 000 envois, qu’ils aillent à 500 personnes ou à 50 000. Loops mesure les contacts abonnés, puis inclut des envois illimités vers eux, avec l’éditeur, les scénarios automatisés et l’envoi transactionnel vers des personnes extérieures à votre audience. Prenons une application qui écrit quatre fois par mois à chacun de ses 10 000 utilisateurs : cela fait 40 000 e-mails. Ce volume tient dans l’offre Pro de Resend à 20 $, contre 99 $ chez Loops, mais le montant de Loops couvre aussi l’outillage de cycle de vie que vous devriez sinon construire ou acheter.

Faisons passer la même application à 50 000 abonnés et 200 000 e-mails par mois. 200 000 e-mails sont un palier du curseur de Resend, où Scale affichait 160 $ le 7 octobre 2026 (Pro ne va sur ce curseur que jusqu’à 100 000 e-mails, à 35 $) : Scale est donc l’offre de cette taille. Loops affiche 249 $. L’écart se réduit parce que Resend facture le volume alors que Loops facture la taille de l’audience. Si vos utilisateurs reçoivent un e-mail par mois, Resend devient encore moins cher ; s’ils en reçoivent vingt, les envois illimités de Loops deviennent plus avantageux.

Première intégration, côte à côte

Loops fonctionne par événements. Votre application lui signale qu’il s’est passé quelque chose, et un scénario construit dans l’éditeur de Loops décide des e-mails qui suivent. Voici l’appel documenté pour envoyer un événement, tiré de la référence de l’API Loops :

curl --request POST \
  --url https://app.loops.so/api/v1/events/send \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "email": "alex@company.com",
  "userId": "usr_7f8e9d0c1b2a",
  "eventName": "signup",
  "eventProperties": {
    "plan": "pro"
  }
}
'

Chez Resend, le chemin le plus direct consiste à envoyer un message depuis le code. Voici l’exemple Node de la référence Send Email, avec l’option d’idempotence décrite sur sa page sur les clés d’idempotence :

import { Resend } from 'resend';

const resend = new Resend('re_xxxxxxxxx');

await resend.emails.send(
  {
    from: 'Acme <onboarding@resend.dev>',
    to: ['delivered@resend.dev'],
    subject: 'hello world',
    html: '<p>it works!</p>',
  },
  {
    idempotencyKey: 'welcome-user/123456789',
  },
);

La clé d’idempotence compte parce que les files d’attente rejouent les requêtes. Resend vérifie s’il a déjà envoyé un e-mail avec la même clé au cours des dernières 24 heures : une requête rejouée n’écrit donc pas deux fois au client. La clé voyage dans un en-tête HTTP Idempotency-Key, et le SDK l’expose sous forme d’option, comme ci-dessus. C’est un point pour Resend lorsque c’est votre propre code qui envoie. Avec Loops, vous envoyez un événement plutôt qu’un e-mail ; la protection contre les doublons dépend alors de la conception du scénario et de ses conditions d’entrée.

L’e-mail transactionnel chez chacun

Les deux savent le faire. Loops permet de construire un e-mail transactionnel dans son éditeur, de le publier, puis d’appeler le point d’accès transactionnel avec l’adresse du destinataire, un identifiant transactionnel et vos variables de données. L’appel peut ajouter le destinataire à votre audience grâce à addToAudience, et la documentation précise que l’e-mail transactionnel part vers n’importe quelle adresse, qu’elle figure ou non dans votre audience. Sa page tarifs indique que l’envoi transactionnel est inclus sans supplément sur les offres payantes. Chez Resend, le transactionnel est le cœur du produit : on envoie depuis le code, ou l’on définit une fois un modèle (« Template ») que l’on réutilise.

Si vos gabarits viennent d’un éditeur visuel ou d’un framework, une différence réelle mérite d’être notée. Loops permet d’apporter votre propre MJML à la place de son éditeur, avec des variables de données à l’intérieur, et sa documentation cite des plugins Figma qui exportent vers lui. Si vous écrivez vos gabarits en MJML ou React Email, vérifiez quel outil accepte votre résultat sans conversion. Resend est édité par l’équipe à l’origine de React Email, ce qui convient naturellement si vos gabarits sont des composants React.

L’automatisation du cycle de vie

C’était là que les deux produits se distinguaient facilement ; ils se recoupent maintenant. La documentation de Resend décrit les Automations : une série d’étapes déclenchées par des événements personnalisés de votre application, que l’on peut construire dans le tableau de bord ou par une API, avec un historique des exécutions pour le débogage. Loops bâtit son produit autour des scénarios, des événements et des segments d’audience : c’est là que son éditeur et ses outils sont les plus poussés. Si vos séquences sont courtes (un e-mail de bienvenue, une relance au bout de trois jours), l’un ou l’autre convient. Si vous avez besoin de nombreuses branches, d’objectifs et de segments entretenus par le marketing, Loops est plus proche de ce métier.

Choisir Loops si…

• Un responsable marketing produit ou un fondateur, et non un ingénieur, rédigera et modifiera les e-mails d’onboarding et de fidélisation.
• Vous voulez l’envoi, les scénarios automatisés et le transactionnel sur une seule facture, sans tarif par utilisateur.
• Votre audience compte moins de 1 000 contacts et vous voulez une offre gratuite qui inclut toutes les fonctions, quitte à accepter le pied de page Loops.

Choisir Resend si…

• Les développeurs possèdent le code des e-mails et veulent une API simple, des clés d’idempotence et des gabarits fondés sur React.
• L’essentiel de votre volume est transactionnel, et un prix par e-mail l’emporte sur un prix par abonné.
• Vous préférez garder la logique de cycle de vie dans votre propre application, ou vos séquences sont assez courtes pour les Automations.

Changer plus tard

Le domaine d’envoi est la partie facile : vérifiez les enregistrements DNS du nouveau fournisseur avant de basculer le trafic, et laissez l’ancien en service pendant la période de transition. Le plus dur, c’est la logique d’automatisation, car les noms d’événements et les conditions des scénarios ne s’exportent pas. Notez pour chaque séquence son déclencheur, son délai, sa condition de sortie et sa règle de suppression avant de partir, puis reconstruisez d’abord un flux peu risqué. Pour comprendre en général comment les flux marketing et transactionnels diffèrent, lisez e-mail transactionnel et e-mail marketing ; pour d’autres services d’envoi tournés vers les développeurs, comparez Resend vs Postmark et consultez la page l’e-mail pour l’usage transactionnel.