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 -