Le problème mentionné par Ernest ici est enfin résolu :-) Enfin, incomplètement, peut-être parce qu'il ne peut pas l'être complètement. Replaçons le problème (affichage unique d'un panneau d'annonce) dans le contexte.

Acte 1 : les biscuits

Avec HTTP, impossible de savoir qui vous visite vraiment ; entre les NAT et les serveurs mandataires (proxys), l'adresse IP d'origine peut être complètement masquée, et c'est le mieux que l'on puisse avoir... et cette information seule n'est pas pertinente. Comment savoir que l'adresse IP apparente de Paul au travail (qu'il partage avec ses 30 collègues) correspond au même individu que l'adresse IP de Paul à la maison. Surtout que si Paul à la maison passe par AOL ou Free, il y a de bonnes chances qu'on n'ait que l'adresse du dernier proxy utilisé. Pour pallier à ce problème de reconnaissance de l'individu visiteur, Netscape introduisit il y a quelques années le biscuit (ou cookie pour les anglophones). Le fonctionnement en est très simple : le serveur envoie un biscuit au client (Netscape Navigator à l'époque) avec une date de péremption. Puis, à chaque fois que le client rend visite au serveur, le client lui rend une copie du biscuit tant que celui-ci n'est pas périmé. Ceci a des applications très intéressantes, la première étant les sites qui vous reconnaissent automatiquement et vous proposent une page d'accueil personnalisé, ou se souviennent tout simplement de votre nom. Qui dit "intérêt" dit aussi "intérêt commercial", et ainsi s'en suivit très rapidement l'exploitation de cette technique pas les régies publicitaires. Celles-ci ont en effet une préoccupations majeures : quelle est l'audience de la publicité ? Un chiffre facile à obtenir est le nombre de fois où la publicité est affichée. La caractérisation du visiteur est par contre plus difficile, le navigateur n'envoie pas automatiquement vos âge, sexe, CSP, revenu net annuel et solde bancaire à la régie publicitaire (quel dommage). Les régies doivent donc utiliser une autre technique : le croisement des informations. Grâce au biscuit qu'elles laissent dans le navigateur, elles peuvent suivre pas à pas les sites que l'internaute visite où leurs publicités sont affichées. Et en fonction des types de sites visités, les régies vont pouvoir déterminer qualitativement l'audience des sites, ce qui va leur permettre de déterminer la valeur de l'emplacement publicitaire (qu'on appelle chez Google le Pagerank) ainsi que le type de publicités qui cible les visiteurs du site. Tout cela est aussi croisé avec l'adresse IP du visiteur, qui peut aussi en dire long (fournisseur d'accès et localisation). Tout ceci a donné mauvaise presse aux biscuits, l'internaute ayant un désir légitime de ne pas être suivi dans tous ces déplacements. Et de toute façon, comme vous l'ont appris vos parents, on ne doit pas accepter des sucreries de quelqu'un qu'on ne connaît pas.

Acte 2 : l'importun

A CinémAsie en ce moment, nous avons deux sondages : Miss CinémAsie 2006 et les cinemasie awards 2006 (oui, c'est pompeux comme nom, dans un collectif on ne peut pas être d'accord avec toutes les décisions). Problème : personne ne va voter. La page d'accueil du site est "un peu chargée", et on ne repère pas tout de suite ces deux éléments. De plus, la page d'accueil n'est pas la seule porte d'entrée du site ; nous sommes bien en présence d'un problème de mise en valeur de l'information. A problème de publicité, remède de publicitaire : annonce affichée automatiquement à l'entrée sur le site, quelque soit le point d'accès. Mais comme nous sommes gentils avec nos visiteurs, nous voulons éviter de les importuner à chaque visite. Et comment les reconnaître et savoir qu'ils ont déjà vu la publicité pour ces deux sondages ? Avec un biscuit évidemment. Cette solution est transparente pour le visiteur dans la quasi-totalité des cas... mais pour ceux qui refusent les biscuits (et pourtant, nous ne sommes pas des inconnus !), c'est le drame. Tant que le serveur ne reçoit pas le biscuit, il force le visiteur à rester sur la publicité ; le visiteur va donc quitter le site.

Acte 3 : les solutions possibles

Première solution, s'appuyer sur l'adresse référante qui est envoyée par le navigateur. Cette adresse est aussi un élément importun du traçage par les régies, et il y a de fortes chances que ceux qui ont bloqué les biscuits ont aussi désactivé l'envoi des référants. Deuxième solution... on arrive à l'épuisement des possibilités, si le visiteur ne nous donne pas le moyen de le reconnaître, ni de savoir d'où il vient, il ne nous reste pas grand chose auquel nous raccrocher. Il nous reste donc : une adresse IP (avec tous les défauts que nous avons vu précédemment), et quelques informations mineures, comme le nom du navigateur et sa version (une fois de plus, si le visiteur n'a pas désactivé l'envoi de ces données dans son navigateur). La solution mise en place est donc la suivante : quand un visiteur arrive sur le site, on regarde s'il nous renvoie un biscuit pour la pub ; si oui, on le laisse passer. Si non, on essaie de déterminer son adresse IP et on récupère les informations sur son navigateur, et on regarde dans une base constante s'il est déjà passé par là ; si oui, on le laisse passer. Si non, on l'inscrit dans la base, on lui donne un biscuit, et on le renvoie vers l'écran publicitaire. De cette manière, on réduit l'efficacité de l'écran, vu que les visiteurs partageant la même IP et ayant la même version de navigateur (courant en entreprise) ne verront pas tous la publicité ; seulement le premier à venir sur le site en fait. Mais au moins, nous ne rejetterons plus nos visiteurs soucieux de ne pas être pollués (quoique, un biscuit c'est biodégradable).

Acte 4 : et après

Il reste toujours à régler un problème trivial : on perd le point d'entrée voulu par l'utilisateur, et s'il ne pense pas à retourner en arrière, il atterrira sur l'accueil et pas sur la page qu'il comptait initialement visiter. En ce qui concerne l'interrogation suivante d'Ernest, à savoir s'il existait une API claire pour accéder aux données du site (en CC BY-NC-SA 2.0 je le rappelle) : la réponse est non. Dans l'état actuel des choses, c'est la demande qui créera l'offre. De plus, le FF (François Fouetteur) ne m'autorisera pas à le faire tant que je n'aurais pas mis en place la cache côté serveur. Et pour finir, il faut du temps pour mettre ces choses en place. Bien sûr, pas énormément, juste un peu de temps de cerveau disponible. J'ai cru que cette semaine de congés allait me donner du temps... mais en fait, quand on en arrive à prendre une semaine de congés rien qu'avec des journées de récupération et pas un seul congé payé ni un RTT, c'est que le cerveau n'est vraiment plus disponible.