1. Introduction

2Un deuxième axe de lecture porte, quant à lui, sur l’évolution de notre pratique : partis de la concep­tion centrée utilisateurs, nous nous sommes impliqués de plus en plus concrètement dans le proces­sus de conception d’applications informatiques. Ce positionnement en tant qu’ergonome-concepteur s’est fait sur les bases d’une articulation de plus en plus précise entre connaissance de l’activité et conception technique. Cet axe de lecture permet donc d’aborder l’évolution de nos connaissances liées à l’activité humaine et à son articulation avec la conception des situations de travail ou de vie quotidienne.

3Un troisième axe de lecture est relatif à notre pratique de la conception en terme d’aide. Le monde de l’ergonomie et celui de l’IHM (Interaction Homme-Machine) ont depuis le début des années 80 explicité des critères tels que l’utilité et l’utilisabilité. Notre pratique nous a amenés à revisiter ces critères de qualité de l’interaction et à les utiliser structurellement comme des cadres pour la concep­tion d’une aide au travail ou à la vie quotidienne. Cette construction de l’aide à partir d’une série de critères nous a ainsi progressivement permis de poser les bases pour des échanges structurés entre acteurs de la conception.

4Ce texte est organisé autour des différents épisodes de cette histoire. Ainsi chaque partie de ce docu­ment correspond à un épisode et porte spécifiquement sur une question relative à notre pratique. Ce mode de présentation, qui met en évidence une réflexion théorique et pratique pour une période don­née, rend bien compte du besoin de capitalisation que nous avons éprouvé à chacun de ces moments-là. Par contre cette présentation peut laisser une double fausse impression. Tout d’abord, elle peut laisser croire qu’à chacune de ces périodes nous ne travaillions que sur un seul type de projet, ce qui n’était pas le cas (par exemple nous avons beaucoup investi dans les années 90 sur le WEB mais nous étions également impliqués sur d’autres types d’applications). Ce mode de présentation peut également laisser l’impression que nous ne considérions, à chacun de ces moments, qu’une seule dimension (l’utilité ou l’utilisabilité….), alors que l’ergonome impliqué dans un projet est toujours confronté à une multitude de points à traiter. Il s’agit bien sûr d’un effet de présentation et, quand par exemple, nous abordions plus précisément la question de l’utilité cela ne voulait pas dire que nous n’apportions pas des réponses aussi à l’utilisabilité et à bien d’autres points ; bien évidemment nous le faisions, mais pour ainsi dire « à l’état de l’art » ou plus exactement en l’état de notre exper­tise, sans chercher à la dépasser.

5Cette histoire de notre pratique de conception est donc structurée autour des épisodes suivants :

1. Dépasser nos acquis des années 80 ;

2. Début des années 90 : de l’utilité pour concevoir une Interaction Homme-Machine ;

3. Fin du XX^e siècle : de l’utilisabilité pour concevoir une Interaction Homme/Machine grand public ;

4. Nouveau millénaire : élargissement de nos problématiques et redéfinition de notre pratique autour des critères de qualité de l’interaction.

2. Dépasser nos acquis des années 80

6Pour aborder ce cheminement historique, nous débutons par la toute première étape qui correspond à la volonté d’un travail de collaboration entre informaticien et ergonome. Cette étape des années 80 est essentielle car elle ancre, dans la pratique des projets, la présence d’ergonomes impliqués con­crètement dans la conception : l’ergonome n’est plus « un juge » qui intervient quand tout est fini mais il devient un acteur de la transformation. La conception centrée utilisateur apparaît à cette épo­que et devient un catalyseur, un porte-drapeau pour les concepteurs, informaticien ou ergonome, qui souhaitent proposer des orientations différentes de conception. L’informatique est reconnue comme un moteur de la transformation, mais celle-ci touche maintenant une large part de la société et pas seulement les informaticiens (pour mémoire le premier PC sort en 1981, la métaphore du bureau de MACINTOSH avec son interface à icônes et fenêtres fait école à partir de 1984 et le livre « User centered system design » est publié en 1986). Le déclin d’une informatique lourde et centralisée débute au profit de postes de travail autonomes qui transforment le métier de la secrétaire, de l’ingé­nieur, du scientifique… Concevoir pour un métier va devenir une priorité qui va animer la commu­nauté internationale spécialiste de ces questions. En interne EDF R&D, le même mouvement se retrouve fin des années 80/début des années 90. Le développement d’applications métier prend une certaine importance et les questions d’interfaces structurent le travail de ces années. Nous présen­tons dans cette partie deux points relatifs à notre pratique :

• les fondements de notre pratique fin des années 80/début 90 ;

• les limites de cette pratique centrée utilisateur et la nécessité de passer à une approche plus modélisatrice pour mieux porter les collaborations de conception.

2.1. Construction des fondements de notre pratique

7Avec la généralisation de l’utilisation de la micro-informatique, les chercheurs du monde universi­taire et industriel ont progressivement pris conscience que l’utilisateur ne peut plus être écarté du processus de conception. Ce mouvement dans les pratiques de conception, après Norman et Draper (1986), a comme slogan la « conception centrée utilisateur ». Ainsi, plusieurs auteurs informaticiens ont montré la nécessité de réaliser une analyse du travail pour la conception de logiciels interactifs. Par exemple, Barthet (1988), Coutaz (1990) mais également Balbo et Coutaz (1993) ont mis en lumière le fait qu’il est nécessaire de bien spécifier la logique d’utilisation d’un futur système et que cela ne peut se réaliser qu’en utilisant les résultats d’une analyse du travail. Ne pas le faire aboutit à ne pas maîtriser la définition des besoins des utilisateurs. Il en résulterait un système dont les fonc­tionnalités sont inadéquates ou inadaptées. Ces auteurs n’affirment pas seulement une position de principe sur la place de l’humain dans la transformation. Ils vont plus loin quand ils proposent d’intégrer le facteur humain à toutes les phases du cycle de vie du logiciel, afin de dépasser le pro­blème du « trop peu, trop tard » relatif à la sous-représentation du facteur humain dans la conception (Palanque, Long, Tarby, Barthet, & Lim, 1994). La conception centrée utilisateur vise donc l’inte­raction et identifie l’analyse du travail comme un moyen permettant de spécifier et développer un outil informatique.

8Cette rencontre entre informaticien et ergonome peut avoir lieu car en ergonomie plusieurs auteurs orientent aussi leurs travaux dans cette même direction. En mettant l’utilisateur au centre du proces­sus de conception, ils souhaitent que l’homme ne soit plus considéré comme un simple « serviteur » du système : le seul critère de transformation technique ne peut plus être la seule puissance des sys­tèmes. Ainsi, des critiques précises sont émises contre les outils informatiques qui ne sont en fait que des prothèses cognitives ; plusieurs auteurs proposent de dépasser cette vision techniciste en abor­dant la conception comme une question d’aide aux activités de l’utilisateur (Pinsky, Kandaroun, & Lantin, 1979 ; Pinsky, & Theureau, 1982 ; Norman, & Draper, 1986 ; Cahour, & Falzon, 1991). Cette approche de la conception comme aide considère l’utilisateur comme un acteur qui doit être aidé dans son raisonnement, dans ses décisions d’action, dans l’évaluation de ses actions. Dans la mesure où l’utilisateur est amené à estimer la pertinence d’une recommandation ou d’un conseil donné par le système (Valot, 1988 ; Falzon, 1989), il est indispensable de l’associer au processus de résolution du problème et de lui donner les moyens de juger de la pertinence des conclusions propo­sées par le logiciel. Ainsi, le système informatique n’est plus un super calculateur qui donne des solutions, il est avant tout un outil permettant de favoriser un engagement de l’utilisateur dans l’action (Hutchins, Holland, & Norman 1986 ; Laurel, 1986).

10Cette démarche, intégrant aspect technique et activité humaine, nous a amenés à progressivement changer notre vocabulaire à la fin des années 80. La cible est progressivement passé d’une descrip­tion de l’interface informatique avec ses menus, ses outils, ses recommandations ergonomiques etc., à une cible visant l’interaction Homme-Machine. Avec cette évolution vers l’interaction, ce n’est plus l’outil qui est la seule visée de transformation mais l’articulation entre l’activité humaine etl’outil. À titre d’exemple, les ergonomes travaillant sur ces questions sont situés dans une entité de la R&D qui se nomme encore au début des années 90 « Outils de dialogue pour l’informatique ». Le même groupe, quelques années plus tard, se nommera « Interaction Homme-Machine ».

