Ne faites pas à vos emails ce que vous ne feriez pas à votre projet Web

L’email, c’est un peu le tonton anarchiste qui milite toujours à la CGT (Confédération Générale du Travail) à 75 ans. Parce que oui, l’email, c’est plus vieux que le Web. Parce que oui, le HTML (HyperText Markup Language) pour l’email ça ressemble au Web d’il y a 25 ans. Et oui, l’email est souvent invité aux réunions de familles, mais il n’a droit qu’au dessert. Et encore !

Pourtant, dans tout projet numérique, l’email continue à tenir une place importante. C’est le seul canal push (qui va vers l’internaute) qui permette via un identifiant universel (l’adresse email), d’envoyer de l’information à un internaute. Et que l’on ne nous dise pas que la notification push (in-app ou web) fait le même job. Le seul vrai concurrent de l’email sur le push, c’est le SMS (Short Message Service)… et comment dire… s’ils ont leur utilité, les SMS restent quand même limités.

L’email mérite mieux qu’un serveur planqué dans un placard

Envoyer vos emails directement depuis votre serveur Web ? Techniquement, il va partir du serveur. Est-ce qu’il va arriver à destination ? Pas certain, vraiment pas certain. Et puis le problème avec les placards, c’est qu’ils prennent la poussière.

Que ce soit pour des questions de délivrabilité ou de maintenance, privilégiez l’envoi des emails de vos projets depuis un outil emailing dédié. Il y en a littéralement des centaines. Et pour les besoins de base, ils ne sont pas très chers. Donc, pas de serveur email maison, à moins d’investir beaucoup de temps et de moyens. Et pas de code d’email hébergé dans un coin de votre backend. Cet email, il va évoluer. Hébergez le HTML directement dans l’outil emailing sélectionné. Et déclenchez son envoi par API (Application Programming Interface).

Illustration totalement non-réaliste du bazar que constitue un projet email. Image générée par Dall‑e.

Le quadriptyque : données, transactions, contenus, campagnes

Si, si, ça existe le quadriptyque (on peut même parler de polyptyque) mais c’est un autre débat.

Vous allez agréger des données et contenus de sources diverses pour alimenter vos emails. Il va donc falloir prendre de la hauteur sur votre architecture.

Ceci n’est pas une grille de bingo mais bel et bien ce que vous trouverez sur votre chemin pour faire des emails : CRM (Customer Relationship Management), Data lake, CMS (Content Management System), Backoffice (maison avec tout le legacy qui fait plaisir), email builder, CDP (Customer Data Platform), DMP (Data Management Platform), CMP (Cookie Management Platform), Automation, IA (Intelligence Artificielle), DAM (Digital Asset Management)…

Une fois de plus, l’outil de gestion de campagne va être un acteur de premier ordre si vous souhaitez envoyer des emails. Il va devoir potentiellement communiquer avec tout ce beau monde. Oui, tout ce beau monde qui va potentiellement communiquer avec l’outil emailing.

Interopérabilité, sécurité, maintenabilité et autres joyeusetés qui vont vous en faire suer. Vraiment, ne le négligez pas.

En matière de données, nous vous conseillons de procéder par étape afin de définir lesquelles sont essentielles, et lesquelles sont accessoires. Cela définira aussi, après inventaire, une bonne partie de votre logique de gestion de campagne. Dans l’ordre :

  1. Listez l’ensemble des messages prévus dans le projet (et laissez de la place pour l’imprévu) : un petit inventaire ne fait jamais de mal. C’est le début de tout, c’est comme pour vos pages web, mais pour vos emails c’est encore plus précieux puisqu’ils sont déclenchés par la donnée. Il ne s’agit pas uniquement de les ranger sagement.
  2. Identifiez la donnée qui déclenchera l’envoi d’un email ou qui permettra de définir un ciblage : oui, c’est à réaliser pour chaque message. L’envoi d’un email automatique peut être déclenché par un nouvel événement, par une transaction, par l’atteinte d’un seuil ou par une date. Pensez aussi aux données qui vont permettre de définir des segments si l’envoi est déclenché manuellement ou périodiquement.
  3. Déterminez les données nécessaires à la personnalisation du contenu : le contenu, c’est aussi de la donnée. Et il est important de comprendre comment elles sont structurées et d’où elles viennent (votre CMS, un flux, …). Dans le contenu d’un email, il est aussi de bon ton d’ajouter de la personnalisation. Celle-ci peut être relativement simple (Chère Madame Michu) ou plus complexe lorsqu’il s’agit de personnaliser le contenu en fonction du profil du destinataire. Nous parlerons alors de blocs conditionnels.
  4. Repérez les indicateurs clefs de performance (KPIs, Key Performance Indicators) que vous désirez analyser : le petit dernier. Comme il est mignon. Taux d’ouverture, taux de délivrabilité, taux de clic… sont les indicateurs classiques des performances d’un email. Mais peut-être avez-vous besoin de plus, comme par exemple des taux de conversion. Et peut-être avez-vous besoin de croiser ces indicateurs avec d’autres données afin de segmenter vos rapports.

