Barthet 1988

logiciels interactifs et ergonomie
modles et mthodes de conception

par Marie-France BARTHET Professeur l'Universit des Sciences Sociales de Toulouse 1988
Version lectronique Lire l'avertissement
Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988
Rsum
(extrait du quatrime de couverture)
L'objectif de ce livre est de montrer qu'il est possible de raliser des logiciels interactifs beaucoup plus adapts aux utilisateurs en modifiant les mthodes d'analyse et de programmation de manire intgrer des lments provenant de l'ergonomie ou de la psychologie cognitive. L'auteur se situe dans le cadre de l'informatique des organisations et des applications collectives de type professionnel ou grand public qui connaissent actuellement un grand essor. Cet ouvrage s'adresse tous ceux qui interviennent dans le processus de conception des applications interactives, que ce soient les informaticiens-analystes, les conseillers informatiques, les ergonomes ou les formateurs.
Avertissement
L'ouvrage de Marie-France BARTHET "Logiciels interactifs et ergonomie, modles et mthode de conception" est paru en 1988 aux ditions Dunod Informatique (Bordas, Paris) avec l'ISBN 2-04018726-X. L'ouvrage original comporte 219 pages, une prface, une bibliographie, et un glossaire. Il est actuellement puis chez cet diteur, il reste cependant encore quelques exemplaires disponibles chez certains libraires. Cette version lectronique de l'ouvrage a t ralise en 1999 par Francis JAMBON, partir des fichiers informatiques originaux, avec l'accord et galement l'aide prcieuse de son auteur. L'ouvrage vous est prsent en version limite, en effet la prface et une partie du rsum n'ont pu tre retrouvs. Il se peut galement que certaines parties soient d'une version antrieure l'ouvrage paru chez Dunod Informatique, ou que des erreurs se soient glisses dans le processus de conversion aux formats HTML et PDF. En outre, la pagination a subit quelques modifications. C'est pourquoi il est prfrable, en cas de doute sur le contenu ou dans les citations, de se rfrencer l'ouvrage paru chez Dunod Informatique. Vous pouvez consulter et/ou tlcharger cet ouvrage pour votre usage personnel uniquement, " des fins scientifiques et ducatives dans un esprit universitaire". Il ne doit pas en tre fait de copies ni de diffusions sous quelque forme que ce soit sans l'accord explicite de son auteur, Marie-France BARTHET. L'ouvrage, quelque soit sa forme, n'est pas libre de droits. "Toute reprsentation ou reproduction, intgrale ou partielle, faite sans le consentement de l'auteur, ou de ses ayant-droits, ou ayantcause, est illicite (loi du 11 mars 1957, alina 1 er de l'article 40). Cette reprsentation ou reproduction, par quelque procd que ce soit, constituerait une contrefaon sanctionne par les articles 425 et suivants du Code pnal. La loi du 11 mars 1957 n'autorise, aux termes des alinas 2 et 3 de l'article 41, que les copies ou reproductions strictement rserves l'usage priv du copiste et non destines une utilisation collective d'une part, et d'autre part, que les analyses et les courtes citations dans un but d'exemple et d'illustration"
Sommaire
Prambule.................................................................................................................................7
Chapitre 1 : L'INTERFACE HOMME-ORDINATEUR.......................................................8

1.1 La conception usuelle des logiciels interactifs...........................................................................8 1.1.1 Les limites des mthodes actuelles.......................................................................................8 1.1.2 Les grands mythes..........................................................................................................14 1.1.3 L'apport d'autres disciplines..............................................................................................16 1.1.4 Les diffrents points de vue...............................................................................................18 1.2 Les principaux concepts dvelopps.....................................................................................21 1.2.1 Les concepts classiques....................................................................................................21 1.2.2 Les nouveaux concepts sur les applications interactives et les utilisateurs..................................23 1.3 Prsentation de l'ouvrage.....................................................................................................28 1.3.1 Composition gnrale......................................................................................................28 1.3.2 Comment le lire?............................................................................................................29
Chapitre 2 : LES STRUCTURES PROFONDES DES APPLICATIONS INTERACTIVES...............................................................31

2.1 La psychologie cognitive et l'utilisateur de logiciel..................................................................32 2.1.1 Elments pertinents.........................................................................................................32 2.1.1.1 L'image oprative......................................................................................................32 2.1.1.2 La planification hirarchique........................................................................................33 2.1.1.3 Utilisateurs expriments et dbutants...........................................................................35 2.1.1.4 Tche et activit.......................................................................................................37 2.1.2 Possibilits d'extrapolation...............................................................................................38 2.2 La Reprsentation Conceptuelle de l'application interactive....................................................41 2.2.1 Introduction...................................................................................................................41 2.2.2 Les paramtres variables de la Reprsentation Conceptuelle.....................................................43 2.2.2.1 Principes de base......................................................................................................43 2.2.2.2 Prise en compte de la variabilit dans la R.C.................................................................49 2.2.2.3 Description dtaille de la R.C....................................................................................52 2.2.2.4 Formalisme graphique...............................................................................................59 2.2.3 Les paramtres constants de la Reprsentation Conceptuelle....................................................63 2.2.3.1 Aides au travail........................................................................................................64 2.2.3.2 Aides l'apprentissage...............................................................................................65 2.2.3.3 Les possibilits d'volution........................................................................................66
Chapitre 3 : LES ASPECTS DE SURFACE DES APPLICATIONS INTERACTIVES...............................................................69

3.1 L'apport de la psychologie cognitive la Reprsentation Externe............................................70 3.1.1 Les structures de la mmoire humaine.................................................................................70 3.1.2 Exprience et automatisme................................................................................................73
3.2 L'apport de l'ergonomie la Reprsentation Externe.............................................................74 3.2.1 Les paramtres de l'interface..............................................................................................74 3.2.2 Recommandations ergonomiques pour les paramtres de l'interface...........................................76 3.2.2.1 Squencement des oprations......................................................................................76 3.2.2.2 Langage d'interaction.................................................................................................77 3.2.2.3 Les dispositifs d'entre...............................................................................................81 3.2.2.4 Les dispositifs de prsentation.....................................................................................81 3.2.2.5 Le temps de rponse..................................................................................................85 3.2.2.6 Le traitement des erreurs.............................................................................................86 3.2.2.7 Le guidage...............................................................................................................88 3.3 La Reprsentation Externe...................................................................................................88 3.3.1 Les paramtres standard de la Reprsentation Externe.............................................................89 3.3.1.1 Traduction des paramtres constants.............................................................................89 3.3.1.2 Les options standard..................................................................................................95 3.3.2 Les paramtres de la Reprsentation Externe spcifiques l'application......................................97 3.3.2.1 Reprsentation Externe des oprations...........................................................................97 3.3.2.2 Reprsentation Externe des procdures.........................................................................100
Chapitre 4 : STRUCTURE INTERNE DES LOGICIELS INTERACTIFS...................105

4.1 Prsentation des systmes de gestion d'cran multifentre.......................................................105 4.1.1 Les fonctionnalits d'un SGM vues par l'utilisateur..............................................................106 4.1.1.1 Liste des fonctions...................................................................................................106 4.1.1.2 La mise en oeuvre de ces fonctions..............................................................................108 4.1.2 Les caractristiques d'un SGM pour le programmeur.............................................................111 4.1.2.1 L'architecture...........................................................................................................111 4.1.2.2 Les proprits..........................................................................................................112 4.1.2.3 La mise en oeuvre....................................................................................................114 4.1.3 Exemples.....................................................................................................................115 4.1.3.1 Le SGM de Macintosh..............................................................................................115 4.1.3.2 Les SGM sous UNIX...............................................................................................117 4.2 Traduction des Reprsentations Conceptuelle et Externe........................................................119 4.2.1 Architecture gnrale de la Reprsentation Interne.................................................................120
Chapitre 5 : DIANE METHODE DE CONCEPTION D'APPLICATIONS INTERACTIVES.........................................................124

5.1 Etude de l'existant.............................................................................................................125 5.1.1 Collecte de l'information.................................................................................................125 5.1.2 Description du systme existant........................................................................................127 5.1.2.1 Les buts d'un poste de travail.....................................................................................128 5.1.2.2 Les diffrentes procdures existantes.............................................................................133 5.2 Conception d'une application interactive..............................................................................136 5.2.1 Mthode de conception de la Reprsentation Conceptuelle.....................................................137 5.2.1.1 Les diffrentes procdures de la Reprsentation Conceptuelle............................................137 5.2.1.2 Les lments d'une procdure.....................................................................................140 5.2.1.3 Dmarche globale pour la Reprsentation Conceptuelle...................................................141 5.2.2 Mthode de conception de la Reprsentation Externe............................................................143 5.2.2.1 Traduction de la Reprsentation Conceptuelle...............................................................144 5.2.2.2 Prise en compte des critres ergonomiques....................................................................145 5.2.2.3 Prise en compte des possibilits techniques..................................................................146 5.3 Prototypage.......................................................................................................................149 5.3.1 Elments tester............................................................................................................149 5.3.2 Comment tester.............................................................................................................151 5.4 Etude de cas "Bibliothque"..............................................................................................152 5.4.1 Le systme d'information existant.....................................................................................153 5.4.1.1 Les fonctions...........................................................................................................153
5.4.1.2 Utilisateurs.............................................................................................................153 5.4.2 Conception du nouveau systme.......................................................................................158 5.4.2.1 Conception de la Reprsentation Conceptuelle...............................................................158 5.4.2.2 Conception de la Reprsentation Externe......................................................................170
Chapitre 6 : DIANE METHODE DE DIAGNOSTIC......................................................174

6.1 Diagnostic d'un logiciel interactif........................................................................................174 6.1.1 Dmarche.....................................................................................................................174 6.1.2 Grille d'analyse..............................................................................................................175 6.2 Cahier des charges d'un logiciel interactif............................................................................182 6.2.1 Spcifications gnrales...................................................................................................183 6.2.2 Spcifications particulires l'application...........................................................................184 6.3 Etude de cas " RTR".........................................................................................................185 6.3.1 Analyse des crans.........................................................................................................185 6.3.2 Enchanements d'crans...................................................................................................192
BIBLIOGRAPHIE.................................................................................................................197
1 - Informatique......................................................................................................................197 2 - Ergonomie.........................................................................................................................198 3 - Livres divers......................................................................................................................200
GLOSSAIRE.........................................................................................................................202
Prambule
L'objectif de ce livre est de montrer qu'il est possible de raliser des logiciels interactifs beaucoup plus adapts aux utilisateurs et qu'il faut pour cela modifier les mthodes d'analyse et de programmation de manire intgrer des lments provenant de l'ergonomie ou de la psychologie cognitive. Nos propos se situent dans le cadre de l'informatique des organisations et concernent plutt des applications collectives de type professionnel ou grand public (c'est--dire que nous n'avons pas fait un travail spcifique sur les systmes interactifs d'aide la dcision ou la conception). Les applications interactives de type professionnel ou grand public connaissent l'heure actuelle un grand essor et concernent donc un nombre d'utilisateurs de plus en plus important. Ce simple fait rend d'autant plus ncessaire d'intgrer ces logiciels tous les lments permettant un apprentissage et une manipulation plus aiss pour des utilisateurs qui n'ont ni le besoin ni l'utilit de rentrer dans la logique informatique. Mais l'argument fondamental qui amne se proccuper de l'optimisation de l'interaction homme-machine est un prolongement logique de la volont d'automatisation. En effet, l'objectif essentiel de l'automatisation est d'augmenter la rentabilit de l'organisation en reportant une partie du travail des personnes vers les machines et en augmentant, si possible, la fiabilit de l'ensemble. Dans le cadre de l'informatique des organisations o les personnes ne peuvent jamais compltement tre remplacs par des automates (comme c'est le cas pour certaines chanes de production), la diminution maximale du travail humain et la fiabilit maximale de l'ensemble sont lies la qualit de l'interaction homme-machine. La dernire raison que l'on peut avoir de se proccuper de l'interaction homme-machine est d'optimiser le travail de l'informaticien quand on sait qu'en moyenne 50% du code sert la gestion de la communication homme-machine. Ce livre s'adresse toutes les personnes qui interviennent dans le processus de conception des applications interactives que ce soit de manire globale comme les informaticiens-analystes ou de manire partielle comme les conseillers extrieurs, les correspondants informatiques, les ergonomes, les formateurs.
Chapitre 1 : L'INTERFACE HOMMEORDINATEUR

Ce premier chapitre a un double but car il prsente d'une part l'tat de l'art dans la conception des applications interactives, d'autre part les principaux concepts dvelopps dans ce livre.
1 . 1 La conception usuelle des logiciels interactifs

Ce paragraphe prsente d'une part l'ensemble des pratiques, des tendances et des prsupposs qui servent de guides dans la conception des applications interactives, d'autre part les apports que l'on peut attendre de disciplines autres que l'informatique.
1.1.1 Les limites des mthodes actuelles

La conception des logiciels interactifs est faite, dans la trs grande majorit des cas, par les informaticiens-analystes qui disposent, pour cela, de mthodes d'analyse et de conception des systmes d'informations automatiss. Ces mthodes les amnent "dduire" l'interface entre l'utilisateur et l'ordinateur de la logique de fonctionnement des systmes d'information. Pour illustrer ce propos, nous faisons rfrence ici deux mthodes bien connues en France, MERISE et AXIAL, qui sont assez caractristiques de la pratique dveloppe dans le domaine de la spcification des applications interactives. La diffrence essentielle sur les applications interactives entre ces deux mthodes tient au degr de dtail des spcifications: - quand on a fini d'appliquer la mthode MERISE (Tar,83), on a des spcifications dtailles des donnes et des traitements associs, mais on ne dispose d'aucune spcification prcise sur le dialogue homme-machine; la consquence immdiate est que l'essentiel de l'interaction homme-machine est dfinie au niveau de la programmation un moment o il est trs difficille d'intgrer le
8
point de vue de l'utilisateur car on est alors entirement absorb par les contraintes matrielles et logicielles. - par contre quand on applique la mthode AXIAL (Pel,86) , on aboutit un ensemble de spcifications prcises concernant l'interaction homme-machine du point de vue de l'analyste sans prise en compte explicite de l'utilisateur. Pour illustrer l'absence de prise en compte du point de vue de l'utilisateur, nous prenons l'exemple suivant dvelopp partir du formalisme de la mthode AXIAL: Cet exemple dcrit un diagramme du dialogue utilisateur-machine qui visualise les enchanements possibles entre un utilisateur et un programme "Commande" qui a pour rle de permettre l'enregistrement des caractristiques d'une commande. Le cas normal, c'est--dire sans erreur, est prsent dans la partie verticale gauche; les erreurs ou les possibilits de sortir de cet enchanement normal sont situes dans la partie droite de schma. La signification du formalisme est la suivante:
Message d'entre, saisie par l'utilisateur Message de sortie affich sur l'cran par l'ordinateur
Message de sortie de l'ordinateur sur l'imprimante
Traitement automatis
Appel menu
Menu E0
Choix transaction "Commande"
Demande caractristiques client E1
n client
Retour menu
Demande commande E2
Client inconnu E1
- n article - quantit
Retour menu
Affichage nom prix, article E2
N article inconnu E2
Quantit non disponible E2
Validation commande
Commande
Impression commande
Retour menu
10
En observant ce diagramme, on peut se poser les questions suivantes: - "Quels sont les critres utiliss pour concevoir le "menu" et sa hirarchie, s'il y a lieu?" Ces critres ne sont pas explicites mais si on regarde l'ensemble de la mthode, on voit que ce menu est dduit du dcoupage du systme d'information (fonction puis opration puis poste de travail), mais qu' aucun moment on ne se pose la question du point de vue de l'utilisateur c'est--dire "Quel est l'ensemble des oprations ncessaires l'utilisateur pour qu'il puisse raliser avec le plus de facilits possible sa tche?". Si on se pose ce type de questions, on peut tre amen regrouper des oprations appartenant des fonctions diffrentes mais utilises par une mme personne, crer une redondance l'intrieur de la hierarchie, introduire des enchanements propres la logique d'utilisation de l'utilisateur... mais on a trs peu de chance de retomber sur le dcoupage labor prcdemment. En d'autres termes, il est tout fait exceptionnel que le point de vue de l'analyste et le point de vue de l'utilisateur concident. En effet, le point de vue de l'analyste suit la logique gnrale du systme d'information alors que le point de vue de l'utilisateur est guid par la logique d'utilisation de son poste de travail . - "Comment sont dtermins les enchanements du dialogue?" L'enchanement propos correspond-il un enchanement possible, probable, moyen? En fait il est tonnant qu'il n'y ait qu'un type d'enchanement possible (comme nous le verrons au chapitre 2) et ceci sans justification de ces enchanements vis--vis d'une logique d'utilisation. Y a-t-il possibilits d'interruption ou d'abandon en cours d'opration? Ces possibilits systmatiques ne sont pas prvues et au contraire, on voit que l'utilisateur est totalement contrl par le logiciel qui prvoit quel moment prcis il peut revenir au dbut du programme. En d'autres termes le partage du pilotage de l'application entre l'homme et l'ordinateur n'est pas explicite, et, en consquence, c'est le plus souvent le pilotage de l'ordinateur qui prime, empchant ainsi l'utilisateur d'adapter ses enchanements en fonction des contraintes propres la ralisation de sa tche. - "En cas d'erreur quelles sont les possibilits de correction de l'utilisateur?"
11
On voit qu'il est prvu des enchanements propres la dtection de certaines erreurs par le logiciel, mais on oublie qu'il y a des erreurs que l'ordinateur ne peut dtecter alors que l'utilisateur peut les voir. Encore faut-il lui donner la possibilit de les rectifier en "dfaisant" ventuellement une partie de ce qu'il a fait. D'autre part, les erreurs dtectes par le logiciel peuvent tre d'origines diffrentes. Si c'est une erreur de saisie, les enchanements prvus dans l'exemple sont bons, mais si c'est une erreur diffrente (numro erronn sur le bordereau), la rectification de cette erreur va ncessiter de la part de l'utilisateur une stratgie diffrente (consultation d'une liste par exemple) qui est rendue impossible dans cet exemple. - "Quelles sont les possibilits de guidage?" A priori, le guidage n'est pas prvu dans ce dialogue utilisateurmachine. Ce diagramme du dialogue utilisateur-machine est complt par les dessins d'cran. Nous donnons ci-dessous, titre d'exemple, un dessin d'cran:
Dessin de l'cran E2
Numro client Nom client
Date
Numro
Nom article
Quantit
P.U.
COM / 03
Validation
A propos de ce dessin d'cran, on peut se poser les questions suivantes (questions toujours centres sur l'utilisateur): - "Toutes les zones de l'cran sont-elles pertinentes pour l'utilisateur?" - "Le vocabulaire des donnes ou des commandes correspond-il au vocabulaire employ par les utilisateurs?"
12
- "La prsentation de l'cran est-elle compatible avec les formulaires existants manipuls par les utilisateurs?" "Si l'enchanement des zones remplir est automatique, correspond-il une logique d'utilisation et ces variabilits?" En rsum, nous pouvons dire que les mthodes d'analyse n'incitent pas l'analyste complter sa conception par le point de vue de l'utilisateur. Elles l'incitent au contraire dduire sa conception du dialogue homme-machine de la logique du systme informatique, comme nous l'indiquons sur le schma suivant:
Etude de l'existant Modle descriptif du systme d'information
Conception du systme informatique Modle de donnes Modle de traitements Caractristiques des matriels informatiques
Conception de l'interface
Nous allons montrer dans la suite de ce livre quelles sont les modifications apporter aux mthodes de conception de manire pouvoir intgrer le point de vue de l'utilisateur. Nous insistons beaucoup sur les mthodes car nous pensons qu'elles sont l'origine de la plupart des interfaces inadaptes aux utilisateurs alors que le contexte actuel du matriel et du logiciel de base y est favorable . En effet, le matriel informatique volue vers de plus grandes capacits en mmoire centrale pour un cot plus faible. Cette tendance est fondamentalement favorable au dveloppement de logiciels adapts aux utilisateurs car de tels logiciels ncessitent, comme nous le verrons, plus d'espace mmoire pour chaque utilisateur. Chaque nouvelle possibilit offerte l'utilisateur se traduit par une augmentation de la place mmoire ncessaire. Sur le plan des logiciels de base, nous voyons l'apparition de logiciels de gestion d'cran plus sophistiqus (voir chapitre 4) qui offrent plus de possibilits d'interaction l'utilisateur tout en dchargeant le programmeur d'une partie de la gestion du dialogue.
13
L'volution du matriel informatique et des logiciels de base est donc tout fait favorable l'mergence de logiciels de plus en plus adapts aux utilisateurs mais paradoxalement ce sont les mthodes d'analyse et de programmation qui constituent l'heure actuelle un frein cette volution; c'est cette lacune que ce livre tente de combler.
1.1.2 Les grands mythes

Dans ce paragraphe, nous avons regroup un certain nombre de propos que l'on peut entendre et qui sont, notre avis, des mythes qui entranent des confusions dans la conception de la communication homme-machine. Interface et application conversationnelle Une application conversationnelle a en commun avec une application diffre le fait de dfinir une structure de donnes et une structure de traitements associe. A priori, la seule grande diffrence est la conception d'une interface homme-ordinateur qui permette la communication entre l'utilisateur et l'ensemble des fonctionnalits de l'application (traitement et donnes). Partant de cette constatation, il semble logique de dduire que, si on veut amliorer la conception des applications interactives, il faut faire porter son effort sur la conception de l'interface indpendamment des fonctionnalits du systme qui peuvent tre dfinies par ailleurs par les mthodes d'analyse classiques. L'indpendance de l'interface semble tre confirme par les propos des concepteurs de "logiciels de base d'interface volue" (voir chapitre 4) qui basent leurs travaux sur la sparation entre les fonctionnalits de l'application et son interface utilisateur. Mais, comme nous le dveloppons dans ce livre, nous verrons qu'une rflexion plus approfondie sur l'amlioration de la communication homme-machine rend impossible d'isoler conceptuellement l'interface et les fonctionnalits car cette amlioration passe par une modification de l'interface mais aussi par une reformulation de la structuration des traitements. En d'autres termes, la structuration des traitements pour les applications conversationnelles et les applications diffres ne peut tre identique car, dans le cas d'applications diffres, on ne doit prvoir que des enchanements automatiques entirement pilots par l'ordinateur alors que dans le cas d'applications conversationnelles on doit tenir compte d'un partage de pilotage entre l'homme et l'ordinateur.
14
En fait, ce propos n'est pas en contradiction relle avec ceux des concepteurs de logiciels de base car il ne se situe pas au mme niveau de proccupation. Nous disons qu'il y a une interdpendance conceptuelle entre interface et fonctionnalits mais il y a une indpendance physique ncessaire lors de l'implmentation essentiellement pour des raisons de diminution de complexit et de modifiabilit. Communication homme-machine L'expression "homme-machine" ou "utilisateur-ordinateur" peut prsenter une ambigut qu'il est ncessaire de lever vu sa frquence d'utilisation dans ce livre. En cours d'excution d'une application interactive, il y a en effet une communication entre un homme et un ordinateur, mais de fait lors de la conception c'est l'analyste et le programmeur qui ont emmagasin sous la forme d'un logiciel un savoir sur l'application. L'utilisateur dialogue avec ce logiciel d'application et donc avec le concepteur de ce logiciel. Cette remarque a l'avantage de montrer clairement que l'amlioration de la communication homme-machine, en l'absence "d'amliorations" de l'homme, ne peut porter que sur l'amlioration de la conception. Langage naturel Il existe une ide trs rpandue selon laquelle la communication entre l'homme et la machine serait optimale si l'ordinateur comprenait le langage naturel . Et qu'il suffit donc d'attendre que les recherches dans ce domaine aient abouti. Sans nier l'intrt d'une communication en langage naturel, ce type de communication ne peut lui seul rsoudre toutes les difficults. Et ceci pour deux raisons essentielles: - dans le cas d'utilisateurs professionnels, il se cre un vocabulaire spcialis, laconique, adapt la tche (voir chapitre 2 ) qui utilise un sous-ensemble restreint et parfois dform du langage naturel. - dans tous les cas, le langage ne constitue qu'une partie de l'interface (voir chapitre 3) qui n'est elle-mme qu'une partie de l'application et ne peut donc en aucun cas suppler aux autres lments de l'application. Intelligence artificielle La mme ide est nonce au sujet de l'intelligence artificielle et en particulier des systmes-experts: " il n'y aura plus de problmes de communication homme-machine quand l'intelligence artificielle sera gnralise".
15
Nous tenons faire remarquer que, si les systmes experts constituent un apport important pour la conception et la ralisation de systmes d'aide la dcision, ils ne sont pas efficaces pour les autres applications d'informatique de gestion. En d'autres termes, les systmes-experts sont adapts au cas o les processus cognitifs des utilisateurs sont "dirigs par les donnes" et non par des procdures (comme c'est le cas pour les applications de gestion qui ne relvent pas de l'aide la dcision). Par contre, de nombreux concepts prsents ici peuvent servir pour le dveloppement de systmes-experts plus adapts aux utilisateurs.
1.1.3 L'apport d'autres disciplines

Pour pouvoir intgrer explicitement l'utilisateur la conception des applications interactives, il est ncessaire de connatre les caractristiques des utilisateurs. Pour ce faire, il est ncessaire de puiser dans d'autres disciplines qui ont pour objectif la connaissance de ces utilisateurs. Deux disciplines nous ont paru particulirement adaptes pour enrichir notre connaissance de l'utilisateur dans le contexte du dialogue homme-machine; il s'agit de la psychologie cognitive et de l'ergonomie que nous dfinissons ici. Psychologie cognitive La psychologie cognitive dsigne la partie de la psychologie qui s'intresse la manire dont l'homme traite l'information (mmorisation, apprentissage,...). Les concepts qui y sont dvelopps ne sont pas du tout spcifiques de l'interaction hommemachine mais il est vident aussi qu'ils entranent des consquences sur cette interaction. En effet, dans le dialogue homme-machine, c'est essentiellement la capacit de l'homme traiter des informations symboliques qui est mise en jeu. Aussi, certains des concepts de la psychologie cognitive, nous ont paru indispensable pour comprendre les ractions des utilisateurs et nous en avons tir des consquences sur la conception des aplications interactives. Ergonomie L'ergonomie s'intresse de manire gnrale l'amlioration des conditions de travail, et l'ergonomie du logiciel concentre plus particulirement son attention sur les conditions de travail lies l'utilisation par l'homme de logiciels interactifs.
16
Le terme "ergonomie du logiciel" a merg dans les annes 80 quand on a commenc se poser srieusement le problme de la qualit de l'interaction homme-machine. On peut remarquer qu'on ne parle pas de l'ergonomie de l'informatique car on distingue toujours l'ergonomie du matriel de celle du logiciel. Les travaux sur l'ergonomie du matriel sont antrieurs ceux sur l'ergonomie du logiciel et ont dj t largement publis. En consquence ils ne sont pas repris dans ce livre; nous citons en bibliographie un livre complet sur ce sujet de Cackir, Hart et Stewart (Cac,80). Les limites de cette approche Par dfinition, l'ergonomie du logiciel ne s'intresse qu' un sousensemble particulier des conditions de travail, l'amlioration du dialogue homme-ordinateur ne suffit pas amliorer globalement les conditions de travail; de plus, il peut y avoir un aspect arbitraire et rducteur s'occuper exclusivement d'ergonomie du logiciel en ngligeant d'autres aspects au moins aussi importants au yeux des utilisateurs.
Pour s'en convaincre, nous faisons rfrence au livre publi par ACTIF (Act,81) qui traite de l'ensemble des modifications des conditions de travail lies l'informatisation. ACTIF regroupe les variables concernant l'impact de l'informatique sur les conditions de travail en quatre rubriques: - l'emploi , qui recouvre des variables quantitatives comme le nombre d'emploi ou la dure du travail et des variables qualitatives lies l'volution du contenu du travail et de la qualification correspondante - l'organisation , qui dsigne d'une part la rpartition globale du travail entre les diffrents partenaires de l'entreprise, d'autre part la description du travail au niveau individuel (type d'activit, rpartition des tches entre l'homme et l'ordinateur,...) - les conditions matrielles , qui dsignent les conditions gnrales comme le bruit, le rythme de travail, etc...et les conditions spcifiques au travail sur terminal (lisibilit, surcharge, dispositifs d'entre de donnes,...). - les relations de travail, c'est--dire la nature des relations qui s'tablissent entre les diffrents membres de l'entreprise et avec les personnes extrieures. Le tableau suivant rsume l'impact des diffrentes tapes de l'analyse informatique sur les diffrentes rubriques dcrivant les conditions de travail:
17
Rubriques lies aux conditions de travail Etapes d'analyse Schma Directeur Etude pralable Etude dtaille Ralisation, maintenance Interaction trs importante Interaction importante Interaction peu importante Non examin Emploi Organisation Conditions matrielles Relations de travail
Nous pouvons constater que ce que l'on dsigne sous le nom d'ergonomie du logiciel regroupe en fait une partie de la rubrique "organisation du travail" au niveau individuel et une partie de la rubrique "conditions matrielles" au niveau informatique. De plus, les effets des diffrentes rubriques ne sont pas indpendants et certains lments peuvent prendre un moment donn une importance accrue par rapport aux autres; par exemple, une menace sur l'emploi ou de mauvaises relations de travail peuvent gommer compltement l'effet bnfique d'un logiciel "ergonomique". Inversement de bonnes relations de travail peuvent minimiser l'effet de mauvaises conditions matrielles.
Par ces remarques, nous voulons simplement prciser que la conception d'un logiciel adapt aux utilisateurs n'est pas en mesure de rsoudre l'ensemble des problmes humains poss par l'introduction de l'informatique mais qu'inversement, il ne peut pas y avoir un processus d'informatisation russi sans optimisation de la manire dont l'homme est amen communiquer avec l'ordinateur.
1.1.4 Les diffrents points de vue

Les applications interactives sont conues, tudies et utilises par des personnes diffrentes ayant des objectifs diffrents. Nous pouvons citer au moins trois types de personnes qui s'intressent de par leur travail ces logiciels; ce sont l'utilisateur, l'informaticien et l'ergonome.On pourrait citer d'autres intervenants comme le conseiller en organisation ou le formateur, mais dans ce livre, nous nous concentrons sur le point de vue des utilisateurs, des informaticiens et des ergonomes.
18
Parce que l'objectif de chacune de ces personnes est diffrent, leurs perceptions de l'interaction homme-machine sont diffrentes et, en particulier, leurs dcompositions de l'interaction et leurs critres d'optimisation diffrent. Nous nous trouvons devant le problme classique, en thorie des systmes, des vues multiples sur un mme objet.. Nous dcrivons ci-dessous succintement ces diffrents points de vue. L'objectif de l'utilisateur est d'avoir un logiciel lui permettant d'excuter sa tche avec le plus de facilit possible. Il existe peu d'tudes sur la perception des utilisateurs; mais, nous avons trouv dans une tude ralise par Rolloy (Rol,82) un dcoupage selon les paramtres suivants: - lisibilit des sorties - adaptation du logiciel aux situations relles de travail - aide l'utilisation et l'apprentissage - oprations redondantes - initiatives possibles pour l'utilisateur. L'ergonome a pour but d'amliorer la communication hommemachine et, pour ce faire, il observe le couple homme-machine de l'extrieur. Le dcoupage qu'il adopte en est une consquence et on trouve dans la littrature en ergonomie un consensus sur un dcoupage en sept paramtres: - le squencement des oprations - le langage d'interaction - les dispositifs d'entre - les dispositifs de prsentation - le temps de rponse - le traitement des erreurs - le guidage. L'objectif de l'informaticien est double selon la phase de conception o il se trouve: - en phase d'analyse son objectif est de dfinir un ensemble de spcifications qui traduisent sur le plan informatique les fonctionnalits de l'application; - en phase de programmation, son objectif est de produire un logiciel fiable compte-tenu des spcifications fonctionnelles et des contraintes matrielles et logicielles. En phase d'analyse et avec des variantes selon les mthodes, on dfinit des paramtres tels que procdure, opration, synchronisation, entit, relation,...
19
En phase de programmation on rajoute des paramtres tels que transaction, type, rubrique,... La correspondance entre les diffrents points de vue La premire remarque que l'on peut faire est que tous ces paramtres ne se correspondent pas de faon biunivoque, comme nous le montrons sur le tableau suivant o l'on a mis en correspondance les paramtres perus par l'utilisateur et ceux utiliss par l'ergonome:
Point de vue de l'ergonome Point de vue de l'utilisateur Lisibilit Adaptation aux situations relles Aide Redondance Initiative Squence- Langage Dispositifs Dispositifs Temps de Traitement ment des d'interrorponse des erreurs Guidage oprations gation d'entre de sortie * * * * * * indique la correspondance des points de vue * * * * * * * * * * * * * *
Par la suite, nous nous proccupons plutt de la correspondance entre le point de vue de l'ergonome et celui de l'informaticien afin de pouvoir intgrer la conception informatique les connaissances acquises par les ergonomes. Pour tablir cette correspondance deux approches sont possibles: - la premire approche est abstraite et se base sur la linguistique pour trouver un cadre thorique commun; cette approche reste pour le moment du domaine de la recherche; - la deuxime approche est plus directement oprationnelle et consiste traduire chaque paramtre provenant de l'ergonomie selon la logique de conception utilise en informatique. C'est cette deuxime approche qui a t choisie et qui est dveloppe dans les chapitres 2 et 3.
20
1 . 2 Les principaux dvelopps

1.2.1 Les concepts classiques
concepts
Avant de faire une prsentation gnrale de l'ouvrage, il nous semble important de dfinir ce que nous entendons par modle, formalisme, mthode et outil dans le contexte de l'interaction homme-machine. Un modle est un ensemble de concepts au moyen desquels nous pensons pouvoir dcrire de manire oprationnelle un sytme rel. Le systme reprsent au moyen de ce modle ne peut en aucun cas tre confondu avec le systme rel qui est dans ce cas le sytme homme-machine. En effet, l'approche de plus en plus rpandue de la thorie des systmes, nous a fait prendre conscience du fait qu'une description exhaustive d'un systme rel est tout fait illusoire et que la description d'un systme rel est dpendante de deux lments qui sont l'objectif et le modle de l'observateur, ce que nous reprsentons sur le schma suivant:
Observateur Modle Objectif Systme rel (entreprise, poste de travail ...)
Modle
Systme reprsent (tude pralable, dtaille ; ...)
Le choix du modle par l'observateur dpend de l'objectif qu'il se fixe quand il observe le rel; c'est--dire qu'il ne choisira pas les mmes lments de description selon l'utilisation qu'il veut faire des rsultats de son observation. L'observateur est, dans ce contexte, l'analyste, l'ergonome ou toute personne intervenant dans le processus de conception.
21
Le systme reprsent (qui est dcrit des niveaux de dtails diffrents dans les diffrents dossiers d'analyse) est volontairement un systme appauvri du systme rel en ce sens qu'il contient moins d'lments et moins d'interrelations entre ces lments que le systme rel. Ce fait n'est pas handicapant si les lments du modle sont choisis avec soin de manire permettre de raliser les objectifs fixs. C'est pour cela qu'il est ncessaire d'intgrer explicitement, au modle des applications interactives, des lments dcrivant l'utilisateur, sinon le systme reprsent n'en contiendra pas. Le modle des applications interactives que nous proposons est dcrit dans les chapitres 2 et 3. Le formalisme est une convention de reprsentation des concepts du modle. Par exemple un schma de base de donnes peut tre reprsent selon un formalisme graphique ou un formalisme littral et linaire. Le choix du formalisme se fait en fonction de sa lisibilit pour l'observateur et en fonction de proprits qui peuvent en tre dduites (c'est le cas des formalismes mathmatiques). Nous proposons dans le chapitre 2 un formalisme graphique permettant de reprsenter les lments du modle. La mthode constitue un mode d'emploi particulier d'un modle; elle indique dans quel ordre observer les diffrents lments et comment procder ces observations. Elle restreint ainsi les possibilits du modle mais elle a l'norme avantage de permettre un apprentissage plus ais. Par contre quand le modle a t bien intrioris et que l'analyste a l'habitude des observations sur le terrain, il peut abandonner en partie ou totalement la mthode, de manire disposer d'une plus grande latitude dcisionnelle lui permettant de mieux s'adapter aux spcificits du systme rel qu'il observe. La mthode de conception des applications interactives adapte aux utilisateurs est dcrite au chapitre 5. A titre d'exemple, nous pouvons citer MERISE qui est prsente d'abord par son modle puis par la mthode associe alors que AXIAL est prsente uniquement sous forme de mthode. Un "outil" est un logiciel d'aide l'analyse qui utilise le formalisme et la mthode associe afin d'augmenter la productivit de l'analyse par des gains de temps d'analyse et de programmation et des gains de fiabilit par des vrifications de cohrence et des simulations. Dans le cadre de ce livre, nous prsentons un modle d'application interactive adapte aux utilisateurs ainsi qu'un formalisme et une mthode associe.Cet ensemble peut, bien sr, tre utilis sans
22
"outil" associ; aussi le problme de l'outil qui, lui seul, constitue un dveloppement important n'est pas trait dans ce livre.
1.2.2 Les nouveaux concepts sur applications interactives et les utilisateurs

