Le mémoire de fin d'études de Hassan El Allali explore l'utilisation des données des smartphones pour déduire le contexte dans les services géolocalisés, en mettant l'accent sur l'importance de la personnalisation des informations en fonction des besoins de l'utilisateur. Le document propose une approche innovante en utilisant des outils organisationnels comme l'agenda et la liste de tâches pour améliorer la pertinence des informations fournies par ces services. Il est structuré en deux parties, l'une consacrée à l'état de l'art des services géolocalisés et l'autre au développement d'un modèle théorique et d'une application pratique pour l'inférence du contexte utilisateur.

1. Faculté des sciences appliquées Année académique: 2008-2009
Utilisation des données d'utilisateur d’un SmartPhone pour la
déduction de contexte dans les services géolocalisés
Mémoire de fin d'études présenté par
Hassan EL ALLALI
Directeur de mémoire :
En vue de l'obtention du grade d'ingé-
Esteban ZIMANYI
nieur civil informaticien à finalité
spécialisée en ingénierie informatique

2. REMERCIEMENTS
Qu'il me soit permis de remercier ici mon directeur de mémoire, Monsieur Esteban ZI-
MANYI, pour sa disponibilité, son écoute et ses conseils avisés. Un énorme merci également
à Monsieur Serge Boucher, qui m’a, tout au long de cette année, guidé, conseillé, soutenu,
encouragé et relu. Je tiens à le remercier pour sa grande disponibilité même lors de ses dépla-
cements à l’étranger. Je tiens également à le remercier pour l’ambiance et le caractère très
amical qu’il a su donner à notre collaboration pour la transformer en une expérience aussi
agréable qu’instructive. Merci enfin à ma famille et mes amis, qui tout au long de la réalisa-
tion de ce mémoire, m'ont supporté et encouragé.
Je dédie ce travail de fin d’études à mon ami Rudy Nzimo qui vit une situation très dif-
ficile en ce moment et à qui je souhaite un dénouement heureux dans un futur très proche.
-2-

3. TABLE DES MATIERES
1. Introduction et Motivation ................................................................................- 5 -
2. Les Services Géolocalisés et l’utilisation du contexte .....................................- 7 -
A. Etat de l’art LBS ...............................................................................................- 7 -
I. Les services PUSH et PULL ........................................................................- 9 -
II. Les services apportés à l’utilisateur ............................................................- 10 -
III. GIS et LBS..................................................................................................- 12 -
IV. Catégories de systèmes LBS.......................................................................- 13 -
V. Exemples de systèmes LBS ........................................................................- 17 -
VI. Le processus type et les composants d’une requête ...................................- 23 -
B. La gestion de contexte ....................................................................................- 31 -
I. Définition ....................................................................................................- 31 -
II. Les services utilisant le contexte ................................................................- 32 -
III. Utilisation des Ontologies et du web sémantique .......................................- 33 -
IV. Modélisation du contexte............................................................................- 35 -
V. Les différents types de contexte (spatial, temporel, environnemental,
socioculturel…) .............................................................................................................- 36 -
VI. Inférence de contexte ..................................................................................- 39 -
VII. Profil des utilisateurs...............................................................................- 40 -
VIII. Modèle de données .................................................................................- 43 -
IX. La protection de la vie privée .....................................................................- 43 -
C. Notre Projet ....................................................................................................- 44 -
3. Travail pratique ...............................................................................................- 45 -
A. Introduction ....................................................................................................- 45 -
B. Vers une structure plus sémantique ................................................................- 45 -
I. Agenda ........................................................................................................- 45 -
II. Carnet d’adresse .........................................................................................- 51 -
III. Liste de tâches (ToDo List) .........................................................................- 52 -
C. Scénario d’une journée ...................................................................................- 53 -
I. Scénario et Agenda .....................................................................................- 54 -
II. Contexte à chaque instant ...........................................................................- 54 -
III. Comportement intelligent idéal du GSM....................................................- 55 -
D. Etablissement d’un modèle de gestion de contexte ........................................- 58 -
-3-

4. I. Idées de bases et inspirations ......................................................................- 58 -
II. Design .........................................................................................................- 59 -
E. Implémentation pratique ................................................................................- 78 -
I. Scénario Simplifié ......................................................................................- 78 -
II. Structure et comportement du programme .................................................- 80 -
4. Conclusion et travaux futurs...........................................................................- 85 -
A. Contributions ..................................................................................................- 85 -
B. Travaux futurs ................................................................................................- 86 -
5. Bibliographie ....................................................................................................- 87 -
6. Annexes .............................................................................................................- 90 -
Code source de l’application ...................................................................................- 90 -
Classe Contexte ....................................................................................................- 90 -
Classe Actions ......................................................................................................- 91 -
-4-

5. 1.INTRODUCTION ET MOTIVATION
L’arrivé d’Internet à la fin des années 1980 a révolutionné la manière de communiquer
de l’homme. En même temps, des progrès considérables étaient achevés dans le monde de
l’électronique où les transistors et les ordinateurs continuaient à gagner en puissance et en
miniaturisation. L’apparition des téléphones portables a permis aux utilisateurs de s’appeler
depuis n’importe quel endroit et pas seulement depuis des postes fixes. Le concept de mobilité
est alors apparu progressivement dans le monde la communication. Pendant ce temps, la com-
plexité du monde augmentait rapidement avec la quantité d’informations disponibles sur
internet et les utilisateurs voulait y accéder depuis n’importe où. Il était alors temps de rendre
Internet mobile.
C’est à ce moment là que les téléphones portables ont arrêté de transporter seulement
de la voix. Ils ont commencé a aussi transporté des données numériques grâce à l’invention,
d’une part, des réseaux sans fils de données de type GPRS et UMTS et, d’autre part, des appa-
reils mobiles plus évolués permettant la navigation sur internet. En même temps, Ces
appareils ont commencé à contenir de plus en plus de capteurs qui collectent des informations
sur l’utilisateur et sa situation à un moment donné pour ensuite mieux le servir et répondre à
ses exigences. La miniaturisation des appareils permettait à l’homme d’avoir tout à coup di-
vers périphériques électroniques autour de lui communiquant sans fils avec une intelligence
de plus en plus distribuée. Très vite nous avons vu apparaître, grâce à cette nouvelle informa-
tique, de nouvelles inventions surprenantes telles que les salles de réunion intelligentes, le
suivi médical continu, la surveillance de facteurs environnementaux en temps réel et, plus
particulièrement, les services géolocalisés.
Ces services, que nous allons particulièrement étudier dans ce projet, visent à fournir à
l’utilisateur l’information exacte dont il a besoin au moment même où il en a besoin en fonc-
tion de sa localisation géographique. Cette information est relative à sa situation instantanée et
à l’endroit où il se trouve. Cette information est censée lui être utile directement dans la situa-
tion où il l’a demandée. Cette contrainte de pertinence de l’information pose d’importants
défis à relever pour arriver à exactement satisfaire les besoins d’information de l’utilisateur
n’importe où et n’importe quand. L’un des défis majeurs à relever est de faire comprendre, au
service qui fournira l’information à l’utilisateur, la situation dans laquelle se trouve ce dernier.
Cette pratique est communément appelée la déduction de contexte de l’utilisateur. En effet,
pour mieux comprendre les besoins de l’utilisateur, l’application a besoin de connaitre un
maximum d’informations sur ce dernier. C’est ici qu’entrent en jeu les différents capteurs et
technologies rassemblés sur l’appareil mobile. Ils essayeront d’assembler autant
d’informations que possible sur le contexte de l’utilisateur afin de les traiter et d’en tirer une
information de contexte pertinente utilisable par le service géolocalisé. Des exemples de cap-
teurs sont par exemple un capteur de localisation géographique ou un accéléromètre.
Malheureusement, de bonnes règles de déduction, de description et de capture d’informations
de contexte restent encore à inventer malgré les innombrables efforts de recherche en la ma-
tière.
-5-

6. Dans ce travail, nous allons nous intéresser à une nouvelle source de déduction de con-
texte non encore explorée. Nous essayerons d’utiliser les informations disponibles dans les
outils organisationnels de l’utilisateur (agenda, carnet d’adresse, liste de tâches) pour inférer
le contexte de l’utilisateur. Pour cela, nous établirons et développerons un modèle et une ap-
plication qui inférerons le contexte de l’utilisateur à un instant donné pour exécuter ensuite
des actions rendant service à l’utilisateur.
Ce rapport est organisé en deux parties. Dans la première nous verrons un état de l’art
des services géolocalisés développés dans le monde jusqu’à présent avec une explication sur
l’architecture générale de ces systèmes. Ensuite nous nous intéresserons à la notion de con-
texte d’utilisateur du point de vue de l’informatique mobile pour montrer son importance au
bon fonctionnement des services géolocalisés. La seconde partie sera consacrée au travail
pratique. Dans cette partie, nous commencerons par proposer une structure plus sémantique
des outils organisationnels de l’utilisateur afin de les rendre plus lisibles par des applications
de déduction de contexte. Nous établirons ensuite un scénario d’une journée d’un utilisateur
lambda pour étudier l’évolution de son contexte et établir le comportement idéal que devrait
adopter son appareil mobile en conséquence. A partir de cette étude, nous construirons un
modèle théorique capable d’inférer le contexte de l’utilisateur afin de reproduire ce compor-
tement idéal. Enfin, nous développerons une application basée sur ce modèle théorique et qui
en reproduira quelques fonctionnalités.
-6-

7. 2. LES SERVICES GEOLOCALISES ET
L’UTILISATION DU CONTEXTE
A. ETAT DE L’ART LBS
Durant les deux dernières décennies, nous avons assisté à l’apparition dans le marché
public de la téléphonie portable d’un côté puis de l’internet de l’autre. Ce sont des phéno-
mènes qui ont révolutionné la vie humaine et plus particulièrement ses modes de
communications. Durant les dix dernières années, ces deux mondes se sont rapprochés petit à
petit pour ne plus en former qu’un. En effet on voit de plus en plus de gens qui utilisent leurs
appareils mobiles pour accéder à internet, communiquer ou chercher des informations.
En effet, l’internet de seconde génération est entrain de fondamentalement changer
l’utilisation du web et la communication entre des groupes de personnes par exemple. Le Web
2.0, encore appelé Web interactif ou Web communautaire est l’ensemble des interfaces web
qui permettent aux utilisateurs d’interagir tant avec le contenu des pages qu’avec les autres
internautes. Les appareils mobiles nous permettent de visualiser des informations sur des
événements tels que des séances de cinéma, des fêtes et des concerts. Ils permettent aussi
d’obtenir des informations sur des endroits via par exemple des cartes géographiques de
villes, ou des adresses de restaurants, musées, hôpitaux ou autres.
C’est ici qu’interviennent les services géolocalisés, aussi appelés LBS, de l’anglais Lo-
cation-Based Services. <+Définition, i.e. service informatique exploitant la position
géographique de l’utilisateur.>. Ces derniers sont justement les services informatiques qui
permettront à l’utilisateur d’avoir cette information de manière exacte, instantanée et perti-
nente. Ces derniers visent à augmenter le confort et la qualité de vie de l’utilisateur en
essayant du mieux que possible de répondre à ses besoins en informations à tout instant.
Considérons un exemple simple d’utilisation de ces services. Supposons que l’on est
voiture et que le niveau de carburant est bas. Nous cherchons une pompe à essence. Chercher
une « pompe à essence » sur internet retournerait toutes les pompes à essence du monde. Il
faudrait rajouter d’autres critères pour affiner la recherche. Un bon choix serait par exemple
de rechercher les pompes à essence qui sont à proximité de la position géographique actuelle
de l’utilisateur. Un autre critère considèrerait l’heure actuelle éventuellement nocturne et les
heures de fermetures des stations d’essence. Un critère additionnel serait par exemple la re-
cherche de bio carburant qui n’est pas disponible dans toutes les pompes à essence.
Ce type de recherche avancée est en fait le type de recherche qui pourrait être automati-
quement effectué par des LBS.
Voici maintenant deux tentatives de définitions pour les services géolocalisés.
-7-

8. Définition 1 : Les services géolocalisés sont des services d’informations disponibles via
des appareils mobiles avec la possibilité d’utiliser la géolocalisation de l’utilisateur deman-
deur de ces services. (1)
Une seconde définition assez similaire donnée par le consortium international Open-
Geospatial en 2005 :
Définition 2 : Un service IP sans fil qui utilise l’information géographique pour ré-
pondre à un utilisateur mobile. Toute application qui exploite la position d’un terminal
mobile. (2)
D’après ces définitions on peut voir les LBS comme l’intersection de trois technolo-
gies :
• Les technologies mobiles d’information comme les appareils portables et leurs
applications.
• Les technologies internet
• Les bases de données spatiales ou les systèmes d’information géographique
(GIS) que nous définirons plus loin.
La figure suivante illustre mieux cette intersection.
FIGURE 1 - LES LBS, UNE INTERSECTIN DE TECHNOLOGIES
-8-

9. Historiquement, le concept de services d’informations géolocalisés n’est pas vraiment
nouveau. Des comparaisons ont été faites avec par exemple, les affiches de concerts dans une
ville qui sont restreints juste aux habitants de la ville ou, plus subtil en encore, les post-it lais-
sés par une personne à une autre dans un endroit bien défini tel que la seconde ne le lira qu’à
un moment, endroit ou contexte bien défini (à une page précise d’un livre par exemple). Les
panneaux de signalisation sur les routes ou aux carrefours indiquent les grandes directions à
suivre par exemple par un automobiliste qui cherchent son chemin. La majeure différence par
rapport aux LBS est que ces services historiques sont beaucoup plus statiques que les LBS. En
effet, les bases de données des LBS évoluent au cours du temps, avec les besoins, le contexte
et la localisation de l’utilisateur. Ce sont des informations électroniques facilement et automa-
tiquement modifiables depuis n’importe où alors que les systèmes historiques nécessitent le
déplacement de l’être humain et ne sont mises à jour que très rarement.
I. LES SERVICES PUSH ET PULL
On peut classifier les services géolocalisés en deux catégories : les services de type push
et les services de type pull. Commençons par définir ces deux termes dans le domaine des
services de télécommunications.
Les services Push sont les services où la requête pour une transaction donnée est initiée
par le serveur ou par le fournisseur. Ce sont typiquement des services du style subs-
cribe/publish où l’utilisateur s’inscrit à un éditeur ou un fournisseur et dès qu’un nouveau
contenu est disponible, ce dernier l’envoie à l’utilisateur. Les publicités sur internet et les
abonnements aux flux RSS font partie de cette catégorie.
Les services Pull sont, par opposition aux premiers, ceux où c’est le client/utilisateur
qui initie la communication et puis ensuite le client répond. Un exemple est les requêtes de
pages web par l’utilisateur aux serveurs ou encore les clients e-mails qui simulent un service
push par envoi périodique de requêtes aux serveurs pour demander si un nouvel e-mail est
arrivé.
Dans le cadre des LBS, les services Push peuvent être activés par un événement comme
par exemple à l’entrée d’une zone géographique. On peut donc par exemple recevoir la liste
des concerts à l’entrée dans une nouvelle ville. Les services Push pourraient aussi être activés
automatiquement à une certaine heure comme un utilisateur abonné aux informations régio-
nales qu’il reçoit périodiquement sur son appareil mobile. Un autre type d’information que
l’on peut recevoir sont les prévisions météorologiques pour les prochaines heures dans la ré-
gion où l’on se trouve par exemple. Ceux-ci sont des exemples pour des services demandés
explicitement par l’utilisateur. Il y a aussi les services non demandés par l’utilisateur comme
des publicités de magasin lorsqu’on entre dans un centre commercial. Ici, comme les services
doivent être personnalisés au maximum, les services Push nécessitent de connaître le profil de
l’utilisateur pour lui adresser des informations pertinentes pour par exemple ne recevoir de
publicité que des magasins convergents avec ses centres d’intérêts. Il est clair que ce type de
messages peut très vite s’avérer irritant pour l’utilisateur qui pourrait recourir à des solutions
comme désactiver totalement ce type de messages.
Les services Pull, quant à eux, sont de nouveau séparés en deux sous-catégories.
-9-

10. a. Les services fonctionnels comme demander un taxi ou une ambulance en un seul
clic.
b. Les services d’information comme par exemple demander le bar asiatique le
plus proche ou encore comme dans notre exemple, la pompe à essence avec du
biocarburant la plus proche.
C’est une utilisation qui se rapproche plus de la navigation classique sur internet à la
différence près que cela se fait par un terminal mobile et qu’en plus des données que
l’utilisateur envoie au services explicitement, l’appareil mobile envoie aussi des données du
profil et de la géolocalisation de l’utilisateur aux LBS.
II. LES SERVICES APPORTES A L’UTILISATEUR
L’idée principale derrière les LBS est d’améliorer la qualité de vie de l’utilisateur en lui
rendant des services à haute valeur informationnelle et pertinents pour lui à l’instant précis où
il en a besoin. En pratique, cela commence par répondre à des questions comme : Où suis-je ?
Où sont mes amis/collègues/familles ? Quelles activités ou commodités sont à proximités ?
De quoi ai-je besoin maintenant ? De quoi aurais-je besoin bientôt ? Qu’est ce qui pourrait
être intéressant pour moi ? Etc.
Lorsque des personnes se trouvent dans un environnement nouveau qu’ils ne connais-
sent pas, leurs besoins et comportements sont généralement prévisibles. Ils doivent se loger,
se nourrir, retirer de l’argent liquide, se déplacer, peut être se soigner etc. S’ils font du tou-
risme, ils veulent visiter des attractions, visiter la ville, trouver un bureau de change.
Nous allons dans cette section expliciter les types d’activités ou les actions d’utilisateur
où les LBS jouent des rôles essentiels pour ensuite donner des exemples de systèmes LBS
déjà en place.
À une activité est associée une série d’actions exécutées par un utilisateur dans le but
d’accomplir un certain objectif comme par exemple résoudre un problème ou faire accomplir
une tâche. Dans notre cas, les activités sont par exemple l’orientation, la navigation, trouver
d’autres personnes ou objets. Ces activités font appel à des systèmes de localisation géogra-
phiques et Reichenbacher (4) a identifié cinq questions mobiles élémentaires pour répondre
aux besoins d’un utilisateur.
Localisation : La première question élémentaire serait de répondre à la question : Où
suis-je par rapport à quelqu’un ou quelque chose d’autre par exemple ?
Recherche : On peut rechercher géographiquement, des personnes, des objets ou des
événements.
Navigation : Une fois localisé, on a besoin d’être guidé vers l’endroit que l’on re-
cherche.
Identification : On pourrait avoir besoin d’informations additionnelles sur un endroit
telle que les heures d’ouverture et fermeture d’un restaurant ou encore ses spécialités ce soir.
- 10 -

11. Vérification : On voudrait peut-être vérifier aussi s’il y a des activités intéressantes aux
alentours de cet endroit. Cette dernière question de vérification inclut, en plus de données
géographiques, les données temporelles des activités ainsi que les préférences de l’utilisateur.
La vérification a proprement dite se fait lorsque l’utilisateur a déjà sélectionné des activités
dans le passé auxquelles il souhaite se rendre puis veut maintenant vérifier si l’horaire, le lieu
ou la validité de ces événements sont toujours inchangées.
Le tableau suivant représente ces différents types de services avec les questions qu’ils
posent ainsi que les opérations géo-spatiales qu’ils impliquent.
Action Questions Opérations
Orientation et localisation Où suis-je ? Positionnement
Où est X ?
Navigation : Navigation dans Comment se rendre Positionnement, rou-
l’espace et tracé d’un itinéraire àX? tage
Recherche : recherche d’objet et Où est le Y le plus Positionnement, cal-
de personnes proche/ le plus per- cul de distance,
tinent ? établissement de
relations
Identification : Identification de Qui est à cet endroit Recherche, extrac-
personne, de places, là ? tion et comparaison
d’événements Comment est cet de paramètres
endroit ?
Vérification d’événements : Que se passe-t-il à Recherche et identi-
Vérifier leur état et leur validité proximité de X ? fication
TABLEAU 1 - LES DIFFERENTS TYPES DE LBS
Nous pouvons remarquer que la localisation et la navigation ont besoin principalement
d’informations géographiques alors que l’identification et la vérification ont besoin
d’avantages d’informations de différents types comme nous le décrivons ici-bas :
Des données statiques d’informations publiques telles que les pages jaunes
par exemple. Ces informations restent relativement statiques au cours du temps
et sont bien sûr disponibles via d’autres canaux de communications comme les
livres et les catalogues.
Des données locales variables qui peuvent changer pendant que l’utilisateur se
déplace et qui doivent donc être mises à jour régulièrement sur l’appareil mo-
bile. Les exemples les plus classiques sont les informations météorologiques, les
conditions de trafic routier, les changements d’horaire de dernière minute des
- 11 -

12. événements. En plus de ces informations, l’utilisateur aurait besoin de conseils
pour réagir au mieux à ces changements. En cas d’averse ou d’orage, si
l’utilisateur est à pied dans la rue, on pourrait lui proposer des chemins couverts
ou souterrains, ou encore le conseiller de se mettre à l’abri en cas de tempête
violente ou tornade. Dans le cas de problème de trafic ou de densité accrue sur
certains axes, le système pourrait proposer à l’utilisateur de passer par un autre
chemin et lui indiquer la meilleure alternative. Dans le cas où le train que
l’utilisateur devait prendre a été retardé ou annulé, le système pourrait proposer
d’autres moyens de transport qui mèneraient vers la même destination et guider
l’utilisateur jusqu’à cette alternative. Dans le cas où une heure de début
d’événement a été avancé, prévenir l’utilisateur et si nécessaire proposer une al-
ternative de déplacement plus rapide pour arriver à temps.
Des informations de sécurité : Cette catégorie regroupe toutes les informations
sur l’état des routes, les prévisions de tempêtes pour les randonneurs par
exemple, les dangers de chute de rochers ou de pierres sur les routes etc. Ces in-
formations sont utiles pour les navigateurs en mer, les voyageurs, les
randonneurs etc. Des services associés pourraient être appelés d’urgence en cas
de problème comme une tempête en mer, une panne de voiture sur la route etc.
Des informations personnelles : Ce type d’information par contre est envoyé
dans l’autre sens. C’est l’utilisateur qui envoie des informations aux LBS pour
enrichir leurs bases de données et finalement améliorer les services que ces der-
niers proposent aux autres utilisateurs. Un exemple serait des randonneurs qui
partagent un nouveau tracé de randonnée qu’ils viennent d’effectuer ou encore
un nouveau point de danger de chute de rocher qui n’était pas répertorié jus-
qu’ici. Ceci se rapproche beaucoup de la philosophie du Web 2.0 où les
utilisateurs sont appelés eux-mêmes à créer le contenu que les autres utilisateurs
consultent et utilisent. Cependant, vu la nouveauté du concept et le manque
d’information sur comment ces données personnelles sont utilisées, traitées et
protégées, il existe de grandes rétissances chez les utilisateurs à partager des in-
formations comme leur type d’activités, leurs localisations et leur identité. Nous
discuterons de cet aspect de la vie privé au prochain chapitre.
III. GIS ET LBS
Nous avons vu au chapitre précédent que les principales fontctions des LBS nécessite de
connaitre la position géographique de l’utilisateur. Pour répondre à ce besoin, intéressons
nous maintenant aux systèmes d’information géographique. Au sens strict, ce sont tous les
systèmes qui intègrent, sauvegardent, modifient, analysent, partagent et affichent des données
géographiques. Dans un sens plus général, les applications GIS qui permettent à un utilisateur
de créer des requêtes et recherches, qui analysent des informations spatiales, modifient des
données ou des cartes et affichent le résultat de toutes ces opérations. (3)
Le premier système d’information géographique a été développé en 1962 à Ottawa dans
l’Ontario. Il a été développé par le département fédéral de la sylviculture et du développement
- 12 -

13. rural qui l’a surnommé le CGIS pour « Canada Geographic Information System » . Il était
utilisé pour stocker, analyser et manipuler des données issues de l’inventaire des terres cana-
diennes. Ce projet connut un franc succès et son développeur Dr. Roger Tomlinson fut
surnommé le « Père des GIS » principalement pour son utilisation innovante de la technique
de superposition de couches de données géographiques convergentes pour l’étude spatiale. Ce
projet fut étendu jusqu’à couvrir l’ensemble du territoire canadien mais ne fût jamais com-
mercialisé au grand public.
D’autres système GIS ont ensuite vu le jour durant les trente dernières années et ont été
développé sur des stations UNIX et même sur des ordinateurs personnels. À la fin du siècle
une évolution rapide de ces systèmes a été consolidée et standardisée sur quelques plate-
formes et les utilisateurs ont peu à peu commencé à exporter le concept de GIS sur internet.
Finalement, depuis quelques années, plusieurs applications GIS open sources sont disponibles
gratuitement sur internet et permettent d’effectuer quelques tâches comme tracer un itinéraire
entre deux points sur une carte par exemple ou encore estimer la durée de ce trajet en voiture.
On voit qu’en comparaison avec les LBS, les GIS ont une relativement différente ori-
gine ainsi qu’un groupe d’utilisateurs différent. Les GIS sont développés depuis assez
longtemps et destinés à des professionnels des applications géographiques alors que les LBS
sont apparus assez récemment avec le développement des services mobiles principalement
pour le grand public. D’un autre côté, les GIS sont développés pour des machines à haute
puissance de calcul et pour des requête assez lourdes alors que les LBS sont conçus justement
pour des appareils mobiles à capacités de calcul et taille d’écran d’affichage réduits.
La relation entre les LBS et les GIS représenté Figure 1 est que les LBS ont besoin des
GIS pour répondre à des questions telles que :
• Où suis-je ?
• Qu’est ce qui est à proximité ?
• Comment pourrais-je y aller ?
En effet répondre à ces questions est une étape nécessaire non suffisante aux LBS pour
répondre aux différentes requêtes de l’utilisateur. Pour reprendre l’exemple précédent de la
pompe à essence, il est en effet nécessaire de connaitre la position de l’utilisateur pour pou-
voir rechercher les pompes à essence les plus proches.
IV. CATEGORIES DE SYSTEMES LBS
Une tentative de classement des LBS en plusieurs catégories et sous catégories a été
faite. Ce classement n’est pas complet mais il englobe la majorité des services actuels. Les
neuf grandes catégories :
• Navigation : cette catégorie regroupe tous les services qui aident l’utilisateur à
se déplacer en extérieur comme en intérieur du point où il se trouve jusqu’à un
endroit donné. On retrouve aussi dans cette catégorie des services plus avancés
- 13 -

