Frénésie, Hérésie, Wi-Fi

"La révolution Wi-Fi est en marche, les hot-spots vous permettent de vous connecter au net depuis les lieux publics, blah blah blah..." comme si c'était une réalité accessible... Vous croyez vraiment que vous allez nous refaire le coup du WAP?

1) Non les hot-spots ne donnent pas un accès rapide à l'Internet. Ils sont généralement reliés par une liaison ADSL partagée entre tous les utilisateurs du Hot-Spot. Un peu plus rapide que le GPRS certes, que l'UMTS certainement pas.

2) Non ce n'est pas pratique. Il faut acheter des coupons pour chaque Hot-Spot et la connexion + facturation est loin d'être automatique. Avantage GPRS/UMTS.

3) Vous ne pouvez pas vous déplacer. (Avantage GPRS/UMTS) Et c'est là que ça devient vraiment croustillant! Croyez-le ou non, il existe un certain nombre de personnes pour vous affirmer qu'ils vont mettre en place un maillage Wi-Fi tellement serré, couplé à une technologie de hand-over qui rendra l'utilisation transparente! :) Et ce n'est pas tout: ils ont même la solution pour les axes routiers: des bornes relais embarquées dans des véhicules! Rien de moins! Une expérience américaine rassemblerait déjà des milliers de voitures relais... Seul problème: au delà de 74 km/h les pertes de paquets deviennent trop importantes pour un fonctionnement correct! (effet doppler?)

Le WAP avait besoin de la téléphonie 3G (vitesse et terminaux) pour devenir exploitable. Le WiFi en version "hot-spot" aussi a besoin de beaucoup d'évolutions... Ironiquement, la solution sera probablement encore une fois la téléphonie 3G!! ;)

Le futur du mobile influencé par la guerre...

Non non pas de warblog ici! Mais ce qui m'amène à parler de la guerre en Irak, c'est d'apprendre que certains politiques américains s'opposent violemment à la reconstruction de l'infrastructure télécom de l'Irak en technologie GSM! Pourquoi? Parce que celà privilégierait la France (Alcatel) et l'Allemagne (Siemens) au détriment des companies américaines (Motorola)... En effet, si l'Europe utilise majoritairement la technologie GSM, les Etats-Unis, eux, utilisent surtout la technologie CDMA. Alors pas question de supporter une technologie "anti-guerre" !!! :(

Et si les US commencent à boycotter la technologie GSM, il n'y a qu'un pas pour qu'ils boycottent aussi Symbian (alliance à dominante Européenne) au profit de Microsoft et Palm...

Généralisation de Bluetooth en 2006

IDC prévoit que 80% des nouveaux téléphones et 70% des nouveaux PDA seront équipés en Bluetooth en 2006. En 2002, on était respectivement à 2,7% et 1,1%!

Il semblerait donc que Bluetooth s'apprête enfin à percer après plusieurs années où on en a beaucoup parlé mais pas beaucoup vu... L'ironie de la chose, c'est qu'entre temps il existe des technologies concurrentes non dénuées d'intéret telles que Ultrawideband (plus rapide) ou ZigBee (plus lent mais consommant moins d'énergie, et on sait à quelle vitesse Bluetooth vide les batteries!). Mais bon, un standard qui marche et qui est disponible, c'est mieux que des specs alléchantes ;)

Le Web et les Statistiques...

Le problème des stats web est extrêmement complexe. Surtout parce que ce qui nous intéresse le plus c'est de savoir:

  • combien de personnes sont venues,
  • d'où elles sont venues,
  • qu'est-ce qu'elles ont regardé,
  • pendant combien de temps,
  • quand sont elles parties,
  • et vers où sont elles parties.

Ceci est en TOTALE CONTRADICTION avec la nature même du web et de son protocole HTTP!

HTTP a été prévu pour demander des simples pages, en dehors de tout contexte. Je demande telle URL, je la reçois, fin de la discussion! En aucune manière il n'a été prévu pour interagir avec un serveur plusieurs fois de suite, en demandant une autre page dans le contexte de la précédente, etc...

En conséquence, les seules statistiques naturellement récupérables depuis un serveur Web sont les suivantes:

  • Quelles pages ont été demandées,
  • quand,
  • à partir de quelle adresse, avec quel browser, etc...

En aucune manière, les stats HTTP brutes ne permettent de savoir qui a demandé quelle page après telle autre...

Bienvenue à bidouilleland!

Evidemment, ceci est le théatre, depuis 1995 au moins, de nombreuses bidouilles, toutes plus tordues les unes que les autres, visant à regrouper ces pages par session et par visiteur unique.

