20 ans d’évolution des IHM web

En 15 ans, le web a complètement modifié notre façon d’accéder et de consommer l’information. Le web est maintenant une composante essentielle de notre quotidien : biens dématérialisés, services en ligne, formation et éducation, jeux en ligne, objets connectés… Je pense ne pas me tromper en disant que le web a façonné la société dans laquelle nous vivons : transparence absolue, peur du micro-ennuie, hyper-individualisme avec la mode des selfies… 15 années très riches, et un nombre incalculable d’innovations technologiques. Je vous propose à travers cet article de faire le point sur l’évolution des technologies liées aux interfaces web.

Dans sa définition la plus stricte, une interface est la couche entre deux éléments par laquelle ont lieu des échanges et des interactions. Dans le cas de l’internet, les interfaces web sont donc la couche permettant aux utilisateurs de consommer et d’interagir avec les nombreux contenus et services en ligne. Nous allons donc passer en revue les différentes technologies d’interface web, étudier leur évolution et constater la façon dont les grands éditeurs essayent encore et toujours de ramener la couverture à eux.

Des sites web aux rich desktop applications

Aux origines du web, les contenus et services n’étaient disponibles qu’à travers les pages HTML : du texte, des tableaux, des images et des formulaires. Mais au fil du temps, les choses se sont compliquées : Panorama des IHM connectés.

Evolution_IHM-1

Si le navigateur était l’interface de référence entre les contenus et les internautes, différentes technologies ont été successivement exploitées pour enrichir l’expérience :

  • Les applets Java pour faire les premières applications en ligne ;
  • Les plugins comme Flash et Silverlight pour faire des Rich Internet Applications ;
  • Les moteurs de widget pour pouvoir diffuser du contenu directement sur le bureau ;
  • Les machines virtuelles comme AIR pour faire tourner des Rich Desktop Applications.

Tout ceci peut vous sembler complètement superflu, mais souvenez-vous qu’à cette époque le W3C souffrait d’une crise interne et que les spécifications de HTML faisaient du sur-place. D’où l’émergence de nombreuses technologies d’interfaces riches pour pouvoir étendre les possibilités du HTML et proposer des modalités d’affichage et d’interaction plus sophistiquées (3D, drag&drop…).

Très clairement cette première décennie de l’histoire des interfaces web a été dominée par Adobe et ses deux technologies phares (Flash et AIR). Puis Apple a lancé son iPhone, et le marché s’est complètement retourné.

Des applications mobiles aux applications packagées

C’est en début d’année 2007 que Steve Jobs a présenté pour la première fois son iPhone. Nous étions très loin de nous douter à l’époque de la révolution que cela allait engendrer, d’autant plus que dans sa première version, il n’y avait pas d’App Store, d’ailleurs ils n’envisageaient pas à l’époque d’ouvrir leur smartphone à des éditeurs externes d’applications. Et pourtant… avec la version 2 et surtout la version 3 du système d’exploitation de l’iPhone, les applications mobiles vont connaitre un succès phénoménal : même si les contenus et les services étaient les mêmes, le fait de les consommer à travers une interface tactile en situation de mobilité a poussé les mobinautes à s’enfermer dans la logique des applications.

Evolution_IHM-2

Loin de moi l’idée de refaire l’histoire, mais les applications mobiles sont à la fois la meilleure et la pire chose qui a pu arriver au web : la meilleure, car cela a permis de démocratiser les interfaces tactiles et de donner un second souffle créatif aux designers ; la pire, car cet écosystème fermé d’applications va à l’encontre du principe d’ouverture et d’universalité du web. C’est d’ailleurs pour protéger son monopole qu’Apple est entré en guerre avec Adobe pour empêcher aux applications Flash de détourner les revenus provenant de son app store. Mais dans une certaine mesure, la volonté d’Apple de diaboliser Flash pour protéger ses revenus a fortement contribué au succès d’HTML5. La montée en puissance de navigateurs alternatifs comme Chrome et Firefox, combinée à un fort enthousiasme autour du renouveau d’HTML a permis de viabiliser l’exploitation à très grande échelle d’applications web comme Gmail, Twitter ou encore SalesForce. Si aujourd’hui, il ne vous venait plus à l’idée d’installer un logiciel pour consulter vos emails ou pour interagir avec vos amis ou collègues, sachez qu’à une époque pas si lointaine le débat faisait rage.

