Figma

Les designs d’email Figma créés en dehors d’Emailify ne sont pas pris en charge

Créez la mise en page de l’email avec les outils de design d’Emailify avant d’exporter du HTML prêt pour la production. Ces outils ajoutent les calques structurés Row, Column, Button et autres dont Emailify a besoin pour générer le HTML. Vous pouvez personnaliser leur contenu et leurs styles après les avoir ajoutés.

Les calques ou frames conçus auparavant dans Figma sans le plugin Emailify seront rendus sous forme d’image statique, et non de texte enrichi ou de contenu HTML.

Forcer le format d’export des images

Emailify détecte automatiquement si un calque contient des zones entièrement transparentes et définit alors PNG comme format d’export par défaut ; sinon, le format est JPG. Vous pouvez forcer le format d’export de n’importe quel calque en JPG ou en PNG en lui ajoutant votre propre réglage d’export.

Blocages avec les réglages Figma « Scroll Wheel » ou « Drag to Pan » activés

Un problème aléatoire peut provoquer un comportement de blocage étrange du plugin ou du canevas lorsque ces réglages (visibles dans la capture d’écran ci-dessous) sont activés.

Si cela se produit dans votre fichier Figma, vous pouvez résoudre le problème en désactivant ces réglages dans Figma : ouvrez le Main Figma Menu, descendez jusqu’à Preferences, puis décochez les réglages Use scroll wheel zoom et Right-click and drag to pan.

Ajouter des liens dans un paragraphe ou un contenu de calque de texte Figma classique

Surlignez le texte à lier dans le calque de texte Figma, puis cliquez sur le bouton d’icône « Link » natif de Figma dans la barre d’outils en haut de Figma : vous pourrez y coller une URL, qu’Emailify rendra automatiquement.

N’utilisez cette méthode que pour les calques de texte de contenu (pas pour les boutons ni les liens de navigation). Elle ne fonctionne que pour les calques de texte de contenu classiques ; pour définir un lien sur un calque de bouton, d’icône de réseau social ou de lien de navigation généré par Emailify, cliquez sur ce calque Figma, puis sur le bouton Settings dans l’en-tête du plugin Emailify, et collez votre URL dans le champ du lien.

Les libellés de boutons ou de liens sont visibles dans Figma mais absents de l’aperçu ou de l’export

Si un bouton est vide ou qu’un lien de navigation manque alors que son texte est visible dans Figma, la cause peut être un problème d’export lié à des données de police mixtes, y compris des polices variables. Une URL de lien correcte ne garantit pas que son libellé a été exporté.

Conservez les libellés sous forme de texte modifiable dans leurs composants Button ou de navigation Emailify d’origine. Fermez et rouvrez Emailify, actualisez l’aperçu, puis exportez à nouveau. Vérifiez le HTML téléchargé avant de l’importer dans votre plateforme d’emailing.

Si les libellés manquent toujours, contactez le support en joignant le frame d’email Figma concerné et le HTML ou le ZIP exporté, afin que nous puissions examiner les calques de texte et reproduire le problème.

Ajouter du texte en exposant ou en indice

Vous pouvez ajouter des exposants et des indices à vos calques de texte Figma : ils seront automatiquement rendus sous forme de balises d’exposant (par exemple sup) ou d’indice (par exemple sub) dans l’export HTML du plugin.

Utiliser des balises de titre (par exemple h1, h2, h3) dans le texte HTML

Si besoin, vous pouvez remplacer la balise de paragraphe par défaut (p) par n’importe quelle balise de titre (par ex. h1, h2). Vous pouvez entourer le contenu de votre calque de texte Figma de la balise de titre voulue : le changement de balise sera géré automatiquement lors de l’export du HTML avec le plugin Emailify.

Extensions de fichier vides avec l’application de bureau Figma sous Windows

Il existe un problème connu avec l’application de bureau Figma (uniquement sous Windows), qui touche aussi les exports de fichiers classiques depuis Figma. Au moment d’enregistrer votre fichier, vous verrez peut-être un libellé « all files ». Si vous l’ignorez et continuez en cliquant sur « Save », le fichier devrait tout de même être enregistré avec la bonne extension et s’ouvrir normalement une fois téléchargé sur votre ordinateur. S’il est malgré tout enregistré sans extension, vous pouvez le renommer pour ajouter manuellement la bonne extension au nom du fichier.

Optimiser vos designs pour réduire la taille de l’export HTML

C’est le nombre de composants Row qui a le plus d’effet sur la taille du HTML exporté, car chaque Row crée un nouvel ensemble d’éléments de tableau. Réutilisez une Row lorsque son contenu peut tenir dans la même structure.

Par exemple, un titre, un sous-titre, un corps de texte et un bouton peuvent partager une seule Column dans une seule Row. Ils n’ont pas besoin de quatre calques Row distincts.

Les options du panneau de réglages d’Emailify n’apparaissent pas quand on clique sur un calque Figma Emailify

Si vous cliquez sur un calque Emailify dans votre design Figma et que les réglages ne s’affichent pas lorsque vous cliquez sur le bouton Settings dans l’en-tête du plugin, votre frame Emailify principal est peut-être imbriqué dans d’autres frames, groupes, etc. Pour résoudre ce problème, sortez votre frame Emailify de tous les frames ou calques imbriqués et replacez-le au niveau de la « page », afin qu’il ne soit imbriqué dans aucun autre calque.

