Il paraît inconcevable aujourd’hui qu’un projet web (site business, portail corporate, intranet institutionnel, …) ai lieu sans le concours d’un Directeur Artistique et de son équipe. Le travail qu’ils vont mener sur le design, l’ergonomie et plus généralement l’utilisabilité du site est en effet primordial pour garantir l’adéquation des choix de présentation et de navigation avec les utilisateurs ciblés.
En revanche, lorsqu’il s’agit d’applications métier, je me demande parfois si nous vivons sur la même planète ! En effet, il est très rare que ces architectes de l’information soient associés à un projet d’applicatif métier (même lorsqu’il s’agit d’un projet intranet donc web) bien qu’il y ai le même besoin final : que l’application soit utilisable par ceux à qui elle est destinée.
Je vous livre donc ici mon plaidoyer en faveur de la création au sein de chaque DSI d’une Direction de l’Architecture de l’Information, intégrant des ergonomes, architectes de l’information, webdesigners / infographistes, taxonomistes, intégrateurs html, …
J’ai assisté récemment dans le cadre d’un des projets que j’accompagne à une réunion qui m’a donné le sentiment de vivre sur une autre planète. Sans rentrer dans un niveau de détails qui risque de ne pas vous passionner, je vais partir de cet exemple pour illustrer les 4 points de mon plaidoyer, quitte à légèrement édulcorer romancer certains passages (pour le bien de la cause bien sur).
Intégrer le design et l’ergonomie en début de projet, c’est gagner du temps.
Le but de cette réunion pour la DSI était de faire valider à la maîtrise d’ouvrage la nouvelle proposition d’IHM de sa future application, revue et corrigée suite à ses premiers retours. Jusqu’ici tout semble normal, car il vous manque l’information principale : cette réunion a eu lieu alors que le projet était dans sa dernière ligne droite…
Ce cas particulier pose la question suivante : comment faire pour éviter de se retrouver face à un tel mur alors que le projet est déjà trop bien avancé ? La réponse est finalement assez simple : en travaillant dès le début du projet sur le visuel de l’interface, ses règles de navigation et d’ergonomie, les limites associées, … Présenter des mock-up, les enrichir pour ensuite les stabiliser est le meilleur moyen pour réduire le risque d’avoir des surprises de dernière minute lorsque la MOA « touchera » pour la première fois son application. Comme le fait très justement remarquer Benoit Drouillat dans la préface du livre d’Amélie Boucher « Ergonomie web illustrée, 60 sites à la loupe », en France, la perception et la place de l’ergonomie dans un projet sont trop souvent associées aux actions correctives […] dans une temporalité séparée voire décalée.
Hors un travail mené en parallèle durant les premières étapes du projet et adapté régulièrement au fur et à mesure du projet ne peut qu’apporter plus de pérennité aux choix finaux tout en améliorant l’utilisabilité de l’application. Par ailleurs, plus le projet avancera, moins il y aura de liberté de manœuvre car il faudra tenir compte des choix techniques effectués et des développements déjà réalisés qui comporteront alors, et c’est normal, leur lot de contraintes imposées.
Travailler sur l’architecture de l’information de l’application dès le début du projet c’est enfin éviter les changements de cap en cours de projet. Ces derniers sont couteux tant en temps qu’en budget, car ils obligent à de multiples itérations bien plus longues que si elles avaient eu lieu au démarrage et génèrent des tensions inutiles.
Travailler avec des professionnels, c’est gagner du temps.
La nouvelle proposition d’IHM utilisait des barres de défilement verticales « imbriquées » (une pour un des blocs de contenu, une pour le contenu de la page), rendant impossible le scroll jusqu’en bas de la page sans passer par l’une ET par l’autre. C’est un problème ergonomique que l’on rencontrait à l’époque des frames en pur html, fortement pénalisant pour l’utilisateur mais heureusement très rarement rencontré aujourd’hui. Cet effet de bord était lié à un choix technique qui résolvait un besoin fonctionnel important, mais au détriment de l’utilisabilité, sans que la MOE ne s’en aperçoive (question de résolution d’écran).
Définir l’architecture de l’information par un mélange de couches successives issues des demandes de niveau macro des maîtrises d’ouvrage, des « solutions » proposées par les équipes techniques pour coller à leurs contraintes de dev tout en tentant de répondre au mieux au besoin macro initial et d’un mix de l’ensemble en fin de projet ne peut être optimal. Le résultat ne sera pas à la hauteur, et cette méthode entrainera une perte de temps énorme, non que les équipes techniques soient incompétentes en la matière ni que les MOA soient à coté de la plaque, simplement parce que ce n’est pas leur métier.
Il nous apparaît à tous évident que de découper les tâches et les répartir par compétences est une méthode d’optimisation qui a fait ses preuves (c’est même de l’ordre de l’enfonçage de porte ouvertes). Ça ne viendrait à l’idée de personne de confier la réalisation des plans de sa maison à son maçon, il y a des architectes pour ça. Bien sur le maçon pourra apporter des remarques pertinentes du fait de son expérience, de même que le maître d’ouvrage pourra apporter des idées et une vision. Mais tout ce beau monde s’appuie sur l’architecte pour donner corps à tout cela sous forme de plan.
Alors pourquoi laisser aux MOA, aux équipes techniques et aux autres acteurs projets la responsabilité d’un domaine pour lequel il existe quantité de professionnels compétents ?
Le temps que la MOA passera ainsi sur ce sujet sera optimisé et elle pourra se consacrer au maximum à son cœur de métier, assurant par là l’adéquation fonctionnelle de l’application. Le temps que les équipes techniques passeront sur le sujet sera là aussi bien moins important, ce qui leur permettra de mieux approfondir les questions techniques. C’est la même chose pour chacun des acteurs projets. Il s’agit d’optimiser le temps de chaque acteur projet pour qu’il puisse se consacrer en majorité à des tâches à forte valeur ajoutée par rapport à ses compétences.
Apporter une cohérence visuelle, c’est donner du sens.
N’oublions pas non plus que le résultat apportera une cohérence globale à toutes les applications sur lesquelles notre utilisateur va devoir travailler durant sa journée. Et autant dire que lorsque l’on voit le nombre d’applications utilisées par jour par un employé lambda, cette cohérence globale ne peut avoir qu’un effet positif !
En travaillant ainsi sur chaque application on fait percevoir à l’utilisateur le fait qu’elles s’inscrivent dans un ensemble : le SI de l’entreprise qui prend ainsi tout son sens, et que ce dernier est à son service et a pour but de lui simplifier la vie, ce qu’il constate en jonglant aisément d’une application à l’autre.
Réussir un projet, c’est apporter de la satisfaction à l’utilisateur final.
On l’oublie trop souvent, mais un projet n’a de sens que si l’application apporte de la satisfaction à l’utilisateur final. A quoi bon fournir une application qui remplit son rôle fonctionnel mais qui n’est pas du tout orienté utilisateur ? Passeriez vous le plus clair de votre temps sur une application mal fichue ? moi non. Trouveriez vous plus agréable une application répondant au besoin métier mais aussi pensée pour être utilisée par vous de la façon la plus simple qui soit ? moi oui. Et ne me dites pas que l’utilisateur n’a qu’à s’adapter, car vous savez aussi bien que moi que certes, il le fera, mais au détriment de sa motivation. Et entre deux entreprises similaires, des employés motivés font toute la différence !