Une approche de gestion de contextes métiers pour l'accès à l'information

HAL Id: hal-01390837

https://hal.archives-ouvertes.fr/hal-01390837

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Une approche de gestion de contextes métiers pour

l’accès à l’information

Hamdi Chaker, Max Chevalier, André Tricot

To cite this version:

To link to this article :

DOI:10.3166/isi.19.2.111-135

URL:

http://dx.doi.org/10.3166/isi.19.2.111-135

To cite this version :

Chaker, Hamdi and Chevalier, Max and Tricot,

André Une approche de gestion de contextes métiers pour l'accès à

l'information. (2014) Ingénierie des Systèmes d'Information, 19 (n° 2).

pp. 111-135. ISSN 1633-1311

O

pen

A

rchive

T

OULOUSE

A

rchive

O

uverte (

OATAO

)

OATAO is an open access repository that collects the work of Toulouse researchers and

makes it freely available over the web where possible.

This is an author-deposited version published in :

http://oatao.univ-toulouse.fr/

Une approche de gestion de contextes

métiers pour l’accès à l’information

Hamdi Chaker

, Max Chevalier

, André Tricot

118 Route de Narbonne, 31062 Toulouse cedex 9 {Hamdi.Chaker, Max.Chevalier}@irit.fr

2. CLLE/Université Toulouse 2,

5 allée Antonio Machado, 31 058 Toulouse cedex 4 andre.tricot@univ-tlse2.fr

RÉSUMÉ. La prise en compte du contexte améliore la pertinence des informations fournies par

les systèmes pour les utilisateurs. Nous introduisons dans ce papier un gestionnaire de situations contextuelles métier basé sur une nouvelle définition générique du contexte. Ce gestionnaire prend en compte diverses dimensions contextuelles et agit comme un intermédiaire entre les systèmes d’accès à l’information (SAI) et les informations contextuelles. Notre approche repose sur un processus original qui gère les différentes dimensions contextuelles afin de créer une situation unique à un instant t. Pour cela, le processus de Mise En Situation (MES) utilise la base de règles qui représente la connaissance contextuelle du gestionnaire. Les situations seront utilisées par les SAI à des fins d’adaptation de processus informationnel. Par ailleurs, un processus d’extraction est proposé pour améliorer la fiabilité du gestionnaire de contexte au fil du temps en faisant évoluer sa base de connaissances. Le gestionnaire a été mis en œuvre à travers un prototype qui a été utilisé pour l’expérimentation afin de mesurer l’impact de nos propositions dans le domaine de la maintenance aéronautique.

ABSTRACT. Taking into account the context is important to improve the way systems provide relevant information to users. For this purpose, we introduce a business context information manager based on a novel and generic definition of the context. This manager takes into account various contextual dimensions and acts as an intermediary between Information Access Systems (IAS) and contextual information. This approach relies on an original process that manages the various contextual dimensions to create a unique situation at time t. To this end, SM (Situation Manager) uses rules set which is the knowledge of the context manager. The situations will be used by an IAS for activity adaptation. Furthermore, an extracting process is also proposed to improve the context manager reliability over time and to facilitate its knowledge evolution.The manager has been implemented through a prototype that has been used for experiments to measure the impact of our proposals in the field of aircraft maintenance.

MOTS-CLÉS: contexte métier, situation contextuelle, gestion de contexte, accès contextuel à l’information, tâche métier, tâche informationnelle, maintenance aéronautique.

KEYWORDS: business context, contextual situation, context management, contextual access to

pascal.pinier@scd.ups-tlse.fr

L’accès à l’information (AI) dans un contexte métier, i.e. lorsque l’utilisateur doit retrouver et exploiter un document pour réaliser une tâche métier, constitue un réel défi. En effet, les moyens et dispositifs existants, en particulier les modèles et moteurs de recherche classiques, s’avèrent inadaptés par manque de pertinence. Le travail que nous proposons se fonde sur la notion de contexte et plus précisément sur la gestion des informations de contexte afin de répondre aux besoins d’adaptation des SAI (systèmes d’accès à l’information) et particulièrement dans des cadres métiers. L’objectif global est d’adosser une couche de contextualisation aux SAI, les rendant plus adaptables.

La contribution de ce travail vise à proposer un gestionnaire de situations contextuelles (GSC) générique et adapté à tout contexte métier. Le GSC prend en compte les informations contextuelles nécessaires au processus de contextualisation des SAI métiers. Il est particulièrement efficace pour les domaines où l’enjeu de fiabilité est fort et où les tâches sont clairement définies et structurées. Pour cela, nous avons choisi la maintenance aéronautique comme domaine d’application parce qu’elle réunit toutes les conditions pour montrer l’efficacité de notre approche.

Dans un premier temps, nous étudions la notion de contexte puis nous proposons une définition générique du contexte et les concepts sous-jacents. Cette définition permet d’inclure, a minima, l’ensemble des dimensions contextuelles jugées pertinentes dans la littérature. Nous insistons sur la généricité de cette définition car elle nous a permis d’intégrer dans le GSC proposé tout ce qui peut être considéré comme des informations contextuelles. Pour offrir un point d’entrée aux systèmes contextualisés basés sur notre approche et ainsi favoriser leur adaptation, nous proposons une nouvelle définition du concept de situation. Nous définissons la situation comme une interprétation du contexte à un instant donné, autrement dit, comme la photographie de l’activité à un instant t.

À des fins de validation, nous avons implanté le prototype de GSC. Pour bénéficier de la généricité du gestionnaire, l’implantation réalisée propose une interface utilisable par les applications (API) qui nécessitent une adaptation au contexte. Afin d’évaluer l’impact de nos propositions dans un domaine concret, nous avons mené, grâce à ce prototype, une expérimentation visant à contextualiser l’AI dans le domaine de la maintenance aéronautique. Nous soulignons la convergence entre les résultats obtenus dans des travaux antérieurs menés par des psycho-cogniticiens et les résultats obtenus avec notre approche.

pascal.pinier@scd.ups-tlse.fr

2.1. Objectif du contexte

Le terme context awareness a été introduit par Schilit et al. en informatique ubiquitaire (Schilit et al., 1994). Ce qui veut dire que les systèmes informatiques peuvent sentir et interagir avec l’environnement externe. Dey (2001) a aussi défini les systèmes sensibles au contexte comme context aware system : un système qui utilise le contexte pour fournir une information pertinente et/ou des services à l’utilisateur, où la pertinence dépend de la tâche de l’utilisateur. Dey différencie le contexte de la situation. Cette dernière est définie comme une description des états des entités pertinentes (Dey, 2001). Pour l’auteur, la description de la situation nécessite moins d’effort que la définition des composantes du contexte. Dans d’autres travaux, nous avons constaté que des chercheurs définissent l’information contextuelle (contextual information), comme des données pertinentes extraites en tenant compte du contexte (Anagnostopoulos et al., 2007).

À la différence des applications classiques, celles qui sont sensibles au contexte s’adaptent en se basant sur les informations contextuelles fournies par un gestionnaire de contexte. Le contexte est donc une source d’adaptation pour les

applications.

2.2. Vision du contexte

2.2.1. Une vision du contexte qui s’élargit

Au début, le contexte était une notion très « physique ». Dans (Schilit et al., 1994), l’emplacement de l’utilisation est la partie la plus importante dans la compréhension du contexte. Pour eux, les aspects importants du contexte sont : où vous êtes, et avec qui, et quelles sont les ressources accessibles, donc disponibles. Pascoe définit lui le contexte comme un sous-ensemble d’états physiques et

conceptuels ayant un intérêt pour une entité particulière (Pascoe, 1998).

pascal.pinier@scd.ups-tlse.fr

2.2.2. Une vision du contexte plus applicative

L’ouverture du contexte a engendré une orientation des définitions de contextes vers les applications cibles. Le contexte est associé aux activités des usagers. Dourish distingue deux vues du contexte : la vue représentative et la vue

interactionnelle. La deuxième considère le contexte comme un dispositif émergeant de l’interaction, déterminé par le temps et le contenu : plutôt que de supposer que le

contexte définit la situation dans laquelle une tâche arrive, Dourish suggère un rapport cyclique entre le contexte et l’activité, où la tâche engendre le contexte (Dourish, 2004).

La conséquence directe de cette orientation de la vision de contexte vers l’activité des usagers est une divergence des définitions du contexte. C’est-à-dire, pour chaque domaine d’application plusieurs définitions du contexte sont proposées. La divergence de ces définitions est donc liée à l’hétérogénéité et l’abondance des objets pour lesquels le contexte est défini, i.e. les entités ou les acteurs auxquels le contexte est destiné (Göker et al., 2009).

2.2.3. Les gestionnaires de contexte

Le gestionnaire de contexte doit être le garant de la collecte, de la gestion et de la présentation des informations contextuelles pour le bénéfice des applications. Il permet de proposer un service intermédiaire de gestion de contexte essentiel pour les applications parce qu’il gère l’accès aux sources de contexte en plus d’effectuer de l’inférence sur les informations contextuelles. Bon nombre de travaux ont étudié et comparé ces gestionnaires selon plusieurs critères comme le modèle de contexte ou l’architecture du gestionnaire (Bettini et al., 2010). Nous avons noté une divergence dans la sémantique de la modélisation du contexte qui diffère d’un travail à l’autre ainsi que les infrastructures de gestion de contexte (Chaker, 2012).

2.3. Situations contextuelles

Les systèmes sensibles aux contextes ont tendance à se transformer de plus en plus en des systèmes sensibles à des situations de ces contextes. En effet, les informations contextuelles de bas niveau (provenant par exemple de capteurs physiques) ont tendance à changer continuellement et sont parfois dénuées de sens ou incertaines. Ainsi, les informations contextuelles brutes ne permettent pas une prise en compte de l’usager dans son contexte, ni l’adaptation des applications sensibles aux contextes.

(Ye et al., 2011). Comparées au contexte, les situations sont significatives, certaines et relativement stables. C’est-à-dire qu’elles ne changent pas lors de modifications « mineures » des informations contextuelles. En plus de cela, faire abstraction des changements des sources contextuelles dans les situations épargne aux systèmes de gestion du contexte les difficultés liées à la résolution des imperfections des informations contextuelles et les changements dans le contexte initial (Bettini et al., 2010). Plus précisément, les situations ajoutent du « sens » destiné aux applications sensibles au contexte et sont plus faciles à définir et à entretenir que les informations contextuelles brutes. Ainsi, l’adaptation des applications sensibles au contexte est alors déclenchée par le passage à une nouvelle situation. Autrement dit, si le changement d’une valeur de contexte déclenche un changement de situation alors le système pourra déclencher l’adaptation adéquate.

Dey a défini la situation contextuelle comme « la description des états des entités pertinentes » (Dey, 2001). Nous rappelons que pour Dey une entité peut être une personne, un endroit, un objet pertinent pour l’usager ou pour l’application. Une situation est donc un état à l’instant t d’un contexte.

Jameson (2001) définit également la situation contextuelle dans laquelle un usager effectue sa tâche et selon laquelle le système va personnaliser les informations proposées. Jameson donne l’exemple de l’emplacement de l’usager à l’instant t à partir duquel le système personnalisera les informations. Jameson ne s’arrête pas là, il va ajouter d’autres dimensions au contexte : l’état de l’usager, que ce soit cognitif et/ou psychologique, ou le profil à long terme de l’usager. La situation définie par Jameson ne concerne que la dimension environnementale du contexte, l’emplacement de l’usager au moment de faire sa tâche ou quand il interagit avec le système.

Schmidt (Schmidt, Beigl, et Gellersen, 1999 ; Schmidt, et al., 1999) a lui aussi introduit la situation dans la contextualisation en considérant que le contexte décrit une situation dans laquelle on trouve un usager, le matériel utilisé, la tâche à réaliser et l’environnement. La situation définie par Schmidt n’est pas du tout celle de Jameson qui ne prend pas en compte l’emplacement du processus. Schmidt définit la sensibilité au contexte (context awareness) comme « la connaissance1 de l’utilisateur et l’état du dispositif informatique, y compris l’environnement, la situation et, à une mesure moindre, l’emplacement ».

D’un autre point de vue, pour Loke (2004) la notion de contexte est liée à la notion de situation. Il propose l’agrégation des informations de contexte, afin de déterminer la situation des entités. Ainsi, la situation est considérée comme étant à un niveau plus élevé que le contexte. Nous remarquons que Loke différencie l’activité et la situation. Il considère une activité comme un type d’information contextuelle pour caractériser une situation. Pour lui, l’activité se réfère généralement à des actions ou des opérations menées par les êtres humains tels que

pascal.pinier@scd.ups-tlse.fr

« cuisiner », « courir », « écrire un article ». Loke s’appuie sur les données issues directement des capteurs pour déterminer l’action courante et l’état du périphérique. Il propose une nouvelle approche pour la représentation des situations en découplant les procédures d’inférence du raisonnement sur les données de contexte. En effet, Loke applique une approche de programmation logique pour caractériser les situations, ce qui aide le concepteur des systèmes sensibles au contexte à identifier naturellement les situations d’une application.

Li et Landay (2008) s’inscrivent dans le même courant (activités, situations). Ces auteurs proposent un paradigme d’interaction pour le système « Ubicomp » basé sur l’activité (informatique ubiquitaire basée sur les activités). Dans leur modèle, la relation entre l’activité et la situation est définie comme suit : une activité évolue chaque fois qu’elle est réalisée dans une situation particulière. Une situation est un ensemble d’actions ou de tâches effectuées dans certaines « circonstances ». Dans leur approche, les circonstances sont les informations issues des différentes sources de contexte. D’autres travaux récents se fondent sur l’approche de Li et Landay pour définir les situations. Par exemple, le travail de Bruegger et al. (2009) : « une situation est toute activité réalisée dans des contextes ».

Par ailleurs, Thomson et al. (2006) ont proposé une approche de détermination automatique des situations à partir des informations contextuelles. Ils ont fourni une bibliothèque réutilisable des caractéristiques des situations. En effet, ils ont exprimé différents niveaux de granularité d’une situation à travers l’héritage des caractéristiques provenant des sources d’informations de contexte. Ainsi, les nouvelles caractéristiques sont créées à partir de caractéristiques existantes afin que la même situation puisse être interprétée à différents niveaux d’abstraction.

Pour Yau et al. (2006), le contexte comprend le système de l’utilisateur ainsi que toutes les informations instantanées, détectables et pertinentes provenant de l’environnement. Quant à la situation, dans leur approche (Yau et al., 2006), elle est définie par un ensemble de contextes collectés sur une période de temps et qui est pertinent pour les actions futures des applications. Yau et al. ont analysé la sémantique des situations et leur ont donné des représentations formelles. Une situation peut être atomique ou composée. La situation atomique est une composition de contextes basée sur les opérateurs de contexte en plus des opérateurs arithmétiques, des opérateurs de comparaisons ainsi que des contraintes de temps. La situation composée, quant à elle, est une composition de situations atomiques ou composées en utilisant de la même manière les opérateurs logiques et les contraintes de temps. L’approche de Yau et al. permet aux concepteurs des applications sensibles au contexte d’utiliser les expressions de la logique formelle pour la spécification des situations.

pascal.pinier@scd.ups-tlse.fr

aussi une situation contextuelle relationnelle : elle est le résultat d’une association de plusieurs parties du contexte initial en respectant une certaine logique relationnelle. Dans leur approche, la situation peut être aussi une situation de relation formelle. En d’autres termes, une situation peut être définie directement en appliquant des relations formelles entre deux parties du contexte initial, comme supérieure à, sous-ensemble de, etc. Enfin, une situation peut également être une combinaison de plusieurs situations.

La plupart des travaux que nous avons présentés dans cette section se concentrent sur la composition des situations et sur des représentations formelles basées sur ces compositions. Le but de ces travaux est d’inférer des situations, permettant une spécification de haut niveau du comportement humain dans un environnement sensible au contexte, afin de lui proposer par la suite les services les plus adaptés. L’intérêt de l’ensemble des travaux présentés porte sur la façon d’abstraire, de représenter et d’identifier les situations d’après les informations brutes provenant du contexte.

2.4. Les dimensions les plus pertinentes du contexte en accès à l’information

Une étude détaillée des travaux de contextualisation de l’AI nous permet de remarquer qu’ils s’accordent tous sur un cœur commun qui inclut l’environnement et les dimensions humaines (Brusilovsky et al., 2007). En effet, les dimensions

usager, tâche et environnement constituent les ensembles de tous les éléments les

plus pertinents du contexte pouvant améliorer le processus informationnel.

2.4.1. Tâche

La tâche de travail est une dimension important du contexte de l’AI. La tâche de travail comme motivation de l’AI a été définie selon plusieurs perspectives (Belkin, 2008 ; Kelly, 2006). Une meilleure prise en compte du modèle de la tâche de AI augmente l’efficacité des SAI (Stojanovic, 2005).

Nous avons remarqué une divergence dans la structure conceptuelle des tâches informationnelles dans la littérature. Les auteurs (Byström et al., 2005; Ingwersen et

al., 2005) classent les tâches en ensembles imbriqués tandis que (Li et al., 2008)

proposent une approche à facettes pour la conceptualisation de tâche afin d’explorer les rapports entre les tâches et le comportement interactif de l’AI.

2.4.2. Usager

pascal.pinier@scd.ups-tlse.fr

etc. (Reichenbacher, 2007) ; et son état physiologique. De nouveaux facteurs font leur apparition dans la dimension usager et se focalisent sur l’état émotionnel dans l’AI (Arapakis et al., 2008) tels que la frustration, le stress, etc.

2.4.3. Environnement

L’environnement se focalise sur les facteurs spatio-temporels, mais la liste peut être plus longue. L’un des premiers facteurs environnementaux ayant été intégré dans l’AI contextuelle est la localisation de l’utilisateur (Abowd et al., 1997). D’autres travaux se focalisent sur les entités autour de l’utilisateur comme faisant partie de l’environnement (l’écran, la résolution…) (Ayú et al., 2008). Ils ont étudié leur impact sur le processus de personnalisation de l’AI.

2.5. Synthèse de l’état de l’art

2.5.1. Définitions du contexte

Nous avons présenté dans cet état de l’art une vision du contexte qui s’est élargie avec le temps afin de prendre en compte la diversité des modèles des applications ubiquitaires. La liste ci-dessous présente l’évolution dans le temps des définitions du contexte les plus influentes de la littérature :

– (Schilit, 94) : le contexte est l’emplacement de l’usager et des objets à proximité. où vous êtes, avec qui et quelles sont les ressources disponibles ;

– (Pascoe, 98) : le contexte est un sous-ensemble d’états physiques et conceptuels ayant un intérêt pour une entité particulière ;

– (Dey, 01) : le contexte est un jeu de situations et d’actions ; énumération de tous les aspects du contexte possible ;

– (Dourish, 04) : deux vues du contexte (représentative et interactionnelle) - Vue représentative : (1) le contexte est une information connue et codée (2) le contexte existe (3) le contexte est stable (4) le contexte est séparable de l’activité

- Vue interactionnelle : le contexte est un dispositif émergeant de l’interaction - (Yau et al., 06) : le contexte est le système de l’usager ainsi que toutes les informations environnementales, instantanées, détectables et pertinentes.

2.5.2. Situation contextuelle

Comparée au contexte, la situation contextuelle est certaine, significative relativement stable. Nous avons présenté une panoplie de définitions de la notion de situation contextuelle. Ci-dessous les définitions les plus influentes de la situation contextuelle dans la littérature :

pascal.pinier@scd.ups-tlse.fr

– (Jameson, 01) : la situation contextuelle est un usager effectuant sa tâche et selon laquelle le système va personnaliser les informations proposées ;

– (Schmidt, 99) : la situation contextuelle est un usager, le matériel utilisé, la tâche à réaliser et l’environnement ;

– (Loke, 04) : la situation contextuelle est une agrégation des informations de contexte, i.e. un niveau plus élevée que le contexte ;

– (Li et Landay, 08) : La situation contextuelle est un ensemble d’actions ou de tâches effectuées dans certaines « circonstances ».

2.5.3. Accès contextuel à l’information

Les facteurs contextuels importants pour l’accès à l’information varient selon les travaux. Ci-dessous une liste des variables contextuelles les plus importantes selon les travaux les plus influents de la littérature :

– (Budzik et al., 01) : l’emplacement, « contexte » de l’usager ( intérêt court et long terme..) la qualité de l’information la tâche, etc. ;

– (Allen, 97) : les variables individuelles (structure de connaissance, styles cognitifs et traits de personnalité…) et les variables situationnelles incluent, par exemple, l’environnement spécifique de la tâche ;

– (Johnson, 03) : le macro-niveau (informations sociétales, informations technologiques, architecture et tendances institutionnelles), le niveau local (contenu, contraintes de recherche, et domaine d’information) et le niveau individuel (programmes de décision, niveau de motivation de l’usager, étape de recherche, logique et expérience des individus…).

