1. Remerciements

Je tiens à remercier toutes les personnes m’ayant aidé tout au long de ce stage de DESS :

• Dominique Scapin et Suzanne Sebillotte pour leur accueil et leur encadrement avisé au sein du projet de psychologie ergonomique à l’INRIA.

•  René Amalberti pour ses conseils et orientations pertinents.

• Denise Fallah et Belen Alonso pour leur aide, leur disponibilité, leur grande volonté de coopération et leurs magnifiques arbres MAD.

•  Hamid Hammouche pour son soutien moral et ses conseils.

•  Pierre Anne pour m’avoir fait découvrir l’ergonomie et toutes ses joies.

•  Tous les ergonomes et psychologues du laboratoire du projet pour avoir accepté et supporté un informaticien voulant s’intégrer au monde de l’ergonomie.

2. Introduction

Ce travail est consacré à l’étude des difficultés rencontrées lors de l’utilisation du formalisme de description de tâches MAD. Il s’inscrit dans le cadre d’un axe de recherche du projet de psychologie ergonomique pour l’informatique à l’INRIA (Institut National de Recherche en Informatique et Automatique) qui concerne la définition de méthodes de description formelle des tâches.

Le projet de psychologie ergonomique pour l’informatique s’inscrit dans le domaine de recherche : intelligence artificielle, systèmes cognitifs et interaction homme-machine. L’objectif général du projet est d’assurer une compatibilité satisfaisante entre la manière dont l’information est traitée et représentée par l’ordinateur, et les utilisateurs. Plus précisément, les recherches ont pour but essentiel de résoudre des problèmes pratiques tout en permettant la généralisation des résultats, la modélisation, la définition des méthodes, et la contribution aux connaissances dans des domaines connexes avec lesquels l’ergonomie des interfaces entretient des relations étroites comme la psychologie, la linguistique et l’intelligence artificielle.

Une étape essentielle est de bien connaître les opérateurs et leur activité. A cet effet, des méthodes de recueil de données et de validation de données ont été construites (de type interviews semi-dirigées). Les données recueillies sont décrites au moyen d’un formalisme : MAD (Méthode Analytique de Description de tâches). Ce formalisme est ensuite utilisé pour mettre en oeuvre des mécanismes de spécification de haut niveau d’abstraction : définition des états de l’interface, types d’informations et moments d’apparition, types de fonctions, etc. ces contraintes, issues de l’analyse de l’activité, peuvent être ensuite confrontées avec les caractéristiques conceptuelles de l’interface à évaluer.

Ce rapport s’intéresse plus particulièrement au formalisme de description de tâches : MAD. Nous commencerons par tracer un historique du formalisme. Nous définirons ensuite les objectifs de notre étude. Nous préciserons le cadre théorique, c’est-à-dire la nécessité d’un formalisme de description de tâches, les objectifs et critères de formalisation ainsi que le concept de tâche. Nous présenterons ensuite le domaine de l’étude : les définitions de MAD et les arbres résultats d’applications du formalisme pour l’analyse de tâches réelles. Nous développerons par la suite la méthodologie adoptée : l’analyse des traces et les entretiens. Puis, les résultats seront énoncés précédant une interprétation et une discussion. Dans cette dernière, nous proposerons quelques éléments de solution dont l’un d’entre eux constituera notre première annexe : la nouvelle définition du formalisme MAD. Nous joindrons aussi des extraits des arbres analysés pour montrer le support de l’analyse des traces.

3. Historique

En 1988, Scapin constate une insuffisance d'outils formels de description de tâches [Scapin 1988]. Pour répondre à ce besoin, il propose une première ébauche d'un formalisme appelé MAD (Méthode Analytique de Description de tâches) qui est orientée conception d'interfaces utilisateur.

Par la suite, une véritable définition du formalisme est donnée dans [Scapin, Pierret-Goldbreich 1989]. Ce rapport explicite clairement les différents éléments du formalisme.

En 1991, Sebillotte propose une méthode pour décrire les tâches selon les objectifs des opérateurs [Sebillotte 1991]. Cette étude décrit les différentes étapes nécessaires pour réaliser une analyse du travail : la conduite de l'interview, le recueil des données, l'analyse des tâches et enfin la formalisation des tâches à l'aide de MAD. On a donc ici une méthode permettant de faciliter l'utilisation du formalisme.

En 1990 commence une étude ergonomique sur le contrôle aérien. L'analyse de l'activité est effectuée selon la méthode décrite ci-dessus et le formalisme choisi est MAD. L’un des objectifs du projet est effectivement d’évaluer le formalisme dans un domaine complexe. En août 1991, une série d'arbres MAD sont proposés [El Farouki, Scapin, Sebillotte 1991] pour modéliser les tâches des contrôleurs aériens. Déjà, un certain nombre de problèmes sont détectés lors de l'utilisation du formalisme MAD [Delsol 1992]. Ceux-ci seront confirmés et précisés par une autre étude en continuité des travaux précédents [Alonso 1993].

Une autre étude ergonomique se propose de décrire les tâches selon le formalisme MAD. Cette étude [Fallah 1992] porte sur la résolution d'incidents maritimes. Là encore, certains problèmes sont détectés lors de l'utilisation du formalisme.

4. Objectifs

L'objectif de cette étude est d'évaluer les difficultés des utilisateurs à appliquer la méthodologie MAD. Ces problèmes peuvent être d'ordre pratique (par exemple, difficulté à manier des arbres graphiques sans outils adaptés) ou d'ordre conceptuel (par exemple, difficulté à appliquer certains aspects du formalisme théorique sur le terrain).

Après avoir situé les différents types de problèmes, nous essayerons d'en cerner les causes. Nous proposerons ensuite quelques éléments de solution en vue de faciliter l'utilisation du formalisme MAD.

Ces propositions devront respecter l'esprit et les définitions initiales de MAD. Elles conduiront aussi à des spécifications pour une interface pour saisir le formalisme MAD.

5. Cadre théorique

Ce travail s'intègre dans le cadre d'un projet dont l'objectif général est de développer une approche pluri-disciplinaire pour la conception d'outils intelligents d'aide à la construction d'interfaces homme-machine. Une étape de ce projet consiste à faciliter les liens entre les ergonomes et les concepteurs d'interface. Pour cela, il apparaît nécessaire de définir un formalisme de description des tâches. Cette nécessité établie, nous énoncerons les objectifs et critères de cette modélisation. Enfin, nous préciserons le concept de tâche.

5.1. Nécessité d'un formalisme de description de tâches

L'ergonomie des logiciels a beaucoup progressé ces dernières années. Elle propose maintenant de nombreux résultats et théories. Cependant, les uns et les autres sont difficiles d'application. [Scapin, Pierret-Goldbreich 1989] emet l’hypothèse que ces obstacles tiennent en bonne partie aux lacunes de formalisation, et par voie de conséquence de méthodes, dans le domaine de la description des tâches.

En effet, d'un côté, on trouve les habituelles recommandations ergonomiques encourageant à prendre en compte l'utilisateur et sa tâche. Elles sont malheureusement trop souvent présentées de façon anecdotique ou floue, et surtout sans lien avec les méthodes de recueil d'informations. Les concepteurs prennent conscience de l'importance de ces recommandations ergonomiques mais ne savent pas comment les prendre en compte.

