Le contrôle des redirections

Si les redirections ^[1] sont à peu prêt aussi vieilles que le web, elles n’étaient, jusqu’à l’apparition des micro-blogs, que rarement utilisées, mises en place par les connaisseurs, lors du déménagement d’un document important.

Dans ce contexte, quand Kevin Gilbertson proposa en 2002 le premier service en-ligne de rétrécissement d’URL (TinyURL.com), permettant de créer à la demande, une redirection depuis une une adresse courte vers l’adresse de son choix, il n’eut qu’un succès modéré. L’initiative tomba presque dans l’oubli, et ce n’est qu’une demi-décennie plus tard, avec l’essor de Twitter que ce service rencontra d’un coup un large public. En effet, le principe de Twitter étant de proposer un blog dont les billets sont plus courts que des SMS, pouvoir réduire une URL devint un enjeu de taille, si j’ose dire. En effet, d’une part certaines URL sont simplement trop longues pour être gazouillées, et d’autre part, une fois l’adresse collée dans un micro-billet il ne reste plus beaucoup de place pour en expliquer l’intérêt.

TinyURL.com fut donc dans un premier temps directement proposé depuis l’interface du site de microblogage pour aider à la rédaction des messages. Puis devant le succès rencontré par cet intermédiaire, de nombreux concurrents vinrent occuper leurs parts de marché, tel que Bit.ly, qui se démarqua par les statistiques offertes sur l’utilisation des liens courts qu’il produit.

Et progressivement, chaque gros acteur du web se mit à proposer son propre service de rétrécissement, pour faire plaisir à ses utilisateurs avec un service techniquement trivial, ne pas dépendre d’un tiers et enfin pour mettre la main, chacun, sur sa parcelle de statistiques d’usage !

Car utiliser un raccourcisseur d’URL revient en fait à ajouter une barrière de péage d’autoroute entre les personnes auxquelles vous communiquez le lien court, et le document que vous souhaitiez porter à leur attention. Bien sûr, c’est une barrière pour laquelle tout le monde est abonné (pour l’instant), et elle ne fait que ralentir un peu le trafic, mais surtout, elle identifie au passage qui l’a franchi, quand et combien de fois.

Or, si cette information était jusque là collectée par l’émetteur du document de destination seulement, elle n’était pas aussi facilement recoupable et monnayable que si c’est un acteur central qui collecte toutes les visites effectuées suivant les recommandations des millions d’utilisateurs de Twitter, de Facebook ou de Google…

Et puis, d’un point de vue pragmatique, au-delà de la seconde d’attente ajoutée après le clic, ou du respect de la vie privée, un autre problème se pose, celui de la pérennité de ces étapes intermédiaires. Aujourd’hui, TinyURL.com se vante de servir des milliards de redirections par mois, mais ce service, qui n’est pas géré par une entreprise, est voué à disparaître, car son nom (qui avait besoin d’être explicite au début) est trop long pour être efficace aujourd’hui. Or, quand les serveurs de TinyURL seront éteints, c’est plus d’un milliard d’adresses qui, d’un coup, ne mèneront plus à rien.

Alors, quand on voit avec quel empressement les entreprises se sont mises à proposer ce gadget en apparence anodin, on peut avoir envie de ne pas se laisser enfermer nous non plus par une compagnie particulière, de suivre cet exemple en s’installant chacun son raccourcisseur d’URL à soi. Après tout, ça ne sera qu’une corde de plus à mettre à l’arc de la NoBox.

Toutefois, la question de la pérennité des redirections mises en place reste posée… En ce premier novembre, il est presque de bon ton de se demander ce qu’on fera du serveur personnel d’un défunt.

Mais pour l’heure, place au détail de l’enfer des redirections vers lequel on nous mène, et qui transforme progressivement le web en maison qui rend fou des 12 travaux d’Astérix… ^[2]

Le web se dirige-t-il vers un cauchemar de redirections ?

Is the Web heading toward redirect Hell?

22 septembre 2010 – Royal.Pingdom.com
(Traduction Framalang : Zitor, Barbidule, Daria, Goofy, Siltaar)

Google le fait. Facebook le fait. Yahoo le fait. Microsoft le fait. Et bientôt, Twitter le fera.

Nous parlons de la manie qu’ont tous les services web d’ajouter une étape intermédiaire pour échantillonner ce sur quoi nous cliquons avant de nous envoyer vers notre vraie destination. Ça dure déjà depuis un certain temps, et c’est progressivement en train de devenir un enfer de redirections. Cela a un coût.

Du trafic déjà en trop

Il y a déjà beaucoup de redirections en place, auxquelles vous ne songez pas forcément. Par exemple :

• Chaque fois que vous cliquez sur un résultat de recherche dans Google ou Bing, il y a un passage obligé par les serveurs du moteur de recherche pour analyse avant d’être redirigé vers le site réellement ciblé;
• Chaque fois que vous cliquez sur un titre dans un flux RSS Feedburner, vous êtes aussi redirigé avant d’arriver à la véritable cible;
• Chaque fois que vous cliquez sur un lien sortant de Facebook, il y a une étape intermédiaire passant par un serveur de Facebook avant de vous rediriger vers où vous voulez aller.

Et ainsi de suite, et ainsi de suite, et ainsi de suite. C’est, bien sûr, parce que Google, Facebook et les autres sociétés en ligne aiment suivre les clics et le comportement de leurs utilisateurs. Vous connaître est une vraie ressource pour ces sociétés. Cela peut les aider à améliorer leur service, à le monétiser plus efficacement et dans de nombreux cas, ces données elles-mêmes valent de l’argent. Au final ce suivi de clic peut aussi être bon pour les utilisateurs finaux, en particulier s’il permet à un service d’améliorer sa qualité.

