Séquences d'emails IA

La plupart des apps SaaS envoient trois emails. Un email de bienvenue, une réinitialisation de mot de passe, et peut-être un reçu de paiement. Ça couvre environ 10% du cycle de vie.

Les 90% restants, c'est le silence. Un utilisateur s'inscrit, explore pendant un jour, et ne revient jamais. Personne ne fait de suivi. Personne n'explique ce que le produit fait vraiment. Personne n'envoie une relance quand l'essai est sur le point d'expirer. L'utilisateur churn avant d'avoir jamais atteint la partie de l'app qui l'aurait fait rester.

Voilà l'écart : les flux d'emails automatisés représentent environ 2% du volume total d'emails mais génèrent 37% des revenus par email. Les emails que la plupart des fondateurs sautent sont ceux qui génèrent la plupart de l'argent.

Cet article présente un système qui construit tous ces emails d'un coup. Une commande. Six agents IA en parallèle. Résultat : 17 templates d'emails, 6 fonctions de tâches de fond, des événements déclencheurs câblés, et du code vérifié par types prêt à tourner en local.

Les 6 séquences que la plupart des apps SaaS manquent

Un système d'emails de cycle de vie couvre six étapes. Chacune cible un moment différent dans le parcours de l'utilisateur.

Bienvenue est la séquence à plus haute valeur. Les premiers emails de bienvenue atteignent des taux d'ouverture de 55 à 70% en moyenne. Les 10% de SaaS les plus performants atteignent 75%+. C'est la meilleure attention que tu obtiendras jamais d'un utilisateur. Quatre emails sur les sept premiers jours, chacun le guidant plus près du moment où ton produit fait tilt.

Relance d'activation attrape le plus grand décrochage. Quelqu'un termine l'onboarding, voit le tableau de bord, et part. Un email 48 heures plus tard avec une action spécifique à essayer en ramène une partie.

Formation aux fonctionnalités prévient un autre type de churn. L'utilisateur est actif mais n'utilise qu'une fonctionnalité. Trois emails sur deux semaines, chacun mettant en avant une fonctionnalité qu'il n'a pas touchée. Les campagnes segmentées comme celle-ci génèrent jusqu'à 760% de revenus en plus que les envois en masse.

Incitation à l'upgrade se déclenche quand l'utilisateur atteint une vraie limite, pas sur un timer. Il a essayé de faire quelque chose que le plan gratuit n'autorise pas. C'est le moment où il comprend la valeur. Trois emails sur cinq jours : ce qui s'est passé, ce que le plan payant inclut, et une offre.

Prévention du churn tourne sur un cron job quotidien. Chaque matin à 9h, il interroge la base de données pour les utilisateurs qui ne se sont pas connectés depuis 7 jours. Trois emails étalés sur les 30 jours suivants. Chacun utilise un angle différent : "voici ce que tu rates", "tes données sont toujours là", et "dis-nous ce qui s'est mal passé."

Win-Back démarre quand Stripe envoie un webhook d'annulation. Trois emails sur 30 jours. Le premier reconnaît l'annulation. Le second met en avant ce qui s'est amélioré depuis leur départ. Le troisième fait une offre. La messagerie cadrée sur la perte (ce que tu abandonnes) convertit 21 à 32% mieux que le cadrage positif (ce que tu gagneras).

Une étude de 38 entreprises SaaS a trouvé que seulement 2 couvraient toutes les étapes du cycle de vie. La plupart s'arrêtent à la bienvenue et à la facturation. Cet écart, c'est là que ce système s'insère.

Pourquoi la plupart des outils d'emails n'aident pas

L'approche standard : ouvre ta plateforme d'emails, choisis un template, écris la copie, règle un délai de 3 jours, répète.

Trois problèmes.

Des timers par lots, pas du comportement. La plupart des outils planifient les emails sur des délais fixes. "Envoyer l'email 2 trois jours après l'email 1." Ça ignore ce que l'utilisateur a réellement fait. Un utilisateur qui a activé le jour 1 ne devrait pas recevoir la même relance que quelqu'un qui ne s'est jamais reconnecté. Les emails déclenchés (envoyés en fonction de ce qu'un utilisateur fait) obtiennent 76% de taux d'ouverture plus élevés et 152% de taux de clics plus élevés que les envois planifiés.

Des templates HTML qui tuent les clics. Les emails HTML riches avec une mise en forme lourde, des images, et des grilles de mise en page paraissent professionnels mais sous-performent. Les emails en texte brut obtiennent 42% de clics en plus. Les clients email qui comptent (Gmail, Apple Mail) gèrent bien le texte brut. Le HTML lourd déclenche les filtres anti-spam et s'affiche mal sur la moitié des appareils que tes utilisateurs portent.

