Mon blog

Un certain nombre de sites Web (pas tous, heureusement) redirigent les clients qui semblent être des appareils mobiles vers un autre URL, spécifique aux mobiles. C'est une très mauvaise idée.

En général, la redirection se fait dès que le serveur Web croit, à tort ou à raison, qu'il voit passer un appareil mobile, par exemple un phono sapiens. On peut le voir avec wget, en faisant varier le champ HTTP User-Agent: (RFC 7231, section 5.5.3) :

% wget --user-agent="Mozilla/5.0 (Android; Mobile; rv:37.0) Gecko/37.0 Firefox/37.0" http://fr.wikipedia.org/wiki/Virgule_d%27exclamation 
--2015-04-27 17:29:04--  http://fr.wikipedia.org/wiki/Virgule_d%27exclamation
Resolving fr.wikipedia.org (fr.wikipedia.org)... 91.198.174.192, 2620:0:862:ed1a::1
Connecting to fr.wikipedia.org (fr.wikipedia.org)|91.198.174.192|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://fr.m.wikipedia.org/wiki/Virgule_d%27exclamation [following]
--2015-04-27 17:29:04--  http://fr.m.wikipedia.org/wiki/Virgule_d%27exclamation
Resolving fr.m.wikipedia.org (fr.m.wikipedia.org)... 91.198.174.204, 2620:0:862:ed1a::1:c
Connecting to fr.m.wikipedia.org (fr.m.wikipedia.org)|91.198.174.204|:80... connected.
HTTP request sent, awaiting response... 200 OK
...

On a été redirigé (code de réponse 302, RFC 7231, section 6.4) depuis le bon URL http://fr.wikipedia.org/wiki/Virgule_d%27exclamation vers http://fr.m.wikipedia.org/wiki/Virgule_d%27exclamation (le composant m dans le nom de domaine indiquant une version pour mobile). Avec un User-Agent: qui n'indiquait pas un mobile, on n'était pas redirigé :

% wget --user-agent="Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0" http://fr.wikipedia.org/wiki/Virgule_d%27exclamation
--2015-04-27 17:28:31--  http://fr.wikipedia.org/wiki/Virgule_d%27exclamation
Resolving fr.wikipedia.org (fr.wikipedia.org)... 91.198.174.192, 2620:0:862:ed1a::1
Connecting to fr.wikipedia.org (fr.wikipedia.org)|91.198.174.192|:80... connected.
HTTP request sent, awaiting response... 200 OK
...

On trouve de telles redirections dans Wikipédia mais aussi les Échos, Rue89, etc.

Ces URL sont utilisés pour transmettre un contenu différent selon les clients. Les problèmes que posent ces URL spécifiques aux mobiles sont les suivants :

• Ils violent un principe de base du Web, qui est que l'URL est la même pour tout le monde, afin qu'on puisse la transmettre, la passer à quelqu'un d'autre, et que l'affichage suive automatiquement. Le Web a été conçu pour cela. Il n'y a aucune bonne raison technique de faire du contenu spécifique pour mobile.
• Il n'y a pas un seul type de « mobile » mais des tas de modèles, avec notamment des tailles d'écran très différentes. Même si on pense qu'il faut des contenus différents selon les machines, ces URL spécifiques ne dispensent donc pas le webmestre d'adapter le contenu à chaque écran.
• Ces URL empêchent d'utiliser une des fonctions de base du Web, passer un URL d'un utilisateur à l'autre (par XMPP, courrier, Twitter, etc). En effet, si je consulte un site sur un smartphone, que je l'envoie en XMPP et que le destinataire est sur un ordinateur de bureau, il verra une version inadaptée. (Rue89 redirige depuis le site mobile vers le site « immobile », mais Wikipédia ne le fait pas.)
• Si on stocke les URL dans une base de données, à des fins de documentation ou de constitution d'une base de connaissances, on aura des doublons puisque le système croira qu'il s'agit de deux ressources différentes. Ainsi, SeenThis affiche un joli petit triangle noir devant chaque URL qui a déjà été cité mais il ne peut plus le faire si on utilise l'URL « mobile » et l'URL « normal » pour la même ressource.
• La redirection nécessite une nouvelle connexion TCP et une nouvelle requête, donc augmente la latence, alors que les mobiles ont justement souvent la plus mauvaise connexion.

Est-ce qu'au moins on peut corriger à la main l'URL qu'on voulait partager ou enregister ? Chez Wikipédia, c'est relativement facile, le schéma est évident. On retire juste le composant m du nom de domaine, et http://fr.m.wikipedia.org/wiki/Potamoch%C3%A8re redevient http://fr.wikipedia.org/wiki/Potamoch%C3%A8re. Par contre, Rue89 utilise des URL radicalement différents (http://m.rue89.nouvelobs.com/node/257496 est http://rue89.nouvelobs.com/2015/04/23/deconnectes-mal-connectes-les-pauvres-numerique-257496, excellent article, au passage) et empêche donc cette réécriture.

Terminons par un argument d'autorité avec deux excellents textes du W3C contre cette idée d'URL spécifiques aux mobiles. Ces deux articles ont été écrits dans le contexte du TLD .mobi (un échec complet et mérité) : « The ".mobi" Proposal is Inconsistent with Device Independence Principles » et « New Top Level Domains .mobi and .xxx Considered Harmful » (qui couvre en outre bien d'autres sujets et est donc plus difficile à utiliser pour ce problème des URL pour mobiles).

Et si vous voulez un point de vue différent sur ce sujet, il y a cette réflexion.