Workflow d’une intégration HTML d’email

Un titre bien sérieux, n’est-ce pas ? Et pourtant, chers amis, il m’est parfois nécessaire de revêtir un caractère de solennité pour aborder des sujets graves. Car je vais tenter ici de répondre à un questionnement existentiel : quelle méthode de travail est appliquée dans notre équipe de production d’intégration HTML d’email ?

Mise en garde : nous souhaitons ici partager l’état d’esprit, le quotidien, les habitudes, les méthodes de travail, et le processus d’intégration que nous suivons chez Badsender. Ce point de vue n’engage que nous, tant chaque développeur a sa propre façon de travailler.

1. C’est toujours les mêmes gestes. Toujours. D’abord, la réception des éléments. Toujours. (Zinedine Zidane)

C’est l’étape indispensable à tout commencement de développement. Pas d’éléments, pas d’intégration. Pas d’intégration… Pas d’intégration.

Il nous faut une maquette. C’est la base.

Et par maquette, j’entends une maquette « Desktop » finalisée, définitive, conçue correctement sur Photoshop, avec les calques correctement rangés et dissociés. On évitera les maquettes réalisées sur inDesign ou Illustrator, qui ne sont pas toujours adaptées au web. Et en plus, une maquette responsive (parce que quand même, ne pas faire de responsive dans l’emailing, c’est plus possible, tut tut tut). En bonus, on réclamera des JPEGs de confirmation, pour s’assurer qu’il s’agisse bien de la même chose (On voit de sacrés différences parfois, croyez-moi !).

N’hésitez pas à demander des maquettes adaptées au Retina si cela fait partie des exigences de vos clients : le design sera alors conçu sur des dimensions doublées (pour un email de 600 pixels de large, la maquette sera de 1200 pixels de large. J’étais pas en série S pourtant au lycée…).

Ensuiiiiiiiiiiiite ?

Il vous faudra aussi réceptionner un brief des liens à mettre en place. Pour faire simple : un fichier Excel, dans lequel chaque visuel ou texte qui doit être cliquable dans l’email aura une url valide indiquée.

Tips : Proposez à votre client de concevoir un « url builder », soit un fichier Excel avec quelques méthodes de concaténation pour que chaque url adopte le code de tracking pertinent. Pour ça, rien de plus simple, une bonne petite fonction façon =CONCATENER(cellule; cellule;), et basta !

Et quoi d’autre ?

Enfin, dans les éléments à réceptionner, il sera aussi requis les gifs animés (si gifs animés il y a), les vidéos (si vidéos il y a), les typographies, les contraintes spécifiques d’intégration à respecter (selon la plateforme de routage parfois)… Bref, tout ce qui peut être utile à l’intégrateur mais qu’il n’a pas par défaut sur sa machine.

2. Vient la phase de découpes/tranches (et il ne s’agit pas de sifflard)

La plupart du temps, nous établissons d’abord une découpe « mentale » de la maquette. On se transforme limite en Professeur Xavier, de chez les X-Men : nous cherchons ainsi à décider quel élément sera en texte brut et mis en forme via CSS, quel élément sera en image… C’est une étape cruciale et pleine de questionnements : Faut-il concevoir une image propre au Desktop et une autre pour le Responsive pour cet élément ? Comment se comportera la maquette sur Mobile ? Vaut-il mieux concevoir deux cellules côte à côte ou une seule ? Est-ce que je vais passer ces textes en HTML avec une typographie particulière, ou plutôt les exporter en PNG ? Quelle sera la dégradation alors ? Puis-je manger un BN entre 14 et 15h00 ?

L’ensemble de ces questionnements trouve souvent une réponse dans l’analyse des statistiques de consultation des précédentes campagnes. N’hésitez pas à demander ces données à votre client si elles existent : elles vous seront d’une grande aide pour savoir, par exemple, que des coins arrondis sur un Call-to-Action sont peut-être « risqués » à concevoir en HTML et CSS si le support de consultation principal est le logiciel de bureau Outlook… Take care of it! (ça veut rien dire…)

Ce qui va dans un sens doit aussi aller dans l’autre sens ! C’est donnant-donnant les amis : ne décidez pas tout seul de tout cela. Discutez-en avec votre client, avertissez-le et éduquez-le aux bonnes pratiques mais n’imposez pas forcément tout en bloc, au risque de le froisser… Et un client froissé est un client mal repassé ! Ça, c’est fait…

3. Et puis zou, on code !

Sur cette étape, je n’ai malheureusement pas grand chose à ajouter… Si ce n’est ceci :

• Veillez à n’utiliser que des hacks & tips vérifiés et testés dans la balise <style> (un border-collapse:collapse appliqué sur tous les table par exemple pourrait vous amener d’étranges rendus sur les coins arrondis ou sur des bordures en dashed)
• N’oubliez pas d’ajouter les correctifs au 120dpi.
• Essayez d’améliorer au maximum l’accessibilité de votre email en respectant les bonnes pratiques sur l’accessibilité dans l’email marketing : cela passe, entre autres choses, par l’utilisation de balises sémantiques (<h1>,<h2>,<h3>,<p>,<ul>,<li>,<strong>,<em>…).
• Ajouter l’attribut role="presentation" à chaque <table> de votre code qui ne serait pas un tableau de données.
• Renseignez l’attribut lang à la balise <html>.
• Indiquez un titre pertinent dans la balise <title>.
• Rendez les noms de vos class et id dans les media queries explicites, pour les utiliser au mieux et rendre le code lisible et compréhensible par tout autre intégrateur. Ainsi, le code suivant : .textaligncenter {text-align:center !important;} sera sans doute plus explicite que .txt_01 {text-align:center !important;}. Enfin, je crois… Non ?
• N’oubliez pas de concevoir un preheader dans l’email.

Concernant le logiciel d’édition de code avec lequel vous allez développer, aucune préférence ! Chez Badsender, nous codons aussi bien sur Dreamweaver que sur SublimeText, c’est dire ! Donc, à chacun son kiff ! Si vous cherchez de l’aide pour en choisir un, allez voir là-haut si j’y suis !

4. S’assurer de la propreté du code HTML

Une fois la maquette codée en HTML et CSS, il nous reste quelques étapes à suivre. Vous allez voir, ça va aller vite. Encore 5 kilomètres et on rentre.

Commentez, si vous le pouvez !

Les commentaires dans le code HTML sont une information précieuse pour la mise à jour ou le debugage d’une intégration HTML d’emailing. Pensez au futur intégrateur qui récupérera peut-être un jour le code que vous avez développé : Le pauvre ! Lui fournir des indications simples sur le fonctionnement du code, c’est lui faire preuve de respect. Et il ne vous en sera que grandement reconnaissant ! Give me a high five, colleague!

L’encodage des caractères spéciaux : é devient é, et caetera, et caetera…

Je vous recommande d’encoder tous les caractères spéciaux présents dans le code : à, é, è, ô, ç, etc… Il existe des plateformes pour cela (parce que faire ça en public, c’est limite ! Un peu de pudeur que diable !). Nous avons développé chez Badsender l’outil KrktR. On garantit rien sur la qualité du code délivré, mais bon, c’est pour nous, c’est cadeau !

La suppression des media queries inutiles : on passe un coup de balai !

Lorsqu’on utilise des Master Template de code HTML, il est récurrent de trouver des gros pavés de media queries, présents pour pallier à tous les cas de figure des comportements des modules sur mobile. Cependant, dans une optique de fournir un code propre sur soi et le plus léger possible, nous vous proposons d’utiliser des outils comme emailcomb ou alter.email pour « nettoyer » le code HTML final. Vous allez voir, vous ne pourrez bientôt plus vous en passer… Une vraie drogue.

Et la minification ?

Personnellement, j’suis pas fan. Ou alors seulement si votre code approche des 102 kilooctets, et donc du seuil fatidique posé par Gmail. Mais sinon, on s’en passe. D’abord parce que la minification de votre code HTML risquerait de casser certaines de vos media queries (si si, c’est du vécu) mais aussi et surtout parce que du même coup, cela peut supprimer vos commentaires, ou rendre tout simplement illisible et incompréhensible l’ensemble de l’intégration.

5. Les tests d’email preview, les BATs, les tests d’email rendering… Appelez-les comme vous voudrez !

Naaaaaaaaaan mais n’essayez même pas de négliger cette étape. Vous ne pouvez pas, que dis-je… VOUS NE DEVEZ PAS fournir une intégration sans l’avoir testé auparavant ! Pour cela, pas 1, pas 3, mais bien 2 méthodes (qui, comme le pinard, devraient être obligatoiiiiires ! Fais attention Gérard !) :

• Le test sur support physique : prenez tous les supports que vous avez à disposition immédiate. Le PC de bureau, l’ordinateur portable du taf, la tablette du gamin, le téléphone portable de votre femme, tous les supports vous dis-je ! Installez tous les logiciels de messagerie et applications de messagerie que vous pouvez. Ouvrez aussi un ensemble d’onglets sur plusieurs navigateurs, vers les webmails où vous auriez des comptes de tests (créez-en un max, ça coûte rien ! Vous vous en servirez pour votre compte Carrouf’ !).
  
  Et shootez ! Bim ! Il ne vous reste plus qu’à attendre la réception du BAT, et de vous assurer que tout est ok : les plateformes d’email preview sont un allié indispensable, mais elles ne seront sans doute jamais en mesure de présenter l’ensemble des résolutions existantes sur le marché, ni la totalité des versions logicielles, des navigateurs de consultation, ou bien même des vitesses de connexion… Rien ne vaut donc un bon vieux test des familles sur support physique pour estimer au mieux le temps d’affichage d’un email selon la méthode de connexion (wifi, 3G, 4G), ou pour avoir le rendu selon le support de consultation, selon le navigateur…

• Les plateformes d’email preview. La tombe de mes morts, vous les connaissez ! Litmus et EmailonAcid pour ne citer que les plus connues bien sûr. Prenez le temps de détailler le rendu de chaque screenshot. Déjà, parce que vous payez pour ça et qu’un sou est un sou, et parce qu’en plus, il y a parfois des petites subtilités. Le travail de l’intégrateur emailing, c’est aussi le sens du détail…

Pour faciliter et fluidifier le worklow de l’intégrateur emailing, EmailonAcid propose d’ailleurs une nouvelle fonctionnalité : Le « Campaign Precheck« . Pratique, même si ça ne va pas faire le job à votre place non plus hein, faut pas pousser !

Vous voyez des choses à ajouter ? Vous faites comment vous chez vous ? Vous passez un coup de serpillière avant de fermer la boutique ? Dites-nous, on est des p’tits curieux ! Plaaaaaace aux commentaires ! Déchaîne la fureur Mitch !