Chapitre 3. Optimiser les stratégies de déconstruction
5.3 Sélection de l’algorithme génétique
Évaluation d’un ensemble d’algorithmes. Les algorithmes génétiques recoupent un
ensemble d’algorithmes ayant tous recours aux notions de combinaison, de mutation, de
sélection et de dominance au sens de Pareto, mais apportant chacun des spécificités. Par exemple, NSGA-II (Deb et al. 2000) ne conserve que les solutions dominantes pour produire une nouvelle population, DBEA (Asafuddoula et al. 2013) sélectionne les solutions à comparer selon deux méthodes (le voisinage ou le hasard) et SPEA 2 (Zitzler et al. 2001) évalue une solution en fonction de sa distance avec le reste des solutions.
Ces spécificités de chaque algorithme induit des différences quant à leur performance. Cependant, le « No free lunch theorem » (Wolpert et Macready 1997) affirme qu’aucun
algorithme n’est meilleur que tous les autres sur l’ensemble des problèmes d’optimisation multi -objectif. Pour déterminer lequel est le plus efficace pour notre problème de déconstruction, nous avons testé huit algorithmes sur une version simplifiée du modèle de déconstruction.
Cette étude a fait l’objet d’un article publié en 2019 dans le journal international Automation in Construction (Quéheille et al. 2019). L’article est mis à disposition dans l’Annexe 4. Nous reportons ici uniquement les résultats (Tableau 3.8).
Tableau 3.8 : Comparaison de la performance des algorithmes de recherche pour un cas de déconstruction (Quéheille et al. 2019)
Algorithme Nombre de solutions optimales* Variété des solutions** Temps de calcul (mn) Pourcentage de solutions optimales avec au moins un taux de valorisation matière
de 70 % NSGA-II (Deb et al. 2000) 21 0,55 10 76 % OMOPSO (Sierra et Coello Coello 2005) 14 0,58 11 57 % CMA-ES(Igel et al. 2007) 6 0,08 12 100 % PAES (Knowles et Corne 1999) 10 0,33 11 100 % SPEA2 (Zitzler et al. 2001) 23 0,27 12 100 % DBEA (Asafuddoula et al. 2013) 25 0,53 12 84 % MOEA/D (Li et Zhang 2007) 1 - 12 0% VEGA (El-Ghazali 2009) 0 - 11 -
* Ne sont considérées que les solutions qui sont optimales dans l’ensemble des solutions
trouvées par tous les algorithmes
** La variété des solutions correspond à la somme des écarts-types sur les valeurs des variables de décision.
Le temps de calcul ne s’est pas avéré un facteur prépondérant dans l’évaluation des
algorithmes, chacun ayant tourné sur une durée équivalente. NSGA-II, SPEA2 et DBEA ont présenté les meilleures performances, avec un équilibre intéressant entre le nombre de
solutions optimales trouvées et l’efficacité sur l’objectif du taux de valorisation matière. NSGA -II et DBEA se démarquent par une variété plus importante de solutions. Nous avons sollicité
l’avis du chargé d’études pour les départager. Le chargé d’études a préféré les solutions de DBEA car ce dernier offrait de la variété sur les variables de décision autant pour la gestion des
déchets (e.g. traitement des déchets) que pour la déconstruction (e.g. nombre d’ouvriers pour
le curage). Nous avons conclu que DBEA (Decomposition-Based Evolutionary Algorithm) (Asafuddoula et al. 2013) était le plus approprié pour résoudre notre problème d’optimisation de la déconstruction. Il est à noter que la plupart des algorithmes d’optimisation, et
notamment DBEA, fonctionnent de façon optimale avec un nombre d’objectifs égal ou
inférieur à 3 (Coello Coello 2017). Cependant, entre 5 et 10 objectifs, les algorithmes génétiques restent assez performants (Asafuddoula et al. 2013). Nous pouvons donc conserver
cet algorithme pour l’optimisation de notre problème de déconstruction complet intégrant les 6 objectifs (coût, délai, taux de stockage et les objectifs ACV).
DBEA.L’algorithme DBEA démarre la recherche en générant des points de référence, ces derniers traçant un hyperplan dans l’espace de recherche (Asafuddoula et al. 2013). Dans la Figure 3.5, l’hyperplan est en trois dimensions, avec une intersection avec chacune des trois fonctions-objectifs f définies. Le point nommé « Point idéal » (Ideal Point) correspond à la
solution dominante idéalisée (N.B. cette solution n’existe généralement pas) : il se situe à
l’origine de l’intersection des trois fonctions-objectifs.
Figure 3.5 : Ensemble de points de référence sur un hyperplan pour 3 fonctions-objectif (Asafuddoula et al. 2013)
Ensuite, la population initiale de solutions est générée aléatoirement.
L’évaluation dessolutions s’effectue à partir de deux distances définies par rapport à une direction tracée entre l’origine et un point de référence (Figure 3.6) :
- La distance d1entre l’origine (i.e. là où se situe le point idéal) et la position du
point projeté sur la direction de référence
- La distance d2 qui est égale à la longueur de la normale du point par rapport à la direction de référence.
Ces deux distances sont calculées avec chaque point de référence (i.e. chaque paire d1-d2 est associée à une direction particulière).
Figure 3.6 : Évaluation de deux solutions selon une direction portée par un point de référence (Asafuddoula et al. 2013)
Des paires de solutions sont construites, soit par hasard, soit par le voisinage. Ces paires de solutions, par recombinaison (i.e. opérateurs de croisement et de mutation appliqués
simultanément), créent des solutions enfants. Les enfants remplacent leurs parents s’ils dominent ces derniers. L’enfant domine le parent si sa distance d2 est la plus faible. Si la distance d2 est équivalente pour les deux solutions, la solution sélectionnée est celle disposant
de la distance d1 la plus faible. Les points de référence sont mis à jour et l’algorithme peut
démarrer une seconde itération en sélectionnant de nouvelles paires de solutions parents. La Figure 3.7 expose l’algorithme de DBEA sous la forme de pseudocode.
Figure 3.7 : Pseudocode de l'algorithme DBEA (Asafuddoula et al. 2013)
Configuration.La recherche des solutions dans l’espace d’étude est conditionnée par
deux facteurs :
- Le nombre d’itérations, correspondant au nombre de fois que l’algorithme initie sa recherche. En raison du caractère stochastique de l’algorithme, il est
suffisante de l’espace. À chaque itération, la population initiale est redéfinie
modifiant la recherche de solutions. Ainsi, les résultats (i.e. les solutions
dominantes) diffèrent selon l’itération.
- Le nombre d’évaluations, correspondant au nombre de solutions évaluées lors d’une itération. A priori, plus celui-ci est grand, plus les solutions dominantes
trouvées sont pertinentes et nombreuses. Toutefois, il arrive que l’algorithme
stagne en tombant dans des minimums locaux.
Évidemment, plus ces deux facteurs sont grands, plus le temps de calcul s’allonge. Il y
a ainsi un compromis à trouver entre nombre de solutions optimales et temps de calcul.
6 Conclusion et implémentation du modèle de déconstruction
Le modèle décrit dans ce chapitre vise l’étude d’un chantier de déconstruction de tout type. Les travaux sont estimés dans leur globalité, de l’installation jusqu’à la remise du terrain au client. Sont inclues les phases d’installation, de curage, de désolidarisation, de démolition, de sous-traitance et de gestion des déchets. Cette dernière phase est déclinée en deux étapes : le traitement et le transport. Jusqu’à 41 natures de déchets différentes sont
considérées dans le modèle. La gestion de l’amiante n’est cependant pas incluse. Le
désamiantage correspond à un travail très différent de la déconstruction : les techniques sont plus diverses, la sélection du matériel est plus complexe et la gestion de la sécurité occupe une place prépondérante. Le métier de désamiantage est à modéliser de manière totalement indépendante de la déconstruction.
L’optimisation de la déconstruction considère la quasi-totalité de ces phases.
L’optimisation touche ainsi aux ressources humaines et matérielles (autant les engins de chantier que les bennes de transport des déchets), aux méthodes de travaux et au plan de
gestion des déchets. L’ensemble des variables de décision se compose de variables
quantitatives discrètes (e.g. variable CuOconsidérant le nombre d’ouvriers pour la phase de curage) et de variables qualitatives (e.g. choix du traitement pour le béton). Des variables contextuelles permettent de formaliser les spécificités de chaque cas étudié. Par hypothèse, il a été considéré que la désolidarisation et la sous-traitance ne sont pas influencées par les
variables de décision et ne disposent pas d’alternatives envisageables.
La performance d’une stratégie de déconstruction s’évalue selon 4 domaines : le coût du chantier, la durée du chantier, le taux de valorisation matière et l’impact environnemental. Ce dernier domaine est décliné en deux séries d’objectifs selon la version du modèle
(recherche ou opérationnelle) : un bilan GES pour la version opérationnelle et une ACV pour
la version recherche. L’influence des variables de décision sur ces fonctions-objectifs est résumée dans la Figure 3.8. En plus des variables contextuelles, le modèle exploite une base de données recensant les variables de connaissance (e.g. coût journalier des ressources humaines et matérielles) pour effectuer les calculs.
Figure 3.8 : Influence des variables de décision sur les fonctions-objectifs du modèle de déconstruction
L’implémentation du modèle a été réalisé en JAVA via la plateforme Eclipse IDE for
Java Developers, version 4.11 (Eclipse Foundation 2019). Le modèle utilise plusieurs modules pour effectuer les différents calculs et opérations. La Figure 3.9 illustre l’ensemble du modèle dans sa version recherche (i.e. avec l’ACV comme fonction-objectif).
Figure 3.9 : Résumé conceptuel du modèle d’optimisation de déconstruction de bâtiments
Le programme développé permet, en partant des différentes données (stockées dans
des fichiers CSV) relatives aux variables, de mener à bien l’optimisation. La contextualisation des variables de décision s’effectue à partir du contexte du chantier (i.e. quantitatif des
déchets, possibilité d’utiliser deux pelles pour la phase de démolition, possibilité d’effectuer
une démolition traditionnelle) et du nombre de centres de traitement Ix disponibles autour du chantier. Le calcul des fonctions-objectifs nécessite aussi l’utilisation de données. La durée du
chantier a besoin par exemple du nombre de jours alloués donné par l’estimation préalable du chargé d’études.
Le programme utilise différentes bibliothèques et ressources externes. Nous avons utilisé la librairie open source MOEA Framework (Hadka 2017), qui contient l’algorithme DBEA pour réaliser l’optimisation. Le modèle à optimiser (i.e. celui présenté dans ce chapitre) a été implémenté directement en JAVA. Cependant, pour réaliser les calculs liés à l’ACV, nous utilisons le logiciel OpenLCA. OpenLCA étant nativement en Python, nous configurons une API
dédiée d’OpenLCA, permettant la connexion avec Eclipse (GreenDelta 2019b). La traduction
de JAVA en Python s’effectue via Jython, qui est une implémentation de Python sous JAVA
(Python Software Foundation 2019). L’échange des données entre OpenLCA et le
programme-maître se fait par des fichiers CSV (comme tous les transferts de données dans le modèle).
Dans le cas de la version opérationnelle du modèle, la branche du système dédiée à
l’ACV est remplacée par le calcul des émissions GES. Les formules exposées dans le chapitre 2
ont directement codées dans le modèle en JAVA afin de gagner du temps de calcul en limitant les appels à des applications externes.
Dans le Chapitre 4, nous présentons des applications de ce modèle à des chantiers réels de déconstruction et nous discutons des résultats trouvés.