14. qui tiennent en compte la densité du trafic et le guidage à l’intérieur d’un grand
parking.
• Information : dans cette catégorie on range toutes les applications qui permet-
tent à l’utilisateur de demander et d’obtenir des informations comme les
informations sur les restaurants, bars et club à proximité, les hôpitaux et phar-
macies etc. Il peut aussi demander des informations touristiques sur une région
ou encore les meilleurs endroits à visiter dans une ville. Cette catégorie regroupe
aussi les pages jaunes ainsi que les guides de shopping des magasins avoisinants.
• Localisation : Cette catégorie permet le suivi d’un objet ou d’une personne et
d’avoir sa position par rapport à l’utilisateur de manière continue. Cette applica-
tion serait par exemple utile pour une société ayant des employés devant
exécuter des missions à l’extérieur par exemple ou encore une société qui veut
garder trace des colis quelle envoie à ses clients pendant tout leur trajet.
• Les jeux : On peut classer les différents jeux qui sont proposés à l’utilisateur en
fonction de son âge et ses goûts et son activité actuelle. Par exemple lorsqu’il est
dans le train pour un long trajet. Un autre type de jeu plus particulier est apparu
avec l’apparition du GPS et qui continue avec les LBS est le géocaching (5) .
Cette activité consiste à cacher un contenant hermétique contenant des objets
quelconques dans différents endroits du monde (222 pays différents). Le but du
jeu étant de dissimuler ces objets ou les retrouver. Plusieurs centaines de milliers
d’objets sont listés sur différents sites web spécialisés.
• Les urgences : cette catégorie représente les services qui consistent à appeler les
services de secours les plus proches en un seul clic ou encore les services qui
permettent de passer ces appels automatiquement en cas d’accident graves.
L’assistance à personnes âgées est aussi un domaine d’application.
• La publicité : Les services qui font la publicité de produits ou services à vendre
dès que l’on est à proximité d’un magasin sous forme d’alertes et de promotions.
• La facturation : une application possible pour ce service serait le paiement au-
tomatique du péage à partir de l’appareil mobile du conducteur par exemple. Un
autre service émergent est la facturation différentielle par rapport à la location.
Pour les opérateurs de télécommunications, les appels cellulaires à partir de cer-
taines zones sont plus coûteux que ceux depuis d’autres zones. Néanmoins, ils
ne peuvent pas facturer différents tarifs à l’utilisateur en fonction de sa géoloca-
lisation sans l’en informer efficacement et clairement. Maintenant, grâce aux
LBS, l’utilisateur est informé de la zone dans laquelle il se trouve et par consé-
quent du coût de l’appel qu’il va effectuer. Les opérateurs peuvent donc
appliquer des tarifs différenciés, ce qui augmente leur compétitivité. On peut
donc différentier le domicile de l’utilisateur ou les appels mobiles seront dirigés
vers le fixe de manière transparente. Même remarque pour la zone du lieu de
travail. On peut aussi différentier des zones denses comme les centres villes où
les antennes sont saturées et donc facturées plus chères et les zones dites vertes
- 14 -

15. où il n’y a pas beaucoup d’utilisateurs et par conséquent le coût de communica-
tion est moins cher. (6)
• La gestion générale et diverse : On pourrait imaginer toutes sortes
d’applications pour la gestion de ressources diverses comme par exemple des lo-
caux vides ou occupés ou une infrastructure donnée, une flotte de bateau ou un
groupe de véhicule et leur localisation ainsi que leur planning etc.
• Les loisirs : Une dernière catégorie rassemble diverses applications comme la
messagerie instantanée non professionnelle, ou encore des applications qui per-
mettent de retrouver un ami sur une carte. Nous avons assisté il y a quelque
semaine au lancement controversé de l’application Latitude de Google. (7) Cette
application permet aux utilisateurs de suivre en temps réel la position de leurs
amis inscrits aussi à ce service. La controverse a été créée par la protection de la
vie privée et sur le fait que la société pouvait garder trace de tous les déplace-
ments de ses utilisateurs.
La figure suivante est un schéma récapitulatif de toutes ces catégories avec des
exemples d’applications pour chacune.
Catégories Exemples d’application
d’applications
Navigation Sur les routes, à l’intérieur de bâtiments, dans un parking, infor-
mation sur le niveau de trafic routier
Information Recherches d’établissement diverses, restaurants, banques,
pompes à essence etc. les informations touristiques, la publicité
Localisation Se localiser géographiquement, le suivi d’objets et d’autres per-
sonnes
Jeux Jeux vidéo, géocaching
Urgences Accidents, personnes âgées, personnes handicapées
Publicité Promotions sur services et produits à proximité
Facturation Paiement automatique au péage routier, facturation différentielle
d’appels téléphoniques
Gestion Gestion de locaux, de véhicules, de personnes, messagerie instan-
tanée
Loisirs Suivi d’amis, messagerie instantanée
TABLEAU 2 - CATEGORIES ET EXEMPLES DE SERVICES LBS
Après avoir fait ce classement et introduit les services push et pull, nous allons mainte-
nant prendre quelques catégories et classer ces services selon 3 paramètres :
Le fait que ce soit plutôt des services push ou pull.
Le fait que ce soit des services actifs plutôt en intérieur ou en extérieur.
Le degré de pertinence et de précision de ces services.
- 15 -

16. Commençons par la catégorie navigation. Ces services sont généralement des services
pull du fait que c’est l’utilisateur qui demande explicitement aux LBS de le guider vers une
destination donnée. Il existe des navigations en extérieur comme sur les routes par exemple
comme des navigations en intérieur comme dans des grands bâtiments par exemple. Ces ser-
vices sont généralement très précis et fournissent de relativement bons résultats. Dans la
même catégorie on peut trouver des services un peu moins précis comme le guidage à
l’intérieur d’un parking. Cette imprécision peut être due au haut degré de précision de locali-
sation nécessaire et non encore atteint pour ce genre d’application. Un autre service de
navigation est la gestion de trafic. La différence majeure avec les services précédents est le
fait que ce service soit de catégorie push puisque le système nous informe spontanément de
problèmes éventuels de trafic sur notre chemin. La figure suivante résume la situation des
services de navigation. Notons que sur l’axe vertical nous avons le degré de précision et que
sur l’axe horizontal nous avons le fait que ce soit plus un service utile en intérieur ou en exté-
rieur. Le code de couleur des bulles est le suivant. Le rouge représente les services push alors
que le vert représente les services pull.
FIGURE 2 - ANALYSE DES LBS DE NAVIGATION
Étudions une seconde catégorie de LBS, la publicité et la facturation. Une particularité
de cette catégorie est que tous les services sont des services push. La facturation des péages
d’autoroute est un service très précis pour des raisons évidentes. La publicité est un service
relativement moins précis actif particulièrement lorsqu’on passe à côté des commerces dans la
rue. La facturation des appels sensible à la géolocalisation nécessite encore moins de préci-
sion vu que les zones tarifaires ne sont pas déterminées au mètre près. Contrairement aux
premiers services qui sont essentiellement actifs en extérieur, cette dernière est aussi bien ac-
tive en intérieur qu’en extérieur. La figure suivante résume la situation de la même manière
que précédemment.
- 16 -

17. FIGURE 3 - ANALYSE DES LBS DE FACTURATION ET DE PUBLICITE
V. EXEMPLES DE SYSTEMES LBS
a. Les services de navigation
Les systèmes de navigation ont vu le jour bien avant l’apparition des LBS. En effet, le
premier système de localisation et de navigation est le GPS (Global Positioning System). Ce
dernier est un système utilisant une constellation de 24 à 32 satellites à orbites géostation-
naires pour fournir un géolocalisation précise aux possesseurs de récepteurs GPS. Le système
a été développé par le département de la défense américaine pour des applications militaires et
a une précision de l’ordre du mètre. Il a été ensuite mis à disposition du grand publique pour
le voir envahir toute sortes de véhicule ou d’objets mobiles comme les voitures et les avions.
La figure suivante représente une interface classique d’un navigateur GPS dans une voi-
ture par exemple. L’écran se compose d’une carte d’un réseau routier urbain avec l’itinéraire
total proposé tracé en rouge ainsi que la prochaine étape immédiate sous forme de flèche
verte.
- 17 -

18. FIGURE 4 - INTERFACE D'UN NAVIGATEUR GPS
Ce n’est que par la suite lors des dernières années que l’on a vu ces systèmes débarquer
sur nos téléphones mobiles et smart phone avec des applications pour nous guider sur notre
chemin jusqu’à notre destination.
Il est cependant nécessaire de faire une différenciation à ce stade. La localisation par té-
léphonie mobile utilise deux techniques de localisation différente. Soit l’appareil est équipé
d’une antenne GPS et il agit donc comme un navigateur GPS de base en communiquant avec
le réseau de satellite GPS, soit il n’est pas équipé de ce type d’antenne et dans ce cas là c’est
l’opérateur qui s’occupe de la localisation de cet appareil par des techniques de triangulation
entre les antennes GSM. Cette technique est cependant beaucoup moins précise puisque sa
précision actuelle est de l’ordre de 500m. Nous voyons à la figure suivante un Smartphone de
type Palm équipé d’une application de navigation.
FIGURE 5 - APPLICATION DE NAVIGATION SUR UN SMARTPHONE
- 18 -

19. Un autre type de positionnement possible et surtout applicable en intérieur est le posi-
tionnement par wifi. En effet par une technique de radiomap par exemple, un réseau wifi est
capable de connaître la position de l’utilisateur connecté à ce réseau et de la lui envoyer ou
encore mieux, de le guider vers une destination dans le bâtiment.
b. Les services d’information
Cette catégorie regroupe diverses applications. Leur point commun principal est que
ce sont des bases de données d’information auxquels l’utilisateur demande des informations
par son appareil mobile. Ces services lui renvoient alors le résultat de sa requête. Typique-
ment, l’opération « trouver la pompe à essence la plus proche » est une requête qui demande
de consulter une base de données contenant toutes les pompes à essence d’un pays ou d’un
continent par exemple et de spécifier dans la requête que l’on ne souhaite retenir que les ré-
sultats situés dans une zone géographique autour de la position de l’utilisateur. Elle peut
aussi, sur demande de l’utilisateur, filtrer de ces résultats toutes les pompes à essence ne
contenant pas de biocarburant. Cette base de données constitue en fait un Web Service
quelque part sur le net qui est sollicité par l’appareil mobile qui lui envoie une requête con-
tenant toute les spécifications désirées. Le Web Service effectue la requête sur sa base de
données et renvoie le résultat à l’utilisateur.
Il existe des dizaines si ce n’est des centaines de services de ce genre. On peut citer
des applications pour trouver l’hôtel le plus proche qui propose des chambres dans une cer-
taine plage de budget ou encore le restaurant asiatique qui reste ouvert après minuit. Un
autre type de service d’information que l’on peut classer aussi dans les services de naviga-
tion est le service qui fournit des informations sur l’état du trafic des routes sur notre
chemin. En effet on retrouve la même architecture de base de données mise à jour réguliè-
rement par les conditions de trafic des routes et qui serait consultée par des appareils
mobiles. Ce service permet à l’utilisateur de visualiser sur son trajet, les routes qui sont plus
ou moins denses en trafic et lui permettra éventuellement de prendre un autre trajet plus ra-
pide parce que moins congestionné.
Un autre exemple typique de services d’information serait par exemple un service dis-
ponible dans les parcs nationaux pour donner plus d’information aux visiteurs et les guider
dans leur visite du parc en leur fournissant des informations en fonction de l’endroit où ils se
trouvent et des animaux qu’ils sont entrain de regarder. Un tel service a déjà été développé
en Suisse par la société Camineo et a été nommé The WebPark Project (8) dont on voit un
exemple d’écran d’appareil mobile à la figure suivante.
- 19 -

20. FIGURE 6 - CAPTURE D'ECRAN DE L'APPLICATION WEBPARK
Le secteur du tourisme a été le premier à connaitre un franc succès auprès des LBS.
Puisque les touristes sont à la recherche de toutes sortes d’information sur l’endroit qu’ils
sont entrain de visiter, les LBS d’information semblent tout indiqués pour ce genre de be-
soins. Il existe des applications qui proposent des visites guidées complète d’une ville avec
des trajets prédéfinis et des informations sur tous les monuments visités et les attractions
touristiques les plus intéressantes. Une application disponible sur l’iPhone, destinée aux
voyageurs qui aimeraient en savoir plus sur la ville qu’ils sont entrain de visiter fait le lien
entre le lieu où se trouve le voyageur et les articles de l’encyclopédie universelle Wikipédia
(9). Cette application, nommée GeoPedia (10), propose à l’utilisateur, dès qu’il a du temps
libre, une sélection automatique d’articles concernant le lieu où il se trouve.
Un projet beaucoup plus ambitieux de ce type a été développé en Allemagne sous le
nom de Location-Based City Portals (11). En effet, ce projet regroupe presque tous les types
de LBS proposés précédemment. Il propose de la localisation, de la navigation pour les pié-
tons, un guide touristique dynamique pour la ville, de la publicité sur les commerces à
proximité, une organisation virtuelle de la ville avec des services d’e-gouvernement, des in-
formations sur la disponibilité de places de parking et des transports en commun ainsi
qu’une plateforme communautaire pour que les différents touristes discutent et s’échange
des idées et des conseils sur la visite de la ville mais aussi pour qu’ils discutent avec les ré-
sidents de la ville et fassent des propositions au conseil de la ville pour améliorer.
c. Les services de suivi et de gestion
Cette catégorie de services attire tant les particuliers que les entreprises. En effet, d’un
point de vue purement technique, des parents qui suivent en continu l’itinéraire et la position
de leur enfant sur un écran est exactement la même chose qu’un gestionnaire qui suit en en
continue l’itinéraire et la position de ses agents commerciaux ou de ses techniciens. Ces ser-
vices répondent à des besoins bien présents de parents par exemple qui désirent laisser un peu
- 20 -

21. plus de libertés à leurs enfants en évitant de les appeler trop régulièrement pour savoir où ils
sont et ce qu’ils font. Ils sont alors plus sereins en voyant leur enfant en classe pendant les
heures d’école et n’auront plus les frayeurs de recherche lorsque l’enfant tarde trop à rentrer le
soir, ils sauront directement s’il est chez un camarade de classe ou à un autre endroit. La so-
ciété CATS (Child Alert Tracking Service) a développé et commercialisé un service
géolocalisé appelé Cat TRAX (12) qui permettrait au parent de connaitre la position de leur
enfant en temps et réel et d’intervenir par exemple lorsque l’enfant est dans un endroit où il
n’est pas censé allé.
Du côté professionnel, ce service est très utile pour un hôpital qui reçoit un appel
d’urgence et le transfère automatiquement à l’ambulance disponible la plus proche du lieu du
malaise. Cette manœuvre serait possible si le système a un suivi en temps réel de la position
de toutes les ambulances pour comparer les temps de trajet entre ces dernières et le lieu de
l’urgence. Un autre avantage serait que le patient recevrait une information du temps d’arrivée
de l’ambulance de manière beaucoup plus précise que les systèmes actuels.
Un autre exemple serait par exemple une société avec une flotte de véhicules qui vou-
drait suivre en temps réel la position de ses véhicules le peut grâce aux LBS. En effet ces
derniers seraient équipés chacun d’un appareil mobile dont la position serait calculée et suivie
en temps réel par l’opérateur ou encore par GPS. Cette position serait ensuite transmise par le
GSM soit par le Réseau 3G/GSM/GPRS/SMS au service LBS ou bien par satellite. Ces in-
formations seraient ensuite rassemblées et traitées pour finalement être affichés sur un même
écran chez le gestionnaire. Voici un schéma explicatif du processus fourni par la société qui
propose ce service (13).
Figure 7 - Schema explicatif du processus de suivi de vehicule par un lbs
- 21 -

22. d. Les services d’urgence
Nous avons déjà parlé en partie de ce type de service dans la catégorie précédente avec
l’exemple des ambulances. Nous pouvons rajouter à cela d’autres applications très promet-
teuses comme par exemple les appels automatiques aux urgences en cas d’accident. Un
motard ou un automobiliste qui a eu un accident et ne sait pas se situer peut uniquement en un
click appeler les secours. Le service LBS s’occupera automatiquement de transmettre aussi la
position de l’utilisateur aux services d’urgence. Ceci peut très bien être réalisé pour des acci-
dents terrestres comme maritime ou aéronautique. En effet il suffit que le lieu de l’accident
soit sous la couverture du réseau GSM pour que la localisation soit faite automatiquement. Un
projet qui propose cette solution est développé par la société Cospas-Sarsat (14) qui propose
tout le processus de sauvetage après l’accident aussi bien en mer qu’en terre. La figure sui-
vante montre comment l’appel est transmis depuis les radiobalises de détresse ELT
(Emergency Locator Transmitter) , PLB (Personal Locator Beacon) ou les EPIRBs (emer-
gency position-indicating radio beacons) pour les signaux maritimes, vers les satellites . Ces
derniers transfèrent alors l’appel ainsi que la position vers les stations terriennes de réception
LUT qui encapsulent ces données pour former un message de détresse envoyé aux centres de
contrôle de mission (MCC). Ce dernier choisi d’envoyer ce message soit à un centre de coor-
dination de sauvetage (RCC), soit à un point de contact (SAR). Ces derniers voleront alors le
plus vite possible au secours des victimes pour les sauver.
FIGURE 8 - SCHEMA D'APPEL DE SECOURS DU MODELE DE L'APPLICATION COSPAS-SARSAT
e. Les services de facturation
Les cartes bancaires ont déjà facilité la vie des usagers du fait qu’elle évite l’utilisation
encombrante de la monnaie et qu’elle ne nécessite pas toujours d’avoir de l’argent liquide sur
soi. Elles ont aussi augmenté la sécurité sur l’argent personnel puisque perdre ou se faire voler
sa carte de banque est nettement moins dangereux que perdre ou se faire voler de l’argent
- 22 -

23. liquide. Le paiement par LBS a porté ceci une étape plus loin, puisqu’il nous dispenserait par
exemple de devoir remplir tous les champs à remplir pour un virement. En effet le service
connait à l’avance le destinataire du virement ainsi que le montant à payer. L’appareil mobile
nous permettrait aussi de ne pas avoir à passer par un distributeur automatique pour payer ses
factures puisque nous disposons déjà d’un terminal électronique à portée de main.
L’application la plus révolutionnaire apportée par ce type de LBS est sans doute le paiement
sensible à la géolocalisation comme l’on a expliqué précédemment avec l’exemple de la télé-
phonie mobile (6).
f. La réalité augmentée
Ce domaine est encore très récent et les premières applications sont toujours en cours de
développement. La première application vraiment pratique dans ce domaine est appelée Wiki-
tude : Practical augemented reality. (15). Cette application est une combinaison de Wikipédia
(9) du système d’exploitation mobile Android de Google (16) et du Smartphone G1 du cons-
tructeur HTC (17). L’application, en géolocalisant l’utilisateur, permet de lui afficher sur
l’écran de son Smartphone, pendant que la caméra est activée, des informations supplémen-
taires sur ce qu’il est entrain d’observer à l’écran que le LBS tire de wikipédia. La figure
suivante est une impression d’écran d’une vidéo qui montre l’application tourner sur un site
touristique et qui affiche à l’écran à côté du monument, des informations supplémentaires sur
ce dernier. On peut voir la vidéo sur le lien suivant (15).
FIGURE 9 - CAPTURE D'ECRAN DE L'APPLICATION WIKITUDE SUR UN SMARTPHONE G1
VI. LE PROCESSUS TYPE ET LES COMPOSANTS D’UNE REQUETE
- 23 -

24. Nous l’avons compris à présent pour qu’un LBS fonctionne correctement, il faut qu’une
série de composants collaborent et interagissent pour effectuer la tâche dont l’utilisateur a
besoin.
La figure suivante illustre ces différents composants et nous allons détailler un peu plus
chacun d’entre eux.
FIGURE 10 - LES COMPOSANTS D'UN SYSTEME LBS
L ES APPAREILS MOBILES
L’appareil mobile est l’outil de communication ou d’interface entre l’utilisateur et le
système et qui lui permet de demander et de recevoir les données dont il a besoin. L’appareil a
plusieurs moyens de transmettre la réponse à l’utilisateur. Elle peut être sous forme vocale,
comme des indications de navigation si l’utilisateur conduit par exemple et ne doit pas trop
regarder l’écran. Elle peut être sous forme de texte comme la description d’un menu de res-
taurant par exemple. Elle peut aussi être d’images ou de vidéos pour montrer des monuments
que l’utilisateur voudrait visiter le lendemain par exemple. Ceci dit l’appareil mobile pourrait
très bien être un GSM comme un Smartphone, un PDA, un ordinateur portable etc. Il pourrait
aussi être, dans des cas plus particuliers, l’ordinateur de bord d’une voiture ou de tout autre
véhicule. Notons aussi que les Web Service à la base sont des applications qui sont conçues
pour la communication machine-à-machine, les humains ne sont pas les seuls à utiliser les
LBS. Il existe des comportements automatiques de requête LBS sans que l’humain ne le de-
mande explicitement comme la vérification régulière et périodique des conditions de trafic
routier par exemple. L’utilisation des LBS dépend aussi de la capacité et la facilité de
l’utilisateur de manier des appareils électroniques, du type d’appareil et de sa capacité de
stockage ainsi que bien d’autres paramètres. Un paramètre important est le besoin de
l’utilisateur/machine d’utiliser une large palette de LBS ou bien juste une seul tâche particu-
- 24 -

25. lière. Vu ce dernier point nous proposons un classement parmi d’autres possibles des appa-
reils mobiles. Nous distinguons alors :
• Appareils dédiés à un but particulier : Ces appareils sont par exemple les sys-
tèmes de navigation d’une voiture ou encore les systèmes d’appel d’urgence
pour les personnes âgées ou handicapées. D’autres systèmes dans cette même
catégorie sont par exemple les systèmes d’appel à dépannage ou à ingénieur ré-
parateur ou encore à des équipes de sauvetages comme dans (13). Certains
appareils utilisant des applications de réalité augmentée sont aussi à classer dans
cette catégorie comme par exemple des systèmes de d’inspection de ponts et bâ-
timents par des contrôleurs fédéraux.
• Appareils multi-usages : Ces appareils sont utilisés par la plus-part des gens
dans leur vie quotidiennes et peuvent être sous formes de GSM, PDA, Palm, Ta-
blet PC ou ordinateur portable. La figure suivante présente ces différents types
d’appareil de divers constructeurs présents sur le marché.
FIGURE 11 - PALETTE D'APPAREILS MOBILES UTILISES POUR LES LBS
Pour ces appareils multi-usages, nous nous devons de parler de leurs limitations. En ef-
fet, la puissance de calcul des appareils n’est pas infinie. Elle est même réduite comparée à la
puissance nécessaire pour certains calculs complexes de cartographie par exemple. C’est pour
cela qu’il existe des serveurs de services de calcul spécialement dédiés à qui l’appareil envoie
les données et attend le résultat du calcul. D’autres limitations encore sont la taille de mé-
moire disponible pour ces applications, la taille des écrans de certains appareils ainsi que la
durée d’autonomie de batteries. La bande passante est aussi à prendre en considération surtout
pour un utilisateur mobile qui est susceptible en se déplaçant de changer de réseau et donc de
bande passante.
- 25 -

26. L E RESEAU DE TELECOMMUNICATIONS
Le second composant essentiel des LBS est le réseau de télécommunication. La tâche de
ce dernier est de transporter et transmettre les données depuis l’utilisateur jusqu’au fournis-
seur de service et puis de transmettre la réponse de ce dernier vers l’utilisateur. Une autre
seconde tâche de ces réseaux est la géolocalisation d’un appareil mobile.
On classe les réseaux sans fil actuellement suivant deux classifications :
• Classement suivant la portée du réseau : Dans cette classification on distingue :
o Les WWAN pour Wireless Wide Area Network comme le réseau GSM et
UMTS.
o Les WLAN pour Wireless Local Area Network comme les réseaux Wifi
IEEE 802.11.
o Les WPAN pour Wireless Personal Area Network comme les réseaux
Bluetooth.
• Classement suivant la typologie du réseau : Dans cette classification on dis-
tingue :
o Les réseaux à infrastructure : où les nœuds sont immobiles et les clients
accèdent à ceux nœuds directement.
o Les réseaux Ad-hoc : les utilisateurs sont eux-mêmes des nœuds mobiles
et les connexions se font de proche en proche.
La Figure suivante illustre ces deux types de classification :
FIGURE 12 - CLASSIFICATION DES RESEAUX SANS FIL
- 26 -

