UNIVERSITÉ DE MONTRÉAL
CONCEPTUALISATION DE L'INTERFACE D’UN LOGICIEL
D’ASSISTANCE À L'ANALYSE ERGONOMIQUE DE TÂCHE
AVEC INTÉGRATION DE PLUSIEURS MÉTHODES
ROBERT MORIN
DÉPARTEMENT DE MATHÉMATIQUES ET DE GÉNIE INDUSTRIEL ÉCOLE POLYTECHNIQUE DE MONTRÉAL
MÉMOIRE PRÉSENTÉ EN VUE DE L’OBTENTION DU DIPLÔME DE MAÎTRISE ÈS SCIENCES APPLIQUÉES
(GÉNIE INDUSTRIEL) AOÛT 2014
UNIVERSITÉ DE MONTRÉAL
ÉCOLE POLYTECHNIQUE DE MONTRÉAL
Ce mémoire intitulé :
CONCEPTUALISATION DE L'INTERFACE D’UN LOGICIEL D’ASSISTANCE À L'ANALYSE ERGONOMIQUE DE TÂCHE AVEC INTÉGRATION DE PLUSIEURS
MÉTHODES
présenté par : MORIN Robert
en vue de l’obtention du diplôme de : Maîtrise ès sciences appliquées a été dûment accepté par le jury d’examen constitué de :
M. DESMARAIS Michel, Ph.D., président
M. ROBERT Jean-Marc, Doctorat, membre et directeur de recherche M. ROBILLARD Pierre-N., Ph.D., membre
REMERCIEMENTS
Je tiens à remercier mon directeur de recherche, M. Jean-Marc Robert, pour sa patience et son soutien tout au long de ce qui fut un parcours un peu chaotique par moments, mais ayant finalement produit des résultats qui, je l’espère, auront justifié le tout.
Aussi et surtout, je veux remercier ma femme pour son amour et son appui indéfectibles durant toute l’aventure.
RÉSUMÉ
Il arrive souvent, dans le cours d’une analyse ergonomique de tâche, qu’il soit nécessaire d’utiliser plus d’une méthode d’analyse pour tirer un maximum d’enseignements des diverses sources d’informations concernant la tâche effectuée par un humain (p. ex. : documents, interviews, observations, prises de mesures, etc.). Malheureusement, dans le contexte actuel, les logiciels qui sont mis à la disposition des analystes ne supportent qu’une seule méthode d’analyse, ce qui force ces derniers à soit n’utiliser qu’une seule méthode soit, s’ils veulent vraiment utiliser plusieurs méthodes, à dupliquer certaines informations pour utiliser d’autres logiciels supportant chacun une autre méthode. Il y a donc tout lieu de croire qu’un logiciel supportant plusieurs méthodes d’analyse peut être utile. L’objectif de cette recherche est donc d’effectuer une proposition détaillée de ce que pourraient être les fonctionnalités et l’interface utilisateur d’un tel logiciel.
Après une revue de la littérature sur les méthodes d’analyse ergonomique de tâche, il a été décidé que le logiciel allait supporter un éventail de méthodes permettant l’analyse de tâches individuelles, incluant l’analyse hiérarchique de tâche (AHT), l’ordinogramme de traitement humain de l’information (OTHI) qui est une forme d’analyse procédurale, la méthode analytique de description de tâche (MAD), l’analyse temporelle, KLM-GOMS et CMN-GOMS. En cours de route, CMN-GOMS s’est révélé être une méthode d’analyse hybride, puisqu’elle est, en fait, une combinaison de deux méthodes : AHT et KLM-GOMS. La méthode CMN-GOMS ne sera donc supportée par @Esperanto que sous la forme d’une analyse multiméthode, soit l’une des nombreuses possibilités du logiciel.
Parce que les méthodes d’analyse de tâches susmentionnées doivent être supportées par un seul et même logiciel, elles ont été soigneusement étudiées pour déterminer leurs points communs et leurs différences. Constatant de nettes différences entre les méthodes sur le plan de leur expressivité, on a voulu, sans affecter leur essence, réduire ces différences pour faciliter les échanges d’informations entre elles. Les méthodes retenues ont donc été rangées dans l’une de deux grandes classes, selon qu’elles servent à analyser une tâche globalement ou à en préciser tous les détails, puis leur expressivité a été examinée et, si possible, augmentée pour obtenir dans chaque classe la plus large base commune possible.
Par la suite, tous les efforts ont porté sur la conceptualisation du logiciel et sur le prototypage très détaillé de plusieurs fenêtres de son interface utilisateur. Le résultat donne une bonne vue d’ensemble des principales fonctionnalités du logiciel et de l’organisation de son interface utilisateur et pourra servir, espère-t-on, comme outil de promotion pour la création d’un logiciel d’analyse ergonomique de tâche multiméthode.
ABSTRACT
Oftentimes, in the course of an ergonomic task analysis, it is necessary to use more than one task-analysis method in order to get the most out of the information gathered about a task that humans must carry out (e.g., documents, interviews, observations, measurement taking, etc.). Unfortunately, the current situation is that all widely available task-analysis software applications support only one task analysis method, thus forcing analysts to either use only one method or to duplicate some information in order to use many applications, each supporting a different method. Therefore, there is every reason to believe that an application supporting multiple task-analysis methods would be useful. The current research goal is to create a detailed proposal for the envisioned functionalities and user interface of such application.
After a literature review on ergonomic task analysis methods, it was decided that the proposed application would support an array of methods for the analysis of individual tasks, including Hierarchical Task Analysis (HTA), a form of procedural analysis, MAD (the French acronym for Analytical [Task] Description Method), a timeline analysis method, KLM-GOMS and CMN-GOMS. Along the way, CMN-GOMS was found to be a hybrid method, as it is a combination of two methods: HTA and KLM-GOMS. CMN-GOMS will therefore not be directly supported; rather, it will be supported as one of the many possible combinations for multi-method analysis. As the aforementioned task-analysis methods must be supported by a single application, they have been carefully studied in order to highlight their commonalities and their differences. Because considerable differences in regard to expressiveness were exposed — while adamant in our desire to not change the essence of each method — we set out to minimize these differences. For this, we assigned every supported method to one of two classes, depending on whether it is meant to analyze the various components of a task or to delve into its minutiae. Then, the expressiveness of each was examined and, as feasible, extended in order to increase commonalities among methods of the same class.
Once this was done, all efforts have focused on conceptualizing the application’s functionalities as well as prototyping most of its user interface. The resulting thesis provides a good overview of the application’s planned functionalities and proposed user interface which, it is hoped, can serve as a promotion tool to create excitement leading to the creation of this multi-method ergonomic task analysis application.
TABLE DES MATIÈRES
REMERCIEMENTS ... III RÉSUMÉ ... IV ABSTRACT ... VI TABLE DES MATIÈRES ...VII LISTE DES TABLEAUX ... XI LISTE DES FIGURES ...XII LISTE DES SIGLES ET ABRÉVIATIONS ... XV LISTE DES ANNEXES ... XVIII
INTRODUCTION ... 1
CHAPITRE 1 PRÉSENTATION DES MÉTHODES D’ANALYSE DE TÂCHE ... 8
1.1 Quelques points communs ... 8
1.2 Réseaux ... 11
1.3 Analyse hiérarchique de tâche (AHT) ... 12
1.4 Analyse procédurale / Ordinogramme de traitement humain de l’information (OTHI) 17 1.5 Méthode analytique de description de tâche (MAD) ... 21
1.6 Analyse temporelle (AT) ... 26
1.6.1 Représentation textuelle ... 27
1.6.2 Représentations graphiques ... 28
1.7 Goals, Operators, Methods, and Selection Rules (GOMS) ... 32
1.8 KLM-GOMS ... 34
1.9 CMN-GOMS ... 38
CHAPITRE 2 NORMALISATION DES MÉTHODES D’ANALYSE DE TÂCHE ... 41
2.1 Récapitulatif des différences entre les méthodes d’AT ... 41
2.2 Méthode native et méthode courante ... 41
2.3 À propos de la normalisation des méthodes d’analyse de tâche ... 43
2.4 Avant de continuer : un petit secret… Ce sont toutes des AHT! ... 45
2.5 Normalisation et notation des méthodes d’analyse supportées ... 47
2.6 Normalisation de l’AHT ... 48
2.6.1 Normalisation et notation des tâches en AHT ... 48
2.6.2 Normalisation et notation des plans en AHT ... 51
2.6.3 Représentations d’une AHT ... 56
2.7 Normalisation de l’analyse procédurale / OTHI ... 57
2.7.1 Représentations d’un OTHI ... 59
2.7.2 Sous-routines et paramètres ... 65
2.7.3 Création de procédures pour l’aide à la performance humaine ... 67
2.8 Normalisation de MAD ... 67
2.8.1 Représentations d’une analyse selon MAD ... 68
2.9 Normalisation de l’analyse temporelle ... 69
2.9.1 Identification des chemins d’exécution d’intérêt ... 71
2.10 Normalisation de KLM-GOMS ... 72
2.11 Normalisation de CMN-GOMS ... 72
2.12 Synthèse ... 73
CHAPITRE 3 CONCEPTUALISATION ET PROTOTYPAGE DE L’IU ... 74
3.1 Fonctionnalités d’utilité générale ... 74
3.1.2 Navigation dans une analyse de tâche ... 75
3.2 AHT ... 78
3.2.1 Processus de construction d'une AHT ... 78
3.2.2 Modification d’une AHT à partir de la fenêtre principale ... 85
3.2.3 Éditeur de plan structuré ... 88
3.2.4 Éditeur graphique de plan ... 91
3.3 OTHI ... 91
3.3.1 Processus de construction d'un OTHI ... 91
3.3.2 Fenêtre principale ... 92
3.3.3 Modification d’une OTHI à partir de la fenêtre principale ... 94
3.3.4 Éditeur de plans AHT en représentation graphique ... 103
3.4 MAD ... 104
3.4.1 Processus d’élaboration d'une description de tâche selon MAD ... 104
3.4.2 Fenêtre principale ... 106
3.4.3 Fenêtre favorisant l’entrée de masse (ou éditeur de tâche) ... 106
3.4.4 Modification d’une description de tâche MAD de la fenêtre principale ... 111
3.4.5 Éditeur de plan structuré ... 112
3.5 Analyse temporelle ... 112
3.5.1 Processus de construction d'une analyse temporelle ... 112
3.5.2 Extraction d’un scénario d’une étude globale (AHT, OTHI ou MAD) ... 112
3.5.3 Création et modification d’une analyse temporelle ... 115
3.5.4 Visualisation d’une analyse temporelle ... 116
3.6 KLM-GOMS ... 117
3.6.2 Création et modification d’une analyse KLM-GOMS ... 118
3.7 CMN-GOMS ... 119
3.7.1 Une méthode toute désignée pour @Esperanto ... 119
3.8 Analyse multiméthode ... 120
3.8.1 De la complexité de l’ensemble aux menus détails ... 120
3.8.2 Transitions possibles entre méthodes d’analyse ... 120
3.8.3 Changement de méthode d’analyse ... 122
3.8.4 Changement pour une autre méthode d’analyse globale ... 123
3.8.5 Changement pour une méthode d’analyse locale d’une analyse globale ... 125
3.8.6 Analyse locale mixte ... 125
3.8.7 Un cas particulier : AHT + KLM-GOMS == CMN-GOMS ... 127
3.9 Conversion entre AHT et OTHI ... 129
3.9.1 Conversion d’une AHT en OTHI ... 129
3.9.2 Conversion d’un OTHI en AHT... 130
3.10 Synthèse ... 133
CONCLUSION ... 134
BIBLIOGRAPHIE ... 136
LISTE DES TABLEAUX
Tableau 1-1 Énoncés disponibles pour les plans d'une AHT. ... 14
Tableau 1-2 Notation utilisée par TaskArchitect© pour les plans d'une AHT. ... 15
Tableau 1-3 Opérateurs KLM-GOMS couramment utilisés. ... 35
Tableau 1-4 Opérateurs KLM-GOMS ajoutés pour l'étude d'IHM sur téléphones mobiles. ... 35
Tableau 2-1 Caractéristiques des méthodes supportées par @Esperanto. ... 42
Tableau 2-2 Notation textuelle pour les tâches. ... 49
Tableau 2-3 Notation graphique pour les tâches. ... 49
Tableau 2-4 Formes identifiant un aspect important d'une tâche. ... 52
Tableau 2-5 Énoncés pour les plans d'une AHT (notation basée sur Stanton (2006)). ... 54
Tableau 2-6 Énoncés pour les plans d'une AHT (notation basée sur TaskArchitect©). ... 55
Tableau 2-7 Notation graphique des différents enchaînements de tâches. ... 60
Tableau 2-8 Notation graphique des énoncés inspirés de la programmation structurée. ... 61
Tableau 2-9 Les divers éléments de la définition d'une sous-routine. ... 66
LISTE DES FIGURES
Figure 1-1 AHT partielle pour la tâche consistant à envoyer un courriel. ... 15
Figure 1-2 AHT de la figure 1 1 en représentation textuelle. ... 16
Figure 1-3 Symboles de base d'un ordinogramme. ... 18
Figure 1-4 Symboles supplémentaires représentant un aspect important d'une tâche. ... 18
Figure 1-5 OTHI correspondant approximativement à l'AHT partielle pour la tâche consistant à envoyer un courriel. ... 19
Figure 1-6 Représentation textuelle de l’OTHI précédent. ... 20
Figure 1-7 Description habituelle d'une tâche selon MAD. ... 23
Figure 1-8 Représentation possible de la tâche «Envoyer courriel» du précédent exemple. ... 25
Figure 1-9 Analyse temporelle d’une méthode réalisant l’envoi d’un courriel. ... 27
Figure 1-10 AT pour l’envoi d’un courriel (représentation de base). ... 28
Figure 1-11 AT pour l’envoi d’un courriel (avec cumulatifs). ... 29
Figure 1-12 AT pour l’envoi d’un courriel (représentation linéaire horizontale simple). ... 29
Figure 1-13 AT pour l’envoi d’un courriel (avec parallélisme). ... 30
Figure 1-14 AT pour l’envoi d’un courriel (avec indication relative de la CMT). ... 31
Figure 1-15 AT pour l’envoi d’un courriel (représentation verticale). ... 31
Figure 1-16 KLM-GOMS pour une méthode réalisant l’envoi d’un courriel. ... 37
Figure 1-17 CMN-GOMS pour l’envoi d’un courriel (avec méthodes en KLM-GOMS). ... 39
Figure 1-18 CMN-GOMS pour l’envoi d’un courriel (comme vu dans la littérature). ... 40
Figure 2-1 Représentations graphiques optionnelles pour les tâches d'une AHT. ... 50
Figure 2-2 AHT normalisée pour la tâche d’envoi d’un courriel (repr. graphique). ... 57
Figure 2-3 AHT normalisée pour la tâche d’envoi d’un courriel (repr. textuelle). ... 58
Figure 2-5 OTHI normalisé identique au précédent hormis l’utilisation de sous-routines. ... 63
Figure 2-6 Représentation textuelle de l’OTHI de la figure 2-4. ... 64
Figure 2-7 Exemple de sous-routine selon la syntaxe du tableau 2-9. ... 66
Figure 2-8 Représentation normalisée possible de l’envoi d’un courriel. ... 68
Figure 2-9 Deux représentations optionnelles pour le corps d'une tâche MAD... 69
Figure 2-10 Deux analyses KLM-GOMS pour l’entrée de l'adresse du destinataire. ... 73
Figure 3-1 Figuration de la lentille virtuelle de la vue dite hyperbolique, dans laquelle les parties plus pâles montrent où les éléments à l’écran sont le plus rapetissée et où les déformations graphiques sont plus importantes. ... 76
Figure 3-2 Simulation des différences entre la vue normale et celle dite hyperbolique. Dans ce cas, c’est la tâche « 3.2 Entrer objet » qui est le point stable entre les vues. ... 77
Figure 3-3 Fenêtre pour la visualisation et l'édition d'AHT. ... 79
Figure 3-4 Contenu suggéré de la fenêtre d'acquisition d'une grande quantité de données. ... 80
Figure 3-5 Représentations graphique et textuelle de l'AHT comme entrée jusqu’ici. ... 84
Figure 3-6 Outils pour l’insertion de tâches par survol. ... 86
Figure 3-7 Mini dialogue pour l'entrée des informations concernant une nouvelle tâche. ... 87
Figure 3-8 Éditeur de plan AHT favorisant leur création de manière structurée. ... 88
Figure 3-9 Fenêtre pour la visualisation et l'édition d'un OTHI. ... 93
Figure 3-10 Les trois autres palettes pour la construction d'OTHI. ... 94
Figure 3-11 Dialogue acceptant les informations relatives à tout nouveau symbole « SI ». ... 95
Figure 3-12 Outils pour l’insertion de symboles par survol. a) Flèches bleues apparaissant lors du survol d’une tâche. b) Mini palette montrant les quatre onglets apparaissant au-dessus des palettes d’outils. c) L’utilisateur ayant choisi l’onglet «Groupes», la mini palette correspondante apparaît. ... 96
Figure 3-14 OTHI pour la tâche consistant à envoyer un courriel (utilisant deux
sous-ordinogrammes non montrés). ... 97
Figure 3-15 Palettes considérées pour l'insertion ou le remplacement de symboles. ... 99
Figure 3-16 Éditeur d'OTHI en représentation textuelle. ... 100
Figure 3-17 Plan assez complexe en représentation graphique. ... 104
Figure 3-18 Plan de la figure précédente en représentation textuelle. ... 105
Figure 3-19 Plan des deux figures précédentes en représentation hybride. ... 105
Figure 3-20 Fenêtre pour la visualisation et l'édition d'une tâche selon MAD. ... 107
Figure 3-21 Contenu suggéré de la fenêtre d'acquisition d'une masse de données. ... 108
Figure 3-22 Informations entrées à propos de la tâche principale « Envoyer courriel ». ... 109
Figure 3-23 Représentations graphique et textuelle de l'arbre MAD comme entrée jusqu’ici. .. 110
Figure 3-24 Infobulle montrant les détails de la tâche principale en réponse à son survol. ... 111
Figure 3-25 Éditeur d'analyse temporelle avec une représentation graphique horizontale. ... 116
Figure 3-26 Éditeur d'analyse temporelle avec une représentation graphique verticale. ... 117
Figure 3-27 AHT dans laquelle une tâche est analysée par un OTHI. ... 123
Figure 3-28 AHT avec une petite insertion en OTHI. ... 124
Figure 3-29 Visualisation d’informations relatives à une tâche analysée de manière mixte. ... 126
Figure 3-30 Insertions de petites analyses locales dans la représentation d'une AHT. ... 127
Figure 3-31 Analyse multiméthode simulant l'application de la méthode CMN-GOMS. ... 128
Figure 3-32 AHT servant de point de départ aux exemples de conversion AHT ↔ OTHI. ... 129
Figure 3-33 OTHI résultant du traitement de la racine de l'AHT de départ... 130
Figure 3-34 OTHI correspondant à l’AHT de départ (la hiérarchie est cependant perdue). ... 131
Figure 3-35 AHT résultant de la conversion d'un OTHI (sans égard à la hiérarchie)... 131
LISTE DES SIGLES ET ABRÉVIATIONS
@Esperanto Le nom du logiciel conceptualisé dans ce mémoire. Ce nom comporte deux parties, l’arobas (« @ ») et « Esperanto », le nom du langage créé par L. L. Zamenhof en 1887.
D’une part, l’arobas qui est quelques fois appelé « at » est, dans ce cas, l’acronyme de « analyse de tâche ». D’autre part, le logiciel conceptualisé ici, à l’image du langage, a pour but d’être un environnement neutre dans lequel tous les analystes de tâche trouveront un environnement qui transcende les frontières et facilite les communications entre les membres de la communauté internationale.
Activité Dans le monde de l’ergonomie francophone, le terme « activité » désigne chacune des étapes effectuées dans le cadre d’une tâche réelle. Toutefois, dans ce mémoire, le terme « tâche » (qui réfère plutôt aux étapes d’une tâche prescrite) est souvent utilisé pour désigner indifféremment les étapes de la tâche à analyser qui peut aussi bien être la tâche prescrite que la réelle.
AHT Analyse hiérarchique de tâche.
Aïeul Tout nœud d’un arbre sur le chemin allant de la racine jusqu’au parent du nœud considéré.
Analyse Le mot « analyse » ainsi que l’expression « analyse de tâche » sont employés pour désigner une analyse ergonomique de tâche. Il n’est jamais question, dans ce document, d’analyse informatique ou de toute autre forme d’analyse.
Analyste Comme pour le mot « analyse », le mot « analyste » est réservé pour les analystes de tâche (le plus souvent des ergonomes). Il n’est pas question, dans ce document, d’analyste informatique, financier ou autre…
Arbre Arbre hiérarchique, soit un graphe acyclique dont un et un seul nœud n’a aucun lien entrant (la racine). Les éléments d’un arbre hiérarchique sont reliés par des relations dites « parent-enfant » dont la signification peut varier selon l’utilisation de l’arbre (par exemple, « moyens-finalité » ou « cause-effet »). Dans le cas de l’analyse hiérarchique de tâche, c’est « but-moyens ».
AT Analyse de tâche ou analyse temporelle. Ce sigle ayant deux significations possibles, il n’est utilisé que lorsqu’il n’y a aucune confusion possible.
CMN-GOMS Card-Moran-Newell GOMS.
GOMS Goals, Operators, Methods, and Selection methods. Une famille de méthodes d’analyse ergonomique de tâche.
Enfant Tout nœud d’un arbre dont le nœud considéré est le parent direct.
Étude Ce terme est employé de manière assez générale pour désigner indifféremment une analyse de tâche ou un ensemble d’analyses de tâche effectuées pour un même but.
Frère/sœur Tout nœud d’un arbre ayant le même parent direct que celui considéré.
Infobulle Fenêtre, affichée en réponse au survol d’un item, dont le but est de fournir des informations à propos dudit item qui sont complémentaires à celles déjà visibles à l’écran.
IHM Interface humain-machine.
IU Interface utilisateur. C’est un cas particulier d’IHM référant spécifiquement à l’interface qu’offre un logiciel à ses utilisateurs.
KLM-GOMS Keystroke-Level Model GOMS.
MAD Méthode analytique de description de tâche.
Nœud Éléments constitutifs d’un arbre qui sont reliés par des relations père-enfant. OTHI Ordinogramme du traitement humain de l’information, une forme d’analyse
ergonomique de tâche procédurale.
Parent Nœud d’un arbre directement avant celui considéré dans le chemin entre la racine et lui-même.
Procédure Suite de tâches (ou activités) à effectuer les unes après les autres. Racine Le seul nœud de l’arbre qui n’a pas de parent (donc, de lien entrant).
Support Ce terme, souvent employé en développement informatique, a plusieurs acceptions. Dans ce mémoire, celle utilisée indique qu’un logiciel ayant été
programmé avec certaines connaissances à propos d’une ou plusieurs méthodes ou techniques est capable d’assister ses utilisateurs dans l’utilisation desdites méthodes ou techniques. Cette assistance peut prendre plusieurs formes : accompagnement des utilisateurs au travers les diverses étapes requises pour réaliser leur but, automatisation de certaines étapes, stockage et validation des données fournies, présentation des résultats avec affichages particuliers, etc. Survol Action de placer le pointeur de la souris au-dessus d’un item apparaissant à
l’écran, puis d’attendre quelques dixièmes de secondes. De cette action peut résulter l’apparition d’une infobulle.
Tâche Dans le monde de l’ergonomie francophone, le terme « tâche » est réservé pour les étapes suggérées d’une tâche prescrite. Toutefois, dans ce mémoire, ce terme est souvent utilisé pour désigner indifféremment les étapes de la tâche à analyser qui peut aussi bien être la tâche prescrite que la réelle. Lors d’une décomposition hiérarchique, on parlera alors de tâches, de sous-tâches, de sous-sous-sous-tâches, etc.
Utilisateur Ce terme est employé dans son acception habituelle en développement informatique. Ce mémoire montrant ce que pourrait être un logiciel d’assistance à l’analyse ergonomique de tâche, les utilisateurs principaux de celui-ci seront des analystes de tâche (qui seront probablement aussi des ergonomes cognitifs). Puisque les résultats d’une analyse de tâche doivent être montrés, compris et acceptés pour toutes les parties prenantes d’un projet, les analystes ne sont pas les seuls utilisateurs du logiciel. Cela dit, il est clair que lesdits analystes auront accès à l’ensemble des fonctionnalités du logiciel, alors que les autres utilisateurs ne pourront que consulter les résultats et ajouter des commentaires.
LISTE DES ANNEXES
INTRODUCTION
Cette recherche porte sur la conceptualisation d’un logiciel d’assistance à l’analyse ergonomique de tâche supportant plusieurs méthodes d’analyse de tâches, même concurrentes. Conséquemment, dans ce mémoire, les termes « analyse de tâche » ou simplement « analyse » réfèrent à une analyse ergonomique de tâche et non pas à une analyse informatique d’un programme ou à tout autre type d’analyse.
Cela dit et bien qu’il commence par une explication de ce qu’est une analyse ergonomique de tâche, ce mémoire n’a pas la prétention d’être une introduction à l’analyse de tâche ou à ses méthodes. À tous les lecteurs désireux d’approfondir ce sujet, l’auteur recommande la lecture de Crandall, Klein et Hoffman (2006) ou alors, pour un résumé très correct qui montre bien le contexte historique et permet de bien comprendre les forces et les faiblesses de ce genre d’analyse, Hollnagel (2012). Les diverses méthodes par lesquelles on peut réaliser une analyse de tâche pourront ensuite être étudiées selon les besoins et les intérêts de chacun.
Analyse ergonomique de tâche
Au sens qui nous concerne, une tâche est un travail qu’une personne (ou une équipe) doit accomplir pour atteindre un objectif connu, en général, dans un temps prédéterminé et des conditions prédéfinies. Conséquemment, une bonne analyse de tâche se doit de prendre en considération non seulement les objectifs de la tâche, mais aussi le contexte dans lequel elle doit être accomplie.
Il existe plusieurs justifications pour entreprendre une analyse de tâche, mais toutes ont en commun le besoin de mieux comprendre la tâche. Il se peut, par exemple, que l’on veuille concevoir une interface humain-machine, améliorer les façons de faire actuelles, évaluer l’impact d’un nouvel équipement, créer une formation appropriée, connaître les risques dont il faut se prémunir, connaître les exigences d’une tâche dans le but de sélectionner le personnel, automatiser une tâche, connaître les besoins de main-d’œuvre ou évaluer les coûts de réalisation d’une tâche.
Le terme « analyse de tâche » a une signification quelque peu différente selon les articles qu’on lit à ce sujet. Selon Hollnagel (2012) qui s’appuie sur les résultats d’un sondage fait par Kirwan
et Ainsworth au début des années ‘90, les diverses définitions peuvent être rangées dans l’une des cinq catégories suivantes :
La description et l’analyse d’observations concernant, soit la manière par laquelle une tâche est réalisée, soit les agissements survenus lors d’événements anormaux (incidents, accidents, etc.).
L’analyse et la description de tâches ou de situations de travail encore inexistantes ou basées sur d’hypothétiques événements.
La représentation des situations décrites plus haut en matière de notations utilisées pour recueillir les informations d’intérêt.
Toutes manières d’analyser et de tirer le maximum des informations recueillies à propos des situations susmentionnées.
Les modes de représentation des résultats et les différentes façons de documenter ce qui est sorti de la description et de l’analyse.
Parce qu’il y a plusieurs raisons pour réaliser une analyse de tâche, différentes méthodes pour le faire ont été développées au fil des ans, chacune avec ses caractéristiques propres et répondant donc à certains besoins mieux que d’autres. Par exemple, certaines méthodes mettent l’accent sur la décomposition hiérarchique d’une tâche complexe en buts, sous-buts, sous-sous-buts, etc. D’autres visent à établir une procédure pour mettre en évidence un mode d’opération permettant à une personne d’accomplir la tâche. D’autres encore sont préoccupées d’abord et avant tout par le temps nécessaire pour accomplir les différentes étapes permettant d’accomplir la tâche.
Face à un nouveau projet d’analyse de tâche, les analystes doivent donc décider de la ou des méthodes à utiliser en fonction de nombreux critères, dont le but de l’étude et l’aspect à étudier en priorité comme, par exemple, la structure de la tâche, les décisions à prendre ou le temps de complétion. Il leur faut aussi considérer d’autres facteurs, tels les outils disponibles et les méthodes qu’ils supportent, la familiarité des gens impliqués dans le projet avec une méthode ou un type de représentation en particulier, la facilité à communiquer les résultats aux personnes impliquées et d’autres encore.
Le point important ici est qu’aucune méthode n’est une panacée pour l’analyse de tâche. Les analystes doivent donc choisir parmi bon nombre de méthodes celle ou celles qu’ils utiliseront pour arriver à leurs fins.
Autre point, au moment de colliger les données et informations qui serviront de base pour une analyse de tâche, il faut porter une attention toute particulière aux sources. Ceci parce qu’il arrive
souvent que la manière de réaliser une tâche pour l’opérateur intervenant sur le terrain dans un contexte réel diffère de la manière prévue et prescrite. C’est la différence entre une tâche
prescrite et une tâche effective. La première correspond à ce qui est demandé par leurs supérieurs
à ceux qui doivent réaliser une tâche (en termes de buts et de résultats à atteindre et souvent aussi d’organisation, de méthodes et d’outils de travail à utiliser, de procédures à suivre, etc.), alors que la deuxième fait référence à ce que font réellement les opérateurs pour réaliser cette tâche, ce qui peut être assez éloigné de la tâche prescrite. D’une certaine manière, on peut voir la tâche effective comme le résultat d’une fonction tenant compte, entre autres, des buts et exigences de la tâche à accomplir, des compétences, aptitudes, expériences et état physiologique de l’opérateur, des caractéristiques du contexte de travail et des moyens disponibles.
Cela dit, une analyse de tâche peut aussi bien porter sur l’une ou l’autre de ces tâches. Il suffit de choisir ses sources d’information en fonction de la tâche d’intérêt et de faire attention à ne pas croiser des informations à propos de la tâche prescrite avec d’autres concernant plutôt la tâche effective.
Indépendamment de la méthode retenue pour effectuer une analyse de tâche, il s’avère qu’avec l’ampleur de la tâche à analyser, la représentation des résultats devient vite difficile à comprendre et surtout à gérer… Et, sans surprise, les tâches qui valent la peine d’être analysées comportent le plus souvent un grand nombre d’opérations et présentent donc une certaine complexité, soit dans l’exécution de certaines étapes en particulier, soit dans les interrelations entre celles-ci. En réponse à cette situation, quelques outils logiciels ont été créés pour alléger tout au moins les problèmes liés à la création et surtout à la modification de la représentation desdits résultats puisqu’elle peut amener des modifications en cascade (sur la numérotation des tâches, par exemple).
De ces outils logiciels, la plupart ont été créés pour assister les analystes dans la représentation de leurs résultats d’analyse de tâche selon les préceptes de l’une ou l’autre des principales méthodes connues. Par exemple, TaskArchitect© 1 assiste ses utilisateurs dans l’élaboration d’analyse
1 Un logiciel de Task Architect, Inc, qui en détient la marque de commerce. Cette compagnie a annoncé sa fermeture
en juillet 2013. En conséquence, TaskArchitect n’est plus vendu et la compagnie a offert de vendre le logiciel à une entité qui voudrait en reprendre le développement.
de tâche selon la méthode nommée « analyse de tâche hiérarchique », alors que KMADe© 2, lui,
utilise plutôt la méthode nommée « méthode analytique de description de tâche ».
De tous les outils logiciels trouvés, seul Dolphin3 semble tenir compte de plus d’une méthode
d’analyse, ce que le logiciel @Esperanto, conçu et présenté dans ce mémoire, se propose de faire. Par contre, aucune trace d’utilisation n’a pu être localisée. Il se pourrait donc que la seule mention de ce logiciel apparaisse dans Limbourg et al. (2001), un article dont le point principal concerne la création d’une topologie qui doit permettre d’exprimer un maximum des concepts d’une méthode dans une autre des méthodes que supporte Dolphin.
Malgré la possibilité d’utiliser un logiciel de dessin généraliste comme Visio© 4 pour créer une
représentation des résultats d’analyse de tâche, ce genre de logiciels n’est en aucune manière concurrent d’@Esperanto ou de n’importe lequel des logiciels que l’on vient de mentionner, puisque les généralistes n’ont aucune connaissance de l’analyse de tâche et ne peuvent donc pas prétendre supporter une quelconque méthode d’analyse de tâche.
But d’@Esperanto : Supporter l’analyse de tâche utilisant plusieurs méthodes
Il arrive souvent qu’un analyste veuille utiliser une méthode pour la majeure partie de son analyse de tâche et d’une ou de plusieurs autres pour des parties spécifiques. Par exemple, il peut être approprié d’approcher une tâche complexe en utilisant une méthode qui nous amènera à en faire une décomposition hiérarchique tout en pouvant utiliser une deuxième méthode qui permettra l’étude détaillée du temps requis pour chacune des procédures élémentaires qu’elle nécessite. C’est précisément là le but du logiciel @Esperanto.
@Esperanto5 est donc un logiciel d’analyse ergonomique de tâche qui offre la possibilité d’utiliser plusieurs méthodes même dans le cadre d’une seule analyse. Il est destiné à des ergonomes, des ingénieurs, des informaticiens, des responsables de formation, des professeurs,
2 Un logiciel en licence libre (GNU LGPL) dont la marque de commerce est détenue par Free Software Foundation.
3 Un logiciel développé pour fins de recherche par Limbourg, Pribeanu et Vanderdonckt (2001).
4 Un logiciel de Microsoft, Inc, qui en détient la marque de commerce.
des étudiants ou tout autre professionnel devant effectuer une analyse de tâche et désirant bénéficier d’une assistance logicielle dans l’élaboration de son analyse.
@Esperanto offre la possibilité de changer de méthode pour les portions choisies par l’utilisateur, permettant ainsi de convertir (traduire d’une certaine manière) une analyse de tâche réalisée avec une méthode en son équivalent d’une autre méthode, ceci dans le but de permettre aux utilisateurs de changer de méthode en cours de route sans pour autant perdre tout ce qui aurait été fait selon la première méthode.
@Esperanto doit aussi aider à définir la terminologie qui devrait être employée tout au long d’une analyse de tâche par l’utilisation de réseaux de concepts (donc, non dirigés) et assister l’utilisateur dans la création d’une vue d’ensemble du domaine d’application par l’utilisation de réseaux dirigés. Finalement, dans la mesure où les intrants de l’analyse (résultats d’interview, notes d’observations, prises de mesure, etc.) lui sont connus, il doit permettre une certaine traçabilité du contenu de l’analyse de tâche.6
Méthodes supportées
Les méthodes d’analyse supportées par @Esperanto ont été choisies avec l’objectif d’offrir un bon éventail de possibilités aux analystes afin de leur permettre de s’attaquer à divers problèmes d’analyse, de diverses manières selon les besoins de chaque projet et les préférences de chacun. Spécifiquement, ces méthodes sont les suivantes :
AHT Analyse hiérarchique de tâche
MAD Méthode analytique de description de tâche
OTHI Ordinogramme de traitement humain de l’information
(Une forme d’analyse procédurale utilisant les ordinogrammes.)
AT Analyse temporelle
KLM-GOMSa Keystroke-Level Model GOMS CMN-GOMSa Card-Moran-Newell GOMS
a Une variante de la méthode GOMS (Goals, Operators, Methods, and Selection rules).
6 Évidemment, le degré auquel @Esperanto peut permettre la traçabilité dépend de ce qui est porté à sa connaissance.
Parmi ces méthodes, certaines mettent l’accent sur la décomposition hiérarchique de la tâche pour la comprendre de manière à pouvoir l’améliorer (changement des façons de faire, automatisation, etc.), la standardiser (homogénéisation d’un site à l’autre, formation, etc.) ou pour toutes autres raisons. D’autres s’attardent plutôt à la séquence d’opérations et de décisions impliquées dans la réalisation de la tâche pour, par exemple, l’étudier finement de manière à optimiser un processus ou à l’encoder pour permettre son exécution par des techniciens adéquatement formés, mais ne possédant pas une connaissance scientifique ou d’ensemble du domaine d’application. D’autres encore permettent d’étudier ou de prévoir le temps nécessaire pour achever une tâche.
Un point commun aux méthodes d’analyse retenues pour @Esperanto est que ce sont toutes des méthodes d’analyse de tâche individuelle. Bien que certaines puissent être adaptées pour analyser des tâches réalisées par une équipe plutôt que par un individu, ce n’est pas leur force.
Ces méthodes sont présentées au chapitre suivant.
Réseaux
Avant de commencer la ou les analyses de tâche nécessaires dans un domaine d’application encore inconnu d’eux, les analystes doivent établir une taxonomie (ou une simple terminologie) de ce domaine pour communiquer au mieux avec les experts de celui-ci. En effet, non seulement les analystes doivent-ils connaître le vocabulaire et les concepts manipulés par les diverses parties prenantes du domaine, ils doivent aussi produire leurs résultats sous forme aisément compréhensible par eux, ce qui implique d’utiliser leur terminologie.
En plus de la taxonomie (ou terminologie), il est nécessaire que les analystes aient une vue d’ensemble des tâches qui pourraient leur être mentionnées dans le cadre de leur étude. Bien sûr, il ne s’agit pas nécessairement de décrire l’ensemble des tâches reliées au domaine d’application, mais tout au moins celles dont les analystes vont entendre parler lors de leur collecte de données. Encore une fois, le but ici est de faciliter la communication entre les analystes et les experts. Pour combler ces deux besoins, @Esperanto supporte l’utilisation de réseaux qu’ils soient dirigés ou non.
La structure du mémoire
Trois chapitres constituent le corps de ce mémoire. Au chapitre 1, les différentes méthodes d’analyse supportées par @Esperanto sont présentées comme elles sont généralement connues
par les analystes ergonomiques de tâche. On y présente aussi les réseaux (bien élémentaires) qui sont supportés par @Esperanto.
Au chapitre 2, pour certaines des méthodes supportées, on décrit les modifications apportées pour étendre leur expressivité et on explique les implications de celles-ci sur les possibilités d’analyse. Au chapitre 3, différentes interfaces utilisateurs sont proposées pour créer et modifier des analyses de tâche selon chaque méthode supportée. C’est à la fin de ce chapitre que l’on aborde vraiment l’aspect multiméthode d’@Esperanto.
CHAPITRE 1
PRÉSENTATION DES MÉTHODES D’ANALYSE DE
TÂCHE
Ce chapitre présente les méthodes d’analyse ergonomique de tâche individuelle qui seront prises en charge par @Esperanto, soit celles identifiées dans l’introduction. Mentionnons que, bien qu’il existe des méthodes comme GroupWare Task Analysis et ConcurTask Trees7, qui permettent
nativement d’analyser des tâches devant être réalisée par plusieurs équipiers, celles-ci ne seront pas considérées dans la première version d’@Esperanto.
On ne cherche ici qu’à présenter les grandes lignes de chacune des méthodes à supporter. Chacune d’elles est donc sommairement décrite dans son état habituel d’utilisation (possibilités, limitations, notations, etc.) dans le but de rappeler ce qu’est chaque méthode et, dans certains cas, de mettre en évidence les caractéristiques importantes pour la suite de ce document.
1.1 Quelques points communs
Avant de décrire les particularités de chacune des méthodes d’analyse de tâche qui nous intéressent, on s’attardera d’abord sur leurs points communs. En effet, étant toutes des méthodes d’analyse de tâche, elles partagent plusieurs choses.
Premièrement, avant de commencer une analyse de tâche, il faut savoir pourquoi elle doit être réalisée, puisque ce n’est qu’en se basant sur les buts que l’analyste pourra adéquatement choisir les aspects de la tâche auxquels il doit porter une attention particulière et, comme on le verra plus loin, limiter la granularité de l’étude sans affecter la pertinence des résultats. Il est donc impératif de connaître les buts à atteindre avant de commencer une analyse de tâche. En fait, de ceux-ci dépendra en partie aussi le choix même de la méthode d’analyse à employer.
Deuxièmement, quelle que soit la méthode retenue, il est essentiel d’assurer la validité des informations relatives à la tâche étudiée. Cette responsabilité incombe aux analystes, puisque les différentes méthodes ne servent qu’à agencer les informations relatives aux tâches d’une manière
qui rendra possible la meilleure analyse.8 L’adage anglais « garbage in; garbage out! »9 résume
très bien la raison pour laquelle tous doivent se préoccuper de la véracité des informations colligées dont sont nourris les outils mis à leur disposition. Pour maximiser la probabilité de bien réussir, les analystes se doivent d’en apprendre assez à propos de la tâche à analyser et de son domaine d’application pour être capables, non seulement de bien communiquer avec les gens du domaine, mais aussi de détecter des erreurs ou contradictions parmi les intrants qu’ils recueillent.10
En corollaire de ce qui précède, on notera qu’il est tout aussi facile d’agencer des informations relatives à une tâche prescrite qu’à une tâche réelle. La seule différence ici est encore une fois sous l’entier contrôle des utilisateurs d’@Esperanto.11 C’est donc à eux d’adapter leur recueil de
données pour obtenir des informations véridiques et concernant exactement ce qu’ils veulent étudier.
Troisièmement, par définition, il est impossible de prévoir l’imprévisible. Bien sûr, il est possible de tenir compte d’autant de circonstances inhabituelles que désiré (erreurs humaines, cas d’exception, incidents, accidents, situations d’urgence ou autres), mais au prix d’une lourdeur disproportionnée dans la représentation résultante. Pour cette raison, la plupart des analyses de tâche ne tiennent pas compte des erreurs humaines. Dans certains cas, GOMS par exemple, on avoue même ne s’intéresser qu’aux tâches réalisées sans erreurs et de manière experte (donc sans hésitation quant à l’enchaînement des étapes devant être réalisées). Cela dit, il est faisable d’obtenir des informations qui permettraient de tenir compte du niveau d’expertise de l’opérateur, mais l’effort de validation qui serait alors requis rendrait l’entreprise par trop longue et
8 Ici, la définition de « meilleure » est bien sûr dépendante des buts de l’analyse et donc du choix de la méthode
d’analyse en fonction de son adéquation avec ceux-ci.
9 En français, ce serait « [des] ordures en entrée [entraînent la production d’] ordures en sortie! ».
10 Il est bien clair que les analystes n’auront aucune autorité pour affirmer que ce qu’ils ont détecté est une erreur ou
une contradiction. Il leur faudra faire confirmer (et corriger) ce genre de choses par un expert.
11 On suppose que les utilisateurs d’@Esperanto seront des ergonomes devant réaliser une analyse de tâche, mais le
coûteuse.12 Dans les domaines où la sécurité est importante, il est courant d’analyser un grand
nombre de scénarios possibles impliquant diverses conditions exceptionnelles (erreurs, incidents ou accidents) en vue de former adéquatement les opérateurs et de leur offrir des moyens de travail performants.
En conséquence des points précédents, on s’aperçoit que lors de situations inhabituelles, si on n’a rien prévu au moment de la conception du système ou de la formation des opérateurs, le résultat d’une analyse de tâche peut être en grande partie inutile pour rétablir la situation. Cela parce que les méthodes d’analyse de tâche ne s’attardent qu’à décrire les buts à atteindre et les actions à prendre pour réussir l’entreprise. Il n’est nulle part fait explicitement mention de l’état du système dans lequel les opérateurs doivent évoluer, ce qui est nécessaire à la détection et à la correction d’une situation imprévue. Au prix de complexifier l’analyse de tâche résultante, il est toutefois possible de pallier à cet inconvénient en ajoutant des informations supplémentaires utiles au diagnostic d’anomalie. Ce prix semble souvent prohibitif au vu de la complexité additionnelle de l’analyse de tâche.
Quatrièmement, toutes les méthodes d’analyse procèdent en décomposant la tâche en unités (tâches ou activités) plus petits. Certaines d’entre elles, dont le but est de bien comprendre la structure de réalisation d’une tâche, utilisent une décomposition hiérarchique de la tâche analysée, ce qui correspond à une manière toute naturelle pour les humains d’aborder un problème complexe. Les autres méthodes, dont le but est surtout d’étudier le temps ou l’ordre d’exécution des activités élémentaires, utilisent plutôt une décomposition linéaire (ou procédurale) de la tâche principale.
On notera ici que les méthodes utilisant une décomposition hiérarchique tiennent aussi compte des buts d’une tâche à analyser. Ainsi, comme on le verra dans la description de l’analyse hiérarchique de tâche, on parlera de buts et de sous-buts, en plus des tâches et des activités. Finalement, dans tous les cas, il est nécessaire de savoir quand arrêter l’analyse d’une tâche. Le but ici est de ne poursuivre l’analyse que si c’est rentable et productif. Il existe donc différents
critères dits d’arrêt pour décider lors de l’analyse d’une tâche de l’adéquation du niveau de détail courant par rapport aux buts à atteindre. On a donc les critères d’arrêt suivants :
Niveau de détail satisfaisant : toutes les parties prenantes s’entendent pour affirmer qu’une tâche ou une activité a été décomposée à un niveau assez fin pour justifier de ne pas poursuivre son analyse.
Inadéquation avec les buts : rien ne peut justifier la poursuite de l’analyse d’une tâche ou d’une activité qui n’a aucun impact sur l’atteinte des buts de celle-ci.
Faible probabilité ou impact des erreurs qui pourraient être commises si on ne poursuivait pas l’analyse plus avant : si le risque encouru en n’analysant pas une tâche ou une activité est soit très faible, soit sans conséquence notable, il est inutile de la poursuivre. Ce critère est souvent associé à l’analyse hiérarchique de tâche, qui l’a fait connaître sous la forme de l’équation p C (où p est la probabilité estimée de ces possibles erreurs si l’analyse
d’une tâche Ti n’est pas faite et où C est leur coût estimé)13. Ce critère, plein de gros bon
sens, doit véritablement s’appliquer à toutes les méthodes.
1.2 Réseaux
Dans le cadre d’une analyse de tâche, les réseaux servent surtout lors des premières étapes sous-entendues à la section précédente parce qu’ils permettent de montrer les relations entre les divers éléments d’un domaine d’application ou d’un système technique ou collaboratif.
En particulier, les réseaux sont utilisés pour mettre en relation :
Les termes et les concepts d’un domaine d’application. Dans ce cas, ils servent donc à établir la taxonomie du domaine d’application.
La place de chaque tâche dans la chorégraphie générale prescrite ou réelle survenant dans le milieu de l’étude.
Les responsabilités de chaque personne impliquée dans la chorégraphie susmentionnée. Pour faciliter la compréhension des réseaux produits, @Esperanto permet aux utilisateurs de définir plusieurs types d’arcs en fonction de leur signification. Par exemple, dans un réseau du personnel d’une usine, on pourrait avoir des liens d’autorité hiérarchique (figurés par des flèches en traits pleins) et des liens d’obligations ou dépendances fonctionnelles (figurés par des flèches en pointillé). Il est possible d’aller encore plus loin en apposant une étiquette sur n’importe quel lien du réseau.
Puisque les réseaux ne sont pas essentiels à l’analyse de tâche et qu’ils ne feront pas faire partie de la première implémentation d’@Esperanto, ils ne seront pas mentionnés plus avant dans ce mémoire.
1.3 Analyse hiérarchique de tâche (AHT)
Depuis son introduction par Annett et Duncan (1967), l’AHT a été utilisée pour analyser des tâches dans virtuellement toutes les sphères de l’activité humaine; une belle preuve de son utilité et de sa relative simplicité d’utilisation.
Par la date de son introduction, bien antérieure à la spectaculaire pénétration de l’informatique personnelle, on comprend aussi que l’AHT est une méthode ne nécessitant pas l’utilisation d’un ordinateur. Peut-être aussi en bonne partie pour cette raison, son formalisme est plutôt désinvolte, d’où la relative simplicité d’utilisation qui en a facilité l’acceptation, mais aussi le manque de rigueur que certains lui reprochent.
Pour analyser une tâche selon cette méthode, il faut commencer par déterminer le but que doit atteindre la tâche à analyser et commencer une décomposition hiérarchique à partir de là. Lors de cette décomposition, il faudra redéfinir toutes tâches suffisamment complexes qu’il est besoin de l’expliquer. Pour chacune de ces dernières, la redéfinition consiste à indiquer la liste des sous-buts à atteindre ou des tâches à effectuer qui contribuent à sa réalisation, ainsi que les instructions nécessaires pour y arriver. Ce processus doit se poursuivre récursivement pour tous les sous-buts et tâches qui viennent d’être spécifiés. La décomposition hiérarchique doit se poursuivre ainsi jusqu’à ce que les conditions d’arrêt mentionnées plus haut permettent d’y mettre fin.
Parce qu’une AHT peut servir dans de multiples contextes, les propriétés à conserver concernant chaque tâche ne sont pas fixées dans la définition de la méthode. Il est plutôt laissé aux analystes de définir eux-mêmes les propriétés qui leurs seront nécessaires. Par exemple, pour une étude A, on pourrait vouloir connaître les habiletés et connaissances requises pour accomplir chaque tâche, alors que pour l’étude B on aura plutôt besoin de connaître les équipements requis, les codes du travail applicables et les documents légaux qu’il faudra produire pour chaque tâche. On verra plus loin comment ces propriétés sont représentées.
En AHT, les instructions que l’on vient de mentionner sont connues sous le nom de « plan ». Ce plan, requis pour tout nœud possédant des enfants (sous-buts ou tâches), montre comment il faut
utiliser lesdits enfants pour réaliser le but ou la tâche du nœud associé. Ces plans, dont le langage n’est qu’en partie formel14, permet bien de stipuler les instructions nécessaires, mais peut rendre
difficile l’utilisation d’outils de validation ou de simulation. La notation de ces plans varie d’un auteur à l’autre15, mais permet toujours de faire essentiellement les mêmes choses. Dans ce chapitre, les notations adoptées sont basées sur une suggestion de Stanton (2006) et sur les possibilités de TaskArchitect©.16 La première est expliquée au tableau 1-1, l’autre au tableau 1-2. À titre comparatif, notons que TaskArchitect© et le logiciel équivalent dans la suite Human Factors Workbench (HFW)17 utilisent tous deux la notation plus verbeuse (mais de premier abord plus claire) pour la création de leurs plans.
On constate donc que, dans l’élaboration de cette méthode, l’accent a été mis sur la facilité d’utilisation pour permettre d’effectuer l’analyse d’une tâche et d’obtenir un résultat utilisable par des humains et, ce, sans recours à un ordinateur. Que le lecteur n’interprète pas cela comme une critique de la méthode, mais comme une simple observation. Après tout, si cette méthode est devenue et est restée un incontournable en ergonomie, c’est qu’elle remplit très bien sa fonction. À titre d’exemple, voir la figure 1-1 où l’on notera que les tâches sont numérotées hiérarchiquement. En général, les analystes adoptent les conventions suivantes :
La racine porte le numéro « 0 ».
Les enfants de la racine portent un nombre entier (« 1 » pour le plus à gauche et successivement en allant vers la droite).
Les enfants de tous les autres nœuds portent un numéro qui résulte de la concaténation du numéro du parent, d’un point et d’un nombre entier (« 1 » pour le plus à gauche et
successivement en allant vers la droite).
14 Les différents logiciels supportant l’élaboration de modèles AHT proposent aux utilisateurs un langage un tant soit
peu formel pour la rédaction des plans. Au besoin et au prix d’un support moindre de la part du logiciel, les analystes peuvent toujours revenir à un langage tout à fait informel pour exprimer les conditions les plus élaborées… Précisions et détails peuvent toujours être au rendez-vous!
15 Les variations sont telles qu’une légende explicative est le plus souvent utilisée.
16 TaskArchitect© est le plus connu des logiciels d’assistance à l’analyse de tâche selon la méthode AHT.
17 HFW est la suite logicielle de Human Reliability contenant plusieurs outils d’analyse dans le domaine de
Tableau 1-1 Énoncés disponibles pour les plans d'une AHT.
Concept Notation Commentaires
Sous-tâches d’une tâche <entier à partir de 1> Les sous-tâches servant à redéfinir une
tâche sont numérotées séquentiellement à partir de « 1 » en commençant par celle de gauche.
Exécution séquentielle 1 > 2 > 3 > 4 Toutes les opérations doivent être
exécutées dans l’ordre indiqué.
Exécution non séquentielle 1 / 2 / 3 / 4 Toutes les opérations doivent être
exécutées sans égard à l’ordre indiqué.
Exécution libre 1 : 2 : 3 : 4 Un certain nombre d’opérations (mais au
moins une) doivent être exécutées, peu importe l’ordre.
Exécution d’un choix 1 | 2 | 3 | 4 Une seule des opérations mentionnées
doit être exécutée.
Exécution concurrente 1 + 2 + 3 + 4 Toutes les opérations doivent être
exécutées concurremment.
En AHT, toutefois, le mot
« concurremment » peut aussi bien
désigner des opérations à faire en même temps par plus d’une personne (en simultané) que des opérations à faire en temps partagé par une seule personne (en parallèle).
Interdiction ¬ <opération> Ne pas faire l’opération mentionnée.
Exécution conditionnelle si X alors 1 sinon 2 Selon que la condition « X » est réalisée
ou non, on choisit la sous-tâche 1 ou la sous-tâche 2.
Instructions textuelles « Facultatif », « Au
besoin », « Quand vide», etc.
Des instructions en langage naturel peuvent toujours être ajoutées pour spécifier au mieux les détails du plan. Regroupement d’instructions
pour ciblage précis.
( … ) Lorsque nécessaire, il est possible de
regrouper certaines instructions pour y appliquer des conditions particulières ou pour modifier localement la séquence d’exécution.
Tableau 1-2 Notation utilisée par TaskArchitect© pour les plans d'une AHT.
Concept Notation originale Notation traduite par l’auteur
Exécution séquentielle Do in sequence <tasks> Faire en séquence <tâches>
Exécution non séquentielle Do in any order <tasks> Faire sans égard à l’ordre <tâches>
Exécution libre Do any of <tasks> Faire l’une de <tâches>
Exécution d’un choix Do only one of <tasks> Faire une seule de <tâches>
Exécution concurrente Do concurrently <tasks> Faire en même temps <tâches>
Interdiction Do not do <tasks> Ne pas faire <tâches>
Exécution conditionnelle If <condition> do <tasks> Si <condition> faire <tâches>
0 Envoyer courriel 1 Choisir le bon compte 2 Toucher «Création» 3 Compléter en-tête 5 Ajouter pièce jointe 4 Composer corps 7 Toucher «Envoyer» 6 Réviser message 3.1 Entrer destinataire 3.2 Entrer objet 3.1.1 Utiliser liste des contacts 3.1.2 Entrer adresse 5.1 Toucher «Ajout p.j.» 5.2 Choisir type de pièce jointe 5.3 Localiser pièce jointe 5.4 Sélectionner pièce jointe 5.5 Toucher «OK» Plan 3 : 1 / 2
Plan 3.1 : si destinataire dans «contacts» alors 1 sinon 2
Plan 5 : 1 > 2 > 3 > 4 > 5 Plan 0 : 1 si besoin est > 2 > (3 / 4 / 5 si requis) > 6 > 7
Figure 1-1 AHT partielle pour la tâche consistant à envoyer un courriel.
Le plan associé à un nœud est placé entre celui-ci et ses enfants. Un plan complexe pouvant apparaître au complet (quitte à augmenter l’espacement vertical entre celui-ci et ses enfants) ou être défini plus loin, ce qui doit alors être indiqué par une note là où attendrait ledit plan. On notera aussi que, dans chaque plan, les enfants sont référencés par leur numéro le plus à droite et non en listant tout le numéro hiérarchique (p. ex. : « 2 » au lieu de « 3.1.2 »).
Comme tout arbre, une AHT peut être représentée sous la forme d’un tableau. C’est cette représentation qui est la principale réponse à la question laissée en suspens plus tôt, soit celle concernant les propriétés associées à chaque tâche qui sont spécifiques à chaque analyse de tâche.
Dans l’exemple de la figure 1-2 (qui reprend l’exemple de la figure 1-1), on notera que, par l’ajout de colonnes supplémentaires audit tableau, il est facile de montrer autant de propriétés que souhaité.
Tâches Type d'entrée Commentaire
0 Envoyer courriel
Plan 0 : 1 si besoin est > 2 > (3 / 4 / 5 si requis) > 6 > 7
1 Choisir le bon compte Sélection Il faudrait mémoriser ce compte
pour la prochaine fois.
2 Toucher «Création» Clic (bouton)
3 Compléter en-tête
Plan 3 : 1 / 2
3.1 Entrer destinataire
Plan 3.1 : si destinataire dans «contacts» alors 1 sinon 2
3.1.1 Utiliser liste des contacts Clic (élément)
3.1.2 Entrer adresse Texte Offrir d'ajouter une nouvelle
adresse aux contacts.
3.2 Entrer objet Texte
4 Composer corps Texte
5 Ajouter pièce jointe Att : Utilisation occasionnelle!
Plan 5 : 1 > 2 > 3 > 4 > 5
5.1 Toucher «Ajout p.j.» Clic (bouton)
5.2 Choisir type de pièce jointe Clic (élément)
5.3 Localiser pièce jointe Navigation Fichier local seulement?
5.4 Sélectionner pièce jointe Clic (élément)
5.5 Toucher «OK» Clic (bouton)
6 Réviser message
7 Toucher «Envoyer» Clic (bouton)
Figure 1-2 AHT de la figure 1 1 en représentation textuelle.
En terminant, notons qu’aucune terminologie pour les plans n’est universellement acceptée, de sorte que la plupart des analyses AHT ont une légende expliquant celle utilisée. Au mieux, observe-t-on une cohérence intra analyste dans l’utilisation de la méthode, mais il existe clairement de nettes différences inter analystes. On remarque aussi que les différents fabricants de logiciels assistant à la création d’AHT proposent l’utilisation d’une notation plutôt formelle
qui se doit cependant de garder des éléments en langage naturel pour permettre la description de toutes les conditions possibles.
1.4 Analyse procédurale / Ordinogramme de traitement humain de
l’information (OTHI)
Cette méthode est une forme particulière d’analyse procédurale qui utilise l’ordinogramme (dans sa représentation graphique empruntée au monde de l’informatique) comme outil de représentation principal.
Cela dit, la raison d’être de cette méthode n’est pas seulement d’exposer la décomposition d’une tâche en sous-tâches, mais aussi et surtout de montrer comment atteindre un but par l’exécution ordonnée de certaines tâches, surtout lorsqu’il faut choisir parmi plusieurs chemins d’exécution en fonction de facteurs divers.
L’ordinogramme de l’OTHI sert à décrire graphiquement des tâches par leur enchaînement de processus et de décisions. À la base, les quelques symboles apparaissant à la figure 1-3 suffisent pour représenter un grand nombre de tâches.
Outre ces symboles de base, l’ANSI (American National Standard Institute) et différents fabricants de logiciels d’aide à la création d’organigrammes18 en ont défini plusieurs autres pour
éviter de surutiliser le rectangle qui, dans la version de base, sert à toutes les sauces. C’est ainsi que les symboles montrés à la figure 1-4 peuvent être utilisés en lieu et place de rectangles pour communiquer graphiquement un aspect sémantique important d'une tâche.
La figure 1-5 montre une version OTHI de l’exemple d’analyse AHT montrée à la figure 1-1. Comme on le constatera, cet OTHI utilise certains de ces derniers symboles.
Le plus souvent, ce construit a deux sorties identifiées l’une par oui et l’autre par non, mais, en fait, les réponses peuvent être n’importe quoi et en n'importe quel nombre!
Référence sur la même page Référence sur une autre page
Liens placés entre les différents symboles pour indiquer le prochain à considérer dans le chemin d'exécution.
Par convention, on omet la pointe de tout lien allant vers la droite ou vers le bas.
Début ou fin de l’ordinogramme Tâche générique
Question
(ses liens de sortie étant étiquettés par les réponses)
Figure 1-3 Symboles de base d'un ordinogramme.
La tâche résulte en la création ou la modification d'un document. La tâche implique un délai (file d'attente, traitement par lots, etc.). Entreposage et entreposage électronique, respectivement. Activité nécessitant l'interaction d'un humain et d'un ordinateur. Activité d'inspection du résultat d'une opération précédente.
Activité complètement automatisée (aucune intervention humaine).
Tâche complexe définie ailleurs sous la forme d'un sous-ordinogramme.
Entrées ou sorties de données.
Étape prépatoire. Transfert de matériaux d'un endroit à un autre. Tâche purement manuelle.
Début Toucher «Création» Toucher «Envoyer» Le compte courant est-il
le bon?
N
O
Utiliser liste des contacts Destinataire dans
liste des contacts?
O N Faut-il une pièce jointe? O N Toucher «Ajout p.j.» Choisir type de pièce jointe Localiser pièce jointe Sélectionner pièce jointe Toucher «OK» Fin Entrer adresse Entrer objet Composer corps Choisir le bon compte Réviser message
Figure 1-5 OTHI correspondant approximativement à l'AHT partielle pour la tâche consistant à envoyer un courriel.
En regardant la figure 1-5, on pourrait ne pas réaliser que les conditions pour effectuer les tâches dites conditionnelles en AHT sont devenues plus précises en OTHI. Ce résultat est en partie dû à l’attention portée au processus à accomplir et aux décisions qu’il faut prendre.
Bien que la représentation graphique de l’OTHI soit la préférée de la méthode, comme toutes les méthodes d’analyse procédurale, elle peut être montrée sous forme textuelle. Un exemple assez rudimentaire de cette représentation est présenté à la figure 1-6, où les énoncés sont énumérés du haut vers le bas en commençant par l’énoncé qui doit être exécuté en premier. Dans cette version rudimentaire, les énoncés sont simplement numérotés (pour permettre de modifier le flot
d’exécution à un énoncé autre que le suivant) et sont indentés en fonction de leur dépendance à un autre énoncé.
# Énoncés et tâches Type d'entrée Commentaire
1 SI le compte n'est pas le bon ALORS
2 Choisir le bon compte Sélection Il faudrait mémoriser ce
compte pour la prochaine fois.
3 Toucher « Création » Clic (bouton)
4 SI destinataire dans liste des contacts ALORS
5 Utiliser la liste des contacts Clic (élément)
6 SINON
7 Entrer l'adresse courriel Texte Offrir d'ajouter une
nouvelle adresse aux contacts.
8 Entrer l'objet Texte
9 Composer le corps Texte
10 SI il doit y avoir une pièce jointe ALORS Att : Utilisation
occasionnelle!
11 Toucher « Ajout p.j. » Clic (bouton)
12 Choisir le type de pièce jointe Clic (élément)
13 Localiser la pièce jointe Navigation Fichier local seulement?
14 Sélectionner la pièce jointe Clic (élément)
15 Toucher « OK » Clic (bouton)
16 Réviser le message
17 Toucher « Envoyer » Clic (bouton)
Figure 1-6 Représentation textuelle de l’OTHI précédent.
Lorsque la longueur et la complexité de l’OTHI augmentent, sa représentation textuelle peut devenir difficile à suivre. Pour atténuer ce problème, divers éléments graphiques peuvent être ajoutés au texte. C’est ainsi que l’on peut ajouter des lignes verticales pour mettre en évidence le niveau d’indentation courant même dans un OTHI s’étirant sur plusieurs pages, que l’on peut faire ressortir certains énoncés clés (les SI … ALORS, SINON, TANTQUE et autres) et que l’on peut utiliser un fil d’Ariane (en en-tête de page) pour donner le contexte du premier énoncé de chaque page. Cette représentation, servant de point de départ pour un type de séquence d’instructions très précises connu sous le nom de « procédure », est plus compacte que sa
