• Aucun résultat trouvé

Evaluation des impacts environnementaux de la production d’électricité par panneaux photovoltaïques, sur base de l’ICV des surfaces disponibles, obtenu à partir de données SIG.

Auteur : LIST.

Contexte

Les impacts environnementaux générés par les systèmes urbains à large échelle (par exemple infrastructure pour la mobilité, pour la gestion des constructions et bâtiments, pour l’optimisation de la consommation d’énergie, etc…) doivent être considérés dans les processus de prises de décision par les autorités responsables de la planification urbaine ou territoriale. Néanmoins afin d’être pertinente et significative, l’évaluation des impacts environnementaux de tels systèmes doit tenir compte de critères techniques et également de paramètres caractérisant la variation et l’évolution du système dans le temps et dans l’espace. Ainsi la modélisation de tels systèmes en vue de leur ACV reste complexe, faisant appel à des approches innovantes telles que l’ACV dynamique et/ou le couplage entre l’ACV et la modélisation par SIG.

Cela requiert donc l’interaction entre logiciels et bases de données des différentes disciplines. La plupart du temps, des solutions ad-hoc sont développées pour répondre au besoin, impliquant beaucoup de manipulations « manuelles ». On observe très peu de développement d’outil générique pour automatiser et faciliter la connexion entre les disciplines.

L’objectif de ce cas d’étude est donc de démontrer la faisabilité de l’échange automatisé de données entre une plateforme SIG et un logiciel ACV. Pour cela, le LIST s’appuie sur les développements de son projet DAEDALUS (Developing An integrated gEospatial approach for DynAmic Life cycle assessment of housing stock retrofit at the Urban Scale). Ce projet postdoc est financé par le Fonds National de la Recherche (FNR) au Luxembourg, et l’objectif est d’évaluer l’impact environnemental de la rénovation des bâtiments à l’échelle de la ville (Mastrucci, et al., 2014), (Mastrucci, et al., 2015), (Mastrucci, et al., 2016).

Dans le cadre de ce projet, un cas d’étude a été développé pour combiner l’évaluation de la consommation électrique des ménages (demande en électricité) pour un quartier de la ville de Rotterdam, et le potentiel de production d’électricité par panneaux photovoltaïques (PV) pour ce même quartier. Pour cela la plateforme libre pour la modélisation SIG des villes iGUESS® (De Sousa, et al., 2012), développée par le LIST dans le cadre du projet européen MUSIC (The MUSIC project, 2013), a été utilisée pour créer des cartographies des villes permettant d'identifier les sources et les pertes d'énergie afin de dégager des opportunités pour améliorer l’efficacité énergétique et d’en évaluer les effets en termes de réduction de la consommation d’énergie.

Dans le cadre de DAEDALUS, un modèle statistique a permis d’estimer la demande en électricité des logements à l’échelle de la ville en utilisant des mesures de consommation, des informations caractérisant les bâtiments et les ménages occupant les bâtiments. Un modèle prédictif pour estimer le potentiel de production d’électricité par PV a également été développé, basé sur le calcul du potentiel d’irradiation solaire des surfaces de toit pour les bâtiments, à l’échelle de la ville. Grâce à ces données d’entrée, l’adéquation entre la demande et la production PV est analysée pour des profils horaires afin de déterminer si la demande peut être couverte pour chaque bâtiment ou groupe de bâtiments, et les résultats sont affichés sur des cartes à l'échelle de la ville différenciée par bâtiment ou groupes de bâtiments.

A partir de la plateforme SIG existante iGUESS® et des données disponibles pour le cas d’étude DAEDALUS spécifique à la ville de Rotterdam, l’objectif du cas d’étude du PRC ECOSD 14.1 était donc

36 de développer un connecteur entre les calculs spatialisés issus d’iGUESS et un logiciel ACV (Figure 19).

Le logiciel libre d’ACV Brightway2 (Mutel, 2016) a été utilisé pour ce couplage, puisque la structure du code de calcul des impacts du cycle de vie et le format des données restent flexibles et ouverts avec ce logiciel, permettant donc de dépasser les limites des logiciels ACV classiques. La connexion avec d’autres logiciels et bases de données par l’ajout de nouvelles fonctionnalités est donc rendue possible avec Brightway2.

Le connecteur est praticable via une interface utilisateur développée dans le cadre du PRC ECOSD 14.1, également en langage Python (Figure 19).

Figure 19: Vue schématique d’ensemble relative au connecteur et de l’interface utilisateur développés

La plateforme iGUESS®, le logiciel Brightway2 ainsi que les développements réalisés pour le PRC ECOSD 14.1 (connecteur et interface utilisateur) sont décrits et démontrés complètement dans l’Annexe 3 « Synthèse détaillée des études de cas et documentation technique du connecteur développé », indépendante du présent rapport ci-dessous. Les sections suivantes visent à donner une vision globale des développements réalisés via ce cas d’étude.

Développement d’un connecteur ACV-GIS et d’une interface utilisateur : « SIGAGIS »

Les objectifs étaient (i) de rendre possible la communication entre deux applications logicielles différentes, iGUESS pour générer les données SIG qui seront liées à l’inventaire du cycle de vie, et Brightway2 pour les calculs ACV, et (ii) de rendre cette connexion praticable via une « plateforme ». Des choix ont donc été faits en amont du développement quant aux langages de programmation, au type d’application à développer en guise de plateforme, à l’architecture de communication entre les différentes applications et la plateforme à développer.

Concernant le type d’application matérialisant la plateforme de communication, il a été décidé de développé une application web type « plug-in » puisque ça permettrait de produire une solution compatible avec les différentes architectures de systèmes d’exploitation (mac, windows, linux). Un autre avantage d'une application web est que si la plateforme devait être utilisée par un grand nombre d'utilisateurs ou si les besoins en termes de fonctionnalités augmentaient, il serait plus facile de gérer cela via une installation cloud. La plateforme ou plug-in développé se nomme « SIGAGIS ».

36 En ce qui concerne les langages de programmation, le choix naturel était d'utiliser python (Eve, n.d.), car c'est le langage de programmation du logiciel LCA Brightway et de l’application SIG iGuess. En outre, nous avons décidé de l'utiliser parce qu'il a déjà plusieurs structurations matures (groupes de paquets ou de bibliothèques) permettant l’implémentation d’applications Web.

Enfin, l'architecture de communication a été conçue comme un simple serveur client, où SIGAGIS joue le rôle d’un client d'iGuess (c’est-à-dire se connecter à lui et récupérer le shapefile SIG requis), et aussi comme un client de Brightway2 (c’est-à-dire se connecter à lui et récupérer le fichier de résultats ACV). SIGAGIS joue également le rôle de serveur pour l'utilisateur final, en lui permettant de fixer un certain nombre de paramètres relatifs aux différents éléments à envoyer à Brigthway2. Avec ces éléments à l'esprit, nous avons choisi d'utiliser un framework python pour construire l’application web SIGAGIS, qui communiquerait avec d'autres applications utilisant le protocole HTTP. Sur les différents frameworks Python existants, nous avons choisi Django.

Framework de programmation utilisé

Django est un framework qui permet de créer des applications web. Dans la plupart des applications web (et non web) usuelles, il est habituel de faire une différence entre le «frontend» et le «backend». Le premier est ce que l'utilisateur voit, généralement une «interface utilisateur graphique», et le dernier est l'infrastructure et les bibliothèques mises en place pour faire le travail que l'application est censée faire. La plupart des applications web fournissent leurs services en permettant aux utilisateurs de se connecter à l'application. La fenêtre de connexion, par exemple, appartient à l'interface, et le serveur de base de données et la base de données avec les noms d'utilisateur et les mots de passe font partie du backend. Ce qui le rend particulièrement intéressant pour ce cas d’étude est qu’il peut fonctionner dans le back end avec une base de données PostgreSQL qui peut intégrer l’extension pour les données SIG, appelée PostGIS. Dans le cas précis de notre développement cette extension permet de rappeler, stocker et analyser les shapefiles générés par iGuess.

Django comme beaucoup d'autres frameworks logiciels est extensible. Cela signifie que de nouveaux paquets peuvent être ajoutés pour fournir de nouvelles fonctionnalités au cadre initial. Une application Django de base aura des "looks" par défaut (polices, couleurs, formatage visuel en général) et ne comprend pas de support pour les bases de données SIG. Puisque nous avons besoin d'accéder au shapefile (une ressource SIG) au sein de SIGAGIS, nous ajouterons un paquet GIS à l'application Django initiale.