Intgration des diffrents points de vue
les
Pour pouvoir intgrer explicitement le point de vue de l'utilisateur la conception des applications interactives, nous proposons un modle qui comprend trois points de vue, celui de l'analyste, celui de l'utilisateur, celui du programmeur. Le point de vue de l'analyste, appel Reprsentation Conceptuelle, dcrit d'abord la logique gnrale du nouveau systme d'information puis la logique des traitements par rapport un poste de travail; c'est dans cette deuxime phase que nous commenons intgrer des lments de psychologie cognitive lis l'utilisateur. Le point de vue de l'utilisateur, appel Reprsentation Externe, correspond au logiciel tel qu'il sera vu et manipul par l'utilisateur. Cette Reprsentation Externe comprend deux parties; la premire est la traduction des lments de la Reprsentation Conceptuelle qui entrent dans l'interaction homme-machine; la deuxime comprend la dfinition de tous les lments spcifiques la Reprsentation Externe (qui correspond la notion d'interface). C'est ici que nous intgrons tous les lments d'ergonomie. Le point de vue du programmeur, appel Reprsentation Interne, correspond la mise en oeuvre des Reprsentations Conceptuelle et Externe. Cette phase ne s'accompagne d'aucune spcification nouvelle concernant l'utilisateur et n'intgre donc aucun lment d'ergonomie supplmentaire. L'ordre de prsentation que nous venons de faire correspond l'ordre usuel de conception comme nous l'indiquons dans le schma ci-dessous:
23
Reprsentation conceptuelle
Reprsentation externe
Reprsentation interne
On peut modifier cet ordre, en partant d'abord de la Reprsentation Externe dans le cas de diagnostic d'un logiciel existant ou dans le cas de conception d'un logiciel interactif individuel. Ces "trois points de vue" peuvent tre mis en oeuvre par une mme personne, condition qu'elle se mette effectivement concevoir l'application avec des points de vue multiples. L'apport de la psychologie cognitive et de l'ergonomie Afin d'amliorer la communication homme-machine, il est ncessaire de recueillir le maximum d'information concernant le traitement de l'information en gnral par l'homme et plus particulirement dans son dialogue avec un ordinateur. Pour ce faire, nous avons rassembl des concepts issus de la psychologie cognitive et de l'ergonomie; cet ensemble de concepts ne constitue en aucun cas une liste exhaustive de l'ensemble des concepts que l'on peut trouver dans ces deux disciplines, mais un sous-ensemble qui nous a paru particulirement oprationnel pour la conception d'applications interactives adaptes aux utilisateurs. En ce qui concerne la psychologie cognitive , nous avons retenu les concepts suivants: - il existe diffrents types d'utilisateurs qui, pour des raisons varies, n'utilisent pas le mme logiciel de la mme manire - il y a une diffrence fondamentale entre la logique de fonctionnement de l'ordinateur et la logique d'utilisation par l'homme de cet ordinateur - on doit distinguer les tches prvues et les tches effectivement mises en oeuvre par les utilisateurs - on peut faire l'hypothse que la rsolution d'une tche par un homme s'organise selon le modle de la planification hirarchique
24
- les caractristiques de la mmoire court terme chez l'homme ont un impact direct sur le dialogue homme-machine - une partie de l'apprentissage passe par la cration d'automatismes.. Les quatre premiers concepts sont dvelopps dans le chapitre 2 car ils ont un impact direct sur la conception de la Reprsentation conceptuelle; les deux derniers sont dvelopps dans le chapitre 3 car ils sont utiliss plutt pour la conception de la Reprsentation Externe. L'ergonomie est l'tude de l'homme en condition de travail en gnral et une partie des tudes porte sur les conditions de travail de l'homme face un ordinateur. En ce qui concerne l'interaction homme-machine, les tudes portent sur les paramtres suivants que nous dveloppons au chapitre 3 car ils ont un impact direct sur la conception de la Reprsentation Externe: - le squencement des oprations dfinit l'enchanement des oprations tel qu'il est autoris par le logiciel; l'enchanement peut tre totalement libre ou guid par l'arborescence d'un menu - le langage d'interaction concerne les commandes et les donnes changes entre l'homme et l'ordinateur aux niveaux lexical et syntaxique - les dispositifs d'entre dfinissent les possibilits physiques d'entre des donnes et des commandes dont dispose l'utilisateur - les dispositifs de sortie dsignent les possibilits d'affichage des informations, qui dpendent la fois du matriel et du logiciel - le temps de rponse peru par l'utilisateur est troitement dpendant de l'organisation des donnes et des programmes - le traitement des erreurs dsigne les possibilits offertes l'utilisateur pour dtecter et corriger ses erreurs - le guidage dfinit les aides l'utilisation et l'apprentissage incluses dans le logiciel. Les interactions entre les Reprsentations Conceptuelle et Externe et les concepts issus de la psychologie cognitive et de l'ergonomie sont reprsents dans la figure suivante:
25
Psychologie cognitive - Types d'utilisateur - Tche prvue / effective - Logique de fonctionnement et d'utilisation - Planification hirarchique
Psychologie cognitive - Structure de la mmoire court terme - Exprience et automatisme Ergonomie - Squencement des oprations - Langage d'interaction - Dispositifs d'entre - Dispositifs de prsentation - Temps de rponse - Traitement des erreurs - Guidage Reprsentation externe
La conception de la Reprsentation Externe doit intgrer toutes les caractristiques de l'utilisateur; certains lments de psychologie cognitive et d'ergonomie sont intgrs directement et d'autres par le biais de la Reprsentation Conceptuelle (qui la prcde). Il faut remarquer galement que les concepts de psychologie cognitive et d'ergonomie ne sont pas compltement indpendants; ce qui est normal tant donn que leur objet d'tude est le mme avec des objectifs diffrents. Ce fait entrane que des options prises au niveau de la Reprsentation Conceptuelle ont un impact sur des lments d'ergonomie, savoir le squencement des oprations, le traitement des erreurs et le guidage. Nous reprsentons, sur le tableau suivant, par une toile le moment o pour la premire fois dans le processus de conception, on se proccupe des diffrents lments d'ergonomie:
26
Squence- Langage Dispositifs Dispositifs Temps de Traitement ment des d'interroGuidage oprations gation d'entre de sortie rponse des erreurs Reprsentation interne Reprsentation conceptuelle Reprsentation externe * * * * * * *
Il est bien entendu que tous ces lments auront une "image" dans la Reprsentation Externe. Processus de conception L'ensemble des caractristiques des utilisateurs (psychologie cognitive et ergonomie confondues) peuvent tre clates en deux sous-ensembles disjoints si l'on s'intresse au processus de conception. En effet, il est alors oprationnel de distinguer les caractristiques qui ncessitent une analyse du travail, de celles qui ont un caractre gnral et qui s'appliquent quelle que soit la situation de travail. Les lments recueillis lors de l'analyse du travail ont un impact sur l'tude de l'existant puis sur les Reprsentations Conceptuelle et Externe. Nous voyons clairement sur le schma suivant que la Reprsentation Externe, c'est--dire ce que voit l'utilisateur, n'est plus conue uniquement partir de la logique du systme informatique:
Ergonomie
Informatique Etude de l'existant
Analyse du travail
Caractristiques ergonomiques gnrales
Reprsentation externe Contraintes matrielles et logicielles
27
Nous reprsentons le lien qui existe entre les mthodes de conception gnrale des systmes informatiques et la mthode particulire de conception des applications interactives sur le schma suivant:
Systme d'information Etude pralable Reprsentation conceptuelle Point de vue de l'analyste Poste de travail
Etude dtaille
Point de vue de l'utilisateur
Ralisation, programmation
Point de vue du programmeur
L'on voit que l'ensemble de notre dmarche s'applique pour chaque type de poste de travail et peut se greffer sans problme sur une mthode existante. Le lien avec la mthode MERISE est dvelopp dans le chapitre 5.
1.3 Prsentation de l'ouvrage

1.3.1 Composition gnrale
Nous prsentons ici la stucture et le contenu des chapitres suivants afin d'indiquer les diffrentes manires possibles d'aborder cet ouvrage. Structure Les chapitres 2, 3 et 4 dcrivent l'ensemble du modle des applications interactives et des caractristiques de l'utilisateur. Les chapitres 5 et 6 dcrivent deux des mthodes que l'on peut associer au modle. Contenu Le chapitre 2 comprend deux parties; la premire expose les concepts de psychologie cognitive qui ont un impact sur la conception de la Reprsentation Conceptuelle; la deuxime dcrit le
28
modle de la Reprsentation Conceptuelle d'un type de poste de travail. Le chapitre 3 prsente d'une part les paramtres d'ergonomie, d'autre part le modle de la Reprsentation Externe qui intgre toutes les caractristiques des utilisateurs (y compris la traduction de la Reprsentation Conceptuelle). Le chapitre 4 dcrit les consquences des deux premires reprsentations sur la mise en oeuvre des logiciels correspondants; il prsente galement les caractristiques des systmes de gestion d'cran de multifentrage comme lment de mise en oeuvre. Le chapitre 5 expose une mthode de conception complte de l'application conversationnelle depuis l'tude de l'existant jusqu' la spcification de la Reprsentation Externe; cette mthode est illustre par une tude de cas. Le chapitre 6 prsente une deuxime mthode qui montre comment faire un diagnostic sur un logiciel existant et comment faire un cahier des charges logiciel respectant des contraintes ergonomiques; la mthode de diagnostic est illustre par un exemple. A qui s'adresse ce livre? Comme nous l'avons dit, ce livre s'adresse toutes les personnes qui interviennent dans le processus de conception des applications interactives que ce soit les informaticiens- analystes ou les conseillers extrieurs, les correspondants informatiques, les ergonomes, les formateurs. Il suppose cependant d'avoir des connaissances dans une des mthodes de conception de systmes informatiques utilises en informatique des organisations, ou d'avoir pratiqu ce type de conception sur le terrain (sinon certains passages se rvleront obscurs).
1.3.2 Comment le lire?

On a l'habitude de lire un livre de manire linaire; cette habitude est induite par les contraintes techniques d'un livre (contraintes qui n'existent pas dans le cas d'un logiciel), et en consquence ce livre a t conu de manire pouvoir tre lu de faon linaire, mais ce n'est pas le seule manire possible. Pour aller plus vite, un informaticien-analyste ou un formateur peut prendre directement connaissance de la mthode et des exemples (chapitre 5 et 6) et il peut ultrieurement tayer ces connaissances par la lecture du modle (chapitres 2, 3, 4).
29
Un intervenant partiel dans le processus de conception (correspondant informatique, ergonome) peut prendre connaissance des concepts de psychologie cognitive et d'ergonomie (premire partie des chapitres 2 et 3) puis de la mthode correspondante (chapitre 5). S'il veut seulement faire un audit d'un logiciel existant, il peut lire en premier la mthode de diagnostic et de conception du cahier des charges (chapitre 6). Nous reprsentons les diffrentes manires possibles de lire ce livre sur le schma suivant:
Analystes
Chapitre 2 Psychologie cognitive Modle orient analyste
Chapitre 3 Ergonomie Modle orient utilisateur
Chapitre 4 Modle orient programmation
Lecture rapide Concepteurs
Chapitre 5 Mthode de conception gnrale, DIANE
Audit
Chapitre 6 Audit et cahier des charges ; exemple
30
Chapitre 2 : LES STRUCTURES PROFONDES DES APPLICATIONS INTERACTIVES

Dans ce premier chapitre de prsentation du modle d'applications interactives adaptes aux utilisateurs, nous prsentons la Reprsentation Conceptuelle qui correspond la spcification de l'application interactive du point de vue de l'analyste. Comme nous l'avons prsent dans le chapitre 1, la Reprsentation Conceptuelle intgre certains lments de psychologie cognitive. Aussi, dans un premier paragraphe, nous prsentons les lments de psychologie cognitive que nous pouvons intgrer la Reprsentation Conceptuelle et dans un deuxime paragraphe, nous exposons de manire dtaille le modle de la Reprsentation Conceptuelle. Nous reprenons ci-dessous le schma prsent au chapitre 1 en indiquant en caractres gras ce qui va tre expos dans ce chapitre.
31
2 . 1 La psychologie cognitive et l'utilisateur de logiciel

2.1.1 Elments pertinents
Notre propos n'est pas ici de faire un expos gnral sur la psychologie cognitive mais d'exposer diffrents concepts qui nous semblent pertinents d'une part pour comprendre les reprsentations mentales d'un utilisateur de logiciel, d'autre part pour guider l'analyste dans sa conception des applications interactives. Nous dveloppons ici les concepts suivants : - l'image oprative qui nous permet de comprendre les images mentales mises en oeuvre dans une tche spcifique (reprsentation de tche) - la planification hirarchique qui traite de la dcomposition d'une action - la diffrence entre utilisateurs novices et expriments - les notions de tche prvue et tche effective. 2.1.1.1 L'image oprative Nous nous rfrons ici aux concepts dvelopps par Ochanine (Och,72), et repris et approfondis par Sperandio (Spe,80) et Cazamian (Caz, 81). On appelle "image oprative" les images mentales qui accompagnent l'action de travail. Quand un utilisateur est confront un objet dont il reoit des informations et sur lequel il devra agir, il a une reprsentation mentale de cet objet. On appelle structure intgrale l'ensemble des relations existantes entre tous les lments d'un objet et structure partielle un groupe de relations mis part pour une raison quelconque. Pour la ralisation d'une tche particulire, tous les lments de la structure intgrale n'offrent pas le mme intrt ; certains lments peuvent tre omis, d'autres au contraire mis en valeur. De manire gnrale, la ralisation d'une tche requiert une structure partielle dite structure oprative et la reprsentation de cette structure par l'utilisateur sera appele image oprative.
32
Les images opratives sont un sous-ensemble des images mentales orientes vers l'action. Dans le cas o le but du sujet est simplement de connatre un objet, l'image mentale qu'il aura de cet objet s'approchera ou mme s'identifiera la structure intgrale. Les deux caractres essentiels de cette image oprative sont le laconisme et la dformation fonctionnelle. - le laconisme : l'image tant un moyen d'action, elle ne retient de l'objet que les seules proprits ncessaires l'action. - la dformation fonctionnelle : c'est une rplique dforme de l'objet, mais dforme par l'accentuation de ce qui est fonctionnellement important pour une tche donne dans un contexte donn. Pour illustrer ces concepts nous donnons deux exemples :
- le premier exemple concerne la confrontation de deux images opratives de deux personnnes diffrentes. Nous sommes dans une salle de contrle d'une centrale thermique o un oprateur doit contrler prs d'un millier de paramtres. Pour l'aider interprter les signaux, l'ingnieur lui fournit un schma de fonctionnement global de l'installation. Mais on s'aperoit que ce schma ne constitue pas une aide mais un gne car l'image oprative de l'oprateur est trs loigne de ce schma. Dans son image oprative les parties trs automatises et trs fiables ont quasiment disparu et certaines parties posant frquemment des problmes sont survalues. Le schma global est opratif pour l'ingnieur en tant que constructeur d'usine mais il ne l'est pas pour le technicien qui n'a pas construire l'usine mais pallier les incidents de son fonctionnement. - le deuxime exemple concerne des mdecins novices et expriments. Trois groupes de mdecins (spcialistes expriments, gnralistes, novices), sont confronts des cas rels de maladie de la thyrode. Aprs palpation et examens, on demande chaque mdecin d'exprimer sa reprsentation mentale de la glande malade par un modelage. Les rsultats montrent que les mdecins les plus qualifis produisent des modelages prsentant des dformations importantes par rapport la ralit, en ce sens que les parties atteintes de la glande sont hyper-dformes par le modelage ,ce qui correspond une dformation fontionnelle permettant d'aboutir au bon diagnostic. Par contre les mdecins dbutants ou moins qualifis produisent des modelages plus conformes au rel mais moins riches en informations pertinentes.
2.1.1.2 La planification hirarchique Cette notion a t introduite par des chercheurs en intelligence artificielle Sacerdoti (Sac,74) et Cohen, (Coh,82) et reprise par des chercheurs en science cognitive Dermott (Der,78) et Sebillotte (Seb,83) (Seb, 87). La question qui se pose ici est de savoir comment l'utilisateur se reprsente le travail qu'il a faire pour atteindre son objectif. La
33
rponse cette question a un double intrt en informatique car elle peut permettre la fois une meilleure utilisation et un meilleur apprentissage si le modle prsent l'utilisateur se rapproche le plus possible de sa logique d'utilisation. Le problme pos ici se distingue de celui de la reprsentation mentale de l'objet tudi (image mentale ou oprative) en ce sens que l'image mentale correspond la partie statique (structure des donnes) et la planification hirarchique la partie dynamique (structure des traitements). L'hypothse de la planification hirarchique est que l'utilisateur va laborer un plan d'action partir du but qu'il souhaite atteindre. Cette hypothse nous semble taye par les travaux faits par Graesser (Gra,81) sur la mmorisation : - une information structurellement ordonne est mieux mmorise, le rappel se faisant par les structures de plus haut niveau. - un lment conceptuellement reli d'autres (dj mmoriss) est mieux mmoris qu'un lment isol. Ce plan d'action lui permettra de raisonner des niveaux de dtail diffrents en passant par la dfinition de sous-buts intermdiaires ncessaires l'accomplissement du but. Certains de ces sous-buts doivent tre ncessairenent raliss, les autres sont optionnels, c'est-dire qu'ils ne sont formuls qu'en cours d'excution de l'action lorsque l'utilisateur se rend compte que certaines conditions requises pour l'excution d'un sous-but ne sont pas remplies. Ces sous-buts ne font pas partie du schma initial de l'action, ils sont gnrs par l'utilisateur en cours d'excution. La description d'un sous-but comporte : - une suite d'actions raliser - l'tat final obtenu par la ralisation de la suite d'actions - les pr-requis qu'il est ncessaire de vrifier avant que l'on puisse excuter la liste d'actions. Dans le cadre de la description du travail de bureau, ou plus gnralement du travail tertiaire, cette dcomposition en sous-buts et pr-requis peut tre d'une grande souplesse car elle permet ultrieurement l'utilisateur de se servir de ces sous-buts dans des contextes diffrents, sans imposer une programmation rigide. Cette mthode de travail peut servir d'une part tudier des contextes particuliers de travail pour rendre le plus fidlement possible la logique d'utilisation de l'oprateur, d'autre part essayer de trouver des sous-buts invariants d'une tche l'autre qui
34
pourraient servir d'lments constructifs pour la ralisation de n'importe quel but.
2.1.1.3 Utilisateurs expriments et dbutants L'existence d'utilisateurs expriments occasionnels) pose deux types de questions : et dbutants (ou
- existe-t-il des diffrences de comportements entre ces deux catgories ? - comment se fait l'apprentissage, c'est--dire le passage d'une catgorie l'autre ? Diffrences de comportement Nous avons dj vu qu'il existe des diffrences au niveau des images opratives, c'est--dire que plus l'utilisateur est expriment, plus il y a une dformation fonctionnelle de l'image oprative. On peut noter aussi une diffrence entre les procdures choisies et les rsultats obtenus pour raliser un mme objectif. Pour illustrer cette diffrence, nous nous rfrons une tude publie par Bisseret (Bis,79) portant sur l'effet de l'exprience sur les contrleurs ariens. Face une situation donne de positions d'avions, le contrleur doit dcider s'il va y avoir un conflit ou non, c'est--dire si deux avions risquent de se rencontrer, auquel cas il doit dtourner un des deux. Les mmes situations ont t exposes un groupe de dbutants et un groupe de contrleurs expriments. Les rsultats montrent que les dbutants sont plus discriminants que les expriments; en effet, les dbutants classent tous les cas dans une des deux catgories de conflit ou de non-conflit alors que les expriments laissent un certain nombre de cas dans le doute, car ils pensent que c'est un cas surveiller sur lequel ils n'ont pas encore assez d'information. Les expriments se montrent ainsi plus prudents mme s'ils sont amens dtourner plus d'avions que les dbutants. Au niveau de l'activit cognitive, il semble que les expriments ont un jugement plus rapide fond sur une catgorisation grossire des situations, alors que les dbutants cherchent calculer pour connatre avec prcision la distance sparant deux avions.
35
Nous n'avons pas d'exemple d'tudes de diffrence portant sur le travail de bureau, mais ces rsultats ont un caractre assez gnral pour que l'on puisse en dduire que l'on devrait observer ces diffrences aussi dans ce secteur. Par contre,l'absence d'tudes ne nous permet pas de dire sur quels lments porteraient ces diffrences. L'apprentissage Nous ne voulons pas traiter ici le problme gnral de l'apprentissage mais seulement celui de l'apprentissage d'un outil comme l'ordinateur. Nous faisons rfrence ici aux travaux dvelopps par Richard (Ric,83), (Ric,87) qui tudie la diffrence entre la logique de fonctionnement et la logique d'utilisation. Dans la logique de fonctionnement, on apprend l'utilisateur le fonctionnement de la machine et les effets de chaque commande du langage de l'ordinateur. "Si P alors Q". Dans la logique d'utilisation, on explique l'utilisateur "comment faire pour" arriver un rsultat donn. "Si l'objectif est Q alors on peut faire P". On montre qu'il est difficile de passer d'une logique de fonctionnement une logique d'utilisation car la procdure laborer pour atteindre un but ne peut tre dduite directement de la connaissance des rgles de fonctionnement ; elle ne peut pas tre non plus, dans le cas gnral, un simple calque de la procdure manuelle. Pour raliser l'aide d'un ordinateur une tche que l'on sait rsoudre par ailleurs, il faut modifier sa reprsentation du problme en dfinissant de nouveaux buts et sous-buts compatibles avec le fonctionnement de la machine. Pour diminuer le foss entre l'utilisation et le fonctionnement, il est propos de dfinir des rgles d'utilisation qui prcisent les actions qu'il est possible de raliser et comment le faire. Les commandes de l'ordinateur ne peuvent, dans le cas gnral, correspondre des actions de l'utilisateur car les commandes sont dfinies par rapport la smantique du dispositif et les actions ont un sens pour l'utilisateur dans le contexte des tches qu'il a accomplir. Dans une logique d'utilisation, on pourrait donner l'ensemble des procdures suivre pour arriver certains buts mais, dans le cas
36
gnral, on ne connat pas l'avance l'ensemble des tches auxquelles peut tre utilis un dispositif, et donc on ne peut laborer un ensemble exhausif de procdure. L'objectif sera donc de dfinir des actions qui ne correspondent pas des buts prcis mais qui seront des procdures pour la ralisation de ces tches. c'est--dire que l'on aura fait pour l'utilisateur le passage des rgles de fonctionnement aux composants d'utilisation. Dans l'optique de la logique de fonctionnement, le problme qui demeure est de dterminer les bonnes rgles d'utilisation faire apprendre, celles qui correspondent des actions que le sujet se donne comme objectifs intermdiaires. 2.1.1.4 Tche et activit Pour distinguer la tche de l'activit, nous nous rfrons Leplat et Hoc (Lep,83): "Toute analyse de situation dans une perspective psychologique amne s'interroger sur les rapports entre une tche et une activit : qu'est-ce qui est demand au sujet, qu'est-ce qu'il cherche faire, que fait-il effectivement et comment, et finalement, quels sont les rapports entre ces deux questions ?". De manire gnrale, la tche indique ce qui est faire, l'activit ce qui se fait. Pour tre plus prcis, nous dfinissons la tche comme la ralisation d'un but donn dans des conditions dtermines. Le but est l'tat final. Il peut tre dcrit par des critres et la valeur qu'ils doivent prendre. Il existe souvent plusieurs manires quivalentes de dcrire le but. Un but peut tre dcrit et valu par un procd qui ne correspond pas celui mis en jeu pour le raliser. Les conditions peuvent tre dcrites de plusieurs manires : - par l'ensemble des tats parcourir avant d'atteindre l'tat final ; - par les oprations admissibles pour parcourir ces tats ; - par la procdure mettre en oeuvre pour ce faire, c'est--dire la combinaison de ces oprations. L'ensemble des tats sera dfini par : - la donne d'un tat initial ; - un dcoupage temporel du processus en tats identifiables ; - une description des tats en valeur de variables qui les caractrisent.
37
L'ensemble des oprations admissibles dans la transformation des tats sera appel le dispositif associ la tche. L'ensemble des procdures peut tre dcrit soit en explicitant la combinaison des oprations sous forme d'algorithme (mode procdural), soit en donnant les proprits qu'elle doit respecter (mode dclaratif). La tche prvue est la tche conue par celui qui en commande l'excution. La description d'une tche est complte pour un sujet donn quand elle lui permet l'excution immdiate de la tche sans nouvelles acquisitions pralables. Une tche dont la description est complte ne requiert donc du sujet qu'une activit d'excution. Une tche dont la description est incomplte requiert du sujet une activit d'laboration en plus de l'activit d'excution proprement dite. L'activit est ce qui est mis en oeuvre pour excuter la tche. La tche effective correspond ce que l'utilisateur fait effectivement. La tche effective n'est pas un dcalque de la partie observable de l'activit. Dans la mesure, par exemple, o elle dfinit une procdure, elle est drive de certains comportements et prend aussi en compte ce qu'on sait des rgles de fonctionnement du systme cognitif. La tche effective constitue donc un modle de l'activit. La validation du modle que constitue la tche effective se fera par la confrontation des prdictions de ce modle avec des traces observables de l'activit.
2.1.2 Possibilits d'extrapolation

Nous reprenons dans ce paragraphe les concepts prsents ci-dessus en leur donnant une interprtation utilisable pour la conception des logiciels interactifs. Du concept d'image oprative, nous pouvons retirer trois ides pour les applications interactives: - la notion de laconisme est importante pour notre conception du vocabulaire et de la syntaxe du dialogue. En effet, certains pensent que la rsolution du problme du dialogue passe par l'utilisation et la comprhension du langage naturel. Cette ide peut tre vraie pour des utilisateurs occasionnels non spcialiss. Mais dans le cas de spcialistes d'une tche, il se cre un vocabulaire spcialis, opratif,
38
non ambigu qui est fonctionnel et adapt la tche. Le rle de l'analyste est alors de reprer ce vocabulaire et de permettre son utilisation. - l'image oprative varie selon la fonction des diffrents utilisateurs. En particulier, l'analyste informaticien et l'utilisateur ont trs peu de chance d'avoir la mme image oprative des tches accomplir. L'analyste a une vision globale et abstraite des procdures de traitement de l'information alors que l'utilisateur a une image locale et concrte de ces mmes tches. - l'image oprative et les processus de dcision varient selon le degr d'exprience des utilisateurs. Il faut donc prvoir des prsentations diffrentes du mme logiciel pour des utilisateurs de niveau d'exprience diffrent. La planification hirarchique correspond une description du travail oriente-but qui part du rsultat que veut atteindre l'utilisateur pour remonter jusqu'aux actions lmentaires ncessaires la ralisation du but. Ce type de description n'est pas usuel dans la conception des systmes d'information o au contraire on fait des descriptions procdurales partir d'vnements d'entre jusqu'aux vnements de sortie. Ces deux dmarches ne sont pas simplement inverses l'une de l'autre car le rsultat obtenu n'est pas le mme: - dans la description oriente-but, on obtient un ensemble d'oprations ncessaires la ralisation du but ; des procdures diffrentes seront regroupes si elles aboutissent au mme but ; cette description permet de dcrire aisment tous les paralllismes et correspond la logique d'utilisation. - dans la description oriente-vnement, on obtient l'enchanement des oprations dclenches par un ou des vnements initiaux ; cette description correspond la logique de fonctionnement du Systme d'Information et dcrit les diffrentes procdures indpendamment de leurs utilisations. Il n'y a que dans le cas simple o un but est obtenu par la ralisation d'une procdure dclenche par un vnement que ces deux mthodes de description aboutissent au mme rsultat. La planification hirarchique s'applique notre avis de faon privilgie pour les raisonnements guids par les traitements et non pas guides par les donnes, c'est--dire quand l'enchanement des oprations est quasi indpendant de la valeur des donnes ou que cette dpendance ne cre pas une explosion combinatoire de l'arborescence. Dans l'entreprise, les postes de travail des dcideurs correspondent davantage des modes de travail guids par les donnes alors que les postes d'excution sont plutt guids par les traitements.
39
Pour la conception des appplications interactives, la distinction entre logique de fonctionnement et logique d'utilisation nous semble particulirement prcieuse. En effet, la plupart des logiciels interactifs sont labors et prsents l'utilisateur selon une logique de fonctionnement. Ce rsultat peut apparatre normal car, aprs l'application d'une mthode classique d'analyse, on dispose toujours d'une description fonctionnelle et jamais des logiques d'utilisation. Les logiques d'utilisation doivent tre recueillies explicitement lors de l'tude de l'existant et tre ventuellement compltes par exprimentation sur prototype. La mthode de recueil des logiques d'utilisation est dcrite dans le chapitre quatre. En ce qui concerne la distinction entre tche prvue et tche effective, on peut se demander quel type de tche l'on recueille lors d'une tude de l'existant classique? Les mthodes d'analyse ne disent rien ce sujet; ce qui a pour consquence qu'en pratique cela dpend de la faon dont on a men cette tude : - si on a interrog essentiellement des responsables, on a beaucoup de chances d'avoir recueilli des tches prvues. - si on a interrog des utilisateurs effectifs, on a plus de chance d'avoir recueilli des tches effectives ou un mlange de tches effectives et de tches prvues. Pour pouvoir distinguer les diffrents types de tches, il faut que l'analyste modifie sa faon de mener les interviews en fonction de cette proccupation et complte ventuellement son tude par des simulations ou des observations. Pour plus de prcision, nous renvoyons galement au chapitre quatre. Interaction entre ces diffrents concepts Les diffrents concepts que nous venons d'exposer ne sont pas indpendants ; nous reprsentons ces relations sur le schma suivant :
Logique d'utilisation Planification hirarchique
Variabilit de la reprsentation
Tches prvues et effectives
40
La planification hirarchique permet de trouver la logique d'utilisation pour un but donn. Les variabilits de la reprsentation se traduiront soit par des logiques d'utilisation diffrentes, soit par les notions de tches prvues et de tches effectives. Pour dcrire les tches prvues et effectives, on peut utiliser la planification hirarchique.
2.2 La Conceptuelle interactive

2.2.1 Introduction
Reprsentation de l'application
Les concepts de psychologie cognitive, dvelopps prcdemment, concernent d'une part la reprsentation des traitements de l'information de l'utilisateur d'autre part les variabilits de cette reprsentation . Nous rsumons ici les concepts que nous avons retenus pour la dfinition de la Reprsentation Conceptuelle d'une application interactive. Reprsentation l'utilisateur du traitement de l'information de
Nous avons retenu deux notions : - le concept de planification hirarchique permet de dcrire le travail de l'utilisateur en partant des buts qu'il se fixe (ou qui lui sont fixs) et de remonter jusqu' l'ensemble des oprations et des pr-requis ncessaires la ralisation de ses buts, - la diffrence entre logique de fonctionnement et logique d'utilisation permet de structurer les menus selon une logique d'utilisation au lieu d'une logique de fonctionnement. Les variabilits de cette reprsentation La reprsentation du traitement de l'information, que nous venons d'voquer, n'est pas unique pour une tche donne ; cette variabilit est due deux causes : - la dformation fonctionnelle de la tche qui provient d'une part des diffrents objectifs de travail des utilisateurs, d'autre part du degr d'exprience professionnelle des diffrents utilisateurs,
41
- la diffrence entre la tche prvue et les tches effectives ; la tche prvue dcrivant la tche standard telle qu'elle est dcrite dans le cas normal ; les tches effectives dcrivant les diffrentes adaptations de la tche prvue ralises par l'utilisateur afin de pouvoir rguler son travail en fonction des alas de l'environnement. Intgration la Reprsentation Conceptuelle La Reprsentation Conceptuelle, qui correspond, comme nous l'avons vu au chapitre 1, au premier niveau de reprsentation de l'application interactive par l'analyste informaticien, intgre d'une part la description des donnes des traitements et d'une partie de l'interface (le reste tant dfini au niveau de la Reprsentation Externe), d'autre part la reprsentation du traitement de l'information de l'utilisateur et la variabilit de ces reprsentations.
Modle d'interface Systme de reprsentation et de traitement de l'information Variabilit
Modle de traitements
Modle de donnes
R.C.
Paramtres constants et variables Dans l'expos du modle de la Reprsentation Conceptuelle, il est ncessaire de distinguer les paramtres variables provenant des caractristiques particulires d'une application des paramtres constants qui sont prsents dans toute application interactive. Les paramtres variables sont issus de l'analyse du travail; il s'agit, par exemple, des buts ou de la logique d'utilisation. Les paramtres constants sont issus des caractristiques gnrales des utilisateurs; il s'agit, par exemple, des possibilits d'interrompre tout moment ou de transfrer des donnes. Comme nous le montrons la fin de ce chapitre, pour des raisons de lisibilit et d'efficacit, seuls les paramtres variables sont reprsents dans les schmas dcrivant la Reprsentation Conceptuelle.
42
2.2.2 Les paramtres variables Reprsentation Conceptuelle

2.2.2.1 Principes de base Le poste de travail
de
la
Contrairement aux mthodes d'analyse usuelle qui ont des reprsentations conceptuelles pour chaque fonction du systme d'information de l'entreprise, nous aurons une Reprsentation Conceptuelle pour chaque type de poste de travail. Le poste de travail se situe l'interaction des grandes fonctions de l'entreprise et de l'organisation de celle-ci. Les fonctions de l'entreprise, qui correspondent aux traitements des flux d'informations qui la traversent, doivent tre dcomposes en traitements qui correspondent la quantit de travail que peut effectuer un tre humain. A ce dcoupage se superpose pour des raisons de pilotage et de contrle de l'entreprise une organisation c'est--dire un ensemble de chanes de pilotage permettant de passer des projets long terme une gestion quotidienne (Mel,77). Un poste de travail sera donc dcrit par des objectifs ou buts correspondant la dcomposition des fonctions et un niveau de responsabilit correspondant sa place dans la chane de pilotage. Nous parlerons de type de poste de travail pour dsigner l'ensemble des postes de travail ayant les mmes objectifs et les mmes niveaux de responsabilit.
43
P. de travail
Flux d'information
Organisation
Nous venons d'insister sur la dfinition du poste de travail car tous les concepts que nous verrons maintenant se situent par rapport au poste de travail.
Le sens de la description du travail Gnralement, dans les mthodes d'analyse de gestion, la description du travail est de type oprationnel : elle part d'vnements dclenchants (ex: un bon de commande arrivant dans l'entreprise) et elle suit le cheminement de cet vnement tout au long des transformations qu'il subit jusqu' la fin du processus. Nous appellerons cette dmarche descendante dans le sens o elle dcrit le systme d'information depuis les vnements initiaux jusqu'aux vnements terminaux. Dans notre Reprsentation Conceptuelle, nous avons dcid d'utiliser une dmarche inverse qui est plus proche de nos connaissances du fonctionnement des oprateurs. Dans notre dmarche que nous appellerons ascendante, nous partirons de la description du (ou des) but(s) du poste de travail pour remonter jusqu'aux vnements initiaux. Le but se dfinit la fois par rapport l'organisation et par rapport au poste de travail. Il permet d'une part l'utilisateur de rguler son activit, d'autre part l'organisation de juger les performances du poste de travail par rapport aux objectifs globaux. Les buts sont dfinis au minimum pour permettre la survie du systme.
44
La tche Nous prendrons la dfinition de la tche dveloppe en ergonomie. La tche est dcrite par un but (tat final) et des conditions ; les conditions peuvent tre dcrites de l'une des trois faons suivantes : - l'ensemble des tats parcourir pour atteindre le but - les oprations admissibles pour parcourir ces tats - la procdure ou combinaisons de ces oprations. L'activit est une occurrence de ralisation d'une tche ; une tche correspondront plusieurs activits. Dans toute la suite de cet expos, nous choisissons de dcrire les conditions d'une tche par une procdure, parce que c'est l'approche qui convient le mieux la majeure partie des postes de travail concerns par l'automatisation, c'est--dire les postes de responsabilit de niveau moyen ou faible (o les raisonnements sont guids par les traitements). Pour les postes de haute responsabilit (o les raisonnements sont guids par les donnes), une approche Intelligence Artificielle base sur les oprations admissibles serait plus indique. La procdure Nous dfinissons : - le but, comme l'tat final que doit atteindre le systme hommemachine. Cet tat final sera dcrit par des critres et la valeur qu'ils doivent prendre, le mme but peut tre dcrit de plusieurs manires quivalentes. - la procdure, comme une combinaison d'oprations permettant d'atteindre le but ; elle sera dcrite par: - une liste d'oprations - une liste de pr-requis, chaque pr-requis exprimant les conditions qui doivent tre ralises pour qu'une opration puisse tre effectue. Dans le cas gnral, la notion de pr-requis permettra d'exprimer la notion de paralllisme, particulirement importante dans le cas d'applications interactives pour augmenter les possibilits d'ajustement et de souplesse de l'utilisateur. Selon leur complexit, les oprations pourront tre dcomposes en plusieurs niveaux. La plus petite dcomposition possible sera appele opration lmentaire ; elle correspond la plus petite unit de traitement de
45
l'information (commande ou donne) qui ait un sens pour l'oprateur. Le but, en fonction de sa complexit et de sa nature, pourra lui aussi tre dcompos en sous-but, sous-sous-but... jusqu' ce que l'on arrive un niveau de traitement de l'information facilement manipulable. La logique d'utilisation Les notions de but, opration, pr-requis font rfrence exclusivement la reprsentation mentale que l'utilisateur a de son travail (logique d'utilisation) ; aucun moment nous ne faisons rfrence ici un dcoupage correspondant la logique du traitement informatique ce qui a pour consquence que nous n'obtiendrons pas forcment le mme dcoupage. Nous allons illustrer ces diffrences de dcoupage des traitements sur un exemple. Exemple de gestion de documents de bibliothque La premire dcomposition de cette fonction en oprations correspond un dcoupage "informatique" (logique de fonctionnement) o le dcoupage et les regroupements correspondent la structure des donnes et aux traitements effectus sur ces donnes (cration, impression, destruction, consultation) . Nous avons un fichier thesaurus et un fichier documents, ce qui donne le dcoupage suivant :
46
Crer des termes
Prfrentiels Synonymes Hirarchie
Gestion du thesaurus
Lier des termes Rfrences
Synonymie Voisinage
Cration de documents
Auteurs Mots-cls Rfrence du catalogue Auteur
Gestion de documents
Impression
du thesaurus Mots-cls d'une liste Documents Mots-cls Donnes Documents
Destruction Hirarchie Relations Mots-cls Question Relation (et, ou, sauf) Synonymie Voisinage
La deuxime dcomposition correspond une logique d'utilisation et nous avons donc dfinir les sous-buts assigns ce poste de travail concernant le but "gestion des documents". L'analyse du travail montre que nous avons deux sous-buts : - enregistrer
47
- consulter. Pour "enregistrer", la liste des oprations possibles est la suivante : - grer les documents (cration, modification, suppression) - grer le thesaurus (cration, modification, suppression de motscls ou de liens) - consulter le thesaurus. Pour "consulter", la liste des oprations possibles est la suivante : - consulter les documents (recherche partir de critres ou de motscls) - consulter le thesaurus - imprimer les rsultats. Il n'y a pas de prcdences spcifique l'application autre que celles implicites lies la gestion des donnes (on ne peut modifier, consulter ou dtruire une information qui n'a pas t cre). La reprsentation visuelle peut se prsenter comme suit :
Consulter Grer document Modifier Supprimer Termes Consulter Sous-but 1 Enregistrer But Gestion de documents Sous-but 2 Consulter Grer thesaurus Consulter thesaurus Rechercher document Consulter thesaurus Impression Catalogue Thesaurus Liste Modifier Liens Termes Liens Termes Supprimer Liens
48
Nous remarquons que l'opration "consulter le thesaurus" figure dans les deux sous-buts, cela signifie que l'oprateur peut avoir besoin de cette opration dans chacun de ces sous-buts et qu'il pourra ainsi y accder sans repasser par une arborescence de commandes. Note : il resterait redcouper les sous-buts intermdiaires : - consulter le thesaurus - grer le thesaurus - grer les document - imprimer - consulter le document. fin de l'exemple. De manire gnrale, une mme opration pourra appartenir plusieurs buts, une mme opration lmentaire pourra appartenir plusieurs oprations. Le critre essentiel est que l'utilisateur ait "sous la main" toutes les oprations dont il peut avoir besoin pour raliser un but donn ( la duplication logique des oprations n'implique aucune duplication physique sur les supports informatiques). 2.2.2.2 Prise en compte de la variabilit dans la R.C Les procdures multiples Pour tenir compte de la variabilit d'excution d'une tche donne, nous dcrirons plusieurs procdures pour une mme tche, le but restant identique. Nous dfinissons : - la procdure prescrite (ou prvue) correspondant la procdure standard ou recommande qui est la plupart du temps, celle qui est spontanment recueillie par les analystes (interview). - la procdure effective tant celle qui est effectivement mise en oeuvre par un utilisateur donn et qui est souvent recueillie par observation. - la procdure minimale comme l'ensemble des oprations et des enchanements minimaux ncessaires pour que le but de la tche puisse tre considr comme atteint par l'ordinateur. Pour une tche donne il y aura une procdure minimale, une procdure prescrite et plusieurs procdures effectives.
49
Procdure minimale
Procdure prvue
Procdure effective 1
Les procdures effectives et la procdure prescrite devront tre compatibles avec la procdure minimale. Cette compatibilit peut s'exprimer de manire formelle mais nous voudrions ici justifier de manire intuitive ces diffrentes notions et leurs relations avec l'utilisateur. Le pilotage de l'application Dans la dfinition d'une application interactive, on fixe, la plupart du temps implicitement, la rpartition du pilotage entre l'homme et l'ordinateur. Le pilotage d'une tche (ou d'un ensemble de tches), recouvre deux notions: - la notion de contrle de l'excution de la tche - la notion de rgulation qui laisse au pilote la possibilit de modifier certaines conditions d'excution de la tche de manire atteindre l'objectif fix quels que soient les alas provenant de l'environnement. La rgulation des tches relve, dans le cas de l'informatique des organisations, quasi exclusivement de la responsabilit de l'utilisateur. En effet, les caractristiques propres d'un systme d'information d'une organisation sont, d'une part d'tre ouvert sur son environnement (ce qui rend trs difficile sinon impossible l'tablissement d'une liste exhaustive de l'ensemble des informations d'entres de l'organisation), d'autre part de grer une trs grande varit d'informations d'origines diverses (organisationnelles, psychologiques, sociologiques, techniques) qu'il est souvent difficile d'expliciter et de spcifier. Il s'en suit que les circonstances qui rclament une intervention rgulatrice ne peuvent pas tre dfinies formellement et encore moins la nature de ces interrelations.
50
On appelle latitude dcisionnelle la part de pilotage qui est sous la responsabilit de l'utilisateur. Dans le cas gnral, le contrle de l'excution d'une application interactive est partag implicitement entre l'homme et l'ordinateur selon des proportions trs variables qui peuvent voluer entre deux situations extrmes qui vont du pilotage entirement automatis au pilotage entirement assum par l'utilisateur. Quand le pilotage est laiss entirement l'utilisateur, aucun squencement des crans n'est impos l'utilisateur. Il active les traitements, dans un ordre totalement libre. Le seul contrle qui est fait par l'ordinateur porte sur l'existence des donnes manipules dans les traitements. Dans ce cas nous laissons de ct trois aspects : - aucun contrle n'est effectu sur la cohrence de la procdure par rapport au but fix - il n'y a pas de prise en compte du travail de l'utilisateur en tant qu'individu intgr dans une organisation dont le travail a un sens par rapport cette organisation. - l'ordinateur n'est pas utilis au maximum de ses possibilits. On se prive par exemple de la possibilit de faire des enchanements automatiques ou des infrences. Ce type de logiciel est en fait trs bien adapt pour des postes o les tches sont peu structures et qui peuvent travailler de manire relativement isole par rapport au reste de l'organisation. Par contre, quand le pilotage est entirement laiss l'ordinateur, il y a la garantie d'une cohrence maximale du systme d'information de l'entreprise mais au dtriment de : - la souplesse de mise en oeuvre pour l'utilisateur - la facilit d'intgrer des variabilits et des alas. Pour notre part, nous voulons nous situer de manire plus gnrale par rapport au pilotage ; les deux cas extrmes que nous venons de citer devenant deux cas particuliers de notre modle. Pour cela nous proposons un modle qui permet d'expliciter et de dcrire : - ce qui doit tre pilot par l'utilisateur, - ce qui doit tre pilot par la machine. C'est pour cela, que nous avons introduit le concept de procdure minimale qui dfinit, pour une tche donne, les contrles qui doivent tre effectus obligatoirement par l'ordinateur quel que soit le type de procdure prescrite ou effective que l'utilisateur dcide
51
de mettre en oeuvre. La procdure minimale dfinit, a contrario, les limites de la latitude dcisionnelle de l'utilisateur. En effet, tout ce qui ne sera pas explicitement dfini au niveau des enchanements et des dclenchements d'oprations dans la procdure minimale sera considr comme laiss la libre disposition de l'utilisateur et ne fera en tout tat de cause l'objet d'aucun contrle systmatique de l'ordinateur. A partir de cette procdure minimale, l'utilisateur peut se dfinir une procdure prescrite (ou standard) et une ou plusieurs procdures effectives qu'il utilisera sa convenance et qui le dchargeront dans des cas connus et rpertoris du contrle de l'excution de la procdure. Mais il pourra tout moment "reprendre la main" afin d'imposer son propre pilotage (dans les limites de sa latitude dcisionnelle) face une situation imprvue. On voit donc que la notion de procdure minimale permet de dfinir une application interactive ouverte en ce sens qu'il n'est pas utile de dfinir a priori l'ensemble des procdures effectives mais qu'elles pourront tre dfinies au fur et mesure des besoins et qu'il nous suffira de vrifier la compatibilit de chaque nouvelle procdure effective avec la procdure minimale. Pour construire la procdure minimale d'une tche nous pouvons soit procder directement si la part de contrle que l'on doit donner l'ordinateur est vidente, soit l'extraire de la procdure prvue. Dans ce dernier cas, nous remarquons que la procdure prvue dcrit des lments de nature diffrentes : - d'une part les rgles de gestion indispensables pour assurer la cohrence et la survie du systme. - d'autre part des rgles de commodit, d'usage, dites de "bon sens" qui peuvent tre transgresses sans remettre en cause le systme mais qui permettent, associes aux rgles de cohrence, de dcrire une procdure usuelle. Nous construirons alors la procdure minimale partir de la procdure prvue dont nous n'aurons retenu que les rgles de cohrence correspondant au contrle que nous souhaitons confier l'ordinateur. 2.2.2.3 Description dtaille de la R.C Nous allons dfinir de manire plus prcise les proprits des oprations et des pr-requis afin de faire le lien avec la structure des traitements et des donnes. Nous distinguons les proprits usuelles
52
de celles permettant de dcrire la rpartition du pilotage entre l'homme et l'ordinateur. Proprits usuelles des oprations Une opration sera dfinie comme un ensemble de transactions pouvant tre excutes conscutivement sans attente d'vnements externes au systme homme-ordinateur (c'est--dire que toutes les informations ncessaires au droulement de l'opration sont soit disponibles en machine soit connues de l'utilisateur). Elle sera dcrite par ses entres, sa nature, son dclenchement, son statut, ses sorties : - ses entres sont la liste des vnements qui peuvent permettre son dclenchement. Un vnement sera dcrit par un nom et la structure de donne qui lui est associe. Un vnement initial sera un vnement qui n'est pas une sortie d'opration. Un vnement terminal sera un vnement qui n'est pas une entre d'opration. - sa nature sera interactive, automatique ou manuelle : . une opration est interactive si son droulement met en oeuvre des actions de l'utilisateur et de l'ordinateur . une opration est automatique si son droulement met en oeuvre exclusivement des actions de l'ordinateur . une opration est manuelle si son droulement met en oeuvre exclusivement des actions de l'utilisateur. Par dfinition, seules les oprations interactives et automatiques sont dcrites dans la R.C d'une application interactive. Les oprations manuelles tant dcrites au niveau plus global du systme d'information existant ou concu. - au cours d'une excution son statut est activable ou non : une opration est activable si les conditions du pr-requis sont ralises. - ses sorties sont des vnements qui pourront dclencher d'autres oprations. Proprits usuelles des pr-requis Les pr-requis recouvrent deux notions distinctes ; d'une part la notion de synchronisation, d'autre part la notion de prcondition.
53
La synchronisation est une proposition logique (boolenne) portant sur la liste des vnements d'entre de l'opration Oi
(A .ET. B) .OU. C peut constituer une synchronisation c'est--dire que Oi deviendra activable quand soit les vnements A et B seront raliss (ou vrai) soit l'vnement C.
A la synchronisation on associera galement la notion de dlai qui correspond une rgle de temps concernant le dclenchement d'une opration Oi quand celle-ci est devenue activable: - dlai nul : l'excution de Oi devra avoir lieu ds que Oi est activable - dlai libre : l'excution de Oi pourra avoir lieu n'importe quel moment aprs son activation - dlai avec bornes : O i devra tre dclench avant une date D1 et aprs une date D2 . Les prconditions expriment une condition sur la valeur des donnes contenues dans l'vnement, conditions qui doivent tre vraies pour que l'vnement soit considr comme ralis. On peut dduire des pr-requis, la notion de prcdence entre oprations. La prcdence exprime un lien de priorit d'excution entre oprations. Si P (Oi, O j) est satisfait cela signifie que Oi doit tre excut avant Oj. Proprits lies au pilotage Pour prciser le pilotage nous sommes amens rajouter des proprits aux oprations et pr-requis : - une opration est obligatoire ou facultative : . une opration est obligatoire si son excution, quand elle est activable, est ncessaire pour atteindre le but. . une opration est facultative si son excution ou sa non excution n'interdit pas d'atteindre le but. - le dclenchement d'une opration est optionnel ou systmatique : . le dclenchement de l'opration est optionnel l'utilisateur s'il dpend de
. le dclenchement de l'opration est systmatique s'il dpend de l'ordinateur. - une prcdence est permanente si elle existe dans toutes les descriptions procdurales de la tche (procdure minimale, prvue, effective)
54
- une prcdence est indicative si elle existe dans une ou plusieurs procdures effectives ou prescrites sans exister dans la procdure minimale. Il est important de noter que les proprits de pilotage sont propres un but.. Cela veut dire qu'une mme opration qui appartiendra deux buts B1 et B 2 peut tre obligatoire dans B1 et facultative dans B2 , et il en sera de mme pour les prcdences. La signification de ces proprits par rapport la notion de pilotage est la suivante : - une opration obligatoire est pilote par l'ordinateur, c'est--dire qu'il contrle son excution. Le but sera considr comme atteint par l'ordinateur si toutes les oprations obligatoires activables ont t ralises. - une opration facultative est pilote par l'utilisateur qui en contrle l'excution. Soit en reprenant l'exemple prcdent de la gestion de documents; oprations OBLIGATOIRE : grer document, GD grer thesaurus, GT Sous-but 1 (SB1 ) oprations FACULTATIVE : consulter thesaurus rechercher document impression Sous-but 2 (SB2 ) SB1 sera considr comme atteint par l'ordinateur si, pour une occurrence de donne, GD et GT ont t raliss. Le But sera considr comme atteint par l'ordinateur si, pour une occurrence de donne, SB1 a t atteint. Toutes les autres oprations sont laisses la libre utilisation de l'utilisateur et leur excution ou non ne fait pas l'objet d'un contrle par l'ordinateur. Pour les prcdences, nous avons le mme type de signification : - une prcdence permanente est pilote par l'ordinateur qui contrle ainsi le dclenchement de l'opration associe
55
- une prcdence indicative est pilote par l'utilisateur qui peut sa demande tre guid dans le droulement de la procdure. Les notions que nous venons de dfinir sont valables pour toutes les procdures sans distinction de procdure prvue, minimale ou effective. La procdure minimale exprime le contrle minimal sur l'utilisateur : elle laisse un pilotage maximal de son travail l'utilisateur. Les procdures prvues et effectives sont des variantes possibles de la procdure minimale qui d'une part restreignent le pilotage de l'utilisateur, d'autre part lui facilitent son travail (enchanements automatique, guidage...).
Les rapports entre proprits Nous allons examiner les rapports entre les diffrentes proprits. Nous examinerons tout d'abord le lien entre les proprits d'une opration puis entre oprations et pr-requis. Les rapports entre les proprits des oprations Nous rappellons qu'une opration est dfinie par ses entres, sa nature, son dclenchement, son statut, ses sorties, son caractre obligatoire ou facultatif. Nous examinons les relations entre : - dclenchement et obligatoire/facultatif - dclenchement et nature - nature et obligatoire/facultatif - dclenchement et vnement d'entre. Les autres proprits sont de toute indpendantes.
vidence
totalement
Rapport entre dclenchement et obligatoire/facultatif Ces deux proprits ne sont pas indpendantes. En effet, si une opration est facultative son dclenchement est ncessairement optionnel puisque seul l'utilisateur peut savoir si cette opration doit ou non tre dclenche. Nous avons l'implication : facultatif => optionnel qui quivaut : systmatique => obligatoire.
56
Le dclenchement systmatique ne peut donc avoir lieu que si l'opration est obligatoire. Par contre, une opration obligatoire peut avoir un dclenchement optionnel ou systmatique. Rapport entre dclenchement et nature Dans la description de la R.C d'une application interactive, une opration ne peut tre qu'interactive ou automatique. Si l'opration est interactive, son dclenchement peut tre optionnel ou systmatique. Si l'opration est automatique, son dclenchement peut tre optionnel ou systmatique. Ce qui revient dire que nature et dclenchement sont indpendants. Rapport entre nature et obligatoire/facultatif Ici aussi nous avons deux proprits indpendantes car une opration interactive ou automatique peut tre indiffremment obligatoire ou facultative. Rapport entre dclenchement et vnement d'entre Au niveau de la R.C., le dclenchement optionnel peut tre considr comme une forme particulire d'entre distincte d'un vnement du systme d'information, en ce sens que l'vnement est dcrit par une structure de donne alors que le dclenchement optionnel est dcrit par une commande utilisateur. Les vnements d'entre et le dclenchement concourent la ralisation du prrequis ncessaire l'activation de la tche. Si les vnements d'entre ont eu lieu, cela entrane l'activation de la tche si le dclenchement est automatique, sinon cela rend possible le dclenchement optionnel de la tche. Mais, dans ce dernier cas, la tche ne sera active que si l'utilisateur dcide d'user de son droit de dclenchement. Les rapports entre les proprits des prcdences et des oprations Nous allons maintenant examiner le lien entre les proprits des oprations et des prcdences suivantes : - celle d'obligatoire ou de facultatif pour les oprations, - celle de permanent ou indicatif pour les prcdences, les autres proprits tant indpendantes. La question qui se pose ici est de savoir si certaines combinaisons de ces proprits ne pourraient pas aboutir des situations de blocage. Nous examinerons seulement le cas de prcdence permanentes car les prcdences indicatives ne donnent pas lieu vrification. Soit P(O i,Oj) une prcdence entre Oi et O j ; si O i et O j sont de mme type
57
(tous les deux obligatoires ou tous les deux facultatifs), il n'y a aucun problme. Si O i est obligatoire et Oj facultatif cela signifiera que, une fois Oi excute, Oi ne le sera pas forcment car cela dpendra de l'utilisateur. Mais ce cas ne provoquera pas de blocage. Si O i est facultatif et Oj obligatoire, Oj ne sera dclench que si Oi l'est. En effet, si Oi n'est pas excut O j ne pourra pas tre dclench et Oi tant facultatif son dclenchement est ncessairement optionnel c'est--dire dpendant de l'utilisateur. Donc si l'utilisateur ne dclenche pas Oi, O j ne pourra pas tre dclenche car elle ne sera pas activable. Mais ce cas non plus ne sera pas un blocage car la dfinition d'une opration obligatoire prcise que le dclenchement de cette opration est ncessaire pour atteindre le but seulement si elle est activable, ce qui n'est pas forcment le cas. L'examen de ces cas montre clairement que par le biais des oprations facultatives l'utilisateur peut avoir une marge de manoeuvre importante et que le comportement de la procdure ne sera pas dterministe. Correspondances entre procdure prvue, minimale effective et
Nous avons vu qu' une procdure prvue correspond dans un contexte donn une procdure minimale et qu' une procdure minimale correspond plusieurs procdures effectives. Nous voulons expliciter dans ce paragraphe quelles sont les correspondances entre les diffrentes tches afin de pouvoir vrifier la compatibilit entre : - la procdure prvue et la procdure minimale, - une procdure effective et la procdure minimale. Par compatibilit, nous voulons dire qu'une procdure prvue, une procdure effective et une procdure minimale dcrivent bien la mme tche. Une procdure prvue pour un poste de travail et un but donns est dcrite par une liste d'oprations et une liste de pr-requis. La procdure prvue correspond la procdure standard qui est excute dans un cas normal ou pour guider un utilisateur novice. La procdure prvue pour un poste de travail et un but donns est dcrite par les mmes lments que la procdure minimale pour lesquels on peut modifier le pilotage en:
58
- supprimant des dclenchements optionnels - rajoutant des prcdences indicatives - augmentant les oprations obligatoires ou les prcdences permanentes. Pour un poste de travail donn, on dira qu'une procdure minimale et une procdure prvue sont compatibles si : i) la procdure prvue et la procdure minimale ont le mme but ii) toutes les oprations obligatoires de procdure minimale sont des oprations de procdure prvue iii) toutes les prcdences permanentes de procdure minimale sont des prcdences de procdure prvue iiii) tous les dclenchements systmatiques de procdure minimale sont des dclenchements de procdure prvue. Nous remarquons que l'ensemble des squences de procdure prvue ralisant le but doit tre inclus dans l'ensemble des squences de procdure minimale ralisant le but. La vrification de cette inclusion est fondamentale car elle permettra l'analyste de vrifier que la procdure minimale qu'il vient de dfinir lui permettra d'excuter la procdure prvue correspondante. Une fois la procdure minimale dfinie, il nous faudra vrifier la compatibilit de toutes les procdures effectives que nous crerons par rapport la procdure minimale. La procdure prvue et les procdures effectives ont la mme dfinition de compatibilit par rapport procdure minimale car la procdure prvue peut tre considre par rapport aux validations comme une procdure effective particulire. Mais la distinction fondamentale entre une procdure prvue et une procdure effective est d'ordre mthodologique. La procdure prvue correspondant gnralement la premire observation de la tche que nous pouvons faire et qui est, par dfinition, la tche standard alors que les procdures effectives correspondent toutes les variantes apportes par les utilisateurs en situation relle de travail et qui seront dfinies au fur et mesure des besoins. 2.2.2.4 Formalisme graphique Nous dfinissons un formalisme graphique qui permet de dcrire l'ensemble des concepts que nous avons dfinis dans la R.C.
59
Concept
Reprsentation graphique
Opration automatique Opration interactive Opration manuelle Opration obligatoire Opration facultative
o f
Rgle d'mission Rgle Evnement (entre ou sortie d'opration) Evnement terminal Rgle
Dclenchement optionnel
Dclenchement automatique Pr-requis
Par dfaut (si pas optionnel)
Equation boolenne sur les vnements d'entre (figure dans le symbole du pr-requis) . Ex : Synchronisation v a b
Prcdence permanente Prcdence indicative
60
Exemple : procdure minimale d'un poste de documentation
Arrive document
Bon de commande
Enregistrement des bases du document o Enregistrement des mots-cls du document o
Crer termes du thesaurus
Crer liens entre termes f
Consulter thesaurus f
Rechercher documents f
Impression thesaurus, catalogue, liste f
61
Exemple : une procdure effective poste de documentation d'un
Arrive document
Enregistrement des bases du document o
Enregistrement des mots-cls du document o inconnu connu Rechercher documents f
62
Commentaires sur l'exemple L'exemple ci-dessus est extrait de la Reprsentation Conceptuelle d'un poste de documentation. Il concerne le but "Enregistrement de nouveaux documents". Pour satisfaire ce but, le documentaliste a besoin de disposer des oprations de mise jour du thesaurus et de consultations diverses; c'est pourquoi ces oprations figurent dans la description de la procdure minimale. Toutes les prcdences permanentes et les oprations obligatoires de la procdure minimale doivent figurer dans toutes les procdures effectives; c'est le cas, ici, de la prcdence permanente entre les oprations obligatoires "Enregistrement des bases du document" et "Enregistrement mots-cls du document". Il est possible, par contre, de rajouter des prcdences permanentes et des oprations obligatoires dans une procdure effective pour minimiser les manipulations de l'utilisateur dans les cas usuels; c'est le cas, ici, pour la prcdence entre les oprations "Enregitrement mots-cls du document" et "Crer termes du thesaurus" qui devient permanente dans la procdure effective ainsi que l'opration "Crer termes du thesaurus" qui devient obligatoire et automatique. Mais l'opration "Crer liens entre termes" est reste interactive, facultative et dclenchement optionnel car c'est une opration complexe pour le documentaliste et il n'est pas vident qu'il ait envi de l'effectuer ponctuellement pour tout nouveau mot-cl enregistr dans le thesaurus. Le mme formalisme s'applique tous les diffrents niveaux de dtails; chaque opration est reprise et dtaille jusqu'au niveau de l'opration lmentaire dans la communication homme-machine, c'est--dire une entre ou une sortie d'une transaction. Un exemple complet est montr dans le chapitre 5. Il est important de noter que seuls les paramtres variables sont exprims sur ce schma; pour des raisons de lisibilit les paramtres constants que nous dveloppons au paragraphe suivant sont volontairement omis. En consquence, ces schmas doivent tre interprts comme la rpartition du pilotage entre l'homme et l'ordinateur en ce qui concerne les paramtres variables auxquels viennent s'ajouter de manire implicite toutes les possibilits des paramtres constants.
2.2.3 Les paramtres constants Reprsentation Conceptuelle
de
la
Ces paramtres vont constituer des aides l'utilisateur utilisables quelle que soit la tche effectue par lce dernier. Le caractre
63
gnral de ces paramtres fait qu'ils n'ont pas besoin d'tre spcifis pour chaque application. Nous distinguerons les aides la ralisation de l'activit, les aides l'apprentissage et les possibilits d'volution du logiciel. 2.2.3.1 Aides au travail Interruption L'interruption permet l'utilisateur de quitter n'importe quelle opration en cours d'excution pour aller excuter une autre opration et reprendre la premire opration son point d'interruption. On peut prvoir plusieurs niveaux successifs d'interruption, bien que concrtement, au-del de trois ou quatre niveaux, ce soit difficilement grable par l'utilisateur. Cette notion est particulirement importante pour toutes les oprations de consultation auxquelles on veut accder alors qu'une autre opration est active. Notre hypothse est qu'en systme monoposte, toutes les oprations sont possibles tout moment. Pour les systmes en temps partag, cela ncessite que le systme gre les conflits ventuels concernant les mises jour multiples de fichiers. Transfert de donnes La possibilit est donne l'utilisateur de transfrer une donne d'une opration une autre sans avoir la ressaisir. Cette fonction permet de minimiser les saisies et donc d'viter les erreurs de recopie; elle permet galement, lors des interruptions, de transporter une donne dans plusieurs oprations successives. Quitter L'utilisateur doit pouvoir demander l'abandon de son travail n'importe quel moment sans avoir finir une opration ou repasser par une arborescence du menu. Le logiciel peut lui signaler les consquences de cette demande selon l'endroit o elle se situe. Diffrer L'utilisateur peut diffrer n'importe quelle opration dans le temps afin de la reprendre ultrieurement sa convenance. Diffrer se distingue de quitter en ce sens que dans l'action de diffrer il y a mmorisation de l'opration non termine ce qui n'est pas le cas dans l'action de quitter.
64
Annuler L'utilisateur peut annuler la dernire action qu'il vient de faire; cette possibilit est particulirement utile pour le redressement des erreurs perues par l'utilisateur ou signales par le logiciel. Mmorisation de l'activit Ce modle d'interface n'imposant pas de cadre rigide l'oprateur, celui-ci peut connatre des difficults de mmorisation de ce qu'il a accompli. Plusieurs types de mmorisation lui seront donc proposs: - entre les sessions, l'enregistrement, pour un utilisateur, des oprations qu'il a diffres dans le temps. Cet enregistrement lui permettra tout moment de connatre l'ensemble des oprations qui sont "en cours" et qu'il devra finir un jour. - entre les sessions, la mmorisation des paramtres propres l'utilisateur: identification, vocabulaire propre, procdures effectives... - en cours de session, l'enregistrement des interruptions successives et non termines qui sont en train d'tre ralises par l'utilisateur. Ceci lui permet surtout de ne pas se perdre dans le logiciel, en particulier s'il est lui-mme interrompu par un vnement extrieur. - en cours de session, on peut avoir aussi une trace du travail total ou dfaut des deux ou trois dernires oprations ralises afin de pouvoir remonter facilement l'tat prcdent du systme. Cette trace de l'activit peut tre intressante pour la dtection et le redressement des erreurs contates par l'utilisateur (en l'absence de possibilit de retour-arrire automatique, ce qui est difficile raliser en toute gnralit). 2.2.3.2 Aides l'apprentissage Nous voulons parler ici d'aide l'apprentissage du maniement du logiciel propos et non pas du travail lui-mme. Nous proposons deux types d'aide qui sont le guidage fonctionnel et le guidage d'utilisation. Guidage fonctionnel Une commande de type SOS doit permettre tout moment l'utilisateur de connatre soit la liste des oprations possibles dans
65
l'tat actuel d'avancement de son travail, soit une explication des fonctions et effets d'une commande donne. Ce type de possibilit est maintenant classique sur un grand nombre de logiciels. Guidage d'utilisation A tout moment, l'utlisateur doit pouvoir passer un mode guid selon une logique d'utilisation o un enchanement d'oprations correspondant aux prcdences permanentes et indicatives lui sera propos en fonction du but qu'il s'est fix. Ce type de guidage peut permettre de rpondre des questions du type "Comment faire pour? ". Ceci est rendu possible grce la structuration du systme en buts, sous-buts, oprations et prcdences. 2.2.3.3 Les possibilits d'volution Nous parlons ici essentiellement d'volution hors programmation, c'est--dire qui peuvent tre mises en uvre, ventuellement, par l'utilisateur lui mme. Ce qu'il sera ais de modifier concerne: - la cration de nouvelles procdures effectives adaptes aux modes de travail des diffrents utilisateurs - la rpartition du pilotage entre l'homme et l'ordinateur c'est-dire les notions de dclenchement, d'oprations obligatoires ou facultatives, de prcdences permanentes ou indicatives - les niveaux d'oprations intermdiaires qui n'ont pas t initialement prvus mais qui utilisent des oprations dj connues de la machine. Cela peut permettre l'utilisateur de se crer ses propres squences standard ou des macro-oprations originales Si on veut faire appel de nouveaux traitements qui ne peuvent pas tre composs partir des oprations dj connues de la machine, il sera ncessaire de programmer ces nouveaux modules. Il en va de mme si l'on veut faire apparatre des donnes ou des relations entre donnes non dcrites dans les structures de donnes de la machine. Cependant, la reprsentation interne que nous proposons au chapitre cinq pour implmenter ce systme est oriente vers une facilit maximum d'volution. Les paramtres constants des applications interactives que nous venons de dcrire doivent tre prsents constamment dans l'esprit de l'analyste pour deux raisons: - ils facilitent et allgent la description de la reprsentation conceptuelle de chaque application interactive ; en effet, l'analyste
66
n'a plus besoin de spcifier les points de retour possibles au menu principal ou aux oprations de consultation puisqu'il est possible tout moment de quitter, de diffrer ou d'interrompre; - inversement, ils permettent d'interprter diffremment les schmas de la reprsentation conceptuelle. Pour se convaincre de la ncessit de ne pas faire figurer les paramtres constants, nous avons visualis sur le schma suivant qui reprend l'exemple de la procdure effective de la documentaliste ce qui se passerait si on indiquait par des flches toutes les possibilits d'interrompre et de quitter de l'utilisateur. Nous voyons clairement que les schmas de la Reprsentation Conceptuelle deviendraient alors illisibles. En pratique, il n'y a que dans le cas o les possibilits standard de l'utilisateur sont rduites qu'on peut les faire figurer dans les schmas.
67
Contre-exemple : visualisation de commandes Quitter et Interrompre s
Arrive document
Enregistrement des bases du document o
Interrompre Enregistrement des mots-cls du document o inconnu connu Rechercher documents f
Interrompre o
Interrompre
68
Chapitre 3 : LES ASPECTS DE SURFACE DES APPLICATIONS INTERACTIVES

Ce chapitre a pour but de prsenter les principes de conception de la Reprsentation Externe qui correspond ce que voit l'utilisateur de l'application interactive. Comme nous le rappelons dans le schma ci-dessous, la Reprsentation Externe provient d'une part des concepts de la Reprsentation Conceptuelle, d'autre part de critres de psychologie cognitive ou d'ergonomie. Il faut aussi noter que la conception de la Reprsentation Externe est fortement dpendante de contraintes techniques qui sont d'une part les caractristiques physiques de l'cran, d'autre part les logiciels de gestion d'cran. Pour mettre en valeur ces contraintes, nous donnons des exemples de mise en oeuvre avec un logiciel de gestion d'cran classique et avec un logiciel de multifentrage. Ce chapitre est divis en trois parties. Dans la premire partie, nous prsentons les connaissances de psychologie cognitive sur la structure de la mmoire et sur l'apprentissage car elles permettent de mieux comprendre le fondement des recommandations ergonomiques. Dans la deuxime partie, nous exposons les recommandations ergonomiques concernant les sept paramtres de l'interface et nous citons des expriences d'observations directes. Dans la troisime partie, nous montrons comment intgrer ces lments la conception de la Reprsentation Externe compte-tenu des contraintes des logiciels de gestion d'cran.
69
3 . 1 L'apport de la psychologie cognitive la Reprsentation Externe

3.1.1 Les structures de la mmoire humaine
La perception et l'enregistrement d'une information quelconque chez l'tre humain met en cause trois types de mmoire: - un registre de l'information sensorielle qui est capable de contenir l'intgralit d'une image pendant un temps trs court (de 0,1 0,5 secondes), - une mmoire court terme qui interprte les informations contenues dans le registre de l'information sensorielle afin d'en extraire les lments significatifs, - une mmoire long terme que l'on peut considrer comme sans limite par rapport la longueur d'une vie humaine.
70
auto-rptition de maintien Registre de l'information sensorielle (0,1 0,5 s) Mmoire court terme (7 items, 2 s)
Mmoire long terme (structure)
Nous ne dveloppons pas ici les caractristiques du registre de l'information sensorielle car elles relvent de la perception physiologique et concernent par consquent l'ergonomie du matriel. Les mmoires court terme et long terme ont par contre un impact important sur l'ergonomie du logiciel. La mmoire court terme constitue une limite norme pour l'tre humain; en effet et schmatiquement, elle ne peut retenir que 7 items pendant un dlai de deux secondes.. Un item correspond une unit d'information significative pour un individu. Exemple d'items: H C T correspond trois items CHAT correspond un item (pour une personne connaissant le franais) Le chiffre de 7 items correspond une moyenne qui fluctue entre un minimum de 5 et un maximum de 9 selon les personnes. Le dlai de deux secondes de rtention de l'information sans altration et sans effort est un minimum atteint par tout le monde. Au-del, cette information s'altre avec le temps; au bout de trois secondes, il n'y a plus que 80% de rponses justes et six secondes 40%. Si l'on dsire conserver une information plus longtemps dans la mmoire court terme, il est ncessaire de procder une autorptition de maintien qui consiste rpter mentalement cette information jusqu' son utilisation. C'est ce que nous pratiquons spontanment quand nous voulons nous souvenir d'un numro de tlphone que nous ne pouvons crire immdiatement. L'effacement de la mmoire court terme se produit spontanment avec le temps, mais il peut tre provoqu aussi par interfrence avec d'autres informations; en effet, l'arrive de nouvelles informations que nous dsirons mmoriser effacera une partie ou la totalit des
71
informations prsentes dans la mmoire court terme et ces dernires seront dfinitivement effaces si nous n'avons pas eu le temps de les faire basculer de la mmoire court terme vers la mmoire long terme ou de les transcrire sur papier. Les mcanismes de mmorisation et de recherche dans la mmoire long terme ne sont pas connus avec autant de prcision que ceux de la mmoire court terme. Cependant, nous savons que l'effort de mmorisation dans la mmoire long terme requiert une concentration qui nous rend relativement indisponible pour d'autres tches. Par exemple, nous savons qu'il est difficile pour un tudiant d'crire compltement une phrase entendue et de la mmoriser en mme temps; cette difficult est accrue s'il ne comprend pas cette phrase. Ce dernier phnomne est d, d'une part aux limites de la mmoire court terme, d'autre part au fait que la mmorisation dans la mmoire long terme est facilite par la comprhension et par la possibilit de rattacher toute nouvelle information une information dj existante dans nos structures mentales. En d'autres termes, il est plus facile de retenir une information dans un domaine connu et qui complte des informations que nous possdons dj ou dit autrement "plus on sait, plus on est capable d'apprendre". Ce fait explique l'intret du raisonnement par analogie qui permet de comparer un phnomne inconnu un phnomne connu. La notion de comprhension est lie la notion de structure de l'information; cela suppose que l'information que l'on veut mmoriser a une structure significative et que cette structure a une correspondance avec la structure des informations que nous possdons dj. Une consquence immdiate est qu'une information strcture est plus facilement mmorisable. A partir de ces faits, diffrents modles explicatifs du fonctionnement de la mmoire ont t labors, mais nous ne les exposerons pas ici car il ne s'agit que d'hypothses et ils n'ont pas de consquences pratiques en ergonomie du logiciel. Les consquences de cette structure de la mmoire sur les interfaces sont multiples: - une simple interruption (tlphone, client,...) cre un effacement de la mmoire court terme; pour remdier cette limite, il est ncessaire de mmoriser l'activit de l'utilisateur de manire pouvoir lui rappeller ces dernires actions, de lui signaler ces erreurs le plus tt possible, de lui signaler les consquences de ces actions,
72
- la dgradation rapide de l'information de la mmoire court terme avec le temps doit tre prise en compte dans la conception du paramtre "temps de rponse", - les limites de capacit en quantit d'information de la mmoire court terme ncessitent la concision et l'emploi de concepts les plus agrgs possibles sous la forme la plus identifiable correspondant ainsi (aprs apprentissage) un seul item, - la mmorisation en mmoire long terme est facilite par la compatibilit entre les anciennes et les nouvelles procdures ou par des analogies avec des systmes connus.
3.1.2 Exprience et automatisme

Nous avons dj parl dans le chapitre prcdent de la diffrence entre utilisateurs novices et utilisateurs expriments en insistant sur le fait qu'ils n'ont pas la mme reprsentation de leur travail, nous voulons prsenter ici une autre diffrence qui a un impact important sur les interfaces. L'utilisateur qui rpte souvent les mmes tches sur des priodes suffisamment longues acquiert des automatismes qui lui permettent d'excuter ces tches trs rapidement et avec une mobilisation minimale de ces processus conscients. En effet, l'excution de ces tches devient en partie ou totalement inconsciente et l'efficacit du travail s'en trouve notablement accrue. Par analogie avec l'ordinateur, on pourrait dire que ces tches sont devenues "cables". Nous pouvons citer comme exemple l'apprentissage du clavier ou la conduite de sa voiture sur un itinraire quotidien. De manire schmatique, nous pouvons mme dire qu'un des objectifs essentiels de tout apprentissage est de crer chez l'individu le maximum d'automatismes pour toutes les tches rptitives afin de lui permettre de dgager le maximum de temps pour des activits plus rares et plus complexes. Une consquence immdiate de cette connaissance est que la conception de l'interface doit favoriser la cration de ces automatismes. Pour cela nous devons concevoir tous les paramtres avec le maximum d'homognit. En effet, la cration d'automatismes ne peut se produire que si dans toutes les situations identiques l'action de l'utilisateur est la mme. Par exemple, la touche permettant de valider l'entre des donnes doit tre la mme pout toutes les applications informatiques.
73
Ce souci d'homognit a un impact sur presque tous les paramtres de l'interface: - en entre: touches/fonction ou souris - en sortie: disposition spatiale de l'cran - erreurs: prsentation et rectification - langage: syntaxe et vocabulaire - squencement: procdure d'enchanement - guidage: prsentation et concepts
3.2 L'apport de l'ergonomie la Reprsentation Externe

3.2.1 Les paramtres de l'interface
Comme nous l'avons vu au chapitre 1, l'interface vue par les ergonomes se dcompose en sept paramtres qui sont: - le squencement des oprations - le langage d'interaction - les dispositifs d'entre - les dispositifs de sortie - le temps de rponse - le traitement des erreurs - le guidage Mais ces paramtres ne sont pas homognes et, en particulier, ils ont des impacts diffrents sur l'utilisateur. Pour illustrer ce fait, mous prsentons une modlisation de l'oprateur en trois niveaux faite par Falzon (Fal, 82) propos du contrle arien: - Le premier niveau concerne les caractristiques physiologiques de l'oprateur; il fait rfrence aux travaux concernant la perception physiologique comme, par exemple, les limites de lisibilit sur un cran, la fatigue visuelle, etc... - Le deuxime niveau concerne le traitement par l'utilisateur des oprations lmentaires. La mmorisation du vocabulaire ou l'utilisation correcte d'une syntaxe fait partie de ce niveau . Ce niveau regroupe les aspects lexicaux et syntaxiques utiliss en linguistique. - Le troisime niveau concerne le systme de reprsentation et de traitement de l'information de l'utilisateur qui lui permet de synthtiser, rsoudre un problme en fonction des informations disponibles. Par exemple, la reprsentation d'une procdure de
74
traitement ou la rsolution d'un problme fait partie de ce dernier niveau. Ce niveau regroupe les aspects smantiques et contextuels de la linguistique. Si on considre les diffrents paramtres de l'interface, on s'aperoit qu'ils n'ont pas le mme statut vis--vis des trois niveaux de l'utilisateur. Par exemple, le squencement des oprations fait appel aux niveaux II et III de l'utilisateur. Nous pouvons reprsenter l'ensemble de ces effets sur le tableau suivant :
Niveaux Paramtres Squencement des oprations mode opratoire Langage d'interaction Dispositifs d'entre Dispositifs de sortie Temps de rponse Traitement des erreurs
I. Physiologique
II. Oprations lmentaires
III. Systme de reprsentation et de traitement
Dans la suite de ce travail, nous ne nous intressons pas aux effets physiologiques qui relvent de l'ergonmie du matriel mais seulement aux niveaux II et III qui relvent de l'ergonomie du logiciel. Aussi, nous n'exposerons pas ici les effets physiologiques des disposifs d'entre et de sortie bien qu'ils aient fait l'objet de trs nombreux travaux en ergonomie.
75
3.2.2 Recommandations ergonomiques pour les paramtres de l'interface

Nous prsentons des recommandations ergonomiques sur les sept paramtres numrs prcdemment. Le sujet est trop rcent pour que ces recommandations soient exhaustives et en outre la combinaison de ces recommandations peut aboutir des contradictions partielles qui ne peuvent tre leves que par une exprimentation auprs des utilisateurs. 3.2.2.1 Squencement des oprations Le problme voqu ici est celui de l'adquation entre l'ordre des oprations fix par la machine et celui ncessaire l'oprateur pour effectuer sa tche dans n'importe quel environnement. En effet, la plupart du temps la conception de l'interface se fait en fonction du droulement normal (tche prvu) ou moyen de la tche sans tenir compte des types d'utilisateurs (expriment / novice) ou d'alas provenant de l'environnement; alors que, ces lments constituent le contexte naturel de toute tche effectue par un tre humain . Nous rapellons que la plupart des caractristiques du squencement font partie de la structure profonde des logiciels et sont ce stade dj dtermines, il s'agit : - du type d'enchanement (libre, guid, automatique) - des possibilits d'enchanements varis selon le degr d'exprience et le type d'utilisateur - d'accder toutes les informations avec autant ou plus de facilit qu' la main - de pouvoir quitter ou annuler tout moment - d'interrompre tout moment une transaction en cours soit pour un temps bref (consultation), soit pour la reprendre ultrieurement (diffrer) - d'afficher ce que l'on vient de faire afin de reprendre plus facilement aprs une interruption - de faire appel une opration quelconque partir d'une autre et de revenir en arrire - de transfrer des informations d'une opration l'autre. La partie externe du logiciel devra permettre l'utilisateur d'excuter le plus facilement possible l'ensemble des possibilits
76
ainsi offertes c'est--dire qu'au niveau de l'interface, il faudra traduire ces caractristiques en: - dispositifs de sortie et d'entre - vocabulaire et syntaxe - messages d'erreur et guidage, ainsi que nous allons le voir dans les paragraphes suivants. 3.2.2.2 Langage d'interaction Le langage d'interaction est l'outil qui va permettre l'utilisateur d'exprimer, au moyen d'un vocabulaire et d'une syntaxe, les oprations qu'il dsire faire effectuer la machine. Ces oprations portent sur des commandes et / ou des donnes. Le vocabulaire De faon unanime, les ergonomes privilgient l'emploi du langage des spcialistes de la tche plutt qu'un langage d'informaticien. Or, l'heure actuelle, on ne peut pas dire que l'on trouve ce type de langage dans tous les logiciels dvelopps. A cel, plusieurs raisons : - la premire, de fond, est lie la dfinition mme du langage d'interaction qui est un compromis entre les tches de l'utilisateur et les fonctions informatiques - la seconde, plus circonstancielle, est lie au fait que ces langages sont conus par des informaticiens qui pensent en fonction de la machine et de leur propre formation (voir l'tude faite par Scapin (Sca,81) d'un langage de messagerie lectronique ) - la dernire est lie la cration de tches nouvelles ou traites diffremment cause de l'automatisation (traitement de texte, messagerie lectronique) et qui ncessitent donc trs souvent la cration d'un vocabulaire nouveau. Dans le cas o l'on ne peut utiliser des mots du vocabulaire courant ou du vocabulaire professionnel en leur conservant le mme sens, que peut-on choisir comme vocabulaire du langage de commande : - des codes numriques ? - des codes mnmoniques ? - des mots de la langue franaise ? - des mots inconnus ? - des pictogrammes?
77
Les codes numriques font l'unanimit contre eux par leurs difficults tre mmoriss et les risques d'erreurs levs. Leurs seuls avantages rsident dans le fait qu'ils sont courts et donc rapides saisir. Cependant les codes numriques qui peuvent tre dcomposs selon une structure connue sont plus faciles mmoriser (comme nous l'avons vu pour la mmorisation long terme). Les codes mnmoniques sont prconiss assez frquemment mais sans qu'il y ait accord sur leurs rgles de fabrication : faut-il prendre la premire lettre du mot, les deux premires lettres, les trois premires lettres ou d'autres ? Nous manquons ici d'expriences srieuses nous disant quelles rgles de troncatures assureraient une meilleure mmorisation et un moindre risque d'erreur. Peut-tre n'existe-t-il pas de rgles gnrales et faut-il tester ceci pour chaque langage ? Certains prconisent de laisser aux utilisateurs le soin de crer eux-mmes leurs prores abrviations partir des mots complets. Les mots du langage naturel : de nombreux informaticiens estiment que l'utilisation du langage naturel est ce que l'on peut offrir de mieux l'utilisateur. C'est pourquoi l'valuation d'un langage (Sca,81) dvelopp dans le cadre d'une messagerie lectronique est intressante car le rsultat est absolument contre-intuitif. En voici les principales conclusions : - le vocabulaire est mieux compris par les informaticiens que par les utilisateurs nafs ; ce rsultat provient du fait que ce vocabulaire ayant t choisi par les informaticiens (inconsciemment en fonction de leur culture), les mots utiliss avaient un sens diffrent dans le contexte informatique par rapport au langage courant - les termes choisis ne sont pas vidents sans apprentissage - il y a de nombreuses confusions dues des problmes de synonymie et d'indtermination syntaxique - la mmorisation est trs mauvaise car il semble, la limite, plus difficile de mmoriser un mot connu avec un nouveau sens que de mmoriser un mot nouveau Les mots inconnus (crs ou issus d'une langue trangre) : il n'y a plus de risque de confusion comme prcdemment, mais il y a un effort de mmorisation plus important.
78
Les pictogrammes peuvent se rvler trs intressants quand ils sont sans ambigut pour l'utilisateur; leur intrt rside dans le fait qu'ils permettent d'exprimer un concept sous un seul item facilement mmorisable dans la mmoire court terme, et qu'ils peuvent permettre l'analogie avec un cas manuel connu ce qui facilite la mmorisation long terme. De tout cela, se dgage le fait qu'il n'y a pas une solution qui l'emporte nettement; il y a donc lieu de procder par exprimentation dans chaque cas. D'o l'intrt d'un prototype d'interface sur lequel on peut exprimenter et que l'on peut modifier aisment. La syntaxe Ce sont les rgles qui permettent d'exprimer les commandes ou les donnes et de les combiner entre elles. Les diverses tudes se rejoignent sur la ncessit de deux caractristiques: - simplicit pour des raisons de mmorisation - homognit pour viter les risques d'erreurs. En effet si la syntaxe est homogne, l'utilisateur peut dvelopper une automatisation de son comportement en tapant, par exemple "retour chariot" aprs chaque commande. Si cette rgle a des exceptions, ces exceptions seront fatalement des sources d'erreurs. Il faut noter que si l'homognisation est facile atteindre au niveau d'une application, elle l'est plus difficilement d'une application l'autre et elle ncessite alors une conception globale de la syntaxe du langage d'interaction qui intgre toutes les applications. La conception d'un langage d'interaction ne se rsume pas ces deux critres. L'objectif d'un langage d'interaction est d'tre d'un apprentissage et d'une utilisation faciles pour l'utilisateur. Pour illustrer ces deux notions, nous nous rferons une tude faite par Corson (Cor,82) et portant sur la comparaison de deux langages d'interrogation de base de donnes SQL et QBE. SQL est un langage d'interrogation classique par mots cls et QBE est un langage dit "graphique" o la syntaxe est allge au maximun. Nous donnons un exemple de chacun de ces langages qui traduit la question suivante: "Trouver le nom des employs qui travaillent dans le dpartement 50 ?" s'crit en SQL SELECT NOM
79
FROM EMP WHERE DEPT NO = 50 s'crit en QBE

