Ce premier chapitre a un double but car il présente d'une part l'état de l'art dans la conception des applications interactives, d'autre part les principaux concepts développés dans ce livre.
Ce paragraphe présente d'une part l'ensemble des pratiques, des tendances et des présupposés 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.
La conception des logiciels interactifs est faite, dans la très grande majorité des cas, par les informaticiens-analystes qui disposent, pour cela, de méthodes d'analyse et de conception des systèmes d'informations automatisés.
Ces méthodes les amènent à "déduire" l'interface entre l'utilisateur et l'ordinateur de la logique de fonctionnement des systèmes d'information.
Pour illustrer ce propos, nous faisons référence ici à deux méthodes bien connues en France, MERISE et AXIAL, qui sont assez caractéristiques de la pratique développée dans le domaine de la spécification des applications interactives.
La différence essentielle sur les applications interactives entre ces deux méthodes tient au degré de détail des spécifications:
- quand on a fini d'appliquer la méthode MERISE (Tar,83), on a des spécifications détaillées des données et des traitements associés, mais on ne dispose d'aucune spécification précise sur le dialogue homme-machine; la conséquence immédiate est que l'essentiel de l'interaction homme-machine est définie au niveau de la programmation à un moment où il est très difficille d'intégrer le point de vue de l'utilisateur car on est alors entièrement absorbé par les contraintes matérielles et logicielles.
- par contre quand on applique la méthode AXIAL (Pel,86) , on aboutit à un ensemble de spécifications précises 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 développé à partir du formalisme de la méthode AXIAL:
Cet exemple décrit un diagramme du dialogue utilisateur-machine qui visualise les enchaînements possibles entre un utilisateur et un programme "Commande" qui a pour rôle de permettre l'enregistrement des caractéristiques d'une commande.
Le cas normal, c'est-à-dire sans erreur, est présenté dans la partie verticale gauche; les erreurs ou les possibilités de sortir de cet enchaînement normal sont situées dans la partie droite de schéma.
La signification du formalisme est la suivante:
En observant ce diagramme, on peut se poser les questions suivantes:
- "Quels sont les critères utilisés pour concevoir le "menu" et sa hiérarchie, s'il y a lieu?"
Ces critères ne sont pas explicites mais si on regarde l'ensemble de la méthode, on voit que ce menu est déduit du découpage du système d'information (fonction puis opération 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 opérations nécessaires à l'utilisateur pour qu'il puisse réaliser avec le plus de facilités possible sa tâche?".
Si on se pose ce type de questions, on peut être amené à regrouper des opérations appartenant à des fonctions différentes mais utilisées par une même personne, à créer une redondance à l'intérieur de la hierarchie, à introduire des enchaînements propres à la logique d'utilisation de l'utilisateur... mais on a très peu de chance de retomber sur le découpage élaboré précédemment.
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 coïncident.
En effet, le point de vue de l'analyste suit la logique générale du système 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 déterminés les enchaînements du dialogue?"
L'enchaînement proposé correspond-il à un enchaînement possible, probable, moyen?
En fait il est étonnant qu'il n'y ait qu'un type d'enchaînement possible (comme nous le verrons au chapitre 2) et ceci sans justification de ces enchaînements vis-à-vis d'une logique d'utilisation.
Y a-t-il possibilités d'interruption ou d'abandon en cours d'opération?
Ces possibilités systématiques ne sont pas prévues et au contraire, on voit que l'utilisateur est totalement contrôlé par le logiciel qui prévoit à quel moment précis il peut revenir au début 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 conséquence, c'est le plus souvent le pilotage de l'ordinateur qui prime, empêchant ainsi l'utilisateur d'adapter ses enchaînements en fonction des contraintes propres à la réalisation de sa tâche.
- "En cas d'erreur quelles sont les possibilités de correction de l'utilisateur?"
On voit qu'il est prévu des enchaînements propres à la détection de certaines erreurs par le logiciel, mais on oublie qu'il y a des erreurs que l'ordinateur ne peut détecter alors que l'utilisateur peut les voir. Encore faut-il lui donner la possibilité de les rectifier en "défaisant" éventuellement une partie de ce qu'il a fait.
D'autre part, les erreurs détectées par le logiciel peuvent être d'origines différentes. Si c'est une erreur de saisie, les enchaînements prévus dans l'exemple sont bons, mais si c'est une erreur différente (numéro erronné sur le bordereau), la rectification de cette erreur va nécessiter de la part de l'utilisateur une stratégie différente (consultation d'une liste par exemple) qui est rendue impossible dans cet exemple.
- "Quelles sont les possibilités de guidage?"
A priori, le guidage n'est pas prévu dans ce dialogue utilisateur-machine.
Ce diagramme du dialogue utilisateur-machine est complété par les dessins d'écran.
Nous donnons ci-dessous, à titre d'exemple, un dessin d'écran:
A propos de ce dessin d'écran, on peut se poser les questions suivantes (questions toujours centrées sur l'utilisateur):
- "Toutes les zones de l'écran sont-elles pertinentes pour l'utilisateur?"
- "Le vocabulaire des données ou des commandes correspond-il au vocabulaire employé par les utilisateurs?"
- "La présentation de l'écran est-elle compatible avec les formulaires existants manipulés par les utilisateurs?"
- "Si l'enchaînement des zones à remplir est automatique, correspond-il à une logique d'utilisation et à ces variabilités?"
En résumé, nous pouvons dire que les méthodes d'analyse n'incitent pas l'analyste à compléter sa conception par le point de vue de l'utilisateur. Elles l'incitent au contraire à déduire sa conception du dialogue homme-machine de la logique du système informatique, comme nous l'indiquons sur le schéma suivant:
Nous allons montrer dans la suite de ce livre quelles sont les modifications à apporter aux méthodes de conception de manière à pouvoir intégrer le point de vue de l'utilisateur.
Nous insistons beaucoup sur les méthodes car nous pensons qu'elles sont à l'origine de la plupart des interfaces inadaptées aux utilisateurs alors que le contexte actuel du matériel et du logiciel de base y est favorable .
En effet, le matériel informatique évolue vers de plus grandes capacités en mémoire centrale pour un coût plus faible. Cette tendance est fondamentalement favorable au développement de logiciels adaptés aux utilisateurs car de tels logiciels nécessitent, comme nous le verrons, plus d'espace mémoire pour chaque utilisateur. Chaque nouvelle possibilité offerte à l'utilisateur se traduit par une augmentation de la place mémoire nécessaire.
Sur le plan des logiciels de base, nous voyons l'apparition de logiciels de gestion d'écran plus sophistiqués (voir chapitre 4) qui offrent plus de possibilités d'interaction à l'utilisateur tout en déchargeant le programmeur d'une partie de la gestion du dialogue.
L'évolution du matériel informatique et des logiciels de base est donc tout à fait favorable à l'émergence de logiciels de plus en plus adaptés aux utilisateurs mais paradoxalement ce sont les méthodes d'analyse et de programmation qui constituent à l'heure actuelle un frein à cette évolution; c'est cette lacune que ce livre tente de combler.
Dans ce paragraphe, nous avons regroupé un certain nombre de propos que l'on peut entendre et qui sont, à notre avis, des mythes qui entraînent des confusions dans la conception de la communication homme-machine.
Une application conversationnelle a en commun avec une application différée le fait de définir une structure de données et une structure de traitements associée. A priori, la seule grande différence est la conception d'une interface homme-ordinateur qui permette la communication entre l'utilisateur et l'ensemble des fonctionnalités de l'application (traitement et données).
Partant de cette constatation, il semble logique de déduire que, si on veut améliorer la conception des applications interactives, il faut faire porter son effort sur la conception de l'interface indépendamment des fonctionnalités du système qui peuvent être définies par ailleurs par les méthodes d'analyse classiques.
L'indépendance de l'interface semble être confirmée par les propos des concepteurs de "logiciels de base d'interface évoluée" (voir chapitre 4) qui basent leurs travaux sur la séparation entre les fonctionnalités de l'application et son interface utilisateur.
Mais, comme nous le développons dans ce livre, nous verrons qu'une réflexion plus approfondie sur l'amélioration de la communication homme-machine rend impossible d'isoler conceptuellement l'interface et les fonctionnalités car cette amélioration 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 différées ne peut être identique car, dans le cas d'applications différées, on ne doit prévoir que des enchaînements automatiques entièrement pilotés 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.
En fait, ce propos n'est pas en contradiction réelle avec ceux des concepteurs de logiciels de base car il ne se situe pas au même niveau de préoccupation.
Nous disons qu'il y a une interdépendance conceptuelle entre interface et fonctionnalités mais il y a une indépendance physique nécessaire lors de l'implémentation essentiellement pour des raisons de diminution de complexité et de modifiabilité.
L'expression "homme-machine" ou "utilisateur-ordinateur" peut présenter une ambiguïté qu'il est nécessaire de lever vu sa fréquence d'utilisation dans ce livre.
En cours d'exécution 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'amélioration de la communication homme-machine, en l'absence "d'améliorations" de l'homme, ne peut porter que sur l'amélioration de la conception.
Il existe une idée très répandue 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'intérêt d'une communication en langage naturel, ce type de communication ne peut à lui seul résoudre toutes les difficultés.
Et ceci pour deux raisons essentielles:
- dans le cas d'utilisateurs professionnels, il se crée un vocabulaire spécialisé, laconique, adapté à la tâche (voir chapitre 2 ) qui utilise un sous-ensemble restreint et parfois déformé du langage naturel.
- dans tous les cas, le langage ne constitue qu'une partie de l'interface (voir chapitre 3) qui n'est elle-même qu'une partie de l'application et ne peut donc en aucun cas suppléer aux autres éléments de l'application.
La même idée est énoncée au sujet de l'intelligence artificielle et en particulier des systèmes-experts: " il n'y aura plus de problèmes de communication homme-machine quand l'intelligence artificielle sera généralisée".
Nous tenons à faire remarquer que, si les systèmes experts constituent un apport important pour la conception et la réalisation de systèmes d'aide à la décision, ils ne sont pas efficaces pour les autres applications d'informatique de gestion.
En d'autres termes, les systèmes-experts sont adaptés au cas où les processus cognitifs des utilisateurs sont "dirigés par les données" et non par des procédures (comme c'est le cas pour les applications de gestion qui ne relévent pas de l'aide à la décision).
Par contre, de nombreux concepts présentés ici peuvent servir pour le développement de systèmes-experts plus adaptés aux utilisateurs.
Pour pouvoir intégrer explicitement l'utilisateur à la conception des applications interactives, il est nécessaire de connaître les caractéristiques des utilisateurs. Pour ce faire, il est nécessaire de puiser dans d'autres disciplines qui ont pour objectif la connaissance de ces utilisateurs.
Deux disciplines nous ont paru particulièrement adaptées 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 définissons ici.
La psychologie cognitive désigne la partie de la psychologie qui s'intéresse à la manière dont l'homme traite l'information (mémorisation, apprentissage,...). Les concepts qui y sont développés ne sont pas du tout spécifiques de l'interaction homme-machine mais il est évident aussi qu'ils entraînent des conséquences 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 réactions des utilisateurs et nous en avons tiré des conséquences sur la conception des aplications interactives.
L'ergonomie s'intéresse de manière générale à l'amélioration des conditions de travail, et l'ergonomie du logiciel concentre plus particulièrement son attention sur les conditions de travail liées à l'utilisation par l'homme de logiciels interactifs.
Le terme "ergonomie du logiciel" a émergé dans les années 80 quand on a commencé à se poser sérieusement le problème 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 matériel de celle du logiciel.
Les travaux sur l'ergonomie du matériel sont antérieurs à ceux sur l'ergonomie du logiciel et ont déjà été largement publiés.
En conséquence 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).
Par définition, l'ergonomie du logiciel ne s'intéresse qu'à un sous-ensemble particulier des conditions de travail, l'amélioration du dialogue homme-ordinateur ne suffit pas à améliorer globalement les conditions de travail; de plus, il peut y avoir un aspect arbitraire et réducteur à s'occuper exclusivement d'ergonomie du logiciel en négligeant d'autres aspects au moins aussi importants au yeux des utilisateurs.
Pour s'en convaincre, nous faisons référence au livre publié par ACTIF (Act,81) qui traite de l'ensemble des modifications des conditions de travail liées à 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 durée du travail et des variables qualitatives liées à l'évolution du contenu du travail et de la qualification correspondante
- l'organisation , qui désigne d'une part la répartition globale du travail entre les différents partenaires de l'entreprise, d'autre part la description du travail au niveau individuel (type d'activité, répartition des tâches entre l'homme et l'ordinateur,...)
- les conditions matérielles , qui désignent les conditions générales comme le bruit, le rythme de travail, etc...et les conditions spécifiques au travail sur terminal (lisibilité, surcharge, dispositifs d'entrée de données,...).
- les relations de travail, c'est-à-dire la nature des relations qui s'établissent entre les différents membres de l'entreprise et avec les personnes extérieures.
Le tableau suivant résume l'impact des différentes étapes de l'analyse informatique sur les différentes rubriques décrivant les conditions de travail:
Nous pouvons constater que ce que l'on désigne 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 matérielles" au niveau informatique.
De plus, les effets des différentes rubriques ne sont pas indépendants et certains éléments 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 complètement l'effet bénéfique d'un logiciel "ergonomique". Inversement de bonnes relations de travail peuvent minimiser l'effet de mauvaises conditions matérielles.
Par ces remarques, nous voulons simplement préciser que la conception d'un logiciel adapté aux utilisateurs n'est pas en mesure de résoudre l'ensemble des problèmes humains posés par l'introduction de l'informatique mais qu'inversement, il ne peut pas y avoir un processus d'informatisation réussi sans optimisation de la manière dont l'homme est amené à communiquer avec l'ordinateur.
Les applications interactives sont conçues, étudiées et utilisées par des personnes différentes ayant des objectifs différents.
Nous pouvons citer au moins trois types de personnes qui s'intéressent 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.
Parce que l'objectif de chacune de ces personnes est différent, leurs perceptions de l'interaction homme-machine sont différentes et, en particulier, leurs décompositions de l'interaction et leurs critères d'optimisation différent. Nous nous trouvons devant le problème classique, en théorie des systèmes, des vues multiples sur un même objet..
Nous décrivons ci-dessous succintement ces différents points de vue.
L'objectif de l'utilisateur est d'avoir un logiciel lui permettant d'exécuter sa tâche avec le plus de facilité possible.
Il existe peu d'études sur la perception des utilisateurs; mais, nous avons trouvé dans une étude réalisée par Rolloy (Rol,82) un découpage selon les paramètres suivants:
- lisibilité des sorties
- adaptation du logiciel aux situations réelles de travail
- aide à l'utilisation et à l'apprentissage
- opérations redondantes
- initiatives possibles pour l'utilisateur.
L'ergonome a pour but d'améliorer la communication homme-machine et, pour ce faire, il observe le couple homme-machine de l'extérieur.
Le découpage qu'il adopte en est une conséquence et on trouve dans la littérature en ergonomie un consensus sur un découpage en sept paramètres:
- le séquencement des opérations
- le langage d'interaction
- les dispositifs d'entrée
- les dispositifs de présentation
- le temps de réponse
- 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 définir un ensemble de spécifications qui traduisent sur le plan informatique les fonctionnalités de l'application;
- en phase de programmation, son objectif est de produire un logiciel fiable compte-tenu des spécifications fonctionnelles et des contraintes matérielles et logicielles.
En phase d'analyse et avec des variantes selon les méthodes, on définit des paramètres tels que procédure, opération, synchronisation, entité, relation,...
En phase de programmation on rajoute des paramètres tels que transaction, type, rubrique,...
La première remarque que l'on peut faire est que tous ces paramètres ne se correspondent pas de façon biunivoque, comme nous le montrons sur le tableau suivant où l'on a mis en correspondance les paramètres perçus par l'utilisateur et ceux utilisés par l'ergonome:
Par la suite, nous nous préoccupons plutôt de la correspondance entre le point de vue de l'ergonome et celui de l'informaticien afin de pouvoir intégrer à la conception informatique les connaissances acquises par les ergonomes.
Pour établir cette correspondance deux approches sont possibles:
- la première approche est abstraite et se base sur la linguistique pour trouver un cadre théorique commun; cette approche reste pour le moment du domaine de la recherche;
- la deuxième approche est plus directement opérationnelle et consiste à traduire chaque paramètre provenant de l'ergonomie selon la logique de conception utilisée en informatique.
C'est cette deuxième approche qui a été choisie et qui est développée dans les chapitres 2 et 3.
Avant de faire une présentation générale de l'ouvrage, il nous semble important de définir ce que nous entendons par modèle, formalisme, méthode et outil dans le contexte de l'interaction homme-machine.
Un modèle est un ensemble de concepts au moyen desquels nous pensons pouvoir décrire de manière opérationnelle un sytème réel. Le système représenté au moyen de ce modèle ne peut en aucun cas être confondu avec le système réel qui est dans ce cas le sytème homme-machine.
En effet, l'approche de plus en plus répandue de la théorie des systèmes, nous a fait prendre conscience du fait qu'une description exhaustive d'un système réel est tout à fait illusoire et que la description d'un système réel est dépendante de deux éléments qui sont l'objectif et le modèle de l'observateur, ce que nous représentons sur le schéma suivant:
Le choix du modèle par l'observateur dépend de l'objectif qu'il se fixe quand il observe le réel; c'est-à-dire qu'il ne choisira pas les mêmes éléments de description selon l'utilisation qu'il veut faire des résultats de son observation.
L'observateur est, dans ce contexte, l'analyste, l'ergonome ou toute personne intervenant dans le processus de conception.
Le système représenté (qui est décrit à des niveaux de détails différents dans les différents dossiers d'analyse) est volontairement un système appauvri du système réel en ce sens qu'il contient moins d'éléments et moins d'interrelations entre ces éléments que le système réel.
Ce fait n'est pas handicapant si les éléments du modèle sont choisis avec soin de manière à permettre de réaliser les objectifs fixés.
C'est pour cela qu'il est nécessaire d'intégrer explicitement, au modèle des applications interactives, des éléments décrivant l'utilisateur, sinon le système représenté n'en contiendra pas.
Le modèle des applications interactives que nous proposons est décrit dans les chapitres 2 et 3.
Le formalisme est une convention de représentation des concepts du modèle. Par exemple un schéma de base de données peut être représenté selon un formalisme graphique ou un formalisme littéral et linéaire.
Le choix du formalisme se fait en fonction de sa lisibilité pour l'observateur et en fonction de propriétés qui peuvent en être déduites (c'est le cas des formalismes mathématiques).
Nous proposons dans le chapitre 2 un formalisme graphique permettant de représenter les éléments du modèle.
La méthode constitue un mode d'emploi particulier d'un modèle; elle indique dans quel ordre observer les différents éléments et comment procéder à ces observations.
Elle restreint ainsi les possibilités du modèle mais elle a l'énorme avantage de permettre un apprentissage plus aisé.
Par contre quand le modèle a été bien intériorisé et que l'analyste a l'habitude des observations sur le terrain, il peut abandonner en partie ou totalement la méthode, de manière à disposer d'une plus grande latitude décisionnelle lui permettant de mieux s'adapter aux spécificités du système réel qu'il observe.
La méthode de conception des applications interactives adaptée aux utilisateurs est décrite au chapitre 5.
A titre d'exemple, nous pouvons citer MERISE qui est présentée d'abord par son modèle puis par la méthode associée alors que AXIAL est présentée uniquement sous forme de méthode.
Un "outil" est un logiciel d'aide à l'analyse qui utilise le formalisme et la méthode associée 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 vérifications de cohérence et des simulations.
Dans le cadre de ce livre, nous présentons un modèle d'application interactive adaptée aux utilisateurs ainsi qu'un formalisme et une méthode associée.Cet ensemble peut, bien sûr, être utilisé sans "outil" associé; aussi le problème de l'outil qui, à lui seul, constitue un développement important n'est pas traité dans ce livre.
Pour pouvoir intégrer explicitement le point de vue de l'utilisateur à la conception des applications interactives, nous proposons un modèle 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é Représentation Conceptuelle, décrit d'abord la logique générale du nouveau système d'information puis la logique des traitements par rapport à un poste de travail; c'est dans cette deuxième phase que nous commençons à intégrer des éléments de psychologie cognitive liés à l'utilisateur.
Le point de vue de l'utilisateur, appelé Représentation Externe, correspond au logiciel tel qu'il sera vu et manipulé par l'utilisateur.
Cette Représentation Externe comprend deux parties; la première est la traduction des éléments de la Représentation Conceptuelle qui entrent dans l'interaction homme-machine; la deuxième comprend la définition de tous les éléments spécifiques à la Représentation Externe (qui correspond à la notion d'interface).
C'est ici que nous intégrons tous les éléments d'ergonomie.
Le point de vue du programmeur, appelé Représentation Interne, correspond à la mise en oeuvre des Représentations Conceptuelle et Externe.
Cette phase ne s'accompagne d'aucune spécification nouvelle concernant l'utilisateur et n'intégre donc aucun élément d'ergonomie supplémentaire.
L'ordre de présentation que nous venons de faire correspond à l'ordre usuel de conception comme nous l'indiquons dans le schéma ci-dessous:
On peut modifier cet ordre, en partant d'abord de la Représentation 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 même personne, à condition qu'elle se mette effectivement à concevoir l'application avec des points de vue multiples.
Afin d'améliorer la communication homme-machine, il est nécessaire de recueillir le maximum d'information concernant le traitement de l'information en général par l'homme et plus particulièrement 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 particulièrement opérationnel pour la conception d'applications interactives adaptées aux utilisateurs.
En ce qui concerne la psychologie cognitive , nous avons retenu les concepts suivants:
- il existe différents types d'utilisateurs qui, pour des raisons variées, n'utilisent pas le même logiciel de la même manière
- il y a une différence fondamentale entre la logique de fonctionnement de l'ordinateur et la logique d'utilisation par l'homme de cet ordinateur
- on doit distinguer les tâches prévues et les tâches effectivement mises en oeuvre par les utilisateurs
- on peut faire l'hypothèse que la résolution d'une tâche par un homme s'organise selon le modèle de la planification hiérarchique
- les caractéristiques de la mémoire à court terme chez l'homme ont un impact direct sur le dialogue homme-machine
- une partie de l'apprentissage passe par la création d'automatismes..
Les quatre premiers concepts sont développés dans le chapitre 2 car ils ont un impact direct sur la conception de la Représentation conceptuelle; les deux derniers sont développés dans le chapitre 3 car ils sont utilisés plutôt pour la conception de la Représentation Externe.
L'ergonomie est l'étude de l'homme en condition de travail en général 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 paramètres suivants que nous développons au chapitre 3 car ils ont un impact direct sur la conception de la Représentation Externe:
- le séquencement des opérations définit l'enchaînement des opérations tel qu'il est autorisé par le logiciel; l'enchaînement peut être totalement libre ou guidé par l'arborescence d'un menu
- le langage d'interaction concerne les commandes et les données échangées entre l'homme et l'ordinateur aux niveaux lexical et syntaxique
- les dispositifs d'entrée définissent les possibilités physiques d'entrée des données et des commandes dont dispose l'utilisateur
- les dispositifs de sortie désignent les possibilités d'affichage des informations, qui dépendent à la fois du matériel et du logiciel
- le temps de réponse perçu par l'utilisateur est étroitement dépendant de l'organisation des données et des programmes
- le traitement des erreurs désigne les possibilités offertes à l'utilisateur pour détecter et corriger ses erreurs
- le guidage définit les aides à l'utilisation et à l'apprentissage incluses dans le logiciel.
Les interactions entre les Représentations Conceptuelle et Externe et les concepts issus de la psychologie cognitive et de l'ergonomie sont représentés dans la figure suivante:
La conception de la Représentation Externe doit intégrer toutes les caractéristiques de l'utilisateur; certains éléments de psychologie cognitive et d'ergonomie sont intégrés directement et d'autres par le biais de la Représentation Conceptuelle (qui la précède).
Il faut remarquer également que les concepts de psychologie cognitive et d'ergonomie ne sont pas complètement indépendants; ce qui est normal étant donné que leur objet d'étude est le même avec des objectifs différents.
Ce fait entraîne que des options prises au niveau de la Représentation Conceptuelle ont un impact sur des éléments d'ergonomie, à savoir le séquencement des opérations, le traitement des erreurs et le guidage.
Nous représentons, sur le tableau suivant, par une étoile le moment où pour la première fois dans le processus de conception, on se préoccupe des différents éléments d'ergonomie:
Il est bien entendu que tous ces éléments auront une "image" dans la Représentation Externe.
L'ensemble des caractéristiques des utilisateurs (psychologie cognitive et ergonomie confondues) peuvent être éclatées en deux sous-ensembles disjoints si l'on s'intéresse au processus de conception.
En effet, il est alors opérationnel de distinguer les caractéristiques qui nécessitent une analyse du travail, de celles qui ont un caractère général et qui s'appliquent quelle que soit la situation de travail.
Les éléments recueillis lors de l'analyse du travail ont un impact sur l'étude de l'existant puis sur les Représentations Conceptuelle et Externe.
Nous voyons clairement sur le schéma suivant que la Représentation Externe, c'est-à-dire ce que voit l'utilisateur, n'est plus conçue uniquement à partir de la logique du système informatique:
Nous représentons le lien qui existe entre les méthodes de conception générale des systèmes informatiques et la méthode particulière de conception des applications interactives sur le schéma suivant:
L'on voit que l'ensemble de notre démarche s'applique pour chaque type de poste de travail et peut se greffer sans problème sur une méthode existante.
Le lien avec la méthode MERISE est développé dans le chapitre 5.
Nous présentons ici la stucture et le contenu des chapitres suivants afin d'indiquer les différentes manières possibles d'aborder cet ouvrage.
Les chapitres 2, 3 et 4 décrivent l'ensemble du modèle des applications interactives et des caractéristiques de l'utilisateur.
Les chapitres 5 et 6 décrivent deux des méthodes que l'on peut associer au modèle.
Le chapitre 2 comprend deux parties; la première expose les concepts de psychologie cognitive qui ont un impact sur la conception de la Représentation Conceptuelle; la deuxième décrit le modèle de la Représentation Conceptuelle d'un type de poste de travail.
Le chapitre 3 présente d'une part les paramètres d'ergonomie, d'autre part le modèle de la Représentation Externe qui intègre toutes les caractéristiques des utilisateurs (y compris la traduction de la Représentation Conceptuelle).
Le chapitre 4 décrit les conséquences des deux premières représentations sur la mise en oeuvre des logiciels correspondants; il présente également les caractéristiques des systèmes de gestion d'écran de multifenêtrage comme élément de mise en oeuvre.
Le chapitre 5 expose une méthode de conception complète de l'application conversationnelle depuis l'étude de l'existant jusqu'à la spécification de la Représentation Externe; cette méthode est illustrée par une étude de cas.
Le chapitre 6 présente une deuxième méthode qui montre comment faire un diagnostic sur un logiciel existant et comment faire un cahier des charges logiciel respectant des contraintes ergonomiques; la méthode de diagnostic est illustrée par un exemple.
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 extérieurs, les correspondants informatiques, les ergonomes, les formateurs.
Il suppose cependant d'avoir des connaissances dans une des méthodes de conception de systèmes informatiques utilisées en informatique des organisations, ou d'avoir pratiqué ce type de conception sur le terrain (sinon certains passages se révèleront obscurs).
On a l'habitude de lire un livre de manière linéaire; cette habitude est induite par les contraintes techniques d'un livre (contraintes qui n'existent pas dans le cas d'un logiciel), et en conséquence ce livre a été conçu de manière à pouvoir être lu de façon linéaire, mais ce n'est pas le seule manière possible.
Pour aller plus vite, un informaticien-analyste ou un formateur peut prendre directement connaissance de la méthode et des exemples (chapitre 5 et 6) et il peut ultérieurement étayer ces connaissances par la lecture du modèle (chapitres 2, 3, 4).
Un intervenant partiel dans le processus de conception (correspondant informatique, ergonome) peut prendre connaissance des concepts de psychologie cognitive et d'ergonomie (première partie des chapitres 2 et 3) puis de la méthode correspondante (chapitre 5).
S'il veut seulement faire un audit d'un logiciel existant, il peut lire en premier la méthode de diagnostic et de conception du cahier des charges (chapitre 6).
Nous représentons les différentes maniéres possibles de lire ce livre sur le schéma suivant:
