Compatibilité des clients de messagerie : quel outil pour un HTML qui s’affiche partout

Pour la plupart des équipes qui envoient des emails HTML, le meilleur point de départ est MJML. C’est un langage de balisage open source qui se compile en tableaux imbriqués et en styles en ligne, la forme que demandent Outlook et Gmail. Il n’a pas de forfait à acheter : vous l’installez et vous l’hébergez vous-même, et le coût réel est le temps d’apprentissage et l’infrastructure de compilation. Si vous préférez ne pas écrire de code, Stripo, BEE ou Unlayer proposent des éditeurs visuels, avec une sortie HTML qu’il faudra relire avant chaque envoi.

Ce guide explique ce qui casse d’un client à l’autre, compare les outils de construction d’emails et les expéditeurs qui les accompagnent, et donne des critères concrets pour choisir. Les prix indiqués proviennent des pages tarifaires publiées par chaque éditeur à la date de vérification mentionnée plus bas. Quand un éditeur ne publie pas de grille chiffrée, nous l’écrivons clairement.

Les clients de messagerie qui comptent vraiment

Un email n’est pas rendu par un navigateur web. Chaque client a son moteur, ses règles de nettoyage du code et ses limites. Avant de choisir un outil, il faut savoir où vos abonnés lisent leurs emails, parce que l’outil doit produire un HTML qui tient dans ces contextes précis.

Outlook de bureau (Windows)

C’est le client le plus contraignant. Les versions 2007 à 2019 utilisent le moteur de rendu de Microsoft Word et non un moteur de navigateur. Cela entraîne plusieurs conséquences concrètes :

• les flottants CSS ne sont pas fiables, la mise en page passe donc par des tableaux ;
• les images de fond posées sur une div ne s’affichent pas, il faut passer par VML ;
• les marges et rembourrages se comportent de façon incohérente selon l’élément ;
• le positionnement CSS est pratiquement inutilisable.

Le nouvel Outlook pour Windows est plus proche d’un moteur web, mais il ne faut pas supposer qu’il se comporte comme Gmail ou Apple Mail. Les deux familles doivent être vérifiées séparément.

Outlook.com et Outlook sur le web

Outlook.com s’appuie sur un rendu de type navigateur, avec un meilleur support CSS que la version de bureau. Il garde pourtant des particularités, notamment sur les images de fond et les règles de nettoyage des balises style. Un correctif validé dans Outlook de bureau ne suffit donc pas à garantir l’affichage ici.

Gmail (web, iOS et Android)

Gmail retire ou réécrit une partie du CSS, surtout les sélecteurs complexes et certaines propriétés. Le support des requêtes média dépend du contexte : l’application mobile est généralement plus fiable que la version web. Gmail bloque aussi les images externes par défaut, ce qui impose un message compréhensible même sans images.

Apple Mail (macOS et iOS)

Apple Mail repose sur WebKit, le moteur de Safari, et supporte la plupart des propriétés CSS modernes, les requêtes média et les images de fond. Si votre audience est majoritairement sur Apple, vous disposez de plus de liberté de mise en page. Il ne faut pas pour autant écrire uniquement pour Apple Mail : les deux autres familles ont un poids qui ne se voit que dans les statistiques de votre propre liste.

Yahoo Mail

Le support est modéré. Yahoo supprime certains styles, mais moins agressivement que Gmail, et accepte les images de fond à condition de prévoir une couleur de repli.

Quel outil pour quel besoin : le comparatif

Le tableau ci-dessous résume le rôle de chaque outil. Les trois premières lignes sont des frameworks ou des éditeurs de construction d’emails. Les deux dernières sont des expéditeurs : ils envoient les emails, et se combinent avec un HTML produit ailleurs.

Ce que fait chaque outil, et où il manque

Chaque section ci-dessous suit le même ordre : ce que l’outil apporte à une équipe qui envoie des emails, ses limites, son prix publié et la page à consulter pour les conditions à jour.

MJML

MJML convient aux équipes qui veulent un HTML compatible sans écrire les tableaux à la main. Vous rédigez des balises sémantiques comme mj-section ou mj-column, et le compilateur produit les tableaux imbriqués et les styles en ligne. Le point fort est la maîtrise : le code est versionné dans votre dépôt, relu comme du code, et reproductible.

Ses limites sont réelles. Il faut un processus de compilation, une habitude de la revue de code et une vérification régulière des cas particuliers d’Outlook. Pour une équipe marketing seule, la mise en place peut être trop lourde. Prix : open source, auto-hébergé, sans forfait éditeur. La page tarifs de MJML donne le cadre à jour.

React Email

React Email permet de construire des templates avec des composants React. C’est intéressant si votre équipe écrit déjà du React : les composants réutilisables, le typage et les tests unitaires du rendu sont des avantages concrets. Le HTML produit reste à inspecter, surtout pour les mises en page complexes dans Outlook.

