Intégration email dans Outlook : des cassures dans un email très long ?

Un bon vieux bug à l’ancienne TMTC, voilà ce qui me manquait ! Récemment, lors de l’intégration HTML d’une campagne, j’ai rencontré un problème récurrent sur mes tests d’email preview sur la plateforme Emailonacid. Sur Outlook 2007 et Outlook 2010, un énorme décalage apparaissait dans mes découpes…

Bon, les problèmes de rendu sur Outlook 2007 et 2010, jusque-là, rien d’étonnant. Mais je n’avais rencontré qu’une seule fois ce problème (alors très vite résolu en redécoupant mon tableau, mais sans chercher réellement l’origine du problème et sa solution). Cette fois, j’avais besoin de comprendre !

La première piste consisterait à débugger l’intégration de l’email. Peut-être une balise mal fermée ? Une duplication d’attribut qui pourrait faire « sauter le code » ? Un souci dans mes hacks CSS en début d’intégration ? Or, cette méthode n’est pas forcément productive dans ce cas : En effet, en supprimant tel ou tel module, le problème n’apparaît plus. Vous vous dites donc : « ok, si je supprime ce module, le problème n’apparaît plus. Donc, le problème vient de ce module ! » Et c’est parti pour une demi-journée de debuggage dans le vent… J’ai pris cher… C’est Grégory Van Gilsen, de l’équipe Badsender, qui m’a soufflé la solution (quel swag ce Greg !)

Car le problème ne vient pas (vraiment) d’un module en particulier mais bien… De l’emailing de façon générale et de la façon d’intégrer ! La solution nous est venu d’un article rédigé en 2011 par Emailonacid (eux-mêmes ! :D). Le problème n’est donc pas d’hier (et sa solution non plus d’ailleurs). Or, très peu de blogueurs ou pro de l’email marketing évoquent ce sujet (et particulièrement en français). Je décide donc de vous l’exposer dans la langue de Molière.

Outlook 2007 et 2010 utilisent le moteur de rendu de Microsoft Word pour afficher un email. Jusque-là, normalement, rien de bien nouveau. Cependant, il faut savoir que Microsoft Word propose différents modes d’affichage : Mode Lecture, Page et Web. Outlook utilise la vue « Web » : c’est une sorte d’éditeur WYSIWYG qui émet son propre code HTML. Au sein de ce mode existe des « limites de texte ». Concrètement, si vous avez une <table> de hauteur supérieure à une certaine valeur (la limite de texte), un <br> sera inséré et votre <table> va se rompre en plusieurs tableaux, créant ainsi des cassures au sein de votre contenu. Attention, comprenez bien ! Nous n’avons pas spécifié de hauteur fixe à notre <table>. C’est la hauteur que son contenu lui impose.
La valeur avait été donnée par Emailonacid à l’époque : cela correspondait à 23,7 pouces, soit environ 1790 pixels. Et comme on le dit souvent, une image vaut mille mots.

Alors, voici pour l’exemple, un email rapidement conçu. C’est parti pour les tests Emailonacid, ça va être skate, brunch et confettis ! Ne prenez pas en compte ni son graphisme ni son contenu, il est factice et généré pour l’exemple. De toute façon, ce n’est pas ici notre centre d’intérêt. Voici donc une capture d’écran du rendu Apple Mail 8.

outlook-bug-cassure-1

Tout est donc ok : aucune cassure, tout apparaît correctement et comme prévu sur la maquette. Voici maintenant une capture du rendu sur Outlook 2007 (c’est identique pour Outlook 2010).

outlook-bug-cassure-2

Le problème est clair, mais soulignons-le tout de même

outlook-bug-cassure-3

D’énormes cassures font leur apparition et décalent l’ensemble de mes cellules. Pour mieux comprendre, voici un schéma de la découpe.

outlook-bug-cassure-4

Cette découpe peut sembler étrange mais je suis obligé de passer par là si je veux pouvoir attribuer un lien différent à chaque visuel. Mais, en encadrant chaque tableau de mon intégration par une bordure de 5px sombre, je me rends encore mieux compte de ces sauts d’intégration. Vous les trouverez d’ailleurs démarqués par des flèches rouges.

outlook-bug-cassure-5

De nombreux commentaires ont été laissés sur la page dédiée au bug sur Emailonacid. Une solution alors évoquée à l’époque dans les commentaires du sujet Emailonacid consistait à ajouter un commentaire conditionnel entre les deux tableaux côte à côté, et donc de les séparer de cette manière :

<!–[if gte mso 9]>
</td>
<td valign=”top”>
<![endif]–>

Or ce correctif ne semble plus fonctionner à ce jour (du moins, par pour notre exemple et dans nos tests). D’autres palliatifs avaient aussi été évoqués mais, selon moi, la solution la plus simple consiste à « séparer », découper votre tableau trop grand. Créez alors un nouveau tableau dans lequel vous viendrez placer la suite de votre email. Ainsi, la hauteur du tableau n’excède plus les 1790 pixels de haut, et les cassures n’apparaissent plus sur Outlook 2007 ou 2010. Izi !

A propos de Thomas Defossez

Thomas a démarré sa carrière en tant qu'intégrateur emailing chez Experian avant de créer sa propre agence web. Aujourd’hui, Thomas a décidé de se focaliser sur l’email afin d’être un spécialiste de l’intégration HTML de ce médium. Depuis fin 2014, Thomas collabore à divers projets de l'Agence Badsender.com.

Un commentaire

  1. Effectivement, il faut créer des tableaux différenciés pour éviter qu’un tableau atteigne la taille fatidique …
    Le moteur de rendu de word sur un client de messagerie fait bien des dégâts 😉

Laisser un commentaire

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