Ce premier chapitre pr´esente le contexte dans lequel se d´eroule notre travail. L’ob- jectif principal du processus que nous d´ecrivons est d’obtenir des informations sur les utilisateurs de sites web. Nous avons pr´esent´e les concepts centraux de r´eseau, de Web
1.8. Conclusion ? 19
ainsi que la famille des protocoles utilis´es. Nous avons ´egalement vu dans quelle pro- portion il existe des cadres et une certaine d´eontologie dans l’utilisation des donn´ees du Web.
Le chapitre suivant traite des donn´ees elles-mˆemes : que sont-elles, de quelle mani`ere les r´ecup´erer? Ces deux questions, pour ˆetre trait´ees de mani`ere ad´equate, demandent une grande connaissance des donn´ees disponibles. Une ´etude la plus exhaustive possible des informations pouvant ˆetre r´ecup´er´ees est primordiale. C’est ce que nous poposons de faire dans le chapitre suivant o`u nous analysons les donn´ees disponibles du cˆot´e client et du cˆot´e serveur.
2
Données du Web et leur
acquisition ?
Sommaire 2.1 Introduction ? 2.2 Cˆot´e client ? 2.3 Cˆot´e serveur ? 2.4 Conclusion ? R´esum´eNous rappelons que le but de notre travail est de fournir `a l’utilisateur d’un site web une meilleure qualit´e de services. Pour y parvenir, nous voulons connaˆıtre les diff´erentes mani`eres qu’ont les utilisateurs de naviguer afin d’en d´eduire la person- nalisation ad´equate pour le service demand´e. Nous pr´esentons dans ce chapitre les divers types de donn´ees li´ees au comportement des utilisateurs et leur accessibilit´e. Nous argumentons notre choix de donn´ees pour notre probl`eme.
2.1
Introduction ?
Le processus complet d´efini dans notre travail rel`eve comme nous l’avons vu dans l’introduction (section 1), de l’extraction de connaissance `a partie de donn´ees. Dans ce paradigme, l’´etape de s´election, souvent n´eglig´ee, d´efinit compl`etement l’espace de travail pour le reste du processus.
Les donn´ees en rapport avec la navigation sur le Web se repartissent en deux grands groupes : celles disponibles lorsque nous nous pla¸cons du cˆot´e client du protocole Http, et celles du cˆot´e serveur. En effet, suivre la navigation d’un utilisateur et avoir acc`es `
a tout ce qui se passe sur son poste de travail rend disponible une grande quantit´e de donn´ees, toutes d´ependantes de l’environnement de l’utilisateur en question. `A l’inverse, une application centralis´ee au niveau du serveur n’a acc`es qu’`a l’activit´e de ce dernier, ind´ependamment des environnements des utilisateurs concern´es.
Notre travail se situe dans le cadre le plus g´en´eral possible : en ce sens, nous voulons que nos m´ethodes s’appliquent quelque soit le site web utilis´e et quelque soit la mani`ere dont l’utilisateur y acc`ede. Ainsi, nous verrons que certains types de donn´ees ont par
nature un coˆut d’acquisition trop important pour ˆetre utilis´es dans un cadre g´en´eral. L’acquisition de donn´ees exotiques pour une application sp´ecifique peut ˆetre envisa- geable mais ne rel`eve pas de ce travail : nous montrons qu’il est possible d’extraire des informations de navigation d’utilisateur pour am´eliorer les services web, ind´ependam- ment du site observ´e et des outils utilis´es.
Le protocole Http est d´efini de mani`ere bi-lat´erale (client-serveur) : nous ´etudions donc les diff´erents types de donn´ees disponibles et leurs acquisitions des deux cˆot´es, client puis serveur.
2.2
Cˆot´e client ?
L’acquisition des donn´ees du cˆot´e du client correspond au cas o`u l’utilisateur veut une meilleure qualit´e de services en autorisant le syst`eme `a connaˆıtre toute son activit´e de navigation. Imaginons qu’`a chaque utilisateur d’un site web soit associ´ee une per- sonne1
qui noterait l’int´egralit´e du comportement, du plus simple clic de la souris, `a un clignement d’œil. Dans ce contexte, la diversit´e des donn´ees r´ecup´erables est immense. Nous d´ecrivons ci-apr`es quelques types de donn´ees utilis´es dans des travaux similaires. Dans [PPPS03], les auteurs expliquent que la connaissance de donn´ees cˆot´e client implique soit la mise en place d’une partie du syst`eme sur le navigateur du client, soit l’utilisation d’un navigateur sp´ecialement d´edi´e pour l’envoi d’information suppl´emen- taire. La premi`ere technique, largement utilis´ee [BLP+03, SBKF01], fait souvent appel
`
a une application en Java ou JavaScript ex´ecut´ee par le client. Ce type d’interfa- ¸cage permet de r´ecup´erer tout ou partie des informations disponibles sur le navigateur : le type de syst`eme d’exploitation, le type de navigateur, les param`etres de ce dernier (langues pr´ef´er´ees, r´esolution d’affichage, types d’application cliente reconnus), mou- vements et clics de syst`emes de pointage, entr´ees au clavier, etc. L’utilisation [CP95] d’un navigateur (( enrichi )) est peu utilis´ee `a cause du d´eveloppement demand´e pour un tel syst`eme.
R´ecemment, un nouveau concept d’affichage des donn´ees web a ´et´e mis en place : il s’agit de faire plusieurs requˆetes pour le contenu mˆeme de la page, en ´echangeant des donn´ees sous format Xml et/ou Html. En effet, le navigateur dit (( enrichi )) pos- s`ede en plus d’un moteur d’affichage, un moteur de demande de requˆetes (g´erant le Xml). Ainsi le navigateur peut demander que les parties dont il a besoin pour afficher convenablement une page web, et mˆeme (et c’est l`a son grand int´erˆet), redemander une partie qui pourrait changer en fonction de l’interaction avec l’utilisateur. Cet ensemble de techniques associ´ees, est d´enomm´e Ajax2
[Gar05]. Cette fa¸con d’afficher les don- n´ees demande une grande interaction entre moteur d’affichage et moteur de requˆete. Pour le moteur Gecko (cf. table 2.1), un langage d´edi´e Xul a ´et´e d´efini pour interagir de mani`ere simple avec le moteur d’affichage. Malheureusement, nous verrons que les navigateurs, mˆeme les plus r´ecents, ne g`erent pas les normes DOM et ECMAScript
1 ou un syst`eme de surveillance avec des facult´es sensorielles infaillibles 2 Acronyme pour Asynchronous Javascript + Xml