EMP NAME P.DUPONT DEPTNO 50 SAL
o seule la deuxime ligne est remplie par l'utilisateur. Les tudes valuatives de SQL montrent que, tant en ce qui concerne l'apprentissage que l'utilisation effective du langage, les programmeurs ralisent de meilleures performances que les nonprogrammeurs. Les tudes comparatives entre SQL et QBE dans les mmes conditions d'apprentissage de procdures et de test montrent que QBE: - requiert moins de temps d'apprentissage - ncessite moins de temps pour les tests - permet une plus grande exactitude dans l'tablissement des requtes - provoque un meilleur niveau de confiance. On peut supposer que la supriorit ergonomique de QBE est essentiellement due la structure tabulaire prexistante sur l'cran et qui fournit l'utilisateur une image de la structure de la base de donnes lui vitant ainsi la mmorisation de la structure de cette base. On peut remarquer ainsi que QBE n'utilise que trs peu de mots-cls, ce qui permet d'viter des confusions avec le langage naturel, comme pour les ET/OU de SQL. Pour conclure cette tude de l'interrogation des bases de donnes, nous devons noter que les difficults d'apprentissage et d'utilisation ne sont pas dues qu' des problmes de prsentation et de langage d'interaction. Les difficults peuvent tre lies la comprhension de la question en langage naturel ou au problme de la transposition par rapport une structure de donnes prdfinie. On remarque aussi un certains nombre d'erreurs lies l'utilisation du ET/OU logique qui n'a pas la mme signification que le et/ou du langage naturel et aussi une difficult employer des quantificateurs (25% des erreurs des utilisateurs dans QBE). Ainsi, sans rduire le problme de l'interrogation des bases de donnes celle du choix du langage d'interaction et de prsentation, nous voyons que celui-ci a une importance non ngligeable sur la facilit d'apprentissage et la minimisation des erreurs.
80
3.2.2.3 Les dispositifs d'entre Un des rles essentiels des dispositifs d'entre part la saisie proprement dite est de permettre la distinction entre commandes et donnes du point de vue de l'informaticien. La saisie des donnes en informatique des organisations ne pose pas de problmes particuliers car elle se fait obligatoirement par l'intermdiaire des touches alphanumriques du clavier. L'entre vocale et la dsignation directe sur cran sont fort peu utilises et utiles. La saisie des commandes offre une plus grande varit: - frappe au clavier du mot entier ou abrg dsignant la commande - frappe de touches spcialises ou touches fonctions - frappe d'une association de touches, en gnral une touche spcialise en mme temps qu'une touche banalise - dsignation par positionnement du curseur et validation, soit par les touches directionnelles du clavier, soit par la souris - dsignation directe sur l'cran par l'intermdiaire d'un light pen ou du doigt Ces diffrents modes de saisie ne sont pas quivalents du point de vue de l'utilisateur. Les deux derniers cits sont les moins coteux sur le plan de la mmorisation; ce peut tre le cas aussi de la saisie des premiers caractres de la commande si celle-ci est visualise sur l'cran. Ces modes de saisie sont donc prconiser dans le cas d'utilisateurs novices ou intermittents. Par contre les touches spcialises peuvent s'avrer trs efficace pour des personnes utilisant intensivement le logiciel et habitues l'usage du clavier. L'association de touches, trs utilise par les informaticiens, est le dispositif d'entre le plus complexe pour l'utilisateur; il est difficile mmoriser et manipuler et entrane ainsi de frquentes erreurs.
3.2.2.4 Les dispositifs de prsentation Le travail interactif avec l'ordinateur se droulant principalement devant un cran, il nous a sembl important de savoir si l'utilisateur avait des stratgies d'exploration d'cran qui nous permettraient de concevoir des prsentations adaptes.
81
Nous nous sommes rendus compte qu'il faut distinguer deux catgories de cas, selon que l'utilisateur explore l'ensemble de l'cran pour dcouvrir ce qu'il cherche ou qu'il recherche de manire slective une information qu'il pense tre une certaine place. Nous parlerons dans le premier cas de "recherche systmatique" et dans le second cas de "recherche slective". Recherche systmatique Pour ce type d'exploration d'cran, nous nous rfrons une exprience faite par Sperandio et Gonju (Spe,83) qui porte sur l'exploration visuelle de tableaux numriques o l'oprateur cherche un nombre donn sans connatre sa localisation. La premire constatation que l'on peut faire est que, dans les pays occidentaux, la lecture d'un texte apparaissant sur un support quelconque s'effectue a priori dans le sens gauche/droite et haut/bas. Dans le cas des tableaux, l'exprience montre que la stratgie d'exploration est au dpart une stratgie par ligne (gauche/droite) et volue ensuite par colonne (haut/bas) l'inverse. On note galement une diminution progressive des dures de fixation et, corrlativement, une diminution du nombre de fixations. La stratgie d'exploration par colonne est adopte car elle est la plus conomique en ce sens qu'elle permet plus facilement une fixation sur le premier chiffre du nombre. Cette exprience tend montrer que ce que l'utilisateur voit le mieux est ce qui est situ dans le coin suprieur gauche ou dans la zone centrale. Par contre les nombres situs en extrmit de ligne ou de colonne ont une moins grande probabilit d'tre perus avec prcision, d'autant plus que les crans bombs distordent plus ou moins l'image sur les bords. Avant de conclure sur la recherche systmatique, nous voudrions relativiser les rsultats prcdents par le fait que les expriences portent exclusivement sur des tableaux de chiffres. D'autres tudes menes par des publicitaires ont montr que dans le cas d'une exploration rapide d'un support et d'une information quelconque, la stratgie d'exploration de l'usager fait un "z" : c'est dire que l'oeil part du coin suprieur gauche, balaye une ligne de gauche droite traverse l'image en diagonale du coin suprieur droit vers le coin infrieur gauche et balaye la dernire ligne de gauche droite. Ce rsultat n'a de sens que pour des utilisateurs qui ne connaissent pas la structure de l'information qu'ils vont
82
rencontrer sur l'cran et qui ont par contre des contraintes de temps. Ces rsultats ne sont pas parfaitement concordants puisqu'ils ne portent pas sur le mme protocole d'expriences, mais ils ont en commun trois lments : - l'exploration commence par le coin suprieur gauche - la zone centrale est parcourue systmatiquement (en partant du coin suprieur gauche ou droit) - l'extrmit gauche ou droite des images est mal vue. Nous pouvons dduire de ces lments que pour des utilisateurs novices ou occasionnels de l'informatique, les informations importantes (qui doivent tre ncessairement lues) doivent commencer dans le coin suprieur gauche ou se situer dans la zone centrale. Recherche slective Lorsque l'cran affiche une structure de l'information qui est connue de l'utilisateur et que celui-ci peroit cette information dans un certain but, la recherche de l'information est slective et non plus systmatique; autrement dit, la saisie de l'information est gouverne par les processus cognitifs . De manire plus prcise, la saisie visuelle dpend moins des caractristiques physiques du stimulus (intensit, taille, localisation, formes) que des stratgies opratoires de l'utilisateur, qui sont dtermines par les caractristiques de la tche et le degr d'exprience des utilisateurs. Nous illustrons ces ides par une tude faite par Bouju et Sperandio (Bou,79) et portant sur les contrleurs ariens. L'objectif de cette tude tait de voir si il y avait des diffrences de stratgie d'exploration visuelle selon le degr d'exprience des contrleurs et selon l'augmentation du trafic arien. En rgle gnrale, quand le trafic augmente on observe une prise d'information plus slective, c'est--dire centre sur les informations juges pertinentes par les contrleurs pour leur dcision; les informations juges pertinentes diffrent selon le degr d'exprience des utilisateurs. Ce phnomne s'accompagne d'une augmentation de la dure moyenne de fixation sur les lments pertinents. Dans tous les cas, on n'observe pas une exploration systmatique des informations, mais une fixation slective sur les points o le contrleur sait qu'il va trouver l'information pertinente.
83
Quand le volume du trafic augmente, le contleur expriment choisit un mode de rgulation plus standardis, c'est--dire plus conomique pour lui. Si on veut transposer ces rsultats dans le cadre de l'informatique des organisations, on peut dire que l'utilisateur expriment ne va pas explorer l'ensemble de l'cran, mais uniquement les points qui lui semblent pertinents et qui pourraient ainsi tre regroups dans les zones observes le plus spontanment. On remarque ainsi qu'en cas de surcharge de travail, l'utilisateur s'achemine vers une standardisation des procdures d'exploration. On facilitera le travail de l'utilisateur si, d'une application l'autre, on lui fournit les informations de mme nature dans les mmes zones (standardisation des emplacements des zones de menus, messages d'erreurs, etc....). Le concept d'homognit permettant d'acqurir des automatismes qui acclrent la prise d'information, prime sur celui d'emplacement; peu importe que la barre de menu soit sur la ligne du haut ou du bas pourvu qu'elle soit toujours la mme place dans toutes les applications. Les prsentations sur cran Nous prsentons maintenant les diffrences de recommandations entre prsentation des donnes et prsentation des commandes. La prsentation des donnes peut se faire de deux manires diffrentes: par question/rponse ou par remplissage de formes. Le mode question/rponse ne donne aucune latitude l'utilisateur, il ne doit donc tre utilis que dans le cas o le guidage total par l'ordinateur s'impose. Le remplissage de formes est plus souple car il peut permettre l'utilisateur d'entrer les donnes dans un ordre diffrent de celui propos (ce qui est trs intressant dans le cas d'un dialogue avec un client) mais aussi d'imposer un ordre dans le cas de saisie de formulaires. Dans ce cas (saisie de formulaires), il est impratif que l'ordre de prsentation des donnes soit le mme que celui du formulaire. La prsentation des commandes peut ne pas exister dans le cas d'utilisation d'un langage de commande; cette absence de prsentation ne peut convenir qu' un public trs spcialis utilisant frquemment ces logiciels.
84
Dans le cas usuel la prsentation des commandes se fait sous forme d'un menu qui peut prsenter les variabilits suivantes: - visualisation uniquement la demande (touche "aide") - barre de menu affiche en permanence - menu droulant dont seul l'en-tte est visualise, le reste apparaissant la demande - menu glissant qui permet de visualiser une liste de commandes plus grande que la place disponible - menu dynamique qui signale l'utilisateur les commandes disponibles un moment donn de l'interaction (au moyen d'une surbrillance par exemple) L'ensemble de ces prsentations par menu demande peu de mmorisation de la part des utilisateurs et est donc particulirement adapt tous les utilisateurs novices et intermittents. Selon les types de logiciel de gestion d'cran (voir chaptre 4), la prsentation des donnes et des commandes peut se faire sous la forme de monofentre ou de multifentre ; la prsentation monofentre est la plus rpandue car la plus ancienne, mais la prsentation multifentre est en plein dveloppement. L'avantage essentiel de cette dernire est de permettre la visualisation de plusieurs oprations simultanment, ce qui est d'une utilit certaine pour l'utilisateur dans le cas d'interruption et de transfert d'informations entre oprations. On peut mme dire que ces deux types d'oprations ne sont de fait praticables qu'avec le multifentrage. Le dcoupage de l'cran en fentres et le recouvrement partiel ou total peut tre gr automatiquement par le logiciel ou tre laiss l'initiative de l'utilisateur; il n'y a pas de recommandations ergonomiques ce sujet car cela dpend du type d'application et du type d'utilisateur. Ici aussi, une exprimentation sur prototype peut s'avrer utile. 3.2.2.5 Le temps de rponse La question qui se pose est la suivante : "Quel est le temps de rponse idal?" - immdiat, rpondent Sperandio et Volleau (Spe,80) ; - pas trop rapide, dit Wisner (Wis, 79), car cela cre une surcharge mentale par acclration des processus cognitifs. Pour tenter de rpondre plus prcisment, nous pouvons nous rfrer deux paramtres importants :
85
- dans une conversation entre deux personnes, le temps de rponse maximun est de l'ordre de deux secondes (tant bien entendu que la rponse peut tre verbale ou reprsente par un geste, un mouvement facial ou autre). D'aprs les observations menes, deux secondes semble bien correspondre un seuil au-del duquel l'individu a l'impression d'attendre ; - par ailleurs, nous avons vu que les informations qui entrent ou qui sortent du cerveau humain transitent par une mmoire court terme pendant 2 6 secondes au maximun. En consquence, si, en cours de travail, nous sommes interrompus par un vnement extrieur, nous risquons d'effacer l'information de la mmoire court terme. En rsum, il est gnant d'tre interrompu pendant la phase de mmorisation et il est pnible de devoir conserver trop longtemps l'information dans la mmoire court terme, ce qui est le cas si le temps de rponse est suprieur 4 secondes. Par contre, un temps de rponse plus long pour une opration qui ne demande pas de mmorisation (l'impression, fin de travail), ne pose pas de problme condition toutefois que l'utilisateur soit averti par un message affich sur l'cran. Si le temps de rponse est vraiment trop long, il faut afficher ce temps pour que l'utilisateur puisse faire ventuellement autre chose en attendant. Sinon, cela peut provoquer de l'anxit car il n'est pas en mesure de savoir si ce temps d'attente provient de contraintes techniques ou d'une erreur de sa part. Toujours pour la mme raison d'anxit, il faut viter les temps de rponse trop variables. Nous arrivons donc aux rsultats suivants: - moins de 2 secondes : temps de rponse idal ; - 2 4 secondes : impression d'attente, peu gnante pour la mmoire court terme, - plus de 4 secondes : trop long si le dialogue ncessite une mmorisation court terme et s'il n'y a pas de messages affichs l'cran.
3.2.2.6 Le traitement des erreurs On distingue deux types d'erreur:
86
- les erreurs d'excution qui proviennent du fait que l'on a tap par inadvertance sur une autre touche que celle dsire; ce type d'erreur est souvent facilement dtectable et rectifiable; - les erreurs d'intention qui correspondent une mauvaise interprtation du sens des commandes ou de la signification des procdures; ces erreurs peuvent n'tre dtectes que tardivement et leurs rectifications demandent un apprentissage de la part de l'utilisateur. Pour le signalement des erreurs, il y a unanimit sur les lments suivants: - les erreurs doivent tre signales immdiatement ou le plus rapidement possible cause de la "volatilit" de la mmoire court terme, - les messages d'erreur doivent tre explicites et dcrire, possible, la cause de l'erreur, si
- les messages d'erreur doivent tre prsents toujours sous la mme forme pour des raisons d'homognit et donc d'optimisation de la recherche slective. Par contre, il y a plusieurs possibilits pour l'emplacement proprement dit du message d'erreur : - ct de l'erreur, on est sr que l'utilisateur verra le message mais il peut ne pas y avoir assez de place, sauf si l'on utilise une fentre en surimpression (logiciel de multifentrage) - dans une zone spciale on peut ne pas remarquer le message d'erreur, ce qui peut amener rajouter des marques spciales comme un clignotement du curseur ou de la zone, un signal sonore, une inversion vido... Pour la correction des erreurs, l'utilisateur doit pouvoir revenir aisment l'opration ou la ligne o se situe l'erreur et il doit pouvoir annuler ventuellement en totalit ou en partie le travail qu'il a fait depuis lors. Les possibilits de correction d'erreur posent des problmes souvent complexes en informatique; ce ne sont pas des paramtres de surface du logiciel, mais des paramtres de la structure profonde que l'on dfinit lors de la Reprsentation Conceptuelle, en particulier quand on dfinit le squencement des oprations.
87
3.2.2.7 Le guidage Selon Senach (Sen,87), il y a essentiellement deux types de guidage: - le guidage fonctionnel par description des commandes; ce guidage fournit pour chaque commande sa dfinition et ses effets, ses conditions d'excution, ses effets de bord ventuels; ces descriptions peuvent tre faites trois niveaux de dtails (rsum, dtaill, catalogue de problmes) - le guidage d'utilisation par reconnaissance des plans d'action de l'utilisateur; ce guidage suppose une mtaconnaissance sur les diffrents buts possibles de l'utilisateur, une gestion du contexte de l'interaction (historique des transactions), une gestion du contexte de l'utilisateur (procdures adaptes un utilisateur donn) Le guidage fonctionnel est adapt des utilisateurs expriments qui veulent se rappeler la syntaxe et la smantique d'une commande. Le guidage d'utilisation convient mieux des utilisateurs novices ou intermittents car il peut les guider dans la ralisation de leur tche en leur indiquant l'ensemble des oprations parcourir en fonction du but qu'ils veulent atteindre.
3.3 La Reprsentation Externe