La limite est évidente pour une équipe sans profil technique : il faut savoir développer. Prix : sur demande. Consultez le site de React Email pour les conditions actuelles.

Maizzle

Maizzle est un framework qui utilise Tailwind pour styliser les emails, puis produit un HTML avec les styles intégrés. Il convient bien aux équipes qui utilisent déjà Tailwind dans leurs interfaces, car le vocabulaire est le même. Il faut toutefois garder à l’esprit que Tailwind n’a pas été conçu pour les emails : certaines classes produisent des styles que les clients ignorent ou suppriment.

Prix : sur demande. Le site de Maizzle indique les conditions actuelles.

Stripo

Stripo est un éditeur visuel par glisser-déposer. Il permet à un marketeur de créer un email sans toucher au code et de l’exporter en HTML. Pour une équipe qui envoie des campagnes fréquentes, c’est le gain de temps le plus visible.

La limite tient à la sortie : le HTML généré doit être relu avant chaque envoi, surtout lorsque les blocs sont imbriqués ou que vous ajoutez du code personnalisé. Prix : sur demande. Le site de Stripo présente les formules disponibles.

BEE

BEE est un éditeur visuel qui peut être intégré dans une application existante. C’est pertinent si vous voulez que vos utilisateurs, ou vos équipes internes, composent leurs emails dans votre propre interface. Vous contrôlez alors les blocs, les couleurs et les règles de marque.

La qualité du rendu dépend du client d’envoi et des blocs choisis. Prix : sur demande. Consultez le site de BEE pour le détail.

Unlayer

Unlayer est un éditeur d’email qui s’intègre dans un produit tiers. Il sert surtout aux éditeurs de logiciels qui veulent offrir un créateur d’emails à leurs clients, sans le développer eux-mêmes. Pour une équipe qui cherche seulement un outil autonome, il est moins direct qu’un éditeur grand public.

Prix : sur demande. Le site d’Unlayer détaille les conditions d’intégration.

Kit

Kit est un expéditeur pour créateurs et petites équipes. Son plan gratuit couvre jusqu’à 10 000 abonnés, avec pages d’inscription, formulaires, diffusions illimitées et segmentation par étiquettes. Les automatisations visuelles et les séquences d’emails commencent avec le plan Creator.

Le plan Creator coûte 33 $ par mois en facturation annuelle, soit 396 $ par an. Le plan Pro, à 66 $ par mois en facturation annuelle, ajoute les signaux d’abonnés, les utilisateurs illimités et le reporting de délivrabilité. Kit propose un essai gratuit de 14 jours sur les formules payantes, sans carte bancaire. Si vous exportez du HTML depuis MJML ou un autre outil, vérifiez avant de vous engager que l’éditeur de Kit accepte l’import de votre code. Consultez la page tarifs de Kit.

Courier

Courier s’adresse aux équipes techniques qui envoient des notifications transactionnelles : confirmations de compte, reçus, alertes. Le plan Developer est gratuit jusqu’à 10 000 envois par mois, avec parcours et diffusions, serveur MCP, CLI et SDK. Le plan Business fonctionne au paiement à l’envoi, à 0,005 $ par envoi. Le plan Enterprise est sur devis, avec remises sur volume.

Courier fonctionne bien avec un HTML produit par MJML, React Email ou Maizzle : votre code rend le message, puis l’API l’envoie. C’est moins adapté aux campagnes marketing qui demandent une gestion fine de la liste et des segments. Consultez la page tarifs de Courier.

Combien coûte l’envoi, selon le volume

Le coût dépend de deux choses : le nombre d’abonnés pour un expéditeur à tarification par abonné, le nombre d’envois pour un expéditeur à tarification à l’envoi. Le tableau suivant utilise uniquement les prix publiés. Quand un palier n’est pas indiqué, le tableau le dit.

Ce qui manque au tableau est important. Un expéditeur qui vous coûte peu à 5 000 abonnés peut coûter beaucoup plus à 50 000, et les frameworks ne facturent rien en eux-mêmes mais demandent du temps de développement. Avant de choisir, calculez le coût sur votre volume réel à douze mois, pas seulement sur le plan d’entrée.

Quel outil choisir selon votre situation

Le bon choix dépend moins de la liste de fonctionnalités que de qui écrit et qui relit les emails. Le tableau de décision suivant part de situations concrètes.

Les propriétés CSS à utiliser, et celles à éviter

Un framework ne vous dispense pas de connaître les propriétés sûres. Il vous permet seulement de les appliquer de façon systématique. Voici la répartition de base.

Sûres dans la plupart des clients

