200 emails gratuits par mois, aucun backend à coder, un formulaire de contact opérationnel en moins de 30 minutes. C’est la promesse d’EmailJS , et sur le papier elle tient. Mais j’ai intégré ce service sur assez de projets pour savoir où ça coince vraiment : la clé visible dans le navigateur, les messages qui filent en spam, le quota qui sature plus vite qu’on ne l’imagine. Voici ce qu’il faut peser avant de l’adopter.
Ce qu’EmailJS fait, et ce qu’il ne fait pas
Le principe est simple. Vous connectez votre service email (Gmail, Outlook, Amazon SES), vous créez un template dans le tableau de bord, puis vous déclenchez l’envoi depuis JavaScript avec trois identifiants : public key, service ID, template ID. Aucune ligne de code côté serveur. Pour un portfolio ou un site vitrine sur Netlify ou Vercel, c’est imbattable en rapidité.
Le malentendu le plus fréquent : EmailJS n’est pas un form backend. Il envoie des emails, point. Pas de stockage des soumissions, pas de tableau de bord consultable au-delà de l’historique, pas de webhooks, aucune validation côté serveur. Si vous voulez retrouver une demande envoyée il y a trois semaines, le plan gratuit ne garde que 7 jours d’historique. Pour archiver et rechercher les soumissions, un service comme Formspree est plus adapté.
Attention aussi au paquet npm emailjs : c’est un client SMTP côté serveur , un projet totalement distinct du SDK @emailjs/browser. Installer le mauvais paquet est une erreur classique qui fait perdre une demi-heure.
Le piège de la clé exposée dans le navigateur
C’est la question qui revient sur tous les forums : « est-ce dangereux d’avoir ma clé visible dans le code front ? ». La clé publique est conçue pour être exposée. Quelqu’un qui la copie ne pourra déclencher que vos templates prédéfinis, avec votre contenu, sans pouvoir composer un email arbitraire. Peu d’intérêt pour un spammeur.
Le vrai risque est ailleurs. La clé privée (access token) ne doit jamais atteindre le navigateur. Même rangée dans un fichier .env, elle finit embarquée dans le bundle JavaScript au build, donc lisible par n’importe qui. Quiconque la récupère peut vider votre quota ou abîmer votre réputation d’expéditeur.
Concrètement, avant toute mise en ligne, activez deux protections dans le tableau de bord : la liste blanche de domaines (seul votre domaine peut déclencher des envois) et reCAPTCHA sur le formulaire. EmailJS applique aussi des limites par IP, mais elles ne suffisent pas seules. Sans ces garde-fous, un bot peut épuiser vos 200 envois mensuels en quelques minutes.
Gratuit, oui, mais jusqu’où exactement
Le plan gratuit plafonne à 200 requêtes par mois, 2 templates, des requêtes limitées à 50 Ko et 7 jours d’historique. Largement suffisant pour un site personnel à faible trafic. Au-delà, voici les seuils réels :
Le plan Personal à 9 $/mois monte à 2 000 requêtes, 6 templates et des pièces jointes jusqu’à 500 Ko. Le plan Professional à 15 $/mois débloque les templates illimités, 5 000 à 10 000 requêtes selon le palier, des pièces jointes de 2 Mo et 3 sièges utilisateurs. Le plan Business à 40 $/mois grimpe de 25 000 à 200 000 requêtes, avec des pièces jointes jusqu’à 30 Mo et un SLA de disponibilité de 99,5 %. La facturation annuelle retire 20 %.
Deux pièges budgétaires à connaître. Quand le quota est atteint, les requêtes suivantes sont purement ignorées , sans file d’attente : un pic de trafic peut vous faire perdre des messages sans alerte immédiate. Et même si certains plans autorisent 30 Mo de pièces jointes, plusieurs services email coupent à 10 Mo, donc restez sous cette barre pour éviter les rejets silencieux.
Quand passer à une alternative
EmailJS brille sur un créneau précis : le formulaire de contact sur site statique, faible volume, livraison directe vers votre boîte. Dès que les besoins changent, d’autres outils prennent l’avantage.
Pour des emails transactionnels à fort volume ou du marketing, Resend ou SendGrid offrent une bien meilleure délivrabilité et des analytics sérieux, au prix d’un backend à gérer. Si vous voulez stocker et trier les soumissions sans coder, Formspree joue le rôle de form backend complet, autour de 15 $/mois, même si la protection anti-spam y est souvent une option payante. Et si vous avez déjà un serveur, Nodemailer reste gratuit et sans quota.
Le point faible documenté d’EmailJS, c’est la délivrabilité avec une adresse Gmail gratuite comme expéditeur : les messages atterrissent fréquemment en spam. Au-delà de 1 000 emails par mois ou pour tout usage professionnel, branchez un domaine personnalisé authentifié plutôt qu’une adresse grand public.
FAQ
Mes emails EmailJS finissent-ils en spam ? Avec une adresse d’expédition Gmail ou Yahoo gratuite, oui, le risque est élevé. La solution fiable consiste à connecter un service sur votre domaine personnalisé et à configurer les enregistrements SPF et DKIM. La délivrabilité grimpe nettement dès que l’expéditeur est authentifié.
Peut-on utiliser EmailJS côté serveur ? Le SDK officiel @emailjs/browser est pensé pour le navigateur. Pour sécuriser totalement vos clés, déplacez la logique d’envoi dans une fonction serverless (Vercel, Netlify, AWS Lambda) qui appelle l’API. Ne confondez pas avec le paquet npm emailjs, qui est un client SMTP serveur sans aucun lien avec le service.
Mon verdict
EmailJS reste mon premier choix pour un besoin clair : recevoir les messages d’un formulaire de contact sur un site statique, sans backend, sans budget. Le plan gratuit couvre la majorité des sites vitrines, et la mise en place tient ses promesses de rapidité. Mais traitez-le pour ce qu’il est : un déclencheur d’emails, pas une infrastructure. Activez la liste blanche et reCAPTCHA dès le départ, utilisez un domaine authentifié, et basculez vers Resend ou un vrai form backend dès que le volume ou les exigences de fiabilité montent.