11En clarifiant l’articulation entre processus de conception informatique et connaissance de l’activité humaine, nous franchissons un pas important dans notre pratique et en même temps nous nous transformons progressivement en ergonome concepteur. Ce changement de rôle a pourtant rapidement montré une limite de notre pratique. Nous développons ce point dans la sous-partie suivante.

2.2. Limite de notre pratique : le manque de modélisation

12Nous avons acquis une certaine légitimité mais les pratiques habituelles que nous mettions en œuvre et qui consistent à « aller sur le terrain », « organiser le point de vue utilisateur », « mettre en avant des dysfonctionnements par rapport à l’activité humaine », « proposer des recommandations » attei­gnent une limite : si nous souhaitons participer à la conception d’une application nous devons être plus précis dans la connaissance de l’activité. En effet, les concepteurs entendent s’appuyer sur la pérennité du métier de l’utilisateur pour orienter la conception. Le postulat est que le métier peut évoluer (par exemple le spécialiste en neutronique) mais que ce processus d’évolution du métier est beaucoup plus lent que celui de l’évolution des outils. Il nous faut alors proposer une vue organisée des futurs besoins permettant de répondre aux exigences métier d’un utilisateur. L’analyse de l’acti­vité est notre moyen pour y parvenir.

13Les auteurs qui abordent la question de la modélisation dans une logique de conception informatique ne sont pas légion fin des années 80. Scapin (Scapin, & Pierret-Golbreich, 1989) est précurseur quand il définit un modèle pour la conception (MAD) qui intègre un point de vue utilisateur. La démarche de Laval (1993) visant à définir une modélisation admissible de l’activité (déclinaison spécifique du Cours d’Action) en modèle informatique SADT est également très exceptionnelle. Nous avons retenu de ces travaux mais aussi de textes plus généraux (par exemple, ceux recueillis dans Amalberti, de Montmollin, & Theureau, 1991, suite au XXIV Congrès de la Société d’Ergono­mie de Langue Française) que la modélisation est un moyen permettant d’orienter la conception informatique. Nous allons chercher alors à proposer, dans un cadre industriel, une approche plus modélisatrice de nos résultats de l’activité pour permettre une articulation avec les concepteurs. Pour autant, il ne s’agit pas pour nous de développer « le modèle » mais, en nous inspirant de Nor­man et Draper (1986), nous pensons que des modèles même approximatifs sont suffisants pour la conception. Par approximatif, nous entendons un modèle qui utilise des « raccourcis » par rapport à une théorie donnée de l’activité humaine mais dont les règles d’élaboration et les limites sont expli­citées. En ce sens, nous nous orientons vers une connaissance de l’activité plus précise, notre objec­tif étant de « définir un niveau d’analyse, de description et si possible d’explication pertinent de ces activités compte tenu de ses objectifs de conception d’aides au travail » (Salembier, 1993, p. 71).

14Ainsi, en nous appuyant sur les évolutions scientifiques de cette époque et en tenant compte de l’orientation modélisatrice des informaticiens avec qui nous travaillions (voir par exemple, Brisson & André 1994), nous nous sommes engagés dans une voie plus modélisatrice pour rendre compte de l’activité. La suite de cet article correspond donc à une réflexion sur notre pratique et sur la réponse que nous avons proposée à nos interlocuteurs, dans un premier temps pour aborder l’utilité et ensuite pour définir l’utilisabilité.

3. Début des années 90 : de l’utilité pour concevoir une interaction Homme-Machine

15Notre contexte de travail dans le début des années 90 est celui du développement d’applications scientifiques destinées aux ingénieurs d’EDF. À titre d’exemple, nous émaillerons le développement de cette partie d’exemples issus du projet GAB (Gestion Automatisée de Bibliothèques). Cet outil, aujourd’hui en service, permet de réaliser des études de neutronique dans le cadre des chargements/ déchargements en combustible du cœur d’un réacteur nucléaire.

16Le développement industriel d’une application scientifique est très long et il est très coûteux d’iden­tifier tardivement un dysfonctionnement résultant d’une inadéquation de l’application aux besoins de l’utilisateur. L’ajout tardif d’une fonctionnalité peut être pratiquement impossible, que ce soit pour des raisons techniques ou pour des raisons de coût. Pour cette raison, il a fallu plusieurs années pour développer l’application GAB mais la définition des fonctionnalités l’a été dans la première année. Elle a servi ensuite de socle sur lequel l’ensemble du système a été conçu et développé. Défi­nir systématiquement les besoins de l’utilisateur en s’appuyant sur ses logiques métier est donc un enjeu qui nous a incités à expliciter les règles de notre pratique au moment de la spécification d’une application. Pour aborder ce processus de transformation, nous distinguons les sous-parties suivantes :

• Les bases de la modélisation pour la conception ;

• Une modélisation de l’activité comme base du diagnostic ergonomique ;

• D’une modélisation de l’activité à un modèle de la future application ;

• Synthèse : modéliser pour définir l’utilité d’une application.

3.1. Les bases de la modélisation pour la conception

17Notre connaissance de l’activité humaine, liée à nos interventions ou à nos travaux plus théoriques et méthodologiques, s’inscrit dans le cadre du paradigme constructiviste proposé par Maturana et Varela (Varela, 1989 ; Maturana, & Varela, 1994). Dans cette perspective nous considérons que l’activité humaine est spécifique et ne peut être réduite au fonctionnement d’un ordinateur. En d’autres termes, nous distinguons deux modélisations avec d’un côté la logique du vivant que nous abordons à partir d’une modélisation de l’activité humaine et d’un autre côté la logique de l’artificiel qui correspond pour nos projets à un modèle informatique pour la conception. La modélisation de l’activité doit rendre compte de phénomènes qui sont dynamiques et contextuels en s’appuyant sur des notions et méthodes qui lui sont spécifiques. Ces notions et méthodes ne sont pas inscrites dans les modèles de conception informatique qui doivent présenter une vue exhaustive et hiérarchique des tâches que doit réaliser un utilisateur avec un système. Le passage du modèle de l’activité au modèle de conception ne peut donc être considéré comme une traduction d’un modèle à l’autre. En fait, l’analyse de l’activité sert de base pour définir un modèle de conception. Dans une telle appro­che, il est donc nécessaire de proposer une description modélisatrice de l’activité et de définir les conditions de passage d’un modèle d’activité au modèle pour la conception.

• • 4 Cela ne signifie pas que certaines expérimentations ne sont pas possibles, mais elles doivent être (...)

  La connaissance de l’activité passe par une analyse en situation réelle de travail. Elle ne peut pas être abordée uniquement hors situation (les interviews) ou à partir d’une situation expéri­mentale qui réduirait le travail à quelques variables isolées4 ;

• L’activité doit être abordée du point de vue de l’acteur (Bannon, 1991). Le point de vue de l’acteur semble un point de vue préférable à tout autre quand il s’agit d’interpréter son activité (Whiteside, & Wixon 1987 ; Winograd, 1990). Ainsi, l’analyse de l’activité porte sur la façon dont l’utilisateur travaille et sur la façon dont il raisonne.

• Une raison théorique : l’acteur humain détermine son engagement dans une situation en fonc­tion de son histoire et de la situation dans laquelle il se trouve. Cette articulation entre son his­toire et son engagement dans une situation est nommée couplage structurel par Maturana et Varela (1994). Theureau (2004a) met en exergue le côté asymétrique de ce couplage structu­rel pour insister sur l’aspect autonome de l’acteur humain qui construit son engagement sur les bases du point de vue particulier qu’il a de la situation (ou du système plus vaste dans lequel il se situe).

• Une raison technologique : la conception en terme d’aide postule une réponse adaptée à un acteur humain en situation. Dans ces conditions, la notion d’aide à l’utilisateur renvoie au côté asymétrique de l’interaction et vise à apporter une aide à la dynamique d’action et de rai­sonnement de l’utilisateur.

20Ainsi, concevoir en terme d’aide consiste à concevoir un couplage structurel asymétrique favorisant l’action de l’acteur humain : nous parlons de couplage structurel asymétrique d’aide. Cette orien­tation se distingue par exemple des approches de la conception en terme de répartition de tâches qui ne vise pas explicitement l’aide à l’utilisateur et postule plutôt une répartition des tâches en fonction de différences « d’habiletés » entre humain et système technique.

