Suis-je un mouton à cinq pattes ?

L'idée de ce billet m'est venu suite à la parution d'une annonce recherchant un développeur C# avec des compétences en design/ergonomie. Elle a donné lieu à des échanges passionnés sur la liste ergoIHM, les uns raillant ces sociétés à la recherche de profils qui font « papa maman  » tandis que les autres se lamentent de la méconnaissance persistante du métier d'ergonome. Au lieu de chercher des moutons à cinq pattes, laissons les développeurs développer et les ergonomes analyser l'activité.

J'aurais bien aimé adhérer à cette classification rassurante si je ne m'étais senti directement visé.

Je fais en effet parti de ces rares olibrius qui, après une formation purement technique, ont eu l'outrecuidance de se tourner vers l'ergonomie. Après cette double formation suivie de 15 années de pratique en conception en implémentation d'IHM dans des contextes variées (SSII, grands comptes, PME, éditeurs), voici l'occasion de faire un retour d'expérience et de me remettre en cause.

Suis-je donc devenu un mouton un cinq pattes ? Que m'apporte donc l'ergonomie dans mon métier de développeur ? A moins que ce ne soit l'inverse ?

Pas n'importe quel développeur

Tout d'abord, il existe aussi des a priori sur le métier de développeur, qui sont malheureusement aussi véhiculés par des ergonomes.

Le développeur n'est pas un ouvrier spécialisé de la programmation, capable de pisser des lignes de code par unité de temps, quel que soit le langage informatique ! La vitesse d'évolution des technologies est telle qu'il est impossible de maîtriser toutes les façons de coder. On observe donc des spécialisations suivant :

•  l'écosystème: Microsoft (.net, Windows Phone), Oracle/Google (Java, android),  progiciels (SAP, X3, …)
• l'architecture applicative : front-office (architecture client  : IHM webs ou natives), back-office (architecture serveur  : modèle métier, base de données, EAI...)

En France, le métier de développeur est largement dévalorisé, car présenté comme un passage obligé, mais transitoire, pour les jeunes ingénieurs. Bref, pour faire partie de l'élite de demain, il est recommandé de passer chef de projet en moins de 5 ans.

Moralité : la plupart des développeurs sont des débutants, et ils ne veulent pas le rester.

Corollaire : les développeurs expérimentés sont rares et on les croit peu compétents.

Pour ma part, j'adore le développement, la construction d'une architecture applicative et l'écriture du code, sont des processus hautement créatifs, qui font appel à des capacités d'abstraction et une gymnastique intellectuelle très valorisantes. Cela colle avec ma vision, plutôt anglo-saxonne, du métier d'ingénieur.

Ainsi, alors que la plupart de mes camarades de promotion étaient attirés par les architectures matérielles et le côté serveur, j'étais pour ma part passionné par la réalisation des interfaces hommes machine.

Si par la suite, j'ai retrouvé cette inégalité d'intérêt entre le front et le back-office, j'ai aussi pu constater que la proportion de code entre le client (l'IHM) et le serveur était, en revanche, équilibrée. Autrement dit, statistiquement, la plupart des développeurs front-office (ceux qui implémentent les IHMs) travaillent sans véritable intérêt.    

Pas n'importe quel ergonome

En sortant de l'école d'ingénieur, je m'estimais bien formé sur les aspects techniques mais complètement à la rue sur les aspects humains. Et encore, j'avais eu la chance d'être sensibilisé par un tout nouveau module d'ergonomie !

Ma logique était simple : pour traiter correctement une problématique, il faut avoir une vision sous tous les angles possibles... A-t-on une représentation correcte d'une pièce de monnaie lorsqu'on ne voit que son côte pile  ?  Cela tenait de l'évidence : il me fallait voir de l'autre côté de l'écran, vers l'utilisateur final.

