Compétences du concepteur

Nous avons identifié le concepteur soit comme un expert du diagnostic des connaissances, soit comme un expert des EIAH utilisateur de diagnostics des connaissances. Ce concepteur peut travailler seul ou au sein d’une équipe. Nous allons ici définir plus précisément le concepteur par les compétences qui sont requises ou facultatives pour l’utilisation de notre méthode d’assistance.

Compétences requises pour l’utilisation de notre méthode de construction et de comparaison

Par défaut, l’utilisation de notre méthode et de notre plateforme passe par trois tâches : construction de techniques de diagnostic, comparaison des techniques construites, utilisation du code source d’une technique construite.

177

La construction de techniques requiert la conception d’une ontologie des traces et des connaissances. Cette ontologie permet aussi bien d’apporter de la sémantique sur les traces que de spécifier des éléments non observés, comme des connaissances. Le concepteur doit être familier avec la conception d’une ontologie, notamment les principes d’héritage et de relations entre classes, ainsi qu’avec la représentation de connaissances sous forme de graphe. Pour rappel, notre ontologie dérive d’une ontologie existante proposant un vocabulaire de base sur la représentation de connaissances (i.e. sur la nature des connaissances : loi, concept, règle, stratégie…). La compréhension de ce vocabulaire est donc nécessaire. Les compétences requises sont donc la familiarité avec la représentation des connaissances sous forme de graphe ou de réseau, et la maîtrise technique des ontologies. Il n’est en revanche pas nécessaire d’avoir des compétences sur les mécanismes plus complexes des ontologies (comme l’inférence, le raisonnement, les requêtes…).

Les connaissances du domaine doivent être tracées dans les traces d’apprenants ou spécifiées dans l’ontologie par le concepteur. L’identification de ces connaissances du domaine n’est pas une compétence spécifiquement requise dans nos travaux, mais un prérequis à la construction de toute technique de diagnostic, qui relève avant tout de la didactique.

La conception de l’ontologie, tout comme la formalisation des modèles de diagnostic, reposent dans notre travail sur le postulat suivant : en EIAH, les connaissances peuvent être diagnostiquées à partir de l’observation des interactions de l’apprenant avec l’EIAH (donc à partir de variables observables dans les traces enrichies). Pour concevoir l’ontologie des traces et des connaissances, la maîtrise de toutes les techniques de diagnostic construites par la plateforme n’est pas requise, grâce à l’algorithme d’apprentissage semi-automatique, mais la maîtrise de ce postulat – une connaissance est diagnostiquée à partir d’observables – semble nécessaire pour pouvoir concevoir et raffiner l’ontologie. Les compétences requises sont donc la compréhension théorique du processus de diagnostic des connaissances. La construction, tout comme la comparaison, nécessite des traces enrichies par un diagnostic comportemental (pour rappel, dans un objectif de généricité). Le concepteur doit donc être capable soit de mettre en place un diagnostic comportemental sur ses traces, soit utiliser des traces déjà enrichies. La mise en place du diagnostic comportemental est à la fois un problème d’algorithmique et un problème d’acquisition et de représentation des connaissances du domaine nécessaires pour réaliser ce diagnostic comportemental, qui dépend le plus souvent du domaine d’apprentissage. La mise en œuvre du diagnostic comportemental peut avoir été réalisée précédemment, comme ce fut le cas dans nos expérimentations où nous avons directement utilisé des traces enrichies.Dans le cas contraire, les compétences requises pour mettre en œuvre ce diagnostic comportemental sont donc le traitement des traces collectées par un EIAH.

Les résultats des critères de comparaison doivent être interprétés par le concepteur. L’interprétation nécessite la compréhension du critère, ce qui peut nécessiter des compétences différentes selon le critère : en statistique, en data-mining, en qualité du génie logiciel, etc. Comme nous l’avons montré dans nos expérimentations, cette interprétation

178

demande de recouper les résultats des critères, de sélectionner des sous-ensembles de traces, d’interpréter les intervalles de confiance… Plus généralement, les compétences requises relèvent de l’analyse de données.

