Contexte d’accueil
Le Laboratoire d’InfoRmatique en Image et Systèmes d’information (LIRIS)
Le Laboratoire d’InfoRmatique en Image et Systèmes d’information (LIRIS) regroupe 330 membres provenant de différents établissements dont le CNRS, l’INSA (Institut National des Sciences Appliquées) de Lyon, l’Université Claude Bernard Lyon 1, l’Université Lumière Lyon 2 et l’Ecole Centrale de Lyon. Les recherches menées au LIRIS ont pour objet principal la recherche et le développement en sciences informatiques.
Grâce à la diversité de ses activités de recherche dans différents domaines comme l’ingénierie, la médecine, les sciences de la vie, les sciences humaines et sociales et les sciences de l’environnement, le LIRIS cherche à mettre en exergue les dispositifs numériques et les jalons de l’Intelligence Artificielle (IA). Le laboratoire LIRIS se veut impliqué dans les défis sociétaux et le développement durable. Il se compose de six pôles de compétences et réunit douze équipes de recherche comme illustré dans la figure ci-dessous.
Le laboratoire Interactions, Corpus, Apprentissages, Représentations (ICAR)
Le laboratoire Interactions, Corpus, Apprentissages, Représentations a été créé en 2003 et relève de l’Institut des Sciences Humaines et sociales du CNRS, de l’Université Lumière Lyon 2 et de l’ENS de Lyon. Il est spécialisé dans le domaine de l’interaction et s’intéresse essentiellement aux langues européennes et à l’arabe. En effet, ses recherches pluridisciplinaires en linguistique et en didactique étudient la langue en interaction et dans le texte dans sa multidimensionnalité.
Les recherches à ICAR ont permis de constituer des banques de données construites à partir de corpus multimodaux de grande taille. Afin de faciliter leur l’exploitation, ICAR a développé un moteur de requête permettant ainsi de proposer une plateforme, CLAPI (Corpus de LAngue Parlée en Interaction) pour accéder à ses banques de données, ainsi qu’une plateforme pour l’analyse textométrique, appelée TXM. Il existe trois grands axes à ICAR, au sein desquels plusieurs thématiques y sont traitées par ses équipes : Équipe InSitu (INteractions et SITUations, pratiques et outils) ; Équipe ADIS (Apprentissages, Discours, Interactions, Savoirs) ; Équipe LanDES (Langue Discours Énonciation Sémiotique).
Présentation du projet
Le projet Fluence e-FRAN
Le projet Fluence est l’un des 22 projets lauréats de l’action e-FRAN , élaborée dans le cadre de la mission interministérielle sur le numérique éducatif et financée par le PIA (Programme d’Investissements d’Avenir) pour expérimenter l’utilisation du numérique dans les pratiques d’enseignement et d’apprentissage. Fluence est un projet soutenu par le CNRS et regroupe trois laboratoires de recherches de l’Université Grenoble-Alpes : LPNC (Laboratoire de Psychologie et NeuroCognition), GIPSA-Lab (Grenoble Images Parole Signal Automatique) et LIDILEM (Laboratoire de Linguistique et Didactique des Langues Etrangères et Maternelles) et celles des Académies de Grenoble et de Mayotte (Mandin et al., 2021).
Il a pour objectif de concevoir des dispositifs numériques innovants pour optimiser l’apprentissage en classe. Fluence vise principalement l’apprentissage de la lecture et de l’anglais en tant que langue étrangère. Il cherche à « […] développer une lecture fluide et aisée via des entraînements spécifiques ciblant soit les mécanismes cognitifs sous-jacents (traitements visuels/visuo-attentionnels) soit des traitements holistiques inhérents à la lecture de textes.».
Ce projet de recherche a permis la conception, le développement et la validation de trois applications sur tablette – EVASION, réalisée par le LPCN pour les traitements visuels et visuo-attentionnels impliqués en lecture – ELARGIR, développée au laboratoire GIPSALab pour la lecture répétée et assistée de textes – LUCIOLE, pour la compréhension orale en anglais et est développée par le LIDILEM.
Les applications du projet Fluence
EVASION
EVASION vise à entraîner l’attention visuelle impliquée dans l’apprentissage de la lecture afin de faciliter la reconnaissance rapide des mots dans le but d’améliorer la lecture chez l’enfant. Il s’agit de traiter des séquences de lettres de plus en plus longues et pendant des temps de plus en plus courts afin de mobiliser l’attention visuelle sur le mot à lire et d’être capable de traiter les lettres qui composent le mot. L’application se compose de quatre mini-jeux qui s’appuient sur le principe des jeux vidéo d’action. Au cours de la progression, EVASION varie selon les quatre critères suivants : la longueur des séquences, la similarité visuelle, le nombre de cibles simultanément présentées et la vitesse de défilement des séquences.
ELARGIR
ELARGIR est un outil basé sur le principe du karaoké et permet d’entraîner la fluence à partir de la lecture répétée ou assistée des textes. La lecture se fait à haute voix d’un texte en synchronie (syllabes, mots, groupes de sens, groupes de souffles, etc.) avec la voix d’un adulte pré-enregistrée. ELARGIR se fait en autonomie mais il sollicite également le travail en groupe pour la découverte et l’évaluation de la lecture. L’enfant procède à la lecture d’environ 10 à 15 textes courts, d’environ 200 à 300 mots ordonnés en difficulté croissante. Par ailleurs, le niveau de difficulté de la lecture (longueur du texte et style de lecture) augmente automatiquement dès lors que l’évaluation effectuée par un camarade est jugée satisfaisante. L’avantage d’ELARGIR est de permettre une meilleure mémorisation de l’orthographe, une accélération du traitement visuelle du texte et la prosodie en lecture.
LUCIOLE
LUCIOLE (LUdique au service de la Compréhension Orale en Langue Etrangère) est un jeu sérieux qui vise la compréhension orale en anglais. Il a été développé avec Unity (un moteur de jeu multiplateforme) et fonctionne sous iOS et Android. Il constitue un placebo pour les jeux EVASION et ELARGIR, car il ne fait pas appel aux modalités de jeu d’action et ne stimule pas les compétences de lecture chez l’enfant. Le jeu consiste à mettre en scène un jeune héros francophone qui se retrouve dans la peau d’un agent secret et devra se débrouiller en anglais afin de réaliser les différentes missions qui lui seront confiées. Dans son mémoire, Adrea Soh décrit le scénario du jeu LUCIOLE où.
Le protocole expérimental du projet Fluence
Le projet Fluence se donne pour objectif de concevoir et expérimenter in situ les outils numériques pour l’apprentissage de la lecture et de l’anglais oral. Il propose alors des entraînements en classe réalisés sur tablettes numériques.
Pour mener à bien cette expérimentation, un protocole de suivi longitudinal de trois ans a été mis en place à partir de 2018 jusqu’à 2021, du fait de la pandémie du Covid-19 qui a empêché le bon déroulement de l’année 3 (c’est-à-dire l’année 2020). Pour cela, des cohortes d’élèves dans les académies de Grenoble et de Mayotte ont participé aux tests des trois logiciels du projet Fluence. Cette étude longitudinale a été testée sur 500 élèves du cycle 2, du CP au CE1 ou CE2 dans les deux académies pendant trois ans afin de prévenir les difficultés d’apprentissages d’une part, d’autre part, une cohorte de 200 élèves de 6ème et de 5ème , se trouvant en difficulté d’apprentissage, a participé au protocole Fluence durant deux ans, dans un objectif de remédiation. Ci-dessous, le plan d’expérimentation tel qu’il a été conçu par les équipes du projet Fluence.
Objectif du stage
Le stage : le projet LUCIOLE
Bien que le projet Fluence e-FRAN soit porté par le CNRS et est sous la responsabilité de Sylviane Valdois (du laboratoire LPCN), celui-ci demande la collaboration de plusieurs équipes de recherche et le soutien de nombreuses institutions. C’est pourquoi, le Service des Langues de l’UGA (Université Grenoble Alpes) et le laboratoire LIDILEM s’est chargé de la création, de la gestion et du suivi du projet LUCIOLE. En effet, LUCIOLE est le produit de nombreux contributeurs (chercheurs, développeurs, stagiaires, acteurs, etc.).
Toutefois, il est représenté par une équipe de chercheurs permanente chargée de la coordination du projet : Mathieu Loiseau, porteur du projet (LIRIS) avec Émilie Magnat, coresponsable du projet (ICAR), Coralie Payre-Ficout (LIDILEM) et Marie-Pierre Jouannaud (LIDILEM), co-responsables pédagogiques.
Pour autant, la validation du jeu LUCIOLE nécessite une analyse fine des traces, qu’il convient de croiser avec les résultats obtenus aux post-tests. De ce fait, un financement complémentaire a été accordé au projet LUCIOLE afin d’analyser les traces collectées. C’est ainsi qu’un stage a été financé par le Labex ASLAN de l’Université de Lyon et constitue en conséquence, l’objet de ce travail de fin d’études.
Missions et tâches
L’objectif même de notre travail consiste à analyser les traces LUCIOLE, recueillies à partir des entraînements des élèves ayant participé au protocole expérimental de Fluence pendant les trois années. Cette analyse a pour but de lier les traces LUCIOLE avec les résultats obtenus aux pré et post-tests. Durant cette période, les tâches que nous avons réalisées ont été réparties en quatre temps :
– La prise en main des données pré et post-tests et l’exportation des traces LUCIOLE à partir des fichiers XML.
– Premier niveau de transformation des traces : transmettre une liste de fichiers XML au programme afin de créer un fichier JSON par utilisateur en y agglomérant toutes ses traces, puis extraire et restructurer les informations.
– Restructuration et désambiguïsation des traces.
– Deuxième niveau de transformation des traces : définir les indicateurs pour calculer la progression de chaque utilisateur pour chaque année de test.
Le déroulement des sessions de jeu
Rappelons que le jeu LUCIOLE, tout comme les autres jeux Fluence, a été intégré en classe selon le protocole expérimental que nous avons décrit supra (voir la figure 2) et dans lequel il a été précisé qu’une session de jeu dure 20 minutes par séance. Il faut savoir qu’une fois que les 20 minutes se sont écoulées, le système suggère au joueur de quitter la partie, sauf si l’enseignant l’autorise à jouer plus de temps. Une fois que le joueur quitte le jeu, il devra alors reprendre le début de l’activité inachevée lors de la session suivante. La figure ci-dessous montre le déroulement d’une session de jeu, où le joueur devra reprendre l’activité à la sous-mission 2.1.
Tests et expérimentations
Parmi les données recueillies dans le cadre du projet LUCIOLE, on trouve :
– les Pré-tests et les post-tests qui ont permis de former des groupes expérimentaux homogènes avec les groupes « contrôle » des logiciels EVASION et ELARGIR. Il faut savoir aussi que les post-tests servent de pré-tests pour chaque année d’expérimentation (la figure 8, ci-après récapitule les tests réalisés) ;
– un questionnaire aux parents sur les langues utilisées en famille ;
– un questionnaire aux enseignants sur l’usage de LUCIOLE en classe, les problèmes rencontrés, la motivation des élèves, etc. ;
– les traces d’interaction suite aux tests effectués pour chaque élève faisant partie de l’expérimentation. Cela permet de récupérer les sons écoutés par l’enfant et le contexte dans lequel il a été écouté, le temps d’entraînement et la progression dans le jeu.
Voici un tableau qui récapitule les pré et post-tests réalisés dans le cadre du projet LUCIOLE.
Définition des concepts utilisés
Parmi les données collectées pour l’analyse et l’évaluation du jeu LUCIOLE, nous retrouvons les traces d’interaction qui nous ont permis de réaliser ce travail. Nous devons alors poser la définition des concepts que nous utiliserons afin de mieux appréhender l’analyse des données, dans ce qui suit.
Qu’est-ce qu’une trace dans les EIAH ?
La notion de « trace » est polysémique et est souvent utilisée dans le langage courant pour désigner une empreinte ou une marque. Toutefois, l’émergence des Environnements Informatiques d’Apprentissage Humain (EIAH) amène à repenser la notion de trace pour parler des « traces numériques ». Deux chercheurs au sein du LIRIS de l’équipe Silex , Laflaquière Julien et Prié Yannick, ont tenté de concevoir une nouvelle approche des traces numériques dans le domaine des EIAH, afin de proposer une réflexivité aux apprenants/utilisateurs, dans le cadre d’une plateforme d’apprentissage collaboratif en ligne (2007). Ils considèrent la notion de trace numérique comme : « […] un enregistrement automatique d’éléments d’interaction entre un utilisateur et son environnement, dans le cadre d’une activité donnée » (Laflaquière et Prié, 2007). Ces éléments d’interaction, qui constituent une trace numérique, résultent des observations de l’activité d’utilisation d’un Environnement Informatique (EI), appelés aussi « observés » (Laflaquière et Prié, 2007). Les observés d’une trace sont représentés par un modèle de trace ou « le vocabulaire de la trace », tel qu’il a été décrit par Laflaquière et Prié (2007). De même, l’ensemble de ces observés est structuré par leurs relations, dans une séquence temporellement située (Lund et Mille, 2009), on parle alors d’une trace modélisée.
Le principe d’un Système à Base de Traces modélisées (SBTm)
S’appuyant sur l’approche des Systèmes à Base de Traces modélisées (SBTm) pour définir un cadre conceptuel permettant de mieux concevoir les traces numériques, les chercheurs de l’équipe Silex ont élaboré un framework qui permet de décrire un SBTm utilisant des traces numériques (Laflaquière et Prié, 2007), représenté dans la figure ciaprès :
Qu’est-ce qu’une trace d’interaction dans LUCIOLE ?
En s’appuyant sur ce que nous avons expliqué dans les points précédents, on considère une trace d’interaction dans LUCIOLE, l’enregistrement d’actions effectuées dans le jeu LUCIOLE par les élèves ayant participé au protocole expérimental. Ces traces d’interaction ont pour but de proposer à l’élève une visualisation de sa progression dans le jeu et des activités jouées, d’un côté ; d’un autre côté, elles permettent aux chercheurs du projet de les collecter pour être exploitées en dehors du jeu, à des fins d’analyse et de validation. C’est cette seconde approche qui nous intéresse dans notre travail.
Nous retiendrons la définition de Pierre-Antoine Champin, selon laquelle une trace est constituée d’« obsels » (les éléments observés). Un « obsel » est formé sur le même mode qu’un « pixel », il permet d’observer un élément de la trace brute pour ensuite la réutiliser – soit en la gardant telle quelle, soit en la transformant – et obtenir des informations (2014).
Chaque « obsel » comporte : un type, une date, un sujet et d’autres attributs.
Dans la figure ci-dessous, nous reprenons un exemple extrait du wiki qui montre l’exemple d’une trace constituée de 4 « obsels » dans un salon de discussion, dans lequel Alice se connecte à un IRC et envoie un message « hi world » et reçoit une réponse de world hi yourself ». On observe que les « obsels » sont localisés dans le temps (la flèche t) et les actions, « envoyer », « recevoir » et « fermer » sont toutes reliées à l’action « ouvrir » du canal IRC.
La prise en main des traces
Dans cette partie du travail, nous allons tenter d’expliciter l’analyse des traces LUCIOLE et les différentes étapes par lesquelles nous sommes passés afin de croiser l’input et les traces d’interaction. Il convient de préciser que le projet sur lequel nous avons travaillé est hébergé sur la plateforme GitLab de la communauté de l’UGA. Outre, les traces et les scripts développés dans le cadre de ce stage, on retrouve également les tickets qui correspondent aux tâches effectuées pendant cette période, selon les besoins du projet.
Modélisation des traces LUCIOLE
Pour comprendre la structure des traces sur lesquelles nous avons travaillé tout au long de ces derniers mois, nous allons tenter d’éclaircir les indicateurs et la modélisation des traces LUCIOLE que nous avons analysés.
Pour connaître les sons joués par l’enfant et à quel mot ou énoncé correspondent, il a fallu créer une base de connaissances afin de faire le lien entre les contenus écoutés par les élèves et les contenus correspondant aux activités et à leur progression. C’est cette base de connaissances qui a permis d’évaluer les différents contextes dans lesquels l’élève a écouté tel ou tel son. Pour cela, les développeurs de LUCIOLE ont mis en place un système par « obsels » qui utilise les transcriptions des sons et ses attributs afin de les croiser avec les sons écoutés par l’élève.
De ce fait, l’exploitation des traces nécessite la modélisation de celles-ci. Ainsi, un modèle de trace peut définir « les types d’ « obsels » (type, date, sujet, attributs), les attributs associés à chaque type et les relations possibles entre les types » (Champin, 2014). C’est ainsi qu’une société privée, appelée GOTAN, a travaillé sur le jeu LUCIOLE. Elle s’est chargée de la partie développement du projet et plus précisément des informations liées à l’envoi des traces, notamment de la structure de la base de données.
Pour modéliser les traces LUCIOLE, GOTAN a fait la distinction entre deux types d’indicateurs en proposant une modélisation des traces pour chaque type d’indicateur. Ci-après, la proposition d’une modélisation des traces faite par la société GOTAN selon le type d’indicateur.
Exportation des traces LUCIOLE
Tout d’abord, dans le cadre de l’analyse des traces LUCIOLE, un nouveau projet a été créé sur GitLab, nommé « Luciole traces ». Ce projet est un espace qui nous a permis d’exporter/importer les données et de partager le travail effectué durant cette période. Afin de prendre en main les traces LUCIOLE, nous avons exporté toutes les données hébergées sur GitLab qui constituaient les traces premières collectées (cf. le principe général d’un SBTm, dans la figure 9) ou ce que nous désignons de traces brutes. Cette exportation avait pour but de nous permettre la manipulation et l’exploitation des traces d’interaction pour être transformées et visualisées. C’est ce que nous expliciterons dans les points suivants. Il convient de noter que l’analyse des traces a été réalisée en Python.
Les traces brutes
Pour analyser les traces LUCIOLE, il a fallu, dans un premier temps exporter toutes les données brutes qui se trouvent dans un dossier nommé [Traces brutes]. Le dossier [Traces brutes] est constitué de quatre dossiers répartis par année d’expérimentation. Nous tenons à préciser que dans le cadre du projet LUCIOLE, nous avons trois années de tests (2018, 2019 et 2020) et une année d’étude complémentaire (2021). Pour chaque année, on retrouve quatre fichiers XML issus du serveur des traces. Nous schématisons le dossier des traces brutes et les fichiers XML pour chaque année de test dans le diagramme suivant.
Découpage des fichiers XML
Afin de faciliter la lecture de ces fichiers XML, nous avons tenté de découper ces fichiers en petits fichiers ouvrables avec un éditeur de texte, dans un script python [split_file.py]. Pour cela, nous avons sélectionné une vingtaine de <row> pour chaque fichier XML découpé. Bien que ce découpage des fichiers n’ait pas été nécessairement utilisé dans le travail qui suit, néanmoins cela nous a aidé à définir un formalisme JSON pour la transformation des traces que nous détaillerons dans les points suivants.
Formalisme des traces en JSON
Pour définir un formalisme des traces pour chaque utilisateur, nous avons identifié les ID fluence à partir de la balise <fluence_id> et avons sauvegardé uniquement les balises suivantes : <id>, <json_parameters>, <has_media>, <create_date>, <group_id>. Le choix de ces balises s’est porté sur les besoins du projet pour le calcul des routines. Nous sommes parties du principe que toutes les traces des fichiers XML sont des traces de l’application LUCIOLE. C’est la raison pour laquelle, nous n’avons pas ajouté les balises de <generic_config_id>, <application_context_id> et <fluence_type>, car ce sont des identifiants relatifs au type d’application. En ce qui concerne les dates, nous avons fait le choix de sauvegarder uniquement la date de création <create_date>, puisque celle-ci est toujours similaire à la date figurant dans la balise <update_date>. Ci-dessous, un exemple de fichier de traces pour un seul utilisateur d’après le formalisme défini en JSON.
Transformation des traces LUCIOLE
Exportation des traces XML en JSON
Suivant le formalisme JSON défini plus haut, nous avons développé un script en python [fluence_id.py] qui permet d’exporter les traces XML en JSON à l’aide d’une bibliothèque _xmltodict_ pour ensuite les structurer d’après le formalisme JSON. Le script prend donc en entrée un fichier XML {export-luciole-annee-mm-jj.log_event.xml} et renvoie en sortie un dossier Fluence_id_annee contenant les fichiers JSON convertis.
Chaque fichier représente un seul utilisateur, identifié par son fluence_id [201712546.json].
Le fichier agglomère toutes les traces de l’utilisateur/élève. La création d’un fichier JSON pour chaque élève (Fluence_id) permettra d’analyser ses traces d’interaction, d’évaluer sa progression dans le jeu et de croiser les résultats de celui-ci avec les résultats obtenus aux posts-tests.
Réécriture des traces
Au vu des anomalies retrouvées dans certains indicateurs des traces, nous avons tenté de soulever ces ambiguïtés, en nous appuyant sur un fichier source, [Scenario.json].
Le fichier [Scenario.json] se trouve dans les traces brutes et contient tous les identifiants que l’on retrouve dans les traces. Les données y sont agencées dans un ordre croissant, en partant des identifiants des missions, puis des activités, et enfin les sons, selon le type de son (stimulus, réponse, consigne, feedback, etc.) dans l’activité.
En nous aidant du fichier [Scenario.json], nous avons procédé, en premier lieu à la préparation des traces. Ensuite, nous avons créé un utilitaire qui utilise le même fichier source pour restructurer les traces.
Préparation des traces à l’aide d’un fichier source
D’abord, nous avons généré – à partir du fichier source, [Scenario.json] – une liste de sons pour la comparer aux sons existants dans les traces, dans un script [verif_sonid.py].
Le fichier de sortie [sons_manquants.json] contient tous les sons manquants dans le fichier source. De cette façon, nous avons pu vérifier tous les sons qui ne figurent pas dans le [Scenario.json], en nous référant aux mediaWiki, afin de voir la concordance des sons avec ceux situés dans les traces.
Cette étape du travail nous a permis de traiter certains sons manquants que nous avons retrouvés dans la base de connaissances des traces LUCIOLE. Ces sons ont été traités via [Scenario.json].
|
Table des matières
Remerciements
Sommaire
Introduction
Partie 1 – Présentation du stage et contexte d’accueil
CHAPITRE 1. CONTEXTE D’ACCUEIL
1. Le Laboratoire d’InfoRmatique en Image et Systèmes d’information (LIRIS)
2. Le laboratoire Interactions, Corpus, Apprentissages, Représentations (ICAR)
CHAPITRE 2. PRESENTATION DU PROJET
1. Le projet Fluence e-FRAN
2. Les applications du projet Fluence
3. Le protocole expérimental du projet Fluence
CHAPITRE 3. OBJECTIF DU STAGE
1. Le stage : le projet LUCIOLE
2. Missions et tâches
Partie 2 – Le jeu LUCIOLE Conception, Fonctionnalités et données collectées
CHAPITRE 4. LES FONCTIONNALITES DU JEU LUCIOLE
1. Se connecter à LUCIOLE
2. Structure du jeu LUCIOLE
CHAPITRE 5. LES DONNEES COLLECTEES
1. Les mediaWiki
2. Tests et expérimentations
3. Définition des concepts utilisés
Partie 3 – Analyse des traces LUCIOLE
CHAPITRE 7. LA PRISE EN MAIN DES TRACES
1. Modélisation des traces LUCIOLE
2. Exportation des traces LUCIOLE
3. Formalisme des traces en JSON
CHAPITRE 8. TRANSFORMATION DES TRACES LUCIOLE
1. Exportation des traces XML en JSON
2. Extraction des traces EVASION et ELARGIR
CHAPITRE 9. DESAMBIGUÏSATION DES TRACES LUCIOLE
1. Fusion des indicateurs
2. Réécriture des traces
3. Gestion des sessions de jeu
CHAPITRE 10. CALCUL DES INDICATEURS
1. Le constructeur CSV
2. Création des routines pour le calcul des indicateurs
3. Récapitulatif du travail réalisé et les difficultés rencontrées
4. Perspectives de l’analyse des traces LUCIOLE et extensions possibles
Conclusion et bilan personnel
Bibliographie
Sitographie
Sigles et abréviations utilisés
Table des illustrations
Table des annexes
Table des matières
Télécharger le rapport complet