J'ai alors recherché une formation en ergonomie logicielle et me suis tourné vers le DESS d'ergonomie de Paris V. J'y ai trouvé l'essentiel, à savoir comment asseoir une conception d'IHM sur une analyse de l'activité ainsi que des fondamentaux sur l'être humain  : psychologie cognitive, limites physiologiques... Pour autant, la formation intégrait un aspect ergonomie physique, sans intérêt pour moi.  Tandis que les techniques liées à la conception d'IHM (outils de maquettage, composants graphiques, patrons de conception...) n'étaient qu'effleurés.

Cependant, la pratique de l'ergonomie ne saurait se résumer à l'analyse de l'activité. A mon sens, l'ergonome crée de la valeur par ses recommandations. L'analyse de l'activité lui permet de les légitimer mais ne constitue pas un livrable. Il ne faut pas confondre le moyen (l'analyse de l'activité) et la fin (des préconisations ou des spécifications). 

Or, de nombreux ergonomes, souvent issus d'un cursus universitaire en psychologie, éprouvent de grandes difficultés à élaborer des recommandations, en particulier dans le domaine des IHMs.

Je ne vois pas comment, sans aucune formation technique, on peut élaborer des propositions techniquement réalistes. Cela dit, il n'est jamais trop tard pour de se mettre à la technique et j'ai vu des psychologues passer de l'autre côté du miroir…

Mon retour d'expérience

 Ce que j'ai vécu en 15 ans n'est sans doute pas représentatif, mais c'est une réalité qui m'a permis de déconstruire certaines représentations   :

•         La pratique de l'ergonomie ne s'improvise pas

Faire simple, c'est compliqué. On ne devient pas ergonome en lisant un bouquin. Il faut une formation solide et beaucoup de pratique. Dans le domaine de l’IHM, cela ne se résume pas à connaître des guidelines, des composants graphiques et des patrons de conception. 

Concevoir une IHM, c'est faire des arbitrages entre des règles souvent contradictoires et tenter de coller aux objectifs et aux modes de pensée de l'utilisateur. Seule l'analyse de l'activité fournit les clés pour comprendre l'activité de l'utilisateur. Le designer d'interactions qui n'est pas ergonome est pour moi une coquille vide.

•         La présence d'un ergonome et d'un graphiste est loin d'être systématique

Mes étudiants d'IUT croient que la spécification et la conception de l'IHM sont systématiquement faite par une équipe spécialisée avec un ergonome et un graphiste ! Dès lors, inutile d'avoir des compétences dans ce domaine. CQFD… 

Effectivement, avec une approche cycle en V classique, on traite en principe les aspects IHM, en intégrant à la phase de spécifications, deux acteurs supplémentaires   : l'ergonome, qui réalise une maquette, et le graphiste qui fait l'habillage graphique. Éventuellement, on fait revenir l'ergonome en phase de recette métier pour faire un audit ergonomique ou des tests utilisateurs. 

Si ce type d'organisation existe, notamment sur les projets webs et chez certains grands comptes, il est loin d'être généralisé, notamment dans les PME et sur les applications internes de gestion. J'ai vu et je vois encore des développeurs concevoir leurs écrans «   from scratch » en cherchant des icônes via Google Image ! C'est fréquent, y compris dans certains grands comptes   !

Il est à la fois triste et paradoxal de constater que des catalogues en ligne bénéficient d'investissements ergonomiques importants pour une fréquence d'usage modérée, tandis que des applications de prise de commande, utilisées à longueur de journée, n'ont pas vu l'ombre d'un graphiste ou d'un ergonome. Comme si le fait que l'utilisateur soit captif pouvait dispenser d'optimiser sa productivité !

•         Le développeur est confronté à des problématiques ergonomiques.

Quand il n'est pas laissé seul face à la conception de l'IHM, le développeur sera quand même tôt ou tard confronté à des problématiques ergonomiques.

