# Séquence d’e-mails de bienvenue : exemples, délais et éligibilité

URL canonique : https://brew.new/fr/blog/welcome-email-sequence
Rédigé par Brew Team
Publication : 2026-08-16
Mise à jour : 2026-09-29

Une séquence de bienvenue aide un nouvel abonné à savoir quoi faire ensuite. Pour un produit SaaS, il peut s’agir de créer un premier projet. Pour une boutique, de comprendre la gamme de produits. Pour une newsletter, de savoir ce qui va arriver et à quelle fréquence.

Partez de la promesse faite à l’inscription. Chaque e-mail suivant doit aider à la tenir. Les délais et le nombre de messages dépendent du produit et de l’audience ; les exemples ci-dessous sont des points de départ à tester. La séquence de bienvenue est la première des séquences de cycle de vie présentées dans notre article [Automatisation e-mail par l’IA](/fr/blog/ai-email-automation).

## Choisissez le bon événement de départ

| Point de départ | Premier message utile | À vérifier |
| --- | --- | --- |
| Compte créé | Une action de configuration | Si la vérification de l’adresse e-mail doit avoir lieu d’abord |
| Adresse e-mail vérifiée | Un mot de bienvenue et un lien direct vers le produit | Ne pas faire doublon avec l’e-mail de vérification |
| Abonnement à la newsletter | Ce à quoi s’attendre et un exemple utile | Le consentement du destinataire et les thèmes choisis |
| Inscription à la boutique | Produits, conseils ou offre promise | Les conditions réelles de l’offre et sa date d’expiration |

Brew peut lancer des séquences à partir d’événements personnalisés envoyés par votre backend ou d’intégrations prises en charge comme [Supabase](/fr/browse/integrations/supabase) et [Clerk](/fr/browse/integrations/clerk). Construisez le payload à partir du schéma du déclencheur choisi, et utilisez son identifiant réel.

## Un exemple de bienvenue pour un SaaS

| E-mail | Délai de départ | Mission | Éligibilité à l’échéance |
| --- | --- | --- | --- |
| Bienvenue | Après l’inscription ou la vérification | Aider à créer le premier projet | Nouveau compte |
| Aide à la configuration | Jour 2 | Montrer un court exemple | Pas encore activé |
| Étape suivante | Après l’activation | Présenter la prochaine action utile | Activé |
| Rappel de fin d’essai | Avant la fin de l’essai | Expliquer ce qui se passe ensuite | Toujours en essai et sans paiement |
| Prise de nouvelles | Après un intervalle adapté | Proposer de l’aide | Toujours éligible et autorisé à le recevoir |

Construisez chaque e-mail autour d’une seule action. Utilisez une vraie URL de destination, un objet clair et une adresse de réponse que quelqu’un surveille. Évitez l’urgence générique et les promesses de résultats que vous n’avez pas mesurés.

## Un exemple de bienvenue pour une newsletter ou une boutique

Pour une newsletter, le premier message peut fournir la ressource promise, annoncer le rythme de parution et montrer un article représentatif. Un message suivant peut expliquer les préférences de thèmes ou présenter l’auteur. Une newsletter n’a pas besoin d’un tunnel d’activation à la mode SaaS pour justifier un deuxième e-mail.

Pour une boutique, livrez d’abord l’offre promise, puis donnez des conseils d’achat utiles. Indiquez précisément les exclusions et la date d’expiration. Un achat peut rendre inutiles les rappels de remise restants : intégrez donc le statut d’achat à vos contrôles d’éligibilité.

## Définissez les règles de sortie avant d’écrire les relances

Décidez de ce qui doit empêcher chaque message : une activation, un achat, une offre expirée, une suppression de compte, un désabonnement ou un changement d’offre. Mettez ensuite cette règle en place dans le système qui lit réellement l’état actuel.

Dans une séquence Brew déclenchée par un événement, une condition sur `payload.activated` lit l’événement d’origine. Une condition sur `contact.activated` lit la valeur actuelle du champ de contact dans Brew au moment où le nœud s’exécute, y compris après une étape d’attente. Déclarez et synchronisez le champ, puis placez la condition avant chaque rappel qui en dépend. Une mise à jour du contact ou un événement ultérieur n’annule pas automatiquement une exécution déjà lancée.

Pour une éligibilité qui dépend de données de compte non synchronisées ou d’un achat précis, programmez une vérification dans votre application. Lisez l’enregistrement qui fait foi au moment où le message arrive à échéance, puis déclenchez un événement de rappel distinct, réservé aux contacts éligibles, uniquement si la règle s’applique toujours. Consultez la page [Build an Automation](https://docs.brew.new/create-emails/build-an-automation#check-state-before-later-reminders) de la documentation.

## Créez et relisez la séquence

Décrivez dans Brew le déclencheur, l’audience, l’action souhaitée et le ton. Vous pouvez aussi partir d’un exemple public de la [galerie de séquences](/fr/browse/flows). Voyez ses délais comme une source d’inspiration, pas comme la preuve que le même calendrier fonctionnera pour votre audience.

Relisez le graphe généré et chaque e-mail. Vérifiez les liens, l’expéditeur, les valeurs par défaut de personnalisation et l’usage d’envoi du domaine. Un message de vérification et un message d’onboarding promotionnel peuvent être soumis à des exigences différentes. Le [guide de la FTC](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) explique le critère américain de la finalité principale ; les [exigences de Gmail envers les expéditeurs](https://support.google.com/mail/answer/81126) couvrent l’authentification, le taux de spam et les règles de désabonnement.

## Testez plus que le scénario idéal

Testez une inscription, un événement répété, une personnalisation manquante et un destinataire non éligible. Pour les conditions de contact, modifiez le champ synchronisé pendant l’attente et vérifiez que le rappel est bien ignoré ; testez aussi les champs manquants. Pour les rappels programmés par votre application, activez le compte ou effectuez un achat avant la vérification, et confirmez qu’aucun événement de rappel n’est déclenché. Vérifiez aussi la gestion des désabonnements et les résultats de délivrance.

Ne publiez qu’après avoir relu les messages et les contrôles d’éligibilité. Suivez l’action que la séquence doit favoriser, comme une configuration terminée ou une première commande, en plus des données de délivrance et de clics. Gardez les messages qui aident les gens à passer à l’action et retravaillez les autres.

Pour des exemples de mise en œuvre, consultez [créer un onboarding depuis Cursor](/fr/blog/how-to-create-an-email-onboarding-sequence-from-cursor) et [convertir les essais à partir des événements produit](/fr/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).