Les interfaces web de saisie rapide

La désynchronisation des activités est l’essence même de Ajax, c’est le “A” dans “Ajax”. Ces derniers temps, on commence a utiliser le terme “Ajax” pour dire “XMLHttpRequest” ce qui était prévisible : personne ne peux dire “XMLHttpRequest” sans attraper le hoquet.

Comme vous le savez déjà nous sommes en train de développer un Progiciel de Gestion Intégré (PGI) pour un grossiste en pharmaceutiques en Tunisie. L’activité de grossiste pharmaceutique est très particulière pour deux raisons :

1. le secteur pharmaceutique est relativement ancien et bien développé ce qui fait qu’il y a des “traditions”
2. le secteur pharmaceutique est très régulé pour des raisons de santé publique évidents

L’une des particularités du secteur c’est le traitement d’un nombre de commandes élevé dans une plage horaire très restreinte. Pour vous donner un ordre d’idée, ici, on traite à peu prés 900 commandes par jour dont 400 entre 11h et 13h. Il faut donc une logistique adéquate.

L’une des difficultés évidentes que nous avons identifiée depuis le début de projet, c’est l’interface de prise de commande qui allait être utilisée par les commerciaux. Les commerciaux sont généralement très peu connaisseurs en informatique : ils sont là pour appeler les clients au téléphone et saisir leurs commande le plus rapidement possible, par conséquent le niveau d’instruction est secondaire. Cela dit, vu la nature de leurs activité, ils maîtrisent parfaitement le logiciel qu’ils utilisent maintenant. Ils ont même développé des réflexes et des automatismes liés aux touches de fonction.

Quand nous avons présenté l’interface de prise de commande la première fois, nos interlocuteurs avaient des doutes. Pourtant la nouvelle interface etait loin devant l’ancienne en terme de fonctionnalités et même en terme d’ergonomie. Nous avons donc corrigé quelques détails par-ci par-là et donné l’application aux utilisateurs finaux pour la tester.

Le verdict fut unanime : la recherche des articles est trop lente. Quand vous cherchez un article dans les 7991 références, notre système met 300ms à répondre. Ce qui était beaucoup trop. Après avoir observé pendant une heure le plus expérimenté des commerciaux travailler sur l’ancienne application, j’ai été convaincu.

Après avoir étudié le problème et essayé différentes solutions, il n’y avait rien à faire : toute l’interface était à refaire. La seule solution était de grignoter sur les 300ms et pour cela il fallait reconcevoir l’interface.

La saisie d’une ligne de commande se passe comme suit :

1. L’utilisateur saisi les premières lettres de l’article recherché
2. Le système lui présente une liste d’articles qui correspondent à sa recherche
3. Il sélectionne l’article qu’il veut
4. Il saisi la quantité commandée
5. Il recommence

Pour bien faire son boulot l’utilisateur a aussi besoin de feedback. Il a besoin de savoir quelle est la quantité disponible en stock et d’être notifié en cas d’erreur (article mal saisi, etc…). Dans le système tel qu’il était conçu, il y avait une seule requête, ce qui nous avait semblé être un bon choix quand on avait conçu l’interface. La logique étant que 1 seule requête (Ajax) prend toujours moins de temps que plusieurs. Mais à y regarder de plus prés, l’activité pour laquelle on conçoit l’interface a une particularité qu’on peut exploiter : quand l’utilisateur veut vraiment (vraiment!) aller rapidement, il ne regarde pas la quantité disponible, il n’a pas le temps.

Ce que nous avons fait c’est séparer la consultation de la disponibilté en stock de la recherche d’article. En fesant cela nous avons gagné du temps doublement :

• d’abord nous n’affichons la quantité disponible que pour l’article séléctionné et non plus pour tous les articles retournés par la recherche, ce qui décharge le serveur.
• ensuite nous avons désynchronisé cette activité (remarquez les barres de synchro dans le diagramme) ce qui fait qu’elle se fait maintenant en parallèle avec la saisie de la quantité et donc ne prends plus de temps.

Cette nouvelle conception nous a permis de faire tomber la réponse du système à 30ms, et de réduire la responsivité perçue par l’utilisateur par – a vue de nez – un facteur 100. Notez aussi que nous n’avons pas fait que désynchroniser la consultation de la disponibilité en stock, nous avons aussi désynchronisé tous les autres feedbacks du système y compris l’affichage de la ligne saisie elle même (remarquez les 3 points de fin d’activité).

La désynchronisation des activités est l’essence même de Ajax, c’est le “A” dans “Ajax”. Ces derniers temps, on commence a utiliser le terme “Ajax” pour dire “XMLHttpRequest” ce qui était prévisible : personne ne peux dire “XMLHttpRequest” sans attraper le hoquet. Certains disent même qu’on fait tout et n’importe quoi avec Ajax et en fait ils veulent dire qu’on fait tout et n’importe quoi avec “XMLHttpRequest”. Je ne le pense pas. Je pense que “XMLHttpRequest” ne peux pas faire de mal, même s’il est utilisé n’importe comment.

Nous sommes actuellement en train de tester la nouvelle interface avec les utilisateurs et vous savez quoi? Aucun feedback. Ils disent rien les utilisateurs. Ils utilisent l’application comme si tout allait de soi. Comme s’ils l’utilisaient depuis toujours. Et je me dis que faire des logiciels pour entreprise a cette différence par rapport à faire des applications grands public : l’efficacité prime sur l’effet. On n’est pas la pour faire du buzz, on ne veut impressionner personne. Et effectivement les utilisateurs ne sont pas impressionnés … mais ils ne se plaignent pas. Et c’est ça notre récompense.