• PROSPECT, en tant que méthodologie de définition des spécifications, entend se limiter à l’explicitation des besoins et en rendre compte par un modèle de tâches. Cette focalisation exclusive sur les besoins est une réelle originalité de PROSPECT qui, de ce fait, ne porte pas sur la définition des dialogues d’une application informatique (les logiques de dialogue, l’organisation des menus sont abordées en phase de conception du dialogue sur la base de concepts qui lui sont propres …). Ce point est important pour l’ergonome car, dans un pre­mier temps, il se focalise sur les besoins d’aide à l’activité pour orienter la définition des tâches du futur système. Ensuite, il peut se consacrer aux logiques de raisonnement et d’actions de l’activité qu’il faut favoriser par un dialogue adapté.

• PROSPECT définit très clairement que le modèle de tâches doit être élaboré en référence à une analyse de l’activité. De plus il permet de spécifier les besoins d’une application en dis­tinguant dans un premier temps les tâches du futur système et ensuite les objets informatiques (les concepts utilisateurs) nécessaires au fonctionnement de ces tâches (par exemple, la tâche « changer un crayon dans un assemblage » nécessite de définir les objets « crayon » et « assemblage »). Le fait d’assujettir la définition des tâches aux besoins de l’activité et ensuite les objets informatiques aux tâches correspond à une déclinaison du principe de « conception centrée utilisateur » et de « conception en termes d’aide » : l’objet technique n’est pas défini a priori mais en référence explicite à un besoin de l’activité humaine.

22La description de l’activité dans des conditions opérationnelles est donc notre premier objectif. Il nous faut ensuite participer à la définition d’un modèle pour la conception en explicitant ses règles d’élaboration en fonction de la modélisation de l’activité. Ce processus d’analyse et de conception est présenté dans les sous-parties ci-après.

3.2. Une modélisation de l’activité comme base du diagnostic ergonomique

• La notion d’unités significatives pour l’acteur. L’analyse que nous réalisons s’attache à mettre en évidence des cohérences d’actions, de communications, d’interprétations, etc., qui sont significatives pour l’utilisateur

• La notion de récits réduits. A partir de cette notion d’unités significatives, l’analyste peut dégager des unités significatives élémentaires et d’autres unités significatives plus larges, les englobant. Un récit réduit correspond donc à un enchaînement d’unités significatives plus ou moins larges présentant ainsi, sous forme de récit, un moment d’activité de l’utilisateur.

24A titre d’exemple, le récit réduit partiel (Figure 2) montre une organisation d’un moment d’activité autour de trois types d’unités significatives (unités élémentaires d’interactions, séquences d’interac­tions et macro-séquences d’interactions).

25De plus, comme il s’agit pour nous de produire un modèle pragmatique dans un cadre opérationnel, nous construisons notre analyse en deux temps (Figure 3 ci-dessous) :

• Dans un premier temps (côté gauche), nous décrivons systématiquement le contenu d’une bande vidéo (écrire les paroles exactes qui sont échangées, les actions réalisées, les transfor­mations de la situation, etc.) et nous définissons les notions d’analyse qui permettent de met­tre en évidence l’organisation de l’activité relative à ce protocole détaillé. Cette démarche nous permet de décliner l’analyse en unités significatives pour ce moment d’activité (ici celle du neutronicien).

• Dans un deuxième temps (côté droit de la figure), nous cherchons à optimiser le temps d’ana­lyse en diminuant le temps de retranscription ainsi que le temps d’identification des unités d’analyse les plus petites. Pour cela, nous identifions et nommons à la volée (en visualisant les films) les unités significatives les plus petites. Sur la base de ce matériau, il devient ensuite possible de reconstituer autant de récits réduits qu’il y a de vidéos à analyser.

26Le modèle d’activité que nous construisons résulte alors d’une généralisation issue d’une comparai­son des différents récits réduits entre eux. Cette modélisation de l’activité est le point de départ qui mène ensuite au modèle pour la conception.

3.3. D’une modélisation de l’activité à un modèle de tâche de la future application

• L’analyse de l’activité permet d’identifier des logiques à préserver et des dysfonctionnements à dépasser. Ce diagnostic d’aide, à la charge de l’ergonome, doit guider la spécification du futur système.

• L’ergonome seul ou l’informaticien seul ne peut prévoir ce que sera la situation future. C’est l’association de la connaissance de l’existant (l’ergonome) avec la connaissance des possibles techniques (l’informaticien) qui permet d’orienter la spécification selon une logique d’aide au travail.

28Pour structurer le travail de l’ergonome et celui de l’informaticien, comme le montre la Figure 4 ci-dessous, nous distinguons trois étapes :

• La description des tâches de l’existant. L’ergonome met en relation le modèle de l’activité avec les caractéristiques de la situation de travail (contraintes de l’environnement technique, règlements, experts, etc.) pour évaluer les causes de son efficacité, de ses dysfonctionne­ments. Il s’agit ici de produire un diagnostic d’aide permettant d’identifier les tâches qui apporteront une aide à l’activité de l’utilisateur. La collaboration entre informaticien et ergo­nome est faible.

• La description des tâches futures. Le passage de la description des tâches de l’existant à la description des tâches futures permet de poser explicitement les transformations qui sont envisagées dans le métier (par exemple, du fait des évolutions techniques) et d’en imaginer les conséquences sur l’activité future. Ici, la collaboration est très forte entre informaticien et ergonome. Cette étape correspond donc à définir des tâches futures permettant d’apporter une aide pour une activité future estimée.

• Le modèle de tâches de la future application. Le passage de la description des tâches futures au modèle du poste de travail, porté essentiellement par l’informaticien, permet de définir le futur poste de travail en supprimant les tâches qui sont automatisables et celles qui ne sont pas jugées nécessaires par le projet (par exemple, du fait d’une contrainte de coût).

29Ce passage d’un modèle d’activité à un modèle pour la conception respecte deux orientations fondamentales :

• Nous distinguons deux réalités, à savoir la cognition humaine d’un côté et le fonctionnement de l’ordinateur de l’autre. Le fait de les avoir bien séparées nous permet de les articuler en passant par un diagnostic d’aide (ici définir les fonctionnalités qui aident à l’activité modélisée) ;

• Le passage de modèle à modèle, en se faisant par étapes, permet de penser progressivement et collectivement la future situation et d’envisager les transformations de l’activité future.

3.4. Synthèse : modéliser pour définir l’utilité d’une application

30En ce début des années 90, la question sur laquelle porte notre priorité est celle de la définition des fonctionnalités d’une application. De cette période et de la réflexion méthodologique qui en découle, nous retenons deux points qui sont devenus centraux pour notre pratique : il s’agit de la construction de l’utilité et du rôle de la modélisation.

31Le premier point de notre retour d’expérience est relatif à l’utilité. Elle est généralement reconnue comme la notion portant les besoins et attentes actuels et à venir d’un public cible pour un objectif de service donné. Cette notion est très souvent abordée pour l’évaluation d’une application, mais assez rarement comme une notion pouvant guider la conception. C’est sur ce dernier point que notre expérience est originale car elle nous conduit à préciser la notion d’utilité dans son rôle de cadre pour la conception. Sur les bases de notre pratique, nous définissons maintenant cette notion comme suit :

• L’utilité est centrale pour la définition même d’une application, elle n’est pas une notion seu­lement réservée à l’évaluation (apprécier l’adéquation des fonctionnalités d’une application à une situation).

• L’utilité d’une application se construit à partir d’un processus d’abstraction qui articule modèle d’activité et modèle pour la conception.

• L’utilité ne se base pas sur n’importe quelle analyse de l’activité mais au contraire sur une analyse qui est focalisée sur les composants de l’activité et leur organisation dynamique (pour notre part, nous utilisons les récits réduits mais d’autres approches sont évidemment possi­bles) pour permettre ensuite de fonder le diagnostic d’aide à cette activité.

• L’utilité est le résultat d’une coopération d’acteurs de la conception permettant de progressi­vement passer d’un diagnostic d’aide à une inscription numérique des besoins en terme de fonctionnalités pour la future application.

• L’utilité est essentiellement portée en phase de spécification et se distingue de la question de l’utilisabilité portée en phase de conception du dialogue. L’utilité est un domaine autonome de connaissance et il est logique de se poser la question des fonctionnalités d’une application sans se poser celle de leur mise en œuvre avec diverses techniques de dialogue.

32En fait, définir des besoins à partir de l’activité et les transposer dans un modèle informatique consiste à viser la qualité de la future interaction en terme d’utilité. Ainsi, par cette démarche nous ne mettons pas en avant telle modélisation de l’activité ou telle modélisation informatique, mais nous insistons bien plus sur le processus de transformation qui va permettre de passer d’une observation et d’une analyse de l’activité en situation à un diagnostic d’aide qui aboutira à une inscription infor­matique en terme d’utilité.

33Le deuxième point de notre retour d’expérience porte sur l’importance de la modélisation dans la définition de l’utilité d’une application. Avec la Figure 5 ci-dessous, inspiré de celle de Haué (2003), nous disons que la phase de spécification telle qu’abordée correspond à aller progressive­ment du monde de l’utilisateur à celui de la machine en passant par un processus d’abstraction. Dans le cas de la spécification, le modèle des besoins utilisateurs (dans notre exemple, un modèle de tâches) est un modèle pivot construit progressivement sur les bases de l’activité et qui permet ensuite une inscription numérique de ces besoins. C’est ce modèle pivot qui est le point central, incarnant la conception centrée sur l’activité en phase de spécification. C’est aussi ce modèle pivot qui est le lieu de la coopération étroite entre ergonome et informaticien.

34La modélisation, en tant que moyen permettant de définir l’utilité, présente donc plusieurs caractéristiques :

• Elle est un outil de l’ergonome et de l’informaticien ;

• Elle est pragmatique tant du côté de l’ergonomie que de l’informatique. En ce qui concerne la modélisation de l’activité, il ne s’agit pas de rechercher la perfection modélisatrice mais de proposer une description suffisamment organisée et systématique. De plus, elle est économi­que car, comme nous l’avons vu, elle ne cherche pas à rendre compte de toute l’activité mais seulement de la dimension la plus utile à cette phase du processus de conception (organisation dynamique de l’activité) ;

• Elle permet de définir les règles de passage et de transformation d’un modèle à l’autre ;

• Elle permet de porter la coopération des acteurs de la conception.

35Notre pratique en phase de spécification d’un système interactif aboutit ainsi à articuler connais­sance de l’activité humaine et monde de la machine dans un cadre formel qui n’écrase pas les diffé­rences entre ces deux univers de connaissance (l’homme et la machine). Cette élaboration résulte d’une connaissance de l’activité qui permet de construire un diagnostic d’aide : la définition du couplage structurel asymétrique d’aide (voir 3.1.) vise ici l’utilité et la modélisation est le moyen mis en avant pour y parvenir.

36Pour revenir aux besoins de l’entreprise, nous pensons qu’en ancrant l’utilité dans la phase de spéci­fication et en posant les bases de l’articulation à l’activité humaine, nous avons ainsi posé les fonde­ments solides et pérennes dont avaient besoin ces gros projets informatiques.

4. Fin du XX^e siècle : de l’utilisabilité pour concevoir une interaction Homme-Machine grand public

37Le contexte est tout autre quand, vers la fin des années 1990, nos activités passent de l’informatique scientifique à la conception d’outils et produits pour les activités commerciales d’EDF. L’utilisateur final n’est plus l’ingénieur d’étude ou le chercheur mais le client d’EDF et les salariés EDF tra­vaillant directement en contact avec les clients (services commerciaux, services techniques, …). Nous passons de la conception d’applications ciblant de toutes petites populations à des applications informatiques où les utilisateurs peuvent se compter en centaines de milliers. La naissance des sites WEB est une bonne illustration de cette tendance avec, par exemple, la conception de sites permet­tant à des utilisateurs de bénéficier d’une relation permanente, personnalisée et interactive avec EDF. Il en est ainsi de l’Agence en Ligne dédiée à la clientèle des particuliers ou de Di@lège, le site dédié aux collectivités locales. Continuités et ruptures qualifient bien cette orientation de notre acti­vité vers un très large public :

• Continuité car nos acquis méthodologiques s’avèrent adaptés à ce nouveau type de probléma­tique. La construction de l’utilité, telle que présentée en phase de spécification, a été détermi­nante pour l’élaboration des sites Agence en Ligne et Di@lège.

• • 9 Ce terme est défini par la norme ISO 9241-11 et signifie qu’un produit doit pouvoir être utilisé pa (...)

  Rupture pourtant car il devient prioritaire de permettre à un public non professionnel et sans formation d’utiliser facilement une application (utilisabilité9). Si nous étions d’accord sur le fait de concevoir une application « intuitive », « conviviale », nous devions être plus précis pour porter la construction de l’utilisabilité.

38Pour aborder cette question de l’utilisabilité, nous produirons une description précise de l’activité qui servira de base à la construction d’un diagnostic ergonomique qui, à son tour, serra à la base de la conception du dialogue du futur site internet. Pour aborder ce processus de transformation, nous distinguons donc les sous-parties suivantes :

• La question de l’utilisabilité ;

• La description de l’activité en vue de définir l’utilisabilité ;

• De l’activité à la définition des principes de dialogue ;

• Synthèse : modéliser pour définir l’utilisabilité d’une application.

4.1. La question de l’utilisabilité

39La question de la facilité d’utilisation des applications interactives, et plus spécifiquement de la faci­lité d’utilisation du dialogue d’une interface, n’est plus tout à fait une question nouvelle dans les années 1994-2000. Au-delà des guides de styles définis par les constructeurs informatiques (APPLE évidemment, mais aussi le CUA IBM, « Motif » de HP et bien sûr Windows), une large littérature existe dans ces années-là sur les recommandations ergonomiques pour le dialogue des interfaces. Par exemple, Scapin (1986) puis Bastien et Scapin (1993) proposent des recommandations permet­tant d’organiser et d’évaluer le dialogue des interfaces. En réalité, ces années vont être le cadre d’une explosion de ce type de recommandations et Vanderdonckt (1994) en recense plus de 3000 tandis que Bastien, Leulier et Scapin (1998) s’appuient sur plus de 800 recommandations pour en proposer une déclinaison plus spécifique pour le WEB. Les organismes officiels ne sont pas non plus en reste et le groupe de travail de l’AFNOR, dont l’une des spécificités est d’être composé d’ergonomes et d’informaticiens, structure en partie ses travaux autour de critères ergonomiques pour l’évaluation de logiciel (AFNOR 1988 et 1991). Ce groupe de travail rejoindra par la suite celui plus international préparant la publication de la norme ISO 9241 comprenant plusieurs parties sur le sujet (voir la norme ISO 9241 de 1996 à 1999, les parties 10 à 17). Cette facilité d’utilisation a fini par être nommé « utilisabilité ». En effet, la notion d’utilisabilité semble peu présente dans les années 80 et le congrès HCI’86 sur le thème « Design for usability » paraît précurseur en la matière. Par contre, cette notion devient incontournable dans les années 90 plus particulièrement avec la généralisation de l’utilisation du WEB (voir par exemple les congrès HCI’1991 et HCI’2000 ; Tho­vtrup, & Nielsen 1991 ; Nielsen, 1993). A compter de cette époque, l’utilisabilité ne concerne plus seulement des populations professionnelles et formées mais s’étend à un grand public pour lequel les formations sont la plupart du temps inexistantes. Des publications très pragmatiques destinées aux concepteurs apparaissent avec pour visée la conception de la simplicité d’utilisation des sites WEB (par exemple, Nielsen, 2000 ; Mander, & Smith, 2002).

• Les recommandations visent une certaine universalité, mais elles ne permettent pas de répon­dre à une situation spécifique de conception. Une solution de dialogue doit pourtant apporter une réponse spécifique à une situation particulière. Par exemple, pour un intranet métier, il est indispensable de proposer une organisation hiérarchique des données qui s’appuie très con­crètement sur les logiques métier de l’utilisateur. La connaissance de l’activité est le moyen qui nous permet de passer de l’universalité au spécifique.

• Les recommandations ne nous apportent pas de réponses sur la façon de produire un tout cohérent et facile d’utilisation. L’homogénéité, la concision, la flexibilité etc., sont des recommandations utiles (elles correspondent à un fond de connaissance nécessaire), mais elles sont générales et seulement pertinentes quand elles sont prises une à une. Par contre, concevoir un dialogue revient à définir une cohérence d’ensemble qui devra être spécifique, c’est-à-dire adaptée à une situation (professionnelle ou non professionnelle) et à une popula­tion cible.

• Les recommandations portent essentiellement sur les éléments de dialogue, mais la facilité d’utilisation va dépendre pour une partie de la cohérence d’une construction articulant la con­tribution de l’ergonomie, du design et du rédactionnel. Si nous prenons l’exemple d’un site Internet, l’entreprise doit porter au travers de son site des logiques différentes (logique marke­ting, logique de marque, logique d’utilisation, …) et au final, la solution de dialogue qui sera mise en ligne doit correspondre à un tout cohérent dans lequel tous ces messages sont parfai­tement intégrés.

4.2. Description de l’activité en vue de définir l’utilisabilité

42« L’analyse de l’activité a-t-elle sa place dans l’élaboration de la facilité d’utilisation ? » était la question que nous posions (Haradji, 2003). Nous répondons à cette question par l’affirmative car nous considérons que c’est le moyen permettant de décrire les dynamiques d’interactions qui sont les plus adaptées à un utilisateur en situation. L’analyse de l’activité en vue de concevoir un dialo­gue informatique a deux finalités complémentaires :

• Définir les regroupements et enchaînements de dialogue qui sont significatifs pour l’utilisa­teur (structuration d’un plan pour un site, regroupement d’un ensemble de tâches dans un même espace de dialogue, …). Cette vue sur la cohérence de l’activité, comme nous l’avons vue précédemment (Partie 3.2.), peut s’appuyer sur une analyse de type récit réduit. Une telle analyse, en mettant en avant l’organisation dynamique de l’activité, est un moyen précieux pour définir les regroupements principaux qui seront réalisés dans le dialogue d’une application ;

• Définir des cohérences locales dans le dialogue qui vont permettre de réaliser les actions for­tement dynamiques (par exemple le dialogue permettant de communiquer avec EDF, le dialo­gue permettant de porter la programmation pour un gestionnaire d’énergie, …). Ici l’analyse doit être plus précise et porter sur certains moments de raisonnement pour mettre en évidence les déterminants de sa dynamique. Nous détaillons ci-dessous ce type de questionnement rela­tif à l’activité.

43Ainsi, afin de définir l’utilisabilité, nous cherchons à documenter ce qui est relatif à la dynamique de réalisation de l’activité et plus précisément à mettre en évidence les logiques de raisonnement et d’actions de l’utilisateur. Il ne s’agit plus d’identifier un besoin de l’activité (l’utilité), mais d’indi­quer comment mettre en œuvre ce besoin (l’utilisabilité). Pour illustrer ce type d’attente, prenons l’exemple de la conception d’un site WEB (Agence en Ligne) permettant aux clients de gérer à dis­tance leur contrat et leur relation avec EDF (le site WEB est en ligne depuis 2000). Nous distinguons :

• Un besoin (l’utilité) : Le besoin de communiquer avec l’entreprise EDF sur différents thèmes (facture, modification de contrat, emménagement/déménagement etc.) ;

• Une attente de qualité d’interaction de la part de l’utilisateur : le client a besoin d’être certain des actions qu’il réalise sur le site car ses actions ont des conséquences directes sur l’organi­sation de sa vie au quotidien (ne pas se tromper dans des adresses pour l’emménagement/ déménagement, prendre un rendez-vous …).

44Pour ce besoin, les différentes attentes de l’utilisateur, en terme de logique de raisonnement, sont les suivantes :

• L’utilisateur doit pouvoir contrôler et modifier les différents éléments de sa demande en préparation ;

• L’utilisateur doit pouvoir valider sa demande et bénéficier immédiatement d’un résumé por­tant sur les éléments de sa demande. Il peut revenir sur sa demande pour la modifier, si nécessaire ;

• L’utilisateur peut envoyer ensuite sa demande et il bénéficie immédiatement d’une informa­tion attestant qu’il a bien envoyé une demande à EDF ;

• L’utilisateur doit être tenu informé de la réception de sa demande par EDF ;

• L’utilisateur doit pouvoir suivre l’évolution de sa demande. Il pourra s’agir d’un contact par EDF, d’envoi de document, d’envoi de message etc.

45Ces différentes étapes dans le raisonnement de l’utilisateur peuvent être schématisées comme suit (Figure 6).

46L’analyse de l’activité permet de mettre en évidence les grandes étapes de raisonnement qui vont servir de base à la définition d’un dialogue pour ce type d’interaction.

47L’analyse de l’activité (Haradji, 2003) permet ainsi de définir les logiques d’interaction et de raison­nement que le site doit porter. Les principes de dialogue que nous abordons dans la sous-partie sui­vante sont donc élaborés sur cette base et permettent de définir les règles structurant le dialogue de la future application. Ce sont ces principes de dialogue qui donnent la logique globale d’utilisation de la future application et qui portent la facilité d’utilisation.

4.3. De l’activité à la définition des principes de dialogue

48Une solution de dialogue doit être spécifique car elle doit répondre à une finalité, à une population cible en situation d’interaction et dépend d’un support avec ses possibilités techniques de dialogue (interface WEB, interface tactile, multi modale, …). L’universalité des recommandations ergonomi­ques apporte peu d’aide ici pour définir une réponse adaptée à une situation donnée. C’est pour cela que nous proposons de considérer les principes de dialogue comme le moyen permettant de spécifier une solution qui porte concrètement la facilité d’utilisation.

49La conception, comme l’indique Pinsky (1992), ne peut pas être abordée selon une vision atomiste. Ainsi, la cohérence d’ensemble d’un dialogue n’est pas égale à la somme des solutions locales : il faut donc aborder la question des différents niveaux de cohérence d’une solution de dialogue et celle des règles de son élaboration. Les principes de dialogue, tels que nous les abordons, définissent ainsi toutes les règles structurant le dialogue. Ils correspondent à la construction d’une solution proposant différents niveaux de cohérence pour l’utilisateur.

• Le problème d’interaction pour lequel une solution de dialogue doit être trouvée. Selon notre pratique, il s’agit de trouver un dialogue pour une ou plusieurs tâches (par exemple, comment gérer la communication par mail avec EDF lors d’actions de modifications de contrats) ;

• Le raisonnement de l’utilisateur en situation pour identifier les logiques à favoriser ; (par exemple, comment les utilisateurs raisonnent quand ils veulent modifier leur contrat par internet) ;

• Les contraintes de conception liées, entre autre, au support (par exemple, élaborer un ensemble dynamique de pages WEB pour gérer les modifications de contrat avec le WEB).

51Comme le montre la Figure 7, les principes de dialogue permettent de distinguer différents types d’unités locales de dialogue (cohérences locales) et d’unités globales de dialogue (cohérences globa­les). Sans entrer dans le détail de construction des principes de dialogue et d’explicitation de cette figure (pour cela voir Haradji, Haué, & Suignard, 2002 et Haué, 2003), nous précisons seulement ces deux types de cohérence portés par les principes de dialogue :

• Les cohérences locales correspondent à une logique locale d’actions et de communications. Une cohérence locale correspond à une unité locale de dialogue :. Par exemple, un mécanisme de dialogue spécifique permettant de faire une commande a une dimension locale. La seule finalité de ce mécanisme est de porter l’action pour laquelle il est fait (dans l’exemple de la Figure 8, le dialogue proposé pour un rappel correspond à une cohérence locale) ;

• Les cohérences globales correspondent à des ensembles plus vastes de dialogue qui intègrent différents éléments locaux de dialogue. Une cohérence globale correspond à une unité globale de dialogue et porte plusieurs finalités pour l’utilisateur. A titre d’exemple, la page d’accueil d’un site WEB est un espace type qui correspond à une cohérence globale dans la mesure où elle porte plusieurs finalités (accueil, navigation, plan, …).

52L’explicitation des principes de dialogue aboutit à définir des règles très concrètes de structuration d’un dialogue donné. La copie d’écran ci-dessous (Figure 8) a été utilisée en 1999 pour définir une page type de l’Agence en Ligne. Cette page type porte une cohérence globale car trois finalités sont articulées : une finalité d’aide, une autre de navigation dans les services du site et pour terminer une finalité d’information et d’action (ici relative au rappel).

53L’utilisabilité, telle que nous l’abordons, se construit dans la définition des différents niveaux de cohérences d’un dialogue informatique. Ce sont les principes de dialogue qui en établissent toutes les règles en définissant les différentes unités de dialogue qui permettent de porter l’interaction avec l’utilisateur. Le point important ici est de définir l’ensemble des unités de dialogue sur la base de patterns d’interactions, c’est-à-dire par un moyen d’analyse et de conception établissant une relation explicite à l’activité humaine.

4.4. Synthèse : modéliser pour définir l’utilisabilité d’une application

54Nous avons vu dans la partie précédente que la conception en terme d’aide peut se décliner précisé­ment en ce qui concerne l’utilité. Nous venons de voir qu’il en est de même pour l’utilisabilité. Revenons sur l’utilisabilité et sur la modélisation permettant d’élaborer l’utilisabilité.

