Écoconception des logiciels : Spécificités des produits logiciels
L’objectif de cet article est de présenter les caractéristiques propres aux logiciels lors d’une analyse de cycle de vie (ACV). Pour chacun des problèmes que soulèvent ces spécificités, nous indiquerons l’approche que nous recommandons 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 ici.
Logiciel : bien matériel ou immatériel ?
Le logiciel est un bien particulier :
• Il ne génère pas de déchet physique direct
• Il n’est pas directement branché à une source d’alimentation et n’est donc pas perçu comme « consommateur ».
• Il a néanmoins un impact sur l’environnement à travers une consommation de ressources et d’énergie due au matériel nécessaire à son développement et à son utilisation.
L’ACV a pour but d’évaluer les impacts environnementaux de biens manufacturés, services et procédés. Mais où se situent les logiciels parmi ces trois types de produits ?
À première vue, les logiciels s’apparentent fortement à des biens matériels tels que ceux créés par l’industrie traditionnelle puisqu’ils sont matérialisés par un ensemble de données informatiques (code source et / ou exécutable) que l’on peut échanger, posséder et utiliser pour satisfaire un besoin précis. Mais il faut bien distinguer le support de stockage et les interfaces physiques d’interaction du logiciel lui-même : le logiciel n’est en réalité rien de plus qu’un état du support de stockage (constitué par une suite bien définie et unique de 0 et de 1), un état du réseau transportant ces données, un ensemble d’états de l’écran affichant la représentation graphique du logiciel, etc. Devrions-nous donc considérer le logiciel plutôt comme un bien « immatériel » ?
Pour répondre à ces questions, il convient de bien faire la distinction entre le logiciel lui-même et le service qu’il rend. Ainsi, on peut effectivement considérer un logiciel comme un bien immatériel qui rend un ou plusieurs services particuliers (ses fonctionnalités ou contenus). En tant que bien immatériel, ses impacts environnementaux résulteront de l’utilisation de ressources (humaines, physiques/matériels…) nécessaires à la mise en œuvre des différentes phases de son cycle de vie : fabrication/développement, fonctionnement, distribution, fin de vie.
Faut-il isoler un logiciel de son environnement de fonctionnement ?
Il est évident qu’un logiciel ne fonctionne jamais seul, mais toujours dans un écosystème avec d’autres logiciels dont il dépend, à commencer par l’OS (système d’exploitation), ou avec lesquels il est en communication ou en interaction. Ainsi, mesurer les impacts générés par le seul logiciel étudié en phase d’utilisation est compliqué.
L’impact du logiciel est indissociable du matériel et de l’OS avec lequel il fonctionne : il n’est pas possible lors d’une ACV d’identifier directement les impacts environnementaux liés à l’OS ou au matériel. Ces impacts peuvent malgré tout être obtenus au travers d’ACV comparatives, c’est-à-dire en comparant par exemple les ACV de deux configurations bien spécifiques : par exemple Logiciel A sur équipement X avec OS1 versus Logiciel A sur équipement X avec OS2 ; c’est ainsi qu’il sera possible d’identifier le delta d’impacts entre les OS1 et OS2. D’autres analyses de sensibilité permettraient d’évaluer les deltas d’impact liés aux différents matériels par exemple.
Un équipement informatique ne fonctionne pas uniquement pour le logiciel étudié. Généralement d’autres applications/logiciels fonctionnent en parallèle sur le même équipement et donc consomment des ressources. Aussi la totalité de la puissance consommée par l’équipement ne peut pas être attribué au logiciel considéré. La stratégie prise dans le cadre du projet de recherche Web Energy Archive pour attribuer au logiciel l’énergie qu’il consomme, est de retrancher la consommation d’énergie due à l’OS et aux services tels que l’antivirus (on parle de consommation en mode idle), à la consommation totale de l’équipement.
Logiciel : quel périmètre considérer?
L’une des principales difficultés à laquelle on se heurte lorsque l’on réfléchit à l’évaluation des impacts environnementaux d’un logiciel est que ce dernier évolue régulièrement au travers des différentes versions (correctrices ou fonctionnelles) et peut avoir une architecture modulaire, voire fonctionner simultanément sur différents équipements.
Un logiciel évolue sans cesse.
Un logiciel se décline la plupart du temps en une multitude de versions et sous-versions qui comprennent des ensembles de fonctionnalités différents. On peut être tenté de dire que cela ne pose pas de problème majeur car les versions sont très espacées dans le temps… mais c’est rarement le cas. Suite à la sortie par un éditeur d’une « release » officielle de version bien identifiée, le logiciel peut très rapidement faire l’objet de patchs correctifs ou de modules complémentaires qui peuvent devenir très nombreux et fréquents. Cette approche de releases fréquentes s’est nettement accentuée ces dernières années.
Il faut donc différencier les évolutions mineures, des évolutions majeures d’un logiciel :
• Les évolutions majeures apportent de nouvelles fonctionnalités, voire restructurent complètement une application.
• Les évolutions mineures apportent principalement des corrections de bugs ou des ajouts de fonctionnalités secondaires.
Puisqu’il est difficile de parler de version « finie » d’un logiciel, nous proposons de limiter l’étude à la « dernière version stable la plus largement diffusée et utilisée ». Quoiqu’il en soit, la version étudiée devra figurer clairement dans les hypothèses de l’étude.
L’impact des versions correctives et/ou fonctionnelles, qu’elles soient mineures ou majeures ne pourra être pris en compte qu’au travers d’une analyse de sensibilité. C’est-à-dire que l’on modélisera l’impact d’une correction de bug et une évolution fonctionnelle par l’ajout de ressources supplémentaires (RH, consommation de papier, matériel…) lors de la phase de fabrication/développement ou au travers d’une nouvelle phase spécifique (maintenance).
Un logiciel est souvent modulaire.
Un logiciel peut être lui-même découpé en plusieurs modules que l’on peut choisir d’installer ou non, ou bien il peut offrir la possibilité d’être étendu par des plugins ou add-ons (comme la plupart des navigateurs web par exemple).
La notion de modularité d’un logiciel ne pourra pas être modélisée comme telle au travers d’une ACV, car il sera difficile voire impossible d’identifier les ressources spécifiques nécessaires au développement de tels ou tels module. Il faudra donc considérer la configuration la plus standard possible, puis des analyses de sensibilité pourront être faites pour évaluer les impacts liés à des ressources nécessaires pour le développement de modules particuliers (RH, matériels…).
Pour poursuivre cette série sur l’ACV des logiciels, nous traiterons dans le prochain article du blog du cycle de vie. En effet, ci celui-ci est pertinent pour un produit matériel usuel, il l’est beaucoup moins pour un logiciel et nous découvrirons pourquoi.
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.
