[New] Proposer RSS comme alternative à la Newsletter

[Fred-artwai]

Comme on le sait tous, les mails çà polluent.
Du coup, il serait intéressant dans notre référentiel de proposer cette alternative au mailing de masse : le RSS.

Certes pas très démocratisé, mais qui est pourtant diablement efficace : avec les flux RSS, aucun risque de vous retrouver piéger dans le dossier spam et il n’y a pas de limite de taille de fichier. Ils sont 100 % livrables et vous pouvez y inclure d’autres formats comme des podcasts ou des vidéos.

Il faudra bien sur mettre des références d'agrégateur de flux RSS.

Donc mettre en avant le RSS, c'est proposer aux utilisateurs une démarche éco-constructive comme alternative à un usage polluant.
On pourrais en guise de mesure moins radicale, demander au concepteur de site web de proposer le flux RSS avant l'inscription à la newsletter.

Qu'en pensez vous ?

[tbroyer]

Est-ce qu'il est vraiment mieux d'utiliser un "protocole" (HTTP+RSS/Atom) en pull qu'un protocole (SMTP) en push ?

Les problèmes de "trop de mail", finalement, c'est principalement dû:

• aux envois sans consentement
• à la non-désinscription des mailings qu'on ne veut plus (rece)voir (combien vont faire un filtre pour mettre à la poubelle plutôt que se désinscrire ? combien vont simplement ignorer ces mails ? j'en connais malheureusement trop)

Un flux RSS n'adressera pas le premier point, et à mon avis pas le second non plus.

Il n'y a pas à ma connaissance de standard pour qu'un flux RSS/Atom indique à l'agrégateur la fréquence de mise à jour (et donc la fréquence de polling à adopter), la RFC 3229 n'a jamais été utilisée pour les flux RSS/Atom à part pour des expérimentations, et pubsubhhubbub semble tombé en désuétude (j'espère me tromper, ça fait longtemps que je n'ai pas travaillé dans le domaine).

[Fred-artwai]

J'utilise Feedly depuis 15 ans, de ce que je vois, la mise à jour des RSS se fait quand je l'ouvre et pas avant et sans notification automatique.

Par contre, j'ai toujours des clients qui veulent faire des mailings avec une mise en avant du formulaire d'inscription malgré mes recommandations. Le nombre de mail qui partent en SPAM ou qui sont stockés ou pire d'adresse mail abandonnée à qui la newsletter est quand même envoyée avec un serveur qui répond que l'adresse n'existe plus...

Je reste convaincu que le RSS c'est nettement plus light.

[tbroyer]

J'utilise Feedly depuis 15 ans, de ce que je vois, la mise à jour des RSS se fait quand je l'ouvre et pas avant et sans notification automatique.

La récupération des infos depuis l'appli mobile (ou web) peut-être, mais ces infos sont récupérées auprès de la Feedly Cloud Platform qui, elle, va vérifier régulièrement les mises à jour des flux: https://feedly.helpscoutdocs.com/article/212-how-often-does-feedly-update
L'avantage de Feedly ici est de mutualiser le polling pour tous ses utilisateurs (une requête à un flux RSS tous les X jours, ou X heures, ou X minutes, quelque soit le nombre d'utilisateurs Feedly intéressés par le flux) vs. avoir chacun d'entre eux mettre à jour sa copie locale du flux RSS.
(D'ailleurs quelqu'un sait comment la nouvelle fonction "follow"/web feed de Chrome fonctionne ? https://www.blogdumoderateur.com/google-chrome-comment-utiliser-lecteur-flux-rss/ Les serveurs de Google jouent le même rôle que Feedly ou bien chaque device fait des requêtes aux serveurs d'origine des flux ?)

[rlemaire]

C'est intéressant pour un particulier (ou un professionnel qui fait de la veille) de passer des mails aux flux RSS, mais je ne sais pas si ça l'est pour les professionnels : ils veulent toucher leurs clients, qui lisent des mails et pas des flux.
J’utilise presque quotidiennement feedly et je ne comprends pas que cette technologie ne soit pas plus utilisée, mais ce n'est pas un remplacement facile pour les entreprises dans leurs projets.

[arnolem]

C'est un sujet que je comptais également proposer.
Pour moi, il y a plusieurs avantages :

• La récupération des informations se fait lorsqu'on lance son client (et donc rien si on ne le lance pas). Ou alors, elle est mutualisée par tous les usagés d'un service comme Feedly
• Les agrégateurs mettent en cache le contenu, donc un RSS lu sur un serveur Feedly aura plutôt l'impact d'un site statique plutôt que d'un WordPress
• Contrairement aux emails, on ne récupère que la liste des actualités et le contenu est récupéré à la volé en cas de consultation de l'article. Pour un mail, tout le contenu arrive sur le serveur même si le client ne le lit jamais
• Enfin, la page en question est renvoyé sans CSS, ni JS, ni Images décoratives, ... Alors que si l'on va sur le site après avoir reçu un email, on chargera tout le site.

[ACTLEM]

J'avoue être embêté (comme @rlemaire et @tbroyer je suppose ^^) avec cette proposition. Nous sommes assez d'accord pour dire que le RSS n'est pas assez utilisé sur le terrain, et cela s'explique entre autres que le flux RSS n'apporte pas assez de conversion côté e-marketing car n'est au final par très utilisé par les clients eux-mêmes (contrairement au mail).
D'un point de vue écoconception, il n'y a pas aujourd'hui d'étude pour confirmer que le flux RSS est meilleur qu'une newsletter bien conçue. Je dirais oui mais sans preuve.
Je propose donc que cette proposition soit gardée en tête pour la prochaine mise à jour et que pour cette version pour l'instant nous la laissons de côté. @Fred-artwai @arnolem: n'hésitez pas à réagir.

[arnolem]

Pour ma part, je pense que le RSS peut être une bonne chose pour l'éco-conception mais je ne l'aurait pas forcément opposé à l'emailing.

Si on oublie l'emailing pour l'instant, êtes vous d'accord pour dire que si vous lisez un article en RSS (sauf extrait), vous n'allez pas forcément aller sur le site web ? Du coup, vous récupérez une version XML de la page (et quelques images de contenu) mais vous ne chargez jamais le CSS, JS et layout du site ? De plus, vous n’exécutez aucun JavaScript ?
En plus, si vous passez par un service tiers, il y a de très forte chance que le contenu soit mis en cache alors qu'il n'est pas rare que le site de destination soit totalement dynamique.

Sans parlé de l'emailing, êtes-vous sceptique sur ce point ? @tbroyer @ACTLEM

[ACTLEM]

Non, je ne suis pas sceptique sur ce point ;-)
Il faudrait voir comment amener le fait qu'utiliser le RSS permet de réduire des impacts. Par exemple, une BP qui dit "Mettre en place un flux RSS", risque d'ajouter des impacts si rien n'est remplacé diminué à côté. D'où peut-être ma proposition de le mettre dans la BP 109 comme alternative aux e-mails. C'est un moyen de pousser le sujet dans un premier temps.