Avec la montée en puissance d’Android, de Windows Phone, et plus généralement la fragmentation des terminaux mobiles, certains éditeurs de contenus et service se sont rapidement rendu compte qu’éditer des applications natives n’était pas forcément une stratégie rentable. Ils se sont tournés vers des frameworks de développement multi-plateforme comme Phonegap, Titanium ou Sencha pour faire des applications hybrides : des contenus et services HTML encapsulés dans une application native. Aujourd’hui le débat entre applications mobiles natives, hybrides ou HTML est toujours actif (Le choix se complique entre application mobile et application HTML5), d’autant plus que l’on a maintenant un minimum de recul sur les mises en page adaptatives (Le Responsive Web Design n’est pas une solution, c’est un compromis).

Personne ne peut nier le rôle primordial de l’iPhone et l’iPad dans l’évolution radicale des usages autour des interfaces. Mais pendant ce temps là, d’autres préparaient leur contre-attaque, à commencer par Adobe qui s’est repositionner en un temps record sur les technologies standards (cf. Adobe & HTML) et qui a même lancé une suite complète d’outils de développement HTML5.

De même, Google a patiemment conçu et perfectionné les différentes pièces d’un plan dont on commence seulement à deviner les contours : ils ont commencé par populariser le navigateur Chrome en utilisant des briques logicielles communes à d’autres produits, dont le moteur de rendu Webkit. Puis ils ont adopté leur propre moteur de rendu HTML (Blink) et ont implémenté la technologie NaCl pour pouvoir exécuter des applications C++ (L’adoption de NativeClient passera par les jeux… et la bureautique). Plus récemment, ils ont commencé à faire la promotion des Chrome Apps, des applications HTML pouvant tourner en mode déconnecté avec Chrome ou ChromeOS (Google transforme son navigateur en environnement d’exécution avec les Chrome Apps). Les choses se sont accélérées tout dernièrement avec l’annonce d’un environnement de développement dédié et le portage des Chrome Apps sur iOS (Google veut accélérer le développement des Chrome Apps). En quelques années, Google s’est imposé comme l’acteur principal du renouveau des interfaces web, aussi bien sur les ordinateurs (avec les applications packagées) que sur les terminaux mobiles (Google prépare la révolution des interfaces Android).

Nous sommes quasiment à la fin de cette seconde décennie et nous y voyons maintenant beaucoup plus clair dans les plans de Google : s’appuyer sur les technologies standards (HTML, javascript…) pour généraliser ses environnements d’exécution (Chrome, ChromeOs et Android). Tout ceci n’est pas sans rappeler les manoeuvres de Microsoft ou Adobe, mais force est de constater que nous allons tout de même vers plus de simplicité et de performance pour les utilisateurs finaux (le fait de pouvoir éditer des documents Office directement dans Chrome avec QuickOffice est quand même un grand plus).

Voilà où nous en sommes en ce début d’année 2014. Vous constaterez que malgré une domination écrasante de son système d’exploitation, Microsoft n’est jamais réellement parvenu à prendre le leadership sur les interfaces web et à imposer ses technologies (le flop de Silverlight est un bel exemple). Il est pour le moment très difficile de prédire l’avenir, mais je suis persuadé que les choses ne vont pas beaucoup bouger : la communauté des développeurs va se détourner des plugins et s’orienter à nouveau vers HTML, que ce soit pour scénariser du contenu, perfectionner des applications en ligne ou se réapproprier les terminaux mobiles. Ceci fera l’objet d’un prochain article…

Google veut accélérer le développement des Chrome Apps

Depuis ses débuts, Google a toujours misé sur les technologies web et a été un fervent défenseur des applications en ligne. Il existe bien des applications Google que l’on installe sur son ordinateur (Picasa, Sketchup…), mais elles sont anecdotiques. Google avait fait sensation en 2009 en annonçant le lancement de ChromeOS, un système d’exploitation pour les chromebooks reposant sur un noyau Linux, mais avec une interface 100% web. Traduction : un ordinateur sur lequel on ne peut pas installer de logiciels et où tout se passe dans le navigateur, en l’occurrence Chrome. Un choix très avant-gardiste que j’ai eu l’occasion de commenter (Avec Chrome OS, Google parie sur le CloudBook et La fin de l’ordinateur individuel est programmée). Quatre ans après, ce choix s’avère payant, car les chromebooks représentent maintenant plus d’1/5 des ventes d’ordinateurs portables : Google’s Chromebooks Have Hit Their Stride.

