En ce moment, je lis énormément de choses sur la “révolution du HTML5″ et la façon dont le HTML4 est supplanté par cette nouvelle itération pensée pour les applications en ligne. Je ne sais pas trop d’où sort cet adage que l’HTML5 est LE langage des applications en ligne, toujours est-il que je ressens comme une ambigüité persistante à ce niveau.

Pour schématiser, un site est un ensemble de pages qui forme un tout cohérent (comme un magazine). Une application est un outil offrant de fonctionnalités. Selon cette définition, dire que HTML5 est le langage des applications en ligne et qu’à l’avenir tout sera application est un non-sens.  Je vois plutôt HTML comme un langage versatile permettant de faire tout un tas de choses, plutôt que de réduire ça à la notion d’application. Pour mémoire, le W3C a essayé pendant des années d’imposer XHTML2 et de faire accepter l’idée que toutes les pages sont des applications, nous savons tous comment cela s’est terminé. Pour être certain qu’il n’y ai pas d’ambigüité, je précise que HTML5 n’est pas remplaçant de XHTML2.

Mais revenons à nos moutons : les applications en ligne sont donc des outils offrant des fonctionnalités aux internautes. Dans la cadre d’une application de gestion de projet ou d’édition de document, tout est limpide. Mais si cette fameuse fonctionnalité est d’afficher du contenu, tout se complique. Pourquoi donc un éditeur de sites voudrait utiliser une application pour afficher du contenu ? Tout simplement pour améliorer l’expérience utilisateur. Deux des sites les plus populaires au monde sont ainsi des applications en ligne permettant d’accéder à des contenus : Facebook et Twitter.

En fait, tout a commencé avec Gmail qui a été le premier site avec une très large audience à utiliser Ajax pour faire des rafraichissements silencieux des pages. Cette technologie n’est plus toute jeune (elle existait déjà au siècle dernier), mais très peu de sites l’utilisent dans le cadre de contenus textuels. Cette réflexion est initialement venue d’une discussion très intéressante que j’ai eue avec Alexandre Malsch, le fondateur de Melty.fr. Pour celles et ceux qui ne connaissent pas, il s’agit d’un des portails les plus populaires auprès des jeunes.

Si vous visiter Melty.fr, vous aurez une expérience de visite assez similaire à n’importe quel portail, pourtant  lorsque que vous arriverez sur le site pour la première fois, c’est le moteur d’affichage qui sera téléchargé en premier, car c’est lui qui gère l’affichage des contenus ainsi que les interactions. Ce moteur, développé en javascript, se positionne ainsi entre le navigateur et l’utilisateur et va intercepter les clics et défilements de la souris pour les interpréter à sa façon et proposer une navigation avec des rafraichissements silencieux qui évitent de recharger à chaque clic des éléments qui ne changent pas.

Les bénéfices de ce moteur d’affichage sont les suivants :

• des temps de chargement plus courts ;
• plus de faciliter dans les fonctions de partage ;
• un meilleur contrôle de l’expérience de lecture ;
• une analyse beaucoup plus fine des parcours et interactions des utilisateurs.

Dans l’absolu, maintenant qu’ils disposent d’une application de lecture pour les ordinateurs, ils peuvent proposer une expérience de lecture très cohérente sur les autres terminaux en proposant des moteurs optimisés pour les tablettes, les smartphones, les TV connectées… Une hypothèse tout à fait intéressante au vu du phénomène de fragmentation des terminaux mobiles, et surtout une réponse tout à fait viable aux problèmes de connexion et de stockage des contenus hors-ligne.

Les premiers utilisateurs de PDAs seraient alors tentés de me faire remarquer que ce n’est ni plus ni moins qu’une reformulation des lecteurs de news du siècle dernier comme AvantGo. Certes, il y a un peu de ça, mais je préfère plutôt saluer la volonté des équipes de Melty de proposer une expérience de lecture maitrisée de bout en bout sans avoir à se reposer sur des applications comme Instapaper ou Pocket.

Je vous rassure : moi aussi j’ai été très perturbé à l’idée d’utiliser un moteur d’affichage pour remplacer celui du navigateur, car c’est toute ça raison d’être ! Toujours est-il que ce site apporte des solutions là où d’autres sont dans une impasse (expérience de lecture maitrisée quel que soit le terminal, gestion des contenus hors ligne, analyse détaillée…). Je serais bien incapable de vous dire si au final cette solution est mieux que de se reposer sur le moteur de rendu natif des navigateurs, car “mieux” est une notion subjective. La discussion reste donc entièrement ouverte…