Introduction
Mon projet professionnel s’est fondé, il y a plus de 15 ans, sur un constat fait lorsque j’étais élève ingénieur. En raison de mon intérêt pour les IHMs, je m’orientais en dernière année vers une spécialisation en Interface et Communication Homme Machine. Grace à cela, je suivais quelques cours sur les technologies de développement de la couche de présentation. Un nouveau cours, optionnel cependant, faisait ouvrir de gros yeux à tout l’amphi : l’ergonomie logicielle. Grace soit rendue au jeune professeur qui tentait, en territoire manifestement hostile, de distiller l’importance du facteur humain dans les projets informatiques ! Son constat était pourtant limpide : l’outil informatique finit toujours par interagir avec l’être humain et une bonne part des coûts de développement sont imputables aux aspects IHMs. Pourquoi diable aucune véritable méthode de conception d’IHM n’est-elle enseignée à ceux qui vont les implémenter ?
Avec le recul, la situation n’a pas tellement changée et je constate, sur de nombreux projets, à quel point l’aspect IHM est, soit sous-estimé, soit géré de façon très artisanale. Certains, encore trop nombreux, pensent que l’IHM est un problème secondaire, facilement sous traitable, et finalement indigne de faire partie du cursus d’un ingénieur ou même d’un technicien supérieur. Non, l’IHM n’est pas un aspect qui s’improvise ou qui se résume à laisser un graphiste passer un coup de peinture. L’IHM est un problème complexe, au cœur de la valeur d’un logiciel. Je vais tenter d’expliquer pourquoi dans ce billet…
Une problématique à 3 dimensions
La première difficulté consiste à appréhender la problématique de l'IHM dans sa globalité, sans en oublier certains aspects.
Il y a trois facettes à adresser
La technologie : le côté Machine
Une IHM s'implémente, c'est à dire qu'elle se traduit in fine par des lignes de codes qui sont très dépendantes de la technologie utilisée (application web ou native, langage de développement, type de terminal à adresser).
Le codage de l'IHM représente une partie de code importante, souvent majoritaire dès lors que l'on souhaite avoir une expérience utilisateur avancée. D'une manière générale, plus les interactions sont complexes, plus les coûts de développements liés à l'IHM augmenteront. Souvent, on atteint des rapports 70/30, entre le code côté couche de présentation et celui côté serveur.
Il existe des exceptions notables, liées à la technologie utilisée. Il sera par exemple beaucoup plus simple de réaliser une IHM auto adaptative (responsive design) avec un développement Android natif que pour une application Web 1.0. De même, j'ai remarqué un saut de complexité, lorsqu'on passe d'IHMs orientées consultation vers des IHMs transactionnelles, c'est à dire avec une part de saisie importante.
Concrètement, l'IHM est implémentée par un ou plusieurs développeurs, rarement spécialisé sur les technologies liées à la couche de présentation et généralement avec peu d'expérience. En effet, en France, le statut de développeur est peu valorisé, un développeur avec plus de 5 ans d'expérience étant fortement invité à faire autre chose. De même, si en pratique, le développeur est spécialisé dans une ou deux technologies (Ex : Java, .Net), il a très rarement connaissance des règles d'ergonomie, parce qu'il n'a pas été formé pour. Pire, la plupart du temps, cet aspect ne l'intéresse absolument pas et il voit l'implémentation IHM comme une partie ingrate de son travail, préférant s'intéresser aux aspects back-office de l'application. Bien évidemment, il existe des exceptions, mais j'ai rencontré très peu d'experts techniques sur la couche de présentation.
L'argent étant le nerf de la guerre, minimiser le code de la couche de présentation est un enjeu de l'équipe de développement, et du chef de projet en particulier. L'aspect IHM étant un aspect mal maitrisé, l'équipe projet aura tendance à minimiser les risques, en simplifiant au maximum par rapport aux aspects techniques. C'est le fameux "on ne peut pas le faire", qui est avancé avec plus ou moins de bonne foi.
Côté relationnel, le développeur manifeste une tendance à la réserve, plus généralisée que dans d'autres métiers. Sa culture cartésienne, le conduit à poser le problème dans toute sa complexité avant d'avancer une solution qui doit traiter tous les cas possibles. Ceci explique la complexité des IHMs laissées aux seuls techniciens et conduit à une certaine résistance au changement, lorsque le besoin utilisateur évolue pendant le projet. Au final, on a souvent une équipe qui campe sur les spécifications fonctionnelles sans prendre d'initiative sur l'IHM. C'est dommage, car ce sont eux, qui, étant au plus prêt, sont le plus à même d'être force de proposition.
L'ergonomie : le côté Humain
De nombreux techniciens ont tendance à l'oublier, mais il y a un être humain derrière l'écran. Celui-ci fonctionne avec des codes très différents de la machine. Il est bien moins cartésien que le développeur qui a une formation scientifique. L’utilisateur ne voit l'application que par son IHM. Ce qui est le sommet de l'iceberg pour l'équipe de développement, représente l'essentiel pour l'utilisateur humain.
De même, l'utilisateur humain va raisonner en termes de service rendu par rapport à son activité alors que l'équipe de développement à un raisonnement orienté architecture, tournée vers les données. Plutôt que de se dire comment informatiser cette activité, le technicien a tendance à se demander comment présenter ces données. A cela, s'ajoute en milieu professionnel, le langage métier de l'utilisateur, peu compatible avec celui, très hermétique de l'informaticien. Tout concourt à un dialogue de sourd qui, de toute façon, n'a souvent jamais lieu !
Pourtant, concevoir une IHM, sans faire dialoguer ces deux mondes ne me semble pas concevable ! C'est précisément là que l'ergonome intervient, dans sa capacité à tenir compte à la fois des contraintes techniques, et de celles issues du facteur humain (physiologie, contexte d'utilisation, psychologie cognitive), pour produire une IHM réalisable. Dans un monde idéal, le choix du matériel et de la plateforme logicielle, résulterait d'une préconisation de l'ergonome par rapport à un contexte d'utilisation (Ex: pistolet à code barre pour une activité de ramassage). En réalité, le contexte hardware et software est souvent imposé : absence de budget pour financer du matériel, équipe de développement formée aux applications webs uniquement.
Bien souvent, l'ergonome sera le seul garant de la présence de l'utilisateur final dans le projet. On est ici à la frontière entre les sciences dures et les sciences humaines. Pour ma part, je pense que le traditionnel mépris des sciences dures envers les sciences humaines, n'est pas étranger à la difficulté de l'application de la démarche ergonomique dans les projets informatiques.
Contrairement au développeur dont on ne peut pas se passer, l'ergonome reste bien souvent en option sur les projets. C'est moins vrai dans les projets webs où l'ergonomie est immédiatement identifiée comme un enjeu majeur. Pour des applications internes, alors que les interactions sont souvent plus complexes et les fréquences d'usage plus importantes, l'ergonome est malheureusement rarement là. Quand il est présent, l'ergonome n'est pas toujours spécialisé sur le travail sur écran et intervient parfois trop tard dans le projet, comme caution ou bien comme pompier quand les utilisateurs râlent.
Le graphisme : le côté agréable à regarder
J'entends par graphisme tout ce qui concerne le rendu visuel des composants IHMs. Le terme de "skin" (peau en français) me semble la notion la plus proche : on peut changer de skin sans modifier le dialogue Homme/Machine. Techniquement parlant, il peut s'agir de feuilles de styles CSS pour une application Web ou d'un "look and feel" pour une application native.
Le graphisme nous fait entrer dans le monde de la subjectivité. Il y a une dimension artistique, dans la capacité du graphiste, à livrer des images, dont l'assemblage produira une impression positive ou négative. Quand on voit à quel point une application ayant quelques années parait vieillotte, on comprend qu'on entre dans le monde de la communication, avec des effets de modes, par définition cycliques.
Autant le couplage ergonomie/technologie est fort, autant le couplage du graphisme avec l'ergonomie et la technologie est plus faible. Attention, je ne dis pas qu'il est inexistant, mais il est me semble possible d'habiller ou de "rewamper" l'application en fin ou après son implémentation.
C'est parce que le graphisme est très souvent confondu avec l'ergonomie, que je refuse de produire des maquettes habillées graphiquement. Je n'en ai tout simplement pas le talent, sans oublier les biais induits en phase de maquettage : discussions sans fins sur les "gouts et les couleurs".
Pendant longtemps, j'ai tenu envers l'habillage graphique, le même discours que je reproche à certains techniciens envers l'ergonomie : un aspect secondaire. C'est une grave erreur, car l'impression véhiculée par l'application au premier coup d'œil (l'effet WAOUH) est essentielle. Chez un éditeur de logiciels, par exemple, c'est sur cela qu'un prospect se basera lorsqu'il établit une "short list" avant un achat. Tout simplement parce qu'il a très peu de temps pour évaluer les dizaines de logiciels sur le marché. La couverture fonctionnelle et la qualité de l'ergonomie, demandent un minimum de temps pour être évaluées. En généralisant, je pourrais également parler de la superficialité de notre société, où la forme est bien souvent privilégiée au fond...
La problématique IHM est pluridisciplinaire
On le voit, une approche exhaustive de la problématique IHM , amène à considérer ces trois aspects à la fois. Comme ils nécessitent des compétences très différentes, il faut a priori faire intervenir des personnes différentes : un graphiste, un ergonome, et au moins un développeur.
Mon retour d'expérience est que les projets où ces trois interlocuteurs sont effectivement représentés sont (très ?) minoritaires. Parfois, on a un graphiste mais pas d'ergonome : c'est l'application vitrine, très agréable à regarder mais pas forcément utile ni utilisable. Ce type d'application pullule en ce moment sur les plateformes mobiles (Exemple: voir cet article). Plus rarement, l'ergonome est présent mais le graphiste absent. Ces deux cas sont généralement la conséquence d'une confusion entre ergonomie et graphisme. Reste, le cas encore trop général : pas de graphiste ni d'ergonome. Soit il n'y a pas de maquette et la réalisation de l'IHMs est laissée au seul développeur, non formé pour, et qui fait ce qu'il peut. Soit une maquette est improvisée par un analyste et implémentée "au pixel près" par le développeur. Les cas d'improvisations complètes de l'IHM sont nombreux sur le terrain, y compris chez les grands comptes.
J'ai également pu constater un silotage des interventions, c'est à dire une absence d'interactions entre les différents acteurs. L'ergonome intervient quelques jours pour réaliser une maquette ou un audit en début de projet puis repart, laissant l'équipe technique démonter techniquement ses propositions. Idem pour le graphiste, qui propose des habillages graphiques avant même que l'équipe technique ne soit constituée. Plus généralement, les interlocuteurs IHM ne sont pas toujours du même côté dans le traditionnel conflit maitrise d'œuvre (équipe technique), maitrise d'ouvrage (graphiste et parfois ergonome).
Comment y remédier ?
La première solution sera la polyvalence. Mais les doubles, voir triples compétences, sont rares et souvent déconsidérées. Si l'on admet que le développeur soit en mesure d'implémenter sur tous les langages et sur n'importe quelle plateforme, un développeur s'intéressant à l'ergonomie sort de son domaine de compétence. Pourtant, n'y a-t-il pas davantage de cohérence s'il a choisit de se spécialiser sur la couche de présentation ?
La seconde solution consiste à faire parler tout ce petit monde, ce qui implique de les associer dans la même équipe projet. Des recouvrements sont possibles et même souhaitables. Les livrables du graphiste sont parfois fortement couplés à la technologie utilisée (Ex : nine patch sous Android). L'ergonome peut aussi moduler ses propositions en fonction des difficultés techniques de réalisation, allant vers le meilleur rapport ergonomie/coût. Les méthodes agiles me paraissent fournir le bon contexte pour mettre fin à ce silotage.
Conclusion
Dans un prochain billet, je me pencherais sous un autre aspect de cette complexité, à savoir le grand nombre d’inconnues d’une problématique IHM.