Les paramètres de requête UTM sont supprimés à l’envoi d’un email HTML

Il existe plusieurs raisons pour lesquelles les paramètres de requête UTM peuvent être supprimés à l’envoi de vos emails HTML : depuis un an environ, de plus en plus de navigateurs et d’appareils les retirent automatiquement (pour des raisons de confidentialité). Si les paramètres fonctionnent quand vous ouvrez les liens depuis la fenêtre d’aperçu d’Emailify, mais plus une fois l’email envoyé depuis votre plateforme d’emailing, c’est probablement qu’un service de redirection ou de raccourcissement de liens supplémentaire est appliqué à l’envoi et les supprime ou les casse.

Lenteur du message « Please wait, loading Figma images... »

Une mise à jour de Figma, il y a quelque temps, oblige tous les plugins Figma à attendre le chargement complet de chaque image en pleine résolution de la page Figma active avant de pouvoir exporter la moindre donnée d’image (même s’ils n’ont besoin que d’un seul calque ou d’une seule image).

Pour l’instant, la seule solution consiste à limiter le nombre de frames et de calques sur votre page Figma active, ce qui accélère nettement cette étape au premier lancement du plugin. Par exemple, vous pouvez créer une nouvelle page dans votre fichier Figma, y placer uniquement le ou les frames Emailify sur lesquels vous voulez travailler ou que vous voulez exporter, puis relancer le plugin sur cette page : le chargement devrait être beaucoup plus rapide.

Images exportées pixellisées

Si vous exportez votre email alors que les images sont encore en cours de chargement progressif dans Figma, elles risquent d’être exportées pixellisées, car elles n’étaient pas entièrement chargées dans le fichier Figma au moment de l’export. Pour éviter cela, assurez-vous que toutes les images sont chargées à 100 % et s’affichent nettement dans le fichier Figma avant d’exporter vos emails avec le plugin Emailify.

Pour aller plus loin, vous pouvez utiliser la fonctionnalité « Downsizer » de TinyImage pour réduire vos remplissages d’image à la taille de leur calque : leur poids diminue et ils se chargent beaucoup plus vite dans votre fichier Figma.

Des pointillés apparaissent lors de la modification de PDF dans Adobe Acrobat

Pour résoudre ce problème, désactivez l’option « Show bounding boxes » dans la barre latérale de l’application Acrobat pendant que vous modifiez votre PDF. L’affichage des cadres de sélection en pointillés est activé par défaut par Adobe lorsque vous passez en mode « Edit » sur un PDF ouvert dans l’application ; désactiver l’option « Show bounding boxes » les masque en un clic.

Un VPN peut être nécessaire en Chine

Remarque : si vous êtes en Chine, le serveur des comptes peut être bloqué par la « grande muraille numérique de Chine » (Great Firewall). Si une erreur d’activation s’affiche alors que votre clé est valide, vous devrez probablement utiliser un VPN pour résoudre le problème.

« An error occurred while loading the plugin environment »

Cette erreur peut survenir dans l’application de bureau Figma si le réglage de débogage Use Developer VM de Figma a été activé par erreur. Pour vérifier qu’il est désactivé, faites un clic droit n’importe où sur votre canevas Figma, survolez Plugins, puis Development, et vérifiez que Use Developer VM est décoché. Une fois l’option décochée (sans coche à côté), le plugin Figma devrait se relancer normalement.

Import des images bloqué sur votre réseau

Si vous avez activé la fonctionnalité Upload Hosted Image URLs, ou si vous avez importé l’email HTML dans une plateforme d’emailing avec les options d’export intégrées d’Emailify, le plugin importe automatiquement les images en ligne pour les héberger.

Si un message d’avertissement s’affiche dans le plugin (Images uploads may be blocked on your current network), cela signifie que le plugin ne parvient pas à accéder au service d’import nécessaire pour héberger ces images en ligne.

Cela vient généralement du réseau (par exemple celui de votre entreprise, dont le pare-feu peut bloquer certaines URL) ou du FAI (fournisseur d’accès à internet) auquel vous êtes connecté, qui restreint ou bloque ces URL. Pour résoudre le problème :

• Partagez la connexion de votre téléphone en point d’accès Wi-Fi avec votre ordinateur, puis relancez le plugin Figma Emailify pour voir si le problème est résolu. Si c’est le cas, c’est que votre autre réseau bloquait les requêtes.
• Vous pouvez aussi essayer un VPN, qui fait passer vos requêtes réseau par un tunnel et contourne les blocages réseau.
• Si vous utilisez déjà un VPN, essayez de le désactiver, puis relancez le plugin Figma Emailify pour voir si le problème est résolu.

Si le problème persiste, n’hésitez pas à nous contacter par email.

Clients de messagerie

Le nouvel Outlook peut réécrire les styles après le chargement d’un email

Le nouvel Outlook pour Windows présente un problème de post-traitement signalé : un email peut d’abord s’afficher correctement, puis changer une fois chargé. Outlook semble réécrire une partie du CSS de l’email lors de cette seconde étape de rendu, ce qui peut provoquer des problèmes comme l’empilement vertical inattendu des colonnes desktop.

Ce comportement est irrégulier : un destinataire peut être touché alors que tous les autres voient la mise en page prévue, et des envois de test identiques peuvent s’afficher différemment dans la même boîte de réception. Customer.io a documenté ces symptômes et les constats actuels dans New Outlook, same headache.

Les nouveaux exports d’Emailify incluent une couche de compatibilité défensive pour le cas connu d’empilement des colonnes. Emailify conserve les styles responsive d’origine de MJML et les solutions de repli en tableaux pour Outlook classique, puis place dans le corps de l’email une seconde copie des seules règles de largeur des colonnes desktop générées. Cela aide les variantes web d’Outlook qui suppriment les styles de l’en-tête de l’email, tout en préservant l’empilement mobile et les points de rupture habituels de MJML dans les autres clients.

Vous n’avez pas besoin de refaire le design. Mettez Emailify à jour et exportez à nouveau l’email pour que le HTML généré contienne cette solution de repli avant d’envoyer un nouveau test.

Si vous rencontrez ce problème :

• Ouvrez l’email concerné dans une fenêtre séparée plutôt que dans le volet de lecture ou d’aperçu d’Outlook. Dans les cas signalés, l’email s’affiche souvent correctement dans la fenêtre séparée.
• Envoyez le même HTML exporté à un autre destinataire ou vers un autre client de messagerie pour vérifier si le problème ne concerne qu’un seul utilisateur d’Outlook.
• Si des envois identiques s’affichent différemment, téléchargez les deux messages reçus en fichiers .eml et comparez leur HTML avant de modifier le design ou l’export Emailify.

Cette solution de repli réduit le problème signalé d’empilement des colonnes desktop, mais Emailify ne peut pas contrôler toutes les réécritures de styles effectuées après la livraison. Si le problème persiste et que le HTML reçu est inchangé, évitez de modifier en profondeur le design dans le seul but de corriger un aperçu Outlook irrégulier.

Le transfert d’un modèle d’email HTML le casse

Malheureusement, lorsqu’une personne transfère à quelqu’un d’autre un email HTML personnalisé qu’elle a reçu, l’email est souvent cassé visuellement une fois transféré.

En effet, les différents clients de messagerie modifient (ou suppriment) une partie du code HTML lors du transfert, ce qui casse l’email ; comme l’explique cet article de Litmus, When Forwarded Emails Break :

Chacun sait que tous les clients de messagerie affichent les emails différemment. Lorsqu’un abonné transfère un email, certains clients de messagerie modifient le code du message transféré. Ils peuvent notamment supprimer certains éléments HTML, envelopper l’email dans un blockquote ou ajouter des classes à votre code, autant de changements qui peuvent casser votre design et rendre l’email moins fonctionnel pour la personne qui le reçoit.

Une solution courante pour limiter ce problème consiste à proposer une version « Web link » consultable dans le navigateur si l’email ne s’affiche pas correctement, généralement ajoutée en haut de l’email (comme celle-ci dans MailChimp) ; si besoin, vous pouvez aussi l’ajouter ailleurs dans l’email sous forme de lien à partager.

Mes emails arrivent dans les spams. Quelle peut en être la cause ?

Voici quelques raisons courantes pour lesquelles vos emails peuvent arriver dans les spams :

• Trop de liens : chaque lien influe sur la délivrabilité. Supprimez les liens qui ne sont pas indispensables, y compris les liens superflus vers les réseaux sociaux, pour améliorer l’arrivée en boîte de réception.
• Mauvaise réputation d’expéditeur : si votre domaine ou votre IP présente un historique de faible engagement, de rebonds ou de plaintes, les fournisseurs de messagerie peuvent signaler vos emails.
• Contenu jugé indésirable : un usage excessif du langage promotionnel (par exemple « Gratuit ! », « Agissez maintenant ! », « Offre à durée limitée ») ou trop d’images pour trop peu de texte peut déclencher les filtres.
• Problèmes d’authentification : vérifiez que SPF, DKIM et DMARC sont correctement configurés pour votre domaine d’envoi.
• Faible engagement : si vos abonnés n’ouvrent ou ne cliquent jamais, vos prochains emails ont plus de chances d’être classés comme spam.
• Qualité de la liste : envoyer à des listes anciennes ou achetées peut provoquer des rebonds et des plaintes pour spam qui nuisent à votre score d’expéditeur.

Commencez par simplifier votre email, vérifier l’authentification de votre domaine et supprimer les liens superflus : ces changements suffisent souvent à améliorer la délivrabilité.

Les ajustements du mode sombre ne sont pris en charge que dans les apps Apple Mail d’iOS et de Mac

Pour l’instant, la prise en charge des styles d’ajustement pour le mode sombre dans les clients de messagerie reste assez faible ; gardez-le à l’esprit et concevez vos emails en considérant ces ajustements du mode sombre comme une « amélioration progressive ».

Il est aussi utile de recourir à d’autres techniques de design astucieuses pour concevoir votre email en tenant compte du mode sombre, comme solution de repli dans les autres clients de messagerie.

La solution de contournement de Gmail pour le texte blanc des boutons a un objectif plus restreint : préserver le texte blanc pur des boutons. Elle ne permet pas de conserver tel quel un texte noir sur fond clair dans le mode sombre de Gmail.

Fines lignes blanches sous-pixel entre les images empilées sur mobile

Cela arrive parfois avec des images en ligne pleine largeur : selon la largeur de l’appareil, lorsque l’image est réduite sur mobile, des « sous-pixels » peuvent s’ajouter à sa hauteur (c’est ce qui laisse ce léger espace entre les images et laisse transparaître l’arrière-plan).