/* Fiables dans les principaux clients */
color: #333333;
font-family: Arial, sans-serif;
font-size: 16px;
font-weight: bold;
line-height: 1.5;
text-align: center;
text-decoration: none;
background-color: #ffffff;
border: 1px solid #cccccc;
padding: 10px; /* sur les cellules de tableau */
width: 100%;
max-width: 600px;

Support partiel, à tester

/* Fonctionnent dans la plupart des clients, problèmes dans Outlook */
border-radius: 4px; /* absent dans Outlook de bureau */
background-image: url(...); /* prévoir VML pour Outlook */
box-shadow: ...; /* support limité */
margin: 10px; /* incohérent dans Outlook */

À éviter ou à utiliser avec précaution

/* Source de problèmes fréquents */
display: flex; /* support faible dans les emails */
display: grid; /* support faible dans les emails */
position: absolute/relative; /* très limité */
float: left/right; /* problèmes dans Outlook */
transform: ...; /* support limité */
animation: ...; /* Apple Mail seulement */

Quand vous utilisez MJML, React Email ou Maizzle, ces règles sont appliquées par le compilateur, mais elles restent utiles pour lire le résultat et repérer ce qui sera ignoré.

Techniques de mise en page qui tiennent

Les tableaux pour la structure

Les tableaux restent la base fiable. Chaque bloc est un tableau, chaque colonne une cellule, et la largeur est fixée en attribut plutôt qu’en CSS seul :

<table role="presentation" width="100%" cellpadding="0" cellspacing="0">
  <tr>
    <td align="center" style="padding: 20px;">
      <table width="600" cellpadding="0" cellspacing="0">
        <tr>
          <td>Contenu ici</td>
        </tr>
      </table>
    </td>
  </tr>
</table>

Commentaires conditionnels pour Outlook

Un commentaire conditionnel permet de n’envoyer un bloc qu’à Outlook de bureau. C’est l’un des rares moyens de corriger un rendu sans toucher aux autres clients :

<!--[if mso]>
  <!-- Code réservé à Outlook -->
  <table width="600"><tr><td>
<![endif]-->

  <div style="max-width: 600px;">
    Contenu pour tous les clients
  </div>

<!--[if mso]>
  </td></tr></table>
<![endif]-->

VML pour les images de fond dans Outlook

Une image de fond sur une section ne s’affiche pas dans Outlook de bureau sans VML. Le bloc suivant prévoit la version Outlook et laisse les autres clients utiliser le CSS :

<!--[if gte mso 9]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width:600px;height:300px;">
<v:fill type="tile" src="background.jpg" color="#ffffff" />
<v:textbox inset="0,0,0,0">
<![endif]-->

<div style="background-image: url(background.jpg); background-color: #ffffff;">
  Contenu ici
</div>

<!--[if gte mso 9]>
</v:textbox>
</v:rect>
<![endif]-->

Si votre framework génère ce bloc, relisez-le une fois pour vérifier la largeur et la hauteur de la zone, car elles doivent correspondre au bloc visible.

Images, polices et requêtes média

Les images

Une image doit toujours indiquer ses dimensions, car Outlook en a besoin pour réserver l’espace. L’espace sous une image est supprimé avec display: block, la mise à l’échelle se fait avec max-width: 100%, et la bordure des images liées est retirée avec border: 0.

<img
  src="https://example.com/image.jpg"
  alt="Description de l’image"
  width="600"
  height="300"
  style="display: block; max-width: 100%; height: auto; border: 0;"
>

• JPG : photos et images complexes
• PNG : transparence et graphiques simples
• GIF : animation, avec modération (poids et lisibilité)
• SVG : support limité, à éviter dans les emails
• WebP : non pris en charge par Outlook de bureau

Le texte alternatif reste essentiel, car Gmail bloque les images externes par défaut. Un email doit rester compréhensible sans image.

Les polices

Les polices web-sûres sont la solution simple : Arial, Georgia, Courier New. Une police web personnalisée ne fonctionne que dans certains clients, notamment Apple Mail et une partie des clients Android. Prévoyez toujours une police de repli :

<p style="font-family: 'Open Sans', Arial, sans-serif;">
  Texte avec police personnalisée
</p>

Outlook et Gmail utiliseront la police de repli. Le message reste lisible, et c’est le point qui compte.

Les requêtes média

Les requêtes média adaptent le gabarit aux petits écrans, mais leur support est inégal. Apple Mail et iOS Mail les appliquent bien, l’application Gmail sur mobile aussi, Gmail web de façon limitée, et Outlook de bureau pas du tout. Concevez donc une version mobile lisible par défaut, puis ajoutez les requêtes média comme amélioration. Ne cachez jamais un élément important uniquement avec display: none.

Migrer un gabarit existant vers un outil

Migrer un gabarit ne consiste pas à copier le HTML dans un nouvel éditeur. Les éditeurs visuels réécrivent souvent la structure, et un ancien gabarit peut contenir des contournements devenus inutiles ou, au contraire, indispensables. La check-list suivante évite les mauvaises surprises.

