ALIXSYS

Yet Another Why Google Should Buy Twitter. Ces derniers temps la mode et aux articles expliquant pourquoi Google devrait racheter twitter. J’ai décidé d’ajouter ma petite pierre à l’édifice.

Si vous êtes un utilisateur de twitter, vous avez peut être eu l’occasion de ressentir un “twitter moment”. Un twitter moment, c’est quand vous réfléchissez à haute voix sur twitter et qu’une voix étrangère vient corroborer vôtre réflexion. C’est déroutant. Déroutant mais jouissif. Par exemple : Vous dites “J’attend le bus depuis 30min, je vais être en retard” et une voix étrangère @taxidriver vous répond immédiatement : “Je viens vous chercher?”. Vous ne connaissiez pas @taxidriver auparavant, mais il va vous rendre immédiatement service.

Il est important de souligner ici la différence dans l’expérience utilisateur entre Google et twitter. Dans Google il faut chercher une information, même formuler une recherche. Dans twitter il vous suffit de communiquer votre état pour que des options vous soient présentées. C’est comme si il suffisait d’y penser. En tout cas ce n’est pas très loin.

Cette faculté de télépathie c’est la force de twitter. Si on l’analyse, on trouve que cette force trouve ses racines dans la dissymétrie entrée/sortie dans les systèmes d’information. L’entrée d’information et la sortie (consultation) d’information ont des fonctions et des propriétés totalement différentes dans un même système; quelque soit le système. C’est ainsi que toute la valeur ajoutée fournie par le système se concentre dans la sortie d’information. Il n y a aucune valeur ajoutée dans l’entrée d’information. Absolument rien. Un système d’information doit tendre vers un système idéal qui ne demande aucune entrée. Un système qui devine vos pensées.

Cette dissymétrie a de profondes implications sur tout le système. Par exemple, dans la plupart des applications, l’entrée n’a pas le même niveau de sécurité que la sortie d’informations. Vu qu’il n y a aucune valeur ajoutée a l’entrée d’information dans un système précisément, le niveau de sécurité de l’entrée d’information pourrait être très bas si le contexte le permet. En d’autres termes si votre système opère dans un contexte ou personne ne va chercher a fausser sciemment vos données, vous pouvez carrément mettre le niveau de sécurité au plus bas. Vous pouvez ne pas demander d’authentification pour les interfaces de saisie.

Cela dit définir un niveau de sécurité pour une interface utilisateur n’est pas si simple, puisque dans son interaction avec le système, l’utilisateur a besoin de feedback et donc de sortie d’information. Les interface utilisateur sont donc composites. Mais ce n’est pas une obligation, c’est à vous de voir.

J’utilise buxfer pour gérer mes petites dépenses. La consommation d’essence de ma 4L, les factures, etc… Pour saisir mes dépenses depuis mon vieux Nokia 6610i j’envoyais un mms a une adresse secrète. Jusqu’au jour ou Tunisie Telecom désactive le mms to mail sans aucune raison ni notice et que je me trouve obligé d’utiliser l’interface web mobile du service. Après quelques mois d’utilisation, je peux dire que ce n’est pas une solution idéale pour mes besoins. Le système m’oblige à m’authentifier trop souvent et c’est très pénible avec mon clavier 12 touches.

Je me suis dit que mes besoins sont très simples, que je n’ai pas vraiment besoin de représenter mes dépenses sous forme de camembert 3D tous les jours, et que ça serait mieux si je me faisais mon petit service sur mesure.

Ce dont j’ai besoin :

• Sélectionner une catégorie de dépenses le plus rapidement possible, sinon ça m’emmerde et je le fais pas
• Saisir un prix et un libellé optionnel le plus rapidement possible, sinon ça m’emmerde et je le fais pas
• Une fois par siècle, je consulte un état structuré de mes dépenses si possible manipulable avec un tableur

