Constructeurs d’emails HTML : le guide 2026 pour choisir entre code, éditeur visuel et intégration

Pour une équipe marketing qui n’a pas de développeur sous la main, Stripo reste le point de départ le plus direct : son offre gratuite n’a pas de limite de durée, et le plan Basic coûte 20 $ par mois. On assemble des blocs, on enregistre un gabarit et on exporte un HTML sans écrire une ligne de code. Si vos templates vivent dans un dépôt Git et sont relus par des développeurs, MJML ou Maizzle conviennent mieux, à condition d’avoir quelqu’un à l’aise avec un processus de compilation.

Ce guide compare les constructeurs les plus utilisés en 2026 selon trois usages : écrire le HTML en code, éditer visuellement, ou intégrer un éditeur dans son propre produit. Pour chaque outil, vous trouverez le public qu’il sert le mieux, ce qu’il fait bien, ce qui le limite et le prix publié sur sa page officielle. Les prix sont ceux affichés sur les pages tarifaires consultées le 7 octobre 2026, en dollars américains, hors taxes locales. Aucun classement par notes n’est proposé : le bon outil dépend surtout de la personne qui modifiera l’email chaque semaine.

Pourquoi l’email HTML se comporte différemment

Un navigateur web suit à peu près les mêmes règles de rendu d’une version à l’autre. Les clients email, eux, n’ont pas de moteur commun. Certains reprennent le moteur de rendu de Word, d’autres suppriment une partie du CSS placé dans l’en-tête du document, et les applications mobiles ajoutent leurs propres exceptions. Un même fichier peut être impeccable dans un client et casser dans un autre sans qu’aucune erreur ne soit signalée.

Cela change la manière d’écrire un email. Plusieurs contraintes reviennent dans presque tous les projets :

• Flexbox et Grid ne sont pas fiables dans tous les clients, si bien que les tables restent la base de la mise en page la plus sûre.
• Le CSS en ligne, appliqué directement sur chaque élément, résiste mieux que les feuilles de style externes.
• Les media queries servent à l’affichage mobile, mais certains clients les ignorent complètement.
• Le mode sombre modifie les couleurs de façon parfois imprévisible, surtout sur les images avec fond transparent.
• Les images peuvent être bloquées par défaut, ce qui oblige à soigner le texte de remplacement et les boutons en texte.

Un constructeur sert à absorber cette complexité. Il produit un HTML qui a déjà été mis en forme pour ces contraintes. Il ne supprime pas la nécessité de relire le résultat : il réduit le nombre de corrections manuelles à faire après coup, et il donne une base commune à toute l’équipe.

Trois familles de constructeurs

Le choix de la famille compte davantage que celui de la marque. Il détermine qui peut modifier un email, comment on le versionne, et ce qui se passe quand le fournisseur change ses conditions.

• Frameworks de code : on écrit du balisage ou des composants, puis on compile en HTML compatible. Les templates vivent dans un dépôt et passent par la revue de code.
• Éditeurs visuels : on glisse des blocs dans une interface et l’outil génère le HTML. Les non-développeurs peuvent travailler seuls, mais le code exporté reste celui de l’éditeur.
• Éditeurs intégrables : un SDK ajoute l’éditeur à votre application, pour que vos propres utilisateurs créent leurs emails et que le HTML revienne dans votre base.

Frameworks de code

MJML

MJML utilise un balisage de type XML, avec des composants comme mj-section, mj-column ou mj-text. Le compilateur transforme ces balises en tables HTML compatibles avec les clients les plus courants. C’est l’un des choix habituels des équipes techniques qui veulent des emails lisibles dans un dépôt et relus comme du code.

<mjml>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-text>Votre contenu ici</mj-text>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Ce qu’il fait bien : le code reste court, les composants sont cohérents et la sortie est prévisible. Une modification dans le fichier source se retrouve dans le HTML généré, ce qui rend la revue entre collègues simple, avec des différences lisibles ligne par ligne.

Où il montre ses limites : il n’existe pas d’éditeur visuel. Un responsable marketing qui veut remplacer une image doit passer par un développeur ou apprendre la syntaxe. La compilation doit en outre être intégrée à votre chaîne de build ou à votre processus d’envoi, ce qui suppose un peu d’outillage.

Prix : MJML est un outil auto-hébergé. Le coût réel se situe dans le temps de développement et dans l’infrastructure de build, et non dans un abonnement. Consulter la page tarifaire de MJML.