[tbroyer]

Si le flux RSS contient l'ensemble du contenu, alors on va télécharger les 10 derniers articles (par exemple) même s'il n'y en a qu'un de nouveau et qu'on a déjà les 9 précédents (à moins que la RFC 3229 soit utilisée, mais je crois pas que ça ait jamais décollé), on a donc une perte sèche de bande passante.
Si le flux ne contient que les résumés/chapôs des articles, alors un article intéressant se traduira par une visite sur le site.
Si le flux ne contient que les titres, c'est encore pire (ça revient à l'histoire de la bonne metadescription pour les moteurs de recherche).

Du côté de la newsletter, si on a un mail par article, avec l'article complet (comme https://www.htmhell.dev/ par exemple, mais c'est un cas assez particulier) alors on a une perte si on ne lit pas l'article (comme pour tout mail, et comme pour le RSS).
Si on a un mail récapitulatif par jour/semaine, alors on se retrouve dans la situation du flux RSS incomplet, mais avec un coût une fois par jour/semaine plutôt que toutes les quelques heures de polling pour rafraîchissement du flux RSS.

L'idéal serait peut-être alors un flux RSS complet avec push (WebPush / pubsubhubbub), on évite alors le polling et les visites du site.

Bref, j'ai un peu peur que ce soit quand même un sujet de niche, et que le meilleur sujet soit encore de ne pas faire de newsletter 😄

Mais disons pourquoi pas si on borne assez précisément de quoi on parle. Mais peut-être aussi que c'est parce que je n'utilise jamais ces fonctionnalités de newsletter 🤷‍♂️

[Fred-artwai]

L'idée que j'avais de cette BP c'est de proposer un RSS avant une inscription à une Newsletter. Du genre "Connaissez-vous le RSS ? Avec cette technologie, vous pouvez suivre notre actualité sans polluer votre boite mail et la planète. En savoir plus..."

Je ne pense pas qu'on puisse remplacer la Newsletter du jour au lendemain. Mais si le RSS reste réservé aux seuls geeks que nous sommes, rien ne remplacera jamais la newsletter. L'objectif dans un premier temps est de faire connaitre cette pratique et de faire réfléchir sur l'usage des mails et mailings à outrance.

[ACTLEM]

Finalement, on pourrait en parler dans la BP 109 (cf Pull Request https://github.com/cnumr/best-practices/pull/278/files), non?

[ACTLEM]

Pas d'avis sur le fait d'en parler comme alternative dans la BP 109 (#278)?

[Fred-artwai]

Pour moi c'est différent.

[ACTLEM]

Ok. Donc pour l'instant, on est plus à laisser de côté.

[Julien-Elie]

Peut-être vaudrait-il mieux reformuler la suggestion en "Proposer un flux RSS pour suivre l'actualité du site" et ne plus parler de newsletter ? Je pense que la newsletter répond à un besoin différent.
Pour des sites proposant des fils d'actualité, des annonces, des blogs ou équivalents, un flux RSS est utile pour éviter aux utilisateurs de régulièrement consulter la page d'accueil du site, cause de transferts de données inutiles.

En renseignant notamment les éléments ttl et skipDays dans le flux RSS, l'agrégateur peut requêter au juste nécessaire.
La taille d'un flux RSS est bien moindre que celle d'une page web complète, donc cela épargne également les ressources.