LarévolutionHTML5
HTML5 est le nouveau mot à la mode, et d’innombrables articles et publications traitent du sujet : On y parle beaucoup de drag’n drop (glisser-déposer), de 3D, de nouvelles possibilités en termes de mise en page, de formulaires, de graphisme, de typographie,...
Cependant cette vision du potentiel d’HTML5 est très réductrice. Ce standard ouvre en effet un univers entier de nouvelles possibilités, qui vont révolutionner la manière dont nous concevons et utilisons les logiciels. Et ce d’autant plus qu’avec le Web 2.0, le Cloud Computing (Informatique dans le Nuage), SaaS et PaaS... le web est devenu la plateforme applicative dominante.

Les acteurs derrière HTML5
HTML5 est la dernière évolution de l’HTML, le principal langage du web. C’est un standard ouvert, c'est-à-dire interopérable et dont les spécifications techniques sont publiques et sans restriction d’accès ou de mise en œuvre. Avec HTML5, la nature du standard et son mode de création ont changé : c’est dorénavant un processus de standardisation plus qu’un standard stable, qui devrait continuer à évoluer mais ne devrait théoriquement plus changer de nom.
Mais qui sont les acteurs en charge de ce standard ? Ou pour le formuler autrement, qui décide de ce qui est dans le standard ou non, et selon quel processus ? Cela dépend en réalité de différents acteurs… Ce qui pose problème et cause une certaine confusion, puisqu’ils peuvent se contredire ou avoir des avis divergents. Les principales structures impliquées sont le WHATWG, le W3C et l’IETF, dont les membres sont parties prenantes du sujet à différents niveaux. Au sein de ces structures, les acteurs majeurs sont les sociétés commerciales et les grosses fondations qui disposent des ressources nécessaires à une contribution régulière et importante. Ce fait interroge d’un point de vue à la fois technique et politique : qui implémente quoi –quelle partie de la norme- et comment ?
Le fonctionnement du W3C est, en schématisant, le suivant pour HTML5: proposition de spécification, implémentation, normalisation et enfin intégration au standard. Si personne n’implémente une proposition, celle-ci est abandonnée : l’avantage d’une telle démarche est de ne normaliser que des éléments utiles et qui sont fonctionnels techniquement. En revanche, le risque est que des acteurs majeurs puissent faire obstacle à une implémentation qui ne leur convient pas, ou qui serait en concurrence avec leurs recherches. Un autre inconvénient est la concurrence entre différentes solutions tentant de se dominer les unes les autres… Un des exemples les plus connus est celui des formats supportés par la balise <video>, sujet abordé dans Scale #2 "En quête des standards Open Video".
En ce qui concerne HTML5, la date de recommandation officielle est fixée à 2014 : à cette date, ce sera un standard du web reconnu et tout ce qui est en discussion ou en implémentation actuellement sera normalisé. Mais il est possible, voire très probable que d’autres demandes surgissent d’ici là, préparant la voie à une prochaine évolution. A l’heure actuelle les navigateurs implémentent les spécifications de façon incrémentale, intégrant à chaque version de nouvelles fonctionnalités selon leur propre calendrier. Il est d’ailleurs intéressant de noter que Microsoft fait, pour Internet Explorer 9 et 10, un effort particulier pour implémenter les nouvelles spécifications, et rattraper son retard sur ses concurrents. De nombreux sites comme html5readiness permettent de visualiser le support des diverses spécifications selon les navigateurs.