27. L ES TECHNIQUES DE POSITIONNEMENT
Par définition, les LBS utilisent la position géographique de l’utilisateur pour répondre à
ses besoins. Donc Ils ont besoin de techniques pour localiser l’appareil mobile de l’utilisateur.
Cette position peut être calculée soit par satellite en utilisant le GPS ou alors en faisant appel
au réseau de télécommunication. D’autres moyens encore sont possibles surtout en environ-
nement intérieur. Nous avons cité le positionnement par wifi mais il existe d’autres moyens de
localisation comme les badges actifs ou encore les balises actives. Si aucune des ses technolo-
gies n’est disponible, l’utilisateur peut encore encoder sa position manuellement.
On peut classer ces différentes méthodes en 2 catégories.
• Le positionnement par le réseau : Dans cette catégorie le calcul de la position
se fait par les stations de bases du réseau cellulaire par exemple. Donc l’appareil
mobile envoie un signal aux stations de bases pour qu’elles le localisent.
• Le positionnement par l’appareil mobile : Dans ce cas, c’est l’appareil lui-
même qui reçoit différents signaux et calcul sa position d’après ces signaux.
L’exemple le plus connu pour cette technique est le système GPS.
Le positionnement, dans les deux catégories repose sur les mêmes principes de bases
suivants :
1. Les stations de bases ont des positions connues.
2. Les informations contenues dans un signal reçu sont utilisées pour évaluer la
distance entre les stations de bases et l’appareil mobile.
3. A partir des informations de 1 et 2 on calcule la position du mobile par intersec-
tion d’arcs de cercle comme dans l’image A de la figure suivante. Mais ce n’est
pas toujours le cas. Parfois on utilise des demi-droites ou mêmes des hyperbo-
loïdes pour le GPS.
Cette figure représente aussi les deux catégories nommées précédemment.
FIGURE 13 - CATEGORIES DE TECHNIQUES DE POSITIONNEMENT
- 27 -

28. L ES SERVICES G EOLOCALISES .
Le dernier composant de base essentiel au fonctionnement des LBS sont les Web Ser-
vices géographiques et les fournisseurs de données.
Les services de localisation ont été standardisés par l’OGC (18) (Open Geospatial con-
sorcium) et l’ISO (19)(International standard Organisation). Plus particulièrement, la norme
19119 définit à travers la spécification OpenLS (20), des services cœurs que tout LBS doit
fournir pour être appelé un serveur de géo-mobilité. OpenLS en a définit 5 en 2005 et ce sont
les suivants :
• Les services d'annuaire : Ces services sont typi-
quement les pages jaunes et fournissent l’endroit, le produit ou le
service le plus proche ou le plus spécifique de la requête.
• Un service Gateway : Il représente l’interface
entre le serveur de géo-mobilité et le serveur de localisation. Il
permet d’obtenir la position actuelle de l’utilisateur.
• Le service public de Géocodage : Ce service re-
tourne la position géographique si l’on fournit le nom d’un lieu ou
son adresse ou son code postal. Inversement, il permet de retour-
ner une adresse complète si on lui fournit une position
géographique.
• Service de présentation : Ce service s’occupe de
fournir la carte géographique d’un lieu dont on lui fournit
l’adresse ou la position géographique. Il permet aussi d’y super-
poser des couches d’information comme des points d’intérêt par
exemple.
• Le service de routage : Ce service permet de cal-
culer un itinéraire entre un point de départ et un point d’arrivée
avec plus ou moins d’option comme spécifier un point intermé-
diaire ou encore demander le chemin le plus court ou le plus rapide
etc.
- 28 -

29. Ayant ces services de bases, il nous faut encore les bases de données contenant les in-
formations à propos des produits et services à proprement parler. On appelle ces serveurs les
fournisseurs de données ou de contenus.
On peut les classer en deux catégories comme on le voit à la figure suivante :
FIGURE 14 - TYPES DE FOURNISSEUR DE CONTENU
Les serveurs d'application à but dédié : Ces services sont spécialisés et ser-
vent en général pour un nombre très limité si ce n’est une seule application. Des
exemples seraient un service de localisation des personnes âgées et des per-
sonnes handicapées. En plus de ce suivi de position, on peut définir des zones à
risques où une alarme serait générée dès que la personne suivie y pénètre. Un
autre exemple de service qui est dans ce cas plus un fournisseur de contenu se-
rait un LBS de parc animalier par exemple qui fournirait non seulement la carte
géographique du parc mais aussi des informations sur les espèces animalières
qui y sont. Ce type de données est assez spécifique au par cet donc serait stocké
et édité dans les bases de données du parc. L’application WebPark en est un
exemple concret (8).
Les serveurs d’application à but général : Ces services sont à usage multiples
et peuvent non seulement être consultés par les LBS mais via internet ou
d’autres applications encore. Ils sont en général fournis par les opérateurs natio-
naux et vont des horaires des transports en commun aux prévisions météo en
passant par les informations de trafic comme on peut le voir dans la figure sui-
vante.
- 29 -

30. FIGURE 15 - EXEMPLES DE SERVICES LBS A BUT GENERAL
- 30 -

31. B. LA GESTION DE CONTEXTE
Les services géolocalisés sont différents des médias et outils plus conventionnels
comme les annuaires, les guides et les cartes parce qu’ils sont conscients du contexte dans
lequel ils sont sollicités et peuvent par conséquent adapter leurs comportements et leur résul-
tats à ce contexte. Il y a plusieurs aspects du contexte et les plus utilisés sont l’identité de
l’utilisateur, sa localisation, l’heure et la tâche qu’il est entrain d’exécuter. Néanmoins des
questions comme l’âge de l’utilisateur, est ce qu’il pleut peuvent être tout aussi prépondé-
rantes dans le comportement des LBS. Ces derniers pourraient par exemples filtrer des
résultats de recherche comme par exemple en ne gardant que les restaurants qui ne sont qu’à
10min de marche à pied de l’utilisateur dans le cas où ce dernier ne serait pas motorisé. Un
autre exemple serait d’afficher avec des icônes différentes les restaurants ouverts et les restau-
rants fermés en prenant en compte l’heure actuelle de la requête. Nous nous rendons donc
compte de l’importance et la valeur ajoutée de la connaissance du contexte de l’utilisateur par
les LBS pour diverses raisons. La manipulation d’appareils portables est moins confortable
que celle d’un ordinateur ou d’une autre interface. Il est donc préférable que l’utilisateur ait à
rentrer le minimum de données possibles et que le système en déduise un maximum d’autres.
Une deuxième raison est que pour les LBS, l’utilisateur est mobile, son contexte est donc
amené beaucoup plus à changer que pour un utilisateur assis devant un ordinateur. Nous al-
lons étudier plus en détail cette notion dans la suite de ce chapitre.
I. DEFINITION
Commençons par définir ce mot « contexte ». Le dictionnaire de l’académie française
propose deux définitions à ce terme. La première est la suivante : Ensemble du texte entourant
un mot, une phrase, un passage pouvant éclairer le sens de ce dernier. La seconde définition
est la suivante : Ensemble de circonstances qui accompagnent un évènement, une action.
La première définition est plus proche de la science des langues et des études de dia-
logue alors que la seconde est beaucoup plus générale et se rapproche plus de l’utilisation
quotidienne de ce mot dans le langage parlé. En ce qui concerne les LBS, les deux définitions
sont pertinentes. La première correspondrait plus à l’étude de la requête proprement dite en-
voyée par l’utilisateur au LBS. Elle s’occuperait de déduire un maximum d’information non
dites dans la requête qui est en générale très courte pour des raisons pratique de confort. La
seconde définition par contre pourrait se référer à toute l’information additionnelle qui est en
dehors de la requête et qui pourrait déterminer avec plus de précision ce que l’utilisateur
cherche ce dont il a besoin.
Dans le monde de l’informatique, une définition fréquemment cité et celle de Dey, A.K.
(21) qui dit que « le contexte contient toute information qui peut être utilisé pour caractériser
la situation d’une entité. Une entité est une personne, une place, ou un objet considéré comme
pertinent à l’interaction entre un utilisateur et une application en incluant l’utilisateur et
l’application eux-mêmes ». D’un autre côté une caractérisation formelle de la notion de con-
texte est toujours manquante à la littérature et les recherches en cours utilisant la notion se
- 31 -

32. basent sur des définitions ad-hoc ou dépendantes des données de contexte qu’utilise
l’application de leur recherche.
Dans notre cas, pour éviter les confusions, le contexte sera défini comme l’ensemble des
informations qui pourraient déterminer ou influencer la sélection de résultats qui seront re-
tournés à l’utilisateur. C'est-à-dire toute information qui pourrait mener à une requête encore
plus spécifique.
II. LES SERVICES UTILISANT LE CONTEXTE
D’après K. Henricksen (22), le contexte peut être classé en 4 catégories :
• Contexte capté : c’est le contexte déduit en utilisant des capteurs. La localisa-
tion par exemple est un contexte capté par des capteurs de localisation.
• Contexte statique : c’est un contexte qui reste relativement fixe et a une grande
probabilité d’être correct. Un exemple est le type d’appareil mobile de
l’utilisateur et donc ses caractéristiques.
• Contexte dérivé : ce sont des informations de contexte calculées depuis d’autres
informations de contexte déjà connues. Par exemple si l’on connait la date de
naissance de l’utilisateur, on peut automatiquement filtrer des endroits auxquels
il ne peut pas accéder. Un autre exemple sera d’estimer si deux objets sont
proches l’un de l’autre en connaissant leur positions respectives.
• Contexte de profil : Ce sont les informations fournies par l’utilisateur comme
par exemple son profil personnel ou encore son agenda et son carnet d’adresse.
C’est précisément cette source de contexte-ci que nous allons étudier plus en dé-
tail dans notre application pratique.
Dans les applications précédentes, le contexte est recueilli, calculé et directement
transmis à l’application de manière fortement couplée. Ceci implique de grosses difficultés
dans la conception des programmes informatiques qui souhaitent par exemple la réutilisation
d’une partie du contexte ou encore la structure en multi couche d’abstraction du contexte. Un
exemple à cet inconvénient sera par exemple deux applications qui nécessitent toutes les deux
de connaitre la localisation de l’utilisateur. Supposons que la différence entre ces deux appli-
cations est que l’une a uniquement besoin connaitre la rue où l’utilisateur est mais que la
seconde a besoin de connaitre le numéro du bâtiment devant lequel l’utilisateur est. Dans ce
cas là, en manque de réutilisation de contexte, les deux applications devront calculer cette
localisation séparément et de manière redondante car le pays, la ville, le code postal et la rue
sont calculé de manière parfaitement identique. Si maintenant la réutilisation du contexte était
d’application, le calcul de la ville, le code postal et la rue ne serait effectué que par une seule
application et le résultat serait réutilisé par l’autre application.
- 32 -

33. Suite à cette problématique, dans un projet mené par IBM (23), qui est un exemple entre
autres, une couche middleware supplémentaire a été développée pour recueillir, calculer et
gérer le contexte pour ensuite le fournir aux applications qui en ont besoin. Cette couche in-
termédiaire permet aux applications cliente qui demandent le contexte de l’obtenir plus
facilement avec des langages de haut niveau sans se soucier de la collecte et l’agrégation du
contexte.
III. UTILISATION DES ONTOLOGIES ET DU WEB SEMANTIQUE
Commençons par définir ce terme. D’après Tom Gruber, des laboratoires de recherches
sur l’intelligence artificielle de Stanford (24), « Une ontologie est une spécification d’une
conceptualisation ».
Le terme ontologie est un sujet assez controversé dans le monde de l’AI (25). Il a une
longue histoire dans le domaine de la philosophie dans lequel il fait référence au sujet de
l’existence. Il a aussi souvent été confondu avec l’épistémologie qui aborde le savoir et les
connaissances.
Dans notre cas, et dans le cas du partage du savoir, l’ontologie est définie comme une
spécification d’une conceptualisation. C'est-à-dire qu’une ontologie est une description des
concepts et des relations qui peuvent exister pour un agent ou une communauté d’agents.
Cette définition est alors compatible avec l’usage du terme ontologie comme un ensemble de
définitions de concepts mais est encore plus général. On utilise alors les ontologies comme
des spécifications que l’on s’engage à suivre pour en quelque sorte standardiser le langage et
le rendre transportable vu qu’il devient indépendant du lecteur et du contexte. En pratique les
ontologies sont représentées comme des ensembles de définitions de vocabulaire formel.
Dans son article (26), N. Guarino, fait une distinction entre les ontologies de haut ni-
veau, qui définissent les sémantiques originelles des concepts, et les ontologies liées au
domaine, tâche et application dont les définitions de concept sont destinées à un domaine,
tâche et application spécifiques.
Les LBS opèrent dans un monde dynamique caractérisé par la multiplicité et la grande
volatilité des partenaires. Ces partenaires ont en plus des vues très hétérogènes du monde.
Ceci implique la nécessité des LBS à créer leurs propres vues. C'est-à-dire créer leurs propres
ontologies désignées par LBSO (27) pour LBS Ontologies pour fournir une base stable de
raisonnement à leurs services. Les LBSO sont principalement influencées par les fournisseurs
de données qui en pratique délimitent le domaine de données à couvrir. Cette définition ini-
tiale est sujette à évoluer en fonction des requêtes de l’utilisateur ainsi que leur satisfaction ou
celle des fournisseurs. Les utilisateurs en particuliers sont très hétérogènes dans les concepts
qu’ils utilisent ainsi que dans les termes pour désigner ces concepts. En effet, si les utilisateurs
ne sont pas contraints à utiliser des terminologies prédéfinies par exemple en utilisant des
interfaces basées sur des menus préétablis, des problèmes d’interprétation apparaissent no-
tamment dans la détermination du vrai sens des requêtes qu’ils formulent. Ceci implique donc
- 33 -

34. le déploiement d’assistance ontologique diverse. Nous allons donner quelques formes
d’assistance largement utilisée (27).
A SSISTANCE PAR DICTIONNAIRE :
La justification de cette assistance par dictionnaire part d’un constat simple : Pour ex-
primer le bon sens, il faut utiliser les bons mots. Le savoir terminologique est un composant
nécessaire dans tout système d’information et plus particulièrement dans les LBS. Il propose
une aide aux utilisateurs dans leur besoin d’exprimer des requêtes sensées même si cela les
oblige à utiliser des mots-clés particuliers ou à choisir des mots dans une liste. Le but clair de
cette manœuvre est de créer des interactions compréhensibles tant par l’homme que par la
machine entre les utilisateurs et les LBS. Ceci est particulièrement difficile dans le cas des
LBS où l’utilisateur est mobile et par conséquent, peut se retrouver dans des endroits de cul-
ture différente et donc de terminologie différente. Les abréviations et les acronymes par
exemple sont souvent utilisés pour faire référence à quelqu’un, quelque chose ou quelque part.
Ils sont en plus très pratiques pour les LBS vu la taille réduite des écrans des appareils mo-
biles. Des ontologies terminologiques peuvent alors proposer une assistance lexicographique
basée sur dictionnaire pour améliorer la communication avec les LBS.
I NTEROPERABILITE DES DONNEES :
Les ontologies doivent naturellement être conformes aux principes des Web Services
sémantiques, où les sources de données ainsi que les services sont supposés être accompa-
gnées de spécifications explicatives et lisibles par machine. Les ontologies sont
l’infrastructure du savoir des Web Services sémantiques. Dans les LBS, elles permettent aux
différentes sources de données d’interagir en dépit des différents formats et représentations en
termes d’abstraction. Aujourd’hui les LBS peuvent déjà utiliser les ontologies développées
par la communauté W3C et mise à disposition via des librairies publiques d’ontologies qui
couvrent un large champ sémantique. Ces ontologies, privées ou publiques, décrivant un
champ de connaissance précis ou bien décrivant d’autres ontologies peuvent fournir un grande
aide dans le partage et la réutilisation du contexte dans les LBS.
M EDIATION DE DONNEES :
Ceci est un aspect particulier d’interopérabilité des données. Des services de médiation
établissent des ponts entre les ontologies avec des spécifications syntaxiques différentes ou
même dans des langages ontologiques différents. Cette technique est particulièrement utilisée
dans les réseaux sociaux comme Flickr (28), Youtube (29) ou Wikipédia (9) comme expliqué
dans cet article (30).
- 34 -

35. IV. MODELISATION DU CONTEXTE
Le contexte est différent des autres types de données par plusieurs aspects :
• Le contexte est éphémère : En effet l’utilisateur fait plusieurs activités dans la
journée et donc son contexte change en conséquence et a une durée de vie limi-
tée.
• Le contexte est incertain : Le contexte ne peut jamais être déduit et certifié
avec une probabilité de 100%. Il subsiste toujours des doutes quand à la validité
du contexte déduit par un système d’information.
• Le contexte est imprécis : le contexte est une notion complexe et donc aucune
interprétation par un système d’information ne peut prétendre cerner un contexte
de manière complète et absolue.
• Le contexte est hétérogène : De part sa définition, le contexte est tout ce qui en-
toure un évènement, une action, une personne ou un objet. Donc le contexte
peut tout aussi bien être un lieu géographique qu’un temps, qu’une activité que
des conditions météorologiques.
• Plusieurs descriptions de contexte différentes peuvent décrire une même si-
tuation réelle : Ceci est un corolaire du point précédent. Un même contexte réel
peut être représenté soit par : « il pleut et l’utilisateur marche dans la rue » ou
alors par « l’utilisateur est au téléphone et est en retard à son travail ».
• Le contexte est spatio-temporellement dynamique : de la même manière que
le premier point, le contexte varie tout aussi bien au cours du temps que quand
l’utilisateur change de lieu géographique. Toutes choses restant égales, un con-
texte à midi est différent d’un contexte à minuit. De même, un contexte dans le
domicile est différent d’un contexte sur le lieu de travail.
En plus de ces différentes propriétés, il existe des relations d’influences entre les con-
textes eux-mêmes. Un temps d’orage ou d’averse peut influencer les conditions de trafic par
exemple mais pas dans le sens inverse.
Un autre point à souligner est que pour certaine tâches, seule une partie du contexte total
est pertinente. Si l’utilisateur s’informe des restaurants les plus proches et qu’il est à pied, les
conditions de trafic ne sont pas pertinentes par exemple. Par la pertinence d’une partie de con-
texte on veut dire, des informations qui influenceraient le filtrage des résultats retournés à
l’utilisateur après une requête.
Il y a eu des premières tentatives d’établir un modèle pour tenter de gérer et représenter
le contexte mais toutes souffrent typiquement de l’une des deux limitations suivantes.
Soit ces modèles ont évolué depuis une application de départ et ont par conséquent une
notion de contexte liée et limitée à ce champ. En visant un modèle de contexte spécifique à
- 35 -

36. une application, le concepteur se réduit souvent à une vision réduite et à un ensemble restreint
de dimensions. Par exemple, ce que font la plus-part des modèles est de classer les contextes
en différentes catégories (utilisateur, appareil mobile, facteurs environnementaux) et prédéfi-
nissent les dimensions nécessaires pour chacune des classes du contexte (31).
La deuxième limitation est que certains modèles construisent la manière dont ils repré-
sentent et sauvegardent le contexte comme une conséquence des technologies utilisées pour
l’implémenter. Donc on remarque que la représentation du contexte est souvent intimement
liée à la plateforme utilisée pour le traitement d’informations de contexte.
Le panel de solutions proposées jusque maintenant s’étend des simples collections
d’attributs et de leurs valeurs jusqu’à des approches complexes qui représentent le contexte
comme des objets de bases de données ou basés sur des hiérarchies de classes dans un langage
de programmation orienté objet (31). Donc la proposition d’un modèle de contexte ne sera
réellement innovante que si elle se détache de ces deux limitations.
Le premier challenge à relever pour définir un modèle de contexte aussi général est de
s’assurer de ne pas imposer une quelconque notion spécifique de contexte aux applications
clientes. Il y a eu plusieurs approches qui ont proposé des modèles généraux dans le sens où
chaque application cliente peut les configurer et définir sa propre notion de contexte (31). Ces
approches supposent que l’application cliente effectuera la configuration préalablement. Le
problème est que la plus-part de ces modèles continue à faire des suppositions implicites sur
le sens de certaines dimensions dans le sens des ontologies ou de la classification de contexte.
Souvent ces modèles mènent à des situations où différentes dimensions de contexte sont trai-
tées différemment alors qu’elle ne le devrait pas.
Ceci est donc indésirable dans un modèle qui se veut global et général pour cerner au
mieux la notion de contexte. Le modèle doit s’abstenir et se détacher de toute supposition sur
le contexte utilisé par une application donnée. Il faudrait donc s’élever une couche plus au
dessus des approches actuelles et abandonner complètement les suppositions sur le sens du
contexte.
V. LES DIFFERENTS TYPES DE CONTEXTE (SPATIAL, TEMPOREL, EN-
VIRONNEMENTAL, SOCIOCULTUREL…)
Rappelons la définition du contexte que nous avons utilisée : le contexte est toute in-
formation qui pourrait être utilisée pour caractériser la situation d’une entité. Cette dernière
pouvant être une personne, une place ou un objet qui serait pertinent pour l’interaction entre
l’utilisateur et l’application LBS. Notons que ces deux derniers sont inclus dans la définition
d’entité.
Plusieurs classifications des types de contexte ont été tentées. Par exemple W. N. Schilit
(32) a insisté sur trois aspects différents du profil :
- 36 -

37. • Le contexte spatial : C'est-à-dire répondre à la question : Où est l’utilisateur en
ce moment ? Il a estimé que la géolocalisation de l’utilisateur avait beaucoup de
corrélation avec son contexte. Ce qui s’est avéré vrai puisque tous les modèles
qui ont suivi intègre cet aspect là.
• Le contexte social : C'est-à-dire répondre à la question : qui est avec
l’utilisateur en ce moment ? Cette question est aussi essentielle puisqu’à partir
des personnes présentes en même temps que l’utilisateur on peut déduire qu’il
est en réunion de travail ou bien en soirée avec les membres du club de Hockey
par exemple.
• Le contexte informationnel : C’est la réponse à la question : quelles sont les
ressources disponibles qui se trouvent à proximité en ce moment? C'est-à-dire
toutes les activités que l’utilisateur pourrait faire après avoir terminé sa tâche
courante.
• Schilit rajoute qu’en plus de ces aspects, il faut encore rajouter tous les aspects
techniques de l’interaction. Ceci peut être par exemple, les capacités
d’affichage de son appareil mobile ou encore la bande passante offerte et dispo-
nible sur le réseau.
Plus tard, en 2003, une classification plus détaillée a été introduite par Nivala (33).
Cette classification est de plus orientée vers les services de téléphonie mobile géolocalisés.
Cette classification se compose de neuf catégories expliquées ci-dessous :
1. Le profil de l’utilisateur : L’identité et le profil de l’utilisateur sont un facteur
important pour permettre au service de s’adapter au mieux à ses attentes. Par
exemple, le service doit connaître l’âge et le sexe de l’utilisateur. Les enfants,
par exemples ne seraient pas intéressés de connaitre les bars et les pubs les plus
proches. Les services devraient aussi connaitre les préférences personnelles des
utilisateurs comme par exemple la langue principale que préfère utiliser
l’utilisateur pour lui faciliter la navigation dans les menus etc. On pourrait aussi
penser que le système aurait besoin de connaitre qui sont les amis et qui sont les
collègues de l’utilisateur pour mieux adapter la façon de communiquer et
d’établir des liens sociaux. Nous verrons cet aspect là dans une prochaine caté-
gorie de contexte qui regroupe l’aspect social du contexte.
2. La localisation : Comme nous l’avons dit pour Schilit, la localisation est
l’élément de contexte le plus commun entre les modèles. Ceci est dû à la forte
corrélation entre la localisation et le contexte. Savoir qu’un utilisateur est sur les
gradins d’un stade de football ou bien dans sa chambre à coucher nous en dit
beaucoup sur son activité actuelle. La géolocalisation peut être soit absolue soit
relative ou logique. Une position absolue serait par exemple des coordonnées de
GPS ou de latitude et longitude. Une position relative serait de dire que
l’utilisateur est dans le bar X ou dans la pièce numéro N du building D.
- 37 -

38. 3. Le temps : Le temps peut faire référence à l’heure instantanée de la journée
comme à de plus longues périodes comme les jours, les semaines et les saisons.
Un contexte à 15h de l’après-midi a de fortes chances d’être différent d’un con-
texte à 3h du matin. De même, ne fusse que pour les conditions
météorologiques, un contexte d’une chaude journée d’été est fort différent d’une
journée de neige en hiver. Le contexte un jour de semaine est différent du con-
texte un dimanche. Dans les LBS de divertissements, le temps est utilisé pour
déterminer si un événement est toujours valide ou bien est-t-il déjà terminé. Il est
aussi beaucoup utilisé pour alerter l’utilisateur pour lui indiquer qu’une activité
va bientôt commencer ou que son agenda prévoit un rendez-vous dans un quart
d’heure.
4. L’orientation : Il est parfois utile de connaitre l’orientation de l’utilisateur pour
savoir dans quelle direction il regarde. Notamment pour les touristes, lors d’une
visite dans un parc ou dans un musée, le LBS fournit des informations addition-
nelles sur ce que l’utilisateur est en train de regarder. On comprend alors mieux
l’importance d’avoir cette information d’orientation. De même lors d’une tâche
de navigation, il est important pour le LBS de savoir dans quelle direction
l’utilisateur regarde : une indication d’aller tout droit n’a aucun sens si le sys-
tème ne connait pas l’orientation actuelle de l’utilisateur.
5. L’historique de navigation : Cet historique permet aux utilisateurs eux-mêmes
de garder une trace de toutes leurs activités, par exemple leur programme de va-
cances. Il leur permet aussi de pouvoir faire demi-tour et remarcher sur leurs pas
dans le cas où ils se seraient perdus. De plus, si ces données d’historique sont
traitées par le système, cela permet de construire un profil de l’utilisateur et de
ce qui l’intéresse de manière à augmenter la pertinence et la qualité des services
et des informations que lui propose le LBS.
6. Le but d’utilisation des LBS : Cet aspect est définit comme les activités, les
buts, les tâches et les rôles des utilisateurs à un moment donné. Par exemple une
marche dans la forêt peut être en tant que touriste comme elle peut être en temps
que garde forestier ou guide pour touriste. Le comportement des LBS serait très
différent d’un rôle à l’autre ou d’un contexte à l’autre. Différents buts
d’utilisation requièrent différents :
a. Types d’informations : un touriste voudrait des informations sur les es-
pèces animalières et végétales qui l’entourent alors qu’un guide
surveillerait plus prudemment les prévisions météorologiques et les
heures de coucher de soleil.
b. Types de présentation : par exemple sous forme de texte, vocal ou de
carte. Un guide préférerait avoir une carte pour voir l’avancement du
parcours alors qu’un touriste préférerait des informations vocales par
exemple pour pouvoir regarder l’environnement en même temps.
- 38 -

