Le processus de prétraitement en WUM : le nettoyage des données

Le processus de prétraitement en WUM : le nettoyage des données

3.5 Prétraitement

Comme nous l’avons vu dans le chapitre précédent, les indicateurs de métrologie relative au Web montrent une évolution exponentielle de celui-ci. Ainsi, et l’instar des données de contenu du Web, les données de son usage collectées dans des fichiers logs ont atteint à leur tour des dimensions colossales.

A titre indicatif, la taille des fichiers logs de certains sites populaires se compte en gigaoctets, comme c’est le cas de Yahoo !, qui collectait en mars 2002 presque 100 GO de données logs Web par heure (Tanasa et al., 2003). Ces volumes énormes de ce type de fichiers constituent une des difficultés majeures à leur manipulation par les algorithmes de fouille, même les plus astucieux entre eux.

De plus, il a été prouvé dans de nombreux travaux (Cooley et al., 1999), (Srivastava et al., 2000),(Berendt et al., 2002), (Murgue, 2006) que ces données sont dans une forme très brute, et inappropriée pour une application directe et fructueuse des techniques de fouille de données.

Ces aléas inhérents aux données d’usage du Web1, qui les rendent incohérentes, erronées et non fiables et limitent leur exploitation naturelle, sont dus à plusieurs éléments, dont les plus prépondérants sont la nature même du protocole http, et l’organisation hiérarchique de l’Internet (Cooley et al., 1999),(Murgue, 2006).

Partant du principe que la qualité des connaissances extraites à partir de ces fichiers est fortement liée et conditionnée par la validité des données recueillies (Berendt et al., 2002), une phase de préparation de ces données s’avère donc nécessaire. Cette phase, dite de prétraitement, à pour objectif d’adapter les données logs à la technique de fouille envisagée. Pour ce faire, elle consiste en vue d’aboutir à des objets « fouillables » d’une part à réduire la taille des données en éliminant celles inutiles à l’analyse et présentant du bruit, et d’autre part de corriger les incohérences existantes. Cette phase inclut souvent une étape de formatage des données corrigées obtenues (Cooley, 2000).

Eu égard aux volumes gigantesques et la nature des données de faible qualité qu’elles traite, la phase de prétraitement est donc très complexe, fastidieuse et consomme un temps énorme, mais reste en revanche primordiale dans tout projet de WUM. Malgré son importance, la littérature consacrée à cette étape reste, selon (Facca et al., 2005), limitée, et la référence la plus complète dans le sujet (l’article de Cooley et al.) date depuis 1999.

Dans cette phase fondamentale, plusieurs tâches doivent être accomplies, qui diffèrent parfois légèrement selon la source d’acquisition des données et la technologie de construction des sites (Cooley, 2000). Si on prend, par exemple, une approche centrée serveur actuellement standardisée, le prétraitement y inclut : le nettoyage des données, l’identification des utilisateurs, l’identification de sessions, et la reconstruction des parcours de navigation (Cooley, 2000).

Pour l’étude du comportement de l’utilisateur, une des finalités en WUM, on ne concentre pas sur la requête http élémentaire, comme on pourrait l’imaginer, mais sur la session de l’utilisateur. Cette dernière, devait être extraite à partir du fichier log, et constitue donc l’unité d’analyse servant de base aux études en WUM. L’étape de prétraitement à comme but de constituer ce fichier des sessions et de le présenter en entrée à la phase de découverte de connaissances.

1 Cf. (Shahabi et al., 2001) pour une bonne discussion sur les problèmes du coté serveur.

3.5.1 Nettoyage

Nous venons de voir que les fichiers logs Web sont caractérisés par leur taille importante. Nous montrons dans ce qui suit, qu’ils incorporent de plus des données superflues et bruitées.

Le nettoyage est une étape cruciale en WUM. Il vise à réduire la taille des logs, en éliminant toutes les requêtes jugées inutiles pour l’analyse. Par le filtrage des données incohérentes et inappropriées, non seulement on gagne de l’espace disque, mais dans le même temps on rend plus efficaces les tâches qui suivent dans le processus de WUM (Tanasa et al., 2003).

Il est primordial quelque soit la source d’acquisition des données utilisée, mais il est en particulier plus déterminant dans les approches de recueil centrées serveur, où l’acquisition des données est effectuée automatiquement et à grande échelle par les serveurs Web, et du fait que les collections de données obtenues avec cette technique sont exposées à plusieurs sources d’incohérence.

Etant donné qu’une page Web, l’unité ergonomique perçue par l’utilisateur, est le résultat de l’assemblage d’éléments hétérogènes (textes, images, sons, scripts, frames….etc.) dont la production est assurée par un ou plusieurs serveurs et la composition par le navigateur, lors d’une requête correspondante à une page le navigateur exécute automatiquement plusieurs autres requêtes vers le serveur : une pour la page, et une autre pour chaque élément la constituant.

