Guide · Email HTML
Pourquoi votre email HTML
est cassé dans Outlook
(et comment le tester)
Un email qui s'affiche parfaitement dans Gmail peut devenir illisible dans Outlook : colonnes empilées, images manquantes, espacements qui explosent. Ce n'est pas un bug isolé — c'est la conséquence directe du moteur de rendu qu'utilise Outlook. Voici pourquoi, et comment vérifier vos templates avant chaque envoi.
Outlook n'est pas un navigateur
C'est la source de 90% des problèmes de rendu email : depuis Outlook 2007, Microsoft a remplacé le moteur de rendu HTML (basé sur Internet Explorer) par le moteur de mise en page de Word. La décision visait à unifier l'affichage entre Word, Outlook et Office — mais Word n'a jamais été conçu pour afficher des pages web.
Concrètement, Outlook desktop (versions 2007 à 365 sur Windows) ignore ou interprète mal : flexbox et CSS grid, les fonds en background-image, les marges négatives, le border-radius sur certains éléments, les polices web via @font-face, et une partie des unités relatives comme % ou vw. Gmail et Apple Mail, eux, utilisent de vrais moteurs web (Blink et WebKit) et affichent presque tout correctement — d'où l'écart de rendu que vous constatez.
Les 6 erreurs qui cassent le rendu
La plupart des templates cassés dans Outlook cumulent plusieurs de ces erreurs, hérités des habitudes du développement web classique :
CSS dans le <head>
Gmail et Outlook.com suppriment les balises <style> du head. Sans CSS inline en secours, tous les styles disparaissent purement et simplement.
Flexbox ou CSS grid
Non supportés par le moteur Word. Les colonnes censées être côte à côte s'empilent verticalement dans Outlook desktop.
Images en background-image
La propriété CSS background-image est ignorée par Outlook. Un visuel de fond censé habiller un bloc de texte disparaît totalement.
Mise en page en <div>
Les div flottantes ou positionnées en absolute sont instables. Les tables HTML restent la seule structure fiable pour la mise en page email.
Largeurs en % ou vw
Les unités relatives se comportent de façon imprévisible dans le moteur Word. Les largeurs de colonnes doivent être fixées en pixels.
Pas de commentaires MSO
Sans commentaires conditionnels <!--[if mso]-->, impossible de cibler spécifiquement Outlook pour corriger un affichage sans casser les autres clients.
Comment tester un email avant l'envoi
Un email ne doit jamais partir sans avoir été vérifié sur les clients mail réellement utilisés par vos destinataires. Voici la méthode en 4 étapes :
Inliner le CSS et valider le HTML
Avant tout envoi de test, passez le code dans un inliner CSS (Juice, Premailer, ou l'export automatique de MJML) pour transformer chaque style en attribut inline.
Lancer un test multi-client (Litmus / Email on Acid)
Ces outils envoient votre email vers de vrais environnements et renvoient des captures d'écran du rendu sur 40 à 90 clients mail : Outlook 2016/2019/365, Gmail, Apple Mail, Yahoo, Orange.
Vérifier sur un vrai Outlook desktop
Les émulateurs sont fiables à 95%, pas à 100%. Un envoi test vers une boîte Outlook 365 desktop réelle reste le seul moyen de confirmer un rendu critique (email transactionnel, lancement produit).
Contrôler le mode sombre et le mobile
Testez le rendu en dark mode sur Apple Mail et Outlook.com, ainsi que l'affichage mobile (iOS Mail, Gmail Android) où plus de 60% des emails sont désormais ouverts.
Checklist avant chaque envoi
La check-list minimale que nous appliquons sur chaque template avant livraison :
- Structure : mise en page en tables HTML, pas de flexbox ni de grid
- CSS : 100% inline, aucune dépendance à une balise <style> externe
- Fonds visuels : VML + commentaires conditionnels MSO pour Outlook, couleur de secours en CSS
- Largeurs : fixées en pixels, jamais en % ou vw pour les colonnes
- Polices : fallback web-safe (Arial, Georgia) si la police custom n'est pas supportée
- Poids : email optimisé sous 100 Ko pour éviter le tronquage Gmail et le dossier spam
- Test réel : rendu vérifié sur Outlook desktop, Gmail, Apple Mail et mobile avant envoi
Questions fréquentes
Pourquoi mon email HTML s'affiche-t-il mal dans Outlook ?
Parce qu'Outlook (2007 à 365, versions desktop Windows) n'utilise pas un moteur de rendu web mais le moteur de Microsoft Word. Il ignore flexbox, CSS grid, les fonds en CSS et la plupart des propriétés modernes, ce qui casse les emails codés comme des pages web classiques.
Faut-il toujours mettre le CSS en inline dans un email ?
Oui, dans la quasi-totalité des cas. Gmail et Outlook.com suppriment ou ignorent les balises <style> placées dans le <head>. Le seul moyen fiable d'appliquer un style est de l'écrire directement dans l'attribut style de chaque balise HTML.
Quel outil utiliser pour tester un email avant de l'envoyer ?
Litmus et Email on Acid sont les références : ils génèrent des captures d'écran du rendu réel sur 40 à 90 clients mail. Pour une vérification rapide sans outil payant, un envoi de test vers une vraie boîte Outlook desktop reste indispensable, car les émulateurs ne sont pas fiables à 100%.
Comment Outlook gère-t-il les images de fond en CSS ?
Outlook ignore la propriété CSS background-image. Pour afficher une image en fond de bloc, il faut utiliser la balise VML associée à des commentaires conditionnels MSO, en plus d'une couleur de secours en CSS pour les autres clients.
Ce qu'un email cassé coûte réellement
Un email mal rendu n'est pas qu'un problème esthétique. Un destinataire qui voit un bloc de texte non stylé, une image manquante ou un bouton d'appel à l'action invisible ne cherche pas à comprendre le problème technique : il ferme l'email, voire se désabonne. Sur une campagne envoyée à plusieurs milliers de contacts, un rendu cassé sur Outlook — client encore massivement utilisé en entreprise et dans les grands comptes B2B — peut représenter une part significative de vos destinataires qui ne verront jamais correctement votre message.
Le coût est cumulatif : perte de clics immédiate, dégradation de la réputation d'expéditeur si le taux d'ouverture chute, et image de marque écornée pour les emails transactionnels (confirmation de commande, facture) où un rendu cassé inquiète plus qu'il n'informe.
C'est pourquoi le test multi-client ne doit jamais être une étape optionnelle réalisée « si le temps le permet », mais une validation systématique intégrée au processus de production, au même titre que la relecture orthographique ou la vérification des liens.
Un email HTML garanti
compatible Outlook.
SnackDesign intègre et teste vos templates sur 40+ clients mail avant livraison, en 48h.
Découvrir l'intégration mailing HTML