HTML5, le couteau suisse du web
HTML5 est bien plus qu’un simple langage de balisage structurant une page web, comme l’était son prédécesseur HTML. L’ensemble des normes qui compose ce nouveau standard permettent de déterminer comment du code va interagir avec les balises de la page. Elles régissent aussi les interactions du navigateur avec d’autres composants, aussi bien physiques que logiciels. Il est évident de ce point de vue que le standard a été conçu pour permettre de développer des applications web...
Ces interactions navigateur-composants sont contrôlées via de nombreuses API, parmi lesquelles les plus connues du grand public sont canvas, WebGL, l’audio et la vidéo,… Mais en ce qui concerne le champ des applications web, d’autres API sont beaucoup plus importantes, notamment :
- - La gestion des applications hors ligne, grâce au fichier manifeste. Il permet au navigateur de créer une copie locale des fichiers nécessaires au fonctionnement d’une application hors connexion. L’API JavaScript Navigator permet de connaître l’état de la connexion et de gérer les mises à jour de l’application.
- - L’accès au contexte et aux données locales avec deux API principales déjà disponibles – la géolocalisation et FileSystem. Ces API sont importantes pour les applications mobiles comme de bureau. Elles ont en revanche des contraintes de sécurité assez élevées.
- - Local Storage, qui permet à l’application de conserver sur le poste de l'utilisateur des données réutilisables lors d'un emploi ultérieur, en toute sécurité et sans limite de taille ; une telle fonctionnalité est intéressante pour un accès hors connexion par exemple.
- - L’échange de données entre client et serveur, avec Web Socket qui est bidirectionnel, ou Server-Sent Events, unidirectionnel.
- - Les Web Workers, qui permettent d’implémenter des traitements asynchrones de longue durée. Ces traitements en dehors de la boucle principale sont très utiles pour des traitements graphiques avancés, des tâches de calculs complexes ou de la manipulation de fichiers volumineux.
Même si de nombreuses spécifications, comme la géo localisation, le Client Storage ou les Web Sockets, ont été sorties du HTML5 à proprement parler, celles-ci sont souvent développées par les mêmes personnes ou organisations. De plus, utilisées séparément, ces fonctionnalités comme HTML5 perdent une grande partie de leur intérêt... La tendance est par conséquent de les considérer comme un ensemble cohérent sous le parapluie HTML5.
Si le Web a été créé à l’origine pour pouvoir mettre à disposition des contenus et y accéder, depuis quelques années on assiste à un bouleversement de ce paradigme : de nombreuses applications y sont proposées, non plus seulement côté serveur, mais également côté client dorénavant. Le défi devient donc aujourd’hui offrir aux utilisateurs des applications web aussi riches et permettant des traitements aussi complexes que les applications locales. Une telle offre impliquera pour les éditeurs comme les utilisateurs l’adoption de nouveaux modèles économiques, comme le SaaS.
Les avantages des applications web sont nombreux : avec celles-ci, il n’est plus nécessaire d’acheter une licence coûteuse et d’acquérir un serveur pour une utilisation ponctuelle. L’utilisateur n’a plus à réaliser une installation de logiciel parfois longue et compliquée ou de faire des mises à jour. L’application devient également accessible de partout, quels que soient les supports et les plateformes. On voit donc la richesse et l’intérêt des domaines couverts par l’HTML5, qui dépassent le simple navigateur et les agences web, et vont bien au-delà des interfaces riches...