55Débutons par l’utilisabilité. Elle est très souvent considérée comme une notion relative à la qualité de l’interaction qui, associée à des critères ergonomiques, permet d’évaluer une proposition de dia­logue. Notre pratique et le retour d’expérience que nous en faisons nous permettent de préciser cette notion dans son rôle de cadre pour la conception de la qualité de l’interaction. Ainsi sur les bases de notre pratique, nous proposons de caractériser la conception de l’utilisabilité comme suit :

• L’utilisabilité, comme l’utilité, se construit à partir d’un processus d’abstraction qui articule modèle de l’activité et modèle pour la conception.

• L’utilisabilité se base sur une connaissance de l’activité qui met en évidence la dynamique de l’activité pour la réalisation de l’interaction. Sur la base de ce type d’analyse, il est possible d’établir un diagnostic d’aide qui porte sur les regroupements et enchaînements de dialogue qui seront les plus pertinents.

• L’utilisabilité s’incarne dans des principes de dialogue qui définissent la cohérence du dialo­gue devant porter la facilité d’utilisation. Ces principes de dialogue correspondent à une solu­tion située car relative à une population, une finalité, une situation d’interactions particulières (celles des futurs utilisateurs) et un environnement technique (par exemple le monde du WEB). La réalisation d’une maquette et sa mise en situation permet d’apprécier l’efficacité des principes de dialogue en termes de facilité d’utilisation.

• L’utilisabilité se définit principalement dans les principes de dialogue, mais elle est en partie le résultat d’une articulation avec d’autres dimensions (le design et le rédactionnel). La cohé­rence d’ensemble d’un dialogue est donc le résultat de l’aboutissement de cette bonne articu­lation entre différents principes de conception (principes de dialogue, principes de design, principes rédactionnels).

• L’utilisabilité est principalement définie, dans le processus de conception, en phase de con­ception du dialogue. L’utilisabilité est un domaine autonome qui porte sur la question du « comment faire » pour réaliser telle action. Ce domaine de questionnement est spécifique, car il correspond à une focalisation particulière sur l’activité humaine et à un questionnement technique également particulier (définir le dialogue d’une application).

56Enfin, revenons sur la modélisation. Elle joue un rôle très structurant dans notre approche de l’utili­sabilité. Ainsi, nous pouvons à nouveau nous inspirer du modèle proposé par Haué (2003) et le décliner pour l’élaboration de l’utilisabilité. Comme le montre Figure 9 ci-dessous, les principes de dialogue sont ainsi positionnés en tant que modèle pivot suffisamment abstrait pour intégrer les caractéristiques d’activité et les visées de conception.

57La modélisation est ici un moyen central pour aborder l’utilisabilité car elle permet :

• d’expliciter les éléments de raisonnement humain nécessaires à l’élaboration du dialogue ;

• d’expliciter les règles de construction d’un dialogue en intégrant la dimension technique ;

• de poser les bases claires d’une coopération entre les différents acteurs participant à la conception du dialogue d’une interface.

58Nous souhaitons ici insister sur la dimension coopération rendue possible par la modélisation. La conception d’un dialogue (par exemple d’un site Internet) doit articuler des objectifs en partie divergents : la modélisation est le moyen pour expliciter les orientations des uns et des autres et per­mettant de produire un tout cohérent. A titre d’exemple, la copie d’écran ci-dessous (Figure 10) cor­respond à une page « plateforme » de l’Agence en Ligne. Cette page plateforme est une page d’orientation dont la caractéristique est de porter des titres longs facilitant la navigation de l’utilisa­teur occasionnel (un menu aurait diminué le nombre de clic mais aurait été moins efficace en terme d’orientation). Ainsi, chacun de ces titres longs est le résultat d’une articulation précise entre le prin­cipe d’orientation (indiquer le nom du service) et le discours d’entreprise. Nous nous sommes mis d’accord avec les sémiologues (dont la mission était d’expliciter le discours de l’entreprise) pour construire ces titres selon des règles précises d’écriture : par exemple, il est important que les mots clés soient mis en évidence en début de phrase pour favoriser la mémorisation.

59De façon plus générale, et en reprenant une terminologie de H. Simon lu par J. Theureau (communi­cation personnelle), nous disons que pour atteindre une cohérence d’ensemble qui intègre les diffé­rents objectifs, il faut dépasser les rationalités limitées de chaque concepteur (ergonomie, design, rédactionnel, technique, …). Nous l’avons fait en explicitant et articulant les différents principes (principes de dialogue, de design, rédactionnel et technique) qui structurent ce site.

60Pour conclure cette partie, et faire le lien avec la partie précédente, il nous semble nécessaire de revenir sur la conception en terme d’aide. De notre point de vue, la conception en terme d’aide n’est pas un « principe philosophique » désincarné, mais correspond à une visée qui se construit à partir des critères de qualité de l’interaction que sont l’utilité et l’utilisabilité. Chacun de ces critères porte une part de la logique d’aide que l’on souhaite impulser et définit un cadre qui permet d’articuler, sur des bases formalisées, activité humaine et orientation technique. L’utilité et l’utilisabilité corres­pondent donc à des briques de base permettant la construction d’un couplage structurel asymétrique d’aide.

5. Nouveau millénaire : Elargissement de nos problématiques et redéfinition de notre pratique à partir des critères de qualité de l’interaction

61Cette quatrième période dans l’évolution de notre pratique est toute récente. Elle résulte d’un élar­gissement de nos problématiques d’analyse et de conception, principalement tiré par l’activité col­lective. Il ne s’agit plus simplement de considérer un utilisateur face à un ordinateur, mais au contraire une situation d’interaction plus complexe prenant en compte des collectifs plus ou moins larges et plus ou moins spécifiques. Ce développement relatif à notre pratique ne pourra pas évidem­ment présenter le même niveau de finalisation que celui que nous venons de présenter. Malgré tout, il est possible d’expliciter les questions nouvelles auxquelles nous sommes confrontés et d’en envi­sager les conséquences sur notre pratique. Pour cela, nous développons les parties suivantes :

• des questions d’analyse et de conception de plus en plus large ;

• une évolution des critères pour la conception ;

• un besoin de critères et de modélisation.

5.1. Des questions d’analyse et de conception de plus en plus large

62L’évolution récente de l’entreprise EDF, du fait de l’ouverture à la concurrence du marché de l’éner­gie, génère une profonde transformation des métiers de l’entreprise (par exemple, ceux liés à la dimension commerciale) mais aussi induit la recherche d’une plus grande efficacité dans le travail. C’est dans ce contexte que doivent être compris les nouveaux projets sur lesquels nous sommes engagés. C’est également du fait de cette évolution de l’entreprise que certaines questions d’analyse deviennent plus stratégiques. Il en est ainsi de la dimension collective dans le travail qui par exem­ple peut permettre une plus grande efficacité de la relation client.

63Cette prise en compte explicite du collectif est une originalité profonde par rapport aux éléments de notre pratique antérieure. Les applications scientifiques et Internet sur lesquelles nous intervenions concernaient principalement une relation entre une personne (un client, un salarié) et une application informatique. Très rarement nos projets visaient une interaction avec un collectif et jamais nous n’avons eu besoin de nous confronter à la description d’une activité collective (par exemple, pour l’Agence en Ligne, nous avons accompagné les évolutions organisationnelles permettant de gérer les courriels clients mais nous n’avons pas eu besoin d’une description très précise du collectif de travail). Avec les nouveaux projets, nous évoluons vers des analyses qui portent sur des acteurs insé­rés dans un ou plusieurs groupes d’acteurs, qui agissent plus ou moins ensemble et qu’il faut aider dans leur dimension individuelle et collective. Nous détaillons maintenant trois problématiques qui illustrent bien cette orientation et qui sont déterminantes pour notre pratique future.

