Outlook n’affiche pas les e-mails HTML avec un navigateur : depuis la version 2007, il délègue le rendu au moteur de Microsoft Word. C’est ce détail, souvent ignoré des développeurs qui testent leurs templates uniquement dans Gmail, qui explique pourquoi une mise en page parfaite d’un côté devient un empilement vertical cassé de l’autre.
Le cas concret qui a motivé cet article : un template de confirmation de commande WooCommerce personnalisé, avec un bouton d’action en flexbox et des marges en rem. Impeccable sur Gmail web et l’application mobile Gmail. Complètement disloqué sur Outlook desktop, où le bouton se retrouvait collé au bord gauche sans espacement, et sur Outlook.com, où les couleurs de fond disparaissaient purement et simplement.
Pourquoi un test « ça marche dans mon navigateur » ne suffit pas
Un e-mail HTML n’est pas une page web. Les clients de messagerie majeurs supportent un sous-ensemble hétéroclite de CSS, chacun avec ses propres exceptions :
- Outlook desktop (moteur Word) ignore
flexbox,grid, et la plupart des propriétés de fond en dégradé. - Gmail web réécrit certaines balises
<style>globales et les convertit en styles en ligne, avec des limites de taille. - Apple Mail supporte quasiment tout le CSS moderne, ce qui donne une fausse impression de sécurité aux développeurs qui testent uniquement dessus.
- Les clients Android génériques varient fortement selon le fabricant du téléphone.
Automatiser la capture de rendu par client
La solution la plus fiable reste un service de capture multi-clients (type Email on Acid ou Litmus), déclenché automatiquement dès qu’un template change dans le dépôt. Faute d’un tel service dans le budget du projet, une alternative pragmatique consiste à automatiser l’envoi vers des boîtes de test réelles, une par client cible, puis à capturer une image de chacune via Playwright pour les webmails.
test('le template de confirmation de commande s\'affiche correctement dans Gmail web', async ({ page }) => {
await page.goto('https://mail.google.com/mail/u/0/#inbox');
await page.click('text=Confirmation de commande #4821');
const frame = page.frameLocator('iframe.email-body');
await expect(frame.locator('.bouton-action')).toBeVisible();
await expect(page).toHaveScreenshot('confirmation-commande-gmail.png', {
maxDiffPixelRatio: 0.02,
});
});
Ce que le script précédent ne couvre pas
Cette approche ne remplace pas un test sur Outlook desktop, qui n’expose pas d’interface web pilotable de la même façon. Pour ce client précis, le contrôle reste largement manuel ou passe par un service tiers spécialisé qui maintient de vraies instances Windows avec Outlook installé.
Écrire un CSS qui survit à Outlook
Plutôt que de chercher à automatiser un contournement pour chaque bizarrerie de rendu, la vraie économie consiste à écrire des templates transactionnels avec des tableaux HTML et du CSS en ligne, la seule approche qui traverse fiablement tous les moteurs :
<table role="presentation" width="100%" cellpadding="0" cellspacing="0">
<tr>
<td style="padding: 24px; background-color: #1d2b3a;">
<a href="https://exemple.test/commande/4821"
style="background-color: #ffffff; color: #1d2b3a; padding: 12px 24px; display: inline-block; text-decoration: none;">
Voir ma commande
</a>
</td>
</tr>
</table>
Ce choix, plus verbeux et moins agréable à écrire qu’un CSS moderne, a un avantage décisif : il rend inutile la moitié des tests visuels multi-clients, puisque le rendu devient prévisible dès la conception plutôt que corrigé après coup.
Intégrer le contrôle dans le flux de livraison
Concrètement, le contrôle qui a le meilleur rapport effort-fiabilité reste une checklist manuelle courte, appliquée à chaque nouveau template avant mise en production : rendu Outlook desktop, rendu Gmail mobile, rendu Apple Mail sombre. Automatiser la totalité coûte souvent plus cher que la valeur qu’on en tire, sauf pour un client envoyant un volume d’e-mails transactionnels critique pour son activité.
Un e-mail transactionnel cassé sur Outlook ne fait pas planter le site : il fait perdre confiance au client final, silencieusement, sans qu’aucune alerte technique ne remonte jamais à l’équipe.
Notre verdict
Tester des templates transactionnels sur plusieurs clients de messagerie n’a de sens que si l’écriture du template elle-même limite déjà la surface d’incompatibilité, via des tableaux et du CSS en ligne. L’automatisation vient ensuite en filet de sécurité, pas en substitut à une conception pensée pour Outlook dès le départ.