En résultat, notre méthode permet d’obtenir le code source d’une ou plusieurs techniques de diagnostic instanciées pour un domaine et un jeu de traces enrichies. L’utilisation du code source d’une technique ou son intégration dans un EIAH nécessite des compétences de programmation et d’architecture logicielle. Il est également nécessaire à ce stade de maîtriser la technique dont on souhaite utiliser et intégrer le code source, ce qui nécessite un travail de documentation.

En résumé, nous pouvons identifier quatre pôles de compétences : représentation de connaissances, analyse de données, programmation et maîtrise de la notion de diagnostic des connaissances. Les trois premiers pôles sont des sous-domaines de l’informatique et/ou de la statistique (pour l’analyse de données). Le dernier pôle est lui spécifique au domaine des EIAH. Le concepteur doit donc avoir des connaissances pluridisciplinaires, en informatique avec des connaissances spécifiques aux EIAH. Or, le domaine des EIAH étant lui-même au carrefour entre informatique, didactique et analyse de données, nous pensons que notre méthode peut être utilisée par les experts des EIAH maîtrisant les compétences que nous avons listées plus haut et la notion de diagnostic des connaissances, au moins théoriquement. Nous notons également que le domaine des EIAH étant pluridisciplinaire, il se trouve en son sein des experts en analyse de données, en représentation de connaissance… Le processus d’utilisation de notre méthode permet la collaboration entre plusieurs concepteurs, en séparant la construction (qui relève essentiellement de la représentation de connaissances), la comparaison (qui relève essentiellement de l’analyse de données) et l’intégration dans un EIAH existant (qui relève du programmeur).

Compétences pour l’ajout de modèles de diagnostic, d’implémentations et de critères

Il est possible de réaliser un certain nombre de tâches facultatives avancées dans notre méthode : la formalisation d’un nouveau modèle de diagnostic, l’ajout d’une implémentation, l’ajout d’un critère de comparaison, le raffinement du code source d’une technique construite.

Dans nos travaux, un modèle de diagnostic est une instance de notre formalisation FMD

proposée au chapitre 3. La spécification d’un nouveau modèle de diagnostic requiert donc des compétences en représentation de données pour la compréhension de ce modèle et la construction d’une instance, ainsi que la maîtrise de l’outil des ontologies. Des compétences théoriques sur la définition du diagnostic des connaissances sont également requises, notamment car notre formalisation repose sur des prises de position (les connaissances sont diagnostiquées à partir d’observables et les connaissances sont représentables sous forme de graphe sémantique) et impose des contraintes (par exemple, absence de cycle entre les ensembles de connaissances et d’observables). Il faut donc tenir compte de ces aspects. L’ajout d’une implémentation dans la plateforme nécessite de proposer un code source capable de lire des traces, d’inférer le modèle de l’apprenant, et de transposer un modèle de

179

diagnostic instancié à un domaine (cf. chapitre 3 pour plus de précisions). Pour ce faire, des compétences solides en représentation de connaissances et raisonnement (inférence en informatique) sont nécessaires. Il est également requis les mêmes compétences en représentation de données que pour la spécification d’un nouveau modèle de diagnostic, puisqu’une technique de diagnostic est le couple formé par un modèle de diagnostic et une implémentation.

Un critère de comparaison est défini de façon générale comme un algorithme évaluant le résultat d’une technique de diagnostic sur une base de traces d’apprenants. Le développement d’un nouveau critère de comparaison requiert donc par défaut des compétences en programmation et en analyse de données (statistique, data-mining…). D’autres compétences facultatives peuvent être requises selon l’objectif du critère. Par exemple, un critère portant sur l’évaluation d’un point de vue génie logiciel des techniques de diagnostic requiert des compétences en génie logiciel.

La plateforme donne en résultat le code source des techniques instanciées aux traces du concepteur. Il est donc possible de raffiner, modifier ou enrichir ce code source, par exemple pour ajouter des variables, raffiner les paramètres, etc. Ces tâches requièrent des compétences spécifiques en conception de diagnostic des connaissances.

Les compétences requises pour l’utilisation avancée de notre méthode demandent donc une bonne connaissance du domaine du diagnostic des connaissances ainsi que des compétences en représentation des connaissances et en raisonnement. Le concepteur ayant ces connaissances est probablement un expert du diagnostic des connaissances ayant lu et maîtrisant notre formalisation FMD.