fplanque: blog geek

Je pense que l'on sous-estime systématiquement la rigueur nécessaire à la production de code XHTML valide... nos browsers sont TELLEMENT permissifs! :'(

Personnellement je m'en suis rendu compte en collant ce petit logo en bas de chacune de mes pages:


On a si vite oublié un caractère accentué par ici ou un & par là... voire un / en fin de balide IMG... Le bouton sur chaque page aide à les vérifier... mais je dois avouer que je n'ai pas eu le courage de les faire vraiment toutes... :-/

Ceci dit, ma plus grosse perte de temps a été d'essayer de rendre valide les pages de blog, lesquelles contiennent des tags RDF permettant théoriquement aux clients de découvrir automatiquement l'adresse de trackback. Pas moyen de les faire accepter au validateur. Ca s'est fini entre commentaires HTML... comme préconisé par Movable Type...

PS: ah oui, à voir aussi: la méthode b2 pour rendre le RDF valide: si HTTP_USER_AGENT contient 'W3C_Validator' alors on n'envoie pas le RDF... PFOUAH! 8|

Vous avez peut être remarqué que les entêtes de pages et la navigation de ce site ont très légèrement changé... c'est le résultat de longues contorsions CSS pour supprimer tous les tableaux inutiles de ce site! (C'est à la mode! :P )

En fait, c'était plus un exercice de style qu'une réelle conviction que les tableaux doivent être définitivement bannis comme technique de mise en page HTML. Enfin plus précisément: oui IDEALEMENT il ne faudrait pas utiliser de tableaux à de seules fins de mise en page et tout faire en CSS, mais je pense que les implémentations actuelles de CSS dans les navigateurs les plus courants sont insuffisantes pour obtenir les résultats voulus. Alors certes, j'y suis (à peu près) arrivé mais ce fut beaucoup plus compliqué qu'avec des tableaux. On ne peut pas espérer, dans ces conditions, que la majorité des webdesigners se mette "à la page"!

PS pour les mordus: Je voulais que mes "rollovers" de navigation aient tous la même largeur. C'est ça qui complique tout (voir code source...) Si je m'étais contenté d'une largeur proportionnelle au texte celà aurait été enfantin (Je ne comprends d'ailleurs pas pourquoi Mark à fait tout un foin de ses onglets -- proportionnels évidemment! :>> ). Par ailleurs, je voulais que le tout soit redimensionnable en fonction de la taille de police choisie par l'utilisateur (et même sous IE). Finalement, il me reste un problème: du contenu invisible à droite de la boite de titre de la page. C'est gênant (enfin, je pinaille...), car il fait apparaitre un ascenseur en bas de page avant l'heure lorsque l'on réduit la largeur de la fenêtre! Si vous savez faire disparaitre ça (sans provoquer de retour à la ligne du titre dans certains browsers), vous êtes probablement un Dieu vivant du CSS pratique! :D

On peut (aussi) afficher le code source en tapant view-source: dans l'adresse avant http: ;)

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...

Je viens de lire un article tellement intéressant de Joel on Software sur les communautés en ligne que j'ai pensé devoir absolument le signaler ici! :P

C'est en anglais mais explique particulièrement bien la raison d'être des communautés et ce qui permet qu'elles fonctionnent bien ou mal ou pas du tout...