Pas de connexion à ton app. Les plateformes d'emails externes ne connaissent pas ta base de données. Elles ne peuvent pas vérifier si un utilisateur a déjà activé avant d'envoyer la relance d'activation. Elles ne peuvent pas sauter l'email d'upgrade pour quelqu'un qui a upgradé hier. Le système d'emails et le produit vivent dans des mondes séparés.

Le système : une commande, deux phases

Le pipeline est une commande slash Claude Code : /emails. Elle lit ton produit, conçoit les séquences, et construit tout.

.claude/
  commands/
    emails.md              # La définition de la commande
  skills/
    email-sequence/        # Frameworks de conception de séquences
    react-email/           # Règles de construction de templates
webapp/
  emails/                  # Templates React Email (sortie)
  lib/inngest/functions/   # Fonctions de tâches de fond (sortie)
  lib/emails/send.ts       # Utilitaire d'envoi (sortie)

Phase 1 (Conception) : Un agent lit tes docs produit, les parcours utilisateur, la voix de marque, et les prix. Il conçoit toutes les 6 séquences avec des lignes d'objet spécifiques, le timing, et les objectifs pour chaque email. Puis il s'arrête et présente le plan. Rien n'est construit tant que tu n'as pas approuvé.

Phase 2 (Construction) : Six agents construisent en parallèle. Un par type de séquence. Chaque agent écrit des templates React Email (des mises en page d'emails construites avec des composants React) et des fonctions Inngest (des tâches de fond qui gèrent le timing, les tentatives, et les vérifications d'état). Un agent de base tourne en premier pour créer la mise en page partagée et l'utilitaire d'envoi. Ensuite cinq agents construisent leurs séquences en même temps.

Phase 1 : lire le produit, concevoir les séquences, attendre l'approbation

L'agent de conception lit tout ce dont il a besoin pour écrire des emails qui sonnent comme ton produit, pas comme un template.

Contexte produit qu'il lit :

