Dans ce premier chapitre de présentation du modèle d'applications interactives adaptées aux utilisateurs, nous présentons la Représentation Conceptuelle qui correspond à la spécification de l'application interactive du point de vue de l'analyste.
Comme nous l'avons présenté dans le chapitre 1, la Représentation Conceptuelle intègre certains éléments de psychologie cognitive. Aussi, dans un premier paragraphe, nous présentons les éléments de psychologie cognitive que nous pouvons intégrer à la Représentation Conceptuelle et dans un deuxième paragraphe, nous exposons de manière détaillée le modèle de la Représentation Conceptuelle.
Nous reprenons ci-dessous le schéma présenté au chapitre 1 en indiquant en caractères gras ce qui va être exposé dans ce chapitre.
Notre propos n'est pas ici de faire un exposé général sur la psychologie cognitive mais d'exposer différents concepts qui nous semblent pertinents d'une part pour comprendre les représentations mentales d'un utilisateur de logiciel, d'autre part pour guider l'analyste dans sa conception des applications interactives.
Nous développons ici les concepts suivants :
- l'image opérative qui nous permet de comprendre les images mentales mises en oeuvre dans une tâche spécifique (représentation de tâche)
- la planification hiérarchique qui traite de la décomposition d'une action
- la différence entre utilisateurs novices et expérimentés
- les notions de tâche prévue et tâche effective.
Nous nous référons ici aux concepts développés par Ochanine (Och,72), et repris et approfondis par Sperandio (Spe,80) et Cazamian (Caz, 81).
On appelle "image opérative" les images mentales qui accompagnent l'action de travail. Quand un utilisateur est confronté à un objet dont il reçoit des informations et sur lequel il devra agir, il a une représentation mentale de cet objet.
On appelle structure intégrale l'ensemble des relations existantes entre tous les éléments d'un objet et structure partielle un groupe de relations mis à part pour une raison quelconque.
Pour la réalisation d'une tâche particulière, tous les éléments de la structure intégrale n'offrent pas le même intérêt ; certains éléments peuvent être omis, d'autres au contraire mis en valeur. De manière générale, la réalisation d'une tâche requiert une structure partielle dite structure opérative et la représentation de cette structure par l'utilisateur sera appelée image opérative.
Les images opératives sont un sous-ensemble des images mentales orientées vers l'action. Dans le cas où le but du sujet est simplement de connaître un objet, l'image mentale qu'il aura de cet objet s'approchera ou même s'identifiera à la structure intégrale. Les deux caractères essentiels de cette image opérative sont le laconisme et la déformation fonctionnelle.
- le laconisme : l'image étant un moyen d'action, elle ne retient de l'objet que les seules propriétés nécessaires à l'action.
- la déformation fonctionnelle : c'est une réplique déformée de l'objet, mais déformée par l'accentuation de ce qui est fonctionnellement important pour une tâche donnée dans un contexte donné.
Pour illustrer ces concepts nous donnons deux exemples :
- le premier exemple concerne la confrontation de deux images opératives de deux personnnes différentes. Nous sommes dans une salle de contrôle d'une centrale thermique où un opérateur doit contrôler près d'un millier de paramètres. Pour l'aider à interpréter les signaux, l'ingénieur lui fournit un schéma de fonctionnement global de l'installation. Mais on s'aperçoit que ce schéma ne constitue pas une aide mais un gêne car l'image opérative de l'opérateur est très éloignée de ce schéma. Dans son image opérative les parties très automatisées et très fiables ont quasiment disparu et certaines parties posant fréquemment des problèmes sont surévaluées.
Le schéma global est opératif pour l'ingénieur 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 deuxième exemple concerne des médecins novices et expérimentés.
Trois groupes de médecins (spécialistes expérimentés, généralistes, novices), sont confrontés à des cas réels de maladie de la thyroïde. Après palpation et examens, on demande à chaque médecin d'exprimer sa représentation mentale de la glande malade par un modelage. Les résultats montrent que les médecins les plus qualifiés produisent des modelages présentant des déformations importantes par rapport à la réalité, en ce sens que les parties atteintes de la glande sont hyper-déformées par le modelage ,ce qui correspond à une déformation fontionnelle permettant d'aboutir au bon diagnostic.
Par contre les médecins débutants ou moins qualifiés produisent des modelages plus conformes au réel mais moins riches en informations pertinentes.
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 représente le travail qu'il a à faire pour atteindre son objectif. La réponse à cette question a un double intérêt en informatique car elle peut permettre à la fois une meilleure utilisation et un meilleur apprentissage si le modèle présenté à l'utilisateur se rapproche le plus possible de sa logique d'utilisation.
Le problème posé ici se distingue de celui de la représentation mentale de l'objet étudié (image mentale ou opérative) en ce sens que l'image mentale correspond à la partie statique (structure des données) et la planification hiérarchique à la partie dynamique (structure des traitements).
L'hypothèse de la planification hiérarchique est que l'utilisateur va élaborer un plan d'action à partir du but qu'il souhaite atteindre.
Cette hypothèse nous semble étayée par les travaux faits par Graesser (Gra,81) sur la mémorisation :
- une information structurellement ordonnée est mieux mémorisée, le rappel se faisant par les structures de plus haut niveau.
- un élément conceptuellement relié à d'autres (déjà mémorisés) est mieux mémorisé qu'un élément isolé.
Ce plan d'action lui permettra de raisonner à des niveaux de détail différents en passant par la définition de sous-buts intermédiaires nécessaires à l'accomplissement du but. Certains de ces sous-buts doivent être nécessairenent réalisés, les autres sont optionnels, c'est-à-dire qu'ils ne sont formulés qu'en cours d'exécution de l'action lorsque l'utilisateur se rend compte que certaines conditions requises pour l'exécution d'un sous-but ne sont pas remplies. Ces sous-buts ne font pas partie du schéma initial de l'action, ils sont générés par l'utilisateur en cours d'exécution.
La description d'un sous-but comporte :
- une suite d'actions à réaliser
- l'état final obtenu par la réalisation de la suite d'actions
- les pré-requis qu'il est nécessaire de vérifier avant que l'on puisse exécuter la liste d'actions.
Dans le cadre de la description du travail de bureau, ou plus généralement du travail tertiaire, cette décomposition en sous-buts et pré-requis peut être d'une grande souplesse car elle permet ultérieurement à l'utilisateur de se servir de ces sous-buts dans des contextes différents, sans imposer une programmation rigide.
Cette méthode de travail peut servir d'une part à étudier des contextes particuliers de travail pour rendre le plus fidèlement possible la logique d'utilisation de l'opérateur, d'autre part à essayer de trouver des sous-buts invariants d'une tâche à l'autre qui pourraient servir d'éléments constructifs pour la réalisation de n'importe quel but.
L'existence d'utilisateurs expérimentés et débutants (ou occasionnels) pose deux types de questions :
- existe-t-il des différences de comportements entre ces deux catégories ?
- comment se fait l'apprentissage, c'est-à-dire le passage d'une catégorie à l'autre ?
Nous avons déjà vu qu'il existe des différences au niveau des images opératives, c'est-à-dire que plus l'utilisateur est expérimenté, plus il y a une déformation fonctionnelle de l'image opérative.
On peut noter aussi une différence entre les procédures choisies et les résultats obtenus pour réaliser un même objectif. Pour illustrer cette différence, nous nous référons à une étude publiée par Bisseret (Bis,79) portant sur l'effet de l'expérience sur les contrôleurs aériens.
Face à une situation donnée de positions d'avions, le contrôleur doit décider s'il va y avoir un conflit ou non, c'est-à-dire si deux avions risquent de se rencontrer, auquel cas il doit détourner un des deux. Les mêmes situations ont été exposées à un groupe de débutants et à un groupe de contrôleurs expérimentés.
Les résultats montrent que les débutants sont plus discriminants que les expérimentés; en effet, les débutants classent tous les cas dans une des deux catégories de conflit ou de non-conflit alors que les expérimentés 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 expérimentés se montrent ainsi plus prudents même s'ils sont amenés à détourner plus d'avions que les débutants.
Au niveau de l'activité cognitive, il semble que les expérimentés ont un jugement plus rapide fondé sur une catégorisation grossière des situations, alors que les débutants cherchent à calculer pour connaître avec précision la distance séparant deux avions.
Nous n'avons pas d'exemple d'études de différence portant sur le travail de bureau, mais ces résultats ont un caractère assez général pour que l'on puisse en déduire que l'on devrait observer ces différences aussi dans ce secteur. Par contre,l'absence d'études ne nous permet pas de dire sur quels éléments porteraient ces différences.
Nous ne voulons pas traiter ici le problème général de l'apprentissage mais seulement celui de l'apprentissage d'un outil comme l'ordinateur. Nous faisons référence ici aux travaux développés par Richard (Ric,83), (Ric,87) qui étudie la différence 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 résultat 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 procédure à élaborer pour atteindre un but ne peut être déduite directement de la connaissance des règles de fonctionnement ; elle ne peut pas être non plus, dans le cas général, un simple calque de la procédure manuelle.
Pour réaliser à l'aide d'un ordinateur une tâche que l'on sait résoudre par ailleurs, il faut modifier sa représentation du problème en définissant 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 définir des règles d'utilisation qui précisent les actions qu'il est possible de réaliser et comment le faire.
Les commandes de l'ordinateur ne peuvent, dans le cas général, correspondre à des actions de l'utilisateur car les commandes sont définies par rapport à la sémantique du dispositif et les actions ont un sens pour l'utilisateur dans le contexte des tâches qu'il a à accomplir.
Dans une logique d'utilisation, on pourrait donner l'ensemble des procédures à suivre pour arriver à certains buts mais, dans le cas général, on ne connaît pas à l'avance l'ensemble des tâches auxquelles peut être utilisé un dispositif, et donc on ne peut élaborer un ensemble exhausif de procédure.
L'objectif sera donc de définir des actions qui ne correspondent pas à des buts précis mais qui seront des procédures pour la réalisation de ces tâches. c'est-à-dire que l'on aura fait pour l'utilisateur le passage des règles de fonctionnement aux composants d'utilisation.
Dans l'optique de la logique de fonctionnement, le problème qui demeure est de déterminer les bonnes règles d'utilisation à faire apprendre, celles qui correspondent à des actions que le sujet se donne comme objectifs intermédiaires.
Pour distinguer la tâche de l'activité, nous nous référons à Leplat et Hoc (Lep,83): "Toute analyse de situation dans une perspective psychologique amène à s'interroger sur les rapports entre une tâche 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 manière générale, la tâche indique ce qui est à faire, l'activité ce qui se fait.
Pour être plus précis, nous définissons la tâche comme la réalisation d'un but donné dans des conditions déterminées.
Le but est l'état final. Il peut être décrit par des critères et la valeur qu'ils doivent prendre.
Il existe souvent plusieurs manières équivalentes de décrire le but. Un but peut être décrit et évalué par un procédé qui ne correspond pas à celui mis en jeu pour le réaliser.
Les conditions peuvent être décrites de plusieurs manières :
- par l'ensemble des états à parcourir avant d'atteindre l'état final ;
- par les opérations admissibles pour parcourir ces états ;
- par la procédure à mettre en oeuvre pour ce faire, c'est-à-dire la combinaison de ces opérations.
L'ensemble des états sera défini par :
- la donnée d'un état initial ;
- un découpage temporel du processus en états identifiables ;
- une description des états en valeur de variables qui les caractérisent.
L'ensemble des opérations admissibles dans la transformation des états sera appelé le dispositif associé à la tâche.
L'ensemble des procédures peut être décrit soit en explicitant la combinaison des opérations sous forme d'algorithme (mode procédural), soit en donnant les propriétés qu'elle doit respecter (mode déclaratif).
La tâche prévue est la tâche conçue par celui qui en commande l'exécution.
La description d'une tâche est complète pour un sujet donné quand elle lui permet l'exécution immédiate de la tâche sans nouvelles acquisitions préalables.
Une tâche dont la description est complète ne requiert donc du sujet qu'une activité d'exécution.
Une tâche dont la description est incomplète requiert du sujet une activité d'élaboration en plus de l'activité d'exécution proprement dite.
L'activité est ce qui est mis en oeuvre pour exécuter la tâche.
La tâche effective correspond à ce que l'utilisateur fait effectivement. La tâche effective n'est pas un décalque de la partie observable de l'activité. Dans la mesure, par exemple, où elle définit une procédure, elle est dérivée de certains comportements et prend aussi en compte ce qu'on sait des règles de fonctionnement du système cognitif. La tâche effective constitue donc un modèle de l'activité. La validation du modèle que constitue la tâche effective se fera par la confrontation des prédictions de ce modèle avec des traces observables de l'activité.
Nous reprenons dans ce paragraphe les concepts présentés ci-dessus en leur donnant une interprétation utilisable pour la conception des logiciels interactifs.
Du concept d'image opérative, nous pouvons retirer trois idées 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 résolution du problème du dialogue passe par l'utilisation et la compréhension du langage naturel. Cette idée peut être vraie pour des utilisateurs occasionnels non spécialisés. Mais dans le cas de spécialistes d'une tâche, il se crée un vocabulaire spécialisé, opératif, non ambigu qui est fonctionnel et adapté à la tâche. Le rôle de l'analyste est alors de repérer ce vocabulaire et de permettre son utilisation.
- l'image opérative varie selon la fonction des différents utilisateurs. En particulier, l'analyste informaticien et l'utilisateur ont très peu de chance d'avoir la même image opérative des tâches à accomplir. L'analyste a une vision globale et abstraite des procédures de traitement de l'information alors que l'utilisateur a une image locale et concrète de ces mêmes tâches.
- l'image opérative et les processus de décision varient selon le degré d'expérience des utilisateurs. Il faut donc prévoir des présentations différentes du même logiciel pour des utilisateurs de niveau d'expérience différent.
La planification hiérarchique correspond à une description du travail orientée-but qui part du résultat que veut atteindre l'utilisateur pour remonter jusqu'aux actions élémentaires nécessaires à la réalisation du but.
Ce type de description n'est pas usuel dans la conception des systèmes d'information où au contraire on fait des descriptions procédurales à partir d'événements d'entrée jusqu'aux événements de sortie. Ces deux démarches ne sont pas simplement inverses l'une de l'autre car le résultat obtenu n'est pas le même:
- dans la description orientée-but, on obtient un ensemble d'opérations nécessaires à la réalisation du but ; des procédures différentes seront regroupées si elles aboutissent au même but ; cette description permet de décrire aisément tous les parallélismes et correspond à la logique d'utilisation.
- dans la description orientée-événement, on obtient l'enchaînement des opérations déclenchées par un ou des événements initiaux ; cette description correspond à la logique de fonctionnement du Système d'Information et décrit les différentes procédures indépendamment de leurs utilisations.
Il n'y a que dans le cas simple où un but est obtenu par la réalisation d'une procédure déclenchée par un événement que ces deux méthodes de description aboutissent au même résultat.
La planification hiérarchique s'applique à notre avis de façon privilégiée pour les raisonnements guidés par les traitements et non pas guidées par les données, c'est-à-dire quand l'enchaînement des opérations est quasi indépendant de la valeur des données ou que cette dépendance ne crée pas une explosion combinatoire de l'arborescence.
Dans l'entreprise, les postes de travail des décideurs correspondent davantage à des modes de travail guidés par les données alors que les postes d'exécution sont plutôt guidés par les traitements.
Pour la conception des appplications interactives, la distinction entre logique de fonctionnement et logique d'utilisation nous semble particulièrement précieuse. En effet, la plupart des logiciels interactifs sont élaborés et présentés à l'utilisateur selon une logique de fonctionnement. Ce résultat peut apparaître normal car, après l'application d'une méthode 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 complétées par expérimentation sur prototype. La méthode de recueil des logiques d'utilisation est décrite dans le chapitre quatre.
En ce qui concerne la distinction entre tâche prévue et tâche effective, on peut se demander quel type de tâche l'on recueille lors d'une étude de l'existant classique?
Les méthodes d'analyse ne disent rien à ce sujet; ce qui a pour conséquence qu'en pratique cela dépend de la façon dont on a mené cette étude :
- si on a interrogé essentiellement des responsables, on a beaucoup de chances d'avoir recueilli des tâches prévues.
- si on a interrogé des utilisateurs effectifs, on a plus de chance d'avoir recueilli des tâches effectives ou un mélange de tâches effectives et de tâches prévues.
Pour pouvoir distinguer les différents types de tâches, il faut que l'analyste modifie sa façon de mener les interviews en fonction de cette préoccupation et complète éventuellement son étude par des simulations ou des observations. Pour plus de précision, nous renvoyons également au chapitre quatre.
Les différents concepts que nous venons d'exposer ne sont pas indépendants ; nous représentons ces relations sur le schéma suivant :
La planification hiérarchique permet de trouver la logique d'utilisation pour un but donné.
Les variabilités de la représentation se traduiront soit par des logiques d'utilisation différentes, soit par les notions de tâches prévues et de tâches effectives.
Pour décrire les tâches prévues et effectives, on peut utiliser la planification hiérarchique.
Les concepts de psychologie cognitive, développés précédemment, concernent d'une part la représentation des traitements de l'information de l'utilisateur d'autre part les variabilités de cette représentation . Nous résumons ici les concepts que nous avons retenus pour la définition de la Représentation Conceptuelle d'une application interactive.
Nous avons retenu deux notions :
- le concept de planification hiérarchique permet de décrire le travail de l'utilisateur en partant des buts qu'il se fixe (ou qui lui sont fixés) et de remonter jusqu'à l'ensemble des opérations et des pré-requis nécessaires à la réalisation de ses buts,
- la différence 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.
La représentation du traitement de l'information, que nous venons d'évoquer, n'est pas unique pour une tâche donnée ; cette variabilité est due à deux causes :
- la déformation fonctionnelle de la tâche qui provient d'une part des différents objectifs de travail des utilisateurs, d'autre part du degré d'expérience professionnelle des différents utilisateurs,
- la différence entre la tâche prévue et les tâches effectives ; la tâche prévue décrivant la tâche standard telle qu'elle est décrite dans le cas normal ; les tâches effectives décrivant les différentes adaptations de la tâche prévue réalisées par l'utilisateur afin de pouvoir réguler son travail en fonction des aléas de l'environnement.
La Représentation Conceptuelle, qui correspond, comme nous l'avons vu au chapitre 1, au premier niveau de représentation de l'application interactive par l'analyste informaticien, intègre d'une part la description des données des traitements et d'une partie de l'interface (le reste étant défini au niveau de la Représentation Externe), d'autre part la représentation du traitement de l'information de l'utilisateur et la variabilité de ces représentations.
Dans l'exposé du modèle de la Représentation Conceptuelle, il est nécessaire de distinguer les paramètres variables provenant des caractéristiques particulières d'une application des paramètres constants qui sont présents dans toute application interactive.
Les paramètres variables sont issus de l'analyse du travail; il s'agit, par exemple, des buts ou de la logique d'utilisation.
Les paramètres constants sont issus des caractéristiques générales des utilisateurs; il s'agit, par exemple, des possibilités d'interrompre à tout moment ou de transférer des données.
Comme nous le montrons à la fin de ce chapitre, pour des raisons de lisibilité et d'efficacité, seuls les paramètres variables sont représentés dans les schémas décrivant la Représentation Conceptuelle.
Contrairement aux méthodes d'analyse usuelle qui ont des représentations conceptuelles pour chaque fonction du système d'information de l'entreprise, nous aurons une Représentation 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 décomposées en traitements qui correspondent à la quantité de travail que peut effectuer un être humain. A ce découpage se superpose pour des raisons de pilotage et de contrôle de l'entreprise une organisation c'est-à-dire un ensemble de chaînes de pilotage permettant de passer des projets à long terme à une gestion quotidienne (Mel,77).
Un poste de travail sera donc décrit par des objectifs ou buts correspondant à la décomposition des fonctions et un niveau de responsabilité correspondant à sa place dans la chaîne de pilotage.
Nous parlerons de type de poste de travail pour désigner l'ensemble des postes de travail ayant les mêmes objectifs et les mêmes niveaux de responsabilité.
Nous venons d'insister sur la définition du poste de travail car tous les concepts que nous verrons maintenant se situent par rapport au poste de travail.
Généralement, dans les méthodes d'analyse de gestion, la description du travail est de type opérationnel : elle part d'événements déclenchants (ex: un bon de commande arrivant dans l'entreprise) et elle suit le cheminement de cet événement tout au long des transformations qu'il subit jusqu'à la fin du processus. Nous appellerons cette démarche descendante dans le sens où elle décrit le système d'information depuis les événements initiaux jusqu'aux événements terminaux.
Dans notre Représentation Conceptuelle, nous avons décidé d'utiliser une démarche inverse qui est plus proche de nos connaissances du fonctionnement des opérateurs.
Dans notre démarche que nous appellerons ascendante, nous partirons de la description du (ou des) but(s) du poste de travail pour remonter jusqu'aux événements initiaux. Le but se définit à la fois par rapport à l'organisation et par rapport au poste de travail. Il permet d'une part à l'utilisateur de réguler son activité, d'autre part à l'organisation de juger les performances du poste de travail par rapport aux objectifs globaux. Les buts sont définis au minimum pour permettre la survie du système.
Nous prendrons la définition de la tâche développée en ergonomie.
La tâche est décrite par un but (état final) et des conditions ; les conditions peuvent être décrites de l'une des trois façons suivantes :
- l'ensemble des états à parcourir pour atteindre le but
- les opérations admissibles pour parcourir ces états
- la procédure ou combinaisons de ces opérations.
L'activité est une occurrence de réalisation d'une tâche ; à une tâche correspondront plusieurs activités.
Dans toute la suite de cet exposé, nous choisissons de décrire les conditions d'une tâche par une procédure, parce que c'est l'approche qui convient le mieux à la majeure partie des postes de travail concernés par l'automatisation, c'est-à-dire les postes de responsabilité de niveau moyen ou faible (où les raisonnements sont guidés par les traitements). Pour les postes de haute responsabilité (où les raisonnements sont guidés par les données), une approche Intelligence Artificielle basée sur les opérations admissibles serait plus indiquée.
Nous définissons :
- le but, comme l'état final que doit atteindre le système homme-machine. Cet état final sera décrit par des critères et la valeur qu'ils doivent prendre, le même but peut être décrit de plusieurs manières équivalentes.
- la procédure, comme une combinaison d'opérations permettant d'atteindre le but ; elle sera décrite par:
- une liste d'opérations
- une liste de pré-requis, chaque pré-requis exprimant les conditions qui doivent être réalisées pour qu'une opération puisse être effectuée.
Dans le cas général, la notion de pré-requis permettra d'exprimer la notion de parallélisme, particulièrement importante dans le cas d'applications interactives pour augmenter les possibilités d'ajustement et de souplesse de l'utilisateur.
Selon leur complexité, les opérations pourront être décomposées en plusieurs niveaux.
La plus petite décomposition possible sera appelée opération élémentaire ; elle correspond à la plus petite unité de traitement de l'information (commande ou donnée) qui ait un sens pour l'opérateur.
Le but, en fonction de sa complexité et de sa nature, pourra lui aussi être décomposé en sous-but, sous-sous-but... jusqu'à ce que l'on arrive à un niveau de traitement de l'information facilement manipulable.
Les notions de but, opération, pré-requis font référence exclusivement à la représentation mentale que l'utilisateur a de son travail (logique d'utilisation) ; à aucun moment nous ne faisons référence ici à un découpage correspondant à la logique du traitement informatique ce qui a pour conséquence que nous n'obtiendrons pas forcément le même découpage.
Nous allons illustrer ces différences de découpage des traitements sur un exemple.
Exemple de gestion de documents de bibliothèque
La première décomposition de cette fonction en opérations correspond à un découpage "informatique" (logique de fonctionnement) où le découpage et les regroupements correspondent à la structure des données et aux traitements effectués sur ces données (création, impression, destruction, consultation) . Nous avons un fichier thesaurus et un fichier documents, ce qui donne le découpage suivant :
La deuxième décomposition correspond à une logique d'utilisation et nous avons donc à définir les sous-buts assignés à ce poste de travail concernant le but "gestion des documents".
L'analyse du travail montre que nous avons deux sous-buts :
- enregistrer
- consulter.
Pour "enregistrer", la liste des opérations possibles est la suivante :
- gérer les documents (création, modification, suppression)
- gérer le thesaurus (création, modification, suppression de mots-clés ou de liens)
- consulter le thesaurus.
Pour "consulter", la liste des opérations possibles est la suivante :
- consulter les documents (recherche à partir de critères ou de mots-clés)
- consulter le thesaurus
- imprimer les résultats.
Il n'y a pas de précédences spécifique à l'application autre que celles implicites liées à la gestion des données (on ne peut modifier, consulter ou détruire une information qui n'a pas été créée).
La représentation visuelle peut se présenter comme suit :
Nous remarquons que l'opération "consulter le thesaurus" figure dans les deux sous-buts, cela signifie que l'opérateur peut avoir besoin de cette opération dans chacun de ces sous-buts et qu'il pourra ainsi y accéder sans repasser par une arborescence de commandes.
Note : il resterait à redécouper les sous-buts intermédiaires :
- consulter le thesaurus
- gérer le thesaurus
- gérer les document
- imprimer
- consulter le document.
fin de l'exemple.
De manière générale, une même opération pourra appartenir à plusieurs buts, une même opération élémentaire pourra appartenir à plusieurs opérations.
Le critère essentiel est que l'utilisateur ait "sous la main" toutes les opérations dont il peut avoir besoin pour réaliser un but donné ( la duplication logique des opérations n'implique aucune duplication physique sur les supports informatiques).
Pour tenir compte de la variabilité d'exécution d'une tâche donnée, nous décrirons plusieurs procédures pour une même tâche, le but restant identique. Nous définissons :
- la procédure prescrite (ou prévue) correspondant à la procédure standard ou recommandée qui est la plupart du temps, celle qui est spontanément recueillie par les analystes (interview).
- la procédure effective étant celle qui est effectivement mise en oeuvre par un utilisateur donné et qui est souvent recueillie par observation.
- la procédure minimale comme l'ensemble des opérations et des enchaînements minimaux nécessaires pour que le but de la tâche puisse être considéré comme atteint par l'ordinateur.
Pour une tâche donnée il y aura une procédure minimale, une procédure prescrite et plusieurs procédures effectives.
Les procédures effectives et la procédure prescrite devront être compatibles avec la procédure minimale.
Cette compatibilité peut s'exprimer de manière formelle mais nous voudrions ici justifier de manière intuitive ces différentes notions et leurs relations avec l'utilisateur.
Dans la définition d'une application interactive, on fixe, la plupart du temps implicitement, la répartition du pilotage entre l'homme et l'ordinateur.
Le pilotage d'une tâche (ou d'un ensemble de tâches), recouvre deux notions:
- la notion de contrôle de l'exécution de la tâche
- la notion de régulation qui laisse au pilote la possibilité de modifier certaines conditions d'exécution de la tâche de manière à atteindre l'objectif fixé quels que soient les aléas provenant de l'environnement.
La régulation des tâches relève, dans le cas de l'informatique des organisations, quasi exclusivement de la responsabilité de l'utilisateur. En effet, les caractéristiques propres d'un système d'information d'une organisation sont, d'une part d'être ouvert sur son environnement (ce qui rend très difficile sinon impossible l'établissement d'une liste exhaustive de l'ensemble des informations d'entrées de l'organisation), d'autre part de gérer une très grande variété d'informations d'origines diverses (organisationnelles, psychologiques, sociologiques, techniques) qu'il est souvent difficile d'expliciter et de spécifier. Il s'en suit que les circonstances qui réclament une intervention régulatrice ne peuvent pas être définies formellement et encore moins la nature de ces interrelations.
On appelle latitude décisionnelle la part de pilotage qui est sous la responsabilité de l'utilisateur.
Dans le cas général, le contrôle de l'exécution d'une application interactive est partagé implicitement entre l'homme et l'ordinateur selon des proportions très variables qui peuvent évoluer entre deux situations extrêmes qui vont du pilotage entièrement automatisé au pilotage entièrement assumé par l'utilisateur.
Quand le pilotage est laissé entièrement à l'utilisateur, aucun séquencement des écrans n'est imposé à l'utilisateur. Il active les traitements, dans un ordre totalement libre. Le seul contrôle qui est fait par l'ordinateur porte sur l'existence des données manipulées dans les traitements.
Dans ce cas nous laissons de côté trois aspects :
- aucun contrôle n'est effectué sur la cohérence de la procédure par rapport au but fixé
- il n'y a pas de prise en compte du travail de l'utilisateur en tant qu'individu intégré dans une organisation dont le travail a un sens par rapport à cette organisation.
- l'ordinateur n'est pas utilisé au maximum de ses possibilités. On se prive par exemple de la possibilité de faire des enchaînements automatiques ou des inférences.
Ce type de logiciel est en fait très bien adapté pour des postes où les tâches sont peu structurées et qui peuvent travailler de manière relativement isolée par rapport au reste de l'organisation.
Par contre, quand le pilotage est entièrement laissé à l'ordinateur, il y a la garantie d'une cohérence maximale du système d'information de l'entreprise mais au détriment de :
- la souplesse de mise en oeuvre pour l'utilisateur
- la facilité d'intégrer des variabilités et des aléas.
Pour notre part, nous voulons nous situer de manière plus générale par rapport au pilotage ; les deux cas extrêmes que nous venons de citer devenant deux cas particuliers de notre modèle.
Pour cela nous proposons un modèle qui permet d'expliciter et de décrire :
- 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 procédure minimale qui définit, pour une tâche donnée, les contrôles qui doivent être effectués obligatoirement par l'ordinateur quel que soit le type de procédure prescrite ou effective que l'utilisateur décide de mettre en oeuvre. La procédure minimale définit, a contrario, les limites de la latitude décisionnelle de l'utilisateur. En effet, tout ce qui ne sera pas explicitement défini au niveau des enchaînements et des déclenchements d'opérations dans la procédure minimale sera considéré comme laissé à la libre disposition de l'utilisateur et ne fera en tout état de cause l'objet d'aucun contrôle systématique de l'ordinateur.
A partir de cette procédure minimale, l'utilisateur peut se définir une procédure prescrite (ou standard) et une ou plusieurs procédures effectives qu'il utilisera à sa convenance et qui le déchargeront dans des cas connus et répertoriés du contrôle de l'exécution de la procédure. Mais il pourra à tout moment "reprendre la main" afin d'imposer son propre pilotage (dans les limites de sa latitude décisionnelle) face à une situation imprévue.
On voit donc que la notion de procédure minimale permet de définir une application interactive ouverte en ce sens qu'il n'est pas utile de définir a priori l'ensemble des procédures effectives mais qu'elles pourront être définies au fur et à mesure des besoins et qu'il nous suffira de vérifier la compatibilité de chaque nouvelle procédure effective avec la procédure minimale.
Pour construire la procédure minimale d'une tâche nous pouvons soit procéder directement si la part de contrôle que l'on doit donner à l'ordinateur est évidente, soit l'extraire de la procédure prévue. Dans ce dernier cas, nous remarquons que la procédure prévue décrit des éléments de nature différentes :
- d'une part les règles de gestion indispensables pour assurer la cohérence et la survie du système.
- d'autre part des règles de commodité, d'usage, dites de "bon sens" qui peuvent être transgressées sans remettre en cause le système mais qui permettent, associées aux règles de cohérence, de décrire une procédure usuelle.
Nous construirons alors la procédure minimale à partir de la procédure prévue dont nous n'aurons retenu que les règles de cohérence correspondant au contrôle que nous souhaitons confier à l'ordinateur.
Nous allons définir de manière plus précise les propriétés des opérations et des pré-requis afin de faire le lien avec la structure des traitements et des données. Nous distinguons les propriétés usuelles de celles permettant de décrire la répartition du pilotage entre l'homme et l'ordinateur.
Une opération sera définie comme un ensemble de transactions pouvant être exécutées consécutivement sans attente d'événements externes au système homme-ordinateur (c'est-à-dire que toutes les informations nécessaires au déroulement de l'opération sont soit disponibles en machine soit connues de l'utilisateur). Elle sera décrite par ses entrées, sa nature, son déclenchement, son statut, ses sorties :
- ses entrées sont la liste des événements qui peuvent permettre son déclenchement. Un événement sera décrit par un nom et la structure de donnée qui lui est associée.
Un événement initial sera un événement qui n'est pas une sortie d'opération.
Un événement terminal sera un événement qui n'est pas une entrée d'opération.
- sa nature sera interactive, automatique ou manuelle :
. une opération est interactive si son déroulement met en oeuvre des actions de l'utilisateur et de l'ordinateur
. une opération est automatique si son déroulement met en oeuvre exclusivement des actions de l'ordinateur
. une opération est manuelle si son déroulement met en oeuvre exclusivement des actions de l'utilisateur.
Par définition, seules les opérations interactives et automatiques sont décrites dans la R.C d'une application interactive. Les opérations manuelles étant décrites au niveau plus global du système d'information existant ou concu.
- au cours d'une exécution son statut est activable ou non :
une opération est activable si les conditions du pré-requis sont réalisées.
- ses sorties sont des événements qui pourront déclencher d'autres opérations.
Les pré-requis recouvrent deux notions distinctes ; d'une part la notion de synchronisation, d'autre part la notion de précondition .
La synchronisation est une proposition logique (booléenne) portant sur la liste des événements d'entrée de l'opération Oi
(A .ET. B) .OU. C peut constituer une synchronisation c'est-à-dire que Oi deviendra activable quand soit les événements A et B seront réalisés (ou vrai) soit l'événement C.
A la synchronisation on associera également la notion de délai qui correspond à une règle de temps concernant le déclenchement d'une opération Oi quand celle-ci est devenue activable:
- délai nul : l'exécution de Oi devra avoir lieu dès que Oi est activable
- délai libre : l'exécution de Oi pourra avoir lieu à n'importe quel moment après son activation
- délai avec bornes : Oi devra être déclenché avant une date D1 et après une date D2.
Les préconditions expriment une condition sur la valeur des données contenues dans l'événement, conditions qui doivent être vraies pour que l'événement soit considéré comme réalisé.
On peut déduire des pré-requis, la notion de précédence entre opérations. La précédence exprime un lien de priorité d'exécution entre opérations. Si P (Oi, Oj) est satisfait cela signifie que Oi doit être exécuté avant Oj.
Pour préciser le pilotage nous sommes amenés à rajouter des propriétés aux opérations et pré-requis :
- une opération est obligatoire ou facultative :
. une opération est obligatoire si son exécution, quand elle est activable, est nécessaire pour atteindre le but.
. une opération est facultative si son exécution ou sa non exécution n'interdit pas d'atteindre le but.
- le déclenchement d'une opération est optionnel ou systématique :
. le déclenchement de l'opération est optionnel s'il dépend de l'utilisateur
. le déclenchement de l'opération est systématique s'il dépend de l'ordinateur.
- une précédence est permanente si elle existe dans toutes les descriptions procédurales de la tâche (procédure minimale, prévue, effective)
- une précédence est indicative si elle existe dans une ou plusieurs procédures effectives ou prescrites sans exister dans la procédure minimale.
Il est important de noter que les propriétés de pilotage sont propres à un but.. Cela veut dire qu'une même opération qui appartiendra à deux buts B1 et B2 peut être obligatoire dans B1 et facultative dans B2, et il en sera de même pour les précédences.
La signification de ces propriétés par rapport à la notion de pilotage est la suivante :
- une opération obligatoire est pilotée par l'ordinateur, c'est-à-dire qu'il contrôle son exécution. Le but sera considéré comme atteint par l'ordinateur si toutes les opérations obligatoires activables ont été réalisées.
- une opération facultative est pilotée par l'utilisateur qui en contrôle l'exécution.
Soit en reprenant l'exemple précédent de la gestion de documents;
opérations OBLIGATOIRE :
gérer document, GD
gérer thesaurus, GT
Sous-but 1 (SB1)
opérations FACULTATIVE :
consulter thesaurus
rechercher document
impression
Sous-but 2 (SB2)
SB1 sera considéré comme atteint par l'ordinateur si, pour une occurrence de donnée, GD et GT ont été réalisés. Le But sera considéré comme atteint par l'ordinateur si, pour une occurrence de donnée, SB1 a été atteint.
Toutes les autres opérations sont laissées à la libre utilisation de l'utilisateur et leur exécution ou non ne fait pas l'objet d'un contrôle par l'ordinateur.
Pour les précédences, nous avons le même type de signification :
- une précédence permanente est pilotée par l'ordinateur qui contrôle ainsi le déclenchement de l'opération associée
- une précédence indicative est pilotée par l'utilisateur qui peut à sa demande être guidé dans le déroulement de la procédure.
Les notions que nous venons de définir sont valables pour toutes les procédures sans distinction de procédure prévue, minimale ou effective.
La procédure minimale exprime le contrôle minimal sur l'utilisateur : elle laisse un pilotage maximal de son travail à l'utilisateur.
Les procédures prévues et effectives sont des variantes possibles de la procédure minimale qui d'une part restreignent le pilotage de l'utilisateur, d'autre part lui facilitent son travail (enchaînements automatique, guidage...).
Nous allons examiner les rapports entre les différentes propriétés. Nous examinerons tout d'abord le lien entre les propriétés d'une opération puis entre opérations et pré-requis.
Les rapports entre les propriétés des opérations
Nous rappellons qu'une opération est définie par ses entrées, sa nature, son déclenchement, son statut, ses sorties, son caractère obligatoire ou facultatif.
Nous examinons les relations entre :
- déclenchement et obligatoire/facultatif
- déclenchement et nature
- nature et obligatoire/facultatif
- déclenchement et événement d'entrée.
Les autres propriétés sont de toute évidence totalement indépendantes.
Rapport entre déclenchement et obligatoire/facultatif
Ces deux propriétés ne sont pas indépendantes. En effet, si une opération est facultative son déclenchement est nécessairement optionnel puisque seul l'utilisateur peut savoir si cette opération doit ou non être déclenchée.
Nous avons l'implication :
facultatif => optionnel
qui équivaut à :
systématique => obligatoire.
Le déclenchement systématique ne peut donc avoir lieu que si l'opération est obligatoire. Par contre, une opération obligatoire peut avoir un déclenchement optionnel ou systématique.
Rapport entre déclenchement et nature
Dans la description de la R.C d'une application interactive, une opération ne peut être qu'interactive ou automatique. Si l'opération est interactive, son déclenchement peut être optionnel ou systématique. Si l'opération est automatique, son déclenchement peut être optionnel ou systématique. Ce qui revient à dire que nature et déclenchement sont indépendants.
Rapport entre nature et obligatoire/facultatif
Ici aussi nous avons deux propriétés indépendantes car une opération interactive ou automatique peut être indifféremment obligatoire ou facultative.
Rapport entre déclenchement et événement d'entrée
Au niveau de la R.C., le déclenchement optionnel peut être considéré comme une forme particulière d'entrée distincte d'un événement du système d'information, en ce sens que l'événement est décrit par une structure de donnée alors que le déclenchement optionnel est décrit par une commande utilisateur. Les événements d'entrée et le déclenchement concourent à la réalisation du pré-requis nécessaire à l'activation de la tâche. Si les événements d'entrée ont eu lieu, cela entraîne l'activation de la tâche si le déclenchement est automatique, sinon cela rend possible le déclenchement optionnel de la tâche. Mais, dans ce dernier cas, la tâche ne sera activée que si l'utilisateur décide d'user de son droit de déclenchement.
Les rapports entre les propriétés des précédences et des opérations
Nous allons maintenant examiner le lien entre les propriétés des opérations et des précédences suivantes :
- celle d'obligatoire ou de facultatif pour les opérations,
- celle de permanent ou indicatif pour les précédences, les autres propriétés étant indépendantes.
La question qui se pose ici est de savoir si certaines combinaisons de ces propriétés ne pourraient pas aboutir à des situations de blocage.
Nous examinerons seulement le cas de précédence permanentes car les précédences indicatives ne donnent pas lieu à vérification. Soit P(Oi,Oj) une précédence entre Oi et Oj ; si Oi et Oj sont de même type (tous les deux obligatoires ou tous les deux facultatifs), il n'y a aucun problème.
Si Oi est obligatoire et Oj facultatif cela signifiera que, une fois Oi exécutée, Oi ne le sera pas forcément car cela dépendra de l'utilisateur. Mais ce cas ne provoquera pas de blocage.
Si Oi est facultatif et Oj obligatoire, Oj ne sera déclenché que si Oi l'est. En effet, si Oi n'est pas exécuté Oj ne pourra pas être déclenché et Oi étant facultatif son déclenchement est nécessairement optionnel c'est-à-dire dépendant de l'utilisateur. Donc si l'utilisateur ne déclenche pas Oi, Oj ne pourra pas être déclenchée car elle ne sera pas activable. Mais ce cas non plus ne sera pas un blocage car la définition d'une opération obligatoire précise que le déclenchement de cette opération est nécessaire pour atteindre le but seulement si elle est activable, ce qui n'est pas forcément le cas.
L'examen de ces cas montre clairement que par le biais des opérations facultatives l'utilisateur peut avoir une marge de manoeuvre importante et que le comportement de la procédure ne sera pas déterministe.
Nous avons vu qu'à une procédure prévue correspond dans un contexte donné une procédure minimale et qu'à une procédure minimale correspond plusieurs procédures effectives.
Nous voulons expliciter dans ce paragraphe quelles sont les correspondances entre les différentes tâches afin de pouvoir vérifier la compatibilité entre :
- la procédure prévue et la procédure minimale,
- une procédure effective et la procédure minimale.
Par compatibilité, nous voulons dire qu'une procédure prévue, une procédure effective et une procédure minimale décrivent bien la même tâche.
Une procédure prévue pour un poste de travail et un but donnés est décrite par une liste d'opérations et une liste de pré-requis.
La procédure prévue correspond à la procédure standard qui est exécutée dans un cas normal ou pour guider un utilisateur novice.
La procédure prévue pour un poste de travail et un but donnés est décrite par les mêmes éléments que la procédure minimale pour lesquels on peut modifier le pilotage en:
- supprimant des déclenchements optionnels
- rajoutant des précédences indicatives
- augmentant les opérations obligatoires ou les précédences permanentes.
Pour un poste de travail donné, on dira qu'une procédure minimale et une procédure prévue sont compatibles si :
i) la procédure prévue et la procédure minimale ont le même but
ii) toutes les opérations obligatoires de procédure minimale sont des opérations de procédure prévue
iii) toutes les précédences permanentes de procédure minimale sont des précédences de procédure prévue
iiii) tous les déclenchements systématiques de procédure minimale sont des déclenchements de procédure prévue.
Nous remarquons que l'ensemble des séquences de procédure prévue réalisant le but doit être inclus dans l'ensemble des séquences de procédure minimale réalisant le but. La vérification de cette inclusion est fondamentale car elle permettra à l'analyste de vérifier que la procédure minimale qu'il vient de définir lui permettra d'exécuter la procédure prévue correspondante.
Une fois la procédure minimale définie, il nous faudra vérifier la compatibilité de toutes les procédures effectives que nous créerons par rapport à la procédure minimale. La procédure prévue et les procédures effectives ont la même définition de compatibilité par rapport à procédure minimale car la procédure prévue peut être considérée par rapport aux validations comme une procédure effective particulière.
Mais la distinction fondamentale entre une procédure prévue et une procédure effective est d'ordre méthodologique.
La procédure prévue correspondant généralement à la première observation de la tâche que nous pouvons faire et qui est, par définition, la tâche standard alors que les procédures effectives correspondent à toutes les variantes apportées par les utilisateurs en situation réelle de travail et qui seront définies au fur et à mesure des besoins.
Nous définissons un formalisme graphique qui permet de décrire l'ensemble des concepts que nous avons définis dans la R.C.
L'exemple ci-dessus est extrait de la Représentation 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 opérations de mise à jour du thesaurus et de consultations diverses; c'est pourquoi ces opérations figurent dans la description de la procédure minimale.
Toutes les précédences permanentes et les opérations obligatoires de la procédure minimale doivent figurer dans toutes les procédures effectives; c'est le cas, ici, de la précédence permanente entre les opérations obligatoires "Enregistrement des bases du document" et "Enregistrement mots-clés du document".
Il est possible, par contre, de rajouter des précédences permanentes et des opérations obligatoires dans une procédure effective pour minimiser les manipulations de l'utilisateur dans les cas usuels; c'est le cas, ici, pour la précédence entre les opérations "Enregitrement mots-clés du document" et "Créer termes du thesaurus" qui devient permanente dans la procédure effective ainsi que l'opération "Créer termes du thesaurus" qui devient obligatoire et automatique.
Mais l'opération "Créer liens entre termes" est restée interactive, facultative et à déclenchement optionnel car c'est une opération 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 même formalisme s'applique à tous les différents niveaux de détails; chaque opération est reprise et détaillée jusqu'au niveau de l'opération élémentaire dans la communication homme-machine, c'est-à-dire une entrée ou une sortie d'une transaction.
Un exemple complet est montré dans le chapitre 5.
Il est important de noter que seuls les paramètres variables sont exprimés sur ce schéma; pour des raisons de lisibilité les paramètres constants que nous développons au paragraphe suivant sont volontairement omis.
En conséquence, ces schémas doivent être interprétés comme la répartition du pilotage entre l'homme et l'ordinateur en ce qui concerne les paramètres variables auxquels viennent s'ajouter de manière implicite toutes les possibilités des paramètres constants.
Ces paramètres vont constituer des aides à l'utilisateur utilisables quelle que soit la tâche effectuée par lce dernier. Le caractère général de ces paramètres fait qu'ils n'ont pas besoin d'être spécifiés pour chaque application.
Nous distinguerons les aides à la réalisation de l'activité, les aides à l'apprentissage et les possibilités d'évolution du logiciel.
Interruption
L'interruption permet à l'utilisateur de quitter n'importe quelle opération en cours d'exécution pour aller exécuter une autre opération et reprendre la première opération à son point d'interruption.
On peut prévoir plusieurs niveaux successifs d'interruption, bien que concrètement, au-delà de trois ou quatre niveaux, ce soit difficilement gérable par l'utilisateur.
Cette notion est particulièrement importante pour toutes les opérations de consultation auxquelles on veut accéder alors qu'une autre opération est active. Notre hypothèse est qu'en système monoposte, toutes les opérations sont possibles à tout moment. Pour les systèmes en temps partagé, cela nécessite que le système gére les conflits éventuels concernant les mises à jour multiples de fichiers.
Transfert de données
La possibilité est donnée à l'utilisateur de transférer une donnée d'une opération à 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 donnée dans plusieurs opérations successives.
Quitter
L'utilisateur doit pouvoir demander l'abandon de son travail à n'importe quel moment sans avoir à finir une opération ou à repasser par une arborescence du menu. Le logiciel peut lui signaler les conséquences de cette demande selon l'endroit où elle se situe.
Différer
L'utilisateur peut différer n'importe quelle opération dans le temps afin de la reprendre ultérieurement à sa convenance. Différer se distingue de quitter en ce sens que dans l'action de différer il y a mémorisation de l'opération non terminée ce qui n'est pas le cas dans l'action de quitter.
Annuler
L'utilisateur peut annuler la derniére action qu'il vient de faire; cette possibilité est particulièrement utile pour le redressement des erreurs perçues par l'utilisateur ou signalées par le logiciel.
Mémorisation de l'activité
Ce modèle d'interface n'imposant pas de cadre rigide à l'opérateur, celui-ci peut connaître des difficultés de mémorisation de ce qu'il a accompli.
Plusieurs types de mémorisation lui seront donc proposés:
- entre les sessions, l'enregistrement, pour un utilisateur, des opérations qu'il a différées dans le temps. Cet enregistrement lui permettra à tout moment de connaître l'ensemble des opérations qui sont "en cours" et qu'il devra finir un jour.
- entre les sessions, la mémorisation des paramètres propres à l'utilisateur: identification, vocabulaire propre, procédures effectives...
- en cours de session, l'enregistrement des interruptions successives et non terminées qui sont en train d'être réalisées par l'utilisateur. Ceci lui permet surtout de ne pas se perdre dans le logiciel, en particulier s'il est lui-même interrompu par un événement extérieur.
- en cours de session, on peut avoir aussi une trace du travail total ou à défaut des deux ou trois dernières opérations réalisées afin de pouvoir remonter facilement à l'état précédent du système. Cette trace de l'activité peut être intéressante pour la détection et le redressement des erreurs contatées par l'utilisateur (en l'absence de possibilité de retour-arrière automatique, ce qui est difficile à réaliser en toute généralité).
Nous voulons parler ici d'aide à l'apprentissage du maniement du logiciel proposé et non pas du travail lui-même.
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 connaître soit la liste des opérations possibles dans l'état actuel d'avancement de son travail, soit une explication des fonctions et effets d'une commande donnée.
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 enchaînement d'opérations correspondant aux précédences permanentes et indicatives lui sera proposé en fonction du but qu'il s'est fixé.
Ce type de guidage peut permettre de répondre à des questions du type "Comment faire pour? ". Ceci est rendu possible grâce à la structuration du système en buts, sous-buts, opérations et précédences.
Nous parlons ici essentiellement d'évolution hors programmation, c'est-à-dire qui peuvent être mises en oeuvre, éventuellement, par l'utilisateur lui même.
Ce qu'il sera aisé de modifier concerne:
- la création de nouvelles procédures effectives adaptées aux modes de travail des différents utilisateurs
- la répartition du pilotage entre l'homme et l'ordinateur c'est-à-dire les notions de déclenchement, d'opérations obligatoires ou facultatives, de précédences permanentes ou indicatives
- les niveaux d'opérations intermédiaires qui n'ont pas été initialement prévus mais qui utilisent des opérations déjà connues de la machine. Cela peut permettre à l'utilisateur de se créer ses propres séquences standard ou des macro-opérations originales
Si on veut faire appel à de nouveaux traitements qui ne peuvent pas être composés à partir des opérations déjà connues de la machine, il sera nécessaire de programmer ces nouveaux modules. Il en va de même si l'on veut faire apparaître des données ou des relations entre données non décrites dans les structures de données de la machine.
Cependant, la représentation interne que nous proposons au chapitre cinq pour implémenter ce système est orientée vers une facilité maximum d'évolution.
Les paramètres constants des applications interactives que nous venons de décrire doivent être présents constamment dans l'esprit de l'analyste pour deux raisons:
- ils facilitent et allègent la description de la représentation conceptuelle de chaque application interactive ; en effet, l'analyste n'a plus besoin de spécifier les points de retour possibles au menu principal ou aux opérations de consultation puisqu'il est possible à tout moment de quitter, de différer ou d'interrompre;
- inversement, ils permettent d'interpréter différemment les schémas de la représentation conceptuelle.
Pour se convaincre de la nécessité de ne pas faire figurer les paramètres constants, nous avons visualisé sur le schéma suivant qui reprend l'exemple de la procédure effective de la documentaliste ce qui se passerait si on indiquait par des flèches toutes les possibilités d'interrompre et de quitter de l'utilisateur.
Nous voyons clairement que les schémas de la Représentation Conceptuelle deviendraient alors illisibles.
En pratique, il n'y a que dans le cas où les possibilités standard de l'utilisateur sont réduites qu'on peut les faire figurer dans les schémas.