La solution de contournement la plus rapide consiste à ajouter un calque Wrapper autour de vos calques « Row » qui contiennent ces images, puis à définir l’arrière-plan de ce Wrapper comme un « Linear Gradient » avec votre couleur d’arrière-plan (par exemple gris) des deux côtés du dégradé. L’arrière-plan est ainsi rendu sous forme d’image, ce qui évite que la couleur d’arrière-plan CSS soit remplacée ou inversée en noir en mode sombre, et fournit un arrière-plan homogène derrière vos rangées d’images pour masquer les espaces sous-pixel.

Les polices Google et personnalisées intégrées ne sont prises en charge que dans les apps Apple Mail d’iOS et de macOS

Pour l’instant, les polices personnalisées ne sont prises en charge que dans Apple Mail sur iOS et macOS parmi les clients de messagerie. Il est donc recommandé d’utiliser des polices compatibles web pour vos calques de texte Figma, ce que vous pouvez définir dans le panneau Configure Fonts de la fonctionnalité « Preview » d’Emailify.

Par ailleurs, certains fournisseurs de services d’emailing (comme MailChimp) les suppriment activement avant même l’envoi de l’email, pour garantir que seules des polices compatibles web sont utilisées.

Emailify inclut tout de même les @imports des polices Google et définit une police de repli compatible web (par exemple « Arial », « Georgia » ou « Courier ») lorsqu’une police Google est utilisée pour du texte enrichi. Elles s’afficheront dans tous les clients de messagerie qui prennent en charge @font-face dans les emails.

Utilisez les polices personnalisées dans vos images. Si vous devez garantir qu’une police personnalisée s’affiche de la même façon dans tous les clients de messagerie, il peut être judicieux de placer vos calques de texte dans un frame « Image ». Ce texte sera exporté comme partie intégrante de l’image et ne dépendra donc pas de la prise en charge des polices web personnalisées pour s’afficher correctement.

Les éléments de formulaire ne sont pas pris en charge dans les emails

La prise en charge des éléments form dans les emails HTML reste assez faible, et leur présence peut entraîner le classement des emails en spam, etc. Mieux vaut donc éviter pour l’instant d’utiliser des formulaires natifs dans les emails HTML.

La meilleure solution de contournement consiste à créer un beau bouton d’appel à l’action (CTA) dans votre design Emailify, qui renvoie vers l’URL d’un formulaire externe comme Google Forms ou Typeform, afin de recueillir les informations des destinataires dans le navigateur.

Comprendre le blocage des images dans certains clients

Voici deux très bons articles qui expliquent ce qu’est le blocage des images et quels clients de messagerie l’activent par défaut (principalement Outlook), alors que d’autres clients comme Gmail, Android, Apple/iOS, etc. affichent tous les images par défaut.

How Image Blocking Works in Email

Email Image Blocking: Answering the What, Why, Where, Who, and How

Malheureusement, cela ne dépend pas du fait que les images soient sécurisées (SSL) ou non : le blocage s’applique systématiquement à toutes les images de l’email.

Le bon côté, c’est que les destinataires qui utilisent l’un des premiers clients cités ont généralement l’habitude de ce comportement et de cliquer sur le bouton « afficher les images », ou ont plus probablement déjà activé l’affichage des images par défaut pour les emails entrants.

Texte violet dans Gmail (plusieurs envois de test avec le même objet)

Si vous envoyez plusieurs tests d’un email vers un compte Gmail, vous remarquerez peut-être qu’une partie du texte apparaît en violet foncé.

Ce n’est pas un problème de votre code HTML : cela se produit lorsque Gmail considère que plusieurs emails envoyés le même jour avec le même objet sont des réponses les uns aux autres. Dans ce cas, il affiche le fil des emails en « vue Conversation ».

Pour en savoir plus sur la vue Conversation de Gmail, consultez la documentation de Google :

La coloration violette est une fonctionnalité d’affichage qui n’existe que dans l’affichage où elle est vue. Elle n’est envoyée dans aucun message, et vous pouvez le vérifier avec la fonctionnalité « Afficher l’original » de Gmail, à condition de connaître un peu le code HTML.

La couleur s’applique au texte repris d’un message précédent de la conversation en cours, et elle est visible pour les destinataires parce qu’ils utilisent eux aussi Gmail et disposent eux aussi de copies des messages précédents de la conversation. Ce qui est coloré dans leur conversation peut être très différent de ce qui l’est dans la vôtre.

Les clients de messagerie ajoutent des liens bleus aux dates, numéros de téléphone et adresses

C’est un problème de longue date : certains clients de messagerie ajoutent automatiquement des liens aux dates, numéros de téléphone et adresses, et leur appliquent aussi leurs propres styles de couleur (généralement des liens bleus).

Emailify applique automatiquement tous les correctifs de code recommandés pour limiter ce problème dans certains clients de messagerie, mais les clients sont souvent mis à jour pour contourner ou neutraliser ces correctifs.

Il existe 2 méthodes supplémentaires pour empêcher le client de messagerie d’ajouter automatiquement des liens (toutes deux mentionnées dans les articles ci-dessus) :

La méthode n° 1 consiste à appliquer au préalable un lien factice (par exemple vers votre propre site web) à chacun de ces calques de texte dans Figma, puis à supprimer tout soulignement dans Figma et à choisir la couleur de votre choix (pour qu’il ne semble pas cliquable). Une balise de lien entoure ainsi déjà le texte de la date, et le client de messagerie n’essaiera pas d’appliquer automatiquement son propre lien non stylé à la place.

