Biz SMTP Form Autoresponder — Auto-email après qu'un lead a rempli un formulaire
Ce skill transforme le formulaire d'inscription sur une page de vente (nom/téléphone/e-mail selon les standards du trafic vietnamien) en 2 e-mails automatiques dès la soumission : (A) un e-mail de bienvenue pour le lead, (B) une notification pour le propriétaire. Les e-mails sont rédigés sur mesure pour chaque offre en fonction du contexte disponible dans le pipeline biz-* (pas de "Merci de vous être inscrit, nous vous contacterons bientôt" générique — ce serait du copy qui tue les leads).
Philosophie : L'e-mail de répondeur automatique est un moment crucial. Le lead vient d'appuyer sur le bouton de soumission = il est au pic de son intention. L'e-mail doit arriver dans les 30 secondes pour (1) confirmer que sa soumission a bien été prise en compte, (2) délivrer ce qui a été promis dans le CTA (lead magnet / réservation / lien de paiement), (3) définir clairement les prochaines étapes. Un bon e-mail de répondeur automatique transforme 20 à 40 % des leads froids en leads chauds. Un e-mail générique = le lead bloque l'expéditeur ou oublie le nom de la marque en 24 heures.
Pourquoi SMTP (et non un seul fournisseur) : SMTP est un standard ouvert — l'utilisateur peut choisir le fournisseur qui correspond à son budget, sa région et ses exigences de conformité. Gmail SMTP est gratuit (500/jour), suffisant pour une page de vente avec moins de 50 leads/jour ; Resend SMTP offre 3 000/mois ; SendGrid, 100/jour avec un abonnement gratuit à vie ; Brevo (populaire au Vietnam), 300/jour gratuit ; les hébergeurs vietnamiens (Mắt Bão, PA, Inet) incluent souvent un serveur SMTP. Le code utilise
nodemailer— pour changer de fournisseur, il suffit de modifier 4 variables d'environnement, pas de code à changer. Évite le verrouillage technologique.
Résultat : patch de code + 2 brouillons d'e-mail HTML responsifs + liste de variables d'environnement + plan de test. Le skill n'envoie PAS d'e-mail de test — l'utilisateur doit confirmer les brouillons au préalable, car le lien du lead magnet, la voix de la marque et le texte d'urgence sont des actifs de l'utilisateur.
Quand utiliser ce skill
- L'utilisateur vient de déployer une page de vente (via
/biz-deploy-vercel) et le formulaire soumet dans le vide. - L'utilisateur a une page de vente existante (Next.js, Vite ou HTML statique sur Vercel) et souhaite intégrer un répondeur automatique par e-mail.
- L'utilisateur construit une nouvelle page et souhaite l'intégration e-mail dès le début, avant le déploiement.
- L'utilisateur a déjà Gmail/Google Workspace et souhaite utiliser le SMTP gratuit plutôt que de créer un nouveau compte fournisseur.
- L'utilisateur a un hébergement vietnamien (Mắt Bão, PA, Inet) avec un serveur SMTP intégré.
À NE PAS utiliser ce skill quand :
- L'utilisateur souhaite des campagnes d'e-mail marketing (newsletter, campagne de nurturing sur 7 à 30 jours) → Mailchimp/ConvertKit/MailerLite sont plus adaptés.
- L'utilisateur souhaite un répondeur automatique par SMS/Zalo OA → cas d'usage différent.
- L'utilisateur souhaite une intégration CRM (leads dans Hubspot/Pipedrive/Notion DB) → autre skill.
- L'utilisateur a besoin de prospection par e-mail en masse → Instantly/Smartlead, pas de transactionnel.
Workflow général (7 phases)
Phase 0 : DÉTECTION DU STACK (Next.js App / Pages / Vite / HTML statique)
↓
Phase 1 : CHOIX DU FOURNISSEUR SMTP (Gmail / Resend SMTP / SendGrid / Mailgun / Brevo / Zoho / Personnalisé)
↓
Phase 2 : COLLECTE DU CONTEXTE (offer.json + conversion-copy.md, ou lecture de l'application Next.js app/page.tsx, ou lecture du HTML déployé)
↓
Phase 3 : CHOIX DU MODÈLE D'E-MAIL (lead magnet / réservation / paiement / nurturing)
↓
Phase 4 : RÉDACTION DE 2 E-MAILS (répondeur automatique + notification propriétaire) — affichage à l'utilisateur
↓
Phase 5 : RÉVISION ET ÉDITION PAR L'UTILISATEUR — itérer jusqu'à validation
↓
Phase 6 : INTÉGRATION DU CODE (installation de nodemailer + route API + liaison formulaire + variables d'environnement)
↓
Phase 7 : CONFIGURATION DU FOURNISSEUR + PLAN DE TEST — instructions pour récupérer les identifiants SMTP, vérifier le domaine (si nécessaire), tester en direct
Chaque phase s'arrête pour la confirmation de l'utilisateur — particulièrement les phases 1 (choix du fournisseur), 4 et 5 (contenu des e-mails), et 7 (DNS du fournisseur) car ce sont des actifs de marque de l'utilisateur. La génération de code en phase 6 est plus proactive.
Phase 0 — Détection du Stack
Lire le fichier racine du projet pour déterminer le stack. Le stack détermine : où placer la route API, la syntaxe d'import de nodemailer, le type de liaison du formulaire (fetch ou form action).
| Fichier détecté | Stack | Chemin de la route API | Liaison du formulaire |
|---|---|---|---|
next.config.js/mjs/ts + dossier app/ | Next.js App Router | app/api/submit/route.ts | composant client fetch('/api/submit') |
next.config.js/mjs/ts + dossier pages/ | Next.js Pages Router | pages/api/submit.ts | composant client fetch('/api/submit') |
vite.config.js/ts | Vite (React/Vue/Svelte) | api/submit.js (fonction Vercel) | composant client fetch('/api/submit') |
package.json sans framework, avec index.html | HTML statique | api/submit.js (fonction Vercel) | <script> en ligne avec fetch('/api/submit') |
| Pas de projet local, seulement une URL | Page déjà déployée | L'utilisateur doit d'abord cloner le dépôt ou indiquer le chemin du dépôt | — |
Lire davantage pour déterminer les champs du formulaire :
- Chercher
<form>dans le code → lister les<input name="...">existants - Valeurs par défaut (selon la mémoire du projet) :
name,phone,email. Certaines pages ajoutent :company,message,budget,utm_source. - Si le formulaire n'existe pas → le skill créera un nouveau formulaire avec 3 champs minimum (nom/téléphone/e-mail) dans la phase 6.
Important : Si l'utilisateur n'a pas de projet local (seulement une URL déployée), s'arrêter et demander : "Avez-vous un dépôt local pour que je puisse intégrer le code ? J'ai besoin de modifier les fichiers source. Si vous n'avez qu'une URL, veuillez cloner le dépôt et m'indiquer le chemin." Impossible d'intégrer uniquement via une URL.
Phase 1 — Choix du Fournisseur SMTP
Demander à l'utilisateur de choisir parmi 7 fournisseurs. Chaque fournisseur a une configuration SMTP différente (hôte/port/auth), et le skill remplit automatiquement le modèle de variables d'environnement en fonction du choix.
| # | Fournisseur | Niveau gratuit | Quand l'utiliser | Hôte SMTP | Port | Notes |
|---|---|---|---|---|---|---|
| 1 | Gmail / Google Workspace | 500/jour | L'utilisateur a déjà Gmail/Workspace, trafic faible | smtp.gmail.com | 587 (STARTTLS) | Mot de passe d'application obligatoire (2FA), NE PAS utiliser le mot de passe principal |
| 2 | Resend SMTP | 3 000/mois | Bonne délivrabilité + logs, OK pour configurer DNS | smtp.resend.com | 587 | Utilisateur = resend, Mot de passe = clé API. Nécessite la vérification du domaine pour envoyer depuis un @marque.vn personnalisé |
| 3 | SendGrid SMTP | 100/jour, gratuit à vie | Stack déjà familier avec SendGrid, besoin de webhook | smtp.sendgrid.net | 587 | Utilisateur = apikey littéral, Mot de passe = clé API |
| 4 | Mailgun SMTP | 100/jour × 3 mois | Région EU/US, convivial pour les développeurs | smtp.mailgun.org (US) ou smtp.eu.mailgun.org (UE) | 587 | Utilisateur/mot de passe depuis les paramètres du domaine Mailgun |
| 5 | Brevo (Sendinblue) SMTP | 300/jour, gratuit à vie | Populaire au Vietnam, niveau gratuit le plus élevé, support Vietnam | smtp-relay.brevo.com | 587 | Utilisateur = e-mail de connexion, Mot de passe = clé SMTP (différente de la clé API) |
| 6 | Zoho Mail SMTP | 5/jour gratuit, 1 $/utilisateur/mois | L'utilisateur utilise déjà Zoho Workspace | smtp.zoho.com | 587 | Nécessite un mot de passe d'application si 2FA activé |
| 7 | SMTP personnalisé | Dépend de l'hébergement | Hébergement Vietnam (Mắt Bão/PA/Inet/Nhân Hòa) inclut SMTP, ou utilisation de Postfix auto-hébergé | L'utilisateur fournit | L'utilisateur fournit | L'utilisateur colle l'hôte/port/utilisateur/mot de passe complets |
Recommandation par défaut selon le type d'offre :
- Page de vente <50 leads/jour, utilisateur avec Gmail → Gmail SMTP (zéro coût, configuration en 5 minutes).
- Page de vente >50 leads/jour ou besoin de délivrabilité professionnelle → Brevo (gratuit 300/jour, bonne délivrabilité pour le Vietnam) ou Resend SMTP (3 000/mois, bons logs).
- Utilisateur veut une solution anti-migration, pouvant être auto-hébergée plus tard → SMTP personnalisé dès le début.
Format de la question à l'utilisateur :
Quel fournisseur SMTP souhaitez-vous utiliser pour envoyer les e-mails automatiques ?
1. Gmail / Google Workspace (gratuit 500/jour, le plus simple si vous avez déjà Gmail)
2. Resend SMTP (gratuit 3 000/mois, haute délivrabilité, nécessite vérification du domaine)
3. SendGrid SMTP (gratuit 100/jour à vie, si l'API SendGrid vous est familière)
4. Mailgun SMTP (gratuit 100/jour × 3 mois)
5. Brevo / Sendinblue SMTP (gratuit 300/jour, populaire au Vietnam)
6. Zoho Mail SMTP (si vous utilisez déjà Zoho Workspace)
7. SMTP personnalisé (l'hébergement Vietnam que vous utilisez en a déjà un / auto-hébergé)
Si vous n'avez pas encore de compte, je vous suggère [Gmail si le trafic est faible / Brevo si vous avez besoin d'une haute délivrabilité]. Quel numéro choisissez-vous ?
Après le choix de l'utilisateur → le sauvegarder pour l'injecter dans le modèle de variables d'environnement en phase 6 et pour fournir les instructions de récupération des identifiants en phase 7.
⚠️ Important — sécurité : Les identifiants SMTP (notamment le mot de passe d'application Gmail) ont l'autorisation d'envoyer des e-mails depuis le compte de l'utilisateur. Ne jamais les coder en dur dans le code source. Toujours utiliser des variables d'environnement. Avertir l'utilisateur de les révoquer immédiatement en cas de commit accidentel.
Phase 2 — Collecte du Contexte
Objectif : comprendre l'offre suffisamment en profondeur pour rédiger un e-mail non générique. 3 modes d'entrée :
Mode A — Artefacts du pipeline disponibles (le plus riche)
L'utilisateur vient d'exécuter /biz-offer-alex-hormozi et/ou ui-ux-pro-max → fichiers présents :
output/<case-slug>/offer.json— segment, résultat idéal, mécanisme, pile de bonus, garantie, tarification (source de vérité PRINCIPALE)output/<case-slug>/conversion-copy.md— bloc héro prêt à coller (titre, sous-titre, texte du CTA)output/<case-slug>/landing-page/app/page.tsx— page de vente Next.js actuelle déjà construite (à lire pour connaître les sections et les champs de formulaire utilisés)
⚠️ Mise à jour 2026-05-14 : L'ancien pipeline avait
layout.json+copy.json(debiz-sales-page-layoutqui est OBSOLÈTE) — la nouvelle procédure IGNORE ces 2 fichiers. Seulsoffer.json+ la lecture de page.tsx sont nécessaires pour le contexte.
Lire les 3 sources ci-dessus. En extraire pour l'e-mail :
- Segment + résultat idéal → personnaliser la ligne d'objet ("[Nom], le parcours de 8 semaines AI Agent est prêt" au lieu de "Bienvenue")
- Nom du mécanisme → renforcer dans le corps du message ("Le système PROMPT framework que vous allez bientôt apprendre…")
- Pile de bonus → lister dans l'e-mail (si l'offre gratuite/low-ticket a des bonus à livrer immédiatement)
- Texte de la garantie → citer textuellement dans l'e-mail pour réduire l'anxiété
- Texte du CTA → refléter dans le CTA final de l'e-mail
Mode B — Page de vente disponible mais pas de fichier JSON
L'utilisateur a du HTML déployé mais n'a pas exécuté biz-offer/biz-sales-page. Le skill lit le HTML :
curl -s <URL>ou lit le fichierindex.htmllocal- Analyse le h1 du héros, le sous-titre, le texte du bouton CTA, le bloc de tarification, le bloc de garantie
- En déduit le type d'offre + le segment
Le mode B est suffisant dans 80 % des cas, mais l'e-mail est moins personnalisé que le mode A. Suggérer à l'utilisateur : "Vous pouvez exécuter /biz-offer-alex-hormozi pour obtenir un offer.json, puis revenir ici ; l'e-mail sera de meilleure qualité. Ou continuer avec le mode B."
Mode C — Rien du tout
L'utilisateur n'a qu'un formulaire HTML, pas de contexte. Le skill doit interviewer avec 5 questions rapides :
- Quel est votre produit/service ? (1 phrase)
- Après que l'utilisateur a rempli le formulaire, que souhaitez-vous lui envoyer ? (PDF à télécharger / lien de réservation / lien de paiement / juste une confirmation et vous rappellerez)
- Nom de la marque + nom de l'expéditeur (qui apparaîtra dans "De :")
- L'e-mail auquel vous souhaitez recevoir la notification de nouveau lead
- Le domaine que vous possédez pour vérifier SPF/DKIM (si vous choisissez Resend/SendGrid/Mailgun/Brevo — Gmail, pas nécessaire)
Phase 3 — Choix du Modèle d'E-mail
Modèle à 2 déclencheurs (pour les offres avec flux de paiement) : Pour les formations low-ticket / produits numériques avec paiement en ligne, il y a 2 déclencheurs différents à des moments différents, envoyant 2 e-mails différents. Ne pas les fusionner en un seul e-mail.
Lead remplit le formulaire sur la page de vente
↓
[Déclencheur A — /api/submit]
↓
E-mail P3 (RAPPEL DE PAIEMENT, léger)
↓
Lead termine le paiement → webhook du fournisseur de paiement
↓
[Déclencheur B — /api/payment-webhook]
↓
E-mail P5 (INTÉGRATION POST-ACHAT, complet)
Règle de contenu :
- P3 (pré-paiement) : seulement le lien de paiement + garantie courte + urgence. NE PAS lister les livrables complets / pile de bonus — le lead ne les a pas encore "gagnés", les lister réduit l'urgence du paiement.
- P5 (post-paiement) : livrer TOUT — lien d'accès, livrables complets, pile de bonus, lien de groupe, horaires de bureau, 1 question de suivi pour personnaliser. C'est le moment crucial.
(Lire la mémoire feedback_email-autoresponder-2-stage-flow pour la justification détaillée.)
À partir du contexte de la phase 2, choisir le modèle approprié. Lire references/email-formulas.md pour les modèles détaillés en vietnamien.
| Modèle | Déclencheur | Quand l'utiliser | Indice pour l'objet |
|---|---|---|---|
| P1 — Livraison du Lead Magnet | Soumission du formulaire | L'offre = téléchargement PDF/e-book/modèle/fichier swipe/checklist gratuit | "[Nom], le document [X] est prêt — ouvrez le fichier maintenant 👇" |
| P2 — Confirmation de Réservation | Soumission du formulaire | L'offre = rendez-vous d'appel/consultation/démo/session de stratégie gratuite | "[Nom], inscription au rendez-vous de conseil confirmée — prochaine étape à l'intérieur" |
| P3 — Rappel de Paiement | Soumission du formulaire (pas encore payé) | L'offre = produit low-ticket (199 000 - 3 000 000 VND), l'e-mail redirige vers le paiement | "[Nom], lien de paiement pour [Cours X] — prix réduit valable 24h ⏰" |
| P4 — Nurturing (Appel commercial à venir) | Soumission du formulaire | L'offre = coaching/agence high-ticket 5 000 000 - 50 000 000+ VND, l'équipe commerciale appellera dans les 24h | "[Nom], [Appelant] vous contactera dans les 24h — checklist de préparation à l'intérieur" |
| P5 — Intégration Post-Achat | Webhook de paiement | Le lead vient de terminer le paiement — livrer la valeur complète + 1 question de personnalisation | "🎉 Bienvenue [Nom] dans [Cours X] — débloquez maintenant" |
Règle de sélection du modèle :
- Offre = téléchargement gratuit/formation → P1 uniquement (1 déclencheur, 1 e-mail).
- Offre = appel de réservation gratuit → P2 uniquement (1 déclencheur, 1 e-mail).
- Offre = low-ticket avec paiement en ligne (Stripe/Momo/ZaloPay/Sepay) → P3 + P5 (2 déclencheurs, 2 e-mails).
- Offre = appel commercial high-ticket → P4 uniquement, suivi par l'équipe commerciale (l'intégration après la conclusion de l'affaire est un processus différent).
Le skill propose le modèle approprié avec la raison, demande à l'utilisateur de confirmer. Exemple : "D'après le offer.json, il s'agit d'un cours à 1 990 000 VND avec intégration de paiement. Je propose de configurer 2 e-mails : P3 (rappel de paiement après le formulaire) + P5 (intégration après le paiement + 1 question de personnalisation). Êtes-vous d'accord ou souhaitez-vous seulement l'e-mail P3 avant ?"
Phase 4 — Rédaction de 2 E-mails
Générer 2 e-mails en vietnamien pur (tutoiement "anh/chị"), HTML responsive pour mobile.
E-mail A — Répondeur automatique envoyé au lead
Structure en 6 blocs (lire references/email-formulas.md pour le texte spécifique à chaque modèle) :
- Ligne d'objet — personnalisée avec
{{name}}, moins de 50 caractères, avec 1 léger emoji à la fin si approprié à la voix de la marque (✉️ 👇 ✓), éviter les déclencheurs de spam ("GRATUIT", "$$$", "garantie" en majuscules). - Texte de prévisualisation — 1 phrase affichée sous l'objet dans la boîte de réception, expliquant la valeur de l'e-mail.
- Salutation — "Bonjour anh/chị {{name}}," — pas "Cher", pas "Bonjour cher client".
- Corps principal — selon le modèle choisi. Règles :
- Court (moins de 200 mots).
- Contient 1 lien/bouton CTA principal clair.
- Mentionner spécifiquement le nom de l'offre/mécanisme du contexte (pas "notre produit").
- Si modèle P3/P4 → avoir 1 rappel d'urgence + 1 réassurance (garantie).
- Signature — Nom de l'expéditeur + nom de la marque + 1 lien de contact (Zalo/Téléphone/Site Web).
- Pied de page — Adresse (obligatoire selon la loi anti-spam) + lien de désabonnement (nécessaire pour la conformité, même pour les e-mails transactionnels).
E-mail B — Notification envoyée au propriétaire
Structure en 4 blocs :
- Ligne d'objet — "[ALERTE] Nouveau lead depuis [Nom de la page] : {{name}}"
- Corps principal — Informations du lead : nom, téléphone, e-mail, message (si présent),
utm_source(si présent), horodatage précis. Formater en tableau. - Recommandation — "Suggestions : contactez dans les 2 heures pendant la peak intent. Le lead a reçu [nom du lead magnet / lien de réservation]." + 1 lien direct pour répondre ou appeler.
- Signature/Suivi — "L'e-mail de répondeur automatique a été envoyé à {{lead_email}} à {{time}}."
Phase 5 — Révision et Édition par l'Utilisateur
Règle absolue : ne pas envoyer sans approbation. Afficher 2 e-mails dans un format de brouillon clair, prêts à être copiés-collés dans un éditeur.
📧 Brouillon A — Répondeur automatique (envoyé au lead)
═══════════════════════════════════════
Objet : [Ligne d'objet]
Prévisualisation : [Texte de prévisualisation]
[Contenu complet de l'e-mail]
───────────────────────────────────────
📧 Brouillon B — Notification propriétaire (envoyé à [email protected])
═══════════════════════════════════════
Objet : [Ligne d'objet]
[Contenu complet de l'e-mail]
Demander :
Anh/chị vui lòng kiểm tra 2 bản nháp trên. Em cần OK trước khi wire code. Anh/chị muốn sửa gì không?
- Nội dung: thêm/bớt đoạn nào?
- Tông giọng: cần formal hơn / friendly hơn / thêm urgency?
- CTA: đổi link / button text?
- Footer: thêm địa chỉ / link unsubscribe?
- Gửi từ tên: "[Tên brand] <[email protected]>" hay "[Tên người] <[email protected]>"?
Itérer. Si l'utilisateur accepte → passer à la phase 6.
Phase 6 — Intégration du Code
Basé sur le stack détecté en phase 0 + le fournisseur SMTP de la phase 1 + le modèle d'e-mail de la phase 3 → le skill génère :
1. Installation du paquet
npm install nodemailer
# ou
pnpm add nodemailer
# ou
yarn add nodemailer
2. Fichier de configuration SMTP
Créer lib/mailer.ts (ou .js) :
import nodemailer from 'nodemailer';
export const transporter = nodemailer.createTransport({
host: process.env.SMTP_HOST,
port: parseInt(process.env.SMTP_PORT || '587'),
secure: false, // true pour le port 465
auth: {
user: process.env.SMTP_USER,
pass: process.env.SMTP_PASS,
},
});
3. Route API /api/submit
- Lire les données du formulaire :
{ name, phone, email, ... } - Valider les champs requis (nom, téléphone, e-mail)
- Appeler
transporter.sendMail()pour l'e-mail A (répondeur automatique) - Appeler
transporter.sendMail()pour l'e-mail B (notification propriétaire) - Sauvegarder le lead dans le stockage (optionnel, si besoin) — mémoire non implémentée, suggérer Supabase/Notion DB / Google Sheets comme prochaine étape
- Retourner la réponse :
{ success: true }
Important — gestion des erreurs :
- Si l'envoi échoue (SMTP refusé, timeout), retourner l'erreur → le frontend peut afficher "E-mail non envoyé, veuillez réessayer" mais accepter quand même le lead (perte de données minimale).
- Logger l'erreur mais ne pas bloquer l'inscription.
4. Variables d'environnement
Créer/modifier .env.local avec les valeurs (exemple pour Gmail) :
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
[email protected]
SMTP_PASS=xxxx xxxx xxxx xxxx # App Password Gmail
FROM_NAME=Nom de votre marque
[email protected]
[email protected]
5. Liaison du formulaire (Frontend)
Si le formulaire n'existe pas encore → générer un formulaire avec 3 champs (nom, téléphone, e-mail) + gestion de la soumission fetch('/api/submit'). Si le formulaire existe déjà → ajouter onSubmit ou modifier l'action du formulaire.
Phase 7 — Configuration du Fournisseur + Plan de Test
Instructions spécifiques à chaque fournisseur (phase 1) pour se connecter et sécuriser, envoyées dans un message séparé :
📋 Anh/chị cần hoàn tất các bước sau trước khi go-live:
[Fournisseur choisi — Gmail]
1. Activez 2FA sur votre compte Gmail : https://myaccount.google.com/signinoptions/two-step-verification
2. Générez un App Password : https://myaccount.google.com/apppasswords (sélectionner "Mail" + votre appareil)
3. Copiez le mot de passe généré (16 caractères) dans .env.local sous SMTP_PASS (pas votre mot de passe principal !)
[Si applicable — Resend / SendGrid / Mailgun / Brevo]
1. Connectez-vous à votre compte, accédez à la section SMTP/API
2. Créez une clé SMTP dédiée (ne pas utiliser une clé API personnelle)
3. Vérifiez votre domaine d'envoi (SPF + DKIM) pour envoyer depuis @votremark.vn
4. Limites de taux : [limite spécifique au fournisseur], ne pas dépasser / minute
📋 Plan de test :
1. Ouvrez la page d'accueil locale : http://localhost:3000
2. Remplissez le formulaire avec des données de test (votre e-mail)
3. Vérifiez la boîte de réception A : l'e-mail de répondeur automatique est-il arrivé ? (dans les 30 secondes)
4. Vérifiez la boîte de réception B : l'e-mail de notification propriétaire est-il arrivé ?
5. Testez : bouton de partage social, lien de désabonnement (ne pas désabonner les e-mails transactionnels, mais si commerce → se conformer à la loi)
6. Testez avec un e-mail inexistant : le système ne bloque pas l'inscription, seule l'envoi échoue — bon comportement ?
Après les tests, déployez sur Vercel :
```bash
vercel --prod
# Ajoutez les variables d'environnement sur Vercel (variables SMTP + FROM/OWNER)
---
## Check-list récapitulative
- [ ] Phase 0 : Détection du stack (Next.js App Router / Pages / Vite / HTML statique)
- [ ] Phase 1 : Choix du fournisseur SMTP (Gmail / Resend / SendGrid / Mailgun / Brevo / Zoho / Personnalisé)
- [ ] Phase 2 : Collecte du contexte (offer.json + conversion-copy.md OU lecture de page.tsx OU interview)
- [ ] Phase 3 : Sélection du modèle (P1 / P2 / P3+P5 / P4)
- [ ] Phase 4 : Brouillons des e-mails (A + B) générés, affichés
- [ ] Phase 5 : Approuvé par l'utilisateur ✓
- [ ] Phase 6 : Code intégré (nodemailer + route API + formulaire + variables d'environnement)
- [ ] Phase 7 : Instructions fournies au fournisseur + plan de test + prêt pour le déploiement
---
## Note sur les références et la mémoire
Ce skill utilise les fichiers de référence suivants (situés dans `references/` du projet) :
- `references/email-formulas.md` — modèles d'e-mails détaillés pour chaque modèle (P1-P5) + exemples de lignes d'objet en vietnamien
- Mémoire : `feedback_email-autoresponder-2-stage-flow` — justification des 2 déclencheurs (P3 + P5)
**Dépendances externes :** `/biz-offer-alex-hormozi` (génération du `offer.json`), `/biz-deploy-vercel` (déploiement Vercel). Skill autonome quant à la détection du `page.tsx`.
---
## Limites actuelles
| Limite | Plan |
|---|---|
| Pas de stockage des leads (base de données) | Prochaine étape : intégration Supabase / Notion DB / Google Sheets |
| Pas de mécanisme de nouvelle tentative pour l'envoi d'e-mail | Retenter 2 fois avec backoff exponentiel → ajouter dans la prochaine itération |
| Pas de logs des e-mails (tracking ouvert/click) | Nécessite un fournisseur SMTP avec tracking (Resend a des logs, SendGrid a des webhooks) |
| Pas de vérification SPF/DKIM automatique | L'utilisateur doit configurer manuellement via les instructions du fournisseur en phase 7 |
| Seulement dans le sens formulaire → e-mail. Pas de webhook inverse (e-mail → webhook) | A faire dans un autre skill |
---
## Changements par rapport à la version précédente
- 2026-05-14 : Arrêt du support pour `biz-sales-page-layout`. Pipeline simplifié : ne plus utiliser `layout.json` / `copy.json`. Seulement `offer.json` + lecture de `page.tsx`.
- 2026-05-01 : Ajout du modèle à 2 déclencheurs P3 + P5 basé sur le feedback de l'utilisateur sur les entonnoirs de paiement.
- 2026-04-15 : Ajout du mode B (lecture HTML déployé) pour les cas sans pipeline d'offre.