Démonstration du développement du prototype par un cas d’application concret.

Le prototype SIGAGIS développé dans le cadre du PRC ECOSD 14.1 est un prototype ad-hoc au projet DAEDALUS, permettant de créer une interaction entre les résultats de modélisation GIS issus de iGuess pour le calcul du potentiel de production d’électricité par PV d’un quartier de la ville de Rotterdam, et les calculs ACV relatifs.

De ce fait :

- Chacun des shapefiles pouvant être utilisés correspond aux résultats spatialisés du potentiel de production d’électricité par PV (potentiel calculé en kWh par type de toit, en fonction de l’inclinaison des toits et du rayonnement solaire associé en fonction du temps, disponible à partir des données GIS cartographiées pour les bâtiments ou groupes de bâtiment de la ville ou du quartier considéré)

- L’ensemble de paramètres (iii) correspond à la répartition moyenne (en %) des technologies PV potentiellement installées selon le type de toit.

36

Django – Modèle

Dans notre cas d’application, les données utilisées dans l’application proviennent du fichier « shapefile » original issu d’iGuess, décrivant le quartier de Bospolder à Rotterdam. Nous devons d'abord laisser l'application Django savoir comment manipuler les données, puis ajouter les données contenues dans le shapefile dans le serveur postgresql. Ce sont des tâches standards réalisées au sein d'une application Django et peuvent être effectuées à la suite de la documentation officielle (Django Software Foundation, 2005).

La description technique des codes pythons développés dans le framework Django pour définir l’ensemble des éléments nécessaires à la création du plug-in SIGAGIS (les chemins de navigation, la vue et la transmission des données, les templates et les formulaires) est détaillée dans l’Annexe 3.

Brightway2 – inventaire du cycle de vie et calcul ACV

Après avoir installé brightway2 en suivant la documentation officielle (Mutel, 2016), il faut créer l'inventaire relatif à l’objet de l’étude (l’unité fonctionnelle) et définir ses paramètres. Dans notre cas, la création de l'inventaire nécessite l'installation de la base de données ecoinvent2.2, puis la création d'une nouvelle base de données spécifique pour le projet. L'installation de ecoinvent2.2 et la création d'une nouvelle base de données peut être effectuée en suivant la documentation officielle. Créer une base de données pour contenir l'inventaire relatif à l’unité fonctionnelle du cas d'étude actuel nécessiterait un script python tel que décrit ci-dessous.

Le script python relatif à la création d’une base de données spécifique à un projet dans Brightway2 est décrit dans l’Annexe 3.

L’interface utilisateur « SIGAGIS »

L’interface de la plateforme est composé de deux grandes sections : une première pour sélectionner la base de données spécifique au projet dans le logiciel ACV Brightway2 et une deuxième pour configurer les paramètres à envoyer au logiciel ACV. La Figure 20 montre un aperçu global de l’interface de SIGAGIS.

36

Figure 20 Aperçu global de l'application

L’interface utilisateur permet donc de

(i) Sélectionner une base de données Brightway2 contenant les données d’inventaires d’arrière-plan qui devront être considérées pour le calcul ACV du projet sélectionné. Cette base de données doit donc être préétablie par le praticien ACV.

(ii) Spécifier l’unité fonctionnelle qui sera considérée pour le calcul ACV

(iii) Fixer (quantitativement) un ensemble de paramètres caractérisant l’inventaire de premier plan.

(iv) Sélectionner la méthode d’évaluation des impacts environnementaux à considérer pour le calcul ACV.

Une fois ces paramètres spécifiés, le calcul est lancé et les résultats sont visibles dans un tableau récapitulatif tel que montré dans la Figure 23.

Dans le cadre du présent cas d’étude, les résultats spatialisés du potentiel de production d’électricité par PV sont différenciés pour deux types de surface de toit : toit plat et toit incliné. Le potentiel de production est calculé en kWh par an pour l’ensemble de la surface disponible pour chacun des deux types de toit. Ce calcul réalisé par iGUESS est fonction de l’inclinaison des toits et du rayonnement solaire associé en fonction du temps, disponible à partir des données GIS cartographiées pour les bâtiments ou groupes de bâtiment de la ville ou du quartier considéré. Dans ce cas, la plateforme développée étant ad-hoc pour l’évaluation de la production d’électricité par panneaux PV, l’unité fonctionnelle spécifiée est « 1 », correspondant par défaut à la production d’électricité par panneaux PV pour le quartier considéré (pour ce cas d’étude les résultats sont relatifs à un quartier de Rotterdam).