• Vue d'ensemble du produit (ce que l'app fait, les niveaux de tarification)
• Parcours utilisateur (qui s'inscrit, ce dont ils se soucient)
• Directives de marque (voix, ton, nom du produit)
• Carte des fonctionnalités (ce qu'on met en avant dans les emails de formation)
• Flux d'authentification (comment fonctionne l'inscription, pour que la séquence de bienvenue corresponde)
• Configuration de facturation (niveaux de tarification, déclencheurs d'upgrade)
• Couleurs de marque (pour que les templates d'emails correspondent à l'app)

À partir de ça, il construit un Email Brief : le nom du produit, le "moment aha" (l'action spécifique où le produit fait tilt pour un utilisateur), le modèle de tarification, les fonctionnalités principales à éduquer, et les déclencheurs d'upgrade.

Puis il conçoit les 17 emails. Pour chacun : ligne d'objet, objectif, timing, et l'angle de la copie.

Les lignes d'objet suivent la recherche. Les lignes d'objet courtes (2 à 4 mots) atteignent des taux d'ouverture moyens de 46% dans une étude de 5,5 millions d'emails. Le système garde chaque objet sous 50 caractères pour la troncature dans les boîtes de réception mobiles.

Le plan complet te parvient avant qu'un seul template soit écrit. Tu peux couper des séquences, changer le timing, réécrire les lignes d'objet, ou supprimer des emails entièrement. La phase de construction utilise ton plan approuvé comme spec.

Phase 2 : six agents construisent en parallèle

Après approbation, six sous-agents démarrent en même temps. Chacun reçoit l'Email Brief, le plan approuvé, les couleurs de marque, et les compétences dont il a besoin.

Agent 0 : mise en page de base et utilitaire d'envoi

Tourne en premier. Crée deux fichiers partagés que tous les autres agents utilisent.

La mise en page de base est un composant React Email (un template d'email réutilisable construit avec React). Il inclut le logo de marque, le conteneur, le pied de page avec le lien de désinscription, et les couleurs de marque converties depuis le CSS de l'app.

L'utilitaire d'envoi encapsule Resend (le service de livraison d'emails). Il prend un composant React Email, le convertit en HTML et en texte brut, et l'envoie. Chaque séquence utilise cette même fonction.

Agents 1 à 5 : un par séquence

Chaque agent écrit deux choses : les templates d'emails et la fonction de tâche de fond qui orchestre la séquence.

Les templates sont des composants React. Chaque email est un fichier .tsx. Des props typées pour que la ligne d'objet, le nom de l'utilisateur, et toutes les données dynamiques soient toutes validées avant que l'email parte.

Les fonctions de tâches de fond utilisent Inngest (un moteur de tâches de fond qui gère la planification, les tentatives, et les workflows basés sur des événements). Chaque fonction définit quand la séquence démarre, combien de temps attendre entre les emails, et quelles vérifications faire avant d'envoyer le suivant.

La structure de fichiers après que les six agents ont terminé :

webapp/emails/
  _components/
    base-layout.tsx                  # Mise en page partagée de marque
  welcome/
    welcome-1-getting-started.tsx    # 4 templates
    welcome-2-activation-nudge.tsx
    welcome-3-feature-education.tsx
    welcome-4-check-in.tsx
  activation/
    activation-nudge.tsx             # 1 template
  education/
    education-1-feature-a.tsx        # 3 templates
    education-2-feature-b.tsx
    education-3-feature-c.tsx
  upgrade/
    upgrade-1-limit-hit.tsx          # 3 templates
    upgrade-2-value.tsx
    upgrade-3-offer.tsx
  churn/
    churn-1-miss-you.tsx             # 3 templates
    churn-2-data-waiting.tsx
    churn-3-feedback.tsx
  winback/
    winback-1-sorry.tsx              # 3 templates
    winback-2-improvements.tsx
    winback-3-offer.tsx

webapp/lib/inngest/functions/emails/
  welcome-sequence.ts
  activation-nudge.ts
  feature-education.ts
  upgrade-prompt.ts
  churn-prevention.ts
  winback-sequence.ts

17 templates. 6 fonctions. Une mise en page partagée. Un utilitaire d'envoi.

Embranchement comportemental : réagir à ce que font les utilisateurs, pas à quand ils se sont inscrits

C'est la partie qui sépare le système d'un drip basé sur un timer.

Inngest supporte une fonctionnalité appelée step.waitForEvent. En termes simples, ça met la séquence en pause et attend qu'une chose spécifique se produise avant de continuer. Si cette chose ne se produit pas dans une limite de temps, la séquence prend un chemin différent.

Voilà à quoi ça ressemble en pratique.

Un utilisateur s'inscrit. La séquence de bienvenue démarre. L'email 1 part immédiatement. Puis la fonction appelle step.waitForEvent et attend jusqu'à 48 heures un événement user.activated (ce qui signifie que l'utilisateur a complété l'action centrale du produit).

Si l'événement arrive, la séquence saute la relance d'activation et passe à la formation aux fonctionnalités. L'utilisateur a déjà trouvé la valeur. Le relancer serait du bruit.

Si l'événement n'arrive pas en 48 heures, la relance d'activation se déclenche. Un email centré sur l'action spécifique que l'utilisateur n'a pas encore prise.

Cet embranchement se produit dans chaque séquence. La demande d'upgrade vérifie si l'utilisateur a upgradé entre les emails. La séquence de prévention du churn vérifie si l'utilisateur s'est reconnecté. La séquence win-back vérifie si l'utilisateur s'est réabonné.

Entre chaque appel step.sleep() (la pause entre les emails), la fonction crée une nouvelle connexion à la base de données et vérifie l'état actuel de l'utilisateur. Si l'utilisateur a déjà converti, la séquence s'arrête. Personne ne reçoit un email d'upgrade le lendemain de son upgrade.

C'est à quoi ressemblent les emails déclenchés en code. Pas un constructeur de flux visuel. Une fonction qui dort, vérifie l'état, s'embranifié, et envoie.

Le câblage des déclencheurs

Les séquences ne démarrent pas seules. Quelque chose dans l'app doit déclencher l'événement.

Le système trouve ces emplacements dans ta base de code et câble les appels inngest.send(). L'inscription a déjà un callback d'auth. Stripe a déjà une route de webhook. La vérification de limite retourne déjà une réponse quand un utilisateur atteint son plafond. Chaque emplacement reçoit une ligne qui déclenche un événement avec l'ID de l'utilisateur, l'email, et les données pertinentes.

La prévention du churn est différente. Elle tourne sur un cron job quotidien, pas sur un événement. Chaque matin, la fonction Inngest interroge la base de données pour les utilisateurs qui n'ont pas été actifs depuis 7+ jours et envoie des événements individuels pour chacun. La séquence par utilisateur gère le reste.

Ce que les données disent

Les chiffres qui façonnent ce système viennent de la façon dont les emails fonctionnent réellement, pas de la théorie.

Une séquence d'onboarding de 7 emails (testée sur un vrai produit SaaS) a fait passer la conversion essai-payant de 12% à 22% et a réduit le churn mensuel de 8% à 4,8%. Ce sont les deux métriques qui se composent. Une hausse de 10 points de conversion plus une réduction de 3 points de churn change le calcul sur chaque euro de marketing que tu dépenses.

Le texte brut gagne en taux de clics parce que ça ressemble à un message d'une personne, pas à une promotion. Le système rend à la fois une version HTML et une version texte brut de chaque email via la fonction render() de React Email. Les destinataires dont les clients email préfèrent le texte brut reçoivent automatiquement la version simple.

Les courtes lignes d'objet fonctionnent parce que les boîtes de réception mobiles tronquent. Une ligne d'objet de 2 à 4 mots est entièrement visible sur chaque appareil. Le système garde chaque objet sous 50 caractères.

Les déclencheurs comportementaux surpassent les timers fixes parce que la pertinence compte plus que le timing. Envoyer le bon email après la bonne action bat n'importe quel email le jour 3 quelle que soit l'action passée.

Contrôles de qualité

Après que les six agents ont terminé, le système lance le vérificateur de types TypeScript sur l'ensemble du projet :

cd webapp && npx tsc --noEmit

Zéro erreur de type. Chaque template a des props typées. Chaque fonction Inngest a des payloads d'événements typés. Chaque appel inngest.send() correspond à la forme d'événement attendue.

Puis il fournit des instructions de test en local :

# Terminal 1 : démarrer le serveur de développement
npm run dev

# Terminal 2 : démarrer le serveur de développement Inngest
npm run dev:inngest

# Ouvrir http://localhost:8288
# Envoyer un événement de test : app/user.signed-up
# Regarder la séquence de bienvenue s'exécuter étape par étape

Le serveur de développement Inngest montre chaque exécution de fonction en temps réel. Tu peux voir chaque étape s'exécuter, chaque compte à rebours de sleep, chaque email qui partirait. Rien ne va vers de vraies boîtes de réception en développement local.

Règles pour construire ça toi-même

Le pattern fonctionne avec n'importe quel fournisseur d'emails, n'importe quel moteur de tâches de fond, n'importe quel framework. Voilà ce qui fait que ça marche.

Lis ton produit avant de concevoir les emails. L'erreur la plus courante, c'est d'écrire des emails qui sonnent générique parce que la personne qui les écrit n'a pas compris le produit en profondeur. Donne au système tes docs produit, les parcours utilisateur, et la voix de marque avant qu'il touche un template.

Conçois toutes les séquences avant d'en construire une seule. Présente le plan complet. Obtiens l'approbation. Puis construis. Changer une ligne d'objet dans un plan est gratuit. La changer dans un template construit signifie re-rendre, re-tester, et re-déployer.

Vérifie l'état utilisateur entre chaque email. Ne suppose jamais que l'utilisateur est toujours dans le même état qu'au démarrage de la séquence. Un step.sleep("3d") (attendre 3 jours) signifie trois jours de changements potentiels. Interroge la base de données avant d'envoyer.

Une action par email. Pas deux boutons. Pas trois liens. Une seule prochaine étape claire. Les emails avec un seul appel à l'action obtiennent des taux de clics plus élevés parce qu'il n'y a pas de décision à prendre.

Construis le texte brut en même temps que le HTML. Ne traite pas le texte brut comme une réflexion après coup. Rends les deux versions depuis le même template. Les emails en texte brut obtiennent 42% de clics en plus dans les tests en face-à-face.

Câble les déclencheurs aux événements existants, pas à de nouveaux. L'inscription se produit déjà. L'annulation se produit déjà. Les limites atteintes se produisent déjà. Le système d'emails se branche sur les événements que ton app déclenche déjà. Zéro nouvelle infrastructure.

Au-delà des emails

Le pattern d'agents en parallèle (un agent de base construit l'infrastructure partagée, puis des agents spécialisés construisent par-dessus en même temps) fonctionne pour plus que les emails.

Systèmes de notifications. Même structure : conçois tous les types de notifications, construis les templates, câble les déclencheurs. Les notifications push, les alertes in-app, et les SMS suivent tous les mêmes étapes du cycle de vie.

Flux d'onboarding. Un agent lit le contexte produit et conçoit le flux. Des agents séparés construisent chaque étape (modal de bienvenue, visite des fonctionnalités, checklist, états vides). L'embranchement comportemental décide quelles étapes montrer en fonction de ce que l'utilisateur a déjà fait.

Documentation. Un agent construit la structure et les composants partagés. Des agents spécialisés écrivent des sections individuelles en parallèle. Même forme. Même pattern de coordination.

La même idée centrale à chaque fois. Lis d'abord le contexte produit. Conçois avant de construire. Construis en parallèle avec une infrastructure partagée. Vérifie l'état avant d'agir. Vérifie les types à la fin.