L’intégration HTML dans les différents clients emails

Aujourd’hui, nous allons rentrer dans le détail de la conception du fichier HTML d’un email. La plus grande difficulté de ce travail consiste à avoir le rendu souhaité dans tous un maximum de clients emails. Les pages web, elles, sont affichées par un navigateur (Internet Explorer, Firefox, Chrome, …) et, depuis les mises à jour d’Internet Explorer, les navigateurs commencent à être plus ou moins en adéquation avec le W3C, l’organisme qui définit les standards de développement web. Pour un email, il peut être affiché soit dans une application de client email (Outlook, Apple Mail, …) qui interprétera le code à sa sauce, soit dans un client email web, auquel cas le code sera interprété deux fois: une première fois par le navigateur, comme une page web, une deuxième fois par le client email (Gmail, Outlook.com, …).
Toute les complications viennent de l’interprétation du code par ces clients emails.

So 90’s

La première difficulté vient des application de client email. Si la plupart des sociétés tentent de faire en sorte que leurs parcs d’applications clients soient toujours à jour, certains utilisateurs ont des clients emails assez vieux (Outlook 2010, Lotus Notes, … ). Surtout dans certains milieu B2B, où les mises à jour de ces logiciels sont toujours postposées du fait de la complexité à être faites sur l’ensemble de leur réseau.

C’est pourquoi les développeurs emailing codent avec un HTML qui date des années 90, peu efficace en terme de lecture et de simplification du code et qui n’a pas grand chose à voir avec les bonnes pratiques de développement web, mais robuste dans de nombreux environnements. Les techniques modernes de design de page web ne fonctionnent pas dans la plupart de ces clients emails (bords arrondis, images de fond, …). Pour être précis, c’est surtout Outlook qui pose des problèmes aux intégrateurs. Pour de sombres raisons, le moteur de rendu HTML des dernières versions d’Outlook est le moteur de rendu HTML de… Word! Et celui-ci n’est pas du tout à jour avec les recommandations du W3C. Par chance, ou peut-être volontairement de la part de Microsoft afin d’offrir un “work-around”, il existe du code spécifique à ce moteur de rendu, le vml (vous pouvez lire notre article à ce sujet), qui permet de contourner certains problèmes. En contrepartie, cela complexifie plus le code, et le rend encore moins accessible au profane.

En dehors d’Outlook, si vous travaillez avec certaines grosses sociétés qui n’ont plus mis leur parque emailing à jours depuis (très) longtemps, vous pouvez être confronté au cauchemar de tout intégrateur: Lotus 6.5 et 7. Ces clients emails deviennent fort rares, mais ils sont encore importants dans certains cas précis. Et ces clients emails sont particulièrement tordus dans leur interprétation du code HTML. Si c’est votre cas, inutile de souhaiter un design trop compliqué pour espérer garder un rendu correct.

On en remet une couche

La deuxième difficulté vient des clients emails web. Pour ceux-ci, il faut d’abord obtenir un rendu correct avec l’interprétation du code des différents navigateurs, et ensuite un rendu correct avec l’interprétation du code des clients emails eux-mêmes. Ceux-ci ajoutent une couche de code supplémentaire au code HTML d’un email. Certains spécifient des valeurs d’interlignage pour lesquelles il vous faudra passer outre (Outlook.com), d’autres ne tiennent compte du centrage d’un élément que s’il est spécifié d’une certaine manière (Yahoo) ou encore, comme nous l’avons développé dans un article précédant, le code spécifique à l’affichage mobile n’est pas pris en compte (Gmail).

Et c’est bien là qu’intervient toute la difficulté de l’intégration. S’il est facile d’obtenir un rendu correct dans un client email spécifique, il est relativement compliqué d’obtenir un rendu correct dans un maximum de clients emails, certains bouts de code étant interprété différemment. Prenons l’exemple d’un padding sur un bloc à largeur fixe. Dans certains cas la valeur du padding sera incluse dans la largeur, dans d’autres elle sera ajoutée à la largeur, ce qui en fait un attribut à éviter puisque le rendu sera différent suivant les clients emails. Il existe de nombreux cas de figure où des morceaux de code permettant d’éviter les difficultés d’un client email engendrent un mauvais rendu sur un autre client email.

Un faux ami qui était auparavant couramment utilisé est de découper son email en image. Il est alors très facile de garder son design à l’identique sur tous les clients emails puisque ce n’est plus le code HTML qui génère le design, mais une ou des images.
Si pendant un temps cela influençait le score de spam de l’email, cela semble être moins le cas aujourd’hui. Par contre, la grosse majorité des clients emails désactivent les images par défaut. Et les utilisateurs sont exposés à toujours plus de communication. Le message à transmettre doit donc être clair en un clin d’oeil. Si pour afficher votre email il faut passer par un premier clic pour afficher les images, alors vous avez déjà perdu une partie de votre audience.

Priorités

Avoir un rendu impeccable dans tous les clients emails est impossible. La première raison étant qu’il est, en pratique, impensable de tester tous les environnements emails (suivant l’OS, le navigateur, l’application) ; il est par contre possible de faire des tests sur l’écrasante majorité des cas de figure. Il est également envisageable de vérifier après quelques envois quels sont les clients emails majoritaires utilisé par vos cibles. Cela permet alors de concentrer ses efforts de manière précise et pertinente.

Badsender peut vous accompagner dans la création de vos emails et vous accompagner dans la mise en place de tests et de bonnes pratiques. N’hésitez pas à consulter notre site agence ou nous contacter pour plus d’informations!

A propos de Grégory Van Gilsen

Ayant suivi des études de graphisme, Grégory a ensuite développé l'ensemble de sa carrière dans le domaine de l'email marketing et de l’eCRM. Après avoir été Digital Campaign Architect dans diverses agences, il rejoint Badsender en janvier 2015 pour y remplir le rôle de responsable des opérations.

Check Also

#MobileEmailLiberationFront : Qu’est-ce qui vous empêche encore de passer vos emails au responsive ?

Avec 54% d’ouvertures d’emails effectuées sur mobile (Litmus, Mars 2017), avec seulement 50% d’emails adaptés …

2 commentaires

  1. Merci pour ce post. Cela me permet de bien comprendre les fonctionnements des client mail pour les newsletters.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *