Une alternative à EmailJS qui garde les clés hors du navigateur

EmailJS envoie les e-mails depuis le navigateur : votre id de service, votre id de modèle et votre clé publique sont donc livrés dans le JavaScript de votre page, à la portée de tous. Un backend de formulaires n'a besoin d'aucune clé dans le navigateur : le formulaire envoie vers une URL, et le backend filtre le spam, stocke le message et vous envoie un e-mail. Vous perdez la réponse automatique d'EmailJS au visiteur, que vous enverriez plutôt depuis votre propre outil d'e-mailing.

Ce qui change ici

EmailJS est populaire pour une bonne raison : il envoie de vrais e-mails depuis un site statique sans serveur. Pour cela, le navigateur appelle directement EmailJS avec trois valeurs : un id de service, un id de modèle et une clé publique. Elles sont dans votre bundle, lisibles dans le code source de la page ou l'onglet réseau.

La FAQ d'EmailJS indique que quelqu'un qui les copie ne peut envoyer que vos modèles avec votre contenu, pas des e-mails arbitraires. C'est vrai pour le texte fixe du modèle. Mais c'est l'appelant qui remplit les variables du modèle : les clés copiées peuvent donc envoyer votre modèle avec n'importe quel nom, message et liens, aussi souvent que votre quota le permet. Et si le To d'un modèle est une variable, comme pour une réponse automatique à l'adresse du visiteur, l'appelant choisit aussi le destinataire.

EmailJS propose des réglages qui réduisent ce risque, comme restreindre les domaines autorisés à utiliser votre clé et ajouter un captcha à un modèle. Vérifiez lesquels votre offre inclut et activez-les si vous restez. La comparaison ci-dessous porte sur la conception, pas sur un verdict concernant le service :

Si la réponse automatique ou un e-mail à votre marque est l'essentiel, EmailJS, ou votre propre serveur avec une API d'e-mail, convient mieux. Si vous voulez le message dans votre boîte, en toute sécurité, et conservé quelque part, un backend de formulaires convient.

Migrer le formulaire

Un formulaire EmailJS typique en React, d'après leur tutoriel de formulaire de contact :

import emailjs from "@emailjs/browser";
import { type FormEvent, useRef, useState } from "react";

export function ContactForm() {
  const form = useRef<HTMLFormElement>(null);
  const [status, setStatus] = useState("");

  async function onSubmit(event: FormEvent<HTMLFormElement>) {
    event.preventDefault();
    if (!form.current) return;
    try {
      await emailjs.sendForm("service_abc123", "template_xyz789", form.current, {
        publicKey: "aBcDeFgHiJkLmNoPq",
      });
      setStatus("Message sent.");
    } catch {
      setStatus("Couldn't send your message.");
    }
  }

  return (
    <form ref={form} onSubmit={onSubmit}>
      <input name="user_name" required />
      <input name="user_email" type="email" required />
      <textarea name="message" required />
      <button>Send</button>
      <p role="status">{status}</p>
    </form>
  );
}

Le même formulaire qui envoie à Ikiform avec submit() de @ikiform/sdk :

import { submit } from "@ikiform/sdk";
import { type FormEvent, useState } from "react";

const FORM_ID = "frm_xxxxxxxxxxxxxxxx";

export function ContactForm() {
  const [status, setStatus] = useState<"idle" | "sending" | "sent">("idle");
  const [fields, setFields] = useState<Record<string, string[]>>({});
  const [error, setError] = useState("");

  async function onSubmit(event: FormEvent<HTMLFormElement>) {
    event.preventDefault();
    setStatus("sending");
    setFields({});
    setError("");
    const result = await submit(FORM_ID, new FormData(event.currentTarget));
    if (result.ok) {
      setStatus("sent");
      return;
    }
    setFields(result.error.fields ?? {});
    setError(result.error.code === "network_error" ? "You're offline. Try again." : result.error.message);
    setStatus("idle");
  }

  if (status === "sent") return <p role="status">Message sent. We'll reply by email.</p>;

  return (
    <form onSubmit={onSubmit}>
      <label htmlFor="user_name">Name</label>
      <input id="user_name" name="user_name" required />
      <label htmlFor="email">Email</label>
      <input id="email" name="email" type="email" required />
      {fields.email ? <p role="alert">{fields.email[0]}</p> : null}
      <label htmlFor="message">Message</label>
      <textarea id="message" name="message" required />
      {fields.message ? <p role="alert">{fields.message[0]}</p> : null}
      <input name="_gotcha" type="text" tabIndex={-1} autoComplete="off" hidden />
      {error && !Object.keys(fields).length ? <p role="alert">{error}</p> : null}
      <button disabled={status === "sending"}>{status === "sending" ? "Sending" : "Send"}</button>
    </form>
  );
}

• @emailjs/browser et les trois id disparaissent. Désinstallez le package, et supprimez le modèle ou le service EmailJS une fois le nouveau formulaire en place, pour que les copies en cache de votre page cessent d'envoyer.
• user_email devient email. EmailJS ne se soucie pas des noms, mais Ikiform utilise le champ appelé email comme adresse de réponse. Les autres noms peuvent rester, car les notifications listent les champs tels qu'ils arrivent.
• submit() ne lève jamais d'exception. Il renvoie l'enveloppe d'erreur, pour que les erreurs de champ issues de la définition du formulaire s'affichent sous leur input.
• Le honeypot est nouveau. EmailJS n'en avait pas ; cet input masqué arrête les bots les plus simples sans configuration.
• Ajoutez votre domaine dans Allowed domains, pour que les envois depuis d'autres sites soient marqués comme spam.

Si vous utilisiez la réponse automatique

Ikiform n'envoie pas d'e-mail à la personne qui remplit le formulaire. Les e-mails de notification vont uniquement à vous et à votre équipe : il n'y a donc ni réponse automatique, ni e-mail de confirmation, ni double opt-in. Envoyez-les depuis votre outil d'e-mailing, déclenché par un webhook. Un service d'envoi que vous pilotez depuis un serveur, comme Resend ou Postmark, peut l'envoyer à chaque webhook submission.created, avec l'adresse du visiteur tirée du payload de confiance plutôt que du navigateur. Le guide sur les destinataires multiples contient un gestionnaire que vous pouvez adapter.

Demandez-vous si vous en avez besoin. Le message de remerciement sur la page indique au visiteur que cela a fonctionné, et une vraie réponse de votre part une heure plus tard vaut mieux qu'un modèle.

Vérifiez que tout fonctionne

1. Dans Allowed domains du formulaire, ajoutez le domaine de votre site, plus localhost pendant le développement. Laissez vide pour accepter les envois de partout.
2. Cherchez emailjs et votre ancien id de service dans votre site compilé. Rien ne doit correspondre.
3. Remplissez le formulaire sur votre page et envoyez-le. Vous arrivez sur votre page de remerciement, ou sur celle hébergée par Ikiform.
4. Vérifiez la boîte de réception de chaque destinataire des notifications. Chacun reçoit un e-mail avec les champs, et Reply répond à l'expéditeur quand le formulaire a un champ email.
5. Envoyez avec le honeypot rempli, _gotcha=bot. L'envoi reçoit quand même une réponse de succès, mais la soumission est stockée comme spam et n'envoie ni e-mail ni webhook.

Si quelque chose ne va pas

Questions