7 idées reçues sur l’intégration des emails en HTML

A l’origine, les emails se réduisaient à du texte, et uniquement du texte. Au fil des décennies, l’email a évolué et a commencé à intégrer d’autres éléments HTML grâce au travail acharné de développeurs talentueux. Les développeurs ont progressivement édicté des listes de « bonnes pratiques » afin d’aider les professionnels à enrichir le contenu de leurs emails. Tout le monde s’est mis à assimiler les règles en matière d’intégration des emails en HTML, par apprendre ce qu’il fallait faire et ce qu’il ne fallait pas faire. Par exemple : limiter la largeur à 600 px, n’utiliser que des polices de caractère standards, passer le CSS inline, etc.

On n’est pas contre l’idée de « bonnes pratiques ». Nous sommes les premiers à en partager dans les articles que nous rédigeons pour vous. Le problème, c’est que certaines bonnes pratiques se transforment en idées reçues. C’est ce qui arrive lorsqu’on oublie que les bonnes pratiques ne sont pas des règles statiques et immuables, mais des recommandations fondées sur la base de l’état des technologies et des outils à une l’époque donnée. Des bonnes pratiques qui étaient fortement recommandées hier ont progressivement perdu de leur pertinence. Ce qui était valable à la fin des années 1990 ne l’est plus forcément au milieu des années 2010.

Nous avons sélectionné pour vous 7 idées reçues concernant l’intégration email. Des idées reçues qui ont la vie dure et qu’il serait pourtant bon de reconsidérer.

Idée reçue #1 : les emails doivent faire 600 pixels de largeur

Avant l’explosion du marché des smartphones et des tablettes, au temps où les emails ne pouvaient être lus que sur un ordinateur, on avait l’habitude de dire que les emails ne devaient pas dépasser 600 px de largeur. C’est une des bonnes pratiques les plus connues. Pourquoi « 600 » pixels ? Parce que la taille de l’espace d’affichage de la plupart des clients emails (Hotmail, Yahoo! et Outlook) faisait entre 500 et 550 pixels. Se limiter à 600 pixels de largeur permettait à l’email de s’afficher pleinement dans l’espace d’affichage des clients emails, sans que l’on ait besoin de scroller horizontalement.

Même s’il y a aujourd’hui beaucoup plus de devices à gérer, avec à chaque fois des tailles d’écran différentes, pourquoi rester fixer sur cette largeur d’email de 600 px ? C’est d’abord une règle facile à appliquer. Si vous éditez le design de vos emails sur Adobe Photoshop ou un outil comme Sketch, vous avez besoin de définir une largeur au départ. Il est vrai qu’utiliser une largeur de 600 pixels permet un affichage optimisé de vos emails sur la plupart des clients de messagerie sur ordinateur. En utilisant des media queries, les développeurs peuvent ensuite faire varier automatiquement la largeur de l’email en fonction du device utilisé par le destinataire.

Les media queries permettent de créer des emails responsive, en variabilisant les largeurs en fonction des devices. Cette technique résout le problème de l’augmentation du nombre de devices. Pour Outlook, qui ne gère pas les media queries, vous pouvez utiliser les commentaires conditionnels de Microsoft.

Cet email de Zalendo fait 450 pixels de largeur – très loin du standard des 600 pixels donc. Ce choix, et celui de CTA bien mis en valeur, rend cet email particulièrement bien « mobile-friendly ». A l’inverse, certaines entreprises utilisent des largeurs d’email supérieures à 600 pixels (640, 650 voire plus de 700 pixels !). Si vous utilisez des media queries qui permettent de fixer une largeur maximum et de faire varier cette largeur en fonction des écrans, la limite des 600 pixels perd beaucoup de sa pertinence. En fait, vous devez surtout prendre en compte la manière dont vos inscrits lisent vos emails. Utilisent-ils plutôt le mobile ou l’ordinateur ? Plutôt Gmail, Outlook ou Yahoo! ? Dans certains cas, opter pour une largeur maximale de 600 pixels fait sens. Mais pas toujours !

Pour approfondir ce sujet, nous vous recommandons la lecture de notre guide complet sur la largeur et la taille idéales de vos emailings.

Idée reçue #2 : vous devez utiliser uniquement des polices de caractère standards

Pendant longtemps, les polices standards ont représenté une option sécurisante. Elles constituaient même la seule option pour que les emails s’affichent correctement. A partir du début des années 2000, des web designers ont expérimenté des polices de caractère non standards sur internet. Depuis 2008, la règle CSS @font-face permet aux web designers d’utiliser des polices non standards ( = leurs propres polices) pour leur site internet. En 2010, Google a lancé sa propre bibliothèque gratuite de polices de caractère : Google Fonts (plus de 800 polices).

Il faut noter que ces polices non standards étaient destinées à l’origine à être utilisées sur des sites web, et pas dans des emails. La plupart des web designers ont rencontré des difficultés au départ pour intégrer ces polices web dans le corps des emails en HTML. Aujourd’hui encore, utiliser des polices non standards dans les emails en HTML suppose des connaissances techniques.

