Discussion

Les besoins identifiés afin de supporter la méthode proposée dans nos travaux de thèse ont permis l’élaboration d’un outil dont l’architecture modulaire a été présentée dans la section 5.2. Un premier besoin concerne la gestion efficace des règles. Actuellement, cette gestion est supportée grâce à un éditeur de règles permettant à un expert ergonome d’alimenter une base de règles, de mettre à jour et de supprimer les règles. Cependant, l’éditeur de règles doit être configuré en amont pour pouvoir écrire des règles par rapport aux concepts de l’ontologie et pour pouvoir guider l’expert ergonome dans cette écriture. Cette configuration passe par l’apprentissage du langage d’écriture des règles (dans notre solution, le langage utilisé est JBoss Rules) pour écrire les conditions applicables sur chaque concept.

D’autres besoins ont été identifiés concernant l’évaluation ergonomique : le support d’un grand ensemble de règles et d’artefacts de taille importante, la prise en compte de nouveaux artefacts, ainsi que le support de l’évaluation dans toutes les étapes du cycle de vie de l’application. La prise en compte d’un artefact (nouveau ou existant) est possible grâce à la présence du fichier de mappings. L’écriture de ce fichier peut être longue et fastidieuse, comme nous avons pu l’expérimenter, mais elle n’est faite qu’une fois, lorsqu’un nouvel artefact doit être supporté par l’outil d’évaluation. L’édition de ce fichier de mappings est supportée par un éditeur qui permet, pour un expert informatique, de faire les mises en correspondance nécessaires pour la transformation. Par ailleurs, le moteur d’évaluation utilisé (JBoss Rules) est un moteur de règles puissant capable de supporter un grand nombre de règles et des artefacts de grande taille (contenu large). L’évaluation sur une application de grande taille, telle que celles développées dans le cadre de projets industriels avec e-Citiz, a prouvé qu’il n’y avait pas de pertes de performance. Enfin, la combinaison du moteur de transformation et du moteur d’évaluation permet d’évaluer les différents artefacts produits dans les différentes étapes du cycle de vie.

107

Concernant le rapport d’évaluation, les besoins exprimés concernaient le détail et l’explication pertinente des erreurs détectées lors de l’évaluation, mais également la possibilité de configurer, de sauvegarder et de versionner celui-ci. Le rapport d’évaluation est actuellement intégré dans une vue de la plateforme Eclipse, plateforme sur laquelle l’outil développé est intégré. Il est par conséquent impossible de configurer, sauvegarder et versionner ces rapports. A terme, nous prévoyons de pouvoir convertir ce rapport au format EARL [EARL], format qui permettrait d’une part, d’évaluer la qualité des rapports produits par notre outil par rapport aux autres outils d’inspection et d’autre part, de coupler nos rapports avec ceux produits par un outil complémentaire au nôtre.

Les besoins sur la correction des erreurs étaient de pouvoir proposer une correction automatique dans le cas où cela est possible, et de proposer une correction semi-automatique ou manuelle autrement. La correction des erreurs n’est, pour l’instant, pas supportée dans notre outil. Actuellement, puisque les erreurs sont relatives au modèle de l’application abstraite, la correction des erreurs est prévue pour être effectuée sur ce modèle, puis, une fois ce modèle corrigé, ces corrections sont ensuite reportées sur l’artefact source. Ce module doit à terme pouvoir guider efficacement la conception d’interfaces ergonomiques en assistant de manière interactive l’évaluateur dans les phases de correction.

Enfin, les besoins sur l’outil de manière générale, étaient qu’il soit modulaire pour pouvoir être facilement intégré à tout environnement de développement, et en outre, être facile à prendre en main. En réponse à ces besoins, nous avons proposé une architecture constituée de plusieurs modules indépendants les uns des autres. Nous avons vu que cette indépendance autorisait le choix des différents modules selon les besoins et contraintes d’un projet, mais permettait également d’intégrer l’outil dans n’importe quel environnement de développement. En outre, l’utilisation de l’outil s’avère simple : dans la plateforme e-Citiz, l’évaluation, une fois configurée, se fait automatiquement à chaque fois que l’e-service spécifié est modifié et sauvegardé, sans intervention de l’utilisateur. Si l’utilisation de l’outil par un évaluateur reste simple, un effort initial doit toutefois être entrepris par l’expert informatique pour éditer les fichiers de mappings mais également pour configurer l’éditeur de règles.

5.5. CONCLUSION

Nous avons présenté dans ce chapitre un outil capable de supporter l’inspection ergonomique de manière automatique dans les différentes étapes du processus de conception selon la méthode proposée dans nos travaux de thèse. L’architecture de cet outil est composée de plusieurs modules indépendants : le moteur de transformation, l’éditeur de mappings, l’éditeur de l’outil de gestion des connaissances ergonomiques, le moteur d’évaluation et l’extracteur de faits, ainsi que le correcteur. Ces modules, puisque indépendants les uns des autres, peuvent être changés et adaptés selon les besoins et contraintes d’un projet. Notamment, l’intégration de notre outil est facilitée dans un environnement de développement utilisant déjà une partie des modules nécessaires au fonctionnement de l’outil.

Notre outil a été intégré dans la plateforme e-Citiz de développement d’e-services. Certains modules, comme le moteur d’évaluation, étaient déjà présents sur cette plateforme ; d’autres, ont été implémentés manuellement, comme le moteur de transformation (la transformation est faite manuellement dans le code). L’intégration de notre outil sur cette plateforme a montré qu’il pouvait être utilisé sur une plateforme employée à l’échelle industrielle.

109