Transformez vos e-mails en revenus avec Brew.
Distinguez les messages de compte et de transaction du marketing, appliquez le critère de la finalité principale et envoyez via une automatisation Brew publiée.
Les e-mails transactionnels apportent une information sur une transaction ou une relation existante : un reçu, une réinitialisation de mot de passe demandée, une mise à jour d’expédition ou une alerte de sécurité du compte. Leur finalité diffère de celle d’une campagne qui invite quelqu’un à acheter ou à revenir.
La distinction dépend du message. Qualifier un e-mail de « transactionnel » dans un outil d’envoi ne détermine pas son statut juridique.
Le guide de conformité CAN-SPAM de la FTC décrit des catégories restreintes de messages transactionnels et relationnels. Pour un contenu mixte, à la fois commercial et transactionnel, il examine ce qu’un destinataire raisonnable comprendrait de l’objet, et l’endroit où figurent les informations transactionnelles.
Un objet promotionnel peut rendre commercial un message mixte. Un court pied de page promotionnel ne suffit pas automatiquement à le faire : la FTC cite l’exemple d’un relevé de compte qui reste principalement transactionnel. Le texte de la règle et le message lui-même sont déterminants.
Mettez en avant les informations essentielles. Si une promotion détourne l’attention d’un reçu ou d’une alerte de sécurité, un e-mail marketing distinct est généralement le choix éditorial le plus clair. Il s’agit de recommandations américaines : vérifiez les exigences qui s’appliquent à vos destinataires et à votre activité. Sources consultées le 28 septembre 2026.
| Message | Finalité habituelle | Points à vérifier |
|---|---|---|
| Reçu de commande ou avis de remboursement | Transactionnelle | Des informations de commande exactes et le bon destinataire |
| Réinitialisation de mot de passe demandée | Sécurité du compte | Une vraie demande, un lien valide et aucune offre qui détourne l’attention |
| Mise à jour d’expédition | Transactionnelle | Des informations sur la commande existante |
| Rappel de panier abandonné | Marketing | Le consentement, l’état actuel du panier et le fonctionnement du désabonnement |
| Incitation à passer à une offre supérieure en fin d’essai | Marketing | L’offre réelle et l’éligibilité actuelle du destinataire |
Un avis sur le statut du compte et une incitation à passer à une offre supérieure peuvent concerner le même essai et servir des finalités différentes. Regardez ce que l’e-mail demande au lecteur de faire.
Les consignes de Gmail imposent le désabonnement en un clic aux e-mails marketing et aux messages envoyés sur abonnement, et en distinguent les messages transactionnels. L’authentification et la réputation comptent toujours pour les deux.
Yahoo recommande de séparer le marketing de masse et le trafic transactionnel par adresse IP et, le cas échéant, par domaine. Suivez la configuration de votre prestataire d’envoi plutôt que de supposer qu’un nouveau sous-domaine suffit à créer une réputation indépendante.
Pour le marketing, la RFC 8058 définit le mécanisme de désabonnement en un clic par en-tête. Un lien en pied de page et un désabonnement par en-tête ont des rôles différents. Testez le comportement sur le message reçu.
Pour ce workflow, Brew utilise une automatisation publiée et son déclencheur. Configurez un domaine d’envoi vérifié avec l’usage d’envoi approprié, déclarez le payload du déclencheur et créez une étape « Envoyer un e-mail » qui utilise ce domaine. Le réglage du domaine détermine le comportement d’envoi de Brew ; il ne rend pas juridiquement transactionnel un contenu promotionnel.
Une fois l’automatisation testée et publiée, c’est votre backend qui actionne le déclencheur. Cet exemple suppose que le déclencheur déclare order_id et ship_date :
curl --fail-with-body \
"https://brew.new/api/v1/automations/triggers/${BREW_ORDER_TRIGGER_ID}/fire" \
-H "Authorization: Bearer ${BREW_API_KEY}" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: order-1234-shipped" \
-d '{"payload":{"email":"ada@example.com","order_id":"1234","ship_date":"Tuesday"}}'Utilisez l’identifiant réel du déclencheur et une clé d’idempotence stable pour l’événement. L’e-mail peut lire un champ déclaré du payload avec une syntaxe comme {{ trigger.order_id }}. Consultez la documentation des balises de fusion et testez les valeurs manquantes.
Examinez l’exécution et l’e-mail reçu. Testez le comportement en cas de nouvelle tentative et vérifiez que les désabonnements marketing sont traités selon l’usage d’envoi. Les autres protections, dont les listes d’exclusion, restent importantes : un réglage transactionnel ne garantit pas la délivrance à toutes les adresses.
Le guide de l’automatisation couvre la publication et les vérifications d’état. Si un assistant compose le modèle, la même vérification avant envoi s’applique.
