ACTES ERGOIA 2006.indd

10e EDITION - CONFERENCE INTERNATIONALE
ACTES DE LA CONFERENCE
Ergo'IA 2006
Bidart/Biarritz France
L'humain comme facteur
de performance
des systèmes complexes
11/12/13 Octobre 2006
6RXVODGLUHFWLRQVFLHQWLILTXHGH
E. Brangier - Université de Metz
C. Kolski - Université de Valenciennes
J.-R. Ruault - DGA
Edités par ESTIA & ESTIA.INNOVATION
ERGO-IA
2006
Manifestation organisée par :
ESTIA & ESTIA.INNOVATION
Techopole Izarbel – 64210 Bidart
Tél : 05 59 43 84 00 – Fax 05 59 43 84 01
E-mail : [email protected] – http://www.ergoia.estia.fr
PARRAINAGE SCIENTIFIQUE
ISBN 2-9514772-6-0
La loi du 11 Mars 1957 n’autorisant, aux termes des alinéas 2 et 3 de l’Article 41, d’une
part que les « copies ou reproduction strictement réservées à l’usage privé du copiste et non
destinées à une utilisation collective » et, d’autre part, que les analyses et les courtes
citations dans un but d’exemple et d’illustration, « toute représentation ou reproduction
intégrale ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou
ayants cause, est illicite » (alinéa 1er de l’article 40). Cette représentation ou reproduction,
par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les
Articles 425 et suivants du Code Pénal.
COMITE SCIENTIFIQUE
Présidence Scientifique
É. BRANGIER - C. KOLSKI - J-R. RUAULT
Université Paul Verlaine Metz & Université de Valenciennes & DGA
z Jean-François AUBRY,
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z Patrick GIRARD,
Institut de Sûreté Industrielle, Nancy
Jean-Paul BARTHES,
Université Technologique de Compiègne
Josiane BASQUE,
Télé-université du Quebec, Montréal
Christian BASTIEN, Université Paris V
Marc-Eric BOBILLIER CHAUMON,
Université Lyon 2
François BOILLEAU, Giat Industries
Guy BOURHIS, Université Metz
Christian BRASSAC, Université Nancy 2
Gaëlle CALVARY, Imag, Grenoble
Noëlle CARBONELL, Loria, Nancy
Valérie CASTEL, Giat Industries
Alain COHENCA,
Renault, Vice Président de l'AFIS
Daniel COINEAU, RATP
François DANIELLOU,
Université Bordeaux 2
Bertrand DAVID, ECL Lyon
Michel DESMARAIS,
Ecole Polytechnique de Montréal
Iñaki DORRONSORO,
Mondragon Corp.Cooperativa
Annie DROUIN, Consultante, Paris
Henri FANCHINI, Artis Facta
Daniel GALARRETA, CNES, Toulouse
Michel GALINIER, Thalès
Claude GERMAIN, Université Lyon 2
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
Université Poitiers, Président de l’AFIHM
Jean-Roch GUIRESSE, ESTIA
Florence HELLA, INRS Nancy
Alain LANCRY, Université Amiens
Valérie LEGUAY, DGA
Bruno MAGGI, Université Bologne
Odile MARTIAL, Consultante, Montréal
Gabriel MICHEL, Université Metz
Faouzi MOUSSA, Université de Tunis
Michel NEBOIT, Président de la Self
Anne-Sophie NYSSEN, Université de Liège
Dina NOTTE, Ergodin, Belgique
Philippe PALANQUE, Université Toulouse 3
Jean PARIES, Dédale
René PATESSON, Université Libre de Bruxelles
Gérard POULAIN, France Télécom R&D
Serge QUAZZOTTI,
CRP Henri Tudor, Luxembourg
Mouldi SAGAR, Université de Valenciennes
Dominique SCAPIN, INRIA
Jean-Claude SPERANDIO,
Pr Emérite Lab. Ergonomie Informatique, Paris V
Daniel TASSET,
D.G. de la Sûreté Nucléaire
et de la Radioprotection
Jean-Claude TUCOULOU,
Giat Industries, Dir. Scientifique de l'AFIS
Frédéric VANDERHAEGEN,
Université de Valenciennes
RELECTEURS ADDITIONNELS
z Emmanuel ADAM, LAMIH, Univ. Valenciennes
z Jean-Daniel FEKETE, INRIA Futurs, LRI, Orsay
z Virginie GOVAERE,
INRS, Vandoeuvre-les-Nancy
z Jean-Luc KOP, Labpsylor, Université Nancy 2
z
z
z
z
Karin LUNDGREN-CAYROL, LICEF, Montréal
Jacques MARC, INRS, Vandoeuvre-les-Nancy
Franck TARPIN-BERNARD, ICTT, Insa Lyon
Corinne VAN DE WEERDT,
INRS Vandoeuvre-les-Nancy
COMITE D’ORGANISATION
PRESIDENT
Jean-Marie BERCKMANS, Président de la CCI Bayonne Pays Basque
MEMBRES
Jean-Roch GUIRESSE, ESTIA
Sophie PAOLACCI, ESTIA.Innovation
Michèle ROUET, ESTIA
TABLE DES MATIERES
CONFERENCES INVITEES
Violations et migrations ordinaires dans les activités à risques : conséquences pour la
résilience globale et la gestion du retour d’expérience en entreprise
R. Amalberti (IMASSA) ................................................................................................................. 13
Génie système : à la croisée de la science et de l'art
A. Faisandier (Directeur, Map Système) ....................................................................................... 21
Vers un prototypage des interfaces graphiques incluant vraiment l'utilisateur final
J. Vanderdonckt (BCHI, Université de Louvain-La-Neuve) ........................................................... 31
ARTICLES LONGS DE RECHERCHE
Evaluation ergonomique d'un prototype de réalité augmentée par des tests utilisateurs :
apports et difficultés
M. Anastassova, Ch. Mégard (CEA, LIST), J.M. Burkhardt,
J. Breda (Unité d'ergonomie Paris 5) ............................................................................................ 45
Association des réseaux de Pétri et des critères d'ergonomie des logiciels pour la
modélisation et la réingénierie de systèmes interactifs, cas de la prescription thérapeutique
en milieu hospitalier
S. Bernonville (LAMIH, Valenciennes et EVALAB, Lille), N. Leroy (EVALAB), C. Kolski (LAMIH),
M.C. Beuscart-Zéphir (EVALAB)................................................................................................... 55
Mémoire des documents familiers : implications pour les systèmes de récupération de
fichiers
T. Blanc-Brude, D.L. Scapin (INRIA, Le Chesnay)........................................................................ 63
Elaboration et validation d'un questionnaire de mesure de l'acceptation des technologies de
l'information et de la communication basé sur le modèle de la symbiose humain-technologieorganisation
E. Brangier, S. Hammes (Univ. Metz, ETIC) ................................................................................. 71
Métamorphose des IHM et Plasticité : article de synthèse
G. Calvary, V. Ganneau, J. Coutaz, L. Balme, O. Dâassi, A. Demeure, J.S. Sottet (UJF CLIPS
IMAG, Grenoble)........................................................................................................................... 79
Importance of peer-to-peer ad hoc collaboration in the development of large software systems
S. Cherry, P.N. Robillard (Dpt génie informatique, Ecole Polytechnique Montréal) ...................... 87
Pour une meilleure prise en compte des opérateurs dans la conception de nouveaux produits
à partir d’une démarche d’évaluations combinées de l’activité
J. Fénix, J-C. Sagot, (UTBM) C. Valot (IMASSA) ........................................................................ 95
Performances et usages d'un environnement d'apprentissage de la programmation " basé sur
exemple "
N. Guibert, P. Girard, L. Guittet (LISI, Poitiers) ........................................................................... 103
Approches orientées services Web de l'IHM de supervision : nouvelles solutions
technologiques pour les ingénieurs et nouvelles problématiques pour les ergonomes ?
D. Idoughi (Univ. Mira, Algérie et LAMIH), C. Kolski (LAMIH, Valenciennes) ............................. 111
Les déterminants du choix d’une modalité d’interaction avec une interface multimodale
L. Karsenty (IntuiLab, Toulouse) ................................................................................................. 119
Usage des interactions verbales pour la conception d'applications interactives centrée Genre
M. Latapy, Ph. Lopistéguy, P. Dagorret, M. Gaio (LIUPPA, IUT Bayonne) ................................. 129
Supports pour la prise en compte des experts et utilisateurs dans le développement de
Systèmes Interactifs d'Aide à la Décision
S. Lepreux (LAMIH, Univ. Valenciennes).................................................................................... 139
Les modèles de tâches pour la contextualisation des composants
A. Lewandowski (LIL, Calais), J.-C.Tarby (Trigone, Lille), G. Bourguin (LIL, Calais) .................. 147
Interaction multimodale pour la recherché d’information d’une base de données de réunions
A. Lisowska (ISSCO Univ. Genève), M. Betrancourt (TECFA, Univ. Genève)............................ 155
La prise de décision en sport de haut niveau : un exemple chez une joueuse experte en
badminton
A.C. Macquet, Ph. Fleurance (Institut National du Sport, Paris) ................................................. 163
Démarche d'aide au choix des dispositifs pour l'ordinateur porté
G. Masserey, O. Champalle, B. David, R. Chalon (ICTT-ECL Lyon) .......................................... 171
Une proposition pour améliorer la performance de l'usager au sein du système d'information
global de la bibliothèque
F. Papy, S. Chauvin (Groupe Doc. numérique et usage, Univ. Paris 8)...................................... 179
Décomposition multimodale de l'Activité : vers un outil d'aide à la conception
O. Plos, S. Buisine (ENSAM, Paris)............................................................................................ 185
Comparaison de deux méthodes de prédiction des erreurs humaines en conduite automobile
Ph. Polet, A. Chaali-Djelassi, F. Vanderhaegen (LAMIH, Valenciennes) .................................... 193
La programmation sur exemple : principes, utilisation et utilité pour les applications
interactives
L. Sanou, P. Girard, L. Guittet (LISI, Poitiers) .......................................................................... 201
ARTICLES LONGS APPLIQUES
Vigiestrips une IHM innovante intégrée au système aéroport avancé
J. Garron (Bertin technologie), J. Journet (Dir. Serv. De la Navigation Aérienne, Athis Mons) ... 211
Utilisation d'une Nouvelle Technologie de l'Information et la Communication - la préparation
de commandes avec le guidage vocal
V. Govaere, J.F. Schouller (INRS, Vandoeuvre)......................................................................... 221
Démarche centrée utilisateur, intégrée dans la conception d'un DEmonstrateur de Vision
INdirecte (DEVIN)
L. Kujawa (Giat Industries, Versailles) ........................................................................................ 229
RUP© et conception centrée sur l'utilisateur : une étude de cas
F. Lemieux, M.C. Desmarais (Ecole Polytechnique de Montréal) ............................................... 237
Nomenclature de critères ergonomiques pour le vote électronique : éléments d'utilisabilité
électorale
G. Michel (Univ. Metz), W. Cybis de Abreu (Univ. De Santa Catarina) ....................................... 245
Esquisse de processus visant à améliorer la capacité d’adaptation des systèmes à leurs
environnements
J.-R. Ruault (DGA, Paris)............................................................................................................ 253
Prise en compte du Facteur Humain dans les études de Sûreté de Fonctionnement des
systèmes militaires terrestres
A.S. Smouts, V. Castel (Giat Système), F. Colomban (CSSI, Toulon),
V. Delebarre (Safe-River, Paris) ................................................................................................. 261
Les savoir-faire de production dans les manufactures du verre et du cristal : des
automatismes aux habiletés cognitives
D. Wannenmacher (Grefige, LabPsyLor Univ. Nancy)............................................................... 269
Déplacements urbains de personnes non voyantes : étude multifactorielle des difficultés et
apports d'une nouvelle interface pour le recueil de données
M. Wolff, Ph. Cabon, G. Uzan, J. Nelson, S. Couix (Unité d'ergonomie Paris 5) ........................ 277
Evaluation d'une interface visuelle et auditive prototype pour un équipement militaire de
campagne
M. Wolff, J.C. Spérandio (Unité d'ergonomie Paris 5), L. Todeschini (DGA, Montreuil).............. 287
ARTICLES COURTS DE RECHERCHE
Enjeux et défis de la conception des interfaces pour les assistants numériques personnels
S. Baffoun, J.M. Robert (Ecole polytechnique de Montréal)........................................................ 297
Apports croisés des démarches d'inspection et de test d'usage dans l'évaluation de
l'accessibilité de E-services
M.E. Bobillier Chaumon (ICTT-ECL), F. Sandoz Guermond (ICTT INSA) .................................. 301
Une approche hybride pour une meilleure visualisation de grands ensembles de règles
d'association
O. Couturier (CRIL, Univ. Artois), J. Rouillard, V. Chevrin (CUEEP, Univ. Lille1) ....................... 305
Les simulations en conduite incidentelle/accidentelle dans le nucléaire : proposition d’un
protocole pour l’analyse de l’activité collective
Cecilia De la Garza (Univ. Paris 5), Pierre Le-Bot (EDF R&D).................................................... 309
Gestion de disponibilité en communication médiatisée : premiers résultats d'une observation
écologique
G. Genieys (France Télécom R&D), J. Kahn (France Telecom VSF),
J.M.C. Bastien (Univ. Paris 5) ..................................................................................................... 313
Interaction personne handicapée/système à balayage : vers un réglage automatique de la
vitesse de défilement adapté à l'utilisateur
S. Ghedira, P. Pino, G. Bourhis (LASC, Univ. Metz)................................................................... 317
Ergonomie des logiciels éducatifs pour enfants déficients cognitifs : l'importance des
émotions
G. Michel, M. Jobert, C. Delcourte, S. Boulakfouf, A. Dibon, G. Petit (labo. Univ. Metz) ............ 321
Comportements des conducteurs vis-à-vis de nouveaux systèmes d'assistance à la conduite
automobile en situation critique
Ch. Pagot, A. Clarion, C. Petit (Renault Research Dpt, Guyancourt),
Ch. Collet (Univ. Lyon 1) ............................................................................................................ 325
Evaluation d'analogies scripturales pour la conception d'une méthode de saisie en mobilité Uni-Glyph
F. Poirier, M. Belatar (Labo. VALORIA) ...................................................................................... 333
Un pas vers un outil d'aide aux évaluateurs de systèmes interactifs à base d'agents
A.Trabelsi, H. Ezzedine (Lamih, Univ. Valenciennes) ................................................................. 337
Evaluation précoce et conception orientée évaluation
J-C. Tarby (Trigone, Lille) ........................................................................................................... 343
ARTICLES COURTS APPLIQUES
L'innovation par l'analyse des performances humaines : application de l'ergonomie à la
conception de produits cosmétiques
E. Brangier (Univ. Metz, ETIC), J.C. Simon (KPSS, Darmstadt)................................................. 349
Applications of human modelling techniques in industrial design context, a multi-agent/multiscale approach
M. Shahrokhi, A. Bernard (IRCCyN, Nantes) .............................................................................. 353
Barrier Analysis through Industrial Design Processes
M. Shahrokhi, A. Bernard (IRCCyN, Nantes) .............................................................................. 357
POSTERS ET DEMONSTRATIONS
Prise en compte du facteur humain pour la conception d'un système informatisé de régulation
médicale de théâtre opérationnel
W. Guessard (Section technique Armées), A. Puidupin, R. Besses, P.O. Miloche, G. Comtet,
V. Di Giusto (Institut de médecine navale) .................................................................................. 363
Modélisation pédagogique : comment choisir les bons outils?
V. Heiwy (CRIP5, Univ. Paris 5).................................................................................................. 365
Conception et Réalisation d'un site de E-recrutement avec module Datamining intégré de
classification
H. Necir (Univ des Sciences de la technologie, Faculté de Bab Ezzouar, Algérie) ..................... 367
IHM et IDM : un tandem prometteur
J.S. Sottet, G. Calvary, J. Coutaz, J.M. Favre (UJF CLIPS IMAG, Grenoble)............................. 369
Déplacements urbains de personnes non voyantes : observation et analyse des difficultés
M. Wolff, Ph. Cabon, G. Uzan, J. Nelson, S. Couix (Unité d'ergonomie Paris 5) ........................ 371
Déplacements urbains des personnes non voyantes : la fréquence cardiaque comme
indicateur potentiel de stress
M. Wolff, Ph. Cabon, G. Uzan, J. Nelson, S. Couix (Unité d'ergonomie Paris 5) ........................ 375
INDEX DES AUTEURS ............................................................................................................ 381
CONFERENCES INVITEES
*******
Violations et migrations ordinaires dans les activités
à risques: conséquences pour la résilience globale
et la gestion du retour d’expérience en entreprise
René Amalberti
IMASSA, BP73, 91223, Brétigny-sur Orge
RESUME
KEYWORDS : Safety,
La question des dérives et des déviances diverses dans
les systèmes sûrs trouve une actualité particulière dans la
sécurisation progressive des systèmes industriels. En
effet, plus on contraint un système, plus le système ainsi
bridé augmente ses mécanismes de violations, en général
pour satisfaire une performance économique devenue
trop contrainte par la sécurité. En s’inspirant du modèle
de migration de Rasmussen (1997), l’auteur propose un
modèle en trois étapes qui rend compte de ce mécanisme
qui fait passer le système d’une ‘violation quasi normale’
(On parle de Border-line Tolerated Conditions of Use –
BTCUs) à un accident spectaculaire. Les notions
importantes à débattre et à modéliser sont à la fois les
mécanismes spontanés des systèmes techniques pour
vivre avec les dérives de tous ordres (notamment les
effets pervers sur le retour d’expérience) et d’un autre
côté les stratégies de sécurisation que l’on peut conseiller
pour réguler de façon réaliste le système globalement, et
plus localement aux trois phases de la migration. Les
notions de cycle de vie des systèmes industriels, de place
de la sécurité dans ces cycles de vie, de robustesse
(resilience) du système et de modèle dynamique de
gestion des risques sont au centre de la conférence.
migrations
industrial systems, violations,
INTRODUCTION
Ce texte traite de l’(in)sécurité des grands systèmes
socio-techniques (pôles énergétiques, transports publics,
médecine). Ces ‘grands systèmes socio-techniques’
présentent trois caractéristiques :
x Les processus à contrôler à gérer sont
dynamiques, ils évoluent pour eux-mêmes mais
peuvent être infléchis par l’intervention
humaine.
x Ils restent sous le contrôle d’Hommes ‘au
contact du processus’ et dans la boucle de
‘management’ ; en anglais on emploie le terme
de ‘sharp end’ pour les premiers, et de ‘blunt
end’ pour les seconds [23]. Cette propriété de
contrôle humain horizontal et vertical ne
disparaît pas quelque soit le niveau de
technologie employé.
x Ils sont à risques; le risque est la mort physique
des acteurs et/ou du système lui-même
(notamment mort économique) ; cette mort peut
être isolée mais s’accompagne le plus souvent
d’effets collatéraux.
MOTS CLES : Sécurité, systèmes industriels, violations,
La sécurité de ces systèmes n’est jamais suffisante.
L’espoir d’amélioration continue de cette sécurité repose
sur un système de croyances au rang desquelles figurent
les cinq principes suivants :
migrations,
ABSTRACT: The matters of deviance and violations in
complex industrial systems are gaining importance with
the continuous pressure for improving safety. Indeed, the
more the systems are constrained, the more deviances
occur to cope with the economic demand. This paper
proposes a three phase model derived from Rasmussen’s
theory of migration to boundaries to explain the
mechanisms by which the deviance occurs, stabilizes,
regresses, or progresses to an accident. Two points must
be clearly understood: first how systems adapt to
deviances and may escape to safety surveillance
(including how they twist the reporting systems to hide
the deviance), and second, what strategy can be
realistically suggested to coping. The concepts of
lifecycle of industrial systems, resilience, and dynamic
risk management are other key point of the paper.
Deux principes sont relativement globaux
x La sécurisation réduit les risques d’exposition
de l’entreprise à la crise.La réduction du
volume et de la survenue des incidents réduit le
nombre de plaintes et problèmes avec les clients
et riverains.
x Il existe une voie commune de sécurisation des
systèmes, basée sur l’adoption d’outils/
organisations ayant fait leur preuve: les
stratégies de sécurité des meilleurs systèmes
(nucléaire, aviation) trace le chemin pour tous
les autres systèmes socio- techniques.
Trois principes sont plus méthodologiques, et centrés sur
la réduction du risque :
x La conformité à une marche ‘idéale’ est la voie
de sécurisation privilégiée des systèmes. Le
13
x
x
d’optimisation de tout système socio-technique. Pour
bien comprendre ce phénomène paradoxal, le texte
propose d’étudier les modèles décrivant les changements
de sécurité dans les cycles industriels, puis de façon plus
précise le comportement des systèmes approchant leur
niveau d’asymptote final, notamment en termes de
violation, et enfin, le texte propose de revenir sur les
solutions envisageables.
retour d’expérience et la démarche qualité sont
les outils habituellement retenus pour cette mise
en conformité. La réduction des écarts et
évènements indésirables conduit naturellement
à une meilleure sécurité.
Les erreurs sont excusables sinon tolérables, et
le système doit développer des barrières pour en
réduire l’occurrence et les conséquences [1, 2].
Les barrières s’organisent en trois secteurs
complémentaires : Prévention, Récupération, et
Atténuation. La distinction entre erreurs
patentes (des acteurs de première ligne) et
erreurs latentes (de la gouvernance du système)
est maintenant admise comme un fait à prendre
en compte avec des actions ciblées sur le
management [13].
Les violations restent considérées comme des
actes délibérées et injustifiables.
MODELISER LES CHANGEMENTS DE SECURITE
DANS LES CYCLES INDUSTRIELS
Le modèle de changement présenté s’inspire des travaux
du sociologue Hughes [20] (voir aussi Gras [17] pour un
éclairage sur les travaux de Hughes) dont le terrain
d’étude privilégié a été pendant longtemps le
développement de l’industrie de l’énergie électrique. Le
modèle décrit trois phases qui s’étendent sur des cycles
de 60 à 90 ans (soit une durée de vie finalement
comparable à celle de la vie humaine) (figure1) :
Cette conférence veut montrer que le caractère de vérité
de ces idées se réduit grandement dans la phase finale
Amalberti, R. Optimum system safety and optimum system resilience: agonist or antagonists concepts? In E. Hollnagel, D. Woods, N. Levison, Resilience
engineering : concepts and precepts, Aldershot, England: Ashgate, 2006: 238-256
Cycle suivant
Cycle des systèmes socio-techniques
Systèmes sous pression médiatique
Niveau de
sécurité
Transparence
RUPTURE
TECHNOLOGIQUE
SECURITE
TEMPS HEROIQUES
TEMPS DE LA
JUSTIFICATION
QUALITE
découvertes fondatrices
Ralentissement des progrès
Sur optimisation des solutions
connues- rigidification des
procédures
REX
TEMPS DE L’ESPOIR, progrès rapides
TEMPS HEROIQUES
découvertes fondatrices
Aucune pression de sécurité
0
10
20
30
40
50
60
70
80
90
100
années de vie
Figure 1 : Cycle de vie des grands systèmes : Ces grands systèmes, à leur échelle, naissent et meurent –on parle de cycle
industriel- en connaissant un cours de vie largement reproductible d’un système à l’autre [20]. Attention !! la mort du
système n’est pas la mort de la fonction du système ; la fonction renaît de ses cendres dans une nouvelle technologie issue
d’une rupture technologique : le cycle reprend, souvent sous une forme différente de couplage ; par exemple l’aéronautique
civile s’approche de sa fin de cycle et devrait subir une rupture technologique de très grande envergure vers les années 2030
avec l’arrivée annoncée d’une guidage satellitaire complet du système. Les professions changeront, de même que toute
l’économie du système, mais on continuera à prendre des avions pour aller de A à B (continuité du service)
14
a.
b.
c.
règlements). Il en résulte une attitude de plus en
plus prudente ; le danger se déplace d’erreur
d’action vers des erreurs par défaut d’action. Le
système consomme aussi de plus en plus de
ressources à se contrôler. Cette consommation, peu
perceptible au départ, devient significative quand le
système se déploie, particulièrement dans un climat
de gestion tendue de personnel. Le déploiement et
souvent les dérives des outils de qualité continue
sont un bon exemple de ce paradoxe. Les
contraintes réglementaires créent aussi des ordres
de priorité dans les problèmes traités, en laissant
dans l’ombre des secteurs objectivement plus
dangereux, mais moins émotionnels, moins soumis
à la pression réglementaire et aux contrôles
techniques, et de facto moins médiatiques.
Une phase de créativité initiale. Quelques individus
portent l’innovation et la sécurité n’est pas
considérée comme une priorité à ce stade.
Une phase de généralisation de masse, qui s’étend
souvent sur plusieurs dizaines d’années. A ce stade,
l’industrie absorbe l’innovation, la standardise,
l’optimise, et la généralise pour un objectif de
rentabilité (économique, éthique, bien être). Cette
phase se caractérise par le flux continu
d’optimisation et le fait que la sécurité évolue en
parallèle de la performance. La défense pénale sur
des problèmes de défaillances est argumentée sur la
dynamique et l’espoir technologique : par exemple,
on a longtemps excusé – au sens de la
responsabilité - la mort de nombreux patients par
la non disponibilité scientifique d’une molécule,
d’un vaccin, ou d’une technique efficace au
moment de leur maladie. En même temps, on a tenu
un discours très fort autour de découvertes qui
règleraient dans un avenir très proche le problème
des futurs patients atteints de la même maladie.
Cette défense, arguant à la fois sur l’inéluctabilité
de la mort par défaut de science et sur l’espoir à
moyen terme d’un sort meilleur, s’est imposée
d’une façon si forte et si naturelle dans
l’inconscient collectif des patients et des familles
jusqu’aux années 90 aux USA et en France qu’elle
a longtemps réduit les plaintes et poursuites en
justice.
Une phase d’optimisation finale, dite de
‘momentum incontrôlé’. La vitesse des progrès se
ralentie et le système devient balistique en tombant
souvent dans des sur-optimisations locales au
détriment d’une vision stratégique globale. Cette
situation génère de nombreux paradoxes.
Cette intolérance croissante abaisse le seuil de
déclenchement des situations de crises. Les crises
sont plus nombreuses, plus imprévisibles, et
toujours plus ardues à contrôler. Le déclencheur
des crises de sécurité d’une entreprise est
particulièrement sensible au regroupement des
plaintes et au phénomène de résonance
émotionnelle par les médias.
ƒ
Enfin les affaires en justice montrent un glissement
sensible de la perception des juges vis-à-vis de la
responsabilité des industries et systèmes publics.
Aujourd’hui, les
marges de progression
technologique spectaculaire sont moindres. Le
public, et la justice dans son écho à la société
civile, tendent à considérer que le risque perçu
n’est pas lié à une technologie ou un savoir
insuffisant, mais à un arbitrage incorrect donnant la
priorité à d’autres dimensions que la sécurité.
Dans tous les cas, et contrairement aux principes que
l’on a vus dans l’introduction, la sécurisation entraîne
toujours un effet paradoxal : la sécurité devient un objet
difficile à manier et elle va se mettre à sérieusement
freiner la productivité du système. C’est cette
‘impossible sécurité’ doublée d’un ‘frein de
productivité’ qui va créer les conditions de l’émergence
d’un paradigme de rupture qui permettra de repartir
dans un nouveau cycle en fin de vie des systèmes
industriels.
Le paradoxe dominant fait que les systèmes ainsi
devenus très sûrs deviennent en même temps plus
fragiles :
ƒ La société demande plus de transparence sur le
risque réel ; cette transparence motive une montée
en puissance croissante de tous les moyens de
retour d’expérience ; cependant, la possession de
l’information rend en retour la société plus
intolérante à tous les problèmes résiduels; l’épisode
des accidents de charters pendant l’été 2005 autour
de l’information détaillée apportée sur l’état des
avions en représente un exemple caricatural : plus
le public dispose de l’information, plus il est pris de
doute sur ce qu’on lui cache derrière cette
information. Cette posture rend parfois difficile le
déploiement des systèmes d’informations trop
transparents, et freine en retour la sécurisation
réelle des pratiques.
ƒ
ƒ
Ainsi, si l’on raisonne en termes de robustesse
(‘resilience’, voir le récent livre de Hollnagel, Woods et
Levison [19]), le modèle d’évolution de la sécurité des
systèmes (il faudrait plutôt parler d’évolution des
fonctionnalités assumées : par exemple le transport
aérien, la production énergétique, ou la stratégie
chirurgicale) prédit des cycles successifs qui vont
balayer plusieurs états de sécurité, avec des propriétés
associées de productivité et d’organisation des
professions [5].
On assiste à une intensification des outils et
méthodes qui se sont avérés jusque là porteurs des
améliorations (qualité, suppression des risques,
contraintes diverses sur le processus, protocoles,
Cinq barrières sont plus particulièrement identifiables
sur la route de l’ultra sécurité ([3], voir figure 2) :
15
x
x
x
un système où la performance globale est
stabilisée et standardisée (interdiction de
performance exceptionnelle), mais où la
délivrance de ce niveau de performance est
garantie par tous les acteurs professionnels
(homogénéité du corps professionnel). C’est
exactement ce que l’aéronautique arrive à
faire : une exploitation interdite par règlements
dans tous ses aspects exceptionnels qui ne
seraient pas maîtrisés par tous, mais une
assurance que ce qui est à faire est faisable par
tous au plus haut niveau de sécurité.
Il faut limiter la production du système pour
progresser vers l’ultra sécurité. A terme, les
derniers progrès nécessitent systématiquement
d’arbitrer en faveur de la sécurité au détriment
de la performance.
Il faut limiter l’autonomie des acteurs, et
laisser la priorité à des objectifs du groupe qui
sont parfois contraires à la réalisation de ses
propres priorités.
Il faut passer d’un modèle d’artisan, basé sur
les différences individuelles et une prime à
l’élite, vers un modèle d’acteurs équivalents,
renonçant aux différences. La combinaison de
la barrière 1 et 3 montre qu’un système sûr est
Amalberti, R. Auroy, Y. Berwick, D., Barach, P. (2005) Five System Barriers To Achieving
Ultrasafe Health Care, Ann Intern Med. 2005;142, 9: 756-764
5 barrières successives pour devenir ultra sûr
Pas de limitation de performance
Accroître les marges, imposer des limites
Excessive autonomie des acteurs
Jouer collectif
Accepter de devenir acteur équivalent
Attitude d’artisan
Sur protection égocentrée des différentes couches Accepter le risque résiduel
humaines du système, notamment couche managériale
Perte de visibilité du risque, investissements
Accepter de questionner
paradoxaux, Conduite politique
les succès passé et
changer de stratégies
Vols Hélicoptères
Vols charters
Alpinisme
hymalayen
Activités ULM
Agricole
Aviation Civile
Rail (France)
Sécurité routière
Industrie chimique
10-2
10-3
10-4
Industrie Nucléaire
10-5
10-6
Extrêmement sûr
Très peu sûr
Pas de systèmes
après ce point
Transfusion sanguine
Risque médical (total)
Risque de
catastrophe
Figure 2 : niveau de sécurité et barrières à franchir pour atteindre l’ultra sécurité
x
Quand le système devient plus sûr, il se trouve
progressivement sous le feu des média (opus
cité, phase 3 du modèle de Hughes). Les
acteurs du système se renvoient la
responsabilité. Il faut absolument éviter qu’une
couche du système socio-technique se
surprotège car la sanction est en général de
mettre les autres couches en situation
d’impossibilité d’effectuer le travail, les oblige
à commettre plus de violations, avec un bilan
x
16
finalement souvent aggravé en matière de
sécurité. La bonne maîtrise de la sécurité
suppose de maintenir un risque homogènement
réparti entre acteurs. La sur réglementation
entre dans cette catégorie de défauts.
Enfin, devenu très sûr, le système doit
préserver la visibilité du risque. Les accidents
sont plus rares, et la tentation est de focaliser
sur des objets moins pertinents. Le retour
d’expérience perd notamment de la valeur
‘charrettes’ contractuelles, enjeux économiques de
l’instant, etc.). Cette variation force à des adaptations
substantielles qui sont autant de points d’entrée dans
des migrations de pratiques.
Pour résumer, plus un système se sécurise, plus le
problème résiduel à traiter est celui des violations [8].
Les écarts intentionnels aux procédures peuvent alors
concerner plus de 50% des procédures en vigueur
(exemple de Degani et Wiener sur les check-lists avion
[12]) et peuvent surtout représenter plus de 50% des
erreurs totales recensées dans le travail des équipes
[18].
[5,9]. Il faut changer le mode de traitement de
l’information et éviter les pièges de la sur
sécurisation.
LA GESTION DES VIOLATIONS COMME VOIE
COMMUNE FINALE DE SECURITE DES SYSTEMES
ULTRA SURS
Les systèmes sûrs ont plus de violations que les
systèmes peu sûrs
L’ajout naturel de contraintes et de normalisation sur
lequel repose les paradigmes de sécurisation des
systèmes aboutit logiquement à une voie commune
finale de sur standardisation.
Cette sécurisation n’efface pas le fait qu’il existe une
variation naturelle des conditions de l’activité
professionnelle (personnels absent, remplaçant,
Les migrations et les dérives évoluent en trois phases
importantes à comprendre, car l’action correctrice est
différente à chaque phase (figure 3).
Amalberti, R., Vincent, C., Auroy, Y., de Saint Maurice, G., Framework models of migrations and violations: a consumer guide, Quality and Safety in
Healthcare, 2006, supplement Safety by design, ii 22-40
Migrations de performance, transgressions des règles
Stopper migration
Sanction possible
Comprendre les causes des migrations
Staffer et réduire la migration par consensus
AVANTAGES
INDIVIDUELS
Réviser les règles
si inadaptées au nouveau contexte
Migration
aux limites
sociales
Pression du système
Performance accrue
Rentabilité
Espace
implicitement négocié
hors analyse de sécurité
Zone des violations
ACCIDENT
BTCUs
Border Line Tolerated
Conditions of Use
ESPACE DE
FONCTIONNEMENT
CONSIDERE COMME
SÛR PAR
CONCEPTION
Technologie
Pression Individuelle
Migration
aux limites
économiques
Qualité de vie, limitations des
savoir-faire, limitation des
responsabilité
PERFORMANCE
Figure 3 : modèle cadre de migrations spontanées des systèmes complexes vers leurs limites de fonctionnement
(inspiré au départ de Rasmussen [22])
x
x
La première phase est celle de la conception.
Avec la pression sécuritaire, le système est
souvent imaginé sur le papier avec des marges
de sécurité très importantes qui satisfont, et
vont même parfois au-delà des exigences
légales.
17
La deuxième phase correspond à la mise en
fonctionnement du système. Très rapidement,
et encore plus si les marges de sécurité ont été
très exagérées, les pratiques professionnelles se
mettent à migrer pour permettre une
performance économiquement viable. On parle
x
de Borderline-Tolerated condition of Use
(BTCUs) [4, 21]). Ces écarts sont tolérés par la
hiérarchie.
Ils
s’accompagnent
de
compensations
personnelles
pour
les
opérateurs (avantages personnels) et fixent
progressivement une marche officieuse du
système, illégale-légale. Tout système conçu
avec une sur-sécurité évolue extrêmement
rapidement dans cette direction car il bride
tellement la performance qu’il en devient
irréaliste [10]. Ce niveau de performance basé
sur une marche illégale finit par satisfaire à la
fois l’entreprise et les salariés ; il devient par
habitude considéré comme la norme, et,
toujours
par
habitude,
se
trouve
progressivement exclu du champ du retour
d’expérience. Même les inspections et
contrôles qualité finissent par éclipser ces
comportements naturels, et ne plus les relever.
Le système devient alors muet. Certains
auteurs ont théorisé le départ de ces dérives en
considérant surtout la dimension contextuelle
de gestion de conflits d’objectifs [6, 11, 25].
D’autres considèrent cette phase typique d’une
culture de sécurité en dérive (Vaughan [26] par
la normalisation de la déviance, Reason,
Carthey, de Leval [24] avec les syndromes de
vulnérabilité) ; mais on peut simplement y lire
une adaptation de survie nécessaire aux
demandes et conditions changeantes de
l’environnement [7], aggravée par une
idéalisme de sécurité ayant poussé à l’adoption
de contraintes illusoires lors de la conception
(des procédures, ou de l’organisation globale
[14, 15]).
La troisième phase se révèle brutalement, et
souvent très tardivement plusieurs mois ou
années après le départ de la seconde phase, par
des incidents graves. Rarement tout le système,
beaucoup plus souvent certains individus, seuls
ou en équipe, ont continué à migrer, sans
contrôle, et finissent par provoquer la survenue
d’incident ou d’accident (voir par exemple
l’accident nucléaire de Tokai Mura [16]).
x
x
x
(importance des staffs sur les pratiques), ou/et
confortée par des observations neutres
(rappelons là encore que des professionnels
trop proches du domaine ne « voient » plus les
migrations).
Dans tous les cas, la meilleure façon de
contrôler le processus est de le rendre visible,
puis de laisser les acteurs s’autoréguler
mutuellement. Un ajustement (relâchement)
des normes peut parfois être utile pour mieux
coller à une réalité nouvelle.
Dans les cas de migrations importantes et
dangereuses, portées par des individus, des
sanctions peuvent être envisagées.
Dans tous les cas, découvrir la migration au
stade de l’incident avéré doit être considéré
comme un échec de la prévention et de l’action
de sécurité.
CONCLUSIONS : LEÇONS, QUEL MODELE(S) DE
RISQUE(S)
Le texte a permis de pointer un certain nombre de
paradoxes qui battent en brèche les concepts de base sur
les lesquels sont fondés les analyses de sécurité
x Les questions de sécurité sont une propriété
émergente de la fin de vie des systèmes déjà
très matures. Les questions de sécurité ne sont
qu’épisodiques dans les systèmes très peu
sûrs ; elles sont centrales dans la gouvernance
des systèmes sûrs.
x Les violations sont une propriété fonctionnelle
de ce couplage, lié au fait que le processus de
sécurisation contraint le système et force à des
adaptations illégales pour réaliser la
performance.
x Le mode de gouvernance est très important
dans la robustesse finale et la régulation de ces
caractéristiques de sécurité sur le court et
moyen terme.
x L’industrie n’est pas homogène en matière de
sécurité. Il faut plus et mieux le dire au public,
en permettant ainsi des tempos différents en
matière de pression judiciaire (figure 4). La
confusion de genre et la globalisation peut
amener le public à avoir des attentes de phase
III- au sens du modèle de Hughes, opus citévis-à-vis de secteurs qui sont à peine en début
de phase II. Dans ce cas, tout le système va se
bloquer précipitamment. Il faut établir une
vision plus systémique du risque, et traiter
chaque secteur avec des outils de sécurité
proportionnés au niveau de sécurité atteint.
Peut être certains secteurs peuvent prétendre à
copier l’aviation, mais pour la plupart le niveau
maximum de sécurité atteignable est sans
doute bien inférieur et pour longtemps.
x Il faut éviter une sur enchère règlementaire et
sécuritaire quand les systèmes deviennent très
Les conséquences des migrations sont importantes
x La sécurisation d’un système avec les outils de
contraintes entraîne mécaniquement une
augmentation des migrations et des violations.
x La prévention ne doit pas reposer sur une
vision idyllique -mais naïve- qui consisterait à
empêcher ces violations à tous prix.
x En effet, le premier problème est de les
identifier. Rappelons que ces migrations sont
particulièrement silencieuses. Or cette
identification ne peut pas reposer sur le retour
d’expérience ; elle doit donc reposer sur une
analyse à la base, médiée par le discours
18
x
sûrs (phase III de Hughes). Plus on sécurise un
secteur d’activité, plus la demande va être forte
de continuer à le sécuriser, au point de
progressivement sécréter les conditions d’une
crise de l’assurance et de la justice
Inversement, le contrôle des premières
barrières est impératif à terme, notamment le
bridage de la performance pour garder le
meilleur niveau de sécurité. Mais évidemment,
le traitement de ce problème renvoie à une
approche plus globale. On entend ici une
x
approche où tous les acteurs sont concernés, la
chaîne politique et hiérarchique bien sûr, les
acteurs techniques de première ligne, mais
aussi les clients qui devront se responsabiliser.
Enfin, quand on a beaucoup amélioré un sous
système, on entre inéluctablement dans la
transition entre phase II et phase III du modèle
de Hugues. Il faudra alors mettre en débat des
définitions et des priorités jusque là peu
discutées (voir les textes sur la résilience et
[5])
Amalberti, R., Hourlier, S. Human error reduction strategies, In (Ed) P. Carayon: Handbook of Human Factors and Ergonomics in Healthcare and Patient
Safety, Hillsdale , New Jersey: LEA, 2006:
Une vision des changements limitée par le niveau de
maturité du système
Erreurs humaines
Approche centrée sur
les acteurs
Superviser
Responsabiliser
Enseigner les compétences non techniques
Accepter de gérer
la responsabilité
Imposer les conditions de travail,
Standardiser/protocoliser
Améliorer la technique
Ajouter des
défenses
Réduire
l’autonomie
des acteurs
10-7
Passer au
modèle d’acteurs
équivalents
Changer les
Maintenir valeurs de la
la visibilité profession
du risque
Ajouter des lois
Changer d’organisation au seul
profit de la sécurité
Viser un niveau de risque explicite
Embaucher des acteurs dédiés à
la sécurité
Reconnaître les problèmes de sécurité
Créer une culture de REX
Contrôler la performance imposée
Enseigner
les compétences
techniques
Approche centrée
sur le système
10-1
Figure 4 : Une synthèse des changements envisageables en fonction du niveau de maturité du système.
BIBLIOGRAPHIE
5.
Amalberti, R. La conduite de systèmes à risques,
2°ed. Paris: PUF, 1°ed. 1996, 2001.
Amalberti, R. Optimum system safety and optimum
system resilience: agonist or antagonists concepts?
In E. Hollnagel, D. Woods, N. Levison (Eds.),
Resilience engineering: concepts and precepts,
Aldershot, England: Ashgate, 2006, pp. 238-256.
6.
Amalberti, R., Auroy, Y., Berwick, D., Barach, P.
Five System Barriers To Achieving Ultrasafe Health
Care, Ann Intern Med., 142(9), 2005, pp. 756-764.
Ajzen, I. The theory of planned behavior.
Organizational Behavior and Human Decision
Processes, 50, 1991, pp. 179-211.
7.
Ashby, WR.
An Introduction to Cybernetics.
London: Methuen & Co, 1956.
8.
Aslanides, M., Valot, C., Nyssen, A.S., Amalberti,
R. Evolution of error and violation description in
French air force accident reports: impacts of human
1.
Amalberti, R. The paradoxes of almost totally safe
transportation systems. Safety Science, 37, 2001, pp.
109-126.
2.
3.
4.
Amalberti, R., Vincent, C., Auroy, Y., de Saint
Maurice, G., Framework models of migrations and
violations: a consumer guide, Quality and Safety in
Healthcare, 2006, supplement Safety by design, ii
22-40.
19
factors education, submitted Human Factors and
Aerospace safety.
prerequisite to effective risk management. Quality in
Health Care, 10, 2001: ii21-ii25
Auroy, Y., Amalberti, R., Benhamou, D. Risk
assessment and control require analysis of both
outcomes and process of care, editorial,
Anesthesiology, 104(4), 2004.
25. Parker, D., Manstead, A.S.R., Stradling, S.G.,
Reason, J.T. Determinants of intention to commit
driving violations.
Accident Analysis and
Prevention, 24, 1992, pp. 117-131.
10. Auroy, Y, De Saint Maurice, G., Vincent, C.
Amalberti, R. The natural lifespan of a safety
policy: violations and system migration in
anaesthesia, Ann Intern Med., 144(9), 2006.
26. Vaughan, D. The Challenger Launch Decision:
Risky Technology, Culture, and Deviance at NASA.
Chicago: Chicago University Press, 1996.
9.
11. Beatty, P., Beatty, S. Anaesthetists' intentions to
violate safety guidelines. Anaesthesia, 59(6), 2004,
pp. 528-540.
12. Degani, A., Wiener, E.
Cockpit Checklists:
Concepts, Design, and Use. Human Factors, 35,
1993, pp. 345-359.
13. Dekker, S. Ten questions about human error.
Avebury: Ashgate, 2004.
14. Espin, S., Lingard, L., Regher, G., Baker, R. The
persistence of unsafe practice in everyday work: an
exploration of organizational and psychological
factors constraining OR safety. Quality and Safety in
Healthcare, 15, 2006, pp. 165-170.
15. Fadier E, de la Garza, C. Safety design: Towards a
new philosophy. Safety science, 44, 2006, pp. 55-73.
16. Furuta K., Sasou, K., Kubota, R., Ujira, H., Shuto,
Y., Yagi, E. Human factor analysis of JCO
Criticality accident. Cognition, Technology, &
Work, 2, 2000, pp. 182-203.
17. Gras, A. Grandeur et dépendance, sociologie des
organisations. PUF : Paris, 1993.
18. Helmreich, R. On error management: Lessons from
aviation. British Medical Journal, 320, 2000, 781785.
19. Hollnagel, E., Woods, D., Levison, D., editor.
Resilience engineering : concepts and precepts.
Aldershot, England: Ashgate publisher limited,
2006.
20. Hughes, T. Networks of Power-electrification in
Western Society. John Hopkins Univ. Pres,
Baltimore, 1983.
21. Polet, P., Vanderhaegen, F., Amalberti, R.
Modelling the Border-line Tolerated Conditions of
Use. Safety Science, 41, 2003, pp. 111-36.
22. Rasmussen, J. Risk management in a dynamic
society. Safety Science, 27, 1997, pp. 183-214.
23. Reason, J. Managing the risk of organizational
accidents. Aldershot: Ashgate Avebury, 1997.
24. Reason, J., Carthey, J., de Leval, MR. Diagnosing
"vulnerable system syndrome": an essential
20
Génie système : à la croisée de la science et de l'art
Alain Faisandier
MAP SYSTEME - 2 chemin de la Serre - 31450 BELBERAUD – FRANCE
[email protected]
RESUME
tional domains. After a brief introduction showing the
links between the general theory of systems and and the
notion of Systems Engineering as seen today, the paper
figures out the necessity of a minimum of rationality
when creating these kind of systems explaining some
fundamentals, principles or concepts. As an example, the
methodological thoughts leads to understand that daily
humans do not need products but they need services. Are
briefly reminded the systems engineering processes to
design systems from the description of stakeholders'
needs, as well as the basic models used by the designer.
The author is interested by the relations between designers and users of these systems in order to present a simplified model of the intellectual creation mechanism,
which proceeds by successive iterations of "analysis /
synthesis" cycles ; this mechanism is at the source of innovation opportunities or at the contrary at the source of
potential failures of future systems.This paper provides a
more precise, and rational definition than those existing
in today standards that allow to perform a genuine engineering method applicable to any kind of concerned systems. This definition ensures the cultural continuity from
the Greeks till now and compatible with technological
and organizational advances. As an example this definition is briefly applied to industrial enterprises. Finally,
some limits of Systems Engineering due to human factor
are brought up in the context of organizational systems.
Cet article s'intéresse uniquement aux systèmes créés et
utilisés par l'homme, qu'ils soient d'ordre technologique,
stratégique ou organisationnel. Les études et expériences
de terrain menées par la communauté des ingénieurs systèmes, représentée par l'International Council On Systems Engineering (INCOSE), tendent vers la définition
d'une discipline nouvelle et des plus utiles dans la totalité des secteurs industriels et organisationnels. Après une
introduction brève montrant les liens entre la théorie générale des systèmes et la notion d'ingénierie de système
telle qu'entrevue aujourd'hui, l'article amène progressivement le lecteur à prendre conscience de la nécessité
d'un minimum de rationalité dans la création de ces systèmes via certaines notions fondamentales, principes ou
concepts. Par exemple, la réflexion méthodologique
amène à comprendre que l'homme n'a pas besoin dans sa
vie courante de produits mais de services. Sont brièvement décrits les processus du génie système pour concevoir les systèmes à partir de la description d'un besoin,
ainsi que les modèles de bases utilisés par le concepteur.
L'auteur s'intéresse au rapport entre concepteurs et utilisateurs de ces systèmes pour présenter un modèle simplifié du mécanisme intellectuel de création par itération
de cycles "analyse – synthèse", lesquels cycles donnent
naissance à des opportunités d'innovation, ou au
contraire à des défaillances potentielles. L'auteur s'est attaché à donner au terme système une définition précise
et rationnelle permettant de dérouler une véritable méthode d'ingénierie et applicable à tous les types de systèmes tels que concernés. La définition assure une continuité culturelle depuis les grecs à nos jours, et compatible des avancées technologiques et organisationnelles de
notre époque. A titre d'exemple, cette définition est appliquée succinctement aux entreprises industrielles. Enfin quelques limites de l'ingénierie des systèmes dues au
facteur humain sont évoquées dans le contexte des systèmes organisationnels.
KEYWORDS : System, systems engineering, architec-
tural design, human factors.
BREVE INTRODUCTION DE LA NOTION DE SYSTEME ET DE GENIE SYSTEME
L'article traite uniquement des systèmes créés et utilisés
par l'homme, qu'ils soient d'ordre technologique, stratégique ou organisationnel. Les études et expériences de
terrain menées par la communauté des ingénieurs systèmes, représentée par l'International Council On Systems
Engineering (INCOSE), tendent vers la définition d'une
discipline nouvelle et des plus utiles dans la totalité des
secteurs industriels et organisationnels.
MOTS CLES : Système, ingénierie des systèmes,
conception des architectures, facteur humain.
Le terme "système" a été utilisé dans le passé en philosophie et en métaphysique bien avant de le retrouver
communément cité dans la biologie, les technologies, les
affaires, voire dans le quotidien de chacun. Néanmoins
si l'on ne prend pas garde à baser les mots sur des
concepts et définitions précises, ils perdent leur force,
leur valeur et leur sens profond ce qui entraîne progressivement leur abandon. Hélas ce constat est bien réel vis-
ABSTRACT
This paper deals only with systems created and used by
human beings and which can be in the domain of technology, strategy or organizations. Studies and experiments done by the community of systems engineers, represented by the International Council On Systems Engineering (INCOSE), aims to define a new discipline
which is very useful for any industrial and organiza-
21
LA CONCEPTION D'UN SYSTEME A PARTIR DE LA
DESCRIPTION D'UN BESOIN
à-vis du terme "système", même dans la communauté
technique, tout simplement par le fait de le substituer au
terme "produit" ou vice versa, ce qui l'ampute de sa
grande richesse. A notre époque, le terme système est à
la source de ce que l'on appelle la "systémique" ou
science des systèmes. De façon très succincte, la systémique s'intéresse de nos jours à deux grands domaines :
In fine, pour donner naissance au produit, les deux vues
du besoin (se déplacer) et de la solution (voiture) devant
être liées, le génie système inclut des activités intellectuelles (et abstraites) permettant d'effectuer les transformations nécessaires. La trame de cette succession de
transformations est une suite de plusieurs processus,
chacun centré sur un thème précis :
- La théorie générale des systèmes qui traite des modèles génériques pour tenter d'expliquer le monde et ses
phénomènes ;
- Les méthodes pour modéliser la vue abstraite de produits complexes.
- le processus de définition et d'analyse du besoin des
parties prenantes ;
- le processus de définition des exigences techniques
(par exigences, comprendre les caractéristiques attendues pour satisfaire les besoins) ;
L'ingénierie des systèmes ou génie système (par ingénierie, comprendre les activités de spécification, description, création et conception) adresse bien ces deux branches :
- le processus de conception de l'architecture fonctionnelle afin de décrire les principes de fonctionnement
(hors solution technologique particulière) et le comportement pour satisfaire les exigences ;
- La "vision système" des produits et des services pour
leur compréhension dans leur contexte d'utilisation (pertinence) ;
- Les modèles basiques et les processus génériques
pour pouvoir créer les systèmes et représenter leurs caractéristiques (complétude).
- le processus de conception de l'architecture organique
pour décrire la solution sous forme de constituants
concrets (dits organiques) et liés, capable de supporter le
comportement attendu et toutes les contraintes identifiées sous forme d'exigences.
LE BESOIN DE SERVICES ET L'UTILISATION DE
PRODUITS
Notre société de consommation se focalise sur les produits, du fait de modèles économiques entropiques dans
lesquels on a remplacé les buts (des produits pourquoi
faire ?) par les moyens (l'argent). A l'inverse le génie
système, du fait de la "vision système ou holistique du
monde" se focalise d'abord sur les besoins, c'est-à-dire
sur le service à rendre. Le consommateur dit "J'ai besoin
d'une voiture (d'un produit)" ; le raisonnable dit "J'ai besoin de me déplacer et de transporter des objets (service)". C'est ainsi que le génie système utilise une définition du terme système liant les deux vues : "combinaison
d'éléments interagissant, organisés pour remplir une finalité" (Cf. figure 1).
De tels processus génériques existent de façon standardisée (voir ISO 15288, EIA 632, IEEE1220 par exemple),
ils décrivent les tâches à effectuer. Mais le travail d'analyse et de synthèse est fait à l'aide de méthodes et de
modèles basiques de représentation du système tels
qu'indiqués dans la Figure 2 :
- Modèle fonctionnel : qui représente des hiérarchies de
fonctions ;
- Modèle dynamique : qui représente les événements et
l'enchaînement des fonctions pour réaliser des scénarios;
- Modèle sémantique : qui représente les informations
véhiculées par les fonctions et les constituants (modèles
de données) ;
Un système = un ensemble dynamique d'interactions
dans des conditions opérationnelles
relation ?
?
relation ?
- Modèle temporel : qui représente les fonctions et les
processus selon des niveaux temporels et décisionnels ;
relation ?
- Modèle organique : qui est une représentation de l'architecture des constituants réalisables physiquement ;
cette architecture organique permet de construire ce que
l'on appelle "l'arborescence produit" du projet.
relation ?
Figure 1: 1ère compréhension de la notion de système.
Aux quatre processus, vient s'ajouter un processus dit
d'analyses système pour évaluer et comparer des solutions d'architectures par rapport à des critères issus des
exigences, contraintes, risques, coûts, délais d'obtention,
etc. Ce processus fait appel à des modèles de types ana-
22
ses à l'école. L'INCOSE voudrait que chaque ingénieur
sortant de l'école soit définitivement "Problem solving
oriented", plutôt que "Solution creating to no problem
oriented" pour caricaturer la situation actuelle. Cette activité étant de plus en plus pratiquée dans les entreprises,
nous ferons plutôt un zoom sur celle de conception des
architectures. D'autant que ce qui nous intéresse dans cet
article est le comportement de l'humain vis-à-vis de la
notion de génie système et de son "apport rationnel".
lytiques en vue de quantifier les performances et autres
critères de choix, de simuler des variations pour consolider les choix.
Modèles dans les processus d'ingénierie
Définir le système
Définir les
besoins
parties prenantes
Concevoir le système
Définir les
exigences
techniques
Décrire le contexte du système :
Concevoir
l'architecture
fonctionnelle
Décrire l'intérieur du système :
Limites physiques
Limites fonctions
Flux échangés
Fréquence exécution
Concevoir
l'architecture
organique
Constituants
Modèles basiques :
Sémantique
Fonctionnel
Dynamique
Temporel
Une fois le problème posé en terme de caractéristiques
attendues, le vrai travail de création commence. Mieux
les exigences seront formulées et précises, plus facile sera le travail de synthèse, selon l'adage bien connu que
"tout problème correctement posé est à moitié résolu".
Néanmoins, nous savons tous que la capacité d'analyse
est plus communément répandue que celle de synthèse
ou de conception. Ceci provient du fait que le mécanisme de création et ses outils n'est pas bien connu, et
donc enseigné pour pouvoir être pratiqué quotidiennement. La plupart du temps l'apprenti concepteur fait un
mélange des genres inapproprié du fait qu'il veut utiliser
soit un seul point de vue, soit un seul mode de représentation, ou encore la même méthode, etc., faisant fi de
leurs limites d'application. La conséquence est que
voyant tout à plat, il perd l'aspect multidimensionnel du
problème et de sa complexité naturelle d'où les multiples
effets d'oublis, d'incohérences, etc. A titre d'illustration
les figures 3 et 4 montrent deux approches qui pourraient
être rencontrées.
Fonctions
Flux échangés
Fréquence exécution
Figure 2: Processus et modèles utilisés en génie système.
Si on a une définition récursive de la notion de système
(un système est constitué de systèmes), il est alors possible de définir des processus récursifs et généralisés quelque soit le système ou sa situation dans la pyramide de
décomposition.
De nos jours, l'ingénieur concepteur de systèmes dispose
d'un ensemble d'outils intellectuels pour effectuer ses
études et donc créer de futurs produits. Il est bien évident que si cet ensemble ne forme pas un ensemble mathématiquement cohérent et prouvé, aucune assurance ne
pourrait être donnée quant à la suite des transformations
pour trouver à coup sûr au moins une solution correspondant à un besoin défini. D'où l'importance des travaux de recherche allant dans cette voie de preuve, ou du
moins pour en fixer les limites – ce type de travaux de
recherche n'étant pas hélas très répandu à l'heure actuelle: les ingénieurs essayent de se satisfaire de représentations de type UML dont l'ensemble n'est absolument pas prouvé.
Moteur
Système
Propulser
Ensemble
moteur
Fonction
Constituant
Mélanger air
carburant
Contrôler
combustion
Fonction
Fonction
En résumé, le génie système, dans l'acceptation restreinte du terme système explicité en introduction, est
tout à la fois :
Chambre
combustion
Constituant
Tuyère
Constituant
Calculateur
Capteurs
Actionneurs
Constituant
Constituant
Constituant
Hard
Soft
Constituant
Constituant
Ceci n'est pas une décomposition "système", c'est une vue "pseudo-produit"
- un état d'esprit qui privilégie la "vision système" c'est à
dire vision globalisante d'un monde cohérent et rationnel,
Figure 3: Exemple de représentation mélangeant vues
fonctionnelle et organique.
- une démarche englobant un ensemble de méthodes cohérentes pour bâtir des solutions à un problème complexe,
Système
Systèmede
de
propulsion
propulsion
- un ensemble d'activités regroupées en "processus" permettant de bâtir des produits sur des "principes solides"
seuls garant d'une qualité durable.
Système
Systèmede
de
combustion
combustion
LA CONCEPTION DES ARCHITECTURES DE SYSTEMES : UN ART ET UNE SCIENCE
Système
Systèmede
de
compression
compression
Système
Systèmede
de
régulation
régulation
de
delalatuyère
tuyère
L'activité autour des notions d'exigence et de besoin est
essentielle pour la prise de conscience de la chaîne de
transformation, et aussi pour changer les attitudes appri-
Système
Systèmede
de
régulation
régulation
Système
Systèmede
de
régulation
régulation
du
ducarburant
carburant
Système
Systèmede
de
réchauffe
réchauffe
Système
Systèmede
de
régulation
régulationde
dela
la
roue
roued'entrée
d'entrée
Figure 4: Exemple d'arborescence système.
23
Système
Systèmede
de
rotation
rotation
L'architecture des systèmes est à la fois un art et une
science.
- Un art parce qu'une partie de la discipline est basée sur
l'imagination ainsi que sur des heuristiques qualitatives
(leçons apprises de l'expérience) ; elle se rattache à la
culture et nécessite des jugements de valeur ; elle manipule des éléments non mesurables physiquement.
- Une science parce que l'autre partie est basée sur des
techniques analytiques quantitatives (mathématique,
scientifique) ; elle nécessite des démonstrations, la rigueur du raisonnement ; elle manipule des éléments mesurables.
PERCEVOIR
PERCEVOIR
RECONNAITRE
RECONNAITRE
des
des mots et des percepts
percepts
COMPRENDRE
ASSOCIER
ASSOCIER percepts et
et concepts
concepts
TRIER
TRIER les concepts
IMAGINER
IMAGINER
TRANSFORMER
TRANSFORMER les
les concepts en idées
ORGANISER
ORGANISER / STRUCTURER
STRUCTURER les
les idées
idées
EXPRIMER
TRANSCRIRE
TRANSCRIRE
les
les idées
idées en mots / en dessins
A
N
A
L
Y
S
E
S
Y
N
T
H
È
S
E
Figure 5: Modèle simplifié du mécanisme intellectuel de
conception.
La pratique de la discipline nécessite donc de faire le
lien entre l'imagination (art) et la réalité tangible
(science). Les heuristiques ne sont satisfaisantes que
dans certaines hypothèses, lesquelles ne sont pas toujours exprimées ; leur justification n'est donc pas souvent mathématiquement sûre. Autrement dit le praticien
doit répondre à la question : "Quelle est la faisabilité de
mon imagination? Quelle est la distance par rapport à
mon appréhension du réel ?" En ce sens, l'architecture
des systèmes a des rapports avec ce que l'on met classiquement sous le terme de "facteur humain".
L'ANALYSE comprend deux activités essentielles que
sont la PERCEPTION et la COMPREHENSION.
- Dans la PERCEPTION, il s'agit d'identifier des percepts plus ou moins élaborés à l'aide des sens et de transformations primaires (sons, mots, formes, images, etc.),
et donc de "reconnaître" ces éléments, mettant en jeu une
mémoire très volatile que l'on peut qualifier d'immédiate.
- La COMPREHENSION consiste à associer les percepts à des concepts et de trier parmi les concepts pour
vérifier la bonne adéquation percepts/concepts. Si les
concepts sont bien enfouis, enracinés dans la mémoire
long terme (dit parfois schéma corporel, ou encore archétypes), par contre l'association percepts/concepts
siège dans une mémoire court terme relative au moment
présent.
En résumé, concevoir l'architecture d'un système
consiste donc à imaginer de façon structurée, en s'appuyant sur des principes et lois universels traduits sous
forme de "patterns" appropriés (c'est-à-dire des modèles
fondamentaux) qui reflètent des réalités. Les heuristiques, principes et lois se répartissent sur les domaines
fondateurs de l'architecture des systèmes :
La SYNTHESE comprend elle aussi deux activités de
base que sont l'IMAGINATION et l'EXPRESSION.
- Domaine statique : concerne la structure, le groupement et/ou la séparation des constituants, les interfaces
ou liens ;
- Dans le mécanisme que nous décrivons ici, il s'agit
d'imagination dirigée et non d'imagination intuitive dans
laquelle l'intellect est en réalité déconnecté. Cette IMAGINATION dirigée consiste à transformer les concepts
en idées, à organiser ces idées et les structurer les unes
par rapport aux autres selon un certain schéma décidé
par le praticien. Ce schéma est une ou des méthodes très
basiques qui consistent à rester campé dans un espace
culturel de pratiques, d'us et coutumes (attitude peu innovante utilisant par exemple la répétition), ou à explorer un peu les frontières sans trop franchir 'l'interdit" ou
les lois de la physique (attitude plus innovante utilisant
par exemple la similarité), ou à l'autre extrémité à franchir les limites usuelles, voire défiant certaines lois physiques (espace dans lequel l'artiste excelle).
- Domaine dynamique : concerne le comportement, les
fonctions et les interactions, les réactions aux événements, les performances (l'efficacité) ;
- Domaine temporel : concerne l'invariance temporelle,
les fréquences d'exécution, les événements cycliques ou
synchrones, les niveaux décisionnels asynchrones ;
- Domaine environnemental : concerne la réaction aux
agressions naturelles ou provoquées, la survivabilité,
l'intégrité.
MODELE SIMPLE DU MECANISME INTELLECTUEL
DE CONCEPTION
Ce mécanisme est résumé sur la figure 5, il se divise en
deux grandes activités que sont l'ANALYSE et la SYNTHESE.
- Enfin l'EXPRESSION consiste à transcrire les idées en
mots, en dessins, etc. selon le mode d'expression choisi
plus ou moins riche.
24
il y a un principal ressort duquel tous les autres dépendent, il y a aussi dans tous les systèmes un premier principe auquel sont subordonnées les différentes parties qui
le composent."
La description de ce mécanisme, de façon un peu sommaire, permet de comprendre deux choses selon que l'on
se place du côté de ses défaillances, ou du côté des opportunités qu'il recèle. En effet, chaque activité peut
comporter des défaillances et engendrer des conséquences sur les produits conçus (défaut de perception Æ produit incomplet, défaut de compréhension Æ produit inadapté, défaut d'imagination Æ produit non optimisé, défaut d'expression Æ produit non standard ou incompréhensible). A l'inverse, chaque activité peut créer des opportunités, des "breakthrough" en fonction de la richesse
culturelle et de la maturité du praticien par rapport aux
utilisateurs de sa création.
"SYSTEME (philosophie) signifie en général un assemblage ou un enchaînement de principes et de conclusions; ou bien encore, le tout et l'ensemble d'une théorie
dont les différentes parties sont liées entre elles, se suivent et dépendent les unes des autres.
Ce mot est formé d'un mot grec qui signifie composition
ou assemblage. C'est dans ce sens là que l'on dit : un
système de philosophie, un système d'astronomie, le système de Descartes, celui de Newton… Les théologiens
ont formé une quantité de systèmes sur la grâce."
VISION SYSTEME ET HERITAGE CULTUREL
Penser système, c'est élargir la vision des choses à des
environnements plus vastes, c'est aussi envisager d'autres
points de vue pour explorer des dimensions non encore
envisagées, donc en quelque sorte c'est s'approcher des
limites culturelles à un instant donné dans un contexte de
société donné.
"SYSTEME (en astronomie) est la supposition d'un certain arrangement des différentes parties qui composent
l'univers, d'après laquelle hypothèse les astronomes expliquent tous les phénomènes ou apparences des corps
célestes."
La "vision système" est aussi un moyen pour innover en
imaginant (ou en découvrant) de nouvelles relations entre les objets ; cette vision des choses permet aussi d'inventer de nouveaux objets pour répondre à de nouveaux
besoins ou les susciter.
Dans le contexte de notre ère matérialiste, et à l'aide de
ces considérations, nous pouvons parler de "Système" en
tant que concept abstrait qui inclut une finalité et est défini à l'origine par une mission et un périmètre. Tout
changement de périmètre et/ou de mission implique la
définition d'un autre système.
Le créateur / concepteur est néanmoins confronté à ce
problème de culture, car il doit savoir jusqu'où il peut aller dans ces limites, au risque d'être incompris ou encore
de ne pouvoir vendre sa production du simple fait de rejet. De nombreux exemples, que les spécialistes du marketing sont supposés connaître, existent. Concevoir et
construire une voiture particulière remplie d'innovations
technologiques, nécessitant une conduite totalement différente du fait d'automatismes ou encore de commandes
vocale ou par joystick est quelque chose de techniquement faisable aujourd'hui. Quelle en serait l'adoption par
le public?
Tout ensemble pour lequel nous ne pouvons pas établir
de finalité, de mission et de périmètre ne peut pas être
appréhendé comme un système et ne peut être traité selon les principes de l'Ingénierie des Systèmes. C'est spécifiquement le cas quand nous arrivons au niveau élémentaire de constituant dans la décomposition hiérarchisée d'un système (niveau auquel il ne subsiste plus que
des caractéristiques physiques), ou quand nous voulons
étudier un ensemble de haut niveau d'abstraction tel un
"sur-système" fortement complexe, pour lequel la mission ne peut plus être identifiée avec certitude (par
exemple, la société humaine).
Depuis le début de cet article, nous utilisons le terme
système sans en avoir donné une définition actuelle utilisable dans le contexte technologique ou organisationnel.
Afin de progresser dans le raisonnement, il est essentiel
de considérer notre héritage culturel ; l'auteur a étudié
l'Encyclopédie de D. DIDEROT en sa deuxième édition
du 18ème siècle [4]. Quinze pages sont consacrées à la
notion de système. En voici quelques extraits :
VERS UNE DEFINITION MODERNE DE LA NOTION
DE SYSTEME
Certes les définitions standardisées actuelles sont intéressantes, néanmoins elles sont un peu limitées pour refléter la richesse du concept hérité du passé. A titre
d'exemple, voici deux définitions, non traduites pour ne
pas fausser ou amputer la compréhension :
SYSTEME (métaphysique) n'est autre chose que la disposition des différentes parties d'un art ou d'une science
dans un état où elles se soutiennent toutes mutuellement,
et où les dernières s'expliquent par les premières. Celles
qui rendent raison des autres s'appellent principes ; et le
système est d'autant plus parfait que les principes sont
en plus petit nombre : il est même à souhaiter qu'on les
réduisent à un seul. Car de même que dans une horloge
Dans l'ISO/IEC 15288 version 2002 - A system is a
combination of interacting elements organized to
achieve one or more stated purposes.
NOTE 1: A system may be considered as a product or as
the services it provides.
25
NOTE 2: In practice, the interpretation of its meaning is
frequently clarified by the use of an associative noun,
e.g. aircraft system. Alternatively the word system may
be substituted simply by a context dependent synonym,
e.g. aircraft, though this may then obscure a system
principles perspective. [1]
besoins et de remplir la mission correspondant à sa finalité.
Cette définition peut être modélisée comme le montre la
figure 6.
Finalité
Bien que cette vision soit adaptée aux petits équipements, elle masque en réalité la "vision système", en
concentrant l'attention sur un point de vue restreint. Le
standard n'englobe pas tous les concepts sous-tendus par
l'approche systémique (Théorie des systèmes). Ce qu'on
peut en tirer n'est pas assez puissant pour former une
base cohérente à la mise en oeuvre d'une véritable "vision système" et, en conséquence, pour concevoir correctement des systèmes complexes.
tracée vers
Mission
Objective
Objectifs
Objectifs
tracée vers
tracés vers
Besoins & attentes
Besoins & attentes
Besoins & attentes
Dans l'EIA 632 version 1999 - [A system is] an aggregation of end products and enabling products to achieve a
given purpose.
satisfait par
satisfait par
Interactions mutuelles
System concept: A system consists of both the end products to be used by an acquirer for an intended purpose
and the set of enabling products that enable the creation, realization, and use of an end product, or an aggregation of end products. Enabling products are used
to perform the associated process functions of the system—develop, produce, test, deploy, and support the end
products; train the operators and maintenance staff of
the end products; and retire or dispose of end products
that are no longer viable for use. Both the end products
and the enabling products are either developed or reused, as appropriate. [2]
exécutées par
constituants
exécutées par
constituants
constituants
constituants
Figure 6: Un modèle pour définir les systèmes.
Pour se rapprocher de la théorie des systèmes [5] et [6],
la définition doit également comprendre le principe d'encapsulation, qui postule qu'un système existe dans un
système de niveau supérieur et opère en interaction avec
d'autres systèmes - voir figure 7.
Cette définition ne reflète pas ce que nous appelons la
"vision système". Ce standard décrit surtout les activités
pour faire l'ingénierie des systèmes comme son titre l'indique.
Système
externe
Système
externe
e
stèm
ur sy
Sur s
Les considérations suivantes et les conséquences d'une
définition bien structurée du terme "système" sont utiles
pour l'ingénierie de n'importe quel type de système. La
définition suivante a été utilisée avec succès par l'auteur
de cet article dans le contexte de projets industriels.
Système
externe
ème
Sur syst
Système
étudié
Système
externe
Figure 7: Principe d'encapsulation.
"un système est un ensemble de constituants (personnes,
équipements, logiciels, matériaux, procédures ou services) coordonnés de sorte que leurs interactions mutuelles, utilisant des ressources dans un contexte donné, satisfassent les besoins et attentes qui sont issus de la mission et des objectifs du système, eux-mêmes issus de sa
finalité".
MODELISATION DE LA DEFINITION D'UN SYSTEME
La figure 8 récapitule les différents concepts qui doivent
être pris en compte pendant la définition et l'ingénierie
d'un système. Ce modèle peut être appliqué à n'importe
quel type de système et en particulier aux organisations
et aux entreprises.
Ou encore de façon moins complète : ensemble composite de personnels, matériels, logiciels et de processus,
organisés de manière à ce que leur inter fonctionnement
permette, dans un environnement donné, de satisfaire les
26
Aspect besoins & attentes
des flux d'entrées et de sorties et commandent ou déclenchent d'autres fonctions.
Système
est caractérisé par
Finalité
Mission
L'architecture organique est un ensemble de constituants
"physiques et concrets" qui réalisent les fonctions du
système. Les constituants échangent les flux d'entrées,
de sorties et de contrôle eux-mêmes transportés par des
liens physiques. Ces constituants physiques, désignés
dans l'ISO 15288 sous le nom de "systems" et de "system elements" peuvent être tangibles ou intangibles.
Tangible signifie que le constituant est caractérisé par sa
nature (logiciel, humain, service, matériel…), intangible
signifie que le constituant est caractérisé par sa propre
finalité et mission.
Objectifs
est déclinée en
scénarios
opérationnels
sont sollicités par
réalisent
Fonctions
Système
externe
supportent
Système
externe
Aspect frontières
constituants
Aspect architectures
Les interactions de ces constituants tangibles et intangibles sont reprises par la notion d'interface, dont la complexité dépend fortement de la manière dont les différentes architectures ont été conçues. Une partie de l'architecture organique traite des effets connexes à l'exécution
des fonctions : utilisation de ressources, production de
déchets, génération de vibration, d'effets psychologiques
pour l'équipage d'un avion, etc.
Figure 8: Eléments caractérisant un système.
Quatre aspects principaux doivent être considérés lors de
la définition d'un système comme exposé ci-après.
1) L'aspect "besoins et attentes"
Pour prétendre à l'appellation de "système", les points
suivants nécessitent d'être identifiés :
3) Les aspects "périmètre et interface"
Finalité – La finalité détermine la pertinence du système
dans le contexte d'une situation donnée. La finalité est la
réponse à la question "Pourquoi ce système doit-il exister ?"
Cet aspect est directement issu du principe systémique
d'encapsulation. Un système, de par sa nature, n'existe
que dans l'esprit des hommes. Le périmètre du système
dépend de ce que l'on inclut ou pas dans le système. La
notion de périmètre est non seulement une question de
connexions physiques mais inclut également les limites
fonctionnelles. Les interdépendances entre les systèmes
sont modélisées en utilisant le concept de "scénario opérationnel". L'ensemble de tous les scénarios opérationnels représente le comportement global du système
concernant les multiples situations de sa vie.
Mission – La mission est la fonction ultime du système,
celle qui englobe toutes les autres, donc celle qui transforme toutes les entrées et sollicitations en sorties et réactions. La mission est la réponse à la question "Que doit
faire le système ?"
Objectifs – Les objectifs fournissent les aspects quantitatifs et qualitatifs de la finalité et de la mission en tant
qu'informations mesurables relatives à l'espace, au temps
et à l'efficacité ou la performance. Les objectifs sont les
réponses aux questions : "combien d'entrées et de sorties ? Combien d'itérations ? Quelle fréquence ? Quelle
fiabilité ? A quel coût ? Etc."
4) L'aspect "hiérarchie"
Les systèmes sont décomposés successivement en systèmes de niveaux inférieurs selon un mode hiérarchique,
chaque niveau est considéré comme un système caractérisé par sa propre finalité et mission. La décomposition
est poursuivie jusqu'à ce que des constituants technologiques soient identifiés par des caractéristiques physiques plutôt que par une finalité. Par exemple, un "segment sol" peut être décomposé en niveaux de "soussystèmes de détection" jusqu'à atteindre le niveau "opérateur radar", "antenne" et "logiciel de surveillance".
2) L'aspect "architecture fonctionnelle et organique"
Ces deux vues complémentaires du système fournissent
la base fondamentale de l'existence du système.
L'architecture fonctionnelle est une structure de fonctions qui permet au système d'exécuter tous les scénarios
opérationnels identifiés sur l'ensemble du cycle de vie.
Les scénarios opérationnels raffinent la mission en un
ensemble de scénarios (ou cas d'utilisation). Un scénario
est un ensemble de fonctions et de structures dynamiques qui décrivent comment les différentes parties de la
mission seront exécutées. En d'autres termes, une fonction transforme des entrées en sorties telles que les matériaux, l'énergie ou l'information ; les fonctions échangent
C'est la vue hiérarchique du système. Mais gardons à
l'esprit que n'importe quel système, où qu'il soit situé
dans la hiérarchie, possède deux structures : une pour ses
fonctions, une autre pour ses constituants physiques. Les
divers niveaux d'abstraction doivent former un ensemble
cohérent, depuis la fonction ultime qu'est la mission jusqu'aux aux fonctions élémentaires réalisées par les constituants.
27
être décomposé en sous-processus et ainsi de suite. Un
processus n'est rien de moins qu'une fonction qui
échange des flux d'entrée, de sortie et de commandecontrôle.
En conclusion de ce chapitre, la vision système incite à
créer des systèmes au travers de vues harmonisées. Celles-ci expriment des missions précises, missions remplies par des constituants auxquels sont allouées les
fonctions, et ceci afin d'effectuer des échanges définis
par leurs interfaces.
L'architecture organique est constituée des différentes
entités d'organisation, tel que le Personnel, les Experts,
les Gestionnaires, les Dirigeants, structurées dans des
Services, Départements, Divisions, Directions, etc. Les
entités d'organisation de l'entreprise exécutent les processus qui leur sont attribués. Parce que l'entreprise est
basée sur des personnes, les liens physiques entre les entités d'organisation sont de type relationnel/sensoriel accompagnés d'une sémantique reconnue et partagée.
La "vision système" permet d'organiser des entités de
manière cohérente et harmonisée, où les constituants et
leurs fonctions ne se "marchent pas sur leurs platesbandes", mais collaborent pour exécuter des missions
précises, où les interfaces sont bien définies et où les interdépendances sont claires.
APPLICATION AUX ENTREPRISES INDUSTRIELLES
En remarque, il est habituel de présenter l'organigramme
de l'entreprise plutôt que le logigramme des processus.
Trop souvent, l'aspect dynamique des systèmes est négligé : les entreprises et les organisations tracent facilement des organigrammes ; les difficultés surviennent
avec les processus et les procédures qui définissent les
interactions entre les entités (vue dynamique et comportementale des flux).
Pour considérer une entreprise en tant que système, nous
appliquerons à ce contexte les quatre aspects précédemment énoncés.
1) L'aspect des besoins et des attentes
La finalité d'une entreprise industrielle est aujourd'hui
orientée vers un but économique et social. Une entreprise industrielle peut être vue comme une entité abstraite créée pour enrichir une nation ou des ensembles de
personnes, qui permettent l'échange de marchandises,
d'énergie et de services entre les personnes, qui aussi
emploient et rémunèrent d'autres personnes, etc. Pour
trouver la finalité d'une entité, nous recherchons habituellement l'entité de niveau abstraite supérieure. Dans
ce cas-ci, elle peut être représentée par la partie culturelle de la société.
3) L'aspect "périmètre et interfaces"
Le périmètre d'une entreprise est défini en termes de
fonctions (missions opérationnelles) et de constituants
physiques (entités d'organisation), selon le domaine servi
par l'entreprise. En terme de fonctions, l'entreprise définit généralement ses activités autour de ses métiers de
base, sous-traite des services connexes pour acquérir des
ressources et/ou sous-traite une partie de ses activités
pour livrer les volumes en temps et en heure. Les limites
fonctionnelles sont également définies par les objectifs
que l'entreprise veut réaliser, sa taille sociale, sa position
sur le marché, et ainsi de suite.
Les missions pour atteindre cette finalité peuvent être,
par exemple, la production de marchandises ou d'énergie, la fourniture de services, le transport des marchandises et des personnes, la maintenance de produits, le retrait de service d'infrastructures, etc.
Associés, clients, fournisseurs, concurrents, administrations, couverture géographique (locale, nationale, internationale) représentent le périmètre physique, et bien sûr
les interfaces sont définies par rapport à ces contextes.
Comme souvent, les interfaces sont le lieu commun de
difficultés : par exemple les difficultés pour répartir correctement les activités entre les partenaires, c'est-à-dire
quelle est la part et la responsabilité du client, de l'entreprise, des fournisseurs de cette entreprise ?
Les objectifs sont les aspects quantitatifs et qualitatifs
qui sont associés aux missions et parfois à la finalité :
combien de marchandises à produire par jour, combien
de personnes à transporter par mois, combien d'étudiants
à enseigner par an, etc. ?
2) L'aspect "architectures"
L'architecture fonctionnelle est représentée par les fonctions opérationnelles de l'entreprise. Typiquement une
entreprise développe de nouveaux produits (Développement) ; les produit (Production) ; les vend (Ventes) ;
contrôle tous les moyens internes et fait le lien avec les
administrations et les lois qui sont des objets externes au
périmètre de l'entreprise (Direction). Ces fonctions de
haut niveau sont décomposées en activités ; les activités
sont groupées dans des ensembles de processus dédiés à
ces activités tels que les processus du domaine technique, processus de soutien logistique, processus contractuel, processus de gestion de projet, processus de support
à l'activité de l'entreprise, etc. Chaque processus peut
Aujourd'hui, le contexte social et économique change
rapidement ; des changements qui apparaissent mineurs
au premier abord révèlent dans le temps des effets majeurs et des conséquences importantes, ce qui oblige les
entreprises à être capables de s'adapter en permanence.
4) L'aspect "hiérarchies"
Chaque entité physique de l'entreprise (Direction, Divisions, Départements, Services) peut être vue à son tour
comme un système. Nous devons définir pour chaque
entité les quatre aspects qui caractérisent un système
28
comme vu précédemment (finalité, mission, objectifs,
périmètre et interfaces, architectures fonctionnelle et
physique, hiérarchies). À des niveaux plus bas de décomposition, une entité est physiquement composée de
"rôles" tenus par des personnes, de procédures documentées, d'outils et autres moyens.
Efficacité de l'approche. Les pratiques d'ingénierie appliquées aux "Systèmes à Humains prépondérants" permettraient de justifier et d'optimiser la portée, les activités, les structures, les moyens, les ressources et les infrastructures de manière efficace et cohérente. Mais l'efficacité est-elle vraiment la caractéristique la plus importante de ce type de système ? Cela dépend de sa finalité
et de ses objectifs ; ceci semble évident pour des Systèmes d'Organisation axés sur l'économie : tout le monde
espère des bénéfices, et des bénéfices qui augmentent en
réduisant la durée et les moyens du développement tout
en optimisant le système de production. Le cas de
l'OTAN a été étudié et son efficacité opérationnelle ou
de fonctionnement pourrait tirer profit d'une telle approche. Mais elle n'est probablement pas aussi évidente
pour tous les types d'organisations.
Dans une entreprise industrielle, développer un nouveau
produit est généralement réalisé par l'intermédiaire d'une
"équipe de projet" qui peut être vue comme un système.
Ce système doit être considéré comme un système abstrait (un système de mission) généralement appelé "un
projet" parce qu'il se concentre sur la mission dans un
temps limité (développer un prototype), partageant des
moyens et des qualifications fournis par l'entreprise.
POURQUOI APPLIQUER CETTE DEMARCHE?
1. Complexité
Facteur humain. Dans les "Systèmes à Humains prépondérants" nous faisons face à ce qui s'appelle le facteur humain dans le contexte du travail et de la culture.
Le propos de cet article n'est pas d'analyser les facteurs
humains, mais quelques idées sont simplement soulignées :
– La rationalité est une question culturelle : le raisonnable n'est pas dans la tête de toute les parties d'une société. La vision système oblige les personnes à s'interroger
sur ce qui a été fait précédemment, à remettre en cause
des acquis. De façon naturelle, un ingénieur concepteur
de systèmes doit s'interroger sur sa manière de travailler
et remettre en cause les produits qu'il crée pour être sûr
de leur pertinence par rapport à leur environnement physique et au contexte culturel. Tout être humain veut-il
remettre en cause son travail dans ce sens ?
La complexité d'organisations telles que l'OTAN (pour
laquelle nous avons appliqué définition et démarche proposés dans cet article), ou de grandes enteprises, réside
dans le nombre de départements, d'interactions entre les
départements, les buts et les objectifs multiples de chacun, et le partage de moyens et de l'infrastructure. La
complexité est évidemment un obstacle à maîtriser pour
n'importe quel type d'organisation. La vision système et
les méthodes associées sont des moyens pour maîtriser la
complexité. La vision système inclut des limitations à
respecter :
- l'une d'entre elles est liée à la décomposition du système par niveaux, chaque niveau n'excédant pas 5 + 2
sous-systèmes, afin d'éviter la prolifération incontrôlable
des interfaces ;
– Qui est supposé faire l'ingénierie de tels systèmes ?
Devrait-elle être faite par les acteurs du système ou par
des ingénieurs ? La démarche d'Ingénierie des Systèmes
est difficile à appliquer parce qu'elle exige une expression rigoureuse du besoin et la recherche d'une solution
correspondante optimisée, et pas seulement énoncer des
solutions par approximations successives qui pourraient
satisfaire un hypothétique problème. Généralement, les
humains préfèrent travailler directement sur les objets
physiques et tangibles plutôt que sur des objets immatériels ; or chose curieuse, les Systèmes d'Organisation
sont "virtuels".
- une autre est de faire partager une compréhension unique des relations par toutes les parties impliquées.
La première limitation améliore la gestion de la complexité, tandis que la seconde semble éviter la réduction
de complexité. Mais cette dernière impression devient
fausse quand la "vision système" est appliquée comme
expliqué en détail dans le chapitre 4. Quand nous considérons l'OTAN comme un ensemble de systèmes interagissant, des simplifications peuvent surgir. En considérant l'OTAN de cette manière, nous faisons face à un ensemble de systèmes, et chaque système peut appliquer le
même cadre pour être conçu, utilisé, maintenu, ou retiré
du service.
– Qui dirigent les entreprises aujourd'hui : les ingénieurs,
les avocats d'affaire, les vendeurs, les directeurs financiers, les actionnaires ? Très souvent, sous la pression
des résultats économiques espérés, les directeurs (hors
du domaine technique) veulent voir une solution réalisée
immédiatement : ce problème mène à des solutions rapidement retenues et rédigées avant de définir les besoins
les justifiant. Etant donné ce trait particulier du comportement humain, concevoir un Système d'Organisation
aurait seulement pour résultat un organigramme sans
2. Système Humain et Facteur humain
Une des conséquences de la définition proposée est que
des systèmes d'organisation peuvent être conçus comme
les systèmes technologiques employant les mêmes pratiques. La question qui se pose réside dans l'adoption des
pratiques d'ingénierie par les acteurs de ces "Systèmes à
Humains prépondérants".
29
que ce soit du côté du concepteur comme de celui de
l'utilisateur, peuvent représenter un obstacle ou au
contraire un catalyseur pour l'adoption des pratiques en
matière de Vision Système et d'Ingénierie des Systèmes
appliquée aux "Systèmes à Humains prépondérants": un
vrai paradoxe !
prêter l'attention nécessaire au marché, aux besoins réels
ou aux processus.
– N'importe quel groupe sérieux est normalement orienté
par une finalité, ainsi que des objectifs plus ou moins
bien définis. Parce que le contexte ou la composition du
groupe pourrait changer dans le temps, l'organisation
doit vérifier en permanence si les buts personnels, les
objectifs et leur compréhension sont conformes à ceux
du groupe, sinon le groupe se désintègre.
BIBLIOGRAPHIE
1. ISO-IEC 15288, Systems & Software Engineering –
System Life Cycle Processes. 2002.
2. ANSI/EIA 632, Processes for Engineering a System.
1998.
3. Life cycle integration - Study for using ISO/IEC
15288 within NATO context- MAP système
NAT/LCI-TECH01/AF-09 – December 2002.
4. Encyclopédie de D. Diderot, 1772.
5. Walliser B. Théorie des Systèmes : Systèmes & modèles. Seuil, 1977.
6. J.L. Lemoigne. Théorie des Systèmes: La théorie du
système général. PUF, 1977.
CONCLUSION
Le propos de cet article était de montrer que des éléments de la Théorie générale des systèmes peuvent être
appliqués pour des systèmes créés et utilisés par
l'homme aussi bien aux ensembles technologiques
qu'aux organisations. Toutes les notions explicitées ont
pu être appliquées sans difficulté dans plusieurs contextes industriels et d'organisations. Quoique l'approche développée semble appropriée et attrayante d'une manière
générale, les questions soulevées par le facteur humain,
30
Vers un Prototypage des Interfaces Graphiques Incluant
Vraiment l’Utilisateur Final
Jean Vanderdonckt, Adrien Coyette
Belgian Laboratory of Computer-Human Interaction (BCHI), Information Systems Unit (ISYS)
Louvain School of Management (IAG), Université catholique de Louvain (UCL)
Place des Doyens, 1 – B-1348 Louvain-la-Neuve (Belgique)
{jean.vanderdonckt, adrien.coyette}@uclouvain.be – http://www.isys.ucl.ac.be/bchi, http://www.usixml.org
RESUME
KEYWORDS : computer-aided design, level of fidelity,
Le besoins en prototypage des interfaces homme-machine graphiques varient en fonction du moment où ils
interviennent dans le cycle de vie de développement de
l’application interactive. Dans ce but, la notion de niveau
de fidélité du prototypage est introduite, définie et illustrée de façon à être supportée par des outils adéquats.
Pour chaque niveau de fidélité, les forces et les faiblesses de ces outils sont développées de façon à identifier
quel outil peut le mieux convenir en fonction de la phase
de développement. Les niveaux de fidélité basse, modérée et élevée sont respectivement supportés par des outils
idoines développés à cet égard : respectivement, un outil
d’esquisse d’interface baptisé SketchiXML, un outil de
dessin vectoriel, baptisé VisiXML, et un éditeur d’interface avancé, baptisé GrafiXML. Ces outils logiciels sont
interopérables par l’échange de spécifications d’une interface homme-machine, rédigées dans le langage UsiXML (USer Interface eXtensible Markup Language), un
langage de description d’interface homme-machine basé
sur XML.
model-driven engineering, prototyping, sketching tool,
user interface description language, USer Interface eXtensible Markup Language.
MOTS CLES : Approche dirigée par les modèles, con-
ception assistée par ordinateur, langage de description
d’interface, niveau de fidélité, outil d’esquisse, prototypage, USer Interface eXtensible Markup Language.
INTRODUCTION
La plupart des acteurs principaux intervenant dans
l’équipe de développement d’une application interactive
s’accorde généralement à dire que le prototypage de
l’application en général [6] et de son interface hommemachine (IHM) en particulier [2] sont des activités à encourager fortement. Notamment pour découvrir le plus
rapidement possible les écarts entre les besoins des utilisateurs finaux et les spécifications de l’interface, du système et pour bien d’autres raisons encore [4,25,27]. En
revanche, quand il s’agit des moyens à déployer pour assurer la réalisation de ce prototypage et garantir son retour sur investissement, les moyens varient largement en
forme, en méthode, en ressource mobilisée, en durée. Et
les acteurs si prompts à favoriser le prototypage se retrouvent bien vite démunis quant au moyen le plus approprié pour leur projet et respectant leur budget. Puisque différents moyens de prototypage existent mettant en
œuvre des moyens à coût variable, il nous paraît opportun de dégager des grandes familles de méthodes de prototypage d’interface en fonction de différents critères.
Tel est l’objectif de cette communication.
ABSTRACT
The requirements for prototyping graphical user interfaces vary depending on the moment they are considered
during the development life cycle of the interactive application. For this purpose, the notion of ‘level of fidelity’ is introduced, defined, and illustrated so as to be supported by appropriate tools. For each level of fidelity,
the strengths and the weaknesses of these supporting
tools are discussed in order to identify which one is estimated the most appropriate for each step of the development life cycle. The levels of fidelity, respectively
low, moderate, and high are supported by individual
softwares which have been developed for this purpose:
respectively a sketching tool, named SketchiXML, a
vectorial drawing tool, named VisiXML, and an advanced interface editor, named GrafiXML. These tools are
interoperable by exchanging the specifications of a user
interface written in the UsiXML language (USer Interface eXtensible Markup Language), a XML-compliant
user interface description language.
31
On considère généralement que le prototypage rapide de
l’interface est une méthode particulière qui se situe dans
le cycle général de vie de développement de cette interface. Ou bien: “une stratégie spécifique pour conduire
l’élicitation des besoins desquels les besoins des utilisateurs finaux sont extraits, présentés, et raffinés sur base
d’un modèle de travail de l’application” selon l’interprétation de Boar [6]. Pour ce qui est de l’interface en particulier, il s’agit d’aboutir le plus rapidement possible à
des spécifications précises qui rencontrent les besoins
exprimés ou perçus comme tels par les utilisateurs finaux. Cette démarche devrait en principe s’opérer de façon à ce que cette découverte soit la plus efficace possible: arriver le plus rapidement en consommant le moins
de ressources possible, notamment en évitant de coder
directement l’interface, une activité considérée comme
coûteuse. Pour ce faire, on remplace l’interface à spécifier par une représentation, un modèle. Puisque l’interface est graphique par nature – ou du moins de modalité
Fidélité\Critère
Phase de développement
Usage
Exploration, découverte, évocation, communication
Type de prototypage
Type d’approche
Facilité de changement
Coût
Temps requis
Naturalité de la représentation
Niveau de détail
Fréquence d’itération
Niveau d’interactivité
Représentation
Horizontal
Ascendante (bottom up)
Elevée
Moyenne
Conception continue, validation de
l’ergonomie du prototype, application en cours de route
Présentation, contenu, layout, début
de la navigation
Simulation, raffinement, itération,
amélioration, validation de
l’utilisabilité, test utilisateur
Diagonal
Expansive (middle-out)
Modérée
Faible
Faible
Très élevée
Modéré
Modéré
Modérée
Elevé
Elevé
Faible
Faible
Très élevée
Faible
Esquisse
Modéré
Elevée
Modéré
Dessin, dessin vectoriel
Convient pour…
Des applications de grande
taille
Des applications moyennes
Niveau des spécifications
Outils en général
Abstrait
Mixte
Elevé
Faible
Elevé
Présentation et navigation réelles
Des applications de taille réduite ou des fragments d’autres
types d’application
Concret
Denim [14], FreeForms [24],
GUILayout [5], Paper [27], JavaSketchIt [8], SILK [17], SketchREAD [1]
SketchiXML [9,10,11]
EtchaPad [22], ExcelProto [3],
MidFi [12], ProtoMixer [23]
Contenu
Outils UsiXML
URL
Basse
Elicitation des besoins, conception préliminaire, conceptualisation, début de l’application
Présentation surtout
Elevée
Conception détaillée, application en fin de spécification
Présentation et navigation,
contenu, layout, fonctionnalités
Propagation générale à
l’application, spécification finale, documentation, marketing
Vertical
Descendante (top down)
Très faible
Editeurs d’interface fournis
avec les environnements intégrés de développement
VisiXML [30]
GrafiXML [19,20],
FormiXML [30]
http://www.usixml.org/index.
http://www.usixml.org/index.
http://www.usixml.org/index.
php?view=page&idpage=29
php?view=page&idpage=11
php?view=page&idpage=10
Tableau 1: Comparaison des caractéristiques des différents niveaux de fidélité.
graphique majoritaire –, il est fondamental que cette représentation soit aussi graphique. Autrement, il est difficile, voire impossible, pour les utilisateurs finaux de réagir sur une autre représentation, de donner leur avis et
de valider les spécifications en cours. Des spécifications
abstraites, même si elles sont recommandables [10], ne
permettent pas de faire intervenir pleinement l’utilisateur
car la non-connaissance du langage abstrait demeurera
toujours pour eux une barrière infranchissable. Il est
donc primordial de d’abord déterminer quelle représentation manipuler, ce qui est abordé dans ce qui suit.
UN RÉFÉRENTIEL POUR LE PROTOTYPAGE
D’INTERFACES
Comme les besoins en prototypage rapide d’interface varient en fonction du projet et des ressources qui lui sont
allouées, nous proposons de choisir un prototypage basé
sur la notion de fidélité du prototypage. La fidélité du
prototypage exprime la similarité entre la représentation
de l’interface prototypée et l’interface finale. On dira
que la fidélité est élevée (en anglais, high fidelity [26]) si
la représentation du prototype est la plus proche possible
de celle de l’interface finale, pour ne pas dire qu’elles
sont identiques. Dans ce cas, un prototype à un niveau
32
de fidélité élevée devrait être aussi proche que possible
de l’interface finale en termes de présentation (quels sont
les objets interactifs utilisés), de navigation globale
(comment naviguer entre les espaces d’information), de
navigation locale (comment naviguer à l’intérieur d’un
espace d’information), de contenu, de layout et de fonctionnalités. On dira que la fidélité est faible (en anglais,
low fidelity [26]) si la représentation du prototype évoque l’interface finale sans la représenter totalement en
détails. Entre les deux, on exprimera que la fidélité est
modérée (en anglais, mid fidelity [11,12]).
En général, on considère que la fidélité d’un prototype
reste constante et ne fait pas intervenir différentes représentations. Cependant, on peut très bien imaginer disposer d’un prototypage mélangeant différents niveaux de
fidélité si le prototype est composé de fragments de fidélité différentes. Ceci peut arriver lorsqu’un prototype est
imaginé à partir de nouvelles esquisses (fidélité faible),
de recopies d’écran estimées applicables (fidélité élevée), ou de dessins issus de logiciel de présentation assistée par ordinateur (fidélité moyenne). Petrie &
Schneider [23] présentent ProtoMixer, un outil de support au prototypage mixte mêlant plusieurs niveaux.
Le tableau 1 compare les trois niveaux de fidélité ainsi
définis sur base d’une même grille d’analyse constituée
de critères. Dans la suite du texte, nous reprendrons seulements les critères considérés comme les plus importants de cette grille d’analyse.
Le niveau de fidélité basse est applicable surtout au
cours des étapes préliminaires du cycle de vie de développement d’une application interactive, principalement
lorsque les spécifications de l’interface sont inconnues,
incomplètes, restent à découvrir, à explorer. Dans ce cas,
l’objectif est surtout d’explorer des conceptions alternatives possibles sans trop les raffiner afin de déterminer
les grands contours de l’interface. Puisque cette étape
peut être itérée fréquemment, il est fondamental que son
coût et son temps de production demeurent faibles. Ceci
au prix d’une représentation basse souvent centrée sur la
présentation : pas question de développer ici déjà les
fonctionnalités avancées de l’application si on n’est pas
encore sûr qu’elles correspondent aux besoins des utilisateurs finaux.
Au contraire, le niveau de fidélité élevée convient principalement pour les étapes avancées du cycle de vie de
développement d’une application interactive. Soit parce
que le domaine est suffisamment connu et maîtrisé pour
proposer une interface dont on pense raisonnablement
qu’elle va s’approcher favorablement de l’interface finale. Soit parce que les itérations répétées du prototypage à un niveau de fidélité plus bas ont permis de dégager les conceptions acceptables et qu’il importe maintenant de les raffiner jusqu’à obtention de l’interface finale. Dans ce cas, l’objectif est surtout de peaufiner
l’interface pour qu’elle soit la plus finalisée possible. Par
conséquent, son coût et son temps de production sont
élevés. Il est donc souhaitable de répéter le moins possible un prototypage à un niveau de fidélité élevée.
Prototype à un niveau
de fidélité élevée
Prototype à un niveau
de fidélité modérée
Prototype à un niveau
de fidélité basse
Figure 1: Trajectoires possibles de prototypage.
Le prototypage à un niveau de fidélité élevée peut être
consécutif à un prototypage à un niveau de fidélité
moins élevé comme soulevé ci-dessus, mais pas nécessairement. Toutes les trajectoires de prototypage son
théoriquement possibles entre les différents niveaux de
fidélité [4,14,23] comme la figure 1 le représente. En
principe, le prototypage peut être initié à n’importe quel
niveau de fidélité, pour autant que cela corresponde aux
besoins des utilisateurs finaux et se terminer à n’importe
quel niveau (figure 1). En pratique cependant, on ob-
33
serve très fréquemment le passage d’une fidélité basse
ou moyenne à une fidélité élevée pour supporter un prototypage réellement progressif et itératif. Le prototypage
peut être itéré à chaque niveau, mais les itérations devraient être moins fréquentes à un niveau de fidélité élevé qu’à un niveau de fidélité bas ou modéré. Il n’est pas
nécessaire non plus de traverser chacun des niveaux
pour obtenir le prototypage souhaité. Tout dépend de la
couverture de l’interface à prototyper. Pour cela, on peut
s’appuyer sur différents cadres de référence permettant
d’identifier quel type de prototypage est souhaitable.
Le cadre de référence de Nielsen (figure 2) distingue
deux types de prototypage en fonction du niveau d’interactivité couvert (tableau 1). On peut décomposer une
application interactive complète en trois couches :
l’interface homme-machine (IHM), la couche d’abstraction et de contrôle de l’application et le noyau fonctionnel comportant les fonctions sémantiques de l’application ; ceci est typique du patron MVC (Model-ViewController) ou PAC (Présentation-Abstraction-Contrôle)
de J. Coutaz.
Prototype vertical
Prototype horizontal
Interface homme-machine
Couche d’abstraction
Application
interactive
complète
Noyau fonctionnel
Figure 2: Prototypages vertical vs. horizontal.
Le type de prototypage est alors dit horizontal si on souhaite prototyper le maximum des fonctionnalités de
l’application au travers de son interface. L’interface est
alors prototypée à un niveau de fidélité faible ou modéré
pour vérifier que toutes les fonctionnalités sont bien
identifiées et couvertes. En revanche, le prototypage
n’est pas profond puisque seuls les aspects primordiaux
(p. ex. la présentation) priment sur les aspects détaillés
(p. ex. les fonctions réellement implémentées). Lorsque
la première couche horizontale est finalisée, par exemple
au travers d’une validation par les utilisateurs finaux, le
prototypage peut se propager vers les niveaux inférieurs
de la figure 2. L’interface est d’abord complétée, la couche d’abstraction est entamée, puis les fonctions.
Le type de prototypage est dit vertical si on souhaite se
concentrer sur quelques fonctionnalités de l’application
et que celles-ci doivent être suffisamment avancées pour
valider l’approche retenue. L’interface est alors prototypée à un niveau de fidélité élevée pour que ces fonctionnalités soient les plus détaillées possibles. En revanche,
le prototypage n’est pas large puisque seuls les aspects
détaillés (p. ex. jusqu’à la navigation locale) d’un petit
nombre de fonctionnalités comptent. Lorsque la colonne
de prototypage vertical est aboutie, le prototypage peut
se propager latéralement pour couvrir d’autres fonctionnalités non encore traitées auparavant.
tion des besoins informationnels de l’utilisateur final. Au
fur et à mesure que la navigation globale se précise, on
peut s’attaquer à la présentation particulière de l’unité
d’interaction résultant ainsi de la navigation et en préciser quelques éléments de sa navigation locale. La figure
4b montre que la navigation globale est la plus touchée
dans ce cas, puis la présentation, puis la navigation locale.
Prototype diagonal
Interface homme-machine
Couche d’abstraction
Application
interactive
complète
Noyau fonctionnel
Figure 3: Prototypage diagonal.
Dans la pratique, cependant, on observe souvent des projets où certains ensembles de fonctionnalités sont tantôt
bien maîtrisés (p. ex. suite à l’expérience acquise dans le
passé au travers d’autres applications interactives) tantôt
presque inconnus (p. ex. aucun autre système semblable
n’existe, aucune expérience préalable ou retour d’utilisation n’existe). Dans ce cas, il est possible de combiner
les deux types de prototypage dans le prototypage que
nous appelons diagonal [10,11] (figure 3). Dans ce type
de prototypage, les parties bien maîtrisées sont soumises
à un type de prototypage vertical tandis que les parties
mal maîtrisées sont soumises à un type de prototypage
horizontal. On peut ainsi marier les avantages des deux
types sans en souffrir des conséquences négatives. La
propagation du prototypage est alors dite expansive puisqu’elle peut s’étendre dans toutes les directions. C’est
pourquoi le prototypage à un niveau modéré convient
bien pour un type d’approche expansive (tableau 1), par
opposition au niveau bas pour une approche ascendante
et au niveau élevé pour une approche descendante.
Si maintenant nous poursuivons la décomposition de la
couche interface homme-machine en trois parties (la présentation, la navigation globale et la navigation locale),
le type de prototypage est alors être précisé et des nouvelles trajectoires de prototypage peuvent apparaître (figure 4). Le cas le plus fréquemment pratiqué consiste à
initialiser le prototypage de l’interface par la partie la
plus facile, la plus visuelle et la plus naturelle pour
l’utilisateur final : la présentation des informations. On
dit alors qu’il s’agit d’un prototype présentationnel d’abord (figure 4a). Il peut n’avoir aucune navigation ni
globale ni locale, auquel cas il s’agit d’une simulation
statique. La figure 4a montre une couverture plus large
de la présentation pour refléter la partie qui est effectivement prototypée. En général, le prototypage par papier
[27] convient bien et est largement éprouvé. Il peut aussi
comporter un embryon de navigation, bien souvent globale d’abord, locale ensuite car on préfère spécifier les
grands traits de la navigation globale avant de préciser
ceux de la navigation locale qui en découlent presque directement. A nouveau, le niveau de fidélité du prototypage est fonction de la couverture à prototyper.
Moins fréquemment, on observe le prototype navigationnel global d’abord (figure 4b) dans lequel on élabore
une architecture d’unités d’interaction ou d’information
dont on ne spécifie que le but et que l’on relie en fonc-
34
Enfin, encore moins fréquemment apparaît le prototype
navigationnel local d’abord (figure 4b). Dans celui-ci,
on précise quelle interaction l’utilisateur final souhaite
avoir avec les différents éléments d’information précis
(p. ex. quel filtre de recherche, quel ordre d’encodage,
quelle suite de boîte de dialogue dans un « wizard »).
Ceci étant précisé, on représente alors physiquement ces
éléments d’information (p. ex. au travers des objets interactifs, du contenu) au sein de la présentation et on boucle le tout par spécifier les grands traits de la navigation
globale. La figure 4c montre que, dans ce cas, la navigation locale a attiré le centre d’intérêt du prototypage,
puis la présentation, puis la navigation globale. Après
quoi, un prototypage vertical ou horizontal peut être
poursuivi.
Prototype présentationnel d’abord
Présentation
Navigation
locale
Navigation
globale
Couche d’abstraction
Noyau fonctionnel
Prototype navigationnel global d’abord
Présentation
Navigation
globale
Navigation
locale
Couche d’abstraction
Noyau fonctionnel
Prototype navigationnel local d’abord
Présentation
Navigation
globale
Navigation
locale
Couche d’abstraction
Noyau fonctionnel
Figure 4: Différents prototypages de l’interface : présentationnel (a), navigationnel global (b), navigationnel local (c).
Après avoir analysé quels sont les types de prototypage
possibles et après avoir dégagé certaines tendances,
voyons à présent comment supporter au mieux chaque
niveau de fidélité par des outils logiciels appropriés.
Pour chaque niveau de fidélité, nous passerons en revue
d’abord les grandes caractéristiques du prototypage à
supporter, puis nous citerons quelques outils représentatifs avant de présenter l’outil logiciel que nous avons développé pour chaque niveau.
La plupart du temps, les concepteurs et les développeurs
se reposent sur les outils qui sont fournis en standard
avec les environnements intégrés de développement, tels
que les éditeurs d’interface (en anglais, interface builders) d’origine. Par exemple, Microsoft Visual Builder
dans l’environnement éponyme.
L’ensemble de ces outils est interopérable : ils communiquent entre eux tous les spécifications de l’interface en
cours de prototypage au moyen d’un fichier rédigé en
UsiXML (USer Interface eXtensible Markup Language,
http://www.usixml.org) [19,20]. Ce langage de description d’interface utilisateur (en anglais, User Interface
Description Language - UIDL) possède une vocation
descriptive (spécifier au mieux les aspects de l’interface
en cours de développement) et une vocation générative
(autoriser la génération automatique de code ou un rendu
automatique de l’interface à partir de ses spécifications).
Ce langage de type XML a été créé au sein du projet européen Caméléon (http://giove.cnuce.cnr.it/cameleon.
html) et est poursuivi actuellement au sein du réseau
d’excellence Similar (http://www.similar.cc). Il couvre
notamment les aspects de tâche, du domaine, de l’interface abstraite, de l’interface concrète et du contexte
d’utilisation (c’est-à-dire l’utilisateur, sa plate-forme logicielle et matérielle et l’environnement physique dans
lequel il est plongé). Dans la suite, seule l’interface
concrète sera utilisée. Pour plus de détails, voir [19,20]
et le site. Il existe d’autres langages similaires, avec des
couvertures plus ou moins différentes et des objectifs
différents: l’étude [28] procure un aperçu de ces langages de description sous la forme d’une grille d’analyse.
D’un côté, ces éditeurs sont ceux qui offrent la présentation et la navigation native de la plate-forme sur laquelle
l’application interactive est développée ; on peut représenter directement l’interface désirée en tirant d’une palette d’objets ceux qui vont constituer l’interface et les
placer dans une surface de travail, ce qui constitue un
avantage indéniable tant du point de vue fonctionnel que
visuel (l’interface graphique étant visuelle par nature).
D’un autre côté, ces éditeurs se restreignent souvent à
l’édition d’interface graphique basée sur des objets interactifs statiquement prédéfinis. Dès lors qu’il s’agit
d’avoir des objets interactifs non natifs, non standards ou
dynamiquement gérés (p. ex. une barre de menu variable, une boîte de dialogue fonction du contenu), l’avantage de l’éditeur cesse : il n’est plus possible d’éditer une
telle interface et il faut recourir à la programmation manuelle. Il en va de même pour tous les aspects de navigation.
Voyons à présent quels sont les outils disponibles en
commençant par le niveau de fidélité élevée puisqu’il est
censé être le plus proche de l’interface finale que nous
espérons. Nous verrons ensuite progressivement les niveaux de fidélité inférieurs. Il est aussi convenable de
débuter par ce niveau car il permet de voir comment les
différentes représentations de l’interface finale se transforment dans les niveaux de fidélité inférieurs.
PROTOTYPAGE À UN NIVEAU DE FIDÉLITÉ ELEVÉE
A ce niveau, l’objectif est de maximiser la proximité entre l’interface prototypée et l’interface finale, à obtenir et
produire. Quand on parle de proximité, il s’agit de couvrir un maximum des aspects de l’interface (présentation, navigations globale et locale), mais aussi l’ordonnancement dans le temps et dans l’espace de l’utilisation
des fonctionnalités. Pour cela, il faudrait que le prototype puisse accepter des entrées au départ des dispositifs
d’interaction supportés (le plus souvent, le clavier et la
souris) afin de les traiter et de les refléter dans le test des
fonctionnalités. Certains prototypes peuvent débuter sur
un jeu de données restreint, non nécessairement connectées à une base de données, afin de simplifier le prototype. D’autres, au contraire, mettent en jeu des sousensembles utiles de bases de données.
35
Par conséquent, les éditeurs d’interface s’avèrent appropriés pour les prototypes présentationnels, surtout en horizontal, mais très peu pour les prototypes navigationnels, particulièrement en vertical. En effet, dès qu’il
s’agit d’un comportement à développer, il faut recourir à
la programmation, dont le coût n’est évidemment pas
souhaitable en phase de prototypage. Par analogie, le
prototypage diagonal est difficile à supporter.
En raison de ces limites, plusieurs personnes se tournent
vers des outils ne présentant pas les mêmes lacunes, tels
que les outils dits de façade [2,4,27]. Ces outils permettent de prototyper une interface en la construisant sans
faire appel à du codage, soit sans nécessairement devoir
développer la couche d’abstraction et/ou le noyau fonctionnel. Des outils hypermédia (comme HyperCard), des
outils de présentation assistée par ordinateur (comme
Microsoft PowerPoint, Aldus Persuasion), des outils auteur pour des applications multimédia (comme Macromedia Director) ont déjà été considérés bien des fois. Effectivement, il est possible de produire une interface à
niveau de fidélité élevée avec un minimum de navigation : le prototypage horizontal est mieux supporté et le
prototypage vertical ou diagonal, partiellement, les prototypes présentationnel et navigationnel sont mieux supportés dans cette approche. Hélas, l’effort de production
est perdu lorsqu’on passe à l’environnement de développement intégré prévu pour l’application complète.
Même si un tel outil génère automatiquement du code,
en tout ou en partie, ce code généré ne sera pas récupérable pour l’interface finale. Le développeur recommence le développement à zéro, avec une interface à
haute fidélité.
Figure 5: Interface de GrafiXML en mode de composition de la présentation (prototypage présentationnel).
Pour répondre à ces défis, nous avons développé GrafiXML (figure 5), un éditeur d’interface à niveau de fidélité élevée fondé sur le langage UsiXML. A l’instar
des éditeurs d’interface, GrafiXML permet de représenter une interface graphique en positionnant les objets interactifs souhaités, que ce soit des objets standards (p.
ex. un bouton radio, une liste de sélection) ou des objets
ajoutés (p. ex. la saisie d’une heure, un calendrier, un
conteneur). Au lieu de générer automatiquement ou
semi-automatiquement le code de l’interface ainsi représentée, GrafiXML produit automatiquement des spécifications fonctionnelles et opérationnelles rédigées en
UsiXML. Ces spécifications peuvent être dépendantes
ou indépendantes d’un contexte d’utilisation. Il est possible aussi de décliner différentes interfaces possibles
pour plusieurs contextes d’utilisation associés au même
projet. Ceci est particulièrement approprié lorsqu’il faut
développer une version multi-plate-forme d’une interface. La figure 5 présente l’outil en fidélité élevée au
moment de la spécification de la présentation. Etant
donné que cette interface peut être multi-plate-forme,
seule une représentation logique est affichée. Pour obtenir en temps réel une interface réelle, il suffit de demander la prévisualisation de l’interface (qui ne fonctionne
qu’en Java Swing). Grâce à un système d’export, GrafiXML peut actuellement générer automatiquement le
code de l’interface dans plusieurs langages cibles, tels
que Java, XHTML ou XUL (http:// www.mozilla.org/
projects/xul/). Par exemple, la figure 6 correspond à
l’interface générée en XHTML à partir de celle spécifiée
à la figure 5, mais sans feuille de style associée. Il est
possible d’adjoindre une feuille de style ultérieurement
afin de rendre la présentation adaptée au contexte d’utili-
36
sation en fonction du travail du designer graphique.
Cette opération est réalisée extérieurement à l’environnement de GrafiXML. Logiquement, GrafiXML peut
simultanément couvrir plusieurs langues pour une même
interface en spécifiant les ressources qui varient en fonction de l’utilisateur (p. ex. les ressources textuelles, les
images, les libellés, le texte de contenu). Dans ce cas, il
ne faut pas dessiner plusieurs interfaces – une seule suffit –, mais bien spécifier les variations de contenu propres à chacune des versions dans les langues différentes.
Une autre différence significative de GrafiXML par rapport à d’autres éditeurs concerne sa capacité à accueillir
des plug-ins destinés à couvrir des ensembles étendus de
fonctionnalités. Par exemple, des plug-ins existent pour
transformer une interface existante pour un PDA, pour
(dé)composer des interfaces entre elles, pour évaluer leur
qualité ergonomique en cours de conception, etc.
Figure 6: Interface finale résultant de GrafiXML.
PROTOTYPAGE À UN NIVEAU DE FIDÉLITÉ MODÉRÉE
Figure 7: Interface de GrafiXML en mode de spécification de
la navigation (prototypage navigationnel).
Enfin, pour supporter le prototypage navigationnel, GrafiXML offre un mode de spécification de la navigation
(figure 7). Dans ce dernier, chaque conteneur (cela peut
être une page web, une boîte de regroupement, une fenêtre, une boîte de dialogue) est affiché par sa miniature et
les miniatures du projet en cours sont rassemblées sur la
partie droite. Il est alors possible de tirer des flèches
d’un objet repris dans un conteneur vers un autre conteneur afin de spécifier des navigations globales élémentaires, du genre « fermer la première fenêtre et ouvrir la
suivante », « désactiver la première fenêtre, la réduire
sous forme iconique et activer la seconde fenêtre ». Le
siège de cette navigation globale (entre conteneurs) peut
résider dans le chef d’un objet interactif en particulier (p.
ex. un bouton de commande) soit dans le chef du conteneur lui-même, signifiant par là un comportement attaché à ce conteneur. Ici aussi, l’outil génère les spécifications détaillées en UsiXML V1.6.4 correspondant au
comportement souhaité, tant du point de vue de la présentation et de la navigation, que du contenu et du layout
(actuellement, quatre types de layout sont disponibles
pour la plupart des situations rencontrées). Actuellement,
GrafiXML ne supporte que la navigation globale. Nous
sommes en train de développer la partie relative à la spécification de la navigation locale. Ce qui est bien plus
complexe étant donné la variation et la complexité des
navigations possibles (p. ex. si je sélectionne telle langue
dans la liste de sélection, alors activer la valeur X dans le
radio bouton et activer le bouton de commande du
conteneur). Il est ardu de définir une notation graphique
permettant d’exprimer un ensemble significatif de ces
comportements. Aussi, nous espérons nous limiter à une
stylistique simple.
Remarquons enfin que GrafiXML ne dispose pas actuellement de la capacité à incorporer un objet interactif non
prédéfini dans UsiXML. Actuellement, il y a une trentaine d’objets, mais cet ensemble peut toujours évoluer
en importance. Par conséquent, GrafiXML souffre de la
même lacune que les éditeurs concernant les objets métier. Nous verrons cependant qu’une solution partielle à
ce problème a été instaurée dans le prototypage à un niveau de fidélité basse.
37
Tant qu’il s’agit de représenter graphiquement la présentation et/ou la navigation dans GrafiXML, le coût et le
temps de production semblent rester au moins égal à
ceux encourus dans un éditeur d’interface courant, si ce
n’est la capacité d’expression plus importante. Ceci mis
à part, les spécifications rédigées en UsiXML produites
par cet outil (ou par d’autres d’ailleurs) restent toujours
disponibles et permettent en principe de ne pas perdre
l’effort de prototypage lorsqu’il s’agit de passer à la
phase de développement. Si on peut récupérer les spécifications afin de produire du code (capacité générative),
un tel code peut être produit par diverses techniques de
génération (p. ex. par squelette, par analyse statique de
code, par « generative programming »).
Pour ce qui est des propriétés avancées de la présentation et de la navigation qui ne font pas l’objet d’une spécification graphique dans GrafiXML, le concepteur a la
possibilité de les spécifier dans des feuilles de propriétés
ou de laisser le système générer automatiquement des
valeurs par défaut pour lui (qui sont réglables et paramétrables). Cette approche convient lorsque l’on connaît
bien l’interface finale ou tout au moins que l’on est proche de son résultat. Si on n’est pas trop sûr de la mouture
finale de cette interface, on peut vite regretter que le coût
et le temps de création deviennent prohibitifs face au retour sur investissement. C’est pourquoi il peut s’avérer
judicieux de passer à un niveau de fidélité modérée.
Figure 8: Interface de VisiXML en mode de spécification de la
présentation (prototypage présentationnel).
Dans ce but, nous avons développé VisiXML (figure 8),
un éditeur d’interface à niveau de fidélité modérée permettant de se restreindre aux aspects visuels uniquement
sans passer par de la programmation ou du codage supplémentaire. VisiXML se présente sous la forme d’un
plug-in développé au sein de l’environnement Microsoft
Visio Pro agrémenté d’un stencil comportant les icônes
de dessin de tous les conteneurs et objets interactifs prévus dans une interface concrète spécifiable par UsiXML
(voir partie gauche de la figure 8). Dans VisiXML, le
concepteur se résume à dessiner l’interface souhaitée en
sélectionnant les conteneurs et objets interactifs individuels souhaités. La différence fondamentale entre GrafiXML (fidélité élevée) et VisiXML (fidélité modérée)
réside dans le fait qu’ici, il ne s’agit que d’un dessin vectoriel, en principe plus facilement modifiable, mais dont
la présentation est liée à celle d’une plate-forme logicielle cible. Au contraire, dans GrafiXML, l’édition n’est
pas liée à un environnement particulier.
Comme VisiXML est incorporé à l’environnement Microsoft Visio, on bénéficie de tout ce qui est supporté par
cet environnement : on peut dessiner n’importe quel autre objet vectoriel de base tel que de la décoration, du
texte, des figures, des dessins. Ceci permet enfin de spécifier des éléments de présentation qui ne seraient pas
définis en standard dans UsiXML, mais ces dessins sont
perdus dans l’export : quand le concepteur pense avoir
terminé sa conception, il peut cliquer sur une première
icône qui détermine automatiquement une hiérarchie des
objets présentés, puis sur une autre icône permettant de
générer automatiquement les spécifications en UsiXML.
Lorsqu’il s’agit d’autres éléments de dessin prévus par
Visio, mais pas par VisiXML, ces éléments sont sauvegardés dans le prototype de fidélité modérée, mais perdus dans les spécifications générées. Ceci engendre une
incohérence latente entre la représentation externe (l’interface dessinée) et la représentation conceptuelle (l’interface spécifiée en UsiXML). En contrepartie, la facilité
d’édition est plus importante, permettant de modifier
plus rapidement et moins en détails l’interface en cours
de prototypage. En effet, le prototypage est restreint aux
seules propriétés physiques et pour la plupart des propriétés physiques ayant un impact visuel, des valeurs par
défaut sont spécifiées afin de minimiser l’apport du
concepteur. Si néanmoins, le concepteur souhaite spécifier des paramètres jugés fort fins pour ce niveau (p. ex.
la police de caractères d’un texte, sa taille, sa couleur), il
peut le faire via la feuille de propriétés située en bas à
droite de la figure 8. Ces propriétés sont retenues dans la
génération des spécifications en UsiXML. Là où la capacité de VisiXML s’arrête, c’est lorsqu’il s’agit de passer à une autre plate-forme (ici, seul Microsoft Windows
XP est supporté) ou de prototyper à des fins d’exploration de conceptions alternatives. Certes, VisiXML comporte la faculté de dessin, mais sa représentation liée à
une plate-forme ne permet pas de faire penser qu’il
s’agit d’une interface en pleine évolution : son niveau
formel [14] de détails procure l’impression qu’il s’agit
déjà d’une interface presque finale, en tout cas dans les
yeux de l’utilisateur final.
En conclusion, VisiXML, même s’il est restreint à du
dessin vectoriel sur une plate-forme donnée, permet de
supporter le prototypage présentationnel et navigationnel
global. Le prototypage navigationnel local n’est aucunement supporté.
38
Dans la même veine, Berger [4] a imaginé un outil de
prototypage d’interface à un niveau de fidélité modérée
au sein de l’environnement Microsoft Excel avec la particularité que des comportements minimaux sur les données peuvent être effectués grâce au langage de macrocommande d’Excel.
PROTOTYPAGE À UN NIVEAU DE FIDÉLITÉ BASSE
Pour ne plus véhiculer l’impression d’une interface dont
la représentation est quasi finale, même si sa conception
l’est, il est judicieux de passer à un niveau de fidélité
basse. Lorsqu’on se situe à un niveau de fidélité basse, la
représentation de l’interface que l’on manipule doit être
la plus naturelle possible pour ne pas entraver le processus de création, de conception exploratoire. La représentation graphique de l’interface manipulée au sein de
l’éditeur est donc fondamentale pour donner
l’impression à l’utilisateur qu’il s’agit d’une interface en
cours de conception et non d’une interface finale. Le caractère informel [14] des spécifications est à préserver.
Figure 9: Interface de GUILayout en mode de spécification de
la présentation (prototypage présentationnel).
Au bas de l’échelle des représentations graphiques se
trouve GUILayout [4] dont l’interface est reproduite à la
figure 9. Nous y voyons que le concepteur peut définir
des zones contenant des types d’information différents :
texte, graphique, vidéo, formulaire. Ces zones informationnelles de base peuvent être récursivement composées
au sein de conteneurs de niveau immédiatement supérieur. Pour représenter l’interface finale de la figure 6, le
concepteur a ici dessiné un conteneur reprenant les zones de texte (destinées à contenir les informations de
guidage) et la zone de formulaire. La représentation graphique manipulée par GUILayout est celle du niveau de
fidélité le plus bas que nous connaissons aujourd’hui.
Pour donner un aperçu avant développement d’une interface, cette représentation suffit. Mais dès qu’il s’agit de
préciser le contenu des zones dessinées, l’utilité de
l’outil s’interrompt. Nous jugeons que cette représentation est de niveau trop bas pour être exploitée de manière
continue dans la suite du cycle de vie de développement.
A un stade moins bas que GUILayout résident les travaux de Meyer [21] avec son outil SketchaPad [22].
Meyer estime pour sa part que même une représentation
graphique de l’interface finale qui serait indépendante de
la plate-forme (p. ex. la partie gauche de la figure 10)
reste insuffisante et risque tout de même de donner
l’impression que la conception de l’interface est suffisamment aboutie, précise pour donner l’impression à
l’utilisateur final que l’interface est déjà obtenue, finalisée. C’est pourquoi il a développé un algorithme graphique permettant d’affecter automatiquement des contours
flous aux représentations graphiques des objets interactifs représentés (la partie droite de la figure 10).
Figure 11: Un environnement collaboratif de conception basé
sur plusieurs niveaux de fidélité concurrents (source :
http://www.isys.ucl.ac.be/bchi/members/jgo/Research.html)
Dans cet environnement, un ou plusieurs niveaux de fidélité peuvent se côtoyer : mono-fidélité si un seul des
trois niveaux est mobilisé, multi-fidélité si plus d’un niveau de fidélité est mobilisé. On dira que la multifidélité est mixte (comme dans [23]) lorsqu’une représentation mélange plusieurs niveaux de fidélité simultanément ou distribuée lorsque plusieurs représentations
ayant chacune une fidélité donnée se côtoient.
Figure 10: Deux représentations graphique d’une interface en
prototypage à niveau de fidélité basse [21].
A un niveau plus élevé qu’EtchaPad réside une famille
d’outils d’esquisse d’interfaces manipulant une représentation dessinée (« esquisse », en anglais, sketching) de
l’interface en cours de prototypage. Les représentants les
plus caractéristiques de cette famille sont dans l’ordre
alphabétique : Denim [14], EtchaPad [22], FreeForms
[24, 25], JavaSketchit [8] basé sur la bibliothèque de reconnaissance de forme CALI [13], SILK [16,17], SketchRead [1]. Ces outils partagent un mode de fonctionnement presque commun : au lieu de manipuler une représentation graphique de l‘interface, proche ou éloignée
comme dans [21], ils permettent au concepteur de dessiner librement l’interface en cours de conception comme
dans un outil de dessin graphique libre. Prototyper une
interface à un niveau de fidélité basse permet de découvrir autant de problèmes qu’à un niveau plus élevé.
Premièrement, un utilisateur final possède autant la capacité de dessiner une interface qu’un concepteur ou
qu’un développeur : dans une étude préliminaire [11],
nous n’avons pas décelé de différence statistiquement
significative entre la capacité d’un utilisateur final et
celle d’un concepteur d’interface pour dessiner une interface. Voici donc un moyen d’inclure vraiment
l’utilisateur final dans le prototypage puisqu’il peut luimême dessiner aussi bien que son concepteur. Il est intéressant d’étudier le binôme (concepteur, utilisateur final)
en situation collaborative de conception, mais ceci requiert une autre infrastructure qui est celle d’un environnement collaboratif de conception (figure 11).
39
Deuxièmement, ce n’est pas parce que le niveau de fidélité du prototypage s’exprime à un niveau inférieur à celui de la réalité (autrement dit, à un niveau de fidélité
moyenne ou basse) que la capacité du prototype à révéler ses avantages et ses inconvénients diminue. En particulier, il a été montré que le nombre de problèmes ergonomiques identifiés à l’aide d’une évaluation heuristique
n’est pas moindre avec une fidélité basse qu’avec une fidélité élevée.
Troisièmement, plusieurs principes fondamentaux président au prototypage à un niveau de fidélité basse :
x
x
x
Principe de naturalité : il faut que l’interface en
cours de dessin soit la plus naturelle possible et que
son dessin soit le plus naturel possible pour ne pas
limiter les capacités exploratrices de son utilisateur,
même si sa représentation n’est pas immédiatement
similaire à celle de l’interface finale.
Principe de non-obstrusion : comme corollaire au
principe de naturalité, il faut que le système de support à l’esquisse soit le moins obstrusif possible et
perturbe le moins possible le concepteur durant cette
phase de prototypage. La représentation en fidélité
basse ne doit donc en aucun cas introduire des tâches ou des actions qui soient étrangères à la nature
originale de l’activité de prototypage.
Principe de continuité : il faut que le système de
support à l’esquisse supporte continûment le dessin
quelle que soit la nature de l’élément sujet au prototypage (p. ex. un objet interactif, du texte, du dessin,
du contenu multimédia). L’utilisateur ne devrait pas
changer de mode de dessin si un élément de nature
différente doit être représenté.
x
Principe de récupération : l’effort obtenu suite à
l’esquisse ne doit pas être perdu pour le reste du cycle de vie de développement de l’application interactive. En principe, pour minimiser les coûts, l’effort consenti durant ce prototypage, même s’il est de
niveau de fidélité basse, devrait être perdu le moins
possible ou récupéré le plus possible dans la suite.
L’ensemble de ces outils adhère plus ou moins aux trois
premiers principes dans une certaine mesure, mais généralement pas au dernier. C’est pourquoi, nous avons développé SketchiXML [9,10,11], un éditeur d’interface à
niveau de fidélité basse fondé sur le langage UsiXML,
dont l’interface est reproduite à la figure 12.
SketchiXML tente donc d’adhérer aux quatre principes
fondamentaux introduits ci-avant de la façon suivante :
x
x
x
Figure 12: Interface de GUILayout en mode de spécification
de la présentation (prototypage présentationnel).
x
Dans cet outil, le concepteur peut spécifier ou non un
profil exprimant un contexte d’utilisation cible (c’est-àdire pour un utilisateur, une plate-forme et un environnement donné). Ensuite, il peut dessiner en dessin libre
l’interface en cours de prototypage. Bien que SketchiXML puisse être aussi utilisé sur un ordinateur normal équipé d’un clavier et d’une souris, il trouve sa
pleine utilisation sur des plateformes de type TabletPC
ou
Wacom
Cintiq
(cfr.
http://www.wacom.com/lcdtablets/index .cfm) qui offrent à son utilisateur la capacité d’écrire et de dessiner
directement sur l’écran, minimisant ainsi l’écart entre le
lieu d’interaction et sa représentation. A tout moment, le
concepteur peut demander au système de reconnaître le
contenu de l’esquisse pour générer aussi automatiquement que possible des spécifications de base d’une interface en UsiXML. Pour ce faire, chaque objet interactif
de base (p. ex. une liste de sélection) a été encodé dans
une grammaire graphique sous la forme de trois représentations préférentielles. Ces trois représentations sont
issues de tests utilisateur qui ont permis de déterminer
quelle sont les trois représentations graphiques préférées
des personnes (concepteurs et non-concepteurs) pour
chaque objet interactif. Pour les autres, seule l’esquisse
demeure et ne donne pas lieu à de la reconnaissance.
40
Principe de naturalité : le dessin et l’écriture du
concepteur forment les seules entrées possibles de
base pour réaliser une esquisse, l’objectif étant de
maximiser la métaphore de l’esquisse papier. Ces
deux formes d’expression sont largement reconnues
comme supportant largement un processus de conception, hautement créatif par nature [25,27].
Principe de non-obstrusion : si le concepteur le
préfère, aucun traitement de l’esquisse n’est effectué
en cours de conception. En particulier, aucune reconnaissance des objets interactifs et de l’écriture ne
sont opérées. Celles-ci ne sont déclenchées qu’à la
demande du concepteur afin de préserver le contrôle
explicite et de ne pas perturber le concepteur. La figure 12 montre que certaines formes ont été reconnues et enrichis par le nom de l’objet correspondant.
Principe de continuité : tant que le concepteur est
en train d’effectuer une esquisse, il reste dans ce
mode. Il ne doit pas passer d’un mode à l’autre pour
exprimer tantôt un objet interactif, tantôt du contenu, tantôt du texte, tantôt une commande de manipulation de l’esquisse (par exemple, effacer un fragment de l’esquisse, déplacer un fragment). A cette
fin, SketchiXML est équipé d’un moteur de reconnaissance de formes basé sur une grammaire graphique existant sous la forme de la bibliothèque
CALI [13], d’un moteur de reconnaissance de gestes
basé sur le traitement du signal émis par le stylet et
d’une bibliothèque de reconnaissance d’écriture.
Principe de récupération : contrairement à Denim
[14] qui ne supporte aucune reconnaissance et plus
loin que FreeForms [24] qui reconnaît moins
d’objets, SketchiXML reconnaît environ une trentaine d’objets interactifs, soit tous ceux qui sont définis dans l’interface concrète en UsiXML [19]. Il
peut donc exporter le résultat de l’esquisse dans un
fichier UsiXML qui est alors récupéré dans l’outil
GrafiXML (figures 5, 7) afin d’être affiné jusqu’au
niveau de détails demandé.
Au terme de ce parcours d’outils, la figure 1 peut être
revisitée à la lumière des avancées effectuées et permet
de couvrir à présent les trajectoires de la figure 13.
Prototype à fidélité
élevée : GrafiXML
Prototype à fidélité
modérée : VisiXML
Prototype à fidélité
basse : SketchiXML
Figure 13: Trajectoires possibles de prototypages en UsiXML.
PROTOTYPAGE AVEC D’AUTRES MODALITES
BIBLIOGRAPHIE
Les outils analysés jusqu’ici se basent évidemment tous
sur une même hypothèse de travail : l’interface de l’application à prototyper est de modalité graphique dominante. La question concernant l’adaptation de ces réflexions à d’autres modalités d’interaction ou à des types
particuliers d’applications interactive est une question en
cours de recherche. Par exemple, SUEDE [15] permet de
prototyper rapidement une application vocale en manipulant une abstraction de questions et réponses. La question du niveau de fidélité se pose ici en d’autres termes
et n’a pas encore fait l’objet de réflexion. De même,
MultiXML [29] permet de prototyper relativement rapidement une interface multimodale (graphique, vocale,
tactile ou combinant celles-ci) pour le web, mais la question du niveau de fidélité n’est pas encore résolue non
plus. Enfin, Topiary [18] exploite l’expérience acquise
dans le développement d’applications sensibles au
contexte pour proposer des représentations de natures
différentes utiles au prototypage de telles applications.
1.
Alvarado, Ch. and Randall, D. SketchREAD: A
Multi-domain Sketch Recognition Engine. In Proc.
of 17th Annual ACM Symposium on User Interface
Software and Technology UIST’2004 (Santa Fe, October 24-27, 2004), ACM Press, New York, 2004,
pp. 23-32.
2.
Baümer, D., Bischofberger, W.R., Lichter, H., and
Züllighoven, H. User Interface Prototyping Concepts, Tools, and Experience. In Proc. of 18th
Int. Conf. on Software Engineering ICSE’96 (Berlin,
March 25-29, 1996). IEEE Computer Society, Washington, 1996, pp. 532-541.
3.
Berger, N. The Excel Story. Interactions, Vol. 13,
No. 1, January-February 2006, pp. 14-17.
4.
Berkun, S. The Art of User Interface Prototyping,
November 2000, accessible at http://www.scottber
kun.com/essays/essay12.htm
5.
Blankenhorn, K. A UML Profile for GUI Layout,
Master thesis, University of Applied Sciences Furtwangen, Furtwangen, 2004.
6.
Boar, B.H. Application prototyping: a requirements
definition strategy for the 80s. John Wiley & Sons,
New York, 1984.
7.
Buxton, W. Sketching and Experience Design. In
Proc. of 10th IFIP TC 13 Int. Conf. on HumanComputer Interaction INTERACT’2005 (Rome, 1216 septembre 2005), M.-F. Costabile, F. Paternò
(eds.), Lecture Notes in Computer Science, Vol.
3585, Springer-Verlag, Berlin, 2005, p. 1.
8.
Caetano, A., Goulart, N., Fonseca, M. and Jorge, J.
JavaSketchIt: Issues in Sketching the Look of User
Interfaces. In Proc. of the 2002 AAAI Spring Symposium on Sketch Understanding (Palo Alto, March
2002), AAAI Press, Menlo Park, 2002, pp. 9-14.
9.
Coyette, A., Faulkner, S., Kolp, M., Limbourg, Q.,
and Vanderdonckt, J. SketchiXML: Towards a Multi-Agent Design Tool for Sketching User Interfaces
Based on UsiXML. In Proc. of 3rd Int. Work-shop
on Task Models and Diagrams for user interface
design TAMODIA’2004 (Prague, November 15-16,
2004), Ph. Palanque, P. Slavik, M. Winckler (eds.),
ACM Press, New York, 2004, pp. 75-82.
CONCLUSION
Au terme de ce parcours, nous avons montré qu’à l’aide
de la trilogie GrafiXML-VisiXML-SketchiXML, il est
possible de supporter différents niveaux de fidélité du
prototypage d’une interface graphique (élevée, modérée,
basse) et qu’il est possible de passer de n’importe quel
niveau de fidélité à un autre en principe. VisiXML ne
supporte que l’interface graphique pour une plate-forme
de type MS Windows au contraire des deux autres outils.
Les trajectoires de prototypage de la figure 13 sont couvertes. En comparant les différents outils de support au
prototypage, nous avons pu identifier quels sont ceux qui
conviennent pour un prototypage horizontal, vertical ou
diagonal, présentationnel, navigationnel global ou local.
L’expérience acquise jusqu’ici semble révéler que le
prototypage à un niveau de fidélité basse est promis à un
avenir certain tant la naturalité est importante : le
concepteur, l’utilisateur final lui-même ou bien les deux
ensembles peuvent pour la première fois collaborer directement au prototype en cours de conception. Gageons
que ces nouvelles formes de prototypage procureront à
l’utilisateur final un réel sentiment d’implication.
REMERCIEMENTS
Les auteurs remercient particulièrement le projet ReQuest (Rapid prototyping of e-commerce applications,
Programme «WIST» Wallonie Information Science &
Technology, Convention n°315592), financé par la Région Wallonne (Belgique), ainsi que le réseau d’excellence SIMILAR (The European research taskforce creating human-machine interfaces SIMILAR to human-human communication, http://www.similar.cc, FP6-IST12003-507609), financé dans le cadre du 6ième Programme
Cadre de la Commission Européenne. Ensuite, nous remercions WACOM Research Europe. Nous remercions
aussi chaleureusement A. Caetano, N. Goulart, M. Fonseca, et J.A. Jorge (INESC-ID, Portugal) pour nous avoir
permis d’utiliser leur bibliothèque CALI.
41
10. Coyette, A., Vanderdonckt, J., Faulkner, S., and
Kolp, M. Generating Abstract User Interfaces from
an Informal Design. In Proc. of 17th Int. Conf. on
Software Engineering and Knowledge Engineering
SEKE’2005 (Taipei, July 14-16, 2005), IJSEKE
Press, Taiwan, 2005.
11. Coyette, A. and Vanderdonckt, J. A Sketching Tool
for Designing Anyuser, Anyplatform, Anywhere
User Interfaces. In Proc. of 10th IFIP TC 13 Int.
Conf. on Human-Computer Interaction INTERACT’2005 (Rome, 12-16 septembre 2005), M.-F.
Costabile, F. Paternò (eds.), Lecture Notes in Computer Science, Vol. 3585, Springer-Verlag, Berlin,
2005, pp. 550-564.
12. Engelberg, D. and Seffah, A. A Framework for Rapid Mid-Fidelity Prototyping of Web Sites. In Proc.
of the IFIP 17th World Computer Congress - TC13
Stream on Usability: Gaining a Competitive Edge
WC’2002 (August 25-29, 2002), Kluwer Academic
Press, Dordrecht, 2002, pp. 203-215.
13. Fonseca, M.J., Pimentel, C. and Jorge, J.A. CALI:
An Online Scribble Recognizer for Calligraphic Interfaces. In Proc. of the 2002 AAAI Spring Symposium on Sketch Understanding (Palo Alto, March
2002), AAAI Press, Menlo Park, 2002, pp. 51-58.
14. Hong, J.I., Li, F.C., Lin, J., and Landay, J.A. EndUser Perceptions of Formal and Informal Representations of Web Sites. In Extended Abstracts of Proc.
of ACM Conf. on Human Factors in Computing Systems CHI’2001 (Seattle, March 31-April 5, 2001).
ACM Press, New York, 2001, pp. 385-386.
15. Klemmer, S.R., Sinha, A.K., Chen, J., Landay, J.A.,
Aboobaker, N., and Wang, A. Suede: a Wizard of
Oz Prototyping Tool for Speech User Interfaces. In
Proc. of the 13th Annual ACM Symposium on User
Interface Software and Technology UIST’2000 (San
Diego, November 6-8, 2000), ACM Press, new
York, 2000, pp. 1-10.
16. Landay, J.A. and Myers B.A. Interactive Sketching
for the Early Stages of User Interface Design. In
Proc. of ACM Conf. on Human Factors in Computing Systems CHI’95 (Denver, May 7-11, 1995),
ACM Press, New York, 1995, pp. 43-50.
17. Landay, J. and Myers, B.A. Sketching Interfaces:
Toward More Human Interface Design. IEEE Computer, Vol. 34, No. 3, March 2001, pp. 56-64.
18. Li, Y., Hong, J.I., and Landay, J.A. Topiary: a Tool
for Prototyping Location-enhanced Applications. In
Proc. of the 17th Annual ACM Symposium on User
Interface Software and Technology UIST’2004
(Santa Fe, October 24-27, 2004), ACM Press, New
York, 2004, pp. 217-226.
19. Limbourg, Q., Vanderdonckt, J., Michotte, B.,
Bouillon, L., and Lopez, V. UsiXML: a Language
Supporting Multi-Path Development of User Interfaces. In Proc. of 9th IFIP Working Conf. on Engineering for HCI jointly with 11th Int. Workshop on
Design, Specification, and Verification of Interactive Systems EHCI-DSVIS’2004 (Hamburg, July 1113, 2004). Lecture Notes in Computer Science, Vol.
3425, Springer-Verlag, Berlin, 2005, pp. 200-220.
20. Limbourg, Q. and Vanderdonckt, J. UsiXML: A
User Interface Description Language Supporting
Multiple Levels of Independence. In Matera, M.,
Comai, S. (Eds.), Engineering Advanced Web Ap-
42
plications, Rinton Press, Paramus, 2004, pp. 325338.
21. Meyer, J. Creating Informal Looking Interfaces,
2005, accessible at http://www.cybergrain.com/tech/
pubs/lines_technote.html
22. Meyer, J. EtchaPad – Disposable Sketch Based Interfaces. In Proc. of ACM Conf. on Human Factors
in Computing Systems CHI’96 (Vancouver, April
13-18, 1996), Conference Companion, ACM Press,
New York, 1996, pp. 195-198.
23. Petrie, J.N. and Schneider, K.A. Mixed-Fidelity
Prototyping of User Interfaces. In Proc. of 13th Int.
Workshop on Design, Specification, and Verification of Interactive Systems DSV-IS’2006 (Dublin,
26-28 July 2006), G. Doherty and A. Blandford
(eds.), Lecture Notes in Computer Science, Springer-Verlag, Berlin, 2006.
24. Plimmer, B.E. and Apperley, M. Software for Students to Sketch Interface Designs. In Proc. of 9th
IFIP TC 13 Int. Conf. on Human-Computer Interaction INTERACT’2003 (Zurich, 1-5 September 2003),
M. Rauterberg, M. Menozzi, J. Wesson (eds.), IOS
Press, Amsterdam, 2003, pp. 73-80.
25. Plimmer B., and Apperley M. Interacting with Sketched Interface Designs: An Evaluation Study. In
Proc. of ACM Conf. on Human Factors in Computing Systems CHI’2004 (Vienna, April 2004), ACM
Press, New York, 2004, pp. 1337-1340.
26. Rudd, J., Stern, K., and Isensee, S. Low vs. HighFidelity Prototyping Debate. Interactions, Vol. 3,
No. 1, January 1996, pp. 76-85.
27. Snyder, C. Paper Prototyping: The Fast and Easy
Way to Design and Refine User Interfaces. Series in
Interactive Technologies, Morgan Kaufmann, 2002.
28. Souchon, N. and Vanderdonckt, J., A Review of
XML-Compliant User Interface Description Languages. In Proc. of 10th Int. Conf. on Design, Specification, and Verification of Interactive Systems
DSV-IS’2003 (Madeira, June 4-6, 2003), J. Jorge,
N.J. Nunes, J. Cunha (eds.), Lecture Notes in Computer Science, Vol. 2844, Springer-Verlag, Berlin,
2003, pp. 377-391.
29. Stanciulescu, A. and Vanderdonckt, J. Design Options for Multimodal Web Applications. In Proc. of
6th Int. Conf. on Computer-Aided Design of User Interfaces CADUI’2006 (Bucharest, 6-8 June 2006),
Springer-Verlag, Berlin, 2006, pp. 41-56.
30. Vanderdonckt, J., A MDA-Compliant Environment
for Developing User Interfaces of Information Systems. In Proc. of 17th Conf. on Advanced Information Systems Engineering CAiSE'05 (Porto, 13-17
juin 2005), O. Pastor & J. Falcão e Cunha (eds.),
Lecture Notes in Computer Science, Vol. 3520,
Springer-Verlag, Berlin, 2005, pp. 16-31.
ARTICLES LONGS DE RECHERCHE
*******
Evaluation ergonomique d’un prototype de réalité augmentée par des tests utilisateurs : apports et difficultés
Margarita Anastassova 1,2, Christine Mégard
Jean-Marie Burkhardt, Juliette Breda
1
2
Commissariat à l’Energie Atomique
Laboratoire d’Intégration des Systèmes et des
Technologies (LIST)
18, route du Panorama
92265 Fontenay-aux-Roses Cedex
[email protected]
[email protected]
Unversité René Descartes - Paris 5
Unité d’Ergonomie
Laboratoire d’Ergonomie Informatique (LEI)
45, rue des Saints-Pères
75270 Paris Cedex 06
[email protected]
[email protected]
RESUME
tion of such tests of emerging technologies is quite difficult.
Cette recherche concerne les apports et les difficultés de
l’évaluation d’un prototype de Réalité Augmentée (RA).
L’objectif est d’évaluer la qualité ergonomique du dispositif et de voir certains avantages et limites des tests
utilisateurs appliqués à une technologie émergente.
D’abord, nous présentons les méthodes utilisées pour
l’évaluation ergonomique de la RA et les principales
conclusions sur l’utilité et l’utilisabilité des systèmes
existants. Ensuite, nous exposons la méthodologie de
l’étude. Elle repose sur une comparaison de 2 groupes
expérimentaux : le premier utilise le prototype de RA et
le deuxième utilise une procédure en papier pour la réalisation d’une même tâche de maintenance. Les résultats montrent que les sujets réalisent plus rapidement et
plus facilement la tâche en utilisant la procédure en papier. D’un point de vue méthodologique, on constate que
les tests utilisateurs sont très utiles pour l’évaluation de
la compatibilité du prototype avec la tâche, mais leur
mise en œuvre rencontre plusieurs difficultés.
KEYWORDS : Augmented reality, maintenance, usability evaluation, user testing.
INTRODUCTION
La Réalité Augmentée (RA) est un ensemble de technologies qui induisent de nouvelles formes d’interaction
homme - machine. Ces technologies sont basées sur
l’association sémantique, spatiale et temporelle d’objets
réels et virtuels (notion de recalage). Fixes ou mobiles,
les systèmes de RA sont construits sur la base d’une architecture comprenant généralement quatre composants
principaux: une caméra filmant la scène visionnée par
l’utilisateur ; un ordinateur générant les objets virtuels ;
des dispositifs d’entrée et de présentation d’information ;
des capteurs de position [2]. L’idée d’augmentation renvoie
ainsi
à
l’enrichissement
supposé
de
l’information véhiculée par les objets virtuels, par référence aux seules informations accessibles à l’utilisateur
dans l’environnement immédiat du monde réel.
MOTS CLES : Evaluation ergonomique, maintenance,
réalité augmentée, tests utilisateurs.
L’étude présentée dans cet article a une double visée : 1)
évaluer l’utilité et l’utilisabilité d’un prototype de RA
destiné à l’assistance à la maintenance de trains et 2) discuter des difficultés d’utilisation des méthodes classiques d’évaluation tels des tests utilisateurs. Dans cette
étude, l’utilité est considérée comme un avantage significatif pour l’utilisateur dans la tâche de maintenance
(ex. : en termes d’efficacité et de rapidité), tandis que
l’utilisabilité correspond à un nombre de critères tels que
facilité d’apprentissage, utilisation sans erreurs, etc. [6].
Dans la première partie de l’article, nous présentons
brièvement les méthodes utilisées pour la conception et
l’évaluation ergonomique des systèmes de RA ainsi que
les principales conclusions sur leur utilité et utilisabilité.
Ensuite sont exposés la méthodologie utilisée et les principaux résultats de notre évaluation. Enfin, nous discutons ces résultats et soulignons certaines limites de la recherche.
ABSTRACT
This study concerns the difficulties and the benefits from
a user evaluation of an Augmented Reality (AR) prototype. The purpose is to assess the utility and the usability
of the application and to see some of the advantages and
the limits of user testing of emerging technologies. We
present the methodology used for the evaluation of AR
technologies and the major conclusions on their utility
and usability. Then, we expose the methodology of our
study, which compares the performance of two groups
on the same maintenance task. One of the groups uses
paper instructions, and the other – the AR prototype for
guiding the assembly. The results show that the assembly task is done faster and easier using the paper instructions. From a methodological point of view, we conclude
that user testing is very useful for evaluating the compatibility of the prototype with the task, but the realiza-
45
CONCEPTION ET EVALUATION ERGONOMIQUE DE
SYSTEMES DE RA
Les tests utilisateurs sont la méthode la plus souvent employée afin d’évaluer la qualité ergonomique des prototypes de RA (ex. [17]). Réalisés en laboratoire d’une
manière analytique, en utilisant de petits échantillons, ils
comparent différents dispositifs d’interaction afin de déterminer le plus pertinent pour une tâche donnée. Les tâches assignées sont souvent courtes et artificielles, de
l’ordre de l’interaction élémentaire plutôt que de
l’activité finalisée dans des situations visant à sauvegarder une certaine écologie (pour plus de détails voir [1]).
Les indices comportementaux relevés sont principalement le temps de réalisation de la tâche et le nombre
d’erreurs. Les évaluations sur le terrain, assez rares, sont
conduites par des questionnaires et des entretiens, souvent informels (ex. : [16]). Dans ce cas, l’intérêt porte
principalement sur la satisfaction des utilisateurs.
Actuellement, les dispositifs de RA font surtout l’objet
de recherches technologiques. Par conséquent, il y a très
peu de retours d’expérience concernant des utilisateurs
réels ainsi que peu de réflexions sur des méthodes
d’évaluation adaptées aux technologies émergentes
(mais voir [4]). De surcroît, certaines des rares évaluations publiées comportent des biais méthodologiques,
voire restent informelles et peu rigoureuses [1].
Connaissances actuelles et orientation des études
empiriques
Les principes fondés empiriquement pour la conception
ergonomique des dispositifs de RA sont encore peu
nombreux et très généraux. On trouve par exemple que :
x
x
x
les visiocasques posent de nombreux problèmes de
charge physique et induisent une certaine surcharge
mentale [3]. C’est pourquoi plusieurs auteurs préconisent un port de visiocasques d’une durée relativement limitée ainsi qu’une distribution équitable du
poids des dispositifs entre les différentes parties du
corps en fonction de l’activité de l’opérateur ;
les interfaces tactiles sont difficilement associables à
une activité manuelle [3] ;
la commande vocale utilisée en entrée n’est pas
adaptée aux environnements bruyants ; selon la précision de la reconnaissance vocale, la vitesse de réalisation des tâches peut être fortement affectée, etc.
Des auteurs ont également recours à des évaluations expertes bien que l’utilisation de cette méthode soit beaucoup moins documentée dans la littérature sur
l’ergonomie de la RA. Actuellement, l’évaluation experte est réalisée sur des maquettes d’écrans, généralement très en amont de la conception des dispositifs. Le
principal avantage de l’utilisation de cette méthode dans
le cadre d’un projet serait le bon rapport coût / résultats
utilisables par la conception [8].
Utilisabilité et compatibilité avec les tâches
Les recherches actuelles montrent que les systèmes de
RA, basés sur l’utilisation de visiocasques, n’améliorent
pas, voire détériorent les performances des sujets par
rapport à un système utilisant un écran classique lorsqu’il s’agit de tâches simples telles que la détection,
l’identification et le suivi de cibles, la réaction à des
alarmes [15, 5]. Ces résultats pourraient être expliqués
par nombre de limitations technologiques des casques
(ex. : défauts de présentation de la profondeur). En revanche, les visiocasques et le recalage se révèleraient
avantageux quand il s’agit de donner un retour rapide
sur l’avancement d’une tâche élémentaire réalisée en parallèle avec d’autres tâches, par exemple sur un poste de
travail multi-écrans.
Une explication possible de la généralité des principes
mentionnés ci-dessus est le fait que le recours à des études du contexte spécifique d’utilisation en même temps
qu’une analyse fine de la tâche à réaliser restent rares.
Pourtant, la multiplication de telles analyses fines et
« spécifiques » est également primordiale pour assurer le
développement de technologies mieux adaptées. Cela est
probablement d’autant plus vrai que l’on se situe hors du
domaine classique de la micro-informatique et des interfaces écran-clavier-souris. Les aspects d’ambiances physiques sont, par exemple, importants du fait de la multimodalité des dispositifs d’interaction, de la mobilité et
de l’exploitation des objets physiques dans
l’environnement. Ainsi aujourd’hui, les recherches réalisées avec des utilisateurs devraient avoir non seulement
la fonction de faire avancer la conception de tel ou tel
prototype particulier, mais également d’établir les fondations empiriques pour des principes et des méthodes
d’évaluation spécifiques à la RA.
Le suivi de procédures est l’un des domaines
d’application privilégiés de la RA. Les chercheurs arrivent à des conclusions controversées dans les évaluations empiriques qui ont été réalisées. Dans certains cas,
on montre que des sujets réalisent une tâche de montage
/ démontage plus rapidement et avec moins d’erreurs
s’ils sont guidés par un système de RA comparativement
à un guidage par des manuels papiers [17]. Au contraire,
d’autres études (ex. : [7]) n’arrivent pas à montrer la supériorité du guidage à l’aide de la RA par rapport au guidage en utilisant des supports en papier. Il paraît difficile
de conclure sur l’effet lié à l’usage d’un système de RA
vu que, souvent, une même information peut être présentée différemment en fonction du support et la littérature
donne rarement des précisions sur ce point.
Les évaluations ergonomiques menées aujourd’hui
Bien que l’utilité et les usages des prototypes de RA
soient des questions cruciales pour l’ergonomie, dans de
nombreux cas, les problèmes relatifs à l’utilisabilité des
techniques d’interaction sont les seuls discutés dans la
littérature.
46
Un résultat intéressant des études empiriques concerne
l’adaptabilité des aides au suivi de procédures en RA à
différents contextes de travail et différents modes opératoires. Plusieurs recherches montrent que l’utilisation
d’un système de RA réduit la variabilité inter- et intraindividuelle des modes opératoires dans la mesure où
l’ordonnancement des tâches est contraint par le système
[3]. Nous pouvons nous interroger sur les problèmes et
les gains que peut poser une réduction de la variabilité
des modes opératoires. Ainsi, l’utilisation d’un système
de RA pourrait être avantageux pour des tâches demandant une application stricte de procédures. En revanche,
ce phénomène peut être une contrainte dans des contextes de travail hautement dynamiques.
des participants aux tests ; (2) le prototype est techniquement et fonctionnellement immature et ce fait engendre un risque de rejet de la technologie. Par conséquent,
les tests sont réalisés avec 10 sujets (6H, 4F), tous ingénieurs en informatique et en électronique dans un des laboratoires de recherche participant au projet. Ils sont répartis aléatoirement en deux groupes de 5 sujets en fonction du guidage utilisé : le premier groupe ne dispose
que d’instructions en papier, tandis que le deuxième utilise le prototype de RA afin de réaliser la tâche assignée.
L’âge des sujets varie entre 26 ans et 46 ans (M=30,
ET=6). Neuf sujets sont Français et un sujet est Allemand francophone. Ils ont une connaissance des technologies de RA par leur culture scientifique, mais ne sont
que partiellement familiarisés avec leur utilisation. Tous
les sujets ont un niveau d’études élevé (Bac + 5 ou plus)
et une bonne connaissance de la langue anglaise. Aucun
ne présente de problèmes visuels particuliers.
UNE ETUDE POUR EVALUER UN SYSTEME DE RA
L’étude présentée ici s’appuie sur deux méthodes
d’évaluation. La première est le test avec des utilisateurs,
ensuite complété par des entretiens semi-dirigés. Une
partie des résultats et nos premières conclusions sont exposées dans cet article. Deuxièmement, une étude par
inspection est menée au moyen de critères ergonomiques
initialement
développés
pour
l’évaluation
d’environnements virtuels. Les données obtenues grâce à
la deuxième technique sont en cours d’analyse.
Le nombre relativement faible de sujets pourrait être expliqué par les contraintes inhérentes au projet, exposées
plus haut, et par la nécessité de faire une évaluation assez rapide de la technologie. D’un point de vue méthodologique, cette limite de l’expérimentation a l’avantage
de remettre en question la validité théorique et pratique
du nombre « magique » de 5 sujets suffisants pour cerner 85% des problèmes d’utilisabilité d’un produit [12].
Objectif de l’étude et questions de recherche
Notre étude ergonomique vise à évaluer d’une manière
empirique et rapide l’utilité et l’utilisabilité d’un prototype de RA. Ce prototype devrait assister des techniciens
de maintenance de trains novices dans la réalisation de
leurs tâches en affichant et en annotant certaines parties
cachées et visibles d’un transformateur électrique réel.
Dans ce cas, l’avantage principal de la RA par rapport à
une procédure en papier serait la réduction du nombre
d’erreurs et du temps de recherche et de traitement de
l’information grâce à la présentation de consignes
contextualisées en temps réel, au moment et à l’endroit
appropriés.
Tâche à réaliser. La tâche à réaliser est une tâche de
démontage de la partie latérale et du câblage d’un transformateur électrique présenté par une maquette à taille
réelle. La tâche et la maquette physique sont identiques
dans la condition « procédure papier » et dans la condition « procédure en RA ». La tâche comporte 9 étapes,
une étape consistant en une ou plusieurs actions élémentaires (ex. : vissage, desserrage, etc.). Notre analyse se
concentre sur les 8 premières étapes car la maquette physique disponible pour l’expérimentation ne permet pas la
réalisation de l’étape 9. En effet à cette étape, il s’agit de
retirer un câble qui n’est pas présent sur la maquette.
Les résultats de l’évaluation doivent servir à la reconception du prototype développé dans le cadre d’une
coopération entre un partenaire industriel et plusieurs laboratoires de recherche.
Matériel. La consigne pour la tâche est présentée (en
format papier et en format électronique) en anglais puisque les futurs utilisateurs sont anglophones. La procédure papier est imprimée sur deux feuilles A4 au recto.
D’un point de vue recherche, l’étude est conduite également afin de réfléchir sur les apports et les limites des
tests utilisateurs classiques dans le cadre d’évaluations
d’outils issus des technologies émergentes. Une autre
question de recherche porte sur l’usage et l’utilité de la
RA pour le guidage dans l’exécution de procédures.
En RA, l’utilisateur a accès à la procédure par
l’intermédiaire d’une interface Windows, Icons, Menus,
Pointing (WIMP). Dans une fenêtre centrale sont affichés l’image du transformateur, un modèle numérique en
3 dimensions (3D) de celui-ci ainsi que d’autres entités
virtuelles (ex. : texte, flèches dynamiques et statiques).
Dans une deuxième fenêtre sous la fenêtre principale apparaît le texte de la procédure à suivre (cf. Fig. 1). Des
boutons de contrôle (« Mise en marche / Arrêt de la vidéo», « Arrêt », « Précèdent », « Suivant » concernant le
Méthode
Sujets. A l’étape actuelle, la participation des futurs uti-
lisateurs « réels » ou représentatifs (c’est-à-dire des
techniciens spécialisés dans la maintenance de trains) est
peu envisageable pour deux raisons : (1) le partenaire
industriel n’exprime pas une volonté claire de fournir
47
contrôle du défilement du texte, et « Effacer ») apparaissent au dessus et à droite de la fenêtre principale.
Après une courte présentation de la tâche à réaliser,
l’utilisateur est laissé libre afin de se familiariser avec le
matériel. Ensuite, l’expérimentateur précise au sujet
qu’il doit effectuer sur le transformateur une partie des
opérations décrites dans la procédure sans contrainte de
temps particulière. Il est demandé au sujet
d’accompagner l’exécution de la tâche par une explication à haute voix. Les sujets sont libres de poser tout
type de questions relatives au vocabulaire et à
l’utilisation du système de RA.
Les sujets qui utilisent le guidage en RA passent ensuite
un entretien portant sur l’utilité du prototype pour la tâche de maintenance, sur les caractéristiques de
l’interface (animations, recalage, etc.) et sur
d’éventuelles propositions d’amélioration.
Figure 1: Ecran principal du logiciel de RA
Le dispositif d’entrée d’information utilisé est un stylet.
A l’aide du stylet, l’utilisateur valide une étape de la procédure afin de passer à la suivante et fait apparaître des
indications textuelles sur les noms des pièces. Les animations se déclanchent automatiquement avec le passage
d’une étape de la procédure à l’autre.
Données recueillies
Les données recueillies sont issues, d’une part, des enregistrements vidéo des passations individuelles et, d’autre
part, des entretiens post-expérimentaux retranscrits verbatim et analysés. Afin de ne pas gêner le sujet et à
cause de contraintes matérielles, l’écran du dispositif de
RA et les actions de l’utilisateur sur l’interface n’ont pas
pu être filmés. De plus, les fichiers logs ne sont pas exploitables à des fins d’évaluation ergonomique, car une
telle utilisation n’a pas été prévue par les concepteurs du
système.
Système de RA testé. L’architecture matérielle du système de RA utilisé est la suivante : une caméra haute définition fixée sur un ordinateur portable (Tablette PC)
filme une maquette du transformateur électrique à taille
réelle. La scène filmée est affichée en temps réel sur
l’écran de l’ordinateur portable et enrichie par des éléments virtuels. En raison de la puissance limitée des Tablette PC actuels et des ressources nécessitées par les algorithmes de traitement, une délocalisation des calculs
vers un PC distant est nécessaire. Par conséquent, les
différents éléments sont reliés par un certain nombre de
câbles. Au total, le dispositif porté par l’utilisateur pèse
2 kg. Le sujet passe une sangle reliée à l’ordinateur portable derrière son cou afin de maintenir le prototype (cf.
Fig. 2).
Méthodes d’analyse. L’analyse des enregistrements vidéo concerne des indicateurs de performance tels que le
nombre d’étapes réalisées ; le nombre de déviations de la
procédure prescrite ; le temps total de réalisation de chaque étape. Ce dernier se décompose 1) en temps de compréhension de la procédure, mesuré à partir du moment
où le sujet prend connaissance de la consigne jusqu’au
moment où il débute la réalisation manuelle de la tâche,
et 2) en temps de manipulation de la maquette réelle.
Les stratégies des sujets sont analysées à partir de la fréquence des allers-retours du regard entre la maquette et
le dispositif d’affichage de la procédure ; le type de
questions posées (ex. : concernant le prototype de RA et
la maquette physique, des demandes d’approbation et de
traduction) ; les déplacements et les postures adoptées
pendant la réalisation de la tâche.
Enfin, l’analyse des entretiens est une analyse du contenu thématique. L’unité d’analyse est définie par l’idée
principale exprimée et délimitée par le changement
d’idée. Trois grands thèmes se dégagent: les difficultés
rencontrées par les sujets, les avantages du prototype
évoqués et les améliorations suggérées.
Le choix a été fait de faire reposer l’analyse sur des indicateurs statistiques uniquement descriptifs, dans la mesure où le recours à l’inférence (F de Snedecor, t de Student ou encore Chi2) n’est aucunement justifié par les
conditions de l’étude expérimentale. D’abord dans le ca-
Figure 2: Le dispositif de RA porté par un sujet
Procédure. Les passations individuelles sont encadrées
par deux ergonomes. Le premier filme l’utilisateur, tandis que le deuxième donne - si nécessaire et à la demande - des explications sur le vocabulaire et le fonctionnement du prototype.
48
dre de ce projet, une généralisation des résultats n’était
pas recherchée. Ensuite, l’échantillon n’était ni tiré au
hasard ni suivait une distribution normale.
Stratégies et comportements observés
Une stratégie de recherche de l’information plus longue avec la procédure papier. La stratégie de recher-
Résultats
Performance dans la réalisation de la tâche
Une supériorité de la condition « papier » en termes
de nombre d’étapes réalisées. L’analyse des enregis-
che et de traitement de l’information, estimée à partir de
la fréquence moyenne des allers-retours du regard entre
la procédure et la maquette, est légèrement plus longue
dans la condition « papier » (Moypap= 1.87, Etypap= 0.95
vs. Moyra=1.77, Etyra= 1.43).
trements vidéo montre qu’en moyenne, les sujets du
groupe utilisant la procédure en papier (PAP) réalisent 7
étapes sur les 8 possibles (Ety=1), tandis que les sujets
du groupe utilisant la réalité augmentée (RA) réalisent
en moyenne 6.4 étapes (Ety=1.34).
Un nombre plus élevé de questions posées dans la
condition « RA ». Le nombre de questions posées en
moyenne à chaque étape est plus élevé en RA que dans
le groupe PAP (Moypap=5.7, Etypap=2 vs. Moyra=9.3,
Etyra=8). Quand les sujets travaillent avec une procédure
papier, ils posent plus de questions relatives à la maquette (Taux De Liaison (TDL)=0.22) ainsi que de questions de traduction / localisation (TDL=0.19). Quand les
sujets travaillent en RA, leurs questions portent majoritairement sur l’utilisation du dispositif (TDL=0.60).
Quelque soit la condition, les sujets posent à peu près le
même nombre questions d’approbation (TDL=0.03).
Pour les analyses qui suivent, nous avons retenu uniquement les étapes réalisées par au moins 4 sujets dans
chaque condition. En effet, les étapes 5 et 7 ont été abordées par très peu de sujets, puisque les consignes respectives étaient ambiguës et, par conséquent, interprétées
différemment par les différents participants.
Un temps total de réalisation plus court dans la
condition « papier ». Globalement, les sujets du groupe
Moins de changements de posture dans la condition
« RA ». Les sujets en condition « RA » passent en
PAP réalisent chaque étape plus rapidement que les sujets du groupe RA (Moy tpap=101s, Etypap=40s vs. Moy
tra=121s, Etyra=83s). Il faut, en moyenne, 20 % de temps
en plus avec la RA pour réaliser l’ensemble d’une étape
par comparaison avec la procédure papier. Une analyse
détaillée de l’activité du sujet à chaque étape montre
cette même supériorité en termes de vitesse de lecture et
de compréhension de la procédure (Moy tpap=53s, Etypap= 34.6s vs. Moy tra=80s, Etyra=72s.), la différence
étant encore plus importante (i.e. 50% de temps en plus).
moyenne 56% de leur temps debout (Ety=15%), 42% de
leur temps accroupi (Ety=16%) et 2% debout penché en
avant (Ety=2%) de leur côté, les sujets en condition
« papier » passent en moyenne 25% de leur temps debout (Ety=12%), 71% de leur temps accroupi (Ety=
13%) et 4% debout penché en avant (Ety=3%). De plus
en moyenne, les sujets en condition « papier » changent
plus souvent de posture (Moypap=2.02, Etypap=1.14) que
les sujets en condition « RA » (Moyra=1.67, Etyra=0.96).
Les données des entretiens
Des difficultés avec le prototype de RA liées principalement aux problèmes de recalage. Dans les entretiens
Mais un temps de manipulation de la maquette plus
important dans la condition « papier ». Le temps de
manipulation de la maquette réelle est plus élevé de 16%
quand les sujets utilisent la procédure papier (Moy
tpap=51s, Etypap=24.9s) que quand ils utilisent le prototype de RA (Moy tra=44s, Etyra=36s).
post-expérimentaux, les sujets évoquent essentiellement
des problèmes relatifs au recalage (33% des difficultés
soulignées par les sujets). En effet, 4 sujets sur les 5 interrogés affirment ne pas avoir perçu et/ou utilisé le recalage.
Enfin d’une manière générale et dans les deux conditions, le temps moyen de compréhension de la consigne
est plus long que le temps de manipulation effective de
la maquette réelle. Dans la condition « papier », cette
différence est légère (Moy tpap= 53s, Etypap= 34.6s vs.
Moy tpap=51s, Etypap=24.9s). Dans la condition « RA »,
cette différence est plus prononcée (Moy tra=80s, Etyra=72s vs. Moy tra=44s, Etyra=36s).
La conception des animations semble également avoir
été problématique (25% des difficultés évoquées). Tous
les sujets mentionnent cet aspect au cours des entretiens.
Les animations sont jugées trop rapides et pas assez claires d’un point de vue sémantique.
Trois sujets évoquent des problèmes relatifs au prototype
de RA : le dispositif est jugé encombrant, peu utilisable
et peu utile pour la tâche de maintenance. D’autres difficultés exposées moins souvent concernent la clarté de la
procédure, l’éclairement du local de l’expérimentation et
l’utilisabilité de l’interface du logiciel de RA (ex.
l’absence d’aide).
Une efficacité comparable des deux guidages en
termes de nombre de déviations de la procédure. Au
cours de l’expérimentation, le groupe PAP commet autant d’erreurs que le groupe RA. En revanche, la distribution des erreurs est différente dans les deux groupes.
Ainsi, les sujets du groupe RA dévient de la procédure
uniquement à l’étape 3, tandis qu’aucune erreur n’est
constatée à cette étape dans la condition « papier ».
49
Peu de suggestions d’amélioration. Comparativement
avec celles de Baber [3] qui suggère que l’utilisation de
prototypes de RA uniformiserait les modes opératoires.
Cette caractéristique de la technologie serait potentiellement intéressante dans le contexte hautement sécuritaire
de la maintenance de trains.
au nombre de problèmes évoqués, 3 fois moins de suggestions d’amélioration ont été émises. Elles concernent
principalement la conception des animations (ex. ajout
de flèches indicatives, changement de couleurs) et le recalage. Il est intéressant de noter que 2 sujets suggèrent
de ne pas se servir du recalage pour la tâche à réaliser.
Il existe une deuxième piste pour expliquer le nombre
égal de déviations de la procédure dans les deux conditions. Dans les entretiens post-expérimentaux, trois sujets
rapportent
qu’à
certains
moments
de
l’expérimentation, ils avaient accès uniquement au modèle 3D du transformateur électrique et non pas à son
image réelle recalée par rapport au modèle 3D. Nous
pouvons alors présumer que le nombre réduit d’erreurs
est la conséquence d’un guidage en utilisant le seul modèle 3D. D’ailleurs, cette conclusion est appuyée par les
sujets qui, dans les entretiens, jugent le guidage en utilisant le modèle 3D suffisant pour réaliser la procédure.
Ainsi est remise en question l’utilisation du recalage
précis, processus technique exigeant beaucoup de ressources machine, pour des tâches de maintenance simples telles que le vissage et le dévissage, pourtant considérées comme des applications privilégiées de la RA.
DISCUSSION
Au moins deux aspects essentiels des résultats exposés
plus haut méritent une discussion plus approfondie. Il
s’agit, d’une part, des aspects liés à l’utilité et
l’utilisabilité du prototype de RA testé et, d’autre part,
des points méthodologiques liés à l’utilisation des tests
utilisateurs dans le contexte d’une technologie émergente.
L’utilité et l’utilisabilité du prototype de RA testé
Le prototype de RA ne semble pas améliorer l’exactitude
des sujets quant au suivi de la procédure. Les utilisateurs
de la technologie sautent plus d’étapes et commettent autant d’erreurs que les sujets travaillant à l’aide d’une
procédure papier classique. Plusieurs hypothèses peuvent être avancées afin d’expliquer ces résultats.
En termes de rapidité, le temps total de réalisation de la
tâche de maintenance est plus long avec le prototype de
RA qu’avec la procédure papier classique. Ce résultat
global est également observable pendant la première
phase de recherche d’informations et de compréhension
des consignes. Cette phase est plus longue en condition
RA qu’en condition papier. Afin d’expliquer ces résultats, nous pouvons proposer les mêmes hypothèses que
celles avancées pour interpréter le nombre plus important d’étapes sautées dans le groupe « RA » que dans le
groupe « papier ». La nouveauté du prototype ainsi que
ses défauts d’utilisabilité, notamment le recalage lent et
difficile, semblent avoir été déterminants pour les performances inférieures des sujets en RA. Encore une fois,
nous pouvons nous interroger sur la valeur ajoutée du
recalage dans de telles situations de maintenance.
Une première interprétation du nombre plus important
d’étapes sautées en RA est liée à la nouveauté de la technologie testée qui pourrait demander plus de temps de
familiarisation aux sujets. De surcroît, une technologie
émergente susciterait probablement un intérêt plus fort
que la tâche de maintenance elle-même, d’autant plus
que les utilisateurs sont des ingénieurs travaillant dans le
domaine des NTIC. Ainsi, ils accorderaient plus
d’attention à l’utilisation de la technologie qu’au suivi de
la procédure. Une deuxième interprétation, moins flatteuse pour le prototype de RA, concerne ses défauts
d’utilisabilité, notamment son poids assez important ; la
concentration de la charge sur le cou de l’opérateur ; la
contrainte de la position verticale ; la relative incompatibilité du Tablette PC et du stylet avec les tâches manuelles de maintenance (ex. vissage, dévissage) ; l’existence
de câbles de liaison gênant les déplacements des utilisateurs ; les problèmes d’interface logicielle mentionnés
dans les entretiens post-expérimentaux (ex. : recalage
lent, animations difficilement percevables et/ou compréhensibles).
Cependant, il ne s’agit pas ici de prendre une position
anti-technologique, mais d’insister sur la nécessité d’une
conception centrée sur l’utilisateur des technologies
émergentes. Une telle approche assurerait, par exemple,
un meilleur choix des tâches à implanter dans les prototypes, une exploitation plus efficace des caractéristiques
des objets physiques dans l’environnement ainsi qu’une
modélisation plus adéquate des objets virtuels utilisés.
De fait, une conception centrée sur l’utilisateur aboutirait
à une exploitation plus efficace des potentialités offertes
par les technologies émergentes telles que la RA.
Le prototype ne semble pas non plus réduire le nombre
d’erreurs, mais une analyse détaillée des résultats montre
que dans le groupe RA l’ensemble des déviations a lieu à
l’étape 3. En condition papier, aucune erreur n’est constatée à cette étape. Les déviations en condition « RA »
seraient éventuellement imputables à une mauvaise
transcription de la procédure papier qui pourrait concerner, encore une fois, la sémantique ou la visibilité des
animations, le texte de la procédure étant le même dans
les deux conditions. En excluant les résultats de l’étape 3
des analyses, on arrive à des conclusions concordantes
Cette affirmation nous amène naturellement vers une réflexion sur la méthodologie du processus de conception
centrée sur l’utilisateur dans le contexte des technologies
émergentes et notamment sur la place des tests utilisateurs « classiques » dans ce processus.
50
Quelques points méthodologiques
tions du sujet et l’utilisation des fichiers log [9]. En revanche, les problèmes du contrôle de l’environnement
physique et la prise en compte des interactions avec celui-ci trouvent peu de solutions satisfaisantes, notamment si les évaluations sont conduites à l’extérieur.
Les résultats de l’évaluation ergonomique rapide montrent que les tests utilisateurs ont un apport indéniable à
l’évaluation de l’utilité et de la compatibilité de
l’application avec la tâche. Cet avantage de la méthode
est d’autant plus appréciable que les technologies émergentes, en générale, et la RA, en particulier, sont des
technologies en recherche d’applications.
Les tests utilisateurs « classiques » de technologies
émergentes se heurtent également à d’autres types de
contraintes. Ainsi, comme pour l’étude exposée dans cet
article, les contraintes temporelles de conception et la
position généralement technocentrée des décideurs imposent des évaluations ergonomiques avec de petits
échantillons composés fréquemment d’ingénieurs qui
ont travaillé sur le projet (ex. : [10]). Cette limitation entraîne à la fois des avantages et des inconvénients. Nous
y voyons trois principaux inconvénients, à savoir les
connaissances souvent limitées des tâches réelles des futurs utilisateurs ; l’impossibilité de généraliser les résultats de l’évaluation ; le nombre relativement réduit de
problèmes d’utilisabilité détectés (une douzaine dans notre cas). En effet, certains auteurs avancent l’idée que les
conclusions de Nielsen [12] sur le fait que cinq sujets
suffisent pour détecter 85% des défauts d’utilisabilité ne
seraient valables que si tous les problèmes ont la même
probabilité d’être détectés et si tous les utilisateurs ont la
même capacité à découvrir ces problèmes [18] . Une
telle configuration paraît peu probable dans le cadre
d’évaluations de technologies émergentes, puisque
l’expérience de leur utilisation varie beaucoup d’un sujet
à un autre.
Cependant, les indicateurs comportementaux utilisés, notamment le temps de réalisation de la tâche et le nombre
d’erreurs, bien qu’informatifs, semblent insuffisants
dans un objectif d’évaluation formative et d’aide à la reconception du dispositif. Le caractère novateur des technologies émergentes pourrait expliquer cette insuffisance. Ainsi, les utilisateurs ciblés et leurs besoins sont
mal cernés. De ce fait, le recrutement de sujets « représentatifs » est une tâche peu facile. De surcroît, une
grande partie des sujets recrutés n’a pas d’expérience
avec le système. En conséquence, les performances varient fortement et les résultats des tests d’évaluation peuvent se révéler peu profitables aux concepteurs, étant
donné qu’aucune tendance ne se dégage clairement.
Pour ces raisons dans le cadre de reconception de technologies innovantes, une analyse détaillée et qualitative
des stratégies d’utilisation et des difficultés rencontrées
par chaque utilisateur semble plus appropriée qu’une
analyse purement quantitative en termes de performances.
Un deuxième argument pour des analyses plus qualitatives est le caractère souvent prototypique des technologies émergentes existantes. D’une part, les prototypes
sont extrêmement variés et peu nombreux, donc difficiles à comparer, de même que les études à dupliquer.
D’autre part, l’immaturité de la technique rend le travail
d’évaluation assez complexe. Par exemple dans notre
cas, l’instabilité et le nombre de fonctions limité de
l’application a introduit la nécessité d’avoir deux évaluateurs travaillant en même temps. Dans d’autres situations, cette même contrainte pourrait également réduire
les possibilités de construire des tâches expérimentales
tant soit peu réalistes.
Une autre difficulté des tests utilisateurs de technologies
émergentes est la mobilité des systèmes à tester. Cette
spécificité
complique
notablement
le
travail
d’évaluation, les défis majeurs étant l’enregistrement des
différents comportements de l’utilisateur ; le contrôle du
contexte physique (ex. éclairement, environnement sonore, etc.) ; la prise en compte des interactions avec
l’environnement réel qui est un élément clé d’un système
de RA [4] ; la création de scénarios écologiques
d’évaluation [9]. Afin d’enregistrer un maximum de
comportements utilisateur dans une situation « écologique » d’interaction, les chercheurs s’orientent majoritairement vers le port par l’utilisateur même de dispositifs
d’évaluation assez lourds, à savoir plusieurs caméras
plus ou moins miniaturisations filmant les différentes ac-
En revanche, le fait d’impliquer d’actuels ou de futurs
concepteurs de technologies dans une démarche ergonomique de conception pourrait avoir plusieurs avantages, par exemple une meilleure prise de conscience des
difficultés d’utilisation ainsi que du travail de
l’ergonome [13].
Enfin, comme dans le cadre d’évaluations ergonomiques
de technologies plus classiques, les résultats des tests
utilisateurs sont fortement conditionnés par la tâche expérimentale assignée aux sujets. De ce fait, nombre de
défauts ergonomiques qui ne seront pas abordés dans
une tâche donnée peuvent être masqués. Afin de pallier
ce problème, une « triangulation » [11] de plusieurs méthodes d’évaluation semble nécessaire afin de mesurer
d’une manière adéquate l’utilité et l’utilisabilité des
technologies émergentes. L’utilisation de critères ergonomiques, par exemple, est une possibilité dans cette direction.
LIMITES ET PERSPECTIVES
Cette recherche a plusieurs limites, à savoir un échantillon d’utilisateurs assez petit, composé de nonspécialistes de la tâche ; un dispositif technologique peu
fonctionnel et instable ; des conditions d’évaluation différentes de celles dans une situation réelle de mainte-
51
nance de trains. Par conséquent, les résultats de l’étude
ne sont pas généralisables.
Cependant, l’évaluation ergonomique du prototype de
RA ouvre un nombre de pistes de réflexion. Une partie
de ces réflexions ont été exposées plus haut. Une autre
partie concerne le besoin de préciser et faire évoluer les
apports recherchés à travers les tests utilisateurs aussi
bien dans les équipes de conception que dans la communauté IHM. Par exemple, nous pouvons constater que
réaliser un seul test utilisateurs dans le cadre d’une évaluation formative, sans analyse détaillée et précise des
comportements, fait peu pour avancer les connaissances
dans le domaine. Une piste dans cette direction pourrait
être un plus grand nombre de recherches et de publications sur des tests utilisateurs de technologies émergentes, qui aideraient à différencier la spécificité de chaque
situation étudiée et, ainsi, à dégager des principes plus
généraux d’évaluation et de conception. Enfin, un travail
futur sur le développement et l’intégration de méthodes
systématiques de description des performances et des
comportements des utilisateurs semble nécessaire.
Azuma, R.T. A Survey of Augmented Reality. Presence: Teleoperators and Virtual Environments, Vol.
6, No. 4, 1997, pp. 355-385.
3.
Baber, C. Wearable Computers: a Human Factors
Review. International Journal of Human-Computer
Interaction, Vol. 13, No. 2, 2001, pp. 123-145.
4.
5.
13. Redish, J., Bias, R.G., Bailey, R., Molich, R., Dumas, J. and Spool, J.M. Usability in Practice: Formative Usability Evaluations – Evolution and Revolution. In Proceedings of the Computer-Human Interaction Conference CHI 2002 (April 20-25, Minneapolis).
14. Shelton, B. and Hedley, N. (2002). Using
Augmented Reality for Teaching Earth-Sun
Relationships to Undergraduate Geography
Students. In Proceedings of the 1st IEEE
International Augmented Reality Toolkit Workshop
(September 29, Darmstadt).
15. Stedmon, A.W. and Stone, R. Re-viewing Reality:
Human Factors Issues in Synthetic Training
Environments. International Journal of HumanComputer Studies, Vol. 55, No. 4, 2001, pp. 675698.
Bristow, H.W., Baber, C., Cross, J., Knight, J.F. and
Wooley, S.I. Defining and Evaluating Context for
Wearable Computing. International Journal of Human-Computer Studies, Vol. 60, No. 5-6, 2004, pp.
798-819.
Burkhardt, J.M. et Sperandio, J.C. Ergonomie et
conception informatique. In Falzon, P. (Ed.), Ergonomie, PUF, Paris, 2004.
7.
Haniff, D.J. and Baber, C. User Evaluation of Augmented Reality Systems. In Proceedings of the 7th
International Conference on Information Visualization IV 2003 (July 16-18, 2003, London), IEEE
Computer Society, London, 2003, pp. 505-511.
Isomursu, M., Kuutti, K. and Väinämö, S. Experience Clip : Method for User Participation and
Evaluation of Mobile Concepts. In Proceedings of
the ACM Participatory Design Conference PDC
2004 (July 27-31, Toronto).
12. Nielsen, J. Why You Only Need to Test with Five
Users,
2000.
Disponible
à
l'adresse
http://www.useit.com/papers/uselabs.html
Bowman, D., Gabbard, J. and Hix, D. A Survey of
Usability Evaluation in Virtual Environments: Classification and Comparison of Methods. Presence:
Teleoperators and Virtual Environments, Vol. 11,
No. 4, 2002, pp. 404-424.
6.
9.
11. Kaulio, M. and Karlsson I.C.M. Triangulation
Strategies in User Requirements Investigations: a
Case Study on the Development of an IT-mediated
Service. Behaviour & Information Technology, Vol.
17, No. 2, 1998, pp. 103-112.
Anastassova, M., Burkhardt, J.-M., Mégard, C. et
Ehanno, P. L’ergonomie de la réalité augmentée
pour l’apprentissage : une revue. Le Travail Humain, sous presse.
2.
Hix, D., Gabbard, J.L., Swan II, J.E., Livingston,
M.A., Höllerer, Julier, S. J., Baillot, Y. and Brown,
D. A Cost-effective Usability Evaluation Progression for Novel Interactive Systems. In Proceedings
of the 37th Hawaii International Conference on Systems Sciences HICSS 2004 (January 5-8, 2004, Hawaii).
10. Kaufmann, H. and Schmalstieg, D. Mathematics
and Geometry Education with Collaborative Augmented Reality. Computers & Graphics, Vol. 27,
No.3, 2003, pp. 339-345.
BIBLIOGRAPHIE
1.
8.
16. Weidenbach, M., Wick, C., Pieper, S., Quast, K.J.,
Fox, T., Grunst, G. and Redel, D.A. Augmented
Reality Simulator for Training in Two-Dimensional
Echocardiography. Computers and Biomedical
Research, Vol. 33, No. 1, 2000, pp. 11-22.
17. Wiedenmaier, S., Oehme, O., Schmidt, L., & Luczak, H. Augmented Reality for Assembly Processes Design and Experimental Evaluation. International
Journal of Human-Computer Interaction, Vol. 16,
No. 3, 2003, pp. 497-514.
52
19. Yeh, M., & Wickens, C.D. (2001). Display
Ssignaling in Augmented Reality : Effects of Cue
Reliability and Image Realism on Attention
Allocation and Trust Calibration. Human Factors,
Vol. 43, 2001, pp. 355-365.
18. Woolrych, A., & Cockton, G. (2002). Why and
When Five Test Users aren't enough. In Proceedings of IHM-HCI 2001 Conference: Volume 2, eds.
J. Vanderdonckt, A. Blandford, and A. Derycke,
Cépadèus Éditions: Toulouse, 105-108, 2001
53
Association des Réseaux de Pétri et des critères
d’ergonomie des logiciels pour la modélisation et la
réingénierie de systèmes interactifs, cas de la
prescription thérapeutique en milieu hospitalier
Stéphanie Bernonville 1,2, Nicolas Leroy 2
Christophe Kolski 1, Marie-Catherine
Beuscart 2
(1) LAMIH-UMR 8530
Le Mont Houy
F-50313 Valenciennes cedex 9
[email protected]
(2) EVALAB-EA 2694
Faculté de Médicine, 1 place de Verdun
F-59045 Lille
[email protected]
RESUME
étroite collaboration avec les concepteurs et
développeurs de logiciel. Néanmoins, les
spécialistes de l’ingénierie logiciel utilisent leur
propre langage, en l’occurrence les méthodes et
modèles du Génie Logiciel définies par P. Jaulent
[16], comme « un ensemble de 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é ».
Ces différents intervenants proviennent de
disciplines aux vocabulaires et méthodes très
spécifiques. Des difficultés de dialogue et de
compréhension rendent souvent difficile leur
coopération [10]. Pour reprendre les propos de
Scapin et Bastien dans [8], on peut estimer que la
recherche en ergonomie et en IHM devrait
conserver l’objectif de concevoir des outils pouvant
être utilisés à la fois par des spécialistes et des non
spécialistes en spécifications formelle et semiformelle, le problème crucial étant de faciliter les
échanges entre les différents intervenants
(ergonomes, concepteurs, développeurs), dans un
projet de conception de système interactif
complexe.
L’objectif de la méthode proposée dans cet article,
est d’aider à la réingénierie de logiciel interactif en
proposant un support commun de travail entre
spécialistes du Génie Logiciel et spécialistes des
facteurs humains et de l’ergonomie. La méthode
proposée combine explicitement réseaux de Petri et
critères d’ergonomie des logiciels. Des cas d’étude
dans le domaine de la prescription thérapeutique en
milieu hospitalier illustrent l’utilisation de cette
méthode.
MOTS CLES : interaction homme-machine, réseaux
de Petri (RdP), critères ergonomiques, réingénierie
ABSTRACT
The objective of the method proposed in this article
is to help existant interactive software
reingeneering by proposing a common work
support between Software Engineering and Human
Factors specialists. The method combines
explicitely Petri Nets and ergonomic criteria. Case
studies illustrating the method concern medication
ordering in healthcare domain.
KEYWORDS: human-computer interaction, Petri
nets (PN), ergonomic criteria, reingeneering.
L’objectif de la méthode proposée dans cet article,
est justement d’aider à la réingénierie de logiciel
interactif existant en proposant un support commun
de travail entre spécialistes du Génie Logiciel et
spécialistes des facteurs humains et de l’ergonomie
(Figure 1). La méthode proposée vise à contribuer à
ce support commun en combinant réseaux de Pétri
et critères d’ergonomie des logiciels. Dans la
première partie, nous fournissons des éléments
bibliographiques en rapport avec l’utilisation des
réseaux de Petri en IHM. Puis nous décrivons la
méthode proposée, en l’illustrant ensuite de cas
réels provenant du domaine de la prescription
thérapeutique en milieu hospitalier.
INTRODUCTION
De nombreuses études ont démontré l’importance
de l’ergonomie dans les projets informatiques,
notamment en terme de retour sur investissement
[21]. Les ergonomes peuvent intervenir dans
différentes phases d’un cycle de développement
d’un projet, notamment la définition des besoins, la
conception et l’évaluation. Pour notre part, nous
nous intéressons aux projets dans lesquels il s’agit
principalement, pour les spécialistes des facteurs
humains et de l’ergonomie, d’analyser et de
modéliser la situation de travail, de fournir des
recommandations pour la création et la réingénierie
des systèmes interactifs.
UTILISATION DES RDP EN IHM
Dans ce contexte, les spécialistes des facteurs
humains et de l’ergonomie doivent travailler en
Les réseaux de Pétri sont utilisés depuis près d’une
vingtaine d’années en IHM ; par manque de place il
n’est pas possible d’être exhaustif quant à la
55
examiner les interfaces et juger de leur respect des
principes de l’utilisabilité. Même si certains
évaluateurs ne se basent que sur leur expérience et
intuitions, il est recommandé de se baser sur
certaines règles, compilées dans des guidelines.
Parmi les structurations (de règles) les plus
couramment utilisées lors des inspections
ergonomiques, on retrouve celle sous l’angle des
critères ergonomiques provenant de Bastien et
Scapin. Ils sont issus d’une synthèse de résultats
expérimentaux et de recommandations qui ont été
traduites en règles et ensuite regroupés en 8
critères et 13 sous critères [7] (voir figure 2). Une
étude expérimentale a notamment montré que les
critères ergonomiques étaient plus efficaces que les
normes de dialogue ISO/DIS 9241-10 pour détecter
les problèmes ergonomiques sur une IHM [6, 9].
description de leur exploitation en IHM, ni
concernant les différentes variantes de RdP.
Ergonomes
Inspection ergonomique
du logiciel
Analyse de l’activité
Tests utilisateurs
Proposition de modifications
de l’existant
Création de maquette
Supports d’analyse et d’aide
pour la ré-ingénierie
Développeurs
Développement
Analyse des résultats/
prise en compte des contraintes
du logiciel
Figure 1. Intégration des supports d’analyse et d’aide
pour la réingénierie.
Notons qu’ils ont été utilisés dans un premier temps
pour la modélisation des tâches humaines [2, 4, 19,
22, 25], puis ont été exploitées progressivement
pour la spécification et la conception du système
interactif visé, sous l’angle particulièrement de sa
dynamique [14, 24, 25] ; cf. par exemple les ICO
(Interactive Cooperative Objects) [24]. Couplés aux
concepts objets, ils servent d’outil de modélisation
dans TOOD (Task Object Oriented Design [20, 27]
visant à disposer d’une méthode allant de la
modélisation des tâches jusqu’à la génération de
parties de l’IHM. Dans [13], les RdP ont servi de
moyen d’étude des tâches sous l’angle des
situations normales et anormales de fonctionnement
du système technique dans un but de spécification
du système interactif. Les RdP peuvent servir aussi
d’outil de comparaison formelle entre tâche
humaine prescrite (théorique) et tâche réelle [1, 3,
4]. Ainsi, selon le même état d’esprit que les
recherches sur les modèles prédictifs de tâches [15,
18], les RdP nous semblent présenter des
potentialités pour contribuer à faciliter des
évaluations prédictives, moyennant éventuellement
des aménagements pour qu’ils soient plus
facilement compréhensibles et exploitables par des
spécialistes des sciences cognitives. Nous nous
situons dans cet état d’esprit.
1. Guidage
1.1 Incitation
1.2 Groupement/distinction entre items
1.2.1 Groupement/distinction par la localisation
1.2.2 Groupement/distinction par le format
1.3 Feed-back immédiat
1.4 Lisibilité
2. Charge de travail
2.1 Brièveté
2.1.1 Concision
2.1.2 Actions minimales
2.2 Densité informationnelle
3. Contrôle explicite
3.1 Actions explicites
3.2 Contrôle utilisateur
4. Adaptabilité
4.1 Flexibilité
4.2 Prise en compte de l’expérience de l’utilisateur
5. Gestion des erreurs
5.1 Protection contre les erreurs
5.2 Qualité des messages d’erreur
5.3 Correction des erreurs
6. Homogénéité/cohérence
7. Signifiance des codes et dénominations
8. Compatibilité
Tableau 1 : Liste des critères et sous-critères ergonomiques.
PROPOSITION D’UNE ASSOCIATION DES
RESEAUX DE PETRI ET DES CRITERES
D’ERGONOMIE DES LOGICIELS
Dans [26], Palanque et al. proposent des règles
pour effectuer une vérification automatique de
modèles du système interactif. Pour notre part,
notre proposition consiste en la démarche suivante :
après des évaluations, des ergonomes positionnent
manuellement (grâce à un éditeur dédié) des
problèmes ergonomiques sur un modèle du système
interactif, puis expliquent aux informaticiens sur un
nouveau modèle comment ce problème pourrait être
résolu, avec une visée de réingénierie.
Buts de la méthode
La méthode que nous proposons, combine les RdP
aux critères d’ergonomie des logiciels. Elle a pour
vocation de servir de supports d’aide et d’analyse,
communs aux informaticiens et aux ergonomes.
Nous avons choisi de l’intituler ErgoPNets
(Ergonomic criteria associated with Petri Nets).
Justification des choix et intérêts de la méthode
Nous avons choisi d’utiliser les réseaux de Pétri car
ils permettent de représenter graphiquement la
description de la dynamique de la tâche et dans
notre contexte, de modéliser les procédures prévues
par les logiciels et les recommandations données
CRITERES D’ERGONOMIE DES LOGICIELS
L’inspection ergonomique est une méthode
couramment utilisée par les ergonomes [5, 23, 17].
Elle consiste pour un petit panel d’évaluateurs à
56
l’utilisateur d’atteindre son objectif. On distingue
donc les procédures correctes (trait noir) et
incorrectes (trait gris). Enfin, une explication
textuelle des problèmes identifiés, reprenant le nom
du critère et éventuellement du sous-critère (au sens
du tableau 1), justifie l’emploi des critères
d’ergonomie du logiciel.
par les ergonomes. Les critères ont été créés dans le
but d’aider les évaluateurs à détecter les problèmes
lors d’inspections ergonomiques. Ils représentent
également les dimensions ergonomiques majeures
selon lesquelles un logiciel interactif peut être
spécifié ou évalué [5]. Nous les utilisons donc pour
catégoriser les problèmes détectés à l’aide d’autres
méthodes, telles que les observations ou les tests
utilisateurs. En effet, ces critères ont été conçus de
manière à pouvoir être utilisés, aussi bien par des
spécialistes que par des non spécialistes des
facteurs humains [6]. La création de ces supports
permet aux ergonomes de décrire de façon
standardisée les problèmes d’utilisabilité qu’ils ont
détectés, ainsi que les recommandations qui leur
sont associées.
Explications des différentes
méthode ErgoPNets
étapes
de
Critères
Icônes
Guidage
Charge de
travail
Contrôle
explicite
Adaptabilité
la
Gestion des
erreurs
La première étape consiste à définir l’objectif
principal que doit atteindre l’utilisateur du logiciel.
Ensuite, il s’agit de décrire la procédure prévue par
le logiciel et correspondant à cet objectif, à l’aide
des réseaux de Pétri. Pour cela, le formalisme de
base est appliqué, c’est-à-dire l’utilisation des
places et des transitions, auxquelles ont été ajoutées
quelques adaptations pour une meilleure
compréhension de tous les acteurs d’un projet.
Ainsi, les états du système ou places (représentés
par de petits cercles) sont les actions des utilisateurs
ou de la machine et les transitions (représentées par
de petits rectangles) sont les évènements de
changement permettant de passer d’un état à un
autre. Chaque place et chaque transition est décrite
textuellement et l’utilisation des mots « et », « ou »
et « puis » permet la représentation de plusieurs
actions ou plusieurs évènements. Le mot « et »
n’impose pas d’ordre tandis que le « puis » signifie
qu’il y a un ordre. L’étape suivante consiste à
associer chacun des 8 critères d’ergonomie des
logiciels issus directement des travaux de Bastien et
Scapin (Tab. 2), représentés chacun par une icône.
Homogénéité
Signifiance
des codes
Compatibilité
Tableau 2. Icônes représentatives de critères
ergonomiques.
A la suite des inspections d’utilisabilité, les
ergonomes proposent des solutions aux problèmes
identifiés dont certaines peuvent être illustrées par
des maquettes. Par conséquent, pour expliquer ces
solutions, la prochaine étape consiste à appliquer
notre méthode en intégrant les recommandations
des ergonomes. Ainsi, nous obtenons deux
procédures, l’une concernant l’application existante
et l’autre concernant les recommandations. Cette
dernière illustre le même objectif que la procédure
de l’application existante. Les solutions proposées
sont encadrées en trait gras et les icônes
précédemment employée(s) pour identifier les
problèmes, sont ré–utilisées et cochées à l’aide d’un
signe de validation. Une explication textuelle
complémentaire est également ajoutée. Tous ces
éléments de représentation seront illustrés plus loin
dans les figures 3 et 4.
Ainsi, l’association des réseaux de Pétri et de ces
huit icônes permet de modéliser les problèmes
ergonomiques identifiés lors des inspections
d’utilisabilité. Pour cela, après avoir décrit les
procédures correspondant à l’objectif fixé, il s’agit
d’encadrer chaque problème identifié et d’y
associer une ou plusieurs des huit icônes. Le niveau
de détail dans la description des procédures a été
adapté à chaque situation. Ainsi, certains
évènements ont été simplifiés car ils ne sont pas
nécessaires à l’identification des problèmes
ergonomiques. Cependant, ils sont présents pour
une représentation complète et logique des
procédures répondant à l’objectif de départ. Un
code supplémentaire est rajouté lorsqu’il s’agit
d’un problème lié au choix de l’utilisateur du
logiciel et que ces choix engendrent différents
chemins possibles, dont certains ne permettent pas à
En conclusion, la modélisation des procédures
prévues par le logiciel et des recommandations
illustrées par les maquettes, constitue un support
d’aide et d’analyse. Les ergonomes peuvent donc
utiliser ErgoPNets pour formaliser leurs
recommandations de façon plus utilisable par les
développeurs.
OUTIL
SUPPORTANT
ERGOPNETS
LA
METHODE
Les modèles ErgoPNets sont réalisés à l’aide du
logiciel VISIO©, qui permet la création de
57
diagrammes organisationnels ainsi que de schémas
techniques et informatiques. Nous avons créé un
gabarit ErgoPNets regroupant les icônes présentées
dans le tableau 2 ainsi que les formes figurant dans
le tableau 3. La figure 2 montre un exemple
d’application de notre méthode au sein du logiciel
Visio.
Formes
médecin à l’aide d’un logiciel de prescription.
Plusieurs cas ont été traités, illustrant l’exploitation
de 4 critères d’ergonomie des logiciels, parmi les 8
proposés par la méthode. Pour illustrer notre
démarche, nous avons choisi, dans cette partie, de
montrer deux cas particuliers du logiciel de
prescription : la recherche d’un produit et la
constitution d’une perfusion.
Signification
Place (État du système)
SYSTEME INFORMATIQUE
Transition (Événement)
1. Affichage de la liste des
prescriptions du patient
Arc (lien entre état du système et événement)
2. Recherche d’un produit
cadre (identification des problèmes et recommandations
sur le réseau de Pétri)
3. Affichage de la liste des produits
correspondant à la recherche
Critère ergonomique /
sous-critère ergonomique
description
UTILISATEUR DU SYSTEME
4. Sélection d’un produit
Zone de texte (description des problèmes et
recommandations)
5. Affichage du masque de saisie
pour la prescription du produit
Lien (association d’une icône et d’une zone de texte)
9
6. Saisie de la prescription
Signe de validation (à placer sur l’icône critère lors de
l’identification des recommandations sur le réseau de
Pétri)
7. Validation de la prescription
8. Affichage de la liste des
prescriptions du patient modifiée
Tableau 3. Liste des formes contenues dans le Gabarit
Visio supportant ErgoPNets.
Tableau 4. Scénario pour la prescription à l’aide du
logiciel.
Exemples d’application : la recherche
produit et la constitution d’une perfusion
d’un
La constitution des supports d’aide se présente en
quatre parties (figures 3 et 4) : (1) la description des
procédures prévues par le logiciel existant, (2)
l’analyse ergonomique des procédures prévues par
le logiciel existant, (3) la description des procédures
intégrant les recommandations des ergonomes et (4)
l’analyse ergonomique des procédures intégrant les
recommandations des ergonomes.
Description de la procédure prévue par le
logiciel
Pour commencer, nous avons défini un objectif à
atteindre pour l’utilisateur. Dans nos deux cas
(figure 3 et 4), il s’agit : (1) pour le médecin, de
constituer une perfusion et pour cela, de
commencer par la recherche du produit qu’il désire
prescrire et (2) de prescrire un ou plusieurs
composant(s) pour constituer une perfusion.
Figure 2. Exemple de modélisation avec la méthode
ErgoPNets (extrait de l’outil Visio).
CAS D’ETUDE DANS LE DOMAINE DE LA
PRESCRIPTION THERAPEUTIQUE
Nous avons testé notre méthode, dans le cadre d’un
projet de réingénierie d’un logiciel de prescription
thérapeutique, utilisé dans les hôpitaux par le
personnel
hospitalier
(médecin,
infirmière,
pharmacien) [11, 28]. Pour la description des
procédures, nous avons simulé des scénarios
montrant les cas d’utilisation de l’application
informatique qui nous intéresse. Le scénario que
nous avons choisi pour illustrer la méthode est
présenté en tableau 4.
Nous avons, pour chacun des cas, d’abord modélisé
les procédures « recherche d’un produit » pour le
premier cas et « constitution d’une perfusion » pour
le deuxième, prévues par le logiciel (réseau de Pétri
à gauche sur les figures). Nous avons utilisé les
places pour décrire les actions de l’utilisateur ou du
système informatique (ex : affichage de la liste des
prescriptions du patient, ajout d’un nouveau
composant par l’utilisateur, déblocage de la saisie
de la durée d’écoulement…) et les transitions qui
correspondent aux évènements permettant de passer
d’une place à une autre (ex : clic sur bouton
Pour l’application d’ErgoPNets, nous nous sommes
intéressés à la prescription des médicaments par le
58
solutions. Le second réseau de Pétri répond au
même objectif de départ et intègre ces
recommandations (réseau de Pétri à droite sur les
figures 3 et 4). Pour mieux comprendre la
correspondance entre les deux réseaux de Pétri ainsi
que les changements liés aux recommandations,
nous avons placé les réseaux de Pétri dans un
tableau (à gauche la procédure prévue par le
logiciel, à droite le réseau de Pétri intégrant les
recommandations). Chaque ligne du tableau
correspond au découpage des réseaux de Pétri en
parties, celles–ci traitant les mêmes étapes pour
atteindre l’objectif. Sur la figure 3, on voit qu’une
partie a été rajoutée par rapport à la procédure
prévue. Tandis que sur la figure 4, on remarque
qu’une partie présente des changements importants
dans la procédure intégrant les recommandations.
« jumelles », produit par voie orale sélectionné par
l’utilisateur, quantité de produit saisie…).
Nous avons également procédé à des
simplifications, identifiées sur les réseaux de Pétri
par des astérisques (ex : produit par voie orale
sélectionné par l’utilisateur, produit prescrit, heure
de début sélectionnée par l’utilisateur…). Ainsi, on
obtient une description focalisée sur les actions et
évènements pertinents à l’analyse ergonomique.
Analyse ergonomique de la procédure prévue
par
logiciel
existant
(modélisation
des
problèmes ergonomiques identifies par les
ergonomes)
Dans cette partie, il s’agit de modéliser les
problèmes ergonomiques concernant la recherche
d’un produit (figure 3) et la prescription de
composants d’une perfusion (figure 4), mis en
évidence lors de l’inspection d’utilisabilité du
logiciel. Dans nos exemples d’application, les
problèmes
identifiés
ont
été
catégorisés
respectivement selon les critères d’ergonomie des
logiciels suivants : « homogénéité » et « gestion des
erreurs » pour la recherche d’un produit (figure 3)
et selon les critères « compatibilité » et « charge de
travail » pour la prescription de composants d’une
perfusion (figure 4). Sur les RdP, la modélisation
est la suivante : les problèmes sont encadrés,
numérotés et une ou plusieurs icônes (voir tableau
2) leur sont associées. Enfin, des cadres où figure le
nom du critère (éventuellement du sous–critère en
respectant la classification initiale de Bastien et
Scapin), le numéro du problème et une explication
textuelle du problème, sont reliés aux icônes. Par
exemple, sur la figure 3, on a identifié deux
problèmes pour un même ensemble de transitions.
Cet ensemble est encadré et deux icônes
correspondant aux critères « homogénéité » et
« gestion des erreurs » lui sont associés ainsi que
des numéros près de chaque icône. Deux cadres
portant chacun le numéro du problème et le critère
associé
(éventuellement
le
sous–critère,
« protection contre les erreurs » pour le critère
« gestion des erreurs »), donnent respectivement
une explication du problème d’homogénéité et du
problème de gestion des erreurs. Enfin, on voit
également sur le réseau de Pétri de la figure 3, que
les deux chemins proposés sont distingués. Celui en
gris correspond au mauvais choix de procédure par
rapport à l’objectif de départ. Tandis que celui en
noir correspond au choix qui convient. Cette
distribution a été rajoutée pour insister sur le fait
qu’un problème identifié, est lié au choix de
procédure, en l’occurrence pour le problème de
gestion des erreurs dans notre exemple.
Description de la procédure intégrant
recommandations des ergonomes
Analyse ergonomique de la procédure intégrant
les
recommandations
(modélisation
des
solutions proposées par les ergonomes)
Pour modéliser les solutions prises en compte dans
les réseaux de Pétri que nous venons de voir dans la
partie précédente, les ensembles d’actions et
d’évènements rajoutés ou modifiés sont encadrés,
portent le même numéro que le problème auquel ils
correspondent dans le réseau de Pétri situé à
gauche. Les icônes correspondant aux critères tels
que « homogénéité », « gestion des erreurs »,
« charge de travail » et « compatibilité » que nous
avons utilisés dans la partie analyse ergonomique
de la procédure prévue par le logiciel existant, sont
à nouveau employés et cochés par un signe de
validation(9). Enfin, une explication textuelle de la
solution apportée est ajoutée dans le cadre
correspondant au problème traité. Par exemple, sur
la figure 2, un problème de compatibilité a été
identifié et modélisé. Une solution est proposée par
les ergonomes et modélisée dans le réseau de Pétri
de droite. Un même cadre, relié aux icônes
« homogénéité » et « homogénéité » coché d’un
signe de validation, portant le numéro 1 et le critère
« compatibilité », comporte les explications du
problème et de la solution.
RESULTATS PRELIMINAIRES
Dans le cadre de projets de réingénierie de logiciel
de prescription thérapeutique, ErgoPNets a fait
l’objet de premiers tests auprès d’une équipe de 5
ergonomes.
Au cours de l’utilisation de la méthode, plusieurs
types d’utilisation sont ressortis : (1) les ergonomes
pouvaient vérifier en permanence la validité de
leurs recommandations au cours de la construction
de maquettes. En effet, la modélisation des
recommandations a souvent permis de détecter
d’éventuelles incohérences dans la procédure
proposée.
les
Suite aux problèmes identifiés dans la partie
précédente, les ergonomes ont proposé des
59
Procédure prévue par le logiciel existant
Procédure intégrant les recommandations des ergonomes
PROBLEME
Concernant l’icône à cliquer pour
rechercher les composants de la
1
* 4 premières lettres du
perfusion : pour le premier, il faut
produit souhaité saisies
cliquer sur l’icône « constitution d’une
dans le champ « ajouter
nouvelle perfusion », pour les autres,
un médicament »
Homogénéité il faut cliquer sur l’icône « jumelle »
* 4 premières lettres du
produit souhaité saisies
dans le champ « ajouter
un médicament »
(
(
)
)
puis
Affichage de la liste des
prescriptions du patient
1. Homogénéité :
Affichage de la liste des
prescriptions du patient
(
(
Clic bouton « jumelles »
ou
Touche entrée saisie
puis
)
)
Clic bouton « constitution
d’une nouvelle perfusion »
SOLUTION
Il n’y a plus qu’un seul bouton pour
lancer la recherche. L’affichage du
masque de saisie se décide plus tard
2
Gestion des erreurs /
dans la procédure.
protection contre les
Affichage de la liste
erreurs
des injectables
Affichage de la liste des
per os et des injectables
PROBLEME
L’icône permettant de rechercher un
composant d’une perfusion et
d’afficher le masque de saisie
correspondant est éloigné du
champ « ajouter un médicament ».
Dans la majorité des cas, l’utilisateur
a tendance à taper sur l’icône a côté
du champ (icône jumelles) ou sur la
touche entrée. Par conséquent, il
affiche le masque de saisie per os
qui ne correspond pas à la saisie des
composants d’une perfusion.
* Produit injectable
par l’utilisateur
sélectionné par
l’utilisateur
ou
* Produit injectable
sélectionné par l’utilisateur
Clic bouton « jumelles »
ou
Touche entrée saisie
9
1
Affichage des produits
* per os sélectionné
* injectable sélectionné
par l’utilisateur
par l’utilisateur
Gestion des erreurs /protection
contre les erreurs
9
SOLUTION
Si le produit est identifié par le
logiciel comme un IV, un message
lui demande si c’est une perf, une
piqûre ou une PCA pour afficher le
masque de saisie correspondant.
* per os prescrit
puis
Clic sur le bouton
validation de la
prescription
Affichage d’une fenêtre
avec les bouton « piqûre »
« PCA » « perfusion »
2
Clic bouton
« piqûre »
Clic bouton « perfusion »
ou
Clic bouton « PCA »
Affichage du masque de
saisie per os
Affichage du masque
de saisie perfusion
Affichage du masque
de saisie per os
)
)
puis
Homogénéité
2. Gestion des erreurs / souscritère protection contre les
erreurs :
* Produit per os sélectionné
*4 premières lettres du
produit souhaité saisies
dans le champ « ajouter
un médicament »
(
(
* injectable
prescrit
puis
Clic sur le bouton
validation de la
prescription
Affichage du masque de
saisie perfusion
)
(
* Perfusion
ou PCA prescrits
puis
Clic sur le bouton validation
de la prescription
* Per os prescrit
puis
Clic sur le bouton validation
de la prescription
* description simplifiée car elle n’est pas nécessaire à l’analyse des problèmes identifiés ici
Figure 3. Support d’aide à l’analyse et à la modélisation des problèmes et recommandations ergonomiques, cas de la
recherche d’un produit pour la prescription thérapeutique.
Procédure intégrant les recommandations des ergonomes
Procédure prévue par le logiciel existant
Affichage de la liste des
prescriptions du patient
Affichage de la liste des prescriptions du patient
* Recherche d’un
* Recherche d’un produit effectuée
puis
produit effectuée
puis
* Composant d’une perfusion sélectionné
* Composant d’une
perfusion sélectionné
* Quantité de
* Quantité de produit saisie
puis
Clic sur l’onglet « posologie »
1. Compatibilité :
PROBLEME
Pour saisir une durée
d’écoulement de la
perfusion, le médecin
doit d’abord saisir une
fréquence « toutes les »
ou un horaire (perte de
temps)
Affichage du masque de saisie « posologie » avec
l’onglet « fréquence et instants » affiché par défaut
* Heure de début sélectionnée par
1
l’utilisateur
ou
* Fréquence « toutes les »
sélectionnée par l’utilisateur
Compatibilité
Déblocage de la saisie d’une durée d’écoulement
Charge de travail/
action minimale
clic sur le bouton
validation de la
prescription
Nombre saisi avec la
calculette
puis
Clic sur le bouton « h »
Nombre saisi
avec la calculette
puis
Clic sur le bouton
« min »
Affichage de la durée
dans le champ/
Affichage du bouton
« h » sur sur fond jaune
Affichage de la durée
dans le champ/
Affichage du bouton
« h » sur sur fond jaune
Affichage de la durée
dans le champ/
Affichage du bouton
« min » sur fond
jaune
Nombre saisi avec la
calculette
puis
Clic sur le bouton
« min »
Affichage de la durée
dans le champ/
Affichage du bouton
« min » sur fond jaune
clic sur le bouton
validation de la
prescription
clic sur le bouton
validation de la
prescription
clic sur le bouton
validation de la
prescription
Saisie durée d’écoulement
Affichage de la
durée égale à
30min dans le
champ/
Affichage du
bouton « 30min »
sur fond jaune
Nombre saisi avec la
calculette
puis
Clic sur le bouton « h »
9
Compatibilité
1
2. Charge de travail /
sous-critère action
minimale :
2
Clic sur le
bouton « 30min »
SOLUTION
L’interface n’impose pas
d’ordre de saisie
produit saisie
puis
Clic sur le bouton
« validation »
PROBLEME
Les aller-retour entre la
calculette et les
boutons pour saisir une
durée d’écoulement
font perdre du temps
SOLUTION
La saisie de la durée
d’écoulement se fait au
clavier ou via une liste
déroulante dans un
champ spécifique
Affichage du masque de saisie
« composant » avec une fenêtre
constituée des onglets
« quantité » et « dose »
Affichage du masque de saisie
« composant » avec nom du composant
et quantité saisie dans le tableau
* Fréquence « toutes les » saisie
(
(
ou
* Moments saisie
ou
* heure de début saisie
)
)
et
Taper dans le champ « durée
d’écoulement » la durée souhaitée
ou
Sélectionner dans la liste déroulante
la durée d’écoulement souhaitée
9
2
Charge de travail/
action minimale
Affichage des informations saisies
clic sur le bouton validation
de la prescription
*description simplifiée car elle n’est pas nécessaire à l’analyse des problèmes identifiés ici
Figure 4. Support d’aide à l’analyse et à la modélisation des problèmes et recommandations ergonomiques, cas de la
constitution d’une perfusion.
60
Saisie durée d’écoulement
Affichage du masque de saisie
« composant » avec l’onglet
« quantité » affiché par défaut
de la méthode des moyens permettant de vérifier
différentes propriétés (réseau borné, vivacité d’un
réseau, réversibilité d’un réseau, réseau sans
blocage) propres aux RdP [12].
(2) Les modèles ErgoPNets ont constitué un
support de communication entre ergonomes et
informaticiens. En effet, les ergonomes ont testé
ErgoPNets pour structurer et modéliser leurs
résultats et les présenter aux informaticiens afin de
leur rendre compte des éventuels points à
considérer concernant le logiciel testé. (3) Si on
compare à une description purement textuelle des
problèmes et recommandations, l’utilisation des
procédures précise la localisation des problèmes et
recommandations et permet d’éviter des ambiguïtés
d’interprétation pour les développeurs. (4) La
création de ces modèles a permis d’alimenter la
mémoire du projet (intégration dans la
documentation du projet).
REMERCIEMENTS
Les auteurs remercient la Région Nord-Pas de
Calais, le FEDER (projets TAC MIAOU et
EUCUE) et le réseau RNTS (projet Presc’Info) qui
ont contribué à financer ces recherches.
BIBLIOGRAPHIE
La caractéristique principale d’ErgoPNets est
l’association des réseaux de Pétri et des critères
ergonomiques pour l’intégration des problèmes et
recommandations ergonomiques au sein des
procédures. Son emploi est particulièrement adapté
pour décrire les problèmes liés à la dynamique des
procédures prévues par le logiciel, qui ne sont pas
toujours compatibles avec l’activité réelle des
utilisateurs. Ainsi, la description des problèmes
relatifs à certains critères tels que « charge de
travail », « adaptabilité », « gestion des erreurs »,
« homogénéité » et « compatibilité » se prêtent
efficacement à l’application de notre méthode. En
effet,
le
formalisme
permet
d’identifier
graphiquement l’impact des recommandations des
ergonomes sur les procédures existantes.
Les résultats préliminaires décrits dans cette partie
sont issus des remarques des ergonomes, qui ont
réalisé les premiers tests. A ce jour, ErgoPNets doit
donc faire l’objet d’une validation plus
approfondie. La mise en place d’un protocole de
test est en cours de préparation.
CONCLUSION ET PERSPECTIVES
Grâce aux réseaux de Pétri et aux critères
ergonomiques, ErgoPNets prend en compte, d’une
part les aspects descriptifs et prescriptifs des
procédures, et d’autre part l’aspect évaluatif de
l’IHM. Cette méthode a fait l’objet de premières
expérimentations en rapport avec la réingénierie
d’un logiciel de prescription thérapeutique. De
nombreuses perspectives découlent de ce travail.
Nous envisageons une analyse profonde des
activités des ergonomes et informaticiens utilisant
la méthode ErgoPNets, afin en particulier d’étudier
l’intégration de la méthode dans leurs activités, ses
points forts et points faibles. L’outil peut faire
l’objet d’améliorations sous l’angle de différentes
aides à l’utilisateur durant la création et la
modification des modèles, de même que sous
l’angle de l’aide à la documentation dans un projet.
Enfin, il sera important de fournir aux utilisateurs
61
1.
Abed, M. Méthodes et modèles formels et
semi-formels pour la conception et
l’évaluation des systèmes homme-machine.
Mémoire d’HDR, Université de Valenciennes
et du Hainaut-Cambrésis, Mai 2001.
2.
Abed, M. Contribution à la modélisation de la
tâche par outils de spécification exploitant les
mouvements oculaires : application à la
conception et l’évaluation des interfaces
homme-machine.
Thèse
de
Doctorat,
Université de Valenciennes et du HainautCambrésis, Septembre 1990.
3.
Abed, M, Bernard, J.M, Angué, J.C. Method
for comparing task model and activity model.
Proceedings
11th
European
annual
conference Human Decision Making and
Manual Control, Valenciennes, France, 1992.
4.
Abed, M., Ezzedine, H. Vers une démarche
intégrée de conception-évaluation des
systèmes Homme-Machine. Journal of
Decision Systems, Vol. 7, 1998, pp. 147-175.
5.
Bastien, J. M. C. L’inspection ergonomique
des logiciels interactifs : intérêts et limites. In
Hoc, J. M., Darses, F. (Eds), Psychologie
ergonomique : tendances actuelles. Paris,
2004.
6.
Bastien, J. M. C., Scapin, L. D. Ergonomic
Criteria for the Evaluation of HumanComputer Interfaces. Rapport technique
INRIA, nq156, 1993.
7.
Bastien, J. M. C., Scapin, L. D. Evaluating a
user interface with ergonomic criteria.
Rapport de recherche INRIA n°2326, 1994.
8.
Bastien, C., Scapin, L.D. Évaluation des
systèmes
d’information
et
Critères
Ergonomiques. In Kolski C. (Ed.).
Environnements évolués et évaluation de
l’IHM, Paris, 2001, pp. 53-80.
9.
Bastien, J. M. C., Scapin, L. D., Leulier, C.
The ergonomic criteria and the ISO/DIS 924110 dialogue principles : a pilot comparison in
an evaluation task. Interacting with
computers, vol. 11, 1999, pp. 299-322.
19. Kontogiannis, T. A Petri Net-based approach
for ergonomic task analysis and modeling
with emphasis on adaptation to system
changes, Safety Science, vol. 41, n°10, 2003,
pp. 803-835.
10. Bernonville, S., Kolski C., Beuscart-Zéphir M.
Contribution and limits of UML models for
task modelling in a complex organizational
context: case study in the healthcare domain.
In K.S. Soliman (Ed.), Internet and
Information
Technology
in
Modern
Organizations: Challenges & Answers,
Proceedings of The 5th IBIMA Conference,
December 13-15, Cairo, Egypt, 2005, pp. 119127.
20. Mahfoudhi, A. TOOD : une méthodologie de
description orientée objet des tâches
utilisateur pour la spécification et la
conception des interfaces homme-machine,
application au contrôle du trafic aérien.
Mémoire de Doctorat, Université de
Valenciennes et du Hainaut-Cambrésis,
janvier 1997.
11. Beuscart-Zéphir, M.C., Pelayo, S., Guerlinger,
S., Anceaux, F., Kulik, J.F., Meaux, J.J.,
Degoulet, P. Computerized “Physician” Order
Entry (CPOE): missing the “N”, standing for
Nurse. Physicians and Nurses activity analysis
and comparison with Paper-based and
Computerized Order Entry systems, IT in
Health Care: Sociotechnical Approaches, 2nd
international Conference, 13-14 September,
Portland Oregon USA, 2004.
21. Mayhew, D., J. The usability engineering
lifecycle. Morgan Kaufmann Publishers, 1999.
22. Navarre, D. Contribution à l’ingénierie en
IHM. Une technique de description formelle et
un environnement pour une modélisation et
une exploitation synergique des tâches et du
système. Thèse de doctorat, Université de
Toulouse 1, juillet 2001.
12. Diaz, M. (Ed.). Réseaux de Pétri, Modèles
Avancés. Hermes, Paris, 2002.
23. Nielsen, J., Molich, R. Heuristic evaluation of
user interfaces. Proceeding of ACM Conf.
CHI’90, ACM Press, Seattle, 1990, pp. 249256.
13. Ezzedine, H., Kolski, C. Modelling of
cognitive activity during normal and
abnormal situations using Object Petri Nets,
application to a supervision system,
Cognitive, Technology and Work, vol. 7,
2005, pp. 167-181.
24. Palanque, P. Modélisation par objets
coopératifs interactifs d'interfaces hommemachines dirigées par l'utilisateur. Thèse de
Doctorat, Université de Toulouse 1, 1992.
14. Gomes, L., Barros, J.P., Coasta, A. Manmachine interface for real-time telecontrol
based on Petri nets specification. In T. Bahill,
F.Y. Wand (Eds.), IEEE SMC 2001
Conference Proceedings (e-Systems, e-Man
and e-Cybernetics), Arizona, USA: IEEE
Press, 2001, pp. 1565-1570.
25. Palanque, P., Bastide, R. Synergistic modelling
of tasks, system and users using formal
specification techniques, Interacting With
Computers, vol. 9, n° 12, 1997, pp. 129-153.
26. Palanque P, Farenc C, Bastide R (1999)
Embedding Ergonomic Rules As Generic
Requirements in a formal Development
Process of Interactive Software. In Proceeding
Interact’99, Sasse A, Jonhson C (Eds). IOS
Press, pp 408-416.
15. Gray, W.D., John, B.E., Atwood M.E. Project
Ernestine: a validation of GOMS for
prediction and explanation of real-world task
performance, Human-Computer Interaction,
vol. 8, 1992, pp. 237-259.
16. Jaulent, P. Génie Logiciel, les méthodes.
Armand Colin, Paris, 1990.
27. Tabary D. Contribution à TOOD, une méthode
à base de modèles pour la spécification et la
conception des systèmes interactifs. Thèse de
Doctorat, Université de Valenciennes et du
Hainaut-Cambrésis, janvier 2001.
17. Kahn, J., M., Prail A. Formal Usability
Inspection. In Nielsen, J., and Mack R., L.
Usability inspection method. John Willey &
son, 1994, pp 141-171.
28. Pelayo, S., Leroy, N., Guerlinger, S.,
Degroisse, M., Meaux, J.J., Beuscart-Zephir,
M.C. Méthodes ergonomiques pour soutenir la
ré-ingénierie des applications logicielles en
santé : l’exemple des fonctionnalités de
prescriptions thérapeutiques. Proceeding of
ErgoIA 2004, Biarritz, France, Novembre
2004.
18. Kieras, D. GOMS models for task analysis. In
D. Diaper and N. Stanton (Eds.), Handbook of
Task
Analysis
for
Human-Computer
Interaction, Lawrence Erlbaum Associates,
London, 2003, pp. 83-116.
62
Mémoire des documents familiers : Implications pour
les systèmes de récupération de fichiers
7%ODQF%UXGH
'/6FDSLQ
INRIA 78153 Le Chesnay cedex, France
[email protected]
INRIA 78153 Le Chesnay cedex, France
[email protected]
EOH3DUFRQVpTXHQWXQSUREOqPHLPSRUWDQWHVWODFRP
SOH[LWpGHODJHVWLRQGHFHVLQIRUPDWLRQVHWSOXVSDUWL
FXOLqUHPHQWOHXUUpFXSpUDWLRQ/HVRXWLOVLQIRUPDWLTXHV
FODVVLTXHV V
DSSX\DQW VXUODPpWDSKRUHGX EXUHDX SK\
VLTXHHWLPSRVDQWXQHRUJDQLVDWLRQGHW\SHKLpUDUFKLTXH
GHV ILFKLHUV pOHFWURQLTXHV RQW PRQWUp OHXUV OLPLWHV
>@ >@ /H EHVRLQ GH QRXYHDX[ RXWLOV SHUPHWWDQW
DX[ XWLOLVDWHXUV GH JpUHU SOXV IDFLOHPHQW OHXUVGRQQpHV
DSSDUDvWGRQFFRPPHXQHQpFHVVLWp/HWHUPH3HUVRQDO
,QIRUPDWLRQ0DQDJHPHQW3,0GpVLJQHOHGRPDLQHGH
UHFKHUFKHTXLpWXGLHODPDQLqUHGRQWOHVXWLOLVDWHXUVJq
UHQW OHXUV GRFXPHQWV SK\VLTXHV OLYUH FDKLHU IHXLOOH
HWF RX QXPpULTXHV ILFKLHU HPDLO SDJH ZHE HWF
GDQVOHEXWGHFRQFHYRLUGHVRXWLOVLQIRUPDWLTXHVG
DLGH
j OD JHVWLRQ GH FHV GRFXPHQWV 3,0 WRROV 6HORQ
%RDUGPDQ >@ O
DFWLYLWp PrPH GH JHVWLRQ GHV GRFX
PHQWV SHXW rWUH GpFRPSRVpH HQ VRXVDFWLYLWpV O
DF
TXLVLWLRQO
RUJDQLVDWLRQODPDLQWHQDQFHHWODUpFXSpUD
WLRQ GHV GRFXPHQWV 1RXV QRXV LQWpUHVVRQV SOXV SDUWL
FXOLqUHPHQW j OD VRXVDFWLYLWp GLWH GH UpFXSpUDWLRQ FDU
QRXV SHQVRQV TX
HOOHFRQVWLWXHO¶XQGHVSUREOqPHVPD
MHXUVOLpVjODJHVWLRQGHVGRFXPHQWV(QHIIHWFRPSWH
WHQX GX IDLW TXH OHXU QRPEUH QH FHVVH GH FURvWUH GDQV
QRV PDFKLQHV QRV GRFXPHQWV VRQW VRXYHQW GLIILFLOHV j
UHWURXYHUGDQVODPDVVH
RÉSUMÉ
&HWWHpWXGHH[SORUDWRLUHDSRXUEXWGHGpWHUPLQHUTXHOV
VRQW OHV DWWULEXWV GRQW OHV XWLOLVDWHXUV VH VRXYLHQQHQW j
SURSRVGHOHXUVSURSUHVGRFXPHQWVSDSLHUHWpOHFWURQL
TXH HW FRPPHQW LOV OHV UDSSHOOHQW DILQ GH IRXUQLU GHV
UHFRPPDQGDWLRQVVXUODPDQLqUHGHFRQFHYRLUGHVV\V
WqPHVTXLSHUPHWWHQWDX[XWLOLVDWHXUVGHUHWURXYHUOHXUV
ILFKLHUV pOHFWURQLTXHV SOXV HIILFDFHPHQW HW SOXV IDFLOH
PHQW 8QH TXDVLH[SpULHQFH D pWp FRQGXLWH DYHF TXD
WRU]H SDUWLFLSDQWV GDQV OHXU SURSUH HQYLURQQHPHQW GH
WUDYDLO 2Q OHXU GHPDQGDLW WRXW G
DERUG GH VH UDSSHOHU
GHV FDUDFWpULVWLTXHV G
XQ RX SOXVLHXUV GH OHXUV GRFX
PHQWVGHWUDYDLOHWGHX[LqPHPHQWGHOHVUHWURXYHU/HV
UpVXOWDWV YRQW GDQV OH VHQV G
XQ EHVRLQ SRXU GHV RXWLOV
GH UpFXSpUDWLRQ SOXV SHUIRUPDQWV ,OV LQGLTXHQW pJDOH
PHQWTXHOVVRQWOHVDWWULEXWVTXLVRQWGHERQVFDQGLGDWV
SRXU IDFLOLWHU ODUpFXSpUDWLRQHWFRPPHQWH[SORLWHUFHV
DWWULEXWVGDQVOHVV\VWqPHVGHUHFKHUFKHGHILFKLHUV
MOTS CLES : *HVWLRQ GHV LQIRUPDWLRQV SHUVRQQHOOHV
pWXGHVXWLOLVDWHXUV\VWqPHVGHUHFKHUFKHVXUOHEXUHDX
UHFKHUFKHG
LQIRUPDWLRQPpPRLUHKXPDLQH
ABSTRACT
7KLVSUHOLPLQDU\VWXG\DLPVDWILQGLQJRXWZKLFKDWWULE
XWHVSHRSOHDFWXDOO\UHFDOODERXWWKHLURZQGRFXPHQWV
HOHFWURQLFDQGSDSHUDQGKRZWKH\UHFDOOWKHPLQRU
GHUWRSURYLGHUHFRPPHQGDWLRQVRQKRZWRGHVLJQWRROV
WKDW DOORZ XVHUV WR UHWULHYH WKHLU HOHFWURQLF ILOHV PRUH
HIIHFWLYHO\ DQG PRUH HDVLO\ $ TXDVLH[SHULPHQW ZDV
FRQGXFWHGZLWKIRXUWHHQSDUWLFLSDQWVDWWKHLUZRUNSODFH
7KH\ ZHUH DVNHG ILUVW WR UHFDOO IHDWXUHV DERXW RQH RU
VHYHUDO RI WKHLU RZQ ZRUN GRFXPHQWV DQG VHFRQGO\
WR ILQG WKHVH GRFXPHQWV5HVXOWV FRUUHODWHV ZLWK WKH
QHHG IRU EHWWHU WRROV IRU UHWULHYDO ,Q DGGLWLRQ UHVXOWV
LQGLFDWH ZKLFK DWWULEXWHV DUH FDQGLGDWH IRU IDFLOLWDWLQJ
ILOHUHWULHYDODQGKRZVHDUFKWRROVVKRXOGXVHWKHVHDW
WULEXWHV
&HW DUWLFOH SUpVHQWH WRXW G¶DERUG OD SUREOpPDWLTXH GH
O¶pWXGHSXLVGpFULWODPpWKRGRORJLHHPSOR\pHDLQVLTXH
OHVUpVXOWDWVREWHQXV(QILQODGLVFXVVLRQVHIRFDOLVHVXU
OHV LPSOLFDWLRQV GHV UpVXOWDWV SRXU OD FRQFHSWLRQ OD
FRQFOXVLRQ pYRTXDQW OHV OLPLWHV GH O¶pWXGH HW OHV SHUV
SHFWLYHVRXYHUWHV
LE RÔLE DES ATTRIBUTS DE DOCUMENT DANS
LEUR RÉCUPÉRATION
/HVRXWLOVG
DLGHjODJHVWLRQGHVGRFXPHQWVSHUVRQQHOV
3,0 WRROV TX
LOV VRLHQW GHV SURWRW\SHV GH UHFKHUFKH
RX GHV V\VWqPHV FRPPHUFLDOLVpV H[SORLWHQW GLIIpUHQWV
W\SHV G
DWWULEXWV GHV GRFXPHQWV SRXU SHUPHWWUH HQWUH
DXWUHVOHXUUpFXSpUDWLRQ SDUO
XWLOLVDWHXU$LQVLOHVRX
WLOVFODVVLTXHVGHVV\VWqPHVG
H[SORLWDWLRQFRQoXVVHORQ
ODPpWDSKRUHGXEXUHDXSK\VLTXHHWLPSRVDQWXQHRUJD
QLVDWLRQ KLpUDUFKLTXH GHV ILFKLHUV IRQW UHSRVHU OD UpFX
SpUDWLRQGHVGRFXPHQWVVXUGHX[DWWULEXWVHQSDUWLFXOLHU
OD ORFDOLVDWLRQ VSDWLDOH GHV GRFXPHQWV HW OH QRP GHV
GRFXPHQWV'
DXWUHV3,0WRROVLVVXVGHODUHFKHUFKHHW
FRQoXVFRPPHGHVDOWHUQDWLYHVDX[RXWLOVFODVVLTXHVRQW
KEYWORDS :3HUVRQDOLQIRUPDWLRQPDQDJHPHQWXVHU
VWXGLHV GHVNWRS VHDUFK WRROV LQIRUPDWLRQ UHWULHYDO
KXPDQPHPRU\
INTRODUCTION
/DTXDQWLWpGHGRQQpHVQXPpULTXHVTXHQRXVDFTXpURQV
HWVWRFNRQVGDQVQRVRUGLQDWHXUVGXUDQWQRVDFWLYLWpVGH
WUDYDLORXGDQVQRWUHYLHSULYpHHVWGHYHQXHFRQVLGpUD
63
SHUVRQQHOV*RQoDOYHVHW-RUJH>@RQWIDLWXQSDVGDQV
FHWWH GLUHFWLRQ HQ GHPDQGDQW j GHV XWLOLVDWHXUV GH UD
FRQWHU O
KLVWRLUH GH WURLV GRFXPHQWV TX
LOV SRVVpGDLHQW
SRXULGHQWLILHUOHVW\SHVG
DWWULEXWVOHVSOXVVRXYHQWUDS
SHOpVHWFRPPHQWFHVDWWULEXWVV
HQFKDvQHQWGDQVODQDU
UDWLRQ &HSHQGDQW OHXU pWXGH QH QRXV UHQVHLJQH QL VXU
ODILDELOLWpGXUDSSHOLHTXHOHVWOHGHJUpG
H[DFWLWXGH
GX UDSSHO " FHOD GpSHQGWLO GX W\SH G
DWWULEXWV " QL
VXU OD PDQLqUH GRQW OHV DWWULEXWV VRQW UDSSHOpV LH GH
TXHOOHV LQIRUPDWLRQV SUpFLVHV UHODWLYHV j XQ DWWULEXW
GRQQp OHV XWLOLVDWHXUV VH VRXYLHQQHQWLOV " DYHF TXHO
GHJUpGHSUpFLVLRQV
H[SULPHOHUDSSHO"1RXVSHQVRQV
TXH FHV LQIRUPDWLRQV VRQW QpFHVVDLUHV SRXU FRQFHYRLU
GHV RXWLOV G
DLGH j OD UpFXSpUDWLRQ GHV GRFXPHQWV TXL
VRLHQW DGDSWpV DX[ FDSDFLWpV GH PpPRULVDWLRQ HW GH
UDSSHOGHVXWLOLVDWHXUVHWSHUPHWWHQWGHOHVH[SORLWHUDX
PLHX[ /
REMHFWLI GH O
pWXGH TXH QRXV DOORQV SUpVHQWHU
PDLQWHQDQWHVWGHWHQWHUGHUpSRQGUHjFHVTXHVWLRQV
FKRLVL G
H[SORLWHU HQ SULRULWp G
DXWUHV W\SHV G
DWWULEXWV
FRPPHSDUH[HPSOHOHWHPSVOLpjO
XWLOLVDWLRQGHVGR
FXPHQWV HJ /LIHVWUHDPV >@ RX OH SURMHW G
DSSDUWH
QDQFHGHVGRFXPHQWVHJ80($>@(QILQFHUWDLQV
3,0WRROVHJ 3UHVWR>@ +D\VWDFN>@DLQVLTXH
OHV RXWLOV GH UHFKHUFKH GHV V\VWqPHV G
H[SORLWDWLRQ GH
QRVRUGLQDWHXUVHJ6SRWOLJKWGDQV0DF26;7LJHU
IRQFWLRQQDOLWp 5HFKHUFKHU GH 06 :LQGRZV 9LVWD
WHQWHQWG
H[SORLWHUOHPD[LPXPG
DWWULEXWVSRXYDQWrWUH
XWLOLVpVSDUO
XWLOLVDWHXUORUVGHVDUHFKHUFKHHJQRP
FRQWHQXGDWHWDLOOHHWF
0DLVFRPPHOHVRXOLJQH%RDUGPDQ>@OHVSURWRW\SHV
GHUHFKHUFKHVRXIIUHQWODSOXSDUWGXWHPSVG
XQPDQTXH
G
pYDOXDWLRQ HWRX G
XQ UpHO IRQGHPHQW HPSLULTXH RX
WKpRULTXHYRLUDXVVL>@4XDQWDX[RXWLOVGHUHFKHU
FKH GHV V\VWqPHV G
H[SORLWDWLRQ GHV pWXGHV PRQWUHQW
TXH OHV XWLOLVDWHXUV QH V
HQ VHUYHQW TX
HQ GHUQLHU UH
FRXUVSUpIpUDQWSDUFRXULUOHVUpSHUWRLUHV>@>@2U
QRXV SHQVRQV TX
XQH GHV SULQFLSDOHV UDLVRQV SRXU OHV
TXHOOHV FHV GHUQLHUV QH VRQW SDV XWLOLVpV HVW TX
LOV QH
VRQW SDV VXIILVDPPHQW XWLOHVHWXWLOLVDEOHVPrPHVLGH
QRXYHOOHV pWXGHV VRQW QpFHVVDLUHV VXU OHV RXWLOV GH UH
FKHUFKH GH QRXYHOOH JpQpUDWLRQ HJ 0DF 26 6SR
WOLJKW TXL VH VRQW ODUJHPHQW DPpOLRUpV HQ SDUWLFXOLHU
HQWHUPHVGHWHPSVGHUpSRQVH1RXVUHMRLJQRQV5DYD
VLRHWDO>@SRXUTXLODUDLVRQSRXUODTXHOOHOHVRXWLOV
GH UHFKHUFKH GHV V\VWqPHV G
H[SORLWDWLRQ QH VRQW SDV
XWLOLVpV SRXUUDLW rWUH TXH H[LVWLQJ VHDUFK WRROV KDYH
QHYHU EHHQ GHVLJQHG IRU DYHUDJH XVHUV EXW UDWKHU IRU
H[SHUWVS
MÉTHODOLOGIE
Participants
'HX[ JURXSHV GH SDUWLFLSDQWV VHSW FKHUFKHXUV HW VHSW
PHPEUHVGXSHUVRQQHODGPLQLVWUDWLIG
XQLQVWLWXWGHUH
FKHUFKH RQW SDUWLFLSp j QRWUH pWXGH /HV SDUWLFLSDQWV
RQWpWpVpOHFWLRQQpVGHPDQLqUHjIRUPHUGHX[JURXSHV
GHSHUVRQQHVHIIHFWXDQWGHX[W\SHVGHWUDYDLOTXDOLWDWL
YHPHQW GLIIpUHQWV GDQV OH EXW G
REWHQLU XQH PHLOOHXUH
UHSUpVHQWDWLYLWpGHQRWUHpFKDQWLOORQHWGHWHVWHUOHVHI
IHWV pYHQWXHOV GHV FDUDFWpULVWLTXHV GH O
DFWLYLWp VXU OD
PpPRULVDWLRQ GHV FDUDFWpULVWLTXHV GHV GRFXPHQWV GH
WUDYDLO
1RXVSHQVRQVFRPPH/DQVGDOH>@TXHODFRQFHSWLRQ
GHV3,0WRROVGRLWSRXUTXHFHVGHUQLHUVVRLHQWDGDSWpV
DX[ XWLOLVDWHXUV UHSRVHU VXU O
LQYHVWLJDWLRQ GHV PpFD
QLVPHVFRJQLWLIVVRXVMDFHQWVjO¶DFWLYLWpGH3,0(QFH
TXLFRQFHUQHODUpFXSpUDWLRQGHVGRFXPHQWVOHVXWLOLVD
WHXUVHIIHFWXDQWOHXUVUHFKHUFKHVVXUODEDVHGHFHGRQW
LOVVHVRXYLHQQHQWjSURSRVGHFHX[FLHJOHXUHPSOD
FHPHQWOHXUQRPHWFO
LQYHVWLJDWLRQGHVDFWLYLWpVFR
JQLWLYHV GH PpPRULVDWLRQ GHV DWWULEXWV GHV GRFXPHQWV
VHPEOH GRQF SULPRUGLDOH 'HV pWXGHV H[SpULPHQWDOHV
VRQWDOOpHVGDQVFHVHQVHQWHVWDQWODFDSDFLWpGHVXWLOL
VDWHXUVjPpPRULVHUHWjUDSSHOHUFHUWDLQVDWWULEXWVHJ
ORFDOLVDWLRQ DSSDUHQFH QRPV HWF GDQV GHV WkFKHV GH
UpFXSpUDWLRQ GH GRFXPHQWV >@ >@ >@ >@ >@
>@ 6L FHV pWXGHV RQW SHUPLV G
REWHQLU GHV UpVXOWDWV
WUqV LQWpUHVVDQWV HOOHV SUpVHQWHQW FHSHQGDQW O
LQFRQYp
QLHQWGXPDQTXHGHYDOLGLWppFRORJLTXHGXPDWpULHOXWL
OLVp (Q HIIHW VDQV GRXWH j FDXVH GHV FRQWUDLQWHV TXL
V
H[HUFHQW VXU OHV H[SpULPHQWDWLRQV FRQWU{OpHV OHV Wk
FKHV GH UpFXSpUDWLRQ QH IRQW SDV LQWHUYHQLU OHV GRFX
PHQWV SURSUHV DX[ SDUWLFLSDQWV PDLV GHV GRFXPHQWV
FROOHFWpV SDU O
H[SpULPHQWDWHXU DYHF OHVTXHOV O
XWLOLVD
WHXU GRLW VH IDPLOLDULVHU GDQV OH FRQWH[WH GH O
H[SpUL
PHQWDWLRQ $LQVL FHV pWXGHV QH SHUPHWWHQW SDV GH Up
SRQGUH j OD TXHVWLRQ VXLYDQWH GH TXRL OHV XWLOLVDWHXUV
VHUDSSHOOHQWLOVjSURSRVGHOHXUVSURSUHVGRFXPHQWV
Procédure
'HV LQWHUYLHZV VHPLGLULJpHV VXLYLHV G
XQH TXDVL
H[SpULHQFH RQW pWp FRQGXLWHV ORUV GH VHVVLRQV G¶XQH
KHXUHHWGHPLHjGHX[KHXUHVGDQVOHEXUHDXGHVSDUWL
FLSDQWV/HVLQWHUYLHZVVHPLGLULJpHVYLVDLHQWjFRQQDv
WUH OH FRQWH[WH GH WUDYDLO HW OHV GLIIpUHQWHV WkFKHV GHV
SDUWLFLSDQWVSRXURULHQWHUOHFKRL[GHVGRFXPHQWVFLEOHV
VSpFLILTXHV VXU OHVTXHOV SRUWDLW OD TXDVLH[SpULHQFH
/¶REMHFWLIGHFHWWHTXDVLH[SpULHQFHpWDLWGHGpWHUPLQHU
GDQVTXHOOHPHVXUHOHVSDUWLFLSDQWVVHUDSSHOOHQWGHVLQ
IRUPDWLRQV RX GHV pYqQHPHQWV OLpV j OHXUV GRFXPHQWV
pOHFWURQLTXH HW SDSLHU HW GH GpWHUPLQHU TXHOOHV VRQW
OHVFDUDFWpULVWLTXHVTXLVRQWXWLOLVpHVRXQRQSRXUODUp
FXSpUDWLRQGHVGRFXPHQWV&HWWHTXDVLH[SpULHQFHSRU
WDQWVXUXQGHX[RXWURLVGRFXPHQWVSURSUHVDX[SDUWL
FLSDQWVpWDLWFRQVWLWXpHGHGHX[SKDVHV
8QH SKDVH GH ©UDSSHOª H[SORUDQW OD FDUDFWpULVDWLRQ
LQWXLWLYH GHV GRFXPHQWV SDU OHV SDUWLFLSDQWV EDVpH VXU
OHXU PpPRULVDWLRQ &HWWH SKDVH FRPSRUWDLW GHX[ VHV
VLRQV XQH VHVVLRQ GH UDSSHO OLEUH DX FRXUV GH OD
TXHOOH RQ GHPDQGDLW DX[ SDUWLFLSDQWV G
H[SULPHU OHV
SULQFLSDOHV FDUDFWpULVWLTXHV GRQW LOV VH VRXYHQDLHQW j
SURSRVGHVGRFXPHQWVHWXQHVHVVLRQGHUDSSHOLQGL
FpGDQVODTXHOOHRQOHXUGHPDQGDLWV
LOVVHUDSSHODLHQW
G
DWWULEXWVTX
LOVOHXUpWDLHQWSURSRVpVXQSDUXQjSDUWLU
64
UDSSHOHWGHVFRPSRUWHPHQWVREVHUYpVjODSKDVHGHUp
FXSpUDWLRQ
G
XQH OLVWH SUppWDEOLH GH DWWULEXWV &HWWH OLVWH pWDLW
FRQVWLWXpH j SDUWLU GHV SULQFLSDX[ DWWULEXWV UHQFRQWUpV
GDQVODOLWWpUDWXUHGXGRPDLQH3,0HWGHO
HQVHPEOHGHV
DWWULEXWV TXH QRXV DYRQV MXJp SHUWLQHQWV SRXU O
XWLOLVD
WHXUHWGRQFVXVFHSWLEOHVG
rWUHPpPRULVpVSDUFHOXLFL
/HV DWWULEXWV SURSRVpV pWDLHQW ORFDOLVDWLRQ UpSHUWRLUH
pOHFWURQLTXH RX ORFDOLVDWLRQ SK\VLTXH W\SH GH ILFKLHU
RXIRUPDWGHGRFXPHQWQRPGHILFKLHUVHXOHPHQWSRXU
OHVGRFXPHQWVpOHFWURQLTXHVWLWUHVLDSSURSULpWDLOOH
HJ QRPEUH GH SDJHV QRPEUH GH OLJQHV HWF PR
PHQW GH GHUQLqUH XWLOLVDWLRQ PRWVFOHIV pOpPHQWV YL
VXHOV HJ H[LVWHQFH GH JUDSKLTXHV WDEOHV FRXOHXUV
pYqQHPHQWVDVVRFLpVjO¶XWLOLVDWLRQGHVGRFXPHQWVHJ
HPDLO DSSHO WpOpSKRQLTXH HWF OLHQV LH GRFXPHQWV
OLpV GLIIpUHQWHV YHUVLRQV GX GRFXPHQW HW RSpUDWLRQV
LHRSpUDWLRQVHIIHFWXpHVVXUOHGRFXPHQW
Phase de rappel
1RWRQV TXH GDQV O
HQVHPEOH LO Q¶\ D SDV HX G
HIIHW GX
W\SHGHSDUWLFLSDQWVFKHUFKHXUYVDGPLQLVWUDWLIVXUOHV
UpVXOWDWV VDXI SRXU OH UDSSHO GH O
DWWULEXW PRPHQW GH
GHUQLqUHXWLOLVDWLRQ/DSURSRUWLRQGHUDSSHOVFRPSRU
WDQWGHVHUUHXUVpWDLWSOXVpOHYpHFKH]OHVDGPLQLVWUDWLIV
TXHFKH]OHVFKHUFKHXUV'HSOXVWURLVDWWULEXWVRQWIDLW
O
REMHW GH UDSSHOV GpSHQGDQW GH OD UpFHQFH HWRX IUp
TXHQFHG
XWLOLVDWLRQGHVGRFXPHQWVPRWVFOHIVWDLOOHHW
pOpPHQWVYLVXHOV&HVDWWULEXWVpWDLHQWVLJQLILFDWLYHPHQW
RX PDUJLQDOHPHQW SOXV IUpTXHPPHQW RX SOXV H[DFWH
PHQWUDSSHOpVTXDQGOHVGRFXPHQWVDYDLHQWpWpXWLOLVpV
UpFHPPHQWRXpWDLHQWXWLOLVpVGHPDQLqUHUpFXUUHQWHSDU
OHVSDUWLFLSDQWV(QILQQRXVQ
DYRQVSDVREVHUYpGHUH
ODWLRQ HQWUH OH W\SH GHV GRFXPHQWV (OHFWURQLTXH YV
3DSLHU RX &UpH YV 0RGLILp YV &RQVXOWpV HW OHV SHU
IRUPDQFHVjODSKDVHGHUDSSHO
8QH SKDVHGH³UpFXSpUDWLRQ´DXFRXUVGHODTXHOOHRQ
GHPDQGDLWDX[ SDUWLFLSDQWVGHUHWURXYHUOHVGRFXPHQWV
FLEOHV pYRTXpV GDQV OHXU SURSUH HQYLURQQHPHQW DYHF
OHXUVSURSUHVRXWLOV
Fréquence des attributs rappelés. (Q FH TXL
FRQFHUQH OH UDSSHO OLEUH OHV SULQFLSDOHV FDUDFWpULVWL
TXHV GHV GRFXPHQWV H[SULPpHV SDU OHV SDUWLFLSDQWV
pWDLHQWFDUDFWpULVWLTXHVGXFRQWHQXGHVGRFXPHQWV
HJ UpVXPp VWUXFWXUH SRUWLRQV VSpFLILTXHV GH WH[WH
FRPPH OH WLWUH HWF GDQVGHVGHVFULSWLRQVGH
GRFXPHQWVpOpPHQWVYLVXHOVHJH[LVWHQFHGHJUD
SKLTXHVLPDJHVFRXOHXUVHWFW\SHGHIL
FKLHURXIRUPDWGXGRFXPHQWHJWDEOHDX([FHOOL
YUHDXIRUPDW$HWF/HVDWWULEXWVTXLRQW
pWp UDSSHOpV SOXV PDUJLQDOHPHQW pWDLHQW OD WDLOOH LH
QRPEUH GH SDJHV OHV OLHQV LH GRFXPHQWV OLpV DX
GRFXPHQW FLEOH HW O
DXWHXU /H QRPEUH PR\HQ G
DWWUL
EXWV GLIIpUHQWV UDSSHOpV SDU SDUWLFLSDQW Q
pWDLW TXH GH
DWWULEXWV
Matériel
/HFKRL[GHVGRFXPHQWVpWDLWRULHQWpSDUO
H[SpULPHQWD
WHXUVXUODEDVHGHVLQIRUPDWLRQVUHFXHLOOLHVjO
LVVXHGH
O
LQWHUYLHZ VHPLGLULJpH &KDTXH GRFXPHQW VpOHFWLRQQp
FRUUHVSRQGDLW j XQ GRFXPHQW TXL DYDLW pWp XWLOLVp ORUV
G
XQHRFFXUUHQFHG
XQHGHVWkFKHVpYRTXpHVSDUOHSDU
WLFLSDQW HJ OHV GLDSRVLWLYHV GH SUpVHQWDWLRQ XWLOLVpHV
SDUXQSDUWLFLSDQWFKHUFKHXUSRXUXQHGHVHVFRPPXQL
FDWLRQVRUDOHVjXQHFRQIpUHQFH
6XUO
HQVHPEOHGHVGRFXPHQWVFLEOHVVpOHFWLRQQpVLO
\DYDLWGRFXPHQWVSDSLHUVHWGRFXPHQWVpOHFWURQL
TXHV GRFXPHQWV VXU OHV DYDLHQW pWp FUppV SDU
O
XWLOLVDWHXU OXLPrPH GRFXPHQWV DYDLHQW MXVWH pWp
FRQVXOWpV HW DYDLHQW pWp FRQVXOWpV HW PRGLILpV pWDLHQW GHV GRFXPHQWV DQFLHQV TXL DYDLHQW pWp FUppV
FRQVXOWpVRXPRGLILpVLO\DGHPRLVpWDLHQWGHV
GRFXPHQWV UpFHQWV TXL DYDLHQW pWp FUppV FRQVXOWpV RX
PRGLILpVLO\DGHPRLVHWpWDLHQWGHVGRFXPHQWV
UpFXUUHQWV TXL pWDLHQW FRQVXOWpV UpJXOLqUHPHQW /HV
GLIIpUHQWV W\SHV GH GRFXPHQWV VpOHFWLRQQpV RQW pWp ILFKLHUVWH[WH3')HW:RUGSDJHV:HERXHQ
VHPEOH GH SDJHV :HE ILFKLHUV SUpVHQWDWLRQ 3R
ZHU3RLQW69*HPDLOVILFKLHUWDEOHDX([FHO
UpSHUWRLUH:LQGRZVHQVHPEOHVGHIHXLOOHVSDSLHU
DJUDIpHVRXQRQRXYUDJHVSDSLHUHWHQVHPEOHGH
SDJHVGDQVXQFDKLHU
(QFHTXLFRQFHUQHOHUDSSHOLQGLFpDWWULEXWVSDUPL
OHVSURSRVpVRQWpWpUDSSHOpVGDQVWRXVOHVFDVSDU
WRXV OHV SDUWLFLSDQWV HW SRXU WRXV OHV GRFXPHQWV &HV
DWWULEXWVVRQWORFDOLVDWLRQW\SHGHILFKLHURXIRUPDWGH
GRFXPHQWPRPHQWGHGHUQLqUHXWLOLVDWLRQPRWVFOHIVHW
pYqQHPHQWV DVVRFLpV YRLU )LJ /HV DXWUHV DWWULEXWV
Q¶RQWSDVWRXMRXUVpWpUDSSHOpVELHQTX¶LOVIDVVHQWSDU
WLHGHVDWWULEXWVGHVGRFXPHQWV
/HV UpVXOWDWV SUpVHQWpV GDQV OHV VHFWLRQV VXLYDQWHV VH
UDSSRUWHQWDX[GRQQpHVFRQFHUQDQWOHVGHX[VHVVLRQVj
ODIRLVLHFHOOHGHUDSSHOOLEUHHWFHOOHGHUDSSHOLQGL
Fp
RESULTATS
/¶H[DPHQ GHV GRQQpHV D pWp PHQp j SDUWLU G¶DQDO\VHV
TXDQWLWDWLYHVHWTXDOLWDWLYHVGHVUpSRQVHVjODSKDVHGH
7RXWHIRLVO
REMHWSULQFLSDOGHQRWUHpWXGHpWDQWODPp
PRLUHGHVGRFXPHQWVOHSURFHVVXVGHUpFXSpUDWLRQQ
HVW
SDVDQDO\VpLFLGHPDQLqUHILQH
65
pWDLW H[DFWH PDLV O
DXWUH QRQRX ELHQO
LQIRUPDWLRQUDS
SHOpHQ
pWDLWSDVSUpFLVH2QREVHUYHpJDOHPHQWTXHOHV
UDSSHOVOHVPRLQVUREXVWHVFRQFHUQHQWOHVDWWULEXWVWDLOOH
HWPRPHQW
Caractéristiques des rappels partiels. (Q FH TXL
FRQFHUQH OHV PRWV FOHIV WRXV OHV GRFXPHQWV FRQWHQDQW
GXWH[WHRQWIDLWO
REMHWG
XQUDSSHOFRQWHQDQWDXPRLQV
XQ PRWFOHI HIIHFWLYHPHQW SUpVHQW GDQV OH WH[WH GXGR
FXPHQW 0DLV VXU GH FHV UDSSHOV FRQWH
QDLHQW pJDOHPHQW GHV PRWV FOHIV TXL Q
pWDLHQW SDV SUp
VHQWVGDQVOHWH[WH
7L
WUH
7D
LO
0 OH
RP
0 HQ W
(
RW
O
V
( pPH FOH
Yq
QH Q WV I V
Y
P
HQ LV X
HO V
WV
D
VV
RF
Lp
V
/L
HQ
2
Sp
V
UD
WL R
QV
/R
F
7\ D OL V
DW
SH
LR
R
Q
X
IR
UP
DW
1
RP
GHGRFXPHQWV
)LJXUH3RXUFHQWDJHVGHGRFXPHQWVSRXUOHVTXHOVFKDTXH
DWWULEXWDpWpUDSSHOp
Exactitude des attributs rappelés. 4XDQG FHOD pWDLW
SRVVLEOH LH GRFXPHQWV UHWURXYpV RQ D FRPSDUp OHV
DWWULEXWV H[SULPpV DYHF OHV DWWULEXWV HIIHFWLYHPHQW SUp
VHQWVGDQVOHVGRFXPHQWV/HVDWWULEXWVGHGRFXPHQWVj
ODIRLVH[SULPpVHWSUpVHQWVGDQVODSOXSDUWGHVFDVRQW
pWpO¶DWWULEXW³W\SHGHILFKLHURXIRUPDWGHGRFXPHQW´HW
O¶DWWULEXW³pOpPHQWVYLVXHOV´ODSOXSDUWGHVDXWUHVDWWUL
EXWV pWDQW PRLQV RX SDUWLHOOHPHQW UREXVWHV 3DU H[HP
SOHOHVUpVXOWDWVLQGLTXHQWTXHVHXOHPHQWGHVGR
FXPHQWV RQW IDLW O
REMHW GX UDSSHO GH OHXU ORFDOLVDWLRQ
H[DFWHDORUVTXHOHVXWLOLVDWHXUVRQWO
KDELWXGHGHJpUHU
OHXUVGRFXPHQWVGHFHWWHPDQLqUH/H7DEOHDXV\QWKp
WLVH OHV UpVXOWDWV FRQFHUQDQW OD TXDOLWp GX UDSSHO SRXU
FKDTXHDWWULEXWVDXISRXUOHVDWWULEXWVpYqQHPHQWVDVVR
FLpV OLHQV HW RSpUDWLRQV,OHVWWUqVGLIILFLOHHQHIIHWGH
YpULILHUO
H[DFWLWXGHGHFHX[FLFDULOVFRQFHUQHQWOHVUH
ODWLRQVH[LVWDQWHQWUHOHGRFXPHQWHWVRQHQYLURQQHPHQW
O
XWLOLVDWHXUOHVWkFKHVOHVDXWUHVGRFXPHQWVHWFUHOD
WLRQVTXLODLVVHQWUDUHPHQWGHVWUDFHVGDQVOHV\VWqPH
/D WDLOOH HW OH PRPHQW GH GHUQLqUH XWLOLVDWLRQ RQW VRX
YHQWIDLWO
REMHWG
XQHDSSUR[LPDWLRQMXVWHHJHQWHU
PHV G
LQWHUYDOOHV HQWUH HW SDJHV SpULRGHV HQ)pYULHUHWFPDLVUDUHPHQWSUpFLVpPHQWLH
HQUDSSHODQWXQQRPEUHH[DFWGHSDJHVRXXQMRXUSUp
FLV 3DU H[HPSOH SDUPL OHV GRFXPHQWV GRQW RQ D SX
YpULILHUODGDWHH[DFWHGHGHUQLqUHXWLOLVDWLRQXQVHXOD
IDLWO
REMHWG
XQUDSSHOH[DFWDXMRXUSUqV
Caractéristiques des rappels erronés. &RQFHUQDQW
OHV DWWULEXWVGHWDLOOHHWGHPRPHQWGHGHUQLqUHXWLOLVD
WLRQQRXVDYRQVUHPDUTXpTXHODGLVWDQFHHQWUHOHUDS
SHO HW OD YpULILFDWLRQ pWDLW VRXYHQW SURSRUWLRQQHOOH DX
QRPEUH GH SDJHV H[SULPpHV RX DX WHPSV pFRXOp (Q
G
DXWUHV WHUPHV OHV UDSSHOV HUURQpV Q
pWDLHQW SDV WURS
pORLJQpVGHODUpDOLWp3DUH[HPSOHFRQFHUQDQWODWDLOOH
XQ SDUWLFLSDQW D GLW HQYLURQ SDJHV SRXU XQ GRFX
PHQWTXLHQFRQWHQDLWHQIDLW'HSOXVO
pFDUWHQWUH
OHQRPEUHUDSSHOpHWOHQRPEUHUpHOpWDLWSURSRUWLRQQHO
jODJUDQGHXUGXQRPEUHUDSSHOpODFRUUpODWLRQHVWSR
VLWLYHU S(QFHTXLFRQFHUQHOH
UDSSHO GX PRPHQWOHVHUUHXUVFRPPLVHVO
RQWpWpDYHF
XQHPDUJHG
HUUHXUDOODQWG¶XQMRXUjVL[PRLVPDLVOD
SOXSDUWpWDLHQWLQIpULHXUHVjGHX[PRLV7RXVOHVUDSSHOV
HUURQpV FRPPLVORUVG
XQHHVWLPDWLRQHQWHUPHVGHMRXU
pWDLHQWIDX[jXQMRXUSUqV/HVpFDUWVHQWUHOHVHVWLPD
WLRQV HQ WHUPHV GH PRLV HW OD UpDOLWp DOODLHQW GH GHX[
VHPDLQHV j GHX[ PRLV 8QH HUUHXU D pWp FRPPLVH ORUV
G
XQHHVWLPDWLRQHQWHUPHVG
DQQpHHOOHpWDLWIDXVVHGH
PRLV/
pFDUWHQWUHOHUDSSHOHWODUpDOLWppWDLWGRQFOD
DXVVL SURSRUWLRQQHO DX GHJUp GH SUpFLVLRQ GH O
HVWLPD
WLRQ
7DEOHDX3RXUFHQWDJHVGHVGRFXPHQWVSRXUOHVTXHOVOH
UDSSHOFRQFHUQDQWFKDTXHDWWULEXWpWDLWWRWDOHPHQWH[DFWSDU
WLHOOHPHQWH[DFWRXWRWDOHPHQWIDX[
/RFDOLVDWLRQ
7\SHRXIRUPDW
5DSSHOSDU
5DSSHO
WRWDOHPHQW WLHOOHPHQW
H[DFW
H[DFW
5DSSHO
WRWDOHPHQW
IDX[
1RP
7LWUH
7DLOOH
0RPHQW
0RWVFOHIV
eOpPHQWVYLVXHOV
/D ORFDOLVDWLRQ UDSSHOpH Q
pWDLW VRXYHQW FRUUHFWH TXH
MXVTX
j XQ FHUWDLQ SRLQW LH XQH SDUWLH VHXOHPHQW GX
FKHPLQ RX GH OD ORFDOLVDWLRQ pWDLW FRUUHFWHPHQW UDSSH
OpH 3RXU OHV GRFXPHQWV pOHFWURQLTXHV FH VRQW OHV FDV
R OH GpEXW GX FKHPLQ OH RX OHV SUHPLHUVUpSHUWRLUHV
pWDLWSDUIDLWHPHQWUDSSHOpPDLVSDVODILQGXFKHPLQOH
RXOHVGHUQLHUVUpSHUWRLUHV 3RXUOHVGRFXPHQWVSDSLHU
OHV UDSSHOV SDUWLHOOHPHQW H[DFWV pWDLHQW FHX[ SRXU OHV
TXHOV XQH ORFDOLVDWLRQ pWDLW IRXUQLH HJ XQ FDUWRQXQ
FDKLHUXQHSLOHHWFPDLVRO
HPSODFHPHQWjO
LQWpULHXU
PrPHGHFHWWHORFDOLVDWLRQQ
pWDLWSDVSUpFLVp
2Q SHXW FRQVWDWHU TX
XQ SRXUFHQWDJH WUqV LPSRUWDQW GH
UDSSHOV G
DWWULEXWV HVW HQ IDLW SDUWLHOOHPHQW H[DFW HJ
PRWVFOHIV QRP HWF F
HVWjGLUH TX
XQH SDUWLH VHXOH
PHQW GHV LQIRUPDWLRQV UDSSHOpHV SDU OHV SDUWLFLSDQWV
66
WURQLTXH O
HQYRL HW OH GpSODFHPHQW FKDQJHPHQW GH
O
HPSODFHPHQWGXGRFXPHQW
Moyens d’expressions utilisés.'HVUpVXOWDWVTXDOLWD
WLIV RQW pWp REWHQXV VXU OHV GLIIpUHQWV PR\HQV HW W\SHV
G
XQLWpV GH YDULDEOH XWLOLVpV SDU OHV LQGLYLGXV SRXU H[
SULPHU OHV DSSUR[LPDWLRQV GH WDLOOH HW GH WHPSV HJ
HQWUH HW SDJHV HQ )pYULHU HWF(QFH
TXL FRQFHUQH OD WDLOOH GDQV XQ SHX PRLQV GH OD PRLWLp
GHVFDVVXUOHVSDUWLFLSDQWVRQWHQIDLWUpSRQGXj
ODTXHVWLRQHQGRQQDQWXQQRPEUHH[DFWDORUVTXHGDQV
XQSHXSOXVGHODPRLWLpGHVFDVVXULOVRQWIDLW
XQH DSSUR[LPDWLRQ /HV DSSUR[LPDWLRQV pWDLHQW GH GLI
IpUHQWV W\SHV 'DQV GHV FDV OHV SDUWLFLSDQWV
GRQQDLHQWXQFKLIIUHURQGDFFRPSDJQpG
XQHIRUPHOLQ
JXLVWLTXH PDUTXDQW O
DSSUR[LPDWLRQ HJ XQH DLQH
GH WUDQVSDUHQWV HQYLURQ SDJHV /D GHX[LqPH
DSSUR[LPDWLRQODSOXVXWLOLVpHpWDLWODVSpFLILFDWLRQG¶XQ
LQWHUYDOOH HJ HQWUH HW SDJHVpFUDQV GDQV
GHV FDV &RQFHUQDQW OH PRPHQW OHV GDWHV RQW
pWp OH SOXV VRXYHQW IRUPXOpHV VRXV IRUPH GH SpULRGHV
GDQVGHVFDV(QIRQFWLRQGXGHJUpGHSUpFL
VLRQOHVSpULRGHVpWDLHQWH[SULPpHVHQWHUPHVG
DQQpH
VHPHVWUHVDLVRQPRLVVHPDLQHMRXUGHPLMRXUQpHRX
KHXUH/HVSpULRGHVRQWpWpWUqVPDMRULWDLUHPHQWIRUPX
OpHVDXPRLVSUqVHJHQIpYULHU/DGHX[LqPH
PDQLqUH GH GRQQHU XQH GDWH pWDLW XQH HVWLPDWLRQ GX
WHPSV pFRXOp SDU UDSSRUW DX WHPSV SUpVHQW VRXV OD
IRUPHLO\D«HJLO\DGHX[PRLVLO\DXQH
TXLQ]DLQHGHMRXUVGDQVGHVFDV
(Q FH TXL FRQFHUQH OHV pYqQHPHQWV DVVRFLpV GHV LQIRUPDWLRQV UDSSHOpHV SHXW rWUH PLV HQ UHODWLRQ
DYHF XQH WUDFH pOHFWURQLTXH SURGXLWH SDU OH RX OHV
pYqQHPHQWVGXFRQWH[WH3DUFRQWUHGHVLQIRU
PDWLRQV UDSSHOpHV Q
D SURGXLW DXFXQH WUDFH 7RXWHV OHV
WUDFHVSURGXLWHVVRQWHQIDLWGHVPDLOVUHoXVRXHQYR\pV
SDU O
XWLOLVDWHXUHWTXLVRQWOLpVDX[ EXWVGHO
XWLOLVDWLRQ
GX GRFXPHQW HW FRUUHVSRQGHQW SRXU OD SOXSDUW j GHV
pFKDQJHVGHPDLOVDYHFGHVFROODERUDWHXUV8QSHXSOXV
GHODPRLWLpGHVWUDFHVPDLOVpWDLWHQFRUHSUpVHQWHVXU
OD PDFKLQH GHV SDUWLFLSDQWV WDQGLV TX
XQ SHX PRLQV GH
ODPRLWLppWDLWDEVHQWHGDQVODSOXSDUWGHVFDVSDUFHTXH
OH SDUWLFLSDQWOHVDYDLWVXSSULPpHV/HVpYqQHPHQWVGX
FRQWH[WHFLWpVSDUOHVSDUWLFLSDQWVPDLVQ
D\DQWSDVODLV
VpGHWUDFHVpWDLHQWHQSUHPLHUOLHXGHVFRPPXQLFDWLRQV
GLUHFWHVRUDOHVRXWpOpSKRQLTXHVHQWUHOHSDUWLFLSDQWHW
GHVFROODERUDWHXUVSURFKHVRXQRQ
(Q FH TXL FRQFHUQH OHV OLHQV VXU O
HQVHPEOH GHVGRFX
PHQWV OLpV DX[ GRFXPHQWV SULQFLSDX[ UDSSHOpV 1 OD PDMRULWp 1 pWDLW HIIHFWLYHPHQW SUpVHQWH
GDQV OH V\VWqPH SRXU OHV GRFXPHQWV pOHFWURQLTXHV RX
GDQV OH EXUHDX SRXU OHV GRFXPHQWV SDSLHUV /HV GRFX
PHQWV UDSSHOpV pWDLHQW OLpV DX GRFXPHQW FLEOH OH SOXV
VRXYHQWSDUFHTX
LOVSDUWLFLSDLHQWjODPrPHWkFKHRXDX
PrPH W\SH GH WkFKH /D SOXSDUW GHV GRFXPHQWV FLEOHV
VXUDYDLWDXPRLQVXQGRFXPHQWOLpUDSSHOpGRQW
OH OLHQ Q
pWDLW SDV VHXOHPHQW DEVWUDLW LH GH FRQWHQX
RXGHIRQFWLRQPDLVpJDOHPHQWFRQFUHWLHG
DFWLRQ
RXGHORFDOLVDWLRQHWGRQFSRWHQWLHOOHPHQWH[SORLWDEOHV
SDUXQV\VWqPH$LQVLGHVGRFXPHQWVOLpVUDSSH
OpV HW SUpVHQWV SDUWDJHDLW OD PrPH ORFDOLVDWLRQ TXH OH
GRFXPHQW FLEOH GDQV OH PrPH GRVVLHU SRXUOHVGRFX
PHQWVpOHFWURQLTXHVHWGDQVOHPrPHGRVVLHURXGDQVOD
PrPHSLOHSRXUOHVGRFXPHQWVSDSLHU/HVDXWUHVW\SHV
GH OLHQV pYRTXpV pWDLHQW OH FRSLHUFROOHU HQWUDQW RX
VRUWDQW OH OLHQ K\SHUWH[WH HQWUDQW RX VRUWDQW OD YHU
VLRQDQWpULHXUHRXSRVWpULHXUHHWF
(QFHTXLFRQFHUQHO
H[SUHVVLRQGXW\SHGHVILFKLHUVLO
IDXWQRWHUTXHOHVXWLOLVDWHXUVQHIRUPXODLHQWSDVVHXOH
PHQW OH W\SH GH OHXUV GRFXPHQWV GX SRLQW GH YXH GX
V\VWqPH PDLV pJDOHPHQW G
XQ SRLQW GH YXH VpPDQWLTXH
GH SOXV KDXW QLYHDX HJ XQH SUpVHQWDWLRQ 3RZHU
3RLQW XQ WDEOHDX ([FHO XQH LPDJH VRXV :RUG
XQHQVHPEOHGHVOLGHVHWF
Types d'informations rappelées. &RQFHUQDQW OHV pOp
PHQWV YLVXHOV OHV GLIIpUHQWHV FDWpJRULHV G
LQIRUPDWLRQV
UDSSHOpHVpWDLHQWGX SOXVIUpTXHQWDXPRLQVIUpTXHQW
ODFRXOHXUHJWLWUHYHUWNDNLSXFHVURXJHERUGHDX[
IRQG EODQF FRXYHUWXUH EOHX FLHO OH IRUPDW HW OD
PLVH HQ SDJH HJ GRXEOH FRORQQH WLWUH HQ JURV
WDEOH GHV PDWLqUHV OD SUpVHQFH G
REMHWV DXWUHV TXH
GX WH[WH JUDSKLTXHV LPDJHV WDEOHDX[« HW GHV JUD
SKLVPHVIDLVDQWSDUWLHGHODPLVHHQSDJHHQWrWHEDQ
GHDX[WUDLWV«8QUpVXOWDWLQWpUHVVDQWHVWTXHOHVpOp
PHQWV UDSSHOpV QH FRQFHUQDLHQW SDV VHXOHPHQW OD SUH
PLqUHSDJHGXGRFXPHQWVHXOHPHQWGHWRXWHVOHV
GHVFULSWLRQVFRPSUHQDLHQWXQLTXHPHQWGHVpOpPHQWVYL
VXHOVGHODSUHPLqUHSDJH
Phase de récupération des documents
3RXU OHV GRFXPHQWV pOHFWURQLTXHV OD PpWKRGH OD SOXV
XWLOLVpH SDU OHV SDUWLFLSDQWV SRXU UHWURXYHU OHXUV GRFX
PHQWVpWDLWOH SDUFRXUVGDQVODKLpUDUFKLHGHVUpSHUWRL
UHV MXVTX
DX UpSHUWRLUH FHQVp FRQWHQLU OH ILFKLHU FLEOH
SXLVODUHFKHUFKHYLVXHOOHGXGRFXPHQWFLEOHSDUPLWRXV
OHVGRFXPHQWVGXUpSHUWRLUH6HXOXQSDUWLFLSDQWDXWLOL
VpODIRQFWLRQUHFKHUFKHUGHVRQ26SDUFHTX
LOQ
DUUL
YDLWSDVjUHWURXYHUOHERQGRVVLHU(QFHTXLFRQFHUQH
OHVGRFXPHQWVSDSLHUODPpWKRGHODSOXVFODVVLTXHpWDLW
ODORFDOLVDWLRQG
XQHQGURLWGRQQpGXEXUHDXGDQVOHTXHO
OHGRFXPHQWpWDLWFHQVpVHWURXYHUSXLVO
H[DPHQUDSLGH
GHVGLIIpUHQWVGRFXPHQWVSUpVHQWVjFHWHQGURLWSRXUUH
WURXYHU OH GRFXPHQW FLEOH 'DQV OHV GHX[ GRPDLQHV
SK\VLTXHHWpOHFWURQLTXHODUHFKHUFKHGHVGRFXPHQWV
3RXUOHVRSpUDWLRQVXQW\SHG
LQIRUPDWLRQIUpTXHPPHQW
UDSSHOp pWDLW OD PRGLILFDWLRQ GX GRFXPHQW HJ QRX
YHOOH YHUVLRQ G
XQ GRFXPHQW UHPSOLVVDJH GHV FKDPSV
G
XQ IRUPXODLUH pOHFWURQLTXH pFULWXUHG
DQQRWDWLRQVVXU
XQGRFXPHQWSDSLHU7URLVDXWUHVW\SHVG
DFWLRQVDVVH]
IUpTXHQWHVpWDLHQWO
LPSUHVVLRQSRXUXQGRFXPHQWpOHF
67
WDLQHVpWXGHVVRXOLJQHQWODSHUWLQHQFH>@>@VRQWGHV
DWWULEXWV TXL DXUDLHQW pJDOHPHQW PpULWpV GH IDLUH SDUWLH
GHQRWUHOLVWHLQGLFpH0DOJUpFHVOLPLWHVQRVUpVXOWDWV
DX[VHVVLRQVGHUDSSHOIRXUQLVVHQWGHVLQIRUPDWLRQVVXU
OHVGLIIpUHQWVDWWULEXWVGRQWOHVXWLOLVDWHXUVVRQWFDSDEOHV
GHVHUDSSHOHU&HODFRQGXLWHQUHWRXUjGHVUHFRPPDQ
GDWLRQV SRWHQWLHOOHV VXU OD PDQLqUH GRQW FHV GLIIpUHQWV
DWWULEXWV SRXUUDLHQW rWUH H[SORLWpV SDU OHV IXWXUV V\VWq
PHV GH UpFXSpUDWLRQ GH GRFXPHQWV &HV UHFRPPDQGD
WLRQVSRWHQWLHOOHVVRQWSUpVHQWpHVFLGHVVRXV
FRPSRUWDLW GRQF GHX[ SKDVHV XQH SKDVH GH ORFDOLVD
WLRQEDVpHVXUOHUDSSHOHWXQHSKDVHGHEDOD\DJHYLVXHO
EDVpH VXU OD UHFRQQDLVVDQFH &H UpVXOWDW HVW FRKpUHQW
DYHFODSURSRVLWLRQGH/DQVGDOH>@TXHFKDTXHWHQWD
WLYHGHUpFXSpUDWLRQG¶LQIRUPDWLRQVLPSOLTXHGHX[SUR
FHVVXV SV\FKRORJLTXHV GLVWLQFWV OD UHFKHUFKH GLULJpH
SDU OH UDSSHO UHFDOOGLUHFWHG VHDUFK VXLYLH GX ED
OD\DJH EDVp VXU OD UHFRQQDLVVDQFH UHFRJQLWLRQEDVHG
VFDQQLQJ
&LQT SDUWLFLSDQWVQ
RQWSDVUpXVVLjUHWURXYHUXQGRFX
PHQW FHOD FRQFHUQDLW GRFXPHQWV SDSLHUV HW GRFX
PHQW pOHFWURQLTXH 6XU OHV GRFXPHQWV UHWURXYpV Q
RQW SDV pWp UHWURXYpV IDFLOHPHQW GRQW SDSLHUV HW pOHFWURQLTXHV'DQVODSOXSDUWGHVFDVVXUVHXOHOD
SKDVH GH UHFKHUFKH GLULJpH SDU OH UDSSHO SRVDLW SUR
EOqPHOH SDUWLFLSDQWFKHUFKDLWGDQVOHPDXYDLVUpSHU
WRLUH RX OH PDXYDLV HPSODFHPHQW 'DQV XQ FDV F
HVW
VHXOHPHQWODSKDVHGHUHFKHUFKHEDVpHVXUODUHFRQQDLV
VDQFH TXL pWDLW GLIILFLOH OH GRFXPHQWFLEOHVHWURXYDLW
ELHQ j O
HQGURLW UHFKHUFKp PDLV LO GHYDLW rWUH UHFRQQX
SDUPL GH QRPEUHX[ FDQGLGDWV LH UHWURXYHU XQ PDLO
GDQVXQGRVVLHU'DQVOHVGHX[FDVUHVWDQWOHVSDUWLFL
SDQWVRQWpSURXYpGHVGLIILFXOWpVGXUDQWOHVGHX[SKDVHV
GHUHFKHUFKH
DISCUSSION
CONCEPTION
ET
IMPLICATIONS
POUR
Favoriser les attributs appropriés
/HV DWWULEXWV TXL VRQW OHV SOXV VRXYHQW HWRX OHV PLHX[
UDSSHOpVF
HVWjGLUHOHW\SHRXIRUPDWOHVpOpPHQWVYL
VXHOVOHVPRWVFOHIVOHVpYqQHPHQWVDVVRFLpVODORFDOL
VDWLRQ HW OH PRPHQW GH GHUQLqUH XWLOLVDWLRQ GHYUDLHQW
rWUHXWLOLVpVHQSULRULWpGDQVOHVRXWLOVGHUHFKHUFKH/H
FRQWHQX PRWVFOHIV HVW OH VHXO DWWULEXW TXL D WRXMRXUV
GRQQpOLHXjXQUDSSHOGHOD SDUWGHV SDUWLFLSDQWVHWOH
UDSSHO FRQWHQDLW WRXMRXUV DX PRLQV XQ pOpPHQW LH XQ
PRWHIIHFWLYHPHQWSUpVHQWGDQVOHGRFXPHQW&HUpVXO
WDWHQFRXUDJHO
XWLOLVDWLRQGHPRWHXUVGHUHFKHUFKHVXU
OHEXUHDX/HW\SHRXIRUPDWTXDQWjOXLHVWjODIRLV
XQGHVDWWULEXWVTXLDWRXMRXUVFRQGXLWjXQUDSSHOHWFH
OXL GRQW OH UDSSHO HVW OH SOXV ILDEOH LO D OH SOXV IRUW
SRXUFHQWDJH GH UDSSHOV WRWDOHPHQW H[DFWV ,O GHYUDLW
GRQFILJXUHUHQSUHPLqUHSODFHGDQVOHVRSWLRQVGHILOWUH
HWRXGHWULGHVRXWLOVGHUHFKHUFKH(QILQOHVUpVXOWDWV
PRQWUHQWTXHOHVXWLOLVDWHXUVVHUDSSHOOHQWSUHVTXHWRX
MRXUVG
pOpPHQWVYLVXHOV SUpVHQWVGDQVOHXUVGRFXPHQWV
HWTX
LOVVHWURPSHQWWUqVUDUHPHQWjFHVXMHW8QHSUp
VHQWDWLRQ G
XQ DSHUoX GH O
DVSHFW GX GRFXPHQW OXL
PrPHHQSOXVGHODVLPSOHSUpVHQWDWLRQGHO
LF{QHFRU
UHVSRQGDQW DX W\SH GX GRFXPHQW DSSDUDvW GRQF SHUWL
QHQWHSRXUIDFLOLWHUODUHFRQQDLVVDQFHGHVGRFXPHQWV\
FRPSULVFHOOHGHVGRFXPHQWVWH[WXHOV
LA
/HVUpVXOWDWVGHODSKDVHGHUpFXSpUDWLRQFRQILUPHQWOH
IDLWTXHOHVXWLOLVDWHXUVRQWVRXYHQWGHVGLIILFXOWpVjUH
WURXYHU OHXUV GRFXPHQWV GDQV OHXU HQYLURQQHPHQW DF
WXHO DYHF OHV RXWLOV GRQW LOV GLVSRVHQW 1RXV DYRQV YX
TXHF
HVWODSUHPLqUHSKDVHGHUHFKHUFKHTXLVHPEOHSR
VHUOHSOXVGHSUREOqPHV&HWWHSKDVHpWDQWEDVpHSULQ
FLSDOHPHQW VXU XQ SURFHVVXV FRJQLWLI GH UDSSHO OHV Up
VXOWDWVTXHQRXVDYRQVUHFXHLOOLVFRQFHUQDQWFHSURFHV
VXV HW OHV LPSOLFDWLRQV TXHO
RQ SHXWHQWLUHUVRQWGRQF
VXVFHSWLEOHV G
DLGHU OHV XWLOLVDWHXUV j PLHX[ UHWURXYHU
OHXUVGRFXPHQWV'HSOXVLODSSDUDvWTXHOHVVWUDWpJLHV
XWLOLVpHV SDU OHV XWLOLVDWHXUV SRXU UHWURXYHU OHXUV GRFX
PHQWVQ
RQWSDVH[SORLWpODYDULpWpGHVDWWULEXWVGRQWLOV
VRQWFDSDEOHVGHVHUDSSHOHUGXUDQWODSKDVHGHUDSSHO
LQGLFpHHWODIRQFWLRQQDOLWpGHUHFKHUFKHVXUOHEXUHDX
HVW WUqV SHX XWLOLVpH &HOD YD GDQV OH VHQV G
XQ EHVRLQ
SRXU GHV RXWLOV GH UHFKHUFKH SOXV SHUIRUPDQWV SRXU OD
UpFXSpUDWLRQGHVGRFXPHQWVSHUVRQQHOV
Favoriser les expressions appropriées
/HV PR\HQV G
H[SULPHU OH PRPHQW GH GHUQLqUH XWLOLVD
WLRQOHVSOXVXWLOLVpVVRQWODVSpFLILFDWLRQG
XQHSpULRGH
XQ PRLV GDQV OD SOXSDUW GHV FDV HJ HQ IpYULHU
HW O
LQIRUPDWLRQ UHODWLYH DX WHPSV pFRXOp HJ
LO \ D GHX[ PRLV &HV PR\HQV G
H[SUHVVLRQV GH
YUDLHQWGRQFrWUHXWLOLVpVHQSULRULWpSDUOHVV\VWqPHVGH
UHFKHUFKH3RXUO
H[SUHVVLRQGHODWDLOOHFHVRQWOHVDG
YHUEHV G
DSSUR[LPDWLRQ HJ HQYLURQ SDJHV HW
OHV LQWHUYDOOHV HJ HQWUH HW SDJHV TXL GH
YUDLHQWrWUHIDYRULVpVSDUOHVRXWLOVGHUHFKHUFKH(QFH
TXLFRQFHUQHO
H[SUHVVLRQGXW\SHOHVRXWLOVGHUHFKHU
FKpGHYUDLHQW SHUPHWWUHDX[XWLOLVDWHXUVGHILOWUHUHWRX
WULHU OHV GRFXPHQWV HQ XWLOLVDQW GHV FDWpJRULHV GH KDXW
QLYHDXTXLRQWGXVHQVSRXUHX[HJXQHSUpVHQWDWLRQ
XQWDEOHDXHWFHWQRQSDVVHXOHPHQWFHOOHVGXV\VWqPH
HJSSW[OVHWF
4XDQGRQGHPDQGDLWDX[SDUWLFLSDQWVGHGLUHFHGRQWLOV
VH VRXYHQDLHQW j SURSRV GH OHXUV GRFXPHQWV SHX GH
FKRVHV pWDLHQW UDSSHOpHV VSRQWDQpPHQW OD SOXSDUW GHV
DWWULEXWVUDSSHOpVRQWGRQFpWpLQGXLWVSDUO
H[SpULPHQ
WDWHXUFHTXLOLPLWHQRVUpVXOWDWVDX[DWWULEXWVTXHQRXV
DYRQV MXJpV LPSRUWDQWV /H EXW GX GRFXPHQW TXL QH
IDLWSDVSDUWLHGHQRVUpVXOWDWVSRXUGHVUDLVRQVPpWKR
GRORJLTXHV O
DWWULEXW DXWHXU GX GRFXPHQW TXL D VRX
YHQW pWp UDSSHOp GH PDQLqUH LQFLGHQWH SDU OHV SDUWLFL
SDQWVHWOHVLQGLYLGXVDVVRFLpVDX[GRFXPHQWVGRQWFHU
Prévoir de la flexibilité dans les requêtes
/H IDLW TXH OHV XWLOLVDWHXUV VRLHQW FDSDEOHV GH UDSSHOHU
GHV PRWVFOHIV GH OHXUV GRFXPHQWV HQFRXUDJH O
XWLOLVD
68
WLRQ GH PRWHXUV GH UHFKHUFKH VXU OH EXUHDX 0DLV
FHX[FLGHYUDLHQWSUHQGUHHQFRPSWHOHIDLWTXHOHVXWL
OLVDWHXUV QH UDSSHOOHQW SDV VHXOHPHQW GHV PRWVFOHIV
H[DFWVPDLVDXVVLGHVPRWVFOHIVHUURQpVSRXUOHPrPH
GRFXPHQW HJ SHUPHWWUH O
XWLOLVDWLRQ GH SOXVLHXUV
FKDPSV GH UHTXrWH WH[WXHOOH DYHF GHV RSWLRQV G
DFWLYD
WLRQGpVDFWLYDWLRQSRXUFKDTXHFKDPSIRXUQLUGHVVXJ
JHVWLRQVSRXUGHVV\QRQ\PHVHWGHVK\SHURQ\PHVHWF
(QFHTXLFRQFHUQHO
XWLOLVDWLRQGHVDWWULEXWVGHWDLOOHHW
GHPRPHQWRQSHXWUHFRPPDQGHUGHIRXUQLUGLIIpUHQWV
W\SHVG
XQLWpVHJQRPEUHGHSDJHVQRPEUHGHOLJQHV
HWF DQQpH PRLV VHPDLQH HWF HW GLIIpUHQWV PR\HQV
G
H[SULPHUOHVDSSUR[LPDWLRQVHJHQWUH«HW«SD
JHV HQYLURQ « SDJHV HWF LO \ D« GXUDQW OD
SpULRGH GH« HWF SRXU V
DGDSWHU j OD YDULDELOLWp GHV
H[SUHVVLRQVGHVXWLOLVDWHXUV
Exploiter les relations explicites entre les documents
(WDQW GRQQp TXH OHV XWLOLVDWHXUV VRQW FDSDEOHV GH VH
UDSSHOHUGHGRFXPHQWVDVVRFLpVDXGRFXPHQWUHFKHUFKp
OHVV\VWqPHVGHUHFKHUFKHGHYUDLHQWrWUHFDSDEOHVG
HQ
UHJLVWUHU FHV DVVRFLDWLRQV SRXU TXH O
XWLOLVDWHXU SXLVVH
UHWURXYHU XQGRFXPHQWHQ SDUWDQWG
XQGRFXPHQWDVVR
FLp GpMj UHWURXYp HJ SHUPHWWUH OD UpFXSpUDWLRQ G
XQ
ILFKLHU HQ PRQWUDQW OHV UHODWLRQV GH FRSLHUFROOHU HQWUH
OHVILFKLHUVUpGXLUHODGLVWDQFHHQWUHOHVV\VWqPHVG
RU
JDQLVDWLRQ GHV ILFKLHUV HW GHV PDLOV SRXU IDFLOLWHU O
H[
SORLWDWLRQGHOHXUVUHODWLRQVSRXUODUpFXSpUDWLRQ
Fournir les logs de certaines opérations effectuées
sur les documents
(WDQW GRQQp TXH OHV XWLOLVDWHXUV VRQW FDSDEOHV GH VH
UDSSHOHUGHVRSpUDWLRQVTX
LOVRQWHIIHFWXpVXUXQGRFX
PHQWDXWUHVTXHO
RXYHUWXUHHWODPRGLILFDWLRQOHVV\V
WqPHVGHUHFKHUFKHGHYUDLHQWrWUHFDSDEOHVG
HQUHJLVWUHU
FHVRSpUDWLRQVHWGHSHUPHWWUHOHXUXWLOLVDWLRQFRPELQpH
j G
DXWUHV DWWULEXWV GH ILFKLHUV SRXU OD UpFXSpUDWLRQ GH
ILFKLHU HJ UHFKHUFKH G
XQ GRFXPHQW LPSULPp HQ )p
YULHU
Permettre l'extensibilité des résultats
&RQFHUQDQWO
DWWULEXWGHODORFDOLVDWLRQpWDQWGRQQpTXH
OHV XWLOLVDWHXUV VH UDSSHOOHQW SOXV IDFLOHPHQW GHV GRV
VLHUV SDUHQWV TXH GHV GHUQLHUV VRXVGRVVLHUV FRQWHQDQW
HIIHFWLYHPHQW OH GRFXPHQW UHFKHUFKp OHV V\VWqPHV GH
YUDLHQW IRXUQLU XQH YLVXDOLVDWLRQ SRXU pWHQGUH OD YXH
FODVVLTXH GX FRQWHQX GHV UpSHUWRLUHV HJ ILFKLHUV FD
FKpV GDQV OHV VRXVGRVVLHUV HWF 3RXU FH TXL HVW GH
O
DWWULEXW WHPSV OH V\VWqPH GHYUDLW IRXUQLU GHV PR\HQV
G
pWHQGUH OHV UpVXOWDWV GH OD SUHPLqUH HVWLPDWLRQ H[SUL
PpHSDUOHVXWLOLVDWHXUVpWDQWGRQQpTXHOHXUUDSSHOHVW
VRXYHQW DSSUR[LPDWLI /
H[WHQVLELOLWp GHYUDLW rWUH SUR
SRUWLRQQHOOH DX W\SH G
XQLWp GH WHPSV H[SULPp HJ VL
O
XWLOLVDWHXU VSpFLILH XQH SpULRGH G
XQ PRLV OH V\VWqPH
GHYUDLW SHUPHWWUH GH YLVXDOLVHU IDFLOHPHQW DXVVL OHV IL
FKLHUVTXLRQWpWpXWLOLVpVGXUDQWOHVPRLVDGMDFHQWV(Q
FHTXLFRQFHUQHODWDLOOHpWDQWGRQQpTXHOHUDSSHOGHV
XWLOLVDWHXUVHVWVRXYHQWDSSUR[LPDWLIOHV\VWqPHGHYUDLW
GRQQHUODSRVVLELOLWpGHYLVXDOLVHUDXVVLOHVILFKLHUVTXL
RQW SOXV RX PRLQV OD PrPH WDLOOH TXH FHOOH VSpFLILpH
QRVUpVXOWDWVVXJJqUHQWTX
XQHWROpUDQFHjO
HUUHXUG
HQ
YLURQ VHUDLW VRXKDLWDEOH 'DQV QRWUH FDV O
LPSOp
PHQWDWLRQG
XQHWHOOHWROpUDQFHDXUDLWUHFRXYHUWSOXVGH
ODPRLWLpGHVUHMHWVGHGRFXPHQWVG
XQHUHFKHUFKHEDVpH
VXUOHWHPSV
Permettre la combinaison semi-automatique d'attributs
/D FRQFHSWLRQ G
RXWLOV GH UpFXSpUDWLRQ GH GRFXPHQWV
SRXUUDLWH[SORLWHUOHIDLWTXHOHUDSSHOGHFHUWDLQVDWWUL
EXWV GpSHQG GH OD UpFHQFH HWRXIUpTXHQFHG
XWLOLVDWLRQ
GXGRFXPHQW/HV\VWqPHSRXUUDLWHQFRXUDJHUFHUWDLQHV
DVVRFLDWLRQV G
DWWULEXWVGXUDQWODVSpFLILFDWLRQGHODUH
FKHUFKHHWHQGpFRXUDJHUG
DXWUHV3DUH[HPSOHVLO
XWL
OLVDWHXU VSpFLILH XQH GDWH GH GHUQLqUH XWLOLVDWLRQ UHODWL
YHPHQW DQFLHQQH HJ SOXV GH VL[ PRLV OH V\VWqPH
SRXUUDLW VXJJpUHU G
HQULFKLU OD UHFKHUFKH DYHF OHVDWWUL
EXWVGRQWOHUDSSHOQ
HVWSDVGpSHQGDQWGXWHPSVHJ
W\SHQRPORFDOLVDWLRQHWFSDURSSRVLWLRQjFHX[GRQW
OHUDSSHOVHGpWpULRUHDYHFOHWHPSVpFRXOpHJWDLOOH
pOpPHQWVYLVXHOV
CONCLUSION
7RXW G
DERUG ORUVTX
RQ GHPDQGDLW DX[ SDUWLFLSDQWV GH
UHWURXYHUOHXUVGRFXPHQWVLOVQ
RQWXWLOLVpTX
XQSH
WLWVRXVHQVHPEOHGHVDWWULEXWVGRQWLOVpWDLHQWFDSDEOHV
GH VH UDSSHOHU HW LOV RQW VRXYHQW HX GHV GLIILFXOWpV j
WURXYHUOHXUVGRFXPHQWVDYHFOHVRXWLOVGRQWLOVGLV
SRVHQWFRXUDPPHQW&HODYDGDQVOHVHQVG
XQEHVRLQGH
QRXYHDX[ RXWLOV GH UpFXSpUDWLRQ 'H SOXV OHV UpVXOWDWV
LQGLTXHQWTXHOVVRQWOHVDWWULEXWVGHGRFXPHQWVTXLVRQW
OH SOXV VRXYHQW UDSSHOpV HJ PRWVFOHIV PDLV DXVVL
FHX[ TXL VRQW OH PLHX[ UDSSHOpV F
HVWjGLUH DYHF OH
PRLQV G
HUUHXUV HJ W\SH $LQVL OHV UpVXOWDWV LQGL
TXHQW TXHOV VRQW OHV DWWULEXWV TXL VRQW GHV FDQGLGDWV
SRXU IDFLOLWHU OD UpFXSpUDWLRQ GH ILFKLHUV /HV UpVXOWDWV
PRQWUHQW pJDOHPHQW FRPPHQW OHV GLIIpUHQWV DWWULEXWV
TXH O
XWLOLVDWHXU HVW FDSDEOH GH UDSSHOHU GHYUDLHQW rWUH
H[SORLWpVSRXUrWUHXWLOLVDEOHV/HV\VWqPHGHYUDLWG
XQH
SDUW SHUPHWWUH j O
XWLOLVDWHXU GH OHV IRUPXOHU VHORQ OD
Fournir des visualisations du contenu des documents
(QFHTXLFRQFHUQHOHVDSHUoXVGHGRFXPHQWOHVV\VWq
PHVQHGHYUDLHQW SDVVHOLPLWHUjOD SUHPLqUHSDJHFDU
QRXV DYRQV YX TXH OHV pOpPHQWV YLVXHOV UDSSHOpV SHX
YHQWWRXWDXVVLELHQFRQFHUQHUOHVDXWUHVSDJHVG
XQGR
FXPHQW,OV
DJLWGRQFG
DXWRULVHUODUHFKHUFKHPDQXHOOH
RXDXWRPDWLTXHGHVpOpPHQWVTXLVRQWLQFOXVGDQVOHGR
FXPHQW SDU H[HPSOH IRXUQLU GHV DSHUoXV GHV GRFX
PHQWV SHUPHWWDQW OD UHFKHUFKH GH JUDSKLTXHV LPDJHV
HWFVXUWRXWHVOHVSDJHV
69
'XPDLV 6 7 &XWUHOO ( &DGL] ---DQFNH*
6DULQ 5 DQG 5REELQV ' & 6WXII ,¶YH
6HHQ $ V\VWHP IRU SHUVRQDO LQIRUPDWLRQ UHWULHYDO
DQGUHXVH,Q3URFHHGLQJVRI6,*,5¶
IRUPH HW OH GHJUp GH SUpFLVLRQ DYHF OHVTXHOV LOV VH OHV
UDSSHOOHQW'
DXWUHSDUWOHV\VWqPHGHYUDLWWHQLUFRPSWH
GH OD QDWXUH SHX ILDEOH PDLV SUpYLVLEOH GX UDSSHO GDQV
OHVUpVXOWDWVTX
LOUHWRXUQH/HVUpVXOWDWVIRXUQLVVHQWpJD
OHPHQWGHVSLVWHVSRXUH[SORLWHUOHIDLWTXHOHUDSSHOGH
FHUWDLQVDWWULEXWV SHXWGpSHQGUHGHODIUpTXHQFHG
XWLOL
VDWLRQ GHV GRFXPHQWV (QILQ LOV HQFRXUDJHQW j GpYH
ORSSHUO
HQUHJLVWUHPHQW SDUOHV\VWqPHGHVDWWULEXWVTXL
FRQFHUQHQWOHVLQWHUDFWLRQVHQWUHOHGRFXPHQWHWVRQHQ
YLURQQHPHQW FRPPH OH FRQWH[WH OHV OLHQV HW OHV WUDLWH
PHQWVHWVXJJqUHQWTXHOVVRQWOHVW\SHVSUpFLVG
LQWHUDF
WLRQVTX
LOVHUDLWSHUWLQHQWG
HQUHJLVWUHU
'XPDLV 6 7 DQG -RQHV : 3 $ FRPSDUL
VRQRIV\PEROLFDQGVSDWLDOILOLQJ,Q 3URFHHGLQJV
RI WKH 6,*&+, FRQIHUHQFH RQ +XPDQ IDFWRUV LQ
FRPSXWLQJV\VWHPV
)UHHPDQ(DQG*HOHUQWHU'/LIHVWUHDPVD
VWRUDJH PRGHO IRU SHUVRQDO GDWD $&0 6,*02'
5HFRUG
*RQoDOYHV ' DQG -RUJH - $ 'HVFULELQJ
GRFXPHQWVZKDWFDQXVHUVWHOOXV",Q3URFHHGLQJV
RI WKH WK LQWHUQDWLRQDO FRQIHUHQFH RQ ,QWHOOLJHQW
8VHU,QWHUIDFHV
/HV UHFRPPDQGDWLRQV LVVXHV GH FHWWH pWXGH SRXUURQW
FRQWULEXHU j O
pYDOXDWLRQ GHV RXWLOV GH UpFXSpUDWLRQ GH
ILFKLHUV GpMj H[LVWDQWV PDLV DXVVL j OD FRQFHSWLRQ GH
QRXYHDX[ V\VWqPHV FDU VL FHUWDLQHV UHFRPPDQGDWLRQV
VRQW GpMj LPSOpPHQWpHV GDQV FHUWDLQV RXWLOV G
DXWUHV
UHVWHQW j PHWWUH HQ RHXYUH%LHQHQWHQGXGHVDQDO\VHV
SOXV DSSURIRQGLHV DLQVL TXH GHV H[SpULPHQWDWLRQV
FRQWU{OpHVGHYURQWrWUHFRQGXLWHVSRXUYDOLGHUjJUDQGH
pFKHOOH OHV UpVXOWDWV GH FHWWH pWXGH H[SORUDWRLUH PDLV
DXVVLSRXUWHVWHUOHVRXWLOVGHUHFKHUFKHGpYHORSSpV
-RQHV:3DQG'XPDLV677KH6SDWLDO
0HWDSKRU IRU 8VHU ,QWHUIDFHV ([SHULPHQWDO 7HVWV
RI 5HIHUHQFH E\ /RFDWLRQ YHUVXV 1DPH $&0
7UDQVDFWLRQVRQ2IILFH ,QIRUPDWLRQ6\VWHPV
.DSWHOLQLQ 9 8PHD 7UDQVODWLQJ LQWHUDF
WLRQKLVWRULHVLQWRSURMHFWFRQWH[WV,Q3URFHHGLQJV
RI WKH 6,*&+, FRQIHUHQFH RQ +XPDQ IDFWRUV LQ
FRPSXWLQJV\VWHPV
REMERCIEMENTS
1RXV UHPHUFLRQV WRXV OHV PHPEUHV GX SHUVRQQHO GH
O
,15,$5RFTXHQFRXUWTXLRQWSDUWLFLSpjFHWWHpWXGH
/DQVGDOH 0 : 7KH SV\FKRORJ\ RI SHU
VRQDOLQIRUPDWLRQPDQDJHPHQW$SSOLHG(UJRQRP
LFV
BIBLIOGRAPHIE
$GDU(.DUJDU'DQG6WHLQ/$+D\
VWDFN SHUXVHU LQIRUPDWLRQ HQYLURQPHQWV ,Q 3UR
FHHGLQJVRIWKHHLJKWKLQWHUQDWLRQDOFRQIHUHQFHRQ
,QIRUPDWLRQ DQG NQRZOHGJH PDQDJHPHQW /DQVGDOH0:5HPHPEHULQJDERXWGRFX
PHQWV PHPRU\ IRU DSSHDUDQFH IRUPDW DQG ORFD
WLRQ(UJRQRPLFV
/DQVGDOH 0 : 6LPSVRQ 0 DQG 6WURXG 7 5
0 $ &RPSDULVRQ RI :RUGV DQG ,FRQV DV
([WHUQDO0HPRU\$LGVLQDQ,QIRUPDWLRQ5HWULHYDO
7DVN ,Q %HKDYLRXU DQG ,QIRUPDWLRQ 7HFKQRORJ\
%DUUHDX 'DQG 1DUGL %)LQGLQJDQG5H
PLQGLQJ)LOH2UJDQL]DWLRQIURPWKH'HVNWRS6,*
&+,%XOOHWLQ
%RDUGPDQ 5 ,PSURYLQJ 7RRO 6XSSRUW IRU
3HUVRQDO,QIRUPDWLRQ0DQDJHPHQW3K''LVVHUWD
WLRQ,PSHULDO&ROOHJH/RQGRQ
0DUVGHQ * DQG &DLUQV ' ( ,PSURYLQJ
WKH8VDELOLW\RIWKH+LHUDUFKLFDO)LOH6\VWHP3UR
FHHGLQJVRI6$,&6,7
&XWUHOO ( 'XPDLV 6 7 DQG 7HHYDQ - 6HDUFKLQJ WR HOLPLQDWH SHUVRQDO LQIRUPDWLRQ PDQ
DJHPHQW&RPPXQLFDWLRQVRIWKH$&0
5DYDVLR 3 6FKlU 6 * DQG .UXHJHU + ,QSXUVXLWRIGHVNWRSHYROXWLRQ8VHUSUREOHPVDQG
SUDFWLFHV ZLWK PRGHUQ GHVNWRS V\VWHPV $&0
7UDQVDFWLRQV RQ &RPSXWHU+XPDQ ,QWHUDFWLRQ
&]HUZLQVNL 0 YDQ 'DQW]LFK 0 5REHUWVRQ *
* DQG +RIIPDQ + 7KH FRQWULEXWLRQ RI
WKXPEQDLOLPDJHPRXVHRYHUWH[WDQGVSDWLDOORFD
WLRQ PHPRU\ WRZHE SDJHUHWULHYDOLQ',Q 3UR
FHHGLQJVRI,QWHUDFW
:KLWWDNHU67HUYHHQ/DQG1DUGL%$
/HW¶VVWRS SXVKLQJWKHHQYHORSHDQGVWDUWDGGUHVV
LQJ LW D UHIHUHQFH WDVN DJHQGD IRU +&, +XPDQ
&RPSXWHU,QWHUDFWLRQ
'RXULVK 3 (GZDUGV : . /D0DUFD $ DQG
6DOLVEXU\ 0 3UHVWR DQ H[SHULPHQWDO DU
FKLWHFWXUH IRU IOXLG LQWHUDFWLYH GRFXPHQW VSDFHV
$&0 7UDQVDFWLRQV RQ &RPSXWHU+XPDQ ,QWHUDF
WLRQ72&+,
70
Élaboration et validation d’un questionnaire de mesure
de l’acceptation des technologies de l’information et de
la communication basé sur le modèle de la symbiose
humain-technologie-organisation
Éric Brangier & Sonia Hammes
Université Paul Verlaine – Metz. LabPsyLor (EA 3947)
Équipe Transdisciplinaire sur l’Interaction et la Cognition
Ile du Saulcy. BP30309 - F - 57006, Metz Cedex 1
[email protected] & [email protected]
RESUME
INTRODUCTION
Cet article a pour objet de mieux comprendre les facteurs
qui expliquent l’utilisation des nouvelles technologies de
l’information et de la communication. Dans un premier
temps, il reprend les éléments d’une théorie de la symbiose humain-technologie-organisation et un modèle
formel fait d’équations sémantiques qui permettent de caractériser ce modèle. Dans un second temps, cette communication propose une échelle de mesure de la liaison
entre l’humain et les technologies de l’information et de
la communication. Cette échelle se présente sous la
forme d’un questionnaire composé de 27 items, dont la
passation sur un échantillon de 172 personnes tend à
montrer la pertinence.
Plusieurs recherches récentes portant sur les formes
d’appropriation, d’utilisation ou d’acceptation sociales
des technologies nouvelles ont insisté sur la notion de
symbiose pour caractériser la relation qui se noue entre
l’homme et la machine [1, 2, 3, 5, 11, 14].
Dans la continuité de ce champ théorique, l’objectif de
cet article est de faire le point sur la notion de symbiose,
puis de proposer un questionnaire d’évaluation de la
symbiose humain – technologie - organisation. La passation de ce questionnaire sur un échantillon de 172 personnes ouvrira ensuite sur la présentation des résultats
obtenus. Finalement, l’interprétation des résultats permettra de discuter la pertinence de l’approche symbiotique par rapport aux autres approches de l’acception sociale des technologies.
MOTS CLES : Symbiose, relation homme-technologie-
organisation, questionnaire, validation.
ABSTRACT
ORIENTATION THEORIQUE : LA SYMBIOSE HUMAINTECHNOLOGIE-ORGANISATION
Le modèle biologique de la symbiose
This article concerns the creation and validation of a
questionnaire about human-technology-organisation
symbiosis level using a sample of 172 persons, about
their use of new technologies. This questionnaire has
been devised following symbiosis’ model by Brangier [2,
3]. The interest of this study is, on the one hand, to corroborate Brangier’s model and, on the other hand to give
useful information for technological advances
Le terme de symbiose est en général utilisé par les sciences de la vie pour définir un état d’interdépendance durable entre deux êtres vivants. Il s’agit d’un fait courant
dans le monde animal, végétal et bactérien, dans lequel
chaque organisme va profiter des avantages découlant de
l’association avec l’autre organisme. On peut tout simplement penser à la fertilisation des fleurs par l’action
des insectes butineurs qui bénéficient en échange d’un
accès à une nourriture.
KEYWORDS: Acceptance, Human-machine symbiosis,
human-technology-organisation relationship, questionnaire, validation of a technology use scale.
Le lien entre la biologie et les technologies de
l’information et de communication (TIC) peut sembler
lointain mais si l’on considère cette idée d’un point de
vue métaphorique, on peut comprendre l’emploi de ce
terme car l’homme d’aujourd’hui entretient une relation
durable et profitable avec TIC. En effet, l’homme construit des TIC visant à l’aider dans son travail ou à
l’assister dans sa vie quotidienne. Il bénéficie chaque
jour de ces dispositifs techniques pour l’accompagner ou
totalement le suppléer dans ses activités (en particulier
71
sons que Karahanna et Straub [10] ont fait appel à trois
facteurs supplémentaires qui sont la présence sociale,
l’influence sociale et le support technique et ont ainsi révisé le TAM de Davis. Mais malgré cette révision, la valeur explicative du TAM cité précédemment tourne autour de 24%, valeur qui est sensiblement la même pour
son petit frère le TAM révisé [10].
les plus pénibles). En retour, l’homme « alimente » la
technologie, l’améliore et la fait progresser de manière
continue.
L’émergence de la notion de symbiose humainmachine.
Pour l’approche symbiotique, la relation entre l’homme
et la technologie est durable et mutuellement profitable.
L’application de la notion de symbiose à la caractérisation de la relation entre l’humain et la machine provient
des travaux initiaux de Licklider [13] qui, en 1960 avait
été le premier à utiliser la notion de symbiose pour dessiner le futur de l’informatique en soulignant que
l’ordinateur devait quitter le domaine des « calculs »
pour se transformer en outil de communication moderne.
Ce faisant, Licklider fut suffisamment clairvoyant pour
imaginer que l’ordinateur pourrait devenir une sorte de
symbiote technologique destiné à assister l’humain dans
sa vie toute entière. L’histoire lui a sans doute donné raison. Du moins, c’est ce que nos résultats tendent à montrer.
Un autre modèle intéressant a été développé par Roy et
Illia [12]. Les auteurs remarquent que de nombreux modèles explicatifs de l’utilisation des TI ont été développés
sans qu’il ne soit jamais fait la liaison entre eux c’est ce
qu’ils se proposent de faire en créant un nouveau modèle
intégrant les facteurs et les théories utilisés par leurs prédécesseurs. Ces auteurs proposent un « modèle conceptuel intégré » qui met en relation les deux orientations
prises par l’étude des interactions homme-machine et définies par Clegg [6], c'est-à-dire le versant ergonomique
et le versant psycho-sociologique. Ce modèle conceptuel
intégré est assez séduisant car il intègre de nombreuses
variables et souligne, d’une part, les relations causales
entre les variables et, d’autre part, il permet de comprendre que ces variables forment un système plus ou moins
stable et régulé. Mais à ce jour, nous ne connaissons pas
de validation de ce modèle, du moins sur le plan statistique. La capacité explicative de ce modèle est plus empirique que statistique. Nous ne savons donc pas quel est le
poids relatif de chaque facteur. En bref, ce modèle semble certes intégrer une multitude de facteurs et de théories, mais cela complique singulièrement sa possibilité
d’utilisation à des fins d’opérationnalisation et de validation. Il nous semble par ailleurs qu’il serait possible de
faire des regroupements entre certains facteurs. C’est ce
que nous proposons de faire dans le modèle ci-dessous.
Plus récemment, l’approche symbiotique a été développée dans le domaine de la relation entre l’homme et la
technologie par Bender, De Haan et Bennett [1] et aussi
par De Rosnay [14] qui a contribué à diffuser cette notion. D’un point de vue plus théorique, Brangier [2] a
proposé un modèle de la symbiose humain-technologieorganisation que nous ne redévelopperons pas ici, mais
que nous opérationnaliserons dans les paragraphes suivants.
L’humain agit sur les TIC qui agissent sur l’humain
L’idée centrale de la symbiose est de considérer que
l’humain et les TIC sont intimement liés et que le genre
humain est devenu, sur le plan phylogénétique et ontogénétique un homme technologique. Des théories anthropologiques et des théories organisationnelles importantes
soutiennent depuis longtemps que toute action humaine
est technique : donc la relation entre homme et technologie n’est pas une nouveauté. L’humain se définit par et
en rapport avec la technologie, qui n’est pas un élément
qui lui est extérieur mais bien une dimension essentielle
de l’existence humaine. L’humain naît, vit, se développe,
travaille, joue, consomme, apprend, etc, dans des espaces
technologiques qui sont à la fois co-extensifs de la nature
humaine et constructifs de l’essence humaine.
L’originalité du modèle symbiotique est donc de compléter les modèles classiques de l’acceptation des TIC qui
reposent sur une sorte d’apprentissage des interactions ou
de gestion des changements socio-organisationnels. Parmi ces modèles, on pense au TAM : Technology Acceptance Model de Davis [7 et 8] qui souligne que l’utilité
perçue et la facilité d’utilisation sont des variables déterminant l’acceptation de la technologie. On peut constater immédiatement qu’il manque un versant essentiel à
ce modèle qui est celui des considérations psychosociales
et socio-organisationelles. C’est sans doute pour ces rai-
Modélisation de la symbiose humain-technologieorganisation
La symbiose est un processus caractérisant l’acceptation
des technologies qui s’enclenche si des conditions particulières de la relation homme-technologie-organisation
sont satisfaites. Ces conditions particulières reposent sur
la mise en oeuvre de trois facteurs déterminant la symbiose, à savoir :
• les fonctionnalités : la symbiose suppose une adaptation optimale des fonctions proposées par la technologie aux objectifs à atteindre par l’homme, par son
travail, par son environnement organisationnel. La
première condition d’acceptation est donc de considérer qu’une TIC doit être dotée de fonctionnalités
utiles, ou du moins évaluées comme telles.
• l’utilisabilité : c'est-à-dire la facilité d’utilisation du
système technique, souvent exprimée par le niveau
de compatibilité entre l’humain, la TIC et la tâche.
La deuxième condition d’acceptation repose donc
sur la simplicité d’utilisation ce qui correspond encore à l’optimisation ergonomique de la TIC.
72
•
les fonctionnalités proposées par la technologie sont
conformes à ce que l’homme souhaite réaliser (H(f))
pour effectuer une tâche donnée (T(f)).
les formes de régulation liées aux comportements
organisationnels :
il
s’agit
des
formes
d’appropriation, de rejet, d’innovation sociale et autres accommodements construits par l’homme dans
un contexte social qui est transformé par l’arrivée
d’une technologie. La troisième condition de la
symbiose vise donc à restituer l’optimisation de la
TIC aux contextes sociaux d’utilisation.
Détaillons ces trois points et montrons leur manière de
s’agencer.
Utilisabilité. Pour profiter pleinement des fonctionnali-
tés, il est nécessaire que l’homme puisse s’en servir facilement. Elles doivent donc être adaptées aux caractéristiques humaines, le but étant de réduire au maximum
l’écart entre le fonctionnement de l’humain et le système.
L’utilisabilité apprécie donc la fluidité des échanges entre l’humain et le système [4].
Fonctionnalités. Une fonctionnalité est une action utile
Sur le plan formel, si nous reprenons la fonctionnalité f
et sa réalisation par un système technique, soit S(f).
L’utilisabilité de cette fonctionnalité serait U(S(f)).
L’utilisabilité peut-être formalisée par la proximité des
modèles de connaissance en jeu au niveau de l’homme
soit H(S(f)) et au niveau de la tâche T(S(f)). Moins il y a
de différence entre U(S(f)), H(S(f)) et T(S(f)) et plus
l’utilisabilité du système (U(S(f)) est proche de ce que
les gens ont dans la tête (H(S(f)) et est proche de la manière dont le travail se retrouve dans le système (T(S(f)) ;
alors on peut considérer l’utilisabilité comme appropriée.
A ce niveau, la symbiose vise donc à qualifier le type de
compatibilité entre les caractéristiques de l’utilisabilité
du système U(S(f)), la tâche (T(S(f))) et la représentation
que l’homme (H(S(f)) se fait de la fonctionnalité implantée dans l’instrument.
réalisée avec un système technique. Les fonctionnalités à
mettre en œuvre dans une TIC sont dégagées lors de
l’analyse du travail d’un opérateur réalisant ce travail. Il
y a symbiose si le système propose des fonctionnalités
valides, c'est-à-dire des fonctionnalités dont l’utilisateur
a réellement besoin et que le système a la possibilité
technique de fournir.
D’un point de vue formel, la fonctionnalité « f » proposée par une TIC doit être compatible avec le travail « T »
de l’humain « H ». On a alors :
• la réalisation de f par le système « S », soit S(f) ;
• le modèle mental que l’homme se fait de la réalisation de la fonctionnalité par la technologie soit H(f) ;
• la tâche à réaliser avec la fonctionnalité f soit T(f).
Si les modèles de connaissance en jeu dans S(f), H(f) et
T(f) sont proches, alors on peut dire que la symbiose est
optimisée au niveau de la fonctionnalité. Autrement dit,
Niveau de la technologie
Fonctionnalité
Utilisabilité
Régulation
S(f)
U(S(f))
R(S)
Conditions de symbiose
S(f)§U(A(f))§ R(A)
Symbiose optimisée au niveau de la technologie
Niveau de l’humain
H(f)
H(S(f))
R(H)
H(f)§H(S(f))§ R(H)
Symbiose optimisée au niveau de l’humain
Niveau du contexte organisationnel
T(f)
Conditions de symbiose
S(f)§H(f)§ T(f)
T(S(f))
R(O)
T(f)§T(S(f))§ R(O)
Symbiose optimisée au niveau de l’organisation
Symbiose optimisée
au niveau des fonctionnalités
U(S(f))§ H(S(f))§ T(S(f))
R(S)§R(H)§ R(O)
Symbiose optimisée au niveau de l’utilisabilité
Symbiose optimisée
au niveau des régulations
Tableau 1 : Modèle de connaissance en jeu aux différents niveaux de l’interaction homme-technologie-organisation croisés avec les
processus de la symbiose –fonctionnalité, utilisabilité, régulations (le signe § correspond à la proximité, à la compatibilité des modèles en jeu), selon Brangier [2] et [3].
biotique de tolérance du contexte de l’organisme extérieur par l’hôte). Autrement dit, une condition supplémentaire
porte
sur
les
régulations
socioorganisationnelles qui généreront des attitudes et des re-
Régulations. Pour être utilisée, une technologie ne doit
pas seulement fournir des fonctionnalités pertinentes et
facilement utilisables ; elle doit encore être située dans
un contexte social qui l’accepte (c’est le principe sym-
73
de symbiose, nous cherchons également à produire des
données qui peuvent valider ou invalider le modèle proposé. Notre modèle consiste à défendre l’idée que la
symbiose entre l’humain, la technologie et l’organisation
va dépendre de l’adaptation des fonctionnalités, de
l’utilisabilité et des régulations aux différents éléments
de la situation (technologie, humain, organisation). La relation symbiotique est donc à rechercher dans les trois lignes et trois colonnes du tableau 1, soit dans les neuf cases.
présentations plus ou moins favorables. Lors de
l’implantation d’une nouvelle technologie, les humains
qui l’utilisent produisent des compromis, des arrangements socialement acceptables avec ces technologies, qui
engendrent par conséquent des changements durables des
comportements personnels et professionnels. Les hommes doivent mettre en œuvre des moyens nouveaux pour
adapter la technologie à leur fonctionnement, s’adapter
eux-mêmes ou adapter le mode de fonctionnement social
et organisationnel, si la technologie ne s’adapte pas ellemême.
En conséquence, le tableau 1 est à lire comme jouant un
rôle charnière entre l’explication que nous donnons à la
symbiose d’une part, et, l’opérationnalisation d’une
échelle quantitative qui permettrait de valider le modèle,
d’autre part. Pour ce qui nous concerne, nous proposons
une validation quantitative en établissant un questionnaire qui, soumis à une population, servira à mesurer des
scores de symbiose. Ce score sera à la fois global et décomposable en plusieurs sous-échelles correspondant à
chacune des lignes ou des colonnes (i.e sous-échelles de
symbiose ou niveau des fonctionnalités, de l’utilisabilté
ou des régulations). Ce sont à la fois les réponses faibles
ou fortes et l’organisation statistique des réponses des
questionnés qui permettront la discussion de la proposition scientifique de notre modèle de l’acceptation des
TIC basé sur la symbiose.
On a donc :
• des régulations en jeu au niveau de l’homme : R(H) ;
c'est-à-dire ses adaptations psychosociales et psychologiques en lien avec la technologie. Selon leurs
possibilités, les humains régulent les usages des
technologies.
• des régulations en jeu au niveau de la technologie :
R(S) ; c'est-à-dire son adaptabilité à la situation
d’utilisation.
• des régulations en jeu au niveau du contexte organisationnel R(O) : c'est-à-dire les modifications collectives (i.e. relatives au groupe social) mises en place
lors de l’introduction de la technologie.
La régulation est maximisée lorsque l’on peut observer la
concordance de ces trois formes de régulations. La symbiose est alors optimisée au niveau des régulations sociales.
Attentes
Plus que des hypothèses, la validation d’une échelle implique des attentes métriques particulières. Aussi, le
questionnaire devrait-il prétendre à :
D’une manière générale, la symbiose repose sur une
compatibilité cognitive des modèles en jeu [16]. Une
technologie sera acceptée si elle correspond à l’idée que
s’en fait l’utilisateur, à son mode de fonctionnement, à
l’idée qu’il se fait de sa tâche, de lui-même et de son environnement social et professionnel. Le modèle proposé
(tableau 1) n’est pas un modèle purement explicatif où
telle cause expliquerait tel effet. Les processus (fonctionnalité, utilisabilité, régulation) constituant les éléments
de la symbiose sont interdépendants. Ces trois dimensions sont enchevêtrées, tant les variables qui les composent sont nombreuses, diversifiées et complexes. Par ailleurs, il faut signaler que la symbiose, une fois optimisée
ne peut pas être prise comme un état stable. La modification d’un des éléments peut modifier l’équilibre
d’ensemble et entraîner des changements d’état. La relation symbiotique est donc le résultat d’un processus en
équilibre délicat. Il suffit qu’un de ces constituants soit
modifié pour que l’équilibre soit rompu et entraîne, par
exemple, insatisfaction, résistance, rejet, malveillance,
inutilisation, sabotage etc., de la part des humains.
1.
2.
3.
4.
PROBLEMATIQUE GENERALE
Problème posé.
La validation d’un modèle scientifique passe toujours par
une confrontation aux données mesurées. Aussi, en proposant de caractériser l’acceptation des TIC par la notion
74
Une bonne corrélation entre l’utilisation réelle des
TIC et le score de symbiose mesuré par le questionnaire. Plus les questionnés se déclarent d’intenses
utilisateurs, plus le score global de symbiose devra
être élevé, et inversement.
Une valeur explicative supérieure à celle du TAM
[7, 8, 11] soit plus de 24% de la variance expliquée.
Une fiabilité ou cohérence interne de l’échelle devrait être élevée, sans quoi nous rejetons le modèle
de la symbiose. A l’inverse, si les items ont une relation forte avec la variable latente (notion de symbiose) alors ils auront une forte corrélation entre
eux. On s’attendrait donc à un Alpha de Cronbach
supérieur à .70. Une échelle fidèle ou stable doit assurer un rapport minimum entre la somme des variances des items et la variance du score total de
l'échelle entre les répondants. Plus une échelle présente un cœfficient Alpha élevé, plus sa fidélité est
jugée excellente.
Une bonne corrélation de tous les items et des souséchelles qui montrerait une relation entre toutes les
réponses aux questions. Cela serait un élément de
preuve de ce nous appelons l’équivalence (ou la
proximité) des modèles en jeu à chaque niveau de la
5.
lation gérée, régulation des changements a été dépassée et l’on assiste au développement de conduites
inventives (ou innovantes).
symbiose [2] et [3]. Si cette corrélation de toutes les
réponses aux items existe, nous pouvons alors supposer qu’il serait intéressant, pour mesurer le niveau
de symbiose, de ne mesurer qu’un seul niveau (ou du
moins d’identifier la sous-échelle qui est la plus déterminante). Nous tenterons par la méthode de régression ascendante de mettre en évidence ce trait
particulier.
Des résultats ayant une structure factorielle organisée autour d’un seul facteur qui restitue la notion de
symbiose. Une forte corrélation inter-items suggère
que tous les items partagent une notion commune.
Ainsi une échelle unidimensionnelle ou une dimension d’une échelle multidimensionnelle serait un indicateur supplémentaire de la véracité de la notion
de symbiose.
Ceci nous donne donc un questionnaire à 27 questions,
fondées sur les 9 cases du tableau 1 multipliées par les
trois niveaux d’intensité. Chaque question correspond à
un croisement entre les processus en jeu dans la symbiose et les niveaux de la symbiose.
1. Les TIC sont d’un grand intérêt.
2. Je sais manipuler les TIC.
3. Je n’ai jamais de problème avec les TIC.
4. Je sais comment faire pour réaliser ce que je souhaite à
l’aide des TIC.
5. Si une TIC est en panne, j’essaie de « bidouiller » pour la
remettre en fonctionnement.
6. Je pense que je suis capable de réparer une TIC en panne.
7. Dans la société, les TIC sont omniprésentes.
8. Les TIC me proposent des fonctions qui me permettent de
gagner du temps et d’être plus efficace au quotidien.
9. J’organise ma vie quotidienne (communications, relations,
travail) en fonction de ce que les TIC me permettent de faire.
10. Les TIC sont faciles à utiliser.
11. Je peux apprendre rapidement à utiliser les TIC.
12. Le simple fait d’utiliser des TIC m’amuse.
13. Les TIC m’indiquent clairement la manière dont je dois les
utiliser.
14. Les concepteurs de TIC tiennent compte de l’avis des utilisateurs.
15. J’aime beaucoup passer du temps à comprendre comment
fonctionne une TIC.
16. Pour réaliser mes activités quotidiennes, je trouve que les
moyens traditionnels sont souvent moins appropriés que les
TIC.
17. J’ai l’impression que les interactions que j’ai avec les TIC
sont toujours optimisées.
18. Les opérations proposées par les TIC donnent un côté plus
ludique (= plaisant et amusant) à mes activités.
19. Je pense que les TIC sont faites de telle manière qu’elles
permettent à l’homme de conserver ses habitudes.
20. J’ai l’impression que l’évolution des TIC va dans le sens
d’une meilleure adaptation aux attentes de l’homme.
21. J’ai l’impression que les TIC devancent les besoins humains.
22. L’usage des TIC me transforme mentalement.
23. Je sais gérer les changements que m’imposent les TIC.
24. J’utilise assez souvent les TIC pour autre chose que ce qui
est initialement prévu.
25. Les TIC s’intègrent facilement dans la société.
26. Je pense que les changements produits par les TIC dans la
société sont prévisibles et donc gérables.
27. Les changements engendrés par les TIC dans la société sont
bénéfiques car ils me permettent d’être créatif.
Tableau 2 : les 27 items de l’échelle de symbiose humaintechnologie-organisation.
METHODOLOGIE
Matériel
La méthode utilisée repose sur l’élaboration et la validation d’une échelle quantitative de mesure de
l’acceptabilité des technologies. Elle se présente sous la
forme d’un questionnaire dont la validation fait l’objet
du présent article. Ce questionnaire tente de repérer la
relation (acceptation/refus) entretenue par les humains
avec les TIC. Conscient de la polysémie de ce concept,
les TIC sont ici vues d’un point de vue générique. C’est
un des avantages de ce questionnaire. Nous nous
intéressons donc à toutes les TIC en général, et à leurs
représentations chez de nombreux utilisateurs. Le
référencement de 19 types de TIC permet aux
questionnés de déclarer ce qu’ils utilisent ou pas comme
TIC et la durée d’utilisation. Nous avons donc une
mesure déclarée (en nombre et en temps) des TIC
utilisées par les questionnés.
Ce questionnaire reprend à la fois les trois processus à
optimiser lors de la mise en place d’une TIC (fonctionnalité, utilisabilité, régulation) ainsi que les trois domaines
concernés par la symbiose (homme, technologie et organisation). Les trois processus seront subdivisés à nouveau
en trois, représentant des niveaux de symbiose successifs
ou en quelque sorte l’intensité de la relation symbiotique
(faible, moyenne ou forte) :
1.
2.
3.
La fonctionnalité perçue est appréciée par l’idée que
l’utilisateur n’a pas le sentiment de maîtriser la TIC,
possède une maîtrise opératoire (maîtrise du fonctionnement visible), ou a développé une maîtrise cognitive (maîtrise du fonctionnement interne) de la
technologie.
L’utilisabilité perçue est également appréciée par
trois critères : sans utilisabilité perçue, simplicité et
facilité d’utilisation, ou perception d’aisance dans
l’utilisation.
La régulation sociale perçue est également vue en
trois niveaux : sans aucune régulation perçue, régu-
Le découpage du questionnaire en six sous-échelles
(fonctionnalités, utilisabilité, régulation, technologie,
homme, contexte) n’est pas explicité aux questionnés. La
passation se fait en auto-administration. Les personnes
doivent coter la fréquence avec laquelle ils ressentent
75
•
différentes impressions sur une échelle de Lickert en 7
points allant de 0 « jamais ressenti » à 6 « ressenti très
fréquemment ». Un score élevé à l’item évoque un niveau élevé de symbiose, à l’inverse un score faible évoque un faible niveau de symbiose. Pour chaque échelle,
le score recueilli a la même signification en fonction de
son niveau mais correspond plus particulièrement aux
fonctionnalités, à l’utilisabilité, à la régulation sociale, au
niveau de la technologie, de l’homme ou du contexte.
Arbitrairement, nous avons décidé que le score moyen de
symbiose serait la moyenne des scores obtenus à chaque
question. De la même façon, le score de chaque échelle
sera la moyenne des réponses aux questions correspondantes.
•
à une plus grande qualité du modèle proposé qui balaye bien tout le champ de la relation hommetechnologie-organisation.
au type de population choisi qui est tout de même
extrêmement typique dans son rapport à la technologie. Nous avons ici en majorité des personnes qui
semblent avoir un rapport en tout ou rien à la technologie. Il faudrait tester une nouvelle fois ce critère
sur un échantillon plus vaste, représentatif de la population générale.
Fidélité : Alpha de Cronbach à 0.9
Le coefficient Alpha de Cronbach obtenu pour
l’ensemble des items s’élève à .954, ce qui traduit une
excellente cohérence interne de l’échelle. Seuls les items
7, 21 et 25 une fois enlevés augmenteraient la cohérence
interne du questionnaire à .956 (pour la question 7) et
.955 (pour les questions 21 et 25). Pour augmenter la fidélité, nous pourrions améliorer ces questions pour une
prochaine version de l’échelle. Ceci dit, la fidélité du
questionnaire est déjà très bonne. Nous pouvons donc
conclure que notre questionnaire dispose d’une excellente consistance interne. Presque tous les items contribuent bien à la mesure du score final de symbiose1.
La première partie du questionnaire porte sur les caractéristiques du répondant (âge, sexe, expérience...), en particulier dans son rapport aux TIC (nombre de TIC utilisées et durée d’utilisation déclarée). La seconde partie
est présentée dans le tableau 2.
Participants et procédure
L’échantillon était composé de 101 hommes et 71 femmes d’un âge moyen de 38,45 ans (écart-type = 20,68 ;
âge minimum = 18 ans ; âge maximum = 84 ans). La passation de ce questionnaire est relativement courte, de 5 à
10 minutes en fonction des sujets.
Corrélation des items entre eux, items-échelle,
échelle – sous-échelle et sous-échelles entre elles.
En ce qui concerne la corrélation des items avec l’échelle
globale de symbiose, seuls 2 items (7 et 25) possèdent
des corrélations inférieures à .35. Plus de 81% des autres
items ont des corrélations supérieures à .60. (p= .01).
Excepté les items 7, 21 et 25, tous les items sont au minimum corrélés à r = .30 (p < .01) à 19 autres items. Au
total 65,52% des 351 corrélations effectuées sont supérieures à .40 (p = .01). Les sous-échelles, quant à elles,
sont toutes très fortement corrélées à l’échelle globale de
symbiose (p= .01) avec des corrélations allant de .89
pour l’échelle de régulation à .96 pour l’échelle
d’utilisabilité (figure 1).
RESULTATS
Les résultats sont restitués selon l’ordre des attentes exprimées dans la partie « problématique ».
Corrélation entre l’utilisation des TIC et la symbiose :
supérieure à 0.6
Pour présager de l’efficacité de l’échelle de symbiose,
nous avons donc demandé aux répondants de nous lister
les TIC qu’ils utilisaient. Nous les avons comptées, ce
qui a permis ensuite de calculer une corrélation entre le
nombre de TIC utilisées et le score de symbiose. Il apparaît que le nombre de TIC utilisées suit le score de symbiose (r= .68 ; p < .001). Ce score diminue également
avec l’augmentation de l’âge du répondant (r= -.67 ; p <
.001).
Les sous-échelles sont également fortement corrélées entre elles avec des indices allant de .67 pour les échelles
de régulation et de fonctionnalité, à .92 pour les échelles
d’utilisabilité et celle du niveau de l’homme. Si l’on étudie les corrélations des sous-échelles deux à deux, elles
sont toutes fortement corrélées les unes avec les autres.
Valeur explicative supérieure au TAM (46% contre
24%)
Une régression par la méthode ascendante effectuée sur
la part représentée par le score de symbiose dans
l’explication d’une plus ou moins forte utilisation des
TIC, montre que la symbiose explique 46% des variations observables dans le nombre de TIC utilisées. De ce
point de vue, notre modèle explique 46% de la variation
dans l’utilisation des TIC. Ce pourcentage obtenu parait
énorme par rapport à celui mis en évidence par Davis [7,
8] dans le TAM et par dans le TAM révisé [11] soit
24%. Nous pouvons penser que ce résultat élevé pour notre modèle soit dû :
Comme attendu, le calcul de la régression ascendante
permet de mettre en évidence un facteur suffisant ou un
trait particulier qui est fortement explicatif de la relation
symbiotique. Parmi les sous-échelles, c’est celle
d’utilisabilité perçue qui s’avère être la plus explicative
des variations du score global de symbiose : environ 92%
de la variance provient de cette sous-échelle (r² ajusté=
1
Si l’on tente de savoir comment améliorer encore la fidélité
grâce à l’Alpha de l’échelle sans l’item, nous remarquons que
la suppression de 3 items améliorerait la fidélité.
76
même d’expliquer le comportement humain dans les environnements techniques. Qui plus est, cette théorie souligne que nos façons de travailler, de vivre et de penser
se trouvent transformées en même temps que le système
technique dans lequel elles se déroulent. De ce point de
vue, la technologie agit sur l’être humain qui, à son tour,
agit sur les facteurs technologiques qui le déterminent.
C’est donc bien la nature des relations en œuvre qui permet d’expliquer la valeur des nouvelles technologies et
l’orientation de la conduite humaine dans les systèmes
technologiques. Ces valeurs associées à la technologie
relèvent des fonctionnalités proposées, de leur niveau
d’utilisabilité perçues et finalement des formes de régulations sociales qui leurs sont attachées. Par voie de conséquence, l’humain évalue les TIC en fonction du modèle
de connaissance qu’il s’en construit, ce modèle étant
fondé d’abord sur les fonctionnalités, l’utilisabilité et les
régulations et sur la compatibilité entre les modèles de
connaissances en jeu. Autrement dit, soient :
.916). Bien entendu, il s’agit d’une supériorité relative,
car les autres sous-échelles ont des pourcentages
d’explicativité très élevés également étant donné que toutes sont très fortement corrélées à l’échelle globale.
Fonctionnalités
Utilisabilité
.912
Régulations
.957
.889
Symbiose
.937
Organisation
.953
.948
Homme
Technologie
•
•
Une fonctionnalité « f » ;
S(f) la réalisation d’une fonctionnalité f par un système technique,
•
H(f), le modèle mental lié à la fonctionnalité f,
•
T(f), le travail réalisé avec la fonctionnalité f,
•
U(S(f)) l’utilisabilité de la fonctionnalité f implantée dans le système S.
•
H(S(f)) le modèle de connaissance de l’homme,
c’est-à-dire la représentation mentale de la fonctionnalité f implémentée dans le dispositif.
•
T(S(f)) le travail à réaliser avec le système.
•
R(S) la régulation du système, c’est-à-dire son
adaptabilité aux variations de la situation ;
•
R(H) la régulation de l’homme, c’est-à-dire les processus psychosociaux de son rapport à la technologie ;
•
R(O) la régulation de l’organisation, les formes de
changements organisationnels réactives à la mise en
place du nouveau dispositif.
Moins il y a de désaccord entre les modèles de connaissances en jeu et plus la relation symbiotique est importante. Autrement dit, plus les niveaux et les processus
sont compatibles, plus l’utilisation générale d’une TIC
s’en trouve optimisée : plus S(f), H(f), T(f) sont proches ;
plus U(S(f)), H(S(f)), T(S(f)) sont également proches ; et
plus R(S), R(H), R(O) le sont aussi ; et plus le système
technologique est d’une nature symbiotique optimisée.
Figure 1 : Corrélations échelle de symbiose avec chacune des
sous-échelles (fonctionnalités, utilisabilité, régulation, homme,
technologie, organisation)
Analyse factorielle
La structure factorielle des résultats repose principalement sur un facteur qui comprend 19 items et explique
plus de 46% de la variance du score de symbiose. La dissémination des résultats sur les autres facteurs est relativement faible, sauf pour les questions 7, 21, 25 et 26 qui
pourraient être révisées.
DISCUSSION
Cette recherche tente de comprendre et mesurer les facteurs qui expliquent l’acceptation de TIC. L’intérêt de
cette question réside dans le fait de mieux comprendre
les comportements des utilisateurs et de souligner que
ces comportements sont déterminés par une série de cognitions qui relève de la manière dont les humains
s’emparent des TIC dans un contexte organisationnel
donné. Au-delà de son intérêt explicatif, ce type de recherche a également pour objectif de permettre la prise
en compte des facteurs qui déterminent une utilisation
harmonieuse des TIC et cherche donc à pronostiquer des
succès ou échecs d’utilisation, sur la base d’une échelle
composée de 27 items.
Aujourd’hui, les modèles [5, 7, 8, 9, 10, 12, 15] dont le
manager, l’ergonome, l’ingénieur et l’informaticien disposent sont souvent discutés grâce à des recherches écologiques ou des validations empiriques. Or comme le
souligne Illia et Roy [12], les modèles proposés renvoient à des théories distinctes rarement superposables. Il
est donc nécessaire de disposer d’une théorie unifiée et
de résultats pour valider cette théorie. Pour ce qui nous
concerne, nous estimons que notre modèle de la symbiose présente des intérêts scientifiques importants à
Les résultats présentés, qui se situent au niveau des représentations (car il s’agit d’un questionnaire), nous
amènent à considérer que l’échelle proposée présente des
qualités statistiques qui vont dans le sens d’une validation du modèle de la symbiose humain-technologieorganisation. En effet, si l’on s’intéresse aux souséchelles, on s’aperçoit que celles-ci sont toutes très fortement corrélées à l’échelle globale de symbiose. Nous
pouvons donc penser que presque tous les items et toutes
77
10. Karahanna, E. & Straub, D.W. (1999). The Psychological origins of perceived usefulness and ease of
use. Information and Management, Vol. 35, No. 4,
pp. 237-250.
les sous-échelles sont une mesure pertinente de la symbiose telle que modélisée dans le tableau 1, c’est sans
doute un élément de validation qui souligne (comme attendu dans [5 et 6]) que la symbiose est un phénomène
constitué de cognitions interdépendantes et imbriquées
les unes dans les autres.
11. Gill, S.K., (Ed). (1996). Human Machine Symbiosis:
The Foundations of Human-Centred Systems Design.
Springer Verlag.
Finalement, le score global de symbiose est conforme à
celui que nous attendions, même au-delà. Aussi, avonsnous tendance à penser que ces résultats sont suffisamment significatifs pour que de nouvelles passations de ce
questionnaire aient lieu sur un échantillon plus large.
12. Illia, A., & Roy, M.C. (2001). Utilisation des TI par
les managers : Vers un modèle conceptuel intégré,
Document
de
Travail
2001-002,
2001.
http://www.fsa.ulaval.ca/rd
13. Licklider, J.C.R., (1960). Man-Computer Symbiosis.
IRE Transactions on Human Factors in Electronics,
Vol HFE-1, March, 1960, 4-11.
BIBLIOGRAPHIE
1. Bender, J., De Haan, J., & Bennett, D. (1995). The
symbiosis of work and technology, In J., Bender, J.,
de Haan, & D., Bennett. London : Taylor & Francis,.
14. Rosnay, de, J. (2000). L’homme symbiotique. Paris :
Seuil, collection Points.
2. Brangier, E. (2002). L’assistance technique comme
forme de symbiose entre l’homme et la technologie.
Esquisse d’un modèle de la symbiose hommetechnologie-organisation.
Revue
d’Interaction
Homme-Machine, Vol. 3, No. 2, pp. 19-34.
15. Schmitz J. & Fulk J. (1991). Organizational Collegues, Media Richness and Electronic Mail: a test of
the Social Influence Model of Technology Use,
Communication Research, 18(4), 487-523.
3. Brangier, E. (2003). La notion de « symbiose
homme-technologie-organisation ». In N. Delobbe,
G. Karnas, & Ch. Vandenberg, Evaluation et développement des compétences au travail. UCL : Presses
Universitaires de Louvain, Vol. 3, pp. 413-422.
16. Streitz, N.A. (1987). Cognitive compatibility as central issue in HCI: theoretical framework and empirical finding. In G. Salvendy (Ed.), Cognitive engineering in the design of HCI and expert system. Amsterdam : Elservier Science Publish, 75-82.
4. Brangier, E., & Barcenilla, J (2003). Concevoir un
produit facile à utiliser : adapter les technologies à
l’homme. Paris : Editions d’organisation.
5. Brangier, E., & Vallery, G. (2004). Aspects psychologiques et organisationnels du développement des
nouvelles technologies de la communication et de
l’information. In Brangier, E., Lancry, A., & Louche,
C. (Eds) Les dimensions humaines du travail : théories et pratiques de la psychologie du travail et des
organisations, Nancy : PUN ; 213-250.
6. Clegg, C. (1994). Psychology and information technology :The study of cognition in organizations. British Journal of Psychology, Vol. 85, pp. 449-477.
7. Davis, F.D. (1986). A technology Acceptance Model
for empirically testing new end-user information systems : theory and results. Thèse, MIT Sloan School
of Management, Cambridge.
8. Davis, F.D. (1989). Perceived usefulness, Perceived
ease of use, and User acceptance of Information technology. MIS Quarterly, Vol. 13, No. 3, pp. 319-339.
9. Goodhue Dale L. & Thompson R. (1995). TaskTechnology Fit and Individual Performance », MIS
Quarterly, V(N), June, 213-236..
78
Métamorphose des IHM et Plasticité:
Article de synthèse
Gaëlle Calvary
Lionel Balme
Joëlle Coutaz
Olfa Dâassi
Alexandre Demeure
Vincent Ganneau
Jean-Sébastien Sottet
Université Joseph-Fourier
Laboratoire CLIPS-IMAG
BP53, 38041 Grenoble Cedex 9
[email protected]
RESUME
sateur [16] en renfort desquelles venaient les critères
d’ergonomie. Par exemple, dans le référentiel de C. Bastien et D. Scapin [3], le critère de guidage/sous-critère
retour d’information qui prône l’affichage de
l’information là où l’utilisateur est censé regarder pouvait être interprété comme: au moins afficher
l’information dans la zone la plus visible de l’écran.
Dans ce même référentiel, le critère charge de travail/sous-critère actions minimales qui incite à une longueur de trajectoire d’interaction la plus courte possible
était entendu comme: réduire le nombre d’actions physiques (déplacements de la souris, entrées de données)
nécessaires à l’accomplissement d’un but. Si la complexité de l’ouvrage pour des IHM classiques s’est toujours soldée par un échec des générateurs d’IHM [14], le
déconfinement des IHM complexifie encore le problème.
Cet article traite de la métamorphose des Interfaces
Homme-Machine (IHM) qui, grâce aux progrès technologiques, passent du centralisé au distribué, du classique
à l’exotique, du monomodal au multimodal, de
l’explicite à l’implicite, du sédentaire au nomade et du
rigide au plastique. L’article se focalise sur la plasticité
des IHM, c’est-à-dire la capacité d’une IHM à s’adapter
à son contexte d’usage (<utilisateur, plate-forme, environnement>) dans le respect de son utilisabilité. Un espace problème est dressé, recensant les questions à se
poser lors de l’ingénierie d’IHM plastiques. Ces questions sont aujourd’hui ouvertes, en l’attente d’un recul
suffisant pour l’élaboration peut-être de recommandations ergonomiques servant alors de garde-fou à
l’ingénierie d’IHM plastiques.
MOTS CLES : Métamorphose des IHM, plasticité des
IHM, adaptation, contexte d’usage, utilisabilité.
Avec les avancées des réseaux et les progrès en miniaturisation, l’utilisateur est imaginé comme mobile, évoluant dans un environnement varié et recourant, de manière opportuniste, à des plates-formes d’interaction diverses. Si cette vision séduit du point de vue de l’usage,
elle pose de nouveaux défis en ingénierie de l’Interaction
Homme-Machine. Vous êtes au salon, confortablement
installé dans votre canapé quand tout à coup votre mobile, perdu au fin fond de votre sac, vous annonce
l’arrivée d’un message (SMS). Dans le meilleur des cas,
vous entendez la sonnerie et courez à la recherche de
votre mobile. Mais quid alors des critères de guidage et
charge de travail? Dans le pire des cas, vous n’entendez
pas la sonnerie et découvrez votre message trois jours
plus tard. Pourquoi votre SMS ne s’afficherait-il pas sur
la surface d’affichage à laquelle vous faîtes face (mur,
télévision, etc.), filtrant les éléments du SMS selon votre
contexte d’usage? Si typiquement vous êtes en réception, il pourrait être indiscret de dévoiler l’identité de
l’émetteur. En revanche, au départ de vos convives,
pourquoi la pièce ne vous rappellerait-elle pas
l’existence de ce message en attente? Pourquoi ne vous
permettrait-elle pas d’y répondre sans grimper à l’étage
pour chercher votre mobile? La notion d’espace interactif prend alors tout son sens extirpant le desktop de sa
boîte grise.
ABSTRACT
This paper deals with the metamorphosis of User Interfaces (UI) in ambient intelligence. Thanks to technological advances, UIs can now be distributed, multimodal,
exotic in their input and output devices, no more limited
to explicit interaction, mobile and plastic. This paper focuses on plasticity. In Human-Computer Interaction,
plasticity refers to the ability of a UI to withstand variations of context of use while preserving usability. A
problem space is provided. It identifies open issues that
computer scientists have to deal with when developing
plastic UIs. A revision or extension of traditional ergonomic criteria might be relevant for both guiding developers and sustaining evaluation.
KEYWORDS : Metamorphosis of UIs, advanced UIs,
plasticity of UIs, adaptation, context of use, usability.
INTRODUCTION
Jusqu’ici l’interaction Homme-Machine était confinée à
une unique plate-forme: l’utilisateur était scotché à son
ordinateur boîte grise et interagissait avec ses traditionnels clavier-souris. Les Interfaces Homme-Machine
(IHM) étaient conçues selon des méthodes centrées utili-
79
Dans une première section, l’article dresse les lignes de
force de la métamorphose des IHM. Parmi elles, nous
retenons la plasticité qui, lorsqu’appliquée aux IHM, dénote la capacité d’un système interactif à s’adapter à son
contexte d’usage dans le respect de son utilisabilité. Le
contexte d’usage est ici défini comme un triplet <utilisateur, plate-forme, environnement>. L’article se focalise
sur la plasticité. Il en présente l’espace problème mettant
ainsi au jour un ensemble de questions à se poser lors de
l’ingénierie d’IHM plastiques. Ces questions, aujourd’hui sans réponse, pourraient justifier une relecture,
voire un ré-examen des critères et recommandations ergonomiques actuels pour mieux assister les informaticiens dans la conception et l’évaluation de tels systèmes.
exemples, AmbientRoom [12] (Figure 2) qui imaginait les fioles comme dispositifs de sortie ou plus récemment l’IO Brush [23], un pinceau magique permettant de prélever un motif (couleur, texture, mouvement) dans le monde physique puis de le reproduire et le manipuler dans le monde numérique. En
produits commercialisés, mentionnons le lapin de
Violet (le «Nabaztag») qui allie entrée et sortie
(http://www.nabaztag.com).
METAMORPHOSE DES IHM
Avec les avancées technologiques, les IHM passent:
•
Du centralisé au distribué. Pour exemples: la métaphore du peintre explorée dans Pick and Drop [20]
ou la télécommande universelle développée dans
Pebbles [15]. Les IHM ne sont plus concentrées en
un unique écran. Elles s’étalent sur un ensemble de
plates-formes mettant à profit les caractéristiques
intrinsèques et extrinsèques de ces plates-formes.
Dans Pick and Drop par exemple (Figure 1),
l’assistant personnel (PDA), par son caractère mobile (intrinsèque) est perçu comme une palette
d’outils dans laquelle l’enseignant vient piocher
couleurs, dessins, films…
Figure 2: De l’écran aux fioles en dispositifs de sortie
[12].
Si ces dispositifs restent marginaux, ils forcent
néanmoins une ouverture d’esprit: les sorties ne
sont plus limitées aux seuls écrans et les entrées
peuvent être médiées par des dispositifs autres que
les claviers-souris. Dès lors, les notions d’entités
physiques et de rôles supplantent l’ex triptyque
écran-clavier-souris [13]. Un mur est une entité physique appropriée pour jouer le rôle de surface
d’affichage. Le doigt ou un stylo par leurs formes
allongées peuvent jouer le rôle de dispositifs
d’entrée. Quant à la main, certains y voient dans
l’alignement des doigts l’opportunité d’un affichage
par lignes [1] (Figure 3).
Figure 1: La métaphore du peintre dans Pick and Drop
[20]. L’IHM de l’éditeur de dessin est distribuée entre un
PDA et un PC.
•
Figure 3: La main en dispositif de sortie [1].
On pourrait imaginer d’autres rôles aux PDA, par
exemple, l’affichage d’informations personnelles.
Par leur petite taille d’écran et a priori leur proximité
de l’utilisateur, l’information devrait en effet y être
peu lisible pour des coups d’œil indiscrets;
Du classique à l’exotique dans les dispositifs
d’entrée/sortie. Alors que nos ordinateurs de bureaux arborent inlassablement le triptyque écranclavier-souris, des prototypes de recherche rivalisent
d’imagination tant en entrée qu’en sortie. Pour
Ainsi, tout objet de l’environnement, dès lors qu’il
est perçu et/ou manipulable par le système, devient
dispositif potentiel d’entrée/sortie et prend alors part
à la plate-forme au même titre que les anciens
écrans-claviers-souris. C’est un déconfinement des
IHM au profit du monde physique. Les recherches
en systèmes mixtes entrent dans ce cadre;
80
•
•
•
Du monomodal au multimodal. Classiquement,
l’interaction Homme-Machine privilégie la vue, le
toucher et l’ouie. Les autres sens humains sont négligés. Le projet Exhalia de France Telecom explore
l’olfactif. Lorque l’utilisateur navigue sur Internet,
des odeurs accompagnent les images. Les recherches
sont aujourd’hui prospectives, mais on pourrait imaginer, pour la sécurité, d’exprimer un danger ou d’en
renforcer le signal par une odeur diffuse.
L’utilisateur n’est alors plus rivé devant l’écran ou
le voyant. L’odeur est diffusée là où l’utilisateur se
trouve, satisfaisant ainsi l’exigence de retour
d’information telle qu’exprimée dans le référentiel
de C. Bastien et D. Scapin [3];
De l’explicite à l’implicite. Alors que les actions
physiques explicites de l’utilisateur sur les dispositifs d’entrée dirigeaient jusqu’ici l’interaction
Homme-Machine, elles perdent aujourd’hui leur
monopole. Désormais, la pièce peut vous écouter,
comprendre le propos du discours et en compléter la
teneur par des informations affichées, par exemple,
au mur. C’est de l’interaction implicite;
Du sédentaire au nomade. Jusqu’ici scotchées à leur
ordinateur d’exécution, les IHM "valsent" désormais
dans leur espace interactif, au gré de l’utilisateur,
selon l’arrivée et le départ de ressources. Elles migrent partiellement ou totalement, changeant ainsi
leur état de distribution et s’adaptant si nécessaire
aux capacités de la plate-forme cible. Typiquement,
dans les surfaces augmentées de Rekimoto [21], la
présentation des objets (tables et chaises) s’adapte à
l’inclinaison horizontale (vue de dessus 2D) ou verticale (perspective 3D) de la surface d’affichage (Figure 4).
rante de différentes façons et rajoute la date lorsque
ceci est possible (Figure 5). Cette forme de plasticité
est appelée remodelage: elle joue sur la présentation
des concepts du domaine et des tâches utilisateur
sans changer l’état de distribution de l’IHM: l’IHM
était centralisée sur une certaine machine M. Elle
reste centralisée sur cette même machine M.
Figure 5 : Dans FlexClock [11], la présentation de
l’heure et optionnellement de la date s’adapte à la taille de
la fenêtre. C’est un exemple de remodelage. A l’époque, la
plasticité n’était étudiée que sous cet angle.
C’est plus tardivement que la réflexion est élargie
comprenant que la métamorphose des IHM diversifie les leviers de plasticité. Par exemple, dans Sedan-Bouillon [2] (un site web pour la promotion des
pays de Sedan et Bouillon, site web plastique développé dans le cadre du projet européen CAMELEON), l’arrivée d’un PDA est vue comme
l’opportunité d’étaler l’IHM entre l’actuel PC et ce
nouveau PDA. Dans ce prototype, lorsque
l’utilisateur Lionel se ballade sur le site web à partir
d’un PC (log_Lionel_0 sur la figure 6a) et s’y
connecte subitement via un PDA (log_Lionel_1),
une proposition de redistribution lui est faite (Figure
6a): le site est structuré en un titre, une barre de navigation et un contenu. Lionel peut afficher là où il
le souhaite les différents espaces de travail. Lionel
choisit d’avoir le titre et le contenu sur PC (Figure
6b) et souhaite disposer sur PDA du titre et de la navigation (Figure 6c). Cette redistribution lui permet
de parcourir le site, confortablement installé dans
son canapé. On notera que, dans ce prototype,
l’adaptation est placée sous le contrôle de
l’utilisateur. Ce contrôle explicite requiert une IHM
(Figure 6a). Nous appelons méta-IHM cette IHM de
la plasticité. La méta-IHM est en charge de rendre
observable et contrôlable à l’utilisateur le processus
d’adaptation.
Figure 4 : Les objets s’affichent en 2D versus 3D selon
l’inclinaison de la surface d’affichage (table horizontale /
écran vertical) [21].
•
Du rigide au plastique. Alors que jusqu’ici les IHM
étaient "de marbre" répondant aux seules actions de
l’utilisateur, elles s’adaptent désormais à un contexte
d’usage changeant. On parle de plasticité lorsque
l’adaptation se fait dans le respect de l’utilisabilité.
Un exemple classique est celui de FlexClock [11]
qui, selon la taille de la fenêtre, affiche l’heure cou-
Si, dans la métamorphose des IHM, la multimodalité
(du monomodal au multimodal) est un moyen de
remodelage en plasticité, les autres axes relèvent de
81
la redistribution: "du centralisé au distribué" est une
redistribution de l’IHM sur la plate-forme; "du classique à l’exotique", une redistribution entre les
mondes physique et numérique; "de l’explicite à
l’implicite", une redistribution des tâches entre
l’utilisateur et le système, "du sédentaire au nomade", une redistribution dynamique. La redistribution est donc un levier fondamental à considérer en
cette période de métamorphose des IHM. Elle peut,
en pratique, être assortie d’un remodelage pour
s’accommoder de capacités différentes entre les
plates-formes source et cible. Par exemple, alors que
sur PC la barre de navigation figurait en bandeau
gauche, elle apparaît horizontalement en partie haute
sur PDA (Figure 6c).
Jusqu’ici les deux leviers (remodelage et redistribution)
ont été étudiés de façon cloisonnée (découverte progressive des difficultés et séparation des préoccupations). La
section suivante en propose un espace problème unificateur.
PLASTICITE DES IHM
La plasticité des IHM est une propriété des systèmes interactifs qui fut introduite en 1998 en réponse à la diversité des plates-formes [25]. Comme à l’évidence l’IHM
ne peut être la même sur grand et petit écran, l’idée était
de régler, par l’adaptation, les coûts de développement et
de maintenance ainsi que les incohérences ergonomiques
résultant de développements cloisonnés entre les versions petit et grand écran. Très vite, l’environnement est
considéré, l’utilisateur ensuite, pour enfin revenir à la
plate-forme comprenant que les IHM n’étaient plus seulement centralisées et sédentaires mais pouvaient se redistribuer au gré du contexte d’usage en termes
d’utilisateur, de plate-forme et d’environnement. La définition était alors posée.
(a)
Le sujet connaît très vite un vif engouement. Différents
angles d’attaque se dessinent, en particulier le multiciblage (méthodes et outils pour la construction d’IHM
adaptées à un contexte d’usage donné – pour exemple,
des outils de forward et reverse engineering tels que Teresa [4] ou WebRevenge [19]), l’information située [24]
et la technologie support dite «context aware computing» [7]. Ces différents éclairages confirment la complexité de l’ouvrage.
(b)
L’ambition de cette section est une prise de recul par
rapport aux différentes recherches pour établir un espace
problème unique regroupant et structurant les questions
clé de l’ingénierie d’IHM plastiques. La structuration
s’appuie sur la décomposition fonctionnelle présentée en
Figure 7. Cette décomposition fonctionnelle rappelle que
la plasticité s’appuie sur des fonctions de reconnaissance
du contexte d’usage; qu’elle consiste à calculer
l’évolution du système interactif sur changement de ce
contexte; que cette évolution peut être apprise; et enfin
que l’ensemble du processus peut être placé sous
l’observabilité et/ou le contrôle de l’utilisateur via une
méta-IHM. Cette section examine chaque fonction.
(c)
Figure 6 : (a) Méta-IHM rendant observable le contexte
d’usage (ici les plates-formes) et proposant à l’utilisateur
une redistribution. Lionel demande à disposer sur PC
(log_Lionel_0) du titre et du contenu (a et b) et placer sur
PDA (log_Lionel_1) la navigation et le titre (a et c).
Figure 7 : Décomposition fonctionnelle d’un système interactif
plastique.
82
Contexte d’usage
La redistribution joue sur l’éparpillement de l’IHM sur
les différentes plates-formes. On distinguera les redistributions qui conservent l’état centralisé d’une IHM (migration totale du PC vers le PDA; ces redistributions
sont notées CC sur la Figure 9 pour Centralisée vers
Centralisée), l’éclatent la faisant passer d’un état centralisé à distribué (c’est le cas de Sedan-Bouillon où le site
se répartit entre le PC et le PDA; elles sont notées
CD); la reconcentrent sur une unique plate-forme, la
faisant ainsi passer d’un état distribué à centralisé
(DC) ou en changent l’état de distribution (DD).
Dès lors que l’IHM est distribuée, il convient de réfléchir
au rôle de chaque plate-forme. Sont-elles par exemple
complémentaires en charge chacune d’un sous-ensemble
des tâches utilisateur? Agissent-elles en totale équivalence permettant à l’utilisateur de réaliser sa tâche soit
sur le PC soit sur le PDA, à sa convenance ? On voit que
les propriétés CARE [5] (Complémentarité, Assignation,
Redondance, Equivalence) sont ici pertinentes pour raisonner sur la distribution de l’IHM.
Si dans la définition de la plasticité, le contexte d’usage
est défini en termes d’utilisateur, de plate-forme et
d’environnement, dans les faits, les travaux se cloisonnent selon la couverture faite du contexte d’usage. Certains se focalisent sur l’adaptation à l’utilisateur [8];
d’autres sur l’adaptation à la plate-forme [2] tandis que
l’environnement reste à notre connaissance encore peu
considéré. Reconnaître le contexte d’usage, c’est en
premier lieu le percevoir. Dans les travaux de Crowley
[6], la perception est dirigée par l’action: ne sont perçus
dans le contexte que les éléments jugés pertinents pour
diriger l’action, c’est-à-dire l’adaptation. Un modèle de
contexte définit les indices à percevoir, par exemple
«batterie faible » qui déclenchera un changement de situation. Le contexte est modélisé comme un graphe de
situations. Les actions (par exemple, migrer vers la plateforme la plus proche) sont attachées aux changements de
situation. Les avantages de l’approche sont nombreux:
(a) restreindre la perception à son strict minimum; (b)
maintenir l’état courant du contexte et son historique. En
pratique, la perception du contexte requiert des capteurs.
Rey [22] propose des contexteurs pour la mise à disposition, au bon niveau d’abstraction, des informations de
contexte aux systèmes interactifs. Les fonctions
d’évolution disposent de ces informations pour calculer
et mettre en œuvre la bonne réaction (par exemple, migrer).
D’un point de vue de la mise en œuvre de la réaction
qu’elle soit de type remodelage et/ou redistribution, six
dimensions sont à considérer:
•
Evolution
L’évolution est en charge du calcul et de la mise en œuvre de la réaction. Deux leviers sont identifiés: le remodelage et la redistribution. C’est par l’étude du remodelage que les recherches en plasticité commencèrent. Un
premier résultat fut l’identification des niveaux
d’abstraction auxquels l’adaptation peut avoir lieu [26].
Le modèle d’architecture logicielle ARCH était mis à
profit pour distinguer cinq niveaux d’abstraction: le
noyau fonctionnel (NF), l’adaptateur de noyau fonctionnel (ANF), le contrôleur de dialogue (CD), les présentations logique et physique. Les recherches étaient alors
menées dans le seul cadre du graphique. Depuis, d’autres
modalités sont considérées, en particulier le vocal [4]. Il
devient alors pertinent de préciser si les modalités humaines sont préservées ou non lors du remodelage. On
parlera de remodelage intra-modal (par exemple graphique vers graphique) lorsque la modalité est préservée,
d’inter-modal (aussi dit transmodal, par exemple, graphique vers vocal) pour un changement de modalité et de
multimodal dès lors que des modalités sont combinées
(par exemple, graphique et vocal dans Teresa [4]).
L’intégration de la perspective système de la notion de
modalité telle que définie par L. Nigay [17] est un prolongement direct au travail.
•
•
•
83
La granularité de l’adaptation. L’adaptation se faitelle au grain de l’interacteur, compactant par exemple un jeu de boutons radio en un menu déroulant?
Se fait-elle au grain de l’espace de travail, c’est-àdire d’un ensemble de tâches logiquement connectées (modification d’un canevas ou d’une fenêtre en
graphique)? Ou modifie-t-elle au contraire toute
l’IHM?
La localisation interne (aussi dite close, notée I)
et/ou externe (aussi dite open, notée E) de
l’adaptation [18]. Il s’agit ici de décider qui de
l’IHM (interacteur, espace de travail ou application)
ou d’un tiers (un intergiciel de l’adaptation) embarque les mécanismes d’adaptation. Aucune recommandation n’existe sur le dosage d’interne/externe.
Des critères de performance ou d’ouverture peuvent
être typiquement considérés. Les approches à service poussent très fort à l’ouverture. L’opportunisme
qu’elles laissent percevoir (j’arrive à la gare, je dispose d’un service imprévu) va dans le sens de
l’informatique ambiante;
Les espaces technologiques au sens de l’Ingénierie
Dirigée par les Modèles (IDM ou Model Driven Engineering en anglais), par exemple, JAVA, HTML,
etc. …). L’adaptation est-elle intra-espace technologique (par exemple, JAVA vers JAVA), interespaces (par exemple, HTML vers JAVA) ou multiespaces combinant par exemple JAVA et HTML
avant et après transformation?
La production statique (S) et/ou dynamique (D) des
IHM. Les IHM sont-elles préfabriquées (statique)
•
•
rain est quasiment vierge en matière de méta-IHM: aucune théorie, aucun modèle, juste quelques idées de métaphores. Par exemple, nous envisageons les ciseaux (Figure 8a) ou les déchirures (Figure 8b) pour exprimer le
caractère détachable ou déchirable d’une IHM: détachable, l’utilisateur peut la découper pour éventuellement la
redistribuer; déchirable, c’est à ses risques et périls, une
perte d’utilisabilité pouvant s’encourir. Nous envisageons les aimants pour exprimer la compatibilité/incompatibilité d’IHM, les puzzles pour exprimer la
complémentarité (CARE). Le domaine du "End-User
Programming" est ici à examiner.
et/ou générées à la volée (dynamique)? Dans Artistic Resizing [9], c’est un mixte de statique et de dynamique qui est opéré. Les IHM sont préfabriquées
à des instants clé de l’interaction (échantillonnage et
création par des designers); les transitions sont calculées à la volée;
Le déploiement statique (S) ou dynamique (D) de
l’adaptation. L’utilisateur doit-il quitter sa session
(statique) le temps que l’adaptation se fasse ou
l’adaptation se fait-elle à la volée (dynamique) permettant, en parallèle, à l’utilisateur de poursuivre sa
tâche?
Le grain de reprise, qui permet de mesurer en termes
d’actions physiques le coût de l’adaptation pour
l’utilisateur. Trois grains sont identifiés: l’action
physique (l’utilisateur ne perd aucune action lors de
l’adaptation – dans Sedan-Bouillon, si l’utilisateur
avait sélectionné «Hotels» sur son site Web, cette
sélection est conservée lors de la migration de la
barre de navigation sur PDA: l’option «Hotels» y
est sélectionnée); la tâche (seules les tâches utilisateur achevées sont alors restaurées – les actions physiques contribuant à la réalisation d’une nouvelle tâche sont perdues); la session (l’utilisateur redémarre
de zéro: il a perdu le bénéfice de toutes ses actions).
a)
b)
Figure 8 : Vers de nouvelles métaphores. Ici, les ciseaux et les
déchirures pour exprimer le caractère détachable versus déchirable d’espaces de travail.
Apprentissage
L’apprentissage est une dimension nouvelle en plasticité.
L’idée serait ici d’ajuster les règles d’évolution (par
exemple, préférer les remodelages aux redistributions)
selon les préférences et habitudes utilisateur. Les travaux
en User Modeling entrent dans ce cadre.
La Figure 9 résume l’espace problème ainsi obtenu. Cet
espace problème est à destination des concepteurs pour
les aider à (a) imaginer des solutions innovantes et (b) se
poser les bonnes questions quant à leur ingénierie. Il ne
prétend pas à l’exhaustivité mais compile un ensemble
de questions en cours d’exploration dans la littérature ou
à investiguer.
Méta-IHM
La méta-IHM concerne le degré de contrôle accordé à
l’utilisateur dans le processus d’adaptation. Au regard du
critère de Guidage/sous-critère Retour d’information [3],
l’observabilité est le degré minimum. Au delà de cette
seule observabilité, une négociation peut être opérée entre l’utilisateur et le système. La dominance de
l’utilisateur ou du système est à étudier. Cette réflexion
est liée aux critères de contrôle explicite et d’adaptabilité
[3] qui méritent d’être ré-examinés sous cet angle.
CONCLUSION ET PERSPECTIVES
Cet article caractérise, dans un premier temps, la métamorphose des IHM puis se focalise sur la plasticité
montrant comment les autres dimensions y sont mises à
profit pour passer d’IHM rigides à des IHM capables de
s’adapter à leur contexte d’usage. Un espace problème
est dressé, compilant des questions essentielles pour
l’ingénierie d’IHM plastiques. Au delà des modèles,
méthodes et outils permettant la construction, l’exécution
et l’évaluation de telles IHM, nous voyons comme perspective au travail l’utilisabilité. Alors que la plasticité
revendique dans sa définition la préservation de
l’utilisabilité, très peu de travaux sont paradoxalement
menés sur cet axe. Des premières règles de dégradation
élégante d’IHM apparaissent [10] sans qu’une conciliation et intégration ne soit faite, à notre connaissance,
avec les référentiels existants. Le sujet est loin d’être clos
s’ouvrant sur de nombreuses communautés.
Dans le processus d’adaptation, nous distinguons cinq
étapes sujettes à observabilité et/ou contrôle: la reconnaissance du contexte d’usage (rendre observable à
l’utilisateur l’arrivée d’un PDA par exemple);
l’initiative de l’adaptation, le calcul et la mise en œuvre
de la réaction (migrer vers le PDA) et enfin l’évaluation
de la réaction et son apprentissage. Ces étapes sont un affinement de Dieterich [8].
Contrairement aux autres fonctions de l’adaptation
(contexte, évolution, apprentissage) qui ont déjà fait
l’objet de travaux à finalité de plasticité ou autre, le ter-
84
Figure 9 : Espace problème de la plasticité. Dans cet espace, les croix (+) dénotent des valeurs non exclusives contrairement aux tirets (-).
.
BIBLIOGRAPHIE
1.
2.
Antoniac, P., Pulli, P., Kuroda,T., Bendas, D., Hickey, S., Sasaki, H. Wireless User Perspectives in Europe: HandSmart Mediaphone Interface, Wireless
Personal Communications, Vol. 22, pp. 161-174,
2002.
Balme, L., Demeure, A., Barralon, N., Coutaz, J.,
Calvary, G. CAMELEON-RT: A Software Architecture Reference Model for Distributed, Migratable,
and Plastic User Interfaces, Lecture Notes in Computer Science, Volume 3295 / 2004, Ambient Intelligence: Second European Symposium, EUSAI 2004,
Markopoulos P., Eggen B., Aarts E. et al. (Eds),
Springer-Verlag Heidelberg (Publisher), ISBN:3540-23721-6, Eindhoven, The Netherlands, November 8-11, 2004, pp. 291-302.
85
3.
Bastien, J.M.C., Scapin D. Ergonomic Criteria for
the Evaluation of Human-Computer Interfaces,
Rapport technique INRIA, N°156, Juin 1993.
4.
Berti, S., Paternò, F. Migratory multimodal interfaces in multidevice environments. In Proc. International Conference on Multimodal Interfaces, ACM
Publ., 2005, pp. 92-99.
5.
Coutaz, J., Nigay, L., Salber, D., Blandford, A.,
May, J., Young, R. Four Easy Pieces for Assessing
the Usability of Multimodal Interaction: The CARE
properties, Proceedings of the INTERACT'95 conference, S. A. Arnesen & D. Gilmore Eds., Cha pman&Hall Publ., Lillehammer, Norway, June 1995,
pp. 115-120.
6.
7.
Crowley, J.L., Coutaz, J., Rey, G., Reignier, P. Perceptual Components for Context-Aware Computing,
UbiComp 2002:Ubiquitous Computing, 4th International Conference, Göteburg, Sweden, Sept./Oct.
2002, G. Borriello, L.E. Holmquist Eds., LNCS,
Springer Publ., pp. 117-134.
15. Myers, B.A. "Using Hand-Held Devices and PCs
Together," Communications of the ACM, Volume
44, Issue 11, November 2001, pp. 34 – 41.
16. Norman, D.A., Draper, S.W. User Centered System
Design, Lawrence Erlbaum Associates, Publishers,
1986.
Dey, A. Providing Architectural Support for Building Context-Aware Applications, PhD thesis, College of Computing, Georgia Institute of Technology,
December 2000.
17. Nigay, L. Conception et modélisation logicielles des
systèmes interactifs : application aux interfaces
multimodales, Thèse de doctorat Informatique préparée au Laboratoire de Génie Informatique
(IMAG), Université Joseph Fourier, 28 janvier 1994,
315 pages.
8. Dieterich, H., Malinowski, U., Kühme, T., SchneiderHufschmidt, M. State of the Art in Adaptive User
Interfaces, in Adaptive User Interfaces: Principles
and Practice, Schneider-Hufschmidt & al. (ed.),
1994, pp. 13-48.
18. Oreizy, P., Taylor, R., et al. An Architecture-Based
Approach to Self-Adaptive Software. In IEEE Intelligent Systems, May-June, 1999, pp. 54-62.
9. Dragicevic, P., Chatty, S., Thevenin D., Vinot J-L.
Artistic Resizing: A Technique For Rich ScaleSensitive Vector Graphics. In: Proc. of the 18th
ACM Symposium on User Interface Software and
Technology (UIST'’05), Seattle, October 23-26,
2005, ACM Press, pp. 201-210.
19. Paganelli, L., Paternò, F. Automatic Reconstruction
of the Underlying Interaction Design of Web Applications, Proceedings of SEKE 2002, Ischia, Italy,
July 2002.
20. Rekimoto, J. Pick-and-Drop: A Direct Manipulation
Technique for Multiple Computer Environments,
Proceedings of UIST'97, ACM Press, 1997, pp. 3139.
10. Florins, M. Vanderdonckt, J., Graceful Degradation
of User Interfaces as a Design Method for Multiplatform Systems, in Proceedings of the 2004 International Conference on Intelligent User Interfaces IUI
2004, Funchal, Madeira Island, Port., January 13-16,
2004, pp. 140-147.
21. Rekimoto, J., Saitoh, M. Augmented Surfaces: A
Spatially Continuous Workspace for Hybrid Computing Environments, Proceedings of CHI'99, ACM
Press, 1999, pp. 378-385.
11. Grolaux, D., Van Roy, P., Vanderdonckt, J. FlexClock: a Plastic Clock Written in Oz with the QTk
Toolkit, In: Proceedings de TAMODIA 2002 (First
International Workshop on Task Models and Diagrams for User Interface Design), Bucharest, 18-19
july 2002, ISBN: 973-8360-01-3, Pribeanu, C.,
Vanderdonckt, J. (eds), INFOREC Publishing House
Bucharest, 2002, pp. 135-142.
22. Rey, G. Contexte en Interaction Homme-Machine :
le contexteur, Thèse de l’Université Joseph-Fourier,
Grenoble I, 1er août 2005, 186 pages.
23. Ryokai, K., Marti, S., Ishii, H. Designing the World
as Your Palette, In CHI’05 extended abstracts on
Human factors in computing systems, Portland, OR,
ACM Press, April 2-7, 2005, pp. 1037-1049.
12. Ishii, H., Wisneski, C., Brave, S., Dahley, S., Gorbet, M., Ullmer, B., Yarin, P. Ambient Room, Video
at the ACM CHI’98 conference, 1998.
24. Suchman, L. Plans and Situated Actions, Cambridge
University Press, 1987.
25. Thevenin, D., Coutaz, J. Plasticity of User Interfaces: Framework and Research Agenda. In Proc. Interact’99, Edinburgh, Sasse, A., Johnson, C. Eds,
IFIP IOS Press Publ., 1999, pp.110-117.
13. Lachenal, C. Modèle et infrastructure logicielle pour
l’interaction multi-instrument multisurface, Thèse
de l’Université Joseph-Fourier, Décembre 2004, 200
pages.
26. Thevenin, D. L’adaptation en Interaction HommeMachine: le cas de la plasticité, Thèse de doctorat
Informatique préparée au Laboratoire de Communication Langagière et Interaction Personne-Système
(CLIPS), Université Joseph Fourier, Décembre
2001, 238 pages.
14. Myers, B., Hudson, S.E., Pausch, R. Past, Present,
and future of user interface software tools, A C M
Transactions on Computer-Human Interaction
(TOCHI), Volume 7, Issue 1, Special issue on human-computer interaction in the new millennium,
Part 1, March 2000, pp. 3–28.
86
Importance of peer-to-peer ad hoc collaboration in the
development of large software systems
Sébastien Cherry
Pierre-N. Robillard
Département de génie informatique
École Polytechnique de Montréal
C.P. 6079 succ Centre-ville
Montréal, Qc. Canada, H3C 3A7
[email protected]
Département de génie informatique
École Polytechnique de Montréal
C.P. 6079 succ Centre-ville
Montréal, Qc, Canada, H3C 3A7
[email protected]
ABSTRACT
Software development is an intensive cognitive task in
which co-located team-mates experience peer-to-peer
collaboration, which is composed of face-to-face communications and in e-mail interactions. Global software
developments are oriented toward the use of interactive
software tools to support and increase the efficiency of
globally distributed software developments. This empirical study explores the mechanisms of ad hoc collaboration in a complex industrial software development environment. Observations based on audio-video recording
are analyzed with a methodology from the human sciences research domain. The observed characteristics of
peer-to-peer ad hoc collaborative activities are presented, showing the impact of the participant roles on the
ad hoc communications profile. There is a very great
need for ad hoc face-to-face communications in colocated team-work, and these could represent up to 30%
of the total team time resources. E-mail interactions were
found to be relatively less important. The various profiles
of ad hoc communications are compared and global
communications patterns are presented.
KEY WORDS: Ad hoc collaborations, face-to-face communications, e-mail interactions, empirical studies, team
collaborative activties, communications profiles.
This shortcoming, according to Perry, Staudenmayer and
Votta [8], is primarily the result of the difficulty in quantitatively measuring the human facets of engineering.
However, as observed by Seaman [11], more and more
studies have been aimed at measuring the so-called “people factors”. Of these factors, communication [12], coordination [4,5] and collaboration [10] among software engineers are relevant aspects on which a number of researchers have focused in the past few years.
Along a similar line of study, Perry, Staudenmayer and
Votta, who are pioneers in the field, tried to describe
how developers spend their time as a software development project unfolds [8]. Their study showed, among
other things, that developers spend 75 minutes per day
on unplanned informal communications. This observation was later supported by Robillard and Robillard in
their study of the different types of collaborative work
performed in software engineering [10]. These types are:
mandatory meetings, called or scheduled meetings, ad
hoc meetings and individual work. A later study by
D’Astous and Robillard [3] analyzed the patterns of exchange between team-mates during called meetings.
These meetings are scheduled in advance and are mostly
peer-review meetings. They built a model to represent
the qualitative and quantitative importance of the various
exchanges that occur during these meetings.
INTRODUCTION
Software engineering is becoming increasingly recognized as a human experience, in spite of the fact that the
human aspects of software development have been studied little in the past. The whole system is quite complex,
since humans interact with computers through various
software tools, and they also interact among themselves
to share information and synchronize their mental model
of the system to be designed. With the rise in global
software development, numerous software tools are being built to facilitate distributed development and team
interaction. We realized that not much is known about
human interaction in co-located teams, which is essentially ad hoc and based on peer-to-peer collaborations
and e-mail exchanges.
87
Ad hoc collabaorations are more difficult to study, given
their spontaneous nature. They are nevertheless important, since they account for a significant amount of the
time spent on a software project, as observed by Perry
and his colleagues. These observations convinced them
of the importance of these activities to team dynamics, a
conviction shared by many other authors in subsequent
studies. Herbsleb and Grinter [5] and Seaman and Basili
[12] come to mind. Despite a fairly large consensus, no
known study has yet described and characterized ad hoc
collaborative activities and their corresponding communications patterns.
These studies are important for measuring the impact of
new technologies such as e-mails and chats on the efficiency of team interaction in building large and complex
software projects.
col was approved by an independent committee at the
École Polytechnique de Montréal, which is mandated to
supervise research with human subjects. An Ethics Certificate was issued for this research.
RESEARCH METHODOLOGIES
The issue of potential bias due to the presence of the
camera was addressed by beginning to record three
weeks before our desired start date in order to allow our
subjects, who were not aware of this buffer period, to become accustomed to the presence of the camera, thus reducing bias to a minimum.
During the course of this research, the observer acts as a
complete participant for several reasons, the most important being that the topic of this research was to study the
efficiency of ad hoc collaborative activites, including
their content [1]. The nature of the interactions between
the observed software developers required that the observer be in a position to understand the jargon used by
observers in their everyday work, as well as the culture
of the organization and the sub-culture of the team [6].
Thus, in order to reach this level of understanding, the
observer had to become involved fairly actively in the
activities of the group. In addition, in order to observe
situations that were as valid as possible, the observer had
to adopt the viewpoint of an insider, and thus, as discussed above, become an insider himself. However, to
avoid introducing subjectivity into the research, the data
were validated and analyzed by researchers who were not
involved with the team studied.
Our observations, based on audio-video recording, were
made on a software development team performing in a
large software development organization. This team was
composed of 13 individuals ranging widely in age, with
different levels of schooling from bachelor’s to doctoral
degrees in the computer sciences and engineering, and
experience ranging from 2 to 16 years in the field and
from 9 months to 5 years of service in the company. In
addition, even though this team is evolving within a large
software organization having a highly standardized process and comprising several thousand software developers
in several countries, the setting has the attributes of
smaller organizations as well, since development is divided among a number of small teams of up to 15 members each, often located in one place. However, developers regularly need to cooperate with stakeholders from
remote locations and in different time zones. This is because they are organized according to their functional
expertise as well as by product areas or software components, all of which are ultimately tightly integrated to
form a enormous solution of millions of lines of code. In
this complex context, collaboration with a wide range of
experts is essential.
The observation phase was conducted in two successive
periods. The first, which we have called the ethnographic period, occupied a time interval of several
months during which the observer was integrated within
the group as a regular employee.
All the necessary measures were put into place to guarantee the ethical use of recordings, and our research proto-
88
The audio-video recording was combined with other
methods, including the automatic copying of all electronic e-mail messages exchanged between the members
of the group by means of the messaging software used in
the company, a daily backup of the source code of the
software developed from the versioning system, as well
as all the files found on the file server used by the team
where working documents were stored. With the audiovideo recordings and e-mail messages, we were confident
that we could capture some of the complexity of the cognitive behaviors of software developers in a complex environment. Then, during the two months of the observation and data collection phase, we gathered the following
data:
•
nearly 200 hours of audio-video recordings of
working sessions;
•
around 2,500 e-mail messages exchanged between team-mates;
•
daily backups of the source code from the versioning system;
•
all the documents found on the file server
shared by the team.
This paper reports on the analysis of the peer-to-peer ad
hoc collaborations, which is composed of face-to-face
(F2F) communications and the e-mail interactions.
DATA VALIDATION
A detailed analysis was performed on the data obtained
from four of the twelve members of the team observed.
These subjects were chosen because, through a judged
sampling, they were identified during our ethnographic
phase as presenting a much more representative behavior
than the others.
A stratified sample of working sessions was analyzed,
and, from that first sample, a number were removed in
order to discard bias due to nonrepresentative sessions,
where some of the subjects were absent or involved in
formal meetings, which prevented them from collaborating with their colleagues as they usually did. Finally,
nearly 35 hours of audio-video recordings were analyzed,
during which a total of 431 ad hoc collaborative activities were observed involving our four subjects interacting
with one another, as well as with other stakeholders.
SUBJECT ROLES
The observations of the team-mates in their normal dayto-day activities prior to the beginning of recording
made it possible for us to identify the role of each of the
four subjects within the team dynamics.
•
•
The rookie (MS1) is the new recruit on the
team. He tries to gather, consolidate and crystallize all the pieces of information in order to understand the environment as well as the technical content related to developing and maintaining software.
The coach (MS2) is the project manager who
occupies the formal leadership position. His interests are centered as much on the task as on
the person, hoping for little more than adequate
output while he tries to convince and motivate
his subordinates by making occasional compromises.
•
The reference (MS3) is responsible for configuration management. While he is not to be considered a guru, he is a fount of knowledge for
his colleagues, who often ask him for information or help in solving problems.
•
The cooperator (MS4) does not play any specific formal or informal role on the team. He is
the embodiment of the average developer, performing his tasks well and cooperating fruitfully
with his colleagues.
MEASUREMENTS OF AD HOC COLLABORATIONS
Ad hoc collaborations were identified as activities forming a logical communicative unit of one or more sequences that presents an evident internal continuity,
while at the same time being distinct from what precedes
or follows it, as defined by [7]. We recall the very specific nature of these collaboration, which are spontaneous, unplanned and of unknown duration. Ad hoc activities, by contrast, are seen by most of the subjects as an
interruption of what they are doing.
Figure 1 illustrates the importance of ad hoc collaboratons. It shows the average percentages of ad hoc collaborative work observed for each subject throughout the total length of the analyzed recording.
For example, MS1 spends 21% of his total working time
on ad hoc activities. The two subjects who exhibit leadership in one form or another (MS2 or MS3) spend more
89
time on ad hoc collaboration than the other two subjects.
The coach and the reference roles accounted for 29% and
41% of their total time spent on ad hoc collaborative activities respectively. As for the rookie, MS1, and the cooperator, MS4, they spent an average of 21% and 25%
percent respectively.
50
41
40
%
30
Ad Hoc
Activities 20
29
25
21
10
0
MS1
MS2
MS3
MS4
Participant
Figure 1. Average percentages of ad hoc collaborative
work observed per participant.
On a team basis, the ad hoc activities account for almost
30%, on average, of all their activities. Ad hoc collaborations are only one component of collaborative activities.
The other two main collaborative activities are scheduled
meetings and mandatory meetings. Team-mates also perform individual work.
Ad hoc activities must be initiated by someone. Figure 2
shows the percentage of interactions initiated by each
subject. For example, MS1 was involved in 108 ad hoc
collaborations, of which he initiated 69, which adds up to
64%. The rookie, MS1, initiated almost twice as many
ad hoc collaborations as the other team members. This
makes sense, since the rookie was new to the team and
on his way up the learning curve. His efficiency depends
on gathering more information than the other players.
This data may quantify the belief that adding someone
new to a project that is late will just delay the project further, since many ad hoc collaborations are initiated by
the newcomer to catch up with the team expertise.
ad hoc communications is always synchronous, while email interactions could be asynchronous.
80
60
%
Initiated 40
Ad Hoc
Activities 20
We studied the exchange of e-mail messages to see how
this collaboration mechanism compares to F2F communications within this project environment.
0
e-mail messages
MS1
MS2
MS3
MS4
60
Team
50
Participant
EXT
40
30
Figure 2 Percentage of ad hoc collaborations initiated by
the participants.
The four observed participants worked as a team on a
few components of a large project. In the course of their
tasks, they needed to interact with the other 13 participants making up the larger group, and also with three
people from outside this larger project group. At the
same time, people from outside the observed team
needed to interact with the team members.
70
60
Team
50
EXT
40
30
20
10
0
Replied
Initiated
M S1
Replied
Initiated
M S2
Replied
Initiated
Replied
M S3
Initiated
M S4
Figure 4. Number of e-mail messages responded to and
initiated from within and from outside the team.
Figure 4 shows that e-mail interaction was not used intensively within the team. The team members seemed to
prefer F2F communications. However, e-mail was extensively used by MS2, the manager, to interact with
people outside the team, and, by the same token, they
used e-mail to interact with him. Comparing Figures 3
and 4, we see that MS2 is the only team member with as
many e-mail interactions as F2F communications.
20
PATTERNS OF AD HOC COLLABORATIONS
10
Ad hoc collaboration, F2F communications and e-mail
interactions constitute an important component of colocated team dynamics. Below, we integrate the data of
all the participants to derive general patterns of ad hoc
activities.
0
Replied Initiated Replied Initiated Replied Initiated Replied Initiated
MS1
MS2
MS3
MS4
Figure 3. Number of ad hoc collaborations responded to
and initiated from within and from outside the team.
Figure 3 presents the number of ad hoc collaborations
initiated from within and from outside the team for each
observed participant. For example, looking at the second
pair of columns, starting from the left, we see that MS1
initiated almost 40 ad hoc collaboarations with his teammates, while he responded to almost 30 ad hoc collaborations from someone outside the team. We observe that
there is almost as much collaborations between the teammates as with people outside the team. MS2, who occupies the role of manager, is the main link for ad hoc collaborations coming from outside the team, as expected.
The Internet, and specifically e-mail interaction, is an
important tool for facilitating written ad hoc collaborations, particularly in the software development environment. However, there is an important difference between
F2F ad hoc communications and e-mail interactions. F2F
90
The box on the right-hand side of Figure 5 represents the
team activities of the four observed participants. In it,
we represent the relative percentages of ad hoc collaboration within the team. The upper round arrows indicate
that 17% of the total number of ad hoc collaborations are
F2F communications among the four observed team
members, while the lower round arrows indicate that 4%
of the total team collaboration are e-mail interactions
among the same participant.
The ad hoc activities involving people outside the observed team are represented by the straight and broken
arrows on the left-hand side of the team box. The tail of
the arrow indicates the origin of those activities. An arrow originating on the left and pointing to the box represents ad hoc activities that are initiated by people outside
the team for which observed teammates are responding
to. An arrow originating from within the team box and
pointing toward the left to the outside represents ad hoc
activities that are initiated by one of the four team mem-
bers. Straight arrows represent F2F communications, and
broken arrows e-mail interactions.
Ad hoc collaboration profile
F2F communications and
e-mail interactions
Responded to
Face-to-face
point from and toward those outside the team, namely 13
other individuals in the organization who have collaborated with the observed participants. Each arrow pointing
away from or toward those outside the team refers to the
total number of ad hoc collaborations among any of the
18 people involved. For example, MS1 initiated 36 ad
hoc collaborations with someone outside the team of four
observed participants, and 41 ad hoc collaborations were
initiated by someone outside the team.
23%
Face-to-face
17%
16%
11%
E-mail
4%
9%
E-mail
Initiated
Figure 5. Overview of face-to-face communications and
e-mail interactions.
The upper arrow pointing to the right, toward the team
box, indicates that 23% of the ad hoc F2F communications with one of the team-mates were initiated by a person outside the observed teammates. The second upper
arrow pointing to the left, away from the team box, indicates that 16% of the ad hoc F2F communications were
initiated by one of the team-mates to a person outside the
team. The broken arrow second from the bottom, pointing toward the team box, indicates that 11% of the ad
hoc e-mail interactions were initiated by a person outside
the team. The broken arrow at the bottom, pointing to the
left, away from the team box, indicates that 9% of the ad
hoc e-mail interactions were initiated by one of the teammates to people outside the team.
We see that F2F communications is still the dominant
means for people to collaborate, both within the team
and with people outside the team. It should be remembered that this study was conducted on a co-located team,
and that the dynamics of ad hoc collaborations could be
quite different within teams whose members are scattered.
Figure 6 shows some of the previously presented results,
combined in the form of a path analysis of the ad hoc
collaboration network between the participants and other
stakeholders. This diagram stresses the main characteristics of the four participants and their respective roles.
The size of the bubbles represents the relative proportion
of all collaborations in which each particpant was involved. The size of the arrows depicts the relative number of collaborations initiated by the particpant from
whom the arrow originates, and directed to the participant toward whom the arrow is directed. For example,
the communication channel MS1-MS2 has 13 communications through MS2, and 8 through MS1. Arrows also
91
Figure 6. Path analysis of the ad hoc collaboration network between the participants and other individuals
Figure 6 presents, in detail, the ad hoc collaboration patterns between the team of observed participants and people outside the team. The rookie (MS1) has absorbed information from the team. He mostly initiated ad hoc collaborations to obtain information, as is shown by the fact
that there are large arrows pointing away from MS1, and
he is rarely involved in responding to requests from
within the observed team. This is a quantitative demonstration of the impact of a newcomer on the team dynamics.
The cooperator (MS4) was involved with the opposite
situation, as shown by the fact that there are many large
arrows pointing toward him, which indicates that people
have been asking him questions. He was more often interrupted by ad hoc collaborations than he was initiating
ad hoc collaborations. This pattern quantitatively confirms his cooperator status. He communicates information in F2F relationships with his colleagues, even
though he was not involved in a significantly higher percentage of collaborations than the rookie.
The reference (MS3) shows an interesting pattern. He
seems to have transferred the information from the outside world to the team. There is a large flow of information coming in from outside, and this flow is propagated,
through him, to the team, specifically toward MS2 and
MS4. We may recall that MS1 is a junior team member,
and so is not likely to have answers to the questions
posed by MS3. These data quantify the importance of the
reference role to the team dynamics.
The coach (MS2) was the main ad hoc collaborator with
people outside the team. It is interesting to note that the
input from outside the team is almost as important as that
for MS4, but, in this case, there is no pattern of internal
propagation of the information. MS4 was probably processing the information himself. His ad hoc collaboration
with the other team members are more balanced.
CONCLUSION
This paper presented an empirical study conducted in an
industrial software engineering setting with the objective
of measuring and analyzing the complexity of the ad hoc
collaborative activities observed in a professional software development team. Ad hoc collaborations have
been observed in previous studies, but, up to now, there
has been little published research on this type of activity,
even though it may account for a fairly large proportion
of the time spent on a software project. Observational
approaches borrow from the social sciences, enabling us
to quantitatively measure the activities sustaining ad hoc
collaborations.
Such studies reveal the importance of face-to-face communications in team activities. This study was conducted
in a high-technology environment with experts in software engineering. It is interesting to note that e-mail interactions is not the main channel for collaboration in
this setting. Personal contact is an important parameter in
team activities. Viewed from the outside, the team seems
have good cohesion and capable of working on this project autonomously. This analysis shows that, although the
team has good internal cohesion, the members collaborate with the outside world as much as they do among
themselves.
The need for collaboration in a complex environment is
shown to be very important. The ergonomics of the
working space for a software development project should
take this into account.
training is available. Ad hoc collaboration is a kind of
‘just in time’ learning. Some people are friendly and collaborate with everyone, and others act as a kind of a guru
who is a resource for all. The cooperator subject of this
study exhibited this pattern. This individual is an important team member, either because of his knowledge or his
ability to help others, or both. Undue pressure on him for
task completion is likely to affect some team members,
since a number of teammates rely on him. It is generally
acknowledged that managers are fairly busy. In this
study, we can see that his ad hoc collaborations with individuals outside the team are more important than those
with the observed team-mates.
Software development is becoming so complex that team
activities are required in most projects. Team activities
based on human collaboration are requirements for the
emergence of design and new ideas. The social sciences
have proven sets of methods and research paradigms to
study human collaboration. This paper illustrates how
these approaches can be used to derive the exchange patterns of ad hoc collaboration in a team project.
Our study provides a deep understanding of the human
activities performed within a software development team,
and enables us to better understand and quantify the various roles of participants. Although this case study is
based on the observation of a specific organization,
which constitutes the primary limitation of this type of
research, the results can be extrapolated to some extent
to a broader set of contexts, any software development
organization for example, and possibly any team setting
with similar dynamics.
ACKNOWLEDGMENT
This research would not have been possible without the
agreement of the company in which it was conducted,
and without the generous participation and patience of
the software development team members from which the
data were collected. To all these people, we extend our
grateful thanks. This research was supported in part by
NSERC grant A-0141.
BIBLIOGRAPHY
This study provides some quantitative basis for evaluating the cost of ad hoc collaborations with respect to the
various roles. The reference subject plays an important
role in that he is a channel of communication between the
team and people outside the team. A significant amount
of his time is devoted to this activity. The manager
should take this into account in planning the reference
subject’s tasks.
This analysis stresses the importance of participant roles
in ad hoc collaborations. New team members need to
achieve team-level expertise, and, in order to do so, they
need to communicate on an ad hoc basis even if formal
92
1. Babbie, E. R., The practice of social research, Belmont, CA: Wadsworth Thomson Learning, 2001.
2. Brennan, R. L. and Prediger, D. J., Coefficient
Kappa: Some Uses, Misuses, and Alternatives Educational and Psychological Measurement, vol. 6, pp.
687-699, 1981.
3. d'Astous, P. and Robillard, P. N., Empirical study of
exchange patterns during software peer review meetings Information and Software Technology, vol. 44,
no. 11, pp. 639-48, August 15, 2002.
4. Grinter, R. E., Herbsleb, J. D., and Perry, D. E., "The
geography of coordination: dealing with distance in
R&D work," Proceedings of GROUP 99: Conference
on Supporting Group Work, 14-17 Nov. 1999, pp.
306-315, 1999.
5. Herbsleb, J. D. and Grinter, R. E., "Splitting the organization and integrating the code: Conway's law revisited," Proceedings of the 21st International Conference on Software Engineering (ICSE '99), 16-22
May 1999, pp. 85-95, 1999.
6. Jorgensen, D. L., Participant observation: a methodology for human studies, Newbury Park, Ca.; London: Sage Publications, 1989.
7. Kerbrat-Orecchioni, C., Les interactions verbales
Anonymous1998. Linguistique. Paris
8. Perry, D. E., Staudenmayer, N. A., and Votta, L. G.,
People, organizations, and process improvement
IEEE Software, vol. 11, no. 4, pp. 36-45, 1994.
93
9. Popping, R., On agreement indices for nominal data.
In: Sociometric research, eds. Saris, W. E., Gallhofer,
I. N., and International Sociological Association.
Basingstoke: Macmillan, 1988.pp. 90-105.
10. Robillard, P. N. and Robillard, M. P., Types of collaborative work in software engineering, Journal of
Systems and Software, vol. 53, no. 3, pp. 219-224,
September 15, 2000.
11. Seaman, C. B., Qualitative methods in empirical studies of software engineering, IEEE Transactions on
Software Engineering, vol. 25, no. 4, pp. 557-572,
July 1999.
12. Seaman, C. B. and Basili, V. R., Communication and
organization in software development: an empirical
study, IBM Systems Journal, vol. 36, no. 4, pp.
550-563, 1997.
Pour une meilleure prise en compte des opérateurs
dans la conception de nouveaux produits à partir d'une
démarche d’évaluations combinées de l’activité
-RKQ)pQL[
-HDQ&ODXGH6DJRW
&ODXGH9DORW
Chemins de fer fédéraux
suisse, Brückfeldstrasse 16,
CH-3000 Bern 65
[email protected]
Université de Technologie
Belfort-Montbeliard,
Laboratoire Système et
Transport, F-90010 Belfort
Cedex
[email protected]
Institut de Médecine
Aérospatiale du Service de
Santé des Armées, BP 73, F91220 Brétigny sur Orge
Cedex
[email protected]
KEYWORDS : 'HVLJQ RI QHZ SURGXFWV (UJRQRPLFV
&RPELQHGHYDOXDWLRQVRIDFWLYLW\
RESUME
1RV WUDYDX[ V
LQWpUHVVHQW j XQH PHLOOHXUH SULVH HQ
FRPSWH GHV VDYRLUV HW VDYRLUIDLUH GHV RSpUDWHXUV GDQV
OH SURFHVVXV GH FRQFHSWLRQ HW GH GpYHORSSHPHQW GH
QRXYHDX[SURGXLWV)DYRUDEOHjO
LGpHG
XQHHUJRQRPLH
GLWH WRWDOH GDQV OH SURFHVVXV F
HVWjGLUH G
XQH
HUJRQRPLH TXL VH GRQQH OHV PR\HQV GH VXLYUH OD
FRQFHSWLRQ GX GpEXW j OD ILQ QRV WUDYDX[ PHWWHQW HQ
OXPLqUH OHV DYDQWDJHV G¶XQH ©GpPDUFKH G¶pYDOXDWLRQV
FRPELQpHV GH O¶DFWLYLWpª &HWWH GpPDUFKH SHUPHW HQ
HIIHW G
LQWpJUHU GqV OH GpEXW GX SURFHVVXV OD IRQFWLRQ
G
XVDJH HW G
pOLPLQHU WUqV W{W OHV SUHPLHUV SUpFRQFHSWV
TXL QH FRUUHVSRQGHQW SDV DX[ DWWHQWHV HW EHVRLQV FH
TXH QRXV DYRQV DSSHOp OHV YXOQpUDELOLWpV 'qV ORUV
O¶pPHUJHQFH UDSLGH G¶XQ FRQFHSW GH SURGXLW FRQVLGpUp
DFFHSWDEOH SRXU O¶HQVHPEOH GHV DFWHXUV GX JURXSH
SURMHW HVW IDFLOLWpH /D GpPDUFKH SUpVHQWpH WUDGXLW XQ
UpHOLQWpUrWSRXUXQHFRQFHSWLRQTXLVHYHXWFHQWUpHVXU
O
KRPPHIDFWHXUGHVpFXULWpHWG
HIILFDFLWp
INTRODUCTION ET PROBLEMATIQUE
/
REMHFWLI GX SUpVHQW WUDYDLO HVW GH SURSRVHU XQH
GpPDUFKH SRXU XQH PHLOOHXUH SULVH HQ FRPSWH GHV
VDYRLUV HW VDYRLUIDLUH GHV RSpUDWHXUV GDQV OD
FRQFHSWLRQ GH SURGXLWV QRXYHDX[ HQ O
RFFXUUHQFH XQ
V\VWqPH G
DLGH j OD FRQGXLWH IHUURYLDLUH &HWWH
GpPDUFKH VH GRQQH SRXU DPELWLRQ GH IDYRULVHU OD
VpFXULWpO¶HIILFDFLWpHWOHFRQIRUWGDQVOHWUDLWHPHQWGHV
LQIRUPDWLRQV SDU OHV FRQGXFWHXUV HW DLQVL DPpOLRUHU OD
SHUIRUPDQFH HW O¶HIILFDFLWp GX V\VWqPH WRXW HQWLHU
pWXGLp
/DSULVHHQFRPSWHGHVVSpFLILFLWpVGHVXWLOLVDWHXUVGRLW
SHUPHWWUH GH SURSRVHU ©XQ HVSDFH SRXU XQH
WHFKQRORJLH SOXV KXPDLQH TXL QH UHQRQFHUDLW SDV
SRXU DXWDQW j OD SHUIRUPDQFHª >@ &HWWH SULVH HQ
FRPSWHSDVVHSDUO¶XWLOLVDWLRQGHPpWKRGHVG¶pYDOXDWLRQ
GHO¶DFWLYLWpIXWXUHTXLSRXUrWUHHIILFDFHGRLWrWUHPLVH
HQ°XYUHDXSOXVW{WGDQVOHSURFHVVXVGHFRQFHSWLRQHW
GH GpYHORSSHPHQW GH SURGXLWV >@ &HWWH LQWHUYHQWLRQ
GRLW rWUH HIIHFWLYH GX GpEXW j OD ILQ GH OD FRQFHSWLRQ
VHORQ O¶LGpH G¶XQH HUJRQRPLH WRWDOH >@ 8QH WHOOH
HUJRQRPLHHVWHIILFDFHHWPRLQVFR€WHXVH>@HWDVVXUH
XQH LQWpJUDWLRQ GH OD SUpYHQWLRQ HQ DPRQW GX SURMHW
>@
MOTS CLES : &RQFHSWLRQ GH SURGXLWV QRXYHDX[
(UJRQRPLH(YDOXDWLRQVFRPELQpHVGHO¶DFWLYLWp
ABSTRACT
2XUZRUNFRQVLVWVLQWDNLQJLQWRDFFRXQWWKHEHVWRIWKH
NQRZOHGJH DQG NQRZKRZ RI WKH RSHUDWRUV LQ WKH
SURFHVV RI GHVLJQ DQG GHYHORSPHQW RI QHZ SURGXFWV
)DYRXUDEOH WR WKLV LGHD RI D WRWDO HUJRQRPLFV LQ WKH
SURFHVV LH RI DQ HUJRQRPLFV ZKLFK JLYHV LWVHOI WKH
PHDQV RI IROORZLQJ WKH GHVLJQ IURP EHJLQQLQJ WR WKH
HQG RXU ZRUN FODULILHV WKH DGYDQWDJHV RI D VWHS RI
HYDOXDWLRQVFRPELQHGRIWKHDFWLYLW\7KLVVWHSLQGHHG
PDNHVLWSRVVLEOHWRLQWHJUDWHYHU\HDUO\LQWKHSURFHVV
WKH IXQFWLRQ RI XVH DQG WR HOLPLQDWH DV RI WKH ILUVW
FRQFHSWV ZKDW ZH FDOO YXOQHUDELOLWLHV WKXV
IDFLOLWDWLQJWKHIDVWHPHUJHQFHRIDFRQFHSWRISURGXFW
DFFHSWDEOH WR WKH ZKROH RI WKH DFWRUV RI WKH SURMHFW
JURXS 7KLV VWHS LV RI UHDO LQWHUHVW IRU D EHWWHU WDNLQJ
LQWR DFFRXQW RI WKH HQGXVHU FRQVHTXHQWO\ VXSSRUWLQJ
VDIHW\ FRPIRUW DQG HIIHFWLYHQHVV RI WKH GHYHORSHG
SURGXFWV
'DQV OD FRQWLQXLWp GHV WUDYDX[ GX /DERUDWRLUH
6\VWqPHVHW7UDQVSRUWVGHO¶8QLYHUVLWpGH7HFKQRORJLH
GH%HOIRUW0RQWEpOLDUG HWHQSDUWLFXOLHUGHVRQpTXLSH
GH UHFKHUFKH HQ (5JRQRPLH HW &2QFHSWLRQ GHV
6\VWqPHV (5&26 >@ >@ >@ >@ >@ QRXV
QRXV VRPPHV LQWpUHVVpV DX[ SRVVLELOLWpV G¶XQH
PHLOOHXUH LQWpJUDWLRQ GX IDFWHXU KXPDLQ j WUDYHUV
O¶HUJRQRPLH GDQV OD GpPDUFKH GH FRQFHSWLRQ SDU OD
PLVHHQSODFHG¶XQHGpPDUFKHTXHQRXVDYRQVLQWLWXOpH
©GpPDUFKH G¶pYDOXDWLRQV FRPELQpHV GH O¶DFWLYLWpª
&HWWHGpPDUFKHTXLVHYHXWSOXULGLVFLSOLQDLUHVHVLWXH
GDQVXQFRQWH[WHG¶LQJpQLHULHFRQFRXUDQWH>@HQULFKLH
95
GHV SULQFLSHV GH FRQFHSWLRQ FHQWUpH VXU O¶RSpUDWHXU
KXPDLQ>@(OOHODLVVHDLQVLXQHSODFHSUpSRQGpUDQWH
DX[ IXWXUV XWLOLVDWHXUV HQ SUHQDQW HQ FRPSWH OHXUV
EHVRLQVHWOHXUVDWWHQWHV
•
/D©GpPDUFKHG¶pYDOXDWLRQVFRPELQpHVGHO¶DFWLYLWpª
GRLW LQWHUYHQLU GqV OHV SUHPLqUHV SKDVHV GH OD
FRQFHSWLRQ DILQ G¶rWUH j PrPH GH IpGpUHU OHV DFWHXUV
GH OD FRQFHSWLRQ DYDQW TXH OD FDSDFLWp UpVLGXHOOH
G¶DFWLRQ QH VRLW WURS IDLEOH >@ ,O V¶DJLW GRQF GH
SURSRVHU DX JURXSH SURMHW XQH HUJRQRPLH R VHV
DFWHXUV GHYURQW rWUH ©DPHQpV j SDVVHU G¶XQ U{OH GH
FULWLTXH SDU UDSSRUW DX[ SURSRVLWLRQV GHV
FRQFHSWHXUV j XQ U{OH G¶DFWHXU GX SURFHVVXV GH
FRQFHSWLRQª>@
6HORQ QRXV OD PLVH HQ °XYUH GH FHV pYDOXDWLRQV GRLW
SUHQGUHHQFRPSWHOHVFULWqUHVVXLYDQWV
• OD VpOHFWLRQ GHV PpWKRGHV G¶pYDOXDWLRQ GRLW VH
EDVHU VXU OHV REMHFWLIV SRXU OHVTXHOV HOOHV VRQW
GHVWLQpHVHWFHFLHQIRQFWLRQGHODVRXUFHGXVDYRLU
HWGHVPR\HQVG¶pYDOXDWLRQ
• O¶H[SORLWDWLRQ GH OD FRPSOpPHQWDULWp HQWUH OHV
GLIIpUHQWV DFWHXUV IXWXUV RSpUDWHXUV H[SHUWV
©HUJRQRPLTXHVª«
• OD YDOLGLWp pFRORJLTXH GHV SURQRVWLFV TXL GpFRXOH
GHVpYDOXDWLRQV
/HV FULWqUHV pQRQFpV SODLGHQW GqV ORUV SRXU OD PLVH HQ
°XYUH GH SOXVLHXUV PpWKRGHV G¶pYDOXDWLRQ GDQV OH
FDGUH GH OD FRQFHSWLRQ GH SURGXLWV $YDQW G¶LOOXVWUHU
QRV SURSRV j WUDYHUV XQ H[HPSOH FRQFUHW QRXV QRXV
SURSRVRQV GH UHYHQLU SOXV HQ GpWDLO VXU OHV FULWqUHV
pYRTXpV
MÉTHODOLOGIE
'¶XQHPDQLqUHJpQpUDOHO¶HUJRQRPLHGRLWSHUPHWWUHGH
SULYLOpJLHU XQH FRQFHSWLRQ TXL SURSRVH XQH FRQWLQXLWp
HQWUH O¶DFWLYLWp DFWXHOOH OH PpWLHU GHV RSpUDWHXUV HW
O¶DFWLYLWp IXWXUH ,O V¶DJLW GH YDORULVHU OHV VWUDWpJLHV
DFWXHOOHV UpSXWpHV HIILFDFHV GpYHORSSpHV SDU OHV
RSpUDWHXUV GDQV OH FDGUH GH O¶DFWLYLWp DFWXHOOH TXL
VHUYLUDGHPRGqOHGHEDVHSRXUODFRQFHSWLRQ*URVMHDQ
HWFROO>@GDQVOHFDGUHG¶XQHLQWHUYHQWLRQORUVGHOD
PLVHHQURXWHG¶XQHEDWWHULHGHIRXUVj&RNHFRQFOXHQW
TXH ©SRXU FRQQDvWUH O¶DFWLYLWp IXWXUH RQ GRLW
SULYLOpJLHU FKDTXH IRLV TXH F¶HVW SRVVLEOH FH TXH
.DUQDV DSSHOOH µO¶H[SpULPHQWDWLRQ GH W\SH ,,¶ XQH
H[SpULPHQWDWLRQ GDQV ODTXHOOH VHXOH OD VLWXDWLRQ HVW
PRGLILpH PDLV SDV OHV VXMHWVª (Q G¶DXWUHV WHUPHV VL
RQPRGLILHOHPpWLHUGHVRSpUDWHXUVRQFRXUWOHULVTXH
TXHOHVGLWVRSpUDWHXUVUHSUHQQHQWOHXUVKDELWXGHVHWGH
FHIDLWWUDYDLOOHQWGLIIpUHPPHQWGHFHTXLDpWpSUpYX
/D SULVH HQ FRPSWH GHV VDYRLUV HW VDYRLUIDLUH GHV
RSpUDWHXUVWRXWDXORQJGXSURFHVVXVGHFRQFHSWLRQGRLW
VXLYUH XQH GpPDUFKH DSSURSULpH ,QVSLUpV GHV WUDYDX[
SUpFpGHQWVOLpVjODFRQFHSWLRQGHSURGXLWV>@>@HW
j OD GpPDUFKH HUJRQRPLTXH SURSRVpH SDU *DUULJRX HW
FROO >@ QRXV SURSRVRQV DLQVL XQH GpPDUFKH GH
FRQFHSWLRQ HUJRQRPLTXH LWpUDWLYH FRPSUHQDQW OHV
pWDSHVVXLYDQWHV
•
•
•
HVW LQGLSHQVDEOH j O¶pODERUDWLRQ GH VFpQDULRV TXL
VHUYLURQWjODPLVHHQ°XYUHGHVpYDOXDWLRQV&HWWH
DFWLYLWp IXWXUH VRXKDLWDEOH GRLW DXVVL LQWpJUHU OHV
DWWHQWHVGHO¶HQWUHSULVH
ODPLVHHQ°XYUHG¶pYDOXDWLRQVTXLGRLWSHUPHWWUH
O¶pPHUJHQFHGHSURQRVWLFVXUO¶DFWLYLWpIXWXUH&HV
pYDOXDWLRQV SHUPHWWURQW G¶rWUH j PrPH GDQV XQ
SUHPLHU WHPSV G¶DLGHU j OD KLpUDUFKLVDWLRQ GHV
SUpFRQFHSWV SURSRVpV SULQFLSHV GH VROXWLRQ HQ
YXH GH UHWHQLU XQ FRQFHSW TXL VHUD DFFHSWDEOH SDU
WRXVOHVSURWDJRQLVWHVGXJURXSHSURMHW>@'DQV
XQ GHX[LqPH WHPSV OHV pYDOXDWLRQV FRQGXLWHV
SHUPHWWURQW G
RSWLPLVHU HW GH YDOLGHU VXU XQ SODQ
HUJRQRPLTXHOHFRQFHSWUHWHQX
Sélection
de
méthodes
d’évaluation
complémentarité des intervenants
et
/D VRXUFH GX VDYRLU H[SHUW RX QRQ HW OHV PR\HQV
G¶pYDOXDWLRQ DUWLILFLHOV RX UpHOV VRQW OHV SULQFLSDX[
IDFWHXUV TXL FRQGLWLRQQHQW OD VpOHFWLRQ GHV PpWKRGHV
G¶pYDOXDWLRQ PDLV OH FKRL[ GH FHV GHUQLqUHV SHXWGRLW
DXVVL rWUH SULV SDU UDSSRUW DX[ DWWHQWHV HW EHVRLQV GHV
XWLOLVDWHXUVILQDX[8QHSURSRVLWLRQGHFHVDWWHQWHVRX
EHVRLQV D pWp SURSRVpH SDU %RQDSDFH >@ HW TXL VRQW
SDU RUGUH G¶LPSRUWDQFH D OD VpFXULWp HW OH ELHQrWUH
E OHV IRQFWLRQQDOLWpV F OD IDFLOLWp G¶XVDJH HW G OH
SODLVLU
XQ GLDJQRVWLF GH O¶H[LVWDQW RX FDUDFWpULVDWLRQ j
WUDYHUV O¶DQDO\VH GH O¶DFWLYLWp GHV RSpUDWHXUV HW GH
O¶HQYLURQQHPHQWDVVRFLp
XQ pODUJLVVHPHQW GX FRQWH[WH GH UpIpUHQFH RX
JpQpUDOLVDWLRQ j XQ FRQWH[WH SOXV JOREDO EDVp VXU
O¶H[SpULHQFH GHV LQWHUYHQDQWV DILQ G¶DLGHU OHV
DFWHXUV GX JURXSH SURMHW j SURSRVHU OHV SUHPLHUV
SUpFRQFHSWV
OD GpILQLWLRQ GX FKDPS GHV DFWLYLWpV IXWXUHV
VRXKDLWDEOHVHQDFFRUGDYHFOHVWUDYDX[GH6DJRW
HW FROO >@ >@ &HWWH DFWLYLWp UHVWH VRXKDLWDEOH
HQWHUPHVGHVpFXULWpG¶HIILFDFLWpHWGHFRQIRUWGHV
RSpUDWHXUV (OOH VH EDVH VXU OHV GRQQpHV LVVXHV GH
ODFDUDFWpULVDWLRQHQULFKLHVSDUODJpQpUDOLVDWLRQHW
'DQV XQH DSSURFKH SOXULGLVFLSOLQDLUH TXL UHJURXSH
HQWUHDXWUHVGHVH[SHUWVGHO¶LQWHUYHQWLRQHUJRQRPLTXH
HW GHV XWLOLVDWHXUV ILQDX[ OH JURXSH SURMHW HVW j PrPH
G¶XWLOLVHU XQ SDQHO GH PpWKRGHV G¶pYDOXDWLRQ IDLVDQW
DSSHO DX[ FRPSpWHQFHV GH WRXV OHV DFWHXUV GX JURXSH
SURMHW &KDTXH PpWKRGH SHUPHWWUD G¶DSSRUWHU VRQ ORW
G¶DYDQWDJHVDLQVLTXHOHPRQWUHQW%RXWLQHW0DUWLDO>@
VXU O
pWXGH GH VLWHV ZHE HQ V
DSSX\DQW VXU GHV WHVWV
G
XWLOLVDELOLWpHWVXUGHVpYDOXDWLRQVKHXULVWLTXHVRFHV
PpWKRGHV RQW SX WUDGXLUH XQH UpHOOH FRPSOpPHQWDULWp
GDQV OHV UpVXOWDWV REWHQXV $LQVL OD PLVH HQ °XYUH GH
96
PpWKRGHVDQDO\WLTXHVSDUGHVH[SHUWVFRPELQpHVjGHV
PpWKRGHV HPSLULTXHV TXL IRQW LQWHUYHQLU OHV IXWXUV
RSpUDWHXUV GRLW rWUH HQYLVDJpH j FKDTXH pWDSH GH OD
FRQFHSWLRQ
/DPLVHHQpYLGHQFHGHODPRGLILFDWLRQGHO¶XWLOLVDWLRQ
G¶XQ SURGXLW TXL VH WUDGXLW GDQV XQ HQYLURQQHPHQW
G\QDPLTXHSDUXQHXWLOLVDWLRQSOXVJUDQGHGHVPDUJHV
&HWWH PRGLILFDWLRQ QH SRXUUD VH SURGXLUH TXH ORUVTXH
OHV RSpUDWHXUV DXURQW DFTXLV XQ QLYHDX G¶H[SHUWLVH
VXIILVDQWSRXUXWLOLVHUSOXVFRQVpTXHPPHQWOHVPDUJHV
GLVSRQLEOHVSKpQRPqQHIDFLOHPHQWREVHUYDEOH
3DU FRQWUH OHV VLPXODWLRQV QH SHXYHQW VH PXOWLSOLHU j
O¶LQILQLSRXUGHVUDLVRQVpFRQRPLTXHVpYLGHQWHV'HFH
IDLWVRLWO¶RQIDYRULVHODGXUpHGHVWHVWVVRLWOHQRPEUH
/HV GHX[ DVSHFWV SHXYHQW rWUH SULV HQ FRPSWH PDLV
FHOD LPSOLTXHUD TXH OH QRPEUH G¶pYDOXDWLRQV FURvWUD
SURSRUWLRQQHOOHPHQW DX QRPEUH GH WHVWHXUV
1pDQPRLQV VXU OD EDVH GHV WUDYDX[ GH 1LHOVHQ >@
VHXO XQ QRPEUH OLPLWp G¶RSpUDWHXUV GH j VHPEOH
VXIILUHjPHQHUjELHQGHVpYDOXDWLRQV
6XU OD EDVH GHV WUDYDX[ GH QRPEUHX[ DXWHXUV >@ >@
>@ >@ >@ >@ >@ HW VHORQ OH EHVRLQ UHFKHUFKp
QRXV VRPPHV WHQWpV GH SURSRVHU OHV PpWKRGHV
VXLYDQWHV
•
•
•
•
6pFXULWp HW ELHQrWUH 35$+5$ HW VLPXODWLRQV
HPSLULTXHVSRXUOHVDVSHFWVFRJQLWLIV6LPXODWLRQV
YLUWXHOOHV HW HPSLULTXHV SRXU OHV DVSHFWV SOXW{W
DQWKURSRPpWULTXHVYRLUHELRPpFDQLTXHV
)RQFWLRQQDOLWpV 5pDOLVpHV HVVHQWLHOOHPHQW GDQV
OH FDGUH GX GLDJQRVWLF GH O¶DFWLYLWp H[LVWDQWH
FDUDFWpULVDWLRQHWHQULFKLHVGHODJpQpUDOLVDWLRQ
)DFLOLWp G¶XVDJH (YDOXDWLRQV KHXULVWLTXHV VLPXODWLRQV HPSLULTXHV SRXU OHV DVSHFWV FRJQLWLIV
6LPXODWLRQV YLUWXHOOHV HW HPSLULTXHV SRXU OHV
DVSHFWV DQWKURSRPpWULTXHV HW ELRPpFDQLTXHV
FRPPHGpMjpYRTXp
3ODLVLU (YDOXDWLRQV UpDOLVpHV GDQV OH FDGUH G¶XQ
GLDJQRVWLF G¶XQ ODUJH UHWRXU G¶H[SpULHQFH SDU
TXHVWLRQQDLUH
APPLICATION
Introduction
1RXV DYRQV DSSOLTXp XQH ©GpPDUFKH G¶pYDOXDWLRQV
FRPELQpHV GH O¶DFWLYLWpª GDQV OH FDGUH G¶XQ SURMHW
GHVWLQpjSURSRVHUXQFRQFHSWG¶LQWHUIDFHSRXUDVVXUHU
XQH FRQGXLWH IHUURYLDLUH IOXLGH VHORQ GHV FULWqUHV
KRUDLUHV SUpFLV >@ >@ &H SURMHW D FRXYHUW j FH
MRXU OD SKDVH GH O¶pWXGH GH IDLVDELOLWp HW GHV pWXGHV
SUpOLPLQDLUHVVXUODEDVHGXSURFHVVXVGHFRQFHSWLRQHW
GHGpYHORSSHPHQWGHSURGXLWVGpFULWSDU6DJRWHWFROO
>@
9DOLGLWppFRORJLTXH
/D TXHVWLRQ GH OD UpHOOH SHUWLQHQFH RX YDOLGLWp
pFRORJLTXH DX VHQV GHV FRQGLWLRQV G¶pYDOXDWLRQ GX
IRQFWLRQQHPHQW XVXHO UHSUpVHQWDWLYHV GX UDSSRUW
WULDQJXODLUHHQWUHOHVLQGLYLGXVO
DFWLYLWpRUJDQLVpHGHV
LQGLYLGXV HW O
HQYLURQQHPHQW GH FHWWH DFWLYLWp GHV
pYDOXDWLRQV HIIHFWXpHV HVW XQ VXMHW UpPDQHQW GDQV
O¶DSSURFKH HUJRQRPLTXH (Q HIIHW O¶REMHFWLI GHV
pYDOXDWLRQVHVWGHSHUPHWWUHO¶pPHUJHQFHGHSURQRVWLFV
VXUO¶DFWLYLWpHWYDOLGHUODFRQIRUPLWpHQWUHOHSURGXLWHW
OHEHVRLQH[SULPp(QTXDOLWpGHOLHXGHSURMHFWLRQV>@
HW GHVWLQpHV j OD FRQIURQWDWLRQ GHV QRXYHDXWpV DX[
FRQWUDLQWHV HW IDFWHXUV GLYHUV OHV pYDOXDWLRQV GRLYHQW
FRQWULEXHU j OD YDOLGDWLRQ RX QRQ GH FHUWDLQV FKRL[
PDLV DXVVL SHUPHWWUH G¶DQWLFLSHU DX SOXV W{W OHV
PRGLILFDWLRQV QpFHVVDLUHV (OOHV GRLYHQW SHUPHWWUH VL
QpFHVVDLUH©XQHPRGLILFDWLRQGXPRGqOHGHGpSDUWª
'HFHIDLWODYDOLGLWppFRORJLTXHGHVpYDOXDWLRQVQ¶HVW
SDV j QpJOLJHU /¶XQ GHV DVSHFWV TXL QRXV VHPEOH
SDUWLFXOLqUHPHQW LPSRUWDQW GDQV OH FDGUH GH SURGXLWV
LQGXVWULHOV HVW TXH OD IDoRQ G¶XWLOLVHU XQ SURGXLW VH
PRGLILH DYHF O¶H[SHUWLVH TX¶DFTXLHUW VRQ RSpUDWHXU
>@ >@ &HWWH FDUDFWpULVWLTXH SHXW DYRLU GHV
UpSHUFXVVLRQVLPSRUWDQWHVTXLQHVHYHUURQWQRQSDVDX
FRXUV GX GpYHORSSHPHQW PDLV ORUV GH O¶XWLOLVDWLRQ
UpHOOH$PDOEHUWL>@GDQVVDGpILQLWLRQGHO¶HUJRQRPLH
WRWDOH SDUOH ELHQ GH SUpYRLU OH UHWRXU G¶H[SpULHQFH
0DLV OH UHWRXU G¶H[SpULHQFH SHXW V¶DYpUHU LQHIILFDFH
SRXUUHPpGLHUjODUpVROXWLRQGHFHUWDLQVSUREOqPHVHW
GRQF FHW DVSHFW GRLW rWUH VL SRVVLEOH pYDOXHU ORUV GH OD
FRQFHSWLRQ
&H SURMHW G¶LQWHUIDFH GHVWLQp j XQ HQYLURQQHPHQW
VRFLRWHFKQLTXH FRPSOH[H TXL UHTXLqUH XQ QLYHDX GH
VpFXULWp LPSRUWDQW DX[ PXOWLSOHV LQWHUDFWLRQV
SUpVHQWDLW XQH IRUWH UHODWLRQ j OD VpFXULWp HW DX PDFUR
V\VWqPH &HV UHODWLRQV RQW FRQGLWLRQQp OH FKRL[ GHV
PpWKRGHVG¶pYDOXDWLRQXWLOLVpHV
3RXU PHQHU j ELHQ FHV WUDYDX[ XQ JURXSH SURMHW
PXOWLGLVFLSOLQDLUH D pWp PLV HQ SODFH HQ IDLVDQW XQH
ODUJHSODFHDX[SUHPLHUVFRQFHUQpVOHVFRQGXFWHXUV
/H JURXSH SURMHW PLV HQ SODFH D IDLW LQWHUYHQLU GH
QRPEUHX[ DFWHXUV UHOHYDQW GH SOXVLHXUV GLVFLSOLQHV HW
PpWLHUVWRXWDXORQJGXSURFHVVXVGHFRQFHSWLRQTXLD
IDLWXQHSODFHSUpSRQGpUDQWHDX[FRQGXFWHXUVPrPHVL
OHXUGLVSRQLELOLWpQ
DSDVWRXMRXUVpWpVLPSOHjQpJRFLHU
SRXUFHWUDYDLOGHFRQFHSWLRQG
,+0
Diagnostic de l’existant (étude de faisabilité)
/D SUHPLqUH pWDSH D pWp GH FRPSUHQGUH OH PpWLHU GH
FRQGXLWHHWOHVVWUDWpJLHVGHFRQGXLWHGHVFRQGXFWHXUV
&HWWH FRPSUpKHQVLRQ D pWp DFTXLVH SDU O¶REVHUYDWLRQ
VXU OH WHUUDLQ GX PpWLHU GH FRQGXLWH SDU OD GLYLVLRQ
YR\DJHXUV GHV FKHPLQV GH IHU IpGpUDX[ VXLVVHV
&HUWDLQV DVSHFWV RQW G€ rWUH FRPSOpWpV SDU GHV
YHUEDOLVDWLRQV &HV DQDO\VHV RQW PLV HQ pYLGHQFH HQ
97
DFFRUG DYHF GH QRPEUHX[ DXWHXUV TXH O¶DFWLYLWp GH
FRQGXLWH DFWXHOOH SHXW rWUH GLIIpUHQWH GH OD FRQGXLWH
SUHVFULWH &HWWH GLIIpUHQFH V¶H[SOLTXH SRXU SOXVLHXUV
UDLVRQVTXHQRXVQHGpYHORSSHURQVSDVGDQVODSUpVHQWH
FRPPXQLFDWLRQ 3RXU UpVXPHU WRXWHIRLV OHV
FRQGXFWHXUV PHWWHQW HQ °XYUH GHV VWUDWpJLHV GH
FRQGXLWH TXL FKHUFKHQW j RSWLPLVHU j WRXW PRPHQW OD
FRQGXLWHDILQG
pYLWHUG¶rWUHDUUrWpVjXQVLJQDORXGDQV
OHEXWG
pFRQRPLVHUGHO¶pQHUJLH&HWWHRSWLPLVDWLRQHVW
ODUJHPHQW EDVpH VXU O¶H[SpULHQFH DFTXLVH /HV
GLIIpUHQFHV REVHUYpHV HQWUH SUHVFULW HW UpDOLVp TXL VH
WUDGXLVHQW SDU GHV VWUDWpJLHV GH FRQGXLWH SURSUHV j
FKDTXH FRQGXFWHXU RQW HQ SDUWLFXOLHU JXLGp OD
GpILQLWLRQGHO¶DFWLYLWpIXWXUHVRXKDLWDEOH&HWWHDFWLYLWp
IXWXUH VRXKDLWDEOH D VHUYL GH EDVH j OD SURSRVLWLRQ GH
VFpQDULRV GH FRQGXLWH XWLOLVpV ORUV GHV pYDOXDWLRQV
SHUPHWWDQW DLQVL GH IRUPDOLVHU OHV H[LJHQFHV
IRQFWLRQQHOOHV
/¶DQDO\VH GH O¶DFWLYLWp D SHUPLV GH GpILQLU O
DFWLYLWp
IXWXUHVRXKDLWDEOHPDLVDXVVLGHPHWWUHHQpYLGHQFHOHV
LQIRUPDWLRQV QpFHVVDLUHV j XQH JHVWLRQ WHPSRUHOOH GX
WUDLQSDUOHFRQGXFWHXU
Evaluation de l’activité future et définition d'un
concept (études préliminaires)
/HV SURSRVLWLRQV pPLVHV SDU OH JURXSH SURMHW RQW pWp
pYDOXpHV JUkFH j OD PLVH HQ °XYUH GH GLIIpUHQWHV
PpWKRGHV G¶pYDOXDWLRQ TXL SUpFLVHURQW OHV EHVRLQV GH
PRGLILFDWLRQV HW OHV PRGDOLWpV G¶XWLOLVDWLRQ GH
O¶LQWHUIDFH MXVTX¶j WHQGUH YHUV XQH GpILQLWLRQ G¶XQ
SURGXLW DFFHSWDEOH HW XQH GpILQLWLRQ G¶XQH DFWLYLWp
IXWXUH HQYLVDJHDEOH >@ 1RXV FRPSUHQRQV SDU
HQYLVDJHDEOHXQHDFWLYLWpTXLDGHIRUWHVFKDQFHVG¶rWUH
WUqVSURFKHGHO¶DFWLYLWpIXWXUHUpHOOH
/HV PpWKRGHV UHWHQXHV RQW SULYLOpJLp OHV DVSHFWV
VpFXULWDLUHV HW O¶LPSRUWDQFH GX PDFUR V\VWqPH &HV
PpWKRGHV VRQW D pYDOXDWLRQV DQDO\WLTXHV GH W\SH
+5$+XPDQ5HOLDELOLW\$VVHVVPHQWESURWRW\SDJH
HWFVLPXODWLRQVHPSLULTXHV
$X QLYHDX GHV JHVWLRQQDLUHV GX WUDILF O¶DFWLYLWp GH
FRQGXLWH GRLW FRQVLVWHU j DVVXUHU XQH FRQGXLWH
FRQIRUPH j OD SODQLILFDWLRQ 0DOKHXUHXVHPHQW FHW
REMHFWLI QH SHXW rWUH DWWHLQW TX¶HQ GpILQLVVDQW GHV
WROpUDQFHVGHFRQGXLWHSDUUDSSRUWjFHWWHSODQLILFDWLRQ
&HV WROpUDQFHV GH FRQGXLWH TXL GRLYHQW DEVRUEHU OHV
LQFHUWLWXGHVOLpHVDX[SDUDPqWUHVWHFKQLTXHVDGKpUHQFH
UDLOURXH GLIIpUHQFH GH PDVVH GHV WUDLQV « QH
SHXYHQW WHQGUH YHUV ]pUR FDU HOOHV GRLYHQW DXVVL
SHUPHWWUH GH ODLVVHU DX[ FRQGXFWHXUV XQH PDUJH
G¶DXWRQRPLH PDUJH LQGLVSHQVDEOH SRXU SHUPHWWUH
G¶XWLOLVHUOHXUVVDYRLUVHWVDYRLUIDLUHF
HVWjGLUHOHXUV
SURSUHV VWUDWpJLHV GH FRQGXLWH &HWWH PDUJH
G¶DXWRQRPLHSHUPHW
• GH UpSRQGUH DX[ DWWHQWHV GX JHVWLRQQDLUH GH
O¶LQIUDVWUXFWXUH HW GRQF OXL SHUPHWWUH XQH PDvWULVH
GHVFLUFXODWLRQV
• GH IDYRULVHU XQH VpFXULWp GLWH pFRORJLTXH >@ TXL
FRQVLVWH j IDYRULVHU GHV VROXWLRQV HQ DFFRUG DYHF
OHVVROXWLRQVSURSUHVGHVRSpUDWHXUVFHTXLODLVVHUD
DX[RSpUDWHXUV©OHFRQWU{OHGHODVLWXDWLRQHWGHOD
SULVH GH ULVTXHV WRXW HQ IDYRULVDQW DX PLHX[ OD
YLVLELOLWp GH VHV SURSUHV DFWLRQV HW GHV DFWLRQV GX
V\VWqPHVǻ>@
• GH GpILQLU XQH DFWLYLWp IXWXUH VRXKDLWDEOH TXL D GH
IRUWHVFKDQFHVGHVHUDSSURFKHUGHO¶DFWLYLWpIXWXUH
UpHOOHHQIDYRULVDQWODPRGLILFDWLRQGXFRQWH[WHHW
QRQGHVVXMHWV>@
/DWROpUDQFHPLQLPDOHGHFRQGXLWHVHUDODFRQVpTXHQFH
G¶XQH SULVH HQ FRPSWH GHV DWWHQWHV HW EHVRLQV GH WRXV
OHV LQWHUYHQDQWV FRQFHUQpV SDU OH WUDILF IHUURYLDLUH
SUHQDQWHQFRPSWHOHVEHVRLQVGXJHVWLRQQDLUHGXWUDILF
HWOHVVDYRLUHWVDYRLUIDLUHGHVRSpUDWHXUV'DQVOHFDV
TXL QRXV LQWpUHVVH OHV VDYRLU HW VDYRLUIDLUH GHV
UpJXODWHXUV GX WUDILF SHXYHQW rWUH DXVVL j PrPH
G¶DXJPHQWHU
FHWWH
WROpUDQFH
GH
FRQGXLWH
0DOKHXUHXVHPHQW FHW DVSHFW Q¶D SDV HQFRUH pWp
FRPSOqWHPHQWWUDLWp
/HV pYDOXDWLRQV DQDO\WLTXHVGH W\SH +5$ RQW pWp
UHWHQXHV SDU UDSSRUW j OHXUV SOXV YDOXH HQ WHUPH GH
VpFXULWp >@ (OOHV SHUPHWWHQW DX JURXSH SURMHW GH
GpWHFWHU OHV YXOQpUDELOLWpV ODWHQWHV GqV OHV SUHPLqUHV
pEDXFKHV FURTXLV IDLWHV HW SHUPHWWHQW G¶pPHWWUH
LPPpGLDWHPHQW GH QRXYHOOHV SURSRVLWLRQV &H W\SH
G¶pYDOXDWLRQDO¶DYDQWDJHGHSHUPHWWUHO¶pOLPLQDWLRQGH
WRXWHV SURSRVLWLRQV LQVDWLVIDLVDQWHV DYDQW TX¶HOOHV
VRLHQWWHVWpHVSOXVHQSURIRQGHXU
/H SURWRW\SDJHHIIHFWXp JUkFH j XQH DQLPDWLRQ
VXJJHVWLYH pWDLW GHVWLQp j YpULILHU UDSLGHPHQW OD
FRKpUHQFH G\QDPLTXH HW DX EHVRLQ GH GpILQLU GH
QRXYHOOHV SURSRVLWLRQV /H SURWRW\SH IDLW ELHQ
pYLGHPPHQWLQWHUYHQLUOHVIXWXUVRSpUDWHXUV
/HVVLPXODWLRQVHPSLULTXHVHQFRQGLWLRQVUpHOOHVWUDLQV
FRPPHUFLDX[ RQW pWp UHWHQXHV GH SDU OD IRUWH UHODWLRQ
GX IXWXU SURGXLW DYHF OH PDFUR V\VWqPH &HV
pYDOXDWLRQV HQ FRQGLWLRQV UpHOOHV RQW pWp SUpIpUpHV j
FHOOHV UpDOLVpHV HQ VLPXODWHXU SRXU IDYRULVHU XQH
YDOLGLWpSOXVpFRORJLTXHGHVUpVXOWDWVREWHQXV(QRXWUH
QRXV DYRQV VRXKDLWp PHWWUH HQ pYLGHQFH O¶XWLOLVDWLRQ
HIIHFWLYH GH O¶LQWHUIDFH DYHF O¶DFFURLVVHPHQW GH
O¶H[SHUWLVH G¶XWLOLVDWLRQ >@ &HW pOpPHQW QRXV D
SHUPLVGHFRQVWDWHUTX¶XQHPRGLILFDWLRQGHVVWUDWpJLHV
GH FRQGXLWH pWDLW YLVLEOH DYHF O¶DXJPHQWDWLRQ GH
O¶H[SHUWLVHG¶XWLOLVDWLRQSDUUDSSRUWjO¶LQWHUIDFH>@
/¶DUWLFXODWLRQ HQWUH FHV WURLV PpWKRGHV HVW UHSUpVHQWpH
VXU OD ILJXUH &HWWH ILJXUH PRQWUH TXH FKDTXH
SURSRVLWLRQ RX PRGLILFDWLRQ HVW pYDOXpH SDU OHV WURLV
PpWKRGHV UHWHQXHV SHUPHWWDQW GH FRQYHUJHU SOXV
98
UDSLGHPHQW YHUV XQH VROXWLRQ DFFHSWDEOH SRXU WRXV OHV
DFWHXUVGHODFRQFHSWLRQ
8QH GHV GLIILFXOWpV UHQFRQWUpH HVW GH SRVLWLRQQHU
O¶RSpUDWHXUHQFRFRQFHSWHXU1RXVDYRQVSXFRQVWDWHU
TXHO¶RSpUDWHXUSHXWpSURXYHUGHVGLIILFXOWpV
o jIRUPDOLVHUHWGpFULUHVRQDFWLYLWp
o j GpFULUH OHV LQIRUPDWLRQV FRPSRVLWHV TX¶LO
FRQVWUXLWHWXWLOLVH
o j pPHWWUH GHV SURSRVLWLRQV FRQFUqWHV SRXU OH
VXSSRUWHUGDQVVRQDFWLYLWp
&HWWHVLWXDWLRQSHXWFRQIRUWHUFHUWDLQVFRQFHSWHXUVTXH
OHV RSpUDWHXUV GRLYHQW rWUH LPSOLTXpV VHXOHPHQWHQILQ
GH SURFHVVXV 1pDQPRLQV OD SKDVH GH FDUDFWpULVDWLRQ
HVWLQGLVSHQVDEOHjODFRPSUpKHQVLRQGHVEHVRLQVHWDW
WHQWHV GHV RSpUDWHXUV 'H SOXV OD PLVH HQ SODFH
G¶pYDOXDWLRQVGqVOHVSUHPLqUHVSKDVHVGHODFRQFHSWLRQ
HVW OD VHXOH PpWKRGH JDUDQWH G¶XQH YpULILFDWLRQ FRQWL
QXHGDQVOHSURFHVVXVGHFRQFHSWLRQGXUHVSHFWGHVEH
VRLQVHWDWWHQWHVGHVRSpUDWHXUV
(Q RXWUH FHWWH VLWXDWLRQ SHXW WHQGUH j HPSOR\HU XQH
DSSURFKH GH W\SH ©GLVFRXQW XVDELOLW\ª 1LHOVHQ ±
TXL SUpFRQLVH XQH ERQQH UpIOH[LRQ HQ DPRQW HW
GHV WHVWV G¶XWLOLVDELOLWp 1RXV Q¶H[FOXRQV SDV XQH WHOOH
DSSURFKHWRXWGXPRLQVVXUODUpIOH[LRQ0DLVFHWWHUp
IOH[LRQGRLWVHEDVHUVXUXQWUDYDLOGHFDUDFWpULVDWLRQHW
rWUH YDOLGpH SDU XQH FRPELQDLVRQ GH PpWKRGHV
G¶pYDOXDWLRQ
6XUODEDVHGHFHTXLYLHQWG¶rWUHGpFULWXQHRUJDQLVD
WLRQ SDUWLFXOLqUH VH GRLW G¶rWUH PLVH SODFH 'DQV QRWUH
FDVQRXVDYRQVRSWpSRXUGHVpFKDQJHVLQIRUPHOVDYHF
WRXWHVSHUVRQQHVFRQFHUQpHVSDUOHSURMHW&HVSHUVRQ
QHV SRXYDLHQW rWUH GHV FRQGXFWHXUV UHQFRQWUpV GDQV OH
FDGUHG¶DFFRPSDJQHPHQWHQFDELQHSRXUDFFXPXOHUXQ
PD[LPXPGHFRQQDLVVDQFHV
5LVTXH
/D GpPDUFKH UHWHQXH SUpVHQWDLW OH ULVTXH G¶DYRLU DQWL
FLSHUXQHVROXWLRQLQVDWLVIDLVDQWH1pDQPRLQVOHULVTXH
pWDLWIRUWOLPLWpGHSDUWOHWUDYDLODPRQWGHFDUDFWpULVD
WLRQHWSDUOHIDLWTXH
D ODSURSRVLWLRQV¶LQVpUDLWGDQVOHFRQWH[WHWHFK
QRORJLTXH SUpFLV FH TXL OLPLWDLW OHV SRVVLELOL
WpVRIIHUWHV
E OH QRPEUH G¶LQIRUPDWLRQV SK\VLTXHV GLVSRQL
EOHVQpFHVVDLUHVjODJHVWLRQKRUDLUHHVWUHODWL
YHPHQWIDLEOH
F ODSURSRVLWLRQDpWpGLVFXWpHDYHFOHSHUVRQQHO
GXVHUYLFHGHVpFXULWp
$YDQWDJH
/¶DYDQWDJHGHODGpPDUFKHUHWHQXHHVWGHSHUPHWWUHGH
UpDOLVHU GH QRPEUHX[ WUDYDX[ HQ SDUDOOqOH HW DLQVL Up
GXLUHOHWHPSVFRQVDFUpjODFRQFHSWLRQ
/D SULVH HQ FRPSWH GHV VDYRLUV HW VDYRLUIDLUH GHV
RSpUDWHXUV QH SHXW rWUH HIIHFWLYH TXH VL HOOH V¶LQWqJUH
ELHQGDQVODGpPDUFKHGHFRQFHSWLRQGHSURGXLWV1RXV
Propositions
Évaluations
HRA
modifications
Prototypage
Simulations
empiriques
Solution
acceptable
)LJXUH0pWKRGRORJLHVXLYLHHQYXHGHGpILQLUXQ
QRXYHDXFRQFHSWG
DLGHjODFRQGXLWHIHUURYLDLUH
/HVpYDOXDWLRQVFRPELQpHVHWSOXVSDUWLFXOLqUHPHQWOHV
VLPXODWLRQV HPSLULTXHV RQW SHUPLV G¶pYDOXHU OHV
SHUIRUPDQFHVHVFRPSWDEOHVDYHFOHFRQFHSWG¶LQWHUIDFH
UHWHQXILJXUH&HFRQFHSWHVWjPrPHGHIDYRULVHUOD
VpFXULWpO
HIILFDFLWpHWOHFRQIRUWGHVFRQGXFWHXUV>@
>@
© 2006, CFF SA, P-OP
)LJXUH&RQFHSWG¶LQWHUIDFH
DISCUSSION
1RWUHWUDYDLOSURSRVHXQHGpPDUFKHSRXUXQHPHLOOHXUH
SULVH HQ FRPSWH GHV VDYRLUV HW VDYRLUIDLUH GHV
RSpUDWHXUVGDQVODFRQFHSWLRQGHSURGXLWVQRXYHDX[HQ
O
RFFXUUHQFHXQHQRXYHOOHDLGHjODFRQGXLWHIHUURYLDLUH
j WUDYHUV XQH ,+0 TXL IDYRULVHODVpFXULWpO¶HIILFDFLWp
HWOHFRQIRUWGDQVOHWUDLWHPHQWGHVLQIRUPDWLRQVSDUOHV
FRQGXFWHXUV
99
SURSRVRQV DLQVL ILJXUH XQ PRGqOH TXL UHSUpVHQWH
O
DUWLFXODWLRQ HUJRQRPLH HW FRQFHSWLRQ TXH QRXV
SUpFRQLVRQV &H PRGqOH V
DSSXLH VXU OD GpPDUFKH
HUJRQRPLTXHSURSRVpHSDU*DUULJRXHWFROO>@HWVXU
OH PRGqOH GH FRQFHSWLRQ SURSRVp SDU 6DJRW HW FROO
>@ >@ ,O SURSRVH XQH DUWLFXODWLRQ FRPPXQH DX[
GpPDUFKHV PHQWLRQQpHV >@ >@ >@ SHUPHWWDQW
GH SURSRVHU XQ FDQHYDV FRPPXQ j FHV GHX[
GpPDUFKHV 3DU UDSSRUW DX PRGqOH GH FRQFHSWLRQ
SUpFpGHPHQW SURSRVp >@ >@ OH SUpVHQW PRGqOH
ILJXUHLQWURGXLWODQRWLRQG¶pYDOXDWLRQVFRPELQpHV
TXL FRQVLVWH j XWLOLVHU SOXVLHXUV PpWKRGHV
FRPSOpPHQWDLUHV j FKDTXH pWDSH j FKDTXH SKDVH GX
SURFHVVXVGHFRQFHSWLRQ
&H PRGqOH ILJXUH VH YHXW XQH DSSURFKH
SUDJPDWLTXH PHWWDQW HQ YDOHXU O¶LQWHUYHQWLRQ
HUJRQRPLTXH GDQV OD FRQFHSWLRQ GH SURGXLWV TXL IDLW
VXLWH j O¶H[SUHVVLRQ G¶XQ EHVRLQ /HV UpVXOWDWV GHV
LWpUDWLRQV VXFFHVVLYHV DOLPHQWHURQW OHV GLYHUVHV pWDSHV
GH OD GpPDUFKH GH FRQFHSWLRQ SRXU DERXWLU j XQH
VROXWLRQ DFFHSWDEOH &HV GLIIpUHQWHV pWDSHV VRQW D
O¶pWXGH GH IDLVDELOLWp E OHV pWXGHV SUpOLPLQDLUHV F
OHV pWXGHV GH GpWDLOV HW G O¶LQGXVWULDOLVDWLRQ 1RXV
DYRQV DXVVL UHSUpVHQWp VXU FH PRGqOH OHV pWDSHV FOpV
TXH VRQW OD GpILQLWLRQ GX FDKLHU GHV FKDUJHV OD
SURSRVLWLRQ G¶DYDQW SURMHWV RX GH SUpFRQFHSWV
O¶pODERUDWLRQ GH PDTXHWWHV RX SURWRW\SHV TXL YLHQQHQW
V\QWKpWLVHU FRQFUpWLVHU OHV SKDVHV G¶DQDO\VH &HV
pWDSHV FOpV SHXYHQW rWUH FRQVLGpUpHV FRPPH GHV
UHSqUHV TXL SHXYHQW IDFLOLWHU O¶LQFRQWRXUQDEOH SKDVDJH
WHPSRUHOGHVSURMHWVGHFRQFHSWLRQ
BESOIN
Étude de faisabilité
Généralisation
Caractérisation
ive
s
Activité future souhaitable et scénarios
uc
ce
ss
Produit
pe
ss
Prototype
Ét
a
Avant-projets / Préconcept
Cahier des charges fonctionnelles
Industrialisation
Études détaillées
Études préliminaires
Modification
souhaitée
Évaluations
combinées
Modification
souhaitée
Conformité validée
Étape suivante
Solution intermédiaire
acceptable
Étape suivante
Produit final
acceptable
)LJXUH0RGqOHG¶DUWLFXODWLRQHQWUHHUJRQRPLHHWFRQFHSWLRQ
6XU OD EDVH GH QRV WUDYDX[ QRXV SHQVRQV TXH OD
©GpPDUFKH G¶pYDOXDWLRQV FRPELQpHV GH O¶DFWLYLWpª
GDQVODGpPDUFKHGHFRQFHSWLRQSHUPHW
• GH IpGpUHU OHV DFWHXUV GH OD FRQFHSWLRQ GH SDUW OH
IDLW TX¶HOOH SURSRVH XQ PR\HQ GH SURMHFWLRQ
FRPPXQDXJURXSHSURMHW>@
• XQH UpGXFWLRQ GX WHPSV FRQVDFUp DX[ SKDVHV
G¶pYDOXDWLRQV SDU OD PLVH HQ °XYUH GH PpWKRGHV
•
100
DQDO\WLTXHV HW FHFL DX QLYHDX GX WHPSV LQYHVWL
SRXU GpWHFWHU OHV YXOQpUDELOLWpV &HFL D SRXU HIIHW
GH OLPLWHU OH QRPEUH G¶LWpUDWLRQV SRXU WHVWHU GHV
VROXWLRQV QRQ VDWLVIDLVDQWHV HW DLQVL DXJPHQWHU OD
SHUIRUPDQFH HW O¶HIILFDFLWp GH OD FRQFHSWLRQ GH
SURGXLWV
GH SHUPHWWUH GHV PRGLILFDWLRQV UDSLGHV JUkFH j
XQHGpWHFWLRQWUqVHQDPRQWGXSURFHVVXV
•
•
G¶pYDOXHU OHV SHUIRUPDQFHV DWWHLJQDEOHV HW GH
WHQGUH YHUV OD GpILQLWLRQ GH O¶DFWLYLWp IXWXUH
HQYLVDJHDEOH SDU OD PLVH HQ °XYUH GH PR\HQV
G¶pYDOXDWLRQV TXL SULYLOpJLHQW OD YDOLGLWp
pFRORJLTXHHWODPLVHHQYDOHXUGHODPRGLILFDWLRQ
GH O¶XWLOLVDWLRQ GX SURGXLW SDU O¶DXJPHQWDWLRQ GH
O¶H[SHUWLVHGHVRSpUDWHXUV
GH FRQFHYRLU XQ SURGXLW DGDSWp DX[ EHVRLQV HW
DWWHQWHV GHV RSpUDWHXUV SDU OHXU LQWpJUDWLRQ j SDUW
HQWLqUHGDQVODGpPDUFKHGHFRQFHSWLRQ
/D GpPDUFKH SURSRVpH GRLW IDYRULVHU OHV IRQFWLRQV
G¶XVDJH HW pOLPLQHU GqV OHV SUHPLHUV SUpFRQFHSWV OHV
YXOQpUDELOLWpV IDFLOLWDQW O¶pPHUJHQFH UDSLGH G¶XQ
FRQFHSWGHSURGXLWDFFHSWDEOH&HWWHGpPDUFKHSUpVHQWH
XQ UpHO LQWpUrW SRXU XQH PHLOOHXUH SULVH HQ FRPSWH GH
O¶RSpUDWHXU GDQV OH SURFHVVXV GH FRQFHSWLRQ HW GH
GpYHORSSHPHQWGHSURGXLWV
/DGpPDUFKH©G¶pYDOXDWLRQVFRPELQpHVGHO¶DFWLYLWpª
SHXWVHQRXUULUGHPR\HQVVLPSOHVHWV¶LQVpUHUGDQVXQ
FRQWH[WH RUJDQLVDWLRQQHO FRPSOH[H DX[ QRPEUHXVHV
FRQWUDLQWHV%LHQpYLGHPPHQWOHFKRL[GHODGpPDUFKH
TXLVHUDUHWHQXHSDUOHVJURXSHVSURMHWVGRLWrWUHDGDSWp
DX[EHVRLQVVSpFLILTXHVGHFKDTXHSURMHW
3DU FRQWUH OD PLVH HQ °XYUH ©G¶pYDOXDWLRQV
FRPELQpHVGHO¶DFWLYLWpªH[LJHTXHOHJURXSHSURMHWDLW
WRXWHV OHV FRPSpWHQFHV QpFHVVDLUHV HW HQ SDUWLFXOLHU
SXLVVHDYRLUHQVRQVHLQGHVUHSUpVHQWDQWVGH©YUDLVª
IXWXUV RSpUDWHXUV /D SDUWLFLSDWLRQ GH FHV GHUQLHUV
QpFHVVLWH TX¶LOV VRLHQW GpJDJpV GH OHXUV IRQFWLRQV
TXRWLGLHQQHV SRXU UHMRLQGUH HW SDUWLFLSHU DX JURXSH
SURMHW8QHWHOOHGpPDUFKHQ¶HVWSDVWRXMRXUVVLPSOHHW
GHPDQGH XQH RUJDQLVDWLRQ VSpFLILTXH &HWWH
SDUWLFLSDWLRQELHQTXHTXHOTXHIRLVGLIILFLOHGRLWDYDQW
WRXWrWUHXQHYRORQWp
REMERCIEMENTS
/HV DXWHXUV VRXKDLWHQW UHPHUFLHU OHV &KHPLQV GH IHU
IpGpUDX[ VXLVVHV HW SOXV SDUWLFXOLqUHPHQW O¶XQLWp
2SHUDWLQJGHOD'LYLVLRQYR\DJHXUV
RÉFÉRENCES BIBLIOGRAPHIQUES
$PDOEHUWL 5 /D FRQGXLWH GHV V\VWqPHV j
ULVTXH38)
'DQV O¶DSSOLFDWLRQ pYRTXpH QRXV QRXV VRPPHV
DSSX\pV VXU OD PLVH HQ RHXYUH GH VLPXODWLRQV
HPSLULTXHVHQFRQGLWLRQVUpHOOHV&HFKRL[DpWpUHWHQX
SRXU DXJPHQWHU OD YDOLGLWp pFRORJLTXH HW PHWWUH HQ
pYLGHQFH OH FKDQJHPHQW GX PRGH GH O¶XWLOLVDWLRQ DYHF
O¶DXJPHQWDWLRQ GX QLYHDX G¶H[SHUWLVH SDU UDSSRUW j
O¶LQWHUIDFH GHV FRQGXFWHXUV 0DOKHXUHXVHPHQW GH
WHOOHV VLPXODWLRQV QH VRQW SDV WRXMRXUV SRVVLEOHV HW OD
UHFKHUFKH GX FKDQJHPHQW GX PRGH G¶XWLOLVDWLRQ VL
QpFHVVDLUH GRLW SRXYRLU DXVVL V¶DSSX\HU VXU G¶DXWUHV
PpWKRGHV
$PDOEHUWL 5 /¶HUJRQRPLH IDFWHXUGHVpFXULWpHW
G¶LQQRYDWLRQ5((1ƒSS
%pJXLQ 3 :HLO)DVVLQD $ 'H OD VLPXODWLRQ GHV
VLWXDWLRQV GH WUDYDLO jODVLWXDWLRQGHVLPXODWLRQ
,Q/DVLPXODWLRQHQHUJRQRPLHFRQQDvWUHDJLUHW
LQWHUDJLU &RRUGLQDWHXUV 3 %HJXLQ HW $ :HLO
)DVVLQDeGLWLRQV2FWDUHV
%RQDSDFH / /LQNLQJ 3URGXFW 3URSHUWLHV WR
3OHDVXUH 7KH 6HQVRULDO 4XDOLW\ $VVHVVPHQW
0HWKRG ± 6(48$0 ,Q 3OHDVXUH ZLWK SURGXFWV %H\RQGXWLOLVDELOLW\(GLWHGE\:6*UHHQDQG
3:-RUGDQ(GLWLRQV7D\ORU)UDQFLV
8QHGHVUpSRQVHVVHWURXYHSHXWrWUHGDQVO¶XWLOLVDWLRQ
GH VLPXODWHXUV JOREDX[ TXL SHUPHWWHQW GH VLPXOHU
O¶DFWLYLWp GH SOXVLHXUV RSpUDWHXUV HQ VLPXOWDQpH RX GH
PpWKRGHVDQDO\WLTXHV
%RXWLQ 0 0DUWLDO 2 5DSSRUW WHFKQLTXH
pYDOXDWLRQ GH O¶XWLOLVDELOLWp G¶XQ VLWH :(% WHVW
G¶XWLOLVDELOLWp YHUVXV pYDOXDWLRQ KHXULVWLTXH
5DSSRUW &5,0 FHQWUH GH UHFKHUFKH
LQIRUPDWLTXHGH0RQWUpDO&DQDGD
CONCLUSION
/D SULVH HQ FRPSWH GHV VDYRLUV HW VDYRLUIDLUH GHV
RSpUDWHXUV YDOLGpH SDU OD PLVH HQ °XYUH ©G¶XQH
GpPDUFKH G¶pYDOXDWLRQV FRPELQpHV GH O¶DFWLYLWpª
SHUPHW GqV OHV SUHPLqUHV pEDXFKHV GH FRQYHUJHU SOXV
UDSLGHPHQW YHUV OH FRQFHSW DFFHSWDEOH SRXU WRXV OHV
DFWHXUVGHODFRQFHSWLRQ
%UDQJLHU(%UDQFLOOD3&RPPHQWFRQFHYRLUXQ
SURGXLW IDFLOH j XWLOLVHU (GLWLRQ G¶RUJDQLVDWLRQ
&OHHWXV . - 'HILQLWLRQ RI &RQFXUUHQW
(QJLQHHULQJ 7HFKQLFDO 5HSRUW 6HULHV 5HVHDUFK
1RWH
&(5&7551
&RQFXUUHQW
(QJLQHHULQJ 5HVHDUFK &HQWHU :HVW 9LUJLQLD
8QLYHUVLW
1RXV SHQVRQV TX¶XQH UpHOOH HIILFDFLWp GHV SURGXLWV
GpYHORSSpVQHSHXWrWUHHIIHFWLYHTXLVLXQHFRQWLQXLWp
HQWUH O¶DFWLYLWp DFWXHOOH HW OD IXWXUH HVW UpHOOHPHQW
DVVXUpH,OV¶DJLWSRXUOHJURXSHSURMHWGHV¶DSSURSULHU
OHWUDYDLOUpHOGHVRSpUDWHXUVHWQRQSDVXQLTXHPHQWOH
SUHVFULW SRXU SURSRVHU GHV SURGXLWV TXL UpSRQGHQW j
OHXUVDWWHQWHVHWEHVRLQVWRXWHQJDUDQWLVVDQWpJDOHPHQW
OHVDWWHQWHVHWEHVRLQVGHVHQWUHSULVHV
&KLWHVFX & 6LPXODWLRQ HQ HUJRQRPLH )DFWHXU
G¶LQQRYDWLRQ GDQV OD FRQFHSWLRQ GH SURGXLWV
$SSOLFDWLRQ j OD FRQFHSWLRQ GH V\VWqPHV GH
WUDYDLO 7KqVH GH GRFWRUDW GH O¶LQVWLWXW QDWLRQDO
SRO\WHFKQLTXHGH/RUUDLQH
101
'DQLHOORX ) /H VWDWXW GH OD 3UDWLTXH HW GHV
1LHOVHQ - *XHUULOOD +&, 8VLQJ 'LVFRXQW
&RQQDLVVDQFHV HQ (UJRQRPLH 'RFXPHQW SRXU
O¶+DELOLWDWLRQ j 'LULJHU GHV 5HFKHUFKHV
7RXORXVH8QLYHUVLWpOH0LUDLO
8VDELOLW\ (QJLQHHULQJ WR 3HQHWUDWH WKH
,QWLPLGDWLRQ
%DUULHU
KWWSZZZXVHLWFRPSDSHUVJXHUULOODBKFLKWPO
'XFKDPS5/DFRQFHSWLRQGHSURGXLWVQRXYHDX[
1RUPH,623URFHVVXVGHFRQFHSWLRQ
eGLWLRQV+HUPHVS
FHQWUpHVXUO¶RSpUDWHXUKXPDLQSRXUOHVV\VWqPHV
LQWHUDFWLI 2UJDQLVDWLRQ ,QWHUQDWLRQDOH GH
1RUPDOLVDWLRQ
)pQL[-*UDIDJQLQR76DJRW-&9DORW&8VHU
FHQWUHG GHVLJQ DSSOLHG WR LQFUHDVH WLPHWDEOH
VWDELOLW\ =(9UDLO *ODVHUV $QQDOHQ 6RQGHUKHIW
7DJXQJGEDQG1RYHPEHU
0LGOHU & /¶DXWR TXL Q¶H[LVWDLW SDV 0DQDJHPHQW
GHV SURMHWV HW WUDQVIRUPDWLRQ GH O¶HQWUHSULVH
,QWHU(GLWLRQV
)pQL[ - 6DJRW -& 9DORW & $VVHVVPHQW LQ
SURGXFW GHVLJQ VXFFHVV IDFWRU ¬ SDUDvWUH GDQV
OHVDFWHVGXqPHFROORTXHLQWHUQDWLRQDOGX&RPLWp
5HFKHUFKH GH O¶$VVRFLDWLRQ LQWHUQDWLRQDOH GH OD
VpFXULWpVRFLDOH1LFH0DUV
5LFKDUG -) /RJLTXH GX IRQFWLRQQHPHQW HW
ORJLTXH G¶XWLOLVDWLRQ 5DSSRUW ,15,$ 1ƒ *DUULJRX$7KLEDXOW-)-DFNVRQ00DVFLD)
6DJRW
&RQWULEXWLRQV HW GpPDUFKH GH O¶HUJRQRPLH GDQV
OHV SURFHVVXV GH FRQFHSWLRQ 3LVWHV 9ROXPH 1ƒ 2FWREUH ± 5pIOH[LRQ VXU OD SUDWLTXH
-& (UJRQRPLH HW FRQFHSWLRQ
DQWKURSRFHQWUpH 0pPRLUH SXU O¶KDELOLWDWLRQ j
GLULJHU GHV UHFKHUFKHV ,QVWLWXW 3RO\WHFKQLTXH GH
/RUUDLQH (FROH 1DWLRQDOH 6XSpULHXUH HQ *pQLH
GHV6\VWqPHV,QGXVWULHOV
*RPHV 6 &RQWULEXWLRQ GH O¶DQDO\VH GH O¶DFWLYLWp
6DJRW -& *RPHV 6 =ZROLQVNL 3 (UJRQRPLFV
DX SURFHVVXV GH FRQFHSWLRQ GH SURGXLWV
LQQRYDQWV DSSOLFDWLRQ j OD FRQFHSWLRQ GH
V\VWqPHV GH FRQWU{OHFRPPDQGH DXWRPRELOHV
7KqVHGHGRFWRUDWLQVWLWXWQDWLRQDOSRO\WHFKQLTXH
GH/RUUDLQH
LQ GHVLJQ D VDIHW\ DQG LQQRYDWLRQ IDFWRU
,QWHUQDWLRQDO -RXUQDO RI 'HVLJQ DQG ,QQRYDWLRQ
5HVHDUFKSS
6DJRW -& *RXLQ 9 *RPHV 6 (UJRQRPLFV LQ
SURGXFW GHVLJQ VDIHW\ IDFWRU 6DIHW\ 6FLHQFH
9ROXPH,VVXHVSS
*URVMHDQ
9 7HUULHU 3 4XHO W\SH
G¶H[SpULPHQWDWLRQ SRXU pWXGLHU O¶DFWLYLWp IXWXUH
$FWHV GX FROORTXH ©5HFKHUFKH HW (UJRQRPLHª
7RXORXVH
6DJRW -& *RPHV 6 ,QWpJUDWLRQ GHV IDFWHXUV
KXPDLQV GDQV OD GpPDUFKH GH FRQFHSWLRQ
DSSURFKH HUJRQRPLTXH &DKLHU GHV 1RWHV
'RFXPHQWDLUHV +\JLqQH HW VpFXULWp DX WUDYDLO
,1563DULVQƒqPHWULPHVWUH
*URVMHDQ-&1HERLW0(UJRQRPLHHWSUpYHQWLRQ
HQ FRQFHSWLRQ GHV VLWXDWLRQV GH WUDYDLO &DKLHUV
GH QRWHV GRFXPHQWDLUHV ,156 ± +\JLqQH HW
VpFXULWp GX WUDYDLO 1ƒ 1' 9DORW & *UDX -< HW $PDOEHUWL 5 /HV
PpWDFRQDLVVDQFHV GHV UHSUpVHQWDWLRQV GH VHV
SURSUHV FRPSpWHQFH 3DUX GDQV $ :HLO)DVVLQD
3 5DEDUGHO HW ' 'XERLV 5HSUpVHQWDWLRQ SRXU
O¶DFWLRQ(GLWLRQ2FWDUqV
,WRK . 6HNL 0 $QGHUVHQ + % $SSURDFKHV WR
7UDQVSRUWDWLRQ VDIHW\ 0HWKRGV DQG &DVH 6WXGLHV
$SSO\LQJ WR 7UDFN 0DLQWHQDQFH 7UDLQ RSHUDWLRQ
,Q +DQGERRN RI &RJQLWLYH 7DVN 'HVLJQ (GLWHG
E\ ( +ROOQDJHO (GLWLRQV /DZUHQFH (UOEDXP
$VVRFLDWHVLQFSS
=ZROLQVNL 3 /D VLPXODWLRQ GH O¶DFWLYLWp FRPPH
RXWLO G¶DLGH j OD FRQFHSWLRQ HW j O¶LQQRYDWLRQ
$SSOLFDWLRQ j OD FRQFHSWLRQ HW j O¶LQQRYDWLRQ
7KqVH GH GRFWRUDW GH O¶LQVWLWXW QDWLRQDO
SRO\WHFKQLTXHGH/RUUDLQH
/HERUJQH & 3URSRVLWLRQ G¶XQH GpPDUFKH
DQWKURSRFHQWUpH GH FRQFHSWLRQ GH SURGXLWV
QRXYHDX[ EDVpH VXU O¶XVDJH HW GHVWLQpH j XQH
PHLOOHXUH LQWpJUDWLRQ SDU O¶HUJRQRPLH GHV
EHVRLQV HW GHV DWWHQWHV GHV XVDJHUV $SSOLFDWLRQ
GDQV OH VHFWHXU GX PRELOLHU GH FXLVLQH 7KqVH GH
GRFWRUDWGHO¶eFROH1DWLRQDOH6XSpULHXUHG¶$UWVHW
0pWLHUV
102
Performances et usages d’un environnement
d’apprentisage de la programmation
« basé sur exemple ».
Nicolas Guibert,
Patrick Girard,
Laurent Guittet
LISI / ENSMA
Téléport 2 - 1 avenue Clément Ader
BP 40109
86961 Futuroscope Chasseneuil cedex
{guibert,guittet,girard}@ensma.fr
RESUME
KEYWORDS : Psychology and didactics of programming, Programming by demonstration, Computer-aided
learning and teaching, Experimentations.
Malgré la place grandissante occupée par l’activité de
programmation, en tant qu’outils d’analyse ou instruments de mesure, dans les sciences expérimentales, son
apprentissage demeure toujours très difficile. De nombreuses études ont caractérisé les erreurs et difficultés
rencontrées par les programmeurs novices. Depuis quelques années, nous explorons l’utilisation d’un paradigme
particulier, la programmation sur exemple, dans le but de
réduire ces difficultés.
INTRODUCTION
Alors que micro-ordinateurs et programmes informatiques se sont implantés dans de nombreuses disciplines
scientifiques en tant qu’outils d’analyse ou instruments
de mesure (physique, chimie, sciences de la vie… on
parle même dans ce dernier cas de bio-informatique),
l’acquisition des compétences requises pour la conception de programmes ne se fait pas aisément. Käasboll
[10] rapporte que, de par le monde, entre 25 et 80 % des
étudiants sont en situation d’échec. Pourquoi la programmation est-elle si difficile d’accès ? Nous nous attachons, en préambule, à ébaucher une réponse à cette
question. Pour cela, à partir de la littérature en psychologie ou en didactique de la programmation, nous pratiquons une synthèse des différents types de difficultés
auxquelles sont confrontés les programmeurs débutants.
Le travail présenté ici se veut une évaluation de cette
démarche, et sera articulé autour de deux axes, celui de
l’analyse des usages et celui de l’efficacité de
l’apprentissage. Trois expérimentations de MELBA,
l’outil développé dans le cadre du projet, utilisant diverses méthodes d’évaluation, sont ainsi présentées et analysées.
MOTS CLES : Psychologie et didactique de la programmation, Programmation sur exemples, Environnement
Informatique pour l’Apprentissage Humain, Expérimentations, Occulométrie.
Par la suite, nous définissons l’approche suivie pour réduire ces difficultés, et décrivons l’outil réalisé dans la
perspective de la mettre en œuvre. Puis, nous présentons
une évaluation de l’apprentissage réalisée à partir de
deux expérimentations en situation réelle, et discutons
du choix et de la pertinence des métriques et du protocole, en comparaison avec d’autres études en psychologie de la programmation. Enfin, nous complétons cette
évaluation et analysons les usages de l’environnement à
partir des résultats d’une expérience avec un oculomètre.
ABSTRACT
Although computers and programs have now become essential in experimental sciences such as analysis or
measurement tools, many students still find learning
Computer Science is extremely difficult. Many studies
have characterized the errors and difficulties encountered by novice programmers. For some years, we explore the use of a particular paradigm, programming by
example, to lower these difficulties.
DIFFICULTES DANS
PROGRAMMATION.
L’APPRENTISSAGE
DE
LA
Duchâteau propose la définition suivante de la programmation : « faire faire une tâche à un ordinateur »
[5]. Cette définition peut être raffinée en un modèle de la
conception d’un programme (figure 1), qui nous permet
de regrouper les difficultés et les erreurs des programmeurs novices, rencontrées dans la littérature [4; 12; 13].
The work being presented here intends to be an evaluation of this approach, in the perserpective of analysing
its efficiency in learning, and how learners appropriate
it. Three experiments of MELBA, the tool developed in
the context of the project, using different methods and
metrics, are thus described and discussed.
La première étape, le "quoi faire", consiste à définir précisément la tâche à automatiser pour parvenir aux spéci-
103
fications du programme. Cependant, cette étape est généralement court-circuitée : les tâches concernées sont très
(ou trop) simples (pour un humain). Les premières difficultés surviennent donc à l’étape suivante, lorsque l’on
s’efforce d’abstraire une stratégie en permettant
l’automatisation.
l’ « intérieur » de l’ordinateur. Une personne, étudiant la
physique, cherche à comprendre des phénomènes qui
(pour la physique élémentaire !) lui sont déjà familiers.
En revanche, en informatique, l’expérience pratique des
ordinateurs (suite bureautique, Internet, jeux vidéos …)
est pratiquement inutile pour comprendre la programmation.
Après avoir traduit l’algorithme ainsi obtenu dans un
langage particulier, et après l’inévitable cortège
d’erreurs syntaxiques peu utiles pour modéliser le fonctionnement de l’ordinateur, la dernière étape consiste à
valider le programme, par une série de tests, dont
l’interprétation des résultats soulève les mêmes difficultés. Il faut attendre cette phase (qui se caractérise par
un retour d’information « inversé » dans le temps – 1, 2,
3, figure 1) pour pouvoir juger de la validité de toutes les
précédentes.
Cette absence d’écho immédiat est la troisième difficulté
majeure de la programmation. Blackwell [2] qui, lui,
parle de « perte de manipulation directe », note que cette
caractéristique est celle qui conditionne l’appellation de
« programmation » dans le sens commun. Les gens disent qu’ils « programment » leur magnétoscope, leur site
Web en HTML, etc. Cette absence représente bien sûr
un important facteur aggravant pour les deux difficultés
précédentes…
Figure 1: Modèle de conception d’un programme, d’après [5].
Cette activité met en exergue la première difficulté majeure de la programmation, à savoir la difficulté
d’abstraction : le programmeur doit factoriser dans le
programme l’ensemble des comportements de la tâche. Il
en résulte un « syndrome de la page blanche », mis en
évidence notamment par Käasboll. Selon les étudiants :
« … lorsque le problème est présenté … on le décompose comme ça, comme ça, comme ça. Tout a
l’air simple et très logique, et puis c’est à toi et
Ouch! Par quoi je commence ? Peut-être que c’est
facile, mais le problème c’est que tu ne sais pas par
quel bout commencer quand il faut résoudre le problème … »
Ces différentes difficultés nous ont conduits à définir
trois objectifs pédagogiques spécifiques :
1. Apprendre à modéliser la tâche (abstraire de façon
exhaustive son déroulement)
2. Apprendre le modèle d’exécution du programme
(être capable de faire le lien entre la position dans le
programme et l’état du système).
3. Apprendre le modèle des données (pouvoir manipuler les structures de données informatiques et pouvoir modéliser les objets de la tâche par des structures adaptées).
L’étape suivante, « comment faire faire », décrit cette
stratégie sous une forme compréhensible par l’exécutantordinateur. Le programmeur débutant est alors confronté
à une difficulté importante venant de la distance cognitive séparant sa sémantique de la tâche de la sémantique
utilisée par l’ordinateur.
Pour ce faire, il nous paraît essentiel de disposer d’un
environnement d’apprentissage permettant de séparer le
plus possible les activités et les difficultés liées à chaque
objectif, afin de supporter un modèle incrémental de la
programmation2.
Considérons une description informatique d’un triangle
par : « int [][] ABC = {{2,2}, {4,13}, {10,6}} ». Cette
présentation « formelle » [5], issue de la sémantique de
l’ordinateur, diffère grandement de la représentation que
l’humain peut se faire des données de la tâche1 (en
l’occurrence le triangle). Cette problématique est compliquée par le fait que, comme le fait remarquer Ben-Ari
[1] le débutant ne possède aucun modèle « naïf » de
2
En effet, contrairement à la physique (où on étudie
d’abord la cinématique du point, puis la mécanique des
solides, puis la mécanique des fluides), en programmation, l’apprentissage des différents concepts se fait quasisimultanément. Ceci est en partie du au fait que
l’enseignement s’appuie sur des langages et des environnements « professionnels » (dans le sens où ils
s’adressent tous à des programmeurs confirmés).
1
Notons bien que ce « fossé cognitif » touche à des représentations « conceptuelles », et qu’il est donc quasiment indépendant du choix du langage de programmation que fera l’enseignant. Par exemple, il sera identique
avec Ada, Pascal et C, car tous trois sont des langages
procéduraux qui manipulent les même concepts.
104
UNE APPROCHE « BASEE SUR L’EXEMPLE » DE
L’APPRENTISSAGE DE LA PROGRAMMATION.
Tentant de réduire ces difficultés de conception, Smith
introduit avec Pygmalion le concept de « Programmation
sur Exemple » ([3] et [9]). Le programme édité est associé à un exemple concret, qui fournit en temps réel un
retour sur le comportement du programme.
Figure 3: l’environnement Stagecast Creator, pendant la construction d’une simulation de traffic ferroviaire
Illustrations de l’approche.
Nous nous proposons à présent d’illustrer cette approche
à partir de deux exemples tirés de l’état de l’art, à savoir
Pygmalion [3], le premier environnement de programmation basé sur l’exemple, et StageCast Creator [9], un
environnement permettant de concevoir « sur exemple »
des simulations ou des jeux vidéo en 2D.
Pertinence et limitations de l’approche « sur exemple ».
Dans le cadre de l’apprentissage de la programmation,
l’écho immédiat pourrait permettre de construire un modèle mental viable du comportement du programme, et
une représentation graphique « pragmatique » de l’état
du système devrait faciliter l’évaluation de celui-ci en
comblant le gouffre d’évaluation lié à la différence de
référentiels. L’apprentissage du modèle informatique de
représentation de la tâche serait alors l’étape suivante, et
pourrait ainsi s’appuyer sur le socle de connaissances
déjà existant.
Pygmalion, tout d’abord est un environnement de programmation visuelle « sur exemple » basé sur la métaphore du tableau blanc (ou noir), et sur le langage
SmallTalk. Il ne s’agit donc pas d’un langage3 visuel à
proprement parler, mais d’un espace de travail graphique. Comme on peut le constater figure 2, les différentes
variables et paramètres apparaissent sous la forme de cases, lesquelles contiennent la valeur courante de la variable. L’état du programme peut ainsi être affiché de façon exhaustive et continue, ce qui rétablit le principe de
manipulation directe.
On peut cependant reprocher aux systèmes « sur exemple » existants deux défauts majeurs. D’une part, ayant
pour cible un public d’« utilisateurs finaux », ils
s’attachent majoritairement à cacher le programme informatique qu’ils construisent, et donc ne permettent pas
de construire la relation programme-état au cœur de nos
objectifs pédagogiques. D’autre part, l’évaluation progressive de l’état du système est généralement obtenue
en contraignant les possibilités d’interactions avec le
programme.
En effet, l’écho proposé par le système impose obligatoirement que le programme soit toujours dans un état cohérent. La plupart de ces environnements vont plus loin
encore en obligeant le programmeur à entrer les commandes dans l’ordre chronologique. Les facilités apportées par l’évaluation progressive de l’état du système et
l’expressivité des commandes sont alors gommées par
ces contraintes, que Green [7] désigne sous le terme d’
« engagement prématuré ». Il leur manque le plus souvent la capacité de « revenir en arrière », ce qui génère
un grand « degré d’engagement », dans le sens où chaque erreur oblige l’utilisateur à reprendre tout depuis le
début. Il est donc conduit à planifier ses actions à
l’avance (« prévisualisation forcée ») pour éviter la
moindre erreur.
Figure 2: l’environnement de programmation Pygmalion ; la
figure représente la conception d’un programme calculant n ! .
Stagecast Creator, pour sa part, reprend l’approche sur
exemple en y ajoutant un aspect « pragmatique », dans le
sens où toutes les actions sont exprimées dans le référentiel du domaine de la tâche, et non dans un référentiel
informatique (par exemple, avec des trains et des rails, et
non pas avec des tableaux, des entiers, ou des «booléens» -figure 3).
3
Pour plus de détail sur la distinction entre langage visuel (comme G pour Labview) et environnement de visualisation de programmes, le lecteur pourra consulter
les taxonomies de Myers[10].
105
Zone de
représentation et
d’édition du
programme (sous la
forme d’un arbre
d’instructions)
Exemple présenté sous
forme graphique
permettant de
visualiser l’état du
programme.
Zone de sélection des
instructions / structures à
ajouter au programme
Zone de visualisation de la
trace d’exécution du
programme
Zone de changement de mode, permet
de basculer en fonctionnement
interactif ou pas. La barre contrôle la
vitesse d’animation de l’exécution (en
mode PLAY)
Figure 4 : Vue d’ensemble des composants de l’environnement MELBA.
Pour mesurer les apports que pourrait apporter à
l’apprentissage l’usage d’un exemple concret pendant la
conception du programme, nous avons conçu
l’environnement MELBA (Metaphor-based Environment to Learn the Basics of Algorithmic) décrit par la figure 4.
ajoutée, l’environnement affiche l’état après exécution
de cette instruction, et la trace associée à l’exécution du
programme jusqu’à ce point. « Lecture » fonctionne de
même, mais propose une animation de l’exécution, et
non pas seulement le résultat. Enfin, « stop » désactive
l’exécution immédiate, et le programme peut alors être
édité de façon « classique ».
MELBA : UN ENVIRONNEMENT D’APPRENTISSAGE
DE LA PROGRAMMATION « BASE SUR L’EXEMPLE »
OBJETS DES ETUDES EXPERIMENTALES
L’étudiant interagit avec le système en construisant par
insertions et suppressions le programme, qui est présenté
sous la forme d’un arbre. A chaque exercice est associé
un ensemble spécifique de commandes et de tests, accessibles par menus déroulants dans la zone opération, qui
agissent sur un modèle formel du système représenté
sous forme graphique dans la fenêtre d’exécution. Alternativement, il est possible de faire des exercices
« classiques » manipulant des données informatiques par
l’opération d’affectation. Une fenêtre d’historique supporte une représentation de la trace d’exécution du programme.
Nous présentons dans les sections suivantes un ensemble
d’expérimentations sur l’environnement MELBA pour
éclairer la pertinence de l’approche « à base
d’exemples » pour l’apprentissage de la programmation.
Pour ce faire nous avons testé les hypothèses suivantes :
1. L’évaluation progressive permise par une exécution
interactive peut-elle jouer un rôle positif dans
l’apprentissage de la programmation ?
2. La programmation « sur exemple », vu qu’elle
ajoute des contraintes à l’édition du système, est elle
utilisable par un apprenant débutant, ou bien le fait
de devoir intégrer simultanément le fonctionnement
d’un programme et le fonctionnement de
l’environnement crée-t-il chez lui une surcharge cognitive ?
3. Quelles compétences sont alors concernées, du diagnostic et de la compréhension de programmes à
leur composition ?
Le système peut être piloté suivant 3 modes. En mode
« Record », les fenêtres d’exécution et d’historique sont
synchronisées avec l’instruction en surbrillance dans le
programme. A chaque fois que l’utilisateur clique sur
une instruction et à chaque fois qu’une instruction est
106
4.
5.
6.
7.
Est-il pertinent d’utiliser la visualisation de programme en apprentissage de l’algorithmique et de la
programmation ?
Faut-il privilégier en ce cas une approche superficielle (qui permet d’avoir rapidement une vue
d’ensemble de l’état du système) ou bien en profondeur (qui fournit une information précise et détaillée, mais nécessite d’être explorée par l’apprenant) ?
Ces deux approches peuvent-elles être combinées ?
(par exemple en proposant deux représentations simultanées et en partie redondantes entre lesquelles
l’utilisateur pourrait créer des liens), ou cela crée-t-il
une surcharge cognitive ?
L’animation a-t-elle une importance critique dans la
visualisation de programme pour l’apprentissage de
la programmation ? Ou bien est-il plus pertinent de
représenter uniquement l’état du programme à certaines positions importantes (sur le modèle des
« points d’arrêts » des debuggers) ?
CHOIX DES METRIQUES
D’EVALUATION.
ET
DES
l’impact à long terme sur la compréhension. Sur les 65
étudiants suivant le cours, 24 ont utilisé l’environnement
MELBA. Le reste de la promotion a suivi un cursus de
TD classique (papier-crayon).
L’environnement Melba, dans cette expérimentation,
était dégradé de telle sorte que seul le mode « sur exemple » (RECORD) était disponible, car cette fonctionnalité constitue le socle de l’approche – et devait donc être
évaluée en priorité (pas de programmation « classique »
ni d’animation). L’historique n’était pas non plus disponible. Les études sur les facteurs influant sur les résultats
aux premiers modules de programmation – telles que [6]
- ayant mis en évidence une corrélation importante avec
une expérience préalable en programmation, nous avons
fait en sorte de « distribuer » uniformément les élèves
ayant déjà ces compétences. Les étudiants du groupe
machine étaient répartis à un par machine. Les résultats
du partiel montrent que le taux d’élève ayant la moyenne
aux exercices portant sur les concepts travaillés avec
l’outil est supérieure de 18 points dans le groupe avec
MELBA (table 1). Cela représente une significativité de
74% (0,26) selon le test khi2. Si, dans l’absolu, un tel résultat est assez faible, au vu de la taille des échantillons,
il s’avère suffisant pour ouvrir la voie à des expérimentations plus approfondies.
MODALITES
Concernant un environnement destiné à l’apprentissage,
la mesure de l’utilité couvre deux aspects distincts et cependant connectés [11]. D’une part, on souhaite évaluer
l’apprentissage (de la discipline enseignée et non pas de
la manipulation du système), et d’autre part on souhaite
tester la capacité à réaliser des tâches (exercices de programmation).
% de résultats
>= moyenne
Pour ceci, nous allons utiliser des méthodologies de tests
issues de différentes disciplines dont l’objet d’étude est
l’apprentissage. On peut pratiquer une première disctinction entre méthodes « quantitatives », qui visent à
quantifier l’impact d’un environnement sur la réalisation
de tâches et/ou l’apprentissage, ou méthodes
« qualitatives » qui permettent de comprendre le cheminement interne de l’apprenant ou de donner des indications sur son degré de conscience face à son apprentissage. D’autre part, on peut distinguer deux types de mesures : « en-ligne », où la mesure se fait pendant la tâche
(nombres d’erreurs, temps pour accomplir la tâche, fixations oculaires …) ou « hors-ligne ». Cette seconde approche ne permet pas d’évaluer le comportement de
l’étudiant pendant son apprentissage, mais peut donner
des informations importantes sur sa compréhension.
Groupes PsE
(22)
76 %
(16)
Groupes témoins
(43)
58 %
(25)
Table 1 : Résultats comparés des groupes avec et sans l’outil.
La répartition des notes (table 2) montre que les différences se concentrent essentiellement sur les notes les
plus faibles et sur les notes moyennes, même si le pourcentage de scores supérieurs à 75% est également supérieur avec l’outil. Ces résultats tendent à confirmer
l’hypothèse 1.
Répartion des notes (par quart)
Q1
Q2
Q3
Q4
2 (9%) 4 (18%) 6 (27%) 10 (45%)
Melba
Témoin 10 (23%) 8 (19%) 8 (19%) 17 (40%)
Table 2 : Répartitions des notes des groupes avec et sans
l’outil.
PREMIERE EXPERIMENTATION.
DEUXIEME EXPERIMENTATION
Dans un premier temps, nous avons cherché à obtenir
des indicateurs sur la première hypothèse. Pour ce faire,
nous avons choisi de pratiquer une évaluation en conditions réelles dans un cours d’initiation à la programmation en L3 pour des bio-informaticiens, comportant 4h
de cours et 12 h de Travaux Dirigés (TD). Le choix de la
méthode s’est portée sur une évaluation quantitative
hors-ligne, sous la forme d’un test (classique dans ce
contexte), avec documents, deux semaines après les
séances de TD, car notre objectif était de quantifier
Nous avons ensuite complété l’outil en ajoutant les autres modes, et en permettant deux types de visualisation.
Pour le programme, le composant d’historique complète
le panneau du programme, en permettant d’explorer très
finement la trace de l’exécution. Pour l’exemple, une
vue « système » montrant les structures de données fut
rajoutée, pouvant remplacer ou compléter la visualisation graphique de la tâche. Ces nouveaux composants
nous permettent dès lors de tester directement les hypo-
107
thèses 4, 5, 6 et 7, par les mêmes modalités que précédemment.
Un des enseignements que l’on peut en tirer est que,
alors que nous avons observé pendant les TD (évaluation
en-ligne qualitative) que de nombreux étudiants faisaient
un usage intensif de la fonctionnalité d’animation, les résultats quantitatifs ne sont pas meilleurs pour autant. En
parallèle, nous avons noté une désaffection du composant d’historique, et une utilisation exclusive de la représentation la plus synthétique de l’état du système, quand
deux vues parallèles étaient proposées. Il semblerait
donc que si la visualisation se soit avérée pertinente dans
notre cas (4) pour exprimer les relations état-programme,
elle doive y être focalisée sur une vue superficielle permettant de donner du premier coup d’œil l’état général
du système (5). L’hypothèse 6 sur l’usage en combinaison des deux approches de la visualisation s’est avérée
non fondée. Le tableau 4 ci-dessous illustre la répartition
des résultats dans les différentes tâches. Celle-ci s’avère
plus « uniforme » que lors du premier test, même si le
pic au troisième quartant y réapparait lors de la tâche de
compréhension, la différence dans Q4 se retrouvant, elle,
dans la tâche de rédaction.
Nous avons donc mené une deuxième expérience sur un
cursus d’ « Initiation à la programmation pour les biologistes » en L1/L2. Celui-ci se décomposait en deux parties : une partie introductive, d’initiation à
l’algorithmique (4h de cours et 6h de TD) validée par un
partiel, sans document, et une partie consacrée au langage Perl. L’expérimentation avait pour cadre la première partie.
Sur les 41 étudiants qui suivaient ce cours, 17 ont formé
un groupe de TD travaillant sur MELBA. Pour 15
d’entre eux, ce cours était une première initiation. Pour
des raisons logistiques, les étudiants étaient 2 par machine, et non pas seuls face à l’environnement. 24 autres
ont suivi un cursus de TD classique, parmi lesquels 18
novices complets. Parmi les exercices du partiel, trois
portaient sur un objectif spécifique traité avec l’outil en
TD (voir table 3). Ce découpage plus fin doit permettre
de tester la troisième question. Ces tâches ont donné les
résultats suivants:
Notes supérieures à la
moyenne
Description d’exécution:
Rédaction de programme:
Compréhension de la tâche:
Total :
Melba
(15)
6 (40%)
6 (40%)
14 (93%)
7 (47%)
Répartition des Notes (Description de la trace) :
Q1
Q2
Q3
Q4
>=50%
9 (60%)
0% 4 (27%) 2 (13%)
40%
12 (67%) 2 (11%) 2 (11%) 2 (11%)
22%
Témoin
(18)
4 (22%)
6 (33%)
14 (78%)
5 (28%)
Répartition des Notes (Rédaction de programme) :
Q1
Q2
Q3
Q4
>=50%
5 (33%) 4 (27%) 2 (13%) 4 (27%)
40%
5 (28%) 7 (39%) 2 (11%) 4 (22%)
33%
Table 3 : pourcentages de notes supérieures ou égales à la
moyenne dans les deux groupes, selon la tâche demandée.
Table 4 : Répartition des notes dans les deux groupes.
On retrouve le même type d’écart observé dans
l’expérimentation précédente, pour tout ce qui concerne
la compréhension (au sens large) de programmes (i.e.
+18, +16 et +19 points). Ces écarts sont significatif à
respectivement 89, 68 et 86% selon le test du khi2. Le
premier et le dernier écart sont donc très significatifs de
par la faible taille de l’échantillon. Pour ce qui concerne
l’écriture de programmes, l’écart est plus faible
(« significatif » à 56% !).
USAGES DE L’ENVIRONNEMENT
Par ailleurs, dans le but de répondre aux questions tenant
plus à l’usage et à l’accomplissement de la tâche (2, par
exemple), une évaluation en-ligne s’imposait, car seule
cette approche est à même de quantifier les usages et les
difficultés d’utilisations éprouvées par les apprenants.
Pour cela, une expérimentation a été conduite sur un
oculomètre Tobii 1750 par Multicom, à Grenoble, auprès de 6 sujets, 3 étudiants de première année et 3 lycéens de première S. Deux tâches spécifiques (compréhension et correction, rédaction complète) y ont été étudiées. Cette expérience a délivré des traces de deux types, d’une part des indicateurs oculaires, d’autre part le
log des clics souris, notamment sur les changements de
mode.
Cela est étonnant, car le test de la première expérimentation portait essentiellement sur cette activité. Plusieurs
hypothèses peuvent être faites à ce sujet, qui prennent en
compte deux changements dans le protocole. D’une part,
il est possible que placer les étudiants à deux par machine ait changé la donne. Les étudiants ayant eu un rôle
moins actif n’auraient pas eu le même bénéfice dans une
situation de composition, mais que leur rôle
d’observateur leur ait permis de développer la compréhension de programmes. La deuxième hypothèse serait
que dans le premier test, les étudiants ayant eu droit aux
documents, leur meilleure compréhension des corrigés
leur aurait permis de s’en inspirer efficacement.
Indicateurs Oculaires
Les indicateurs de l’oculomètre (table 5) nous permettent
ainsi de répondre rapidement à la dernière question. On
constate que la zone d’historique est très peu regardée
(respectivement 2,5% et 1,1% des fixations oculaires),
les zones les plus pertinentes pour les apprenants étant
(sans surprise) le programme, suivi des zones opération
et exécution. La deuxième information importante est la
108
forte augmentation du pourcentage de fixations dans les
zones programme et opération au détriment de la zone
exécution, lors de la tâche 2.
firmer cette hypothèse, analysons l’utilisation des différents modes du système.
Traces des clics souris
Zône d’intérêt
Programme
Exécution
Opérations
Historique
Modes
Popups_erreur
Tâche 1
Intéressons-nous en premier lieu à la répartition de
l’usage des modes sur l’ensemble des deux tâches, en
mesurant le prorata de temps passé dans chaque mode
(table 6). Le temps passé en mode interactif (qui fournit
un écho actif : RECORD et PLAY) est plus important,
ce qui confirme le besoin d’un retour rapide et facile à
décrypter. Néanmoins les valeurs importantes de PLAY
et STOP semblent également confirmer la difficulté
d’intégrer le paradigme d’édition « sur exemple ». Par
ailleurs RECORD progresse au détriment de PLAY.
Cela n’est qu’à première vue incohérent avec les indicateurs oculaires. En effet, si le nombre de commandes
exécutées est de 10, par exemple, le programmeur
consulte l’exemple 10 fois en mode PLAY, contre 1 en
mode RECORD (l’état final)…
Tâche 2
45,5%
24,2%
18,8%
2,5%
3,3%
5,7%
51,9%
9,8%
28,5%
1,1%
1,9%
6,8%
Table 5 : Distribution des fixations en pourcentage, pour les
tâches de correction (1) et de rédaction de programme (2).
Les différences de nature entre les deux tâches peuvent
être considérées comme la première raison de ces changements. En effet, la première tâche consiste à corriger
un programme existant, donc l’exploration du programme pour le comprendre est essentielle et explique la
place prépondérante des zones de programme et
d’édition. A contrario, dans la deuxième tâche, le programme manipulé est celui de l’utilisateur, de plus construit progressivement, et ne nécessite donc pas une exploration approfondie pour en inférer le sens. Cette hypothèse est cohérente avec les transitions entre zones
(Figures 5a et 5b). Les transitions Programme-Exécution
ne diminuent que de 4 points environ, ce qui atteste que
c’est l’exploration interne de la zone d’exemple qui diminue dans la seconde tâche, bien plus que les consultations de celle-ci.
Mode :
RECORD
PLAY
STOP
Debug :
Composition : Total :
26,2%
37,6%
31,9%
29,2%
19,3%
24,2%
44,3%
43,1%
43,7%
Table 6 : Répartition de l’usage des différents modes du logiciel pour chaque tâche.
Ces informations demeurent cependant encore trop générales pour pouvoir tirer des conclusions sur les usages de
l’environnement. Les tables 7a et 7b répertorient
l’utilisation de chaque mode par chaque sujet. On constate une grande variabilité interindividuelle. On peut cependant extraire trois catégories, une proche de la programmation « sur exemple » (80%+ en mode interactif,
édition en RECORD), une correspondant à ce que permettent les environnements de programmation classique
(§35% PLAY, 65% STOP) et un profil hybride (§50%
interactif).
Exercice 1 – Correction d’erreurs
Sujet RECORD PLAY
STOP
Temps
S1
73,9%
13,3%
12,2%
17 mn 07 s
S2
10,4%
35,5%
53,2%
17 mn 24 s
S3
70,4%
11,8%
17,9%
4 mn 52 s
S4
0%
34,6%
65,4%
10 mn 24 s
S5
2,4%
38,4%
58,4%
2 mn 58 s
S6
0%
41,8%
58,2%
4 mn 25 s
Figure 5a : Transitions entre les différentes zones de
l’interface, dans l’exercice de détection/correction d’erreur.
Table 7a : Utilisation de chaque mode par chaque sujet, et
temps de réalisation (1° tâche)
On peut constater que les trois profils sont équitablement
répartis et ne sont pas en corrélation avec le temps
d’accomplissement de la tâche. De plus, un individu peut
changer de profil d’une tâche à l’autre (tels que S1, S2,
et S4). Il se peut que le choix du style d’interaction selon
la tâche dépende du style d’apprentissage du sujet ou
Figure 5b : Transitions entre les différentes zones de
l’interface, dans l’exercice de rédaction de programme.
Par ailleurs, ces indicateurs laissent à penser que la recherche d’un écho du système à chaque modification
n’est pas systématique, ce qui contredit un peu le paradigme « sur exemple ». Pour pouvoir confirmer ou in-
109
d’une autre caractéristique cognitive. Le confirmer ou
pas demandera des investigations ultérieures.
programmation. L’association de ces trois profils à des
caractéristiques cognitives de l’apprenant est une piste
d’approfondissement, tout comme étudier la pertinence
de l’approche en enseignement à distance.
Exercice 2 – Composition de programme
Sujet RECORD PLAY
STOP
Temps
S1
23,2%
12,9%
63,8%
8 mn 10 s
S2
78,8%
4,5%
16,7%
16 mn 45 s
S3
91,6%
0%
8,4%
4 mn 45 s
S4
28,9%
21,4%
49,8%
8 mn 35 s
S5
0%
28,7%
71,3%
8 mn 42 s
S6
3,1%
48,1%
48,8%
17 mn 07 s
REMERCIEMENTS
Nous souhaitons remercier les membres de l’équipe
Multicom du laboratoire CLIPS-IMAG pour leur
conduite de l’expérimentation oculométrique, et leur
aide à l’exploitation des résultats.
BIBLIOGRAPHIE
Table 7b : Utilisation de chaque mode par chaque sujet, et
temps de réalisation (2° tâches)
1.
Ben-Ari, M. Constructivism in Computer Science
Education. in 29th ACM SIGCSE Technical Symposium on Computer Science Education. 1998. Atlanta Georgia: ACM press.
2.
Blackwell, A. (2002). What is Programming? PPIG
Workshop, Brunel University, London, UK.
3.
Cypher, A., ed. Watch What I Do: Programming by
Demonstration. . 1993, The MIT Press: Cambridge,
Massachusetts. 604.
4.
Du Boulay, B., Some Difficulties of Learning to
Program, in Studying the Novice Programmer.
1989, Lawrence Erlbaum Asssocites. p. 283-299.
5.
Duchâteau, C., Images pour programmer. Vol. 1.
2000.
6.
Goold, A. and Rimmer, R. (2000). “Factors affecting Performance in Firs-Year Computing.” SIGCSE
Bulletin 32(2): 39-43.
7.
Green, T. R. G. (1989). Cognitive dimensions of
notations. People and Computers.
8.
Käasboll, J., Exploring didactic models for programming. 1998 : Norsk Informatikk-konferanse,
Høgskolen i Agder.
9.
Lieberman, H., Your Wish is my command. 2001:
Morgan Kaufmann. 416.
CONCLUSION ET PERSPECTIVES
Dans cet article, nous avons étudié la pertinence d’un
paradigme alternatif de conception : « la programmation
sur exemple » pour supporter l’apprentissage de la programmation. Pour cela, nous avons proposé une synthèse
des différents types de difficultés auxquels sont
confrontés les étudiants en initiation à la programmation,
qui semble attester de l’adéquation de cette approche aux
objectifs pédagogiques.
Nous avons présenté un environnement d’apprentissage
de la programmation, MELBA, basé sur ces concepts, et
rapporté les résultats de trois expérimentations menées
sur cet outil pour évaluer l’approche. En travaillant sur
la base de sept hypothèses, nous sommes arrivés à un
certain nombre de conclusions :
x L’évaluation progressive permise par une exécution
interactive joue un rôle positif dans l’apprentissage
d’un modèle d’exécution du programme (H1), en
particulier en compréhension de programme, et en
recherche / correction d’erreurs (H3).
x Pour cela, des techniques de visualisation de programme proposant un modèle graphique de l’état du
système sont nécessaires (H4) ; pour être efficaces,
elles doivent fournir une vue d’ensemble d’où les
informations importantes peuvent être extraites rapidement (H5).
x Combiner plusieurs modèles graphiques de la même
information semble inutile et superflu (H6).
x L’animation de l’exécution du programme, quoique
naturellement utilisée par beaucoup d’étudiants, ne
semble pas apporter de gain quantifiable (H7).
x Les mesures des usages nous indiquent que la programmation « sur l’exemple » est utilisée indifféremment par des néophytes ou par des étudiants
plus qualifiés (H2). Cependant, les contraintes
qu’elle impose sur l’ordre d’édition n’en font probablement pas le mode d’interaction le plus naturel
pour nombre d’apprenants.
10. Myers, B. A. (1986). Visual Programming, Programming by Example, and Program Visualization :
A Taxonomy. Human Factors in Computing Systems
(CHI'86), New-York, ACM/SIGCHI.
11. Nogry, S. Jean-Daubias, S. Ollagnier-Beldame, M.
(2004). Evaluation des EIAH: une nécessaire diverstité des méthodes. TICE 2004, Compiègnes.
12. Pea, R.D., Language-Independent Conceptual
“Bugs” in Novice Programming. Journal of Educational Computing Research, 1986. 2(1): p. 25-36.
13. Teaching and Learning Computer Programming,
R.E. Mayer, Editor. 1988, Lawrence Erlbaum Associates. p.153-178.
Ces mesures nous ont amenés à définir deux autres profils d’utilisation, eux aussi indépendants du niveau en
110
Approches orientées services Web de l'IHM de
supervision : nouvelles solutions technologiques pour
les ingénieurs et nouvelles problématiques
pour les ergonomes ?
Djilali Idoughi (1,2)
Christophe Kolski (2)
(1) Université A. Mira, Béjaia 06000, Algérie.
[email protected]
(2) LAMIH-UMR CNRS 8530, University of valenciennes and Hainaut Cambrésis,
Le Mont Houy 59313, Valenciennes cedex 9,
France.
[email protected]
RESUME
les missions de la supervision, en l’occurrence
la surveillance, la gestion des alarmes, l’analyse des données, l’amélioration de la maintenance, l’optimisation
des procédés, la garantie de la qualité ou encore la gestion de la traçabilité. La facilité d’utilisation des
différentes fonctions mises à la disposition de ces
différents acteurs sera aussi d’une importance capitale
[15].
Dans cet article, nous considérons l’IHM de supervision
dans un contexte technologique nouveau et en constante
évolution, lequel est caractérisé par des aspects importants comme la mobilité et la coopération entre acteurs
d’une part, et l’inter connectivité, l’interopérabilité et
l’hétérogénéité des systèmes industriels utilisés d’autre
part. De nouvelles solutions technologiques « attrayantes » pour les ingénieurs devraient conduire à de nouvelles problématiques pour les ergonomes.
La tendance actuelle dans l’industrie est d’intégrer de
tels systèmes de supervision que l'on qualifie de traditionnels, avec de nouvelles fonctions inhérentes au système d’information sous-jacent intégrant les personnes,
le(s) process et les informations, lesquels peuvent être
accédés désormais en dehors de la salle de contrôle.
Grâce à l’évolution au niveau des nouvelles sciences et
technologies de l’information et de la communication,
différents supports d’information peuvent même être
maintenant envisagés (PDA, Pocket PC, téléphones portables, etc.) [8] et font d’ailleurs d’ores et déjà l’objet de
nombreuses réalisations dans les industries de process,
alors qu’elles n’ont fait l’objet que de peu d’évaluations
sous l’angle de l’ergonomie.
MOTS CLES : Supervision basée sur le web, Interaction Homme-Machine, Services Web, Architecture
orientée services, Processus métier, Intégration de services.
ABSTRACT
We consider HCI issues for modern supervisory and
control systems within a new technological context, in
constant evolution. This evolution is characterized by
some important features such as mobility, cooperation
between human actors, but also interconnectivity, interoperability and heterogeneity of industrial systems. New
technological solutions, which are attractive for the engineers, have to lead to new problematics for the ergonomists.
Pourtant, différents modes d’utilisation, différentes ressources matérielles imposent des interactions HommeMachine différentes. A l’évidence, l’IHM d’une application ne peut être identique sur un téléphone portable ou
sur une station de travail en raison de leurs différences
en termes de ressources matérielles (taille de l’écran, absence de claviers, etc.) [25]. Ceci induit non seulement le
développement de solutions interactionnelles ou d’IHM
dédiées, mais aussi de préciser clairement les différentes
classes d’utilisateurs concernées et les différents types
de tâches qui sont susceptibles d’évoluer suite à l’apport
de ces nouveaux moyens d’interaction.
KEYWORDS : Web-based Supervision, HumanComputer Interaction, Web services, Services oriented
Architecture, Business processes, Services integration.
INTRODUCTION
L’Interaction Homme-Machine joue un rôle prépondérant dans tout système de supervision [18,22,23]. Depuis
longtemps, on considère que l’opérateur humain en salle
de contrôle doit disposer de vue(s) globale(s) sur le système tout en ayant la possibilité de modifier des valeurs
de paramètres du procédé supervisé selon la situation en
cours [10,16]. De façon plus globale, le système interactif mis à la disposition des différents acteurs (incluant les
opérateurs de supervision) de l’organisation mise en
place au sein de l’entreprise doit considérer les principa-
Dans ces conditions, la nécessité ou le besoin d’une
nouvelle approche pour la conception et l’évaluation de
ces nouveaux systèmes de supervision de processus industriels devient impératif ; de nouvelles perspectives et
problématiques semblent apparaître pour les ergonomes.
111
Certes le concepteur des nouvelles IHM de supervision
doit proposer une méthodologie de conception dont le
rôle central est l'opérateur humain, mais la supervision
conventionnelle ou traditionnelle est profondément différente de celle basée sur les technologies de l'information, notamment celles du web. En ce sens, les besoins et
les spécifications de l'opérateur dans le contexte d'une
supervision basée sur le web sont ou peuvent être exprimées différemment. Jusqu'à présent, les recherches menées sur l'IHM en général et la supervision en particulier
ont proposé des méthodologies de conception d'IHM
d'une manière générale où les spécifications de l'opérateur vis-à-vis de l'IHM de supervision ne sont exprimées
que par rapport à un contexte centralisé de la supervision
(en salle de contrôle), difficilement modifiable.
physiquement séparées mais qui coopèrent pour réaliser
différentes tâches. Par conséquent, les informations nécessaires à une supervision sont devenues désormais distribuées et l'accès à l'information, son traitement se font
souvent dans des lieux différents. Le support de l'information est aussi très hétérogène, dû à la diversité des
équipements, des différents systèmes d'exploitation, des
langages de programmation, des nombreux types de bases de données. Il apparaît donc nécessaire de considérer
la supervision dans un environnement hétérogène et distribué. Un traitement répondant à ce besoin est un traitement ouvert réparti.
Généralement, au niveau des différents responsables de
départements ou services, comme par exemple des responsables de production, méthodes, qualité, maintenance
et autres, la supervision accumule un nombre considérable d'informations devant être traitées et analysées efficacement et fiablement sachant que la complexité d'un
système de supervision devient importante dès que les
données échangées s’accroissent relativement au nombre
de plus en plus important d'équipements qu’il devient
possible de superviser. Par conséquent, la supervision
doit pouvoir fournir suffisamment d'outils et de méthodes de visualisation et d'extraction d'informations permettant une information synthétique, accessible de partout, au moment voulu et indépendamment des dispositifs d'accès (PC, PDA, Pocket PC, etc...).
Peu de travaux ont été réalisés pour obtenir un retour
d’expérience quant à l’exploitation et l'utilisation des
technologies du Web et d’internet dans le contexte de la
supervision, malgré un potentiel mis en évidence par
plusieurs auteurs [11,28,32,33]. En réalité, la supervision
et le contrôle basés sur Internet sont un nouveau et récent concept où réellement peu de travaux ont été effectués pour développer des méthodes de conception systématiques, dans lesquels des volets importants de
conception sont à considérer selon un nouvel angle de
vue [33] ; en particulier : la spécification des besoins relatifs aux acteurs de différents types distribués dans le
temps et l’espace, la sélection d’architecture ou de modèle d’architecture basé sur le web, la conception
d’interface Web, la supervision et le contrôle (et un ensemble de tâches annexes) exploitant les potentialités du
web, les tests de sûreté du système totalement distribué
et l’accès concurrentiel aux utilisateurs (et donc pas seulement aux opérateurs de la salle de contrôle, mais à un
ensemble d’intervenants de différents corps de métier, et
de niveaux hiérarchiques variés).
Une tendance actuelle tente de mettre la supervision au
cœur de l'entreprise où tous les acteurs de cette entreprise puissent interagir avec tous les processus métiers et
en apportant de nombreuses possibilités de visualisation
ou de vues de l'entreprise selon les besoins et les objectifs de chaque acteur dans un environnement Web exprimés à l’aide de services Web. L'application web de
supervision consultée par un opérateur humain résulte en
fait de la mise en œuvre de services Web pouvant être
assemblés et développés en interne à l'entreprise dans
l'objectif d'intégration d'applications d'entreprise, de personnes et de process, et en externe dans le cas de la supervision multi-sites par exemple ou d'ouverture de l'entreprise à l'extérieur pour ses partenaires et fournisseurs.
Il s’agit à terme d’intégrer la dimension technologique
notamment celle du Web et des sciences et technologies
de l’information et de la communication dans le processus de construction d’IHM de supervision basé sur la notion de services Web ; pour cela il devient possible pour
les ingénieurs de s’appuyer sur une architecture orientée
services dont les principales motivations et objectifs sont
exposés brièvement ci-après.
ARCHITECTURE ORIENTEE SERVICES (SOA) ET
CONCEPT DE L’ORIENTATION SERVICES
L'architecture orientée services (SOA) est un moyen de
réutiliser l'existant et de le transformer en des services
plus agiles [5] (visant une grande interconnexion entre
les différents départements, groupes de travail ou simples acteurs de l’entreprise, pour aller vers des capacités
de réactivité de plus en plus grandes). La base d'une
SOA repose sur des services répondant aux critères suivants : faiblement couplés, distribués, invocables et publiables et orientés métier. Avec ce type d'architecture,
les processus métiers, les présentations des informations
et contenus (écrans), les logiques applicatives et les données sont séparées dans des couches distinctes et faible-
NOUVELLES MOTIVATIONS ET NOUVEAUX
OBJECTIFS POUR LES INGENIEURS
Le besoin de réseaux de communication est né de l'intérêt de mettre à disposition des utilisateurs, répartis géographiquement, des fonctions de traitement et des ressources informatiques présentes sur un ensemble de stations.
Les applications informatiques y compris celles de supervision sont devenues réparties et sont construites à
partir de ressources matérielles et logicielles qui sont
112
ment couplées [4]. L'architecture décompose les applications en services, disponibles et réutilisables à travers laquelle le système d'information d'une entreprise peut être
totalement intégré, c'est-à-dire qu’il doit permettre une
combinaison efficace et flexible de ressources que constituent les personnes, les process et les informations dans
un but d'optimisation, par exemple de la production
quand il s'agit de la supervision, à travers et au delà de
l'entreprise.
comme IBM, Epicentric [6], Netgrity/DataChannel regroupés sous l'égide du comité technique WSIA (Web
Services Interactive Applications) au sein de l'OASIS
(Organization for the Advancement of Structured Information Standards) [19]. Cet accès aux applications et
aux services web concerne tant l'accès direct par l'utilisateur aux services via un navigateur web que la gestion de
la syndication1 et de l'assemblage de services web par
différents intermédiaires avant l'interaction avec l'utilisateur final. Les deux scénarios ayant servi de base à l'élaboration de spécifications décrites ci-dessous sont d'une
part : l'accès multi canal des utilisateurs aux services
web (PC, PDA, Téléphones cellulaires) et d'autre part,
l'agrégation de services web sous une mise en page unique par un intermédiaire d'un canal de distribution qu'est
celui de portails (voir plus loin). Mais aussi, des spécifications comme WSFL d'IBM, Xlang de Microsoft ont
été élaborées pour assurer l'assemblage en amont des
services web. Cet aspect n'est pas considéré dans cet article.
L'approche SOA prône une conception désolidarisée des
développements traditionnels (conçus le plus souvent selon le découpage suivant : présentation, logique métier,
base de données) ; en ce sens, elle sépare la conception
selon la présentation, l'interaction, les processus, les services et les bases de données. Par conséquent, le choix
en amont d'une telle architecture va guider la manière
dont les applications (et donc leurs IHM) vont être
conçues, tant sur la manière de concevoir les composants
et les services, que sur leurs interactions dans le cadre du
système d'information global [5].
Les Services Web s’appuient sur un modèle d’interaction
assurant trois rôles : (1) celui de fournisseur de services,
(2) celui d’annuaire de services, (3) celui de demandeur
de services. Ceci est réalisé selon les trois types
d’opérations suivantes : Publication de description de
services (Opération Publish/Publier), Recherche et découverte de la bonne description de services (Opération
find/Rechercher) et Association ou invocation des services basés sur la description (Opération bind/Lier), d’une
part, et d’autre part, en se basant sur un ensemble de
standards tels que : http, SOAP [24], WSDL [31] et
UDDI [26] facilitant le transport, l’invocation, la description et la recherche de services Web, comme illustré
par la figure 1.
Les services web [30] forment un des éléments d'une
SOA. Ils fournissent la base technologique pour faire
communiquer les applications entre elles. Ils ont l'intérêt
de réduire les coûts et la complexité dans la mise en œuvre d'une SOA [13], comme expliqué dans la section suivante.
DEFINITIONS ET CARACTERISTIQUES TECHNIQUES
DES SERVICES WEB
Les services web sont des applications auto descriptives,
modulaires et faiblement couplées qui fournissent un
modèle simple de programmation et de déploiement
d’applications, basé sur des normes et s’exécutant aux
travers de l’infrastructure Web. Ils réalisent des fonctions allant des simples requêtes aux processus métiers
sophistiqués.
annuaire de
Services
Description de
services
Trouver
Les Services Web ont pour objectif d’assurer à travers le
réseau Internet ou intranet, l’interaction entre les applications, les ordinateurs et les processus métier via les
protocoles Internet et XML [7] en permettant d’accéder
de manière uniforme, à partir d’un seul accès Web à plusieurs services applicatifs distants. Ils correspondent
donc à de nouveaux composants logiciels dans un système d’interaction fondé sur le Web, et sont déployés sur
de multiples canaux de distribution [13].
Publier
WSDL, UDDI
demandeur
de services
WSDL,UDDI
Invoquer
fournisseur
de Services
Figure 1 : Déploiement des services web
LES PRINCIPALES APPROCHES DE SOLUTIONS
ORIENTEES
SERVICES
POUR
L’INTERFACE
HOMME-MACHINE
Dans une SOA basée sur les services web, une application Web est définie comme étant une application au travers d’un ou de plusieurs services Web chargés
d’adapter la présentation de l’information au canal de
distribution et aux profils des utilisateurs. Ainsi,
l’utilisateur final doit disposer en principe de
l’information dont il a besoin quel que soit son mode
d’accès [4]. Cet accès en aval à ces services web a été la
préoccupation d'un groupe de sociétés et d'éditeurs
Cette section présente et décrit très brièvement les différentes spécifications concernant les interfaces utilisateurs
1
Syndication : procédé consistant à rendre disponible une partie du
contenu d'un site web afin qu'elle soit utilisée par d'autres sites. Pour
une définition plus complète, voir :
http://www.dicodunet.com/definitions/commenter-430.htm
113
des services Web qui sont : WSUI exploitant XML [32],
WSXL d’IBM en utilisant WSDL [12], WSIA [21] et
WSRP [20] d'OASIS.
tion, (4) les composants de contrôle. L'ensemble de composants de données et de présentation liés par un composant de contrôle forme un conteneur WSXL.
WSUI - Web Service User Interface. WSUI a été propo-
WSIA - Web Services for Interactive Applications.
sé à l’origine par Epicentric. Son objectif vise à décrire :
(1) la présentation des services Web à leur utilisateur via
des instructions de mise en page des résultats des invocations de ces services ; (2) le modèle des interactions
avec l’utilisateur. WSUI peut donc faire office de standard pour la définition d'interfaces utilisateurs relatives
aux services web [2]. A ces fins, WSUI introduit et formalise en un dialecte XML les composants suivants :
composants et conteneurs, pages et vues, évènements et
flux d’interaction. Le composant WSUI, entièrement décrit en XML, est une application Web indépendante de la
plate-forme d’exécution, capable d’invoquer des services
Web d’une part, et de présenter des informations à
l’utilisateur et de réagir à ses commandes c’est-à-dire à
un ou plusieurs services Web avec son interface graphique et son modèle d’interactions d’autre part. Le conteneur peut être constitué de plusieurs pages Web ; chaque
page Web comporte une ou plusieurs vues sur des composants WSUI. Un composant peut être affiché sous plusieurs vues dans la même application (ex. html pour navigateur Web et WML pour un téléphone WAP). A notre avis, cette possibilité peut être exploitée pour prendre
en charge les notions d’adaptabilité en rapport avec celle
de plasticité2 d’IHM [3,25].
WSIA [21] est une spécification proposée par l'OASIS
dont l'objectif est de fournir un modèle de composants
d'interfaces basé sur XML et les services web pour
consolider les travaux déjà engagés par IBM avec
WSXL d'une part et les efforts engagés par Epicentric
avec WSUI d'autre part. WSIA constitue un modèle unifié des interactions avec les services web.
WSXL
-
Web
Service
Experience
WSRP - Web Service Remote Portal. La spécification
WSRP [20] concerne l'agrégation de contenus entre portails d'information en formalisant l'architecture de portlets3 sous-jacentes à WSXL.
Les Services Web pour Applications Interactives
(WSIA) et Services Web pour Portails distants (WSRP)
définissent une interface de service web pour accéder et
interagir avec des présentations interactives orientées
web services indépendamment des canaux de diffusion.
APPLICATION A L'IHM DE SUPERVISION
Nous nous intéressons aux systèmes ayant la capacité à
créer des interfaces utilisateurs pouvant dialoguer avec
les processus métiers d’une part, et ayant des capacités
de Workflow intégrées permettant d’assigner des tâches
aux opérateurs en fonction de leur profil d’autre part.
Aussi, l’IHM d’un système de supervision est basée sur
le modèle des services Web décrit précédemment. Ce
modèle d’IHM propose plusieurs services Web relatifs à
la supervision et la communication (interaction) entre
différents acteurs humains (opérateurs en salle de
contrôle, rondiers, équipes de maintenance, ingénieurs
de production, décideurs, managers, experts, etc.) constituant l’organisation globale de l'entreprise.
Language.
WSXL est la spécification XML écrite par IBM et qui a
pour objet la gestion, l'agrégation et syndication des interfaces utilisateurs des applications et des services Web
pour l'utilisateur final. L’approche WSXL d’IBM
s’inscrit dans le prolongement de modèles orientés objets des interfaces graphiques et s’est inspirée du modèle
de référence MVC (Model View Controller), dans lequel
les données (modèle), leurs vues et les commandes
utilisateurs (Controller) sont séparées [17]. Une
application WSXL est constituée d'un ou plusieurs
composants de données, d'un ou plusieurs composants
de présentation et d'un composant de contrôle (du
dialogue homme-machine) qui lie les composants de
données et présentation en spécifiant leur comportement
collectif en réponse aux commandes de l’utilisateur.
WSXL propose donc quatre classes de composants qui
sont : (1) Composants de base, dont tous les autres
composants héritent, (2) les composants de données, (3)
les composants de présentation, (4) les composants de
Transformation de scénarios de supervision en services web et en Workflow de tâches opérateurs. Il
s'agit de définir les composants du système de supervision pouvant être accédés à l’aide de services Web par
un utilisateur. Cet accès peut être solicité soit par une
application à travers un service web automatisé, soit par
un poste opérateur (humain) demandant une fonction (tâche) à travers un serveur de services. Ce dernier gère la
requête en appelant le service stocké dans un référentiel
(annuaire), se charge de son exécution puis renvoie la ré-
2
Sur le site de l’Action Spéciale (AS) 160 « Plasticité des interfaces »
on trouve actuellement la définition suivante : « Cette AS traite de la
plasticité des systèmes interactifs, c’est-à-dire de leur capacité à
s’adapter à la diversité des plates-formes d’interaction (PC, assistant
personnel, téléphone mobile) et à l’environnement physique dans lequel s’inscrit l’interaction (chez soi, en voiture, en train, etc.).
L’adaptation logicielle à la diversité des contextes d’interaction doit se
faire à moindre coût pour le développeur tout en préservant
l’utilisabilité du système » (Cf. http://insitu.lri.fr/RTP/a_as.htm)
3 Portlet : module intégré à un portail d'entreprise, qui permet à l'utilisateur de disposer, dans la même fenêtre, d'un accès centralisé et convivial à différentes ressources (données, applications, sites Web, etc.), de
modifier l'interface du portail selon ses besoins et de personnaliser ainsi
son environnement de travail (source :
http://www.journaldunet.com/encyclopedie/definition/398/51/20/portle
t.shtml).
114
la réponse à l’utilisateur initial sous le format désiré
comme illustré par la figure 2.
nance à distance : on suppose que ce service peut permettre à un opérateur d’astreinte d'accéder depuis n'importe quel dispositif d'accès (PC, PDA, Pocket PC, Téléphone cellulaire) de partout, pour superviser, diagnostiquer à l'aide des fonctions de diagnostic intégrées et, au
besoin, commander via Intranet/Internet les machines et
équipements concernés.
Utilisateur
L’opérateur d’astreinte est contacté par le superviseur en
chef selon le principe visible en figure 3. L’opérateur
d'astreinte reçoit un message sur son téléphone portable
de la part du superviseur en chef (le moyen de communication choisi par cet opérateur pour être joint) ; il
consulte et prend connaissance du message qui lui demande d'intervenir pour dénouer une situation délicate
de supervision, accepte et confirme la mission. A partir
de son téléphone portable, il décide d'accéder au système
de supervision de son entreprise à travers son IHM
(agrégation et intégration de services), via des portlets
implémentant les différents outils et tâches que peut accomplir un opérateur de supervision (Cf. figure 2).
…
Requêtes/
réponses
HTTP
Serveur Web
Requêtes/
réponses
SOAP
Puis il s'authentifie. Le système affiche un certain nombre de services sous forme de portlet. L’opérateur choisit
le service de maintenance à distance. Il intervient à distance et dénoue la situation pour laquelle il rend compte
à son superviseur en chef en lui envoyant différentes
vues d’affichage du process en question sur différents
dispositifs de sortie avec un courrier électronique adressé au responsable de la maintenance pour traitement ultérieur.
Services Web
Figure 2. Accès opérateur via un serveur de services web
Le scénario d’une tâche de supervision correspond donc
à l’invocation d’un ou plusieurs services Web donnant
naissance à un ou plusieurs Workflow définissant un
service composé [28] et implémenté suivant une chorégraphie de services Web [1].
Services
Web
Profils opérateurs
Les différentes catégories ou classes de services Web
que peuvent composer le modèle de supervision sont à
titre d’exemple, les services web de Production, Méthodes, Qualité, Maintenance, Approvisionnement, Logistique, Formation, Direction générale, etc. Ce sont des services web orientés non seulement vers les opérateurs de
la salle de contrôle, mais aussi vers de nombreux autres
membres de l’organisation que ces services web peuvent
permettre de faire interagir.
Appli.
Web
Opérateur
Services Web
Maintenance
Services Web
Logistique
Services Web
Approvisionnement
…
Scénario de supervision. Il s'agit pour les personnels
de l'entreprise de pouvoir interagir avec l'interface utilisateur du portail de l'entreprise pour accomplir différentes tâches qui leur sont assignées suivant leur profil, collaborer avec leurs collègues et ceci à travers les différents services Web des activités verticales de l’entreprise
implémentés par exemple sous forme de portlets à l’aide
de WSRP. L’interface utilisateur peut être déployée sur
différents dispositifs de sortie ou même une partie des
renseignements requis peut être passée à un autre service
Web pour un traitement spécifique comme illustré à travers l’exemple suivant de service de support et mainte-
Services web
dédiées aux activités verticales de l'entreprise
Figure 3. Application web vue en tant qu’agrégation
de services web (inspiré de [4])
DISCUSSION : VERS DE NOUVELLES PROBLEMATIQUES ET PISTES DE RCHERCHE POUR LES ERGONOMES
De nombreuses questions de recherche vis-à-vis de
l’incidence de cette nouvelle approche de supervision se
posent potentiellement aux ergonomes. Il est possible
115
d’en recenser sans souci d’exhaustivité, mais surtout de
représentativité.
exemple, un rondier réalisant une action sur le processus
industriel à la demande des opérateurs de la salle de
contrôle, tout en s’appuyant sur des informations sur certaines machines, disponibles par l’intermédiaire d’un
PDA ou un pocket PC) soient les plus ergonomiques
possibles. Il faut à ce sujet préciser que peu de recherches ont été menées relativement à la plasticité des IHM
dans un contexte de supervision. C’est un domaine à défricher.
D’abord, il s’agit d’analyser et de comprendre les incidences, intérêts et limites de passer à une supervision
classique où les opérateurs sont en salle de contrôle, à
une supervision où des acteurs hors salle de contrôle ont
la possibilité d’utiliser à distance des fonctionnalités de
supervision. Il est important de bien analyser les responsabilités et tâches possibles qu’il est possible d’attribuer
à ces acteurs, qu’ils soient acteurs directs de la supervision ou non.
Les concepts de formation sur le lieu de travail (ou en
dehors de celui-ci) peuvent éventuellement faire l’objet
aussi d’évolutions tirant profit des concepts de service
web. Il est dans ce cas important de réorganiser le travail
de manière à ce que des séquences d’auto-formation ou
entraînement puissent y être intégrées de manière utile et
harmonieuse (portant par exemple sur des procédures
d’intervention dans des situations inhabituelles), sans
nuire à la qualité du travail en cours, par exemple lors de
phases d’attente ou de déplacement.
Par exemple, si des fonctionnalités de e-maintenance
(maintenance à distance) sont utilisées sur des machines
ou composants d’installations industrielles, il est important de faire en sorte que les opérateurs en salle de
contrôle soient prévenus automatiquement, de manière à
ce qu’ils intègrent ces interventions se voulant les
plus transparentes possibles, dans leur processus de raisonnement.
CONCLUSION
Dans cet article, nous avons mis en avant une nouvelle
approche de conception d’IHM de supervision à travers
la notion de services Web et les technologies sousjacentes orientées interfaces utilisateurs et pouvant répondre aux nouvelles exigences et contraintes mises en
évidence en introduction.
Il est important aussi de souligner qu’à partir du moment
où des utilisateurs sont nomades et qu’il est important de
procéder à des évaluations en terme d’utilité et
d’utilisabilité de dispositifs interactifs d’aide aux activités, on se situe dans un challenge difficile et encore peu
traité aussi bien au niveau national qu’international, relatif à la nécessité de méthodes d’évaluation adaptées.
Voir [14] pour une présentation de plusieurs méthodes
utiles à ce sujet.
Le modèle orienté services de l’IHM de supervision peut
mettre en avant l’agrégation et la syndication de sources
d'information indépendantes au niveau de la couche présentation sous le contrôle de l'utilisateur à travers de
nouveaux standards d’échange et de présentation de
données, oeuvrant à donner une représentation transparente (le plus souvent en se basant sur XML), de la présentation des Web Services et des interactions avec leurs
utilisateurs rendant ainsi en principe facile voire automatique leur adaptation aux différents modes d’accès.
De manière générale, il serait important d’analyser les
nouvelles articulations à trouver concernant les différentes activités de l’entreprise, au travers de ces services à
distance. Certaines d’entre elles n’ont peut-être jamais
été envisagées ou approfondies. Par exemple, dans des
cas de figure particuliers, les chargés de clientèle peuvent avoir intérêt à consulter avant, voire même pendant
les interactions chez les clients, des informations relatives à la production en cours ou aux prévisions en terme
de production.
Aussi, la modélisation des activités d’un opérateur
comme service web est un choix de conception qui peut
être considéré lors du processus de conception de l'IHM.
La supervision utilisant les technologies du Web et d'Internet ouvre beaucoup de perspectives en termes de communication et de partage d'informations au sein d’une
entreprise et au plus près des équipements permettent
ainsi un transfert vertical d’informations de l’installation
(terrain) qui représente le niveau le plus bas de la
hiérarchie vers le niveau le plus supérieur qu’est celui du
management.
Il serait intéressant d’analyser l’apport de ces nouvelles
technologies dans un contexte de changement (relève) de
poste/d’équipe, phase critique du travail en équipes successives (cf. par exemple [9]). Par exemple, serait-il possible et/ou utile de se préparer à un changement en anticipant sur la consultation d’un ensemble de variables,
par exemple significatives de l’état de fonctionnement
du procédé, à l’aide par exemple de son téléphone portable ou d’un PDA ?
Ces nouvelles technologies très attrayantes pour les ingénieurs sont d’ores et déjà disponibles et même de plus
en plus utilisées. Encore faut-il maintenant qu’elles
soient connues par les ergonomes, que leurs avantages et
inconvénients soient bien cernés, et que de nouvelles
Un domaine de recherche très actif est la plasticité des
interfaces homme-machine [3,25], concept très intéressant dans une optique de services web. Il est très important que les interfaces homme-machine utilisées par des
utilisateurs nomades en lien avec la supervision (par
116
13. Kadima, H., Monfort V. Les services Web : techniques, démarches et outils, XML, WSDL, SOAP,
UDDI, Rosetta, UML. Edition Dunod, 2003.
méthodes de conception et d’évaluation adaptées apparaissent.
REMERCIEMENTS
14. Kjeldskov, J., Stage, J. New techniques for usability
evaluation of mobile systems. International Journal
of Human-Computer Studies, 60, pp. 599-620,
2004.
Les auteurs remercient la Région Nord-Pas de Calais et
le FEDER (projets TAC MIAOU et EUCUE, TAT
SART) qui ont contribué à financer certaines parties de
ces recherches.
15. Kolski, C. Interfaces homme-machine, application
aux systèmes industriels complexes. Hermes, Paris,
1997.
BIBLIOGRAPHIE
1.
2.
3.
Arkin, A. et al. Web Service Choreography Interface (WSCI) 1.0, W3C Note 8, August 2002. Accessible à : http://www.w3.org/TR/wsci/
16. Lejon, J.C. L'évolution de la conduite sur SNCC.
L'ergonomie des systèmes numériques decontrôle
commande. Paris, Editions ANACT, 1991.
Bazydlo, P., Bernadac, J.C., Karaoui, M., Landeau ,
S., Le Roux, B., Rouxel, C., Vila, J.L., Wagener, G.
Les services Web, un nouvel atout pour l'entreprise
étendue; les technologies mise en œuvre. Publication Cosmosbay~Vectis, Janvier 2003. Accessible
à : http://cosmobay.com
17. Model-View-Controller (MVC).
http://ootips.org/mvc-pattern.html
Chauvet, J.M. Services Web avec SOAP, WSDL,
UDDI, ebXML. Edition Eyrolles, 2002.
5.
De Gamma Enabling service-oriented Architecture,
mai 2003. Accessible à : http://www.2gamma.com
à:
18. Moray, N. Human factors in process control. In
Handbook of human factors and ergonomics, G.
Salvendy (Ed.), John Wiley & Sons, INC., pp.19441971, 1997.
Calvary, G., Coutaz, J., Thévenin, D. Supporting
context changes for plastic user interfaces: a process
and a mechanism. In A. Blanford, J. Vanderdonckt
et P. Gray (réd.), Proc. of HCI-IHM 2001, SpringerVerlag, Londres, pp. 349-363, 2001.
4.
Accessible
19. OASIS (Organization for the Advancement of
Structured Information Standards), accessible à :
http://www.oasis-open.org
20. OASIS Web Services for Remote Portlets (WSRP)
http://www.oasisTC.
Accessible
à:
open.org/committees/wsrp/
6.
www.Epicentric.com
21. OASIS Web Services Interactive Applications TC.
Accessible
à
:
http://www.oasisopen.org/committees/wsia/
7.
Extensible Markup Language (XML) 1.1. W3C
Recommendation 04 February 2004, edited in place
15 April 2004, http://www.w3c.org/TR/2004/RECxml11-20040204/
22. Rasmussen, J. Information processing and humanmachine interaction, an approach to cognitive engineering. Elsevier Science Publishing, 1986.
8.
Gomes, T. Les terminaux mobiles vont-ils révolutionner les interfaces homme-machine ? Mesures,
758, pp. 44-47, 2003.
23. Sheridan, T.B. Task allocation and supervisory control. In Handbook of human-computer Interaction,
M. Helander (Ed.), Elsevier Science Publishers
B.V., North Holland, 1988.
9.
Grusenmeyer, C. La relève de poste, une phase critique du travail en équipes successives. Note bibliographique 80, INRS, septembre 1990.
24. Simple Object Access Protocol (SOAP). W3C,
http://www.w3.org/TR/soap/
10. Hoc, J.M. Supervision et contrôle de processus, la
cognition en situation dynamique. Grenoble, Presses
Universitaires de Grenoble, Grenoble, 1996.
25. Thévenin, D., Coutaz, J., 1999. Plasticity of user interfaces: framework and research agenda. Proceedings of Interact’99 seventh IFIP Conference on
Human-Computer Interaction, Edinburgh, Scotland.
11. Hung, M.H., Chen, K.Y., Ho, R.W., Cheng, F.T.
Development of an e-diagnostics/maintenance
framework for semiconductor factories with security
considerations. Advanced Engineering Informatics,
17, pp. 165-178, 2003.
26. UDDI, OASIS. Accessible à : http://www.uddi.org/
27. UIML. Accessible à : http://www.uiml.org/
28. Van der Aalast, W., Van Hee, K. Workflow management: Methods, Models and Systems. MIT Press
2002.
12. IBM, Web Service Experience Language, 01 Oct
2001, Updated 10 Apr 2002. Accessible à :
http://www128.ibm.com/developerworks/library/specification/
ws-wsxl/
117
29. Warnier, E., Ylimiemi, L., Joensuu, P. Web based
monitoring and control of industrial processes. Report A, No 22, University of Oulu, Control Engineering Laboratory, September, 2003.
33. Yang, S.H., Chen, X., Alty, J.L. Design issues and
implementation of internet-based process control
systems. Control Engineering practice, 11, pp. 709720, 2003.
30. Web Services Activity. W3C. Accessible à :
http://www.w3.org/2002/ws/
34. You, S., Wang, T., Eagleson, R., Meng, C., Zhang,
Q. A low-cost internet-based telerobotics system for
access to remote laboratories. Artificial Intelligence
in Engineering, 15, pp. 265-279, 2003.
31. Web Services Description Language (WSDL) 1.1.
W3C Note 15 March 2001. Accesible à :
http://www.w3.org/TR/wsdl
32. Web Services User Interface (WSUI). Accessible à :
http://www.service-architecture.com/webservices/articles/web_services_user_interface_wsui.html
118
Les déterminants du choix d’une modalité d’interaction
avec une interface multimodale
Laurent Karsenty
INTUILAB, Prologue 1, La Pyrénéenne, 31672 Labège
[email protected]
RESUME
collaboratifs et les applications de réalité virtuelle
(Thalman, 2002), pour ne citer que quelques exemples.
Si les premiers travaux significatifs sur la multimodalité
ne datent pas d’aujourd’hui, force est de reconnaître que
la conception d’interfaces multimodales soulève encore
de nombreuses questions. Pour une part, ces questions
sont liées à la méconnaissance des déterminants du choix
de chaque modalité d’interaction ou combinaison de
modalités par l’utilisateur. Pourtant, en analysant les
travaux empiriques à notre disposition et en recoupant
plusieurs résultats disparates, on s’aperçoit qu’une
certaine connaissance est déjà disponible laquelle, si elle
est encore insuffisante pour établir une théorie complète
et précisément guider les choix de conception, peut
néanmoins faciliter certaines décisions des concepteurs.
C’est l’objectif de cet article que de rapporter les
résultats d’une telle analyse sous forme d’une synthèse
des principales observations recueillies sur l’usage
d’interfaces multimodales. Cette synthèse permettra de
tirer une série d’enseignements et de pistes de réflexion.
Pour respecter les limites imposées à cet article, nous
nous focaliserons dans la suite sur la multimodalité en
entrée. L’usage des modalités vocale et gestuelle sera
plus particulièrement traité car elles sont au cœur de
nombreuses applications envisagées aujourd’hui. Par
gestes, nous entendrons à la fois les gestes 2D ou 3D
mais aussi les gestes de manipulation d’une souris, d’un
stylet ou de tout autre dispositif de commande.
Les
applications
industrielles
des
interfaces
multimodales touchent de plus en plus de domaines.
Pourtant, leur conception soulève encore de nombreuses
questions, en partie liées à notre méconnaissance des
déterminants du choix d’une modalité d’interaction par
l’utilisateur. Cet article rapporte une série d’observations
tirées d’expérimentations d’interfaces multimodales qui
comblent en partie ce manque. L’effet de certains
déterminants est spécifiquement discuté, comme la
nature de la tâche et l’évaluation subjective et
contextualisée de la performance réalisée par l’utilisateur
alors qu’il utilise le système.
MOTS CLES : multimodalité, commande vocale, geste
ABSTRACT
Multimodal interfaces get wider recognition in industry
and more and more applications are considered today.
However, their design still raises many questions, partly
related to our lack of knowledge regarding the
determinants of the choice of an interaction modality by
users. This article reports a series of observations on the
use of multimodal interfaces which partly fill this lack.
The effect of some determinants is specifically
discussed, such as the nature of the task and the
subjective and contextualized evaluation of the
performance carried out by users as they are using the
system.
QUELQUES DEFINITIONS
KEYWORDS : multimodality, spoken command, gesture
Système multimodal
Nous considérerons comme système multimodal tout
permettant d’utiliser plusieurs canaux de communication
en entrée et/ou en sortie (Nigay et Coutaz, 1996, Martin,
Julia et Cheyer, 1998). Nous retiendrons en outre que les
systèmes multimodaux offrent une autre source de
flexibilité aux utilisateurs : elle concerne le format des
informations transmises ou, ce que Bernsen (2002) a
proposé d’appeler la modalité représentationnelle. Pour
chaque canal, il existe en effet plusieurs façons de
« conditionner » l’information à transmettre. Par
exemple, en s’adressant à un serveur vocal, l’utilisateur
peut formater son message en une suite de mots-clés, de
morceaux de phrase simplifiée ou en une expression
totalement naturelle. Nous verrons que du point de vue
INTRODUCTION
Les développements récents de l’informatique et des
infrastructures
de
télécommunication
ouvrent
aujourd’hui la porte à une interaction plus riche entre
l’homme et la machine. En particulier, il devient
possible d’avoir recours à une interaction multimodale,
dépassant le paradigme clavier-souris-écran pour
exploiter plusieurs modalités d’interaction, que ce soit
sur un poste fixe ou un terminal mobile. Ces
perspectives concernent des applications aussi variées
que les bornes publiques d’information (ex., Lamel et
al., 2002), les services mobiles de recherche
d’information (Karsenty et al., 2005), les systèmes
embarqués (ex., Kamp, 1998), les environnements
119
de l’utilisateur, ces deux dimensions, canal de
communication et modalité représentationnelle, ne sont
pas indépendantes.
ou si celui-ci ne trouverait pas plus facile et/ou plus
efficace de les enchaîner séquentiellement. On peut aussi
se demander s’il préférerait tirer parti des spécificités de
chaque modalité et les combiner de façon
complémentaire ou, au contraire, chercher à réaliser un
acte complet avec seulement une modalité, quitte à être
parfois moins efficace. Il est aussi nécessaire de savoir si
l’utilisateur
adopterait
plusieurs
modalités
indifféremment pour transmettre une même information
ou si, au contraire, il ne préférerait pas toujours la même
modalité pour une fonctionnalité ou une commande
donnée, auquel cas il serait inutile de fournir plusieurs
modalités. Enfin, il convient de déterminer s’il n’existe
pas plusieurs profils d’utilisateurs face à ces nouvelles
interfaces et ce qui les caractériserait.
Modes de coordination entre modalités
La transmission d’une information peut s’appuyer sur
une modalité unique ou sur une combinaison de
modalités. Ainsi, pour indiquer une destination
souhaitée, on peut dire « Je voudrais aller au 5 rue du
Pont » ou désigner le lieu souhaité tout en disant « Je
voudrais aller ici. » Avec des systèmes où une
combinaison de modalités en entrée est possible,
l’utilisateur doit connaître les modes de coordination
entre modalités autorisés (Coutaz & Nigay, 1994).
L’usage de plusieurs modalités peut être séquentiel ou
parallèle. Certains systèmes n’autorisent que des
combinaisons séquentielles de modalités, sans
recouvrement dans le temps. C’est le cas notamment du
prototype MiPad (Huang et al., 2001) où l’utilisateur,
pour remplir un champ d’information, doit d’abord
cliquer dessus puis parler. D’autres systèmes autorisent
des recouvrements de modalités, en faisant intervenir un
mécanisme explicite ou implicite de fusion multimodale
combinant le sens extrait de chaque modalité. Par
exemple, avec le système Intuikit développé par
Intuilab1, l’utilisateur peut saisir un objet représentant
une valeur boursière avec sa main sur un écran tactile et
dire en même temps « Je voudrais en acheter pour 200
euros », par exemple.
Quel que soit le mode disponible ou choisi, les modalités
peuvent être utilisées de façon complémentaire,
redondante ou même concurrente. Deux modalités sont
complémentaires si les informations que chacune
véhicule constituent une partie du sens global
communiqué. Deux modalités utilisées de façon
séquentielle ou parallèle sont redondantes si les
informations que chacune véhicule sont identiques. Par
exemple, un utilisateur peut dire : « Je veux aller à
Toulouse » tout en montrant la ville de Toulouse sur une
carte. Enfin, deux modalités peuvent être utilisées de
façon concurrente, au sens de contradictoire ou
conflictuelle. Par exemple, un utilisateur pourrait lancer
la commande vocale « tourne à droite » en désignant
gestuellement la gauche.
Enfin, deux modalités sont équivalentes si l’utilisateur
ou le système les utilise indifféremment pour transmettre
la même information. Dans le cas inverse, on peut parler
de l’assignation d’un type d’information à une modalité
donnée.
Toutes ces distinctions sont fondamentales pour l’étude
des usages de la multimodalité. Si un système offre
plusieurs modalités d’entrée, on peut en effet se
demander s’il y a intérêt à fournir des mécanismes de
fusion multimodale supposant que l’utilisateur agisse en
combinant deux modalités (à peu près) en même temps
USAGES OBSERVES LORS D’EXPERIMENTATIONS
Une synthèse des résultats de plusieurs expérimentations
est présentée ici. Soulignons que beaucoup de ces
travaux de recherche portent sur des environnements
simulant en partie les capacités du système. Pour cette
raison, une attitude prudente dans l’interprétation des
résultats reste nécessaire.
Commandes multimodales vs. monomodales
Plusieurs travaux comparent le taux de commandes
multimodales au taux de commandes monomodales pour
vérifier l’intérêt des premières. Généralement, le terme
de commande multimodale y désigne une utilisation
complémentaire et parallèle des modalités. De façon
générale, on constate la prédominance de commandes
uniquement vocales : ainsi, dans des tâches exploitant le
plan d’une ville, Oviatt et al. (1997) enregistre 63,5% de
commandes effectuées oralement, contre 17,5%
effectuées par l’écriture et 19% par des commandes
multimodales associant parole et stylet. Dans une tâche
de manipulation de fichiers, la même prédominance a été
observée (Huls & Bos, 1998) : environ 58% des
commandes étaient réalisées à la voix uniquement, alors
que seulement 11% environ étaient réalisées de façon
multimodale.
Toutefois, ces résultats varient en fonction des tâches
réalisées par les utilisateurs. Ainsi, dans une tâche
d’aménagement d’un salon, impliquant la manipulation
et l’organisation d’objets dans l’espace (canapé, table,
chaises, etc.), Mignot et Carbonel (1996) ont enregistré
43% de commandes vocales, contre 41% de commandes
multimodales (geste+voix) et 16% de commandes
uniquement gestuelles. Oviatt et al. (1997) ont constaté
de leur côté que les commandes multimodales étaient
produites plus fréquemment pour des tâches spatiales de
localisation (ajouter, déplacer, modifier ou calculer la
distance entre les objets). Enfin, Catinis et Caelen (1995)
enregistrent, sur une tâche de dessin, 66% de
commandes multimodales. Cela dit, dans ce dernier cas,
l’utilisation de la commande vocale était très contrainte :
une seule structure syntaxique et un vocabulaire de
quelques dizaines de mots seulement étaient autorisés.
1
On pourra consulter une démo de cette application à :
http://www.intuilab.com/presentation/202-demos.html
120
Cette spécificité, qui a pu favoriser le recours à la
multimodalité, révèle que l’adoption d’une modalité au
sens de canal de communication peut dépendre à la fois
de la tâche mais aussi du format d’information autorisé.
De plus, certaines conditions externes favoriseraient le
recours à l’une ou l’autre des modalités. Huls et Bos
(1998) ont notamment révélé l’effet de deux facteurs sur
ce choix dans une tâche de manipulation de fichiers
informatiques (des résultats similaires sont présentés
dans Oviatt et al., 1997) :
x La longueur des mots (noms de fichier) : les mots
courts – 3 à 4 caractères dans cette étude –
favorisaient le recours à la modalité vocale (76%
des commandes) alors que les mots longs – plus de
8 caractères dans cette même étude – conduisaient à
un ré-équilibrage dans le choix des commandes avec
39% de commandes de type manipulation directe
(avec la souris), 18% de commandes multimodales
(parole + désignation avec la souris) et 43% de
commandes vocales.
x L’accessibilité
visuelle
des
objets :
dans
l’expérimentation de Huls et Bos, les fichiers à
manipuler pouvaient être visibles à l’écran ou non.
Lorsqu’ils n’étaient pas visibles, les utilisateurs
avaient préférentiellement recours à la modalité
vocale seule pour y faire référence (72% des cas).
Par contre, lorsqu’ils étaient visibles, la modalité
vocale seule ne représentait plus que 44% des cas.
Bien évidemment, la combinaison de ces deux facteurs a
produit des résultats encore plus marqués puisque, dans
le cas de noms courts et non visibles, 86% des
commandes utilisaient la parole seule, alors qu’avec des
noms longs visibles, la commande vocale ne représentait
plus que 28% des cas.
D’autres conditions favoriseraient l’adoption d’une
modalité en particulier au détriment des autres. C’est le
cas notamment de la modalité de sortie utilisée par le
système. Ainsi, on a observé qu’un prompt vocal
favorisait le choix de la modalité vocale en entrée alors
que plusieurs modalités étaient disponibles (Lamel et al.,
2002). On peut supposer qu’une forme de pré-activation
intra-modale est possible entre la modalité utilisée en
entrée et celle utilisée en sortie.
x
x
Modifications du langage dans un environnement
multimodal
x
Plusieurs auteurs ont montré que l’utilisation de
plusieurs modalités modifiait le comportement langagier.
Les modifications suivantes ont notamment été relevées :
x Simplification du langage : les expressions
produites dans un environnement multimodal sont
plus brèves et moins complexes que les énoncés
unimodaux (Oviatt et al., 1997, Petrelli et al., 1997).
Par exemple, si avec la modalité vocale seule,
l’utilisateur dit (Oviatt et al., 1997) : « Je voudrais
voir la photo de la maison à l’extrémité sud-ouest de
Reward Lake», dans un environnement multimodal,
il encerclerait la maison avec son stylet tout en
121
disant : "Montre la photo". Les études citées ne
disent pas, par contre, si une telle simplification est
observée chez tous les utilisateurs. Par contre, ils
mentionnent qu’elle implique une amélioration des
taux de reconnaissance correcte des commandes
vocales.
Antériorité du composant de localisation avec le
geste : dans les énoncés vocaux, le constituant de
localisation est rarement au début (seulement dans
1% des énoncés) ; par contre, les expressions
multimodales débutent invariablement avec un geste
graphique délivrant l’information de localisation
suivi d’un énoncé verbal (Oviatt et al., 1997) . Par
exemple, l’utilisateur dessine un cercle et dit :
« Ajoute une piscine », alors qu’avec la voix seule,
il dirait plus probablement: « Ajoute une piscine +
[énoncé de localisation] »). Il faut souligner que
l’antériorité du geste sur la parole a été observée
systématiquement dans les études sur la
communication humaine (cf. Butterworth & Hadar,
1989) et devrait reposer sur des dispositions
naturelles mises en œuvre en planifiant un acte
multimodal.
Apparition de nouvelles formes de référence.
Plusieurs études font mention notamment des
formes suivantes (Siroux et al.,1995, Petrelli et al.,
1997) :
o des références déictiques combinées à un geste
désignant une localisation (ex. « Y a-t-il des
campings ici ? ») ;
o l’utilisation redondante de références définies
vocales avec un geste déictique (ex. « Donne
moi la distance entre Lansing et Morestel » avec
une désignation tactile sur chacune des deux
villes) ;
o des références mixtes, avec une désignation
tactile complétant une requête verbale sans
référence à un lieu (ex. « Quels sont les
campings » + une désignation sur une
localisation). Toutefois, il convient de noter que
ce dernier type de combinaison est soit observé
rarement, soit observé avec des utilisateurs
expérimentés. Il ne semble donc pas « naturel »
mais pourrait apparaître intéressant avec
l’expérience.
Conception des expressions référentielles en
fonction
des
caractéristiques
perceptives :
l’exploitation d’un support visuel peut aussi
modifier le langage et, en particulier, les expressions
référentielles (Gaiffe & Romary, 1997). Ainsi,
l’absence de structuration spatiale et/ou de
caractéristiques perceptives contrastant des objets
représentés induit des expressions complexes et
variables d’un utilisateur à l’autre. Par exemple,
pour désigner un point non identifié sur la carte
d’une ville, l’utilisateur peut dire : « … entre le Pont
Charlemagne et l’avenue Gabriel Péri ». Par contre,
Effets de l’expérience
si la carte est quadrillée, l’utilisateur pourra
employer une expression plus simple telle que
«… en A 8». Toutefois, notons que cette analyse ne
prévoit pas la difficulté potentielle de l’utilisateur
pour savoir quelle(s) caractéristique(s) perceptive(s)
il peut exploiter vocalement pour faire référence à
un objet présenté visuellement.
Toutes ces observations confirment l’idée que la
multimodalité a un réel potentiel pour améliorer la
performance des utilisateurs et qu’une partie de ce gain
au moins peut être acquis naturellement en vertu du fait
que l‘action humaine – langagière, manuelle ou autre est fortement contextualisée
Un fait à mettre en parallèle avec cette apparente
recherche d’efficacité est l’accroissement du taux de
commandes multimodales avec l’expérience. Par
exemple, Petrelli et al. (1997) notent que des utilisateurs
expérimentés réalisent 84% de leurs commandes de
façon multimodale alors qu’ils ne sont que 30% parmi
les novices. Des résultats moins impressionnants mais
démontrant la même tendance ont été enregistrés par
Mignot & Carbonell (1996). Toutefois, cette évolution
ne concernait alors qu’une moitié des utilisateurs.
Globalement, ces observations suggèrent que la
réalisation de commandes multimodales apparaît soit peu
intuitive à l’utilisateur novice, soit difficile à exécuter ne
serait-ce que parce qu’elle demande à combiner deux
modalités. Ce n’est qu’avec l’expérience, et donc une
certaine maîtrise des commandes à modalité unique, que
certains d’entre eux se lanceraient à expérimenter les
commandes multimodales. Ils auraient alors la
possibilité de constater les gains d’efficacité que leur
apporte cette nouvelle forme d‘interaction.
Usage complémentaire des modalités
La complémentarité a été observée dans plusieurs
études. Cette complémentarité concerne le plus souvent
la combinaison entre une expression déictique (ici, là,
ce, …) et un geste déictique et sert ainsi à faciliter la
localisation. Mais elle peut aussi servir d’autres
fonctions. Elle permet notamment de combiner un geste
anaphorique ou un geste de manipulation avec de la
parole.
Ainsi, avec le système QuickSet (Cohen et al., 1997),
l’utilisateur peut contrôler un environnement multimodal
de simulation et lancer des commandes du type : « Jeep
23, suivez cette route d’évacuation » avec un geste
(stylet) montrant la direction à suivre. Le geste peut ici
simplement consister à indiquer par une flèche la
direction à suivre : il possède pour cette raison des
vertus anaphoriques. Avec le même système, l’utilisateur
peut dessiner un carré tout en disant « Crée une unité
médicale ici », la parole donnant alors sens au geste de
manipulation de l’outil dessin. Avec un utilisateur
entraîné à ces styles d’interaction, le temps de création
d’entités a été divisé par 9 par rapport à l’utilisation
d’une interface graphique standard (Cohen et al., 1998).
Trois types de complémentarité se dessinent donc :
x geste déictique + voix ;
x geste anaphorique + voix ;
x geste de manipulation + voix.
Beaucoup de travaux insistent sur le premier type de
complémentarité. Pourtant, il se pourrait bien qu’il n’ait
qu’un intérêt relatif dans le cadre de l’interaction
homme-machine. Une étude sur l’utilisation d’une carte
de ville multimodale dans laquelle les utilisateurs
pouvaient créer, déplacer, supprimer des objets ou
calculer des distances entre des points (Oviatt et al.,
1997), a montré que les expressions multimodales du
type geste déictique + voix représentaient 14% de
l’ensemble des expressions multimodales, les 86%
restant étant constitué d’expressions du type geste de
manipulation + voix. Ces résultats semblent indiquer que
les utilisateurs exploitent avantageusement la
multimodalité pour des actions complexes, là où le gain
en efficacité devrait être le plus marqué.
Usage parallèle ou séquentiel de modalités
Théoriquement, les modalités utilisées de façon
complémentaire peuvent être mises en œuvre
parallèlement ou séquentiellement. Une question
importante est de savoir si, spontanément, l’utilisateur
aurait le plus souvent recours à un usage parallèle ou
séquentiel des modalités. Cette question a souvent été
traitée en analysant l’utilisation conjointe d’un geste
déictique avec une référence déictique. En fait, les
résultats obtenus à ce jour sont contradictoires :
x Une étude empirique de la temporalité des modalités
(Oviatt et al., 1997) a montré que l’usage parallèle
des modalités ne constituait pas la majorité des cas.
Le parallélisme entre une expression déictique et un
geste déictique (« mets ce triangle ici ») ne
concernait alors que 25% de ce type de commande.
Le plus souvent, le geste précédait la parole, avec un
intervalle de temps moyen de 1 seconde, et un
espace de variation allant de 0 à 4 secondes
maximum.
x D’un autre côté, dans l’expérimentation de
Hauptmann & McAvinney (1993) sur des
manipulations multimodales de cubes, les gestes
étaient réalisés pendant ou après le début de la voix
dans 50% des cas. Ils ne commençaient avant la
commande vocale que dans 8-9% des cas. Le même
type de résultat a été enregistré par Catinis (1998)
dans une tâche de dessin.
A côté de cela, il est intéressant de constater que des
mesures très proches de celles fournies par Oviatt et al.
ont été obtenues à partir d’études de la multimodalité
geste + parole dans la communication homme-homme
(cf. Butterworth & Hadar, 1989). On pourrait donc
penser que la précédence du geste sur la parole a un
caractère naturel ou spontané intéressant à reproduire en
interaction homme-machine. Mais il est aussi possible
122
que suivant le dispositif offert aux utilisateurs (type de
microphone, type de dispositif de désignation : main ou
stylet, type de geste autorisé : 2D ou 3D, etc.) et suivant
les tâches étudiées, cette règle ne s’applique pas de façon
identique.
aller ici », tout en pointant sur la « Rue Minguy » et le
système comprendrait « Je voudrais aller Rue du
Séjour » par le canal vocal et « Rue Minguy » par le
canal gestuel. La conception des systèmes multimodaux
devra permettre à l’utilisateur de détecter ces états
d’incohérence et les corriger facilement.
Usage redondant des modalités
De manière générale, peu de redondance dans les
expressions multimodales a été observée. Toutefois, les
observations recueillies ne sont pas toutes homogènes.
Ainsi, Petrelli et al. (1997) ont constaté que la
redondance caractérisait 25% des références quand le
référent – il s’agissait de champs d’information à remplir
- avait un nom très court (une seule lettre). Par contre,
elle ne caractérisait que 10% environ des références
quand le référent – toujours un champ - comportait un
nom plus long (par ex., « Informations générales »). Les
auteurs suggèrent l’idée que la redondance serait
favorisée quand le coût de la désignation verbale est
faible.
Si l’effort est une variable à prendre en compte pour
comprendre la redondance multimodale, elle ne semble
toutefois pas être la seule. La fiabilité semble aussi jouer
un rôle dans la décision d’appliquer deux modalités
redondantes. C’est ce qui se dégage de l’analyse des
corpus de Catinis (1998) concernant une application de
dessin multimodal. Ainsi, l’auteur constate que parmi les
actions “dessiner”, “déplacer” et “effacer”, la dernière
est celle qui suscite le plus de redondance. Or, cette
action est celle qui comporte le plus de risque (aucune
demande de confirmation ne suivait l’action
d’effacement). La redondance pourrait donc être
exploitée aussi pour fiabiliser une commande.
Equivalence et assignation des modalités
L’équivalence est rarement analysée et n’a été observée
que dans peu d’études. Catinis (1998) fait toutefois état
d’un nombre assez important de commandes de dessin
(38%) qui sont exprimées par les sujets indifféremment
par la parole, avec la souris, ou par une combinaison des
deux. Par contre, l’assignation est un phénomène qui
semble plus largement répandu.
Il faut souligner que l’assignation peut concerner soit
une modalité dans son ensemble – dans ce cas,
l’utilisateur a tendance à utiliser le système toujours avec
la même modalité quel que soit le contexte de dialogue –
soit une modalité (ou combinaison de modalités) pour
une commande donnée (Calvet et al., 2001, Catinis,
1988).
L’assignation apparaît moins comme un phénomène
s’imposant dès le départ que comme un phénomène
émergent d’une succession d‘interactions. Certains
auteurs ont d’ailleurs noté que cette stabilisation des
usages apparaissait relativement vite, pour certains
utilisateurs juste après un ou deux essais (Carbonell et
al., 1996).
De manière générale, l’assignation semble résulter d’une
recherche d’efficacité de l’interaction mais, parfois, elle
ne conduit pas forcément l’utilisateur à sélectionner les
modes d’interaction les plus efficaces (Mignot et
Carbonell, 1996). La question reste toutefois posée quant
à savoir si le choix de modalités moins efficaces se fait
parce que l’utilisateur y trouve tout de même un intérêt
ou s’il se fait par manque de connaissance (voire par
oubli) de toutes les possibilités offertes par le système.
Usage concurrent de modalités
L’application de modalités concurrentes par l’utilisateur
a rarement été observée. Dans l’étude de Mignot et
Carbonell (1996), un cas est relaté. L’utilisateur
demandait au système de changer l’emplacement du
canapé et de l’armoire. Tout en formulant cette
commande, il se rendît compte qu’un piano se trouvait
sur la trajectoire des meubles et le désigna alors pour le
traîner vers le centre de la pièce. Un traitement correct
de cette séquence supposerait d’interpréter chaque acte –
verbal et gestuel – de façon autonome.
À cette forme de concurrence, on peut ajouter les erreurs
typiques d’orientation (ex., désigner la gauche en disant
à droite ou l’inverse) ainsi que les lapsus (ex. désigner
un objet tout en en nommant un autre par erreur).
Toutefois, ces cas devraient être relativement rares, ce
qui ne veut pas dire qu’il faudrait en sous-estimer
l’importance en particulier si l’erreur peut avoir des
conséquences dommageables.
En utilisation réelle, on peut toutefois anticiper qu’un
plus grand nombre de cas de concurrence apparaîtra, liés
non pas aux actes de l’utilisateur mais aux erreurs de
reconnaissance du système. Ainsi, un utilisateur pourrait
demander à un système de navigation : « Je voudrais
Différences inter-individuelles
Plusieurs études font le même constat : la phase
d’appropriation d’un système multimodal ne converge
pas vers l’adoption des mêmes modalités quel que soit
l’utilisateur (Mignot et Carbonell, 1996, Siroux et al.,
1997, Calvet et al., 2001 entre autres). Carbonell et al.
(1996) parlent de profils ou styles multimodaux
individualisés, sans expliquer ce qui conduit les uns ou
les autres à préférer telle(s) modalité(s). Calvet & al.
(2001) introduisent l’idée de préférences individuelles
qui inclineraient chaque utilisateur à adopter plutôt
telle(s) modalité(s) ou telle(s) autre(s). Ils précisent que
ces préférences semblent être liées à de nombreux
facteurs, par exemple un goût pour la nouveauté, une
aversion pour le vocal (on sait que 15 à 20% des
utilisateurs raccrochent immédiatement quand ils
s’aperçoivent qu’ils doivent parler à un serveur vocal),
ou encore une tendance prononcée pour l’exploration
(ou l’inverse). Ces analyses ne conduisent toutefois pas
123
à penser que l’utilisateur abandonnerait totalement le
recours à une modalité non préférée : dans certaines
circonstances, on constate en effet une utilisation
ponctuelle d’une modalité généralement délaissée.
certaines modalités ou combinaisons de modalités à
certaines commandes.
Dans cette discussion, nous proposons une analyse de
l’effet des deux premiers déterminants afin de mieux en
comprendre la nature.
Changement de modalité face à des erreurs du
système
Impact de la nature de la tâche
Une situation particulière peut justement provoquer un
changement de modalité : il s’agit de l’impossibilité de
résoudre rapidement une erreur en gardant la même
modalité. Par exemple, Catinis (1998) a fait les constats
suivants :
x après une première erreur, l’utilisateur a réitéré la
commande avec le même mode dans 78% des
cas dans une tâche de dessin et dans 65% des cas
dans une tâche de traitement de texte ;
x après le deuxième ou troisième échec, l’utilisateur
est passé/e à un autre mode dans 82% des cas pour
la tâche de dessin (le calcul n’est pas disponible
pour la tâche de traitement de texte).
Parallèlement, plusieurs études ont montré que
persévérer en ré-appliquant la modalité vocale après une
erreur du système conduisait généralement à dégrader les
taux de reconnaissance (ex., Karsenty & Botherel,
2005) et qu’un changement de canal de communication
ou de modalité représentationnelle était en général plus
efficace pour rétablir la compréhension (Karsenty &
Botherel, 2005, Suhm & al., 2001).
La question est de savoir si l’utilisateur novice aurait
tendance à changer par lui-même de modalité lorsqu’il
rencontre une erreur répétitive ou s’il a besoin
d’incitation pour cela. Certaines études tendraient à
montrer que, dans ces conditions, le changement de
modalité s’effectue « naturellement » (par ex., Oviatt &
VanGent, 1996), au moins chez une partie des
utilisateurs. Toutefois, d’autres études non publiées dont
nous avons eu connaissance ont révélé que les
utilisateurs pouvaient persévérer un grand nombre de
fois en répétant les mêmes commandes avant de changer
de modalité, voire sans jamais le faire. Il est possible que
ces observations contradictoires soient liées à des
variations dans les conditions d’expérimentation.
Plusieurs études invitent à penser que l’usage d’une
interface multimodale dépend de la nature de la tâche.
Mais comment l’expliquer ? En s’appuyant sur des
travaux de Psychologie Cognitive, on peut avancer que
la dépendance tâche-modalité repose en premier lieu sur
la nature de la représentation du but que construit
chaque utilisateur. Certaines tâches engagent plus
facilement à construire des représentations imagées et
spatialisées du but, comme par exemple le déplacement
ou la manipulation d’un objet ou l’identification d’un
lieu, d’une zone ou d’une distance. D’autres induisent
plutôt la formation de représentations dites
propositionnelles, comme lors d’une recherche d’un
numéro de téléphone ou une requête d’action sur un
objet donné (ex., supprimer un fichier). Or, il semble que
chacun de ces types de représentation ait un pouvoir de
pré-activation de certaines modalités d’action (cf. Krauss
et al., 2000) : les représentations imagées préactiveraient le plus souvent la modalité gestuelle tandis
que les représentations propositionnelles pré-activeraient
les modalités de production – orale ou écrite - d’un
discours. Par ailleurs, il faut noter qu’un geste ne peut
représenter que certaines catégories d’information : une
forme ou une distance, une localisation dans l’espace,
une trajectoire ou une direction. Tous les concepts ne
peuvent donc pas être traduits sous forme de geste. A
l’inverse, le discours peut théoriquement traduire tout
concept mais cette modalité est simplement parfois
beaucoup plus coûteuse - on pourrait aussi dire moins
« naturelle » - que d’autres pour transmettre certains
d’entre eux.
Une autre raison expliquant le lien tâche-modalité est
liée aux exigences à satisfaire dans l’atteinte d’un but.
Certaines tâches imposent par exemple de réaliser le but
très rapidement, ou alors avec aucune erreur, ou encore
avec un effort minimum. D’autres n’imposent pas ces
exigences. Or, chaque modalité ne satisfait pas de la
même façon chacune d’entre elles.
DISCUSSION
Les observations passées en revue dans cet article
permettent d’identifier 4 grandes classes de déterminants
du choix d’une modalité par l’utilisateur :
x la tâche ;
x une fonction d‘évaluation subjective de la
performance mise en œuvre par l’utilisateur ;
x ses préférences initiales qui le prédisposeraient à
opter au départ pour certaines modalités, ou les
délaisser, indépendamment de toute autre
considération ;
x l’expérience, qui semble pouvoir modifier en partie
les préférences initiales de l’utilisateur et concourir
à développer, d’une part, l’usage combiné de
plusieurs modalités et, d’autre part, l’assignation de
Evaluation subjective de la performance
En fait, on peut supposer que l’utilisateur évalue sa
performance avec une modalité donnée – soit avant de
l’utiliser, soit en l’utilisant - pour vérifier qu’elle lui
permettra de satisfaire ses exigences de tâche. On peut
ainsi rendre compte que l’usage de l’écriture manuscrite
sur PDA, qui cause encore un taux d’erreur non
négligeable, soit jugée comme acceptable dès lors que
l’utilisateur a pour principale contrainte de prendre des
notes rapidement. Il est intéressant de noter que les trois
exigences que nous avons mentionnées, vitesse
d’exécution, effort de mise en oeuvre et fiabilité, sont
124
interdépendantes si bien que lorsque la priorité est mise
sur l’une, le poids des autres, ou au moins de l’une des
autres, est généralement affaibli. Autrement dit, mettre la
priorité sur l’une d’elles doit conduire l’utilisateur à être
plus tolérant sur la satisfaction des autres et devrait donc
rendre plus acceptable des modalités qui ne les
satisferaient pas totalement.
L’évaluation de la performance repose en partie sur une
évaluation de l’effort de mise en œuvre avec chaque
modalité. A ce titre, on peut comprendre que certaines
caractéristiques de l’interface aient un impact sur le
choix d’une modalité : c’est le cas par exemple des
dispositifs physiques d’utilisation d’une modalité (ex., le
Push-To-Talk pour activer la reconnaissance de parole
versus l’utilisation libre de la reconnaissance de parole
au téléphone) ou du degré de précision exigée dans la
réalisation d’un geste. Autre facteur affectant
l’évaluation de performance : les caractéristiques de
l’objet de l’action. On a notamment vu que la longueur
de son nom ou son niveau d’accessibilité à l’écran
affectait directement le choix d’une modalité.
Un autre facteur devrait affecter cette évaluation : il
s’agit de la modalité sélectionnée pour l’action juste
précédente. Catinis (1998) rapporte des travaux ayant
montré qu’un changement de modalité entraîne toujours
un coût non négligeable. Si l’utilisateur évalue son effort
avant d’adopter une modalité donnée dans un contexte
donné, ce paramètre doit entrer en jeu et pourrait le
conduire à préférer maintenir la modalité active même si
elle peut apparaître moins performante lorsqu’elle est
considérée isolément. On pourrait expliquer ainsi que
certains utilisateurs persévèrent avant de changer de
modalité lorsqu’ils rencontrent des erreurs répétées.
Cette hypothèse pourrait aussi rendre compte d’une
observation inattendue extraite de l’évaluation d’une
IHM multimodale sur smartphone (décrite dans Karsenty
et al., 2005) : à de nombreuses reprises, les utilisateurs
ont confirmé vocalement une requête réalisée en vocal
en disant « OK », après avoir activé la reconnaissance de
parole en appuyant sur un bouton Push-To-Talk présenté
à l’écran, alors que ce même écran présentait un bouton
de confirmation « OK », parfaitement visible, sur lequel
un simple clic aurait suffit. Dans la très grande majorité
des cas, cette confirmation vocale suivait une autre
commande vocale.
x
x
x
CONCLUSION
On peut tirer une série d’enseignements de la synthèse
des travaux présentée ici et des éléments d’analyse qui
ont suivi :
x Pour décider de la pertinence d’une (nouvelle)
modalité dans un dispositif d’interaction, les
concepteurs devraient prendre en compte en premier
lieu la nature même de la tâche et, en particulier, la
nature des représentations de but qu’elle induit chez
les utilisateurs ainsi que les propriétés des objets sur
lesquels ceux-ci vont pouvoir agir (ex. degré
d’accessibilité, longueur de leur nom, etc.).
125
Une fois cette analyse menée, on doit considérer
qu’il n’y a toutefois pas une modalité qui est
préférable aux autres pour tous les utilisateurs,
même pour une tâche donnée. Des différences interindividuelles fortes existent, pouvant remettre en
cause le lien qui pourrait sembler naturel entre une
tâche et une modalité. Idéalement, toute tâche
devrait donc être réalisable par la modalité supposée
la plus efficace pour une tâche donnée et au moins
une modalité supplémentaire, dont le choix doit
dépendre des acquis antérieurs de la population
ciblée.
Au-delà de ces facteurs, le choix d’une modalité par
l’utilisateur semble résulter d’une évaluation
subjective de sa performance a priori et pendant
l’action. Nous avons avancé que la performance
avec une modalité donnée était évaluée par rapport à
3 critères inter-dépendants, l’effort de mise en
œuvre, la vitesse d’exécution et la fiabilité, tout en
reconnaissant
que
l’utilisateur
recherchait
probablement le meilleur compromis au vu de ses
exigences liées à la tâche. Rien n’empêche donc,
par exemple, qu’il choisisse une modalité moins
fiable mais plus rapide que les autres si sa principale
contrainte est le temps disponible. Par ailleurs, il
apparaît que cette évaluation de performance est
fortement contextualisée, dépendant tout à la fois de
l’état interne de l’utilisateur (ex., phénomène de préactivation intra-modale liée à la sortie du système ;
modalité utilisée précédemment par l’utilisateur), de
l’état du système, des propriétés de l‘environnement
ou encore des autres modalités disponibles – et donc
concurrentes - pour une même action.
Une
conséquence, parmi d’autres, de cette caractéristique
est que la conception et l’évaluation des interfaces
multimodales accompagnant le lancement de
nouveaux produits devraient s’extraire des
conditions de laboratoire – prégnantes dans les 15
dernières années - pour s’ancrer maintenant au plus
près des contextes d’usage réels amenant leur lot de
complexité… mais aussi de représentativité des
conditions d’acceptabilité.
Enfin, on pourra retenir que la mise en œuvre
parallèle de deux modalités – thème au cœur de
nombreux travaux de recherche sur la multimodalité
- est peu probable par des utilisateurs novices (au
moins, tant que cette forme d’interaction n’est pas
devenue très répandue). L’usage monomodal ou,
éventuellement, multimodal sous forme d’une
séquence de commandes semble bien plus probable.
Par contre, la multimodalité synergique peut
apparaître avantageuse avec l’expérience pour
certaines tâches et satisfaire les attentes des
utilisateurs fréquents. Dans ce cas, concernant la
coordination geste/parole, les concepteurs devraient
rechercher à créer des systèmes flexibles, acceptant
différents modes de coordination entre le geste et la
parole avec certaines limites temporelles entre les
deux pour pouvoir distinguer une commande
multimodale complémentaire d’une séquence de 2
commandes indépendantes réalisées chacune avec
une modalité différente.
Gaiffe B. & Romary L. (1997). Constraints on the Use
of Language, Gesture and Speech for Multimodal
Dialogues. Proceedings of the ACL-EACL Workshop
on Referring Phenomena in a Multimedia Context
and Their Computational Treatment, Madrid.
Hauptmann A.G. & McAvinney P. (1993). Gestures
with speech for graphic manipulation. International
Journal of Man-Machine Studies, 38, 231-249.
Huang, X. et al. (2001). MIPAD: A multimodal
interaction prototype. Proceedings of ICASSP’2001,
Salt Lake City.
Huls C. and Bos E. (1998). Studies in Full Integration of
Language and Action. In H. Bunt, R. Beuna, and T.
Borghuis (Eds.) Multimodal Human-Computer
Commmunication, Systems, Techniques, and
Experiments, Springer.
Kamp J.F. (1998). Interaction personnes-systèmes
embarqués. Etude des modalités et des dispositifs
d'interaction. Thèse d’Informatique de l'ENST.
Karsenty L. (2002) Shifting the design philosophy of
spoken natural language dialogue: From invisible to
transparent systems. International Journal of Speech
Technology, 5(2), 147-158.
Karsenty L. & Botherel V. (2005) Transparency
strategies to help users handle system errors. Speech
Communication, 45, 305-324.
Karsenty L., Sire S., Causse M., Deherly D. (2005) Quel
impact de l'entrée vocale sur la conception graphique
d'un service mobile ? Actes de la Conférence
IHM’2005, ACM Press.
Krauss R.M., Chen Y. & Gottesman R.F. (2000).
Lexical gestures and lexical access: a process model.
In: McNeill D. (ed.) Language and Gesture (pp. 261283). Cambridge University Press.
Lamel L., Bennacef S., Gauvain J.L., Dartigues H. &
Temem J.N. (2002) User Evaluation of the MASK
Kiosk. Speech Communication, 38(1-2), 131-139.
Martin J.C., Julia L. & Cheyer A. (1998). A theoretical
framework for multimodal user studies. Proc. of the
2d Int. Conf. on Cooperative Multimodal
Communication (pp. 104-110), Tilburg.
Mignot C. & Carbonell N. (1996). Commande orale et
gestuelle : étude empirique. Technique et Science
Informatiques, 15(10), 1399-1428.
Nigay L. & Coutaz J. (1996). Espaces de conception des
interfaces multimédia et multimodales. Techniques et
Sciences de l'Informatique, 15(9), 1195-1225.
Oviatt S. L. & vanGent R. (1996) Error resolution
during multimodal human--computer interaction.
Proc. of the Int. Conf. on Spoken Language
Processing, Philadelphia.
Oviatt S. L., DeAngeli A. & Kuhn K. (1997). Integration
and synchronization of input modes during
multimodal
human-computer
interaction.
Proceedings of CHI '97, ACM Press, pp. 415-422.
Au-delà de ces enseignements, les travaux rapportés ici
soulèvent quelques questions qu’il reste à traiter. L’une
d’elles concerne l’effort d’apprentissage face à une
interface multimodale. Peu d’études abordent cette
question pourtant centrale dans la perspective de
déployer commercialement des produits ou services
multimodaux. Or, à l’image des interfaces vocales dont
on pensait à tort qu’elles pouvaient être naturelles, c-àd., utilisable sans apprentissage (Karsenty, 2002), il
apparaît relativement évident que les interfaces
multimodales
nécessiteront
aussi
un
certain
apprentissage. Quelle forme devra-t-il prendre ? Quelles
propriétés des interfaces multimodales devront être
apprises ? Dans quelle mesure des commandes
multimodales pourraient être découvertes dans la
continuité
des
(séquences
de)
commandes
monomodales ? Quelles sont les limites d’acceptabilité
des utilisateurs face à cette exigence d’apprentissage ?
Voici quelques questions que la recherche sur la
multimodalité devra aborder dans un avenir proche.
RÉFÉRENCES
Bernsen N.O. (2002). Multimodality in language and
speech systems. In: B. Granström, D. House and I.
Karlsson (eds.) Multimodality in language and
speech systems. Kluwer.
Butterworth & Hadar, 1989. Gesture, speech, and
computational stages: a reply to McNeill.
Psychological Review, 96, 168-174
Calvet G. et al. (2001) Etude empirique de l’usage de la
multimodalité avec un ordinateur de poche. Actes
d’IHM-HCI 2001 (papier court), Lille-France.
Catinis L. et Caelen J. (1995) Analyse du comportement
multimodal de l'usager humain dans une tâche de
dessin. Actes d’IHM'95, pp.123-129.
Catinis L. (1998). Etude de l'usage de la parole dans les
interfaces multimodales. Thèse de l’Institut National
Polytechnique de Grenoble.
Cohen, P. R., Johnston, M., McGee, D., Oviatt, S.,
Pittman, J., Smith, I., Chen, L., & Clow, J. (1997).
Quickset: Multimodal interaction for distributed
applications. Proceedings of the 5th International
Multimedia Conference, pp. 31-40. ACM Press.
Cohen, P. R., Johnston, M., McGee, D., Oviatt, S. L.,
Clow, J., & Smith, I. (1998). The efficiency of
multimodal interaction: A case study. Proceedings of
ICSLP’98, vol.2, pp. 249-252.
Coutaz J. & Nigay L. (1994) Les propriétés CARE dans
les interfaces multimodales. Actes d’IHM’94, pp. 714, Lille
126
Petrelli D., De Angeli A., Gerbino W., Cassano G.
(1997). Referring in Multimodal Systems: The
Importance of User Expertise and System Features.
Proceedings of the Workshop on Referring
Phenomena in a Multimedia Context and Their
Computational Treatment, Madrid.
Siroux, J., Guyomard, M., Multon, F. and Remondeau,
C. (1995) Oral and gestural activities of the users in
the GEORAL system. Proceedings of the First
International Workshop IMMI, Edinburgh.
Suhm B., Myers B. & Waibel A. (2001) Multimodal
error correction for speech user interfaces. ACM
Transactions on Computer-Human Interaction
(TOCHI), 8(1), March 2001, 60-98.
Thalmann D. (2002) Using Virtual Humans for
Multimodal Communication in Virtual Reality and
Augmented Reality. In: P.C. Yuen, Y.Y. Tang & P.
Wang (eds.) Multimodal interface for humanmachine communication. World Scientific.
127
Usage des interactions verbales pour la conception
d’applications interactives centrée Genre
0DULRQ/DWDS\3KLOLSSH/RSLVWpJX\3DQW[LND'DJRUUHW0DXUR*DLR
LIUPPA - Laboratoire d’Informatique de l’Université de Pau et Pays de l’Adour
IUT de Bayonne, Château Neuf, Place Paul Bert
64100 BAYONNE
[Latapy, Lopisteguy, Dagorret, Gaio]@univ-pau.fr
RESUME
/D SHUIRUPDQFH G¶XQH DSSOLFDWLRQ LQWHUDFWLYH SHXW rWUH
pYDOXpH HQWUH DXWUHV HQ WHUPHV G¶DFFHSWDELOLWp 1RXV
FRQVLGpURQV TXH YDORULVHU OD GLPHQVLRQ JHQUH GDQV OH
SURFHVVXV GH FRQFHSWLRQ G¶XQH DSSOLFDWLRQ LQWHUDFWLYH
IDYRULVHVRQDFFHSWDELOLWp(QHIIHWOHJHQUHHVWXQFRGH
SDUWDJp HQWUH OHV LQWHUDFWDQWV TXL V¶DSSXLH VXU GHV
VWUXFWXUHV GHFRPPXQLFDWLRQHW UpSRQGjGHV LQWHQWLRQV
GHFRPPXQLFDWLRQSHUPHWWDQWGHVDWLVIDLUHOHVDWWHQWHVGH
O¶XWLOLVDWHXU 1RXV SURSRVRQV GDQV FHW DUWLFOH GH QRXV
DSSX\HU VXU OD WKpRULH GHV LQWHUDFWLRQV YHUEDOHV TXL PHW
HQ pYLGHQFH WURLV QLYHDX[ GH GpFRPSRVLWLRQ GLDORJLTXH
VHORQ OHVTXHOV OHV LQWHUDFWDQWV RUJDQLVHQW OHXU
FRPPXQLFDWLRQ O¶LQWHUDFWLRQODVpTXHQFHHW O¶pFKDQJH
1RXV PHWWRQV HQ pYLGHQFH O¶H[LVWHQFH G¶XQH
GpFRPSRVLWLRQ VLPLODLUH GDQV OHV LQWHUDFWLRQV HQWUH
O¶DSSOLFDWLRQ LQWHUDFWLYH HW VRQ XWLOLVDWHXU &HWWH
VLPLOLWXGH QRXV FRQGXLW j REVHUYHU TXH OHV SURSULpWpV
VWUXFWXUDQWHV DVVRFLpHV j O
RUJDQLVDWLRQ KLpUDUFKLTXH GHV
LQWHUDFWLRQV YHUEDOHV VRQW pJDOHPHQW SUpVHQWHV GDQV OHV
LQWHUDFWLRQV HQWUH O
XWLOLVDWHXU HW O
DSSOLFDWLRQ 1RXV
SURSRVRQV DORUV GHV UHFRPPDQGDWLRQV HW XQH QRWDWLRQ
YDORULVDQW ORUV GX SURFHVVXV GH FRQFHSWLRQ OD SULVH HQ
FRPSWHGHFHVSURSULpWpVUHODWLYHPHQWjXQJHQUHGRQQp
&RPPH UpVXOWDW GH O
H[SpULPHQWDWLRQ GH FHWWH DSSURFKH
QRXV SUpVHQWRQV XQ H[WUDLW GH OD KLpUDUFKLH GHV
LQWHUDFWLRQVG
XQHDSSOLFDWLRQGXJHQUHOXGRpGXFDWLI
MOTS CLES :,QWHUDFWLRQV YHUEDOHV JHQUHDSSOLFDWLRQV
LQWHUDFWLYHVUHFRPPDQGDWLRQVGHFRQFHSWLRQ
ABSTRACT
$FFHSWDELOLW\RILQWHUDFWLYHDSSOLFDWLRQVFDQEHPHDVXUHG
LQ WHUPV RI SHUIRUPDQFH :H FRQVLGHU WKDQ HQKDQFLQJ
WKH *HQUH GLPHQVLRQ RI DQ LQWHUDFWLYH DSSOLFDWLRQ DLGV
VXSSRUWLQJ LWV DFFHSWDELOLW\ ,QGHHG *HQUH FDQ EH
YLHZHG DV D VHW RI UXOHV VKDUHG E\ LQWHUDFWLQJ HQWLWLHV
VXSSRUWHG E\ FRPPXQLFDWLRQ VWUXFWXUHVWKDW PDWFKHVWR
GHVLJQHUV FRPPXQLFDWLRQ LQWHQWLRQV DQG IXOILOV XVHUV
H[SHFWDWLRQV ,Q WKLV SDSHU ZH DLP WR EDVH RXU SXUSRVH
RQ WKH YHUEDO LQWHUDFWLRQV WKHRU\ ZKLFK LGHQWLILHV WKUHH
GLDORJLFDO OHYHOV RI LQWHUDFWRUV FRPPXQLFDWLRQ
LQWHUDFWLRQ VHTXHQFH DQG H[FKDQJH :H KLJKOLJKW WKH
H[LVWHQFH RI D VLPLODU KLHUDUFK\ LQ H[LVWLQJ LQWHUDFWLRQV
EHWZHHQ DQ LQWHUDFWLYH DSSOLFDWLRQ DQG LWV XVHU 7KLV
VLPLODULW\ OHDGV XV WR REVHUYH WKDW WKH VWUXFWXULQJ
129
SURSHUWLHV UHODWHG WR WKH KLHUDUFKLFDO RUJDQL]DWLRQ RI
YHUEDO LQWHUDFWLRQV DUH DOVR YLVLEOH LQ DSSOLFDWLRQ XVHU
LQWHUDFWLRQV 7KHUHE\ ZH JLYH VRPH GHVLJQ JXLGHOLQHV
DQG HOHPHQWV RI QRWDWLRQ WKDW WDNH LQWR DFFRXQW WKHVH
SURSHUWLHVUHODWLYHWRDJLYHQJHQUH$QH[SHULPHQWDWLRQ
WKDW HQKDQFHV WKH LQWHUDFWLRQV KLHUDUFK\ RI D OXGR
HGXFDWLRQDODSSOLFDWLRQLVILQDOO\SUHVHQWHG
KEYWORDS: 9HUEDO LQWHUDFWLRQV JHQUH LQWHUDFWLYH
DSSOLFDWLRQVJXLGHOLQHV
INTRODUCTION
3DUPL OHV FULWqUHV SHUPHWWDQW G¶pYDOXHU OD SHUIRUPDQFH
QRXV FRQVLGpURQV GDQV QRV UHFKHUFKHV OH FULWqUH
G¶DFFHSWDELOLWp >@ /¶DFFHSWDELOLWp SHXW rWUH VFLQGpH
VHORQ GHX[ GLPHQVLRQV O¶DFFHSWDELOLWp VRFLDOH
V¶LQWpUHVVDQW DX FRQWH[WH G¶XWLOLVDWLRQ GX V\VWqPH HW
O¶DFFHSWDELOLWp SUDWLTXH FRQVLGpUDQW O¶LQWHQWLRQ RX EXW
TXHOHV\VWqPHSHUPHWG¶DWWHLQGUH>@
%LHQ TX¶XWLOLVpH GHSXLV GHV VLqFOHV GDQV OD
FRPPXQLFDWLRQHWODFUpDWLRQODQRWLRQGH ©*HQUHªHVW
HQFRUH SHX FRQVLGpUpH HQ LQIRUPDWLTXH 1RV WUDYDX[
V¶LQWpUHVVHQWjFHWWH QRWLRQFRPPH XQH GLPHQVLRQTXLD
OD FDSDFLWp GH IDYRULVHU O¶DFFHSWDELOLWp GHV SURGXLWV
UpVXOWDQWV (Q HIIHW OH JHQUH IDYRULVH O¶DFFHSWDELOLWp
VRFLDOH SXLVTX¶LO HVW XQ FRGH SDUWDJp HQWUH OHV
LQWHUDFWDQWV HW O¶DFFHSWDELOLWp SUDWLTXH SXLVTX¶LO UpSRQG
jXQHRXSOXVLHXUVLQWHQWLRQVGHFRPPXQLFDWLRQ>@
$LQVL OH JHQUH HVW FDUDFWpULVp SDU GHV VWUXFWXUHV GH
FRPPXQLFDWLRQ UpFXUUHQWHV SDUWDJpHV SDU O¶pPHWWHXU
DXWHXUHWOHUpFHSWHXUXWLOLVDWHXUOHSUHPLHUVHVHUYDQWGH
FHVLQYDULDQWVSRXURUJDQLVHUVRQPHVVDJHGDQVOHJHQUH
VRXKDLWp OH VHFRQG UHFHYDQW OH PHVVDJH SDU OH ELDLV GX
JHQUH GRQW LO FRQQDvW OHV UqJOHV /HV VWUXFWXUHV GH
FRPPXQLFDWLRQ FRQVWLWXHQW OHV EULTXHV GH EDVH SRXU
DUWLFXOHU OD FRPPXQLFDWLRQ QRXV QRXV VRPPHV
LQWpUHVVpV j OD WKpRULH GHV LQWHUDFWLRQV YHUEDOHV TXL
SURSRVH GHV SULQFLSHV VHORQ OHVTXHOV V¶RUJDQLVH OD
FRPPXQLFDWLRQ1RXVDYRQVUpDOLVpXQSDUDOOqOHHQWUHOHV
LQWHUDFWLRQV YHUEDOHV KRPPHKRPPH HW OHV LQWHUDFWLRQV
KRPPHPDFKLQHSRXU DGDSWHU OHV SULQFLSHV GDQV XQH
SHUVSHFWLYH GH FRQFHSWLRQ G¶DSSOLFDWLRQV /HV
DSSOLFDWLRQV LQWHUDFWLYHV FRQVLGpUpHV QH UHOqYHQW SDV GX
GLDORJXH KRPPHPDFKLQH DX VHQV GH >@ FRPSRUWDQW
GHVV\VWqPHVUpDFWLIV©LQWHOOLJHQWVªLQIpUHQFHVDJHQWV
/¶REMHFWLI HVW G¶LGHQWLILHU GHV UqJOHV GH KDXW QLYHDX
GpULYpHV GHV LQWHUDFWLRQV YHUEDOHV j GHVWLQDWLRQ GH
FRQFHSWHXUVG¶DSSOLFDWLRQVLQWHUDFWLYHVHWGHOHVYDORULVHU
GDQV OHV SURFHVVXV GH FRQFHSWLRQ SRXU RUJDQLVHU OHV
VWUXFWXUHVGHFRPPXQLFDWLRQGXJHQUHYRXOX
$LQVLXQWULSOHFRQVWDWDQLPHQRWUHUpIOH[LRQ
• OH JHQUH HVW LQKpUHQW j WRXWH DFWLYLWp GH
FRPPXQLFDWLRQ LO HVW SRUWHXU G¶XQH LQWHQWLRQ TXL
VWUXFWXUHOHGpURXOHPHQWGHO¶DSSOLFDWLRQ
• OHJHQUHGpILQLWGHVVWUXFWXUHVGHFRPPXQLFDWLRQ
• OHPpODQJHGHVJHQUHVHVWXQYHFWHXUGHFUpDWLYLWp
&HW DUWLFOH HVW VWUXFWXUp FRPPH VXLW /D SUHPLqUH SDUWLH
HVWFRQVDFUpHjXQHSUpVHQWDWLRQGHODQRWLRQGHJHQUHGH
VRQDFFHSWLRQOLWWpUDLUHjVRQDFFHSWLRQGDQVOHGRPDLQH
LQIRUPDWLTXH /D GHX[LqPH SDUWLH GpWDLOOH O¶DGDSWDWLRQ
QRWDPPHQW DX[ DSSOLFDWLRQV LQWHUDFWLYHV j YRFDWLRQ GH
ORLVLU GHV REVHUYDWLRQV IDLWHV GDQV OHV LQWHUDFWLRQV
YHUEDOHV &HWWH DGDSWDWLRQ GRQQH OLHX j GHV
UHFRPPDQGDWLRQV j GHVWLQDWLRQ GHV FRQFHSWHXUV
G
DSSOLFDWLRQV LQWHUDFWLYHV /D WURLVLqPH SDUWLH SURSRVH
XQHQRWDWLRQGpULYpHGHVPRGqOHVGHWkFKHVSRXUDLGHUj
ODPRGpOLVDWLRQGHVFpQDULRVLQWHUDFWLRQQHOVTXLGpFULYHQW
OHVVWUXFWXUHVGHFRPPXQLFDWLRQ/DTXDWULqPHSDUWLHHVW
FRQVDFUpH j XQH H[SpULPHQWDWLRQ HOOH SUpVHQWH XQH
DSSOLFDWLRQ LQWHUDFWLYH GH JHQUH OXGRpGXFDWLI TXL
H[SORLWHFHVSURSRVLWLRQV(QILQQRXVWHUPLQRQVSDUGHV
pOpPHQWVGHFRQFOXVLRQ
5HODWLYHPHQWjFHGHUQLHUSRLQWQRXVREVHUYRQVTXHGHV
SURGXFWLRQVQRYDWULFHVVRQWSDUIRLVLVVXHVGXPpODQJHGH
VWUXFWXUHV GH FRPPXQLFDWLRQ HPSUXQWpHV j GLIIpUHQWV
JHQUHV $ WLWUH G¶H[HPSOH QRXV SRXYRQV FLWHU OHV
DSSOLFDWLRQV OXGRpGXFDWLYHV TXL PpODQJHQW GHV
VWUXFWXUHV HPSUXQWpHV DX[ JHQUHV pGXFDWLI HW OXGLTXH
QRXVLOOXVWURQVFHPpODQJHHQTXDWULqPHSDUWLH
LA NOTION DE GENRE
/D QRWLRQ GH *HQUHHVW XQH GLPHQVLRQ FXOWXUHOOHPHQW
LQKpUHQWH j WRXWH DFWLYLWp GH FRPPXQLFDWLRQ (OOH HVW
DSSDUXH HQ DYDQW -& DYHF $ULVWRWH TXL HQ D SRVp
OHV IRQGHPHQWV HQ V
LQWHUURJHDQW VXU OH U{OH GX ODQJDJH
GDQVODFRPPXQLFDWLRQHWODFUpDWLRQ
'¶DSUqV OHV IRUPDOLVWHV OHV JHQUHV GLIIqUHQW VHORQ OHXU
GRPLQDQWH FHOOHFL pWDQW OLpH DX[ IRQFWLRQV TXH UHPSOLW
XQH°XYUH>@&HFLJXLGHQRWUHDSSURFKHHWQRXVPqQHj
FRQVLGpUHUTXHOHFKRL[G¶XQJHQUHHVWGpWHUPLQpSDUXQH
LQWHQWLRQ GH FRPPXQLFDWLRQ F¶HVWjGLUH XQH OLJQH
GLUHFWULFHTXLRULHQWHODWUDQVPLVVLRQGXPHVVDJH
3DUDLOOHXUVOHVFKHUFKHXUVLVVXVGXGRPDLQHGHVJHQUHV
>@>@DIILUPHQWTX¶XQJHQUHLQGXLWGHVFRQYHQWLRQVHW
VWUXFWXUHV GH FRPPXQLFDWLRQ VXU OHVTXHOOHV UHSRVHQW OHV
pFKDQJHV HQWUH LQWHUDFWDQWV pPHWWHXUV HW UpFHSWHXUV
/RUVTX¶XQFRQFHSWHXUFKRLVLWG¶XWLOLVHUGHVVWUXFWXUHVGH
FRPPXQLFDWLRQVRQFKRL[HVWJXLGpSDUXQHLQWHQWLRQHW
OD FRPELQDLVRQ GHV VWUXFWXUHV UHWHQXHV UHVSHFWH OHV
FRQYHQWLRQV GX JHQUH DYHF OHTXHO OH SXEOLF HVW IDPLOLHU
$LQVLOHJHQUHGpILQLWXQFRGHSDUWDJpHQWUHpPHWWHXUVHW
UpFHSWHXUVFHTXLIDFLOLWHODWUDQVPLVVLRQGXPHVVDJH
(Q pODUJLVVDQW OD FRPPXQLFDWLRQ j G¶DXWUHV PpGLDV TXH
OHWH[WHpFULWF¶HVWGHSXLVSHXTXHOHJHQUHFRPPHQFHj
rWUH FRQVLGpUp FRPPH UpIpUHQW GDQV OHV V\VWqPHV
G¶LQIRUPDWLRQ >@>@>@ &HV WUDYDX[ WUDLWHQW GH OD
GLPHQVLRQ JHQUH FRPPH FRQFHSW VWUXFWXUDQW SRXU OHV
SDWURQVGHFRQFHSWLRQG¶LQWHUDFWLRQOHJHQUH GpILQLVVDQW
OHVDWWHQWHVGXSXEOLF
DES
INTERACTIONS
INTERACTIONS
ENTRE
APPLICATION
VERBALES
UTILISATEUR
/HV WUDYDX[ VXU OHV LQWHUDFWLRQV YHUEDOHV pWXGLHQW HQWUH
DXWUHV O¶RUJDQLVDWLRQ VWUXFWXUHOOH GHV pFKDQJHV UpDOLVpV
HQWUH LQWHUORFXWHXUV >@ >@ HW OHV SURSULpWpV HW UqJOHV
TXL UpJLVVHQW FHV pFKDQJHV &HV WUDYDX[ VRQW UpDOLVpV
GDQV GHV SHUVSHFWLYHV UHODWLYHV DX GLVFRXUV HW DX
GLDORJXHWHOOHVTXHSDUH[HPSOHO¶DQDO\VHHWODV\QWKqVH
GH GLVFRXUV >@ OD FRQFHSWLRQ GH V\VWqPHV G¶DLGH DX
GLDORJXH KRPPHPDFKLQH >@ RX OD FRRUGLQDWLRQ
G¶DFWHXUVYLUWXHOV>@RXKXPDLQV>@
1RWUH LQWpUrW SRXU OHV WUDYDX[ HQ LQWHUDFWLRQV YHUEDOHV
V
HVW RULHQWp YHUV OHV SULQFLSHV pOpPHQWDLUHV PLV HQ
pYLGHQFH GDQV OHV pFKDQJHV HQWUH LQWHUDFWDQWV &HV
SULQFLSHVSUpVHQWHQWODSDUWLFXODULWpGHVHUYLUGHFDGUHGH
FRPPXQLFDWLRQ DX[ LQWHUDFWDQWV OHXU SUpGLVSRVLWLRQ
FRJQLWLYH j UHVSHFWHU FHV SULQFLSHV QRXV D FRQGXLW j
HQYLVDJHUOHXUDGDSWDWLRQDX[DSSOLFDWLRQVLQWHUDFWLYHV
&HWWH VHFWLRQ PHW HQ FRUUHVSRQGDQFH GHV UpVXOWDWV LVVXV
GH O¶DQDO\VH GHV LQWHUDFWLRQV YHUEDOHV DYHF OHV
LQWHUDFWLRQV HQWUH XWLOLVDWHXU HW DSSOLFDWLRQ LQWHUDFWLYH
'DQV XQ SUHPLHU WHPSV FHWWH FRUUHVSRQGDQFH SRUWH VXU
O¶RUJDQLVDWLRQ KLpUDUFKLTXH GHV LQWHUDFWLRQV &HWWH
VLPLOLWXGHKLpUDUFKLTXHHVWHQVXLWHXWLOLVpHSRXUPHWWUHHQ
H[HUJXHGDQVOHVDSSOLFDWLRQVLQWHUDFWLYHVGHVSURSULpWpV
REVHUYpHVGDQVOHVLQWHUDFWLRQVYHUEDOHVDILQGHGpJDJHU
GHV UHFRPPDQGDWLRQV j GHVWLQDWLRQ GH FRQFHSWHXUV
G
DSSOLFDWLRQVLQWHUDFWLYHV
$X FRXUV GH FHWWH pWXGH OHV FKRL[ WHUPLQRORJLTXHV
RSpUpVSULYLOpJLHURQWOHIRFXVXWLOLVDWHXUSDUDLOOHXUVSDU
VRXFLV GH VLPSOLILFDWLRQ OHV PrPHV WHUPHV VHURQW
PDLQWHQXV SRXU QRPPHU OHV H[pFXWLRQV REVHUYpHV GDQV
XQH VHVVLRQ HW OHV XQLWpV FRQFHSWXHOOHV TXL DXURQW
YRFDWLRQjSRUWHUFHVH[pFXWLRQV
1RXVRSSRVRQVOHVDSSOLFDWLRQVLQWHUDFWLYHVjYRFDWLRQGH
ORLVLUDX[DSSOLFDWLRQVGHSURGXFWLRQTXLVXSSRUWHQWXQH
DFWLYLWpKXPDLQHGDQVXQFRQWH[WHSURIHVVLRQQHO
130
AUX
ET
/HVSULQFLSHVUHWHQXVQHSUpWHQGHQWSDVFRXYULU
H[KDXVWLYHPHQWOHFKDPSGLVFLSOLQDLUHGHVLQWHUDFWLRQV
YHUEDOHV
Organisation hiérarchique
/¶XQGHVSULQFLSHVIRQGDWHXUVLVVXGHO¶pFROHJHQHYRLVH
VXU OHTXHO VH EDVH XQH SDUW VLJQLILFDWLYH GHV WUDYDX[ HQ
LQWHUDFWLRQV YHUEDOHV HVW FHOXL GH OD GpFRPSRVLWLRQ GHV
LQWHUDFWLRQV HQWUH ORFXWHXUV VHORQ SOXVLHXUV QLYHDX[
O¶LQWHUYHQWLRQO¶pFKDQJHODVpTXHQFHHWO¶LQWHUDFWLRQ
/¶LQWHUDFWLRQ FRXYUH O
HQVHPEOH GH OD FRQYHUVDWLRQ HOOH
HVWFDUDFWpULVpHSDUOHFDGUHLQWHUDFWLRQQHOGDQVOHTXHOOD
FRQYHUVDWLRQ HVW GpOLPLWpH /¶LQWHUDFWLRQ HVW FRPSRVpH
GH VpTXHQFHV FRQVWLWXpHV G
pFKDQJHV UHOLpV SDU XQ IRUW
GHJUpGHFRKpUHQFHVpPDQWLTXHHWRXSUDJPDWLTXHFHTXL
FRUUHVSRQG j XQ VHXO REMHW WUDQVDFWLRQQHO &
HVWjGLUH j
TXHOHVpFKDQJHVFRPSRVDQWXQHVpTXHQFHFRQFHUQHQWXQ
VHXO EXW /¶pFKDQJHHVW FRQVWLWXp G¶XQH j SOXVLHXUV
LQWHUYHQWLRQV XQH LQWHUYHQWLRQ pWDQW GpILQLH FRPPH OD
FRQWULEXWLRQG¶XQVHXOORFXWHXU
&HWWH KLpUDUFKLH PHWHQpYLGHQFH TXHODFRPPXQLFDWLRQ
HQWUH LQWHUDFWDQWV V¶RUJDQLVH VXU OD EDVH G¶LQWHUYHQWLRQV
UHJURXSpHV HQ pFKDQJHV HX[PrPHV RUJDQLVpV HQ
VpTXHQFHV O¶LQWHUDFWLRQ SRXU VD SDUW UHJURXSH GHV
VpTXHQFHVSDUWDJHDQWXQPrPHEXW
'DQV O¶DGDSWDWLRQ HQYLVDJpH GHX[ W\SHV G¶LQWHUDFWDQWV
VRQWFRQVLGpUpVO¶XWLOLVDWHXUHWO¶DSSOLFDWLRQLQWHUDFWLYH
'H IDLW OHV LQWHUYHQWLRQV VRQW VRLW GHV DFWLRQV
SHUFHSWLEOHVSDUO¶XWLOLVDWHXUDXTXHOFDVO¶DSSOLFDWLRQHVW
pPHWWULFH HW O¶XWLOLVDWHXU GHVWLQDWDLUH VRLW GHV DFWLRQV
UpDOLVpHV SDU O¶XWLOLVDWHXU DXTXHO FDV O¶XWLOLVDWHXU HVW
pPHWWHXU HW O¶DSSOLFDWLRQ GHVWLQDWDLUH 8QH VHVVLRQ TXL
FRXYUH O¶HQVHPEOH GHV LQWHUYHQWLRQV UpDOLVpHV HVW
DVVLPLODEOH j O¶LQWHUDFWLRQ $X FRXUV G¶XQH VHVVLRQ XQ
XWLOLVDWHXU UpDOLVH DYHF XQH DSSOLFDWLRQ LQWHUDFWLYH XQ
HQVHPEOHGHWkFKHVGRQWODFRPSOpWLRQV¶LQVFULWGDQVXQ
FDGUHHWXQ EXW /D FRPSOpWLRQGHVWkFKHVHVWOD SOXSDUW
GX WHPSV VDWLVIDLWH SDU OD UpDOLVDWLRQ GH WkFKHV GH SOXV
EDV QLYHDX &HWWH GpFRPSRVLWLRQ HQ VRXV WkFKHV QH VH
OLPLWH SDV QpFHVVDLUHPHQW j GHX[ QLYHDX[ ORJLTXHV
FRPPH FHOD HVW SURSRVp HQ LQWHUDFWLRQV YHUEDOHV
VpTXHQFHV FRPSRVpHV G¶pFKDQJHV HOOH SHXW HQ
FRPSRUWHUG¶DYDQWDJH$LQVLODVpTXHQFHHVWDVVLPLODEOH
j OD QRWLRQ G¶DFWLYLWp XQH DFWLYLWp UHSUpVHQWH OHV WUDFHV
G¶XQH WkFKH HW GH EXW DVVRFLp XQ HQVHPEOH G¶DFWLYLWpV
FRUUHVSRQGDQWDXGpURXOHPHQWG¶XQHVHVVLRQ(QILQQRXV
FRQVHUYRQV OD WHUPLQRORJLH G¶pFKDQJH SRXU OD VWUXFWXUH
GH SOXV EDV QLYHDX HOOH FRUUHVSRQG DX[ HQFKDvQHPHQWV
G¶LQWHUYHQWLRQVVLPSOHVWHOVTXHSDUH[HPSOHODVpOHFWLRQ
ODQRWLILFDWLRQRXODYDOLGDWLRQ
/HVDFWLRQVUpDOLVpHVSDUO¶XWLOLVDWHXUVRQWUpGXLWHVDX[
SRWHQWLDOLWpVG¶LQWHUYHQWLRQPLVHVjVDGLVSRVLWLRQjWRXW
LQVWDQW
>@SDUOHGHVpTXHQFHVHWG
pSLVRGHVG¶LQWHUYHQWLRQVUpDOLVpV
SDUO¶XWLOLVDWHXU
131
,QWHUDFWLRQ
6pTXHQFH
)RUW'HJUp
GH&RKpUHQFH
6HVVLRQ
%XW
(FKDQJH
,QWHUYHQWLRQ
/RFXWHXU
$FWLYLWp
$FWLYLWp
&RPSRVpH
(FKDQJH
$FWLYLWp6LPSOH
,QWHUYHQWLRQ
$FWLRQ
3HUFHSWLEOH
$FWLRQ
5pDOLVDEOH
,QWHUDFWDQW
8WLOLVDWHXU
$SSOLFDWLRQ
,QWHUDFWLYH
)LJXUHLQWHUDFWLRQYHUEDOHÙVHVVLRQLQWHUDFWLYH
1RXVDYRQVDLQVLUDSSURFKpILJXUHGDQVXQHQRWDWLRQ
HPSUXQWpH j 80/ OHV QRWLRQV G¶LQWHUDFWLRQ VpTXHQFH
pFKDQJHHWLQWHUYHQWLRQGHVQRWLRQVGHVHVVLRQDFWLYLWp
pFKDQJHHWLQWHUYHQWLRQTXHQRXVTXDOLILRQVSDUODVXLWH
G¶XQLWp G
LQWHUDFWLRQ 1RXV SRXUVXLYRQV HQ LGHQWLILDQW
GHV SURSULpWpV REVHUYpHV GDQV OHV LQWHUDFWLRQV YHUEDOHV
DGDSWDEOHVDX[DSSOLFDWLRQVLQWHUDFWLYHVSRXUHQGpULYHU
GHVUHFRPPDQGDWLRQVGHFRQFHSWLRQ
Cadre interactionnel
7RXW FRPPH GDQV OHV LQWHUDFWLRQV YHUEDOHV XQH VHVVLRQ
HVWFDUDFWpULVpHSDUXQFDGUHLQWHUDFWLRQQHOFRPSRVp
G¶XQVFKpPDSDUWLFLSDWLRQQHOVHVLQWHUDFWDQWV
G¶XQGRPDLQHOHUpIpUHQWHQLQWHUDFWLRQVYHUEDOHVHW
VHV WKpPDWLTXHV VXU OHVTXHOOHV SRUWHQW OHV
LQWHUDFWLRQV
G¶XQHXQLWpGHWHPSVHWGHOLHXVWDEOHVWRXWDXORQJGH
OD VHVVLRQ FDU QRXV FRQVLGpURQV LFL OHV DSSOLFDWLRQV
V\QFKURQHV
/DPRGLILFDWLRQGHO¶XQHGHFHVFDUDFWpULVWLTXHVLPSOLTXH
ODIHUPHWXUHGHODVHVVLRQUHVSO¶LQWHUDFWLRQDFWXHOOHHW
O¶RXYHUWXUHG¶XQHQRXYHOOH
Système de place
6HORQ FH SULQFLSH OD SODFH VRFLDOH SURIHVVLRQQHOOH«
RFFXSpH SDUO
LQWHUDFWDQWPDLVDXVVL VDUHODWLRQ YLV j YLV
GH VRQ LQWHUORFXWHXU FRQWUDLJQHQW VHV LQWHUYHQWLRQV
FHOOHVFLUHVSHFWHQWGHVWUDLWVVSpFLILTXHVHWFDUDFWpULVHQW
VRQ pQRQFLDWLRQ HW VHV DFWHV GH ODQJDJH DVVHUWLI
SURPLVVLIGLUHFWLI«
5HFRPPDQGDWLRQ
&RQVWUXLUH XQ V\VWqPH GH SODFH SRXU OHV LQWHUDFWDQWV HW
OHVpYHQWXHOVDYDWDUV
$X FRXUV G¶XQH VHVVLRQ LO H[LVWH pJDOHPHQW XQ V\VWqPH
GH SODFH LPSOLFLWH HQWUH O
XWLOLVDWHXU HW O
DSSOLFDWLRQ &H
V\VWqPH GH SODFH HVW OLp DX U{OH TX¶j O¶LQWHUDFWDQW GDQV
O¶DSSOLFDWLRQ FH U{OH pWDQW LQGXLW SDU OH JHQUH GH
O¶DSSOLFDWLRQ 3DU H[HPSOH O¶XWLOLVDWHXU SHXW GDQV XQH
DSSOLFDWLRQ pGXFDWLYH DYRLU XQ U{OH G¶DSSUHQDQW
G¶DVVLVWDQW RX GH WXWHXU GDQV XQH DSSOLFDWLRQ OXGLTXH
O¶XWLOLVDWHXUSHXWDYRLUXQU{OHGHMRXHXUHWO¶DSSOLFDWLRQ
XQU{OHGHSHUVRQQDJHQRQMRXHXUGHPRGpUDWHXU«$X
U{OH DVVRFLp j O¶LQWHUDFWDQW FRUUHVSRQGHQW GHV SDWURQV
/RUVTXHGHVFRQFHSWVIRQWO
REMHWGHSHUVRQQLILFDWLRQOHXUV
DYDWDUVGRLYHQWrWUHLQWpJUpVGDQVOHV\VWqPHGHSODFH
G¶LQWHUYHQWLRQVGDQVOHVTXHOVO¶pQRQFLDWLRQHVWFRQIRUPH
jVDSODFH&HVSDWURQVG¶LQWHUYHQWLRQVVHPDWpULDOLVHURQW
QRWDPPHQW GDQV OHV PHVVDJHV pPLV SDU O¶DSSOLFDWLRQ HW
GDQVOHVDFWLRQVUpDOLVDEOHVSDUO¶XWLOLVDWHXU
3RXUOHVDSSOLFDWLRQVLQWHUDFWLYHVGRQWODFRQFHSWLRQHVW
EDVpHVXUGHVSURWRW\SHVGHQRPEUHXVHVDPELJXwWpVVRQW
OHYpHV JUkFH j O¶DMXVWHPHQW GHV PHVVDJHV HW GH OHXUV
PRGHV G
pQRQFLDWLRQ GqV OHV SUHPLqUHV LWpUDWLRQV GX
SURWRW\SDJH/
pWDEOLVVHPHQWG
XQV\VWqPHGHSODFHSRXU
FKDFXQHGHVXQLWpVG
LQWHUDFWLRQpYLWHDLQVLODUpDOLVDWLRQ
G
DMXVWHPHQWVGLVVROXVDXFRXSSDUFRXS
Propriétés de démarcation
'DQV XQ GLDORJXH OHV LQWHUDFWLRQV UHVS pFKDQJHV VRQW
JpQpUDOHPHQW ERUQpHV SDU GHV VpTXHQFHV UHVS
LQWHUYHQWLRQV GH SOXV EDV QLYHDX D\DQW GHV SURSULpWpV
GpPDUFDWLYHV $LQVL O¶LQWHUDFWLRQ SHXW rWUH LQLWLpH SDU
XQH VpTXHQFH G¶RXYHUWXUH HW WHUPLQpH SDU XQH VpTXHQFH
GHFO{WXUHHWO¶pFKDQJHSDUXQHLQWHUYHQWLRQLQLWLDWLYHHW
XQHLQWHUYHQWLRQUpDFWLYHRXpYDOXDWLYH
5HFRPPDQGDWLRQ
%RUQHUOHVXQLWpVG
LQWHUDFWLRQSDUGHVXQLWpVG
RXYHUWXUH
HWGHIHUPHWXUH
&HWWH FDUDFWpULVWLTXH G
XQLWp G
LQWHUDFWLRQ GpPDUFDWLYH
SRXU LQWURGXLUH HW FRQFOXUH XQH VHVVLRQ RX XQH DFWLYLWp
HVWFRXUDQWHGDQVOHVDSSOLFDWLRQVLQWHUDFWLYHV
'DQV OHV DSSOLFDWLRQV GH JHQUH OXGLTXH QRWDPPHQW OHV
XQLWpVLQWURGXFWLYHVVHSUpVHQWHQWVRXYHQWVRXVODIRUPH
G¶XQHFLQpPDWLTXHDXGpEXWGXMHXSUpVHQWDQWOHMRXHXUHW
O¶XQLYHUV GDQV OHTXHO LO YD pYROXHU HW G¶XQ ©EULHILQJª
LQWURGXLVDQW OHV PLVVLRQV /HV XQLWpV FRQFOXVLYHV VRQW
JpQpUDOHPHQW XQ ©GHEULHILQJª j OD ILQ GHV PLVVLRQV HW
XQELODQGHVSRLQWVHWGXQLYHDXGXMRXHXUjODILQGXMHX
'HWHOOHVVpTXHQFHVGpPDUFDWLYHVREMHFWLIVHWFRQVLJQHV
ELODQ GHV DSSUHQWLVVDJHV VRQW pJDOHPHQW LGHQWLILDEOHV
GDQVOHVDSSOLFDWLRQVSpGDJRJLTXHV
/D QpFHVVLWp G¶XQLWpV GpPDUFDWLYHV HVW XQH SURSULpWp j
YDORULVHU GDQV OH SURFHVVXV GH FRQFHSWLRQ OHXU XWLOLWp
GpSHQGDQW GX FDGUH LQWHUDFWLRQQHO (OOHV PDUTXHQW
H[SOLFLWHPHQWOHGpEXWHWODILQG¶XQHXQLWpG¶LQWHUDFWLRQ
HW VRQW O¶RFFDVLRQ G¶pFKDQJHV VSpFLILTXHV QRWLILFDWLRQ
DMXVWHPHQWUpVXOWDWV\QWKqVH«
Propriétés d’enchaînement
$XFRXUVG¶XQGLDORJXHGHPrPHTXHGDQVXQHVHVVLRQ
OHV XQLWpV G¶LQWHUDFWLRQ SHXYHQW V
HQFKDvQHU
VpTXHQWLHOOHPHQW rWUH LQWHUURPSXHV V
HQFKkVVHU RX
SURJUHVVHU DOWHUQDWLYHPHQW FKDFXQH FRXYUDQW XQ EXW HW
XQHWKpPDWLTXHSURSUH
/RUVTXH GDQV XQ GLDORJXH UHVS XQH VHVVLRQ RQ RXYUH
XQHQRXYHOOHXQLWpG¶LQWHUDFWLRQTXLVHUWXQEXWRXWUDLWH
G¶XQWKqPHYRLVLQjO¶XQLWpHQFRXUVFHWWHQRXYHOOHXQLWp
HVWTXDOLILpHGHSDUHQWKpWLTXHVXERUGRQQpH3DUFRQWUHVL
OHEXWHWODWKpPDWLTXHVRQWpORLJQpVGHO¶XQLWpHQFRXUV
OD QRXYHOOH XQLWp HVW TXDOLILpH GH SDUHQWKpWLTXH
G¶LQWHUUXSWLRQ
132
3DU H[HPSOH OHV RSWLRQV RIIHUWHV GDQV XQ SRUWDLO WEB
FRQVWLWXHQW GHV LQWHUYHQWLRQV LQLWLDWLYHV GH O¶DSSOLFDWLRQ
DX[TXHOOHV O
XWLOLVDWHXU SHXW UpSRQGUH SDU XQH
LQWHUYHQWLRQ UpDFWLYH TXL IDLW SURJUHVVHU O
XQLWp
G
LQWHUDFWLRQ FRUUHVSRQGDQWH $LQVL GDQV XQH VHVVLRQ j
WRXW PRPHQWSOXVLHXUV XQLWpV G
LQWHUDFWLRQV SHXYHQWrWUH
HQFRXUVHWQRQWHUPLQpHV
5HFRPPDQGDWLRQ
2SWLPLVHUOHQRPEUHG¶XQLWpVG¶LQWHUDFWLRQHQFRXUV
2SWLPLVHU OH QRPEUH G
XQLWpV G
LQWHUDFWLRQ HQ FRXUV
GpSHQG GX JHQUH GH O¶DSSOLFDWLRQ FRQVLGpUpH HW GH VRQ
FDGUH LQWHUDFWLRQQHO 6L O
XWLOLVDWHXU Q¶HVW SDV H[SHUW FH
QRPEUHHVWjPLQLPLVHUSRXUQHSDVURPSUHODWUDPHGX
VFpQDULR6LOD WkFKH SRXUDWWHLQGUHOHEXWHVWFRPSOH[H
SDU H[HPSOH QRQ OLQpDLUH LO HVW VRXKDLWDEOH GH
GpFRPSRVHUO
XQLWpG
LQWHUDFWLRQFRUUHVSRQGDQWHHQXQLWpV
GH SOXV SHWLWH WDLOOH RX GH FRQFHYRLU GHV XQLWpV
G
LQWHUDFWLRQFRPSOpPHQWDLUHVD\DQWXQEXWG¶DLGHRXGH
V\QWKqVHFRPPHOHVWDEOHDX[GHERUG
/HV PpWKRGHV GH FRQFHSWLRQ WHQGHQW j UDWLRQDOLVHU OHV
XQLWpV G
LQWHUDFWLRQ HQ VXJJpUDQW DX FRQFHSWHXU
G
LGHQWLILHU GHV EXWV LQWHUDFWLRQQHOV 3DU H[HPSOH VHORQ
O¶DSSURFKHHWOHJHQUHG
DSSOLFDWLRQFRQVLGpUpODWkFKHj
UpDOLVHUO
REMHWjPDQLSXOHUODFRPPXQLFDWLRQjpWDEOLU
O
H[HUFLFH j UpDOLVHU OD SLqFH j GpSODFHU OH PRQVWUH j
YDLQFUH O
LQIRUPDWLRQ j SURSRVHUUHFKHUFKHU« VRQW GHV
EXWVSHUPHWWDQWGHUDWLRQDOLVHUOHVXQLWpVG
LQWHUDFWLRQ
Propriétés de complétude
'DQV OHV LQWHUDFWLRQV YHUEDOHV XQ pFKDQJH VDWLVIDLW OD
SURSULpWp GH FRPSOpWXGH LQWHUDFWLRQQHOOH ORUVTX¶LO \ D
FO{WXUH GH O¶pFKDQJH DYHF DFFRUG H[SOLFLWH GHV GHX[
LQWHUDFWDQWV FKDFXQ GDQV XQH LQWHUYHQWLRQ SURSUH &HWWH
SURSULpWp HVW W\SLTXHPHQW REVHUYDEOH GDQV XQH VHVVLRQ
GDQV OH FDV G
XQ UHWRXU XWLOLVDWHXU TXL LPSOLTXH GHX[
LQWHUYHQWLRQV FHOOH GH O
XWLOLVDWHXU SXLV FHOOH GH
O
DSSOLFDWLRQ 'H PrPH OD GHPDQGH GH FRQILUPDWLRQ
G¶XQH RSpUDWLRQ XWLOLVDWHXU VDWLVIDLW FHWWH SURSULpWp GH
FRPSOpWXGHLQWHUDFWLRQQHOOH
/D FRPSOpWXGH LQWHUDFWLYH TXDQW j HOOH HVW OLpH j OD
FODUWp HW DX FDUDFWqUH MXVWLILp GHV LQWHUYHQWLRQV TXL
SHUPHWWHQW j O¶LQWHUORFXWHXU GH SUHQGUH SRVLWLRQ HW
DXWRULVHQW OD SRXUVXLWH OLQpDLUH GX GLDORJXH 'DQV XQH
VHVVLRQ FHWWH SURSULpWp HVW VDWLVIDLWH ORUVTXH OHV
LQWHUYHQWLRQV GH O¶DSSOLFDWLRQ SHUPHWWHQW j O¶XWLOLVDWHXU
GH SURJUHVVHU GDQV O¶XQLWp G¶LQWHUDFWLRQ HQ FRXUV DYHF
OHVDFWLRQVTXLOXLVRQWRIIHUWHVSRXULQWHUYHQLU
5HFRPPDQGDWLRQ
2UJDQLVHU GDQV GHV VFpQDULRV LQWHUDFWLRQQHOV OHV
DFWLYLWpV pFKDQJHV HW LQWHUYHQWLRQV HQ UHJURXSHPHQWV
FRKpUHQWV
$LQVLSHUPHWWUHjO¶XWLOLVDWHXUODFRPSOpWLRQGHVDWkFKH
YD FRQGXLUH OH FRQFHSWHXU j RUJDQLVHU GHV XQLWpV
G¶LQWHUDFWLRQ UDWLRQDOLVpHV GDQV XQ OLYUDEOH OH VFpQDULR
LQWHUDFWLRQQHO/DIRQFWLRQGXVFpQDULRHVWGHIRUPDOLVHU
O
RUJDQLVDWLRQ GHV XQLWpV G
LQWHUDFWLRQ GDQV O
REMHFWLI GH
VHUYLU XQ EXW /HV FULWqUHV G¶RUJDQLVDWLRQ GHV XQLWpV
LQWHUDFWLRQQHOOHV TXL OH FRPSRVHQW HW TXL VHUYHQW FH EXW
GpSHQGHQW QRWDPPHQW GX JHQUH GH O
DSSOLFDWLRQ 1RXV
REVHUYRQV FHSHQGDQW TXH OD QRWLRQ GH VFpQDULR
LQWHUDFWLRQQHO HVW SUpVHQWH PDLV Q
HVW SDV H[SOLFLWHPHQW
LGHQWLILpHGDQVOHVPpWKRGHVGHFRQFHSWLRQ
3DU H[HPSOH XQ VFKpPD QDYLJDWLRQQHO SHUPHW
G
RUJDQLVHU OHV LQWHUYHQWLRQV G
XQH DSSOLFDWLRQ GDWD
FHQWULFV>@>@6\VWqPHG
,QIRUPDWLRQSRXUOH:HEHW
GH O
XWLOLVDWHXU HQ VH IRFDOLVDQW VXU OHV GRQQpHV j
SUpVHQWHUFRQVXOWHU8QVFKpPDGHSDUFRXUVSpGDJRJLTXH
VHUW OD SHUVSHFWLYH LQWHUDFWLRQQHOOH G
XQH DSSOLFDWLRQ
SpGDJRJLTXH HQ VH EDVDQW VXU GHV FULWqUHV SpGDJRJLTXHV
SUpUHTXLV DEVWUDFWLRQ LOOXVWUDWLRQ H[HUFLFH« /HV
PRGqOHV GH WkFKH SHUPHWWHQW G¶DERXWLU j XQ VFpQDULR
LQWHUDFWLRQQHOHQSULYLOpJLDQWODWkFKHjUpDOLVHU«
6HORQ OH JHQUH G¶DSSOLFDWLRQ OH VFpQDULR LQWHUDFWLRQQHO
SUHQG GRQF GLIIpUHQWHV IRUPHV HW HVW PRGpOLVp DYHF GHV
ODQJDJHVHWGHVQRWDWLRQVGLIIpUHQWV
/D VHFWLRQ VXLYDQWH SURSRVH XQH QRWDWLRQ SHUPHWWDQW
G¶DSSUpKHQGHU OHV pOpPHQWV IRQGDPHQWDX[ GX VFpQDULR
LQWHUDFWLRQQHO GDQV ODTXHOOH OHV LQWHUYHQWLRQV GHV
LQWHUDFWDQWV XWLOLVDWHXU HW DSSOLFDWLRQ SHXYHQW rWUH
H[SOLFLWHPHQWIRUPDOLVpHV
UNE
NOTATION
INTERACTIONNELS
POUR
LES
SCENARIOS
/D QRWDWLRQ TXH QRXV DYRQV pWDEOLH HVW LQVSLUpH GHV
PRGqOHV GH WkFKH FDU LOV SHUPHWWHQW GH GpFULUH
H[SOLFLWHPHQW OHV DFWLYLWpV GHV LQWHUDFWDQWV 1RWUH FKRL[
V
HVW GLULJp YHUV &RQFXUUHQW 7DVN 7UHH &77 >@ /D
QRWDWLRQ JUDSKLTXH DUERUHVFHQWH GH &77 IDFLOLWH OD
PRGpOLVDWLRQ GH QLYHDX[ G
DEVWUDFWLRQV TXH QRXV
XWLOLVHURQV SRXU PRGpOLVHU OD KLpUDUFKLH GHV XQLWpV
G
LQWHUDFWLRQOHVVFKpPDVUpVXOWDQWVVRQWH[SRUWDEOHVHQ
/2726>@FHTXLSHUPHWGHYDOLGHUOHXUFRKpUHQFH
Notation pour l’interaction
&77 SURSRVH TXDWUH W\SHV GH WkFKHV FRJQLWLYH
DEVWUDLWH LQWHUDFWLYH HW PDFKLQH /HV WkFKHV FRJQLWLYHV
DEVWUDLWHVHWPDFKLQHRQWpWpUHFRQGXLWHV
$FWLRQFRJQLWLYHUHSUpVHQWHWRXWHDFWLRQFRJQLWLYH
RXQRQLQWHUDFWLRQQHOOHUpDOLVpHSDUO¶XWLOLVDWHXU
$FWLRQ PDFKLQH UHSUpVHQWH WRXW WUDLWHPHQW RSpUp
SDU O¶DSSOLFDWLRQ LQWHUDFWLYH QRQ SHUFHSWLEOH SDU
O¶XWLOLVDWHXU
8QLWp DEVWUDLWH IDFLOLWH OH UHJURXSHPHQW G
XQLWpV
G
LQWHUDFWLRQV
$ILQG¶LQWpJUHUO¶DSSURFKHLQWHUDFWLRQVYHUEDOHVODWkFKH
LQWHUDFWLYHDpWpGpFRPSRVpHFRPPHVXLW
6FpQDULRGpFULWRUJDQLVHHWKLpUDUFKLVHGHVXQLWpV
G
LQWHUDFWLRQ
133
$FWLRQSHUFHSWLEOHSDUO
XWLOLVDWHXUUHSUpVHQWHWRXW
©RXWSXWª GH O¶DSSOLFDWLRQ LQWHUDFWLYH SHUFHSWLEOH
SDUO¶XWLOLVDWHXULPDJHVRQ«
$FWLRQUpDOLVDEOH SDUO
XWLOLVDWHXUUHSUpVHQWH WRXW
©LQSXWª UpDOLVDEOH SDU O
XWLOLVDWHXU VDLVLH FOLF
VRXULVGpSODFHPHQWHQWUpHYRFDOH«
(QILQOHVXQLWpVG
LQWHUDFWLRQRQWpWpLQWURGXLWHV
6\VWqPH G
LQWHUDFWLRQ UHSUpVHQWH OH SOXV KDXW
QLYHDXGXVFpQDULRLQWHUDFWLRQQHO
$FWLYLWpUHJURXSHGHVpFKDQJHVRXGHVDFWLYLWpVGH
SOXVEDVQLYHDXSRXUVDWLVIDLUHXQEXW
(FKDQJHUHJURXSHXQHRXSOXVLHXUVLQWHUYHQWLRQV
'HV pFKDQJHV UpFXUUHQWV QRWLILFDWLRQ VpOHFWLRQ
LQWHUURJDWLRQ« RQW IDLW O
REMHW GH SDWURQV TXL VDWLVIRQW
OD SURSULpWp GH FRPSOpWXGH LQWHUDFWLYH SDU UHWRXU
XWLOLVDWHXU GH O
DSSOLFDWLRQ RX YDOLGDWLRQ GH O
XWLOLVDWHXU
'DQV OD VXLWH GH O
DUWLFOH QRXV Q
XWLOLVHURQV TXH OHV
pFKDQJHVVXLYDQWV
6pOHFWLRQ FI ILJXUH O
XWLOLVDWHXU UHVS
O
DSSOLFDWLRQ UHQVHLJQH XQH SURSULpWp SDUPL GHV
SURSRVLWLRQV VXJJpUpHV SDU O
DSSOLFDWLRQ UHVS
O
XWLOLVDWHXU
1RWLILFDWLRQ O
XWLOLVDWHXU UHVS O
DSSOLFDWLRQ
LQIRUPHO
DSSOLFDWLRQO
XWLOLVDWHXU
&RQIRUPpPHQW j FH TXH QRXV DYRQV YX OHV XQLWpV
G
LQWHUDFWLRQ LFL VFKpPDWLVpHV VHUYHQW XQ EXW GDQV XQH
WKpPDWLTXH GX GRPDLQH GX FDGUH LQWHUDFWLRQQHO /D
VHFWLRQ VXLYDQWH SUpVHQWH GHV RSpUDWHXUV WHPSRUHOV TXL
SHUPHWWHQWGHVFpQDULVHUOHXUVHQFKDvQHPHQWV
6pOHFWLRQ
!!
3URSRVHU
6pOHFWLRQ
&KRLVLU
!!
!!
6DYRLUTXHO 6pOHFWLRQQHU )HHG%DFN
,WHP
,WHP&KRLVLU
GH6pOHFWLRQ
)LJXUH6FKpPDLQWHUDFWLRQQHOGXSDWURQ6pOHFWLRQ
Opérateurs de synchronisation
/HV SURSULpWpV G
HQFKDvQHPHQW GHV XQLWpV G
LQWHUDFWLRQ
VRQWLFLSRUWpHVSDUGHVRSpUDWHXUVXQDLUHVRXELQDLUHVGH
&77GRQWQRXVQHOLVWRQVLFLTX
XQHSDUWLH
8!!8 (QFKDvQHPHQW VXLYL 8 VH UpDOLVH GqV TXH
8HVWWHUPLQpH
>8@2SWLRQDOLWp/DUpDOLVDWLRQGH8HVWRSWLRQQHOOH
8_!8 (QFKDvQHPHQW HQFKkVVp 8 SHXW rWUH
LQWHUURPSXHSDU8PDLVTXDQG8VHWHUPLQH8GRLWVH
UpDFWLYHU GHSXLV O¶pWDW GDQV OHTXHO HOOH pWDLW DX PRPHQW
GHO¶LQWHUUXSWLRQ
8>!8 ,QWHUUXSWLRQ 8 SHXW rWUH LQWHUURPSXH SDU
8PDLV8QHUHSUHQGSDV
8___8(QFKDvQHPHQWFURLVp8HW8VRQWUpDOLVpHV
GDQVQ¶LPSRUWHTXHORUGUHHWHQSDUDOOqOH
8_ _8 ,QGpSHQGDQFH G¶RUGUH 8 HW 8 VRQW
UpDOLVpHV GDQV Q¶LPSRUWH TXHO RUGUH PDLV OH GpEXW GH OD
qPH XQLWp G¶LQWHUDFWLRQ QpFHVVLWH OD ILQ GH OD qUH XQLWp
G¶LQWHUDFWLRQ
8>@8&KRL[6RLW8VRLW8HVWUpDOLVpH
8,WpUDWLRQ8HVWUpSpWpHSOXVLHXUVIRLV
/D GpPDUFKHFRQFHSWXHOOHSRXUFRQVWUXLUHOHVVFpQDULRV
LQWHUDFWLRQQHOVTXHSHUPHWGHVFKpPDWLVHUFHWWHQRWDWLRQ
HVWJXLGpHSDUOHFDGUHLQWHUDFWLRQQHOGDQVOHTXHOV
LQVFULW
V
LQVFULUD O
XWLOLVDWLRQ GH O
DSSOLFDWLRQ $LQVL OH JHQUH
G
DSSOLFDWLRQ HW OH EXW LQWHUDFWLRQQHO SRXUVXLYL
UDWLRQDOLVHQWOHSURFHVVXVGHVFpQDULVDWLRQ
ILLUSTRATION
EDUCATIVE
-
UNE
APPLICATION
LUDO-
&HWWH SDUWLH SUpVHQWH GHV pOpPHQWV GH FRQFHSWLRQ G¶XQH
DSSOLFDWLRQLQWHUDFWLYHPpODQJHDQWOHVJHQUHVOXGLTXHHW
pGXFDWLIRQRXVDYRQVLQWpJUpOHVQRWLRQVLQWURGXLWHV
Le cadre interactionnel
&H SURMHW D GpEXWp DYHF XQH GHPDQGH GH O¶$VVRFLDWLRQ
GHV *XLGHV %DLJQHXUV $QJOR\V 0DvWUHV 1DJHXUV
6DXYHWHXUVVXUODFRPPXQH G¶$QJOHW&HWWHDVVRFLDWLRQ
UpDOLVH FKDTXH DQQpH XQH FRXUWH LQWHUYHQWLRQ SRXU OHV
HQIDQWV GH j DQV GDQV OHV pFROHV G¶$QJOHW VXU OH
OLWWRUDO $WODQWLTXH DILQ GH OHV VHQVLELOLVHU DX[ ULVTXHV
H[LVWDQWV j OD SODJH ORUV GH OD VDLVRQ HVWLYDOH PDL j
VHSWHPEUH /¶DVVRFLDWLRQ VRXKDLWH UHQIRUFHU VRQ DFWLRQ
HQ SHUPHWWDQW DX[ HQIDQWV GH FRQVROLGHU HW G¶pYDOXHU
OHXUVFRQQDLVVDQFHVGHVULVTXHVHQFRXUXVjODSODJHWRXW
HQV¶DPXVDQW1RXVDYRQVDORUVSDUWLFLSpjODFRQFHSWLRQ
GH©6SODVKªXQHDSSOLFDWLRQOXGRpGXFDWLYH
Schéma
Temps
Participa- Domaine Thématiques
Lieu
tionnel
* Heure
ouverture
* Heure
Enfant 820 mn
fermeture
La
10 ans +
et
* Sifflet
plage
«Splash!»
* Zones de Ecole
plage
* Drapeaux
* …
>@ /H JHQUH OXGLTXH TXH QRXV DYRQV VpOHFWLRQQp HVW
EDVp VXU OD GpILQLWLRQ G¶XQH KLVWRLUH OD SUpVHQFH GH
SHUVRQQDJHV O¶H[LVWHQFH G¶XQ EXW TXH OH KpURV GRLW
DWWHLQGUHHWODUHQFRQWUHG¶pSUHXYHVTX¶LOGRLWVXUPRQWHU
©6SODVKª
_ _
_ _
_ _
_ _
6LIIOHW
'UDSHDX[
=RQHV
2XYHUWXUH )HUPHWXUH
)LJXUH6FpQDULRLQWHUDFWLRQQHOVLPSOH
8Q VFpQDULR LQWHUDFWLRQQHO GH FH JHQUH FRPSRUWH GHV
DFWLYLWpVGpPDUFDWLYHVGH GpEXWHW GHILQHWHVWFRPSRVp
G¶DFWLYLWpVGRQWOHVHQFKDvQHPHQWVVRQWFRQWUDLQWVSDUOH
VXFFqVG¶pSUHXYHV
'DQV ©6SODVKªO¶KLVWRLUHVXLWOHFRXUVG¶XQHMRXUQpHj
ODSODJHO¶XWLOLVDWHXU HVWOH SHUVRQQDJH SULQFLSDO GX MHX
XQ 6WDJLDLUH *XLGH %DLJQHXU OD TXrWH TX¶LO SRXUVXLW HVW
G¶REWHQLU OH VWDWXW G¶$VVLVWDQW *XLGH %DLJQHXU OHV
pSUHXYHV TX¶LO GRLW VXUPRQWHU ILJXUH MDORQQHQW OD
MRXUQpH HW VXUPRQWHU OHV pSUHXYHV GpSHQG GH VHV
FRQQDLVVDQFHV VXU OHV QRWLRQV j PDvWULVHU /¶XWLOLVDWHXU
GpSODFH OH VWDJLDLUH 6XU OD SODJH HW GHV pSUHXYHV VH
SUpVHQWHQWjOXLDXFRXUVGHVDYLVLWH
©6SODVKª
!!
!!
2XYULU
!!
)HUPHU
-RXHU
!!
3UpVHQWDWLRQ >'LGDFWLWLHO@
!!
&KRLVLU 6¶pTXLSHU
-RXHXU
!!
>'pFRXYLU
3ODJH@
!!
!!
2XYULU 6XUYHLOOHU3ODJH )HUPHU
%DLJQDGH
%DLJQDGH
)LJXUH6FpQDULRLQWHUDFWLRQQHOGHO¶DSSOLFDWLRQ©6SODVKª
&KDTXH DFWLYLWp VFpQDULVH OD FRPSOpWLRQ GX EXW
But
©&RQVROLGHU HW pYDOXHU OHV FRQQDLVVDQFHV GHV ULVTXHV GH OD
SODJH WRXW HQ MRXDQWª SRXU XQH RX SOXVLHXUV WKpPDWLTXHV
Consolider et
évaluer les
connaissances
des risques
de la plage
tout en
jouant
7DEOH6FKpPDWLVDWLRQGXFDGUHLQWHUDFWLRQQHOGH©6SODVKª
Un genre ludique et un genre pédagogique pour
rationaliser l’interaction
/HVWKpPDWLTXHVGHODSODJHVRQWGHVQRWLRQVLPSRUWDQWHV
VXUOHVTXHOOHVOHV016YHXOHQWTXHSRUWHO¶DSSOLFDWLRQ$
FKDTXH QRWLRQ j DERUGHU SHXW rWUH DVVRFLpH XQH DFWLYLWp
G¶LQWHUDFWLRQ
SpGDJRJLTXH
VDQV
FRQWUDLQWH
G¶HQFKDvQHPHQW GH W\SH SUp UHTXLV HW OH VFpQDULR
LQWHUDFWLRQQHO GH ©6SODVKª SHXW DORUV rWUH IRUPDOLVp
DYHF OH PRGqOH GX SDWURQ GH VFpQDULR PHQX &HWWH
VROXWLRQ ILJXUH SHX DGDSWpH DX SXEOLF HW DX[
FRQWUDLQWHV IL[pHV D pWp HQULFKLH HQ OXL DGMXYDQW OD
GLPHQVLRQ OXGLTXH GRWpH G¶XQH VWUXFWXUH GH JDPHGHVLJQ
134
GX FDGUH LQWHUDFWLRQQHO1RXV SUpVHQWRQV SOXV HQ GpWDLO
O¶DFWLYLWp 6XUYHLOOHU3ODJHSRXUODTXHOOHILJXUHO¶pFKDQJH
LWpUDWLI 'pSODFHU6WDJLDLUH016 SHXW rWUH HQFKkVVp DYHF OHV
DFWLYLWpV 5HQFRQWUHU3ODJLHQV 5HWURXYHU(QIDQW3HUGX RX
6XUYHLOOHU$FWLYLWpVj5LVTXH 'DQV FHWWH GHUQLqUH DFWLYLWp GHV
pFKDQJHV LQGpSHQGDQWV WHOV TXH 3UpYHQLU(QIDQWV6XU+ RX
3UpYHQLU(QIDQWV6XU'LJXH VRQW UpDOLVDEOHV 6XU OD ILJXUH OHV IHXLOOHV GH O¶DUEUH VRQW GHV LQWHUYHQWLRQV WRXWHV OHV
DFWLRQV FRJQLWLYHV QH VRQW SDV SUpVHQWpHV HW O¶DFWLYLWp
5HWURXYHU(QIDQW3HUGXQ¶HVWSDVGpWDLOOpH
&HV HQFKDvQHPHQWV DVVXUHQW TXH OH QRPEUH G¶XQLWpV
G¶LQWHUDFWLRQSRWHQWLHOOHPHQWHQFRXUVVLPXOWDQpPHQWHVW
PLQLPLVp j GHX[ /HV HQFKDvQHPHQWV VRQW GRQF
G¶LQWHUUXSWLRQ VDXI GDQV OH FDV G¶XQ SODJLHQ V¶LO HVW
FURLVpGRQWODTXHVWLRQHVWVXERUGRQQpHHOOHFRPSUHQG
XQHLQGLFDWLRQVXUODORFDOLVDWLRQGHO¶HQIDQWSHUGX
LQWHUDFWDQWV TXH GHV SURSULpWpV GH GpPDUFDWLRQ
FDUDFWpULVHQW FHUWDLQHV XQLWpV G¶LQWHUDFWLRQ TXH OHV
HQFKDvQHPHQWV GHV XQLWpV SHXYHQW rWUH VXERUGRQQpV RX
G¶LQWHUUXSWLRQ HW TXH O¶HQVHPEOH GHV LQWHUDFWLRQV
V¶LQVFULYHQW GDQVXQFDGUHLQWHUDFWLRQQHOHWSDUWLFLSHQWj
XQEXWLQWHUDFWLRQQHO
6XUYHLOOHU3ODJH
___
___
'pSODFHU
6WDJLDLUH016
5HQFRQWUHU
3ODJLHQV
___
5HWURXYHU
6XUYHLOOHU
(QIDQW3HUGX $FWLYLWpVj5LVTXH
!!
0RGLILHU
)HHG%DFN 5pSRQGUH
'pSODFHPHQW 'pSODFHPHQW 4XHVWLRQ
!!
!!
3RVHU4XHVWLRQ
&KRLVLU
!!
!!
&RQQDvWUH
5pSRQVH
_ _
3UpYHQLU
(QIDQWV6XU+
6pOHFWLRQQHU
5pSRQVH
3UpYHQLU(QIDQWV
6XU'LJXH
!!
(QIDQWV 6LIIOHU
6LIIOHU
(QIDQWV
(QIDQWV6XU+ 6RUWHQW+ (QIDQWV 'HVFHQGHQW
6XU'LJXH 'H'LJXH
)HHG%DFN
6pOHFWLRQ
)LJXUH0RGqOHGHO¶DFWLRQ©6XUYHLOOHUSODJHª
Le système de place
'DQV O¶DFWLYLWp ©6XUYHLOOHU3ODJHª GHV DYDWDUV RQW GHV
U{OHV TXL FRQWUDLJQHQW OHXU pQRQFLDWLRQ OD WDEOH SURSRVH GHV pQRQFLDWLRQV SRVVLEOHV SRXU FKDFXQ GHV
SHUVRQQDJHVTXLGLIIqUHVHORQOHXUSODFHYLVjYLVGHOHXU
LQWHUORFXWHXU$LQVLOHVWDJLDLUHXWLOLVHUDXQHpQRQFLDWLRQ
GpFODUDWLYH OH FKHI GH SRVWH VRQ VXSpULHXU XWLOLVDQW OH
SOXV VRXYHQW XQH pQRQFLDWLRQ LPSpUDWLYH ORUVTX¶LO
V¶DGUHVVHjOXL /D PqUHXWLOLVHUDDYHFOHJXLGHEDLJQHXU
XQHpQRQFLDWLRQLQWHUURJDWLYHORUVTX¶HOOHOXLGHPDQGHGH
O¶DLGHDORUVTX¶HOOHXWLOLVHUDXQHpQRQFLDWLRQH[FODPDWLYH
SRXUOHUHPHUFLHU
SurveillerPlage Rôle
Enfant 8-10 Stagiaire
ans
MNS
Chef
de
poste
«Splash!»
Mère
Enonciation
Déclaratif
Impératif,
Déclaratif
Traits
Personnage
principal
PNJ
Exclamatif,
Interrogatif
PNJ
Surfer Interrogatif
PNJ
1RXV DYRQV DORUV GpJDJp GH FHWWH DSSURFKH GHV
UHFRPPDQGDWLRQV j GHVWLQDWLRQ GHV FRQFHSWHXUV
G
DSSOLFDWLRQV LQWHUDFWLYHV ,O HVW QRWDEOH TXH FHV
UHFRPPDQGDWLRQV VRQW FRQIRUPHV DX[ SURSULpWpV j
VDWLVIDLUH GDQV OHV JXLGHV HUJRQRPLTXHV >@ >@ &HWWH
FRQVLVWDQFH HVW XQ pOpPHQW HQFRXUDJHDQW TXDQW j QRWUH
GpPDUFKH &HWWH GHUQLqUH DSSRUWH GHV pOpPHQWV GH
FRQVWUXFWLRQ IpGpUpV SDU OH JHQUH GDQV OH VFpQDULR
LQWHUDFWLRQQHO TXL LQWqJUH GH IDoRQ FRQVLVWDQWH FHV
SURSULpWpV HUJRQRPLTXHV GqV OHV SUHPLqUHV pWDSHV GH OD
FRQFHSWLRQ
/H VFpQDULR LQWHUDFWLRQQHO RUJDQLVH GHV XQLWpV
G¶LQWHUDFWLRQ FDSDEOHV G¶KpEHUJHU HW GH VXSSRUWHU GHV
DFWLYLWpV SURSUHV DX JHQUH GH O¶DSSOLFDWLRQ &KDFXQH GH
FHVDFWLYLWpVWUDLWHGHWKpPDWLTXHVGXGRPDLQHHWVHUWXQ
EXWLQWHQWLRQGHO¶DXWHXUDWWHQWHGXUpFHSWHXU
7
7DEOH6\VWqPHGHSODFHSDUWLHOGH6XUYHLOOHU3ODJH
CONCLUSION
/H QRPEUH FURLVVDQW G¶DSSOLFDWLRQV LQWHUDFWLYHV
DX[TXHOOHV QRXV VRPPHV FRQIURQWp GDQV OH TXRWLGLHQ
FRQGXLW j SODFHU OH SUREOqPH GH O
DFFHSWDELOLWp GH FHV
V\VWqPHVFRPPHXQSRLQWGHSOXVHQSOXVFULWLTXH
1RXV DYDQoRQV O¶LGpH TXH OD SURGXFWLRQ GDQV XQ JHQUH
GRQQpLPSOLTXHGHVFDQRQVLQWHQWLRQQHOVHWVWUXFWXUHOVGH
O¶LQWHUDFWLRQ GRQW OH UHVSHFW SDU OHV FRQFHSWHXUV IDFLOLWH
O¶DFFHSWDELOLWpVRFLDOHHWSUDWLTXHHWGRQFODSHUIRUPDQFH
GH O¶LPSDFW GX SURGXLW UpVXOWDQW (Q HIIHW OH JHQUH HVW
LQKpUHQWjWRXWHDFWLYLWpGHFRPPXQLFDWLRQLOHVWSRUWHXU
G¶XQH LQWHQWLRQ HW GpILQLW GHV VWUXFWXUHV GH
FRPPXQLFDWLRQSDUWDJpHVSDUO¶pPHWWHXUHWOHUpFHSWHXU
3RXU IDFLOLWHU OD IRUPDOLVDWLRQ GHV VWUXFWXUHV GH
FRPPXQLFDWLRQTXLFDUDFWpULVHQWXQJHQUHG¶DSSOLFDWLRQ
QRXV DYRQV XWLOLVp OH SRLQW GH YXH GHV LQWHUDFWLRQV
YHUEDOHV&HSRLQWGHYXHQRXVLQGLTXHHQWUHDXWUHVTXH
OHV LQWHUDFWLRQV V¶RUJDQLVHQW HQ QLYHDX[ KLpUDUFKLTXHV
TX¶XQ V\VWqPH GH SODFH LQIOXHQFH OHV LQWHUYHQWLRQV GHV
6XU OD EDVH G
REVHUYDWLRQV HPSLULTXHV QRXV DYRQV
FRQVWDWpODSUpVHQFHGHSURSULpWpVVLPLODLUHVjFHOOHVGHV
LQWHUDFWLRQV YHUEDOHV GDQV OHV DSSOLFDWLRQV LQWHUDFWLYHV
(QVXLWHQRXVDYRQVUDSSURFKpOHVQRWLRQVG¶LQWHQWLRQGH
O¶pPHWWHXU HW G¶DWWHQWH GX UpFHSWHXU TXL GpOLPLWHQW OH
FDGUH GH WRXW JHQUH GH OD QRWLRQ GH EXW LQWHUDFWLRQQHO
LQWURGXLWHSDUOHVLQWHUDFWLRQVYHUEDOHV&HWWHRSpUDWLRQ
FRPELQpH DYHF OD VLPLOLWXGH HQWUH OHV LQWHUDFWLRQV
YHUEDOHVG¶XQHSDUWHWOHVLQWHUDFWLRQVHQWUHXWLOLVDWHXUHW
DSSOLFDWLRQ LQWHUDFWLYH G¶DXWUH SDUW QRXV D FRQGXLW j
IDLUH SRUWHU OH JHQUH G¶XQH DSSOLFDWLRQ SDU OD KLpUDUFKLH
GHVXQLWpVG¶LQWHUDFWLRQVTXLODFRPSRVHQW
31-3HUVRQQDJH1RQ-RXHXU
135
Genre
d’application
SIW,
Encyclopédique
Pédagogique
Ludique
Narrative
Unités
Schéma
d’interaction interactionnel
Nœud, Menu,
Schéma
VisiteGuidée … navigationnel
Exercice,
Learning
Cours …
scenario
Epreuve,
Game design
Niveau …
Acte, Scène …
Scénario
7DEOH3UpVHQFHGXVFKpPDLQWHUDFWLRQQHO
&HWWH DSSURFKH FRQFHSWXHOOH HVW FRKpUHQWH DYHF OHV
VFKpPDV SUpFRQLVpV GDQV GHV PpWKRGHV GH FRQFHSWLRQ
WDEOH 7RXWHIRLV OH IRFXV XWLOLVp SDU FHV PpWKRGHV
SULYLOpJLH XQ SRLQW GH YXH SDUWLFXOLHU OHV GRQQpHV
500>@RX:HE0/>@O¶pGXFDWLRQ0,6$>@OH
MHX >@ OD WkFKH &77 >@« (Q PrPH WHPSV FHV
PpWKRGHV RQWHQFRPPXQG¶DERXWLUVXUGHVDSSOLFDWLRQV
QpFHVVDLUHPHQW SRUWpHV SDU OHV LQWHUDFWLRQV (Q FH VHQV
QRWUH WUDYDLO FHQWUp LQWHUDFWLRQV VRXKDLWH HQULFKLU OHV
PpWKRGHV GHFRQFHSWLRQH[LVWDQWHVHQYDORULVDQWDXSOXV
W{W GDQV OH SURFHVVXV GH FRQFHSWLRQ OHV SURSULpWpV GHV
LQWHUDFWLRQV
'DQV OH PrPH RUGUH G¶LGpH >@ PRGpOLVH GDQV GHV
%L3DUWLWH6WDWH&KDUWO¶LQWHUDFWLRQDYHFGHX[W\SHVG¶pWDWV
FHX[ UHSUpVHQWDQW OHV LQWHUYHQWLRQV GH O¶XWLOLVDWHXU HW
FHX[ UHSUpVHQWDQW OHV LQWHUYHQWLRQV GH OD PDFKLQH &H
WUDYDLO V¶LQWpUHVVH VSpFLILTXHPHQW DX[ DSSOLFDWLRQV
LQWHUDFWLYHV EDVpHV VXU O¶REWHQWLRQ HW OH UHPSOLVVDJH GH
IRUPXODLUHV DORUV TXH QRWUH FRQWULEXWLRQ SOXV
JpQpUDOLVWHQHVHFRQWUDLQWSDVjXQJHQUHG¶DSSOLFDWLRQ
/¶pTXLSH GH FRQFHSWLRQ SRXU O¶H[SpULPHQWDWLRQ
©6SODVKª pWXGLDQWV HQ LQIRUPDWLTXH HW PXOWLPpGLD
GLVSRVDLHQW GHV UHFRPPDQGDWLRQV GH OD QRWDWLRQ &77
PRGLILpH HW G¶XQ GRFXPHQW GH UpIpUHQFH VXU OHV JHQUHV
pGXFDWLI HW OXGLTXH 'HV DXWHXUV GH O¶DUWLFOH RQW REVHUYp
O¶XVDJH GH FHWWH OLDVVH GH UHVVRXUFHV DX FRXUV GX SURMHW
/D GLIIpUHQFLDWLRQ GHV JHQUHV D FODLUHPHQW pWp SHUoXH HW
UHVSHFWpH WRXW DX ORQJ GX SURMHW GH PrPH TXH OH IRFXV
LQWHUDFWLRQ DYHF VHV QLYHDX[ GH GpFRPSRVLWLRQ /HV
LQWHQWLRQVOXGLTXHHWSpGDJRJLTXHRQWV\VWpPDWLTXHPHQW
pWp FRQVLGpUpHV GDQV FKDFXQH GHV XQLWpV G¶LQWHUDFWLRQ
3DU FRQWUH OD QRWDWLRQ &77 D SUpVHQWp GHV SUREOqPHV
TXDQW j VD PDvWULVH /¶XWLOLVDWLRQ GX SURGXLW IHUD O¶REMHW
G¶XQHpYDOXDWLRQHQGpEXWG¶pWp
$FWXHOOHPHQWQRXVWUDYDLOORQVDYHFXQHDXWUHpTXLSHjOD
FRQFHSWLRQ GH ©6SODVK:HEª GH PrPH GRPDLQH HW
WKpPDWLTXHVPDLV GXJHQUHHQF\FORSpGLTXH1RXVDYRQV
IRXUQL XQH OLDVVH VLPLODLUH DFFRPSDJQpH G¶H[HUFLFHV GH
SULVH HQ PDLQ GH OD QRWDWLRQ &77 /¶REMHFWLI GH FHWWH
VHFRQGHH[SpULPHQWDWLRQHVWGHFRQVROLGHUO¶DSSURFKHHW
G¶DSSUpFLHUVRQDFFHSWDWLRQ
BIBLIOGRAPHIE
$GDPV ( 5ROOLQJV $ 2Q *DPH 'HVLJQ 1HZ
5LGHUV3XEOLVKLQJ,QGLDQDSROLV
%DVWLHQ -0& 6FDSLQ ' (UJRQRPLF &ULWHULD IRU
WKH (YDOXDWLRQ RI +XPDQ&RPSXWHU LQWHUIDFHV
,QVWLWXW1DWLRQDOGHUHFKHUFKHHQLQIRUPDWLTXHHWHQ
DXWRPDWLTXH)UDQFH
&DQYDW . (QVHLJQHU OD OLWWpUDWXUH SDU OHV JHQUHV
3RXU XQH DSSURFKH WKpRULTXH HW GLGDFWLTXH GH OD
QRWLRQ GH JHQUH OLWWpUDLUH &ROOHFWLRQ 6DYRLUV HQ
3UDWLTXH'H%RHFN8QLYHUVLWp%UX[HOOHV
&HUL 6 )UDWHUQDOL 3 %RQJLR $ :HE 0RGHOLQJ
/DQJXDJH :HE0/ D 0RGHOLQJ /DQJXDJH IRU
'HVLJQLQJ :HE 6LWHV ,Q 3URFHHGLQJV RI WKH WK
,QWHUQDWLRQDO ::: &RQIHUHQFH 0D\ $PVWHUGDP
&KDQGOHU'$QLQWURGXFWLRQWRJHQUH7KHRU\
KWWSZZZDEHUDFXNPHGLD'RFXPHQWVLQWJHQUHLQ
WJHQUHKWPO
'H OD 7HMD . /XQGJUHQ&D\URO 3DTXHWWH *
7UDQVSRVLQJ 0,6$ /HDUQLQJ 6FHQDULRV LQWR ,06
8QLWV RI /HDUQLQJ -RXUQDO RI (GXFDWLRQDO
WHFKQRORJ\ DQG 6RFLHW\ (76 6SHFLDO LVVXH RQ
/HDUQLQJ'HVLJQ-DQXDU\
136
'UDKHLP ' :HEHU * 0RGHOOLQJ IRUPEDVHG
LQWHUIDFHV ZLWK ELSDUWLWH VWDWH PDFKLQHV ,QWHUDFWLQJ
:LWK&RPSXWHUV9RO1ƒSS
)HUEHU - /HV V\VWqPHV PXOWLDJHQWV 9HUV XQH
LQWHOOLJHQFHFROOHFWLYH,QWHUeGLWLRQV3DULV
*DOLEHUW 2 ,OORX] * 5RVVHW 6 5LWHO $Q 2SHQ
'RPDLQ+XPDQ&RPSXWHU 'LDORJ 6\VWHP ,Q
3URFHHGLQJV RI ,QWHUVSHHFK
6HSWHPEHU ±
/LVERDSS
,VDNRZLW] 7 6WRKU ($ DQG %DODVXEUDPDQLDQ 3
500 D PHWKRGRORJ\ RI VWUXFWXUHG K\SHUPHGLD
GHVLJQ &RPPXQLFDWLRQV RI WKH $&0 9RO 1R
SS
,62 ,QIRUPDWLRQ 3URFHVVLQJ 6\VWHPV 2SHQ
6\VWHPHV ,QWHUFRQQHFWLRQ /2726 $ IRUPDO
'HVFULSWLRQ %DVHG RQ 7HPSRUDO 2UGHULQJ
2EVHUYDWLRQDO %HKDYLRXU ,62,6 &HQWUDO
6HFUHWDULDW
.HUEUDW2UHFFKLRQL & /HV LQWHUDFWLRQV YHUEDOHV
7RPH,,$UPDQG&ROLQ/LQJXLVWLTXH3DULV
/DWDS\ 0 'DJRUUHW 3 /RSLVWpJX\ 3 /D
FRRUGLQDWLRQ LQWUDSURFHVVXV VHV LQWHUDFWLRQV
YHUEDOHV,Q$FWHVGXFRQJUqV0RGqOHV)RUPHOVSRXU
O¶,QWHUDFWLRQ 0),¶ 0DL /LOOH &pSDGXqV(GLWLRQV7RXORXVHSS
/DWDS\ 0 $XJPHQWHU O¶DFFHSWDELOLWp GHV
DSSOLFDWLRQV LQWHUDFWLYHV 9DORULVHU OD GLPHQVLRQ
©JHQUHª ,Q$FWHVGXFRQJUqV ,QIRUVLG 0DL
%LDUULW]SS
/DWDS\ 0 /RSLVWpJX\ 3 'DJRUUHW 3 *HQUH
3RWHQWLDOLWLHV )RU ,QWHUDFWLYH $SSOLFDWLRQV 'HVLJQ
DQG $FFHSWDWLRQ ,Q 3URFHHGLQJV RI $&0 1RUGLF
&RQIHUHQFH RQ &RPSXWHU +XPDQ ,QWHUDFWLRQ
QRUGL&+,¶ 2FWREHU 7DPSHUH
$&03UHVV1HZ<RUNSS
/XQGEHUJ - $UYROD 0 +ROPOLG 6 *HQUHV 8VH
4XDOLWLHV DQG ,QWHUDFWLYH $UWLIDFWV SRVLWLRQ SDSHU
IRU+&,:RUNVKRS%DWK
1LHOVHQ - 8VDELOLW\ (QJLQHHULQJ $FDGHPLF 3UHVV
%RVWRQ0$
1RJLHU -) (UJRQRPLH GX ORJLFLHO HW GHVLJQ
ZHE(GLWLRQV'XQRGqPHpGLWLRQ3DULV
0D]LqUH ) /¶DQDO\VH GX GLVFRXUV (GLWRQV 38)
3DULV
3DWHUQz ) &RQFXU7DVN7UHHV $Q (QJLQHHUHG
1RWDWLRQ IRU 7DVN 0RGHOV &KDSWHU LQ 'LDSHU
' 6WDQWRQ 1 (GV 7KH +DQGERRN RI 7DVN
$QDO\VLV IRU +XPDQ&RPSXWHU ,QWHUDFWLRQ
/DZUHQFH (UOEDXP $VVRFLDWHV 0DKZDK SS
3HPEHUWRQ / *HQUH DV D 6WUXFWXULQJ &RQFHSW IRU
,QWHUDFWLRQ 'HVLJQ 3DWWHUQ SRVLWLRQ SDSHU IRU WKH
+&,6,*:RUNVKRSRQSDWWHUQV/RQGRQ
:ULJKW 3 DQG )LQOD\ - 8QGHUVWDQGLQJ 8VHU
([SHULHQFH /LWHUDU\ $QDO\VLV PHHWV +&, SRVLWLRQ
SDSHUIRU+&,
3KLOLSSRQ 0 0LOOH $ &DSODW * $LGH j
O
XWLOLVDWHXUVDYRLUTXDQGLQWHUYHQLU,Q $FWHVGHOD
&RQIpUHQFH )UDQFRSKRQH VXU O
,QWHUDFWLRQ +RPPH
0DFKLQH ,+0¶ ± VHSWHPEUH 7RXORXVH$&03UHVVSS
;XHUHE $ &DHOHQ - 8Q PRGqOH G¶LQWHUSUpWDWLRQ
SUDJPDWLTXH HQ GLDORJXH KRPPHPDFKLQH EDVp VXU
OD 6'57 ,Q $FWHV GH 7$/1¶ ;,qPH &RQIpUHQFH
VXUOH7UDLWHPHQW$XWRPDWLTXHGX/DQJDJH1DWXUHO
DYULO)qVSS
5RXOHW ( $FWHV GH ODQJDJH FRQQHFWHXUV
SUDJPDWLTXHVHWVWUXFWXUHGXGLVFRXUV)HXLOOHWV
SS
137
Supports pour la prise en compte des experts et utilisateurs dans le développement de Systèmes Interactifs
d’Aide à la Décision
Sophie Lepreux
LAMIH – UMR CNRS 8530
Université de Valenciennes et du Hainaut-Cambrésis,
Le Mont-Houy
59313, Valenciennes Cedex 9, France
[email protected]
RESUME
systèmes doivent permettre à l’utilisateur de mesurer les
conséquences de ses choix en essayant de ne pas
l’induire en erreur. Pour cela, il doit pouvoir comparer
les diverses options pour pouvoir faire le choix le plus
approprié. Des outils d’analyse lui sont alors nécessaires.
Ces outils peuvent être de natures très différentes
(simulateur,
système
expert,
recherche
opérationnelle,…) et apportent tous un indicateur de
décision. Le système doit alors fournir une interface ou
des interactions permettant à l’utilisateur d’utiliser
l’ensemble de ces outils et d’analyser l’ensemble des
résultats afin de prendre une décision. Nous nous situons
ici dans le processus de décision basé sur la
connaissance dans le modèle de Rassmussen [20].
La prise de décision est toujours un problème d’actualité
et le développement de Systèmes Interactifs d’Aide à la
Décisison (SIAD) reste complexe. Les approches de
développement classiques ne sont pas suffisantes pour
être applicables aux SIAD. Nous proposons une
approche mixant les principes des travaux de différents
domaines et visant à mieux prendre en compte les
facteurs humains dans la conception de SIAD. Des
moyens permettant d’impliquer les acteurs sont proposés
puis évalués par l’application de cette approche pour le
développement d’un SIAD dans le domaine ferroviaire.
Les premières évaluations avec les utilisateurs
permettent de montrer l’apport des moyens proposés à la
fois d’un point de vue ergonomique mais aussi d’un
point de vue de l’aide dans leur processus de prise de
décision. Des perspectives dans le domaine des IHM
sont alors introduites.
Les IHM dans les systèmes d’aide à la décision ont déjà
fait l’objet de recherches. Par exemple, Chen [6] a
cherché à améliorer les IHM pour les systèmes experts.
en connectant chaque composant du système expert avec
des interfaces homme-machine pour apporter une
meilleure information à l’utilisateur. Pour cela, il
propose un composant wrapper d’interface. Chaque
interface peut être spécifique au composant qu’elle «
emballe ». Les utilisateurs experts n’ont pas
nécessairement besoin des interactions fournissant plus
de précision sur le fonctionnement tandis que les novices
pourront les utiliser pour mieux comprendre le
fonctionnement du système. De cette manière,
l’utilisateur peut suivre le processus du système et donc
avoir plus confiance dans ses résultats. Ces interfaces
peuvent également permettre aux utilisateurs de mieux
vérifier les bases de connaissance et identifier les
incompatibilités. Le principe adopté par Chen est
intéressant car il montre l’intérêt d’associer des
interfaces utilisateur à chaque composant métier. Pour
nous, tous les composants métiers sont considérés
comme possédant une interface utilisateur.
MOTS CLES : Templates, Patrons, Systèmes Interactifs
d’Aide à la Décision (SIAD), Approche de
développement, IHM.
ABSTRACT
Decision making is always a topical problem. The
existing classical development approaches are not
sufficient to DSS development. This paper proposes a
mixed approach from several domains which aims at
better taking account of human factors. Means as
templates allowing to increase the actors implication are
proposed. This approach is applied to DSS development
in railway investments. The first evaluations with the
end users allow to validate the means. The evaluations
are oriented on ergonomics criteria and on decision
making process support. Conclusion and perspectives in
HCI domain are presented.
KEYWORDS: Templates, Patterns, Decision Support
System (DSS), Development approach, HCI.
Nos travaux précédents ont consisté à proposer une
amélioration à une démarche de développement de SIAD
permettant de mieux prendre en compte l’utilisateur en
phase d’analyse [16]. Cette méthode nous semble encore
insuffisante c’est pourquoi ce papier propose une
INTRODUCTION
Les systèmes interactifs d’aide à la décision sont le plus
couramment des systèmes décideurs. Pour nous, ces
139
démarche plus complète pour intégrer l’ensemble des
acteurs dans le cycle de développement.
maine des IHM qui n’est pas basé sur le modèle en V est
le modèle en étoile [13]. Il a l’intérêt de placer
l’évaluation au centre du processus. Cela permet de réellement intégrer les utilisateurs au centre du processus par
le biais des évaluations. Cependant, ce cycle n’est pas
suffisamment complet pour un développement logiciel.
Le cycle en V a été enrichi dans le domaine de la réutilisation pour intégrer la gestion des composants. Le cycle
en X résultant intègre des étapes d’utilisation et de fabrication et stockage des composants [8]. Dans le domaine
de la gestion des connaissances, le modèle MODESTI
couple les principes des IHM et l’intégration des experts
[10]. Il propose trois phases descendantes en parallèle,
une dédiée à l’expert, une à l’utilisateur, et une comportant les étapes classiques du génie logiciel. Cependant il
ne prend pas en compte la réutilisabilité. L’ensemble des
modèles offre des principes intéressant selon les besoins.
Ils ne sont pas suffisants pour le développement d’un
SIAD tel que nous l’avons défini. C’est pourquoi la section suivante présente un modèle proposé pour le développement de SIAD.
Dans la première section, nous présenterons les modèles
de divers domaines en précisant leurs avantages et
inconvénients pour le dévelopement d’un SIAD.
L’approche de développement de SIAD, et en particulier
la méthode intégrant des moyens d’assister les experts et
les utilisateurs lors de la phase d’analyse, sera présentée
en deuxième section. La troisième section présentera une
étude de cas dans le domaine ferroviaire, basée sur
l’approche, où l’utilisation des supports proposés sera
illustrée. La quatrième section présente les résultats des
évaluations réalisées par des experts sur l’étude de cas.
Nous pourrons alors conclure et présenter les
perspectives de ces travaux.
TRAVAUX RELATIFS
Malgré l’importance des SIAD, il n’existe pas
d’approche de développement générique et spécifique
aux SIAD. Les méthodes existantes dans ce domaine
sont souvent spécifiques à un domaine d’application [19]
ou centré sur un moyen de calcul (RO, IA, simulation…)
[18]. Nous nous sommes donc intéressés aux méthodes
« génériques » issues d’autres domaines. Le modèle en
V est le plus connu des modèles du génie logiciel [14]. Il
structure les étapes en deux phases : une descendante
pour la conception et une ascendante pour l’intégration
et l’évaluation. Les moyens d’évaluation sont définis
dans la phase descendante. Ce modèle n’est pas suffisamment spécifique pour permettre un développement
efficace d’un SIAD. Ce modèle est un pilier du génie
logiciel ; il a souvent été réutilisé et adapté dans d’autres
domaines, comme nous le verrons dans la fin de cette
section. Il existe de nouvelles méthodes proposées dans
le génie logiciel tels que RUP et eXtreme Programming
(XP). Cette dernière est strictement itérative ; les développements s’effectuent selon un système d’itérations
imbriquées de courtes durées comprenant les itérations
de développement et les itérations de livraison [7]. Certaines pratiques sont très intéressantes comme « assurer
un feedback constant » mais qui amène des principes tel
que le développement piloté par les tests. Or ce principe
est difficile à mettre en œuvre dans le cadre de développement de systèmes tels que des SIAD. Selon nous, la
phase d’analyse est indispensable pour ce type de système comme nous le verrons par la suite. Un autre défaut, à notre avis, de cette méthode pour le développement de SIAD vient de sa particularité qui consiste à refuser toute rédaction de documentation d’analyse et de
conception. Le cycle en V a été utilisé dans le domaine
des IHM puisqu’il a inspiré le modèle en U [1, 16]. Ce
dernier modèle intègre des étapes centrées sur les facteurs humains et a par la suite été enrichi d’étapes permettant de mieux intégrer les experts dans la phase descendante. Ce modèle commence à s’approcher du domaine des SIAD mais il n’est pas assez complet en terme
de gestion des connaissances. Un autre modèle du do-
Activités issues du GL,
des IHM, des SBC
Exploitation
Maintenance
Faisabilité
Activités issues du GL
Activités issues du GL,
des IHM
Activités issues de la
réutilisation
Evaluation
technique et
évaluation par les
utilisateurs
Phase
descendante
de conception
Phase
ascendante
d’évaluation
Recherche /conception
des composants
Développement du SIAD
Validation des
composants
Dépôt de composants
Figure 1 : Le modèle d’ADESIAD, vue globale
APPROCHE DE DEVELOPPEMENT DE SIAD
CYCLE DE DEVELOPPEMENT
Identification du
problème
ca
ur
a te
oth
é
ilis
Ex
pe
rt
Ut
Bib
li
me
no
Erg
o
ien
ticie
itic
ma
Info
r
Dir
ec
Phases de
développement
Co
gn
tio
n
n
Acteur
ire
L’approche proposée se compose d’un modèle, d’une
méthode et d’une architecture. Le modèle est une
combinaison des cycles en V, en U et en étoile, en X et
MODESTI. Ce cycle se veut également itératif. Le cycle
proposé, vu en Figure 1, permet d’impliquer les
utilisateurs et experts lors des phases (1) descendante
dite de conception, (2) ascendante qui comprend
l’intégration et les évaluations techniques et terminales
(ou sommatives) et (3) centrale dite d’évaluations
formatives. Ce modèle est plus développé dans [15].
Légende
Spécification
Contribution majeure
(rôle moteur)
Conception
Contribution mineure
(rôle participatif)
Réalisation
Se tient informé
Validation
Figure 2 : Acteurs du développement
140
Les acteurs agissant dans ce modèle sont présentés en
Figure 2. Ce schéma est issu des travaux de [5, 10] auquel nous avons ajouté le bibliothécaire. On retrouve
alors le groupe de pilotage qui définit les finalités et arrête des stratégies pour l’ensemble des aspects du projet.
Ce groupe a une fonction de contrôle et de coordination.
Le groupe de développement est composé d’un cogniticien, d’un informaticien, d’un ergonome et d’un bibliothécaire. Le cogniticien recueille et analyse les connaissances expertes, élabore les modèles. La réalisation est à
la charge de l’informaticien qui définit les orientations
pour la réalisation physique et concrétise le système.
L’ergonome analyse les besoins de l’utilisateur. Le bibliothécaire est chargé de fournir les documents aux autres intervenants et de classer les nouveaux documents
établis de manière à avoir un suivi et un archivage de
toutes les décisions et actions.
entre deux problèmes ; elles sont figurées dans le champ
« problèmes connexes » qui est optionnel. Pour terminer,
le champ « analyse » permet de renseigner les méthodes
de traitement qui permettent d’analyser ou de résoudre le
problème. Si des solutions sont d’ores et déjà connues, elles figurent dans le champ « solution ». Le template fournit ainsi un support réutilisable par tous et une base de discussion. Il peut toutefois être adapté en fonction des attentes et des remarques des experts et du domaine. Nous verrons par la suite que les patrons instanciés à partir de ce
template serviront à la description des composants métier
associés mais aussi à la présentation des informations dans
certaines interfaces utilisateur du SIAD.
Un exemple est donné pour le problème de déplacement
en Figure 4. Les sous-problèmes ou problèmes pères
sont représentés par de simples flèches. De la même manière, il est possible d’enrichir le template et la notation
par exemple par des notations « ET » et « OU ». Des
exemples intéressants existent dans les travaux de [4].
Ce template permet de supporter trois des cinq étapes du
processus décisionnel proposé par [2] qui sont la décomposition du problème en sous-problèmes,
l’identification des options et la spécification des facteurs et autres informations pertinentes. La quatrième
étape consiste à évaluer l’ensemble des options. Cette
étape est supportée en partie par le champ « analyse »
qui permet de donner une piste pour traiter le problème.
Cependant, ce champ ne permet pas à l’utilisateur
d’effectuer l’analyse. Ce champ « analyse » permet
d’identifier les composants métier qui seront utilisés par
les utilisateurs et experts finaux. Ces composants métier
sont spécifiés en phase de spécification à l’aide d’un
template proposé par la méthode et vu en Figure 5. On
retrouve dans ce template un champ « nom », l’intention
qui correspond à l’action que devra accomplir le composant, le « contexte » dans lequel il s’applique et les problèmes qu’il résout, les « données d’entrée obligatoires »
qui devront être renseignées par l’utilisateur, les « données d’entrée facultatives » qui ne sont pas indispensables au fonctionnement de l’outil mais qui peuvent permettre de fournir plus de précision, les « données de sortie » correspondent au résultat attendu suite à
l’utilisation de ce composant et enfin le champ « solution » permet de fournir une description succincte ou un
algorithme plus précis. Ces composants sont ensuite recherchés dans la mémoire de l’entreprise ou à l’extérieur
pour être intégrés au SIAD. Ces composants métier peuvent être intégrés sous la forme de composant ou de service. Ce choix doit être fait par l’équipe. La Figure 6
présente les définitions des composants métier qui devraient être utilisés pour le problème de la recherche
d’un moyen de transport privé et personnel. La dernière
étape du processus de décision est la promulgation de la
décision avec examen des résultats. Cette étape est supportée par les IHM du SIAD qui présentent les résultats.
Figure 3 : Template pour la description d’un problème
La méthode permet de détailler l’ensemble des étapes du
modèle. Elle introduit la notion de patron dans chacune
des étapes de la phase descendante de conception. Ces
patrons sont utilisés pour la réutilisation des connaissances, à la fois expertes (métier) et informatiques avant de
devenir des composants réutilisables. Ces patrons sont
un des moyens introduits dans le cycle pour impliquer
les utilisateurs et décideurs et pour permettre de capitaliser les connaissances relatives au problème. Nous appelons template la structure du patron (les champs sont à
renseigner) et patron une instance du template dont les
champs sont renseignés. Un exemple de template est
fourni en Figure 3. Ce template sert de support aux experts, utilisateurs et ergonome(s) pour la définition des
problèmes métier relatifs au SIAD. Le template est inspiré des canevas proposés par [11]. De manière à utiliser et
partager cette connaissance, chaque problème doit porter
un nom. Une définition doit y être associée pour permettre à d’autres personnes non initiées de comprendre le
problème. Le problème est toujours lié à des entités qui
sont précisées dans le champ « attribut ». Le but du template est de relier les problèmes entre eux ; pour cela les
champs « problème père » et « sous-problème » assurent
la navigabilité. Enfin, d’autres relations peuvent exister
141
Figure 4 : Exemple de décomposition d’un problème de déplacement, mise en forme à l’aide du patron de problème
principal qui est l’investissement en infrastructure. La
décomposition du problème a été validée après trois tentatives ; les rémises en cause ont été facilitées par les
évaluations formatives placées au centre du modèle et
faisant intervenir l’ensemble des acteurs.
Figure 5 : Template pour la définition des composants
L’architecture d’ADESIAD permet de situer les éléments par rapport aux couches interface, spécifique au
système, spécifique au domaine infrastructure et plateforme logicielle. Elle n’est pas développée ici par manque de place, une description se trouve dans [15]
APPLICATION A L’AIDE A LA DECISION DANS LES
INVESTISSEMENTS FERROVIAIRES
L’approche proposée dans la section précédente a été
appliquée au développement d’un SIAD dans le domaine
ferroviaire. Le SIAD a pour objectif d’aider la prise de
décision dans les investissements dans les infrastructures
ferroviaires. Le développement du SIAD a suivi le cycle
proposé par l’approche. Dans la phase descendante (dite
de conception) et conformément à la méthode, les templates ont été utilisés pour la décomposition du problème
Figure 6 : Composants associés au sous-problème de recherche d’un moyen de transport privé et personnel
142
Figure 7 : Décomposition du problème d’investissement dans les infrastructures ferroviaires
Le problème d’investissement a été scindé en trois sousproblèmes dont un est relatif à l’analyse de
l’infrastructure par rapport au trafic ferroviaire, un à
l’analyse de l’infrastructure seule et un à l’analyse du
trafic seul. Ceux-ci ont été décomposés à leur tour pour
donner l’arborescence vue en Figure 7 (Seuls les noms
de problèmes sont indiqués). Les patrons du problème
principal et d’un de ses sous-problèmes feuilles sont visibles de manière plus complète en Figure 8 et 9. On remarque que le problème de capacité en ligne, vu en Figure 9, indique quatre analyses possibles. Un composant, associé à une de ces analyses et qui consiste à insérer un type de sillon, est présenté en Figure 10. Ce composant devra être développé, intégré à la base de composant et pourra ensuite être intégré lors de la phase ascendante en tant que composant métier. Une partie des interactions homme-machine a été modélisée par un diagramme état-transition issu de UML, cf. Figure 11. Cette
modélisation,
réalisée
en
présence
d’experts,
d’utilisateurs, d’ergonomes et d’informaticiens, a permis
de définir le nombre d’écrans à utiliser, l’enchaînement
des vues, les modalités de dialogue homme-machine.
Pour chacune des vues, les modes de présentation des informations sont définies en collaboration avec l’expert,
l’utilisateur et l’informaticien. Les modes d’activation
des différents outils d’aide sont déterminés. Sur la Figure 10 sont également présentées les activités dans lesquelles l’utilisateur peut se trouver. Les cinq étapes du
processus de décision ont été synthétisées en trois types
d’activités qui sont le choix des outils (intégrant les étapes 1, 2 et 3), l’utilisation (étape 4) et l’analyse des résultats (étape 5). Ce qui correspond aux étapes 1, 2 et 3
sera basé sur les patrons de problème qui ont été définis.
Le choix des outils intègre trois types d’aide traduits par
différents modes d’affichage des outils. Le mode par
liste présente l’ensemble des outils. La sélection peut
être faite par mots-clés pour donner un affichage dit
« par mots-clés ». Le troisième mode d’affichage suit la
décomposition du problème faite en analyse et est nom-
mé « par thème ». L’utilisation correspond à l’utilisation
des composants métier associés. L’étape 5 consiste théoriquement à composer une interface avec les résultats hétérogènes issus des divers composants. Cette étape n’a
pas été réalisée lors de ce développement.
Figure 8 : Patron relatif au problème d’investissement
Figure 9 : Patron relatif au problème de la capacité en ligne
143
avec le système, (3) une première mise en situation avec
un problème issu du domaine. L’utilisateur a dû utiliser
le SIAD pour choisir les outils adaptés à son problème et
a répété cette action trois fois pour chacun des modes
d’aide au choix. A la fin de chaque sélection,
l’utilisateur a rempli un questionnaire sur son impression
par rapport au mode utilisé et les résultats obtenus. A la
fin, il a rempli un questionnaire permettant d’évaluer le
SIAD selon les critères d’utilisabilité de Bastien et Scapin [3]. (4) L’utilisateur a reproduit le même scénario
avec deux autres problèmes caractéristiques du domaine
mais en utilisant les modes selon un ordre préétabli. Les
documents recueillis sont les questionnaires sur les problèmes d’investissement ferroviaires, le questionnaire
d’évaluation ergonomique de l’IHM et l’enregistrement
sur vidéo (image et son) contenant l’ensemble des actions exécutées par l’utilisateur. Celui-ci a été enregistré
à partir de la première mise en situation jusqu’à la fin de
l’expérimentation. Trois utilisateurs de profils différents
ont participé à ces évaluations. L’utilisateur dit « novice » a des notions issues du domaine ferroviaire mais
ne travaille pas directement dans le domaine de
l’expertise. L’utilisateur débutant est un chargé d’étude
ferroviaire ayant une expérience de deux ans et
l’utilisateur dit « expert » est un chargé d’étude ferroviaire de trente ans d’expérience. Nous n’avons pas souhaité faire participer plus de monde car ces évaluations
ne sont pas terminales.
Figure 10 : Patron relatif au composant métier d’insertion
d’un sillon dans une grille horaire
ESTIMATION PAR LES UTILISATEURS
Les évaluations qui ont été menées consistent à valider
l’utilisation du template et des patrons associés pour
l’aide à la prise de décision. Selon le cycle de développement, la validation débute par le SIAD indépendamment des composants métier. L’objectif étant de valider
l’intérêt des supports pour l’aide à la décision, seule
l’activité de choix des outils correspondant au template
sera présentée.
Le protocole est centré sur l’évaluation de l’interaction
et l’influence des modes de présentation des outils sur
les utilisateurs. Pour mener à bien cette évaluation, les
futurs utilisateurs ont été mis en situation la plus réelle
possible. L’évaluation s’est déroulée en quatre étapes :
(1) la présentation du système et des modes de choix qui
lui sont proposés, (2) la familiarisation de l’utilisateur
Figure 11 : Diagramme états-transitions pour la spécification des IHM
144
Sur le Tableau 1, on constate que l’utilisateur considéré
comme expert a préféré commencer l’étude avec le mode
de recherche par liste car il ne lui semblait pas utile
d’être aidé par les autres mécanismes. L’utilisateur débutant a choisi le mode thème car il a apprécié la structure
arborescente le guidant dans le choix des outils en fonction du problème ; d’après cet utilisateur, ce mode a
l’avantage de lui éviter d’oublier des outils. Le troisième
utilisateur, dit novice, a utilisé le mode mots-clés car il
lui semblait lui permettre de trouver une sélection à son
problème. A la fin des études, l’utilisateur expert gardera
sa préférence pour le mode Liste, le débutant celle pour
le mode Thème et l’utilisateur novice celle pour les modes par liste et par mots-clés. On notera que l’utilisateur
novice a été gêné lors de l’utilisation de SIADIF avec le
mode thème car des outils ont été proposés plusieurs fois
dans des thèmes différents. Les autres utilisateurs n’ont
pas été gênés et ont été globalement en accord avec les
propositions de ce mode.
A chaque fin d’utilisation selon un mode, il a été demandé aux utilisateurs de quantifier leur satisfaction par
rapport à la sélection d’outils faite. Il en ressort que les
trois utilisateurs ont jugé les résultats sortants du mode
« recherche par liste » comme sensiblement meilleurs
par rapport aux deux autres modes, cf. Figure 12. On
remarque par ailleurs que les utilisateurs expert et débutant n’ont pas apprécié les résultats sortis de l’usage du
mode par Mots-clés. Or pour l’utilisateur expert les outils sélectionnés dans le mode Mots-clés sont plus nombreux que dans les autres modes. Le mode a donc correctement proposé les outils (sans manque). Concernant
l’utilisateur débutant, la sélection est rigoureusement la
même entre le mode Liste et le mode mots-clés. Pour cet
utilisateur, la différence de sélection entre l’outil 1 et 3
est dûe à un changement d’avis concernant la stratégie à
suivre pour résoudre le problème, indépendant de
l’utilisation du système. La seule différence dûe au mode
de recherche se situe au niveau d’un outil non sélectionné lors de l’utilisation du mode Thème car celui-ci
n’était pas proposé. A contrario, un des outils n’a pas été
sélectionné par l’utilisateur expert lors de l’utilisation du
mode Thème alors que ce mode le proposait ; on peut
supposer que le problème est de reconnaissance. L’outil
ne devait pas être présent là où l’utilisateur s’attendait à
le trouver. C’est principalement pour cette raison que
l’utilisateur expert est moins satisfait des résultats obtenus à l’aide du mode Thème.
Liste
Thème
Mots-clés
Préférence finale
Expert
1
3
2
Liste
Débu2
1
3
Thème
tant
Novice
2
3
1
Liste ou
Mots-clés
satisfaction des utilisateurs concernant la
sélection d'outils obtenue par mode
100,00
utilisateur novice
50,00
utilisateur débutant
utilisateur expert
0,00
Thème
Liste
Mots clés
mode de sélection
Figure 12 : Degré de satisfaction des résultats par rapport aux
modes utilisés
D’un point de vue utilisabilité, le principal reproche
concernait le manque de retour d’information particulièrement dans le mode thème. Le mode thème proposait
les outils dans plusieurs tableaux. Des outils pouvaient
se retrouver dans plusieurs thèmes. Le manque de retour
d’information obligeait les utilisateurs à se souvenir ou à
prendre en note les outils au fur et à mesure de la sélection. Cela s’est répercuté sur leur notation dans la grille
d’utilisabilité, cf. Figure 13 concernant le guidage.
guidage
100,00
compatibilité
charge de travail
50,00
utilisateur novice
signification des codes
0,00
contrôle explicite
utilisateur débutant
utilisateur expert
moyenne
homogéneité/cohérence
adaptabilité
gestion des erreurs
Figure 13 : Résultats globaux relatifs à l’utilisabilité.
CONCLUSION ET PERSPECTIVES
Ce papier a présenté un certain nombre de cycles de développement issus de divers domaines en lien avec les
SIAD. Pour nous le SIAD est un moyen d’assistance qui
permet de proposer un ensemble d’outils accompagné
d’une aide pour faciliter l’ensemble du processus de décision. Les cycles ont montré des avantages mais aussi
souvent des insuffisances pour le développement des
SIAD. Une approche couplant un certain nombre de
principes a été présentée. Des supports à la prise en
compte des utilisateurs et des experts pour le développement et la réutilisation ont été proposés. Ceux-ci sont
génériques mais peuvent être adaptés à des cas particuliers. Une étude de cas dans le domaine ferroviaire a tenté de montrer l’intérêt des supports pour l’aide à la décision et notamment dans un premier temps dans le choix
des outils. L’approche proposée peut encore être affinée
et approfondie. Une plateforme la supportant serait une
réelle aide dans le cadre du développement, notamment
pour faciliter la gestion des patrons introduits lors d’un
développement. Le SIAD tel qu’il est développé à l’aide
de l’approche permet de manipuler un certain nombre
Tableau 1 : Ordonnancement du choix de mode par chaque
utilisateur
145
d’outils. L’étape finale du processus de décision est la
synthèse des analyses de manière à aboutir à une décision. Cette synthèse, supportée par le SIAD, est effectuée grâce aux opérateurs de composition des IHM [17].
Ce travail fait partie des perspectives car il existe peu de
moyen pour composer des IHM. Les travaux relatifs au
projet RAINBOW [9] visent cet objectif à partir de spécification de l’IHM en SUNML. Cette problématique est
également abordée dans les travaux relatifs à la composition de composants [12]. Cependant, il faut dans le cas
du SIAD que la composition soit réalisée de manière,
encore une fois, à supporter le décideur.
9.
10.
11.
REMERCIEMENTS
Les auteurs remercient les experts de RFF pour leur
participation dans ce travail et la région Nord - Pas-deCalais qui a participé au co-financement de la thèse avec
RFF. Ce travail bénéficie aussi d’idées provenant du
projet TACT MIAOU et EUCUE supportés par la région
Nord- Pas-de-Calais et le FEDER.
12.
13.
BIBLIOGRAPHIE
1.
2.
3.
4.
5.
6.
7.
8.
Abed, M. Méthodes et Modèles formels et semiformels de conception et évaluation des systèmes
homme-machine. Mémoire d’HDR, Université de
Valenciennes et du Hainaut-Cambrésis, 2001.
Balasubramanian, P., Nochur, K., Henderson, J.-C.
et Millie Kwan, M. Managing process knowledge
for decision support. Decision Support Systems Vol
27 (1-2), 1999, pp. 145-162
Bastien, J. et Scapin, D. Evaluation des systèmes
d’information et critères ergonomiques. In Kolski, C
(ed). Environnements évolués et évaluation de
l’IHM. Interaction Homme Machine pour les SI.
Éditions Hermès, Paris, 2001, pp. 53-79.
Buisine A. Vers une démarche industrielle pour le
développement d'Interfaces Homme-Machine, De
l'analyse de l'activité à la génération du code. Thèse
de l’Université de Rouen. 1999
Caulier P. Méthodologie de capitalisation et de réutilisation de connaissances pour l'aide à la supervision des procédés automatisés complexes - Application à la supervision du trafic téléphonique de l'Ile
de France. Thèse de l’Université de Valenciennes et
du Hainaut-Cambrèsis. 1997.
Chen, Z. Interacting with software system components. Decision Support Systems, Vol. 14, 1995, pp.
349-357.
Cloux, P.-Y. RUP, XP Architectures et Outils - industrialiser le processus de développement. Dunod,
2003, Paris.
Coulange, B. Réutilisation du logiciel. MASSON,
1996, Paris.
14.
15.
16.
17.
18.
19.
20.
146
Dery-Pinna, A.-M., Fierstone, J., and Picard, E.
Component Model and Programming: a First Step to
Manage Human-Computer Interaction Adaptation.
In Proc. of 5th Int. Symposium on Human-Computer
Interaction with Mobile Devices and Services MobileHCI’2003 (Udine, September 8-11, 2003). Lecture Notes in Computer Science, Vol. 2795, Springer-Verlag, Berlin, 2003, 456–460.
Duribreux-Cocquebert M. MODESTI : vers une méthodologie interactive de développement de Systèmes à Base de Connaissances. Thèse de l’Université
de Valenciennes et du Hainaut-Cambrésis. 1995.
Gamma E., Hem R., Johnson R. et Vlissides J. Design Patterns: Elements of reusable Object-Oriented
Software. Addison Wesley, Massachusetts, 1994.
Grundy, J. et Hosking, J. Developing adaptable user
interfaces for component-based systems. Interacting
with Computers, Vol. 14, 2002, pp. 175-194.
Hartson, H.R. et Hix, D. Towards empirically derived methodologies and tools for Human-Computer
development. International Journal of Man-Machine
Studies, Vol. 31, 1989, pp. 477-494.
Jaulent P. Génie Logiciel, les méthodes. A. Colin,
Paris, 1994.
Lepreux, S. Approche de Développement centré décideur et à l’aide de patron de Systèmes Interactifs
d’Aide à la Décision, application à l’investissement
dans le domaine ferroviaire. Thèse de doctorat, Université de Valenciennes et du Hainaut-Cambrésis,
2005.
Lepreux, S., Abed, M. et Kolski, C. A Humancentred methodology applied to decision support
system design and evaluation in a railway network
context. Cognition, Technology & Work, Vol. 5,
2003, pp. 248-271.
Lepreux, S., Vanderdonckt, J. Towards Supporting
User Interface Design by Composition Rules, Proc.
of the "6th Int. Conf. on Computer-Aided Design of
User Interfaces. CADUI'2006, (Bucharest, Romania, 6-8 June 2006), Chapter 19, Springer-Verlag,
Berlin, 2006.
Lévine, P. et Pomerol, J.-C. Systèmes interactifs
d'aide à la décision et systèmes experts. Hermès, Paris, France, 1989.
Palma-dos-Reis, A. et Zahedi, F. M. Designing personalized intelligent financial decision support systems. Decision Support Systems. Vol 26(1), 1999,
pp. 31-47.
Rasmussen, J. Skill, rules and knowledge; signals,
signs, and symbols, and other distinctions in human
performance models. IEEE Transactions on Systems, Man and Cybernetics, Vol. SMC-13, No. 3,
1983, pp. 257-267.
Les Modèles de Tâches
pour la Contextualisation des Composants
Arnaud Lewandowski, Grégory Bourguin
Jean-Claude Tarby
Laboratoire dInformatique du Littoral
50, rue Ferdinand Buisson
62228, Calais, France
{lewandowski, bourguin}@lil.univ-littoral.fr
Laboratoire Trigone
Institut CUEEP, Université Lille 1
59655 Villeneuve dAscq, France
[email protected]
débit a contribué à la mise à disposition d’une pléthore
d’outils destinés à supporter les activités humaines. Ainsi, si autrefois l’utilisateur n’avait d’autre choix que de
s’adapter à un système rigide et sans concurrence, la
tendance est à présent inversée: si l’utilisateur n’est pas
en mesure d’adapter le système à ses besoins émergents,
il est probable qu’il en change. Pour répondre à ce besoin de plus en plus prégnant, une des approches proposées consiste à fournir aux utilisateurs les moyens leur
permettant d’adapter au fil de leurs besoins leur environnement logiciel de support d’activités. Cela sous-entend
d’implanter dans l’environnement les mécanismes adéquats qui permettront aux utilisateurs d’y intégrer les
nouveaux outils qu’ils téléchargent sur le Web. S’il
existe des mécanismes avancés qui permettent de réaliser
cette contextualisation d’outils d’un point de vue technologique, il est intéressant de noter que ces solutions
sont toujours confrontées à un problème d’ordre sémantique: pour intégrer de manière fine un outil (ou composant logiciel) dans l’environnement, il est nécessaire de
comprendre le fonctionnement de ce composant, et
quelle sera sa place dans l’activité globale supportée par
l’environnement. Or, nous pensons que les modèles et
outils actuels présentent des lacunes de ce point de vue,
et restent inaccessibles pour l’utilisateur final. Pour pallier ce manque, nous avons amorcé une nouvelle approche pour la définition, le développement et l’intégration
dynamique de composants. Nous proposons de mieux
utiliser les modèles de tâches issus du domaine des IHM,
qui, dans l’approche de conception classique, ont tendance à s’évaporer au fil du processus de développement
pour finalement disparaître. Nous pensons que ces modèles de tâches peuvent améliorer la compréhension et
faciliter la contextualisation des composants par les utilisateurs. Dans un premier temps, nous détaillerons la problématique de l’intégration fine et dynamique de composants, en évoquant les solutions existantes et les problèmes auxquels elles font face, notamment du point de vue
de l’accessibilité aux utilisateurs. Nous proposerons ensuite l’approche de conception Orientée Tâches (OT)
visant à ajouter de la sémantique dans les composants au
travers des modèles de tâches, en vue d’assister la
contextualisation de ces composants. Enfin, nous introduirons une mise en œuvre de cette démarche dans la
plateforme CooLDev.
RESUME
Une solution permettant de répondre au caractère émergeant et évolutif des besoins des utilisateurs, vis-à-vis
des environnements logiciels supportant leurs activités,
consiste à leur donner les moyens d’adapter ces environnements par l’intégration de nouveaux outils. De nombreuses solutions techniques existent pour l’intégration
de composants logiciels, mais leur accessibilité reste
cantonnée aux développeurs expérimentés. Une des raisons principales réside dans le fait que les approches
d’intégration dynamique sont confrontées à un problème
d’ordre sémantique: pour bien intégrer un outil dans une
activité, il faut en effet bien comprendre quelle sera sa
place dans cette activité. Pour faciliter cette compréhension et donc l’intégration dynamique et fine de composants, nous proposons une nouvelle approche de conception et d’intégration inspirée de travaux sur la modélisation des tâches.
MOTS CLES : Composant, Intégration, Tâche.
ABSTRACT
Users’ needs towards the software environments supporting their activities are emerging and continuously
evolve. A solution is to give to the users the means to
adapt these environments, by integrating the tools they
need. Many technical solutions exist, but their use is
limited to a public of experts in software developement.
The main reason is that current dynamic integration approaches face a semantic problem: in order to finely integrate a tool in an activity, one must indeed well understand what will be its place in this activity. In order to
facilitate this understanding and this dynamic integration, we propose a new approach of conception and integration, based on previous work on task modelling.
KEYWORDS: Component, Integration, Task.
INTRODUCTION
Aujourd’hui, de nombreux travaux tendent à apporter
des réponses aux besoins émergents des utilisateurs visà-vis des environnements logiciels supportant leurs activités. En effet, les avancées technologiques ont largement contribué à rendre les utilisateurs de plus en plus
exigeants vis-à-vis des systèmes informatiques. Par ailleurs, la démocratisation de l’Internet et des accès haut-
147
la cohérence de l’environnement est principalement gérée mentalement par les utilisateurs. Notre objectif est de
fournir un environnement qui crée le contexte
d’utilisation des divers outils impliqués dans une activité
globale et supporte par exemple l’activité de développement de logiciel en gérant les liens existants entre ces
diverses (sous-)activités, c’est-à-dire en gérant l’interactivités. Gérer l’inter-activités consiste principalement à
gérer le contexte d’exécution des outils mis en œuvre par
les utilisateurs dans la réalisation de leur activité globale
[17]. Un contexte particulier pourra par exemple configurer les outils pour refléter le rôle de l’utilisateur dans
l’activité globale supportée par l’environnement. Ainsi,
les acteurs chargés du test dans l’activité de production
d’un logiciel n’auront pas, par exemple, les droits
d’accès leur permettant de modifier le code du logiciel.
Ce contexte pourra aussi piloter les outils (supportant les
sous-activités) en fonction de changements d’états dans
l’activité globale. La mise en œuvre de tels scénarios
dans l’inter-activités, orchestrant un ensemble d’outils ne
se connaissant pas a priori, suppose que ces composants/outils puissent être contextualités de manière fine
dans l’environnement global.
LE PROBLEME DE LA CONTEXTUALISATION
De nombreuses études théoriques et empiriques ont démontré le caractère émergeant des besoins des utilisateurs vis-à-vis de leurs activités et des environnements
logiciels les supportant [8,12,16,29,34]. De fait, de nombreux travaux de recherche tendent à intégrer aux environnements logiciels les mécanismes permettant de supporter ces besoins émergents, et à donner aux utilisateurs
la possibilité de faire évoluer eux-mêmes ces environnements. Comme nous l’avons évoqué dans
l’introduction, les utilisateurs n’hésitent plus à rechercher sur l’Internet les outils qui répondent le mieux à
leurs besoins, outils qu’ils utiliseront ensuite dans le
cadre de leur activité. Supporter une telle évolution de
l’environnement consiste donc à supporter la contextualisation (ou intégration) de nouveaux outils (ou composants) dans l’environnement.
La contextualisation – vision inspirée des SHS
Le domaine du TCAO (Travail Coopératif Assisté par
Ordinateur) a intégré depuis longtemps les résultats de
recherches en Sciences Humaines et Sociales, établissant
clairement que les besoins des utilisateurs ne peuvent
être complètement définis a priori et de manière exhaustive. Ainsi, la Théorie de l’Activité [1] met en évidence
le fait que l’activité humaine, et tous les éléments qui la
composent, est sujette à l’évolution, y compris les besoins des utilisateurs, qui émergent de celle-ci. Un système informatique dédié à supporter une activité particulière doit donc également être en mesure d’évoluer.
C’est ainsi que nos travaux tentent de fournir des environnements informatiques adéquats suivant le principe
de coévolution (défini en détails dans [4,5]), c’est-à-dire
permettant aux utilisateurs finaux de (re)définir dynamiquement et coopérativement leur propre environnement
informatique. Cette (re)définition peut par exemple se
traduire par une évolution des rôles mis en jeu dans
l’activité coopérative, ou encore par l’intégration dynamique de nouveaux outils (sous forme de composants)
au sein de l’environnement de travail. Nos travaux étant
fortement inspirés par la Théorie de l’Activité, nous
avons traduit ce besoin d’intégration dynamique d’outils
en terme de gestion de l’inter-activités [17]. Cette approche considère que chaque outil est destiné à supporter un
type d’activité en particulier. Mais lorsque plusieurs outils sont utilisés en parallèle par un groupe d’acteurs, ils
servent généralement une activité de plus haut niveau
que celle pour laquelle chaque outil a été créé. Imaginons par exemple qu’un groupe utilise en parallèle un
composant de discussion synchrone, un outil de partage
de document de type CVS1, et un éditeur de code. Ces
divers outils supportent chacun une activité (discussion
synchrone pour le chat, etc.) et ne se connaissent pas.
Cependant, ils sont utilisés de manière complémentaire
par le groupe du fait qu’ils servent une activité coopérative globale de développement de logiciel. Bien souvent,
La contextualisation – solutions techniques
Le problème de l’intégration de composants logiciels est
un domaine de recherche complexe. De nombreuses solutions techniques tentent d’ailleurs d’y apporter des
réponses. Par exemple, les composants distribués de type
Corba [37], EJB (Enterprise JavaBeans) [2], ou encore
les Services Web [11] sont conçus en vue de leur intégration future. Y sont parfois associés des langages de
composition [36] qui permettent d’intégrer de manière
fine ces composants ou services informatiques au sein
d’applications. Il est à noter que ces solutions technologiques pour l’intégration sont à destination exclusivement de développeurs expérimentés, notamment en raison de leur complexité, de leur coût de mise en œuvre et
de la spécificité des techniques employées [13]. Néanmoins, ces différentes méthodes d’intégration fonctionnent suivant le même principe : il est possible de découvrir dynamiquement les objets sur l’Internet, de les instancier, de découvrir par introspection leurs méthodes
publiques ainsi que leurs éventuels canaux
d’événements, et finalement de les utiliser. Ces mécanismes sont fort intéressants pour nous permettre de gérer l’inter-activités. Pourtant, ils apportent principalement une solution à la dimension technique du problème.
En effet, intégrer dynamiquement un outil de manière
fine suppose qu’on puisse l’utiliser, mais aussi que l’on
comprenne comment l’utiliser. Pour pallier ce problème
de sémantique des composants, les technologies Orientées Objets (OO) fournissent quelques supports pour leur
compréhension, comme le WSDL [3], langage de description des Services Web; ou encore la Javadoc [14],
une documentation des composants JavaBeans générée à
partir de balises insérées dans le code desdits composants sous forme de commentaires. Ainsi, dans
1
CVS (Concurrent Versions System) est un outil de gestion centralisée
de versions, très utilisé par les équipes de développement logiciel.
148
l’exemple de la création d’un chat intégrable, la Javadoc
associée pourrait décrire la liste des méthodes publiques
de l’outil pour son pilotage telles que envoyerMessage,
authentifier, afficherGroupe, etc. Néanmoins, pour intégrer un tel composant, ce genre de documentation, qui
décrit le fonctionnement des méthodes mais pas la façon
de les utiliser, n’est généralement pas suffisante. Tout
développeur a d’ailleurs déjà été confronté à ce problème. Par exemple, dans quel ordre ces méthodes doivent-elles être appelées par l’application qui contextualise le chat pour que ce composant fonctionne correctement? Une solution consiste à rechercher des exemples
d’utilisation, en épluchant le code d’une autre application qui utilise le même composant, ou en procédant à
une initiation à sa mise en œuvre sous forme de tutoriel,
dans le meilleur des cas.
Quest-ce quun outil du point de vue de la tâche?
En cohérence avec notre approche de l’inter-activités, on
peut considérer que chaque outil supporte une tâche à
laquelle il est dédié. En d’autres termes, tout composant
informatique peut être vu comme un support générique à
une tâche particulière, cette tâche étant inscrite plus ou
moins implicitement dans l’outil. En effet, le concepteur
de l’outil a créé les mécanismes sous-jacents et son interface de manière à proposer un support adéquat à une
tâche donnée. Ainsi, un composant de mail supporte la
réalisation de tâches de mailing, un composant de chat
supporte des activités de discussion synchrone, etc. En
conclusion, on peut considérer que contextualiser un
outil, c’est contextualiser une tâche existante dans le
cadre d’une tâche plus globale. De manière à faciliter
cette contextualisation et à apporter une réponse aux
problèmes de l’intégration dynamique, nous proposons
ci-après de mieux utiliser le modèle de tâches du composant, sorte de chaînon manquant qui disparaît généralement entre la phase de conception et le code produit.
Nous pensons que ces difficultés liées à l’intégration
dynamique de composants tiers proviennent d’une perte
de sémantique dans les moyens proposés quant à leur
documentation. Seuls des informaticiens passionnés sont
en général capables d’intégrer au mieux la plupart des
composants émergeant sur l’Internet car, procédant par
l’étude de codes existants, ils doivent presque totalement
reconstruire mentalement la mécanique de fonctionnement de l’outil qu’ils tentent d’intégrer. Cette problématique limite la réutilisation à des utilisateurs très spécialisés. D’ailleurs, si de nombreux travaux sont en cours
[15,21], visant à pallier ce problème sémantique dans les
modèles de composants, les solutions proposées restent
généralement à destination de développeurs expérimentés. Or, dans le cadre de nos travaux sur la coévolution
[5], nous avons montré qu’il serait fort bénéfique de faciliter cette intégration fine et dynamique de composant,
y compris pour et par les utilisateurs finaux. C’est ainsi
que d’autres solutions ont été envisagées, consistant à
intégrer des composants dans un environnement cible
particulier qui fournit des mécanismes permettant de
relever le niveau d’abstraction de l’intégration; c’est le
cas des plug-ins Eclipse [24] intégrables exclusivement à
cette plateforme. Si cette intégration est plus accessible
aux utilisateurs finaux, c’est au détriment de la souplesse
de l’intégration; la spécification de la façon dont un
composant sera intégré est en effet souvent codée directement dans le composant, et il difficile de (re)définir
finement ce «schéma» d’intégration autrement qu’en
modifiant le code. L’intégration fine et dynamique par
les utilisateurs est donc toujours un problème prégnant:
en effet, les méthodes permettant de réaliser une telle
intégration sont confrontées à des problèmes sémantiques, et ne sont accessibles qu’à un public d’experts –
donc pas les utilisateurs finaux. Ces utilisateurs, informaticiens ou non, ne sont pas des spécialistes de la technologie mise en œuvre, mais plutôt des spécialistes de la
tâche qu’ils veulent accomplir.
DE LORIENTE OBJET A LORIENTE TACHES
Utilisation des modèles de tâches dans le cycle de
développement
Très tôt, les ergonomes se sont penchés sur la logique de
fonctionnement et la logique d’utilisation [31] afin de
comprendre le mode de fonctionnement des utilisateurs
pendant leurs activités, c'est-à-dire lors de la réalisation
de leurs tâches. Petit à petit, l’analyse des tâches s’est
étoffée avec la modélisation permettant non seulement
de décrire précisément les tâches effectives (celles réalisées réellement par les utilisateurs), mais également
d’écrire le modèle des tâches prescrites, c'est-à-dire celles que les utilisateurs sont censés réaliser par la suite.
Cette modélisation, ainsi que les méthodes associées
(CARD, ACTU2, etc. [25]), devenant de plus en plus
complexe, une multitude de formalismes ont fait leur
apparition, la majorité étant couplée à des outils le plus
souvent graphiques, par exemple CTTE [22] pour le
formalisme CTT [27] et TAMOT [18] pour Diane+ [35].
L’utilisation des tâches prend une place de plus en plus
importante dans le Génie Logiciel, principalement dans
le domaine des IHM. Nombreux sont les travaux dans ce
domaine qui portent sur les moyens visant à exprimer les
tâches des utilisateurs. Cette approche orientée tâches est
généralement utilisée dans les phases amont ou aval d’un
processus de conception [7,9,18,19,20,26,27,30]. Toutefois, il est intéressant de constater que si ces méthodes
proposent de commencer la conception d’un composant
par une modélisation de la tâche, cette démarche s’efface
2
CARD (Collaborative Analysis of Requirements and Design) et
ACTU (Analyse Collaborative des Tâches des Utilisateurs) sont des
méthodes de conception participative, basées sur l’utilisation de cartes
à jouer représentant des tâches et des objets familiers pour les participants. Ces méthodes permettent de recueillir facilement des modèles de
tâches utlisateur.
149
Figure 1. Schématisation de l’approche de conception classique, et de l’approche Orientée Tâches qui tend à préserver le
modèle de tâches tout au long du processus de développement, pour une meilleure contextualisation du composant.
tâches associé à partir du code. Ceci rejoint le fait évoqué précédemment concernant la nécessité pour les intégrateurs d’entrer dans le code du composant pour en réextraire la logique de fonctionnement du point de vue
informatique, et surtout sa logique d’utilisation du point
de vue de l’utilisateur, c’est-à-dire reconstruire et rendre
à nouveau explicite le modèle de tâches sous-jacent.
C’est aussi pour cela que lors des phases de tests finaux,
les équipes de développement sont obligées de recourir
aux «espions», aux interviews, et à d’autres techniques
pour retrouver une partie de ce modèle de tâches. Par
conséquent, nous sommes convaincus que la conservation explicite du modèle de tâches, jusque dans la mise à
disposition du composant logiciel, sera bénéfique à
l’intégration dynamique des outils dans l’activité des
utilisateurs. De plus, les modèles de tâches servent aussi
souvent, en tant qu’objet partagé, à une meilleure communication entre les différents acteurs (y compris les
futurs utilisateurs) du processus complexe de développement. De ce fait, la mise à disposition du modèle de
tâches devrait non seulement permettre la compréhension du fonctionnement de l’outil à intégrer, mais aussi
faciliter l’intégration au niveau de la tâche globale par
les utilisateurs finaux eux-mêmes en fournissant sa logique d’utilisation. C’est ce que nous proposons de réaliser
grâce à une nouvelle approche de conception.
progressivement pour finalement être absorbée par une
démarche de conception orientée objet inspirée par
l’ingénierie informatique. Cette approche de conception
classique tend à transformer les modèles de tâches en
modèles d’objets, d’où découle implicitement la structuration en classes du composant produit (cf. Figure 1,
partie supérieure). Le modèle de tâches de base se retrouve noyé, inscrit de manière implicite dans la complexité du code produit. En effet, les approches orientées
tâches ne sont pas ou peu utilisées pendant le cycle de
conception et de développement, c'est-à-dire après le
recueil des besoins et leur analyse. Par ailleurs, les outils
de conception actuels, principalement ceux reconnus en
Génie Logiciel – qu’il s’agisse d’Environnements de
Développement Intégrés (EDI) dédiés à supporter les
phases de programmation/test, ou des Ateliers de Génie
Logiciel (AGL) comme Rational Rose, tendant à supporter l’intégralité du processus de production –
n’intègrent absolument pas les approches orientées tâches. UML lui-même, n’intègre pas du tout la notion de
tâches telle que nous la connaissons en IHM. Par exemple: UML ne contient pas les notions de buts utilisateur
ou d’intentions de l’utilisateur; UML ne permet pas de
modéliser les utilisateurs (connaissances, habitudes,…);
la différence de notion entre tâche interactive, tâche
système et tâche manuelle n’existe pas dans UML.
Pourtant, nombreux sont les travaux qui ont tenté de
remédier à ce manque [6,23,28,32], profitant de similitudes entre certains concepts d’UML et des approches
orientées tâches pour créer des «traducteurs».
On constate donc que le bénéfice réalisé dans les phases
amont lors de la modélisation des tâches disparaît totalement lors de la conception et de l’implémentation.
Même si le code produit reflète les tâches initialement
identifiées, il est très difficile de retrouver le modèle de
Une nouvelle démarche de conception
Comme nous l’avons illustré précédemment, le bénéfice
de l’utilisation des modèles de tâches est présent à tous
les stades du cycle de vie du composant logiciel, depuis
sa conception, en passant par son développement, et jusqu’à sa contextualisation. Notre proposition consiste en
une démarche de conception Orientée Tâche (OT), c’està-dire une approche ‘classique’ augmentée par le main-
150
mentale au fur et à mesure de la définition des besoins
pour l’outil de discussion. En l’occurrence, c’est le formalisme Diane+ [35] que nous avons utilisé pour
l’élaboration de ce modèle de tâches. Toutefois, comme
notre démarche s’attache à relier au code des concepts
généraux des modèles de tâches, il est tout à fait possible
d’utiliser d’autres formalismes comme CTT [27]. Ce
modèle (dont le premier niveau de décomposition est
donné sur la Figure 2) est constitué de plusieurs tâches
(se connecter, communiquer, etc.), elles-mêmes éventuellement décomposées en sous-tâches (c’est le cas des
tâches communiquer et administrer). C’est ce modèle
qui, suivant notre démarche, sera conservé lors du processus de développement. C’est donc également ce modèle qui sera utilisé pour la contextualisation du composant dans une tâche plus globale. En fonction du nouveau
contexte d’usage (défini lors de la contextualisation),
certaines parties du modèle pourront être shuntées. Dans
notre exemple, la tâche se connecter (à laquelle correspond l’interface demandant à l’utilisateur de renseigner
ses informations de connexion) peut être shuntée par un
appel direct au lien validate. Ce type de shunt est souvent mis en œuvre dans un environnement global qui se
charge de récupérer les informations de connexion des
acteurs et les transmet lui-même aux outils qui y sont
intégrés de manière à les configurer automatiquement.
tien explicite des liens entre le code et le modèle de tâches qui en est à la base. Notre démarche n’impose aucun formalisme particulier pour la modélisation des tâches puisque nous nous attachons à relier des concepts
des modèles de tâches (indépendants donc du formalisme) au code. De la même manière, cette démarche de
conception n’a pas d’incidence directe sur la structuration des classes du composant. En effet, notre démarche
consiste justement à identifier les liens entre le code du
composant (autrement dit sa structuration) et le modèle
de tâches qui en est à l’origine. Ces liens sont inscrits
dans le code sous forme de balises (à la manière des balises de la Javadoc, insérées dans le code sous forme de
commentaires, pour permettre la génération automatique
de documentation) lors de la phase d’implémentation.
Cette démarche permet d’obtenir des composants avec
un modèle de tâches documenté et lié au code (cf. Figure1, partie inférieure).
L’avantage de cette démarche réside dans le fait qu’elle
n’induit qu’une faible surcharge du travail des concepteurs et des développeurs. En effet, si le modèle de tâches est déjà réalisé pour les besoins de l’analyse, la
surcharge consiste uniquement à inscrire dans le code les
liens susmentionnés et à livrer le composant avec son
modèle de tâches. En revanche, le gain en matière de
sémantique concernant le fonctionnement du composant
est appréciable, et pourra aider à sa compréhension. Pour
la contextualisation, nous proposons de fournir les
moyens de manipulation associant les mécanismes
d’introspection et de documentation classiques avec le
modèle de tâches du composant.
MISE EN ŒUVRE DANS LA PLATEFORME COOLDEV
L’objectif du projet CooLDev (Développement Coopératif du Logiciel) est de proposer un environnement global pour le support des activités coopératives de développement logiciel. L’environnement CooLDev, fondé
sur la plate-forme Eclipse, propose déjà des moyens pour
la gestion de l’inter-activités. Un méta-modèle, auquel
nous avons associé divers mécanismes pour l’exécution,
permet notamment de décrire et de gérer les liens existant entre des activités [17]. Toutefois, ces mécanismes
étaient jusqu’à présent limités dans leur utilisation par le
problème de sémantique que nous venons d’exposer. Les
moyens techniques pour la contextualisation des outils
existent, mais le problème réside dans la compréhension
de leur fonctionnement. Nous pensons que la nouvelle
approche OT que nous présentons permettrait d’apporter
une réponse à ce problème. Pour valider cette approche,
nous avons décidé de procéder au développement d’un
plug-in Eclipse de discussion synchrone que nous pourrons contextualiser dans la plateforme CooLDev.
Figure 2. La tâche du chat (niveau global).
La phase suivante correspond au codage de l’outil et de
son interface sur la base du modèle de tâches défini en
amont. La particularité de cette phase consiste à conserver les liens entre ce modèle et le code produit. Ces liens
sont inscrits dans le code grâce à des tags de type xdoclet
(balises sémantiques insérées dans le code, suivant le
modèle des balises de la Javadoc) qui référencent des
entités du modèle (tâches, liens, etc.). Cependant, chaque
entité du modèle de tâches n’est pas forcément reliée à
une portion de code; c’est par exemple le cas de la plupart des tâches complexes qui sont constituées de plusieurs tâches (comme la tâche administrer) et dont la
réalisation peut s’effectuer de plusieurs manières. Ici,
Conception et développement dun composant OT
Notre démarche présente de nombreuses similitudes avec
les approches classiques. La conception a été faite sur la
base d’un modèle de tâches construit de manière incré-
151
d’une manière générale, les tags ajoutés au code mettent
en correspondance des méthodes avec des tâches
(comme la tâche se connecter, par exemple) ou des liens
du modèle de tâches (comme le lien validate). Ainsi, le
corps de la méthode authentifier(String login, String
password) est précédé d’une balise xdoclet
(@taskmodel.link name="validate"), qui indique que le
lien validate du modèle de tâches est réalisé par cette
méthode. La tâche se connecter peut ainsi être shuntée
par une entité extérieure (d’un autre modèle de tâches)
faisant un appel direct à la méthode authentifier en renseignant ses deux paramètres. On dispose alors d’un
composant fonctionnel livré avec son modèle de tâches
sous forme d’un fichier XML lié à celui-ci.
Ce prototype permet d’une part d’avoir une vision globale du modèle de tâches du composant à intégrer, et
donc contribue à la compréhension de son fonctionnement. D’autre part, il permet de spécifier la façon dont le
composant sera intégré à la tâche globale, au travers de
la définition de liens entre le modèle de tâches du composant et le modèle de la tâche globale. Ce genre de liens
tend à supporter une contextualisation d’une dimension
plus fine du composant dans l’activité, qui va plus loin
qu’une simple intégration visuelle dans l’environnement.
Cette première mise en œuvre de la démarche de
conception OT a permis de mettre en évidence plusieurs
éléments. D’une part, comme nous l’avons évoqué, cette
démarche n’induit effectivement qu’une faible surcharge
de travail pour les concepteurs et les développeurs, si
tant est que l’analyse faite en amont ait donné lieu à
l’élaboration d’un modèle de tâches. D’autre part, nous
avons pu constater, dans le cadre de cet exemple simple,
que l’adjonction aux autres moyens de documentation
(Javadoc, etc.) d’un modèle de tâches décrivant le fonctionnement et l’utilisation du composant rend sa compréhension plus intuitive. La contextualisation dans
l’environnement global par la création de liens fins s’en
trouve facilitée. Nos travaux se poursuivent avec
l’objectif de rendre plus accessibles aux utilisateurs finaux ces mécanismes d’introspection sur les modèles de
tâches et leur manipulation pour la contextualisation des
composants au sein de leurs activités.
Contextualisation dun composant OT
A partir de ce composant OT, on peut donc appliquer les
mécanismes d’introspection classiques qui nous permettront d’obtenir la liste des méthodes utilisables pour son
intégration, la Javadoc qui décrit le fonctionnement de
cette méthode dans une approche Orientée Objet, mais
aussi les liens directs entre ces méthodes et le modèle de
tâches sous-jacent. Pour faciliter la contextualisation du
composant dans l’activité globale, nous avons développé
un prototype (cf. Figure 3) permettant de réaliser cette
introspection du point de vue du modèle de tâches des
composants, avec ses différents niveaux de décomposition, et d’effectuer sa liaison avec la tâche de l’activité
globale. Dans l’exemple, le modèle de tâches du composant de discussion synchrone a été intégré à la tâche globale d’utilisation de l’environnement Eclipse, via le lien
de connexion présenté dans le paragraphe précédent.
CONCLUSION
Une réponse aux besoins émergents des utilisateurs
consiste à leur proposer l’intégration dynamique de nouveaux outils dans leur environnement de travail informatisé. Si l’on considère les moyens existants du point
de vue de l’activité humaine, cette intégration dynamique pose problème au niveau sémantique. En effet,
l’intégration fine d’un composant implique la compréhension de la (sous-)tâche qu’il supporte pour définir la
place qu’il occupera dans l’activité visée. Malheureusement les moyens actuels induisent une perte sémantique
lors de la réalisation des outils. L’approche Orientée
Tâche (OT) que nous avons proposée tire parti du processus de modélisation des tâches réalisé en amont de la
phase de conception du composant. Généralement, ces
modèles de tâches se retrouvent finalement dilués dans le
code du composant. Notre approche les conserve tout au
long du processus de développement, et les livre avec le
composant final en tissant des liens fins entre le modèle
de tâches à l’origine du composant et le code correspondant à sa réalisation. Nous avons vérifié la faisabilité de
cette approche par le développement et l’intégration d’un
plug-in de chat pour la plate-forme CooLDev. Nos travaux actuels consistent à parfaire ces nouveaux moyens
d’introspection et leur outillage de manière à faciliter
davantage l’intégration dynamique de composants/outils
par les utilisateurs finaux, pour une meilleure coévolution [5].
Figure 3. Maquette d’intégration du modèle de tâches du chat
dans la tâche globale par shunt de la tâche se connecter.
152
12. Folcher, V. Appropriating artifacts as instruments:
when design-for-use meets design-in-use. In Interacting with Computers, 15(5), 2003, pp. 647-663.
REMERCIEMENTS
Les auteurs tiennent à remercier la Direction de la Recherche pour l’ACI CooLDEv, le programme TAC financé par la Région Nord/Pas-de-Calais et l’Etat dans le
cadre du CPER pour les projets MIAOU et EUCUE.
13. Heineman, G.T. and Councill, W.T. Componentbased software engineering: putting the pieces together. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, 2001.
BIBLIOGRAPHIE
1.
Bedny, G., Meister, D. The Russian theory of activity, Current Applications to Design and Learning.
Lawrence Erlbaum Associates, Publishers, 1997.
2.
Blevins, D. Overview of the Enterprise JavaBeans
Component Model. In [13], pp. 589-606.
3.
Booth, D. and Liu, C.K. Web Services Description
Language (WSDL) Version 2.0 6 January 2006.
Disponible à l’adresse :
.
http://www.w3.org/TR/wsdl20-primer
4.
5.
15. Kiniry, J.R. Semantic Component Composition.
Third International Workshop on Composition Languages, in conjunction with 17th European Conference on Object-Oriented Programming (ECOOP),
Darmstadt, Germany, 2003.
16. Kuutti, K. Notes on systems supporting “Organisational context” – An activity theory viewpoint.
COMIC European project, deliverable D1.1, 1993,
pp 101- 117.
Bourguin, G. and Derycke, A. Systèmes interactifs
en co-évolution - réflexions sur les apports de la
théorie de l’activité au support des pratiques collectives distribuées. Revue d'Interaction HommeMachine, Vol 6, N° 1, 2005.
17. Lewandowski, A. and Bourguin, G. Gestion de l'inter-activités pour le support au développement logiciel coopératif. Actes IHM 2005, Toulouse, France,
27-30 Septembre 2005, pp. 99-106.
Bourguin, G., Derycke, A., Tarby, J.C. Beyond the
Interface: Co-evolution Inside Interactive Systems –
A proposal Founded on Activity Theory. Springer
Verlag, People and Computer vol. 15 – Interaction
without Frontiers, Proc. of HCI’2001, Blandford,
Vanderdonckt, Gray (eds), 2001, pp. 297-310.
6.
Bruins, A. The Value of Task Analysis in Interaction Design. In Task to Dialogue: Task-Based User
Interface Design, Workshop, CHI’98, Los Angeles,
April 18-23, 1998.
7.
Clerckx, T., Luyten, K., Coninx, K. DynaMo-AID: a
Design Process and a Runtime Architecture for Dynamic Model-Based User Interface Development. In
The 9th IFIP Working Conference on Engineering
for Human-Computer Interaction, jointly with the
11th International Workshop on Design, Specification and Verification of Interactive Systems, Tremsbüttel Castle, Hamburg, Germany, July 11-13, 2004,
Pre-Proceedings, pp. 142-160, 2004.
8.
14. Javadoc, sur Wikipédia.fr, disponible à l’adresse :
http://fr.wikipedia.org/wiki/Javadoc
18. Lu, S., Paris, C., Vander Linden, K. and Colineau,
N. Generating UML Diagrams From Task Models.
In Proc. of CHINZ'03, July 3-4 2003, Dunedin, New
Zealand.
19. Luyten, K., Clerckx, T., Coninx, K., Vanderdonckt,
J. Derivation of a Dialog Model from a Task Model
by Activity Chain Extraction. In Interactive Systems: Design, Specification, and Verification, 10th
International Workshop DSV-IS, Funchal, Madeira
Island, Portugal, June, 2003.
20. Luyten, K., Vandervelpen, C., Coninx, K. Task
Modeling for Ambient Intelligent Environments:
Design Support for Situated Task Executions. In
The 4th International Workshop on TAsk MOdels
and DIAgrams for user interface design (TAMODIA
2005), Gdansk, Poland, 2005, pp. 87-94.
21. Medjahed, B., Bouguettaya, A., Elmagarmid, A.K.
Composing Web services on the Semantic Web. In
The International Journal on Very Large Data
Bases Vol. 12(4), Springer, Nov 2003, pp. 333-351.
Cubranic, D., Murphy, G.C., Singer, J., Booth, K.S.
Learning from project history: a case study for software development. In Proceedings of CSCW04,
Chicago, Illinois, USA, ACM Press, 2004, pp. 8291.
Delotte, O., David, B.T., Chalon R. Task Modelling
for Capillary Collaborative Systems based on Scenarios. In [33], pp. 25-31.
22. Mori, G., Paterno, F., Santoro, C. CTTE: Support
for Developing and Analysing Task Models for Interactive System Design. In IEEE Transactions on
Software Engineering, Volume 28, Issue 8, 2002,
pp. 797-813.
10. Diaper, D. and Stanton, N. Handbook of Task
Analysis for Human-Computer Interaction. Lawrence Erlbaum Associates Pubs, London, 2004.
23. Nunes, N. Falcão e Cunha, J. Towards a UML profile for interaction design: the Wisdom approach. In
Proc. of the UML 2000 Workshop, 2000.
9.
11. Ferris, C. and Farrel, J. What are web services?
Communications of the ACM, 46(6), 2003, pp. 31.
153
24. Object Technology International, Inc. Eclipse Platform Technical Overview, Février 2003. Disponible
à l’adresse : http://www.eclipse.org
32. Scogings, C., Phillips, C. Linking Task and Dialogue Modeling: Toward an Integrated Software
Engineering Method. In [10], pp. 551-566.
25. O'Neill, E., Johnson, P. Participatory task modelling: users and developers modelling users' tasks and
domains. In [33], pp. 67-74.
33. Slavík, P., Palanque, P. (eds.). Proceedings of the
Third International Workshop on Task Models and
Diagrams for User Interface Design - TAMODIA
2004. November 15 - 16, 2004, Prague, Czech Republic, ACM 2004.
26. Paris, C., Colineau, N., Lu, S., and Vander Linden,
K. Automatically generating effective online help.
International Journal on Elearning, ISSN 15372456, Volume 4, Issue 1, 2005, pp. 83-103.
34. Suchman, L. Plans and Situated Actions. Cambridge
University Press, Cambridge, UK, 1987.
35. Tarby, J-C. and Barthet, M-F. Analyse et modélisation des tâches dans la conception des systèmes
d’information : mise en oeuvre avec la méthode
Diane+. In Kolski C., Analyse et conception de
l’IHM, Interaction Homme-Machine pour les Systèmes d’information, volume 1, Paris : Hermes,
2001.
27. Paterno, F. ConcurTaskTrees: An Engineered Notation for Task Models. In [10], pp. 483-501.
28. Pinheiro da Silva, P. Object Modelling of Interactive
Systems: The UMLi Approach. PhD's thesis, University of Manchester, United Kingdom, 2002.
29. Rabardel, P. From artefact to instrument. In Interacting with Computers, 15(5), October 2003, pp.
641-645.
36. van der Aalst, W. Don't go with the flow: Web
services composition standards exposed. Trends
Controversies Jan/Feb 2003 issue of IEEE Intelligent Systems, 2003.
30. Reichart, D., Forbrig, P., Dittmar, A. Task models
as basis for requirements engineering and software
execution. In [33], pp. 51-58.
37. Wang, N., Schmidt, D.C., O’Ryan, C. Overview of
the CORBA Component Model. In [13], pp. 557572.
31. Richard, J-F. Logique de fonctionnement et logique
d'utilisation. Rapport de recherche INRIA N° 202,
Avril 1983.
154
Interaction multimodale pour la recherche
d’information dans une base de données de réunions
Agnes Lisowska
Mireille Betrancourt
ISSCO/TIM/ETI, University of Geneva
1211 Geneva 4, Switzerland
[email protected]
TECFA / FPSE, Université de Genève
CH 1211 Genève 4, Suisse
[email protected]
ABSTRACT
appelée SmartRoom a été conçue pour enregistrer les
réunions de telle sorte que les données multimodales
résultantes puissent être facilement synchronisées, traitées
et stockées. Par exemple, dans le projet IM2, dans lequel
le présent travail est inséré, les réunions sont enregistrées
au moyen de l’outil SmartRoom [7] et les données résultantes sont stockées dans une base de données qui contient
les informations visuelles et audio d'une réunion, une
transcription des textes de la réunion, ainsi que divers
niveaux d'annotation, y compris linguistiques (des actes
de dialogue, des segments de matière, des mots-clés) et
métaniveaux (actions de réunion). En outre, les données
de réunion contiennent les versions électroniques de tous
les documents utilisés lors des réunions, les notes prises
par les participants, et ce qui a été écrit sur le whiteboard
électronique disponible dans la pièce.
Une question centrale est alors comment un utilisateur
réel, tel que l’employé d'une compagnie qui emploie un
tel SmartRoom, peut mieux exploiter ces données. Tucker et Whittaker [10] fournissent une bonne vue d'ensemble des types de navigateurs de réunion qui ont été développés dans divers projets et suggèrent une taxonomie en
4 catégories –audio, vidéo, artefact et discours. Cependant, les outils de navigation proposés pour ces données
de réunion reposent sur les dispositifs d’entrée standard,
souris et de clavier. A notre connaissance, aucune recherche ne s’est penché sur la possibilité d'incorporer l'entrée
multimodale dans le système de navigation et de récupération de données multimodales, en l’occurrence des documents de réunions.
In this paper we discuss the results of user-based experiments to determine whether multimodal input to an interface for browsing and retrieving multimedia meetings
gives users added value in their interactions. We focus our
work on interaction with the Archivus interface using
mouse, keyboard, voice and touchscreen input. We find
that voice input in particular does appear to give added
value, especially when used in combination with more
familiar modalities such as the mouse and keyboard. We
conclude with a discussion of some of the contributing
factors to these findings and directions for future experiments.
KEYWORDS
Multimodal interaction, meeting database, information
search.
RESUME
Cet article présente les résultats d’une expérience explorant les effets de l’utilisation de modalités d’entrée multimodales pour la navigation et la recherche dans une base
de documents de réunions multimédia. Nous nous sommes intéressés particulièrement à l’interaction avec
l’interface Archivus sous différentes modalités (souris,
clavier, voix et écran tactile). Notre expérience préliminaire montre que la voix facilite l’interaction, en particulier lorsqu’elle est combinée avec des modalités plus
familières comme le clavier et la souris. Nous concluons
sur une discussion des facteurs qui expliqueraient ces
résultats et les expériences que nous allons mener pour
vérifier ces hypothèses.
Oviatt [8] déclare que l'entrée vocale combinée avec la
souris et le clavier était l’une des combinaisons de modalité les plus tôt utilisées dans les systèmes multimodaux.
Dans ces systèmes, le langage naturel a été préféré pour
permettre «une plus grande puissance expressive pour
l'utilisateur». Les récentes recherches sur les interactions
multimodales se sont intéressés à des domaines impliquant des tâches spatio-temporelles comme tracer des
actions sur une carte [8], où stylo la voix sont souvent
employées. Les résultats ont prouvé que les utilisateurs
agissent de façon multimodale dans de tels systèmes.
Ainsi, dans la combinaison stylet-voix, le stylet est
MOTS CLES
Interaction multimodale, base de données de réunion,
recherche d’information.
INTRODUCTION
Dans le cadre de projets1 impliquant la collection de
données multimodales de réunion, une interface spécifique
1
The IM2 project http://www.im2.ch, the AMI project
www.amiproject.org, The Meeting Room Project at Carnegie Mellon University, http://www.is.cs.cmu.edu/mie/,
Rich transcription of natural and impromptu meetings at
ICSI,
Berkeley,
http://www.icsi.berkeley.edu/icsi-
ro.html, and the Multimodal
http://www.m4project.org/.
155
Meeting
Manager
utilisé pour désigner des éléments tels que les symboles,
les localisations et les objets physiques, alors que la voix
est employée pour les éléments temporels ou plus abstraits de l'interaction [8]. La modalité vocale est également employée dans les systèmes conversationnels dans
un contexte d’interaction téléphonique qui n’implique pas
d’interface graphique [3, 4, 11]. D’autres recherches sur
la modalité vocale concernent les interactions avec un
monde virtuel, comme dans le système Hans Christian
Anderson, où l’enfant peut converser avec une représentation virtuelle de l’auteur de contes de fées pour apprendre
sur sa vie ou ses histoires [1]. Le système sur lequel
porte cette étude s’inspire de ces deux types d’interactions
pour créer une interface conversationnelle multimodale.
LE SYSTEME ARCHIVUS
Le système Archivus, décrit en détail dans [6], a été conçu
sur la base des indications relevées dans une analyse des
besoins pour l’interface d’exploration et de recherche de
données de réunions [5]. Les données recueillies dans cette
étude ont permis de dégager le type d’informations que les
utilisateurs voudraient rechercher à propos des réunions,
ce qui nous a aidé à structurer à la fois la disposition des
fonctionnalités de l’interface et les chemins que les utilisateurs emprunteraient pour trouver l’information dans la
base de données. En outre, le système a été conçu pour
être multimodal de façon flexible, ce qui signifie que
l’utilisateur peut employer la modalité d’entrée qu’il
souhaite (dans ce cas souris, clavier, écran tactile ou
voix), l’employer seule ou en combinaison avec d’autres
modalités. Cette flexibilité nous permet d’étudier comment les utilisateurs gère la multimodalité d’entrée lorsque les contraintes d’utilisation sont minimales.
Notre hypothèse est que l’exploitation des données de
réunions pourrait être facilitée par l’utilisation d’une
interface conversationnelle qui permettrait l’emploi d’une
variété de modalités d’accès à l’information: requêtes
complexes en langage naturel par la voix et/ou le clavier,
et dispositifs de pointage avec la souris et/ou directement
sur un écran tactile. La multimodalité devrait être particulièrement adéquate dans ce contexte, dans la mesure où les
informations peuvent être stockées dans différentes réunions et sur différents médias, impliquant des requêtes
complexes.
La Figure 1 présente l’interface dont les différents éléments sont numérotés et décrits ci-après.
Dans le système à l’étude, le langage naturel peut être
utilisé en entrée vocale ou écrite au clavier et peut être
interprété à deux niveaux. Le premier niveau est celui des
commandes, où le langage est utilisé pour contrôler
l’interface, comme on cliquerait sur des objets de
l’interface graphique. Ce niveau ne nécessite pas de traitement particulier au niveau du système si ce n’est
l’implantation d’un système de reconnaissance vocale. Le
deuxième niveau est celui des requêtes complexes exprimées de façon libre pour la recherche d’informations dans
la base, ce qui nécessite d’équiper le système d’un module
d’interprétation syntaxique et sémantique de l’entrée utilisateur.
Figure 1: L’interface du système Archivus.
Pour rendre l’interface plus familière aux utilisateurs, il a
été choisi d’utiliser la métaphore de la bibliothèque ou des
archives. Dans cette métaphore, chaque réunion est représentée par un livre (zone 2) et l’ensemble de la base par
une étagère (zone 1). À tout moment, l’utilisateur voit
l’étagère, et les réunions pertinentes pour la recherche en
cours sont mises en évidence. Quand un utilisateur ouvre
un livre, il a accès à tous les aspects de la réunion, y
compris tous les médias associés à cette réunion, qu’ils
soient audio, vidéo ou textuels. Les utilisateurs peuvent
explorer ces réunions comme ils le feraient avec un livre,
peuvent lancer les médias audio et visuels (zone 3) ou
rechercher des éléments particuliers dans une réunion.
En collaboration avec nos collègues du Laboratoire
d’Intelligence Artificielle de l’Ecole Polytechnique de
Lausanne, nous avons participé à la conception d’un
système, Archivus, [6] poursuivant les objectifs mentionnés précédemment. Le présent article décrit les résultats d’une expérience dont l’objectif était de déterminer si
la multimodalité en entrée améliore l’interaction avec une
base de données de réunions multimodales utilisant le
système Archivus, et le cas échéant, de quelle nature est
cette interaction multimodale. Il est important de noter
que nous définissons l’amélioration en termes d’efficience
accrue (nombre d’informations trouvées dans un temps
donné), d’utilité (l’information peut-elle être retrouvée
ainsi), et de satisfaction globale (opinion générale de
l’utilisateur).
Les utilisateurs peuvent spécifier leurs critères de recherche de deux façons: premièrement, en utilisant la barre
156
res, le type d’expression langagière utilisé et l’efficacité
pour accomplir les recherches dans la base. Pour obtenir
ces informations, les interactions de l’utilisateur avec le
système ont été enregistrées à l’aide de deux caméras (une
caméra filmant le visage et une filmant les mains et les
dispositifs d’interaction) et d’un équipement qui enregistrait tout ce qui se déroulait sur l’écran de l’utilisateur. Le
dispositif comprenait un ordinateur (dans ce cas un PC de
bureau avec un écran tactile), des haut-parleurs, une souris
sans fil et un microphone main libre.
de recherche (zone 5) où les utilisateurs peuvent demander
au système de trouver l’information qu’ils cherchent en
entrant une requête en langage naturel. Il peut s’agit de
mots clé ou d’expressions linguistiques plus complexes.
Cependant, même si les utilisateurs peuvent poser des
questions de forme très libres comme par exemple «Qui
était en retard à la réunion du 21 janvier?», le système
ne fournit pas une réponse mais indique les documents de
la réunion qui peuvent contenir la réponse (en zone 2). La
deuxième façon de rechercher de l’information consiste à
utiliser les boutons de critères (zone 6). Ces boutons
servent aussi de représentation des annotations sousjacentes dans la base de données. En cliquant sur ces
annotations, les utilisateurs peuvent naviguer dans la base
pour atteindre les informations recherchées. De cette
manière, les utilisateurs novices peuvent apprendre quelles sont les annotations et options d’interaction disponibles dans le système. Les experts quant à eux peuvent
déjà connaître les options et annotations de la base –dans
ce cas, ils peuvent directement émettre une requête vocale
pour atteindre des éléments précis en se servant des critères de la base. Néanmoins, dans une situation où ils ne
pourraient pas utiliser la voix, ils peuvent accéder à la
même information en interagissant avec les boutons de
navigation
Dans la mesure où nous envisageons que l’usage de la
multimodalité, et particulièrement de la modalité vocale,
n’apporte de valeur ajoutée que si l’utilisation du langage
naturel est possible, il fallait donc permettre l’utilisation
du langage nature dans cette expérience. Or un système
robuste et fiable de traitement du langage naturel vocal ne
peut être développé que si l’on connaît les contraintes que
le système doit satisfaire et notamment le type de vocabulaire utilisé et le type d’expression que le système doit
pouvoir traiter. C’est pourquoi nous avons employé la
méthode du Magicien d’Oz [2, 9]. Selon cette méthode,
les utilisateurs interagissent avec ce qu’ils croient être un
système finalisé comportant un module de traitement du
langage naturel (en plus des autres modalités
d’interaction). En réalité, la reconnaissance de la parole et
le traitement de la requête sont simulés par un humain, le
«magicien», qui intervient sur l’interface depuis une
autre pièce. Le magicien entend ce que dit l’utilisateur et
voit l’état son interface, de sorte à pouvoir gérer
l’interaction de façon transparente. Dans l’environnement
expérimental que nous avons utilisé, l’information de la
caméra de face, les entrées micro et l’écran de l’utilisateur
étaient directement transmis au magicien, qui disposait de
deux ordinateur: un pour le traitement de la requête de
l’utilisateur, l’autre pour visualiser l’écran de l’utilisateur.
Un troisième écran montrait le visage de l’utilisateur
pendant qu’il interagit avec l’interface pour que le magicien puisse voir ses réactions. Toutes ces informations
permettaient au magicien d’avoir une vision globale de
l’interaction et de simuler le traitement langagier de façon
aussi adéquate que possible.
Les utilisateurs sont également guidés dans leurs interactions par un système d’aide (zone 4) qui leur donne un
feedback par rapport à leur recherche et des indices concernant les zones où l’information a des chances de se trouver. Enfin, une liste des critères courants (zone 7) sert à
rappeler à l’utilisateur les critères qu’il a entrés dans le
système depuis le début de l’interaction. Cela permet à
l’utilisateur d’enlever tout critère qui s’avèrerait non pertinent sans avoir à respécifier les autres, ce qui est particulièrement utile lorsque les critères ont été générés par le
système à partir d’une entrée en langage naturel. La zone
8 présente des boutons de commande générale du système
comme «Aide» et «Initialisation».
Le système Archivus utilisé dans cette expérience n’avait
pas encore de module de reconnaissance de la parole et
n’avait qu’un module élémentaire de traitement de requêtes
en langage naturel. C’est pourquoi nous avons utilisé un
paradigme Magicien d’Oz pour simuler les fonctionnalités
qui n’étaient pas opérationnelles (voir section suivante).
Loin d’être un obstacle, la simulation permet
d’expérimenter l’interaction multimodale avec un minimum de contraintes sur la situation et sur la tâche.
L’ENVIRONNEMENT
L’EXPERIENCE
La présente étude est à considérer comme une expérience
préliminaire qui sera suivie d’expériences plus ciblées.
Elle a pour objectif d’évaluer les performances des utilisateurs avec le système Archivus en fonction de la modalité
d’entrée utilisée (souris, clavier, voix, écran tactile ou une
combinaison de ces modalités) et d’évaluer l’usage spontané de modalités nouvelles comme la voix et l’écran
tactile.
EXPERIMENTAL
Nous avons mené une expérience pour explorer
l’interaction multimodale dans une base de données multimodales dans le contexte de l’archivage de documents de
réunions. En particulier, nous nous sommes intéressés à
l’ordre et la fréquence d’utilisation de modalités particuliè-
Participants
Les participants étaient 24 utilisateurs (11 femmes et 13
hommes) principalement entre 18 et 35 ans. Ils n’étaient
157
pas de langue maternelle anglaise mais maîtrisaient
l’anglais. La majorité (63%) assistait à au moins une
réunion par mois. Dans la mesure où les systèmes
d’interrogation de base de données de réunions sont encore
au stade de prototype, nous ne pouvions pas trouver
d’experts sur ce type d’interface. Toutefois, tous les utilisateurs utilisaient l’informatique au moins 2 heures par
jour, et 67% l’utilisaient entre 5 et 10 heures par jour. Le
système d’exploitation le plus utilisé était Microsoft
Windows (83% des utilisateurs), suivi d’Unix (12 %)
puis Apple (5%). Les utilisateurs ont rapporté utiliser
fréquemment (plus d’une fois par semaine) les applications suivantes: navigateurs internet (100% des utilisateurs), traitement de texte (83%), lecteur vidéo (54%),
lecteur audio (67%), base de données (25%). En outre,
17% des utilisateurs ont déjà utilisé la modalité vocale
pour interagir avec un ordinateur et 88% ont déjà utilisé
un écran tactile. En effet, en Suisse de nombreux services
(banques, billetteries de train, etc.) utilisent des automates
à écrans tactiles.
L’ordre dans lequel les questions étaient posées était varié
aléatoirement entre les participants.
Procédure
La passation était individuelle. On demandait d’abord aux
participants de remplir un questionnaire factuel (données
démographiques et usages informatiques) et un formulaire
de consentement. Le scénario d’utilisation leur était ensuite donné ainsi qu’une description du système Archivus
et de ses principales fonctionnalités (sans manipulation
du système). La passation expérimentale comportait deux
phases, de 20 minutes chacune. Dans une première phase,
les participants n’avaient accès qu’à un sous-ensemble de
modalités en fonction de la condition à laquelle ils étaient
affectés (cf. Plan expérimental). Ils devaient alors répondre à 11 questions (5 vrai/faux, 6 à réponses courtes).
Dans une seconde phase, les participants avaient accès à
toutes les modalités et devaient répondre à 10 questions (5
vrai/faux, 5 à réponses courtes). Enfin, les participants
répondaient à un questionnaire post-expérimental et à un
bref entretien avec l’expérimentateur. Pendant les deux
phases de l’expérience, les participants étaient seuls dans
la pièce, l’expérimentateur n’intervenant que qu’entre les
deux phases pour donner le deuxième questionnaire
Plan expérimental
Au total, 4 modalités d’interaction ont été utilisées –
souris (S), voix (V), clavier (C) et écran tactile (T) – et
ont donné lieu à huit conditions en fonction de la ou des
modalités imposées en première phase (S, T, V, S-C, VC, T-V-C, S-V-C, S-T-V-C, ce dernier groupe servant de
contrôle puisque toutes les modalités étaient disponible
dès la première phase). Les conditions ont été comparées
en inter-sujets afin de contrôler le niveau d’expérience
acquis par les participants au cours de la passation.
RESULTATS ET DISCUSSION
L’analyse des données s’est portée sur quatre aspects
principaux – performance à la tâche, effet d’apprentissage,
nombre d’interactions et appréciation subjective de
l’utilisateur.
Performance de recherche d’information
Compte tenu de la familiarité des utilisateurs avec la
souris et le clavier et le peu de temps alloué pour manipuler le système, nous postulions que la condition sourisclavier serait la plus performante pour la tache de recherche d’information. Nous avons choisi comme indicateur
le nombre de réponses correctes mais aussi le nombre de
réponses trouvées, qu’elles soient ou non correctes. En
effet, nous sommes intéressés dans cette étude à
l’interaction multimodale plus qu’à l’efficacité de
l’interface de recherche d’informations (notamment outils
d’aide à la recherche, fonctionnalités).
Le tableau 1 présente le taux moyen de réponses correctes
en phase 1 pour chacune des 8 conditions. Les données du
tableau 1 montrent clairement que l’hypothèse d’une
supériorité de la condition Souris – Clavier n’est pas con-
Matériel
Le scénario d’utilisation était le suivant: les participants
devaient s’imaginer être de nouveaux employés d’une
compagnie qui utilise le système SmartRooms pour
enregistrer ses réunions et à qui le supérieur a demandé de
rechercher certaines informations avec l’interface Archivus. Les participants étaient informés du type de données
qu’ils pouvaient trouver dans la base. Le questionnaire de
recherche d’information comportait 21 questions de deux
types: des questions vrai/faux (Le budget était-il de 1000
FS?) et des questions à réponses courtes (Qui a assisté à
toutes les réunions?). Les questions étaient conçues de
sorte à ce qu’elles nécessitent l’exploration de différentes
zones et de différents types de média dans le système.
Table 1: Taux moyen (en pourcentage) et écart-type du nombre de réponses correctes en Phase 1 en fonction de la
condition2.
Conditions
Taux moy.
ET
2
S
36
3.7
V-C-S-T
25
0.22
T
24
1.6
S-V-C
24
1.6
T-V-C
21
0.22
V
18
0.67
S-C
12
0.22
V-C
6
0.22
Les chiffres dans tous les tableaux sont les moyennes calculées sur les 3 utilisateurs de chaque condition.
158
-firmée. A l’inverse, les participants dans cette condition
réalisent l’avant-dernier score. La condition SourisClavier apparaît, sur résultats observés, en deçà des conditions impliquant des modalités d’interaction nouvelle
(Voix, Tactile – Voix – Clavier, Souris – Voix – Clavier). Ce sont les participants en condition Souris qui ont
les meilleures performances, puis de la condition avec
toutes les modalités, et ensuite écran Tactile seul. Les
bonnes performances des conditions impliquant que
l’interaction déictique souris ou écran tactile suggère que
dans ce système, la recherche d’information par navigation amènerait à de meilleures performances que la recherche par requêtes verbales. Le deuxième constat est que les
conditions impliquant la voix sont plutôt efficientes, ce
qui renforce l’hypothèse selon laquelle la voix serait une
modalité intéressante dans ce contexte. En outre, il est
intéressant de noter l’efficience de la condition «toutes
modalités». L’analyse de l’activité montre que les interactions vocales représentent 17% des interactions dans
cette condition. Enfin, on note que la condition Tactile
seul semble moins efficiente que la condition Souris
seule, alors que ces deux conditions sont fonctionnellement équivalentes. Cette différence pourrait provenir
d’une moins grande familiarité des utilisateurs avec
l’écran tactile, et d’ailleurs la différence se retrouve entre
les conditions S-C-V et T-C-V. Compte tenu du faible
effectif, il n’est pas possible d’opérer des statistiques
inférentielles sur ces résultats.
de même qu’il y a plus d’interactions en condition SourisClavier-Voix qu’en condition écran Tactile-Clavier-Voix.
Cette différence pourrait s’expliquer par un effet de blocage qu’exercerait la modalité nouvelle qu’est l’écran
tactile. Parce que cette modalité n’est pas familière aux
utilisateurs, ceux-ci seraient plus hésitants à l’utiliser,
alors même qu’elle est fonctionnellement équivalente à la
souris. Cet effet de blocage pourrait également expliquer
la différence entre la condition Voix seule et Voix-Clavier
(Tableau 2, lignes 5 et 6). En effet, les participants dans
la condition Voix seule ont produits plus d’interactions
que les participants en condition Voix-Clavier, alors que
l’on aurait pu attendre l’inverse, le clavier étant une modalité familière. Il est possible que de présenter une nouvelle modalité seule incite à davantage l’utiliser qu’en
association avec la modalité la moins efficace (clavier) de
l’usuelle combinaison clavier-souris. En outre, dans la
condition Voix-Clavier, la Voix est utilisé bien plus
fréquemment que le clavier (Tableau 2 ligne 6) ce qui
suggère que la voix semble préférée au clavier. Cependant, en phase 2 où toutes les modalités sont accessibles,
les participants de la condition Voix-Clavier utilisent
alors bien plus le clavier que la voix (cf. Tableau 3).
Voix
Clavier
Analyse des interactions
1
2
3
4
5
6
S
T
S-C-V
T-C-V
V
V-C
S
268
T
Phase 1
V
C
195
150
62
0
4
62
47
8
15
2
Phase 2
25%
75%
Table 3 : Pourcentage d’interactions avec la modalité
Voix et la modalité clavier dans la condition Voix-Clavier
en phases 1 et 2 (Phase 1, voix et clavier seulement,
Phase 2, toutes modalités utilisables).
À partir des vidéos des actions utilisateurs, nous avons
relevé le nombre d’interactions réalisées dans chaque
modalité. Le tableau 2 montre le nombre total
d’interactions dans chaque modalité pour chaque condition.
Condition
Phase 1
97%
3%
Là encore, il est possible que ce changement s’explique
par la familiarité de l’interaction clavier-souris. En retrouvant l’interaction avec la souris, les utilisateurs abandonnent l’interaction vocale pour utiliser le clavier, modalité plus familière qui est automatiquement associée à la
souris et qui est habituellement considérée comme efficace. Cependant, les résultats montrent aussi que la prépondérance de l’interaction classique clavier-souris peut
être diminuée dans certaines circonstances. Par exemple,
en phase 2 de la condition Souris-Clavier, la voix est
utilisée deux fois plus que le clavier même si la souris
continue à être utilisée aussi fréquemment qu’en Phase 1.
Total
268
195
158
81
62
49
Table 2: Nombre d’interactions en phase 1 pour chaque
condition. Les cellules grisées indiquent les modalités qui
n’étaient pas disponibles.
Effet
d’apprentissage
Nous nous attendions à un effet d’apprentissage dans la
phase 2: les participants de conditions où seules étaient
disponibles les modalités langagières d’interaction (Clavier mais surtout Voix) dans la première phase devraient
davantage utiliser les modalités langagières dans la
deuxième phase. Cette attente était basée sur le fait que
les participants n’ayant pas utilisé ces modalités en première phase n’auraient qu’une expérience limitée dans les
Dans la mesure où le langage induit un temps de traitement plus lent que les modalités de pointage, nous ne
pouvons que comparer les fonctionnalités qui sont équivalentes au niveau du système. En ce qui concerne les
conditions avec modalité de pointage, le nombre
d’interactions est plus important en condition Souris
qu’en condition écran Tactile (Tableau 2, lignes 1 et 2),,
159
tionnaire fournit des données intéressantes pour interpréter
les données d’interaction.
De manière générale, les utilisateurs ont trouvé le système difficile à utiliser, ne l’ont pas trouvé convivial et
ne pensaient pas qu’ils le maîtrisaient après 40 mn
d’utilisation. En effet, les participants n’ont pas eu de
tutoriel explicite avant l’utilisation. En outre, les participants ont trouvé que l’interaction avec le langage était
particulièrement lente, du fait de l’intervention du magicien mais également parce que l’interface utilisée par le
magicien pour analyser la requête langagière n’était pas
optimale. Ainsi, les utilisateurs ont classé la souris
comme la modalité la plus efficace, à l’exception du cas
où il fallait trouver une information dans un livre de
réunion, où la souris et le clavier ont été classés comme
également efficaces.
Par ailleurs, 38% des participants ont estimé que le langage naturel n’avait pas facilité leur interaction avec le
système, contre 21% qui l’ont apprécié (28%sans opinion). Toutefois, 54% ont admis que le fait de contrôler
le système par la voix était utile. Il est possible que
l’opinion défavorable des utilisateurs provienne de la
lenteur du système et des conseils audio qui leur été fournis tout au long de l’interaction. Alors que plus de la
moitié des participants trouvaient que ces conseils étaient
compréhensibles, d’un ton et d’une longueur corrects, ils
ont estimé qu’ils ne leur donnaient pas assez
d’information sur la façon de travailler avec le système.
En outre, plus de la moitié n’ont pas aimé la voix synthétique utilisée pour générer ces conseils. Ces deux
points précis seront pris en compte pour des versions
futures du système.
interactions langagières et donc ne seraient pas enclins à
les utiliser en deuxième phase. Le tableau 4 montre les
pourcentages d’utilisation de chaque modalité en phase 2
en fonction de la condition.
Conditions
1
2
3
4
5
V
V-C
S-C
V-C-S-T
S
Pointage
S
T
89
2
88
0
40
26
61
18
84
5
Langage
V
C
5
4
3
9
29
5
4
17
7
4
Table 4: Taux d’interactions par modalité en phase 2
en fonction de la condition (modalités disponibles en
phase 1).
Contrairement à nos attentes, ce sont les participants qui
ont bénéficié d’une interaction traditionnelle en phase 1
(Souris-Clavier) qui ont utilisé la voix le plus fréquemment en phase 2 (29%). Les participants qui ont eu accès
à toutes les modalités (Tableau 4, ligne 4) sont ensuite
ceux qui utilisent le plus fréquemment les interactions
langagières, mais principalement par le clavier. À
l’inverse, les participants des conditions avec langage seul
(lignes 1 et 2) ont très peu utilisé ces modalités
d’interaction. Enfin, les participants ne disposant que de
la souris ont utilisé un paradigme d’interaction familier
en phase 1 et l’ont maintenu en phase 2.
Notre interprétation est la suivante: les participants de la
condition toutes modalités ont pu explorer les modalités
langagières en phase 1 et revenir à des modalités familières au cas où. Ils auraient donc volontiers utilisé les
modalités langagières en phase 2 parce que a) ils étaient
déjà familiers du système et b) ils savaient qu’ils pouvaient se rabattre sur des modalités «de confort». À
l’inverse, les participants qui n’avaient que l’entrée langagière ont pu se sentir perdus ou frustrés lors des interactions initiales avec le système en n’ayant que des modalités peu familières. Par conséquent, lorsqu’ils ont eu la
possibilité d’utiliser toutes les modalités en phase 2, ils
sont immédiatement revenus à des modalités familières.
Un autre résultat intéressant est que les utilisateurs en
condition écran Tactile ont utilisé majoritairement la
souris (60%) plutôt que l’écran tactile (26%) en phase 2,
ce qui renforce l’hypothèse selon laquelle la souris procure un haut niveau de confort dans les interactions initiales avec un nouveau système.
CONCLUSIONS ET PERSPECTIVES
Cet article rapporte des résultats encourageants concernant
l’utilisation de la multimodalité dans des interfaces de
base de données de réunion. En particulier, nous avons vu
que les utilisateurs pouvaient être encouragés à utiliser
des modalités d’interaction nouvelles, et que certaines de
ces modalités, en particulier la voix, pouvait même sur
un temps court d’apprentissage, s’avérer efficace. En
outre, il semble que le fait de pouvoir utiliser des modalités plus familières en début d’interaction avec le nouveau
système favorise l’utilisation de ces modalités nouvelles,
en l’occurrence la modalité voix, probablement parce
qu’elles augmentent le sentiment de «confort» des
utilisateurs. Parallèlement, les résultats montraient que la
seule modalité de pointage provoquait des performances
élevée, ce qui suggère que la récupération des information
dans le système Archivus se fait plus facilement par
navigation que par requête en langage naturel.
Les limites de l’expérience présentée ici tiennent en premier lieu à la difficulté d’utilisation du système Archivus
lui-même, comme l’ont montré les faibles performances
de réussite des tâches en temps limité. Ces problèmes
d’utilisation ont pu entacher l’efficience des différentes
Satisfaction des utilisateurs
Les réactions des utilisateurs par rapport au système,
telles que rapportées dans le questionnaire d’évaluation
subjective posé à l’issue de l’expérience, ont mis en
évidence de sérieux problèmes de fonctionnement du
système qui ont depuis été résolus. Toutefois, ce ques-
160
REMERCIEMENTS
modalités d’interaction. Une deuxième limite provient du
caractère exploratoire de cette expérience, qui a comparé
un grand nombre de conditions d’interaction avec un
faible nombre de participants. Les résultats obtenus ont
pour objectif de suggérer des hypothèses qui pourront être
explorées dans les expériences suivantes.
Les auteurs aimeraient remercier Susan Armstrong, Martin Rajman, Mirek Melichar et Marita Ailomaa de leur
collaboration à la conception et au développement du
système Archivus, et à la passation de l’expérience .
Merci à Marcin Bogobowicz d’avoir conçu la composante
graphique de l’interface et à la fondation Suisse de la
recherche ainsi qu’à l’Université de Genève d’avoir financé cette recherche.
En ce qui concerne l’utilisation du système lui-même,
une nouvelle version du système Archivus a été réalisée
en fonction des résultats de cette expérience. Un test
utilisateur est en cours de passation pour vérifier son
ergonomie d’utilisation, notamment au niveau du temps
d’apprentissage de l’interface. Par exemple, l’ouverture
d’un livre de réunion nécessitait deux clics consécutifs
plutôt qu’un double-clic traditionnel, ce qui a semé la
confusion chez les utilisateurs, d’autant que tous les
objets ne réagissaient pas de la même façon. D’autre part,
la voix synthétique utilisée pour donner des conseils était
jugée désagréable, peu informative et la plupart des utilisateurs l’ont désactivée. Ceci a pu les rebuter d’utiliser la
modalité vocale. Les indices audio ont été révisés et la
voix améliorée pour la prochaine version. En outre, plutôt qu’un écran tactile, le système sera équipé d’un écran
réactif à un stylet, plus habituel pour ce type
d’équipement de bureau et aussi plus précis. Enfin, au
niveau méthodologique, la prochaine expérimentation, à
plus grande échelle, sera ciblée sur le test des hypothèses
relevées dans cette première expérience. L’efficacité de
l’interaction sera prise en compte en plus de l’efficience et
les démarches utilisateurs seront analysées à l’aide d’un
modèle de tâche pour chaque recherche.
La contribution principale de cette recherche était d’étudier
la contribution de l’interaction multimodale pour la navigation et la recherche dans une base de données multimodale (en l’occurrence des données de réunions). Toutefois,
cette recherche a soulevé des questions méthodologiques
intéressantes pour la recherche sur des modalités
d’interaction innovantes. En effet, il est nécessaire que
l’utilisateur interagisse suffisamment avec le système,
avec des tâches authentiques et signifiantes, pour se familiariser avec ses fonctionnalités et son contenu. Cette
condition est déjà en elle-même difficilement réalisable en
condition de laboratoire, nécessaire tant que l’expérience
se déroule en magicien d’Oz. D’autre part, on ne peut
séparer
l’utilisation des modalités d’interaction de
l’utilisabilité générale du système, de sorte que les résultats doivent être contextualisés en fonction du système
concerné et en l’occurrence, de l’organisation des documents et des fonctionnalités de navigation disponibles.
Ces obstacles méthodologiques expliquent la difficulté
que rencontrent les recherches sur les modalités
d’interaction innovantes pour satisfaire à la fois la rigueur
méthodologique et l’écologie de la situation étudiée,
seules conditions pour générer des résultats exploitables
dans d’autres contextes.
BIBLIOGRAPHIE
1. Bernsen, N.O. and Dybkjaer, L. Evaluation of
SpokeMultimodal Conversation. In proceedings of
the International Conference on Multimodal Interfaces, ICMI -04. (October 14-15, 2004 State College,
Pennsylvania, USA), ACM Press, pp. 38-45.
2. Dahlbäck, N., Jönsson, A., and Ahrenberg, L..
Wizard of Oz Studies - Why and How. In the International Workshop on Intelligent User Interfaces. 1993.
Orlando, FL, USA: ACM Press, New York, pp 193200.
3. Karat, C., Vergo, J., and Namahoo D. Converstional
Interface Technologies. In The Human-Computer Interaction Handbook. Jacko, J.A., and Sears, A.
(eds). Lawrence Erlbaum Associates Inc., Mahaw,
New Jersey. 2003, pp 169-187.
4. Lai, J., and Yankelovich, N. Conversational Speech
Interfaces. In The Human-Computer Interaction
Handbook. Jacko, J.A., and Sears, A. (eds). Lawrence Erlbaum Associates Inc., Mahaw, New Jersey. 2003, pp 698-714.
5. Lisowska, A., Popescu-Belis, A., and Armstrong, S.
User Query Analysis for the Specification and Evaluation of a Dialogue Processing and Retrieval System. In proceedings of the Fourth International
Conference on Language Resources and Evalation LREC'2004. ( May 26-28, 2004, Lisbon, Portugal).
Vol 4, pp. 993-996.
6. Lisowska, A., Rajman, M., and Bui, T.H.
ARCHIVUS : A System for Accesssing the Content
of Recorded Multimo- dal Meetings. In Lecture Notes
in Computer Science 3361, S. Bengio and H. Bourlard, (Eds). Springer Verlag Publications, 2005, pp.
291-305.
7. Moore, D. The IDIAP Smart Meeting Room.
IDIAP Report. Martigny, Switzerland, 2002. p.13.
8. Oviatt, S., Multimodal Interfaces, In The HumanComputer Interaction Handbook. Jacko, J.A., and
Sears, A. (eds). Lawrence Erlbaum Associates Inc,
Mahaw, New Jersey, 2003, pp 286-304.
161
9. Salber, D. and Coutaz, J. Applying the Wizard of Oz
Technique to the Study of Multimodal Systems. In
3rd International East/West Human Computer Interaction Conference. Moscow, Russia, 1993. Springer
Verlag Publications, pp 291-230.
In Lecture Notes in Computer Science 3361, S. Bengio and H. Bourlard, (Eds). Springer Verlag Publications, 2005, p. 1-11.
11. Zue, V. Conversational Interfaces: Advances and
Challenges. In the Proceedings of. Eurospeech ’97,
pp 9-18.
10. Tucker, S. and Whittaker, S. Accessing Multimodal
Meeting Data: Systems, Problems and Possibilities,
162
La prise de décision en sport de haut niveau :
un exemple chez une joueuse experte en badminton.
Anne-Claire Macquet
Philippe Fleurance
Institut National du Sport
et de l’Education Physique
11, avenue du Tremblay
75012 Paris
[email protected]
Institut National du Sport
et de l’Education Physique
11, avenue du Tremblay
75012 Paris
[email protected]
ABSTRACT
To produce performance in dynamic situation, elite
athlete quickly makes efficient decisions. For theoretical
models [e.g. 8, 1, 5], decision making is composed of
two phases: situation assessment and decision making.
The present study focuses on decision making of a
woman expert badminton player during dynamic
situations. Two matches were videotaped and selfconfrontation interviews were used to collect data.
Interviews were transcribed verbatim. Results were
organised in three points. The first point revealed three
types of intentions during a rally: to maintain the rally; to
take the advantage; and to finish the point. It also
revealed eight types of decisions related to a situation: to
ensure an action; to observe the opponent’s decision; to
put pressure on the opponent; to surprise the opponent;
to reproduce an efficient action; and to play wide. The
second point showed differences between decisions
during the matches and differences in the decision
frequencies (e.g. the player often reproduced an efficient
action). The third point revealed different types of
information and knowledge which were reported during
decision making (e.g. information related to the
opponent, knowledge about rules). Results according to
different phases of decision making are discussed in
relation to theoretical models. They allow to show the
mode of assessment situation, its progressive nature, the
taking time in consideration in decision making and the
origin of decision (retrieved from memory or emergent).
Consequences for training are suggested.
RESUME
Pour produire de la performance en situation complexe,
le sportif de haut niveau prend rapidement des décisions
efficaces. Des modèles théoriques [e.g. 8, 1, 5]
envisagent la prise de décision à travers deux phases : la
compréhension de la situation et le choix d’une décision.
La présente étude a examiné les prises de décision d’une
joueuse experte en badminton, en situation dynamique.
Deux matches ont été filmés ; deux entretiens d’autoconfrontation ont été menés, puis retranscrits verbatim.
L’analyse des données a mis en évidence trois points
principaux. Le premier a permis d’identifier trois types
d’intentions dans l’échange, et huit types de décisions
en situation. Les intentions visaient à : maintenir
l’échange, prendre l’avantage, finir l’échange. Les
décisions visaient à : réaliser un choix restreint, assurer
son action, observer l’adversaire, l’influencer, lui mettre
de la pression, la surprendre, reproduire une action
efficace et agrandir le court. Le deuxième point a montré
des différences dans les types de décisions prises au
cours des matches et une prégnance de certaines
décisions (e.g. reproduire une action efficace). Le
troisième point a permis d’identifier diverses
informations et connaissances (e.g. informations sur les
adversaires, connaissances sur les règles). Les résultats
liés aux différentes phases de la prise de décision sont
discutés en référence aux modèles théoriques. Ils
permettent de montrer le mode de compréhension de la
situation, son caractère progressif, la prise en compte du
temps dans la prise de décision et l’origine de la
décision (préconstruite ou émergente). Des implications
sont envisagées pour l’entraînement.
KEYWORDS.
Decision-making,
player, dynamic situations.
expert
badminton
INTRODUCTION
Pour produire de la performance en sport de haut niveau,
les athlètes sont amenés à prendre des décisions efficaces
et à les mettre en œuvre dans le cours du jeu. Si
l’expertise dans leur domaine leur permet de les réaliser
avec efficience, la question du choix demeure délicate.
La décision vise un résultat particulier, elle doit
permettre, en badminton, de contrôler tout ou partie de la
situation et aboutir à un gain de l’échange ou à un
MOTS CLES. Prise de décision, joueuse experte en
badminton, situations dynamiques
163
avantage dans l’échange pour le joueur. En référence aux
travaux en ergonomie cognitive [2], la majorité des
situations sportives est dynamique : les situations
évoluent en partie en dehors du contrôle de l’opérateur.
En badminton, le joueur et son adversaire contribuent à
la faire évoluer : la décision de l’un dépend largement de
l’action de l’autre. Une minorité de situations (e.g. le
service) est statique : le serveur initie l’échange, sa
décision est première dans l’échange. Les situations sont
peu prévisibles ; leur incertitude peut être liée à la nature
de l’événement, au lieu d’apparition, au temps (moment
Les
d’apparition et temps disponible pour agir).
situations apparaissent complexes. Elles sont mal
définies, elles se réalisent sous pression temporelle et
sont susceptibles de contenir des risques [8] : le joueur
est amené à agir vite, à prendre des risques au regard de
l’évolution du score. La prise de décision est rendue plus
difficile en situation mal définie et incertaine, lorsque
que le joueur n’a le temps ni de tout comprendre ni de
tout faire.
contenus dans une situation problème stockée en
mémoire, il peut choisir une ou la décision
correspondant à ce problème et l’exécuter. Le processus
de prise de décision consiste ainsi en deux phases : une
phase de compréhension de la situation et une phase de
choix d’une décision. Ce processus en deux étapes a été
expliqué par le modèle de la « Naturalistic Decision
Making » [8] pour des décisions prises en situations mal
définies, incertaines, changeantes, à forte pression
temporelle et contenant des risques. L’évaluation ou
compréhension de la situation passe par une prise en
compte rapide des caractéristiques changeantes de la
situation, qui correspond à la « situation awareness » [4].
Cette compréhension procède par comparaison entre la
situation actuelle et un ensemble de situations contenues
en mémoire. Le choix d’un cours d’action est envisagé
au regard des possibilités liées à la situation. Il est réalisé
à partir d’un registre d’actions réalisables par des experts
du domaine dans des situations problèmes.
Pour le modèle de la suffisance cognitive [1], ce choix
n’est pas seulement efficace, il est également satisfaisant
pour l’opérateur qui va le réaliser. Ce modèle ne porte
pas directement sur la prise de décision, il vise plus
largement à expliquer l’activité de l’opérateur en
situation dynamique. Il apparaît séduisant pour
comprendre la prise de décision en sport de haut niveau.
Il est basé sur l’idée d’une compréhension suffisante de la
situation et du choix d’une décision efficace et
satisfaisante. La compréhension procède par actualisation
de la situation occurrente. En situation complexe,
l’opérateur ne peut pas tout comprendre : les
informations utiles ne sont pas toujours disponibles ; il
doit se satisfaire d’une compréhension partielle. Cette
dernière est le plus souvent suffisante pour agir. Le
modèle s’appuie sur des décisions optimales, sur des
compromis, pour un opérateur engagé dans une situation
à un instant donné. A partir de ce modèle, on peut
considérer que l’apprentissage ne vise pas la reproduction
d’un modèle idéal, basé principalement sur des décisions
préconstruites, mais plutôt le développement d’un modèle
de compromis, qui s’appuie à la fois sur des décisions
stockées en mémoire et automatisées pour jouer en
réflexe et sur des décisions construites localement, afin
d’assurer une adaptation permanente aux conditions
changeantes du couplage entre le joueur et la situation.
Pour gérer cette difficulté, les entraîneurs contribuent à
développer chez les joueurs un répertoire d’actions
efficaces associées à des situations spécifiques [5]. Ils
considèrent qu’une solution particulière correspond à un
type de problème. Le travail de l’entraîneur consiste
alors à identifier les problèmes rencontrés en
compétition, à les classer, à trouver des solutions et à les
travailler avec les athlètes à l’entraînement, afin qu’ils
puissent les reproduire en compétition. Les situations
proposées à l’entraînement sont standardisées.
L’incertitude propre au travail est manipulée par
l’entraîneur dans la constitution de son exercice, elle ne
renvoie pas à la constitution naturelle du jeu compétitif.
Les décisions choisies sont ainsi préconstruites, sur la
base d’un registre purement technique et tactique
maîtrisé par l’entraîneur. Ce modèle est rassurant pour
l’entraîneur et pour le joueur qui disposent d’un
répertoire d’actions correspondant à des situations
problèmes. Il est économique et permet de faire face à la
pression temporelle. L’apprentissage passe par la
perception
des
informations
pertinentes
pour
l’entraîneur, il consiste en une reconnaissance de la
situation, il vise à créer puis à renforcer les liens entre
une situation type contenue en mémoire et la situation
occurrente. L’idée consiste à apprendre à reproduire des
actions efficaces, basées sur des règles, qui prennent en
compte le jeu, l’athlète, l’adversaire.
Cette étude a visé à analyser la nature des décisions
prises en situations compétitives, par une joueuse
experte en badminton, ainsi que les éléments qui ont
contribué à ces choix. Les décisions ont été considérées
dans la temporalité des matches.
L’utilisation de ce modèle par le joueur repose sur une
analyse comparative : la situation occurrente est
comparée à un ensemble de situations contenu en
mémoire. En référence aux travaux sur la « situation
awareness » [4] et au modèle de la décision basée sur la
reconnaissance (« Recognition Primed Decision »)[8], la
comparaison s’appuie sur des traits de la situation
considérés comme saillants pour un ensemble d’experts.
Lorsque le joueur note une correspondance entre ces
traits contenus dans la situation occurrente et ceux
METHODE
La participante
Une joueuse experte en badminton a participé
volontairement à l’étude. Elle était classée parmi les
quarante meilleures joueuses mondiales au moment de
l’étude.
164
Le recueil des données
gagner l’échange. L’intention de « maintenir l’échange »
comprenait trois décisions : « assurer son action »,
« réaliser un choix restreint », « observer l’adversaire ».
Dans la première décision, la joueuse ne voulait pas
prendre de risques (exemple : « je joue la sécurité, je
vais remettre au fond », match 2, set 1, décision 4). Dans
la deuxième, elle était dans l’urgence et ses possibilités
d’action étaient réduites (exemple : « j’peux rien faire
d’autre que dégager » match 1, set 2, décision 15). Dans
la troisième, elle souhaitait tester les possibilités
adverses, pour les exploiter par la suite (exemple…
« j’fais un amorti droit … j’lai pas encore fait, j’veux
voir c’que ça donne », match 1, set 2, décision 95).
L’intention « prendre l’avantage dans l’échange »
consistait en 5 décisions : « influencer la décision
adverse », « mettre de la pression sur l’adversaire »,
« surprendre l’adversaire », « reproduire une action
efficace », « agrandir le court ». En visant à influencer
l’adversaire, elle voulait l’inciter à prendre une décision
particulière ou à la dissuader d’une décision qui l’aurait
mise en difficulté (exemple : « je sers court pour qu’elle
lobe ou qu’elle amortisse », match 2, set 2, décision 29).
En cherchant à mettre de la pression, elle souhaitait
placer l’adversaire en situation d’urgence (exemple : « je
veux descendre le volant », match 2, set 1, décision 2).
En tentant de surprendre l’adversaire, elle tentait de
s’opposer aux attentes présumées de l’adversaire
(exemple, « je fais un slice croisé pour la surprendre »,
match 2, set 1, décision 22). En visant à reproduire une
action efficace, elle optait pour une action qu’elle
maîtrisait particulièrement et dont le résultat avait été
efficace dans le passé (exemple : « je sers long, je fais
quelque chose que je maîtrise tout de suite », match 1,
set 1, décision 1). En voulant « agrandir » le court, elle
visait à amener l’adversaire à réaliser un grand
déplacement (exemple : « j’essaie d’agrandir avec un
dégagement croisé » match 2, set 1, décision 3.
L’intention « finir l’échange » concernait à la fois
l’échange et la situation, de ce fait elle pouvait être
considérée comme une intention et une décision
(exemple : « là je joue pour finir le point, j’y vais pour
marquer », match 2, set 1, décision 46).
Deux types de données qualitatives ont été recueillis :
des données issues de matches enregistrés dans leur
totalité et des données issues d’entretiens en autoconfrontation menés dans les 48 heures suivant chaque
match. Deux matches ont été filmés lors de tournois
internationaux, pris en compte pour le classement
mondial et pour la qualification aux Jeux Olympiques
d’Athènes. Ils concernaient deux adversaires différentes.
L’entretien en auto-confrontation permet de mettre à jour
les cognitions de l’athlète lors de la compétition [3]. Nos
entretiens ont porté plus spécifiquement sur l’activité
décisionnelle de la joueuse qui était amenée à décrire ses
perceptions, ses focalisations, ses communications, ses
sentiments, ses analyses à l’origine de ses choix d’action
liés aux quatre premières frappes de chaque échange, des
deux premiers sets. Le choix des décisions à analyser a
été contraint par le temps : la durée de l’entretien a été
fixé à 1h30, du fait des nombreuses activités de la
joueuse. Ce choix des décisions a été discuté avec les
entraîneurs qui les considéraient comme les plus
significatives de l’échange.
Le traitement des données
Les entretiens ont été retranscrits verbatim, puis validés
par la joueuse. Le traitement des données a procédé par
des descriptions puis par une analyse inductive. Il a été
élaboré en trois phases : la première consistait à
découper les décisions au sein des verbalisations et à
décrire
les
situations
correspondantes
(score,
comportements…). La deuxième phase a permis de
construire des catégories de décisions en rapport avec
l’évolution de la situation et des catégories d’intentions
en rapport à l’évolution de l’échange. La troisième phase
visait à identifier les catégories d’informations et de
connaissances utilisées par celle-ci pour prendre sa
décision. Le traitement a été validé par un autre
chercheur et discuté avec les entraîneurs.
RESULTATS
L’analyse des résultats a permis de mettre à jour 217
décisions : 119 dans le match 1 et 98 dans le match 2. Le
match 1 a été gagné en trois sets et le match 2 a été perdu
en deux sets.
Les intentions et les décisions au cours des matches
La mise à jour des décisions en situation et des
intentions dans l’échange
L’analyse des intentions au cours des matches a mis en
évidence la prédominance de l’intention prendre
l’avantage dans l’échange (figures 1, 2, 3 et 4). Dans le
match 1, les décisions étaient plus variées au deuxième
set qu’au premier et en seconde partie de set qu’en
première. Dans le match 2, la différence était moins
importante. La décision la plus fréquente consistait
à reproduire une action efficace. La deuxième fréquence
concernait les décisions d’agrandir le court et de mettre
la pression sur l’adversaire. La volonté de mettre de la
pression sur l’adversaire était plus marquée au match 1
et celle d’agrandir le court l’était davantage au match 2.
La troisième tendance renvoyait aux décisions d’assurer,
de réaliser un choix restreint, puis de surprendre
Les décisions et les intentions renvoyaient à des
temporalités différentes : les décisions concernaient
l’effet attendu de la décision sur la situation occurrente
et les intentions étaient liées à l’effet de la décision sur
l’évolution de l’échange. Trois types d’intention et huit
types de décisions ont été identifiés. L’intention
« maintenir l’échange » indiquait que le joueur souhaitait
poursuivre ou engager l’échange. L’intention « prendre
l’avantage dans l’échange » renvoyait à la volonté de la
joueuse d’imposer son jeu afin de mettre en place les
conditions favorables pour finir l’échange par la suite.
L’intention « finir l’échange » se référait à la volonté de
165
décision 4), (d) un événement antérieur (exemple : « ça
faisait deux fois que je descendais le volant, que je
perdais l’avantage », match 2, set 1, décision 12), (e) des
attentes concernant l’action adverse (exemple : « je
m’attends à un service court », match 2, set 1, décision
6), (f) des conséquences de l’action envisagée (exemple :
« c’est dur d’attaquer quand le volant est bien servi »,
match 1, set 2, décision 3). En envisageant l’analyse de
la situation réalisée par la joueuse pour chaque type de
décision, nous avons mis en évidence quelques
régularités, entre les éléments pris en compte pour
prendre une décision et le type de décision concomitante.
Dans ce texte, nous nous sommes limités à la
représentation des résultats liés aux décisions qui
apparaissaient régulièrement. Nous n’avons pas retenu
les décisions consistant à observer l’action adverse et à
influencer l’adversaire. Les résultats exprimés en
nombre d’occurrences décisionnelles ont montré (table
1) que la joueuse rapportait le plus souvent des
informations
concernant
son
adversaire.
Les
informations la concernant étaient moins fréquentes. Les
informations liées à la trajectoire du volant étaient
relativement
peu
verbalisées.
Ces
dernières
apparaissaient plutôt lorsque la joueuse décidait de finir
l’échange. Les informations inhérentes à l’adversaire
apparaissaient plus souvent lorsque la joueuse choisissait
d’agrandir le court, de finir l’échange, de réaliser un
l’adversaire. Ces décisions apparaissaient davantage
dans le match 2 que dans le match 1.
La décision de finir était plus fréquente dans le match 1,
que la joueuse a gagné, que dans le match 2, qu’elle a
perdu. Les décisions d’influencer l’action adverse et
d’observer l’adversaire étaient peu prises.
Les informations et les connaissances rapportées
par la joueuse pour prendre sa décision
L’analyse des verbalisations a permis de mettre en
évidence trois catégories d’informations utiles et six
catégories de connaissances. Les informations
concernaient :
(a)
l’adversaire
(comportement,
position…, exemple : « elle fait son revers », match 1,
set 1, décision 28), (b) la joueuse (comportement,
position…, exemple : « je suis très avancée », match 2,
set 1, décision 3) et (c) la trajectoire du volant (vitesse,
direction, exemple : « son lob est court », match 2, set 1,
décision 5). Les connaissances portaient sur : (a) la
joueuse (exemple : « je maîtrise pas bien le service
court», match 1, set 1, décision 3), (b) l’adversaire
(exemple : « elle fait ça tout le temps, aussitôt que le
volant est levé », match 2, set 1, décision 21), (c) les
règles individuelles (exemple : « je fais quelque chose
que je maîtrise tout de suite « , match 1, set 1, décision
1) et les règles liées à la situation (exemple : « quand je
suis en retard filet, réflexe, je lobe » match 2, set 2,
166
Adversaire
Set 1
Set 2
3
8
6
10
16
5
4
10
7
17
3
24
6
3
Assurer son action
Réaliser un choix restreint
Mettre de la pression
Surprendre l’adversaire
Reproduire une action
Agrandir le court
Finir l’échange
Joueuse
Set 1
2
7
15
3
7
3
3
Set 2
9
6
2
8
16
15
2
Trajectoire du volant
Set 1
Set 2
1
4
1
3
1
2
0
2
0
4
2
3
4
3
Table 1. Les occurrences dans les types d’informations rapportées dans les décisions pour chaque match
Adversaire
Assurer
Choix
Pression
Surprendre
Reproduire
Agrandir
Finir
S1
1
1
8
1
2
0
1
S2
1
0
1
0
5
5
0
Joueuse
S1
1
2
3
2
4
1
2
S2
2
3
2
3
13
4
6
Règles
Règles
Règles
situation
individuelles
S1
S2
S1
S2
8
1
0
6
2
0
4
10
5
1
2
1
6
0
0
1
9
2
2
5
1
0
0
6
1
0
0
1
Evénement
antérieur
S1
2
0
7
1
6
0
1
S2
5
1
2
4
11
6
0
Attentes / Conséquences
des actions
adversaire
S1
0
2
1
0
5
0
1
S2
2
2
1
3
1
1
0
S1
0
1
8
0
3
2
1
S2
2
1
1
1
5
6
0
Table 2 : Les occurrences dans les types de connaissances rapportées dans les décisions pour chaque match
DISCUSSION
choix restreint et de mettre de la pression sur son
adversaire. Les informations liées à la joueuse étaient
plus souvent rapportées lorsqu’elle décidait d’agrandir le
court, de surprendre l’adversaire, de mettre de la
pression et de réaliser un choix restreint.
Les résultats ont montré que la joueuse ne visait pas
immédiatement à gagner l’échange, elle tentait le plus
souvent à mettre en place les conditions pour prendre
l’avantage dans l’échange. Les résultats sont discutés en
rapport avec les différentes phases de la prise de décision
en référence aux modèles théoriques. Ils permettent de
montrer le processus de compréhension de la situation,
son caractère progressif, la prise en compte du temps
dans la prise de décision et l’origine de la décision
(préconstruite ou émergente). Des implications sont
envisagées pour l’entraînement.
Les connaissances les plus rapportées concernaient les
règles, puis un événement antérieur (table 2). Les
connaissances liées l’adversaire ont été plus
particulièrement verbalisées dans le match 1,
lorsqu’elle cherchait à mettre de la pression. Celles
inhérentes à la joueuse ont été plus souvent rapportées
dans le match 2, lorsqu’elle visait à reproduire une
action efficace. Les règles individuelles étaient plutôt
explicitées au cours du match 1, dans les décisions de
reproduire une action efficace et d’assurer son action.
Elles étaient peu rapportées dans le match 2. Les
règles liées à la situation étaient plutôt considérées au
cours des deux matches pour les décisions de réaliser
un choix restreint. Elles l’étaient également au second
match pour les décisions d’agrandir le court, d’assurer
et de reproduire. Les connaissances portant sur
un événement antérieur concernaient plutôt, pour les
deux matches les décisions de reproduire une action
efficace. Les attentes étaient plus particulièrement
envisagées pour la décision de reproduire, au match 1
et à un niveau moindre, de surprendre au match 2. Les
conséquences des actions étaient plus souvent
rapportées pour les décisions de mettre de la pression,
d’agrandir le court et de reproduire une action
efficace.
Le processus de compréhension de la situation
Les résultats ont indiqué la prégnance de certaines
informations (e.g. liées à l’adversaire et à la joueuse) et
connaissances (e.g. inhérentes aux règles et à un
événement antérieur). Ceux-ci suggèrent l’idée d’une
compréhension fondée sur la comparaison des traits
saillants, contenus dans la situation actuelle à ceux,
contenus dans un répertoire mémorisé par la joueuse. Ce
dernier était sans cesse actualisé à partir des situations
liées aux matches, aux connaissances sur elle-même et
sur l’adversaire. Ce répertoire semble construit sur une
base commune aux experts d’un domaine et d’un
complément propre aux connaissances, compétences et
expériences propres à la joueuse. La base commune
serait composée des règles liées à la situation, des
conséquences des actions, des connaissances liées à
l’adversaire. La base personnelle consisterait en les
règles individuelles, les connaissances liées à la joueuse,
167
les attentes, les événements antérieurs et des
connaissances sur l’adversaire. Cette compréhension de
la situation fondée sur un processus de comparaison
valide le modèle des bases de connaissances [5] et celui
de la « Naturalistic Decision Making » [8], qui s’appuie
sur la modélisation de la compréhension à partir de la
« situation awareness » [4].
L’évaluation de la situation n’était pas figée, elle se
poursuivait dans le temps, la joueuse prenant en compte
les éléments nouveaux apparaissant dans la situation
(comportement de la joueuse, trajectoire du volant).
Elle restait « en éveil », poursuivant sa recherche
d’informations utiles. Cette compréhension progressive
basée sur une évaluation continue de la situation renforce
la modélisation de la compréhension proposée à travers
la « situation awareness » [4], ainsi que le modèle de la
suffisance cognitive [1]. Ce dernier prédit une
compréhension par actualisation de la situation
occurrente.
s’appuyait le plus souvent sur des connaissances liées au
passé et au présent, plutôt qu’à l’avenir.
La décision est apparue comme une projection dans
l’avenir : elle était basée sur des intentions tactiques et
était bornée par la contrainte temporelle. Cet avenir
présentait plusieurs échéances : une échéance immédiate
qui renvoyait à la réalisation d’un geste technicotactique, une échéance différée liée à l’évolution de la
situation, une échéance plus « lointaine » inhérente à
l’effet attendu sur l’évolution de l’échange. En
badminton, le jeu se construit le plus souvent sur
plusieurs coups. Chaque décision est envisagée dans
l’idée d’une construction progressive de l’échange, du
set et du match. Chaque nouvelle décision s’appuie à la
fois sur la compréhension de la situation occurrente, les
possibilités projetées de la joueuse, le résultat des
décisions précédentes dans des situations similaires,
l’évolution du score…
La prise en compte du temps dans la prise de
décision
L’origine de la décision
La décision était ensuite choisie dans le répertoire de la
joueuse, en fonction des caractéristiques spécifiques de
la situation, des ressources propres à la joueuse à cet
instant et des effets attendus sur le jeu. Les notions
d’efficacité dans le jeu et de satisfaction pour la joueuse
renforcent le modèle de la suffisance cognitive [1]. La
recherche d’efficacité n’était pas toujours totale : la
joueuse choisissait de différer l’intention de maîtriser
l’échange, préférant au préalable se mettre dans des
conditions favorables pour pouvoir finir. La décision est
apparue comme un compromis entre l’intention de
gagner, les possibilités de la joueuse en situation et le
répertoire d’actions possibles actualisé dans cette
situation.
L’analyse des verbalisations a révélé des différences
dans le niveau et dans le moment de compréhension des
situations par la joueuse. Certaines situations étaient
comprises très tardivement, ce qui lui laissait peu de
temps pour se décider et pour agir. Elle était amenée à
bricoler une solution dans l’urgence, elle était le plus
souvent acculée à réaliser un choix restreint. D’autres
situations présentaient une temporalité plus importante,
qui facilitait la compréhension et le choix. Ces
différences de compréhension liées à la fois à la pression
temporelle et à l’incertitude contenue dans la situation
confortent le modèle de la suffisance cognitive [1]. Selon
les prédictions de ce modèle, l’opérateur ne peut pas tout
comprendre, il se centre sur des informations saillantes
qui vont lui permettre de donner suffisamment de sens à
la situation pour pouvoir agir. Dans notre étude, ces
informations
concernaient
plus particulièrement
l’adversaire et elle-même. Les informations sur la
trajectoire du volant étaient peu rapportées, sans doute
du fait de la nécessité de comprendre la situation
relativement tôt, pour avoir le temps d’agir.
Le répertoire de la joueuse pouvait différer du registre
technico-tactique développé à l’entraînement. Celui-là
était sans cesse actualisé par ses compétences à un
instant, par des contraintes liées aux possibilités
motrices et biomécaniques… Une différence semblait
apparaître entre le modèle idéal utilisé par l’entraîneur,
qui visait une décision efficace dans une situation
problème typique et les modèles utilisés par la joueuse,
qui oscillaient entre un modèle idéal basé sur la
reproduction
de
décisions
pré-construites
à
l’entraînement et un modèle de compromis, qui visait la
construction de décisions en cours d’action. Les
décisions pré-construites s’appuyaient sur la
reproduction de routines d’exécution, qualifiées
« d’automatismes » par la joueuse ; elles semblaient
concerner plus particulièrement les décisions de
reproduire une action efficace, de réaliser un choix
restreint et d’assurer son action. Ces automatismes
semblent intéressants en situation dynamique, lorsque
la joueuse dispose de très peu de temps pour agir. Ils
présentent un coût cognitif moins important pour
l’athlète et ils permettent de pallier à une
compréhension moindre de la situation [1]. Les autres
Les résultats ont montré que la joueuse recourrait à des
temporalités variées pour prendre sa décision : les
situations passées (liées au match actuel ou à des
matches précédents), la situation actuelle et les situations
futures anticipées (évolution de la situation, de
l’échange, du set, du match). Les catégories de
connaissances contribuent également à souligner cette
temporalité : la joueuse se référait au passé à travers la
prise en compte d’événements antérieurs, au présent, à
partir de sa connaissance de l’adversaire, d’elle-même et
des règles, et au futur anticipé à travers la construction
de connaissances sur les attentes et les conséquences de
l’action envisagée. La prise en compte de temporalités
variées conforte les travaux menés en volley-ball [6] et
en tennis de table [7]. La joueuse a montré qu’elle
168
BIBLIOGRAPHIE
types de décision rapportées dans l’étude se référaient
le plus souvent à des décisions contenues dans le
registre de la joueuse et adaptées au cours de l’action,
en fonction de l’adversaire, d’elle-même, des
événements antérieurs liés au match ou à des matches
précédents, aux conséquences des actions et aux
attentes à l’égard de l’adversaire.
1.
Amalberti, R. La maîtrise des Situations
Dynamiques. Psychologie Française, Vol. 46, No. 2,
2001, pp. 107-118.
2.
Amalberti, R. and Hoc, J.-M. Analyse des Activités
Cognitives en Situations Dynamiques : pour quels
buts ? Comment ? Le Travail Humain, Vol. 61, No.
3, 1998, pp. 209-234.
3.
Cranach, M. (Von), and Harré, R. The Analysis of
Action. Recent Theoretical and Empirical Advances.
Cambridge University Press, New-York, 1982.
4.
Endsley, M.R., Bolté, B., and Jones, D.G. Designing
for Situation Awareness. Taylor and Francis,
London and New York, 2003.
5.
McPherson, S.L. and Kernodle, M.W., 2003,
Tactics, the Neglected Attribute of Expertise. In J.L.
Starkes and K.A. Ericsson (Eds), Expert
Performance in Sports. Human Kinetics,
Champaign, IL, 2003, pp. 137-168.
6.
Macquet, A.-C. Le Contrôle des Situations chez les
Volleyeurs Experts : Informations Perçues et
Connaissances Mobilisées ou Construites. Thèse de
Doctorat, Université Paris XI, 2001.
7.
Sève, C., Saury, J., Ria, L., and Durand, M.
Structure of Expert Players’ Activity during
Competitive Interaction in Table Tennis. Research
Quaterly For Exercice and Sport, Vol. 74, No. 1,
2003, pp. 71-83.
8.
Zsambok, C.E. and Klein, G. Naturalistic Decision
Making. Where are we now? In C.E. Zsambok, and
G. Klein (Eds), Naturalistic Decision Making.
Lawrence Erlbaum Associates, Mahwah, New
Jersey, 1997, pp.3-16.
Perspectives pour l’entraînement
Globalement deux types de décisions sont apparues au
cours des matches : des décisions pré-construites basées
sur des routines d’exécution contenues en mémoire et
des décisions construites en cours d’action, émergeant de
la co-détermination entre la joueuse et la situation. Bien
que ce travail ne constitue qu’une étude de cas, la mise
en évidence de ces deux types de décisions suggère
quelques implications pour l’entraînement. Si
l’utilisation des décisions pré-construites semble être
utile à cette joueuse, le jeu a montré que ses décisions
n’étaient pas toujours efficaces et l’adversaire pouvait
s’habituer à ces préférences. L’élaboration de décisions
« inédites » en cours d’action est apparue comme une
autre voie pour varier le jeu et tenter d’augmenter son
efficacité. Cette construction de solutions s’inscrit dans
une perspective développementale visant l’adaptation
permanente de la joueuse aux situations dans lesquelles
elle est engagée. Dans cette perspective, l’entraîneur ne
se contenterait plus d’indiquer les traits saillants de la
situation, ni de donner une « solution toute faite » à la
joueuse, mais il l’inciterait, au cours de l’entraînement et
de compétition, à analyser plus en profondeur le jeu
adverse, pour élaborer les solutions optimales en
situations dynamiques. L’entraîneur ne serait plus la
référence essentielle. Ce type de situation s’appuierait
sur l’analyse et l’exploitation du jeu adverse, sur la base
de la réalisation de matches à thèmes, à l’entraînement.
Dans ces conditions, la joueuse pourrait apprendre à
l’entraînement non seulement à reproduire des décisions
pré-construites, mais aussi à analyser et à exploiter le jeu
adverse, en fonction de thématiques précises (adaptation
à un jeu basé sur la reproduction, à un jeu varié…). Cette
étude ne représente qu’une étude de cas qui pourra être
enrichie par d’autres cas, pour mieux comprendre « ce
qui se passe » en compétition.
REMERCIEMENTS
Cette étude a été financée par le Ministère de la
Jeunesse, des Sports et de la Vie associative. Nous
remercions la joueuse et son entraîneur, pour leur
participation à l’étude.
169
Démarche d’aide au choix de dispositifs
pour l'ordinateur porté
Guillaume Masserey, Olivier Champalle, Bertrand David, René Chalon
Laboratoire ICTT – Ecole Centrale de Lyon
36, av. Guy de Collongue
69134 Ecully Cedex
{ Guillaume.Masserey, Olivier.Champalle, Bertrand.David, Rene.Chalon } @ec-lyon.fr
RESUME
d’ordinateurs portés, ordinateurs non seulement portable
(déplaçables), mais pouvant être utilisés en mouvement,
en déplacement. Notre objectif est d’équiper l’acteur,
porteur d’ordinateur porté, de dispositifs en adéquation
avec les tâches qu’il doit assurer. C’est pour cela que la
base de notre démarche est de fournir au concepteur un
référentiel sur lequel va s’appuyer le processus de choix
de dispositifs d’interaction. Ce référentiel, couplé à des
matrices dispositifs/critères, facilite l’évaluation de la
performance de l’ordinateur porté au fur et à mesure de
sa conception et permet de se rendre compte des compromis à réaliser, en justifiant et traçant les choix effectués selon une approche de Design Rationale [5, 17, 20,
21] de sorte à pouvoir aisément remettre en cause des
choix si l’on se trouvait dans une impasse. Le choix d’un
dispositif est quant à lui basé sur un raisonnement QoC
[16] ou tout autre raisonnement logique prenant en
compte différents critères [17, 18] mais de sorte à réaliser un compromis entre ceux-ci. Cette démarche est en
fait un processus itératif qui prend en compte les tâches à
réaliser et plus particulièrement les tâches d’interaction
qui les composent, prises séparément mais aussi considérées ensemble pour tenir compte des critères tels que la
continuité de l’interaction [12] et la réduction du nombre
de dispositifs.
Cet article décrit une démarche d’aide au choix de dispositifs d’interaction pour l’ordinateur porté dans le
contexte de systèmes mobiles et de Réalité Augmentée.
Elle est basée sur un référentiel de dispositifs
d’interaction qui a pour vocation de guider le concepteur
dans le choix des éléments à utiliser. Ce référentiel est
couplé à des matrices dispositifs/critères permettant des
comparaisons entre les dispositifs. Ces matrices aident
au choix des dispositifs les plus performants c'est-à-dire
les plus adaptés aux tâches à réaliser. Le fil conducteur
de ce processus est la modélisation des tâches et des tâches d’interaction les composant. Après avoir présenté la
démarche, nous l’illustrons dans notre cadre de recherche, à savoir l’ingénierie des systèmes mobiles et de Réalité Augmentée. Enfin nous conclurons sur son apport.
MOTS CLES : Démarche d’ingénierie, performance, ergonomie, ordinateur porté.
ABSTRACT
This article describes a method of choice of interaction
peripherals for wearable computer in mobile and augmented Reality context. It is based on a referential of interaction devices which vocation is to support choices of
devices to be used. This referential is coupled with matrices devices/criteria allowing comparisons between different devices. These matrices guide choice of most
powerful devices i.e. most adapted to the tasks to be
done. The process is guided by tasks modelling and their
interaction tasks, necessary for human machine interaction. After having presented this method, we illustrate it
within our research framework, wearable computer interaction devices choice for mobile and of Augmented
Reality situations. Finally we will conclude by the discussion of its contribution.
Nous présentons dans un premier temps la démarche,
après avoir défini les notions fondamentales auxquelles
elle fait appel c'est-à-dire la tâche, le référentiel et les
matrices/critères. Dans un deuxième temps nous décrivons une étude de cas montrant l’application de la démarche.
PRINCIPE
La tâche à assurer par l’acteur porteur de l’ordinateur
(figure 1, T) constitue le point de départ de notre démarche. Celle-ci peut être décomposée en tâches plus précises, ces dernières pouvant faire apparaître les tâches
d’interaction, tâches sur lesquelles s’appuient les interactions.
KEYWORDS: Engineering method, performance, ergo-
nomics, wearable computer.
INTRODUCTION
L’ingénierie des systèmes mixtes [27] et mobiles [24]
n’est pas une activité facile, car elle nécessite de bien
connaître les dispositifs et technologies existants et de
les choisir en tenant compte des exigences qu’il est souhaitable d’expliciter. C’est en particulier le cas en ce qui
concerne le choix de dispositifs d’interaction dans le cas
L’affectation de dispositifs se fait pour chaque tâche
d’interaction prise séparément mais aussi considérée
avec l’ensemble des tâches d’interaction de la (sous-) tâche à laquelle elle appartient. Pour évaluer la capacité
d’un dispositif à répondre à une tâche d’interaction, étant
donnée la diversité des tâches d’interaction possibles, un
171
ces groupes correspondent aux trois grandes parties d’un
système mobile et de RA et plus généralement d’un système interactif, ainsi qu’une partie plus système (Communication). Ces groupes sont les interactions HM en
entrées, les interactions IHM en sorties, les interactions
de l’utilisateur avec l’environnement avec l’idée sousjacente de traiter certains aspects des environnements
ubiquitaires [26] et enfin un groupe système (Communication).
intermédiaire entre tâche d’interaction et dispositif est
nécessaire, c’est la technique d’interaction. Le concepteur doit considérer d’abord le niveau sémantique de la
tâche concrétisée en tâches d’interaction puis le niveau
syntaxique [6] que représentent les techniques
d’interaction [13] qui composent chaque tâche
d’interaction (figure 1, I).
T
Tâche
Point d’accès
WiFi
Tags
RFID
Contextualisation
Tâche
d'interaction 1
Tâche
d'interaction 2
...
Lecteur
RFID
Tâche
d'interaction N
GPS et RFID
I
Technique
d'interaction 1
...
GPRS / 3G
Caméra
(et marqueurs)
RFID
(logique)
Technique
d'interaction L
Affichage
Autres capteurs
Localisation
Dispositif
d'interaction 1
...
Lecteurs et
tags RFID
Micro-clavier
Dispositif
d'interaction K
Clavier virtuel et
gant
Micro fixe
Ecriture sur écran
tactile
Micro porté
Figure 1 : Mise en relation de la Tâche avec les Techniques
d’interaction et les Dispositifs d’interaction
Semi-transparent
dans lunettes
WiFi
Opaque dans lunettes
PDA ou
TabletPC
Oreillette
Casque
BT
GPS (géographique)
D
Casque
audio
Sortie sonore
Haut-parleur
Cellule
Cellule piezobraille
électrique
Sortie
sensoGant
rielle
Eye-tracker
porté
Armature
Interaction
graphique
Combinaison
Interaction
gestuelle
Interaction
vocale
Etant donné le nombre de techniques d’interaction possibles, un guidage des techniques d’interaction
utilisables est conseillé ; à cet effet, nous avons choisi
d’utiliser les tâches d’interaction types [11] qui sont
Sélection, Position, Orientation, Chemin, Saisie de Texte
et Saisie de Nombre. Selon ce principe, chaque tâche
d’interaction de la tâche devra être assimilée à une de
ces tâches d’interaction types. D’un autre côté, une
évaluation/comparaison des dispositifs pour réaliser chacune de ces techniques d’interaction doit exister pour déterminer lesquels affecter à ces techniques d’interaction
et donc aux tâches d’interaction et finalement aux tâches
à réaliser.
Lunettes
à écran
intégré
Communication
Micro
Interaction
à l’oeil
Eye-tracker
TabletPC
Gant de données
Figure 2: Un exemple de référentiel pour les systèmes mobiles et de Réalité Augmentée
Le groupe interaction en entrée
Il comprend 4 axes (Interaction graphique, Interaction
vocale, Interaction à l’œil, Interaction gestuelle). Ce découpage en 4 axes n’est pas réalisé au hasard, il s’inscrit
dans un raisonnement initié depuis plusieurs années qui
tend à découper les interactions d’entrée selon les modalités et d’autres critères [2, 7, 13, 15, 19] descriptifs du
dispositif ou du média traité.
LE REFERENTIEL
Le référentiel doit être choisi avec précaution pour exprimer tous les éléments pouvant potentiellement entrer
dans la sélection de dispositifs de l’ordinateur porté.
Le groupe interaction en sortie
Il comprend 3 axes (Affichage, Sortie sonore, Sortie sensorielle), ces trois axes correspondent aux modalités
d’interaction en sortie [1, 3, 8] les plus importantes.
Le référentiel s’organise en axes (figure 2), chaque axe
pouvant être utilisé ou non dans la configuration à bâtir.
Si un axe n’est pas utilisé, c’est comme s’il prenait la valeur 0. Plus les éléments sont situés vers l’extrémité des
axes et plus ceux-ci sont performants relativement à un
critère pertinent de l’axe. Par exemple pour l’axe Affichage, les différents éléments sont placés selon le critère
de continuité du regard de plus en plus important.
Le groupe interaction avec l’environnement
Il comprend 2 axes (Localisation, Contextualisation).
Ces deux axes définissent les moyens requis pour la
mise en place d’environnement ubiquitaires [25].
Le groupe système
Il comprend un unique élément Communication qui correspond aux moyens utilisés pour réaliser la communication avec d’autres ordinateurs ou des capteurs ou autres
objets communicants.
La figure 2 présente un référentiel adapté pour la
conception de systèmes mobiles et de Réalité Augmentée (RA). On peut remarquer le découpage en 4 groupes,
172
PRINCIPE D’AFFECTATION DE DISPOSITIFS
gure 4) forme une matrice « dispositifs/critères » (figure
5).
Pour affecter un dispositif à une tâche d’interaction, il
faut savoir quelles techniques d’interaction il supporte
pour pouvoir évaluer sa capacité à la réaliser. Dans notre démarche cela équivaut à évaluer :
x
Son adéquation avec la technique d’interaction (et
respectivement la tâche d’interaction pour considérer des critères tels que la continuité de l’interaction
ou la minimisation du nombre de dispositifs).
x
Ses capacités dans les conditions de réalisation de la
tâche, qu’elles soient environnementales (humidité,
champs magnétique, …) ou de l’utilisateur (ressources disponibles : 0, 1 ou 2 mains libres, porte ou non
des lunettes …).
x
La figure 5 présente une matrice critères/dispositifs sans
les valeurs. Cette matrice est celle de la technique
d’interaction Saisie de Texte sous des conditions non
explicitées (Ci). A noter que les conditions s’expriment
comme des contraintes plutôt que comme des possibilités ainsi on pourrait avoir la contrainte « 2 mains prises » au lieu de donner la contrainte « 0 mains libres ».
Les préférences et « différences » interindividuelles
s’expriment aussi sous formes de conditions.
C1
C2
…
CN
SCORE
Clavier
Souris
Gant
Eye-tracker
Micro
Ecran-tactile+stylet
Ecran-tactile+doigt
Tablettetactile+stylet
MOYENNE
Ses valeurs dans les critères de performance relativement à la technique d’interaction (et respectivement la tâche d’interaction) et aux conditions de réalisation.
De manière plus synthétique, le choix d’un dispositif se
fait selon la technique (respectivement la tâche)
d’interaction à réaliser, selon les conditions de réalisation de la tâche, et en fonction de ses valeurs dans les
différents critères, voir figure 3. Pour chacune des techniques d’interaction, on est amené à évaluer chacun des
dispositifs, dans les différentes conditions d’utilisation.
Figure 5 : Une matrice de description dispositifs/critères
Définition d’une matrice multicritère
Les critères sont placés sur les colonnes (C1, C2, …
CN). Les dispositifs sont mis sur les lignes. La dernière
colonne contient le score du dispositif. Le score est la
valeur globale du dispositif ; sa valeur est définie par
une formule établie par le concepteur et utilisée pour
calculer la valeur des scores de chacun des dispositifs
d’une même matrice. La formule la plus simple étant la
somme des valeurs du dispositif dans chaque critère,
d’autres formules telles que la somme de la valeur des
critères pondérés peuvent s’avérer pertinentes.
Conditions
Critères
Dispositifs
Figure 3 : Cube des possibles pour une tâche d’interaction
La dernière ligne contient une ou plusieurs valeurs caractéristiques pour chacun des critères et le score par
rapport à l’ensemble des dispositifs ; ce peut être la valeur moyenne du critère ou du score, ou la valeur MMM
(Minimum / Moyenne / Maximum) qui permet de se
rendre compte des valeurs minimales, moyennes et
maximales que peuvent avoir les critères et le score par
rapport à l’ensemble des dispositifs. Ces valeurs calculées permettent d’estimer rapidement la place qu’occupe
notre dispositif en respect de ses critères ou de son score
et de déduire notamment si certains dispositifs ont des
meilleures valeurs de critères ou ont de meilleurs scores
et cela sans parcourir la table complète.
Cela revient à réaliser autant de cubes que de techniques
d’interaction, ainsi le nombre de cubes peut être très important. Si l’on souhaite appliquer la démarche au niveau
tâche d’interaction, il faut considérer les tâches
d’interaction types ; ainsi il y aurait 6 cubes : Sélection,
Position, Orientation, Chemin, Saisie de Texte, Saisie de
Nombre.
Critères
Dispositifs
Notes des dispositifs selon les différents critères
Figure 4 : Un plan dispositifs/critères pour une condition et
une technique d’interaction donnée
L’affectation de notes dans chaque critère et à chaque
dispositif doit se faire avec précaution, le plus objectivement possible et ne peut être réalisé que par un expert
des domaines concernés à savoir les systèmes mobiles et
de RA mais aussi des domaines induits par les critères
MATRICES MULTICRITERE
Pour chaque condition, le plan formé par les axes dispositifs et critères pris indépendamment des conditions (fi-
173
considérés. Dans le cas de critères tels que l’utilisabilité,
les valeurs à affecter à chacun des dispositifs devraient
soient être le résultat d’études réalisées au préalable,
soient calculées par un ergonome expert ; dans tous les
cas, les valeurs doivent être affectées le plus objectivement possible pour ne pas fausser tout le processus.
décomposé la tâche d’interaction en techniques
d’interaction [11, 12, 13, 14, 15], il va devoir appliquer
de manière itérative le raisonnement de sélection de dispositifs pour chacune de ces techniques d’interaction,
tout en tenant compte des choix réalisés pour chacune
d’entre elles.
Utilisation des couleurs dans la matrice
Sélection de
d’interaction
L’utilisation de différentes couleurs de fond est recommandée pour définir la matrice de manière à la rendre la
plus lisible possible et donc la plus efficiente. Ainsi, on
conseille l’usage de quatre couleurs distinctes pour mettre en évidence les différentes cellules de la matrice :
- Elément non singulier,
- Valeur la plus faible (de critère pris séparément),
- Valeur la plus forte (de critère pris séparément),
- Rubrique calculée pour la dernière colonne (score)
et la dernière ligne (moyenne ou valeur MMM).
dispositifs
pour
une
technique
Le concepteur ne peut encore comparer les dispositifs
tant qu’il n’a pas déterminé les conditions de réalisation
de la tâche : ces conditions peuvent être des indications
hors formalisme (ex : « La tâche se déroule en extérieur ») ou des conséquences logiques des tâches
d’interaction qui viennent d’être réalisées ou qui peuvent
être réalisées en parallèle et donc des dispositifs précédemment sélectionnés ou couramment utilisés. Une fois
cela fait, la matrice dispositifs/critères est déterminée.
Dans un premier temps, le concepteur revoit le référentiel pour se remettre en tête les différents dispositifs qui
peuvent répondre à son problème ; cette évaluation reste
fortement subjective. Dans un deuxième temps, une fois
qu’il a déterminé les dispositifs [18] qui lui semblent les
plus adaptés dans le référentiel et selon les critères de
performance, aidé de la matrice dispositifs/critères sélectionnée, il évalue ce dispositif et le compare aux autres ;
il fait alors le choix selon les critères préétablis (heuristique). Si son choix ne s’avère pas particulièrement performant(ex : si un des critères extra heuristique a une
très mauvaise valeur), il peut consulter à nouveau le référentiel pour choisir d’autres dispositifs ou continuer
son choix directement depuis la matrice.
Ces différentes couleurs devront se retrouver respectivement dans chaque matrice. Si les dispositifs ne sont
pas ordonnés par score (parce qu’ils le sont par
modalités par exemple) le dispositif de plus faible score
(et respectivement de plus fort score) peut être mis en
évidence en coloriant sa cellule « nom » de la couleur
« Valeur la plus faible score » (et respectivement de la
couleur « Valeur de plus fort score »). Il est important de
mettre en évidence ces valeurs minimales et maximales
de chaque critère puisque l’on va être amené à
considérer les critères selon un ordre précis dans une
première phase, puis de manière globale dans une
deuxième.
PRESENTATION DE LA DEMARCHE
Une fois les éléments précédents modélisées (Tâche, Référentiel, Matrices), la démarche peut s’appliquer. Il
s’agit de parcourir la tâche en profondeur d’abord et
d’affecter à chaque tâche d’interaction un dispositif selon un compromis tendant à maximiser la performance,
au sens des valeurs du dispositif dans chacun des critères. Mais, il faut également tenir compte de toutes les
techniques d’interaction de la tâche pour faire un bon
choix de dispositif ainsi que de tenir compte de
l’ensemble des dispositifs qui ont déjà été sélectionnés
pour réaliser une autre sous-tâche et cela pour minimiser
le nombre de dispositifs, le coût des équipements, le
poids, l’encombrement, maximiser la continuité de
l’interaction et tout autre critère relatif à la prise en
compte de la tâche de manière globale.
Application des critères pour le choix du dispositif
Les critères sont ordonnés préalablement à l’exécution
de la démarche. La prise en compte de cet ensemble de
critères doit cependant se comprendre comme un compromis. Aussi un critère ayant une valeur très mauvaise
peut écarter un dispositif même si celui-ci a une très
bonne valeur dans un critère plus prioritaire. En effet,
nous sommes bien dans un raisonnement de logique
floue visant à atteindre un équilibre entre différentes
contraintes pour arriver à proposer une configuration de
dispositifs cohérente. Le concepteur va donc considérer
les critères dans un certain ordre, mais sans jamais appliquer de raisonnement tout ou rien.
Traçage – Retour en arrière (Backwarding)
Le processus de sélection est incrémental ; un choix de
dispositif peut empêcher l’exécution complète de la tâche ou altérer la performance globale de celle-ci s’il est
incompatible avec ceux permettant de réaliser des parties
de la tâche qu’il ne permet pas d’effectuer. Dans ce cas,
il faut se demander si les choix précédents, bien qu’ils
formaient alors le meilleur compromis, ne doivent pas
être révisés pour finalement sélectionner un autre dispositif certes moins performant mais aboutissant finalement
Nous décrivons maintenant le raisonnement que doit
mener le concepteur lorsqu’il doit affecter un dispositif à
une tâche d’interaction.
Sélection de dispositifs pour une tâche d’interaction
Le concepteur doit d’abord se demander à quelle tâche
d’interaction type (Sélection, Position, …) la tâche
d’interaction est assimilable pour déterminer les techniques d’interaction qui vont pouvoir être utilisées. Ayant
174
à un meilleur compromis. Pour rendre possible ce mécanisme de retour en arrière (backwarding), il faut tracer
les choix effectués, c’est-à-dire noter les explications/justifications de chacun de ceux-ci avec leurs scores, leurs avantages et inconvénients. Grâce à cette trace,
le concepteur est, en principe, capable de justifier tous
les choix réalisés et de ne pas refaire un même choix
alors qu’il ne peut aboutir à l’ingénierie complète du
système mais aussi de modifier des choix antérieurs, unitairement (technique d’interaction) ou par bloc (technique(s) d’interaction, tâche(s) d’interaction, tâche). Cette
trace peut-être représentée de manière graphique sur
l’arbre de tâches, dans un tableau ou textuellement ; dans
tous les cas, il est vivement conseillé de la structurer sinon elle va devenir rapidement illisible et inexploitable.
COllaboration – COntextualisation), l’ensemble des informations nécessaires. Les besoins d’information, de
formation, d’assistance, d’aide à la maintenance et de
dépannage sont ainsi pris en compte.
Contexte du scénario
Nous nous plaçons ici dans la situation d’un technicien
« volant » chargé d’intervenir sur un équipement qu’il ne
connaît pas ou peu. Ce technicien est employé dans une
société de service fournissant des prestations de maintenance sur des équipements de type bureautiques : imprimantes, photocopieuses, scanner, fax, PC (portable et
fixe), téléphone. Ces équipements peuvent avoir été
loués par les clients. Ce technicien est considéré comme
polyvalent et capable d’intervenir sur ces différents
d’équipements même s’il n’est pas expert des appareils
qu’il va être amené à réparer. Dans ce but, il maitrise et
est susceptible d’utiliser des dispositifs innovants, mobiles ou de réalité augmentée.
Il est à noter qu’en fonction des dispositifs retenus, de
leur coût, de leur fragilité et de l’impossibilité de les porter en même temps, le concepteur peut être amené, en
dernier recours, à reconsidérer l’organisation des tâches
dans le but de déduire une configuration (ensemble cohérent de dispositifs) en appliquant à nouveau la démarche.
Le scénario
Nous décrivons ci-après l’intervention d’un technicien
sur une imprimante dont la marque et le modèle lui sont
inconnus :
1 Le technicien utilise un dispositif mobile pour se
connecter au site web de sa SSII.
2 Il s’identifie et accède à la partie réservée aux techniciens.
3 Il recherche le nom et la marque de l’imprimante à
dépanner pour accéder à sa documentation.
4 De là, le technicien détermine l’origine du problème
correspondant au remplacement du tambour de
l’imprimante, modèle standard dont il dispose dans
son véhicule. Cependant, il ne sait pas comment opérer pour remplacer le tambour défectueux.
5 A ce moment, le dépannage commence et le technicien utilise ses deux mains pour pouvoir intervenir
sur l’équipement, tout en consultant la documentation adaptée, utilisant le média approprié (texte,
image, vidéo, son), et accomplir sa tâche.
6 A l’issue de l’intervention, le technicien écrit un rapport, une facture …
Outil informatique pour la démarche
Un outil informatique (s’inspirant de [4]) en cours de
développement en Java/XML va bientôt permettre
d’éditer ces choix numériquement et ainsi d’expliciter
les choix effectués plus simplement tout en stockant les
traces de chaque choix dans un fichier et tout en calculant le score au fur et à mesure des options choisies avec
les valeurs moyennes selon les différents critères. Cet
outil permettra à terme en plus de représenter graphiquement les choix sur l’arbre de tâches, de présenter les
choix sous forme de tableau et d’imprimer ceux-ci avec
leurs justifications. Il va également historiser les différents chemins empruntés, des solutions obtenues ou sans
issues constatés (par exemple dûes à l’absence de dispositifs compatibles avec les autres déjà utilisés pour cette
tâche). Cette historisation permet une explication a posteriori des choix effectués, ce qui est particulièrement
important si ces choix sont amenés à être remis en question par exemple suite à un retour d’expérience.
Analyse
Dans ce scénario, nous pouvons, par notre expérience,
deviner des équipements plus adaptés que d’autres. Et
ce, notamment pour les tâches 1, 2, 3, 4 et 6 où les dispositifs de type PDA ou Tablet PC semblent convenir
naturellement. Cependant, il n’en va pas de même pour
la tâche 5 correspondant à l’intervention directe du technicien sur l’imprimante défectueuse, dont les contraintes
(deux mains prises et consultation de documentation) ne
nous permettent pas d’appréhender simplement le ou les
dispositifs
nécessaires.
Nous
détaillons
donc
l’application de notre démarche aux contraintes de la tâche 5 avec comme critères la mobilité, l’efficience et la
satisfaction. Nous résumons dans la figure 6 ci-dessous
ETUDE DE CAS
Dans cette partie, nous mettons en pratique la démarche
explicitée plus haut. Pour ce faire, nous décidons d’évoluer dans le cadre du projet HelpMeToDo actuellement
traité au laboratoire ICTT qui vise à exploiter des nouveaux moyens de communication mobiles pour le grand
public et les professionnels dans toutes les activités nécessitant de l’aide. Les besoins d’information, de formation, d’assistance, d’aide à la maintenance et de dépannage dans des contextes individuels, collectifs, industriels ou grand public sont donc pris en compte. Le Mobile Learning (apprentissage juste à temps situé dans le
contexte d’intervention) vise à amener, sur le lieu
d’action, grâce aux principes MOCOCO (MObilité –
175
l’arbre simplifié de la tâche 5 exprimé à l’aide du formalise CTT [23].
Privilégier le critère de mobilité nous conduit, à l’issue
de l’utilisation de notre matrice, au choix du micro porté,
plus léger et plus agréable pour les utilisateurs que
l’Eye-Tracker lourd et inconfortable. Il faut toutefois ne
pas oublier la faible efficience du micro porté induite
par l’imperfection du système de reconnaissance vocale,
notamment dû à sa difficulté de calibration. Ce critère
pourrait être crucial dans la suite de notre analyse, car
les erreurs du système pourraient dérouter le technicien.
Notre arbre laisse clairement apparaître les techniques
d’interaction auxquelles l’utilisateur va devoir faire appel afin de sélectionner la documentation indispensable
pour accomplir son intervention. Notre but est de pouvoir déterminer à l’aide de la démarche, explicitée plus
haut, le ou les dispositif(s) à retenir dans les conditions
d’intervention de la tâche 5.
2. Choisir item
La figure 8 présente la matrice de description dispositifs/critères propre à la technique d’interaction « CHOISIR ITEM ».
Dispositifs
Eye-tracker
porté
Micro porté
MOYENNE
Mobilité
Efficience
Satisfaction
utilisateur
SCORE
2
5
3
10
5
3,5
2
3,5
2
2,5
9
9,5
Figure 8 : matrice dispositifs/critères « CHOISIR
ITEM »-deux mains prises-en mobilité
Cette nouvelle matrice, nous conduit à retenir le dispositif Eye-Tracker dont l’efficience et la satisfaction utilisateur pour la technique d’interaction « CHOISIR ITEM »,
dans les conditions établies, est supérieure au micro porté.
Figure 6 : Arbre de la tâche 5
Nous choisissons arbitrairement de traiter la tâche
d’interaction « Sélection du média » qui est une tâche
d’interaction d’entrée contrairement aux deux autres
(« Consulter … »), nous ne traitons pas la tâche
« consulter le média » qui contient les mêmes tâches
d’interaction que la tâche « Consulter menu media » car
elle ne met pas en valeur d’autres aspects de la démarche, excepté, des critères comme la continuité de
l’interaction et la minimisation du nombre de dispositifs,
car il y a récurrence des tâches d’interaction.
Nous nous occupons maintenant de l’affectation des dispositifs à chacune des techniques d’interaction, nous
nous limitons au raisonnement basé sur les matrices sans
insister sur la consultation du référentiel antérieur à
l’utilisation des matrices. Dans les différentes matrices
ci-dessous, le système de notation retenu va de 1 (très
peu adapté) à 5 (très adapté).
3. Confirmer
Nous nous intéressons à présent au dernier dispositif
d’entrée de notre tâche d’interaction « Sélection du média ». Pour ce faire nous utilisons la matrice dispositifs/critères suivante (Figure 9).
Dispositifs
Eye-tracker
porté
Micro porté
MOYENNE
Nous présentons ci-dessous, figure 7, la matrice de description dispositifs/critères propre à la technique
d’interaction « DEFILER » et avec la condition : « deux
mains prises ».
Eye-tracker
porté
Micro porté
MOYENNE
Mobilité
Efficience
Satisfaction
utilisateur
SCORE
2
4
2
8
5
3,5
2
3
2
2
9
8,5
Efficience
Satisfaction
utilisateur
SCORE
2
3
2
7
5
3,5
4
3,5
4
3
13
10
Figure 9 : matrice dispositifs/critères « CONFIRMER »-deux mains prises-en mobilité
Le micro porté est le dispositif le plus intéressant en rapport à nos besoins. En effet, il est plus facile pour un utilisateur de confirmer le choix d’un item avec le son de sa
voix qu’avec le regard. Le résultat de notre analyse,
pour la tâche « Sélection du média », fait ressortir le besoin d’utiliser en même temps un dispositif micro porté
ainsi qu’un eye-tracker. Notre technicien sera donc capable de faire défiler la liste de média disponible avec le
son de sa voix, de choisir un média à l’aide de ses yeux
et pour finir de confirmer la sélection à nouveau avec le
son de sa voix. Notre étude ne serait pas complète si
nous ne choisissions pas, via la même démarche, les dispositifs en sortie. Nous avons déjà précisé, dans notre
scénario, que l’utilisateur devrait être à même de visuali-
1. Défiler
Dispositifs
Mobilité
Figure 7 : matrice dispositifs/critères « DEFILER »deux mains prises-en mobilité
176
ser des menus, via la tâche système « Consulter menu
média », et de consulter de la documentation adaptée que
ce soit du texte, des images, de la vidéo ou du son. Nous
traitons donc maintenant la tâche d’interaction en sortie
« Consulter menu média ».
équipement s’avère, en fait, plus judicieux et confortable
pour le technicien et souvent plus économique.
Bilan : dispositifs requis
La figure 12 présente un bilan récapitulatif des résultats
établis en suivant la démarche, pour la réalisation de la
tâche Dépannage (5) de notre scénario. Le technicien
devra donc utiliser les types de dispositifs retenus, associés à chaque tâche d’interaction. A savoir : le micro et
l’oreillette portés, l’eye-tracker et l’écran opaque dans
des lunettes.
4. Visualiser
La figure 10 nous permet de choisir le dispositif le plus
adapté au besoin du technicien. En fonction des notes
constatées, nous décidons de porter notre choix sur les
lunettes à écran opaque (micro-écran de 0,3 pouces). Ce
dispositif, moins mobile que les lunettes à écran semitransparent, est cependant le plus adapté aux besoins de
visualisation du technicien.
Dispositifs
Lunettes à
écran opaque
Lunettes à
écran semitransparent
MOYENNE
Mobilité
Efficience
Satisfaction
SCORE
3
4
3
10
4
2
2
8
3,5
3
5
9
Figure 10 : Matrice dispositifs/critères « VISUALISER »deux mains prises-en mobilité
Faisant suite à notre analyse concernant la technique
d’interaction « VISUALISER », notre démarche nous
permet de nous interroger sur la difficulté ergonomique,
pour le technicien de porter en même temps, et durant
toute la phase d’intervention, un eye-tracker (déterminé
plus haut) ainsi que des lunettes à écran opaque. Nous
décidons cependant de conserver cette organisation mais
nous nous montrerons vigilants sur le calibrage et la précision de l’eye-tracker en question afin de permettre au
technicien de désigner « facilement » les informations
qui lui seront utiles.
Figure 12 : Récapitulatif des choix proposés par la démarche
Validation du système
Il faut maintenant se demander si le fait d’utiliser en entrée un micro et un eye-tracker est judicieux et si
l’utilisation de l’un ou l’autre de ces dispositifs
n’aboutirait pas à une meilleure performance globale.
Ainsi, on peut s’interroger sur l’usage du micro seulement en entrée, pour un meilleur compromis.
L’utilisation d’un eye-tracker est contraignante, il faut
l’installer, le calibrer, le manipuler avec précaution. Finalement, sa faible implication dans la tâche (seulement
pour « Choisir item »), fait que l’usage du micro seulement est le compromis qui maximise la continuité de
l’interaction et minimise le nombre de dispositifs requis.
L’usage du micro seul en entrée augmente la performance globale du système. La configuration déterminée par la démarche est finalement l’ensemble formé par
les Lunettes à écran opaque et le casque comportant
Micro et oreillette.
5. Ecouter
Notre dernière analyse porte sur la technique
d’interaction « Ecouter ». Le technicien pouvant être à
même d’utiliser des documentations sonores, nous utilisons la matrice suivante :
Dispositifs
Mobilité
Efficience
Casque audio
Oreillette
MOYENNE
4
5
4,5
5
4
4,5
Satisfaction
3
4
3,5
SCORE
12
13
12,5
Figure 11 : Matrice dispositifs/critères « ECOUTER »-deux
mains prises-en mobilité
La lecture de cette matrice nous permet de dégager le
choix de l’oreillette. Plus légère et ne couvrant qu’une
seule oreille contrario à un casque stéréo, elle offre un
bon équilibre entre l’efficience que nous recherchons et
la satisfaction. En outre, l’oreillette et le micro porté sont
deux éléments importants de notre configuration. Nous
décidons donc de retenir un seul dispositif porté composé d’un micro et oreillette, si possible. Le choix de cet
CONCLUSION
Dans cet article, nous avons décrit une démarche aidant
au choix de dispositifs d’ordinateur porté dans le
contexte de mobilité et de Réalité Augmentée. Nous
avons décrit les différents éléments qu’elle nécessite
177
pour s’appliquer et donné un aperçu de son efficacité et
sa reproductibilité sur un exemple concret. Cette démarche se veut générique et s’applique à l’ensemble des dispositifs d’interaction existants ou à venir. Elle permet de
configurer l’ordinateur porté en relation avec les tâches à
effectuer.
13. Hinckley, K., Jacob, R.J.K., and Ware, C. Input/output Devices and Interaction Techniques. In
The Computer Science Handbook, Second Edition,
ed. by A.B. Tucker, 2004, pp. 20.1-20.32, Chapman
and Hall/CRC Press.
14. Jacob, R.J.K., Leggett, J.J., Myers, B.A., Pausch, R.
Interaction Styles and Input/Output Devices. Behaviour and Information Technology, vol. 12, no. 2,
1993, pp. 69-79.
BIBLIOGRAPHIE
1. Bernsen, N.O. A revised generation of the taxonomy
of output modalities. Esprit Basic Research project
AMODEUS-2 Working Paper RP5-TM-WP11,
1994.
15. Jacob, R. J., Sibert, L. E., McFarlane, D. C., and
Mullen, M. P. Integrality and separability of input
devices. ACM Trans. Comput.-Hum. Interact. 1, 1
(Mar. 1994), pp. 3-26.
http://doi.acm.org/10.1145/174630.174631
2. Bernsen, N.O. A taxonomy of input modalities. CCI
Working Papers in Cognitive Science and HCI,
WPCS-95-9. Centre for Cognitive Science, Roskilde
University, 1995.
16. Lacaze X. La conception rationalisée pour les systèmes interactifs. Thèse de doctorat, Université Paul
Sabatier, Toulouse, 2005.
3. Bernsen, N.O. Foundations of multimodal representations. A taxonomy of representational modalities.
Interacting with Computers Vol. 6 No. 4, 1994, pp.
347-371.
17. Lacaze, X., Palanque, P., Navarre, D. Evaluation de
Performance et Modèles de Tâches comme Support à
la Conception Rationnelle des Systèmes Interactifs.
Actes du congrès IHM '02, 2002, pp. 17-24.
4. Bleser, T. W. and Sibert, J. Toto: a tool for selecting
interaction techniques. In Proceedings of UIST '90.
ACM Press, New York, NY, 1990, pp. 135-142.
http://doi.acm.org/10.1145/97924.97940
18. Lingrand D., de Morais W. O., Tigli J.Y. Ordinateur
porté : dispositifs d'entrée-sortie. Actes du congrès
IHM’05, 2005, pp. 219-222.
5. Burge, J., Brown, D.C. Reasoning with Design Rationale. Artificial Intelligence in Design’00, Netherlands, 2000, pp. 611-629.
19. MacKenzie, I. S. Input devices and interaction techniques for advanced computing. In W. Barfield, & T.
A. Furness III (Eds.), Virtual environments and advanced interface design, 1995, pp. 437-470. Oxford,
UK: Oxford University Press.
6. Buxton, W. Lexical and Pragmatic Considerations of
Input Structure. Computer Graphics 17(1), 1983, pp.
31-37.
20. McKerlie, D., MacLean, A. Reasoning with Design
Rationale: Practical Experience with Design Space
Analysis. Design Studies, 15, 2, 1994, pp. 214-226.
7. Card, S. K., Mackinlay, J. D., and Robertson, G. A
morphological analysis of the design space of input
devices. ACM Trans. Inf. Syst. 9, 2 (Apr. 1991), pp.
99-122. http://doi.acm.org/10.1145/123078.128726
21. Moran, T.P. and Carroll, J.M. Design Rationale:
Concepts, Techniques, and Use. Lawrence Erlbaum
Associates Publishers, 1996.
8. (ETSI) Human Factors (HF); Guidelines on the multimodality of icons and pictograms. EG 202 048
V1.1.1, August 2002.
22. Newman, W. and Lamming, M. Interactive System
Design. Addison Wesley, 1995, ISBN:0201631628.
9. Farenc, C. and Palanque, P. Exploitation des notations de Design Rationale pour une conception justifiée des applications interactives. Actes du congrès
IHM'99, 1999, Montpellier, pp. 33-40.
23. Paterno F. (2000). Model-Based Design and Evaluation of Interactive Applications, Applied Computing
Series, Springer.
24. Plouznikoff N. & Robert J.-M., Caractéristiques, enjeux et défis de l'informatique portée, Actes du
congrès IHM'04, 2004, pp. 125-132.
10. Fekete, J.-D., Girard, P. Environnements de développement de systèmes interactifs, dans C. Kolski.
(coodinateur) Interaction pour les Systèmes
d'Information, volume 2, Editions HERMES, Paris,
11. 2001.
Foley, J. D., Wallace, V. L., and Chan, P. 1984. The
25. Shakeri, C., Brown, D., Noori, M. Discovery of Design Methodologies. Artificial Intelligence in Design’00, Netherlands, 2000, pp 479-496.
human factors of computer graphics interaction techniques. IEEE Computer Graphic Applications. 4, 11
(Nov. 1984), pp. 13-48.
26. Weiser M. The Computer of the 21st Century, In
Scientific American, vol. 265, no. 3, 1991, pp. 66-75.
12. Florins, M., Trevisan, D., Vanderdonckt, J. The Continuity Property in Mixed Reality Systems and Multiplatform Systems: a comparative study. In Proceedings of CADUI’04, 2004, pp. 328-339.
27. Wellner P., Mackay W. and Gold R. Computer Augmented Environments: Back to the Real World. Special Issue of Communications of the ACM, vol. 36,
1993.
178
Une proposition pour améliorer la performance de
l'usager au sein du système d'information global de la
bibliothèque
Fabrice Papy
Sophie Chauvin
Document numérique & Usages
Document numérique & Usages
Université Paris 8
2 rue de la liberté 93526 Saint-Denis
Tél: 01 49 40 64 17 Fax : 01 49 40
Université Paris 8
2 rue de la liberté 93526 Saint-Denis
Tél: 01 49 40 64 17 Fax : 01 49 40
[email protected]
[email protected]
RESUME
has to evoluate in order to give to the users very recent
information technologies. From this point of view, the
library is an hybrid system which is simultaneously
obsolete and innovating and it is difficult to assess its
performance without considering the user posture, his
usability with the librarian information system and his
comprehension of the library conceptual model. With the
environnement we have developed and tested into an
academic library, we have identified some structural
elements which ameliorate the comprehension of the
library conceptual model and its potential uses.
La conservation et la diffusion des connaissances font
partie des missions clairement identifiées des
bibliothèques universitaires et aboutissent à la création
de systèmes d'information extrêmement complexes.
Ainsi, l'activité d'expertise des bibliothécaires en matière
d'organisation et de description des connaissances vient
rencontrer et accompagner une intégration importante de
ressources
documentaires
(traditionnelles
et
électroniques) et d'outils informatiques (OPAC, SRI,
portail documentaire) en constante évolution. Construite
sur des modèles anciens d'organisation des
connaissances, la bibliothèque doit s'adapter aux plus
récentes évolutions technologiques du traitement de
l'information afin de les mettre à la disposition des
usagers. De ce point de vue, la bibliothèque constitue un
système hybride simultanément obsolète et innovant
dont il est difficile d'évaluer la performance
indépendamment de la position de l'usager, de son degré
de familiarité avec les propositions technodocumentaires du lieu et de sa compréhension du modèle
conceptuel dans lequel s'inscrit toute la complexité de
l'objet culturel. A partir d'une interface d'interrogation
des données bibliographiques conçue et expérimentée au
sein de la bibliothèque de l'Université Paris 8, il a été
possible d'identifier des éléments structurels qui
améliorent la compréhension du modèle conceptuel
sous-jacent de la bibliothèque et ses usages potentiels.
KEYWORDS : Library Information System, user,
librarian, complexity, conceptual model, ICT, efficiency,
assessment, representation, Visual…Catalog, OPAC
LA BIBLIOTHEQUE UNIVERSITAIRE : UN SYSTEME
DOCUMENTAIRE COMPLEXE
Un espace multidimensionnel
La
bibliothèque
universitaire
est
un
lieu
multidimensionnel où les activités de l'expertise
professionnelle des bibliothécaires en matière
d'organisation des connaissances rencontrent les activités
intellectuelles et cognitives des usagers reliés
directement aux études supérieures et à la recherche.
Accompagnant les dimensions culturelle et sociale, ce
sont également les dimensions logistique (acquisition et
traitements du document) technique (service aux
usagers,
fonctionnement
réglementaire
de
la
bibliothèque) et technologique (catalogues, bases de
données et ressources électroniques) qui participent à
l'accessibilité du fonds documentaire. Ces différentes
dimensions qui répondent à des réalités et des logiques
de fonctionnement spécifiques se doivent de converger
afin de servir au mieux les missions institutionnelles de
la bibliothèque universitaire dans tout ce qui relève de la
conservation et de diffusion des connaissances. [1, 8].
MOTS CLES : Système d'information des bibliothèques,
usager, bibliothécaire, complexité, modèle conceptuel,
TIC,
efficacité,
évaluation,
représentation,
Visual…Catalog, OPAC
ABSTRACT
Making accessibility and preserving knowledge are
clearly identified missions of academic libraries and lead
to build complex information systems. So, the librarians'
expert activities in terms of knowledge organisation and
description meet and go with an important integration of
various resources (both traditional and digital) and tools
(OPAC, IRS) in constant increasing. Built upon old
knowledge organisation models, the academic library
Ces espaces documentaires institutionnels physiques,
numérisés et numériques, revisités par la médiation
technologique, pensés pour favoriser l’accessibilité
[6,7,9],
proposent
des
modèles
génériques
d’organisation des savoirs que matérialisent les
179
classifications telles que Dewey, CDU, Bliss, LCC, etc.
[18].
public qui en ignore (fréquemment) toutes les exigences
et toutes les subtilités.
L’organisation structurée et rationnelle portée par les
classifications imprime une volonté d’universalisation de
tous les savoirs. Vœu pieu, démesure ou exagération
prétentieuse, les classifications -à quelques tentatives
près partiellement appliquées comme la Classification à
facettes Colon- finissent par produire une approche
décontextualisée des connaissances. Sans pour autant
constituer la focale de l'activité des professionnels de la
bibliothèque (la formation et les services aux usagers en
sont d'autres), cette exigence de la classification pèse sur
la politique documentaire des services communs de
documentation (SCD), oriente une grande part de
l'activité professionnelle des bibliothécaires (acquisition,
catalogage) et concrétise l'adéquation de la bibliothèque
avec les formations suivies par les étudiants, les cours
dispensés par les enseignants et les activités scientifiques
des chercheurs.
La bibliothèque se présente alors comme un espace
ordonné, condamné à être mis cycliquement en désordre
par les usagers qui la pratiquent. Imaginer un
usager/lecteur – idéal - ayant développé une expertise
des lieux lui permettant d'exploiter à son avantage
l'organisation pointilleuse de la bibliothèque, sans en
perturber ni l'ordre ni le fonctionnement relève d'un
manifeste improbable. Ce modèle idéal de l'usagerexpert reste hautement anecdotique et cède la place au
modèle plus commun de l'usager-néophyte ayant des
besoins élémentaires de localisation et de disponibilité
d'ouvrages, de sélection de sources, de méthodologie de
la recherche, d'expression linguistique de ses recherches,
de transcription de ses demandes en expressions
syntaxiques "compréhensibles" par la multitude des
systèmes d'informations automatisés disponibles
(catalogue, cédéroms, sites spécialisées, Web
généraliste,..).
Avec les OPAC (On Line Public Access Catalog) les
catalogues informatisés des bibliothèques, ce ne sont ni
plus ni moins que les structures de données Unimarc, les
classifications (de type LCC, Dewey, CDU), les
vedettes-matières, qui sont brutalement portées à
l’appréciation d’usagers globalement incompétents. De
fait, la prétendue accessibilité dont sont porteuses les
TIC notamment en ce qui concerne l'information
numérique met en évidence l’existence de deux
communautés juxtaposées : d’une part celle des usagersutilisateurs en quête d’information mais peu concernés
par les exigences et les problématiques des bibliothèques
et d’autre part celle des bibliothécaires impliqués dans
des exigences professionnelles quotidiennes (service
public, acquisition, conservation, catalogage, prêt,
échanges de données).
Cette fracture entre les capacités avérées et les habiletés
présumées de l'usager, vision de l'esprit des
professionnels de la bibliothèque [10] se vérifie d'autant
mieux à l'éclairage des enseignements apportés par les
formations à la maîtrise de l'information, de la
méthodologie documentaire et du travail universitaire [3]
[5]. On y découvre que cet usager-néophyte vit
généralement dans l'ignorance de la complexité de
l'organisation
technique,
institutionnelle
et
socioculturelle de la bibliothèque et qu'il est d'autant
moins versé à y manifester de l'intérêt que la plus grande
part de ses efforts portera dans ses deux premières
années universitaires à appréhender, identifier et
s'approprier les règles du travail intellectuel qui forment
le canevas invisible de sa réussite.
Par rapport à cette activité déterminante, la bibliothèque
considérée cette fois-ci du point de vue des compétences
professionnelles impliquées et des expertises s'y
développant - qu'ignorent fréquemment les usagers implique une démarche volontaire de cohérence, de sens
global, selon des relations complexes de présupposition
logique,
de
généalogie,
de
complémentarité,
d'explicitation mutuelle [7] qui assurément introduit une
autre dimension que la simple accumulation d'ouvrages
[11].
Les évaluations des services aux usagers mettent en
évidence que l’amélioration de la qualité des services
passe par un subtil mélange de connaissances effectives
de la bibliothèque et d’une plus grande accessibilité de
l’expertise de ses professionnels.
La bibliothèque : lieu de savoirs, espace des
professionnels de la bibliothèque
Cependant les bibliothèques demeurent, malgré
l'accessibilité technique introduite par les TIC , des lieux
extrêmement spécialisés où les activités des
professionnels de la bibliothèques traduisent,
encapsulent et reflètent des modes d'organisation et de
communication, des savoirs, des contextes, des objets
physiques, des représentations mentales, des procédures,
et des systèmes de valeurs. En cela, les bibliothèques
sont le reflet d'une institution culturelle qui renvoie à des
valeurs, une organisation et un espace social complexe
[13]. Plus encore, la bibliothèque apparaît comme un
lieu de contradiction où l'organisation en place s'évertue
à développer, préserver une organisation rationnelle des
savoirs relevant presque d'un idéal à l'intention d'un
UNE
ORGANISATION
INTELLECTUELLE
VISIBLE PAR LES USAGERS
PEU
Ces impératifs de la gestion de la chaîne documentaire
ont réduit les processus d'organisation intellectuelle et de
cohérence globale du fonds et des collections, où
interviennent
l'expertise
professionnelle
des
bibliothécaires (spécialités disciplinaires, connaissances
des formations proposées par l'université) à quelques
propriétés qui n'apparaissent que trop discrètement dans
les OPAC [2, 20].
180
C'est dans le cadre d'une action de recherches pluridisciplinaire (Sciences de l'Information et de la
Communication, Informatique, Sciences de l'Education,
Cartographie, Psychologie-Ergonomie) que nous avons
cherché à vérifier l'hypothèse qu'un dispositif rénovant
les fonctionnalités des OPAC pourrait améliorer les
performances en RI des usagers principalement quand
les recherches s'inscrivent dans un processus de
repérages et de reconnaissances de champs et de
frontières disciplinaires [4, 15].
ces lieux, de véritables actions meta-cognitives visant à
homogénéiser et organiser les collections et le fonds
documentaire d'un point de vue intellectuel [6, 17, 19].
Améliorer les performances de l'usager
Le modèle que nous présentons (Fig. 1) rassemble sur 3
niveaux les objets qui sont porteurs de la visibilité de
cette méta-connaissance d'organisation.
L'organisation des salles de lecture et la distribution des
secteurs disciplinaires au sein de chaque salle constituent
de véritables connaissances de références introduites par
les conservateurs et bibliothécaires afin de donner aux
usagers tous les moyens de saisir les logiques d'organisation des collections et des proximités disciplinaires.
Il s'agit de rendre visible les objets conceptuels et leurs
relations qui interviennent de façon significative dans
l'organisation intellectuelle de la bibliothèque. On
constate souvent que les représentations de la
bibliothèque qu'ont les usagers sont erronées. Cette
différence profonde entre la représentation qu'ils en ont
et la réalité des missions de la bibliothèque universitaire
et de recherche provient d'un référent inadapté.
La couche supérieure "Classe" signale les grandes
catégories scientifiques relatives à la classification
adoptée (CDU, Dewey, Bliss, LCC) et aménagée en
fonction des spécialités développées par les
établissements de l'enseignement supé-rieur. Chacune de
ces classes regroupe plusieurs ouvrages qui sont
reconnus par les acquéreurs comme conformes aux
propriétés de la catégorie où ils figurent. Le sens des
flèches du graphique partant de chacun des nœuds de la
couche "Classe" peut être interprété comme "subdivision
composée de".
En effet, les usagers qui n'ont eu la possibilité de suivre
dans leur cursus universitaire un cours de méthodologie
documentaire [5] garde une représentation de la
bibliothèque universitaire proche de celle qu'ils peuvent
avoir du Centre de Documentation et d'Information
(CDI) de leur période lycéenne ou bien encore construire
à partir de leur pratique personnelle de la bibliothèque
municipale.
Ce sont les notices bibliographiques qui sont représentées dans la couche intermédiaire "entités". La notices et
les informations descriptives qui la composent (champs
et sous-champs UNIMARC) apportent tous les éléments
facilitant l'indexation et la recherche de l'ouvrage. Elles
rassemblent des méta-données destinées aux usagers (Titres, auteurs, éditeurs, format, …) et aux bibliothécaires
(zone SIBIL).
Il arrive cependant que ces usagers aient pu suivre
quelques heures de formations (dites formations aux
usagers) mises en place par les SCD eux-mêmes. Ces
formations de quelques heures subissent l'effet
instrumental des dispositifs en libre accès proposés par
les SCD. De fait, c'est la formation à la logique des
outils de RI généralistes et spécialisés (moteurs de
recherches, annuaires, encyclopédies, catalogues, bases
de données) qui l'emporte lors des séances planifiées (2
x 3h).
Les meta-données descriptives portent sur l'ouvrage en
tant qu'entité et sur ses instances (les exemplaires). Les
exemplaires sont dotées de propriétés spécifiques
comme le statut (empruntable, exclu du prêt, en
traitement, …) et la classe de rattachement. C'est par
l'intermédiaire des exemplaires que la notice se trouve
rattachée à une, voire plusieurs catégories scientifiques.
Quelles que soient leurs qualités et l'implication du personnel du SCD, ces formations demeurent parcellaires
(elles ne permettent pas de toucher tout le public de
l'uni-versité) et insuffisantes pour aboutir chez l'usager
au développement de véritables habiletés pour maîtriser
les dispositifs techniques [16]. L'offre toujours plus
importante d'outils informatiques et de bases de données
destinés à la RI accapare le temps des formations, qui
n'apportent alors que très indirectement un apprentissage
de la cohérence globale du système d'information de la
bibliothèque dans un objectif d'appropriation [14].
Classes (organisation intellectuelle)
Notices
(entités)
UN MODELE CONCEPTUEL EN COUCHE : CLASSES,
NOTICES ET ELEMENTS CONCEPTUELS RAMEAU
Les opérations de classification et de description sémantique à partir d'un langage documentaire et d'un vocabulaire contrôlé organisés ou non en thésaurus, la
distribution d'un ouvrage dans une ou plusieurs classes
thématiques constituent de la part des professionnels de
Eléments conceptuels RAMEAU
181
Fig. 1 : Modèle d'organisation intellectuelle des collections
dans une bibliothèque
: classes, éléments conceptuels
RAMEAU et notices
La dernière couche (éléments conceptuels RAMEAU)
contient, dans des notices d'autorité reliées provenant du
répertoire national RAMEAU (Répertoire d'AutoritéMatière Encyclopédique Alphabétique et Unifié) (cf.
http://rameau.bnf.fr), le vocabulaire et les indications qui
permettent de construire les vedettes-matières dans un
fichier bibliographique.
Le répertoire évolue sur la base des propositions faites
par le réseau des utilisateurs professionnels. La liste
d'autorité est complétée par le guide d'indexation qui en
assure la lecture cohérente et le bon usage. A la
différence d'un thésaurus, la liste d'autorité
encyclopédique n'est pas constituée a priori mais au fur
et à mesure des besoins d'indexation et évolue sur la
base des propositions faites par le réseau de ses
utilisateurs.
Fig. 2 : Le Visual…Catalog, Interface d'interrogation basée sur
le modèle classes, notices et éléments conceptuels RAMEAU
(http://visualcatalog.univ-paris8.fr)
CONCLUSION
Comme l'illustre la figure 1, les deux réseaux organisent
par des logiques bien distinctes le fonds documentaire.
Celui de la classification utilise un regroupement
thématique pré-établi qui créera une relation entre
l'exemplaire, l'univers intellectuel et l'espace de la
bibliothèque (les exemplaires sont généralement placés
en salles de lecture).
La généralisation des services de type "Bibliothèques
Numériques", passe invariablement par des catalogues en
ligne qui banalisent l'accès à des modes d'organisation des
connaissances qui demeure d'une rare complexité en
regard de l'immensité de la tâche. Cette mécanisation
logicielle systématique des systèmes d'informations,
induite par les TIC issues du Web, s'accompagne d'un
"allant de soi" en matière de manipulations techniques qui
tend à déteindre sur les habiletés intellectuelles soustendues. Il ne faut pas oublier que ces systèmes
d'informations ne sont en définitive que les ingrédients
destinés à agrémenter un processus long et exigeant de
transformation des individus, de compréhension et de
connaissances de soi, des autres, et des systèmes - quels
qu'ils soient - dans lesquels ils évoluent par choix ou par
contrainte. Dans ce dessein et indépendamment de toute
considération technologique, la capacité de l'individu à
appréhender et idéalement à s'approprier ces informations,
est loin d'être acquise. Elle repose sur des habiletés, des
stratégies, des savoir-faire qu'il revient à chacun d'adapter
et de puiser au fil des expériences sociales, culturelles et
cognitives qu'il est amené à vivre et qui sont garantes de
performances escomptées.
Le second, à l'inverse, s'affranchira des exemplaires pour
signer sémantiquement la notice d'un document. Cette
information offre alors la possibilité de croisement dans
des réserves bibliographiques mutualisées.
Le Visual…Catalog se présente comme un amplificateur
visuel des structurations sous-jacentes de la bibliothèque
et favorise les relations constructives entre la libre
associativité des usagers et les documents disponibles.
A partir de ce modèle, nous avons développé un dispositif expérimental (cf. figure 2) qui tout en utilisant les
mêmes meta-données, rénove le fonctionnement des
OPAC traditionnels [12]. Il se compose de 3 modules :
l'interrogation, l'exploration de la classification et la
localisation à partir d’une cartographie interactive. Cette
approche complémentaire à la recherche documentaire
repose sur l'intégralité du fonds bibliographiques du
SCD de l'université Paris 8 (360 000 notices
bibliographiques).
Il révèle l'organisation globale résultant des missions des
bibliothèques en matière de conservation et de diffusion
des connaissances. Placé à la périphérie du cœur des
activités intellectuelles complexes associées à la
transmission, la construction, l'acquisition et l'organisation
de connaissances, le dispositif tend à suggérer à l'usager la
nécessité d'acquérir les habiletés "méta-documentaires"
dépassant les démarches documentaires individuelles des
étudiants et enseignants-chercheurs, afin d'utiliser ce lieu
de connaissances à la hauteur des ressources
Une notice peut-être caractérisée par plusieurs vedettesmatières. Une vedette-matière peut être rattachée à plusieurs notices.
Un modèle utilisable par l'usager
Par rapport à une implication intellectuelle immédiate
que l'usager développe à l'endroit de la bibliothèque
poussé par les travaux de natures différentes que lui
imposent les exigences de son parcours universitaire, les
réseaux liés à la classification et au vocabulaire
RAMEAU s'avèrent selon nous les plus adaptés pour
pouvoir exploiter le plus exhaustivement possible le
fonds documentaire en limitant la désorientation et la
surcharge cognitive.
182
documentaires, techniques, humaines imbriquées et
reliées, qu'il met à leur disposition.
Ce dispositif expérimental fonctionne depuis octobre 2004
à la bibliothèque de l'université Paris 8 et exploite les
mêmes
données
bibliographiques
(actualisées
quotidiennement) que l'OPAC propriétaire (Absys).
Les sessions d'interrogation longues (entre 45 minutes et 4
heures, en local ou en distant) que nous avons pu constater
grâce aux croisements de données des fichiers-journaux
du serveur Web et des requêtes des usagers représentent
selon nous un indicateur pertinent d'une transformation du
comportement de RI de l'usager. Il n'est malheureusement
pas possible de confronter ces données avec celles de
l'OPAC propriétaire, les données d'enregistrement que
celui-ci fournit étant beaucoup moins fines.
Charte des bibliothèques adoptée par le Conseil
supérieur des bibliothèques le 7 novembre 1991,
http://www.enssib.fr/autres-sites/csb/csb-char.html
[consultée le 22 février 2005]
Dinet, J., Rouet, J-F., "La recherche d'information :
processus cognitifs, facteurs de difficultés et
dimensions de l'expertise", in IHM et recherche
d'informations, C. Paganelli (dir), Traité STI, Paris,
Hermes, 2002, pp 133-161.
5.
Jolly C., Bibliothèques universitaires. Regard sur les
changements, BBF 2001 - Paris, t. 46, n° 6
9.
Jolly, C., "Le plan U3M et les bibliothèques des
établissements d’enseignement supérieur", chniques
et architecture, juin-juillet 2001, n° 454, pp.80-83,
<http://www.sup.adc.education.fr/bib/Acti/U3m/plan
U3M.htm> (consulté le 21 février 2005)
14. Rabardel P. , "Les hommes et les technologies :
approche cognitive des instruments contemporains",
éd. A. Colin, Paris, 1995.
Chaudiron S., Ihadjadene M.., "Quelle place pour
l'usager dans l'évaluation des SRI ?", actes du
colloque "Recherches récentes en Sciences de
l'information", 21-22 mars 2002, Toulouse, AdbsEditions, V. Couzinet et G. Ré-gimbeau (dir), Paris :
ADBS éd., 2002, pp 211- 230
4.
8.
13. Polity Y., "Les bibliothèques, objets de recherche
universitaire" , BBF 2001 – Paris, t. 46, n° 4, p. 64-70
BIBLIOGRAPHIE
Coulon A., "Le métier d’étudiant. L’entrée dans la vie
universitaire", Paris, PUF, 1997.
Jacob C., "Travailler en bibliothèque", Recherches et
Bibliothèque, Les Cahiers de Paris VIII/Recherches,
PUV, 2005, p. 31-39
12. Papy F., Folcher V., Sidir M., Cerratto Pargman T.,
(2004) "E-Learning et technologies pour la
coopération : inadéquations artefactuelles et logiques
des activités instru-mentées", ERGO-IA, 17-19
novembre 2004
Ce travail de recherches s'effectue avec le SCD de
l'université Paris 8 et le groupe de recherche en
Psychologie-Ergonomie (C3U) dans le cadre d'un
partenariat de recherche.
3.
7.
11. Mounier E., "Systèmes documentaires et systèmes de
gestion de bibliothèques : place et rôle de l'opé-rateur
professionnel", in IHM et recherche d'informations,
C. Paganelli (dir), Traité STI, Paris, Hermes, 2002, pp
103-132
REMERCIEMENTS
2.
Hunter, E., "Do we still need classification ?", in The
Future of Classification, edited by R. Marcella and A.
Maltby (eds), Gower Publishing, Vermont, USA,
2000, pages 1-17.
10. Le Marec, J., Babou, I., "De l'étude des usages à une
théorie des composites" in "Lire, Ecrire, Récrire", E.
Souchier, Y. Jeanneret J. Le Marec (dir), BPI, Mars
2003, pages 235-299
A partir de ces sessions de consultations longues, rien ne
permet cependant de confirmer l'hypothèse d'une
amélioration des performances de l'usager en RI dans la
bibliothèque, rien ne permet de l'infirmer non plus. Les
prochains résultats d'une étude ergonomique menée par
une équipe de psychologues-ergonomes auprès de 10
sujets expérimentateurs nous en apprendront davantage.
1.
6.
15. Rice R.E., Mc Creadie M., Chang S-J L., Accessing
and Browsing: Information and Communication, The
MIT Press, London, England, 2001.
16. Rouet, J-F., "Les système d'information en ligne :
quels outils pour quels usages ?", Actes "Réseaux
humains / Réseaux technologiques", Maison des
Sciences de l'Homme et de la Société, Université de
Poitiers, 19 mai 2001
17. Rowley E. J., Organizing knowledge, 2nd Edition
reprinted by Gower Publishing, England, 1995.
18. Salvan, P. "Esquisse de l'évolution des systèmes de
classification", Ecole Nationale Supérieure des Bibliothèques, Paris, 1972
Féo A., "L'enseignement de méthodologie documentaire à l'Université Paris 8. Un accompagnement bien
tempé-ré". Documentaliste-Sciences de l'Information,
1998, vol. 35, n°3
19. Svenonius E., Information Organization, in The
intellectual Foundation of Informaton Organization,
MIT Press, 2000
20. Yee M.M., Shatford Layne S., Improving Online
Public Access Catalogs, London : American library
association, 1998.
183
Décomposition Multimodale de l’Activité :
Vers un outil d’aide à la conception
Plos Ornella
Buisine Stéphanie
Ecole Nationale Supérieure d’Arts et Métiers
Laboratoire Conception de Produits et Innovation
151, bd de l’Hôpital 75013 Paris
[email protected]
[email protected]
RESUME
média (téléphones mobiles, assistants personnels de type
PDA, lecteurs MP3, domotique…). Une interface est
dite multimédia lorsqu’elle transmet à l’utilisateur des
informations sous plusieurs modalités de communication
(informations visuelles, auditives, tactiles ou proprioceptives…) ; lorsque l’utilisateur peut lui aussi utiliser plusieurs modalités pour transmettre des informations au
système (entrées gestuelles, verbales…), l’interface est
dite multimodale [8]. Le multimédia et le multimodal
rendent potentiellement l’interaction plus riche, plus intuitive et parfois plus flexible. Encore faut-il, pour
l’utilisateur, disposer de toutes ses modalités perceptives
et motrices.
Aujourd’hui les produits de la vie quotidienne ont tendance à se doter de pouvoirs numériques, informationnels, communicationnels, etc. Ils deviennent donc « multifonctionnels » et par là même bien souvent « multimédia » ou « multimodaux ». Cependant il existe encore
des problèmes d’accessibilité de ces produits aux personnes en situation de handicap. Dans cet article, nous
présentons une méthode originale d’Analyse de
l’Activité : au-delà de la décomposition des activités en
actes élémentaires, nous faisons apparaître dans les diagrammes de représentation les modalités perceptives et
motrices associées à ces actes. Baptisée Décomposition
Multimodale de l’Activité, elle permet la prise en
compte des utilisateurs déficients dans le processus de
conception ainsi que la formalisation des données ergonomiques issues de l’analyse de l’activité.
L’accessibilité des nouvelles technologies aux personnes
présentant des déficiences est devenue une préoccupation affichée pour de nombreux industriels et pour les
pouvoirs publics. En France, cette préoccupation a récemment été formalisée par une loi (loi n° 2005-102 du
11 février 2005 pour l'égalité des droits et des chances,
la participation et la citoyenneté des personnes handicapées). A première vue, l’adaptation des produits multimédia et multimodaux ne semble pas poser de problèmes
insurmontables : ces produits exploitant par nature plusieurs canaux de communication avec l’utilisateur, on
peut imaginer compenser totalement l’absence d’une
modalité par le recours à une ou plusieurs autres modalités. Mais ceci nécessite d’avoir au préalable idéntifié
précisément le besoin, puis de l’avoir traduit de manière
appropriée en paramètres de conception. Prenons
l’exemple d’un utilisateur aveugle et d’un téléphone
mobile : si on considère uniquement que cet utilisateur
ne pourra pas recevoir les informations visuelles, on peut
penser que la déficience sera compensée par un système
de synthèse vocale (qui lit les informations affichées à
l’écran). Or, l’absence de vision perturbe également les
actions motrices de l’utilisateur, puisqu’il ne peut identifier par la vue les touches sur lesquelles il doit appuyer.
On pourrait alors penser que l’ajout d’un système de reconnaissance vocale (permettant d’agir sur le téléphone
par la parole au lieu du geste) résoudra le problème.
Mais en réalité il s’avère que pour certaines opérations il
n’est pas souhaitable d’utiliser des commandes vocales
(par exemple, lorsque l’utilisateur doit entrer son code
MOTS CLES : Ergonomie, Analyse de l’Activité, Handicap, Conception.
ABSTRACT
Nowadays products of the daily life tend to be
augmented with numeric, informative or communicative
power. They become thus “multifunctional” and
therefore often “multimedia” or “multimodal”. However,
there are still problems of product accessibility to
disabled people. In this article, we present an original
method of Activity Analysis: beyond the decomposition
of the activities in elementary acts, we insert in the
diagrams the representation of perceptive and motor
modalities associated to these acts. With this new
method called Multimodal Decomposition of the
Activity, it becomes possible to account for disabled
users in the design process. It also enables a
formalization of the ergonomic data collected during the
analysis of the activity.
KEYWORDS : Ergonomics, Activity Analysis, Disabled
People, Design.
INTRODUCTION
Avec le développement et la miniaturisation des technologies numériques, de plus en plus de produits de notre
environnement quotidien intègrent une interface multi-
185
PIN). Ainsi, l’accessibilité d’un téléphone mobile pour
un utilisateur aveugle impliquera nécessairement que le
clavier soit utilisable, notamment grâce à des repères tactiles [9]. Cet exemple montre que la conception de produits multimédia ou multimodaux adaptés aux personnes
présentant des déficiences nécessite une connaissance
approfondie à la fois des besoins des utilisateurs en termes de modalités d’interaction, et de l’activité réalisée
avec le produit ou le système.
x
x
x
L’objectif de cet article est de présenter une méthode
d’analyse de l’activité permettant de visualiser les modalités d’interaction sollicitées lors de l’utilisation d’un
produit ou d’un système. Dans un premier temps, nous
proposerons un bref état de l’art des méthodes d’analyse
des tâches ou de l’activité. Puis nous exposerons les
principes de notre méthode, intitulée Décomposition
Multimodale de l’Activité (DMA), avant d’en donner un
exemple d’application. Enfin, nous positionnerons les
apports potentiels de cette méthode dans le processus de
conception.
Ces modèles abordent l’analyse de l’activité sous des
angles légèrement différents, en intégrant des informations différentes, et permettent ainsi de répondre à des
objectifs d’évaluation ou de conception différents. Dans
le contexte qui nous intéresse (la conception de produits
multimédia / multimodaux adaptés pour des personnes
présentant des déficiences perceptives ou motrices), il
nous semble pertinent de chercher à intégrer les modalités d’interaction dans l’analyse de l’activité. Vis-à-vis
des méthodes que nous avons recensées, cette idée apparaît originale puisqu’elle ne semble pas avoir été mise en
œuvre auparavant. C’est en nous appuyant sur ce constat
que nous proposons ci-après une méthode de Décomposition Multimodale de l’Activité.
LES MODELES D’ANALYSE DES TACHES
L’analyse des tâches consiste à décrire précisément les
actions nécessaires lors de l’utilisation d’un système
pour atteindre un objectif donné. On distingue classiquement la tâche prescrite, telle qu’elle a été imaginée
par le concepteur du système, et l’activité, telle qu’elle
est effectivement réalisée par l’utilisateur. Les modèles
d’analyse de la tâche ou de l’activité sont des méthodes
qui permettent de formaliser et de visualiser les résultats
de cette analyse. Cette partie, destinée à présenter un rapide panorama des modèles existants, s’appuie principalement sur l’état de l’art fourni par Scapin et Bastien
[10].
LA DECOMPOSITION MULTIMODALE DE L’ACTIVITE
Certaines méthodes innovantes sont nées du rapprochement de différents modèles et outils préexistants ; c’est
le cas par exemple de la méthode SADT/Petri [1]. Nous
inspirant de cette démarche, nous avons pensé utiliser de
manière conjointe le modèle HTA [2] et la modélisation
dynamique et formelle des réseaux de Petri pour proposer une nouvelle méthode.
Les modèles d’analyse des tâches se présentent sous des
formes variées comme par exemple les diagrammes
d’entrées-sorties, les organigrammes fonctionnels, les
arborescences, les réseaux de Petri, etc. Un des principes
de base consiste à décomposer la tâche en sous-tâches
jusqu’au niveau terminal des actions. A cette décomposition peuvent s’ajouter d’autres relations entre les éléments : causales (conjonction et/ou occurrence), temporelles (séquencement, simultanéité), cognitives (comparaison, choix, décision…), etc.
Les réseaux de Petri permettent de décrire de façon formelle des sytèmes composés de variables, les places (représentées par des ellipses) qui peuvent changer d’état
grâce à des opérateurs de changement d’état, les transitions (représentées par des rectangles). L’état du système
est modélisé par une distribution de jetons dans les places du réseau représentant la valeur des variables [7]. La
figure 1 présente un exemple de réseau de Petri : la place
1 contient un jeton et la place 2 n’en contient pas, on dit
alors que la place 1 est marquée. La transition 1 a besoin
d’au moins un jeton dans la place 1 pour pouvoir
s’exécuter, on parle alors de franchir une transition.
Comme la place 1 contient un jeton, la transition 1 peut
être franchie, en retirant le jeton de la place 1 et en déposant le jeton dans la place 2. Après le franchissement de
la transition 1, la place 2 contient un jeton, rendant franchissable la transition 2, etc.
Parmi les premiers modèles d’analyse des tâches, le modèle HTA pour Hierarchical Task Analysis [2] consiste à
décomposer, de façon hiérarchique, une tâche globale en
sous-tâches élémentaires. Il permet alors de mettre en
évidence les informations nécessaires à l’utilisateur pour
chaque but et chaque sous-but. Par la suite, d’autres modèles se sont inspirés de cette structure, et notamment :
x
Le modèle GOMS qui décompose la tâche en
Goals, Operators, Methods et Selection rules
[4].
Le modèle KLM (Keystroke Level Model) [3],
qui permet de prédire le temps d’exécution des
tâches.
Le modèle MAD* ou MAD (STAR) (Modèle
Analytique de Description des tâcheS utilisaTeur orienté spécificAtion d’inteRface) [10] qui
permet de prendre en compte la dynamique de
la tâche avec ses interruptions, itérations, changements de niveaux, etc.
Le modèle CLG (Commun Language Grammar), qui comporte trois composants : conceptuel, communication, physique [6].
186
existe également des places facultatives (représentées
par des cercles en pointillé) et des transitions facultatives
(représentées par des rectangles en pointillé), qui correspondent à des actes élémentaires qui ne sont pas toujours
observés dans l’activité.
Place 1
Transition 1
Place 2
Il faut souligner que nous n’avons adopté que la représentation graphique des réseaux de Petri et non
l’intégralité de leur fonctionnement. En effet, certaines
règles n’ont pas pu être respectées, notamment au niveau
du parcours des jetons : dans les réseaux de Petri, c’est
un même jeton qui franchit des transitions successives.
Or, dans le cas des modalités d’interaction, il est parfois
nécessaire de mettre en jeu différentes modalités pour
accomplir des actes élémentaires successifs. Chaque
modalité n’est pas nécessaire à toutes les places et une
modalité unique est insuffisante pour parcourir tout le
diagramme. En conséquence, nous ne faisons apparaître
au niveau de chaque place que les modalités qui y sont
mises en jeu. Par exemple, si une partie de l’activité
consiste à réagir à un signal sonore par un geste, la première place fera apparaître la modalité auditive uniquement et la seconde fera apparaître la modalité gestuelle
uniquement.
Transition 2
Figure 1: Exemple de réseau de Petri.
Certains réseaux de Petri appelés Object Petri Nets ont
été utilisés dans le cadre d’analyse des tâches comme
ICO (Interactive Cooperative Object) [7] ou TOOD
(Task Object Oriented Design) [11] ainsi que pour modéliser l’activité cognitive [5]. Ils permettent notamment
de modéliser des objets d’un système disposés en réseau.
Cette représentation a l’avantage de permettre une souplesse de modélisation en faisant ressortir l’aspect dynamique (parallèlisme, synchronisation, etc.) des tâches.
Le principe de l’intégration de jetons dans le diagramme
représentant l’activité nous a semblé intéressant pour
faire apparaître les modalités d’interaction. Nous avons
donc élaboré la méthode de Décomposition Multimodale
de l’Activité (DMA) en combinant une analyse de
l’activité de type HTA [2] avec la représentation graphique des réseaux de Petri.
Pour marquer une place obligatoire en l’absence de jeton, l’ajout d’un compensateur (C) permet de « réparer »
les conséquences d’une modalité absente ou déficiente.
Cette notion peut être assimilée à celle des réparateurs
que l’on retrouve dans les résaux de Petri utilisés en
« sécurité machine ». Ces éléments permettent notamment de franchir une transition si la place n’est pas marquée. Par exemple, pour un équipement qui tombe en
panne, la transition « attente de réparation » peut être
franchie si un réparateur externe est disponible (figure
2). Dans notre méthode DMA, les compensateurs sont
représentés par des losanges et peuvent être une solution
qui englobe plusieurs places, ou une solution qui agit sur
une seule transition.
En reprenant le principe de décomposition du modèle
HTA [2], l’activité est décomposée en actions jusqu’à
obtenir des actes élémentaires. Cette décomposition
poussée permet d’identifier, pour chaque acte élémentaire, les modalités perceptives (visuelle, auditive, tactile, etc.), motrices (geste, parole, etc.) et cognitive (dans
notre modèle, la modalité cognitive regroupe toutes les
fonctions cognitives de manière non différenciée : un
choix, une décision, une recherche en mémoire, etc.) de
l’interaction homme-système.
P1 : équipement
en marche
T1 : panne
Chacun de ces éléments (les actes élémentaires, les modalités) est ensuite traduit au sein d’une représentation
globale utilisant le formalisme graphique des réseaux de
Petri. Les actes élémentaires sont représentés comme un
ensemble de places (P) et de transitions de places (T).
Chaque place est marquée par la mise en jeu d’une ou
plusieurs modalités, représentées par des jetons ronds,
triangulaires et carrés (correspondant aux modalités perceptives, motrices et cognitives, respectivement). Dans
notre modèle, ce sont donc les modalités (jetons) qui
permettent de passer d’un acte élémentaire à un autre
(places, transitions de places). Si une place obligatoire
(représentée par un cercle continu) n’est pas marquée
(absence de jetons) car la ou les modalités sont déficientes ou absentes, la transition ne peut être franchie. Il
P2 : équipement
en panne
R : réparateur
disponible
T2 : équipement en
attente de réparation
P3 : équipement en
réparation
T1 : équipement
réparé
Figure 2: Exemple de réseau de Petri avec un réparateur.
187
L’originalité de ce nouveau modèle repose sur le fait de
pouvoir identifier et comprendre la mise en jeu des différentes modalités lors de la réalisation d’une activité. Il
permet de voir, de façon schématique, quels actes élémentaires vont poser problème lorsqu’une modalité est
déficiente ou absente. L’équipe de conception peut alors
réfléchir à la façon d’éviter un blocage lié à une déficience, c’est-à-dire d’intégrer des compensateurs ou d’en
créer de nouveaux. Les compensateurs peuvent provenir
notamment :
x
x
jetons triangulaires aux modalités motrices (geste et parole) et le jeton carré représente les modalités cognitives.
La colonne de gauche décrit l’activité « composer un
numéro » pour une personne non déficiente disposant de
toutes ses modalités. La colonne du milieu illustre la
même activité à effectuer par une personne non voyante.
L’absence de la modalité « vue » s’exprime par la suppression du jeton rond bleu dans le diagramme. Cela
permet d’identifier les actes élémentaires (places et transitions de places) qui vont être touchés par l’absence de
cette modalité. Les places problématiques pour une personne non voyante sont par conséquent :
D’une modification des modalités d’interaction
existantes : par exemple une personne malvoyante peut avoir besoin d’augmenter la taille
et le contraste des caractères dans un message
textuel.
Et/ou de l’utilisation de modalités alternatives :
pour une personne aveugle on peut compenser
en améliorant les retours sonores ou tactiles.
x
x
Dans la section suivante, nous proposons de déployer la
méthode de Décomposition Multimodale de l’Activité à
un exemple concret.
L’identification des touches (reconnaître les
touches portant un numéro des touches de
contrôle, distinguer les touches portant des numéros entre elles, etc.).
La vérification, à l’écran, du chiffre ou du numéro composé (être sûr qu’on a bien appuyé sur
la bonne touche).
La colonne de droite représente l’activité réalisée par
une personne non voyante avec différentes solutions (ou
compensateurs) possibles mises à disposition.
L’introduction d’un compensateur (représenté par un losange) entraîne l’apparition de nouvelles modalités dans
le diagramme. Par exemple, une solution de discrimination tactile des touches se traduit par un nouveau jeton
de perception tactile, un système de reconnaissance vocale permet l’introduction d’un jeton de parole, et des
feedbacks auditifs donnent lieu à autant de jetons de perception auditive. La modélisation DMA pour un utilisateur non voyant (colonne de droite) offre une vue synthétique de l’activité avec notamment :
APPLICATION A L’UTILISATION D’UN TELEPHONE
PORTABLE
Avec un taux d’équipement avoisinant les 70% en
France, le téléphone mobile peut être considéré comme
un produit grand public, à forte valeur ajoutée. Ce produit réunit à la fois une interface physique et une interface numérique, qui sont liées dans le sens où la facilité
de navigation de l’interface numérique (l’accès aux différents menus, les retours en arrière, l’intuitivité…) est
en partie dépendante de l’utilisabilité de l’interface physique (prise en main et taille du téléphone, taille et résolution de l’écran, taille du clavier, forme et emplacement
des touches, symboles des raccourcis…). Au final, il est
difficile de traiter l’un sans l’autre, l’interface physique
pouvant avoir des conséquences sur l’interface numérique. Pour comprendre cette relation de dépendance, il
semble préférable d’étudier le produit dans sa globalité.
x
x
Parmi toutes les manières d’émettre un appel au moyen
d’un téléphone portable (composer un numéro, utiliser le
répertoire…), nous prendrons l’activité « composer un
numéro » pour appliquer notre méthode DMA.
x
Cette activité peut être décomposée en actes élémentaires (par exemple : presser une touche), auxquels sont associées des modalités perceptives, motrices et cognitives. La figure 3 montre trois diagrammes (un par colonne) obtenus en appliquant notre méthode à l’activité
« composer un numéro ». Les places sont représentées
par des cercles, les transitions de places par des rectangles. A l’intérieur du diagramme figurent des jetons qui
représentent les modalités : les jetons ronds correspondent aux modalités perceptives (vue, toucher, ouïe), les
Des solutions existantes comme la reconnaissance vocale (commande vocale) disponible sur
certains modèles de téléphones portables, ou la
synthèse vocale.
Certaines stratégies employées par les utilisateurs, que nous avons identifiées grâce à des entretiens et des observations. C’est par exemple
le cas du repérage tactile grâce au point sur la
touche 5 du clavier.
De nouvelles voies de solution, comme par
exemple le repérage par discrimination tactile
des touches : l’utilisateur pourrait identifier certaines touches grâce à leur forme particulière ou
à leur texture.
La méthode DMA peut ainsi s’avérer utile en phase de
traduction du besoin, pour formaliser les résultats de
l’analyse du besoin et en déduire des spécifications pour
la conception ou la re-conception. Mais les bénéfices potentiels de cette méthode ne se limitent pas à cette
188
Activité effectuée
par une personne
non déficiente
P2.1 : identifier la
touche x
P4.1 : entendre la
pression (bip ou
clic)
P4.2 : sentir le
retour d’effort
P4.3 : voir le chiffre à l’écran
P6.1 : identifier la
touche appeler
P8.1 : entendre la
pression (bip ou
clic)
P8.2 : sentir le
retour d’effort
P8.3 : voir l’appel
à l’écran
Modalités perceptives
toucher
vue
ouïe
P0 : appeler
contact
Activité à effectuer
par une personne
non voyante
Activité effectuée
par une personne
non voyante
P0
P0
T0 : composer le
n°
T0
T0
P1 : choix du
contact à apeler
P1
P1
T1 : n° à composer
retrouvé
P2.2 : Diriger et
positionner son
doigt sur la touche x
T2 : touche x
sélectionnée
T1
P2.1
P2.2
P4.1
P4.2
P4.3
T2
P2.1 : identifier
la touche x par
repérage tactile (point sur
le 5) et représentation mentale du clavier
P4.1
P4.2
P4.3 : entendre
le chiffre composé s’afficher
à l’écran
C1 : texture,
forme, espacement des
touches
T1
P2.2
C2 : synthèse
vocale
T2
P3 : presser
la touche x
P3
T3 : touche x
pressée
T3
P5 : vérification
du n° composé
P5
P5 : entendre le
n° composé
T4 : n° vérifié
T4
T4
P6.2 : Diriger et
positionner son
P6.1
doigt sur la touche appeler
T5 : touche appeler sélectionnée P8.1
P8.2
P8.3
P6.2
T5
P3
T3
P6.1 = P2.1
P8.1
P8.2
P8.3 : entendre la
confirmation
d’appel
T5
P7
T6 : touche appeler
pressée
T6
T6
P9 : attendre
l’émission de
l’appel
P9
P9
T7 : appel émis
T7
T7
parole
geste
C1
P6.2
P7 : presser la
touche appeler
Modalités motrices
C3 : reconnaissance vocale
P7
P : Place obligatoire
P : Place problématique à
compenser
P : Place facultative
C : Compensateur
T : Transition
T : Transition facultative
Modalités cognitives
Figure 3: Exemple de diagrammes DMA appliqués à l’activité « composer un numéro » sur un téléphone portable. Le modèle de
gauche correspond à la réalisation de cette activité par un utilisateur disposant de toutes ses modalités ; les deux autres modèles par
un utilisateur non voyant sans compensateurs (milieu) et avec compensateur (droite).
189
seule phase, comme nous allons tenter de le montrer
dans la section suivante.
En phase de traduction du besoin, la DMA peut être
utilisée en trois points (DMA1, DMA2, DMA3 sur la
figure 4). La DMA1 est réalisée par les concepteurs, et
repose sur deux sources principales :
INTEGRATION AU PROCESSUS DE CONCEPTION
La figure 4 montre différents points d’insertion pour la
méthode DMA dans le processus de conception. Nous
considérons ici principalement un projet du type
conception de produit multimédia ou multimodal, en
particulier lorsqu’un des objectifs est qu’il soit adapté
aux personnes présentant des déficiences ; car dans ce
cas l’étude des modalités d’interaction doit être plus
fine.
TRADUCTION DU BESOIN
x
x
L’Analyse Fonctionnelle Externe (méthode
APTE®) des produits existants et de leur environnement, qui permet d’avoir une première
idée du fonctionnement global du système.
L’analyse des produits et solutions existantes,
la veille technologique, afin d’intégrer au modèle les technologies disponibles.
Analyse de
l’existant
Analyse de l’activité
de l’utilisateur
Description structurelle et
fonctionnelle du système
Modélisation de
l’activité effectuée
par l’utilisateur
Analyse fonctionnelle
Modélisation de
l’activité à effectuer
par un utilisateur
DMA2
DMA1
DMA3
INTERPRETATION
DU BESOIN
Cahier des charges
fonctionnel
Recherche de
concepts d’usage
DMA3
Phase créative : rechercher
et proposer de nouveaux
concepts technologiques et
d’usage
Recherche de concepts
technologiques
DMA4
DEFINITION ET VALIDATION
Cahier des charges
concepteur
DMA4
Tests utilisateurs
Matérialisation et évaluation
du produit (pré-maquette et
prototype)
DMA5
Figure 4: Utilisations potentielles de l’outil DMA dans le processus de conception.
190
DMA1 correspond plus ou moins à l’usage prescrit par
l’équipe de conception en phase amont. Vis-à-vis de
notre précédent exemple (figure 4), DMA1 correspond
aux organigrammes de gauche (utilisateur non déficient) et du milieu (hypothèse et anticipation des problèmes d’un utilisateur présentant une déficience et ne
bénéficiant d’aucun compensateur). DMA2 concerne
davantage les données réelles issues de l’analyse de
l’activité des utilisateurs cibles. Cette étape permet de
recueillir les stratégies et les besoins des utilisateurs, et
a pour but d’aboutir à des recommandations d’ordre
ergonomique pour la conception du nouveau produit.
La méthode DMA permet non seulement de synthétiser
les données recueillies, mais également de guider
l’analyse de l’activité. En effet, la réflexion sur l’usage
possible (prescrit) menée avec DMA1 pourrait permettre de préparer le terrain et d’observer tout de suite les
places qui ne s’effectuent pas de la manière prévue,
celles qui manquent… DMA2 aboutit à une comparaison du prescrit et du réel.
compte des spécificités d’une population en termes de
modalités d’interaction :
x
x
DMA peut aider à identifier les problèmes potentiels et réels liés à l’absence ou l’altération
d’une modalité.
Elle peut aussi faciliter la recherche de solutions existantes ou innovantes pour compenser
des modalités d’interaction déficientes.
Comme tout modèle d’analyse de la tâche ou de
l’activité, DMA n’est qu’une représentation abstraite
de la réalisation de l’activité, qui peut varier en fonction des différences interindividuelles, du contexte, du
produit, etc. Elle ne permet de comprendre que certains
aspects du problème, mais peut néanmoins être utile à
l’analyse et à la conception.
L’emprunt du formalisme graphique des réseaux de Petri permet au modèle DMA de proposer une décomposition uniforme de l’activité, avec une description des
interactions aussi bien déclarative (état des choses) que
procédurale (façon d’arriver à ces états). Autorisant la
prise en compte de phases parallèles et séquentielles,
DMA peut être ajusté en fonction du système étudié ou
du contexte de réalisation de l’activité.
DMA3 est un modèle synthétique et enrichi
(DMA1+DMA2), dont l’objectif est à la fois d’être le
plus proche possible de l’activité réelle d’utilisation
des produits existants et de faire figurer de premières
solutions et hypothèses de conception. DMA3 est destiné à servir de donnée d’entrée à la rédaction du Cahier des Charges Fonctionnel.
L’originalité de DMA repose sur la mise en avant des
modalités d’interactions utilisateur-système dans
l’usage d’un produit. Elle permet d’identifier les problèmes liés à une modalité déficiente mais pourrait aussi être utilisée pour un produit qui utilise une modalité
plus qu’une autre, etc. Cette méthode permet de formaliser les données issues du terrain et d’intégrer
l’analyse de l’activité de façon schématique dans un
outil utilisé par l’ensemble de l’équipe de conception.
Elle permet également au concepteur d’imaginer
l’usage d’un produit encore non-existant et d’en anticiper ses problèmes potentiels.
DMA3 faisant également ressortir les besoins des utilisateurs, cette représentation intermédiaire peut aussi
être un support de créativité lors de la phase
d’interprétation du besoin. Face à l’altération ou
l’absence d’une ou plusieurs modalités, la phase de
créativité peut être orientée vers la recherche de solutions et de compensateurs, aboutissant ainsi à de nouveaux concepts d’usages. Une fois un ou plusieurs
concepts sélectionnés, le modèle est remis à jour pour
les intégrer. On obtient alors DMA4.
En phase de définition et de validation du produit,
DMA4 est traduit en paramètres de conception. Ce
même diagramme peut aussi permettre d’élaborer un
guide d’évaluation du produit soulignant les critères à
respecter au niveau des modalités mises en jeu dans
l’utilisation du produit (DMA5).
Nous avons mis en œuvre l’outil DMA dans le cadre
d’un projet de définition d’un Cahier des Charges
d’Evaluation Handicap de terminaux mobiles pour un
opérateur français de téléphonie mobile. Notre utilisation s’est arrêtée au stade DMA3 et n’a pas été étendue
à un processus de conception complet, néanmoins cette
méthode a été appréciée pour ses qualités de synthèse
des données recueillies lors de l’analyse de l’existant et
de l’analyse des besoins des utilisateurs.
Le processus de conception présenté en figure 4 inclut
la possibilité de retours en arrière vers DMA3 ou
DMA4 afin de les corriger en fonction des résultats
d’évaluation de la maquette ou du prototype, et ainsi
d’opérer une boucle d’amélioration du produit.
La méthode DMA n’ayant pas été appliquée à toutes
les étapes du processus de conception, elle manque
sans doute de maturité à l’heure actuelle. Son utilisation tout au long de la démarche de conception devrait
permettre d’évaluer sa pertinence pour chaque étape et
éventuellement de l’améliorer. Nous pouvons aussi envisager d’expérimenter son usage par différents acteurs
CONCLUSION
La méthode de Décomposition Multimodale de
l’Activité proposée dans cet article peut s’avérer être
un outil d’aide à la conception permettant la prise en
191
7. Navarre, D. Contribution à l'ingénierie en Interaction Homme Machine - Une technique de description formelle et un environnement pour une modélisation et une exploitation synergiques des tâches et
du système: Thèse de l'Université de Toulouse,
2001.
de la conception afin d’évaluer ses coûts et ses bénéfices. Car si la DMA propose une logique de fonctionnement qui se veut intuitive, empruntée aux réseaux de
Petri, il s’avère nécessaire de s’accoutumer, par apprentissage, au formalisme graphique.
BIBLIOGRAPHIE
1. Abed, M., Bernard, J.M., and Angué, J.C. Task
analysis and modelization by using SADT and Petri
Networks. In Proceedings of European Conference
on Human Decision Making and Manual Control,
1991.
8. Oviatt, S.L. Multimodal interfaces. In J.A. Jacko
and A. Sears (Ed.) The Human-Computer
Interaction Handbook: Fundamentals, evolving
technologies and emerging applications, Lawrence
Erlbaum Associates, Mahwah, NJ. 2003, pp. 286304.
2. Annett, J. and Duncan, K.D. Task analysis and
training design. Occupational Psychology, 41,
1967, pp. 211-221.
9. Plos, O. and Buisine, S. Universal design of mobile
phones: A case study. In Proceedings of CHI'06
International Conference on Human Factors in
Computing Systems (work-in-progress), ACM
Press, 2006, pp. 1229-1234.
3. Card, S.K. and Moran, T.P. The Keystroke-Level
Model for user performance time with interactive
systems. Communication of the ACM, 23, 1980,
pp. 396-410.
10. Scapin, D.L. and Bastien, J.M.C. Analyse des tâches et aide ergonomique à la conception: L'approche MAD*. In C. Kolski (Ed.) Analyse et Conception de l'IHM, Hermès Science Publications, Paris.
2001, pp. 85-116.
4. Card, S.K., Moran, T.P., and Newell, A. The
Psychology of Human Computer Interaction.
Hillsdale, N.J.: Erlbaum, 1983.
5. Ezzedine, H. and Kolski, C. Modelling of cognitive
activity during normal and abnormal situations
using Object Petri Nets, application to a
supervision system. Cognition, Technology &
Work, 7, 2004, pp. 167-181.
11. Tabary, D., Abed, M., and Kolsky, C. Object
oriented modelling of manual, automatic,
interactive tasks in mono or multi-user contexts
using the TOOD method. In Proceedings of
Conference on Management and Control of
Production and Logistics, 2000, pp. 101-111.
6. Moran, T.P. The command language grammar: A
representation of the user interface of interactive
computer systems. International Journal of ManMachine Studies, 15, 1981, pp. 3-50.
192
Comparaison de deux méthodes de prédiction des
erreurs humaines en conduite automobile
Polet Philippe, Chaali-Djelassi Abir, Vanderhaegen Fréderic
Laboratoire d'Automatique de Mécanique et d’Informatique industrielles et Humaines (LAMIH)
Université de Valenciennes et du Hainaut-Cambrésis - UMR 8530 CNRS
Le Mont Houy - 59313 Valenciennes Cedex 9 – FRANCE
{ppolet,vanderhaegen,abir.djelassi}@univ-valenciennes.fr
RESUME
ou diminuer l’impact des conséquences. Or, il n’est pas
rare de constater que des barrières soient désactivées
sciemment par les opérateurs humains. Ce type de comportement est appelé un franchissement de barrières.
Afin d’améliorer la sécurité des systèmes il est primordial de comprendre les raisons poussant les opérateurs
humains à commettre ces comportements erronés. Il est
également important de pouvoir anticiper ces comportements déviés afin de mettre en place des moyens de sécurisation adaptés. Ces comportements sont qualifiés d'erronés en référence à la définition de l'erreur humaine en
sûreté de fonctionnement : « Écart entre le comportement de l’opérateur humain et ce qu’il aurait dû être, cet
écart dépassant des limites d’acceptabilité dans des
conditions données » [17]. Cet article présente dans un
premier temps le cadre théorique du franchissement de
barrière. Une seconde partie propose deux méthodes de
prédiction des franchissements de barrières. Les résultats
des deux approches sont ensuite comparés. Une dernière
partie tire les conclusions de cette étude préliminaire et
propose des perspectives de recherche.
Cet article présente deux modèles de prédiction de comportements humains erronés particuliers : les franchissements de barrières qui sont des non-respects volontaires,
i.e. des violations, de barrières de sécurité [1]. L’analyse
de ce type de comportement suit les caractéristiques du
modèle BCD qui détermine les bénéfices, coûts et déficits potentiels qui sont associés à ces franchissements de
barrières et qui motivent leur occurrence. Deux modèles
sont proposés : un basé sur le raisonnement à partir de
cas, un second basé sur un réseau de neurones. Ils sont
validés et comparés à partir de résultats d’une campagne
expérimentale de simulation de conduite automobile.
MOTS CLES : Fiabilité Humaine, violations, conduite
automobile, réseau de neurones, Raisonnement à partir
de cas.
ABSTRACT
This paper purpose two model in order to predict particular erroneous human behaviour : barrier removal which
correspond to intentional non-respect (i.e. violation) of
safety rules, or safety equipment [1]. The analysis of this
kind of behaviour may be supported by the BCD model
determining benefit, cost and deficit associated to the
barrier and motivating its removal. Two models are proposed : the first one, the case-based reasoning, and the
second one, a neural network oriented approach. The
preliminary results obtained with these methods are
presented. The data come from an experimental campaign in car driving simulation.
LE FRANCHISSEMENT DE BARRIÈRE
La majeure partie des méthodes d’analyse de la fiabilité
humaine se base sur des typologies d’erreurs humaines.
La typologie proposée par Reason [3] est certainement
l’une des plus utilisée (Cf. figure 1).
KEYWORDS : Human Reliability, violations, car driving, neural network, Case-Based Reasoning.
INTRODUCTION
La majeure partie des systèmes industriels comporte des
risques liés à leur exploitation. Afin de diminuer ces
risques, les concepteurs mettent en place des moyens de
prévention et/ou protection appelés barrières. Hollnagel
[2] définit la barrière comme un obstacle, une obstruction
ou une gêne qui peut soit (1) prévenir l’exécution d’une
action ou l’apparition d’un événement, soit (2) prévenir
Figure 1: typologie des erreurs humaines selon Reason [3].
193
Deux catégories d’erreurs sont retenues les erreurs
intentionnelles (les ratés, les lapsus et les fautes) et les
erreurs intentionnelles (les violations).
Notre objectif est de déterminer s'il est possible de prédire le comportement d'un opérateur humain face à des
barrières en ne se basant que sur l'observation du comportement en cours, de l'opérateur.
Les méthodes d’analyse de la fiabilité humaine se
focalisent essentiellement sur les erreurs nonintentionnelles, pour lesquelles il est possible de calculer
des probabilités d’occurrence. La plupart des méthodes
ne sont pas adaptées pour l’analyse des violations. Une
analyse spécifique des violations doit être réalisée afin
d’en déterminer les causes. En effet, les violations sont
une conséquence inévitable de la recherche de
performance dans les systèmes sociaux techniques
complexes. C'est le point de vue de Diane Vaughan dans
sa célèbre analyse de l'accident de Chalenger, pour qui
les « derives normales » sont placées au coeur des causes
d'accidents[11].
Nos approches doivent tenir compte du fait que nous n'avons pas de connaissances formalisées sur le domaine.
Par conséquent, nous proposons deux approches : l'une
basée sur les réseaux de neurones, la deuxième basée sur
le raisonnement à partir de cas.
Pour ce faire, le contexte expérimental retenu a été la
conduite automobile. Il s'agit en effet, d'un contexte où
les franchissements de barrières (infractions au code la
route) sont importants.
PRÉSENTATION DE LA CAMPAGNE EXPÉRIMENTALE
Polet et al. [4] proposent un modèle explicatif (le modèle
BCD) du franchissement de barrière. Pour ce faire, une
approche multi-critères est nécessaire. En effet, l’opérateur humain, lors de la réalisation de ses tâches, tient
compte de différents critères tels que la productivité, la
qualité des produits réalisés, sa charge de travail, la sécurité… . Son objectif est d’optimiser son activité afin de
maximiser ces critères.
Le LAMIH dispose d'un simulateur de conduite grande
échelle (cf . figure 2).
Le respect de barrières constitue dans certains cas des
contraintes pour l’opérateur. Par exemple, cela implique
une augmentation de la charge de travail de celui-ci en
obligeant l’arrêt d’une ligne de production pour effectuer
une opération de maintenance. En effet, certains dispositifs de sécurité empêchent toute intervention sur un outil
quand il est en marche.
Figure 2 : Le simulateur de conduite du LAMIH.
Selon ces auteurs, un franchissement de barrière est une
dérive comportementale intentionnelle dont les
conséquences sur la situation courante peuvent être analysées suivant trois paramètres d’évaluation multicritère.
Pendant l'expérimentation, 22 sujets ont été confrontés
deux ou quatre fois à trois types de barrières : le respect
de la ligne continue, un stop et une intersection avec
priorité à droite. L'étude présentée dans cet article
concerne unique ment les situations d'intersections avec
priorité à droite devant être respectées par le sujet (cf.
figure 3).
- Un bénéfice immédiat qui représente le gain associé au
non-respect de la barrière.
- Un coût immédiat qui est une perte acceptable pour l’utilisateur afin d’atteindre le bénéfice attendu. Il est physique lors du retrait de la barrière, puis cognitif afin de
contrôler le déficit potentiel.
- Un déficit potentiel est une perte inacceptable due à un
échec possible du franchissement de barrière.
Ce modèle a démontré son utilité pour expliquer les franchissements de barrières. Néanmoins, il nécessite a priori, d'avoir identifié les bénéfices, coûts et déficits perçus
par l'opérateur. Ces données ne sont pas toujours disponibles.
Figure 3: situation d'intersection avec règle de priorité à droite.
Différentes données durant l'expérimentation ont été
enregistrées par le simulateur de conduite pour chaque
194
sujets : le numéro d'ordre de la situation, le nombre de
fois où le sujet était confronté à cette situation (2 ou 4),
les vitesses d'approche à l'intersection, les rapports de
boite de vitesse, la position des pédales d'accélérateur et
de frein, l'angle du volant.
Un neurone intègre en général une sommation p des entrées xi pondérées par des poids wi et une transformation
de cette pondération par une fonction F(p), (cf. figure 5).
Par ailleurs des indicateurs ont été calculés. En effet, un
véhicule se déplace dans un environnement avec lequel il
peut interagir. A tout moment, il est possible de calculer
dans une fenêtre temporelle, les points qui pourront être
atteints par le véhicule. Certains de ces points
correspondent à des point de collision (cf. figure 4).
Figure 5 : Principes d’un réseau de neurones.
Les entrées xi d’un neurone peuvent être externes à un
réseau de neurones ou être les sorties d’un de ces derniers. Différentes connexions peuvent alors être déterminées à partir des flux de transfert de l’information dans
un réseau donné. Par exemple, dans une connexion
récurrente, le calcul de la sortie d’un neurone est un processus en boucle fermée alors que dans une connexion
directe, il est en boucle ouverte.
Figure 4 : prévision des points atteignables par un véhicule en
mouvement.
3 indicateurs ont été élaboréss :
•
La sécurité (S), qui est évaluée comme suit
=
∑
,
ou tac représente le temps avant collision.
•
•
le degré de liberté (DL) :
L'espace libre autour du véhicule E
Les travaux de Kohonen [5] basés sur les cartes auto-organisatrices ont été appliqués pour prédire les décisions
de franchissements de barrières. Une carte auto-organisatrice est le résultat d’un réseau récurrent de k neurones à
n entrées et k sorties. Elle permet d’établir une cartographie des distributions de données en propageant par calcul de similarité la sortie d’un neurone sur les neurones
voisins. On peut imaginer que le fonctionnement de ce
réseau se présente sous la forme d’une série de n harpes à
k cordes désaccordées et dont les notes initiales sont inconnues. La phase d’apprentissage du réseau permet
alors d’accorder toutes les harpes en fonction des avis
des opérateurs humains et de déterminer le meilleur accord commun.
L'analyse à posteriori des situations a permis de statuer
sur le comportement (respect ou non de la priorité à
droite). Dans chacune des situations un véhicule se trouvait à la droite du véhicule du sujet. Si le sujet ne laissait
pas passer le véhicule à droite on constatait un refus de
priorité (noté FB).
Chaque situation a donc été décrite selon un vecteur d'entrées utilisable soit par un réseau de neurone ou un raisonnement à partir de cas.
Les valeurs initiales des poids wi sont fixées arbitrairement mais sont remises à jour successivement afin de déterminer le modèle reproduisant le plus fidèlement possible le comportement des données d’entrée. Ces dernières sont implantées dans le réseau sous la forme d’un
vecteur d’entrée x={x1, x2, …, xn}. La sortie du réseau
est un autre vecteur y={y1, y2, …, yk}. A la première
itération, la sortie yi de chaque neurone est alors
L'APPROCHE BASÉE SUR LES RÉSEAUX DE NEURONES
Un réseau de neurones permet de copier partiellement le
traitement de l’information effectué par des opérateurs
humains. Il est composé d’une série de neurones interconnectés et agissant de manière à résoudre une tâche
donnée [5]. La tâche à modéliser ici est le respect ou le
franchissement, par les utilisateurs d’une machine donnée, de barrières techniques prévues par les concepteurs
de celle-ci.
=
∑
= où le poids du neurone i est le vecteur
wi={wi1, wi2, …, win}. Avant d’entamer les itérations
195
suivantes pour le calcul de nouvelles sorties jusqu’à la fin
de la phase d’apprentissage, le réseau recherche le neurone i0 à partir d’une fonction de similarité prédéfinie :
− = − $
$% $& $& $& $'& $'& $'&(& $& $& $&$)
. Le réseau remet ensuite à
← jour les poids de ce neurone ainsi que ceux des neurones
voisins
en
appliquant
la
règle
suivante :
⎡
⎤
← + α ⎣ − ⎦ , étant une fonction de ré-
ajustement d’un poids à partir d’une distance donnée.
Dans l’étude de faisabilité de prédiction des franchissements de barrières, les vecteurs d’entrée contiennent une
série d’informations relatives aux franchissements de
barrières FB. Ces vecteurs sont notés xj(xj1, xj1, xj1, xj2,
xj2, xj2, …, xji, xji, xji, FBj). Dans la phase d’apprentissage, tous les paramètres d’un vecteur d’entrées sont
connectés à tous les neurones du réseau afin de déterminer celui qui a le vecteur de poids (wi1, wi2, wi3, …
win) le plus proche du vecteur d’entrée proposé, figure 3.
Les poids sont remis à jour afin de structurer le réseau de
neurone et d’accentuer les liens entre chaque neurone (cf.
figure 6).
← #
!
-
"
*
+ ,
Figure 7 : Algorithme de prédiction avec le réseau de
neurones.
L'APPROCHE RAISONNEMENT À PARTIR DE CAS
(RÀPC)
Le RÀPC trouve tout son intérêt quand on désire résoudre des problèmes issus d’un domaine pour lequel les
connaissances sont incomplètes et/ou non formalisées. Il
ne peut s’appliquer que pour des problèmes pour lesquels
des solutions à des problèmes similaires sont connus. Le
RÀPC constitue, par conséquent, un outil de capitalisation et d’apprentissage des connaissances.
Le RÀPC consiste à rechercher un cas similaire au problème parmi ceux déjà rencontrés et de réutiliser la solution et/ou le raisonnement employé dans le cas déjà enregistré (cf. figure 8). Bien évidemment le cas enregistré
est rarement identique au problème traité.
On distingue 2 types de RÀPC [6]:
• Le RÀPC de résolution a pour objectif de rechercher la solution d’un problème précis. Il
consiste à trouver un chemin, par une suite d’actions ou d’inférences, entre les données d’un
problème, et une ou plusieurs solutions.
• Le RÀPC d’interprétation permet l’interprétation d’une situation nouvelle par confrontation à
un ensemble de situations mémorisées. Il
consiste à évaluer des situations ou des solutions, et donc de comparer et contraster des cas
pour interpréter une situation.
Figure 6: Phase d’apprentissage du réseau de neurones.
Pour la phase d’apprentissage, le paramètre FBj est supprimé du vecteur d’entrée afin de le prédire à partir du
neurone gagnant déterminé en fonction des autres caractéristiques. La valeur qui lui est associée est alors de 1 si
le poids wi0n du neurone gagnant qui correspond au paramètre FBj dépasse 0,5, et de 0 sinon (i.e. pas de franchissement de barrière). Ce résultat est ensuite comparé avec
la valeur réelle observée afin de calculer un taux de prédiction correcte pour chaque itération, figure 7.
Les travaux présentés dans cet article s’inscrivent dans
l’interprétation de situation.
196
Dans de nombreuses situations, les étapes d’adaptations
et d’améliorations sont facultatives. Ainsi le RÀPC est
utilisé pour rechercher le cas connu le plus proche (au
sens de la similarité) du cas cible.
A la différence d'un réseau de neurones, le RÀPC est
opérationnel dès qu'un cas est enregistré dans la base de
cas.
RÉSULTATS DES PRÉDICTIONS DES DEUX APPROCHES
Nous avons comparé les capacités prédictives des deux
approches. Le but était de prédire le comportement (FB
ou non) d'un conducteur pour chaque situation.
Pour chaque approche un nombre minimal (N) de situations a constitué soit la base de cas, soit les données
d 'apprentissage. Puis, les situations suivantes ont été prédites. Nous avons fait varier N de 1 à 91 pour le RÀPC,
et de 10 à 91 pour le réseau de neurones. Pour chaque itération de N les prédictions ont été comparées avec les
comportements observés. Les taux de prédictions ont
donc été calculés pour chaque itération que ce soit pour
le réseau de neurones ou le RÀPC (Cf. figures 9 & 10).
Figure 8 : Les différentes étapes du cycle du RÀPC, d'après
Slade [7] et Haton [8] .
Un cas est un ensemble de conjonctions de descripteurs,
appelés également dimensions. Le problème lié à la représentation des cas consiste à déterminer les descripteurs utiles et nécessaires pour décrire une situation.
Dans le cas d’un RÀPC de résolution, la description du
cas comprendra tous les éléments ayant servi à sa résolution.
La détermination des descripteurs utiles aux étapes futures du raisonnement est une des phases les plus importantes pour le RÀPC. Ces descripteurs sont exprimés en
fonction des connaissances du domaine d’application.
Leur détermination nécessite donc une bonne compréhension du domaine et de la tâche à réaliser.
Les cas sont organisés dans une mémoire de cas appelée
base de cas. Les cas sont des expériences réelles qui se
présentent sous la forme :
Triplet<P,S,J> où :
•
•
•
Prédiction par le réseau de neurones
Figure 9 : Taux de prédiction du réseau de neurones en
fonction du nombre de situation pris en compte pour
l'apprentissage.
P est la description du problème
S est la solution du problème
J est la justification de la solution
La courbe d'apprentissage du réseau de neurones montre
combien la phase d'apprentissage reste une étape
conséquente. En effet les résultats sont fortement dispersés. Néanmoins, le taux de prédiction oscille entre 70 et
80% à partir de N=80.
Si cible est le problème actuel alors résoudre_cible revient à choisir un problème source auquel est associé une
solution sol(source), et à adapter cette solution pour produire sol(cible) [9].
L’appariement de cas [10] peut alors faire appel à :
• la recherche des correspondances entre descripteurs,
• le calcul du degré d’appariement des descripteurs,
• la pondération éventuelle des descripteurs dans
le cas.
La notion de similarité, au sens le plus large du terme, est
traitée dans de nombreux domaines tel que l’analyse de
données, la psychologie cognitive ainsi que l’intelligence
artificielle.
197
raction de ces barrières avec le conducteur doit être étudiée de manière approfondie. En effet, ces barrières ne
seront efficaces que si elles prédisent correctement
l'intention du conducteur et si leur déclenchement est toléré par celui-ci. Sinon, ces barrières seront franchies et
n'auront pas d'intérêt pour la sécurité.
REMERCIEMENTS
Les travaux présentés dans cet article s'inscrivent dans le
cadre du pôle ST2 (Sciences et technologies pour la
Sécurité dans les Transports), du thème 4 (Facteurs humains : défaillances et parades).
BIBLIOGRAPHIE
Figure 10 : Taux de prédiction du RÀPC, en fonction du
nombre de cas insérés dans la base de cas.
[1] POLET P. (2002). Modélisation des franchissements
de barrières pour l'analyse des risques des systèmes
homme-machine. Mémoire de Doctorat, Université de
Valenciennes et du Hainaut-Cambrésis, Valenciennes,
France, décembre.
Le RÀPC donne un taux de prédiction supérieur à 90% à
partir de N=15 (le taux de prédiction moyen 91%). Le
RÀPC semble, dans, cette étude moins sensible à la variation des cas dans la base (ajout de nouveau cas).
Le raisonnement à partir de cas permet d'obtenir rapidement (peu de cas dans la base) des taux de prédiction très
satisfaisants.
[2] Hollnagel, E. 1999. Accident and barriers. 7th
European Conference on Cognitive Science Approaches
to Process Control, pp175-180, Villeneuve d’Ascq,
France.
CONCLUSION ET PERSPECTIVES
[3] J. Reason, (1990) Human error, Cambridge University Press, Cambridge, 1990.
Cette étude comparative a démontré expérimentalement
que la prédiction du comportement dévié des opérateurs
humains, correspondant à des violations, était possible.
Cette prédiction réalisée dans le cadre de la conduite automobile ne s'est basée que sur des données objectives.
[4] Polet, P., Vanderhaegen, F., Wieringa, P. Theory of
safety related violation of system barriers. Cognition
Technology & Work, 4, 171-179. 2002.
[5] T. Kohonen, 2001. « Self-Organizing Maps », Third
Edition, Springer : New York, 2001.
Deux approches ont été proposées : l'une basée sur les réseaux de neurones, l'autre sur le raisonnement à partir de
cas. La comparaison de ces deux approches montre que
le RÀPC est plus appropriée dans les situations où le retour d'expérience est faible.
[6] Bichindaritz (1994), Apprentissage de concepts dans
une mémoire Dynamique : Raisonnement A Partir de cas
adaptable a la tache cognitive, thèse de doctorat, Paris V.
D'autre études devront être menées pour l'étude de situations différentes : respect de STOP, respect de ligne
continue... Par ailleurs, les deux approches devraient être
comparées avec un retour d'expérience plus important,
afin de confirmer ou infirmer la comparaison préliminaire présentée dans cet article.
[7] Slade S., Case-Based Reasoning: a research
paradigm. AI Magazine, 12 (1), pp42-55, 1991
[8] Haton J-P, (1991), Le raisonnement en intelligence
artificielle : Modèles, techniques et architectures pour
les systèmes à base de connaissances, InterEditions, Paris, 1991.
Par ailleurs, des données concernant le profil de conducteur devraient être intégrées. En effet, certains facteurs
tels que l'age, le sexe, le kilométrage annuel semblent,
selon certains auteurs ([12], [13], [14], [15]), favoriser
l'apparition de violations en conduite automobile.
[9] Mille A. et Napoli A. (1997), Aspect du raisonnement à partir de cas in PRC-GDR IA’97,
Hermes,1997.
[10] Rougerez-Loriette S. (1994), Prédiction de processus à partir de comportements passés : le système REBECAS. Thèse de doctorat de l’université de Paris VI
1994.
Les travaux présentés dans ce papier nous permettent
d'envisager l'élaboration de systèmes embarqués afin d'améliorer la sécurité du conducteur. Ces systèmes embarqués formeraient un second niveau de barrières. L'inte-
198
drivers, Accident Analysis and Prevention 35 (2003)
903–912.
[11] Vaughan, D. 1996 The challenger launch decision:
risky technology, culture, and deviance at NASA, University of Chicago press.
[15] Cheng-qiu Xie, Dianne Parker, A social psychological approach to driving violations in two Chinese cities, Transportation Research Part F 5 (2002) 293–308
[12] Per-Arne Rimmö, Lars Åberg,. On the distinction
between violations and errors: sensation seeking associations., Transportation Research Part F 2 (1999) 151166, 1999.
[16] Alain VERNET. Comportements, personnalité, conduite des v6hicules automobiles, Recherche - Transports
- Sécurité, Volume 72, July-September 2001, Pages 5670.
[13] Jerry L. Deffenbacher ,David M. Deffenbacher, Rebekah S. Lynch, Tracy L. Richards. Anger, aggression,
and risky behavior: a comparison of high and low anger
drivers, Behaviour Research and Therapy 41 (2003)
701–718.
[14] Michael A. Gebers , Raymond C. Peck. Using
traffic conviction correlates to identify high accident-risk
[17] Villemeur A., Sûreté de fonctionnement des sytèmes
industriels, Collection de la direction des études et
recherches d’EDF, Eyrolles, 1988.
199
La programmation sur exemple : principes, utilisation
et utilité pour les applications interactives
Loé SANOU – Patrick GIRARD – Laurent GUITTET
Laboratoire dInformatique Scientifique et Industrielle (LISI / ENSMA)
Téléport 2 -1, avenue Clément Ader BP 40109
86961 Futuroscope, France
[sanou, girard, guittet]@ensma.fr
On peut pourtant considérer que la recherche de solutions à ce problème, dans les années 1980, constitue le
point de départ des travaux sur le « End-User programming ». Ainsi, la première réponse a consisté à permettre
à l’utilisateur d’adapter son application à ses besoins
propres, au moyen de choix prédéfinis, les
« Préférences », présentes aujourd’hui dans la majorité
des logiciels. Tout naturellement, l’étape suivante a
consisté en la possibilité d’adapter l’interface, par exemple en modifiant les items de menus mis à disposition de
l’utilisateur.
On
appelle
cette
technique
la
« personnalisation ». Des solutions adaptatives ont ensuite été utilisées avec plus ou moins de bonheur. Les
menus « adaptatifs » de certaines versions de MS-Word©
ont ainsi été proposés, puis éliminés.
RESUME
La programmation sur exemple, issue du besoin
d’adaptation des applications interactives aux activités
de l’utilisateur, recouvre toute une série de techniques,
allant de l’enregistrement-rejeu à l’inférence de règles à
partir des interactions de l’utilisateur. Dans ce travail,
nous analysons les principes qui sous-tendent la programmation sur exemple, et montrons que, à travers une
utilisation de plus en plus large, elle constitue une solution pertinente pour certaines classes de problèmes où
elle était jusqu’à présent peu utilisée.
MOTS CLES : Programmation sur exemple, Adaptabilité,
Adaptativité, Assistance, Tests dinterfaces.
ABSTRACT
Programming by Demonstration, which comes from the
need to adapt interactive applications to users’ activities,
stands for some techniques, starting from recording/replaying to rule inference from user interactions. In
this work, we analyse the underlying principles of Programming by Demonstration. Then, we demonstrate
how, through an increasing usage, it constitutes a pertinent solution for some problem classes, where it has not
been largely used yet.
Toutes
ces
techniques
présentent
néanmoins
l’inconvénient de manquer singulièrement de puissance
d’expression. On ne peut en effet ni créer une nouvelle
commande par assemblage de commandes existantes, ni
même automatiser des enchaînements de commandes.
Afin d’augmenter les possibilités d’adaptation, il était
tentant de revenir aux principes simples et universels de
la programmation. Des langages de scripts ont ainsi été
conçus, permettant d’obtenir le degré de puissance souhaité. Malheureusement, cette technique, qui nécessite la
maîtrise des principes de la programmation, s’avère inutilisable pour l’utilisateur « commun », le « end-user »
des anglo-saxons. Des techniques d’enregistrement de
macros ont alors vu le jour, tout particulièrement dans le
domaine des systèmes iconiques [16, 17]. La programmation devenait accessible au « end-user ».
KEYWORDS : Programming by demonstration, examplebased programming, Adaptable, Adaptative, Assistance,
User Interface Testing
INTRODUCTION
Depuis l’avènement des interfaces graphiques, les logiciels ont globalement évolué vers une augmentation des
fonctionnalités. Les logiciels de bureautique, comme
MS-Word© ou MS-Excel©, qui contiennent aujourd’hui
plusieurs centaines de fonctions, en sont la parfaite illustration, au point que la majorité des utilisateurs ne
connaissent pas, et donc n’utilisent pas, la plus grande
part de leurs fonctions. Cette course en avant sur les
fonctionnalités aboutit à imposer à l’utilisateur des interfaces de plus en plus lourdes, où les menus s’allongent,
et où le nombre d’interactions purement articulatoires
augmente de façon déraisonnable. L’émergence des
techniques post-WIMP a engendré très récemment une
salutaire remise en cause de cette tendance [2].
L’utilisation accrue de l’image a conduit à jeter les bases
de la programmation dite visuelle (« Visual Programming »[12]). Cette dernière s’appuie sur le fait établi
que, dans la majorité des cas, la symbolique de l’image
apporte une information beaucoup plus importante
qu’une simple représentation textuelle. Dans le domaine
de la programmation, de nombreux systèmes ont ainsi
été développés. Cependant, une compréhension des principes de la programmation est là encore nécessaire. Audelà de la simple utilisation de l’image, c’est sur celle de
l’exemple que se sont concentrés les travaux. L’idée générale est que tout raisonnement autour de l’exemple est
201
plus intuitif qu’un raisonnement abstrait. C’est ainsi
qu’ont vu le jour les systèmes « avec exemple » (Programming with example), qui permettent l’exécution
immédiate de l’exemple en cours de construction, et surtout les systèmes « sur exemple » (Programming by
Example ou Programming by Demonstration, que nous
appellerons PsE par la suite) [10].
Naissance dun concept
Pygmalion [6] est considéré comme l’un des tous premiers systèmes relevant de la PsE. Son objectif est de
permettre la construction d’un programme en s’appuyant
sur un exemple. L’environnement du système, semi graphique, est basé sur la métaphore du « tableau noir » : la
zone de travail est vue comme un tableau où le programmeur peut « dessiner » ses idées. La figure 2
présente l’environnement Pygmalion lors de la réalisation d’un exemple : la fonction « factorielle ».
Pygmalion est à l’origine du concept d’icône disposant à
la fois d’une image, d’un contenu (du texte pour une
icône du document), et d’un comportement (déplacement
d’une icône par « Drag and Drop »). Pygmalion fournit
un menu permettant d’accéder aux icônes et aux opérateurs portant sur ces icônes. Lorsque Pygmalion est en
mode
enregistrement,
une
zone
d’historique
(« remembered ») affiche les deux dernières actions exécutées. Le système dispose aussi d’une zone où le
programmeur peut taper et évaluer des expressions écrites en Smalltalk.
La figure 1 ci-dessous représente une illustration des différentes approches exposées précédemment, selon l’axe
de l’engagement par rapport à l’exemple, et de la puissance d’expression de ces solutions.
Figure 1 : Illustration des différentes approches
Au-delà de cette trame historique, la programmation sur
exemple (PsE) a été expérimentée dans des domaines
très variés. Elle apparaît par exemple dans des applications grand public, comme MS-Excel© par exemple.
Certains champs d’application ont exploité ses fondements avec beaucoup de réussite, comme la conception
technique [11]. Enfin, la « End-User Programming » apparaît dans de nombreuses conférences et workshops.
Le présent papier a pour but de présenter une synthèse
des principes, de l’utilisation et de l’utilité des systèmes
de programmation sur exemple, qui nous conduira à explorer de nouvelles pistes où sa généralisation nous
semble souhaitable. Notre exposé sera découpé en trois
points. Dans un premier temps, nous décrivons quelques
systèmes de PsE afin d’illustrer de façon concrète notre
propos. Dans une deuxième partie, nous analysons les
principes sous-jacents. Enfin, nous proposons des axes
où il nous semble que la généralisation de son utilisation
apporte des solutions originales et efficaces.
Figure 2 : Pygmalion : Réalisation de la fonction
« factorielle ».
Pygmalion fournit des représentations graphiques standard d’opérateurs arithmétiques et booléens. Pour
réaliser la fonction « factorielle » par exemple, on commence par allouer une icône. Ensuite l’utilisateur lui
associe deux sous icônes pour représenter l’argument et
la valeur de la fonction, et il dessine un symbole pour la
représenter (figure 2). On rend la bordure invisible et on
associe un nom avec l’icône par une commande « define ». Le système effectue alors une capture
d’écran : la zone de travail sera restaurée dans cet état
chaque fois que la fonction sera appelée. L’appel de la
fonction « define » fait basculer le système en mode enregistrement. On peut alors spécifier le comportement de
la fonction, à l’aide d’un exemple.
QUELQUES EXEMPLES
Les systèmes de PsE couvrent une grande variété
d’applications. Nous décrivons ici quelques systèmes représentatifs des différentes notions que nous détaillerons
dans la section suivante.
202
Des macros iconiques
Le domaine de la conception technique
Le domaine des macros est, comme nous l’avons dit en
introduction, un domaine privilégié de la programmation
par l’utilisateur final. Des systèmes plus ou moins graphiques et interactifs ont été développés, et des révisions
modernes sont proposées, comme Automator dans le
système Mac OS X, permettant d’automatiser des tâches
répétitives comme le renommage de fichiers. SmallStar
[16] est une des premières tentatives pour adapter une
technique graphique de PsE à cette problématique.
SmallStar est une simulation de l’interface graphique du
système d’exploitation Star de Xerox [28] à laquelle des
capacités de PsE ont été rajoutées. C’est le premier système de PsE destiné au grand public (i.e. des utilisateurs
n’ayant pas de connaissance préalable de la programmation) dans le but d’automatiser les tâches répétitives
souvent rencontrées lorsqu’ils utilisent Star.
Le domaine de la conception technique (incluant en particulier la CAO, conception assistée par ordinateur) a
pleinement assimilé les techniques de la PsE, au point
qu’aujourd’hui, les systèmes dits paramétriques, les plus
utilisés au plan industriel, fondent leur modélisation sur
des principes de PsE.
Example Based Programming [25], (EBP) est un exemple d’environnement de développement de programmes
paramétrés, susceptibles de générer des comportements
standard. Il permet en particulier de mettre au point par
manipulation directe et visuelle les programmes générés.
EBP utilise des techniques de programmation sur exemple permettant la création de familles de composants
standard portables par des utilisateurs de systèmes de
conception assistée par ordinateur.
Figure 4: Environnement EBP.
Le système EBP manipule des entités géométriques simples (points, droites infinies, segments, cercles, arcs,
etc.) et des entités structurées (courbes, surfaces planes
et ensembles structurés). La plupart des contraintes résultant des règles de dessin technique sont supportées.
EBP permet de spécifier interactivement, de façon graphique un programme contenant des structures de
contrôle usuelles et offre la possibilité de générer du
code. La programmation sur exemple est réalisée dans
EBP via un mode enregistrement des appels de fonctions
du système. Les programmes au sein d’EBP (où ils sont
nommés « instances ») sont séparés des exemples. EBP
espionne l’utilisateur et construit une instance après
l’activation du mode enregistrement. Le passage en
mode utilisation permet à l’utilisateur d’exploiter cette
instance. Lors de l’exécution de l’instance en mode enregistrement, la définition de la valeur du paramètre
effectif est constituée d’une expression quelconque mettant en jeu des entités ou des paramètres du programme
appelant. EBP comporte des structures de contrôle complètes. Les sous-programmes, les alternatives et les
répétitions sont totalement disponibles.
Figure 3: Bureau SmallStar.
Star utilise la métaphore du bureau avec les icônes représentant les différents objets du système (programmes,
imprimantes, documents, formulaires, boîtes aux lettres,
tableaux, etc.). Dans SmallStar, pour créer un programme, l’utilisateur commence par ouvrir une icône
programme puis presse le bouton « Start Recording »
pour démarrer l’enregistrement. Il effectue ensuite les
étapes nécessaires puis presse le bouton « Stop Recording » pour arrêter l’enregistrement. Une fois la phase
d’enregistrement du programme terminée, l’utilisateur
doit effectuer les généralisations nécessaires. Pour chaque type d’objet présent dans le système, y compris les
commandes enregistrées, SmallStar propose un ensemble
de descripteurs de données présenté à l’utilisateur dans
une boîte de dialogue. L’utilisateur spécifie explicitement, au moyen d’interfaces textuelles dirigées, les
structures de contrôle et les descripteurs de données. Une
commande sous SmallStar possède un nom et un ensemble d’arguments ; elle peut impliquer plusieurs actions de
la part de l’utilisateur.
203
Eager fait partie des systèmes qui cherchent à déduire
des actions de l’utilisateur ses intentions, pour lui proposer son aide lorsque certains patterns d’interaction,
comme une répétition, sont reconnus. De nombreux systèmes ont suivi cette voie, permettant dans certains cas
de créer de nouvelles règles à partir des exemples.
Enseignement, éducation, simulation
Fournir une assistance, par l’exemple, à la compréhension des mécanismes de programmation est un thème
important dans les systèmes de PsE.
Un environnement d’initiation à la programmation et basé sur l’exemple est MELBA [13] (Metaphors-based
Environment to Learn the Basics of Algorithmic). C’est
un système d’apprentissage composé de trois zones :
l’espace du programme qui permet de représenter et
d’éditer celui-ci, une zone sémantique (représentant
l’exécutant) et une zone pragmatique (représentant graphiquement le sujet du programme). Chaque zone est
interactive et la cohérence de l’ensemble est assurée par
des mécanismes de programmation sur ou avec exemple.
MELBA est un environnement très souple, qui ne préjuge pas de la méthode utilisée pour appréhender les
principes de la programmation. Ainsi, l’utilisateur peut-il
partir de son savoir-faire sur la tâche et induire un programme avec l’aide du mécanisme de programmation
sur exemple ou au contaire chercher à comprendre un
programme grâce à l’animation de la zone de la tâche
[15].
Figure 6: Anticipation de commande dans le menu Eager.
Après ces quelques exemples, nous analysons, dans la
section suivante, les principes qui fondent la PsE.
PRINCIPES DES SYSTEMES DE PSE
La différence essentielle entre la programmation avec
exemple et la programmation sur exemple réside dans le
fait que cette dernière s’appuie sur une manipulation
concrète de l’exemple. De fait, la technique de base
consiste à implanter dans un système interactif un système d’enregistrement-rejeu, cher aux systèmes de
macros sur exemple [19, 23].
Lenregistrement-rejeu
Dans l’utilisation de la PsE, il convient de distinguer
deux modes qui s’ajoutent ou se superposent à
l’utilisation interactive classique du système. Le premier
mode est le mode « enregistrement », pendant lequel le
système enregistre les actions de l’utilisateur pour construire une trace. Cet enregistrement peut être explicite,
comme dans les systèmes de macro, ou implicite comme
dans Eager [4]. Dans le premier cas, l’application dispose d’un outil de type « panneau de contrôle de système
enregistreur », avec les fonctions « RECORD »,
« PLAY », « STOP », ou encore « PAUSE » (figure 7).
Figure 5: Environnement MELBA
après chargement des données d’un exercice.
Assistance à lutilisateur
Eager [5] est un système emblématique de la PsE. Il
permet d’automatiser les tâches répétitives, comme par
exemple constituer automatiquement une liste numérotée
de titres de documents. Il prend en compte le fait que
l’utilisateur ne réalise pas toujours immédiatement qu’il
peut créer un programme pour accomplir la tâche qui
l’intéresse. Eager observe en permanence le comportement de l’utilisateur pour essayer de prédire ses
prochaines commandes. Il anticipe la commande suivante de l’utilisateur sans l’exécuter lorsqu’il détecte une
boucle. Pour cela, il propose à l’utilisateur la prochaine
action à effectuer, à charge pour lui de le confirmer. La
figure 6 illustre l’étape où Eager (le petit chat) propose la
prochaine action à l’utilisateur. Si celui-ci confirme
l’inférence d’Eager, ce dernier est en mesure de terminer
automatiquement la tâche.
Figure 7 : Un panneau de contrôle d’enregistrement-rejeu, ici
dans l’application Jacareto 1
Ce principe est poussé à son paroxysme dans les systèmes dits paramétriques, qui modélisent leurs données
1
204
http://jacareto.sourceforge.net/
Grammex [21] et StageCast Creator [3] sont deux autres exemples de ce niveau d’enregistrement.
5. Le dernier niveau concerne le niveau pragmatique.
Ici, on ne considère que les actions du système qui
ont un rôle dans la résolution du but final de
l’utilisateur. Les actions articulatoires, ainsi que les
opérations non constructives ne sont pas enregistrées.
Les systèmes paramétriques en conception technique
en sont la parfaite illustration. Comme il est expliqué
dans [31], ce sont les données mêmes de l’application
qui enregistrent leur historique de construction, ce
qui permet de les rejouer après d’éventuelles modifications de paramètres.
comme un historique d’actions constructives, enregistré
au cours de la construction interactive de l’objet.
Le niveau d’enregistrement peut être très différent selon
les systèmes. Les travaux menés sur les systèmes de
conception technique [9, 11, 26, 31] ont permis de caractériser cinq niveaux d’enregistrement-rejeu.
1. Le premier niveau correspond à l’enregistrement des
actions les plus élémentaires de l’utilisateur. Les
premiers systèmes d’enregistrement de macro fonctionnaient selon ce principe, avec comme corollaire
que la situation initiale jouait un rôle prépondérant
sur le bon déroulement de la phase de rejeu : les positions graphiques étant enregistrées en absolu, toute
différence dans la configuration initiale de l’écran
aboutissait à une exécution erronée de la macro.
Dans Jacareto, l’enregistrement se passe au niveau de
la boîte à outils d’interaction, Swing en l’occurrence ;
ce sont ainsi les événements de bas-niveau (MouseEvent, MouseMoveEvent, KeyEvent) qui sont
enregistrés et rejoués, permettant un rejeu à
l’identique de toutes les actions de l’utilisateur.
2. Le deuxième niveau concerne l’aspect lexical de
l’interaction. Les éléments sont enregistrés au niveau
de l’action élémentaire, du point de vue de
l’utilisateur, et non plus de la boîte à outils. Eager [4]
en est la parfaite illustration. Les actions telles que le
changement de focus sur une application, ou la sélection d’un item de menu, sont ainsi rejouées pour
permettre à l’utilisateur de confirmer les propositions
du système.
3. Le troisième niveau correspond à l’aspect syntaxique
de l’interaction. Le système Like [9] en est un bon
exemple. Dans ce système de conception technique,
le dialogue entre l’utilisateur et le système est décrit
par le moyen d’automates évolués (des Augmented
Transition Networks, ou ATN [32]), manipulant des
jetons de dialogue (commandes, paramètres).
L’enregistrement de ces jetons constitue la base de
l’enregistrement au niveau syntaxique. Nous verrons
que ce niveau d’enregistrement présente un intérêt
certain pour l’interprétation des actions de
l’utilisateur. Notons que, lorsque le style de dialogue
est la manipulation directe, comme c’est le cas par
exemple pour Peridot [22], il est très difficile de
distinguer le niveau lexical du niveau syntaxique :
chaque interaction élémentaire est à la fois un élément lexical et un élément syntaxique, puisque la
réaction du système est supposée continue.
4. Le quatrième niveau est tout naturellement le niveau
sémantique, en référence à la théorie de la compilation. Il s’agit là d’enregistrer la fonction du système
invoquée par l’utilisateur, pour être à même de la rejouer directement en phase d’exécution. Dans les
systèmes de conception technique, cette approche est
représentée par EBP [25], dont le but premier
consiste à créer de véritables programmes paramétrés, échangeables d’un système de CAO à un autre.
Le choix du niveau de l’enregistrement est très important
en fonction du but recherché par l’utilisation de la PsE.
En effet, plus l’enregistrement s’effectue à un niveau
élémentaire dans le dialogue entre l’utilisateur et
l’application, et plus il sera dépendant des changements
intervenant dans l’interface de l’application. Si l’objectif
de la PsE consiste à construire des programmes réutilisables (comme des programmes paramétrés en conception
technique, par exemple), tout changement dans
l’interface invalidera ces programmes si l’enregistrement
se fait à un niveau inférieur au niveau sémantique.
La généralisation
Le simple enregistrement-rejeu ne permet pas de faire
autre chose que de la répétition à l’identique d’une séquence, qu’elle se situe au niveau de l’interaction ou du
système lui-même. Ce qui distingue une simple trace
d’exécution d’un vrai programme relève de la généralisation.
Le premier niveau de généralisation consiste à considérer les objets manipulés. En effet, un programme est
censé pouvoir s’exécuter sur des « variables », c’est-àdire avec des valeurs différentes d’une exécution à
l’autre. Lorsque l’on travaille sur un exemple, on dispose
de valeurs concrètes ; la généralisation consiste à distinguer les valeurs qui vont changer d’une exécution à
l’autre de celles qui demeureront constantes. SmallStar
[16, 17] est le premier système à se focaliser sur les caractéristiques des objets manipulés par les systèmes de
PsE. Il définit une notion de descripteur, qui permet de
transformer la référence à un objet unique en une définition sémantique. La notion de variable, bien connue en
programmation classique, est évidemment définie. Elle
est étendue par des notions plus spécifiques, comme par
exemple la notion de collection : une variable peut être
généralisée de manière à répondre à une définition générique, ce qui entraîne implicitement une itération de
collection. Le système appartient à la catégorie des systèmes iconiques, et la généralisation se traduit par
exemple par l’utilisation de joker, comme « *.txt » pour
représenter des noms comportant obligatoirement un suffixe particulier. Notons que, dans la majorité des cas, la
sémantique de la variable n’a pas besoin d’être connue
205
approches, quoique séduisantes, se trouvent le plus souvent limitées par leur pouvoir d’expression : elles sont
spécifiques du domaine d’application, et peuvent difficilement être généralisées. Elles se heurtent à un deuxième
obstacle : lorsque l’on construit de nouvelles règles, il est
difficile d’être sûr qu’elles s’appliqueront sans erreur
dans tous les cas de figure.
par le système d’espionnage, qui se contente d’être capable de référencer l’objet pendant la phase de rejeu.
Ceci n’est plus vrai dès lors que l’on ajoute des structures de contrôle au programme.
La deuxième phase de généralisation consiste à ajouter
une sémantique de contrôle au programme. Très naturellement, les techniques peuvent relever d’approches
différentes. Lorsque l’on s’appuie sur une sémantique de
programmation structurée, il convient d’ajouter ou de repérer des alternatives et des répétitions. C’est le cas de
SmallStar, par exemple. Les approches fonctionnelles
(Pygmalion [29]) ou logiques (StageCast Creator [3]) ont
également été explorées. Dans tous les cas, afin de
contrôler les structures utilisées, il devient nécessaire de
définir parmi les objets une sémantique booléenne. En
effet, lors du rejeu, c’est une valeur booléenne qui permettra de choisir quelle alternative exécuter, ou qui
dirigera la règle à appliquer. Des expressions booléennes
plus complexes pourront s’avérer nécessaires (EBP
[25]). Enfin, pour permettre à l’utilisateur de comprendre
plus facilement cette sémantique, des expressions numériques seront également introduites.
DES CHAMPS DAPPLICATION EN EXPANSION
La PsE a donné lieu à de nombreux systèmes. Le reproche que l’on peut faire à ces travaux est le manque
d’évaluations conduites à leur propos. En dehors de
MELBA, pour lequel plusieurs expérimentations ont été
réalisées, aucune démarche formelle d’évaluation n’a été
engagée. On peut considérer néanmoins que la commercialisation de systèmes relevant de la PsE constitue une
forme d’évaluation. La plus grande réussite est certainement celle des systèmes de conception technique dits
paramétriques, qui constituent aujourd’hui la majorité
des systèmes de cette catégorie. Un autre domaine notable est celui de la simulation, où des logiciels comme
StageCast Creator 2 ou AgentSheets3 ont été commercialisés.
Trois domaines se dégagent comme particulièrement
pertinents du point de vue de la PsE.
Inférence, règles
La mise en œuvre de la généralisation peut s’effectuer de
manières très diverses. Nombreux sont les systèmes qui
demandent explicitement à l’utilisateur de faire cette généralisation. SmallStar oblige l’édition du programme
enregistré, pour effectuer manuellement la généralisation
des objets, et impose l’introduction textuelle des structures de contrôle. Le caractère sur exemple devient moins
marqué. D’autres systèmes (Pygmalion, EBP, StageCast
Creator) exigent que les structures de contrôle soient
prévues par le programmeur, et introduites par des commandes spécifiques.
Fonction dassistance
Il s’agit ici d’un retour aux sources. La possibilité de
personnaliser son application est un besoin considéré
comme majeur par les utilisateurs. De nombreux éditeurs
de logiciels ont ainsi développé des solutions s’appuyant
peu ou prou sur les techniques de la PsE pour enrichir les
possibilités d’adaptation. Les techniques de généralisation a priori sont utilisées dans l’outil Automator 4 qui
permet d’automatiser des tâches dans Mac OS X. Les
techniques d’inférence et d’espionnage trouvent leur utilité dans des agents d’aide, ou autres assistants. Dans
MS-Excel©, par exemple, un espionnage systématique de
l’utilisateur permet de détecter les situations
s’apparentant à une gestion de liste (Figure 8), comme le
fait Eager.
Pour éviter ce côté explicite, analysé comme contraire à
la logique de l’utilisateur non-programmeur, plusieurs
auteurs ont choisi de proposer des méthodes utilisant
l’exemple de façon plus marquée. Ainsi, PBE [1] se sertil de deux exécutions différentes pour déduire quelles
sont les variables et quelles sont les constantes. Eager [4]
demande à l’utilisateur de confirmer les actions qu’il a
détectées, et analyse les déviations pour construire le
programme correct.
Les techniques de la PsE, utilisées de façon ponctuelle
dans certaines situations d’interaction, sont de nature à
apporter de nouvelles fonctions d’assistance à
l’utilisateur. Selon les besoins, des techniques explicites
de généralisation seront préférables à l’utilisation de
l’inférence, principalement lorsqu’on souhaitera que
l’utilisateur puisse contrôler finement son automatisation. Elles sont la base de l’adaptabilité des applications.
L’usage de l’inférence permet en plus d’atteindre des objectifs d’adaptativité.
Allant plus loin sur la voie de l’inférence, c’est-à-dire
l’induction de faits nouveaux à partir de faits connus, de
nombreux auteurs ont couplé des moteurs d’inférence
aux systèmes de PsE. Eager [4] ou Mondrian [20] reconnaissent ainsi des situations complexes. Des résultats
probants ont ainsi été obtenus dans le domaine de la simulation. La définition de nouvelles règles par
l’utilisateur est considérée comme l’étape suivante :
Grammex [21] permet ainsi de définir explicitement, sur
exemple, de nouvelles règles qui s’appliqueront ensuite
comme des règles pré-existantes dans le système. Ces
2
http://www.stagecast.com/
http://www.agentsheets.com/
4
http://www.apple.com/fr/macosx/features/automator/
3
206
d’émules10, et que leurs outils sont de plus en plus largement utilisés, tester les interfaces s’avère encore un
processus difficile. Les techniques d’analyse de code ont
largement montré leurs limites, et la validation par les
modèles n’est pas encore opérationnelle au niveau industriel. Aujourd’hui, ce sont les approches intégrant la PsE
qui semblent émerger. Ainsi, Jacareto 11 permet-il
d’enregistrer les interactions de bas-niveau et autorise-til l’automatisation de tests d’interface. Pour rendre ces
outils plus puissants, un couplage avec les approches à
base d’analyse de tâches, comme dans [8], s’avère très
efficace.
CONCLUSION
La programmation sur exemple recouvre une série de
techniques, allant de l’enregistrement-rejeu à l’inférence
de règles à partir des actions de l’utilisateur. La constante de ces techniques est l’utilisation intensive d’un
exemple tiré de l’action de l’utilisateur sur un système
interactif.
Figure 8 : L’exemple d’utilisation de la PsE dans MS-Excel©
Pédagogie
Les applications pédagogiques et de simulation constituent un champ d’investigation important pour la PsE.
Les objectifs des systèmes qui l’utilisent sont très variés.
Ils peuvent concerner l’apprentissage de la programmation (MELBA [14], Toontalk 5[18] ), ou plus
généralement de la stratégie de résolution de problème
(StageCast Creator [30], Agentsheets [27]). L’effort
principal se porte dans ces systèmes sur l’aide à
l’explicitation des principes de généralisation. De ce fait,
un effort tout particulier est porté sur la visualisation des
programmes, qui cherche à être la plus explicite possible.
Les avancées dans le domaine des nouvelles techniques
d’interaction trouvent également leur application dans la
PsE. Ainsi, l’application des techniques des interfaces
tangibles a donné lieu au Topobo6, qui permet à de jeunes enfants à étudier la dynamique des actions (et donc
la programmation) en s’appuyant sur la manipulation de
d’objets de construction qui mémorisent leurs actions et
les rejouent.
Les différentes facettes de la PsE ont été décrites et validées dans de nombreux systèmes expérimentaux. Alors
que la PsE véhicule une image de technique à la portée
limitée, on s’aperçoit qu’elle est de plus en plus souvent
utilisée dans les applications interactives. À partir d’une
présentation d’exemples significatifs, nous avons analysé
les principes qui sous-tendent la PsE. Nous avons pu ainsi définir cinq niveaux possibles dans l’enregistrement
des actions de l’utilisateur, qui s’appliquent à des problématiques différentes. Nous avons ensuite catégorisé
les diverses formes de généralisation des programmes.
Enfin, dans une dernière partie, nous avons exploré
quelques grands secteurs où la PsE apporte des résultats
significatifs, en terme d’augmentation des possibilités
des systèmes.
La généralisation des techniques de PsE passe, à notre
sens, par la définition d’outils permettant une implémentation généralisée de ces techniques. Cela est vrai au
niveau des techniques d’enregistrement, ou des approches internes (Aide [24]) comme externes (PbDScript
[7]) doivent être proposées. Cela est vrai également pour
les techniques de généralisation, qui doivent être abordées de façon générique. Les champs d’investigation
demeurent ici largement ouverts. Pour terminer, notons
que le point faible des travaux sur la PsE réside dans les
études d’utilisabilité, qui n’ont été que très rarement
conduites jusqu’à présent. Il y a là également de grandes
possibilités pour de futurs travaux.
Outils de conception et de validation
Le domaine des outils de conception est certainement celui où la PsE est intégrée le plus profondément aux
applications. Les outils graphiques modernes utilisent
abondamment l’analyse temps-réel des interactions pour
fournir une assistance au placement des composants (alignement, contraintes, etc.). On trouve ces fonctionnalités
dans des outils de dessin (OmniGraffle7), de présentation
(Keynote8) ou encore les GUI-Builders (Matisse9 dans
NetBeans).
L’utilisation des techniques d’enregistrement-rejeu
s’avère extrêmement prometteuse pour la vérification et
la validation des applications interactives. Alors que les
techniques de tests unitaires font de plus en plus
BIBLIOGRAPHIE
1. Bauer, M.A., Programming by Examples. Articial Intelligence, 1979. 12: pp. 1-21.
5
http://www.toontalk.com/
6
http://web.media.mit.edu/~hayes/topobo/
7
http://www.omnigroup.com/applications/omnigraffle/
8
http://www.apple.com/iwork/keynote/
9
http://www.netbeans.org/kb/articles/matisse.html
10
11
207
http://www.extremeprogramming.org/, http://www.junit.org/
http://jacareto.sourceforge.net/
17. Halbert, D., SmallStar : Programming by Demonstration in the Desktop Metaphor, in Watch What I Do :
Programming by Demonstration, A. Cypher, Editor.
1993, The MIT Press: Cambridge, Massachusuetts.
pp. 102-123.
18. Kahn, K., How Any Program Can Be Created by
Working with Examples, in Your Wish is My Command, H. Lieberman, Editor. 2001. pp. 21-44.
19. Kurlander, D. and Feiner, S. A History-Based Macro
by Example System. in ACM Symposium on User
Interface Software and Technology (UIST'92). 1992.
Monterey, California: ACM/SIGCHI, pp. 99-115.
20. Lieberman, H., Mondrian: a Teachable Editor, in
Watch What I Do: Programming by Demonstration,
A. Cypher, Editor. 1993, The MIT Press: Cambridge,
Massachusetts. pp. 341-360.
21. Lieberman, H., Nardi, B.A., and Wright, D. Grammex : Defining Grammar by Example. in Human
Factors in Computing Systems (CHI'98). 1998. Los
Angeles, California: ACM/SIGCHI, pp. 11-12.
22. Myers, B.A., PERIDOT: Creating User Interfaces by
Demonstration, in Watch What I Do: Programming
by Demonstration, A. Cypher, Editor. 1993, The MIT
Press: Cambridge, Massachusetts. pp. 125-154.
23. Olsen, D.R. and Dance, J.R., Macros by Example in a
Graphical UIMS. IEEE Computer Graphics and Applications, 1988. 12(1): pp. 68-78.
24. Piernot, P.P. and Yvon, M.P., The AIDE Project: An
Application-Independent Demonstrational Environment, in Watch What I Do: Programming by
Demonstration, A. Cypher, Editor. 1993, The MIT
Press: Cambridge, Massachusetts. pp. 383-402.
25. Potier, J.-C., Conception sur exemple, mise au point
et génération de programmes portables de géométrie
paramétrée dans le système EBP. Thèse: Université
de Poitiers. 140p.
26. Potier, J.-C., et al., Génération graphique interactive
de programmes de géométrie paramétrée. Revue
d'Automatique et de Productique Appliquée (RAPA),
1995. 8(2-3): pp. 229-234.
27. Repenning, A. and Perrone, C., Programming by
Analogous Examples, in Your Wish is My Command, H. Lieberman, Editor. 2001. pp. 351-370.
28. Smith, D., et al., Designing the Star User Interface.
Byte, 1982. 7(4): pp. 242-282.
29. Smith, D.C., A Computer Program to Model and
Stimulate Creative Thought. 1977, Basel: Birkhauser.
187p.
30. Smith, D.C., Cypher, A., and Tesler, L., Novice Programming Comes of Age, in Your Wish is My
Command, H. Lieberman, Editor. 2001. pp. 7-20.
31. Texier, G., Contribution à l'ingéniérie des systèmes
interactifs : Un environnement de conception graphique d'applications spécialisées de conception. Thèse:
Université de Poitiers. 230p.
32. Woods, W., Transition Network Grammars for Natural Language Analysis. Communications of the
ACM, 1970. 13(10): pp. 591-606.
2. Beaudouin-Lafon, M. Designing interaction, not interfaces. in Advanced Visual Interfaces. 2004.
Gallipoly, Italie, pp. 15-22.
3. Canfield Smith, D., Cypher, A., and Tesler, L., Novice Programming Comes of Age, in Your Wish is
My Command, H. Lieberman, Editor. 2001. pp. 7-20.
4. Cypher, A. Eager: Programming Repetitive Tasks by
Example. in Human Factors in Computing Systems
(CHI'91).
1991.
New
Orleans,
Louisiana:
ACM/SIGCHI, pp. 33-39.
5. Cypher, A., Eager : Programming Repetitive Tasks
by Demonstration, in Watch What I Do: Programming by Demonstration, A. Cypher, Editor. 1993,
The MIT Press: Cambridge, Massachusetts. pp. 205217.
6. Cypher, A., ed. Watch What I Do: Programming by
Demonstration. 1993, The MIT Press: Cambridge,
Massachusetts. 604p.
7. Depaulis, F., Guittet, L., and Martin, C. Apprends ce
que je fais. in 15ème Conférence Francophone sur
l'Interaction Homme-Machine. 2003. Caen: ACM
Press, pp. 236-239.
8. Fabio Paternò, C.S., Preventing user errors by systematic analysis of deviations from the system task
model. International Journal of Human-Computer
Studies, 2002. 56(2): pp. 225-245.
9. Girard, P., Environnement de Programmation pour
Non-Programmeur et Paramétrage en Conception
Assistée par Ordinateur : le système LIKE. Thèse:
Université de Poitiers. 195p.
10. Girard, P., Ingénierie des systèmes interactifs : vers
des méthodes formelles intégrant l'utilisateur. HDR:
Université de Poitiers. 92p.
11. Girard, P., Bringing Programming by Demonstration
to CAD Users (Chapter 7), in Your wish is my command, H. Lieberman, Editor. 2001, Morgan
Kaufmann. pp. 135-162.
12. Glinert, E.P., ed. Visual programming environments:
paradigms and systems. Vol. 1. 1990, IEEE Computer Society Press: Los Alamitos, California. 660p.
13. Guibert, N. and Girard, P. Programmation sur Exemple et Enseignement assisté par ordinateur de
l’algorithmique : le projet MELBA. in 15° Conférence Francophone sur l'Interaction Homme-Machine
(IHM'2003). 2003. Caen: ACM Press, pp. 248-251.
14. Guibert, N., Girard, P., and Guittet, L. Examplebased Programming: a pertinent visual approach for
learning to program. in Advanced Visual Interfaces.
2004. Gallipoli, Italy: acm press, pp. 358-361.
15. Guibert, N., Guittet, L., and Girard, P. Apprendre la
programmation par l’exemple : méthode et système.
in Technologies de l'Information et de la Connaissance dans l'Enseignement Supérieur et l'Industrie
(TICE). 2004. UTC Compiègnes- France.
16. Halbert, D., Programming by Example. PhD Thesis:
University of California. 121p.
208
ARTICLES LONGS APPLIQUES
*******
Vigiestrips une IHM innovante intégrée au système
Aéroport Avancé
Joël GARRON
Jérôme JOURNET
Bertin Technologies (1)
10 bis, avenue Ampère – Montigny le Bretonneux
78053 St Quentin en Yvelines
Direction des Services de la Navigation Aérienne (2)
Zone aéroportuaire - Route périphérique Bât 1608
91200 Athis-Mons
[email protected]
[email protected]
RESUME
KEYWORDS : ATC, Airport, paper strips, complex
system, Vigiestrips, performance factor.
Cet article fait le point sur un projet de remplacement
des strips papier dans les tours de contrôle de l’aéroport
de Roissy Charles De Gaulle (CDG). Il montre dans une
première partie à quel point le fonctionnement de cette
plate-forme aéroportuaire s’apparente à un système complexe. Dans une deuxième partie consacrée aux strips
papier, les auteurs exposent tout d’abord les qualités
opérationnelles de ce support vis à vis de l’activité des
contrôleurs SOL et LOC de CDG. Puis, ils mettent en
exergue les limites réelles de ce même support en regard
du fonctionnement d’un système qui va en se complexifiant. Dans une troisième partie, l’article présente le
concept Vigiestrips et les deux axes autour desquels il
s’articule (services rendus au contrôleur utilisant l’outil
Vigiestrips et mise en réseau des données entre le
contrôleur et les autres acteurs du système). Les auteurs
présentent ensuite les valeurs ajoutées de ce concept
dans le contexte d’un système « Aéroport Avancé », notamment dans la perspective d’en satisfaire les deux
principaux objectifs: sécurité et efficacité du trafic.
INTRODUCTION
Lorsque l’on visite aujourd’hui les vigies des tours sud
et nord de l’aéroport de CDG, on est toujours étonné devant l’effervescence de l’activité des contrôleurs aériens
et la complexité de leur environnement de travail. Les
contrôleurs en vigie (prévol, SOL, LOC), responsables
de la surveillance et du guidage des aéronefs sur la plateforme et dans ses environs, centralisent et traitent des informations en provenance d’outils nombreux et hétérogènes tels que la fréquence radio, l’image radar sol et air,
l’image météo aux seuils de piste et la vue extérieure.
Ces informations sont de surcroît exploitées dans un environnement fortement contraint (pressions temporelles
fortes).
En association avec cet environnement complexe, les
contrôleurs SOL et LOC concentrent pourtant une part
essentielle de leur activité gestuelle et perceptive sur
l’utilisation de simples supports papier (les strips). Ces
strips, assimilables à un outil « papier-crayon »,
s’avèrent en fait d’une grande richesse sur le plan opérationnel car ils constituent pour les contrôleurs une aide
déterminante dans la gestion de leurs ressources perceptives et cognitives. En revanche, les strips revêtent un
certain nombre de limites inhérentes à la nature et aux
propriétés du support papier. De plus, leur faible capacité d’évolution les rend de plus en plus inadaptés face à la
complexification croissante du système aéroportuaire et
aux nouveaux enjeux en terme de sécurité et d’efficacité
(fluidité, capacité) du trafic. C’est dans ce contexte que
la conception de solutions IHM, intégrant cette complexité et positionnant toujours le contrôleur en tant que
facteur de performance, est aujourd’hui un enjeu majeur.
MOTS CLES : ATC, Aéroport, système complexe, strips
papier, Vigiestrips, facteur de performance.
ABSTRACT
This article deals with a project aiming at replacing
paper strips currently used in the Control Towers of
Paris-Charles de Gaulle Airport with electronic artifacts.
The first part demonstrates that an airport platform is
actually a complex system. Operational advantages of
paper strips are then detailed while focusing on
GROUND and RUNWAY air traffic controllers activity
at CDG. Limits and drawbacks of these strips are then
mentioned with regards to an ever complexifying
system. Vigiestrips concept is then discussed following
two guidelines : services for the controller on the one
side, and networking of information between controller
and other actors of the system on the other side. Added
values of Vigiestrips concept are then enumerated in the
frame of an “advanced airport“ system, relying
especially on two key objectives : airport safety and
efficiency.
L’AEROPORT : UN SYSTEME COMPLEXE
La navigation aérienne
L’ATC (Air Trafic Control) assure globalement la gestion du trafic aérien dans les aéroports et dans l’espace
aérien. Afin d’assurer cette tâche, l’espace est découpé
en zones géographiques appelées secteurs de contrôle.
Tout au long du vol un aéronef va donc traverser succes-
211
sivement un ensemble de secteurs qui constituent une
chaîne de responsabilités jusqu’à son arrivée au parking
de destination. Cette activité du contrôle de la navigation
aérienne offre une complexité qui provient de plusieurs
facteurs. Il y a d’une part l’hétérogénéité de ses usagers :
au sein des mêmes infrastructures se côtoient le trafic
commercial (plusieurs milliards de passager par an dans
le monde), l’aviation amateur et l’aviation militaire. Elle
vient d’autre part d’une exigence de sécurité très forte
ayant un impact majeur sur les organisations humaines et
techniques. Enfin, la multiplicité des acteurs en jeu, aux
contraintes fortes et parfois contradictoires constitue une
caractéristique indissociable de ce domaine.
Flow Management Unit) tout d’abord peut imposer de
respecter des délais unitaires au départ en fonction de
contraintes ou de surcharges de l’espace aérien à
l’échelle européenne. L’aéroport et les compagnies constituent également des interlocuteurs privilégiés dont il
faut intégrer les contraintes : les intentions départs planifiées évoluent en fonction du déroulement des opérations
d’escale pour chaque appareil, et peuvent se révéler
contradictoires avec les stratégies de planification mises
en place par l’ATC et la CFMU. En cas de dégradation
des conditions météorologiques, les moyens de dégivrage deviennent également un acteur critique qui impacte de façon décisive la gestion des aéronefs sur la
plate-forme. Enfin les centre de contrôle (Approches,
En-route) et aéroports adjacents influent significativement le trafic en temps réel, en cas de congestion de
l’espace aérien supérieur ou en cas de déroutements dus
à une dégradation météo sur des terrains proches insuffisamment équipés.
Le système de Roissy-CDG
ATC
Traite ment
pl an d e vo l
CFMU
En Route
Les objectifs du système « Aéroport Avancé » de
CDG
DMAN
Aé roport CDG
L’ensemble des outils développés ou en cours de développement pour tendre vers un environnement
« Aéroport Avancé » se décline au travers des deux
grands objectifs fédérateurs du système aéroport.
RIMCAS
L’objectif Sécurité :
AMAN
Approche
Autres
terrains
x
Figure 1 : Navigation aérienne et CDG
L’aéroport constitue le centre névralgique de cette
chaîne (cf. Figure 1), au sein de laquelle des conditions
de sécurité maximales et une efficacité optimale du trafic
doivent être atteints. Contrairement à l’espace aérien, où
la répartition du trafic est largement compartimentée selon les différentes catégories d’aviation (tourisme, défense, commerciale), les infrastructures aéroportuaires
(pistes, taxiways, parkings) doivent être simultanément
partagées entre tous les usagers (de l’appareil de 400
tonnes à l’avion de tourisme biplace). L’ATC doit alors
assurer la gestion complète des aéronefs sur l’aéroport,
éviter tout risque d’abordage tout en assurant un écoulement fluide du trafic. Les contraintes à intégrer y sont
diverses : respecter pour chaque avion le créneau horaire
de décollage prévu, intégrer des contraintes anticipées
(gestion du dégivrage avant décollage, ravitaillement…)
ou subies en temps réel (déchargement d’un bagage à la
dernière minute, anomalies avant décollage, problèmes
d’allocation de parkings…).
x
Les services fournis par l’outil RIMCAS (information et alarme lors d’une situation potentiellement conflictuelle ou conflictuelle aux abords
des pistes) se basent sur un algorithme
d’incursions pistes adapté à CDG.
La mise en place de verrous de sécurité se décline également au travers de barres d’arrêt sur
les bretelles d’accès aux pistes, commandables
depuis la tour de contrôle, qui empêchent tout
mobile (véhicule ou aéronef) d’accéder aux pistes pendant les phases critiques (atterrissage, décollage).
L’objectif Efficacité :
x
x
CDG figure parmi les aéroports les plus importants et les
plus complexes au monde. Y assurer la gestion du trafic
aérien implique la mise en place d’interfaces avec un
certain nombre d’acteurs extérieurs. La CFMU (Central
212
L’outil DMAN (Departure Manager) se base sur
un algorithme d’aide plus global destiné à répondre conjointement aux besoins des aéroports
de la région parisienne et des centres en-route
intégrant différents flux de départs. Son rôle est
la prédiction et l’optimisation de séquences de
décollage et des charges de trafic pour les secteurs en-route d’intégration.
L’outil AMAN (Arrival Manager) optimise la
capacité d’atterrissage sur les terrains de la région parisienne en permettant aux secteurs enroute d’appliquer une séquence des aéronefs à
l’arrivée le plus tôt possible, afin de lisser le tra-
x
fic et éviter les congestions au niveau de
l’aéroport.
Le CDM (Collaborative Decision Making), participe de la volonté de mettre en commun un certain nombre d’informations et de requêtes en
provenance de différents acteurs (ADP, Air
France…).
premier plan pour la gestion du stress du contrôleur. Le
fait de disposer d’un support d’information fiable en
toute circonstance ainsi que le sentiment de mieux maîtriser le trafic (manipulation d’un objet concret) rassure
réellement le contrôleur.
Vers une complexité croissante. En regard de ces
objectifs, la recherche de performance et de précision
exigée par ces outils accroît progressivement le besoin
de collaboration en ligne des différents acteurs de CDG
(contrôleurs, Air France, gestionnaire de parking, ADP,
CFMU…). En effet, l’impact potentiel des contraintes de
chacun est tel que leur connaissance mutuelle par
l’ensemble des acteurs du système devient le garant du
bon fonctionnement de la plate-forme de CDG.
Figure 3 : Détail d’un strip papier
… mais un outil en voie d’obsolescence
Le support papier présente cependant des limites intrinsèques difficilement contournables. Aujourd’hui déjà,
certaines situations opérationnelles mettent à mal la robustesse de ce support (pics de trafic, situations transitoires mal anticipées…). Sous la contrainte de temps, le
contrôleur se trouve confronté à des difficultés dans la
gestion et la mise à jour de son tableau de strips (tri des
strips à la sortie d’imprimante, recherche d’un strip,
existence potentielle de strips en double, débordement
du tableau de strips…).
LE STRIP PAPIER A CDG
Un outil à haute valeur ajoutée…
De plus, la complexification progressive du système aéroportuaire de CDG , implique une réévaluation du rôle
du contrôleur en tant qu’acteur central et facteur de performance au sein de ce système. Il s’agit en effet de garder l’homme dans la boucle en lui donnant les moyens
d’interagir avec d’autres acteurs toujours plus nombreux
du système (partage dynamique des informations). Or, il
n’est guère concevable de conserver un outil comme le
strip papier qui constitue un obstacle réel vis à vis des
besoins croissants en termes de collaboration en ligne
des différents acteurs. Tout d’abord, le strip papier, qui
ne véhicule les « traces » de l’activité du contrôleur que
d’une manière locale, s’adapte mal aux évolutions d’un
système qui doit promouvoir une collaboration accrue
entre les contrôleurs de CDG et leurs interlocuteurs directs dans la chaîne de contrôle (Approche et CRNA
Nord). D’autre part, les actions de contrôle (clairances
données aux pilotes par les contrôleurs SOL et LOC et
inscrites sur le strip papier) devront pouvoir être transmises en temps réel vers un certain nombre d’outils
d’aides au contrôle, afin de rendre ces derniers plus réactifs aux évènements de trafic. Enfin, dans un contexte
d’Aéroport Avancé, le contrôleur devra gérer d’une manière centralisée et cohérente une quantité toujours plus
grande d’informations en provenance d’un nombre
croissant d’acteurs du système de contrôle (facteurs humains ou techniques). Or, l’absence d’évolutivité du
papier (matière inerte) ne permet pas au strip papier de
faire vivre des informations (affichage et mise à jour régulière) et interdit donc à ce support tout rôle
d’intégration dynamique.
Figure 2 : Strips papiers à la tour
Dans le cadre d’une étude terrain effectuée en 2001 à la
tour sud de CDG, une équipe d’ergonome de la DSNA
(cf. [1]) a centré ses observations sur les méthodes de
travail des contrôleurs SOL et LOC associées à la gestion des strips papier (cf. Figure 2). Un strip papier
correspond à un aéronef (cf. Figure 3). Chaque strip est
manipulé dans un tableau alloué (le tableau opérationnel) et annoté à plusieurs reprises par le contrôleur lorsque l’aéronef associé se trouve dans son secteur de responsabilité (i.e. une partie des parkings et de la plateforme CDG pour le contrôleur SOL, la zone de servitudes pistes sud ou nord pour le contrôleur LOC). En tout
premier lieu, les auteurs purent mettre en évidence la
forte dimension cognitive inhérente à l’usage de ce support (résultats corroborant les travaux de recherche dans
le domaine, cf. [3] et [4]). L’environnement de type
« stripping » constitue un réel prolongement de l’activité
mentale et perceptive des contrôleurs. Par ailleurs, en
permettant un partage continu des informations entre le
SOL et le LOC, ce support enrichit le travail collectif et
contribue directement à la constitution d’une conscience
partagée du trafic. Enfin, le strip s’avère un outil de tout
Par conséquent, sous peine de dégrader le niveau de performance du contrôleur et donc de l’ensemble du sys-
213
tème aéroportuaire, le strip papier doit aujourd’hui être
considéré à CDG comme un outil obsolète.
frastructures peu complexes, ne peut être envisagé pour
CDG, où la charge de trafic et la complexité du système
sont telles que seule une solution réellement intégrée à
l’activité du SOL et du LOC et aux méthodes de travail
associées peut être envisagée.
LES TENTATIVES DE SUPPRESSION DU STRIP PAPIER DANS L’ATC
La transition vers un environnement de travail « tout
électronique » dans l’ATC est une préoccupation remontant au début des années 80. Aujourd’hui encore, à
l’exception de certains aéroports (canadiens, brésiliens,
ou encore européens comme Oslo et Bruxelles), la majorité des terrains dans le monde n’a pas effectué cette
transition vers un contrôle aérien sans strip. Deux grandes familles de solutions ont émergé : l’une orientée vers
une gestion des vols par listes, l’autre proposant une
transposition du support papier dans un environnement
électronique.
VIGIESTRIPS : UN OUTIL REMETTANT LE CONTROLEUR AU CENTRE DU SYSTEME AEROPORT
Le concept Vigiestrips
Ayant bien intégré le rôle actuel des strips papier dans
les tours de CDG et appréhendé les futurs enjeux opérationnels associés à la complexification du système aéroport, les protagonistes du programme Vigiestrips se sont
orientés vers un concept qui s’articule autour de deux
axes fondamentaux :
x
Les nombreuses tentatives infructueuses qui ont essaimé
l’histoire du contrôle aérien dans ce domaine sont à cet
égard tout à fait notables. Le rejet chronique des contrôleurs aériens face aux solutions proposées tenait à plusieurs facteurs :
x
Pour les systèmes conçus à base de listes, l’écueil fut de
vaciller de façon récurrente entre des solutions automatisant les classements, mal acceptées (principes
d’animation peu ou mal connus, algorithmes de tri inadaptés), et des solutions proposant une gestion manuelle
des listes, se heurtant à une lourdeur de manipulation et
une inefficacité globale rédhibitoires (cf. [10]). Ces solutions se heurtaient également à une immaturité technique : puissances de calcul insuffisantes, technologies
tactiles peu fiables.
Premier axe - Conserver les qualités
opérationnelles reconnues des strips papier tout
en gommant leurs limites sur le plan de la
manipulation.
Deuxième axe - Intégrer des fonctions nouvelles
à fortes valeurs ajoutées replaçant le contrôleur
au centre du système (cf. Figure 4) et permettant
de répondre aux exigences futures de
l’environnement Aéroport Avancé.
Aéroport CDG
B arres d’arrêt
RIMC AS
Balisages au sol
SO L
Des systèmes proposant une transposition de la méthode
de travail élaborée avec le strip papier sont apparus plus
tard, tentant, en l’immergeant dans un environnement
électronique, de reproduire les avantages du strip papier
tout en lui conférant un comportement dynamique. Digistrips, projet développé par la DSNA à la fin des années 90 (cf. [5]), marqua ainsi un réel tournant dans les
possibilités envisageables. Ce projet proposait un démonstrateur sur écran tactile reproduisant la gestuelle associée aux strips papier pour le contrôle En Route. La
DSNA, considérant cette étude comme prospective, ne la
concrétisa pas par des expérimentations réalistes et le
démonstrateur ne fut pas adapté à un centre En route
particulier. A noter cependant que quelques industriels
en ont tenté des applications concrètes.
DMAN
LOC
VI GIE STRIPS
Prévol
Autres
contrôleurs
CDM
ADP
Parking
A ir France
Figure 4 : Vigiestrips au centre du système de contrôle aéroportuaire
Vigiestrips : une IHM dépassant les limites du strips
papier
En référence au premier axe du concept Vigiestrips, les
choix de conception IHM se sont inspirés de
l’environnement Digistrips (cf. ci-dessus). Dans la lignée
de ce projet, les concepteurs de Vigiestrips ont conservé
la notion de « stripping » (manipulation de strips par le
contrôleur) en mettant en avant une IHM alliant intuitivité et simplicité d’usage. Ils ont dans cette perspective repris le principe d’une interaction directe sur une dalle
tactile (stylet). La suite du chapitre présente de manière
synthétique les principaux services proposés autour de la
L’application au domaine aéroportuaire est plus récente.
Des solutions intermédiaires ont été mises en place sur
certains aéroports, plus sophistiquées qu’une simple gestion de liste mais ne reproduisant qu’imparfaitement les
apports du support papier sur un plan cognitif (aide à
l’anticipation, la mémorisation et la représentation mentale du trafic). Ce type de produits, s’il peut s’avérer
adaptable à des terrains de taille moyenne ou à des in-
214
gestion des strips devenus des « e-strips » (strips électroniques).
la richesse cognitive et la naturalité d’exécution. La modalité d’écriture libre, accessible sur un format d’e-strip
zoomé (cf. Figure 6), permet au contrôleur d’écrire des
informations diverses, qu’il s’agisse d’un symbole unique (e.g. l’entourage ou le soulignage d’un item) ou
d’une petite phrase (e.g. Problème radio).
Figure 6 : Ecriture libre sur e-strips zoomés
La modalité d’écriture mettant en œuvre la reconnaissance de gestes a été réservée à la saisie d’instructions de
contrôle (e.g. ordre de roulage aujourd’hui concrétisé
par le tracé d’un R sur le strip papier, ordre de décollage
concrétisé par le tracé d’un T, etc.). Plusieurs facteurs
ont orienté ce choix de conception. Tout d’abord le
nombre de gestes saisi est relativement restreint (moins
de dix gestes). Ces gestes sont ensuite simples à tracer et
de caractère stable (les mêmes symboles sont partagés
par tous les contrôleurs).. Pour favoriser le caractère naturel de la saisie, ces symboles (R, T…) ont donc été reproduits et intégrés dans la bibliothèque de gestes.
Figure 5 : IHM Vigiestrips
L’IHM Vigiestrips (cf. Figure 5) conserve les deux
principales zones actuelles de gestion des strips : le
tableau d’attente à gauche (zone de stockage des strips
correspondant aux aéronefs qui vont arriver sur le
secteur) et le tableau opérationnel au centre (zone de
manipulation et de classification des strips
correspondants aux aéronefs sous la responsabilité du
contrôleur). La gestion du tableau d’attente, apparentée
aujourd’hui à des actions peu valorisées (e.g. recherche
des strips à l’imprimante, pré tri), a été pour l’essentiel
déléguée au système (mise en place et classification
automatique des e-strips). De ce fait, le contrôleur se
trouve soulagé d’un grand nombre d’actions parasites et
coûteuses (notamment dans le cas de pics de trafic) et
peut donc se concentrer sur ses actions de contrôle. En
revanche, comme l’a démontrée l’étude terrain, les
manipulations de strips dans le tableau opérationnel
s’avèrent essentielles pour le contrôleur SOL comme
pour le LOC. Vigiestrips préserve donc une grande
liberté de déplacement et de positionnement des e-strips
dans ce tableau. Cette liberté d’action est de plus
enrichie d’un certain nombre de services IHM destinés à
faciliter toutes les gestuelles de manipulations : fonctions
de guidage dynamique (position fantôme de l’e-strip
anticipant sa position future, activation des colonnes à
l’approche de l’e-strip…) et aides au positionnement
(déplacements groupés, insertions entre deux e-strips,
décalages rapides, effets d’attraction de l’e-strip par la
colonne activée …).
L’intérêt de la reconnaissance de gestes se situe également dans le fait que le système interprète le symbole
tracé et qu’il peut en restituer un feed-back bien lisible
pour le contrôleur (cf. Figure 7). Enfin et surtout, une
fois le symbole reconnu, le système est en mesure de
diffuser l’information en temps réel aux autres acteurs
du système aéroport.
Figure 7 : Reconnaissance de gestes
Vigiestrips : un support d’intégration des fonctions
du système Aéroport Avancé
En référence au second axe du concept Vigiestrips, Les
nouveaux services fournis ont pour ambition de favoriser
la mise place du système Aéroport Avancé et de
contribuer à l’atteinte des objectifs de sécurité et
d’efficacité du trafic. A ce titre, et comme cela a déjà été
mis en avant par D.Pavet et al. (Cf. [7]),
l’environnement Vigiestrips se positionne comme un
véritable outil d’intégration des données circulant entre
les différents acteurs (humains et techniques) du
système.
Les actions d’annotations sur les strips, également assimilées à des actions “valorisées” sur un plan opérationnel (i.e. gestes d’écriture facilitant le processus de mémorisation), ont également été reproduites dans
l’environnement Vigiestrips. Le contrôleur dispose à cet
effet de deux modalités pour annoter son e-strip : la reconnaissance de gestes et l’écriture libre. Ces deux modalités perpétuent l’acte d’écriture directe par le biais du
stylet sur la dalle tactile de manière à en conserver toute
La prise en compte des fonctions de Sécurité.
L’activité de guidage et de surveillance du trafic est tout
d’abord favorisée par la hiérarchisation et le partage des
215
informations via le support e-strip. Les contrôleurs SOL
et LOC peuvent par exemple partager la visualisation de
l’e-strip d’un seul et même aéronef sur leur IHM Vigiestrips respective (un seul contrôleur en a cependant la
responsabilité à un instant t). Ensuite, le support e-strip
permet de créer une redondance des informations qui ne
sont aujourd’hui affichées que sur l’image radar. C’est le
cas notamment des informations et des alarmes générées
par l’outil RIMCAS (cf. Figure 8).
La prise en compte des objectifs d’efficacité du trafic.
Comme cela a été évoqué par E. Page (cf. [6]), le
principe d’alimenter le système avec les actions du
contrôleur SOL ou LOC est également avantageux pour
des fonctions de l’Aéroport Avancé telles que des aides
à l’optimisation de la séquence Départ et la gestion des
créneaux CFMU.
A titre d’exemple, les clairances saisies par le contrôleur
pour les aéronefs au Départ (sortie de parking, roulage)
sont envoyées au DMAN. Cet outil est alors en mesure
d’affiner l’estimée de décollage de chaque aéronef
Départ sur la base de ces clairances et d’en informer en
retour le contrôleur et la compagnie aérienne.
Concrètement, il envoie au contrôleur prévol (qui gère
les parkings) une heure optimisée pour la mise en route
des aéronefs et au contrôleur SOL une heure optimisée
pour leur faire quitter le parking. Ces mises à jour de
l’estimée de décollage permettent également au DMAN
d’informer les contrôleurs qu’un aéronef ayant un
créneau CFMU sera éventuellement en avance ou au
contraire en retard sur son créneau. Dans ce cas, une
information est fournie spécifiquement aux contrôleurs
SOL et LOC sur le temps à faire perdre ou à faire gagner
à l’aéronef pour permettre à ce dernier de se réinsérer
dans son créneau de décollage (cf. Figure 9).
Figure 8 : Redondance des informations et des alarmes
De plus, la prise en compte par le système des actions du
contrôleur (saisie de clairances effectuée via la zone de
reconnaissance de gestes et récupérées par RIMCAS)
doit permettre une meilleure anticipation d’une situation
à risque. Par exemple, un aéronef au décollage débutant
une accélération sur la piste peut être considérée comme
une situation à risque si le système n’a pas détecté la
clairance de décollage effectuée par le LOC (tracé du
symbole T sur l’e-strip). RIMCAS traite cette donnée en
association avec des données radar et génère le cas
échéant une information ou une alarme qui est affichée
directement sur l’e-strip. La prise en compte par le système des actions du contrôleur doit aussi grandement favoriser la gestion des éclairages au sol pour les barres
d’arrêt (feux rouges régulant l’accès à la piste pour les
mobiles au sol) .
Figure 9 : Information de temps à gagner
Pour l’optimisation de la séquence Départ, l’exploitation
des actions du contrôleur par le système aéroport ne se
limite pas aux annotations des e-strips. L’environnement
Vigiestrips permet également de transmettre au DMAN
les informations de la séquence globale construite par le
LOC en récupérant les informations de la position relative de chaque e-strip dans la colonne des Départs du tableau opérationnel. Le DMAN peut alors affiner régulièrement ses calculs de séquence globale en prenant en
considération les choix du contrôleur.
Un exemple est donné illustrant les échanges entre le
DMAN et les IHM des contrôleurs dans le cas de la gestion d’un retard créneau (cf. Figure 10).
A titre d’exemple, une autorisation d’alignement piste
(saisie du geste « I » par le contrôleur LOC) enclenche
l’activation du feu vert au niveau de la barre d’arrêt ainsi
que l’allumage des éclairages au sol de manière à guider
le pilote jusqu’à la piste. Cela doit induire une réelle
amélioration dans le fonctionnement du système
aéroport dans la mesure où toutes ces actions sont
aujourd’hui effectuées sur des écrans différents et
alourdissent considérablement la tâche du contrôleur.
216
jour déroulé en deux étapes : deux séries de preexpérimentations (small-scale experimentations) en 2004
et une expérimentation de validation complète (extensive
experimentations) en 2005 ; ces étapes étant en conformité avec la méthodologie prônée par le comité de validation de la DSNA – cf. [8] et [9]).
La première série de pre-expérimentations était centrée
sur le thème de la manipulation des e-strips dans un espace défini (décalages, déplacements verticaux, horizontaux, en biais…) et la deuxième série était centrée sur le
thème de l’écriture sur e-strips (symboles ou mots). Les
deux séries étaient bâties sur une logique de comparaison : les sujets devaient effectuer une même série de petits exercices alternativement sur un tableau de strips
(strips papier) et sur Vigiestrips (e-strips). Chaque exercice était filmé et chronométré. Pour les deux séries, les
résultats quantitatifs et objectifs se sont avérés être à
l’avantage des strips papiers (les erreurs système dans la
reconnaissance de symboles, les erreurs « humaine »
dans l’exécution de la tâche et le temps mis pour effectuer l’exercice étaient supérieurs sur Vigiestrips) alors
que les résultats subjectifs qualitatifs et quantitatifs (debriefings, questionnaire incluant la notion de charge de
travail perçue) étaient au contraire plus en faveur de Vigiestrips (effet de séduction d’un environnement « hightech », dialogues jugés naturels, sentiment d’un environnement propre et bien rangé à la fin de chaque exercice…).
Figure 10 : Services DMAN
La compagnie aérienne Air France et les gestionnaires
de parking, autres acteurs du système aéroportuaire de
CDG, bénéficient eux aussi de la récupération temps réel
des actions des contrôleurs SOL et LOC. En effet, les
clairances de sortie de parking (repoussage concrétisé
par la saisie d’un P sur l’e-strip), de décollage ou
d’atterrissage (saisie d’un L sur l’e-strip) sont traitées
par le DMAN et récupérées par l’outil CDM qui informe
en retour les différents acteurs d’éventuels délais sur la
disponibilité des parkings, les heures précises de sorties
de parking, etc. Le partage de ces informations doit
concourir à optimiser les allocations de parkings et donc
à éviter l’encombrement des taxiways par des aéronefs
en attente d’un parking.
L’analyse des résultats de ces pre-expérimentations, et
plus particulièrement ceux défavorables à Vigiestrips
(indicateurs quantitatifs objectifs), a permis aux expérimentateurs d’identifier un certain nombre d’axes
d’améliorations dont les principaux sont cités en-suivant.
Le type d’écran et la technologie utilisés ont été changés.
Les écrans tactiles résistifs interdisant le double contact
(le sujet ne peut pas appuyer sa main ou son avant bras
sur l’écran lors de l’écriture) et présentant des limites diverses (problèmes de parallaxes, nécessité d’exercer une
pression assez forte sur le stylet) ont été remplacés par
une technologie de type électromagnétique bien plus appropriée (pression du stylet minimisée et possibilité
d’effectuer un double contact sur l’écran). Des éléments
de conception de la maquette ont été modifiés afin de
minimiser les temps de réponse de l’IHM, l’algorithme
de reconnaissance de gestes a été optimisé par le biais
d’une bibliothèque de symboles simplifiée, quelques
fonctions IHM sensibles (sources d’erreurs dans leur
mise en oeuvre) ont été améliorées.
LE PROCESSUS D’EVALUATION DE VIGIESTRIPS
Studies
Graphic design / Look and Feel
Input
Small-scale
Experimentations
Output
(dialogues devices,
(Feed-back / animations)
intuitiveness, naturality…)
System tools (PRIMA, DMAN)
HMI functions / working methods
(intra and inter-positions)
Field studies at CDG airport
(paper strips : advantages and drawbacks)
Toutes ces évolutions ont été concrétisées pour la première expérimentation de validation complète qui a eu
lieu entre avril et septembre 2005 (5 sessions de 3 journées chacune). 10 contrôleurs de Roissy CDG ont participé à ces sessions (2 par session). Les deux positions
SOL et LOC étaient simulées dans un environnement
complet (visuel 3D de l’aéroport, scénarios variés com-
Extensive Experimentations
Figure 11 : Démarche d’évaluation
Les étapes expérimentales
Suite à l’étude terrain évoquée plus en avant dans cet article, le processus d’évaluation de Vigiestrips s’est à ce
217
portant différentes charges et configurations de trafic,
présence de pilotes écho radar, liaisons téléphone et
VHF, intégration du DMAN et de PRIMA, etc.). A ce
stade, l’expérimentation n’était pas de nature comparative (pas de confrontation avec un environnement
« Baseline » avec strips papier). L’environnement réaliste ainsi que la prise en compte croisée de nombreux
indicateurs (thèmes sécurité et efficacité du trafic
appréhendés par le biais d’indicateurs tels que la charge
de travail perçue, le collectif de travail, les communications, la mise en oeuvre de fonctions IHM spécifiques,
etc.) ont cependant permis d’obtenir des résultats solides
et étayés.
Figure 13 : Sécurité des pistes
Une interrogation majeure persiste cependant au sujet de
la reconnaissance de symboles par le système (saisie
d’instructions). Son intérêt opérationnel (naturalité, aide
à la mémorisation, clarté du feed back) a été parfaitement perçu par les contrôleurs mais les erreurs de reconnaissance résiduelles, même si elles ont fortement diminué comparativement aux pre-expérimentations (35%
d’erreurs pour certains symboles ramenés à moins de
5%) persistent. Or, il a été clairement observé qu’une
seule erreur de reconnaissance pouvait avoir de lourdes
conséquences sur la sécurité du contrôle (e.g. le LOC
saisit un T pour l’autorisation de décollage d’un vol, le
système ne reconnaît pas le symbole et ne l’affiche pas
sur l’e-strip, le LOC peut donc quelques minutes plus
tard oublier le fait qu’il a autorisé ce vol au décollage).
La figure ci-dessous (cf. Figure 14) issue du traitement
des données illustre ces réserves (position du curseur
dans la partie « compromis actif »).
Les principaux résultats
L’exploitation et l’analyse de l’ensemble des données
recueillies par différentes sources (archivages informatiques, enregistrements audio/vidéo, grilles d’observation,
débriefings, questionnaires) ont permis de montrer que le
concept Vigiestrips, associé à d’autres outils de contrôle
(Vue extérieure, image radar, DMAN, PRIMA)
répondait sur un plan individuel (SOL et LOC) comme
sur un plan collectif (collaboration SOL-LOC) aux principales attentes opérationnelles du contrôle en tour à
CDG (anticipation et organisation du trafic, prévention
des incursions pistes, transferts et coordinations, gestion
des traversées de pistes, etc.). La pertinence de certains
choix techniques (interaction tactile) et conceptuels (partage des tâches homme-machine, logiques de manipulations des e-strips et d’écriture…) en ressort renforcée. A
titre d’exemple, les figures ci-dessous (cf. Figure 12 et
Figure 13) extraites des résultats des expérimentations, illustrent les avis des contrôleurs sur les évolutions par
rapport aux strips papier en général et l’impact sur la
sécurité des pistes en particulier.
Principe des saisies de symboles (LOC)
Utilisabilité
28
IHM adaptée mais
fonctions inutiles
Fonctions utiles
et IHM adaptée
0
y=-8
x=8
Fonctions
inutiles et IHM
inadaptée
Fonctions utiles
mais IHM
inadaptée
-28
-20
0
Utilité
Figure 14 : Qualité de la reconnaissance de symboles
Des études complémentaires doivent donc être effectuées sur ce thème précis pour décider à terme de sa viabilité dans l’activité de contrôle en tour. Il faut retenir
au global que sur le fond, et malgré quelques réserves
sur certains points IHM à améliorer, le concept Vigiestrips a recueilli l’adhésion de la totalité des contrôleurs
ayant participé aux expérimentations. Ils demandent clairement que ce projet ait une suite concrète.
Figure 12 : Comparaison e-strips / strips papier
218
20
CONCLUSION
Cette interopérabilité se traduira par une compréhension
et une représentation partagée des différentes situations
de trafic et des prises de décision concertées (renégociation participative des créneaux de décollages, répercussions rapides des modifications de programmation compagnies sur les prévisions de charges de
trafic,etc.). Là où aujourd’hui les différents acteurs ont
des vues encore trop souvent cloisonnées (non coordonnées et non mises en réseau), la mise en place
d’interfaces communes et interactives ouvre la voie à un
système intégré et à des prises de décisions dans le sens
de l’intérêt global du système aéroport CDG et vers une
efficacité optimale de l’ATC.
La phase de conception et la première étape de
l’évaluation de l’IHM Vigiestrips est aujourd’hui terminée. Les résultats issus de la campagne
d’expérimentations menée avec des contrôleurs de CDG
en 2005 (cf. [2]) valident le concept Vigiestrips ainsi
qu’une majeure partie des choix IHM. De nouvelles étapes dans le processus d’évaluation doivent être franchies prochainement pour aller vers une implantation
opérationnelle progressive. Un certain nombre de métriques devront être abordées (e.g. évolution de la criticité
des alarmes générées, gains en capacité et fluidité de trafic …) pour quantifier précisément les différents gains
par rapport aux strips papier, et illustrer de manière
concrète les impacts de la mise en réseau de l’activité
des contrôleurs (exploitation en temps réel par le système d’actes comme les saisies d’instructions sur les estrips) sur la performance globale du système Aéroport
Avancé.
BIBLIOGRAPHY
Pour cela, différentes actions vont être entreprises, telles
que l’organisation de nouvelles expérimentations complètes de type comparative (mesures des gains sur un
plan sécurité et efficacité pour alimenter notamment des
considérations de retours sur investissement) et
l’installation de Vigiestrips en position miroir sur le site
de CDG (connection au trafic réel et mise en réseau des
données). Cette deuxième action aura plusieurs avantages comme de permettre la confrontation de l’outil aux
conditions réelles d’exploitation (utilisation dans la durée, ambiances lumineuses de la tour, aléas du quotidien
comme le renversement de la tasse de café sur l’écran,
simulations de pannes diverses, etc.) et de donner la
possibilité à tous les contrôleurs de découvrir et de tester
l’outil sur place.
Il s’agit au final, alors que le thème de « l’Homme dans
la boucle » fait toujours débat dans le domaine du
contrôle aérien (e.g. le concept de free flight est toujours
vivace chez certains membres de la communauté aéronautique), de garder le contrôleur aérien au centre d’un
système global participatif. Avec Vigiestrips,
l’interopérabilité totale entre les différents acteurs
(Compagnies, Centre de régulation CFMU, gestionnaires
d’aéroports et contrôle aérien) peut être sérieusement
envisagée.
1.
Coullon, I. Garron, J. Pavet, D. Henry-Ducos, P.
Utilisation des strips papier par les contrôleurs de
la Vigie Sud à Paris/LFPG – CENA/ICS/R00-010
2.
Garron, J. Saladin étape 2 – Résultats
d’expérimentations. SDER/NT05-340.
3.
Gras, A. et al. Face à l’automate : le pilote, le
contrôleur et l’ingénieur. Publications de la Sorbonne, 1994.
4.
Mackay, W. Is paper Safer ? The Role of paper
Flight Strips in Air Traffic Control.
ACM/Transactions on Computer-Human
Interaction (2000) Vol. 6 (4), pp. 311-340
5.
Mertz, C. Vinot, J.L. Chatty, S. Pushing the limits
of ATC User Interface Design beyond S&M
Interaction : the Digistrips experience – FAA/EEC
R&D seminar ATM 2000-Napoli.
6.
Page, E. Laurent, T. Pavet, D. Departure manager
for the Paris region – Revue technique de la DTI –
DSNA – June 2005.
7.
Pavet, P. et al. Use of paper strips by tower air
traffic controllers and promises offered by new
design technologies on user interface –
USA/Europe R&D seminar ATM 2001-Santa-Fe.
8.
Pavet, D. Comité Validation, Objectifs, Mandat –
NT02-183
9.
Chabrol, C. Guide pratique de la validation au
CENA – CENA/ICS/NT03-043
10. De Beler, N. Mavern, F. Spécifications de la maquette HEGIAS 94 – CENA/ICS/R94-040
219
Utilisation d’une Nouvelle Technologie de l’Information et la
Communication – la préparation de commandes avec le
guidage vocal
Virginie Govaere et Jean-François Schouller
INRS
Département Homme au travail
BP 27
54701 Vandoeuvre cedex
Email : [email protected]
[email protected]
Email : [email protected]
mental component of the task of preparation that on the
level of physical painfulness.
RESUME
Ce travail s’inscrit dans une étude, menée par l’INRS,
sur les effets de l’utilisation des Nouvelles Technologies
de l’Information et de la Communication (NTIC) pour la
santé et la sécurité des opérateurs. L’intervention s’est
déroulée dans le secteur de la logistique et a concerné
l’activité de préparation de commandes. L’introduction
du guidage vocal a permis à l’entreprise de réaliser des
gains de productivité importants. Cependant, ce guidage
semble contribuer à la diminution des marges de
manœuvre des préparateurs du fait de l’organisation du
cycle de préparation de commande en « pas à pas ».
Malgré cette restriction sévère des marges, certains
opérateurs parviennent à regagner d’autres espaces :
réaliser des pronostics ou valider par anticipation ce qui
va être commandé. Ces premières analyses ont permis de
montrer que la principale modification introduite par le
guidage vocal intervient plutôt sur la composante
mentale de la tâche de préparation qu’au niveau de la
pénibilité physique.
KEYWORDS
ICT, logistic, health and safety
INTRODUCTION
Ce travail s’inscrit dans une étude, menée par l’INRS,
sur les effets pour la santé et sécurité des opérateurs de
l’utilisation
des
Nouvelles
Technologies
de
l’Information et de la Communication (NTIC). Il répond
également à une demande de la Caisse Régionale
d’Assurance Maladie (CRAM) des Pays de la Loire et
d’une entreprise qui souhaitent connaître les effets de
l’utilisation du guidage vocal sur les préparateurs de
commandes, en termes de santé et de sécurité.
Les changements induits par l’innovation en matière
d’information et de communication constituent un
progrès pour l’entreprise et favorisent l’efficacité. Mais,
comme toute introduction de nouveaux outils, ces
technologies amènent des modifications dans la façon de
travailler, dans les compétences à mettre en œuvre par
les utilisateurs et probablement dans la façon dont
l’entreprise toute entière organise son fonctionnement [6,
5, 7]. Ces nouvelles situations de travail peuvent
conduire à une réduction de certains risques et/ou
engendrer des risques nouveaux pour les opérateurs.
L’étude présentée visait à mieux comprendre les
modifications du travail liées à l’utilisation de ces NTIC
afin de prévenir les éventuels risques professionnels.
L’intervention s’est déroulée dans le secteur de la
logistique. Ce secteur présente deux caractéristiques :
x Un indice élevé de fréquence d’accidents de travail
avec arrêt (1,75 fois supérieur à la moyenne nationale,
tous CTN confondus),
x Une transformation organisationnelle du secteur qui
se traduit par l’intégration de technologies
informatiques et de réseaux de communication dans
l’ensemble des processus [1]. La logistique évolue des
opérations d’entreposage ou liées au transport vers la
notion de « supply chain » (« chaîne logistique »). Elle
peut ainsi se définir comme « la technologie de la
MOTS CLES
Logistique, préparation de commandes, Nouvelles
technologies de l’Information et de la Communication,
santé et sécurité
ABSTRACT
This study falls under a program of the INRS on the
effects of the use of Information and Communication
Technologies (ICT) for health and safety of the
operators. The intervention took place in the logistics
sector and was related to the activity of preparation of
orders. The introduction of vocal guidance led to carry
out important profits of productivity for the company.
However, this guidance seems to contribute to the
reduction in the margins of manoeuvre of the operators
because of the cycle of preparation of order in “step by
step”. In spite of this severe restriction of the margins,
some operators manage to regain other spaces: to carry
out predictions about task sequences or to validate by
anticipation what will be ordered. These first analyses
made it possible to show that the principal modification
introduced by vocal guidance intervenes rather on the
221
maîtrise des flux tout au long de la chaîne clientsfournisseur » [2].
Il existe actuellement peu d’études ergonomiques sur
l’activité de préparation de commandes dans ce secteur.
Le préparateur de commandes a pour mission principale
la préparation matérielle des commandes à partir d’un
bordereau ou d’un dispositif informatique portatif.
que des entretiens semi-dirigés pour saisir le ressenti
des préparateurs de commandes.
x Des auto confrontations amenaient les préparateurs à
réagir à différentes séquences filmées de leur activité.
Tous les préparateurs y ont participé. Il s’agissait de
tenter d’accéder aux représentations et stratégies mises
en œuvre par les préparateurs dans leur travail.
x Un questionnaire, comportant 20 questions réparties
en quatre thèmes : fatigue physique, fatigue nerveuse,
fatigue auditive et satisfaction au travail a été soumis à
24 préparateurs, en une passation au milieu de la
semaine. Les préparateurs étaient volontaires et leur
répartition respectait les critères d’âge et d’ancienneté
établis pour l’intervention.
x Une évaluation subjective de la fatigue physique sur
une journée de travail a été soumise à 24 préparateurs.
Le principe de l’échelle de Borg [3, 4] a été retenu.
Celle-ci consiste à demander à l’opérateur, au cours de
son activité, d’évaluer la fatigue ressentie au niveau
d’un segment musculaire sur une échelle en dix points.
Cette évaluation a porté sur 8 segments : le cou, le dos,
les avant-bras gauche et droit, les bras gauche et droit,
les jambes gauche et droite. Six passations ont été
effectuées : à la prise de poste (8h00-8h30), avant la
pause du matin (9h45), avant la coupure du matin
(11h45), à la reprise après la coupure (13h15), avant la
pause de l’après-midi (14h45) et en fin de poste
(16h15).
CONTEXTE DE L’INTERVENTION
La plate-forme logistique sur laquelle nous sommes
intervenus est orientée vers la grande distribution
(hypermarchés et supermarchés). Elle comprend 150
salariés dont 60 préparateurs de commandes. Ces
derniers se déplacent dans l’entrepôt (20 500m2) avec un
chariot motorisé. Les préparateurs sont guidés dans la
réalisation des commandes par un système de
reconnaissance vocale (NTIC). L’introduction de cet
outil a pour objectif de diminuer fortement le nombre
d’inversions, suppressions ou ajouts de colis dans les
commandes. Ainsi, un guidage pas à pas des
préparateurs dans le déroulement et le contenu des
opérations à réaliser est retenu dans le fonctionnement
du système de guidage vocal. Ce choix induit un niveau
de prescription très élevé pour les préparateurs (Figure
1).
RESULTATS
L’analyse de l’activité donne des informations
quantitatives et qualitatives sur le déroulement et le
contenu du travail.
Les préparateurs de commandes se déplacent dans les
allées de l’entrepôt (Figure 2), constituent une
commande ou une palette, déposent celle-ci sur le quai
d’expédition. Il arrive que des déplacements en chariot
soient interrompus par des encombrements ou des
circulations dans les allées. Les emplacements des colis
peuvent également ne pas être approvisionnés. Dans ces
deux situations, l’activité est suspendue.
Figure 1: Préparateur de commandes en cours de prélèvement
de colis
Afin d’accéder à une compréhension de la situation de
travail, nous avons procédé à l’analyse :
x de la tâche à réaliser,
x du ressenti des préparateurs en termes de stress, de
fatigue, de satisfaction,
x des contraintes temporelles, mentales, hiérarchiques
qui pèsent sur le préparateur,
x du collectif de travail (constitution des équipes,
répartition du travail, du relationnel).
METHODOLOGIE
Le recueil des données d’analyse de l’activité a mis en
oeuvre différentes méthodes :
x Des observations directes et instrumentées (vidéo,
audio et mesures physiques) quantifiaient l’activité des
préparateurs de commandes. 10 préparateurs ont
participé à cette phase d’enregistrement et ont été
sélectionnés sur des critères d’âge, d’ancienneté et de
volontariat. L’enregistrement comprenait la réalisation
de plusieurs commandes. Des données audio, relatives
aux échanges entre le système de guidage vocal et les
préparateurs, ont également été recueillies.
x Des entretiens libres ont été conduits pour
comprendre le fonctionnement de la plate-forme ainsi
Figure 2 : L’entrepôt et une allée
Analyse de l’activité : une activité segmentée, brève
et répétitive
Nous avons découpé l’activité des préparateurs de
commandes en sous activités : arrêt sur chariot, attente
de ré-approvisionnement en colis des emplacements
222
(picking), déplacement avec le chariot, réalisation de
palette et catégorie « autre » (opérations telles que
l’édition d’étiquettes, la prise de palette, la dépose de la
palette sur le quai d’expédition, les dysfonctionnement
important de la communication avec la vocale). On
considère que chaque sous-activité se termine lorsqu’une
autre commence.
x déplacement à pied vers le poste de conduite et
départ avec le chariot ou déplacement vers un autre lieu
de prélèvement de colis.
Répartition temporelle des sous-activités
Le tableau 1 montre que la répartition temporelle des
sous-activités pour les 10 préparateurs se décompose de
la manière suivante :
x 50% du temps est consacré à la réalisation de la
palette elle-même,
x 43% du temps d’activité se passe en déplacement
avec le chariot,
x un temps résiduel (7%) est alloué à des sousactivités annexes : arrêt sur chariot (3%), attente de réapprovisionnement du picking (1%) et catégorie
« autre » (3%).
Arrêt sur chariot
Durée en%
Fréquence en %
3%
5%
0
20
40
60
80
Durée en secondes
Sous-activités
Deplacement avec chariot
Attente de colis
Arrêt sur chariot
Réalisation de la palette
Autre
Figure 3 : Illustration de 80 secondes d’enchaînement de sous
activités pour un préparateur (n°10) (extrait des observations
instrumentées)
Analyse du Système Technique : le guidage vocal
Architecture et fonctionnement technique du système vocal
Le système vocal dispose d’un vocabulaire limité de
phrases et de fonctions enregistrées. Ce système repose
sur des technologies de reconnaissance vocale mono
locuteur. L’empreinte vocale réalisée par les préparateurs
est réalisée en situation réelle de travail. Elle se compose
des 40 mots utilisés (chiffres de 0 à 9 et les fonctions
utilisables). Le taux d’erreurs du système (absence de
traitement du message, traitement erroné) est faible
(6%). Le guidage est assuré par un « talkman » et le
logiciel de gestion d’entrepôt AS400.
1%
4%
Attente colis
Déplacement sur
43%
43%
chariot
Réalisation de la
50%
40%
palette
3%
8%
Autre
Tableau 1: Répartition des sous-activités en pourcentage de
fréquence et en durée (10 préparateurs)
Ces données illustrent également les différences entre
répartition temporelle et fréquentielle. Certaines sousactivités sont répétées fréquemment avec des durées très
brèves : les activités annexes, par exemple (arrêt, attente,
autre), représentent 17% des événements enregistrés
alors que leur durée n’est que de 7% du temps total
d’enregistrement. Ceci exprime une segmentation de
l’activité des préparateurs illustrée par la Figure 3. Celleci montre la brièveté de chaque sous-activité (chaque
symbole correspond à 2 secondes) et leur enchaînement
temporel.
Figure 4 : Deux opérations de réalisation de palette
Le talkman (Figure 5) est un boîtier porté à la ceinture
du préparateur. Ce boîtier est composé d’un casque et
d’un micro qui assurent les échanges entre le préparateur
et le système vocal. Il permet de régler l’intensité et la
vitesse d’élocution des messages émis par le système de
guidage vocal.
Plusieurs opérations très brèves en parallèle
La sous-activité « réalisation de palette » (Figure 4) peut
également inclure plusieurs opérations (le filmage de la
palette, une ou plusieurs prises de colis, des
arrangements de colis…).
Si l’on considère l’opération de prise-dépose, on observe
qu’elle dure en moyenne 12 secondes pour l’ensemble
des préparateurs et nécessite la succession d’étapes
suivantes :
x déplacement à pied (du chariot vers le « picking »),
x saisie du (ou des) colis à prélever (éventuellement
une station penchée),
x retour à pied vers les fourches du chariot,
x dépose du (ou des) colis sur la palette posée sur les
fourches (éventuellement station penchée),
Figure 5 : Le talkman
223
bruit du moteur du chariot, bruit de la dépose de la
palette sur les fourches du chariot, circulation des
chariots, filmage de la palette, présence des autres
préparateurs. Cet environnement sonore induit des
interprétations erronées du système qui peut considérer
ce bruit comme un message du préparateur.
En début de commande, le préparateur active le talkman
qui se connecte par voie radio au logiciel d’entrepôt. La
commande est alors chargée sur le talkman.
En cours de commande, le déroulement normal des
échanges est le suivant :
x le système fournit l’adresse à laquelle le préparateur
doit se rendre pour prélever des colis (l’adresse contient
une indication de zone et un numéro d’allée ; voir les
deux premières lignes de l’échange en Figure 6),
x le préparateur valide cette adresse (ligne 3, Figure 6)
en donnant un code de validation (code détrompeur
spécifique à chaque adresse),
x la validation de l’adresse donne accès aux quantités
de colis à prélever à cette adresse (ligne 4, Figure 6),
x le préparateur prélève le nombre de colis indiqué par
le système et valide le prélèvement en rappelant la
quantité prélevée (ligne 4, Figure 6),
x l’adresse suivante est fournie au préparateur (toutes
les informations de zone, allée, emplacement, niveau
sont indiquées sur une étiquette positionnée à chaque
emplacement).
TALKMAN
Zone Alpha
Allée 11
PREPARATEUR
OK
OK
Emplacement 108
9…3 (code détrompeur)
Prenez 2 colis
2 OK
Emplacement 231 niveau
0
1…0
Performances avec l’utilisation du système vocal
Globalement, les objectifs de l’entreprise liés à
l’introduction du guidage vocal sont remplis. Une
augmentation de 15% de la productivité de l’entreprise a
été enregistrée entre juin 2003 et juin 2004. Ce gain a été
renforcé par une diminution du nombre d’inversions, de
suppressions ou d’ajouts de colis dans les commandes.
Avant l’introduction du guidage vocal, les erreurs de
préparation correspondaient à 0,8% des colis préparés.
Elles représentent actuellement seulement 0,16%.
Effets de l’utilisation
préparateurs
de
la
vocale
sur
les
L’augmentation de la production est également vécue
comme un point positif par les préparateurs de
commandes. En effet, la prime de rendement peut
atteindre 1/3 de leur salaire. Cette augmentation de la
production correspond, en moyenne, à une augmentation
de 25 colis par heure et par préparateur.
Cependant, il existe également un coût humain lié à
l’utilisation de la vocale, que nous avons pu estimer
grâce aux questionnaires, aux évaluations subjectives (24
préparateurs)
et
aux
auto-confrontations
(10
préparateurs).
Fatigue physique
La majorité des 24 préparateurs considère que
l’utilisation du guidage vocal n’a pas modifié leur
appréciation de la fatigue physique. Pourtant, on note
que 17% des préparateurs estiment que leur fatigue
physique est plus importante depuis l’introduction du
guidage vocal, alors que seulement 8% des préparateurs
considèrent qu’elle est moins importante du fait de la
suppression de tâches liées à l’étiquetage des colis, au
port et au maniement du listing.
Même si la fatigue physique déclarée reste
majoritairement inchangée depuis l’utilisation du
guidage vocal, les évaluations subjectives des 24
préparateurs montrent que cette fatigue existe. Les
résultats indiquent que 66% des préparateurs ressentent
une fatigue, au moins modérée, dans le dos et les jambes
en fin de poste. Les critères d’âge et d’ancienneté
apparaissent peu discriminants en ce qui concerne cette
évaluation et ceci, quelles que soient les parties du corps
concernées.
Nous avons analysé les données d’évaluation subjective
en fonction d’un critère de productivité individuelle en
classant les 24 préparateurs selon leur rendement. Deux
groupes de mêmes effectifs ont été établis :
x un groupe qualifié par une « forte » productivité
(209 colis par heure en moyenne),
x un groupe qualifié par une « faible » productivité
(167,4 colis par heure en moyenne).
Figure 6 : Exemple d’échanges entre le talkman et un
préparateur pendant la réalisation d'une commande
Exposition aux émissions sonores du système de guidage
Pour évaluer l’exposition des préparateurs au système
vocal sur une journée de travail de 7 heures, nous avons
considéré que le système fonctionnait et émettait de
manière identique pour l’ensemble des 10 préparateurs.
Nous avons envisagé les 12 heures d’enregistrement
obtenus lors de notre intervention comme un flux
continu uniforme. Nous avons appliqué ensuite une règle
de proportionnalité. Par exemple, on considère que si en
12 heures, le nombre de message émis par le guidage
vocal est de 1200, il sera de 700 sur 7 heures de travail.
Ce mode de calcul a permis de montrer que les émissions
du système vocal représentaient 37 minutes et 47
secondes sur 7 heures de travail, soit moins de 9% du
temps. Durant ce temps, le système est intervenu 2954
fois et les interventions ont duré en moyenne 0,8
secondes.
Les interventions du système ont consisté en des
indications d’adresses et de quantités de colis (62%) et
ont été majoritairement émises durant la phase de
« réalisation de palette » (64%). Ces interventions se
déroulaient dans un environnement sonore perturbé :
224
estiment que la communication entre préparateurs s’est
détériorée depuis l’utilisation de la vocale.
A l’attention nécessaire pour comprendre les messages et
au nombre limité des communications avec les
collègues, s’ajoutent des difficultés dans les échanges
entre préparateurs et système vocal. L’analyse des
échanges montre que sur une journée de 7 heures (voir la
méthode de calcul utilisée dans le paragraphe Exposition
aux émissions sonores du système de guidage), les erreurs
ou difficultés suivantes ont été détectées :
x 195 erreurs de perception par le système de guidage
(6% des émissions du système de guidage),
x 82 demandes de répétition des instructions par le
préparateur (moins de 3% des émissions des
préparateurs),
x 24 difficultés de chargement de la commande sur le
talkman,
x 468 signaux d’interférence (Bip) émis par le
système.
Le taux d’erreurs de compréhension par le système de
guidage vocal est cependant faible (6% soit 2 minutes 30
cumulées sur une journée de travail et l’ensemble des
préparateurs) compte tenu de l’environnement bruité
dans lequel évoluent les préparateurs.
La productivité standard dans l’entreprise étant de 175
colis par heure et par préparateur, on peut considérer que
le premier groupe a une productivité moyenne supérieure
de 20% au standard alors que le second groupe a une
productivité moyenne inférieure de 4%.
66% des préparateurs du groupe 1 ressentent une fatigue
au moins modérée dans le cou, alors que tous les
préparateurs du groupe 2 déclarent ressentir peu de
fatigue physique.
Fatigue nerveuse
Les réponses au questionnaire (24 préparateurs)
montrent que 64% des préparateurs (Figure 7) estiment
que les efforts attentionnels nécessaires à la réalisation
de leur travail ont augmenté depuis l’utilisation du
guidage vocal. Les données d’auto confrontations
indiquent que ces efforts attentionnels porteraient
essentiellement sur la nécessité de mettre en place des
stratégies de régulation et d’anticipation.
beaucoup
plus
4%
NR
13%
un peu moins
8%
ca n'a pas
changé
17%
Irritabilité et plaintes
Les entretiens et les auto-confrontations établissent que
les 10 préparateurs considèrent les erreurs comme
pénibles et irritantes, car ils estiment que leur travail est
de préparer les commandes et non de récupérer les
dysfonctionnements du guidage vocal (Figure 8). Cette
irritabilité est également rapportée dans le
questionnaire : 40% des 24 préparateurs déclarent être
fréquemment irritable en fin de journée de travail (soit
plusieurs fois par semaine).
un peu plus
58%
Figure 7 : Répartition des réponses des 24 préparateurs au
questionnaire à la question « Pensez-vous que votre travail
demande de l'attention depuis la mise en place du guidage
vocal? »
Représentation de la tâche
Un guidage « pas à pas » ne permet pas aux préparateurs
de se constituer une représentation globale de la
commande. Par exemple, ils ne peuvent prévoir la
constitution de cette commande : est-elle composée de
beaucoup de colis de même forme ? Les derniers colis
sont-ils volumineux ou lourds ? Sans ces informations,
les préparateurs sont contraints de réorganiser leur
palette (10% du temps total de réalisation des palettes
des 10 préparateurs). Cette réorganisation constitue un
élément de régulation corrective de l’activité (rétablir
une stabilité défaillante) et (ou) anticipatrice (préparer la
palette à recevoir le colis).
« Il y a des gens qu’on pense être super calme et depuis
la vocale, ils sont vachement à cran. Ça irrite d’avoir
cette vocale : on a un rendement à faire et si la vocale
ne comprend pas, qu’il faut répéter 10 fois alors
qu’avant on s’est dépêché pour gagner du temps et
qu’on est en train de tout perdre. Nous on dit le bon
truc et elle ne comprend pas. Au bout d’un moment ...
c’est fatiguant. »
Figure 8 : Extrait de l’auto confrontation d’un préparateur
Une gestion contrainte
Les problèmes de niveau sonore ambiant ou
d’identification des préparateurs par le système vocal
obligent le préparateur à lancer une procédure de mesure
du bruit de fond ou d’enregistrement de l’empreinte
vocale en cours de commande. Ces procédures sont
brèves (quelques secondes) mais ces quelques secondes
contribuent à l’irritabilité des préparateurs, car elles sont
considérées comme des pertes de temps subies. Le
préparateur est forcé de réaliser ces procédures sous
peine de devoir répéter plusieurs fois les mêmes données
pour une prise en compte par le système.
Les échanges et leurs traitements
La gestion des consignes données par la vocale se fait en
parallèle aux autres opérations. Le guidage vocal
contraint les préparateurs à être attentifs aux messages
car ceux-ci sont brefs. Les préparateurs se dispensent de
parler
à
leurs
collègues
pour
éviter
un
dysfonctionnement du système. En effet, toute parole du
préparateur est considérée comme un signal devant être
interprété par le système. Ainsi, des interventions
comme « Bonjour » ou « Ça va Seb. ? » sont interprétés
par le système comme « Retour » ou « 1…7 ». L’analyse
du questionnaire montre que 84% des préparateurs
225
l’entreprise a constaté cette augmentation et a souhaité
l’encadrer en plafonnant la prime de rendement des
préparateurs. La prime de rendement n’augmente plus au
delà de 240 colis par heure et par préparateur.
Les transformations introduites par l’utilisation du
guidage vocal apparaissent importantes au niveau mental
pour les préparateurs. Celles-ci sont de plusieurs types :
x gestion en parallèle des messages émis par la vocale
et d’autres opérations,
x exigences d’attention aux messages de la vocale car
ceux-ci sont brefs,
x mise en place de procédures de gestion des échanges
avec le système, adaptées au niveau sonore ambiant et à
l’identification des préparateurs par le système vocal,
x limitation des échanges verbaux entre préparateurs
liée aux risques de mauvaises interprétations par le
système,
x absence ou insuffisance d’informations qui
contribuent à construire une vision globale de la
commande.
Ces exigences et contraintes apparaissent subies par les
préparateurs. Elles sont considérées également comme
consommatrices de temps et d’attention.
Afin de compenser l’insuffisance d’information
permettant d’avoir une vision de la commande, les
préparateurs mettent en place des stratégies de régulation
basées sur différentes hypothèses :
x Hypothèses issues de connaissances générales sur :
¾Le fonctionnement global et habituel de
l’entrepôt. Par exemple : les commandes du mercredi
matin sont d’un certain type ; la commande en cours
devrait s’en approcher,
¾La constitution des commandes de la journée.
Par exemple : depuis deux heures, toutes les commandes
commencent dans l’allée 6 et se terminent dans l’allée
19. Les parcours suivants dans les allées et les prises de
colis ont des chances d’être du même type,
¾La connaissance du client. Par exemple : ce
client fait habituellement des commandes d’un certain
type de produits en grande quantité ; il faut donc prévoir
de la place sur la palette pour ce type de colis,
x Hypothèses élaborées à partir de l’état d’avancement
de la commande : les colis de cette commande sont
demandés en multiples ou les colis se répartissent dans
des allées distantes, les prises de colis devraient donc se
dérouler selon le même schéma par la suite,
x Hypothèses élaborées à partir des derniers colis
prélevés.
Les stratégies d’anticipation mises en œuvre consistent à
valider à l’avance certaines des informations et
consignes données par le guidage vocal. Ainsi, les
préparateurs peuvent valider jusqu’à 3 emplacements
d’avance. Cette validation anticipée semble efficace,
mais risquée et coûteuse. En effet, elle permet au
préparateur d’optimiser le positionnement des colis sur
la palette (stabilité), le circuit de déplacement avec le
chariot et d’assurer un rendement individuel élevé. Mais,
elle augmente les risques d’erreurs dans les prises de
Une gestion anticipative
Afin de réduire les dysfonctionnements, les préparateurs
limitent leurs communications avec les collègues et
utilisent différentes stratégies d’échange avec le guidage
vocal :
x ils éteignent le talkman lors du déplacement avec le
chariot ou du filmage de la palette (66 extinctions pour
les 10 préparateurs sur une journée de travail) afin
d’empêcher toutes perturbations sonores du système de
guidage,
x ils utilisent la fonction « Répéter » après, ou durant,
un événement potentiellement perturbant pour le
système vocal (185 répétitions pour les 10 préparateurs
sur une journée de travail). Cette fonction permet de
relancer la dernière information fournie par le système
et ainsi, d’initialiser la réponse du préparateur. Cette
fonction est détournée de son rôle initial. Les erreurs ou
dysfonctionnements
sont
considérés
comme
suffisamment pénalisants pour que les préparateurs
mettent en place des moyens d’éviter ces perturbations
en détournant le fonctionnement prévu.
CONCLUSION ET DISCUSSION
Ce travail a montré que l’activité de préparation de
commandes était composée d’une succession de sousactivités et d’opérations fréquentes et très brèves.
L’activité du préparateur est donc une activité plus
segmentée que l’on pouvait le penser a priori.
Avec l’introduction du guidage vocal, l’entreprise et les
préparateurs ont réalisé des gains de productivité
importants. Cette productivité accrue contribue
probablement à la brièveté et la segmentation des
opérations que nous avons observées. Toutefois,
l’intensification de ces opérations du fait de leur brièveté
pourrait également découler d’un aménagement différent
du temps choisi par les préparateurs ou contraint par la
nouvelle organisation (une étude comparative est en
cours. Elle vise à comparer la préparation de commandes
avec et sans guidage vocal).
L’accroissement de la productivité nous a conduits à
nous intéresser au coût physique et mental de
l’utilisation du guidage vocal. Sur le plan physique, il
faut rappeler que la préparation de commandes est une
activité de manutention. Celle-ci engendre donc des
sollicitations physiques, qu’il y ait ou non recours au
guidage vocal. Globalement, depuis l’introduction de ce
guidage, les efforts physiques fournis ont peu évolué.
Néanmoins, les résultats concernant les relations entre
fatigue musculaire et productivité des préparateurs sont
intéressants. Ils montrent qu’une productivité importante
amène à ressentir la fatigue de façon plus marquée
qu’avec une productivité faible. Ceci est clair sur les
parties du corps fortement sollicitées par l’activité
physique : cou, jambes et dos. Ce constat n’est pas
original, mais semble indiquer que le niveau de
productivité des préparateurs influe sur le ressenti de la
fatigue musculaire. Cette question est d’autant plus
importante que le guidage vocal accompagne une
augmentation de la productivité. Il est à souligner que
226
colis ainsi que la charge de travail. En effet, une
mémorisation est nécessaire, et cette stratégie contribue à
supprimer les possibilités de récupérer ces informations
en cas d’oubli. Le coût élevé de la stratégie est évident
pour les préparateurs puisqu’ils ne la mettent en place
que lorsqu’ils se considèrent en forme et très concentrés
(Figure 9).
physiques de prise-dépose des colis. La mise en place
de racks dynamiques, par exemple, permettrait aux
préparateurs de prélever les colis en bord de palette et
limiterait ainsi les contorsions ou postures éprouvantes.
x Une réflexion sur l’organisation de la production est
à étudier afin de fournir aux préparateurs des moyens
de réguler leur activité (par exemple, des informations
sur la constitution de la palette, l’allée de fin de
commande, indication et la localisation des colis
volumineux ou en grande quantité).
Ce travail nous a permis d’accéder à un premier niveau
de compréhension des effets de l’utilisation du guidage
vocal sur l’activité des préparateurs de commandes. Une
étude comparative reprenant la même méthodologie et
les mêmes outils d’analyse est actuellement en cours sur
la même tâche réalisée sans guidage vocal. Elle devrait
amener des résultats complémentaires sur la
segmentation des opérations et leur brièveté, la fatigue
nerveuse et physique, et la mise en place de la
représentation de la commande.
« Les anticipations même d’un ou deux codes ; un matin
crevé, non, ou un vendredi après midi, non plus, mais
sinon…. Il faut quand même que ce soit des jours de
forme ».
Figure 9 Extrait de l’auto confrontation d’un préparateur
Cette stratégie est cependant reconnue par les
préparateurs pour les gains qu’elle apporte au niveau :
x de la production, donc de la prime de rendement,
x du ressenti (fatigue, satisfaction au travail).
Elle contribue également à donner aux préparateurs
l’impression d’une certaine autonomie par rapport au
système de guidage. Les préparateurs ont quelques fois
le sentiment d’être des automates qui suivent le système
vocal. En prenant le système de vitesse, ils ressentent
une satisfaction à tricher avec la machine et ont ainsi
l’impression de retrouver un peu d’humanité.
D’autres préparateurs utilisent cette stratégie pour
s’aménager des temps de pause supplémentaires tout en
conservant un rendement acceptable.
Lors de nos premières interventions dans l’entreprise, fin
2004 (soit moins d’un an après l’introduction de la
vocale), les préparateurs exprimaient, dans les entretiens
et observations libres, une satisfaction évidente à
l’utilisation du guidage vocal. Ils indiquaient que celui-ci
leur permettait d’augmenter leur productivité ainsi que
de faciliter la manutention des colis (plus de listing à
consulter ou à porter…). La perception de l’utilisation du
guidage vocal s’est fortement dégradée avec le temps
comme le montrent les résultats présentés. La CRAM
Rhône-Alpes mène actuellement un travail sur ce même
sujet de prévention et a mis en évidence des résultats
proches de ceux obtenus fin 2004. Le « turn over » des
préparateurs en région Rhône-Alpes est cependant plus
important. Ils restent dans ces entreprises moins d’une
année, ce qui correspond à la durée d’exposition de nos
préparateurs à la fin 2004. La durée d’exposition au
système de guidage semblerait être un élément important
dans la dégradation du ressenti des opérateurs.
BIBLIOGRAPHIE
1.
2.
3.
4.
5.
6.
7.
PERSPECTIVES
Des restitutions intermédiaires, réalisées auprès de
l’entreprise et de la CRAM des Pays de la Loire, ont
permis de suggérer quelques pistes de prévention :
x Des améliorations technique du système de guidage
vocal sont à envisager afin d’améliorer les échanges
entre le préparateur et le système, et de limiter les
erreurs ou difficultés de compréhension.
x Les agencements des zones de prélèvement des colis
ou l’utilisation de chariots à fourches mobiles (fourches
positionnables à la hauteur de la dépose des colis)
pourraient être considérés afin de limiter les efforts
227
Arnal, P. Quel impact de l’évolution de
l’informatisation de la chaîne logistique ? D’une
logique segmentée à une logique de gestion globale,
Le journal du Net, 23 février 2004, site
http://solutionsjournaldunet.com/0402/040223_scm.
shtml.2004
Benbouali, S. Conception des plates-formes
logistiques non-réfrigérées alimentaires, Mémoire
de prévention, Formation des ingénieurs conseils,
CRAM Languedoc Roussillon, année 2003-2004,
39.p.
Borg, G. Aspects subjectifs de la charge physique et
mentale. Le Travail Humain, tome 40, n°. 2, 1977,
pp. 225-232.
Borg, G. Borg's range model and scales. J. Sport
Psychol., 32, 2001, pp. 110-126.
Hamant, S. & Radocchia, N. NTIC, Flexibilité et
transformation du travail : le cas de France
Télécom. Mémoire de DESS Universités de Metz et
Nancy 2, 2001.
Muhlmann, D. Des nouvelles technologies à l’image
des vieilles organisations. Sociologie du travail,
n°.43, 2001, pp 327-347.
Vendramin, P. Les TIC, complices de
l’intensification du travail. In Actes du Colloque
« Organisation, intensité du travail, qualité du
travail », Paris, 21-22 novembre 2002.
Démarche centrée utilisateur, intégrée dans la conception d'un DEmonstrateur de Vision INdirecte (DEVIN)
Laurence KUJAWA
Giat Industries
Direction Technique Systèmes
11, allée des Marronniers 78022 Versailles Cedex
[email protected]
RESUME
odology, applied by human factors experts of the Giat
Industries company. This paper describes this methodology and gives an illustration of Human Factors Engineering (HFE) : processing ergonomic conception,
methodological framework for collecting and analysis
data, human factors documentation …
Depuis plusieurs années, Giat industries conçoit des démonstrateurs technologiques, dans le but de préparer,
notamment au profit de la DGA (Délégation Générale
pour l'Armement), les futurs véhicules terrestres militaires. Un des principaux objectifs dans la conception des
blindés futurs est l'augmentation de la protection des
membres d'équipage tout en maintenant les performances du système. Une solution "prometteuse" est la délocalisation des postes opérateurs, actuellement situés en
tourelle, vers des postes en châssis. Cette solution impacte fortement les futurs utilisateurs en termes de réorganisation de l'activité, modification des contraintes et
exigences de la tâche… Ces problématiques sont appréhendées dès les phases amont du projet DEVIN en positionnant, dans l'équipe intégrée, un ergonome responsable de la prise en compte des aspects facteurs humains.
Cet article a pour objectif de montrer comment les aspects facteurs humains sont intégrés dans le projet
DEVIN. Il précise notamment les types d'études, les résultats obtenus et les résultats attendus quant à l'évaluation avec les utilisateurs finaux de la solution préconisée,
au regard des objectifs techniques de l'étude qui consistent à valider de nouveaux principes de conception des
postes opérateurs de véhicule blindé.
KEYWORDS : User-centred approach, design process,
man-machine interface new solutions, tasks organisation
evolution, crew members station, DEVIN.
INTRODUCTION
Dans le cadre des programmes militaires terrestres futurs, les groupements étatiques, ainsi que les industriels
de l'armement terrestre, mènent des réflexions
complémentaires et conjointes sur l'évolution de
l'architecture des plates-formes militaires terrestres. Ces
réflexions sont la conséquence des besoins exprimés en
termes de protection de l'équipage face à des menaces de
plus en plus agressives, de réduction de masse des
véhicules afin d'assurer l'aérotransportabilité, ainsi que
de furtivité des silhouettes dans un souci de non
détection par des systèmes adverses.
A l'heure actuelle, une plate-forme militaire terrestre est
traditionnellement composée de deux parties complémentaires (voir la figure 1): un châssis dans lequel se
trouve un opérateur (le pilote) et une tourelle orientable
sur 360°, à l'intérieur de laquelle travaillent en binôme
un chef et un opérateur tourelle. En réponse aux besoins
exprimés par les instances étatiques, Giat Industries est
en charge d'étudier, un nouveau véhicule basé sur le
concept de tourelle inhabitée (voir la figure 1). Ce
concept implique notamment :
MOTS CLES : Démarche centrée utilisateur, processus
de conception, démonstrateur technologique, évaluation
de poste équipage, DEVIN.
ABSTRACT
During the past few years, Giat Industries is integrated
into the conception of several technology demonstration
programs mainly for the French defence procurement
agency (DGA). The main aim is to prepare the future
armoured vehicles. One of the most challenging issues,
is to obtain an optimal crew protection while maintaining performances. A promising solution is to confine the
crew inside the hull. This solution is really significant
and involves crew activity of military system, and their
way of work in terms of : evolution of tasks, requirements and constraints of realisation, capabilities and limits of the human operator, new solutions of HMI. These
questions are taken into account by "user-centred" meth-
-
-
229
une délocalisation des opérateurs actuellement situés
en tourelle (le binôme chef / opérateur tourelle) vers
des postes situés en châssis,
une téléopération de la tourelle par les opérateurs depuis le châssis,
une perte de la vision directe habituellement utilisée
par les opérateurs en tourelle, avec une remise en
cause des moyens de vision habituels (occultation
des épiscopes),
-
une nouvelle allocation de tâches au sein de l'équipage,
l'intégration de nouvelles habitudes de travail associées à l'utilisation de certaines technologies plus ou
moins maîtrisées par les opérationnels.
-
Opérateurs en tourelle
Opérateur en châssis
L'environnement observé par les opérateurs se distingue
de par sa profondeur : un environnement proche (appréhension de l'environnement immédiat) et un environnement lointain (détection de menaces et d'objets extérieurs). Ces tâches sont à réaliser sur un secteur de 360°,
à site horizontal variable, en quasi instantané, dans un
environnement varié, notamment urbain. Actuellement,
ces tâches sont réalisées par l’intermédiaire de moyens
optiques classiques (épiscopes de grossissement 1). Pour
un système militaire terrestre, la perception représente
une capacité fondamentale du système (Réf. [3] et [6]).
Architecture classique
© Giat Industries 2006
de détecter, reconnaître et identifier la présence d'objets et d’agressions extérieures,
d'appréhender l’environnement général du compartiment de terrain et du système afin de pouvoir se situer par rapport aux amis et aux éléments remarquables du terrain (routes, bâtiments, végétation....), décider et coordonner les actions, diriger le déplacement du véhicule, assurer la navigation, prendre les
décisions de commandement.
Concept de tourelle inhabitée
Délocalisation des opérateurs
La délocalisation des opérateurs de la tourelle vers le
châssis permet d'augmenter et d'améliorer les échanges
et le partage d'informations au sein de l'équipage. Par
contre, il devient impossible de conserver une vision directe optimale sur l'environnement extérieur. Cette limitation a des conséquences physiologiques et cognitives
non négligeables sur la perte de référence des opérateurs
par rapport à l'environnement proche dans lequel le véhicule évolue.
Tous les opérateurs en châssis
Figure 1 : Architecture classique vs tourelle inhabitée
La finalité de ce projet est la réalisation d'un démonstrateur technologique (DEVIN – DEmonstrateur de Vision
INdirecte) qui a trois objectifs principaux : 1/ identifier
une architecture de perception permettant d'assurer les
fonctions liées à l'observation, pour un équipage délocalisé en châssis, 2/ vérifier que les performances de ces
fonctions sont suffisantes pour rendre le concept déporté
techniquement pertinent et opérationnellement viabl, et
3/ évaluer les conséquences physiologiques et cognitives
de la délocalisation sur les membres d'équipage. Au regard des problématiques énoncées, trois axes d'études
d'ergonomie sont proposés:
-
La première problématique traitée au cours de cette
étude est l'impact de l'intégration de moyens de vision
indirecte sur la tâche d'observation des opérateurs. En effet, il s’agit d’une évolution importante de la mise en
oeuvre de cette fonction qui ait apparaître certaines
contraintes dimensionnantes qu’il est nécessaire de
considérer lors de la définition des interfaces opérateurs,
afin d’en réduire les effets négatifs sur l’efficacité opérationnelle du véhicule (et / ou sur la mise en oeuvre de
ces fonctionnalités). Il s'agit, pour les opérateurs habituellement localisés en tourelle, d'une totale remise en
cause de leurs habitudes de travail et des moyens utilisés
pour l'acquisition de l'information extérieure (exemples :
la perte de la voie directe optique utilisée pour
l’observation, la détection et la reconnaissance d'objets
extérieurs, la perte de la sensation du mouvement de
l’arme en tourelle…).
axe 1 : impact de la délocalisation des opérateurs de
la tourelle vers le châssis,
axe 2 : intégration de nouvelles fonctionnalités et assistances à l'opérateur,
axe 3 : redéfinition des IHM.
Intégration de nouvelles fonctionnalités
Rappel sur la fonction perception / observation
L'intégration de toute nouvelle fonctionnalité au sein
d'un système militaire terrestre impacte fortement l'activité des opérateurs au sein du véhicule. En effet, ces
nouvelles tâches insérées en plus de leur activité connue
et maîtrisée viennent solliciter l'attention des opérateurs.
Ces évolutions se traduisent le plus souvent par une re-
Pour les opérateurs de systèmes militaires terrestres, observer consiste à surveiller l'environnement extérieur en
vue :
230
mise en cause de l’organisation classique des fonctions
où le partage des rôles entre la composante technique et
la composante humaine était jusqu’alors clairement maîtrisé.
processus au demeurant classique, constitue un référentiel commun à tous les acteurs d'un projet.
Analyse et
clarificatio n du
besoin
La seconde problématique traitée au cours de cette étude
est une réflexion sur une nouvelle répartition des tâches
entre les binômes "Chef x Opérateur tourelle" d'une part
et "Système x Opérateurs" d'autre part. En effet, la prise
en compte de nouvelles fonctionnalités introduit une réflexion sur l'intégration possible de nombreuses aides et
assistances permettant d'améliorer l'efficacité du couple
homme-machine. Ces réflexions portent notamment sur
le niveau d'assistance à mettre en œuvre et tentent de répondre à la question suivante : Quelle place doit occuper
l'opérateur dans la mise en œuvre de son système et / ou
dans les prises de décision ?
Spécification d u
beso in et choix
de concept
RDL
RDL Revu e d e Déc isio n de Lance men t
Développement
RDP
Q ualification
définitive
Q ualification
interne
RCD
RQI
R CPA
RDP: Rev ue de Dév el op pement Prél iminai re
RCD : Rev ue Critique de Dév eloppe ment
RQI: Revu e de Qu ali ficatio n In terne
RCPA : Revue Crit iq ue d es Pre mie rs Art icle s
Figure 2 : Processus E&D de Giat Industries
Démarche ergonomique
La démarche centrée utilisateur, proposée par le pôle ergonomie en charge des études de conception de postes
opérateurs (composantes cognitive et physique), est pleinement intégrée au sein du processus industriel d'Etude
et Développement, au même titre que les processus des
autres métiers contributeurs (ingénierie système,
architecture mécanique, logiciel…). La méthodologie se
base sur une démarche classique de conception ergonomique nominale qui s'applique à tous les projets et études générales comportant une tâche de conception de
poste utilisateur, de systèmes d'aide à la décision ou plus
généralement d'IHM. Afin de permettre à la démarche
ergonomique d'être naturellement intégrée dans le processus général de conception mis en œuvre au sein de
Giat Industries, sont identifés pour chaque phase de ce
processus, les différents points d'interventions ergonomiques et d'échanges avec les autres métiers contributeurs (voir la figure 3).
Redéfinition des IHM
Les innovations relatives aux dispositifs de saisie et
d’accès à l’information, aux systèmes d’aide à la décision, sont autant de moyens susceptibles de contribuer à
la définition de nouvelles architectures de postes opérateurs. Par contre, l'introduction d’équipements non encore banalisés dans un environnement blindé, comme
par exemple un écran classique et / ou tactile, peut entraîner des difficultés dans leur mise en œuvre par les
opérationnels.
La troisième problématique traitée au cours de cette
étude est l'impact de l'intégration d'équipements identifiés comme novateurs par les opérateurs actuels de véhicules blindés. Leur intégration peut entraîner des modifications importantes dans la façon dont les opérateurs
vont réaliser leur activité (la finalité de l'activité reste
identique, par contre les moyens et la procédure d'utilisation pour arriver à cette finalité sont profondément modifiés).
A nalyse et
clarification du
bes oin
Spécification du
besoin et choix
de concept
R DL
D évelop pemen t
R DP
Qualification
interne
RC D
Etape descendante d'analyse
R QI
Qualificatio n
définitive
R CPA
Etape ascendante
d'intégration des solutions
Anal yse de
l'activité
Acqui sition du
retour
d'expéri ence
Spécifi cation des IHM
Spécifi cation
des postes
INTEGRATION DES FACTEURS HUMAINS
Justification des choix
de conception
Avant de présenter les résultats de l'intervention ergonomique appliquée pour répondre aux problématiques
du projet DEVIN, il est intéressant de montrer comment
les aspects facteurs humains sont intégrés dans le processus général de conception des systèmes militaires terrestres de Giat Industries.
Particip ation à l a
qualification du
produit
Suivi du
développement
Etape de recherche de solutions
Figure 3 : Démarche de conception ergonomique intégrée dans
le processus Etudes et Développement
Processus Etudes et Développement (Processus
E&D)
Ce processus et cette démarche sont appliqués dans le
cadre du développement de DEVIN. Ils permettent notamment de mettre en place, dès le début du projet, une
équipe intégrée pluridisciplinaire composée d'un
responsable de développement en charge de la cohérence
technique du projet, d'un ergonome garant du respect de
la prise en compte des contraintes de conception liées
aux spécificités des utilisateurs, d'un architecte système
en charge de la définition de l'architecture fonctionnelle
du démonstrateur, d'un informaticien en charge de la dé-
La démarche de conception industrielle suit un processus
général d'études et de développement mis en place au
sein de Giat Industries (voir la figure 2). Ce processus
est jalonné de points de rencontre (revues) permettant à
chaque acteur du projet de valider les orientations retenues (architecture système, technologies, architecture
mécanique…) au regard de l'ensembles des données acquises au cours des phases précédentes (et en cours). Ce
231
finition de l'architecture logicielle de DEVIN et des experts en visionique, architecture mécanique, architecture
vétronique1…
L'intérêt de l'imbrication de la démarche ergonomique
classique et du processus Etudes et Développement est
double :
les phénomènes de mal de transport, de claustrophobie,
de désorientation spatiale, de confort (ou de "moindre
inconfort"), de fatigue oculaire et de perte de repère dans
l'espace. En ce qui concerne ces points, le démonstrateur
permettra d’évaluer diverses solutions d'interfaces opérateurs, tant technologiques que basées sur des principes
de formalisation de l'informations.
-
Evaluation des technologies de perception
-
permettre l'intégration d'une démarche centrée
utilisateur au sein des programmes
permettre la mise en place d'un fonctionnement en
ingénierie intégrée
Des études antérieures ont montré que le point prioritaire
à traiter pour exploiter une tourelle "inhabitée", est "l'appréhension du terrain et de la vision proche". DEVIN
tente de répondre à ce besoin en permettant, d'une part,
l'étude d'architectures et d'équipements réalisant la perception en vision proche, et d'autre part, en offrant la
possibilité de vérifier la pertinence opérationnelle d'une
telle architecture. Les solutions préconisées se basent sur
une restitution de l'environnement extérieur via une
chaîne optronique homogène. Différentes technologies
sont utilisées et testées afin de vérifier la pertinence
technique, fonctionnelle et surtout la viabilité opérationnelle des solutions préconisées (exemple : écrans de restitution, visuel de casque, écrans tactiles…).
OBJECTIFS DE DEVIN
DEVIN est un démonstrateur de vision indirecte. Il est
construit sur la base d'un véhicule expérimental nommé
PISE (voir la figure 4) et développé par les Etablissements Techniques d'AngerS (DGA/DCE/ETAS).
PLAN D'ACTIONS
Pour aboutir en final à une solution répondant aux problématiques énoncées, les tâches suivantes sont menées:
Figure 4 : Véhicule expérimental existant - PISE
-
PISE est un banc d'évaluation roulant mis à disposition
dans le cadre du contrat pour permettre l'intégration du
démonstrateur DEVIN. Il est construit sur la base d'un
chenillé dans lequel peuvent être positionnés quatre opérateurs : trois membres d'équipage et un observateur
d'essai.
-
DEVIN est un outil d'évaluation :
-
identifier et spécifier le besoin opérationnel lié à l'observation et la perception,
identifier les technologies s’intégrant dans l'architecture pressentie,
étudier et établir la faisabilité des points durs technologiques,
spécifier et réaliser un démonstrateur fonctionnel,
valider la solution architecturale retenue auprès
d'opérationnels.
intégrer la solution (DEVIN) dans un démonstrateur
plus global (PISE),
évaluer la solution intégrée avec un panel d'utilisateurs représentatif de la future population utilisatrice.
Ainsi, le démonstrateur est limité aux seuls aspects soulevant des problèmes de faisabilité technique et d'utilisation opérationnelle.
des contraintes physiologiques rencontrées par les
utilisateurs des nouvelles technologies de perception,
d'une nouvelle architecture de perception mise en
œuvre par un équipage délocalisé en châssis.
RESULTATS
Besoin opérationnel
Evaluation des contraintes physiologiques
L'analyse du besoin opérationnel est réalisée sur la base
d’une analyse fonctionnelle, complétée par une analyse
ergonomique. Cette dernière, basée sur une démarche
terrain de recueil d'expertise (RETEX), est menée auprès
d'opérationnels du 1er Régiment de Hussards Parachutistes (1er RHP) de retour d'opérations extérieures en
contexte de crise. L'identification du besoin se fait via
l'utilisation de techniques de recueil de données (entretiens individuels, entretien en dynamique de groupe,
auto confrontation des argumentaires). Le recueil réalisé
Le premier objectif de DEVIN est de permettre
l’évaluation de certaines conséquences physiologiques et
cognitives que pose la perception déportée en châssis.
Parmi celles-ci, il s’agit tout particulièrement d’évaluer
1
L'architecture vétronique représente l'infrastructure sur
laquelle viennent se connecter tous les équipements
(électronique, électrique, calculateurs, moyens visionique, etc.) d'un véhicule ou d'un système.
232
lors de cette phase permet d'acquérir des données dimensionnantes et spécifiantes pour la définition des postes
opérateurs. Elles déterminent notamment les principales
recommandations à prendre en compte lors de la conception d'un système militaire terrestre dans un contexte
d'opérateurs déportés en châssis, n'ayant plus accès à la
vision directe comme moyen principal de prise d'information sur l'environnement extérieur.
-
Dans le projet, une synthèse présente les différentes architectures envisagées, et précise les avantages et inconvénients de chacune des solutions au regard de critères d'évaluation multi métiers. Les critères utilisés sont
notamment les suivants : maturité technique, adéquation
au besoin opérationnel, disponibilité immédiate de la
technologie dans un contexte de véhicule blindé, coût,
degré d'acceptation de la technologie par les utilisateurs… Cette démarche permet une validation commune
et partagée des choix définitifs entérinés pour la spécification du démonstrateur DEVIN.
Principaux résultats de l'analyse ergonomique :
-
-
-
-
-
système permettant le calcul de la profondeur à base
de capteurs stéréoscopiques,
système de surveillance 360° aux abords proches du
véhicule (utilisation lorsque le véhicule est à l'arrêt),
techniques de création d'un bandeau virtuel d'images
à partir de plusieurs capteurs indépendants.
nécessité de conserver une vision directe même dégradée (rôle d'aide à l'opérateur pour lutter contre la
claustrophobie et le stress en préservant un accès à la
information réelle, brute et non traitée),
importance de pallier la perte des informations signifiantes de mouvement (sensations existantes dans la
tourelle différentes de celles du châssis) par l'intégration d'aides graphiques et/ou sérigraphiées,
apport de réflexions sur de nouvelles configurations
de postes opérateurs facilitant la proximité et le partage d'informations entre les membres d'équipage,
prise en compte de critères physiologiques et techniques impliqués dans l'activité des opérateurs étudiés
(exemples : taille du champ de vision humain / taille
du champ de vision nécessaire pour observer un théâtre d'opération militaire, type de supports de présentation de l'information, choix de l'implantation de la
chaîne de capture et de restitution de l'information,
apport de la vision stéréoscopique…),
importance de l'intégration d'aides à la perception de
l'environnement extérieur.
Spécifications et développement du démonstrateur
L'analyse du besoin opérationnel et les études technologiques menées en parallèle servent de données d'entrée
aux phases de spécification du démonstrateur DEVIN.
Lors de cette étape, les spécifications techniques et logicielles de DEVIN sont réalisées sur la base d'un cahier
des charges IHM décrivant la spécification ergonomique
des interfaces opérateurs.
Architecture du démonstrateur
L'architecture de DEVIN (voir la figure 5) s'articule autour des points suivants :
-
Etudes technologiques
Les études technologiques réalisées au cours de ce projet
permettent de réaliser, en collaboration avec l'ergonome,
d'une part des études prospectives avec des fournisseurs,
et d'autre part des tests et essais techniques en laboratoire sur des technologies et équipements existants. Ces
études technologiques ont permis de fournir les données
nécessaires en termes de maturité technique et de capacité d'adaptation dans un contexte de véhicule blindé des
technologies étudiées. Combinées au besoin opérationnel, ces données ont notamment servi comme critère
d'aide aux choix des solutions techniques à intégrer dans
le démonstrateur DEVIN.
deux systèmes de vision proche
un système complémentaire de vision lointaine.
Système de visio n
proche 2
Système de vision
lointaine
Système de vision
proche 1
Quelques solutions technologiques étudiées en collaboration avec l'ergonome du projet :
-
système de vision panoramique jour, à base de capteurs (caméras) jour,
système de vision panoramique nuit, à base de capteurs (caméras) fonctionnant en infra rouge,
système multi-caméras sur tourelleau orientable à
360°,
système de visualisation stéréoscopique,
Figure 5 : Architecture du démonstrateur DEVIN
Ces moyens permettent d'étudier attentivement les problèmes de volume de données numériques ainsi que les
débits nécessaires pour disposer d'une fonction observation cohérente avec un besoin opérationnel. Ils permet-
233
tent également d'évaluer les implications liées à l'emploi
d'équipements numériques reliés à une architecture vétronique interne dans le cadre d'études prospectives des
blindés futurs.
graphiques à la localisation de l'opérateur. Les aides
concernent notamment :
-
Poste équipage
L'équipage d'un véhicule blindé classique est traditionnellement représenté par un chef, un opérateur tourelle et
un pilote. Le partage des tâches entre ces trois opérateurs, fait l'objet d'un emploi opérationnel défini et maîtrisé. Dans le cadre de ce projet, les études se focalisent
sur les interactions entre le chef et l'opérateur tourelle.
Les deux postes sont identiques et configurables selon le
rôle de l'opérateur.
la localisation de l'opérateur dans son environnement
tactique (exemple : localisation des menaces potentielles)
la localisation de l'opérateur dans son environnement
proche et position des équipements externes (exemples : position de la tourelle par rapport au châssis,
position et direction des viseurs d'observation…).
Sur les écrans inférieurs, sont notamment présentées :
-
Ecran de commandes
Vision proche
-
Vision lointaine
Cartographie
les informations et commandes de mise en œuvre et
de gestion du système (exemple : gestion des servitudes liées aux capteurs, gestion de la protection de
l'équipage et du système…),
des aides au partage d'informations entre opérateurs
ainsi que des aides redondantes de localisation de
l'opérateur dans son environnement tactique, dans
son environnement proche et de la position des
équipements externes.
© Giat Industries 2004
© Giat Industries 2004
Poste tireur
Poste chef
Figure 6 : Architecture des postes opérateurs
Figure 7 : Organisation des IHM de DEVIN
Les images des équipements de vision proche et lointaine, sont restituées au chef et au opérateur tourelle par
l'intermédiaire de 6 écrans à chaque poste (voir la figure
6), qui servent également de pupitres (écrans tactiles).
Les redondances volontairement positionnées dans ce
démonstrateur permettent d'évaluer les moyens d'accès
préférentiels des opérateurs en fonction de leurs différences inter et intra individuelles.
Interface Homme-Machine
Evaluation technique et ergonomique du démonstrateur
Un focus sur les IHM montre l'organisation des informations et des commandes au sein des postes opérateurs du
démonstrateur DEVIN (voir la figure 7). Les écrans supportent les informations et commandes nécessaires à la
réalisation de l'activité du binôme chef/opérateur tourelle. L'activité prise en compte dans le démonstrateur
est basée aussi bien sur la mise en œuvre de fonctions
classiques d'un système militaire terrestre actuel (exemple : localisation du véhicule sur le théâtre d'opération),
que sur la prise en compte des fonctions innovantes intégrables dans un futur véhicule blindé (exemple : gestion
de la protection collective).
L'objectif ici est de réaliser des essais, de dépouiller les
résultats, de comparer les différentes configurations testées et de statuer sur la viabilité du concept de perception
et de visée déportée. L'analyse des résultats doit prendre
en compte les aspects technologiques, système et ergonomiques, afin de les corréler aux études précédemment
réalisées. Les conclusions de cette étude permettront de
définir une solution d'intégration d’une tourelle téléopérée au sein d'un futur système militaire terrestre.
Attendus des évaluations techniques et ergonomiques
La définition des attendus des évaluations permet de définir les objectifs et critères d'évaluation à prendre en
compte. Ils précisent les équipements, les fonctions, ainsi que les niveaux de performance qui pourront être éva-
Sur les écrans supérieurs, sont notamment présentées en
superposition de l'environnement extérieur, des aides
234
lués sur le démonstrateur. Il est donc nécessaire de définir au préalable des critères de performance permettant
de vérifier l’intérêt des technologies prises en compte.
Deux groupes de critères sont retenus :
-
Formation préalable
Les choix d'architecture réalisés dans le cadre du démonstrateur sont en rupture technologique avec les équipements actuels utilisés par les opérateurs. Ce point justifie une période préalable de prise en main technique du
démonstrateur par les opérateurs chargés de l'évaluation
de DEVIN. De plus, l'architecture fonctionnelle du démonstrateur prend en compte les nouvelles fonctionnalités intégrables dans les futurs systèmes militaires terrestres. Ces évolutions pressenties sont issues pour la plupart d'études prospectives, dont les résultats ne sont pas
encore portés à la connaissance des utilisateurs actuels.
Ce deuxième point implique d'expliquer aux opérationnels chargés de l'évaluation les nouvelles potentialités du
système à tester.
des critères techniques mesurables et quantifiables
(exemples: temps de réponse, nombre d'erreurs…),
des critères subjectifs (ex : appréciation par l'opérateur -et par l'observateur- du degré d'atteinte des objectifs en fonction de la consigne, appréciation d'un
seuil en deçà duquel la qualité de perception ne permet pas de réaliser correctement la fonction…).
Ces attendus sont identifiés au sein de l'équipe pluridisciplinaire (ergonome, experts en visionique, informaticien, architecte système, architecte mécanique) afin
d'appréhender les différents domaines de l'étude. Les attendus ergonomiques génériques consistent notamment
en l'évaluation du concept de reconfigurabilité des IHM
au sein d'un véhicule blindé, du concept du poste unique,
des modes de fonctionnement système et de l'intégration
d'aides et assistances à l'opérateur.
CONCLUSION ET PERSPECTIVES
Apport d'une démarche ergonomique intégrée
L'intégration de la démarche ergonomique au sein de ce
projet a largement été facilitée par une adhésion totale de
l'équipe pluridisciplinaire déjà sensibilisée à la prise en
compte des aspects facteurs humains dans la conception
système. Cette adhésion dès les phases amonts du projet
a permis :
Profil opérateur ciblé
Les attendus des évaluations sont différents en fonction
des profils d'utilisateurs participant aux évaluations. En
effet, les opérationnels prévus pour le déroulement des
évaluations sont scindés en deux groupes différents :
-
-
un équipage dit "de référence",
des équipages dits "opérationnels".
-
Les membres de l'équipage de référence sont des experts
dans l'utilisation technique de différents systèmes et démonstrateurs technologiques en cours. Les thèmes d'évaluation abordés avec eux traitent essentiellement de la
validation de l'architecture technologique choisie.
La conception centrée utilisateur a permis de repositionner l'homme dans le système. Les résultats démontrent
qu'il fait partie intégrante du système. Considéré depuis
longtemps comme facteur limitant de la performance des
systèmes complexes, l'opérateur peut aujourd'hui être
appréhendé comme un générateur de solution au même
titre que d'autres composantes.
Les membres des équipages opérationnels sont constitués d'utilisateurs de systèmes blindés, actuellement en
service dans les régiments de l'armée de terre et ayant
pour la plupart participé à des opérations extérieures (déploiement en contexte opérationnel réel). Les thèmes
d'évaluation abordés concernent essentiellement :
-
de dérouler la démarche ergonomique dans son intégralité (de l'analyse aux évaluations),
de travailler tout au long du projet en ingénierie intégrée,
de favoriser une synergie forte entre tous les métiers
impactés,
de disposer de références et d'outils communs aidant
aux choix des solutions préconisées.
Dans le domaine des systèmes militaires terrestres, les
processus de conception avaient tendance à traiter
l'homme comme un facteur externe. Cette démarche
pouvait aboutir à des aberrations d'un point de vue
ergonomique. Plusieurs exemples peuvent être cités :
la viabilité opérationnelle de la tourelle téléopérée
(avec opérateurs déportés en châssis),
la pertinence opérationnelle des solutions technologiques choisies,
l'adéquation des choix d'IHM avec les exigences et
contraintes réelles des tâches à réaliser,
l'évaluation des critères dimensionnants dans la réalisation des tâches au cours d'une mission : organisation des IHM, séquentialité des tâches au regard des
missions à réaliser, organisation et répartition des activités au sein du binôme chef/opérateur tourelle…
-
-
235
la conception de postes opérateurs avec l'optimisation du volume alloué aux équipements au détriment
de l'opérateur qui devait se caler "au mieux" pour
intégrer son poste,
la conception d'IHM potentiellement génératrices
d'erreurs pour le système avec une consigne d'utilisation liée à la formation de l'utilisateur de type : "on
dira en formation que c'est dangereux d'actionner la
commande et l'opérateur s'adaptera".
Aujourd'hui, l'armée est une armée de métier dont le
cœur est constitué autant par les hommes que par les systèmes. Cette armée évolue en termes d'exigences (de
plus en plus précises), de restrictions, de législation (de
plus en plus proche du code du travail civil). A l'heure
actuelle, l'intégration d'une démarche centrée utilisateur
dans la conception de systèmes militaires terrestres permet de prendre en compte très tôt les aspects facteurs
humains et d'aider les concepteurs dans l'atteinte des performances requises par les projets.
-
-
-
Apports techniques et ergonomiques de l'étude
Comme on a pu le voir, les concepts opérationnels développés autour des futurs véhicules de combat débouchent
sur plusieurs innovations intégrées dans le démonstrateur
DEVIN : équipage délocalisé, nouveaux concepts technologiques... Ainsi équipé, DEVIN, démonstrateur évolutif, permet de recueillir les données et pré requis nécessaires et indispensables à une bonne intégration des
évolutions technologiques pressenties dans les futures
plates-formes terrestres militaires.
En conclusion, ce projet est une première étape permettant la validation d'hypothèses de conception (intégration
de solutions technologiques, organisation du collectif de
travail au sein d'un équipage, remise en cause des habitudes de travail). Une deuxième étape est d'ors et déjà à
préparer. Elle consiste en la transposition sur un véhicule réel des résultats obtenus avec DEVIN. Les données acquises sont considérées aujourd'hui comme dimensionnantes, voire spécifiantes pour la conception de
nos nouveaux systèmes militaires terrestres.
Apports techniques
Le démonstrateur DEVIN contribue à enrichir nos
connaissances notamment sur les points techniques suivants :
-
-
-
BIBLIOGRAPHIE
veille lointaine : évaluer l’aptitude du matériel à réaliser la surveillance d'un secteur situé à une distance
de plusieurs kilomètres.
veille proche : évaluer l’aptitude du matériel à réaliser la surveillance de l’environnement proche du véhicule .
intégration d'une architecture de perception innovante, au sein d'une architecture vétronique globale
pour les futurs systèmes.
1.
Azerot T and Echalier S (2004). Evaluation of new
HMI concepts embedded in an experimental platform. Congress of MILVA 2004.
2.
Echalier S et Kujawa L (2004). Interface hommemachine d'un système de traitement de menaces.
Brevet en cours.
3.
Fisanne C (1999). La téléopération et l'homme
4.
Kujawa L (2004). Programme d'étude amont : Etude
d'évolution et essais d'un démonstrateur de perception et de visée déportées. Contraintes et exigences
ergonomiques liées à l'activité du binôme chef /
opérateur tourelle.
5.
Kujawa L (2004). Programme d'étude amont : Etude
d'évolution et essais d'un démonstrateur de perception et de visée déportées. Cahier des Charges IHM
des postes opérateurs du démonstrateur de perception et de visée déportées.
6.
Mestre D, Masson G (1996). Evaluation des besoins
en informations visuelles pour la téléopération.
7.
Mestre D, Masson G (1996). Etat de l'art des solutions technologiques pour la perception visuelle de
l'environnement lors des tâches de téléopération.
8.
NF EN ISO 13407. Processus de conception centrée
sur l'opérateur humain pour les systèmes interactifs.
1999
.
Apports ergonomiques
Ce projet a permis aux ergonomes de réaliser un certain
nombre d'analyses et d'études de concepts qui ont notamment abouti à :
-
-
l'appréciation, la qualification et, autant que possible,
la quantification des contraintes physiologiques liées
à la perte de vision directe,
l'identification du positionnement et du rôle de l'opérateur au sein d'un futur système complexe intégrant
des aides et assistances à l'opérateur, ainsi que des
automatismes divers,
l'identification de l'impact des nouvelles technologies
introduites comme support de réalisation d'activités
classiques pour les opérateurs (analyse du transfert
de tâches, acceptabilité des nouvelles technologies…).
la consolidation des données acquises sur le terrain
sur les exigences et contraintes ergonomiques à prendre en compte lors de la conception de postes équipages de plates-formes militaires terrestres,
l'évaluation d'une organisation de tâches au sein d'un
collectif de travail pré établi,
la validation des hypothèses structurantes posées lors
de l'identification de la probable organisation des tâches à mener par le système et les membres d'équipage,
236
RUP© et conception centrée sur l’utilisateur : une étude
de cas
François Lemieux
Michel C. Desmarais
Département de génie informatique
École Polytechnique de Montréal
C.P. 6079, succ. Centre-Ville, Montréal
Québec, Canada, H3C 3A7
[email protected]
[email protected]
RÉSUMÉ
specific sequence of distinct activities and a better
understanding of key UCD principles would allow the
process to be user-centered.
Le processus de développement logiciel RUP© est perçu
comme une norme de fait par l’industrie. Il n’est pas
centré sur l’utilisateur, mais il est plutôt centré sur
l’architecture. Cela peut être un handicap lors de la
conception d’applications logicielles interactives. Le
RUP pourrait néanmoins être adapté à la conception centrée sur l’utilisateur. Cette étude de cas aborde cette
question commune à plusieurs projets de développement
logiciel qui utilisent le RUP et où une équipe ergonomique intervient. La conformité du RUP à la norme
ISO 13407 qui définit la conception centrée sur l’utilisateur est ici analysée. Pour le RUP, la conception centrée sur l’utilisateur et les tests d’utilisabilité sont des
« concepts clés ». Les résultats démontrent cependant
que son application ne se traduit pas par une conception
centrée sur l’utilisateur. Certains éléments pertinents du
processus ne sont pas retenus par l’équipe de développement. Certains principes gagneraient à être mieux
compris et mieux intégrés au processus et un enchaînement d’activités distinct permettraient une conception
centrée sur l’utilisateur.
KEYWORDS: Rational Unified Process, RUP, ISO
13047, UCD, case
development practices
study,
software
engineering,
INTRODUCTION
En génie logiciel, la production d’un système informatique doit se faire selon une suite d’opérations définies par
un processus de développement [21]. Les premières étapes d’un processus de développement logiciel, la modélisation métier et la définition des exigences, consistent à
définir les spécifications du système à partir des besoins
du client [12]. Lors de ces étapes on définit, entre autres,
les scénarios d’opération, les exigences fonctionnelles et
les exigences non-fonctionnelles ainsi que les interfaces–
utilisateurs [6, 7, 8].
Le Rational Unified Process (RUP), une version commerciale de ce type de processus, est utilisé dans
l’industrie du développement logiciel à une telle échelle
qu’il est perçu comme une norme de fait [14, 4].
CLÉS : Rational Unified Process, RUP,
ISO 13047, conception centrée sur l’utilisateur, étude de
cas, génie logiciel, processus de développement centréutilisateur.
MOTS
La norme ISO 13407 prescrit les règles à suivre pour
adapter un processus de développement logiciel à la
conception centrée sur l’utilisateur [9]. Cette norme, intitulée « Processus de conception centrée sur l'opérateur
humain pour les systèmes interactifs », sera utilisée ici
pour établir dans quelle mesure le processus suivi par
l’équipe est conforme à la conception centrée sur
l’utilisateur.
ABSTRACT
RUP is a software development process that is widely
used in industry. RUP is an architecture-centered process
and generally not recognized as user-centered. This
could be considered as a shortoming for interactive
applications. However, can RUP be adapted, or is it at
least compatible with a user-centered design (UCD)
process? We address this issue through a case study that
is typical of many software development projects, where
RUP is adapted to the needs of the project and where an
HCI team has the responsibility for user requirements.
We analyse the extent to which the resulting process is
compliant with ISO 13407, the standard defining the
UCD process. Results show that, altought UCD is a key
concept for RUP, its application in the project does not
yield a user-centered process according to the standard.
Key elements of UCD are omitted by the adaptation
made by the development team. We conclude that a
De nombreux problèmes de réalisation des systèmes informatiques interactifs sont imputables à une mauvaise
gestion des exigences. Or, les exigences liées à l’utilisateur et à l’organisation constituent la majorité des exigences de ces systèmes. La conception centrée sur
l’utilisateur pallie à ces problèmes [9, 19].
Comment un processus comme le RUP traite-t-il la gestion des exigences-utilisateurs et comment peut-on adapter ce processus à la conception centrée sur l’utilisateur ?
Cette étude de cas aborde cette question sous trois angles : celui du processus tel que défini par la référence
237
de base, le RUP [22] ; l’adaptation et l’application qu’en
fait une équipe de développement pour un projet donné ;
et enfin, selon l’angle d’une intervention ergonomique
visant à utiliser l’approche centrée sur l’utilisateur lors
de la définition des exigences.
Jacobson, Grady Booch et James Rumbaugh, chefs de
file de la conception orientée objet [16].
Le RUP est un processus de développement itératif qui
se déroule en 4 phases : l’inception ou opportunité, l’élaboration, la construction et la transition. Il comporte des
enchaînements d’activités qui sont au nombre de 6 parmi
lesquels on retrouve la modélisation métier et la gestion
des exigences. Il y a aussi 3 enchaînements d’activités de
soutien dont celui de la gestion de projet. La conception
des interfaces-utilisateurs se fait lors des activités de gestion des exigences dans la version 2002 du processus
[18].
L’étude de cas décrit l’intervention d’une équipe d’ergonomes auprès d’une équipe d’analystes fonctionnels
qui travaillent à la modélisation métier et à la définition
des exigences de la première application d’un nouveau
progiciel d’entreprise. Le processus RUP est adapté par
l’équipe de développment. L’application étudiée, la
« Gestion des réseaux de distribution » (RDD), est définie par 48 cas d’utilisation dont 6 font l’objet d’une intervention ergonomique complète.
La définition détaillée des exigences est exprimée par
des cas d’utilisation qui sont des scénarios qui décrivent
des fonctionnalités du système et devraient fournir un résultat pour un acteur particulier [18]. Il ne faut pas
confondre les cas d’utilisation avec les scénarios
d’utilisation connus en ingénierie de l’utilisabilité [14].
LE RUP ET ISO13407
Le RUP et son application dans le cadre du cas seront
analysés selon la perspective de la norme ISO 13407. Le
RUP et la norme sont ici décrits dans leurs grandes lignes avant d’aborder l’étude du cas.
Le RUP ne prétend pas être centré sur l’utilisateur. Il est
plutôt centré sur l’architecture et piloté par des cas
d’utilisation [18]. Le RUP assimile la conception centrée
sur l’utilisateur à un « concept clé ». C’est ce concept
qui établit des équivalences entre les activités et artefacts
du processus et les prescriptions de la norme ISO 13407.
Les tests d’utilisabilité constituent aussi un « concept
clé » associé à la discipline des tests.
La norme ISO 13407
La norme ISO 13407 prescrit un processus de conception centrée sur l’utilisateur. La norme ISO 13407 ne
prétend pas couvrir un cycle de développement de système ; elle est complémentaire au processus de développement et s’y intégre selon le contexte.
La norme énonce 4 grands principes :
ƒ
ƒ
ƒ
ƒ
Les « concepts clés » sont les travailleurs, les activités,
les artefacts et les enchaînements d’activités, ainsi que
d’autres éléments qui permettent de décrire le processus
[18]. La description de certains de ces concepts, comme
risque, itération, phase ou tests de performance, est incluse à l’intérieur des enchaînements d’activités appropriés [22].
la participation active des utilisateurs et une compréhension claire des exigences liées à l'utilisateur et
à la tâche ;
une allocation appropriée des fonctions entre les utilisateurs et la technologie ;
l'itération des solutions de conception ;
une conception pluridisciplinaire [9].
Il existe aussi une « feuille de route » de l’ingénierie de
l’utilisabilité. Pour le RUP, une feuille de route est
l’adaptation du processus générique à des problèmes
spécifiques. Une telle feuille de route existe, par exemple, pour les solutions d'affaires électroniques [22].
Et elle propose des activités :
ƒ
ƒ
ƒ
ƒ
comprendre et spécifier le contexte d’utilisation ;
spécifier les exigences liées à l’utilisateur et à l’organisation ;
proposer des solutions de conception ;
évaluer les conceptions par rapport aux exigences
[9].
GÉNIE LOGICIEL ET CONCEPTION CENTRÉE SUR
L’UTILISATEUR
Un processus de développement doit être adapté à un
contexte d’application particulier. Dans le cas du RUP,
cette adaptation fait l’objet d’un enchaînement
d’activités spécifique. Mais, le processus est ici d’abord
analysé dans sa forme « générique » pour établir sa
conformité à ISO 13047.
Une norme, ISO 9241-11 prescrit des lignes directrices
relatives à l’utilisabilité [9]. Un rapport technique,
ISO TR 16982 présente des méthodes d’utilisabilité
existentes applicables dans le cadre de ISO 13407[12].
Un rapport technique ISO TR 18529 décrit un modèle
formel fondé sur ISO 13407 [11].
Les approches du génie logiciel et de l’ingénierie de
l’utilisabilité qui guident la conception centrée sur
l’utilisateur sont différentes. Le génie logiciel modélise
le domaine après avoir identifié le « contexte du problème » alors que l’ingénierie de l’utilisabilité spécifie
Le RUP
Le RUP a été inspiré d’un processus générique, The Unified Software Development Process développé par Ivar
238
les exigences liées à l’utilisateur et à l’organisation après
avoir identifié le « contexte d’utilisation ». Le RUP, selon la perspective de la conception centrée sur
l’utilisateur, soulève plusieurs problèmes :
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Conformément à la pratique, l’équipe de développement
a adapté le RUP à ses besoins en retenant les activités et
les artefacts qu’elle a jugés pertinents. Un processus de
conception des interfaces-utilisateurs a ainsi été défini
selon les prescriptions du RUP. Une intervention ergonomique s’y est rajoutée et s’est effectuée selon la méthodologie proposée par Mayhew [20].
il souffre de l’absence de préoccupation des facteurs
humains [24] ;
il ne traite pas des aspects internationaux et interculturels [24] ;
il ne se préoccupe pas du modèle centré sur l'utilisateur durant la conception de l'interface-utilisateur
[24] ;
il néglige la personnalisation de l'interface nécessaire à l'interaction entre la technologie et les utilisateurs [24] ;
en donnant l’impression de répondre à toutes les
questions, il nie l’initiative du concepteur
d’interface-utilisateur [4] ;
il ne distingue pas clairement l'utilisateur final de
l’expert du domaine, biaisant ainsi l’utilisateur en
faveur du développement [4] ;
il désigne un seul travailleur en utilisabilité et c’est
le concepteur d'interface-utilisateur dont la responsabilité se limite à aménager visuellement l'interface
sans pour autant avoir une quelconque compétence
en utilisabilité [4] ;
il soutient peu l'analyse de la tâche des utilisateurs et
l’identification des groupes d'utilisateur [4] ;
les développeurs sont plus préoccupés par l’implémentation de toutes les fonctionnalités que par
l’utilisabilité du système [3] ;
la production des cas d’utilisation supplante la compréhension des besoins réels des utilisateurs [3] ;
le langage UML est souvent inaccessible aux utilisateurs qui lui préfèrent la présentation de prototypes
d’interface-utilisateur pour comprendre comment le
système fonctionnera [3].
La méthodologie
L’analyse de cas est une méthode de recherche courante
pour l’étude de processus de développement logiciel
[28]. L’étude de cas est ici une étude de cas unique. La
méthode de cueillettes des données est l’observation participante : le chercheur a participé au développement en
effectuant l’intervention ergonomique. Cependant, la décision de faire du cas l’objet d’une recherche a été prise
après l’intervention du chercheur. Le chercheur n’a donc
pas pu influencer le cours du projet.
L’analyse de contenu et la méthode ex post facto ont été
privilégiées pour l’analyse des données. Ces données
provenaient de documents, notamment les biens livrables
pertinents du projet et d’entrevues faites après coup. Les
observations du chercheur ont servi à guider la démarche
d’analyse mais n’ont été utilisées qu’occasionnellement
pour assurer la validité interne des données. Une analyse
croisée des guides et normes produits par l’équipe de développement avec les biens livrables correspondants a
été faite afin de s’assurer qu’ils étaient respectés par les
membres de l’équipe de développement.
L’analyse des données est celle de la comparaison intracas. C’est une analyse comparative qui permet
d’analyser les descriptions et explications du même cas
[24, 1, 5]. Les détails de l’étude apparaissent dans [19].
Chaque assertion et affirmation y est associée à une
source formellement identifiée.
Voilà pourquoi des propositions ont été formulées pour
harmoniser les processus de développement logiciel
orientés-objets [19, 2] en général, et le RUP en particulier, à la conception centrée sur l’utilisateur [24, 25, 26].
Seffah, Desmarais et Metzker [23] ont fait un inventaire
de plusieurs de ces efforts. L’étude de cas vise, ici, à vérifier si ces problèmes se sont matérialisés et comment
ils ont été résolus.
Les questions de recherches qui constituent les unités
d’analyse [27] sont inspirées des principes et des activités de la norme ISO 13407 citées précédemment et sont
les suivantes :
LE CAS
ƒ
ƒ
ƒ
Le cas étudié porte sur le déroulement de la modélisation
d’affaires et de la définition des exigences lors du développement d’une application durant lequel une intervention ergonomique a été faite. L’application correspond à
un module d’un plus grand système. Le système est un
progiciel de gestion d’une entreprise de production de
biens dont la vente est assurée par plus de 10 000 détaillants.
ƒ
ƒ
ƒ
239
Le RUP soutient-il la participation active des utilisateurs ?
Définit-il le contexte d’utilisation selon ISO
13407 ?
Le RUP permet-t-il une bonne spécification des exigences-utilisateurs notamment par une bonne répartition des fonctions entre les utilisateurs et la technologie selon ISO 13407 ?
La production des solutions de conception se faitelle par le RUP selon ISO 13407 ?
L’approche itérative d’ISO 13407 est-elle respectée
par le RUP ?
L’évaluation des solutions de conception retenue
par le RUP est-elle conforme à celle qui est prescrite
par ISO 13407 ?
ƒ
Le RUP reconnaît-il la nécessité d’un personnel
qualifié selon ISO 13407 ?
sateurs Web. La version du RUP qui est étudiée ici est :
2002.05.01.305.000 [22].
Le contexte
LES RÉSULTATS
L’application étudiée, la « Gestion des réseaux de distribution » (RDD), correspond au premier des 13 modules
qui composent le système à développer. Ce système a
pour mission d’assurer la gestion des opérations de vente
de produits distribués par des commerçants. Ces opérations de vente comptent pour 1,8 G$ CA, soit 45 % des
revenus de l’entreprise et mobilise plus de 800 employés. Lors de la période étudiée, 3 applications faisaient l’objet de projets de développement simultanés.
La modélisation métier et la définition des exigences du
projet RDD ont duré un an et ont mobilisé 17 personnes
à plein temps.
Pour chaque question de recherche, nous présentons les
« prescriptions » de la norme ISO 13407 et les dispositions correspondantes du RUP, « l’implémentation »
qu’en a faite l’équipe de développement et la description
de « l’intervention ergonomique » correspondante.
Le RUP soutient-il la participation active des utilisateurs ?
ISO 13407 prévoit une participation directe et diversifiée
des utilisateurs. Les modalités de cette participation sont
précisées par la norme ISO TR 16982 [12]. Le RUP,
pour sa part, juge souhaitable une participation des utilisateurs.
Le tableau 1 inventorie certaines caractéristiques de
l’application. Les diagrammes de processus opérationnels (DPO) sont des diagrammes des processus
d’affaires qui décrivent les opérations lorsque le nouveau système sera mis en place. Les caractéristiques logicielles sont l’équivalent d’exigences logicielles. Les
cas d’utilisation et les acteurs correspondent à la définition qu’en donne le RUP. Les utilisateurs sont ceux qui
manipuleront le système.
Caractéristiques de l’application
DPO
Caractéristiques logicielles non fonctionnelles
Caractéristiques logicielles fonctionnelles
Cas d’utilisation
Acteurs
Utilisateurs
Lors de « l’application » du processus, à la demande expresse du client, les représentants des utilisateurs participent à l’élaboration, valident et approuvent la plupart des
artefacts de la modélisation métier et de la définition des
exigences. Cette participation n’est pas inspirée du processus mais était une demande du client. Cette participation des utilisateurs se faisait à peu près exclusivement
dans le cadre d’ateliers de travail avec les représentants
des utilisateurs.
Nbre
53
194
109
48
67
80
La participation suscitée par l’intervention ergonomique
a inclus la planification du cycle, le suivi de
l’avancement des activités ergonomiques et la variété
des méthodes de validation.
En limitant la participation des utilisateurs à des ateliers
de travail, l’équipe de développement a ainsi placé fréquemment les représentants des utilisateurs dans le rôle
d’expert du domaine avec les conséquences mentionnées
plus tôt par Gulliksen et al. [4].
Tableau 1: Envergure de l'application RDD.
L’intervention ergonomique a été faite à la demande et
sous l’autorité du service responsable des analystes
d’affaires et des représentants des utilisateurs. La définition des processus d’affaires, les DPO ainsi que
l’identification des caractéristiques logicielles relevaient
de ce service. Par contre, la définition des exigences relevait, elle, de l’équipe de développement. La définition
des exigences s’est effectuée sur une période d’un an
pour l’application visée par l’étude. L’intervention ergonomique s’est déroulée du 4e au 9e mois de cette période.
Elle a consisté à faire la conception des interfaces-utilisateurs pour des fonctionnalités critiques définies par
6 cas d’utilisation.
Définit-il le contexte d'utilisation selon ISO 13407 ?
Selon ISO 13407, le contexte d’utilisation comprend
l’analyse de la tâche, la description détaillée des utilisateurs et la description de l’environnement physique,
technique et organisationnel.
Le RUP prévoit, pour sa part, une définition du contexte
lors de la production de l’artefact Vision, qui est
l’équivalent d’une spécification des exigences du système. Il ne distingue pas le contexte du problème propre
au génie logiciel du contexte d’utilisation de la conception centrée sur l’utilisateur. Cette description du
contexte se fait à haut niveau. Quant à la tâche, le RUP
assimile le cas d’utilisation à une description du contexte
de la tâche. Ce qui n’est pas conforme à ISO 13407.
Les artefacts traités par l’intervention ergonomique ont
été produits par 9 personnes. Une spécification de
34 interfaces comprenant 727 champs a été produite par
les ergonomes. Des analystes fonctionnels ont produit
les autres interfaces-utilisateurs de l’application. L’architecture du système est de type J2EE avec interfaces-utili-
Lors de l’adaptation du processus, l’équipe de développement a choisi de ne pas produire de document Vision.
Il n’y a donc pas de description des utilisateurs tel que
240
prescrit par le RUP. Il existe des acteurs qui sont décrits
par le rôle qu’ils jouent dans le système. Ils correspondent à des utilisateurs génériques. C’est insuffisant en
conception centrée sur l’utilisateur. Quant aux cas
d’utilisation, ils visent d’abord à décrire le futur système
et ses fonctionnalités. Ils ne sont pas inspirés d’une
l’analyse du contexte de la tâche. Ils sont plutôt extraits
des processus d’affaires représentés par les DPO et par
les caractéristiques logicielles fonctionnelles et non
fonctionnelles.
L’intervention ergonomique a abordé la répartition des
fonctions sans toutefois l’avoir formellement documentée. Ainsi, par exemple, l’analyste fonctionnel souhaitait
modéliser des champs d’adresse en fonction des normes
nationales et internationales afin de faciliter les traitements automatiques des services postaux nationaux. Les
ergonomes recommandaient plutôt que cette ventilation
des champs soit faite en fonction des besoins réels de
l’entreprise et du temps disponible que les utilisateurs finaux pouvaient consacrer à cette tâche puisque les adresses servaient plutôt à la localisation d’établissements
plutôt qu’à des fins postales.
L’intervention ergonomique a produit une analyse du
contexte d’utilisation qui comprend une description de
l’environnement physique, technique, dont les équipements, et organisationnel. Une description détaillée des
utilisateurs finaux y a été incluse. Des analyses de la tâche ont complété la description du contexte. Les cas
d’utilisation ont certes été utilisés, mais pour comprendre le fonctionnement du futur système.
En conclusion, le RUP, comme la plupart des processus
de développement logiciel, limite ses préoccupations
d’utilisabilité à la seule conception des interfaces-utilisateurs. Or, l’utilisabilité, selon ISO 13407, ne se limite
pas aux seules interfaces-utilisateurs, mais à l’ensemble
des exigences liées aux utilisateurs et à l’organisation.
L’intervention ergonomique, pour sa part, a permis
d’aborder la spécification des exigences-utilisateurs de
façon plus large qu’au plan de l’interface-utilisateur et
de rendre plus explicite la question de la répartition des
fonctions.
La norme ISO 13407 met formellement en garde contre
la tentation de « décrire les tâches uniquement en termes
de fonctions ou d’attributs d’un produit ou d’un système
[9] ». Les cas d’utilisation correspondent à ce genre de
description où l’on retrouve explicitement les fonctionnalités et les attributs du système. Ce ne sont pas des
analyses du contexte de la tâche. Quant à la pertience du
contexte d’utilisation, le RUP est à ce point sibyllin sur
cette question que l’équipe de développement n’a pas
jugé pertinent de produire le document Vision qui est
présumé le contenir. On peut en conclure que le RUP n’a
pas favorisé la définition du contexte d’utilisation.
La production des solutions de conception se faitelle par le RUP selon ISO 13407 ?
La matérialisation des solutions de conception correspond, pour ISO 13407, à la production de prototypes statiques ou dynamiques qui s’inspirent du contexte
d’utilisation. Elle s’inspire aussi de l’état des techniques,
de l’expérience et des connaissances des participants et,
enfin, des normes et des guides.
Le RUP permet-t-il une bonne spécification des exigences-utilisateurs notamment par une bonne répartition des fonctions entre les utilisateurs et la technologie selon ISO 13407 ?
Pour le RUP, la conception des interfaces-utilisateurs repose d’abord sur des guides qui ont été produits en début
de projet lors de la discipline « environnement » du processus. D’autre part, une interface-utilisateur doit obligatoirement correspondre à un cas d’utilisation sans égard
au contexte d’utilisation.
Il faut distinguer, les fonctions qui doivent être exécutées par l’utilisateur de celles qui sont assumées par la
technologie selon ISO 13407. C’est l’analyse de la tâche
qui dicte ce choix. Par ailleurs, les exigences liées à
l’utilisateur et à l’organisation doivent comprendre, entre
autres, la description des interfaces-utilisateurs, les exigences d’utilisabilité et de sécurité.
C’est ainsi que l’équipe de développement a produit des
interfaces-utilisateurs selon les prescriptions d’un guide
appelé « Cadre de conception des interfaces Web » qui
fixe des lignes directrices de conception, explique
l’utilisation des composants et présente des gabarits
d’écran. Il faut noter qu’à chaque cas d’utilisation devait
correspondre un « scénarimage » ou storyboard de cas
d’utilisation qui regroupe les prototypes d’interfaces-utilisateurs du cas.
Le RUP ignore cette répartition des fonctions entre les
utilisateurs et la technologie. Par contre, il prévoit des
exigences d’automatisation.
L’équipe de développement ignore aussi cette répartition
lors de l’application du processus. Les exigences sont
des caractéristiques du nouveau système inspirées des
processus d’affaires et correspondent aux exigences
d’automatisation du RUP. Il existe des exigences
d’utilisabilité peu nombreuses et décrites à haut niveau.
Les exigences de sécurité sont définies par une équipe
distincte mandatée à cet fin.
La spécification d’interface produite lors de l’intervention ergonomique était, elle, inspirée de l’analyse
contextuelle de la tâche. Elle correspondait à 6 cas ou
partie de cas d’utilisation. Certains ont été créés pour répondre à la spécification. Un court guide de style qui définit l’apparence des interfaces-utilisateurs a par la suite
241
été produit après validation avec les représentants des
utilisateurs et les utilisateurs finaux.
surveillance à long terme, pour la suite du cycle de vie.
L’évaluation lors de la conception consiste à faire faire
des simulations de tâches par les utilisateurs à partir de
maquettes ou de prototypes. On recueille à ce moment
l’information nécessaire à amélioration des solutions de
conception. Ces tests doivent faire l’objet d’un plan
d’évaluation incorporé au projet.
Lle RUP laisse entendre que la production des solutions
de conception est réalisable à partir des seuls guides.
C’est ainsi qu’il peut inhiber l’initiative du concepteur
d’interface-utilisateur, comme le suggèrent Gulliksen et
al [4], et qu’il néglige l’importance du contexte d’utilisation dans la réalisation des solutions de conception.
L’équipe de développement présumait donc que ces guides constituaient la pierre angulaire de la conception
d’interfaces-utilisateurs.
Bien que le RUP prévoie différents modes d’évaluation
des prototypes, dont des tests d’utilisabilité, il n’y a pas
de planification de ces tests. De plus, le gabarit de plan
de test défini par le RUP prévoit des tests d’utilisabilité,
mais les distinctions liées à la conception des interfacesutilisateurs et à la surveillance ne sont pas faites. Ainsi,
les tests d’utilisabilité, tels qu’ils y sont présentés, sont
assimilables à d’autres tests et sont conçus par un
concepteur de tests et exécutés par un testeur. Le « concept clé » tests d’utilisabilité du RUP est d’ailleurs inclus
dans la discipline de tests plutôt que dans celle de définition des exigences.
L'approche itérative d'ISO 13407 est-elle respectée
par le RUP ?
Pour ISO 13407, les itérations sont nécessaires à l’amélioration des solutions de conception. Les itérations doivent faire l’objet d’une planification à l’intérieur du projet et doivent se poursuivre jusqu’à l’atteinte des objectifs de conception. Elles consistent à reprendre la solution de conception présentée aux utilisateurs et soumise à leur évaluation jusqu’à ce qu’elle soit satisfaisante pour leas parties prenantes.
Pour l’équipe de développement, l’évaluation des interfaces-utilisateurs reposait sur des revues : des rencontres
des analystes fonctionnels faites avec les représentants
des utilisateurs et des revues par les pairs. Les tests
d’utilisabilité faits par les ergonomes ont d’ailleurs été
perçus au début comme une intrusion dans la juridiction
de l’équipe de l’assurance qualité. Des explications sur
la nature des évaluations ont dû être fournies.
L’itération constitue l’un des fondements du RUP qui en
reconnaît plusieurs types. Mais, il n’y a pas d’itérations
planifiées pour les interfaces-utilisateurs. Il y a une
forme itérative de prototypage qui correspond plus à des
incrémentations qu’à des corrections successives.
L’équipe de développement prévoyait que les cas
d’utilisation et les scénarimages devaient être produits
les uns après les autres. Dans les faits, les analystes fonctionnels les ont produits parallèlement. Il y a donc eu
une forme d’itération entre les cas d’utilisation et les interfaces-utilisateurs malgré les prescriptions de
l’application du processus.
Plusieurs types d’évaluation ont été faits lors de l’intervention ergonomique. Les premières maquettes ont été
soumises à l’évaluation selon des lignes directrices génériques et à l’évaluation heuristique d’ergonomes. Des
tests avec simulation de tâche ont ensuite été faits avec
les représentants des utilisateurs et avec les utilisateurs
finaux. Des évaluations pas à pas ont aussi été faites
avec les représentants des utilisateurs seuls, puis en présence des analystes fonctionnels concernés. Ces évaluations ont permis aux analystes fonctionnels et aux représentants des utilisateurs d’ajouter des cas d’utilisation
manquants au modèle des cas, en plus d’améliorer les
solutions de conception. Elles ont aussi permis de corriger le contenu des cas d’utilisation en cours de réalisation, permettant ainsi une validation des exigences.
Lors de l’intervention ergonomique, une planification
des itérations a d’abord été proposée. Ensuite, la solution
de conception a été présentée et soumise à l’évaluation
des représentants des utilisateurs, aux utilisateurs finaux
et aux autres parties prenantes, à plusieurs reprises jusqu’à ce que la solution de conception réponde aux exigences-utilisateurs.
Il importe donc que les itérations soient planifiées et effectives. Mais le RUP ne l’affirme pas lui-même clairement pour la conception des interfaces-utilisateurs et
pour la spécification des exigences détaillées liées à
l’utilisateur comme les cas d’utilisation. L’équipe de développement n’a pas fait cette planification.
Le prototypage, les simulations, la modélisation et les
maquettes à améliorer par les tests avec les utilisateurs, à
différentes étapes de la conception, constituent l’esprit
de l’évaluation des solutions de conception d'ISO 13407
[17]. Les tests d’utilisabilité identifiés par le RUP ne devraient pas être qu’un concept, ils devraient être liés à
l’activité de conception des interfaces-utilisateurs.
L'évaluation des solutions de conception retenue par
le RUP est-elle conforme à celle qui est prescrite par
ISO 13407 ?
Le RUP reconnaît-il la nécessité d'un personnel qualifié selon ISO 13407 ?
ISO 13407 distingue l’évaluation des interfaces-utilisateurs lors de leur conception de celle effectuée pour la
Pour ISO 13407, la conception centrée sur l’utilisateur
est « une activité pluridisciplinaire faisant appel aux
242
connaissances et aux techniques du domaine des facteurs
humains et de l’ergonomie ».
que lors de son application, dans cette étude de cas, ils
n’ont pas été retenus.
Le RUP prévoit qu’un système est développé par des
« travailleurs » qui jouent un « rôle » comme un acteur
dans une pièce de théâtre. Néanmoins, les qualifications
des travailleurs concernés par la spécification des exigences et la conception des interfaces-utilisateurs doivent inclure une maîtrise du domaine. Et, selon la feuille
de route de l’ingénierie de l’utilisabilité du RUP,
l’analyste de processus métier, l’analyste système et le
spécificateur de cas d’utilisation doivent être qualifiés
pour recueillir l’information sur les utilisateurs, leurs tâches et leur environnement afin d’intégrer cette information aux artefacts de modélisation de métier et
d’exigence. Le RUP reconnaît même l’existence
d’expert en utilisabilité qui serait un graphiste.
L’introduction des cas d’utilisation dans la définition des
exigences aurait pu laisser croire qu’on se rapprochait de
la conception centrée sur l’utilisateur. Cela aurait pu être
le cas si on avait associé plus formellement le concepteur
d’interfaces utilisateurs à leur élaboration. C’était ce que
souhaitait initialement Ivar Jacobson [15], mais c’est resté lettre morte.
On constate cependant que l’intervention ergonomique
inspirée de la conception centrée sur l’utilisateur peut
cohabiter avec le RUP. Dans le cas présent, cette intervention a été dictée expressément par les représentants
des utilisateurs et non par le RUP lui-même. Il faudrait
que le RUP reconnaisse formellement la conception centrée sur l’utilisateur en insérant un enchaînement d’activités propre. Il y a quelques artefacts à ajouter, à modifier ou à remplacer. Il faut une équipe distincte et qualifiée.
C’est la direction responsable des représentants des utilisateurs et des analystes d’affaires, et non l’équipe de développement, qui a recruté et supervisé les ergonomes.
Le « Cadre de conception des interfaces WEB » a été
produit sous la responsabilité d’un architecte. Les interfaces-utilisateurs ont été conçues par les analystes fonctionnels responsables de la production des cas
d’utilisation. Ils n’avaient pas de qualification en
conception d’interfaces-utilisateurs.
Enfin, le « contexte du problème » et le « contexte
d’utilisation » ne sont pas la même chose. Les deux sont
nécessaires à la modélisation et la spécification d’un système interactif. Mais il faut apprendre à les distinguer et
à les faire cohabiter.
L’équipe d’ergonomes, était composée de deux ergonomes ayant des formations en sciences cognitives et en informatique, d’un informaticien et d’un graphiste. Et,
lorsque ce fut nécessaire, des séances d’évaluation ont
été tenues avec toutes les parties prenantes selon le
principe de la pluridisciplinarité.
REMERCIEMENTS
Nous tenons à remercier Guy Leblanc de ErgoIGL pour
sa précieuse collaboration.
BIBLIOGRAPHIE
1.
On constate donc que si ISO 13407 réclame l'assurance
d’un personnel qualifié pour exécuter les activités et les
méthodes appropriées, le RUP ne pose pas de conditions
sur les qualifications du personnel ou sur les méthodes
[17].
2.
CONCLUSION
3.
Une étude de cas unique invite à une certaine prudence
sur les conclusions. Celles qu’on peut en tirer ici pour le
processus RUP doivent être limitées à l’implémentation
qu’en a faite une équipe de développement. Par ailleurs,
on ne peut pas généraliser à tout le génie logiciel les
constatations faites pour le RUP.
4.
Le RUP est un processus centré sur l’architecture et n’a
pas la prétention d’être centré sur l’utilisateur. Il évoque
les principes de la conception centrée sur l’utilisateur en
en faisant un concept et en définissant une feuille de
route de l’ingénierie de l’utilisabilité. Cependant, il n’en
fait pas un enchaînement d’activités distinct. Certains
principes de la conception centrée sur l’utilisateur sont
mal compris et d’autres mal intégrés au RUP. Si bien,
5.
6.
243
Cunningham, J.B. 1997. "Case study principles for
different types of cases". Quality and quantity. Novembre. Kluwer Academic Publishers: Dordrecht,
Pays-Bas. 31(4).401-423.
Constantine, L.L., Lockwood, L. A.D. 2001.
"Structure and Style in Use Cases for User Interface
Design". Object modeling and user interface design.
Eds. Addison-Wesley: Boston. 245-279.
Gulliksen, J., Göransson, B., Boivie, I., Persson, J.,
Blomkvist, S., Cajander, Å. 2005. "Key Principles
for User-Centred Systems Design". HumanCentered Software Engineering. Eds. Kluwer
Academic Publishers: Boston, Ma. 17-36.
Gulliksen, J., Göransson, B., Lif, M. 2001. "A UserCentered Approach to Object-Oriented User
Interface Design". Object modeling and user
interface design. Eds. Addison-Wesley: Boston.
288-312.
Hlady Rispal, M. 2002. La méthode des cas : application à la recherche en gestion. De Boeck Université: Paris.
IEEE. 1998a. IEEE guide for information technology - system definition - Concept of Operations
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
(ConOps) document. Mars. IEEE Computer
Society: New York, NY. IEEE Std 1362-1998.
IEEE. 1998b. IEEE guide for developing system requirements specifications. Décembre. IEEE Computer Society: New York, NY. IEEE Std 1233, 1998
Edition.
IEEE. 1998c. IEEE recommended practice for software requirements specifications. Juin. IEEE Computer Society: New York, NY. IEEE Std 830-1998.
ISO. 1998. Exigences ergonomiques pour travail de
bureau avec terminaux à écrans de visualisation
(TEV) Partie 11: Lignes directrices relatives à
l’utilisabilité. Mars. ISO (Organisation internationale de normalisation): Genève, Suisse. ISO 924111:1998(F).
ISO. 1999. Processus de conception centrée sur
l'opérateur humain pour les systèmes interactifs.
Août. ISO (The International Organization For
Standardization): 29 p. Norme internationale ISO
Suisse ISO 13407:1999.
ISO. 2000. Ergonomics - Ergonomics of humansystem interaction - Human-centred lifecycle process descriptions. Avril. ISO (The International
Organization for Standardization): Genève, Suisse.
ISO/TR 18529:2000(E).
ISO. 2002. Ergonomie de l'interaction homme-système — Méthodes d'utilisabilité pour la conception
centrée sur l'opérateur humain. Juin. ISO (Organisation internationale de normalisation): Genève,
Suisse. ISO/TR 16982:2002(F).
ISO/IEC 1995. Information Technology Software
Life Cycle Processes. Février. IEEE Computer Society: New York, NY. ISO/IEC 12207:1994(E).
Jacobson, I. 1994. "Basic Use Case Modeling".
Report on Object Analysis and Design. Juillet/Août.
SIGS Publications: New York. 15-19.
Jacobson, I. 1995. "The Use-Case Construct in
Object-Oriented Software Engineering". Scenariobased design : envisioning work and technology in
system development. Eds. John Wiley and Sons:
New York. 309-336.
Jacobson, I., Booch, G., Rumbaugh, J.1998. The
unified software development process. AddisonWesley: Reading, MA.
John, B.E., Bass, L.J., Adams R.J. 2003.
"Communication across the HCI/SE divide: ISO
13407 and the Rational Unified Process®". In
proceedings of HCI International,. Juin. Elsevier:
Crête. 5.
18. Kruchten, P. 2001. Introduction au Rational Unified
Process. Éditions Eyrolles: Paris, France.
19. Lemieux, F. 2005. "Processus RUP© et conception
centrée sur l'utilisateur : une étude de cas", Mémoire
de maîtrise, École Polytechnique de Montréal. Montréal.
20. Mayhew, D.J. 1999. "Introduction". The Usability
engineering lifecycle. Morgan Kaufman: San
Francisco.
21. Naur, P., Randell, B. OTAN. 1969. "Software
Engineering: Report on a conference sponsored by
the NATO Science Committee". Software
Engineering: Report on a conference sponsored by
the NATO Science Committee. Octobre. Eds. Organisation du traité de l’Atlantique Nord: Garmisch,
Allemagne.
22. Rational. 2002. Rational Unified Process. Version
2002.05.01.305.000.
Rational
Software
Corporation: Cupertino, Ca.
23. Seffah, A., Desmarais, M.C., Metzker, E. 2005.
"HCI, Usability and Software Engineering
Integration: Present and Future" in Human-Centered
Software Engineering . Seffah, A., Gulliksen, J.,
Desmarais, M.C. Eds. Springer. 37-57.
24. Sousa, K.S., Furtado, E. 2003. "RUPi, A Unified
Process that Integrates Human-Computer Interaction
and Software Engineering". Bridging the Gaps
Between Software Engineering and HumanComputer Interaction. Mai. International Federation
for Information Processing: Portland, Or. 41-48.
25. Sousa, K.S., Furtado, E. 2003. "A Unified Process
for Interactive Systems". CLIHC 2003 - Workshop
Integrating Human-Computer Interaction and
Software Engineering Models and Processes . Août.
Semiotic engineering research group: Rio de
Janeiro, BR. 1-6.
26. Sousa, K.S., Furtado, E.. 2003c. "An Approach To
Integrate HCI And SE In Requirements
Engineering". Closing the Gap : Software
Engineering and Human-Computer Interaction .
Septembre. International Federation for Information
Processing: Louvain-la- Neuve, Belgique. 81-88.
27. Yin, R.K. 1989. "Analyzing Case Study Evidence".
Case study research : design and methods. Sage Publications: Newbury Park, CA.
28. Zelkowitz, M.V., Wallace, D.R. 1998. "Experimental Models for Validating Technology". Computer.
Mai. IEEE Computer Society: Piscataway, NJ.
031:5.23-31.
244
2
Nomenclature de critères ergonomiques pour le vote
électronique: éléments d’utilisabilité électorale
Gabriel Michel
Walter Cybis de Abreu
Université Paul Verlaine – Metz –
Laboratoire de Psychologie de Lorraine, Équipe
Transdisciplinaire sur l’Interaction et la Cognition.
BP 30309. Ile du Saulcy – F 57006 Metz cedex 1
[email protected] 03-87-31-52-83
Universidade Federal de Santa Catarina,
Departemento de Informática e Estatística.
Florianópolis, Brésil.
[email protected] 00-1-(514) 340-4711
RESUME
KEYWORDS : Usability criteria, political usability,
Cette communication a pour objectif de faire le point sur
les problèmes posés par l’usage des urnes de vote électronique dans le monde. Elle propose de considérer que
ces problèmes d’utilisation relèvent à la fois de difficultés opératoires classiques et bien connues en ergonomie et de difficultés provenant d’un manque
d’utilisabilité électorale. L’utilisabilité électorale représente un domaine d’application de l’utilisabilité qui vise
à définir et obtenir un haut niveau de crédibilité et de légitimité du processus de vote électronique en plus des
critères classiques d’efficacité, d’efficience et de satisfaction. Enfin, les auteurs proposent douze critères ergonomiques dédiés à la conception et à l’évaluation des urnes de vote électronique. Ainsi, la question de la capacité
de l’ergonomie à donner au vote électronique un statut
de procédure démocratique est posée et discutée tout en
soulignant le rôle déterminant que l’ergonomie devra de
plus en plus jouer dans la conception de systèmes politiques.
electronic voting system, e-vote, e-citizen, e-democracy.
INTRODUCTION
Dans le monde, le développement vertigineux du vote
électronique génère une série d’espoirs sur une meilleure
démocratie tout en suscitant des craintes relatives à de
nouvelles formes électroniques de despotisme. Les expériences de vote électronique menées en Allemagne, Autriche, Australie, Belgique, Brésil, États-Unis
d’Amérique, France, Inde, Suisse, Royaume Uni, Venezuela, etc… ont permis de dégager de nombreux problèmes, dont certains liés à l’ergonomie de ces systèmes.
Ainsi, il apparaît que l’organisation des interactions
électeur-urne peut influencer directement le fonctionnement démocratique et la légitimité des choix. Certains
problèmes pourraient provenir d’une mauvais automatisation du vote manuel: ainsi l’écart entre la procédure
manuelle et l’interaction proposée par le système de vote
peut expliquer un certains nombre d’erreurs des électeurs. Mais il n’existe pas, à notre connaissance, d’études
portant sur ce sujetde même qu’il existe peu d’études sur
l’accessibilité du vote manuel (par exemple aux personnes handicapées ou illettrées). Cependant les urnes électroniques étant des dispositifs nouveaux et de plus numériques il a paru plus naturel de les évaluer. Comme certaines élections et recherches l’ont montré [1, 2, 5, 6, 7,
12, 13], la manière de concevoir les interactions entre le
citoyen et l’urne oriente finalement les comportements
de l’électeur, y compris, dans une certaine mesure, son
choix électoral. Ce constat est d’autant plus vrai lorsque
les électeurs sont fragilisés (handicapés, seniors, illettrés…) [12].
MOTS CLES : Critère ergonomique, utilisabilité politique, urne électronique, e-vote, e-citoyen, e-démocratie
ABSTRACT
This article aims to give a progress report on the problems arising from the use of electronic vote systems in
the world. It proposes considering the fact that these
problems concern traditional and well-known operational
difficulties in ergonomics as well as difficulties stemming from a political lack of usability. Electoral usability
represents a domain of the applicability of the usability
that aims to define and obtain a high level of credibility
and legitimacy of the electronic vote process in addition
to the traditional criteria of effectiveness, efficiency and
satisfaction. Lastly, the authors propose twelve ergonomic criteria dedicated to the design and the evaluation
of the ballot boxes of electronic voting. Thus, the question of the capacity of ergonomics to give the electronic
vote a status of democratic procedure is put forth and
discussed while underlining the determining role and
importance that ergonomics should have in the design of
political systems.
L’urne ne peut donc être résumée à un dispositif de saisie
d’un choix mais représente une structure artefactuelle où
les choix individuels doivent pouvoir s’exprimer le plus
facilement possible, sans exclure aucune personne ayant
droit de vote [15].
Son acceptation sociale implique non seulement un niveau d’utilisabilité très élevé et adapté à tous les électeurs, mais aussi une bonne compatibilité avec les exigences des droits humains fondamentaux et une légiti-
245
3
l'électeur, en particulier si celui-ci est une personne
vieillissante, un aveugle, un analphabète ou un « éloigné
» de la technologie. A maxima, de tels systèmes peuvent
manipuler, innocemment ou volontairement, le vote de
l’électeur en facilitant les votes pour certains partis et
complexifiant les votes pour d’autres. Une autre possibilité est que ces systèmes induisent des erreurs chez ces
populations sensibles impliquant l’annulation de leur
vote. Nous avons montré d’ailleurs par une étude statistique effectuée sur différents pays que le nombre des exclus technologiques pouvait varier de 20% à plus de 50%
selon le niveau de développement et aussi de vieillissement du pays [7]. Ce qui introduit la nécessité de
l’accessibilité de ces systèmes à ces différentes catégories d’exclus. Par rapport aux critères d’utilisabilité et
d’accessibilité classiques on peut souligner que dans le
cadre des urnes de vote:
mité socialement partagée. L’ergonomie de l’urne est
donc un aspect essentiel de son acceptation et de son
usage. Les caractéristiques de l’urne électronique constituent un cadre général facilitant ou complexifiant le
processus de vote. Par voie de conséquence, l’urne électronique doit à la fois présenter une simplicité
d’utilisation très élevée mais aussi montrer sa crédibilité
à restituer les choix démocratiques. L’ergonomie doit
rendre compte de cette double exigence.
L’objectif de ce papier est à la fois de synthétiser les
problèmes posés par l’usage des urnes électroniques
puis, de proposer, présenter et discuter des critères ergonomiques pour concevoir et évaluer ces urnes.
PROBLEMES ERGONOMIQUES POSES PAR LE
VOTE ELECTRONIQUE
D’un point de vue synthétique, nous proposons de classer ces problèmes en deux types: ceux relevant de
l’utilisation opératoire à proprement parler (utilisabilité
classique) et ceux venant d’un déficit de légitimité du
vote (utilisabilité électorale).
•
•
Problèmes d’utilisabilité classique
D’un point de vue synthétique et général (pour des résultats plus précis et tenant compte des types d’urnes et
des pays, le lecteur pourra se reporter à [7]), il a été mis
en évidence qu’environ 80% des répondants (ou électeurs ou observés, selon les méthodologies de recherche
mises en œuvre dans les études) trouvent que les systèmes étaient faciles à utiliser. Cela ne prouve pas que ces
électeurs aient tous réussi à voter correctement comme le
montrent les évaluations que nous avons effectuées ([6],
et [7]). Même si ce score moyen de 80% peut sembler
satisfaisant, il ne doit pas faire oublier les difficultés de
lecture, de lisibilité, de correction des erreurs,
d’apprentissage et de confiance que rencontrent un nombre significatif d’électeurs [1, 2, 6]. Le vote n’est effectivement pas une tâche comme les autres. De tels systèmes
devraient présenter 100% de satisfaction ou encore un
consensus absolu, ou du moins aussi élevé que le vote
classique.
•
leur niveau d’utilisabilité devra être extrêmement
élevé. On pourrait parler de zéros défauts.
elles doivent être obligatoirement accessibles à toutes les catégories de population, ce qui n’est pas le
cas pour toute interface. Actuellement les interfaces
qui se disent accessibles (par exemple certains sites
web) ne sont accessibles que pour un certain type de
handicap et souvent partiellement.
dès sa première utilisation l’électeur a l’impression
de connaître le système.
D’où l’intérêt de se poser la question de la notion
d’expérience utilisateur. Comme on le sait, l’ergonomie
est la qualité de l’adaptation des caractéristiques d’une
interface à l’utilisateur et à sa tache. L’expérience utilisateur est la qualité des relations que s’établissent entre
les utilisateurs et cette interface lors de la réalisation de
leurs tâches. Ces deux qualités sont associées par une
relation de cause et effet. En conséquence, dans une activité de conception nous devons spécifier tant
l’ergonomie de l’interface que l’expérience que cette interface est supposée de produire.
Nous construisons une interface ergonomique à l’aide de
pratiques telles que l’analyse de l’utilisateur, de son travail et de son contexte et en respectant des principes et
règles ergonomiques. Nous spécifions l’expérience utilisateur par les qualités que doivent marquer les relations
entre utilisateurs et cette interface, par exemple, l’utilité,
l’utilisabilité (la productivité et la satisfaction de
l’utilisateur), la confiance, l’accessibilité, etc..
Problèmes d’utilisabilité électorale
Le vote n’est que minimalement une interaction entre un
électeur et un dispositif technique, qu’il soit électronique
ou manuel. Par contre, il est d’abord une interaction entre un électeur et un système politique qui attribue à
l’électeur la possibilité de s’exprimer sur son avenir et
celui de son pays. Aussi, il nous semble que les critères
d’utilisabilité souvent mis en avant comme l’efficacité,
l’efficience et la satisfaction sont insuffisants pour expliquer les difficultés, le rejet, le refus, en bref la non acceptation du vote électronique. En effet, il nous apparaît,
notamment par les études menées sur les urnes de vote
brésilienne et vénézuelienne, qu'un système de vote
électronique peut, à minima, interférer sur la volonté de
L’utilisabilité électorale correspond à une utilisabilité et
à une accessibilité extrêmes. De plus elle intègre deux
critères supplémentaires d’utilisabilité:
-
246
la crédibilité: elle désigne la capacité d’un système
à reproduire fidèlement l’intention de l’utilisateur et
4
-
Les douze principes ergonomiques suivants définissent
un premier cadre de l’utilisabilité électorale. Ils se voudraient universels et instantiables, c’est-à-dire applicables à toutes les urnes quelque soit le pays ou le type
d’élection. Nous présentons ici une partie de ces recommandations, parmi celles qui nous ont paru les plus importantes, illustrées par des exemples de systèmes de
votes dont les évaluations plus détaillées sont décrites en
[7].
souligne donc le fait que l’électeur le juge crédible.
Dans cette perspective, Ong, Lai et Wang [14] proposent de considérer que la « crédibilité perçue »
(perceived credibility) est un élément important de
l’acceptation d’une technologie, du maintien des
motivations de l’utilisateur et de la poursuite des
intentions à utiliser le système. Ce concept de crédibilité perçue, fait donc intervenir le sentiment de
valeur pour expliquer la manière dont l’usager
évalue son acte de vote électronique.
la légitimité: c’est la croyance que la délégation de
la tâche électorale à une machine est un facteur
d’amélioration démocratique (et pas seulement de
réduction des coûts de traitement des suffrages exprimés). La légitimité cautionne l’usage du dispositif électoral, en transférant une partie du po uvoir de
l’humain et de la justice dans le dispositif électoral.
Remarquons à titre anecdotique, que l’arrêt ordonné
par la Cour Suprême des USA du recomptage des
votes en Floride lors de la première élection du Président Bush, est finalement une reconnaissance indirecte que la légitimité du processus électoral
n’était pas garantie.
1. Compatibilité: flexibilité modale
Il s’agit de prévoir différents modes d’entrée et d'affichage d'information. On devrait pouvoir offrir d’autres
alternatives que la combinaison clavier-souris-écran ou
écran tactile ou encore les boutons à presser en face d’un
candidat donné. Ces 3 alternatives correspondent à pratiquement tous les systèmes de vote actuels. Les sorties
pourraient typiquement se présenter sous les formes visuelles, textuelles et picturales (avec possibilité
d’agrandissement), ainsi que sonores, tactiles (Braille)
voire haptiques. Cette flexibilité modale permettrait ainsi
une plus grande accessibilité des systèmes de votes aux
différentes catégorie d’exclus.
La plupart des systèmes de vote utilisés récemment tels
que ceux du Brésil, du Venezuela ou de l’Inde ne proposent qu’un affichage des informations. L’entrée des informations se faisait par un clavier: le braille n’était employé qu’au Brésil pour l’entrée des informations (cf figure 1 ci-dessous) mais sans retour vocal ou sonore.
LA NECESSITE DE LA «CONCEPTION POUR TOUS»
Une urne électronique inadaptée s'avère donc être un
facteur important d’exclusion sociale et politique. En
fait, plusieurs expériences soulignent que l’absence
d’évaluation des urnes électroniques sur des sujets fragiles entraîne des échecs d’utilisation et par voie de
conséquence réduit la légitimité des résultats des élections [4, 6, 13]. L’utilisabilité n’est donc pas un gadget
scientifique qui vise à ajouter un supplément d’âme à un
dispositif technique. Fondamentalement, l’utilisabilité est
le vecteur de la légitimité du processus électoral..
Dans cette perspective, la conception des urnes électroniques pourrait judicieusement s’appuyer sur l’approche
de la «conception pour tous» ou de la «conception inclusive» (design for all) [3]. Cette approche soutient l’idée
que si l’on conçoit un produit accessible aux personnes
les plus handicapées alors le produit résultant sera aussi
accessible aux personnes avec des déficits mineurs et aux
personnes bien portantes.
Figure 1: Clavier numérique avec inscriptions en Braille (Urne
Électronique Brésilienne)
Par contre le modèle AccuVote-SX fabriqué par Diebold
et employé aux élections américaines de 2004 proposait
une interface sonore offrant une flexibilité modale et une
fonction d'agrandissement des parties de l'écran assurant
une lisibilité accrue des informations.
CRITERES ERGONOMIQUES POUR LE VOTE ELECTRONIQUE
Pour atteindre une utilisabilité électorale, il faut que les
concepteurs disposent des principes et règles
d’ergonomie capables de les guider. Les critères ergonomiques pour le vote électronique proposés dans la
suite synthétisent les résultats de différentes recherches,
à la fois des tests utilisateurs et des inspections ergonomiques réalisées sur les principales urnes de votes utilisées ces dernières années.
2. Compatibilité avec les connaissances informati ques et les outils technologiques de l’électeur
Le vote ne doit pas impliquer une bonne connaissance
des technologies informatiques et de leurs manipulations.
En particulier il ne doit pas nécessiter la possession d’un
ordinateur et d’une connexion Internet.
247
5
Dans certains cas, pour voter, il faut posséder un ordinateur et une connexion Internet. C’est le cas des projets de
Genève [10] ou de Neufchatel en Suisse. Il s’agit d’un
système de vote électronique accessible depuis Internet.
On attribue à l’électeur, également internaute, un code
confidentiel unique, qu'il recevra en même
te!:m;;;;:!!!mps que le matériel de vote à relier à sa machine. Bien sûr, cela suppose que l’utilisateur possède un
ordinateur et qu’il sache installer les périphériques nécessaires. Pour voter en ligne, l'internaute devra prouver
son identité au moyen d’un code d'accès, d’un mot de
passe et d’une carte à numéros, pour ensuite pouvoir accéder à la page permettant d’effectuer le vote.
interfaces étudiées (celle de 1996 et celle de 2002) de
l’urne brésilienne dans ce sens en étaient totalement dépourvues.
La complexité de la procédure d’authentification (mot de
passe à retenir, carte à numéro à conserver, code secret à
retenir) pose à n’en pas douter d’énormes problèmes
d’accessibilités pour tous, et surtout aux personnes
âgées et aveugles (cf figure 2 ci-dessous).
On constate sur l’écran initial, un manque total de guidage: la seule incitation étant le premier curseur qui clignotait (cf. figure 3 ci-dessus). La seule indication donnée, en dehors des 5 caractères de soulignement, est le
titre de l’écran signifiant «Conseiller Municipal». Des
informations de guidage un peu plus riches telles que
l’explication de ce qu’on attend de l’électeur (voter pour
le conseiller municipal), de la procédure proposée (taper
2 chiffres, pour la liste, ou 5 pour le candidat puis validation) auraient été indispensables.
Figure 3 : Écran initial pour le vote du conseiller municipal écran de confirmation du vote - UEB en 1996
L’utilisation d’un périphérique supplémentaire à relier à
la machine de l’utilisateur pour pouvoir lire la carte
électronique sous-entend deux choses: que l’utilisateur
possède un ordinateur chez soi, tout en étant connecté à
Internet, et qu’il sache se servir d’un ordinateur ainsi que
des différentes connectiques qui y sont liées (appareil de
vote, etc..). Une grande catégorie de la population risque
donc d’être exclue avec ce système, à savoir les non habitués à la technologie et les personnes ne possédant pas
d’ordinateur (ou un ordinateur non compatible avec le
périphérique fourni). Les personnes aveugles, malvoyantes et les seniors sont elles aussi totalement exclues
car le Web leur est difficilement accessible
Quand cela est possible, ajouter des photos de candidats
et/ou les logos des partis au moment du choix et non de
la validation.
4. Guidage: délimitation claire des votes
Lorsqu’il faut effectuer dans la même session plusieurs
votes, il faut fournir des indications évidentes (visuelles
et/ou sonores) de la fin de chaque vote et du début du
vote suivant.
Figure 4 : Séquence d'écrans principaux de l'urne électronique
brésilienne employée aux élections municipales. Les flèches
rouges montrent l'effet d'une annulation.
Figure 2 : Écran d'identification du système de vote par I nternet employé en Suisse.
Les différents bulletins de vote de l'urne électronique
brésilienne ont tous globalement la même apparence et le
même comportement. Ils présentent d'abord un écran
d'invitation à la saisie d'un code de candidat, suivi d'un
autre de demande de confirmation de cette intention (cf
figure 3). En cas d'annulation, la page d'invitation est
présentée à nouveau. Le dispositif signale l'accomplissement d'un vote intermédiaire (qui n'est pas le dernier
3. Guidage renforcé et amical
L’interface doit accueillir les électeurs et les inviter à
l'interaction d'une façon amicale (personnalisée), claire et
détaillée, tout en conservant un style concis. Les libellés
doivent être précis et complétés par des instructions claires et détaillées concernant la tâche de vote. Les deux
248
6
dans la séquence de votes) par un bref signal sonore qui
est accompagné de la présentation de la page initiale du
bulletin suivant. Il n'y a donc pas un message visuel explicite confirmant que ce vote a été pris en compte. Tout
ce que l'électeur peut observer lorsqu'il accomplit son
vote est la présentation de la page d'invitation du bulletin
de vote suivant, d'apparence générale identique à celle du
bulletin que l'on vient de quitter. Visuellement parlant,
l'effet d'une confirmation et celui d'une annulation se ressemblent beaucoup (cf figure 4 ci-dessus).
On peut imaginer qu'en cas d'incidents, l'électeur moins
avisé peut ne pas réaliser qu'il y a eu une transition de
bulletin. Dans ce cas, il va tenter de voter pour un candidat à une élection (conseilleur municipal) sur le bulletin
de vote de l'élection suivante (maire).
Figure 5: La machine électronique de vote (Electronic Voting
Machine) employé en Inde
6. Focalisation de l'attention
Les informations et les contrôles doivent être disposés
aussi proches que possible les uns des autres de manière
à toujours focaliser l’attention des électeurs sur un même
point de l'interface. Ainsi, lorsqu'un écran tactile n'est
pas disponible, les touches du clavier devraient être disposées autour de l'écran.
Le système Platinium aux Etats Unis comporte lui aussi
plusieurs écrans successifs: la navigation d’un écran à
l’autre se fait grâce aux boutons «Next» et «Preview».
Indiquer à tout moment le vote correspondant à cet écran
et le numéro de l’écran (par exemple 3 sur
5)améliorerait le guidage.
5. Feedback/contrôle local et global
Lorsque plusieurs votes ont été effectués il faut présenter, à la fin des interactions, un bilan de ces votes, et
donner aux électeurs la possibilité de tout annuler et de
recommencer le vote. Pour chaque vote particulier il doit
également être possible de corriger ce vote, de revenir au
vote précédent pour vérifier ses choix et ainsi de naviguer entre les différents votes effectués tant que
l’ensemble des votes n’aura pas été validé.
Figure 6 : Urne de vote du Brésil séparant l'écran, à gauche du
clavier, à droite.
Dans l’urne brésilienne, (cf figure 6 ci-dessus) ce n’est
pas le cas: à droite de l’écran se trouve un clavier numérique. Beaucoup d’électeurs ne regardaient que le clavier
et parfois ignoraient totalement l’écran.
L'urne électronique employée en Inde [11] (cf figure 5)
est composée uniquement par des tablettes numériques
sans ressources d'affichage de données. Sur celles-ci les
informations et contrôles sont disposées selon une matrice de 16 lignes et 4 colonnes. Chaque ligne présente le
nom d'un candidat, le symbole de son parti, une petite
lumière rouge et un bouton bleu pour commander le vote
pour ce candidat
7. Lisibilité accrue
Ce critère s’applique surtout pour les malvoyants et les
seniors. Pour cela il faut prévoir des contrastes importants ainsi que des mécanismes simples d'agrandissement.
Le système supporte jusqu'à 4 tablettes, ainsi il est possible d’avoir jusqu'à 64 candidats par élection. Lorsqu'un
vote est accompli, un signal sonore se fait entendre et un
voyant rouge clignote pour quelques instants sur la ligne
du candidat choisi. Au bout de quelques secondes, le
voyant s’éteint et le son s’arrête: l'électeur ne trouvera
plus aucune trace de son vote sur l'interface. Les manques de feedback et de possibilités de modifier un vote
accompli sont des défauts du système d’autant plus graves qu’il est possible de voter pour plusieurs candidats
sur une même tablette.
Pour la plupart des interfaces de vote, le manque de
contraste, le choix de la police de caractères et la densité
informationnelle nuisent à la lecture des informations,
particulièrement chez les déficients visuels. Par exemple
dans le vote Platinium aux Etats-Unis, la case à sélectionner tactilement était peu lisible et de surface réduite
(donc difficile à sélectionner en particulier pour les seniors).
Ou encore le eSlate Electronic Voting System [12] (cf
figure 7 ci-dessous), de Hart InterCivic, défini sur un
palm-top spécialement conçu pour le vote électronique.
249
7
9. Protection des votes importants
Il a été utilisé aux Etats-Unis dans plusieurs états, notamment lors des élections présidentielles.
Etant donné que les situations d'erreurs peuvent entraver
les votes des électeurs, lorsque plusieurs votes sont à définir dans une seule séance, il est conseillé de commencer par les votes les plus importants.
L'urne électronique employée au Brésil depuis 96 oblige
l'électeur à suivre une séquence de votes définie au préalable: ainsi les votes les plus importants sont proposés à
la fin du processus. Cette situation implique un manque
de protection de l'élection la plus importante, celle du
président. Ce dernier vote est dépendant de la réussite
des votes antérieurs. En 2004, l'électeur était forcé de
passer par 5 autres bulletins, comparativement plus difficiles à remplir, avant d'arriver au bulletin destiné au vote
pour le président. On a pu montrer que ce dispositif met
en péril les votes des personnes le plus défavorisées qui
souvent n'interagissent qu'avec le clavier, ne regardant
pas les informations sur l'écran [6]. En cela elles suivent
un script d'actions sur le clavier basé sur des répétitions
des séquences des frappes: elles se focalisent sur les
touches numériques permettant de saisir les codes des
candidats et sur la touche "Confirmer". Une erreur sur ce
script va déclencher un dialogue d'exception qui sera
ignoré par les électeurs qui ne regardent pas l'écran.
Cette situation amènera inévitablement à des incidents
sur les votes suivants. Il est donc probable que les 5 votes qui précèdent celui du président aient influé sur la réussite de ce dernier vote (particulièrement dans le cas
des électeurs les moins favorisés ).
Figure 7 : Interfece de l’eSlate Electronic Voting System.
Le texte est difficilement lisible pour des seniors ou des
malvoyants. Il en est de même pour le texte situé sur les
touches. Tourner la roue “SELECT” est probablement
source de problèmes, particulièrement pour les seniors.
En dehors du contraste, et comme pour les interfaces
destinées aux malvoyants ou aux seniors, il faut une police de caractères et une taille de caractères appropriées
ainsi qu’une densité informationnelle limitée.
8. Langage électoral :
Faire appel aux termes de langage spécifiques des élections, éviter d'employer des dénominations liées à la
technologie. Par exemple, utilisez «Voter» au lieu de
«Confirmer» ou «valider».
10. Correction intuitive des erreurs.
On sait que plus le niveau de développement d’un pays
est bas, plus nombreux seront les exclus technologiques
(se référer à [7] pour les statistiques). Pour ces pays, le
niveau d’accessibilité des urnes est encore plus sensible
et en conséquence ces principes devraient être respectés
à la lettre, en particulier celui du contrôle global. Même
l'électeur le plus défavorisé devrait avoir à tout moment
l'opportunité de corriger aisément ses différentes actions
et de tout annuler.
Dans le système américain Sure Vote ou dans le projet
suisse de Neufchatel il fallait mémoriser et manipuler
plusieurs codes. Il en était de même des différentes urnes
brésiliennes: 2 nombres à retenir en 1996, puis 6 en
2002.
Pour l’urne du Brésil la validation ou la correction
étaient ensuite proposées après la saisie du code du candidat(cf figure 3) : les tests utilisateurs ont montré que
certains électeurs suite à la saisie de leur code restaient
bloqués devant cet écran de validation/correction, parfois
pendant plusieurs minutes, ne sachant que faire, allant
jusqu’à abandonner. Les interview qui ont suivi ont
montré que pour ces électeurs le terme valider n’avait
pas de sens.
Le système employé en Inde est totalement dépourvu de
correction d'erreurs. En effet, les tablettes numériques
sont conçues de façon à intégrer la sélection d'un candidat et la confirmation du vote sur une même action de
l'utilisateur. Son vote est accompli au moment même où
il presse sur un des boutons bleus de la tablette. Avec
cette machine l'électeur n'est pas autorisé à commettre
d’erreurs.
Pour le eSlate Electronic Voting System (cf figure 7),
l’interface utilisateur manque de clarté. Le bouton “SELECT” est utilisé pour modifier le choix mis en évidence
sur l’écran (en bleu clair). C’est le bouton “ENTER” qui
effectue la sélection.
11. Compatibilité avec les objectifs des électeurs
Il doit avoir une correspondance directe entre les objectifs des électeurs (voter pour un candidat, pour un parti,
voter en blanc, annuler le vote) et les options de commande dans l'interface. La réalisation de ces objectifs ne
250
8
doit jamais être associée à des actions exotiques, comme
saisir le code d'un candidat inexistant.
de l’urne électronique, mais également les compléter par
les recommandations, normes et critères ergonomiques
classiques [3]. Il faut noter aussi que lorsque le vote est
un acte obligatoire les priorités des concepteurs en terme
d'utilisabilité sont probablement l'efficacité et l'efficience. Pour les décideurs, dans le cas du vote obligatoire, la satisfaction des électeurs semble être facultative.
Par contre, lorsque le vote est non obligatoire, les urnes
devraient devenir un moyen d’augmenter le nombre de
votants par rapport au vote traditionnel. Dans ce cas, la
satisfaction des électeurs devient un objectif important
du système de vote électronique. Des principes concernant une conception esthétique et minimaliste, tel que
ceux définis par Nielsen, pourraient alors s'appliquer,
sans pour autant nuire à l'accessibilité des interfaces.
C’est le cas de l’urne de vote indienne, il y a un manque
de compatibilité entre l'intention légitime des électeurs
de voter blanc et les possibilités du système. En effet, on
observe qu'il n'y a pas de commande associée au vote
blanc sur la tablette et que la séance de vote ne se clôture
qu'après avoir choisi un candidat par pression sur un des
boutons bleus. L'absence de cette possibilité pour l'électeur génère donc une situation d'impasse. Ainsi avec ce
dispositif il se voit privé de manifester son insatisfaction
avec le statu quo, car il n'a également pas pu voter nul.
12. Support à la confiance
Les interfaces électroniques de vote doivent rassurer
l’électeur sur la fiabilité du système, en prévoyant par
exemple, l'impression du bulletin de vote rempli électroniquement. L'électeur pourra faire confiance à un système que lui permettre de tenir dans ses mains et vérifier
son vote avant de le déposer dans l'urne.
Enfin n’oublions pas que si l’on veut que tout le monde
puisse voter, et pour limiter le nombre des exclus, et audelà du respect des recommandations ergonomiques, il
est indispensable que l’accès aux urnes à tous soit possible avant le vote pour une familiarisation et un apprentissage du système. Il faut aussi, tant qu’on n’est pas certain
qu’un système de vote électronique donné permet à tous
de voter, offrir la possibilité, pour ceux qui le désirent,
de voter de manière classique.
On constate que la plupart des principales urnes électroniques au monde ne proposent pas de possibilités pour
rassurer les électeurs de la fiabilité des votes accomplis.
Comment les gens qui utilisent des urnes électroniques
aux USA, au Brésil et en Inde peuvent savoir si leurs
votes ont été pris en compte correctement par le système
? Ils ne voient pas d'objets tangibles associés à leurs
votes et ne comprennent pas les arguments techniques
avancés par les autorités responsables. À l'heure actuelle
le seul dispositif capable de rassurer l'utilisateur de la
prise en compte du vote par le système est celui employé
au Venezuela [16] (cf figure 8 ci-dessous). Immédiatement après avoir effectué son vote, l’urne imprime un
bulletin en papier grâce auquel l’électeur peut contrôler
le résultat de son vote. L’électeur dépose ensuite ce bulletin à l'intérieur d'une urne en carton placée àcoté du
dispositif électronique. L'électeur peut partir rassuré car
il existe une trace matérialisée de son vote qui pourra
être récupérée et éventuellement recomptée. Malheureusement ce contrôle n’est pas prévu dans la plupart des
systèmes de vote électronique actuels.
CONCLUSION
L’ergonomie peut-elle permettre au vote électronique
d’accéder au statut de procédure démocratique? C’est là
une question fondamentale et difficile, dont l’enjeu est
pratique et théorique pour la science ergonomique!
L’urne électronique est un véritable défi pour
l’ergonomie qui ne peut plus se contenter de scores
d’utilisabilité élevés. Elle doit raisonner en performance
absolue, c'est-à-dire avec des exigences de performances
comparables, voire meilleures, que celles du vote manuel. Sur le plan théorique, les enjeux de l’utilisabilité
électorale obligent sans doute une évolution de certaines
notions d’ergonomie et un rapprochement avec des disciplines comme le droit électoral, les sciences politiques
et la sécurité informatique. Il s’agit donc d’une ouverture
vers les sciences sociales et politiques.
La conception de tout système de vote électronique doit
se réaliser dans le contexte des cycles du génie de
l’utilisabilité: la structure générale de ce processus étant
analogue à celle proposée par la norme ISO 13407 [11].
Avec, bien-sûr, la nécessité d’impliquer des utilisateur
finaux pendant tout le cycle. Toutes les catégories
d’utilisateurs devraient être concernés, particulièrement
les exclus de la technologie. Les principes généraux de
conception devraient intégrer les critères ergonomiques
pour le vote électronique, et la spécification de
l’utilisabilité doit prévoir des exigences de productivité
et de satisfaction très élevées,. Ces interfaces doivent,
évidement être validés par toutes les parties prenantes:
Figure 8 : Système Smartic, employé au Venezuela, qui imprime un bulletin en papier que l'utilisateur peut véri fier avant
de le déposer dans l'urne en carton.
Les concepteurs d'urnes électroniques devraient appliquer non seulement ces principes spécifiques au domaine
251
9
les autorités, les fabricants et les électeurs. A chaque cycle de développement les tests d’utilisabilité doivent
avoir un caractère très rigoureux et exigeant. Il n’est pas
possible d’admettre des erreurs d’ergonomie sur les urnes ni des niveaux d’utilisabilité en dessous de l’optimal.
Le respect de ces critères devrait également pouvoir être
contrôlé avant chaque mise en place de tout système de
vote électronique par un groupe indépendant d’experts
internationaux en utilisabilité. Il n’y a qu’à ces conditions minimales que l’on pourra limiter l’exclusion démocratique par le vote électronique.
BIBLIOGRAPHIE
1.
2.
Bederson, B. B., Lee, B., Sherman, R., Herrnson, P.
S., Niemi, R. G. (2003). Electronic Voting System
Usability Issues. CHI 2003, ACM Conference on
Human Factors in Computing Systems, CHI Letters,
5(1), pp. 145-152. Available online as tech report:
http://www.cs.umd.edu/local-cgibin/hcil/sr.pl?number=HCIL-2002-25
Brangier, E., Barcenilla, J (2003). Concevoir un
produit facile à utiliser: adapter les technologies à
l’homme. Paris: Éditions d’organisation.
4.
Brangier, E., Bobillier-Chaumon, M-E., Cybis De
Abreu, W., Michel, G., Pino, P., Van De Weerdt, C.
(2002). Analyse psycho-ergonomique de l'interaction entre l'homme et les NTIC (nouvelles technologies de l’information et de la communication): introduction à une psychologie de « environnement
digital », Hygiène et Sécurité du travail. N°189,
4ème trimestre, 15-25.
5.
6.
Cybis, W. A., Michel, G. & Brangier, E., (2006,
soumis). L’ergonomie dans l’enjeu démocratique du
vote électronique des citoyens : éléments
d’utilisabilité politique, in Bobiliier Chaumon (et al,
Eds) "La relation de service : nouveaux usages,
nouveaux acteurs".
8.
e-voting (2206), site de l’Etat de Genève consacré au
vote
par
Internet,
disponible à l'adresse http://www.geneve.ch/evoting/
9.
Hart Intercivic (2206) Electronic Voting System e S l a t e
( 2 0 0 6 )
,
disponible
à
l'adresse
http://www.hartintercivic.com/innerpage.php?pageid
=26
10. India Elections (2006), The Electoral System of Ind i a ,
d i s p o n i b l e
à
l ' a d r e s s e
http://www.indianelections.com/electoralsystem/
electricvotingmachine.html
Bederson, B.B., Bongshin Lee, B., Robert M.
Sherman, R.M., Paul S. Herrnson, P.S., Richard G.
Niemi, R.G. (2003). Electronic voting system usability issues, Proceedings of the SIGCHI conference on Human factors in computing systems, April
05-10, 2003, Ft. Lauderdale, Florida, USA
3.
7.
11. ISO (1999). ISO 13407: Human-centred design
processes for interactive systems. Geneva: International Standards Organisation
12. Michel, G. & De Abreu, W. C. (1999). Vers une exclusion technologique : expérience de l'évaluation
ergonomique du vote électronique au Brésil, In B.
Nanard (Eds), IHM 99, Toulouse: Cépaduès, 53-62.
13. Michel, G. A., Cybis, W. A., 2005. Electronic voting
for all : the experience of the Brazilian computerized voting system, UPA Conference 2005, Montreal, Canada
14. Ong, C-S., Lai J-Y., & Wang Y-S. (2004). Factors
affecting engineers’ acceptance of asynchronous elearning systems in high-tech companies. Information & Management, Volume 41, Issue 6, July 2004,
Pages 795-804
Briand,M.(2006), Machines à voter, automatiser ou
renforcer la participation, Brest Ouvert
http://www.brestouvert.net/article.php?id_article=79
7 (Accédé le 7 Janvier 2006).
15. Robertson, S.P., (2005). Voter-centred design: toward a voter decision support system. ACM Transaction on computer-human interaction (TOCHI),
V o l
1 2 ,
I s s u e
Cybis, W. A., Michel, G. A., 1999. The interference
of new technologies and the dangers of their
broader use: the case of computerized voting in
Brazil – an ergonomic evaluation., 2nd Brazilian
Workshop on HCI and Human Factors in Computer
Systems; Campinas, 1999 (In Portuguese).
16. Smartmatic (2006), Special: Venezuelan Elections
2004,
disponible
à
l'adresse
http://www.smartmatic.com/infography_01.htm
252
Esquisse