Mais…

Les choses sont en train de déraper

S’il ne s’agissait que d’une seule étape supplémentaire, cela pourrait aller. Mais si vous regardez autour, vous vous rendrez compte que ces redirections sont en train de s’empiler, chaque service interceptant des informations sur le clic lors du cheminement vers la destination finale. Vous savez, celle que l’utilisateur a vraiment demandée.

Cela peut vite devenir incontrôlable. Nous avons vu des scénarios où les liens sortants de Facebook, par exemple, vous redirigent d’abord vers un serveur Facebook, puis vers un racourcisseur d’URL (par exemple bit.ly), qui à son tour vous redirige vers une URL plus longue qui elle-même génère plusieurs redirections avant que FINALEMENT vous parveniez à la cible. Il n’est pas rare qu’il y ait plus de trois redirections vers différents sites qui, du point de vue de l’utilisateur, sont du trafic superflu.

Le problème, c’est que ce trafic supplémentaire n’est pas gratuit. Cela rallonge le temps nécessaire pour atteindre l’objectif, et cela rajoute d’autres liens (au sens propre !) dans la chaîne, ce qui peut la briser ou la ralentir. Cela peut même faire apparaitre des sites comme indisponibles alors qu’ils ne le sont pas, simplement parce que quelque chose sur le chemin est tombé en panne.

Et il semble que cette pratique soit de plus en plus répandue sur le Web.

Un exemple récent de cette « mode de la redirection » : Twitter

Vous souvenez-vous de cette vague de raccourcisseurs d’URL qui est venue quand Twitter a commencé à devenir populaire? C’est là que commence notre histoire.

Twitter a d’abord utilisé le déjà établi TinyURL.com comme raccourcisseur d’URL par défaut. C’était un partenaire idéal pour Twitter et sa limite de 140 caractères par message.

Puis vinrent Bit.ly et une pléthore d’autres raccourcisseurs d’URL, qui voulaient eux aussi surfer sur le succès grandissant de Twitter. Bit.ly a rapidement réussi à remplacer TinyURL comme réducteur d’URL par défaut pour Twitter. Grâce à cela, Bit.ly a mis la main sur une foule de données : la liste d’une bonne partie des liens postés sur Twitter, et de leur popularité, chaque clic pouvant être tracé.

Ce n’était qu’une question de temps avant que Twitter ne veuille garder ces données pour lui seul. Pourquoi s’en priverait-il ? Cela lui permet d’avoir le contrôle total de l’infrastructure nécessaire à son fonctionnement, tout en récupérant des informations sur ce que les utilisateurs aiment s’échanger, et ainsi de suite. Twitter a donc créé récemment son propre raccourcisseur d’URL, t.co. Dans le cas de Twitter, cela peut parfaitement se comprendre.

Cela est bel et bon, mais voici maintenant la partie la plus intéressante qui est la plus pertinente pour cet article : d’ici la fin de l’année, Twitter va rediriger TOUS les liens vers son raccourcisseur d’URL, y compris les liens déjà raccourcis par d’autres services comme Bit.ly ou Goo.gl, le raccourcisseur de Google. En canalisant tous les clics vers ses propres serveurs, Twitter va acquérir une connaissance précise de la façon dont son service est utilisé, et de ses utilisateurs. Cela lui donne le contrôle total sur la qualité de son service. C’est une bonne chose pour Twitter.

Mais qu’arrive-t-il quand tout le monde veut un morceau du gâteau ? Redirection après redirection après redirection avant d’arriver à notre destination ? Oui, c’est exactement ce qui se passe, et vous aurez à vivre avec ce trafic supplémentaire.

Voici ce à quoi le partage de liens pourrait ressembler une fois que Twitter aura commencé à soumettre tous les clics à son propre service :

1. Quelqu’un partage un lien goo.gl sur Twitter, il est alors transformé en un lien t.co.
2. En cliquant sur le lien t.co, l’utilisateur est alors redirigé vers les serveurs de Twitter pour convertir le lien t.co en lien goo.gl et se voit réorienté dessus.
3. Le lien goo.gl dirige l’utilisateur vers les serveurs de Google pour y être résolu et ré-orienter enfin l’utilisateur vers la cible qu’il souhaitais atteindre.
4. Rien n’empêche cette cible de n’être à son tour qu’une nouvelle redirection…

Vous en avez la tête qui tourne, hein ?

Encore plus de niveaux de redirection ?

Il y a un an, nous avons écrit un article sur les inconvénients potentiels des raccourcisseurs d’URL, et il s’applique parfaitement à ce scénario plus général avec de multiples redirections entre les sites. Les conséquences de ces redirections sur les performances, la sécurité et la confidentialité sont les mêmes.

Nous soupçonnons fortement que le chemin pris par Twitter (échantillonner et enregistrer les clics avant expédition vers la cible, avec ou sans raccourcisseurs d’URL) laisse présager des pratiques à venir chez les autres services Web qui ne le font pas déjà.

Et même quand les services principaux ne le font pas, de plus en plus d’intermédiaires et d’applications tierces, comme les raccourcisseurs d’URL, apparaissent tous les jours. L’autre jour, le fabricant d’antivirus McAfee a annoncé la version-bêta de McAf.ee, un raccourcisseur d’URL « sécurisé ». C’est peut-être super, qui sait, mais à la lumière de ce que nous vous avons dit dans cet article, il est difficile de ne pas penser : quoi, encore une autre niveau de redirection ? Est-ce vraiment vers cela que le Web évolue ? Est-ce vraiment ce que nous voulons ?