Ce que'HTML5 va changer...
Comment savoir ce que le web sera dans quelques années ? De quelle manière HTML5 et les prochaines innovations impacteront non seulement les entreprises du web, mais également toutes les autres ? L’effet transformatif d’HTML5 sur l’industrie et les métiers est pour Ori Pekelman, Directeur Technique d’af83, potentiellement plus important encore que celui du cloud computing. "On peut par exemple imaginer disposer bientôt d’applications professionnelles de CAO en ligne… La société Structure Computation quant à elle propose déjà une suite logicielle en ligne pour le calcul de structure". Et la montée en puissance des applications web va à terme poser la question de la viabilité économique des logiciels professionnels, qu’ils soient ou non de niche. En France et dans le monde l’écosystème du service informatique et des éditeurs de logiciels risque par conséquent d’être fortement perturbé si ceux-ci ne prennent pas le virage de l’application web.
D’un autre côté, si l’HTML5 permet de développer des applications fonctionnant sur tous types de supports, on assiste également au mouvement inverse avec le développement de nombreux kiosques d’applications sur le modèle de l’AppStore d’Apple : L’Appup d’Intel, l’AppStore de Microsoft pour Windows8... Quant à Google, la société propose des applications HTML5 sur son Chrome Web Store mais travaille en parallèle sur un portail d’applications natives dans Chrome. On peut donc s’interroger sur la philosophie qui l’emportera.
A ce sujet Ori Pekelman déclare que "rien n’est écrit d’avance... il est encore trop tôt pour dire si le web se transformera en un ensemble de jardins clos (walled garden) ou en applications web collaboratives tirant parti de l’Internet des Données (Linked Data - NdlR publication des données sur le Web sous forme structurée, reliée au réseau et non isolée)." C'est-à-dire soit une prééminence des AppStore ou équivalent, avec des ensembles de service fermés exclusifs à une plateforme, soit un internet complètement ouvert. Selon lui, "il y aura très probablement un mélange des deux pendant un moment".
Il y a donc en ce moment une résistance des acteurs historique de l’industrie de l’informatique, dont HTML5 menace l’activité. Cependant la demande et la pression de la concurrence devrait inciter les différents acteurs à sauter le pas et à développer des applications HTML5. Le support natif du standard par la grande majorité des nouveaux terminaux (smartphones, tablettes,...) jouera également un grand rôle dans son adoption rapide et sa diffusion.
Cependant l’essor des applications web pose un problème particulier : à l’heure actuelle, les fournisseurs de services deviennent propriétaires des données hébergées sur l’application, comme c’est le cas entre autres sur Facebook ou Google Docs. Au-delà de la question éthique d’un tel usage, il est peu probable que cela soit accepté par des entreprises quand il s’agira de bases de données clients, ou de documents de travail critiques. Pour garantir la liberté des utilisateurs, et le succès à long terme des applications web, le découplage des données de l’application elle-même est donc nécessaire. Des projets comme Unhosted, devraient permettre à l’avenir de garantir une telle liberté.
Enfin, le principal défi pour les entreprises, au-delà du virage du HTML5 et des applications web, sera de prendre conscience de l’importance pour elles des structures comme le W3C ou le WHATWG. Étant donné l’impact des mutations techniques, il va devenir crucial pour les acteurs de participer aux divers groupes de travail et de faire entendre leur voix, pour ne pas seulement subir les évolutions, mais les faire et les influencer.
Nos Recommandations
- 1. Sauter le pas
- Malgré un risque, temporaire, d’appauvrissement fonctionnel et de performance pour les premières applications qui feront le pari d’HTML5. Il ne faudra pas être en retard : Aujourd’hui, celles-ci peuvent encore avoir du mal à rivaliser avec les applications natives, ou locales, mais avec l’amélioration des capacités des terminaux d’ici peu, elles devraient surclasser celles-ci. Et à ce moment là, il y a de fortes chances que si vous ne vous soyez pas lancé, un de vos concurrents l’ait fait...
De plus, l’adoption d’HTML5 met à votre portée de nouvelles cibles potentielles pour faire tourner vos applications. Voici quelques exemples pour vous convaincre : avec Windows8 Metro, les applications passent de XAML à HTML5. Imad Sousou, directeur de l’Intel Open Source Technology Center, justifie ainsi l’abandon de Meego, dont les applications natives étaient développées avec Qt, pour Tizen et HTML5 : "Nous croyons que le futur appartient aux applications HTML5". Le principe "Write once run everywhere" devrait enfin finir par devenir réalité. - 2. Contrôler vos données
- Avec les nouvelles applications en ligne, les données sont de plus en plus éparpillées : chez l’utilisateur, chez les fournisseurs d’applications, sur des serveurs dans le nuage,... Cet état de fait oblige les entreprises à s’interroger sur des points cruciaux : Qui contrôle leurs données et comment ? Peuvent-elles récupérer toutes leurs données facilement, quand elles le souhaitent ou si le service est arrêté ? Pourront-elles les porter sur un autre système (application, serveur,...) ou leur format est-il fermé ? Sont-elles sûres que leurs données sensibles restent "privées" ?
Une deuxième problématique s’ajoute, qui est celle de la pérennité des informations. Les données doivent être stockées de façon persistante, et ne pas être impactées en cas de panne par exemple. De plus l’obsolescence en informatique est de plus en plus rapide, et il faut pouvoir être certain d’accéder aussi longtemps que nécessaire à ses données, ce qui implique un contrôle des formats. Un format interopérable et largement utilisé étant bien évidemment le meilleur cas de figure – à défaut il faudra s’assurer de la possibilité de les convertir de façon sûre et rapide.
Ces problématiques sont à considérer sous tous leurs aspects lors du choix des solutions, en fonction de vos usages, besoins et spécifications. - 3. Ne pas sous-estimer la complexité d'une application HTML5
- Au-delà de la complexité intrinsèque d’HTML5, en particulier pour les API, une application HTML5 fait de plus en plus souvent appel à JavaScript. Cependant selon les applications, son usage peut se révéler plus complexe qu’envisagé – maîtriser jQuery ne suffit plus... Faire de la veille, se former et expérimenter sont donc plus que jamais nécessaire. Une équipe de développeurs expérimentés vous permettra également de tirer tout le parti de la combinaison HTML5 - JavaScript.
Il est de plus important de disposer des bons outils, avec des frameworks comme Backbone.js ou SproutCore. Certains autres outils permettent de générer du code JavaScript sans en écrire. Parmi ceux-ci, citons deux solutions de Google, comme GWT qui est un framework Java et leur dernier-né DART, mais également CoffeeScript.
Pour en savoir plus
Voici une sélection de ressources sur l'HTML5, parmi les multiples disponibles en ligne :
- une des « bibles » du HTML5, détaillant les fonctionnalités les plus importantes (il en existe une version française non finalisée à ce jour
- un ensemble de ressources sur l’HTML5, exemples de codes, tutoriaux, bacs à sable
- le récapitulatif du support de chaque fonctionnalité, détaillé par navigateur et version de navigateur
- les spécifications HTML5
- Les démonstrations HTML5 de Mozilla, avec des concours mensuels, Apple et Microsoft
- Savoir quels éléments HTML5 sont utilisés par un site avec le tableau périodique HTML5
- Un peu d'humour : HTML5 est-il prêt ?
Voici également un ensemble de ressources plus pratiques :
- pour le développement mobile, rendre mobile un site HTML5 et appMobi, un ensemble d'outils de développement
- des tutoriaux sur EventSource
- un livre sur l'API FileSystem
- des démonstrations WebGL
- deux librairies 3D, three.js et glge, pour faciliter la 3D avec l'API WebGL
- les spécifications des WebWorkers
IETF, W3C, WHATWG, kesaco ?
L’IETF est un groupe informel, sans statuts, membres, ni adhésion, à l’origine de la première spécification officielle du langage HTML. Son travail est centré sur les protocoles et standards d’internet.
Le W3C, World Wide Web Consortium est un organisme de standardisation comptant plus de 450 membres à l’heure actuelle, grandes entreprises, organisations, fondations, organismes publics. Il a supplanté l’IETF en ce qui concerne l’HTML et publié les versions ultérieures de cette norme.
Le WHATWG est un groupe dissident du W3C, en désaccord avec l’orientation du W3C (notamment sur le XHTML 2). Il est formé par différents développeurs de navigateurs web via une collaboration non officielle. Ceux-ci souhaitent donner la priorité à un format pour créer des applications web ; cependant de nombreux membres sont aussi actifs au sein du W3C. Ce groupe fut le premier à travailler sur l’HTML5. Sa procédure de fonctionnement, inverse de celle du W3C, est "Commit-then-Review" (c'est-à-dire implémentation des changements avant examen et adoption).
Unhosted
Unhosted est un projet initié par Michiel de Jong, pour qui un logiciel n’est libre que si le code et les données sont libres. Cette réflexion a mené à la solution de séparer l’application web et les données utilisées par cette application, à la différence du modèle actuel le plus courant – où on dépose ses données sur les serveurs du fournisseur du service web. Celles-ci peuvent être hébergées chez soi, ou chez un hébergeur tiers de confiance, l’utilisateur gardant en permanence le contrôle sur ses données. C’est alors le navigateur qui traite les données, les encrypte avant de les envoyer au serveur de stockage, et les décrypte quand il les reçoit.
Ce principe permet aussi au fournisseur de services d’avoir une charge de données infiniment moindre sur ses serveurs, et donc des coûts plus limités, puisqu’il n’héberge plus que le code source de l’application… ce qui devrait permettre aux acteurs du Libre de pouvoir proposer des applications à grande échelle plus facilement. La Document Foundation, qui développe LibreOffice, travaille ainsi avec Unhosted, pour LOOL, sa suite en ligne qui devrait être proposée au grand public fin 2012 ou début 2013. LOOL devrait d’ailleurs se positionner comme un très sérieux concurrent de Google Docs...


