Etat de l’art des interfaces riches

Voilà plus de 6 ans que je parle des interfaces riches sur ce blog (en fait depuis la première année). Au cours de cette période, il s’est passé beaucoup de choses et les usages se sont fortement diversifiés et intensifiés. Je souhaiterais aujourd’hui faire un tour d’horizon des interfaces riches pour plusieurs raisons :

  1. Parce que les interfaces riches existent depuis plus de 10 ans et sont indissociables de l’internet ;
  2. Parce qu’il y a toujours ce très désagréable débat de fond sur HTML5 qui va remplacer Flash (une belle ineptie : Pourquoi HTML5 et Flash ne peuvent être comparés) ;
  3. Parce que l’on en parle trop peu et que le sujet est néanmoins délicat à traiter ;
  4. Parce que je suis en train de finaliser une formation sur ce sujet : Interfaces riches, quelles opportunités pour votre marque ou votre activité.

Bref, j’ai envie de mettre les interfaces riches à l’honneur. Mais commençons par le commencement…

Définition et historique

Lancé en 1996 par Macromedia, Flash est la technologie la plus emblématique des interfaces riches. Cela fait donc 15 ans que les interfaces riches existent. Le terme « Rich Internet Application » est par contre plus jeune puisqu’il a été introduit pour la première fois en mars 2002 (on utilisait également les termes « client riche« , « client léger« , « client web« …).

Pour bien comprendre ce que sont les interfaces riches, intéressons-nous d’abord à ce qu’elles ne sont pas. Les interfaces pauvres désignent ainsi les pages web statiques composées de textes ou d’images. N’y voyez pas un quelconque jugement de valeur, des sociétés comme Amazon ou Ebay ont gagné des milliards de dollars avec des pages web composées exclusivement de textes, images, tableaux et formulaires.

Il est également important de ne pas opposer interfaces riches et pages HTML : les interfaces riches sont un complément du HTML, pas un substitut. Les interfaces riches sont ainsi des modules encapsulés dans des pages HTML. Donc dans tous les cas de figure, les interfaces riches ne remplacent pas le HTML, elles le complètent, l’enrichissent.

La définition communément admise est que ce sont des interfaces web qui proposent les mêmes fonctionnalités et la même expérience qu’une application traditionnelle, mais je trouve cette vision trop restrictive, car elle se limite à l’aspect applicatif. Nous en venons donc à ma définition : Les interfaces riches sont des interfaces web offrant plus de possibilités d’affichage et de manipulation que les pages web traditionnelles. Cette définition englobe donc des usages plus vastes dont le rich media. Mais cela n’empêche pas les éditeurs de solutions de présenter les interfaces riches comme une alternative très intéressante aux applications classiques.

Vous noterez également que ma définition ne mentionne pas explicitement les navigateurs web. Et pour cause, les interfaces riches se scindent en deux grandes familles :

  • Les Rich Internet Applications (RIA) qui sont exécutées dans le navigateur ;
  • Les Rich Desktop Application (RDA) qui sont lancées depuis le bureau.

Autant les RIAs restent confinées dans votre navigateur, autant les RDAs sont indépendantes de ce dernier et sont lancées depuis le menu « Démarrer » ou un raccourci. Elles se comportent donc comme des applications natives et ne sont pas installées sur le système d’exploitation mais sur une couche intermédiaire (la machine virtuelle). Cette différence entre RIA et RDA est subtile, mais peut parfois être confusante à l’image de logiciels qui peuvent être exécutés indifféremment dans votre navigateur ou sur votre bureau comme Balsamiq ou le Project Rome.

Il y a quelques années j’avais rédigé un article pour expliquer ces différences types d’interfaces riches: 10 ans d’évolution des interfaces web au service de l’expérience utilisateur. Même si certaines technologies ont disparu ou évolué, le schéma d’ensemble est toujours valide :

Comparaison des différents types d'interfaces riches

Nous en venons donc à la grande question : les interfaces riches sont-elles mieux que les interfaces pauvres ?

Pourquoi utiliser les interfaces riches ?

En fait la question de la supériorité des interfaces riches est subjective : mieux par rapport à quoi ? Comme avec toute technologie informatique, tout est une question de contexte et de contraintes. Les interfaces riches sont plus sophistiquées, mais plus lourdes qu’une page HTML. Elles sont plus puissantes, mais plus complexes. Elles sont plus performantes, mais plus risquées.