Nous avons vu que la Reprsentation Conceptuelle est constitue de deux ensembles de paramtres que nous avons appels : - les paramtres constants, - les paramtres variables propres une application particulire. Ces deux ensembles ne sont pas du tout de mme nature. Les paramtres constants sont mettre en oeuvre pour faciliter le travail de l'utilisateur quel que soit le type de tches qu'il a accomplir ce qui ncessiste donc la conception d'outils gnraux. Les paramtres variables sont des lments (traitement et donnes) issus de l'analyse du travail, spcifiques chaque application. A cause de cette diffrence, nous examinerons sparement la traduction de ces paramtres en R.E.
88
Donnes
1 - RE directement dduite de la RC 2 - RE vue de l'utilisateur
2 Paramtres constants
Traitements
La dfinition des paramtres constants est totalement indpendante de celle des paramtres variables, mais l'interface rsultante "vue" par l'utilisateur (R.E) sera la conjonction de ces deux ensembles d'lments.
3.3.1 Les paramtres Reprsentation Externe
standard
de
la
Dans ce paragraphe, nous dcrivons tous les lments qui ne sont pas lis une application particulire; il s'agit, d'une part de la traduction des paramtres constants provenant de la Reprsentation Conceptuelle, d'autre part des options standard qui doivent tre prises pour homogniser toutes les applications. 3.3.1.1 Traduction des paramtres constants Nous avons dfini trois types de paramtres constants qui sont ceux : - d'aide au travail - d'aide l'apprentissage - d'volution. Pour l'aide au travail, nous avons dfini les lments suivants : - les possibilits d'interrompre tout moment une tche pour aller en excuter une autre - les possibilits de quitter le travail n'importe quel moment - les possibilits de diffrer le travail en cours - la possibilit de transfrer les donnes d'une tche l'autre. - l'annulation pour la gestion des erreurs
89
- la mmorisation de l'activit de l'utilisateur (gestion du contexte) qui comprend quatre aspects (oprations interrompues, oprations diffres, traces du travail, paramtres propres l'utilisateur). L'aide l'apprentissage concerne le guidage fonctionnel et le guidage d'utilisation. Les possibilits d'volution concernent les lments de la reprsentation conceptuelle que l'utilisateur peut modifier luimme. Ces paramtres sont qualifis de constants en ce sens qu'ils sont utiles quelle que soit l'application traite. Aussi, serait-il logique qu'ils soient intgrs dans un logiciel de base sur lequel on pourrait greffer les lments propres une application particulire. C'est ce qui est fait, partiellement, avec les logiciels de multifentrage que nous dcrivons au chapitre 4. Ils grent automatiquement l'interruption et le transfert de donnes entre oprations, les autres paramtres devant tre programms. Nous pouvons constater que ces paramtres constants permettent de prendre en compte les recommandations ergonomiques concernant le squencement des oprations, le guidage et partiellement la correction d'erreurs. La question que nous devons rsoudre ici est la suivante: "Comment prsenter ces possibilits l'utilisateur au niveau de l'interface?" La rgle qui s'impose en priorit est celle de l'homognit ; ces paramtres tant communs toutes les appplications doivent tre prsents exactement de la mme faon quelle que soit l'application, c'est--dire qu'ils doivent: - recevoir la mme dnomination - tre prsents visuellement sur l'cran de la mme manire - tre slectionns avec le mme dispositif d'entre. Nous dtaillons ci-dessous les critres que l'on peut mettre en oeuvre pour traduire les paramtres constants dans une Reprsentation Externe adapte aux utilisateurs. A titre d'illustration, nous prsentons deux possibilits selon que l'on dispose d'un logiciel de gestion d'cran mono ou multifentre. Subdivision des commandes Dans le cas o nous mettons en oeuvre l'ensemble des possibilits numres prcdemment ou, du moins, une partie importante
90
d'entre elles, il est ncessaire de procder un regroupement en sous-ensembles afin de ne pas surcharger l'cran. Le critre de regroupement essentiel est la frquence d'utilisation. A titre d'exemple, l'ensemble des commandes standard est subdivis en quatre sous-ensembles selon leur frquence d'utilisation; cette subdivision est indpendante du type de logiciel de gestion d'cran: - le premier sous-ensemble concerne l'aide l'utilisation avec les commandes Interrompre Diffrer Quitter Annuler Copier Insrer - le second sous-ensemble concerne la mmorisation avec la commande Mmoire un premier niveau et les commandes Interruption Transaction Diffr Utilisateur au second niveau - le troisime sous-ensemble concerne l'aide l'apprentissage avec la commande Guidage au premier niveau et les commandes Buts et Commandes au deuxime niveau - le quatrime sous-ensemble concerne les possibilits d'volution avec la commande Evolution au premier niveau et les commandes Procdure Opration Statut Dclenchement Prcdence au deuxime niveau. Dnomination des commandes Le choix de la dnomination des commandes standard comporte un aspect arbitraire, car on ne peut se rfrer aucun vocabulaire de spcialiste; les commandes standard correspondent des oprations spcifiques de l'interaction homme-machine qui n'ont pas d'quivalent dans le travail manuel. Mais, on peut s'inspirer des principes suivants: - pour liminer l'indtermination syntaxique, il y a lieu de nommer toutes les commandes sous la mme forme syntaxique; on prendra soit la forme verbale soit la forme nominale. La pratique des informaticiens consiste plutt prendre la forme verbale, sans que cette pratique soit confirme ou infirme par des tests d'ergonomie; - la dnomination de la commande doit reflter le point de vue des utilisateurs et non des informaticiens.Par exemple, la mme commande s'appellera "consulter thesaurus" du point de vue de l'utilisateur et "afficher thesaurus" du point de vue de l'informaticien. En cas d'ambigut, il est utile de procder des tests d'apprentissage et de mmorisation. Disposition spatiale La prsentation des commandes standard l'cran est guide par deux critres:
91
- ne pas surcharger l'cran de commandes inutiles ou utilises peu frquemment, - rester au maximum homogne entre toutes les applications
Exemple avec logiciel monofentre: Afin de ne pas surcharger l'cran, nous avons dcid que le menu standard n'utiliserait qu'une ligne ce qui,dans le cas usuel, correspond 80 caractres. Ce choix nous oblige crer deux niveaux de commandes o le premier niveau est affich en permanence dans la ligne menu; le deuxime niveau n'apparaissant qu' la demande. Pour minimiser les manipulations, nous mettons dans le deuxime niveau les commandes utilises plus rarement. Nous aurons donc en permanence la barre de menu suivante:
Interrompre Diffrer Quitter Annuler Copier Insrer Mmoire Guidage Evolution
Nous choisissons de disposer cette barre sur la premire ligne de l'cran; nous aurions pu dcider de la mettre sur la dernire ligne, l'essentiel tant de rester homogne sur l'ensemble des applications. Si l'utilisateur slectionne une des six premires commandes, il y aura excution immdiate alors que les trois dernires commandes donneront lieu l'affichage d'une autre barre de menu au mme emplacement. La commmande Mmoire affichera la barre suivante: Mmoire Mmoire de d'interruption transaction Mmoire Mmoire d'opration du profil diffre d'utilisateur
Exemple avec logiciel de multifentrage:
92
Le multifentrage permet d'utiliser un menu droulant c'est dire un menu qui apparat dans une fentre en surimpression uniquement pendant le temps souhait par l'utilisateur.L'avantage de ce type de menu rside dans le fait que l'on ne fait apparatre que ce qui concerne l'utilisateur et ceci sans surcharger l'cran. Cela suppose une structuration des commandes en deux niveaux; les commandes du premier niveau tant affich en permanence dans une barre de menu; les commandes du second niveau associes chaque commande du premier niveau n'apparaissant qu' la demande dans des menus droulants. Au premier niveau, nous indiquons les quatre sous-ensembles dcrits dans le premier exemple sous la forme d'une barre de menu qui occupe la premire ligne de l'cran, ce qui permet au menu droulant d'apparatre au-dessous de chaque commande; si l'utilisateur slectionne la commande Aide, il obtiendra:
(menu droulant)
Aide Mmoire Interrompre Diffrer Quitter Annuler Copier Insrer
Guidage
Evolution
Et il obtiendrait de la mme manire les commandes de deuxime niveau associes Mmoire Guidage et Evolution.
Slection des commandes Pour slectionner les commandes, on peut utiliser diverses possibilits: - positionner le curseur sur la commande au moyen des touchesfonctions de dplacement (ou d'une souris,...) puis valider par une touche-fonction. Cette possibilit est intressante pour les utilisateurs novices ou intermittents car elle demande peu d'effort de mmorisation; - taper la (ou les) premire lettre de la commande en association avec une autre touche indiquant que l'on est en mode saisie de commande. Ce mode de dsignation est plus complexe mmoriser que le prcdent; mais il peut tre utilis par des non-spcialistes, si les commandes et leurs abrviations sont affiches en entier et en permanence sur l'cran. Dans le cas contraire, il faut le rserver des spcialistes assidus;
93
- utiliser des touches-fonctions associes chaque commande. Cette possibilit est trs efficace pour des utilisateurs expriments.
Exemple: Nous choisissons d'implmenter deux possibilits ; la premire cite pour les utilisateurs novices et la dernire pour les utilisateurs expriments. Pour des utilisateurs novices ou intermittents, la slection la plus simple d'une commande se fait au moyen de la souris (ou de toute autre dsignation directe); quand l'utilisateur positionne avec la souris le curseur sur la commande Aide le menu ci-dessus apparat tant que l'utilisateur appuie sur le bouton de la souris; il ne lui reste plus qu' faire glisser le curseur jusqu' la commande dsire et relacher le bouton de la souris sur cette position pour que cette commande soit slectionne. Cette manoeuvre est en fait plus difficile dcrire par crit qu' excuter physiquement! Pour des utilisateurs plus expriments qui n'ont pas besoin de visualiser le menu droulant, il est plus rapide de taper sur une touche-fonction .
Traitement des erreurs On peut dtecter deux types d'erreur, soit l'utilisateur slectionne une commande qui n'existe pas, soit il slectionne une commande qui existe mais qui ne peut tre active ce moment l (c'est le cas de la commande Copier qui ne peut tre slectionne deux fois de suite sans risque d'ambigut). Dans le premier cas (commande inexistante), on fait apparatre un message d'erreur dans une zone de l'cran spcialise cet effet selon les options dfinies dans l'cran standard (voir paragraphe suivant). Avec le multifentrage, la visualisation des messages d'erreur peut se faire dans une fentre en surimpression ce qui a l'avantage d'tre trs bien peru par l'utilisateur. Dans le second cas, on peut procder de la mme manire mais il est plus efficace d'indiquer galement sur les commandes elle-mmes celles qui sont activables et celles qui ne le sont pas afin de minimiser ce type d'erreur; ceci correspond la notion de menu dynamique, c'est--dire au signalement a priori des commandes possibles un moment donn. Pour prsenter ce menu dynamique, on fait ressortir visuellement (surbrillance, inversion vido,...) les commandes activables un moment donn par rapport aux commandes non activables; on peut galement faire disparaitre de l'cran les commandes non activables, mais cette faon de procder est moins judicieuse car elle ne prserve pas l'homognit de la prsentation.
94
3.3.1.2 Les options standard Disposition spatiale Avant de dcrire une opration et une procdure particulire, il est impratif de dterminer une disposition standard de l'cran qui servira de cadre pour l'ensemble des applications. Les critres de disposition doivent s'inspirer des rsultats d'ergonomie sur la recherche systmatique et slective; nous avons vu qu'un novice va balayer l'cran en "z" , alors qu'un expriment consultera directement la zone qui l'intresse (si l'cran est standard, cette stratgie devient trs efficace). Aussi, on peut en dduire que, si on veut que les zones de menu (dans la mesure o elles existent) soient vues par des utilisateurs novices, il faut les mettre sur la premire ou la dernire ligne de l'cran; cette option ne constitue pas une gne pour les utilisateurs expriments dans la mesure o ils ne consulteront cette zone que s'ils en ont besoin. Un autre critre utiliser est la non surcharge de l'cran; ce critre peut tre en contradiction avec les autres car il peut amener ne pas spcialiser des zones d'cran, de manire librer tout l'cran pour la zone de dialogue dans le cas d'oprations trs forte densit d'informations. Les possibilits de disposition sont bien sr diffrentes selon que nous disposons ou non d'un logiciel de multifentrage; nous examinons titre d'exemple les deux possibilits.
Exemple de disposition standard monofentre : Nous spcialisons quatre zones: - les zones de menu spcifique et standard occupent les deux premires lignes de l'cran - la zone de message d'erreur et de service occupe la dernire ligne - la zone de dialogue utilise dans chaque opration occupe tout le reste de l'cran. Menu standard Menu spcifique
Zone de dialogue
Messages d'erreur ou de service
95
Exemple de disposition standard multifentre : - les zones de menu spcifique et standard n'occupent que la premire ligne de l'cran car l'utilisation de menu droulant permet de regrouper plus fortement les commandes sans gne pour l'utilisateur - la zone de message d'erreur et de service n'existe pas en permanence; elle sera dite dans une fentre en surimpression qui ne sera affiche qu'en cas de message - la zone de dialogue occupe le reste de l'cran. Menu standard et spcifique Zone de dialogue Fentre Messages d'erreur (s'il y a lieu) Menu droulant ( la demande)
Syntaxe Une partie de la syntaxe du langage d'interrogation a un caractre gnral et doit donc tre dtermin ce niveau de manire tre homogne sur l'ensemble des applications. Il s'agit: - du mode de slection des commandes (standard ou spcifiques) - de la validation des donnes ou des crans. Messages de service Le contenu des messages de service est dpendant du contenu d'une application particulire mais il existe un message de service caractre gnral, c'est celui concernant le temps de rponse. En effet, le temps de rponse n'est pas connu ce stade de la conception puisqu'il dpend de la Reprsentation Interne de l'application, mais nous avons vu qu'au-del de 2 secondes l'utilisateur a l'impression d'attendre et qu'au del de 4 secondes, il est indispensable de lui signaler par un message que la procdure se droule normalement. Le contenu et la forme du ou des messages concernant le temps de rponse doivent tre dtermins ce stade car ils sont indpendants du contenu de l'application.
96
3.3.2 Les paramtres de la Reprsentation Externe spcifiques l'application

Quand l'tape de la Reprsentation Conceptuelle est finie, nous disposons, pour chaque but d'un poste de travail, de spcifications comples concernant la structure de donnes et la structure de traitement des oprations de la procdure. Pour chaque opration interactive, nous connaissons: - la liste de ses actions - la liste de ses entres - la liste de ses sorties - ses pr-requis - son dclenchement Pour chaque procdure, nous avons: - la liste des oprations activables - les prcdences entre ces oprations. Au niveau de la Reprsentation Externe, il nous reste dfinir pour chaque opration interactive: - la disposition du ou des crans - le vocabulaire des donnes - le contenu des messages d'erreur, de service ou de guidage - la syntaxe - les dispositifs d'entre. Pour l'ensemble de la procdure, nous devons dfinir: - les noms des commandes activant les oprations - la hirarchie du menu - la prsentation du menu - la syntaxe et les dispositifs d'entre - les messages d'erreur et de guidage. Nous illustrons cette dmarche sur un exemple qui reprend celui de la documentation dvelopp dans le chapitre deux. Nous dcrivons l'opration "enregistrement des bases du document" et la procdure minimale d'un poste de documentation. 3.3.2.1 Reprsentation Externe des oprations Vocabulaire Pour la dtermination du vocabulaire des donnes, il n'existe qu'un seul critre qui est celui d'utiliser le vocabulaire des spcialistes de la tche (ou le vocabulaire courant pour les applications "grand public").
97
Dans les cas (rares) o il y a cration de donnes qui n'existent pas dans les tches actuelles, il est ncessaire de procder des tests d'apprentissage et de mmorisation pour ces nouveaux noms.
Exemple: Pour dcrire les donnes qui permettent au documentaliste d'enregistrer un document nous choisissons le vocabulaire dj utilis par le documentaliste qui est: COTE, AUTEUR, TITRE, EDITEUR, ANNEE, NOMBRE DE PAGES, LANGUE.
Syntaxe L'indication de fin de saisie de donnes doit tre faite par le mme moyen sur l'ensemble de l'application. Le mme principe doit tre appliqu pour la validation de l'ensemble de l'cran. Disposition spatiale Si l'opration correspond un document sur papier ou un cran existant dj, il faut ,dans la mesure o ces documents ou ces crans sont adapts aux ncessits de la tche, s'en inspirer fortement compte-tenu des nouvelles contraintes techniques. Dans les autres cas, il faut rechercher la ou les logiques d'utilisation de cette opration de manire prsenter les donnes dans l'ordre de la logique d'utilisation la plus courante en prvoyant ventuellement des possibilits de variantes dans l'ordre de remplissage, par exemple, s'il y a lieu.
Exemple: Nous reproduisons sur l'cran l'ordre et la disposition spatiale contenu dans une fiche documentation manuelle car les documentalistes y sont habitus et surtout parce que les systmes manuels et automatiques vont continuer coexister, ce qui donne: Zone de dialogue Cote Titre Auteur(s) Editeur Nombre de pages Langue Anne
98
Dispositif d'entre Pour une opration, le dispositif d'entre concerne la saisie des donnes et l'enchanement des diffrentes zones de saisie. Les donnes peuvent tre saisies au clavier, ou slectionns sur une liste affiche par le logiciel, ou en provenance d'une autre opration. Le premier cas ne pose pas de problme; dans les deux autres cas, il faut veiller au fait que les modes de dsignation soient homognes sur l'ensemble de l'application. Le mode d'enchanement des zones de saisie est dtermin dans la Reprsentation Conceptuelle; s'il est l'initiative de l'ordinateur , cela se traduit par un positionnement automatique du curseur; s'il est l'initiative de l'utilisateur, il faut prvoir un mode de dsignation d'une zone par l'utilisateur. Le plus simple et le plus efficace est la dsignation directe (souris, light pen,...) ou la rigueur les touches-fonction de dplacement de curseur.
Exemple: Les zones sont enchaines automatiquement car cet ordre correspond aux habitudes des documentalistes et tous les renseignements sont groups sur un mme document. Le choix des touches-fonctions pour la syntaxe est motiv par le fait qu'il y a beaucoup de saisie au clavier et que les documentalistes sont trs habitus utiliser un clavier.
Messages d'erreur Nous devons dterminer l'ensemble des erreurs que l'utilisateur peut commettre et surtout que le logiciel peut dtecter afin de prvoir les messages d'erreurs correspondants. Chaque message d'erreur doit tre le plus explicite possible et indiquer le type de contrle qui est effectu.
Exemple: Sur la "Cote" il peut y avoir deux types d'erreur: - une erreur de vraisemblance si l'utilisateur tape une cote incompatible avec la composition prvue (deux lettres suivies au maximum de six chiffres) auquel cas le message sera "mauvaise composition de la cote"; - une erreur de concordance si la cote correspond une cote existant dj ce qui est impossible puisque cette opration a pour but de permettre l'enregistrement de nouveaux livres; le message d'erreur tant "cote dj attribue". Sur l' "Anne" il peut y avoir un contrle de vraisemblance sur une fourchette minimum/maximum avec le message "erreur sur la date". Sur l' "Auteur" il ne peut pas y avoir de vrifications. Sur l' "Editeur", il y a contrle de concordance avecune liste d'diteur et le message est donc "diteur non enregistr". Sur le "Nombre de pages", il y a un contrle de vraisemblance sur les chiffres avec en rponse le message "le nombre de pages doit tre numrique". Sur la "Langue", il y a un contrle de concordance par rapport une liste de langues avec le message "langue non enregistre".
99
3.3.2.2 Reprsentation Externe des procdures Vocabulaire Nous devons dterminer l'ensemble des noms de commande correspondant chaque opration. L aussi, il faut au maximum adopter le vocabulaire employ par les spcialistes de la tche, mais ce n'est pas toujours possible quand des oprations automatises ne correspondent pas des oprations manuelles. Dans ce cas, on s'inspirera des deux principes dvelopps pour la dnominations des commandes standard (forme verbale ou nominale, dnomination du point de vue de l'utilisateur); en cas d'ambigut on procdera une exprimentation.
Exemple: Nous donnons ci-dessous la liste des diffrentes oprations de la procdure minimale d'un poste de documentation et la liste correspondante des noms de commande. Liste des oprations de la procdure Enregistrer les bases du document Crer termes du thesaurus Crer liens entre termes Consulter thesaurus Rechercher documents Imprimer thesaurus Enregistrer mots-cls Liste correspondante des commandes Indexer (vocabulaire du spcialiste) Crer mots-cls Lier mots-cls Consulter thesaurus Chercher document Imprimer -
L'opration "Enregistrement mots-cls du document" n'a pas de nom de commande correspondant car elle correspond un dclenchement automatique dans la procdure minimale et ne peut donc tre dclenche par l'utilisateur.
Hirarchie du menu Dans le cas gnral, l'ensemble des commandes d'une application interactive est trop important pour pouvoir tre prsent l'utilisateur sous la forme d'une liste unique. Aussi, on subdivise l'ensemble des commandes de manire obtenir une stucture arborescente ou hirarchise; l'utilisateur doit alors parcourir cette arborescence pour activer les commandes utiles son travail. Cette structure hirarchique du menu ne doit en aucun cas tre faite par rapport la logique des traitements informatiques mais par rapport la logique d'utilisation des utilisateurs. Cette logique d'utilisation a t dtermin au niveau de la Reprsentation Conceptuelle quand on dcompose le travail effectuer en buts, sous-buts,..., oprations.
100
C'est cette structuration qui doit tre reprise ici; les buts correspondent au niveau un de la structure arborescente, les sousbuts au niveau deux et les oprations au dernier niveau.
Exemple: Comme nous l'avons vu au chapitre 2, la suite d'une tude sur la logique d'utilisation des documentalistes, on a constat que le but de la procdure qui est de grer les documents se subdivise en deux sous-buts: "enregistrer document" et "consulter document". Les commandes ci-dessus sont donc regroupes en deux sous-ensembles: - le premier sous-ensemble nomm "Enregistrer" regroupe toutes les commandes permettant d'atteindre ce sous-but, soit Indexer, Crer mots cls, Lier mots cls, Consulter thesaurus. - le second sous-ensemble nomm "Consulter" regroupe Consulter thesaurus, Chercher document, Imprimer. Comme nous l'avons dj remarqu, dans ce dcoupage en logique d'utilisation, certaines commandes (ici, consulter thesaurus) peuvent apparatre dans plusieurs sous-menus puisque l'objectif est de minimiser les manipulations de l'utilisateur.
Prsentation du menu Le menu peut tre affich en permanence ou seulement la demande de l'utilisateur; l'affichage permanent est plus favorable aux utilisateurs novices ou intermittents alors que l'affichage la demande, s'il est utilis, doit tre rserv aux utilisateurs expriments. Dans le cas d'affichage permanent, la ligne o est affiche le menu a un contenu volutif selon la demande de l'utilisateur; au premier niveau, elle contient la liste des buts et au dernier niveau, la liste des oprations. Avec un logiciel de multifentrage, on peut avoir une variante qui consiste mettre la liste des oprations dans un menu droulant.
Exemple avec logiciel monofentre: Dans la barre de menu initiale (au premier niveau), on affiche les sous-buts: Enregistrer et Consulter. Quand l'utilisateur slectionne un but, la barre de menu initiale est remplace par l'ensemble des commandes dpendantes de ce but; par exemple, si l'utilisateur slectionne "Enregistrer", on affiche: Indexer, Crer mots-cls, Lier mots-cls, Consulter thesaurus. L'utilisateur dispose ainsi de l'ensemble des commandes lui permettant de raliser un enregistrement sans avoir revenir au premier niveau . Exemple avec logiciel de multifentrage: La barre de menu initiale (contenant les buts) reste affiche en permanence et la liste des oprations dpendante d'un but apparat la demande de l'utilisateur dans un menu droulant comme nous l'indiquons dans le schma suivant:
101
Enregistrer Indexer Crer mots-cls Lier mots-cls Consulter thesaurus
Consulter
Dispositif d'entre Comme pour la slection des commandes standard, on peut utiliser le clavier avec la touche "mode commande" et la frappe d'une abrviation de la commande dsire ou la souris en positionnant le curseur sur la commande et en cliquant ou une touche-fonction.
Exemple: On rserve les touches fonctions aux commandes standard. Pour les commandes spcifiques l'application, on offre deux types de mode de slection laiss au choix de l'utilisateur; la dsignation directe par la souris et la combinaison d'une touche commande et d'une abrviation de la commande.
Messages d'erreur Comme pour le menu standard, nous avons deux types d'erreur: - l'erreur de concordance, si la lettre tape ne correspond pas une commande; il est important de remarquer qu'il ne peut pas y avoir d'erreur si la slection se fait par cliquage de la souris. - l'erreur d'utilisation si l'utilisateur veut activer une commande existante mais non activable ce stade de la transaction.
Exemple: Pour l'erreur de concordance, le message sera "commande inconnu, veuillez la retaper". Le problme de l'erreur d'utilisation ne se pose pas dans cet exemple car, dans la procdure minimale du poste de documentation, il n'y a qu'une prcdence qui est dclenchement automatique. Par contre le cas pourrait se poser dans une autre procdure effective.
Guidage Il est important ici de prvoir le contenu des messages qui serviront de guide l'utilisateur. Pour le guidage fonctionnel, on fournira pour chaque commande, un rsum dcrivant le rle et les effets de cette commande, ventuellement illustr par un exemple; on peut ensuite rajouter un
102
niveau d'explication plus dtaill avec une liste exhaustive de tous les problmes que l'on peut rencontrer pour excuter cette commande. Pour le guidage d'utilisation, il faut exploiter la structuration en buts et sous-buts de la Reprsentation Conceptuelle puisqu'elle correspond une logique d'utilisation selon les buts de l'utilisateur et qu'elle permet donc de rpondre des questions du type "comment faire pour...?". De plus, ce guidage d'utilisation peut tre personnalis en utilisant une procdure effective propre un utilisateur ainsi que la mmorisation des transactions dj effectues. Synthse de la Reprsentation Externe La Reprsentation Externe telle qu'elle sera vue par l'utilisateur est une composition des paramtres standard et des paramtres variables de l'application puisqu' chaque moment d'une transaction, plusieurs options sont offertes l'utilisateur; ces options provenant la fois des commandes standard et des commandes spcifiques l'application. Pour illustrer ce fait, nous prsentons ci-dessous un exemple d'cran utilisant un logiciel de multifentrage avec interruption d'opration. L'opration "Indexer" a t interrompue (paramtre standard) de manire implicite par l'activation de l'opration "Consulter thesaurus" car le documentaliste voulait connatre les mots-cls relis par une relation de hirarchie au mot-cl "informatique" afin de mener bien son opration d'indexation de document.
103
DOCUMENTATION
Options standard Enregistrer Consulter
Indexer
Cote Titre X235L Anne 1988
Histoire de l'informatique Epistmologie Mot-cl Langages Cyberntique Consulter thesaurus Type de lien Hirarchie Synonymie Homonymie Voisinage Quitter
Mots-cls Informatique Rseaux
Informatique
Mots lis Informatique de gestion Langages Analyse Programmation Rseaux de Petri
104
Chapitre 4 : STRUCTURE INTERNE DES LOGICIELS INTERACTIFS

Nous prsentons dans ce chapitre la conception et la mise en oeuvre de la Reprsentation Interne de l'application interactive qui d'une part reprsente le point de vue du programmeur sur cette application, d'autre part est la traduction de la Reprsentation Conceptuelle et de la Reprsentation Externe. Les possibilits de mise en oeuvre sont trs diffrentes selon le type de logiciel de gestion d'cran dont on dispose. On distingue les logiciels de gestion d'cran classiques grant une seule fentre des logiciels plus labors permettant entre autre de grer plusieurs fentres et que nous appelerons dans la suite de ce chapitre des systmes de Gestion Multifentre ou SGM. Nous ne dtaillons pas ici les caractristiques de logiciels de gestion d'cran classiques car ils sont bien connus des informaticiens. Nous dirons simplement qu'il en existe deux types; les plus lmentaires permettent uniquement de dfinir les sorties sur cran ligne aprs ligne alors que les plus volus permettent de dfinir globalement un cran de manire interactive. Par contre dans un premier paragraphe, nous prsentons de manire dtaille les SGM (Weg,83) car ils sont encore peu utiliss alors qu'ils prsentent des fonctionnalits trs intressantes pour la mise en oeuvre d'une Reprsentation Externe adapte l'utilisateur. Dans le deuxime paragraphe, nous montrons comment mettre en oeuvre les Reprsentations Conceptuelle et Externe au niveau de la programmation.
4.1 Prsentation des systmes de gestion d'cran multifentre

La fonction principale d'un SGM est de permettre l'accs en parallle diffrentes applications et de leur donner la possibilit d'changer des informations. Pour permettre ces accs parallles,
105
l'cran est divis en fentres et chaque fentre est associe une application. Le SGM. est responsable de la gestion de l'cran et des diffrents priphriques d'entre du systme (clavier, souris, ...). L'intrt d'un tel SGM. est de fournir au programmeur d'application un ensemble de primitives qui lui permettront d'intgrer dans les applications une gestion trs volue des priphriques d'entre/sortie sans qu'il ait besoin de programmer ses fonctionnalits chaque fois. Le gain pour le programmeur peut tre compar au passage des systmes de gestion de fichiers aux Systmes de Gestion de Bases de Donnes. Dans le cadre d'une application btie sur un systme de gestion de fichiers le programmeur intgre la gestion des liens entre fichiers pour chaque application particulire alors qu'il en est dcharg avec un Systme de gestion de Base de Donnes. De la mme manire, un SGM.lui permet de se dcharger des problmes d'interruption et transfert de donnes entre applications. Un SGM prsente galement un intrt pour l'utilisateur car il lui apporte une grande souplesse dans la gestion du dialogue. Nous prsentons tout d'abord le SGM du point de vue de l'utilisateur, puis du point de vue du programmeur et, en dernier lieu, l'exemple d'un SGM particulier.
4.1.1 Les fonctionnalits d'un SGM vues par l'utilisateur

4.1.1.1 Liste des fonctions Les fonctions principales d'un SGM. sont de permettre l'accs en parallle diffrentes applications et la communication entre applications. La communication entre applications prsente deux aspects : - dmarrage et arrt des applications; il doit tre possible d'activer de nouvelles applications partir de celles dj actives, sans qu'il soit ncessaire de dsactiver les premires (interruption et reprise). Par exemple, l'utilisateur doit pouvoir visualiser les informations du fichier Clients alors qu'il fait une cration. - change d'informations entre applications actives. Par exemple, l'utilisateur peut changer une information du fichier Clients au document Facture.
106
En s'appuyant sur ces deux fonctionnalits (accs parallle, communication), le SGM permet galement d'effectuer la gestion des menus, des dsignations, de l'cho, des erreurs, du signal et de l'aide l'utilisation. La gestion des menus le menu (ensemble de commandes) autoris un moment donn de l'activit peut apparatre dans une fentre spciale. Il peut soit tre affich constament l'cran, soit apparatre sur l'cran la demande de l'utilisateur et disparatre ds qu'une commande est choisie. Le menu peut tre modifi interactivement par les activits afin de ne donner que les commandes permises l'utisateur un moment donn (notion de menu dynamique). La gestion des dsignations La dsignation permet l'utilisateur d'identifier un point sur l'cran ; la slection permet d'identifier une entit logique. Une slection peut tre dfinie par une ou plusieurs dsignations; les slections peuvent se faire de deux faons : - soit en dsignant l'information de faon spatiale, par exemple pour supprimer une phrase, on dsigne le dbut et la fin de cette phrase; - soit en utilisant la stucture hirarchique de cette information. Le parcours de cette hirarchie peut se faire de faon ascendante (du mot au document), descendante (du document au mot) ou horizontale (information au mme niveau dans diffrents documents). La gestion de l'cho L'ide est de renvoyer un cho (ou rtroaction) l'utilisateur lui permettant de s'assurer que son action immdiate a bien t prise en compte par l'ordinateur. S'il vient d'activer une commande, l'cho peut tre tout simplement le rsultat de l'opration (si celle-ci peut tre faite immdiatement). On peut galement signaler cette commande par un moyen visuel quelconque (surbrillance, inversion vido...). Il peut tre galement intressant de signaler que l'ordinateur est en train de travailler (en cas de temps de rponse suprieur 2 secondes) ou qu'il est en attente de paramtres de l'utilisateur. Si l'utilisateur vient de slecter un objet, celui-ci peut tre mis en vidence comme pour les commandes (clignotements, inversion vido...). La gestion des erreurs Le systme gre deux fonctions : - le signalement des erreurs soit dans une fentre ddie soit prs d'une zone errone.
107
- les commandes de rectification d'erreurs. On peut trouver des commandes comme : "annuler" pour une excution en cours "arrter" pour arrt temporaire d'excution "reprendre" aprs un arrt temporaire "dfaire" pour se retrouver dans l'tat prcdent l'activation d'une commande. La gestion du signal Elle permet d'indiquer l'utilisateur qu'un venement vient de parvenir l'ordinateur. Par exemple, dans le cas de messages lectroniques, on signalera par une icne l'utilisateur l'arrive d'un document dans une bote aux lettres. L'aide l'utilisateur A tout moment sur demande de l'utilisateur, le systme peut expliquer une commande particulire: - l'ensemble des fonctions accessibles un moment donn - la documentation complte du systme - les causes possibles des erreurs. 4.1.1.2 La mise en oeuvre de ces fonctions Nous entendons par mise en oeuvre les diffrentes manires dont dispose l'utilisateur pour mettre en oeuvre le dmarrage et l'arrt du systme et des activits, les fentres et les commandes Dmarrage et arrt du systme Le systme dispose d'un certain nombre de valeurs par dfaut. L'identifiant au dmarrage de l'utilisateur peut permettre de personnaliser le systme en ce sens qu'il activera les dernires valeurs par dfaut fournies par cet utilisateur. Un autre aspect de la personnalisation consiste conserver le contexte des activits entre deux sessions de travail de manire que l'utilisateur puisse redmarrer dans l'tat o il avait arrt son travail. Gestion des fentres Les fentres sont utilises par les diffrentes activits pour contenir des informations ou des menus. La fentre et l'application tant fortement lies, la mise en oeuvre la plus simple pour l'utilisateur consiste crer automatiquement une fentre ds qu'il active une nouvelle activit et inversement dtruire automatiquement cette fentre lorsque cette activit est considre comme termine (fin de saisie de paramtres ou commande explicite de l'utilisateur).
108
En gnral, cette fentre est constitue de deux parties appeles clture et cadre: - la clture est la partie de la fentre dlimitant l'espace o peut tre affect l'information de l'activit. Si cette information est beaucoup plus grande que l'espace delimit par la clture, on peut avoir une zone de dfilement (ou un "page page") commande par l'utilisateur. - le cadre entoure la clture et permet de distinguer les fentres les unes des autres car il contient des informations permettant d'identifier la fentre et ventuellement des zones pour les commandes du menu. La gestion des fentres implique un partage de l'cran qui peut tre gr de deux manires : - l'utilisateur choisit la taille et la position de ses fentres. Ces diffrentes fentres peuvent se recouvrir partiellement ou totalement. L'inconvnient est que l'utilisateur assure seul la gestion de l'cran; - le systme peut grer compltement le partage de l'cran en optimisant l'occupation de l'cran et en interdisant le recouvrement de fentres. Plus on cre de fentres, plus la taille de chaque fentre diminue (on est de fait limit 4 ou 6 fentres pour des raisons de lisibilit). L'utilisateur peut intervenir sur la grandeur respective des diffrentes fentres. On peut bien sr imaginer des variantes entre ces deux manires extrmes. Par exemple, toute nouvelle fentre est cre automatiquement dans un espace libre (au besoin en diminuant la taille des autres fentres) et l'utilisateur peut ensuite demander un recrouvement partiel ou total, ce qui peut tre utile dans le cas o un travail de fond est excut en parallle avec d'autres activits. Il peut exister des liens hirachiques entre fentres : - lien mre-fille : une opration (fermeture, ouverture, dplacement) sur la fentre mre entrane automatiquement la mme opration sur la fentre fille; - lien frre-soeur : deux fentres sont soeurs si elles sont filles d'une mme fentre. L'utilisateur ne peut travailler que sur une des soeurs la fois (si deux fentres soeurs occupent un mme position dans l'cran, une des deux soeurs recouvre l'autre). Le jeu minimun de commandes de manipulation de fentres est le suivant :
109
- cration de fentre ; cette commande peut tre automatique si elle est active par la cration d'une activit. La taille et la position peuvent tre choisies automatiquement ou indiques par l'utilisateur; - changement d'activit courante (l'activit courante est l'activit vers laquelle les entres du clavier sont diriges); - changement de position et d'ordre de superposition; - changement de taille de la fentre; cette modification peut soit avoir un effet de "loupe" sur l'information visualise, soit modifier la quantit d'informations affiches. Il peut tre intressant de pouvoir rsumer une fentre son titre. La plupart des commandes sont offertes explicitement l'utilisateur soit dans le cadre des fentres, soit dans une fentre rserve au gestionnaire de fentres. Si le systme a des commandes gnriques (valables pour toutes les activits), ces commandes peuvent tre utilises pour manipuler les fentres. Par exemple, la mme commande peut dtruire un paragraphe d'un document et d'une fentre. Certaines commandes peuvent tre implicites. Nous avons dj vu que la cration d'une activit peut entraner la cration d'une fentre. De mme, le changement d'activit courante peut se faire automatiquement quand l'utilisateur dsigne une fentre. Syntaxe des commandes Nous pouvons avoir une syntaxe prfixe, postfixe ou infixe. - Dans une commande prfixe, l'utilisateur indique le nom de la commande plus les paramtres de cette commande. Cette syntaxe est souvent considre comme plus "naturelle" car plus proche de la manire de penser de l'utilisateur. Cette syntaxe place l'utilisateur dans un mode temporaire. En effet, aprs chaque commande il peut spcifier seulement les paramtres ayant trait cette commande. Ceci est un inconvnient si l'utilisateur veut utiliser plusieurs commandes et si on veut conserver la simplicit de la syntaxe. - Dans une commande postfixe, l'objet traiter est spcifi en premier et il est suivi par l'opration accomplir. Cette syntaxe, plus simple que la prcedente pour les commandes un paramtre, s'adapte mal aux commandes plusieurs paramtres, si on veut conserver la simplicit de syntaxe. - La syntaxe infixe est intermdiaire entre la postfixe et la prfixe.Les paramtres entourent la commande, ce qui rend simple une commande deux paramtres, sinon on cumule les inconvnients des deux autres syntaxes.
110
4.1.2 Les caractristiques d'un SGM pour le programmeur

