# Séquence e-mail de conversion des essais SaaS avec les événements produit

URL canonique : https://brew.new/fr/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
Rédigé par Thomas Park
Publication : 2026-09-26
Mise à jour : 2026-09-29

Un e-mail de conversion d’essai doit réagir à ce que l’utilisateur a fait. Quelqu’un qui n’a pas encore créé de projet a besoin d’aide pour la configuration. Quelqu’un qui utilise le produit tous les jours a besoin d’une explication claire de l’offre payante. Envoyer le même compte à rebours à ces deux personnes, c’est passer à côté de cette différence.

Ce guide distingue la conception de la séquence de la logique applicative qui décide qui doit recevoir chaque e-mail.

## Choisissez un événement d’activation

Choisissez une action qui montre que l’utilisateur a obtenu un premier résultat utile avec le produit. Elle doit être assez précise pour que votre backend puisse l’enregistrer : un projet créé, un import terminé ou un coéquipier invité. Une simple page vue suffit rarement.

Enregistrez la date d’inscription, la fin de l’essai, l’activation et le statut payant dans le système qui fait foi pour ces données. Considérez les champs de contact de votre plateforme e-mail comme des données synchronisées, pas comme la preuve qu’une séquence lancée plus tôt lit un état à jour.

## Donnez une seule mission à chaque message

| Message | Quand il est utile | Éligibilité vérifiée à l’échéance |
| --- | --- | --- |
| Bienvenue | Après l’inscription ou la vérification | Le compte existe et peut recevoir ce message |
| Aide à la configuration | Environ deux jours plus tard, à adapter à votre produit | Pas encore activé |
| Prochaine action utile | Après l’activation | Activé, sans avoir encore effectué cette action |
| Fin de l’essai | Avant la date réelle de fin de l’essai | Essai toujours en cours et compte non payant |
| Dernière prise de nouvelles | Après la fin de l’essai, si c’est pertinent | Toujours non payant, éligible et autorisé à recevoir des e-mails marketing |

Ces délais sont des points de départ à tester, pas des intervalles dont on aurait mesuré qu’ils donnent les meilleurs résultats. Indiquez la date réelle de fin de l’essai et ce qui se passe ensuite. Ne fabriquez pas de rareté et ne laissez pas entendre qu’un prélèvement aura lieu si aucun moyen de paiement n’est enregistré.

## Choisissez la source des contrôles d’éligibilité

Dans une séquence Brew déclenchée par un événement, `payload.activated` lit l’événement d’origine, tandis que `contact.activated` lit la valeur actuelle du champ de contact Brew du destinataire au moment où s’exécute un « Filtre » ou un « Embranchement » conditionnel. Pour ne plus envoyer de rappels de configuration après l’activation, déclarez ce champ booléen, synchronisez-le depuis votre produit et vérifiez `contact.activated equals false` après chaque « Attente » concernée. Une valeur manquante n’équivaut pas à false : testez ce cas séparément.

Ces lectures portent sur le contact enregistré dans Brew, pas sur la base de données de votre application ni sur une requête Stripe en temps réel. Recevoir un événement d’activation ou de paiement n’annule pas automatiquement une exécution lancée plus tôt. Le graphe a besoin d’une condition avant chaque envoi qui dépend de l’état.

Pour les données qui se trouvent hors de Brew, faites programmer un job par votre application. À l’échéance, lisez l’état actuel du compte ou de la facture, et ne déclenchez un événement personnalisé Brew distinct que si le destinataire remplit toujours les conditions. Incluez dans ce nouvel événement les données actuelles nécessaires à la personnalisation.

Par exemple, un rappel programmé par l’application fonctionne ainsi :

```text
Signup committed → fire welcome event
Reminder job becomes due → read current account
  Already activated or paid → finish without firing an email event
  Still eligible → fire setup-reminder event with current data
```

Utilisez l’identifiant de déclencheur réellement renvoyé par Brew et le schéma déclaré du déclencheur. Suivez le [guide de configuration des automatisations](https://docs.brew.new/create-emails/build-an-automation) et la documentation sur les [contrats de payload typés](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Pour les nouvelles tentatives de déclenchement, utilisez le mécanisme d’idempotence documenté.

## Utilisez Stripe pour les données dont il est la source

Si Stripe gère l’essai, ses événements d’abonnement fournissent le contexte de facturation. L’[intégration Stripe](/fr/browse/integrations/stripe) propose des déclencheurs pour les événements pris en charge, dont `customer.subscription.trial_will_end`. L’activation dans le produit reste du ressort de votre application, à moins que vous ne transmettiez cette information séparément.

Pour un rappel ultérieur lié au paiement, vérifiez l’enregistrement Stripe actuel. Une mise à jour de carte réussie ne prouve pas qu’une facture a été payée. Coordonnez vos envois avec les e-mails que Stripe envoie lui-même, pour que le client ne reçoive qu’un seul avis par finalité.

## Rédigez l’e-mail une fois la règle d’éligibilité fixée

Partez de la situation réelle du destinataire. Expliquez une action utile et ajoutez un lien direct vers elle. Un e-mail de configuration peut proposer un court exemple et une adresse de réponse. Un e-mail sur l’offre payante doit décrire la limite ou la fonctionnalité concernée et le prix réel, avec un lien vers les tarifs en vigueur.

Alignez le consentement marketing, la gestion des désabonnements et l’usage d’envoi du domaine sur le message. Une inscription à l’essai ne justifie pas des e-mails promotionnels sans rapport avec lui.

## Prouvez que les sorties fonctionnent

Testez ce qui se passe quand un contact est activé ou paie avant chaque contrôle d’éligibilité. Avec des conditions sur le contact, modifiez les champs Brew concernés pendant l’attente et vérifiez que le rappel est bien ignoré. Avec des vérifications programmées par l’application, vérifiez que les comptes non éligibles ne produisent aucun événement de rappel. Testez aussi les nouvelles tentatives, les prolongations d’essai, les suppressions de compte, les désabonnements et les champs manquants. Contrôlez à la fois les logs de l’application et l’historique d’exécution dans Brew.

Évaluez l’activation et la conversion en offre payante avec les données de votre produit, et les échecs de délivrance avec la plateforme e-mail. Les taux d’ouverture ne montrent pas, à eux seuls, si la séquence a aidé un utilisateur en essai. Consultez notre [guide de la séquence de bienvenue](/fr/blog/welcome-email-sequence) pour des exemples, et [MCP ou REST](/fr/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use) pour savoir comment répartir la mise en œuvre.