Créateur d'app IA avec Resend : les e-mails du projet

Créateur d'app IA avec Resend : les e-mails du projet

Oui : un projet construit sur Zugo peut envoyer des e-mails via Resend. Il s'agit des messages que le produit émet tout seul, comme la confirmation d'un formulaire ou l'accusé de réception d'une commande. Brancher le service ne consomme pas de crédits, puisque ceux ci servent à construire et à modifier le projet.

Le vrai sujet n'est pas le branchement, qui prend quelques minutes. C'est de savoir quels messages méritent d'exister, et lesquels agacent tout le monde.

À quoi sert Resend dans un projet généré ?

À envoyer des e-mails depuis votre nom de domaine plutôt que depuis une boîte personnelle. La différence se voit dès le premier message : l'expéditeur est votre entreprise, l'adresse de réponse aussi, et le message ne passe pas par votre messagerie du matin.

Le second bénéfice est moins visible et plus important : la traçabilité. Un service d'envoi garde la trace de ce qui est parti, de ce qui a été accepté par le serveur destinataire et de ce qui a été refusé. Quand un client affirme n'avoir rien reçu, vous avez autre chose à répondre qu'une intuition.

Il faut nommer la frontière tout de suite. Ce dont on parle ici, ce sont les e-mails déclenchés par le produit. Une stratégie de campagnes, de segmentation et de relance commerciale est un autre métier, souvent servi par un autre outil, et le confondre avec l'envoi transactionnel donne des résultats médiocres des deux côtés.

Quels e-mails un petit projet envoie t il vraiment ?

Moins qu'on ne croit, et toujours les mêmes familles. Le tableau ci dessous couvre l'essentiel de ce qu'un site ou une application de petite taille a besoin d'émettre.

La règle qui évite les regrets : un e-mail automatique se justifie quand son absence crée une inquiétude. Personne ne se demande s'il a bien reçu une lettre de bienvenue, tout le monde se demande si sa demande de devis est partie.

Si votre besoin est de collecter des adresses avant d'envoyer quoi que ce soit, construire une page d'inscription à une newsletter traite l'étape d'avant.

Pourquoi ne pas envoyer depuis une adresse Gmail ?

Parce que les messageries jugent l'expéditeur autant que le contenu, et qu'un envoi automatique depuis une adresse grand public réunit les signaux qui font atterrir en indésirable.

Trois raisons concrètes. Un envoi programmé depuis une boîte personnelle sort du comportement normal de cette boîte, et les filtres le remarquent. Vous n'avez aucune trace exploitable en cas de litige. Et vous mélangez, dans une même boîte, vos conversations et les messages du produit, ce qui rend le suivi impossible dès la dixième demande.

Un domaine d'envoi qui vous appartient règle les trois d'un coup. C'est la même logique que pour l'adresse du site : le sujet du nom de domaine est développé dans brancher un domaine personnalisé, et l'e-mail en est le prolongement naturel.

Que faut il configurer pour que les messages arrivent ?

Le travail se passe dans la zone DNS de votre domaine, pas dans le projet. Trois enregistrements font l'essentiel du travail de réputation.

SPF déclare quels serveurs ont le droit d'envoyer en votre nom. DKIM signe chaque message pour prouver qu'il n'a pas été modifié en route. DMARC dit aux messageries destinataires quoi faire quand une des deux vérifications échoue. Les trois se posent une fois et demandent ensuite très peu d'entretien.

Deux erreurs coûtent des journées entières. La première consiste à modifier ces enregistrements dans un panneau qui n'est pas celui qui fait autorité, ce qui arrive quand le domaine est enregistré chez un prestataire et délégué à un autre. La seconde consiste à conclure que rien ne fonctionne au bout de dix minutes : la propagation DNS prend en général de quelques minutes à quelques heures.

Testez ensuite avec de vraies adresses chez plusieurs fournisseurs, y compris une boîte professionnelle d'entreprise, pas seulement la vôtre.

Combien coûte tout cela en crédits ?

L'envoi d'e-mails relève de votre compte Resend. Sur Zugo, les crédits couvrent la construction et les modifications, selon la grille ci dessous.

La formule gratuite donne 5 crédits, soit un peu moins qu'une construction complète. Pro coûte $25 par mois pour 200 crédits, ce qui correspond à environ 33 constructions, ou 66 modifications, ou 16 plateformes multipages. Business coûte $99 par mois pour 800 crédits.

Un conseil d'arbitrage utile : regroupez vos demandes de changement sur les e-mails. Reformuler trois messages en une seule modification coûte 3 crédits, les reformuler un par un en coûte 9 pour le même résultat.

Un e-mail est il toujours le bon canal ?

Non, et le réflexe d'en envoyer un pour chaque événement produit de la fatigue plus que de l'attention.

Pour une information que l'utilisateur consultera plus tard, l'e-mail est parfait : il reste, il se retrouve, il se transfère à son comptable. Pour une information immédiate pendant qu'il est sur la page, un message affiché à l'écran fait mieux le travail et ne coûte rien à personne.

Il existe aussi un troisième cas, celui où l'e-mail est le mauvais canal parce que la loi encadre l'usage. La prospection commerciale vers des particuliers suppose un consentement préalable, et une case pré cochée n'en est pas un. Ce que vous stockez de vos utilisateurs pour ces envois relève du même sujet que mes données sont elles en sécurité.

Où sont les limites honnêtes ?

Trois, dites franchement.

La délivrabilité ne s'achète pas, elle se construit. Un domaine neuf qui envoie beaucoup d'un coup se fait filtrer, quel que soit le prestataire. Montez en volume progressivement et surveillez les refus dès les premières semaines.

Zugo ne remplace pas une équipe de développement sur un produit complexe. Des scénarios d'envoi conditionnels, des relances qui dépendent du comportement, des modèles de message multilingues gérés par une équipe marketing : tout cela dépasse ce qu'une génération et quelques modifications produisent proprement.

Enfin, la vérification en bac à sable porte sur le projet livré : Zugo s'assure qu'une construction s'ouvre avant de vous la rendre. Elle ne teste pas votre configuration DNS, ni le texte de vos messages, ni le fait qu'une adresse de réponse soit relevée par un humain. Envoyez vous un exemplaire de chaque e-mail et lisez le sur téléphone avant d'ouvrir au public.

Par où commencer ?

Faites la liste des messages que votre projet doit émettre, en une ligne chacun, avant de brancher quoi que ce soit. Une liste courte se tient, une liste ambitieuse finit en messages jamais relus.

Construisez ensuite le projet, publiez le, branchez le domaine puis l'envoi, et testez chaque message avec de vraies adresses. Si des paiements sont en jeu, prévoyez la confirmation d'achat en même temps que l'encaissement, le sujet est traité dans brancher Stripe sur un projet généré. Vous pouvez commencer sur zugo.dev avec la formule gratuite et n'ajouter l'e-mail que le jour où quelqu'un attend une réponse.