3. Limites des travaux existants

3.1. Limites liées à la définition du contexte

Les chercheurs ont proposé plusieurs définitions de cette notion de contexte dans le but de mieux l’intégrer dans les systèmes et de la gérer dans sa complexité. La première limite de ces travaux réside dans le fait qu’ils divergent sur la définition même de la notion de contexte. Ainsi, ces définitions ne considèrent pas toutes les dimensions contextuelles disponibles et prennent donc exclusivement en compte les dimensions spécifiques aux besoins de l’application à contextualiser. Bazire et al., (2005) ont présenté et examiné 150 définitions différentes du contexte dans des domaines variés. Les définitions ont été négligées au profit des modèles du contexte sur lesquels se basent les systèmes.

3.2. Limites liées à la gestion du contexte

Les travaux rencontrés ont évidemment hérité des limites liées à la non-généricité de leurs définitions. En effet, malgré la multitude des approches de

pascal.pinier@scd.ups-tlse.fr

gestion du contexte, nous n’avons pas pu trouver de travaux proposant un gestionnaire de contexte générique prenant en compte tout ce qui peut être qualifié de dimension contextuelle, y compris l’utilisateur lui-même. Plus encore, une deuxième limite attribuée aux travaux de la littérature, réside dans le fait que les gestionnaires de contexte proposés ne prennent pas en considération les éléments contextuels les uns par rapport aux autres au moment de la contextualisation, même si ces derniers peuvent interagir les uns sur les autres.

3.3. Limites liées à la gestion des situations passées

Une troisième limite réside dans l’absence d’approche utilisant le feedback sur les situations enregistrées (historique du contexte) pour améliorer le processus de contextualisation (création des situations) ou rendre possible une telle contextualisation. En effet, les approches propres à la littérature utilisent l’historique de contexte afin d’améliorer le processus de prédiction des situations (activités) pour mieux se rapprocher du besoin global de l’usager, mais sans feedback.

4. Proposition

Nous exposerons dans cette section le GSC qui se fonde sur l’ensemble des approches que nous proposons. Le GSC a un rôle primordial pour garantir la pertinence et la précision des informations contextuelles provenant des différentes sources du contexte. Ces informations sont proposées aux systèmes tiers qui font à des fins d’adaptation par exemple. Le GSC gère l’accès aux sources de contexte en plus d’effectuer de l’inférence sur les informations contextuelles.

Le GSC, comme la définition de contexte qui en est la base, est générique et doit prendre en considération tous les éléments contextuels qualifiés de pertinents pour une application ou pour un système donné. Ainsi, nous exposons une nouvelle définition du contexte qui vise à donner à cette notion une généricité et une base commune issue des différents travaux.

4.1. Notre vision du contexte

4.1.1. Définition du contexte

Le contexte d’un objet correspond à toutes les dimensions contextuelles pouvant avoir un impact sur cet objet.

pascal.pinier@scd.ups-tlse.fr

trois dimensions pertinentes du contexte dans l’accès à l’information. Le contexte de l’usager pourrait être composé de la tâche qu’il réalise ainsi que de l’environnement dans lequel il se trouve parce qu’ils peuvent avoir un effet direct sur lui. De manière similaire, la tâche a aussi son propre contexte ; ce dernier pourrait être composé de l’usager qui l’effectue et de l’environnement dans lequel elle est réalisée, seulement si ces deux dimensions ont un impact sur elle.

4.1.2. Concepts du contexte

Le contexte comme nous le proposons dans nos travaux est défini par : – Contexte = {dimension contextuelle}

– Dimension contextuelle = {Élément contextuel}

– Élément contextuel = {Élément contextuel} | {Nom, Valeur, Constance, Fiabilité}

Dans la figure 1, un exemple qui illustre les concepts et les éléments du contexte.

Figure 1. Un exemple de contexte

Les dimensions contextuelles sont les dimensions composant un contexte et regroupant tout ce qui peut être quantifié et regroupé dans une dimension pour décrire la même entité du monde réel. Les dimensions contextuelles sont composées d’éléments contextuels et ont une structure hiérarchique.

pascal.pinier@scd.ups-tlse.fr

d’éléments contextuels élémentaires tels que la « langue préférée » et « le format de lecture préféré ». Un élément contextuel élémentaire est caractérisé par : un Nom, une Valeur, une variable Constance et la Fiabilité de la valeur de l’élément.

4.2. Du contexte à la situation

4.2.1. Interprétation du contexte

L’interprétation du contexte doit être considérée en complément des informations brutes provenant du contexte initial. Celle-ci comporte en plus les dimensions contextuelles ainsi que les éléments contextuels les plus pertinents pour une activité donnée, des connaissances contextuelles supplémentaires.

4.2.2. Rôle de l’interprétation du contexte

Dans notre approche, une interprétation du contexte est fondamentale à la contextualisation des applications sensibles au contexte. Cette importance peut être interprétée selon trois niveaux complémentaires : la possibilité de coexistence des différents éléments contextuels issus du contexte initial : la validité ; l’impact de

ces éléments les uns sur les autres dans une même interprétation de contexte ; le manque d’informations contextuelles qui peut survenir dans les contextes initiaux.

4.2.3. Situation contextuelle

La situation offre selon notre approche le support d’interaction et d’adaptation du contexte. Les dimensions contextuelles qui composent le contexte en entrée sont reproduites et adaptées au niveau de la situation pour générer ensemble, à l’instant t, une situation unique. Ainsi, l’interaction entre les différentes dimensions contextuelles peut entraîner des modifications (insertions, modifications, suppressions, etc.) du contenu de ces dimensions issues du contexte. Ces adaptations aux travers des éléments qui composent les différentes dimensions, permettent de produire la photographie la plus fidèle possible d’une interprétation du contexte.

4.2.3.1. Définition

La situation est une interprétation stable d’un contexte à un instant t.

pascal.pinier@scd.ups-tlse.fr

4.2.3.2. Concepts de la situation contextuelle

Situationt = {{dimensions contextuellest}, Validité, {étatn, {actions}}, @Situationt-1}

Une situation est composée de quatre éléments. Premièrement, elle se compose d’un ensemble de dimensions contextuelles issu du contexte. Deuxièmement la validité qui indique si une situation est valide ou non en fonction des règles. Le troisième élément est l’ensemble des actions qui se sont déroulées durant un laps de temps correspondant à la situation. Enfin, toutes les situations qui sont associées doivent être liées. Pour cela, le quatrième élément de la situation est un lien (pointeur) vers la situation qui l’a précédée et dont la fin déclencha sa création

4.2.3.3. Exemple de situation

Voici un exemple utilisant les trois dimensions pertinentes de la situation. La situation unique à l’instant t serait la photographie de l’activité de l’usager lambda opérateur novice en maintenance aéronautique effectuant sa tâche de maintenance sur un tarmac lumineux, bruyant et avec un vent violant.