Stratégie de test avant chaque envoi

Un test efficace suit un ordre précis, car les clients les plus contraignants révèlent les problèmes les plus vite :

1. Outlook de bureau en premier. S’il tient ici, il tient souvent partout. Ce n’est pas une garantie, mais c’est le test le plus sélectif.
2. Gmail, web et mobile. La suppression de CSS et les requêtes média s’y voient immédiatement.
3. Apple Mail sur iPhone. Vérifiez les tailles de police, les marges et la largeur des images.
4. Sans images. Désactivez-les et relisez : le message doit tenir debout, avec les boutons et les liens visibles.

Les outils de prévisualisation multi-clients sont utiles pour gagner du temps, mais ils ne remplacent pas un envoi de test à une adresse réelle de chaque famille de clients.

Erreurs de workflow à éviter

Le problème le plus fréquent n’est pas technique, il est organisationnel. Un HTML généré par un framework est modifié à la main dans l’éditeur de l’expéditeur, puis personne ne sait plus quelle version est la bonne. Décidez d’une seule source : soit le code versionné, soit l’éditeur visuel, jamais les deux à la fois.

La deuxième erreur est de tester une version de bureau sur un écran de bureau et de considérer le travail terminé. Le rendu mobile et les clients web ont leur propre logique. La troisième est de négliger le texte brut : sans version texte, les filtres de spam et les lecteurs d’écran sont moins bien servis, et le message perd en clarté.

Le mot de la fin

La compatibilité des clients de messagerie reste exigeante, mais elle se maîtrise avec des règles simples : mise en page par tableaux, styles en ligne, polices web-sûres avec repli, images décrites et envoi test dans Outlook avant tout. L’outil ne fait que répartir le travail. MJML est le meilleur point de départ pour une équipe qui code, React Email et Maizzle conviennent aux équipes déjà outillées autour de React ou Tailwind, Stripo, BEE et Unlayer répondent à des besoins d’édition visuelle, et Kit et Courier se choisissent selon que vous envoyez des campagnes ou des notifications.

Questions fréquentes

Quel est le meilleur outil pour un HTML compatible avec Outlook ?

MJML est le choix le plus direct pour une équipe qui code, parce qu’il compile en tableaux imbriqués et en styles en ligne. Sans compétence de développement, un éditeur visuel comme Stripo ou BEE est plus accessible, à condition de relire le HTML généré et de tester dans Outlook de bureau.

MJML est-il vraiment gratuit ?

MJML est open source et s’installe sur votre propre infrastructure. Il n’y a pas de forfait à payer à l’éditeur pour l’utiliser, mais le temps de mise en place et l’hébergement de la compilation sont à votre charge. La page tarifs de MJML donne le cadre à jour.

Peut-on utiliser React Email avec un expéditeur comme Courier ?

Oui, dans le principe : vous générez le HTML à partir de vos composants React, puis vous l’envoyez via l’API de l’expéditeur. Vérifiez avant tout que votre expéditeur accepte un HTML fourni par l’application et qu’il ne réécrit pas le code à l’envoi.

À partir de quel volume Kit devient-il coûteux ?

Le plan gratuit couvre jusqu’à 10 000 abonnés. Au-delà, le tarif dépend du nombre d’abonnés, et la grille n’est pas reproduite ici. Le plan Creator coûte 33 $ par mois en facturation annuelle, soit 396 $ par an, pour les automatisations. Consultez la page tarifs de Kit pour votre volume exact.

Combien coûte Courier pour 25 000 envois par mois ?

Au tarif Business de 0,005 $ par envoi, 25 000 envois donnent 125 $ par mois, si le tarif s’applique à l’ensemble des envois. Le plan Developer est gratuit jusqu’à 10 000 envois par mois. Vérifiez la modalité exacte sur la page tarifs de Courier avant de chiffrer un budget.

Dois-je écrire une version texte de chaque email ?

Oui. Une version en texte brut améliore la lisibilité pour les lecteurs d’écran et les clients qui n’affichent pas le HTML, et elle donne au message une structure que le filtre anti-spam peut lire. Les outils de construction d’emails la génèrent souvent, mais il faut la relire.

Les requêtes média fonctionnent-elles dans Outlook ?

Non, pas dans Outlook de bureau. Concevez le gabarit pour être lisible sur mobile sans requête média, puis ajoutez les règles pour Apple Mail, iOS Mail et l’application Gmail. Ne cachez pas d’information importante avec display: none.

Faut-il migrer tous les gabarits d’un coup ?

Non. Reconstruisez un gabarit de référence, vérifiez-le dans les trois grandes familles de clients, puis migrez les autres un par un. Gardez l’ancien gabarit actif quelques semaines pour comparer les résultats.