Une fois l’inventaire réalisé, il devrait être plus simple de valider où seront stockés les emails, quel système gérera la logique de déclenchement, et quel autre système gérera la génération du contenu (s’il est en partie automatisé).

Point sur la délivrabilité et il ne sera pas petit

Pour vous expliquer pourquoi vous n’avez pas envie de gérer ça vous-même ! Si vous êtes déjà persuadés, passez au point suivant. 😉

Si vous avez déjà configuré un domaine afin qu’il puisse expédier des emails, vous savez sans doute qu’il y a plein de trucs à configurer dans votre serveur DNS (Domain Name System) : SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), DMARC (Domain-based Message Authentication, Reporting, and Conformance), BIMI (Brand Indicators for Message Identification)…

Si vous ne l’avez jamais fait, Dieu vous en préserve.

Exemple d’email envoyé par le WordPress des 24 jours de web depuis un serveur Gandi pas taillé pour ça : pas de signature DKIM, pas de chiffrement de la transaction SMTP (Simple Mail Transfer Protocol), mauvais alignement des domaines…

Hé bien vous savez quoi ? Ce n’est que l’arbre qui cache la forêt des outils emailing. Parce qu’en utilisant un outil dédié plutôt qu’en configurant votre propre serveur email aux petits oignons (il est d’ailleurs probable que vous oubliez une bonne partie des oignons dans l’aventure), vous vous évitez de :

  • Configurer les feedback loops (boucles de rétroaction) : mécanisme permettant de récolter l’identité des auteurs de plaintes spams (possible chez Microsoft, Yahoo, Laposte.net…) pour les rejeter des envois suivants.
  • Vous inscrire dans les différents outils de postmaster : outils qui permettent de collecter des informations utiles à l’évaluation de la réputation de l’expéditeur·ice et qui servent au pilotage de la délivrabilité email.
  • Configurer le reverse DNS de vos adresses IP (Internet Protocol) : parce que les serveurs email « maison » ne sont pas toujours utilisés par des personnes bien intentionnées, vous aurez besoin de travailler votre identité d’expéditeur·ice.
  • Mettre en place une mécanique de gestion des désabonnements : vous savez, recueillir les optouts, les réinjecter directement dans une base de données et vous assurer que l’adresse ne soit plus jamais sollicitée.
  • Mettre en place le List-Unsubscribe : c’est un « truc » technique qui permet aux messageries de présenter un lien de désinscription dans son interface (vous avez peut-être vu ça dans Gmail ou Apple Mail).
  • Configurer le module de signature DKIM de votre MTA (Mail Transfer Agent) : quand vous utilisez un outil du marché, DKIM, c’est une ligne sur votre serveur DNS. Si vous le faites vous-même, ça veut dire générer des clefs, configurer votre MTA, …
  • Développer (ou configurer) un module de tracking (suivi) des ouvertures et de clics : Ahaha ! C’est un de mes préférés. Ça a l’air simple, un pixel de tracking, une redirection et c’est fini. Que nenni. Vous oubliez les fausses ouvertures du cache d’Apple qu’il faut traiter, les robots cliqueurs qu’il faut détecter… et plein d’autres joyeusetés.
  • Analyser et catégoriser les bounces (rebonds) : vous saviez qu’un code SMTP peut avoir plusieurs significations en fonction de la messagerie qui l’émet ? Non ? Et si nous vous disons que pour un même code, il y a plusieurs messages textes, et qu’il faut les traiter différemment. Bonjour le casse-tête si vous avez une dette technique de plusieurs années et que vous envoyez à des dizaines de destinations différentes.
  • Email throttling : j’adore ce terme. L’email throttling, c’est le fait de modifier la vitesse d’envoi des emails en fonction du serveur de destination (Gmail, Microsoft, Yahoo, Orange…) pour s’adapter à leurs préférences. Une science complexe…
  • … j’en avais d’autres, mais j’arrête là, j’espère que le tracking, les bounces et le throttling vous ont définitivement ôté l’envie de bricoler sur l’envoi de vos emails. Cet article n’a pas été écrit pour traiter de la configuration d’un serveur email.

Retenez que les outils emailing font tout cela pour vous, que c’est indispensable, et que le faire « maison », c’est beaucoup de temps, de ressources et d’apprentissage.

Le HTML pour l’email, non, ce n’est pas sale !

Pwarf, des emails à intégrer moi je suis dev front, je vaux mieux que ça.

