DÉFINITION D’UN CADRE POUR L’ÉVALUATION

A PRIORI DES INTERFACES HOMME-MACHINE

DANS LES SYSTÈMES INDUSTRIELS DE
SUPERVISION
Martial Grislin

To cite this version:

Martial Grislin. DÉFINITION D’UN CADRE POUR L’ÉVALUATION A PRIORI DES INTER-
FACES HOMME-MACHINE DANS LES SYSTÈMES INDUSTRIELS DE SUPERVISION. Interface
homme-machine [cs.HC]. Université de Valenciennes et du Hainaut-Cambrésis, 1995. Français. �NNT :
1995ICME9529�. �tel-01441585�

HAL Id: tel-01441585

https://tel.archives-ouvertes.fr/tel-01441585
Submitted on 25 Jan 2017

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
 Numéro d’ordre : 95-29

THÈSE
présentée à

L’université de Valenciennes
et du Hainaut-Cambrésis

en vue de l'obtention du

DOCTORAT
Spécialité

AUTOMATIQUE
INDUSTRIELLE ET HUMAINE
par

Martial GRISLIN
Maître ès Sciences

DÉFINITION D’UN CADRE POUR

L’ÉVALUATION A PRIORI DES INTERFACES HOMME-MACHINE DANS
LES SYSTÈMES INDUSTRIELS DE SUPERVISION

Soutenue le 10 Novembre 1995 devant la commission d’examen :

Mme. et MM. : Jean-Claude ANGUÉ

Abdallah ASSE
Florent CHAVAND rapporteur
Christophe KOLSKI
Patrick MILLOT
Marie-Claude THOMAS rapporteur
 “ […] it seems that «Le mieux est l’ennemi du bien» (Voltaire
1764) to the extend that insisting on using only the best methods
may result in using no methods at all.”

(Nielsen 1993)
 Avant propos

Merci à…

… Jean-Claude ANGUE, Professeur à l’université de Valenciennes, pour m’avoir accueilli au sein

de son équipe de recherche du Laboratoire d’Automatique et de Mécanique Industrielles et Humaines.
Je tiens ici à lui témoigner toute ma reconnaissance pour m’avoir guidé au cours de ce travail.

… Christophe KOLSKI, Professeur à l’université de Valenciennes, qui m’a suivi, guidé et conseillé
avec enthousiasme tout au long de mon travail. Je tiens à lui exprimer ma profonde reconnaissance
pour avoir enrichi ma recherche et ce mémoire par le biais de ses nombreuses remarques et de ses
nombreux conseils.

… Marie-Claude THOMAS, Professeur à l’université de Nice et Florent CHAVAND, Professeur à

l’université d’Evry, de me faire l’honneur d’examiner ce travail et d’en être les rapporteurs.

… Patrick MILLOT, Professeur à l’université de Valenciennes, et Abdallah ASSE, président

directeur général de la société Prosyst, d’avoir accepté d’examiner ce travail et de siéger à la
commission d’examen.

… à Emmanuelle pour sa patience, ses nombreuses relectures et remarques, et tous mes collègues,
amis, copains qui m’ont eu (ou que j’ai eu) à supporter (!), je pense plus particulièrement à Michèle,
aux B106’biomen et Alexis, Nanard, Pascal, Fred…

… et une pensée particulière pour mes parents sans lesquels ce mémoire n’existeraient pas
aujourd’hui.
 SOMMAIRE

SOMMAIRE

INTRODUCTION GÉNÉRALE............................................................................15

CHAPITRE I

L’ÉVALUATION DES INTERFACES HOMME-MACHINE

INTRODUCTION........................................................................................19
I. LES SYSTÈMES HOMME-MACHINE DE SUPERVISION........................19
I.1. ARCHITECTURE DU SYSTÈME HOMME-MACHINE.....................19
I.2. LA QUALITÉ DU DIALOGUE HOMME-MACHINE........................20
I.3. CONCLUSION...........................................................................22
II. LE DÉVELOPPEMENT DES INTERFACES HOMME-MACHINE.............22
II.1. LES CYCLES DE VIE DU GÉNIE LOGICIEL..................................22
II.2. LE CYCLE DE VIE EN V............................................................23
II.3. LE CYCLE DE VIE EN V VIS-À-VIS DE LA MÉTHODE EN U DU
LAMIH....................................................................................24
II.4. CONCLUSION SUR LE DÉVELOPPEMENT DES IHM...................26
III. L’ÉVALUATION DES INTERFACES HOMME-MACHINE.......................26
III.1. PRINCIPE DE L’ÉVALUATION.....................................................26
III.2. LES DONNÉES DE BASE À RECUEILLIR.....................................29
III.3. LE TRAITEMENT DES DONNÉES ISSUES DE L’ÉVALUATION.......31
III.4. LES INTERVENANTS DE L’ÉVALUATION....................................32
III.5. CONCLUSION, BESOINS POUR L’ÉVALUATION DES INTERFACES33
CONCLUSION SUR L’ÉVALUATION DES INTERFACES HOMME-MACHINE. .33

CHAPITRE II

LES MÉTHODES ET TECHNIQUES USUELLES D’ÉVALUATION DES INTERFACES

HOMME-MACHINE
(MISE EN RELATION AVEC LES SYSTÈMES INDUSTRIELS DE SUPERVISION)
INTRODUCTION............................................................................................................37
I. DISCUSSION PRÉALABLE SUR LES CLASSIFICATIONS ACTUELLES EN MATIÈRE
D’ÉVALUATION D’IHM......................................................................................37
I.1. ÉVALUATION D’UNE INTERFACE EXISTANTE.............................................38
I.2. ÉVALUATION D’UNE INTERFACE EN COURS DE DÉVELOPPEMENT.............38

SOMMAIRE 1
 SOMMAIRE
II. LES APPROCHES CENTRÉES SUR LES UTILISATEURS...........................................39
II.1. LES APPROCHES EMPIRIQUES DE DIAGNOSTIC D’USAGE...........................39
II.2. L’ESTIMATION DE LA CHARGE DE TRAVAIL...............................................43
II.3. LES TESTS DE CONCEPTION......................................................................45
II.4. CONCLUSION SUR LES APPROCHES CENTRÉES SUR LES UTILISATEURS ET
POSITIONNEMENT DANS LE CYCLE DE DÉVELOPPEMENT..........................47
III. LES APPROCHES CENTRÉES SUR UNE EXPERTISE...............................................48
III.1. LES MÉTHODES ET TECHNIQUES...............................................................48
III.2. CONCLUSION DES APPROCHES EXPERTES ET POSITIONNEMENT DANS LE
CYCLE DE DÉVELOPPEMENT.....................................................................50
CONCLUSION SUR LES MÉTHODES USUELLES D’ÉVALUATION DES IHM.....................50

CHAPITRE III

LES MÉTHODES ET TECHNIQUE ANALYTIQUE D’ÉVALUATION DES INTERFACES

HOMME-MACHINE
(MISE EN RELATION AVEC LES SYSTÈMES INDUSTRIELS DE SUPERVISION)
INTRODUCTION............................................................................................................55
I. LES APPROCHES CENTRÉES SUR UNE MODÉLISATION........................................55
I.1. LES MODÈLES FORMELS PRÉDICTIFS........................................................55
I.1.1. LES MODÈLES DE TÂCHES....................................................................56
I.1.2. LES MODÈLES LINGUISTIQUES.............................................................59
I.1.3. CONCLUSION SUR LES MODÈLES FORMELS PRÉDICTIFS ET
POSITIONNEMENT DANS LE CYCLE DE DÉVELOPPEMENT.....................61
I.2. LES MODÈLES FORMELS DITS DE QUALITÉ DE L’IHM, APPROCHES
LOGICIELLES ............................................................................................62
I.2.1. LES SYSTÈMES D’ÉVALUATION AUTOMATIQUE DE L’AFFICHAGE.........62
I.2.2. LES SYSTÈMES DE GÉNÉRATION AUTOMATIQUE DE L’AFFICHAGE........64
I.2.3. CONCLUSION SUR LES MODÈLES FORMELS DITS DE QUALITÉ DE L’IHM
.............................................................................................................65
II. SYNTHÈSE DES MÉTHODES ET TECHNIQUES D’ÉVALUATION RECENSÉES...........65
CONCLUSION SUR L’ÉVALUATION ANALYTIQUE DES IHM...........................................67

CHAPITRE IV

PROPOSITION D’UNE DÉMARCHE D’ÉVALUATION A PRIORI DES INTERFACES

HOMME-MACHINE
(APPLICATION AUX SYSTÈMES INDUSTRIELS DE SUPERVISION)
INTRODUCTION............................................................................................................71
I. RECHERCHE D’UN CANEVAS THÉORIQUE POUR DÉCRIRE L’INTERACTION HOMME-
MACHINE............................................................................................................71
I.1. ÉVALUER TOUT AU LONG DU DÉVELOPPEMENT........................................71
I.2. LA COMPLEXITÉ DE L’INTERACTION HOMME-MACHINE...........................72
I.3. LES MODÈLES ARCHITECTURAUX.............................................................73
I.4. LA MODÉLISATION EN TERME DE LANGAGE.............................................74

SOMMAIRE 2
 SOMMAIRE
II. PROPOSITION DU CANEVAS THÉORIQUE COSÉSYL.............................................75
II.1. LE MODÈLE CONCEPTUEL DE L’INTERFACE..............................................77
II.1.1. DESCRIPTION DU NIVEAU CONCEPTUEL...............................................77
II.1.2. SITUATION DU NIVEAU CONCEPTUEL DANS LE CYCLE EN V................79
II.2. LA SÉMANTIQUE DE LA TÂCHE.................................................................80
II.2.1. DESCRIPTION DU NIVEAU SÉMANTIQUE...............................................80
II.2.2. SITUATION DU NIVEAU SÉMANTIQUE DANS LE CYCLE EN V................81
II.3. LA DÉFINITION SYNTAXIQUE ET LA REPRÉSENTATION LEXICALE DU
DIALOGUE.................................................................................................82
II.3.1. DESCRIPTION DU NIVEAU SYNTAXIQUE...............................................82
II.3.2. DESCRIPTION DU NIVEAU LEXICAL......................................................83
II.3.3. SITUATION DES NIVEAUX SYNTAXIQUE ET LEXICAL DANS LE CYCLE EN V
.............................................................................................................84
II.4. CONCLUSION SUR LE CANEVAS THÉORIQUE COSÉSYL..............................84
III. PROPOSITION DE LA DÉMARCHE D’ÉVALUATION A PRIORI.................................87
III.1. PRINCIPE DE LA DÉMARCHE D’ÉVALUATION A PRIORI..............................87
III.2. PHASE E1, MODÉLISATION A PRIORI DE L’INTERACTION HOMME-MACHINE
..................................................................................................................88
CONSTRUCTION DU MODÈLE OBSERVÉ...............................................................89
CONSTRUCTION DU MODÈLE DE L'ÉVALUATEUR................................................89
III.3. PHASE E2, ÉVALUATION A PRIORI DE L’UTILITÉ DE L’INTERFACE............91
III.4. PHASE E3, ÉVALUATION A PRIORI DE L’UTILISABILITÉ DE L’INTERFACE. .91
III.4.1. PRINCIPE..............................................................................................91
III.4.2. LES CRITÈRES ERGONOMIQUES D’ÉVALUATION DE L’UTILISABILITÉ DANS
LA DÉMARCHE A PRIORI.......................................................................92
III.5. SYNTHÈSE DE LA DÉMARCHE PROPOSÉE POUR L’ÉVALUATION A PRIORI. .93
CONCLUSION SUR LA DÉMARCHE D’ÉVALUATION PROPOSÉE......................................95

CHAPITRE V

MISE EN ŒUVRE ET PERSPECTIVES DE LA DÉMARCHE D’ÉVALUATION A PRIORI DES

INTERFACES HOMME-MACHINE
(APPLICATION AUX SYSTÈMES INDUSTRIELS DE SUPERVISION)
INTRODUCTION............................................................................................................99
I. MISE EN ŒUVRE DE LA DÉMARCHE POUR ÉVALUER A PRIORI UNE IHM DE
SUPERVISION......................................................................................................99
I.1. PRINCIPE DE FONCTIONNEMENT DU PROCÉDÉ ÉTUDIÉ.............................99
I.2. MISE EN ŒUVRE DE LA DÉMARCHE........................................................100
II. ÉVALUATION LORS DE L’ÉTAPE DE SPÉCIFICATION FONCTIONNELLE...............101
II.1. PHASE E1 : MODÉLISATION A PRIORI DE L’INTERACTION HOMME-MACHINE
(SPÉCIFIÉE).............................................................................................101
II.1.1. EXEMPLE DE MODÈLE OBSERVÉ (LORS DES SPÉCIFICATIONS
FONCTIONNELLES).............................................................................102
II.1.2. EXEMPLE DE MODÈLE DE L’ÉVALUATEUR (LORS DES SPÉCIFICATIONS
FONCTIONNELLES).............................................................................104
II.2. PHASE E2 : ÉVALUATION A PRIORI DE L’UTILITÉ DE L’INTERFACE
(SPÉCIFIÉE).............................................................................................105
II.3. PHASE E3 : ÉVALUATION DE L’UTILISABILITÉ DE L’INTERFACE (SPÉCIFIÉE)
................................................................................................................109
II.4. CONCLUSION SUR L’ÉVALUATION DES SPÉCIFICATIONS..........................109
III. ÉVALUATION LORS DE L’ÉTAPE DE CONCEPTION PRÉLIMINAIRE......................110
SOMMAIRE 3
 SOMMAIRE
III.1. PHASE E1 : MODÉLISATION A PRIORI DE L’INTERACTION HOMME-MACHINE
(CONÇUE)................................................................................................111
III.1.1. EXEMPLE DE MODÈLE OBSERVÉ (LORS DE LA CONCEPTION
PRÉLIMINAIRE)...................................................................................111
III.1.2. EXEMPLE DE MODÈLE DE L’ÉVALUATEUR (LORS DE LA CONCEPTION
PRÉLIMINAIRE)...................................................................................114
III.2. PHASE E2 : ÉVALUATION A PRIORI DE L’UTILITÉ DE L’INTERFACE (CONÇUE)
................................................................................................................116
III.3. PHASE E3 : ÉVALUATION A PRIORI DE L’UTILISABILITÉ DE L’INTERFACE
(CONÇUE)................................................................................................118
III.4. CONCLUSION SUR L’ÉVALUATION DE LA CONCEPTION PRÉLIMINAIRE....118
IV. BILAN ET PERSPECTIVES DE RECHERCHE.........................................................119
IV.1. DIFFICULTÉ D’UNE DÉMARCHE D’ÉVALUATION PARTICIPATIVE..............119
IV.2. DIFFICULTÉ DU PRINCIPE D’ÉVALUATION BASÉE SUR UNE MODÉLISATION
................................................................................................................120
IV.3. DÉMARCHE ANALYTIQUE D’ÉVALUATION A POSTERIORI.........................121
IV.4. ENVIRONNEMENT GLOBAL D’ÉVALUATION DES IHM INDUSTRIELLES. . .123
CONCLUSION DE LA MISE EN ŒUVRE ET DES PERSPECTIVES DE LA DÉMARCHE........126

CONCLUSION GÉNÉRALE..............................................................................131

RÉFÉRENCES BIBLIOGRAPHIQUES
RÉFÉRENCES PERSONNELLES.............................................................133
AUTRES RÉFÉRENCES.........................................................................134
INDEX DES AUTEURS..........................................................................147
INDEX DES FIGURES ET DES TABLEAUX..........................................................149

ANNEXES
ANNEXE A :
PROCESSUS DE DÉVELOPPEMENT EN V ADAPTÉ À UN SYSTÈME
INTERACTIF, ISSU DU GÉNIE LOGICIEL...........................................155
ACTIVITÉS DE DÉVELOPPEMENT DES IHM SELON LE CYCLE EN V156
ANNEXE B :
PROCÉDÉ DE FABRICATION DE MÉLANGE......................................159
ANNEXE C :
MAQUETTE DE L’IMAGERIE DE SUPERVISION DU PROCÉDÉ DE
MÉLANGE.......................................................................................163
ANNEXE D :
QUELQUES PISTES DE RECHERCHES DE MÉTHODES D’ESTIMATION DES
CRITÈRES ERGONOMIQUES D’ÉVALUATION....................................169

SOMMAIRE 4
Introduction générale
14 Introduction générale
Introduction générale 15

L’évolution des technologies enregistrée au cours de ces dernières décennies a modifié la manière d’appréhender
l’automatisation et l’informatisation des procédés industriels. En effet, les processus industriels sont passés d’une
instrumentation entièrement automatique qui tendait à exclure l’opérateur, à une automatisation moins radicale,
centrée sur l’homme. Prendre en compte cette évolution est devenu nécessaire et essentiel dans les industries à haut
risque comme les processus continus (nucléaire, chimie) et dans les transports (aérien, ferroviaire, spatial).

Pendant les années 80, afin de pallier les insuffisances technologiques, c’est une collaboration entre le couple
homme-machine qui est préconisée : la machine prépare et trie l’information, l’homme prend les décisions. La
prochaine décennie conduit à envisager des machines qui “raisonnent” en parallèle de l’homme et sont capables de le
prendre en compte, de lui présenter dynamiquement la bonne information. Bientôt, elles iront jusqu’à détecter les
erreurs de ce partenaire humain. Ces changements ont en particulier, profondément modifié le travail des opérateurs
dans les salles de supervision.

Cette évolution du travail de l’homme tient à plusieurs raisons. L’une de ces raisons concerne la gestion des
dysfonctionnements qui est difficilement automatisable car l’ensemble des défauts ne peut être prévu de façon
exhaustive. De plus, l’élaboration par l’opérateur des procédures de correction des défauts n’est généralement pas le
fruit d’un raisonnement de type analytique, mais relève plutôt d’un savoir-faire typiquement humain, acquis par
apprentissage ou par induction (Rasmussen 86 ; Sheridan 88 ; Johannsen et al. 92). De ce fait, les opérateurs ont été
“conservés” pour effectuer les tâches décisionnelles de supervision non automatisables aujourd’hui, telles que la
détection et l’anticipation des défauts, le diagnostic et la reprise des dysfonctionnements.

L’homme reste donc indispensable au contrôle des processus complexes. Cependant, sa présence dans le système
de conduite ne va pas sans provoquer quelques défauts propres à sa rapidité plus ou moins importante à résoudre les
problèmes et à sa fiabilité. Une solution à ces problèmes est d’assister l’opérateur dans sa tâche. Tel est l’objectif des
systèmes de conduite et de supervision des procédés.

Pour les processus industriels, l’interface homme-machine constitue l’intermédiaire entre la machine —au sens
général du terme— et l’opérateur présent en salle de contrôle. Elle comprend à la fois les dispositifs de présentation de
l’information, les organes de commande et d’éventuels outils d’assistance. Le développement de ce lien entre deux
entités complètement différentes n’est pas trivial. Un ensemble de problèmes ergonomiques apparaît à la fois lors de
l’utilisation et lors de la réalisation de ces systèmes de supervision. Ainsi, de nombreuses recherches sont actuellement
menées, d’une part pour aider l’opérateur humain en salle de contrôle et d’autre part pour fournir aux équipes de
développement des méthodes et des outils permettant de mieux intégrer l’homme lors de la conception.

De plus, il ne suffit pas de réaliser l’interface, il faut aussi vérifier si elle correspond bien aux besoins et contraintes
du système homme-machine. Le développement de ceux-ci passe généralement par un cycle de vie standard
“analyse/spécification, conception, réalisation, intégration, évaluation, maintenance”, itératif pour certaines phases.
L’ingénierie des interfaces propose un grand nombre d’outils d’aide pour les phases d’analyse (modèles de tâche), de
conception et d’implémentation (maquettage, générateurs d’interfaces, boîtes à outils). Par contre, le passage à la
phase d’évaluation, que nous situons à plusieurs niveaux dans le cycle, est un des problèmes cruciaux pour l’équipe de
développement.

Dans ce contexte, l’objectif de la recherche est de proposer un cadre pour faciliter une évaluation a priori des
interfaces homme-machine, c’est-à-dire le plus tôt possible lors du cycle de développement. Pour cela, il s’agit de
définir une démarche qui mette à la disposition de l’équipe de développement un ensemble de techniques et méthodes
d’évaluation adaptées aux critères de l’étape du développement en cours. En effet, même si actuellement, un grand
nombre de techniques d’évaluation des interfaces homme-machine existe, il n’est pas toujours facile de choisir celle(s)
adaptée(s). De plus, leur utilisation est une tâche longue, difficile, requérant expertise et patience.

La présentation de ce travail de recherche et des résultats obtenus fait l’objet de ce mémoire. Il est composé de
cinq chapitres.
16 Introduction générale

Le CHAPITRE I présente d’abord la notion de système homme-machine et discute de l’évolution de l’activité

humaine en salle de contrôle. Cette présentation est suivie par la description du cycle global de développement d’un
système homme-machine et d’une discussion qui souligne les points critiques du développement des interfaces. Nous
y intégrons l’approche du cycle de vie en V issue du génie logiciel. Puis nous définissons l’évaluation des interfaces
homme-machine et rappelons qu’avant d’évaluer il faut savoir quoi observer et qui va observer.

Trois approches d’évaluation sont ensuite proposées dans le CHAPITRE II pour recenser les méthodes et techniques
utilisables pour les systèmes interactifs : (1) les approches basées sur l’utilisateur, (2) les approches basées sur une
expertise et (3) les approches basées sur une modélisation de l’IHM et/ou de l’interaction homme-machine. Ce
chapitre est ensuite focalisé sur l’ensemble des méthodes et techniques usuelles d’évaluation des IHM, soit les deux
premières approches proposées (1) et (2). Chaque technique est présentée en détail avec son principe de base et les
données ergonomiques concernées. Nous soulignons les avantages et limites de leur utilisation pour l’évaluation dès le
début du développement des systèmes industriels de supervision.

Le CHAPITRE III est consacré à la description en détail des méthodes et techniques analytiques d’évaluation des
IHM, associées à la dernière approche (3) proposée dans le chapitre II. Celles-ci sont généralement orientées
conception d’IHM ; nous les avons “détournées” pour l’évaluation tout au long du développement. Ces dernières sont
basées sur une modélisation, et introduisent une démarche analytique d’évaluation. A l’issue de cette partie, nous
proposons une synthèse des méthodes et techniques recensées par rapport au principe d’évaluation retenu.

Le CHAPITRE IV est consacré à la proposition d’une démarche d’évaluation a priori des interfaces homme-machine.
Nous y définissons un canevas théorique pour décrire l’interaction homme-machine. Puis, les méthodes et techniques
d’évaluation, recensées dans les chapitres II et III, sont classées par rapport aux niveaux du modèle d’architecture
proposé. Leurs points d’entrées sont ainsi situés tout au long du cycle de développement des IHM.

L’objectif du CHAPITRE V est de montrer la validité de la démarche proposée. Pour cela, elle sera tout d’abord mise
en œuvre, en laboratoire, lors de la spécification fonctionnelle de l’imagerie de supervision d’un procédé industriel
“fictif”, puis lors de l’étape de conception préliminaire. Un certain nombre de modèles dits analytiques sont ainsi
utilisés concrètement pour décrire l’interaction homme-machine dans le but de valider leur utilisation pour
l’évaluation. La validité de la démarche est ensuite discutée en soulignant quelques difficultés, puis nos perspectives
de recherches sont introduites.

La figure ci-dessous illustre le plan du mémoire avec les interactions entre les cinq chapitres.

Bilan et perspectives

Chapitre V
Chapitre I Mise en œuvre de la
problématique des IHM de supervision
L'évaluation des interfaces démarche
homme-machine d'évaluation a priori
Cycle de développement en V
Démarche d'évaluation
Principe de l'évaluation
Critères d'évaluation Canevas de description

Chapitre II approches basées Chapitre IV

Les méthodes et sur les utilisateurs Proposition d'une
techniques usuelles approches basées démarche d'évaluation
d'évaluation des IHM sur une expertise a priori des IHM
approches basées sur
une modélisation 3 approches / principe d'évaluation

Chapitre III
Les méthodes et SYNTHESE
techniques analytiques / PRINCIPE
d'évaluation des IHM

Figure 0 : Plan du mémoire

Chapitre I

L’évaluation des Interfaces Homme-Machine

INTRODUCTION

I. LES SYSTÈMES HOMME-MACHINE DE SUPERVISION

II. LE DÉVELOPPEMENT DES INTERFACES HOMME-MACHINE

III. L’ÉVALUATION DES INTERFACES HOMME-MACHINE

CONCLUSION SUR L’ÉVALUATION DES INTERFACES HOMME-

MACHINE
 Chapitre I 19

Lors du développement des interfaces homme-machine de supervision, il est nécessaire de bien connaître le
système à diriger et celui qui le dirige. En général, les ingénieurs concepteurs connaissent bien la technologie de la
machine, il y a donc en principe peu de problèmes de conception de ce côté. Par contre, lorsque l’homme doit y être
associé, des questions se posent sur la relation homme-machine. En effet, le concepteur ne connaît pas toujours les
utilisateurs et surtout ne sait pas exactement comment ceux-ci se représentent leurs tâches.

L’objectif de ce chapitre est de mettre en évidence de tels problèmes. En particulier, l’accent sera mis sur
l’importance de la qualité du dialogue homme-machine supporté par une interface de supervision. Cela permettra
ensuite de se focaliser sur notre problématique : l’évaluation des interfaces homme-machine.

Dans la première partie, nous abordons la structure globale d’un système de supervision. Cette description est
suivie de celle du cycle complet de développement d’un système homme-machine ainsi que d’une courte discussion
qui souligne les points critiques de la conception des IHM. Nous y intégrons le modèle du cycle de vie en V issu du
génie logiciel, qui servira de base de réflexion tout au long du mémoire. Enfin, nous définissons l’évaluation des IHM
en en donnant le principe, les données de base à recueillir et leur traitement, puis les intervenants de l’évaluation.

I. L ES SYSTÈMES HOMME - MACHINE DE SUPERVISION

“ Le superviseur [au sens du système technologique de supervision] est l’outil à travers lequel un exploitant
visualise en temps réel l’état et l’évolution d’une installation industrielle automatisée” (Pradenc 92, cité par Poulain
94). Les objectifs du couple “superviseur et exploitant” ne sont pas restreints aux activités purement liées à la
visualisation des données du système de production. Il faut aussi y intégrer la conduite de l’installation en agissant sur
les commandes, la gestion de la production en termes de cadence, de qualité ou encore de quantité de produit, tout en
veillant à la sécurité des installations, des hommes et de l’environnement.

I.1. Architecture du système homme-machine

Un système homme-machine consiste en une synthèse fonctionnelle entre un homme et un système technologique.
Il est composé au minimum d’un opérateur humain, d’une machine et d’une interface permettant la communication
entre les deux (Johannsen 82). Dans ce contexte, l’opérateur de supervision effectue deux “activités” complémentaires
(Moray 86) :

• la surveillance (“monitoring”), consistant en l’examen de données formelles ou informelles qui l’informent de

l’état du procédé (affichages, alarmes, bruits, odeurs, vibrations…). Le but de l’opérateur est de décider en
fonction de ces informations si le système est dans un état normal de fonctionnement et toujours sous contrôle.

• le contrôle supervisé (“supervisory control”), où l’opérateur applique des commandes à destination du procédé
via un “contrôleur intelligent” (interface, autre opérateur…).

Sheridan (85) décrit un système de conduite de procédé industriel fortement automatisé comme une architecture
hiérarchique en quatre niveaux (fig. I.1) : le procédé (1), constitué de plusieurs sous-systèmes ; la régulation (2),
assurée par des calculateurs locaux, automates programmables industriels, etc. ; le calculateur de supervision (3),
coordinateur du fonctionnement de l’ensemble des sous-systèmes ; et l’opérateur de supervision (4) qui contrôle et
assure le bon fonctionnement du procédé. Un système d’assistance à l’opérateur peut s’y ajouter. Il est directement
connecté au calculateur de supervision et l’interaction avec l’opérateur passe par l’interface.
 Chapitre I 20

Opérateur de
supervision
4
Communication des informations, Commandes ou demandes
présentation des variables du procédé d'informations
SYSTÈME DE
CONDUITE ET DE Interface Opérateur-calculateur
RÉGULATION
3
Calculateur Système
de d'assistance
supervision à l'opérateur

2 Calculateur Calculateur Calculateur

local 1 local 2 … local n

Sous-système Sous-système … Sous-système

1 1 2 n
PROCEDE

Figure I.1 : Architecture des systèmes de supervision de procédés

fortement automatisés (Sheridan 85)

Dans une telle architecture, le rôle de l’opérateur est fonction du degré d’automatisation de la machine. Bien
qu’éloigné du procédé concret, l’homme s’avère donc toujours indispensable, notamment lors des régimes transitoires,
en cas de dysfonctionnements. Il peut aller du simple intervenant dans la boucle de commande à celui de “maître” de
la machine lorsqu’il en contrôle toutes les fonctions. L’IHM s’avère donc essentielle car c’est elle qui fournit,
partiellement ou totalement, les informations à l’opérateur.

Ainsi, quel que soit le système automatisé étudié, la réalisation d’une interface homme-machine adaptée est
primordiale. C’est elle qui doit établir les correspondances entre la tâche de l’homme et les fonctionnalités du procédé,
d’où l’importance de la qualité du dialogue entre les deux. Or, on constate que les développements mis en œuvre ne
donnent pas toujours les résultats escomptés.

I.2. La qualité du dialogue homme-machine

La visualisation et plus généralement, l’utilisation des données fournies par les interfaces doit être aisée et efficace,
dans le but d’améliorer la rapidité et la fiabilité des décisions et actions humaines. Pourtant, un ensemble de
problèmes ergonomiques1 est rencontré lors de la conception et de l’utilisation des systèmes de supervision.

En effet, il y a une trentaine d’années, l’homme était intégré dans la boucle de régulation ; il mesurait lui-même les
variables, les évaluait et les corrigeait. Après l’introduction des automates programmables industriels avec lesquels
l’opérateur assignait un objectif à chaque boucle de régulation et surveillait leur bon fonctionnement, sont apparus les
systèmes de supervision. Cette fois, c’est le calculateur qui assure une grande partie des fonctions (Neboit et al. 90).
Dans ces salles de contrôle, l’opérateur est la plupart du temps éloigné de la réalité du terrain et des installations. Il
travaille essentiellement à travers une interface graphique lui donnant une représentation plus ou moins réaliste du
procédé, à l’aide de modes de présentation spécifiques (synoptiques, courbes, barre-graphe, graphe de fluence, etc.).

Dans de tels systèmes, le “superviseur” humain a principalement un rôle de “décideur” avec des tâches
essentiellement mentales de résolution de problèmes (détection et anticipation des défauts, diagnostic et reprise des

1
Les anglo-saxons parlent de “Human factors” pour désigner ce que nous appelons “ergonomie”, laissant au terme
“ergonomics” son sens ancien lié aux seuls aspects physiologiques.
 Chapitre I 21

dysfonctionnements…). Il prend des décisions et effectue des actions sur le procédé, tout en étant plongé dans “un
monde virtuel” dans lequel l’ergonomie de conception des outils graphiques est d’une importance fondamentale.

En 1989, une étude de Chardavoine et Lejon (citée par Poulain 94) a mis en évidence la qualité souvent
relativement médiocre de la communication homme-système de supervision. D’après les auteurs cela est
principalement dû au passage des systèmes analogiques aux systèmes numériques à la fin des années 70. L’évolution
consistait alors à transposer directement, sans analyse, les appareillages classiques vers la console et le clavier. Cinq
points noirs ont été dégagés par cette étude :

• Le morcellement des informations : décomposition plus ou moins arbitraire des tableaux muraux et leur
recopie en différentes vues textuelles ou graphiques sur écran. Ce découpage, dû principalement à la taille
réduite des écrans, a engendré la perte de “corrélation floue” entre informations. En effet, à partir de la vision
globale des anciens pupitres de supervision et en raison de son expérience, l’opérateur pouvait se construire une
image mentale pour chacun des états de fonctionnement du procédé. 2

• La conduite sur exception : avec beaucoup de vues de supervision la probabilité que l’opérateur se trouve sur
la bonne vue au moment de l’incident est faible. L’introduction des systèmes numériques a nécessité d’ajouter
beaucoup d’alarmes pour signaler des débuts d’anormalité. Cela peut inciter une conduite sous sollicitation
d’alarmes (donc sans anticipation) ; de plus, leur trop grand nombre peut engendrer des avalanches d’alarmes.

• L’abandon de la conduite sur tendance : certains systèmes numériques de contrôle commande (SNCC) sont
mal conçus en ce qui concerne la présentation des tendances. Celles-ci sont souvent utilisées a posteriori à des
fins de diagnostic ou pour des réglages fins de conduite et non plus pour la conduite prédictive ou préventive.

• La non prise en compte des conduites multi-opérateurs : dès que l’on quitte la marche stable, c’est plus
souvent une équipe qui essaie de résoudre le problème et non plus un opérateur isolé. Or les SNCC sont mal
adaptés à la conduite multi-opérateurs.

• L’opposition d’action opérateur-automatisme : la plupart des installations sont dotées d’automatismes pour
éviter la violation des contraintes de sécurité. L’opérateur a tendance à essayer de contrer les automatismes de
manière à éviter l’arrêt automatique de l’installation, ce qui peut conduire à des situations dramatiques voire
irréversibles.

Shepherd (93) confirme de tels points en mettant en évidence des cassures du cycle de résolution de problème des
opérateurs, pendant la supervision, dû à la pauvreté des interfaces. Souvent, celles-ci ne permettent pas à l’homme de
voir l’information nécessaire au contrôle en cours. De plus, la fragmentation des informations l’oblige à examiner
différents items dans des écrans séparés avant d’inférer son raisonnement.

Pour remédier à de tels problèmes, des travaux ont été consacrés à la présentation des informations sur écran et
fournissent de nombreuses recommandations (de Keyser 80 ; Gilmore et al. 89 ; Kolski 93). Mais celles-ci s’avèrent
insuffisantes si les besoins informationnels des opérateurs ne sont pas pris en compte (nécessité d’une analyse de la
tâche). Dans ce cas, les conséquences ergonomiques sont variées : mauvaise structuration de l’imagerie, oublis
d’informations nécessaires à l’opérateur, représentations inadaptées, etc. Ces lacunes conduisent inévitablement à des
erreurs humaines (Leplat 85 ; Reason 90).

I.3.Conclusion
Dans les systèmes complexes fortement automatisés où les fonctions de décision et de traitement de l’information
deviennent de plus en plus complexes, la qualité du dialogue homme-machine est primordiale. En effet, l’opérateur
qui assure la surveillance et la commande des installations est relativement passif pendant la phase de surveillance.

2
Ce phénomène a été constaté lors de plusieurs travaux sur l’analyse de l’activité des opérateurs de conduite de la
chaufferie nucléaire dans les sous-marins d’ancienne génération (Berger 91 ; Salazar-Ferrer 91 ; Grislin et al. 92b).
 Chapitre I 22

Par contre, il est dangereusement sollicité en phase de dysfonctionnement critique. C’est pourquoi il faut donner un
vrai sens au mot “dialogue” en dotant les postes de supervision d’indicateurs simples et efficaces permettant de bien
informer les opérateurs et de fournir des outils d’aide adaptés aux situations critiques.

De plus, les performances des IHM, par leur rapidité, dépassent parfois les capacités d’assimilation des opérateurs
humains. Par exemple, lors de l’accident de Three Mile Island, l’évolution trop rapide des paramètres de supervision
et le manque de trace de cette évolution ont, entre autres, gêné les opérateurs dans leur diagnostic. De façon
symétrique, la lenteur d’un système de supervision engendre aussi des erreurs. Par exemple, le rafraîchissement
retardé d’un écran de contrôle dû à un traitement numérique trop long peut masquer une évolution importante du
procédé. De plus, certaines interfaces engendrent un manque d’initiative de l’homme face à la machine qui impose sa
logique. On peut aussi noter que la mesure et la visualisation des paramètres pertinents n’est pas toujours possible, et
les données recueillies ne sont pas toujours fiables.

Il est indispensable que les acteurs intervenant dans la phase de conception de ces interfaces tiennent compte des
capacités de l’homme. Cette tâche est loin d’être triviale pour l’équipe de développement.

II. L E DÉVELOPPEMENT DES I NTERFACES H OMME -M ACHINE

Plusieurs auteurs cités par Scapin en 1988, mettent en évidence des lacunes dans la prise en compte de l’ergonomie
au sein du processus de conception de l’IHM (fig. I.2). Ils se posent par conséquent des questions sur la description
des tâches humaines et le manque d’outils pour passer de l’analyse à la conception.

équipe de
développement difficultés de pas d'outils pour
lacunes de lacunes de lacunes de description passer de l'analyse
théorisation formalisation méthode de la tâche à la conception

Figure I.2 : Obstacles au développement des IHM

Il n’existe pas de démarche unique pour concevoir des systèmes homme-machine. De nombreux ouvrages y sont
consacrés mais les méthodes et outils proposés y sont souvent partiels. Divers travaux issus de l’ergonomie, de
l’automatique humaine et de l’informatique proposent à ce sujet des démarches applicables au développement d’IHM
(entre autres : Daniellou 86 ; Sperandio 88 ; Barthet 88 ; Abed 90 ; Millot 90 ; Coutaz 90 ; Nielsen 93 ; Kolski 95).

Dans la mesure où nous nous intéressons à l’évaluation d’applications de supervision, qui sont avant tout des
logiciels, nous aborderons succinctement les modèles les plus utilisés actuellement pour leur développement.

II.1.Les cycles de vie du génie logiciel

Le génie logiciel est défini comme “l’ensemble des procédures, méthodes, langages, ateliers, imposés ou
préconisés par les normes adaptées à l’environnement d’utilisation, afin de favoriser la production et la maintenance
de composants logiciels de qualité” (Jaulent 90). Le cycle de vie du logiciel est généralement composé d’un ensemble
d’étapes décrites sous la forme d’un enchaînement propre.

Parmi ces différents cycles, les plus connus s’inspirent du modèle en cascade (“Waterfall” fig. I.3a, Boehm 82),
affiné sous différentes formes pour aboutir au modèle en V (présenté dans le paragraphe suivant), jusqu’au plus récent
modèle en spirale (fig. I.3b, Boehm 88).3

3
Voir aussi, Sommerville (88), AFNOR (89), et surtout Balbo (94) pour une discussion sur l’évolution des cycles de vie
et notamment la prise en compte de l’évaluation lors des étapes du développement des interfaces utilisateurs.
 Chapitre I 23

Cycle en Cascade Cycle en Spirale

Coût cumulé
Faisabilité
Détermination des Evaluation des alternatives
Spécification objectifs, des choix Identification et résolution
et des contraintes des risques
Conception
préliminaire
analyse de risque
Conception
détaillée prototypage
Bilan
Codage - Tests Répartition besoins simulation…
unitaires des tâches developpement specif.
tests
Intégration integration conception
Planification des implémentation
Implémentation phases suivantes
Développement
Vérification du produit
Exploitation
au niveau suivant
Maintenance

Figure I.3 : Deux modèles de cycles de vie utilisés en génie logiciel

(cycles en cascade et en spirale)

Ces cycles ont en commun un ensemble d’étapes qui sont : l’identification des besoins qui consiste en une prise de
connaissance du projet et de la demande ; l’analyse du système dans différents modes de fonctionnement (normaux et
anormaux) ; la spécification où sont définis l’architecture de l’interface, les enchaînements graphiques, la présentation
d’information et des traitements spécifiques éventuels ; la conception qui consiste à définir une architecture matérielle
et logicielle qui réponde à l’analyse des besoins et aux contraintes ; l’implémentation et le codage qui intègrent en
particulier la réalisation proprement dite de l’interface ; les tests (souvent essentiellement techniques) qui ont pour
objectif de vérifier si le système réalisé répond à un ensemble de besoins ; enfin l’exploitation qui concerne la mise en
service du système sur site, son exploitation, le suivi et la maintenance (Poulain 94).

II.2.Le cycle de vie en V

Le cycle de vie en V d’un système, préconisé par l’Association Française pour le Contrôle Industriel de la Qualité
(AFCIQ), propose un découpage normalisé (fig. I.4, Forse 89 ; Jaulent 90). Ce cycle de vie servira de base de
réflexion dans le chapitre IV ; ses grandes lignes sont donc présentées ici. De plus amples détails concernant le
développement de l’interface sont fournis en annexe A.

Le cycle en V représente la vie d’un système comme une succession d’étapes qui commence par l’analyse des
besoins dans la phase descendante du V pour aboutir à la réalisation concrète du produit. Puis, on remonte le long du
cycle en réalisant des tests, l’intégration puis la recette. L’exploitation et la maintenance visent le suivi du système
jusqu’à son démantèlement. Cette démarche est donc décomposée en six phases : (1) orientation, faisabilité, (2)
conception préliminaire et détaillée du système, (3) développement logiciel, (4) intégration matérielle et logicielle,
production du système, (5) recette et validation du système et (6) exploitation et maintenance du système. Les phases
de conception (2) et de développement du logiciel (3) sont elles-mêmes décomposées en sous-phases plus détaillées.
 Chapitre I 24

CYCLE DE VIE Exploitation

Orientation (1) D'UN SYSTEME
faisabilité (6) Maintenance du
BESOIN PRODUIT
système

Conception Recette système

Certification
préliminaire du validation du
système (5) système
(2)
Conception (4) Intégration
détaillée du Validation matériel-logiciel
système production

Spécification
Validation Validation du
Spécification fonctionnelle
logiciel Validation
du logiciel
(3)
Conception Intégration
préliminaire Vérification et tests
du logiciel d'intégration

Conception
Tests unitaires
détaillée du
du logiciel
logiciel
Conception Réalisation

Programmation
Codage CYCLE DE VIE DU
LOGICIEL (AFCIQ)

Figure I.4 : Cycle de vie en V d’un système

(les flèches en trait grisé-épais numérotées de 1 à 6, traduisent la séquence temporelle des étapes)

L’originalité du cycle en V vient du fait que les étapes ne sont pas indépendantes les unes des autres. En effet, la
détection d’un problème à un instant quelconque du cycle nécessite une correction et pour ce faire, un retour en
arrière. Les étapes initiales ont donc une influence prépondérante sur la vie du système (besoin à satisfaire, qualité
globale, coût, temps…).

Afin d’améliorer le dialogue entre l’homme et la machine, il est primordial de suivre une démarche de
développement rigoureuse pour, à la fois, la machine à superviser et l’interface de supervision. C’est pourquoi nous
présentons la démarche adoptée au LAMIH dans le paragraphe suivant.

II.3.Le cycle de vie en V vis-à-vis de la méthode en U du LAMIH

La démarche en U de conception-évaluation proposée au LAMIH pour le développement de systèmes homme-
machine, positionne l’IHM selon le principe de la figure I.5. Celle-ci est composée de deux phases : descendante et
ascendante.

La phase descendante de conception débouche sur la réalisation et l’intégration du système homme-machine à

partir des caractéristiques techniques du procédé et des objectifs qui lui ont été assignés. L’aspect primordial de cette
phase est l’analyse des différentes tâches à effectuer (tâches prescrites), analyse préalable à la répartition a priori des
tâches entre l’homme et la machine. En outre, cette analyse doit porter à la fois sur les conditions normales de
fonctionnement et les modes de fonctionnement anormaux. En effet, c’est l’ensemble des tâches de surveillance, de
contrôle et de reprise de défaut qui constitue les tâches prescrites des automatismes et de l’opérateur. Ces tâches
devront toutes satisfaire des critères spécifiques à la machine et à l’homme.
 Chapitre I 25

La méthode suivie pour l’analyse et la description du système homme-machine doit permettre de mettre en
évidence, de manière précise et exhaustive, des informations pertinentes sur la tâche avant la réalisation de l’IHM, du
point de vue : du découpage en sous-tâches (ou sous-buts) et de leurs rapports logiques, fonctionnels, séquentiels
(relations d’existence et/ou, relations de précédence avant/après/en même temps) ; des listes d’informations par
opération élémentaire et de leur pertinence ; des regroupements d’informations (listes, groupes, associations) ; des
dénominations habituellement utilisées dans l’exécution des tâches.

caractéristiques techniques et PHASE ASCENDANTE

contextes de objectifs du procédé
fonctionnement du
D'ÉVALUATION
procédé (normaux, analyse du procédé et
anormaux) du système de contrôle modèle général des activités
tâches à réaliser de l'opérateur humain
(limites, ressources)
analyse des tâches prescrites
besoins en assistance
validation affinage
besoins modèle des • interfaces H-M
choix du degré d'automatisation informationnels
et du mode de coopération H-M tâches humaines • modes de coopération H-M
modèle des activités
mode de
tâches de analyse cognitive des activités
coopération
coopération traitement de données
définition des définition des
outils outils mesures
contextes, scénario système H-M
d'automatisation d'assistance
(fonctionnements normaux et réel ou simulé
anormaux, coopération H-M)
mesures à effectuer
spécifications de l'IHM Critères (types, méthodes)
Ergonomiques définition des
protocoles expérimentaux
implémentation / intégration
du système H-M Objectifs de l'évaluation

IHM
PHASE DESCENDANTE
DE CONCEPTION

Figure I.5 : Démarche en U de conception-évaluation d’un système homme-machine

(adaptée de Abed 90 ; Millot 90 ; Debernard 93)

Comme la connaissance actuelle sur l’opérateur humain et les aspects cognitifs de son travail est trop incomplète
pour envisager la conception “en boucle ouverte”, il est indispensable d’avoir recours à une phase d’évaluation. C’est
le rôle de la phase ascendante de la démarche.

La phase ascendante d’évaluation du système homme-machine consiste à évaluer et valider l’interface proposée.
Elle porte généralement sur l’atteinte des objectifs assignés au système global (quantification par des critères de
production, de performance, etc.), le respect des consignes de sécurité de l’installation, le jugement de l’opérateur
concernant notamment l’interface de dialogue et les systèmes d’aide éventuels et enfin le “coût du travail” pour
l’opérateur. L’analyse de l’activité de l’opérateur constitue une étape importante de la phase d’évaluation.

Le choix de la démarche globale de développement de l’IHM dépend principalement des habitudes de travail de
l’équipe de développement plus que de l’adéquation au contexte de la démarche elle-même. Par exemple, dans le
domaine de l’automatisation des systèmes de production, c’est le cycle en V qui est actuellement le mieux accepté
(PRNF 92 ; Popieul 94). C’est de plus celui qui est retenu dans la démarche qualité de l’ISO 9000. Qu’en est-il pour
des interfaces de supervision ?

Pour le développement des interfaces, la phase 3 de développement logiciel du cycle en V —zone grisée sur la
figure I.4— peut être mise en corrélation avec la démarche descendante-ascendante qui vient d’être discutée.
Remarquons que le cycle de vie du logiciel constitue une couche qui peut être spécifique à l’interface (voir l’annexe
 Chapitre I 26

A). Ce principe des couches successives concernant le matériel, la partie opératoire, le logiciel et l’interface rejoint
l’évolution actuelle de l’architecture des IHM graphiques, dans lesquelles le traitement des données est séparé de la
gestion de l’affichage.

De plus, le modèle en V peut intégrer les principes du modèle spirale dans sa phase descendante et donc faciliter le
prototypage. Une démarche proposée par Poulain (94) pour le développement de synoptiques de supervision s’en
inspire. En effet, avec le modèle en V, la préparation, dès les étapes de spécification et de conception, des données qui
seront nécessaires lors des étapes de réalisation et de validation incite à formaliser et à identifier le plus tôt possible les
points critiques pouvant apparaître à la fin du projet.

Toutefois, ce cycle de vie ne permet pas la détection précoce de problèmes ergonomiques pouvant entraîner des
difficultés d’utilisation. En effet, seules les évaluations a posteriori lors de la phase ascendante (une fois l’interface
codée) sont réalisées. Aussi, plus les défauts sont détectés tardivement, plus le retour sera proche du début et imposera
de nouveau le parcours quasiment complet du cycle. Le temps de développement en sera allongé et donc le coût
augmenté : d’un facteur dix si le défaut est détecté lors des spécifications, jusqu’au million après la livraison, dans
certains cas (Balbo 94). Ne serait-il pas possible de réaliser certaines évaluations prédictives dès la spécification ou la
conception de l’interface ? Dans ce cas, non seulement le coût de modification des erreurs détectées tardivement sera
diminué, mais aussi, le “stress” engendré par les phases de tests finaux et de validation sera moindre. Cette limitation
de pression sur l’équipe de développement agira directement sur la qualité du produit développé. L’objectif de nos
recherches a donc été de ramener l’évaluation le plus en amont possible dans le développement.

II.4.Conclusion sur le développement des IHM

Les constats énoncés tout au long de cette partie, nous amènent à souligner, comme plusieurs autres auteurs, qu’il
est important, dès l’analyse de la tâche, de connaître les objectifs du projet, les besoins de l’utilisateur et donc avant
tout, de déterminer précisément la tâche de l’opérateur.

Actuellement, le génie logiciel est en pleine effervescence et on assiste à l’avènement de nombreuses méthodes,
modèles, techniques, qui visent à couvrir l’ensemble des étapes du cycle de vie (Jacobson et al. 93 ; Booch 94 ;
Denning et al. 94 ; Curtis et al. 94). Mais, dans la majorité des cas, la conception des interactions homme-machine et
l’évaluation de leur qualité n’apparaissent pas explicitement et systématiquement dans ces étapes.

Pourtant, les applications informatiques interactives sont de plus en plus répandues. Du point de vue des facteurs
humains, il est évident que la qualité de l’IHM est cruciale pour leur efficacité, leur utilisabilité 4 et leur acceptabilité
auprès des utilisateurs, ceci particulièrement pour les systèmes homme-machine complexes où les contraintes
d’utilisation sont sévères en termes de sécurité, économie, production. Sachant que pour ces applications, le coût de
programmation de l’interface peut constituer plus de la moitié du coût total du logiciel (Bass et al. 91), l’utilisation de
méthodes et de techniques d’évaluation s’impose pour l’équipe chargée du développement.

III. L’ ÉVALUATION DES I NTERFACES H OMME -M ACHINE

Avant de recenser la plupart des méthodes et techniques issues de la littérature, il est nécessaire de mieux préciser
le principe de l’évaluation.

III.1. Principe de l’évaluation

L’IHM doit être considérée en tant que composant du système homme-machine global. Dans ces conditions, son
évaluation consiste à le vérifier et à chercher à le valider. Le système homme-machine est vérifié, s’il correspond aux
spécifications issues de la définition des besoins. Il est validé, s’il correspond aux besoins en respectant les contraintes
4
Le barbarisme “utilisabilité” traduit le concept anglais “usability”. Il est défini par la norme ISO 9241 comme “[…]
l’efficacité, la fiabilité et la satisfaction avec laquelle des utilisateurs spécifiques atteignent des objectifs spécifiques dans un
environnement particulier.”
 Chapitre I 27

du domaine d’application (sécurité, production, ergonomie…) ; sinon ses insuffisances par rapport à des critères
identifiés a priori sont mises en évidence et doivent être corrigées.

L’évaluation ergonomique d’une IHM consiste à s’assurer que l’utilisateur est capable de réaliser sa tâche au
moyen du système de communication qui lui est proposé. Pour Senach (90), “Toute évaluation consiste à comparer un
modèle de l’objet évalué à un modèle de référence permettant d’établir des conclusions.”. Nous expliquerons plus en
détail ce principe d’évaluation à partir du chapitre III.

Lors de l’évaluation de logiciel interactif, le modèle que l’on peut qualifier d’observé (ou d’analysé) est donc
comparé à un modèle de référence. Ce modèle est représentatif de l’adéquation de l’IHM évaluée, par rapport aux
besoins spécifiques définis par le concepteur 5 (fig. I.6). Dans ce cas, le modèle de référence est établi à partir de règles
ergonomiques extraites par exemple des normes, ou des guides ergonomiques.

Propriétés de l'évaluation
Données de bases
Techniques de recueil de données

SYSTÈME À ÉVALUER Modèle

observé
Sous-système 1
Niveau d'adéquation de
Sous-système 2 l'interface par rapport
PROCÉDÉ aux besoins
……
Modèle de
Sous-système n référence
Modèle de
l'évaluateur

Figure I.6 : Principe de l’évaluation

Pour des systèmes de supervision, nous verrons qu’une évaluation basée sur une comparaison n’est pas simple. Ce
principe va plutôt aider à décrire un modèle d’une interface capable de répondre aux besoins de l’opérateur en terme
de tâche. Ce modèle dit de référence —nous l’appellerons plutôt “modèle de l’évaluateur”— correspond en fait à un
modèle que va se construire l’équipe d’évaluation en prenant en compte des propriétés que doit respecter l’interface.

Ces propriétés qui sont l’utilité et l’utilisabilité (définies plus loin) doivent être “introduites” dans le modèle ou
prise en compte dans la démarche. De plus, la modélisation nécessite la définition de variables cibles —les
informations d’entrées— recueillies au moyen de techniques de recueil de données.

La construction et la validation des modèles utilisés constituent les principales sources de difficulté pour une bonne
évaluation. Ceux-ci consistent en une description formelle du dialogue entre l’opérateur de supervision et la machine.
Comme l’interaction homme-machine est difficile à décrire de manière simple —il existe souvent un écart entre la
théorie formalisée et la réalité—, le problème est de savoir si l’on peut se fier aux résultats d’une évaluation basée sur
une représentation plus ou moins éloignée de la réalité. Nous verrons que la construction de cette représentation
dédiée évaluation ergonomique dépend fortement de l’approche utilisée.

En outre, l’interaction homme-machine qui à un certain niveau correspond à la tâche de l’opérateur, peut être vue
selon trois descriptions de l’interface du point de vue des intervenants sur le système (fig. I.7) : le modèle conceptuel
du concepteur, le modèle de l’utilisateur et le modèle de l’évaluateur (Norman 86).

La modélisation a pour objet de décrire le système et déduire ce dont l’utilisateur a besoin pour réaliser sa tâche. Il
faut distinguer le modèle conceptuel de la machine créé par le concepteur d’interface, et la représentation mentale que
se fait l’utilisateur du système, construite progressivement par la pratique à partir de ses acquis antérieurs et de ses
interactions. Cette représentation de l’utilisateur est en relation avec l’image qu’a voulu en donner le concepteur.

5
Pour des raisons de clarté, nous utilisons le terme concepteur pour parler d’équipe de conception. De la même manière
l’évaluateur représente une équipe qui intervient tout au long du cycle de développement des systèmes interactifs. Notons
que ces deux équipes ne sont pas forcément disjointes (nous y reviendrons au §III.4).
 Chapitre I 28

contraintes techniques
tâche de l'application
tâche de l'interface
spécifications capture des informations
choix techniques pertinentes pour l'évaluation
exigences Modèle du
expériences concepteur
…
tâche de l'opérateur Modèle évaluation
contraintes de production Modèle de ergonomique
qualité, sécurité l'utilisateur de l'IHM
préférences utilité
… Modèle de
utilisabilité l'évaluateur
analyse de la tâche
recommandations ergonomiques
choix de techniques d'évaluation
données à recueillir
…

Figure I.7 : Trois points de vue du modèle ergonomique de l’IHM pour l’évaluation

Pour l’évaluateur, la construction du modèle de l’IHM est dirigée par le contexte ; c’est-à-dire que la sélection des
propriétés pertinentes pour le diagnostic de la qualité ergonomique dépend non seulement des objectifs de l’évaluation
mais aussi des caractéristiques de la population et des exigences des tâches. La richesse des fonctionnalités et la
facilité d’utilisation d’une interface sont deux propriétés importantes définies sous les termes utilité et utilisabilité
(fig. I.8) :

EVALUATION IHM

UTILITE "UTILISABILITE"
• capacité fonctionnelle, • facilité d'apprentissage,
• performance du système, • facilité d'utilisation,
• qualité de l'assistance, • qualité de la documentation,
•… •…
qualité ergonomique
cohérence cohérence
interne externe

Figure I.8 : Deux propriétés pour l’évaluation d’une IHM : l’utilité et l’utilisabilité (Senach 90)

• L’utilité détermine si l’interface permet à l’utilisateur d’atteindre ses objectifs de travail. Elle correspond par
exemple aux capacités fonctionnelles, aux performances et à la qualité de l’assistance technique fournie à
l’utilisateur par le système.

• L’utilisabilité rend compte de la qualité de l’interaction homme-machine, en termes particulièrement de facilité

d’apprentissage et d’utilisation, ainsi que de qualité de la documentation.

Le concept d’utilisabilité a été proposé par Eason (84) et affiné récemment par Nielsen (93) pour différencier
l’utilité potentielle d’un produit de son utilité réelle. Ce critère constitue en quelque sorte une frontière entre les deux.
En effet, fréquemment, l’ajout à l’interface de fonctionnalités censées faciliter l’exploitation a pour effet pervers de
compliquer la tâche. L’utilisabilité reflète aussi la “cohérence de la conception” qui est à la fois la cohérence interne :
régularité des décisions du concepteur (langage de commande bien structuré, position invariante de l’affichage…), et
la cohérence externe : adéquation des tâches au fonctionnement cognitif des utilisateurs.

Pour l’évaluation, il faudra donc se construire un modèle a priori de l’interaction homme-machine en prenant en
compte l’utilité et l’utilisabilité de l’interface. En outre, il est important de bien délimiter le niveau de précision du
modèle afin de pouvoir observer et faire ressortir les aspects pertinents vis-à-vis des objectifs du système. Il s’agit
donc de déterminer ce qui permettra de porter un jugement sur l’IHM concernée.
 Chapitre I 29

III.2. Les données de base à recueillir

Avant d’évaluer, il convient de définir le plus tôt possible quelles seront les variables à observer et bien sûr la
manière de les recueillir. L’analyse de l’IHM doit mettre à jour un ensemble de variables cibles, c’est-à-dire les
données de base à recueillir. Ce sont en effet, le système à évaluer et son utilisation qui définissent le comportement
que l’on mesure lors d’une évaluation.

Comme nous le constaterons progressivement, l’évaluation des IHM regroupe un grand nombre de méthodes
empruntées à diverses disciplines. Pourtant, pour une évaluation ergonomique, ce ne sont ni les méthodes ni les
techniques qui priment, mais les données. C’est leur type, leur structure et leurs difficultés d’obtention qui
déterminent les méthodes de recueil et d’analyse les mieux adaptées (Sperandio 91). Sans oublier qu’elles sont très
imbriquées, il ne s’agit pas de tout enregistrer pour analyser ensuite, mais de bien savoir de quoi il s’agit pour utiliser
la bonne méthode de recueil. C’est pourquoi nous exposons les données à recueillir avant d’expliquer les méthodes et
techniques d’évaluation possibles : avant de savoir comment évaluer, il faut savoir ce que l’on observe.

La figure I.9 présente quelques unes des principales variables dépendantes utilisées pour l’évaluation des IHM
usuelles. Deux grandes familles se distinguent : l’acceptabilité sociale et l’acceptabilité pratique. La seconde classe
comprend les contraintes courantes de production, de coût, de fiabilité… mais aussi la facilité d’utilisation qui
concerne principalement l’IHM. C’est dans ce critère d’utilisation que l’on retrouve les deux propriétés citées
précédemment et plus particulièrement l’utilisabilité de l’interface.

Acceptabilité Utilité
sociale
Acceptabilité Facilité d'utilisation Facile à apprendre
du système Coût Utilisation efficace
Acceptabilité Compatibilité Utilisabilité Facile à mémoriser
pratique Fiabilité Peu d'erreurs
Etc. Préférence subjective
…

Figure I.9 : Principales variables cibles pour l’évaluation des IHM (traduit de Nielsen 93)

La littérature propose un très grand nombre de recommandations ergonomiques sous forme de guides (Smith et al.
86 ; Scapin 87 ; Brown 88 ; Vanderdonckt 94) ou de standards (BSI 91/40677, ISO 9241). Pour l’évaluation, il s’agit
soit de les utiliser comme propriétés à observer ou mesurer, soit d’en extraire des critères ergonomiques
d’évaluation. En se basant sur plusieurs travaux de recherche (Smith et al. 86 ; Scapin 90 ; Whitefield et al. 91), une
classification de ces informations a été proposée par Bastien et Scapin (93) pour aboutir à un jeu de critères et sous-
critères qui prennent en compte ces recommandations. Dix-huit critères élémentaires sont ainsi énumérés et explicités
dans les tableaux I.1 (nous les avons utilisés tout au long de notre travail). Plusieurs études ont montré qu’ils
pouvaient servir de descripteurs pour l’évaluation des IHM et ont validé leur définition (Bastien 91 ; Pollier 92 ;
Bonnardel 92).

Tableau I.1 : Critères ergonomiques d’évaluation (critères en gras, numérotés)

Critères Principe et Objectif
Le guidage : moyens mis en œuvre pour conseiller, orienter, informer et conduire l’utilisateur lors de l’interaction avec la
machine (localisation dans les séquences, actions permises et leurs conséquences, information sur demande.
Incitation (1) Informations fournies à l’utilisateur sur l’état dans lequel il se trouve, actions possibles ou attendues et
“Prompting” moyens de les mettre en œuvre. Une bonne incitation guide et évite par exemple d’avoir à apprendre une
série de commandes, permet aussi de connaître le mode et la position dans le dialogue (aides disponibles,
format adéquat d’entrée de données, unités de mesure…).
Groupement par Positionnement des items les uns par rapport aux autres pour indiquer leur appartenance ou non à une même
localisation (2) classe, ou leur distinction : repérage (mémorisation), organisation logique (listes hiérarchiques, groupement
des options en fonction des objets sur lesquels elles s’appliquent…).
Groupement par Indices graphiques (format, couleur) des items les uns par rapport aux autres pour indiquer leur
format (3) appartenance ou non à une même classe, ou leur distinction (facilité à reconnaître les liens entre
informations, distinguer les aires de fonctions, ou les labels et champs d’entrées…).
 Chapitre I 30

Tableau I.1 : (suite)

Retour Réponses de la machine après des actions de l’utilisateur (temps le plus court possible). Le retour
informatif d’information engendre la confiance et la satisfaction de l’utilisateur comme la compréhension du dialogue.
immédiat (4) (toujours faire apparaître les entrées utilisateur à l’écran sauf si confidentielles, si plusieurs curseurs sont
“Feed-back” présents à l’écran indiquer celui qui est actif…).
Clarté (5) Caractéristiques lexicales de présentation des informations : facilité de lecture (textes en sombre sur fond
clair plus faciles à lire que l’inverse, textes en Majuscules et minuscules plus rapidement lus qu’en
MAJUSCULES, titres centrés, curseur repérable…).
La charge de travail : coût du travail pour l’utilisateur, quantité de travail (mentale et physique) investie. Les surcharges comme les sous-
charges (génératrices de baisse de vigilance) ne sont pas acceptables car elles sont la cause, à plus ou moins long terme, d’une défaillance de
l’utilisateur et donc du système homme-machine.
Concision (6) Charge de travail perceptive et mnésique en rapport avec des éléments individuels d’entrée/sortie : capacités
de la mémoire à court terme limitées (pas de codes supérieurs à 4 ou 5 caractères ou alors, utiliser des
mnémoniques ou abréviations, entrer des données courtes…).
Actions Charge de travail au niveau des options ou moyens utilisés pour atteindre un but (minimum d’étapes dans la
minimales (7) sélection, saisie unique des données, éviter la ponctuation des commandes…).
Charge mentale Charge de travail perceptive et mnésique pour des ensembles d’éléments : éviter d’imposer la mémorisation
(8) de longues et nombreuses informations, procédures, ou activités nécessitant une activité cognitive complexe
Densité (limiter la densité des informations, n’afficher que ce qui est nécessaire, l’information ne doit pas nécessiter
informationnelle de traduction d’unités…).
Le contrôle explicite : correspond à la fois au contrôle qu’a l’utilisateur sur l’interface et le caractère explicite de ses actions. Le contrôle du
dialogue par l’utilisateur est un facteur d’acceptation du système.
Actions explicites Relation entre le fonctionnement de l’application et les actions des utilisateurs : le système doit exécuter
(9) seulement les opérations demandées par l’utilisateur et ce, au moment où il les demande (action explicite de
validation après sélection d’une option par pointage, l’entrée de commande doit se terminer par < ENTER>
avec des possibilités d’édition au préalable…).
Contrôle L’utilisateur doit toujours “avoir la main” et donc pouvoir contrôler le déroulement des traitements en cours.
utilisateur (10) Ses actions doivent être anticipées et des options appropriées fournies pour chaque cas, l’utilisateur doit
toujours pouvoir intervenir (le curseur ne peut se déplacer sans contrôle de l’utilisateur, l’utilisateur doit
toujours être maître de la vitesse de dialogue…).
L’adaptabilité : capacité du système à réagir selon le contexte, les besoins et préférences de l’utilisateur. Une IHM ne peut convenir à la fois
à tous les utilisateurs potentiels. Pour qu’elle n’ait pas d’effets négatifs, elle doit s’adapter.
Flexibilité (11) Moyens mis à la disposition de l’utilisateur pour la personnalisation de l’interface afin d’adopter ses propres
stratégies ou habitudes de travail (différentes façons d’atteindre un même objectif, capacité de l’interface à
être adaptée à des actions variées de l’utilisateur, désactivation temporairement des affichages inutiles, de
configuration des entrées par défaut…).
Prise en compte Moyens mis en œuvre pour permettre au système de respecter le niveau d’expertise de l’utilisateur. Des
de l’expérience utilisateurs expérimentés ont besoin de dialogues moins explicites que les novices (prévoir des raccourcis,
utilisateur (12) des choix d’entrées simples ou multiples selon l’expérience, autoriser différents modes de dialogue…).
La gestion des erreurs : moyens permettant d’éviter ou de réduire les erreurs et de les corriger. Les interruptions provoquées par celles-ci ont
des conséquences sur l’activité de l’utilisateur et peuvent causer des accidents graves.
Protection (13) Moyens mis en place pour détecter les erreurs d’entrées de données ou de commandes (demande de
confirmation avant de quitter une session, protection des labels de champs, accès impossibles aux aires non
nécessaires à l’utilisateur…).
Qualité des Pertinence et exactitude de l’information fournie à l’utilisateur sur la nature des erreurs commises et sur les
messages (14) actions à entreprendre pour corriger (aucune action ne doit suivre une action invalide, fournir des messages
d’erreurs orientés tâches…).
Correction (15) Moyens mis à la disposition de l’utilisateur pour corriger les erreurs. La facilité de correction diminue les
perturbations dues aux erreurs (retour arrière ou annulation d’une action possible).
Homogénéité et Consistance (16) : Conservation des choix d’objets de l’interface (codes, procédures) pour des contextes identiques et non-
conservation pour des contextes différents (standardisation et homogénéité des codes, procédures, dénominations, moyens, localisation,
format d’écran, procédure, similaire…).
Signification des codes (17) : Adéquation entre l’objet ou l’information affichée ou demandée et son référent. Des codes et dénominations
“signifiants” disposent d’une relation sémantique forte avec leur référent (titre représentatif, règles de contraction ou d’abréviation
explicitées, distinction des labels…).
Compatibilité (18) : Accord existant entre caractéristiques L4utilisateur (mémoire, perception, habitudes…) et l’organisation de l’interface
(E/S, dialogue, architecture…) : procédures et tâches respectant les attentes ou habitudes utilisateur, traductions, transpositions, références à
la documentation minimisées (informations directement utilisables, écrans compatibles avec le support papier, organisation des données
affichées conforme à l’organisation des données à entrer, procédures de dialogue dans l’ordre imaginé ou habituel de l’utilisateur…).
 Chapitre I 31

L’ensemble de ces critères vise à aider l’évaluateur à estimer la qualité ergonomique de l’interface et à prendre si
nécessaire des décisions de modification et/ou d’amélioration. Il existe des relations de causalité entre ceux-ci (par
exemple, une baisse de la performance peut être la conséquence d’une surcharge de travail) ; c’est pourquoi ils ne
doivent pas être étudiés séparément. En fait, les bonnes interfaces réalisent des compromis entre des caractéristiques
aussi diverses et souvent contradictoires que la prise en compte de l’intuition et l’expérience de l’utilisateur, la
consistance et l’adaptabilité, la flexibilité et les actions explicites, tenant compte fondamentalement des
caractéristiques des utilisateurs potentiels, et de leurs attentes.

Les critères d’évaluation ergonomique concernent principalement la qualité de l’interface au sens de l’utilisabilité.
La facilité d’utilisation, d’apprentissage, et l’efficacité, sont des critères fondamentaux de qualité. Il nous semble
pourtant pertinent de s’intéresser aussi à l’utilité de l’interface en observant l’adéquation à la tâche et la répartition
du travail.

L’adéquation à la tâche consiste à vérifier si les procédures cognitives développées par l’utilisateur sont similaires
à celles initialement développées par le concepteur et donc à estimer si la tâche réelle redéfinie par l’utilisateur est en
accord avec la tâche prescrite à effectuer (Abed 90). Concernant la répartition du travail, il s’agit d’étudier
l’adaptation du poste de travail à la tâche, en s’intéressant à la façon dont est organisé le travail en terme de répartition
entre l’homme et la machine (Millot 88 ; Debernard 93). Notons que l’ensemble de ces critères sont rassemblés par
Cote et al. (93) sous la dénomination conformité fonctionnelle.

De plus, la performance du système homme-machine n’est évidemment pas à délaisser lors de l’évaluation.
L’interface est conçue pour assurer la communication entre l’homme et la machine certes, mais le système homme-
machine doit produire des résultats. C’est pourquoi un (ou plusieurs) critère de performance du système global est
indispensable pour déterminer si les objectifs sont atteints. La difficulté réside dans le choix d’une (ou plusieurs)
donnée représentative, pertinente et surtout mesurable.

De la même manière, les préférences de l’utilisateur sont à prendre en compte également dans toute évaluation
(c’est lui qui va travailler avec le machine, il a son mot à dire ). C’est un critère subjectif basé sur le jugement et les
suggestions de l’utilisateur sur la qualité du système homme-machine. Nielsen (93) émet toutefois une réserve
concernant l’avis des utilisateurs : ceux-ci commencent souvent par rejeter une modification conseillée par le
concepteur si elle s’avère complètement différente de ses habitudes, pour, si elle est bonne, ne plus s’en passer ensuite.

Enfin, l’évaluation de l’IHM fait partie de l’évaluation du système global ; aussi l’analyse de l’ensemble de la
documentation, notamment les aides utilisateur, doit être prise en compte de façon explicite dans les critères. Ceci
nous paraît important même si celles-ci ne seront en principe quasiment jamais consultées pour une interface qui
respecte toutes les recommandations ergonomiques et qui s’avère adaptée à l’utilisateur (facile d’utilisation, rapide à
apprendre, intuitive…), ou alors pour laquelle l’utilisateur est parfaitement formé.

Après avoir collecté les données, il est souvent nécessaire, vu leur nombre, d’effectuer des traitements afin de
faciliter l’interprétation pour l’évaluation.

III.3. Le traitement des données issues de l’évaluation

Les mesures effectuées sur le système homme-machine regroupent la totalité des variables observées par rapport
aux deux propriétés étudiées (l’utilité et l’utilisabilité). Elles forment en quelque sorte une base de données
expérimentales avec des informations aussi bien objectives (par exemple des taux d’erreurs de manipulation de l’IHM
enregistrées automatiquement) que subjectives (par exemple issues des questionnaires ou d’interviews). En fonction
de leur nature et dans le but d’élaborer le modèle observé, différents traitements spécifiques sont appliqués.

Le traitement des données repose sur l’utilisation de méthodes d’analyse de données issues des statistiques
descriptives (Volle 81). L’analyse des données s’applique à des résultats statistiques bruts, et permet de faciliter la
description et l’interprétation des phénomènes où le nombre des observations est important. L’application de ces
méthodes numériques nécessite des connaissances approfondies sur leur fondement théorique, et une bonne pratique
pour interpréter les résultats.
 Chapitre I 32

Sans entrer dans le détail (cf. Loslever 88 ou Philippe 93), nous dirons simplement que l’analyse des données
issues de l’évaluation repose sur trois orientations :

• La mise en évidence de l’effet des facteurs est basée principalement sur l’utilisation de l’analyse de la
variance pour reconnaître les données qui interviennent réellement sur le système homme-machine et modifient
le résultat de l’évaluation (Dugue et al. 69).

• Le traitement des données objectives fait appel aux méthodes d’analyse multidimensionnelles (Sayarh 91 ;
Rouanet et al. 93). Après un codage adapté, elles consistent à faire apparaître les relations existant entre les
variables observées, avec par exemple les méthodes factorielles et de classification (Volle 81). Par exemple,
Simon (93) propose d’utiliser différents codages pour étudier l’influence de différents facteurs sur le chemin
oculaires d’opérateurs de supervision.

• L’analyse des données subjectives, principalement pour le dépouillement des questionnaires, comme par
exemple pour l’analyse des données recueillies avec l’échelle de Cooper-Harper 6 (Cf. l’utilisation par Kamoun
89), fait également appel à certaines des méthodes multidimensionnelles telles que l’analyse factorielle (Cibois
87) ou les sous-ensembles flous (voir par exemple leur utilisation par Guerra 91).

Pour l’analyse des données recueillies sur l’IHM, on pourra avoir recours à la méthode expérimentale de Valliser
(77, détaillé dans Philippe 93). Elle peut se représenter comme un cycle itératif d’évaluation qui passe par : (i) le
champ théorique d’investigation, point de départ et définition des connaissances du domaine, (ii) le modèle
hypothétique, hypothèse de recherche, définition des variables à contrôler et à mesurer, (iii) le champ empirique, lieu
des observations, (iv) le modèle observé ou identifié, à partir duquel une conclusion est apportée sur les résultats
obtenus. Cette démarche rejoint le principe proposé de comparaison des deux modèles de l’interaction homme-
machine.

L’évaluation d’une IHM, en passant par la définition des données de base à recueillir, le recueil puis le traitement
des données, nécessite une compétence pluridisciplinaire que se partagent un certain nombre d’intervenants.

III.4. Les intervenants de l’évaluation

L’évaluation peut être effectuée par un ergonome, le concepteur lui-même, voire même un utilisateur ( Ravden et
al. 89). Il semble que le choix de l’évaluateur soit fonction de la tâche, de ses compétences, et de la phase de
développement en cours. L’évaluation demandera donc des compétences d’ergonomes connaissant la tâche,
d’informaticiens (ou concepteurs), mais on préférera l’intervention d’une équipe pluridisciplinaire d’évaluateurs
(Norman 86 ; Meinadier 91 ; Adreit et al. 92 ; Poulain 94).

En fait, on considère maintenant de plus en plus que l’évaluation n’est véritablement efficace que si la démarche
adoptée pour le processus de développement de logiciel est participative (Lanning 91 ; Kolski 93 ; CACM 93). Par
exemple, dans les applications industrielles complexes, la notion de groupe de travail est primordiale ( Abed 90). Ces
groupes qui composent l’équipe de développement, s’organisent autour de quatre types principaux de connaissances :
celles de l’ergonome, de l’ingénieur, de l’utilisateur et du concepteur.

• Les connaissances de l’ergonome : celui-ci doit être familier des exigences physiques et cognitives, ainsi que
des limites et des ressources théoriques d’un utilisateur réalisant une tâche donnée dans un environnement
socio-technique, … mais doit aussi être largement sensibilisé au fonctionnement du système technique.

6
Cette échelle qui permet l’estimation de la charge de travail d’un opérateur sera expliquée dans le chapitre II.
 Chapitre I 33

• Les connaissances de l’ingénieur : l’ingénieur est censé connaître l’application, son comportement physique,
son modèle et l’interaction entre ses variables. Il est aussi capable de recenser les informations utiles pour le
maintien du fonctionnement normal du système et de contribuer à l’analyse des modes opératoires qu’effectue
l’utilisateur sur le terrain.

• Les connaissances de l’utilisateur : elles se basent sur la pratique et l’expérience de différentes situations.
L’utilisateur connaît l’efficacité de certaines interventions ; dans le meilleur des cas, il a déjà utilisé différents
outils informatiques. Il est donc théoriquement en mesure de recenser une grande partie des tâches qui lui ont
été assignées et d’en décrire les contraintes.

• Les connaissances du concepteur de l’IHM (informaticien, automaticien) : il apporte ses connaissances liées
aux méthodes et outils de développement. Il doit en outre faciliter la liaison entre les données recueillies et leur
modélisation.

Ainsi, l’évaluation devrait être suivie et réalisée par un personnel qualifié dans la mise en œuvre
d’expérimentations et qui possède des connaissances ergonomiques appropriées au produit concerné. Dans la
littérature, on considère que ce type de personnel doit inclure des personnes spécialistes en ergonomie, ou encore en
physiologie et psychologie appliquée. Cependant, à partir de la grande variété des IHM, il est clair que certains autres
groupes professionnels peuvent réussir à mener à bien des tests utilisateurs. Certaines des tâches incluses dans la
conduite de l’évaluation peuvent, à l’occasion, être prises en charge par d’autres personnes mais un “entraînement”
spécifique sera souvent requis préalablement pour assurer des résultats satisfaisants (McClelland 90). Dans ce cas, la
collecte des données doit être réalisée de façon bien définie, ce qui est souvent difficile dans un système déjà conçu et
pas forcément “ouvert”.

III.5. Conclusion, besoins pour l’évaluation des interfaces

Toute évaluation consiste à identifier ou à prévoir les difficultés que rencontrent les utilisateurs, à détecter les
points forts et les points faibles du système, à en comprendre les raisons pour ensuite trouver des solutions correctives.
Comme nous venons de le voir, avec toujours un même objectif, les techniques employées sont très dépendantes du
contexte. Aussi, avant toute analyse, il est nécessaire de bien choisir la méthode à employer, liant à la fois le critère à
évaluer à la situation concrète (Grislin et al. 93). C’est un des points sur lesquels nous insistons dans la suite de ce
mémoire, en nous basant sur les classifications actuelles.

Dans la majeure partie des cas de développement d’applications informatiques interactives, les interactions
homme-machine et l’évaluation de leur qualité ne sont pas explicitement et systématiquement prises en compte lors du
cycle de vie. Pourtant, il est évident que la qualité des IHM est cruciale. Aussi, l’utilisation de méthodes et de
techniques d’évaluation s’impose pour l’équipe chargée du développement.

C ONCLUSION SUR L’ ÉVALUATION DES I NTERFACES H OMME -M ACHINE

La première partie de ce chapitre a rappelé la structure globale d’un système homme-machine de supervision. En
montrant le rôle du superviseur qui à la fois surveille et agit sur l’installation, nous avons souligné l’importance de la
qualité des interactions homme-machine. Celles-ci sont réalisées au moyen d’une interface intégrée au système de
supervision. C’est pourquoi cette partie a été suivie de la description du cycle global de développement d’un système
homme-machine.

Le cycle de vie en V a été présenté plus particulièrement puisqu’il semble le mieux admis et surtout bien adapté au
développement d’un système interactif. En effet, le développement d’une IHM passe par une phase descendante
d’analyse des besoins de l’utilisateur et de conception, suivie d’une démarche ascendante de tests, validation,
intégration et certification avec l’opérateur. Nous avons discuté des besoins pour la conception des IHM, mais c’est
son évaluation au cours de la phase descendante qui a retenu notre attention.
 Chapitre I 34

Dans ce cadre, au vu des besoins pour la conception et pour l’évaluation des IHM, l’objectif de notre travail
souligne le fait que l’évaluation et la conception sont étroitement liées ; l’une ne va pas sans l’autre. Nous pouvons
ainsi nous associer à une idée fondamentale énoncée par Senach (90) : “ Cette organisation [des techniques
d’évaluation des IHM] va à l’encontre des idées reçues en matière d’évaluation : elle montre que celle-ci constitue un
processus parallèle à la conception, qu’elle ne peut pas être réduite à une simple étape ponctuelle et qu’une équipe
d’évaluation doit pouvoir utiliser un ensemble d’outils —allant des techniques cliniques aux méthodes formelles— à
chaque étape de la vie d’un produit.”

C’est l’objectif de notre travail en proposant une démarche qui entre en jeu dès l’étape de spécification
fonctionnelle d’une application interactive. Celle-ci ne pourra être efficace que dans la mesure où des outils fiables,
systématiques et faciles à utiliser seront disponibles. Cette idée souligne la nécessité de fournir à l’évaluateur une
palette d’outils d’ingénierie pour l’évaluation de l’IHM (Kolski 93). C’est pourquoi les deux chapitres suivants
présentent et discutent d’un grand nombre de méthodes et techniques utilisables pour l’évaluation. Elles composent
l’environnement de la démarche proposée et seront positionnées tout au long du cycle de développement.

Actuellement, les méthodes utilisées sont principalement empiriques, basées sur la mesure et/ou l’observation de
données représentatives des actions des utilisateurs, et expertes. Le chapitre II est consacré à la description en détail de
ces méthodes et techniques dans le cadre de l’évaluation des IHM des systèmes industriels de supervision.
Chapitre II

Les méthodes et techniques usuelles d’évaluation des Interfaces

Homme-Machine
(mise en relation avec les systèmes industriels de supervision)

INTRODUCTION

I. DISCUSSION PRÉALABLE SUR LES CLASSIFICATIONS ACTUELLES EN

MATIÈRE D’ÉVALUATION D’IHM

II. LES APPROCHES CENTRÉES SUR LES UTILISATEURS

III. LES APPROCHES CENTRÉES SUR UNE EXPERTISE

CONCLUSION SUR LES MÉTHODES USUELLES D’ÉVALUATION DES

IHM
 Chapitre I 37

Il semble que le terme évaluation recouvre des significations différentes suivant le contexte et le niveau de l’étude
dans laquelle elle se pratique. Dans le contexte industriel, où l’objectif est d’obtenir un produit fini, l’évaluation porte
le plus souvent sur les performances ; en recherche, elle porte aussi sur des méthodes et des modèles choisis au cours
des phases de conception.

Dans le chapitre précédent, nous avons discuté de la structure globale d’un système homme-machine de
supervision, des obstacles rencontrés par l’équipe de développement pour prendre en compte l’ergonomie au sein du
processus de conception, et de notre problématique : l’évaluation des IHM.

Ce chapitre est principalement consacré à la présentation des différentes situations d’évaluation, ce qui mettra en
évidence trois types d’approches différentes : (i) centrée sur l’utilisateur, (ii) centrée sur une expertise, et (iii) centrée
sur une modélisation. Les méthodes et techniques issues des deux premières approches seront ensuite discutées.

I. D ISCUSSION PRÉALABLE SUR LES CLASSIFICATIONS ACTUELLES EN

MATIÈRE D ’ ÉVALUATION D ’IHM

Plusieurs classifications existent dans la littérature, on trouve souvent la distinction entre des approches dites
prédictives et des approches dites expérimentales, c’est le cas par exemple de la classification de Nielsen et Molich
(90). Proche de ces auteurs, Senach (90), qui a constitué pour nous une source importante d’inspiration, différencie les
techniques en des approches analytiques et d’autres empiriques. Maguire et al. (89) et Sweeney et al. (93) proposent
trois grandes familles de méthodes où l’évaluation est basée sur l’utilisateur, la théorie ou sur une expertise.
Whitefield et al. (90) organisent leur classification en fonction de la présence ou non de l’utilisateur d’une part, et du
système interactif à évaluer d’autre part. Aschehoug (91) présente les techniques d’évaluation comme des méthodes
de description des interfaces et discute de la pertinence des modèles et des formalismes. Balbo et Coutaz (92, 94)
classifient les techniques en fonction de plusieurs paramètres, tel leur degré d’automatisation, la prise en compte de
l’utilisateur, ou encore le savoir utilisé pour l’évaluation.

Les classifications existantes sont très importantes, et semblent souvent en théorie très pertinentes, puisqu’elles
permettent d’appréhender de manière générale les conditions principales d’évaluation. Toutefois, en tirant des leçons
des évaluations réalisées sur des systèmes homme-machine complexes réels et/ou simulés, nous nous sommes aperçus
que chaque cas d’évaluation est un cas particulier, où l’évaluation relève d’un état d’esprit qui doit se retrouver tout au
long des étapes du cycle de vie du système concerné, et où les conditions d’évaluation peuvent varier d’une semaine à
l’autre, sous les contraintes industrielles, par exemple, non-disponibilité des utilisateurs représentatifs, nombre très
limité de journées de travail imposé par les décideurs —peut-on dans ce cas encore parler d’évaluation ? ou plutôt
d’évaluation à moindre coût (Nielsen 93)—, ou alors obligation d’utiliser des méthodes “simples” réutilisables ensuite
en interne par des non-spécialistes, mise en évidence de problèmes de fond concernant l’utilité du futur système, etc.)

C’est pourquoi, notre objectif n’est pas de proposer une nouvelle classification, mais de décrire des ensembles de
méthodes et techniques qui pourront et devront être combinées pour arriver à une évaluation pertinente. Celles-ci sont
issues de domaines variés, tels que le génie logiciel, l’acquisition de connaissances, l’ergonomie ou la psychologie.
Elles ont été adaptées aux caractéristiques propres des interventions ergonomiques et aux situations du terrain. Cette
effervescence d’études a donné naissance à un grand nombre de méthodes —plus d’une trentaine sont recensées. Dans
un souci de clarté, il nous a été nécessaire d’effectuer des regroupements de méthodes et techniques. Nous en avons
défini trois que l’on retrouve d’ailleurs explicitement ou implicitement dans la plupart des classifications existantes :
centrée sur l’utilisateur, centrée sur une expertise, centrée sur une modélisation (Grislin et al. 95a).

Une évaluation rigoureuse des IHM nécessite de suivre des méthodes et des techniques d’évaluation. Ce recours
pour les évaluateurs à une certaine aide (ne faut-il pas plutôt parler dans de nombreux cas de recours pour l’équipe de
développement ?) dépend des caractéristiques de la situation à évaluer et, en particulier de l’état de développement du
système interactif à évaluer : réalisé concrètement (l’interface existe), ou hypothétique mais potentiellement
envisageable (l’interface est inexistante).
 Chapitre I 38

I.1. Évaluation d’une interface existante

Lorsque l’interface à évaluer existe, des méthodes d’analyse de données comportementales recueillies au moyen
d’observations ou de mesures, sur le terrain ou en laboratoire sont préconisées. Ces méthodes consistent à réaliser des
tests d’utilisabilité avec des utilisateurs habituels ou des sujets sélectionnés pour l’expérience. Ce type d’évaluation
s’effectue généralement a posteriori sur des interfaces déjà utilisées ou maquettées et aboutit à l’émission de
jugements relatifs à leur utilisation.

Dans ce premier cas, on distingue un certain nombre de méthodes et techniques que nous proposons de classer
selon deux approches qui seront détaillées dans ce chapitre :

(1) les approches centrées sur les utilisateurs qui consistent à “mesurer” les performances d’utilisateurs
représentatifs grâce au recueil et l’observation des données de l’interaction, puis l’analyse de ces traces de
l’activité des utilisateurs.
Ces méthodes mettent en jeu les multiples outils élaborés par l’expérimentation. On trouve les techniques
associées au diagnostic d’usage qui concerne l’évaluation de dispositifs existants, à l’estimation de la charge
de travail basée sur l’observation du travail cognitif de l’utilisateur, aux tests de conception qui réalisent
l’évaluation selon un cycle itératif tout au long du processus de conception.

(2) les approches centrées sur une expertise qui sont basées sur le jugement d’experts en communication
homme-machine ou peuvent s’appuyer sur des grilles d’évaluation ou des questionnaires listant les qualités
d’une bonne interface.

I.2. Évaluation d’une interface en cours de développement

Lorsque l’interface à évaluer est inexistante, des méthodes d’évaluation analytiques sont utilisables. Elles
permettent de réaliser une analyse a priori, i.e. de fournir une appréciation de l’interface avant son utilisation réelle.
L’évaluation repose alors sur la comparaison des informations concernant l’interface, à un stade particulier de son
développement, avec un modèle de l'évaluateur. Ce modèle décrit une interface qui répond aux besoins nécessaires à
l’opérateur dans la réalisation de sa tâche en terme d’utilité et d’utilisabilité. Il est issu des connaissances en
ergonomie et peut être supporté par une architecture appropriée à la description du dialogue homme-machine (nous
proposerons un canevas théorique dans le chapitre IV). Ces méthodes peuvent alors être utilisées au cours de la
spécification-conception, en vue d’un contrôle a priori de la qualité ergonomique de l’interface prévue.

Dans ce second cas, nous proposons de classer les techniques correspondantes selon les deux approches suivantes :

(2) certaines approches centrées sur une expertise (déjà citées précédemment) qui consistent à analyser
l’interface en la comparant à un modèle informel de la communication homme-machine. Certaines méthodes
préconisent le respect de recommandations ergonomiques, ces règles peuvent constituer “l’architecture” du
modèle de l'évaluateur.

(3) les approches centrées sur une modélisation (détaillées dans le chapitre III), consistent à effectuer
l’évaluation sur un modèle de l’interface ou de l’interaction homme-machine. Ces approches utilisent des
modèles formels et/ou des métriques de qualité.
Ces modèles permettent de prédire au moyen de spécifications, certains aspects liés à l’interaction homme-
machine (hiérarchie des tâches, cheminement des actions de l’utilisateur, durée …). Des métriques sont mises
en place pour mesurer de façon objective certains aspects associés à la qualité de l’interaction (cohérence,
compatibilité avec l’image mentale de l’utilisateur, qualité des écrans …).

Comme nous le verrons progressivement dans la suite de ce mémoire, le recours à ces représentations abstraites
autorise des prédictions relatives aux performances qui ne peuvent pas être établies avec une approche purement
empirique.
 Chapitre I 39

II. L ES APPROCHES CENTRÉES SUR LES UTILISATEURS

Lorsque l’interface existe, les données comportementales sont recueillies au moyen de méthodes plutôt
expérimentales. Ce type d’approche consiste à recueillir des données représentatives de l’interaction à l’aide de
mesures ou d’observations provenant de l’utilisation des interfaces par des utilisateurs représentatifs de la population
finale, puis à analyser ces traces de l’activité. Comme l’évaluation doit être effectuée dans un environnement le plus
proche possible de la réalité et (si possible) sans gêner l’opérateur, beaucoup de ces méthodes utilisent
l’enregistrement vidéo, avec souvent un protocole expérimental.

On distingue les techniques associées au diagnostic d’usage, à l’estimation de la charge de travail et aux tests de
conception, successivement présentées dans les paragraphes suivants.

II.1. Les approches empiriques de diagnostic d’usage

Les approches empiriques concernent l’évaluation de dispositifs existants. Les principales techniques de recueil et
méthodes d’analyse utilisables pour l’évaluation sont présentées dans le tableau II.1 : l’arbre des causes, les incidents
critiques, les traces écrites du travail, le recueil de l’expertise, les questionnaires, les mouchards électroniques,
l’observation des tactiques visuelles, l’enregistrement vidéo, et l’analyse des protocoles. Le choix de l’une ou l’autre
dépend surtout des contraintes d’application (délais, matériel, …).

Tableau II.1 : Les approches empiriques de diagnostic d’usage

Techniques Principe / Objectif Critères ergono-
miques concernés
Arbre des causes - Description graphique d’un enchaînement causal sous la forme d’unegroupement, actions
arborescence (connecteurs ET et OU) en partant de l’événement minimales, gestion des
(Villemeur 88 ;
indésirable et en recherchant ses causes possibles. erreurs, homogénéité et
Kirwan 90)
- Comparaison des situations incidentelles ou accidentelles à celles quiconsistance, signifiance
auraient pu avoir lieu sans problème d'utilisation de l'interface. des codes, compatibilité
Incidents - Recueil systématique des dysfonctionnements de l’IHM à partir guidage, charge de
critiques d’entretiens avec les utilisateurs et d’observations en situation. travail, contrôle
- Description des incidents, classification hiérarchique, identification explicite, adaptabilité,
(Senach et al. 85 ; des classes de situation, proposition d’améliorations gestion des erreurs,
Koenemann- signifiance des codes,
Belliveau et al. 94) compatibilité
Traces écrites du - Analyse des traces écrites du travail de l’utilisateur (notes écrites, critères “en vrac”
travail (papier) documents de conduite, cahiers de doléances, enregistrements des
entrées utilisateurs).
(Sperandio 91) - Localisation des lacunes par les changements sollicités, ou les
problèmes empêchant d’exécuter une tâche efficacement.
Recueil de - Rendu de l’activité et des problèmes de l’utilisateur en langue groupement, clarté,
l’expertise naturelle (entretiens, verbalisations spontanées ou provoquées) ou à concision, actions
l'aide de graphiques. minimales, contrôle
(Dieng 90 ; - Mise en évidence : des exécutions particulières (ce qui a été fait), des explicite, adaptabilité,
Benkirane 91 ; procédures (comment procéder), de la connaissances sous-jacentes homogénéité et
Salazar-Ferrer 91 ; aux procédures (propriétés du système), de l’organisation et des consistance,
Benysh 93) stratégies de raisonnement… compatibilité
 Chapitre I 40

Tableau II.1 : (suite)

Questionnaires - Appréciations subjectives des besoins des utilisateurs auprès d’un tous les critères si les
groupe sélectionné (fonction du type d’utilisateur final et du type de questionnaires sont
(Rushinek et al. 86 ;
produit). exhaustifs.
Sweeney et al. 87 ;
- Questionnaires d’utilisation sur la qualité d’une interface. Analyse
Sinclair 90)
des données recueillies par des méthodes statistiques classiques.
Mouchard - Recueil automatique, en situation naturelle, des actions des incitation, retour
électronique utilisateurs et des répercussions sur le système. informatif, concision,
- Pratique de laboratoire possible sur site lorsque le système est ouvert contrôle explicite,
(Neal et al. 83 ; (insertion d’un mouchard dans l’application pour stocker flexibilité, gestion des
Hanson et al. 84 ; automatiquement des données). erreurs
Bias et al. 93)
Observation des - Observation de l’activité oculaire au moyen d’un oculomètre pour groupement par
tactiques estimer le comportement cognitif ainsi que la connaissance exploitée localisation, clarté,
par l’utilisateur. charge de travail,
visuelles - Très indirectement, dans l’activité oculaire de l’utilisateur se qualité des messages,
(Moray 86 ; Abed trouvent des “traces” de son comportement cognitif ainsi que la signifiance des codes
90 ; Itoh et al. 90 ; connaissance qu’il manipule (la vision centrale correspond à la prise
Bernard 94 ; Riera et d’information et la vision périphérique au champ visuel).
al. 94)
Enregistrement - Enregistrement objectif de l’activité de l'utilisateur pour estimer sa groupements, guidage,
vidéo performance et celle du système homme-machine (vidéo, interviews contrôle explicite,
ou questionnaires). qualité des messages
(Youmans 87 ; - Identification des moments où les difficultés sont rencontrées, d’erreurs, signifiance
Maguire et al. 89 ; recherche d’explications a posteriori en fonction des faiblesses de des codes, compatibilité
Theaker et al. 89) l’interface.
Analyse des - Modélisation, au moyen d'un arbre, de l’activité intellectuelle par des connaissances sur le
protocoles observations et des entretiens. système, stratégies,
- Explication par l’utilisateur de ce qu’il fait lors de l’interaction avec problèmes types,
(Ericsson et al. 84 ; la machine (possibilité d’enregistrement pour analyse ultérieure) : enchaînement, activité
Belkin et al. 87 ; problèmes types, verbalisations provoquées, informations à la
Koubek et al. 91) demande, étude de la mémorisation, pensée à voix haute…

Les informations issues des méthodes du diagnostic d’usage, facilitent beaucoup les décisions en matière de
conception ou d’amélioration. Par exemple, l’arbre des causes, applicable pour la majorité des systèmes interactifs,
permet d’identifier beaucoup de causes humaines et de procédures conduisant à une défaillance, ainsi que de leurs
combinaisons. Cependant, l’évolution temporelle des événements du système n’est pas bien prise en compte et
l’identification des séquences de défaillances s’avère difficile pour des systèmes complexes.

L’analyse des incidents critiques est possible dans la plupart des situations. Un diagnostic global des principaux
dysfonctionnements du système est rapidement obtenu par l’évaluateur (difficultés d’utilisation, détection des
inadéquations des outils ou de la logique de travail, dysfonctionnements, etc.). De plus, ces informations peuvent être
utilisées pour définir les premières fonctionnalités d’un nouveau système, réaliser des aménagements, préciser les
objectifs de formation.

Les traces écrites facilitent la mise en évidence de lacunes de l’IHM et sont un moyen de communication entre les
utilisateurs et les concepteurs. Les données recueillies décrivent des événements survenus : défauts, changements de
consigne, arrêts, redémarrages, erreurs et actions de correction, etc. Par exemple, les cahiers de doléances mis à la
disposition des utilisateurs dès la mise en exploitation sont d’un apport précieux pour détecter l’impact de l’interface
et éventuellement l’améliorer. Malgré sa facilité de mise en œuvre, cette méthode reste très succincte et les utilisateurs
la délaissent très vite lorsque leurs remarques ne sont pas prises en compte.

Le recueil de l’expertise, par son principe de base en apparence simple, propose des techniques de recueil
couramment utilisées notamment en ingénierie de la connaissance (fig. II.1). Mais il est nécessaire de prêter attention
aux biais de verbalisation. En effet, pour l’utilisateur de système interactifs, rendre compte de son activité n’est pas la
même chose qu’expliciter et faire comprendre l’essence même de celle-ci. De plus, lors de l’analyse puis la
 Chapitre I 41

modélisation des connaissances, il faut prendre en compte la coopération du système avec l’utilisateur —qui ne sera
pas forcément un expert—, et intégrer les connaissances dans l’environnement (Duribreux 95).

Recueil de l'expertise
bla bla bla et patati ??…
bla bla bla …… et patata…

Figure II.1 : Techniques du recueil de l’expertise

Proposer un questionnaire à l’utilisateur est possible dans la plupart des situations. L’évaluateur peut recueillir de
façon économique des informations subjectives sous une forme sûre, structurée et propice à l’analyse (connaissances
des fonctionnalités, difficultés d’utilisation, cohérence, remarques générales). Cette technique a l’avantage de
permettre à l’utilisateur de travailler “à tête reposée”, même si ceci est susceptible d’introduire un biais dans ses
réponses puisqu’il n’est pas toujours en mesure de se souvenir des difficultés rencontrées lors des différentes
situations de travail. Mais, cette méthode basée sur l’opinion des utilisateurs ne rapporte pas la dynamique du système,
ne permet pas d’identifier l’organisation de l’activité de l’utilisateur, ni la fréquence d’utilisation des commandes, ni
non plus le contexte de chaque erreur d’utilisation.

La technique du mouchard électronique est plus objective et moins perturbante pour l’opérateur puisque les
données sont enregistrées à son insu (fig. II.2). Un grand nombre de données temporelles sont recueillies (dynamique,
possibilité de re-consulter le passé immédiat ou rejouer une séquence). Celles-ci une fois traitées peuvent donner une
bonne appréciation de la performance de l’IHM, du temps de réponse et des exigences de l’interaction. Mais il est
parfois difficile de déterminer la ou les variables pertinentes pour évaluer la performance.

Mouchard
électronique

Figure II.2 : Techniques du mouchard électronique

La conduite de système industriel complexe à l’aide d’outils graphiques d’assistance fait principalement appel au
sens visuel de l’homme. Dans ces conditions, l’étude de l’activité oculomotrice s’intègre logiquement dans une
démarche d’évaluation finale d’un système.

A partir de l’observation des tactiques visuelles, il est possible d’étudier la manière dont l’utilisateur recherche et
localise les informations utiles en fonction des différentes situations de fonctionnement, de mettre en évidence les
stratégies utilisées et de localiser des lacunes des outils graphiques lors de certaines situations de crise. Bien que la
mise en place de techniques oculométriques pose certains problèmes techniques (la calibration et la mesure peuvent
gêner l’utilisateur), celles-ci paraissent désormais suffisamment maîtrisées pour contribuer à l’évaluation des
stratégies visuelles d’un utilisateur et donc à l’aménagement ergonomique des IHM.

Il existe de nombreuses techniques de mesure des mouvements oculaires reposant sur des propriétés optiques,
électriques et mécaniques de l’oeil. Le lecteur intéressé se référera par exemple à l’étude comparative de Chammam
(87).

Actuellement, certains oculomètres, tels les NAC 5, 6 et 7 et l’ASL —basés généralement sur le reflet ou le
 Chapitre I 42

vecteur cornéen—, autorisent une mobilité totale de la tête et fournissent la direction du regard dans un repère lié à
celle-ci. L’évaluateur est capable d’analyser le regard pour en extraire différents descripteurs : le nombre total de
fixations (importance relative de l’instrument et donc de l’information), la durée de fixation (temps nécessaire au
décodage et difficulté d’extraction de l’information), la fréquence de passage (liaisons fonctionnelles entre
instruments). Simon et al.

(94) décrivent une instrumentation permettant la mesure et le traitement entièrement automatiques des
mouvements oculaires d’un opérateur utilisant une interface (fig. II.3).

Caméra "œil"
Moniteur "scène" Moniteur "œil" système de mesure magnétique + Source IR
des mouvement de la tête

Système de traitement
oculométrique ASL
• traitement d'image
• définition du vecteur cornéen
• incrustation de la direction relative
du regard (par rapport à la tête) Caméra
"scène"

Image "scène" direction relative

du regard

Unité de traitement et
mesure des mouvements de tête
PC
Enregistrement vidéo
sur magnétoscope
avec marquage
temporel des images position et orientation
de la tête

Direction absolue du regard (dans

-> dépouillement un repère lié à l'image scène)
semi-automatique -> dépouillement automatique

Figure II.3 : Architecture matérielle du système oculométrique utilisé au LAMIH

Cette instrumentation a été utilisée au LAMIH, notamment pour l’analyse des tâches de contrôleurs de la
navigation aérienne dans le but de réaménager l’interface (Abed 90 ; Bernard 94), étudier les stratégies visuelles des
conducteurs de la chaufferie nucléaire de Sous-marins Nucléaires d’Attaque (Berger 91), pour l’évaluation de postes
de conduite automobile (Grislin 91 ; Riera 93 ; Simon, et al. 94), pour évaluer une proposition d’interface pour le
transport ferroviaire (Benaïssa 93).

La technique d’observation des tactiques visuelles est utilisable en parallèle avec d’autres moyens d’analyse de
l’activité d’un utilisateur face à un écran ou un ensemble de supports d’informations. Toutefois, des difficultés
peuvent être rencontrées lors de l’exploitation des résultats : la fixation du regard ne correspond pas toujours à une
prise d’information et il n’est pas possible d’évaluer l’influence de la vision périphérique.

L’enregistrement vidéo permet une estimation “objective” de la performance de l’utilisateur et du système

homme-machine. Certaines observations des postures caractéristiques et des efforts de l’opérateur dans ses
mouvements peuvent apporter des informations sur son activité : ruptures du mouvement, stratégies, zones regardées,
immobilité physique. Les moments de frustration sont identifiés et peuvent être expliqués en fonction des faiblesses
de l’interface. Associée à l’analyse des protocoles, l’activité intellectuelle de l’utilisateur peut être recueillie et
analysée (fig. II.4).
 Chapitre I 43

Analyse des protocoles

1 "bla bla…" 2
bla bla… parce que… 3

?
?

Figure II.4 : Enregistrement vidéo et analyse des protocoles

Les informations sont recueillies, en particulier grâce à l’utilisateur qui pense à voix haute, en donnant des
explications orales de ce qu’il fait au moment de son interaction avec l’application. Ce qu’il dit est enregistré sur
bande magnétique audio ou vidéo pour être analysé ultérieurement. L’analyse des données est effectuée à tête reposée
et en auto-confrontation avec l’utilisateur —l’auto-confrontation peut être utilisée également dans un but de
formation.

La difficulté d’application de ces dernières techniques de recueil réside dans la nécessité de bien spécifier les
objectifs de l’évaluation, la préparation du recueil et surtout le traitement et l’analyse des données brutes. Notons que,
le système homme-machine doit souvent être ouvert et permettre la mise en place de l’instrumentation oculométrique
qui est volumineuse. Notons aussi que le “dépouillement” est souvent très long et le recueil de données est
relativement imprécis en particulier lorsque les tâches sont complexes. Par exemple, lors de l’évaluation, par
enregistrement vidéo, du pupitre de contrôle-commande du réacteur de sous-marin nucléaire d’attaque, plusieurs
heures d’analyse avec un expert-formateur étaient nécessaires pour préciser les activités des utilisateurs (Grislin et al.
92b).

II.2. L’estimation de la charge de travail

Une mesure qualitative ou quantitative du niveau d’activité d’un utilisateur effectuant une tâche peut être
pertinente pour évaluer la difficulté à utiliser l’IHM (Wierwille et al. 93). De nombreuses méthodes sont proposées
par des spécialistes provenant d’horizons divers : psychologie, physiologie, ergonomie, sciences pour l’ingénieur, etc.
La littérature à leur sujet abonde, que ce soit concernant leur développement ou leur mise en œuvre. Les principales
“familles” de méthodes généralement citées sont listées dans le tableau II.2.

Tableau II.2 : Approches empiriques d’évaluation de la charge de travail (Simon 93)

(Les critères ergonomiques principalement concernés sont la concision, les actions minimales et la charge mentale.)
Techniques Principe / Objectif
Échelles subjectives - Estimation subjective du travail cognitif afin d’évaluer le niveau d’activité mentale et physique par des
(Questionnaires) questionnaires d’opinion.
• COOPER HARPER scale : arbre de décision à dix possibilités, basé sur : probabilité d’erreur, charge de
(Amalberti et al. 86 ; travail mental, difficulté, effort exigé compte tenu de la performance.
Hill et al. 92) • Subjective Workload Assessment Technique : indication par l’opérateur de son niveau de difficulté sur
trois dimensions d’exigence (temporelle, stress, effort mental).
• Task Load indeX : calcul par pondération sur six échelles (exigences mentale, physique et temporelle,
performance, effort physique et mental, et le stress).
• Overall Workload : localisation par l’opérateur de son niveau de charge sur un axe.
Mesures - Évaluation de la charge de travail en quantifiant les changements au niveau de certaines fonctions
physiologique physiologiques (activité électrique du cerveau, des muscles, clignotement de l’oeil, diamètre de la pupille,
(Wierwille 79 ; Wilson fréquence cardiaque ou respiratoire, variations de la résistance électrique de la peau, dosage biochimique).
et al. 88 ; Sperandio - Cette mesure donne un indice sur la capacité à faire face à une tâche.
91 ; Simon 93)
Mesure de la - Estimation de la charge en mesurant une donnée représentative du niveau de difficulté de l’utilisateur
performance lorsqu’il réalise sa tâche (temps de réponse, erreurs par rapport à la consigne).
(Leplat et al. 67 ; - Toute augmentation de la charge de travail engendre une dégradation de sa performance sur la tâche
Odgen et al. 79 ; principale. Voir par exemple la méthode de la double tâche qui consiste à estimer l’exigence de la tâche
Bensaoula 87) principale en ajoutant une tâche supplémentaire qui sature l’utilisateur.
Modèle normatif - Estimation de la charge avec un modèle normatif simulé de l’utilisateur, basé sur différentes hypothèses :
 Chapitre I 44

(Millot 88 ; Kamoun • canal de transmission d’information limité, prise en compte des lois de la théorie de l’information,
89 ; Berger 92, et al. relation entre la performance et la charge de travail (courbe en U inversé),
89 ; Sperandio 91 ; • analyse des modifications de comportement opératoire de l’utilisateur comme critère de charge,
Riera 93) • aspect temporel de réalisation de la tâche (obligation de la réaliser dans un temps imparti).

Ces méthodes sont envisageables pour l’évaluation de la charge de travail lors de l’interaction homme-machine.
Plusieurs thèses récentes du laboratoire (Berger 92 ; Riera 93 ; Simon 93) consacrent des développements importants
à ce sujet. L’estimation est basée sur l’observation du travail cognitif de l’utilisateur, et doit permettre de détecter les
instants de “sous-charge” et de “surcharge” de celui-ci (Millot 88).

Les instants de sous-charge sont responsables de baisses de vigilance. Par exemple, dans une salle de contrôle,
lorsqu’il n’y a aucune évolution des variables sur les écrans, l’opérateur se trouve dans un état tel que face à une
situation critique, il peut ne pas détecter l’arrivée de nouvelles tâches à réaliser. La situation de surcharge est tout aussi
dangereuse, car en raison de ses capacités limitées, il ne peut plus répondre aux exigences de la ou des tâches
devenues critiques. Les cascades d’alarmes, par exemple, sont des cas classiques où l’opérateur est en surcharge de
travail, et où les problèmes sont difficile à résoudre.

Les échelles subjectives (fig. II.5), bien qu’incompatibles avec une estimation en ligne (le questionnaire est rempli
après la réalisation de la tâche), délivrent un indice de charge totale après la tâche. Avec SWAT, la charge de travail est
évaluée —on ne la mesure pas— à partir de plusieurs descripteurs les plus indépendants possible. L’estimation
obtenue par cette méthode est relativement bonne, mais la compréhension du questionnaire est difficile pour
l’utilisateur. De plus, les méthodes subjectives sont à utiliser avec précaution, car elles s’apparentent à des
verbalisations qui sont très facilement biaisées.

Echelles Subjectives
• Cooper Harper • TLX • SWAT

calcul classification
de la
charge

Figure II.5 : Méthodes subjectives d’estimation de la charge de travail

Quant aux méthodes physiologiques, elles n’évaluent pas directement la charge, mais fournissent plutôt un indice
sur la capacité de l’utilisateur à faire face à la tâche et sur son niveau de vigilance. De plus, les indicateurs
physiologiques sont aussi fonction de l’émotion, de l’effort physique, du stress, etc., ce qui nécessite l’extraction du
signal utile caractéristique de la charge de travail mental, de la mesure bruitée par un “bruit physiologique”.

La mesure de la performance est limitée par le fait qu’il est difficile de définir la variable ou l’ensemble de
variable(s) dépendante(s) de la tâche principale, qui sera à même de refléter la charge de travail de l’utilisateur. De
plus, cette technique qui se base sur une courbe en U inversé de l’efficacité en fonction de la charge, n’est pas toujours
fiable : une augmentation de la charge n’engendre pas forcément une baisse de la performance. Quand à la méthode de
la double tâche qui a été fréquemment utilisée et qui fait l’objet d’un grand nombre d’applications très diverses
(Sperandio 91), elle est limitée par : (i) le risque de modification de mode opératoire s’il y a conflit entre les deux
tâches et (ii) l’hypothèse sur laquelle la capacité totale de l’utilisateur supposée invariante, est abusive en situation
réelle.

Les méthodes basées sur le modèle normatif (ou modèle observateur) sont intéressantes car objectives et non
perturbatrices ; elles délivrent des valeurs de charge en ligne. Ces méthodes théoriques de modélisation
comportementale de l’individu ont l’avantage de définir une métrique pour la charge de travail, mais elles sont
difficiles à appliquer pour modéliser finement le comportement humain. En effet, l’homme ne se rapproche pas
toujours d’un modèle normatif puisqu’il existe de nombreuses variations inter et intra-individuelles. C’est le cas des
méthodes basées sur le modèle observateur et la méthode temporelle, proposée par Millot en 1988 (fig. II.6).
 Chapitre I 45

Avec cette dernière, il faut que le temps disponible et le temps requis pour réaliser le tâche soient mesurables, ce
qui limite grandement les contextes d’applications. Par exemple, les tâches qualifiées de “hautement cognitives” —
courante en contrôle de process— ne peuvent être prises en compte par ce type de modèle.

Tâche Temps
TR(t) Requis
TD(t) Temps
Disponible
MACHINE
Interface H-M
Difficulté
UTILISATEUR

Modèle Charge
Temps Disponible
observateur de travail Temps Requis

Figure II.6 : Méthode temporelle basée sur le modèle observateur

L’analyse des méthodes amène à dire que l’estimation de la charge de travail doit reposer sur l’utilisation de
plusieurs indices. Santucci (87) propose le trépied de la figure II.7 qui associe une description du travail réalisé par
l’utilisateur à un estimateur subjectif et un indice physiologique.

Analyse de la tâche Indice subjectif indice

effectuée physiologique
Description du travail
réalisé par l'utilisateur

Changements de stratégies

"vécu conscient"
Indice de charge de l'utilisateur "câblage" de l'utilisateur

Figure II.7 : “Trépied” de techniques d’évaluation de la charge de travail

L’analyse de la tâche effectuée renseigne sur les différentes stratégies de l’utilisateur, un changement de stratégie
pouvant signifier une variation de charge. L’indice subjectif rend compte du “vécu conscient” de l’utilisateur alors que
l’indice physiologique par un “câblage” de l’utilisateur informe sur sa capacité et son niveau de vigilance. Une
démarche similaire a donné de bons résultats pour l’évaluation de la charge de travail des conducteurs automobiles :
association des méthodes subjectives à la méthode temporelle (Grislin 91 ; Riera 93).

II.3. Les tests de conception

Ce type de méthode, bien connu en génie logiciel (Boehm 88), concerne tout d’abord la conception de l’interface
—c’est pourquoi les tests de conception sont séparés sur la figure II.1. Les méthodes de ce type sont rattachées à
l’approche empirique parce que ces tests utilisent à un moment ou un autre des techniques de recueil plutôt
expérimentales. De plus, ce type d’évaluation peut être mis en oeuvre lorsqu’il n’existe pas encore d’expérience
d’utilisation du système.

De nombreux environnements du marché, souvent graphiques, facilitent la réalisation et la modification de

l’interface homme-machine par la réduction de l’écriture de code et la réutilisabilité des programmes. La plupart de
ces outils facilitent la réalisation itérative de plusieurs versions plus ou moins avancées de l’interface. Il est dans ce
cas possible d’évaluer celle-ci au fur et à mesure du projet (Senach 90).

Les tests de conception ont pour objet de valider un produit selon des exigences fortes. Cette évaluation doit être
réalisée selon un cycle itératif tout au long du processus de développement. A chaque phase, les solutions
envisageables pour un problème spécifique sont hiérarchisées. Les données sont ensuite recueillies au moyen d’une
 Chapitre I 46

batterie de tests qui engendrent des aménagements mis à l’épreuve à leur tour dans une nouvelle version, ainsi de suite
jusqu’à satisfaction. Ainsi, des alternatives sont évaluées par rapport aux objectifs du système final, les résultats
servant de base pour les étapes suivantes de la démarche. Il est dans ce cas possible d’évaluer l’interface au fur et à
mesure du projet ; on parle alors d’évaluation itérative (fig. II.8).

Sélection Produit fini

Banc d'essai
d'alternative de Prototypage final
conception
Etudes Contrôle de qualité
bla bla…

expérimentales Mesure
Détection
de défauts d'impacts

Figure II.8 : Démarche globale de l’évaluation itérative

Les techniques présentées dans le tableau II.3 correspondent aux étapes clés de ce type d’évaluation.

Tableau II.3 : Approches empiriques de tests de conception

Techniques Principe / Objectif Critères ergono-miques

concernés
Prototypage - Évaluation “précoce” avec les utilisateurs de certains aspects particuliers pris Tous les critères
(Bodjer et al. 89 ; James un par un (entrées, sorties, qualité des messages…), ergonomiques sont
91 ; Miller-Jakobs 91 ; - Développement de l’interface au moyen d’outils de prototypage (boîtes à outils potentiellement
Poulain 94) gestionnaires de fenêtre, éditeurs d’interfaces), concernés par le
- Évaluation des performances au moyen d’une batterie de tests (diagramme prototype à évaluer
d’usage, mesures...).
Groupes de discussion - Rassembler plusieurs corps de métier (utilisateurs, concepteur, informaticiens, Tous les critères
(CACM 93) experts en communication homme-machine …) afin de discuter des différents ergonomiques sont
aspects de l’interface. potentiellement
concernés
Banc d’essai final - Contrôle de la qualité du produit final par une mesure d’utilisabilité globale du Tous les critères
(Neal et al. 83 ; Novara système : performance, fonctionnalités, interface utilisateur, documentation, ergonomiques sont
et al. 87 ; Walsh et al. traduction dans une autre langue, apprentissage, flexibilité, installation, potentiellement
90 ; Rowley 94) maintenance, etc. concernés
- Recueil empirique de données objectives et subjectives sur des stations
d’évaluation spécialement aménagées : microphones, magnétophones, glaces
sans tain, caméras, chronomètres, mouchards électroniques…

Dans le contexte du contrôle de procédé où la complexité des tâches et le nombre de supports d’information
utilisés entraînent rapidement beaucoup d’alternatives de conception, ce recueil des données empiriques permet de
hiérarchiser les solutions. Ces méthodes sont utilisées lorsqu’il n’existe aucun critère de choix évident entre plusieurs
solutions de conception ou différents modes de présentation d’information pour une tâche donnée : qualités de
représentation iconiques (tests de familiarité, de temps de réaction et d’opinion), adéquation de différents modes de
commande aux impératifs d’une tâche, adéquation de libellés de variables aux habitudes des utilisateurs. En outre, ces
méthodes permettent l’enrichissement de bases de données ergonomiques.

Le prototypage permet d’évaluer plus tôt lors du développement : confrontation des choix de conception à la
réalité du terrain, l’utilisateur n’est plus devant le fait accompli, sensibilisation du concepteur à la logique de
l’utilisateur —et inversement—, détection précoce des problèmes et mise en évidence des besoins en matière de
formation ainsi que d’aides logicielles ou sur support papier. Notons aussi que les scénarimages (ou story-board) sont
aussi souvent utilisés pour présenter aux utilisateurs l’enchaînement des écrans dessinés sur papier ; premier support
de dialogue pour l'équipe de développement. Cette méthode, utilisée depuis longtemps intuitivement par de nombreux
concepteurs, s’inscrit dans les premières étapes d’une démarche de prototypage.
 Chapitre I 47

Constituer des groupes de discussion permet de rassembler des spécialistes en communication homme-machine
avec les utilisateurs du système ou du futur système afin de leur poser des questions précises sur leur expérience. Ces
entrevues permettent de se focaliser sur l’interaction homme-machine et notamment sur les problèmes rencontrés. En
outre l’interface peut être revue par un groupe indépendant pour l’identification des problèmes potentiels.

Quant aux bancs d’essai finaux, ils interviennent une fois que l’interface est implémentée et permettent de vérifier
l’interface par rapport à un grand nombre de critères. Des stations d’évaluation, faisant office de banc d’essai final,
font leur apparition dans certains centres de recherche et de développement (par exemple LOTUS, MICROSOFT ou
WORDPERFECT). Les limitations viennent du fait que l’évaluation est effectuée en dehors du contexte réel de la tâche,
de ses contraintes et de son environnement. En effet, une alternative obtenant de médiocres résultats en phase
d’évaluation peut s’avérer meilleure dans une situation de travail qui se rattache à d’autres informations suivant la
logique de l’utilisateur (et inversement). Malgré l’évolution des outils, ces approches sont plutôt exploratoires ; dans
de nombreux cas, elles ne se basent pas suffisamment sur une méthode.

II.4. Conclusion sur les approches centrées sur les utilisateurs et

positionnement dans le cycle de développement
La plupart des approches empiriques, en particulier les techniques de diagnostic d’usage ainsi que celles
permettant l’estimation de la charge de travail, nécessitent une expérience d’utilisation, i.e., un site de référence
existant, ce qui n’est pas toujours possible pour la conception d’un système complètement nouveau. Aussi, ces
techniques ne sont applicables que lorsque le développement de l’interface est bien avancé. Dans le cadre de notre
objectif d’évaluer dès le début du développement, elles seront difficilement envisageables dans un processus parallèle
à la conception. Les tests de conception quant à eux, permettent une évaluation selon un cycle itératif tout au long de
la spécification-conception.

Notons toutefois que le développement d’un système démarre rarement de rien puisqu’il vise généralement
l’amélioration d’une situation existante, déjà informatisée ou non. Dans ce cas, toutes les techniques de diagnostic
d’usage peuvent être envisagées dès les étapes de spécification-conception et introduire un état d’esprit d’évaluation.
Bien entendu, on les utilisera aussi lors des phases d’implémentation, de tests et d’exploitation, lorsque l’interface
existe concrètement.

Ces techniques d’évaluation sont basées sur le recueil et l’analyse de performances d’utilisateurs. Il s’agit du
recueil de données comportementales (vitesse d’exécution ou d’apprentissage d’une tâche ou d’une action, jugement
de satisfaction, verbalisation, connaissances sur le système, stratégies et problèmes rencontrés…) qui rendent compte
de l’utilisation d’une interface existante ou d’un prototype, en situation réelle ou en laboratoire. Des évaluations de ce
type auprès d’utilisateurs peuvent en fait être également effectuées tout au long du processus de spécification-
conception et servir à différents objectifs (par exemple tester des alternatives de conception, réaliser un diagnostic de
premier usage ou comparer deux interfaces).

On peut aussi envisager l’utilisation des approches empiriques dès qu’un prototype réaliste de l’interface est
disponible. L’équipe d’évaluation peut dans ce cas réaliser des expérimentations, avec un protocole rigoureux pour
observer l’utilisateur lors de la réalisation de ses tâches. L’ensemble de ces techniques est donc préconisé dès la
spécification fonctionnelle, mise à part l’analyse des traces écrites du travail qui, pour être pertinente, nécessite un
acquis relativement long de l’utilisation du système. En effet, lorsque l’interface n’est pas complètement réalisée, on
ne dispose pas d’un historique de son utilisation. Nous émettons toutefois certaines réserves quant à leur validité. En
effet, d’une part il est nécessaire de disposer d’utilisateurs expérimentés —pour éviter que l’évaluation ne soit trop
grossière— mais pas trop experts (par exemple, l’évaluation d’un prototype de tableau de bord automobile avec des
pilotes professionnels n’est pas forcément généralisable). D’autre part, les techniques d’observation nécessitent
souvent une instrumentation importante et un dépouillement aval difficile et long (par exemple, pour les tactiques
visuelles). Ce surplus de technicité n’est pas toujours nécessaire sur tous les types d’interfaces (évaluation d’un
distributeur de billet par rapport à celle d’un poste de pilotage d’avion).

Concernant les tests de conception, la mise en place d’un groupe de discussion qui rassemble les intervenants
dans le développement et les utilisateurs est normalement envisageable une fois l’interface complètement réalisée,
c’est à dire à partir des tests d’intégration. On y aura recours plus tôt dans une démarche participative de
 Chapitre I 48

développement du système homme-machine (ou si on dispose d’un prototype, de faire participer des utilisateurs d’un
système voisin, ou système de référence, pour bénéficier de leur expérience). Dans ce cas, un grand nombre
d’intervenants possédant des connaissances et des méthodes variées peuvent apporter leurs avis sur l’utilité et
l’utilisabilité de l’interface. La difficulté sera d’organiser et de gérer toutes ces opinions et méthodes de travail ( Karat
et al. 91).

Le prototypage est utilisé dès la spécification et lors de la conception proprement dite. Dans ce cas, l’évaluation
est réalisée selon un cycle itératif tout au long du processus de conception. A chaque phase de développement, le
produit subit des tests qui engendrent des aménagements mis à l’épreuve à leur tour dans une nouvelle version, ainsi
de suite jusqu’à satisfaction. Quant au banc d’essai final, il ne peut être mis en œuvre dans les premières étapes du
cycle puisqu’il concerne le système interactif et sa documentation dans sa globalité.

Lorsque les données relatives à l’utilisation ne peuvent être enregistrées par des mesures, ou lorsque l’interface
n’existe pas, le recueil des données du modèle de l’interaction homme-machine doit se faire par les approches
expertes.

III. L ES APPROCHES CENTRÉES SUR UNE EXPERTISE

III.1. Les méthodes et techniques

L’évaluation des aspects de communication homme-machine d’un système interactif nécessite souvent une analyse
qualifiée d’experte. On distingue plusieurs méthodes et techniques présentées dans le tableau II.4.

Tableau II.4 : Approches expertes d’évaluation

Techniques Principe / Objectif Critères ergono-miques

concernés
Expertise humaine - Faire intervenir un ou plusieurs experts en communication homme- Tous les critères, les
(Hammond et al. 84; Molich et machine pour juger de la qualité ergonomique d’une interface et experts sont censés les
al. 90 ; Pollier 92) proposer des améliorations. maîtriser…
Grille d’évaluation - Évaluer la qualité par notation systématique par rapport à une liste Tous les critères, les grilles
(Johnsen et al. 89 ; Nielsen 90) complète des propriétés d’une interface. en sont généralement
- Les recommandations de la littérature peuvent composer les entrées issues…
de la grille : Guide de 944 conseils ou principes (Smith et al. 86), aide-
mémoire des questions à se poser (Scapin 87), “check-list” pour
l’évaluation (Ravden et al. 89).
Expérience de l’analyste - Se mettre à la place des utilisateurs et apprendre leur métier (permet guidage, contrôle
(Ombredane et al. 55 ; Kolski d’appréhender certaines difficultés rencontrées par les utilisateurs). explicite, adaptabilité,
89) protection contre les
erreurs, homogénéité,
signifiance des codes
Cognitive Walk-throughs - Méthode particulière d'intervention d'un expert humain (cf. ci-dessus) guidage, charge de travail,
(Lewis et al. 90 ; Polson et al. qui suit les étapes suivantes : recensement des tâches humaines à contrôle expli-cite, qualité
92) évaluer, des séquences d'actions que l'utilisateur devra effectuer, des mes-sages, signifiance
remplissage d'un questionnaire spécifique pour chacune de ces actions. des codes, compatibilité

Le type d’évaluation le plus couramment cité consiste à faire intervenir un spécialiste en communication homme-
machine pour juger de la qualité ergonomique de l’interface et proposer des améliorations. L’expertise humaine est
efficace et simple à mettre en œuvre pour un diagnostic rapide des erreurs de conception. Toutefois, l’évaluation basée
sur un modèle individuel acquis par la pratique risque d’être trop personnel. Chaque spécialiste se focalise sur des
aspects particuliers de l’interface et fonde son évaluation sur une démarche globale qui lui est propre (fig. II.9). On
sait aujourd’hui qu’un spécialiste des facteurs humains même expérimenté identifie en moyenne moins de la moitié
des problèmes potentiels d’une interface (Pollier 92). Pour avoir une vision complète des problèmes et éviter un biais
de focalisation, il est nécessaire de recourir à plusieurs spécialistes (psychologues, cogniticiens, graphistes, rédacteurs
de documents techniques) entraînant un coût homme non négligeable.
 Chapitre I 49

Faire intervenir un ou des experts en communication homme-machine.

Validation par
questionnement ou
Juger de la qualité auto-utilisation.
ergonomique d’une modèle 1 modèle 2
interface

Proposer des procédé

améliorations

Figure II.9 : Expertise humaine

L’utilisation des grilles d’évaluation est d’un apport très bénéfique pour l’évaluateur puisqu’elle l’oblige à ne
négliger aucun des aspects de l’interface (fig. II.10). Cette technique obtient d’excellents résultats pour l’évaluation
comparative d’interfaces et de prototypes. Elle est utilisable par des concepteurs, des spécialistes des facteurs humains
et même parfois par les utilisateurs finaux du système. Cette méthode est donc un excellent support qui peut être
associée à celle précédemment citée. Smith et Mosier (86) proposent une “check-list” ergonomique très complète mais
l’accès aux 944 conseils ou principes (480 pages) peut rebuter les évaluateurs (!). C’est pourquoi les questions
ergonomiques à se poser ont été listées par plusieurs chercheurs sous la forme plus synthétique d’un aide-mémoire
(voir Scapin 87, Barthet 88 ou Nielsen 93, …), ou autour d’une liste de critères d’évaluation (voir chapitre I).
Récemment Vanderdonckt (94) a proposé un recensement de règles ergonomique pour des applications hautement
interactives classées par rapport à des critères ordonnés par importance.

GRILLE D'ÉVALUATION Note

1 2 3 4 5
Prise en compte de l'expérience utilisateur,respect du niveau d'expertise
1L'information est-elle présentée dans le même état d'esprit que l'utilisateur s'en fait ?
2L'affichage graphique est-il compatible avec la représentation que se fait l'utilisateur du système ?
3La structure du système est-elle adaptée à la perception de la tâche de l'utilisateur ?
4Le déroulement des activités exigées pour effectuer une tâche est-il en accord avec les attentes de l'utilisateur ?
5Le système travaille-t-il dans la même voie que la pensée de l'utilisateur ?
6 Estimation globale du système en terme de prise en compte de l'expérience de l'utilisateur ?

Clarté visuelle Caractéristiques lexicales de présentation des informations (cognitif, perceptif)

Groupement par localisation,positionnement des items, appartenance-distinction.
1Chaque écran est-il clairement identifié (titre informatif ou description) ?
2L'organisation des informations sur l'écran est-elle toujours logique ?
3La séparation entre les différents informations est-elle claire de part et d'autre de l'écran ?

Figure II.10 : Extrait d’une grille d’évaluation (inspiré de Ravden et al. 89)

La mise en oeuvre de l’expérience de l’analyste ne permet l’évaluation que de la prise en main du système
(facilité d’apprentissage, ergonomie normative). En effet, d’après Sperandio (91), elle est rarement utile lorsque les
tâches sont compliquées, l’analyste a souvent tendance à se prendre comme modèle et à pratiquer l’introspection sur
lui-même, alors qu’il ne peut que devenir un utilisateur sans expérience et donc éprouver des difficultés à analyser
objectivement le travail.

Par exemple, dans une salle de contrôle, cette méthode pose un problème quasiment insurmontable : il est hors de
question que l’évaluateur utilise l’imagerie en ligne, dans la salle de contrôle, au risque de modifier des paramètres de
régulateurs, des seuils d’alarmes ou des valeurs de consigne. Afin d’améliorer la compétence de dialogue avec les
utilisateurs et de mieux appréhender l’utilisation de fonctionnalités de l’imagerie, il peut être toutefois possible pour
l’évaluateur d’utiliser l’imagerie hors ligne (sans être connecté au procédé). Dans ce cas, on est évidemment loin de
l’idée de départ de cette méthode, qui est d’apprendre le métier de l’utilisateur.

La méthode des Cognitive Walkthroughs permet de prédire des aspects de l'IHM facilitant la résolution des
problèmes rencontrés par l'utilisateur, ainsi que le processus d'apprentissage. L’analyse des résultats s'appuie sur une
théorie cognitive de l'apprentissage par l'exploration qui consiste à trouver les méthodes les plus efficaces, en
cherchant à identifier les différentes images du système que se construisent les utilisateurs en fonction de leur
 Chapitre I 50

expérience. Par exemple, une étude sur un système de formatage de texte a permis de constater des différences
interindividuelles élevées pour les utilisateurs expérimentés (dont la classification selon des critères fonctionnels
permet d’effectuer des groupements de commandes cohérents, proches du système) et novices (pour lesquels des
groupements incohérents ont été mis en évidence).

III.2. Conclusion des approches expertes et positionnement dans le cycle

de développement
Les approches expertes autorisent l’évaluation des situations existantes ou inexistantes. L’expérience de l’analyste
n’est envisageable qu’une fois l’interface réalisée alors que l’expertise et les grilles d’évaluation sont utilisables en
parallèle à la conception. Le modèle de l’évaluateur peut être construit à partir d’une expertise humaine et de grilles
d’évaluation dès l’étape de spécification. En effet, ces méthodes contribuent à améliorer la définition des besoins, de
l’architecture de l’interface, des enchaînements graphiques, la présentation de l’information et des traitements
d’affichage.

Bien que l’expertise humaine soit sans doute la méthode qui donne les meilleurs résultats, le recours à un
ergonome ne concerne qu'une faible proportion des projets industriels analysés. De plus, lorsqu'il est consulté, c'est
souvent à une étape avancée du développement, principalement sur des questions d'aménagement physique de la salle
de contrôle (éclairage, mobilier…). Cette situation est sans aucun doute due au manque de connaissance des
ingénieurs de l’intérêt d’une telle méthode et selon une moindre mesure au coût d’une telle évaluation.

Quant aux grilles, celles-ci sont souvent difficilement accessibles aux concepteurs non-spécialistes de l’ergonomie.
En effet, peu d’informations sont fournies sur la façon de les utiliser. Les recommandations restent très subjectives
et/ou interprétables (taille, organisation logique...) et la pondération des notes est difficile à analyser. Cette méthode
est mieux adaptée à des experts en ergonomie qui possèdent déjà un modèle mental du travail de l’utilisateur. De plus
la grille d’analyse doit à la fois tenir compte des fonctionnalités particulières du système étudié et rester “universelle”
(nombre considérable d’items pas toujours utiles).

Par exemple, lors de plusieurs évaluations d’IHM de salle de contrôle, l’utilisation du questionnaire mis au point
par Ravden et Johnson (89), a nécessité des ajustements importants. En effet, des questions relatives à chaque type de
vue utilisé ont dû être ajoutées et de nombreuses autres modifiées ou supprimées. Certains points semblaient trop
éloignés de la réalité des opérateurs (Benaïssa 93 ; Kolski et al. 93).

C ONCLUSION SUR LES MÉTHODES USUELLES D ’ ÉVALUATION DES IHM

Un constat fondamental suite à l’analyse des méthodes présentées dans ce chapitre est que les approches
empiriques centrées sur les utilisateurs nécessitent généralement une formation ou la connaissance de techniques
relevant du domaine de l’ergonomie et de la psychologie (construction de questionnaires, analyse de protocoles
verbaux) que n’ont pas les concepteurs. Ainsi, un certain nombre de “déficiences” a pu être relevées (Sweeney et al.
87 ; Nielsen 93), par exemple : absence ou manque d’explications claires concernant les questions à se poser au début
d’une évaluation, choix de techniques inadaptées entraînant le recueil d’une quantité ou d’un type d’information ne
répondant pas aux questions posées.

De plus, la mise en œuvre d’une expérience contrôlée et l’enregistrement puis le dépouillement de données
relatives à l’utilisation prennent du temps, ce qui s’avère souvent incompatible avec les exigences de rapidité de
développement des systèmes. En outre, les utilisateurs finaux ne sont pas toujours disponibles ou accessibles, et les
concepteurs pas toujours convaincus de l’utilité d’effectuer des tests précoces. En effet, l’évaluation est encore
considérée beaucoup plus comme une fonction corrective que comme une source génératrice d’information pour des
solutions de conception. Il reste donc à leur démontrer, au travers d’exemples concrets, l’impact que peuvent avoir des
tests précoces auprès d’utilisateurs.
 Chapitre I 51

Quant aux approches qualifiées d’expertes, elles viennent en complément des approches empiriques pour vérifier
qu’un maximum de critères ont été pris en compte. Cette approche sera également obligatoire s'il n'est pas possible de
faire intervenir des utilisateurs expérimentés et/ou potentiels dès le début du projet.

Lorsque l’interface à évaluer est inexistante, nous avons vu qu’il était aussi possible de s’orienter vers une
approche plus analytique centrée sur la modélisation de l’IHM et/ou de l’interaction homme-machine. Le chapitre
suivant est consacré à ce type de méthodes et techniques, encore très peu utilisées aujourd’hui dans les systèmes
industriels complexes. Comme pour ce chapitre, nous les présentons en analysant celles utilisables tout au long du
développement.
Chapitre III

Les méthodes et techniques analytiques d’évaluation des

Interfaces Homme-Machine
(Mises en relation avec les systèmes industriels de supervision)

INTRODUCTION

I. LES APPROCHES CENTRÉES SUR UNE MODÉLISATION

II. SYNTHÈSE DES MÉTHODES ET TECHNIQUES D’ÉVALUATION

RECENSÉES

CONCLUSION SUR L’ÉVALUATION ANALYTIQUE DES IHM

55 Chapitre III

Nous avons vu dans le chapitre II que les approches empiriques basées sur les utilisateurs ne semble pas toujours
possibles lors du développement des IHM ; les approches centrées sur une expertise peuvent paraître plus accessibles
aux concepteurs, même si dans la majeure partie des cas, des tests a posteriori seront toujours nécessaires. Quant aux
approches basées sur une modélisation de l’interaction homme-machine, elles permettent d’effectuer un diagnostic a
priori des caractéristiques ergonomiques des interfaces sans avoir recours à des données relatives à l’utilisation du
système. Elles cherchent à prédire les difficultés que pourront rencontrer les utilisateurs, à partir des propriétés de
l’interface.

En gardant, comme dans les chapitres précédents, l’état d’esprit des systèmes industriels complexes, ce chapitre est
consacré à ces méthodes et techniques centrées sur la modélisation de l’IHM et/ou de l’interaction homme-
machine. Elles sont, nous le verrons, utilisables en cours de développement. Cette partie soulignera, d’une part
l’importance d’une évaluation à chaque étape du cycle de développement, et d’autre part l’intérêt offert par une
approche d’évaluation plus analytique.

I. L ES APPROCHES CENTRÉES SUR UNE MODÉLISATION

Ces approches, qualifiées également d’analytiques, se basent sur des modèles formels —informatisés ou non— de
l’interface et/ou de l’interaction homme-machine ainsi que sur la mise en œuvre progressive de métriques objectives.
L’évaluation est réalisée en comparant une représentation de l’interface à une référence décrivant les qualités d’une
“bonne interface” selon plusieurs critères ergonomiques prédéfinis.

Les modèles sont utilisés pour prédire au moyen de spécifications, certains aspects liés à l’interaction homme-
machine (hiérarchie des tâches, cheminement des actions de l’utilisateur, temps requis pour réaliser une tâche…). Les
métriques sont mises en place pour mesurer de façon objective certains aspects associés à la qualité de l’interaction
(cohérence, compatibilité avec l’image mentale de l’utilisateur, qualité des écrans…). Le recours à ces représentations
abstraites autorise des prédictions relatives aux performances qui ne peuvent pas être établies avec une approche
purement empirique.

Afin de mettre en évidence les méthodes et techniques utilisables pour l’évaluation, nous reprenons ici la
distinction de Senach (90) concernant les modèles qualifiés de prédictifs et ceux dits de qualité, successivement
décrits dans les paragraphes suivants. Dans la suite de ce mémoire, nous nous focaliserons sur les modèles prédictifs.

I.1. Les modèles formels prédictifs

La modélisation des tâches humaines est particulièrement importante dans la mesure où elle facilite la
communication entre les intervenants de l’équipe de développement. D’après de nombreux auteurs ( Barthet 88 ;
Senach 90 ; Abed 90), les besoins en assistance peuvent être mieux mis en évidence, et considérés lors du choix des
différentes fonctions d’aide aux tâches humaines ; de même, on considère que les besoins informationnels de
l’utilisateur ne peuvent qu’être mieux pris en compte lors de la spécification des IHM, si ceux-ci sont situés par
rapport à une modélisation des tâches humaines.

Cette modélisation peut être effectuée au moyen de différents modes de description généralement inspirés d’une
décomposition en buts, sous-buts (fig. III.1). Ces décompositions peuvent respecter plusieurs formalismes issus des
modèles formels prédictifs. On distingue les modèles de tâches et les modèles linguistiques.
 Chapitre III 56

but
ssbut ssbut
ssbut ssbut ssbut ssbut
ssbut ssbut ssbut buts élémentaires

Figure III.1 : Description de la tâche sous la forme d’une description en buts et sous-buts

I.1.1. Les modèles de tâches

Les modèles de tâches consistent en une décomposition hiérarchique des tâches pour représenter l’activité
cognitive d’un utilisateur. Le tableau III.1 liste les modèles les plus connus parmi ceux applicables aux applications
interactives. Dans ce type de description, la tâche est décomposée par raffinage en partant de la tâche globale ou, au
contraire, à partir des constituants élémentaires (analyse descendante et ascendante). Elle fournit un support formel
pour l’évaluation prédictive de la performance, puisqu’elle propose une description mesurable du comportement de
l’utilisateur et de ses performances.

Tableau III.1 : Exemples de modèles formels prédictifs : les modèles de tâche

Techniques Principe / Objectif Critères ergonomiques

concernés
HTA - Décomposition hiérarchique de la tâche globale en sous-tâches élémentaires incitation, actions
(Duncan 81, Stammer et pour mettre en évidence les compétences et informations nécessaires à minimales, flexibilité,
al. 90 ; Shepherd 93) l’utilisateur pour chaque but ou sous-but, compte tenu de la structure du charge mentale, prise en
système. compte de l’expérience
utilisateur
GOMS et - Description de l’activité cognitive d’un utilisateur (expert) engagé dans la incitation, actions
CPM-GOMS réalisation d’une tâche de routine sans erreur. minimales, flexibilité,
(Card et al. 83 ; John - Buts (“Goal”) organisés en une hiérarchie, Opérateurs ou actions charge mentale, prise en
88 ; Gray et al. 92 ; élémentaires (“Operator”), Méthodes ou procédures de réalisation d’un but compte de l’expérience
John et al. 92 ; Irving et (“Method”) et Règles de sélection (“Selection rules”) des méthodes lorsque de l’utilisateur
al. 94) plusieurs solutions permettent d’atteindre un même but.
Le modèle CPM-GOMS introduit dans GOMS la méthode du chemin critique
pour calculer un temps critique de réalisation d’une tâche.
DIANE et DIANE+ - Extension de la méthode MERISE à la description de la tâche et la logique incitation, actions
(Barthet 88 ; Tarby 93) d’utilisation du système... minimales, charge
- Description graphique des tâches selon le principe de planification mentale, flexibilité, prise
hiérarchique. en compte de
l’expérience utilisateur
MAD - Description des tâches à partir de données issues de l’analyse du travail d’un incitation, actions
(Scapin 88 ; Scapin et utilisateur : logiques de traitement de l’information. minimales, flexibilité,
al. 89 ; El Farouki et al. - Décomposition des tâches de façon structurelle et description de façon charge mentale, prise en
91 ; Sebillotte 94) déclarative (état du monde) et procédurale (façon d’arriver à un état). MAD compte de l’expérience
prend en compte le parallélisme et le séquentiel (synchronisation des tâches), de l’utilisateur
tout en proposant une description implémentable.
SADT-Pétri ou TOOD - Représentation du SHM basée sur le modèle de tâche caractérisant le SADT : incitation,
(Abed 90 ; Berger 91 ; comportement de la machine, de l’utilisateur et de leurs interactions. actions minimales,
Benaïssa 93 ; Abed et - Décomposition fonctionnelle du système de façon descendante, modulaire, flexibilité, charge
Angue 94 ; Mahfoudi et hiérarchique et structurée par des diagrammes SADT. Puis description du mentale, prise en compte
al. 95) comportement décisionnel face à une situation donnée avec des Réseaux de expérience de
Pétri synchronisés. l’utilisateur
- La méthode a récemment évolué vers TOOD en introduisant une description Pétri : retour informatif,
orientée objet des tâches. Le modèle de tâche résultant se présente sous la protection contre les
forme d’un ensemble d’entités coopératives concernant l’application, erreurs, action explicite,
l’interface et l’opérateur humain. contrôle utilisateur
57 Chapitre III

Le modèle de tâche HTA peut être considéré comme l’ancêtre des modèles de tâches. Il a été utilisé dans
l’industrie pour la formation des utilisateurs, mais a servi également de moyen d’analyse de la fiabilité humaine pour
un ensemble de tâches à réaliser. Un critère de probabilité en terme de coût pour trouver la panne y est énoncé. La
décomposition s’arrête lorsque le rapport entre le coût et la probabilité de défaillance est inférieur à un coefficient pré-
défini. En effet, plus on descend dans l’arbre, plus la probabilité de détection de la panne augmente, mais le coût
augmente également. Inversement, moins on parcourt l’arbre, moins le coût est élevé mais les chances de réussite
s’avèrent moindres. Cela peut être mis en rapport avec le choix des variables pertinentes à présenter sur l’interface
homme-machine.

Le modèle GOMS est sans doute le plus connu des modèles de tâche et fait l’objet de recherches actives
actuellement. Celui-ci vise à prédire la durée de réalisation des tâches, et permet de décrire le choix des méthodes et
des opérateurs. La qualité des prédictions est étroitement liée au grain d’analyse et il est nécessaire de définir a priori
les différentes méthodes. Il permet de prédire les performances d’un utilisateur expert à partir de la description
préalable de la tâche, du langage de commande du système, de paramètres caractéristiques des capacités motrices de
l’utilisateur et des temps de réponse du système et enfin de la méthode de réalisation de la tâche. La prédiction
s’effectue avec l’hypothèse de tâches routinières réalisées par des utilisateurs expérimentés et ceci sans erreur de leur
part.

D’après Coutaz (90), la démarche hiérarchique suivie par GOMS est compatible avec celle pratiquée par les
informaticiens ; cependant, GOMS est très réducteur puisqu’il ne permet de prédire les performances que d’un
utilisateur expert ne commettant pas d’erreur. Par son approche formelle, GOMS a ouvert des perspectives
intéressantes et a conduit à la définition d’autres modèles (tel KLM décrit ci-après). Cependant, pour des tâches
complexes où l’utilisateur est confronté à des situations inhabituelles, sources d’erreurs et de démarches cognitives
variées, les limitations de ce modèle ne semblent pas permettre son utilisation directe.

Le modèle KLM (Keystroke Level Model ; Card et al. 83) est associé à une méthode de calcul de temps de
réalisation de tâches simples. Bien que souvent associée à GOMS, cette méthode nous paraît applicable à tous les
autres modèles de tâche. Ce modèle est dérivé de GOMS et concerne particulièrement les actions physiques que
l’utilisateur doit effectuer pour réaliser une commande. Il permet de prédire ses performances à partir de la description
préalable de la tâche, du langage de commande du système, de paramètres caractéristiques des capacités motrices de
l’utilisateur et des temps de réponse du système et enfin de la méthode de réalisation de la tâche. La prédiction
s’effectue avec l’hypothèse de tâches routinières réalisées par des utilisateurs expérimentés et ceci sans erreur de leur
part.

Les critères ergonomiques concernés par KLM sont les mêmes que ceux obtenus par les réseaux de Pétri du
modèle SADT-Pétri : le retour informatif, la protection contre les erreurs, les actions explicites, le contrôle utilisateur.
Des exemples d’utilisation du modèle peuvent être trouvés dans Coutaz (90) et Haunold et al. (94). Bien que les
principes soient facilement compréhensibles et fournissent des valeurs numériques simples, sa mise en oeuvre pose
rapidement des problèmes : (i) le placement du paramètre relatif à l’activité mentale est difficile, (ii) la modélisation
est très longue (Cohill et al. 88). Ce type de modèle permet essentiellement de prédire le temps de réalisation d’une
tâche sans rendre compte des situations d’élaboration de procédures. L’ensemble des sous-buts est réalisé sans
interruption et dans un ordre fixe souvent en contradiction avec l’activité réelle de l’utilisateur (Aschehoug 91).

Les modèles GOMS et KLM ont été validés au départ avec des tâches de traitement de texte. Le fait que ces
modèles ne tiennent pas compte des erreurs de l’utilisateur et ne prévoient pas de phase de résolution de problème
(phase caractéristique des activités de l’utilisateur lors des situations anormales) ne permet pas d’envisager leur
utilisation directe pour la prédiction de l’efficacité de l’utilisateur lorsque celui-ci effectue des tâches complexes.

Toutefois, on peut souligner que des validations récentes pour des tâches hautement cognitives ont été réalisées au
moyen d’un modèle étendu au calcul du chemin critique pour réaliser la tâche, appelé CPM-GOMS (Gray et al. 92 ;
John et al. 92 ; fig. III.2). Ces études montrent la possibilité d’utiliser le modèle pour évaluer des systèmes en
situation de travail proche de la réalité. CPM-GOMS peut donc être utilisé pour des tests de conception, au lieu de
mettre en place des études empiriques nécessitant des prototypes.

Comme l’indique la figure III.2, CPM-GOMS permet de comprendre les tâches des utilisateurs par une
représentation sous forme de réseau, où le parallélisme est représenté par un “graphique planifié”. Chaque activité est
 Chapitre III 58

représentée par une boîte et une durée associée. Les dépendances entre activités sont représentées par des lignes.
Boîtes et dépendances sont dessinées en accord avec la compréhension de la tâche, telle qu’elle est détaillée par
l’utilisateur. Quand, lors d’activités en parallèle, une séquence d’activités prend plus de temps que les autres, le temps
critique est calculé sur la séquence la plus longue et détermine le temps total pour la tâche complète.

Station de travail courante

tâches chemin critique

Station de travail proposée

tâches chemin critique

Figure III.2 : Évaluation de stations de travail avec CPM-GOMS, (Gray et al. 92)

La méthode DIANE propose une planification hiérarchique des tâches de manière graphique et en explicitant les
tâches humaines, les procédures, la logique d’utilisation du système... L’extension DIANE+ introduit en outre une
méthode de génération automatique d’IHM. Notons que cette méthode s’intègre naturellement dans une démarche de
développement avec la méthode MERISE, puisqu’elle en est issue.

Développée à l’INRIA, MAD est une méthode facilitant la description des tâches des utilisateurs. Le modèle de
tâche obtenu permet de mieux opérationnaliser la différence entre logique fonctionnelle et logique d’utilisation
(caractéristiques de l’utilisateur et de sa tâche), plutôt que de la logique fonctionnelle de l’application et des
contraintes imposées par l’ordinateur. Bien que très prometteur, le rendu de l’interruption de l’activité (abandon,
changement de but, erreur, modification de chemin dans l’arbre) et les erreurs, humaines et/ou techniques, ne sont pas
bien prises en compte dans la description. Notons que ces lacunes tendent à disparaître dans les nouvelles versions de
MAD (voir Hamouche 93, pour l’extension de MAD à la spécification des interfaces).

La méthode basée sur SADT/Pétri est issue du LAMIH, elle a été prévue au départ pour modéliser des tâches de
contrôle de la navigation aérienne. L’association de l’outil SADT, utilisé pour la décomposition fonctionnelle du
problème, à l’outil Pétri employé pour décrire précisément dans le temps le déroulement des opérations, est bien
adaptée à la description de tâches humaines (fig. III.3). Le modèle obtenu est ensuite utilisé lors de l’évaluation
ergonomique pour l’analyse des activités des utilisateurs lors de l’exécution de leurs tâches.

De nombreux paramètres sont enregistrés : informations présentées sur les interfaces, stratégies oculaires (obtenues
par des techniques oculométriques), explications subjectives complémentaires (obtenues par verbalisations et
questionnaires). Ces paramètres sont ensuite utilisés pour affiner le modèle théorique des tâches, selon l’activité réelle
des utilisateurs. Par mise en corrélation, un modèle de l’activité cognitive est obtenu. Chacun des comportements
humains peut à l’aide de ce modèle être analysé finement. Il est ainsi possible de mettre en évidence des lacunes et des
besoins en fonctions et en informations.

SADT/Pétri est adapté à la vérification de l’adéquation des procédures utilisateur à celles préconisées par le
concepteur, puisque le mode de représentation est le même pour les deux analyses (a priori et réelle). Les réseaux
fournissent une description fine du comportement des interfaces, en particulier concernant la réaction technique du
système suite aux opérations de l’utilisateur. Pour l’évaluation, cette description permet d’évaluer les parcours entre
les différents écrans, d’avoir une idée précise des caractéristiques de l’espace théorique de problème (état et
utilisateur) dans lequel va naviguer l’utilisateur. On peut ainsi évaluer les possibilités d’actions offertes à l’utilisateur,
ainsi que la lourdeur des transactions en termes de nombre d’états.
59 Chapitre III

Plus général Système

AO

SADT A2
A1

A21
A13
A11 A22 données de
contrôle
A12
Réseaux de pétri
données Pi données
d'entrées tk de sorties
Pj
Plus détaillé
Mécanisme ou
support d'activité

Figure III.3 : Description de la tâche par SADT et réseaux de Pétri (Abed 90)

Notons qu’il existe de nombreux travaux relatifs à la modélisation de tâches humaines dans un but de conception
et/ou d’évaluation des IHM. Citons par exemple TAKD (Task Analysis Knowledge Description ; Johnson et al. 84),
qui permet à partir de la description des tâches, de type HTA, d’identifier les actions individuelles (classées en actions
génériques) et les objets conceptuels (classés en listes d’objets) avec une bonne analyse de l’existant. La méthode JSD
pour Jackson System Development (Jackson 83), étendue à JSD* (Lim et al. 92), avec globalement les mêmes
objectifs que DIANE pour MERISE, vise à couvrir en continu les phases d’analyse des besoins, de “synthèse” et de
spécification de l’IHM, à l’aide de différents formalismes graphiques et textuels. 1

I.1.2. Les modèles linguistiques

Les modèles linguistiques explicitent la structure de l’interaction homme-machine au moyen de grammaires
(tableau III.2).

Tableau III.2 : Exemples de modèles formels prédictifs : les modèles linguistiques

Techniques Principe / Objectif Critères ergono-miques
concernés
ALG - Construction d’un modèle des actions mises en jeu par l’utilisateur, sous incitation, actions minimales,
(Reisner 84) la forme de règles de production : décomposition récursive des buts des flexibilité, charge mentale,
utilisateurs (symbole initial pour le but général, phrases pour les procédures prise en compte de
et mots pour les actions élémentaires). l’expérience utilisateur
CLG - Description des tâches en une série de modèles établie à chacun de six guidage, contrôle explicite,
(Moran 81 ; Coutaz 90) niveaux d’abstraction : tâches et sémantique pour les buts et sous-buts, charge mentale, expérience
syntaxe et interaction pour la communication entre l’utilisateur et le utilisateur, correction et
système, présentation et unités d’entrée-sortie pour la composante protection erreurs,
physique. homogénéité et cohérence,
compatibilité

1
voir aussi Balbo (94) qui recense un certain nombre de méthodes pour l’évaluation des interfaces utilisateur et Tarby
(93) qui s’interesse aux méthodes utilisables pour la spécification du dialogue homme-machine.
 Chapitre III 60

Tableau III.2 : (suite)

TAG et ETAG - Décomposition en sous-tâches simples routinières pouvant être exécutées incitation, actions minimales,
(Payne et al. 89 ; par l’utilisateur sans prise de décision (organisation des tâches en actions flexibilité, charge mentale,
Schiele et al. 90 ; sous la forme d’un méta-langage). Modélisation de la représentation prise en compte de
Tauber 90) mentale du langage d’interaction. l’expérience utilisateur

Ces modèles sont utilisables pour décrire les tâches d’interaction entre l’utilisateur et l’interface, dans un but
principalement d’évaluation du langage de commande et de sa cohérence. Ces grammaires formelles constituent des
modèles à base d’items à un niveau bas, c’est-à-dire le plus souvent sans considération des aspects conceptuels
(définition de la tâche globale, des sous-tâches et des tâches élémentaires). Poitrenaud et al. (93) parlent à ce sujet de
grammaires d’action, en les situant comme des formalismes qui mettent en avant les liens existant entre le domaine de
l’action et celui du langage.

Le modèle linguistique ALG qui est une adaptation du formalisme BNF 2, comprend une décomposition puis une
hiérarchisation des buts des utilisateurs, et permet de formaliser les entrées-sorties du système. Toutefois, en ne
décrivant que la hiérarchie des buts utilisateur, la grammaire ne rend pas compte des relations avec l’affichage à
l’écran, ni de la dynamique du dialogue. Les interactions homme-machine n’y sont pas suffisamment décrites.

L’hypothèse de base de CLG est qu’il décrit le modèle conceptuel du système vu par l’utilisateur. Cette grammaire
transforme la description des tâches en une série de modèles établie à chacun des niveaux de l’interaction : niveaux
tâche, sémantique, syntaxique et interaction. Un exemple de description d’une imagerie de contrôle d’un procédé
chimique est visible en figure III.4. Le modèle présenté concerne le niveau tâche : la tâche “superviser la fabrication”
qui a comme résultat pour l’utilisateur, la fabrication d’un produit final, le contrôle du système et la connaissance de
son état, est décrite comme l’exécution en parallèle (PAR) d’une suite de sous-tâches. Ces sous-tâches sont ensuite
décrites de la même manière dans la suite de la description.

T-superviser-fabrication= (UNE TACHE

(* assurer la fabrication de produits chimiques différents, en mélangeant des matières premières et un solvant. L’état du
procédé doit toujours être connu et sous contrôle )
NOM= “superviser la fabrication”
RESULTAT= (produit-final ET système-sous-contrôle ET état-connu)
FAIRE (PAR: (* faire en parallèle l’ensemble des tâches décrites ci-dessous)
T-superviser-cellule (T-cellule[i] ET T-cellule-solvant)
T-superviser-température
T-gérer—recettes (T-recette[i])
T-surveiller-systeme (T-procédé-complet))
T-superviser-cellule= (UNE TACHE
NOM= “surveiller les paramètres principaux d’une cellule”
PARAMETRE= (UNE T-cellule[i])
RESULTAT= (etat-cellule ET sous-contrôle)
FAIRE (PAR:
T-superviser-variable (T-matière-première)
T-superviser-système (T-convoyeur ET T-broyeur ET T-cuve-mélangeur)
T-superviser-variable (T-température ET T-débit-solvant ET T-paramètres-exploitation)
T-nettoyage
……

Figure III.4 : Extrait de la description d’une interface avec CLG (Bellotti 94)

Selon Coutaz (90), ce formalisme permet de localiser les décisions d’évaluation qui seront critiques pour
l’utilisateur. L’efficacité de l’interface est évaluée par une estimation de la vitesse d’exécution ou du temps
d’apprentissage (en utilisant des calculs de temps pour réaliser ou apprendre chaque tâche du type “KLM”) ou par une

2
Backus-Naur-Form (voir son utilisation par Reisner 84) est une méthode de description formelle d’un langage
(protocole de communication, langage de commande, langage informatique, etc.). Elle est constituée d’un vocabulaire
(ensemble de symboles) et d’une grammaire (règles d’association de symboles).
61 Chapitre III

estimation de la “charge mentale” de l’utilisateur. Cette approche n’est pas directement exploitable pour évaluer un
produit fini développé avec une autre méthode : il faudrait traduire l’interface en CLG pour en faire l’analyse. La
hiérarchisation des aspects de l’interaction homme-machine est toutefois à retenir. La réécriture du dialogue homme-
machine sous la forme d’une grammaire permet en principe de détecter les problèmes de cohérence, ainsi que les
difficultés et les inconsistances liées à l’apprentissage.

TAG vise à modéliser la représentation mentale du langage d’interaction. La tâche est décomposée en sous-tâches
simples routinières pouvant être exécutées par l’utilisateur sans prise de décision (organisation des tâches en actions
sous la forme d’un méta-langage). TAG aide à juger la structure de tâches décrites à l’aide d’un langage, mais celui-ci
se limite aux tâches simples, c’est-à-dire à la description des fonctions spécifiques du dispositif. Il n’a pas de mise en
relation des différentes tâches simples à des niveaux supérieurs. Pourtant, pour évaluer les qualités ergonomiques
d’une interface, il est nécessaire d’observer les informations visualisées en se basant sur la description de modèles
conceptuels de l’interface.

Tauber (90) propose donc de décrire les procédures d’utilisation et le modèle de fonctionnement en unités ETAG
qui sont des événements de changement de localisation des objets de l’interface ajoutés à TAG. L’idée centrale est
qu’il faut expliciter, les connaissances que l’utilisateur doit avoir sur la structure du dispositif qu’il utilise pour réaliser
ces tâches. Sur le plan de l’évaluation, cette approche permet d’énumérer les propriétés de consistance conceptuelle de
l’interface. Dans ce formalisme, le lien entre les objets mis en jeu dans les actions et les manipulations auxquelles on
peut les soumettre est très faible. Ce qui conduit à un modèle dans lequel le langage d’interaction n’est pas très bien
représenté. C’est pourtant ce qui nous intéresse pour l’évaluation.

Les modèles linguistiques3 sont à retenir pour l’idée de formaliser l’interaction homme-machine comme un
langage de programmation… et donc de pouvoir automatiser l’évaluation. C’est le cas également des modèles formels
qui sont fondés sur une théorie concernant l’activité cognitive de l’utilisateur. Par exemple, CCT (Cognitive
Complexity Theory, Kieras 85) vise à formaliser la notion de complexité du point de vue de l’utilisateur du système
informatique, et ICS (Interacting Cognitive Subsystems, Barnard 87) propose une modélisation cognitive de
l’utilisateur sous forme de sous-systèmes sensoriels, de traitement de l’information, et moteurs. Les tâches y sont
décrites selon divers principes, puis des métriques permettent, pour CCT, de prédire les connaissances requises pour
utiliser l’IHM et certaines difficultés d’utilisation, ou pour ICS, prédire la charge cognitive de l’utilisateur pour une
tâche donnée. Retenons aussi le modèle UAN (Hartson et al. 92) qui permet de décrire des IHM à manipulation
directe à l’aide d’une notation spécifique : expression dans des tableaux des suites temporelles d’actions de
l’utilisateur, des retours d’information et des changements d’état de variables de l’IHM.

I.1.3. Conclusion sur les modèles formels prédictifs et

positionnement dans le cycle de développement
Les modèles prédictifs énumérés ci-dessus s’intéressent à l’interaction homme-machine au sens des tâches et de
leur organisation. Ils sont de plus très importants en tant que support de dialogue entre chaque intervenant du projet.
On oublie aussi trop souvent que de tels modèles peuvent en plus être utilisés une fois l’interface réalisée pour
modéliser les activités des utilisateurs, et comparer cette modélisation à celle effectuée vis-à-vis des tâches prévues
par les concepteurs, afin d’en tirer les conséquences en terme d’aménagement des IHM et/ou de formation.

L’ensemble des modèles formels dits prédictifs peuvent être utilisé pour prédire certains aspects liés à l’interaction
homme-machine (hiérarchie des tâches, cheminement des actions de l’utilisateur, alternatives, temps requis pour
réaliser une tâche…) et faciliter la mise en évidence de problèmes potentiels. Des métriques sont progressivement
mises en place par les chercheurs pour mesurer objectivement des aspects associés à la qualité de l’interaction
(cohérence, compatibilité avec l’image mentale de l’utilisateur, qualité des écrans…).

Tous les modèles de tâches énumérés s’intéressent à l’interaction homme-machine au sens des tâches et de leur
organisation. On peut donc les utiliser dès les étapes d’analyse et de spécification. Les extensions KLM et Pétri
associées respectivement aux modèles GOMS et SADT, permettent de formaliser l’activité de l’utilisateur. Ils sont

3
Voir aussi Poitrenaud (93) qui présente quelques études relatives aux grammaires d’action.
 Chapitre III 62

utilisables lors de la conception détaillée, lorsque l’activité de l’utilisateur est définie par rapport à ces fonctions et la
description obtenue peut être analysée afin d’estimer l’utilité et l’utilisabilité de l’interface (nous le verrons sur une
application dans le chapitre V).

Les modèles linguistiques ALG et TAG permettent la définition de la tâche globale, des sous-tâches et des tâches
élémentaires. C’est pourquoi, comme pour les modèles de tâche, ils sont utilisables dès les étapes d’analyse et de
spécification fonctionnelle. Le modèle CLG apporte une description qui fait apparaître différents niveaux de
l’interaction (sémantique et syntaxique, nous en parlerons au chapitre suivant). En effet, une définition des objets
manipulés et des fonctions est réalisée, des modules sont mis en évidence ainsi que les liens entre fonctions et
modules. De plus, la syntaxe exacte de ces fonctions est décrite, en mettant en évidence l’activité de l’utilisateur.
Enfin, seul CLG s’intéresse à la présentation de l’information et aux entités physiques manipulées. Ce modèle
linguistique est donc utilisable en principe dès l’étape de spécification de l’interface jusqu’à la conception détaillée
(mais nous verrons dans le chapitre V que la réalité n’est pas aussi simple et qu’il existe un certain nombre de limites
liées à son utilisation).

I.2. Les modèles formels dits de qualité de l’IHM, approches

logicielles 4
Les modèles formels dits de qualité de l’IHM sont, dans l’état actuel de la recherche, complémentaires des
modèles formels dits prédictifs décrits précédemment. En effet, ils s’intéressent aux propriétés mesurables de
l’interface, et ceci selon des critères d’utilisabilité formalisés. On distingue des approches d’évaluation automatique de
l’affichage, ainsi que des approches de génération automatique des affichages ou des spécifications d’IHM.

I.2.1. Les systèmes d’évaluation automatique de l’affichage

Le premier type de modèle de qualité des affichages applicable pour l’évaluation des IHM consiste en la mise en
oeuvre d’outils informatiques capables d’effectuer automatiquement des mesures ergonomiques sur des pages-écrans,
indépendamment du contexte d’utilisation. Pour l’évaluation d’un système interactif, de telles approches partent du
principe que certains problèmes ergonomiques liés à l’utilisation de l’interface peuvent être évités a priori. Mais elles
doivent s’intégrer dans une démarche globale d’évaluation selon un ensemble de critères interconnectés dont il s’agit
de gérer la cohérence par rapport aux différents contextes opérationnels d’utilisation.

Plusieurs approches démontrent bien la possibilité de rendre opérationnelles les trop nombreuses recommandations
ergonomiques actuellement proposées dans une forme souvent rébarbative (manuels et guides) tels le Programme
d’analyse des affichages, SYNOP pour l’évaluation de synoptiques et KRI/AG pour l’évaluation d’interface de
dialogue (tableau III.3).

L’analyse effectuée par le programme d’analyse des affichages mis au point par Tullis permet de prédire en
particulier des temps de recherche d’information. Les évaluations qui en découlent relatives à l’utilisation de
l’interface apportent des recommandations pour l’améliorer. Ce programme peut être utile comme outil de
développement itératif, par sa capacité à analyser les différentes versions d’un écran et à en proposer des
aménagements. Notons que ce programme est capable d’évaluer essentiellement des pages-écrans alphanumériques.

4
Dans les modèles formels dits de qualité, Senach (90) distingue également des approches qualifiées de cognitives visant
à prendre en compte certains traitements effectués sur l'information. La plupart de ces approches sont issues de la
psychologie cognitive. Pour notre part, nous avons choisi de nous intéresser essentiellement aux modèles formels dits de
qualité ayant fait l'objet d'implantations logicielles significatives. En effet, ceux-ci font parties d'un courant de recherche de
plus en plus important en informatique.
63 Chapitre III

Tableau III.3 : Exemples de modèles formels de qualité : la complexité perceptive

Techniques Principe / Objectif Critères ergonomiques
concernés
Display Analysis - Mesure de la qualité des affichages en fonction de six paramètres : la densité groupements, clarté,
Program globale d’information, la densité locale, le nombre de groupes d’informations charge mentale
(Tullis 86, 88) distincts, la taille moyenne des groupes, le nombre d’items, la complexité de
l’affichage.
SYNOP - Système expert d’évaluation et d’amélioration automatique de synoptiques groupements, clarté,
(Kolski 89 ; 91a) industriels à partir de recommandations ergonomiques. charge mentale,
- Analyse de la lisibilité des caractères, du format d’écran, de la présentation homogénéité et
des courbes… consistance
KRI/AG - Système à base de connaissance capable d’évaluer automatiquement une groupements, clarté,
(Löwgren et al. 92) interface de dialogue. Création d’écrans avec un outil graphique sous X- charge mentale,
Windows et traduction dans en fichier sous la forme d’un pseudo langage de homogénéité et
programmation (UIL). consistance
- Analyse des fichiers à l’aide de règles issues de l’ergonomie des logiciels et
de guides de style Motif.

La maquette SYNOP et le système KRI/AG permettent l’évaluation respective de synoptiques industriels et

d’interfaces de dialogue dans un environnement graphique en utilisant des bases de connaissances spécifiques. Des
recommandations sont fournies sous forme de commentaires pour KRI/AG (fig. III.5) et des modifications sont
effectuées automatiquement sur les pages-écrans synoptiques avec SYNOP. Cependant, ils ne permettent pas l’étude
globale d’un ensemble de pages-écrans. Ils sont limités par leur principe d’évaluation statique et écran par écran. De
plus, du fait des bases de connaissances utilisées, les modèles de ce type sont limités à un aspect de l’interaction
(affichage homogène) et doivent être associés à d’autres techniques d’évaluation.

La maquette SYNOP a montré la faisabilité de ce type de technique mais la principale difficulté réside dans
l’implémentation d’un interpréteur de synoptique pour chaque type d’écran à évaluer. Le système KRI/AG, qui
interprète des fichiers en UIL (User Interface Language) qui tend à devenir un standard, semble très prometteur pour
une évaluation automatique, mais essentiellement pour des interfaces de dialogue.

écran (TeleUSE) fichier UIL Outil d'évaluation KRI/AG

recommandations
(User Interface
Analyse sous forme de texte
Langage)
des fichiers
Commentaires

Base de connaissance

ergonomie du logiciel
guide de style Motif

Figure III.5 : Principe d’utilisation de KRI/AG (adapté de Lowgren et al. 92)

Les modèles formels de qualité de l’interface cherchent à identifier les propriétés intrinsèques qui auront un effet
sur la performance de l’utilisateur, notamment en limitant les difficultés d’utilisation. Dans cette perspective, plusieurs
travaux tendent à évaluer la qualité ergonomique d’interface sur certains aspects. Par exemple, les recherches, qui vont
dans le sens de l’évaluation automatique d’affichage au moyen des programmes informatiques de Lemke et al. (90),
Gibbons (92) ou Byrne et al. (94).5

5
Notons aussi des travaux récents menés en évaluation d'IHM multi-utilisateurs à partir de critères liées au travail
coopératif (Zorola Villarreal 95).
 Chapitre III 64

I.2.2. Les systèmes de génération automatique de l’affichage

Le second type de modélisation de la qualité des IHM vise la génération automatique d’affichage ou la
spécification d’affichage. Elle a pour objectif de conduire à des affichages respectant a priori des concepts
ergonomiques de base. Trois exemples représentatifs ont été proposés dans le tableau III.4 : le prototype “A
Presentation Tool”, l’approche de “l’analyse de la structure logique de l’affichage” et ERGO-CONCEPTOR. Dans cette
approche à base de connaissance, l'évaluation est donc en fait sous-jacente et vise à rejoindre la conception en
orientant certains choix (en terme d'utilisabilité) le plus en amont possible.

Tableau III.4 : Exemples de modèles formels de qualité : la génération automatique d’affichage

Techniques Principe / Objectif Critères ergono-miques
concernés
“A Presentation Tool” - Automatisation de la présentation de l’information indépendamment de groupements, clarté,
(APT) l’application en utilisant un langage de présentations graphiques (primitives concision, charge mentale,
(Mackinlay 86) graphiques et opérateurs de composition), qui permettent la génération de homogénéité et consistance,
modes de représentation de plus haut niveau. compatibilité
Structure logique de - Description explicite de la structure de l’affichage selon différents niveaux groupements, clarté,
l’affichage d’abstraction puis évaluation de ces règles (relations structurelles entre les concision, charge mentale,
(Perlman 87) entités d’un ensemble d’information formalisées sous la forme d’un réseau homogénéité et consistance,
sémantique). Ces règles sont évaluables et constituent des axiomes de la compatibilité
présentation de l’information.
ERGO-CONCEPTOR - Génération automatique des spécifications d’interface à partir d’une groupements, clarté,
(Kolski et al. 91b ; description de l’application (de type procédé industriel à superviser) selon concision, charge mentale,
Moussa 92) différents niveaux d’abstraction. Les spécifications d’interface sont ensuite homogénéité et consistance,
directement utilisables par le concepteur qui peut réaliser interactivement signifiance des codes,
chaque vue graphique. compatibilité

Ce type de démarche concerne plutôt l’évaluation dynamique des interfaces homme-machine. Pourtant avec “A
Presentation Tool”, les modes de représentation générés automatiquement permettent la représentation
essentiellement statique de données numériques à l’aide de fonctions de type histogramme, barre-graphe, etc. Les
alternatives de conception générées sont testées en fonction de critères graphiques statiques de conception. Cet outil
possède une certaine capacité à décrire des contraintes de traitement de l’information visuelle par l’utilisateur et à
rendre explicites les conventions de lecture de l’information graphique.

L’affichage doit rendre apparente la structure logique de l’information, à l’aide du programme de Perlman, la
structure de l’affichage est décrite de manière explicite, selon différents niveaux d’abstraction (écran en cinq zones, la
première zone contient quatre éléments, etc.). Les relations structurelles entre les entités d’un ensemble d’information
sont formalisées sous la forme d’un réseau sémantique. Le modèle de description obtenu par cette technique, permet
d’inférer quels attributs d’affichage doivent être utilisés pour mettre en évidence cette structure. Les aspects
ergonomiques liés à la présentation sont formalisés, en établissant des liens entre des propriétés structurelles de
l’affichage et des règles de présentation. Cependant, ce type de démarche se restreint trop à une aide à la conception
des aspects liés à la présentation, sans s’occuper du contexte d’utilisation de la vue.

Ce n’est pas tout à fait le cas du système ERGO-CONCEPTOR qui apporte une aide à l’évaluation, sous la forme de
spécifications, en proposant au concepteur des modes de représentation, supposés a priori adaptés ergonomiquement
aux tâches de contrôle (fig. III.6). Le concepteur peut les sélectionner directement sur l’écran et générer
interactivement des vues de type synoptique industriel. Ce système est actuellement à l’état de maquette de
laboratoire. Les vues obtenues par ces outils de génération automatique d’affichage doivent être validées ensuite avec
les utilisateurs.
65 Chapitre III

Description interactive Génération

de l'application Base de automatique de Base de
en y exprimant données spécifications d'IHM données
les besoins "application" à partir spécifications
des utilisateurs d'une base de règles d'IHM

Description interactive des vues en se basant

ou non sur les alternatives (spécifications d'IHM)
proposées automatiquement

Figure III.6. : Principe global d’utilisation du système ERGO-CONCEPTOR

L’intérêt de ces systèmes consiste avant tout en l’automatisation de plusieurs étapes de la conception et de la
réalisation d’interface. Un intérêt de ce type d’approche est que la génération des spécifications se base sur des
données issues de la description de l’application (un système industriel à superviser). Certains chercheurs s’engagent
dans cette voie qui vise à générer automatiquement des spécifications d’interface ou des pages-écrans, à partir de
l’énoncé préalable de spécifications. Parmi ces approches de génération automatique, citons les systèmes UIDE (Foley
et al. 91) et son dérivé USAGE (Byrne et al. 94), SAGE (Roth et al. 94), les travaux menés autour de DIANE+ (Tarby
93), ou SIROCO (Normand 92).

I.2.3. Conclusion sur les modèles formels dits de qualité de l’IHM

Il faut considérer que l’ensemble de ces systèmes sont à l’état de prototypes de recherche, même s’ils ont été
validés sur des cas concrets. Ils sont censés intervenir sur des pages-écrans réalisées ou en cours de prototypage afin
d’apporter une aide à l’évaluateur dans sa démarche globale, en se focalisant sur des critères d’utilisabilité. De tels
systèmes devraient bientôt être intégrés dans des environnements graphiques de développement.

En effet, un outil d’évaluation d’interface homme-machine ne peut se contenter d’une évaluation portant
exclusivement sur l’un ou l’autre de ses aspects. Il doit pouvoir caractériser les points forts et les points faibles de
l’interaction ; l’analyse doit porter aussi bien sur le langage de commande en entrée comme en sortie, que sur
l’organisation des écrans. L’ensemble des travaux présentés suggère qu’il est difficile de développer un outil capable
d’évaluer n’importe quelle interface. Un outil vraiment satisfaisant doit en fait être constitué d’un véritable
environnement d’évaluation.

Lorsque les outils d’évaluation automatique d’affichage et de génération de spécification seront disponibles sur le
marché, c’est lors des étapes de conception et de codage qu’ils devrait être possible d’évaluer l’IHM. Toutefois, il sera
important que ces futurs systèmes s’intègrent de manière naturelle dans les méthodes du génie logiciel.

Cette idée de ramener l’évaluation a priori le plus haut possible dans le développement, en la rendant
opérationnelle sous la forme le plus souvent d’un système à base de connaissance, augure bien des environnements
graphiques à venir.

II. S YNTHÈSE DES MÉTHODES ET TECHNIQUES D ’ ÉVALUATION RECENSÉES

Nous avons effectué une synthèse des méthodes et techniques, en les réactualisant et en ne retenant que celles
utilisables pour l’évaluation des IHM tout au long du développement. Le recensement des méthodes et techniques se
rapproche de la classification proposée par Whitefield et ses collègues (op. cit.). Nous l’avons mise à jour, en étudiant
les méthodes et techniques vis-à-vis de l’évaluation de systèmes interactifs. Elles ont été détaillées dans le chapitre
précédent et dans celui-ci avec des tableaux présentant leur principe, les critères ergonomiques qui nous paraissent
potentiellement concernés —parmi ceux énumérés dans le tableau I.1 du chapitre I— et plusieurs références
bibliographiques.
 Chapitre III 66

La figure III.7 reprend les méthodes et techniques détaillées dans ce mémoire en les localisant dans leur approche
respective.6

Recensement des méthodes et techniques d'évaluation des IHM

Approches centrées sur les utilisateurs
Diagnostic d'usage Estimation de la charge de travail
L'interface Arbre des causes Echelles subjectives
existe Incidents critiques Mesures physiologiques
Traces du travail (papier) Mesure de performance
Recueil de l'expertise Modèle normatif
Questionnaires
Mouchard électronique Tests de conception
Tactiques visuelles Prototypage
Enregistrement vidéo Groupes de discussion
Analyse des protocoles Banc d'essai final

Approches centrées sur une expertise

Expertise humaine
Grille d'évaluation
Expérience de l'analyste
Cognitive Walkthroughs
Approches centrées sur une modélisation
Modèle formel prédictif Modèle formel de qualité
Modèles de tâches Évaluation automatique
L'interface est (HTA, GOMS, DIANE, MAD, SADT-Petri) de l'affichage
Modèles linguistiques Génération automatique
inexistante (ALG, CLG, TAG) de l'affichage

Figure III.7 : Recensement des méthodes et techniques d’évaluation des IHM selon les trois approches proposées

Au vu des différents constats concernant les trois approches discutées, l’objectif de notre recherche est de proposer
une démarche d’évaluation tout au long du cycle de vie des systèmes interactifs. En accord avec le principe de
l’évaluation énoncé précédemment dans le chapitre I (“Toute évaluation consiste à comparer un modèle de l’objet
évalué à un modèle de référence permettant d’établir des conclusions”), la démarche d’évaluation dépend des
approches utilisées (fig. III.8) :
• Pour la première approche dite centrée sur les utilisateurs (1), le principe d’évaluation consiste en un recueil
et en l’analyse de données, puis en un rendu de l’utilisation de l’IHM.
La comparaison est réalisée par rapport aux performances attendues et spécifiées lors de l’analyse des besoins.
Les résultats de l’évaluation devront être pris en compte sur le système à évaluer, ce qui n’est pas toujours
possible en réalité si le système est déjà réalisé.
• Lors des approches centrées sur une expertise (2), le modèle observé est celui de l’expert, ou une grille
complétée des recommandations ergonomiques utilisées. Le modèle de l’évaluateur correspond à ce que
l’expert considère comme une bonne interface, ou à des “bonnes” notes désirées pour chaque critère
d’évaluation.
• Avec les approches centrées sur une modélisation (3), en plus de valider ou non l’interface, les résultats de
l’évaluation doivent être justifiés et directement réutilisables. En effet, lorsque des défauts sont localisés, des
améliorations peuvent être proposées et donc directement inférées sur le développement.
Cette approche de l’évaluation analytique des IHM constitue l’objet principal de notre travail ; elle est
détaillée dans la suite du mémoire.
6
Ce recensement des méthodes et techniques utilisables pour l’évaluation des IHM, présentées dans les chapitres II et III, a fait l’objet
d’un article de synthèse dans la revue Technique et Science Informatiques (Grislin, et al. 96). Il a été soumis fin Juillet 1994, accepté sous
réserve de modifications en Janvier 1995, celles-ci ayant été prises en compte dans une nouvelle version début mai 1995, acceptée en août
1995.
67 Chapitre III

Pour les trois approches proposées, les informations issues de l’analyse et de l’élaboration des modifications en
terme d’utilité et d’utilisabilité, mettent à jour des informations sur l’interaction homme-machine. Ces résultats
doivent enrichir la connaissance en évaluation qui sert de base au modèle de l’évaluateur. L’interface validée (ou non)
constitue donc un retour d’expérience utile et primordial pour l’évolution du domaine de la conception et de
l’évaluation des IHM.

Propriétés de l'évaluation
Données de bases
Techniques de recueil de données

SYSTÈME À ÉVALUER
Sous-système 1
Sous-système 2 niveau d'adéquation de l'interface
PROCÉDÉ à répondre aux besoins
…… Modèle
observé
Sous-système n Evaluation de l'interface Interface
homme-machine validée

Utilité Utilisabilité
CONNAISSANCES Modèle de
EN ÉVALUATION l'évaluateur

approches centrées sur l'expertise(2) Analyse, Elaboration

et sur la modélisation (3) des modifications en
terme d'utilité
approches centrées sur les utilisateurs (1) et sur l'expertise (2)
Analyse, Elaboration
des modifications en
terme d'utilisabilité

Figure III.8 : Principe de l’évaluation selon les trois approches proposées

C ONCLUSION SUR L’ ÉVALUATION ANALYTIQUE DES IHM

La description de l’interaction homme-machine au moyen des modèles de tâche et linguistiques fournit un support
que l’on qualifie dans la littérature de formel, pour l’évaluation prédictive de la performance, puisqu’elle propose une
description mesurable du comportement de l’utilisateur. Le modèle obtenu est ainsi utilisé pour l’évaluation
ergonomique en analysant la représentation des activités probables des utilisateurs lors de l’exécution de leurs tâches.

De nombreux paramètres doivent être recueillis, souvent au moyen des techniques empiriques précédemment
citées : informations présentées sur les interfaces, stratégies oculaires (obtenues par des techniques oculométriques),
explications subjectives complémentaires (obtenues par verbalisations et questionnaires). Ces paramètres sont ensuite
utilisés pour affiner le modèle théorique des tâches, selon l’activité réelle des utilisateurs. Cette description permet
d’évaluer les parcours entre les différents écrans, d’avoir une idée précise des caractéristiques de l’espace théorique du
problème dans lequel va naviguer l’utilisateur. On peut aussi évaluer les possibilités d’actions offertes à l’utilisateur,
ainsi que la lourdeur des transactions en termes de nombre d’états. Ce type d’approche analytique permet de mettre en
évidence des lacunes dans l’interaction homme-machine et des besoins en fonctions et en informations.

Ces modèles sont encore à l’état de recherche et actuellement insuffisamment développés ou validés pour
constituer des outils d’évaluation à part entière. Leur utilisation nécessite un travail de formalisation assez long et peu
d’informations sont données concernant la manière d’effectuer des tests en cours de conception.

Même si c’est souvent lors des étapes finales du cycle que certains problèmes ergonomiques relatifs à l’utilité ou
l’utilisabilité de l’interface sont détectés, certaines lacunes sont introduites dès les différentes étapes de spécification-
conception. Celles-ci n’apparaissent que tardivement alors qu’une évaluation a priori les aurait peut-être détectées
plus tôt. Ne serait-il pas possible d’évaluer l’interface avant qu’elle ne soit réalisée ?
 Chapitre III 68

Le chapitre IV est principalement consacré à cette approche analytique d’évaluation. Comme celle-ci passe par une
modélisation de l’interaction homme-machine, un “canevas” théorique de représentation sera proposé. Puis nous
proposerons une démarche d’évaluation a priori des interfaces homme-machine qui permettra de prendre en
compte l’évaluation dès les phases de spécification fonctionnelle, de conception préliminaire et détaillée.
Chapitre IV

Proposition d’une démarche d’évaluation a priori des Interfaces

Homme-Machine
(Application aux systèmes industriels de supervision)

INTRODUCTION

I. RECHERCHE D’UN CANEVAS THÉORIQUE POUR DÉCRIRE

L’INTERACTION HOMME-MACHINE

II. PROPOSITION DU CANEVAS THÉORIQUE COSÉSYL

III. PROPOSITION DE LA DÉMARCHE D’ÉVALUATION A PRIORI

CONCLUSION SUR LA DÉMARCHE D’ÉVALUATION PROPOSÉE

71 Chapitre IV

Actuellement, on constate que, mis à part dans les démarches de maquettage/proptotypage, seules des évaluations à
tendance empirique sont réalisées lors de la phase ascendante de développement en V d’une IHM. L’interface n’est
donc évaluée que lorsqu’elle a été codée —ou lorsqu’il existe une maquette ou un prototype. Aussi, des lacunes
introduites lors des étapes de spécification-conception, sont détectées tardivement alors qu’une évaluation a priori les
aurait sans doute détectées plus tôt. Ceci est d’autant plus coûteux pour l’équipe de développement que l’application
visée est complexe (comme c’est le cas pour les applications de supervision).

Les deux premières parties de ce chapitre portent sur la description de l’interaction homme-machine pour
l’évaluation des interfaces, avec pour point de mire les applications complexes qui nous préoccupent dans ce
mémoire. Pour cela, nous présentons les modèles d’architecture existant puis introduisons un canevas théorique pour
formaliser l’interaction dès le début du développement. Celui-ci va d’une part, définir un cadre de pensée pour
l’évaluation tout au long du cycle, et d’autre part, fournir à l’équipe de développement une structure générique à partir
de laquelle il est possible de construire un système interactif particulier.

Puis, nous proposons une démarche d’évaluation des IHM pour la phase descendante du cycle en V. Cette méthode
qui vise l’évaluation a priori, est basée sur une distribution des techniques d’évaluation énoncées au chapitre II, dans
le canevas proposé.

I. R ECHERCHE D ’ UN CANEVAS THÉORIQUE POUR DÉCRIRE L’ INTERACTION

HOMME - MACHINE

La démarche est basée sur l’hypothèse que l’étude d’une description de l’interaction homme-machine peut
contribuer à évaluer l’utilité et l’utilisabilité des systèmes de supervision. C’est pourquoi nous recherchons un canevas
théorique qui sera utilisé comme trame pour décrire la communication entre l’homme et la machine tout au long du
développement. Cette description permettra ensuite d’évaluer la complexité de l’interaction.

I.1. Évaluer tout au long du développement

L’un des principes directeurs de la démarche est d’effectuer un suivi du développement de l’interface étape par
étape, pour critiquer les propositions et les choix issus de la spécification-conception ou de la réalisation-validation de
l’IHM. Ainsi, en intégrant l’évaluation tout au long du cycle en V, l’équipe de développement ne passe à l’étape
suivante qu’à la condition que l’interface corresponde aux besoins et réponde aux critères ergonomiques, en respectant
les contraintes du domaine d’application : sécurité, production, ergonomie… (cf. définition de l’évaluation d’un
système homme-machine, chapitre I).

Rappelons que le cycle de développement en V comprend une démarche descendante de conception-réalisation

puis une démarche ascendante de réalisation-validation :

• Les phases de spécification et de conception conduisent à définir des niveaux de description de plus en plus
détaillés.

• Les phases de tests, d’intégration et de validation permettent d’évaluer la conformité de la réalisation pour
chaque niveau de la conception en commençant par les parties les plus élémentaires puis en remontant
progressivement jusqu’au produit complet.

Comme on peut le voir sur la figure IV.1, à chaque étape de la conception est associée une étape de test et
d’évaluation de la conformité. Les deux démarches descendante et ascendante sont donc complémentaires (cf. annexe
A).
 Chapitre IV 72

Analyse des besoins, Exploitation Maintenance,

Conception préliminaire et Recette & validation
détaillée du système Intégration du système
CYCLE DE VIE DU LOGICIEL INTERACTIF

(1) (2)
Spécification
Validation
fonctionnelle
Spécification
EVALUATION EVALUATION Validation
ConceptionA PRIORI Intégration
préliminaire A POSTERIORIet tests

Conception
Tests unitaires
détaillée
Conception
Tests
Programmation
Codage
Codage

Réalisation

Figure IV.1 : Démarche d’évaluation a priori et a posteriori

parallèle au cycle de développement d’une IHM

Tout au long de ce cycle, nous partons de l’hypothèse que l’évaluation peut et doit être réalisée à chaque étape :
dès la spécification fonctionnelle, la conception préliminaire et la conception détaillée, et ceci jusqu’à la validation de
l’interface, en passant par les tests unitaires et d’intégration (Kolski et Grislin 95). Les techniques principalement
employées sont issues des approches empiriques, des approches expertes et des modèles formels prédictifs de
l’approche analytique (Grislin et al. 96). Aussi, deux types d’évaluation peuvent être réalisés (Fig. IV.1) :

(1) l’évaluation a priori, qui intervient dans la phase descendante du cycle de développement c’est-à-dire au
cours de la spécification-conception. Elle porte principalement sur l’évaluation de l’interface vis-à-vis de son
utilité par rapport aux besoins qui ont été définis et de son utilisabilité au regard des critères ergonomiques
recensés.

(2) l’évaluation a posteriori, qui est mise en œuvre dans la phase ascendante de réalisation et de validation.
L’évaluation y est effectuée en utilisant les méthodes classiques, déjà discutées dans le chapitre II (approches
empiriques et expertes).1

La proposition énoncée dans ce chapitre concerne l’évaluation a priori, peu étudiée actuellement dans les
systèmes industriels complexes, à l’inverse des méthodes utilisables a posteriori et illustrées dans le chapitre II.

I.2. La complexité de l’interaction homme-machine

La complexité de l’interaction peut être illustrée par les points suivants (Meinadier 91). Ceux-ci sont fortement liés
aux problèmes de qualité du dialogue homme-machine énoncés au chapitre I (§ I.2).

• la complexité du dialogue homme-machine, liée à l’activité mentale de l’homme. Celle-ci est a priori
illimitée et non canalisée contrairement à la communication côté interface qui est structurée par le programme
informatique.

1
Pour seconder les méthodes classiques à tendance empirique, des méthodes analytiques peuvent être envisagées.
L’évaluation sera alors basée sur la comparaison de l’interface réellement conçue avec un modèle de l’interaction défini au
cours de la phase descendante. Nous y reviendrons lors de nos perspectives de recherche (chapitre V).
73 Chapitre IV

• la grande diversité des applications potentielles, liée tant à la diversité des domaines d’application
(administration, bureautique, conception, conduite de procédé, etc.) qu’à la diversité des objets manipulés
(texte, graphiques, multimédia).

• la diversité des matériels d’interfaçage à prendre en compte aussi bien en entrée (tablette graphique, souris,
“joystick”, boule roulante, clavier, voix, boutons de pupitre, écran tactile, geste) qu’en sortie (écrans
alphanumériques, graphique monochrome ou couleur, son, afficheurs analogiques, numériques, synthèse
vocale…).

• l’hétérogénéité des environnements, matériels et logiciels de base, sur lesquels devra pouvoir fonctionner le
système interactif.

• la reprise d’applications anciennes, où le nouveau poste de travail doit savoir communiquer avec l’ancienne
application, ou encore passer aux nouvelles interfaces sans trop de perturbation pour les utilisateurs.

Tout en étant la plus ouverte possible à cette diversité de types de dialogues, d’applications, de matériels, l’IHM
doit assurer la séparation entre le monde virtuel de l’application qui reste dans son propre domaine fonctionnel, et le
monde physique des entrées-sorties. Comme nous le verrons ci-après, ceci doit permettre à l’application de rester à
son niveau d’abstraction et d’ignorer le dialogue avec les dispositifs physiques d’entrée/sortie.

Il est alors nécessaire de définir une architecture de l’interface permettant d’introduire une certaine modularité de
réalisation. L’évaluation de l’interaction homme-machine sera réalisée par la suite selon cette architecture. Différents
modèles architecturaux sont alors possibles.

I.3. Les modèles architecturaux

Le dialogue homme-machine peut être vu comme étant essentiellement composé d’activations d’entrées-sorties
dont l’interface n’a pas la maîtrise du fait de l’activité mentale de l’homme ; ceci introduit une grande complexité. On
cherche donc à rendre l’interaction modulaire pour mieux maîtriser la complexité du dialogue ; c’est un des buts de la
recherche d’architectures.

Différents types de modélisation ont été proposés pour la réalisation de systèmes interactifs. Ils ont pour objet de
fournir des structures génériques à partir desquelles il est possible de construire l’interface. Les trois types suivants en
donnent une vision globale.

• Dans la modélisation en terme de langage, initiée par Moran (81) et affinée par Foley et al. (82), on considère
l’interaction homme-machine comme une communication, où les niveaux d’abstraction sont représentés par
une structure linguistique selon plusieurs composantes : conceptuelle, sémantique, syntaxique et lexicale.
Comme nous le verrons en I.4, cette modélisation a inspiré le modèle de Seeheim et ses dérivés.

• Dans la modélisation en terme d’entrée-sortie (présentée dans Coutaz 90), les divers niveaux d’abstraction
sont vus soit comme des couches d’échange avec l’utilisateur, représentées par une hiérarchie de machines
abstraites, soit comme des modules logiciels nécessaires à la réalisation de l’interface homme-machine. Ces
modèles en strates successives d’abstraction permettent de cacher progressivement à l’application, la
complexité des entrées-sorties et la prise en compte des événements des utilisateurs.

• La modélisation dite multi-agents, où les niveaux d’abstraction sont appelés “agents”, mais correspondent en
fait à des systèmes de traitement de l’information très proches des couches ou modules ci-dessus. L’originalité
et la complexité de cette démarche est que cette organisation travaille en parallèle et coopère (CACM 94).

Quelle que soit la démarche proposée, l’interaction est toujours représentée comme une succession d’opérations de
communication et de traitement s’effectuant à divers niveaux d’abstraction : depuis les actions physiques de
l’utilisateur jusqu’aux concepts de l’application, et inversement, depuis les concepts jusqu’aux caractéristiques de
fonctionnement des unités physiques d’entrée-sortie. Ces modèles à niveaux sont fondés sur la description de
 Chapitre IV 74

l’interface en une suite de niveaux descriptifs et hiérarchisés. Cette description de l’interaction homme-machine est
basée sur : (i) les éléments intrinsèques de l’interface qui décrivent les propriétés lexicales, syntaxiques et sémantiques
des constituants, (ii) les éléments externes de l’interface qui correspondent aux connaissances antérieures qu’a
l’utilisateur sur la tâche. Ce dernier type met en relation les objets et actions du domaine décrits par les futurs
utilisateurs.

Nous retenons les idées de base de la modélisation en terme de langage qui concentre la représentation sur le
dialogue, moins bien décrit dans les autres modèles.

En effet, le point de vue en couches modulaires ainsi que l’approche “multi-agents” définissent l’architecture
logicielle des systèmes interactifs mais pas l’organisation de l’interaction homme-machine. Notons que Coutaz (90)
introduit les aspects du modèle Langage dans le modèle multi-agents avec le modèle PAC qui structure un système
interactif en trois constituants : la Présentation, l’Abstraction et le Contrôle.

Les différentes abstractions du modèle Langage s’apparentent à des niveaux de conception d’une IHM ; c’est
pourquoi les idées de base de ce modèle sont utilisées dans la suite de nos travaux pour définir un canevas de
l’interaction homme-machine. La partie suivante indique les principes directeurs de la classe des modèles Langage ;
un exemple marquant de cette classe, le modèle de Seeheim, y est présenté.

I.4. La modélisation en terme de langage

Les modèles d’architecture de type Langage s’inspirent de l’analogie entre l’interaction homme-machine et les
dialogues entre individus (Coutaz 90). Ces architectures fonctionnelles sont des modèles à niveaux qui considèrent
l’interaction comme un dialogue analogue à une conversation humaine —deux individus peuvent échanger des idées à
condition d’utiliser le même langage. De la même manière, l’utilisateur et le système communiquent par
l’intermédiaire d’un langage commun.

Ces modèles linguistiques sont basés sur une structure à trois composantes : la sémantique, la syntaxe et le
lexique :

• La sémantique définit la signification des phrases. Elle représente les concepts et le savoir-faire dans un
domaine donné. La sémantique permet la description précise des classes d’objets auxquelles l’utilisateur et le
système font référence dans la conversation, établit les liens fonctionnels entre entrées-sorties et l’application
technologique. Pour le système interactif, la sémantique est relative aux séquences d’événements issus des
dispositifs physiques.

• La syntaxe définit la construction des phrases du langage à partir des éléments syntaxiques. Un tel élément est
une unité qui ne peut être décomposée plus avant sans perdre sa signification. Au sein de l’interface, elle
correspond à la structure des entrées ou la disposition des items sur l’écran.

• Le lexique définit la production des unités syntaxiques à partir d’un vocabulaire. Dans le cas d’une interface,
ce vocabulaire comprend tout ce qu’il est possible de manipuler à partir des dispositifs d’entrée et de sortie
(frappe au clavier, affichage d’icône à l’écran…).

Foley et Van Dam (op. cit.) furent parmi les premiers à tenter cette vue linguistique sur l’interaction homme-
ordinateur. Ils ajoutent toutefois un niveau conceptuel supérieur : ce niveau énumère les objets et les transformations
possibles, c’est-à-dire la définition de la tâche globale, des sous-tâches et des tâches élémentaires. Pour détailler et
aider la description de l’interface par le concepteur, Foley et Van Dam ont utilisé un formalisme spécifique qui
différencie les types de ces objets, leurs relations, les propriétés et opérations réalisables. Ce mode de description
(notamment la description des entrées sous la forme d’une grammaire BNF) décrit les séquences d’actions comme des
segments de la syntaxe d’un langage.
75 Chapitre IV

Parmi la classe des modèles du type Langage, le plus connu est certainement le modèle de Seeheim2 (Pfaff 85). Il
part du principe que la logique de l’interaction homme-machine peut être décrite comme une communication. Trois
fonctions y sont considérées comme des processus séparés (fig. IV.2).

Interface Homme-Machine

Contrôle de Interface avec

Utilisateur Présentation Application
dialogue l'application

structure modèle de structure

externe dialogue interne

Figure IV.2 : Structure du modèle de Seeheim

• La présentation correspond au composant responsable de la présentation externe des données de l’interface. Il

représente le niveau lexical, comprend les images qui apparaissent sur l’écran, prend en compte les entrées
utilisateur à partir du dispositif d’entrée et fait la conversion des données d’entrées dans une forme adaptée au
besoin des autres constituants de l’interface.

• Le contrôle de dialogue s’occupe de la gestion des dialogues, soit la structure syntaxique du dialogue
utilisateur-application en visant une spécification exécutable.

• L’interface avec l’application concerne l’activation des fonctions de l’application. C’est la représentation de
l’application du point de vue de l’interface au niveau sémantique, soit l’intermédiaire entre l’interface
proprement dite et le programme d’application.

Chacun de ces constituants correspond à un aspect du modèle Langage : la présentation concerne l’analyse
lexicale ; le contrôle de dialogue est responsable de l’analyse sémantique et gère l’état de l’interaction ; l’interface
avec l’application définit auprès du contrôleur la vue sémantique du système.

La réalisation d’interface doit prendre en compte les aspects ergonomiques et l’ensemble des problèmes techniques
de mise en œuvre de l’interaction. C’est pourquoi la voie que nous proposons est plus directement tournée vers la
conception de système homme-machine pensée en terme de dialogue. L’interface apparaît donc comme un interprète
entre l’utilisateur et le processus à superviser. Elle doit traduire les intentions de l’homme vers le processus et
interpréter pour l’homme les retours du processus.

Ainsi, nous partons sur l’hypothèse que l’IHM de supervision peut être structurée comme un langage avec ses
différents niveaux : conceptuel, sémantique, syntaxique et lexical. Dans la partie III, cette métaphore du langage va
nous permettre de structurer la conception et l’évaluation de l’interface. Dans ce but, il s’agit d’abord de définir plus
précisément le canevas théorique retenu.

II. P ROPOSITION DU CANEVAS THÉORIQUE COSÉSYL

En nous calquant sur les principes du modèle Langage, notre proposition réside dans un canevas théorique en
quatre niveaux pour décrire l’interaction homme-machine : le modèle CO nceptuel de l’interface qui englobe les trois
autres, la SÉ mantique de la tâche, la définition SY ntaxique du dialogue, et la représentation L exicale (fig. IV.3). Dans
la suite de cet exposé, nous l’appellerons COSÉSYL. Chacun de ces niveaux est décrit dans les paragraphes suivants.
Ce

2
Notons que les modèles ARCH (Bass et al. 91) et PAC-AMODEUS (Nigay et al. 91) sont considérés comme des
versions plus modernes du modèle de Seeheim. Nous gardons tout de même Seeheim qui permettra de décrire nos
propositions dans un cadre connu de tous.
 Chapitre IV 76

canevas n’est pas complètement nouveau puisqu’il est très proche de ceux présentés précédemment ; nous allons
tenter dans ce mémoire, de l’adapter aux IHM de supervision.

Niveau d'interaction
Langage homme-machine objets
opérations
buts et tâches
Que peut-on faire ? modèle COnceptuel attributs
de l'interface relations

Sémantique
Que se passe-t-il si ? SÉmantique
de la tâche effets des commandes

Comment faire pour ? définition

Syntaxique SYntaxique du
dialogue séquences d'E/S

Que signifie telle représentation

Lexical
information ? Lexicale représentation physique,
dénomination, codage

Figure IV.3 : Canevas théorique pour décrire l’interaction homme-machine ( COSÉSYL)

Pour illustrer l’architecture proposée, nous nous inspirons d’un exemple simplifié de supervision d’un réacteur
nucléaire par un opérateur à partir d’un poste central de commande. Sans entrer dans le détail du procédé, nous dirons
simplement que celui-ci est un réacteur compact à eau sous pression (PWR) utilisé pour la propulsion navale ( Berger
91 ; Salazar-Ferrer 91, 92 ; Grislin et al. 92b).

Le procédé est illustré par la figure IV.4 qui présente un schéma succinct du réacteur. Il comprend principalement
le cœur où se situe la fission d’atome, le générateur de vapeur, le pressuriseur qui permet de maintenir le circuit
primaire à une pression constante, un turbo alternateur et un condenseur, les circuits primaire et secondaire.

circulation eau Enceinte étanche

primaire
circulation eau-
vapeur secondaire
Générateur de
Vapeur (GV)
VS vapeur pressuriseur
VC circuit secondaire
Conversion
d'énergie eau

Pompe
primaire
Condenseur
V1

Cœur
pompe
alimentaire 1 V2
PPD
circuit primaire dérivé
pompe
alimentaire 2 VP
} vers circuits auxiliaires
de refroidissement

Figure IV.4 : Schéma du réacteur compact à eau sous pression

Le rôle de la chaudière nucléaire est de fournir le débit de vapeur nécessaire à l’alimentation d’un groupe
turboalternateur. Dans un réacteur à eau pressurisée, cette vapeur est produite dans un générateur de vapeur (GV) qui
77 Chapitre IV

coiffe le cœur du réacteur. Le fluide de la boucle primaire, eau sous pression, chauffe durant son passage dans le cœur
puis cède cette chaleur dans le GV. La partie secondaire du générateur de vapeur étant à pression plus faible, l’eau
d’alimentation secondaire est chauffée puis vaporisée. Elle est ensuite envoyée vers la turbine puis condensée avant
d’être rejetée dans le GV via les pompes et les vannes alimentaires. 3

II.1. Le modèle CO nceptuel de l’interface

Pour bien prendre en compte les intentions de l’utilisateur dans la description de l’interaction, nous prenons
explicitement en compte les buts et les tâches de l’opérateur de supervision. A partir de l’analyse de la tâche et de sa
planification hiérarchique, ce niveau définit la tâche globale, les sous-tâches et les tâches élémentaires.

II.1.1. Description du niveau CO nceptuel

Le niveau conceptuel a pour objet de construire un modèle de la tâche en identifiant et en classant les concepts
importants de l’application. A ce niveau sont donc déterminés :

a. les types d’objets manipulés par l’application et dont l’utilisateur a besoin pour exécuter sa tâche,

b. les opérations sur les objets, leurs attributs et leurs relations.

Le niveau conceptuel consiste à décrire la tâche de supervision du système et à en déduire les besoins de
l’utilisateur. Il fait donc appel aux recherches nombreuses et pluridisciplinaires dans le domaine de l’analyse de la
tâche.

a. Analyse de la tâche et définition des objets dont l’utilisateur a besoin

Ce dont a besoin l’opérateur de supervision de la chaufferie nucléaire est défini en fonction des actions qu’il devra
effectuer sur le procédé pour réaliser ses tâches :4

• La tâche principale consiste (entre autres) à asservir en permanence 5 la puissance produite par le primaire à la
puissance demandée par le secondaire (voir la décomposition fig. IV.5).

• La tâche de régulation est généralement gérée en automatique par des régulateurs, mais l’opérateur intervient
lors des situations transitoires et des variations d’allure.

• Il a de plus une activité de surveillance et de diagnostic importante lors de la conduite en mode dégradé.

La tâche globale d’asservissement peut être composée des tâches suivantes : réguler la température moyenne
primaire, prendre en compte l’environnement, contrôler l’évolution de la masse d’eau dans le GV, réguler la pression
primaire, contrôler le fluide primaire, réguler la pression secondaire. Ces sous-tâches peuvent ensuite être
redécomposées jusqu’aux tâches élémentaires, qui sont des actions directement réalisables au moyen de l’interface
(fig. IV.5).

La représentation des tâches de l’opérateur peut être réalisée par différents modèles hiérarchiques. Nous en avons
décrit plusieurs dans le chapitre III (HTA, MAD, GOMS…).

3
Les explications concernant ce type de réacteur restent intentionnellement très générales, nous ferons l’analogie avec
un réacteur classique. Concernant la technologie et le fonctionnement, nous nous sommes inspirés entre autres de Siebert et
al. (88), Alengry (89), et de plusieurs articles issus des Techniques de l’Ingénieur (92).
4
Notre énumération est bien entendu non exhaustive, et nous ne présentons ici que les principes généraux.
5
Dans un sous-marin nucléaire, le réacteur doit pouvoir fournir à tout moment la puissance demandée, avec une
dynamique rapide en fonction du niveau opérationnel de la mission (il doit toujours y avoir assez d’énergie pour
remonter !).
 Chapitre IV 78

puissance neutronique (Wn)

Asservir en Réguler la (2) surveiller les flux neutronique
permanence la température paramètres pression primaire (p1)
puissance commander les grappes de contrôle variation de température (∆T)
moyenne primaire réguler en faible surveiller les paramètres régulation vitesse des grappes
produite à la (Tm1) amplitude modifier le schéma des grappes configurer la régulation
puissance regulation automatique choix du régulateur
demandée surveiller les mécanismes
puissance neutronique (Wn)
réguler en grande commander les grappes de contrôle flux neutronique
amplitude surveiller les paramètres régulation pression primaire (p1)
modifier le schéma des grappes variation de température (∆T)
regulation automatique vitesse des grappes
surveiller les mécanismes
commander les vannes
réaliser le contournement vapeur surveiller les paramètres
Prendre en compte surveiller l'état de état globale
la chaufferie chaînes de mesure
l'environnement ∆P : pression primaire position des grappes de contrôle
∆T : température primaire disposition des moyens de refroidissement
surveiller les alarmes ∆N : niveau pressuriseur disposition des moyens de contrôle
∆We : puissance extraite
mesure du niveau GV
répondre à la demande
d'énergie mesure débit vapeur sortie
mesure ouverture vanne
régulation grand/petit débit
(1) maintenir le niveau GV réguler vanne principale
(2) Contrôler réguler le niveau GV agir sur les vannes alimentaires
réguler la vitesse de circulation
réguler vanne petit débit
l'évolution de adapter le débit à la puissance
la masse réguler les (3) surveiller les paramètres
régler la vitesse des pompes alimentaires
paramètres régler la vitesse des electro-pompe
d'eau du GV d'échange
agir sur les paramètres utiliser le circuit alimentaire auxiliaire
surveiller l'alimentation GV
refroidir le réacteur via le secondaire refroidir le réacteur via le secondaire
vérifier le
commander les turbo pompes
fonctionnement du
séparateur sécheur commander les moto pompes
démarrage de l'injection de sécurité

Réguler la contrôle des surveiller le niveau pressuriseur

agir sur la vanne de décharge
pression primaire niveaux pressuriseur régler le circuit de décharge régler les chaufferettes proportionnelles
agir sur le chauffage régler les chaufferettes tout ou rien
surveiller l'ébullition régler les chaufferettes proportionnelles
régler les chaufferettes tout ou rien
réguler la pression surveiller l'évolution des paramètres surveiller le courant d'alimentation
dans le pressuriseur régler la circulation surveiller la puissance consommée
agir sur le chauffage utiliser la douche pressuriseur
contrôler l'étanchéité soupapes contrôler les vannes de décharge
régler les vannes d'aspersion
Contrôler le Réguler le niveau surveiller l'évolution de la température
fluide primaire primaire surveiller les paramètres primaires
réguler le niveau mesurer la pression primaire
pressuriseur dériver l'eau primaire vers le CPD mesurer la pression pressuriseur
surveiller la marge de pressurisation
renouveler le fluide contrôler la qualité du fluide
modifier le régime de surveiller la circulation
circulation primaire modifier le mode de circulation
agir sur la pompe primaire
(2) Réguler la réguler la Tm1(4)
surveiller la pompe primaire dévier la circulation primaire
pression réguler la décharge
surveiller l'évolution du régime
secondaire (p2) à l'atmosphère

Figure IV.5 : Niveau conceptuel pour la supervision du réacteur

(déduit des articles issus de Techniques de l’Ingénieur, op. cit.)

Pour asservir la puissance, les objets manipulés par l’opérateur sont nombreux. En effet, dans un réacteur PWR à
recirculation naturelle, la variation de puissance secondaire engendre l’ouverture de la vanne alimentaire (V1 ou V2),
donc la variation du débit et de la pression secondaire, puis par voie de conséquence la modification des conditions
d’échanges dans le GV. Les principaux paramètres d’échange sont la pression, le niveau d’eau et la température.

La pression secondaire résulte de la température moyenne primaire ; elle est donc indirectement régulée par les
grappes de contrôle ou par le contournement vapeur. Le niveau d’eau dans le GV est régulé par action sur des vannes
alimentaires et par le réglage de la circulation de l’eau avec deux turbopompes. De plus, l’opérateur en relation
permanente avec l’environnement (propulsion, consommation), doit se préserver une marge de manœuvre suffisante
pour répondre à toute variation de puissance, surveiller la fatigue des composants et préserver l’intégrité de la
chaufferie.

b. Les opérations sur les objets, leurs attributs et leurs relations

Les tâches composées ci-dessus sont en relation étroite entre elles, comme le montre l’arborescence de la figure
IV.5. La présentation sous la forme d’un arbre montre les relations directes entre tâches et sous-tâches. Mais en ce qui
79 Chapitre IV

concerne les attributs manipulés, une analyse plus détaillée de chacune des tâches est nécessaire (Fig. IV.6).

Contrôler l’évolution de la masse d’eau du GV

Relation = réguler le niveau GV, réguler les paramètres d’échange, vérifier le séparateur sécheur
paramètres primaires : puissance neutronique, Tm1 (tâche réguler Tm1)
paramètres secondaires : puissance électrique, vanne admission turbine, pression vapeur
Attribut = surface d’échange, dimension, niveau GV, température GV, pression GV, ∆T primaire-secondaire,
puissance d’échange

Réguler le niveau GV
Relation = maintenir le niveau GV, agir sur les vannes alimentaires, réguler la vitesse de circulation
Attribut = température nominale d’eau alimentaire, pression vapeur pleine charge, taux d’humidité sortie GV, débit
max. vapeur charge nulle, pression secondaire, débit vapeur

Réguler la température moyenne primaire

Relation = surveiller les paramètres
commande des grappes de contrôle, surveiller les paramètres de régulation, schéma des grappes, mécanismes
contournement vapeur (tâche réguler le niveau GV)
Attribut = pression de fonctionnement, ∆température eau primaire, débit boucle primaire, volume eau primaire,
puissance neutronique
Figure IV.6 : Les relations et attributs sur les tâches

L’analyse des tâches de l’opérateur met en évidence certaines relations entre tâches. Par exemple, pour assurer un
transfert correct de l’énergie du primaire au secondaire, il est nécessaire de contrôler les évolutions de la masse d’eau
dans l’objet générateur de vapeur. Cela est assuré par la sous-tâche réguler le niveau GV (1 sur la figure IV.5). De
plus, les trois tâches réguler la température moyenne primaire, contrôler l’évolution de la masse d’eau du GV et
réguler la pression secondaire sont étroitement liées (2 sur la figure IV.5). La sous-tâche réguler les paramètres
d’échange (3 sur la figure IV.5) nécessite à la fois la surveillance des paramètres primaires et secondaires, et la
régulation de la pression secondaire met en œuvre l’ensemble de la tâche réguler la température moyenne primaire (4
sur la figure IV.5).

En effet, la pression secondaire résulte de la température primaire ; elle est donc réglée indirectement par les
grappes de contrôle et le circuit de contournement (qui sont des éléments a priori en relation avec le circuit primaire).
Cela montre que la régulation des paramètres du secondaire est effectuée par l’intermédiaire du primaire et fait donc
partie des tâches de l’opérateur liées au primaire.

Cette relation doit apparaître sur l’interface de supervision. Les attributs manipulés seront donc les organes de
commande des circuits primaire et secondaire ainsi que certains paramètres mesurés (pression, température, niveau,
puissance), les grappes de contrôle, le circuit de contournement vapeur, les organes de régulation du circuit
alimentaire.

II.1.2. Situation du niveau CO nceptuel dans le cycle en V

Les informations qui concernent ce que doit proposer l’interface en terme de tâche et comment l’utilisateur doit
accomplir sa tâche, puis la validation de ce qui aura été conçu, correspondent au niveau conceptuel de l’interaction
homme-machine (fig. IV.7).

En effet, dans le cycle en V, l’étape de spécification fonctionnelle détaille les besoins en fonction du comportement
attendu de l’IHM, et fournit donc les spécifications des niveaux de décomposition. Ainsi, une première description des
procédures d’utilisation du système est fournie. Puis, lors de l’étape ascendante de validation en vis-à-vis, l’interface
sera validée en terme de conformité de l’activité réelle des utilisateurs avec la tâche prescrite (utilité de l’interface).

Après l’étude des concepts du système homme-machine, l’équipe de développement s’intéresse maintenant au
niveau sémantique du canevas COSÉSYL.
 Chapitre IV 80

Analyse des besoins, Exploitation Maintenance,

Conception préliminaire et Recette & validation
détaillée du système Intégration du système
CYCLE DE VIE DU LOGICIEL INTÉRACTIF
Que doit proposer
l'IHM ? Spécification fonctionnelle COnceptuel Validation
Comment doit faire Validation de
Évaluation IHM l'IHM intégré
l'OH pour a priori
accomplir sa tâche ?

Conception préliminaire Tests d'intégration

Conception détaillée Tests unitaires

Programmation Codage

Figure IV.7 : Niveau conceptuel du cycle de développement logiciel en V

II.2. La SÉ mantique de la tâche

Le niveau sémantique décrit l’accomplissement des tâches, identifiées au niveau conceptuel, en termes de
composants et d’actions sur ces composants. Un composant est un objet du système tel que l’utilisateur le perçoit et le
manipule au travers de l’interface, non pas toujours tel qu’il existe en réalité. Par exemple, la commande de manœuvre
des grappes de contrôle dans le cœur d’un réacteur nucléaire n’est pas représentée sur le pupitre, par son mécanisme
mécanique réel, mais plutôt par un commutateur, des boutons montée-descente, une manette ou une métaphore
comme un icône interactif…

II.2.1. Description du niveau sémantique

Pour chacune des tâches, le niveau sémantique définit, d’une part l’effet des commandes et actions de l’utilisateur
sur les objets décrits au niveau supérieur, et d’autre part la signification des retours du système (fonction, paramètres,
résultats, erreurs, retour informatif, effets marginaux, état final). Il s’agit donc de la signification des commandes liées
à la tâche. Les “objets” manipulés et les fonctions y sont définis, des modules apparaissent, ainsi que des liens entre
fonctions et modules.

La signification de ces commandes liées à la tâche décrit l’accomplissement des tâches par l’utilisateur sur le
système. Les procédures de l’opérateur et les fonctions du système sont donc définies en terme d’unités
fonctionnelles. Par exemple, lorsque l’opérateur commande une vanne, il le fait dans un but associé à une tâche
planifiée (assurer la circulation dans un circuit, pour diminuer la température, et donc la pression…). Au niveau
sémantique sera décrite la procédure de commande de la vanne (ouverture ou fermeture) et son rôle dans le circuit.
L’interface doit se charger de la répercussion de la commande à la fois sur le procédé (ouverture ou fermeture de la
vanne), et sur l’écran (fig. IV.8), en informant l’opérateur que son action a bien les conséquences souhaitées
(changement d’état du ou des éléments d’affichage concernés, circulation dans le circuit…).

Sur l’exemple de la figure IV.8, l’effet des commandes et des actions utilisateur sur la régulation du niveau dans le
générateur de vapeur concerne les opérations énumérées au niveau précédent. Par exemple, la demande de variation
de charge électrique agit directement sur l’organe d’admission turbine (réguler débit GV). Cette variation du débit de
vapeur implique immédiatement une variation de la pression secondaire et donc une modification des conditions
d’échanges (la régulation des paramètres du circuit primaire). En fonction de l’état du procédé (normal, dégradé),
l’opérateur devra suivre des procédures définies de régulation du niveau GV, et de variation de la puissance du
réacteur en utilisant ou non des modules automatiques de régulation : ouverture de la vanne d’alimentation, sélection
ou non du régulateur approprié, avec éventuellement une calibration du régulateur selon une procédure particulière.
81 Chapitre IV

effet des opérations sur le système accomplissement des tâches par l’utilisateur

variation We interaction des objets actions utilisateur sur procédure de

les paramètres régulation
manipulés
GV
commande vanne
admission GV
retours informatifs calibrer
régler Tm1 choix régulateur
variation pression
secondaire pression réguler
débit ……
modification des conditions d'échange réguler les
(pression, débit, température) paramètres d'échange
vitesse de
circulation
réguler le
niveau GV vannes (ouverte,
fermée, inconnu)

Figure IV.8 : Niveau sémantique de la tâche

De plus, avec les modules fonctionnels, sont définis les éléments manipulés par l’opérateur et par le système. Par
exemple, l’élaboration d’une consigne de position de la vanne alimentaire sera réalisée par un régulateur à partir des
mesures du débit vapeur, du débit eau et de la variation de niveau GV, alors que l’opérateur n’agira pas de manière
aussi cartésienne. Il faudra donc lui définir une procédure rigoureuse de régulation qui sera implantée dans l’interface.

La signification des retours du système consiste à décrire les résultats des actions de l’utilisateur sur les paramètres
nécessaires et manipulés. En plus des retours informatifs, les actions liées aux objets sont définies. Par exemple la
visualisation de l’état ouvert, fermé ou inconnu des vannes.

La description de l’application au niveau sémantique aboutit à la définition des différents modules, et propose une
première organisation ou architecture de l’IHM en sous-systèmes pour chacune des fonctions énumérées.

II.2.2. Situation du niveau SÉ mantique dans le cycle en V

Ce niveau est principalement concerné lors des deux étapes de conception préliminaire et de validation, en vis-à-
vis dans le cycle en V (fig. IV.9).

Analyse des besoins, Exploitation Maintenance,

Conception préliminaire et Recette & validation
détaillée du système Intégration du système
CYCLE DE VIE DU LOGICIEL INTÉRACTIF

Que doit proposer l'IHM ?

Spécification fonctionnelle COnceptuel Validation
Validation de
Comment doit faire l'OH Évaluation IHM l'IHM intégré
pour accomplir sa tâche ? a priori

Conception préliminaire SÉmantique Tests d'intégration Evaluation des

Définition des modules intégrés
composants de Évaluation modules dans l'interface
l'interface a priori globale

Conception détaillée Tests unitaires

Programmation Codage

Figure IV.9 : Niveau sémantique du cycle de développement logiciel en V

La conception préliminaire consiste à recenser l’ensemble des modules informatiques concrétisant les fonctions
 Chapitre IV 82

que doit remplir l’application, identifiés lors de la spécification fonctionnelle. Les “objets” et fonctions y sont définis.
La phase ascendante de test correspondante, consistera à évaluer l’intégration de ces modules dans l’interface globale.
Comme pour le niveau conceptuel précédent, la validation sera réalisée en regard de l’étape de conception
préliminaire (stratégie d’intégration, scénarios de tests).

Ces deux premiers niveaux (conceptuel et sémantique) restent dans le domaine du signifié ; par contre, les deux
suivants (syntaxique et lexical) permettent la traduction concrète de l’interaction et de ce qui sera visible sur
l’interface physique. En effet, le conceptuel se rapporte à la tâche à effectuer, et la sémantique des commandes de
l’utilisateur et des retours de la machine concerne le fonctionnement de l’interface. L’utilisation et l’apprentissage de
l’IHM sont ainsi facilités d’une part, en mettant en jeu les connaissances que l’utilisateur a de la tâche (en liaison avec
l’aspect conceptuel de l’application), et d’autre part, en facilitant la compréhension de son fonctionnement.

II.3. La définition SY ntaxique et la représentation L exicale du dialogue

Les niveaux syntaxique et lexical décrivent, pour chacune des actions, la structure du dialogue homme-machine
avec leurs commandes et effets selon le contexte.

II.3.1. Description du niveau SY ntaxique

Le niveau syntaxique a pour objectif de définir le dialogue homme-machine. Il met en œuvre les actions décrites
dans la définition sémantique de la tâche. Le dialogue est détaillé en explicitant les séquences d’entrées-sorties qui
représentent les procédures pour atteindre un objectif. La syntaxe exacte des fonctions énumérées dans les niveaux
supérieurs y est décrite, l’activité de l’utilisateur est définie par rapport à ces fonctions. Pour chacune des actions, la
fonction informatique appropriée et ses arguments sont décrits. Ce sont des règles de composition des séquences
d’entrées comprises et exécutables par l’interface. Elles concernent :

• la spécification syntaxique des commandes d’entrée et de sortie,

• la structuration du dialogue et de l’interaction avec les relations d’entrées et de sorties,

• le style général du dialogue et son contrôle, soit par la machine, soit par l’homme.

Le dialogue correspond à un échange d’information entre l’homme et la machine. Il est composé d’une transaction
faite par l’utilisateur qui cherche à réaliser un but au moyen des commandes du système, et d’une interaction réalisée
par l’application qui établit la relation entre l’entrée et la sortie appropriée. Une attention toute particulière doit être
apportée au retour d’information qui règle le comportement de l’utilisateur. En effet, c’est ce retour (ou non-retour)
qui sera interprété par l’utilisateur pour la réalisation de sa tâche. Celui-ci doit être immédiat, clair et concis.

Parmi les styles de communication, le dialogue objet-action —sélection d’un objet sur l’écran puis choix de
l’action à lui faire subir en pointant un item dans un menu déroulant— apparaît comme la base des interfaces
graphiques d’aujourd’hui, tout en intégrant l’ensemble des modes de dialogue courant (touches fonctions, menus,
manipulation directe…). Il donne le contrôle complet à l’utilisateur sans lui imposer l’apprentissage d’un langage de
commande, tout en le focalisant sur les objets de l’application. Il peut de plus être utilisé pour la conduite de
processus.

Pour l’opération de régulation du niveau d’eau GV, la syntaxe décrit comment agir au moyen de l’interface sur
l’ouverture des vannes du circuit eau-vapeur (illustré sur la figure IV.10).

Avec un dialogue objet-action, l’opérateur sélectionne la vanne, appelle un menu de commande ou de visualisation
de son état, sélectionne son ordre et le valide. L’interface doit faire les relations d’une part, entre la commande en
entrée de l’opérateur et la sortie vers le procédé, et d’autre part, l’entrée du procédé et la sortie sur l’interface (c’est-à-
dire l’affichage de l’évolution de l’état de fonctionnement de la vanne, et la modification physique de l’état de la
vanne). Pour la supervision d’un procédé continu, il faut aussi considérer le système comme étant interactif du côté
machine (évolution continue des paramètres, mesures par capteurs, régulation automatique), comme du côté homme
83 Chapitre IV

(actions de conduite de l’opérateur).

Déroulement des actions affichage de l'évolution de l'état

de contrôle-commande de fonctionnement de la vanne
du circuit eau-vapeur
affichage
menu de
commande
sélection de la sélection de l'ordre
validation ……
vanne sur l'IHM de commande
menu de
visualisation
d'état actions opérateur de modification
de l'état de la vanne
variables d'état
de la vanne
Monde physique ou sous-système de commande
sous-système de mesure
technologique
action automatique de
régulation de la vanne

V1

Figure IV.10 : Exemple de représentation syntaxique (ouverture d’une vanne, circuit eau-vapeur)

Remarquons encore que la syntaxe du langage d’interaction doit tenir compte des critères ergonomiques
s’appliquant à la syntaxe d’entrée comme à celle de sortie : la présentation des écrans, la structuration entre écrans et
les changements de contexte, les menus et leur hiérarchie, les retours informatifs, les contrôles d’entrées, les
messages, etc.

II.3.2. Description du niveau L exical

Le niveau lexical consiste à exprimer les informations en terme de dénomination, de représentation physique juste
avant le codage ; les choix sont liés aux aspects pragmatiques d’utilisation des dispositifs d’entrée-sortie. La
représentation lexicale détermine ce qui est immédiatement accessible par l’utilisateur : les éléments physiques
manipulés (entrée), les affichages (sortie). Elle renvoie à la sémantique des objets représentés et donc à l’interaction
homme-machine.

Le niveau Lexical rend donc compte des caractéristiques de surface (dénomination des commandes, attributs
graphiques) de l’interface, définit les éléments physiques manipulés (entrées), les affichages (sorties), et l’interaction
qui existe au moyen de ces éléments. C’est le choix de la symbolique utilisée pour représenter la vanne et les
commandes associées, son positionnement, son évolution pendant l’interaction, les périphériques de commande et
d’affichage (Fig. IV.11). La terminologie et les images mentales des utilisateurs doivent être prises en compte pour
concevoir les affichages, ainsi que les entrées-sorties. Aussi, le respect des critères ergonomiques est essentiel, car
directement visible par l’utilisateur.

(1) (2) (3) (4)

CS1 CS2 CS1 CS2 CS1 vanne CS2 CS1 vanne CS2
alimentaire alimentaire
Ouv.(mm)= 0 Ouv.(mm)= 0
Q (m3/h)= 0 Q (m3/h)= 0
PA1 PA2 PA1 PA2 PA1 R = … PA2 PA1 R = … PA2
Quitter Quitter

Sous système A Sous système A Sous système A Sous système A

Figure IV.11 : Exemple de représentation lexicale de la commande d’une vanne

 Chapitre IV 84

L’exemple de la figure IV.11 montre comment les quatre premières étapes de l’interaction pour la commande d’une
vanne d’un circuit peuvent être représentées au niveau lexical —la procédure a été définie au niveau syntaxique
supérieur. Une partie du circuit est dessinée selon une schématique normalisée, il comprend deux vannes et deux
pompes (1). Par un mode de dialogue action-effet, avec une boule roulante par exemple, l’opérateur positionne le
curseur sur l’élément à commander (2). Lorsque le curseur se trouve sur la vanne, un cadre l’entoure, montrant ainsi
qu’une opération interactive lui est associée. Si l’opérateur veut obtenir des informations, il actionne le bouton de
validation, une fenêtre de dialogue apparaît près de l’élément (3). L’opérateur sélectionne alors l’information à
modifier (4), de la même manière un cadre apparaît lorsqu’une opération est possible (incrémenter ou décrémenter
l’ouverture, modifier le régulateur), et ainsi de suite. Dans l’exemple présenté, les actions sont directement appliquées
sur le procédé sans validation intermédiaire, puis la fenêtre est fermée grâce au bouton “quitter”.

II.3.3. Situation des niveaux SY ntaxique et L exical dans le cycle en V

L’étape de conception détaillée concerne principalement la syntaxe de l’interaction car elle consiste à développer
les modules en termes d’unités fonctionnelles : procédures ou fonctions (fig. IV.12). Ensuite, les composants
élémentaires seront testés de manière unitaire lors de l’évaluation ascendante. Ainsi, la structure générale de
l’interaction homme-machine est décrite puis évaluée à ce niveau.

Analyse des besoins, Exploitation Maintenance,

Conception préliminaire et Recette & validation
détaillée du système Intégration du système
CYCLE DE VIE DU LOGICIEL INTÉRACTIF

Que doit proposer l'IHM ?

Spécification fonctionnelle COnceptuel Validation
Validation de
Comment doit faire l'OH Évaluation IHM l'IHM intégré
pour accomplir sa tâche ? a priori

Conception préliminaire SÉmantique Tests d'intégration Evaluation des

Définition des modules intégrés dans
Évaluation modules
composants de l'interface l'interface globale
a priori

Conception détaillée SYntaxique Tests unitaires

Conception en détail éléments Evaluation des
de chacun des Évaluation et composants
d'IHM
composants a priori Lexical

Programmation Codage

Figure IV.12 : Niveaux syntaxique et lexical du cycle de développement logiciel en V

Les actions physiques élémentaires nécessaires à la spécification des commandes sont aussi définies lors de ces
étapes, au niveau lexical. En effet, ce niveau d’abstraction constitue encore une spécification de ce que doit être
l’interaction homme-machine et pas encore tout à fait sa réalisation. Il décrit concrètement comment l’utilisateur et le
système interagissent en termes d’actions élémentaires. Cette définition aboutit à celle de Coutaz (90) : la
spécification des éléments syntaxiques d’entrée (manipulation par l’utilisateur) et de sortie (définition des affichages).

II.4. Conclusion sur le canevas théorique COSÉSYL

Le canevas théorique COSÉSYL proposé permet de décrire l’interface selon différents niveaux d’abstraction et va
impliquer une démarche de développement centrée sur l’homme. Cela répond bien au souci d’introduire les facteurs
humains dans le génie logiciel. En effet, le dialogue homme-machine peut être modélisé comme un langage, avec une
structure en couches passant du monde conceptuel et sémantique au monde perceptuel, pour se traduire finalement par
un échange physique. L’utilisateur a des buts à atteindre dans le monde réel. Pour les atteindre, il exécute des tâches
sous forme d’opérations s’exécutant sur les objets abstraits de l’interface.
85 Chapitre IV

Cette architecture donne un cadre à la conception et à l’évaluation de l’interaction homme-machine, et permet de

justifier les choix ergonomiques tout au long du développement de l’interface. L’utilisation d’un modèle d’architecture
de la classe des modèles Langage est principalement liée aux trois points suivants :

• Le modèle s’insère dans un cadre de pensée permettant une explication simple du principe de fonctionnement
des systèmes interactifs (Coutaz 90).

• Il permet un développement itératif des IHM. En effet, les aspects conceptuels, sémantiques, syntaxiques et
lexicaux introduisent une certaine modularité et rendent possible l’ajustement itératif de l’interface.

• Il n’introduit aucune hypothèse sur le matériel et sur la nature de l’application.

La figure IV.13 présente une synthèse des quatre niveaux du canevas COSÉSYL.

Le schéma COSÉSYL correspond à une approche structurée, descendante, analytique de l’interface homme-machine.
C’est la vision théorique du concepteur. A l’opposé, l’opérateur humain qui, comme utilisateur final est directement
concerné par la supervision lorsqu’il utilise l’interface, a une approche empirique, ascendante, synthétique. C’est à
partir du signifiant qu’il remonte au signifié.

Cette approche descendante du concepteur et celle ascendante de l’utilisateur met en relation les étapes du cycle en
V avec les niveaux du modèle COSÉSYL :

• au niveau COnceptuel sont rassemblées les informations qui concernent la tâche que doit accomplir l’utilisateur
au moyen de l’interface. En terme d’évaluation, cette couche concerne la propriété d’utilité de l’interface.

• au niveau SÉmantique sont décrites à la fois les commandes de l’opérateur sur le processus et les répercussions
du processus sur l’interface. L’évaluation peut commencer sur l’utilisabilité des modules d’interface.

• aux niveaux SYntaxique et Lexical, le dialogue homme-machine est complètement déterminé. Un grand
nombre de critères d’évaluation concernant la propriété d’utilisabilité peuvent être mis en œuvre.

En conservant cette vision en niveaux d’abstraction du cycle de développement, nous proposons une démarche
d’évaluation a priori des IHM. Cette proposition est basée sur (i) le principe de l’évaluation énoncé au chapitre I, (ii)
les méthodes et techniques associées aux trois approches d’évaluation proposées aux chapitres II et III, et (iii) le
canevas théorique retenu pour décrire l’interaction homme-machine. La partie suivante est consacrée à cette
démarche.
 Chapitre IV 86

Niveau COnceptuel

“Concerne le concept, l’idée conçue par l’esprit : organiser les perceptions et les connaissances” (Dictionnaire analogique
Larousse).
Identification et classement des concepts important de l’application : tâche globale, sous-tâche, tâche élémentaire.
Décrire la tâche de supervision du système et déduire ce dont l’utilisateur a besoin
• type d’objet manipulé par l’application et utile pour la tâche de l’utilisateur,
• relation entre les objets,
• opérations sur les objets et leurs attributs.

Niveau SÉmantique
“qui a trait au sens (contenu sémantique du mot), qui se rapporte à l’interprétation d’un système formel” (Dictionnaire
analogique Larousse).
Description précise des classes d’objets auxquelles l’utilisateur et le système font référence, des liens fonctionnels
d’entrée-sortie et des applications technologiques.
Définir les séquences d’événements sur le dispositif physique
—> Aspect fonctionnel de l’interaction homme-machine :
• effet des commandes et actions utilisateurs sur les objets conceptuels,
• signification des retours du système (fonction, paramètre, résultat, erreur, retour informatif…).
—> Signification des commandes liées à la tâche : accomplissement des tâches par l’utilisateur sur le système
• description des modules en terme d’unité fonctionnelle (procédures ou fonctions),
• modules de tâche et liens entre fonctions et modules,
• définition des objets manipulés et des actions liées aux objets,
• organisation ou architecture de l’IHM en sous-systèmes pour chacune des fonctions énumérées.

Niveau SYntaxique
“qui traite de la fonction et de la disposition des mots” (Dictionnaire analogique Larousse).
Détailler et structurer les entrées ou la disposition des items sur l’écran
—> Règles de composition des séquences d’entrée comprises et exécutables par l’interface :
• définition du dialogue homme-machine,
• représentation des procédures pour atteindre un objectif,
• syntaxe des fonctions énumérées au niveau supérieur (activité de l’utilisateur).
—> Dialogue :
• l’utilisateur cherche à réaliser un but au moyen des commandes du système,
• interaction réalisée par l’application qui établit la relation entre l’entrée et la sortie appropriée (feed-back).

Niveau Lexical
“qui concerne le lexique, le vocabulaire” (Dictionnaire analogique Larousse).
Ce qu’il est possible de créer à partir des dispositifs d’entrée-sortie : frappe au clavier, affichage, icône (vocabulaire).
Définir précisément les commandes et les attributs graphiques
(caractéristiques de surface)
—> Description des actions physiques :
• déterminer ce qui est immédiatement accessible par l’utilisateur : éléments physiques manipulés (entrée), et affichage
(sortie),
• description concrète de comment l’utilisateur et le système interagissent,
• actions élémentaires, exprimer les informations en terme de dénomination, de représentation physique.

Figure IV.13 : Synthèse des quatre niveaux du canevas COSÉSYL

87 Chapitre IV

III. P ROPOSITION DE LA DÉMARCHE D ’ ÉVALUATION A PRIORI

Le canevas COSÉSYL est un cadre dans lequel il a été possible de positionner les différentes étapes de
développement des IHM. Ce cadre permet également de structurer la démarche d’évaluation a priori que nous
proposons, et qui est expliquée ci-dessous.

III.1. Principe de la démarche d’évaluation a priori

Puisque la démarche a priori est située dans la phase descendante de spécification-conception du cycle en V, le
système à évaluer est à ce stade inexistant. La démarche, basée sur le principe énoncé au chapitre I, consiste alors à
construire une représentation de l’interaction homme-machine (fig. IV.14, phase 1). Celle-ci permet ensuite d’évaluer
l’utilité de l’interface future pour élaborer des modifications et effectuer un ajustement du modèle (fig. IV.14, phase
2). Puis, l’interaction homme-machine est évaluée en s’intéressant à la propriété d’utilisabilité (Fig. IV.14, phase 3).

En fonction de la phase, le rebouclage se fera soit directement sur l’interface à évaluer, soit sur la modélisation qui
en a été faite. De plus, les données fournies sont source d’informations pour enrichir la connaissance en évaluation.
Propriétés de l'évaluation
Données de bases
Techniques de recueil de données

Phase 1 Phase 2 Phase 3

SYSTÈME À ÉVALUER
Sous-système 1 niveau d'adéquation de
l'interface à répondre aux
Sous-système 2 besoins
(en cours de
PROCÉDÉ développement)
…… Modèle
Sous-système n observé Evaluation Evaluation de Interface
de l'utilité de l'utilisabilité validée
l'interface de l'interface
Utilité Utilisabilité
CONNAISSANCES Modèle de
EN ÉVALUATION l'évaluateur

Analyse, Elaboration
des modifications en
terme d'utilité
Analyse, Elaboration
des modifications en
terme d'utilisabilité

Figure IV.14 : Principe global de la démarche d’évaluation proposée

Au regard de ce principe global, la démarche d’évaluation a priori proposée est composée de trois phases notées
E1, E2 et E3 (Grislin et al. 95b), qui sont expliquées dans les paragraphes suivants :

E1 Modélisation a priori de l’interaction homme-machine. Nous verrons que cette phase qui consiste à décrire
l’interaction homme-machine constitue la plus grosse difficulté de la démarche.

E2 Évaluation a priori de l’utilité de l’interface future. Cette phase consiste à comparer les modèles construits
lors de l’étape E1 pour évaluer l’utilité de l’interface future —“l’interface future” correspond à une prédiction
de ce que sera l’interface à développer à partir de sa description.

E3 Évaluation a priori de l’utilisabilité de l’interface future. C’est lors de cette phase que la qualité de
l’interaction homme-machine est mesurée.

La figure IV.15 illustre l’enchaînement des trois phases au niveau de l’étape de spécification fonctionnelle de
l’interface. Lors des étapes de conception préliminaire et de conception détaillée, la démarche est appliquée de façon
similaire, seules les données mesurées ou les informations d’entrée des modèles utilisés pour l’évaluation changent à
 Chapitre IV 88

chaque niveau d’abstraction. Nous l’expliquons progressivement dans la suite du chapitre.

Étape de spécification fonctionnelle

Évaluation a priori de l'interaction H-M

Élaborer les Phase E1 Phase E2 Phase E3
spécifications Modélisation
a priori de Évaluation Évaluation de
l'interaction de l'utilité de l'utilisabilité de
spécifications homme-machine l'interface l'interface

ajustement des spécifications

spécifications fonctionnelles
validées pour l'étape suivante

Figure IV.15 : Démarche d’évaluation a priori (exemple de l’étape de spécification fonctionnelle)

A l’issue des deux dernières phases, un document de corrections est élaboré. Celui-ci doit regrouper les différentes
remarques formulées lors de l’évaluation a priori. Celles-ci constituent des recommandations en vue de re-spécifier ou
de re-concevoir l’IHM, suivant l’étape dans laquelle on se trouve.

La démarche est basée sur plusieurs croisements entre les classifications des techniques, les niveaux d’abstraction
du modèle COSÉSYL, le cycle en V et les phases spécifiques à l’évaluation a priori. Aussi, nous avons choisi de
présenter la démarche a priori phase par phase, telle qu’elle est appliquée chronologiquement lors du développement
de l’interface. Dans le chapitre suivant, celle-ci est appliquée sur un cas concret qui illustre son utilisation en détail.

III.2. Phase E1, Modélisation a priori de l’interaction homme-machine

Lors de la phase E1, la modélisation a priori concerne l’interaction homme-machine au niveau de l’étape
descendante de développement en cours, c’est-à-dire de la description :

• soit des concepts en termes de tâches spécifiées lors de l’étape de spécification fonctionnelle (niveau
COnceptuel),

• soit des modules en termes d’unités fonctionnelles relatives à l’interaction, définies lors de l’étape de
conception préliminaire (niveau SÉmantique),

• soit de la structure du dialogue de commande, des règles de composition des séquences d’entrée comprises et
exécutables par l’interface (niveau SYntaxique) et les actions physiques d’interaction homme-machine (niveau
Lexical) décrites lors de la conception détaillée.

L’évaluation doit être effectuée en parallèle à la spécification-conception de l’interface. Au sein de chaque étape de
développement, il est nécessaire d’une part, de décrire l’interaction homme-machine au moyen d’un formalisme
adapté, et d’autre part, de choisir la technique adaptée au recueil des données d’entrée du modèle (fig. IV.16). C’est la
construction du modèle observé et du modèle dit de l'évaluateur.

La phase E1 englobe donc la réalisation des deux descriptions de l’interaction homme-machine. D’un côté l’équipe
d’évaluation dispose d’une description de ce que sera l’interaction vue par les concepteurs, à partir des informations
fournies par l’étape en cours ; de l’autre, l’équipe réalise une analyse a priori de l’interaction homme-machine en
prenant explicitement en compte l’homme. En effet, comme nous l’avons souligné dans le chapitre I, il existe
différents points de vue de l’interface en fonction des intervenants sur le système et de leurs connaissances. Ainsi, le
modèle observé est plus centré sur la technique et le modèle de l’évaluateur sur l’homme. Bien sûr, aucun des deux
n’est parfait, l’objectif est d’arriver à un compromis pour développer une interface adaptée aux tâches à réaliser par le
système homme-machine.
89 Chapitre IV

Analyse des besoins,

Conception préliminaire
et détaillée du système Interaction homme-machine, Phase E1
vision du concepteur Orienté conception
Spécif. Modélisation Modèle
observé IHM / Procédé
fctelle a priori de
ou E2
Concepθ l'interaction Modèle de Orienté conception
analyse des besoins, CO IHM / Opérateur
prélim. l'évaluateur
ou analyse de la tâche, SÉ H-M (homme par rapport
spécification
Concepθ contraintes et objectifs, SY au processus)
conception de l'IHM
détaillée facteurs humains Interaction homme-machine,
L vision de l'évaluateur

CO Modèles CO Techniques
SÉ formels SÉ de recueil
SY prédictifs SY
L de tâche L

Figure IV.16 : Phase E1, Modélisation a priori de l’interaction homme-machine

Construction du modèle observé

Lors du développement d’applications interactives, une analyse du système homme-machine doit être réalisée,
c’est la démarche du concepteur. Par exemple, lors de l’étape de spécification fonctionnelle, l’objectif de l’équipe de
conception est de répondre à la question “Quelles fonctions doit assurer l’interface ?”, et ce, à partir des besoins
exprimés lors des étapes amont (analyse des besoins, conception préliminaire et détaillée du système). L’activité de
développement à ce niveau consiste donc à formaliser les besoins exprimés dans un document de spécification
fonctionnelle (pour les autres niveaux du cycle en V, voir la description des activités de développement dans l’annexe
A).

Dans le cadre de la démarche d’évaluation proposée, le premier objectif de la phase E1 est de modéliser a priori
l’interaction homme-machine à partir des informations issues de cette analyse, souvent orientée procédé, pour aboutir
au modèle observé. Mais le concepteur est dépendant de la méthode d’analyse employée : structuration de la
démarche, de son intuition des besoins et des capacités de l’utilisateur. De ce fait, l’analyse de la tâche par l’expert du
procédé technologique n’est pas forcément en accord avec les concepts de l’utilisateur.

C’est pourquoi pour chaque étape du développement, l’évaluateur doit adopter une démarche orientée homme —
voire “user centred design” de Norman (86).

Construction du modèle de l'évaluateur

Le modèle de l’évaluateur, point clé de l’évaluation, sera constitué de ce que doit respecter l’interface au niveau de
développement concerné en termes de besoins de l’utilisateur pour réaliser sa tâche. Nous proposons de guider la
construction de ce modèle par rapport aux quatre niveaux d’abstraction de COSÉSYL (Cf. figure de synthèse IV.13).
C’est à dire qu’il faudra analyser le cahier des charges du système en termes de besoins, contraintes et objectifs pour
la réalisation de la tâche de l’opérateur. Cette analyse a priori de l’interaction constitue le deuxième objectif de la
phase E1 : la description du modèle de l’évaluateur.

L’analyse de l’interaction homme-machine, nécessite de s’intéresser à la tâche de l’utilisateur qui est définie
comme : “un objectif à atteindre par l’utilisateur à l’aide du système interactif” (Normand 92). Une arborescence en
buts et sous-buts doit être utilisée pour construire une description concise de la structure de la tâche du point de vue de
l’utilisateur (Kieras et al. 85). Ce découpage présente un caractère plus constant que les résultats obtenus par d’autres
méthodes qui peuvent subir des changements au gré des personnes ou des machines. C’est pourquoi il nous paraît
nécessaire d’utiliser les modèles formels prédictifs pour décrire cette interaction.
 Chapitre IV 90

Ces modèles peuvent être utilisés à plusieurs niveaux du développement pour la modélisation a priori, selon leurs
spécificités. Comme nous l’avons vu au chapitre III, à chaque étape du développement, ils permettent de modéliser
l’interaction au niveau considéré. Pour choisir la méthode adapté au niveau considéré, nous avons positionné les
modèles formels prédictifs par rapport aux niveaux du canevas COSÉSYL. Cette classification les met aussi en rapport
avec les couches du cycle en V, définies dans la partie précédente (Grislin et al. 95a, et 95b). La figure IV.17, présente
cette première localisation, des techniques d’évaluation présentées dans les chapitres II et III.

Traces
Arbre des écrites du travail
causes
Recueil
Incidents de l'expertise
critiques
PHASE DESCENDANTE Questionnaires
DU CYCLE HTA Mouchard électronique Cognitive walkthroughs
GOMS-KLM Tactiques visuelles Groupe de discussion
niveau Enregistrement vidéo PrototypageExpertise humaine
DIANE Banc d'essaiGrille
finald'évaluation
Analyse des besoins, d'abstraction MAD Analyse des protocoles
ALG
Conception préliminaire SADT-Petri CLG
et détaillée du système TAG

Spécification fonctionnelle Conceptuel

Phase
E1 GOMSSADT

Conception préliminaire Sémantique manque de si expérience de l'utilisation

Phase ? méthodes de (site de référence)
E1 description

Conception détaillée Syntaxique

Phase et
E1 Lexical KLM Petri

Approches basées Approches basées sur Approches basées sur

sur une modélisation les utilisateurs une expertise

Figure IV.17 : Positionnement des techniques dans le canevas COSÉSYL,

pour l’évaluation a priori

Le positionnement proposé est visualisé par un point sur la figure qui indique que la méthode nous paraît adaptée
au niveau considéré. Notons que cette localisation des techniques peut être moins “binaire” et plus modulée dans les
divers niveaux ; cela constitue une de nos perspectives de recherche.

Notons que puisque l’on travaille a priori, si l’équipe d’évaluation intervient très tôt dans le développement, elle
peut élaborer tout de suite un modèle de l’évaluateur (en étroite collaboration avec le concepteur et l’utilisateur futur).
Ce modèle sera alors utilisé directement pour la conception de l’interface. Dans ce cas, la démarche proposée
s’apparente à une démarche de conception orientée homme, en intégrant une évaluation de l’utilité et de l’utilisabilité
parallèle au développement. Par contre, si l’on n’intervient que pour de l’évaluation des spécifications ou de la
conception, la démarche impose de refaire tout le travail d’analyse amont à l’étape en cours. C’est pourquoi il faut une
démarche de développement participative entre tous les intervenants impliqués dans le développement d’une
application interactive.

Après avoir choisi une méthode de description adaptée, les données d’entrées du modèle doivent être recueillies au
moyen de certaines méthodes et techniques de recueil basées sur les utilisateurs —sur un site de référence, si c’est
possible— ou sur une expertise (voir chapitre II). Ces techniques vont dépendre du type d’information et du niveau de
développement du système. En premier lieu, les informations recueillies lors de la conception proprement dite, vont
servir à la construction du modèle de l’interaction homme-machine (Cf. en première partie de l’annexe A, la
localisation des méthodes de conception dans le cycle en V). En second lieu, nous proposons aussi d’intégrer les
approches empiriques dans le cycle en V. Ces méthodes contribuent à enrichir le modèle, mais elles permettent surtout
d’évaluer (plus ou moins directement) les spécifications, la conception préliminaire et la conception détaillée de
l’interface.
91 Chapitre IV

III.3. Phase E2, Évaluation a priori de l’utilité de l’interface

La phase E2 concerne l’évaluation de l’utilité de l’interface à partir des modèles de description de l’interaction
homme-machine issus de la phase précédente (fig. IV.18). C’est lors de cette phase que nous cherchons à appliquer le
principe énoncé par Senach (90) : “Toute évaluation consiste à comparer un modèle de l’objet évalué à un modèle de
référence permettant d’établir des conclusions.” Selon les hypothèses de notre démarche, ces modèles doivent être à
l’image de l’interaction homme-machine du produit final, leur analyse doit permettre d’estimer l’utilité (phase E2)
puis la difficulté d’utilisation de l’interface, l’utilisabilité (phase E3, nous y viendrons au §III.4).

Phase E2
E1
Modèle
observé Évaluation de
Modèle de
l'utilité de E3
Modèle de
l'interface l'interaction
l'évaluateur
Analyse, Elaboration
des modifications

Modèles adéquation de la tâche,

CO
formels répartition du travail,
SÉ f performance du système,
SY prédictifs
L de tâche sécurité, qualité

Figure IV.18 : Phase E2, Évaluation a priori de l’utilité de l’interface

Comme la démarche est appliquée de façon chronologique tout au long du cycle de développement, celle-ci
s’intéresse successivement aux différentes étapes descendantes de spécification-conception et donc aux quatre niveaux
de COSÉSYL (conceptuel, sémantique, syntaxique et lexical) identifiés comme des couches d’abstraction. La figure
IV.18, présente le principe de la phase E2 : le modèle observé obtenu, lors de la phase E1, doit être comparé au
modèle de l'évaluateur pour évaluer l’utilité de l’interface et construire le modèle de l’interaction homme-machine.
L’analyse des résultats de cette comparaison doit permettre ensuite d’ajuster les éléments issus du modèle observé et
de celui de l'évaluateur. Le chapitre V présentera un exemple d’application qui montrera la différence entre ces
modèles.

L’évaluation consiste alors à vérifier si ce qui a été spécifié ou conçu correspond bien à ce qui a été demandé,
notamment en ce qui concerne la propriété d’utilité définie au chapitre I. Rappelons que l’utilité concerne la prise en
compte de la capacité fonctionnelle de la future interface à permettre à l’utilisateur d’atteindre ses objectifs, en termes
d’adéquation à la tâche, de répartition du travail, de performance, de sécurité et de qualité.

Lors de la démarche de développement, l’évaluation doit aussi être effectuée à l’aide de critères ergonomiques liés
à l’utilisabilité du système interactif. C’est l’objet de la phase E3.

III.4. Phase E3, Évaluation a priori de l’utilisabilité de l’interface

III.4.1. Principe
Évaluer l’utilisabilité de l’interface avant qu’elle ne soit réalisée doit permettre de vérifier si les solutions
envisagés sont en accord avec les critères ergonomiques (Cf. chapitre I, §III.2). S’il y a désaccord, on peut s’attendre à
ce que l’interface qui sera conçue engendre inévitablement des erreurs ou des problèmes pour l’utilisateur. Il vaut
mieux dans ce cas modifier ou adapter le plus rapidement possible les choix de spécification ou de conception. C’est
l’objet de l’ajustement réalisé par la phase E3 (fig. IV.19).
 Chapitre IV 92

ajustement

Spécification Phase E3
Vision du ou conception E1
concepteur (concepteur) Modèle E2 Interaction
observé
Évaluation de homme-machine
l'utilisabilité validée pour
Vision de CO Modèle de l'étape suivante
l'évaluateur
Spécification SÉ l'évaluateur de l'interface
ou conception SY
(évaluateur)
L

CO Positionnement
SÉ des critères
SY ergonomiques
L

Figure IV.19 : Phase E3, Évaluation a priori de l’utilisabilité de l’interface

Les critères recensés dans le premier chapitre (tableau I.1) sont utilisés lors de cette phase pour prédire
l’utilisabilité de la future interface. Il s’agit donc de les faire “apparaître” dans le modèle de l’interaction obtenu et de
les estimer. Ceux-ci concernent divers aspects de l’interface à des niveaux d’abstraction différents (par exemple,
l’organisation en tâches de l’IHM ne se situe pas au même niveau que le choix de la couleur d’un composant d’une
vue). C’est pourquoi nous proposons une première classification des critères ergonomiques par rapport aux canevas
COSÉSYL.

III.4.2. Les critères ergonomiques d’évaluation de l’utilisabilité

dans la démarche a priori
La figure IV.20 illustre une première classification des critères ergonomiques selon les étapes de développement du
cycle de vie en V d’une IHM. Le principe du classement a été de différencier les notions prises en compte dans la
définition de chaque critère (Grislin et al. 93). Puis suivant le niveau d’abstraction de ces notions, les critères sont
répertoriés selon les niveaux de COSÉSYL.

Le Guidage
Incitation (1)
PHASE DESCENDANTE Groupement par localisation (2) La gestion des erreurs
Groupement par Laformat (3) de travail L’adaptabilitéProtection contreHomogénéité
les erreurset(13)
Consistance (16)
DU CYCLE charge Signification
Retour informatifConcision
immédiat (6)
(4)
Le contrôleFlexibilité Qualité des messages
explicite (11) (14) des codes (17)
Clarté (5) Actions(7)
explicites (9) deCorrection
Expérience l’utilisateur Compatibilité
des erreurs (15) (18)
(12)
Actions minimales
niveau Contrôle
Charge mentale (8) utilisateur (10)
d'abstraction
Analyse des besoins,
Conception préliminaire
et détaillée du système

Spécification fonctionnelle Conceptuel

Phase
E3

Conception préliminaire Sémantique

Phase
E3

Conception détaillée Syntaxique

Phase et
E3 Lexical

Figure IV.20 : critères ergonomiques d’évaluation dans canevas COSÉSYL, pour l’évaluation a priori (première proposition)
93 Chapitre IV

Les critères concernent l’interface à différents niveaux d’abstraction ; ils ne sont pas à prendre en compte dans une
même étape du cycle de développement. Par exemple, lors des spécifications fonctionnelles, les jugements portent
davantage sur l’organisation et les fonctionnalités de l’interface que sur les couleurs des composants (qui ne sont
d’ailleurs le plus souvent pas encore définies). De plus, un critère peut avoir une définition trop générale, et donc être
pris en compte à différentes étapes, mais pour des raisons diverses.

Par exemple, à l’étape de spécification fonctionnelle, l’utilisateur peut avoir besoin d’une aide sur ce qu’il peut
faire avec l’interface (en termes de tâches), tandis qu’à l’étape de conception préliminaire, les aides porteront sur
l’utilité de telle ou telle autre fonction proposée pour accomplir une tâche donnée. Ainsi, après avoir modélisé
l’interaction homme-machine dans la phase E2, l’évaluation sera effectuée à partir des critères cités. L’évaluateur doit
pouvoir évaluer l’interface en estimant tous les critères pris en considération au sein de l’étape de développement
envisagée.

Sur la figure IV.20, on s’aperçoit que lorsqu’un critère est concerné par un niveau d’abstraction, il continue à l’être
dans les niveaux inférieurs. Par exemple, la flexibilité de l’interface qui concerne les moyens mis à la disposition des
utilisateurs pour personnaliser l’interface, correspond, en fonction du niveau de COSÉSYL :

• au nombre de façons différentes pour atteindre un objectif donné, au niveau COnceptuel,

• aux différentes possibilités d’action sur les composants du système, au niveau SÉmantique,

• aux variations offertes par l’interface dans la structure du dialogue de commande, au niveau SYntaxique,

• aux possibilités d’actions physiques, au niveau Lexical.

Les motivations de ce positionnement sont diverses. En premier lieu, il s’agit d’aider l’équipe de développement
dans le choix des critères d’évaluation adaptés à l’étape en cours. Les recommandations ergonomiques doivent
faciliter la “notation” de l’interface selon différents niveaux d’abstraction. En effet, l’aide, l’organisation des menus,
la charge de travail, les affichages, la qualité de messages, etc, ne sont pas à prendre en compte dans une même étape
du cycle de développement. En second lieu, il se peut qu’un critère ergonomique intervienne de manière différente à
plusieurs étapes de conception.

Les différents critères étant localisés tout au long du cycle de développement, l’équipe d’évaluation doit pouvoir,
en se basant sur le modèle de l’interaction (issu des phases précédentes), évaluer l’interface en estimant tous les
critères pris en considération au sein de l’étape en cours. Dans ce but, il convient d’utiliser des métriques d’estimation
rigoureuses. Le principe de ces méthodes d’estimation sera décrit dans le chapitre V, sur une application.

III.5. Synthèse de la démarche proposée pour l’évaluation a priori

L’évaluation a priori porte principalement sur l’évaluation de l’interface vis-à-vis de son utilité par rapport aux
besoins qui ont été définis et de son utilisabilité en regard de critères ergonomiques recensés. Elle est composée de
trois phases principales :

E1 Modélisation a priori de l’interaction homme-machine.

E2 Évaluation a priori de l’utilité de l’interface future.

E3 Évaluation a priori de l’utilisabilité de l’interface future.

A partir, soit des spécifications de l’interaction homme-machine, soit de la définition ou de la conception détaillée
des composants, il s’agit de “mesurer”, de critiquer et surtout de proposer des améliorations de l’IHM le plus tôt
possible lors du développement. Cette mesure consiste à construire une représentation de ce que sera l’interaction
homme-machine, en s’aidant d’un modèle de l'évaluateur basé sur les besoins spécifiques à l’application visée, et les
données plus générales que l’on trouve dans le modèle du concepteur.
 Chapitre IV 94

Comme la démarche que nous proposons se déroule tout au long des étapes de spécification et de conception de
l’IHM, les phases E1, E2 et E3 seront effectuées à chacune des étapes descendantes du cycle en V (sur la figure IV.21,
la première étape est détaillée). Leur objectif est d’obtenir un modèle a priori de l’interaction homme-machine
évaluée, c’est-à-dire à la fois compatible avec les besoins de l’utilisateur (utilité) et respectant les critères
ergonomiques (utilisabilité). L’interface doit, en outre, respecter les contraintes particulières de l’application.
Analyse des besoins,
Conception préliminaire et Niveau
détaillée du système d'abstraction

Evaluation a priori de l'interaction homme-machine

Spécification
Phase E1 Phase E2 Phase E3 COnceptuel
ou conception Modèle
Vision du (concepteur) Modélisation
concepteur observé Évaluation de Modèle Évaluation de
a priori de A PRIORI de l'utilisabilité de
l'utilité de
Spécification CO l'interaction l'interface l'interaction l'interface
Modèle de
ou SÉ H-M l'évaluateur
conception SY
(évaluateur) L
Vision de Outil de modélisation Critères d'évaluation
l'évaluateur adapté concernés
Interaction homme-machine
validée pour l'étape suivante

informations utilisables lors dela phase ascendante

Conception préliminaired'évaluation-validation
Évaluation a priori SÉmantique du développement de l'IHM
E1 E2 E3

Conception détaillée SYntaxique

Évaluation a priori et
E1 E2 E3 Lexical

Programmation Codage

Figure IV.21 : Synthèse de la démarche d’évaluation a priori des IHM

Lors de la phase E2, la comparaison de la représentation de l’interaction observée et de celle de l'évaluateur doit
permettre de construire un modèle de l’interaction homme-machine au niveau concerné. Celui-ci sera utilisé d’une
part lors de l’étape descendante suivante et d’autre part pour les tests-validations lors de l’étape ascendante en vis-à-
vis.

Notons que dans notre démarche d’évaluation a priori, la modélisation de l’interaction homme-machine peut être
très proche de celle utilisée pour la conception proprement dite. En effet, lors de la phase E1, les données d’entrée des
modèles sont issues des étapes de spécification-conception. Ainsi, lorsque le modèle de l’évaluateur tend vers des
alternatives de conception, l’évaluation s’apparente à de la conception pure. Pour le développement d’une interface
inexistante, la phase E1 peut donc constituer une phase de conception plutôt que d’évaluation. Cela rejoint le point
fondamental que nous avons souligné en conclusion du premier chapitre en énonçant l’évaluation comme “[…] un
processus parallèle à la conception” (Grislin et al. 96).

Lorsque l’on poursuit le cycle de développement, l’étape suivante est celle de l’implémentation-codage. Lors de
notre travail de recherche, nous ne nous sommes pas intéressés à l’évaluation dans cette étape, l’évaluation dans ce cas
consisterait à des tests de qualité du logiciel (Forse 89 ; Meskens 91). L’évaluation peut ensuite continuer selon une
démarche similaire une fois l’interface réalisée. Dans ce cas, le principe de notre proposition change quelque peu
puisque ce n’est plus l’interaction homme-machine probable —définie a priori— qui est évaluée, mais l’interface
effectivement réalisée et qui sera utilisée. Ce second aspect de l’évaluation, a posteriori, constitue une de nos
perspectives de recherche (cf. chapitre V ; Grislin et al. 95b ; Kolski et Grislin 95).
95 Chapitre IV

C ONCLUSION SUR LA DÉMARCHE D ’ ÉVALUATION PROPOSÉE

Dans un but de conception-évaluation, nous avons cherché à classer les trois approches d’évaluation présentées
dans les chapitres précédents par rapport aux niveaux conceptuel, sémantique, syntaxique et lexical. Ces différentes
couches, mises en relation avec le cycle de développement représentent l’architecture d’un système interactif : le
canevas COSÉSYL. Nous avons montré que la description des objets, de leurs attributs, de leurs relations, des
opérations portant sur ces objets constituent le niveau conceptuel de l’interaction. La description sémantique du
langage homme-machine, comme dans le langage humain, est supportée par une grammaire avec ses niveaux
syntaxiques (dialogue, phrase) et lexicaux (symboles signifiants élémentaires, mots), nous acheminant peu à peu vers
l’interface physique.

Le positionnement des méthodes et techniques parmi les quatre niveaux nous a permis de situer l’évaluation tout
au long du cycle de développement en V des systèmes interactifs. Cette classification des méthodes et techniques
utilisables pour les systèmes interactifs, découle de l’étude des techniques d’évaluation présentée dans le chapitre
précédent. Il est alors possible de choisir, pour une étape donnée, l’approche correspondant le mieux à l’évaluation en
cours.

L’évaluation doit être réalisée à chaque étape du cycle de vie. Les techniques employées sont issues des approches
empiriques, expertes et des modèles formels prédictifs de l’approche analytique. Aussi, une première proposition de
démarche d’évaluation a priori a été proposée ; elle intervient dans la phase descendante du cycle de développement
de l’interface homme-machine c’est-à-dire au cours de sa spécification-conception.

L’étude et la proposition d’une démarche d’aide à l’évaluation ne suffisent à en garantir ni l’efficacité, ni

l’utilisation6. Pour cela une étape de validation dans des conditions les plus proches possibles des conditions
d’utilisation réelle est indispensable. C’est pourquoi le chapitre suivant est consacré à la mise en œuvre de la
démarche d’évaluation a priori sur une application de supervision simulée en laboratoire.

6
Soit l’utilité et l’utilisabilité de la démarche proposée.
 Chapitre V 98

Chapitre V

Mise en œuvre et perspectives

de la démarche d’évaluation a priori des Interfaces Homme-
Machine
(Application sur un système complexe de supervision)

INTRODUCTION

I. MISE EN ŒUVRE DE LA DÉMARCHE POUR ÉVALUER A PRIORI UNE

IHM DE SUPERVISION

II. ÉVALUATION LORS DE L’ÉTAPE DE SPÉCIFICATION FONCTIONNELLE

III. ÉVALUATION LORS DE L’ÉTAPE DE CONCEPTION PRÉLIMINAIRE

IV. BILAN ET PERSPECTIVES DE RECHERCHE

CONCLUSION DE LA MISE EN ŒUVRE ET DES PERSPECTIVES DE LA

DÉMARCHE
 Chapitre V 99

Le chapitre précédent consacré à la présentation de la démarche d’évaluation, ne nous a pas permis d’en observer
sa mise en œuvre. Une étude plus approfondie dans un contexte proche de la réalité doit maintenant permettre de
garantir la validité des principes introduits, notamment les premières propositions de positionnement des méthodes et
des critères d’évaluation.

Notre objectif, introduit dès le début de ce mémoire est de montrer la possibilité d’évaluer une IHM dès le début de
son développement. C’est pourquoi nous présentons une première application de la démarche d’évaluation a priori, à
différentes étapes de la spécification-conception d’une imagerie industrielle. Il sera ainsi possible de mettre en
évidence l’ensemble des problèmes rencontrés ; certains feront d’ailleurs l’objet de perspectives de recherche.

Rappelons brièvement les trois phases principales E1, E2 et E3 détaillées dans le chapitre IV :

E1 Modélisation a priori de l’interaction homme-machine : construction du modèle orienté processus (vision du

concepteur) et de celui orienté homme (vision de l’évaluateur) 1, à partir des informations issues de l’étape de
développement en cours. Les méthodes utilisées ont été présentées et discutées dans le chapitre III.

E2 Évaluation a priori de l’utilité de l’interface : évaluation de l’utilité à partir de la comparaison des deux
modèles de l’étape E1. Cette phase aboutit à un premier compromis, préconisé par l’évaluateur, qui décrit
l’interaction homme-machine.

E3 Évaluation de l’utilisabilité de l’interface : mesure de la qualité de l’interaction homme-machine. Cette phase

est basée sur l’estimation des critères ergonomiques concernés par l’étape en cours (voir notre première
localisation dans le chapitre IV).

A l’issue de ces phases, les différentes remarques sont regroupées et constituent des recommandations en vue
de re-spécifier ou de re-concevoir l’IHM.

Cette première mise en œuvre concerne l’évaluation d’une interface de supervision d’un procédé industriel “fictif”.
Le développement de celle-ci est fondé sur le cycle en V et a abouti à une première version papier de l’IHM ;
l’évaluation utilise des formalismes du type prédictif de tâche et linguistique. Notre objectif est de vérifier la validité
et la faisabilité des propositions formulées dans le chapitre précédent. Certains types de modèles analytiques y sont
donc utilisés concrètement pour décrire l’interaction homme-machine dans le but de valider… leur utilité et leur
utilisabilité pour l’évaluation a priori.

Dans un souci de clarté dans la présentation, certains détails sont reportés en annexes B, C, D, ce qui permet de se
focaliser uniquement sur l’application de la démarche d’évaluation.

I. M ISE
EN ŒUVRE DE LA DÉMARCHE POUR É VALUER A PRIORI UNE IHM DE
SUPERVISION

I.1. Principe de fonctionnement du procédé étudié

Le système à évaluer est une interface de supervision d’une usine de fabrication de mélange. La supervision
consiste principalement à contrôler et à commander treize stations de mélange

1
Comme nous l’avons déjà souligné au début de ce mémoire, nous employons les termes concepteur et évaluateur pour
désigner l’équipe de conception et l’équipe d’évaluation, tous deux ayant des éléments communs et faisant partie de
l’équipe de développement (voir chapitre I, § III.4. Les intervenants de l’évaluation).
 Chapitre V 100

comportant un ensemble d’éléments couramment rencontrés en situation réelle (convoyeurs, moteurs, vannes,
containers, actionneurs, capteurs…). La figure V.1 présente une station schématisée, avec son fonctionnement. Il y a
quatre types de stations différentes, présentés en détail en annexe B.

6 Principe de fonctionnement :
nettoyage auto
6 • Stockage de la matière première dans des trémies (1),
nettoyage auto
(1) remplissage assuré par une équipe de manutention sous
trémie 1

6
l’autorité de l’opérateur de supervision (se trouvant
trémie 2 nettoyage auto seul dans une salle de contrôle). Il y a 6 types différents
(2)
V1 6 de matières premières. Le mélange final peut être
V2
nettoyage auto composé au minimum de 2 produits différents, et au
bascule 1 trémie 3
maximum de 6 (selon la recette), avec toujours
(3) V3 bascule 2
l’addition d’un solvant en fin de fabrication.
trémie 4
V4
• Pesage sur bascule électronique (2) de la quantité de
BR
(4) bascule 3
matière première nécessaire au mélange, géré par le
BR calculateur.
bascule 4
Broyeur • Réseau de convoyeur (3), plusieurs km, qui achemine
BR la matière première jusqu’au mélangeur en passant ou
non par un broyeur.
BR BR
• Broyeur (4) pour réduire en poudre certains types de
solvant granulés, réglable manuellement par l’équipe de
Vs (5) manutention sous l’autorité de l’opérateur de
P Moteur supervision.
eau froide
vers chaudière
(6)
• Mélange dans la cuve du mélangeur (5) pendant un
T Mélangeur T temps t, à une température constante, avec addition
d’une quantité déterminée de solvant.
eau chaude
cuve vers module suivant • Système de régulation de température (6) composé
d’une circulation d’eau chaude ou froide autour de la
eau chaude
cuve. Ce circuit de chauffage est groupé par stations,
Vc ainsi l’eau utilisée dans une cellule est réutilisée dans la
suivante.
• Récupération du produit final dans des containers
container
(CPF)
container
(CPF) Station de mélange (CPF) par l’équipe de manutention.
3éme génération (G3A)

Figure V.1 : Schéma d’une station de mélange et principe de fonctionnement

Ce procédé est fictif et a été défini au LAMIH dans le but de tester la démarche, dans le cadre d’un projet de
laboratoire (Jouglet et al. 94). Le système de fabrication est en fait similaire à celui existant dans une entreprise de la
région (station de mélange de sables pour la fabrication du verre) ; ainsi la validité de nos propositions technologiques
est vérifiée. La technologie utilisée pour les capteurs de mesures spécifiques est celle existant sur le marché (choix,
faisabilité, fiabilité, précision). L’objectif du projet consistait pour deux concepteurs, à analyser le fonctionnement du
système homme-machine pour aboutir à une maquette de l’interface de supervision utilisée par un opérateur seul dans
une salle de contrôle. La démarche de développement suivie respecte celle préconisée par le cycle en V. L’équipe de
conception était composée de deux étudiants de niveau ingénieur-maître, l’un d’eux considéré comme débutant —bien
que déjà sensibilisé à l’importance des facteurs humains— et l’autre ayant déjà conçu des synoptiques dans le cadre
d’un stage industriel.

I.2. Mise en œuvre de la démarche

La démarche d’évaluation a priori a été appliquée étape par étape parallèlement au développement (fig. V.2). Nous
l’avons tout d’abord utilisée pour évaluer les spécifications fonctionnelles, puis lors de l’étape de conception
préliminaire pour évaluer les éléments de l’interface. L’évaluation lors de la conception détaillée n’a pas été réalisée
car l’interface n’a pas été développée à ce niveau de détail. Nous verrons toutefois que certains aspects syntaxiques de
l’interaction ont été abordés dans les niveaux supérieurs.
 Chapitre V 101

Analyse du procédé
en fonctionnement
normal et anormal

EVALUATION A PRIORI
E1
Spécification E2
fonctionnelle OBS utilité E3
utilisabilité
EVAL
Spécification - conception d'une IHM

E1
Conception E2
préliminaire OBS E3
utilité
utilisabilité
EVAL

Figure V.2 : Mise en œuvre de la démarche d’évaluation a priori

Notre intervention lors du développement de l’IHM fait l’objet de la première mise en œuvre de la démarche
d’évaluation a priori. Pour cela, l’équipe d’évaluation était composée de deux chercheurs en communication homme-
machine : l’un informaticien très sensibilisé aux méthodes d’évaluation des IHM dans le cadre de son DEA, et l’autre,
—moi-même— automaticien travaillant sur l’évaluation des IHM depuis plusieurs années (évaluation de la charge de
travail du conducteur automobile (Grislin 91 ; Riera et Grislin 94), analyse de l’activité des opérateurs de conduite de
réacteur nucléaire (Grislin et al. 92a, 92b), étude des méthodes et techniques d’évaluation (Grislin et al. 93, 95a, 95b,
à paraître).

Nous avons pris pour hypothèse que les données disponibles étaient essentiellement celles fournies par les
concepteurs en fonction de l’étape en cours (accès aux documents et rapports des concepteurs, et mise au point lors de
réunions périodiques). Cette “simulation” du développement de l’IHM de supervision s’est déroulée au LAMIH sur
une période de cinq mois.

II. É VALUATION LORS DE L’ ÉTAPE DE SPÉCIFICATION FONCTIONNELLE

Lors de l’étape de spécification fonctionnelle, l’IHM n’est pas encore réalisée. Les informations disponibles pour
l’évaluation sont uniquement celles issues des analyses menées par les concepteurs en amont (analyse du
fonctionnement normal et anormal, définition des besoins), et les spécifications concernent l’interaction homme-
machine générée à cette étape (niveau COnceptuel de COSÉSYL).

II.1. Phase E1 : modélisation a priori de l’interaction homme-machine

(spécifiée)

Comme nous l’avons vu au chapitre IV, la phase E1 consiste à modéliser ce que sera l’interaction homme-machine
au niveau conceptuel en identifiant et en classant les concepts importants de l’application : les buts et les tâches de
l’utilisateur. L’objectif est d’identifier le plus tôt possible les problèmes qui risquent d’être rencontrés lors de
l’exécution de la tâche prescrite. La description a priori de l’interaction sera ensuite réalisée à partir d’une synthèse
des modèles observé (OBS) et de l’évaluateur (ÉVAL) (fig. V.3).

Le modèle OBS est directement issu des spécifications fonctionnelles et peut être construit en collaboration avec le
concepteur ou par le concepteur lui-même. Alors que le modèle ÉVAL est construit par l’équipe d’évaluation à partir
des analyses du cahier des charges, des besoins, des contraintes et des objectifs du futur système. Bien entendu et
comme nous l’avons souligné dans le premier chapitre, dans un contexte réel, l’évaluation pendant le développement
doit être réalisée de manière participative.
 Chapitre V 102

Analyse du procédé
en fonctionnement
normal et anormal EVALUATION A PRIORI
Spécification E1
OBS E2 E3
fonctionnelle utilité
cahier des charges CO utilisabilité
EVAL
analyse des besoins, SÉ
contraintes et SY
objectifs L

Figure V.3 : Étape de spécification fonctionnelle, phase E1

Ces premières modélisations sont en fait principalement consacrées à la tâche. En effet, c’est au niveau conceptuel
qu’est déterminée la structure des tâches que l’utilisateur a à effectuer avec l’aide de l’interface. Sur la figure IV.17,
qui positionne les techniques dans le canevas COSÉSYL (cf. chapitre IV), nous proposons d’utiliser les modèles formels
prédictifs pour décrire la tâche de l’opérateur. Rappelons que ces méthodes sont utilisées ici car elles ont l’avantage de
fournir une décomposition hiérarchique graphique, claire et explicite.

Dans un but d’illustration, nous détaillons ci-dessous un exemple d’utilisation d’un modèle hiérarchique de tâche,
en l’occurrence HTA, pour construire le modèle OBServé d’une part, et le modèle de l’ÉVALuateur d’autre part.2

II.1.1. Exemple de modèle OBS ervé (lors des spécifications fonctionnelles)

Concernant la modélisation des tâches, l’équipe d’évaluation peut être confrontée à deux cas de figures :

(i) Dans le cas le moins fréquent dans l’industrie, les concepteurs effectuent une analyse de tâche suivie d’une
modélisation ; le modèle OBS correspond à cette description de la tâche de l’opérateur.

(ii) Dans le cas le plus fréquent, et c’est justement ce qui s’est passé ici, il n’y a pas eu d’analyse de tâche ; l’équipe
d’évaluation doit remédier à ce manque en effectuant une analyse de la tâche à l’aide des informations
disponibles, et donc construire OBS (en plus de ÉVAL).

Les informations collectées par l’équipe d’évaluation, pour construire cette arborescence sont celles utilisées
pendant l’analyse et proviennent de différentes sources. Dans notre cas, ces données sur la tâche de l’opérateur sont
principalement issues de l’analyse du fonctionnement du procédé. Cette analyse est issue d’une description à l’aide de
quatre méthodes préconisées et détaillées par Fadier (90) : les diagrammes blocs (DB) et les graphes de fluence (GF),
pour le fonctionnement normal ; puis l’Analyse des Modes de Défaillance et de leurs Effets (AMDE) et les arbres de
défaillances (AD), pour le fonctionnement anormal (exemple en figure V.4). Rappelons que cette étude a été réalisée
par l’équipe de conception et a contribué à la définition des besoins vis-à-vis de l’interface, selon donc le point de vue
des concepteurs. Elle correspond à la première étape de la démarche en U de conception-évaluation d’un système
homme-machine (présentée au chapitre I).

Ces méthodes ont permis aux concepteurs de décrire le système, de comprendre son fonctionnement normal et
dégradé, de les modéliser, et de connaître ainsi les liaisons fonctionnelles entre les différentes variables. Par exemple,
les graphes de fluence permettent de faire des regroupements, de détecter les variables clés et leurs interactions.
Notons toutefois que la complexité des graphes obtenus rend difficile leur exploitation. Les diagrammes blocs ont
permis d’avoir une vision globale du procédé en fonctionnement et représentent le schéma fonctionnel qu’auront les
opérateurs lors de la supervision. Le diagramme de tâche, réalisé ensuite, structure la connaissance utilisée en
conception à partir des spécifications, sans nécessité de mesure directe généralement obtenue par une évaluation
empirique. Mais seules les actions opérateurs sont

2
Comme nous l’avons vu dans le chapitre II, nous aurions pu illustrer cet exemple avec GOMS, DIANE, MAD ou
SADT-Petri. HTA nous parait être le plus simple pour montrer la mise en œuvre de la démarche d’évaluation.
 Chapitre V 103

représentées ; les procédures de résolution des problèmes ne sont pas décrites. Malgré cette lacune, cette
modélisation des tâches humaines est particulièrement importante dans la mesure où elle facilite la communication
entre les intervenants de l’équipe de développement, et met en évidence les besoins informationnels de l’opérateur.
Voir à ce sujet les récents travaux de Riera et al. (95) qui proposent une démarche d’analyse prenant en compte les
besoins informationnels dès le début du développement.

AMDEC / Diagramme bloc / Arbre de défaillances / Graphe de fluence

Figure V.4 : Exemple de documents utilisés par l’équipe d’évaluation

La démarche suivie pour l’analyse et la construction de l’arbre hiérarchique des tâches de supervision est la
suivante (inspirée de celle utilisée par Stammer et al. 90 avec HTA) :

1. Nous énumérons les tâches buts3 de l’opérateur de supervision.

2. Une tâche but est choisie et dénommée par un verbe. Nous la décrivons ensuite en une série d’opérations plus
détaillées, avec des constituants et un ordre de réalisation.

3. Chaque opération est redécrite progressivement, jusqu’à un niveau de réalisation de sous-tâches explicites qui
ne méritent plus d’être détaillées.

4. Puis, nous retournons à l’étape 2 pour décrire la tâche suivante, jusqu’à ce que toutes les tâches énumérées en 1
soient décrites.

Par exemple, dans notre cas les tâches buts de l’opérateur de supervision sont : assurer la fabrication de produit
dans chacune des cellules, vérifier que les cuves de mélange soient à la bonne température, configurer le calculateur
avec les gammes de fabrication (ou recettes) des produits et prendre en compte les alarmes. Sur la figure V.5, la
première tâche but a été dénommée “surveiller les paramètres principaux de la cellule 1”, décomposée en neuf
opérations plus détaillées, avec un ordre de réalisation correspondant au plan 1. Chaque opération est redécrite ensuite
de la même manière jusqu’au niveau élémentaire.

3
Normand (92) définit la tâche comme : “un objectif à atteindre par l’utilisateur à l’aide d’un système interactif”. Ainsi
la tâche est un but que l’utilisateur vise à atteindre assorti d’une procédure (ou plan) qui décrit les moyens pour atteindre ce
but. Le but est un état du système que l’utilisateur souhaite obtenir. D’où la notion de tâche but.
 Chapitre V 104

La figure V.5 présente une partie de l’arbre des tâches obtenu pour le procédé considéré. Des liens de relation entre
éléments tâche sont ajoutés à cette analyse sous la forme d’un ordonnancement de besoins à spécifier, qui inclut le
séquencement des opérations : un plan pour chaque division (annoté sur la figure).

OBS 1 surveiller les paramètres 1.1 surveiller l'entrée des

principaux de la cellule 1 matières premières
1.2 surveiller les convoyeurs
…cellules 1 à 13… 1.3 surveiller le broyeur
1.4 surveiller la cuve mélangeur
surveiller les paramètres
assurer 0 13
principaux de la cellule 13 1.5 surveiller et ajuster les
la fabrication des paramètres de température
mélanges à partir de
1.6 surveiller et ajuster le
la salle de contrôle débit solvant
contrôler les paramètres de
14 surveiller les paramètres
température 1.7
d'exploitation surveiller la quantité
1.8.1
surveiller le mélange en de mélange sortie
1.8 Tâches terminales
15 gérer les recettes sorties du processus surveiller la qualité
1.8.2
demander le nettoyage du mélange sortie
1.9
de la cellule
16 gérer les alarmes

plan 0 plan 1 plan 1.8

1 à 13 continuellement 1, 2, 3, 4 et 7 continuellement 1 et 2
pendant que l'usine est en 5 et 6 pendant le mélange
fonctionnement 8 après le temps de mélange
14 selon la situation 9 selon changement de mélange
15 en début de poste
16 si apparition d'alarme

Figure V.5 : Modèle OBServé lors de l’étape de spécification fonctionnelle

(obtenu à partir des informations concepteur)

Après avoir observé et décrit les spécifications fonctionnelles, l’évaluateur s’intéresse maintenant à ce qui avait été
effectivement demandé à l’initialisation du développement. C’est la construction du modèle de l’évaluateur.

II.1.2. Exemple de modèle de l’ ÉVAL uateur (lors des spécifications

fonctionnelles)

Lors de l’étape de spécification fonctionnelle de l’interface, l’évaluation consiste à vérifier si l’IHM spécifiée
permet bien de réaliser les tâches préconisées par l’analyse du fonctionnement du procédé et la définition des besoins.
Pour cela, l’évaluateur s’est reporté au cahier des charges, et a analysé ce qui a été demandé par l’initiateur du projet,
concernant la tâche de l’opérateur de supervision. Ce travail doit en principe être effectué en étroite collaboration avec
le futur utilisateur de l’interface (s’il existe) ou celui d’une interface voisine.

Dans notre cas, l’opérateur de supervision doit saisir les recettes des mélanges à fabriquer pour configurer le
calculateur, gérer la communication avec les services amont et aval mais surtout avec la manutention, superviser les
13 stations de mélange, la cellule de solvant et la température de chaque cuve de mélangeur. Pendant la fabrication ou
en cas de problème, c’est lui qui agit sur les paramètres du processus et décide des interventions nécessaires (équipe
de manutention ou de maintenance). De plus, l’interface doit permettre à l’opérateur d’anticiper au maximum.

La description ÉVAL est alors effectuée dans un formalisme permettant sa comparaison avec le modèle OBS (ici une
hiérarchie HTA de tâches, fig. V.6). La démarche pour aboutir à cette description est la même que celle décrite
précédemment.

Cette première phase E1 qui part de l’analyse de la structure du système pour aboutir à un schéma fonctionnel des
tâches de l’opérateur contribue à situer les articulations homme-procédé et à définir les exigences du travail. En effet,
lors d’une intervention ergonomique de conception ou d’évaluation, l’équipe de développement doit acquérir une
connaissance suffisante du système socio-technique considéré.
 Chapitre V 105

1.1 configurer le calculateur

EVAL 1 saisir les recettes

1.2 créer une nouvelle recette
1.3 créer une nouvelle recette
} liste des constituants du
mélange (%, poids, T°…)

2.1 communiquer avec la production

Tâches
2 gérer la communication 2.2 communiquer avec la maintenance
terminales
2.3 communiquer avec la manutention

superviser les 13 cellules 3.1 agir sur les paramètres

surveiller le 0 3
de mélange
système de 3.2 prendre des décisions
fabrication

}
tâche 3 à 15 3.3 surveiller les paramètres

superviser la cellule 3.4 surveiller les éléments pour anticiper…

16
solvant
3.5 réguler la température du
mélange
17 superviser la température
3.6 autoriser le nettoyage
surveiller les paramétres
18 principaux du procédé
complet

plan 0 plan 3
1 en début de poste 1, 2 selon la situation
2, 3…16 , 17,18 en continue 3, 4 continuellement
5 pendant le mélange
6 selon changement de mélange

Figure V.6 : Modèle de l’ÉVALuateur de description des besoins

(obtenu à partir d’une analyse de la tâche)

Après avoir décrit les spécifications de l’interaction homme-machine, sous la forme des modèles OBS et ÉVAL,
l’évaluation a priori de l’utilité de l’interface devient possible dans la phase E2.

II.2. Phase E2 : Évaluation a priori de l’utilité de l’interface (spécifiée)

La phase E2 est focalisée sur l’évaluation de l’utilité de l’IHM par comparaison des modèles de description de
l’interaction homme-machine (fig. V.7). L’utilité d’une interface reflète la facilité avec laquelle l’utilisateur peut
atteindre ses objectifs de travail, principalement en terme de capacité fonctionnelle et de performance du système.
L’évaluer consiste à observer l’adéquation à la tâche et la répartition du travail, c’est-à-dire à vérifier si les procédures
de l’utilisateur sont similaires à celles qui seront développées (comparaison de la tâche prescrite à la tâche réelle).

EVALUATION A PRIORI

Spécification E1
OBS E2 E3
fonctionnelle utilité
utilisabilité
EVAL

Figure V.7 : Étape de spécification fonctionnelle, phase E2

Dans la figure V.8, nous avons ramené les deux descriptions obtenues précédemment : le modèle OBServé issu de
l’analyse du fonctionnement du système (figure V.5) et le modèle de l’ ÉVALuateur qui décrit les besoins,
principalement issu de l’analyse des tâches (figure V.6).

La comparaison des deux descriptions est effectuée par l’évaluateur, en mettant en rapport les tâches énumérées
dans chacune des descriptions. Celles-ci doivent de plus être prises en compte à un même niveau de décomposition.
En fait, il faut vérifier que tous les besoins ont bien été pris en compte ou que leur interprétation est en accord avec la
tâche globale ou les sous-tâches de l’opérateur de supervision. En cas de mauvaise description, l’interface qui en sera
issue risque de ne plus correspondre à ce qui a été demandé.
 Chapitre V 106

Pour chaque tâche du modèle de l’évaluateur (Téval i), on recherche celle correspondante dans le modèle observé
(Tobsi). Si elle n’existe pas, c’est que cette tâche n’a pas été prise en compte et constitue une erreur de spécification. Il
est toutefois possible qu’une tâche Tobs i soit divisée en plusieurs tâches (Téval j1, Tévalj2, Tévalj3) dans le modèle
ÉVAL, ou inversement que Téval i corresponde à (Tobsj1, Tobsj2, …, Tobsjn). Dans ce cas, la tâche sera effectivement
prise en compte dans l’interaction mais il faut vérifier que la décomposition soit toujours en accord avec la réalisation
de la tâche préconisée lors de la définition des besoins.

OBS : modèle observé de description des spécifications fonctionnelles

surveiller les paramètres
1 1.1 surveiller l'entrée des
principaux de la cellule 1 matières premières
1.2 surveiller les convoyeurs
…cellules 1 à 13… 1.3 surveiller le broyeur
1.4 surveiller la cuve mélangeur
surveiller les paramètres
assurer 0 13 1.5 surveiller et ajuster les
principaux de la cellule 13 paramètres de température
la fabrication des
mélanges à partir de
1.6 surveiller et ajuster le
la salle de contrôle débit solvant
contrôler les paramètres de
14 surveiller les paramètres
température 1.7
d'exploitation
surveiller le mélange en
1.8
15 gérer les recettes sorties du processus
demander le nettoyage
1.9
de la cellule
16 gérer les alarmes

Analyse, évaluation de
l’utilité de l’interface

ÉVAL : modèle de l’évaluateur de description des besoins

1 saisir les recettes
2 gérer la communication
1.1 configurer le calculateur
1.2 créer une nouvelle recette
1.3 créer une nouvelle recette
2.1 communiquer avec la production
2.2 communiquer avec la maintenance
2.3 communiquer avec la manutention

superviser les 13 cellules

3 3.1 agir sur les paramètres
surveiller le 0 de mélange
système de 3.2 prendre des décisions
fabrication tâche 3 à 15 3.3 surveiller les paramètres

superviser la cellule 3.4 surveiller les éléments

16 solvant
3.5 réguler la température du
mélange
17 superviser la température
3.6 autoriser le nettoyage
surveiller les paramétres
18 principaux du procédé
complet

Figure V.8 : Comparaison des modèles observés et de l’évaluateur

Lorsque la tâche Tobsi est décrite dans le modèle OBS, son niveau dans l’arborescence doit être identique à celle de
Tévali du modèle ÉVAL. Si le niveau est différent, cet état de fait doit être justifié. Il faut aussi vérifier les tâches mères
et sœurs en prenant en compte leurs liens et surtout leur planification. C’est pourquoi le plan associé à chaque division
est intéressant pour préciser l’ordonnancement des tâches.

Concernant les spécifications de l’interface du procédé de mélange, les points énumérés ci-dessous présentent
quelques-unes des remarques issues de la comparaison des deux descriptions proposées (évaluation de l’utilité) :

• Tous les besoins préconisés dans le modèle ÉVAL apparaissent dans la description a priori OBS. Cela laisse
 Chapitre V 107

présager une bonne prise en compte des besoins utilisateur (en considérant que l’analyse des tâches a été bien
effectuée).

• Les tâches de supervision des paramètres des cellules de mélange apparaissent au niveau 2 de la description
OBS (Tobs1.5 et Tobs1.7). Elles sont pourtant primordiales pour l’anticipation de l’évolution du processus ;
c’est pourquoi la modélisation ÉVAL les a prises en compte très tôt (Tobs 18). La profondeur à laquelle se
trouvent les tâches et surtout la comparaison avec ce qui été préconisé met à jour l’importance accordée aux
différentes activités de supervision. Il semble en effet que plus une opération se trouve bas dans l’arborescence,
plus elle devient spécifique et donc moins globale.

• Lors de la définition des besoins, il a été demandé de prévoir une interface qui permette d’anticiper au
maximum. C’est pourquoi, une tâche de gestion des alarmes apparaît au second niveau de la description OBS
(Tobs16). Dans le modèle ÉVAL, cette tâche n’est pas présente de façon explicite pour éviter une conduite dite
“sous alarme”. L’anticipation est rendue possible par la présentation au premier niveau des principaux
paramètres pertinents de chaque cellule (Téval 18). Notons que la définition et le mode de présentation de ces
paramètres permettant l’anticipation ne sont pas donnés.

• La tâche de communication avec la manutention n’est pas prise en compte dans la description a priori OBS.
Pourtant elle a été préconisée comme faisant partie de l’interaction homme-machine (Téval 2) puisque
l’opérateur de supervision doit dans certain cas prendre contact avec des intervenants sur le terrain pour obtenir
des informations non instrumentées sur le procédé (par exemple le niveau de remplissage des trémies).

• En ce qui concerne le solvant, liant important dans la composition du produit, nous constatons que celui-ci n’est
surveillé qu’au sein de la supervision des cellules de mélange (Tobs 1.6). Une tâche de haut niveau pour
superviser la cellule solvant doit être ajoutée, en effet le solvant est un élément qui intervient dans tout le
processus de fabrication, un arrêt de sa distribution engendrerait inévitablement un arrêt de la production. C’est
pourquoi l’évaluateur a préconisé la tâche Téval16.

La phase E2 constitue donc une vérification des propositions des concepteurs lors de l’étape de spécification. La
synthèse des deux modèles conduit en quelque sorte à effectuer une conception orientée homme. A l’issue de la phase
d’évaluation, on obtient un modèle a priori de l’interaction homme-machine au niveau conceptuel, qui devra être
utilisé pour la suite (fig. V.9). Les améliorations suite à l’analyse de la phase E2 sont annotées sur la figure.

L’analyse de la tâche et la comparaison des deux descriptions par ce premier “filtre d’évaluation” E2 permet de
concevoir des systèmes à partir des fonctions définies lors de l’identification du besoin et non à partir du matériel
existant. Elle permet également de prendre en considération les exigences de l’opérateur humain impliqué dans le
système, et aboutit à l’établissement des schémas de structure du système. Au niveau conceptuel, on parlera d’objets
conceptuels manipulés par l’opérateur lors de l’interaction avec la machine. A ce modèle a priori de l’interaction, sera
ajoutée une description des objets, de leurs attributs et de leurs relations (illustrée par la figure V.10 pour les tâches
“surveiller les paramètres principaux de la cellule 1” (T1) et “gérer les recettes” (T15).

Chaque tâche doit comporter des informations et des indices qui seront ensuite utilisés lors de la phase suivante
d’évaluation. Le nom, le numéro d’ordre, le type de tâche, le niveau ou la profondeur dans l’arborescence, le nombre
d’objets de même niveau (parmi), l’indice de la tâche immédiatement supérieure (parent) sont autant de données
nécessaires pour identifier chaque tâche et la localiser dans l’arborescence. Le but de la tâche informe sur la
signification de l’objet dans l’interaction homme-machine. Les relations entre tâches, les paramètres manipulés, leurs
attributs et les outils qui seront a priori utilisés dans l’interaction (éléments déjà discutés dans le chapitre IV sur
l’exemple du réacteur nucléaire), seront utiles pour décrire la sémantique de l’interaction homme-machine. Les
conditions déclenchantes correspondent à l’état du monde à satisfaire avant de commencer la tâche. Celles
déclenchées représentent le monde après réalisation de la tâche (similaire aux pré-conditions et post-conditions du
formalisme MAD)
 Chapitre V 108

OBS 1.1 surveiller l'entrée des

Modèle matières premières tâche surveiller les éléments
A PRIORI
EVAL 1.2 surveiller les convoyeurs dans le modèle EVAL
surveiller les paramètres
1 1.3 surveiller le broyeur
principaux de la cellule 1
1.4 surveiller la cuve mélangeur

…cellules 1 à 13… 1.5 surveiller et ajuster les tâche surveiller les paramètres
paramètres de température dans le modèle EVAL
1.6 surveiller et ajuster le
assurer 0 surveiller les paramètres débit solvant
13
la fabrication des principaux de la cellule 13
surveiller les paramètres
mélanges à partir de 1.7
d'exploitation surveiller la quantité
la salle de contrôle 1.8.1
surveiller le mélange en de mélange sorties
1.8
sorties du processus surveiller la qualité
1.8.2
contrôler les paramètres de demander le nettoyage du mélange sortie
14 1.9
température de la cellule

Tâche non prise en compte 15.1 configurer le calculateur

dans les spécifications 15 gérer les recettes 15.2 créer une nouvelle recette
fonctionnelles 15.3 modifier une recette

16 superviser la cellule solvant

17 gérer la communication
Pour permettre
l'anticipation 18 surveiller les paramétres
principaux du processus
18.1 communiquer avec la production
18.2 communiquer avec la maintenance
18.3 communiquer avec la manutention
plan 1.8
1 et 2

plan 0 plan 1
1 à 13, 16, 18 continuement 1, 2, 3, 4 et 7 continuellement
pendant que l'usine est en 5 et 6 pendant le mélange
fonctionnement 8 aprés le temps de mélange
14 et 15 selon la situation 9 selon changement de mélange
17 en début de poste

Figure V.9 : Modèle a priori de l’interaction homme-machine, au niveau conceptuel

(synthèse des modèles ÉVAL et OBS)

Surveiller les paramètres principaux de la cellule 1 =(tâche, niveau(1), numéro(1), parmi(18), parent (tâche,0))
But: Évaluer l’état global de la cellule en contrôlant certain paramètres pertinents, afin de se rendre compte de l’état
du système
Relation: surveiller entrée matières premières (T1.1), surveiller éléments cellule (T1.2, T1.3, T1.4), surveiller-ajuster
paramètres température (T1.5), surveiller-ajuster débit solvant (T1.6), surveiller paramètres exploitation (T1.7),
surveiller mélange sortie processus (T1.8), nettoyage cellule (T1.9), cellules adjacentes (T2…13),
communication (T17.3)
Paramètres manipulés: état éléments, recette mélange
Outils utilisés pour l’interaction: écran, clavier, souris, radio téléphone
Pré-condition:
Post-condition:

Gérer les recettes =(tâche, niveau(1), numero(15), parmi(18), parent(tâche,0))

But: décrire le mode de fabrication d’un ou de différents produits
Relations: configurer calculateur (T15.1), créer nouvelle recette (T15.2), modifier recette (T15.3)
calculateur, cellules mélanges
Paramètres manipulés: n° recette, n° cellule, noms composant, noms produit, quantités…
Outils utilisés pour l’interaction: écran, clavier, souris
Pré-condition: début de poste, fonctionnement normal
Post-condition: configuration calculateur
Figure V.10 : Exemple de description des objets, de leurs attributs et leur relations
 Chapitre V 109

II.3. Phase E3 : Évaluation de l’utilisabilité de l’interface (spécifiée)

La phase d’évaluation de l’utilisabilité de l’interface permet de vérifier la qualité ergonomique de l’interaction
homme-machine avant de continuer le cycle. A partir de la description de l’interaction obtenue après le premier filtre
d’évaluation E2, l’évaluateur va estimer l’utilisabilité de l’interface qui sera conçue à partir des spécifications (fig.
V.11).

EVALUATION A PRIORI

Spécification E1
OBS E2 E3
fonctionnelle utilité
utilisabilité
EVAL

Figure V.11 : Étape de spécification fonctionnelle, phase E3

En fonction de l’étape de développement en cours, seulement certains critères ergonomiques sont concernés (Cf.
figure IV.20 du chapitre IV). Les critères à évaluer lors de l’étape de spécification fonctionnelle sont l’incitation, les
actions minimales et la charge mentale, la flexibilité et la prise en compte de l’expérience de l’utilisateur rassemblés
dans l’adaptabilité de l’interface, et la compatibilité. La démarche d’estimation des critères consiste tout d’abord à les
mettre en évidence dans la description puis à juger de leur prise en compte dans l’interaction homme-machine. La
mise en évidence du critère dans la description a priori est spécifique à chacun d’eux.

Notre travail ne consistait pas à mettre en place des méthodes d’estimation de tous ces critères, nous donnons
quelques exemples simples en annexe D (pistes de recherches de méthodes d’estimation des critères ergonomiques
d’évaluation) dans le but de prouver globalement la faisabilité de la démarche d’évaluation a priori. Bien entendu,
ces “métriques” méritent de plus amples travaux, elles font l’objet de nos perspectives de recherches.

A titre d’exemple, nous nous intéressons ci-dessous au critère d’incitation, caractéristique du guidage dans la
communication homme-machine.

La description hiérarchique des tâches et les plans de la figure V.9 listent les informations a priori utilisées par
l’opérateur lors de son interaction avec l’application : les relations entre objets, leurs attributs et propriétés, les
opérations possibles. Ces données (reprises dans la figure V.10) permettent de conseiller, orienter, informer et guider
l’utilisateur pour la réalisation de sa tâche ; elles sont représentatives de l’incitation. Lister et comptabiliser les
éléments renseignés dans les descriptions peut contribuer à une première estimation de ce critère. L’annexe D présente
un exemple de calcul pour les tâches surveiller les paramètres principaux de la cellule 1 (T1) et gérer les recettes
(T15).

Dans la proposition, chaque élément renseigné dans la description incrémente la note du critère d’incitation de la
tâche (plus la note est élevée, plus l’incitation est bonne). Dans notre exemple, la tâche “gérer les recettes” est mieux
renseignée que la tâche “surveiller les paramètres principaux de la cellule 1”. Ce manque de précision dans les
spécifications de la tâche risque de se répercuter sur l’interface, puisque les données utilisées pour construire le
modèle a priori doivent être utilisées dans les phases suivantes de conception jusqu’à la réalisation. Ainsi il faut
apporter plus de précision dans les spécifications fonctionnelles de la tâche de visualisation de la cellule de mélange ;
ici l’effort doit être porté sur les pré et post-conditions.

II.4. Conclusion sur l’évaluation des spécifications

Dans notre cas d’étude, l’évaluation a été exclusivement réalisée à partir des informations issues des spécifications
fonctionnelles. Un certain nombre de lacunes relatives à l’utilité et l’utilisabilité de l’interface future ont été mises à
jour grâce à la démarche d’évaluation proposée. A ce stade du développement, les spécifications doivent être revues
par rapport aux recommandations proposées. Si les spécifications restent inchangées, les lacunes détectées à ce niveau
se répercuteront aux niveaux inférieurs. Bien entendu, tout ce travail d’évaluation est réalisé en étroite collaboration
 Chapitre V 110

avec les intervenants dans le développement. Les recommandations qui en sont issues sont le résultat de
compromis discutés par les deux équipes lors de réunions de travail.

Les points suivants font la synthèse des principaux résultats de l’évaluation a priori. Ils correspondent à ce qui est
décrit dans le modèle de l’interaction homme-machine de la figure V.8 et constituent des avertissements sur
l’ergonomie de l’interface future.

• La supervision des paramètres principaux des cellules de mélange doit être prévue à un niveau haut dans
l’imagerie. Cela permettra de disposer d’informations permettant d’anticiper sur l’évolution du procédé à partir
de l’évolution de variables pertinentes.

• Il faut intégrer dans l’IHM la tâche de communication avec les membres de l’équipe de manutention qui se
trouvent sur les différents sites. En effet, certaines mesures importantes en cas de dysfonctionnement ne sont
pas instrumentées, elles interviennent pourtant dans la supervision (par exemple le niveau de remplissage des
trémies).

• L’interface doit permettre au superviseur d’intervenir directement sur les éléments du procédé. Il faut en
conséquence définir explicitement les modes et procédures de commande.

• Il s’agit de prendre en compte le critère d’incitation de la même manière partout dans l’interface, et de prévoir
des modules d’aide utilisateur.

• La tâche globale de supervision et les tâches de surveillance des paramètres principaux des cellules manipulent
beaucoup d’entités ; elles risquent d’impliquer une charge de travail importante.

• L’adaptabilité de l’interface n’a pas été prise en compte. Il faut prévoir d’autres modes d’accès plus direct aux
éléments du système. Il serait sans doute nécessaire d’envisager la possibilité de configurer l’interface en
fonction du mode de fonctionnement (normal, anormal, dégradé) ; cela limiterait sans doute la charge de
travail.

Lors du déroulement du projet attaché à cette étude, une imagerie de supervision du procédé a été proposée dans
l’étape de conception en prenant en compte les spécifications évaluées. Celle-ci est présentée en détail en annexe C.
Dans la partie suivante, nous présentons l’évaluation réalisée, toujours en suivant la démarche d’évaluation a priori.

III. É VALUATION LORS DE L’ ÉTAPE DE CONCEPTION PRÉLIMINAIRE

Comme précédemment, nous appliquons les trois phases E1, E2 et E3 de façon chronologique, mais cette fois,
c’est le niveau sémantique qui est le plus concerné (Fig. V.12). Il s’agit donc d’évaluer l’aspect fonctionnel de
l’interaction en analysant, d’une part les commandes et actions de l’utilisateur pour réaliser sa tâche, et d’autre part les
retours du système.

Analyse du procédé
en fonctionnement
normal et anormal

Spécification
fonctionnelle
EVALUATION A PRIORI
Conception E1
OBS
E2 E3
préliminaire utilité
cahier des charges CO utilisabilité
analyse des besoins, SÉ EVAL
contraintes et SY
objectifs L

Figure V.12 : Phases E1, E2 et E3 d’évaluation a priori lors de la conception préliminaire

Selon les définitions du génie logiciel, lors de l’étape de conception préliminaire la solution “optimale”
 Chapitre V 111

répondant aux besoins spécifiés lors des spécifications fonctionnelles est décrite. Cette étape consiste à décomposer la
solution en une architecture modulaire. Dans cette architecture, chaque composant fait l’objet d’une description
jusqu’à ce que les besoins identifiés soient tous pris en compte.

Dans notre cas, à cette étape, l’équipe d’évaluation dispose des différents écrans de l’interface future donnant un
aperçu grossier des composants graphiques qui seront mis à la disposition des opérateurs (Fig. V.13, toutes les
propositions d’écran de l’imagerie proposée sont présentées et détaillées dans l’annexe C).

Figure V.13 : Première version papier des vues de l’imagerie proposées par les concepteurs
(a) vue principale, (b) vue cellule fabrication avec deux vues de détails (c et d)

Selon les concepteurs, chaque tâche y est considérée et sous-jacente, et l’architecture de l’interface correspond à
l’ordonnancement de différents écrans représentant des niveaux d’abstraction dans la tâche à réaliser. On constate que
non seulement la sémantique de l’interaction peut être analysée, mais que l’équipe d’évaluation dispose aussi de
quelques éléments correspondant aux niveaux syntaxique et lexical. En effet, lors des réunions de travail avec les
concepteurs, différents aspects de la gestion du dialogue ont été abordés : enchaînements des pages écrans, rôles des
boutons de commande, positionnement des items, choix graphiques…

III.1. Phase E1 : modélisation a priori de l’interaction homme-machine

(conçue)

Le formalisme CLG a été utilisé pour représenter l’interaction homme-machine aux différents niveaux
d’abstraction du modèle COSÉSYL. Comme nous l’avons signalé dans le chapitre III, lors du positionnement des
modèles, CLG est en théorie le seul modèle disponible au niveau sémantique ; c’est la raison pour laquelle il est utilisé
ici, même si son utilisation s’avère excessivement lourde.

III.1.1. Exemple de modèle OBS ervé (lors de la conception préliminaire)

La description CLG du modèle OBS est directement issue des écrans qui ont été proposés par les concepteurs (fig.
V.13). Le niveau sémantique enrichit le modèle du niveau conceptuel avec les concepts mis en jeu par l’interface.
CLG est fondé sur l’hypothèse de base de décrire le système
 Chapitre V 112

selon le point de vue de l’utilisateur. Dans ce but, le système homme-machine est considéré comme un ensemble
d’objets à manipuler, ceux-ci sont décrits au moyen des éléments de représentation proposés au niveau sémantique de
CLG : les entités et opérations conceptuelles, et les méthodes sémantiques (figure V.14).

Entités conceptuelles manipulées au niveau sémantique

SYSTEME Le système homme-machine qu’utilise l’opérateur est composé
ENTITE (n) d’un ensemble d’entités conceptuelles (n) et d’opérations (m).
OPERATION (m)
Entité (1…n) • Les entités conceptuelles représentent les tâches spécifiques
DESCRIPTION à effectuer par l’utilisateur au moyen du système.
COMMANDE • Leurs descriptions réunissent : les propriétés importantes,
VARIABLE les constituants, les relations et les variables manipulées.
• Les commandes et opérations concernent les actions
OPERATION spécifiques des tâches liées aux entitées.
…

Opérations conceptuelles manipulées au niveau sémantique

OPS (i)
• Les opérations conceptuelles sont les actions élémentaires
OBJET applicables aux entités conceptuelles.
DESCRIPTION Elles se caractérisent par des paramètres d’entrée, un résultat,
RESULTAT des conditions d’échec, etc, et se répartissent en deux
OPU (j) catégories.
OBJET • les opérations réalisées par le système (OPS)
DESCRIPTION • les opérations qui modélisent les actions
RESULTAT conceptuelles de l’utilisateur (OPU)
…

Méthodes conceptuelles manipulées au niveau sémantique

M-SEM (p)
BUT La méthode sémantique décrit un moyen pour accomplir
une tâche en terme :
RESULTAT • d'entités et d’opérations conceptuelles,
PROCEDURE • sous la forme d’une procédure sémantique.
…

Figure V.14 : Éléments de représentation au niveau sémantique de CLG

Dans notre cas d’étude, les entités conceptuelles 4 CLG sont des “objets écran” décrits à partir des vues existantes,
elles sont dites conceptuelles car liées aux tâches de l’opérateur. La figure V.15 présente une partie de la description de
l’entité conceptuelle “imagerie de supervision”. Imagerie-supervision y est défini comme UN SYSTÈME qui manipule
un ensemble de 18 ENTITÉS conceptuelles correspondant aux différents écrans de l’imagerie : vue-principale, vue-
cellule-fabrication[1 à 13], vue-solvant, vue-alarmes, vue-recette, vue-température (les deux premières vues sont
présentées sur le figure V.13, pour les autres voir l’annexe C).

L’entité vue-principale est ensuite décrite comme représentant la tâche globale de supervision de la fabrication. Sa
description correspond au contenu de l’écran (voir la représentation de l’écran sur la figure V.13 ou en annexe C), soit
ce qui a été jugé nécessaire par les concepteurs pour réaliser la tâche considérée —c’est le modèle OBS :

• Les entités blocs-cellules représentent les 13 stations de mélange et la station de fabrication du solvant.

• Les deux entités synthèse-paramètre correspondent à une présentation synthétique de l’état des cellules (des
pseudo vues étoiles).

4
Pour décrire la communication homme-machine, que nous situons au niveau sémantique de COSÉSYL, le formalisme
CLG manipule des éléments dit conceptuels. Malgré l’emploi du terme conceptuel, ceux-ci ne sont pas à confondre avec les
tâches du niveau COnceptuel défini dans COSÉSYL, on s’intéresse bien ici à la SÉmantique de l’interaction.
 Chapitre V 113

• Les commandes correspondent aux actions possibles à partir de cet écran ; elles sont décrites ensuite
individuellement.

• Les variables utilisées pour représenter et manipuler les objets du système sont relatives à l’interaction avec
l’homme et le processus. Elles représentent l’état des éléments de la cellule de fabrication concernée et les
mesures effectuées sur le produit fabriqué : temps-mélange, température-cuve…

Imagerie-supervision= (UN SYSTEME

| NOM= “imagerie de supervision”
| ENTITE= (ENSEMBLE: (* ensemble des objets manipulés par l’imagerie)
| | vue-principale, vue-cellule-fabrication[i], vue-solvant, vue-alarmes, vue-recette,
| | vue-temperature, écran, imprimante)
| OPERATION= (ENSEMBLE: (* ensemble des opérations possibles sur l’imagerie)
| | afficher, consulter, rechercher-info, surveiller-cellule, surveiller-procédé, surveiller-solvant,
| | surveiller-alarme, surveiller-temp, modifier-recette, autoriser-nettoyage, commander-fab,
| | commander-fab-S, saisir-données, imprimer)
|
| vue-principale = (UNE ENTITÉ
| | NOM= “vue principale”
| | REPRÉSENTE (UNE T-ecran) (* représente une entité de tâche écran de supervision)
| | DESCRIPTION: (ENSEMBLE:
| | | titre-vue(NOM),
| | | contexte(NOM),
| | | aide(NOM, element),
| | | blocs-cellules[i]= (ENSEMBLE: cellule-fab[1..13], cellule-solvant),
| | | synthèse-paramètre(cellule[1…7]),
| | | synthèse-paramètre(cellule[8…14]) )
| | COMMANDE= (ENSEMBLE: alarme, recette, température, selectionner[blocs-cellule[i] )
| | VARIABLE= (* parametres pertinents des cellules)
| | | (état-procédé, état-cellule[i], alarme-cellule[i], degré-gravité-cellule[i])
| | OPERATION= (ENSEMBLE: afficher, mettre-à-jour, sélectionner-élément, rechercher, lire) )
| ……
Figure V.15 : Description au niveau sémantique : exemple d’entités conceptuelles (OBS)

Les opérations interactives que peut réaliser l’opérateur à partir du système global ou les retours de l’interface sont
listés dans la description du système Imagerie-supervision. La figure V.16 en détaille quelques-unes. Par exemple, La
surveillance des cellules est une opération utilisateur (OPU) qui consiste à s’intéresser à un écran de l’imagerie de
supervision. Cet écran est représentatif de l’état de fonctionnement de la cellule à surveiller. L’opérateur va analyser
cet objet par rapport à un ensemble de critères qui lui sont propres et qui vont lui permettre de connaître l’état global
de la cellule (état, dysfonctionnement, dégradations, disponibilité, qualité de fabrication par exemple).

OPU-surveiller-cellule= (UNE OPERATION-UTILISATEUR

| OBJET= (UN PARAMETRE VALEUR= (UN T-ecran))
| DANS (UN PARAMETRE VALEUR= (UNE ENTITE DE imagerie-supervision)
| POUR (UN PARAMETRE VALEUR= (ENTITE-CRITERE))
| RESULTAT= (UNE ENTITE)) (* qui satisfasse ENTITE-CRITERE) )
| (* l’opérateur recherche un objet de type T-écran DANS une ENTITE de l’imagerie de supervision pour |
satisfaire le critére)

OPS-afficher= (UNE OPERATION-SYSTEME

| OBJET= (UN PARAMETRE VALEUR= (UNE ENTITE))
| DANS (UN PARAMETRE VALEUR= (UNE PLACE DE ecran))
| VISIBLE-SI (ETAT (ENTITE)= EN-FONCTIONNEMENT) )
| (* afficher un objet de type ENTITE à une PLACE dans l’écran SI cette entité est visible
| la PLACE n’est pas spécifiée au niveau sémantique)
……
Figure V.16 : Description au niveau sémantique : exemple d’opérations conceptuelles (OBS)
(OPS : opération système et OPU : opération utilisateur)
 Chapitre V 114

L’accomplissement d’une tâche est ensuite décrite avec la méthode sémantique qui associe une procédure, basée
sur les opérations conceptuelles système et utilisateur, à une tâche définie au niveau supérieur. La figure V.17 donne
un exemple de méthodes associées à la tâche élémentaire surveiller le broyeur.

M-SEM13= (UNE METHODE-SEMANTIQUE POUR T-surveiller-broyeur[i]

| (* pour rechercher la VALEUR du couple-broyeur, il faut afficher vue-principale, rechercher la cellule-
| fabrication i, l’afficher, y rechercher le broyeur, optionnellement selectionner le broyeur et afficher la
| vue de détail, le couple-broyeur est lu par l’opérateur)
| BUT= (UN PARAMETRE VALEUR= (couple-broyeur))
| RESULTAT= (UNE VALEUR)
| FAIRE (SEQ:
| | START Imagerie-supervision
| | OPS-afficher vue-principale
| | OPU-rechercher cellule-fab[i]
| | OPU-selectionner (LE blocs-cellules DE (RESULTAT DE OPU-rechercher)
| | OPS-afficher (LA vue-cellule-fabrication DE (RESULTAT DE OPU-rechercher)
| | OPU-rechercher broyeur
| | OPU-consulter couple-broyeur
| OPTION (SEQ: (* affichage de la vue de détail )
| | OPU-selectionner broyeur
| | OPS-afficher (LA vue-détail DE RESULTAT DE OPU-rechercher)
| | OPU-rechercher couple-broyeur
| | OPU-consulter (LE RESULTAT DE OPU-rechercher) ) )
| ……
Figure V.17 : Description au niveau sémantique : exemple de méthode conceptuelle (OBS)

Surveiller le broyeur consiste à observer l’évolution du couple de broyage (un paramètre valeur). Avec la maquette
de supervision proposée, l’opérateur va pouvoir observer cette évolution, soit dans la vue de la cellule de fabrication,
soit à partir de la fenêtre de détail du broyeur. Le résultat recherché par l’opérateur correspond à la valeur numérique
du couple. La description CLG décrit la procédure qui va permettre d’aboutir au résultat recherché en utilisant les
entités et les opérations conceptuelles définies précédemment. Elle consiste donc à réaliser en séquence les opérations
système et utilisateur : afficher la vue principale (OPS), rechercher la cellule par l’opérateur (OPU), la sélectionner
(OPU), afficher la vue correspondante (OPS), rechercher et consulter par l’opérateur (OPU) la valeur du couple
broyeur. La méthode sémantique proposée comprend une séquence optionnelle, ainsi, si le broyeur n’est pas en
fonctionnement, l’opérateur devra demander l’affichage de la vue de détail (OPU sélectionner puis OPS afficher) pour
obtenir des informations sur le couple broyeur non visible sur la vue correspondant à la cellule (OPU rechercher et
OPU consulter).

III.1.2. Exemple de modèle de l’ ÉVAL uateur (lors de la conception préliminaire)

Lors de l’étape de conception de l’interface, il faut vérifier si l’IHM permet bien de réaliser les tâches qui ont été
spécifiées précédemment. Pour cela, l’équipe d’évaluation enrichit la description de l’interaction homme-machine du
niveau supérieur (phase E1) par des informations sur le mode d’accomplissement des tâches par l’opérateur et
l’interface. Le formalisme utilisé doit permettre de décrire la sémantique de l’interaction. Comme l’équipe
d’évaluation réalise ensuite une comparaison avec le modèle OBS, elle utilise aussi CLG ici. Cette grammaire n’ayant
pas été utilisée au niveau conceptuel supérieur, il faut donc traduire la description hiérarchique de tâches HTA en
CLG. Comme pour le modèle OBS, les figures suivantes présentent des exemples d’entités et d’opérations
conceptuelles, ainsi que des exemples de méthodes sémantiques associées au modèle ÉVAL.

L’IHM est un système qui manipule des entités correspondant aux tâches que doit réaliser l’opérateur (fig. V.18).
 Chapitre V 115

IHM= (UN SYSTEME

| NOM= “Maquette de supervision du procédé complet”
| ENTITES= (ENSEMBLE: (* ensemble des entités manipulées par le système)
| | procédé-complet, cellules(PARAMETRE cellule[c]), (* ‘c’ numéro de cellule 1 à 13)
| | cellule-solvant, température(PARAMETRE cellule[c]), recettes, communication, radio-telephone,
| | ecran, imprimante)
| OPERATIONS= (ENSEMBLE: (* ensemble des opérations possibles sur le système)
| | surveiller-procédé, surveiller-cellule, contrôler-cellule(PARAMETRE cellule[c]),
| | surveiller-cellule-solvant, contrôler-cellule-solvant, surveiller-température,
| | contrôler-température, communiquer, configurer-procédé, editer, afficher)
|
| Procédé-complet= (UNE ENTITE
| | NOM= “état globale du procédé complet”
| | REPRESENTE (UN T-système)
| | DESCRIPTION: (ENSEMBLE:
| | | état-procédé, (* état global du procédé pour permettre l’anticipation)
| | | contrôle-p, (* contrôle operateur possible sur le procédé)
| | | etat-cellules) (* état de toutes les cellules)
| | COMMANDE= (contrôle-c[c]) (* contrôle opérateur possible sur les cellules)
| | VARIABLE: (ENSEMBLE: ...) )
| | (*variables globales d’état des cellules, et d’état des mélanges fabriqués)
| ……
Figure V.18 : Description au niveau sémantique : exemple d’entités conceptuelles (ÉVAL)

La description de la figure liste les entités conceptuelles du système IHM : procédé-complet pour la tâche de
surveillance des paramètres principaux du processus, cellules paramétrées par un numéro, qui permet la supervision
d’une station de mélange en particulier, cellule-solvant pour la supervision de la fabrication du solvant, et température
qui concerne la tâche de suivi des températures de mélange. L’entité conceptuelle recette correspond à la tâche de
gestion des recettes (ou gamme de fabrication des produits) que doit superviser l’opérateur de la salle de contrôle. La
communication fait partie des tâches prescrites et à réaliser par le superviseur. C’est pourquoi un radio téléphone fait
partie de la description (en plus de l’écran et l’imprimante). Les tâches de supervision du procédé complet et des
cellules sont ensuite décrites de la même manière.

Selon le même principe que pour le modèle OBS, la figure V.19 donne un extrait de la description des opérations
réalisées soit par le système, soit par l’utilisateur à partir des entités conceptuelles précédemment décrites.

OPS-Afficher= (UNE OPERATION-SYSTEME

| OBJET= (UN PARAMETRE VALEUR= (UNE ENTITE))
| DANS (UN PARAMETRE VALEUR= (UNE PLACE DE ecran)) )
| (* afficher un objet de type ENTITE à une PLACE dans l’écran ; la PLACE n’est pas spécifiée au
| niveau sémantique)

OPU-surveiller= (UNE OPERATION-UTILISATEUR

| OBJET= (UN PARAMETRE VALEUR= (UNE ENTITE))
| DANS (UN PARAMETRE VALEUR= (UNE ENTITE DE IHM))
| POUR (UN PARAMETRE VALEUR= (ENTITE-CRITERE))
| RESULTAT= (UNE ENTITE)) ) (* qui satisfasse ENTITE-CRITERE)
| (* l’opérateur recherche un objet de type ENTITE DANS une ENTITE de la maquette de supervision pour
| satisfaire le critère)
……
Figure V.19 : Description au niveau sémantique : exemple d’opérations conceptuelles (ÉVAL)
(OPS : opération système et OPU : opération utilisateur)

Les méthodes sémantiques permettent ensuite de décrire a priori comment l’utilisateur va réaliser sa tâche. Comme
pour le modèle OBS ces méthodes sont basées sur des opérations systèmes et utilisateurs qui manipulent les entités
 Chapitre V 116

conceptuelles décrites précédemment (Fig. V.20).

M-SEM13= (UNE METHODE-SEMANTIQUE POUR T-surveiller-broyeur[i]

| (* pour rechercher l’état du broyeur, il faut afficher le procédé-complet,
| rechercher la cellule-fabrication ‘c’, l’afficher, y rechercher l’état du broyeur)
| BUT= (UN PARAMETRE VALEUR= (etat-broyeur))
| RESULTAT= (UNE VALEUR)
| FAIRE (SEQ:
| | START IHM
| | OPS-afficher procédé-complet
| | OPU-rechercher cellule[c]
| | OPU-selectionner (LE RESULTAT DE OPU-rechercher)
| | OPS-afficher (LE RESULTAT DE OPU-rechercher)
| | OPU-rechercher etat-broyeur
| | OPU-consulter (LE RESULTAT DE OPU-rechercher) )
Figure V.20 : Description au niveau sémantique : exemple de méthode conceptuelle (ÉVAL)

Cette description qui est directement issue de l’analyse des besoins, du cahier des charges et des contraintes et
objectifs du système homme-machine, décompose l’interaction en une séquence d’opérations. Ainsi, pour surveiller le
couple broyeur, le but de l’opérateur est de connaître son état, représenté par un paramètre. Avec l’IHM proposée dans
les descriptions ÉVAL ci-dessus, la méthode consiste à : afficher la vue du procédé complet, rechercher la cellule
concernée par l’opérateur, la sélectionner, afficher la vue correspondante, y rechercher et consulter par l’opérateur la
valeur du couple broyeur.

III.2. Phase E2 : Évaluation a priori de l’utilité de l’interface (conçue)

Il y a plusieurs difficultés à évaluer l’utilité de l’interface au niveau sémantique. Cette propriété concerne, d’une
part les éléments manipulés lors de l’interaction homme-machine (soit les entités et les opérations conceptuelles), et
d’autre part les méthodes pour accomplir les tâches.

Comme nous l’avons signalé tout au long de ce mémoire, l’utilité concerne principalement les aspects relatifs à la
tâche de l’opérateur et à la performance du système homme-machine. Celle-ci est donc évaluée lors de l’étape de
spécification fonctionnelle. Répéter la phase E2 ici, revient donc à vérifier si les recommandations en terme d’utilité
proposées dans l’étape précédente de développement ont bien été prises en compte (synthèse du §II.4).

Dans ce cas, et pour l’application qui nous intéresse, ce travail consiste à comparer les entités conceptuelles de
tâche entre elles. Cette comparaison peut être effectuée manuellement par l’équipe d’évaluation ou de façon
automatique en analysant les modèles OBS et ÉVAL en terme de sémantique et de syntaxe de la grammaire utilisée.
C’est à ce niveau que doivent être recherchés des algorithmes d’analyse et de comparaison ; ce point peut constituer
une perspectives de recherche. Dans ce cadre, il est nécessaire de disposer d’un formalisme rigoureux et propice à ce
travail, ce qui n’est pas vraiment le cas de celui proposé par CLG. En effet, CLG structure l’interaction homme-
machine en niveaux mais laisse beaucoup de libertés à l’analyste quant à la manière de la décrire. Seul un corps plus
ou moins grossier de description est proposé par l’auteur de la méthode (Moran 81 ; voir aussi les descriptions en
CLG de Coutaz 90). La décomposition obtenue organise l’interaction en sous-domaines moins complexes, mais à
chaque étape interviennent des décisions essentielles pour la qualité de l’interaction. Par exemple, les choix de termes
et d’enchaînement des tâches sont spécifiques à chaque application et à chaque analyste (par exemple, l’entité vue-
principale de OBS, correspond à l’entité procédé-complet de ÉVAL). Pour permettre la comparaison automatique, il faut
soit fournir un lexique des termes à utiliser pour construire les modèles, soit les retraduire.

Selon la démarche que nous proposons, au niveau sémantique de COSÉSYL, il faut évaluer les opérations
conceptuelles et les méthodes sémantiques CLG qui décrivent l’interaction homme-machine. Comme nous venons de
le signaler, pour pouvoir les comparer, il faut disposer d’une description fortement formalisée. Dans ce cadre, la
comparaison des deux descriptions OBS et ÉVAL de la phase E1 n’est possible qu’élément (de représentation) par
élément : entités conceptuelles, opérations utilisateur et système, et méthodes conceptuelles (Fig. V.21).
 Chapitre V 117

Modèle OBS Modèle ÉVAL

Entités conceptuelles manipulées au niveau sémantique
SYSTEMEOBS SYSTEMEÉVAL
ENTITEOBS (i) ENTITEÉVAL (j)
ENTITEOBS (i) — ENTITEÉVAL (j)
OPERATIONOBS (i) OPERATIONÉVAL (j)
OPERATIONOBS (i) — OPERATIONÉVAL (j)
EntitéOBS (i…n) EntitéÉVAL (j…m)
DESCRIPTION DESCRIPTION
COMMANDE pour toutes les entités (MAX (n,m)) COMMANDE
VARIABLE EntitéOBS (k) — EntitéÉVAL (k) VARIABLE
OPERATION OPERATION

=> Identification, nombre

Opérations conceptuelles manipulées au niveau sémantique

OPS (n) OPS (n)
OBJET OBJET
DESCRIPTION
OPSOBS (i) — OPSÉVAL (j) DESCRIPTION
RESULTAT OPUOBS (i) — OPUÉVAL (j) RESULTAT
OPU (n) OPU (n)
OBJET OBJET
=> Identification, nombre
DESCRIPTION DESCRIPTION
RESULTAT RESULTAT

Méthodes conceptuelles manipulées au niveau sémantique

M-SEMOBS (i) M-SEMÉVAL (j)
BUT BUT
M-SEMOBS (i) — M-SEMÉVAL (j)
RESULTAT RESULTAT
PROCEDURE PROCEDURE
=> Identification, nombre

Figure V.21 : Comparaison des éléments de représentation (cas de l’utilisation de CLG)

Pour l’application qui illustre ce chapitre, une analyse manuelle à partir des exemples présentés a été effectuée.
Cette vérification met en évidence que les recommandations préconisées lors de l’évaluation à l’issue des
spécifications fonctionnelles n’ont pas toutes été prises en compte. Ainsi, les principales tâches de surveillance du
procédé (cellules fabrication et solvant) sont représentées sur une vue principale et chaque tâche correspond à un
écran spécifique détaillé. Une présentation synthétique des informations du procédé complet est prévue, a priori sous
la forme d’une “pseudo vue étoile”. Mais la tâche de communication avec les opérateurs sur le site n’a toujours pas
été prise en compte et la supervision de la température du mélange ne permet pas la reprise en main de la régulation
(en cas de palier important). De plus on constate que l’interface proposée ne permet pas un réel contrôle supervisé du
procédé. En effet, aucune fonctionnalité de commande sur le procédé n’est présente sur les premières propositions
d’imagerie.

En ce qui concerne les opérations conceptuelles et les méthodes du niveau sémantique, celles-ci décrivent
comment l’homme (opérateur) et la machine (système) communiquent. En comparant OBS et ÉVAL, on constate que les
mêmes opérations d’interaction se retrouvent dans les deux descriptions. Elles correspondent à un dialogue classique
homme-machine avec écran et pointeur que l’on retrouve dans la majorité des interfaces, c’est sans doute pour cela
que les concepteurs comme les évaluateurs ont choisi ce mode d’interaction. Notons à ce sujet que ce n’est pas
toujours le mode d’interaction “en vogue” qui donnera les meilleurs résultats (voir une étude comparative de Tullis
 Chapitre V 118

93, avec 7 modes de dialogue différents pour une tâche données).

L’opération système d’affichage du modèle observé est conditionné par le caractère visible ou non de l’objet à
afficher. Certaines informations ne seront donc pas toujours présentées à l’opérateur ; dans ce cas, il n’y aura pas de
retour informatif immédiat. Ce caractère optionnel d’accès à certaines informations est flagrant dans les descriptions
des méthodes (on s’en rend bien compte avec M-SEM13, figure V.20). Avec l’interface conçue, les opérateurs
devront, dans certains cas, aller chercher les paramètres du broyeur dans des vues de détail nécessitant plus
d’opérations d’interaction.

III.3. Phase E3 : Évaluation a priori de l’utilisabilité de l’interface

(conçue)

La représentation issue des phases précédentes correspond à une approximation de l’interaction homme-machine
lors de l’utilisation de l’interface finale ; son évaluation dans la phase E3 permet d’estimer son utilisabilité. Les
critères d’évaluation à estimer à ce niveau sont (Cf. figure IV.20, chapitre précédent) : l’incitation, le retour informatif
immédiat, les actions minimales et la charge mentale, les actions explicites et le contrôle utilisateur correspondant au
contrôle explicite du dialogue, la flexibilité et l’expérience de l’utilisateur rassemblés dans l’adaptabilité de
l’interface, la correction des erreurs, l’homogénéité et la compatibilité.

Rechercher, valider et proposer des méthodes d’estimation de ces critères constitue une de nos perspectives de
recherche (quelques pistes sont données en annexe D). Nous nous contentons ici de discuter d’une “erreur”
ergonomique relative au critère de retour informatif immédiat, qui peut être facilement mise en évidence par une
analyse de la description CLG. Cela montre bien que certains aspects élémentaires de l’interaction homme-machine
peuvent être évalué à partir d’une description formelle.

Le retour informatif immédiat s’intéresse aux réponses de la machine après des actions de l’utilisateur (temps le
plus court possible), chaque action utilisateur est visualisée en réponse à son attente. Il n’est pas à négliger car ce
retour a des incidences sur la confiance et la satisfaction de l’utilisateur, ainsi que sur la compréhension du dialogue.
Comme ce critère concerne directement l’interaction homme-machine, il peut être estimé grâce aux opérations
système (OPS) et utilisateur (OPU), et aux méthodes sémantiques décrites. Dans ce cas, il faut vérifier que les OPS
engendrent bien un retour vers l’homme, et que les OPU obtiennent toujours une réponse de la machine sous forme
d’un résultat visible. D’après les descriptions CLG, cela ne sera pas toujours le cas.

En effet, dans le cas de l’imagerie conçue, pour ne pas surcharger les vues, les concepteurs ont choisi d’afficher
seulement les éléments qui apportent des informations sur l’état de l’objet à afficher. Ainsi, un élément de la station de
mélange qui n’est pas en fonctionnement, n’est pas affiché sur l’écran : par exemple, une vanne à l’état fermé est
visible alors que son état ouvert n’est pas représenté. De la même manière, le couple broyeur ne sera affiché que si
celui-ci est en fonctionnement. Les concepteurs ont décidé que seuls les éléments ne changeant pas d’état pendant la
fabrication restent toujours à l’écran (trémies, bascules, broyeur et cuve de mélange). Cette propriété des objets à
afficher est indiquée dans la description de l’opération conceptuelle qui gère l’affichage des informations interactives
sur l’écran (OPS-afficher) grâce à l’opérateur VISIBLE-SI, qui correspond à l’état de fonctionnement de l’objet.

L’analyse des méthodes conceptuelles CLG qui décrivent les procédures opérateur pour réaliser une tâche au
moyen de l’interface contribue donc à l’estimation de ce critère. Le retour informatif immédiat implique que chaque
opération utilisateur soit associée à une réponse rapide du système. Il faut donc que les objets manipulés par chaque
opération soient définis de façon explicite et qu’un résultat visible soit décrit. Par exemple l’opération OPS-afficher
manipule bien une ENTITE dans une PLACE de l’écran, mais d’une part, le résultat n’est pas défini de façon
explicite, et d’autre part celui-ci ne sera pas toujours visible puisque conditionné par son état de fonctionnement.

III.4. Conclusion sur l’évaluation de la conception préliminaire

Les remarques issues de l’évaluation a priori permettent de constituer un document de recommandations qui
doivent être prises en compte pour ajuster la conception. Les principales recommandations de “re-conception” sont les
suivantes :
 Chapitre V 119

• Tous les écrans doivent contenir “un contexte” représentant le cheminement réalisé par l’opérateur dans
l’accomplissement de sa tâche, et concernant l’état d’évolution du procédé.

• Des fonctions de correction des erreurs doivent être prises en compte, spécifiées puis conçues, comme pour la
prise en compte des niveaux de l’expérience des utilisateurs

• Tous les boutons doivent être nommés suivant une même logique. Il serait préférable d’utiliser des verbes car
ceux-ci traduisent des actions de l’utilisateur.

• Enfin, les écrans correspondant aux buts élémentaires et donc à l’activité de l’utilisateur ne font apparaître
aucune fonction de commande, Par exemple, l’écran “cellule-fabrication” comprend un lexique de fonctions
élémentaires très succinct qui ne propose que des actions liées exclusivement au dialogue avec l’interface.

Ce dernier point nous incite à remarquer que l’interface développée se contente de visualiser sans autoriser le
contrôle/commande (c’est pourtant ce qui a été demandé dans le cahier des charges). Par exemple, si l’opérateur doit
intervenir sur la régulation d’un paramètre visualisé sur une des vues, aucune fonction n’est mise à sa disposition.
Cette lacune grave de la maquette incite fortement, d’une part à revoir chacun des écrans correspondant aux buts
élémentaires de la description hiérarchique des tâches vue lors de l’étape de spécifications fonctionnelles, et d’autre
part à prévoir des fonctions permettant à l’opérateur de vraiment superviser la fabrication —dans le sens défini au
chapitre I : surveillance et contrôle supervisé.

Cette dernière remarque est issue de la description CLG des écrans. Or elle concerne une lacune au niveau de la
description conceptuelle des tâches de l’opérateur de supervision. Ce problème n’a en fait pas été détecté par
l’évaluation du modèle a priori lors des spécifications fonctionnelles, en raison du fait que les informations relatives
aux fonctionnalités offertes à l’utilisateur ne sont pas décrites au niveau conceptuel, mais seulement au niveau
sémantique. Cet état de fait peut conduire à remettre en cause le modèle de description qui a été utilisé lors de l’étape
précédente de développement, car il n’incite pas à décrire les tâches en termes de fonctions, soit à remettre en cause le
contenu de la description qui a été faite.

Après avoir mis en œuvre la démarche proposée, il s’agit maintenant d’en tirer des enseignements, pour envisager
des perspectives d’utilisation dans un environnement complet d’évaluation. Dans la partie suivante, la validité de la
démarche d’évaluation a priori est discutée en soulignant quelques difficultés de mise en œuvre. Un ensemble de
perspectives d’évolution de notre travail y sont aussi introduites.

IV. B ILAN ET PERSPECTIVES DE RECHERCHE

La démarche d’évaluation a priori a été appliquée sur un cas de laboratoire. Cette pré-validation donne de premiers
résultats prometteurs concernant la validité d’une approche analytique d’évaluation. Il apparaît néanmoins plusieurs
difficultés déjà soulignées tout au long de la mise en œuvre et dont certaines font l’objet de nos perspectives de
recherches.

IV.1. Difficulté d’une démarche d’évaluation participative

Une des originalités de notre proposition vient du fait que l’évaluation est réalisée à chaque étape du
développement. Il faut bien se représenter l’évaluation a priori comme faisant partie entière du développement de
l’IHM et non comme étant la dernière étape du développement. Dans ce cas, l’équipe de développement doit-elle
“arrêter” de concevoir pour évaluer ou doit-elle attendre les résultats de l’évaluation pour passer à l’étape suivante ?

Dans le cas d’étude présenté, l’équipe de développement était composée de deux groupes de travail : l’un
travaillant sur la spécification-conception de l’imagerie, l’autre sur l’évaluation des données fournies. Il s’avère
qu’après que les concepteurs aient fourni le dossier de spécification, ils ont commencé l’étape suivante de conception
préliminaire sans attendre les résultats de
 Chapitre V 120

l’évaluation (Cf. la non prise en compte de certaines recommandations). Ceci s’explique par le fait que, avec la
démarche proposée, les évaluateurs attendent le dossier complet de spécification, leur permettant de réaliser le modèle
OBS pour commencer une première boucle d’évaluation. Les résultats de leur évaluation ne sont donc pas toujours
disponibles rapidement en entrée de l’étape suivante. De plus, lorsque les recommandations sont proposées, celles-ci
risquent de remettre en cause un certain nombre de données déjà spécifiées ou conçues. Avec la démarche proposée, il
est donc primordial d’attendre l’aval des évaluateurs pour commencer l’étape suivante.

Pour pallier cette lacune, les deux équipes doivent travailler en étroite collaboration dès l’initiation du projet afin
que les concepteurs fournissent des données au fur et à mesure du développement. Dans ce cas, la démarche
d’évaluation se situe dans une approche participative de développement des systèmes hommes-machines (Le
Strugeon, Grislin et al. 95 ; voir aussi l’analyse de l’activité en conception participative de Garrigou et al. 95). Elle
constitue une démarche parallèle au sens de Senach, mais avec des points de rencontre lors des phases d’évaluation.
Notons que cette collaboration entre les différents intervenants du développement ne doit pas se limiter au concepteur
et aux évaluateurs. Comme nous l’avons souligné dans le premier chapitre d’autres groupes de travail sont aussi
concernés, avec en priorité les opérateurs qui comme utilisateurs de la machine sont très largement concernés par
l’évaluation.

Nous avons souligné les deux visions du développement : celle du concepteur et celle de l’évaluateur. Dans le cas
d’une démarche en étroite collaboration, il peut être judicieux de développer l’IHM en suivant directement la
démarche a priori proposée ; on peut donc disposer dans ce cas tout de suite d’une interface qui prend en compte
l’opérateur. En effet, le canevas théorique COSÉSYL introduit un cadre pour la formalisation des tâches et sur cette
base, poser les bonnes questions pour la formalisation.

IV.2. Difficulté du principe d’évaluation basée sur une modélisation

Le principe de la démarche basé sur une comparaison de deux modèles est sujet à quelques difficultés. La
modélisation est issue d’un ensemble de données spécifiques à l’application visée, et de données générales que l’on
retrouve dans le modèle de conception. Comme nous l’avons souligné dans le chapitre I (§III.1), la construction et la
validation des modèles utilisés constituent les principales sources de difficulté pour une bonne évaluation.

Outre la difficulté de modéliser l’interaction homme-machine, la première phase de la démarche qui réside dans le
choix d’un modèle formel prédictif pour modéliser l’interface, soulève une difficulté lors de sa mise en œuvre. En
effet, les limitations du modèle choisi risquent de se retrouver dans la description qui a était faite de l’interface.
L’évaluation sera alors réalisée sur un modèle, plus ou moins erroné, de l’interaction homme-machine, ce qui peut
mettre en cause une partie des résultats. De plus, l’interface elle-même et les aspects à évaluer peuvent influencer le
choix du modèle ou de la méthode de modélisation. C’est pour pallier ces limitations que nous avons proposé une
classification selon un canevas qui se veut détaché du contexte à évaluer.

Concernant la représentativité des modèles, ceux proposés sont issus des recherches en communication homme-
machine et sont donc a priori adaptés à la représentation de l’interaction. Leur validité reste à prouver à l’usage et
surtout pour des applications complexes (dans notre cas le contrôle de procédé industriel). Des recherches sont encore
à effectuer pour affiner ces modèles, l’objectif n’étant pas de proposer une solution “universelle”, mais plutôt des
méthodes et outils de description fiables, adaptés à l’évaluation analytique et surtout utilisables pour des systèmes
industriels de supervision.

Il s’avère que l’utilisation du modèle CLG pour décrire une interface de contrôle de process n’est pas facile ; il
faudrait utiliser un formalisme plus “rigide” et surtout disposer de “recette” pour savoir quelles informations il faut
aller chercher, comment les recueillir pour être sûr de ne rien oublier. De plus, CLG donne trop de liberté à l’analyste
pour choisir son vocabulaire et les opérateurs utilisés dans la description. L’exemple d’application présenté dans ce
chapitre montre bien la lourdeur du formalisme et le temps passé à décrire les deux modèles OBS et ÉVAL de
l’interaction homme-machine. C’est pourquoi, il faut chercher un compromis entre la rigueur de l’évaluation et le coût
résultant.
 Chapitre V 121

Dans ce but d’optimiser à la fois la phase de modélisation et le modèle, le formalisme doit pouvoir être réutilisable
(ou traduisible) lors des étapes suivantes du développement ; cela pour éviter de devoir redécrire l’interaction dans un
formalisme différent à chaque niveau. De plus, la possibilité d’implémenter l’IHM directement à partir de la
description qui en a été faite permettrait d’une part de diminuer les erreurs d’interprétation faites par le développeur
informaticien, et d’autre part de diminuer le temps de programmation (voir la classification des techniques utilisées
pour la spécification d’UIMS de Voegtlin 91, et l’état de l’art sur les outils de génération d’interface de El Mrabet 91).

Tout au long de ce mémoire, nous nous sommes attachés à remonter l’évaluation le plus haut possible dans le cycle
de développement des systèmes industriels, ce qui nous a conduit à une démarche a priori, mais n’oublions pas qu’une
fois l’interface réalisée, l’évaluation continue. C’est pourquoi nous discutons maintenant d’une démarche d’évaluation
analytique a posteriori, qui constitue une de nos perspectives de recherche.

IV.3. Démarche analytique d’évaluation a posteriori

Puisque la démarche a priori s’intéresse à l’utilisation des approches basées sur la modélisation de l’interaction
homme-machine lorsque l’interface n’existe pas encore, ne pourrait-on pas utiliser la même démarche lorsque
l’interface existe ? C’est-à-dire chercher à évaluer de manière analytique une fois l’interface conçue.

Dans ce cas, lors des étapes ascendantes de réalisation-validation du cycle de vie en V —qui constituent une phase
d’évaluation proprement dite—, nous proposons d’utiliser les trois approches introduites dans le mémoire : (1) basées
sur l’utilisateur, (2) basées sur une expertise et (3) analytiques basées sur une modélisation de l’IHM. Les approches
(1) et (2) correspondent en fait aux approches habituellement utilisées dans le domaine de l’évaluation ; l’évaluation
“analytique” (3) consisterait alors à comparer une description de l’interface réalisée avec les informations issues de la
phase descendante de spécification-conception correspondantes, selon l’état d’esprit de la démarche en U du LAMIH
(cf. Chapitre I, § II.3) : comparaison du modèle a priori des tâches, défini dans la phase descendante de conception, au
modèle a posteriori de l’activité, réalisé lors de la phase ascendante d’évaluation

L’originalité de cette proposition résiderait dans l’utilisation des modèles formels prédictifs et linguistiques pour
évaluer l’IHM réalisée. La démarche d’évaluation a posteriori serait analogue à celle a priori : les trois phases notées
E1*, E2* et E3* seraient appliquées, et une phase d’évaluation empirique (Ee*) leur serait associée (fig. V.22).

Exploitation Maintenance, IHM validée

Recette & validation, Intégration Évaluation a posteriori de l'IHM
d Élaboration des corrections
modèle A PRIORI c
Spécif.
ou fctelle
validation
a Phase E1* Phase E2* Phase E3*
IHM
ou Modélisation
ou
b Évaluation
Concepθ Tests
a posteriori Évaluation analytique de
ou prélim. intégration
de IHM analytique de l'utilisabilité de
ou
ou l'utilité de l'interface
Concepθ Tests l'interface
détaillée unitaires
Ee* Évaluation empirique et experte de l'IHM
plans :
- de validation,
- d'intégration,
- de réalisation des tests CO Modèles CO Techniques CO Positionnement
SÉ formels SÉ de recueil SÉ des critères
SY prédictifs SY SY ergonomiques
L de tâche L L

Figure V.22 : Démarche d’évaluation analytique a posteriori

 Chapitre V 122

E1* Modélisation a posteriori de l’interface homme-machine. Cette phase consisterait à construire le modèle
OBS* de l’interface effectivement implémentée (a sur la figure). Le modèle ÉVAL* correspondrait au modèle A
PRIORI de l’interaction homme-machine construit lors de la phase E1 d’évaluation correspondant à l’étape
descendante de développement en vis-à-vis (c sur la figure).

E2* Évaluation a priori de l’utilité de l’interface. Cette phase consisterait à comparer le modèle OBS* construit
lors de l’étape E1* avec le modèle A PRIORI construit dans la phase descendante.

E3* Évaluation a priori de l’utilisabilité de l’interface. Comme pour la démarche a priori, cette phase consisterait
à évaluer l’utilisabilité de l’interface au moyen des critères ergonomiques concernés par l’étape en cours.
Certains des modèles dits de qualité pourraient aussi être utilisés lors de cette phase. En effet, ceux-ci
n’estiment pas exactement des critères ergonomiques, mais des propriétés que doivent respecter les IHM. Ils
s’intéressent davantage à la qualité physique de l’IHM qu’à l’activité de l’utilisateur, ces modèles de qualité
pourront donc être classés par rapport au modèle COSÉSYL suivant le même principe que pour les modèles
formels prédictifs.

Ee* Évaluation empirique et experte de l’IHM. Puisque à ce niveau du développement l’interface est maintenant
réalisée, les techniques issues des approches basées sur les utilisateurs (si ceux-ci sont disponibles) sont
utilisables pour l’évaluation a posteriori (b sur la figure). Cette évaluation empirique et experte serait réalisée
en parallèle à la démarche que nous proposons.

Ces quatre phases constituent une toute première proposition qu’il faudra affiner par des travaux de recherches
supplémentaires, et par des applications concrètes. Nous discutons ci-dessous du principe global qui pourrait être
adopté.

Selon le principe du cycle en V décrit dans le chapitre I et détaillée en annexe A, dans chaque étape ascendante, on
exploiterait toutes les informations issues des étapes de spécification-conception en vis-à-vis. Ces données concernent
d’une part les plans de réalisation des tests unitaires, d’intégration et de validation qui explicitent le déroulement de
l’étape. La démarche d’évaluation a posteriori utiliserait en plus les informations sur l’interaction homme-machine
définies a priori dans les phases E2 descendantes de la démarche d’évaluation a priori (c sur la figure). De plus,
comme le processus d’évaluation a pour but d’évaluer l’interface et de la valider, il déboucherait sur des corrections
qui nécessitent de retourner à l’étape de même niveau (d sur la figure). Dans le cas de notre démarche a posteriori, les
corrections seraient plus facilement re-exploitables dans les étapes de spécification-conception puisque déjà en partie
formalisées à partir du modèle A PRIORI.

Le principe de la démarche, consistant à diviser le cycle de développement en couches correspondant aux niveaux
d’abstraction du canevas COSÉSYL, serait toujours valable ici. Ainsi, à chacune des étapes d’évaluation, un modèle de
l’IHM serait construit au moyen d’une technique utilisable au niveau concerné.

• Lors des tests unitaires, l’activité réelle de l’opérateur serait modélisée à l’aide de descriptions formelles
adaptées à la syntaxe et au lexique du dialogue homme-machine.

• Lors de l’intégration, l’interface serait décrite en termes d’entités et de fonctions, à l’aide d’un modèle formel
utilisable au niveau sémantique.

• Enfin pour la validation, l’organisation de l’IHM serait décrite en terme de tâches ou de concepts.

Comme pour la démarche a priori, l’évaluation analytique de l’interface nécessiterait la construction d’une
représentation de l’interaction homme-machine. Cette représentation pourrait se baser sur l’utilisation des approches
fondées sur la modélisation en fonction du niveau concerné (voir le premier positionnement de la figure V.23). Par
exemple, au cours de l’étape des tests unitaires, l’aspect physique d’utilisation des dispositifs d’entrée-sortie et la
définition du dialogue
 Chapitre V 123

entre l’homme et la machine sont décrits. Parmi les modèles étudiés dans ce mémoire, trois d’entre eux semblent
être utilisables pour créer la représentation dynamique de l’activité de l’opérateur à ce niveau : KLM, les réseaux de
Petri et le modèle CLG, ce qu’il faudra confirmer lors de nos recherches futures. De la même manière que pour la
démarche à priori, l’analyse du modèle doit mettre en évidence les lacunes de l’IHM et engendrer les modifications
nécessaires. Notons de plus que le choix de la méthode de description sera sans doute guidé par le choix qui a été fait
lors de la phase descendante correspondante. En effet, pour comparer le modèle OBS* (de l’interface obtenu) avec le
modèle A PRIORI correspondant à l’étape de même niveau, il faut que les deux formalismes soit identiques. Bien
entendu, les positionnements de la figure V.23 devront être validés sur des cas concrets.

Traces
Arbre des écrites du travail
causes
Recueil
Incidents de l'expertise
critiques
Questionnaires
Mouchard électronique PHASE ASCENDANTE
HTA Cognitive walkthroughs DU CYCLE DE VIE
GOMS-KLM Tactiques visuelles Groupe de discussion
EnregistrementEstmation
vidéo Prototypage Expertise humaine
DIANE de la Grille
MAD Analyse des protocoles Banc
charge de travail d'essai finald'évaluation
niveau Exploitation Maintenance,
ALG
SADT-Petri CLG d'abstraction Recette & validation
Intégration
TAG

Conceptuel Validation

IHM Evaluation
GOMSSADT a posteriori

Sémantique Tests d'intégration

? sous- Evaluation
systèmes a posteriori

Syntaxique Tests unitaires

? et éléments Evaluation
KLM Petri Lexical d'IHM a posteriori

Approches basées Approches basées sur Approches basées sur

sur une modélisation les utilisateurs une expertise

Figure V.23 : Premier positionnement des techniques dans le canevas COSÉSYL,

pour l’évaluation a posteriori

Puisque maintenant l’interface existe, les méthodes issues des approches basées sur les utilisateurs et sur une
expertise sont utilisables à la fois pour l’évaluation, et pour recueillir des données à intégrer dans chaque modèle
(Kolski et Grislin 95 ; Grislin et al. 95a).

Nous conclurons nos perspectives sur un environnement global d’évaluation basé sur les principes introduits, et
prenant en compte les méthodes et techniques étudiées tout au long de notre travail de recherche.

IV.4. Environnement global d’évaluation des IHM industrielles

En guise de synthèse, il est maintenant important de situer, par rapport aux différentes étapes d’un cycle de
développement de système interactif, l’ensemble des méthodes et techniques recensées (fig. V.24). Ainsi, il apparaît
d’abord que les approches empiriques, les méthodes d’estimation de la charge de travail et les méthodes basées sur
une expertise humaine ou papier auront énormément d’importance dès l’analyse des besoins si une ou plusieurs
situations de référence peuvent être analysées.
 Chapitre V 124

Analyse des Tests

besoins d'acceptation
Spécification Tests du
fonctionnelle système
Conception Tests
globale d'intégration
Conception Tests
détailllée unitaires

Codage

Approches empiriques
Estimation de la charge de travail
Tests de conceptionavec situation de référence
Banc d'essai final
Expertise humaine ou papier
CLG, KLM, Petri
Modèles formels prédictifs
EMA
Evaluation automatique des affichages
UIMS
Génération automatique des affichages

démarche a priori démarche a posteriori

Figure V.24 : Positionnement des méthodes et techniques d’évaluation dans le cycle en V
(Grislin et al. 95b)

Comme nous l’avons précisé tout au long du mémoire, l’évaluation peut rejoindre la conception, et ceci dans les
phases amont du cycle de vie. Ainsi, par la suite, de l’étape de spécification fonctionnelle à celle de codage jusqu’aux
tests d’intégration, des tests de conception peuvent être mis en œuvre. C’est tout au long de ces étapes que devraient
apparaître progressivement des systèmes de génération automatique tels que nous les avons décrits (chapitre III),
prenant en compte les caractéristiques des tâches humaines à effectuer, puis l’activité réelle de l’opérateur. Si l’on se
focalise sur l’étape de spécification fonctionnelle, les modèles formels prédictifs y prennent de plus en plus
d’importance. On peut de plus leur associer une expertise humaine ou papier. Pour certains modèles actuels (tel CLG),
l’étape de conception globale est également concernée.

Dans l’état actuel des recherches, les systèmes d’évaluation automatique (hors-contexte d’utilisation de l’IHM) se
situent aux étapes de conception détaillée/codage/tests unitaires. Ils devraient à terme progressivement remonter dans
les étapes supérieures en prenant en compte les tâches humaines. Notons à ce sujet le système EMA (Balbo 94) encore
à l’état de maquette mais qui va dans ce sens en prenant en compte les tâches humaines.

Lorsque le système est réalisé, il est possible de l’évaluer par banc d’essai final. Il est également possible d’utiliser
les approches empiriques, les méthodes d’estimation de la charge de travail et l’expertise humaine ou papier dans une
démarche d’évaluation a posteriori, qui ont déjà été citées pour l’analyse de situations de référence.

Sur la figure V.24, on s’aperçoit que des méthodes et techniques peuvent répondre potentiellement aux besoins de
l’équipe d’évaluation pour toutes les étapes du cycle de développement. Pourtant, la réalité est toute autre. Quand elles
sont utilisées lors d’un projet, c’est ponctuellement, de manière non systématique, et pas toujours au moment le plus
adéquat, et souvent sans couvrir l’ensemble des critères liés à l’utilité et à l’utilisabilité. C’est pourquoi nous
conclurons cette partie par la proposition d’un environnement d’évaluation qui prendrait en compte l’ensemble des
principes introduits dans ce mémoire pour commencer l’évaluation dès le début du développement d’une IHM (fig.
V.25).
 Chapitre V 125

Système Système
à évaluer évalué

ÉVALUATION
DE L'IHM

Méthodologie d'évaluation des IHM

Palette de techniques 3 DÉMARCHE D'ÉVALUATION
adaptée à la situation
déterminants du système
propriétés à évaluer, A PRIORI A POSTERIORI
• dynamique, 2
• classification,
1 contraintes, objectifs
ou E1*
Choix E1
• pertinence, E2* E3*
• formation, E2 E3
• expérience opérateurs Grille de classification
• ... critères - techniques - Ee*
contraintes contraintes
expérimentales
état des Liste de critères Batterie de
besoins CO
d'évaluation techniques d'évaluation Evaluation
conséquences de
Méthodes SÉ Critéres
SY
l'évaluation sélection / adaptation sélection / adaptation L 4
au contexte au contexte méthodes

critères connaissance
techniques ergonomique
d'évaluation d'évaluation
ÉTUDE CRITIQUE ÉTUDE CRITIQUE

Figure V.25 : Vers un environnement d’évaluation des IHM

L’environnement global qui pourra être adopté passe par quatre modules principaux, décrit ci-dessous.
L’intégration de ces modules qui reprend l’ensemble des principes, méthodes et techniques d’évaluation énoncées
dans le mémoire pourrait conduire ensuite vers la spécification puis la réalisation d’un atelier logiciel dédié évaluation
des IHM.

1 Le premier module consistera en une analyse des déterminants du système. En effet, la démarche d’évaluation
à adopter est très dépendante du système à évaluer ; elle peut être fonction, entre autres de : la dynamique et la classe
du procédé, la pertinence d’une évaluation globale ou spécifique à certains aspects ciblés de l’interaction homme-
machine, du niveau de formation et de l’expérience des opérateurs, etc. Ce premier audit des caractéristiques du
système homme-machine et de son environnement socio-technique doit permettre de mieux connaître les contraintes
expérimentales, l’état des besoins (production, qualité, convivialité, …), et les conséquences de l’évaluation.

Ce premier module devrait permettre de définir les propriétés à évaluer, de mettre en évidence les contraintes
spécifiques de la situation, et de définir les objectifs de l’évaluation.

2 A partir de la définition des critères et méthodes d’évaluation un second module devra permettre de choisir
les critères et les méthodes ou techniques applicables à cette situation. Pour cela une grille de classification des
critères par rapport aux techniques doit être utilisée. En entrée de cette grille, on pourra trouver l’ensemble des
contraintes “technologiques” des méthodes ou techniques utilisables et de la situation à évaluer, la liste des critères
ergonomiques d’évaluation, ainsi qu’une batterie de méthodes et/ou techniques d’évaluation utilisable dans le
domaine concerné.

D’autres dimensions peuvent aussi être prises en compte dans la grille, voir par exemple les axes proposés par
Balbo (94) : les moyens humains, les ressources matérielles, les connaissances requises, les facteurs situationnels, et la
 Chapitre V 126

nature des résultats fournis. Nous avons initié un travail dans ce sens lors de notre travail de recherche par une
première étude critique des critères et des techniques d’évaluation (Grislin et al. 93). A notre avis, celui-ci constitue un
sujet à part entière qui mérite d’être prolongé dans des perspectives proches.

En sortie de ce module de choix, on devrait déboucher sur une palette des méthodes et techniques adaptées à la
situation à évaluer tout au long du cycle de développement de l’interface homme-machine.

3 Après ce choix du “comment évaluer” en fonction de la situation et selon l’étape de développement en cours,
le module suivant s’intéressera ensuite à l’évaluation analytique proprement dite soit de l’interaction homme-machine
pour la démarche a priori, soit de l’IHM réalisée pour la démarche a posteriori. De la même manière que pour la
démarche expliquée dans ce mémoire, cette évaluation analytique sera basée sur les classifications des méthodes et
des critères d’évaluation, adaptée à la situation à évaluer, autour du canevas COSÉSYL proposé.

Bien entendu, comme nous l’avons souligné précédement, la démarche d’évaluation a priori pourra aussi être
directement utilisée pour spécifier, concevoir l’IHM en complément des méthodes classiques de conception.

4 Enfin, le dernier module concernera les résultats de l’évaluation qui doivent d’une part reboucler sur le
développement, et d’autre part apporter des informations sur l’utilisation des méthodes d’évaluation. Cela permettra,
d’une part d’enrichir la connaissance ergonomique, et d’autre part d’identifier les critères et les techniques
d’évaluation adaptées aux différentes situations rencontrées.

Un objectif global de la recherche dans le domaine serait donc de s’orienter vers des démarches d’évaluation
positionnées tout au long du cycle de vie. Notons que d’autres cycles étendant les plus connus du génie logiciel sont
actuellement envisagés. Par exemple, Hix et Hartson proposent un modèle en étoile centrant le développement logiciel
sur l’évaluation (Hix et al. 93) ; Kolski propose un modèle appelé ∇ (nabla) explicitant la prise en compte de facteurs
humains lors du développement des systèmes interactifs (Kolski 95).

C ONCLUSION DE LA MISE EN ŒUVRE ET DES PERSPECTIVES DE LA

DÉMARCHE

Ce chapitre a fait office d’étude de faisabilité en montrant qu’il était possible de remonter l’évaluation le plus haut
possible dans le cycle de développement des interfaces homme-machine, dans le cas d’un système industriel de
supervision, tout en offrant un cadre pour l’évaluation a priori.

En faisant intervenir des modèles formels prédictifs lors de la phase descendante du cycle de vie, l’équipe
d’évaluation peut formaliser puis évaluer l’interaction homme-machine dès les étapes de spécifications fonctionnelles,
et de conception préliminaire. La modélisation ainsi obtenue peut permettre d’évaluer, d’une part l’utilité de
l’interface en comparant les modèles OBS (modèle observé) et ÉVAL (modèle de l’évaluateur), et d’autre part son
utilisabilité à l’aide des critères ergonomiques concernés par le niveau de développement en cours. Enfin,
l’élaboration d’un document regroupant des recommandations peut permettre à l’équipe de conception d’améliorer
l’interface.

Dans un contexte idéal, cette description —limitée ici aux spécifications et à la conception préliminaire de l’IHM
— devrait conduire à la conception détaillée puis au codage de l’interface. Or, l’objectif de l’application faisant l’objet
de ce chapitre était de se calquer sur des situations industrielles allant jusqu’à une première ébauche papier de
l’imagerie. C’est pourquoi, la démarche d’évaluation proposée dans ce mémoire n’a pas été utilisée dans sa globalité.
Cette première application de laboratoire constitue donc en quelque sorte une première ébauche de mise en œuvre. De
plus, la phase E3 de la démarche nécessite l’utilisation de “métriques” d’estimation des critères ergonomiques ; celles-
ci sont encore à l’état de perspectives de recherche.
 Chapitre V 127

La première partie de ce chapitre fait donc apparaître plusieurs perspectives de recherches présentées à partir du
paragraphe IV. En premier lieu, l’aspect participatif entre les intervenants du développement incite à utiliser
directement la démarche proposée pour le conception-évaluation de l’IHM autour d’un canevas de description de
l’interaction. En second lieu, on constate que la modélisation de cette interaction n’est pas chose facile, et risque
d’introduire certaines limitations. C’est pourquoi des travaux de recherche devraient permettre l’amélioration des
modèles formels prédictifs actuels. En dernier lieu, nous avons défini un cadre qui étend notre démarche à
l’évaluation analytique a posteriori, une fois l’interface réalisée. En conclusion, un environnement global
d’évaluation tout au long du cycle de développement des IHM a été proposé. Celui-ci peut constituer un début pour la
spécification puis la réalisation d’un atelier dédié évaluation des IHM.

Enfin, et avant toute perspective, il serait primordial d’appliquer la démarche d’évaluation a priori tout au long du
développement d’une IHM industrielle réelle, pour vérifier la validité des principes et des classifications introduits.
Cela constitue une perspective incontournable pour la poursuite et la validation de notre travail. Il faudrait pour cela
s’insérer dans l’équipe de développement dès le début du projet, le suivre dans chacune des étapes et évaluer pas à pas
les propositions.
Conclusion générale
 Dans un objectif général d’étude de la communication homme-machine dans les systèmes industriels de
supervision, nous nous sommes focalisés sur l’évaluation des interfaces entre l’opérateur et la machine qu’il
supervise.

A ce titre, nous avons dans un premier temps, déterminé l’espace de notre travail en présentant les systèmes
homme-machine de supervision, leur cycle global de développement, et en particulier la localisation de l’IHM dans le
cycle en V du génie logiciel (CHAPITRE I). La seconde partie de ce premier chapitre était ensuite consacrée à la
présentation de notre problématique, l’évaluation a priori, et de son environnement.

Les besoins étant identifiés, les chapitres suivants sont consacrés à une réflexion sur les méthodes et techniques
d’évaluation utilisables a priori pour les systèmes industriels de supervision. Ainsi, après une discussion des
différentes situations d’évaluation —interface existante ou inexistante—, nous avons présenté, dans le CHAPITRE II, les
méthodes et techniques usuelles d’évaluation des IHM : celles centrées sur les utilisateurs, et celles centrées sur une
expertise. Cette première analyse des approches classiques plutôt orientées vers l’évaluation d’une interface existante
(ou réalisée), nous a incités à étudier des méthodes et techniques analytiques de conception-évaluation basées sur une
modélisation. Celles-ci ont été présentées dans le CHAPITRE III.

Cette étude s’est terminée par une synthèse de toutes les méthodes et techniques recensées ainsi qu’une discussion
par rapport au principe global de l’évaluation des IHM (chapitre III, §II).

Ces deux chapitres montrent que ce sont surtout des évaluations à tendance empirique qui sont effectuées, et ceci
lors de la phase ascendante du cycle en V. L’interface n’est évaluée que lorsqu’elle a été codée. Aussi, des lacunes
introduites lors des étapes de spécification-conception sont détectées tardivement alors qu’une évaluation a priori les
aurait sans doute décelées plus tôt. C’est pourquoi nous discutons ensuite, dans les CHAPITRES IV et V, de la possibilité
d’une démarche d’évaluation a priori, où l’évaluation des IHM est située dans le développement complet d’un
système industriel de supervision, en la ramenant le plus en amont possible dans le cycle. C’est dans ce cadre de
travail que nous avons analysé les modèles formels de conception-évaluation en montrant leur utilité pour l’évaluation
tout au long du cycle de développement.

Dans le CHAPITRE IV, nous avons tout d’abord exposé le canevas théorique COSÉSYL qui a pour but d’aider à
représenter et à analyser l’interaction Homme-Machine dans les applications industrielles de supervision (contrôle-
commande/supervision de procédé, imagerie industrielle). Ce modèle a pour principe de décrire l’interaction selon
quatre niveaux : le modèle COnceptuel de l’interface qui correspond aux tâches de l’opérateur, la SÉmantique de la
tâche, la définition SYntaxique du dialogue homme-machine, puis sa représentation Lexicale. Un exemple simplifié de
supervision d’un réacteur nucléaire a permis d’illustrer cette architecture.

Enfin une démarche d’évaluation a priori a été proposée et présentée. A partir ou bien des spécifications, ou bien
de données de conception de l’interface future, il s’agit de “mesurer”, de critiquer et surtout de proposer des
améliorations en terme d’utilité et d’utilisabilité.

Puis, dans le CHAPITRE V nous avons présenté la mise en œuvre de notre démarche sur une application de
supervision et des perspectives de recherche. Ce chapitre comprend à la fois la mise en œuvre et les perspectives pour
les deux raisons suivantes :

(i) C’est tout d’abord une première mise en œuvre de la démarche parce que nous avons montré la faisabilité de
l’évaluation tout au long du développement d’une interface de supervision. Certains modèles prédictifs de tâche
et linguistiques ont été utilisés concrètement pour décrire l’interaction homme-machine dans le but de valider
leur utilisation pour l’évaluation (HTA, CLG).
 Conclusion générale 132

(ii) Ce dernier chapitre rassemble aussi des perspectives de recherche parce que d’une part, les principes introduits
dans ce mémoire, à la base de notre proposition (évaluation basée sur une modélisation, démarche a priori,
canevas COSÉSYL), devraient être validés sur un cas réel de supervision industriel ; d’autre part notre travail
devrait entraîner d’autres recherches, voir par exemple les pistes proposées concernant des métriques
d’estimation des critères ergonomiques, la recherche ou l’adaptation des formalismes existants à la description
de l’interaction homme-machine en contrôle de process, les prémisses d’une démarche analytique d’évaluation
a posteriori ainsi que notre dernière proposition d’intégrer l’évaluation dans un environnement global de
développement des IHM.

Rappelons encore que la finalité visée par notre recherche était guidée par la phrase de Senach concernant la prise
en compte de l’évaluation comme “un processus parallèle à la conception […] et qu’une équipe d’évaluation doit
pouvoir utiliser un ensemble d’outils à chaque étape de la vie d’un produit.”.

Avec toujours cet objectif à l’esprit, nous avons tenté de proposer un cadre pour une aide à l'évaluation des
imageries industrielles par l'équipe de développement. L’importance de la prise en compte des facteurs humains lors
du développement de systèmes interactifs a ainsi été soulignée (cf. chapitre I, §II). Il est clair que les chefs de projets
éprouvent des difficultés à chiffrer le coût et le retour d’investissement d’une évaluation ergonomique. A ce sujet,
nous constatons que le rapprochement progressif des recherches en informatique, en automatique, et dans les sciences
cognitives (sur le thème de la Communication Homme-Machine en particulier), ainsi que l’enseignement de
l’ergonomie dans de plus en plus de formations techniques, devraient permettre à terme d’améliorer la situation.

Nous avons aussi souligné l’insuffisance des formalismes et des métriques dans les méthodes d’évaluation utilisées
par les spécialistes de la communication homme-machine (cf. chapitre III, §I.2). En parallèle, on peut insister sur les
limites des systèmes supports à l’évaluation (très peu sont pour l’instant sortis des laboratoires). Bien qu’encore peu
répandus, ces modèles et outils font l’objet d’un courant de recherche important et devraient à notre avis déboucher
rapidement sur des systèmes opérationnels.

Enfin, les méthodes et techniques citées dans ce mémoire sont souvent considérées indépendamment les unes des
autres, et paraissent d’ailleurs pour la plupart rébarbatives aux spécialistes du développement des interfaces dans les
systèmes homme-machine de supervision. Il est clair qu’un travail de mise en cohérence des méthodes et techniques
actuelles devrait être mené, de manière à faciliter leur articulation vis-à-vis des étapes du cycle de vie (cf. chapitre V,
§IV.4).

Malgré son importance, il reste encore un long chemin à parcourir pour que l’évaluation tout au long du
développement entre dans les “us et coutumes”. De nombreux chercheurs s’y attellent depuis plusieurs années.
L’évaluation des IHM constitue donc un domaine de recherche extrêmement riche, en pleine évolution quant aux
méthodes et techniques.
Références bibliographiques

La bibliographie est référencée par auteurs et par année de publication en commençant par la liste des
contributions personnelles. Les chapitres dans lesquels les documents sont cités, sont indiqués par I, II, III, IV ou V,
puis à la suite de la référence complète, quelque mots clés ou un rapide commentaire permet de les situer par rapport à
notre travail, préciser le domaine concerné, et indiquer ce que nous y avons trouvé.

Références personnelles

Revue internationale
GRISLIN M., C. KOLSKI (96) III, IV
Évaluation des Interfaces Homme-Machine lors du développement de système interactif. Technique et Science
Informatiques , N°3, Mars 96, 31 p.
Publication des chapitre II et III dans un article volumineux…, principe de l’évaluation, discussion de l’utilisation des méthodes et
techniques tout au long du cycle de développement des IHM.

Colloques internationaux avec comité de lecture

GRISLIN M., C. KOLSKI, J.C. ANGUE (93) I, IV
Towards an Organization of Man-Machine Interface Evaluation Techniques using a Usability Criteria Grid. XII
European Annual Conference on Human Decision Making and Manual Control, University of Kassel, Kassel, Germany,
June 22-24, pp. 4.6-4.13.
Premier recensement des méthodes et techniques d’évaluation, prise en compte des contraintes d’utilisation relative à la situation à
évaluer.
RIERA B., M. GRISLIN, P. MILLOT (94) II
Methodology To Evaluate Man-Car Interfaces. IFAC/IFORS Transportation Systems: Theory and Application of
Advanced Technology, Tianjin, China, August 24-26, preprints vol II, 459-469.
Evaluation de l’interface en conduite automobile, application de la méthode temporelle et observation des tactiques visuelles dans
un contexte double tâche.
GRISLIN M., C. KOLSKI, J-C. ANGUE (95A) IV
Human-computer interface evaluation in industrial complex systems: a review of usable techniques. 6th
IFAC/IFIP/IFORS/IEA SYMPOSIUM on Analysis, Design and Evaluation of Man-Machine Systems at MIT -
Cambridge, MA USA, June 27-29.
Recensement des méthodes utilisable et discussion des approches analytiques pour l’évaluation des IHM.
LE STRUGEON E., M. GRISLIN, P. MILLOT (95) IV, V
Application of MultiAgent Techniques to the Design of Human-Machine Systems Organizations. 6th
IFAC/IFIP/IFORS/IEA SYMPOSIUM on Analysis, Design and Evaluation of Man-Machine Systems at MIT -
Cambridge, MA USA, June 27-29.
Perspective pour appliquer les organisations multi-agents de l’IAD à la communication H-M.
GRISLIN M., C. KOLSKI (95B) IV
Towards a method combining “a priori” and “a posteriori” HCI evaluation in industrial complex systems. IEA World
Conference 1995/ 3rd Latin American Congress/ 7th Brazilian Ergonomics Congress Conference, Rio de Janeiro, 16-20
octobre.
Proposition de la démarche d’évaluation a priori, prise en compte des techniques a posteriori.

Colloque national sans comité de lecture

KOLSKI C., M. GRISLIN (95) IV
Méthodes d’évaluation des interfaces homme-machine, utilisation a priori et/ou a posteriori. Journée Supervision et
Coopération Homme-Machine, Paris, 12 et 13 janvier.
Recensement des méthodes d’évaluation de la qualité des IHM, et discussion de leur utilisation a priori et/ou a posteriori dans le
cycle de développement d’application de supervision.
 Références bibliographiques 134

Rapports de contrat et de recherche

GRISLIN M. (91) II
Evaluation de la charge de travail d'un Opérateur Humain effectuant une tâche de conduite automobile plus une tâche
secondaire. Mémoire de DEA Automatique Industrielles et Humaine, LAIH Valenciennes, 60 p.
Evaluation de la charge de travail avec la méthode temporelle, mise en œuvre d’un protocole expérimentale dans un contexte
double tâche avec observation des tactiques visuelles.
GRISLIN M., B. RIERA, P. MILLOT, J.C. ANGUE (91) II
Evaluation de la charge de travail d'un opérateur éffectuant une tâche de conduite automobile. Rapport final de contrat
et annexes, convention UV16, LAIH et Direction de la Recherche de Renault.
Description de la méthode temporelle d’évaluation de la charge de travail, experimentation dans un contexte double tâche avec
observation des tactiques visuelles (protocole expérimental, experimentation, résultats).
GRISLIN M., J.C. ANGUE (92A) II, V
Conception, réalisation d'un prototype d'interface pour le poste opérateur-propulseur d'un sous-marin nucléaire.
Rapport de contrat CERTSM/DCN.
Analyse de la tâche d’operateur de conduite de la chaufferie nucléaire, observation en entrainement sur simulateur (vidéo,
questionnaires, auto-confrontation).
GRISLIN M., P. SALAZAR-FERRER (92B) I, IV
Interface homme-machine, imagerie interactive de conduite. Rapport interne de recherche, CERTSM/DFH, Laboratoire
d’ergonomie, DCN Toulon, 40 p.
Mise en évidences des besoins et proposition de nouvelles imageries pour la conduite de la chaufferie nucléaire.

Autres références

ABED M. (90) I, II, III

Contribution à la méthodologie de la tâche de conception par des outils de spécification exploitant les mouvements
oculaires : application à la conception et l'évaluation des interfaces Homme-Machine. Thèse en Automatique
Industrielle et Humaine, Valenciennes, 174 p.
Conception-évaluation d’un système H-M (démarche ascendante-descendante du LAMIH, intervenants, connaissances requises),
description de la méthode de description SADT-Petri pour l’analyse de la tâche.
ABED M., J.C. ANGUE (94) III
A new method for conception, realisation and evaluation of man-machine. IEEE Int. Conf. on Systems, Man and
Cybernetics, San Antonio, Texas, October 2-5, 1420-1427.
Évolution de la démarche descendante-ascendante du LAMIH et de la méthode d’analyse de la tâche SADT-Petri.
ADREIT F., N. OZKAN, V. SENGES, P. VAILLANT (92) I
Ergonomie et méthodes de conception et d'évaluation des IHM. Quatrièmes Journées sur l'ingénierie des Interfaces
Homme-Machine, IHM'92, Telecom, Paris, 30 novembre, 1-2.
Compte-rendu de l’atelier sur la communication homme-machine (conception, évaluation, intervenants…).
AFNOR (89) I
Génie logiciel, recueil de norme française. 1989.
Génie logiciel, les cycles de vie du logiciel.
ALENGRY P. (89) IV
Analyse du travail de pilotage d'une centrale nucléaire : (I) Le système socio-technique, et (II) Les classes de situation.
Rapports de Recherche INRIA n°989 et n°1007, Mars.
Technologie, fonctionnement et conduite de réacteurs nucléaire.
AMALBERTI R., D. BATEJAT, M. BATAILLE, J.C. MENU, G. SANTUCCI (86) III
Charge de travail mental, validation en France d’une technique d’évaluation subjective américaine : SWAT. Rev. Méd.
Aéro. Spat., tome xxv, n° 98, 158-163.
Introduction au concept de charge de travail, méthode subjective d’estimation (SWAT).
ASCHEHOUG F. (91) II, III
La pertinence des modèles et des formalismes de description des interfaces pour l'évaluation ergonomique. Rapport de
Recherche INRIA n°1416, 32 p.
Techniques d’évaluation comme méthodes de description des IHM (pertinence des modèles et des formalismes).
135 Références bibliographiques

BALBO S. (94). I, III

Évaluation ergonomique des interfaces utilisateur : un pas vers l’automatisation. Thèse de l’université de Joseph Fourier,
Grenoble I, 293 p.
Cycle de vie en V, méthodes d’évaluation, proposition d’une demarche automatique d’évaluation.
BALBO S., J. COUTAZ (92) I, II, V
Un pas vers l'évaluation automatique des IHM. ERGO IA'92, 7-9/10/92, Biarritz, France, 367-382.
Classification des techniques d’évaluation en fonction du degré d’automatsation, de le prise en compte de l’utilisateur, et du savoir
utilisé pour l’évaluation.
BALBO S., J. COUTAZ (93) III
Modéles de tâche : analyse comparative, utilité et limitations. IHM’93, cinquièmes journées sur l’ingénierie des
interfaces homme-machine, Lyon, 19-20 octobre, 1131-137.
Discussion des modèles de tâches CLG, TAG, ETAG, UAN, TKS, MAD, GOMS…
BARNARD P.J. (87) III
Cognitive resources and the learning of human-computer dialogs, in Interfacing Thought, J.M. Carroll (Ed.), MIT Press,
pp. 112-158.
Modèle ICS
BARTHET M.F. (88) I, II, III
Logiciels interactifs et ergonomie, Modèles et méthodes de conception. Dunod informatique Paris.
Génie logiciel, démarche pour le développement d’IHM, grille d’évaluation, méthode DIANE.
BASS L., J. COUTAZ (91) I
Developing Software for the user interface. The SEI Series in Software Engineering. Addison-Wesley. (cité par Kolski
93)
Importance du coût de programmation de l’interface /logiciel total.
BASS L., R. LITTLE, R. PELLEGRINO, S. REED, R. SEACORD, M. SZEZUR (91)
The ARCH model: SEEHEIM revisited. User Interface developer’s workshop, CHI’91, april.
Le modéle ARCH de description de l’interaction homme-machine.
BASTIEN J.M.C. (91) I
Validation de critères ergonomique pour l'évaluation d'interfaces utilisateur. Rapport INRIA n°1427.
Utilisation des critères ergonomiques comme descripteurs pour l’évaluation des IHM.
BASTIEN J.M.C., D.L. SCAPIN (93) I
Bastien J.M.C., D.L. Scapin (93) Ergonomic criteria for the evaluation of Human-computer Interfaces. Rapport
Technique INRIA n°156.
Classification des critères ergonomiques d’évaluation, définition de 18 critères élementaires : principes, justifications, exemples,
liens entres critères (version Française et anglaise).
BELKIN N.J., H.M. BROOKS, P.J. DANIELS (87) II
Knowledge elicitation using discourse analysis. Int. J. of Man-Machine Studies, 27, 127-144.
Analyse des protocoles pour l’évaluation des IHM.
BELLOTTI F. (94) III
Utilisation des modèles formels pour l’évaluation des interfaces homme-machine lors du cycle de développement de
systèmes interactifs. Mémoire de DEA en automatique industrielle et humaine, Université de Valenciennes.
Études et comparaison des modèles formels pour l’analyse et l’évaluation des sustèmes interactifs.
BENAISSA M.L. (93) II, III
Une démarche de conception, réalisation et évaluation d’IHM : application au projet ferroviaire ASTREE. Thése en
Automatique Industrielle et Humaine, Université de Valenciennes, 131 p.
Modèlisation par SADT/petri, tactiques visuelles et questionnaire de Ravden et Johnson pour l’évaluation…
BENKIRANE M. (91) II
Contribution à la méthodologie d'extraction de connaissance dans les domaines de diagnostique technique. Thèse en
Automatique Industrielle et Humaine, Université de Valenciennes, 154 p.
Méthodes de recueil de l’expertise… technique du tri conceptuel.
BENSAOULA (87) II
Modèle de description pour l’évaluation de la charge mentale par la méthode de la double tâche. Thèse de docteur-
ingénieur, Université de Saint-Etienne. (cité par Berger 92)
BENYSH D.V., R.J. KOUBEK, V. CALVEZ (93) II
A comparative review of knowledge structure measurement techniques for interface design. Int. J. of Human-Computer
Interaction, 5 (3), 211-237.
Méthodes de recueil de l’expertise.
 Références bibliographiques 136

BERGER T. (91) I, II, IV

Modélisation de la tâche d'un opérateur dans le poste propulsion (PCP) d'un SNA. Rapport DRET contrat n°89-1023
entre LAIH Valenciennes/CERTSM Toulon, 64 p.
Etude des stratégies visuelles lors de la résolution de pannes, analyse de la tâche et de l’activité avec SADT/petri.
BERGER T. (92) II, III
Contribution à l’étude de l’activité cognitive de l’opérateur, et à l’évaluation de sa charge de travail. Thèse en
automatique industrielle et humaine, Université de Valenciennes, 214 p.
Evaluation de la charge de travail, application de la méthode temporelle à différents contextes, comparaison de la tâche prescrite à
l’activité réelle d’opérateur de supervision avec le formalisme SADT/petri.
BERGER T., B. RIERA, J.C. ANGUE, P. MILLOT (89) II
Real time assessment of human operator workload in a simulated multitask context of a monitoring and supervising
process. ESA Workshop Human Factors engineering: a task-oriented approach, 21-23 november.
Evaluation de la charge de travail, application de la méthode temporelle dans différents contextes.
BERNARD J.M. (94) II
Exploitation des mesures oculométriques dans la modélisation de la tâche prescrite et de l’activité réelle des opérateurs
par réseaux de pétri. Thèse en automatique industrielle et humaine, Université de Valenciennes.
BIAS R.G., D.J. GILLAN, T.S. TULLIS (93) II
Three Usability Enhancements to the Human Factors-Design Interface. Proc. of the fifth Int. Conf. HCI’93, Orlando,
Florida, August 8-13, vol 2, Salvendy & Smith (Eds), Elsevier, 169-174.
Technique du mouchard électronique (ou monitoring).
BODJER S., K. GRONBAEK (89) II
Cooperative prototyping experiments - users and designers envision a dental case record system. Proc. of the first EC-
CSCW'89, Bowers & Benford (Eds.), UK, Computer Sciences Company.
Prototypage pour l’évaluation des IHM (tests de conception).
BOEHM B.W. (82) I
Les facteurs du coût du logiciel. Techniques et Scences Informatiques, 1 (1), pp. 5-24, 1982.
Cycle de vie du logiciel (cascade…), coût de développement.
BOEHM B.W. (88) II
A spiral model of software development and Enhancement. IEEE Comp., 21 (5), 61-72, 1988.
Génie logiciel, évolution des modèle de cycle de vie : des “code-and-fix”, “stagewise” et “waterfall”, “evolutionary
development”, “transform” modèles, au modèle en spirale.
BONNARDEL N. (92) I
Le rôle de l’évaluation dans les activités de conception. Thèse de psychologie cognitive, Université d’Aix en Provence,
juillet, 249 p.
Discussion de l’évaluation, utilisation des critères ergonomiques comme descripteurs pour l’évaluation.
BOOCH G. (94) I
Conception orientée objets et applications, 2ème édition, Addison-Wesley.
Génie logiciel, nouvelles méthodes et techniques pour le développement tout au long du cycle de vie…
BROWN C.M. (88) I
Human-Computer Interface Design Guidelines. NJ: Ablex. (cité par Nielsen 93)
Guide des recommandations ergonomiques pour le développement des IHM.
BYRNE M.D., S.D. WOOD, P. SUKAVIRIYA, J.D. FOLEY, D.E. KIERAS (94) III
Automating interface evaluation. CHI'94 Conference Proceedings, Boston, Massachusetts USA, April 24-28, ACM
Press, Addison-Wesley, 232-237.
Evaluation automatique de l’affichage au moyen d’un programme informatique.
CACM (93) I, II
Special issue about Participatory Design. Communication of the ACM, 36 (4), june.
Intervenants pour la conception-évaluation des IHM, démarche participative, groupes de discussion.
CACM (94) III
Special issue about Intelligent Agents. Communication of the ACM, 37 (7), july.
Application des approches multi-agent de l’IAD à la communication H-M.
CARD S., T.P. MORAN, A. NEWELL (83) III
The psychology of human-computer interaction. Hillsdale, NJ: Lawerence Erlbaum Associates.
Proposition des formalisme GOMS pour la description hiérarchique des tâches, et KLM pour la prédiction des temps de
réalisation des tâches élémentaires…
137 Références bibliographiques

CHAMMAM M. (87) II
Contribution à la conception et à la réalisation d’un oculomètre pour la mesure et le traitement automatique de la
direction absolue du regard d’un opérateur humain au travail. Thèse en automatique industrielle et humaine, Université
de Valenciennes.
Etude comparative de techniques de mesure des mouvements oculaires…
CHARDAVOINE R., J.C. LEJON (89) I
SNCC : une technologie mal digérée. Mesures, 31-48, juin. (cité par Poulain 94)
Etude de la communication homme-système de supervision, mise en évidences des problèmes principaux.
CIBOIS P. (87) I
L’analyse factorielle. Que sais-je ? PUF, 2ème édition octobre, Paris.
COHILL A.M., D.M. GILFOIL, J.V. PILITSIS (88) III
Mesuring the utility of application software. Advances in Human-Computer Interaction, Hartson & Hix (Eds.), vol. 2,
Ablex, Norwood, N.J., 1-28.
Utilisation des modèles formels de tâche (GOMS et KLM).
COTE V., J.F. MARTIN, B. COULETTE (93) I
Un modèle paramétrique pour l'évaluation des interfaces personne-système. Software Engineering & Its Applications,
Sixth International Conference, November 15-19, Le CNIT, Paris La Défense, EC2.
Proposition d’une grille paramétrique pour l’évaluation ergonomique des IHM, classification des critères.
COUTAZ J. (90) I, III, IV, V
Interfaces homme-ordinateur : conception et réalisation. BORDAS, Paris.
Démarche de développement des IHM, modélisation de l’interaction H-M en terme d’E/S, modèle PAC.
COUTAZ J., S. BALBO (94) II
Evaluation des interfaces utilisateur : taxonomie et recommandations. Actes des sixièmes journées sur l’Ingénierie des
Interfaces Homme-Machine, IHM’94, 211-218, Lille, 8-9 décembre.
Taxonomie des techniques d’évaluation selon 5 dimensions : moyen humains, ressources materielles, connaissances, facteurs
situationnels, résultats.
CURTIS B., B. HEFLEY (94) I
A Wimp no more, the maturing of user interface engineering, Interactions, ACM, january, 22-34.
Génie logiciel, nouvelles méthodes et techniques pour le développement tout au long du cycle de vie…
DANIELLOU (86) I
L'opérateur, la vanne; l'écran : l'ergonomie dans les salles de contrôle. Montrouge, ANACT- Outils et Méthodes.
Démarche pour le développement d’IHM.
DE KEYSER V. (80) I
Etude sur la contribution que pourrait apporter l’ergonomie à la conception des systèmes de commande et d’alerte dans
des industries de transformation. Luxembourg. Rapport S/79/45, vol. 1 et 2.
Recommandation sur le présentation des informations sur écran.
DE LADONCHAMPS J., J.J. VERDEAU (72) IV
Réacteur nucléaire à eau pressurisée. Théorie, Technologie et application à la propulsion navale. Masson (Ed.).
DEBERNARD S. (93) I
Contribution à la répartition dynamique des tâches entre opérateur et système automatisé : application au contrôle du
trafic aérien. Thèse en automatique industrielle et humaine, Université de Valenciennes.
Démarche de conception-évalution d’un système homme-machine, Répartition dynamique des tâches (H-M).
DENNING P.J, P.A. GARGAN (94) I
A disipline of software architecture. Interactions, ACM, january, 55-65.
Génie logiciel, nouvelles méthodes et techniques pour le développement tout au long du cycle de vie…
DIENG R. (90) II
Méthodes et outils d'acquisition des connaissances. Rapport de Recherche INRIA n°1319, 32 p.
DUGUE D., M. GIRAULT (69) I
Analyse de variance et plans d’expérience. Dunod.
DUNCAN K.D. (81) III
Training for fault diagnosis in industrial process plant. Human Detection and Diagnosis of System Failures, Rasmussen
& Rouse (Eds.), Plenum Press, New-York.
Description hiérarchiques des tâches avec le modèle de tâche HTA…
 Références bibliographiques 138

DURIBREUX M. (95) II
Approche méthodologique et interactive de développement de systèmes à base de connaissances : la méthodologie
MODESTI. (titre provisoire) Thèse en automatique industrielle et humaine, Université de Valenciennes.
EASON K.D. (84) I
Towards the experimental study of usability. Behaviour and information technology, 3 (2), 133-145. (cité par Senach 90)
proposition du concept “d’utilisabilité” (usability) pour rendre compte de la qualité de l’interaction H-M.
EL FAROUKI L., D.L. SCAPIN, S. SEBILLOTTE (91) III
Prise en compte des tâches du contrôleur pour l’ergonomie des interfaces. Rapport CENA/INRIA, n°91223, août.
Application du formalisme MAD pour la description des tâches.
EL MRABET H. (91) V
Outils de génération d'interface : etat de l'art et classification. Rapports Techniques de l'INRIA, N° 126, Rocquencourt,
78 p.
Etat de l’art sur les outils de génération d’interface
ERICSSON A.K., H.A. SIMON (84) II
Protocol analysis: verbal reports as data. Cambridge, MA: MIT Press. (cité par Senach 90)
Analyse des protocoles pour l’évaluation des IHM.
FADIER E. (90) V
Fiabilité humaine : méthodes d'analyse et domaines d'application. Les Facteurs humains de la fiabilité dans les systèmes
complexes, Leplat & De Terssac (Eds.), Edition Octarés, Marseille, 47-80.
Présentation et discussion de méthodes d’analyse des systèmes automatiques homme-machine, mise en évidence de 4 méthodes
d’analyse : les diagrammes blocs et les graphes de fluence, pour le fonctionnement normal ; l’analyse des modes de défaillance et
de leurs effetc (AMDEC) et les arbres de défaillances, pour le fonctionnement anormal.
FOLEY J.D., A. VAN DAM (82) IV
Fondamentals of interactive computer graphics. Addison-Wesley: Reading, Mass. (cité par Coutaz 90)
Modèle Langage, modélisation de l’interaction H-M comme un langage de communication.
FOLEY J.D., W. KIM, S. KOVACEVIC, K. MURRAY (91) III
Foley J.D., W. Kim, S. Kovacevic, K. Murray (91) UIDE: an intelligent user interface design. Architectures for
intelligente interfaces: elements and prototypes, Sullivan & Tyler (Eds.), 339-385, MA: Addison-Wesley.
Génération automatique des spécifications d’interface (UIDE).
FORSE T. (89) I, IV
Qualimétrie des systèmes complexes- mesure de la qualité du logiciel. Les Editions d’Organisation, 260 p.
Génie logiciel et qualité, modèle de cycle de vie en V, métriques de mesure de la qualité.
GARRIGOU A., F. DANIELLOU, G. CARBALLEDA, S. RUAUD (95) V
Activity analysis in participatory design and analysis of participatory design activity. Int. J. of Industrial Ergonomics, 15
(1995), 311-327.
Analyse de l’activité de conception dans une démarche participative.
GIBBONS S.C. (92) III
Towards an expert system based menu interface evaluation tool. Rapport INRIA n°1581.
Evaluation automatique de l’affichage au moyen d’un programme informatique.
GILMORE W.E., D.I. GERTMAN, H.S. BLACKMAN (89) I
User-computer interface in process control. A Human Factors Engineering Handbook, Academic Press.
Recommandation sur le présentation des informations sur écran.
GRAY W.D., B.E. JOHN, M.E. ATWOOD (92) III
Gray W.D., B.E. John, M.E. Atwood (92) The precis of project ernestine or an overview of validation of GOMS. CHI'92,
Proc. of ACM Conf. on Human factors in Computing Systems, Bauersfeld et al. (Ed.), Monterey, California, May 3-7,
1992, 307-312.
Application du formalisme CPM-GOMS à l’évaluation de stations de travail.
GUERRA T.M. (91) I
Analyse de données objecto-subjectives : approche par la théorie des sous-ensembles flous. Thèse en automatique
industrielle et humaine, Université de Valenciennes.
HAMMOND N., G. HINTON, P. BARNARD, A. MACLEAN, J. LONG, A. WHITEFIELD (84) II
Evaluating the interface of a document processor: a comparison of expert judgement and user observation. In Human-
Computer Interaction, INTERACT'84, B. Schackel (Ed.), Elsevier Science Publishers B.V.: North-Holland, IFIP, 725-
729. (cité par Senach 90)
Expertise humaine pour l’évaluation des IHM…
HAMMOUCHE H. (93) III
De la modélisation des tâches à la spécification d’interface utilisateur. Rapport INRIA n°1959, 70 p.
Extension du formalisme MAD de descritpion des tâches à la spécification des interfaces utilisateurs.
139 Références bibliographiques

HANSON S.J., R.E. KRAUT, J.M. FARBER (84) II

Interface design and multi-variate analysis of UNIX command use. ACM transaction od Office Information Systems, 2,
24-57. (cité par Senach 90)
Technique du mouchard électronique (ou monitoring).
HARTSON H.R., P.D. GRAY (92) III, V
Temporal aspects of tasks in the user action notation. Human-Computer Interaction, vol. 7, pp. 1-45.
Méthode linguistic UAN de description des tâches.
HAUNOLD P, D.F.W. KUHN (94) III
A Keystroke level analysis of a graphics application: manual map digitizing. CHI'94 Conference Proceedings, ACM
Press, Addison-Wesley.
Utilisation de la méthode KLM pour la prédiction des temps d’exécution de tâches élémentaires.
HILL S.G., H.P. IAVECHIA, J.C. BYRES, A.C. BITTNER, A.L. ZAKLAD, R.E. CHRIST (92) II
Comparison of four subjective workload rating scales. Human Factors, 34 (4), 429-439.
Méthode subjective d’estimation de la charge de travail (MCH, TLX, OW, SWAT).
HIX D., R. HARTSON (93) V
Developing User Interfaces, ensuring usability through product & process. Wilay, 381 p.
Modèle en étoile pour l’évaluation dans le développement logiciel
IRVING S., P. OLSON, J.E. IRVING (94) III
A GOMS analysis of the advanced automated cockpit. CHI'94 Conference Proceedings, Boston, Massachusetts USA,
April 24-28, ACM Press, Addison-Wesley, 344-350.
Application du formalisme GOMS à l’analyse de la tâche dans un cockpit automatisé.
ISO 9241 I
Ergonomic requirements for office work with visual displays units. International Standard Organization, 1992.
Standard de conception et d’évaluation ergonomique.
ITOH Y., Y. HAYASHI, I. TSUKUI, S. SAITO (90) II
The ergonomic evaluation of eye movement and mental workload in aircraft pilots. Ergonomics, vol 33, n°6, 719-733.
(cité par Simon 93)
Oculométrie et comparaison entre instruments traditionnels et de nouveaux systèmes de présentation (écrans).
JACKSON M. (83) III
System Developement. Prentice Hall.
Méthode de description des tâches JSD.
JACOBSON I., M. CHRISTERSON, P. JONSSON, G. OVERGRAAD (93) I
Le génie logiciel orienté objet, une approche fondée sur les cas d’utilisation. Addison-Wesley.
Nouvelles méthodes et techniques pour le développement tout au long du cycle de vie…
JAMES M.G. (91) II
James M.G. (91) PRODUSER: PROcess for Developing USER interfaces. Taking Software Design Seriously, J. Karat
(Ed.), Academic Press.
Prototypage pour l’évaluation des IHM (tests de conception).
JAULENT P. (90) I
Génie logiciel : les méthodes, 2° édition. Armand Colin, Paris.
Méthodes utilisés en génie logiciel, cycle de vie en V de l’AFCIQ.
JOHANNSEN G. (82) I
Man-machine systems - introduction and background. IFAC on Analysis Design and Evaluation of Man-Machine
Systems, Baden-Baden, Federal republic of germany, xiii-xvii.
Système homme-machine, procédé fortement automatisé
JOHANNSEN G., A.H. LEVIS, H.G. STASSEN (92) INTRO. GÉNÉRALE
Theorical problems in Man-Machine Systems and their experimental validation. 5th IFAC/IFIP/IFORS/IEA Symposium
on Analysis Design and Evaluation of Man-Machine Systems, The Hague, Netherlands, 9-11 June.
JOHN B.E. (88) III
Contribution to engineering models of human-computer interaction. Doctoral dissertation, Carnegie Mellon University.
(cité par John et al. 92)
Extension du formalisme GOMS à CPM-GOMS, notion de chemin critique…
JOHN B.E., A.H. VERA (92) III
A GOMS analysis of graphic, machine-paced, highly interactive task. CHI'92, Proc. of ACM Conf. on Human factors in
Computing Systems, Bauersfeld, et al. (Ed.), Monterey, California, May 3-7, 251-258.
Application du formalisme CPM-GOMS à l’analyse d’une tâche hautement interactive (Jeu vidéo).
 Références bibliographiques 140

JOHNSEN G.I., C.W. CLEGG, S.J. RAVDEN (89) II

Towards a practical method of user interface evaluation. Applied Ergonomics, 20 (4), 255-260, December. (cité par
Nielsen 93)
Grille d’évaluation…
JOHNSON P., D. DIAPER, J. LONG (84) II, III
Tasks, skills and knowledge : task analysis for knowledge based descriptions. INTERACT'84, B. Shackel (ed.), North
Holland, 499-503.
Méthode TAKD d’analyse de la tâche.
JOUGLET D., O. PETIT (94) V
Jouglet D., O. Petit (94) Analyse, conception et évaluation d’une imagerie de supervision. Projet IUP 3ème année,
Valenciennes, Juin.
Utilisation des 4 méthodes préconisées par Fadier (90) pour l’analyse d’un SHM, et spécification de l’imagerie évaluée au
chapitre IV (cf. annexes B et C).
KAMOUN A. (89) I, II
Contribution à la répartition dynamique des tâches entre opérateur et calculateur pour la supervision des procédés
industriels. Thèse en automatique industrielle et humaine, Université de Valenciennes.
Echelles subjectives et méthode temporelle d’évaluation de la charge de travail.
KARAT J., J.L. BENNETT (91) II
Using Scenarios in design Meetings - A Case Study Example. In J. Karat (Ed.), Taking Software Design Seriously:
Practical Techniques for Human-Computer Interaction Design. Boston: Academic Press, 63-94.
Groupe de discussion (méthode de travail, gestion des connaissances).
KIERAS D., P.G. POLSON (85) III, IV
Kieras D., P.G. Polson (85) An approach to the formal analysis of user complexity. Int. J. of Man-Machine Studies, 22,
365-394.
Modèle de compatibilité cognitive, prédiction des difficultés d’utilisation.
KIRWAN B. (90) II
Human reliability assessment. In Evaluation of Human works: a practical ergonomics methodology. Wilson J.R. and
Corlett E.N. (Eds.), Taylor & Francis.
Méthode de l’arbre des causes.
KOENEMANN-BELLIVEAU J., J.M. CARROLL, M.B. ROSSON, M.K. SINGLEY (94) II
Comparative usability evaluation: critical incidents and critical threads. CHI'94 Conference Proceedings, Boston,
Massachusetts USA, April 24-28, ACM Press, Addison-Wesley.
Méthodes des incidents critiques.
KOLSKI C. (89) III
Contribution à l'ergonomie de conception des interfaces graphiques Homme-Machine. Thèse en Automatique
Industrielle et Humaine, Université de Valenciennes, 168 p.
Expérience de l’analyste pour l’évaluation d’IHM, évaluation de la qualité des affichages avec un système expert d’analyse des
synoptiques industriels.
KOLSKI C. (93) I
Ingénierie des interfaces homme-machine, conception et évaluation. Editions Hermès, Paris, 372 p., août.
Etat de l’art en IHM, démarche pour le développement d’IHM (intervenants, démarche participative…), recommandation sur le
présentation des informations sur écran, interfaces “intelligentes”…
KOLSKI C. (95) I, V
Méthode et modèle de conception et d’évaluation des interfaces homme-machine. Thèse d’habilitation à diriger des
recherches, spécialité informatique, Janvier.
Proposition d’un cadre théorique et méthodologique de développement de système interactif…
KOLSKI C., B. RIERA, T. BERGER (93) II
Analyse en salle de contrôle, lignes directrice pour la conception d'imagerie pour un procédé de même type. Rapport
établi dans le cadre de la convention SOLVAY/LAIH.
Méthode d’analyse, utilisation du questionnaire de Ravden et Johnson pour l’évaluation.
KOLSKI C., F. MOUSSA (91B) III
Une approche d'intégration de connaissances ergonomiques dans un atelier logiciel de création d'interfaces pour le
contrôle de procédé. Quatrièmes Journées Internationales : Le génie logiciel et ses applications, Toulouse, Editions EC2,
9-13 décembre.
ERGOCONCEPTOR : géneration automatique des spécifications à partir d’une description de l’application.
KOLSKI C., M. GRISLIN (95) IV
Méthodes d’évaluation des interfaces homme-machine, utilisation a priori et/ou a posteriori. Journée Supervision et
Coopération Homme-Machine, Paris, 12 et 13 janvier.
Recensement des méthodes d’évaluation de la qualité des IHM, et discussion de leur utilisation a priori et/ou a posteriori dans le
cycle de développement d’application de supervision.
141 Références bibliographiques

KOLSKI C., P. MILLOT (91A) III

A rule-based approach to the ergonomic “static” evaluation of man-machine graphic interface in industrial processes.
Int. J. of Man-Machine Studies, 35, 657-674.
Evaluation de la qualité des affichages avec un système expert d’analyse des synoptiques industriels.
KOUBEK R.J., G. SALVENDY (91) II
Cognitive performance of super-experts on computer program modification tasks. Ergonomics, 8, 1095-1112.
Analyse des protocoles pour l’évaluation des IHM.
LANNING T.R. (91) I
Let the users design ! In Taking Software design seriously, J. Karat (Ed.), Academic Press, 127-135.
Intervenants pour la conception-évaluation des IHM, démarche participative.
LE STRUGEON E., M. GRISLIN, P. MILLOT (95) V
Application of MultiAgent Techniques to the Design of Human-Machine Systems Organizations. 6th
IFAC/IFIP/IFORS/IEA SYMPOSIUM on Analysis, Design and Evaluation of Man-Machine Systems at MIT-
Cambridge, MA USA, June 27-29, 1995.
Perspective pour appliquer les organisations multi-agents de l’IAD à la communication H-M.
LEMKE A., G. FISCHER (90) III
A cooperative problem solving system for user interface design. In Proceedings Eight National Conference on Artificial
Intelligence AAAI-90, 479-484.
Evaluation automatique de l’affichage au moyen d’un programme informatique.
LEPLAT J. (85) I
Erreur humaine, fiabilité humaine dans le travail. Armand Colin (Ed.), Paris.
LEPLAT J., J.C. SPERANDIO (67) II
La mesure de la charge de travail par la technique de la tâche ajoutée. L’année Psychologique, Tome 1, 255-277.
LEWIS C., P. POLSON, C. WHARTON, J. RIEMAN (90) II
Testing a walkthrough methodology for theory-based design of Walk-Up-and-Use interfaces, Proceedings CHI'91
Conference on Computer Human Interaction, Seattle, ACM New-York, pp. 235-242.
Méthode experte de “cognitive walkthrough”
LIM K.Y., J.B. LONG, N. SILCOCK (92) III
Instanciation of task analysis in a structured method for user interface design, in Proc. of the 11th Interdisciplinary
Workshop on Informatics and Psychology : Task Analysis in Human-Computer Interaction, Scarding, June, 9-11.
Extension de la méthode JSD à JSD*
LOSLEVER P. (88) I
Etude ergonomique du poste de bureautique : approche par les méthodes multidimensionnelles d'analyse des données.
Thèse en Automatique Industrielle et Humaine, Valenciennes.
Présentation détaillé des méthodes de traitement des données pour l’analyse ergonomique.
LÖWGREN J., T. NORDQVIST (92) III
Knowledge-based evaluation as design support for graphical user interfaces. Proc. of ACM Conf. on Human factors in
Computing Systems, CHI'92, Bauersfeld, et al. (Ed.), Monterey, California, May 3-7 1992, 181-188.
Evaluation automatique de la qualité des interfaces de dialogue avec un système à base de connaissance.
MACKINLAY J. (86) III
Automating the design of graphical presentation of relationnal information. ACM Transactions on Graphics, 5 (2), 110-
141. (cité par Senach 90)
Géneration automatique des affichages, outil de présentation des informations.
MAGUIRE M., M. SWEENEY (89) II
Maguire M., M. Sweeney (89) System Monitoring: Garbage Generator or Basic for comprehensive Evaluation system?
Proc. of the fifth conf. of the British Computer Society, HCI Specialist Group, Univerity of Nottingham, 5-8 september,
375-394.
Classification des techniques d’évaluation selon 3 familles, basée sur : l’utilisateur, la théorie, ou l’expertise. Description de la
techniques des enregistrements vidéo pour l’évaluation des IHM.
MAHFOUDHI A., M. ABED M., J.C. ANGUE (95) III
Mahfoudhi A., M. Abed M., J.C. Angue (95) TOOD : Task Object Oriented Description fot Man Machine Systyms
Analysis Design. 6th IFAC/IFIP/IFORS/IEA SYMPOSIUM on Analysis, Design and Evaluation of Man-Machine
Systems at MIT- Cambridge, MA USA, June 27-29.
Proposition et description du formalisme TOOD extension de SADT/petri.
MCCLELLAND I. (90) I
Product assessement and user trials. In Wilson & Corlett, Evaluation of human work - a practical ergonomics
methodology. Taylor & Francis Ltd (Eds.), 218-247.
Intervenants pour la conception-évaluation des IHM.
 Références bibliographiques 142

MEINADIER J.P. (91) I, IV

L'interface utilisateur, pour une informatique plus conviviale. Informatique et stratégie, Dunod informatique, Paris, 232
p.
“Vulgarisation” des travaux sur la communication homme-machine (notion de qualité ergonomique, méthode, recommandations,
intervenants, évaluation…), complexité de l’interaction…
MESKENS N. (91). IV
Contribution à la conception d’un système d’analyse de la qualité de programmes informatiques. Thése de Doctorat en
Automatique et Informatique Humaine, Dec 91.
Génie logiciel et qualité, métriques de mesure de la qualité.
MILLER-JAKOBS H.H. (91) II
Miller-Jakobs H.H. (91) Rapid Prototyping: An Effective Technique for System development. In J. Karat (Ed.), Taking
Software Design Seriously. Boston: Academic Press, 273-286.
Prototypage pour l’évaluation des IHM (tests de conception).
MILLOT P. (88) I, II
Supervision des procédés automatisés et ergonomie. Hermés, Paris, 237 p.
Répartition dynamique des tâches (H-M), évaluation de la charge de travail (méthode temporelle).
MILLOT P. (90) I
Coopération Homme-Machine : exemple de la téléoperation. Journée GR Automatique, 17-19/10, Strasbourg, 1-25.
Démarche pour le développement d’IHM.
MOLICH R., J. NIELSEN (90) II
Molich R., J. Nielsen (90) Improving a human computer dialogue. Communications of the ACM, 33, 338-348. (cité par
Kolski 93)
Expertise humaine pour l’évaluation des IHM…
MORAN T.P. (81) III, IV, V
Moran T.P. (81) The Command Language Grammar: a representation of the user interface of interactive computer
systems. Int. J. of Man-Machine Studies, 15, 3-50.
Modélisation de l’interaction H-M comme un langage, description du modèle linguistique CLG…
MORAY N. (86) I, II
Monitoring behavior and supervisory control. Human performance, chap. 40, 1-50.
Système homme-machine, définition de la supervision (surveillance et contrôle supervisié), discussion sur l’évaluation des
planches de bord d’aéronefs avec l’oculométrie.
MOUSSA F. (92) III
Contribution à la conception ergonomique des interfaces de supervision dans les procédés industriels : application au
système ERGO-CONCEPTOR. Thèse en automatique industrielle et humaine, Université de Valenciennes, juillet.
Génération automatique des spécifications d’interface (ERGO-CONCEPTOR).
NEAL A.S., R.M. SIMON (83) II
Playback: a method for evaluating the usability of software and its documentation. In Human Factors in Computing
Systems-I, A. Janda (Ed.), ACM, North-Holland, Amsterdam, 78-82. (cité par Senach 90)
Technique du mouchard électronique (ou monitoring), banc d’essai final pour l’évaluation des IHM.
NEBOIT M., H. GUILLERMAIN, E. FADIER (90) I
De l’analyse du système à l’analyse de l’interaction opérateur-tâche : proposition méthodologique. Les Facteurs
humains de la fiabilité dans les systèmes complexes, Leplat, De Terssac (Eds), Octarés (Ed), Marseille, 241-265.
Évolution des systèmes de supervision et du dialogue homme-machine.
NIELSEN J. (90) II
Designing user interfaces for international use. North-Holland, Elsevier, Amsterdam. (cité par Kolski 93)
Grille d’évaluation…
NIELSEN J. (93) I
Usability Engineering. Academic Press, Boston, 358 p.
Définition de l’utilisabilité et état de l’art très complet sur la recherche en communication H-M, méthodes pour le développement
d’IHM (conception centrée utilisateur, recettes “bon marché”), bibliographie commentée très exhaustive mais principalement
américaine.
NIGAY L., J. COUTAZ (91) IV
Building user interfaces: organizing software agents. In Proc. ESPRIT’91 Conf., Bruxelles, november, 707-719.
Modéle d’architecture
NIELSEN J., R. MOLICH (90) II
Nielsen J., R. Molich (90) Heuristic evaluation of user interfaces. Proceedings CHI’90, Seatle, ACM New York, pp.
349-356.
Distinction entre les approches prédictives et experimentales pour l’évaluation des IHM.
143 Références bibliographiques

NORMAN D.A. (86) I, IV

Cognitive engineering. User centred system design: new perspectives on human computer interaction. Norman &
Draper (Eds), Hillsdale, NJ: Erlbaum Associates, 31-61. (cité par Berger 92)
Différents points de vues pour la description de l’interaction homme-machine, intervenants pour l’évaluation.
NORMAND V. (92) III, IV, V
Normand V. (92) Le modèle SIROCO : de la spécification conceptuelle des interfaces utilisateurs à leur réalisation.
Thèse de l'Université Joseph Fourier, Grenoble I.
Génération automatique des spécifications d’interface.
NOVARA F., N. BERTAGGIA, A. DILLON, J. BONNER (87) II
The evaluation of products using the usability methodology with proposals for product development. Working paper
A5.3a, ESPRIT Project 385 - HUFIT/04-OLI-11/87. (cité par Senach 90)
Banc d’essai final pour l’évaluation des IHM (tests de conception).
ODGEN E.C., J.M. LEVINE, E.J. EISNER (79) II
Measurement of workload by secondary tasks. Human Factors, 21 (5), 529-548. (cité par Simon 93)
Méthode d’évaluation de la charge de travail par la mesure de la performance.
OMBREDANE A., J.M. FAVERGE (55) II
L'analyse du travail. Paris, PUF. (cité par Kolski 93)
Technique de l’expérience de l’analyste…
PAYNE S.J., T.R.G. GREEN (89) III
Payne S.J., T.R.G. Green (89) Task-Action Grammar: the model and developments. In D.Diaper (Ed), Task analysis for
human-computer interaction, John Wiley and Sons, 75-107.
Description du modèle linguistique TAG…
PERLMAN G. (87) III
An axiomatic model of information presentation. Proceedings of the 1987 Human Factors Society Meeting, New York,
Human Factors Society, 1219-1223.
Géneration automatique des affichages, programme de description de la structure logique des affichages.
PFAFF G.E. (85) IV
User Interface Management Systems, (Ed), New York: Springer-Verlag.
Modèle du type Langage : Seeheim (présentation, contrôle du dialogue, et interface avec l’application).
PHILIPPE B. (93) I
Système d’aide à la conception des protocoles expérimentaux en communication homme-machine, fondé sur une
analyse orientée par les objets. Thèse en automatique industrielle et humaine, Université de Valenciennes.
Description de la méthode expérimentale d’analyse de Valisser (77) et du traitement des données…
POITRENAUD S. (93) III
Le réseau sémantique : une alternative aux grammaires d’action. Laboratoire de psychologie cognitive du traitement de
l’information symbolique CNRS - Université de Paris 8.
Présentation de gammaires et de leur évolution (BNF, Set Grammar, TAG, ETAG, YSS), proposition du réseau sémantique
PROCOPE (description des tâches, représentation des connaissances et de leur organisation).
POLLIER A. (92) I, II
Evaluation d'une interface par des ergonomes: diagnostics et stratégies. Le Travail Humain, tome 55, n°1, 71-96.
Utilisation des critères ergonomiques et de l’expertise humaine pour l’évaluation des IHM…
POLSON P.G., C. LEWIS, J. RIEMAN, C. WHARTON (92) II
Cognitive walkthroughs : a method for theory-based evaluation of user interfaces, International Journal of Man-
Machine Studies, 36, pp. 741-773.
Méthode experte de “cognitive walkthrough”
POPIEUL J.C. (94) I
Contribution à l’étude et à l’implémentation d’une démarche de conception de machines et systèmes automatisés de
production. Thèse en automatique industrielle et humaine, Université de Valenciennes.
Influence des étapes initiales pour la conception de système automatisés de production.
POULAIN T. (94) I, II
Poulain T. (94) Contribution du génie logiciel à la conception et l'évaluation d'applications de supervision. Thèse en
automatique industrielle et humaine, Université de Valenciennes.
Démarche de développement de synoptiques de supervision basée sur le modèle spirale (prototypage, atelier de génie logiciel,
intervenants…).
PRNF (92) I
PRNF (92) Représentation des systèmes de contrôle et de commande des systèmes automatisés. Contribution à
l’intégration des outils XAO du génie automatique, modèle conceptuel Base-PTA, Projet de normalisation, AFNOR
Z68-901.
Impact du cycle de vie en V dans le domaine de l’automatisation.
 Références bibliographiques 144

RASMUSSEN (86) INTRO. GÉNÉRALE

Information Processing and Human-Machine Interaction - An approach to cognitive engineering. Elsevier Science
Publishing Co., Inc., 1986, 214 p.
RAVDEN S., G. JOHNSON (89) I, II
Evaluating Usability Of Human-Computer Interface. Chichester: Ellis Horwood.
Chek-list pour l’évaluation des IHM et discussion des intervenants pour évaluer.
REASON J. (90) I
Human error. Cambridge University Press.
La réference sur l’erreur humaine, voir aussi Leplat 85.
REISNER P. (84, 86) III
Reisner P. (84) Formal grammars as a tool for analysing ease of use: some fundamental concepts. Human Factors in
Computer Systems, Thomas & Schneider (eds), Norwood, N.J.: Ablex, 1984. (cité par Senach 90)
Human-computer interaction : what is it and what research is needed ? IBM Research report RJ 5308, 1986.
Méthode de description formelle BNF, description du modèle linguistique ALG…
RIERA B. (93) II
Methodologie d'évaluation des interfaces Homme/Vehicule automobile. Thèse en Automatique Industrielle et Humaine,
Valenciennes, 255 p.
Evaluation de la charge de travail (différentes méthodes), application de la méthode temporelle à la conduite automobile,
observation des tactiques visuelles.
RIERA B., B. VILAIN, L. DEMEULENAERE, P. MILLOT (95) V
Riera B., B. Vilain, L. Demeulenaere, P. Millot (95) A proposeal to defined and to treat alarms in a supervivion room.
IFAC/IFIP/IFORS/IEA SYMPOSIUM on Analysis, Design and Evaluation of Man-Machine Systems at MIT -
Cambridge, MA USA, June 27-29.
Proposition de méthodes pour analyser les SHM en prenant en compte les besoins informationnelles de l’homme.
RIERA B., M. GRISLIN, P. MILLOT (94) II, V
Riera B., M. Grislin, P. Millot (94) Methodology To Evaluate Man-Car Interfaces. IFAC/IFORS Transportation
Systems: Theory and Application of Advanced Technology, Tianjin, China, August 24-26, preprints vol II, 459-469.
Evaluation de la charge de travail dans un contexte double tâche, application de la méthode temporelle, observation des tactiques
visuelles.
ROTH S.T., J. KOLOJEJCHICK, J. MATTIS, J. GOLDSTEIN (94) III
Roth S.T., J. Kolojejchick, J. Mattis, J. Goldstein (94) Interactive graphic design using automatic presentation
knowledge. CHI'94 Conference Proceedings, Boston, Massachusetts USA, April 24-28, ACM Press, Addison-Wesley,
112-117.
Génération automatique des spécifications d’interface (SAGE).
ROUANET H., B. LE ROUX (93) I
Analyse des données multidimensionnelles - Statistique en Sciences Humaines. Dunod, Paris, 310 p.
ROWLEY D.E. (94) II
Rowley D.E. (94) Usability testing in the field: bringing the laboratory to the user. CHI'94 Conference Proceedings,
Boston, Massachusetts USA, April 24-28, ACM Press, Addison-Wesley.
Banc d’essai final pour l’évaluation des IHM (tests de conception).
RUSHINEK A., S. RUSHINEK (86) II
What makes users happy ? Communication of ACM, 29.
Questionnaires d’utilisation des interfaces.
SALAZAR-FERRER P. (91) I, II, IV
Une approche non-verbale pour l'extraction de le connaissance structurale. ERGO’IA 92, 7-9 octobre, Biarritz, France,
291-308.
Méthodes de recueil de l’expertise, application au opérateurs de conduite de chaufferie nucléaire.
SALAZAR-FERRER P. (92) IV
Résolution de pannes complexes sur simulateur de chaufferie nucléaire embarquée : ORION. Rapport interne de
recherche CERTSM/DFH, DCN Toulon Naval, Juillet.
Technologie, fonctionnement et conduite de réacteurs nucléaire PWR.
SANTUCCI G. (87) II
Evaluation de la charge de travail en aéronautique (deuxième partie). Médecine aéronautique et spatiale, tome xxvi, n°
102, 146-152. (cité par Simon 93)
Trépied de trois méthodes : description du travail, estimation subjective, indice physiologique.
145 Références bibliographiques

SAYARH H. (91) I
Contribution à l’analyse de données à l’étude locale et globale des signaux multidimensionnels : Application à
l’analyse des SHM. Thèse en automatique industrielle et humaine, Université de Valenciennes.
SCAPIN D.L. (87) II
Guide ergonomique de conception des interfaces Homme-Machine. Rapport Technique INRIA n°77, 92 p.
Synthèse des recommandation ergonomiques et aide mémoire des questions à se poser, grille d’évaluation.
SCAPIN D.L. (88) I, III
Vers des outils formels de description des tâches orientés conception d'interfaces. Rapport INRIA n°893, 28 p.
Mise en évidence des lacunes dans le prise en compte de l’ergonomie au sein du processus de conception des IHM, pb de
decription des tâches humaine et du manque d’outils pour passer de l’analyse à la conception, proposition du formalisme MAD
pou la description des tâches.
SCAPIN D.L. (90) I
Organizing Human Factors Knowledge for the Evaluation and Design of Interfaces. Int. J. of Human-Computer
Interaction 2(3), 203-229.
Conception-évaluation des IHM, définition des critères ergonomiques à respecter.
SCAPIN D.L., C. PIERRET-GOLBREICH (89) III
MAD : Une méthode analytique des descriptions des tâches. Actes du colloques sur l'ingenierie des interfaces Homme-
Machines, pp.131-148, Sophia Antipolis, 24-26 Mai.
Description du formalisme MAD.
SCHIELE F., T. GREEN (90) III
HCI formalisms and cognitive psychology: the case of Task-Action Grammar. Formal Methods in Computer
Interaction, Harrison & Thimbleby (Eds), Cambridge University Press, Cambridge, U.K. 9-62.
Description du modèle linguistique TAG…
SEBILLOTTE S. (94) III
Méthodologie pratique d’analyse de la tâche en vue de l’extraction de caractéristiques pertinentes pour la conception
d’interface. Rapport technique INRIA n° 163, mars.
Description du formalisme MAD et démarche d’utilisation.
SENACH B. (90) I, II, III
Évaluation ergonomique des IHM : une revue de la littérature. Rapport INRIA n°1180, 75 p.
Classification des techniques d’évaluation selon deux approches : analytiques et empirique.
SENACH B., P. ALENGRY (85) III, IV
Evaluation d'un dispositif d'assistance à la conduite et au dépannage de chaînes de fabrication automatisées. Rapport
Technique INRIA, Février 1985.
Méthodes des incidents critiques.
SHEPHERD A. (93). I, III
An approach to information requirements specification for process control tasks. Ergonomics, vol. 36, n°11, 1425-1437.
Proposition d’une démarche ergonomique de spécification des besoins d’information basé sur une analyse des buts des opérateurs
(analyse de la tâche, HTA, définition d’éléments de tâche standard).
SHERIDAN T.B. (85) I
Forty-five years of man-machine system: history and trends. 2nd IFAC Congress: Analysis, Design and Evaluation of
Man-Machine Systems, Varese, September. (cité par Berger 92)
Système homme-machine, architecture, procédé fortement automatisé
SHERIDAN T.B. (88) INTRO. GÉNÉRALE
Task allocation and superviory control. In Handbook of Human-Computer Interaction, M. Helander (Ed.), Elsevier
Science Publishers B.V., North-Holland.
SIEBERT S., Y. SICARD, M.H. THEBAULT (88) IV
Comparaison d'interface de conduite, essais incidentels sur pupitre d'imagerie graphiques. Le Travail humain, tome
51/n°1, 81-95.
Fonctionnement et conduite de réacteurs nucléaire.
SIMON P. (93) I, II
Contribution de l'analyse des mouvements oculaires à l'évaluation de la charge de travail mental. Thèse en automatique
industrielle et humaine, Université de Valenciennes.
Evaluation de la charge de travail : synthèse de différentes méthodes.
SIMON P., J-C. POPIEUL, J-C. ANGUE (94) II
Evaluation d’une planche de bord, étude exploratoire. Rapport de contrat LAMIH-PSA, Septembre 1994.
Méthode d’observation des tactiques visuelles (architecture materiel, évaluation d’un tableau de bord).
 Références bibliographiques 146

SINCLAIR M.A. (90) II

Subjective assessment. In Evaluation of Human works: a practical ergonomics methodology. Wilson J.R. and Corlett
E.N. (Eds.), Taylor & Francis, 58-88.
Questionnaires d’utilisation des interfaces.
SMITH S.L., J.N. MOSIER (86) I, II
Guidelines for designing User Interface Software. Technical report MTR-10090, The MITRE Corporation, Bedfort, MA
01730, Massachusetts, USA.
944 recommandations ergonomique pour le développement d’IHM, grille d’évaluation. Principes, justification et exemples
concernant les données d’entrée et de sorties (affichage), les séquences de commande, le guidage utilisateur, la transmission et la
protection des données.
SOMMERVILLE I. (88) I
Le génie logiciel et ses applications, 4ème édition, informatique/intelligence artificielle (col.), 336 p.
Introduction au génie logiciel, méthodes, modèles, techniques.
SPERANDIO J.C. (88) I, II
L'ergonomie du travail mental. Masson Paris, 2ème Edition, 145 p.
Démarche pour le développement d’IHM, analyse de la tâche, évaluation de la charge de travail.
SPERANDIO J.C. (91) I
Les méthodes d'analyse du travail en psychologie ergonomique. In La recherche en Psychologie (Domaine et méthodes)
de J.P. Rossi, Dunod (Ed.).
Le point sur l’analyse du travail (importance du type de données, techniques de recueil, méthodes d’analyse).
STAMMER R.B., S.C. MICHAEL, J.A. ASTEY (90). III, V
Stammer R.B., S.C. Michael, J.A. Astey (90) Task analysis In Evaluation of Human works: a practical ergonomics
methodology. Wilson J.R. and Corlett E.N. (Eds.), Taylor & Francis, 134-160.
Description hiérarchiques des tâches avec le modèle de tâche HTA…
SWEENEY M., A. DILLON (87) II
Methodologies employed in the psychological evaluation of HCI. Human-computer interaction-INTERACT’87,
Bullinger, Shackel (Ed), Elsevier Science Publishers, North-Holland, Amsterdam, 367-373. (cité par Senach 90)
Questionnaires d’utilisation des interfaces.
SWEENEY M., M. MAGUIRE, B. SHACKEL (93) II
Sweeney M., M. Maguire, B. Shackel (93) Evaluating user-computer interaction: a framework. Int. J. Man-Machine
Studies 38, 689-711.
Classification des techniques d’évaluation (utilisateur, théorie, expertise).
TARBY J.C. (93) III
Tarby J.C. (93) Gestion automatique du dialogue homme-machine à partir de spécifications conceptuelles. Thèse de
l'université de Toulouse I.
Méthode DIANE+, et spécification automatique d’IHM.
TAUBER M. (90) III
Tauber M. (90) ETAG: Extended Task Action Grammar - A language for the description of the user’s task language.
Human-Computer Interaction - INTERACT'90, Diaper, Gilmore, Cockton, Shackel (Eds.), 163-168, North-Holland.
Description du modèle linguistique ETAG (extension de TAG)…
TECHNIQUES DE L’INGÉNIEUR IV
Bouteille F., F.Y. Guéna, J.F. Pététrot (92). Réacteur à eau ordinaire sous pression (REP) - Fonctionnement normal et
accidentel. B3110, 19 p.
Charbonneau S. (79). REP - Sureté. B3120, 12 p.
Delor M., A. Gautier, Y. Wilmar (85). REP - Fonctionnement. B3110, 16 p.
Durant-Smet R., J. Bebin (85). REP - description technologique. B3100, 24 p.
Naudan G., J.L. Nigon (91). REP - Physique du cœur : neutronique et thermohydraulique B3090, 12 p.
Verdeau J.J., J.L. de Ladonchamps (91). REP de propulsion navale. B3140, 9 p.
Techniques de l’Ingénieur - Traité Mécanique et Chaleur, Génie nucléaire.
Technologie, fonctionnement et conduite de réacteurs nucléaire PWR.
THEAKER C.J., R. PHILLIPS, T.M. FROST, W.R. LOVE (89) II
HIMS: a tool for HCI evaluations. People and computers V, Sutcliffe & Macaulay (Eds.), The BCS HCI Special Interest
Group, 427-442, Cambridge University Press.
Techniques des enregistrements vidéo pour l’évaluation des IHM.
TULLIS T.S. (86) III
Display analysis program (Version 4.0). Lawrence, Kansas, The Report Store, 1986. (cité par Nielsen 93)
Evaluation de la qualité des affichages
147 Références bibliographiques

TULLIS T.S. (88) III

Tullis T.S. (88) Screen design. Handbook of Human-Computer Interaction, M. Helander (ed.), Elsevier Science
Publisheders B.V. (North-Holland), 1988, 377-411.
Programme d’analyse des affichages alphanumériques.
TULLIS T.S. (93) V
Is user interface design just common sense? Proc. of HCI International’93, vol 2, G. Salvendy & M. J. Smith (Eds),
Elsevier, Orlando, Florida, 9-14, August 8-13.
Expérimentation et comparaisons de différents modes d’interaction homme-machine.
VANDERDONCKT J. (94) I
Guide ergonomique de la presentation des applications hautement interactives, Press universitaire de Namur.
Corpus ergonomicus de 3700 règles classées en division /18 critères. Ordonnancement par importance, et déclinaison des critères /
7 niveaux (but, pragmatique, sémantique, syntaxique, lexical, alphabétique, physique).
VANDERDONCKT J., F. BODART (94) II
Jusqu’au bout avec nos règles ergonomiques. Actes des sixièmes journées sur l’Ingénierie des Interfaces Homme-
Machine, IHM’94, 231-236, Lille, 8-9 décembre.
Proposition d’une approche multi-stratégie de l’implémentation des outils de génération automatique d’IHM, basée sur les règles
et les critères ergonomiques.
VILLEMEUR A. (88) II
Sûreté de fonctionnement des systèmes industriels : fiabilité, facteur humain, informatisation. Eyrolles, Paris.
Méthode de l’arbre des causes.
VOEGTLIN (91) V
Voegtlin (91) Procédé de génération d’objets pour la création d’application interactives adaptables. Thèse de Doctorat,
université de Haute Alsace (cité par Poulain 94)
Classification des techniques utilisées pour la spécification d’UIMS
VOLLE (81) I
Analyse des données. Deuxième édition, Economica, Paris.
WALSH P.A., J.V. LAWS (90) II
Methods and tools in industry for mobility testing: the STL usability evaluation workbench. BCS HCI Special Interest
Group Meeting, Camden Town, London, 21 May.
Banc d’essai final pour l’évaluation des IHM (tests de conception).
WHITEFIELD A., F. WILSON, J. DOWELL (91) I, II, III
Whitefield A., F. Wilson, J. Dowell (91) A framwork for human factors evaluation. Behaviour & Information
Technology, vol 10, n°1, jan.-feb., 65-79.
Conception-évaluation des IHM, classification des techniques d’évaluation selon deux approches : analytiques et empirique,
recensement des critères ergonomiques d’évaluation.
WIERWILLE W.W (79) II
Physiological measures of aircrew mental workload. Human Factors, 21(5), 575-593. (cité par Simon 93)
Méthode physiologique d’évaluation de la charge de travail.
WIERWILLE W.W., F. T. EGGEMEIER (93) II
Recommendations for Mental Workload Measurement in a Test and Evaluation Environment. Human Factors, 35 (2),
263-281.
Méthodes d’évaluation de la charge de travail, discussion, contraintes et limites d’utilisation.
WILSON G.F., R.D. O’DONNEL (88) II
Measurement of operator workload with the neuropsychological worload test battery. In Human Mental Workload.
Hancock & Meshkati (Eds), North-Holland, Advances in psychology. (cité par Simon 93)
Méthode physiologique d’évaluation de la charge de travail.
WILSON J.R., E.N. CORLETT (90) II
Evaluation of human work, a practical ergonomics methodology. Ed. Taylor & Francis Ltd, 890 p.
Ouvrage sur la conception/évaluation des IHM, méthodes ergonomiques de base, conception-évaluation.
YOUMANS D.M. (87) II
Using video in the design process. Proc. of IEE colloquium on Evaluation Techniques for Interactive Systems Design,
Professional Group C5 (MMI), 2 october, Savoy Place, London, IEE Digest n°1987/78, 2.1-2.3.
Techniques des enregistrements vidéo pour l’évaluation des IHM.
ZOROLA VILLARREAL RENAUT (95) III
L'évaluation des IHMs multi-utilisateurs dans le travail coopératif. Thèse de doctorat en Informatique, université de
Toulouse I, octobre 1995.
1 Annexe A

Annexes

ANNEXE A :
PROCESSUS DE DÉVELOPPEMENT EN V ADAPTÉ À UN SYSTÈME
INTERACTIF, ISSU DU GÉNIE LOGICIEL

ACTIVITÉS DE DÉVELOPPEMENT DES IHM SELON LE CYCLE EN V

ANNEXE B :
PROCÉDÉ DE FABRICATION DE MÉLANGE

ANNEXE C :
MAQUETTE DE L’IMAGERIE DE SUPERVISION DU PROCÉDÉ DE MÉLANGE

ANNEXE D :
QUELQUES PISTES DE RECHERCHES DE MÉTHODES D’ESTIMATION DES
CRITÈRES ERGONOMIQUES D’ÉVALUATION

Annexe A 1
2 Annexe A
A NNEXE A : P ROCESSUS DE DÉVELOPPEMENT EN V ADAPTÉ À UN SYSTÈME
INTERACTIF, ISSU DU GÉNIE LOGICIEL

La figure A.1 détaille chacune des phases du cycle de développement en V avec une première localisation des
méthodes utilisables.

Figure A.1 : Cycle de vie en V et méthodes d’analyses utilisables le long du développement

(d’après Forse 89 et Jaulent 90)

Annexe A 2
3 Annexe A
A CTIVITÉS DE DÉVELOPPEMENT DES IHM SELON LE CYCLE EN V
Cette synthèse est principalement issue des études réalisées par Forse (89) sur la qualimétrie des systèmes complexes,
et Jaulent (90) sur les méthodes du génie logiciel. Dans les quelques lignes suivantes, nous nous attachons à décrire les
activités réalisées dans chacune des phases de développement de la couche interface.

L’originalité du cycle de développement en V est caractérisés par les deux points suivants.

(1) Le cycle en V permet le mise en regard des étapes de développement :

• l’étape de spécification fonctionnelle et l’étape de validation (niveau 1),
• l’étape de conception préliminaire et l’étape d’intégration (niveau 2),
• l’étape de conception détaillée et l’étape de tests unitaires (niveau 3),

Le niveau 4 comprend uniquement l’étape de réalisation codage.

(2) Chaque étape est caractérisée par :

• un objectif double concernant l’activité de développement effectuée dans l’étape (réalisation de l’étape proprement
dite et préparation ou prise en compte de l’étape en vis-à-vis), par exemple, l’étape de spécification fonctionnelle
consiste à spécifier les besoins à satisfaire et à définir la stratégie de validation qui sera mise en œuvre lors de
l’étape en vis-à-vis.
• des responsabilités particulières, à chaque niveau, les responsabilités dépendront d’intervenants différents.
• un degré de difficulté particulier : au niveau 1, il sera élevé car les choix lors de cette étape sont primordiaux et un
défaut de spécification génère un coût élevé. Aux niveaux inférieurs, la difficulté diminue (par exemple, une erreur
de syntaxe dans le code).

Afin de bien comprendre le processus de développement de l’interface, une description des activités réalisées étape
par étape et les documents fournis est donnée dans les paragraphes suivants. La gestion du projet et les responsabilités n’y
sont pas décrites (voir Forse 89).

Étape de spécification fonctionnelle

Le premier objectif de cette étape est de répondre à la question “Quelles fonctions doit assurer l’interface ?”, et ce, à
partir des besoins exprimés lors des étapes amont (analyse des besoins, conception préliminaire et détaillée du système).
La première activité de réalisation à ce niveau consiste donc à formaliser les besoins exprimés dans un document de
spécification fonctionnelle : Dossier de Spécification Fonctionnelle des Besoins (DSFB).
• définition des fonctionnalités et des relations entre fonctions,
• définition des performances requises et des contraintes de réalisation (performances, priorités, précisions, capacité,
environnement matériel, …),
• définition des interfaces avec le système ou d’autres sous-systèmes (logiciel, matériel).

Les fonctions que doit assurer l’interface vis-à-vis de l’opérateur sont aussi décrites. Elles sont définie dans le Manuel
d’Utilisation (MU) et concernent :
• les traitements réalisables par l’opérateur et leurs enchaînements,
• les procédures de démarrage, d’arrêt, de reprise,
• la présentation des écrans, des résultats…

Le deuxième objectif est de préparer la stratégie de validation, c’est à dire définir en regard de la spécification, les
scénarios de test permettant d’assurer que l’interface réponde effectivement aux besoins spécifiés. Cette activité consiste à
préciser dans un Plan de Validation (PVA) :

Annexe A 3
4 Annexe A
• les scénarios de tests et leurs enchaînements,
• l’organisation et les moyens (méthodes, matériel, humains) à prévoir pour l’étape de validation.

Étape de conception préliminaire

L’objectif principal de cette étape est de décrire la solution optimale répondant aux besoins spécifiés lors des
spécifications fonctionnelles. La décomposition de cette solution est effectuée jusqu’à ce que les besoins identifiés dans le
Document de Spécification Fonctionnelle des Besoins (DSFB) soient tous pris en compte. Cette étape consiste à
décomposer la solution en une architecture modulaire. Dans cette architecture, chaque composant fait l’objet d’une
description. L’ensemble de ces spécifications constitue le document de conception préliminaire (DCP) :
• chaque élément défini en spécification fonctionnelle doit y avoir sa description (performance, liens entre éléments,
qualité),
• l’architecture de l’interface y est constituée par une suite ordonnée de niveaux d’abstraction (différents niveaux
d’abstraction, du général au particulier),
• le niveau d’abstraction le plus élevé constitue un composant unique dont le but est de contrôler la structure
dynamique sous-jacente.

Le deuxième objectif de préparer la stratégie d’intégration, c’est à dire de définir en regard des niveaux de
conception identifiés et décrits dans le DCP, la démarche d’intégration et les scénarios de test d’intégration permettant de
vérifier que l’élément de conception testé satisfait les exigences fonctionnelles définies dans le DCP. Cette activité avec
son organisation et les moyens à mettre en œuvre, est détaillé dans un Plan d’Intégration (PI).

Lors de cette étape, les jeux d’essai, leurs données d’entrée et les résultats attendus, associés aux scénarios de tests de
validation sont finalisés. Ceux-ci sont rassemblés dans un Document de Tests de Validation (DTVA), ce document ajouté
au PVA constitue le document de référence support au déroulement de l’étape de validation.

Le Manuel d’Utilisation (MU) est mis à jour en étudiant la faisabilité des spécifications (présentation des tableaux,
modes d’affichage, etc.).

Étape de conception détaillée

L’objectif de cette étape est de fournir une solution algorithmique à tous les composants de l’architecture définis
en phase de conception préliminaire, et de définir les ressources internes de chaque composant : Document de Conception
Détaillée (DCD). La conception détaillée n’apporte pas de décision supplémentaire quant au choix d’architecture.

L’objectif de cette étape est aussi de définir les procédures de tests et les jeux d’essai permettant de tester
unitairement les composants décrits en conception détaillée : Document de Test Unitaires (DTU).

Comme pour l’étape précédente, cette phase permet de finaliser les jeux d’essai, leurs données d’entrée et les résultats
attendus, associés aux scénarios de tests d’intégration permettant de vérifier le bon fonctionnement de chaque composant :
Document de Tests d’Intégration (DTI). Ce document ajouté au PI constitue le document de référence support au
déroulement de l’étape d’intégration.

Étape de réalisation-codage
Le but de cette étape est de traduire chaque unité de conception détaillée sous forme de code interprétable par un
calculateur. C’est donc le codage en respectant les standards de programmation, la compilation et la correction des erreurs
(essentiellement d’origine syntaxique). Les documents de sortie de cette étape sont le code source et les listages de chaque
unité de compilation.

Annexe A 4
5 Annexe A

Étape de tests unitaires

Les tests unitaires ont pour but de vérifier que chaque unité de compilation, traduction en code interprétable d’un
élément de conception, est conforme à sa description contenue dans le Document de conception Détaillée, soit exécuter
les tests unitaires tels qu’ils sont définis dans le DTU, de consigner les résultats dans ce même document et de corriger les
anomalies détectées.

A la sortie de cette étape, on recueille les unités de compilation testées et les listages correspondants, le DTU complété
par les résultats des tests.

Étape d’intégration
L’objectif de cette étape est d’assembler progressivement les différents éléments de conception :
• assembler les éléments correspondant à chaque niveau d’intégration, conformément au PI, et simuler les
éléments manquants et l’environnement,
• exécuter les tests d’intégration, c’est à dire générer les jeux de tests, dérouler les tests d’intégration tels qu’ils sont
décrits dans le DTI ; comparer les résultats à ceux attendus et les consigner dans le DTI ; en cas d’anomalie,
localiser l’origine et suivre la procédure de modification pour le corriger.

A l’issue de cette étape, on obtient le code complet, le DTI complété des résultats des tests d’intégration, les rapports
d’anomalie, et toutes les informations nécessaires à la reconstruction de l’application à partir des unités de compilation.

Étape de validation
Cette étape consiste à exécuter les tests de validation afin de vérifier que le code résultant de la phase d’intégration,
proposé comme solution au problème posé en phase de spécification fonctionnelle est effectivement conforme aux
spécifications établies pendant cette étape :
• exécuter les tests de validation tels qu’ils sont définis dans le DTV,
• comparer les résultats obtenus aux résultats attendus et les consigner dans le DTV, en cas d’anomalie, localiser
l’origine et suivre la procédure de modification pour corriger le défaut identifié.

A l’issue de cette étape, on dispose de l’application validée satisfaisant les besoins exprimés en phase de spécification
ainsi que le DTV complété.

La figure A.2 permet de visualiser, en regard de chaque étape du cycle de développement, les documents issus du
processus de réalisation.

DSFB PVA
MU spécification DTV complété
validation DSFB : Document de Spécification
PVA fonctionnelle DTV
Fonctionnelle des besoins
DSFB-MU MU : Manuel d'Utilisation
DCP
PI conception PI PVA : Plan de Validation
intégration DTI complété
DTV préliminaire DTI DCP : Document de Conception
MU mis à jour Préliminaire
DCP-MU Listage mis à jour
PI : Plan d'Intégration
DCD conception tests
DTI DTU DTV : Document de tests de validation
détaillée DTU unitaires DCD : Document de Conception
DTU
DCD Détaillée
DTI : Document de Tests d'Intégration
Listage codage DTU : Document de Tests Unitaires

Figure A.2 : Interaction des documents dans le cycle de développement en V

Annexe A 5
1 Annexe B
A NNEXE B : P ROCÉDÉ DE FABRICATION DE MÉLANGE

Le procédé est une usine de fabrication d’un mélange chimique (de la peinture par exemple, la nature du produit
fabriqué n’est pas importante, mais donne juste une idée du procédé considéré) comportant un ensemble d’éléments
couramment rencontrés en situation réelle (convoyeurs, machines, actionneurs, capteurs…). Le mélange fabriqué (appelé
produit final) est composé de différentes matières premières livrées en granulé plus ou moins fin additionnées d’un solvant
dans la phase finale de la fabrication. L’usine est composé de 14 cellules : 13 stations de mélange et une cellule de solvant.

Les cellules de mélange regroupent principalement : des trémies de produits sec (matière première au mélange), des
bascules de pesée, des convoyeurs (plusieurs km) pour acheminer les produits, un broyeur (pour certaines cellules), une
cuve avec mélangeur équipé d’un système de chauffage (fig. B.1, cf. aussi fig. B.2 décrite plus loin).

Figure B.1 : Description de l’installation complète

Annexe B 1
2 Annexe B

La figure B.2 représente une cellule simplifiée, à l’image de ce qu’elle est réellement sur site.

6
nettoyage auto
6
nettoyage auto
(1)
trémie 1

6
trémie 2 nettoyage auto
(2)
V1 6
nettoyage auto
V2
bascule 1 trémie 3

(3) V3 bascule 2
trémie 4
V4

BR
(4) bascule 3

BR
bascule 4
Broyeur
BR

BR BR

solvant
Vs (5)
P Moteur

eau froide
vers chaudière
(6)
T T
Mélangeur

cuve vers module suivant

eau chaude

eau chaude

Vc

container container
(CPF) (CPF) Station de mélange
3éme génération (G3A)

Figure B.2 : Description d’une cellule de fabrication de produit chimique

Quatre générations de cellules de mélange plus ou moins évoluées existent sur site, l’installation complète comporte
donc :
• 5 cellules G1A à G1E avec 2 trémies, pouvant mélanger 2 types de produits différents, les circuits de chauffage des
cuves de mélange sont couplés 2 à 2.
• 3 cellules G2A à G2C avec 3 trémies pouvant broyer jusqu’à 2 types de produits différents et les mélanger à un
troisième non broyé, les circuits de chauffage des cuves de mélange sont couplés à 3.
• 3 cellules G3A à G3C avec 4 trémies pouvant broyer jusqu’à 2 types de produits différents et les mélanger à 2
autres non broyés, les circuits de chauffage des cuves de mélange sont couplés à 3.
• 2 cellules G4A et G4B avec 2 trémies couvertes et 2 non-couvertes pouvant broyer jusqu’à 2 types de produits
différents dont un toxique et les mélanger à 2 autres non broyé dont un toxique, les circuits de chauffage des cuves
de mélange sont couplés à 2.

Annexe B 2
3 Annexe B

A noter que lors d’un mélange dans une cellule, toutes les trémies ne sont pas forcément utilisés. Par exemple dans une
cellule G3A à 4 trémies, seuls 2 trémies peuvent être utilisées avec seulement un seul produit à broyer.

Dans un souci pédagogique nous expliquons ci-dessous le fonctionnement d’une cellule de mélange de produit. Les
douze autres fonctionnent sur le même principe.
• La matière première est stockée dans les trémies (1), leur remplissage est assuré par une équipe de manutention
sous l’autorité de l’opérateur de supervision. Il y a 6 types différents de matières premières dont 1 toxiques : les
produits A, B, C, D, E et T (toxique). Le mélange final peut être composé au minimum de 2 produits différents, et
au maximum de 6 produits (selon la recette), avec toujours l’addition du solvant S en fin de fabrication.
• La quantité de matière première nécessaire au mélange est obtenue par pesage électronique (2), géré par le
calculateur.
• Un réseau de convoyeur (3) de plusieurs kilomètres (simplifié sur le schéma) achemine la matière première
jusqu’au mélangeur en passant ou non par un broyeur. Les “restes” de produits éventuels sur les convoyeur (en cas
de dysfonctionnement) sont gérés et signalés par les manutentionnaire et récupéré dans des bacs de récupération
BR.
• Certains granulés doivent être réduis en poudre avant le mélange. Dans ce cas ils passent par un broyeur (4) réglable
manuellement par l’équipe de manutention sous l’autorité de l’opérateur de supervision.
• Après pesage et broyage, les produits sont mélangés dans la cuve du mélangeur (5). Une quantité déterminée de
solvant est additionnée pendant le mélange. De plus, pour obtenir un produit final homogène, celui-ci doit être
effectué à température constante. C’est pourquoi la cuve du mélangeur est équipée d’un système de régulation de
température (6). Ce système est composé d’une circulation d’eau chaude ou froide autour de la cuve. Ce circuit de
chauffage est groupé par stations. Ainsi, l’eau chaude utilisée dans une cellule est réutilisée dans la suivante (voir
fig. B.1).
• Une fois le temps de mélange terminé, le produit final est récupéré dans des containers puis expédié par l’équipe de
manutention. Deux containers sont positionnés sous la cuve du mélangeur ; le passage à l’un ou l’autre est réalisé
automatiquement par le calculateur.

L’usine fonctionne en continu et fabrique plusieurs mélanges en parallèle. Au vu de la configuration des cellules, la
fabrication nécessite le passage dans plusieurs cellules parfois différentes : un mélange récupéré en sortie de la cuve
(appelé produit intermédiaire), pourra être réutilisé en entrée d’une cellule. L’ordonnancement de l’occupation des stations
de mélange (matière première, produit fabriqué) est planifié à l’avance. Ainsi, un mélange peut circuler dans plusieurs
cellules en passant par des étapes d’attentes. De plus, la quantité de produit mélangé est identique dans chaque cellule et
les commandes de produits sont souvent très supérieurs à cette quantité ; le mélange final est divisé en autant
d’échantillons nécessaires qui seront fabriqués séparément.

Toute cette installation doit être supervisée par un opérateur dans une salle de contrôle centralisé, celui-ci doit pouvoir
intervenir sur tous les automatismes et les conduire en manuel le cas échéant. Une maquette de l’interface de supervision a
été réalisée pour permettre de contrôler le procédé, elle doit permettre de visualiser la fabrication des mélanges dans les
différentes cellules et intervenir en cas de problèmes soit anticiper sur l’évolution du procédé (annexe C).

La figure B.3 représente les quatre cellules simplifiées, en les mettant en vis-à-vis pour visualiser facilement
l’évolution.

Annexe B 3
4 Annexe B

nettoyage auto 6

nettoyage auto 6

silos 1

silos 2
6
nettoyage auto V1

nettoyage auto 6 V2
bascule 1 6
nettoyage auto
silos 1 bascule 2
V3
convoyeur 1 V4
silos 2
silos 3
convoyeur 2
V1
bac de bac de
V2 récupération récupération
solvant bascule 1
Moteur Broyeur (BR) (BR)
bascule 2 bascule 3
Vs V3
convoyeur 1
P V4
convoyeur 2
convoyeur 3
eau froide
vers chaudière bac de
solvant
récupération
T T (BR)
Mélangeur
Vs

P Moteur
vers module suivant
eau chaude
eau froide
vers chaudière
eau chaude
T Mélangeur T

Vc
vers module suivant
eau chaude

eau chaude
container container
(CPF) (CPF) Vc

container container
(CPF) (CPF)
Station de mélange
Station de mélange 2éme génération (G2A)
1ére génération (G1A)

6
6
nettoyage auto 6
6 nettoyage auto
nettoyage auto
silos 1
trémie 1
6
6
T silos 2
trémie 2 nettoyage auto

V1 6
V1 6 nettoyage auto
nettoyage auto V2
V2 bascule 1 silos 3
bascule 1 trémie 3
bascule 2 T
bascule 2 V3
V3 silos 4
trémie 4 V4
V4
BRS
BR bascule 3
bascule 3
BR
BR
bascule 4
bascule 4 Broyeur
Broyeur
BRS
BR

BR
BR BR BRS

solvant solvant
Vs Moteur
Vs
P Moteur
eau froide P
vers chaudière
eau froide
vers chaudière
T Mélangeur T
T T
Mélangeur

cuve vers module suivant

eau chaude
vers module suivant
eau chaude
eau chaude
eau chaude
Vc
Vc

container container container container

(CPF) (CPF)
Station de mélange (CPF) (CPF) Station de mélange
3éme génération (G3A) 4éme génération (G4A)

Figure B.3 : Description des 4 cellules de fabrication de produit chimique

Annexe B 4
5 Annexe B
A NNEXE C : M AQUETTE DE L’ IMAGERIE DE SUPERVISION DU PROCÉDÉ DE MÉLANGE

REMARQUE IMPORTANTE : Les figures suivantes représentent les différents vues réalisées pour la maquette de
l’imagerie de supervision du procédé de mélange. Les vues originales ont été dessinées à la main par les concepteurs,
voir les exemples présentés dans le chapitre IV. Dans un souci de clarté de reproduction celles-ci ont du être redessinées
au moyen d’un éditeur graphique, nous nous sommes attachés à reproduire intégralement et garder intactes les
propositions qui ont été faites.

Toutes les informations suivantes sont celles fournies par les concepteurs de l’imagerie de supervision du procédé de
mélange proposée (Jouglet et al. 94). Cette annexe constitue en quelque sorte une partie du dossier de conception de la
maquette.

Toutes les vues sont structurées en cinq zones spécifiques (indiquées sur la première vue) : le titre de la vue, le
contexte, les commandes, une zone d’aide avec des messages et la fenêtre principale au centre qui peut être enrichie pour
certaines vues d’une fenêtre de détail.

La fenêtre de contexte mise à la disposition du superviseur est chargée d’informer l’OH sur l’avancement de la
production, par exemple par la visualisation du temps de mélange, de l’état de la cellule, des produits mélangés. Ce retour
d’information lui permet d’évaluer ce qu’il est en train de faire et lui indique les différentes possibilités à partir de sa
position courante.

Le premier écran (fig. C.1) correspond à l’écran principal de l’interface. Il permet de visualiser simultanément toutes
les cellules en fonctionnement. C’est à partir de celui-ci que l’on peut accéder à l’arborescence des vues. L’opérateur de
supervision peut y revenir à tout moment par action sur le bouton menu principal. Il y a trois niveaux de vues dans
l’enchaînement :
• la vue principale (fig. C.1),
• les vues des recettes, des alarmes, des tendances (ou trends), des cellules de fabrication, de la cellule solvant (fig.
C.2, C.3, C.4, C.5, C.6)
• les fenêtres détaillées (fig. C.8 et C.9) qui apparaissant dans la fenêtre des vues des cellules et du solvant (fig. C.7a
et b).

VUE PRINCIPALE Date: 07/06/94 Heure: 9:22:12

zone de titre
Légende des vues Alarmes
étoiles :
LO : Low contexte Recettes
HI : High Bloquée Active Bloquée Active Active
EM : Emergency Températures

message change et
C1 évolution de la couleur en fonction de l'état cellule
LO
C7 C2
L
O HI
1 2 3 4 5
LO
HI
HI
Active En Active Active Hors
LO
HI EM attente service
HI
LO
C6 HI C3 zone de
HI commandes
LO
LO

C5 C4 6 7 8 9 10
C8
C14 LO Hors Active Active Coupure
C9 service liaison
L
O HI LO
HI
HI

C13 LO
HI EM Cellule
HI
LO
slovant
HI
HI
C10 11 12 13 14
LO
LO

C12 C11 aide et message

Pour plus de détails, cliquer deux fois sur la cellule

Figure C.1 : Écran de la vue principale

Trois paramètres importants concernant l’état de la cellule, l’apparition des alarmes sur la cellule

Annexe B 5
6 Annexe B

concernée et son degré de gravité sont présentés. A gauche sur l’écran, un moyen original de représenter
synthétiquement le fonctionnement des quatorze cellules y est proposé Ainsi, le degré de gravité, représenté par quatre
états (normal, LOw, HIgh, et EMergency ), est affiché par une pseudo vue étoile (“septogone” lorsque tout va bien). Par
exemple, sur la vue présentée, la cellule 3 est en EM, la 2 en LO, la 1 en HI…

D’après les concepteurs, ce mode de représentation permet de détecter plus rapidement l’apparition d’une alarme, par
déformation de la vue : le degré d’importance guidera l’opérateur dans le choix des priorités d’action.

Parallèlement à ces deux étoiles, 14 rectangles symbolisent les cellules ; un code de couleur ainsi qu’un libellé donnent
l’état de la cellule.

A partir de cette vue, l’opérateur peut aller à n’importe quel point de l’imagerie : la vue des recettes des mélanges (fig.
C.2), la vue des alarmes (fig. C.3), les trends de température (fig. C.4), les quatorze écrans représentant les cellules de
fabrication sans ou avec fenêtre de détail (fig. C.7a et C.8) et la cellule de solvant sans ou avec fenêtre de détail (fig. C.7b
et C.9).

La figure C.2 représente la vue de gestion des recettes des mélanges, accessible par action sur un bouton de commande
depuis la vue principale.

RECETTES Date: 07/06/94 Heure: 9:22:12

Modification de la
recette Nouvelle
N°02 sur l'unité N°03 N°01 unité 02 Modification
N°02 unité 02
N°01 unité 03 Récapitulatif
N°02 unité 03
N°03 unité 03 Menu
N°01 unité 04
N°01 unité 05

N° Recette 02 N° Unité 03
Trémie N°01 Produit A % produit 30%
Trémie N°02 Produit B % produit 20%
Trémie N°03 Produit E % produit 10%
Trémie N°04 Produit D % produit
Solvant % produit 20%
Total 80%

Quantité totale de mélange kg

Ordre d'exécution de la recette
Vitesse de rotation du mélangeur tr/mn
Temps de mélange mn
Température du mélange °C
Ecartement broyeur mm

Erreur ! le total des % doit être de 100%

Figure C.2 : Écran de gestion des recettes

La recette regroupe toutes les données nécessaires à la fabrication du produit. Il comprend entre autre les proportions
de matières première et de solvant, le temps de mélange, la température… Tous ces éléments sont regroupés sur une vue
que doit initialiser l’opérateur en début de poste. Chaque élément est entré sous un format préétabli, un contrôle
automatique est effectué à chaque saisie afin d’éliminer toute erreur. L’opérateur a la possibilité de visualiser toutes les
recettes mémorisées. Cette tâche est indispensable lors des changements de poste, afin de garantir un suivi. A noter que des
modifications peuvent y être apportées à tout moment par l’opérateur, qui est le seul autorisé à y intervenir.

La figure C.3 représente la vue de gestion des alarmes, accessible par action sur un bouton de commande depuis la vue
principale.

Pour chaque alarme son libellé, le degré de gravité, le numéro d’unité sur laquelle elle est intervenue, la date et l’heure
de son apparition, et un indicateur de non acquittement (*) sont donnés. Tant que l’opérateur n’a pas acquitté l’alarme,
l’indicateur reste affiché. Dans le cas contraire,

Annexe B 6
7 Annexe B

l’indicateur disparaît, et l’alarme s’efface lorsque le problème est totalement résolu. Les alarmes sont classées dans
l’ordre décroissant de leur apparition. Elles sont également mémorisées dans un fichier de données, qui peut être à tout
moment visualisé et imprimé.

ALARMES Date: 07/06/94 Heure: 9:22:12

Légende : Sélectionner
EM : Emergency & visualiser
HI : High
LO : Low Sélectionner
& imprimer

Menu

* HI unité 01 Défaut température 02/06/94 08:10:26

* EM unité 03 Mélangeur arrété 02/06/94 08:09:11
* LO unité 06 BR non présent 02/06/94 08:05:50
* LO unité 02 BR non présent 02/06/94 07:59:20
* HI unité 14 Niveau bas trémie N°01 02/06/94 07:43:07
EM unité 03 Défaut poids bascule 02/06/94 07:33:05
LO unité 10 Container non-présent 02/06/94 07:15:31
LO unité 10 Container plein 02/06/94 07:11:28
HI unité 14 Paramètres chimiques incorrectes 02/06/94 06:59:57
EM unité 14 Cuve intermédiaire solvant niveau bas 02/06/94 06:55:35
EM unité 14 Bruleur éteint 02/06/94 06:40:31
LO unité 13 Convoyeurs silos en marche arrière en manuel
02/06/94 06:37:26
LO unité 13 Convoyeurs silos en marche arrière en manuel
02/06/94 06:37:25
LO unité 13 Vannes trèmie ouverte en manuel 02/06/94 06:30:31
LO unité 13 Vannes bascule ouverte en manuel 02/06/94 06:30:28
HI unité 14 Défaut température 02/06/94 06:10:58
……… ……… ………
……… ……… ………

Figure C.3 : Écran de gestion des alarmes

La figure C.4 représente la vue de visualisation des températures de mélanges, accessible par action sur un bouton de
commande depuis la vue principale.

TRENDS TEMPÉRATURE CELLULES Date: 07/06/94 Heure: 9:22:12

Affichage Trend Vers écran

écran 2/4 1/4

Vers écran
3/4

Menu

T°C Unité 05 T°C Unité 06

40 40
30 30
20 20
10 10

5 10 15 20 25 to temps 5 10 15 20 25 to temps
(mn) (mn)

T°C T°C
Unité 07 Unité 08
40 40
30 30
20 20
10 10

5 10 15 20 25 to temps 5 10 15 20 25 to temps
(mn) (mn)

Pour visualiser les autres unités, utiliser les fonctions à droite de l'écran

Figure C.4 : Écran de suivi des températures

Les trends de température de chaque cellule sont représentés sur des vues spécifiques qui regroupent quatre cellules à
chaque fois. Lors de l’analyse, la température est apparue comme un paramètre important, pour l’installation, la sécurité et
la qualité du produit. Comme la température a une grande constante de temps, les variations sont difficilement décelables
sur un simple compteur, c’est pourquoi les trends, permettent de détecter les dérives. D’après les concepteurs, cette vue
doit
Annexe B 7
8 Annexe B

permettre une anticipation sur la régulation de la température.

Afin de faciliter la lisibilité des courbes et des échelles, seulement quatre trends sont représentés par vue. L’opérateur a
toutefois la possibilité de se déplacer latéralement parmi les quatre vues dans l’ordre de son choix.

Le fonctionnement de l’unité est représenté sur un synoptique, ressemblant au schéma représentatif de l’installation du
site. Les figure C.5 et 6 représentent respectivement une des 13 vues de visualisation de la cellule de fabrication et la vue
de visualisation de la cellule solvant. Ces écrans sont accessibles par action sur un bouton de commande ou sur le bloc
correspondant depuis la vue principale.

Cellule fabrication n°03 Date: 07/06/94 Heure: 9:22:12

Fabrication : trémie 1 trémie 2 trémie 3 trémie 4

trémie 1 Détails
active/bloquée/arrétée trémie 2
trémie 3 Cellule
Temps de mélange trémie 4 solvant
température
0% 25% 50% 75% 100% convoyeur Cellule fab.
broyeur n°02
cuve mélangeur
arrivée solvant Cellule fab.
n°02

Procédure
nettoyage
convoyeur 1 BR
couple Menu
broyeur convoyeur 2 BR
(M.m) Fabrication
convoyeur 3 BR
30
convoyeur 4 BR Reprise
arrivée solvant
5 Arrêt
Mélangeur débit solvant
BR 1,53 m3/h
eau froide
100 100

eau chaude

10 10
T° cuve Vitesse
(°C) mélangeur
(Tr/mn)

Pour plus de détails sur un élément, cliquer dessus

Figure C.5 : Écran de visualisation de la cellule de fabrication

Cellule solvant Date: 07/06/94 Heure: 9:22:12

Fabrication : active cuve MP 1 cuve MP 2 cuve MP 3

cuve MP 1 Détails
H H cuve
H MP 2
cuve MP 3 vers cellule
Temps de mélange cuve mélange fabrication
cuve stockage
0% 25% 50% 75% 100% bruleur Menu

Arrêt

Reprise
B B B
cuve mélange
H
débit
T°cuve 5 m3/h
1100

300

B
Bruleur
cuve stockage

Pour plus de détails sur un élément, cliquer dessus

Figure C.6 : Écran de visualisation de la cellule solvant

Annexe B 8
9 Annexe B

Pour ces deux vues, tous les paramètres importants issus de l’analyse y sont affichés. Les principales informations sont
pour la cellule de fabrication : la température, la vitesse de rotation du mélangeur et le couple du broyeur, qui sont
représentées par des barre-graphes couplés avec des valeurs numériques précises. Il faut en effet une représentation
dynamique pour effectuer une anticipation. Un code des couleurs est associé pour les autres organes de la chaîne : ce code
correspond à la fois aux normes de la littérature, et à la logique de fonctionnement (par exemple le vert pour une marche
normale, le rouge pour un problème ou un danger).

Pour ne pas surcharger les vues des cellules fabrication, les concepteurs ont choisi d’afficher seulement les éléments
qui apportent des informations sur l’état de la cellule. Ainsi, un élément de la station de mélange qui n’est pas en
fonctionnement, n’est pas affiché sur l’écran. Par exemple, une vanne à l’état fermée est affichée alors que l’état ouvert est
représenté par la canalisation libre, laissant circuler le produit. La mesure du débit sera affichée seulement lorsque la
canalisation débite du produit. Les bacs de récupération de produit (BR) sont affichés que s’ils sont présent, le barregraphe
du couple broyeur que si le broyeur est en fonctionnement. Le sens de circulation d’un convoyeur est indiqué s’il est en
fonctionnement sinon le convoyeur est effacé… Seules les éléments ne changeant pas d’état pendant la fabrication restent
toujours à l’écran (trémies, bascules, broyeur et cuve de mélange).

En ce qui concerne les commandes, l’opérateur a entre autre la possibilité de :

• se déplacer entre les vues des cellules, sans devoir remonter à la vue globale,
• choisir l’affichage ou non d’une vue détaillée lui donnant des informations supplémentaires figures C.7a et 7b. La
figure C.8 présente les fenêtres de détail pour le fabrication et C.9 pour le solvant,
• autoriser la production automatique ou son arrêt,
• autoriser le nettoyage complet ou partiel de l’installation.

Les commandes ayant une action sur l’installation sont généralement protégées par un mot de passe. En effet, seul le
superviseur a la responsabilité de ces commandes.

Détail broyeur - Cellule fabrication n°03 Date: 07/06/94 Heure: 9:22:12

Fabrication : trémie 1 trémie 2 trémie 3 trémie 4

Détails
active/bloquée/arrétée
Cellule
Temps de mélange solvant
0% 25% 50% 75% 100% Cellule fab.
n°02

Cellule fab.
n°02

Procédure
nettoyage
convoyeur 1 BR
Menu
convoyeur 1
Fabrication
convoyeur 1

convoyeur 1 Reprise
BR
arrivée solvant
Arrêt
Mélangeur débit solvant broyeur : arrêt
BR 1,53 m3/h Couple
eau froide Nm
3
100 100
2

60 60 1
eau chaude tps
20 15 10 5 t0 mn
écartement: 5mm
10 10 Couple = 0Nm
T° cuve Vitesse seuil h. 1,5 Nm
(°C) mélangeur
(Tr/mn)
BR

Pour plus de détails sur un élément, cliquer dessus

Figure C.7a : Écran de visualisation de la cellule de fabrication avec fenêtre de détail

(ici cuve mélangeur)

Annexe B 9
10 Annexe B

Détail cuve mélange - Cellule solvant Date: 07/06/94 Heure: 9:22:12

Fabrication : active cuve MP 1 cuve MP 2 cuve MP 3

Détails
H H H
vers cellule
Temps de mélange fabrication

0% 25% 50% 75% 100%

Menu

Arrêt

Reprise
B B B
cuve mélange
H
débit
T°cuve 5 m3/h

paramètres
chimiques
H PH= 6,8
débit 5m3/h TH= 15
300
consigne 35°C
niveau
Haut T°= 35°C
seuil h. 50°C
seuil b. 20°C
P= 1bar
B
seuil h. 3bars
B
Bruleur niveau
cuve stockage Bas débit= 2m3/h

Figure C.7b : Écran de visualisation de la cellule solvant avec fenêtre de détail (ici cuve mélangeur)

Les figures C.8 et 9 présentent les fenêtres de détail qui viennent se placer en bas à droite dans les vues synoptiques de
visualisation fabrication et de visualisation solvant. Lorsqu’elles sont affichées, les éléments représentés dans ces vues
sont toujours visible quelque soit l’état de fonctionnement de la station correspondante.

Trémie : marche/arrêt/bloquée convoyeur : marche/arrêt/bloquée broyeur : arrêt

température
T°C Couple
trémie 1 poids 30 Nm
convoyeur 1 3
kg
BR 20 2
200
10 1
convoyeur 1 tps tps
chaud 20 15 10 5 t0 mn 20 15 10 5 t0 mn
BR
100
écartement: 5mm
convoyeur 1 consigne : 19°C Couple = 0Nm
tps cuve
BR T°= 19°C seuil h. 1,5 Nm
20 15 10 5 t0 mn
convoyeur 1 seuil h. 30°C
seuil b. 12°C
poids = 1500,00 Kg BR froid BR

cuve mélangeur: marche

procédure de nettoyage: marche/arrêt arrivée solvant

N= 1050tr/mn C= 0,5N.m
seuil h. 2000 seuil h. 2N.m
Marche Arrêt
consigne: 18°C
débit
T°=18°C
(m3/h)
seuil h. 30°C Temps de nettoyage
seuil b. 12°C débit 2
0m3/h 0% 25% 50% 75% 100%
1
tps
débit
20 15 10 5 t0 mn
0m3/h

Figure C.8 : Fenêtres de détail de la cellule de fabrication

débit Om3/h paramètres cuve stockage Bruleur : marche cuve MP 1 débit

chimiques
débit 10m3/h m3/h
PH= 6,8
TH= 15 2
débit Om3/h consigne : 700°C
T = 725°C 1
consigne 35°C seuil h. 1100°C
niveau
T°= 35°C N= 75% seuil b. 300°C
Haut
seuil h. 50°C N= 1000 tr/mn 20 15 10 5 t0 tps
seuil b. 20°C seuil haut mn
P= 1bar 3000 tr/mn
débit= 0 m3/h
seuil h. 3bars
débit= 2m3/h
débit = 0m3/h
niveau
Bas débit 0m3/h débit= 0 m3/h

Figure C.9 : fenêtre de détail de la cellule solvant

Annexe B 10
1 Annexe D
A NNEXE D : Q UELQUES PISTES DE RECHERCHE DE MÉTHODES
D ’ ESTIMATION DES CRITÈRES ERGONOMIQUES D ’ ÉVALUATION

Dans le but d’illustrer quelques “métriques” d’estimation des critères ergonomiques d’évaluation et de prouver la
faisabilité de la démarche d’évaluation proposée, nous présentons ci-dessous quelques exemples de méthodes utilisables.
Celles-ci ont été utilisées sur le cas d’étude proposé dans notre mémoire. Bien entendu, ces “métriques” ne sont pas à
appliquer telles quelles à tous les cas, elles doivent être étudiées, critiquées, améliorées et surtout validées.

Exemple d’estimation du critère d’incitation

Incitation : Informations fournies à l’utilisateur sur l’état dans lequel il se trouve, actions possibles ou attendues et
moyens de les mettre en œuvre (aides disponibles, format adéquat d’entrées, unités de mesure…).

Lors de l’étape de spécification fonctionnelle : Lors de cette étape, c’est le niveau conceptuel de l’interaction qui est décrit.
Les modèles utilisés pour la décomposition hiérarchique des tâches renseignent sur les concepts utilisés lors de l’interaction avec
l’application : les objets manipulés par l’utilisateur, les relations entre objets, leurs attributs et propriétés, les opérations
possibles. Si toutes ces informations ne sont pas spécifiées, elles ne seront pas conçues et donc pas visibles sur l’IHM. Ce sont
pourtant celles-ci qui permettent de conseiller, orienter, informer et guider l’utilisateur pour la réalisation de sa tâche.

Lister et comptabiliser les éléments renseignés dans les descriptions contribue à une première estimation de l’incitation (voir
les plans de HTA). Le tableau D.1 présente un premier exemple pour les tâches surveiller les paramètres principaux de la
cellule 1 (T1) et gérer les recettes (T15) à partir des informations des figures V.9 et V.10 du chapitre V.
Tableau D.1 : Estimation de l’incitation sur une description hiérarchique de tâche
Tâche “surveiller les paramètres principaux de la cellule 1” (T 1)
But: Évaluer l’état global de la cellule… +1
Indices (type, niveau, numéro, parmi, parent): renseignés +1
Relation: T1.1 à T1.9, T17 et T2 à T13 +1
Paramètres manipulés: état des différents éléments, recette du mélange +1
Outils utilisés/ interaction: écran, clavier, souris, radio-téléphone +1
Pré conditions: non renseignés 0
post conditions: non renseignés 0
Note d’incitation ramenée sur 10 : 7
Tâche “gérer les recettes” (T15)
But: décrire le mode de fabrication d’un ou de différents produits +1
Indices (type, niveau, numéro, parmi, parent): renseignés +1
Relation: T15.1 à T15.3, T1 à T13 +1
Paramètres manipulés: n°recette, n°cellule, noms du mélange et des produits… +1
Outils utilisés/ interaction: écran, clavier, souris +1
Pré conditions: renseignés +1
post conditions: renseignés +1
Note d’incitation ramenée sur 10 : 10

Dans la proposition, chaque élément renseigné incrémente de 1 la note du critère d’incitation de la tâche. Notons qu’il
serait plus judicieux de pondérer les informations apportées ou non en fonction de leur importance par rapport au critère.
Ainsi, une information non fournie peut fortement pénaliser le critère, par exemple les pré-conditions et post-conditions
sont très importantes dans la définition de l’interaction.

L’exemple du tableau montre que l’incitation au niveau du guidage pour la réalisation de la tâche “gérer les recettes”
est mieux prise en compte que pour la tâche “surveiller les paramètres principaux de la cellule 1” (note d’incitation de
10/10 au lieu de 7/10). Ce manque de précision dans les spécifications de la tâche risque de se répercuter sur l’interface,
puisque les données utilisées pour construire le modèle a priori doivent être utilisées dans les phases suivantes de
conception jusqu’à la réalisation. Ainsi il faut apporter plus de précision dans les spécifications fonctionnelles de la tâche
de visualisation de la cellule de mélange ; ici l’effort doit être porté sur les pré et post-conditions.

Lors de l’étape de Conception préliminaire : Pour estimer le critère d’incitation avec les descriptions CLG, il faut y
recenser tous les objets qui apportent des informations sur la situation du dialogue homme-machine (position, états
antérieur et postérieur), les opérations possibles, et les aides. Ainsi, les commandes informent, avec des boutons, des
Annexe D 1
2 Annexe D
actions accessibles au niveau inférieur mais pas du cheminement pour y arriver. Par exemple, l’entité contexte a pour but
de présenter l’évolution de la cellule de fabrication correspondante. De plus on constate qu’une entité d’aide a été prévue
alors qu’elle n’apparaissait pas dans la spécification fonctionnelle.

Exemple d’estimation des critères de charge de travail

Actions minimales : charge de travail au niveau des options ou moyens utilisés pour atteindre un but (minimiser
le nombre d’étapes de sélection, redondance d’entrées de données…).
Charge mentale : charge de travail perceptive et mnésique pour des ensembles d’éléments (procédures à
mémoriser courtes et peu nombreuses, densité d’informations faible…).

Le critère ergonomique relatif à la charge de travail nécessaire à l’utilisateur pour accomplir sa tâche regroupe les deux
sous-critères actions minimales et charge mentale. Ils sont liés ; c’est pourquoi il faut les estimer ensemble. Pour faire
apparaître cette charge dans un formalisme, Reisner (84, avec ALG) convertit les phrases de ce qui a été décrit en
équations de temps et d’erreurs sur lesquelles des calculs de prédiction sont ensuite effectués. La longueur des séquences
pour une tâche donnée est utilisée comme indice de la “simplicité des procédures”. Ces principes sont beaucoup trop
réducteurs : en effet une tâche facile à décrire peut être difficile à réaliser.

Lors de l’étape de spécification fonctionnelle : Avec ces réserves, nous nous en inspirons essentiellement dans un but
d’illustration, pour proposer une estimation des deux critères à partir de la description hiérarchique présentée dans le
chapitre V (figure V.8). Il ne s’agit pas ici de proposer une méthode de plus pour estimer la charge de travail (!), voir les
techniques présentées dans le chapitre II, mais d’essayer de proposer des idées de pistes pour mesurer la charge à partir de
descriptions formelles. Dans le cas d’une description sous la forme d’une arborescence, pour chaque tâche, la mesure peut
consister à mesurer la profondeur de l’arbre ou la longueur du chemin parcouru pour y parvenir. Le niveau le plus haut
dans l’arborescence correspond à une note de 0 ; à chaque changement de niveau, la note est incrémentée. La difficulté en
terme d’action minimale sera donc faible pour une petite valeur de la note.

Au vu de la description a priori de l’interaction homme-machine pour l’imagerie spécifiée lors de l’étape, le critère
d’actions minimales est faible car la profondeur de l’arbre est de 3 au maximum. Il correspond au niveau auquel il faut
descendre pour agir sur le processus. Le tableau D.2 présente les valeurs obtenues pour l’arborescence de la figure V.9
(chapitre V). Par exemple, le chemin à parcourir pour intervenir sur le convoyeur est décrit ci-dessous :

• A partir de la tâche “assurer la fabrication” : profondeur = 0,

• “surveiller les paramètres principaux de la cellule i” (T1) : profondeur = 1,

• “surveiller les convoyeurs” (T1.2) : profondeur = 2, mais la tâche T 1.2 ne précise pas que l’opérateur intervienne
sur les paramètres du convoyeur. D’après les informations fournies par les spécifications, il ne peut que surveiller
certaines variables relatives à l’état de fonctionnement du convoyeur. Cela sous-entend de descendre encore d’au
moins un niveau pour intervenir sur le convoyeur, soit au moins une profondeur de 3.

En ce qui concerne l’estimation du critère de charge mentale, nous partons par exemple de l’hypothèse (simpliste) que
le nombre d’éléments manipulés parmi ceux proposés pour réaliser la tâche est représentative de ce critère. La démarche
d’estimation consiste alors à comptabiliser le nombre total d’objets de même niveau à chaque nœud rencontré (plus le
nombre de tâches ou d’objets est grand plus la charge mentale est supposée élevée) et le nombre de sous-tâches filles
(beaucoup d’alternatives rendent la tâche plus difficile). De plus, une charge forte sur une tâche à la racine peut se
répercuter sur ses sous-tâches filles. C’est pourquoi nous proposons de prendre en compte la difficulté de réalisation des
tâches mères dans le calcul. Le critère de charge mentale peut donc être estimé au moyen de la formule D1.

Formule D1 : Estimation du critère de charge mentale de l’interface

⎧
⎪ CM ( T11 ) = Card E1
⎨
⎪ CM( Tij) = CM⎛ T(i −1)k ⎞ + N i + Card E j
⎩ ⎝ ⎠

avec :
CM(T) = Charge mentale de la tâche T

Annexe D 2
3 Annexe D
Tij = tâche j du niveau i, de parent T(i-1)k niveau 1
Ni = nombre de tâches au niveau i ……
……… ………
Card E j = Card {T( i+1) k Tij est le parent de T( i+1) k} T(i-1)k

niveau i Ti1 Tij Ti(j+1) ……

Ni = nombre de tâches
au niveau i
Card Ej = nombre de sous-tâches de la tâche j

Le tableau D.2 donne un exemple d’application de la formule avec la description de la figure V.9 (chapitre V). Les
résultats obtenus donnent une idée du niveau de difficulté pour réaliser la tâche correspondante, ils doivent être analysés
l’un par rapport à l’autre (telle tâche est plus difficile que telle autre, en terme d’action minimale).
Tableau D.2 : Estimation des actions minimales sur une description hiérarchique de tâche

Mesure du niveau des tâches Estimation

et énumération des sous-tâches des critères
Tâche (Tij) niveau sous-tâches nombre de Action CM (Tij)
même niv. sous-tâches minimale
0 assurer la fabrication 0 1 18 0 0+1+18=19
1…13 surveiller les paramètres principaux de la cellule i 1 18 9 = 46 (19+18+9)
14 contrôle les paramètres de température 1 18 ? > 37 (19+18+?)
15 gérer les recettes 1 18 3 =40 (19+18+3)
16 superviser la cellule solvant 1 18 ? 1 > 37 (19+18+?)
17 gérer la communication 1 18 3 =40 (19+18+3)
18 surveiller les paramètres principaux du processus 1 18 ? > 37 (19+18+?)
1.1 surveiller l’entrée des matière première. 2 9 ? > 55 (46+9+?)
1.2 surveiller convoyeurs 2 9 ? > 55 (46+9+?)
1.3 surveiller broyeur 2 9 ? > 55 (46+9+?)
1.4 surveiller cuve mélangeur 2 9 ? > 55 (46+9+?)
1.5 surveiller et ajuster les paramètres de température 2 9 ? > 55 (46+9+?)
1.6 surveiller et ajuster le débit solvant 2 9 ? 2 > 55 (46+9+?)
1.7 surveiller les paramètres d’exploitation 2 9 ? > 55 (46+9+?)
1.8 surveiller le mélange en sortie du processus 2 9 2 =57 (46+9+2)
1.9 demander le nettoyage cellule 2 9 ? > 55 (46+9+?)
etc … … … … …
1.8.1 surveiller la quantité de mélange sortie 3 2 0 = 59 (57+2+0)
1.8.2 surveiller la qualité du mélange sortie 3 2 0 3 = 59 (57+2+0)
etc … … … … …

On constate à la fois dans l’arborescence de la figure et par les résultats du tableau que certaines tâches manipulent
beaucoup d’éléments. Par exemple les tâches de surveillance des paramètres principaux des cellules sont attachées à un
nœud de 18 tâches et manipulent 9 sous-tâches non élémentaires qui se décomposent encore. Nous constatons d’ailleurs
que pour la description, la largeur de l’arbre est de 9. Le mode d’interaction associé devra permettre à l’opérateur de
manipuler toutes ces informations, et comportera donc beaucoup de fonctions (charge mentale grande). Par contre, comme
nous l’avons déjà signalé, le cheminement relativement faible pour accéder à la tâche (3 niveaux) vient compenser cette
difficulté.

Cette métrique pour estimer la charge de travail est bien entendu trop simple et mériterait de plus amples études qui
s’inscrivent dans nos perspectives concernant la recherche de métriques d’estimation des critères ergonomiques
d’évaluation.

En effet, l’analyse d’une description hiérarchique n’est pas simple, et on ne peut se limiter à des mesures de largeur et
de profondeur uniquement ; c’est pourquoi nous avons introduit les nœuds et les sous-tâches. Pour exploiter ces données,
il faut se référer aux calculs de complexité des arbres utilisés en algorithmique (décomposition en but/sous-buts ou
fin/moyens). De plus, pour mesurer la charge de travail lors de l’interaction homme-machine, il faut aussi prendre en
compte le chemin parcouru dans la communication réelle ; c’est-à-dire à la fois prédire les difficultés de l’opérateur pour
atteindre la tâche courante, mais aussi hériter de celles amont. Notons aussi qu’une tâche racine (ou mère) peut être a
priori considérée comme plus chargée que ses filles qui sont des décompositions du problème global en sous problèmes.
Annexe D 3
4 Annexe D
De plus, l’estimation que nous avons proposée se contente d’un parcours qui part de la racine de l’arbre vers les branches,
et non pas d’un état particulier dans la réalisation de la tâche globale vers l’état but recherché par l’opérateur (Fig. D.1).

propagation
propagation

Figure D.1 : Navigation dans une arborescence d’IHM lors de l’interaction

Lors de l’étape de conception préliminaire : Puisque les actions minimales sont fonction du nombre d’options ou de
moyens pour atteindre un but. L’analyse et l’énumération de toutes les options proposées par l’interface pour réaliser les
tâches élémentaires décrites dans la description CLG des méthodes et procédures sémantiques des opérations utilisateur
peuvent contribuer à son estimation.

Pour l’interface conçue, on constate que le volume d’informations à manipuler est relativement faible en terme
d’actions, simplement du fait que celle-ci ne permet pas à l’opérateur d’agir directement sur le procédé. De plus, une zone
dite de contexte a été prévue dans la conception de certains écrans (entité “contexte” dans la description CLG de la figure
V.15), mais celle-ci présente des informations concernant généralement l’état du système, et ne représente en aucun cas
“une trace” de l’activité de l’opérateur lui évitant de mémoriser le chemin parcouru dans les différents écrans pour
l’accomplissement de sa tâche.

Exemple d’estimation du critère d’adaptabilité

Adaptabilité : capacité du système à réagir selon le contexte, les besoins et préférences de l’utilisateur. L’IHM ne
peut convenir à la fois à tous les utilisateurs potentiels. Pour qu’elle n’ait pas d’effets négatifs, elle doit s’adapter.

Pour évaluer l’adaptabilité de l’interface, nous pouvons par exemple nous inspirer de listes de contrôle de la qualité des
logiciels (Forse 89). L’estimation qui a été utilisée dans notre cas, est basée sur la liste du tableau D.3. Celle-ci n’est pas
exhaustive, et des recommandations ergonomiques de la littérature peuvent bien entendu y être ajoutées (voir les grilles
d’évaluation du chapitre II). Un questionnaire du type de celui qui est présenté peut être prévu pour être utilisé lors des
étapes de spécification et de conception préliminaire. Comme on ne s’intéresse qu’aux spécifications, un indice niveau
peut avoir pour but “d’activer” ou non la question concernée. Ainsi, la même liste peut être utilisée dans les niveaux
inférieurs du développement.

Annexe D 4
5 Annexe D
Tableau D.3 : Questionnaire d’évaluation de l’adaptabilité de l’interface (adapté de Forse 89)
utilisée pour l’étape de spécification fonctionnelle (il est possible d’ajouter d’autres questions)
poids niveau réponse
1. Plusieurs niveaux correspondant à l’expérience des utilisateurs sont-ils mis en évidence ? 3 1 partiel.
2. Le dialogue homme-machine de l’interaction est-il flexible, permissif ? 2 0
3. Les utilisateurs peuvent-ils définir eux-même leur dialogue ? 1 0
4. les séquences de commandes correspondent-elles à l’expérience des utilisateurs ? 2 0
5. Les séquences de commandes usuelles sont-elles codées ? 1 0
6. L’utilisateur peut-il définir ses propres codes ? 1 0
7. Les procédures de configuration de l’interface sont-elles automatisées ? 1 1 oui
8. Y-a-t il plusieurs modes de navigation et sont-ils configurables ? 1 1 partiel.
9. Les caractéristiques vidéo sont-elles configurables ? 1 1 non
10. Y a-t-il plusieurs périphériques d’entrée-sortie et sont-ils configurables ? 1 1 non
11. Les mnémoniques de commandes sont-ils configurables ? 1 0

La démarche consiste à répondre aux questions au regard de la description a priori de l’interaction homme-machine et donc
de ce que sera l’interface. L’évaluation est subjective, elle demande de l’expérience de la part de l’évaluateur. Celui-ci répond
par oui, partiellement ou non à chaque question du niveau concerné, puis calcule la moyenne pondérée de l’ensemble des
réponses aux questions (formule D2) :

Formule D2 : Estimation de l’adaptabilité de l’interface (adapté de Forse 89)

n avec :
∑ ( poidsk × niveauk × réponsek ) n = nombre de questions de la liste
k=1 poids = facteur de pondération de la question k
AD = n k
∑ ( poidsk × niveauk ) réponsek = valeur de la réponse à la question k
k =1
1 si la réponse est oui
Le résultat est une valeur bornée entre 0 et 1 0,5 si la réponse est partiellement
0 si la réponse est non
niveauk = 1 si la question k est concernée à ce niveau
= 0 sinon
Calcul de l’adaptabilité lors de l’étape de spécification fonctionnelle :
3 × 1× 0,5 + 1× 1× 1+ 1× 1× 0, 5+ 1 × 1 × 0 + 1× 1× 0
AD = = 0, 42
3× 1+ 1× 1+ 1× 1 +1 × 1 +1 × 1

Dans notre cas, on constate après calcul que l’adaptabilité est plutôt mauvaise (0,42 par rapport à un maximum de 1).
On peut donc s’attendre à ce que l’interface qui sera réalisée à partir des spécifications étudiées soit peu flexible : aucune
tâche de personnalisation n’apparaît dans la description, ni dans les documents de spécification. Par ailleurs, l’interface ne
prend a priori pas en compte l’expérience de l’utilisateur ; par exemple, il n’y a pas de raccourci pour accéder plus
rapidement à des sous tâches ou actions élémentaires. De plus, comme aucun module d’aide n’est prévu à ce niveau,
l’apprentissage de l’utilisation de cette interface sans formation préalable, sera sans doute difficile.

Malgré les recommandations préconisées lors de l’étape de spécification fonctionnelle, l’estimation calculée par la
même formule mais avec les résultats obtenus lors de l’étape de conception préliminaire ne donne pas de résultat meilleur.
La moyenne pondérée avec toutes les questions donne 0,25 ce qui est encore moins bien que précédemment (O,42). Ce
constat nous amène à conclure que l’interface réalisée ne sera pas adaptable.

Annexe D 5
 DÉFINITION D’UN CADRE POUR L’ÉVALUATION A PRIORI
DES INTERFACES HOMME-MACHINE
DANS LES SYSTÈMES INDUSTRIELS DE SUPERVISION
Cette thèse s’inscrit dans le domaine de la communication homme-machine dans les systèmes industriels de supervision.
Elle s’articule autour de deux thèmes principaux qui sont l’analyse critique des méthodes et techniques d’évaluation, et la
définition d’un cadre pour l’évaluation a priori des IHM.
Après avoir défini l’espace de notre travail en présentant les systèmes homme-machine de supervision et leur cycle de
développement, le mémoire décrit la problématique de la recherche : l’évaluation des IHM de supervision. Après une
discussion des différentes situations d’évaluation —interface existante ou inexistante—, les méthodes et techniques
utilisables pour l’évaluation des IHM industrielles de supervision sont recensées selon trois approches : centrées sur les
utilisateurs, centrées sur une expertise humaine ou papier, et centrées sur une modélisation de l’interface et/ou de l’interaction
homme-machine. Il s’avère que ce sont surtout des évaluations à tendance empirique qui sont effectuées, après la réalisation
de l’IHM de supervision. Aussi, des lacunes introduites lors des étapes de spécification-conception sont détectées
tardivement alors qu’une évaluation a priori les aurait sans doute décelées plus tôt. C’est pourquoi un cadre pour faciliter
l’évaluation a priori des IHM, au cours du développement d’un système industriel de supervision, est ensuite défini. Celui-
ci est fondé sur une description de l’interaction homme-machine au moyen de modèles formels, cette formalisation est
structurée autour d’un canevas théorique spécifique. L’évaluation est ensuite réalisée par comparaison des modèles obtenus,
en s’intéressant aux propriétés de l’utilité et de l’utilisabilité de l’IHM.
Notre recherche a pour finalité de prendre en compte l’évaluation comme un processus parallèle à la conception et de
souligner qu’une équipe d’évaluation doit pouvoir utiliser un ensemble d’outils à chaque étape de la vie d’un système
homme-machine de supervision. Le cadre défini dans ce mémoire a été appliqué sur une maquette de laboratoire et débouche
sur plusieurs perspectives de recherches.

Mots clés : Interface Homme-Machine, conception-évaluation, cycle de développement, méthodes et techniques

d’évaluation, évaluation a priori, critères d’évaluation, systèmes industriels de supervision

DEFINITION OF A FRAMEWORK FOR THE A PRIORI EVALUATION

OF HUMAN-MACHINE INTERFACES
IN SUPERVISION INDUSTRIAL SYSTEMS

Summary

This Ph. D. thesis concerns the field of Human-Machine communication in supervision industrial systems. It deals with
two major topics, which are the critical analysis of evaluation methods and techniques, and the definition of a framework for
HMI a priori evaluation.
After defining our work space by the presentation of the Human-Machine supervision systems and their development
cycle, this thesis describes the research problem: the evaluation of supervision HMI. After a discussion about the different
evaluation situations —existent or nonexistent interface—, the methods and techniques usable for the evaluation of
supervision industrial HMI are classified into three approaches: one is centred on the users, the second one is centred on a
human or paper expertise, and the third one on a model of the interface and/or the Human-Machine interaction. It appears
that empirical evaluations mainly are realised, after the achievement of the supervision HMI. Therefore deficencies
introduced during specification-design steps are detected too late whereas an a priori evaluation would have revealed them
earlier. That is why a framework to facilitate the a priori evaluation of HMI, during the development of a supervision
industrial system, is defined then. It is based on a description of the human-machine interaction with the help of formal
models, this formalization is structured by a specific theoretical frame. This evaluation is then realised by comparing
obtained models, according to the HMI utility and usability.
The finality of our research work is to see the evaluation as a process paralleling the design and to underline that an
evaluation team should have at its disposal a set of tools for every step in the life of the supervision human-machine system.
The framework defined in this report has been applied in a laboratory and opens several research perspectives.

Key words : Human-Machine Interface, design-evaluation, development cycle, evaluation methods and techniques, a
priori evaluation, evaluation criteria, supervision industrial sytems