À propos de newsletters et autres emails automatiques
Je vais essayer dans ce document de rapidement récapituler les informations qui sont utiles à tous les groupes.
Les services
Les newsletters (et les emails transactionnels comme le mail de "j'ai oublié mon mot de passe") sont envoyées via des services spécialisés, on ne peut pas faire ça via sa boite mail perso. Il est possible de monter son propre serveur mail (comme l'école l'a fait en installant une copie de Zimbra sur un ordi) mais vos emails finiront rapidement dans le dossier spam car il faut acquerir de la "réputation" pour que vos emails soient livrés comme il faut.
Si votre machine qui envoie les emails n'est pas connue de Gmail, Outlook, Yahoo, Laposte.net etc... alors ses quelques premiers emails peuvent lui donner une "mauvaise réputation" si ils ne sont pas ouvert, ou pire, manuellement mis dans le dossier spams. Bien evidemment, c'est beaucoup plus facile de se faire une mauvaise réputation plutôt qu'une bonne. Et donc en réalité, c'est ça la vraie offre de ces services, utiliser la réputation de leur adresse pour blaster votre montagne d'emails.
Donc dans l'essentiel, il faut passer par l'un des services suivants
D'autres refs au cas où
- sendgrid
- postmark
- mailgun
- mailerlite
et tout un tas d'autres trucs si vous cherchez "email marketing tools" dans un moteur de recherche.
Les stratégies d'écriture
Pour ce qui est de composer une newsletter, il y a essentiellement 3 techniques
- les editeurs drag-and-drop
- il existe des librairies qui vous donnent accès à des composants que vous pouvez assembler dans un editeur de code
- MJML (la librairie qui fait tourner l'editeur de mailjet 💪)
- Foundation for Emails
- ecrire le code directement (solution que je recommenderais a personne honnetement)
Les limitations techniques
- pas de javascript, autrement dit, votre email n'exécute aucune ligne de code, c'est uniquement un document
- pas d'éléments HTML modernes comme
<dialog>et pas d'éléments médias autre que les images (donc ni<video>, ni<audio>, ni<canvas>) - pas d'animations graphiques sauf les GIF (mais faites attention, c'est un vieux format mal optimisé donc ça rend l'email très lourd, très vite)
- les différents clients d'emails ont des restrictions de poids et n'accepterons pas des emails trop gros (25Mo sur Gmail et 20Mo sur Outlook par exemple)
- le meilleur moyen de faire de l'interaction, c'est de mettre un lien vers une URL speciale qui contient l'information
Et il y a des limitations dans la mise en forme de votre email en fonction de la stratégie d'écriture que vous avez sélectionnée juste au-dessus. C'est d'ailleurs pour ça que je vous encourage à jouer avec les éditeurs de mailchimp, mailjet ainsi que mosaico et de regarder les composants disponibles dans les librairies. Ça tiendrait qu'à moi, le rende serai sur l'un de ces outils plutôt que sur figma 😉
Une note sur l'a11y (accessibility)
On n'accède pas tous au web de la même manière.
Certaines formes de média ne sont pas accessibles pour tout le monde, et typiquement, les images sont un média qui requiert d'avoir des yeux fonctionnels.
Sur le web, il existe tout un domaine de connaissance lié aux techniques pour palier à ces problèmes d'accessibilité. Si vous voulez plonger dans ce domaine je vous recommande de commencer par la WAI, mais un autre jour parce que ce n'est pas rien comme lecture 😅.
Quoi qu'il en soit, on a deux solutions pour nos images.
On peut rajouter des informations dans une image pour qu'elle soit prise en compte par les screenreaders
Parmis les images suivantes, laquelle est accessible selon vous?
Indice: vous pouvez essayer d'appuyer sur F12 ou de faire un clic droit > inpsecter sur les éléments de la page pour ouvrir la console. (pas besoin de comprendre tout ce qui est dans la console pour avoir la réponse)
Réponse
Celle du milieu. Et si je vous montre leur HTML ce sera probablement plus clair pourquoi
<img src="kitty.jpg" />
<img src="mariette.jpg" alt="un chat" title="un chat" />
<img src="tube.jpg" />
La propriété alt est ce qui sera lu à voix haute par le screenreader, autrement dit, c'est là qu'il faut se débrouiller pour communiquer, via du texte, la même information que votre image.
L'autre façon de ne pas priver nos lecteurs non-voyant d'informations est de réaliser que la bonne pratique consiste toujours à envoyer notre email sous forme d'HTML+CSS (le code qui décrit à votre lecteur d'emails comment afficher le document) accompagné d'une version "plaintext" autrement dit "texte basique".
La version plaintext est la version la plus "tout terrain" de votre email, c'est garanti d'être ouvrable par toutes les boites mail (le saviez-vous? Certaines personnes configurent leurs boites pour n'accepter que la version plaintext). Mais la version plaintext ne permet aucune customisation de la font, ni image, ni mise en page, ni rien, seulement du texte brut.
Vous pouvez essayer d'envoyer un email sous ce format-là en passant par zimbra comme ceci.
Ah et aussi, les emails c'est pas ouf d'un point de vue écologique aussi, parce que c'est un vieux standard qui était prévu pour l'internet des années 2000.
Quand vous envoyez 500 emails de 15Mo c'est 500 x 15 = 7,5Go. Et c'est envoyé, que ça soit lu ou pas et derrière on sait que ça a pas mal de chance de traîner ad vitam aeternam au fond de la boite mail. Vu que c'est une multiplication, chaque octet retiré de l'email c'est autant d'octets que d'abonnés qu'on enverra pas.
Après, c'est intéressant de contempler la question. Mais bon, on va pas culpabiliser parcequ'en vrai c'est de la poussière comparé au streaming, les blockchains, et les intelligences artificielles.