Yayaw gère les modèles d'e-mails transactionnels depuis /dashboard/content/email-templates. Cette route est un écran : une table Yayaw Table en pleine page pour rechercher, filtrer, créer, activer, désactiver, supprimer et ouvrir les modèles (voir La liste des modèles d'e-mails). Chaque ligne ouvre l'éditeur React Email dédié à /dashboard/content/email-templates/[slug].

Docs liées :

Vue d'ensemble du CMS pour comprendre comment les modèles partagent des variables avec le système de contenu plus large
Modèles de données CMS pour les variables CMS globales
Produits de facturation pour les événements d'achat et d'abonnement

La liste des modèles d'e-mails

/dashboard/content/email-templates (permission de route email-template:list) affiche l'écran dashboard.content.email-templates. Les modèles appartiennent à la plateforme : c'est donc un écran global, une seule copie pour toute la plateforme, que seuls les Super Admins personnalisent (voir Dashboard). Son écran par défaut est la table en pleine page de la source system:email-templates, les modèles modifiés en dernier d'abord, 20 par page.

La table liste tous les modèles à qui détient email-template:list globalement, quelle que soit l'organisation active, et une permission d'organisation ne l'ouvre jamais. Qui détient aussi email-template:manage globalement (les Super Admins) dispose de :

