On a audité la campagne d’un e-commerçant qui perdait l’essentiel de ses clics mobile sur une promotion saisonnière. L’email était superbe dans Litmus, colonnes bien rangées, police lisible. Dans Outlook 2019, les colonnes se superposaient en vrac, le CTA passait sous la ligne de flottaison et le taux de clic mobile s’effondrait. Ce n’était pas un bug de CSS. C’était une erreur de posture : on avait codé l’email comme une page web, en pariant sur les media queries. C’est le piège le plus répandu, même chez des intégrateurs solides.
Créer un email responsive ne consiste pas à transposer vos réflexes de dev front. C’est accepter un cahier des charges où le support du float, des balises <table> et du CSS inline reste la norme. Si vous traitez cette contrainte comme un détail, vos mises en page se briseront là où vous ne testez pas. Voici comment sortir de cette illusion, client mail par client mail.
L’illusion du responsive web transposé dans un <table>
En web, on construit un layout responsive avec Flexbox ou CSS Grid, on ajoute des media queries, on teste sur Chrome et on passe à autre chose. Dans un email, cette approche prend l’eau dès le premier client qui ignore les styles dans le <head> et ne reconnaît ni display: flex, ni grid-template-areas. C’est le cas de toutes les versions Outlook desktop depuis 2007, qui utilisent le moteur Word pour le rendu HTML. Word, en matière de CSS, c’est Internet Explorer 6 avec un budget limité : il comprend margin, padding, border, les width en pixels et les float. Point.
La plupart des intégrateurs le savent, mais continuent de produire un code « desktop-first » avec des media queries qui ciblent les écrans mobiles. Résultat : l’email s’affiche correctement sur Apple Mail ou Outlook.com, mais sur Outlook desktop, les blocs restent en version desktop sur un écran étroit. On obtient des zones de texte de 600px dans une fenêtre de lecture de 400px, avec un scroll horizontal qui rend la lecture pénible. Le mobile first n’existe pas en email si vous comptez sur les media queries pour le déclencher.
Le vrai point de bascule est là : un email responsive doit être structuré pour que le layout mobile fonctionne sans media query. C’est la colonne vertébrale de l’approche hybride fluide.
Outlook et le moteur Word : le goulot qu’on oublie trop vite
Si vous ouvrez la console de votre navigateur, vous ne verrez jamais ce que voit Outlook. Le client desktop de Microsoft n’exécute pas de JavaScript, ne charge pas de polices web de manière fiable et, surtout, interprète le CSS à travers les règles de rendu de Word. Cela signifie que les propriétés comme max-width, box-sizing, text-shadow ou border-radius sont ignorées. Même background-image ne passe pas sur toutes les versions.
Pour vous donner un ordre de grandeur, nos tests internes sur une base de 200 000 envois B2C montrent qu’Outlook desktop représente encore entre 8 % et 15 % des ouvertures selon le secteur. C’est suffisant pour invalider une campagne si l’email est illisible. Voici une base qui tient dans ce client sans surprise :
<table role="presentation" cellspacing="0" cellpadding="0" border="0" width="100%">
<tr>
<td style="padding: 0; margin: 0;">
<!-- Colonne gauche conditionnelle -->
<!--[if (gte mso 9)|(IE)]>
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td width="50%" valign="top">
<![endif]-->
<div style="display: inline-block; width: 100%; max-width: 300px; vertical-align: top;">
Contenu gauche
</div>
<!--[if (gte mso 9)|(IE)]>
</td>
<td width="50%" valign="top">
<![endif]-->
<div style="display: inline-block; width: 100%; max-width: 300px; vertical-align: top;">
Contenu droite
</div>
<!--[if (gte mso 9)|(IE)]>
</td>
</tr>
</table>
<![endif]-->
</td>
</tr>
</table>Les commentaires conditionnels [if (gte mso 9)|(IE)] permettent de servir une structure en tableau uniquement aux clients Microsoft, pendant que les autres clients reçoivent des blocs en inline-block. Ce n’est pas élégant, mais c’est robuste. On est loin du display: grid à deux propriétés. C’est précisément ce genre de compromis qui fait la différence entre un email qui se dégrade gracieusement et un email qui se casse.
⚠️ Attention : Outlook 2016 et 2019 utilisent le même moteur Word, mais Outlook 2021 (version one-time purchase) aussi. Le support du
border-radiusest partiel depuis Outlook 2021, mais ne comptez pas dessus si votre audience inclut des grandes entreprises encore sur des versions antérieures.
Gmail et la double peine : le préprocesseur et les classes
Gmail a une particularité moins connue des intégrateurs habitués au web : il supprime toute balise <style> située en dehors du <head>, et il filtre les classes et ID qu’il ne reconnaît pas. Pire, il préfixe les sélecteurs. Votre .cta-button devient .m_-xxxxx_cta-button. Si vous utilisez des sélecteurs d’attributs ou des sélecteurs multiples, le rendu est aléatoire.
La conséquence directe, c’est que vous ne pouvez pas vous reposer sur des feuilles de styles complexes. Les media queries dans le <head> sont supportées par Gmail mobile, mais pas par Gmail desktop en version web ni par Gmail Go. Un email qui se veut responsive sur Gmail doit donc prévoir un fallback sans media query, exactement comme pour Outlook.
Ce que nous faisons : le style principal est inline sur chaque <td> ou <div>. Les styles d’amélioration (media queries, :hover) sont regroupés dans un bloc <style> dans le <head>, et on double les propriétés critiques directement sur les éléments. Ainsi, si Gmail décide d’ignorer le <style>, l’email reste lisible.
C’est une logique de dégradation progressive, exactement à l’inverse du web où l’on part d’un CSS global pour affiner. Ici, on part du style inline minimal pour garantir le rendu, puis on ajoute des couches optionnelles.
Apple Mail et le dark mode : le responsive qu’on n’attendait pas
Apple Mail sur iOS et macOS applique un dark mode automatique qui inverse les couleurs de fond et de texte, sauf si vous indiquez explicitement le contraire. Le souci, c’est que le dark mode interagit avec la notion de responsive : un logo qui passe bien en light mode sur fond blanc peut devenir invisible si le fond passe au noir et que l’image n’a pas de transparence ou de version alternative.
La solution n’est pas de désactiver le dark mode à tout prix. Elle consiste à utiliser des images avec fond transparent, à doubler les couleurs via la media query prefers-color-scheme, et surtout à ne pas considérer le dark mode comme un simple « thème ». Dans un email transactionnel, un bouton dont la couleur disparaît dans le mode sombre peut littéralement cacher le lien de confirmation. C’est un vrai problème d’accessibilité et de conversion.
Le responsive thinking appliqué à l’email ne s’arrête pas aux largeurs d’écran. Il couvre la densité de pixels, les modes de lecture, les réglages d’accessibilité. C’est un élargissement du même combat qu’on mène sur les Core Web Vitals quand on va au-delà du simple LCP pour inclure les préférences utilisateur dans la boucle de performance. D’ailleurs, en web, nous avions exploré une logique similaire sur le respect des signaux de classement dans optimisation core web vitals.
La structure hybride fluide : un seul code pour survivre partout
Plutôt que d’empiler les hacks client par client, on peut structurer le gabarit autour d’un principe simple : chaque bloc doit être capable de passer d’une largeur fixe à une largeur fluide, puis de s’empiler verticalement, sans media query.
Voici le squelette mental :
- Chaque « colonne » est un
<div>avecdisplay: inline-block; width: 100%; max-width: 300px; vertical-align: top;. - Ces
<div>sont contenus dans un conteneur entext-align: center;pour éviter les problèmes d’espacement entre blocs inline. - Pour Outlook, on enveloppe le tout dans des commentaires conditionnels qui forcent une structure en tableau.
- Les images ont
width: 100%; height: auto;et unemax-widthfixe.
Résultat : sur un viewport de 600px, les blocs s’alignent côte à côte si leur max-width le permet. Sur 320px, ils passent naturellement à la ligne, parce que width: 100% combiné à max-width force l’empilement. Aucune media query n’est requise. Le comportement responsive est une conséquence mécanique de la fluidité du layout, pas d’un déclencheur CSS.
C’est à la fois plus simple et plus radical. Et cela évite de dépendre du support des media queries chez les clients secondaires comme Yahoo Mail, Outlook.com en mode restreint ou les très vieux clients Android.
Ne codez pas sans logs : le débogage qu’on ne fait jamais
Tester un email responsive ne se limite pas à ouvrir Gmail et iOS Mail. Il faut accepter de regarder les logs de rendu et les captures automatisées. Litmus ou Email on Acid sont pratiques, mais vous pouvez aussi construire une suite de tests en local avec un outil comme mailpit ou smtp4dev, qui intercepte les emails sortants et les affiche dans un navigateur webkit. En forçant différents user agents et en désactivant le CSS, vous simulez une partie des clients problématiques.
La posture est la même que lorsqu’on débuggue un LCP avec les DevTools : on traque précisément ce qui bloque le rendu et on compare les cascades. Pour l’email, on liste les propriétés invalides, on vérifie la sortie HTML après passage dans le préprocesseur Gmail (via un compte test), et on documente les exceptions. Ce n’est pas glamour, mais c’est la seule manière de ne pas découvrir les bugs via la baisse du taux de clic.
📌 À retenir : Si vous n’avez pas testé votre email dans au moins Outlook 2019 et Gmail web sans les styles, vous ne savez pas s’il est responsive. Le « responsive » se mesure à la capacité de lire l’email sans CSS, pas avec.
Quand on code un template email avec un background plus complexe (composants dynamiques, génération de variantes), on peut aussi se poser la question de l’environnement de développement. Un IDE configuré pour le web moderne peut vous faire oublier les contraintes de l’email. Sur ce plan, nous avions comparé les retours d’expérience entre plusieurs outils de code, notamment sur l’approche IA-native avec Claude Code vs Cursor IDE, qui impacte directement la productivité lorsqu’on manipule du HTML inline.
Questions fréquentes
Est-ce que display: grid finira par arriver dans les clients mail ?
Certains clients comme Apple Mail le supportent déjà partiellement, mais Outlook desktop et les webmails Gmail restent figés sur un modèle de boîtes plus ancien. La probabilité d’un support universel est quasi nulle à horizon deux à trois ans. Le chemin le plus sûr reste de coder comme si ce support n’existait pas.
Pourquoi ne pas simplement utiliser un framework comme MJML ou Foundation for Emails ?
Ces outils simplifient la création, mais ils ajoutent une couche d’abstraction qui peut masquer le code réellement envoyé. Si vous avez besoin d’un contrôle fin sur la compatibilité Outlook ou sur le poids du HTML, comprendre le code natif produit est indispensable. Le framework devient alors une béquille qui ralentit le débogage.
Faut-il gérer l’état des blocs dans un builder d’email avec un store global ?
Si vous construisez un éditeur modulaire en React pour générer des templates à la volée, le choix du gestionnaire d’état influe sur la fluidité de l’interface. Nous avons décrit les avantages de Zustand pour ce type de cas dans l’article sur le state management React avec Zustand, car il évite la complexité de Redux tout en restant prévisible avec des blocs déplaçables.