Nous prsentons dans ce paragraphe l'architecture gnrale d'un SGM puis les proprits principales et enfin les possibilits de mise en oeuvre (Cou, 86). 4.1.2.1 L'architecture L'ide essentielle sur l'architecture interne d'un logiciel d'application interactive est de sparer au niveau du code les fonctionnalits concernant l'application de celles concernant l'interface homme/ordinateur. Cette ide est justifie par le fait que les fonctionnalits de l'application sont par dfinition spcifiques chaque application alors qu'une partie importante des caractristiques de l'interface est indpendante de toute application (voir les paramtres constants de la Reprsentation Conceptuelle).
Application Interactive
Fonctionnalits
Interface
Donnes
Traitements
Gestion des Entres/Sorties
Gestion du dialogue
Les fonctionnalits sont dcomposes en donnes et traitements, d'une part pour les facilits ultrieures de modification, d'autre part pour minimiser la programmation en utilisant des systmes de gestion de base de donnes. L'interface est subdivise en gestion des entres/sorties, totalement indpendante de l'application, et gestion du dialogue qui fait le lien entre les entres/sorties et les fonctionnalits de l'application. L'architecture d'un SGM peut tre ferme ou ouverte:
111
- architecture ferme Pour cette architecture le SGM est vu comme un tout, fournissant un ensemble bien dfini et indissociable de services. Ce type d'architecture permet de rendre tranparents les dtails d'implantation et les particularits de la machine, et d'tre "insensible" aux erreurs ventuelles des programmeurs d'applications. L'inconvnient majeur est que cette structure permet difficilement l'volution vers de nouvelles activits et ne permet pas aux programmeurs d'application d'utiliser de manire particulire les diffrentes fonctionnalits du SGM. - architecture ouverte Cette architecture permet au programmeur d'utiliser tous les niveaux de services dont il a besoin et ainsi d'utiliser des parties du SGM pour les besoins propres de l'activit. Il faut cependant noter qu'une architecture totalement ouverte ne peut garantir un partage quitable des ressources dans un systme multiutilisateur. L'architecture ouverte, pour tre oprationnelle, ncessite que : - chaque module soit effectivement indpendant des autres (pas d'effets de bord, pas de rfrences croises) - les services offerts par chaque niveau doivent se limiter au strict ncessaire afin de ne pas nuire aux extensions ultrieures. Par exemple, la gestion des fentres ne gre qu'un niveau de fentres (pas les sous-fentres) ce qui permet au programmeur d'utiliser ces fonctions de gestion de fentres l'intrieur d'une fentre propre une activit. Alors qu'une gestion de fentres plus labore grant ds le dpart toute une arborescence de fentres n'aurait pas permis une rutilisation facile pour le programmeur. Toute fonction qui concerne plusieurs niveaux de services doit tre dfinie dans un seul niveau, de priorit plus leve. Par exemple, le changement d'activit courante. 4.1.2.2 Les proprits Le niveau d'abstraction Il est dfini par l'unit d'change entre l'application et l'interface; cette unit d'change peut voluer entre deux extrmes; elle peut concerner des vnements lmentaires comme la prise en compte du "clic" de la souris ou des vnements synthtiques comme une commande complte et syntaxiquement correcte. Ce niveau d'abstraction joue un rle important pour la facilit de mise en oeuvre de la programmation; en effet, un niveau d'abstraction trop bas correspondant des vnements lmentaires
112
rend le travail du programmeur lourd et complexe tout en lui donnant le maximum de latitude. L'idal est bien sr est d'avoir un niveau d'abstraction lev tout en se rservant la possibilit de commandes plus lmentaires pour rsoudre des cas particuliers. Contrle du dialogue Le contrle du dialogue correspond aux possibilits d'enchanement des oprations qui, dans le cas gnral, sont rparties entre l'utilisateur et la machine; le contrle spcifie donc les enchanements automatiques aussi bien que les dclenchements utilisateurs. Le contrle peut se faire dans l'application ou dans l'interface. Il est plus usuel de mettre le contrle dans l'application et plus prcisment dans les traitements, mais cette pratique a l'inconvnient de rendre complexe sinon impossible la modification de ce contrle par le programmeur et encore plus par l'utilisateur. Aussi, si on veut pouvoir intgrer de nouvelles procdures effectives, il est prfrable de mettre ce contrle dans l'interface. Par contre, on peut envisager un contrle rparti entre l'application et l'interface dans le cas o on a un traitement dirige par les donnes, c'est--dire quand les enchanements dpendent au niveau du logiciel de la valeur des donnes; c'est plus prcisment le cas dans les systmes d'aide la dcision et en particulier dans les systmes experts. Paralllisme Nous distinguons le paralllisme gr par paralllisme tel qu'il est peru par l'utilisateur. l'ordinateur du
Le paralllisme gr par l'ordinateur consiste faire travailler en parallle soit plusieurs priphriques, soit plusieurs applications, soit plusieurs utilisateurs. Ces fonctions sont prise en compte par le systme d'exploitation de la machine. Le paralllisme peru par l'utilisateur correspond la possibilit de ce dernier d'interrompre tout instant une application pour en activer une autre en gardant prsent sur l'cran l'image de ces diffrentes applications. Cette fonction est rendue possible et praticable pour l'utilisateur par la gestion du multifentrage au niveau de l'interface, ce multifentrage s'accompagnant ou non de multitche. La fonction de multitche (ou paralllisme de la machine) a un impact sur le temps de rponse alors que le fonction de multifentrage facilite le travail de l'utilisateur.
113
Contexte Nous parlons ici du contexte de l'interaction entre l'homme et la machine. La plupart du temps ce contexte n'est pas pris en compte par le logiciel . On peut distinguer plusieurs formes de contexte: - le contexte de l'utilisateur qui permet de prendre en compte diffrents types d'utilisateur - le contexte des objectifs du travail qui est rvl par la logique d'utilisation - le contexte de la transaction qui permet de savoir o l'on se situe par rapport aux objectifs recherchs. La gestion de ces diffrents contextes a un impact sur le guidage, le traitement des erreurs et l'adaptabilit aux utilisateurs. Adaptabilit On peut distinguer l'adaptation gre automatiquement par l'ordinateur de l'adaptation dclenche par l'utilisateur. Dans les deux cas, il s'agit de la possibilit de modifier le logiciel pour s'adapter de nouveaux besoins. L'adaptation automatique du logiciel est aborde en intelligence artificielle et ralise dans certains didacticiels. L'adaptation dclenche par l'utilisateur n'est possible que si le logiciel est structur en ce sens; d'o l'importance d'une architecture modulaire des logiciels interactifs telle que nous la prsentons ici et qui est une condition ncessaire toute recherche d'adaptabilit. 4.1.2.3 La mise en oeuvre L'utilisation d'un SGM implique un style de programmation particulier que l'on qualifie de "dirige par les vnements". Le programme est conu comme une boucle appelant rgulirement une procdure qui lui fournit l'vnement suivant disponible et qui aiguille le programme vers l'action concerne, en fonction du type d'vnement reu et de l'tat courant du programme. Ce mode de fonctionnement s'apparente aux automates d'tats finis o l'tat suivant est fonction de l'tat courant et de l'vnement qui provoque la transition. Actuellement, les SGM se prsentent sous deux formes: les "botes outils" et les systmes gnriques. Les premiers sont disponibles sur le march alors que les seconds sont en dveloppement. Les "botes outils" sont constitues d'un ensemble de fonctions ddies l'interface homme/machine.
114
Il existe des fonctions des niveaux d'abstraction trs divers; les fonctions lmentaires grent des vnements comme l'appui sur une touche du clavier ou le cliquage sur la souris alors que d'autres plus synthtiques permettent de grer les menus. Les "botes outils" sont des systmes architecture ouverte o le programmeur a un maximum de latitude, mais en contrepartie il a grer tous les dtails de l'interaction ce qui est la fois complexe et lourd. Les systmes gnriques fournissent des formes standard partir desquels on va dvelopper l'application; ils permettent aussi parfois une dfinition interactive des ressources (dessin d'une fentre, d'une icne,...). Ces systmes sont btis sur une bote outils; ils peuvent donc avoir une architecture ouverte ou ferme selon que l'on peut ou non accder aux fonctions de la bote outils. L'objectif de ces systmes gnriques est de faire gagner du temps de programmation quitte perdre un peu de souplesse. C'est certainement la voie d'avenir pour le plus grand nombre de programmeurs d'application.
4.1.3 Exemples
4.1.3.1 Le SGM de Macintosh Le SGM de Macintosh est constitu d'une part d'un ensemble de primitives implantes en ROM, d'autre part d'un ensemble de fonctions logicielles regoupes dans la "bote outils". Ces primitives et fonctions sont prsentes dans le formalisme PASCAL mais sont galement accessibles partir de tout langage permettant l'excution de l'instruction TRAP. Les fonctions de la "bote outils" sont regoupes en modules selon le type d'objets qu'elles manipulent; cette structuration correspond une approche "langage-objet". Les modules concernant directement l'interface sont: - le gestionnaire de ressources - le gestionnaire d'vnements - le gestionnaire de fentres - le gestionnaire de contrles - le gestionnaire de menus D'autres modules sont disponibles pour la programmation de l'application elle-mme; ce sont les gestionnaires d'impression, de fichiers, de mmoire.
115
Le gestionnaire de ressources Les ressources sont l'ensemble des objets (fentres, messages, icnes,...)qui vont tre grs par l'interface; dans ce module on dcrit leurs caractristiques comme, par exemple, la taille d'une fentre. Le fait de dcrire ces ressources dans un module spar permet d'effectuer aisment des modifications. Il existe des ressources systme, accessibles par toute application sans dfinition pralable. Le gestionnaire de ressources permet la gestion de l'espace mmoire occup par ces ressources. Le gestionnaire d'vnements Ce sont les vnements d'interaction avec l'utilisateur, on trouve les vnements suivants: - l'vnement "souris" indique que l'utilisateur vient de presser ou de relacher la souris - l'vnement "clavier" indique que l'utilisateur presse ou relache une touche - l'vnement "disque" se produit si l'utilisateur introduit une disquette dans un des lecteurs - l'vnement "d'activation" est gnr par le gestionnaire de fentres lorsqu'une fentre devient active ou inactive - l'vnement de "mise jour" se produit si une partie du contenu d'une fentre doit tre dessine ou redessine par le programme - l'vnement "rseau" est gnr par le gestionnaire du rseau d'ordinateurs quand il existe - l'vnement "priv" peut tre dfini par n'importe quelle application spcifique Les vnements sont stocks dans une file d'attente gre en FIFO (premier entre/premier sortie) mais o on peut dfinir des priorits. Le gestionnaire de fentres Il permet de manipuler les fentres, c'est--dire de les ouvrir, de faire varier leur taille, de les dplacer, de les dtruire... Comme l'utilisateur est libre de superposer ces fentres, c'est le gestionnaire de fentres qui va grer cette superposition. Il permet galement de donner des rponses standard certaines actions de l'utilisateur comme: - rendre active une fentre aprs "cliquage" de la souris dans cette fentre - fermer une fentre aprs "cliquage" dans l'icne de fermeture - dplacer une fentre aprs "cliquage" sur la barre de titre. Il existe des fentres prdfinies mais il est possible de dfinir de nouveaux types de fentres.
116
Le gestionnaire de contrles Les contrles sont des objets graphiques prdfinis (botes, boutons, barres de dfilement) qui permettent de proposer des choix l'utilisateur. On peut les utiliser, par exemple, pour dfinir les paramtres d'une impression. Les barres de dfilement permettent l'utilisateur de faire glisser le contenu d'une fentre de manire visualiser plus d'informations que ne peut en contenir une fentre. L'utilisateur agit sur ces contrles par l'intermdiaire de la souris. Le gestionnaire de menus Il permet la manipulation de "menus droulants" qui apparaissent sur l'cran uniquement quand l'utilisateur appuie sur la souris. Il permet galement d'activer ou de dsactiver des commandes du menu ce qui est utile pour visualiser un menu dynamique. Nous pouvons constater que beaucoup de ces fonctions prsentes dans le formalisme PASCAL sont de bas niveau et demandent donc un travail important de programmation. Par contre, il existe en LELISP un certain nombre de fonctions de haut niveau qui permettent une mise en oeuvre rapide qu'il peut tre intressant d'utiliser pour construire un prototype d'interface. 4.1.3.2 Les SGM sous UNIX Nous prsentons ici des SGM dvelopps sous UNIX de manire gnrale et d'un systme particulier galement sous UNIX : BRUWIN (Mer, 81). Les SGM. dvelopps sous UNIX offrent l'utilisateur une commande explicite de cration de fentre. Celle ci associe automatiquement un interprteur de commande (shell) la fentre cre, ce qui garantit l'indpendance des programmes qui s'xcutent dans les diffrentes fentres. La compatibilit des SGM avec UNIX est assure de la manire suivante : - le gestionnaire de fentre doit collaborer avec le gestionnaire de fichiers. En effet, dans UNIX, toutes les entres/sorties se font au moyen de fichiers spciaux. Les programmes d'application accdent leur fentre par leur fichier standard d'entre ou de sortie ; ainsi chaque fentre simule un clavier : cran alphanumrique (il faut crer des procdures spciales pour pouvoir dessiner dans une fentre); - ces diffrents fichiers spciaux sont grs l'aide d'appels systmes qui sont galement utiliss pour grer les fentres puisqu'elles sont considres comme des fichiers spciaux;
117
- la description du contenu de la fentre peut tre gre entirement par le SGM ou bien dlgue au programmateur d'application. Dans ce cas, le SGM a une routine d'interruption qui permet d'activer le programme qui s'occupe de l'affichage du contenu; - les SGM sont intgrs au moyen d'UNIX car c'est la seule mthode qui permet de partager, entre plusieurs programmes la fois, du code et des donnes.Certains oprateurs offerts par les systmes UNIX font double emploi avec un SGM: . l'oprateur postfixe "&" qui permet d'activer une commande sans attendre que celle qui est active soit termine . l'oprateur prfixe "!" qui permet d'envoyer directement une commande l'interprteur de commandes sans quitter son programme. Exemple de SGM sous UNIX : BRUWIN Le systme BRUWIN (Brown University Window Manager) est un des premiers SGM raliss sous UNIX. Il fonctionne avec des terminaux alphanumriques permettant de dsigner un point sur l'cran. Il offre deux modes d'utilisation : - le mode processus pour communiquer avec le programme en excution dans la fentre courante - le mode commande pour communiquer avec le gestionnaire de fentres. Ce mode offre les commandes suivantes : . cancel : supprime l'excution de la commande BRUWIN en cours . create : cre une fentre (associe l'interprteur de commande) . change : modifie la taille d'une fentre . move : dplace une fentre . destroy : dtruit une fentre et son interprteur de commandes . command : change de fentre courante. BRUWIN est divis en trois modules principaux : . un module gestionnaire de fentre qui est responsable de la division de l'cran en fentres, de la mise jour de l'cran et de la gestion des commandes de manipulation de fentres; - un module mulateur de terminal virtuel qui permet l'adaptation diffrents tyes de terminaux. . un module contrleur de tches qui assure le lien entre BRUWIN et le systme d'exploitation. Il est galement responsable de l'envoi des caractres au programme d'application courant.
118
utilisateur
gestionnaire de fentres
Emulateur de terminal virtuel
Contrleur de tches
S E programme d'application
Interface gestionnaire/ mulateur
Interface mulateur/ contrleur
L'indpendance entre ces trois modules est assure par deux modules interface (gestionnaire / mulateur et mulateur / contrleur) ; ce qui permet de modifier l'un d'entre eux sans modifier l'ensemble. Cet exemple montre que le SGM, tel que nous l'avons dfini, peut tre vu comme une extension du systme d'exploitation, UNIX se prtant bien ce genre d'extension.
4.2 Traduction des Reprsentations Conceptuelle et Externe

