• Aucun résultat trouvé

III. Le système Fuzzy4U : concepts, architecture et implémentation

2 Le système Fuzzy4U : architecture logicielle et implémentation

2.2 Implémentation du système Fuzzy4U

2.2.2 Moteur d’adaptation en logique floue

Le travail de thèse a porté sur la réalisation d’un moteur d’adaptation. Il doit permettre de calculer un variant d’IHM adapté à l’utilisateur et de calculer les adaptations à mettre en place au sein de ce variant à partir des caractéristiques du contexte d’usage courant. Dans le cadre de cette thèse, le calcul des adaptations est effectué par un moteur en logique floue, ExpressIF, appelé grâce à un Web Service via une requête http. L’outil ExpressIF a été développé par CEA Tech. Il permet la création des différentes variables linguistiques d’entrées et de sorties nécessaires (Figure 30).

III. Le système Fuzzy4U : concepts, architecture et implémentation

93

Chaque variable linguistique nécessite d’être nommée, définie sur un domaine (booléen, discret ou continu), puis requiert un graphique, détaillant la certitude des différents états de cette variable grâce aux fonctions d’appartenance.

Pour la définition de nos variables linguistiques, nous nous sommes basés sur la définition des variables utilisées au sein du projet MyUI [Peissner et al. 2012], qui définit la majorité de ses variables sur le domaine [0;4], avec la valeur 0 qui représente une absence de problème, et la valeur 4 le niveau le plus élevé de ce problème (par exemple, une acuité visuelle à 0 signifie que l’utilisateur n’a aucun problème de vue, alors qu’une valeur de 4 représente une acuité visuelle particulièrement faible).

La majorité des caractéristiques (acuité visuelle, niveau d’attention, précision des mains, etc.) que nous utilisons est ainsi définie sur ce même domaine continu [0;4] (voir Figure 30), et certaines caractéristiques utilisent un domaine discret lorsque la continuité sur un domaine ne fait plus sens, tel que la variable de vision des couleurs, listant les différents types de daltonisme (deutéranopie, tritanopie, protanopie et achromatie) (Figure 31).

En termes de graphique, l’outil permet la création de différents types de courbes : lignes brisées, triangle, trapèze, gaussienne normalisée, sigmoïde, sigmoïde inversée et courbe en cloche (Figure 32). Cependant, comme cela a été précisé au début de chapitre, lors de la présentation de la logique floue, plusieurs travaux recommandent en particulier l’utilisation de courbes triangulaires et trapézoïdales [Pedrycz 1994 ; Barua et al. 2014]. Nous avons donc défini nos variables en utilisant ces types de courbes.

Au sein de MyUI, le domaine des variables est divisé en 4 sous-domaines [0;1], ]1;2], ]2;3] et ]3;4], représentant les différents états (par exemple, respectivement une acuité visuelle normale, faible, très faible et minimale), avec un passage d’un état à un autre aux seuils de valeur 1, 2 et 3. Nous nous sommes basés sur ce formalisme pour la définition de nos variables linguistiques, auquel nous avons ajouté une gestion de l’incertitude au niveau de ces seuils. En effet, pour une valeur proche de l’un de ces seuils (par exemple la valeur 1), il est difficile d’affirmer que l’état précédent ou l’état suivant serait préférable. Nous avons donc traduit ces seuils par une certitude de 50% pour les deux états concernés (précédant et suivant) au sein de nos variables linguistiques. Par exemple, dans la Figure 30, une valeur de 1 se traduit par un croisement des courbes des deux états, « normal » et « faible », représentant une certitude de 50% dans l’état « normal » et de 50% dans l’état « faible ». En s’éloignant de ces seuils, les certitudes des différents états concernés augmentent et diminuent proportionnellement. Par exemple, une valeur de 1.25 se traduit par une certitude de 75% pour l’état « faible » et de 25% pour l’état « normal ». Enfin, à la valeur 1.5, l’état « faible » atteint une certitude de 100% alors que l’état normal est à 0%. Nous avons ainsi défini nos variables linguistiques pour qu’elles aient, pour toute valeur du domaine, une certitude cumulée de 100%.

III. Le système Fuzzy4U : concepts, architecture et implémentation

94

Figure 31 : ExpressIF – Exemple de variable définie sur un domaine discret

III. Le système Fuzzy4U : concepts, architecture et implémentation

95

Les variables linguistiques de sortie nécessitent une étape supplémentaire qui est l’ajout d’une méthode d’agrégation et d’une méthode de défuzzification. Ces deux méthodes permettent de finaliser le calcul en logique floue. L’exécution des règles floues, décrites ci-après, permettent en effet de calculer une ou plusieurs aires correspondant au niveau d’activation des différents états des variables (voir section III.1.5). Ces aires sont généralement agrégées pour n’en former qu’une, à partir de laquelle la méthode de défuzzification se base afin de calculer une valeur non-floue utilisable en dehors du moteur en logique floue, dite valeur « crisp ».

Dans le cadre de cette thèse, nous avons choisi de regrouper l’étape d’agrégation et l’étape de défuzzification en une étape unique. Le principe de notre méthode est, pour chacune des règles, de calculer le barycentre du sous-ensemble flou de sortie, puis de calculer la moyenne pondérée de ces barycentres, dont la pondération va dépendre de la superficie de l’aire de ce sous-ensemble flou. En considérant toutes les règles ayant une même sortie, la valeur défuzzifiée peut s’écrire :

𝑑(𝑠𝑜𝑟𝑡𝑖𝑒) = ∑ 𝐶𝑖 𝑖 × 𝐴𝑖 ∑ 𝐴𝑖 𝑖

où Ci est la valeur du barycentre et Ai l’aire sous la courbe pour la ième règle concernant cette sortie.

Cette défuzzification est utilisable sur des variables linguistiques continues et nous avons pu l’adapter aux variables discrètes lorsqu’elles sont ordonnées, car cet ordre permet de donner du sens au barycentre. Dans ce cas, la valeur de sortie finale est déterminée comme étant celle qui est la plus proche de la somme pondérée des barycentres. Cela permet d’assurer une transition progressive entre les différentes valeurs d’une sortie, même dans le cas de domaines discrets ordonnés.

Une fois les variables linguistiques nécessaires créées, l’étape suivante est la définition des règles floues (Figure 33). Le moteur ExpressIF permet de gérer des règles de la forme « Si a est ax alors b est bx », avec a et b des variables linguistiques, respectivement d’entrée et de sortie, et ax et bx étant un état donné de chacune des variables. Par exemple « Si age est elderly alors animation est false ».

La logique floue permet d’utiliser les opérateurs logiques de négation (NON), de conjonction (ET) et de disjonction (OU) au sein de la prémisse des différentes règles. Toutefois, nous avons visé une définition de règles « simple ». Chaque règle ne se base ainsi que sur une seule caractéristique du contexte d’usage, la combinaison des règles étant gérée par le biais de l’étape de défuzzification choisie, le barycentre pondéré.

III. Le système Fuzzy4U : concepts, architecture et implémentation

96 Figure 33 : ExpressIF - Listing des règles floues créées

Enfin, l’outil propose un « mode interactif », permettant d’effectuer des tests en modifiant les diverses valeurs d’entrées des variables linguistiques afin de voir les résultats produits par l’ensemble de règles définies (Figure 34).

III. Le système Fuzzy4U : concepts, architecture et implémentation

97

Dans le cas où un développeur souhaite adopter cette approche d’adaptation des IHM, et afin de limiter le coût de développement, nous préconisons de limiter le nombre de variants en s’appuyant quand c’est possible sur les possibilités offertes par le Responsive Web Design – y compris les flexboxes et les grilles CSS. En effet, une page écrite avec un CSS « responsive » peut déjà prendre en compte des modifications liées aux variations de taille d’écran. Par exemple, il peut permettre de transformer deux espaces de travail placés côte-à-côte sur un grand écran en deux espaces l’un au-dessus de l’autre. Un variant peut donc parfaitement être ‘responsive’ et être adapté pour plusieurs tailles d’écran. Cependant, le Responsive Web Design présente des limites : (a) il ne peut prendre comme condition de changement que la nature du dispostif (imprimante, mobile…) et sa taille d’écran (il est impossible d’exprimer des variations spatiales en fonction de la taille de police, par exemple), que (b) il ne peut avoir qu’un impact limité sur la réorganisation spatiale (certaines modifications comme convertir un espace de travail en onglet sont très délicates à programmer et plus encore à maintenir car la page doit contenir toutes les variations et le CSS ne sert plus qu’à décider laquelle est affichée) et qu’enfin (c) il ne gère pas mieux les transformations d’interacteurs (liste de cases à cocher sur PC devenant une liste à puces sur SmartPhone), l’existence des variants permet d’élargir les possibilités, en permettant de créer des variations des IHM, dédiés à des conditions hors de portée du Responsive Web Design. Mobiliser à la fois les variants et le Responsive Web Design permet ainsi de limiter le nombre de variants (ce qui optimise le coût de développement et de maintenance) tout en pouvant dépasser si besoin les limites du CSS.

Si un développeur souhaite modifier les adaptations mises en place, plusieurs possibilités s’offrent à lui : il peut modifier les règles d’adaptation, afin que le calcul des paramètres lui corresponde mieux (et par induction que le rendu de l’IHM soit plus adéquatement adapté) ou encore modifier les règles CSS elles-mêmes afin de personnaliser l’adaptation. Nous préconisons une modification du CSS, bien que les autres méthodes restent disponibles dans le cas où une modification du CSS ne soit pas la plus appropriée. Par exemple, si un développeur ne souhaite pas différencier les luminosités ambiantes « sombre » et « très sombre » en appliquant un même fond d’écran gris. Avec une modification du CSS, le développeur conserve les deux règles standards et doit les modifier pour préciser les deux cas de figures : une règle « luminosité sombre Alors fond gris » et une seconde « luminosité très sombre Alors fond gris ». Dans ce cas de figure, il est préférable de modifier la règle d’adaptation elle-même afin de regrouper les deux cas en une seule règle et éviter ainsi de modifier inutilement les attributs de la page, sans modification de rendu de l’IHM.

Le moteur d’adaptation actuel s’appuie sur 87 règles en logique floue : 73 règles portant sur l’utilisateur, 6 règles pour la plate-forme et 8 règles pour l’environnement. L’ensemble de ces règles est fourni en Annexe 2 : Liste des règles d’adaptation implémentées dans Fuzzy4U. Il n’a pas pour objectif d’être exhaustif, mais d’être suffisamment important pour être réaliste et permettre de mettre en avant la combinaison des règles effectuée par la logique floue. Par la suite, nous nous focaliserons sur les règles liées à l’accessibilité, qui sont au cœur de notre travail de thèse.

III. Le système Fuzzy4U : concepts, architecture et implémentation

98