64En premier lieu, débutons par une problématique d’aide à la vie quotidienne à partir d’artefacts auto­nomes, dynamiques interactifs et répartis. Le monde des produits et services, lié à la fourniture de l’électricité, du gaz etc., chez le client est en développement et la description de l’activité de moments de vie quotidienne dans l’habitat devient importante pour permettre de proposer des offres (produits et services) adaptés à leurs usages. Mais comprendre ces moments de vie quotidienne induit de nouvelles questions théoriques et méthodologiques (par exemple, comment rendre compte de la dynamique d’une activité complexe associant des activités finalisées, des activités de loisir, des activités d’éducation, etc.) et ouvre sur une compréhension de l’activité humaine qui est individuelle et collective (la personne et la famille). Parallèlement, de nouveaux artefacts, comme ceux liés à l’informatique diffuse, semblent pouvoir être utilisés comme support pour des services liés à la vie quotidienne (services liés à la gestion d’énergie, à la sécurité, etc.). L’idée principale de l’informati­que diffuse, dont l’un des précurseurs est Weiser (1993), consiste à proposer une informatique qui soit disséminée dans l’environnement de l’utilisateur afin de lui apporter, quand il le souhaite et où il le souhaite, le service dont il a besoin. Cette problématique ouvre sur de nombreuses questions, nous en énonçons deux. La première question concerne l’activité pour laquelle nous devons préciser la notion de contexte pour l’acteur individuel et collectif. En effet, si nous souhaitons qu’un système dynamique, mobile et interactif apporte une réponse pertinente, nous sommes obligés de préciser la notion de contexte pour l’acteur (un service sera pertinent en fonction de ce que fait l’acteur, de son histoire récente, de la dynamique de son activité, de son environnement, de son interaction avec d’autres membres de la famille, …). La deuxième question porte sur la conception d’un système d’intelligence diffuse. Ce type de système correspond, comme l’indique Steels (2002), à un nouveau paradigme de conception. Dans ces conditions, il faut définir de nouvelles bases de coopération pour passer de la description de l’activité à un modèle pour la conception. Notre objectif au final est de mieux comprendre certaines de ces scènes de la vie quotidienne pour permettre une approche anthropocentrée de l’Intelligence diffuse dans l’habitat et, ainsi, dépasser la seule orientation techni­que (Drogoul, & Servat, 2001 ; Haradji, Ferrand, & Li, 2004).

65De plus, nous débutons également une autre problématique portant sur l’aide à la coopération dans des équipes projets. Il s’agit ici d’envisager l’efficacité de nouveaux outils sur les pratiques de tra­vail d’acteurs engagés dans un projet. Une question essentielle porte ici sur la compréhension de la coopération de différents acteurs au sein d’un projet et d’identifier pourquoi, la plupart du temps, ils sont dans une logique de « travailler ensemble séparément » (Crépeau, 2001). L’entreprise numéri­que affiche très souvent des visées de plus grande efficacité et les outils sont souvent annoncés comme un moyen pour y parvenir. Mais ces « machines à coopérer » comme l’indique Faveaux (2004) aboutissent très souvent à une mise en commun de compétences plus qu’à une construction collective de savoirs. Cette problématique oriente notre travail vers la compréhension des formes de coopération dans un projet à un instant t, mais oriente également sur la capacité d’apprécier une évo­lution de l’efficacité de la coopération. Ainsi, la question centrale sera celle de l’efficacité des outils dans la construction et l’évolution de la coopération dans un projet. Il ne sera pas suffisant de dire qu’un outil améliore la coopération, mais il faudra démontrer que les pratiques de coopération sont plus efficaces et qu’elles sont durables (c’est-à-dire dépassant le seul cadre d’une expérimentation).

66Enfin, nous sommes engagés dans une problématique de transformation d’un ensemble technico­organisationnel et humain dédié à la relation de service. Une entreprise comme EDF évolue en per­manence en terme d’organisation, d’outil, de métier en recherchant toujours le meilleur équilibre entre l’efficacité de l’entreprise et la qualité de service auprès de ses clients. Cette problématique de la relation de service (Gadrey, 1994 ; Cerf, Vallery, & Boucheix, 2004) renvoie directement à la coopération des différents acteurs faisant vivre ce service, qu’il s’agisse des acteurs de l’entreprise ou du client. Mais cette coopération d’acteurs ne peut être isolée de son aspect organisationnel et technique, ce qui fait dire à Girin (2001) que la qualité de service doit aborder des « agencements organisationnels », c’est-à-dire « une combinaison de ressources hétérogènes capables de réaliser une certaine performance ». Cette orientation pousse d’emblée à envisager la coopération dans la relation de service au-delà de l’interaction immédiate, du moment, entre l’agent et le client. Elle vise à intégrer le reste du travail qui se fait le long de la chaîne, entre le front office et le back office, c’est-à-dire avec les autres acteurs et autres entités qui portent le service. Cette coopération passe nécessairement par l’optimisation des « agencements technico-organisationnels » à l’échelle « micro » (en agissant sur la compétence des agents et celles des clients, sur les outils à disposition des agents et du client, sur les coopérations entre acteurs d’une même entité) mais aussi à l’échelle « macro » (pour favoriser les relations fonctionnelles entre les divers acteurs concernés, les différen­tes structures et réduire la « rigidification du système global », …) (Bouzit, Motté, & Haradji, 2005). Il s’avère donc nécessaire d’instaurer et d’optimiser un « travail d’articulation » (Grosjean, & Lacoste, 1999 ; Veyrunes, 2004) entre tous les acteurs concernés (y compris le client) pour favoriser l’efficacité et la réactivité de la coopération dans la situation de service.

67Ces trois nouvelles problématiques montrent que la conception de la qualité de l’interaction ne peut donc plus se cantonner à une appréciation d’une relation stricte entre une personne et une machine, mais doit être étendue à une situation beaucoup plus vaste intégrant des collectifs d’acteurs (liés à la vie quotidienne ou à la vie professionnelle), des outils et des organisations. La question des critères de qualité de l’interaction se pose dorénavant pour nous au niveau de ces situations d’interaction plus complexes. C’est donc un cadre plus large de conception qui nous oblige à ré-interroger notre pratique et à évaluer les ajustements que nous devrons réaliser. Nous abordons cette dimension dans la sous-partie suivante.

5.2. Une évolution des critères pour la conception

68Les nombreux travaux relatifs à la dimension collective en milieu professionnel montrent que les critères d’utilité et d’utilisabilité sont adaptés aux problématiques liées à des collectifs (par exemple en terme de fonctionnalités et de moyens d’interaction qui aident le collectif). Nous voudrions plutôt nous focaliser, dans cette sous-partie, sur des limites prévisibles des critères tels que nous les avons abordés.

69Une première limite dans notre approche réside dans le fait que nous avons abordé l’utilité et l’utili­sabilité sans avoir besoin de la notion de contexte pour l’utilisateur : nos modèles pour la conception n’explicitent pas cette dimension. Or, avec l’arrivée d’applications informatiques dynamiques adap­tatives et parfois mobiles, nous devons adapter la réponse du système en terme de fonctionnalité et de dialogue. Par exemple, un contexte utile de présentation d’une information peut être relatif à la pièce dans laquelle je me trouve, au moyen d’interaction présent en ce lieu, à ma présence seule ou pas, à la réalisation d’une activité, ... Pour de tels systèmes, le cadre de conception que représente respectivement l’utilité et l’utilisabilité doit intégrer, comme le suggère Haué (2003), un modèle du contexte.

70Une deuxième limite dans notre approche porte sur le fait que nous ne savons pas comment les acteurs dans le cadre de leur coopération s’approprient leurs outils. En suivant en cela Haué (2003, 2004), nous disons que les situations d’interaction liées au grand public, celles liées à la coopération de différents acteurs dans un projet et celles liées à la relation de service posent une question d’appropriation des outils et de transformation des savoirs et pratiques de ces utilisateurs.

71Une troisième limite dans notre approche est relative à la non prise en compte explicite d’une accep­tabilité individuelle et sociale. Le fait d’agir sur l’activité de personnes insérées dans des collectifs plus ou moins large ouvre directement sur cette dimension de la qualité de l’interaction. Un système de « vidéocommunication » sur le poste de travail peut permettre des coopérations plus efficaces entre acteurs d’un projet, mais cet outil peut aussi être considéré comme inacceptable du point de vue de l’autonomie de l’individu. Il en est de même à une échelle plus large quand sont envisagées les transformations d’un système technico-organisationnel lié à la réalisation d’un service (évolution de métiers, d’outils, d’organisations, …).

72Une dernière limite réside dans la non prise en compte explicite de la dimension émotionnelle dans l’activité. Les situations de vie quotidienne, par exemple celle relative à la sécurité des personnes, comportent des dimensions émotionnelles fortes. Au-delà de ces aspects sensibles, la dimension émotionnelle se retrouve dans le plaisir ou pas que l’utilisateur ressent par l’utilisation d’un jeu, d’un objet, d’un outil et dans la façon dont il envisage l’insertion de cet objet dans sa relation à l’environnement. La relation de service est une situation porteuse d’émotion, par exemple, lorsqu’un commercial est en communication avec un interlocuteur en difficulté financière et/ou sociale. Cette dimension émotionnelle peut être en partie prise en compte dans le fonctionnement des outils, dans l’organisation, les formations métiers, etc.