36

Figure 21: Unité fonctionnelle – potentiel de production d’électricité spatialisé

L’ensemble de paramètres à indiquer par l’utilisateur correspond au mix des technologies de panneaux PV utilisées pour la production d’électricité, pour chaque type de toit (Figure 22). Cela correspond donc à l’inventaire de premier plan.

Figure 22 : ensemble de paramètres à indiquer par l’utilisateur correspondant au mix des technologies de panneaux PV utilisées pour la production d’électricité

Ces paramètres sont ensuite envoyés vers Brightway et associés aux inventaires d’arrière-plan contenus dans la base de données prédéfinie et sélectionnée via l’interface de QGIS ; pour procéder au calcul des résultats ACV.

Les résultats ACV sont restitués tels qu’illustré par la Figure 23.

167,926 kWh/an Flat 50 kWh/an Slanted

PV area Solar irradiation

1624 m2 Flat 1411,15 kWh/a/PV area

500 m2 slanted 350 kWh/a/PV area

Potentiel de production électricité pour le quartier bospold pour une année

Flat Roof - PV technology mix Slanted Roof - PV technology mix

50% % single-Si, laminated, integrated 30% % single-Si, laminated, integrated 50% % multi-Si, laminated, integrated 30% % single-Si, panel, mounted

3% % multi-Si, laminated, integrated 2% % multi-Si, panel, mounted 5% % ribbon-Si, panel, mounted 5% % ribbon-Si, laminated, integrated 5% % CdTe, laminated, integrated 5% % CIS, panel, mounted 5% % a-Si, laminated, integrated 5% % a-Si, panel, mounted

36

Figure 23 Tableau récapitulatif des résultats ACV tels que présentés par SIGAGIS

Conclusion

Le prototype de plateforme développé « SIGAGIS » a permis de démontrer la faisabilité d’une combinaison entre l’ACV et le SIG. Il a démontré la faisabilité de la communication entre des données issues de fichiers SIG type shapefile, et un logiciel ACV, sous la forme d’un couplage faible (une quantité limitée d’information est échangée, et seulement du SIG vers l’ACV). La plateforme joue le rôle d’intermédiaire entre les deux de manière d’exploiter les outputs du calcul SIG comme des inputs pour définir un inventaire régionalisé, considéré pour le calcul ACV. Elle permet également de consulter et visualiser les résultats.

Comme précisé plus tôt dans le rapport, le prototype est ad-hoc à l’évaluation de la production d’électricité par panneaux photovoltaïques, néanmoins les fonctionnalités développées en prenant appui sur le cas d’étude démontrent que SIGAGIS pourrait être le point de départ pour le développement d’une plateforme plus générique pour le couplage de l’ACV et du SIG.

Certaines améliorations pourraient également lui être apportées en termes de fonctionnalités, par exemple pour une visualisation cartographiée des résultats, une connexion directe avec iGuess permettrait une communication bidirectionnelle entre SIG et ACV (couplage fort - les outils interagissent en échangeant une grande quantité d’informations).

Une limite peut néanmoins être identifiée, liée aux besoins de compétences en programmation dans le langage Python pour pouvoir définir l’inventaire d’arrière-plan dans Brightway2.

36

Conclusion et Recommandations

Le PRC ECOSD 14.1 a permis de démontrer la pertinence et l’intérêt pour une combinaison de l’ACV avec d’autres disciplines, en particulier l’intégration de paramètres spatio-temporels dans les inventaires et pour la caractérisation des impacts.

La possibilité d’implémenter des connexions entre les logiciels d’ACV les plus utilisés (Simapro, Gabi, Umberto & OpenLCA) et des logiciels ou bases de données externes est bien souvent limitée. Des adaptations informatiques souvent conséquentes sont généralement nécessaires pour créer des interfaces et développer des outils intégrés. Les logiciels généraux tels que R ou Excel sont de ce fait souvent utilisés. Brightway, basé sur le langage informatique Python, peut constituer une alternative intéressante. Cependant, il est beaucoup moins convivial que les logiciels ACV usuels.

