Création d’email et envoi : définir le passage

Un utilisateur termine son email et clique sur Envoyer. Derrière cette action, votre application peut enregistrer un brouillon, produire le HTML, personnaliser le contenu, soumettre une tâche et attendre des événements de livraison.

La création d’email et l’envoi se rejoignent à cet endroit. Attribuer chaque étape à un responsable rend les erreurs compréhensibles et réduit le risque d’envoyer une mauvaise version.

Distinguer document et message sortant

Le document modifiable décrit une structure : titres, paragraphes, références d’images et réglages de présentation. L’export contient le HTML rendu et une version texte. La tâche d’envoi ajoute les destinataires, l’expéditeur et les états opérationnels.

Ces éléments n’ont pas le même cycle de vie. Vous pouvez reprendre le document pour l’annonce du mois suivant tout en conservant intact l’historique du précédent envoi. Exporter le dernier brouillon ne doit pas réécrire la trace de ce qui est déjà parti.

Weavour assure la création, héberge modèles et images et exporte le HTML. Votre application assure l’envoi. La méthode documentée exportHTML() renvoie { html, text, document } ; elle ne choisit pas l’audience et ne soumet pas une diffusion. La documentation de rendu React Email traite également la génération du balisage comme une opération distincte.

Formaliser le contrat de votre application

Prenons une annonce intitulée « Nouveau tableau de reporting ». Votre backend pourrait recevoir l’identifiant du document, sa révision enregistrée, l’objet, le HTML, le texte et une sélection d’audience. C’est un exemple de contrat applicatif, pas une route ni un format de requête Weavour.

Le sens des champs est essentiel. L’objet provient-il du brouillon courant ? Le HTML représente-t-il la révision 18 ? Les variables doivent-elles être résolues avant la soumission, ou le système d’envoi les remplacera-t-il pour chaque destinataire ?

Documentez ces choix. Si quelqu’un modifie le brouillon après validation, votre produit doit soit demander une nouvelle validation, soit conserver l’instantané déjà approuvé. Associer silencieusement une ancienne autorisation à un nouveau contenu crée une ambiguïté difficile à diagnostiquer.

Garder le choix des destinataires côté serveur

L’application hôte sait quelle personne authentifiée demande l’envoi, quel client possède l’audience et quels contacts sont admissibles. Vérifiez ces relations sur le serveur au lieu de faire confiance aux identifiants ou adresses reçus du navigateur.

Les secrets du prestataire d’envoi restent également côté serveur. L’éditeur n’en a pas besoin pour produire le message. Les userId et organizationId intégrés à Weavour sont des espaces de noms déclaratifs, sans identité utilisateur vérifiée ; une autorisation administrative doit provenir du contexte authentifié de votre application.

Appliquez vos règles de préférences et d’exclusion lorsque l’audience devient une tâche d’envoi. Une prévisualisation préparée plus tôt peut ne plus refléter la liste actuelle. Définissez le traitement de ces changements plutôt que d’en charger implicitement l’éditeur.

Prévoir une reprise adaptée à chaque erreur

Si l’export échoue, gardez le brouillon visible et indiquez la préparation à corriger. Si le backend refuse l’audience, permettez de modifier la sélection sans perdre le message. Si une requête au prestataire expire, cherchez si elle a été acceptée avant de proposer une nouvelle soumission.

Utilisez un identifiant stable de tâche dans votre application pour éviter qu’un double clic crée deux campagnes. Associez-y la révision du contenu et distinguez la réponse initiale du prestataire des événements de livraison ultérieurs.

L’acceptation par un prestataire ne prouve pas l’arrivée en boîte de réception. La présentation de la délivrabilité par Amazon SES rappelle les enjeux de réputation et de retour d’information. Choisissez des libellés correspondant à vos preuves.

Tester un message de bout en bout

Pour cette annonce de reporting, réalisez un exercice limité :

• Enregistrer une révision et exporter exactement son contenu.
• Prévisualiser avec des données complètes puis incomplètes.
• Soumettre l’envoi à un destinataire interne par votre backend.
• Rejouer la requête et vérifier la prévention des doublons.
• Contrôler le message reçu, ses liens et son alternative texte.
• Retrouver sa révision depuis l’historique d’envoi.

Le passage est fiable quand chaque composant peut expliquer ce qu’il a accepté et produit. Dessinez ces responsabilités avant de connecter le bouton Envoyer. Utilisez ensuite Weavour comme couche de création dans le parcours d’envoi dont votre application garde la maîtrise.