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

J'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 ?