Que faire avancer dans l’étude des EIAH : la technique, l’ingénierie ou l’expérimentation ?
Réponse au texte de Pierre Tchounikine " Ingénierie des EIAH "
Atelier " Fondements des EIAH " Plate-forme AFIA 2001 " L'ia informatique de la connaissance ", 28 juin
Philippe Dessus, LSE Grenoble ; Philippe.Dessus@upmf-grenoble.fr

Qu’est-ce qu’un EIAH ?

Dans le texte d’introduction à la Plate-forme AFIA, on peut comprendre que les EIAH sont le produit d’une convergence entre :

des communautés étudiant des objets différents : systèmes tutoriels intelligents, micromondes, simulation, multimédia et hypermédias éducatifs ;
des champs de l’informatique différents : intelligence artificielle, communication personne-système, ingénierie des logiciels, réseaux et systèmes ;
des disciplines différentes : informatique, psychologie cognitive, didactique, sciences de l’éducation.

Cette liste peut être pertinente, mais ne permet guère de définir ce qu’est un EIAH, ou plutôt ce que cela n’est pas. D’une part, un regroupement plutôt qu’un resserrement de préoccupations de recherche a des chances de faire augmenter le flou. Ensuite se pose la question des absents de la liste, pourquoi la philosophie ou la linguistique ne pourraient participer aux EIAH ? Enfin, certains (Bergia, 2001) excluent certains systèmes des EIAH " car ils ne réalisent pas un véritable suivi individualisé (modèle de l’apprenant très limité) et se limitent généralement à un transfert de connaissances au lieu de proposer un environnement avec lequel l’élève va interagir pour construire son apprentissage " (p. 38).

Que faire avancer ? La technique, les méthodes ou l’expérimentation ?

J’ai relevé et classé, dans la présentation de Tchounikine, certaines idées qui montrent dans quelles directions l’ingénierie des EIAH peut se développer. Travailler sur les EIAH, c’est travailler notamment dans trois directions qui sont toutes trois acceptables. Mais la poursuite simultanée de deux d’entre elles — ou des trois — peut causer des incompatibilités ou des antagonismes.

Faire avancer la technique. C’est l’affaire des informaticiens. Se demander si " cela marche ", se préoccuper de réutilisation ou de récurrence, intégrer telle fonctionnalité plutôt que telle autre, travailler en Java, WAP ou XTML, etc. Toutes ces questions sont intéressantes, mais doivent être connectées à une méthode et un type de validation. Et c’est là que cela se gâte.

Faire avancer la méthode. C’est l’affaire des ingénieurs. Mettre en place de nouvelles méthodes qui permettent une utilisation raisonnée des EIAH. Il n’y a pas de réel antagonisme entre technique et méthode, mais plutôt des visées communes qui sont trompeuses : prescrire des moyens rationnels d’apprendre et d’enseigner. Par exemple, le travail sur les EIAH devra élucider la part de la participation de l’homme et de la machine dans la méthode. Accepter que tout ne soit pas pris en charge par la machine, que le modèle de l’élève puisse être aussi dans la tête de l’enseignant ou celle d’autres élèves — par exemple, csile, environnement de construction de connaissances scientifiques de type forum, n’a pas de modèle de l’élève, pour autant, n’est-ce pas un EIAH ? Ensuite, les méthodes sont par définition prescriptives et, assez souvent, fondées sur des théories implicites difficiles à analyser et à critiquer. Cela crée un antagonisme avec les expérimentations, par nature descriptives et dont le cadre théorique doit être explicité. Par exemple, la méthode de conception de curricula de Tyler se trouve en filigrane dans le texte de Tchounikine (identifier les objectifs, choix d’une tactique, étude de l’activité réelle, [évaluation]). Or on a depuis longtemps montré que les enseignants ne planifiaient pas ainsi réellement.

Faire avancer l’expérimentation. Cela devrait être l’affaire de tous. Valider des EIAH en mettant au point des expérimentations, c’est s’exposer à l’effet pds (pas de différence significative) qui hante tout chercheur (antagonisme avec les méthodes et la technique, dont l’utilisation présuppose un effet positif). Cela nécessite des versions stables (antagonisme avec la technique, qui a tendance à avoir un cycle de vie plus court).