39. c. Les modes d’interaction : Dépendamment de si l’utilisateur fait un autre
usage de ses mains, par exemple un pilote et un passager dans une voi-
ture, le mode d’interaction avec le LBS sera différent.
7. La situation socioculturelle : Cette situation pour un utilisateur est caractérisée
par plusieurs facteurs qui déterminent s’il est en plus ou moins forte interaction
avec les autres personnes présentes ou pas. Elle détermine aussi quels types
d’interactions est-ce etc. Voici trois de ces facteurs qui aideraient à mieux défi-
nir ce contexte :
a. La proximité aux autres membres
b. Le type de relations sociales qui le lie à ces derniers
c. Les éventuelles tâches collaboratives qu’il est amené à effectuer avec eux
8. L’environnement physique : Dans cette catégorie, on retrouve des éléments
physiques tels que le degré d’éclairage pour pouvoir ajuster l’intensité de rétro-
éclairage de l’écran ainsi que son niveau de contraste en conséquence. On y
trouve aussi le niveau sonore du bruit ambiant pour pouvoir ajuster en même
temps le niveau de sonnerie ainsi que le niveau de haut parleur en cas d’appel.
9. Les propriétés du système de télécommunication : Par système de télécom-
munications nous entendons, l’ensemble de l’appareil mobile et du réseau de
télécommunications qu’il utilise. Les propriétés importantes et pertinentes pour
les LBS dans cette catégorie seraient : la taille de l’écran, le fait qu’il soit tactile
ou pas, le fait qu’il soit en couleur ou en noir et blanc, le temps de batterie res-
tant et la quantité de mémoire disponible etc. En ce qui concerne le réseau de
télécommunications, le système LBS aurait besoin de savoir si la connexion à
internet dont dispose l’utilisateur est illimitée dans le temps ou pas ou encore de
la bande passante de cette connexion afin d’adapter ses quantités de trafic en
conséquence pour ne pas ralentir l’utilisateur dans sa navigation personnelle.
VI. INFERENCE DE CONTEXTE
Pour l’être humain, il est facile de comprendre le contexte d’une personne à un moment
donné mais pour une application, l’exercice s’avère beaucoup plus compliqué. Plusieurs re-
cherches sont en cours sur le sujet. La connaissance du contexte d’une autre personne facilite
la communication avec elle. Un exemple simple est l’affichage d’un profil ou d’un statut
d’utilisateur dans les applications de messageries instantanée qui fourni un peu plus
d’information sur le contexte de l’utilisateur. De la même manière, entre un utilisateur et son
appareil mobile, plus ce dernier récolte d’informations sur le contexte de son utilisateur, meil-
leure sera la qualité du service qu’il lui fournira. La collecte de ces informations et l’inférence
d’information de contexte de haut niveau est alors devenue crucial dans le développement
d’application utilisant le contexte. Pour faire cela, les applications essayent d’utiliser des in-
- 39 -

40. formations brutes pour ensuite en inférer d’autres de plus haut niveau. Un exemple
d’information brute serait celle obtenu par un récepteur GPS. Cette position serait ensuite
utiliser pour inférer une information de plus haut niveau. Par exemple, un lieu, comme une
station de bus, pourrait être inféré à partir de la position géographique (latitude, longitude) en
combinaison avec un système d’informations géographique. D’autres informations de plus
haut niveau peuvent encore être inférées de cette position géographique : Imaginons qu’un
utilisateur prenne tous les jours approximativement à la même heure, le même itinéraire pour
se rendre sur son lieu de travail. Si l’application conserve un historique de ces déplacements,
elle pourrait inférer un contexte de niveau plus haut encore que l’information : « l’utilisateur
est à la station de bus X ». En effet elle pourrait inférer que non seulement l’utilisateur est à
cette station de bus mais qu’en plus il se rend sur son lieu de travail. Ce type de recherche a
été mené dans une étude menée par Erik Meeuwissen, Paul Reinold, et Cynthia Liem (34) où
des informations de positionnement géographique ont été collectées sur des voyageurs pour
ensuite en inférer par exemple leur point de départ, leur point d’arrivée, l’itinéraire logique
(stations et correspondances) ainsi que sa durée. Les informations de positionnements brutes
dans ce cas ont été les identifiants des stations de bases du réseau cellulaire auquel se connec-
tent leurs appareils mobiles.
Une étude récente a, elle, été consacrée à l’inférence d’information sur les types de rela-
tions sociale qui lient l’utilisateur aux personnes avec qui il interagit quotidiennement. En
effet l’étude d’Alisa Devlic (35) utilise les communications quotidiennes qu’à l’utilisateur
avec d’autres personnes pour en inférer le type de relation qui les lit. En pratique l’application
fournit plusieurs types de relations probables qui pourraient lier l’utilisateur à d’autres per-
sonnes avec, pour chacune, une probabilité que cette relation soit vraie.
Une autre tendance dans l’inférence de contexte et de combiner des informations de lo-
calisation avec d’autres informations issues de capteurs simples et relativement bon-marché
comme des accéléromètres. Une étude qui va dans ce sens a été réalisée à l’université de
Washington par Evan Welbourne (36) où un appareil mobile doté de système de localisation
par réseau GSM ainsi que par réseau wifi a été augmenté d’une puce contenant d’autres cap-
teurs primitifs comme un accéléromètre et un baromètre. Cette étude a montré qu’il est était
très efficace d’utiliser des synergies d’informations provenant de capteurs de localisations
ainsi que de capteurs plus primitifs. Ce projet a permis de montrer qu’à partir de ces données
combinées, l’application pouvait inférer des données de contexte de haut niveau comme le fait
que l’utilisateur soit dans un bus ou conduise sa voiture ou encore faire la différence entre le
fait qu’il soit entrain de marcher ou bien de courir.
VII. PROFIL DES UTILISATEURS
D EFINITION ET UTILITE DANS LES LBS
Avant de lier cette notion aux LBS et à la déduction de contexte, commençons par la dé-
finir.
- 40 -

41. Un profil d’utilisateur est une collection de données personnelles associées à un utilisa-
teur spécifique. Un profil fait alors référence à une représentation numérique explicite de
l’identité d’une personne. Un profil utilisateur peut aussi être vu comme une représentation
informatique d’un modèle d’utilisateur. Ce modèle est alors complété par les informations
personnelles d’une personne spécifique. Un profil peut donc être utilisé pour sauvegarder la
description des caractéristiques d’une personne. Ces informations peuvent ensuite être exploi-
tées par des systèmes qui prennent en compte les préférences et les caractéristiques des
utilisateurs pour mieux s’adapter à ces derniers. On voit alors apparaître le lien avec les LBS.
Les profils d’utilisateurs ont été sujets de pas mal de recherches surtout dans le monde
de l’intelligence artificielle. Les études ont touché pas mal de questions comme l’acquisition
des profils d’utilisateurs, le savoir dégagé de ces connaissances de profil, l’utilisation de ces
données de profil pour un meilleur filtrage et livraison de résultat. Différents algorithmes qui
prennent en compte le profil ont été implémentés dans des applications qui proposent de la
recommandation ou du parcours du web. Les sites de réseaux sociaux utilisent ces algo-
rithmes intensément de telle manière qu’ils se sont mis en commun avec Google (7) et
Myspace (37) pour créer une collection d’APIS (application programming interfaces). Pour
faciliter l’interopérabilité et l’échange d’informations diverses, dont les profils d’utilisateur,
entre ces différents réseaux.
La plus-part des applications qui demandent un profil d’utilisateur pour améliorer le
service des Web Services utilisent en fait une application qui traite et utilise ces profils
d’utilisateurs. Les Web Services font systématiquement appel aux profils d’utilisateurs. On le
voit par exemple dans les formulaires qu’ils proposent à l’utilisateur de remplir avant de
s’inscrire au service. On le voit par exemple sur Facebook, My Yahoo ! , sur Monster.com
pour la recherche d’emploi ou encore PointCast pour l’abonnement aux informations
d’actualité. Le but principal est de retourner des résultats plus pertinents à l’utilisateur. Un
exemple courant est que dès que le système connait le pays de l’utilisateur, il adapte automa-
tiquement la langue d’affichage de l’application en fonction de la langue parlée. Pour la
Belgique où la Suisse, il faudrait en plus connaitre la ville pour choisir cette langue correcte-
ment.
En plus, les profils d’utilisateur peuvent être de grande valeur et de confort au sein d’un
même groupe d’intérêt. Pour augmenter la prise de conscience sociale des visiteurs d’une
ville, le projet GUIDE (38) leur permet d’interagir et de coopérer quand ils sont dans le même
contexte géographique, c'est-à-dire proches les uns des autres. Ce système s’est révélé très
efficace pour évaluer la popularité d’une certaine attraction en se basant sur les commentaires
d’autres utilisateurs qui l’ont déjà visitée. Des interviews avec des utilisateurs potentiels de
LBS ont montré que ces derniers attachaient beaucoup d’importance à la protection de la vie
privée dans ces systèmes de partage de profil d’utilisateur. Ils ont aussi montré qu’ils étaient
prêts à reconstruire leur propre profil d’utilisateur pour chaque nouvelle zone géographique
mais qu’ils ne voulaient pas le faire pour chacun des Services qu’ils utilisent. Ceci implique
donc que le profil d’utilisateur devra être partagé entre les applications.
Dans les services géolocalisés, vu la constante mobilité de l’utilisateur, l’environnement
de travail est en constante évolution et changement. De même pour les types et les fonctionna-
- 41 -

42. lités des sources de données disponibles. De ce fait, les approches statiques ne sont que très
peu efficaces dans de tels environnement. Pour les LBS, non seulement l’environnement mais
aussi le profil d’utilisateur peuvent changer à tout moment à cause des déplacements de
l’utilisateur, des changements de contexte social (l’entrée en réunion et la sortie de celle-ci),
des changements dans l’activité de l’utilisateur (du milieu professionnel au divertissement).
Par conséquent, il est clair que des approches au cas par cas ne feront pas évoluer les modèles
et resteront des solutions de bricolages non extensibles et dont la faible flexibilité se fera sen-
tir à la moindre évolution de l’application. Il est donc nécessaire de se concentrer sur des
approches plus génériques et plus dynamiques pour construire des modèles qui seront ca-
pables, à tout moment d’adapter et d’ajuster leurs services à l’environnement et au profil
d’utilisateur courants.
A CQUISITION DU PROFIL D ’ UTILISATEUR
L’acquisition explicite du profil de l’utilisateur en utilisant des questionnaires et des
formulaires a le clair avantage que les données acquises sont plus fiables et plus précises
puisqu’elles ont été introduites et validées par l’utilisateur lui-même. À part le dérangement
pour l’utilisateur causé par le remplissage de ces formulaires, l’inconvénient de cette approche
est sa faible adaptabilité au changement de contexte. Les utilisateurs ne vont pas à chaque
changement de contexte mettre à jour les données qu’ils ont entrées dans leur profil
d’utilisateur pour adapter le comportement du service LBS à leur nouveau contexte. Il est à
noter que les utilisateurs n’aiment pas remplir de longs questionnaires ennuyeux pour un
simple service. Des systèmes qui essayent de palier à ce problème utilisent des techniques
d’acquisition implicite de profil d’utilisateur. Par exemple, il est possible d’inférer les préfé-
rences des utilisateurs par l’observation des interactions entre l’utilisateur et le système ainsi
que des choix de sélection d’information qu’il a fait. Cette technique allège clairement
l’encombrement causé à l’utilisateur par les longs questionnaires. Cependant, elle a aussi un
coût : c’est le sacrifice de la précision et la fiabilité des données de profiles inférées explici-
tement. En particulier dans un environnement multi-contexte complexe comme celui des LBS,
il n’est pas facile de déterminer l’impact d’un contexte spécifique d’un contexte donné sur le
processus de prise de décision de l’utilisateur. Une manière réaliste serait donc de combiner
ces deux stratégies implicites et explicites pour essayer de diminuer les inconvénients de cha-
cune des deux et obtenir une technique qui serait globalement meilleure.
Un autre aspect de l’acquisition explicite de profil d’utilisateur dans les LBS est que ces
derniers peuvent mieux cibler et alléger cette acquisition explicite pour ne garder que les
questions qui sont effectivement utiles. Par exemple, il est évident qu’il faut éviter de deman-
der à l’utilisateur quel type de cuisine il préfère si la description des restaurants dans la base
de données ne contient pas cette information de type de cuisine. On voit alors comment cette
technique peut alléger le nombre d’interactions explicites entre le LBS et l’utilisateur pour
l’acquisition de ses préférences. En fait le cœur de cette technique réside dans le fait de faire
correspondre ou comparer les données de profil d’utilisateur avec celles du profil des données
dans les bases de données et de prendre l’intersection entre les deux. Nous parlerons des pro-
- 42 -

43. fils de données dans la section suivante. L’acquisition des données d’utilisateur peut être in-
crémentale, augmentant avec le nombre d’interactions entre le LBS et l’utilisateur. Elle peut
être de cette sorte plus intelligente, plus efficace et moins encombrante pour l’utilisateur si
l’on prend en compte d’autres critères comme la facilité d’utilisation, la sélectivité des critères
et la fréquence d’utilisation des services. Il serait aussi peut-être bénéfique de coupler cette
acquisition avec des raisonnements ontologiques visant à calculer des données complémen-
taires sans devoir les demander à l’utilisateur.
VIII. MODELE DE DONNEES
Les profils de données décrivent les services de données en fournissant des informations
sur quelles données et quelles fonctions un service peut offrir. Ils sont similaires aux schémas
de base de données (39) dans le sens qu’ils sont aussi des contenants de métadonnées mais qui
jouent un rôle différent. Un schéma de base de données définit et renforce les règles qui con-
traignent les données à sauver dans une base de données alors qu’un profil de données
informe le LBS sur la nature et les sémantiques des données disponibles chez les fournisseurs
de données. Les profils de données dans les LBS sont construits indépendamment des fournis-
seurs de services qui sont hétérogènes, distribués et interdépendants. Une gestion centralisée
comme dans une base de données traditionnelle n’est pas nécessairement la meilleure straté-
gie pour gérer des profils de données. Des stratégies plus distribuées sont en cours
d’investigation.
IX. LA PROTECTION DE LA VIE PRIVEE
Le problème de la protection de la vie privé s’est posé bien avant l’apparition des LBS.
En effet, il est arrivé avec l’utilisation des bases de données qui stockent toutes sortent
d’informations personnelles sur les personnes sans que ces dernières aient un contrôle sur la
consultation et l’exploitation de ces données. Les LBS ont rajouté une nouvelle dimension à
ce problème dans le sens où, maintenant, une nouvelle donnée personnelle est rajoutée à la
base de données : sa géolocalisation. Ces recherches ont commencé il y a longtemps sur des
projets qui utilisaient la géolocalisation de l’utilisateur comme le projet Active Location
Badge (40) en 1992 qui utilisait déjà la technologie infrarouge pour identifier un utilisateur à
un endroit donné. Maintenant avec la généralisation des LBS, le même problème se pose con-
cernant la protection de la vie privée des utilisateurs.
Le sujet de la protection de la vie privée a souvent été abordé en termes de degré niveau
de sécurité des systèmes qui stockent les informations ainsi que le niveau de sensibilité de ces
dernières. Donc la sécurité des Web Services qui stockent ces informations est regardée de
près et plusieurs études ont été faites pour augmenter ce niveau de sécurité. Dans ce type de
recherches, c’est souvent la protection de l’identité de l’utilisateur qui est au cœur des efforts
des chercheurs. Maintenant, avec l’arrivée des LBS, la géolocalisation de l’utilisateur est con-
sidérée comme faisant partie de son identité au même titre que son nom ou son numéro de
- 43 -

44. sécurité sociale. La seule différence avec ces autres attributs est que cette position change
continuellement et est par conséquent plus attachée aux applications mobiles.
Les LBS posent notamment deux variantes différentes concernant la géolocalisation. La
première étant que les applications sont conscientes de la localisation de l’utilisateur. La se-
conde est le service de suivi de personnes où certaines personnes ont la possibilité de suivre et
de connaitre la localisation actuelle d’autres utilisateurs. Une étude a été réalisée (41) dans ce
sens là et ces deux variantes ont été étudiées à l’université de Copenhague. Cette étude a
comparé la perception des utilisateurs potentiels de LBS de l’utilité de ces deux types de ser-
vices. L’étude a montré que les gens ont jugé ces deux types de services utiles autant l’un que
l’autre. Cependant, ils ont jugé que le service de suivi de personnes par d’autres personnes les
dérangeait nettement plus que lorsque ce ne sont que des applications qui utilisent leur locali-
sation pour leur fournir un meilleur service.
C. NOTRE PROJET
Dans les sections précédentes, nous avons commencé par introduire les services géolo-
calisés en les définissant et en donnant des exemples d’applications passées et actuelles. Nous
avons aussi vu plus en détail tous les composants des ces systèmes LBS et leurs interactions.
Nous sommes ensuite passés sur un sujet en relation avec le premier, à savoir le con-
texte de l’utilisateur d’applications informatiques et plus particulièrement, le contexte
d’utilisateur d’applications mobiles. Nous avons introduit les applications qui se basent sur le
contexte de l’utilisateur ainsi que le concept d’ontologies utilisé pour mieux modéliser le con-
texte. Nous avons aussi introduit la problématique de déduction de contexte.
Notre projet expérimental portera sur les applications LBS utilisant le contexte pour
mieux servir l’utilisateur et plus particulièrement sur cette problématique de déduction du
contexte. Nous avons vu que le contexte est un concept hétérogène et que les sources
d’informations qui permettent de le déduire sont très diverses. Dans notre cas, nous allons
nous focaliser sur comment utiliser les informations personnelles de l’utilisateur pour essayer
d’en déduire son contexte. Par informations personnelles nous entendons les informations
stockées dans l’appareil mobiles comme son agenda, son carnet d’adresse et sa liste de tâches.
- 44 -

45. 3.TRAVAIL PRATIQUE
A. INTRODUCTION
Dans la première moitié de ce rapport, nous avons introduit les services géolocalisés et
ensuite le concept de contexte d’utilisateur dans le cas de ces services géolocalisés. Ces intro-
ductions motivent cette seconde moitié qui portera sur le travail expérimental effectué dans le
cadre de ce mémoire de fin d’études. En effet ce travail porte sur la déduction de contexte
pour les services géolocalisés et plus particulièrement sur la déduction de contexte en utilisant
les données personnelles de l’utilisateur comme son agenda, son carnet d’adresse et sa liste de
tâches.
Pour exploiter ces données personnelles, nous allons d’abord proposer une structure
pour ces outils d’organisation qui serait plus structurée et plus lisible tant pour une machine
que pour l’humain ; c'est-à-dire une structure plus sémantique. Nous allons ensuite, pour
mieux comprendre les comportements idéaux que devraient adopter les LBS dans des situa-
tions concrètes, imaginer et développer un scénario probable d’une journée d’un utilisateur
fictif. Nous allons dresser son agenda, définir ses différents contextes au fur et à mesure de la
journée pour ensuite établir un comportement idéal de son appareil mobile en fonction de
chaque situation. Ayant fait cette étude, nous allons ensuite développer un modèle de gestion
de contexte plus global qui pourrait déduire le contexte d’un utilisateur donné, le modéliser et
agir en conséquence. Enfin nous allons prendre quelques exemples de ces comportements que
devraient adopter un appareil mobile qui gère le contexte et les implémenter dans une applica-
tion réelle qui tourne sur un appareil mobile.
B. VERS UNE STRUCTURE PLUS SEMANTIQUE
Comme nous l’avons dit précédemment, nous allons étudier comment tirer des informa-
tions de contexte à partir des informations contenues dans les outils organisationnels (agenda,
carnet d’adresse et liste de tâches) de l’appareil mobile d’un utilisateur. Ce processus sera
automatique, ce qui signifie que l’application devra lire le contenu de l’agenda d’un utilisateur
et le « comprendre » du mieux qu’elle pourra pour en déduire le contexte de l’utilisateur.
Nous voyons donc quel défi nous relevons ici, vu que ce genre d’application est en cours de
recherche dans le domaine de l’intelligence artificielle. C’est pour cela que pour rendre cette
tâche moins complexe et surtout accroitre les probabilités que cette interprétation soit la plus
fiable possible, nous allons tenter de rendre la structure de ces outils organisationnels plus
lisible par la machine et donc plus sémantique. Une conséquence à ceci est que parfois, ces
outils organisationnels se croiseront et se mettront à jour mutuellement pour rester cohérents
entre eux. Nous verrons des exemples concrets dans la suite.
I. AGENDA
- 45 -

46. L’agenda est un outil qui permet d’organiser et de gérer son temps en le remplissant
d’actions à faire. Chaque action notée dans l’agenda a un temps de commencement et, si dis-
ponible, un temps d’achèvement aussi. De cette manière, les actions se succèdent dans le
temps et remplissent alors les journées de l’utilisateur. Ce sont précisément ces informations-
là que nous allons exploiter pour essayer de déduire le contexte de l’utilisateur vu qu’il y a
normalement une grande corrélation entre l’action qu’est en train d’exécuter l’utilisateur à un
instant donné et son contexte pendant ce même instant.
Pour nous aider à mieux déduire le contexte de l’utilisateur, nous avons décidé de défi-
nir plusieurs catégories d’activités ou d’événements que peut entrer l’utilisateur dans son
agenda. En se basant sur les catégories déjà existantes dans la plupart des agendas électro-
niques et sur une classification qui engloberait la majorité des activités que pourrait noter un
utilisateur dans son agenda, nous allons proposer une structure de ce dernier qui à notre avis
serait meilleure pour déduire le contexte de l’utilisateur. Cette structure donnerait une catégo-
rie à chaque activité ou événement entré dans l’agenda. De plus, dépendamment de la
catégorie choisie, l’utilisateur sera amené à remplir quelques sous-champs concernant cette
activité pour mieux la comprendre. Nous allons expliciter tout cela plus en détail.
Nos différentes catégories sont les suivantes :
a) Meeting :
Cette catégorie regroupera toutes les activités que l’utilisateur pourrait faire avec
d’autres personnes. Une entrée d’agenda dans cette catégorie là indiquerait directement une
information fiable sur le contexte de l’utilisateur. Cette information est que l’utilisateur n’est
pas seul pendant cette activité puisqu’il fait cette activité avec d’autres personnes. Ceci in-
fluence donc clairement son contexte social. On verra que ceci aura de l’incidence sur le
comportement de l’appareil mobile. De plus, lorsque l’utilisateur enregistre une entrée dans
cette catégorie-là il lui est demandé de remplir quelque champ pour mieux décrire cette activi-
té. Ces différents sous-champs sont les suivants :
• Subject : Ce champ contient le sujet de l’activité. Il peut être assez général ou
contenir le titre de cette activité.
• With : Ce sous-champ représente la ou les personnes avec qui l’utilisateur à
prévu de faire cette activité.
• Where : Ce sous-champ contient le lieu où est sensé se tenir cette activité.
• Type : Ce champ est légèrement moins naturel dans le sens où l’utilisateur n’en
voit pas directement l’utilité pour son activité. Mais en fait son utilité est assez
indirecte vue que ce champ est idéal et très important pour la déduction du con-
texte de cette activité. Vu la non trivialité de ce champ, une liste prédéfinie de
choix sera présentée à l’utilisateur pour qu’il fasse un choix facilement et rapi-
- 46 -

47. dement. Les choix prédéfinis que nous proposons sont : « business », « friends »,
« family », « holidays ». Ces champs doivent être normalement mutuellement
exclusifs. Les trois premiers le sont. Si un rendez-vous est professionnel alors il
n’est pas familial, ni amical. Par contre le quatrième choix peut se chevaucher
avec le second et le troisième choix. Des vacances sont passées en famille ou
entre amis. Néanmoins, nous avons quand même décidé de proposer ce choix
pour la particularité qu’a ce contexte spécial.
Donnons maintenant quelques exemples pour cette entrée.
Considérons que l’utilisateur veuille noter dans son agenda un match de football avec
ses anciens amis d’université au terrain de l’Agora.
Il entrera dans son agenda cette activité dans la catégorie meeting et il remplira les sous-
champs de cette catégorie comme suit.
Subject: football game
With: university friends
Where: Agora playfield
Type: friends
Dans cet exemple là par exemple, on peut imaginer que les mots « football » et
« game » peuvent être reconnu par la machine qui en déduira que c’est une activité sportive
par exemple. Dans le champ With le mot « friends » pourrait être reconnu aussi pour en dé-
duire que c’est une activité avec des amis. Ce champ peut aussi contenir le nom d’amis
choisis directement dans le carnet d’adresse où ils seront dans la catégorie « friends ». Le
champ Where contient le nom du lieu de l’activité donc le contenu de ce champs pourrait
pointer directement vers une entrée représentant un lieu dans le carnet d’adresse de l’appareil
mobile. Si une entrée du carnet d’adresse correspond effectivement à ce lieu, alors tous les
détails de cette entrée du carnet d’adresse peuvent être d’une utilité. On peut imaginer qu’au
moment de se rendre au match, l’application extrait directement l’adresse postale de ce lieu et
la fournit à l’application de navigation qui va automatiquement localiser ce lieu et calculer
l’itinéraire pour l’utilisateur depuis sa position actuelle jusqu’au terrain de football. Un numé-
ro de téléphone de ce lieu pourrait être automatiquement extrait et proposé à l’utilisateur si
jamais ce dernier a un retard ou un empêchement pour se rendre au match. Enfin le dernier
champ sera mis à « friends » qui est un des choix de la liste. Notons que ce champ parait re-
dondant avec le champ With dont le mot friends a déjà été extrait. Il est cependant à
remarquer deux choses à ce sujet.
La première remarque est que dans notre exemple, cela relève de la coïncidence que le
champ With contienne le mot « friends ». Il était tout à fait probable qu’il contienne les mots
« football club team » ou encore « John Mayer’s team ». Ces mots ne contiennent pas
d’indication du contexte amical de l’activité alors que c’en est clairement une. Dans le deu-
xième exemple, le nom propre, « John Mayer » pourrait être recherché et trouvé dans le carnet
d’adresse. Ce contact sera peu être sous la catégorie « amis » dans ce carnet d’adresse. Il est
- 47 -

