4.4.1.3 Filtrage des items inutiles
Pour des contraintes qui nous échappent, liées à la coopération et les relations humaines et aussi à la disponibilité et bien que le nombre d’utilisateurs ayant accepté de participer à l’expérimentation, qui n’a durée que quelques jours, est faible, le nombre d’entrées du
rapportent pas forcement à des actions explicites des utilisateurs, ou sont le résultat d’une situation d’incohérence dans le fonctionnement du système de l’usager. A cet effet, des modules ont été écrits afin d’identifier, puis d’éliminer ces entrées. Les principales sources d’incohérences, à notre point de vue, sont ci-dessous expliquées :
1. les adresses MAC invalides : dans la fonction de détection d’adresses MAC, une constante matérialisée par la valeur '00-00-00-00-00-00' est retournée en cas d’absence de connexion, ou si des erreurs de communications, avec la carte réseau, sont renvoyées. Une partie non négligeable d’entrées du log ont été trouvé avec la constante d’erreur ci-dessus. Ces entrées correspondent donc aux usagers continuant à surfer en la présence de cette situation d’erreur qu’ils l’ont ignoré par méconnaissance.
2. les urls non ciblées : pour fins de réduction de données et simplification de l’étude, un choix a été fixé au départ consistant a ne tracer que les requêtes pour le protocole http ou sa version sécurisée https, et le protocole ftp. Nous filtrons donc toute entrée dont l’url ne respecte pas ces deux protocoles.
3. les requêtes provenant des frames : les pages avec frames sont l’une des sources d’incohérence les plus difficile à résoudre. Cette question sera discutée dans le point suivant.
4. les requêtes vers les ressources locales : l’une des caractéristiques des BHO est leur capacité de tracer non seulement les évènements d’IE, mais aussi ceux liés à l’explorateur windows (Roberts, 1999). Un premier niveau de filtrage des évènements de l’explorateur de windows est assuré donc dans l’outil de collecte de traces lui-même, en n’autorisant le recueil de traces que si l’application cliente du BHO est le navigateur (nom de l’exécutable iexplore.exe). Par ailleurs, notre objectif est l’étude de l’usage du web, les navigations effectuées offline, ou vers des pages stockées sur le disque local ne sont pas prise en considération. 5. les items à jeux de caractères non latins : dans le fichier log textuel, les pages
des sites à jeux de caractères non latin sont consignées dans le format texte standard avec des caractères illisibles, c’est le cas par exemple des sites en
arabes, en chinois…etc. Ces items ont été malgré cela conservés dans le log et exploités en termes de pages visitées et la temporalité de cet usage.
6. les items orphelins : les items orphelins sont des entrées du fichier log qui avant ou après les différentes opérations de nettoyage se trouvent isolées. Il peut s’agir de requêtes seules pour une des fenêtres d’une navigation, d’évènements de fermeture (code 03) de fenêtre délaissés, ou d’évènements quelconques (de type 01,02 ou 03) relatifs à des fenêtres terminées ou inexistantes lors d’une session.
L’algorithme suivant permet de supprimer les entrées ayant des adresses MAC invalides, des urls inutiles, ou les requêtes vers les pages locales. Les items pour frames et orphelins seront traités dans les algorithmes suivants.
Procedure nettoyage Entrée : log brut Sortie : log nettoyé
debut
Ouvrir la table Log ; Tant que non Log.EOF faire Debut
Log.Lire (item) ;
Si MAC(item)=MAC_Invalide ou URL(item) est locale ou Protocole(item) non dans (http,https,ftp) alors Marquer_Item_Pour_Effacement fsi ; Fin Tant que ;
Fin de nettoyage
11. Suppression d’items inutiles
4.4.1.4 Question des pages avec frames
Une page à frames est une page (dite frameset) constituée de plusieurs autres pages ou cadres (qui peuvent à leurs tours contenir récursivement des frames) affichées par le navigateur quand cette page est demandée. Ce mécanisme est une autre source qui est à l’origine du bruit introduit sur les données collectées. Si la page contient n frames, alors à une requête (évènement 01) vers l’url de cette page, le navigateur émet n+1 autre requête, une pour chaque sous-page, et une dernière pour le top page. De plus, et selon la documentation de Microsoft (Roberts, 1999), l’évènement DocumentComplete est
dernier événement n’est pas déclenché par chaque frame, mais il est lancé par tout frame entraînant auparavant un évènement DownloadBegin (Cf. annexe 2). Il est enfin, déclenché toujours par la top page, une fois toutes les sous pages concernées l’ont déclenché.
Ce problème constitue un vrai casse-tête et demeure à l’heure actuelle posé. (Beauvisage, 2004) constatait en page 68 : « ce problème est à ce jour quasiment impossible à
régler de manière satisfaisante sur la base de donnes de trafic : ni l’exploitation du champ Referer dans les entêtes http, qui renseigne l’url à l’origine des requêtes, ni la détection des rafales de requêtes ne permettent de distinguer systématiquement si les requêtes correspondent à des pages ou des composants de pages».
A titre de contribution, et afin d’apporter une solution a ce problème, nous avons d’abord prévu de détecter dans l’outil d’acquisition de traces les pages avec frames, et de récupérer en outre le nombre de frames pour chaque page de ce type. Ceci a été réalisé par l’accès à la propriété frames de l’objet Document de la page une fois celle-ci est complètement téléchargée.
//--- extrait de la méthode invoke du BHO --- Entrée : évènements d’IE, avec autres paramètres
Sortie : log brut, avec pour les page à frames le nombre de frames
// lorsque la page est complètement téléchargée on la trace et on // récupère le titre et le nombre de frames s'il y on a
….
DISPID_DOCUMENTCOMPLETE: begin
url:=TDispParams(Params).rgvarg[0].pvarVal^; Doc:=FWebBrowser.document;
Titre:=Doc.title; // le titre de la page
Frames:=Doc.frames.length; // nombre de frames s'ils existent …