La méthode n° 2 consiste à ajouter une entité HTML invisible spéciale (‌) juste après le premier caractère de chacune de vos dates, numéros de téléphone ou adresses (par exemple 6‌75 Massachusetts Ave, Cambridge, MA 02139), ce qui devrait amener le client de messagerie à considérer qu’il ne s’agit pas d’une date et l’empêcher d’y appliquer automatiquement un lien.

Certains VPN peuvent empêcher l’affichage des images importées

Si vous avez activé la fonctionnalité Upload Hosted Image URLs, ou si vous avez importé l’email HTML dans une plateforme d’emailing avec les options d’export intégrées d’Emailify, il existe un cas limite très rare où certaines adresses IP attribuées par des VPN sont bloquées par l’hébergeur d’images, ce qui empêche le chargement des images.

Si des images ne se chargent pas, c’est probablement la cause (désactivez temporairement votre VPN pour le vérifier vous-même).

Les signatures d’email ne prennent pas en charge les polices personnalisées

Contrairement aux emails HTML complets, dans lesquels il est possible d’intégrer des polices personnalisées (mais uniquement pour Apple Mail : les autres clients comme Gmail et Outlook ne prennent en charge aucune police personnalisée intégrée), les signatures d’email ne prennent pas en charge de balise style permettant d’ajouter le moindre code d’intégration de police. Concevez donc plutôt vos signatures avec des polices système compatibles web.

L’app Gmail pour iOS n’affiche pas les styles responsive mobiles

La raison principale : si l’une des propriétés ou l’un des styles CSS de la requête @media contient une faute de frappe (par exemple padding-bottm au lieu de padding-bottom) ou s’il y a un retour à la ligne au milieu d’une propriété de style (par exemple padd nouvelle ligne ing-top), l’app Gmail ignore tous les autres styles et n’affiche aucun ajustement responsive pour mobile.

Cela ne devrait pas arriver avec le code exporté nativement par le plugin, mais peut se produire si vous modifiez manuellement le code HTML après l’avoir exporté depuis Emailify (ou si votre plateforme d’emailing modifie le code ou ajoute des limites de longueur de ligne).

Limite de 500 caractères par ligne dans les emails HTML

Emailify limite le HTML exporté à 500 caractères par ligne. Bien que la limite officielle soit de 998 caractères, des lignes plus courtes évitent des problèmes d’affichage et de livraison constatés dans Outlook et chez certains fournisseurs de services d’emailing.

Les VPN peuvent empêcher certains liens vers les réseaux sociaux de s’ouvrir correctement

Bien que cela semble rare, si certains liens vers des réseaux sociaux (par exemple Facebook, Instagram) ne s’ouvrent pas correctement, c’est probablement la cause (désactivez temporairement votre VPN pour le vérifier vous-même), et non un problème lié à l’email HTML ou aux liens eux-mêmes.

Outlook

Les coins arrondis (border-radius) ne s’affichent pas dans Outlook

Malheureusement, la propriété border-radius n’est pas prise en charge dans Outlook : les coins resteront donc toujours carrés. Consultez la liste de prise en charge de border-radius pour savoir plus précisément quels clients de messagerie prennent en charge cette propriété CSS.

La hauteur des boutons s’effondre sur Outlook.com (faute de véritable URL)