C’est pourquoi nous recommandons de privilégier les polices standards universelles dans vos emails, même s’il n’est pas du tout interdit d’utiliser des polices non standards pour vous différencier de vos concurrents. Si vous optez pour des polices non standards, vous devez surtout vérifier que les clients de messagerie de vos inscrits les gèrent correctement. Aujourd’hui, les polices non standards sont gérés par Google Android, Apple Mail (iPhone et Ipad) et Outlook (2011 et 2016). En clair, un peu plus de la moitié des emails sont ouverts aujourd’hui depuis des clients email qui supportent les polices de caractère non standards. Vous devez analyser votre base d’inscrits pour déterminer si utiliser des polices non standards est envisageable ou non. Il y a fort à parier que d’ici plusieurs années tous les clients de messagerie géreront les polices non standards. La bonne pratique qui consiste à n’utiliser que des polices universelles n’aura surement plus de fondement dans un avenir proche.

Dans l’illustration ci-dessous, on a deux exemples d’un même email : celui de gauche utilise les polices web, contrairement à celui de droite. The Outnet a fait le choix d’une police de caractère alternative très proche de leur police web, démontrant que l’on peut utiliser aujourd’hui des polices web dans les emails, avec des résultats tout à fait satisfaisants.

Découvrez comment réaliser le tracking de vos campagnes emailing via Google Analytics.

Idée reçue #3 : il ne faut utiliser que des Doctype transitionnels

Dans un document HTML, le Doctype spécifie au navigateur la manière dont il doit rendre la page. La balise Doctype est insérée au tout début de l’email. Dans la plupart des emails, le Doctype ressemble à ça :

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">  

Tous les développeurs d’emails ont pris l’habitude d’utiliser un Doctype, même si dans les faits certains clients de messagerie supprime cette balise ou la remplace par une autre. C’est le cas par exemple de Gmail de Outlook.com et de Yahoo! Mail : ces trois clients de messagerie éjectent la balise de l’email, quelque soit le Doctype utilisé, et la remplacent par un Doctype HTML5.

Sur le web, il existe plusieurs types de Doctypes qui chacun à leur manière changent la manière dont sont rendus certaines propriétés CSS et certains éléments HTML. Le Doctype ci-dessous autorise la plupart des éléments HTML, y compris les éléments dépréciés comme les balises <font> (remplacés aujourd’hui par des attributs CSS : font-family, font-size…). Dans le passé, ce Doctype était le plus recommandé. Mais ça, c’était avant que le HTML5 ne devienne le standard. Aujourd’hui, le Doctype recommandé est celui-ci :

<!DOCTYPE html>  

Le Doctype HTML5 permet d’intégrer ans les emails les éléments HTML5 les plus récents, comme par exemple la balise <video>. Même si tous les clients de messagerie ne peuvent pas rendre tous ces nouveaux éléments/propriétés, il n’y a pas de raison de se priver de ce Doctype. C’est même conseillé, car c’est l’avenir ! Il faut savoir que vous pouvez toujours utiliser des codes dépréciés avec le Doctype HTML5, mais le code deviendra invalide suite au test de validation. Que votre code soit valide ou non, ça n’aura aucun impact en termes de délivrabilité ou en termes de performance, mais nous vous conseillons quand même de vérifier la structure de votre HTML et vos balises ouvertes pour éviter les problèmes de rendu visuel.

Idée reçue #4 : vous devez utiliser des sélecteurs d’attributs CSS

