React Email Editor
Composant React sous licence MIT qui intègre l'éditeur d'e-mails par glisser-déposer d'Unlayer dans votre propre produit
React Email Editor est un composant React qui installe un éditeur d'e-mails par glisser-déposer à l'intérieur de votre application, pour que vos utilisateurs conçoivent leurs e-mails sans que vous ayez à construire un éditeur. Le composant est sous licence MIT, s'installe depuis npm en une ligne et compte 5 206 étoiles GitHub en août 2026 — mais l'éditeur qu'il affiche est le produit hébergé d'Unlayer, et c'est précisément la distinction que le badge de licence masque. Il détermine la vitesse à laquelle vous livrez la gestion de modèles d'e-mails ; il ne détermine rien quant à l'ouverture de ces e-mails.
Ce que c'est, précisément
React Email Editor (github.com/unlayer/react-email-editor) est l'enveloppe React officielle de l'éditeur visuel d'e-mails d'Unlayer. Vous affichez un unique composant d'éditeur, en gardez une référence, et travaillez avec les trois méthodes documentées par le README : loadDesign remet à l'écran un modèle enregistré, saveDesign vous rend la maquette en JSON, et exportHtml renvoie du HTML responsive accompagné de ce même JSON. Votre base stocke le JSON pour permettre une modification ultérieure, et le HTML pour que votre chaîne d'envoi ait quelque chose à livrer. Le dépôt existe depuis 2017 et est maintenu sans effort apparent : la version 2.1.2 est sortie le 11 août 2026, et le travail derrière relevait de la vraie correction et non de l'entretien — un défaut d'hydratation au rendu côté serveur et une fuite ancienne où les éditeurs n'étaient jamais détruits au démontage.
La version 2 est une modernisation, et ses propres notes de migration sont d'une franchise inhabituelle : React 16.8 et Node 18 deviennent le plancher, les importations profondes vers l'intérieur du paquet sont bloquées par une carte d'exports, et le code publié est en ES2019 — une chaîne d'outils ancienne incapable de l'analyser doit rester sur la ligne 1.x. Le paquet porte la directive "use client", ce qui permet, avec l'App Router de Next.js, de l'importer directement dans un composant client sans le contournement habituel par import dynamique. La sortie est vérifiée sur Gmail, Apple Mail, Outlook et Yahoo Mail — les quatre clients où le HTML d'e-mail écrit à la main s'effondre le plus souvent.
Composant ouvert, éditeur hébergé : relisez la ligne de licence
Le dépôt est sous MIT et le README le dit sans détour, mais MIT couvre le composant React, pas l'éditeur qu'il charge. Cette forme est courante dans l'outillage pour développeurs et mérite d'être traitée délibérément, car « open source » sur le badge et « open source » dans votre registre des risques répondent à deux questions différentes. Voici ce qui se trouve où.
| Ce que vous obtenez | Où cela réside | Ce que cela implique pour vous |
|---|---|---|
| Le composant React | Votre dépôt, via npm, sous MIT | À vous de le forker, le corriger, l'épingler. Rien ici ne peut vous être retiré. |
| L'interface d'édition, les outils et l'assistant IA | Le service d'Unlayer, chargé à l'exécution et configuré par les options du composant | La capacité de vos utilisateurs à éditer dépend de la disponibilité d'un tiers, et l'étendue des fonctionnalités suit la feuille de route de ce fournisseur, pas votre dépôt. |
| Le HTML exporté et le JSON de maquette | Votre base de données | La partie transportable. Les modèles déjà créés restent les vôtres même si vous changez d'éditeur plus tard. |
| Les traductions de l'interface de l'éditeur | Un dépôt Unlayer distinct qui accepte les pull requests | Vous pouvez contribuer une langue, mais vous la contribuez en amont : vous ne la livrez pas localement. |
Où un éditeur d'e-mails trouve sa place dans la panoplie d'un fondateur
La question à trancher avant d'installer quoi que ce soit est : à qui appartiennent ces e-mails ? Si ce sont vos utilisateurs qui rédigent et envoient des e-mails depuis votre produit — un CRM, un outil de newsletter, un système de réservation dont quelqu'un veut personnaliser les confirmations —, un éditeur intégré devient difficilement évitable, et en construire un représente des mois de travail sans rapport avec la raison pour laquelle on vous a acheté le produit. S'il ne s'agit que de vos e-mails transactionnels et de cycle de vie, vous n'avez besoin d'aucun éditeur visuel : des modèles écrits en code comme React Email demandent moins de travail et se versionnent bien mieux.
- Il résout la production, pas la distribution Un éditeur accélère la création d'e-mails. Il n'a aucun avis sur qui les reçoit, sur la délivrabilité de l'adresse, ni sur le fait que le message valait la peine d'être envoyé.
- Il retire une file d'attente de votre bureau Le vrai gain, quand ce sont vos utilisateurs qui rédigent, c'est que les demandes de modèles cessent d'arriver sous forme de tickets techniques. C'est un argument de charge de support, pas de croissance, et il est parfaitement légitime de l'acheter à ce titre.
- Il ne décide pas des taux d'ouverture La mise en page est la seule partie de la performance e-mail à peu près résolue. L'objet, le moment, la qualité de la liste et la réputation d'expédition ne le sont pas, et aucun de ces éléments n'apparaît dans un éditeur.
- Il ajoute une dépendance à l'exécution Un éditeur hébergé et intégré est un tiers placé sur le chemin critique de votre produit. Acceptable en connaissance de cause, à condition de vérifier que les maquettes enregistrées resteront ouvrables si vous cessez un jour de payer.
Notre propre expérience de l'e-mail chez AgentCeres — le directeur de la croissance par IA, sur agentceres.com — pointe dans la même direction, et les deux choses qui ont compté n'étaient ni la mise en page ni l'outil. La première fut la soustraction : une personne qui s'inscrivait et restait quelques minutes dans le produit pouvait recevoir trois messages presque identiques en cinq minutes environ, dès que la première recherche automatique s'ajoutait au message de bienvenue et à l'annonce d'essai. Nous avons supprimé un e-mail au lieu d'en dessiner un meilleur. La production n'a jamais été la contrainte ; la retenue, si. La seconde fut la langue. Chaque message automatique que nous envoyons existe en versions écrites à la main pour les marchés que nous servons, plutôt qu'en traduction automatique, parce que la version automatique se lisait exactement comme une version automatique — et c'est précisément le travail qu'aucun éditeur par glisser-déposer, si bon soit-il, n'aurait allégé. Choisissez l'éditeur selon les mains qui s'en serviront, puis consacrez le temps gagné à des e-mails de cycle de vie qu'on ait envie de recevoir.
FAQ
- React Email Editor est-il gratuit ?
- Le composant React du dépôt est sous licence MIT et librement utilisable. L'éditeur qu'il intègre est le produit propre d'Unlayer : ses conditions et ses éventuelles limites sont fixées par Unlayer et sont distinctes de la licence du dépôt. Lisez les deux avant de bâtir dessus une fonctionnalité payante.
- En quoi diffère-t-il de React Email ?
- React Email concerne les e-mails que vous écrivez : des composants dans votre code, compilés en HTML, relus en pull request. React Email Editor concerne les e-mails que vos utilisateurs écrivent : une surface visuelle dans votre produit qui renvoie du HTML et un JSON de maquette. Publics différents, et la plupart des produits n'ont besoin que de l'un des deux.
- Fonctionne-t-il avec l'App Router de Next.js ?
- Oui. Le README indique que le paquet publié contient la directive "use client", ce qui permet de l'importer directement depuis un composant client sans contournement par import dynamique. L'éditeur s'affiche toujours dans le DOM et reste donc, par nature, exclusivement côté client.
- Envoie-t-il l'e-mail ?
- Non, et cette frontière mérite de rester nette. Il produit du HTML et un JSON de maquette. L'acheminement, la gestion des listes, les désinscriptions et la réputation d'expéditeur relèvent d'une infrastructure d'envoi — une solution auto-hébergée comme listmonk ou une API d'e-mail —, et ce sont ces éléments qui décident si le message atteint seulement une boîte de réception.
- Qu'est-ce qui casse en passant de la version 1 ?
- L'API du composant est inchangée : la plupart des applications migrent sans toucher au code. Ce sont les prérequis qui ont bougé — React 16.8 et Node 18 au minimum, importations profondes vers l'intérieur du paquet désormais bloquées, et code publié en ES2019. La version 2 détruit également les éditeurs au démontage, ce qui corrige une fuite mais constitue un changement de comportement à connaître si une partie de votre application dépendait de l'ancien cycle de vie.
You built it. Now grow it.
AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $39/month.