Email builder : les dix questions à se poser avant de choisir

Le choix d’un email builder se fait trop souvent par défaut : parce qu’il est imposé par une direction, parce qu’il est déjà en place, ou parce que la décision revient à des personnes qui ne sont pas celles qui vont l’utiliser on a daily basis.

Résultat : de la frustration chez les équipes opérationnelles, des emails incohérents d’une campagne à l’autre, et une production qui se dégrade.

Deux familles d’outils reviennent tout au long de l’article :

• les email builders « standalone » (LePatron, Stripo, Dartagnan…), qui ne font que ça
• les email builders « intégrés » aux outils de routage (Actito, Selligent, SFMC, Adobe Campaign, HubSpot…), qu’on retrouve sous forme de module drag and drop dans l’ESP (Email Service Provider, la solution qui route vos campagnes).

Voici les dix questions que nous posons systématiquement à nos clients avant qu’ils choisissent leur méthode de production email et que nous avons abordé en Live : voir le replay.

1. Valider la faisabilité du design

Avant tout, il faut savoir où en est la maturité du design et quel niveau de finesse nous voulons produire avec un builder. Un design peut paraître simple sur une maquette et devenir un vrai casse-tête à reproduire en drag and drop.

Nous l’avons vu chez Younited Credit : un bloc de type « cover » combine image de fond, pictogramme éditable, titre en deux couleurs, paragraphe et bouton, le tout dans un cadre qui déborde avec une ombre portée. Un exercice difficile pour beaucoup d’email builders.

At Challenges, l’identité visuelle repose sur des éléments très fins : marges externes, bordures, filets qui partent du milieu d’un titre, polices personnalisées, soulignements spécifiques. Une fois perdus dans un builder plus limité, ces éléments font disparaître toute reconnaissance de marque.

Le constat est direct : un design fin est en général plus facilement reproductible dans un builder standalone que dans un builder intégré à un routeur. Chez Challenges, plusieurs builders ont été testés en amont via des POC (Proof of Concept) avant de trancher, et ce n’est finalement pas le builder intégré au routeur du client qui a été retenu, faute de pouvoir garantir la fidélité du design.

2. Qui va utiliser l’outil au quotidien

Un email builder s’adresse à des profils très différents : équipes marketing et CRM d’un côté, designers et intégrateurs de l’autre. Ils n’ont ni la même aisance avec l’outil, ni les mêmes objectifs.

Un designer se soucie du calcul des marges, des gouttières, de la divisibilité des colonnes. Une équipe marketing veut surtout définir ce dont elle a besoin par typologie de campagne : un titre, un sous-titre, un CTA pour un email promotionnel, une catégorie, un titre, un CTA pour une newsletter. La promesse du drag and drop, c’est de mettre la technique de côté. Sauf que dès qu’un contenu est retiré ou ajouté dans un bloc à plusieurs éléments, il faut souvent revérifier toutes les valeurs de marge en desktop et en mobile.

Un setup qui fonctionnait bien peut se retrouver cassé après une simple modification de contenu, sans que l’utilisateur comprenne pourquoi.

3. Choisir entre liberté créative et sécurité de marque

C’est le point de friction principal dans le choix d’un builder.

D’un côté, un modèle ouvert (type Stripo ou BeeFree) : la même matière première pour tous les annonceurs, une grande liberté de composition, mais aussi le risque de sortir de sa charte graphique.

De l’autre, un modèle davantage verrouillé, pensé « design system », où les options disponibles dans l’interface s’adaptent aux besoins exprimés par l’annonceur, jusqu’à empêcher techniquement l’utilisation d’une couleur ou d’une police hors charte.

Le choix dépend de la maturité de la marque et du turnover des équipes. Une identité qui évolue vite (l’événementiel, par exemple) se prête bien à un outil ouvert. Une organisation de grande taille avec du turnover, où la subjectivité de chacun finit par éroder la cohérence de marque, a davantage intérêt à un cadre plus strict.

4. Évaluer la complexité de votre structure

Multi-marques, multi-langues, multi-marchés, multi-routeurs : plus l’organisation est ramifiée, plus certains builders sont mis en difficulté.

Un schéma courant chez les grands groupes ou ETI (entreprises de taille intermédiaire) que nous accompagnons : une direction globale pilote plusieurs marchés (France, Belgique, Canada, Suisse), chaque marché gérant ses propres marques et déclinaisons de langue.

Le multi-routeur mérite une attention particulière : quand les emails ne partent pas systématiquement du même ESP, un builder indépendant garantit la cohérence du template à l’export, quel que soit l’outil de routage utilisé derrière.

5. Cadrer la production, au-delà de l’outil

L’outil et ses fonctionnalités ne suffisent jamais à eux seuls.

Dans les grandes organisations, la perte d’information circule vite : si un builder est trop verrouillé pour des besoins ponctuels (un Black Friday, par exemple), les équipes contournent (export, bricolage du code HTML), souvent sans que la direction s’en rende compte.

