Fin mars, je publiais une proposition visant à réduire l’impact environnemental du stockage presque indéfini de la plupart des emails.
La proposition : ajouter une date d’expiration à certains types d’emails (principalement commerciaux), afin que ceux-ci puissent être supprimés presque automatiquement.
Cette proposition a déclenché de nombreuses réactions, certaines très enthousiastes, d’autres moins, ce qui est intéressant aussi afin d’enrichir le débat.
Pour ceux qui veulent relire les échanges publics, les principaux ont eu lieu ici :
- LinkedIn : https://www.linkedin.com/pulse/zerocarbonemail-auto-magically-delete-expired-emails-from-loriaux/
- Slack emailgeeks : https://emailgeeks.slack.com/archives/C0K1GQ7PG/p1616679051162100
Toutes ces remarques permettent d’enrichir la réflexion sur le sujet, et je vais prendre le temps de détailler les principales tout en y répondant.
D’ailleurs, cela permet aussi de reformuler le principe de base afin de le rendre plus clair et plus proche de ce qu’il pourrait être dans la réalité :
« Fournir aux expéditeurs d’emails commerciaux le moyen de préciser une date d’expiration de leurs messages. Ceci afin de permettre aux webmails et aux FAIs de concevoir plus facilement des outils de suppression (semi)automatiques de ces emails. »
Dans cet article, nous recensons donc les remarques et questions les plus fréquemment rencontrées en y répondant. N’hésitez pas à continuer à enrichir la discussion ici ou ailleurs.
Il vaut mieux réduire l’empreinte carbone en réduisant le nombre d’emails envoyés
Sans doute la remarque la plus répandue. Qui est tout à fait pertinente.
Avec le mécanisme de date d’expiration, il ne s’agit pas de dédouaner les expéditeurs de cette autre responsabilité qui est de moins envoyer.
Mais il ne faut pas se leurrer, même des marques attentives à leur empreinte carbone vont continuer à envoyer des emails. Et même s’ils en envoient moins, qu’ils arrêtent de cibler leurs inactifs, qu’ils segmentent mieux, qu’ils déportent leurs emails de masse vers des emails automatisés.
Donc, oui, incitons les marques à moins envoyer. Mais trouvons des solutions pour ce qui sera quand même envoyé.
C’est le rôle du destinataire, c’est lui qui est aux commandes
Seconde remarque la plus souvent rencontrée !
Dans le même ordre d’idée, certains suggèrent que les webmails et clients email pourraient proposer des outils pour supprimer en masse certains emails de manière intelligente.
L’objectif de la date d’expiration, c’est justement que les webmails et clients email aient une information supplémentaire pour créer ces outils et les mettre entre les mains des destinataires.
Donc oui, au final, c’est le destinataire qui prend la décision. Mais il faut lui simplifier la vie, sinon, comme aujourd’hui, il ne fera rien. Parce que c’est compliqué, qu’il n’y pense pas ou qu’il a peur de supprimer des messages importants.
Est-ce que ça réduit vraiment l’empreinte carbone ?
On peut même aller plus loin, est-ce qu’au contraire l’action de supprimer un email ne consomme pas plus d’énergie que le stockage indéfini ?
Quand on réfléchit à l’empreinte carbone du stockage d’un email, il faut penser à toute la chaîne, de la construction du matériel jusqu’à son recyclage et pas uniquement à la consommation d’énergie des supports de stockage.
Actuellement, s’il existe des chiffres sur l’empreinte carbone de l’email, ceux-ci sont peu précis et ne détaillent pas les différentes étapes du cycle de vie d’un email.
Il serait très intéressant d’avoir ce niveau de détail. Mais il serait dommage d’attendre d’avoir ces informations avant de bouger. Au risque de ne jamais rien faire.
L’email, en tant que protocole, est impossible à réformer
L’email est un vieux monsieur (ou une vieille dame), et, en tant que protocole, il est extrêmement difficile de le faire évoluer. C’est une remarque qui a été faite à plusieurs reprises et qui est tout à fait pertinente.
L’adoption des dernières évolutions de l’email a pris plusieurs années à se répandre… et pour certaines, ce n’est pas encore gagné (DMARC, BIMI, List-Unsubscribe, …).
Afin de contrer cette difficulté, dans la proposition initiale, il était proposé de passer par deux mécanismes différents :
- une en-tête SMTP dédiée : la voie la plus longue à faire valider et adopter
- du code Schema.org directement dans le corps du message : simple à mettre en place par les annonceurs et les routeurs
De nombreuses personnes se sont montrées sceptiques vis-à-vis de la seconde option. Concernant la première, Marcel Becker faisait remarquer sur le Slack Emailgeeks qu’une en-tête SMTP « Expires: » existait déjà dans les RFCs (https://tools.ietf.org/html/rfc4021#page-31) et qu’elle était inutilisée. Il semble néanmoins qu’on ne puisse pas recycler cette en-tête. A confirmer.
Si le projet doit voir le jour, il est donc indispensable que des spécialistes techniques de l’email se penchent sur la solution qui doit être utilisée afin de transmettre la date d’expiration de l’expéditeur du message vers Mail User Agent (MUA, i.e. client email). C’est un point crucial du projet.
Dans certains pays, les webmails et FAI pourraient ne pas avoir le droit de supprimer un email
La législation de certains pays est très restrictive concernant la confidentialité des communications électroniques. Les opérateurs ont alors l’interdiction d’intervenir dans les boites email de leurs clients et utilisateurs.
C’est une objection qui a été vue à plusieurs reprises et qui doit être adressée.
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
Il y a néanmoins plusieurs pistes qui semblent tout à fait exploitables pour respecter la loi tout en allant de l’avant :
- Demander un consentement à l’utilisateur sur le principe de suppression automatique.
- Ne pas supprimer automatiquement, mais proposer régulièrement à l’utilisateur de nettoyer ses emails sur base de la date d’expiration.
- Permettre de bloquer la suppression automatique sur certains expéditeurs ou messages.
Encore une fois, la date d’expiration n’est pas là pour supprimer des emails sans prévenir le destinataire. Au contraire, l’objectif est de l’aider, de lui simplifier la tâche… et peut-être aussi de l’éduquer à l’importance de l’écologie numérique.
C’est beaucoup de travail pour les webmails et FAIs
Oui, clairement, l’adoption de la date d’expiration des emails va nécessiter du travail du côté des webmails et FAIs.
Certains, comme Steve Atkins de Wordtothewise, s’interrogent d’ailleurs sur la nécessité d’une date d’expiration. Est-ce que les FAI n’ont pas déjà suffisamment de données pour mettre en place ces mécaniques sans l’aide d’une date d’expiration :
« If an ISP wanted to do this, they could probably do it without really needing any additional data from the sender. Identify bulk mail; offer user option to automatically archive older bulk mail, either after some length of time or to maintain no more than X messages from a sender in their inbox. »
A quoi Marcel Becker (Verizon Media/Yahoo) répond :
« yes, we already do that. We recommend to users what they should delete or not — but having additional sender signals in the expire header helps. That’s all 🙂 »
Voici une liste, non exhaustive, des fonctionnalités sur lesquelles les FAIs devraient travailler pour tenir compte de la date d’expiration et proposer la suppression (semi)automatique de ces emails :
- lire et stocker la date d’expiration
- afficher la date à partir de laquelle l’email expire dans l’interface
- collecter le consentement des utilisateurs avant de pouvoir supprimer automatiquement certains emails
- prévoir un mécanisme afin d’exclure un email ou un expéditeur de la suppression automatique sur demande du destinataire
- …
C’est beaucoup de travail pour les routeurs
Du côté des routeurs aussi il y a potentiellement du travail de mise à jour de leurs outils afin de permettre aux annonceurs de déclarer une date d’expiration et de la transmettre aux MUAs.
D’ailleurs, il est intéressant de se projeter sur l’implémentation de cette fonctionnalité. Premièrement, a priori, seuls seraient concernés les emails commerciaux, on ne peut pas imaginer qu’un email transactionnel, qui peut avoir une valeur juridique se voit imposer une date d’expiration.
Pour l’annonceur, c’est au moment de la création de son message que la date d’expiration sera définie. Au même moment dans l’interface du routeur que le choix de l’objet, de l’adresse d’expédition, …
Voici les options qu’il pourrait avoir à disposition au moment de régler la date d’expiration :
- L’email expire 30 jours après la date d’envoi (par défaut)
- Personnaliser le date d’expiration
- Ne pas définir de date d’expiration pour cet email
Il serait intéressant de proposer un cahier des charges déjà bien ficelé dont les routeurs pourraient s’inspirer (dès que les décisions techniques auront été prises).
Les prochaines étapes
1. Recueillir des promesses
Dans cette proposition, il y a une chaîne de 3 intervenants différents qui doivent tous s’engager en même temps dans la même direction. Si l’un des maillons de la chaîne ne participe pas, les efforts des autres seront vains.
Ces intervenants sont :
- Les émetteurs d’emails (annonceurs) : qui doivent s’engager à définir la date d’expiration de l’ensemble des emails qu’ils envoient.
- Les ESPs (Email Service Provider, les routeurs) : qui doivent modifier leur solution afin de collecter la date d’expiration et la transmettre aux webmails et FAI.
- Les webmails et FAIs : qui doivent traiter la date d’expiration et proposer différents outils aux destinataires afin d’arriver à notre résultat final, à savoir, réduire le nombre d’emails stockés de manière illimitée.
Nous allons donc rédiger plusieurs emails et argumentaires types afin de tenter de recueillir des promesses de participation de la part de ces différents acteurs. Si vous adhérez à ce projet, vous pourrez évidemment participer en contactant vos relations.
Ces argumentaires seront spécifiques pour ces différents acteurs, auxquels nous pourrons aussi ajouter les Associations Professionnelles.
2. Structurer le projet sur un wiki
Un Xwiki a rapidement été déployé ici : https://www.zerocarbon.email/
N’hésitez pas à vous créer un compte si vous désirez participer et commenter.
Ce Wiki nous permettra de structurer l’information autour du projet :
- Spécifications techniques
- FAQs
- Modèles d’argumentaires pour le reccueil des promesses
- Liste des marques, routeurs, webmails, FAI ayant réalisé une promesse de participation
- …
3. Valider les aspects techniques
C’est une dimension qui pourrait prendre du temps. Il serait donc intéressant de constituer rapidement une petite équipe dont le rôle serait de valider les aspects techniques du transport de la date d’expiration dans les emails.
4. Et encore d’autres choses
TBD
Merci aux contributeurs de ce débat
- Dylan Smith, Litmus, https://www.linkedin.com/in/dylanatsmith/
- Laura Atkins, Wordtothewise, https://www.linkedin.com/in/lauraatkins/
- Vytis Marciulionis, Emarsys, https://www.linkedin.com/in/vytis-mar?iulionis-b452415b/
- Mark Robbins, Salesforce, https://www.linkedin.com/in/mjrobbins/
- Marcel Becker, Verizon Media, https://www.linkedin.com/in/marcel-becker-1a69a9/
- Steve Atkins, Wordtothewise, https://www.linkedin.com/in/lluad/
- Benjamin Billon, Splio, https://www.linkedin.com/in/benjaminbillon/
- James Lamb, Spokeo, https://www.linkedin.com/in/tvjames/
- Bruno Florence, SNCD, https://www.linkedin.com/in/brunoflorence/
- Nathalie Phan Place, SNCD, https://www.linkedin.com/in/nathalie-phan-place-6bbb1124/
- Damon Sauer, Sendlane, https://www.linkedin.com/in/deepvoice/
- Christophe Alves, Scal-e, https://www.linkedin.com/in/alveschristophe/
- Mathieu Tarnus, Sarbacane, https://www.linkedin.com/in/mtarnus/
- Charles Sauthier, Groupe SeLoger, https://www.linkedin.com/in/csauthier/
- Tilak Bobby, Insider, https://www.linkedin.com/in/??-tilak-bobby-??-bb7916a8/
- Julien Musso, SmartProfile, https://www.linkedin.com/in/julienmusso/
- Armand Thiberge, Sendinblue, https://www.linkedin.com/in/armand-thiberge-72a4559/
- L’équipe de Badsender
Désolé si j’ai oublié quelqu’un 😉