Il existe de nombreux avantages et inconvénients à utiliser les interfaces riches, mais nous pouvons néanmoins isoler 3 motivations principales :

  • Afficher des contenus multimédia (vidéos, musiques, animations…) ;
  • Offrir une expérience utilisateur plus sophistiquée ;
  • Proposer un outil de travail plus performant.

Autant il ya quelques années la question avait son importance, autant maintenant les interfaces riches sont partout, sous la forme de modules enrichis exploitant différentes technologies (javascript, Flash…). Les sites de commerce en ligne font ainsi un usage quasi-systématique des interfaces riches : Différentes interfaces riches pour différentes fonctions.

Les interfaces riches appliquées au commerce en ligne

La question à laquelle vous devez donc répondre est plus de savoir si telle interface ou tel module mérite un enrichissement en fonction du contexte (vos cibles, vos contraintes…). Il n’existe pas de méthode universelle pour savoir quand une interface riche est plus appropriée qu’une page HTML classique, encore une fois tout est question de contexte, il n’y a pas de bon ou mauvais choix.

Nous pouvons cependant isoler quatre grandes familles d’usages où les interfaces riches sont particulièrement bien adaptées :

Les quatre grandes familles d'usages des RIAs

Ce panorama des usages n’est pas forcément exhaustif, mais il dresse un tableau assez complet de ce pour quoi les interfaces riches sont conçues. Il vous est toujours possible de faire ce que vous voulez avec les RIAs (pourquoi pas un site textuel en Flash) mais il est toujours préférable de choisir la bonne technologie pour le bon usage. Ce qui me fait une parfaite transition avec la suite…

Quelles technologies pour quels usages ?

Le moins que l’on puisse dire est que les gros éditeurs sont particulièrement actifs pour promouvoir leurs technologies. Les grands acteurs ainsi présent sont les suivants :

  • Adobe avec Flash/Flex mais aussi AIR et l’OpenScreen Project ;
  • Microsoft avec Silverlight et WindowsClient (WPF et Windows Forms) ;
  • Google avec GWTNaClO3D et différents sites d’évangélisation de javascript comme Chrome Experiments ou 20ThingsILearned ;
  • Sun, Oracle et IBM qui sont les grands promoteurs de Java et des technologies qui vont avec ;
  • Apple qui se fait très discret mais exploite son format Quicktime ainsi qu’un framework javascript (Gianduia) ;
  • Le W3C qui oeuvre à standardiser tout ça et à faire évoluer les spécifications au travers des ses groupes de travail.

Je ne rentrerais pas dans une explication laborieuse sur les intérêts croisés de ces différents éditeurs, mais je pense ne pas me tromper en disant que les enjeux sont de taille et qu’aucun des acteurs cités plus haut ne sont à considérer comme bienfaiteur ou néfaste (la réalité est plus contrastée).

Toujours est-il qu’il existe un sacré nombre de technologies et qu’il est parfois difficile de s’y retrouver. Je vous propose donc cette classification des différentes familles technologiques liées aux interfaces riches :

Les familles technologiques des interfaces riches

Deux précisions importantes : ce panorama n’est pas exhaustif ; il existe des subtilités qui empêchent le rattachement de certaines technologies à telle ou telle famille (notamment XUL, OpenLaszlo, NativeClient, XForms) mais j’ai fait le choix de la simplification pour ne pas compliquer le travail d’évangélisation. Si vous avez une meilleure classification, n’hésitez pas à la mentionner dans les commentaires.

Le choix d’une technologie par rapport à une autre est encore une fois question de contexte : en fonction des ressources disponibles, de l’historique du projet et de son héritage, des contraintes, du budget et des délais… Il existe une infinité de critères, mais souvenez-vous qu’il n’y a pas de mauvais choix, juste des compromis.

Les nouveaux facteurs à prendre en compte