Notre recommandation : mettre en place une équipe transverse (design, intégration, rédaction, data, CRM) et documenter deux choses en parallèle de l’outil, un cadre éditorial (comment s’écrit un email commercial, une newsletter, un transactionnel) et un document de design system (quel bloc utiliser, pour quelle typologie de campagne).

Autre bonne pratique : organiser des rétrospectives régulières, en reprenant un échantillon d’emails envoyés avec un référent design, rédaction et CRM, pour identifier ce qui fonctionne et ce qui doit être corrigé. La fréquence dépend de la taille de l’équipe et du volume produit, mais le principe doit exister, quel que soit le rythme choisi.

6. Maitriser la qualité dans le temps

Un design system n’est jamais figé. Les règles évoluent : Outlook fait évoluer ses moteurs de rendu, les fournisseurs de services de messagerie (La Poste, Orange, Gmail…) changent leur interprétation du HTML et du CSS, un changement d’ESP peut tout remettre en question. Ce qui a été validé à un instant T, y compris passé dans des outils de test comme Email on Acid, peut se dégrader avec le temps si personne ne le surveille.

La question à se poser en amont : le code produit par le builder est-il évolutif ? Peut-on corriger finement un élément sans tout reconstruire ? Tous les outils n’offrent pas la même souplesse sur ce point.

7. Faire évoluer vos templates

Un design system est vivant, pas monolithique. Les évolutions peuvent rester mineures (un logo, une typo, une couleur qui change, comme chez Clarins) ou aller plus loin, avec l’ajout de blocs entièrement nouveaux liés à de nouveaux besoins métier.

Chez Younited, par exemple, des blocs orientés simulateur de crédit ou échéancier de paiement sont nés d’objectifs CRM précis.

C’est le rôle de l’équipe transverse évoquée plus haut : faire remonter les besoins, designer le bloc correspondant, l’intégrer au builder, plutôt que de laisser une équipe métier bricoler un bloc qu’elle n’a pas les compétences pour produire correctement.

8. Accéder et exploiter les données

Presque toutes les demandes de builder incluent, tôt ou tard, un besoin de personnalisation. La vraie question n’est pas « peut-on faire de la perso ? », la réponse est presque toujours oui avec un builder indépendant, mais « quel niveau de personnalisation avons-nous réellement besoin d’exploiter ? ".

Dans la pratique, beaucoup d’annonceurs se limitent à la civilité, au prénom et au nom. D’autres vont plus loin : La Poste, par exemple, exploite du contenu conditionnel avec de la géolocalisation du point physique le plus proche du destinataire.

Le secteur presse et médias (remontée de flux éditoriaux) et le e-commerce (recommandation produit) sont ceux qui exploitent le plus ce type de fonctionnalité.

Un point à connaître : avec un builder intégré directement à la source de données (CRM, ESP), nous pouvons prévisualiser le rendu avec de la donnée réellement interprétée, un avantage qu’un builder tiers, non connecté à cette donnée, n’offre pas.

9. Questionner la dépendance

Derrière une demande de changement d’email builder se cache souvent une réflexion plus large sur l’écosystème technique, un projet de migration d’ESP par exemple.

Si tous les templates ont été construits avec le module drag and drop propre à un ESP donné, migrer vers un autre outil de routage veut dire reconstruire tout ce travail dans un nouvel outil intégré. Le HTML exporté ne suffit pas à retrouver l’éditabilité d’origine.

Ce sujet de la dépendance est d’autant plus sensible aujourd’hui avec les récentes recommandations de la CNIL (Commission nationale de l’informatique et des libertés) sur le pixel d’ouverture, qui compliquent la donne pour les organisations dépendantes d’outils américains. Un builder indépendant du routeur limite ce risque : le travail de templating reste garanti, quel que soit l’ESP utilisé pour l’envoi.

10. Estimer le coût complet

Le prix affiché d’une licence, parfois quelques dizaines d’euros par mois et par utilisateur, ne reflète jamais le coût réel de production.

Derrière, il y a l’atelier de cadrage, le cahier des charges, la rédaction des documents de cadre éditorial et de design system, le paramétrage du setup, la production des layouts desktop et mobile, puis l’hébergement, le support et la formation des équipes.

Une bonne partie de cet investissement se concentre sur la première année et s’amortit sur les deux à trois années suivantes. D’où l’intérêt de se projeter au-delà du prix de la licence avant de s’engager : mieux vaut que ce travail de production serve plus de six mois.

In summary

Le prix reste, dans la pratique, le critère qui revient le plus vite dans une décision d’email builder, et la mutualisation des coûts via l’ESP en place est une tentation naturelle. Mais cette économie peut se révéler fausse si l’outil ne tient pas la route sur le design, la gouvernance ou la dépendance à long terme. Faire remonter ces dix questions jusqu’à la direction de marque, avant de trancher, reste le meilleur moyen d’éviter les regrets six mois plus tard.