48. aussi à noter que la recherche et la reconnaissance de « John Mayer » comme nom propre
dans ce champ ne sont pas des opérations triviales non plus.
La deuxième remarque est que la déduction de contexte est une procédure qui contient
encore une grande partie d’incertitude de sorte que les contextes déduits ne sont pas fiables à
100%, bien loin de là. C’est pour cela que la redondance est un élément positif dans ce cas
dans le sens où il augmente les probabilités de déduction correcte de contexte en confirmant
certaines suppositions ou hypothèses. C’est pour cela que c’est plutôt une bonne chose d’avoir
reconnu ce mot « friend » dans la catégorie With. Cela augmente la probabilité que ce con-
texte soit bien amical.
Donnons maintenant un second exemple d’entrée possible dans l’agenda. Supposons
que l’utilisateur souhaite enregistrer une réunion de travail avec des personnes du département
marketing de la société où il travaille pour discuter une nouvelle campagne de publicité par
exemple. Il entrera les sous champ suivants dans la catégorie meeting :
Subject: new ad campaign
With: marketing department
Where: office 102
Type: business
Dans ce cas, la même remarque peut être faite pour le champ With. Il peut y avoir une
entrée sous le nom « Marketing Department » dans le carnet d’adresse et donc on peut en tirer
par exemple l’adresse postale ou le numéro de téléphone du département qui pourrait être
utilisé en cas de problème. Le champ Where contient le nom du local où est programmée la
réunion. Il peut très bien y avoir un Web Service dans le bâtiment qui fournit la géolocalisa-
tion du local si on y entre le numéro de local. L’application peut alors faire appel à ce Web
Service et en obtenir la géolocalisation exacte du local dans le bâtiment. Elle pourra alors en-
suite transmettre cette localisation à l’application de navigation. Le type business de l’activité
permettrait par exemple de filtrer les appels non professionnels durant la durée de cette réu-
nion.
Un dernier exemple d’entrée possible dans l’agenda serait un diner familial avec les
grands-parents de l’utilisateur à son domicile. Il remplirait les sous-champs comme suit :
Subject: Diner
With: Grand-parents
Where: home
Type: family
Ici le sujet « Diner » pourrait être reconnu par l’application et en déduire que l’activité
est un repas. Le champ With contient le mot grands-parents qui pourrait être reconnu comme
désignant des membres de la famille et en déduire par conséquent le contexte familial de
l’activité. Le champ Where contient le mot clé « Home » qui sera associé et sémantiquement
connu comme le domicile de l’utilisateur. Son adresse sera par conséquent connue elle aussi
et la navigation depuis le lieu où se trouve l’utilisateur vers son domicile sera déclenchée au-
- 48 -

49. tomatiquement à l’approche de l’heure du diner. Une autre idée est que si le lieu du rendez-
vous ne se trouve pas dans le carnet d’adresse et que l’utilisateur s’y rend donc sans aide de
navigation de l’appareil mobile, ce dernier pourrait noter la position GPS du lieu du rendez-
vous et l’associé en mémoire au nom qu’à entré l’utilisateur dans le champ Where. Enfin le
dernier champ qui indique le type familial de l’activité suscite les mêmes remarques que le
premier exemple.
b) Call
Passons à présent à la seconde catégorie de l’agenda. Cette catégorie sera utilisée quand
l’utilisateur voudra enregistrer des rappels d’appels qu’il voudrait passer dans le futur. Par
exemple lorsqu’il reçoit un message qui nécessite qu’il y réponde par un appel mais qu’il ne
peut pas y répondre à ce moment là.
Un avantage de la catégorisation de l’agenda est que, maintenant, dépendamment de la
catégorie choisie, l’utilisateur aura plus ou moins de sous-champs pertinents à remplir. Alors
qu’avant, toutes les activités étaient considérées de la même manière et l’utilisateur était par
exemple ramené à remplir un champ Where alors qu’il veut noter un appel à faire par la suite.
Pour cette catégorie Call, les champs à remplir sont moins nombreux :
• Who : Ce champ contiendra le nom ou un mot clé faisant référence pour
l’utilisateur à la personne qu’il doit appeler.
• Subject : Ce champ contiendra un ou plusieurs mots contenant le sujet ou la mo-
tivation de cet appel.
• Type : Ce champ est assez similaire à celui de la catégorie meeting mais l’utilité
est assez particulière. De plus ce champ ne serait vraiment utile que pour les so-
ciétés qui souhaitent contrôler les abonnements téléphoniques de leurs employés.
C’est pour cela que nous ne faisons que proposer ce champ de manière option-
nelle dans notre structure d’agenda. L’idée de ce champ vient des abonnements
téléphoniques professionnels qui font une distinction entre les appels profes-
sionnels et les appels personnels pour des raisons de séparation des facturations.
Une autre raison qui apparaitra dans la suite sera par exemple que les appels pro-
fessionnels sont plus aptes à être passés pendant les heures de travail alors que
les appels personnels sont plus pour une portion de temps ou l’utilisateur profite
de son temps libre.
Une particularité de cette catégorie Call est qu’elle sera très liée à un autre outil
d’organisation : la liste de tâches. En effet un appel entré dans la catégorie Call sera considéré
comme une tâche à faire et sera par conséquence automatiquement ajouté à la liste de tâches
dans l’autre outil. Ces deux outils seront donc cohérents entre eux et s’échangeront des infor-
mations sémantiques.
- 49 -

50. Il est donc à noter que cette fonction sera tout aussi accessible par l’outil de liste de
tâches que par l’agenda.
c) Birthday
Cette catégorie sera utilisée par exemple pour noter la date d’anniversaire d’une per-
sonne dont on vient de connaitre cette date et qu’on ne souhaite pas oublier. Similairement à
la catégorie précédente, celle-ci est aussi en étroite relation avec un autre outil organisation-
nel : le carnet d’adresse. En effet, une fois rentré dans l’agenda, une entrée correspondante
sera créée dans le carnet d’adresse avec cette date de naissance. Si jamais ce contact existe
déjà dans le carnet d’adresse, cette date de naissance sera simplement ajoutée comme détail de
ce contact et un rappel sera activé à chaque anniversaire.
Les sous-champs de cette catégorie seront les suivants :
• Who : Ce champ contiendra le nom de la personne dont l’anniversaire souhaite
être ajouté. Ce champ proposera aussi de parcourir le carnet d’adresse si jamais
ce contact y existe déjà.
• Date of birth : Ce champ contiendra la date de naissance du contact et par con-
séquent à chaque rappel d’anniversaire, son âge sera automatiquement calculé et
indiqué à l’utilisateur.
De plus, on peut très bien imaginer qu’un SMS de félicitations soit créé par
l’application à partir de modèles de SMS. Ce message sera ensuite proposé à l’utilisateur pour
approbation ou modification avant envoie. Le numéro du contact sera automatiquement ex-
trait du carnet d’adresse.
On peut aussi imaginer que l’application propose d’ajouter automatiquement à la liste
de tâche que l’utilisateur doit aller acheter un cadeau à la personne qui fêtera son anniversaire.
Mais ceci dépend naturellement du degré de relation social qui lie les deux contacts.
d) Note
Cette catégorie ne représente pas spécialement une activité mais répond au besoin qu’à
parfois l’utilisateur de noter une idée ou une phrase ou un nom de film par exemple pour ne
pas l’oublier et pouvoir se le rappeler plus tard.
Cette catégorie comprendra par conséquent juste un sous-champ Subject pour noter
l’idée ou la phrase à se rappeler.
- 50 -

51. Nous voyons donc d’après ces exemples l’utilité d’avoir une structure sémantique de
cette sorte. En effet, pour l’utilisateur, une entrée dans l’agenda en un seul champ comme
« Diner with grand-parents at home » a peut-être la même signification que la structure sé-
mantique en catégories et en sous-champs mais pour la machine, la différence est remarquable
de part la déduction de contexte et les réactions utiles que peut avoir l’application en lisant et
« comprenant » ces champs.
II. CARNET D’ADRESSE
Le carnet d’adresse est une base de données qui contient une liste d’entrées qui repré-
sentent soit des personnes, des lieux ou même des sociétés ou des administrations publiques
etc. Toute entité capable d’avoir un numéro de téléphone, une adresse postale, un e-mail etc.
peut être entrée dans cette base de données.
De même que pour l’agenda nous allons proposer une structure sémantique sous forme
de sous-champs pour mieux structurer cet outil. Cette structure n’est pas aussi innovante que
celle que nous proposons pour l’agenda car la plus-part des appareils portables proposent déjà
tous ces champs.
Nous allons donc donner une liste non exhaustive de sous champs que doit contenir un
carnet d’adresse pour bien répondre aux demandes des LBS.
nom : Ce champ contiendra en fait plusieurs sous champs comme le nom de fa-
mille, le prénom, un deuxième prénom et un nom de jeune fille par exemple
numéro : De même, ce champ contiendra plusieurs sous-champs pour les diffé-
rents numéros que peut avoir une personne : un numéro de GSM professionnel,
personnel, un numéro de domicile, un numéro fixe professionnel, un numéro
fixe de seconde résidence etc.
Adresse postale : Ce champ contiendra des sous champs d’une part pour les dif-
férentes adresses qui peuvent être liées à une personne (professionnelle,
personnelle, personnelle secondaire etc.) mais aussi que chacune de ces adresses
sont divisées sémantiquement en plusieurs sous-champs comme le nom de la
rue, le numéro, le code postal, le quartier, la ville et le pays.
Les adresses Web : Ce champ contiendra les différentes adresses emails que
peut utiliser une personne mais aussi les différents site web ou blogs qui lui sont
associés.
Date de naissance : Ce champ contiendra la date de naissance de la personne et
peut être utilisé comme créer une alerte d’anniversaire, un SMS de félicitations
ou une tâche d’achat de cadeau d’anniversaire.
- 51 -

52. De cette manière les applications pourront accéder de manière très précise aux données
dont elles ont besoin pour accomplir leur tâches diverses. Nous verrons plusieurs exemples
dans la suite.
III. LISTE DE TACHES (TODO LIST)
Une liste de tâches représente comme son nom l’indique une liste qui contient une liste
de tâches que quelqu’un doit faire. C’est un excellent outil d’organisation qui s’est imposé par
sa simplicité et son utilité. Il est notamment maintenant implémenté dans tous les appareils
mobiles et l’utilisateur peut l’utiliser pour y enregistrer toutes sortes de tâches qu’il souhaite
accomplir dans le futur. C’est donc une occasion d’augmenter la qualité des services que rend
l’appareil portable à l’utilisateur en augmentant la pertinence de ses actions et réactions au
contexte.
L’idée à exploiter ici est qu’en général, si l’utilisateur ne tient qu’une seule liste de
tâches, ces dernières sont de natures ou de catégories différentes. Il faut donc trouver une
classification ou une catégorisation des tâches que l’utilisateur a à faire. En regardant plu-
sieurs exemples de tâches quelconques qu’un utilisateur doit faire, on voit qu’on peut choisir
comme typage par exemple, des tâches professionnelles, des tâches personnelles, des tâches
familiales ou des tâches à faire entre amis. On peut voir les exemples suivants
Une tâche « send the financial report to Tom » serait de type professionnel.
Une tâche « watch the new U2 music video » serait de type personnel.
Une tâche « watch the Shrek DVD » pourrait être classés dans les tâches familiales si
l’utilisateur pensait le voir en famille.
Une tâche « check out the new neighborhood pub » serait une tâche à faire entre amis.
L’idée derrière cette classification est en fait d’essayer de rappeler les bonnes tâches au
bon moment. C'est-à-dire que lorsqu’on est au bureau par exemple, on aimerait bien que notre
appareil mobile nous rappelle que l’on doit envoyer un rapport financier à un collègue plutôt
que de nous rappeler que l’on doit regarder Shrek avec la famille. La même chose se passe
lorsqu’on est en famille un soir, on préfèrerait voir sonner le rappel de Shrek plutôt que celui
du rapport financier que l’on doit envoyer. Donc avec cette classification, une application
serait capable de rappeler les bonnes tâches aux bons moments.
Une autre idée qui viendrait augmenter la pertinence des rappels serait de prévoir un
champ supplémentaire lors de l’encodage de la tâche où l’utilisateur pourrait entrer une esti-
mation du temps qu’il pense que cette tâche pourrait prendre pour être effectuée. Cette
initiative vient du faite que certaines tâches durent plus que d’autres et que dans l’agenda de
la journée, une application peut facilement calculer le temps que l’utilisateur a encore devant
lui avant l’heure de la prochaine tâche. Elle pourra donc lui proposer en conséquence la tâche
qui conviendrait le mieux à un instant donné.
- 52 -

53. Un exemple est que l’utilisateur a deux tâches encodées dans sa liste de tâches avec les
estimations de durées suivantes qui sont :
« read the nanotubes article » 15min.
« Take clothes to laundry » 1h.
Si maintenant il est 13h30 l’utilisateur vient de finir son déjeuner par exemple et que
dans son agenda il a un rendez-vous à 14h, l’application qui tient en compte les durées des
tâches lui proposera de lire l’article sur les nanotubes et non d’emmener son linge au lavoir.
Un inconvénient de ces champs est qu’ils sont ennuyants pour l’utilisateur qui souhaite
encoder sa tâche le plus rapidement et le plus simplement possible dans son appareil mobile.
Ceci n’est cependant plus un problème si ces champs sont automatiquement remplis par syn-
chronisation de calendrier et de carnet d’adresse en un PC et l’appareil mobile. On supposera
alors que ces champs seraient plus facile à remplir sur un ordinateur que sur un clavier
d’appareil mobile. Pour le champ type de la tâche par exemple, une valeur par défaut undefi-
ned serait attribuée jusqu’au moment où l’utilisateur souhaite explicitement spécifier la
catégorie de cette tâche.
Ayant expliqué nos motivations nous proposons donc finalement la structure de l’outil
de liste de tâches :
Subject : le nom ou l’idée de la tâche à faire
Priority : Ceci serait une liste de trois choix possible « low », « medium », et
« high ». Cette priorité serait un critère supplémentaire de selection de tâches à
rappeler à l’utilisateur le plus tôt ou le plus souvent. Elle aura aussi comme va-
leur par défaut medium ou undefined.
Type : une liste de 4 choix : « business » « personal » « family » « friends »
avec une valeur « undefined » par défaut .
Estimated duration : une liste de choix : « 15min », « 30 min », « 1h »,
« 1h30 », « more », « undefined ».
De cette manière les tâches auront un contenu sémantique supplémentaire qui permet-
trait aux applications mieux les traiter automatiquement et de manière plus pertinente afin
d’augmenter au final la qualité des comportements et des actions des appareils mobiles.
C. SCENARIO D’UNE JOURNEE
Dans cette partie nous allons créer un scénario de la journée d’un utilisateur pour mieux
comprendre, étudier la notion de contexte, sa déduction et le comportement idéal de l’appareil
mobile dans ce cas là.
Concrètement, à partir de ce scénario d’une journée, nous allons déduire un agenda pro-
bable qu’aurait pu encoder l’utilisateur dans son appareil mobile. Ensuite, nous allons illustrer
à chaque étape de cette journée les changements de contexte de l’utilisateur. Enfin, nous al-
- 53 -

54. lons, pour chaque étape ou contexte de la journée, proposer le comportement idéal de
l’appareil mobile.
I. SCENARIO ET AGENDA
Soit Tom l’utilisateur de l’appareil mobile. Le scénario que nous avons choisi est une
journée de Tom qui se déroulera comme suit :
Tom se réveille vers 9h pour se rendre en voiture à une réunion à son bureau à 10h. A
midi, Tom a rendez-vous avec sa sœur Maria pour déjeuner dans un restaurant italien nommé
« Luigi Pastas ». En début d’après-midi, il appelle son supérieur, John Parker, pour l’informer
du résultat de la réunion du matin. A 15h, Tom a rendez vous avec des collègues de travail à
l’hôpital Erasme pour travailler sur un projet. Ensuite, à 18h, Il se rendra à un bar nommé
« La Taverne » où il a rendez vous avec des amis membres de son club de Hockey. Enfin, à
20h, Tom a invité ses grands-parents chez lui à diner.
Pour cette journée supposons que Tom ait rempli son agenda dans son appareil mobile,
il serait sous cette forme :
10h00: meeting @ office
12h00: lunch @ “Luigi Pastas” with ‘Maria Sanchez’
14h00: Call John Parker about the morning meeting.
15h00: teamwork @ Erasme hospital/ local A 234 with colleagues
18h00: Drink @ Bar La Taverne with hockey club members
20h00: Dinner @ home with grandparents.
Supposons que le symbole @ signifie que cette activité se déroule dans ce lieu et que ce
lieu et code dans le champ sémantique Where de son agenda. Supposons que with signifie que
les personnes avec qui il fait une activité sont codées dans le champ sémantique with de
l’agenda.
Supposons ensuite que Office, Home, Luigi Pastas, Erasme et Bar La Taverne sont des
entrées dans le carnet d’adresses de Tom et que leurs adresses postales et numéros de télé-
phone sont aussi codés.
II. CONTEXTE A CHAQUE INSTANT
Une première chose à faire est de diviser la journée en plusieurs étapes où le contexte
varie. Ensuite pour chacune de ces étapes, nous allons déterminer le contexte de Tom à cet
instant donné. Le tableau suivant représente pour chaque étape, son numéro, son heure de
début, sa description ainsi que le contexte de Tom pendant cette étape.
Numéro heure Description de l’étape Contexte pendant l’étape
- 54 -

55. d’étape
1 Avant Tom dort chez lui Sommeil nocturne
9h
2 9h son réveil sonne. Il se prépare pour se prépare à sortir de chez lui
aller à la réunion
3 9h40 sort de chez lui et prend sa voiture conduit sa voiture vers son
jusqu’à son bureau bureau
4 10h la réunion commence en réunion professionnelle
5 11h45 la réunion se termine et Tom prend sa conduit sa voiture pour aller
voiture pour aller au restaurant au restaurant
6 12h15 arrive au restaurant et déjeune avec sa déjeune avec sa sœur
sœur
7 14h00 quitte le restaurant et va déposer sa sa voiture vers chez lui
voiture chez lui
8 14h30 prend le métro pour aller à Erasme dans le métro vers Erasme
9 14h50 arrive à Erasme et se dirige vers le se dirige vers le local
local
10 15h00 Le travail de groupe commence Travail en groupe profession-
nel
11 17h30 quitte Erasme et se dirige vers le Bar se dirige en métro vers le Bar
La Taverne La Taverne
12 18h30 arrive au bar avec ses amis dans un bar
13 19h45 quitte le bar vers chez lui se dirige en bus vers chez lui
14 20h00 arrive chez lui pour accueillir ses dine avec ses grands parents
grands parents et diner
15 23h00 Tom s’endort Sommeil nocturne. Même que
numéro 1
TABLEAU 3 - LES DIFFERENTES ETAPES DE LA JOURNEE AVEC LE CONTEXTE CORRESPONDANT
Nous venons de diviser la journée en plusieurs étapes. Pour chacune d’elles nous avons
aussi décrit le contexte. Reste à définir comment devrait réagir l’appareil mobile en consé-
quence.
III. COMPORTEMENT INTELLIGENT IDEAL DU GSM
Nous allons maintenant donner le comportement idéal que devrait adopter un appareil
mobile qui s’adapte et réagit au changement de contexte dans le cas du scénario de Tom.
1. Avant 9h, Tom dort chez lui. C’est la nuit. L’application lit l’agenda de la journée.
Elle trouve le premier rendez vous à 10h au bureau. Il consulte l’historique des jour-
nées précédentes et trouve que Tom prend quasi-toujours sa voiture pour aller au
bureau. L’application a aussi une fonction navigateur du type GPS, donc elle a une
estimation assez précise du temps de trajet entre le domicile et le bureau. Il addi-
tionne à ce temps, le temps que prend habituellement l’utilisateur pour se préparer le
matin ou alors le temps qu’il a entré lui-même pour cette action. Elle obtient alors le
temps entre l’heure du réveil et l’heure du début de la réunion. Elle a donc mainte-
- 55 -

56. nant calculé l’heure idéale pour faire sonner le réveil de l’utilisateur. Durant ce
temps de sommeil, les sonneries sont désactivées. Le filtrage des appels est activé.
2. À 9h, Tom est chez lui. Il se prépare à sortir vers son bureau. Le GSM lui affiche le
temps qu’il lui reste pour quitter son domicile. Dès le réveil, le filtrage d’appel est
désactivé. Le volume de sonnerie est réglé à moyen.
3. À 9h40, Tom conduit sa voiture vers son bureau. Le GSM se met en mode naviga-
tion et affiche l’itinéraire du domicile au bureau. Remarque : avec le temps,
l’utilisateur connait par cœur le chemin entre le domicile et le bureau donc il peut
désactiver ces fonctions de navigation. Néanmoins, elle s’activera automatiquement
si la destination un autre jour n’est pas le bureau. Durant la conduite, le GSM passe
en mode kit main libre, et tous les appels sont transférés vers le système audio du
véhicule.
4. À 10h, Tom est en réunion professionnelle. Les sons du GSM sont désactivés. Les
appels sont filtrés sauf peu être les appels professionnels comme ceux du supérieur
de Tom par exemple. Pendant ce temps, l’application continue à lire l’agenda, et
trouve que le prochain rendez-vous est à midi dans un lieu appelé Luigi Pastas.
L’application parcourt alors le carnet d’adresse à la recherche d’une entrée appelée
Luigi Pastas et la trouve. Elle vérifie le champ adresse pour voir si une adresse et
disponible et la trouve. Elle fait donc appel à l’application de navigation pour avoir
une estimation du temps de trajet depuis le bureau jusqu’au restaurant. Le GSM af-
fiche alors un compte à rebours pour quitter le bureau et arriver à temps au
restaurant.
5. À 11h45 Tom est retard sur son planning, il finit la réunion et se dirige vers sa voi-
ture. L’application, qui a calculé ce retard, cherche dans le carnet d’adresse une
entrée sous le nom de « Maria Sanchez ». Elle la trouve et trouve que ce contact et
dans la catégorie family, mais trouve aussi son numéro de portable. Elle propose
alors en un seul click à Tom de composer son numéro pour la prévenir du retard ou
alors compose un SMS déjà tout prêt sous la forme. « Salut Maria, excuse moi,
j’aurai 18min de retard, j’arrive, Tom. ». Tom choisi alors l’option qu’il veut en un
seul click. Tom est donc dans sa voiture et se dirige vers le restaurant, l’application
de navigation lui indique le chemin à l’aide d’instructions vocales pour ne pas per-
turber sa vision sur la route.
6. À 12h18 Tom déjeune avec sa sœur. L’application a trouvé le lien familial, elle filtre
alors les appels professionnels, adapte le niveau de sonnerie à un niveau moyen ou
vibreur. Pendant le repas, l’application continue à lire l’agenda de la journée. Elle
trouve que Tom a un appel à passer à 14h, et qu’il doit de rendre à Erasme à 15h. La
particularité ici est que l’application lit aussi que Tom va à un bar à 18h. Son but est
d’éviter que Tom ne conduise en état d’ébriété. Elle voit que le Bar n’est pas trop
loin d’Erasme et donc elle anticipe cet événement en proposant à Tom de d’abord
déposer sa voiture chez lui pour ensuite de se rendre à Erasme en transport en com-
mun. L’application a accès aux Web Services des transports en commun et connait
et peut par conséquent avoir accès aux horaires des métros etc. pour calculer le trajet
et le temps de trajet du restaurant jusqu’au domicile en voiture puis du domicile jus-
qu’à Erasme en transport en commun. Rappelons que Tom est encore au restaurant.
L’application propose et explique à Tom son initiative de changement de trajet. Tom
- 56 -

