(norme de langage `a l’origine de Javascript) de mani`ere indentique. Un d´eveloppement coˆuteux est donc n´ecessaire aves ces nouveaux clients (( enrichis )).
Il est `a noter que d’autres donn´ees ont pu ˆetre utilis´ees de mani`ere marginale dans le but d’augmenter les pertinences de traitement. Ces derni`eres sont g´en´eralement is- sues de protocoles d’acquisition lourds et coˆuteux. Les donn´ees oculom´etriques [GE03], en sont un exemple : le mouvement des yeux des utilisateurs est enregistr´e par une cam´era, ce qui permet de reconstituer le chemin visuel de l’utilisateur. Ces donn´ees sont plus souvent utilis´ees pour am´eliorer l’ergonomie d’un site web. En effet, la diffi- cult´e [GSL+02] inh´erente `a l’acquisition de ces derni`eres ne permet pas une exploitation simple pour un probl`eme qui se veut g´en´eral.
L’ex´ecution cˆot´e client de code d´evelopp´e pour un serveur en particulier repose sur de nombreux concepts : en effet, pour ce type de mise en œuvre, il est indispensable de pouvoir appliquer une commande `a une partie d’un document ou `a un ´el´ement du navigateur (comme par exemple : changer le type de message de la barre d’´etat du navi- gateur). Pour cela, il est indispensable d’utiliser un langage de programmation agissant sur des objets d´efinis comme ´etant soit des parties du document, soit du navigateur lui-mˆeme. Les diff´erents navigateurs utilisent tous un langage de programmation compa- tible avec la norme ECMAScript [Int99] agissant sur des objets du DOM3
[W3C04]. Un des probl`emes, cependant, est la grande diversit´e des implantations des langages de type ECMAScript et du mod`ele d’objets propres `a chaque client. Pour r´esumer, la table 2.1 rassemble les diff´erentes entit´es utilis´ees pour chacun des six moteurs d’affi-
Moteur Version ECMAScript Version DOM4
Gecko, SpiderMonkey JavaScript 1.6 DOM Level 3 (non test´e)
Trident JScript 5.6 DOM Level 3 (en partie) 5
Presto ECMAScript6
DOM Level 3
Tasman JScript 5.6 DOM Level 0
iCab InScript 3.22 DOM Level 2
KHTML JavaScript 1.5 DOM Level 2
Tab.2.1 – R´esum´e des diff´erents langages ECMAScript et mod`eles DOM support´es par les navigateurs courants
chage les plus r´epandus. Notons que les navigateurs issus de Mozilla (Firefox, Camino) utilisent le moteur Gecko, Internet Explorer pour Windows le moteur Trident, Opera le moteur Presto, Internet Explorer pour Mac le moteur Tasman, iCab le moteur ´epo- nyme, et enfin Konqueror le moteur KHTML.
Cette table rassemble les diverses versions ECMAScript et DOM de ces moteurs. Il apparait difficile alors de d´evelopper des m´ethodes g´en´eriques lorsqu’un navigateur choisi utilise des langages sp´ecifiques. Le grand nombre de navigateur web supportant
3 De l’anglais : Document Object Model
4 Le site http://www.webdevout.net/browser support dom.php donne en d´etail l’´etat de support
des sp´ecifications DOM. Les navigateurs de type Gecko ont l’air les plus avanc´es.
5 (( With only a few minor exceptions )) : annotation mentionn´ee sur le site de Microsoft
ou pas telle ou telle sp´ecification du w3c, ou l’implantant de mani`ere non ´equivalente `a un autre, nous conduit `a ne pas envisager le cˆot´e client comme une bonne solution pour notre probl`eme, `a savoir r´ecup´erer de mani`ere automatique les informations pertinentes de navigation d’un utilisateur.
En r´esum´e, le cˆot´e client demande une acquisition des donn´ees fortement d´epen- dantes de l’environnement o`u ´evolue l’utilisateur. Cette vision peut toutefois ˆetre en- visag´ee pour une forte optimisation d’un site web particulier avec un coˆut ´elev´e de d´eveloppement. Plac´e du cˆot´e serveur, un syst`eme de surveillance sera moins coˆuteux mais ne verra que l’activit´e du serveur lui-mˆeme.
2.3
Cˆot´e serveur ?
`
A l’inverse du cˆot´e client o`u toutes les donn´ees ayant un lien avec la navigation de l’utilisateur pourraient ˆetre enregistr´ees (mais au prix d’un investissement colossal), le cˆot´e serveur ne dispose que de tr`es peu de donn´ees, toutes regroup´ees dans les fichiers de logs et la structure mˆeme du site consid´er´e.
2.3.1 Logs serveurs ?
L’activit´e d’un serveur web est compos´ee d’une succession d’´etapes : la r´eception d’une requˆete en provenance d’un client, l’analyse de la requˆete, la cr´eation de la r´e- ponse, l’envoi de cette derni`ere. La totalit´e de ces informations peut ˆetre stock´ee dans un fichier d’enregistrements (ou logs), mais en pratique seule une s´election d’informa- tions propre `a chaque serveur est sauvegard´ee. Le w3c recommande [Luo95] toutefois de stocker les ´el´ements suivants :
– nom (ou adresse r´eseau) de la machine cliente ; – nom d’utilisateur distant ;
– nom d’utilisateur authentifi´e ; – date et heure de la requˆete ; – requˆete envoy´ee par le client ; – type de r´eponse du serveur ; – taille de la r´eponse.
Le protocole Http pr´evoit lors de la cr´eation d’une requˆete (respectivement d’une r´e- ponse) une liste de donn´ees permettant de d´efinir divers autres param`etres : de la gestion des caches `a l’encodage de la requˆete (ou r´eponse) en passant par des informations com- pl´ementaires de nature vari´ee (langage, type de navigateur, information suppl´ementaire d’erreur, date de derni`ere modification du document, type de contenu de la r´eponse). Ainsi une requˆete/r´eponse est toujours compos´ee d’une premi`ere ligne mentionnant son type, suivie d’un nombre quelconque de lignes facultatives d´ecrivant les param`etres optionnels.
Pour rechercher dans cette source de donn´ees des informations pertinentes sur la navigation d’un utilisateur, nous devons d´efinir quelques notions de bases. Pour cela, le