Longtemps critiquées pour leur « apparent » manque de richesse graphique, les interfaces Web HTML se sont imposées depuis de manière hégémonique dans les entreprises et administrations. Nous étions au début pourtant peu nombreux à soutenir ces choix face à l’alternative applets et ActiveX, reproduction pure et simple du « passé » Client / Serveur. Les deux principales raisons qui ont fait le succès des interfaces HTML sont une enveloppe technique maîtrisée (malgré les efforts des éditeurs Microsoft et Netscape …) et leur simplicité d’utilisation. Depuis, les technologies ont évolué et les applications de gestion Web se sont complexifiées. Aussi, un réexamen de la situation semble-t-il nécessaire en se souvenant que « ce ne sont pas les études sur la lampe à huile qui ont permis l’invention de l’électricité » (Daniel Jouve) …
Les utilisateurs sont-ils égaux face aux applications de gestion ?
Avant tout, faisons le point sur le fonctionnement des applications Web de gestion actuelles. La grande majorité des utilisateurs se satisfont pleinement des interfaces Web. Cela est d’autant plus vrai si les standards d’utilisation du Web sont respectés. Chaque concepteur d’interfaces doit en effet, se souvenir que ses utilisateurs passeront plus de temps sur des sites externes (Yahoo, Boursorama, …) que sur son application. Il se conformera donc à respecter ce qui marche ailleurs… facilitant ainsi l’adoption de son application. Par exemple, la présentation d’une liste (de mails, de produits, de clients, de résultats …) permettra le tri sur certaines colonnes, fournira une pagination des informations, etc
Face à cette belle unanimité, quelques voix courageuses s’élèvent. Courageuses, car bien souvent, elles sont immédiatement taxées de rétrogrades. Or, elles ne traduisent pas toujours un frein au changement, mais parfois un réel problème de productivité. Dans bien des cas, cette minorité d’utilisateurs « grincheux » a des besoins différents face à l’application concernée : allers-retours fréquents, traitements de lignes par lot (drag&drop, déplacement …), tris rapides sur les colonnes, validation de données champs par champs (tels que les codes postaux impossibles à contrôler en JavaScript) … Et, dans ce cas, l’interface Web correspond bien à une régression par rapport aux applications « clients lourds ». Une fois cette différence admise, il convient de réétudier si de nouvelles solutions techniques peuvent y pallier.
L’interface utilisateur au fil des évolutions techniques
Aujourd’hui, techniquement, on pourrait assister au retour de l’interface client riche pour les applications de gestion. J’écris bien « techniquement » car, même si c’est faisable (utiliser de nouveau des interfaces utilisateurs riches), ça ne veut pas dire que cela va forcément avoir lieu…
Petit rappel historique : il faut se rappeler que les grands tournants techniques qui ont marqué l’évolution de l’informatique lors de ces 30 dernières années ont toujours été accompagnés (voire même provoqués) par un changement profond dans l’interface utilisateur.
À l’époque du mainframe tout-puissant, au niveau de l’interface utilisateur, les choses étaient simples, on avait droit à l’interface caractère en mode bloc et c’était tout ! Ce mode bloc, s’il était économe en ressources techniques, imposait une ergonomie très frustre : l’utilisateur n’avait droit à aucune aide ou contrôle de saisie tant qu’il n’avait pas « transmis » sa transaction…
L’ère du PC a apporté puis imposé l’interface utilisateur graphique mais cela ne s’est pas fait en un clin d’oeil (avant d’avoir Windows, on a eu Dos d’abord…), il a fallu du temps avant d’admettre que l’interface graphique n’était pas seulement utile pour les tâches bureautiques, son bénéfice était également important pour toutes les applications de gestion réclamant beaucoup de saisie. Si dans vos applications de production vous utilisiez le mode graphique et tous ses avantages (case à cocher pour indiquer la présence d’un élément, bouton radio pour sélectionner un choix parmi trois ou quatre, valeurs apparaissant dans une petite fenêtre sur laquelle on clique pour désigner une valeur dans une liste, etc.), vos utilisateurs pouvaient alors aller jusqu’à quatre fois plus vite en faisant moins d’erreurs de frappe qu’avec de classiques transactions en mode bloc.
Ceci dit, sur le plan strictement ergonomique, le bénéfice apporté par les interfaces graphiques a souvent été gâché par une incompréhension des contraintes en matière de design. En effet, l’enveloppe de possibilités théoriquement illimitées de Windows peut se révéler dans de nombreux cas un sérieux handicap. Ainsi, est-il difficile de choisir entre les nombreuses façons d’accomplir telle ou telle fonction. De fait, il existe toujours plusieurs « gestes » pour une même tâche. Pour un contexte de type application de gestion, ce potentiel très large peut devenir gênant car il comporte de nombreuses façons de mal faire.
Toutefois, ce handicap n’a pas été suffisant pour freiner la progression de l’interface graphique au sein des entreprises. En revanche, on s’est vite aperçu que le déploiement des applications client-serveur posait problème. Et c’est bel et bien ce syndrome du déploiement qui a empêché la généralisation du modèle client / serveur à l’échelle de l’entreprise et donc de l’utilisation de l’interface graphique à large échelle pour les applications de gestion…
L’avènement du Web a permis de sortir de cette situation bloquée : soudain, il y avait une solution disponible, simple, standard et répandue à des millions d’exemplaires (au moins pour ce qui est de la partie cliente).
Mais que faire alors avec notre minorité d’utilisateurs « grincheux », à juste titre, …
Les interfaces clients riches « zéro déploiement » et respectant des protocoles standards Web HTTP, XML … : un nouveau tournant ?
Après les échecs des applets et des ActiveX, la disponibilité d’applications client riche Web pour une catégorie d’utilisateurs limités semblait irréaliste. Or, une barrière technique ne résiste pas éternellement et, récemment, le problème du déploiement des applications clientes riches a reçu de nouvelles réponses avec Java Web Start [Java Web Start : [ ]], les WinForms de Microsoft .NET [Smart Client Application Model and the .NET Framework 1.1 : [ ]] et l’Action Script de Macromedia Flash[Macromedia Flash MX : [ ]].
Ces technologies apportent deux innovations majeures :
– la possibilité réelle de déployer sans coût une application lourde sur le poste client,
– la possibilité d’accéder à des traitements côté serveur via des protocoles et des standards tels que HTTP et XML.
Il devient alors possible de proposer l’accès à une application de gestion via deux interfaces : une interface HTML pour les utilisateurs standards, une interface client riche pour les utilisateurs ayant un besoin de manipulation fort (à noter qu’ils ne sont pas forcément les utilisateurs intensifs …). Les traitements côté serveur sont dans ce cas les mêmes quelle que soit l’interface utilisée.
Comment ça marche ? A titre d’exemple décrivons le fonctionnement de Java Web Start : Il s’agit d’un petit logiciel qu’il faut installer côté client ; il mesure entre 700 Ko et 5 Mo selon que le poste utilisateur dispose ou non d’un runtime Java déjà installé. Ce logiciel se comporte comme un plug-in et permet le déploiement et le lancement automatique de logiciels par un simple clic sur un lien hypertexte dans un navigateur Web. Donc, en dehors de cette opération préalable, le déploiement des applications est effectivement facilité.
Lors du premier lancement de l’application, le module Java Web Start la télécharge et l’enregistre dans un répertoire du disque dur côté client ; puis lance son exécution. Lors des lancements ultérieurs, Java Web Start se borne à vérifier que la version de l’application n’a pas changé depuis sa dernière exécution ; il ne la re-téléchargera que si les versions côté client et serveur ne concordent pas. Un autre des intérêts de cette technique est que la configuration des applications se fait côté serveur, un avantage important dans le cadre du déploiement.
Et maintenant, que vais-je faire ?
Les interfaces Web resteront prédominantes dans notre paysage informatique qui évolue toujours plus vers une webification à grande échelle. Néanmoins, les technologies « client riche » Web auront une place croissante dans les systèmes d’information. Les responsables informatiques doivent y être sensibilisés pour des réponses toujours plus adéquates face aux besoins utilisateurs. Ces technologies se développeront d’autant plus qu’elles seront aussi simples à mettre en oeuvre que les technologies HTML. Si des progrès restent à faire pour Java et Flash pour lesquels les coûts de mise en oeuvre sont encore élevés … Microsoft bénéficient d’un avantage concurrentiel sur lequel le géant de Redmond n’a pas communiqué … encore.