Nous pourrions supprimer, dans la situation, tous les éléments contextuels qui n’ont aucun impact sur la réalisation de la tâche par l’usager dans l’environnement actuel. Ceci permet de créer une situation unique et reflétant au plus près la réalité de l’exécution de la tâche qui sera exploitée par la suite par le SAI à des fins d’adaptations. Dans ce qui suit, après avoir défini la situation, nous évoluons d’une façon logique vers l’approche de sa création.

4.3. Gestionnaire de situations contextuelles métier

Le GSC, comme la définition de contexte qui en est la base, est générique. La généricité du gestionnaire réside dans le fait qu’il doit prendre en compte tout ce qui peut être qualifié de dimension contextuelle. Autrement dit, il ne doit pas exclure a

priori des informations jugées contextuelles. 4.3.1. Architecture du GSC

Dans cette section nous présentons l’architecture globale de notre GSC. Nous pouvons voir sur la figure 2 les trois parties principales qui composent le GSC. Les applications sensibles au contexte communiquent au GSC, à travers des capteurs applicatifs, des informations contextuelles qui lui sont propres.

4.3.1.1. Gestionnaire de données contextuelles

pascal.pinier@scd.ups-tlse.fr

la communication entre les différentes composantes du GSC d’une part et des applications en quête d’informations contextuelles d’autre part.

Figure 2. Architecture globale du gestionnaire de situations contextuelles

4.3.1.2. Définition et types des règles

Les règles sont le moyen qui permet au GSC de confronter les éléments contextuels les uns aux autres et de créer une situation unique à un instant t. Principalement, le GSC se fonde sur les règles pour « adapter » les éléments contextuels en mettant à jour leurs valeurs ainsi que leurs fiabilités.

Le GSC métier utilise trois types de règles. Les deux premiers, règles métier

légales et règles métier, sont fournis directement par les experts du domaine GSC.

Elles sont considérées comme la connaissance spécifique liée aux éléments contextuels qui affectent le règlement et le bon déroulement des activités de travail. Contrairement au deuxième type, les règles métier légales sont des règles dont la violation est strictement interdite par la législation d’une organisation par exemple. Le troisième type de règles non fournies par les experts correspond aux règles

inférées (ou connaissances générées liées au contexte). Ces règles sont extraites de

l’historique des situations valides.

Toutes ces règles sont une implication de la forme X implique Y, notée X Î Y, où X est une conjonction d’éléments contextuels provenant des différentes dimensions contextuelles et Y est un élément contextuel unique qui n’est pas présent dans X ou une fonction permettant de modifier la structure de la dimension contextuelle (suppression d’un ou plusieurs éléments). Enfin, dans notre approche, chaque règle possède une Priorité (valeur de type réel) transmise par les experts (pour les deux premiers types) ou calculée par le GSC (pour les règles inférées).

pascal.pinier@scd.ups-tlse.fr

4.3.1.3. Processus de mise en situation (MES)

Le processus de mise en situation (figure 2) est la partie la plus importante du GSC en termes d’objectifs atteints. Le processus MES gère la mise en relation des différentes dimensions contextuelles pour atteindre l’interprétation stable du contexte initial et ainsi créer des situations uniques dans le temps. Le MES permet soit de conserver les éléments contextuels des différentes dimensions de départ dans la situation sans les modifier, soit de les adapter en fonction des différentes interactions qui puissent exister entre eux. Nous assumons donc qu’une dimension contextuelle C (i.e. ses éléments contextuels) est adaptée au regard des autres dimensions contextuelles disponibles, c’est-à-dire que l’impact des autres dimensions contextuelles sur C est évalué. Autrement dit, une dimension contextuelle est adaptée selon son propre contexte (i.e. les autres dimensions contextuelles disponibles) : principe de récursivité du contexte.

Le processus MES doit garantir également la stabilité de la situation qui réside dans le résultat de la dynamique des interactions entre les différents éléments contextuels présents au moment de la création d’une nouvelle situation. Le MES applique successivement les règles sur les dimensions jusqu’à ce qu’un point de stabilité soit trouvé, c’est ce que nous appelons la situation. Elle est atteinte quand il n’y a plus de règles à appliquer ou lorsque l’on dépasse un grand nombre d’itérations.

Prenons un exemple afin d’illustrer le déroulement de la mise en situation. La figure 3 illustre un exemple simplifié de contexte initial. Ce contexte est composé des trois valeurs des dimensions contextuelles usager, tâche et environnement. L’usager possède trois éléments contextuels : son nom, son expérience du domaine et enfin son état émotionnel. De même, la tâche possède deux caractéristiques : le temps moyen requis pour son exécution ainsi que son objectif. Enfin, l’environnement est représenté par trois éléments contextuels : température, lieu et niveau sonore.

Figure 3. Exemple d’un contexte initial pour les SAI métier

Pour réaliser le cycle d’adaptation, le processus MES repose par exemple sur les deux règles suivantes :

R1 : Environnement.Bruit = « fort » ET Tâche. complexité=« difficile »

Î Usager.Etat=« stressé » (priorité = 0,9)

pascal.pinier@scd.ups-tlse.fr

Î Tâche.tempMin = 40min (priorité = 0,7)

Dans cet exemple, seule la règle R1 peut être appliquée dans une première itération impliquant sur l’usager adaptée un état émotionnel stressé avec une fiabilité de 0.9 (figure 4). Cette nouvelle valeur permet à la règle R2 d’être vérifiée. Ainsi, dans une deuxième itération la tâche adaptée aura une durée requise de 40 min au lieu de 20 min avec une fiabilité de 0.7 (figure 4). Grâce à cette information le SAI sait que le temps d’exécution de la tâche sera supérieur à son temps de référence (i.e. 20 min).

Figure 4. L’adaptation de la tâche T

Le processus MES peut arrêter la stabilisation du contexte après la deuxième itération puisque le point de stabilité est atteint, i.e. le processus MES n’a plus de règles pouvant être appliquées. La situation est donc générée (figure 5). Elle sera fournie par le GSC au SAI métier qui avait demandé sa création.

Figure 5. La situation finale générée par le processus MES

pascal.pinier@scd.ups-tlse.fr

4.3.1.4. Processus d’extraction de règles

L’ensemble de règles exploitées par le GSC doit évoluer pour prendre en compte l’historique du contexte. Pour cela, nous appliquons un procédé d’extraction de règles (figure 3) sur l’historique des situations valides enregistrées. Notre intérêt pour les situations passées est clairement justifié étant donné que dans ces situations nous avons toutes les informations sur les éléments du système. De plus, l’interaction des différents éléments contextuels au moment de l’adaptation peut elle-même causer un changement dans les valeurs de départ (exemple figure 5) ou dans les modèles initiaux des dimensions. En effet, apprendre des situations passées ne peut que donner à notre GSC une vue réaliste des interactions qui ont réellement eu lieu entre des éléments contextuels spécifiques pour créer une situation. C’est donc au fil du temps que le système devient plus efficace et pertinent. C’est-à-dire que l’adaptation des éléments devient plus représentative de la réalité, générant ainsi des situations fidèles à leur contexte, et par conséquent aux interactions de toutes ses dimensions.