Nouveau modèle : le formulaire de création (nom, slug tiré du nom s'il reste vide, catégorie), puis l'éditeur du nouveau modèle ;
la suppression d'une ligne et, pour une sélection, Supprimer, Activer et Désactiver, chacune confirmée ; l'activation et la désactivation ne changent que les modèles qui ne le sont pas déjà.

Le serveur vérifie de nouveau chaque écriture (email-template:create, delete ou update, globalement).

La table garde les colonnes de la liste (nom, slug, catégorie, statut, variables, mise à jour), ses vues enregistrées et ses favoris (email-templates-catalog-v1), et ses files de travail après la vue propre à l'écran : Modèles actifs, Modèles inactifs et E-mails transactionnels. Elle propose les modes Tableau, Liste et un Kanban par catégorie, dont on ne peut pas déplacer les cartes : la catégorie d'un modèle se change dans son éditeur.

Recherche : elle lit le nom, le slug et la catégorie, ainsi que l'objet et la description de chaque langue. Elle ne lit jamais le HTML, le texte brut ou le document de l'éditeur d'un modèle.
Pagination : au plus 100 modèles par page (10, 20 ou 50 proposés).
Ordre : les noms se trient comme on les lit (« Welcome 2 » avant « Welcome 10 »), dans la base ; quand deux noms ne diffèrent que par la casse ou les accents, le nom en minuscules et sans accent vient d'abord.
Paramètres d'URL : les paramètres de la table sont indexés par sa source (system:email-templates-…), et view=<id> ouvre une vue enregistrée ou une file de travail.

Un assistant qui prépare un brouillon de cet écran ne lit que les colonnes de la source, jamais l'identifiant d'une ligne ni si la personne peut la modifier ; les assistants listent et modifient les modèles avec les outils ci-dessous.

Rôle CMS

Les modèles d'e-mails transactionnels sont des surfaces de communication gérées comme du contenu. Ils partagent les patterns d'édition, de localisation, de variables et de plan de contrôle (control plane) avec le CMS, mais ils ne sont pas rendus par le runtime des pages publiques. Les expéditeurs runtime chargent les modèles actifs, appliquent les variables transactionnelles, résolvent les variables CMS et retombent sur les valeurs par défaut des composants React Email quand aucun modèle n'existe en base.

Utilisez les modèles d'e-mails pour les confirmations d'achat, mises à jour d'abonnement, invitations et autres messages pilotés par événements. Utilisez les pages et sections pour le contenu web public ou réservé aux membres d'organisation.

Modèle de données

Chaque modèle stocke :

slug, name, subject, preview_text, description, category
exports html rendu et text brut utilisés par l'envoi runtime
editor_document, le document JSON TipTap de React Email Editor
default_locale, locales et localized_content pour les variantes traduites inline
variables, le contrat {{variable}} propre au modèle
sample_variables, utilisées par l'aperçu externe et les envois de test
design hérité, conservé uniquement pour que les anciennes lignes Unlayer puissent migrer proprement

Les modèles sont à l'échelle plateforme en v1. Les surcharges propres aux organisations devront être ajoutées plus tard comme couche de lookup explicite, plutôt que surcharger la table globale actuelle.

Le plan de contrôle (control plane) de production expose les opérations de modèles pour les clients MCP de confiance :

yayaw_email_templates_list
yayaw_email_template_get
yayaw_email_template_save
yayaw_email_templates_sync_system

Les écritures exigent control-plane:write ou control-plane:admin, l'autorisation Yayaw email-template:update/manage et un reason.

Localisation

Les modèles d'e-mails suivent le même modèle de localisation inline que les pages CMS. La barre d'outils de l'éditeur permet aux auteurs de changer de locale activée, et chaque locale stocke son propre objet, texte d'aperçu, description, HTML, export texte et document éditeur dans localized_content.

Enregistrer une locale met uniquement cette locale à jour. La locale par défaut miroite aussi les colonnes héritées de premier niveau afin que les lookups runtime existants et les anciennes lignes continuent de fonctionner pendant la migration.

Le panneau IA inclut une bascule de synchronisation de locale activée par défaut. Quand un modèle est enregistré, la locale actuellement ouverte sert de source, et les mêmes changements de texte, structure, style et ordre de blocs sont appliqués aux autres locales activées. Les mises à jour de synchronisation générées par IA écrivent les valeurs localisées subject, previewText, description, html et text ; les valeurs editorDocument des locales cibles sont effacées afin que l'éditeur puisse reconstruire depuis le HTML synchronisé quand cette locale est ouverte.

Le canvas de l'éditeur se concentre uniquement sur le design. La barre d'outils ouvre l'aperçu d'e-mail rendu dans un onglet séparé du navigateur après export du dernier état éditeur et application des variables transactionnelles d'exemple, plus les variables CMS globales.

Variables

Les modèles d'e-mails prennent en charge deux familles de variables :

Les variables de modèle utilisent {{name}} ou des chemins imbriqués comme {{invitation.inviteLink}}.
Les variables CMS utilisent le format de token CMS global, par exemple {site.name} ou {data.global.header-menu.main.brand_label}.

L'éditeur d'e-mail expose les deux familles. Les variables CMS sont résolues via le même catalogue de données globales publiées et de variables de site que celui utilisé par les pages et sections, afin que les auteurs de contenu puissent réutiliser les mêmes valeurs globales dans tout le CMS.

Comportement runtime

Lors de l'envoi d'un e-mail, Yayaw essaie d'abord le modèle actif en base pour le slug configuré et la locale demandée. Si cette locale manque, le rendu retombe sur la locale par défaut du modèle puis sur les colonnes héritées de premier niveau. Si aucun modèle actif n'existe, les e-mails auth continuent d'utiliser le fallback de leur composant React Email.

Les e-mails de facturation sont aussi des modèles système. Ils sont envoyés depuis les handlers de webhooks Stripe et sont volontairement non bloquants : si Resend n'est pas configuré ou si le modèle manque, le webhook journalise le skip et continue de traiter l'achat ou la mise à jour d'abonnement.

Slugs des modèles de facturation intégrés :

billing-purchase-confirmation
billing-subscription-updated
billing-invoice-available

Les modèles de facturation peuvent utiliser des variables imbriquées comme :

{{billing.productName}}
{{billing.amountFormatted}}
{{billing.billingInterval}}
{{billing.billingReason}}
{{billing.optionsSummary}}
{{billing.lineItemsSummary}}
{{billing.discountSummary}}
{{billing.periodStart}} et {{billing.periodEnd}}
{{billing.invoiceId}}, {{billing.invoiceNumber}}, {{billing.invoiceUrl}} et {{billing.invoicePdfUrl}}
{{billing.manageUrl}}
{{billing.accessUrl}}
{{billing.deliverablesSummary}}
{{organization.name}}
{{user.email}}

billing-invoice-available est envoyé depuis les événements Stripe invoice.paid. Le handler est idempotent via billing_webhook_events et résout l'organisation depuis les métadonnées de facture, les métadonnées d'abonnement, puis les lignes locales d'abonnement/client. Le Checkout ponctuel active aussi la création de factures Stripe, afin que les achats lifetime payés puissent générer ce modèle.

Utilisez bun run docs:llm:generate et l'outil du plan de contrôle yayaw_email_templates_sync_system après avoir ajouté des métadonnées de modèles de facturation afin que les variables de l'éditeur et la synchronisation du plan de contrôle MCP restent alignées.

Le HTML stocké est traité comme la représentation runtime rapide. Enregistrez le modèle après édition afin que html, text et editor_document restent synchronisés.

Workflow local

Après modification des contrats de modèles, métadonnées de modèles système, schéma ou docs assistants générées, exécutez :

bun run generate:actions
bun run docs:generate
bun run docs:check-translations
bun run docs:llm:generate
bun run docs:llm:check
bunx tsc --noEmit
bun run check

Pour les variables d'e-mails de facturation, exécutez aussi :

bun test src/lib/server/services/billing/billing-email-notifications.test.ts

Modèles d'e-mails transactionnels