Ergonomie, Rails et Architecture de l'information web (2.0)

Ça fait un moment maintenant que je voulais écrire sur l’excellent schémas d’Éric Burke, qui met face à face les produits Apple et Google et les applications d’entreprise. Bien que cruel et un peu caricatural, ce dernier révèle pourtant une situation bien souvent vraie, et révélatrice de deux grands travers de la conception logicielle : la trop grande complexité des processus avec, comme corollaire, le trop plein de fonctionnalités.

À 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.

Vous avez développé une petite application pour vos propres besoins, par exemple un outil de publication en ligne. Des gens l’ont remarquée et ont commencé à s’y intéresser, au point que vous la publiiez sous une licence quelconque, pour le plus grand bien de la communauté. Et un jour, ce qui allait très bien pour une seule personne ne suffit plus, et vous décidez de franchir le pas : rendre votre application multi utilisateurs. Belle initiative, mais par où commencer ?

Quels utilisateurs ?

Commencez par remettre à plat l’ensemble des fonctionnalités de votre outil. Recensez chacune d’entre elles et classez les par groupe en fonction des utilisateurs “type” qui seront amenés à les utiliser.

Dans notre cas, nous séparons les fonctionnalités de l’application en 3 groupes distincts :

L’administration

• La configuration.
• Le paramètrage du thème.
• La sélection des greffons.
• La gestion des utilisateurs.

La publication

• La gestion / publication des billets.
• La gestion des catégories.
• La gestion des média.
• La modération des commentaires.

La contribution

• Ajout de commentaires.

Et voilà, nous avons défini 3 profils types, et défini leurs attributions possibles. Nous aurions pu en définir plus, par exemple un rédacteur qui aurait des droits d’écriture mais pas de publication, ou un modérateur pour les contributions qui n’aurait pas de droits en écriture, mais nous choisissons la simplicité. Reste maintenant à l’implémenter dans notre application, et là, deux choix s’offrent à nous.

Implémentation par profils

L’implémentation par profils est la plus simple à mettre en oeuvre, au détriment de la souplesse. On attribue un profil à chaque utilisateur, puis, pour chacune des actions possibles, on contrôle le profil de l’utilisateur, et on agit en conséquence. Pour cela, on va créer 3 méthodes, vérifiant que l’utilisateur dispose bien du profil voulu :

Vous remarquerez que pour chaque profil inférieur, on vérifie également que l’utilisateur dispose du profil supérieur. En effet, on considère que les utilisateurs hiérarchiquement les plus élevés disposent de fait des droits les plus bas.

Implémentation par droits

Beaucoup plus complexe à mettre en place, l’implémentation par droit est en revanche extraordinairement souple. Elle ne convient cependant pas à n’importe quelle application car elle a son petit effet “usine à gaz”, vous pèserez donc bien le pour et le contre avant de la mettre en place.

Le principe est simple : vous définissez une série de droits ; chacun de ces droits correspond à une action possible sur l’application : créer une catégorie, modifier un billet, effacer un commentaire, afficher la liste des utilisateurs… Vous remarquerez au passage que ce système de droits repose sur le CRUD (Create, Read, Update, Delete) et trouve tout à fait sa place dans une application RESTful, mais je m’égare. Une fois définis les droits, vous créez les profils fonctionnels que nous avons vus tout à l’heure, et vous leur attribuez les droits qui vont bien. L’administrateur les aura à priori tous, le contributeur n’en aura que très peu. Pour cela, faites un tableau de correspondance entre les deux. Il y a d’ailleurs de fortes chances pour que vous ayez le même dans votre application :

Droits	Administrateur	Rédacteur	Contributeur
Créer un billet	X	X
Ajouter un utilisateur	X
Ajouter un commentaire	X	X	X

Vous assignez ensuite un profil à chaque utilisateur. Pour chaque action possible, vous vérifierez que l’utilisateur dispose bien du droit adéquat. Pour cela, on va créer une méthode toute simple :

Deux choses rendent cette implémentation par droits formidablement souple :

• Vous pouvez ajouter autant de profils que vous le souhaitez, puisque ceux-ci ne sont que des conteneurs à doits. Les droits sont en effet liés à l’utilisateur et le profil ne sert qu’à les grouper.
• Vous pouvez très facilement surcharger un profil en attribuant ou supprimant des droits à un utilisateur spécifique.

Et maintenant ?

Il ne vous reste plus qu’à vous mettre au travail, en réfléchissant bien à ce que vous souhaitez faire de votre application. Chaque système a ses avantages et ses inconvénients, et passer de l’un à l’autre est tout sauf évident.

Et pour ceux qui pensent que ce billet est une réflexion sur ce que pourrait devenir Typo dans un futur proche, vous vous trompez. 50% du code est déjà fait, il me reste à le propager à l’ensemble de l’application.