Souvent, les spécifications contiennent des maquettes ou des copies d'écrans, mais pas systématiquement. Maquetter l'ensemble des écrans étant un travail colossal, certains cas d'utilisation ne sont carrément pas illustrés. En outre, quand le temps du développement est venu, l'ergonome est bien souvent parti.  

A cela, s'ajoute des problématiques de faisabilité technique (composant graphique absent du framework avalisé par la DSI), conduisant à des adaptations plus ou moins heureuses des développeurs ! En phase de développement, on assiste parfois (souvent ?) à une déconstruction totale de l'IHM proposée par l'ergonome. Malheureusement, celui-ci n'est plus la pour se défendre, et il arrive que le livrable ne contiennent plus grand chose de ses propositions   !

•         Il existe une vraie complémentarité entre l'implémentation d'IHM et l'ergonomie

Le développeur est le premier utilisateur, au sens temporel du terme. Comme il est au plus prêt du code, s'il distingue un problème il est susceptible de le corriger à moindre coût. A l'inverse, si le problème n'est découvert qu'après la mise en production, il est souvent trop tard car le budget a été consommé ! 

C'est une réalité, les guides ergonomiques sont rarement mis en pratique par le développeur. D'où l'intérêt d'implémenter ces règles, car au final, c'est le code qui fait foi. C'est possible, sur certaines architectures techniques. J'ai en tête un projet pour un grand compte pharmaceutique, ou nous avons réalisé un framework graphique implémentant environ 50% des règles du guide d'ergonomie. L'ergonomie peut donc s'implémenter...

La spécification d'une IHM n'est pas déterministe, c'est à dire qu'à exigence ergonomique égale, il existe plusieurs IHMs possibles. Etre développeur m'aide à proposer la solution technique la moins coûteuse.

C'est en forgeant qu'on devient forgeron   : je ne connais pas de meilleur moyen pour connaître les composants graphiques et les patrons de design d'une plateforme, que d'implémenter une application.

Conclusion

S'il est clair que je n'entre dans aucune des cases habituelles, je ne pense pas être devenu un mouton à 5 pattes. Au contraire, je revendique la cohérence de mon parcours, autour d'un seul et même domaine d'étude : l'IHM. Je me sens bien comme ergonome car mon travail est basé sur l'analyse de l'activité et la connaissance des utilisateurs finaux. Je me sens bien comme développeur car c'est lui qui réalise in fine l'IHM mais aussi parce c'est une activité que je pratique avec plaisir.

Chacun trace sa route et loin de moi l'idée d'imposer une façon de faire ou d'être.

J'ai choisi de me spécialiser, non en fonction des stéréotypes des métiers existants, mais des compétences qui me semblaient utiles en conception d'IHM.  Je ne suis ni superman ni omniscient : je ne fais pas d'ergonomie physique,  j'ai délaissé les aspects design car je n'ai pas de talent artistique et j'ai choisi d'implémenter uniquement côté client dans l'écosystème Java afin d'avoir une réelle expertise.

Au final, je milite pour une démocratisation de l'ergonomie. Sortons l'ergonomie de ses niches habituelles (site web, téléphonie, IHM embarquées...) chez les grands comptes pour l'appliquer en PME sur des applications de gestion à usage intensif  !  Cela implique de sortir d'une pratique académique de l'ergonomie et de devenir pragmatique. S'adapter au budget limité du client sans sacrifier l'analyse de l'activité, proportionner l'effort ergonomique en fonction des fréquences d'usages. Ces projets ne peuvent pas toujours se permettre de faire intervenir un ergonome pendant tout le projet. 

Nous qui observons, chaque jour, des activités en environnement dégradé, ne pouvons-nous adapter la pratique de notre métier en contexte dégradé    ?  J'enseigne l'ergonomie en IUT informatique et propose une formation à destination des développeurs et les chefs de projet... En effet, quand l'ergonome ne peut pas être là, je préfère cent fois avoir des développeurs avec une sensibilité ergonomique.