GreenIT.fr

Par Olivier Philippot  -  18/01/2012

Select ratingPas terribleCorrectBienSuperExcellent

 

Imprimer

Livre du Green Code Lab

A l’occasion de la publication du livre du Green Code Lab, nous publions une série d’article sur l’éco-conception des logiciels. Voici le premier de la série sur l’analyse du cycle de vie.

Pourquoi des ACV du logiciel ?

L’analyse des impacts du logiciel ne sera cohérente qu’en prenant en compte tout le cycle de vie du logiciel (du berceau à la tombe, i.e. de la conception à la désinstallation du logiciel). L’impact de la fabrication est en effet non négligeable pour certains logiciels (Trés grosses équipes de développement, infrastructure lourdes…), de la même manière qu’une fin de vie mal gérée peut être assez néfaste (cause par exemple d’obsolescence ressentie). La phase d’utilisation quand à elle est potentiellement tout aussi polluante, d’autant plus que le logiciel sera déployé à grande échelle. Les CMS comme Drupal ou Wordpress dont la performance n’est pas la meilleure et qui sont la base d’une trés grande partie des sites mondiaux en est l’exemple.

Les méthodologies actuelles d’ACV sur le logiciel ne sont cependant pas encore répandues et traitent généralement de la phase d’utilisation du logiciel intégré à du matériel (exemple de 19 grammes de CO2 : l’empreinte carbone d’un e-mail selon l’ADEME). L’immatérialité du logiciel est en effet complexe à traiter et cela pose au domaine de nouveaux problèmes : définition du périmètre du logiciel, intégration de la variable du nombre de déploiement, évolutivité constante du logiciel… Pourtant, l’ACV du logiciel lui même est un instrument de pilotage obligatoire pour l’éco-conception du logiciel. Les méthodologies de chiffrage et d’analyse du logiciel, existant depuis longtemps, sont une piste de réflexion pour de nouvelles méthodologies d’ACV.

Unité fonctionnelle comme élément de comparaison

La définition de l’unité fonctionnelle est par exemple critique et complexe pour les applications. Elle permet de comparer différents produits entre eux. Or le logiciel intègre une multitude de fonctionnalité. La définition de l’unité fonctionnelle doit prendre en compte cette contrainte. Comment comparer deux logiciels de bureautique compte tenu du nombre de fonctions, d’options et d’interfaces ?
On peut trouver des pistes de réflexions dans les points de fonctions utilisés dans le chiffrage des logiciels.

Les points de fonction permettent de mesurer la taille du logiciel en quantifiant les fonctionnalités offertes aux utilisateurs en se basant sur des modèles de calcul. Cette métrique est standardisée par l’IFPUG (International Function Point User’s Group) et par l’ISO. La méthode inventorie les éléments suivants et affecte des points :

• ENT (entrée) : fonctions d’entrée de données de l’utilisateur : Créations, modifications, duplications, validations, suppressions
• INT (interrogation) : fonctions de consultation des données : Listes, détails, annotations
• SOR (sortie) : fonctions de restitution des données transformées : Calculs, graphiques, déductions.

La somme des points attribués à tous les composants donne la taille fonctionnelle du logiciel.

• Portail complet de vente de pièces détachées sur internet : env. 6 000 points ;
• Logiciel de navigation, type Carminat, Garmin, … : 1 000 points ;
• Logiciel de comptabilité, type Ciel Compta : 2 000 points ;
• Logiciel de gestion des nomenclatures industrielles : 4 000 points;
• Logiciel d’analyse de temps et de la paie dans une grande entreprise : 5 000 points.

La définition de l’unité fonctionnelle peut ensuite se baser sur les points de fonction. Analyser l’impact de deux logiciels est alors plus cohérent si l’on compare des applications ayant le même nombre de points de fonction.

Déploiement des logiciels et analyse de l’impact 

Pour un produit physique, on arrive très bien à identifier la partie de fabrication nécessaire pour le produit fini. Or pour le logiciel, cela est beaucoup plus complexe : La fabrication du logiciel ne va pas en effet donner une unité mais plusieurs unités. Le logiciel va être en effet déployé à plus ou moins grande échelle. Nous pouvons comparer cela à la démultiplication d’un produit physique (qui elle n’est pas possible). Le déploiement permet de mutualiser l’impact de la phase de fabrication sur tous les utilisateurs mais il augmente aussi les impacts de la phase d’utilisation. Donc, deux approches sont possibles (et complémentaires) :

• On considère le périmètre d’un logiciel unique. L’impact de la phase de fabrication va donc être divisé par le nombre de logiciels déployés
• On considère la totalité des logiciels déployés. On ne divise plus l’impact de la phase de fabrication mais on multiplie l’impact de la phase d’utilisation.

La première approche est utile pour fournir des éléments de comparaison intéressants. Par exemple, si l’on veut évaluer l’impact comparatif de l’intégration de plusieurs logiciels, on pourra utiliser ces données. On pourra alors dire concrètement quel impact prendre en compte. L’impact d’un fournisseur sera beaucoup plus important si le logiciel n’a pas été déployé à grande échelle. Cela est normal car on doit assumer l’impact du fournisseur. Cependant cela ne doit pas être une excuse pour que les développeurs s’affranchissent d’intégrer des bonnes pratiques si ils déploient le logiciel à grande échelle. La deuxième approche est donc nécessaire pour analyser l’impact du logiciel vis-à-vis du déploiement. Une amélioration même mineure de l’impact lors de la phase d’utilisation aura alors un effet important sur un logiciel déployé largement. 

Autres spécificités des ACV logiciels 

Quelques autres spécificités des acv logiciels sont à noter :

• Même si un produit logiciel est commercialisé, l’effort de fabrication n’est pas terminé. Il va en effet se prolonger sous la forme de la maintenance de correction et d’évolution. Donc l’impact de la phase de fabrication va augmenter. Compte tenu que le coût de maintenance peut atteindre 80 % du coût global de fabrication, cet impact n’est pas à négliger. L’analyse du cycle de vie est donc à mettre à jour régulièrement tout au long de la vie du logiciel.
• Le logiciel évolue sous différentes formes et plus particulièrement sous différentes versions. Les nouvelles versions sont considérées comme une suite et on hérite donc de l’impact des versions antérieures
• Toutes les parties du logiciel ne sont pas toujours développées par la société : des librairies sont parfois fournies par d’autres sociétés ou d’autres développeurs. L’impact de ses modules ne peut pas être négligé. Chaque module intégré doit donc être évalué afin d’en analyser le poids sur le logiciel fini.

L’ACV d’un logiciel n’est donc pas une étape simple. C’est cependant une étape obligatoire dans l’éco-conception. Des projets pilotes seraient nécessaires pour avancer sur le sujet… Intéressé ?

Partager sur Viadeo


Tags: ACV, Green Code Lab, Green Pattern