On a reçu la capture d’écran un vendredi soir. Un joli template de newsletter, trois colonnes bien alignées dans Gmail web, des images srcset parfaitement définies, une palette de couleurs validée par la marque. Sur l’iPhone du directeur marketing, le CTA principal disparaissait sous un bloc tronqué, la moitié droite de l’email plongeait dans le vide. L’équipe avait codé la newsletter comme une page web responsive, avec display: flex et rem, testée uniquement sous Chrome et Safari. Personne n’avait lancé un test Email on Acid. Résultat : 25 % de clics en moins sur la cible mobile ce jour-là, et un débrief qui a duré jusqu’au lundi.
Responsive web et responsive email n’ont rien à voir
Un client mail, ce n’est pas un navigateur. Outlook 2016-2019 affiche le HTML via le moteur de rendu de Microsoft Word. Gmail rogne les style intégrés selon des règles opaques. Apple Mail supprime les media queries quand l’utilisateur active « Protéger la confidentialité de l’activité dans Mail ». Le développeur qui applique les recettes du responsive web (grid, flex, unités relatives modernes) à un template d’email obtient un rendu cassé sur la moitié des boîtes professionnelles. Même logique que pour l’optimisation des Core Web Vitals : se fier à un seul simulateur est une erreur.
La méthode Email on Acid pour traquer un bug de rendu en 5 minutes
Voici comment on a utilisé l’outil pour sauver la newsletter e-commerce d’un client qui voyait son taux de conversion s’effondrer sur mobile.
- On charge le HTML de l’email dans l’interface. Email on Acid le parse, injecte les styles et prépare les rendus. Pas besoin de l’envoyer via un ESP, la previsualisation est immédiate.
- On sélectionne les clients mail critiques : Outlook 2016, Outlook 365, Gmail App Android, Apple Mail iOS, et un webmail type Yahoo. Ce sont ceux sur lesquels le client enregistrait le plus d’ouvertures.
- En moins de trois minutes, les captures s’affichent. On repère immédiatement le bloc
.promo-gridqui explose sur Outlook 2016 : le moteur Word ignoremax-width:100%sur les divs, il les transforme en largeur fixe issue du fichier HTML. - On corrige en encapsulant chaque bloc dans un tableau avec
width="100%"et en utilisant des attributs HTML (align="center") au lieu de propriétés CSS. On relance le test. En deux itérations, le rendu est propre partout.
💡 Conseil : Activez toujours le filtre « Images désactivées » dans Email on Acid. Un quart des destinataires ne télécharge pas les images par défaut ; la newsletter doit rester lisible avec le seul texte ALT.
Ce processus, répété à chaque modification du template, raccourcit nettement le debug. Pendant que le débat Claude Code vs Cursor IDE agite les équipes de dev web, nos templates d’email se construisent encore comme en 2004. La rigueur de test qu’impose Email on Acid n’a rien à envier à une pipeline CI.
Trois patterns « presque » responsives qui plantent en production
On a collecté ces bugs sur plusieurs missions. Aucun nom de marque, mais des cas bien réels.
Le piège de la hauteur automatique sur image de fond. Une newsletter mode utilisait une image de fond sur un tableau via l’attribut background et une couleur de secours. Sur Outlook, l’image s’étirait en hauteur en poussant le texte hors du viewport mobile. Le correctif : doubler le tableau avec un second dédié à l’image, hauteur fixe sur le td, et background-size: cover conditionnel dans un @media ignoré par Outlook (qui prendra simplement la couleur de fond). Testé via Email on Acid, le template affichait un bloc centré de 320px de haut, sans scroll parasite.
La grille 3 colonnes qui devient une colonne sur Gmail App. La newsletter d’un éditeur logiciel utilisait trois div flottantes en display:inline-block. Sur Gmail App Android, le float est ignoré, les colonnes restent en pleine largeur et le CTA se retrouve isolé tout en bas. La solution : une structure en tables imbriquées, avec align="left" sur chaque td pour les colonnes desktop, et un bloc unique rétractable via @media pour le mobile. Repéré en une seule soumission sur la plateforme.
Le bouton qui rétrécit jusqu’à 12px. Un template utilisait une div stylée avec padding et border-radius pour créer un CTA. Sur Outlook 2016, le padding gauche n’est pas géré, le texte touche le bord, la largeur minimale contraint la taille de police et le bouton devient illisible. Le remède : un vrai bouton via <a> avec background-color et display:inline-block, doublé d’un VML pour Outlook (oui, du VML). Email on Acid compare côte à côte le rendu avec et sans VML. Le VML fonctionne comme le state management avec Zustand : un compartiment isolé qui gère un comportement aberrant sans polluer le reste du code.
Le vrai coût du CSS inline et des media queries mal supportées
La plupart des ESP (Mailchimp, SendGrid, Brevo) inlinent automatiquement le CSS en style sur chaque élément. Certains inliners écrasent des propriétés critiques ou dupliquent des règles sur des centaines de lignes, rendant le HTML illisible au débug. Yahoo Mail, lui, supprime overflow:hidden et text-overflow:ellipsis même après inlining : la troncature élégante prévue sur la description produit est coupée brutalement. La parade : limiter le nombre de caractères en amont dans le flux de données, plutôt que de compter sur du CSS.
⚠️ Attention : Gmail App iOS applique les media queries, mais si une règle
!importantest présente dans un bloc non responsive, elle peut écraser la version mobile. Le réflexe : désactiver les styles inline dans Email on Acid pour isoler les conflits.
La checklist en neuf points qui a divisé le temps de test
Au début, on soumettait le HTML au jugement d’Email on Acid à chaque modification, un peu au hasard. Rapidement, on a figé une checklist de neuf points, calée sur les anomalies les plus fréquentes :
- Ouverture sous Outlook 2016 avec et sans images
- Zoom à 120 % sur Outlook (pour les utilisateurs qui agrandissent)
- Rendu Gmail App avec CSS inline désactivé volontairement
- Rendu Apple Mail avec « Protéger la confidentialité » activé
- Désactivation des polices web (fallback
font-family) - Vérification du CTA en mode texte (ALT seul, sans image)
- Largeur à 320px (le viewport le plus étroit qu’on cible)
- Dark mode forcé sur Gmail et Outlook (oui, les clients modifient les couleurs)
- Balisage
aria-labelsur les liens visuels, vérifié avec un lecteur d’écran simulé
Cette routine prend sept minutes. On l’exécute après chaque changement significatif du template. Les anomalies sont documentées dans un tableau Notion avec une capture issue d’Email on Acid et le commit du correctif. L’équipe SEO du client, qui pousse parfois des contenus urgents, sait qu’elle peut modifier le HTML sans casser l’affichage parce que le test est automatisé côté dev.
Le parallèle avec la performance web est frappant. Optimiser le LCP d’une landing page, c’est répéter un scénario de test reproductible : classe réseau, CPU throttling, cache désactivé. Email on Acid joue le même rôle pour l’email, un banc de test qui élimine l’à‑peu‑près.
Questions fréquentes
Email on Acid est-il redondant si j’utilise déjà les tests intégrés de mon ESP (Mailchimp, SendGrid) ? Non. Les tests intégrés se limitent souvent à quelques clients populaires et n’actualisent pas leurs environnements aussi vite. Email on Acid couvre plus de 70 clients, avec des mises à jour hebdomadaires, et donne accès à des options de débug poussées comme la désactivation des media queries ou le live preview avec modification du code.
Faut-il vraiment apprendre le VML en 2026 pour un simple email responsive ?
Pas nécessairement pour tous les templates, mais si votre newsletter vise des professionnels ouverts sous Outlook 2016-2019, quelques lignes de VML conditionnel dans un commentaire <!--[if mso]> sauvent la mise des boutons et des arrière‑plans. Email on Acid vous montre immédiatement l’utilité du VML sans avoir à attendre un retour destinataire.
Peut-on tester une newsletter déjà envoyée pour comprendre un bug passé ? Oui, il suffit de récupérer le HTML source (pas le rendu final chez le destinataire, mais le code envoyé par l’ESP) et de le soumettre à Email on Acid. Vous pouvez même forcer l’affichage des versions antérieures d’un client mail pour reproduire un bug historique.
