Par opposition à d'autres machines qui représentent des extensions du corps humain, par exemple qui fournissent des capacités et une puissance supplémentaires, l'ordinateur, et en particulier le logiciel, représente plutôt une extension du cerveau humain, en faisant appel à des processus plus cognitifs (e.g., perception, mémoire, language, résolution de problèmes, prise de décision, etc.).
En conséquence, pour améliorer l'IHO, il convient de s'intéresser plus particulièrement aux processus cognitifs humains. Utilisant les résultats et les méthodes de l'ergonomie, l'objectif de ce guide est de fournir un certain nombre de recommandations pour la conception de logiciels mieux adaptés aux processus cognitifs des utilisateurs. L'objectif est de fournir des éléments permettant d'améliorer la communication utilisateur-ordinateur au même titre que l'on s'assure de la performance d'autres aspects des systèmes, tels que la qualité des algorithmes, le temps de réponse, la sécurité et la fiabilité.
Ce qui est spécifique à l'ergonomie des logiciels par rapport à d'autres aspects plus classiques de l'ergonomie est que la conception du logiciel établit le contenu des informations disponibles à l'utilisateur ainsi que les relations visuelles entre ces informations. En combinaison avec, ou à la place du matériel, le logiciel établit aussi la séquence des actions que l'utilisateur doit effectuer ainsi que le feed-back concernant ces actions. Par opposition à un environnement papier ou à des dispositifs plus classiques de présentation d'informations et de commandes ("displays and controls", "knobs and dials") la tâche de l'utilisateur est intimement dépendante du logiciel. En conséquence, l'impact de l'ergonomie dans le développement du logiciel est très important, puisque cela concerne l'ensemble de l'activité de l'utilisateur. L'ergonomie ne s'intéresse pas seulement aux aspects de surface de l'IHO, mais à tout ce qui peut influencer l'activité de l'utilisateur. Il ne s'agit en effet pas seulement de définir la taille des caractères, mais aussi de définir quelles informations doivent être fournies.
Pour ces raisons, l'ergonomie du logiciel a eu historiquement (et a toujours) une part importante dans la conception et l'évaluation de systèmes critiques tels que le contrôle du trafic aérien, les applications militaires et les centrales nucléaires. Dans d'autres environnements qui ne posent pas de problèmes aussi aigus de sécurité, l'ergonomie des logiciels n'est devenue une discipline essentielle que depuis dix ans. De nombreux organismes, entreprises, qui produisent ou simplement utilisent des systèmes informatiques incluent maintenant l'ergonomie dans leurs travaux de conception et d'évaluation de systèmes, mais aussi dans leur stratégie publicitaire et de marketing. Dans ces environnements, les améliorations attendues sont bien sûr liées à la satisfaction des utilisateurs et à une meilleure acceptabilité, mais aussi à une meilleure efficacité des opérations, à des économies de temps et d'argent, et finalement à des profits plus élevés pour les entreprises.
L'objectif de ce guide est de recenser les divers problèmes d'ordre ergonomique posés par les Interfaces Homme-Ordinateur et d'y apporter un certain nombre de propositions de solutions. Ces recommandations sont issues en grande partie des résultats des recherches en ergonomie du logiciel mais aussi d'une pratique de conseil sur le terrain. Ce guide est donc entaché d'une certaine subjectivité, à la fois quant au choix des recommandations (certaines ne sont pas mentionnées parce que trop spécifiques ou parce qu'elles manquent d'étayage expérimental ou bien encore parce qu'elles sortent du cadre fixé) mais aussi quant au contenu de certaines règles. En effet, certains choix ont été faits quand les résultats de plusieurs études étaient en désaccord.
Cependant, ces précautions prises, il convient de signaler que ce guide correspond à des demandes souvent réitérées de la part des concepteurs qui souhaitent disposer de quelques règles de conception.
En conséquence, malgré la répugnance de certains ergonomes à se montrer normatifs, nous avons pris le parti d'énoncer un certain nombre de recommandations. Même si ces recommandations ne sont pas complètes, même si elles peuvent être remises en cause par de futurs travaux scientifiques, même si on ne peut s'en contenter toujours et s'il faut bien souvent faire appel à l'expert en ergonomie, énoncer ces recommandations a le mérite de permettre l'introduction de considérations ergonomiques dans des entreprises qui de toute façon ne pourraient faire appel aux ergonomes chaque fois qu'elles concoivent un produit logiciel, et qui préfèrent avoir des recommandations qui "marchent" dans 75% des cas plutôt que pas de recommandation du tout.
Rappelons aussi que ce guide ne concerne que certains aspects de l'interface (i.e., les aspects indépendants de tâches spécifiques), qu'il y a certains compromis à faire entre les diverses recommandations et que l'aspect combinatoire des règles restera cependant assez complexe à manipuler (en effet, à un point donné de la conception d'une transaction, il convient d'examiner de nombreuses règles, souvent inter-dépendantes). En fait, une contribution ultérieure à ce guide pourra être de formaliser de façon exhaustive la combinatoire des règles afin qu'elles soient appliquées de façon concomitante, notamment à des fins évaluatives (la technique d'implémentation pouvant, par exemple, prendre la forme d'un système expert).
La première erreur est de croire que des améliorations pour l'utilisateur seront issues uniquement des progrès technologiques, alors que chaque nouvelle technologie (e.g., les écrans ou la commande vocale) fait surgir de nouveaux problèmes (e.g. disposition spatiale des informations ou entraînement du locuteur) par rapport à la technologie précédente (respectivement les télétypes ou les claviers).
La seconde erreur est de penser que pour concevoir des logiciels ergonomiques, il suffit d'y réfléchir un peu. Or on sait bien que l'introspection dans ce domaine, surtout à propos de phénomènes cognitifs complexes, ne donne pas de bons résultats.
Deux des conséquences de ces croyances sont que souvent les concepteurs ne connaissent pas suffisamment bien les tâches qu'ils sont supposés informatiser, et qu'ils ne réalisent pas l'effort, ou ne connaissent les méthodes appropriées nécessaires pour obtenir cette connaissance. Une autre conséquence est que les concepteurs ont souvent tendance à fournir aux utilisateurs tout ce à quoi ils peuvent penser. Malheureusement, fournir dix mauvais outils n'est pas meilleur que de n'en proposer qu'un seul qui soit bien adapté.
L'organisation des équipes de conception ainsi que les contraintes de temps sont aussi des facteurs importants dans les erreurs de conception. Le fait que le logiciel soit implémenté par des individus qui ne partagent pas nécessairement la même vue des procédures opérationnelles désirées peut conduire à des interfaces non homogènes, voire incompatibles. Quand un utilisateur doit effectuer des tâches avec des procédures différentes, ou pire, quand il doit effectuer différemment des transactions conceptuellement similaires au sein d'une même tâche, une contrainte non nécessaire lui est imposée pour l'apprentissage et l'utilisation du système. Quand plusieurs systèmes sont développés au sein d'une grande entreprise et quand la conception de l'IHO est établie indépendamment pour chaque système, le résultat est souvent d'imposer des comportements incompatibles à des utilisateurs qui pourront avoir à utiliser plusieurs systèmes, ou tout simplement communiquer avec d'autres utilisateurs qui ont besoin de coopérer vers le même objectif.
Les défauts de conception de l'IHO conduisent à une performance dégradée des systèmes. Les utilisateurs peuvent parfois compenser une mauvaise conception par des efforts supplémentaires. Cependant, il y a une limite à l'adaptation des utilisateurs à une mauvaise interface. L'effet négatif cumulé résultant de plusieurs erreurs de conception peut conduire à des dysfonctionnements des systèmes, à des performances insatisfaisantes, et à des plaintes des utilisateurs.
Cela peut aussi conduire à:
Cela signifie bien entendu des opérations interrompues, du temps, des efforts et des investissements perdus, et l'échec vis-à-vis des avantages potentiels de l'informatisation. Par ailleurs, le passage de procédures manuelles à l'informatique peut aussi signifier en fait deux fois plus de temps nécessaire pour mener des tâches à leur terme en raison de déficiences dans la conception de l'IHO (en effet, dans certains cas, la tâche est doublée, i.e., qu'il y a conservation de la procédure manuelle en plus de la procédure informatisée).
Dans l'absence de guidage effectif, la conception et l'implémentation de l'IHO peut devenir l'apanage de programmeurs non familiers avec les exigences opérationnelles de la tâche. L'IHO est alors produite lentement, la détection et la correction des erreurs de conception (quand cela est fait) intervient seulement après l'implémentation initiale des systèmes, quand les modifications du logiciel sont difficiles et coûteuses. La mise en oeuvre de l'ergonomie devrait donc se faire à chaque étape de la conception, le plus tôt possible, plutôt qu'a posteriori, lors d'une contribution évaluative extérieure.
|
|
