Entretiens

À chaque étape de notre méthode d’instrumentation, nous avons réalisé des entretiens nous permettant de recueillir auprès de différents acteurs des informations sur les différentes facettes du métier embarqué dans Hop3x. Ceci nous a permis de recueillir deux types de données : des informations que nous ne pouvions pas obtenir autrement que par entretien de face à face ; des informations permettant de compléter et de comprendre, de donner sens, à d’autres données recueillies par d’autres méthodes sans interprétation sémantique dans l’univers métier de Hop3x.

7.2.1.3.1 Entretiens avec les concepteurs initiaux de Hop3x

Nous avons mené nos premiers entretiens auprès des concepteurs initiaux de Hop3x. Ce sont des enseignants/chercheurs en informatique qui ont développé Hop3x pour leurs propres besoins d’enseignement des travaux pratiques en programmation orientée-objet d’une part, et d’autre part pour tester leurs hypothèses de recherche sur le tutorat [Lekira et al. 2011]. Ils jouent un double rôle : concepteurs pédagogiques lorsqu’ils définissent le contenu des sessions d’apprentissage, tuteurs pendant le déroulement des sessions. C’est la raison pour laquelle nous considérons ces enseignants comme des experts du domaine spécifique de Hop3x.

L’objectif de nos premiers entretiens avec ces concepteurs était de découvrir l’architecture et le fonctionnement du système Hop3x (cf. sa section d’avant). Suite à la fouille des fichiers XML existants sur le serveur, nous avons interrogé les concepteurs de Hop3x sur la raison d’existence de chaque élément. Leurs réponses nous ont permis de formaliser ces éléments dans un métamodèle (cf. étape suivante) qui cristallise les connaissances métiers déjà explicitées. Ce métamodèle initial sert à construire dans un premier temps un éditeur basique des sessions non-ouvertes.

Par ailleurs, nous avons posé un ensemble de questions ouvertes aux enseignants concepteurs. Le but était de récolter explicitement les informations sur les circonstances de conception des sessions exécutables sur Hop3x. Nous nous sommes focalisés sur les pratiques exercées et les instruments utilisés dans le processus de création de la structure et du contenu de ces sessions. En réponse, les enseignants ont confirmé qu’ils n’utilisaient ni une méthodologie formelle, au sens propre de terme, ni un outil spécifique. Ils ont créé manuellement des fichiers XML pour définir la structure et le contenu des sessions en utilisant un éditeur de texte. La méthode n’est bien évidemment pas appropriée pour tous les enseignants qui souhaiteraient utiliser Hop3x pour mettre en place des sessions d’apprentissage, des compétences informatiques étant nécessaires pour formaliser et opérationnaliser les sessions.

Mais nous avons aussi constaté que les concepteurs des sessions utilisent implicitement des concepts métier qui n’existent pas dans les fichiers XML. Nous avons ainsi pu identifier : « l’objectif de la session », « l’objectif de chaque question » et « les tâches liées à chaque question ». Les enseignants nous ont dit qu’ils ciblent un objectif d’apprentissage par la définition de chaque session, voire des sous objectifs pour chaque question, malgré le fait qu’ils ne les expriment pas explicitement. De plus, ils spécifient trois types de tâches pour chaque question : tâches obligatoires, tâches souhaitées, et tâches interdites. La définition

de ces tâches doit dépendre de chaque apprenant ou groupe d’apprenant, selon le contexte d’apprentissage. La définition explicite des caractéristiques de chaque question, y compris son objectif, est nécessaire pour plusieurs causes, par exemple pour guider les tuteurs dans l’adaptation dynamique pendant l’exécution, ainsi que pour des raisons de capitalisation et réutilisation des questions, voire des variantes.

Les enseignants concepteurs ont affirmé qu’ils ne peuvent pas prévoir en amont tous les éléments qui constituent le contenu d’une session. Ce n’est que durant le déroulement et en fonction de la progression des activités des apprenants que les adaptations peuvent être effectuées en fonction de l’objectif d’apprentissage ciblé et du contexte (apprenant concerné, temps restant, etc.). La première fois, ces adaptations sont imprévisibles mais dans les cycles suivants, elles peuvent être considérées comme prévisibles si les enseignants concepteurs décident de les capitaliser à travers un processus de réingénierie. Par exemple, après le déroulement de la session de TP déployée dans notre expérimentation, et après avoir constaté que les tuteurs ont donné aux apprenants une formule mathématique qui manquait à la question 8, pour les aider à avancer, les enseignants concepteurs l’ont ajoutée dans le contenu même de la session. Elle est considérée comme une adaptation améliorante de la question 8.

Un autre objectif de nos entretiens avec les experts de Hop3x visait à faire une distinction entre les éléments de la session qui sont adaptables et ceux qui sont fixes. À cet effet, nous avons conduit des négociations sur les choix à prendre pour améliorer le métier formalisé afin de rendre les sessions ouvertes. Nous avons donc pu identifier des éléments statiques d’une session et ceux qui peuvent êtres adaptables. Pour les premiers on distingue : les caractéristiques individuelles de la session (nom, langage, mode, confirmation, temps de début et de fin), ainsi que la liste des tuteurs qui peuvent être impliqués. Pour les seconds, on distingue l’ensemble des questions et leurs caractéristiques. Il apparaît par ailleurs que l’enseignant peut adapter la session suivant trois éléments : les indicateurs sur l’activité d’apprentissage, les apprenants et/ou les groupes impliqués. Ce sont les éléments qui caractérisent le contexte d’exécution de la session.