57. peut soit accepter soit refuser. Supposons qu’il accepte. L’application lui affiche
donc le compte à rebours pour quitter le restaurant.
7. À 14h00 Conduit sa voiture vers chez lui, il est guidé par le système de navigation,
ses appels ne sont plus filtrés et sont dirigés vers le système audio de la voiture.
8. À 14h30 il est dans le métro vers Erasme, l’application sait qu’il est en trajet dans
un métro, elle lui propose donc de passer l’appel qu’il a noté dans ses tâches à faire.
Elle a bien sûr lu le nom de John Parker dans l’agenda et est allée chercher son nu-
méro dans le carnet d’adresse. Elle affiche aussi à Tom le sujet de l’appel.
9. À 14h50 Tom arrive à Erasme. L’entrée dans l’agenda indique : « teamwork @
Erasme hospital/ local A 234 with colleagues. Elle tente alors de se connecter au
Web Service d’Erasme pour essayer de localiser le local A 234. Supposons qu’elle
trouve un Web Service à qui elle fournit le nom du local et qui lui retourne la posi-
tion de ce local. Elle guide alors Tom à l’intérieur du bâtiment vers le local A 234 en
utilisant une technologie de localisation par wifi par exemple.
10. À 15h00 Le travail en groupe commence, le contexte professionnel déduit implique
l’application d’un filtre pour les appels non professionnels. Pendant la réunion,
l’application se renseigne sur le trajet depuis Erasme jusqu’au bar La Taverne. Re-
marquons qu’à l’étape 6 l’application a lu le nom du bar La Taverne dans l’agenda.
Elle est allée le chercher dans le carnet d’adresse. Elle l’a trouvé et en a extrait
l’adresse postale. Elle a ensuite localiser le bar. Donc, pendant la réunion
l’application calcule le trajet et la durée du trajet jusqu’au bar et affiche le temps
restant à Tom pour quitter la réunion. Elle lui affiche ensuite les horaires de métro
pour se rendre au bar à temps. De plus, ayant détecté que le bar est une activité qui
demande d’avoir de l’argent sur soi en général, elle localise le distributeur de billet
le plus proche et propose à Tom de l’y guider d’abord.
11. À 17h30 Il se dirige en métro vers le Bar La Taverne. Le volume de la sonnerie est
réglé au maximum et le filtrage d’appel est désactivé. L’application lui indique dans
combien d’arrêts il doit descendre et quelle correspondance prendre etc.
12. À 18h30 Il est avec ses amis dans le bar. Les appels professionnels sont filtrés. Le
temps de trajet jusque chez lui est de nouveau calculé et un compte à rebours pour
quitter le bar est affiché.
13. À 19h45 il dirige en bus vers chez lui. L’application lui indique quels transports
prendre et jusque quels arrêts.
14. À 20h00, Tom dine avec ses grands parents. Le volume de la sonnerie est réglé en
conséquent et les appels professionnels ou d’amis sont filtrés. Un rappel de l’heure
du premier rendez-vous du lendemain est affiché comme note pour que Tom sache à
quelle heure à peu près il doit aller se coucher.
15. À 23h00, Tom dort. Ce contexte est le même que le premier contexte.
Nous venons donc de voir et d’établir un scénario complet avec l’agenda qui y corres-
pond ainsi que le contexte de l’utilisateur à chaque instant de la journée. Nous avons ensuite
établit et donné des exemples de comportements nouveaux que les GSM pourraient adopter
s’il avait accès aux LBS et qu’ils étaient structurés de manière plus sémantique et que les ap-
- 57 -

58. pareils mobiles étaient équipés des technologies nécessaires comme le routage par Wifi par
exemple.
D. ETABLISSEMENT D’UN MODELE DE GESTION DE CON-
TEXTE
I. IDEES DE BASES ET INSPIRATIONS
Lors de ce travail pratique, notre approche globale a été la suivante. En se basant sur les
possibilités d’utilisation des LBS ainsi que sur les facteurs qui facilitaient la déduction de con-
texte, nous avons proposé une structure plus sémantique pour les outils organisationnels de
l’appareil mobile. Les outils organisationnels étudiés sont l’agenda, le carnet d’adresse et la
liste de tâches. Cette structure plus sémantique faciliterait grandement la lecture par des appli-
cations LBS des données qui y sont stockées. Ces applications pourraient ensuite plus
facilement procéder à la déduction du contexte de l’utilisateur à partir de ces données.
Après avoir proposé cette structure, nous avons voulu plus s’approcher de la notion de
contexte pour mieux la connaitre dans un but de mieux la modéliser. Vu la notion tellement
vaste et la diversité des contextes dans lesquels peut se trouver un utilisateur, nous avons vou-
lu s’approcher le plus possible de cette notion. Et pour cela, nous avons imaginé un scénario
complet de journée probable que pourrait avoir un utilisateur en étudiant tous les détails du
processus comme les entrées exactes qu’il a dans son agenda, tous les contextes par lesquels il
passe pendant cette journée, et tous les comportements idéaux que devrait avoir son appareil
mobile à chaque instant.
A partir de ces observations, nous avons ensuite essayé de cerner les différentes situa-
tions dans lesquelles se retrouvait l’utilisateur tout au long de sa journée pour construire un
modèle de contexte qui pourrait englober un maximum de ces situations. La construction de
ce modèle se fait à la section suivante.
Notre idée de base pour modéliser le contexte est de le diviser en plusieurs parties ou
sous catégories qu’on appellera des « Micro-Contextes ». C’est l’agrégation de ces micro-
contextes qui définira le contexte complet de l’utilisateur à un instant donné. Chaque micro-
contexte représente un seul aspect particulier du contexte global. Cette modélisation en subdi-
visant le contexte en micro-contextes s’avère très appropriée et pratique vu la forte exogénéité
des sources de contexte et des types de micro-contextes. Chaque micro-contexte s’occupe de
modéliser un type différent d’information de contexte et peut donc avoir une source différente
d’information.
Pour mieux comprendre cette notion de micro-contexte, reprenons l’exemple précédent
du scénario complet et plaçons-nous à 9h55 juste avant la réunion de bureau que l’utilisateur a
à 10h sur son lieu de travail. Il est le premier dans la salle de réunion en attendant le début. On
- 58 -

59. connait le contexte global de la situation. Maintenant nous allons étudier cette dernière en
utilisant notre modèle de décomposition de contexte en micro-contextes. En effet on peut di-
viser la description de la situation ou du contexte en plusieurs propriétés. Le premier exemple
est que l’on peut dire que l’utilisateur se trouve dans un contexte professionnel par opposition
à un contexte familial ou entre amis. Cette déduction est faite par le fait que l’utilisateur se
trouve sur le lieu de travail et qu’il a une réunion qui commence dans 5 min. Cet exemple
montre que le fait de dire que l’utilisateur se trouve dans une situation professionnelle est une
description partielle de son contexte global que l’on a expliqué précédemment. On a donc ici
explicité un micro-contexte de la situation. Un deuxième exemple de micro-contexte est de
dire que l’utilisateur est en avance sur son rendez-vous. En effet il 9h55, il est sur le lieu de la
réunion mais il n’est pas encore l’heure de la réunion. Ce micro-contexte est par opposition au
fait d’être à l’heure ou en retard. Il est ainsi possible d’imaginer toute une série d’autres mi-
cro-contextes décrivant un aspect particulier du contexte global.
On a donc ici subdivisé la situation en une série de micro-contextes qui peuvent facile-
ment être modélisés par une application. En effet, les micro-contextes se résument à un
attribut, une variable ou même à un objet instance d’une classe dont il faut définir les attri-
buts. On peut en effet imaginer une variable « Schedule Status » à laquelle l’application, selon
le contexte, affecte soit la valeur early, soit onTime soit late soit over. De même, on peut ima-
giner une seconde variable nommée socialType à laquelle, selon le contexte, on affecterait soit
la valeur professionnal, soit family soit friends.
Donc en faisant ceci, nous avons réussi à modéliser le contexte global à l’aide de micro-
contextes distincts qui représentent chacun un aspect distinct du contexte global. La seconde
étape maintenant est qu’en fonction du contexte déduit comme ci-dessus, l’application LBS
adopte le meilleur comportement et effectue les actions qu’il faut. En étudiant les différentes
valeurs des micro-contextes, l’application fait le choix d’effectuer telles ou telles actions. Elle
peut aussi se baser, en plus des micro-contextes de la situation actuelle, sur l’historique et les
préférences passées de l’utilisateur. Reprenons le même exemple. Supposons que la réunion
commence. Un micro-contexte pourrait coder que l’utilisateur est occupé et un second pour-
rait coder que l’utilisateur est en contexte professionnel. Une réaction idéale que l’application
pourrait avoir en conséquence à ces deux micro-contextes est de mettre le GSM en mode si-
lencieux et/ou de filtrer les appels non professionnels pendant toute la durée de la réunion.
Après l’introduction de ces idées de base sur lesquelles nous avons construit notre mo-
dèle, nous allons maintenant expliciter ce dernier ainsi que son fonctionnement. Ce modèle
sera à son tour la base de l’application qui tournera sur les appareils mobiles et qui se chargera
de la déduction du contexte de l’utilisateur à tout instant.
II. DESIGN
Avant d’expliquer le modèle, rappelons que le but de ce dernier est de lire et d’utiliser
les informations personnelles de l’utilisateur contenues dans ses outils organisationnels
(agenda, carnet d’adresse, liste de tâches) afin d’en dégager le contexte de l’utilisateur à un
- 59 -

60. moment donné pour ensuite, effectuer les actions les plus pertinentes pour ce contexte donné.
Nous allons maintenant expliquer les différents étapes ou composantes de notre modèle. Le
modèle est structuré en couches qui représentent en quelque sorte la chaine de traitement de
l’information depuis sa lecture jusqu’aux actions entreprises en conséquences. Les différents
sous-chapitres suivants représentent chacun une couche du modèle.
a) L ES ENTREES
A partir de cette définition, nous pouvons déjà dire que le modèle aura comme données
d’entrées les informations personnelles de l’utilisateur. En effet ces informations, et en parti-
culier son agenda, représentent la principale source d’information de déduction de contexte.
Un rendez vous au bureau de 10h à 11h sera noté dans l’agenda. A partir de cette lecture, le
modèle pourra déduire que de 10h à 11h l’utilisateur sera au bureau, en réunion. Il pourra
donc en déduire qu’il ne faut pas le déranger et filtrer les appels non-professionnels par
exemple. Donc afin d’effectuer ces actions au bon moment, le modèle a aussi besoin de con-
naître l’horloge pour savoir à quel instant commence la réunion par exemple. Par conséquent,
notre modèle aura aussi comme entrée l’horloge de l’appareil mobile. Une autre entrée sera
utilisée aussi mais son utilité sera plus claire à expliquer dans une prochaine étape du modèle.
Cette entrée est l’historique des actions ou des choix qu’a fait l’utilisateur antérieurement dans
un contexte similaire que le contexte actuel. Les trois entrées d’informations citées plus haut
représentent la première couche de notre modèle.
Ces données sources vont être ensuite lues pour en extraire les informations pertinentes
à la déduction de contexte de l’utilisateur.
b) L’ EXTRACTION DES DONNEES
Une couche du modèle sera dédiée à cette tâche-ci. Elle sera responsable de lire les dif-
férentes entrées de l’agenda, et plus particulièrement l’activité actuelle et la suivante. En effet,
on a vu que l’application devra déduire le contexte actuel de l’utilisateur et par conséquent
son activité actuelle. De même, on a aussi vu que l’application devra connaitre la prochaine
activité qu’a prévu l’utilisateur pour par exemple, connaitre son lieu géographique pour en-
suite estimer le temps de trajet jusqu’à cet endroit, pour enfin afficher à l’utilisateur l’heure
maximale à laquelle il devra terminer son activité actuelle. Cette couche devra donc, pour
chaque activité, aller extraire l’heure de début, de fin, le lieu ainsi qu’éventuellement les noms
des différentes personnes impliquées.
En plus de ces données, cette couche sera amenée à lire le contenu même du sujet de
l’activité qui pourrait être par exemple « drink at bar La Taverne » comme dans le scénario
précédent. Cette couche devra par exemple reconnaitre certains mots-clés importants à la dé-
duction de contexte comme par exemple cinema, hospital, museum, theater, opera, concert,
- 60 -

61. show, etc. pour les lieux ou encore, birthday, holidays, diner, lunch, breakfast, game, jogging,
fitness etc. pour les activités. Les lieux comme les cinémas, les théâtres, les hôpitaux, les opé-
ras et les musées sont importants à reconnaitre parce qu’ils sont, entre autres, considérés
comme des lieux sensibles aux bruits et où un téléphone qui sonne pourrait déranger autrui. Il
serait donc utile que cette couche extrait ces mots là. De même pour les noms d’activités, il
serait important de savoir que l’utilisateur est en train de faire du jogging par exemple pour
pouvoir soit filtrer certains appels non désirés ou encore mettre la sonnerie de l’appareil au
niveau maximal.
Néanmoins, il faut essayer d’éviter un maximum cette technique-là parce que si effecti-
vement elle permet de déduire un contexte de manière très précise et correcte, elle présente un
inconvénient majeur. La diversité des types de lieux et des activités fait que cette technique
n’est pas efficace et ne couvrira jamais la majorité des situations. En effet pour faire cela, il
faudrait coder dans une application toutes ces situations et leurs descriptions pour qu’à chaque
mot-clé, un dictionnaire soit parcouru et la situation identifiée. Cette technique demande donc
une taille de programme inenvisageable mais surtout qu’il est très difficile d’écrire un algo-
rithme capable de lire le langage naturel et le découpé correctement vu la grande ambigüité de
ce dernier. Cette technique est par conséquent difficilement utilisable.
Un dernier élément que cette couche doit extraire est l’heure actuelle ou l’horloge. Elle
permettra de connaitre à tout instant si une activité s’approche dans le temps, si elle a com-
mencé, si elle est en cours ou alors si elle est terminée. Ceci peut être fait par simple
comparaison de l’horloge avec les heures de début et de fin d’une activité que cette même
couche a extraite.
c) L A DEDUCTION DE CONTEXTE
Maintenant que nous avons toutes les données pertinentes extraites des entrées, nous
devons effectuer la tâche la plus importante et qui est la tâche centrale de tout ce travail : la
déduction de contexte. Cette couche de modélisation de contexte sera construite comme cela a
été expliqué dans la section précédente qui donnait les idées de bases de la construction du
modèle. En effet, c’est dans cette couche ci que seront modélisés les différents micro-
contextes où chacun aura un ensemble limité de valeurs qu’il peut prendre. Nous avons déjà
parlé du micro-contexte qui code le Social Type 1. Ce micro-contexte peut prendre unique-
ment l’une des trois valeurs suivantes : Professional, Family, Friends. La couche de contexte
lit les données que lui fournit la couche précédente et prend alors la décision de mettre un
micro-contexte à telle ou telle valeurs. Elle est ainsi responsable d’assigner des valeurs à cha-
cun des micro-contextes pour ainsi constituer le contexte global ou la situation dans laquelle
se trouve l’utilisateur. Un autre exemple de micro contexte que nous avons déjà donné est le
fait que l’utilisateur soit plutôt en avance, à temps, ou en retard pour un rendez-vous ou une
activité ou encore que cette dernière est déjà terminée. Ce micro-contexte est nommé schedule
Status et ne pourra donc évidemment porter qu’une des quatre valeurs suivantes : early, on-
Time, late ou over.
- 61 -

62. Expliquons maintenant par quels mécanismes sont attribuées les valeurs aux micro-
contextes. Nous avons déjà expliqué l’exogénéité des sources d’information de contexte et par
conséquent celle des micro-contextes. Pour la même raison, chaque micro-contexte a ses
propres mécanismes de décision qui doivent donc être définis dans le modèle. Il y a une multi-
tude de micro-contextes imaginables pour caractériser un contexte. Pour en choisir quelques
uns, nous nous sommes inspirés du scénario complet de journée présenté à la section précé-
dente pour voir quels étaient les aspects pertinents d’un contexte que l’on devrait modéliser
pour arriver au comportement idéal décrit à la fin de cette même section. Notre sélection a
porté sur les micro-contextes suivants :
• Social Type 1 : Ce micro-contexte permet de coder si l’utilisateur se trouve plu-
tôt dans un contexte professional, family ou friends. Un rendez-vous au bureau
pour une réunion sur, disons, un plan marketing doit être classé comme micro-
contexte ayant comme valeur professional. Un diner avec les grands-parents à la
maison doit être considéré comme un micro-contexte ayant comme valeur fami-
ly. Finalement une soirée dans un bar avec les membres d’un club de hockey
doit être considérée comme un micro-contexte ayant comme valeur friends. La
classification de ce micro-contexte permettra dans la suite d’impliquer diverses
actions sur l’appareil mobile comme par exemple un filtrage d’appel pertinent
pour chaque situation. On le verra par la suite mais ce micro-contexte va per-
mettre aussi de commander quelles tâches de la liste de tâches, s’il en a,
l’appareil mobile devra proposer à l’utilisateur suivant le contexte où il se
trouve.
• Social Type 2 : Ce second micro-contexte va coder si l’utilisateur est plutôt en
groupe ou tout seul. Donc les valeurs possibles seront alone ou group. Ce micro-
contexte, comme le précédent permettra de mieux caractériser le contexte. Il
permettra similairement de proposer des tâches à faire plutôt qu’on en seul ou
plutôt quand l’on est en groupe ou alors, en couplage avec le micro-contexte En-
vironment Noise Level que l’on verra par la suite, permettra d’adapter le niveau
de volume de la sonnerie de l’appareil mobile par exemple.
• Familiarity with the Environment : on peut classer l’environnement géogra-
phique dans lequel évolue l’utilisateur suivant son degré de familiarité avec ce
dernier. C'est-à-dire, si l’on suppose les trois valeurs suivantes : none, medium et
high, on pourra classer chaque situation suivant ce micro-contexte. Ce micro-
contexte se base essentiellement sur l’historique de navigation de l’utilisateur.
Par exemple, quand l’utilisateur est chez lui, à son bureau, chez ses parents ou
même sur la route entre chez lui et son lieu de travail, on peut dire que
l’utilisateur est dans un environnement avec lequel il est très familier. On pour-
rait donc caractériser ces contextes là en donnant la valeur high au micro-
contexte « Familiarity with the Environment ». Un autre exemple typique serait
si l’utilisateur est en voyage dans une ville qu’il visite pour la première fois.
Dans ce cas-là, la valeur que devra prendre ce micro-contexte est logiquement la
valeur none. Un cas intermédiaire serait lorsque l’utilisateur se trouve dans un
endroit où il a rarement été ou alors qu’il n’a visité qu’il y a très longtemps.
- 62 -

63. Dans ce cas là, la valeur de ce micro-contexte serait : medium. La question à la-
quelle on doit répondre maintenant est bien sûr : « À quoi nous servirait une
classification de ce type ? ». La réponse est que selon la valeur que prendra ce
micro-contexte, l’application donnera plus où moins d’information à l’utilisateur
sur le lieu où il se trouve. S’il est chez lui, il n’a pas besoin que son appareil mo-
bile lui indique où se trouve le salon. De même pour son trajet entre sa maison et
son lieu de travail, le système de navigation n’est pas obligé de se mettre systé-
matiquement en route puisque l’on suppose que ce trajet devient vite connu par
cœur après quelques temps. Si par contre, l’utilisateur sort de son hôtel dans un
pays étranger, la situation est complètement différente. Dans ce cas là, toute in-
dication géographique de l’appareil mobile pour l’utilisateur peut être d’une
grande utilité. L’utilisateur se basera beaucoup plus sur le système de navigation
de son appareil mobile. De plus, ce micro-contexte est facile à inférer puisqu’il
suffit que l’application lise l’adresse d’un lieu de rendez vous qui est située dans
un lieu jamais encore visité par l’utilisateur pour en déduire cette valeur de mi-
cro-contexte.
• Environment Noise Level : Ce micro-contexte va coder le niveau d’intensité de
bruit ambiant dans l’environnement actuel de l’utilisateur. On pourrait imaginer
classer tous les environnements dans une des trois catégories suivantes :
o Environnement bruyant : dans cette catégorie, on classera tous les lieux
bruyants comme les bars, les concerts, les clubs et les environnements
extérieurs comme lorsque l’utilisateur marche dans la rue etc. La valeur
correspondante à cet état sera high.
o Environnement calme : Dans cette catégorie seront rangés les lieux où le
niveau de bruit est bas, comme lorsque l’utilisateur est chez lui ou qu’il
est dans son bureau à travailler tout seul. Lorsque l’utilisateur est dans un
restaurant calme aussi. La valeur correspondante à cet état sera low.
o Environnement critique : Ces environnements sont ceux qui sont très si-
lencieux ou alors très sensibles au bruit. C'est-à-dire qu’une sonnerie de
téléphone dans un endroit pareil pourrait être dérangeante. Des exemples
d’endroits dans cette catégorie seraient, les salles de cinéma, les hôpi-
taux, les musées, les opéras et les théâtres mais aussi lorsque l’utilisateur
dort par exemple ou ne souhaite pas du tout être dérangé. Une situation
comme la dernière pourrait être lorsque l’utilisateur fait un discours ou
une présentation devant une assemblée de gens par exemple. La valeur
correspondante à cet état sera critical.
La première utilité de ce micro-contexte est facile à deviner. C’est bien sûr utile
pour que l’application sache adapter le niveau de sonnerie de l’appareil mobile
lorsque l’utilisateur reçoit un appel ou lorsqu’il utilise une application audible
sur l’appareil mobile comme un jeu par exemple. Une deuxième utilité, un peu
moins évidente pour cette classification et que vu le niveau de bruit ambiant,
- 63 -

64. l’application peut aussi adapter le niveau sonore de l’haut parleur ou de l’oreille
du l’utilisateur pendant qu’il est en communication.
• Schedule Status : ce micro-contexte a déjà été expliqué précédemment. Il per-
mettra de savoir si l’utilisateur est plutôt en avance, à temps, ou en retard par
rapport à une tâche de l’agenda et plus particulièrement par rapport à son pro-
chain rendez-vous. Les différentes valeurs possibles pour ce micro-contexte
sont : early, onTime, late ou over. La décision de l’assignation d’une ou l’autre
valeur est prise simplement en comparant l’horloge actuelle avec les temps de
début et de fin d’une activité de l’agenda. Ici nous sommes en présence d’une
des limites de notre modèle : En effet cette limite vient du fait que notre modèle
n’utilise pas la géolocalisation de l’utilisateur et donc ne connait pas sa position
actuelle. Dans ce cas, si l’utilisateur est à 30min à pied du lieu du rendez-vous et
que ce dernier commence dans 15min, notre modèle indiquera que l’utilisateur
est en avance sur son rendez-vous alors qu’en réalité il est retard. De même si
l’utilisateur est sur le lieu de rendez-vous et que ce dernier à commencer,
l’application notera qu’il est en retard alors qu’il était parfaitement à l’heure. Si
maintenant ce micro-contexte utilise des données de géolocalisation, ce pro-
blème disparaitra puisqu’il aura l’information exacte du temps qu’il reste à
l’utilisateur pour arriver à un point de rendez-vous. Donc ce micro-contexte de-
vra être utilisé avec une application de navigation pour être tout à fait pertinent.
• User Focus : Ce micro-contexte sera utilisé pour représenter le niveau
d’interaction tolérable par l’utilisateur entre lui-même et son appareil mobile. Le
but final étant de ne pas trop agacer ou monopoliser l’attention de l’utilisateur.
Donc on peut imaginer de nouveau trois ou plusieurs niveau par exemple : low
medium et high. La valeur low va représenter les situations où l’utilisateur est
plutôt non occupé comme par exemple quand il est chez lui ou qu’il est dans un
moyen de transport en commun ou dans une salle d’attente. Le niveau medium
serait un niveau intermédiaire où l’utilisateur serait occupé mais à une tâche non
critique et donc où il tolérerait encore un peu de dérangement comme lorsqu’il
mange, lorsqu’il travaille seul par exemple. Le niveau high est le niveau de con-
centration maximum. Il représente le cas où l’utilisateur est en réunion et qu’il
ne souhaite pas que son appareil mobile lui signale les dernières nouvelle
d’actualités sur un sujet qui l’intéresse ou encore lorsqu’il conduit et qu’il ne
doit pas être perturbé par d’autres informations que celles de navigation. Une
autre situation de ce type serait simplement lorsqu’il dort. L’utilité de ce micro-
contexte a déjà été partiellement expliquée. Il servira à régler la fréquence des
sollicitations de l’attention de l’utilisateur. On peut imaginer classer ces sollici-
tations en niveau d’importance ou d’urgence. Par exemple, un appel est une
sollicitation urgente alors qu’une information météo l’est moins. Donc en fonc-
tion du niveau de concentration de l’utilisateur, certaines informations seront
filtrées ou pas.
Pour notre modèle de base, nous n’avons pas choisi tous les micro-contextes plus haut
pour les implémenter mais uniquement ceux qui sont assez déductibles à partir des données
- 64 -

