# Comment créer une séquence e-mail d’onboarding depuis Cursor

URL canonique : https://brew.new/fr/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Rédigé par Philip Sørensen
Publication : 2026-09-25
Mise à jour : 2026-09-29

Un e-mail d’onboarding dépend des mêmes données d’événement que votre produit. Travailler depuis Cursor vous permet de relire le gestionnaire d’inscription, de créer le déclencheur Brew correspondant et de vérifier l’e-mail au même endroit. Confiez à une personne la responsabilité de publier la séquence et de valider les envois réels.

## Connectez Brew

Ajoutez ce serveur dans les paramètres MCP de Cursor ou dans le fichier `.cursor/mcp.json` de votre projet :

```json
{
  "mcpServers": {
    "brew": { "url": "https://brew.new/api/mcp" }
  }
}
```

Terminez la connexion OAuth de Brew et sélectionnez la marque voulue. Demandez à l’agent d’appeler `get_brew_capabilities`. Suivez le [guide de configuration des clients](https://docs.brew.new/api-reference/mcp/connect-your-client) si votre client utilise un autre format de configuration. Ne mettez aucune clé API dans la conversation ni dans le dépôt.

## Définissez séparément l’inscription et l’éligibilité aux rappels

Demandez à Cursor de trouver le code qui enregistre un nouveau compte en base. Décidez de ce qui compte comme une activation, par exemple la création d’un premier projet. Ce tutoriel laisse les vérifications d’éligibilité dans l’application et utilise deux déclencheurs distincts :

- Un déclencheur d’inscription, pour l’e-mail de bienvenue immédiat.
- Un déclencheur de rappel éligible, que votre application n’actionne qu’après avoir vérifié l’état d’activation actuel.

Utilisez `save_trigger` pour définir chaque payload, y compris le champ email obligatoire, de type chaîne. Enregistrez les identifiants de déclencheur réellement renvoyés. Un nom d’affichage comme `user_signed_up` ne remplace pas l’identifiant d’API.

## Créez et relisez les e-mails

Voici un premier brief utile :

```text
Create a welcome email for a new account.
One action: create a first project at https://app.example.com/projects/new.
Use the brand already selected in Brew. Do not invent statistics or testimonials.
Create a separate setup-reminder email for recipients our app confirms have not activated.
Leave both automations as drafts for review.
```

L’agent peut utiliser `create_email`, `edit_email` et `save_automation`. Ouvrez les résultats dans Brew et vérifiez la mise en page, les textes, les liens et le domaine d’envoi. Utilisez la [syntaxe des balises de fusion](https://docs.brew.new/create-emails/merge-tags) documentée, avec une valeur par défaut testée pour un nom manquant.

Ne placez pas un filtre `activated is false` sur un chemin linéaire avant une relance `activated is true` : un filtre non satisfait arrête toutes les étapes qui en descendent. Les champs de l’événement comme `payload.activated` restent figés après une attente. Plutôt que cette méthode, où l’application planifie les rappels, vous pouvez définir et synchroniser un champ de contact booléen, puis vérifier `contact.activated` après chaque attente concernée. Cette condition lit le contact Brew actuel, pas la base de données de votre application. Consultez le [guide de la séquence d’essai](/fr/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Branchez le backend

Récupérez le contrat de chaque déclencheur avec `get_trigger_contract`, ou générez les contrats avec la [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Actionnez le déclencheur d’inscription une fois la transaction de création du compte validée.

Cet exemple shell suppose que `BREW_SIGNUP_TRIGGER_ID` contient l’identifiant renvoyé à la création du déclencheur, et que son schéma déclare `firstName` :

```bash
curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_SIGNUP_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: signup-example-account-123" \
  -d '{"payload":{"email":"alex@example.com","firstName":"Alex"}}'
```

Utilisez une clé stable par événement d’inscription, conservez-la pour les nouvelles tentatives et examinez les réponses en échec. Suivez le [contrat d’idempotence de l’API](https://docs.brew.new/api-reference/api/idempotency).

Quand un rappel arrive à échéance, votre application lit l’état actuel du compte. Si l’utilisateur est activé, supprimé ou inéligible pour une autre raison, elle n’actionne pas le déclencheur de rappel. Sinon, elle envoie un nouvel événement avec les données actuelles. La mise à jour d’un champ de contact ne suffit pas, à elle seule, à annuler l’exécution d’origine.

## Testez avant de publier

Utilisez `test_automation` avec des destinataires maîtrisés. Vérifiez le [comportement actuel des tests](https://docs.brew.new/create-emails/build-an-automation) et examinez l’historique des exécutions. Testez aussi le planificateur de l’application :

1. Un nouveau compte reçoit l’e-mail de bienvenue une seule fois.
2. Un compte inactif produit un seul événement de rappel éligible.
3. Un compte activé avant la vérification planifiée ne produit aucun événement de rappel.
4. Une nouvelle tentative ne crée pas d’envoi supplémentaire.
5. Des champs manquants ou non valides produisent une erreur que votre backend enregistre et traite.

Vérifiez l’usage d’envoi du domaine et les exigences de consentement. Publiez ensuite explicitement avec `save_automation` et `published: true`. Une automatisation publiée peut s’exécuter sur des événements réels.

Pour concevoir la séquence dans son ensemble, consultez notre [guide de la séquence de bienvenue](/fr/blog/welcome-email-sequence). Pour choisir l’interface qu’utilise votre backend, lisez [MCP ou REST](/fr/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).