Exemple de Chromebook fabriqué par Acer
Exemple de Chromebook fabriqué par Acer

Le problème est que si tout le monde est d’accord pour dire que ces machines proposent un rapport qualité / prix imbattable, leur utilisation en mode hors connexion est très hasardeuse. Non en fait pour être exacte, les termes généralement employés sont : “sans une connexion internet, un chromebook est un gadget complètement inutile“. Pour pallier a cette faiblesse, les équipes de Chrome ont travaillé d’arrache-pied pour améliorer la gestion du mode hors connexion. Le résultat sont les Chrome Apps, des applications web qui fonctionnent hors-ligne, en d’autres termes : des applications en ligne qui se comportent comme des logiciels (cf. What Are Chrome Apps?). Vous noterez d’ailleurs que ces Chrome Apps ne sont pas uniquement réservées aux Chromebooks, mais à tous les ordinateurs qui utilisent Chrome (Google transforme son navigateur en environnement d’exécution avec les Chrome Apps). Vous pourriez me dire qu’une application en ligne fonctionnant sans connexion ne pourra jamais réellement remplacer un “gros” logiciel, mais là encore, Google a réfléchi à la question (Tous vos documents bureautique consultables directement dans votre navigateur).

Google cherche donc à faire de Chrome le coeur de son écosystème. Mais le problème est que pour qu’un écosystème informatique soit viable, il faut un minimum d’applications et de développeurs. Dans ce contexte, il semblerait que Google soit en train de travailler sur un certain nombre d’outils pour leur simplifier la tâche. L’infatigable François Beaufort a ainsi repéré en fin d’année dernière un projet d’environnement de développement de Chrome Apps : Google building Spark, a Web-based development tool. Le projet Spark est donc un IDE (Integrated Development Environment), un ensemble d’outils permettant aux développeurs de créer beaucoup plus facilement des applications pour Chrome.

L'environnement de développement de Chrome Apps
L’environnement de développement de Chrome Apps

Cet environnement de développement présente deux particularités intéressantes :

Dart, Polymer, Spark, Native Client… force est de constater que Google ne ménage pas ses efforts pour séduire la communauté des développeurs et imposer sa vision d’une informatique plus “légère”. Et puisque l’on parle d’alléger l’outil informatique, comment ne pas évoquer Android, le système d’exploitation mobile de Google. Figurez-vous qu’avec les Chrome Apps, ils ont réussi à faire la liaison entre les deux OS : Google is building Chrome apps support for Android and iOS, beta release coming as soon as January 2014. Une autre équipe est en train de finaliser un mécanisme de portage des Chrome Apps pour qu’elles puissent être exécutées sur un terminal Android, toujours par l’intermédiaire de Chrome.

Les Mobile Chrome Apps sont donc l’arme secrète de Google pour révolutionner les concepts de logiciel et d’application mobile. En d’autres termes : plutôt que de développer une application pour un terminal ou un système d’exploitation spécifique (PC, Mac ou Android), vous pouvez utiliser les Chrome Apps pour déployer des applications web partout où vous le souhaitez. “Arme secrète” est vraiment le bon terme, car les équipes de Google se font très discrètes sur ce chantier. En cherchant bien, il est possible de trouver quelques informations (Chrome DevTools for Mobile: Emulate and Screencast), mais il n’y a qu’une seule personne qui communique ouvertement là-dessus : Porting Chrome Packaged Apps to Mobile using Cordova.

J’imagine que cette discrétion est due aux nombreuses difficultés techniques que les équipes devront résoudre afin de stabiliser les Chrome Apps et l’environnement de développement Spark. Pour mémoire, je vous rappelle que la fondation Mozilla s’était aventurée il y a peu de temps dans un chantier similaire avec Bespin, rebaptisé plus tard SkyWriter et finalement fusionné avec le projet Ace (Mozilla Skywriter has been merged into Ace).

Tout ceci est encore un peu complexe à comprendre et soulève de nombreuses difficultés techniques. Mais c’est le prix à payer pour pouvoir exploiter dans de bonnes conditions des applications en ligne sans connexion. C’est le prix à payer pour réinventer l’outil informatique…