65. d’entrées que nous avons choisies, à savoir : l’agenda, le carnet d’adresse, la liste de tâches,
l’horloge et l’historique. Les critères que nous avons choisis parmi les précédents sont :
Social Type 1 : comme expliqué plus haut, il sert à coder si un contexte est plu-
tôt professionnel, familial ou amical. Nous allons proposer concrètement
quelques exemples de pseudo-codes qui aboutiraient à inférer ce micro-
contexte :
o Professional : si une activité se passe au bureau il y a de fortes chances
que son contexte ou son objet soit professionnel. Donc nous avons le
pseudo-code suivant :
if (event.location=="office")
then context.social_type_1 = "Professional"
Un second exemple serait si un meeting a lieu avec un contact et
que ce contact est dans la catégorie professional du carnet d’adresse. Le
contexte est donc jugé professionnel.
my_contact = meeting.with
if (my_contact.get_category()==”professional”
then context.social_type_1 = "professional"
o Family : les activités familiales sont par définition les activités qui se
passent avec les membres de la famille. Il faudra donc comme dans
l’exemple précédent vérifier le champ with de l’activité pour vérifier si
c’est un membre de la famille.
my_contact = meeting.with
if (my_contact.get_category()==”family”
then context.social_type_1 = " family "
De plus, nous remarquons encore une fois ici une limite de notre
modèle. En effet un second moyen d’inférer ce contexte familial serait
d’utiliser la carte géographique où seraient mémorisés tous les lieux de
type familial comme les différents domiciles des différents membres de
la famille. Dès que l’utilisateur est dans un de ces lieux, il y a de fortes
chances que le contexte soit familial.
Un second moyen d’inférer ce type de contexte serait en utilisant
les technologies Bluetooth. Si les appareils mobiles se reconnaissent et
s’échangent leurs identités, l’application peut, de la même manière que
dans le carnet d’adresse, connaitre dans quelle catégorie se trouve ce con-
tact.
- 65 -

66. Les deux précédentes remarques sont aussi valables pour les deux
autres valeurs de ce micro-contexte, à savoir : Professional et Friends.
o Friends : Similairement en utilisant la catégorie des contacts avec qui
l’activité est prévue, l’application peut inférer le contexte amical :
my_contact = meeting.with
if (my_contact.get_category()==”friends”
then context.social_type_1 = " friends "
Social Type 2 : Le second critère que nous avons choisi est celui qui code si une
activité est en groupe en solitaire. La plupart des activités dans l’agenda de type
meeting, party, birthday etc. sont de type en groupe alors que des tâches comme
faire une course, amener sa voiture au garage ou aller chez le médecin etc. sont
des actions que l’on effectue généralement seul. Donc pour les activités qui sont
programmés dans l’agenda comme ayant un type meeting, party ou birthday se-
ront automatiquement notés comme des activités en groupe. Le code effectuant
ce comportement sera de la forme suivante :
if (event.type==”meeting”or “party” or “birthday”)
then context.social_type_2 = " group "
A partir de l’agenda seul, il est difficile d’inférer plus sur ce micro-contexte. Par
contre, un outil beaucoup plus efficace pour cette tâche est l’utilisation des
communications Bluetooth. En effet si l’appareil détecte un autre appareil à
proximité et que ce dernier est reconnu par le premier, on peut alors inférer que
l’utilisateur est en présence de personnes qu’il connait. Ce micro-contexte, cou-
plé avec le premier, permettre de définir une politique de filtrage d’appel comme
nous le verrons dans la suite.
Environment Noise Level : Ce micro-contexte, comme nous l’avons expliqué in-
fluence directement le niveau de volume de sonneries de l’appareil ainsi que le
niveau du haut parleur. Pour inférer les niveaux de bruit ambiant à partir de
l’agenda, nous pouvons supposer qu’une fête a systématiquement un niveau de
bruit assez élevé. De même qu’un drink dans un bar ou une sortie dans un club,
un concert ou lorsque l’utilisateur marche dans la rue, l’environnement peut être
considéré comme bruyant. Contrairement, un meeting est plus calme et moins
bruyant. Une sortie au cinéma, au théâtre ou à l’opéra, de même qu’une visite
dans un musée ou un hôpital sera considérée comme une activité sensible au
bruit :
if (event.type=="meeting" and event.location=="office")
then context.Environment_noise_level = “low”
if (event.subject.contains("bar" or “club” or “concert”) or
event.location.contains("bar" or “club” or “concert”))
- 66 -

67. then context.Environment_noise_level = “high”
if (event.subject.contains("cinema" or “theater” or “opera”or …) or
event.location.contains("cinema" or “theater” or “opera”or …))
then context.Environment_noise_level = “high”
Nous utilisons ici la technique qui consiste à énumérer une liste de lieu ou le ni-
veau de bruit est critique. Nous avons déjà expliqué que cette technique n’était pas
fiable puisque difficilement implémentable. Un autre moyen de déterminer le niveau
de bruit de l’environnement serait simplement d’utiliser le microphone de l’appareil
mobile pour mesurer le niveau de bruit.
Schedule Status : Le dernier micro-contexte qui sera utilisé est celui qui indique
si l’utilisateur est plutôt en avance, à temps ou en retard par rapport à un événe-
ment ou encore que c’est événement est déjà terminé. Comme nous l’avons
expliqué plus haut, nous sommes ici en présence d’une limitation du modèle où
l’utilisation d’une application de navigation serait très bénéfique. En effet en uti-
lisant cette dernière pour estimer le temps de trajet jusqu’au lieu de prochain
rendez-vous, nous pouvons utiliser le pseudo-code suivant :
travel_time = next_event.location.get_estimated_time_from(current_location)
if ( event.start_time less than currentTime + travel_time)
then schedule status = "early"
else if ( event. start_time greater than currentTime + travel_time)
then schedule status = "late"
else if ( event. start_time equals currentTime + travel_time)
then schedule status = "onTime"
else if ( event. stop_time equals currentTime + travel_time)
then schedule status = "over"
Nous avons maintenant parcouru les différents micro-contextes que l’on souhaite utili-
ser dans notre modèle et nous avons montré comment leurs différentes valeurs peuvent être
inférées ou induites à partir des valeurs extraites de la couche précédente. Notons que ces in-
férences ne sont pas toutes fiables à 100% et ont par conséquence toutes une valeur de
confiance inférieure à l’unité sachant qu’une inférence de valeur de confiance égale à l’unité
veut dire que cette induction est vraie sans risque d’erreur. Pour augmenter cette valeur de
confiance il est très utile d’utiliser plusieurs sources différentes d’information pour inférer une
valeur de micro-contexte. Nous avons évoqué l’exemple de l’utilisation du microphone de
l’appareil mobile pour déterminer le niveau de bruit de l’environnement. Nous avons aussi
parlé de l’utilisation de la géolocalisation comme confirmation d’une inférence de meeting
professionnel. Par exemple lorsque nous avons un meeting au bureau noté dans l’agenda, c’est
bien d’en déduire qu’à ce moment là, l’utilisateur est en réunion mais c’est beaucoup mieux
- 67 -

68. de vérifier par géolocalisation que l’utilisateur se trouve bien sur son lieu de travail. Ceci
augmente l’indice de confiance d’une inférence.
Après avoir déduit ce contexte d’utilisateur sous formes de micro-contextes ayant cha-
cun une valeur particulière, nous pouvons maintenant étudier qu’elles sont les actions que doit
prendre l’application en réaction à ce contexte global de l’utilisateur.
d) L ES REACTIONS DE L ’ APPLICATION AU CHANGEMENT DE CONTEXTE
Nous allons maintenant voir à partir du contexte global, quelles actions l’application
devra entreprendre ou pas. En effet ceci étant le but final de cette déduction de contexte. Ce
sont ces actions qui font finalement la différence entre une application qui prend en compte le
contexte de l’utilisateur et une autre qui ne le fait pas. Nous allons de nouveau profiter de
cette structure de micro-contextes qui s’avère encore être bien pratique dans la synthèse de
ces actions. En effet chaque micro-contexte ou groupe de micro-contextes pourra engendrer
une ou plusieurs actions. Par exemple, un micro-contexte d’environnement bruyant engendre-
ra l’action qui est de régler le niveau de sonnerie maximum alors qu’un micro contexte qui
indique que l’utilisateur est en avance, impliquera que l’application propose à ce dernier une
tâche qu’il a dans sa liste de tâches. Cependant, la réalité n’est pas aussi simple que cela et la
règle selon laquelle un micro-contexte engendre une action n’est pas toujours d’application.
En effet, prenons l’exemple suivant : l’utilisateur est en réunion avec ses collègues. Si son
contexte est inféré correctement, deux micro-contextes indiqueront que l’utilisateur est dans
un contexte professionnel et qu’il est en groupe. Ce n’est qu’en ayant ces deux conditions là
que l’application pourra décider de filtrer ses appels non-professionnels par exemple. Donc ici
nous venons de voir un exemple où ce sont deux micro-contextes qui sont nécessaires pour
engendrer une seule action. Ceci reste encore gérable avec des techniques normales de pro-
grammation, en utilisant du pseudo-code comme présenté plus haut ou plus particulièrement,
comme le suivant :
If (context.social_type_1 == ‘‘professional’’ and context.social_type_2 == ‘‘group’’)
Then calls.apply_filtering(‘‘professional’’)
Une situation moins évidente et plus délicate encore serait le cas où nous aurons deux
valeurs de micro-contextes qui impliquent que l’application exécute deux actions contradic-
toires. Dans ce cas là, vu la nature séquentielle de la programmation, nous aurons la première
action qui sera effectuée comme réaction à une valeur d’un micro-contexte mais nous verrons
tout de suite après cette action écrasée par son action contraire qui sera elle causée par une
autre valeur de micro-contexte. Ceci engendrerait fatalement un comportement imprévisible et
indéterministe basé sur laquelle des deux actions s’exécuterait en dernier. Donnons un
exemple de situation où ce problème se pose : supposons que l’utilisateur soit en réunion de
travail sur un chantier de construction par exemple. Supposons que ses micro-contextes ont
été inférés correctement. Si l’on regarde les deux micro-contextes qui codent successivement
le niveau de bruit de l’environnement et le degré de concentration de l’utilisateur. Le premier
- 68 -

69. comportera un niveau de bruit élevé alors que le second comportera un niveau de concentra-
tion élevé aussi. Si l’on considère l’action de contrôler le niveau de sonnerie de l’appareil
mobile nous aurons deux réactions contradictoires aux deux micro-contextes précédents. Le
niveau de bruit élevé engendrera de mettre le niveau de sonnerie au maximum alors que le
niveau de concentration voudra lui baisser ce niveau au maximum. Dans ce cas là, il n’y a pas
de bonne ou mauvaise action dans l’absolu. Un utilisateur peut très bien être en plein travail et
souhaiter ne pas être dérangé lors de cette réunion importante comme un autre utilisateur lui
souhaiterait rester en contact avec le monde extérieur durant cette réunion. Donc on voit ici
que l’on doit suivre les préférences de l’utilisateur. Une solution serait que l’application lui
demande son avis à chaque fois qu’elle se trouve devant ce genre de dilemme. Elle aura donc
la bonne réponse puisqu’elle vient explicitement de l’utilisateur mais cette pratique peut vite
s’avérer agaçante. Une meilleure solution serait une solution évolutive et adaptative au com-
portement de l’utilisateur. Cette solution devra mémoriser les choix précédents de l’utilisateur
dans de pareilles circonstances et prendre la décision qu’il a prise le plus dans le passé. Pour
modéliser ceci, nous allons attribuer une pondération à chaque micro-contexte. Ce poids re-
présentera le degré d’importance qu’un utilisateur accorde implicitement à un micro-contexte
par rapport à un autre. Chaque fois qu’un utilisateur annulera explicitement une action en fa-
veur d’une autre, le poids de cette dernière se verra incrémenté alors que l’autre sera
décrémenté. Dans notre exemple précédent, si sur le chantier, l’application fait le choix de
mettre le volume au maximum ; supposons que l’utilisateur reçoive un appel. Si l’utilisateur y
répond normalement et prend la communication, le choix sera considéré comme bon et les
pondérations existantes à cet instant là ne changeront pas. Si maintenant il reçoit cet appel, ne
le prend pas, et met son appareil en mode silencieux, on peut en déduire qu’il est contre le
choix qu’a fait l’application et qu’il aurait préféré que l’application prennent plutôt en consi-
dération le fait qu’il soit en réunion plutôt que le fait qu’il soit en chantier. Dans ce cas là, on
augmentera alors le poids du micro-contexte qui code le niveau de concentration de
l’utilisateur par rapport à celui qui code le niveau de bruit de l’environnement pour indiquer
que l’utilisateur y accorde plus d’importance. Avec ce système là, les préférences de
l’utilisateur sont prises en compte et sauvegardées pour des utilisations futures. Lorsque
l’application se trouvera dans un dilemme de ce type où deux micro-contextes voudraient dé-
clencher deux actions contradictoires, elle n’aura qu’à comparer les poids de ces deux micro-
contextes pour savoir quels choix faire. Ce système toute fois être implémenté et testé pour
déceler s’il n’existe pas des effets négatifs cachés. Ce système permet aussi de bien réagir à
un changement de préférence de l’utilisateur dans le temps. Si tout à coup il accorde plus
d’importance à un micro-contexte qu’il négligeait dans le passé, son poids se mettra à grandir
au fur et à mesure jusqu’à commencer à être prépondérant dans les prises de décision. Pour
rendre cette réaction de l’application plus rapide il serait judicieux de fixer des valeurs maxi-
male et minimale pour tous les poids pour qu’en cas de changement de tendance, on ne se
retrouve pas avec des poids tellement éloignés qu’il faudrait une centaine de décisions in-
verses pour annuler l’ancienne tendance. Un pseudo-code pour la gestion des poids des micro-
contextes serait le suivant :
- 69 -

70. If (context.Environment_noise_level == ‘high’ and context.user_focus == ‘high’ and
decision_silent_profile.is_canceled_by_user())
Then context.Environment_noise_level.weight.increment()
context.Environment_ user_focus.weight.decrement()
Else if (context.Environment_noise_level == ‘high’ and context.user_focus == ‘high’ and
decision_loud_profile.is_canceled_by_user())
Then context.Environment_noise_level.weight.decrement()
context.Environment_ user_focus.weight.increment()
Voyons maintenant comment ces poids sont utilisés dans le cas de micro-contextes con-
tradictoires :
If (context.Environment_noise_level == ‘high’ and context.user_focus == ‘high’)
Then if (context.Environment_noise_level.weight greater than con-
text.user_focus.weight )
Then phone.ringing_level = ‘max’
Else if (context.Environment_noise_level.weight less than con-
text.user_focus.weight )
Then phone.ringing_level = ‘min’
Nous allons maintenant passer au traitement des autres actions dans le cas où il n’y a
pas de contradiction et dans le cadre des micro-contextes que nous avons choisis dans notre
modèle. En se basant aussi sur le scénario complet d’une journée que nous avons explicité
plus haut, nous avons dégagé les actions suivantes que devra exécuter l’application. Nous
allons aussi expliciter le pseudo-code qui les effectuerait.
• Ajuster le volume de la sonnerie de l’appareil mobile: Cette action dépendra
de quelques facteurs comme le niveau de bruit ambiant, le degré de concentra-
tion de l’utilisateur ainsi que du fait qu’il soit tout seul ou en groupe. Par
exemple, s’il est en réunion dans un bureau, le bruit ambiant sera faible,
l’activité sera en groupe et il sera concentré. Tous les facteurs sont là pour
mettre son appareil mobile en silencieux. Par contre, si le niveau de bruit aug-
mente, on pourrait augmenter le niveau de volume. De même s’il n’est plus en
groupe mais tout seul, il y a moins de risques pour qu’il dérange d’autres per-
sonnes que lui-même, on pourrait donc tolérer un niveau moyen de sonnerie.
Voici un pseudo code qui prend en compte le niveau de bruit ambiant et le fait
qu’il soit tout seul ou en groupe :
if (event.noise_level=="critical")
then phone.change_profile(silent)
else if (context.social_type_1 == "professional" and context.social_type_2 ==
"group" and event.noise_level == "low")
then phone.change_profile(silent)
else if (event.noise_level==" low ")
then phone.set_profile(general)
- 70 -

71. else if (event.noise_level=="high")
then phone.set_profile(loud)
• Filtrage d’appel: Cette action est souvent souhaitée lorsqu’on se trouve dans un
contexte donné et que l’on ne souhaite pas être perturbé par des appels ou des
messages d’un autre contexte. Ici c’est typiquement le micro-contexte So-
cial_Context_1 qui sera déterminant puisqu’il code le type de situation sociale
(professionnelle, familiale ou amicale). On utilisera aussi le niveau de concentra-
tion de l’utilisateur. S’il est très concentré, on activera le filtrage.
if (context.focus_level=="high")
then if (context.social_type_1 == "professional")
then phone.filter_calls("professionnal")
if (context.social_type_1 == "family")
then phone.filter_calls("family")
if (context.social_type_1 == "friends")
then phone.filter_calls("friends ")
• Afficher la prochaine destination : Cette action utilise le module de navigation
de l’appareil mobile. Elle utilise aussi l’agenda et le carnet d’adresse pour ex-
traire l’adresse du prochain meeting. Cette adresse sera donc fourni au module
de navigation qui va calculer l’itinéraire jusqu’à cette destination. Ce pseudo-
code devra être appelé lorsque l’utilisateur fini un rendez-vous et veut passer au
suivant.
if (list_contacts.contains(event.location)) and
list_contacts.get_contact(event.location).has_addresse())
then next_location = list_contacts.get_contact(event.location);
next_address = next_location.get_addresse();
phone.Navigator.Navigate_to(next_address);
• Afficher une alternative de transport : Cette fonction doit être appelée soit sur
demande de l’utilisateur soit spontanément par l’application et ceci dans le cas
où l’utilisateur est en retard à son prochain rendez-vous et qu’il existe un moyen
de transport jugé plus rapide pour y arriver plutôt. Cette fonction utilise beau-
coup le module de navigation que nous n’étudions pas dans le cadre de ce
mémoire. Néanmoins, voici le pseudo-code qui effectuerait cette action à partir
des micro-contextes :
next_location = list_contacts.get_contact(event.location);
next_address = next_location.get_addresse();
if (context.schedule_status == ‘late’)
then proposed_Path= Phone.Navigator.find_fastest_path_to (next_address)
- 71 -

72. • Prévenir la personne du prochain rendez-vous : Dans le même cas, le même
micro-contexte peut induire l’action de prévenir automatiquement la personne
du prochain rendez-vous du retard de l’utilisateur. Le pseudo code pour cette ac-
tion serait :
•
Next_contact = next_event.with
Next_contact_phone = contact_list.get_number(next_contact)
if (context.schedule_status == ‘late’)
then phone.propose_call(next_contact)
• Afficher une tâche à faire : Cette action, contrairement à la précédente est ef-
fectuée lorsque l’utilisateur a du temps libre devant lui ou qu’il est en avance par
rapport à son prochain meeting. C’est ici que nous utiliserons la nouvelle classi-
fication de la liste de tâches qui consiste à classer les tâches selon leur contexte
(professionnel, familial ou amical). Donc si l’utilisateur a du temps devant lui et
qu’il est dans un des différents contextes, l’application lui proposera des tâches
différentes à faire :
•
if ( (events.get_nextevent().get_time() - current.time ) is_greater_than 60min)
if (social_type1 = "professional")
then display_alert( todo_list.get_next_profesional_todo_item())
else if (social_type1 = "family")
then display_alert( todo_list.get_next_family_todo_item();)
else if (social_type1 = "friends")
then display_alert( todo_list.get_next_friends_todo_item();)
Nous venons à présent d’illustrer comment seront déduites les actions à partir des va-
leurs des micro-contextes. Cette couche représente la couche finale de notre modèle.
Cependant, une déduction systématique de ces actions peut vite dans certains cas ne pas tota-
lement satisfaire les attentes et préférences de l’utilisateur. Donc pour mieux se rapprocher
des préférences de chaque utilisateur lors de la prise de ces décisions, il serait intéressant de
prendre aussi en considération, conjointement avec le contexte global actuel de l’utilisateur,
l’historique des décisions qu’a prises l’utilisateur dans le passé pour un contexte similaire.
Cette couche qui tiendra compte de l’historique viendra se placer juste avant la couche finale
que l’on vient d’expliquer dans ce chapitre.
e) L A PRISE DE DECISION AVEC INTEGRATION DE L ’ HISTORIQUE
Vu la nature non totalement fiable et très complexe de la déduction de contexte, ainsi
que la diversité et la complexité des préférences de tout un chacun, il se peut que les réactions
- 72 -

73. d’une application à un contexte ne conviennent pas totalement et tout le temps à l’utilisateur.
Il se peut que ces préférences évoluent dans le temps aussi. Par exemple, il se peut qu’une
personne ne veuille pas que ses appels familiaux soient filtrés pendant une réunion profes-
sionnelle. Pour palier à ce problème là, nous avons décidé d’inclure dans notre modèle,
l’utilisation de l’historique des actions et des choix qu’a fait l’utilisateur dans le passé pour
décider quels choix seront fait pour le contexte actuel. Pour cela, pour chaque contexte donné,
nous allons chercher dans l’historique un contexte similaire ainsi que les choix ou décisions
qu’a faits l’utilisateur dans ce cas là. Si l’on remarque qu’il y a une décision que prend systé-
matiquement l’application dans un contexte donné, et que l’utilisateur à annuler plusieurs fois,
il sera donc préférable de directement l’annuler si ce même contexte se représente.
Pour pouvoir utiliser un historique il va falloir le construire. Il sera sous forme d’une
base de données qui stocke les différents contextes par lesquels passe l’utilisateur, et pour
chacun de ces contextes stockeraient aussi les préférences et les choix qu’a faits l’utilisateur à
ce moment là. En ayant cette base de données, l’application, après avoir inféré un contexte
actuel d’utilisateur, n’aura plus qu’à fournir ce contexte à la base de données pour recevoir en
retour toutes les décisions qu’a prises l’utilisateur pour ce contexte là dans le passé.
Notre modèle sera constitué de cinq couches comme nous les avons détaillées précé-
demment. En voici un résumé :
• Les informations d’entrée
• L’extraction des informations pertinentes à la déduction de contexte
• La déduction de contexte suivant le modèle de micro-contextes
• La prise en compte de l’historique des choix antérieurs de l’utilisateur
• la prise de décisions des actions de l’application
Dans ce modèle là toutes les étapes sont accomplies de manière automatique sans
l’intervention de l’utilisateur. Par contre pour la construction de l’historique, la base de don-
nées observera le même modèle mais uniquement lorsque l’utilisateur intervient pour annuler
ou modifier une décision qui a été prise automatiquement par le modèle automatique auto-
nome. Pour mieux éclaircir les idées nous allons présenter le processus avec le schéma
suivant :
- 73 -

74. FIGURE 16 - SCHEMA DE PRISE EN COMPTE DE L'HISTORIQUE DANS LE MODELE
De cette manière, on voit comment les actions qu’a effectuées l’utilisateur par lui-même
(dans le modèle de droite) sont sauvegardées dans une base de données d’historique qui sera
consultée dans le futur par l’application autonome qui prendra des décisions. Elle tiendra
compte de cet historique avant de décider quelles actions ou non elle devra effectuer dans un
contexte donné. Par un mécanisme semblable à celui que l’on a introduit pour les décisions
contradictoires dans le chapitre précédent, nous pouvons attribuer à chaque micro-contexte
une pondération qui représentera à quel point l’utilisateur juge ce micro-contexte pertinent
dans un contexte global donné. Nous n’irons pas plus loin sur ce sujet d’historique dans le
cadre de ce mémoire dont le sujet est plus focalisé la déduction de contexte.
Maintenant que nous avons introduit toutes les couches de notre modèle nous allons le
présenter dans un seul schéma et nous utiliserons deux exemples pour détailler toutes les
étapes de traitement depuis l’agenda jusqu’aux actions.
f) L E MODELE COMPLET AVEC UN EXEMPLE
À la figure précédente, nous avons introduit la structure en cinq couches de notre mo-
dèle. Maintenant nous allons donner une version plus détaillée de ce modèle. Nous utiliserons
aussi deux exemples tirés du scénario complet étudié dans une section précédente. Le premier
exemple sera le rendez-vous à 10h du matin au bureau. Pour cet exemple nous supposerons
qu’il est 9h45. Le second exemple sera quant à lui le diner chez les grands-parents à 21h. Pour
ce second exemple nous supposerons qu’il est 21h.
- 74 -

75. Nous allons étudier le traitement de ces informations par chaque couche pour nos deux
exemples :
• Exemple 1 : nous avons l’entrée suivante dans l’agenda : « meeting at office at
10h » et nous supposons que l’horloge indique 9h45.
o Première couche : les entrées : Ce sont la ligne d’agenda et l’horloge ac-
tuelle.
o Seconde couche : L’extraction des données : à partir de l’agenda et
l’horloge seront extraits les éléments pertinents qui sont le type d’activité
(meeting), le lieu de l’activité (office), l’heure de début de l’activité (10h)
et finalement le temps qu’indique l’horloge (9h45)
o Troisième couche : la déduction de contexte : à partir des valeurs ex-
traites à la couche précédente, nous allons donner une valeur à chacun
des micro-contextes de cette couche :
Le type social 1 : Le fait que le lieu du rendez-vous est au bureau
implique qu’il est de type professionnel.
Le type social 2 : Le fait que ce soit un rendez-vous implique que
c’est une activité en groupe.
Le niveau bruit de l’environnement : le fait que ce soit une réu-
nion et qu’elle se passe au bureau implique que c’est une activité
sensible au bruit.
L’état par rapport à l’agenda : La comparaison entre l’heure de
l’horloge et l’heure de début du rendez-vous permet de dire que
l’utilisateur est en avance sur son rendez-vous. Ceci dit, nous
avons déjà fait la remarque ce que ce micro-contexte ne prend
vraiment tout son sens que lorsqu’il est utilisé conjointement avec
un module de navigation.
o Quatrième couche : Prise en compte de l’historique : Nous n’étudions
pas ce point-ci dans le cadre de ce mémoire, c’est pour cela que nous
supposerons que l’historique est vierge à ce moment là et n’a par consé-
quent aucun impact sur les décisions.
o Cinquième couche : la prise de décision : chacune des décisions est im-
pliquée par un ou plusieurs valeurs de micro-contexte :
Filtrage d’appel : Le fait que ce soit une activité professionnelle
et que l’utilisateur est en groupe peut impliquer qu’il serait judi-
cieux de filtrer ses appels non professionnels. Nous avons dit
précédemment qu’une valeur du micro-contexte focus_level mise
à high impliquerait aussi ce filtrage d’appel.
- 75 -

