Un site Web de 1000 ans
Le grenier d’une grand-mère, la boîte à chaussures pleine de photos dans un placard ou tout simplement les étagères de nos bibliothèques : nous collectionnons de très nombreux objets physiques. Ces porteurs d’informations sont des éléments de notre mémoire personnelle et collective. Ils nous aident à créer du lien affectif, à transmettre des émotions mais aussi de la connaissance. La gestion de la mémoire (ou l’archivage) prend lieu à tous les niveaux structurels, du souvenir d’enfance à l’information d’une multinationale.
Organisation de l’information dans le monde physique
Nous avons appris dans le monde physique à gérer cette information par la création de stratégies adaptées à notre environnement. Une boîte à chaussures, une étagère, un entrepôt, autant de structures physiques permettant de stocker. À ces structures, nous avons associé des systèmes d’identification. Pour les vieilles photographies de l’arrière grand-mère, il s’agit de la boîte en métal rangée sur la première étagère du placard à droite (identificateur unique). Pour une bibliothèque, on utilise un système de numération, comme un numéro ISBN associé à une position physique dans un bâtiment. Il existe également des structures de stockage temporaires telles que la boîte aux lettres, l’espace où le facteur dépose nos courriers. Nous connaissons la fonction de cet objet, qui possède également un identificateur unique, mais dont le contenu change tous les jours.
La refonte du site Web, cette catastrophe périodique
Au cours de la vie d’un site Web, il est régulier d’entendre le mot « refonte » dans les équipes ou l’agence Web qui doivent gérer le site. Les raisons évoquées sont le changement de design, la réorganisation structurelle de l’entreprise, les contenus « obsolètes », le changement de plate-forme technique, les enjeux de performance. Le résultat est souvent catastrophique pour le long terme. L’information précédente est détruite. La pratique ressemble beaucoup à celle de la terre brûlée qui, en effet, donne un coup de fouet aux champs, mais a aussi pour conséquence de détruire de nombreux éléments vitaux pour l’équilibre de l’écosystème.
L’information nouvelle sera de nouveau obsolète d’ici quelques mois, quelques années. Le problème n’a pas été résolu. Une couche de peinture a été rajoutée sur l’ancienne un peu vieillie et passée de mode. Il doit être possible de mieux gérer l’information et d’éviter une refonte catastrophique.
Nous devons apprendre à créer des sites dont l’information devient obsolète.
Une information dont la valeur est à venir
Toutes les informations dans notre quotidien ont une valeur qui dépend de son utilisation. Il y a cependant un schéma relativement constant dans la valeur qu’une information peut avoir au cours du temps :
- brouillon et accessible à un lectorat restreint
- fraîche et avec un accès plus important
- obsolète, périmée
- historique, émotionnelle
Gérer la mémoire d’un site Web, c’est établir une stratégie en utilisant les outils du Web permettant de passer par les différents étapes de la vie d’une information.
Les URI, un système d’identifiants pérennes
Sur le Web, le système qui permet d’identifier les « objets » uniques (ou pièces d’information) est défini par l’URI. Il s’agit en quelque sorte d’une étiquette précise éliminant toute ambiguïté. Lorsque vient le moment de choisir des identificateurs (URI), les concepteurs de sites Web vont souvent penser aux axes suivants :
- indexation par les moteurs de recherche ;
- lisibilité par les humains ;
- hiérarchie de la structure d’information.
Malheureusement, il est très rarement question de la pérennité de cet identifiant. Par exemple, sur le site 24 jours de web, l’URI de chaque article contient un élément pour rendre l’adresse unique : 2012
.
http://www.24joursdeweb.fr/2012/un-portfolio-nomme-desir/
Il est à noter que cela pourrait être Gf69Tzx
. Cependant, les dates sont un système pratique pour rendre unique un identifiant. L’heure unique, qui est un système circulaire, n’est pas un bon système. Si en 2042, une personne veut écrire un nouveau 24 jours de Web avec l’identifiant un-portfolio-nomme-desir
, il suffit d’utiliser :
http://www.24joursdeweb.fr/2042/un-portfolio-nomme-desir/
Les questions à se poser quand vous définissez l’architecture d’information d’un site en Web, en plus de celles listées précédemment :
- Qu’est-ce que cet URI identifie ?
- Est-ce que l’information à cet URI sera régulièrement mise à jour ?
- Est-ce que l’URI sera accessible dans 50 ans ou plus ?
- Quel est le couplage entre l’information et l’URI ?
Une fois que ces questions sont bien posées, il devient beaucoup plus facile de réaliser une refonte du site Web sans détruire l’information. Nous aurons commencé à gérer la mémoire du site Web.
HTTP, la gestion de la mémoire
Sur le Web, la boîte à outils qui nous permet de gérer l’information est le protocole HTTP. Nous sommes très familiers avec l’accès à l’information en utilisant HTTP GET
. Si nous envoyons une requête vers le serveur Web pour la page d’accueil de 24 jours de Web :
GET / HTTP/1.1
Host: www.24joursdeweb.fr
Le serveur répond
HTTP/1.1 200 OK
Set-Cookie: mailplan=R3631203178; path=/; expires=Wed, 05-Dec-2012 14:15:40 GMT
Date: Fri, 30 Nov 2012 02:12:56 GMT
Server: Apache/2.2.X (OVH)
X-Powered-By: PHP/5.3.16
X-Pingback: http://www.24joursdeweb.fr/xmlrpc.php
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1247
Content-Type: text/html; charset=UTF-8
[… reste du contenu coupé …]
HTTP propose cependant beaucoup d’outils en plus de ce simple accès à l’information. Il permet aux architectes d’informations et aux personnes en charge de l’expérience utilisateur (UX) de définir une meilleure gestion de l’information sur le long terme (en coopération avec les développeurs Web).
Les redirections permanentes
Une fois les URI pérennes choisis, il est fort possible que nous ayons besoin de rediriger vers un nouvel identifiant. Dans le cas d’une refonte et d’un site mal conçu auparavant, mais également parce que nous réalisons que nous avions commis une erreur dans la création du précédent URI, comme un couplage trop fort entre l’URI et son contenu.
Une entreprise, Casimir, est acquise par l’entreprise Gloubiboulga. L’organigramme de Casimir n’est plus pertinent dans le cadre de cette acquisition et les gestionnaires du site Web doivent maintenant rediriger vers l’organigramme du site de Gloubiboulga. HTTP utilise le code 308
. Une requête de client du type
GET /organigramme HTTP/1.1
Host: casimir.example.com
permettra au serveur de répondre
HTTP/1.1 308 Moved Permanently
Location: http://gloubiboulga.example.net/organigramme
Le serveur envoie un message clair signifiant clairement aux clients (navigateurs, moteurs de recherche, etc.) que l’adresse a changé de façon permanente. Si le gestionnaire de signets est intelligent, il peut également mettre à jour les signets automatiquement ou après avoir demandé à l’utilisateur.
Ce n’est pas le seul choix possible. Tout le talent des équipes de conception du site Web consiste à déterminer ce qui sera pertinent pour la gestion de la mémoire du site. Par exemple, il est tout à fait possible d’envisager que toute l’histoire de la société Casimir doit être conservée sur le long terme et plutôt que de rediriger vers
http://gloubiboulga.example.net/organigramme
on choisira de rediriger vers
http://gloubiboulga.example.net/2012/casimir/organigramme
Il s’agit là de choix d’interactions.
Les redirections temporaires
Un autre outil très pratique de la boîte à outils HTTP est la redirection temporaire. Il s’agit en effet de définir un identifiant générique, mais dont le contenu change assez régulièrement. Imaginons qu’un restaurant affiche un menu du midi différent en fonction du marché du matin. Les clients réguliers du restaurant veulent savoir ce qu’il y a de disponible ce midi. Il est plus pratique pour eux de connaître l’adresse du menu du jour ou de la mettre dans leurs signets.
http://resto.example.net/menu-jour
Cela se traduit en requête dans le navigateur :
GET /menu-jour HTTP/1.1
Host: resto.example.net
Le serveur pourrait être alors paramétré de façon à répondre avec le menu du jour en envoyant une redirection temporaire avec le code 307.
HTTP/1.1 307 Temporary Redirect
Location: http://resto.example.net/2012/11/30/menu
Le client se retrouve automatiquement dirigé vers la page du menu du jour. Il y a un identifiant unique permettant de garder un historique de tous les menus successifs. Nous pouvons imaginer que cette page collecte également les commentaires des clients sur ce menu spécifique, les photos prises ou les messages échangés sur les réseaux sociaux. Pour les moteurs de recherche et les gestionnaires de signets, il s’agit d’une redirection temporaire, les deux URI sont donc bien différents et ont leur existence propre.
Un autre cas de figure est celui d’une page d’incident temporaire. La page habituelle d’information est redirigée automatiquement mais de façon temporaire vers une page de notifications d’un incident.
La destruction du contenu
Il existe d’autres cas de figure où il est parfois nécessaire d’indiquer qu’une information a été détruite et donc que l’identifiant en question n’est plus pertinent et sera sûrement amené à disparaître entièrement dans le futur. Isabelle Toulemonde avait un compte sur un réseau social et décide de fermer son profil définitivement. Une requête avec le client vers la page de profil donnera par exemple
GET /isabelle-toulemonde HTTP/1.1
Host: scoobidoo.example.org
et la réponse du serveur pourra être
HTTP/1.1 410 Gone
[… information possible …]
Il est à noter qu’il est possible d’envoyer un message dans le corps de la réponse afin d’expliquer la raison. Par exemple, que l’utilisateur a volontairement effacé son compte, que le contenu qui était disponible était illégal, etc. Le code 410
informe un navigateur que cet URI devrait être oublié et qu’il n’est pas nécessaire de revenir indexer la page. Un gestionnaire de signets intelligent pourrait détecter que l’utilisateur a ce signet dans sa liste et proposer de l’effacer. Une fois de plus, il n’y a pas de choix unique mais une discussion à avoir sur la pertinence de l’information et de sa gestion sur le long terme.
Les avantages de la gestion de la mémoire d’un site Web
Nous avons vu qu’il était important de
- Créer des URI en prenant en compte leur pertinence sur le long terme.
- Utiliser HTTP afin de gérer l’évolution de ses URI.
Cette gestion de la mémoire d’un site Web offre quelques avantages tels que :
- l’augmentation de la confiance des utilisateurs pour la structure gérant ce site Web. Il est toujours agréable pour un utilisateur qui a l’habitude d’un URI de pouvoir retrouver l’information pertinente ;
- l’augmentation de la position dans les moteurs de recherche. Un URI pérenne permet aux personnes de lier la page Web à partir d’autres sites Web sans soucis et ainsi, petit à petit, d’améliorer le faisceau de liens à travers le Web ;
- les signets des utilisateurs de navigateur, de même, restent pérennes ;
- l’enrichissement de l’information sur le long terme. Une information, après sa période d’actualité, devient historique.
En gérant mieux les URI, nous améliorons en même temps l’expérience utilisateur et la réputation du site Web.
8 commentaires sur cet article
Nico, le 13 décembre 2012 à 8:56
À noter, même si je suis le premier à vanter les mérites des redirections permanentes (pour d'évidentes raisons de qualité et leur côté pratique pour l'utilisateur lors de refontes), il faut vraiment utiliser cette possibilité avec précaution : ces dernières sont parfois utilisées avec la finesse d'un bazooka, et elles peuvent poser de nombreux problèmes quand elles sont utilisées à tort et à travers.
Par exemple, vu qu'elles sont mises en cache (normal, c'est permanent, donc pas la peine d'y revenir), les "annuler" devient vite problématique si le stagiaire ou le développeur imprudents les ont utilisées à la place des redirections temporaires.
Donc attention avant de foncer tête baissée, il faut vraiment se poser la question de la pertinence de leur utilisation et voir plus loin que "bon, je fais ça à la rache, on s'en fout, on verra après" (sans forcément penser au millénaire ;) ).
tzi, le 13 décembre 2012 à 14:11
Super article. Un point de vue rarement abordé et que je trouve très intéressant. Merci :)
noclat, le 13 décembre 2012 à 15:02
Trop peu souvent abordé, trop souvent négligé ou même méconnu, moi le premier. Merci beaucoup pour cet article ;).
STPo, le 14 décembre 2012 à 22:35
Je comprends mieux tes réactions à l'article de Marie... Je te rejoins sur beaucoup de choses ici (uri pérennes, etc.). Ça n'empêche pas les refontes, le tout est de bien les faire en conservant une certaine cohérence d'une version à l'autre !
Simounet, le 23 décembre 2012 à 23:56
Il est vrai que le nombre de personnes optant pour une vision à long terme de leurs publications sur le web est relativement restreint. Y penser et définir une stratégie en est pourtant une phase essentielle. Merci pour cette piqure de rappel.
Frank Taillandier, le 29 décembre 2012 à 16:35
@Karl : Si le système a du sens pour ton blog personnel, penses-tu vraiment que ça soit nécessaire pour tous les contenus produits de plus en plus nombreux et dont 90% sont de mauvaise qualité. Je recommande chaudement l'intervention de Brad Frost sur le sujet intitulé Death to Bullshit (https://vimeo.com/56164296).
Enfin le versioning, n'a t-il pas aussi son rôle à jouer à ce niveau pour des sites comme Wikipédia ?
karl, le 29 décembre 2012 à 17:07
@Frank
On ne peut pas et on ne doit pas tout conserver de l'information que nous produisons. Cependant la qualité de l'information est orthogonale à mon propos sur la bonne gestion de l'information. Ce que je déplore c'est de voir de nombreux sites dont l'information devrait être maintenue (exemple des sites gouvernementaux) et qui sont en piteux état.
À noter qu'il est très difficile de définir la qualité d'une information sur le long terme. Les historiens, sociologues par exemple peuvent se nourrir des publicité idiote des magazines du passé pour faire une analyse de la société et de son évolution.
Quant au versioning, il s'agit d'un autre enjeu avec des points de rencontre sur la courbe du temps. Note que le versioning tel que fait par Wikipedia est justement une gestion des URIs en créant des URI différents pour chaque version. Que l'URI soit une des interfaces d'accès à différentes versions, bien sûr. C'est ce que l'article explique justement.
Shonagon, le 4 décembre 2015 à 15:05
Un petit rebond malheureusement bien triste à propos de la refonte d'un site de musée : http://zone47.com/dozo/lettre-au-musee-sigma-a-propos-de-la-refonte-de-son-site-web
Il n’est plus possible de laisser un commentaire sur les articles mais la discussion continue sur les réseaux sociaux :