L’idée c’est que je ne vais pas demander un mot de passe pour saisir les dépenses, je vais juste demander un email comme identifiant. Quand vous voulez un état vous n’avez qu’a indiquer un email et l’état est envoyé a l’email en question. Voila pour la sécurité. A vue de nez le niveau de sécurité est amplement suffisant pour ma petite application. On verra à l’itération suivante si je devrais combattre le spam.

Je me suis donc retroussé les manches et le résultat c’est FLOOS essayez la sur votre téléphone portable (ça marche aussi sur votre ordinateur, mais ça n’a pas beaucoup d’interet). Et pour vous prouver à quel point je fais confiance au niveau de sécurité que j’ai établi pour l’application voici le code source de FLOOS. Si vous trouvez des bugs, ne soyez pas avare, c’est par ici les bugs : bugs FLOOS.

Les systèmes automatiques sont faits pour effectuer des opérations complexes tout en cachant la complexité a l’utilisateur. Si on ne fait pas attention en les concevant, ils cachent aussi la responsabilité. Pour pallier a ce problème, souvent, on ajoute des fonctionnalités de traçabilité : historiques et autres artefacts. Alors qu’il serait beaucoup plus effectif de concevoir le système dés le départ de façon à garder la responsabilité proche de l’utilisateur.

La responsabilité à un cout. C’est une sorte de taxe qu’on paie sur tous les produits qu’on en soit conscient ou pas. Quand elle est inscrite sur la facture, la responsabilité porte souvent le libellé : “Frais de gestion” ou “Assurance qualité”. Mais souvent, elle est sous évaluée. Bien évaluée, la responsabilité représentera probablement plus que 30% de la facture. Prenons un pain par exemple : c’est de l’eau, de la farine et du travail du boulanger. Dans le prix du pain, il y a le cout de la responsabilité du boulanger qui doit s’assurer que le pain est commestible et qu’il est de bonne qualité. D’ailleurs c’est principalement pour cela que les boulangers ne se valent pas. Mais il y aussi le cout de la responsabilité des services d’hygiène nationaux qui vérifient que les normes sanitaires sont respectées. Il y a le cout de la responsabilté de celui qui a vendu la farine et de celui qui a vendu l’eau et celui qui a loué le local. Chaque fois qu’il y a travail, il y a responsabilité et il y a un cout.

Maintenant, la responsabilité liée à un produit est fixe, elle ne peux pas être diminuée. Et la responsabilité ne se donne pas, elle se prend. Chacun est libre de prendre autant de responsabilité qu’il le désire. Mais pour l’acheteur, plus le vendeur prend de responsabilité moins il doit en prendre lui même. Parce qu’il faut bien que quelqu’un la prenne. Aussi plus de responsabilité engagée dans un produit est le seul argument de vente valable pour justifier d’un prix relativement élevé. Cet argument est souvent abusivement formulé : “meilleure qualité”. La qualité d’un produit c’est palpable, ce n’est pas un argument de vente. Et si le produit n’existe pas encore - le cas d’un logiciel ou d’une architecture - c’est qu’on parle d’assurance qualité et non pas de qualité. Et l’assurance c’est précisément le produit de la responsabilité. Il y a des vendeurs de responsabilité pure. Ça s’appelle les sociétés d’assurance.

A l’inverse, l’acheteur peut avoir une idée de la quantité maximale de responsabilité engagée dans un produit avec un calcul aussi simple que “30% de la facture” à titre d’exemple. Si vous achetez un jouet a 5 dinars, la responsabilité maximale engagée dedans est de 1.500 dinars. Le reste c’est vous qui l’assumez, alors ne le donnez pas a un enfant.