Nous nous appuyons sur toutes ces informations pour faire évoluer le métamodèle initial des sessions non-ouvertes vers un nouveau qui permet d’exprimer les sessions ouvertes.

7.2.1.3.2 Entretien avec les tuteurs impliqués dans l’expérimentation

Lors de notre expérimentation, nous avons mené nos observations essentiellement auprès des tuteurs. Ce sont en effet leurs comportements durant l’exécution des sessions que nous cherchions à comprendre, analyser et interpréter afin de :

 cerner les besoins en termes d’adaptation des sessions en temps réel,

 déterminer d’autres concepts métiers qui ne sont pas formalisés dans les fichiers XML,

 identifier les fonctionnalités nécessaires à intégrer dans la version initiale du système pour faciliter certaines tâches assez récurrentes.

Nous leur avons donc posé un ensemble de questions déliées à leurs interventions, au fur et à mesure et à posteriori du déroulement des sessions. Cela nous a permis de confirmer et d’approfondir notre observation et de préconiser des fonctionnalités nécessaires à intégrer dans le système pour promouvoir son ouverture.

Nous avons pu remarquer que les tuteurs ne pouvaient pas mettre à jour le contenu de la session pendant son déroulement en utilisant la version initiale du système. Les modifications apparaissant nécessaires ne peuvent êtres effectuées qu’à travers les interventions tuteurales introduites via les outils de communication (audio ou messagerie). Elles relèvent donc de l’approche d’adaptation par déviation (cf. section 2.1.3.3.2), c’est-à-dire, changement de l’instance de la session sans modifier sa définition et son contenu, tels que l’ajout ou la suppression des questions en temps réel. Ce sont des adaptations éphémères qui ne provoquent pas un changement de la structure de la session dans le serveur, donc pas de capitalisation et de réutilisation des adaptations considérées comme positives.

7.2.2 Définition du métamodèle des sessions non-ouvertes et

prototypage d’un premier éditeur spécifique

Lors de cette étape, notre but était de construire un premier outil pour réifier le métier de Hop3x. Pour ce faire, nous avons utilisé EMF (Eclipse Modeling Framework)¹⁷, qui facilite la génération de code pour la construction d’outils basés sur des métamodèles structurés

[Steinberg et al. 08]. Nous avons donc défini un métamodèle décrivant le DSEML¹⁸ des sessions Hop3x, qui a permis ensuite le prototypage d’un premier éditeur de sessions spécifique au domaine métier de Hop3x (cf. figure 53). Cet éditeur spécifique ne permet pas de produire des sessions d’apprentissage ouvertes, mais il est construit pour valider le métamodèle qui formalise le métier.

17www.eclipse.org/emf, dernier visite Avril 2012.

18

Figure 53 : Processus d’élaboration de DSEML de Hop3x et d’un éditeur spécifique.

Le métamodèle a été défini comme un modèle conforme à ECORE (le méta

d’EMF). Pour ce faire, nous avons utilisé les informations récupérées à partir des fichiers XML existants dans le serveur Hop3x, après, toutefois, avoir conclu un compromis sur significations et les raisons d’être de chaque élément et attribut de ces fichiers XML et avoir validé l’ensemble, lors des entretiens que nous avons menés auprès des enseignants créateurs de ces fichiers. La figure 54 présente le métamodèle élaboré p

connaissances métier déjà formalisées dans les fichiers XML.

Figure 54 : Métamodèle des sessions Hop3x non Formalisation des

concepts métier

Domaine de Hop3x

Processus d’élaboration de DSEML de Hop3x et d’un éditeur spécifique.

Le métamodèle a été défini comme un modèle conforme à ECORE (le méta

d’EMF). Pour ce faire, nous avons utilisé les informations récupérées à partir des fichiers XML existants dans le serveur Hop3x, après, toutefois, avoir conclu un compromis sur significations et les raisons d’être de chaque élément et attribut de ces fichiers XML et avoir validé l’ensemble, lors des entretiens que nous avons menés auprès des enseignants créateurs de ces fichiers. La figure 54 présente le métamodèle élaboré p

connaissances métier déjà formalisées dans les fichiers XML.

Métamodèle des sessions Hop3x non-ouvertes. Formalisation des

concepts métier Prototypage

Métamodèle de DSEML de Hop3x

Processus d’élaboration de DSEML de Hop3x et d’un éditeur spécifique.

Le métamodèle a été défini comme un modèle conforme à ECORE (le méta-métamodèle d’EMF). Pour ce faire, nous avons utilisé les informations récupérées à partir des fichiers XML existants dans le serveur Hop3x, après, toutefois, avoir conclu un compromis sur les significations et les raisons d’être de chaque élément et attribut de ces fichiers XML et avoir validé l’ensemble, lors des entretiens que nous avons menés auprès des enseignants créateurs de ces fichiers. La figure 54 présente le métamodèle élaboré pour cristalliser les

ouvertes.

Éditeur spécifique des sessions non-ouvertes

En nous basant sur ce métamodèle et grâce à l’outillage d’EMF nous avons généré un éditeur basique (cf. figure 55). Il fournit une vue d’arborescence des modèles qui sont en l’occurrence des sessions Hop3x.

Figure 55 :

7.2.3 Évolution du métamodèle initial vers un autre