En prenant en compte l’objectif du WUM, qui est l’analyse du comportement des utilisateurs à travers l’étude de leurs motifs d’accès, il est de bon aloi de supprimer les entrées des fichiers logs correspondantes aux requêtes pointant explicitement vers des images ou des fichiers dont on est sûr qu’ils ne constituent pas des sources de pages et qu’ils ne représentent pas des requêtes explicites de l’utilisateur.

On ne retient alors que les requêtes vers les fichiers html, ce qui nous permet de se rapprocher le plus possible d’une correspondance entre requête et page vue. Ce filtrage est aisé, puisque il consiste à repérer les extensions des fichiers correspondants à des formats de fichiers précis (jpg, jpeg, gif, css, js…), (Cooley et al., 1999),(Beauvisage, 2004), (Murgue, 2006).

Mentionnons toutefois, que la suppression des requêtes pointant vers les fichiers multimédia, bien qu’elle soit une règle dans le nettoyage en WUM, elle n’est pas absolue. En effet, si le site analysé est spécialisé dans l’offre de produits multimédia, il est évident que les requêtes vers ces fichiers doivent être conservées, car elles expriment des actions liées à un comportement utilisateur (Cooley, 2000). Les requêtes vers ce genre de fichiers seront aussi gardées si l’intention de l’étude de l’usage du Web est l’analyse de trafic Web (Tanasa et al., 2003).

Récemment, (Weinreich et al., 2006) identifie trois catégories, moins présentes auparavant, de requêtes de pages, qui ne sont pas reliées à des actions délibérées des utilisateurs. Il s’agit des pages de sites utilisant les frames html ou inlines (iFrames), les annonces publicitaires et les rechargements automatiques de pages. Cette référence propose des heuristiques pour l’identification de ce type de requêtes, qui sont exclues dans l’analyse de l’usage car elles introduisent du bruit, étant donné qu’elles ne sont pas initiées par l’utilisateur.

Un autre type de requêtes qui introduisent des distorsions dans les fichiers logs sont celles effectuées automatiquement par les robots Web. Ces derniers sont actuellement largement utilisés dans différentes fonctions, telles que pour la découverte de ressources, la vérification de liens, la construction et la mise à jour d’indexes dans les SRI, ou comme assistants à la navigation. Ils affectent de manière significative ces fichiers (Cooley, 2000), (Tan et al., 2000).

Le comportement de navigation de ces robots est loin, en étendu ou en vitesse, à celui observé chez l’homme. Il est judicieux de filtrer les entrées qu’ils génèrent, et ne reflétant pas un comportement utilisateur.

Si les concepteurs des robots Web respectent les règles d’écriture de ces outils1 (Tan et al., 2000), leur repérage serait simplifié. Dans ce cas, on se basera sur le champ user- agent de la requête, qui nous renseigne sur l’identité du robot, ou en détectant l’accès au fichier robot.txt disponible sur le site.

Cependant, de nos jours, il est presque impossible de connaître tous les robots web, en raison de leur nombre croissant et le manque de respect des standards dans leur développement. Dans de pareils cas, on fera recours à des heuristiques, telles que celles proposées dans (Tan et al., 2000) ou (Tanasa et al., 2003).

Les tâches de suppression des requêtes relatives aux images et scripts, ainsi que celles provenant des robots web permettent, une fois achevées, de minimiser considérablement la taille des fichiers logs de départ. Le gain obtenu peut dépassé, dans certain cas, plus de 50% (Tanasa et al., 2003).

Additivement à ces filtrages, d’autres tâches peuvent être accomplies dans cette phase. Ainsi, on peut envisager de fusionner plusieurs fichiers logs si on se situe dans le cadre d’un WUM multi-sites (Tanasa et al., 2003), ou d’une acquisition de données par des approches hybrides comme celle utilisée par (Weinreich et al., 2006), qui combine des fichiers logs client avec un log proxy.

On peut aussi filtrer les requêtes non réussies en examinant les codes statuts correspondants (doivent être différents de 200), (Murgue, 2006), et opérer un découpage des URLs à leurs principaux composants (Beauvisage, 2004)…etc.

1 Ces règles incluent les points suivants : le robot doit s’identifier auprès du serveur web (le champ agent), il doit modérer son rythme d’acquisition des données, et respecter les permissions définies dans le fichiers robot.txt du serveur qu’il doit consulter en premier.

Notons en fin que le travail fastidieux de nettoyage, et de prétraitement en général, sera grandement simplifié si nous adoptons une approche d’acquisition de données du coté des clients. En effet, les collections obtenues par cette approche sont plus fiables et précises, et peuvent être de plus contrôlées par le concepteur et sont exemptes des problèmes des robots web.

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