• Aucun résultat trouvé

Adaptation de méthodes d’évaluation dans le cadre de la conception d’une application numérique pour un jeune public avec troubles du spectre autistique : étude au cours de la conception et de l'évaluation de l’application çATED au sein d'une ULIS TED

N/A
N/A
Protected

Academic year: 2021

Partager "Adaptation de méthodes d’évaluation dans le cadre de la conception d’une application numérique pour un jeune public avec troubles du spectre autistique : étude au cours de la conception et de l'évaluation de l’application çATED au sein d'une ULIS TED"

Copied!
247
0
0

Texte intégral

(1)

HAL Id: tel-01808379

https://tel.archives-ouvertes.fr/tel-01808379

Submitted on 5 Jun 2018

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Adaptation de méthodes d’évaluation dans le cadre de la

conception d’une application numérique pour un jeune

public avec troubles du spectre autistique : étude au

cours de la conception et de l’évaluation de l’application

çATED au sein d’une ULIS TED

Marine Guffroy

To cite this version:

Marine Guffroy. Adaptation de méthodes d’évaluation dans le cadre de la conception d’une application numérique pour un jeune public avec troubles du spectre autistique : étude au cours de la conception et de l’évaluation de l’application çATED au sein d’une ULIS TED. Environnements Informatiques pour l’Apprentissage Humain. Université du Maine, 2017. Français. �NNT : 2017LEMA3001�. �tel-01808379�

(2)

Marine GUFFROY

Mémoire présenté en vue de l’obtention du

grade de Docteur de Le Mans Université

sous le sceau de l’Université Bretagne Loire

École doctorale :Ecole doctorale 504 CEI – Cognition, Education, Interactions Discipline : Informatique (27)

Spécialité : IHM

Unité de recherche : CREN Soutenue le 07 avril 2017 Thèse N° : 2017LEMA3001

Adaptation de méthodes d’évaluation

dans le cadre de la conception d’une

application numérique pour un jeune

public avec troubles du spectre

autistique

.

Etude au cours de la conception et de l’évaluation de

l’application çATED au sein d’une ULIS TED

JURY

Rapporteurs : Christophe KOLSKI, Professeur des Universités, Université de Valenciennes

Patrick GIRARD, Professeur des Universités, Université de Poitiers

Examinateurs : Nadine VIGOUROUX, Chercheur (CR) CNRS, Université de Toulouse

Carole TARDIF, Professeur des Universités, Etablissement

Directeur de Thèse : Pascal LEROUX, Professeur des Universités, Le Mans Université Co-encadrant de Thèse : Philippe TEUTSCH, Enseignant-Chercheur, Le Mans Université

(3)
(4)

3

Th se de do to at de l’U ive sit du Mai e

spécialité

informatique

présentée par

Marine GUFFROY

pour l’obtention du titre de

Docteur en Informatique et applications

Adaptatio de thodes d’ valuatio da s le ad e de la conception

d’u e appli atio u

i ue pou u jeu e pu li ave t ou les du

spectre autistique.

Étude

au ou s de la o eptio et de l' valuatio de l’appli atio çATED au sei d'u e ULIS

TED

Jury

Rapporteurs : Christophe KOLSKI, Professeur des Universités, Université de Valenciennes Patrick GIRARD, Professeur des Universités, Université de Poitiers

Examinateurs : Nadine VIGOUROUX, Chercheur (CR) CNRS, Université de Toulouse

Carole TARDIF, Professeur des Universités, Université Aix Marseille

Directeur de Thèse : Pascal LEROUX, Professeur des Universités, Université du Maine

(5)
(6)

5

Remerciements

Je remercie Pascal Leroux, mon directeur de thèse et Philippe Teutsch, mon co-directeur de thèse, pou avoi assu l’e ad e e t de ette th se et pou ’avoi aid e à a u i la igueu scientifique tout au long de ces années de recherche.

Merci également à la société SII et ses directeurs Guy Bonvalet et Charles Mauclair pour avoir accepté de participer à cette aventure.

Je remercie mes collègues de SII qui ont participé de près ou de loin à ce projet. Ils ont permis la o e alisatio de l’appli atio et o t appo t s leu s ega ds p ofessio els.

Mes e e ie e ts vo t à l’ ole la Tilleulière aux Sorinières, à Véronique Le Dour, l’i stitut i e, à Aud e Be tho et Evelyne Delpierre, les AVS, ainsi qu’au enfants pour leur enthousiasme et leur implication. Ils ont rendu possible ce projet.

Je voudrais e e ie les e es du C‘EN d’avoi pe is la alisatio de e superbe projet et d’avoi o t leu i t t et soutie . Un merci, en particulier à Cendrine Mercier, qui a réalisé sa th se e pa all le de la ie e et ave ui j’ai eu des dis ussio s fructueuses et amicales tout au long de cette thèse.

Je remercie Christophe Kolski, Patrick Girard, Nadine Vigouroux et Carole Tardif d’avoi a ept d’ t e e es de o ju de th se.

Je e e ie l’e se le des e seig a ts ue j’ai eu la ha e d’avoi depuis mes premiers jours su les a s de l’ ole à aujou d’hui. Ils ’o t do e la soif de savoi et offe t u e du atio ui ’a pe is d’a outi à ette th se.

Je tiens à remercier ma famille et mes amis pour leur présence et leur soutien.

J’ad esse e fi u g a d e i à toutes les pe so es ue j’ai ôto es et ave ui j’ai olla o tout au lo g de ette th se, pou avoi pa ti ip , ha u e à leu a i e, à l’a outisse e t de e travail.

(7)

6

Table des matières

Introduction ………..….11

Genèse du projet çATED-Autis e………... Co te te de e he he………..……….…10

O je tifs de e he he……….16

Démarche de recherche et uestio e e t………16

Pla de th se………..

Chapitre 1 : La conception et

l’évaluation d’une application nu érique ………....19

1 La conception centrée utilisateur ... 21

1.1 Présentation générale ... 21

1.2 La norme ISO correspondante ... 23

. L’app o he Agile ... D oule e t d’u p ojet ... 28

2.1 La phase de recueil de besoins ... 30

. La phase de da tio du ahie d’e ige es fo tio elles ... 35

2.3 La phase de développement ... 37

. La phase d’ valuatio ... 37

2.5 La mise en production et la mise à disposition ... 39

3 Bilan sur les méthodes et techniques citées ... 39

Conclusion du chapitre 1 ... 40

Bibliographie du chapitre 1 ... 41

Chapitre 2 : Un public spécifique : le jeune public avec TSA

……….47

L’autis e et les TSA ... 49

1.1 Définitions et classifications ... 49

1.2 Le diagnostic et les symptômes ... 53

1.3 À retenir ... 60

P ise e ha ge, a o pag e e t et solutio s d’aide e ista tes ... 60

2.1 Exemple de méthodes dites globales et de méthodes de communication ... 60

2.2 Prise en charge pédagogique ... 64

2.3 Prise en charge transversale ... 67

2.4 Synthèse sur ce public ... 67

Le appo t de e pu li ave l’i fo ati ue ... 68

3.1 Accueil du numérique par le public avec TSA ... 70

. Les tudes alis es autou de l’outil ulti-touch pour le public avec TSA ... 72

. L’usage du ta tile dans le cadre scolaire ... 73

3.4 Premier bilan sur les usages du numérique pour le public avec TSA ... 74

4 Les applications existantes ... 75

4.1 Communication ... 75

4.2 Interactions et scénarios sociaux ... 76

(8)

7

4.4 Compétences motrices ... 77

4.5 Perception visuelle ... 78

4.6 Programmes éducatifs ... 78

4.7 Retours existants sur ces applications ... 79

Conclusion du chapitre 2 ... 80

Bibliographie du chapitre 2 ... 80

Chapitre 3 : Prise en compte des particularités du jeune public avec TSA dans la conception

d’un outil nu érique - Adaptation des éthodologies de conception et d’évaluation………85

1 Prise en compte du public dans les méthodologies de conception et d’ valuatio ... 8

1.1 Quelle méthodologie de conception utiliser ? ... 88

. Quelles thodes et te h i ues de o eptio et d’ valuatio possi les pou le public avec TSA... 90