React Email

React Email permet de construire les emails comme des composants React. Si votre application est déjà écrite en React, les templates rejoignent la bibliothèque de composants : on réutilise les boutons, les en-têtes et les mises en forme, et les props déterminent le contenu affiché.

Ce qu’il fait bien : l’équipe produit et l’équipe email parlent le même langage, et les données dynamiques, comme le prénom d’un client ou le montant d’une facture, s’insèrent naturellement dans le composant. Les templates peuvent être couverts par les mêmes tests que le reste de l’application.

Où il montre ses limites : il suppose une stack React. Une équipe marketing qui n’écrit pas de React ne peut pas modifier un template seule. Le rendu final dépend aussi de la façon dont le composant est écrit, ce qui oblige à relire le HTML produit avant chaque envoi.

Prix : le tarif n’est pas repris dans ce guide, faute de grille vérifiée. Consultez la documentation officielle du projet pour connaître les conditions d’usage avant de l’intégrer.

Maizzle

Maizzle apporte Tailwind CSS à l’email. On écrit des classes utilitaires familières, et le framework se charge de l’intégration du CSS dans le HTML et de certaines transformations nécessaires aux clients. Pour une équipe qui écrit déjà ses interfaces web avec Tailwind, la courbe d’apprentissage reste faible.

Ce qu’il fait bien : le style des emails reste cohérent avec le site ou l’application, et les variables partagées évitent de répéter les couleurs et les polices dans chaque fichier. Les gabarits sont organisés en composants réutilisables.

Où il montre ses limites : il faut configurer le build, et le résultat doit être vérifié comme pour tout framework. Les personnes non techniques ne peuvent pas modifier les gabarits sans formation, et les erreurs de configuration se voient surtout au moment de l’envoi de test.

Prix : Maizzle est auto-hébergé. Consulter la page tarifaire de Maizzle.

Idéal pour : les équipes où des développeurs maintiennent les templates, les applications qui génèrent des emails de façon programmatique, et les projets qui ont besoin de revue de code et d’historique de versions.

Éditeurs visuels

Les éditeurs visuels permettent aux responsables marketing de créer et de modifier des emails sans passer par un développeur. Ils proposent des blocs déjà prévus pour les clients courants. Le compromis est simple : on gagne en autonomie et en rapidité, on perd une partie du contrôle sur le code généré.

Stripo

Stripo est souvent le premier éditeur visuel essayé. Son offre gratuite n’a pas de limite de durée. Les plans d’abonnement sont Basic à 20 $ par mois, Medium à 45 $ par mois et Pro à 125 $ par mois. Stripo propose aussi un plugin pour intégrer l’éditeur dans une plateforme existante : Plugin Free sans frais, Startup à 100 $ par mois, Business à 550 $ par mois, et une offre Enterprise sur demande.

Ce qu’il fait bien : la bibliothèque de blocs et de gabarits permet de produire une newsletter complète dans une même session de travail. Les équipes sans développeur peuvent travailler seules, et l’export HTML se récupère pour l’envoyer depuis une autre plateforme d’envoi.

Où il montre ses limites : les fonctions diffèrent selon le plan, et une équipe qui passe de l’offre gratuite au plan Basic doit vérifier précisément ce qu’elle gagne. Le code exporté est lisible mais généré : une correction importante se fait dans l’éditeur, et non directement dans le fichier, sinon elle sera écrasée au prochain export.

Prix : offre gratuite sans limite de durée, Basic 20 $ par mois, Medium 45 $ par mois, Pro 125 $ par mois. Consulter la page tarifaire de Stripo.

BEE Free

BEE Free est l’éditeur visuel de la famille BEE, proposé dans une version gratuite. Il convient aux équipes qui veulent tester une mise en page avant de payer, ou qui envoient un volume modeste d’emails.

Ce qu’il fait bien : l’interface est directe et la mise en forme par blocs suffit pour des newsletters simples. Un responsable marketing peut produire un gabarit de base en une session, sans formation particulière.

Où il montre ses limites : comme pour tout éditeur visuel, le contrôle fin du code est limité. Pour les mises en page complexes, les limites apparaissent vite, et le rendu doit être vérifié dans les clients réellement utilisés par votre audience.

