HTML et e-mail : 6 erreurs courantes à éviter

Publié: 2017-12-21

Dans cet article

Créer un e-mail avec du code HTML ? Voici 6 erreurs trop fréquentes que vous devriez éviter, afin de profiter des avantages de communications par e-mail rationalisées et propres.

Erreur 1. Utilisation de code trop verbeux

On sait que grâce au HTML et au CSS on peut construire une structure d'email et lui donner une forme, ou plutôt un format, qui permet d'afficher un certain type de police, une couleur de fond spécifique, des images etc.

Nous allons maintenant voir comment les balises HTML et CSS remplissent la même fonction à certains égards et finissent par se chevaucher. Prenons un exemple pratique : définir la couleur de fond d'un tableau à la fois en HTML et en CSS.

Le code est affiché dans l'image. Vous pouvez voir qu'il y a deux points où la couleur de fond est définie :

bgcolor = "#e75c00" est l'attribut de la table des balises ;
background-color est l'attribut CSS appliqué à la table.

Les deux attributs font la même chose, et donc ils se superposent : ils imposent la couleur orange (#e75c00 selon le format hexadécimal) sur le fond du tableau.

Le point critique devrait maintenant être plus clair : les définitions de propriétés HTML et CSS peuvent s'empiler les unes sur les autres. En fait, lors de la refonte ou de la modification du même modèle de courrier électronique, le code peut souvent s'enliser dans des propriétés redondantes qui remplissent la même fonction.

Et ce n'est pas tout. Étant donné que les styles en ligne peuvent être appliqués à chaque élément, ce cas (pervers) peut également se produire :

Un navigateur (ou un client de messagerie) lirait le code plus ou moins comme ceci :

Appliquer un fond gris ( bgcolor = " #efefef " ) au tableau
Dix appliquent un fond noir ( bgcolor = "#000000" ) à la ligne
Enfin, appliquez un fond orange ( background-color: #e75c00 ) à la cellule contenant le texte Hello World!

Le résultat final est identique dans cet exemple et dans le précédent : du texte blanc sur fond orange.

Le problème est que trois règles de fond différentes ont été définies dans le second cas. Celui vu par l'utilisateur est celui défini par rapport à la cellule, car le navigateur lit le code séquentiellement (table -> tr -> td). Puisque la dernière définition a été définie sur le <td> , c'est précisément ce qui sera affiché.

Il est clair qu'une grande partie du code n'est pas nécessaire. Ce n'est pas seulement parce que la seule couleur d'arrière-plan affichée est celle appliquée à la cellule, mais aussi parce que l'un des objectifs d'un bon marketing par e-mail est de garder les communications aussi claires que possible. Très verbeux, le code redondant n'est pas un code léger.

Nos recommandations :

Gardez le code aussi propre que possible
Évitez les répétitions inutiles lors du formatage du code
Privilégier les styles en ligne
Essayez de construire une structure modulaire pour le code de communication
Essayez de garder le code aussi ordonné que possible grâce à l'indentation (il existe plusieurs services en ligne qui le font, comme HTMLformatter ou Clean CSS), pour pouvoir avoir une vue d'ensemble de la structure de la communication
Gardez une trace de l'historique des modifications apportées aux macros sur un modèle

Erreur 2. Commenter excessivement le code

Comme pour la plupart des langages, il est également possible d'ajouter des commentaires au HTML. Qu'est-ce qu'un commentaire dans un script HTML ? C'est une partie de la liste qui est ignorée par le programme qui lit et exécute le code.

Un exemple de commentaire est donné dans la figure ci-dessous :

Comme vous pouvez le voir, tout ce qui se trouve entre <!- et -> n'est pas seulement d'une couleur différente (selon le programme d'édition), mais surtout, il n'est pas affiché à l'écran.

Cela permet d'insérer des « communications de service » concernant le code qui a été écrit, ou des instructions pour des parties qui ne sont pas encore terminées ou qui doivent être améliorées.

Il existe également une autre façon d'utiliser les commentaires. Étant donné que tout ce qui est inclus entre les marqueurs d'ouverture et de fermeture n'est pas affiché, il est possible de masquer des parties de page entières avec, comme le montre l'exemple suivant. En effet, on constate que seules trois lignes sont visibles à l'écran au lieu des quatre inscrites dans le code.

C'est un outil utile, bien sûr, mais il ne faut pas en abuser. S'il est vrai que le code commenté n'est pas affiché, il reste néanmoins dans la communication envoyée, l'alourdissant.

Notre conseil :

Utiliser judicieusement les commentaires, par exemple pour indiquer le début et la fin des structures de communication, ou pour insérer des informations utiles pour le développeur
Ne soyez pas long dans les commentaires et, mieux encore, écrivez-les en anglais
Supprimer le code commenté avant l'envoi, car il n'est pas nécessaire à des fins de communication

Erreur 3. Mauvaise gestion du contenu des e-mails

Lors de la conception d'un email, avant même d'écrire une seule ligne de code, il est bon de définir certains paramètres qui ne pourront pas être modifiés dans la phase de réalisation ultérieure, et par conséquent lors de la production.

Certains de ces paramètres incluent :

Largeur de l'e-mail
Taille de l'image
Nombre d'images
Taille de la police utilisée dans l'en-tête
Taille de la police du corps du texte

Etc. Un paramètre qui est souvent omis est celui du nombre maximum de frappes pour tout élément de texte.

À ce stade, vous pourriez objecter que nous sommes coupables d'être fanatiques des règles, mais il y a deux bonnes raisons d'être si strict. La première est conceptuelle et la seconde opérationnelle.

Sur le plan conceptuel, le contenu (texte, images, etc.) et le contenant (structure HTML) sont deux entités distinctes avec une hiérarchie très précise qui voit le premier subordonné au second.

En fait, le contenu doit être adapté au contenant, et non l'inverse. L'architecture de la communication est construite lors de l'écriture du code. Cela définit le conteneur et, une fois mis en forme, le conteneur reste tel quel que soit le contenu, même si l'e-mail a été créé pour être réactif.

En résumé – et paraphrasant Bruce Lee – le contenu est comme de l'eau : si vous mettez de l'eau dans une tasse, elle devient la tasse ; si vous mettez de l'eau dans une bouteille, elle devient la bouteille ; si vous mettez de l'eau dans une théière, elle devient la théière.

Vous ne pouvez pas vous attendre à ce qu'une tasse devienne une bouteille, et une théière ne sera jamais une tasse. Par conséquent, le texte (ou l'image ou le bouton) doit s'adapter à la structure qui le contient, et non l'inverse.

La deuxième raison est plus opérationnelle. Si tous les paramètres pour composer la communication sont connus exactement a priori, alors non seulement il est possible de créer des communications plus efficaces lors de la phase de rédaction, mais aussi des communications plus équilibrées.

Prenons un exemple plus concret : supposons que nous ayons un DEM avec deux produits côte à côte. Un produit est généralement associé à :

Une image
Le nom du produit
La description du produit
Le prix
Le CTA menant à la page produit

Or, puisque les produits sont côte à côte, les pièces doivent nécessairement être équilibrées.

Cela signifie que les images doivent avoir la même hauteur, les textes descriptifs doivent avoir une longueur similaire et les deux CTA ne doivent pas être trop dissemblables.

Ignorer ou ne pas respecter ces principes de base peut conduire à des cas comme l'image ci-dessus.

La symétrie entre les deux éléments est rompue car le titre du produit à gauche est si long qu'il couvre trois lignes, tandis que celui de droite est si court qu'il ne remplit qu'une seule ligne. Une discorde s'est introduite, ce qui fragilise finalement toute la communication.

Le respect de ces règles devient encore plus important lorsque l'on pense au monde mobile, où tous les appareils ont des résolutions très disparates : des 1125 x 2436 px de l'iPhone X aux 1440 x 2960 px du Samsung Galaxy S8, en passant par les 768 x 1280 px du Microsoft Lumia 1020.

Lorsque cette grande diversité se superpose à la jungle dense des clients de messagerie, cela signifie que nous n'avons pas le contrôle total de l'affichage du DEM, car il n'y a pas de code définitif qui s'adapte aux pixels dans tous les cas. Donc, si vous ne pouvez pas le contrôler par code, vous devez essayer de le faire indirectement, en modifiant les autres parties qui composent un email, comme la longueur des textes ou la taille des images.

Nos recommandations :

Définir toutes les parties du modèle
Rester cohérent entre les différentes parties de la communication
Respectez les règles que vous vous êtes données
Les règles peuvent être enfreintes, mais cela doit être fait en toute conscience
Si le modèle ne répond pas à vos besoins, vous pouvez commencer à penser à en définir un nouveau

Erreur 4. Numéros de téléphone interactifs et adresses erronés

Parfois, les expéditeurs d'e-mails ajoutent leurs coordonnées, notamment dans le pied de page. Cela comprend généralement une adresse et un numéro de téléphone.

Alors qu'un numéro de téléphone et une adresse peuvent être des informations standard pour les e-mails des clients de bureau, bien qu'ils soient rarement utilisés, ces éléments sont particulièrement importants lorsqu'il s'agit du côté mobile.

Cela se produit principalement pour deux raisons :

Vous pouvez ouvrir une application qui gère les données en un clic (calendrier, téléphone, navigateur)
L'espace d'affichage est réduit, et ainsi chaque information a une plus grande visibilité, même si elle est située dans le pied de page

Il est donc important de ne pas oublier également ces détails lors du développement de la communication, car leur comportement varie selon les différents appareils.

Prenons un moment pour examiner un exemple créé ad hoc via une simulation. Les deux exemples sont affichés par l'iPhone 6+ iOS 9.

L'image de gauche montre la newsletter reçue par l'utilisateur avec le texte saisi directement, sans aucune mise en forme.

Tout est correct d'un point de vue technique, mais il faut tenir compte du fait que le code est interprété par l'application de messagerie elle-même sur le mobile. Il « lit » le texte de l'e-mail et lorsqu'il reconnaît le texte sous la forme d'une date, d'une adresse ou d'un numéro de téléphone, il relie automatiquement le lien actif à l'application respective, c'est-à-dire le calendrier, la carte ou le téléphone.

Tout cela est très pratique, car un simple clic vous permet de passer un appel téléphonique, de programmer un événement ou d'ouvrir la carte pour définir un itinéraire. Les seuls qui peuvent être tristes à ce sujet sont l'art et le développeur, qui n'aiment pas voir les liens bleus et le soulignement. Alors, que devrions-nous faire? Comment devrions-nous procéder?

Vous pouvez utiliser une petite solution de contournement ou une astuce pour ramener les choses à la normale. Soyons clairs : bien qu'elles enfreignent les règles du HTML bien formaté, les solutions de contournement sont indispensables dans le vaste océan des clients de messagerie.

Si l'objectif principal d'un développeur est de rendre la communication visible sur autant de clients que possible, alors il doit faire des compromis et adopter les solutions de contournement.

Voyons donc comment le code a été modifié.

Pour ce qui est du téléphone, c'est simple : comme la balise d'ancrage permet de définir un numéro de téléphone en utilisant tel dans la propriété href , on ajoute le numéro de téléphone sans espace ni ligne de séparation.

Cependant, nous devons agir différemment pour une adresse ou une date. Pour ceux-ci, il faut définir une classe (.address) qui impose la balise d'ancrage qui insérera automatiquement la couleur au sein du client (couleur : #ffffff ;). Surtout, il faudrait supprimer le soulignement, qui est une caractéristique par défaut de chaque lien (text-decoration:none;).

Notez que les deux attributs de la classe d' adresse ont !important , qui doit être appliqué par le client quelle que soit la propriété. Sans cela, rien ne garantit que la solution de contournement fera son travail.

Nos recommandations :

Faites toujours attention à la façon dont la communication peut être affichée sur les mobiles (c'est-à-dire en faisant des tests)
Dans la mesure du possible, utilisez des micro-fixes pour rendre les communications adaptées aux mobiles
Ne présumez pas que ce qui est bon pour le bureau est également bon pour le mobile
Connaissez votre public : quelle technologie utilise-t-il ? Quels appareils ? Quels médias ?
Utilisez des tests internes pour expérimenter vos propres communications, en particulier lorsqu'il y a des mises à jour substantielles des applications clientes de messagerie

Erreur 5. Ne pas nettoyer les balises abandonnées ou vides

En poursuivant l'objectif d'essayer de minimiser le poids global de la communication, nous devons faire attention aux parties du code existant qui ont été vidées de leur contenu naturel.

Donnons tout de suite un exemple concret : une balise <font> , peut-être avec une série de styles en ligne, qui ne contient aucun texte. De toute évidence, le côté e-mail ne pourra rien lire, mais la balise de formatage <font> continue d'exister et d'occuper de l'espace physique dans l'e-mail.

Un autre exemple classique est celui des balises d'ancrage <a> qui n'ont pas d'objet lié, donc quelque chose comme : <a href="http://www.mailup.com" style="color:#00000;text-decoration:none"> </a>.

Habituellement, ces « erreurs » sont présentes dans ce code qui a été retravaillé ou utilisé à plusieurs reprises, de sorte que différentes parties, telles que des images, des liens et des textes, ont été insérées, modifiées ou supprimées. Alternativement, cela pourrait être une indication d'une utilisation incorrecte d'un éditeur WYSIWYG. En effet, s'ils sont mal ou imprudemment utilisés, ces éditeurs ont le défaut d'ajouter du code à du code, puisque chaque élément prédéfini a normalement une partie du code défini dès la création de l'éditeur lui-même.

Le programme applique le modèle de manière non critique à chaque fois que l'élément sélectionné est inséré et, par conséquent, ce problème peut survenir lorsque vous réécrivez la même partie de l'e-mail un nombre suffisant de fois.

Notre conseil :

Lors de l'écriture du code, vérifiez toujours qu'il n'y a pas de balises abandonnées ou vides
Si vous utilisez un éditeur WYSIWYG et qu'il est possible d'accéder au code, effectuez un contrôle pour vous assurer que tout est en ordre et qu'il n'y a pas ce genre d'erreurs

Erreur 6. Utilisation de HTML non validé

Parler de validation du code de messagerie est un sujet épineux.

« La plupart des pages du World Wide Web sont écrites dans des langages informatiques (tels que HTML) qui permettent aux auteurs Web de structurer du texte, d'ajouter du contenu multimédia et de spécifier l'apparence ou le style du résultat.
Comme pour chaque langage, ceux-ci ont leur propre grammaire , vocabulaire et syntaxe , et chaque document écrit avec ces langages informatiques est censé suivre ces règles. Les langages (X)HTML, pour toutes les versions jusqu'à XHTML 1.1, utilisent des grammaires lisibles par machine appelées DTD, un mécanisme hérité de SGML.
Cependant, tout comme les textes en langage naturel peuvent contenir des fautes d'orthographe ou de grammaire, les documents utilisant des langages de balisage peuvent (pour diverses raisons) ne pas suivre ces règles. Le processus consistant à vérifier si un document suit réellement les règles de la ou des langues qu'il utilise est appelé validation , et l'outil utilisé pour cela est un validateur. Un document qui réussit ce processus est appelé valide .
Avec ces concepts à l'esprit, nous pouvons définir la « validation du balisage » comme le processus de vérification d'un document Web par rapport à la grammaire (généralement une DTD) qu'il prétend utiliser ».
Définition W3C

Le W3C nous aide en tant que gardien et garant du code en fournissant un outil de validation de code dont l'analyse indique les erreurs et suggère des moyens de les corriger. Grâce à cet outil, il est possible d'identifier et de corriger des erreurs structurelles plus importantes.

Il ne faut pas oublier que l'Email Marketing a une double situation :

D'une part, HTML est un langage standardisé avec des règles et des structures très précises
De l'autre, une série de solutions de contournement qui ne sont pas standard, et sont souvent mal vues, mais qui fonctionnent bien si vous voulez avoir une visualisation correcte sur les clients de messagerie

Ces deux aspects sont comme un vieux couple marié, où la passion s'est depuis longtemps éteinte. Ils ne savent pas pourquoi ils vivent ensemble, mais ils sont obligés de le faire en faisant des compromis.

Alors pourquoi parler de validation de code ? Est-ce que ça fait du sens? Quels sont les compromis ?

Il est logique de parler de validation de code lorsqu'il est placé dans une perspective plus large, sans entrer trop dans les détails. Par conséquent, en ce qui concerne la structure, les modules à partir desquels l'email est composé et les tableaux qui constituent l'épine dorsale de la communication, il est parfaitement logique d'avoir un code aussi propre et aussi proche du standard dicté par le W3C que possible.

Cependant, nous devons être conscients de la réalité, et le compromis consiste donc en la création d'une structure solide et fonctionnelle, à laquelle les solutions de contournement sont ajoutées comme une sorte de réglage fin pour étendre la visualisation correcte au plus grand nombre de clients possible.

On sait déjà que les contournements ne sont que des exceptions à la règle, ou des techniques pas parfaitement orthodoxes, issues de connaissances accumulées par l'expérience, mais leur existence n'a de sens que parce qu'elles permettent de visualiser correctement le code, sans aucune dépagination.

Notre conseil :

Si vous avez des doutes sur le code, la validation peut servir d'outil d'analyse rapide et efficace
La validation de code peut être un bon outil pour identifier rapidement les plus grosses erreurs dans une liste de code
Le code validé est toujours un excellent point de départ pour faire évoluer et adapter par la suite la communication avec des solutions de contournement, pour la rendre la plus universelle possible
La validation peut être vue comme un « entretien » pour le code, en particulier sur les modèles qui ont été fréquemment manipulés et retravaillés
Au fur et à mesure que vous acquérez de l'expérience, constituez une petite bibliothèque de solutions ad hoc pour divers clients afin de gagner du temps lors de la résolution de problèmes.