Le premier cas d’étude a permis de démontrer la pertinence de considérer une caractérisation spatialisée de l’impact eutrophisation et sur la faisabilité méthodologique d’un tel développement. La considération de la sensibilité du territoire à ces impacts permet une évaluation plus fine et plus facilement exploitable en termes d’aide à la décision.

Le cas d’étude basé sur l’évaluation spatialisée de l’utilisation des terres à partir de données d’inventaire également régionalisées a permis de démontrer l’existence de solutions techniques pour partiellement automatiser la liaison entre évaluation environnementale et une autre discipline, le SIG dans ce cas, via un plug-in permettant ainsi de limiter le besoin de compétences spécifiques en programmation informatique (R ou python) pour le praticien ACV. La valeur ajoutée se situe également au niveau de la visualisation des résultats cartographiés.

Le prototype de plateforme développé « SIGAGIS » a permis de démontrer la faisabilité d’une combinaison entre l’ACV et le SIG. Il a démontré la faisabilité de la communication entre des données issues de fichiers SIG type shapefile, et un logiciel ACV, sous la forme d’un couplage faible. L’ensemble des livrables du projet ont démontré que les travaux existants sont très récents quelle que soit la combinaison envisagée, certaines de ces intégrations sont encore en phase expérimentale, ce qui signifie qu'il existe différentes approches possibles, chacune comportant des limites, et il n'existe pas de consensus clair sur quelle approche choisir. Néanmoins la valeur ajoutée et la faisabilité technique du couplage via une plateforme d’échange ont également été démontrées, et l’intérêt de la communauté ACV a été ressenti aussi bien au travers de l’enquête auprès des membres ECOSD, qu’à travers l’état de l’art réalisé.

L’ensemble des livrables ont néanmoins démontré également la complexité de tels développements, nécessitant d’importants moyens en termes de compétences, de coût et de temps, pouvant constituer un frein à l’implémentation et à la pratique de plateformes de couplage. Une tendance pour pallier ce manque de moyen est la simplification des modèles, facilitant ainsi la transposition des résultats d’une discipline vers l’autre. Cela constitue néanmoins un risque pour la pertinence de la combinaison, au même titre que le développement d’une plateforme dont la pratique ou la prise en main resterait trop complexe, nécessitant des compétences trop spécifiques.

Afin de limiter les risques et assurer la pertinence d’une plateforme d’évaluation environnementale, il serait préférable de réaliser les développements à travers une collaboration entre organismes de recherche et industries. Le prototype SIGAGIS pourrait être le point de départ pour le développement d’une plateforme plus générique pour le couplage de l’ACV et du SIG. Une limite peut néanmoins être identifiée, liée aux besoins de compétences en programmation dans le langage Python pour pouvoir définir l’inventaire d’arrière-plan dans Brightway2.

36

References

Beck, T. et al., 2010. LANCA Land Use Indicator Value Calculation in Life Cycle Assessment. Fraunhofer IBP, Stuttgart.

Benetto, Enrico, Christiane Dujet, and Patrick Rousseaux. 2008. “Integrating Fuzzy Multicriteria Analysis and Uncertainty Evaluation in Life Cycle Assessment.” Environmental Modelling & Software 23 (12): 1461–67. doi:10.1016/j.envsoft.2008.04.008.

Caspers, H. 1984. OECD: Eutrophication of Waters. Monitoring, Assessment and Control. 154 pp. Paris: Organisation for Economic Co-Operation and Development 1982. (Publié en français sous le titre « Eutrophication des Eaux. Méthodes de Surveillance, d'Evaluation et de Lutte »). Int. Revue ges. Hydrobiol. Hydrogr., 69: 200. doi: 10.1002/iroh.19840690206

Csiszar, Susan A., David E. Meyer, Kathie L. Dionisio, Peter Egeghy, Kristin K. Isaacs, Paul S. Price, Kelly A. Scanlon, et al. 2016. “Conceptual Framework To Extend Life Cycle Assessment Using Near- Field Human Exposure Modeling and High-Throughput Tools for Chemicals.” Environmental Science & Technology, September. doi:10.1021/acs.est.6b02277.

Davis, Chris, Igor Nikolić, and Gerard P. J. Dijkema. 2009. “Integration of Life Cycle Assessment Into

Documents relatifs