1.3 Problématique de recherche ... 95

2 Les interlocuteurs médiateurs ... 96

2.1 Identification des interlocuteurs médiateurs ... 97

2.2 Médiateur lors du premier recueil ... 97

. M diateu lo s de la phase d’ valuatio ... 98

U e aît ise d’ouv age adapt e ... 99

3.1 Un savoir-faire adapté ... 99

3.2 Un savoir-être adapté ...100

U e se le d’a teu s à diff e ts o e ts du p ojet ... 101

5 Intégration des interlocuteurs médiateurs dans la conduite du projet ...101

5.1 La phase de recueil ... 103

. Les phases d’ valuatio , de e ueil de etou s et de validatio ... 104

Conclusion du chapitre 3 ... 109

Bibliographie du chapitre 3 ... 110

Chapitre 4 : Mise

en œuvre de la proposition de méthodologie d’évaluation………113

Cad e de la ise à l’essai ... 115

. L’appli atio valu e ... 5

1.2 Contexte de la mise à l’essai : l’ULIS TED ... 118

1.3 La MOA ... 122

1.4 Positionnement des acteurs dans la démarche de conception ... 123

D oule e t de la ise à l’essai ... 125

2.1 Mise en confiance avec les enfants (de mars à avril 2014) ... 125

. Mise à dispositio des ta lettes et de l’appli atio ai 0 ... 125

. Évaluatio de l’appli atio çATED de ai à jui 0 ... 127

2.4 Développement (de juillet 2014 à mars 2015) ... 137

. A tivit a e e : da tio du ode d’e ploi ... 137

. Évaluatio de la ouvelle ve sio de l’appli atio çATED (de mars 2015 à juin 2015) ………... 3 Conclusion... 142

(9)

8

. L’appo t des diff e ts a teu s ... 142

3.3 Bilan ... 146

Chapitre 5 : Bilan et mise en perspectives

……….147

1 Bilans de la proposition scientifique ... 149

1.1 Bilan sur les méthodes et techniques existantes ... 149

. Bila su la p opositio de thodologie d’ valuatio ... 151

2 Limites ... 153

2.1 Différence entre les points de vue des utilisateurs et des interlocuteurs médiateurs ………... 153

2.2 Investissement des différents acteurs ... 153

2.3 Une MOA au-delà de ses compétences ... 153

2.4 Place de l’i te ve a t MOA da s les it atio s suiva tes ... 154

. ‘e ouvele la ise à l’essai ... 154

3 Observations supplémentaires ... 154

3.1 Une meilleure autonomie ... 154

3.2 Un outil médiateur ... 155

3.3 Meilleure communication et ouverture sur les autres ... 155

3.4 Une meilleure inclusion des nouveaux élèves ... 156

4 Perspectives ... 156

. ‘e ouvelle e t de la ise à l’essai ... 156

4.2 Vérification de la nécessité de la présence de la MOA in situ ... 156

4.3 Recueil initial de données en trépied ………... 157

4.4 Transposition de la thode d’ valuatio p opos e à u aut e pu li ... 5 Bilan de la thèse ... 158

5.1 Un projet de R&D entre monde industriel et monde universitaire ... 158

5.2 Un projet pluridisciplinaire ... 158

6 En guise de conclusion ... 159

Références bibliographiques

………..……….…161

(10)
(11)
(12)

11

Introduction

(13)

12

