Conception d’emails responsive : Un guide technique
Créez des emails qui s’adaptent gracieusement du bureau au mobile.
Plus de 60 % des emails sont ouverts sur des appareils mobiles. La conception responsive n’est pas optionnelle. Mais l’email responsive est plus difficile que le web responsive. Le support des requêtes média varie. Flexbox ne fonctionne pas. Vous êtes coincé avec des tables.
Ce guide couvre des techniques qui fonctionnent réellement sur tous les clients email. Si vous voulez éviter la complexité, des outils comme Sequenzy gèrent le comportement responsive automatiquement dans leur constructeur visuel.
La réalité de l’email mobile
Les clients email sur mobile gèrent la conception responsive différemment :
- Apple Mail (iOS) : Support complet des requêtes média, fonctionne comme un navigateur
- Gmail App : Supporte les requêtes média depuis 2016, mais avec des particularités
- Outlook App : Support limité des requêtes média
- Samsung Mail : Généralement bon support
Le défi est de concevoir pour tous. Certains supportent les requêtes média, d’autres non. Votre mise en page a besoin de solutions de repli.
Mises en page fluides : La base
Commencez avec des largeurs fluides. Au lieu de largeurs en pixels fixes, utilisez des pourcentages avec des contraintes max-width :
<table role="presentation" width="100%" style="max-width: 600px;">
<tr>
<td style="padding: 20px;">
Content flows to fill available width
</td>
</tr>
</table> Cela fonctionne partout. Sur bureau, l’email fait 600 px de large. Sur mobile, il se rétrécit pour s’adapter à l’écran. Aucune requête média requise.
Requêtes média pour l’amélioration
Les requêtes média vous permettent de personnaliser l’expérience mobile dans les clients compatibles :
<style>
@media screen and (max-width: 600px) {
.column {
width: 100% !important;
display: block !important;
}
.stack-on-mobile {
display: block !important;
width: 100% !important;
}
.hide-on-mobile {
display: none !important;
}
.mobile-padding {
padding: 10px !important;
}
}
</style> Techniques clés :
- Empiler les colonnes : Convertir les colonnes côte à côte en blocs empilés
- Ajuster le padding : Réduire le padding sur les petits écrans
- Masquer les éléments : Supprimer le contenu secondaire sur mobile
- Redimensionner les images : Rendre les images pleine largeur
Les déclarations !important sont nécessaires car les styles inline ont une haute spécificité.
La méthode hybride/éponge
Cette technique utilise des commentaires conditionnels et CSS pour créer des mises en page responsive sans requêtes média :
<!--[if mso]>
<table role="presentation" width="600">
<tr>
<td width="300">
<![endif]-->
<div style="display: inline-block; width: 100%; max-width: 300px;">
Column 1 content
</div>
<!--[if mso]>
</td>
<td width="300">
<![endif]-->
<div style="display: inline-block; width: 100%; max-width: 300px;">
Column 2 content
</div>
<!--[if mso]>
</td>
</tr>
</table>
<![endif]--> Cela crée des colonnes côte à côte dans Outlook (qui lit les commentaires conditionnels) et des colonnes empilées partout ailleurs (qui utilise les éléments div). Aucune requête média nécessaire.
Images responsive
Les images doivent s’adapter à leurs conteneurs :
<img src="image.jpg"
width="600"
style="display: block; max-width: 100%; height: auto;"
alt="Description"> L’attribut width définit la taille prévue. max-width : 100 % empêche le débordement. height : auto maintient le ratio d’aspect.
Boutons adaptés au tactile
Les utilisateurs mobiles tapent, ne cliquent pas. Les boutons ont besoin d’une taille adéquate :
<table role="presentation">
<tr>
<td style="background-color: #007bff; border-radius: 4px; padding: 12px 24px;">
<a href="https://example.com"
style="color: #ffffff; text-decoration: none; font-weight: bold; display: block;">
Click Here
</a>
</td>
</tr>
</table> Cible tactile minimale : 44x44 pixels (recommandation Apple). Plus de padding est mieux que moins.
Tester le comportement responsive
Testez sur de vrais appareils quand possible. Les émulateurs et aperçus ne détectent pas tout :
- Envoyez des emails de test sur vos propres appareils
- Utilisez Litmus ou Email on Acid pour des aperçus automatisés
- Testez les orientations portrait et paysage
- Vérifiez avec les images désactivées
Utiliser des frameworks pour le responsive
Des frameworks comme MJML gèrent la conception responsive automatiquement :
<mj-section>
<mj-column>
<mj-text>Column 1</mj-text>
</mj-column>
<mj-column>
<mj-text>Column 2</mj-text>
</mj-column>
</mj-section> Ce MJML compile en HTML responsive. Les colonnes s’empilent sur mobile automatiquement. Aucune requête média manuelle.
Les constructeurs visuels comme Sequenzy fonctionnent de manière similaire. Les blocs sont pré-configurés pour le comportement responsive. Glissez des composants, personnalisez le contenu, la gestion responsive est intégrée.
Patrons responsive courants
Colonne unique (Mobile-First)
Commencez avec une mise en page en colonne unique. Cela fonctionne partout et nécessite des ajustements responsive minimaux.
Deux colonnes vers empilées
Côte à côte sur bureau, empilées sur mobile. Le patron responsive le plus courant. Utilisez la méthode hybride ou les requêtes média.
Image hero avec CTA
Image pleine largeur suivie d’un texte centré et bouton. Fonctionne bien à toute taille. L’image s’adapte, le texte reste lisible.
Le mot de la fin
L’email responsive est réalisable mais nécessite de comprendre les contraintes. Commencez avec des mises en page fluides, améliorez avec des requêtes média là où supporté, et testez minutieusement.
Si la complexité technique est intimidante, des frameworks comme MJML ou des plateformes comme Sequenzy s’en chargent pour vous. La sortie est testée sur les clients, et le comportement responsive est intégré aux composants.
Tableau de décision : ce qui sépare vraiment les bonnes options des pénibles
| Criterion | Question to answer |
|---|---|
| Source de vérité | Le résultat peut-il être versionné, relu et annulé par un propriétaire désigné ? |
| Sécurité de rendu | Le résultat survit-il à Outlook, au dark mode, aux images désactivées et aux largeurs mobiles ? |
| Accessibilité | Ordre sémantique, alt text, contraste et usage des liens sans acrobaties ? |
| Transmission | Combien d’étapes manuelles entre le design approuvé et l’envoi planifié ? |
| Coût à l’échelle | Le tarif compte t-il des contacts, des envois, des sièges ou des exports — où est le prochain palier ? |
Un plan de 30 jours pour tester tout cela dans votre stack
| When | Do this |
|---|---|
| Semaine 1 | Inventorier un gabarit représentatif, le passer dans la shortlist et noter les défauts par candidat. |
| Semaine 2 | Piloter les deux meilleurs : construier, générer sur les clients cibles, noter chaque transfert manuel. |
| Semaine 3 | Mesurer le temps du responsable, les réparations et chaque échec en dark mode ou sans images. |
| Semaine 4 | Décider sur preuve écrite : rendu, accessibilité, coût du palier suivant et plan de retour. |
Questions fréquentes
Comment comparaison démarrer sans se noyer dans les fonctions ?
Péaufez plutôt un message représentatif qui reflète votre quotidien : contenu dynamique, réutilisation de modules ou accessibilité stricte. Ce message unique servira de test pour tous les candidats, plutôt que de cliquer des dashboard avec données d’entraînement.
Combien de candidats vaut-il la peine de tester en parallèle ?
Restez surtout sous chiffre de trois : deux en pilote et un en réserve. Chaque candidat supplémentaire multiplie la preuve à rassembler plus qu’il n’apporte de gain individuel.
Quand vaut-il la peine de changer d’outil ?
Quand le même type de défaut revient trois fois de suite chez un candidat, ou lorsque le palier tarifaire suivant coûte plus cher que tout le pilote. Sinon le pilote tranché est souvent moins cher que la migration.
Les prix changent : vérifiez les plans sur la page officielle du fournisseur et faites-le à chaque renouvellement.