Prix : version gratuite. Les conditions détaillées ne sont pas reprises dans ce guide ; consultez le site officiel de BEE avant de vous engager sur une fonction payante.

Postcards

Postcards, édité par Designmodo, combine un éditeur visuel, des fonctions d’assistance par IA et des outils de partage pour l’équipe. Son plan Start est gratuit : 10 projets de gabarits, 5 exports par mois, 10 emails de test par jour, des membres d’équipe illimités, et un accès à l’API et au serveur MCP.

Les plans payants sont facturés par mois. Le plan Plus à 16 $ par mois ajoute des projets illimités, 20 exports mensuels et 5 exports quotidiens, 5 000 crédits IA par mois, 20 aperçus de clients email par mois et un membre d’équipe inclus. Le plan Pro à 24 $ par mois propose des exports illimités, 10 000 crédits IA par mois, 50 aperçus par mois, trois membres d’équipe, l’hébergement d’images avec CDN et le SSO. La page tarifaire comporte un sélecteur entre facturation mensuelle et annuelle.

Ce qu’il fait bien : le plan gratuit est assez large pour un premier projet, et les membres d’équipe illimités facilitent la collaboration sur les gabarits sans payer de siège supplémentaire.

Où il montre ses limites : le plan Start limite les exports et les tests quotidiens. Une équipe qui envoie chaque jour doit prévoir le passage au plan Plus, et les crédits IA ne s’utilisent que dans les plans payants.

Prix : Start gratuit, Plus 16 $ par mois, Pro 24 $ par mois. Consulter la page tarifaire de Postcards.

Éditeurs intégrables

Si votre produit doit permettre à vos clients de créer leurs propres emails, qu’il s’agisse d’une plateforme marketing, d’un CRM ou d’un outil de newsletter, vous avez besoin d’un éditeur que vous intégrez à votre application. Ces outils sont fournis sous forme de SDK. Vos utilisateurs voient l’éditeur dans votre interface, et le HTML revient dans votre propre base de données.

import EmailEditor from 'react-email-editor';

function MyBuilder() {
  const editorRef = useRef(null);

  const exportHtml = () => {
    editorRef.current.editor.exportHtml((data) => {
      // Enregistrer le HTML dans votre base
    });
  };

  return <EmailEditor ref={editorRef} />;
}

Unlayer

Unlayer est conçu pour être intégré dans un produit. Il existe une offre gratuite, et le premier palier payant est à 250 $ par mois, avec 1 TB de bande passante incluse. Les paliers suivants sont à 750 $ par mois et à 2 000 $ par mois, ce dernier donnant accès à l’ensemble des crédits complémentaires. La page tarifaire indique les mêmes montants en facturation mensuelle et annuelle.

Ce qu’il fait bien : le SDK s’ajoute à une application React ou à une page web, et l’export HTML se récupère directement dans votre code. Les blocs personnalisés permettent de respecter l’identité visuelle de chaque client de votre plateforme.

Où il montre ses limites : le coût ne se justifie que si vous offrez réellement la création d’emails à vos utilisateurs. Pour une personne qui travaille seule sur ses newsletters, un éditeur visuel autonome revient bien moins cher. Il faut aussi prévoir le temps d’intégration et la maintenance du SDK dans votre application.

Prix : offre gratuite, puis 250 $ par mois, 750 $ par mois et 2 000 $ par mois selon le palier. Consulter la page tarifaire d’Unlayer.

Chamaileon

Chamaileon s’adresse aux organisations qui veulent un système de design pour leurs emails, avec un accompagnement au lancement. Le tarif de départ publié est de 400 $ par mois, indiqué en facturation annuelle. La formule inclut un onboarding et une formation, la mise en place d’un système de design email et un support 24/7/365.

Ce qu’il fait bien : il convient aux équipes qui gèrent plusieurs marques, plusieurs rédacteurs et des règles graphiques strictes. Le système de design limite les écarts entre les emails produits par des personnes différentes.

Où il montre ses limites : aucun plan gratuit n’est listé, et le seuil d’entrée est élevé pour une petite équipe. Il vaut mieux l’évaluer lorsque le coût d’un email défectueux est déjà important pour l’entreprise.

Prix : 400 $ par mois au tarif de départ publié. Consulter la page tarifaire de Chamaileon.

Tester le rendu avec Email on Acid

