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

Tout projet un tant soit peu sérieux qui se respecte tombe un jour ou un autre sur le bug stupide, ultra bloquant dans certaines circonstances improbables mais fortement susceptibles de se produire par la faute de l’interface chaise / clavier, et tout simplement impossible à corriger. Et qu’il s’agisse de Trac, Bugzilla ou toute autre solution maison, tout projet quelque peu conséquent utilise un outil de rapport de bugs permettant d’en suivre le cycle de vie de l’apparition à la fermeture, et, le cas échéant, de générer de jolis rapports de résolution de bugs à destination du client qui voit ainsi la fiabilité de son application s’accroître avec le temps.

Il y a quatre ans de cela, je travaillais en tant que prestataire sur le logiciel de gestion clientèle de notre principal fournisseur d’énergie. Il s’agissait d’une gigantesque usine à gaz en J2EE dont la moindre page mettait bien 4 ou 5 bonnes secondes à s’afficher. Le changement de valeur d’un menu déroulant permettait de rafraîchir le contenu d’une de ces pages, provoquant la fameuse latence sus citée.

Un jour, j’eus la fâcheuse idée de sélectionner le menu déroulant en question, et de donner un grand coup de roulette sur ma souris. Résultat : plantage pur et simple du serveur d’application Weblogic, et obligés de redémarrer le serveur Sun – une bête de course – sur lequel était hébergé l’application. Plein de zèle, je remplissais donc un rapport de bugs détaillé et circonstancié, niveaus de criticité et d’urgence maximums. Une seule solution pour résoudre ce bug : intercepter ou désactiver la molette de la souris depuis Internet Explorer.

Retour de la fiche une petite heure plus tard au statut “clos rejeté”, avec pour raison de la clôture les postes de travail du client sont équipés de souris à 2 boutons sans molettes, bug inapplicable en grandeur réelle.

Classe, j’te dis classe