Comme nous l'avons défini au chapitre 1, une méthode permet de rendre opérationnel un modèle ou en d'autres termes constitue un mode d'emploi particulier d'un modèle. En ce sens, elle restreint les possibilités du modèle et de fait, quand on a très bien intégré un modèle, on n'a plus besoin de suivre une méthode particulière et on s'adapte mieux ainsi aux particularités de l'environnement.
Par contre, il est beaucoup plus simple d'apprendre à manier un nouveau modèle par le biais d'une méthode qui sert de guide tout au long de la démarche.
On peut dire qu'une méthode est une sorte de procédure prévue qui indique:
- comment s'articulent les différents éléments du modèle (séquentialité, parallélisme),
- quels sont ceux qui sont observables et comment,
- quels sont ceux qui sont déductibles et à partir de quoi (observations, connaissances générales).
On peut ainsi à la limite appliquer une méthode sans maîtriser pleinement le modèle sous-jacent. A cet effet, ce chapitre constitue un tout en soi qui peut être utilisé quasiment indépendamment des autres chapitres. Mais, si on veut savoir sur quels éléments de psychologie cognitive et d'ergonomie se base cette méthode, il faut lire la première partie des chapitres 2 et 3.
Pour les définitions de concepts, on se reportera au glossaire (les concepts définis dans le glossaire et utilisés pour la première fois dans ce chapitre sont marqués d'une astérisque "*").
Le chapitre comporte deux parties:
- dans les trois premiers paragraphes, nous présentons une démarche informatique classique où l'informaticien est responsable de l'ensemble du processus de l'analyse jusqu'à la conception de l'application. Nous présentons d'abord l'étude de l'existant, puis la conception de l'application automatisée et en dernier lieu les tests sur le prototype ainsi défini;
- dans le dernier paragraphe, nous traitons une étude de cas complète qui va de l'étude de l'existant à la définition de la Représentation Externe.
La méthode DIANE que nous exposons ci-dessous concerne exclusivement l'analyse et la conception des applications interactives ; mais la plupart du temps, il est nécessaire de faire une étude globale du système d'information avant de se préoccuper des applications interactives, il nous a paru donc important de montrer comment la méthode DIANE pouvait se greffer sur une méthode d'analyse générale. Dans la suite de cet exposé, nous montrons comment intégrer la méthode DIANE à partir de la méthode MERISE.
Nous rappelons dans le premier paragraphe les divers modes de recueil de l'information d'un système existant afin de pouvoir s'y réfèrer dans le deuxième paragraphe quand nous décrivons le système existant, l'objectif étant de montrer quels sont les modes de recueil les plus adaptés pour décrire les différents paramètres du système.
Nous présentons succintement l'ensemble des techniques utilisables pour décrire le travail existant; dans les trois premières (entretien, réunion, questionnaire), l'utilisateur joue un rôle actif d'explicitation verbale de son travail alors que dans les trois dernières (autorelevé, observation, capteur), il exécute son travail sans l'analyser.
C'est certainement la technique la plus utilisée par les informaticiens ; elle présente l'avantage d'être une très bonne source d'informations qualitatives.
L'entretien peut être structuré ou non; s'il n'est pas structuré, il permet d'obtenir des informations à caractère général, de percevoir le climat et les problèmes principaux qui se posent. Un entretien non structuré constitue souvent une étape obligatoire pour commencer une étude de l'existant dans une entreprise peu ou pas connue.
L'entretien structuré s'apparente à un questionnaire en ce sens qu'il demande une préparation préalable de questions à réponses limitées ou ouvertes; s'il est bien conçu, il facilite la synthèse des informations provenant des différents interlocuteurs.
Le choix des personnes à interroger est un problème essentiel, car il est rarement possible d'avoir des entretiens avec l'ensemble des personnes interessées par l'étude et un mauvais choix peut donner une vision fausse ou biaisée de l'existant.
L'inconvénient majeur de l'entretien est qu'il est coûteux en temps, à la fois pour l'analyste et pour les utilisateurs . Aussi peut-on le remplacer ou le compléter par des réunions ou des questionnaires.
La conduite de réunion suppose un minimum de formation et d'expérience pour être efficace ainsi qu'un choix judicieux du nombre et du type des participants. Car les interactions entre les participants peuvent être stérilisantes et empêcher de recueillir toutes les informations souhaitables.
Par contre, correctement mené elle peut permettre une adhésion du groupe à l'étude et l'émergence de nouvelles propositions.
Les questionnaires remplis par l'utilisateur peuvent compléter ou même remplacer des entretiens ou des réunions pour recueillir des informations précises, bien délimités et quantitatives.
L'inconvénient réside dans le fait qu'il peut être mal rempli si l'utilisateur interpréte de manière erronnée certaines questions.
Les entretiens, réunions et questionnaires font appel explicitement à l'utilisateur et donc à sa subjectivité pour décrire sa situation de travail; on obtient donc ainsi le réel perçu parl'utilisateur et exprimé pour l'analyste.
Cette situation peut avoir trois effets:
- certains comportements inconscients ne sont pas exprimés,
- si le réel est complexe, on recueille la description des cas "normaux" et non pas des cas effectifs,
- certains faits peuvent être volontairement omis.
Il consiste à faire remplir aux interessés un questionnaire détaillée décrivant leur travail au fur et à mesure qu'il se déroule; on recueille ainsi le travail effectif et non pas le travail décrit.
L'inconvénient majeur est que l'analyste peut se retrouver avec une masse d'information inexploitable qui ne lui permet pas de dégager une synthèse du travail ainsi décrit.
Cette technique très utilisée par les ergonomes l'est fort peu par les informaticiens.
Elle permet, comme l'autorelevé, de recueillir une information sur le travail effectif ; son avantage supplémentaire est de ne pas mobiliser l'utilisateur puisque c'est un observateur extérieur qui remplit les relevés.
Elle est par contre très coûteuse en temps d'analyste.
Dans le cas d'étude sur des logiciels existants, cette technique consiste à rajouter des éléments aux logiciels de manière à recueillir automatiquement les traces de travail de l'utilisateur. C'est une observation automatique qui de ce fait ne s'applique qu'à l'observation de certains paramètres, mais qui peut compléter d'autres techniques d'observation.
Les autorelevés, les obsevations et les capteurs permettent par des moyens différents de recueillir les traces de travail effectif.
La plupart du temps, on combine plusieurs de ces techniques pour avoir l'image la plus exacte du système existant; on peut, par exemple, procéder à des observations, puis avoir un entretien avec l'utilisateur observé pour obtenir des compléments d'informations sur les faits observés.
Quel que soit le soin que l'on prend à recueillir l'information sur le système existant, on n'obtient qu'une image partielle du système réel et l'essentiel est de savoir quelle partie du système réel on a décidé d'ignorer, jusqu'à quel niveau de détail on veut le décrire et quels sont les éléments du système réel que l'on juge négligeables.
L'objectif de cette étape est de montrer comment déterminer les logiques d'utilisation (*) associées aux différents postes de travail concernés par l'automatisation.
Cette logique d'utilisation se traduit ici par la détermination des buts (*) d'un poste de travail (*); puis, pour chaque but, la détermination des différentes procédures (*) permettant de l'atteindre.
Le découpage d'un système d'information se fait usuellement dans les méthodes d'analyse par la notion de domaine ou de fonction. L'objectif est de découper le système d'information en sous-systèmes le plus indépendants possibles (c'est-à-dire ayant le minimum de relations entre eux).
Dans la méthode MERISE, à l'intérieur d'un domaine ou d'une fonction du système d'information, le découpage, s'il y a lieu, se fait en processus au niveau conceptuel et en procédures au niveau organisationnel. Le processus ou la procédure est elle-même décomposée en un enchaînement d'événements et d'opérations.
L'opération est définie "comme un ensemble d'actions élémentaires non ininterruptible".
La notion d'opération non interruptible est une notion importante du découpage de MERISE qui ne pose aucun problème pour les opérations manuelles et automatiques, mais qui nous semble devoir être précisée dans le cas d'opérations interactives ; aussi définissons-nous une opération interactive comme "un ensemble de transactions qui peuvent être exécutées consécutivement et sans attente d'événements externes au système homme-ordinateur". Cette définition permet d'intégrer toutes les interruptions provoquées par l'utilisateur en cours d'opération que ce soit pour activer d'autres opérations ou pour différer son travail.
Rechercher les buts d'un poste de travail revient à chercher la logique d'utilisation des utilisateurs. Pour celà, nous pouvons procéder de deux manières :
- la première manière part du système d'information
- la seconde manière est issue de l'étude du système de décision.
Nous présentons en premier la méthode issue de l'étude du système d'information, car c'est celle qui est la plus usuelle pour les analystes. En effet les méthodes de conception des systèmes informatisés s'appuient sur le système d'information et même, souvent, uniquement sur le système d'information du système opérant.
Dans la méthode MERISE, la détermination des buts d'un poste de travail se situera immédiatement après la description du niveau organisationnel des traitements et des données du système existant. A la fin de cette phase, nous disposons, pour les traitements, d'un ensemble de procédures qui décrivent les enchaînements des opérations du nouveau système et pour chaque opération nous avons déterminé, sa nature (interactive, automatique, manuelle) et son lieu d'exécution (poste de travail, service). Pour les données, nous disposons de l'ensemble des vues externes du poste de travail. Par la suite, nous considérons simultanément les traitements et les données d'une opération.
Nous allons maintenant regrouper toutes les opérations interactives et automatiques exécutées sur un même type de poste de travail. Il faut remarquer que le même type de poste de travail peut participer à des procédures différentes mais aussi à des fonctions différentes.
(Ex : la gestion des stocks participe à la fonction achats et à la fonction ventes ; c'est le seul point d'intersection de ces fonctions).
Ces regroupements seront faits en respectant les règles d'enchaînement et les synchronisations (*) déterminées aux niveaux précédents (règles d'enchaînement du niveau conceptuel et du niveau organisationnel).
Exemple d'interaction entre fonctions, procédures et opérations d'un poste de travail:
Pour faire émerger les buts , nous remarquons qu'un but d'un poste de travail donné correspond à un sous-ensemble d'opérations de l'ensemble des opérations possibles de ce poste de travail.
Il est important de noter que l'ensemble des buts d'un poste de travail ne constitue pas forcément une partition de l'ensemble des opérations car une même opération peut appartenir à deux buts différents.
Pour déterminer si deux opérations appartiennent au même but (c'est-à-dire sont nécessaires à la réalisation du but), il faut demander à l'utilisateur s'il peut avoir besoin en même temps de ces opérations dans la réalisation d'une de ces tâches. L'objectif est qu'il ait "sous la main", à un moment donné, l'ensemble des opérations qu'il peut être amené à utiliser pour réaliser un but donné. Il faut penser en particulier aux opérations de consultation pour l'aide et aux opérations de modification et d'annulation pour la correction des erreurs.
Les informations nécessaires aux regroupements des opérations en buts peuvent être recueillies par entretien auprès des utilisateurs concernés (exécutants); en cas d'ambiguïté, les entretiens peuvent être complétés par des autorelevés ou des observations.
Cette démarche, qui part des opérations du système d'information pour faire émerger les buts, convient bien aux postes de faible responsabilité qui n'ont pas de fonction de pilotage vis-à-vis d'autres postes de travail et/ou qui n'ont pas de fonction de régulation importante.
Dans les autres cas, il est plus efficace et plus sûr d'utiliser la seconde démarche qui part de l'étude du système de décision.
Détermination des buts à partir du système de décision
Le système de décision est peu étudié en tant que tel dans les méthodes d'analyse informatique; la seule méthode opérationnelle qui l'étudie ainsi que ses interactions avec le système d'information est l'Analyse Modulaire des Systèmes de J. Melese (Mel,77). Cette méthode, que nous rappelons brièvement ci-dessous, peut être appliquée globalement ou localement; elle permet de dégager les objectifs d'un poste de travail et d'étudier la compatibilité des boucles de régulation par rapport à ces objectifs. Elle peut être un guide pour dégager les objectifs mais aussi pour définir les différents types de procédures, en particulier la procédure minimale.
L'Analyse Modulaire des systèmes
Le principal intérêt de l'A.M.S est de permettre l'analyse de l'interaction entre le système d'information et le système de décision de l'entreprise. Pour cela, elle propose une description ou toute activité de l'entreprise est modélisé sous la forme d'un couple module de pilotage-module technologique que nous représentons dans un formalisme simplifié sur le schéma suivant:
Le module de pilotage permet de décrire les mécanismes de décision qui transforment les informations d'entrée de ce module en informations de décision pour le module technologique afin de maintenir le fonctionnement du module technologique en direction des objectifs assignés. Les objectifs sont décrits selon trois types de variables qui sont l'activité, le coût, l'efficacité. Pour notre étude, ce sont les descriptions des objectifs en termes d'activité et d'efficacité qui sont à retenir.
Un autre concept intéressant pour notre étude est la distinction entre variables de réglage et variables de contrôle. Les variables de contrôle correspondent à une transmission de décisions prises à un niveau hiérarchique supérieur; le module de pilotage se contente d'adapter ces décisions au contexte du module technologique, mais il n'en est pas à l'origine et il ne peut les remettre en cause.
Les variables de réglage sont par contre de l'entière responsabilité du module de pilotage correspondant. Elles permettent de décrire les décisions qui sont générées à ce niveau en fonction des informations provenant du module technologique (entrées informatives internes) ou provenant d'autres modules ou de l'environnement (entrées opératives et informatives externes).
L'ensemble des variables de réglage et des entrées d'information constitue une boucle de régulation qui a pour but de maîtriser le fonctionnement du module technologique et d'absorber une partie des fluctuations de ce module.
Cette décomposition en deux modules s'applique aussi bien au niveau de l'entreprise globale qu'au niveau du poste de travail. Elle permet ainsi de dégager des chaînes de pilotage qui décrivent le système de décision de l'entreprise, c'est-à-dire la transmission des décisions, la répartition des responsabilités et les boucles de régulation.
Dans le cadre de notre étude, nous l'appliquons à l'ensemble des postes de travail concernés par le nouveau système afin de dégager à la fois les buts et la latitude décisionnelle de chaque poste de travail. La latitude décisionnelle permet de dégager plus aisément les procédures minimales.
Le reste du système d'information est décrit au niveau du module technologique par les règles opératoires permettant de transformer les informations d'entrée de ce module en informations de sortie.
Les objectifs ou buts étant ainsi déterminés par l'étude du système de décision et l'ensemble des opérations par l'étude du système d'information, il suffit de mettre les deux en correspondance en se demandant quelles sont les opérations qui contribuent à la réalisation d'un but.
Cette démarche est sans contexte plus sûre que la précédente, mais comme elle est plus lourde à mettre en oeuvre il est préférable de la réserver aux postes exerçant des responsabilités dans les organisations ou aux postes dont on n'arrive pas à faire émerger sans ambiguïté des buts par le simple regroupement des opérations.
Tableau de synthèse de la détermination des buts:
1.2.2 Les différentes procédures existantes
Les procédures, que nous définissons ici, utilisent un formalisme, présenté dans le chapitre 2, très voisin de celui utilisé dans MERISE pour décrire les processus ou procédures; mais elles se distinguent des procédures de MERISE par leur sémantique car elles décrivent l'enchaînement des opérations nécessaires à la réalisation d'un but d'un utilisateur et non pas un sous-domaine du système d'information.
La notion d'opération (*) est elle aussi modifiée pour pouvoir intégrer les interruptions à l'initiative de l'utilisateur.
Pour chaque but, nous déterminons en premier la procédure prévue (*) car c'est celle qui se dégage "naturellement" d'une étude de l'existant menée au moyen d'entretiens ou de questionnaires auprès des exécutants ou des responsables.
En effet, quand on interroge des utilisateurs, on obtient en premier lieu la description des cas les plus courants qui correspondent normalement à la procédure prévue. La description de la procédure prévue existante est indipensable pour la suite de l'étude.
Pour obtenir la description de procédures effectives (*) qui correspondent à des cas particuliers ou à des habitudes de travail différentes, il faut soit mener des entretiens plus approfondis auprès des exécutants, soit procéder à des observations ou mettre en place des capteurs ou faire remplir des autorelevés. La description des procédures effectives existantes étant très coûteuse en temps d'analyse, elle ne doit être faite que si les procédures existantes sont peu ou pas modifiées par le changement de système.
La procédure minimale (*) ne peut se dégager spontanément des entretiens car elle comprend des informations qui, la plupart du temps, ne sont pas explicites. Il s'agit ici de définir explicitement la latitude décisionnelle de l'utilisateur ou, en d'autres termes, la marge de manoeuvre dont il dispose pour effectuer le travail assigné à son poste. Cette marge de manoeuvre s'exprime par la nature des déclenchements (*) (optionnel ou systématique), des précédences (*) (permanentes ou indicatives) et des opérations (*) (obligatoires ou facultatives).
Si le système existant que nous observons est composé de procédures entièrement manuelles, la nature des déclenchements, des précédences et des opérations décrira la répartition des responsabilités entre le poste de travail que nous décrivons et les postes de travail dont il dépend ou qui dépendent de lui.
Tous les aspects obligatoires, permanents et systématiques correspondent à des consignes intransgressables à ce niveau de responsabilité.
Si les procédures existantes sont déjà automatisées, ces consignes intransgressables doivent être déjà intégrées aux logiciels; en conséquence, il faut dans ce cas étudier la répartition du pilotage entre l'homme et la machine. Mais la répartition existante du pilotage entre l'homme et la machine ne correspond pas forcément à la procédure minimale, nous pouvons simplement supposer que la procédure minimale est incluse dans la partie de la procédure gérée par ordinateur et qu'il faut alors la dégager par une étude plus approfondie.
La procédure minimale ne peut être recueillie que par entretien dirigé auprès des responsables ou des exécutants selon le contexte de l'entreprise.
Pour déterminer la procédure minimale, le plus simple est de partir de la procédure prévue déjà recueillie et de poser des questions permettant de dégager les déclenchements systématiques, les précédences permanentes et les opérations obligatoires.
La notion de déclenchement n'a de pertinence que dans le cas d'une procédure existante déjà automatisée (opérations interactives ou automatiques) où l'on se demande si c'est l'utilisateur ou l'ordinateur qui déclenche une opération; en effet, si les opérations sont manuelles, il est évident qu'elles ne peuvent être déclenchées que par l'utilisateur!
Nous rappelons qu'il y a des précédences de type logique (une modification ne peut avoir lieu qu'après une création) et des précédences de type organisationnel, c'est-à-dire liées aux règles de gestion ("tout paiement de facture ne peut se faire qu'après l'émission d'un bon de commande").
Ce sont les précédences de type organisationnel que nous étudions ici.
Pour trouver la nature des précédences, on pose des questions du type:
"Que se passerait-il si vous effectuiez l'opération Y avant l'opération X ?" (quand la procédure prévue indique que X est exécutée avant Y).
Si l'utilisateur répond que c'est impossible parce que le réglement interne ou la loi s'y oppose ou toute autre raison ne relevant pas de lui, on a une précédence permanente. S'il répond que c'est plus commode ou plus logique ou plus facile, on a très certainement affaire à une précédence indicative.
Pour connaitre le caractère obligatoire ou facultatif des opérations mises en oeuvre dans la procédure prévue, il faut poser des questions du type
"Peut-on ne pas exécuter l'opération X ?" ou
"Que se passe-t-il si on ne fait pas l'opération X ?".
Tableau de synthèse de la détermination des procédures:
A la fin de l'étude de l'existant, nous disposons donc au minimum d'une description des procédures prévues et minimales des différents postes de travail qui vont faire l'objet d'une nouvelle conception.
Nous exposons dans ce paragraphe comment concevoir les nouveaux logiciels interactifs à partir des spécifications de l'existant. Pour chaque poste de travail, cette conception se subdivise en trois parties; nous concevons d'abord la Représentation Conceptuelle de l'application puis la Représentation Externe et en dernier la Représentation Interne qui dépend à la fois des deux autres représentations.
Nous n'exposons pas ici la méthode de conception de la Représentation Interne car celle-ci est trop dépendante des logiciels de base disponibles et des méthodes de programmation; elle nécessite à elle seule un développement égal à l'ensemble de ce livre.
Nous présentons donc ci-dessous la méthode de conception de la Représentation Conceptuelle et de la Représentation Externe.
Nous allons définir, dans le premier paragraphe, les trois types de procédures (prévue, minimale, effective) du nouveau système et dans le deuxième paragraphe, le détail d'une procédure.
L'ordre d'élaboration de ces procédures peut varier selon les cas :
- si les nouvelles procédures automatisées sont proches des procédures existantes, on définira en premier lieu les procédures prévues (puis minimale puis effective).
- si les nouvelles procédures automatisées sont éloignées des procédures existantes, on définira en premier lieu la procédure minimale (puis prévue puis effective).
Ces trois types de procédures n'ont pas du tout le même statut méthodologique; il est indispensable de définir la procédure minimale; il est confortable de définir une procédure prévue; il peut être utile et efficace de définir une ou des procédures effectives .
Il y a deux manières différentes de la définir selon que le nouveau système est plus ou moins éloigné de l'ancien système.
Premier cas
Elle est déduite de la procédure minimale existante si celle-ci est peu ou pas modifiée par l'automatisation. Dans ce cas, nous repartons de cette procédure minimale existante et pour chaque opération, nous nous demandons si cette opération reste manuelle ou devient interactive ou automatique.
Pour la procédure constituée de ces opérations interactives et automatisées, nous nous posons la question fondamentale suivante:
"Les précédences permanentes et les opérations obligatoires du système existant doivent-elles être contrôlées par l'ordinateur?"; ou en d'autres termes, "transfère-t-on une partie du contrôle de l'organisation à l'ordinateur?".
La plupart du temps, la réponse est positive, car on pense que ce transfert ne peut qu'accroître l'efficacité du contrôle.
Mais ce transfert n'est pas toujours ausssi direct car on profite souvent de l'automatisation d'une procédure pour procéder à des réorganisations qui ont justement un impact sur la latitude décisionnelle des différents postes de travail: on peut être amené à augmenter ou à diminuer cette latitude décisionnelle, ce qui influe sur la nature des précédences, des opérations et des déclenchements.
Il faut noter que ces modifications sont souvent faites implicitement sans que le lien soit fait explicitement avec l'organisation.
L'objectif essentiel de cette étape est de rendre explicites les choix organisationnels et leurs conséquences sur le niveau décisionnel de chaque poste de travail.
Pour déterminer les déclenchements systématiques, il faut se demander si "l'enchaînement est immédiat ou non entre deux opérations reliées par une précedence permanente".
Si l'enchaînement est immédiat, on a un déclenchement systématique, c'est-à-dire déclenché par l'ordinateur. Dans tous les autres cas, on a un déclenchement optionnel, c'est-à-dire contrôlé par l'utilisateur.
Au niveau de la procédure minimale, il vaut mieux prévoir le maximum de déclenchements optionnels pour avoir la plus grande latitude dans la définition des procédures prévues et effectives.
Deuxième cas:
La procédure minimale est définie "ex nihilo" si l'automatisation modifie trop la procédure minimale existante.
Pour cela, on part de l'ensemble des opérations appartenant au but considéré et pour chaque opération nous définissons, comme précédemment, son caractère obligatoire ou facultatif et la nature de son déclenchement. Nous introduisons ensuite les précédences permanentes correspondant aux règles de gestion non transgressables .
Elle correspond au cas normal ou usuel. Son rôle est d'une part de servir de guidage à un utilisateur novice qui se poserait une question du type "comment faire pour atteindre le but x", d'autre part de simplifier le travail de l'utilisateur en lui fournissant une procédure réduite au cas normal avec le maximum d'aide et d'enchaînement automatique.
Si la conception du sytème automatisé n'entraîne pas ou peu de modifications, la procédure prévue peut être déduite directement de la procédure prévue existante telle qu'elle a été recuillie lors de l'étude de l'existant .
Si la conception du système automatisé entraîne une modification de la logique de fonctionnement du système d'information et/ou une réorganisation, il faudra la créer à partir de la procédure minimale. Pour cela, on rajoutera à la procédure minimale des précédences indicatives et des déclenchements automatiques qui rendront l'exécution de la procédure prévue plus commode et plus rapide. Bien entendu, il ne s'agira seulement que d'hypothèses sur le fonctionnement usuel de la procédure qui demanderont à être validées auprès des utilisateurs sur un prototype ou sur le logiciel final.
Les procédures effectives ne sont pas nécessairement définies à ce stade de la méthode. En effet, une procédure effective ne peut être définie ici que si l'on a observé lors de l'étude de l'existant des variantes de procédures liées à des types différents d'utilisateurs (novices, expérimentés, occasionnels...).
Dans le cas où on a pu procéder à ces observations, on définira une procédure effective en rajoutant des précédences indicatives à la procédure minimale qui correspondent à l'usage de l'utilisateur, en augmentant les déclenchements automatiques pour minimiser les manipulations de l'utilisateur et en supprimant des opérations facultatives non nécessaires dans ce cas particulier.
Si l'on n'a pas pu procéder à ces observations, on ne pourra pas définir de procédure effective à ce stade de la méthode. Il faudra alors attendre d'avoir réalisé complétement l'application interactive (sous sa forme minimale et prévue) afin de l'expérimenter auprès des utilisateurs et de rajouter ensuite à la demande différentes procédures effectives (ce qui suppose une structure de logiciel permettant cette adaptation telle que nous l'avons définie dans le chapitre 4).
Pour mieux visualiser la méthode de conception, nous représentons sur les deux schémas suivants deux façons de la mettre en oeuvre selon le contexte de l'étude et de l'entreprise. Dans les deux cas, nous supposons qu'il y a un existant qui sert de base à la nouvelle conception.
Mais cette phase d'étude de l'existant peut ne pas avoir lieu, soit parceque on a affaire à un nouveau service ou une nouvelle entreprise, soit parce que l'on a décidé de modifier en profondeur le système existant et qu'il ne doit plus servir de réfèrence. Les schémas que nous présentons se réduisent alors à la phase de conception suivie éventuellement de la phase d'expérimentation.
Démarche minimale
Le premier schéma montre la démarche minimale où l'on part de la procédure prévue existante recueillie par entretien ou questionnaire pour extraire la procédure minimale existante par entretien à partir de la procédure prévue.
La conception se fait alors par le chemin inverse avec la détermination de la nouvelle procédure minimale à partir de la procédure minimale existante puis la conception de la nouvelle procédure prévue en fonction de la procédure prévue existante et de la nouvelle procédure minimale.
Cette démarche est minimale en ce sens qu'on ne peut pas réduire la longueur de l'étude à un niveau inférieur en temps et en informations recueillies.
Elle peut éventuellement suffire si les procédures sont simples ou si le niveau décisionnel du poste de travail est bas.
Dans les autres cas, il vaut mieux faire une étude plus complète comme nous le présentons ci-dessous.
Démarche maximale
L'étude de l'existant peut être complétée par le recueil d'une ou de plusieurs procédures effectives qui servent à déterminer de nouvelles procédures effectives compte-tenu de la nouvelle procédure minimale.
Ultérieurement, lors de la phase d'expérimentation (après la détermination de la Représentation Externe), on peut tester l'adéquation de la nouvelle procédure prévue en tant que guide pour des utilisateurs novices et l'adéquation des procédures effectives pour les utilisateurs expérimentés.
Cette démarche est beaucoup plus coûteuse en temps d'analyste et d'utilisateur car les deux parties que nous rajoutons (procédures effectives et expérimentations) font appel à des recueils de trace de travail (observations,autorelevés, capteurs).
Les flèches en trait plein indiquent la démarche obligatoire minimale; les flèches en pointillé indiquent une démarche possible.
Les paramètres constants désignent l'ensemble des aides offertes à l'utilisateur indépendamment de toute application.
Dans le chapitre 2, nous avons défini trois types de paramètres constants; les premiers concernent l'aide au travail (interrompre, quitter, annuler, transfèrer,...), les seconds l'aide à l'apprentissage (guidage fonctionnel et guidage d'utilisation), les troisièmes les possibilités d'évolution (ajout de procédures effectives,...).
A ce stade du déroulement de la méthode, il faut décider quels sont les paramètres constants qui seront effectivement mis systématiquement à la disposition des utilisateurs.
Ce choix peut dépendre de la nature du travail, de la latitude décisionnelle des utilisateurs, mais aussi de contraintes matérielles et logicielles.
Ces choix ont des conséquences sur la Représentation Conceptuelle des paramètres variables de la procédure.
En effet, si on ne donne pas à l'utilisateur, par exemple, les possibilités systématiques de quitter ou d'interrompre, il faudra prévoir dans la description de la procédure les endroits spécifiques où l'utilisateur pourra activer ces commandes.
Les paramètres variables correspondent à la description des procédures spécifiques d'une application.
La méthode Diane pouvant se greffer sur la méthode Merise, nous utilisons le formalisme graphique de Merise pour la description des événements, des opérations, des règles d'émission et des synchronisations.
Nous rajoutons à ce formalisme différents concepts qui ont pour but de définir la répartition du pilotage entre l'homme et l'ordinateur dans le cadre des applications interactives et qui permettent de répondre aux questions suivantes:
- Qui déclenche l'opération?
Si c'est l'utilisateur, on a un déclenchement optionnel; si c'est l'ordinateur, c'est un déclenchement automatique.
- Qui fait l'opération?
Si c'est l'utilisateur, c'est une opération manuelle; si c'est l'ordinateur, c'est une opération automatique; si c'est les deux, c'est une opération interactive.
- Qui contrôle l'exécution de l'opération?
Si c'est l'utilisateur, c'est une opération facultative; si c'est l'ordinateur, c'est une opération obligatoire.
- Qui contrôle l'enchaînement entre opérations?
Si c'est l'utilisateur, c'est une précédence indicative; si c'est l'ordinateur, c'est une précédence permanente.
L'ensemble de ces paramètres variables ainsi que le formalisme associé est présenté dans la deuxième partie du chapitre 2.
L'étude de cas présentée à la fin de ce chapitre illustre de façon détaillée la description des procédures de la Représentation Conceptuelle.
La conception de la Représentation Externe est dépendante de plusieurs éléments que nous avons schématisés sur la figure ci-dessous.
En premier lieu, elle comprend la traduction des spécifications déterminées dans la Représentation Conceptuelle.
Elle intégre aussi certains éléments d'ergonomie provenant de l'étude de l'existant comme le vocabulaire spécialisé, ou ayant un caractère général comme l'homogénéité.
Et elle dépend également des possibilités techniques matérielles et logicielles des ordinateurs sur lesquels se fait l'implémentation.
Dans la première étape de la définition de la Représentation Externe il s'agit de donner une représentation externe aux paramètres définis dans la Représentation Conceptuelle et que nous avons détaillés à la fin du chapitre 2.
On distingue, comme précédemment, les paramètres constants des paramètres variables qui sont propres à l'application.
Les paramètres constants de la Représentation Conceptuelle concernent l'aide à l'utilisation, la mémorisation et le guidage; ces paramètres doivent être traduits sous forme de commandes activables par l'utilisateur.
Pour chacune de ces commandes, il faut prévoir:
- un nom sans ambiguïté pour les utilisateurs et compatible avec les logiciels existants
- une forme de présentation (caractères gras, italiques,...) éventuellement variable pour indiquer que la commande est ou n'est pas activable
- un mode de désignation (touche-fonction, souris,...) et une syntaxe rapide et facile à mémoriser
- une détection d'erreurs et le contenu des messages correspondants
- une subdivision, s'il y a lieu, correspondant à une fréquence d'utilisation.
Les paramètres propres à l'application se divisent en paramètres provenant de la procédure qui se traduisent sous la forme de commandes activables par l'utilisateur et de paramètres provenant des opérations qui se traduisent en données.
Pour les commandes spécifiques à l'application, il faut prévoir:
- une hiérarchie de l'ensemble de ces commandes qui refléte la logique d'utilisation
- une présentation des commandes (menu déroulant, glissant, fixe) et une forme de caractères avec éventuellement une deuxième forme pour distinguer les commandes activables des autres (menu dynamique)
- la dénomination de ces commandes en utilisant au maximum le vocabulaire et les abréviations des spécialistes s'ils existent.
- le mode de désignation et la syntaxe
- le contenu des messages d'erreurs qui peut être très variable selon que l'on décide ou non de distinguer les erreurs d'intention des erreurs d'exécution.
La traduction des opérations amène la définition des éléments suivants:
- la présentation de la zone de dialogue avec la distinction des zones d'entrée (saisie de l'utilisateur) et des zones de sortie (réponse de l'ordinateur)
- le vocabulaire des données issu du vocabulaire des spécialistes
- la syntaxe de fin de saisie de données et de validation de zones ou d'écrans
- le contenu des messages d'erreur en fonction des erreurs que l'on a choisi de détecter et des possibilités de correction.
La traduction de l'ensemble des paramètres que nous venons d'énumérer doit se faire en tenant compte d'une part des critères ergonomiques, d'autre part des possibilités techniques, comme nous allons le détailler dans les deux paragraphes suivants.
Nous distinguons les critères ergonomiques à caractère général des éléments ergonomiques provenant de l'étude de l'existant, c'est-à-dire propres à l'application.
Le premier critère à intégrer à la Représentation Externe est le critère d'homogénéité qui a des conséquences sur trois éléments:
- la présentation générale des écrans, c'est-à-dire le choix des emplacements des zones de menu, de saisie de données, de messages d'erreur, de messages de services, cette présentation devant être homogène sur l'ensemble de l'application et si possible avec les autres logiciels existants;
- les dispositifs d'entrée en distinguant les dispositifs d'entrée des données de ceux d'entrée des commandes et, éventuellement, en distinguant les commandes standard et les commandes particulières; l'entrée des commandes standard doit être homogène sur l'ensemble du logiciel, rapide et facile à mémoriser; le dispositif d'entrée des commandes particulières doit être aussi homogène et doit se distinguer sans ambiguïté du dispositif d'entrée des données;
- la syntaxe du langage de commande, c'est-à-dire la validation des commandes, des données et des écrans.
Les éléments provenant de l'existant se répartissent en deux ensembles; les premiers ont déjà été utilisés au niveau de la conception de la Représentation Conceptuelle: il s'agit de la répartition du pilotage entre l'homme et la machine et de la logique d'utilisation; les seconds sont intégrables uniquement au niveau de la Représentation Externe et il s'agit:
- du vocabulaire des spécialistes qui sert à déterminer le vocabulaire des données et des commandes quand cela est possible, c'est-à-dire quand il y a correspondance entre les opération existantes et les opérations créées par l'automatisation;
- de la présentation des formulaires ou des écrans existants dans la mesure où il n'y a pas de modifications du système d'information existant;
- des erreurs à détecter et des possibilités de correction qu'il y a à faire compte-tenu des impératifs de fiabilité de l'application et des types d'erreurs usuels commis.
La détermination de la Représentation Externe est elle aussi fortement dépendante des possibilités matérielles et logicielles des ordinateurs sur lesquels se fait la réalisation.
Sur le plan matériel, il y a deux contraintes:
- la définition de l'écran qui donne la limite du nombre de caractères aisément lisibles par l'utilisateur et les possibilités graphiques;
- les dispositifs physiques d'entrée (clavier, souris,...) qui offrent plus ou moins de choix pour distinguer par exemple les commandes des données.
Sur le plan logiciel, la contrainte essentielle tient au type de logiciel de gestion d'écran qui impose des contraintes très fortes sur la présentation générale et particulière de l'interaction ainsi que sur les possibilités de commandes standard comme l'interruption. Cet élément a été développé dans les chapitres 3 et 4.
La conception de la Représentation Externe ne peut se faire de manière linéaire en intégrant d'abord la Représentation Conceptuelle, puis les critères ergonomiques, puis les possibilités techniques; ces trois éléments doivent être intégrés simultanément pour la conception de chacun des paramètres de la Représentation Externe.
Nous avons visualisé ces interactions dans le schéma suivant.
L'objectif de cette étape est de montrer comment faire des tests auprès des utilisateurs sur le logiciel conçu et réalisé dans les trois étapes précédentes.
Si la réalisation a abouti directement au logiciel définitif, les modifications consécutives aux tests que nous allons pratiquer dans cette phase risque d'être coûteux en temps de programmation. Aussi est-il préférable, quand cela est possible, de procéder aux tests sur des versions du logiciel non définitives, c'est-à-dire sur des maquettes ou des prototypes.
Nous appelons maquette une simulation partielle du logiciel; certains outils de génie logiciel engendrent automatiquement des maquettes qui permettent par exemple de simuler l'enchaînement des écrans. Les maquettes sont surtout utiles à l'analyste car elles lui permettent de visualiser les conséquences des spécifications qu'il vient de faire, mais elles sont d'un intérêt limité pour des tests auprès des utilisateurs car trop éloignées du logiciel définitif.
Nous appelons prototype un logiciel qui possède toutes les fonctionnalités du logiciel définitif, mais sans souci de performances (optimisation des temps de réponse et de la place mémoire). Les prototypes peuvent être générés automatiquement par un outil de génie logiciel ou écrits directement avec un langage d'intelligence artificielle (PROLOG, SMALLTALK,...). Les prototypes correspondent à une version du logiciel définitif réaliste qui permettent de réaliser efficacement des tests auprès des utilisateurs, puis de le modifier à un moindre coût.
Cette étape de tests auprès des utilisateurs n'est pas encore couramment pratiquée en informatique, mais dans le cas de logiciels interactifs elle est indispensable car plusieurs éléments de la Représentation Externe ne peuvent être déterminés en l'absence de l'utilisateur.
Les éléments à tester sont d'une part des éléments simples pour lesquels il n'y a pas de critères ergonomiques d'autre part l'interaction d'éléments simples dont l'effet est a priori non prévisible.
Il s'agit ici de tester tous les éléments de la Représentation Externe qui n'ont pas pu être défini à partir de critères ergonomiques:
- le vocabulaire qui n'est pas inspiré du vocabulaire des spécialistes; c'est généralement le cas du vocabulaire de commandes correspondant à des opérations propres à l'ordinateur ou à de nouvelles opérations qui n'existaient pas;
- la présentation des zones de saisie de données nouvelles qui ne correspondent pas à des formulaires ou des écrans existants;
- la logique d'utilisation pour des tâches nouvelles ou profondément modifiées par l'automatisation;
- les procédures effectives mises en oeuvre par les utilisateurs sur les nouveaux logiciels.
Nous avons présenté au chapitre 3 des critères ergonomiques pour chacun des paramètres de la Représentation Externe, mais quand on veut appliquer l'ensemble de ces critères sur une application particulière avec des possibilités techniques particulières, on est amené à faire des choix, des compromis qui n'optimisent pas forcément l'ensemble des paramètres. C'est pour pouvoir tester les effets de ces choix qu'une expérimentation sur prototype est également nécessaire.
Nous citons ci-dessous les interactions les plus courantes:
- pour la présentation du dialogue, il peut s'avérer impossible pour des raisons techniques (définition de l'écran) de suivre la mise en page des formulaires existants; on doit alors proposer une présentation des données cohérente avec un ordre "standard" de saisie et l'expérimenter;
- pour le mode de désignation, il peut y avoir incompatibilité entre le critère d'homogénéité et les possibilités techniques des dispositifs d'entrée.
Par exemple, on peut être limité par le nombre de touches-fonctions disponibles par rapport au nombre de commandes standard ou propres à l'application; il faut alors choisir de façon arbitraire les commandes qui seront activées par touche-fonction (de préfèrence les commandes standard) et choisir également un autre mode de désignation pour les autres commandes;
- il peut y avoir incompatibilité entre la hiérarchie du menu et sa présentation; en effet, la hiérarchie du menu doit refléter la logique d'utilisation et la présentation du menu est dépendante des possibilités techniques et doit être homogène sur l'ensemble des logiciels.
Pour une application particulière, on peut avoir un niveau du menu pou lequel les libellés des commandes correspondantes soient en nombre supérieur à la capacité de la zone de présentation du menu. Il faut alors choisir entre la modification de la présentation du menu et la modification de la hiérarchie de ce menu;
- le mode de désignation peut impliquer des contraintes pour le choix du vocabulaire des commandes.
En effet, si la désignation n'est pas directe (saisie de la commande au clavier), il faut prévoir une abréviation de cette commande. Cette abréviation doit être l'application d'une règle mnémonique sur les noms de commande; les noms de commandes sont par ailleurs choisis soit dans le vocabulaire des spécialistes, soit pour leur non-ambiguïté. Il n'est pas évident qu'en appliquant la règle d'abréviation sur ces noms, on obtienne des abréviations toujours différentes.
Dans ce cas, il faut choisir entre modifier le vocabulaire des commandes ou modifier la règle d'abréviation.
On peut procéder à des tests "en laboratoire" ou à des tests "sur le terrain".
Les tests en laboratoire sont surtout utiles sur une première version du prototype pour en éliminer les dysfonctionnements les plus criants, mais les tests sur le terrain sont plus révélateurs. Cependant ces derniers ne sont pas toujours possibles car ils peuvent s'avérer perturbants pour le milieu de travail.
Si cela est possible, il est intéressant de procéder à des tests à deux moments: tout d'abord en début d'utilisation, puis un ou deux mois après le début de l'utilisation.
Les tests de début permettent surtout de tester les facilités d'apprentissage alors que les tests ultérieurs permettent de tester le facilités d'utilisation pour des utilisateurs expérimentés.
Les tests sont obligatoirement longs pour l'analyste car il n'est pas possible de procéder à de simples entretiens comme dans le cas de l'étude de l'existant.
En effet, au cours d'un entretien, l'utilisateur fait une reconstruction mentale du travail qu'il a effectué et cette reconstruction a tendance à gommer ou à surévaluer les erreurs qu'il commet et les difficultés qu'il rencontre.
Les seuls moyens de tests fiables dans ce contexte sont les observations et les capteurs (les autorelevés étant trop coûteux en temps utilisateur).
Les capteurs sont particulièrement bien adaptés aux tests sur prototype car ils peuvent être rajoutés au logiciel du prototype sans fausser le cours normal de l'exécution du travail de l'utilisateur.
Le capteur le plus simple consiste en la mémorisation systématique de l'ensemble des transactions effectuées entre l'utilisateur et le logiciel. Mais ce type de capteur fournit une masse d'informations difficile à synthétiser; aussi est-il souvent plus judicieux de faire des capteurs plus sélectifs portant sur les éléments qu'il nous semble prioritaire de tester , ce qui facilite les synthèses ultérieures.
La phase de tests à partir de capteurs peut être précédée ou suivie d'observations par un tiers ou par l'analyste.
Les observations faites avant permettent de dégager les éléments sur lesquels il sera nécessaire de faire des tests au moyen des capteurs.
Dans tous les cas, les observations permettent de dégager des faits qui ne peuvent être enregistrès par capteurs; c'est le cas par exemple de toutes les consultations d'informations hors logiciels effectuées par les utilisateurs.
Ces observations peuvent être complétées par des entretiens portant sur certains faits observés et difficiles à interpréter; il peut être utile de savoir pourquoi telle information a manqué à un moment particulier.