D'un autre côté, de nombreux modèles ont été proposés pour l'interaction homme-ordinateur. Mais, rares sont ceux qui font référence spécifiquement au problème de la conception d'interface, et nombreux sont ceux qui se préoccupent essentiellement de phénomènes de comportement de bas niveau. De plus, les modèles dont on dispose sont difficilement applicables et à fortiori implémentables [Coutaz 1988]. Néanmoins, certains de leurs aspects méritent d'être retenus [Scapin 1988].

Ce dont le concepteur a réellement besoin, c'est d'une description stable et complète des tâches prenant en compte les représentations des utilisateurs individuels. Cette description doit donc être formalisée. Cette formalisation devra prendre en compte les recommandations et retenir les aspects intéressants des modèles de l'interaction homme-machine.

5.2. Objectifs et critères de formalisation

L'objectif général de MAD est, dans une première étape, de représenter les tâches de l'utilisateur de manière uniforme afin de poser les problèmes de conception ergonomiques sur des bases informationnelles solides. Il ne s'agit pas de fournir un modèle de l'interface homme-ordinateur, ni d'effectuer des prédictions évaluatives d'interfaces, ni de définir des classifications à priori. Ce n'est qu'ultérieurement que les considérations ergonomiques organisées selon des critères pertinents (e.g. objectifs de conception, niveaux d'abstraction) pourront être mises en oeuvre, à partir du formalisme MAD.

Les autres exigences d'un tel outil de formalisation sont les suivantes :

•  considérer la façon dont l'utilisateur se représente la tâche, et non pas la logique du traitement informatique (si informatisation) ou de la tâche prescrite.

•  prendre en compte les aspects conceptuels et sémantiques et pas seulement les aspects syntaxiques et lexicaux.

•  permettre, après test et évaluation, de définir une méthode de recueil de données, dans le cadre de l'analyse du travail.

•  autoriser la décomposition structurelle des tâches de façon uniforme.

•  autoriser la description, aussi bien d'un point de vue déclaratif (état du monde) que procédural (façon d'arriver à cet état).

•  autoriser la prise en compte du parallélisme et pas seulement du séquentiel (synchronisation des tâches).

•  permettre une implémentation sur laquelle travailler, notamment lors de la mise en relation avec d'autres logiciels d'intelligence artificielle, en particulier ceux qui tentent de modéliser l'environnement de bureau.

5.3. Le concept de tâche

La nécessité d'introduire le concept de “tâche” apparaît actuellement dans différents contextes. On peut distinguer ce concept au moins selon deux optiques d'utilisation dont la frontière est parfois floue : la modélisation du raisonnement et la modélisation d'une activité. L’aspect qui nous intéresse pour cette étude est, bien entendu, celui de la modélisation de l’activité.

Dans [Sebillotte 1991], la distinction entre tâche et activité est rappelée. La tâche est “ce qui est à faire”, le but à atteindre du point de vue de l’opérateur. Elle correspond à la manière habituelle de réaliser un travail dans un environnement donné. Elle est souvent différente de la tâche prescrite, c’est-à-dire telle qu’établie par la hiérarchie ou le manuel de procédure.

Pour décrire la tâche, on fait essentiellement appel aux représentations mentales des opérateurs ainsi qu’à des séries d’observations de l’activité. En effet, l’activité est une réalisation (ou instanciation) de la tâche.

Dans [Hammouche 1993], on apprend que la tâche est généralement décrite par un but, objectif de la tâche, des conditions d’exécution, une liste de sous-tâches et des contraintes fonctionnelles et/ou temporelles.

Pour MAD, il existe deux types de tâches : les tâches simples et les tâches composées.

Les tâches simples correspondent à des actions élémentaires observables d’un opérateur.

Par élémentaire, on entend qu’il n’est pas pertinent pour la modélisation de la décomposer de manière plus précise. Le caractère élémentaire d’une tâche peut être difficile à déterminer. Une idée serait de dire qu’une tâche est élémentaire lorsque l’opérateur ne peut plus expliciter davantage son action [Sebillotte 1987]. Cela se traduit souvent par une identité entre l’action et l’explication, c’est-à-dire que si on demande à l’opérateur d’expliquer son action, il répète le nom de son action[1]. Une autre idée, non contradictoire avec la première d’ailleurs, est de dire que les tâches doivent au moins avoir une signification cognitive et ne pas descendre au niveau physiologique.

Par observable, on entend que l’action doit être situable dans un intervalle de temps. Entre le début et la fin de l’action se produit un changement sur le monde de l’opérateur directement conséquence de l’action. Une action peut être physique (appuyer sur un bouton) ou mentale (effectuer un calcul).

Dans [Pierret-Goldbreich et al.1989], on trouve la définition d’une tâche composée. Une tâche composée est une tâche dont le niveau opérationnel ne fait pas appel à une simple procédure mais à un enchaînement structuré de sous-tâches. Cette combinaison de tâches est décrite par une entité structure permettant de définir à la fois les composants, sous-tâches constitutives de la tâche composite ainsi que leur agencement, c’est-à-dire les relations d’ordre temporel ou logique existant entre ces différents composants.

Nous ajouterons que les tâches composées correspondent à des tâches abstraites, décomposées en une structure de sous-tâches. Les sous-tâches d’une tâche abstraite sont reliées entre elles, sémantiquement, par un but global défini au niveau de la tâche abstraite. Ce but peut être lui-même sous-but, d’un but, encore plus global, d’une tâche de plus haut niveau. Ainsi, par abstraite, on entend que la décomposition n’est pas seulement d’ordre logico-temporel mais aussi d’ordre sémantique. Pour illustrer notre propos, les deux figures suivantes montrent deux manières d’exprimer la même tâche composée “faire un repas”. Dans les deux cas, on a bien la même quantité d’information logico-temporelle. Par contre, la deuxième figure contient des informations sémantiques supplémentaires qu’il est très intéressant d’avoir car elles établissent un niveau d’abstraction supplémentaire.

.m8.Figure 1 : Exemple de tâche composée avec un niveau d’abstraction

.m8.Figure 2 : Exemple de tâche composée avec deux niveaux d’abstraction

6. Domaine de l'étude

Cette étude s’appuie essentiellement sur les résultats de trois travaux : Le formalisme de description de tâches MAD, l’arbre du contrôle aérien et l’arbre de la résolution d’incidents maritimes. Ces travaux ainsi que notre étude, s’inscrivent dans le cadre d’un axe de recherche du projet de psychologie ergonomique pour l’informatique qui concerne la définition de méthodes de description formelle des tâches.

Nous allons maintenant donner quelques éléments de description de ces travaux.

6.1. MAD

MAD est une Méthode Analytique de Description de tâches orientée Conception d'Interfaces Utilisateur.

Cette définition se retrouve dans de nombreux articles et rapports publiés par Scapin ([Scapin 1988], [Scapin, Pierret-Goldbreich 1989] par exemple). Celle qui semble la plus complète et qui correspond en quelque sorte à “l'état de l'art” est celle trouvée dans [Scapin, Pierret-Goldbreich 1989]. Pour mémoire, nous la rappelons ici.

“Dans le formalisme MAD, les principaux concepts sont ceux d'objet-tâche, d'action, de structure :

Le concept de tâche est représenté par un objet générique (au sens de frame, catégorie, prototype, etc.) appelé objet-tâche (O.T.). Cet objet comporte les éléments suivants :

-  un état-initial (I) : sous ensemble de l'état du monde constitué de la liste des objets, arguments d'entrée de la tâche.

