Continuons sur notre lancée des releases aux noms de légumes verts. L’équipe GREENSPECTOR est fière de vous présenter la version v.1.15.0 Fennel de GREENSPECTOR! Détails sur les améliorations ci-dessous.
Continue reading « Découvrez « Fennel », la version 1.15.0 de GREENSPECTOR ! »
GREENSPECTOR a été retenue parmi les 31 solutions innovantes à impact positif afin de participer à l’aventure My Positive Impact.
Continue reading « MyPositiveImpact: GREENSPECTOR est candidat, à vos votes ! »Continuons sur notre lancée des releases aux noms de légumes verts, voici la version 1.14.0 Endive de GREENSPECTOR. Vous trouverez le détail des améliorations ci-dessous.
Continue reading « Découvrez « Endive », la version 1.14.0 de GREENSPECTOR ! »Lors du développement d’un objet connecté, l’autonomie est un de critères les plus importants à tester. Ne pas mesurer la consommation énergétique do votre plateforme peut potentiellement mener à certains problèmes, comme:
Mais comment pouvons-nous donc mesurer l’énergie ?
Sur ce blog, nous avons déjà expliqué plusieurs fois comment mesurer l’énergie avec uniquement un logiciel, plus particulièrement sur Android. Mais la mesure sur plateforme IoT n’est pas si simple : pas de sonde énergétique embarquée, pas d’API… Il faudra donc faire des mesures du matériel.
Pour mesurer la consommation énergétique il faut utiliser un shunt. C’est un resistor qui est à placer dans votre circuit électrique : quand le courant passe à travers le resistor, une tension différentielle se crée. Et l’énergie peut se calculer avec la loi d’Ohm : Energie = Tension x Courant.
On intègre ce shunt de deux manières : haute tension et basse tension. Le fait de choisir haute ou basse dépend de la position du shunt, selon la batterie et l’énergie à l’intérieur. La position « Haute » est localisée entre le point positif de la batterie et votre charge (plateforme), et la « Basse » se positionne entre la masse de batterie et la masse de plateforme.
Le côté Basse tension présente quelques désavantages, plus particulièrement liés à la commutation de la charge qui crée des problèmes de boucle de masse. C’est généralement le cas pour l’IoT, avec les capteurs, régulateurs, etc… Choisissons plutôt donc de mesurer le côté Haute tension !
Arduino fournit un tutoriel axé sur la mesure d’énergie avec une breakout board INA219 et une précision à 1%.
La câblage est plûtot facile à réaliser en utilisant une breadboard et en suivant le tutoriel Adafruit.
Pour tester votre installation, vous pouvez essayer avec un exemple. Vous obtiendrez alors quatre informations :
Nous pouvons maintenant intégrer la plateforme IoT et pour cela nous avons choisi un Raspberry, ce qui est plutôt cool à mesurer avec un Arduino !
La première difficulté rencontrée est l’insertion du shunt entre le point d’énergie positif de la batterie et le Vin du Raspberry.
Dans un premier temps, vous pouvez l’intégrer directement sur la board Raspberry, en coupant le circuit. Mais nous avons choisi une option moins intrusive, consistant à l’intégrer dans le câble d’alimentation. Raspberry étant alimenté par USB, nous devons donc placer le shunt entre le V+ de l’ordinateur et le V+ du Raspberry :
En situation réelle, cela donne cela :
Vous devez maintenant lancer le code exemple pour obtenir le courant et la tension de la plateforme. Pour un Raspberry sans aucune configuration particulière (sans OS, sans carte) j’ai obtenu une puissance moyenne de 230 mW.
Ensuite, vous n’avez plus qu’à initier les mesures de vos différents projets ! Par exemple, vous verrez ici comment j’ai mesuré une station météo Arduino.
Suite logique des versions Avocado, Broccoli et Cucumber, l’équipe GREENSPECTOR a le plaisir de vous présenter la toute nouvelle Release 1.13.0 Dill Pickle ! Vous trouverez le détail ci-dessous des mises à jour et dernières features implémentées.
Continue reading « Découvrez « Dill Pickle », la version 1.13.0 de GREENSPECTOR ! »La Poste est devenu opérateur national pour le passage du code de la route depuis 2016. Cet examen appelé ETG (Examen Technique Général) se traduit par la mise à disposition d’une tablette dans une salle d’examen d’un bureau de poste et d’une série de questions posées à chaque candidat. Chaque bureau de poste est donc équipé de tablette de type Galaxy Tab A.
Continue reading « [Retour d’expérience] Le projet ETG du Groupe La Poste »Comme son nom l’indique, UI Automator est un framework fourni par Android permettant d’exécuter des tests fonctionnels d’interface utilisateur (UI pour User Interface en anglais) de façon automatisée.
Ce framework permet d’interagir avec les éléments visibles sur l’écran du smartphone : cliquer sur un bouton, remplir un champ texte, scroller, etc.
Grâce à UI Automator, vous pouvez par exemple lancer une application, remplir un formulaire de login, naviguer dans les menus…
Écrivons ensemble un premier scénario de test avec UI Automator !
Notre objectif sera modeste : lancer une vidéo depuis l’application YouTube pour Android.
Dans le framework Android, vous trouverez aussi Espresso : quelle est la différence ?
UI Automator est plutôt orienté tests « boîte noire » : vous pouvez tester n’importe quelle application (même si vous n’avez pas le code) ou même accéder à des paramètres systèmes d’Android (par exemple le panneau de configuration).
Espresso, lui est plutôt orienté tests « boîte blanche » : vous devez avoir le code de l’application à tester, vous pouvez effectuer des assertions plus fines (par exemple sur la création d’activité dans l’application).
Il existe également d’autres outils, comme Appium, mais qui ne sont pas intégrés dans le framework Android.
Ils ont l’avantage d’offrir des fonctionnalités en plus et des couches d’abstractions supplémentaires. C’est cependant au prix d’une certaines complexité de mise en place.
Vous l’aurez compris, UI Automator est pour nous le plus adapté et le plus simple pour commencer rapidement !
Les tests UI Automator font partie de la famille des test instrumentés : ils doivent être exécutés sur un smartphone ou sur un émulateur Android.
Pendant le test, deux APK s’exécutent au sein du même processus : un premier APK pour l’application à tester et un deuxième APK pour le test.
Vous avez donc besoin d’une application (et d’un scénario !) à tester.
Le code source d’une application Android est usuellement organisé de la façon suivante :
module
|---src
|---androidTest
|---main
|---testPremier cas : vous êtes le développeur de l’application à tester.
La solution la plus simple consiste alors à développer les tests dans le même module que l’application.
Le dossier main contiendra alors le code source de votre application et le dossier androidTest vos tests UI Automator.
Deuxième cas : vous n’avez pas le code source de l’application à tester.
Il vous suffit alors de créer un nouveau module : le dossier main sera vide et, comme précédemment, le dossier androidTest contiendra vos test UI Automator.
Dans le fichier build.gradle du module, ajoutez les configurations suivantes (UI Automator fonctionne avec AndroidJUnitRunner) :
android {
...
defaultConfig {
...
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
...
}dependencies {
...
androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2'
androidTestCompile 'com.android.support.test:runner:0.5'
}Après vous être assuré que le projet compile correctement, il est temps d’ajouter une nouvelle classe dans module/src/androidTest :
@RunWith(AndroidJUnit4.class)
public class YouTubeTest {
@Test
public void watchVideo() throws Exception {
// TODO
}
}Tout est maintenant prêt pour l’implémentation du scénario de test !
Quelques petites précisions avant de se lancer…
UI Automator permet d’interagir avec les éléments visibles sur l’écran.
Chaque élément possède un certain nombre de propriétés, parmi lesquelles : content-description, class, resource-id, text.
UI Automator permet de rechercher un élément vérifiant une propriété donnée.
Par exemple, pour accéder au bouton Valider affiché sur votre écran, vous pouvez rechercher l’élément dont la propriété text vaut Valider.
Mais vous pouvez aussi être plus spécifique, par exemple : l’élément dont la class est android.widget.EditText et la content-description est text_name.
La (ou les) propriété(s) utilisée(s) pour rechercher un élément a son importance.
Par exemple, méfiez-vous des libellés, notamment si votre application est disponible en plusieurs langues !
Afin de connaître les propriétés des éléments visibles sur l’écran, il est très pratique d’utiliser l’outil Android uiautomatorviewer (que vous trouverez dans le répertoire tools de votre SDK Android).
Une fois lancé, cet outil permet de faire des captures d’écran d’un smartphone Android.
À chaque capture d’écran est associée un arbre représentant la hiérarchie des éléments visibles, avec leurs propriétés respectives.
Revenons à notre scénario de test, pour lequel nous nous proposons d’effectuer les actions suivantes :
Avant de démarrer toute interaction avec les éléments sur l’écran, il faut instancier un objet UiDevice qui représentera l’état actuel de l’écran du smartphone.
UiDevice mDevice = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());Commençons par lancer l’application YouTube, comme expliqué dans la documentation Android.
L’objet de cet article étant de dérouler quelques fonctionnalités les plus simples d’UI Automator, cette étape n’est pas détaillée.
L’étape suivante consiste à cliquer sur la loupe pour effectuer une recherche.
Après avoir repéré le resource-id de la loupe grâce à uiautomatorviewer, nous utilisons la méthode waitForExists permettant d’attendre que l’élément apparaisse avant de cliquer sur l’objet.
UiObject icon = mDevice.findObject(new UiSelector().resourceId("com.google.android.youtube:id/menu_search"));
icon.waitForExists(TIMEOUT);
icon.click();Nous nous servons ensuite de la méthode setText pour renseigner le mot clé de recherche souhaité.
UiObject editText = mDevice.findObject(new UiSelector().text("Search YouTube"));
editText.waitForExists(TIMEOUT);
editText.setText("greenspector");
mDevice.pressEnter();Précédemment, nous n’avons utilisé qu’un seul critère pour rechercher les éléments sur l’écran.
Mais il est possible d’en combiner plusieurs (si certaines propriétés ont la même valeur pour plusieurs éléments), par exemple :
UiObject video = mDevice.findObject(new UiSelector()
.resourceId("com.google.android.youtube:id/title")
.text("Power Test Cloud - Greenspector (FR)"));Enfin, attendons quelques secondes en regardant le début de la vidéo.
synchronized (mDevice) {
mDevice.wait(20000);
}Afin d’exécuter les tests, il est nécessaire d’être connecté via ADB à un smartphone (soit un smartphone physique « réel », soit un émulateur Android).
Le lancement peut s’effectuer directement depuis Android Studio, ou bien en ligne de commande avec ADB.
Premier cas : depuis Android Studio.
Se rendre dans le menu Run, puis Edit configurations.
Cliquer sur le signe + pour ajouter une configuration, sélectionner le modèle Android Instrumented Tests.
Adapter la configuration avec le nom du module à tester, le type de test, le smartphone (réel ou émulateur).
Deuxième cas : en ligne de commande avec ADB.
Tout d’abord, compiler l’application ainsi que les tests, par exemple en utilisant les tâches assemble et assembleAndroidTest du wrapper Gradle :
$ ./gradlew clean assemble assembleAndroidTestPuis installer sur le smartphone les fichiers .apk générés :
$ adb install module/build/outputs/apk/module-debug.apk
$ adb install module/build/outputs/apk/module-debug-androidTest.apkEnfin, lancer le test :
$ adb shell am instrument com.package.test/android.test.InstrumentationTestRunnerEt voilà ! Objectif atteint pour ce premier test simple UI Automator, c’est maintenant à vous de jouer !
L’influence des couleurs sur la consommation d’énergie des smartphones ou des tablettes est un débat récurrent. On entend beaucoup d’affirmations péremptoires (du type «choisis un fond noir pour consommer moins») qui bien souvent ne tiennent pas compte des technologies sous-jacentes – pourtant très diverses – ou d’études précises sur le sujet. Alors comme d’habitude, en tant qu’obsédé des mesures d’énergie sur appareils mobiles, j’ai voulu en savoir plus.
La réduction des consommations d’énergie des appareils mobiles est un leitmotiv pour tous les constructeurs. En effet,l’autonomie est un des critères de choix principaux avant l’achat d’un appareil. Les fabricants travaillent donc à optimiser tous les composants: amélioration de l’efficience des processeurs, technologies de senseurs moins consommatrices, augmentation de la capacité des batteries… Lorsque j’ai mis au point la méthodologie de mesure de consommation d’énergie des logiciels chez GREENSPECTOR, j’ai été amené à étudier tous les paramètres qui peuvent influencer cette consommation. Oui, les écrans en font partie, mais il me semblait intéressant de creuser un peu ce sujet. Allons-y.
Pour mesurer les comportements énergétiques des écrans, je crée une petite batterie de tests qui fait varier la luminosité de l’écran par paliers (0%, 25%, 50%, 75% et 100%) et d’afficher une page complète d’une certaine couleur (Rouge, Vert, Bleu, Noir, Blanc). Puis j’exécute les tests sur les divers appareils dont nous disposons dans notre Power Test Cloud. Les consommations d’énergie (et d’autres ressources) sont mesurées par les sondes GREENSPECTOR qui sont installées sur ces appareils. Puis je récupère les résultats des mesures, et je trace des jolis graphes pour les interpréter plus facilement.
Je commence par mon appareil favori, le Motorola Nexus 6 dont l’écran utilise la technologie AMOLED. On obtient la cartographie suivante des consommations suivantes : en abscisse les différentes couleurs affichées, dans la profondeur les variations de luminosité, et sur l’axe vertical, on retrouve la consommation de batterie qui en résulte :
Le Nexus 6 se base sur une technologie AMOLED : Matrice Active LED ou de l’anglais Active-Matrix Organic Light-Emitting Diode. C’est une technologie qui lie la technologie OLED (diode électroluminescente organique) et celle des matrices actives (commande de chaque pixel indépendamment). C’est une alternative à la technologie historique des LCD (écrans à Cristaux Liquides).
Le noir est facile à réaliser pour les écrans AMOLED car il faut juste éteindre des pixels. C’est pourquoi le noir consomme moins. Le blanc est une composition du bleu, rouge et vert, on le retrouve donc dans la moyenne des couleurs.
Afin de confirmer ce comportement énergétique, je mesure celui du Galaxy S6 qui exploite une technologie dérivée, baptisée Super AMOLED:
On observe le même comportement avec une légère différence : cette fois c’est le blanc qui consomme le plus (44% de plus que le noir) en devançant légèrement le bleu. Globalement les constats sont les mêmes : le noir est beaucoup moins consommateur, et le blanc et le bleu consomment plus que les autres couleurs.
Pour les AMOLED, c’est clair. Mais qu’en est-il pour les autres technologies ? Prenons par exemple le Nexus 5 qui est sur une technologie LCD IPS+:
On voit clairement qu’avec un écran LCD IPS+, la couleur ne joue pas sur la consommation. On peut juste noter qu’à la luminosité maximale, le blanc sera très légèrement plus consommateur (4% d’écart soit 10 à 15 mn de différence sur l’autonomie théorique).
La technologie IPS (In-Plane Switching) est une technologie LCD. IPS+ ajoute des LED pour améliorer l’affichage. Sur les écrans LCD la théorie veut que la consommation soit indépendante de la couleur : tout est bon donc ! Au passage, notons que la technologie Retina des écrans Apple reposait jusqu’à présent sur une technologie IPS, mais il semble que cela va changer avec le nouvel iPhone 8S basé sur un écran OLED : designers d’apps iOS, prenez-en note.
La mesure sur une tablette Nexus 9, elle aussi basée sur une technologie IPS donne les résultats suivants :
Les constats sont les mêmes que le Nexus 5, avec un écart de 2% à peine entre les couleurs.
En effectuant les mesures sur la tablette Google PixelC, modèle récent en technologie toujours LCD mais dans sa variante LTPS , on obtient ceci :
Il y a toujours une indépendance globale de la consommation de batterie vis-à-vis de la couleur. Cependant une couleur se détache légèrement: l’impact du blanc à luminosité maximale est 12% plus fort que celui du noir (soit 9h d’autonomie en noir contre 8h en blanc).
Le LCD LTPS (Low Temperature Poly-Silicon) est en fait une technologie Thin Film Transistor (TFT) avec une technologie à matrice active (comme les AMOLED). La différence sur les blancs provient probablement de la possibilité d’activer ou non les pixels.
Maintenant que nous avons fait ces quelques tests, essayons de comparer ces différents modèles entre eux. Pour cela, prenons la consommation causée par l’affichage d’un écran blanc ou noir, divisée par la taille de l’écran. Pour exprimer la notion de taille, nous ne prenons pas sa surface (ce qui serait scientifiquement plus exact) mais simplement sa diagonale exprimée en pouces, car c’est la seule information dont dispose l’utilisateur : c’est donc celle-là qui lui importe lorsqu’il doit faire un choix :
Basé sur une technologie AMOLED, le Galaxy S6 a une consommation assez élevée. Idem pour le Pixel C avec sa technologie LTPS IPS (avec une augmentation exponentielle de la consommation quand la luminosité augmente). Dans les blancs, aucune technologie ne sort du lot en fait. Cette analyse est cependant à considérer avec précaution car nous n’avons pas mesuré beaucoup d’appareils.
En observant le comportement du noir, on retrouve l’intérêt de la technologie AMOLED dont la consommation est constante. Cependant à luminosité minimale (0 %), la consommation est plus importante que pour les autres technologies. Sur la plage 25% – 50% il n’y a pas de différence ; et l’avantage est clair pour des luminosités fortes où l’AMOLED tire son épingle du jeu.
Voici venu le moment de délivrer notre verdict. Faut-il choisir un fond d’écran noir pour son smartphone ou sa tablette ?
Si vous avez un écran AMOLED : oui ! Sans hésiter, choisissez pour votre fond d’écran une image avec une couleur prédominante noire. (Pour savoir quel type d’écran vous avez-, , regardez les spécifications sur le site du constructeur ou sur des sites dédiés). Si votre appareil est basé sur une technologie différente, vous pouvez toujours appliquer cette bonne pratique, cependant les gains d’autonomie seront moindres.
Dans la même logique, préférez les applications avec des interfaces ou des skins noirs (comme Google Black par exemple, ou le « mode nuit » de Twitter…). Et si votre application préférée ne propose pas de version « sombre », demandez-la à l’éditeur….
Pour tous : configurez la luminosité au minimum nécessaire pour assurer un bon confort d’utilisation. A 25% les technologies actuelles permettent souvent d’avoir un bon rendu. Évitez le 100% permanent – c’est une valeur que je réserve pour l’extérieur les jours ensoleillés. Si vous en disposez sur votre appareil, activez l’adaptation automatique de la luminosité… Mais vérifez cependant qu’elle n’est pas trop lumineuse, dans ce cas une configuration manuelle pourrait être plus efficiente.
Comme l’usage, les paramètres et les designs d’écran sont maîtrisés, il est possible de choisir le smartphone le plus adapté à l’usage. Ne vous fiez pas uniquement aux données constructeurs, vous pouvez effectuer des tests adaptés qui vous donneront une idée plus claire de l’autonomie réelle. Spécifiez des interfaces adaptées à vos téléphones. Si vous avez une flotte avec écrans AMOLED, il est important pour l’autonomie de vos appareils d’avoir des interfaces plutôt sombres que claires.
Le choix des couleurs dépend principalement de la charte graphique et de la marque mais la consommation d’énergie peut être un critère supplémentaire qui rendra votre design plus efficient. Il est intéressant de spécifier idéalement deux thèmes : un sombre et un gris. Cela permettra à l’utilisateur de choisir le thème le plus adapté à son appareil.
Afin d’adapter le design au contexte matériel, il est intéressant d’offrir à l’utilisateur le choix d’un thème plus sombre. Il faudra donc implémenter une option de modification de l’écran (facile avec des CMS, plus compliqué avec un framework).
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.
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 :
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 :
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.
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.
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:
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.
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:
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.
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.
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 :
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.
Différents scénarios sont possibles, ici seuls 3 sont rapidement présentés (d’autres sont possibles).
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 :
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.
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.
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.