L’autre jour, je me suis arrêté a un passage à niveau et j’ai attendu. J’ai attendu jusqu’à me rendre compte que le passage à niveau était probablement cassé : c’était une fausse alerte, “False Positive” en anglais, il n’y avait pas de train. A ce moment là je me suis demandé si le passage à niveau ne demandait pas une intervention humaine pour fonctionner. Le chauffeur aurait il oublié d’appuyer sur le bouton pour lever la barrière? Et c’est très dangereux. Tous les experts en sécurité vous le diront : une fausse alerte est presque aussi dangereuse qu’une vraie alerte. La preuve, j’ai contourné la barrière pour traverser. Si le même problème s’était reproduit encore une ou deux fois, j’aurais probablement pris l’habitude de contourner la barrière et je me serais probablement fait écraser un jour ou l’autre. Ne vaudrait il pas mieux avoir des systèmes automatisés pour ce genre de chose? Un capteur sur les rails et un déclenchement automatique et on n’en parle plus.

Non. C’est une question de responsabilité. Je ne m’y connais pas en passages à niveau, et après une petite recherche sur internet à ce sujet, je ne suis toujours pas en mesure de vous dire si c’est automatique ou manuel. Mais il serait probablement plus judicieux qu’ils soient manuels et assistés. Les systèmes automatiques, y compris les systèmes informatiques, ont une fâcheuse tendance à éloigner la responsabilité de l’utilisateur. Les systèmes automatiques sont faits pour effectuer des opérations complexes tout en cachant la complexité a l’utilisateur. Si on ne fait pas attention en les concevant, ils cachent aussi la responsabilité. Pour pallier a ce problème, souvent, on ajoute des fonctionnalités de traçabilité : historiques et autres artefacts. Alors qu’il serait beaucoup plus effectif de concevoir le système des le départ de façon à garder la responsabilité proche de l’utilisateur.

A ALIXSYS nous construisons des progiciels de gestion. Ce sont des applications critiques et nos clients nous demandent souvent de :

• “verrouiller”
• ajouter des contrôles
• diminuer des droits d’accès
• demander des confirmations à l’utilisateur
• etc…

Tout se passe comme si nos clients faisaient plus confiance au logiciel qu’aux utilisateurs, y compris eux mêmes. C’est que les erreurs humaines ont souvent des conséquences graves et il est tellement facile de faire en sorte que le logiciel les empêche… à première vue. Vue de notre bout de la lorgnette, la situation est différente :

1. Le système ne peux en aucun cas empêcher l’erreur humaine.
2. Le système est là pour donner du pouvoir aux hommes, pas pour les brider. Du pouvoir de faire des choses qu’ils ne pouvaient pas faire sans.
3. On préfère que les hommes se trompent plutôt que le système.

Oui. On préfère que les hommes se trompent plutôt que le système. C’est une question de responsabilité. Quand un utilisateur se trompe, on ne l’en empêche pas, on essaye de savoir pourquoi il s’est trompé. Dans 50% des cas c’est notre logiciel qui est en cause; mais dans 50% des cas c’est la procédure qui est en cause. C’est aussi notre métier de savoir quand un problème n’est pas de notre compétence et d’en informer le client. C’est le conseil. Quand c’est notre logiciel qui est en cause, dans presque tous les cas, le problème est dans l’interface utilisateur et il y a une meilleur solution que de limiter la liberté de l’utilisateur. Il suffit de changer la position d’un bouton, pour que plus personne ne clique dessus par erreur. Il suffit de changer le libellé d’un champ de saisie de chiffre, pour que plus personne ne tape des lettres dedans.

Quand le système se trompe, qui porte la responsabilité à votre avis? Oui, c’est nous. Et qui paie? Oui, le client. La responsabilité liée à un produit est fixe, on a dit. Alors à ALIXSYS, nous préférons que ça soit le client qui la porte quand c’est possible. Après tout, en déléguant la responsabilité, il ne délègue pas le risque (l’histoire de la responsabilité et du risque, je vous la raconterais peut être une prochaine fois). Alors c’est tout benef pour lui aussi. Avouez que c’est cocasse comme manière d’être compétitifs sur nos prix. D’aucuns tapent dans l’assurance qualité pour diminuer leurs part de responsabilité, nous ce qu’on fait c’est concevoir des systèmes où la responsabilité est d’emblée déléguée à l’utilisateur.

Voilà. Vous connaissez notre secret. Bossez maintenant.

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.