Il serait totalement déraisonnable d'utiliser les adresses IP pour tenter d'identifier un utilisateur unique (ce qui n'empêche pas certains outils de stats de le faire, comme si on étant en 1990...) En effet, les adresses IP sont depuis longtemps devenues non uniques dans le temps (allocation dynamique) ni même à un instant donné (proxies, NAT...). Par exemple, lorsque deux collègues de bureau surfent simultanément sur un même site, la probabilité qu'ils utilisent tous deux la même adresse IP frise les 100% (enfin, j'exagère, mais à peine! :) )

Finalement, le moyen aujourd'hui le plus communément utilisé pour identifier un même utilisateur lorsqu'il demande plusieurs pages consécutives est le cookie... Et ça c'est quand l'utilisateur le veut bien! (Est-il nécessaire de rappeler les incessantes polémiques - largement injustifiées au demeurant - sur les cookies?)

Mais il y a pire: les serveurs web n'attribuent pas automatiquement de cookie aux utilisateurs lorsqu'ils "arrivent" (c'est à dire lorsqu'ils demandent une page pour la première fois). Il est donc nécessaire de plugguer une "saloperie" (pardonnez moi l'expression) quelque part pour poser ce cookie sur tout nouvel utilisateur. Ce cookie (s'il a été accepté par l'utilisateur) est alors renvoyé systématiquement vers le serveur web pour chaque nouvelle page demandée sur ce serveur (et ceci jusqu'à l'expiration du cookie). Il peut ainsi être enregistré avec les stats HTTP ou encore être traité directement par le plugin qui l'a posé au départ.

Tant que le browser de l'utilisateur accepte les cookies, celà fonctionne à peu près bien. Le problème, c'est que tout le monde ne les accepte pas et que de nombreux agents ne les supportent pas (browsers lights sur appareils mobiles, robots d'indexation, aspirateurs, aggrégateurs RSS, etc...)

Une autre solution, plus robuste mais aussi beaucoup plus complexe à mettre en oeuvre, consiste à inclure un identifiant utilisateur dans les URL. C'est ce qu'utilisent les plus gros sites de commerce électronique, de services bancaires etc... Le soucis étant dans ce cas d'éviter que quelqu'un d'autre n'utilise l'URL suite à un bookmark ou à un envoi d'une "adresse intéressante" par mail... Afin de se prémunir contre ça, on en vient à sécuriser le procédé avec un cookie... Par ailleurs, on perd les bénéfices des caches et des proxies... (Ces sujets mériteraient des développements plus poussés dans des articles à part entière...)

Dans tous les cas, il est impossible de savoir que l'utilisateur est parti voir ailleurs, surtout si il se contente tout simplement de fermer son browser. La seule chose qu'on peut détecter c'est que ça fait x minutes que le cookie x n'est pas revenu, donc on considère que l'utilisateur est "parti du site" mais on ne sait pas vraiment quand...

Concrêtement...

Alors, on pourrait rêver à des solutions élégantes telles qu'un protocole HTTP connecté... mais celà nécessite des modifications à l'échelle du web entier, rien que ça...

Avec les moyens du bord d'un site web lambda, les solutions disponibles se répartissent globalement dans les trois catégories suivantes:

  • N'utiliser que des pages dynamiques (type PHP, JSP, ASP, CFML etc...), poser des cookies et/ou personnaliser les URLs et traiter les statistiques au fur et à mesure, en contrôlant aussi le Referer pour détecter les clients sans cookies.
  • Inclure des "plug-ins" dans les pages web (type eStat, Xiti, etc...) afin d'assurer la pose et l'analyse des cookies.
  • Traiter du mieux possible l'analyse des fichiers de log du serveur web avec un logiciel spécialisé (type WebTrends...)

Pages dynamiques

Cette solution est la plus adaptée pour qui veut des statistiques extrêmement précises. Bien développée cette solution permettra d'obtenir virtuellement n'importe quel type de statistique dont on peut rêver... enfin dans les limites des informations disponibles! N'espérez pas obtenir l'âge de l'utilisateur sans qu'il ne vous le donne ;)

Toutefois, développer un site 100% dynamique en PHP, JSP ou autre constitue une charge de travail sans commune mesure avec l'assemblage plus ou moins progressif de simples pages HTML.

Finalement, l'énorme inconvénient de cette solution est qu'elle requiert une puissance de traitement très largement supérieure au niveau du serveur web. Les coûts d'exploitation s'en ressentent très largement. Cette solution se réserve donc plutôt aux sites disposant d'un budget de fonctionnement assez consistant.

Plugs-ins HTML

Cette solution est utilisable à peu de frais. Très peu de frais! C'est probablement même la plus économique puisque des services tels que eStat ou Xiti vous la proposent gratuitement.

Il vous suffit de vous inscrire et de placer le morceau de code HTML fourni dans vos pages web. Ce petit morceau de code sert à la fois à poser le cookie et enregistrer les statistiques comme il sert à afficher une petite icône de publicité pour le service concerné. Si vous ne voulez pas de cette icône sur vos pages vous devez payer... ce qui vous donnera également accès à des statistiques plus poussées.

Le petit morceau de code que vous insérez dans vos pages est en fait un morceau de code JavaScript. Celui-ci se charge de récupérer un certain nombre d'informations telles que le Referer, les caractéristiques de l'écran (résolution, couleurs...) et de les envoyer au service de stats. En retour le service de stats renvoie l'icône de pub (ou un simple pixel dans la version payante) et pose le cookie si nécessaire. Au passage la consultation de la page en cours est enregistrée et les statistiques sont consultables sur le site du service.

Toutefois, au delà de l'icône que vous pouvez faire disparaitre en utilisant la version payante,les inconvénients de ce type de solution sont nombreux:

  • Seules les pages dans lesquelles vous avez incorporé le code sont logguées. Vous ne pouvez donc pas suivre l'audience d'une image, d'un fichier ZIP, d'une animation Flash ou encore d'un feed RSS.
  • Si le browser n'exécute pas le Javascript (soit parce qu'il ne sait pas le faire - browser light - ou parce que l'utilisateur l'a désactivé, le système ne fonctionne pas, ou bien a moitié: tag noscript avec référencement direct de l'image sans Referer ni caractéristiques écran...)
  • Le code Xiti ne fonctionne pas dans Mozilla (et donc pas non plus dans Netscape...).
  • Si le browser ne charge pas les images (soit par incapacité - browser texte - soit par choix utilisateur), le service de stats ne fonctionne plus du tout.
  • Si l'utilisateur n'attend pas la fin du chargement de la page et que l'image de stats n'a pas encore été demandée au serveur, la page n'est pas comptabilisée.
  • Pratiquement aucun robot d'indexation ne va charger les images, leurs requêtes resteront donc également invisibles.
  • Finalement, certains logiciels servant à bloquer les publicités indésirables, bloquent également les images de stats et donc les stats sur les utilisateurs concernés!

Analyse des fichiers de logs

Cette solution nécessite plusieurs choses:

  • Avoir accès aux fichiers de log (tous les hébergeur ne les fournissent pas) et idéalement à des logs assez exhaustifs!
  • Acquérir un logiciel d'analyse (type Webtrends)
  • Idéalement: pouvoir installer le plug-in serveur sur le serveur web afin que celui-ci pose automatiquement un cookie chez les utilisateurs. Les hébergeurs mutualisés ne vous permettront pas une telle manipulation. Ceci nécessite donc un serveur dédié. Si vous ne pouvez pas installer ce plug-in, vous vous retrouvez dans la situation la plus basique, décrite au début de cet article: vous n'aurez pas de statistiques fiables sur les sessions et les visiteurs uniques.

Cette solution est la plus légère en termes de charge au niveau du serveur et par là aussi la plus élégante. C'est un bon compromis à partir du moment où vous disposez d'un serveur dédié et d'un bon logiciel d'analyse (WebTrends est très limité!)

 

Il n'y a donc pas de bonne solution en terme de staistiques web. Juste une "moins pire" à choisir en fonction de votre situation...

La fin des PDA?

Sur Mobitopia, Russel n'hésite pas à prédire la fin des PDAs:

Palm is just soooo doomed. PocketPCs for that matter as well.

...en comparant les ventes de smartphones par rapport aux PDAs...

Bien sûr, les chiffres sont peu significatifs dans la mesure où ils intègrent les téléphones équipés de gadgets tels que les appareils photos ou lecteurs mp3 et que les gens qui les achètent ne font pas vraiment partie de la même cible que celle des PDAs... Mais tout de même, il faut bien reconnaitre un début de tendance... et ce n'est pas très étonnant: les avantages d'un PDA sur un smartphone sont de plus en plus flous!

Personnellement, si j'étais fabricant de PDAs, comme je l'ai déjà dit à plusieurs reprises, j'agrandirais l'écran en laissant les smartphones coincés dans leur form factor téléphonique. Malheureusement, je ne vois rien venir à l'horizon... :( Je ne peux pas croire qu'ils n'y aient pas pensé... Mais je ne vois pas non plus la raison de ne pas le faire... Hum... en fait j'ai un article complet sur le sujet dans les cartons depuis 2 ou 3 mois... il faudrait peut être que je prenne le temps de le publier... ;)