5.3. Un besoin de critères et de modélisation

74Les critères tels que nous les avons mis en œuvre jusqu’à maintenant apparaissent comme des cadres pour la conception de la qualité de l’interaction. Ainsi, ils doivent définir un périmètre de questions relatif à la connaissance de l’activité humaine et à sa transformation. L’évolution de nos problémati­ques nous amène à envisager une évolution de notre pratique par une évolution qualitative de l’uti­lité et l’utilisabilité (par exemple en intégrant la dimension contexte) mais aussi par l’explicitation de critères qui n’organisent pas encore notre pratique. Nous pensons que ces « nouveaux » critères doivent être mieux définis et qu’ils doivent être précisés autour des questions suivantes :

• Quel point de vue sur l’activité est nécessaire pour documenter un critère ? Nous avons vu que l’utilité et l’utilisabilité ne nécessitent pas le même regard sur l’activité. Nous faisons l’hypothèse que tout nouveau critère doit bénéficier d’un point de vue particulier sur l’acti­vité.

• Quelle logique d’aide est visée pour quelle transformation ? Un critère définit un type d’aide particulier (par exemple, les besoins d’utilité). Tout critère doit ainsi expliciter une visée d’aide. La conception en terme d’aide pour un projet donné consiste donc à mettre en œuvre un ou plusieurs de ces critères en fonction des objectifs d’aide.

• Quels modèles sont nécessaires pour porter un critère ? Nous avons distingué et articulé le modèle de connaissance de l’activité et le modèle de conception. Nous pensons qu’un critère doit se construire à partir d’une articulation de modèles.

• Quelles coopérations sont nécessaires pour aborder un critère ? Nous avons décrit une articu­lation entre ergonomie et informatique pour définir l’utilité et l’utilisabilité mais aussi, pour l’utilisabilité, une articulation avec les principes de design et ceux du rédactionnel. Chaque critère porte intrinsèquement des coopérations différentes en fonction de l’objectif d’aide à atteindre.

• Quelle phase du processus de conception permet de porter le mieux un critère ? Nous avons vu que l’utilité se positionne facilement en phase de spécification et l’utilisabilité en phase de conception de dialogue. Mais un projet comprend d’autres phases comme par exemple celle liée à l’accompagnement du changement (évolution de compétences, d’organisations, etc.). Nous faisons l’hypothèse qu’un critère doit pouvoir se positionner sur au moins une phase d’organisation d’un projet.

75Avec les « nouveaux » critères, l’objet de conception n’est pas seulement la machine mais un ensemble plus vaste intégrant la machine, l’organisation, le métier, … Dans ces conditions, la visée de conception n’est plus l’interaction Homme-Machine, mais la situation d’interaction dans ses extensions spatiale, sociale, émotionnelle et temporelle. Cette ouverture à une plus grande com­plexité de la situation d’interaction nécessite d’articuler différentes contributions (disciplines et rôles dans le projet). Ainsi, nous pensons que différents éclairages relatifs à l’activité humaine devront être explicités et que leur contribution respective devra s’incarner dans un modèle pour la conception (l’architecte porte des plans, l’organisateur porte des schémas organisationnels, etc.). Nous faisons également l’hypothèse que cette démarche de conception passera par un niveau d’abs­traction (le modèle pivot) qui permettra la rencontre des acteurs de la conception.

6. Conclusion

76Ce parcours nous laisse l’impression d’avoir beaucoup évolué dans notre pratique. Les bases fonda­mentales de la conception centrée utilisateur ont été progressivement précisées, du fait d’une articu­lation explicite à l’activité humaine. Au-delà de cette dynamique d’évolution que nous venons de présenter, il nous semble que ce texte peut ouvrir une voie de discussion relative à la conception en terme d’aide.

77Telle que nous l’abordons, la conception vise à définir un couplage structurel asymétrique d’aide à destination d’un ou plusieurs acteurs en situation. De plus, la dimension aide se définit à partir d’un ensemble de critères relatifs à la qualité de l’interaction. Ainsi, dans le cadre de ce couplage asymé­trique d’aide, chaque critère apparaît comme portant une aide spécifique à l’activité humaine. Nous avons vu que l’utilité focalise sur les besoins d’aide pour l’activité, que l’utilisabilité focalise sur la dynamique de l’activité liée aux moyens d’interaction, que l’appropriabilité vise les transformations du savoir pour l’activité, etc. Sur ces bases et en termes de perspectives, nous proposons quatre hypothèses pour aborder la question des critères structurant la conception en terme d’aide.

78La première hypothèse est relative aux différentes dimensions de l’activité humaine auxquels font référence ces critères. Certains de ces critères sont liés à la dimension cognitive dans l’activité, d’autres semblent porter sur la dimension émotionnelle dans l’activité, d’autres encore sur des logi­ques d’acteurs, etc. Cette liste de critères est issue de notre expérience, elle n’est donc pas exhaus­tive et reste à compléter. D’autres critères, très connus en ergonomie, portent sur la pénibilité ou encore sur l’adaptabilité anthropométrique des postes. Ces critères liés à la dimension physique dans l’activité sont-ils de même nature que ceux décrits dans cet article et peuvent-ils jouer le même rôle de cadre pour la conception des situations de travail ou de vie ? Nous faisons l’hypothèse que l’approche en terme de couplage structurel asymétrique d’aide amène donc à transformer les situa­tions, en se basant sur des critères qui visent à favoriser les dimensions cognitives, émotionnelles, organisationnelles, sociales, physiques, etc. de l’activité humaine.

79La deuxième hypothèse vise à identifier des critères fondamentaux. Il nous semble que nous pou­vons nommer critère fondamental tout critère portant sur une dimension de l’activité humaine en interaction avec l’environnement (cognitive, émotionnelle, organisationnelle, sociale, physique, etc.). Un critère porte une aide sur une dimension spécifique de l’activité humaine en vue de favori­ser ce déterminant du couplage structurel.

80La troisième hypothèse porte sur l’existence de critères transverses. Nous pensons que nous pou­vons nommer critère transverse tout critère qui s’appuiera sur plusieurs critères fondamentaux pour être atteint. Par exemple, l’accessibilité (d’un lieu, d’une application) pour une personne ayant un handicap (momentané ou permanent) est un critère transverse. Un critère transverse porte sur une question spécifique (ici le handicap) et va nécessiter d’interroger de façon particulière un ensemble de critères fondamentaux (pour l’accessibilité il faut proposer une réponse construite qui va interro­ger de façon spécifique l’utilité, l’utilisabilité, la pénibilité, etc.). D’autres critères transverses existent et, par exemple, dans le domaine de la conception des jeux, il existe la jouabilité, ou bien encore dans le domaine de la conception automobile nous trouvons l’habitabilité, etc.

81La dernière hypothèse, quant à elle, découle des deux précédentes : la conception en terme d’aide vise à définir un couplage asymétrique d’aide en s’appuyant sur des critères fondamentaux et trans­verses liés à la qualité de l’interaction.

82Cette réflexion sur la conception en terme d’aide structurée autour de critères nous semble ainsi ouvrir sur un programme de recherche technologique que nous pourrions baptiser « ingénierie des situations d’interactions » ou bien encore, pour faire référence à Pinsky (1990), « Technologie des situations d’interactions ». Comme tout programme de recherche technologique en ergonomie, il vise donc à expliciter les conditions d’une bonne articulation entre la connaissance de l’activité humaine et la conception d’une situation d’interaction. Un tel programme ouvre de plus structurellement sur une coopération d’acteurs organisée autour des critères de qualité de l’interaction.

83Ce programme de recherche présente l’avantage en milieu industriel de pouvoir être construit au fil des projets de transformation auxquels nous participons. Il permet aussi, progressivement, d’aller vers une explicitation plus grande des règles de notre pratique. Un peu à l’identique de l’art de l’ingénieur, nous pensons que l’art de l’ergonome se doit d’être construit sur des bases formelles qui favorisent la transmission du savoir et la confrontation scientifique. Nous pensons également que c’est à partir de cette explicitation que le métier d’ergonome peut s’articuler facilement avec les autres acteurs de la conception. Par notre pratique, nous souhaitons donc contribuer à mieux définir l’identité de l’ergonome et faciliter ainsi son positionnement dans la transformation des situations.