Et par conséquent, travail d’intégration HTML inadapté aux contextes et contraintes des différents environnements d’ouverture. Une structure de mise en page en Grid CSS (Cascading Style Sheets), c’est beau, oui, mais Gmail et d’autres ne vont pas la supporter en rendu. Un responsive mobile first, l’idée est bien, mais où sont les commentaires conditionnels pour Outlook ?

Mode sombre, accessibilité, écoconception « OSEF (on s’en fout) ce sont des emails, personne ne les lit. Viens, vas‑y, on fait du full image au moins ça passera partout ».

Quel mépris de « class ».

Engagez vos équipes techniques et offrez leur les outils adaptés

Si le Web s’est professionnalisé, les frameworks multipliés à outrance, et bien pour le mail c’est plus confidentiel mais sachez que ça existe.

Faites bosser vos équipes de développement sur vos emails avec le framework Maizzle, ils vous diront merci.

Un npm install et ils seront aux anges de retrouver un environnement de travail entièrement configurable, Tailwind CSS pour des classes utilitaires, un build avec post processeur et des variables de template qui passent par Front Matter.

Capture d’écran de la page d’accueil de Maizzle (pour vous prouver qu’en email, il est possible de coder de manière très organisée). Allez voir la doc, elle est au top !

Augmentez le niveau de qualité de vos intégrations

Responsabilisez vos équipes de conception sur les sujets tels que l’accessibilité, le responsive design, l’écoconception, le mode sombre, l’optimisation des ressources… Inutile de vous parler également de la mise en place de tests, qu’ils soient automatisés ou non, des checklists, du contrôle avec des linters.

En appliquant ces principes que vous avez déjà sur vos projets Web, ce sont toutes vos campagnes email qui en tireront les bénéfices.

Le gain sera perceptible aussi bien pour vos équipes qu’en terme d’expérience pour vos utilisateur·ices. La conversion c’est bien. Limiter les frustrations, l’insatisfaction et le désabonnement c’est encore mieux.

Design system email, si si c’est possible

Non, l’email n’est pas du jetable avec lequel on peut faire n’importe quoi. Il s’agit de l’image de votre organisation.

Nous allons tacher d’oublier les pratiques un peu désuètes. Les maquettes Photoshop monolithique et unitaire à la papa d’un côté et une charte graphique dans un PDF (Portable Document Format) oubliée au fin fond d’un dossier d’archive sur un serveur local, c’est fini !

Pour commencer, vous allez choisir un outil qui va vous permettre du prototypage fonctionnel un peu plus souple (par exemple Figma, pour n’en citer qu’un) et mettre en place une structure modulaire.

Oui, vous allez penser vos emails en composants tout comme vous le faites pour vos applications ou projet Web. Et vous savez quoi ? Les grands principes d’Atomic design posés par Brad Frost en 2013 sont également applicables à l’email. Alors aucune excuse pour ne pas faire les choses correctement, en partant des plus petits éléments de vos designs. Les plus petits détails font toute la différence.

Documentez et détaillez avec des exemples de code, des recommandations de bonnes pratiques, des usages à exclure.

Bref, établissez LE référentiel de travail central pour vos équipes de production technique, comme marketing. Une connaissance transversale et partagée pour concevoir vos campagnes en cohérence et préserver votre identité.

Exemple du design system email de Badsender dans Figma

« Une refonte passe avant tout par le design »

Erreur ! Grossière erreur.

Ce n’est que la partie visible de l’iceberg. C’est celle qui flattera directement l’égo de vos décideurs et mettra des paillettes dans vos yeux, mais certainement pas la plus stratégique pour votre audience ou vos équipes de production.

Prenez du recul et mettez à plat l’ensemble de vos typologies de campagne (transactionnel, trigger, newsletter, promotionnel…).

Prenez en compte votre connaissance client. Rentrez plus précisément dans votre cible pour définir vos personas. Cela vous permettra également de vous poser des questions sur les environnements d’ouverture et les contextes d’usage pour faire les bons choix (coucou Customer Journey Map).

Ecoute voir !

Comment concevoir des messages sans se pencher sur la rédaction ?

Car oui, nous avons parlé de serveur, de données, d’intégration HTML/CSS, de design… mais si vous envoyez des emails, c’est avant tout que vous avez des choses à dire à vos client·e·s, abonné·e·s, lecteur·rice·s…

Travaillez votre charte éditoriale. Sur le fond comme sur la forme.

Les sujets ce sont les vôtres, vous les connaissez et les maîtrisez mieux que quiconque. Vous pouvez faire des choix forts pour leur donner un axe, un angle singulier et différenciant. Tout comme vous pouvez y mettre un ton. Le ton qui portera votre discours de marque.

Ce travail sur vos contenus est le cœur de la meule, c’est ce qui va donner toute sa saveur à vos emails. Alors n’oubliez surtout pas un cadre des écrits ou une charte éditoriale dans votre design system.

