2. Quels sont les besoins d’échanges asynchrones en ACV ? ... 122 3. Intérêt du formalisme Issue-Based Information System (IBIS) ... 123 B. La K2alligraphie un formalisme pour la création de notices explicatives d’ACV ... 125 1. Objectifs et principes de la K2alligraphie ... 125 2. Construction d’une notice par la K2alligraphie ... 126 3. Une forte intégration possible aux démarches d’écoconception ... 126 C. La K2alligraphie en pratique d’après des données d’Aubrilam... 128 1. L’ACV d’un produit d’Aubrilam ... 128 2. Construction de la notice de l’ACV du banc d’extérieur d’Aubrilam ... 128 3. Détails de la notice explicative de l’ACV du banc d’extérieur d’Aubrilam ... 129
II. Mise à l’épreuve du formalisme K2alligraphie lors d’une étude empirique en milieu académique ... 131
A. Description de l’étude empirique ... 131 1. Objectifs de l’étude empirique... 131 2. Description de l’étude empirique ... 131 3. Déroulé et documents disponibles ... 132 4. Observations réalisées ... 132 B. Résultats de la séance observée ... 134 1. Traitement des données ... 134 2. Résultats de l’activité dans sa globalité ... 134 3. Résultats locaux : utilisation des documents ... 135 C. Analyse et limites ... 137 1. Quelques limites ... 137 2. Un déroulement positif de l’activité ... 137 3. Une notice explicative utile ... 137
III. Conclusions ... 138
A. Un formalisme utile ... 138 B. Des perspectives de développement en milieu industriel ... 138
122
Etant donné l’importance des objets intermédiaires dans l’organisation des interactions sociales, nous avons montrés qu’ils jouaient aussi un rôle dans la construction de connaissances. Nous allons ici traiter de la création d’un objet intermédiaire dédié au cas particulier des interfaces entre les différents acteurs impliqués lors d’Analyses de Cycle de Vie.
I. La K
2alligraphie pour formaliser et partager les raisonnements lors d’une
Analyse de Cycle de Vie
A. Formaliser les raisonnements en ACV
1. Un besoin de construction de connaissances par échanges asynchrones
Nous avons précédemment établi que la construction de connaissances pouvait améliorer les démarches d’écoconception. L’étude bibliographique du chapitre 2 a mis en évidence un manque de connaissances, notamment d’un niveau local, dans le domaine de l’écoconception. Ce manque n’étant pas traité par les initiatives existantes, il apparaissait alors naturel de réfléchir aux leviers permettant de le combler. Le rôle potentiel des interactions sociales dans cette construction de connaissances avait alors été mis en avant. Le concept d’objet intermédiaire96 avait aussi été évoqué comme élément central de ces échanges. Nous nous interrogions, par ailleurs, sur l’hypothèse que l’absence d’objets intermédiaires, à l’interface des différents acteurs de l’écoconception, pouvait expliquer en partie le manque de connaissances dont souffrent ces démarches. Le chapitre 4 a proposé la méthode K2stor comme moyen pour diagnostiquer les problèmes liés aux connaissances dans les démarches d’écoconception. Nous l’avons mis à l’épreuve d’un cas industriel, ce qui a permis d’identifier deux catégories d’interactions sociales à créer. La première, qualifiée de synchrone, peut être créée par l’approche K2afé longuement présentée en chapitre 5.
Il s’agit à présent de réfléchir aux moyens permettant de créer des situations d’échanges asynchrones. Nous avons identifié que l’Analyse de Cycle de Vie (ACV) est une activité déterminante dans les démarches d’écoconception. C’est pourquoi nous allons nous intéresser aux besoins particuliers de celle-ci dans la partie suivante.
2. Quels sont les besoins d’échanges asynchrones en ACV ?
La conduite des Analyses de Cycle de vie nécessite des échanges entre de nombreux acteurs. Il peut s’agir d’échanges synchrones, par exemple entre la personne en charge de l’ACV et une autre possédant des données nécessaires à sa réalisation. Ces échanges peuvent aussi être espacés dans le temps. Nous pouvons évoquer le cas d’une personne qui souhaite comprendre les résultats d’une ACV qu’elle n’a pas réalisée, ou celui d’une personne qui cherche à modifier une ACV réalisée par une autre (Figure 49). Dans chacun des cas évoqués, il s’agit d’échanges asynchrones : ils vont permettre la construction de connaissances pour la compréhension ou la réalisation d’une ACV.
96 Le chapitre 2 insistait aussi sur la difficulté de développement pratique d’objets intermédiaires : il s’agit avant tout d’un concept propre « aux chercheurs ». Il n’existe donc pas de « recette » pour les construire, il est cependant possible de les identifier quand ils existent et sont utilisés.
123
Figure 49. Besoin d'échanges en ACV
La réalisation d’une ACV impose d’effectuer de nombreux choix : définition des limites de l’étude, négligence de certaines données, utilisation de bases de données génériques, etc. La liste pourrait être longue, mais tous ces choix ont en commun qu’ils résultent de l’expertise du praticien97 de l’ACV. Nous avons déjà vu au chapitre 2 que l’ACV, et l’écoconception de façon plus générale, s’appuient sur un savoir en cours de construction, à la fois mouvant et flou. Le raisonnement qui amène à effectuer des choix en ACV n’est donc pas facilement formalisable car hautement lié aux connaissances de ces experts. La situation est donc paradoxale car il est nécessaire d’échanger à propos de raisonnements qui sont difficilement partageables.
Force est de constater que les outils utilisés pour réaliser des ACV n’offrent que peu de fonctionnalités d’échange. Le fichier résultant d’une ACV contient principalement les données brutes utilisées. Il est par exemple possible de retrouver la masse, ou encore le type de bois modélisé, dans le logiciel d’ACV. Mais il n’est souvent pas possible de connaitre les questions qui se sont posées lors de ces choix, et surtout les raisons qui ont amené à les réaliser. Si certains logiciels permettent à l’analyste de préciser quelques-uns de ses choix par l’ajout de commentaires libres98, il s’agit uniquement des choix finaux, c’est-à-dire faisant abstraction des possibilités évoquées mais non retenues.
Or il existe un besoin de garder une trace des raisonnements amenant aux choix en ACV. Il est utile de connaitre quelles étaient les possibilités et pourquoi certains choix ont été effectués. Ceci faciliterait la compréhension des résultats d’une ACV et permettrait également de mettre à jour facilement une étude déjà réalisée, si des changements ont eu lieu sur le produit ou le contexte (normes, fournisseurs…).
Ce besoin de comprendre le pourquoi autant que le quoi avait déjà été mis en avant en conception et était responsable du développement du Design Rationale99. Dans ce cadre, des outils graphiques sont utilisés pour retracer les raisonnements mis en œuvre dans des démarches de conception. Un des plus simple est le langage IBIS (Issue-Based Information System) que nous allons détailler dans la partie suivante.
3. Intérêt du formalisme Issue-Based Information System (IBIS)
IBIS est un formalisme graphique pour représenter les questionnements amenant à une ou des solutions de conception [Kunz and Rittel 1970]. Il permet, entre autres, de capitaliser les raisons qui ont amené à des décisions de conception. Cassier le décrit dans sa thèse comme ayant
97 Ou du suivi de règles ou guidelines mais nécessairement construites selon une telle expertise.
98 Par exemple, le logiciel Bilan Produit de l’ADEME permet de rajouter des commentaires.
124
« vocation à tracer le processus argumentatif qui se déroule autour des choix de conception […] en proposant une modélisation du processus en arborescence » p66 [Cassier 2010]. Il est
centré sur les problèmes, c’est-à-dire les questions, comme par exemple : quel matériau choisir
pour réaliser un flacon ? Avec une arborescence, il permet ensuite d’organiser les solutions ou
idées à ce problème : verre, plastique etc… Ces solutions vont être étayées, ou critiquées, par des arguments positifs ou négatifs. Un exemple d’utilisation réalisé avec le logiciel designVUE100 est donné Figure 50.
Figure 50. Exemple d'utilisation du formalisme IBIS
Le formalisme IBIS a été décliné en plusieurs variantes, celle proposée par le logiciel designVUE permet de nuancer ou préciser davantage les raisonnements. Il est ainsi possible de donner un statut à chacun des éléments précédents. Par exemple, une solution peut être
acceptée, rejetée, probable ou peu probable. Avec ce formalisme nous disposons donc de 15
symboles différents (Tableau 34).
Elements IBIS Statuts
Problème Résolu Insoluble Rejeté
Solution Acceptée Rejetée Probable Peu probable
Argument pour Dominant Défaillant
Argument contre Dominant Défaillant
Tableau 34. Récapitulatif des éléments IBIS utilisés par le logiciel designVUE
IBIS offre de nombreuses fonctionnalités, sa forme graphique permettant de construire facilement des représentations aisément compréhensibles. L’exemple donné Figure 50 montre que pour répondre à la question initiale, deux alternatives ont été envisagées, et aucune n’a été retenue ni rejetée pour le moment. Ce formalisme oblige également à argumenter les choix et surtout les expliciter. Il est alors possible d’identifier si des arguments peuvent évoluer : une solution non retenue dans un premier temps pouvant le devenir par la suite.
125
Néanmoins, IBIS n’est pas exempt de tout reproche. Etant donné qu’il est dédié aux cas de conception, il doit formaliser des raisonnements faisant intervenir de nombreux acteurs. Il est déjà difficile d’envisager une construction individuelle en direct, l’acteur étant principalement focalisé sur ses tâches de conception, alors imaginer une construction collective l’est d’autant plus. Cependant, il est possible de construire cette formalisation de raisonnement a posteriori de l’activité de conception, par exemple, par l’intermédiaire d’une personne dédiée. En plus de l’épineux choix de cette personne, réussir à comprendre le raisonnement et toutes ses nuances (exemples : quelle est la question exacte qui était posée ? Est-ce que cet argument était vraiment
dominant ? …), peut s’avérer extrêmement chronophage voir inextricable. Enfin, la conception
d’un produit peut être fortement complexe et donc engendrer de très nombreux raisonnements. Leur formalisation, en plus d’être fastidieuse à construire, peut être longue à appréhender notamment pour une personne extérieure à ce cas de conception.
Nous venons de voir que la compréhension et la réalisation d’Analyse de Cycle de Vie imposent des besoins d’échanges asynchrones entre ses acteurs. Ce type d’échanges permet la construction de connaissances et donc l’amélioration des analyses. Nous avons réussi à préciser que ce besoin d’échange se traduit principalement par un besoin de retranscription des raisonnements amenant aux choix en ACV. L’étude du langage IBIS a permis de nous rendre compte de l’intérêt de ce formalisme mais aussi d’appréhender quelques-unes de ses limites. Ainsi, nous proposons de développer un formalisme graphique pour créer des notices explicatives en ACV. Ces notices doivent expliquer les choix effectués lors d’une ACV en retranscrivant les raisonnements qui les ont amenés. Le formalisme à développer doit pouvoir être mis en place facilement tout en s’intégrant pleinement au processus de conception.
B. La K2alligraphie un formalisme pour la création de notices explicatives d’ACV