Nos travaux de recherche se situent dans le domaine des interactions hommes-machines (IHM). Plus p is e t, ous ous i t esso s à l’adaptatio des thodologies de o eptio et d’évaluation à u pu li sp ifi ue. Da s ot e as il s’agit d’u jeu e public scolarisé avec TSA (Troubles du Spectre Autistique ui p se te e t e aut es des diffi ult s de o u i atio et d’i te a tio s sociales. La pla e de l’IHM da s la o eptio d’outil ’est plus à p ouve . Elle pe et notamment de mieux prendre en co pte l’utilisateu et ses esoi s (Kolski, Ezzedine, & Abed, 2001).

Ce hapit e d’i t odu tio présente tout d’a o d la genèse du projet puis le contexte dans lequel s’i s it ot e e he he. Nous d gageo s e suite la p o l ati ue générale et décrirons les objectifs de recherche. Enfin nous présentons notre approche méthodologique et le plan général de la thèse.

Genèse du projet çATED-Autisme

En classe, les élèves avec TSA utilisent des pictogrammes (images sur des cartes) pour schématiser les tâ hes u’ils o t à alise . Ces pictogrammes sont associés à un time timer (minuteur mécanique représentant visuellement le temps) pou illust e le te ps u’il este pou effe tue u e tâ he. Cependant les pictogrammes présentent quelques inconvénients. Ils nécessitent du temps de fabrication, prennent de la place (il est commun que les pictogrammes soient rangés dans des valises ou des g os lasseu s , s’a i e t apide e t (étant donnée la manipulation quotidienne), et enfin ne sont pas facilement modifiables.

Parallèlement, les tablettes tactiles sont appréciées par ce public. Le côté stable, patient et prévisible de semble pouvoir intéresser le public TSA. De plus ces appareils permettent une forte pe so alisatio via le hoi de fo d d’ a , l’age e e t des appli atio s, ou encore la dispo i ilit de l’appa eil photo. C’est de e o stat u’est , e 0 le p ojet çATED-Autisme, fruit de la olla o atio de l’U ive sit de Na tes et du Maine, l’ESPE, le CRA (Centre de Ressources Autisme) des Pays de la Loire et la société de service en informatique SII Nantes, a permis en 2011 la atio de la p e i e ve sio de l’appli atio çATED. Le premier objectif du projet fut de transposer un outil existant sur papier vers une application sur support mobile.

Figure 1 - Organisation du projet çATED-Autisme

Recherche clinique

• CRA des Pays de la Loire (Centre Ressources Autisme) • CHU d'Angers

• Univeristé d'Angers

Recherche en Sciences de l'éducation

• Université de Nantes

• ESPE (Ecole Supérieure du Professorat et de l'Education) • CREN (Centre de Recherches en Education de Nantes)

Recherche et développement en Informatique (CIFRE)

• SII Nantes • Université du Maine • CREN

(14)

13

Image 1 - Écran principal de l'application çATED (version 2013)

L’appli atio çATED pe et de er un agenda visuel sur tablette via la gestion de tâches, représentées par un nom, une image et un son. Une fois créées, les tâches sont assemblées dans un agenda personnel et quotidien. Sur l’ a p i ipal de l’appli atio (Image 1), l’utilisateu peut visualiser les tâches précédentes et suivantes, ainsi que, au centre, la tâche courante à laquelle est liée un time timer permettant de visualise le te ps u’il este ava t la fi de la tâ he.

Co stata t le su s de l’appli atio et les etou s des utilisateu s, l’ uipe a d id de poursuivre le projet en 2013 par le lancement pluridisciplinaire selon trois axes :

- recherche clinique ;

- e he he e s ie es de l’ du atio ; - projet R&D.

La e he he li i ue s’i t esse à l’app op iatio de la ta lette et à la atio d’u guide de o es pratiques à destination des pa e ts. L’e jeu de la e he he e s ie es de l’ du atio est l’ tude de l’app op iatio de çATED da s l’a s au app e tissages et le d veloppe e t de la o u i atio sociale des enfants avec autisme.

Le projet de R&D en informatique, a pour but de cr e u e ouvelle ve sio de l’appli atio tout e se confrontant aux problèmes de conception et d’ valuatio d’u e appli atio u i ue su tablette liés au public cible, un jeune public scolarisé avec TSA. C’est à ce dernier aspect que les travaux de reche he s’i t esse t. Ce t avail fi ie d’u fi a e e t p iv de la so i t SII Nantes via une thèse CIFRE (Convention Industrielle de Formation par la REcherche). Le partenariat e t e les ilieu i dust iel et u ive sitai e pe et de fi ie de l’expertise de chacune des parties via une collaboration étroite.

(15)

14

Au sein du laboratoire pluridisciplinaire CREN (Centre de Recherches en Education de Nantes), le projet çATED-Autisme fait partie des projets de recherche de l’a e , Analyse de l'activité, formation,

professionnalisation et médiation numérique.

Contexte de recherche

Depuis plusieurs années, les familles, spécialistes et éducateurs encadrant les enfants avec TSA ont observé un intérêt grandissant de ces derniers pour le matériel informatique. Une relation positive entre ce jeune public et les ordinateurs a tout de suite été remarquée. Différents travaux ont été réalisés dans ce sens : l’i fo ati ue e soutie pou diff e tes diffi ult s ue peuve t e o t e le public avec autisme. Par exemple les tudes su l’o di ateu e aide au i te a tio s so iales (Bernard-Opitz, Sriram, & Nakhoda-Sapuan, 2001; Rajendran & Mitchell, 2000) ou encore au langage (Bosseler & Massaro, 2003; Moore & Calvert, 2000) o t e t ue l’i fo ati ue p se te u e relation stable, patiente et prévisible qui convient parfaitement aux particularit s de e pu li . L’outil i fo ati ue pe et de p te l’a tio à l’ide ti ue, d’a lio e le sultat, il tol e l’e eu (Murray, 1997).

Toutefois l’utilisatio du lavie et de la sou is ’est pas si si ple et e tai s pa e ts t oig e t, expliquant que lors des séances sur les machines, les enfants ont tendance à montrer les choses à l’ a . Da s e as, ’est souve t l’e adrant qui manipule la souris.

L’appa itio des s a tpho es puis des ta lettes, a pe is à la fin des années 2000 de minimiser la taille des appareils mais a également permis de modifier les interactions possibles des utilisateurs avec les systèmes en per etta t d’i te agi du out des doigts. Le ta tile est souve t ualifi de plus si ple d’utilisatio , l’a gu e t ta t ue la a ipulatio est plus « naturelle ». Les interfaces rendues plus directes et plus intuitives, facilitent l’utilisatio de l’appli ation et permettent ainsi une plus grande concentration.

Les pa e ts d’e fa ts avec TSA apprécient les applications leurs permettant de communiquer avec leur enfant, ce qui permet, à ce dernier, de se fai e o p e d e, d’i di ue e u’il souhaite et de fai e u pas ve s l’auto o ie. La taille de ce type de matériel est lui aussi apprécié car contrairement aux précédents ordinateurs de bureaux et portables, les smartphones et tablettes sont facilement transportables, aussi bien en visite dans la famille que da s les salles d’atte te de de i s.

Il est do i t essa t d’ tudie la atio d’appli atio s su es suppo ts pou e t pe de pu li s spécifiques. Les tablettes et smartphones étant transportables facilement, ils pourraient devenir des aides quotidiennes et soutenir ce public dans leur autonomisation.

Nous nous intéressons plus précisément au thodologies de o eptio et d’ valuatio d’u e application sur tablette tout en tenant compte des spécificités de notre public, un jeune public scolarisé avec TSA.

(16)

15

Notre recherche se trouve à l’i te se tio de deux grands domaines de recherche (figure 2) : - La atio d’u e appli atio i fo ati ue (aspect ingénierie et informatique) :

Il existe classiquement un ensemble de méthodes et de concepts approuvés et conseillés pou o evoi u outil i fo ati ue et l’ value . La o eptio e t e utilisateu s est pa exemple conseillée, elle permet de pla e l’usage au e t e du p o essus e ha gea t ave lui à diff e ts o e ts du p ojet afi u’il valide le t avail de alisatio e ou s. - Le public spécifique et son environnement (aspect sciences humaines) :

Les méthodes citées ci-dessus sont appli a les e l’ tat si l’utilisateu e p se te aucun handicap ais ela ’est pas toujou s le as. Nous ous i t esso s i i à u pu li pa ti ulie , le jeune public scolarisé avec TSA. Celui-ci présente entre autres des difficultés dans les domaines de la communication et des interactions sociales. Hors une grande partie des thodes de o eptio et d’ valuatio s’appuie su l’ ha ge et do la o u i atio . U e tude du pu li est do p i o diale afi d’ide tifie ses apa it s et diffi ult s. Afi d’y pa ve i l’ tude de l’utilisateu lui- e est i po ta te ais gale e t l’ tude de so environnement.

Notre approche méthodologique générale est pluridisciplinaire, au centre de deux grands domaines ue so t l’i fo ati ue et les s ie es hu ai es. Elle s’i s it plei e e t da s le do ai e de l’IHM. Cette pluridisciplinarité de retrouve également dans les organismes dans lesquels les travaux de

ette th se se d oule t, l’e t ep ise et le la o atoi e u ive sitai e o te te de la CIF‘E ai si u’u e ULIS TED (Unité Localisée pou l’I lusio S olai e d’e fa ts ave T ou les E vahissa ts du Développement) où pendant 18 mois nous avons mis à l’essai ot e p opositio .

Méthodologie de conception et d’évaluation d’une application dédiée à un public spécifique Autisme / TSA, prise en charge et scolarisation Autisme / TSA et nouvelles technologies Conception centrée utilisateurs Evaluation C atio d’u e

application informatique Public spécifique et son environnement

(17)

16

Objectifs de recherche

Au d ut de ot e p ojet, e 0 , ous disposio s de l’appli ation dans sa version initiale. Nous souhaitio s u’à la fi de ot e p ojet ette appli atio o espo de au ieu au esoi s des enfants scolarisés avec TSA. Notre volonté était que cette application soit utilisable et utile. Pour ce faire nous avons eu besoi d’ value l’appli atio e ista te, de e ueilli les etou s et ve tuels nouveaux besoins des utilisateurs avant de développer une nouvelle.

Le public cible est jeune et présente des difficultés de communication et de relations sociales, il ne peut pas exprimer ses besoins et retours. Nous posons comme hypothèse que le recueil de besoins et retours ’est pas o plet s’il ’est alis u’ave les utilisateurs finaux. Cependant la littérature (Monibi & Hayes, 2008; Muñoz, Barcelos, Noel, & Kreisel, 2012) s’a o de su le fait ue alg es contraintes une démarche de conception participative centrée sur les utilisateurs est possible. Cette recherche vise à proposer une méthodologie de conception et évaluation adaptée dans le

ad e de la atio d’u e appli atio su ta lette d di e à u jeu e pu li ave TSA. Cette proposition repose sur différents aspects :

- la p ise e o pte du o te te et de l’e vi o e e t du pu li ;

- la s le tio , l’adaptatio et la o i aiso des thodes de o eptio lassi ues ;

- la p ise e o pte des diff e ts t pes d’a o pag ateu s p se ts da s l’e vi o e e t des jeunes avec TSA. Ceci afi d’all ge la ha ge de t avail pou le pu li fi al ais également de compléter les informations fournies par ce dernier.

Démarche de recherche et problématique de recherche générale

Nos t avau po te t su la o eptio et l’ valuatio d’u e appli atio d di e à u jeu e pu li scolarisé avec TSA.

Tout d’abord, il est nécessaire de connaître le contexte général dans lequel se place notre étude. Nous devons, d’u e pa t, identifier les méthodes dont nous disposons pour concevoir et évaluer un outil informatique et, d’aut e pa t, le public pour lequel nous souhaitons créer cet outil.

C’est pou uoi dans un premier temps nous nous intéressons aux thodologies lassi ues, ’est-à-dire les méthodes qui fonctionnent dans une cadre « ordinaire » où les utilisateurs ne présentent aucune particularité ou difficulté. Cela nous permet de mettre en évidence un ensemble de méthodes que nous avons potentiellement à disposition.

Dans u se o d te ps ous ous pe ho s su l’étude du public cible, le jeune public scolarisé avec TSA. Cet état des connaissances nous permet de connaître d’u e pa t les apa it s et li ites du public mais également son quotidien et plus particulièrement le contexte s olai e puis ue ’est da s

e ad e ue s’i s it ot e p ojet.

Le cadre étant ainsi établi, nous pouvons confronter les informations recueillies et mettre en évidence les problématiques auxquelles nous désirons répondre.

(18)

17

Comment faire en sorte que malgré ses

difficultés de communication

, le jeune utilisateur avec TSA puisse

participer

à la

conception

continue de son outil via la phase d’

évaluation

? Un ensemble de méthodes existe pour le recueil de besoins et de retours dans une démarche de conception centrée sur les utilisateurs. Cependant chacune a ses limites. Certaines ne sont pas applicables ou doivent être adaptées pour des publics spécifiques.

Quelles

méthodes et techniques de recueil de besoins

et d’évaluation sélectionner

dans le cas de la conception d’u e appli atio pou u jeu e pu li ave TSA ? Comment les

adapter,

les

compléter

et les mettre en place ?

Nous proposons ainsi une méthodologie de conception et d’évaluation adaptée au jeune public avec TSA s’appu a t su l’adaptatio et la o i aiso de thodes e ista tes ais gale e t su l’e vi o e e t hu ai du pu li . Nous ne sommes plus dans une démarche centrée sur l’utilisateu ais e t e su l’utilisateu et so o te te. Nous ous appu o s su le oise e t de points de vue de différents acteurs présents.

Afi de ett e à l’essai otre proposition méthodologique de conception et évaluation, nous nous so es appu s su l’appli atio çATED. Ai si ous avo s pu alise deu phases d’ valuation, une p e i e su la ve sio i itiale et la se o de su la ouvelle ve sio de l’appli atio , d velopp e grâce aux retours de la première phase. Cette nouvelle it atio de o eptio de l’application a eu lieu au sei d’une ULIS TED (Unité Localisée pou l’I lusio S olai e d’enfants présentant des Troubles Envahissants du Développement) dans laquelle nous sommes intervenus hebdomadairement pendant 18 mois. Cette structure est composée de cinq enfants avec TSA.

Plan de la thèse

Nos t avau s’a ti ule t e i parties.

Le premier hapit e p se te le od le lassi ue de o eptio et valuatio d’u e appli atio numérique (correspondant au cercle Créatio d’u e applicatio i for ati ue de la figure 2). Chaque étape y est détaillée. Les différentes méthodes existantes classiques y sont présentées et discutées. Cette pa tie pe et de d fi i le ad e sta da d d’u p ojet afi de pouvoi pa la suite, dans le t oisi e hapit e, l’adapte au pu li ui ous i t esse i i, soit le jeu e pu li ave TSA.

Le second chapitre (cercle Public spécifique et son environnement de la figure 2) est dédié à la présentation du public avec TSA. Les différentes classifications utilisées par les spécialistes du domaine y sont présentées ainsi que la hiérarchisation des pathologies. Les troubles sont détaillés ce qui permettra dans la suite des travaux de sélectionner les méthodes qui peuvent être utilisées. Ce chapitre présente également l’a o pag e e t do t fi ie e pu li da s les st u tu es scolaires.

Le troisième chapitre confronte les points de vue issus des deux précédents chapitres. Pour chacune des méthodes et techniques citées, nous déterminerons si elles peuvent être mise en place avec le jeune public avec TSA et comment. Nous pourrons ainsi proposer une méthodologie de conception et d’ valuatio adaptée à ce public.

(19)

18

Dans le quatrième chapitre, nous présentons la ise à l’essai de la solutio ue ous p oposons. Dans un premier temps, nous présentons le protocole de la ise à l’essai, puis la structure qui nous a accueillis ainsi que les différents profils des enfants. Enfin nous détaillerons le déroulement de notre intervention.

La dernière partie de la thèse conclut sur ce travail de recherche à différentes échelles. Celle du domaine de recherche, celle du projet çATED-Autisme avec le lien avec les autres axes de recherche ais gale e t à l’ helle de l’e t ep ise ui a a ueilli ette th se. Les limites de la proposition sont également présentées ainsi que les perspectives que laissent entrevoir ce projet.

Bibliographie

Bernard-Opitz, V., Sriram, N., & Nakhoda-Sapuan, S. (2001). Enhancing Social Problem Solving in Children with Autism and Normal Children Through Computer-Assisted Instruction. Journal of

Autism and Developmental Disorders, 31(4), 377‑384. https://doi.org/10.1023/A:1010660502130

Bosseler, A., & Massaro, D. W. (2003). Development and evaluation of a computer-animated tutor for vocabulary and language learning in children with autism. Journal of Autism and

Developmental Disorders, 33(6), 653‑672. https://doi.org/10.1023/B:JADD.0000006002.82367.4f

Kolski, C., Ezzedi e, H., & A ed, M. 00 . C le de d veloppe e t du logi iel : des les lassi ues au les e i his sous l’a gle des i te a tio s ho e-machine. In Analyse et Conception

de l’IHM. I teractio Ho e-machine pour les SI, volume 1 (Hermes, p. 23‑49). Paris.

Monibi, M., & Hayes, G. R. (2008). Mocotos: Mobile Communications Tools for Children with Special Needs (p. 121‑124). Présenté à IDC’08, Chicago (USA).

Moore, M., & Calvert, S. (2000). Brief report: vocabulary acquisition for children with autism: teacher or computer instruction. Journal of Autism and Developmental Disorders, 30(4), 359‑362. Muñoz, R., Barcelos, T., Noel, R., & Kreisel, S. (2012). Development of Software that Supports the

Improvement of the Empathy in Children with Autism Spectrum Disorder. In Chilean

Computer Science Society (SCCC), 2012 31st International Conference of the (p. 223‑228).

https://doi.org/10.1109/SCCC.2012.33

Murray, D. K. C. (1997). Autism and information technology: therapy with computers. Autism and

Learning - A Guide to Good Practice, 100‑115.

‘aje d a , G., & Mit hell, P. 000 . Co pute ediated i te a tio i Aspe ge ’s s d o e: the Bubble Dialogue program. Computers and Education, 35(3), 189‑207. https://doi.org/10.1016/S0360-1315(00)00031-2

(20)

19

Chapitre 1

La conception et

l’évaluation d’une

(21)

20

Table des matières

1 La conception centrée utilisateur ... 21

1.1 Présentation générale ... 21

1.1.1 La phase d’a al se des esoi s ... 22

1.1.2 La phase de conception ... 23

1.1.3 La phase d’ valuatio ... 23

1.2 La norme ISO correspondante ... 23

1.3 L’app o he Agile ... 24

1.3.1 Les acteurs ... 25

1.3.2 Les différents documents et livrables ... 26

1.3.3 Les différentes évènements ... 26

1.3.4 Vue globale de la méthode... 28

2 D oule e t d’u p ojet ... 28

2.1 La phase de recueil de besoins ... 30

2.1.1 Observation directe ... 30

2.1.2 Entretiens individuels ... 31

2.1.3 Groupe de discussion ... 31

2.1.4 Enquêtes et questionnaires ... 32

2.1.5 Modélisation empathique ... 32

2.1.6 Age da d’a tivit s ... 33

2.1.7 Brainstorming ... 33

2.1.8 Scénarios, storyboards, et personas ... 34

2.1.9 Prototype ... 34

2.1.10 Conception coopérative et participative ... 35

2.2 La phase de da tio du ahie d’e ige es fo tio elles ... 35

2.3 La phase de développement ... 37

2.4 La phase d’ valuatio ... 37

2.4.1 Le recueil des retours ... 38

2.4.2 La phase de validation ... 39

2.5 La mise en production et la mise à disposition ... 39

3 Bilan sur les méthodes et techniques citées ... 40

Conclusion du chapitre 1 ... 41

(22)

21

Le projet R&D en informatique çATED s’est d oul da s u o te te d’ingénierie (CIFRE) avec une société partenaire disposant de ses propres méthodes et normes de travail. Le développement de l’appli atio çATED se d oule da s e ad e i pos . Cepe da t la spécificité du public cible a dès le départ questionné l’équipe de conception sur les méthodologies disponibles pour garantir un produit adapté au besoin et à son contexte de mise e œuv e.

Quel que soit sa nature, numérique ou non, un outil est utile et utilisa le seule e t s’il a t ie conçu. S’il e l’est pas, l’utilisateu e peut pas s’e se vi ou ’e o p e d pas so utilit . La conception de l’a tefa t impactera dans tous les as so le de vie. L’ e industrielle est derrière nous. Le taylorisme ’est plus adapt au s h as de o so atio a tuels. Le o po te e t des o so ateu s a volu . Nous e so es plus da s u e d a he d’adoptio pa le a h ais ve s u ph o e d’adaptatio au a h (Fauré, 2015). L’utilisateur final est consulté avant la création des produits. Il intervient plus tôt et plus souvent dans le cycle de conception. Il peut ainsi valider ou invalider le t avail alis pa l’ uipe de o eptio lo s de phases intermédiaires. Les modèles de conception tels que le cycle en V qui propose un schéma linéaire sont handicapant par leur « effet tunnel ». Le p oduit ’est valid u’à la fi du p o essus de atio . U e de a de de modification, pouvant impacter une partie plus ou moins importante du développement, doit être identifiée au plus tôt et non en toute fin du processus. Les coûts de modification se trouvent ainsi diminués.

Ce hapit e s’i t esse plus pa ti uli e e t au phases de e ueil de esoi et d’ valuatio da s u schéma de conception cent e utilisateu da s le as de la atio d’u outil u i ue. U e description des méthodes et techniques génériques existantes pour ces phases est présentée. Chaque technique a ses limites dues aux spécificités du public.

1 La conception centrée utilisateur

L’i po ta e de la p se e de l’utilisateu da s la o eptio d’outil a t ise e vide e depuis de nombreuses années (Norman & Draper, 1986). Mais comment faire intervenir l’utilisateu da s la atio d’u outil et u’e est-il des publics plus spécifiques ? De plus, la généralisation des profils est compliquée pour un public présentant une grande diversité de particularités. L’ tude de ha ue personnalité ne mène pas toujours à une possible généralisation(Moffatt, Findlater, & Allen, 2006) mais offre des perspectives uniques (Fischer & Sullivan, 2002).

Cette première partie présente la conception centrée utilisateur, ainsi que la mani e do t elle s’est imposée dans le monde industriel (norme ISO). Nous présentons également une approche créée et appliquée dans de nombreuses entreprises de développement privées, l’Agilit .

1.1 Présentation générale

La conception centrée utilisateur (CCU) consiste à tenir compte des caractéristiques des utilisateurs, des tâ hes u’ils souhaite t a o pli et du o te te da s le uel es de i es so t a o plies. Elle a pou ut d’a oit e l’utilisa ilit et l’utilit des p oduits. C’est-à-dire permettre de « mieux

(23)

22

attei d e les o je tifs fi s, e appo ta t u e eilleu e satisfa tio des esoi s li s à l’utilisateu et à l’o ga isatio » (ISO 9241-210:2010 - E go o ie de l’i te a tio ho e-système -- Partie 210: Co eptio e t e su l’op ateu hu ai pou les s st es i te a tifs, s. d., ISO 13407:1999 - P o essus de o eptio e t e su l’op ateu hu ai pou les s st es i te a tifs, s. d.).

Figure 3 - Schéma simplifié du cycle de conception centré sur l'utilisateur

La conception centrée utilisateur est un processus itératif composé de trois principales phases : - phase d’a al se des esoi s ;

- phase de conception ;

- phase d’i stallatio et d’évaluation en usage.

Ces phases sont succinctement présentées dans cette partie. Elles seront détaillées dans la partie suivante en p se ta t le d oule e t o plet d’u p ojet.

La plupa t des auteu s s’e te de t su es g a des tapes (Bastien & Scapin, 2003). Cependant ces phases peuvent être décomposées en activités plus précises reposant sur un ensemble de méthodes et techniques que nous décrivons plus bas. Cette décomposition en phases de travail est présentée dans ce chapitre dans la section 2 « D oule e t d’u p ojet »

1.1.1

La phase d’anal se des besoins

La phase d’a al se a pour but de préciser les attentes et les besoins des utilisateurs finaux. Ces de ie s p se te t la tâ he u’ils souhaite t éaliser avec le produit. Cette tâche est présentée dans so e se le, ’est-à-dire le détail de la tâche mais également son contexte de réalisation. Cette phase pe et de p ise l’utilit e he h e pa les utilisateu s de l’appli atio . Les thodes d'observation peuvent comprendre l'utilisation de questionnaires, de grilles d'observation, de focus group. Il est préférable d'ordonner ces besoins et exigences selon leur importance vis-à-vis du produit à développer, et des éventuelles contraintes de faisabilité technique.

Phase d'analyse Phase de conception Phase d'évaluation

(24)

23

1.1.2 La phase de conception

La phase de o eptio s’appuie su des éléments recueillis dans la phase précédente : un premier prototype du produit est conçu. Ce prototype sulte, d’u e pa t, de l’a al se de la tâ he des utilisateurs et des spécificités du contexte de travail et, d’aut e pa t, des principes et recommandations ergonomiques. Cette première maquette évoluera ensuite en fonction des retours de la phase suiva te d’ valuatio . Cha ue it atio pe et d'e i hi et fi alise la a uette.

1.1.3

La phase d’évaluation

La phase d’ valuatio po te su l’utilisa ilit du p oduit ui est valu e, ’est-à-dire la validité de la satisfaction des utilisateurs dans la réalisation des tâches. Parmi les différentes méthodes d'évaluation possibles, la principale est le test utilisateur. Celui- i o siste à pla e l’utilisateu e situatio d’utilisatio elle du p oduit et à o se ve les diffi ult s e o t es. L’ valuatio pe et d’ide tifier les points à améliorer sur la maquette et donc de préparer la version suivante qui sera à nouveau testée et ainsi de suite.

1.2 La norme ISO correspondante

D’ap s le site offi iel, www.iso.org, la norme ISO 9241-210 se définit comme suit.

La conception centrée sur l'opérateur humain est une manière de concevoir les systèmes interactifs, ayant pour objet de rendre les systèmes utilisables et utiles en se concentrant sur les utilisateurs, leurs besoins et leurs exigences, et en appliquant les facteurs humains, l'ergonomie et les connaissances et techniques existantes en matière d'utilisabilité. Cette approche favorise l'efficacité et l'efficience, améliore le bien-être de l'homme, ainsi que la satisfaction des utilisateurs, l'accessibilité et la durabilité, et réduit les effets nuisibles potentiels de leur utilisation sur la santé, la sécurité et les performances.

Il existe un ensemble substantiel de connaissances relatives aux facteurs humains/à l'ergonomie et à l'utilisabilité co cer a t l'orga isatio et la ise e œuvre efficaces de la co ceptio ce trée sur l'opérateur humain. La présente partie de l'ISO 9241 vise à la diffusion de ces informations afin d'aider les responsables de la gestion des processus de conception et de correction des matériels et des logiciels à identifier et à planifier des activités de conception centrée sur l'opérateur humain, de manière efficace et à bon escient.

L’approche de co ceptio ce trée sur l'opérateur hu ai décrite da s la prése te partie de l'ISO 9241 vient en complément des approches existantes de conception des systèmes. Elle peut être intégrée à des approches aussi diverses que des applications orientées objets, des approches en cascade et le développement rapide d'applications.

Les principes de la conception centrée sur l'opérateur humain et les activités connexes n'ont guère été modifiés depuis la publication de l'ISO 13407 et ont été validés par dix années d'application pratique. La présente partie de l'ISO 9241 reflète cet aspect en formulant des exigences et des recommandations.

(25)

24 Les principes de cette norme sont les suivants :

- la conception est fondée sur une compréhension explicite des utilisateurs, des tâches et des environnements ;

- les utilisateurs sont impliqués dans la conception et le développement ;

- la co ceptio est dirigée et précisée par l’évaluatio ce trée sur l’utilisateur ;

- le processus est itératif ;

- la co ceptio couvre l’expérie ce de l’utilisateur da s so i tégralité ;

- l’é uipe de co ceptio i clut des co pétences et des points de vue pluridisciplinaires.

1.3

L’approche Agile

Le o de i dust iel a p is o s ie e de ette essit d’i t g e plus d’hu ai et d’ ha ges dans la alisatio d’u p ojet. L’app o he Agile p opose u s h a de d veloppe e t de p oduits. Les grandes idées de cette approche sont clairement énoncées dans le manifeste1, dig pa l’ uipe fondatrice (Beck et al., 2001) :

Manifeste pour le développement Agile de logiciels

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

-

les individus et leurs interactions

plus que les processus et les outils ;

-

des logiciels opérationnels

plus u’u e docu e tatio exhaustive ; -

la collaboration avec les clients

plus que la négociation contractuelle ;

-

l’adaptatio au cha ge e t

plus ue le suivi d’u pla .

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

L’id e p i ipale est de p opose « un cadre de travail permettant de répondre à des problèmes complexes et changeants, tout en livrant de manière productive et créative des produits de la plus grande valeur possible » Ke S h a e et Jeff Suthe la d, deu des e es de l’ uipe fo dat i e . L’agilit p ô e de g a ds p i ipes :

- satisfaire le client ;

- livrer le produit vite et régulièrement ; - collaborer avec le client ;

- travailler en équipe.

L’id e p i ipale est u’u p ojet e peut pas t e u p o essus p di tif fig . Il est essai e de régulièrement ajuster les besoins et donc les tâches à réaliser tout au long du processus de conception. L’ uipe est alo s fo alis e su u e pa tie li it e et aît isa le des fo tio alit s à réaliser. Le projet est ainsi réalisé vite et bien.

Les trois piliers de cette méthode sont les suivants :

(26)

25

- transparence : avoi u la gage o u e t e l’ uipe et le management afin d’avoi u e bonne compréhension ;

- inspection : faire le point régulièrement sur les différents artéfacts produits ; - adaptation : adapte le p o essus si u e d ive est o stat e pe da t l’i spe tio .

L’app o he Agile p opose plusieu s méthodologies de travail, ici nous nous intéressons à la méthode SCRUM.

1.3.1 Les acteurs

Afin de mettre en place cette méthodologie de travail, différents acteurs sont pris en considération.

1.3.1.1 Product owner (propriétaire du produit)

M e si l’app o he Agile e pa le pas de MOA aît ise/ aît e d’ouv age ou MOE (maîtrise/maître d’œuv e , le p odu t o e est e ui se app o he le plus du MOA. Ils o t des ôles t s p o hes. Le product est le représentant des clients et utilisateurs, et responsable du succès du projet. Il se charge principalement de trois choses :

- il explicite les éléments du backlog (décrit ci-dessous) qui sont exprimés sous forme de user stories ;

- il s’assu e ue le a klog soit visible et compris par tous ;

- il définit l’o d e des fo tio alit s à d veloppe et fi e ave l’ uipe des o je tifs du sp i t. Cette pe so e doit t e dispo i le à tout o e t, ’est la seule passe elle ve s le lie t. C’est elle qui rencontre le client, et/ou les utilisateurs quand ces derniers sont disponibles. Le product owner recueille les besoins, les centralise, rédige la documentation fonctionnelle, est la passerelle vers le client et enfin valide le produit à la fin de chaque itération.

1.3.1.2 Scrum master

Il est l’a i ateu , oa h et leade de l’ uipe te h i ue ≠ hef de projet). Il fait en sorte que l’ uipe puisse t availle au ieu . Il assu e la pa tie ad i ist ative du p ojet et fait do ta po entre les développeurs et les demandes extérieurs. Le scrum master est responsable de la

o p he sio et ise e œuv e de la thode de t avail s u .

1.3.1.3 Équipe de développement

Elle est auto o ga is e, auto g e et plu idis ipli ai e. Il ’ a pas de hi a hie i te e, les d isio s sont prises ensemble. Elle est chargée de livrer, à chaque fin de sprint (sous partie du projet, voir ci-dessous), une nouvelle version enrichie du produit final.

(27)

26

1.3.2 Les différents documents et livrables

1.3.2.1 Le backlog

Le backlog contient la liste des fonctionnalités à réaliser. Chaque élément a trois attributs, sa des iptio , l’esti atio de sa du e de alisatio , et l’o d e da s le uel il doit t e alis .

Ce document est la bible du projet, tout y est décrit. Tous les membres doivent y avoir accès à tout moment.

On retrouve donc ici les informatio s p se tes da s le ahie d’e ige es. Il est possi le, suiva t les p ojets ue ’est deu do u e ts ’e fo e u’u .

1.3.2.2 Le sprint backlog

Au début de chaque sprint, le périmètre est défini. Le sprint backlog regroupe alors les éléments du backlog s le tio s pou le sp i t. Seule l’ uipe peut le odifie . Ce do u e t volue pe da t tout le sp i t, l’id e est ue e do u e t do e u e visio la plus p ise possi le de e ue l’ uipe prévoit de réaliser.

1.3.3 Les différentes évènements

1.3.3.1 Sprint

Subdivisio du p ojet ui e p e d e o pte u’u e pa tie des fo tio alit s, elle e d passe généralement pas un mois. À la fi du sp i t, l’ uipe de d veloppe e t d liv e u i e t du p oduit. Du a t u sp i t, l’ uipe este la e, et la ualit du p oduit ’est pas go ia le. Chaque sprint se termine par une validation qui permet ainsi le début du suivant.

1.3.3.2 Daily scrum (mêlée quotidienne)

Tous les jou s, du a t ui ze i utes a i u , l’e se le des e es de l’ uipe de développement, répond tour à tour à trois questions :

- Qu’ai-je fait hier ?

- Que dois-je fai e aujou d’hui ? - Quelles difficultés ai-je rencontrées ?

Cette réunion permet de faire un point sur la coordination des tâches en cours et ainsi de s h o ise l’ uipe. Le s u aste s’assu e du o d oule e t et le p odu t o e ’est pas présent. Si des précisions doivent être apportées, il sera contacté au dehors de la mêlée quotidienne.

(28)

27

Figure 4 - Exemple de support graphique utilisé quotidiennement dans une approche Agile, aquette d’un ta leau lanc utilisé dans un bureau

L’app o he Agile s’appuie su des suppo ts visuels. Da s le as du dail s u , les uipes peuve t s’appu e su u ta leau où ha ue tâ he à alise est ot e su u post-it qui se déplace de colonne en colonne (classiquement : à fai e/ e ou s/ faites, ais d’aut es olo es peuve t t e ajoutées). D’aut es i fo atio s peuve t t e affi h es telles ue des pla i gs, des ou es suiva t les indicateurs fixés au début du projet (comme la performance ou la qualité par exemple).

1.3.3.3 Sprint planning meeting

‘ u io au d ut du sp i t où tout le o de est p se t. Elle ’e de pas huit heu es pou u sp i t d’u ois. Elle se d oule e deu te ps :

- Partie 1 : les développeurs cherchent à prévoir ce qui sera développer pendant le prochain sprint ;

- Partie 2 : l’ uipe se fo alise su la a i e d’age e le p o hai sp i t.

1.3.3.4 Revue de sprint

À la fi du sp i t, tout le o de est p se t afi de lôtu e l’it atio . Ne d passa t pas u e du e de trois heures pou u sp i t d’u ois, la evue de sp i t pe et la d o st atio et validatio du logiciel. Chaque élément développé est énoncé présenté et validé par le product owner.

1.3.3.5 Rétrospective du sprint

À la fi du sp i t, l’ uipe de d veloppe e t et le s u aste se et ouvent pour faire le bilan. Ils mettent ainsi en évidence ce qui a bien et mal fonctionné, ainsi que les erreurs commises durant le sprint afin de prendre des décisions pour que cela se passe pour le mieux dans le sprint suivant.

(29)

28

1.3.4 Vue globale de la méthode

Figure 5 - Vue globale de la méthode Agile-scrum

L’app o he Agile pe et do u e gestio de p ojet it ative où à ha ue tape/sp i t, le p oduit est validé par le product owner (représentant le client/utilisateur final). Cette méthodologie permet d’i t g e les usage s à la o eptio , sa s ue ela soit t op te h i ue pou eu . Il a u e transparence dans la communication afin que chacun comprenne les besoins et retours des autres membres. Le ôt it atif pe et u e validatio guli e du p ojet et pe et do d’e ha ge les caractéristiques si celles-ci sont jugées non appropriées.

La ise e pla e de l’app o he Agile ’est pas possi le da s tous les p ojets. Les p ojets insécables en différents sprints ne peuvent pas utiliser cette approche.

La o eptio e t e utilisateu s est de plus e plus utilis e. L’app o he Agile e est u e e ple d’app op iatio pa les so i t s de d veloppe e t a tuelles.

2

Déroule ent d’un projet

Cette pa tie p se te le d oule e t o plet d’u p ojet, o e illustré dans le schéma de la figure 6. C’est su e s h a g al ue s’appuie t pa e e ple les p ojets i fo ati ues e s par SII. Chaque étape y est décrite et présente les méthodes pouvant être utilisées. Cependant nous ous i t esse o s pa ti uli e e t au phases de e ueil de esoi s et d’ valuatio . C’est-à-dire les phases e es pa la aît ise d’ouv age MOA où elle-ci est en contact direct avec les utilisateurs. Certaines méthodes sont communes à ces deux phases, dans ce cas, elles seront présentées dans la partie recueil des besoins.

(30)

29 : les étapes

: les livrables

(31)

30

Les sous partie qui suivent s’appuie su l’ouv age Universal Access Handbook (Stephanidis, 2009).

2.1 La phase de recueil de besoins

Cette première phase en amont permet le recueil des besoins des utilisateurs. Idéalement ce sont ces derniers qui participent à cette étape. Cependant, dans la réalité, ce sont souvent les responsables ou dirigeants des usagers qui sont acteurs. Ce cas de figure se présente régulièrement da s l’i dust ie. Ce tai s utilisateu s e so t pas dispo i les. Si l’o p e d le as d’u outil d di à des militaires sur le terrain par exemple, ce ne sont pas les utilisateurs finaux eux-mêmes qui présentent leurs besoins mais leurs supérieurs.

Cette phase permet de prendre connaissance des caractéristiques des utilisateurs (mémoire, pe eptio s, ha itudes o p te es, âge, atte tes, et . ais gale e t des tâ hes et l’o ga isatio des sorties, entrées, dialogue du futur logiciel interactif (Bastien & Scapin, 1997). Il s’agit i i de savoi qui utilisera le futur outil, connaître ses attitudes et motivations, prendre connaissance des tâches à réaliser, leur expérience, leurs aptitudes et compétences, leur formation, leurs caractéristiques physiques, leurs habitudes, leurs préférences. Tout ceci a des impacts sur la conception.

Différentes méthodes peuvent être utilisées dans cette étape. Ci-dessous, les 10 méthodes les plus souvent citées et utilisées.

2.1.1 Observation directe

L’o se vatio di e te est u e des thodes les plus populai es. Elle pe et d’e plo e l’e p ie e utilisateur sur le terrain en anthropologie, ethnologie (Beyer & Holtzblatt, 1999). Les méthodes ethnographiques sont basées sur quatre principes de base :

- milieux naturels : les personnes sont étudiées dans leurs activités quotidiennes ; - holisme : prise en compte du tissu social et historique de la vie quotidienne ;

- descriptif : description de ce que les gens font réellement, et non pas ce qu'ils devraient faire. Aucun juge e t ’est do ;

- du point de vue de membres : les ethnographes créent une compréhension du monde du point de vue de ceux étudiés.

Le but de l'observation sur le terrain est de mieux comprendre l'expérience de l'utilisateur telle que vécue et comprise dans le contexte d'utilisation. Examiner les utilisateurs dans leur contexte permet une meilleure compréhension des relations entre les préférences, le comportement, les problèmes et les valeurs.

Les séances d'observation peuvent être enregistrées sur vidéos, celles-ci seront ensuite analysées. Une alternative moins efficace est de prendre des notes. Cette technique est souvent utilisée en conjonction avec d'autres, comme des entretiens par exemple. L'obtention de la coopération des utilisateurs est essentielle. L'observateur doit être discret au cours de la session, et seulement poser des questions pour clarifier quand cela est nécessaire. L'efficacité de l'observation et d'autres techniques ethnographiques peut varier, car les utilisateurs ont tendance à ajuster la façon dont ils

(32)

31

effectuent des tâches lorsqu’ils so t surveillés. Davies et son équipe (Davies, Marcella, McGrenere, & Purves, 2004) ont étudié le cas des études de terrain et l'observation directe lors de la conception avec les utilisateurs ayant une déficience cognitive ou aphasie, montrant que cette méthode ne repose pas sur les capacités de communication des participants. Des observations similaires peuvent être faites avec des personnes avec autisme. L’eth og aphie semble être une composante précieuse dans le cadre de la conception participative centrée sur l'utilisateur.

U e diffi ult ave l'o se vatio di e te est u’elle peut t e, da s e tai s as, pe çue o e u e forme d'invasion de l'espace et de la vie privée des utilisateurs, et donc ne peut pas être bien acceptée. Par exemple, il peut être difficile pour certaines personnes de révéler les problèmes

u’elles rencontrent dans leurs activités quotidiennes.

2.1.2 Entretiens individuels

Les entretiens individuels sont une autre méthode de collecte des besoins des utilisateurs inspirée pa l’ethnographie (Gubrium & Holstein, 2002). Cette technique est couramment utilisée. Les utilisateurs, les intervenants et les experts du domaine sont interrogés pour obtenir des informations sur leurs besoins ou les exigences relatives à un système (Macaulay, 1996). Les entrevues peuvent être non structurées (aucune séquence spécifique de questions ’est suivie), structurées (les questions sont préparées et commandées à l'avance), ou semi-structurées (basées sur une série de questions fixes avec la portée de l'utilisateur pour élargir leurs réponses). La sélection des utilisateurs est importante, elle doit être représentative afin d'obtenir des résultats utiles. Voir l'environnement donne également une image mentale vive de la façon dont les utilisateurs travaillent avec les outils existants et comment un nouveau système peut mieux leur correspondre (Smith & Mander, 2001). Les entrevues sont souvent évités lorsque le groupe d'utilisateurs cible est composé de personnes présentant des déficiences cognitives ou des facultés de communication affaiblies.

2.1.3 Groupe de discussion

Les groupes de discussion sont inspirés de techniques de recherche de marché. Chaque participant peut intervenir pour présenter des idées, puis par un processus de discussion, une vue collective est établie (Bruseberg & McDonagh-Philp, 2001). Les groupes de discussion impliquent généralement de 6 à 12 personnes, guidées par un animateur. Plusieurs séances de discussion peuvent être organisées.

Le principal avantage des groupes de discussion est la faible discrimination dans le choix des intervenants. En effet, des utilisateurs qui ne peuvent ni lire ni écrire, peuvent tout de même pa ti ipe . De plus, des pe so es ti e tes à t e i te og es ou ui pe se t ’avoi ie à di e s’e p i e o t plus fa ile e t e g oupe u’e e t etie i dividuel (Kitzinger, 1995).

Organiser une discussion de groupe incluant des participants handicapés nécessite une importante préparation et est tributaire des compétences de communication de chaque participant. Cette méthode ne doit pas être utilisée si le groupe d'utilisateurs cible a de graves problèmes de o u i atio . De e, si les pa ti ipa ts p se te t des t ou les de l’app e tissage, da s e as,

(33)

32

ils o t souve t u e fai le apa it d’atte tio . E fi , la satisfaction des participants est également un facteur important à prendre en compte.

2.1.4 Enquêtes et questionnaires

Les enquêtes auprès des utilisateurs consistent à administrer une série de questions écrites à une population d'utilisateurs de l'échantillon. Elles sont généralement ciblées pour obtenir des résultats statistiquement pertinents. Les questionnaires sont largement utilisés dans les premières phases de conception. Les questionnaires doivent être conçus avec soin pour obtenir des résultats significatifs. Les questions peuvent être fermées avec des réponses fixes et ouvertes où les personnes interrogées sont libres de répondre comme ils le souhaitent. Diverses échelles sont utilisées dans les questionnaires pour évaluer les réponses des utilisateurs. La formulation simple et compréhensible des questions est essentielle. Les questions doivent également être ciblées pour éviter la collecte de grandes quantités d'informations non pertinentes.

La recherche montre qu'il existe des différences dans la manière de répondre aux questionnaires en fo tio de l’âge. Pa e e ple, les pe so es âg es o t te da e à utilise la po se «Ne sait pas» plus souvent que les personnes plus jeunes. Ils semblent également utiliser cette réponse quand ils sont confrontés à des questions qui sont complexes dans la syntaxe. Leurs réponses semblent également éviter les extrémités de chaînes (note plus basses et note plus élevée). Les chercheurs ont trouvé des manières de contourner ce problème. Par exemple, Eisma et son équipe (Eisma et al., 2004) ont o stat ue lo s ue ’est le he heu ui e l’e t etie di e te e t ave l'utilisateu , alors il récupère des informations plus utiles et perspicaces. De leur côté, Dickinson et son équipe (Dickinson, Eisma, Syme, & Gregor, 2002) ont constaté que les entretiens réalisés à domicile étaient plus effi a es da s la p odu tio d'i fo atio s ue si l’utilisateu avait po du au uestio ai e seul.

2.1.5 Modélisation empathique

La modélisation empathique est une technique destinée à aider les concepteurs et les développeurs à se ett e da s la peau des utilisateu s. G ale e t, il a u e si ulatio de l’i validit . Cette technique a été appliquée, pour la première fois, pour simuler les changements visuels liés à l'âge dans une variété de tâches quotidiennes de l'environnement, en vue de susciter les exigences de conception des malvoyants dans différents environnements architecturaux (Pastalan, 1982). La modélisation empathique peut être caractérisée comme une technique informelle, et il n'y a pas de directives précises sur la façon de l'utiliser.

Quelques exemples de modélisation empathique :

- déficience visuelle due à la cataracte : utilisation d'une vieille paire de lunettes avec de la vaseline ;

- cécité totale : foulard ou un bandage noué sur les yeux ; - perte totale de l'ouïe : bouchons d'oreilles.

(34)

33

En outre, l'application de logiciels simulant des déficiences visuelles et auditives ont été développés pour aider les concepteurs à comprendre les difficultés d'interaction rencontrées par les utilisateurs (Goodman-Deane, Langdon, Clarkson, Caldwell, & Sarhan, 2007).

Certains troubles peuvent être difficilement simulés, voire impossible à reproduire. Les déficiences cognitives sont par exemple difficiles à simuler (Svensk, 1997).

2.1.6

Agenda d’activités

L’age da d’a tivit s est u e aut e thode eth og aphi ue ui pe et à l’utilisateu d’auto d la e e u’il fait sur une période de temps définie (Whyte, 1984). Les participants sont tenus d'enregistrer les activités qu'ils réalisent dans le cours d'une journée normale. Ces agendas permettent alors d'identifier des modèles de comportement qui ne seraient pas reconnaissables par l'observation à court terme. Ces journaux peuvent être textuels, mais aussi visuels, en employant des images et des vidéos.

Différents outils peuve t t e is à dispositio de l’utilisateu ui alise so jou al : caméra, e egist eu vo al, jou al u i ue, jou al papie … . L’id e g ale est de laisse le plus de li e t s possi les à l’utilisateu da s e p o essus d’auto-déclaration.

La lecture et l’écriture d'un journal sur papier peuvent être un processus difficile pour les utilisateurs aveugles et les utilisateurs ayant une déficience motrice. Par conséquent, dans ces cas, il sera p f a le d’opte pou des ve sio s u i ues. Lazar et son équipe (Lazar, Allen, Kleinman, & Malarkey, 2007) ont rapporté lors de leur étude que le journal électronique avait été un succès pour investiguer les causes de frustration des utilisateurs aveugles pour accéder au web par le biais de lecteurs d'écran.

2.1.7 Brainstorming

Le brainstorming, est une des approches de la créativité en groupe (Osborn, 1963). C’est u processus où des pa ti ipa ts, de diff e ts ho izo s ’a a t pas la e a tivit , se liv e t à u e dis ussio i fo elle pou g e apide e t u g a d o e d’id es. Cette te h i ue est souvent utilisée dans les premières phases de conception pour définir les objectifs préliminaires du p ojet. L’ava tage du ai sto i g est u’il favo ise la li e pe s e et l’e p essio . La dive sit des profils des participants permet alors un large panel de solutions et idées.

Moffatt et son équipe (Moffatt, McGrenere, Purves, & Klawe, 2004) se sont intéressés à l'utilisation du brainstorming avec des utilisateurs aphasique. L'utilisation d'images peut être utile dans certains cas, en fonction de la capacité d'expression des utilisateurs concernés. Le brainstorming est également souvent utilisé pour recueillir des idées de conception initiales avec la participation des proches et des encadrants, laissant l'implication directe des utilisateurs aux phases de conception suivantes lorsque certains prototypes peuvent être montrés.

Globalement, le brainstorming peut être considéré comme approprié lorsque les utilisateurs impliqués ont de bonnes capacités de communication (pas nécessairement verbale), mais peuvent également être adaptés aux besoins d'autres groupes. Cela peut alors impacter le rythme de la discussion et la génération d'idées.

(35)

34

2.1.8 Scénarios, storyboards, et personas

Les scénarios sont largement utilisés pour identifier les exigences. En effet, ils décrivent de manière a ative les a tio s de l’utilisateu , les a tio s du s st e et le dialogue e t e les deu . Les scénarios donnent des exemples réalistes et détaillés de la façon dont les utilisateurs peuvent effectuer leurs tâches dans un contexte spécifié avec le système étudié (Carroll, 1995, 2000). L'objectif principal de la construction de scénarios est de fournir des exemples d'utilisation future comme une aide à la compréhension des exigences des utilisateurs.

Les storyboards sont des représentations graphiques des scénarios, présentant des séquences d'images qui montrent la relation entre les actions ou les entrées utilisateur et les sorties du s st e. Le sto oa di g, à l’o igi e, tait utilis pou les fil s, la t l visio , et l'i dust ie de l'animation (Hart, 1998). Un storyboard typique contient un certain nombre d'images des fonctionnalités telles que des menus, des boîtes de dialogue et des fenêtres. Les storyboards peuvent varier en ce qui concerne le niveau de détail, l'inclusion d'un texte, la représentation des personnes et des émotions, le nombre de cadres, et la façon dont le temps de passage est indiqué (Truong, Hayes, & Abowd, 2006).

Une autre méthode liée aux scénarios est appelé personas (Cooper, 1999), où un modèle de l'utilisateur est créé avec un nom, une personnalité, et une image, pour représenter chacun des groupes les plus importants des utilisateurs. Le modèle de persona est une représentation a h t pale d'utilisateu s els ou pote tiels. Il ’est pas u e des iptio d'u v ita le utilisateu ou un utilisateur moyen. Le persona représente le comportement des utilisateurs, compilés dans une description fictive d'un seul individu. Des solutions de conception potentielle peuvent alors être évaluées en fonction des besoins d'une personnalité particulière et sur les tâches que celle-ci est censées accomplir (Idoughi, Seffah, & Kolski, 2012).

2.1.9 Prototype

Un prototype est une représentation concrète de tout ou partie d'un système interactif. Il est un artefact tangible, nécessite peu d'interprétation, et peut être utilisé par les utilisateurs finaux (Beaudouin-Lafon & Mackay, 2002). Les prototypes prennent différentes formes. Ils sont de différents niveaux : de bas niveau, ils regroupent les premières idées de l'organisation visuelle du contenu, de niveau intermédiaire, c'est-à-dire uniquement un enchaînent d'écrans, ou encore, de haut niveaux, ils présentent alors l'ensemble des fonctionnalités. Ils prennent ainsi différentes fo es, alla t des o uis papie s, jus u’au p otot pes e lig e, ui o p e e t des animations informatiques, des présentations vidéos interactives, et des applications développées avec les constructeurs d'interface. Les prototypes de bas niveaux, aussi appelés prototypes rapides, sont créés dans un but précis, puis jetés, c'est un processus itératif qui évolue, que ce soit pour travailler sur certains détails (en augmentant leur précision) ou pour explorer diverses solutions de rechange. La collaboration autour de la création de prototypes est un moyen efficace d'impliquer les utilisateurs dans la conception. Les prototypes aident les utilisateurs à exprimer leurs besoins, et les solutions de conception proposées par les concepteurs.

Références

Documents relatifs