Dans cette partie nous réalisons une critique du travail effectué. Dans un premier temps nous discutons de chaque partie prise séparément puis, nous traiterons l’ensemble de la méthodologie abordée dans cette thèse.
8.2.1
Discussion sur la partie modélisation
Parmi les indicateurs choisis, plusieurs éléments sont discutables. Dans la partie économique le choix de certains paramètres ou certaines fonctions de calcul peut impacter cet indicateur et par conséquent modifier la prise de position. La partie environnementale contient le plus d’interrogations. Ainsi, le choix pour évaluer cet impact s’est porté sur l’EcoCost qui présente l’avantage de réduire l’ensemble des valeurs d’émissions à une même unité. Plusieurs critiques peuvent être néanmoins réalisées. Premièrement, cet indicateur n’est pas destiné par essence à être utilisé pour réaliser des évaluations et analyses environnementales, mais bien plutôt comme élément de sélection pour les décideurs. Le fait de tout regrouper à une seule valeur simplifie l’analyse et la comparaison, mais cette agrégation implique une perte d’information intéressante comme le type d’émissions, sa quantité etc. Certaines définitions de cette base renvoient à d’autre bases telle qu’Impact 2000, qu’il serait nécessaire de posséder. Enfin, la partie sociale est, dans cette thèse, limitée au nombre d’emplois créés. Outre la difficulté d’estimation de ces indicateurs, la principale question que l’on peut se poser ici est son intérêt. En effet du point de vue économique le nombre de travailleurs directs se traduit par une ligne de coût représentant la masse salariale, ce qui par conséquent, détériore les indicateurs économiques. Il est possible de débattre sur l’importance de la création d’emplois dans la société. Néanmoins, nous ne pouvons que constater que cette considération provient d’un parti pris sur la question.
8.2.2
Discussion sur la partie génération de trajectoire
En ce qui concerne le RàPC, la mise en place de structure de description non définie offre une très grande liberté. Cette liberté peut se traduire par des difficultés lors du traitement de l’information. Ainsi, un des principaux points discutables reste la sélection aléatoire possible du cas source et par conséquent le fait que le système devienne non déterministe. Ainsi, lors de la phase d’estimation du résultat de transformation, une étape d’appariement est nécessaire et peut, dans certain cas, générer des résultats surprenants par un appariement qui ne convient pas à la transformation. De plus, la méthode proposée pour le stockage et l’indexation puis la sélection des cas sources pose des problèmes majeurs. Ainsi, pour une configuration de trois couches à 100%, pour 45 états introduits dans la base, environ 5000 définitions communes ont été générées. Or, ceci provoque une augmentation exponentielle du temps d’apprentissage lors de l’introduction dans la base de nouveaux cas
8.2. DISCUSSION
et une forte augmentation du nombre de données dans le système, ralentissant ou bloquant ce dernier. Enfin, ce système repose pour beaucoup sur l’utilisation de mécanismes d’inférences et sur la définition de taxonomies. La première remarque est qu’une taxonomie sur des concepts représente déjà une forme de connaissance sujette à interprétation. Or, lors de la recherche de similarité, nous mettons en avant le fait que notre système n’a pas besoin de connaissances sur les distances entre cas pour fonctionner, mais s’appuie sur des déductions logiques dont certaines sont basées sur les taxonomies. Par conséquent, bien que notre argument soit valable, il est néanmoins nécessaire de moduler son ampleur.
8.2.3
Discussion sur la partie modélisation et évaluation
L’outil de modélisation à quant à lui certaines limites. Ainsi, nous pouvons remarquer qu’un des points limitants de cet outil est le nombre de contraintes que l’on peut modéliser dans les entités. En effet, deux éléments sont à prendre en compte. Le premier est la limitation du parser qui a été implémenté et qui permet de traduire les contraintes au niveau entité en contraintes systèmes et permettre par la suite leur compréhension par le solveur choisi4. Le deuxième élément est le solveur lui-même qui autorise un nombre limité de contraintes. Enfin, la dernière question que l’on peut se poser est l’utilité ici de la base de données orientée objets Zodb. En effet, bien que la possibilité de décrire un type d’opération (génération de classe par la méta-classe) et de pouvoir s’en servir dans notre modèle n’est pas discutable, il est toutefois possible de conserver ces éléments de deux manières. La première est comme nous l’avons fait, la seconde serait l’intégration au système de ces classes d’entités avec un modèle de greffons où des fichiers Python seraient déposés. Cette dernière méthode a l’avantage de ne pas nécessiter d’autre outil que Python mais demande de passer par une phase de programmation. La méthode choisie permet de s’affranchir de cette phase de programmation dans le cas où une interface graphique5 serait développée.
8.2.4
Discussion sur l’ensemble des trois parties
Ici, nous allons analyser l’ensemble des travaux réalisés dans la thèse, les considérer comme un tout et voir les limites ou remarques qui pourraient être identifiées. L’ensemble de la thèse, qui rappelons le a pour but de tenter de proposer de nouvelles voies de valorisation des déchets, s’articule autour de trois principaux axes. Le premier est la modélisation et l’évaluation théorique de trajectoires. Cette partie vise à fournir un cadre permettant de décrire ces dernières sous un ensemble de structures communes permettant d’obtenir des descriptions homogènes. Le second axe est le développement d’un outil et donc d’un modèle dont le but est de pouvoir générer de nouvelles trajectoires. Enfin, le troisième est la modélisation à proprement dite et l’évaluation des trajectoires. Par conséquent, l’ensemble de la thèse forme, aux premiers abords, un ensemble cohérent qui suit une certaine logique :
Étape Permet Fournit À qui ?
Cadre de modélisation et choix des critères
De décrire des trajectoires de manière uniforme
Des cas unifiés De fournir les indicateurs
et la manière de les calcu- ler
Des indicateurs RàPC
RàPC La génération de nouvelles trajectoires pour les dé- chets
Des listes successives d’opérations (transforma- tions) Outil de modélisation et d’évaluation Outil de modélisation et d’évaluation
La modélisation d’une tra- jectoire
Les valeurs des flux et des indicateurs
Utilisateur
Tableau 8.1– Relations entre les différents éléments de cette thèse
Plusieurs remarques peuvent être faites quant à l’homogénéité de l’ensemble et plus précisément sur la continuité. Le principal point est le « fossé » qu’il y a entre la réponse fournie par le générateur de trajectoire et les besoins de l’outil de modélisation. En effet, le premier ne fournit qu’une liste d’étapes, alors que le second à besoin d’équipements concrets et de nombreuses données telles que :
— La liste des équipements dimensionnés
4. Un peu comme le ferai un langage de modélisation algébrique comme GNU mathproghttp://lpsolve.sourceforge.net/5. 5/MathProg.htm
— Les investissements
— La position géographique des unités
— Le prix d’achat des matières premières et le prix de vente — ...
Ce que ne fournit pas le générateur. Néanmoins, il est possible d’implémenter dans le système des bases de cas où un état décrirait le produit d’entrée, une relation représenterait l’opération de transformation fournie par le générateur et l’état d’arrivée décrirait l’équipement correspondant, ce qui permettrait de fournir une liste des principaux équipements nécessaires à la réalisation de la trajectoire. Malheureusement, les autres données, tels que le dimensionnement, le calcul d’investissement etc, doivent être spécifiées par l’utilisateur. Ce point montre qu’il manque une étape dans le processus de génération de nouvelles trajectoires. Cependant, dans la partie Perspectives8.3.3, nous proposons une approche qui pourrait combler, du moins partiellement, l’écart sur les données.