-  un état-final (F) : sous ensemble de l'état du monde constitué de la liste des objets, arguments de sortie de la tâche. Il s'agit des objets directement créés ou modifiés suite à l'exécution de la tâche. Certains objets peuvent naturellement apparaître à la fois en entrée et en sortie.

-  un but (B) : sous-ensemble de l'état-final (B est inclus dans F), indiquant explicitement le but recherché dans l'exécution de la tâche.

-  des préconditions (C.N.) : ensemble des prédicats exprimant des contraintes sur l'état initial et qui doivent nécessairement être satisfaites pour pouvoir déclencher l'exécution de la tâche. On distingue un type particulier de préconditions, les conditions-nécessaires déclenchantes (C.N.D.) qui décrivent des états particuliers qui non seulement doivent être satisfaits pour permettre l'exécution de la tâche mais qui de plus ont un rôle dynamique de déclenchement de la tâche. (condition nécessaire et suffisante à son déclenchement).

-  des postconditions (P.C.) : ensemble des prédicats exprimant des contraintes sur l'état final et qui doivent nécessairement être satisfaites après l'exécution de la tâche. Les postconditions sont des contraintes qui portent sur l'état final.

On distingue deux types d'objet-tâche : l'objet-tâche est donc la racine de deux sous-classes particulières : la classe tâche élémentaire et la classe tâche composée :

-  Une tâche élémentaire est une tâche indécomposable dont le niveau opérationnel est caractérisée par un objet méthode de type simple, c'est-à-dire une action. Une tâche élémentaire comporte donc en plus des éléments précédents un descripteur de l'action à exécuter.

-  Une tâche composée est une tâche dont le niveau opérationnel est défini par une structure décrivant le corps de la tâche. Celle-ci comporte donc un champ supplémentaire structure.

Le concept de structure est représenté par un objet générique caractérisé par un constructeur et ses arguments constitués d'une liste d'objet-tâche. Les constructeurs décrivent l'agencement des différentes tâches impliquées. Certains constructeurs sont prédéfinis :

-  SEQ : tâches séquentielles (par exemple dans le scénario suivant : localiser un fichier, puis déplacer le curseur, puis ouvrir un fichier).