Plusieurs développeurs avaient remarqué, un bug concernant Yahoo! Mail. Ce client de messagerie a en effet tendance à activer les propriétés CSS contenues dans les media queries même si l’email est lu depuis un device non-mobile. Ce qui crée des problèmes d’affichage. La solution, pour remédier à cette bizarrerie, consistait à transformer l’attribut CSS en question en sélecteur d’attributs. Pour rappel, les sélecteurs d’attributs permettent de cibler un élément en fonction de la présence d’un attribut CSS ou en fonction de la valeur de cet attribut. Voici à quoi ça ressemble :

  *[class=”foo”] {color:#000000; font-family: sans-serif;}  

Ecrire des CSS de ce type dans le <head> de l’email est devenu depuis une sorte de standard, dans la mesure où les autres clients de messagerie (ceux en tous cas qui lisent les styles dans le head) gèrent comme Yahoo! Mail aussi les sélecteurs d’attributs. Sauf que début 2015, Yahoo! Mail a intégré une mise à jour résolvant le problème et permettant de lire les styles normalement. C’est-à-dire comme ça :

  .foo {color:#000000; font-family: sans-serif;}  

Malgré cette mise à jour, les développeurs d’emails ont pris l’habitude d’utiliser les sélecteurs d’attributs. Pourtant, cette technique qui consiste à utiliser des sélecteurs n’a plus de raison d’être. C’est se prendre la tête pour rien. Certains développeurs préfèrent même désactiver la mise à jour Yahoo! plutôt que de changer leurs habitudes. Le problème, c’est que les sélecteurs d’attributs peuvent causer quelques soucis. En effet, un client de messagerie comme Gmail ne gère pas les sélecteurs d’attributs, ce qui peut provoquer des problèmes d’affichage importants de vos emails. En revanche, Gmail supporte désormais les feuilles de style dans le <head>.

Pour résumer : utiliser des sélecteurs d’attributs n’est plus recommandé, car le bug Yahoo! Mail a été réparé et parce que Gmail ne les gère pas.

Nous vous invitons à découvrir le guide complet que nous avons consacré à la mise en page et au contenu des emails.

Idée reçue #5 : tous les styles CSS utilisés dans les emails doivent être inline

L’utilisation de tableaux pour les structures d’emails et de feuilles de styles inlines est au fondement du développement email depuis…toujours. Ces deux éléments font la grande différence entre le développement web et le développement email. L’utilisation de CSS inlines est tellement devenu un réflexe qu’il est devenu difficile de savoir pourquoi cela se justifie. Certains avancent que c’est à cause de Outlook et Gmail. Ce qui est faux, car Outlook n’a jamais eu de problème avec les feuilles de style placées dans le <head>. Il est vrai que pendant longtemps Gmail ne supportait pas les styles dans le head. Mais depuis quelques mois les choses ont changé : Gmail gère dorénavant les feuilles de styles dans le head. Du coup, à quoi bon continuer d’utiliser cette technique ?

Si vos inscrits utilisent principalement Gmail, iOs ou même Outlook, nous vous recommandons vraiment de déplacer vos feuilles de style dans le head. Par contre, si vous inscrits utilisent des clients de messagerie plutôt atypiques comme Yandex (russe), Libero (italien) ou autre T-Online (allemand) qui reposent sur les styles inlines, il est préférable de conserver vos styles inline.

Pour en savoir plus sur le CSS inline (et sur bien d’autres choses), découvrez notre guide « l’art de coder un email en HTML / CSS« .

Idée reçue #6 : vous ne devez pas utiliser d’images d’arrière-plan dans vos emails

Il est de notoriété publique que les images d’arrière-plan sont difficiles à gérer dans les emails et posent tout un tas de problèmes d’affichage. Les développeurs email utilisent en général des codes VML compliqués pour optimiser leur rendu sur les différentes d’Outlook. Et Outlook n’est pas le seul client de messagerie à mal gérer les images de fond.

Nous voudrions ici vous dire que des images d’arrière-plan peuvent parfaitement fonctionner dans un email. En fait, tout dépend de la manière dont vous les incorporez dans le design de l’email. Ce ne sont pas les images d’arrière-plan qui posent problème en tant que tel, mais leur mode d’intégration. Si vos inscrits utilisent des clients de messagerie qui ne supportent pas toujours les images d’arrière-plan, nous vous conseillons de ne pas utiliser les images d’arrière-plan comme élément clé de votre design, car cela peut occasionner des problèmes. Mais rien n’empêche d’utiliser des images d’arrière-plan à titre secondaire, comme simples améliorations de votre design initial.

Une des raisons principales qui amenaient à éviter les images d’arrière-plan, c’était que Gmail gérait mal les propriétés CSS background-size et background-position. Or, oes propriétés sont importantes pour les écrans avec une densité élevée de pixels et pour les email responsive/hybrides. Elles permettent d’avoir un bon contrôle sur la taille et le positionnement de l’image. Il faut savoir que Gmail supporte désormais ces propriétés. Du coup, il y a aujourd’hui beaucoup moins de raisons d’éviter les images d’arrière-plan que par le passé.

Découvrez 15 exemples d’email transactionnels – Bienvenue, notification et confirmation.

Idée reçue #7 : Les emails doivent s’afficher à l’identique sur tous les clients de messagerie

Nous en arrivons à la dernière idée reçue sur l’intégration des emails en HTML. Il y a toujours de petites différences d’affichage d’un client de messagerie à l’autre. Plutôt que de les accepter, certains développeurs email s’acharnent à faire en sorte que les emails s’affichent à l’identique sur les différents clients. C’est un travail qui part d’une bonne intention (offrir à tous ses inscrits la même expérience), mais qui s’avère fastidieux. Pire : cela peut conduire à détériorer le code HTML, créant tout un tas d’autres problèmes parfois difficiles à réparer.

Au final, le jeu n’en vaut vraiment pas la chandelle. Surtout qu’en général, encore une fois, ce ne sont que quelques pixels qui varient d’un client à l’autre.

Voilà selon nous les 7 principales idées reçues sur le sujet. Pour finir, rappelons cette évidence : ce n’est parce qu’une pratique a été adoptée pendant des années qu’elle reste valable aujourd’hui. Vous devez toujours questionner les règles et les bonnes pratiques en vigueur – cette remarque s’applique pour tout d’ailleurs !