Deux fonctionnalités principales sont attendues de ce système : l’une axée sur la proposition à l’enseignant d’un scénario décrivant les outils les mieux adaptés afin de lui assurer une évolution cohérente de son environnement ; l’autre axée sur l’évaluation a posteriori des scénarios proposés, en fonction de critères de satisfaction des besoins, permettant ainsi de bénéficier des expériences d’utilisation par d’autres enseignants. Deux types de ressources-outils sont concernés par notre étude, les applicatifs et les Web Services, qu’ils soient gratuits ou commercialisés.

Notre étude repose sur deux hypothèses, la première vis-à-vis du besoin (a), l’autre vis-à-vis de la ressource outil (b). Ainsi (a) l’enseignant dispose du contenu de son enseignement et souhaite utiliser et intégrer un ou des outils TIC. Nous n’avons donc pas comme objectif d’aider au développement du contenu d’un cours. (b) L’architecte connaît les ressources-outils qu’il souhaite utiliser et le système devrait l’aider dans son apprentissage de ces outils.

L’article est structuré en trois parties, les besoins et les situations exprimés par l’enseignant, les types de besoins et les fonctionnalités des ressources outils (§2), l’architecture du système (§3), et enfin la méthodologie proposée au travers de différents évènements qui interviennent sur le système d’information (§4).

L’enseignant exprime en langage naturel la situation dans laquelle il se trouve et ses besoins. Par exemple, "  Je recherche un outil qui me permette de faire des histogrammes à partir de tableaux de chiffres. " A partir de cette situation, l’architecte en déduit un type de besoin ; nous avons retenu six types de besoins de ressources outils adaptés à l’enseignant. Cette situation correspond au type générique B2 : Modification de la forme du contenu (Figure 1). L’architecte construit alors une hiérarchie des besoins à partir de questions/réponses avec l’enseignant, dans laquelle un nœud correspond à un critère. Chacun des critères de cet arbre est évalué par l’enseignant. Les feuilles de l’arbre correspondent aux fonctionnalités de ressources outils. Le parcours d’une branche de l’arbre permet d’affiner le besoin de l’utilisateur final.

Figure 1. Exemple de hiérarchie de besoins

Alors que les critères liés aux besoins sont évalués par l’enseignant, les critères liés aux ressources-outils (Figure 2) relèvent de la compétence de l’architecte vis-à-vis de ses connaissances des outils. On peut comparer ce processus aux différents critères de choix qui interviennent lors de l’achat d’un ordinateur où les critères d’utilisation sont compréhensibles par l’utilisateur alors que les critères techniques relèvent des compétences d’un spécialiste. Deux autres critères sont l’environnement technologique de l’enseignant et la discipline enseignée par ce dernier.

Figure 2. Exemple de hiérarchie de fonctionnalités des ressources outils

Un tel du système devra se composer de 4 composantes (Figure 3) : (i) les types de besoins et leur hiérarchie, (ii) les hiérarchies de fonctionnalités des ressources outils. Pour chaque outil nous stockons des annotations sur la satisfaction des enseignants qui l’ont déjà utilisé avec des pré requis nécessaires, (iii) les ressources outils disponibles sur le Web, (iv) les mémoires : d’une part la mémoire collective dans laquelle l’architecte stockera les chemin retenus dans les arbres des besoins et des fonctionnalités pour une situation donnée, l’évaluation des scénarios par les enseignants, les situations et leur contexte ; et d’autre part la mémoire d’usage de chaque enseignant.

Figure 3. Architecture du système

Deux événements peuvent intervenir sur le système et déclencher la mise à jour des informations dans le système d’information : l’expression d’un besoin par un enseignant, et l’évaluation d’un scénario par l’enseignant.

L’expression d’un besoin par un enseignant constitue le cœur du système. (1) L’enseignant exprime son besoin de TIC dans une situation donnée, en langage naturel. Cette situation est décrite sous la forme d’un script. La description d’une situation recouvre souvent plusieurs besoins qui relèvent de différents types de besoins. (2) L’architecte analyse le script, identifie les besoins et les rattache à des types de besoins. (3) Un dialogue entre l’architecte et l’enseignant permet d’affiner le besoin et de descendre dans la hiérarchie des besoins. Dès qu’une fonctionnalité de ressource est détectée dans l’arbre des besoins, on arrête le processus. (4) L’architecte propose un scénario qui indique les ressources à mettre en œuvre pour satisfaire le besoin de l’enseignant, une aide à la mise en œuvre, et éventuellement une simulation. (5) L’architecte stocke le script d’origine, le scénario et les chemins parcourus dans les arborescences dans une mémoire collective.

L’évaluation d’un scénario par l’enseignant : après que l’enseignant ait mis en œuvre le scénario proposé par l’architecte, il est important de connaître son évaluation et son indice de satisfaction par rapport au besoin qu’il a exprimé initialement. Ces résultats d’évaluation vont venir enrichir le module de l’enseignant, et permettront d’améliorer par la suite, la personnalisation de l’aide apportée par l’architecte à l’enseignant. On peut appeler ce module, modèle de l’enseignant car il en a toutes les caractéristiques. Par ailleurs, l’architecte stockera les résultats de l’évaluation dans la mémoire collective. 

L’approche décrite dans cet article est une réponse aux besoins de nos différentes institutions à l’heure où se mettent en place des centres de ressources pour les universités ouvertes. Les instances universitaires encouragent les enseignants à développer des applications pédagogiques et des innovations pédagogiques en intégrant les TIC.

La connaissance des besoins de l’enseignant, des fonctionnalités des outils qu’il attend et de son environnement physique, présente dans le modèle de l’enseignant, permettra au système, et par là-même à l’architecte, d’alerter l’enseignant de la présence de nouveaux outils ou de nouvelles versions qui pourraient améliorer la satisfaction de ses besoins.

Enfin, le système pourrait aider à la construction progressive d’une plate forme et à l’évaluation des outils suite au retour des évaluations par l’enseignant. L’enseignant est alors en situation d’apprentissage des outils TIC.