-  PAR : tâches parallèles (par exemple dans le scénario suivant : soit insérer des fichiers déjà constitués, puis rédiger un autre texte, soit l'inverse).

-  ALT : tâches alternatives (une manière ou une autre de faire; par exemple dans le scénario suivant : effectuer un copie soit par commande clavier, soit par désignation d'options de menu).

-  BOUCLE : tâches itératives (par exemple dans le scénario suivant : effectuer des opérations d'insertion de fichier d'un collègue, puis recommencer pour un autre membre de l'équipe).

-  FAC : tâches facultatives (pour les opérations non requises, par exemple ajouter un sigle au rapport d'activité de son équipe).”

Sous l’impulsion de l’expansion des modèles objet en informatique, une deuxième définition, esquissée dans [Pierret-Goldbreich et al. 1989], précisée dans [Hammouche 1993], définit les différents éléments d'une tâche MAD sous forme d'objets. Chaque élément devient un objet à attributs. Ainsi une tâche est un objet avec les attributs suivants : nom de la tâche, type, état initial, état final, préconditions, postconditions, structure de sous-tâches... Chaque attribut regroupe en fait des ensembles d'objets. Ainsi l'attribut préconditions est une liste d'objets de type “préconditions”. Un objet de type “préconditions” a les attributs suivants : nom, type, prédicats. De même les états initiaux et finaux sont des listes d'objets d'un type appelé “objet” qui contient les attributs nom, type...

La définition objet a permis de développer une première implémentation d’un outil d’acquisition et de représentation des tâches orienté objet appelé EMAD [Delouis, Pierret, 1991]. Celle-ci utilisait le langage de frames SHIRKA [Rechenman et al., 1988]. Malheureusement, le langage SHIRKA n’était pas stabilisé et demandait beaucoup de ressources. L’outil EMAD est donc resté limité à une capacité de manipulation de quelques tâches seulement. Néanmoins, l’intérêt de l’approche objet avait pu ainsi être démontré.

Dans le même temps, MAD a été utilisé sur le terrain dans le cadre de l’analyse de l’activité. La définition a alors été interprétée pour satisfaire les besoins des ergonomes. On peut trouver l’essentiel de ces interprétations dans [Sebillotte 1991]. Elles concernent en particulier les définitions des préconditions et du but.

6.2. Arbre du contrôle aérien

Cet arbre a été réalisé lors d’une étude menée au projet de Psychologie Ergonomique pour l’Informatique à l'INRIA pour le projet PHIDIAS (périPHérique Intégré de DIalogue et d’ASsistance) du CENA (Centre d’Etudes de la Navigation Aérienne). Le but de ce projet est de renouveler le poste de travail du contrôleur aérien, c’est-à-dire d’intégrer sur la position de contrôle l’ensemble des fonctions de visualisation et de dialogue avec le système de contrôle, ce qui est fait actuellement avec divers dispositifs indépendants.

Une première étude [El Farouki et al. 1991] avait trois objectifs : un objectif appliqué qui était de fournir et de justifier des spécifications ergonomiques pour l’interface future sur la position de contrôle au CENA et deux objectifs de recherches qui visaient d’une part à tester un outil de description, le formalisme MAD, et d’autre part à identifier des contraintes liées à la représentation des opérateurs.

Une analyse de l’activité a donc été effectuée avec pour résultat un arbre MAD

Le rapport [El Farouki et al. 1991] décrit la méthode utilisée pour recueillir les données et construire l’arbre. On trouve en annexe l’arbre et les fiches descriptives des tâches.

L’activité décrite est celle du contrôle aérien que l’on peut séparer en cinq grandes parties : la relève, la planification du trafic, la surveillance du trafic, la résolution des conflits et la gestion de la position. Le recueil d'informations s'est effectué par des interviews semi-dirigées et des observations directes sur le terrain avec demandes d’explication. La technique d'interview utilisée est celle décrite dans [Sebillotte 1991].

Finalement, une partie des résultats de l’étude est cinq arbres contenant 157 tâches ou sous-tâches distinctes avec jusqu'à 7 niveaux hiérarchiques. Nous fournissons en annexe une partie de cet arbre.

Une autre étude en continuité avec la précédente se propose d’étudier le partage des tâches entre les contrôleurs ainsi que les problèmes rencontrés lors de l’utilisation de MAD pour décrire une activité impliquant plusieurs opérateurs.

Deux rapports [Delsol 1992], [Alonso 1993] décrivent les résultats obtenus. D’une part, une partie des arbres a été modifiée et approfondie, 37 tâches ont été rajoutées portant à 194 le nombre de fiches. D’autre part, des modifications du formalismes ont été proposées.

6.3. Arbre de la résolution d'incidents sur des navires

Cet arbre a été réalisé lors d'une étude menée au projet de Psychologie Ergonomique pour l’Informatique à l'INRIA pour un projet européen ESPRIT dénommé INTUITIVE (INTeractive Users Interface and Tools For Information in a Visual Environnement). L’objectif de l’étude est de contribuer à la spécification d’un système d’aide aux navires en situation critique. Il s’agit plus précisément de l’assistance à l’accès multimodal aux informations multimédias en situation critique.

Une analyse de l’activité a donc été effectuée avec pour résultat un arbre MAD

Le rapport [Fallah 1992] décrit la méthode utilisée pour recueillir les données et construire l’arbre. On trouve en annexe l'arbre et les fiches descriptives des tâches.

L'activité décrite est celle de la résolution d'un incendie sur un navire en mer. Le recueil d'informations s'est effectué par des interviews semi-dirigées et une étude des traces. Il était en effet impossible d'observer directement une situation réelle d'incendie. La technique d'interview utilisée est celle décrite dans [Sebillotte 1991].

Finalement, un des résultats de l'étude est un arbre contenant 33 tâches ou sous-tâches distinctes avec jusqu'à 7 niveaux hiérarchiques. Nous fournissons en annexe une partie de cet arbre.

7. Méthodologie

Nous présentons ici la méthodologie que nous avons mis en oeuvre pour cette étude ergonomique. Dans un premier temps, une prise de contact avec le domaine a été nécessaire. Deux techniques ont ensuite été utilisées : l’analyse des traces et des entretiens. Nous définirons aussi des critères de mesure d’écart entre la définition du formalisme et l’utilisation faite par les ergonomes.

7.1. Prise de contact avec le terrain

La première partie de l’étude a consisté à prendre contact avec le terrain.

L’étude se déroule dans le projet de psychologie ergonomique pour l’informatique. La population étudiée est composée d’ergonomes travaillant en rapport avec MAD. On distingue deux catégories de population : les ergonomes experts, qui ont essentiellement travaillé sur la théorie et la définition de MAD, et les ergonomes débutants, qui ont essentiellement utilisé le formalisme pour effectuer des analyses de l’activité. Dans la suite, nous appellerons les premiers les théoriciens et les seconds les praticiens.

Après la prise de contact avec les personnes, nous avons rassemblé l’ensemble des travaux réalisés autour de MAD. On peut distinguer deux types de travaux : les études portant sur la théorie et la définition du formalisme et les études comportant des applications du formalisme sur le terrain.

Dans le même temps, nous avons aussi effectué une revue bibliographique du domaine général de la formalisation de la tâche pour mieux comprendre les concepts et termes impliqués.

Puis, nous avons commencé à étudier les définitions successives [Scapin 1988][Pierret-Goldbreich et al. 1989] de MAD en mettant l’accent sur la dernière qui correspond à l’état de l’art [Scapin et al. 1989].

Après avoir bien compris la définition, nous avons examiné les rapports décrivant les utilisations. Ceci comprend une étude qui définit une méthodologie pour le recueil, l’analyse de données en vue de la formalisation des tâches [Sebillotte 1991]. Cette méthodologie a été appliquée dans deux domaines : le contrôle aérien [El Farouki et al. 1991][Alonso 1993] et la résolution d’incendie sur navire [Fallah 1992].

Ces rapports mentionnaient les difficultés à appliquer le formalisme dans certains cas. Après une première analyse, il est apparu que ces difficultés résultaient d’interprétations du formalisme. Ces interprétations résultaient d’une part des difficultés à exprimer certaines caractéristiques particulières des activités à analyser et d’autre part de différences de compréhensions du formalisme entre les différentes personnes.

Ainsi, il est apparu nécessaire de procéder à une analyse approfondie des arbres pour pouvoir énumérer les interprétations et problèmes rencontrés lors de la conception des arbres. Cette analyse a bien sûr été complétée par des entretiens avec les concepteurs d’arbre.

7.2. Analyse des traces

Etant donné que les études ergonomiques d’analyse de l’activité ayant conduit aux arbres ont déjà été effectuées, il était donc impossible d’observer directement l’élaboration des arbres de tâches. D’autre part, aucun autre arbre n’est en cours d’élaboration actuellement. Nous avons donc du nous appuyer sur les traces. Ces traces sont constituées du résultat des analyses de tâches effectuées au projet : un arbre du contrôle aérien de 194 tâches et un arbre de la résolution d’incendie de 33 tâches.

Bien que notre analyse porte surtout sur la forme employée dans ces descriptions de tâches MAD, une compréhension minimale du contenu des tâches a été nécessaire. Pour cela, il a fallu se familiariser avec les deux terrains des activités. Comme les observations sur le terrain ont déjà été effectuées, nous nous sommes contentés de lire de manière approfondie les descriptions figurant dans les rapports ainsi que de parler avec les ergonomes ayant effectué les études.

Après cette familiarisation, une étude de chaque fiche correspondant à une tâche ou sous-tâche a été entreprise. Pour chaque tâche, on a relevé les éléments qui ne correspondaient exactement au formalisme, en notant à chaque fois le problème rencontré. Une liste exhaustive des interprétations et problèmes rencontrés a ensuite été établie. Une classification a ensuite été entreprise. Un certain nombre d’ambiguïtés ont aussi été relevées.

Pour chaque tâche, une ébauche de correction a été fournie pour être soumise aux concepteurs d’arbre. Pour approfondir cette analyse, des entretiens avec les concepteurs d’arbre ont été nécessaires.

7.3. Entretiens

L’analyse des arbres s’est effectuée en collaboration proche avec les ergonomes concepteurs d’arbres MAD. Dans un premier temps, des entretiens ont été nécessaires pour prendre connaissance des différents domaines concernés. Des entretiens libres ont ensuite permis d’une part de confirmer les hypothèses d’interprétations, d’autre part de découvrir les causes de ces mêmes interprétations.

Les personnes interrogées travaillant dans le même laboratoire, les entretiens se sont déroulées de manière quasi informelle avec prise de notes papier.

Ainsi, on a pu établir la représentation du formalisme que s’était construite les ergonomes ainsi que les compromis mis en oeuvre pour adapter le formalisme aux exigences du terrain.

7.4. Analyse

Après s’être bien avoir acquis une bonne connaissance des définitions, analysé les arbres et s’être entretenu avec les ergonomes, une analyse de la situation a été possible. La liste et le classement des interprétations ont été effectué. Ensuite seulement, des ébauches de solutions ont pu être proposées.

8. Résultats

Nous présentons ici les résultats de notre étude. C’est une liste des interprétations et problèmes rencontrés lors de l’utilisation du formalisme MAD par des ergonomes. Ces résultats sont divisés en trois parties : les interprétations du formalisme selon les personnes, les problèmes rencontrés lors de l’utilisation du formalisme sur le terrain et les problèmes liés au manque d’outils adaptés.

8.1. Interprétations

Cette partie décrit les interprétations que les différents utilisateurs de MAD ont fait des définitions originelles de MAD.

8.1.1. Prérequis

Si l'on observe la définition des préconditions dans [Sebillotte 1991], on remarque que les notions de prérequis et préconditions sont confondues. Or, la première version de MAD [Scapin 1988] utilisait le terme de prérequis et pas celui de précondition. On peut donc être amené à penser que ces deux termes représentent la même chose. En fait, le problème est plus compliqué, une discussion détaillée est donc nécessaire en vue d’éclaircir les différences entre ces deux concepts.

Dans le formalisme Procope [Richard et al. 1990], on trouve les deux éléments séparément. Les définitions suivantes sont données : “Une procédure peut contenir des pré-requis et des pré-conditions qui font référence aux états permettant l'exécution du corps de la procédure. Les pré-requis sont des états qui doivent être réalisés pour que le corps soit accompli. Le pré-requis possède sa propre procédure subordonnée qui doit être exécutée chaque fois que l'état n'est pas réalisé. De même, les pré-conditions sont le test d'états. Une pré-condition est la condition d'entrée dans la procédure. Mais il n'y a pas de procédure subordonnée pour réaliser cet état. Soit cela ne dépend pas de l'action de l'utilisateur, soit l'utilisation de la procédure rend impossible l'atteinte d'un but en attente. Quand la pré-condition n'est pas satisfaite, on doit abandonner la procédure pour laquelle c'est une pré-condition.”

Comme on peut le constater, le prérequis concerne une autre procédure qui doit être exécutée pour que la tâche ait lieu. La précondition est juste un test d'état.

Un grand nombre des préconditions observées dans les arbres sont en fait des prérequis. Ainsi, ces préconditions expriment la nécessité d'avoir accompli une autre tâche avant de pouvoir commencer la courante, ce qui correspond bien à un prérequis.

On constate donc que cette notion de prérequis est importante et doit être exprimée. De plus, elle doit l'être dans les termes de la définition originelle, sans rajouter d'élément au formalisme. En effet, pour le moment les préconditions de ce type sont notées par une phrase du type “avoir fait la tâche X” ou une proposition reprenant un nom de tâche.

Ce genre de précondition peut être utile MAIS le plus souvent, on constate que le prérequis concerne une tâche qui précède logiquement la tâche courante. C'est-à-dire, si on considère par exemple une suite séquentielle de tâches, la troisième tâche aura pour prérequis la deuxième, qui aura elle-même pour prérequis la première et donc par transitivité, la troisième aura la première pour prérequis (cf figure 1).

 
.m8.Figure 3 : Exemples de prérequis

Ainsi, le constructeur “SEQ” définit implicitement ce type de prérequis. Il n'est donc pas nécessaire d'ajouter une information redondante au niveau des préconditions. Cependant, les prérequis peuvent être utiles avec d'autres types de constructeurs (cf la description des constructeurs PAR, ALT pour plus de détails).

Néanmoins, il peut être intéressant de préciser les prérequis même s'ils sont implicites si l'on considère que l'on peut sortir la sous-tâche de son contexte pour, par exemple, la dupliquer ailleurs. La redondance d'information aurait donc un sens puisqu'elle préciserait explicitement les dépendances d'ordre.

Ainsi, il convient dans les définitions des préconditions de préciser la distinction avec les prérequis et définir comment les exprimer selon MAD.

8.1.2. Postrequis

Comme nous l’avons constaté précédemment, un problème se pose sur la distinction entre les prérequis et les préconditions. Dans le même ordre d’idée se trouve le problème de la distinction entre postrequis et postconditions.

Là encore, nous allons encore nous référer à la définition donnée dans Procope. Les postrequis sont “des actions auxiliaires qui complètent l'exécution de la procédure. Ils ne sont pas strictement nécessaires pour atteindre les buts. En un sens, ils sont ce qu'il reste à faire quand on a terminé.” Cette notion se retrouve parfois dans les arbres MAD dans les postconditions. C'est par exemple, la postcondition “faire le rapport de l'incident” dans la tâche de résolution d'incendie. Là aussi, il convient de l'exprimer correctement avec le formalisme MAD. En effet, cette formulation place une procédure dans les postconditions et on se retrouve avec le même problème que pour les prérequis.

Ainsi, il convient dans les définitions des postconditions de préciser la distinction avec les postrequis et définir comment les exprimer selon MAD.

8.1.3. Conditions dans états

On trouve fréquemment dans les états initiaux et finaux les éléments suivants :

-  un strip (n+1) lu

-  un strip (n+1) en main

-  des avions contrôlés

-  environnement contrôlé

-  casque branché

-  un avion (n) dont le contrôleur n'a plus la charge et à qui il a communiqué les données.

-  alarme sonore acquittée

Or, la définition de MAD décrit l'état initial (respectivement final) comme un “sous-ensemble de l'état du monde constitué de la liste des objets, arguments d'entrée (respectivement de sortie) de la tâche”. D'autre part, les pré (respectivement post)-conditions sont un “ensemble de prédicats exprimant des contraintes sur l'état initial (respectivement final)”.

Selon la définition, on ne devrait trouver dans un état qu'une liste d'objets sans aucune contraintes. Or, si on peut effectivement distinguer des objets (un strip (n+1), des avions, environnement, casque...), on trouve aussi les contraintes sur ces mêmes objets (un strip (n+1) lu, environnement contrôlé, casque branché...).

Après entretiens, il semblerait que la frontière entre état et condition ne soit pas clairement établie. En fait, la plupart des états contiennent des conditions.

Il serait donc nécessaire de mieux préciser et définir les concepts d’objets et de contraintes.

8.1.4. Enoncés des conditions

Les conditions sont énoncées en langage naturel, dans un style non homogène. On peut trouver des conditions en style télégraphique (nom tout seul, nom+adjectif, verbe+nom) jusqu’à des phrases complètes très longue (Ex : le contrôleur radar a pris connaissance des strips du tableau).

Or, MAD est un formalisme. Selon la définition, les conditions sont des prédicats. Elles doivent satisfaire à une certaine grammaire. Néanmoins, il est aussi utile de pouvoir exprimer des conditions en langage naturel qui aident à la compréhension de l’arbre. Il serait donc nécessaire de préciser le concept de prédicat.

8.1.5. Conditions nécessaires déclenchantes

Dans les arbres, on peut en distinguer trois types d’utilisation :

•  Les préconditions de la tâche de plus haut niveau d’abstraction. Ce sont en effet, des conditions déclenchantes, puisqu’elles déterminent l’instant du début de la activité. On constate que dans l’arbre du contrôle aérien, ces conditions sont présentes mais ne sont pas appelées déclenchantes, elles sont juste dans les préconditions.

•  Les conditions permettant de choisir entre les différentes options d’une alternative. On peut en effet considérer que ces conditions sont déclenchantes. On constate par contre qu’elles ne sont pas présentes dans toutes les alternatives, alors qu’elles devraient l’être, ne serait ce que pour indiquer les critères de choix entre les différentes alternatives.

•  Les conditions qui permettent d’exprimer les interruptions ou les priorités. Là encore, dans la plupart des cas, les conditions sont sous forme de préconditions normales. D’autre part, aucune précision sur la manière dont fonctionne les interruptions n’est réellement explicitée. Ces problèmes sont repris dans les paragraphe sur les interruptions et les priorités.

On constate donc que les conditions nécessaires déclenchantes existent dans les arbres, sont utiles mais ne sont pas toujours différenciées des préconditions normales. D’autre part, on constate qu’il existe plusieurs sortes de conditions nécessaires déclenchantes. Des précisions sont donc nécessaires sur la définition des conditions nécessaires déclenchantes.

8.1.6. Signification des pré-conditions non vérifiées

Dans le formalisme, il est spécifié que les préconditions sont des prédicats exprimant des contraintes qui doivent nécessairement être vérifiées pour pouvoir déclencher l’exécution de la tâche. Or, cette définition ne dit pas quelles sont les conséquences pour l’activité si les préconditions ne sont pas vérifiées. En effet, plusieurs interprétations sont possibles. On peut considérer que la tâche ne sera pas exécutée si ses préconditions ne sont pas vérifiées, en d’autres termes qu’elle sera “sautée”. Une autre interprétation pourrait être de dire que l’opérateur attend qu’elles soient satisfaites sans rien faire, ou bien, qu’il fait une autre tâche en attendant. Dans le cas où l’opérateur fait une autre tâche en attendant, doit-il s’interrompre si pendant l’exécution de la tâche d’attente, les préconditions de la première sont satisfaites ?

Tout ceci est sujet à interprétation et nécessite des éclaircissements.

8.1.7. Postconditions : résultat de l'action ou conditions de fin de tâche ?

On trouve dans les arbres deux types de postconditions réellement différentes. D’une part, certaines postconditions expriment le résultat de la tâche. C’est par exemple pour la tâche “éteindre l’incendie” la postcondition “feu éteint”. Ce type de postconditions exprime un changement de l’état du monde qui découle du corps de la tâche. Quand la tâche se termine, alors, la postcondition est vérifiée.

D’autre part, certaines postconditions expriment des conditions d’arrêt de la tâche. C’est par exemple pour la tâche “classer les strips” la postcondition “aucun strip à classer”. Dans ce cas, la tâche continue tant que la postcondition n’est pas vérifiée. C’est la postcondition qui conditionne la fin de la tâche.

Ces deux types de postconditions répondent bien à la définition initiale, dans le sens où elles sont effectivement satisfaites lorsque la tâche se termine, mais une distinction au niveau de la définition semble nécessaire.

8.1.8. But

Si on observe quelques exemples de buts dans les arbres, on constate qu'ils n'ont aucun rapport avec les définitions de MAD :

-  Le CO relevant s'installe à la position.

-  S'assurer que le digitatron fonctionne correctement.

-  Préserver les personnes à bord et le navire.

-  S'informer des différentes données concernant le secteur et le trafic qui le traverse.

En effet, la définition de MAD nous dit “sous-ensemble de l'état final, indiquant explicitement le but recherché dans l'exécution de la tâche.” Or, dans le rapport [Sebillotte 1991], on trouve la définition suivante : “but : (qui peut être un sous-ensemble de l'état final), il indique explicitement le but recherché et atteint par l'exécution de la tâche.” Cette définition invite à faire une description textuelle du but de la tâche et de son action, ce qui est fait dans les arbres existants. Cela correspond même le plus souvent à une explication détaillée sous forme textuelle de la tâche. Ce texte a une valeur descriptive importante mais n'est pas prévu dans la définition originelle de MAD. Ce que l'on veut dans le but, c'est OBLIGATOIREMENT un sous-ensemble de l'état final, c'est-à-dire une liste d'objets incluse dans la liste de l'état final.

Plusieurs remarques peuvent être tirées de ces observations :

•  Il semble toujours possible d'exprimer les exemples de buts énoncés sous forme de texte en terme d'action ou de condition sur des objets.

•  Il serait intéressant d'intégrer dans le formalisme MAD une description sous forme de texte. Ces descriptions pourraient faciliter la compréhension du but mais aussi des autres éléments de la tâche.

•  Il faut exprimer l'information contenue dans l'élément but tel que défini initialement, c'est-à-dire le sous-ensemble de l'état final indiquant explicitement le but recherché.

Ces remarques devront donc être prises en compte par la définition.

8.2. Problèmes formels

Lors de l’application du formalisme sur le terrain, quelques problèmes se sont posés. En effet, certaines caractéristiques des activités observées ne pouvaient pas être facilement exprimées avec le formalisme. Nous avons ici recensé les différents problèmes rencontrés.

8.2.1. Constructeur parallèle et simultané

Au départ, MAD a été pensé comme méthode d’analyse de l’activité d’un seul opérateur. Or, outre le fait que les activités soient rarement totalement individuelles, les deux activités décrites dans les arbres impliquent plusieurs opérateurs. Un des principaux problèmes pour l’utilisation de MAD pour décrire l’activité de plusieurs opérateurs est la faiblesse du constructeur parallèle. En effet, le constructeur parallèle est supposé représenter des sous-tâches dont l’ordre d’exécution n’a pas d’importance et en même temps des sous-tâches qui peuvent éventuellement s’exécuter simultanément. Or, il est clair que ces notions sont différentes et doivent être plus détaillées dans les définitions.

En effet, le fait que l’ordre des tâches ne soit pas contraint ne dit rien sur la simultanéité possible des sous-tâches. D’autre part, même si l’ordre des tâches n’est pas contraint, il peut être intéressant d’exprimer des priorités entre les tâches. Il faut donc que le formalisme puisse exprimer ces priorités.

En ce qui concerne la simultanéité, l’approche des praticiens a été de définir un nouveau constructeur appelé “simultané” pour exprimer des tâches pouvant s’effectuer simultanément. Le problème est que deux sous-tâches d’une simultanée peuvent commencer ou finir à des moment différents. Or, le constructeur ne permet pas d’exprimer ces nuances de simultanéité. Il faut donc pouvoir exprimer les conditions temporelles de début et de fin de tâche.

8.2.2. Interruptions

Le problème de la gestion des interruptions est abordée dans tous les rapports sur MAD. Une proposition de [Delsol 1992], reprise dans [Fallah 1993] et [Alonso 1992], est d’ajouter un attribut “interruptible” à chaque tâche au niveau du constructeur. Or, si l’utilité de l’attribut est reconnue par tous (théoriciens et praticiens), aucune utilisation concrète n’est présente dans les arbres alors que le besoin existe. Les arbres ne contiennent aucune information permettant de décrire les mécanismes d’interruption ou bien parfois contiennent des conditions sous forme de phrases non formalisées.

Après entretiens, la conclusion est que si l’attribut interruptible n’est pas utilisé, c’est parce qu’il n’est pas suffisamment défini et formalisé. Il faut donc un effort dans ce sens.

8.2.3. Boucles

Les boucles sont considérées comme des constructeurs dans les définitions du formalisme. Or, on observe dans les arbres que ce constructeur n’est jamais utilisé tel que décrit dans la définition.

Néanmoins, on trouve des boucles dans les arbres. Voici les quelques cas trouvés :

•  les tâches élémentaires qui se répètent elles-même : “rechercher des informations”. L’action se répète tant que les informations ne sont pas trouvées. Dans ce cas, un attribut nommé itérative, boucle ou répétitive selon les cas a été défini par les praticiens. Parfois, aucune information sur les fiches ne signale l’aspect itératif ou répétitif de la tâche, il ne se déduit que du contenu sémantique de l’action. Il faut donc définir clairement un attribut unique d’itération ainsi que les moyens de l’utiliser pour les tâches élémentaires.

•  les tâches élémentaires qui contiennent dans leurs postconditions des phrases du genre : “boucler sur tâche X” où X est une tâche de niveau plus abstrait. Cela signifie qu’une tâche décomposée doit être répétée plusieurs fois. Or cette tâche décomposée peut avoir une structure parallèle ou séquentielle. Si on voulait utiliser le constructeur boucle, on ne pourrait pas exprimer cette structure en même temps. L’aspect itératif ne doit donc pas être exprimé par le constructeur mais par un attribut supplémentaire de la tâche.

•  les tâches dites “itératives” dont l’exécution exige l’obtention de valeurs particulières de variables : “préparer le trafic en sortie” qui continue tant que la configuration en sortie n’est pas satisfaisante. Il s’agit de tâches débutées dans un premier temps (réalisation de certaines sous-tâches) avec certains paramètres, mais qui sont susceptibles de revenir sur elles-mêmes avec des informations supplémentaires pour atteindre un état qui autorise la poursuite de la tâche. Dans ce cas, il faut pouvoir exprimer formellement la condition de fin de tâche.

•  les tâches dites “répétitives” du genre “faire une première classification” qui a lieu au cours de la planification du trafic et qui est réalisée autant de fois qu’il y a de strips reçus. Ce sont des tâches qui sont réalisées un certain nombre de fois jusqu’à l’épuisement d’événements déclenchant son exécution. Là aussi, il faut pouvoir exprimer formellement d’une part l’aspect répétitif et d’autre part les conditions déterminant le nombre d’itérations.

8.2.4. Tâches continues

Certaines tâches dans les arbres sont dites continues. Les différents types de tâches continues sont les suivantes :

•  les tâches de “surveillance” : l’opérateur “attend” une configuration particulière des valeurs des différents paramètres pour entreprendre des actions appropriées.

•  les tâches “implicites” : elles sont exécutées de façon systématique tout au long de la réalisation de la tâche mère. C’est par exemple le cas de la tâche “recueil d’informations” dans le contrôle aérien. Elle est réalisée tout au long du contrôle. Ce pourrait être aussi une tâche “prendre des notes sur activité”.

Les praticiens ont proposé de définir un nouvel attribut continuité. Il faut formaliser cet attribut.

8.2.5. Attribut facultatif

Les facultatives sont considérées comme des constructeurs dans les définitions du formalisme. Or, on observe dans les arbres que ce constructeur n’est jamais utilisé tel que décrit dans la définition.

Néanmoins, on trouve des facultatives dans les arbres. Par exemple, la tâche “évacuer” de la lutte contre l’incendie est considérée comme facultative. La tâche de niveau supérieur “lutter contre l’incendie” peut se terminer sans que la sous-tâche “évacuer” n’ait été accomplie. Or, la tâche “évacuer” est elle-même composée séquentielle. L’aspect facultatif doit donc être exprimé en plus du constructeur de sous-tâche par un autre attribut de la tâche. L’approche choisie dans [Alonso 1993] est de dire pour chaque tâche si elle est facultative ou obligatoire, ce qui correspond à créer un nouvel attribut.

8.2.6. Opérateur

Dans la définition originale de MAD, l’opérateur n’est pas du tout défini au niveau de la tâche. En effet, le point de vue adopté au départ est celui de la description de l’activité d’un opérateur seul en vue de spécifications d’une interface entre UN homme et UNE machine. Or, le parti a été pris d’étendre les possibilités de description de MAD à des activités impliquant plusieurs opérateurs ainsi que pour étudier le partage des tâches.

Plusieurs besoins se sont faits sentir. Tout d’abord, un nouvel attribut “opérateur” a été créé. Celui-ci est utilisé dans l’arbre de résolution d’incendies. Pour chaque tâche, on définit l’opérateur qui la réalise. Cette approche semble tout à fait satisfaisante.

On constate que les opérateurs peuvent intervenir dans les conditions. Ils sont donc, dans ce cas, considérés comme des objets.

Il peut aussi arriver que plusieurs opérateurs soient possibles pour une tâche. Ainsi, le nouvel attribut opérateur peut avoir plusieurs valeurs. Mais il faut que le formalisme puisse exprimer les critères qui vont permettre de choisir entre les valeurs.

L’étude sur le partage des tâches utilise une autre approche. En effet, l’intérêt est centré sur le répartition des différentes tâches de la même activité selon les critères suivants : trafic fort ou faible, un seul contrôleur, deux contrôleurs, un contrôleur avec un ou deux élèves. Dans ce cas, des tableaux spécifiques ont été établis que l’on trouve en annexe du rapport [Alonso 1993].

8.2.7. Outils et informations utilisées

Deux nouveaux éléments ont été introduits lors de l’étude sur le contrôle aérien : les outils et les informations utilisées. Ceux-ci ont une grande utilité pour l’analyse de l’activité. En effet, ils permettent de mieux situer le “monde” de chaque tâche.

Néanmoins, ce sont des objets de l’état du monde, or la définition dit que les objets nécessaires à la tâche doivent apparaître dans l’état initial. Il faut donc préciser formellement la définition des outils et informations utilisées.

8.3. Problèmes d’outils

L’utilisation de MAD est rendue difficile par l’absence d’outils réellement adaptés. Nous recensons ici les différentes conséquences de ces problèmes.

8.3.1. Manipulation des arbres graphiques

Les arbres graphiques ne sont pas homogènes dans leur présentation. L’arbre du contrôle aérien est présenté horizontalement, l’autre l’est verticalement. Ceci n’est pas trop grave. Ce qui est par contre plus regrettable est le non alignement des tâches de même niveau, ainsi que certaines configurations peu claires.

Tous ces problèmes de présentation des arbres graphiques expriment la difficulté de manipulation des arbres graphiques avec l’outil utilisé actuellement, c’est-à-dire le logiciel de dessin Mac Draw. En effet, cet outil ne reconnaît et ni ne permet pas du tout la manipulation d’une structure d’arbre telle que celle de MAD. D’autre part, dans le cas d’arbres complexes, les modifications deviennent vite fastidieuses et compliquées, d’où des arbres par toujours clairs.

Le manque d’outils adaptés pour manipuler des arbres pose donc un réel problème aux utilisateurs du formalisme. Il serait donc intéressant de développer un outil pour MAD.

8.3.2. Duplication et numérotation des tâches

Une étude sur le partage des tâches et l’influence de certains facteurs en rapport avec le contrôle aérien est présentée dans le rapport [Alonso 1993]. En effet, un des buts de cette étude est de montrer l’influence de l’importance du trafic ainsi que du nombre d’opérateurs en poste sur l’activité. Ainsi, pour chaque configuration du trafic et d’opérateurs, on observe une configuration de tâches différentes. Or, ces différentes configurations sont exprimées sous forme de tableau. Ces tableaux reprennent les noms de tâches de l’arbre original ainsi que leurs numéros. D’autre part, certaines tâches sont dupliquées, parfois plusieurs fois.

Ces tableaux remplissent bien leur rôle, à savoir montrer les différentes configurations de tâches selon les conditions, mais plusieurs problèmes se posent. Ces tableaux sont en fait des arbres MAD “écrasés” et divisés. Leurs inconvénients sont qu’ils ne visualisent pas du tout la structure arborescente des tâches. D’autre part, la numérotation n’a plus aucune logique, elle ne sert qu’à se référer aux fiches de l’arbre mais n’expriment plus du tout le niveau d’abstraction ou l’enchaînement logico-temporel.

En fait, à chaque tableau aurait du correspondre un arbre graphique MAD décrivant la tâche selon les facteurs. Le contenu de chaque tâche ou sous-tâche aurait été reprise de la base de tâches établie avec le premier arbre. La numérotation aurait pu être locale à chaque sous-arbre.

Si une telle démarche n’a pas été effectuée, c’est essentiellement par manque ou faiblesse d’outils. En effet, le temps imparti à cette étude ne permettait pas de redessiner chaque arbre avec l’outil actuel Mac Draw. D’autre part, l’absence de possibilité simple de réutilisation de la base de tâche existante a obligé l’ergonome à faire des duplications et des transferts alors qu’il aurait été préférable d’avoir une base de tâches organisée en classes à partir de laquelle on aurait pu construire un arbre structuré en réutilisant les connaissances.

Là encore, le manque d’outils adaptés pour manipuler le formalisme MAD pose un réel problème.

9. Interprétation et discussion

Après avoir recensé et analysé les différents problèmes rencontrés lors de l’utilisation du formalisme MAD, il devient possible de donner quelques éléments permettant de comprendre l’origine de ces difficultés. Ce qui nous permettra ensuite de faire des propositions pour tenter de résoudre ces problèmes.

9.1. Interprétation

Les résultats de l’analyse nous apprennent que les définitions originelles de MAD ont été l’objet d’interprétations. Ces interprétations sont dues d’une part, aux nécessités liées à l’application du formalisme sur un terrain réel, et d’autre part, à une trop grande généralité des définitions. De plus, certains concepts n’ont pas été suffisamment définis au départ.

D’autre part, le formalisme a été défini à l’origine pour décrire des tâches de bureau. Ces tâches impliquent généralement un seul opérateur. Or, l’un des objectifs des études sur le contrôle aérien et la résolution d’incendies était d’évaluer le formalisme sur la description d’activités complexes. Ainsi, si le formalisme s’est révélé tout à fait satisfaisant dans la plupart des cas, certaines caractéristiques des tâches n’ont pu être exprimées simplement. Les principaux problèmes sont  : les tâches impliquant plusieurs opérateurs, les interruptions de tâches, les boucles et les tâches facultatives. Quelques propositions d’extension du formalisme ont été faites et mises en application dans les arbres. Elles ont permis de résoudre une partie des problèmes.

Pour finir, nous avons constaté que l’utilisation de MAD était rendue difficile par le manque d’outils informatiques adaptés. Une première tentative de développement d’un outil permettant la saisie du formalisme MAD a montré les difficultés rencontrées lors de l’implémentation d’un formalisme de description de tâches.

9.2. Discussion

Dans la partie précédente, nous avons pu établir trois problèmes principaux rendant l’utilisation de MAD difficile : l’interprétation des définitions initiales, l’insuffisance du formalisme à exprimer certaines caractéristiques des tâches et le manque d’outils informatiques adaptés.

Pour les deux premiers problèmes, une solution est de proposer une nouvelle définition du formalisme MAD. Celle-ci devra prendre en compte toutes les remarques énoncées dans la partie résultat. Ainsi, les parties des définitions sujettes à interprétation devront être précisées. Des définitions pour les nouveaux attributs devront être proposées.

Pour le problème du manque d’outils, un des objectifs du stage était justement de définir et des spécifications pour un logiciel permettant la saisie et l’édition du formalisme MAD sur ordinateur. Les arbres de tâche étant stockés sous forme de fichier informatique, l’édition en serait donc facilitée. D’autre part, une autre étude [Hammouche 1993] consiste à élaborer un système expert permettant d’utiliser les arbres MAD pour produire des spécifications d’interfaces homme-machine au niveau conceptuel de la tâche correspondante.

Nous présentons donc en annexe une nouvelle définition de MAD ainsi que les spécifications de l’interface de saisie du formalisme.

10. Conclusion

Après avoir recensé les différents problèmes rencontrés par les utilisateurs de MAD, nous avons établi la nécessité de nouvelles définitions pour le formalisme. L’essentiel de l’étude a été consacrée à l’élaboration de ces nouvelles définitions. Celles-ci sont le fruit d’une collaboration étroite entre toutes les personnes du projet travaillant avec MAD. Le but était de concilier les vues des différents utilisateurs : formalistes théoriciens et utilisateurs sur le terrain, informaticiens et ergonomes, en une synthèse respectant les critères et objectifs définis au départ. Bien entendu, il reste maintenant à valider les nouvelles définitions en l’utilisant pour décrire une activité réelle. Une première étape pourrait aussi être la modification des arbres existants pour correspondre aux nouvelles définitions. Ainsi, après une nouvelle utilisation, les définitions pourraient de nouveau être affinées.

Le stage avait aussi pour objectif annexe la spécification et la réalisation d’un logiciel permettant la saisie et l’édition du formalisme. Or, par manque de temps, seule une ébauche de logiciel a pu être développée. La réalisation sera bientôt reprise par une autre personne, ainsi on pourra disposer prochainement d’un outil pour faciliter l’utilisation de MAD.

Les perspectives du formalisme MAD sont importantes. Deux activités complexes ont été décrites à l’aide de MAD. Ces descriptions ont déjà pu être très utiles pour la connaissance des domaines impliqués ainsi que pour la spécification d’interfaces. Bientôt, un système expert générera automatiquement des spécifications conceptuelles d’interfaces à partir du formalisme.

D’autre part, il serait intéressant d’étudier les caractéristiques formelles de MAD ainsi que les méthodes de recueil de données. Un objectif serait l’écriture d’un “mode d’emploi” du formalisme. Ainsi on pourrait obtenir une méthode générale décrivant comment réaliser le recueil de données, la construction de la description de tâches, la spécification, voire la réalisation d’une interface homme-machine. Un outil informatique d’aide (et non seulement d’édition) à la construction d’arbres pourrait aussi être imaginé.

Du point de vue de l’intelligence artificielle, le formalisme est très intéressant pour la représentation des connaissances. Il permet de représenter, voire de modéliser des informations de type tâche d’une façon à la fois proche du langage naturel et possible à implémenter. On pourrait ainsi en déduire des systèmes de planification.

11. Bibliographie

Alonso B. (1993) : Le partage des tâches entre contrôleurs aériens, Rapport convention INRIA/CENA 91/C.0007.

Coutaz J. (1988) : De l'ergonome à l'informaticien : pour une méthode de conception et de réalisation des systèmes interactifs. Actes du colloque ERGO-IA'88, 4-6 octobre 1988, Biarritz, France.

Delouis I., Pierret C. (1991) : EMAD, manuel de référence, Rapport interne INRIA.

Delsol P. (1992) : Description des tâches de contrôle aérien, amélioration du formalisme MAD, modifications de la description. Prise en compte du partage des tâches entre les contrôleurs, Rapport convention INRIA/CENA 91/C.0007.

El Farouki L., Scapin D.L., Sebillotte S. (1991) : Prise en compte des tâches du contrôleur pour l'ergonomie des interfaces, Rapport convention INRIA/CENA 90/C.0008.

Fallah D. (1992) : Description des tâches selon le formalisme MAD par l'étude des traces : résolution d'incidents maritimes, Rapport de DESS, DEA, INRIA, à paraître.

Hammouche H. (1993) : De la modèlisation des tâches à la spécification d’interfaces utilisateur , Rapport de recherche INRIA à paraître.

Pierret-Goldbreich C., Delouis I., Scapin D.L. (1989) Un outil d'acquisition et de représentation des tâches orienté objet, Rapport de recherche INRIA N°1063

Rechenman F., Fontanille P., Uvietta P. (1988) : SHIRKA, système de gestion de bases de connaissances centrées-objet, manuel d’utilisation.

Richard J.F., Poitrenaud S., Tijus C.A. (1990) : An object-oriented semantic description of procedures for evaluation of interfaces, Proceedings, ECCE-5, Fifth European Conference on cognitive ergonomics.

Scapin D.L. (1988) : Vers des outils formels de description des tâches orientés conception d'interfaces, Rapport de recherche N°893, INRIA Rocquencourt.

Scapin D.L., Pierret-Goldbreich C. (1989) : MAD : une méthode analytique de description des tâches, colloque sur l'ingénierie des interfaces homme-machine, Sophia-Antipolis.

Sebillotte S. (1987) : La planification hiérarchique comme méthode d’analyse de tâches; analyse de tâches de bureau, Rapport de Recherche N°599, INRIA Rocquencourt.

Sebillotte S. (1991) : Décrire des tâches selon les objectifs des opérateurs, de l'interview à la formalisation, Le Travail Humain 54,3 p193-223.

12. Annexes

- Nouvelle définition de MAD.

- Partie de l’arbre du contrôle aérien.

- Partie de l’arbre de la résolution d’incendies.