La Reprsentation Interne n'est traite ici que trs succintement par le biais de son architecture gnrale, car une prsentation dtaille dpasserait par le thme et le volume le cadre de ce livre: - par le thme, car il serait ncessaire de rentrer dans le dtail des structures de contrle comme les Rseaux de Petri et dans le dtail des techniques de programmation alors que ce livre est centr sur l'analyse et la spcification des applications interactives; - par le volume, car un tel dveloppement ncessite lui seul un livre. La R.I. est la traduction des Reprsentations Conceptuelle et Externe. Normalement toutes les spcifications ont dj t faites et le passage la R.I. est une simple traduction sans gnration de nouvelles spcifications.
119
RC RI
RE
4.2.1 Architecture Reprsentation Interne
gnrale
de
la
Notre objectif principal est de permettre la conception et la ralisation d'interfaces le plus adaptative possibles. Cette procupation se traduit dans la conception de l'architecture gnrale de la R.I. Les modifications de programmes sont d'autant plus aises que les diffrentes fonctionnalits sont spares de telle manire que la modification d'un lment n'ait pas de rpercussions sur les autres lments (sauf au niveau de l'interfaage des diffrentes fonctionnalits).
Nous reprsentons cette architecture gnrale sur le schma suivant :

Saisie Utilisateur SGM INTERFACE
Rgles d'enchainement
Superviseur
Mmorisation de l'activit
Primitives de traitement
TRAITEMENTS
B.D.
Primitives de donnes
DONNEES
120
Nous dfinissons une primitive comme un lment indcomposable vis--vis du systme informatique, de mme qu'une opration lmentaire est un lment indcomposable vis--vis de l'utilisateur. Les primitives de traitement dcrivent les algorithmes de calcul. Les primitives de donnes dcrivent les contrles de vraisemblance, de concordance, la recherche et la mise jour des donnes. Les rgles d'enchanement dcrivent les diffrentes procdures (prvues, minimales et effectives). La mmorisation de l'activit des utilisateurs permet de grer les interruptions, les diffrs, les aides et l'tat d'avancement de la transaction en cours. Le superviseur joue un rle central d'activation des diffrents modules en fonction du contexte; il a un double rle d'enchanement des oprations et de contrle de la validit de ces enchanements. Le SGM dtermine la nature de l'vnement reu (clavier, lecteur,...) et le traite s'il relve seulement de la syntaxe (dplacement fentre, changement de taille,...); s'il relve de la smantique de l'application (commandes,...), il active le superviseur. Les diffrents modules que nous venons de dfinir n'ont pas le mme statut; certains ont un caractre gnral alors que d'autres sont entirement dfinis pour chaque application . Nous prsentons ces diffrents modules en prcisant leurs rles et leurs structures. Le superviseur C'est le module qui a le caractre le plus gnral, c'est--dire qu'il est totalement indpendant de tout type d'application. Le superviseur a deux fonctions imbriques : - une fonction d'enchanement, - une fonction de contrle. Il reoit les demandes d'actions de l'utilisateur travers le SGM. Il contrle le fait que la demande de l'utilisateur est compatible avec les rgles d'enchanement et la mmorisation de l'activit. Si tel est le cas, il active les traitements demandes et il met jour la mmorisation de l'activit. Il renvoie des messages l'utilisateur par le biais du SGM.
121
De plus il gre les abandons, les reports, les interruptions (dans le cas o cette dernire fonction n'est pas prise en compte par le SGM) par des mises jour du module de mmorisation de l'activit. Rgles d'enchanement et mmorisation de l'activit Pour ces modules nous avons deux possibilits de reprsentation: les automates d'tats finis et les Rseaux de Petri. La reprsentation sous forme d'automates d'tats finis est maintenant classique et bien connue des informaticiens; la reprsentation visuelle est simple et la transposition sous forme vectorielle facile. Le seul inconvnient est qu'elle ne permet pas une gestion aise du paralllisme. Le paralllisme tant une composante essentielle des traitements en informatique des organisations et dans les interfaces homme/machine, il est plus exact d'utiliser le formalisme des Rseaux de Petri (Bra, 83) et plus prcisment les Rseaux de Petri Objets (Sib, 85) et (Bar, 86) qui ont l'avantage de permettre l'expression des interactions entre les donnes et les traitements. Les primitives de traitement et de donnes Nous incluons dans ces modules les primitives de : - contrle de donnes (vraisemblance et concordance) - gestion de donnes - gestion de traitements. La dfinition de ces primitives est entirement particulire chaque application. Elles sont dfinies pour chaque oprations interactive ou automatique. L'architecture que nous venons de prsenter correspond aux possibilts maximales de mise en oeuvre des fonctionnalits des logiciels interactifs; il n'est pas vident de runir l'ensemble des logiciels et des comptences permettant ce type de mise en oeuvre; nous examinons ce qui peut tre fait si certains des composants sont absents: - si on ne dispose pas d'un interprteur de Rseau de Petri, on peut grer les enchanements et la mmorisation de la transaction au moyen de vecteurs boolens qui traduisent le comportement de l'automate d'tat fini; ceci sera praticable tant que le paralllisme est faible;
122
- si on ne dispose pas d'un SGM, certaines fonctionnalits comme la gestion des interruptions peuvent tre prises en charge par le superviseur ou ventuellement par une modification du systme d'exploitation; par contre, la plupart des fonctionnalits offertes directement l'utilisateur comme le dplacement de fentres ou leur superposition ne peuvent plus raisonnablement tre gres; - si on adopte une architecture de programmes plus classique o l'on ne distingue pas l'interface et les traitements, on se prive de possibilits de modification et en particulier d'adaptation aprs des tests auprs des utilisateurs; mais on peut quand mme mettre en oeuvre les recommandations ergonomiques caractre gnral.
123
Chapitre 5 : DIANE METHODE DE CONCEPTION D'APPLICATIONS INTERACTIVES

Comme nous l'avons dfini au chapitre 1, une mthode permet de rendre oprationnel un modle ou en d'autres termes constitue un mode d'emploi particulier d'un modle. En ce sens, elle restreint les possibilits du modle et de fait, quand on a trs bien intgr un modle, on n'a plus besoin de suivre une mthode particulire et on s'adapte mieux ainsi aux particularits de l'environnement. Par contre, il est beaucoup plus simple d'apprendre manier un nouveau modle par le biais d'une mthode qui sert de guide tout au long de la dmarche. On peut dire qu'une mthode est une sorte de procdure prvue qui indique: - comment s'articulent les diffrents lments du modle (squentialit, paralllisme), - quels sont ceux qui sont observables et comment, - quels sont ceux qui sont dductibles et partir de quoi (observations, connaissances gnrales). On peut ainsi la limite appliquer une mthode sans matriser pleinement le modle sous-jacent. A cet effet, ce chapitre constitue un tout en soi qui peut tre utilis quasiment indpendamment des autres chapitres. Mais, si on veut savoir sur quels lments de psychologie cognitive et d'ergonomie se base cette mthode, il faut lire la premire partie des chapitres 2 et 3. Pour les dfinitions de concepts, on se reportera au glossaire (les concepts dfinis dans le glossaire et utiliss pour la premire fois dans ce chapitre sont marqus d'une astrisque "*"). Le chapitre comporte deux parties: - dans les trois premiers paragraphes, nous prsentons une dmarche informatique classique o l'informaticien est responsable de l'ensemble du processus de l'analyse jusqu' la conception de l'application. Nous prsentons d'abord l'tude de l'existant, puis la conception de l'application automatise et en dernier lieu les tests sur le prototype ainsi dfini;
124
- dans le dernier paragraphe, nous traitons une tude de cas complte qui va de l'tude de l'existant la dfinition de la Reprsentation Externe. La mthode DIANE que nous exposons ci-dessous concerne exclusivement l'analyse et la conception des applications interactives ; mais la plupart du temps, il est ncessaire de faire une tude globale du systme d'information avant de se proccuper des applications interactives, il nous a paru donc important de montrer comment la mthode DIANE pouvait se greffer sur une mthode d'analyse gnrale. Dans la suite de cet expos, nous montrons comment intgrer la mthode DIANE partir de la mthode MERISE.
5.1 Etude de l'existant

Nous rappelons dans le premier paragraphe les divers modes de recueil de l'information d'un systme existant afin de pouvoir s'y rfrer dans le deuxime paragraphe quand nous dcrivons le systme existant, l'objectif tant de montrer quels sont les modes de recueil les plus adapts pour dcrire les diffrents paramtres du systme.
5.1.1 Collecte de l'information

Nous prsentons succintement l'ensemble des techniques utilisables pour dcrire le travail existant; dans les trois premires (entretien, runion, questionnaire), l'utilisateur joue un rle actif d'explicitation verbale de son travail alors que dans les trois dernires (autorelev, observation, capteur), il excute son travail sans l'analyser. Entretien C'est certainement la technique la plus utilise par les informaticiens ; elle prsente l'avantage d'tre une trs bonne source d'informations qualitatives. L'entretien peut tre structur ou non; s'il n'est pas structur, il permet d'obtenir des informations caractre gnral, de percevoir le climat et les problmes principaux qui se posent. Un entretien non structur constitue souvent une tape obligatoire pour commencer une tude de l'existant dans une entreprise peu ou pas connue. L'entretien structur s'apparente un questionnaire en ce sens qu'il demande une prparation pralable de questions rponses limites
125
ou ouvertes; s'il est bien conu, il facilite la synthse des informations provenant des diffrents interlocuteurs. Le choix des personnes interroger est un problme essentiel, car il est rarement possible d'avoir des entretiens avec l'ensemble des personnes interesses par l'tude et un mauvais choix peut donner une vision fausse ou biaise de l'existant. L'inconvnient majeur de l'entretien est qu'il est coteux en temps, la fois pour l'analyste et pour les utilisateurs . Aussi peut-on le remplacer ou le complter par des runions ou des questionnaires. Runion La conduite de runion suppose un minimum de formation et d'exprience pour tre efficace ainsi qu'un choix judicieux du nombre et du type des participants. Car les interactions entre les participants peuvent tre strilisantes et empcher de recueillir toutes les informations souhaitables. Par contre, correctement men elle peut permettre une adhsion du groupe l'tude et l'mergence de nouvelles propositions. Questionnaire Les questionnaires remplis par l'utilisateur peuvent complter ou mme remplacer des entretiens ou des runions pour recueillir des informations prcises, bien dlimits et quantitatives. L'inconvnient rside dans le fait qu'il peut tre mal rempli si l'utilisateur interprte de manire erronne certaines questions. Les entretiens, runions et questionnaires font appel explicitement l'utilisateur et donc sa subjectivit pour dcrire sa situation de travail; on obtient donc ainsi le rel peru parl'utilisateur et exprim pour l'analyste. Cette situation peut avoir trois effets: - certains comportements inconscients ne sont pas exprims, - si le rel est complexe, on recueille la description des cas "normaux" et non pas des cas effectifs, - certains faits peuvent tre volontairement omis. Autorelev Il consiste faire remplir aux interesss un questionnaire dtaille dcrivant leur travail au fur et mesure qu'il se droule; on recueille ainsi le travail effectif et non pas le travail dcrit. L'inconvnient majeur est que l'analyste peut se retrouver avec une masse d'information inexploitable qui ne lui permet pas de dgager une synthse du travail ainsi dcrit.
126
Observation Cette technique trs utilise par les ergonomes l'est fort peu par les informaticiens. Elle permet, comme l'autorelev, de recueillir une information sur le travail effectif ; son avantage supplmentaire est de ne pas mobiliser l'utilisateur puisque c'est un observateur extrieur qui remplit les relevs. Elle est par contre trs coteuse en temps d'analyste. Capteur Dans le cas d'tude sur des logiciels existants, cette technique consiste rajouter des lments aux logiciels de manire recueillir automatiquement les traces de travail de l'utilisateur. C'est une observation automatique qui de ce fait ne s'applique qu' l'observation de certains paramtres, mais qui peut complter d'autres techniques d'observation. Les autorelevs, les obsevations et les capteurs permettent par des moyens diffrents de recueillir les traces de travail effectif. La plupart du temps, on combine plusieurs de ces techniques pour avoir l'image la plus exacte du systme existant; on peut, par exemple, procder des observations, puis avoir un entretien avec l'utilisateur observ pour obtenir des complments d'informations sur les faits observs. Quel que soit le soin que l'on prend recueillir l'information sur le systme existant, on n'obtient qu'une image partielle du systme rel et l'essentiel est de savoir quelle partie du systme rel on a dcid d'ignorer, jusqu' quel niveau de dtail on veut le dcrire et quels sont les lments du systme rel que l'on juge ngligeables.
5.1.2 Description du systme existant

L'objectif de cette tape est de montrer comment dterminer les logiques d'utilisation (*) associes aux diffrents postes de travail concerns par l'automatisation. Cette logique d'utilisation se traduit ici par la dtermination des buts (*) d'un poste de travail (*); puis, pour chaque but, la dtermination des diffrentes procdures (*) permettant de l'atteindre.
127
Organisation
Poste de travail 1
Poste de travail 2
Poste de travail i
But 1
But 2
But j
Procdure prvue
Procdure minimale
Procdure effective
5.1.2.1 Les buts d'un poste de travail Le dcoupage d'un systme d'information se fait usuellement dans les mthodes d'analyse par la notion de domaine ou de fonction. L'objectif est de dcouper le systme d'information en soussystmes le plus indpendants possibles (c'est--dire ayant le minimum de relations entre eux). Dans la mthode MERISE, l'intrieur d'un domaine ou d'une fonction du systme d'information, le dcoupage, s'il y a lieu, se fait en processus au niveau conceptuel et en procdures au niveau organisationnel. Le processus ou la procdure est elle-mme dcompose en un enchanement d'vnements et d'oprations. L'opration est dfinie "comme un ensemble d'actions lmentaires non ininterruptible". La notion d'opration non interruptible est une notion importante du dcoupage de MERISE qui ne pose aucun problme pour les oprations manuelles et automatiques, mais qui nous semble devoir tre prcise dans le cas d'oprations interactives ; aussi dfinissonsnous une opration interactive comme "un ensemble de transactions qui peuvent tre excutes conscutivement et sans attente d'vnements externes au systme homme-ordinateur". Cette dfinition permet d'intgrer toutes les interruptions provoques par l'utilisateur en cours d'opration que ce soit pour activer d'autres oprations ou pour diffrer son travail.
128
Rechercher les buts d'un poste de travail revient chercher la logique d'utilisation des utilisateurs. Pour cel, nous pouvons procder de deux manires : - la premire manire part du systme d'information - la seconde manire est issue de l'tude du systme de dcision. Dtermination des buts partir du systme d'information Nous prsentons en premier la mthode issue de l'tude du systme d'information, car c'est celle qui est la plus usuelle pour les analystes. En effet les mthodes de conception des systmes informatiss s'appuient sur le systme d'information et mme, souvent, uniquement sur le systme d'information du systme oprant. Dans la mthode MERISE, la dtermination des buts d'un poste de travail se situera immdiatement aprs la description du niveau organisationnel des traitements et des donnes du systme existant. A la fin de cette phase, nous disposons, pour les traitements, d'un ensemble de procdures qui dcrivent les enchanements des oprations du nouveau systme et pour chaque opration nous avons dtermin, sa nature (interactive, automatique, manuelle) et son lieu d'excution (poste de travail, service). Pour les donnes, nous disposons de l'ensemble des vues externes du poste de travail. Par la suite, nous considrons simultanment les traitements et les donnes d'une opration. Nous allons maintenant regrouper toutes les oprations interactives et automatiques excutes sur un mme type de poste de travail. Il faut remarquer que le mme type de poste de travail peut participer des procdures diffrentes mais aussi des fonctions diffrentes. (Ex : la gestion des stocks participe la fonction achats et la fonction ventes ; c'est le seul point d'intersection de ces fonctions). Ces regroupements seront faits en respectant les rgles d'enchanement et les synchronisations (*) dtermines aux niveaux prcdents (rgles d'enchanement du niveau conceptuel et du niveau organisationnel).
129
Exemple d'interaction entre fonctions, procdures et oprations d'un poste de travail:

Fonction 1 Procdure 1 Procdure 2 Fonction 2
Poste de travail 1
Poste de travail 3
Poste de travail 4
Poste de travail 2
Pour faire merger les buts , nous remarquons qu'un but d'un poste de travail donn correspond un sous-ensemble d'oprations de l'ensemble des oprations possibles de ce poste de travail. Il est important de noter que l'ensemble des buts d'un poste de travail ne constitue pas forcment une partition de l'ensemble des oprations car une mme opration peut appartenir deux buts diffrents. Pour dterminer si deux oprations appartiennent au mme but (c'est--dire sont ncessaires la ralisation du but), il faut demander l'utilisateur s'il peut avoir besoin en mme temps de ces oprations dans la ralisation d'une de ces tches. L'objectif est qu'il ait "sous la main", un moment donn, l'ensemble des oprations qu'il peut tre amen utiliser pour raliser un but donn. Il faut penser en particulier aux oprations de consultation pour l'aide et aux oprations de modification et d'annulation pour la correction des erreurs. Les informations ncessaires aux regroupements des oprations en buts peuvent tre recueillies par entretien auprs des utilisateurs concerns (excutants); en cas d'ambigut, les entretiens peuvent tre complts par des autorelevs ou des observations. Cette dmarche, qui part des oprations du systme d'information pour faire merger les buts, convient bien aux postes de faible responsabilit qui n'ont pas de fonction de pilotage vis--vis d'autres
130
postes de travail et/ou qui n'ont pas de fonction de rgulation importante. Dans les autres cas, il est plus efficace et plus sr d'utiliser la seconde dmarche qui part de l'tude du systme de dcision. Dtermination des buts partir du systme de dcision Le systme de dcision est peu tudi en tant que tel dans les mthodes d'analyse informatique; la seule mthode oprationnelle qui l'tudie ainsi que ses interactions avec le systme d'information est l'Analyse Modulaire des Systmes de J. Melese (Mel,77). Cette mthode, que nous rappelons brivement ci-dessous, peut tre applique globalement ou localement; elle permet de dgager les objectifs d'un poste de travail et d'tudier la compatibilit des boucles de rgulation par rapport ces objectifs. Elle peut tre un guide pour dgager les objectifs mais aussi pour dfinir les diffrents types de procdures, en particulier la procdure minimale. L'Analyse Modulaire des systmes Le principal intrt de l'A.M.S est de permettre l'analyse de l'interaction entre le systme d'information et le systme de dcision de l'entreprise. Pour cela, elle propose une description ou toute activit de l'entreprise est modlis sous la forme d'un couple module de pilotage-module technologique que nous reprsentons dans un formalisme simplifi sur le schma suivant:
Entres Entres informatives opratives externes Entres Entres opratives informatives
Entres informatives internes Activit Variables de contrle
Module de pilotage Variables de rglage

Rgles opratoire Degr de modlisation Variables de contrle
Module technologique
Rgles opratoires Degr de programmation
Cot Efficacit
Sorties opratives
Sorties informatives
Sorties Sorties opratives informatives
131
Le module de pilotage permet de dcrire les mcanismes de dcision qui transforment les informations d'entre de ce module en informations de dcision pour le module technologique afin de maintenir le fonctionnement du module technologique en direction des objectifs assigns. Les objectifs sont dcrits selon trois types de variables qui sont l'activit, le cot, l'efficacit. Pour notre tude, ce sont les descriptions des objectifs en termes d'activit et d'efficacit qui sont retenir. Un autre concept intressant pour notre tude est la distinction entre variables de rglage et variables de contrle. Les variables de contrle correspondent une transmission de dcisions prises un niveau hirarchique suprieur; le module de pilotage se contente d'adapter ces dcisions au contexte du module technologique, mais il n'en est pas l'origine et il ne peut les remettre en cause. Les variables de rglage sont par contre de l'entire responsabilit du module de pilotage correspondant. Elles permettent de dcrire les dcisions qui sont gnres ce niveau en fonction des informations provenant du module technologique (entres informatives internes) ou provenant d'autres modules ou de l'environnement (entres opratives et informatives externes). L'ensemble des variables de rglage et des entres d'information constitue une boucle de rgulation qui a pour but de matriser le fonctionnement du module technologique et d'absorber une partie des fluctuations de ce module. Cette dcomposition en deux modules s'applique aussi bien au niveau de l'entreprise globale qu'au niveau du poste de travail. Elle permet ainsi de dgager des chanes de pilotage qui dcrivent le systme de dcision de l'entreprise, c'est--dire la transmission des dcisions, la rpartition des responsabilits et les boucles de rgulation. Dans le cadre de notre tude, nous l'appliquons l'ensemble des postes de travail concerns par le nouveau systme afin de dgager la fois les buts et la latitude dcisionnelle de chaque poste de travail. La latitude dcisionnelle permet de dgager plus aisment les procdures minimales. Le reste du systme d'information est dcrit au niveau du module technologique par les rgles opratoires permettant de transformer les informations d'entre de ce module en informations de sortie. Les objectifs ou buts tant ainsi dtermins par l'tude du systme de dcision et l'ensemble des oprations par l'tude du systme d'information, il suffit de mettre les deux en correspondance en se
132
demandant quelles sont les oprations qui contribuent la ralisation d'un but. Cette dmarche est sans contexte plus sre que la prcdente, mais comme elle est plus lourde mettre en oeuvre il est prfrable de la rserver aux postes exerant des responsabilits dans les organisations ou aux postes dont on n'arrive pas faire merger sans ambigut des buts par le simple regroupement des oprations. Tableau de synthse de la dtermination des buts:
Pour dterminer... les buts par rapport au systme d'information, ...dfinir - ensemble des oprations utiles la ralisation d'un but - aide - redressement des erreurs Moyens de collecte - entretiens auprs d'utilisateurs - autorelevs
Pour dterminer... les buts par rapport au systme de dcision,
...dfinir - activit et efficacit - boucle de rgulation - variables de rglage et variables de contrle
Moyens de collecte entretiens auprs d'utilisateurs et de responsables
5.1.2.2 Les diffrentes procdures existantes Les procdures, que nous dfinissons ici, utilisent un formalisme, prsent dans le chapitre 2, trs voisin de celui utilis dans MERISE pour dcrire les processus ou procdures; mais elles se distinguent des procdures de MERISE par leur smantique car elles dcrivent l'enchanement des oprations ncessaires la ralisation d'un but d'un utilisateur et non pas un sous-domaine du systme d'information. La notion d'opration (*) est elle aussi modifie pour pouvoir intgrer les interruptions l'initiative de l'utilisateur.
133
Pour chaque but, nous dterminons en premier la procdure prvue (*) car c'est celle qui se dgage "naturellement" d'une tude de l'existant mene au moyen d'entretiens ou de questionnaires auprs des excutants ou des responsables. En effet, quand on interroge des utilisateurs, on obtient en premier lieu la description des cas les plus courants qui correspondent normalement la procdure prvue. La description de la procdure prvue existante est indipensable pour la suite de l'tude. Pour obtenir la description de procdures effectives (*) qui correspondent des cas particuliers ou des habitudes de travail diffrentes, il faut soit mener des entretiens plus approfondis auprs des excutants, soit procder des observations ou mettre en place des capteurs ou faire remplir des autorelevs. La description des procdures effectives existantes tant trs coteuse en temps d'analyse, elle ne doit tre faite que si les procdures existantes sont peu ou pas modifies par le changement de systme. La procdure minimale (*) ne peut se dgager spontanment des entretiens car elle comprend des informations qui, la plupart du temps, ne sont pas explicites. Il s'agit ici de dfinir explicitement la latitude dcisionnelle de l'utilisateur ou, en d'autres termes, la marge de manoeuvre dont il dispose pour effectuer le travail assign son poste. Cette marge de manoeuvre s'exprime par la nature des dclenchements (*) (optionnel ou systmatique), des prcdences (*) (permanentes ou indicatives) et des oprations (*) (obligatoires ou facultatives). Si le systme existant que nous observons est compos de procdures entirement manuelles, la nature des dclenchements, des prcdences et des oprations dcrira la rpartition des responsabilits entre le poste de travail que nous dcrivons et les postes de travail dont il dpend ou qui dpendent de lui. Tous les aspects obligatoires, permanents et systmatiques correspondent des consignes intransgressables ce niveau de responsabilit. Si les procdures existantes sont dj automatises, ces consignes intransgressables doivent tre dj intgres aux logiciels; en consquence, il faut dans ce cas tudier la rpartition du pilotage entre l'homme et la machine. Mais la rpartition existante du pilotage entre l'homme et la machine ne correspond pas forcment la procdure minimale, nous pouvons simplement supposer que la procdure minimale est incluse dans la partie de la procdure gre par ordinateur et qu'il faut alors la dgager par une tude plus approfondie.
134
La procdure minimale ne peut tre recueillie que par entretien dirig auprs des responsables ou des excutants selon le contexte de l'entreprise. Pour dterminer la procdure minimale, le plus simple est de partir de la procdure prvue dj recueillie et de poser des questions permettant de dgager les dclenchements systmatiques, les prcdences permanentes et les oprations obligatoires. La notion de dclenchement n'a de pertinence que dans le cas d'une procdure existante dj automatise (oprations interactives ou automatiques) o l'on se demande si c'est l'utilisateur ou l'ordinateur qui dclenche une opration; en effet, si les oprations sont manuelles, il est vident qu'elles ne peuvent tre dclenches que par l'utilisateur! Nous rappelons qu'il y a des prcdences de type logique (une modification ne peut avoir lieu qu'aprs une cration) et des prcdences de type organisationnel, c'est--dire lies aux rgles de gestion ("tout paiement de facture ne peut se faire qu'aprs l'mission d'un bon de commande"). Ce sont les prcdences de type organisationnel que nous tudions ici. Pour trouver la nature des prcdences, on pose des questions du type: "Que se passerait-il si vous effectuiez l'opration Y avant l'opration X ?" (quand la procdure prvue indique que X est excute avant Y). Si l'utilisateur rpond que c'est impossible parce que le rglement interne ou la loi s'y oppose ou toute autre raison ne relevant pas de lui, on a une prcdence permanente. S'il rpond que c'est plus commode ou plus logique ou plus facile, on a trs certainement affaire une prcdence indicative. Pour connaitre le caractre obligatoire ou facultatif des oprations mises en oeuvre dans la procdure prvue, il faut poser des questions du type "Peut-on ne pas excuter l'opration X ?" ou "Que se passe-t-il si on ne fait pas l'opration X ?".
135
Tableau de synthse de la dtermination des procdures:

Pour dterminer... la procdure prvue, ...dfinir les cas usuels Moyens de collecte entretiens ou questionnaires auprs d'utilisateurs (mme novices) et de responsables
Pour dterminer... la procdure effective,
...dfinir - les rponses aux alas - les types d'utilisateurs (expriments, novices..) - l'organisation propre l'utilisateur
Moyens de collecte - auto-relevs - capteurs - observations auprs des utilisateurs
Pour dterminer... la procdure minimale,
...dfinir la latitude dcisionnelle associe au poste de travail : - oprations obligatoires ou facultatives - prcdence permanente ou indicative - dclenchement par utilisateur ou par ordinateur
Moyens de collecte entretiens approfondis partir de la procdure prvue, auprs des responsables ou des utilisateurs expriments
A la fin de l'tude de l'existant, nous disposons donc au minimum d'une description des procdures prvues et minimales des diffrents postes de travail qui vont faire l'objet d'une nouvelle conception.
5.2 Conception d'une application interactive

Nous exposons dans ce paragraphe comment concevoir les nouveaux logiciels interactifs partir des spcifications de l'existant. Pour chaque poste de travail, cette conception se subdivise en trois parties; nous concevons d'abord la Reprsentation Conceptuelle de
136
l'application puis la Reprsentation Externe et en dernier la Reprsentation Interne qui dpend la fois des deux autres reprsentations.
Nous n'exposons pas ici la mthode de conception de la Reprsentation Interne car celle-ci est trop dpendante des logiciels de base disponibles et des mthodes de programmation; elle ncessite elle seule un dveloppement gal l'ensemble de ce livre. Nous prsentons donc ci-dessous la mthode de conception de la Reprsentation Conceptuelle et de la Reprsentation Externe.
5.2.1 Mthode de conception Reprsentation Conceptuelle
de
la
Nous allons dfinir, dans le premier paragraphe, les trois types de procdures (prvue, minimale, effective) du nouveau systme et dans le deuxime paragraphe, le dtail d'une procdure. 5.2.1.1 Les diffrentes procdures de la Reprsentation Conceptuelle L'ordre d'laboration de ces procdures peut varier selon les cas : - si les nouvelles procdures automatises sont proches des procdures existantes, on dfinira en premier lieu les procdures prvues (puis minimale puis effective). - si les nouvelles procdures automatises sont loignes des procdures existantes, on dfinira en premier lieu la procdure minimale (puis prvue puis effective).
137
Ces trois types de procdures n'ont pas du tout le mme statut mthodologique; il est indispensable de dfinir la procdure minimale; il est confortable de dfinir une procdure prvue; il peut tre utile et efficace de dfinir une ou des procdures effectives . Procdure minimale Il y a deux manires diffrentes de la dfinir selon que le nouveau systme est plus ou moins loign de l'ancien systme. Premier cas Elle est dduite de la procdure minimale existante si celle-ci est peu ou pas modifie par l'automatisation. Dans ce cas, nous repartons de cette procdure minimale existante et pour chaque opration, nous nous demandons si cette opration reste manuelle ou devient interactive ou automatique. Pour la procdure constitue de ces oprations interactives et automatises, nous nous posons la question fondamentale suivante: "Les prcdences permanentes et les oprations obligatoires du systme existant doivent-elles tre contrles par l'ordinateur?"; ou en d'autres termes, "transfre-t-on une partie du contrle de l'organisation l'ordinateur?". La plupart du temps, la rponse est positive, car on pense que ce transfert ne peut qu'accrotre l'efficacit du contrle. Mais ce transfert n'est pas toujours ausssi direct car on profite souvent de l'automatisation d'une procdure pour procder des rorganisations qui ont justement un impact sur la latitude dcisionnelle des diffrents postes de travail: on peut tre amen augmenter ou diminuer cette latitude dcisionnelle, ce qui influe sur la nature des prcdences, des oprations et des dclenchements. Il faut noter que ces modifications sont souvent faites implicitement sans que le lien soit fait explicitement avec l'organisation. L'objectif essentiel de cette tape est de rendre explicites les choix organisationnels et leurs consquences sur le niveau dcisionnel de chaque poste de travail. Pour dterminer les dclenchements systmatiques, il faut se demander si "l'enchanement est immdiat ou non entre deux oprations relies par une prcedence permanente". Si l'enchanement est immdiat, on a un dclenchement systmatique, c'est--dire dclench par l'ordinateur. Dans tous les autres cas, on a un dclenchement optionnel, c'est--dire contrl par l'utilisateur.
138
Au niveau de la procdure minimale, il vaut mieux prvoir le maximum de dclenchements optionnels pour avoir la plus grande latitude dans la dfinition des procdures prvues et effectives. Deuxime cas: La procdure minimale est dfinie "ex nihilo" si l'automatisation modifie trop la procdure minimale existante. Pour cela, on part de l'ensemble des oprations appartenant au but considr et pour chaque opration nous dfinissons, comme prcdemment, son caractre obligatoire ou facultatif et la nature de son dclenchement. Nous introduisons ensuite les prcdences permanentes correspondant aux rgles de gestion non transgressables . La procdure prvue Elle correspond au cas normal ou usuel. Son rle est d'une part de servir de guidage un utilisateur novice qui se poserait une question du type "comment faire pour atteindre le but x", d'autre part de simplifier le travail de l'utilisateur en lui fournissant une procdure rduite au cas normal avec le maximum d'aide et d'enchanement automatique. Si la conception du sytme automatis n'entrane pas ou peu de modifications, la procdure prvue peut tre dduite directement de la procdure prvue existante telle qu'elle a t recuillie lors de l'tude de l'existant . Si la conception du systme automatis entrane une modification de la logique de fonctionnement du systme d'information et/ou une rorganisation, il faudra la crer partir de la procdure minimale. Pour cela, on rajoutera la procdure minimale des prcdences indicatives et des dclenchements automatiques qui rendront l'excution de la procdure prvue plus commode et plus rapide. Bien entendu, il ne s'agira seulement que d'hypothses sur le fonctionnement usuel de la procdure qui demanderont tre valides auprs des utilisateurs sur un prototype ou sur le logiciel final. La procdure effective Les procdures effectives ne sont pas ncessairement dfinies ce stade de la mthode. En effet, une procdure effective ne peut tre dfinie ici que si l'on a observ lors de l'tude de l'existant des variantes de procdures lies des types diffrents d'utilisateurs (novices, expriments, occasionnels...).
139
Dans le cas o on a pu procder ces observations, on dfinira une procdure effective en rajoutant des prcdences indicatives la procdure minimale qui correspondent l'usage de l'utilisateur, en augmentant les dclenchements automatiques pour minimiser les manipulations de l'utilisateur et en supprimant des oprations facultatives non ncessaires dans ce cas particulier. Si l'on n'a pas pu procder ces observations, on ne pourra pas dfinir de procdure effective ce stade de la mthode. Il faudra alors attendre d'avoir ralis compltement l'application interactive (sous sa forme minimale et prvue) afin de l'exprimenter auprs des utilisateurs et de rajouter ensuite la demande diffrentes procdures effectives (ce qui suppose une structure de logiciel permettant cette adaptation telle que nous l'avons dfinie dans le chapitre 4). 5.2.1.2 Les lments d'une procdure Paramtres constants Les paramtres constants dsignent l'ensemble des aides offertes l'utilisateur indpendamment de toute application. Dans le chapitre 2, nous avons dfini trois types de paramtres constants; les premiers concernent l'aide au travail (interrompre, quitter, annuler, transfrer,...), les seconds l'aide l'apprentissage (guidage fonctionnel et guidage d'utilisation), les troisimes les possibilits d'volution (ajout de procdures effectives,...). A ce stade du droulement de la mthode, il faut dcider quels sont les paramtres constants qui seront effectivement mis systmatiquement la disposition des utilisateurs. Ce choix peut dpendre de la nature du travail, de la latitude dcisionnelle des utilisateurs, mais aussi de contraintes matrielles et logicielles. Ces choix ont des consquences sur la Reprsentation Conceptuelle des paramtres variables de la procdure. En effet, si on ne donne pas l'utilisateur, par exemple, les possibilits systmatiques de quitter ou d'interrompre, il faudra prvoir dans la description de la procdure les endroits spcifiques o l'utilisateur pourra activer ces commandes. Paramtres variables Les paramtres variables correspondent la description des procdures spcifiques d'une application. La mthode Diane pouvant se greffer sur la mthode Merise, nous utilisons le formalisme graphique de Merise pour la description des
140
vnements, des oprations, des rgles d'mission et des synchronisations. Nous rajoutons ce formalisme diffrents concepts qui ont pour but de dfinir la rpartition du pilotage entre l'homme et l'ordinateur dans le cadre des applications interactives et qui permettent de rpondre aux questions suivantes: - Qui dclenche l'opration? Si c'est l'utilisateur, on a un dclenchement optionnel; si c'est l'ordinateur, c'est un dclenchement automatique. - Qui fait l'opration? Si c'est l'utilisateur, c'est une opration manuelle; si c'est l'ordinateur, c'est une opration automatique; si c'est les deux, c'est une opration interactive. - Qui contrle l'excution de l'opration? Si c'est l'utilisateur, c'est une opration facultative; si c'est l'ordinateur, c'est une opration obligatoire. - Qui contrle l'enchanement entre oprations? Si c'est l'utilisateur, c'est une prcdence indicative; si c'est l'ordinateur, c'est une prcdence permanente. L'ensemble de ces paramtres variables ainsi que le formalisme associ est prsent dans la deuxime partie du chapitre 2. L'tude de cas prsente la fin de ce chapitre illustre de faon dtaille la description des procdures de la Reprsentation Conceptuelle. 5.2.1.3 Dmarche Conceptuelle globale pour la Reprsentation
Pour mieux visualiser la mthode de conception, nous reprsentons sur les deux schmas suivants deux faons de la mettre en oeuvre selon le contexte de l'tude et de l'entreprise. Dans les deux cas, nous supposons qu'il y a un existant qui sert de base la nouvelle conception. Mais cette phase d'tude de l'existant peut ne pas avoir lieu, soit parceque on a affaire un nouveau service ou une nouvelle entreprise, soit parce que l'on a dcid de modifier en profondeur le systme existant et qu'il ne doit plus servir de rfrence. Les schmas que nous prsentons se rduisent alors la phase de conception suivie ventuellement de la phase d'exprimentation. Dmarche minimale Le premier schma montre la dmarche minimale o l'on part de la procdure prvue existante recueillie par entretien ou questionnaire pour extraire la procdure minimale existante par entretien partir de la procdure prvue.
141
La conception se fait alors par le chemin inverse avec la dtermination de la nouvelle procdure minimale partir de la procdure minimale existante puis la conception de la nouvelle procdure prvue en fonction de la procdure prvue existante et de la nouvelle procdure minimale.
Procdure prvue (existant) Procdure minimale (existant)
Existant
Conception
Procdure prvue (nouveau)
Procdure minimale (nouveau)
Cette dmarche est minimale en ce sens qu'on ne peut pas rduire la longueur de l'tude un niveau infrieur en temps et en informations recueillies. Elle peut ventuellement suffire si les procdures sont simples ou si le niveau dcisionnel du poste de travail est bas. Dans les autres cas, il vaut mieux faire une tude plus complte comme nous le prsentons ci-dessous. Dmarche maximale L'tude de l'existant peut tre complte par le recueil d'une ou de plusieurs procdures effectives qui servent dterminer de nouvelles procdures effectives compte-tenu de la nouvelle procdure minimale. Ultrieurement, lors de la phase d'exprimentation (aprs la dtermination de la Reprsentation Externe), on peut tester l'adquation de la nouvelle procdure prvue en tant que guide pour des utilisateurs novices et l'adquation des procdures effectives pour les utilisateurs expriments. Cette dmarche est beaucoup plus coteuse en temps d'analyste et d'utilisateur car les deux parties que nous rajoutons (procdures effectives et exprimentations) font appel des recueils de trace de travail (observations,autorelevs, capteurs).
142
Existant
Procdure prvue (existant)
Procdure minimale (existant)
Procdure effective (existant)
Conception
Procdure prvue (nouveau)
Procdure minimale (nouveau)
Procdure effective (nouveau)
Exprimentation
Procdure prvue
Procdure effective
Les flches en trait plein indiquent la dmarche obligatoire minimale; les flches en pointill indiquent une dmarche possible.
5.2.2 Mthode de Reprsentation Externe
conception
de
la
La conception de la Reprsentation Externe est dpendante de plusieurs lments que nous avons schmatiss sur la figure cidessous. En premier lieu, elle comprend la traduction des spcifications dtermines dans la Reprsentation Conceptuelle. Elle intgre aussi certains lments d'ergonomie provenant de l'tude de l'existant comme le vocabulaire spcialis, ou ayant un caractre gnral comme l'homognit. Et elle dpend galement des possibilits techniques matrielles et logicielles des ordinateurs sur lesquels se fait l'implmentation.
143
Existant
Critres ergonomiques gnraux
Possibilits techniques (logiciel, matriel)
5.2.2.1 Traduction de la Reprsentation Conceptuelle Dans la premire tape de la dfinition de la Reprsentation Externe il s'agit de donner une reprsentation externe aux paramtres dfinis dans la Reprsentation Conceptuelle et que nous avons dtaills la fin du chapitre 2. On distingue, comme prcdemment, les paramtres constants des paramtres variables qui sont propres l'application. Les paramtres constants de la Reprsentation Conceptuelle concernent l'aide l'utilisation, la mmorisation et le guidage; ces paramtres doivent tre traduits sous forme de commandes activables par l'utilisateur. Pour chacune de ces commandes, il faut prvoir: - un nom sans ambigut pour les utilisateurs et compatible avec les logiciels existants - une forme de prsentation (caractres gras, italiques,...) ventuellement variable pour indiquer que la commande est ou n'est pas activable - un mode de dsignation (touche-fonction, souris,...) et une syntaxe rapide et facile mmoriser - une dtection d'erreurs et le contenu des messages correspondants
144
- une subdivision, s'il y a lieu, correspondant une frquence d'utilisation. Les paramtres propres l'application se divisent en paramtres provenant de la procdure qui se traduisent sous la forme de commandes activables par l'utilisateur et de paramtres provenant des oprations qui se traduisent en donnes. Pour les commandes spcifiques l'application, il faut prvoir: - une hirarchie de l'ensemble de ces commandes qui reflte la logique d'utilisation - une prsentation des commandes (menu droulant, glissant, fixe) et une forme de caractres avec ventuellement une deuxime forme pour distinguer les commandes activables des autres (menu dynamique) - la dnomination de ces commandes en utilisant au maximum le vocabulaire et les abrviations des spcialistes s'ils existent. - le mode de dsignation et la syntaxe - le contenu des messages d'erreurs qui peut tre trs variable selon que l'on dcide ou non de distinguer les erreurs d'intention des erreurs d'excution. La traduction des oprations amne la dfinition des lments suivants: - la prsentation de la zone de dialogue avec la distinction des zones d'entre (saisie de l'utilisateur) et des zones de sortie (rponse de l'ordinateur) - le vocabulaire des donnes issu du vocabulaire des spcialistes - la syntaxe de fin de saisie de donnes et de validation de zones ou d'crans - le contenu des messages d'erreur en fonction des erreurs que l'on a choisi de dtecter et des possibilits de correction. La traduction de l'ensemble des paramtres que nous venons d'numrer doit se faire en tenant compte d'une part des critres ergonomiques, d'autre part des possibilits techniques, comme nous allons le dtailler dans les deux paragraphes suivants. 5.2.2.2 Prise en compte des critres ergonomiques Nous distinguons les critres ergonomiques caractre gnral des lments ergonomiques provenant de l'tude de l'existant, c'est-dire propres l'application. Le premier critre intgrer la Reprsentation Externe est le critre d'homognit qui a des consquences sur trois lments:
145
- la prsentation gnrale des crans, c'est--dire le choix des emplacements des zones de menu, de saisie de donnes, de messages d'erreur, de messages de services, cette prsentation devant tre homogne sur l'ensemble de l'application et si possible avec les autres logiciels existants; - les dispositifs d'entre en distinguant les dispositifs d'entre des donnes de ceux d'entre des commandes et, ventuellement, en distinguant les commandes standard et les commandes particulires; l'entre des commandes standard doit tre homogne sur l'ensemble du logiciel, rapide et facile mmoriser; le dispositif d'entre des commandes particulires doit tre aussi homogne et doit se distinguer sans ambigut du dispositif d'entre des donnes; - la syntaxe du langage de commande, c'est--dire la validation des commandes, des donnes et des crans. Les lments provenant de l'existant se rpartissent en deux ensembles; les premiers ont dj t utiliss au niveau de la conception de la Reprsentation Conceptuelle: il s'agit de la rpartition du pilotage entre l'homme et la machine et de la logique d'utilisation; les seconds sont intgrables uniquement au niveau de la Reprsentation Externe et il s'agit: - du vocabulaire des spcialistes qui sert dterminer le vocabulaire des donnes et des commandes quand cela est possible, c'est--dire quand il y a correspondance entre les opration existantes et les oprations cres par l'automatisation; - de la prsentation des formulaires ou des crans existants dans la mesure o il n'y a pas de modifications du systme d'information existant; - des erreurs dtecter et des possibilits de correction qu'il y a faire compte-tenu des impratifs de fiabilit de l'application et des types d'erreurs usuels commis. 5.2.2.3 Prise en compte des possibilits techniques La dtermination de la Reprsentation Externe est elle aussi fortement dpendante des possibilits matrielles et logicielles des ordinateurs sur lesquels se fait la ralisation. Sur le plan matriel, il y a deux contraintes: - la dfinition de l'cran qui donne la limite du nombre de caractres aisment lisibles par l'utilisateur et les possibilits graphiques;
146
- les dispositifs physiques d'entre (clavier, souris,...) qui offrent plus ou moins de choix pour distinguer par exemple les commandes des donnes. Sur le plan logiciel, la contrainte essentielle tient au type de logiciel de gestion d'cran qui impose des contraintes trs fortes sur la prsentation gnrale et particulire de l'interaction ainsi que sur les possibilits de commandes standard comme l'interruption. Cet lment a t dvelopp dans les chapitres 3 et 4. La conception de la Reprsentation Externe ne peut se faire de manire linaire en intgrant d'abord la Reprsentation Conceptuelle, puis les critres ergonomiques, puis les possibilits techniques; ces trois lments doivent tre intgrs simultanment pour la conception de chacun des paramtres de la Reprsentation Externe. Nous avons visualis ces interactions dans le schma suivant.
147
Conception de la RE (synthse)
Reprsentation conceptuelle Paramtres standard Reprsentation externe Vocabulaire Prsentation Commandes Syntaxe Mode de dsignation Paramtres propres l'application 1 - Procdure Messages d'erreur Menu dynamique Rpartition du pilotage Logique d'utilisation Vocabulaire des spcialistes Homognit Critres ergonomiques Possibilits techniques Dfinition de l'cran (matriel) Mono ou multifentrage (logiciel) Clavier/souris Mono ou multifentrage
Hirarchie du menu Vocabulaire du menu Prsentation du menu Syntaxe du menu Mode de dsignation Messages d'erreur
Logiciel de base (menu droulant, glissant, fixe ...)
Homognit Clavier/souris Mono ou multifentrage Erreurs dtecter Formulaires Dfinition de l'cran Logiciel de base
2 - Oprations
Prsentation du dialogue
Vocabulaire des donnes Syntaxe
Vocabulaire des spcialistes Homognit Erreurs dtecter
Messages d'erreur Correction

148
Mono ou multifentrage
5.3 Prototypage
L'objectif de cette tape est de montrer comment faire des tests auprs des utilisateurs sur le logiciel conu et ralis dans les trois tapes prcdentes. Si la ralisation a abouti directement au logiciel dfinitif, les modifications conscutives aux tests que nous allons pratiquer dans cette phase risque d'tre coteux en temps de programmation. Aussi est-il prfrable, quand cela est possible, de procder aux tests sur des versions du logiciel non dfinitives, c'est--dire sur des maquettes ou des prototypes. Nous appelons maquette une simulation partielle du logiciel; certains outils de gnie logiciel engendrent automatiquement des maquettes qui permettent par exemple de simuler l'enchanement des crans. Les maquettes sont surtout utiles l'analyste car elles lui permettent de visualiser les consquences des spcifications qu'il vient de faire, mais elles sont d'un intrt limit pour des tests auprs des utilisateurs car trop loignes du logiciel dfinitif. Nous appelons prototype un logiciel qui possde toutes les fonctionnalits du logiciel dfinitif, mais sans souci de performances (optimisation des temps de rponse et de la place mmoire). Les prototypes peuvent tre gnrs automatiquement par un outil de gnie logiciel ou crits directement avec un langage d'intelligence artificielle (PROLOG, SMALLTALK,...). Les prototypes correspondent une version du logiciel dfinitif raliste qui permettent de raliser efficacement des tests auprs des utilisateurs, puis de le modifier un moindre cot. Cette tape de tests auprs des utilisateurs n'est pas encore couramment pratique en informatique, mais dans le cas de logiciels interactifs elle est indispensable car plusieurs lments de la Reprsentation Externe ne peuvent tre dtermins en l'absence de l'utilisateur.
5.3.1 Elments tester

Les lments tester sont d'une part des lments simples pour lesquels il n'y a pas de critres ergonomiques d'autre part l'interaction d'lments simples dont l'effet est a priori non prvisible. Elments simples Il s'agit ici de tester tous les lments de la Reprsentation Externe qui n'ont pas pu tre dfini partir de critres ergonomiques:
149
- le vocabulaire qui n'est pas inspir du vocabulaire des spcialistes; c'est gnralement le cas du vocabulaire de commandes correspondant des oprations propres l'ordinateur ou de nouvelles oprations qui n'existaient pas; - la prsentation des zones de saisie de donnes nouvelles qui ne correspondent pas des formulaires ou des crans existants; - la logique d'utilisation pour des tches nouvelles ou profondment modifies par l'automatisation; - les procdures effectives mises en oeuvre par les utilisateurs sur les nouveaux logiciels. Interaction d'lments simples Nous avons prsent au chapitre 3 des critres ergonomiques pour chacun des paramtres de la Reprsentation Externe, mais quand on veut appliquer l'ensemble de ces critres sur une application particulire avec des possibilits techniques particulires, on est amen faire des choix, des compromis qui n'optimisent pas forcment l'ensemble des paramtres. C'est pour pouvoir tester les effets de ces choix qu'une exprimentation sur prototype est galement ncessaire. Nous citons ci-dessous les interactions les plus courantes: - pour la prsentation du dialogue, il peut s'avrer impossible pour des raisons techniques (dfinition de l'cran) de suivre la mise en page des formulaires existants; on doit alors proposer une prsentation des donnes cohrente avec un ordre "standard" de saisie et l'exprimenter; - pour le mode de dsignation, il peut y avoir incompatibilit entre le critre d'homognit et les possibilits techniques des dispositifs d'entre. Par exemple, on peut tre limit par le nombre de touches-fonctions disponibles par rapport au nombre de commandes standard ou propres l'application; il faut alors choisir de faon arbitraire les commandes qui seront actives par touche-fonction (de prfrence les commandes standard) et choisir galement un autre mode de dsignation pour les autres commandes; - il peut y avoir incompatibilit entre la hirarchie du menu et sa prsentation; en effet, la hirarchie du menu doit reflter la logique d'utilisation et la prsentation du menu est dpendante des possibilits techniques et doit tre homogne sur l'ensemble des logiciels. Pour une application particulire, on peut avoir un niveau du menu pou lequel les libells des commandes correspondantes soient en nombre suprieur la capacit de la zone de prsentation du menu.
150
Il faut alors choisir entre la modification de la prsentation du menu et la modification de la hirarchie de ce menu; - le mode de dsignation peut impliquer des contraintes pour le choix du vocabulaire des commandes. En effet, si la dsignation n'est pas directe (saisie de la commande au clavier), il faut prvoir une abrviation de cette commande. Cette abrviation doit tre l'application d'une rgle mnmonique sur les noms de commande; les noms de commandes sont par ailleurs choisis soit dans le vocabulaire des spcialistes, soit pour leur nonambigut. Il n'est pas vident qu'en appliquant la rgle d'abrviation sur ces noms, on obtienne des abrviations toujours diffrentes. Dans ce cas, il faut choisir entre modifier le vocabulaire des commandes ou modifier la rgle d'abrviation.
5.3.2 Comment tester

On peut procder des tests "en laboratoire" ou des tests "sur le terrain". Les tests en laboratoire sont surtout utiles sur une premire version du prototype pour en liminer les dysfonctionnements les plus criants, mais les tests sur le terrain sont plus rvlateurs. Cependant ces derniers ne sont pas toujours possibles car ils peuvent s'avrer perturbants pour le milieu de travail. Si cela est possible, il est intressant de procder des tests deux moments: tout d'abord en dbut d'utilisation, puis un ou deux mois aprs le dbut de l'utilisation. Les tests de dbut permettent surtout de tester les facilits d'apprentissage alors que les tests ultrieurs permettent de tester le facilits d'utilisation pour des utilisateurs expriments. Les tests sont obligatoirement longs pour l'analyste car il n'est pas possible de procder de simples entretiens comme dans le cas de l'tude de l'existant. En effet, au cours d'un entretien, l'utilisateur fait une reconstruction mentale du travail qu'il a effectu et cette reconstruction a tendance gommer ou survaluer les erreurs qu'il commet et les difficults qu'il rencontre. Les seuls moyens de tests fiables dans ce contexte sont les observations et les capteurs (les autorelevs tant trop coteux en temps utilisateur).
151
Les capteurs sont particulirement bien adapts aux tests sur prototype car ils peuvent tre rajouts au logiciel du prototype sans fausser le cours normal de l'excution du travail de l'utilisateur. Le capteur le plus simple consiste en la mmorisation systmatique de l'ensemble des transactions effectues entre l'utilisateur et le logiciel. Mais ce type de capteur fournit une masse d'informations difficile synthtiser; aussi est-il souvent plus judicieux de faire des capteurs plus slectifs portant sur les lments qu'il nous semble prioritaire de tester, ce qui facilite les synthses ultrieures. La phase de tests partir de capteurs peut tre prcde ou suivie d'observations par un tiers ou par l'analyste. Les observations faites avant permettent de dgager les lments sur lesquels il sera ncessaire de faire des tests au moyen des capteurs. Dans tous les cas, les observations permettent de dgager des faits qui ne peuvent tre enregistrs par capteurs; c'est le cas par exemple de toutes les consultations d'informations hors logiciels effectues par les utilisateurs. Ces observations peuvent tre compltes par des entretiens portant sur certains faits observs et difficiles interprter; il peut tre utile de savoir pourquoi telle information a manqu un moment particulier.
5.4 Etude de cas "Bibliothque"

"Bibliothque" est une tude complte qui part de la description du systme d'information existant selon MERISE pour aboutir la reprsentation externe correspondant une opration donne . Le but essentiel tant d'illustrer les mthodes prsentes dans l'ouvrage, l'exemple a t choisi volontairement simple et n'exige du lecteur aucune comptence technique particulire dans le domaine de la documentation, hormis la connaissance du concept de thesaurus . Thesaurus : liste alphabtique de mots-cls relis par des liens smantiques (synonymie, homonymie, hirarchie...) ; permet de rechercher un ouvrage non seulement par le titre ou l'auteur, mais aussi partir de mots-cls . Nous prsentons d'abord la description du systme existant avec le formalisme MERISE, puis la conception du nouveau systme.
152
5.4.1 Le systme d'information existant

5.4.1.1 Les fonctions Les schmas qui suivent dcrivent en dtail le systme d'information existant, selon une classification en fonctions.
Systme d'information existant Fonction 1: gestion du fonds Fonction 2 : gestion des prts
Perte
Fig 1.1 On distingue, dans l'existant, deux grandes fonctions (figures 1.3 et 1.4): - gestion du fonds documentaire (commander et enregistrer les livres ...) - gestion des prts de livres aux abonns (rechercher les ouvrages, enregistrer les prts ...) . Cette distinction revient partager le systme en deux sous-systmes . Le choix du dcoupage se justifie, au sens de la thorie des systmes, par le fait que les inter-relations entre sous-systmes sont ainsi rduites au minimum : les deux fonctions prsentent un seul point d'intersection, matrialis par la circulation d'une fiche en cas de perte d'ouvrage . 5.4.1.2 Utilisateurs Trois types d'utilisateurs sont confronts au systme d'information : - l'administratif intervient dans l'achat et le paiement des livres ; - le documentaliste enregistre et prte les livres ; - l'abonn de la bibliothque consulte et emprunte les livres .
153
Le dcoupage en deux sous-systmes est tel que l'administratif et l'abonn n'ont affaire qu' un des deux sous-systmes alors que le documentaliste intervient dans les deux. Notons que la gestion des prts fait parfois intervenir simultanment l'abonn et le documentaliste . L'interaction entre le dcoupage en fonctions et en postes de travail est prsente sur le schma suivant:
Systme d'information existant Fonction 1: gestion du fonds Fonction 2 : gestion des prts
Administratif Abonn
Perte Documentaliste
Fig1.2
154
Existant Fonction 1 : gestion des fonds

Initiative documentaliste Demande d'abonn documentaliste administratif B.C.E.: bon de commande externe B.C.I.: bon de commande interne
v Commande interne
B.C.I.
Commande externe B.C.E. Facture Arrive livre
Rception livre
Livre
Enregistrement livre Cote Livre cot Paiement /...
Fig 1.3
155
.../
Livre cot
Mise en service Tous les ans, janvier
Livre en service Inventaire perdu abm
Livres absents
Livres restaurer
Consultation prt prt non prt
Restauration
Livre prt
Livre restaur
F2
Fiche perte
Enregistrer perte
Fig 1.3 (suite)
156
Existant Fonction 2 : gestion des prts

Demande prt documentaliste abonn
Consultation du fonds non trouv trouv Demande prt
Demande prt
Emprunt autre bibliothque succs chec
Consultation des prts non prt prt
Livre
Refus
Demande prt
Refus
Prt
Recherche rayon prsent absent
Livre Demande prt Restitution la bibliothque Enregistrement prt F1 Fiche de perte
Livre prt Enregistrement retour livre Relance
Livre rang
Lettre
157
Fig 1.4
Nous montrons titre d'exemple une seule procdure minimale du systme existant car les procdures minimales du systme existant et du nouveau systme sont trs proches et ne se diffrencient que par l'indication des oprations interactives et automatiques dans le nouveau systme.
Existant Procdure minimale administratif But : gestion des achats de livres
B.C.I.
Commande externe
Facture
B.C.E.
Cote du livre
Paiement o
5.4.2 Conception du nouveau systme

5.4.2.1 Conception de la Reprsentation Conceptuelle Nous prsentons les lments suivants: - le schma de la base de donnes selon le formalisme entit-relation de MERISE (figure 1.6)
158
v B.C.E.: bon de commande externe B.C.I.: bon de commande interne Fig 1.5
- la procdure prvue de l'abonn, dcrite par la figure 1.9 - les procdures minimales pour tous les postes de travail: la procdure minimale de l'administratif est dcrite par la figure1.7 et celle de l'abonn par la figure 1.8. Pour le documentaliste, il y a trois procdures minimales correspondant trois buts diffrents de ce poste de travail ; elles sont dcrites par les figures 1.10 1.14; - une procdure effective du poste du documentaliste pour deux buts diffrents (gestion du fonds propre et gestion des prts), dcrite par les figures 1.15 et 1.16 - le dtail d'une opration (enregistrement prt), dcrit par la figure 1.18. Schma de la base de donnes
Abonn numro abonn nom, prnom adresse type profil nombre d'avertissements Prt interne numro abonn cote date d'emprunt dernire date d'avertissement nombre d'avertissements Livre cote titre auteurs nombre de pages langue mots-cls date perte
Prt externe date emprunt
Emprunt numro bibliothque bibliothque cote livre emprunt titre date d'emprunt
Fig 1.6
Choix des paramtres constants Nous choisissons de mettre en oeuvre les paramtres constants minimum concernant l'aide l'utilisateur; ce sont les possibilit d'interrompre, de quitter, d'annuler et de tranfrer. En consquence, tous les schmas qui suivent doivent tre interprts en fonction de ce choix.
159
Nouveau systme Procdure minimale administratif
But : gestion des achats de livres
B.C.I.
Commande externe
Facture
B.C.E.
Cote du livre
Paiement o
v B.C.E.: bon de commande externe B.C.I.: bon de commande interne Fig 1.7
160
Nouveau systme But : emprunt de livres Procdure minimale abonn
Enregistrement prt
Consultation du fonds o
Fiche prt Consultation thesaurus Fig 1.8 f
Procdure prvue abonn
Consultation du fonds trouv
f non trouv
Livre
Enregistrement prt o
Fiche prt
Fig 1.9
161
Nouveau systme Procdure minimale documentaliste But 1: gestion du fonds propre
Initiative documentaliste
Demande d'abonn
Consultation du fonds
v Commande interne
Consultation B.C.I.
B.C.I.
(B.C.I.: bon de commande interne)
Consultation prt Livre
Enregistrement livre o
Dtails de cette opration fig 1.11
Livre cot
Liste inventaire
Livres abms
Enregistrement perte o Fiche perte Fig 1.10

162
Livres restaurer o
Liste
Remarques sur la figure 1.9 La prcdence entre les oprations "Consultation du fonds" et "Enregistrement prt" est une prcdence facultative (indique en pointill) car elle ne figure pas dans la procdure minimale de l'abonn. Ici, elle engendre un enchanement automatique car il n'y a pas de dclenchement par l'utilisateur de l'opration "Enregistrement prt". Cette prcdence modifie l'opration "Enregistrement prt" en ce sens qu'il y a un transfert automatique des donnes dcrivant le livre consult, ce qui minimise la saisie de la part de l'abonn. L'opration "Enregistrement prt" de la procdure abonn diffre de celle du mme nom de la procdure documentaliste par le fait qu'il y a mission d'une fiche prt qui sert retirer le livre de la bibliothque.
Remarques sur la figure 1.10: Il n'y a pas de prcdence permanente entre les oprations "Commande interne " et "Enregistrement" car il y a des livres qui parviennent la bibliothque sans avoir t commands. Les oprations "Consultation B.C.I" et "Consultation prt" ont t rajoutes (par rapport la description de la fonction1) car elles peuvent tre utiles la prise de dcision.
Dtail de l'opration "Enregistrem livre" ent

Livre
Enregistrement bases du livre
Consultation du thesaurus
Enregistrement mots-cls du livre
o Fig 1.11
Modification du thesaurus
163
Procdure minimale documentaliste(suite) But 2 : gestion des prts

Demande utilisateur
Enregistrement abonn o Livre demand Numro d'abonn
Livre prt Livre rendu
Enregistrement livre rendu
Relance o o
Consultation du fonds (dtail ci-aprs)
Consultation prt
Consultation B.C.I.
f Fig 1.12
164
Consultation du thesaurus
Dtail de l'opration "Consultatio du fonds" n
Recherche sur cote
Recherche sur mots-cls f f Fig 1.13
Recherche sur auteurs
165
Procdure minimale documentaliste(suite) But 3 : gestion des changes avecles autres bibliothques
Demande abonn
Enregistrement demande de prt
Lettre Livre bibliothque Refus
Enregistrement livre prt
Annulation demande o
Avertir abonn o Demande abonn Livre rendu
Lettre Enregistrement livre rendu o
Prt du livre externe o
Livre renvoyer
Consultation demande f Fig 1.14

166
Consultation prt f
Nouveau systme Procdure effective documentaliste But 1: gestion du fonds propre

Sous-but 1 : achat de livres Sous-but 3 : perte de livres Livre non trouv
Commande interne
Consultation B.C.I. trouv
f non trouv
Enregistrement perte
Message
Consultation prt B.C.I. non prt prt
B.C.I. : bon de commande interne Sous-but 2 : enregistrement de livres (trait au chapitre 2) Fig 1.15 perte Message
Remarques sur la figure 1.15 Pour minimiser le travail du documentaliste, l'opration "Consultation B.C.I" devient automatique quand le documentaliste dclenche l'opration "Commande interne". De mme, l'opration "Consultation prt" est excute automatiquement la suite de l'activation de l'opration "Enregistrement perte".
167
Nouveau systme Procdure effective documentaliste But 2 : gestion des prts
Consultation du fonds non trouv trouv
Consultation prt trouv f non trouv
Enregistrement abonn
Livre rendu
Livre prt Enregistrement prt o Dtails fig 1.18, 1.19, 1.20
Enregistrement Consultation livre rendu B.C.I. fo
Relance o
Fig 1.16
168
Reprsentation conceptuelle de l'opration "Enregistrement prt"

Procdure prvue
E 2.1
Saisie numro abonn existe o n'existe pas
E 2.1
Affichage nom prnom type profil o
Affichage message d'erreur o
E 2.2
E 2.1
Saisie numro livre o existe n'existe pas
E 2.1
Affichage date emprunt, titre auteurs, validation
Message d'erreur o
E 2.3
E 2.1
Saisie validation valid
o non valid
U : initiative utilisateur E : cran ou fentre
Fig 1.17
169
Remarques sur la figure 1.17 Cette figure dcrit en dtail l'opration "Enregitrement prt" en descendant au niveau de dtail le plus lev que l'on peut atteindre avec ce formalisme (saisie d'une rubriquepar l'utilisateur). Le symbole "U" (initiative utilisateur) signifie que l'on passe le contrle de la procdure l'utilisateur qui peut alors activer soit une des commandes standard sa disposition (remonter, quitter, annuler,...), soit une commande de la procdure activable ce moment l. L'utilisation de ce symbole a l'avantage de simplifier le schma puisqu'il n'oblige plus dire tout ce qui est possible ; par contre, il peut tre complt en commentaires par la liste de ce qui est interdit, c'est--dire les oprations non activables un moment donn. La liste des commandes activables par l'utilisateur un moment donn doit tre visible pour l'utilisateur dans le menu (paramtres dfinis dans la Reprsentation Externe). Un enchanement automatique (pas de dclenchement utilisateur) se traduit ce niveau de dtail par un positionnement automatique du curseur sur l'cran. Si on voulait le faire figurer dans le schma de description de cette opration, il faudrait supprimer les dclenchements de l'utilisateur des oprations "Saisie numro abonn", "Saisie numro livre", "Saisie validation". 5.4.2.2 Conception de la Reprsentation Externe Nous prsentons une description de l'cran standard dans les figures 1.18 et 1.19 puis la Reprsentation Externe de l'opration "enregistrement prt" (dcrite ci-dessus) dans les figures 1.20 et 1.21.
170
Ecran standard Services Aide Prter Consulter Chercher Abonner
Visualisation opration interrompue Fig 1.18 Visualisation du contenu des menus droulants Services Copier Insrer Annuler Diffrer Quitter Aide Instances Transactions Profil Guidage buts Guidage commandes Prter Sortie Entre Relance Consulter Prts B.C.I. Abonns Chercher Cote Mots-cls Auteurs Abonner Liste abonns Enregistrement
Visualisation opration interrompue Fig 1.19
171
Ecran E 2.1
Services Abonn Numro Nom Adresse Type Profil ******************** **************************************** ** ** Aide Prter Consulter Chercher Abonner
Livre emprunt Cote Date d'emprunt ****** Titre Auteurs **************************************** ******************** Validation Visualisation opration interrompue Complt par l'utilisateur Fig 1.20 * Complt par la machine
Remarques sur la figure 1.20 Dans la description de l'cran, nous distinguons visuellement les donnes qui sont saisies par l'utilisateur des donnes affiches par l'ordinateur. Fentre E 2.2 Abonn inexistant !
!
Fentre E 2.3 Cote inconnue !
LU
!
LU Fig 1.21
172
Remarques sur la figure 1.21 Le terme LU signifie que l'utilisateur doit "cliquer" sur ce terme pour indiquer qu'il a lu le message d'erreur. si il n'y avait qu'un choix possible pour l'utilisateur aprs une erreur, il serait plus judicieux de l'indiquer directement dans la fentre contenant le message d'erreur comme nous l'indiquons ci-dessous (l'utilisateur doit "cliquer" sur les "boutons" permettant de slectionner les commandes ANNULER ou QUITTER).
!
Annuler
Abonn inexistant ! Quitter
173
Chapitre 6 : DIANE METHODE DE DIAGNOSTIC

