2.3 Discussion générale
2.3.1 La situation à l’issue du projet Daft
En 2005, à l’issue des premiers développements de l’architecture Daft, les composants pris en charge par l’architecture sont : des composants intégrés dans des pages Web, des applications Java standalone ainsi que des sites Web entiers (Table 4).
Table 4 : domaine d’application et méthodologie de développement du projet Daft.
2.3.2 Ouverture
Les développements de l’architecture ont permis d’identifier un certain nombre de manques Ils concernent essentiellement deux axes de recherches : les problématiques liées à l’architecture logicielle et les problématiques liées au traitement de la langue. Pour les raisons déjà citées, nous ne développerons pas les problématiques liées à la Langue Naturelle. Nous préciserons simplement qu’elles ont donné lieu à une production scientifique dans le cadre de la thèse de François Bouchet sur le thème de la production d’heuristiques de raisonnements (Bouchet & Sansonnet 2009) pour la résolution de requêtes d’assistance ; ainsi que des études fondées sur les corpus (Xuetao
D’un point de vue de l’architecture logicielle, le projet Daft représente un réel progrès, de par sa réalisation. Néanmoins, d’un strict point de vue de la généricité logicielle des progrès sont encore possibles. En effet, le développement du modèle du composant est encore laissé à la charge du programmeur. L’écriture de ce modèle de composant devient alors un problème en soi :
- Le besoin d’écrire ce code est un problème : il faudrait synthétiser ce modèle automatiquement.
- Il se pose aussi la question de l’intégration de ce modèle dans le cycle de vie d’une application. Le projet InterViews se suffisait à lui-même : l’écriture du composant étant alors égale à l’écriture du modèle. Pour le projet Daft, on suppose l’application déjà existante, on suppose également qu’il est possible d’accéder à son code source. Or, ces deux suppositions représentent une simplification qui interdit le passage à l’échelle. Dans l’hypothèse où nous voulons réellement proposer une solution d’assistance, il faut écarter à tout prix les considérations d’écriture du modèle pour le programmeur. Il faut également établir les différents cas d’utilisation d’un tel modèle pour définir une stratégie générique de synthèse de
modèles.
- Il se pose enfin la question de l’intégration de connaissances sémantiques dans le modèle. Celui-ci se pose comme une base de connaissances pour formuler des réponses à l’utilisateur. Le modèle sert également de base de connaissances sur son état actuel et donc sert de support au raisonnement. Les informations exprimées dans le modèle sont donc cruciales. Par ailleurs, le modèle devient une
représentation de l’application : la question de l’exactitude de cette représentation
se pose donc (une représentation n’est jamais identique au système représenté, sinon ils seraient confondus et on se retrouverait dans la situation du projet InterViews).
Derrière la question de la représentation des connaissances dans le modèle du composant, se cache une question fondamentale de l’assistance : l’usager d’une application se construit une représentation erronée de l’application, ce qui le conduit à faire des erreurs et à se retrouver dans la situation de blocage. Le modèle du composant est également une représentation de l’application qui est utilisée par l’Agent Assistant pour répondre aux requêtes de l’utilisateur. La question de la divergence entre la représentation cognitive de l’utilisateur et l’application se trouve déportée sur la divergence entre la représentation cognitive de l’utilisateur et la représentation du modèle du composant : c’est le fossé cognitif. Par contre, nous avons un moyen d’agir directement sur le modèle du composant et sur les informations qu’on y fait figurer, contrairement au code du composant, sur lequel on ne peut que tenter d’insérer des points d’accès vers le modèle pour en assurer la synchronisation.
Donc, on se retrouve avec les questions suivantes : quelles informations peut-on faire figurer dans le modèle d’un composant ? Et comment les obtient-on ? Par ailleurs, il est nécessaire d’intégrer une dimension d’évaluation des modèles que nous allons proposés et plus particulièrement de leur influence sur le processus d’assistance.
2.3 - Discussion générale
2.3.3 Vers un modèle d'assistance
Les questions de la modélisation, de la place du modèle et surtout de la méthodologie d’obtention du modèle deviennent des enjeux majeurs. A l’issue des travaux menés dans le projet Daft, il est apparu comme très important de donner au modèle une plus grande substance. L’enjeu réside dans la description d’un modèle et dans la méthodologie qui permet de l’obtenir avant de lui donner une existence indépendante de l’architecture. Pour autant, les modèles des applications sont très utilisés dans le monde de l’informatique. On citera par exemple le domaine de l’Ingénierie Dirigée par les modèles (IDM).
Il nous est apparu important de créer des modèles pour l’assistance, par opposition avec les modèles de l’industrie qui sont utilisés pour la génération du code source, et répondre à des soucis de portabilité, de maintenance ou d’évolution.
Le chapitre suivant présente une étude théorique réalisée dans le cadre de la thèse et qui vise à répondre à la question : « qu’est-ce qui distingue les modèles de l’industrie des modèles pour l’assistance ? ».