Le bon, la brute et le truand

L’email, souvent relégué au second plan des projets numériques, mérite une place de choix. Annoncé mort à peu près chaque année, il reste et restera indispensable pour une raison simple : avec le web, il est l’un des seuls médias d’Internet à n’être la propriété d’aucune entreprise.

Face aux myriades de technologies propriétaires et de plateformes détenues par les GAFAM (Google, Amazon, Facebook, Apple et Microsoft), cela lui donne un avantage concurrentiel énorme. Aucune dépendance à un acteur monopolistique, les fournisseurs sont interchangeables, l’email est interopérable, les prix des plateformes sont relativement bas, et la technologie est stable et éprouvée.

Alors oui, si la techno est stable et éprouvée, elle peut avoir l’air « old school » (spoiler alert : elle l’est). La communauté des #emailgeeks vit un peu en vase clos (nous vous recommandons d’aller faire un tour sur la communauté Slack #emailgeecks pour vous faire un idée de ce monde merveilleux) et s’extasie parfois sur des sujets que le ou la développeur·euse web lambda jugera totalement incongru.

Mais il est aussi temps de redéfinir notre perception de l’email, non plus comme un outil désuet, mais comme un élément crucial de notre arsenal de communication. Si les fondations techniques de l’email sont anciennes et bougent lentement, cela n’empêche pas d’adopter des pratiques de conception et de développement modernes.

Cette réévaluation de l’email n’affecte pas seulement nos destinataires, mais elle est aussi essentielle pour dynamiser et valoriser nos équipes de production. En intégrant l’email de manière stratégique et innovante dans nos projets, nous ouvrons la voie à une plus grande créativité, une meilleure collaboration et une efficacité accrue au sein de nos équipes. C’est en encourageant ces changements que nous pouvons maximiser l’impact de nos campagnes et renforcer les liens avec notre audience.

Faisons donc de l’email un pilier de nos initiatives numériques, en reconnaissant son potentiel et en le mettant au service de nos objectifs stratégiques. Cela représente une opportunité unique de redéfinir et d’enrichir l’expérience utilisateur·ices, tant de nos équipes de production que de nos destinataires.

Dites-nous comment vous faites vos emails et quelle place vous leur accordez, nous vous dirons qui vous êtes !

2 commentaires sur cet article

  1. Nicolas Chevallier, le 14 décembre 2023 à 10:21

    Merci pour cet article. Je suis d'accord sur le fait que le mail est souvent oublié dans un projet web, qu'on ne passe pas suffisamment de temps dans l'optimisation, l'intégration et la délivérabilité.

    par contre je ne suis pas d'accord sur l'affirmation qu'il faille obligatoirement passer par un service externe d'envoi de mails pour plusieurs raisons:

    • la gestion d'un serveur SMTP sur une IP dédiée peut être compliquée mais est largement réalisable si le canal mail est important, voir vital pour le projet.
    • gérer la réputation d'une IP n'est pas compliquée une fois la mise en place terminée. On peut même discuter avec les équipes des principaux FAI français pour vérifier que tout est OK (et oui il y a des humains derrière !). La vérification des blacklists et inscription à quelques whitelists est réalisable la aussi.

    A contrario, croire qu'en payant un service on s'affranchit des problèmes est une erreur. Au moindre problème on est dépendant du prestataire, des autres boites qui envoient avec les IPs partagées. Et le tarif pour avoir une IP dédiée avec ces services devient vite prohibitif (sans compter l'envoi des mails !). Dernier conseil: tester vos envois avec le fabuleux outil Mail Tester ! https://www.mail-tester.com/

  2. Jonathan Loriaux & Olivier Fredon, le 14 décembre 2023 à 11:12

    Bonjour Nicolas,

    Je suis en effet tout à fait d'accord que l'on ne s'affranchit pas de problèmes en choisissant un service payant.

    Par contre, envoyer des emails, ce n'est pas juste configurer un MTA/Serveur SMTP et gérer la réputation des adresses IP. Les coûts de déploiement du tracking, de la mise en place des feedbackloops, la catégorisation des bounces, la gestion du désabonnement, le list-unsubscribe et de tout le reste est loin d'être négligeable.

    Mais évidemment, ça dépendra des volumes envoyés. La question ne se posera pas de la même manière avec quelques milliers d'emails par mois ou avec quelques millions.

    Mais gérer une infra d'envoi d'emails de masse en interne requiert une réelle expertise si on veut bien faire le taf. C'est aussi un monde qui change régulièrement et qu'il faut savoir mettre à jour et maintenir.

    Quant à Mail-Tester, c'est un chouette outil... mais c'est loin d'être la panacée ;-)

    A bientôt

Il n’est plus possible de laisser un commentaire sur les articles mais la discussion continue sur les réseaux sociaux :