Ce chapitre s'adresse plus particulirement aux personnes qui se situent l'extrieur du processus de conception, tel que nous venons de le dcrire au chapitre 5, mais qui peuvent intervenir sur celui-ci en particulier pour amliorer la communication homme-machine. Il peut s'agir du correspondant informatique, d'un ergonome, d'un conseiller extrieur l'entreprise ou d'un utilisateur. Ce chapitre comprend trois parties . Dans la premire partie, nous indiquons comment procder aux tests d'un logiciel existant; dans la deuxime partie comment faire un cahier des charges permettant de spcifier les caractristiques du logiciel amlior et dans la troisime partie, nous exposons une tude de cas portant sur le diagnostic d'un logiciel existant.
6 . 1 Diagnostic interactif
6.1.1 Dmarche
d'un
logiciel
Pour faire le diagnostic d'un logiciel existant, on dispose gnralement de deux sources d'informations: d'une part les dossiers d'analyse et de programmation, d'autre part le logiciel luimme tel qu'il a t ralis. Les dossiers d'analyse et de programmation correspondent respectivement la Reprsentation Conceptuelle et la Reprsentation Interne. Le logiciel ralis correspond essentiellement la Reprsentation Externe, mme si on peut galement y voir des lments de la Reprsentation Conceptuelle traduits en Reprsentation Externe et un lment de la Reprsentation Interne, le temps de rponse. Le dossier d'analyse peut fournir des indications intressantes concernant le schma de la base de donnes, la hirarchie du menu, l'enchanement des oprations et, ventuellement, les dessins
174
d'cran; le dossier de programmation indiquera les types de contrle d'erreurs effectus et le dtail des entres/sorties. Mais le diagnostic ne peut en aucun cas tre ralis uniquement au vu des dossiers d'analyse et ventuellement de programmation. En effet, ces dossiers sont rarement complets car de nombreux dtails se rglent souvent au stade de l'criture des programmes; de plus, ils peuvent tre erronns par le fait que des options prises au niveau de l'analyse n'ont pas t respectes au niveau de la ralisation. Aussi, dans tous les cas, les lments pertinents pour la communication homme/machine que nous relevons dans ces dossiers devront tre tests sur le logiciel ralis. Le diagnostic est possible mme si nous ne disposons que du logiciel ralis car il est possible de recomposer les lments des dossiers d'analyse et de programmation qui nous intressent en examinant le logiciel ralis mme si cette procdure peut s'avrer plus longue. L'essentiel de notre expos porte sur l'examen du logiciel car, comme nous venons de le voir, c'est un passage oblig pour notre tude. La mthode la plus efficace consiste procder en deux tapes: - tout d'abord, on teste soi-mme le logiciel sur les critres que nous dcrivons dans la grille d'analyse ci-aprs; ces tests permettent de dgager une grille d'observation , - ensuite, on effectue des observations sur des utilisateurs du logiciel partir de la grille d'observation labore prcdemment. Dans les deux cas, on doit procder des recopies d'cran systmatiques en cours de tests pour pouvoir recomposer ultrieurement les squences suivies et s'assurer que l'ensemble du logiciel a t test; c'est pour cela que la confrontation avec le dossier d'analyse peut s'avrer fructueuse.
6.1.2 Grille d'analyse

Cette grille d'analyse repose en grande partie sur les paramtres de l'interface vus par l'ergonome (voir chapitre trois) ; cette approche permet effectivement de tester les possibilits de communication avec un logiciel d'un point de vue extrieur sa conception. Pour chaque cran , on observe les paramtres suivants: - vocabulaire La premire question qui se pose est de savoir si le vocabulaire utilis, que ce soit pour nommer les commandes et les donnes ou
175
pour les messages de services ou d'erreurs est ambigu pour l'utilisateur; ces ambiguts se traduisent, soit par des erreurs systmatique des utilisateurs, soit par une sous-utilisation des possibilits du logiciel. Dans tous les cas, l'utilisateur a des difficults mmoriser ce vocabulaire. La deuxime question concerne les abrviations qui, si elles existent, doivent tre mnmoniques: l'utilisateur doit pouvoir trouver une rgle simple lui permettant de passer du mot complet son abrviation; l aussi, l'homognit de l'application de cette rgle est essentielle. - syntaxe Le premier lment tester est l'homognit: des actions identiques de la part de l'utilisateur (quand elles sont autorises) ont des effets identiques sur le programme; inversement, une mme action de l'ordinateur est toujours active par la mme commande; ceci doit tre vrifi sur l'ensemble des crans. Le deuxime lment est la simplicit du point de vue de l'utilisateur. Si ces deux lments ne sont pas respects, l'utilisateur ne pourra pas dvelopper d'automatismes, ce qui se traduira au mieux par une lenteur d'excution et au pire par des erreurs de manipulation. - dispositifs d'entre Les observations d'erreur lies strictement au dispositif d'entre sont assez rares maintenant, car les dispositifs d'entre en informatique des organisations sont peu nombreux (clavier, souris,...) et assez standardiss. Par exemple, toutes les marques d'ordinateur proposent aujourd'hui des claviers AZERTY alors que le clavier QWERTY est, en France, une source continuelle d'erreurs pour des utilisateurs familiariss aux normes franaises. Par contre, d'autres lments du clavier (touches-fonctions...) et les "souris" ne sont pas normalises, ce qui peut tre une source d'erreurs aisment observable. - dispositifs de sortie Nous ne parlons pas ici des caractristiques matrielles des crans (bien qu'elles jouent un rle essentiel dans la fatigue visuelle) car elles ne relvent pas de l'ergonomie du logiciel et donc de notre marge de manoeuvre concernant le logiciel. La premire chose observer est la lisibilit gnrale qui se traduit par un cran qui n'est pas surcharg d'informations, avec des zones distinctes pour des objets informationnels distincts, de manire que
176
la structure de l'cran apparaisse clairement la suite d'un parcours visuel rapide. La deuxime chose observer est l'homognit de la prsentation entre les diffrents crans de mme type (crans de menus, crans de saisie, crans d'explication,...). Par exemple, le nom de l'opration que l'on est en train d'excuter doit toujours apparatre au mme endroit de l'cran et avec le mme graphisme. Une prsentation gnrale surcharge ou non homogne engendre lenteur de lecture et fatigue . Puis, nous examinons plus en dtail chaque zone de l'cran pour savoir si elles sont pertinentes ou non pour l'utilisateur; inversement, nous regardons si toutes les donnes pertinentes au niveau de cet cran y figurent. La pertinence des zones peut tre longue tester et demande une connaissance approfondie du travail ou des observations. - temps de rponse L'observation des temps de rponse est simple et leur acceptabilit obit des rgles simples dveloppes au chapitre 3. Il faut vrifier que pour des temps de rponse suprieur quatre secondes, un message d'information apparat. Dans le cas o le logiciel se dconnecte au bout d'un certain temps de non utilisation, il faut vrifier que ce laps de temps est compatible avec la nature de la tche entreprise. Par exemple, une tche de type dcisionnel s'accompagne de dlais de rponse plus long de la part de l'utilisateur. - logique d'utilisation Pour les crans de menu, on peut vrifier si l'ensemble des commandes prsent sur un cran suit une logique d'utilisation c'est-dire si l'utilisateur y trouve un ensemble cohrent du point de vue de la ralisation de sa tche. Ce critre est repris un niveau plus global avec l'enchanement des crans. - traitement des erreurs Le premier lment tester est la capacit du logiciel percevoir les erreurs de l'utilisateur. Pour cela, il faut dans un premier temps imaginer un ensemble d'erreurs possibles, puis complter si ncessaire par des observations. Le deuxime test porte sur l'intelligibilit du message d'erreur et sa pertinence par rapport l'erreur commise. Le troisime test porte sur les possibilits et les facilits offertes pour rectifier les erreurs.
177
L'ensemble des tests sur les erreurs constitue un travail important de la part de l'intervenant et des utilisateurs mais il est crucial pour la qualit du logiciel. - aide Il faut identifier les diffrents types d'aide offerts l'utilisateur (explicitation de commandes, explicitation de procdures, infrences) et pour chaque type d'aide procder aux vrifications suivantes. La premire vrification concerne la possibilit d'tre guid tout moment de l'utilisation du logiciel. La deuxime vrification porte sur la cohrence des explications avec les faits: il faut vrifier si les explications caractre gnral sur les commandes correspondent bien la ralit du comportement du logiciel dans tous les cas. Pour les enchanements d'cran, il faut tester les lments suivants: - l'arborescence du menu Il faut vrifier que l'ensemble de l'arborescence du menu correspond bien une logique d'utilisation, c'est--dire que les commandes regroupes un certain niveau correspondent bien un ensemble de commandes qui ont un rapport entre elles du point de vue du travail de l'utilisateur. Si les enchanements d'cran sont automatiques, il faut s'assurer que ce fait constitue une aide pour l'utilisateur et non pas une gne; inversement, il faut essayer de dtecter si certains enchanements d'cran ne devraient pas devenir automatiques. Si les interruptions d'oprations ne sont pas permises par le systme, il faut vrifier que l'on peut naviguer aisment entre les oprations que l'on a besoin d'utiliser en parallle comme, par exemple, "consulter" avant ou aprs "enregistrer". Les tests sur ces lments peuvent tre simuls par l'intervenant, mais il est indispensable qu'ils soient raliss avec des utilisateurs. - les commandes standard d'enchanement Il faut vrifier que les commandes standard d'enchanement entre crans comme "sortie", "aide",etc..., sont disponibles tout moment et produisent toujours les mmes effets! Si certaines commandes ne sont pas excutables dans certaines parties du programme, elles doivent tre signales l'utilisateur;
178
inversement, on doit indiquer les commandes standard disponibles chaque moment. - l'homognit entre crans Nous devons vrifier que la syntaxe, les dispositifs d'entre et la prsentation de l'cran (dispositif de sortie) sont homognes sur l'ensemble du logiciel et mme sur l'ensemble des logiciels manipuls par les diffrents postes de travail. Pour permettre un diagnostic plus ais sur l'enchanement des crans, on peut reprsenter ces enchanements sous la forme d'un automate d'tats finis comme le propose la mthode Use (Was, 82) avec les conventions suivantes: - les tats (visualises par des cercles) reprsentent les crans ou les fentres ou les lignes selon le mode d'interaction minimum entre l'homme et la machine. - les transitions (visualises par des flches) reprsentent les actions de l'utilisateur permettant de basculer d'un tat l'autre. Nous prsentons ci-aprs un exemple de ce formalisme:
Exemple d'enchanement d'crans

