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…

2 commentaires sur “20 ans d’évolution des IHM web

  1. Le Web ne se résume pas à un navigateur, c’est un ensemble de technologies qui répondent à des normes et qui permettent de développer des services accessibles.
    A la façon de l’informatique moderne, le Web est découpé selon le principe du Model -View – Controller :
    – les données (la partie Model) sont hébergées sur l’internet quelque part
    – les applications (ou Controller) tournent sur des serveurs quelque part et permettent de donner du sens aux données brutes (en créant des listes ou des cartes géographiques par ex)
    – l’interface d’accès (ou View) est dans l’application qui est lancée par l’utilisateur soit sur son smartphone, sur son ordinateur ou dans un navigateur.

    La partie View n’a pas besoin d’être universelle, elle doit s’adapter à l’appareil sur lequel le service va s’afficher.
    Google Maps est en premier un service qui permet de donner sens à des données brutes (Model) et aussi une API sur laquelle se branchent des applications (View) telles que Maps ou Uber ou autre.

    Pourquoi avoir autant d’insistance pour que tout passe en mode HTML à travers des navigateurs ?
    Pour chaque site il faut redéfinir l’interface via les css pour des devices particuliers, l’universalité n’est pas vraiment là.

    (je réponds très en retard mais je ne pense pas souvent à venir sur ce site passionnant)

  2. Vous faites d’excellents articles, comment est-il possible de vous contacter.
    Je travaille avec l’Education Nationale.

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s