• 
• Par Stephane LEE
• le 15 May 2006

Faire une newsletter en HTML

Nous avons récemment fait partir deux lettres d’informations HTML, et je veux partager avec vous les quelques enseignements que nous en avons tirer.

Si vous avez besoin d’envoyer des informations à vos abonnés, posez-vous d’abord la question : Pourquoi une newsletter ?

Aujourd'hui, les possibilités d'informer votre audience sont multiples : blog, flux RSS, e-mailing. Laquelle choisir ? On pourra se référer à une note que j'ai écrit il y a quelques temps pour avoir des éléments de réponse. Dans le cas qui nous intéresse, le notre , nous avons un blog qui dispose de fils RSS pour ceux qui veulent s'abonner à nos articles. C'est bien mais...un blog est publique par nature, et nous voulions réserver l'accès à certaines informations (comme les codes d'accès à notre version beta) aux personnes qui nous avions invitées et à celles qui voulaient se porter volontaires. Dans ce cas, seule une newsletter, c'est à dire un envoi ciblé d'information à des personnes souhaitant les recevoir, pouvait correspondre à ce cahier des charges. Une fois le choix de réaliser une newsletter fait, reste la question du comment. La première question que nous nous sommes posés concernait la forme de ce que nous allions envoyer : du texte brut, un formatage HTML, une pièce jointe en PDF ? Nous avons finalement opté pour une newsletter HTML, parce que nous voulions introduire certains éléments graphiques dans la lettre, comme notre logo ou des blocs d'information pour préparer nos abonnés à ce qu'ils pourraient retrouver sur notre pré-site ou notre application. Comme nous souhaitions également pointer certaines pages Web dans le contenu, il nous est apparu plus naturel de le faire directement dans le mail, formatté en HTML. Si ce choix semble logique, il n'est pas des plus fluides dans sa réalisation...qui fut beaucoup plus complexe que prévu ! Car faire une newsletter en HTML, c'est se confronter aux habituelles incompatibilités bien connues des professionnels du Web. Tout le monde sait (ou pas encore) que si le format HTML est standard, les différentes implémentations de ce standard sont loin d'être identiques, et que chaque navigateur a ses spécificités (Internet Explorer notamment). Faire en sorte qu'une application Web fonctionne correctment sur l'ensemble des navigateurs est uen gageure et coûte très cher...Et bien il en est de même pour les Newsletter HTML :-( Qu'elle ne fût pas ma surprise de voir que notre Newsletter réalisée (en HTML) apparaissait totalement différemment quand on passait d'un client mail à un autre !!! Une petite explication : les clients mail utilisent généralement des "moteurs HTML" issus des grands navigateurs (Gecko pour Firefox, Webkit pour Safari, etc.). On pourrait donc se dire que si votre page HTML incluse dans la newsletter apparait correctement sur IE, Firefox et Safari, elle devrait être présentable sur la plupart des clients e-mail (Outlook, Thunderbird, etc.) utilisant ces moteurs. C'est en partie vrai mais...certains clients mails actuels utilisent des moteurs d'ancienne génération pas compatibles avec certains styles "CSS" par exemple. D'autre part, de plus en plus d'internautes utilisent des clients Web pour accéder à leur boite aux lettres (cf Gmail, Hotmail, Yahoo, etc.). On pourrait se dire que si l'abonné utilise un navigateur pour regarder ses mails, et que la page HTML incluse dans la newsletter apparait bien dans ce navigateur, tout se présente bien...c'est sans compter avec le zèle de certains fournisseurs de boite mail, qui suppriment certains formattages HTML, remplacent certains styles par les leurs ou refusent catégoriquement d'afficher des pages HTML !!! Après de multiples essais, on commence à s'arracher les cheveux - même si on n'en a pas - et on se dit qu'on avait pas prévu des passer des heures la-dessus. Il est temps d'adopter une procédure de repli ! Heureusement, il existe une parade. Elle consiste à d'utiliser ce que les spécialistes appellent un mail "multipart", c'est à dire un mail comprenant deux parties : une partie en format texte brut, l'autre avec la page HTML. En fonction de ce qu'accepte le client mail du destinataire, le mail s'affichera d'une façon ou d'une autre, avec au minimum le texte brut si le HTML n'est pas accepté. Il est donc important de vérifier que votre gestionnaire d'envoi de newsletter gère ce double envoi. Dans le texte brut, on pourra mettre un lien vers la page HTML, si tant est que vous l'aviez hébergée sur un serveur Web. On pourra alternativement insérer une image de votre page HTML. Pour cela, il faut transformer votre page HTML en image Gif, Png ou Jpg. Si votre page HTML a une taille dépassant celles d'un écran standard, des outils comme Paparazzi sur Mac peuvent aider à constituer l'image à partir d'une simple capture d'écran...Dans ce cas bien sur, il sera impossible de proposer de cliquer sur différents liens HTML, puisqu'il ne sera plus "cliquables" sur l'image envoyée. A propos des liens dans une newsletter, sachez que nous avons tous tendance à agir mécaniquement en lisant un mail, et cliquer sur le premier lien venu, sans même prendre la peine de lire la totalité du message. J'ai fait l'erreur de mettre des liens importants vers la fin du contenu, ce qui fait qu'un grand nombre de gens ne l'ont jamais vu :-( Donc, ne faites pas la même chose, et penser à hierarchiser vos liens : sur lequel voulez-vous que les abonnés cliquent en priorité ? Bon, maintenant que vous avez votre page HTML, et choisit votre mode dégradé, il vous faut l'envoyer à tout le monde ! Quel outil de "newsletter management" choisir ? J'ai fait un tour rapide de quelques solutions du marché (Cabestan, Cheetah, Campaigner, Emailvision, Dolist), et me suis vite rendu compte que le coût pour une start-up était rédhibitoire. J'ai alors regardé et testé des solutions Open Source comme Wanewsletter. Au final, j'ai choisit d'utiliser une solution commerciale mais gratuite (jusqu'à nouvel ordre), proposée par les australiens de Zookoda. Pourquoi Zookoda ? Pour plusieurs raisons :

• Parce que c'est une start-up, et qu'entre start-ups, on se comprend
• Parce que leur produit permet à la fois de produire des Newsletter au contenu manuel ou au contenu automatisé (à partir de fils RSS de blogs)
• Parce les fonctionnalités sont relativement nombreuses et le tracking performant
• Parce que l'interface est sympathique et assez simple

Au final, qu'est ce que je retiens de cet épisode de l'aventure Feedback 2.0 ?

1. Penser que la création d'une newsletter HTML prendra du temps : est-ce que le jeu en vaut la chandelle ?
2. Ne pas oublier les procédures de contournement pour qu'un maximum d'abonnés puissent voir votre page HTML
3. Mettre les liens les plus importants en tête du message
4. Ne pas oublier d'inclure un lien de désabonnement (c'est légalement obligatoire)

Voilà, j'espère que cette expérience pourra vous être utile, et j'attends vos conseils et retours...

1. Le 06/26 à 18:35 par Xavier

J’acquièsce pour avoir testé Zookoda L’essayer c’est l’adopter…

2. Le 12/08 à 13:26 par

Merci 1000 fois pour ce partage d’expérience ! Je me pose exactement la (les) même question dans un contexte professionnel. D’ailleurs votre solution Feedback20 pourrait nous intéresser.  A suivre.

3. Le 12/31 à 0:21 par Al West

Bonsoir,
Je suis ok pour Zookoda, le design me plaît mais je n’arrive pas à créer un broadcast ou un de leur webmaster doit vérifier que je ne suis pas en train de spammer. C’est dommage, j’ai envoyer plusieurs mails pour savoir comment faire et cela fait 3 semaines que rien n’avancent.
Quelqu’un sait il comment faire ?
peut être recréer un compte…
-----