Le discours concernant l'usage de l'ordinateur à fin d'apprentissage est fortement récurrent. Il y a plus de dix ans Jacques Perriault signalait les oublis concernant l'EAO (Vingt ans d'enseignement assisté par ordinateur: usages, oubli, diversification. Revue Education Permanente, no 72 73. Décembre 1983). A l'heure où l'on parle de plus en plus de formation continue et de formation à distance, il semble important de capitaliser le plus possible tous les essais réalisés dans le domaine si l'on ne veut pas ajouter une tranche d'oubli de 20 ans et éviter ainsi de repartir à zéro et de naïvement recommencer avec toujours les mêmes espoirs et les mêmes déceptions. C'est le but de cette lettre que de présenter quelques enseignements fournis par l'usage et la présentation de divers didacticiels de même que le développement de Prof'Expert, que ce soit la première version (projet WBO 46), la version avec vidéo (projet WBO 689) ou les versions ultérieures (version intégrée). Aspect historique, évaluation des coûts et problèmes de réalisation des "interfaces" sont les trois sujets qui seront plus précisément abordés. A propos du coût de l'EAOLes coûts (indépendemment du rendement) de l'EAO ne sont pas faciles à établir. Les expériences menées en entreprise montrent que certaines formations (utilisation d'une nouvelle machine, introduction de nouvelles applications sur les terminaux des guichets des banques, etc.) reviennent meilleur marché en utilisant des systèmes sur ordinateur que les formations classiques, ceci étant valable pour un public à former de plusieurs centaines d'employés. Mais de façon générale, il est difficile d'obtenir les coûts réels d'un développement. De nombreuses variables difficiles à cerner sont à prendre en compte: degré de réutilisation d'autres travaux (ceci est en particulier valable, lorsque le système EAO est développé en même temps que le système et sa documentation), plateforme utilisée, ressources multimédia nécessaires, etc. Les chiffres souvent articulés évoquent un coût brut de 150'000 frs par heure d'EAO produite. Cet ordre de grandeur a la faculté de refroidir les petits budgets alors que, ce coût concerne des systèmes relativement élaborés et complexes, comprenant des images et des séquences vidéo originales. Si l'on se contente de créer des systèmes simples pour lesquels il suffit d'entrer des données dans des systèmes relativement standard et en limitant les aspects graphiques, il est certainement possible de s'en sortir à meilleur compte. Nous avons essayé d'imaginer ces coûts pour la création de 10 heures d'enseignement de base en une année avec les limitations notées ci-dessus réalisées par deux personnes ayant chacune une bonne connaissance de la discipline considérée et une expérience minimale de l'EAO (on peut imaginer l'intervention ponctuelle d'experts ou d'aide pour entrer les données). L'analyse des coûts a été faite en considérant les rubriques suivantes (un poids indicatif en nombre de jours est donné entre parenthèses): choix initiaux (10), adaptation de l'outil (30), formation, essais divers (30), création des contenus (45), administration (20), élaboration, prise de données (50), documentation minimale (15), essais (10). Cela permet d'établir le coût d'une heure d'EAO à 20'000 frs. Dans cette étude, les frais d'environnement (bureau, ordinateur, ...) ne sont pas comptés. On ne tient pas compte non plus des ajustements à apporter après un certain temps d'essai, ni d'autres problèmes qui pourraient survenir. C'est une première tentative. Mais nous espérons que cet essai, par les réactions qu'il pourra susciter, permettra d'affiner ce calcul du coût. Cela serait de la plus grande utilité pour tous ceux qui voudraient se lancer dans une production locale. A. Favre, L.-O. Pochon EAO et apprentissageCes quelques brefs éléments de réflexion tentent de cerner les notions qui permettent de définir une bonne interaction d'apprentissage avec un logiciel d'EAO (au sens large du terme). Apprendre avec une machine est possible, mais l'expérience montre qu'il y a des "choses" qui marchent et d'autres qui ne marchent pas sans que les analyses a priori puissent vraiment juger des "capacités" pédagogiques d'un système d'enseignement. Les couleurs agréables, le soin mis à la présentation favorisent certainement l'apprentissage, mais ce n'est pas suffisant. Le problème qui semble central est celui de savoir dans quelle mesure un utilisateur "colle" à l'interface. On appellera cela le phénomène de "la captation". Certains éléments peuvent la favoriser, d'autres la perturber. Pour l'analyser, il s'agit tout d'abord de distinguer le lien que la tâche entretient avec l'ordinateur ou son fonctionnement. Etant donné un utilisateur motivé et du temps à disposition, une activité de programmation Logo, par exemple, devrait s'harmoniser sans peine à l'activité menée; la maîtrise de l'ordinateur est un ingrédient de la tâche. Cela devrait aussi être le cas avec Cabri-géomètre et d'autres systèmes de construction relativement simples (à voir si la nouvelle version de Cabri n'est pas trop riche de ce point de vue). Par contre, dans le cas d'un traitement de textes, la réalisation de la forme peut entrer en conflit avec celle du fond. De façon générale, plus l'interface est riche et plus il y aura une interaction importante entre la tâche effective (prise de connaissance d'une information, par exemple) et la manipulation de la machine (accès aux différents fragments cachés d'une information). Plus la tâche demandera de détours de manipulation, et plus cela donnera à l'utilisateur des occasions de perdre le fil de sa réflexion et de son apprentissage. Un deuxième paramètre à prendre en compte est la nature de la tâche sur la machine par rapport à la tâche réelle. Elle peut être apparentée (simulateur de vol), changer de registre psycho-moteur (jeu de golf!), ou alors être beaucoup plus difficile à caractériser dans le cas où les manipulations sont liées à des opérations mentales (apprentissages mathématiques). Cela pose le problème du rôle de la main et de l'oeil dans des apprentissages de type abstrait. Quelle différence y a-t-il entre taper la réponse au clavier, désigner la réponse à l'aide de la souris, écrire avec un stylo optique ou montrer avec le doigt sur un écran tactile. Déplacer le regard, "activer" la "fenêtre" avant de taper la réponse, sont des éléments qui doivent être pris en compte dans l'analyse d'un système d'apprentissage. A titre d'exemple, on a examiné diverses possibilités pour l'utilisateur de fournir des expressions ensemblistes, par exemple de donner la réponse A Ç B. Utiliser la combinaison de touches alt-239 pour le symbole d'intersection, c'est couper l'utilisateur de la notion travaillée. Déplacer un symbole avec la souris coupe du rythme de l'écriture symbolique. Désigner le symbole avec la souris ou avec un QCM semble la solution la plus adaptée. Le symbole désigné doit rapidement se placer dans l'expression à produire et le geste accompli ne doit pas briser "fil de la plume" (ou plutôt du clavier ou de la souris!). Un même type de problème se pose également avec les messages. Rarement lus, ils interfèrent également avec le rythme du travail (changement du point de focalisation du regard). En cas de réponses fausses, donner les données qui mènent à la réponse, tels que certains systèmes le proposent (Mac-Elem du CUEPP) semble une bonne idée mais qui augmente par trop le nombre d'éléments à prendre en compte par l'utilisateur (donnée, réponse erronée, nouvelle donnée, ...). L'analyse des erreurs devrait pouvoir s'intégrer dans le rythme même de l'interaction, par exemple en redemandant une réponse plutôt que de délivrer un message explicatif. Une solution reste à explorer qui utiliserait un canal "parallèle" et fournirait les commentaires de "vive voix". Dans le même ordre d'idée, travailler face à un ordinateur rend difficile la prise de notes. Mais fournir un bloc-notes électronique ajoute de la complexité sur l'écran et dans les manipulations. Que peut-on dire de chacune des approches? De même, on peut considérer l'usage d'une calculatrice externe ou un outil intégré au logiciel. L'incorporation d'outils dans le logiciel est facile à réaliser et cette possibilité est toujours considérée comme un atout des logiciels d'enseignement. Toutefois, peu d'études semblent avoir pris le parti de comparer le comportement des utilisateurs face à l'une ou l'autre des approches. Avis aux amateurs. Ce ballon d'essai cherche la théorie de l'apprentissage qui aurait défini et étudié des aspects évoqués. A voir si dans cette quête de la "captation" la part qui serait du domaine de l'apprentissage et celle qui relèverait du conditionnement pur. L.-O. Pochon, A. Favre Apprentissages de base, de la langue maternelle et des autres, à l'aide de l'ordinateurEn plusieurs manifestations, près de trente logiciels auront été présentés entre 1984 et aujourd'hui à Neuchâtel. A l'occasion des dernières journées "Ecriture sur ordinateur", il nous a semblé intéressant d'en faire la liste et de nous demander ce qu'il en reste. Nous constatons que l'outil informatique s'est banalisé, standardisé; que si l'utopie est moins présente, l'utilisation réelle, à grande échelle, de l'informatique dans le monde de l'apprentissage n'en reste pas moins marginale. Ces manifestations ont eu lieu dans les cadres suivants : Cours OFIAMT, Journées UDO, Atelier de reconversion professionnelle, Formation continue (Ecole normale, CPLN), IRDP. L'Association ABORD ou son ébauche y a chaque fois contribué.
Qu'en reste t il ? Qu'avons nous pu en faire ? Quel avenir ? Des compléments d'information sont disponibles auprès de Louis Gagnebin, Cassarde 19, Neuchâtel, qui a établi ces quelques repères historiques.
PExpert\Lettre5.TXT - Neuchâtel, le 6 mars 1996 LOP/ege |