Fin de vie : obsolescence et déchets liés aux logiciels ?
La phase de fin de vie d’un logiciel est également difficile à appréhender et fait donc ici l’objet d’un article dédié, clôturant notre série sur l’ACV des logiciels.
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.
Les logiciels se cachent pour mourir (fin de vie & obsolescence)
La phase de fin de vie d’un logiciel est particulièrement délicate à envisager dans l’analyse de cycle de vie, notamment pour les deux raisons suivantes :
1) Il n’existe pas d’obsolescence intrinsèque à un logiciel. Un logiciel est théoriquement utilisable à l’infini, tant qu’il existe des matériels pour le faire fonctionner. Le logiciel ignore l’usure et ne risque pas de tomber en panne parce qu’il est lui-même devenu trop vieux. On ne peut donc pas déterminer une durée de vie d’un logiciel qui serait liée au fait que ses composants vont se dégrader au cours du temps. Les seules raisons qui rendent un logiciel obsolète sont extérieures au produit lui-même :
- décision de l’utilisateur de le supprimer,
- politique de maintenance d’une version,
- obsolescence des matériels supportant le logiciel,
- obsolescence des autres logiciels en interaction avec le logiciel (système d’exploitation, bases de données…),
- disparition du besoin utilisateur
- etc.
2) Un logiciel ne génère pas en apparence de déchets matériels en fin de vie. Lorsqu’on décide de ne plus l’utiliser – ou qu’on ne peut plus l’utiliser – il est simplement supprimé du poste sur lequel il est installé sans que cela ne génère de déchets matériels. Au pire, il reste des fichiers qui occupent inutilement de l’espace disque. Mais en réalité, si l’on y regarde de plus près on trouve des déchets matériels (déchets liés au processus de conception / développement, CD + boîte + Manuel papier (si le logiciel était emballé…)… pris en compte dans d’autres étapes de l’analyse), et surtout des déchets liés au matériel (ordinateur, smartphone, tablette, équipement réseau …) utilisé pour faire fonctionner le logiciel.
En quoi le logiciel contribue-t-il à générer des déchets ? Tout simplement par son impact direct ou indirect sur l’obsolescence du matériel :
Remplacement ou mise à jour logiciel nécessitant de nouveaux équipements :
Pour un même besoin utilisateur, si le logiciel subit une mise à jour majeure ou s’il est remplacé par un autre logiciel, et que cette opération nécessite d’autres ressources matérielles (machines plus puissantes, technologies différentes), alors on peut considérer les anciens matériels comme des déchets causés par le logiciel. C’est le phénomène d’ « obsolescence des matériels » entraîné par le renouvellement des logiciels : c’est donc le logiciel qui est responsable du déchet. Un logiciel mature (sans évolution fonctionnelle) n’a pas de raison d’être à l’origine de déchets… Mais quel logiciel n’évolue pas ? On veillera, a minima, à contrôler les consommations de ressources demandées par les nouvelles versions du logiciel.
Mauvaise désinstallation :
une procédure de désinstallation mal conçue ou mal appliquée peut aussi contribuer à l’obsolescence. En effet, des clés de registre laissées, des fichiers temporaires ; si le logiciel ne laisse pas le système comme il était avant, on crée un empreinte ressource résiduelle qui vient alourdir le fonctionnement du système.
Effet de bord de la désinstallation sur d’autres logiciels :
Il faudra également s’intéresser aux autres logiciels que la désinstallation en fin de vie peut rendre obsolètes : des dépendances peuvent exister qui risquent d’avoir un effet d’obsolescence en cascade (je mets à jour mon logiciel => il exige une nouvelle version de gestionnaire de base de données => ce gestionnaire demande une mise à jour de l’OS => le nouvel OS n’a plus de pilote pour mon imprimante => je change mon imprimante…).
On le voit, la phase de fin de vie d’un logiciel peut s’avérer complexe à appréhender. Toutefois on gagnera lors de l’étude à en faire une première approximation rapide, afin de déterminer si elle représente un poids relatif important ou non par rapport aux autres phases.
Cette série sur l’ACV des logiciels est maintenant terminée, retrouvez sur le blog les précédents articles traitant de ce sujet:
- Pourquoi réaliser une ACV des logiciels ?
- Les spécificités des produits logiciels;
- Le cycle de vie d’un logciel.
Vous pouvez auss 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.
