Recueil de données : coté serveur, coté Proxy et coté client

Recueil de données : coté serveur, coté Proxy et coté client

3.4 Recueil de données

Dans cette phase, différentes sortes de données sont collectées. Les plus communément exploitées sont les fichiers log enregistrés selon la position des dispositifs de collecte dans le réseau, les données issues des procédures d’inscription si disponibles, et les données sur la structure et le contenu des sites (Markov et al., 2007).

Pour pouvoir effectuer une analyse de l’usage du Web, il est nécessaire de disposer de données de trafic suffisantes et en bonne qualité. Ces deux conditions sur la quantité et la qualité des données sont d’ailleurs exigées dans tout projet de fouille. Dans le cadre du WUM, la première exigence est assurée dans la phase de recueil, alors que la deuxième condition est prise en charge durant la phase de prétraitement.

Depuis 1990, l’examen de l’offre des contenus et des services sur le Web montre une évolution apparente. Ainsi, de multiples protocoles (http, ftp, pop3…) et différentes méthodes de présentation de contenu (statiques, dynamiques) sont actuellement implémentés.

Si du point de vue de l’utilisateur, ces détails techniques sont insignifiants, et la diversité des logiciels est transparente, et tous ces éléments sont pour lui en total continuité, alors en développant des outils de recueil de traces de navigation, on est obligé par contre de prendre en considération tous ces aspects. Il est important d’avoir un angle d’approche technique de l’activité sur internet. Quels protocoles sont utilisés, par quelles applications passent-ils, quel est le format de données envoyées et comment les intercepter ? (Beauvisage, 2004).

Le WUM est basé sur les données de trafic collectées à partir de trois sources : les serveurs Web, les serveurs proxy, et les clients Web. La collecte de données de ces trois sources présente chacune des avantages et des inconvénients.

Les types de données recueillies diffèrent non seulement en terme de localisation, mais aussi sur la nature des données disponibles, la population des usagers concernés, et dans les méthodes d’implémentations (Cooley, 2000). Nous présentons les propriétés de chaque approche dans les sections suivantes.

3.4.1 Recueil coté serveur (1-site : N-utilisateurs)

Les serveurs Web sont indiscutablement la source de données la plus riche et la plus utilisée en WUM (Cooley, 2000), (Facca et al., 2005). La quasi-totalité des projets en WUM se fondent sur des données de trafic issues des serveurs Web, car ils peuvent être configurés à enregistrer automatiquement, dans des fichiers log, les traces de requêtes effectuées par les utilisateurs du site.

Ce type de projets, tels que WEBMINER (Cooley et al., 1997), Web Utilization Miner (Spiliopoulou et al., 1999), WebSIFT (Cooley, 2000), sont qualifiés de site-centric.

Une littérature relativement abondante traite de l’analyse des usages du coté des serveurs Web. Un tel engouement s’explique par les enjeux économiques sous-jacents à ces recherches : les sites à vocation commerciale souhaite disposer de données les plus précises possibles sur leur fréquentation, afin de savoir qu’elles pages sont les plus visitées, comment les utilisateurs y arrivent, et comment les faire rester plus longtemps sur le site (Beauvisage, 2004).

Les fichiers logs serveur sont de type texte. Ils consignent pour chaque requête reçue une réponse, sous forme d’une seule ligne ASCII qu’ils ajoutent à la fin. Ces fichiers sont stockés sous différents formats, dont le plus utilisé est le CLF (Common Log Format), ou sa version étendue l’ECLF (Extended CLF).

Les informations de base qui y sont enregistrées sont : l’adresse IP du client, l’identification de l’utilisateur, la date et l’heure de l’accès, la requête proprement dite (composée de quatre champ : la méthode utilisée : GET, POST, PUT ou HEAD, l’URL, une entête, et le protocole), et un code statut, plus la taille indiquant le nombre d’octets retournés (Cooley, 2000).

Le format ECLF ajoute deux autres informations : le referrer, qui renseigne sur la page de provenance, c’est-à-dire l’URL du site visité avant par l’utilisateur qui le lie à la page courante, et le user-agent fournissant des informations sur l’environnement du client, telles que : la version du navigateur et du système d’exploitation, et peut dans certain cas contenir l’identification d’un robot Web (W3C, 1995), (W3C, 1996), (Markov et al., 2007).

Deux exemples du champs user-agent pour une machine exécutant windows 2000 et utilisant Internet Explorer 6 et Firefox 1.0.7 sont respectivement : « Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) », et « Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 ».

Une alternative au collecte de données d’usage du Web coté serveur est l’utilisation de la technique des packet-sniffers (Kammenhuber et al., 2006)1. Ces derniers, sont des logiciels permettant d’intercepter les données transmises dans une communication réseau, en captant les paquets TCP/IP échangés sur la couche réseau.

Cette technique permet le recueil de données en temps réel, et offre la possibilité de fusion des informations provenant de différents serveurs, et de détecter la rupture de la communication (clics sur le bouton stop). Malgré les avantages des packet-sniffers, ils sont rarement utilisés en pratique, en raison des difficultés du passage à l’échelle rencontrées dans l’analyse de serveurs ayant un trafic important, et leur inadéquation aux communications sécurisées et cryptées (Facca et al., 2005).

