Écoconception des logiciels : Quel est le cycle de vie d’un logiciel ?

Reading Time: 5 minutes

L’objectif de cet article est de présenter le cycle de vie d’un logiciel. Pour chacun des problèmes que soulève l’analyse de ce cycle de vie, nous indiquerons l’approche que nous recommandons, notamment pour l’évaluation des impacts environnementaux.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réelle sur l’évaluation des impacts environnementaux d’une application disponible en téléchargement.

La grande majorité des cycles de vie des produits manufacturés étudiés lors des ACV (Analyses de Cycle de Vie) peuvent être considérés comme étant composés des 6 phases suivantes:

  • la conception du produit,
  • l’extraction des matières premières,
  • le processus de fabrication et de conditionnement,
  • le processus logistique et d’acheminement,
  • l’usage du produit,
  • la fin de vie (démontage, transport, tri, recyclage, déchets).

Cependant, si ce cycle de vie est pertinent pour un produit matériel usuel, il l’est moins pour un logiciel. En effet, en tant que « bien immatériel », un logiciel ne nécessite pas directement d’extraction de matières premières.
La phase de fabrication n’est pas envisageable comme un processus de fabrication répété N fois pour produire N exemplaires du produit : il faut plutôt la considérer comme une phase unique permettant d’aboutir à une version du logiciel théoriquement reproductible et réutilisable à l’infini.

Transport amont et distribution

Pour la phase de transport amont (logistique), si le logiciel est conçu à partir de différentes modules développés sur différents sites, il faudra (dans la mesure du possible) prendre en compte l’envoi depuis les différents sites vers le site d’agrégation des différents modules. Dans une première approche ces impacts pourront être considérés comme négligeables car ayant de très grandes chances de représenter moins de 5% des impacts totaux.
Si la distribution vers les utilisateurs finaux est réalisée via un téléchargement sur internet, l’impact environnemental de ce téléchargement devra être pris en compte. Si la distribution se fait par un support matériel (DVD, clef USB…) la fabrication et le transport de ces supports devront être pris en compte.
L’installation du logiciel peut être rattachée à la phase d’usage. La maintenance pourra être modélisée comme étant un surcoût de la phase de fabrication. La fin de vie d’un logiciel semble à première vue inexistante, ou du moins sans impact. Nous verrons plus loin qu’il n’en est rien en réalité. On devra intégrer la désinstallation des programmes et la destruction /récupération des données associées.
Comme proposé au sein du Green Patterns, le manuel de référence d’écoconception des logiciels par le Green Code Lab, on peut donc pour un logiciel simplifier ce cycle de vie en ne retenant que 4 phases: la fabrication, la distribution vers l’utilisateur final, l’utilisation, et la fin de vie/réutilisation/recyclage.

La fabrication

Ce processus de conception et de développement est considéré donc comme une phase unique permettant de produire le logiciel. Cette phase intègre tout le processus de conception du logiciel :

  • analyse des besoins,
  • conception,
  • programmation,
  • test,
  • stabilisation,
  • déploiement.

Les ressources associées aux maintenances correctives (correction de bug) et les enrichissements fonctionnels, sont à inclure dans cette phase.
Un logiciel est souvent et en partie constitué de composants tels que des frameworks, bibliothèques, librairies. Dans ce cas, on pourra considérer que la fabrication de ces composants a un impact négligeable au regard du nombre de copies (réutilisations) qui en sont effectuées.

La distribution/copie vers l’utilisateur final