Le processus d’extraction de règles se base sur l’algorithme a priori, algorithme pionnier d’extraction de règles d’association (Agrawal et al., 1993). À ce niveau, il obtient de simples corrélations entre des items (éléments contextuels) issues de différentes transactions (situations). Le processus alimente ainsi la base de règles avec les nouvelles règles inférées. Chaque règle inférée est classée selon sa priorité qui est sa confiance dans notre approche.

4.3.2. Engagement du GSC envers les SAI

L’objectif premier de notre GSC est la vérification de la validité des situations. Une situation valide est une situation qui ne contredit pas les règles métier légales. Le deuxième objectif du GSC est d’utiliser les règles pour combler un manque d’informations contextuelles. Le manque d’informations contextuelles peut survenir dans deux cas ; au moment de l’initialisation du système ou entre une situation t-1 et une situation t. Pour le deuxième cas, le GSC récupère les informations contextuelles de la situation précédente en plus des éléments contextuels mis à jour par l’application pour créer la nouvelle situation t.

Le troisième objectif du GSC est d’anticiper les événements et de les proposer automatiquement au SAI. Dans ce cas de figure, le SAI envoie les actions des usagers au GSC et le gestionnaire recommande des actions en utilisant des critères de similarité (raisonnement par cas sur les situations). Par exemple, pour une situation donnée, le GSC recommande un document ignoré par l’utilisateur et dont la lecture est présente dans le log des actions de toutes les autres situations similaires.

Le quatrième objectif est la mise à disposition du SAI des valeurs de tous les éléments contextuels ainsi que leurs fiabilités. Notons que ces dernières sont issues des priorités des règles utilisées pour obtenir la valeur de ces éléments contextuels.

pascal.pinier@scd.ups-tlse.fr

Le GSC a été mis en œuvre à travers un prototype qui s’articule aux SAI dans la

maintenance aéronautique. Ce champ d’application va nous servir de base pour

l’évaluation de notre approche. La caractéristique principale de ce domaine métier réside dans le fait que l’enjeu de fiabilité est fort et que ses tâches sont précisément définies. La garantie de cette fiabilité est étroitement liée au processus informationnels des usagers et au contexte dans lequel se déroule la tâche de maintenance. Dans ce cadre, le GSC proposé prend tout son sens.

5.1. Architecture globale du prototype implanté

Le prototype implémenté repose sur une architecture client-serveur schématisée dans la figure 6. Cette architecture est basée d’une part, sur le SGBD « Oracle 10g2 » pour le stockage des situations, des différentes actions et des éléments qui les composent et d’autre part, sur une interface client « Java 1.6 » afin de simuler des mises en situation et l’extraction de nouvelles règles.

Pour son initialisation, le prototype communique avec l’application qui lui fournit les règles ainsi que leurs structures et les dimensions contextuelles en XML.

Figure 6. Architecture globale du prototype

5.2. Expérimentation : fouille de règles basée sur des situations réelles

5.2.1. Protocole

pascal.pinier@scd.ups-tlse.fr

avec notre système. Cependant, pour combler cette limite nous avons collaboré avec les experts du domaine de la maintenance aéronautique pour étudier avec eux les éléments contextuels dans le domaine et pour ainsi avoir des données utiles pour nos expérimentations.

Dans un premier temps, nous avons validé les variables à modéliser dans notre prototype avec les experts du domaine. Dans notre approche, ces variables représentent les éléments contextuels des trois dimensions contextuelles (usager, tâche et environnement). Ensuite, nous nous sommes fondés sur des procédures de maintenance pour : (1) les étudier avec l’aide des experts du domaine ; (2) extraire d’éventuelles règles métier légales ; (3) les modéliser en utilisant le formalisme CTT (Paterno, 2000) ; (4) les transformer en XML exploitable par notre prototype.

En conséquence, nous avons pu simuler la création des situations avec des données issues de la maintenance aéronautique. Cependant, à part le contrôle de la validité des situations par rapport aux quelques règles métier légales que nous avons extraites des procédures, les situations générées ne reflètent pas l’originalité de notre démarche de création de situations.

Nous avons extrait les tâches de la thèse de Zafiharimalala (2011). L’auteur a travaillé dans le domaine de la maintenance aéronautique selon une perspective de psychologie cognitive et ergonomique. Plus exactement, Zafiharimalala a étudié la façon dont les opérateurs accèdent à l’information, en réalisant des études de terrain, fondées sur l’observation détaillée de techniciens effectuant leurs tâches. La thèse présente aussi des expérimentations sur l’utilisation des petits et grands écrans pour la recherche et la consultation de l’information, toujours en maintenance aéronautique.

Nous avons choisi une des tâches de maintenance fortement liée à l’accès à l’information : la tâche T1 et la sous-procédure AMM 32-41-11-000-006-B. La tâche T1 a pour objectif de trouver une procédure dans la documentation AMM

32-41-11-000-006-B Removal of the MLG Wheel et consultation de la sous-procédure AMM 32-41-11-020-075-A Preparation of the Wheel before Removal. La tâche T1

est une tâche complexe et son temps de référence est estimé à 291 secondes. Grace à notre collaboration avec Zafiharimalala nous avons pu récolter 23

situations réelles. Les éléments contextuels composant ces situations sont fondés

sur les variables pertinentes des trois dimensions de la maintenance présentées précédemment.

5.2.2. Résultat de la fouille de règles

pascal.pinier@scd.ups-tlse.fr

Malgré le nombre limité de situations, nous avons pu obtenir des règles qui convergent vers le travail de Zafiharimalala. En effet, en nous fondant sur ces 23 situations récoltées, nous obtenons une règle de priorité maximale (=1) admettant que tous les opérateurs considérés experts ne dépassent pas le temps de référence de la tâche quand elle est exécutée sur un PC (grand écran). Par contre, en utilisant un PDA (petit écran), les temps d’exécution des experts varient et dépassent dans quelques cas le temps de référence. Les opérateurs novices dans le domaine (élèves en BTS maintenance aéronautique), dépassent le temps de référence dans 66 % des cas. En outre, contrairement aux experts, les novices ne sont pas impactés par la taille des écrans utilisés.

L’explication de ces règles dans (Zafiharimalala, 2011) réside dans le fait que les experts ont l’habitude de travailler avec les PC pour réaliser cette tâche ce qui justifie les temps très courts de réalisation. Concernant l’utilisation des PDA, qui ne sont pas encore employés dans le domaine de la maintenance (au moment de l’étude), les experts rencontrent beaucoup de difficultés à exécuter cette même tâche routinière sur un autre support (PDA). Enfin pour les novices, vu leur manque d’expérience du domaine, le temps d’exécution d’une tâche est logiquement supérieur à la normale.

Nous avons pu extraire d’autres règles qui ne peuvent pas être considérées pertinentes vu le nombre limité de situations utilisées. Parmi les règles extraites ayant une confiance égale à 1, nous pouvons citer, à titre d’exemple, celle qui admet que les « experts » ayant une qualification « B2 » et effectuant une tâche

« exigeante » dans un niveau de luminosité « moyen » ne sautent pas des étapes.