Une autre solution, de recueil centré serveur, est l’utilisation des outils permettant l’accès à la couche application sur les serveurs. Cette solution est probablement la meilleur selon (Facca et al., 2005), mais reste difficile à mener en raison des spécificités des applications sur les serveurs et les droits de copyright.

3.4.2 Recueil coté Proxy (N-sites : M-utilisateurs)

Un proxy est une machine intermédiaire placée entre le client et le serveur, qui permet d’acheminer indirectement les requêtes de l’un vers l’autre. Ces machines servent à plusieurs fonctions. Elles sont souvent utilisées par les fournisseurs d’accès à Internet (FAI) comme machine offrant des connexions Web à un groupe d’utilisateurs, ou pour implémenter des mécanismes de cache, afin d’améliorer le trafic des réseaux importants. Elles peuvent jouer aussi le rôle, dans les organisations protégeant leurs systèmes, de machines pare-feu dans le cadre d’une stratégie de sécurité.

L’emploi des serveurs proxy dans le recueil de données aux fins de WUM offre l’avantage, par rapport aux autres sources de données, de pouvoir étudier le comportement d’un groupe d’utilisateurs sur un ensemble de sites (Cooley, 2000),

(Kerkhofs et al., 2001),(Hong et al., 2001). Cependant, ces méthodes restent similaires aux méthodes centrées serveur, elles utilisent des formats de données analogues, et posent les même problèmes. Notons que certains chercheurs confondent les deux approches précédentes, et considèrent seulement deux classes de sources de données en WUM, les collections coté serveur et celles coté client (Shahabi et al., 2001), (Murgue, 2006).

1 Les packets sniffers peuvent être implémentés sous Unix (bibliothèque libpcap), ou sous windows (bibliothèque winpcap). (Kammenhuber et al., 2006) utilise Bro http analyser, un outil utilisé dans les environnements Unix dans le cadre de l’analyse de la sécurité, fondé sur les packet-sniffers.

3.4.3 Recueil coté client (N-sites : 1-utilisateur)

Contrairement aux méthodes de recueil de traces de navigation centrées serveur, qui sont maintenant relativement standardisées et validées, la collecte coté client, i.e au niveau des postes des utilisateurs, est encore un champ d’activité en devenir, du fait des différents choix technologiques possibles et du degré de finesse des informations que l’on souhaite recueillir (Beauvisage, 2004). Cette approche est réputée plus riche et précise, car elle opère sur la source des actions de l’utilisateur, et permet ainsi de mieux décrire son comportement.

Elle est en plus préférée du fait qu’elle permet de surmonter l’ensemble des problèmes relatifs à la préparation des données collectées (utilisateurs identifiés, sessions facile à reconstruire…etc.), (Cooley, 2000). Pour ce faire, deux techniques sont généralement employées.

Les agents distants chargés du suivi par l’enregistrement puis le transfert des actions de l’utilisateur sur un site donné. Ces modules logiciels se reposent sur les applets Java ou les modules en JavaScript, solution retenue dans plusieurs travaux (Shahabi et al., 2000),(Shahabi et al., 2001),(Obendorf et al., 2004).

La deuxième technique est l’utilisation d’un navigateur modifié, où la sonde de collecte est intégrée dans le logiciel client lui-même. La première étude de l’usage du Web centrée utilisateur utilise ce procédé en étendant la navigateur XMosaic (Catledge et al., 1995),(Cunha et al., 1995).

Plus récemment, cette approche a été utilisée dans (Lu et al., 2003) et (Zhou et al., 2005) en se basant, pour Internet Explorer, sur la technique des Browser Helper Object (BHO) de Microsoft (Roberts, 1999), et dans (Beauvisage, 2004) en exploitant les technologie NetMeter développée par la société NetValue, et Audinet réalisée par France Télécom R&D. (Weinreich et al., 2006) adopte cette technique, en altérant le code XUL (XML User Interface Language) du navigateur Firefox.

Une version légère de l’approche des browsers modifiés consiste à recourir aux fonctionnalités d’enregistrement des données offertes déjà dans certains navigateurs. A titre d’exemple, Cockburn et McKenzie se servaient en 2000, à l’université de Canterbury (New Zealand), des fichiers history.dat et bookmarks.html du navigateur Netscape (Cockburn et al., 2001),(Baldi et al., 2003).

Malgré la richesse qu’offre la collecte de traces coté client, cette approche présente un inconvénient majeur. En effet, elle dépend fortement de l’environnement du client (Murgue, 2006), et exige la coopération des utilisateurs, par l’activation des options de support des applets et JavaScript dans leurs navigateurs, ou d’accepter de se servir volontairement de la version modifiée du logiciel client qu’on leur propose.

Par ailleurs, les applets java peuvent affecter les temps de consultations des pages, en raison des délais nécessaire à leur chargement. Alors que les modules en JavaScript, même si légers en interprétation, ils ne peuvent capter toutes les actions effectuées par l’internaute (clique sur les boutons : précédent, actualiser…) (Cooley, 2000). .

Pour citer ce mémoire (mémoire de master, thèse, PFE,...) :
Université 🏫: Université Kasdi Merbah de Ouargla - Option : Informatique et Communication Electronique - Mémoire du diplôme de Magister
Auteur·trice·s 🎓:
Slimane OULAD NAOUI

Slimane OULAD NAOUI
Année de soutenance 📅:
Rechercher
Télécharger ce mémoire en ligne PDF (gratuit)

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Scroll to Top