Différents scénarios sont possibles, ici seuls 3 sont rapidement présentés (d’autres sont possibles).

  • Téléchargement : le logiciel ainsi que la documentation sont distribués par voie électronique. Il faudra ici prendre en compte le périmètre de l’émetteur du programme (serveurs de téléchargement) mais également le récepteur (les ordinateurs des utilisateurs finaux) ainsi que l’infrastructure qui a permis de véhiculer les fichiers électroniques (réseau, routeurs, …) en prenant une quote-part de la construction du matériel et de l’énergie nécessaire au téléchargement du logiciel en fonction de la ressource utilisée.
  • Le logiciel ainsi que la documentation sont packagés et envoyés par courrier postal, il faudra prendre en compte le support (CD-ROM, DVD, clef USB, documentation), l’emballage et le transport postal associé.
  • L’utilisateur peut récupérer la licence et la notice d’utilisation dans un commerce ou par courrier postal et télécharger le logiciel. Il faut donc prendre en compte l’étape de packaging (fabrication & transport) ainsi que le téléchargement du logiciel. Dans ce cas particulier, les impacts liés au déplacement de l’utilisateur peuvent être forts et peuvent écraser les autres impacts. Des ACV précédentes, menées par le groupe Orange sur des terminaux, mobiles, modem, CD-ROM, ont montré que les déplacements des client pouvaient être très variés et très impactants, notamment s’ils ont lieu en voiture (plusieurs kg de CO2e)

L’utilisation du logiciel par l’utilisateur final débute par la phase d’installation sur son matériel (mise en service) suite au téléchargement (distribution) par exemple et couvre toute la phase d’usage du logiciel sur le matériel adéquat de l’usager. Le périmètre intègre :

  • le matériel nécessaire ou prérequis pour utiliser le logiciel. Dans ce cas, on prend en compte la quote-part de :
    • la fabrication du matériel (l’équipement de l’utilisateur, accès réseau, accès serveur),
    • l’utilisation de l’énergie en phase d’usage du matériel (l’équipement de l’utilisateur avec éventuellement l’accès réseau et serveur) et qui peut intégrer par défaut la consommation des logiciels prérequis ;
    • les logiciels prérequis intégrant leurs consommations de ressources (OS, machines virtuelles, …). On peut isoler la consommation de ressources de ces logiciels prérequis en établissant une valeur étalon appelée « Idle » qui correspond à la consommation de ressources du matériel et de ses logiciels prérequis, avant toute exécution du logiciel étudié ; cette valeur peut-être décomposée en autant de valeurs si on souhaite isoler l’OS du navigateur par exemple ;
  • le logiciel étudié intégrant sa consommation d’énergie :
    • les données nécessaires pour utiliser le logiciel ou créées par le logiciel et stockées sur les différentes ressources de matériel de l’application ;
    • la consommation d’énergie associée à ces données est intégrée par défaut dans l’équipement.

Par exemple dans le cas d’une page Web, les prérequis matériels et logiciels pour afficher la page côté utilisateur sont : un ordinateur/tablette/smartphone, un OS (Android, Windows, iOS…), le navigateur (Firefox, Chrome, Edge, Safari…) et les plugins éventuels.

La fin de vie / réutilisation / recyclage

On fait l’hypothèse qu’en fin de vie un logiciel est effacé ou désinstallé côté usager / côté éditeur du logiciel. Il y a plusieurs points à prendre en compte pour cette étape : la fin de vie du matériel support et la fin de vie des données générées par le logiciel.

  • Fin de vie du matériel support : on revient ici à une problématique habituelle de fin de vie d’un support matériel électronique donc complexe et polluant, classé en DEEE (Déchet d’Équipement Électrique et Électronique)
  • Fin de vie des données : on pourra considérer la bonne désinstallation du logiciel selon une procédure qui supprime tous les fichiers de configuration sur le poste client. On doit prendre également en considération dans cette phase les données générées par le logiciel et qui ont été créées volontairement ou non par l’utilisateur. Plusieurs cas se présentent :
    • l’utilisateur ne souhaite pas récupérer les données qu’il a produites ;
    • l’utilisateur souhaite récupérer ces données pour les utiliser avec un autre outil comparable et un processus de conversion est prévu ; ce processus a été pris en compte dans ce nouvel outil dans le cadre de sa phase de fabrication ;
    • l’outil ne permet pas le processus de récupération et de conversion des données pour une nouvelle utilisation ; on devra alors estimer l’impact de la conversion pour l’utilisateur dans cette phase de fin de vie.

Pour terminer cette série sur l’ACV des logiciels, le prochain article du blog traitera de l’obsolescence programmée des logiciels. En effet, la phase de fin de vie d’un logiciel étant difficile à appréhender, cela fera l’objet d’un article dédié

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.