Email on Acid n’est pas un constructeur. C’est un service de tests de rendu qui montre comment un email s’affiche dans une liste de clients et d’appareils. On l’utilise après la construction, quel que soit l’outil choisi, et il ne remplace ni le gabarit ni le code.

Le plan Basic est à 99 $ par mois, avec 1 000 aperçus par mois sur plus de 100 clients et appareils, et un accès API. Le plan Premium est à 199 $ par mois, avec 2 000 aperçus par mois, des tests d’accessibilité et une analyse du HTML. Consulter la page tarifaire d’Email on Acid.

Pour une petite équipe, un contrôle manuel sur les clients principaux de votre audience peut suffire pendant les premiers mois. Le service devient utile quand le volume d’envois augmente, ou lorsque plusieurs personnes doivent valider chaque envoi avant sa sortie.

Comparatif des outils

Le tableau suivant résume, pour chaque outil, le public qu’il sert le mieux, son prix d’entrée et sa limite principale. Il ne classe pas les outils : une équipe technique et une équipe marketing n’ont pas besoin de la même chose.

Ce que coûtent ces outils selon votre situation

Les prix ci-dessous sont donnés pour le plan cité, en dollars américains, à la date de consultation du 7 octobre 2026. Ces outils ne tarifient pas la taille de votre liste de contacts : la question utile est donc le nombre de personnes qui travaillent sur les emails, le volume d’exports ou d’aperçus, et la nécessité d’une intégration. Le coût de la plateforme d’envoi, qui facture les envois eux-mêmes, se calcule séparément et n’est pas repris ici.

Ce tableau montre un point simple : pour un petit volume, le plan gratuit ou le premier palier payant suffit souvent, alors que l’intégration dans un produit change tout le calcul. Si un outil gratuit ne couvre pas votre besoin, comparez le prix du palier suivant avec le temps que vous consacreriez à corriger un HTML écrit à la main. Dans bien des cas, le coût caché des corrections dépasse la différence de prix.

Comment choisir selon votre équipe

Le bon outil dépend moins de la liste de fonctions que de la personne qui modifiera l’email après la mise en place. Trois questions aident à trancher : qui modifiera le gabarit la semaine prochaine, combien de personnes doivent valider un envoi, et quel sera le coût de la prochaine étape quand le plan actuel ne suffira plus.

Le tableau de décision ci-dessous part de ces situations. Il indique l’outil le plus probable et la raison principale, sans prétendre couvrir tous les cas.

Quand deux solutions semblent équivalentes, regardez la personne qui gère le processus au quotidien. Un outil que personne n’ose modifier finit par figer les emails, quelles que soient ses qualités techniques. Un outil trop simple pour l’équipe technique pousse en revanche à contourner le système avec des copies de HTML qui n’ont plus de propriétaire.

Relier le constructeur à votre plateforme d’envoi

Un constructeur ne sert à rien s’il ne s’articule pas avec la plateforme qui envoie réellement les emails. Trois schémas se rencontrent souvent. Le premier consiste à exporter le HTML depuis l’éditeur puis à le coller dans l’outil d’envoi, ce qui fonctionne pour une newsletter ponctuelle mais multiplie les allers-retours. Le deuxième passe par une API : le gabarit est récupéré ou généré au moment de l’envoi, avec les variables du destinataire. Le troisième fait du constructeur une partie de l’application, comme avec un éditeur intégrable.

Quel que soit le schéma, vérifiez deux points avant de vous engager : le format des variables dynamiques (prénom, identifiant de commande, lien de désinscription) doit être identique dans le constructeur et dans la plateforme d’envoi, et le lien de désinscription doit rester présent dans chaque gabarit exporté. Un oubli sur ce point est plus fréquent qu’on ne le pense quand un gabarit est repris d’un ancien outil.

Mise en place et migration

Qu’il s’agisse d’un premier outil ou d’un changement, la migration se fait en étapes. Le tableau suivant sert de checklist. Chaque étape doit être validée avant de passer à la suivante.

Gardez toujours une copie du HTML final, même si vous travaillez dans un éditeur visuel. Si l’éditeur change de tarif, retire une fonction ou modifie son export, vous conservez la maîtrise de vos gabarits. Les frameworks de code offrent le même avantage, puisque le fichier source reste dans votre dépôt.

