Dans notre série d’articles sur l’ACV mail réalisée avec Hubblo et l’ADEME, nous explorons la temporalité du transport des messages. Lorsqu’on cherche à améliorer l’efficacité d’un service nous pouvons… ralentir. Un peu comme il existait des timbres verts pour des lettres normales et des timbres rouges pour les lettres urgentes, on peut introduire des délais dans la délivrance d’un e-mail dans le cas où le message n’est pas urgent.

Dans les années 2010 avec le développement de services ayant des millions d’utilisateurs, les développeurs ont été confrontés à des problèmes de scalabilité notamment avec les traitements synchrones (immédiats). Une solution a émergé : l’utilisation de files d’attentes et de réponses asynchrones (décalées par rapport à l’action utilisateur). Par exemple, lors d’une commande, l’utilisateur pouvait voir un résumé de sa commande mais avait accès à tous les paramètres plus tard, lorsque la commande avait réellement été traitée par le système. Il s’agissait à l’époque de passer à l’échelle, mais pour réduire l’empreinte d’un service on peut aussi ralentir.

Pour notre cas de l’envoi de mail, cela permet d’attendre qu’un mobile soit connecté à un réseau local par wifi, plutôt que d’utiliser le réseau 34/4G/5G (levier 1) lorsqu’une personne est en itinérance. Cela permet aussi de retenir les messages côté serveur et d’attendre le meilleur mix énergétique pour envoyer les messages non-urgents : pendant une période où la production électrique est peu carbonnée (levier 2).

Levier 1 : modification dynamique du réseau d’accès

Avec la démarche attributionnelle, l’impact est minime (pas mesurable sauf pour l’épuisement des resources abiotiques avec gain de 0,02%). Cette absence de différence s’explique par la faible taille d’un email : en moyenne 120Ko avec 25% d’email ayant une pièce jointe dans notre échantillon.

La démarche conséquentielle court terme distingue 3 tiers :

• le tier 1 correspond au mobile. On considère que le mobile existe déjà (les utilisateurs n’achètent pas un smartphone pour l’utilisation de l’email) et que les utilisateurs ne vont pas changer de mobile pour envoyer/recevoir des emails. On considère donc la consommation d’énergie pour l’envoi/réception de mail et la différence entre wifi et 3G/4G ;
• le tier 2 représente l’utilisation du réseau. Là aussi, le réseau internet mobile existe déjà, et donc on considère les différences entre wifi et 3G/4G ;
• le tier 3, les data centers. De même, ils n’ont pas été construits pour le mail. Comme les emails ne varient pas entre le scénario de base et les différents leviers, seuls le cas du changement de type de réseau et le décalage dans le temps côté serveur ont un impact.

On observe une diminution de 22% sur l’envoi de mails pendant une semaine, mais rapporté à leur taille, cela représente un gain de 0,04 gCO2eq.

Levier 2 : Déplacement de la demande dans le temps

Avec l’analyse conséquentielle court terme on obtient:

Comme pour le levier 1 on observe une diminution de 20% sur l’envoi de mails pendant une semaine, mais rapporté à leur taille, cela représente également un gain de 0,04 gCO2eq.

On constate finalement dans les deux cas un effet très limité qui est lié à la taille des mails envoyés. En revanche, pour des services dont les données échangées seraient beaucoup plus volumineuses (par exemple des vidéos), cette possibilité pourrait avoir des effets notables. Par exemple un boîtier avec une antenne TNT pourrait proposer en local sur le réseau wifi une liste d’émissions et séries, l’utilisateur·ice choisit ce qui l’intéresse sur son mobile, le boîtier enregistre (pour la TNT) et télécharge (pour internet) les contenus pour les installer sur le mobile. Quand l’utilisateur·ice regarde ses contenus plus tard sur son mobile, ils sont stockés dans la mémoire et la communication 4G/5G n’est pas utilisée pour le flux vidéo. Et vous, imaginez-vous d’autres scénarios possibles d’usages asynchrones pour épargner le réseau ?

Retrouvez les autres articles de la série :

• La présentation
• La description des leviers
• Le facteur de la taille de l’infrastructure
• La durée de vie des terminaux
• Ainsi que l’étude complète.

Photo de Mathyas Kurmann sur Unsplash

Problème du jour, nous souhaitons renommer une colonne dans une table de notre schéma SQL. Problème simple ou compliqué ? Explorons les enjeux et impacts potentiels de cette action à priori anodine par l’angle de l’architecture évolutive et du déploiement continu.

Dans le cadre de l’appel à projets “Études d’écoconception des produits et des services” de l’ADEME, nous avons réalisé en partenariat avec Hubblo une Analyse de Cycle de Vie (ou ACV) relative à l’impact du mail.

Nous avons récemment changé notre façon de documenter le Design System des outils de l’écosystème autour d’Iroco. Dans cet article un peu technique, nous expliquons les raisons de ce changement. Nous décrivons notre démarche pour comparer quelques alternatives. Nous concluons avec les raisons de notre choix final.