Si la hauteur d’un composant bouton se réduit à la taille du calque de texte qu’il contient, c’est qu’Outlook.com se comporte ainsi lorsque le href ne contient pas une véritable URL (par exemple [replaceLinkInHere] au lieu d’une vraie URL comme https://google.com). Définissez une véritable URL sur votre composant bouton en cliquant sur le calque du bouton dans Figma, puis en utilisant le bouton Settings du plugin pour y coller votre URL.

Ligne blanche de 1px sur les rangées « en ordre inversé » dans certaines versions d’Outlook

Certaines versions d’Outlook présentent un bug connu avec le réglage d’inversion des colonnes : une ligne blanche de 1px peut apparaître à côté de l’une des colonnes. C’est l’une des bizarreries d’affichage d’Outlook dues au moteur de rendu de Microsoft Word, et elle peut se produire lorsque la Row inversée a aussi une marge intérieure (padding).

La meilleure solution de contournement consiste à retirer le padding de ce calque Row inversé, à envelopper la Row dans un Wrapper et à appliquer plutôt le padding au Wrapper extérieur. L’espacement visuel reste le même, mais vous évitez le bug d’affichage d’Outlook sur la Row inversée elle-même.

Cette solution de contournement correspond à l’approche évoquée dans le ticket GitHub de MJML correspondant.

Outlook transforme automatiquement les dates et heures en liens de calendrier bleus

Pour empêcher Outlook d’interpréter le texte comme une date ou une heure et de l’afficher automatiquement sous forme de lien, vous pouvez insérer une entité HTML « espace sans chasse » (​) entre les jours, les dates et les heures pour casser la détection de motifs d’Outlook, comme dans cet exemple testé et fonctionnel : Monday​ — Friday 8​am to 5​pm

Les accents (signes diacritiques) des majuscules sont coupés

Si un calque de texte est en majuscules et que certains caractères comportent des signes diacritiques (par exemple Ä, Ö, Ü) dont l’accent supérieur ne s’affiche pas dans Outlook, c’est parce que la valeur d’interligne (« line height ») du calque de texte dans Figma est inférieure à la taille de police (« font size »). Outlook rogne en effet tout contenu qui ne tient pas dans la hauteur d’interligne (contrairement aux autres clients, qui le laissent simplement déborder).

Pour résoudre ce problème, il suffit d’augmenter l’interligne pour qu’il soit un peu plus grand que la taille de police. Par exemple, si un calque de texte a une taille de police de « 24px » et un interligne actuel de « 23px », augmentez l’interligne de « 23px » à « 28px » dans Figma (afin de laisser assez de marge en hauteur pour les accents qui dépassent la hauteur des capitales de 24px) : les accents et signes diacritiques s’afficheront alors correctement dans Outlook, sans être coupés par un interligne trop faible.

Le bug aléatoire de la « ligne de 1px » d’Outlook

Il existe un problème très agaçant, connu sous le nom de bug de la ligne de 1px d’Outlook, qui apparaît de façon aléatoire dans certaines versions d’Outlook :

Outlook ajoute des lignes supplémentaires à nos emails. Ces lignes héritent de l’arrière-plan défini sur votre balise body... pour ne rien arranger, ce bug semble se produire au hasard, même s’il apparaît plus souvent sur les machines Windows 10 que sous Windows 7.

Comme l’indique l’article ci-dessus, le phénomène est assez aléatoire et il n’existe pas de correctif fiable ; on peut toutefois généralement le résoudre par tâtonnements, en ajustant la taille de police du texte situé au-dessus de l’endroit où la ligne apparaît. Par exemple (extrait de l’article) :

Pour certains, la solution consiste simplement à passer de tailles de police impaires à des tailles paires. Par exemple, si vous avez une taille de police de 13px ou 15px, essayez de la passer à 14px.

Un autre bon article de synthèse, Fixing White Lines in Outlook, donne aussi davantage de détails et des correctifs possibles.

Pour aller plus loin, l’article Outlook 2016 madness and the weird 1px thin horizontal lines détaille davantage le problème de fond, et cette discussion détaillée sur le forum Litmus avance aussi des hypothèses sur ses causes et des pistes de dépannage.

Gmail

Gmail tronque l’email

Gmail tronque les emails dont la taille de message dépasse 102 Ko et masque le contenu complet derrière un lien « View entire message ». Pour l’éviter, utilisez le bouton Preview pour voir la taille de votre fichier HTML avant l’export, et supprimez autant de contenu que possible pour réduire la taille du fichier.

Si l’email est toujours tronqué alors qu’il est en dessous de la limite de taille du fichier HTML, c’est très probablement dû à un caractère UTF-8 présent dans le contenu de l’email, qui peut aussi amener Gmail à tronquer l’email. La meilleure solution consiste à remplacer le caractère UTF-8 par sa version encodée en HTML (par exemple &copy au lieu de ©), ce que le plugin fait automatiquement.

Cela peut aussi arriver si vous envoyez des emails avec le même objet (par exemple lorsque vous vous envoyez plusieurs tests) : Gmail regroupe alors les emails dans un seul fil et peut tronquer le contenu des envois suivants. Pour contourner ce problème, veillez à toujours utiliser un objet différent (par exemple « Test v1 », « Test v2 », etc.).

Le texte blanc des boutons devient noir dans l’app mobile Gmail en mode sombre

Gmail (et d’autres apps) applique automatiquement des styles de mode sombre à votre email, boutons compris, lorsque le thème système de l’utilisateur est réglé sur le mode sombre.

Pour les boutons censés avoir un texte blanc en mode clair comme en mode sombre :

1. Définissez le calque de texte du bouton en blanc pur (#FFFFFF) dans Figma.
2. Sélectionnez le composant Button, ouvrez Settings et définissez aussi sa couleur de texte d’ajustement pour le mode sombre en blanc pur (#FFFFFF).
3. Exportez à nouveau l’email et envoyez un test vers l’app mobile Gmail où vous avez constaté le problème.

Lorsque les deux couleurs sont définies en blanc pur, Emailify ajoute du code de compatibilité supplémentaire destiné à préserver le texte blanc du bouton. Cette solution de contournement ne préserve pas un texte noir ou d’une autre couleur que le blanc, et ne verrouille pas la couleur d’arrière-plan du bouton. Si votre design nécessite un texte noir sur fond clair, conservez ces couleurs prévues et testez ce design séparément : passer le texte en blanc modifierait le design au lieu de répondre à ce besoin.

Si le résultat diffère toujours de votre design, contactez le support en joignant le HTML ou le ZIP exporté, une capture d’écran, l’app de messagerie et l’appareil utilisés, ainsi que les couleurs de texte et d’arrière-plan que vous voulez conserver. Indiquez aussi les réglages que vous avez déjà essayés. Consultez design et tests du mode sombre pour le workflow complet et ses limites.

Colonnes empilées sur desktop dans Gmail

Certains fournisseurs de services d’emailing (comme MailChimp) tentent de modifier le HTML de votre email avant son envoi, ce qui peut entraîner l’empilement de certaines colonnes de votre email dans Gmail sur desktop, au lieu de leur alignement sur une même rangée.

En général, ces plateformes modifient votre HTML pour « intégrer en ligne » (inlining) les styles dans vos éléments HTML. Or Emailify intègre déjà automatiquement tous les styles CSS en ligne, pour que vos emails soient prêts pour la production. Si vous trouvez dans les options HTML ou d’import de votre fournisseur de services d’emailing un réglage permettant de « désactiver » cette intégration en ligne ou cette modification, le problème devrait être résolu.

Si vous ne savez pas si le problème vient de votre fournisseur de services d’emailing ou du code lui-même, utilisez un service gratuit comme htmltest.email (qui ne modifie pas votre HTML) pour vous envoyer un email de test. Si le test fonctionne depuis htmltest.email, c’est que votre fournisseur de services d’emailing modifie votre HTML avant l’envoi.

Gmail sur iOS impose un interligne minimal

Si vous définissez line-height sur une valeur inférieure à la font-size actuelle, Gmail la remplace automatiquement par line-height:normal;. Ainsi, line-height:1, line-height:1em et line-height:100% fonctionnent comme prévu, mais line-height:0.9, line-height:0.9em et line-height:99% sont tous convertis en line-height:normal;.

Il en va de même pour les valeurs en px : font-size:20px; line-height:19px ne fonctionnera pas, mais font-size:19px; line-height:19px fonctionnera.

Pour résoudre le problème, assurez-vous simplement que l’interligne de votre calque de texte est supérieur ou égal à la taille de police.

L’app Gmail pour iOS n’affiche pas les styles responsive mobiles

La raison principale : si l’une des propriétés ou l’un des styles CSS de la requête @media contient une faute de frappe (par exemple padding-bottm au lieu de padding-bottom) ou s’il y a un retour à la ligne au milieu d’une propriété de style (par exemple padd nouvelle ligne ing-top), l’app Gmail ignore tous les autres styles et n’affiche aucun ajustement responsive pour mobile.

Cela ne devrait pas arriver avec le code exporté nativement par le plugin, mais peut se produire si vous modifiez manuellement le code HTML après l’avoir exporté depuis Emailify (ou si votre plateforme d’emailing modifie le code ou ajoute des limites de longueur de ligne).

Gmail traduit à tort des emails rédigés uniquement en anglais dans d’autres langues

Si votre email contient surtout des blocs d’image sans texte enrichi, ou de nombreux blocs d’image avant le texte enrichi placé plus bas, Gmail pense parfois que l’email est rédigé dans une autre langue et propose de le traduire en anglais, et ce bien qu’Emailify ajoute automatiquement un attribut lang="en" aux balises html et body du code.

Comme l’indique cette discussion à ce sujet sur les forums Litmus :

Nous avons constaté (empiriquement) que les emails contenant beaucoup de CSS et de HTML avant le moindre contenu réel sont classés comme anglais, même si leur contenu est dans une autre langue.

Notre solution de contournement consiste à envoyer un email multipart texte et HTML, avec une version texte placée avant la partie HTML. Bien sûr, le texte doit être conséquent, pas seulement « Bonjour ... », sinon les balises HTML et le CSS restent dominants.

L’algorithme de traduction ne semble faire aucun effort pour retirer le HTML et le CSS du corps de l’email, ou s’il le fait, il tronque peut-être le message avant de les retirer et se retrouve donc avec très peu de contenu pour la détection. (Il est facile aujourd’hui d’arriver à plus de 5000 caractères d’en-têtes et de CSS avant la moindre ligne de contenu.)

GIF

Convertir des vidéos en GIF animés pour vos emails

Les balises video natives ne sont malheureusement pas prises en charge dans les emails HTML : la meilleure façon d’ajouter des images animées ou du contenu vidéo à vos designs d’email HTML est donc d’utiliser des GIF, qu’il s’agisse d’un fichier GIF téléchargé sur internet ou d’un GIF que vous avez créé vous-même.

Si vous avez déjà une vidéo à utiliser comme GIF, l’application gratuite Gifski vous aide à convertir de courts fichiers vidéo en GIF animés à utiliser dans vos designs d’email.

Un tutoriel vidéo très complet présente également les différentes façons d’utiliser des GIF dans vos designs Emailify et de les inclure dans vos exports HTML.

Les couleurs et dégradés des GIF paraissent un peu granuleux

Les GIF diffèrent un peu des images JPG/PNG classiques, car ils ne peuvent contenir que 256 couleurs au maximum. Si vous utilisez des images très détaillées ou des dégradés avec beaucoup de variations de couleur, il est normal, en raison de cette limite du format GIF, que le résultat soit moins net ou moins fidèle en couleurs que les images d’origine utilisées comme source du GIF.

La transparence ne s’affiche pas dans les GIF

Le format GIF accepte soit une opacité de 0 %, soit une opacité de 100 %, mais rien entre les deux. Vous pouvez donc avoir un GIF animé avec un arrière-plan entièrement transparent derrière des éléments entièrement opaques et visibles. Les calques doivent donc être soit entièrement transparents, soit non : tout calque dont l’opacité est inférieure à 50 % sera transparent, et tout calque dont l’opacité est supérieure à 50 % sera opaque.

Signaler les GIF transparents dans Figma. Emailify essaie de détecter automatiquement si votre GIF a un arrière-plan transparent ; si votre GIF a besoin de transparence et que le plugin ne le détecte pas de lui-même, ajoutez le mot Transparent n’importe où dans le nom de votre calque Figma (par exemple My Layer Name - Transparent) pour forcer son export avec un arrière-plan transparent.

Conserver votre fichier GIF d’origine à l’export (en gardant les proportions)

Si vous déposez votre GIF dans Figma et redimensionnez le calque proportionnellement pour conserver ses proportions d’origine, Emailify utilisera automatiquement le fichier GIF d’origine dans vos exports.

À l’inverse, si vous donnez à votre calque Figma des proportions différentes de celles du GIF d’origine, Emailify devra recréer votre GIF pour tenir compte de la zone d’image recadrée, ce qui peut alourdir le fichier GIF et ralentir l’export.

Le GIF ne s’affiche pas dans Gmail (limite de taille de fichier)

Si vous avez utilisé des GIF dans votre design mais qu’ils n’apparaissent pas lors d’un envoi de test vers une boîte Gmail, c’est probablement que la limite du cache d’images de Gmail est atteinte, ce qui empêche leur affichage.

Lors de l’export en HTML, Emailify essaie de compresser les GIF volumineux pour les faire passer sous la limite de taille de fichier de Gmail, ce qui devrait résoudre le problème dans presque tous les cas (sauf si le GIF est exceptionnellement long, très lourd ou doté d’une fréquence d’images très élevée au départ).

Klaviyo

L’éditeur de modèles Klaviyo plante (parfois) lorsque des GIF sont utilisés dans le design de votre email

Un bug aléatoire de Klaviyo provoque une erreur 500 (erreur interne du serveur) et affiche une page indiquant Something is amiss. We're on it. ; cela semble surtout se produire lorsque le modèle est « Editable ».

Klaviyo a connaissance de ce bug, mais aucune correction ne semble prévue à court terme.

Une solution de contournement consiste à retirer le GIF de votre design Figma avant d’exporter le HTML pour Klaviyo, puis à importer l’image GIF séparément dans Klaviyo une fois que l’éditeur de modèles s’est chargé sans l’erreur ci-dessus.

Marge intérieure supplémentaire autour des blocs de texte dans les modèles Klaviyo modifiables

Klaviyo a mis à jour son éditeur et l’impose à tous les modèles depuis le 6 juin 2023. Malheureusement, si vous exportez des emails HTML avec l’option Editable Content activée dans Emailify, Klaviyo applique par défaut environ 18px de marge intérieure (padding) supplémentaire autour de chaque élément de texte, sous la forme d’un attribut style en ligne sur un nouvel élément td qu’il injecte dans le HTML lorsque le modèle est modifiable.

L’activation de l’option Force the padding added by Klaviyo's new editor to be 0px dans Emailify ajoute bien automatiquement du CSS supplémentaire pour supprimer ce padding dans tous les clients mobiles et dans les clients desktop autres qu’Outlook, comme Gmail, etc. En revanche, Outlook affichera toujours ce padding, sauf si chacune des valeurs « Padding » des blocs de texte modifiables de votre modèle est manuellement passée à « 0 » lors de la modification de l’email de votre campagne dans l’éditeur Klaviyo.

Le texte d’aperçu Klaviyo est dupliqué ou affiche du corps de texte en trop

Définissez le texte d’aperçu à un seul endroit. Si vous avez déjà saisi un Preheader Text dans Emailify, laissez vide le champ de texte d’aperçu de Klaviyo. Si vous préférez gérer le texte d’aperçu dans Klaviyo, laissez vide le preheader d’Emailify pour cet export.

Si Klaviyo affiche encore du corps de texte en trop après le texte d’aperçu prévu, activez Add Whitespace to Preview Text dans les options d’export d’Emailify et exportez à nouveau l’email. Cela ajoute un espaceur de compatibilité masqué après un preheader non vide, mais l’affichage dans la boîte de réception peut encore varier entre Klaviyo et les différents clients de messagerie.

Consultez Définir l’objet et le preheader de vos emails HTML pour le workflow complet du preheader.

MailChimp

L’activation des images modifiables utilise des images @1x plus floues (au lieu des images Retina @2x)

Vous pouvez rendre les images de votre modèle modifiables dans MailChimp avec l’option Editable Images, mais malheureusement, MailChimp ne prend pas en charge les images Retina @2x modifiables : elles seront donc en @1x.

Si vous préférez des images Retina @2x non modifiables, laissez cette option désactivée.

MailChimp supprime le style des liens lors de l’intégration de balises <link> de polices Typekit

MailChimp supprime les styles des liens lorsqu’une feuille de style Typekit personnalisée est ajoutée à votre email. Plus précisément, si vous incluez une balise comme : <link rel="stylesheet" href="https://use.typekit.net/lml7iwl.css">

dans le <head>, MailChimp supprime tous les attributs style de vos balises <a>. Retirer cette balise corrige le problème et rétablit les styles de vos liens.

Si vous souhaitez tout de même utiliser vos polices Typekit, vous pouvez passer par la fonctionnalité Web Fonts intégrée au plugin. Au lieu de lier la feuille de style, vous aurez besoin de l’URL directe du fichier de police .woff2 figurant dans votre fichier CSS Typekit (par exemple : https://use.typekit.net/...). Collez cette URL dans le panneau Configure Fonts du plugin : il générera automatiquement le style @font-face correspondant à vos noms de polices Figma dans le HTML. Consultez le tutoriel vidéo étape par étape pour en savoir plus.

Notez que les polices web personnalisées ne fonctionnent que dans Apple Mail. Les autres clients de messagerie (comme Outlook ou Gmail) ne les prennent pas en charge : nous vous recommandons donc de définir une police de repli compatible web dans le plugin pour contrôler ce qui s’affiche. Beaucoup d’utilisateurs trouvent plus simple de concevoir avec des polices compatibles web dans Figma, mais l’ajout de polices web personnalisées reste une amélioration progressive appréciable pour les utilisateurs d’Apple Mail.