Parmi les Email Builders que j’ai pu analyser, celui de Salesforce Marketing Cloud se distingue par une interface sobre et fonctionnelle. Pas de fioriture, on est là pour travailler. L’approche est claire : templates, structures, blocs de contenu. Mais est-il pertinent ? Voyons ce que ça donne en pratique.
Comment fonctionne le builder ?
Le builder de SFMC repose sur un modèle de templates dans lequel on vient injecter des structures (colonnes et compositions pré-fabriquées) ainsi que des blocs de contenu : texte, image, HTML, blocs avancés (contenu dynamique, A/B testing, etc.), et des blocs sur mesure.
Ces blocs sur mesure méritent qu’on s’y attarde. Si on les construit avec les éléments natifs du builder, ils restent éditables. Mais si on passe par du HTML personnalisé, ces blocs ne sont plus éditables ; et ce, même en copiant-collant le code d’un bloc natif dans un bloc « libre ». Cela veut donc dire que, quel que soit le code HTML injecté, un bloc de type HTML ne sera jamais éditable en WYSIWYG.
Les structures (Layouts)
Le système de colonnage est solide. On peut gérer une à cinq colonnes, jouer sur les largeurs en pourcentage, et — point appréciable — contrôler l’ordre d’affichage sur mobile (empilage ou non, sens de lecture). Des compositions pré-fabriquées sont également disponibles pour aller plus vite. C’est propre et modulaire.
Les blocs de contenu (Blocks)
Basic Content
Les blocs de base couvrent l’essentiel : texte, image, bouton, HTML, Free Form, Code Snippet. Le bloc bouton offre une gestion des coins arrondis, des marges internes et des bordures — c’est fonctionnel. Par contre, il n’est pas possible de mettre le texte du bouton en gras. Limitation difficile à comprendre.
Le bloc HTML permet d’injecter du code sur mesure, ce qui offre de la flexibilité. Mais comme mentionné plus haut, on perd le côté éditable.
Advanced Content
Le bloc Reference Content (contenu synchronisé) est utile pour les éléments récurrents comme les headers ou footers : on appelle un bloc qui a été enregistré au préalable. Dommage qu’il soit verrouillé et qu’il ne soit pas possible de détacher l’instance pour en modifier le contenu ponctuellement.
Le bloc Dynamic Content permet d’afficher du contenu selon des règles et conditions, ce qui est la moindre des choses pour le builder d’une plateforme aussi importante. L’A/B Test est également disponible sous forme de bloc, permettant de tester des variations de contenus.
Interactive Content
Deux blocs : Email Form (AMP4email) et Image Carousel. L’AMP4email est très peu supporté par les clients email actuels (Outlook.com a même fait marche arrière). En pratique, ces blocs ont une valeur limitée pour la majorité des cas d’usage. C’est anecdotique et un peu dommage qu’il y ait de l’énergie et du temps dans ces modules et pas ailleurs. Pour ceux que cela intéresse, Olivier a déjà publié un article au sujet de ce genre de “prouesses techniques”.
Le Design
L’onglet Design est le point de départ logique de toute création : choix du template, couleurs de fond, styles par défaut (textes, titres, liens, boutons) et comportement mobile via media queries. Je recommande de le configurer en début de projet, au risque de voir ses styles écrasés si on y revient après coup.
Sur les titres, on peut utiliser <h1>, <h2> et <h3>, mais il n’y a pas de gestion des balises <p>. Tout passe directement dans des <td>. C’est un manque du point de vue de l’accessibilité et de la sémantique.
Les points forts
- Réactivité de l’outil : pas de latence, l’interface répond bien.
- Vue arborescente (Tree View) : Elle liste toutes les structures et blocs de manière synthétique, permet de réordonner, dupliquer ou supprimer facilement. Un vrai gain de temps.
- « Restore to Global Styles » : pratique pour revenir aux styles par défaut après des modifications qui partent dans tous les sens.
- Gestion dissociée des marges : on peut définir des valeurs différentes pour chaque côté d’un bloc ou d’un layout. Ça semble basique, mais tous les builders ne le font pas.
- Accès au code source complet via Code View : utile pour évaluer la qualité du code sans avoir à envoyer un BAT.
- Éditeur HTML sur les blocs Basic Content : on peut aller modifier directement le code généré pour les boutons, textes, images. C’est une arme à double tranchant — grande flexibilité, mais aussi grande liberté de tout casser. Il est à noter aussi que tout n’est pas éditable. Dans certains cas le builder accepte les modifications, dans d’autres non. Mais les critères selon lesquels une modification est possible ou pas ne sont pas clairs.
Les limites
Typographie et custom fonts
Le builder est limité aux web safe fonts (Arial, Tahoma, Trebuchet, etc.). L’injection de custom fonts est techniquement possible via le template, mais leur utilisation passe par du CSS non inliné :
<style type="text/css">
@font-face {
font-family: 'MyCustomFont';
src: url('<https://www.yourdomain.com/fonts/myfont.woff2>') format('woff2');
}
body, table, td { font-family: 'MyCustomFont', Arial, sans-serif !important; }
</style>
Conséquence directe : certains clients email n’en tiendront pas compte. C’est une option qui existe, mais qui demande de bien informer les utilisateurs sur ses limites de support.
Images de fond et coins arrondis
Pas de gestion des images de fond via les blocs natifs. La seule option est de passer par du HTML injecté directement. Il serait techniquement possible de créer des blocs éditables avec des images de fond ou des coins arrondis, mais uniquement via des workarounds : les options visuelles (arrondis, images de fond) seraient dans le code et donc non éditables via l’interface, et les options natives comme les marges ou la couleur de fond pourraient interférer avec ce code custom.
En pratique, dans un environnement multi-utilisateurs, ce genre de solution n’est pas réaliste. Il faudrait éduquer chaque utilisateur sur les options à ne pas toucher sous peine de casser le rendu. Ce n’est pas viable à grande échelle.
Gestion mobile
Il n’y a pas de gestion spécifique pour le mobile au niveau des blocs. Il est possible d’injecter des CSS personnalisées au niveau du template, mais la modification du code HTML dans les composants pré-fabriqués ne fonctionne que partiellement. Dans un bouton par exemple, on peut modifier ce qui se trouve à l’intérieur de la balise <td>, mais pas la <td> elle-même ni ce qui est au-dessus dans l’arborescence.
Et s’il est possible de masquer un bloc sur mobile, il n’est pas possible de masquer un bloc sur desktop. Vous pouvez donc imaginer du contenu spécifique desktop, mais pas spécifique mobile. Ce qui, à l’heure actuelle, est un gros point faible.
Accessibilité et qualité du code
Pas d’attribut lang sur le <html>, pas de correctifs pour le 120DPI, des largeurs gérées via l’attribut width plutôt que via CSS. Les balises sémantiques <h1>, <h2>, <h3> sont disponibles dans le bloc Text, mais pas de <p> — tout passe dans des <td>. Et pour ne rien arranger, des attributs title sont automatiquement ajoutés sur les liens, ce qui est contre-productif en termes d’accessibilité, et non modifiable. Bref, rien ne va. On voit clairement que l’accessibilité au niveau technique n’est pas du tout prise en compte avec ce builder.
Conclusion
Le builder de SFMC est fonctionnel et fait un travail correct pour des besoins standards. Si l’email à produire est simple — structure classique, contenu texte/image, boutons basiques — le builder s’en sort bien.
Mais dès qu’on s’attaque à des besoins un peu plus spécifiques — design système avancé, images de fond, gestion fine de la typographie, accessibilité soignée — et surtout dès qu’on implique des utilisateurs non-techniques, le builder montre ses limites. Les workarounds existent, mais ils nécessitent une rigueur et une formation des utilisateurs qui ne sont pas compatibles avec un environnement avec de nombreux contributeurs. Particulièrement si ces derniers n’ont pas un minimum de bagage technique en HTML.
C’est particulièrement dommage pour SFMC, qui est une plateforme destinée aux très grands comptes, avec des équipes souvent larges et des exigences élevées en termes de design système. Dans ce contexte, le builder n’est clairement pas à la hauteur. Dans un autre contexte : une plateforme destinée à des clients plus modestes, avec des besoins plus simples, il pourrait tout à fait être à sa place.
Nous sommes bien entendu disponibles pour vous accompagner dans l’évaluation ou la mise en place de votre builder email. N’hésitez pas à nous contacter.
Laisser un commentaire