Que fait Email Automation — Constructeur de section d'administration ?
Construisez un système d'automatisation des emails de classe mondiale à l'intérieur du panneau d'administration existant de l'utilisateur. Il surveille le comportement des utilisateurs, les inscrit dans la séquence de cycle de vie appropriée et envoie des emails de rappel personnalisés, un par un, via la connexion email configurée de l'application — basé sur un timing de tunnel éprouvé, pas sur des envois en masse.
Objectif : augmenter le retour, l'achat et la rétention des utilisateurs — sans spammer personne et sans casser ce qui fonctionne déjà.
Lisez ceci en premier : cette compétence est non intrusive par conception. Elle étudie l'application avant d'y toucher, n'ajoute que de nouvelles tables/routes (ne réécrit jamais les flux existants), réutilise la connexion email de l'application et est livrée en pause. Rien n'est envoyé tant qu'un administrateur ne l'a pas explicitement activée.
Le flux de travail
0. Découverte ─▶ 1. Conception ─▶ 2. Construction ─▶ 3. Branchement des événements ─▶ 4. Interface admin ─▶ 5. Vérification ─▶ 6. Remise
étudier modèle de nouvelles déclencheurs → tableau de test à blanc + en pause +
l'application données + tables/ inscriptions bord + tables aperçu « Activer ? »
+ admin séquences worker/planning + statistiques
0. Découverte (obligatoire, avant tout code)
Étudiez l'application en profondeur et produisez un court plan d'intégration. Voir references/discovery.md.
- Détectez la stack, le framework, l'ORM/SGBD, l'auth, les sessions, le panneau d'administration (ou notez son absence).
- Trouvez la connexion email existante (SMTP/SDK du fournisseur) — réutilisez-la ; n'en ajoutez jamais une seconde.
- Cartographiez les produits, le panier/checkout, les commandes, les utilisateurs et les événements nécessaires.
- Comprenez le but et le modèle économique de la plateforme (e-commerce, SaaS, fintech, réservation, …), son événement d'activation et ses étapes critiques pour le compte — puis proposez des séquences de rappel supplémentaires adaptées (vérification d'email, complétion de profil, onboarding, KYC, essai/facturation, réservation, renouvellement…).
- S'il n'y a pas de panneau d'administration, demandez à l'utilisateur s'il faut en créer un minimal.
1. Conception
- Définissez le modèle de données (
examples/data-model.md) : séquences, étapes, inscriptions, emails planifiés, journal des envois, paramètres, suppressions. - Choisissez l'ensemble de séquences et les timings (
references/sequences.md).
2. Construction (ajout uniquement)
- Ajoutez de nouvelles tables/collections, une tâche planifiée et le worker d'envoi. Ne modifiez pas les tables existantes.
- Ajoutez un interrupteur / bouton pause maître (par défaut OFF) et un coupe-circuit global.
3. Branchement des événements
- Accrochez les événements existants de l'application (inscription, connexion, ajout au panier, début de checkout, achat, inactivité) à l'inscription — sans modifier leur comportement (observez, n'interceptez pas).
4. Interface admin
- Ajoutez un menu de niveau supérieur « Email Automation » avec des onglets : Séquences · Destinataires · Statistiques · Paramètres. Voir
references/admin-ui.md. - Ajoutez des tables réservées aux administrateurs (achetés/abandonnés) en bas des pages produit et checkout.
5. Vérification
- Mode test à blanc, outil d'aperçu/envoi test, contrôles d'idempotence et audit des conditions d'arrêt.
6. Remise
- Le système est livré en pause. Notifiez l'administrateur, montrez un bouton « Activer » en un clic (ou laissez l'agent aider) et documentez le rollback.
Le catalogue de séquences (timing de tunnel éprouvé)
Détails complets, intention du contenu et conditions d'arrêt : references/sequences.md. Résumé :
| # | Séquence | Déclencheur | Timing (par défaut) | S'arrête quand |
|---|---|---|---|---|
| 1 | Bienvenue / activation | Inscription | 0h bienvenue → 24h valeur → 72h preuve sociale | Connexion / achat |
| 2 | Inscrit, jamais connecté | Inscrit + aucune connexion | 1h → 24h → 72h | Connexion |
| 3 | Connecté, aucun achat/utilisation | Connecté, inactif | 1h rappel → 24h → 5j | Achat / activation |
| 4 | Panier / checkout / produit abandonné | Panier ou checkout ou vue produit, aucun achat | 1h rappel (sans réduction) → 24h preuve sociale/objection → 48–72h urgence + réduction | Achat |
| 5 | Avis post-achat | Achat (conscient du type de produit) | Le lendemain « Comment ça va ? » → 2 semaines « expérience + vente additionnelle » | Avis / désabonnement |
| 6 | Vente additionnelle / croisée | Achat, autres produits existent | Après le moment de valeur (3–7 jours) | Achat de l'article promu |
| 7 | Reconquête / réengagement | Inactif 30 / 60 / 90 jours | Neutre → valeur → final « nous allons arrêter » | Activité / désabonnement |
| 8 | Réapprovisionnement | Produit consommable | ~Jour 45–60 | R rachat |
Réductions : Les ventes additionnelles peuvent comporter une réduction ; les paniers abandonnés comportent urgence + réduction. Par défaut 0 % — à 0, l'email ne doit pas mentionner de réduction du tout. Une garde de panier minimal ignore l'incitation sur les paniers de très faible valeur. (references/sequences.md.)
Précédence : un utilisateur est dans au plus une séquence promotionnelle — achat > panier > navigation > bienvenue > non-connexion > inactif > reconquête. Séquences supplémentaires : abandon de navigation, retour en stock, baisse de prix, relance de paiement, parrainage. Voir references/sequences.md.
Plus les séquences dérivées de la plateforme découvertes à partir du but de l'application — par ex. vérification d'email, complétion de profil, configuration onboarding, KYC, fin d'essai/facturation, rappels de réservation, renouvellements. N'ajoutez que celles que la plateforme peut détecter et sur lesquelles elle peut agir (references/sequences.md).
Règles non négociables
- Étudier avant de construire. Ne modifiez jamais les flux d'authentification, panier, checkout, commande ou utilisateur existants. N'ajoutez que de nouvelles tables/routes.
- Réutilisez la connexion email existante. Pas de deuxième configuration SMTP/fournisseur. Pas d'envoi en masse — les emails sont par utilisateur et pilotés par événement.
- Livré en pause. Interrupteur maître OFF ; l'administrateur est notifié pour l'activer (l'agent peut proposer son aide).
- Pas de spam. Limites de fréquence (par défaut ≤1 email marketing/utilisateur/24h, ≤4/semaine), heures de silence et une liste de suppression globale (désabonné, rebond, plainte). Respectez le consentement et l'intérêt.
- Les conditions d'arrêt gagnent toujours. Revérifiez l'objectif (achat/connexion/activation) avant chaque envoi pour que les acheteurs ne reçoivent pas de rappels de panier.
- Contenu personnalisé, un à un. « De » une vraie personne (
Nom de la Marque), formulé personnellement, fait référence au produit réel, un seul CTA clair et un lien « contacter l'administrateur » dans chaque email. - Délivrabilité + conformité légale. SPF/DKIM/DMARC, domaine d'envoi de marque, HTML + texte brut, désabonnement + adresse physique, pas de mots déclencheurs de spam. Voir
references/sending-and-compliance.md. - Tout est vérifiable. Chaque envoi est journalisé (qui, quelle séquence/étape, quand, pourquoi) et chaque email planifié est visible dans l'administration.
- Esthétique + intégration parfaite. Alignez-vous sur les tokens de design de l'application ; la section d'administration doit paraître native. Utilisez la rigueur type
reviews-to-features: hiérarchie claire, cibles de 44 pixels, contraste accessible. - Éditeur WYSIWYG gratuit pour les corps d'email. L'administrateur édite chaque modèle d'email dans un éditeur WYSIWYG gratuit, auto-hébergé (TinyMCE Community ; ou Quill / TipTap / Summernote / GrapesJS). La sortie doit être sûre pour l'email (CSS en ligne, tableaux, ~600 px, pas de JS), nettoyée, avec des jetons de fusion, un bloc de réduction conditionnelle et une version texte brut générée automatiquement.
Contrat de non-intrusion (appliqué)
« Non intrusif » est vérifié, pas supposé. Liste de contrôle complète : references/non-disruption.md. Minimum :
- Sauvegardez la base de données avant la migration ; les migrations sont additives + réversibles (ne modifient pas les tables existantes).
- Les hooks sont en mode observation uniquement et encapsulés dans
try/catch— un observateur en échec ne casse jamais l'inscription/connexion/checkout/paiement. - Livré en pause avec un coupe-circuit global ; réutilisez la connexion mail existante.
- Test de fumée des cinq flux principaux après l'installation ; exécutez un exercice de rollback (désactiver → supprimer les tables → confirmer que rien n'est touché).
Surface d'administration (ce que l'administrateur obtient)
- Disposition calme et épurée — ≤4 onglets, une seule action principale par vue, détails dans un tiroir, actions secondaires/destructrices dans un menu débordant (
⋯), paramètres avancés repliés, bannières de santé seulement quand nécessaire. - Bannières de santé en haut de chaque onglet (seulement en cas de problème) : aucun transport email configuré, planificateur/cron non exécuté (avec un détail du pourquoi + comment corriger) et automatisation en pause. Voir
references/health-checks.md. - Menu Email Automation (niveau supérieur), avec onglets :
- Séquences — par séquence Démarrer / Mettre en pause / Supprimer (suppression confirmée + soft-delete/restaurable, rangée dans
⋯), délais, réductions, conditions d'arrêt, un éditeur WYSIWYG gratuit et ajouter / réordonner / supprimer des étapes. - Utilisateurs et destinataires — rechercher un utilisateur par email ; développer leur séquence d'emails avec la flèche vers le bas ; annuler un email spécifique ou exclure complètement l'utilisateur ; plus le journal complet des envois pagé par 100 avec quand et pourquoi.
- Statistiques — des utilisateurs qui ont reçu un rappel, combien ont converti, revenu, graphique par jour / semaine / mois.
- Paramètres — expéditeur (nom-d'expéditeur/email-d'expéditeur/répondre-à/adresse physique), pause maître, limites, heures de silence.
- Séquences — par séquence Démarrer / Mettre en pause / Supprimer (suppression confirmée + soft-delete/restaurable, rangée dans
- Tables réservées aux administrateurs en bas des pages produit et checkout :
- Onglets Acheté / Abandonné — clairement marqués « Admin only ».
- Colonnes : email (→ panneau utilisateur), dates d'inscription/connexion/abandon, montant qui aurait été payé, téléphone (→
tel:appel) et une flèche dévoilant emails reçus + planifiés qui renvoie au panneau utilisateur pour annuler/exclure. - Désactivable depuis Email Automation → Paramètres, avec instructions sous le titre du tableau + lien.
Spécification complète de l'interface : references/admin-ui.md.
Quand NE PAS utiliser
- Aucune base de consentement légale pour l'email marketing (proposez d'abord un flux de consentement).
- Très petites bases d'utilisateurs où le bruit de l'automatisation dépasse la valeur — envoyez manuellement.
- Produits où l'email n'est pas le canal (SMS/push d'abord) — adaptez le moteur, ne forcez pas l'email.
- Contextes réglementés (santé/finance) nécessitant une revue plus stricte — obtenez l'approbation sur le contenu et les flux de données.
- Besoins transactionnels à haute assurance — ne routez jamais les reçus/emails de sécurité via ce système.
Livrables produits par l'agent
references/discovery.md→ un plan d'intégration pour l'application spécifique, comprenant une liste restreinte de séquences proposées dérivée du but de la plateforme.- Nouvelles tables/migrations + le planificateur + le worker d'envoi (additifs).
- Les hooks d'événements (observation uniquement).
- La page d'administration « Email Automation » + onglets + graphique de statistiques, incluant un éditeur WYSIWYG gratuit, ajouter / réordonner / supprimer des étapes, une recherche d'utilisateur + annulation/exclusion par email et avertissements de santé (pause, cron non exécuté, aucun transport mail).
- Les tables réservées aux administrateurs (achetés/abandonnés).
- Un outil d'aperçu/envoi test + test à blanc + notes de rollback.
- Un court document de remise : ce qui a été ajouté, comment l'activer, comment le mettre en pause, comment faire un rollback.
Références
references/discovery.md— étudier l'application, trouver l'administration, choisir un chemin d'intégration.references/non-disruption.md— le contrat de non-intrusion appliqué (sauvegarde, migrations réversibles, isolation des hooks, test de fumée, exercice de rollback).references/triggers.md— règles de détection exactes pour chaque déclencheur (abandon de panier, inactivité, etc.).references/sequences.md— le catalogue complet des séquences, précédence, timings, intention du contenu, conditions d'arrêt.references/email-copy.md— standards de contenu personnel « d'une seule personne », lignes d'objet, modèles.references/sending-and-compliance.md— planificateur, idempotence, limites, pré-vérification de délivrabilité.references/compliance.md— consentement, désabonnement signé, centre de préférences, webhooks de rebond/plainte.references/admin-ui.md— tableau de bord, onglet utilisateurs (recherche/annulation/exclusion), journal (100/page), statistiques, tables admin-only, WYSIWYG, ajout/modification d'étapes.references/health-checks.md— avertissements de pause / cron non exécuté / absence de transport avec conseils de correction.references/reference-implementation.md— le moteur en pseudocode + SQL (verrouillage, moissonnage, attribution).examples/worker.mjs+examples/worker.test.mjs— noyau planificateur/worker exécutable et testé.examples/data-model.md— schéma de base de données.examples/sequence-config.json— une configuration de séquence concrète et éditable.examples/email-templates.md— exemples d'emails rendus.