Les logiciels ont beau avoir été élaborés avec soin et soumis à des
tests, il est fréquent qu’ils s’avèrent insuffisamment adaptés aux
besoins des utilisateurs (ici notés BU), parce que leur conception est
centrée sur des aspects plus techniques qu’ergonomiques (adaptés à
une réalisation efficace et confortable de tâches humaines).
En nous appuyant sur la littérature relative à l’ingénierie logicielle, nous
avons d’abord listé les lacunes principales des processus de conception
usuels : l’analyse des BU est éludée ou très sommaire ; les utilisateurs
sont peu sollicités ; quand ils le sont, il est en général trop tard pour
rectifier suffisamment le produit final... Nous avons ensuite entrepris
d’améliorer une méthode de conception de logiciels de réalité virtuelle1
afin de constituer un guide méthodologique de prise en compte des BU.
Les étapes ajoutées à cette méthode ont été mises en oeuvre et validées
empiriquement dans le cadre de la conception d’Appli-Viz’3D. Ce logiciel
commercial est un outil d’aide à la conception et à la vente de produits
de puériculture ; il permet de mettre en scène des prototypes de produits
et des mannequins dans un environnement virtuel 3D réaliste (une
chambre d’enfant ou une voiture) ; ses utilisateurs sont des ingénieurs,
des designers et des agents de marketing.
Ces étapes, qui reposent sur un principe de co-conception faisant participer tous les acteurs du projet et des utilisateurs2, sont : le recueil et l’analyse, par les concepteurs, des exigences des commanditaires du logiciel ; l’analyse des BU exprimés dès le début de la conception, comme « avoir un environnement chambre et un environnement voiture » ; l’identification des contraintes des concepteurs afin que tous les partenaires en aient conscience ; la concertation régulière (construire, tout au long du processus, une représentation du logiciel commune à tous les acteurs) ; la confrontation des exigences, des BU et des contraintes (synthèse des quatre étapes précédentes) ; la mise en situation et l’identification de nouveaux besoins (faire émerger, en situation d’utilisation, les BU non conscients ou latents, qui n’existaient pas a priori, comme pouvoir créer une chambre avec une ou deux fenêtres) ; la connaissance des priorités des utilisateurs dans les choix de conception : par exemple, ils ont jugé cruciale la possibilité de donner aux mannequins des postures réalistes alors qu’elle n’avait pas été prévue par les concepteurs.
1. La méthode I²I, Interaction et immersion pour l’innovation, S. Richir (Techniques de l’ingénieur, pp1-9, 2003). Cf. le glossaire, quant au terme réalité virtuelle.
2. Vers une conception centrée sur l’utilité : une analyse de la co-construction participative et continue des besoins dans le contexte des technologies émergentes, É. Loup-Escande (thèse de doctorat, Université d’Angers, 2010)
© www.ohazar.comL’expérience tirée des « machines à
enseigner »1 montre combien un recours
efficace à des outils informatiques nécessite
leur adaptation non seulement aux contenus
pédagogiques et aux apprenants mais aussi aux
enseignants et à leurs activités. Nous mesurons
« l’intelligence » d’un EIAH (environnement
informatique pour l’apprentissage humain) à
son « ouverture », c’est-à-dire à aux possibilités
qu’il offre aux utilisateurs pour l’ajuster par
eux-mêmes.
Notre équipe travaille sur un prototype d’EIAH
pour l’apprentissage de la programmation avec
des travaux pratiques lors desquels un tuteur
encadre à distance des élèves confrontés à un
problème de codage. Le tuteur doit pouvoir
percevoir l’activité des élèves à travers leurs
interactions avec la machine et parfois
compléter le scénario pédagogique (poser un
nouvel exercice, donner accès à un document,
etc.) en fonction de leurs performances.
Suivre simultanément l’activité de plusieurs
élèves est facile techniquement mais pas
humainement. Il s’agit donc de fournir à
chaque tuteur les indicateurs les plus utiles
à ses yeux ; un tel indicateur dépend de la
stratégie d’observation, qui peut évoluer avec
le contexte pédagogique. Par exemple, la rareté
des interactions de l’élève avec la machine est
un problème quand celui-ci est censé coder,
pas quand il lit un énoncé. Un tuteur voudra
être alerté de l’inactivité d’un élève ; un autre
préfèrera juger d’une activité moyenne...
Dans un cas, un indicateur approprié pourra
être un code de couleur lié à la fréquence de
frappe du clavier ; dans un autre, ce sera plutôt
une courbe temporelle synthétisant l’activité
de compilation2...
En collaboration avec des ingénieurs
pédagogiques et des enseignants, nous
mettons au point un outil de paramétrage du
« profil » de tuteur (relatif à ses habitudes ou
préférences) et du contexte d’apprentissage,
qui permet à l’EIAH de calculer les indicateurs
à fournir à chaque tuteur. Une approche
« d’ingénierie dirigée par les modèles » est
aussi développée pour mettre à disposition
du tuteur une interface d’édition qui va lui
permettre dynamiquement, sans arrêter l’EIAH,
de définir de nouveaux indicateurs pour changer
sa stratégie d’observation ou de modifier son
scénario pédagogique.
1. Cf. Les machines à enseigner, E. Bruillar (Hermès, 1997)
2. Cf. le glossaire.
Repenser l'ingénierie des EIAH pour des enseignants concepteurs, in Usages, usagers et compétences informationnelles au XXIème siècle, P. Cottier, Ch. Choquet, P. Tchounikine, (Hermès/Lavoisier, 2008)
Têtes chercheuses ©2007 |
mentions légales |
contactez nous |
page d'accueil |
Réalisation : Intelliance 2007