Bilan carbone simplifié du service Paylib
Introduction
L’aventure numérique responsable Publicis Sapient a commencé il y a 2 ans lorsque j’ai fait ma première présentation de sensibilisation à l’impact environnemental du numérique. Le sujet a depuis gagné en importance et nous avons développé notre approche de l’écoconception qui repose notamment sur le parti pris de systématiquement modéliser les émissions de CO2 du service numérique dans son ensemble (incluant l’impact de la phase de fabrication et en faisant des hypothèses pour combler les données manquantes) avant de commencer à appliquer les bonnes pratiques d’écoconception. Nous nous assurons ainsi d’investir des efforts proportionnés au bénéfice attendu. C’est la démarche que nous avons appliquée avec notre client Paylib et elle a conduit à des résultats parfois contre-intuitifs qui nous ont montré que l’écoconception ne se fait pas toujours là où on croit. Pour rappel Paylib est un service de paiement instantané par numéro de téléphone directement intégré dans les applications des établissements bancaires partenaires.
Je ne parlerai que d’impact environnemental dans cet article car c’est le sous-domaine du numérique responsable que nous avons choisi de traiter en priorité. De même au sein de l’impact environnemental je ne parlerai que d’émissions de CO2 car nous avons fait le choix d’être monocritère dans notre analyse. En effet, les facteurs d’émission de CO2 sont les indicateurs environnementaux les plus matures à l’heure actuelle. Ils ont le mérite de couvrir à la fois les phases de production, de distribution et d’utilisation (et sont négligeables en ce qui concerne la fin de vie pour les devices numériques d’après cette étude de l’ADEME et ARCEP). De plus, la démarche de sobriété que nous mettrons en place en tant que développeurs a peu de risque de créer des transferts de pollution.
Périmètre d’étude
L’objectif de cette analyse est d’obtenir un ordre de grandeur des émissions de CO2 dues à la fabrication du hardware et à la consommation d’électricité nécessaires au fonctionnement du service Paylib. Cette analyse repose sur des données très haut niveau et sur des hypothèses, dans l’idée d’obtenir des résultats rapides pour identifier les priorités d’écoconception.
Le périmètre du système étudié est le suivant:
- Le site de récupération de fonds https://recup.paylib.fr et site vitrine https://paylib.fr. Le service de récupération de fonds est utilisé dans le cas où le destinataire du paiement n’a pas déjà son IBAN dans le service Paylib. Il a alors la possibilité de renseigner son IBAN pour recevoir le paiement par virement.
- L’infrastructure informatique Paylib.
- Les applications Paylib Android et iOS.
Cette analyse exclut les prestataires externes de Paylib, l’IT de l’entreprise ainsi que l’usage du service Paylib dans les applications bancaires partenaires.
Pour préserver la confidentialité des données Paylib tout en conservant des ordres de grandeur réalistes tous les chiffres présentés dans cette analyse se feront sur la base d’un million de visites (dans le cas des sites) ou d’utilisateurs (dans le cas des apps et de l’infra).
Les sites Paylib
Le parcours utilisateur du site de récupération de fonds est très simple, épuré et ne nécessite qu’environ 1 Mo de transfert de données. Les principaux paramètres que nous avons utilisés pour modéliser le système terminal utilisateur — réseau — serveur sur les phases de fabrication et d’utilisation sont les suivants :
- 2 minutes de temps de visite, qui permettent d’attribuer une fraction de la fabrication du smartphone au prorata temporis, sur la base de 3h30 d’utilisation quotidienne (Source State of mobile 2022) et d’une hypothèse de durée de vie de 3 ans.
- Fabrication d’un smartphone : 30 kg de CO2 eq (source ADEME).
- Intensité énergétique du réseau mobile : 0,12 kWh / Go (chiffre d’une étude récente de la société de télécom Finlandaise).
- Hypothèse de 0,1 Mo de données de tracking uploadées et stockées par visite.
Le chiffre d’intensité énergétique du réseau mobile est peut-être très inférieur à celui que vous avez en tête (le site websitecarbon.com utilise 0,81 kWh / Go par exemple), mais son périmètre est limité à l’électricité utilisée directement par le réseau (contrairement au chiffre de websitecarbon qui prend en compte notamment la fabrication des terminaux utilisateurs, que nous comptons déjà par ailleurs) et surtout c’est un chiffre récent (étude de 2021). La fraîcheur de ce type de données est essentielle car même si les gains d’efficacité ralentissent on peut garder en tête qu’en ce moment on divise environ par 10 tous les 10 ans la quantité d’énergie nécessaire pour faire une quantité de calcul donnée (cf cet article sur la loi de Koomey si vous voulez en savoir plus).
La modélisation nous donne un résultat de 500 kg CO2 eq / an / million de visites d’émissions liées à l’existence du service, à 80% dues à la fabrication des smartphones. Cela représente un ordre de grandeur de 0,5 g CO2 eq par visite, ce qui est un ordre de grandeur que nous retrouvons souvent dans ce genre de calcul.
Concernant le site vitrine, davantage de données transférées et une durée moyenne de visite plus courte mènent à un chiffre très similaire. L’ordre de grandeur de l’impact carbone des 2 sites Paylib est donc d’une tonne de CO2 eq par an et par million de visites sur chacun des sites.
Analyse de l’infrastructure informatique
Pour ce qui est de l’empreinte carbone de l’infrastructure, nous avons utilisé l’outil Datavizta auquel nous avons fourni la liste des serveurs et des capacités de stockage des environnements de production et de pré-production. Les résultats obtenus (approximatifs car reposant sur beaucoup de valeurs par défaut de l’outil) indiquent un impact d’environ 3 tonnes de CO2 par an et par million d’utilisateurs, réparties de façon égale entre l’exploitation et la fabrication des serveurs.
Il est également important de noter que l’infrastructure actuelle émet environ 50% plus de CO2 que l’ancienne. Cela suggère une tendance à la hausse de l’empreinte carbone avec la croissance du service. Toutefois, cette augmentation n’est pas proportionnelle à l’augmentation du nombre de CPU, ce qui montre que des facteurs d’efficacité sont également à l’œuvre.
Applications mobile
Nous avons également examiné l’empreinte carbone des applications Paylib iOS et Android, en utilisant le nombre de téléchargements cumulés, la taille des applications et la fréquence des mises à jour. Un point notable est le fait que l’utilisation de ces applications est relativement faible, car les paiements Paylib ne s’effectuent pas dans l’application Paylib mais dans les applications des banques. L’application Paylib permet d’accompagner les utilisateurs pour utiliser ou activer le service, de gérer son compte Paylib et de créer et gérer des groupes de dépense. Il a donc été important de prendre en compte la fonctionnalité d’hibernation des systèmes d’exploitation iOS et Android (cf cet article sur l’hibernation des applications Android et cet article sur la décharge des applications iOS) pour ne pas considérer qu’une application inutilisée était mise à jour systématiquement.
En prenant en compte ces facteurs, l’empreinte carbone d’un million d’applications Paylib s’élève à environ 2,5 tonnes CO2 eq / an.
Conclusion
Notre modélisation a donné les résultats suivants :
- 1 tonne CO2 eq / an / million de visites pour les sites de récupération de fonds et vitrine,
- 3 tonnes CO2 eq / an / million d’utilisateurs pour l’infra,
- 2,5 tonnes CO2 eq / an / million d’utilisateurs pour les applications iOS et Android.
Nous obtenons un total d’environ 7 tonnes d’émissions de CO2 eq par an et par million d’utilisateurs. Est-ce beaucoup ? Deux comparaisons permettent de s’en rendre compte :
- 7 tonnes de CO2 eq correspond à 700€ en fixant un prix interne du carbone de 100€ la tonne de CO2 eq. 100€ / tonne CO2 eq est un bon ordre de grandeur à la fois de taxe carbone (c’est l’objectif 2030 en France) et de prix des quotas d’émission carbone à horizon 2030 (source étude State of the EU ETS). Même si cette taxe et ces quotas ne s’appliquent pas à toutes les entreprises aujourd’hui leur généralisation est en cours et ce chiffre est donc un bon ordre de grandeur volontariste pour un prix du carbone interne à l’entreprise.
- 7 tonnes de CO2 eq correspond également à 70% des 10 tonnes de CO2 eq émises annuellement en moyenne par Français.
Le chiffre de 7 tonnes de CO2 eq n’est donc pas très élevé dans l’absolu, mais il est proportionnel à l’utilisation. Voyons maintenant à partir de quel volume d’utilisation il devient intéressant d’investir dans une refonte d’écoconception.
Pour les sites, passer 2 jours de développement soit environ 2000€ permettrait peut-être de réduire la bande passante de 30% (certaines images sont mal dimensionnées notamment) mais ça ne réduirait l’impact des sites que de 1% car seulement 3% de l’impact vient du réseau dans notre modèle. Sur 5 ans on aurait donc économisé 50 kg de CO2 eq par million de visites soit 5€, ce qui est clairement disproportionné par rapport à l’investissement à moins d’avoir plusieurs centaines de millions de visites par an.
De même pour les émissions de l’infra à 3 tonnes de CO2 eq / an / million d’utilisateurs, il est très probable que les efforts d’optimisation ne conduisent pas à une réduction d’émissions de CO2 proportionnellement, d’autant plus que l’auto-scaling n’est pas une option envisageable car Paylib a fait le choix de serveurs privés. En faisant l’hypothèse qu’une démarche poussée d’optimisation réduirait l’impact de 30% et coûte 2 semaines de développement, on dépenserait 10 000€ pour éviter d’émettre 5 tonnes de CO2 eq / million d’utilisateurs sur 5 ans, soit 500€ / million d’utilisateurs. L’investissement devient pertinent à partir d’une vingtaine de millions d’utilisateurs. À noter que la réduction des coûts d’infrastructure engendrés pourrait contribuer à rendre cette démarche rentable à un niveau d’usage moindre.
Enfin, du côté des applications mobiles les transferts de données représentent 70% des 2,5 tonnes CO2 eq / an / millions d’applications. Si l’on estime que des optimisations techniques pourraient réduire de 20% le volume de données transférées en 2 semaines de développement, alors cet investissement de 10 000€ permettrait d’éviter d’émettre 20%*70%*2,5*5 ≈ 2 tonnes de CO2 eq sur 5 ans soit 200€ / million d’utilisateurs. Là encore l’investissement est difficilement rentable à moins d’avoir des centaines de millions d’utilisateurs.
Il n’est donc pas pertinent d’investir dans l’écoconception du service Paylib car le gain environnemental serait probablement minime. En revanche, la prise en compte accrue de ces problématiques dès la phase de conception du projet aurait certainement permis d’éviter d’émettre plusieurs tonnes de CO2 eq par an et par million d’utilisateurs sans surcoût notable, d’où l’importance d’inclure l’écoconception dans les bonnes pratiques de développement que tout travailleur de la tech devrait connaître, au même titre que le software craftsmanship.
Cette analyse montre l’importance de modéliser le système dans son ensemble avant d’appliquer les bonnes pratiques afin de ne pas surinvestir et en fin de compte décourager la pérennité de la démarche responsable. Côté modélisation, ce travail nous a poussé à prendre en compte la fonctionnalité d’hibernation des applications et à réaliser qu’elle pouvait avoir un impact majeur sur l’économie de données. N’hésitez pas à poser vos questions sur le modèle en commentaires ! Nous serons transparents sur les facteurs utilisés et nous sommes ouverts à des discussions constructives pour les améliorer.