Pour un premier pilote, deux semaines suffisent. Choisissez un gabarit représentatif, reconstruisez-le dans deux outils candidats au maximum, faites-le passer dans vos clients principaux et notez le temps passé ainsi que les corrections nécessaires. Ne comparez pas plus de trois outils à la fois : chaque outil ajouté multiplie les vérifications sans rendre la décision beaucoup plus claire.

Tester le rendu sur les clients clés

Quel que soit le constructeur, le test sur les clients de votre audience reste obligatoire. Les clients à vérifier en priorité sont généralement les suivants :

• Gmail, sur le web et sur mobile
• Outlook, dans les versions utilisées par votre public professionnel
• Apple Mail, sur macOS et iOS
• Yahoo Mail
• Outlook.com et Hotmail

La plupart des constructeurs produisent un HTML fiable pour ces clients. Les cas limites apparaissent surtout dans les anciennes versions d’Outlook, quand les images sont désactivées et en mode sombre. Vérifiez aussi le texte de remplacement et le contraste des boutons, car ils comptent pour l’accessibilité autant que pour le rendu.

Le bilan

Choisissez en fonction de votre situation réelle :

• Développeurs qui veulent du contrôle et de la revue de code : MJML, React Email ou Maizzle
• Marketing qui publie seul : Stripo, BEE Free ou Postcards
• Produit qui offre l’édition d’emails à ses utilisateurs : Unlayer ou Chamaileon
• Validation de rendu avant les envois importants : Email on Acid, en complément d’un des outils ci-dessus

Le pire choix reste la paralysie par l’analyse. Choisissez un outil raisonnable, construisez un gabarit réel, vérifiez le rendu et ajustez. La plupart des outils produisent un HTML correct : les différences se situent dans le workflow, dans l’intégration et dans le coût du palier suivant.

Questions fréquentes

Quel outil choisir si je n’ai pas de développeur ?

Stripo est le point de départ le plus simple : son offre gratuite n’a pas de limite de durée, et le plan Basic est à 20 $ par mois. Postcards est une alternative si vous voulez un plan gratuit avec des membres d’équipe illimités, mais ses exports mensuels sont limités dans ce plan.

Un constructeur d’emails dispense-t-il de tester le rendu ?

Non. Un constructeur produit un HTML conçu pour les contraintes des clients email, mais il ne remplace pas une vérification dans les clients de votre audience. Si votre équipe ne peut pas tout contrôler, Email on Acid peut compléter le travail, à partir de 99 $ par mois dans son plan Basic.

Faut-il payer pour utiliser MJML ou Maizzle ?

Les deux outils sont auto-hébergés et ne proposent pas d’abonnement à proprement parler. Le coût réel se trouve dans le temps de développement, l’infrastructure de build et la maintenance des templates. Vérifiez les conditions d’usage sur la documentation officielle avant de les intégrer à un produit commercial.

Les prix dépendent-ils du nombre de contacts de ma liste ?

Pour les outils de ce guide, non. Les tarifs cités dépendent des plans, des exports, des aperçus, des crédits IA, des membres d’équipe ou de la bande passante. Le nombre de contacts et le volume d’envois relèvent de votre plateforme d’envoi, qui facture à part.

Peut-on passer d’un éditeur visuel à un framework de code ?

Oui, à condition d’exporter le HTML de chaque gabarit actif et de le reconstruire dans le framework. Le HTML exporté sert de référence pour vérifier que la version en code produit le même rendu. Le plus gros du travail porte sur la recréation des blocs réutilisés.

Combien de temps prend un pilote ?

Deux semaines suffisent pour comparer deux outils sur un gabarit représentatif. La première semaine sert à construire et à contrôler le rendu, la seconde à mesurer le temps passé et les corrections nécessaires. Décidez ensuite sur des éléments écrits : rendu, accessibilité, coût du palier suivant et plan de retour.

Comment vérifier les prix avant de m’engager ?

Consultez la page tarifaire officielle du fournisseur, car les prix évoluent et peuvent varier selon la facturation mensuelle ou annuelle. Les montants de ce guide sont ceux affichés le 7 octobre 2026, en dollars américains, hors taxes locales.

Faut-il conserver les anciens gabarits après une migration ?

Oui, pendant au moins un cycle complet d’envois. Conservez le HTML exporté et la version précédente de chaque gabarit, avec la date de la dernière modification et le nom de la personne qui l’a validée. Si une erreur apparaît après la bascule, vous pouvez restaurer l’ancien fichier sans reconstruire le gabarit dans l’urgence.