À mesure que le haut débit se démocratise et que les machines disposent de suffisamment de RAM pour faire tourner de grosses quantité de Javascript, nombreuses sont les sociétés décidant de migrer qui une partie de leurs applications métier, qui une partie de leurs applications éditées, sur une plate-forme web. Difficile de ne pas être tentés par le Saint Graal des applications instantanément déployées sur des milliers de postes pour les premières, et des applications impossibles à pirater pour les secondes. Encore faut-il faire les choses correctement : bien que le web ne soit finalement qu’un vecteur de transmission et de présentation des informations, les applications web sont très différente des applications de bureau, et le portage ne manque pas de pièges.

L’envie d’écrire un billet sur le sujet me travaille depuis mon expérience sur le projet Optimia / Niveau 1 en 2003. Optimia était l’outil de gestion des dossiers clients d’EDF/GDF. J’avais rejoint l’équipe de développement au moment où ils passaient d’un outil client lourd développé en Power Builder connecté à une base Sybase vers une plate-forme web en J2EE. Toute la difficulté résidait dans une contrainte de 99% d’isométrie ergonomique et fonctionnelle avec la version précédente. Ces contraintes étaient dictées par des impératifs économiques et pratiques – difficile de former des milliers d’utilisateurs en un temps record – et un contexte politique et social hyper tendu avec l’ouverture des marchés de l’énergie à la concurrence dans lequel les changements devaient être limités au maximum. Incidemment, cela coïncidait avec les premières utilisations sérieuses d’AJAX et un regain d’intérêt de ma part pour le web après des années de dédain.

Ce billet tente de mettre l’accent sur des erreurs à éviter et des points clés du portage. Il ne cherche en aucun cas à être exhaustif, bien qu’il ne soit pas exclu que j’aborde un certain nombre d’autres points dans des articles à venir. Les difficultés envisagées sont d’ordre techniques et humaines :

  1. La bande passante.
  2. Les habitudes des utilisateurs du web.
  3. Les habitudes des utilisateurs d’applications desktop.
  4. La résistance au changement.

Tout le monde ne dispose pas d’une bande passante illimitée

Bien qu’en France, le haut débit se soit très largement démocratisé, la majorité de la planète utilise encore de vieux modems 56k, et de très nombreuses entreprises utilisent encore en interne des liaisons RNIS 128k.

Afin de permettre à tous de pouvoir utiliser les applications, tâchez de ne rafraîchir que le minimum d’une page tant qu’il ne s’agit pas de valider des informations. L’AJAX est maintenant une technologie éprouvée, disponible par défaut de manière simple dans la plupart des framework web, et son utilisation à bon escient permet d’éviter bien du trafic inutile.

Cependant, afin de rester accessible au plus grand nombre, n’oubliez pas de développer en progressive enhancement, qui veut que l’on développe des applications fonctionnant de la manière la plus simple possible – c’est à dire sur des navigateurs ne disposant pas de Javascript – avant d’ajouter les améliorations clica convi. Les aveugles et les déficients visuels vous en remercieront.

Dans les esprits, une application web doit se comporter comme un site web

Il y a 3 ans maintenant, j’ai été amené à assurer la formation des futurs utilisateurs d’une application utilisant massivement de l’AJAX afin d’utiliser au minimum une liaison RNIS ridicule et par ailleurs déjà saturée. S’agissant du premier portage d’une application desktop sur un environnement de ce type, le retour des testeurs était très important afin d’assurer le portage d’un grand nombre d’autres applications du même genre. Le retour avait été unanime : quand on valide un formulaire et que la page ne se recharge pas, on n’a pas l’impression que les données ont été effectivement transmises au serveur.

Les utilisateurs s’attendent naturellement à ce qu’une application web agisse comme un site web traditionnel. Cela implique particulièrement que tout changement d’état des données manipulées à l’écran doit passer par un rechargement complet de la page, quand bien mêmes les données seraient-elles envoyées en AJAX. Ce point représentait plus qu’une gène pour les utilisateurs qui cliquaient frénétiquement sur leur souris tout en remplissant fiches de bugs sur fiches de bugs, se plaignant qu’aucune des pages ne marchait.

Afin de pallier ce problème, nous avons du provoquer artificiellement le rechargement de la page à chaque validation de formulaire, quand bien même ce rechargement n’entraînait systématiquement aucun changement sur les données manipulées.

Le clic droit n’est pas une fatalité

Une des problématiques auxquelles vous devrez faire face lors du portage d’une application vers le web portera sur l’utilisation du clic droit sur l’application d’origine. En effet, nombreuses sont les applications qui l’utilisent afin de proposer des actions contextuelles qu’il faudra reproduire d’une manière ou d’une autre.

Il est certes possible de récupérer le clic droit en javascript, et de déclencher une action, par exemple l’affichage d’un petit menu déroulant, mais ce n’est clairement pas une bonne idée :

  1. Ce n’est absolument pas accessible.
  2. Ce n’est pas “web”.
  3. Cela supprime des fonctionnalités utiles du navigateur.

Il est donc nécessaire de repenser l’accès aux fonctionnalités contextuelles apportées par le clic droit à l’aune du médium web. Pour cela, plusieurs méthodes existent. La plus simple est encore de créer une barre d’icônes, toujours au même endroit, donnant accès aux fonctionnalités contextuelles généralement offertes par le clic droit. N’oubliez pas de reproduire les raccourcis clavier de l’application originale en récupérant les séquences de touches. Si le portage ne diffère pas trop de l’originale, ses utilisateurs habituels vous remercieront largement de les avoir conservés.

Une refonte ergonomique n’est pas toujours un mal

J’aime à croire que tout n’est pas immuable en ce bas monde, et la conduite du changement est une chose aussi risquée qu’excitante. Tenter un portage à l’identique de l’existant afin de ne pas dépayser l’utilisateur n’est pas toujours une bonne idée. Bien souvent, la refonte ergonomique de l’existant et la formation des utilisateurs vous coûteront moins cher et vous fera perdre moins de temps que de tenter de plaquer un existant sur un média pour lequel il n’est pas fait. Ajoutez-y les économies réalisées par le gain de productivité engendré par l’optimisation des processus au sein de la nouvelle application, et la nécessité d’une réflexion de fond s’impose d’elle-même. Aussi, avant d’exiger une application 100% isométrique à l’existant, penchez vous sur l’équation suivante :

Coût du portage iso - (coût de la refonte ergonomique + communication sur le changement + formation des utilisateurs - économies après la hausse de productivité due à la refonte étalée sur 3 ans)

Si le résultat vous semble largement supérieur à 0, n’hésitez plus : repartez de zéro, ou presque, et à vos utilisateurs une application neuve, mieux adaptée à l’environnement web, plus belle et plus facilement utilisable. Ils vous en remercieront.

Une refonte de processus non plus d’ailleurs

On oublie trop souvent qu’une refonte ergonomique ne se limite pas à inscrire des interfaces à Relooking Extrême. Les applications web, et plus généralement les applications centralisant les données sur une unique plate-forme déportée – serveur de fichiers, serveur de base de données – et non sur le poste client permettent de dématérialiser et d’optimiser de nombreux processus.

Toute la difficulté réside alors dans une très bonne conduite du changement : évangéliser afin de créer une dynamique de groupe qui entraînera l’adoption des nouveaux processus par l’ensemble des acteurs concernés. Mais ceci est une autre histoire.

ne pas jouer avec le feu

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: