Écrire du HTML pour l’e-mail revient à coder pour une trentaine de moteurs de rendu dont aucun ne suit les mêmes règles que les navigateurs. Outlook sur Windows utilise toujours le moteur de rendu de Microsoft Word. Gmail réécrit les styles. Apple Mail applique les préférences système. Voici ce qui fonctionne réellement en 2026, et ce qui reste à éviter.
Le tableau reste la structure de référence
La disparition annoncée des tableaux de mise en page n’a pas eu lieu. Les versions bureau d’Outlook sous Windows continuent de s’appuyer sur le moteur Word, qui ignore float, display: flex et display: grid. Une mise en page fondée sur ces propriétés s’effondre en colonne unique — parfois de façon acceptable, souvent non.
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center" style="padding: 24px 16px;">
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0">
<tr><td style="font-family: Arial, sans-serif; font-size: 16px; line-height: 24px;">
Contenu
</td></tr>
</table>
</td>
</tr>
</table>L’attribut role="presentation" n’est pas décoratif : il indique aux lecteurs d’écran que le tableau structure la mise en page et ne contient pas de données, ce qui évite une lecture cellule par cellule.
Ce qui est réellement disponible
| Technique | Statut en 2026 | Remarque |
|---|---|---|
Styles en ligne (style="") | Indispensable | Certains clients suppriment encore les blocs <style> |
<style> dans le <head> | Largement pris en charge | À utiliser pour les media queries, pas pour les styles critiques |
| Media queries | Bonne prise en charge | Ignorées par Outlook Windows, d’où l’approche « mobile d’abord dégradée » |
| Polices web | Partielle | Toujours prévoir une pile de repli système |
| WebP | Partielle | Non pris en charge par certains Outlook — préférer JPEG ou PNG |
| SVG | À éviter | Bloqué par Gmail et la plupart des clients |
position, flex, grid | À éviter | Non gérés par le moteur Word |
| Mode sombre | Hétérogène | prefers-color-scheme fonctionne, mais certains clients inversent les couleurs d’autorité |
Le mode sombre, principal changement récent
C’est le sujet qui produit le plus de rendus inattendus. Trois comportements coexistent : les clients qui respectent prefers-color-scheme, ceux qui inversent automatiquement les couleurs claires, et ceux qui n’appliquent rien. Un fond blanc et un texte noir écrits en dur peuvent donc devenir un fond sombre avec un texte resté noir — illisible.
<style>
:root { color-scheme: light dark; supported-color-schemes: light dark; }
@media (prefers-color-scheme: dark) {
.corps { background-color: #14181d !important; }
.texte { color: #e8edf3 !important; }
.logo-clair { display: none !important; }
.logo-sombre { display: block !important; }
}
</style>Deux règles pratiques limitent les dégâts : ne jamais poser un logo en PNG transparent noir (il disparaît sur fond sombre — prévoir une version claire), et éviter les contrastes extrêmes que les clients inverseurs traitent de façon agressive.
Un e-mail se conçoit pour être lisible même quand toutes ses règles CSS sont ignorées. Ce qui reste alors doit encore fonctionner.
Images : indispensables, jamais essentielles
Une part importante des destinataires lit les messages images bloquées par défaut. Trois conséquences opérationnelles :
- Attribut
altsystématique, rédigé pour être lu — c’est le texte qui s’affiche à la place. - Aucune information essentielle dans une image seule : un bouton d’action doit rester un lien stylé en HTML, pas une image cliquable.
- Dimensions explicites (
widthetheighten attributs) pour éviter le réagencement à l’affichage.
Le bouton, cas d’école
Le bouton « bulletproof » reste la technique de référence : un lien stylé dans une cellule de tableau, avec un repli conditionnel pour Outlook.
<table role="presentation" cellpadding="0" cellspacing="0" border="0">
<tr><td bgcolor="#0a6cff" style="border-radius:6px;">
<a href="https://exemple.fr/"
style="display:inline-block; padding:14px 28px; font-family:Arial,sans-serif;
font-size:16px; color:#ffffff; text-decoration:none;">
Lire l'article
</a>
</td></tr>
</table>Les contrôles avant envoi
- Poids total sous 102 ko pour le HTML : au-delà, Gmail tronque le message et affiche un lien « afficher le message entier », ce qui casse le suivi et l’affichage.
- Version texte brut renseignée : son absence est un signal négatif pour les filtres.
- Rendu vérifié sur au moins Outlook Windows, Gmail web, Gmail mobile et Apple Mail — ce quatuor couvre l’essentiel des écarts.
- Liens absolus et en HTTPS, y compris les images.
- Lien de désinscription visible et fonctionnel, en plus de l’en-tête
List-Unsubscribe.
Ce qu’il faut retenir
Le HTML e-mail ne converge pas vers le HTML web, et parier sur cette convergence produit des messages cassés chez une partie des destinataires. La méthode qui tient consiste à écrire une structure en tableaux, à styler en ligne, à traiter le mode sombre explicitement, et à considérer chaque amélioration CSS comme un bonus qui peut disparaître.
J’ai passé plus de temps qu’il n’est raisonnable à réparer des gabarits qui rendaient parfaitement dans un navigateur et s’effondraient dans Outlook. La règle que j’applique depuis : je teste le rendu Outlook avant d’écrire le contenu, pas après. Un gabarit validé une fois se réutilise des années. — Simon Janvier