RETOUR
E0
RETOUR
E5 3+ ENVOI
1+ ENVOI E1 2+ ENVOI
AIDE RETOUR
E2 F+ ENVOI F+ ENVOI
E4
E3
179
Si l'on veut que ce type de schmas reste lisible, il est la plupart du temps impossible de faire figurer sur un mme schma l'ensemble des transitions possibles. Aussi, en pratique, on ralise un premier schma "descendant" o on visualise les enchanements en partant du premier cran vers tous les autres; puis on fait un ou plusieurs autres schmas pour reprsenter toutes les autres transitions possibles (quitter, aide,...). Des exemples de ces schmas sont donns dans l'tude de cas RTR prsent dans la troisime partie de ce chapitre. Dans le tableau de synthse ci-dessous, nous rappelons l'ensemble des lments tester et pour chacun d'eux nous indiquons quels types de tests doivent tre pratiqus avec les utilisateurs en plus d'une exprimentation directe par l'intervenant.
180
Grille d'analyse d'un logiciel (synthse)

Paramtres Pour chaque cran : Vocabulaire - ambigut - rgles d'abrviation - mmorisation - erreurs - erreurs - rapidit d'excution - mmorisation Elments de test Tests sur utilisateur
Syntaxe
- homognit - simplicit
Dispositifs d'entre
- homognit par rapport aux autres matriels utiliss - lisibilit de l'cran - homognit de la prsentation - pertinence des zones - dlai - message d'attente - erreurs dtectes - lisibilit des messages - possibilits de rectification d'erreurs - type d'aide - accs tout moment - cohrence du logiciel
- erreurs
Dispositifs de sortie
- lenteur d'excution - fatigabilit
Temps de rponse Traitement des erreurs
- gne - fiabilit des traitements - ralentissement du travail - dtournement des procdures - facilit d'apprentissage - facilits d'utilisation
Aide
Entre crans : - syntaxe - dispositifs d'entre - prsentation de l'cran - mmorisation - dveloppement d'automatismes - difficults d'utilisation - lenteur
Homognit
Arborescence du menu
- logique d'utilisation - accs tout moment aux commandes standard - effets homognes de ces commandes
Commandes d'enchanement
- lenteur l'excution - difficults de mmorisation
181
6 . 2 Cahier des charges logiciel interactif
d'un
Dans cette tape, nous prsentons un canevas de cahier des charges du logiciel destination des informaticiens responsables de la ralisation du logiciel. L'objectif de ce cahier des charges est de traduire les observations que l'on vient de faire sur le logiciel en spcifications oprationnelles pour les informaticiens. On peut, ce sujet, remarquer qu'il est possible de faire un cahier des charges pour un logiciel interactif uniquement partir de la Reprsentation Externe, c'est--dire en partant du point de vue de l'utilisateur; les informaticiens se chargeant alors d'laborer une Reprsentation Conceptuelle et une Reprsentation Interne compatibles avec cette Reprsentation Externe. Ce cahier des charges se prsente comme un cahier des charges classique de logiciel informatique auquel on rajoute un ensemble de spcifications propres l'interaction homme-machine. C'est ce dernier aspect que nous dveloppons ci-dessous. Nous rappelons qu'un cahier des charges classique comprend l'ensemble des spcifications concernant les donnes (rubriques, accs, volumes,...) et les traitements (algorithmes, scurit, confidentialit,...). Nous rajoutons ces spcifications celles concernant les Reprsentations Externes (ou vues externes) des diffrents postes de travail concerns par le logiciel. Il est tout fait inutile de donner des spcifications concernant la Reprsentation Interne car cela relve de la comptence et de la responsabilit de l'informaticien qui doit concevoir cette Reprsentation Interne de manire ce qu'elle puisse satisfaire les spcifications de la Reprsentation Externe. On ne donne pas non plus de spcifications directes concernant la Reprsentation Conceptuelle mais la Reprsentation Externe contient des paramtres provenant de la Reprsentation Conceptuelle comme les enchanements d'crans ou la rpartition du pilotage entre l'homme et la machine. Les spcifications concernant la Reprsentation Externe se subdivisent en deux sous-ensembles; le premier concerne les spcifications caractre gnral, le deuxime les spcifications propres l'application et chaque poste de travail.
182
6.2.1 Spcifications gnrales

L'objectif de ces spcifications est de fournir un cadre gnral de ralisation du logiciel permettant de crer une homognit maximale l'intrieur du logiciel et avec les logiciels existants s'il y a lieu. Ces spcifications doivent porter sur les paramtres suivants: - les commandes standard qui doivent tre actives (sauf exceptions) sur l'ensemble du logiciel. Il s'agit des commandes d'aide l'utilisation que nous avons prsentes dans les chapitres 2 et 3; les commandes les plus usuelles concernent les possibilits de quitter, d'annuler, de revenir en arrire, d'interrompre. Il vaut mieux spcifier galement le vocabulaire de dsignation de ces commandes et les abrviations, surtout s'il existe dj des logiciels les utilisant, afin que ce vocabulaire reste identique et n'entrane pas d'ambigut smantique chez les utilisateurs. - la prsentation gnrale des crans qui doit tre identique sur l'ensemble du logiciel et de prfrence compatible avec les logiciels existants. Nous entendons par prsentation gnrale des crans les choix concernant l'emplacement des zones de menu, de saisie de donnes, de messages d'erreur ainsi que la forme visuelle de ces paramtres; dans la forme visuelle, nous dcrivons le type de caractre (gras, italique, surbrillance, couleur,...), la forme des fentres ou des zones, l'impression du fond des zones (motifs, couleurs,...), les conventions de reprsentations (touchesfonctions,...). Le plus simple est de prsenter une ou des images d'cran ou de fentres (selon que l'on a un logiciel de mono ou de multifentrage) avec une reprsentation des diffrentes formes visuelles. - les dispositifs d'entre qui doivent tre galement homognes avec les autres matriels et logiciels existants; ces spcifications portent sur le type de clavier (AZERTY, accentu, mathmatique...) et sur le mode de dsignation des commandes (frappe au clavier, touchefonction, souris,...). - la syntaxe du langage de commande comme la validation des crans ou l'indication de fin de saisie des donnes qui doivent aussi tre homognes. Il faut bien se rendre compte que tout ce qui n'aura pas t spcifi ici a plus de chance d'tre htrogne qu'homogne surtout si la ralisation (ce qui est le cas le plus courant) est confie plusieurs
183
informaticiens. Pour s'en convaincre, il suffit de se reporter l'tude de cas RTR dcrit dans le paragraphe suivant et qui ne constitue pas un cas d'exception.
6.2.2 Spcifications l'application
particulires
Il faut d'abord dfinir les diffrents types de poste de travail concerns par l'application dans la mesure o ces types de postes correspondent des vues externes diffrentes de la mme application (par exemple les postes correspondant diffrents niveaux de responsabilits). Puis, pour chaque poste de travail, on dfinit la ou les Reprsentations Externes; on peut avoir plusieurs Reprsentations Externes pour un poste de travail (correspond aux diffrents types de procdures dfinies au chapitre 2) si on a plusieurs types d'utilisateurs (expriments, novices) ou des utilisateurs ayant des procdures effectives diffrentes. Pour chaque Reprsentation Externe, nous spcifions les paramtres suivants: - la rpartition du pilotage entre l'homme et la machine qui comporte trois aspects; la spcification des enchanements entre crans, les crans et donnes obligatoires ou facultatives saisir et les dclenchements d'crans l'initiative de l'utilisateur ou de l'ordinateur. - l'ensemble des commandes et la hirarchie de ces commandes en menu suivant une logique d'utilisation; les noms de commandes doivent tre spcifis soit quand ils correspondent un vocabulaire spcialis, soit pour tre compatibles avec des commandes de logiciels existants. - les erreurs indispensables dtecter et le contenu des messages d'erreur correspondants; on peut rajouter ventuellement les possibilits de correction d'erreurs (retour-arrire, dfaire,...). - la prsentation des crans de saisie qui doivent correspondre le plus possible des prsentations dj existantes comme les formulaires ou les crans. - le vocabulaire des spcialistes afin qu'il soit utilis dans la dnomination des donnes et ventuellement des commandes.
184
6.3 Etude de cas " RTR"

Le cas RTR (Rseau de Transport par Rail) est inspir d'un cas rel utilis dans le cadre de la tlmatique grand public. Ce cas a pour but d'illustrer la mthode permettant de faire un diagnostic d'un logiciel interactif. Il s'agit, en l'occurence, d'un logiciel tlmatique destin au grand public, ce qui facilite le diagnostic en ce sens que nous n'avons pas besoin de faire des tests sur des types d'utilisateurs diffrents (expriments, novices,...) et que la notion de procdure effective n'est plus utile. Pour ce type de logiciel, une premire exprimentation, directement effectue par l'analyste en fonction de la grille d'analyse dfinie prcedemment, permet de faire un certain nombre de remarques utiles la prparation de tests systmatiques auprs d'un chantillon d'utilisateurs. Nous prsentons ci-dessous quelques-une des images d'crans sur lequel nous pouvons a priori formuler un certain nombre de critiques, compte-tenu des lments ergonomiques prsents prcdemment. Ces constatations ne sont pas forcment exhaustives car elles n'ont pas t valides sur un nombre suffisant d'utilisateurs. Nous prsentons ensuite des remarques ayant trait aux enchanements entre les crans.
6.3.1 Analyse des crans

La figure 2.1 reproduit le premier cran du logiciel RTR sur lequel nous pouvons faire les remarques suivantes: - la premire remarque a trait au fait que la syntaxe n'est pas homogne; en effet, cet cran propose un choix entre quatre possibilits ; pour obtenir trois d'entre elles, on doit taper une abrviation puis appuyer sur la touche "ENVOI", alors que pour la quatrime, il faur appuyer sur la touche "SUITE". Comme nous le verrons, cette htrognit se reproduit tout au long du logiciel; la consquence en est que l'utilisateur ne peut pas acqurir d'automatismes concernant l'envoi d'un message l'ordinateur; cela ncessite plus de concentration et occasionne des erreurs.
185
RTR
* DAVANTAGE D'HORAIRES REGIONAUX, C'EST POSSIBLE ! ! ! DEPUIS LE 1er OCTOBRE 1987 . . . D ENVOI les horaires et la rservation sommaire des services les principaux mots-cls (C) RTR 1987 MC H ENVOI SUITE ENVOI
Fig 2.1
- la deuxime remarque est relative l'ambigut des messages concernant le premier et le dernier choix: l'utilisateur n'a qu'une ide vague ou pas d'ide du tout sur ce que peut apporter la consultation de "Davantage d'horaires rgionaux, c'est possible!!!" et "les principaux mots-cls". Par contre les deux autres possibilits sont explicites. - la troisime remarque porte sur la non-pertinence d'une zone de l'cran; la dernire ligne, nous avons le message "(C) RTR 1987" qui n'est d'aucune utilit pour l'utilisateur car il sait dj par la premire ligne qu'il est en train de consulter RTR, on peut penser qu'il sait en quelle anne il est et la signification du (C) n'est pas ncessaire pour utiliser le logiciel. Cette zone inutile, du point de vue de l'utilisateur, se retrouve avec des variantes de prsentation sur tous les crans. La figure 2.2 est obtenue en appuyant sur la touche "SUITE" partir du premier cran; on peut l'obtenir aussi d'autres moments en appuyant sur la touche "SOMMAIRE"; ceci est une autre forme de l'htrognit de la syntaxe. Nous avons choisi cet cran car il est trs caractristique des abrviations non mnmoniques en ce sens que ces abrviations ne sont pas constitues partir d'une rgle unique facilement mmorisable.
186
Les abrviation des commandes 2,3,4,7,9,11,12 reprennent des lettres contenues dans le vocabulaire de ces commandes et peuvent donc tre plus facilement mmorises (une tude plus fine s'imposerait); mais cette rgle n'est pas applique pour les autres commandes.
RTR
1 2 3 4
SOMMAIRE
INFV PERS HORA RESA SERNAM MARC CONT INFO SE MC AI ENVOI
INFORMATIONS VOYAGEURS gnrales et rgionales informations personnalises les horaires la rservation des places
INFORMATIONS MARCHANDISES 5 colis, lots, dmnagements 6 transports par wagons complets 7 transports en conteneurs 8 CONNAITRE LA RTR 9 l'actualit AC / 1 panorama 11 les principaux mots-cls 12 aide l'utilisation du minitel tapez le N ou le MOT choisi et RTR (C) 1987 Fig 2.2
La commande 1 a une abrviation correspondant la ligne prcdente qui est un libell gnral. La commande 5 a comme abrviation le nom d'une entreprise! Les commandes 6 et 10 ont une abrviation mystrieuse pour un utilisateur ordinaire. La commande 8 a une abrviation proche de celle de la commande 1 et loigne de la commande qu'elle dsigne. Nous pouvons faire galement deux remarques sur la prsentation: - la premire concerne la ligne o sont prsentes les commandes 9 et 10; cette ligne n'est pas homogne avec les autres puisqu'il y a deux commandes sur la mme ligne ce qui la rend quasiment illisible. - la seconde concerne l'criture du chiffre zro qui est prsent avec une barre, ce qui est usuel uniquement pour les informaticiens et inconnu pour tous les autres utilisateurs. La figure 2.3 reprsente un des feuillets de l'aide l'utilisation ; le premier feuillet de cette aide est obtenu en tapant 12 ou AI suivi de
187
"ENVOI" la suite de l'cran SOMMAIRE; pour obtenir le deuxime feuillet, il faut appuyer sur 1 suivi de la touche "ENVOI" alors que pour obtenir les autres feuillets, il faut appuyer sur "SUITE" (htrognit de la syntaxe). La premire remarque que l'on peut faire sur cet cran concerne le vocabulaire; certains mots de ce vocabulaire ont une signification pour l'informaticien mais pas pour les autres utilisateurs. Il s'agit de "fonctions", "accs", "page adjacente" (la faute d'orthographe sur adjacente est d'origine!). La deuxime remarque a trait l'ambigut du message dcrivant "Retour au feuillet prcdent"; ce message exprime en fait deux ides diffrentes, la premire a trait effectivement au retour la page prcdente, la seconde a trait la "page rubrique prcdente", ce qui n'est pas trs explicite. La troisime remarque n'est pas directement visible sur l'cran puisqu'elle concerne la vrification de la cohrence entre les explications contenues dans l'aide et le logiciel lui-mme. Cela concerne les touches SUITE et RETOUR dont l'emploi au cours de l'utilisation du logiciel n'est pas toujours possible et dont les effets ne sont pas toujours ceux attendus.
RTR
SUITE OU FEUILLET SUIVANT RETOUR AU FEUILLET PRECEDENT
AIDE A L'UTIL ISATION

TOUCHE SUITE
FONCTIONS DE CONSULTATION passage au message suivant ou la page suivante retour au message ou la page prcdente, associ *, retour la page rubrique prcdente
RETOUR
REPETITION rptition de l'cran en cas de DU FEUILLET mauvaise transmission REPET. associ un choix numrique accs une page adjascente sans avoir revenir au sommaire correspondant appuyez sur RTR AI Fig 2.3 SUITE
188
La figure 2.4 reprsente le premier cran du service "horaires"que l'on obtient en tapant la commande "HORA" comme il est indiqu dans la premire ligne. La premire remarque concerne le vocabulaire des messages de service: - le mot "relation"qui dsigne une liaison ferroviaire n'est pas en usage dans le vocabulaire courant; La deuxime remarque concerne la logique d'utilisation au niveau de cet cran. On trouve en effet, regroups dans le service "horaires", deux autres services, "les rductions" et "les dernires nouvelles", qu'il n'est pas du tout vident de placer cet endroit. En ce qui concerne "les rductions", l'utilisateur doit pouvoir y accder directement sans passer par une arborescence; c'est donc un service qui doit tre prsent au niveau du sommaire gnral. Si l'accs direct n'est pas possible, il faut le regrouper dans un service du type "informations gnrales" o l'utilisateur peut s'attendre trouver des informations varies caractre gnral et non pas dans un service spcifique comme "horaires"
RTR
HORAIRES
HORA
HORAIRES "VILLE A VILLE" : -de toutes les relations desservies par trains ou autocars directs (Banlieue de Paris exclue) soit 16. relations, -des principales relations desservies par correspondance, soit 2. relations pour une date comprise dans les deux mois a venir . tapez 1 ENVOI GUIDE ENVOI ENVOI
" Si vous hsitez .................... " Les rductions .. .........REDU
" Les dernires nouvelles ....... DERN (C) R T R 1987
.
Fig 2.4
189
La figure 2.5 reprsente un cran de consultation d'horaires o l'utilisateur a essay de revenir la page prcdente (liste des horaires) au moyen de la touche "RETOUR"; on voit alors que s'affiche sur la premire ligne le message d'erreur "touche retour ineffective". Ce message est en contradiction avec les explications contenues dans "l'aide l'utilisation" o l'on indique que la touche "RETOUR" permet de revenir la page prcdente. Si la rgle nonce ne peut, pour des raisons techniques, tre respecte, il faut modifier le texte de l'aide et indiquer pour chaque cran les touches actives ce niveau (notion de menu dynamique). Mais avant de faire ces modifications, il y aurait lieu de vrifier s'il y a une vritable impossibilit technique respecter cette rgle qui a l'avantage de la simplicit et qui correspond une touche fonction.
TOUCHE RETOUR INEFFECTIVE
RTR
LOCALITES : de dpart : TOULOUSE (31) d'arrive : PARIS (75) DATE DE DEPART : 221
HORAIRES
Horaires sur la mme relation : 1- mme sens une autre date 2- retour la mme date 3- retour une autre date tapez le N . + Fig 2.5
ENVOI
La figure 2.6 correspond l'cran de rservation obtenu directement partir de l'cran "Sommaire". On peut faire des remarques de surface au sujet de la syntaxe des phrases suivantes: - "Vous dsirez des : ASSISES"; alors qu'il y a suffisamment d'espace pour rajouter le mot "PLACES". - "Vous pouvez : - autre rsevation ou horaire". Ce type de syntaxe inutilement incomplte constitue pour les utilisateurs une gne importante qui affecte leur comprhension.
190
Mais la remarque essentielle sur cet cran concerne le traitement des erreurs. Nous sommes dans un cas d'erreur non dtecte avec message d'erreur erronn. En effet, quand l'utilisateur partant de TOULOUSE tape PARIS comme destination, l'ordinateur lui demande de choisir parmi une des gares parisiennes; cette question est parfaitement inutile puiqu'il n'a pas le choix effectif de cette gare! Cette information devrait donc tre dduite automatiquement. Si l'utilisateur se trompe sur la gare d'arrive (ici, en tapant PARISNORD), le logiciel ne lui signale pas l'erreur et, en consquence, l'utilisateur continue saisir les autres donnes; aprs validation, il obtient comme message qu'il n'y a pas de train l'heure indique. Le comportement du programme est par ailleurs non stable car au cours d'un autre essai de ce type nous n'avons pas obtenu de message d'erreur mais un message d'attente "votre demande est transmise veuillez patienter" suivi d'une interruption pour dpassement de temps sans utilisation! Quelle que soit la rponse du logiciel, l'utilisateur ne peut pas savoir qu'il a fait une erreur sur la gare de destination.
RTR
RESERVATION
Vous voulez voyager : - de : TOULOUSE-MATABIAU - : PARIS-NORD - le : 241 - par le train : ORDINAIRE DE 8H Vous dsirez des : ASSISES - en : 1. classe - nombre et prfrences : 1 . Nous ne pouvons effectuer votre rservation pour le motif suivant : AUCUN TRAIN NE DESSERT LA RELATION A L'HEURE INDIQUEE .
Vous pouvez : - modifier votre demande ....1 - autre rservation ou horaire Fig 2.6
ENVOI SUITE
191
La figure 2.7 est un cran de rservation obtenu partir du service "horaires", ce qui a pour consquence que les quatre premires lignes sont remplies automatiquement par le logiciel car elles correspondent au choix fait par l'utilisateur sur l'cran prcdent. Mais la zone indiquant le numro du train n'est pas pertinente pour l'utilisateur alors que l'heure du train le serait et ne figure pas. L'indication concernant la longueur du nom (limite 13 caractres) est une indication d'ordre technique qui est peu pertinente pour l'utilisateur; elle correspond la logique de fonctionnement (indexation des fichiers) et non la logique d'utilisation.
RTR
RESERVATION
Vous voulez voyager : - de : TOULOUSE-MATABIAU - : PARIS AUSTERLITZ - le : 241 - par le train : N 74 Vous dsirez des : ASSISES - en : 1. classe - nombre et prfrences : 1 Veuillez nous indiquer en 13 caractres maximum votre nom qui permettra d e vous identifier, lors du retrait de votre titre de rservation : ............. aprs votre rponse modifier la demande vous voulez tre aid Fig. 2.7 ENVOI ENVOI GUIDE
6.3.2 Enchanements d'crans

Les enchanements d'crans peuvent tre tests uniquement partir du logiciel, mais l'analyse sera plus rapide si l'on dispose du dossier d'analyse et que l'on procde ensuite des vrifications systmatiques sur le logiciel. Sinon la premire partie du diagnostic consiste reconstituer l'arborescence du menu qui figure dans le dossier d'analyse. C'est ce qui a t fait dans ce cas et nous prsentons ci-dessous deux schmas, avec le formalisme des automates d'tats finis, qui ont t remplis lors des tests sur le logiciel RTR:
192
- le premier reprsente une partie de l'arborescence gnrale dans le sens descendant, c'est--dire en partant du menu gnral et en allant vers les crans suivants; pour faire le lien avec les images d'crans prsentes prcdemment , nous avons indiqu dans les places du schma (reprsentes par un cercle) le numro des figures correspondantes. - le deuxime schma reprsente les tests systmatiques des touches RETOUR et SOMMAIRE pour chacun des crans reprsents sur le premier schma; on voit cependant la touche GUIDE apparatre une fois quand on est dans le cas o les touches RETOUR et SOMMAIRE sont toutes les deux interdites; mais pour des raisons de lisibilit, il n'tait pas possible de reprsenter sur le mme schma les tests systmatiques de la touche GUIDE. A partir de ces schmas, dysfonctionnements suivants: nous pouvons constater les
1. l'arborescence du menu ne correspond pas globalement une logique d'utilisation; on peut titre d'exemple citer les faits suivants: - on peut aller de l'cran "horaires" vers l'cran "rservation" (comme on peut le voir sur le schma reprsentant un extrait de l'arborescence de RTR) mais l'inverse n'est pas vrai; ce fait constitue une gne importante car il est usuel d'avoir besoin de consulter des horaires en cours de rservation soit pour s'assurer de l'horaire prcis soit pour redresser une erreur. - le sommaire gnral (figure 2.2) s'adresse des types d'utilisateurs diffrents et des niveaux diffrents; il y aurait lieu de distinguer au minimum les voyageurs (horaires et rservations) et les entreprises (transports par wagons complets et en conteneurs). Les diffrents types d'information caractre gnral peuvent tre regroups par type d'utilisateur (informations gnrales, actualit,...). - certaines informations de niveau un ne sont pas acessibles directement; par exemple, les rductions ne sont accessibles qu' partir des horaires, ce que l'utilisateur ne peut absolument pas deviner. 2. Les commandes standard d'enchanement ne sont pas systmatiquement activables par l'utilisateur, sans qu'aucune indication ne lui soit fournie ce sujet. Il s'agit des commandes correspondants des touches-fonctions comme SOMMAIRE, GUIDE, ANNULATION, CORRECTION, RETOUR, SUITE.
193
De plus, l'effet de ces commandes n'est pas toujours identique, ce qui rend le comportement du logiciel non prvisible pour l'utilisateur et lui interdit de dvelopper un automatisme. Nous pouvons voir sur le deuxime schma que dans la branche "horaires", sur quatre crans successifs, on a trois actions diffrentes pour la mme touche RETOUR (interdiction, retour l'cran prcdent, retour la ligne prcdente du mme cran). De mme pour la touche SOMMAIRE qui fait parfois revenir l'cran prcdent, parfois deux crans prcdents,parfois au dbut de l'arborescence ou qui est interdite. Comme nous l'avons indiqu au dbut de ce chapitre, le formalisme des automates d'tats finis, qui a l'avantage d'tre trs facile utiliser pour dcrire les enchanements d'crans, prsente une ambigut quand il s'agit d'exprimer le paralllisme et les synchronisations. Nous pouvons constater ce problme sur le deuxime schma o, partir de l'cran "Horaires/1", il y a deux sorties par la touche SOMMAIRE selon que l'on vient de "Horaires/0" ou de "Menu gnral". Pour lever cette ambigut due au formalisme, il faudrait dupliquer compltement la branche constitue des crans "Horaires/1", "Horaires/2", "Horaires/3" et "Rservation"...; ceci alourdirait la prsentation du schma sans offrir d'avantages notables pour satisfaire l'objectif que l'on s'est fix ici: le diagnostic du logiciel vu du point de vue de l'utilisateur.
194
Extrait de l'arborescence du menu
GUIDE
Menu gnral fig 2.1

SUITE
Guide
(non dit)
H+ Sommaire fig 2.2 12+

ENVOI ENVOI
4+
ENVOI
3+
ENVOI
Aide l'utilisation/1
Rservation/1
Horaires/0 fig 2.4
1+
ENVOI
SUITE
1+
ENVOI
Horaires/1
Donnes + ENVOI Rservation fig 2.6 Horaires/2 (listes)
SUITE
N horaire + ENVOI Aide l'utilisation/3 fig 2.3 Horaires/3
1 ou 2 + ENVOI
Rservation fig 2.7

195
Test des touches RETOUR et SOMMAIRE
GUIDE
Menu gnral fig 2.1

RETOUR
Guide
RETOUR
interdit
SOMMAIRE
Sommaire fig 2.2
interdit
RETOUR
ou
RETOUR
ou
RETOUR SOMMAIRE SOMMAIRE
ou
SOMMAIRE
SOMMAIRE
Rservation/1
Horaires/0 fig 2.4

SOMMAIRE
RETOUR
ou
SOMMAIRE
Horaires/1
RETOUR
interdit
SOMMAIRE RETOUR
Horaires/2 (listes)
RETOUR
Aide l'utilisation/3 fig 2.3
Horaires/3
RETOUR
Rservation fig 2.7

196
BIBLIOGRAPHIE 1 - Informatique
Livres (Coh, 82) COHEN et FEIZENBAUM The Handbook of Artificial Intelligence - Vol. 3 Ed. PITMAN - 1982 (Col, 86) A.COLLONGUES, J.HUGUES, B.LAROCHE MERISE, mthode de conception Dunod Informatique - 1986 (Pol, 86) P.PELLAUMAIL La mthode AXIAL, conception d'information Editions d'Organisation - 1986 d'un systme
(Tar, 83) H. TARDIEU, S. ROCHFELD, R.COLETTI La mthode MERISE Ed. Organisations - 1983 Revues Maquettage et prototypage : outils et techniques Gnie Logiciel n3 - janvier 1986 Informatique de gestion : les mthodes Gnie Logiciel n4 - avril 1986 Informatique de gestion : les outils Gnie Logiciel n5 - juillet 1986 Articles (Bar, 86) MF. BARTHET, C. SIBERTIN-BLANC La modlisation d'applications interactives adaptes aux utilisateurs par des Rseaux de Petri Structure de Donnes Congrs AFCET, Gnie Logiciel, Versailles, mai 86
197
(Bra, 86) G. BRAJNIK,G. GUIDA,C. TASSO An expert interface for effective man-machine interaction Cooperative Interfaces to Information System, SPRINGER-VERLAG - 1986 (Cou,86) J.COUTAZ La construction d'interfaces homme-machine Rapport IMAG n635 - 1986 (Mer, 81) MEYROWITZ et MOSER Bruwin : an adaptable design strategy for window manager/virtual terminal system. ACM SIGOPS - Vol 15 N 5 - December 1981 (Sar, 74) SACERDOTI Planning in a hierarchy of abstraction spaces. Artificial Intelligence 5 - 1974 ( Sib, 85) SIBERTIN-BLANC Les rseaux de Ptri de haut niveau comme formalisme de modlisation des traitements d'un systme d'informatique.Convention Informatique Latine - 1985 (Was, 82) WASSERMAN The user software engineering methodology: an overwiew University of California, San Franscisco - 1982 (Weg, 83) WEGMANN Vitrail - Conception et ralisation d'un noyau de communication homme-machine pour un systme bureautique intgr. Thse Docteur Ingnieur - Universit Paris VI Septembre 1983
2 - Ergonomie
Livres (Art, 81) ACTIF Informatisation et vie au travail Les Editions d'Organisation - 1981
198
(Cac, 80) CACKIR, HART, STEWART Les terminaux cran Editions d'Organisation - 1980 (Not, 80) L.NORMAN Traitement de l'information et comportement humain Etudes Vivantes, Montreal - 1980 (Spe, 80) SPERANDIO La psychologie en ergonomie. PUF - 1980 Articles (Bar, 87) MF. BARTHET, L.PINSKY Analyse du travail ergonomique et mthodes d'analyse informatique Les Cahiers "Technologie, Emploi, Travail", n4 L'ergonomie des logiciels, Documentation Franaise octobre 87 (Bis, 79) BISSERET Utilisation de la thorie de la dtection du signal pour l'tude des dcisions : effet de l'exprience des oprateurs. Rapport INRIA C. 07911R60 - 1979
(Bou, 79) BOUJU - SPERANDIO Analyse de l'activit visuelle des contrleurs d'approche. Rapport INRIA C. 07911R59 - 1979 (Caz, 81) CAZAMIAN Image et Action - Doc. interne - 1981 Dpartement d'Ergonomie et d'Ecologie Humaine. Universit Paris I. (Cor, 82) CORSON Aspects psychologiques lis l'interrogation d'une base de donnes. Rapport INRIA N 126 - Avril 1982 (Der, 78) DERMOTT Planning and Acting. Cognitive Science - Vol. 2 - 1978 (Gra, 81) GRAESSER, ROUANNET, DE LLENBACH Incorporating Infrences in Narrative Reprsentations : Astady of How and Why - Cognitive Psychology, 1981
199
(Lep, 83) J.LEPLAT, JM. HOC Tche et activit dans l'analyse psychologique des situations Cahiers de psychologie cognitive - mars 1983 (Och, 72) OCHANINE - QUAAS - ZALTMAN Dformation fonctionnelle des images opratives. Questions de psychologie N 13 - 1972 (Pin, 87) L.PINSKY De l'interface la situation de travail Rapport introductif, congrs SELF, Lige septembre 1987 (Ric, 83) JF. RICHARD Logique du fonctionnement et logique d'utilisation Rapport INRIA n202 - avril 1983 (Rol, 82) ROLLOY Etude des conditions de travail en agence commerciale des tlcommunications. Rapport interne - 1982 (Sca, 87) D. SCAPIN Guide ergonomique de conception des interfaces hommemachine Rapport INRIA n77 - 1987 (Seb, 87) S.SEBILLOTTE La planification hirarchique comme mthode d'analyse de la tche Rapport INRIA n599 - 1987 (Sec, 87) B. SENACH Intelligence des logiciels d'aide l'utilisation et modlisation de l'activit des utilisateurs Les Cahiers "Technologie, Emploi, Travail", n4 L'ergonomie des logiciels, Documentation Franaise octobre 1987
3 - Livres divers
(Bra, 83) G.W.BRAMS Rseaux de Petri Masson - 1983
200
(Mel, 77) MELESE Analyse modulaire des Systmes Ed. Hommes et Techniques - 1977
201
GLOSSAIRE
Activable Proprit d'une opration ; une opration est activable si les conditions du pr-requis sont ralises . Activit L'activit est ce qui est mis en oeuvre pour excuter la tche . C'est la trace de ce qui est fait rellement par l'utilisateur . But Etat final que doit atteindre le systme homme-machine . Il sera dcrit par des critres et la valeur qu'ils doivent prendre . Dclenchement Proprit d'une opration ; c'est un vnement particulier en entre d'une opration ; si le dclenchement est optionnel, cela signifie que cet vnement est dclench par l'utilisateur . Si le dclenchement est systmatique, cela signifie que cet vnement est dclench par l'ordinateur . Entit C'est la reprsentation abstraite d'un objet identifiable du monde rel . Une entit sera dcrite par une liste de rubriques . Evnement C'est un fait dont l'apparition est de nature dclencher l'excution de traitements. Dans le cas de la description d'un systme d'information,l'vnement sera dcrit par un ensemble de donnes . Facultative Proprit d'une opration . Une opration est facultative si son excution ou sa non-excution n'interdit pas d'atteindre le but .
202
Indicative Proprit d'une prcdence . Une prcdence est indicative si elle existe dans une ou plusieurs procdures effectives ou prescrites sans exister dans la procdure minimale . Latitude dcisionnelle C'est la partie du pilotage de la tche qui est sous la responsabilit de l'utilisateur . Logique de fonctionnement C'est un dcoupage de l'application du point de vue de l'informatique (analyste ou programmeur). Logique d'utilisation C'est un dcoupage de l'application du point de vue de l'utilisateur. Obligatoire Proprit d'une opration . Une opration est obligatoire si son excution, quand elle est activable, est ncessaire pour atteindre le but . Opration C'est un ensemble de transactions qui peuvent tre excutes conscutivement et sans attente d'vnements externes au systme homme-ordinateur . Opration lmentaire C'est la plus petite dcomposition possible qui ait un sens pour l'oprateur. Optionnel Voir "dclenchement".
203
Permanente Proprit d'une prcdence . Une prcdence est permanente si elle existe dans toutes les descriptions procdurales de la tche . Pilotage Le pilotage d'une tche, au sens de la thorie des systmes, recouvre la notion de contrle de l'excution et de rgulation de la tche . Poste de travail C'est un ensemble de moyens mis la disposition d'un utilisateur pour lui permettre de raliser un ensemble de fonctions dtermines dans une organisation donne . Prcdence C'est un lien de priorit d'excution entre oprations . Si P(Oi, O j) est satisfait, cela signifie que Oi doit tre excut avant Oj . Une prcdence est permanente si son excution est contrle par l'ordinateur; elle est indicative si son excution est contrle par l'utilisateur. Pr-requis C'est l'ensemble des conditions (sur les vnements et sur les donnes) qui doivent tre vrifies pour que l'opration puisse s'excuter . Procdure Description formelle et dtaille d'une tche permettant de dcrire l'enchanement des diffrentes oprations . Procdure effective (PE) C'est une description permise d'une tche ; c'est un modle de l'activit .
204
Procdure minimale (PM) Cest l'ensemble des oprations et des enchanements minimaux pour que le but de la tche puisse tre considr comme atteint par l'ordinateur . Procdure prvue ou prescrite (PP) C'est la description d'une tche telle qu'elle est prvue dans son droulement standard. Rgle d'mission Les rgles d'mission sont des rgles incluses dans les oprations et dont les valeurs dterminent les vnements de sortie de l'opration. Reprsentation conceptuelle (RC) C'est la reprsentation abstraite d'un poste de travail vu par l'analyste . Reprsentation externe (RE) C'est la reprsentation concrte des applications interactives vues par l'utilisateur . Reprsentation interne (RI) C'est la reprsentation concrte des applications interactives telles qu'elles seront programmes . Rubrique C'est la plus petite information significative qui puisse tre utilise de faon autonome. Synchronisation C'est une proposition logique boolenne portant sur la liste des vnements d'entres d'une opration . Systmatique Voir "dclenchement"
205
Tche C'est une fonction d'un poste de travail . Elle sera dcrite par un but et des conditions; les conditions peuvent tre dcrites soit par l'ensemble des tats parcourir pour atteindre le but, soit par les oprations admissibles pour parcourir ces tats, soit par la procdure (ou combinaison de ces oprations) . Transaction C'est une interaction complte (un aller-retour) entre l'utilisateur et le systme technique .
206

Barthet 1988

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Barthet 1988

Uploaded by

Copyright:

Available Formats

logiciels interactifs et ergonomie

modles et mthodes de conception

Version lectronique Lire l'avertissement

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Chapitre 1 : L'INTERFACE HOMME-ORDINATEUR.......................................................8

Chapitre 2 : LES STRUCTURES PROFONDES DES APPLICATIONS INTERACTIVES...............................................................31

Chapitre 3 : LES ASPECTS DE SURFACE DES APPLICATIONS INTERACTIVES...............................................................69

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Chapitre 4 : STRUCTURE INTERNE DES LOGICIELS INTERACTIFS...................105

Chapitre 5 : DIANE METHODE DE CONCEPTION D'APPLICATIONS INTERACTIVES.........................................................124

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Chapitre 6 : DIANE METHODE DE DIAGNOSTIC......................................................174

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Chapitre 1 : L'INTERFACE HOMMEORDINATEUR

1 . 1 La conception usuelle des logiciels interactifs

1.1.1 Les limites des mthodes actuelles

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Message de sortie de l'ordinateur sur l'imprimante

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Choix transaction "Commande"

Demande caractristiques client E1

Affichage nom prix, article E2

Quantit non disponible E2

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Numro client Nom client

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

1.1.2 Les grands mythes

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

1.1.3 L'apport d'autres disciplines

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

1.1.4 Les diffrents points de vue

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

1 . 2 Les principaux dvelopps

Systme reprsent (tude pralable, dtaille ; ...)

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

1.2.2 Les nouveaux concepts sur applications interactives et les utilisateurs

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Informatique Etude de l'existant

Caractristiques ergonomiques gnrales

Reprsentation externe Contraintes matrielles et logicielles

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Point de vue de l'utilisateur

Point de vue du programmeur

1.3 Prsentation de l'ouvrage

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

1.3.2 Comment le lire?

Marie-France BARTHET - Logiciels interactifs et ergonomie : modles et mthodes de conception - 1988

Chapitre 2 Psychologie cognitive Modle orient analyste

Chapitre 3 Ergonomie Modle orient utilisateur

Chapitre 4 Modle orient programmation