Autant il y a trois ans le choix se résumait à choisir entre Flash et Ajax, autant la situation est nettement plus compliquée aujourd’hui. Et ceci pour plusieurs raisons :

  • Les navigateurs récents sont de plus en plus performants (Chrome, Opera et Firefox se battent à coup de benchmarks) et permettent aux interfaces riches et applications réalisées en javascript de rivaliser avec les RIAs plus « lourdes » (réalisées en Flash, Silverlight…) en terme de stabilité et de rapidité d’exécution. De même, le W3C et les industriels du web (Google, Apple…) ont fait de gros efforts pour promouvoir HTML5 ainsi que CSS3 et inciter les éditeurs à mieux exploiter les opportunités offertes (cf. CSS3 et javascript seront-elles les technologies RIA du future ?). Les technologies standards du web rentrent maintenant en concurrence avec les technologies propriétaires pour la réalisation d’enrichissements de premier niveau (transitions, petites animations, effets graphiques…). Et ne pensez pas qu’Internet Explorer va se laisser facilement distancer par ses concurrents, car Microsoft s’apprête à lancer IE9 qui devrait leur permettre de rattraper une bonne partie de leur retard (avec notamment un bien meilleur support de HTML5 et CSS3).
  • Les smartphones et terminaux alternatifs prennent une place toujours plus importante dans nos usages quotidiens et notre consommation des services et contenus en ligne (cf. 2011, l’année du point de bascule). Il convient donc d’intégrer cette contrainte dans votre choix dès le départ et de réfléchir aux meilleurs moyens d’exploiter les opportunités offertes par ces terminaux.
  • Une très grosse bataille est en cours sur les codecs utilisés pour diffuser de la vidéo avec HTML5. Ce point rejoint les deux précédents, ou plutôt cristallise les tensions liées à l’exploitation de la vidéo en ligne (énorme marché) sur les terminaux alternatifs (smartphones, tablettes, TV connectées…). En fait, les enjeux de cet affrontement sont tellement importants que ce sujet mérite d’être isolé.

Rajouter à cela les contraintes d’accessibilité, de référencement, d’utilisabilité, de ROI, de performances, de disponibilité des ressources… et vous aurez un contexte extrêmement complexe à maitriser. Est-ce une mauvaise nouvelle ? Non pas du tout, car si ce sujet est aussi complexe, c’est qu’il est au coeur de l’internet et du quotidien des utilisateurs. En d’autres termes : Bien appréhender les enjeux liés aux interfaces riches conditionne le succès de votre présence sur le web.

11 commentaires sur “Etat de l’art des interfaces riches

  1. Si je lis le descriptif de la formation (http://fredcavazza.wordpress.com/formation-interfaces-riches/) il est noté :
    > Les technologies propriétaires (XUL, ActiveX, SmartClient, IBM Forms)

    Soit il y a incompréhension, soit il y a erreur sur les mots.
    XUL n’est _pas_ une technologie propriétaire. En tout cas pas au sens d’un logiciel ou d’une techno propriétaire comme on l’entend … heu … tout le temps.

    XUL est la base par exemple de firefox. XUL est disponible sous licence GPL, LGPL et MPL et ça en fait donc un logiciel libre.

    Mais peut-être ai-je mal compris le « propriétaire »

    voir par exemple http://en.wikipedia.org/wiki/XUL

  2. @ Plop > Je ne sais pas si tu as déjà essayé de simplifier la classification des interfaces riches, mais c’est un exercice très délicat. « Technologie propriétaire » veut dire « qui ne s’exécute que dans un environnement particulier » (en l’occurrence Firefox). XUL et NativeClient rentrent donc potentiellement dans cette catégorie. Mais dans ma classification plus haut je les ai positionné dans 2 familles différentes car c’est mon point de vue. J’ai prévu de publier un article sur InterfacesRiches.fr qui explique de façon plus détaillé ces familles, ça sera l’occasion de traiter les cas particuliers comme XUL (et OpenLaszlo et XFomrs et …).

  3. La technologie XUL ne s’exécute pas « dans un environnement particulier » mais depuis un runtime XULRunner. Ce runtime est disponible pour Windows, Mac et Linux, ce qui couvre plus de 99% des OS grand public à mon avis…
    Ta confusion vient probablement du fait que Firefox intègre lui-même une version de XULRunner, le rendant donc apte à exécuter une interface XUL.
    Voilà de quoi changer la classification de XUL ;-)

  4. Notre expérience est que tous les internautes ne sont pas prêts à passer aux interfaces riches. Là où nous te rejoignons c’est qu’il faut sans doute mettre en avant le coté riche de l’interface, sinon il faut revenir au html « normal » ou tout du moins chercher à l’imiter. C’est notre expérience chez Gifteer.

  5. @ Gifteer > Avec HTML5 et CSS3, l’HTML “normal” devient riche. Les technologies évoluent, donc au final c’est peut-être la définition même des interfaces riches qui doit évoluer…

  6. « Les frameworks javascript qui harmonisent les développements Ajax »
    … ne veut pas dire grand chose.

    AJAX est un subset minuscule de ce que ces framework proposent en terme de possibilités.

    « Autant il y a trois ans le choix se résumait à choisir entre Flash et Ajax »
    … n’est pas bien plus pertinent.

    Flash et AJAX n’ont vraiment rien à voir. Les deux ne sont pas utilisés pour les mêmes raisons.

Laisser un commentaire