Les formats graphiques
Construire un site Web
Protocoles de messagerie
Le protocoles FTP
Le dessin vectoriel
Cours de Basic
Retouche d'images
Le langage XML
Les associations
Le E-commerce
Les virus
La compression
Les cookies
Trouver un job
La comptabilité
Comprendre la paie

Comprendre l'informatique

Les cookies

Bref historique

Nous allons dans cet article essayer d'expliquer quelle la fonction d'un cookie, et chacun verra qu'il n'y a pas de quoi se faire des cheveux blancs, bien que des dérives soient toujours possibles, ce qui est de toute façon le cas de toutes les technologies.
Pour des raisons qui relèvent de la théorie du complot (je fais partie des initiés), il est de bon ton d'adopter un ton techno-paranoiaque vis à vis de l'internet et de ses technologies secrêtes. Ainsi des cookies qui ont été accusés d'à peu près n'importe quoi ; de fliquer les internautes, de fournir des informations ultra-confidentielles à des vilains sites marchands, etc …

Leur fonctionnement

Pour comprendre ce qu'est un cookie, il faut en revenir à la base, c'est à dire au HTTP [1]. Le HTTP est le protocole qui s'établit entre un navigateur et le serveur web en face.

Ainsi lorsque le navigateur désire afficher une page, il envoie une commande au serveur (commande GET + le nom de la page), commande qui est récupérée par le serveur, lequel renvoie la page toujours suivant le protocole HTTP.
Nous n'allons pas entrer dans le détail, mais il est important de comprendre une chose : lorsque le navigateur veut afficher une page il accomplit les tâches suivantes :

- Il ouvre une connexion réseau (en pratique il ouvre une socket)
- Il envoie la commande GET pour obtenir la page
- Il récupère les données que lui envoie le serveur
- Il ferme la connexion.

Ainsi à chaque page qu'il veut afficher, il est obligé d'effectuer cette même séquence. Cela à pour conséquence que s'il veut afficher une page 2 à la suite d'une page 1, le serveur n'a aucune chance de savoir que c'est le même navigateur qui veut faire cette opération. A chaque fois, on repart de zéro.
Le HTTP est dit stateless (sans état), car le serveur ne garde pas la mémoire des états précédents et est incapable d'associer une série d'opérations à un navigateur particulier, et donc à un utilisateur donné.

Prenons un exemple : vous utilisez une messagerie web type Hotmail. La page 1 est constituée par la page de login (avec le login et le mot de passe à rentrer), la page 2 par la liste des messages. D'après ce qui a été dit précédemment lorsque le serveur devra afficher la liste des messages, il ne saura pas que c'est l'utilisateur machin qui a entré ses coordonnées sur la page 1, et ne pourra donc pas afficher les dits messages.

C'est très gênant. Le HTTP est incapable de gérer la notion de session. Une session est l'intervalle de temps qui sépare une connexion d'une déconnexion. Lors d'une session, le navigateur (donc l'utilisateur) est reconnu par le serveur de manière unique. Ainsi dans le cas de la messagerie web, si machin se connecte, il ouvre une session : quand il parcourt les pages suivantes, il est reconnu comme étant machin, et le serveur peut lui afficher les messages qui lui sont associés, ses paramètres, bref ses données en général.
D'une manière générale, tous les sites qui demandent une identification au démarrage doivent gérer la notion de session. Or le HTTP ne la gère pas. Il faut donc ajouter un truc au HTTP. Ce truc, c'est le cookie.

Le principe est le suivant : les données de session (typiquement, le login et le mot de passe) sont stockées quelque part sur le serveur, et sont repérées par un identifiant unique. Cet identifiant est codé dans le cookie. Lequel cookie est renvoyé avec la page qui suit celle d'identification. Jusqu'à ce moment là, le cookie n'est qu'un bout de code dans le flux HTTP de retour. Lorsqu'il reçoit le cookie, le navigateur le stocke sur disque. Et c'est tout.
Ensuite, à chaque demande de page par la suite (avec une commande GET, donc), le navigateur enverra en plus le continu du cookie vers le serveur. Oh miracle ! Le contenu du cookie est l'identifiant unique, associé à l'utilisateur. On peut donc le reconnaître, et donc afficher les données qui lui sont associées ; dans le cas de la messagerie web, c'est la liste de ses messages, par exemple.
Ainsi, bien démystifié, le cookie apparaît pour ce qu'il est tout banalement dans 95% des cas : un simple outil technique pour assurer une session.

Mais va-t'on me demander : un cookie est-il bien nécessaire pour identifier l'utilisateur ? Son adresse IP n'est-elle pas suffisante ? Non, et ce pour au moins 2 raisons :

1. D'abord la majorité des utilisateurs passent par le RTC (téléphone) et donc ont des adresses IP dynamiques. La session pouvant être maintenue entre deux appels téléphoniques, les adresses IP peuvent changer, et tout est perdu. Une déconnexion au niveau de la session n'est pas la même chose qu'une déconnexion téléphonique, ne confondons pas !
2. Ensuite les gens qui se connectent depuis leur boulot sont souvent derrière des proxy et du point de vue du serveur ont tous la même adresse IP (du moins ceux qui bossent au même endroit).

Il y a donc nécessité de véhiculer entre le serveur et le navigateur, l'identifiant unique de la session.
Il est vrai que l'on n'est pas obligé d'utiliser la technique du cookie pour faire cela. On pourrait au moins soit passer cet identifiant par codage d'URL, soit le passer dans un champ caché de chaque page. Je ne vais pas rentrer dans le détail, mais disons que ces techniques sont assez contraignantes, et laborieuses. Elles présentent aussi des inconvénients au niveau de la sécurité.
Car il ne faut pas oublier une chose : les programmes sont écrits par des programmeurs, c.a.d, majoritairement des gens paresseux et pas toujours très bons techniquement [2]. Ils n'ont pas envie de se casser la tête, d'autant que les langages de programmation et/ou les outils pour développer des sites web gèrent la session par cookie de manière complètement transparente.
Ceci explique la profusion de cookies, et pourquoi certains sites ne fonctionnent carrément pas si vous choisissez de refuser les cookies sur votre navigateur.
Vous voyez donc qu'il n'y a pas vraiment pas de quoi en faire un fromage.
La police de la pensée, elle ne passera donc pas par-là.

{1] Ce qui suit est evidemment un modèle plutôt simplifié de la réalité. Le présent article se vise qu'à une vulgarisation bon enfant.
[2] Ce qui explique les failles de sécurité dont certains sites font leur fond de commerce. Il ne s'agit pas d'un complot, mais d'un manque de professionnalisme et/ou de talent, un peu comme lorsque le garagiste oublie de changer les plaquettes de frein lors d'une révision générale.