Aller directement au contenu

Y a-t-il un usager dans la salle ?

25/02/2009
1

Ergonomie-Ouvrage-UsabilisJ’ai la nette impression que le monde informatique évolue beaucoup plus lentement qu’il ne le pense. Je me rends compte que c’est un domaine très jeune comparé à d’autres comme le monde automobile par exemple. D’ailleurs, cela ne viendrait à l’idée d’aucun constructeur de mettre en vente ses voitures sans s’être assuré qu’il y a avait un réel besoin pour son modèle, et sans l’avoir testé et retesté. Et nous, dans le monde informatique, on continue à dire que ces analyses de besoins et ces tests utilisateurs ne sont pas essentiels, que ça coûte cher, que ça prend du temps, et j’en passe.

Retour en arrière.
J’ai en mémoire le projet d’un client sur une application dédiée aux ressources humaines. L’objectif était d’installer un nouveau système au sein d’un important groupe permettant de gérer tous ses processus RH. Population concernée : plus de 120 000 personnes à  travers le monde…
18 mois après le début du projet et quelques mois après les premières mises en ligne, on m’appela pour comprendre ce qu’il se passait avec ‘certains usagers’ qui auraient des difficultés d’usages…

Proposition d’une méthode « traditionnelle«  :
– analyse experte, basée sur les usages identifiés au sein du groupe ;
– entretiens d’observations sur sites avec les différents types d’usagers pour mieux comprendre leurs contextes d’usages, et surtout leurs activités et besoins réels
– tests utilisateurs avec les différents profils d’usagers
– prototypage fonctionnel incluant les recommandations ergonomiques
– charte ergonomique

Anecdote principale : En écoutant la synthèse de ce que faisaient réellement les usagers, leurs besoins et enjeux réels, l’équipe projet était abasourdie. Le décalage entre ce qui a été formalisé par des « groupes de travail experts métiers«  et la réalité du terrain était abyssal. La fameuse différence entre le travail prescrit et le travail réel ! Par ailleurs, le système développé était principalement une liste de fonctionnalités, sans réels regroupement des contenus et fonctionnalités par processus et activités fondamentales. Les usagers devaient donc, à grand frais cognitifs, se construire une représentation mentale du système afin de réaliser le mieux possible leurs activités au quotidien.

Conclusion du client : beaucoup de temps et d’énergies pour discuter de détails métier, sans s’assurer que les fondamentaux, les usagers finaux, soient suffisamment considérés.

Fin de l’histoire : le client était finalement ravi de la démarche et décida d’inclure un ergonome dans chaque nouvelle phase de son projet. L’objectif étant de toujours confronter les besoins réels des usagers avec la vision des experts métiers du groupe, responsables des cahiers des charges de chaque projet…

Note : gain de temps, d’efficacité, de validité, de performance…une méthode « traditionnelle » qui a finalement du bon dans le monde informatique, vous pensez-pas ?

Un commentaire

  • guillaume dit :

    Quelques points en complément
    D’une part ne pas oublier le change management : il m’est arrivé a de nombreuses reprises d’être envoyé pour un déploiement applicatif sans que les utilisateurs soient vraiment suivis, soit parce que cela n’avait pas été budgété dans le projet, soit que l’euphorie du déploiement après quelques années de développement avait mis cette tâche aux oubliettes.

    Une fois j’ai été appelé suite à un déploiement pour aider les utilisateurs à comprendre l’application qui leur avait été livrée, je devais rester deux semaines pour faire quelques formations aux managers et aux trainers, finalement je suis resté six mois, car le changement était si drastique que les utilisateurs étaient perdus, dix ans d’habitude de travail balayés du revers de la main comme une miette sur une table…

    D’autres part et souvent dû a une mauvaise compréhension du management, les ergonomes ont été les premiers à être coupés suite a des réductions budgétaires

    ou encore sur un projet récent, l’équipe de management nous a demandé de ne pas parler aux utilisateurs tant que le dev n’était pas fini, de peur de nouveaux besoins

    un analyste d’affaire doit souvent utiliser cette méthode traditionnelle pour faire avancer la business, et je pense l’avoir utilisé systématiquement sur tous mes mandats

Laisser un commentaire