76. Profil silencieux : Le fait que ce soit un rendez-vous et qu’il se
passe sur le lieu de travail pourrait impliquer que l’appareil mo-
bile soit mis sous silencieux. Ce type de décision un peu délicate
pourrait être appris par la suite grâce à l’utilisation d’un histo-
rique pour savoir vraiment si l’utilisateur préfère un mode
silencieux pendant ses réunions ou bien préfère-t-il laisser sonner
ses appels.
• Exemple 2 : Nous avons l’entrée suivante dans l’agenda : « Diner at home at
9p.m » et nous supposons que l’horloge indique 21h.
o Première couche : les entrées : Ce sont toujours cette même ligne
d’agenda et l’horloge actuelle.
o Seconde couche : L’extraction des données : A partir de l’agenda et
l’horloge seront extraits les éléments pertinents qui sont le type d’activité
(diner), les personnes avec qui l’activité est programmée (grands-
parents), le lieu de l’activité (home), l’heure de début de l’activité
(9p.m.) et finalement le temps qu’indique l’horloge (9p.m)
o Troisième couche : la déduction de contexte : A partir des valeurs ex-
traites à la couche précédente, nous allons donner une valeur à chacun
des micro-contextes de cette couche :
Le type social 1 : Le fait que le lieu du rendez-vous est à la mai-
son et que le diner soit avec les grands-parents implique que
l’activité est de type familial.
Le type social 2 : Le fait que le champ with soit rempli implique
que c’est une activité en groupe.
Le niveau de bruit de l’environnement : Par raisonnement in-
verse, le fait que cesoit une situation intermédiaire entre, d’une
part, less environnements bruyants comme les clubs, les bars et
les concerts et, d’autre part, les environnements critique comme
les réunions, les salles de cinéma et de théâtre nous poussent à
mettre le micro-contexte de niveau de bruit au niveau intermé-
diaire qui est le niveau « bas » .
L’état par rapport à l’agenda : La comparaison entre l’heure de
l’horloge et l’heure de début du diner permet de dire que
l’utilisateur est à temps sur son rendez-vous. Même remarque que
précédemment.
o Quatrième couche : Prise en compte de l’historique : Même remarque
également.
- 76 -

77. o Cinquième couche : la prise de décision : chacune des décisions est im-
pliquée par un ou plusieurs valeurs de micro-contexte :
Filtrage d’appel : Le fait que ce soit une activité familiale et que
l’utilisateur est en groupe peut impliquer qu’il serait judicieux de
filtrer ses appels non familiaux. On peut aussi se baser sur
l’historique pour ce genre de décision.
Niveau de sonnerie moyen : Le niveau de bruit sonore bas et le
fait que ce ne soit pas un cadre professionnel pourrait impliquer
que le niveau de sonnerie de l’appareil soit réglé sur moyen.
Nous avons à présent présenté les cinq couches illustrées par deux exemples, nous al-
lons donc enfin présenter le schéma final du modèle en cinq couches. Sur ce schéma seront
représentés nos deux exemples. Les flux d’implication et de traitement de l’information seront
eux représentés par des flèches.
FIGURE 17 - SCHEMA DE MODELE EN CINQ COUCHES AVEC DEUX EXEMPLES
- 77 -

78. Nous voyons donc superposées nos cinq couches de modèles de la première en haut à la
dernière en bas. La troisième couche qui représente le contexte est divisée en micro-contextes
représentés par les grosses boites rouges.
Dans cette partie, nous avons illustré le modèle que nous avons construit pour effectuer
une déduction de contexte de l’utilisateur ainsi qu’exécuter les meilleures actions en consé-
quence. Pour faire cela nous avons commencé par expliquer les idées de bases et les
inspirations qui nous ont aidés à construire le modèle sous sa forme actuelle. Ensuite, nous
avons expliqué le modèle en lui-même avec ses différentes couches et la fonction de chaque
couche. Enfin nous avons montré par deux exemples concrets comme notre modèle les traite-
rait en en déduisant le contexte pour ensuite en déduire les actions à exécuter.
Nous allons maintenant passer à l’implémentation pratique d’une partie de notre modèle
sous forme d’une application qui tourne sur appareil mobile de marque Nokia (42). Ce pro-
gramme implémentera quelques unes des fonctionnalités décrites plus haut.
E. IMPLEMENTATION PRATIQUE
Nous allons maintenant présenter l’application que nous avons développée et qui im-
plémente quelques unes des fonctionnalités de notre modèle explicité plus haut. Nous allons
commencer par présenter un scénario simplifié basé sur le scénario complet d’une journée de
l’utilisateur expliqué dans une section précédente. Ensuite nous allons la structure de notre
programme ainsi que la manière dont il réagit à chaque étape du scénario simplifié.
I. SCENARIO SIMPLIFIE
Rappelons l’agenda associé au scénario complet que nous avons décrit plus haut :
10h00: meeting @ office
12h00: lunch @ “Luigi Pastas” with ‘Maria Sanchez’
14h00: Call John Parker about the morning meeting.
15h00: teamwork @ Erasme hospital/ local A 234 with colleagues
18h00: Drink @ Bar La Taverne with hockey club members
20h00: Dinner @ home with grandparents.
De cet agenda nous allons garder uniquement les éléments suivants :
10h00: meeting @ office
14h00: Call John Parker about the morning meeting.
18h00: Drink @ Bar La Taverne with hockey club members
On voit sur les deux figures suivantes les entrées telles que sauvées dans l’agenda
- 78 -

79. FIGURE 18 - LE SCENARIO TEL QUE SAUVE DANS L'AGENDA
En plus de cela, nous allons rajouter dans la liste de tâches une tâche qui a comme ob-
jet : « Buy a birthday gift for Maria » comme on le voit sur la capture d’écran suivante :
FIGURE 19 - LA TACHE SAUVEE DANS LA TODO LIST
Nous verrons comment le programme va traiter cette tâche.
En plus de l’agenda, nous avons aussi sauvé dans le carnet d’adresse le contact John
Parker que l’utilisateur devra appeler à 14h. Pour ce contact, nous avons donc entré son nu-
méro de téléphone. De même, nous avons entré le contact La Taverne comme un lieu dans le
carnet d’adresse et pour ce lieu nous avons entré l’adresse postale aussi comme on le voit
dans les deux figures suivantes :
- 79 -

80. FIGURE 20 - LES DEUX CONTACTS DANS LE CARNET D'ADRESSES
Nous verrons comment notre application va traiter chacune de ces entrées dans l’agenda
ainsi que la tâche enregistrée dans la liste de tâches et ceci en interagissant avec les contacts
du carnet d’adresse.
II. STRUCTURE ET COMPORTEMENT DU PROGRAMME
Le programme se structure en plusieurs classes qui s’occupent de diverses tâches. Nous
allons nous concentrer sur deux tâches principales. La première classe représente le contexte
d’une situation à travers un objet context qui a comme attribut les différents micro-contextes
que l’on a choisi modéliser le contexte dans la section précédente. En voici une structure gé-
nérique avec les attributs :
Classe Context :
• social_Type_1 : avec les valeurs possibles suivantes :
o professional
o family
o friends
• social_Type_2 : avec les valeurs possibles suivantes :
o alone
o group
• environment_noise_level :
o low
o high
o critical
• schedule_status :
o early
o onTime
o late
o over
- 80 -

81. Suivant notre modèle à cinq couches, pour chaque évènement, un objet context sera ins-
tancié. Les champs de l’événement seront lus dans l’agenda pour ensuite calculer et attribuer
les valeurs adéquates aux attributs de cet objet context comme expliqué dans le modèle.
Jusqu’à présent, pour un évènement donné, nous avons inféré le contexte à partir des
données d’entrées. A partir de là, toujours suivant le modèle, l’application devra en déduire
les actions à faire. C’est ici qu’intervient la classe Actions.
Vu les événements de l’Agenda et de la liste de tâches que l’on a prévu de traiter dans le
scénario simplifié, cette Classe Actions devra faire les tâches suivantes :
• Pour la réunion de 10h la classe devra :
o Lire les valeurs des micro-contextes dans l’objet Context.
o Mettre le niveau de sonnerie sur silencieux comme conséquences du
point précédent.
• Pour l’appel de John Parker la classe devra :
o Chercher le contact John Parker dans le carnet d’adresse :
o Extraire son numéro de téléphone.
o Proposer à l’utilisateur de l’appeler en un seul click.
• Pour le rendez-vous au bar La Taverne la classe devra :
o Chercher le contact La Taverne dans le carnet d’adresse.
o Extraire son adresse postale.
o Afficher cette adresse à l’utilisateur en lui indiquant que c’est celle du
prochain rendez-vous. Cette étape pourrait être poussée plus loin si on
imagine que cette adresse pourrait être fournie à l’application de naviga-
tion pour automatiquement diriger l’utilisateur vers ce lieu.
• Pour la tâche dans la liste de tâche à faire, la classe devra :
o Observer à un moment donné si l’utilisateur n’est pas occupé.
o Vérifier qu’il reste au moins une heure entre l’instant actuel et le pro-
chain rendez-vous.
o Dans ce cas là, extraire une tâche dans la liste de tâches et la proposer à
l’utilisateur.
Nous avons donc ces quatre actions que doit exécuter cette classe. Pour chacune de ces
actions nous allons montrer quelles méthodes ont été développées avec à chaque fois les ré-
sultats qu’elles produisent sur l’appareil mobile.
- 81 -

82. • Pour la réunion de 10h, la méthode handleMeetings(), fait appel à une autre mé-
thode handleSilentMeetings(). Cette dernière s’occupe de mettre l’appareil
mobile en mode silencieux. Le résultat produit à l’écran est le suivant :
FIGURE 21 - LA CAPTURE D'ECRAN DU PASSAGE EN MODE SILENCIEUX
• Pour l’appel de John Parker, la méthode handlecalls() s’occupe d’aller chercher
le contact à appeler dans la liste de contacts et l’affiche comme aux deux figures
suivantes en proposant de l’appeler directement :
FIGURE 22 - DETECTION D'APPEL A FAIRE ET PROPOSITION D'APPEL EN UN CLICK
• Pour le rendez-vous au bar La Taverne, c’est la méthode handleMeetingAd-
dress() qui s’occupera de chercher le contact la taverne en utilisant la méthode
getThisContact() pour ensuite en extraire l’adresse postale. Enfin, une alerte se-
ra affichée à l’utilisateur à l’écran pour lui signaler que son prochain rendez-
vous est à l’adresse trouvée dans le carnet d’adresse et lui proposera en un seul
click d’appeler le navigateur avec cette adresse comme destination. On voit aux
deux figures suivantes le résultat tel qu’affiché à l’écran:
- 82 -

83. FIGURE 23 - RECHERCHE D'ADRESSE DU PROCHAIN RDV ET PROPOSITION DE NAVIGATION
• Pour la tâche dans la liste de tâches à faire, c’est la méthode handleToDo() qui
est appelée. Elle s’occupera de vérifier que l’utilisateur est en avance d’une
heure sur son prochain rendez-vous en vérifiant que l’attribut shed_stat (sche-
dule status) de l’instance de l’objet Context a bien une valeur ‘‘early’’. Dans
l’affirmative, cette méthode, va aller chercher une tâche dans la liste de tâches
pour la proposer à l’utilisateur comme on le voit à la figure suivante :
FIGURE 24 - PROPOSITION D'UNE TACHE A PARTIR DE LA TODO LIST
Nous venons d’expliquer la dernière fonctionnalité de notre application qui conclut cette
partie explicative de la structure et du comportement de l’application. Nous avons vu, à tra-
vers un scénario simplifié contenant trois entrées dans l’agenda et une entrée dans la liste de
tâches, quelles méthodes ont été développées pour gérer ce type de contextes. En résumé,
notre application gère les rendez-vous de l’utilisateur en mettant l’appareil mobile directement
en silencieux durant le temps de la réunion. Après ceci nous avons montré comment
l’application gère les rappels d’appels que doit passer l’utilisateur en allant chercher directe-
ment le numéro d’appel dans le carnet d’adresse de l’utilisateur pour lui proposer d’appeler ce
contact en un seul click. Ensuite, nous avons montré comment l’application gère les événe-
ments dont l’utilisateur à indiquer le nom du lieu de rendez-vous. L’application va chercher
- 83 -

84. l’adresse postale de ce lieu dans le carnet d’adresse pour l’afficher à l’utilisateur ou encore
pour lui proposer de lancer le module de navigation avec cette adresse comme destination.
Enfin, la dernière fonctionnalité permet de gérer les tâches que l’utilisateur a sauvées dans sa
liste de tâches. En effet elle attend un moment où l’utilisateur est disponible et où en plus il
n’a pas d’activité prévu durant l’heure qui suit. C’est à ce moment là qu’elle lui propose de
faire cette tâche.
Cette implémentation pratique du modèle développé termine la seconde et dernière par-
tie de ce travail de fin d’études. Cette seconde partie a été consacrée au travail pratique qui a
été effectué durant ce mémoire. Durant cette partie nous avons commencé par introduire une
structure plus sémantique des outils organisationnels que l’utilisateur utilise sur son appareil
mobile. Nous avons ensuite proposé un scénario complet d’une journée d’un utilisateur afin
de mieux comprendre quel serait le contexte à chaque instant de cette journée ainsi que le
comportement idéal que doit adopter l’appareil mobile en fonction de ces changements de
contexte. Ensuite, à partir de ce comportement idéal, nous sommes passés au modèle propre-
ment dit en décrivant ses idées de bases ainsi que ses différentes couches et fonctionnalités.
Enfin, à partir de ce modèle, nous avons développé une application sous la même architecture
de modèle et qui s’occupe de traiter une version réduite du scénario complet proposé précé-
demment. Le modèle ainsi que l’application procèdent en deux grandes étapes à la gestion de
contexte de l’utilisateur. La première est de récolter des données brutes pour en extraire le
contexte de l’utilisateur. La seconde étape est, à partir de ce contexte, déterminer les meil-
leures actions que l’appareil mobile peut entreprendre pour réagir à ce contexte et servir au
mieux les besoins de l’utilisateur.
- 84 -

85. 4.CONCLUSION ET TRAVAUX FUTURS
A. CONTRIBUTIONS
Le but de ce travail de fin d’étude était d’étudier la possibilité d’utiliser les données pré-
sentes dans les outils organisationnels que l’utilisateur a sur son appareil mobile pour en
inférer des informations sur son contexte à un instant donné. Le but futur étant que les appli-
cations utilisant des services géolocalisés augmentent la qualité de la communication et des
services qu’elles délivrent à l’utilisateur en s’adaptant du mieux que possible à sa situation à
un instant donné.
Après avoir introduit les services géolocalisés et la notion de contexte pour les systèmes
d’informations, notre contribution dans ce travail a suivi la démarche suivante. Premièrement,
nous avons proposé une structure des outils organisationnels qui soit plus sémantique pour
que les applications saisissent mieux le sens des données stockées dans ces outils. Au lieu de
stocker dans une ligne d’agenda du texte brut qui n’a de sens que pour l’utilisateur, cette
structure utilise plusieurs champs sémantiques dans lesquels sont stockés par exemple, le lieu
d’un rendez-vous mais aussi la ou les personnes avec qui ce rendez-vous est prévu etc. Après
avoir proposé cette structure sémantique, nous avons établi un scénario d’une journée d’un
utilisateur lambda. Nous avons ensuite découpé cette journée en plusieurs étapes pour dégager
le contexte de l’utilisateur à chaque étape ainsi que le comportement idéal que devrait avoir
un appareil mobile conscient du contexte. Ces résultats ont ensuite été la base de la création
d’un modèle théorique qui vise, à partir des données d’entrées (les informations dans l’agenda
essentiellement) à inférer le contexte de l’utilisateur à un instant donné de la journée. Ensuite,
à partir de ce contexte inféré, le modèle en déduit les meilleures actions que l’appareil mobile
peut effectuer. Dans ce modèle, nous avons aussi schématisé un historique qui sauvegarde
toutes les actions prises par l’utilisateur dans un contexte donné. Cet historique sera ensuite
pris en compte lorsque le modèle déduira les actions à prendre à partir du contexte de
l’utilisateur. Ceci permettra de prendre en compte ses préférences dans le passé dans le choix
des actions. Après avoir construit ce modèle, nous avons développé une application qui im-
plémente quelques unes des fonctionnalités que propose le modèle. L’application permet par
exemple d’inférer un contexte de réunion professionnelle et d’adapter automatiquement le
niveau de sonnerie de l’appareil mobile. Elle permet aussi d’extraire l’adresse du lieu du pro-
chain rendez-vous de l’utilisateur et de la lui présenter. Une autre fonctionnalité développée
est de détecter le contexte selon lequel l’utilisateur n’a aucune activité de prévue dans la pro-
chaine heure pour, à ce moment là, lui proposer une tâche qu’il a notée dans la liste des tâches
de son appareil mobile.
- 85 -

86. B. TRAVAUX FUTURS
Comme précédemment mentionné lors du développement du modèle, il se dégage de
notre travail deux directions prometteuses de recherches futures pour améliorer et développer
ce travail.
La première direction est l’intégration dans le modèle de l’aspect localisation géogra-
phique de l’utilisateur. Cette donnée est cruciale pour l’inférence du contexte. Une bonne
combinaison des informations de contexte géographiques avec celles issues des outils organi-
sationnels peuvent créer de riches synergies qui pourraient porter la déduction de contexte à
un plus haut niveau. Par exemple, savoir que l’utilisateur est à un endroit géographique donné
et que sa prochaine activité se déroulera dans un autre endroit, permettra d’inférer que
l’utilisateur sera en retard à cette activité par exemple et, éventuellement, automatiquement
prévenir les personnes qui l’attendent de ce retard.
La seconde direction pour continuer ce modèle serait de développer et de tester le mo-
dèle proposé pour l’historique. En effet cet aspect semble assez prometteur pour compléter le
modèle actuel vu qu’il rend ce dernier plus adaptatif au comportement de chaque utilisateur et
moins figé que l’application développée qui, pour un contexte donné, applique toujours les
mêmes actions. En prenant en compte l’historique des actions de l’utilisateur, ce modèle pour-
rait modifier ces actions pour les rendre plus en concordance avec les préférences
personnelles de chaque utilisateur.
De plus, l’application actuelle a encore besoin d’une série de tests pour vérifier son
fonctionnement pratique. Il faut la tester sur un groupe d’utilisateurs pour pouvoir améliorer
l’ergonomie de l’application. C'est-à-dire la façon dont l’application présente l’information à
l’utilisateur. De plus, l’application a été basée sur un scénario réduit et ne traite par consé-
quent que de quelques fonctionnalités. On peut donc augmenter ce nombre de situations
traitées en incluant par exemple la gestion des filtrages automatiques d’appels non profes-
sionnels en cas de réunion professionnelle. On peut aussi penser à améliorer le choix de la
tâche choisie dans la liste des tâches en associant le type de tâche choisi au type de contexte
actuel. C'est-à-dire que, par exemple, dans un contexte familial, si l’utilisateur n’est pas occu-
pé, la tâche que l’application doit lui proposer ne doit pas être de type professionnel mais bien
de type familial.
En ce qui concerne le modèle en lui-même, il peut encore être amélioré. En effet, dans
la couche de déduction de contexte, nous avons choisi quatre micro-contextes pour caractéri-
ser notre contexte. L’avantage de ce modèle est que l’on peut justement ajouter autant de
micro-contextes que l’on souhaite pour enrichir le modèle et le rapprocher de plus en plus de
la description de la situation réelle de l’utilisateur. On peut donc penser prendre en compte le
micro-contexte qui représente le niveau de concentration de l’utilisateur et l’intégrer au mo-
dèle. Nous avons cité d’autres micro-contextes que l’on pourrait encore ajouter. Un autre
point à améliorer serait d’étudier encore plus d’exemples de situations probables et déterminer
pour chacune comment le modèle doit en inférer le contexte et en déduire les meilleures ac-
tions à entreprendre.
- 86 -

87. 5.BIBLIOGRAPHIE
1. Virrantaus, K., Markkula, J., Garmash, A., Terziyan Y.V. Developing GIS-
Supported Location-. Kyoto Japan : s.n., 2001.
2. Open Geospatial Consortium (OGC), . Open Location Services 1.1. . OGC. 2005.
3. Mobile Cartography - Adaptive Visualisation of Geographic Information on Mobile
Devices. Reichenbacher, T. 2004.
4. wikipedia. http://en.wikipedia.org/wiki/Geographic_information_system. wikipedia.
[En ligne]
5. Géocaching. wikipedia. [En ligne] http://fr.wikipedia.org/wiki/G%C3%A9ocaching.
6. Mobile in a minute. mobilein.com. [En ligne]
http://www.mobilein.com/what_is_a_VAS.htm.
7. Inc., Google. Google.com. [En ligne] www.google.com/intl/fr_fr/latitude/intro.html .
8. WebPark Project. e-cartouche.ch. [En ligne] Camenio. http://www.e-
cartouche.ch/content_reg/cartouche/LBSdata/en/html/index.html.
9. Wikipedia.com. [En ligne] Wikipedia . www.wikipedia.com.
10. GeoPedia. locmedia.wordpress.com. [En ligne]
http://locmedia.wordpress.com/tag/location-based-service/.
11. Location-based City Portals. slideshare.net. [En ligne]
http://www.slideshare.net/DZF/locationbased-city-portals-opportunities-for-your-city-
presentation.
12. CATS. lbs-tracking-services-stalking-with-a-smile. gotomobile.com. [En ligne]
CATS. http://www.gotomobile.com/archives/lbs-tracking-services-stalking-with-a-smile.
13. itrack123.com.au. [En ligne] itrack123. http://www.itrack123.com.au/.
14. cospas-sarsat.org. [En ligne] cospas-sarsat. http://www.cospas-
sarsat.org/MainPages/indexFrench.htm.
15. ikitude : Practical Augmented Reality. Youtube. [En ligne]
http://www.youtube.com/watch?v=8EA8xlicmT8&feature=player_embedded.
16. android. google. [En ligne] Google. http://www.google.fr/mobile/android/.
17. HTC. HTC.com. [En ligne] HTC. www.HTC.com.
18. OGC. opengeospatial.org. opengeospatial.org. [En ligne] OGC.
www.opengeospatial.org.
- 87 -

88. 19. iso. iso.org. [En ligne] iso. http://www.iso.org/iso/fr/home.htm.
20. OpenLS. ols. opengeospatial.org. [En ligne] OpenLS.
http://www.opengeospatial.org/standards/ols.
21. Dey, A.K. Understanding and using context. Personal and Ubiquitous Computing
Journal,. Understanding and using context. Personal and Ubiquitous Computing Journal.
2001.
22. K. Henricksen, J. Indulska, and A. Rakotonirainy. Modeling context information
in pervasive computing systems. In proceedings of 1st International Conference on Pervasive
Computing. Modeling context information in pervasive computing systems.
23. H. Lei, D.M. Sow, J.S. Davis II, G. Banavar, and M. Ebling. The design and
applications of a context service. Mobile Computing and Communications Review.
24. Gruber, Tom. what-is-an-ontology.html. www-ksl.stanford.edu. [En ligne]
http://www-ksl.stanford.edu/kst/what-is-an-ontology.html.
25. Tom Grubber. what is an ontology. stanford.edu. [En ligne] http://www-
ksl.stanford.edu/kst/what-is-an-ontology.html.
26. Guarino., N. Semantic matching: Formal ontological distinctions for information
organization,extraction, and integration. 1997.
27. Yu, Shijun. Contextualized and personalized location-based services. Lausanne :
s.n., 2007.
28. Flickr. http://www.flickr.com/. http://www.flickr.com/. [En ligne] Yahoo.
http://www.flickr.com/.
29. Youtube. Youtube. youtube.com. [En ligne] Google. www.youtube.com.
30. Data Mediation and Interoperation in Social Web:Modeling, Crawling and
Integrating Social Tagging Data. Ying Ding, Ioan Toma, Sin-Jae Kang, Michael Fried,
Zhixian Yan.
31. Grossniklaus, Micheal. Context-Aware Data Management : An Object oriented
Version Model. 2007.
32. Schilit, William Noah. A system Architecture for Context-Aware Mobile
Computing. Colombia : s.n., 1994.
33. Nivala, A.-M., Sarjakoski, L. T.,. Need for context-aware topographic maps in
mobile devices. Proceedings of ScanGIS 2003,. 2003.
34. Inferring and Predicting Context of Mobile Users. Erik Meeuwissen, Paul
Reinold, and Cynthia Liem.
35. Context inference of users' social relationships and distributed policy management.
Alisa Devlic, Roland Reichle, Michal Wagner, Manuele Kirsch Pinheiro, Yves
- 88 -

89. Vanrompay, Yolande Berbers, and Massimo Valla. s.l. : the 6th IEEE Workshop on
Context Modeling and Reasoning (CoMoRea) at the 7th IEEE International Conference on
Pervasive Computing and Communication (PerCom’09).
36. Mobile Context Inference Using Low-Cost Sensors. Evan Welbourne1, Jonathan
Lester2, Anthony LaMarca3, and Gaetano Borriello1,3.
37. Inc, myspace. myspace. myspace.com. [En ligne] www.myspace.com.
38. K. Cheverst, G. Smith, K. Mitchell, A. Friday, and N. Davies. The role of shared
context in supporting cooperation between city visitors. Computers & Graphics. 2001.
39. Database_schema. Wikipedia. [En ligne] Wikipedia.
http://en.wikipedia.org/wiki/Database_schema.
40. The Active Badge Location System. Roy Want, Andy Hopper , Veronica Falcão
and Jonathan Gibbons. Cambridge, England : s.n., 1992.
41. Location-Based Services for Mobile Telephony: a study of users’ privacy concerns.
Dey, Louise Barkhuus & Anind. Copenhagen : s.n.
42. Nokia. nokia.com. nokia.com. [En ligne] Nokia. www.nokia.com.
43. G1 le Smartphone de google. [En ligne] Google.
http://www.linternaute.com/hightech/mobile/actualite/g1-le-telephone-mobile-selon-
google/un-telephone-surdoue-mais-cher.shtml.
- 89 -

90. 6.ANNEXES
CODE SOURCE DE L’APPLICATION
CLASSE CONTEXTE
- 90 -

91. CLASSE ACTIONS
- 91 -

92. - 92 -

93. - 93 -

94. - 94 -

95. - 95 -

96. - 96 -