Cependant, le support de cette règle est très faible (= 6/23). Ce qui veut dire que malgré sa confiance maximale, nous ne pouvons pas juger si cette règle est pertinente ou pas en nous appuyant uniquement sur notre ensemble de situations et plus précisément sur les 6 situations des experts. Nous aurons besoin de plus de situations dans lesquelles les usagers sont des experts pour déduire de la pertinence de la règle.

5.3. Application et objectifs des règles inférées

5.3.1. Utilisation orientée psychologie cognitive

5.3.1.1. Application des règles dans un contexte général

pascal.pinier@scd.ups-tlse.fr

réussite de la tâche) ou l’efficience (relativement au temps mis pour réaliser la tâche) au fur et à mesure du processus d’émergence. De nombreuses situations de travail, mais aussi de formation ou d’aide à l’usager pourraient exploiter ce système de règles.

5.3.1.2. Application des règles dans le contexte de la maintenance aéronautique Le système de règles a été appliqué au domaine de la maintenance aéronautique lors de son implémentation. Dans ce domaine à fort enjeu de sécurité, la perspective habituelle est de prescrire des règles sûres et de contraindre les opérateurs à les mettre en œuvre. Si au cours des 40 dernières années cette approche a eu un très grand succès, contribuant à la diminution spectaculaire du nombre d’accidents d’avions (faisant de ce mode de transport le plus fiable au monde), il semble aujourd’hui que les progrès se heurtent à une sorte de plafond de verre. Il y aura toujours de très rares cas d’opérateurs qui, exceptionnellement, ne suivent pas la procédure. Quand on analyse des raisons de ce refus (Zafiharimalala et al. sous presse) on constate que le manque de pertinence de l’information et le rapport coût perçu / bénéfice perçu en contexte défavorable de l’AI constituent probablement des causes majeures. Une information contextuelle semble donc pouvoir représenter un gain de pertinence important dans ce domaine.

5.3.2. Utilisation orientée système contextuel d’accès à l’information

5.3.2.1. Application des règles dans un contexte général

Le GSC utilise les règles inférées pour combler un manque d’informations contextuelles. Nous précisons que le GSC garde en mémoire toute l’activité de la réalisation d’une tâche entamée. C’est-à-dire, il conserve l’évolution des situations qui s’enchainent et qui sont liées par la même tâche initiale.

Le manque d’informations contextuelles peut survenir dans les deux cas suivants. Au moment de l’initialisation du système, c’est-à-dire, au moment de la création de la première situation de l’activité, il se peut qu’il manque d’informations contextuelles du fait par exemple d’une défaillance d’un des capteurs. Dans ce cas, GSC utilise les règles métier puis les règles inférées pour prédire les informations manquantes, pour ensuite créer la situation ; entre une situation t-1 et une situation t (ou deux états de la même situation), le GSC récupère les informations contextuelles de la situation précédente. Le GSC utilise donc les règles pour adapter les éléments contextuels et mesurer l’impact des informations contextuelles mises à jour sur le reste des éléments contextuels. Enfin, la situation est générée par le GSC.

pascal.pinier@scd.ups-tlse.fr

les situations). Ainsi, le GSC propose les actions les plus récurrentes pour des situations relativement similaires (i.e. qui possèdent des éléments contextuels ayant des valeurs similaires) au moyen des règles inférées. En effet, dès lors où une situation possède un sous-ensemble d’éléments contextuels (couples élément = valeur) correspondant à la prémisse d’une règle, la conclusion de cette règle peut être appliquée (cf. 4.3.1.2.). C’est en ce sens où le système est capable de reproduire ce qu’il a identifié comme régularité dans le passé. Par exemple, pour une situation donnée, le GSC peut recommander un document ignoré par l’utilisateur et dont la lecture est présente dans le log des actions de toutes les autres situations antérieures et similaires.

5.3.2.2. Application des règles dans le contexte de la maintenance aéronautique Nous pouvons dire que les outils de veille stratégique devront combiner les données opérationnelles avec des outils analytiques pour présenter des informations complexes et concurrentielles pour les planificateurs et les décideurs (experts des domaines). Les règles inférées des situations en sont un bon exemple qui fournit des informations d’analyse sur le paysage des données de la maintenance aéronautique. Quand elles sont bien analysées, les règles extraites permettent d’avoir une vue holistique des déroulements des activités des opérateurs pour améliorer leur efficacité et éviter d’éventuelles erreurs.

Des règles peuvent aussi être inférées des situations dites invalides. Elles sont stockées par le GSC afin de faire remonter l’information aux experts du domaine. Cela permettra de faire évoluer le SI en mettant à jour la base des règles légales. Nous pouvons donner l’exemple d’un circuit d’information découvert par l’usage récurrent d’un document « interdit » pour une catégorie d’usager.

6. Conclusion

Les travaux présentés dans cet article se situent dans le cadre général de la contextualisation des systèmes d’informations. Plus particulièrement, notre approche se concentre sur la fiabilité des informations contextuelles utilisées par les systèmes d’AI dans des contextes métiers. Contrairement à la plupart des travaux dans ce même cadre, nous ne nous intéressons pas à la manière avec laquelle ces systèmes adaptent leurs processus informationnels, mais plutôt au contrôle et à la gestion des informations contextuelles afin de leur garantir la photographie la plus fidèle possible du contexte à un instant donné. Pour cela, nous avons proposé un GSC générique fondé sur un ensemble de contributions qui portent sur quatre volets. Dans un premier temps, nous avons défini le contexte d’un objet ainsi que ses composantes. Nous avons aussi défini la situation comme étant la photographie la plus fidèle possible d’une interprétation stable du contexte à un instant donné. Par conséquent, nous avons proposé un GSC fondé sur une approche afin de générer les situations. L’approche permet au GSC, à travers le MES, d’injecter des connaissances supplémentaires dans les situations. Pour générer les situations, le

pascal.pinier@scd.ups-tlse.fr

MES porte davantage sur la dynamique de l’interaction entre toutes les dimensions contextuelles que sur la façon dont l’information est représentée. Par conséquent, nous avons ajouté à notre GSC le processus d’extraction de règles permettant d’avoir un feedback sur ces situations passées. Ainsi, notre approche offre des connaissances issues des régularités constatées dans les situations stockées. Ce sont ces connaissances mêmes que nous ne pouvons pas détecter directement au sein du contexte et qui pourraient être déduites uniquement à partir des relations entre les éléments contextuels dans diverses dimensions contextuelles.

De nombreuses perspectives s’offrent à la suite de nos travaux. La première perspective à long terme concerne l’aspect du contexte lui-même. Notre gestionnaire n’est pas encore adapté aux environnements ubiquitaires dans lesquels les tâches ne sont pas prescrites et l’information contextuelle change continuellement. Dans ce type d’environnement, le GSC doit être plus réactif et moins dépendant des règles métier. Une autre piste de recherche peut exploiter les différentes actions entreprises par un utilisateur durant ses diverses activités. Nous pouvons ainsi nous fonder sur les études existantes des analyses de traces pour mettre une modélisation de l’usage du système par les utilisateurs. Cela permettra aux systèmes d’améliorer leurs processus d’adaptation en fonction des modèles de traces des utilisateurs en analysant la chronologie de toutes les actions réalisées dans les situations.

Bibliographie

Abowd G. D., Atkeson C. G., Hong J., Long S., Kooper R., Pinkerton M. (1997). Cyberguide: a mobile context-aware tour guide. Wirel. Netw., 3(5), 421433. doi:10.1023/A:1019194325861

Agrawal R., Imielinski T., Swami A. (1993). Mining Association Rules between Sets of Items in Large Databases. ACM SIGMOD International Conference on Management of Data (p. 207216).

Anagnostopoulos C. B., Tsounis A., Hadjiefthymiades S. (2007). Context awareness in mobile computing environments. Wireless Personal Communications, 42(3), 445464. Arapakis I., Jose J. M., Gray P. D. (2008). Affective feedback: an investigation into the role

of emotions in the information seeking process. Proceedings of the 31st annual

international ACM SIGIR conference on Research and development in information retrieval (p. 395402). Singapore, ACM.

Bazire M., Brézillon P. (2005). Understanding context before using it. Modeling and Using

Context, 2940.

Belkin N. J. (2008). Some(what) grand challenges for information retrieval. SIGIR Forum,

42(1), 4754. doi:10.1145/1394251.1394261

Bettini C., Brdiczka O., Henricksen K., Indulska J., Nicklas D., Ranganathan A., Riboni D. (2010). A survey of context modelling and reasoning techniques. Pervasive and Mobile

pascal.pinier@scd.ups-tlse.fr

Bruegger P., Lalanne D., Lisowska A., Hirsbrunner B. (2009). Tools for designing and prototyping activity-based pervasive applications. Proceedings of the 7th International

Conference on Advances in Mobile Computing and Multimedia, p. 129136.

Brusilovsky P. (1996). Methods and Techniques of Adaptive Hypermedia. Consulté sur : http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.8848

Brusilovsky P., Millán E. (2007). User Models for Adaptive Hypermedia and Adaptive Educational Systems. The Adaptive Web, p. 353.

Byström K. (2002). Information and information sources in tasks of varying complexity. J.

Am. Soc. Inf. Sci. Technol., 53(7), 581-591. doi:http://dx.doi.org/10.1002/asi.10064

Byström K., Hansen P. (2005). Conceptual framework for tasks in information studies: Book Reviews. J. Am. Soc. Inf. Sci. Technol., 56(10), 1050-1061. doi:http://dx.doi.org/10.1002/asi.v56:10

Chaker H. (2012, juillet 24). Une approche de gestion de contextes métiers pour l’accès à

l’information. Université Toulouse 1 Capitole.

Costa P. D., Almeida J. P. A., Pires L. F., Van Sinderen M. (2007). Situation specification and realization in rule-based context-aware applications. Proceedings of the 7th IFIP WG 6.1

Int. conference on Distributed applications and interoperable systems, p. 32-47).

Dey A. K. (2001). Understanding and Using Context. Personal Ubiquitous Comput., 5(1), 47. Dourish P. (2004). What we talk about when we talk about context. Personal Ubiquitous

Comput., 8(1), 1930.

Göker A., Myrhaug H. (2008). Evaluation of a mobile information system in context. Inf.

Process. Manage., 44(1), 39-65. doi:10.1016/j.ipm.2007.03.011

Göker A., Myrhaug H., Bierig R. (2009). Context and information retrieval. Information

Retrieval: Searching in the 21st Century. John Wiley and Sons, Ltd, Chichester, UK.

Ingwersen P., Järvelin K. (2005). The Turn: Integration of Information Seeking and Retrieval

in Context (The Information Retrieval Series). Springer-Verlag New York, Inc.

Jameson A. (2001). Modelling both the Context and the User. Personal Ubiquitous Comput., 5(1), 2933.

Kelly D. (2006). Measuring online information seeking context, Part 1: Background and method. J. Am. Soc. Inf. Sci. Technol., 57(13), p. 17291739.

Li Y., Belkin N. J. (2008). A faceted approach to conceptualizing tasks in information seeking. Information Processing & Management, 44(6), 1822-1837. doi:http://dx.doi.org/ 10.1016/j.ipm.2008.07.005

Li Y., Landay J. A. (2008). Activity-based prototyping of ubicomp applications for long-lived, everyday human activities. Proceeding of the twenty-sixth annual SIGCHI

conference on Human factors in computing systems (p. 1303-1312).

Loke S. W. (2004). Representing and reasoning with situations for context-aware pervasive computing: a logic programming perspective. The Knowledge Engineering Review, 19(03), 213-233.

Pascoe J. (1998). Adding generic contextual capabilities to wearable computers. Proceedings

pascal.pinier@scd.ups-tlse.fr

Paterno F. (2000). Model-based design of interactive applications. Intelligence, 11(4), 2638. Pomerol J.-C., Brézillon P. (2001). About some relationships between Knowledge and

Context. Modeling and Using Context, 461-464.

Reichenbacher T. (2007). Adaptation in mobile and ubiquitous cartography. Multimedia

Cartography, Cartwright, William and Peterson ed., Springer Berlin Heidelberg, DOI

10.1007/978-3-540-36651-5_27, p. 383-397.

Schilit B. N., Adams N., Want R. (1994). Context-aware computing applications. First

Workshop on Mobile Computing Systems and Applications (p. 8590).

Schmidt A., Aidoo K. A., Takaluoma A., Tuomela U., Van Laerhoven K., Van de Velde W. (1999). Advanced interaction in context. Handheld and Ubiquitous Computing: First

International Symposium, Huc’99. Karlsruhe, Germany, September 27-29, Proceedings

(p. 89). Springer.

Schmidt A., Beigl M., Gellersen H. W. (1999). There is more to context than location.

Computers & Graphics, 23(6), 893901. doi:10.1016/S0097-8493(99)00120-X

Spink A., Cole C. (2001). Introduction to the special issue: Everyday life information-seeking research. Library & Information Science Research, 23(4), 301304. doi:10.1016/S0740-8188(01)00090-1

Stojanovic N. (2005). On the role of a user’s knowledge gap in an information retrieval process. Proceedings of the 3rd international conference on Knowledge capture, 83-90. doi:10.1145/1088622.1088638

Thomson G., Terzis S., Nixon P. (2006). Situation determination with reusable situation specifications. Pervasive Computing and Communications Workshops, 2006. PerCom

Workshops 2006. Fourth Annual IEEE International Conference on, p. 620-623.

Yau S. S., Huang D., Gong H., Yao Y. (2006). Support for situation awareness in trustworthy ubiquitous computing application software. Software: Practice and Experience, 36(9), 893-921.

Ye J., Dobson S., McKeever S. (2011). Situation identification techniques in pervasive computing: A review. Pervasive and Mobile Computing, vol. 8, Issue 1, February 2012, p. 36-66.

Zafiharimalala H. (2011). Etude ergonomique pour la consultation sur écran de petite taille

de la documentation de maintenance aéronautique. Thèse de doctorat en Psychologie.

Université Toulouse II – Le Mirail, Toulouse.