Taille de police : small-medium-big

Les experts du BIEF
Xavier ROEGIERSPrésident

Évaluer un projet d'informatique pédagogique : une question de questions

Recherche en éducation - théorie & pratique, nos 16/17, Bruxelles / GERARD, F.-M. & ROEGIERS, X. / 1994

Télécharger la publication

Introduction

L'exploitation de l'ordinateur comme outil pédagogique constitue dans la plupart des cas un véritable projet pour les utilisateurs : les enseignants et les élèves, mais aussi les concepteurs. Un tel projet d'« informatique pédagogique » peut prendre de nombreuses formes, depuis la conception ou l'utilisation d'un didacticiel jusqu'à l'apprentissage d'un langage informatique en passant par l'utilisation de l'ordinateur comme outil de simulation, de communication, de calcul,...
Pour assurer la cohérence et la pérennité d'un projet d'informatique pédagogique, il convient de mettre en oeuvre un processus d'évaluation.
Celui-ci n'échappe pas à la complexité de l'évaluation de tout projet, considéré comme un processus débouchant sur un produit à atteindre.
Réduire l'évaluation à la simple évaluation du produit final risquerait cependant de faire oublier qu'un projet s'évalue dès les premières étapes du processus, et que ces évaluations sont déterminantes pour la réussite du projet, tant pour l'orienter que pour le réguler. Il convient pour cela de poser quelques questions, les bonnes questions.

1. Les composantes d'un projet d'informatique pédagogique

Avant d'aborder les différentes opérations d'évaluation souhaitables, commençons par proposer un cadre méthodologique général d'élaboration d'un projet d'informatique pédagogique. Nous en distinguerons les composantes suivantes.

1.1. La détermination des objectifs

Il s'agit de se demander : à quoi l'ordinateur doit-il servir ? Quelle(s) fonction(s) doit-il permettre de remplir ? Quel type d'aide veut-on qu'il apporte, pour l'élève ou pour l'enseignant ?
Dans une autre publication (GERARD F.M. & ROEGIERS X., 1993), nous avons identifié 7 fonctions que peut remplir un manuel scolaire. Développons ces 7 fonctions, en les appliquant au projet d'informatique pédagogique et en essayant de cerner l'apport spécifique de l'ordinateur.

  • Fonction de transmission de connaissances : c'est le cas des didacticiels - utilisés sous le mode tutoriel - ou encore des CD-ROM ou CD interactifs dont l'objectif est de communiquer à l'apprenant une série d'informations. L'ordinateur permet une découverte progressive, très structurée, et une adaptation constante au cheminement de l'élève.
  • Fonction de développement de capacités et de compétences : dans le cas de didacticiels, il s'agit - par exemple -de programmes qui visent à pouvoir opérationaliser un processus de détection de pannes, ou encore à permettre un diagnostic médical. C'est également le type de fonction poursuivie par l'utilisation pédagogique de logiciels-outils (traitement de texte, tableur,) ou par la découverte d'un langage tel que LOGO.
  • Fonction de consolidation de l'acquis, ou d'exercice : que ce soit sous une forme ludique ou systématique, c'est une des fonctions les plus usitées de l'informatique pédagogique, dans laquelle les possibilités de « répétition » et/ou de « génération aléatoire » sont exploitées sous de multiples modalités, par exemple lorsque l'ordinateur tire au hasard des mots que l'élève doit traduire dans une autre langue.
  • Fonction d'évaluation de l'acquis : c'est une fonction que poursuivent de nombreux didacticiels destinés à la réalisation de bilans des connaissances, que ce soit de manière individuelle ou à une échelle collective, par exemple pour analyser les acquis d'une classe entière.
    Dans la perspective de l'évaluation formative, deux fonctions complémentaires s'y rattachent, de manière particulièrement féconde grâce à l'interactivité avec l'ordinateur :
    - la fonction de diagnostic qui consiste à analyser l'erreur, c'est-à-dire à en rechercher les causes probables. Cela suppose que deux causes possibles soient envisagées au minimum lors de l'analyse : par exemple, une multiplication écrite inexacte serait analysée sur la base d'une erreur dans les tables de multiplication ou d'une erreur de numération) ;
    - la fonction de remédiation qui consiste - sur la base de l'analyse de l'erreur - à proposer des activités idoines permettant de la corriger.
    Notons que ces fonctions peuvent être atteintes de manière indirecte par l'utilisation de l'ordinateur comme outil de simulation lorsque, par exemple, l'élève introduit des données qu'il croit correctes et que l'ordinateur peut lui montrer qu'elles aboutissent à un mauvais résultat, provoquant ainsi chez l'élève un nouveau processus d'analyse et de remédiation (LEBRUN, 1991).
  • Fonction d'aide à l'intégration des acquis : c'est par exemple une fonction que peut poursuivre un didacticiel orienté vers l'aide à la décision ou vers la résolution de problèmes, à partir d'un ensemble d'éléments donnés. C'est aussi le cas lorsque l'élève est invité à utiliser le langage de l'ordinateur, par exemple à l'aide d'un tableur, pour résoudre un problème complexe, telle une équation à une inconnue du deuxième degré.
  • Fonction de référence : c'est une des fonctions préférentielles des produits actuels dans le domaine des multi-médias et des CD interactifs qui permettent - par le texte, l'image et le son - de prendre connaissance de nombreuses informations, et cela sous de multiples formes structurantes (cartes, tableaux comparatifs).
    C'est aussi la fonction poursuivie par certains didacticiels, par exemple de conjugaison, dans lesquels l'apprenant peut rechercher n'importe quelle forme à conjuguer.
  • Fonction d'éducation sociale et culturelle : cette fonction peut être celle de didacticiels qui ont pour objectif premier de sensibiliser à une problématique, comme celle de l'environnement par exemple, mais aussi celle de l'utilisation pédagogique des logiciels-outils dans la mesure où ceux-ci permettent la réalisation de projets orientés vers les activités d'éveil (DEPOVER, GILLET & VERBRUGGEN, 1993).

Tout comme un manuel scolaire, un projet d'informatique pédagogique poursuit rarement une fonction unique. À côté d'une fonction principale, en général facilement identifiable, il en poursuit deux ou trois autres secondaires.
Par exemple, un logiciel d'anticipation du contexte académique et social en début de cycle universitaire cherche à la fois à développer des compétences (gestion du temps, attitude face au travail), à réaliser une évaluation d'orientation par la définition d'un profil de l'étudiant, et à l'aider à s'insérer dans le contexte social et culturel universitaire (ENTWISTLE, ODOR et ANDERSON, 1987).
De même, un didacticiel de conjugaison, qui poursuivrait la fonction première de référence, en permettant à l'apprenant de rechercher toute forme à conjuguer, peut dans le même temps remplir la fonction d'exercice (l'apprenant est invité à produire un verbe conjugué), voire même de diagnostic s'il y a analyse de l'erreur (confusion entre deux temps, etc.).

1.2. L'analyse des contenus-matières

Cette étape, qui concerne essentiellement les didacticiels, consiste - dans un premier temps et en liaison avec les objectifs poursuivis - à circonscrire les contenus à traiter, aussi bien sur le plan du niveau de difficulté de ceux-ci que sur le plan de leur étendue.
Par exemple, ayant décidé d'exercer l'accord des participes passés, veut-on plutôt mettre l'accent sur la diversité des verbes à accorder, sur la palette des cas d'accord que l'on rencontre, ou au contraire sur la diversité des situations dans lesquelles on peut être amené à les accorder ?
Un second temps, pour lequel le fait de recourir à l'ordinateur constitue probablement un avantage majeur, consiste à analyser les contenus-matières pour les structurer de manière logique et rationnelle.

1.3. L'architecture pédagogique du projet

Elle consiste non seulement à déterminer les types d'interactions à développer entre la machine et l'apprenant (nature des interactions, fréquence de celles-ci, type d'aide, convivialité, etc.) mais aussi à dégager les interactions possibles entre l'élève et l'enseignant, ou entre les élèves, et les bénéfices qui peuvent être tirés de ces interactions.
On posera - par exemple - la question de savoir si, en cas d'erreur, on donne la bonne solution à l'apprenant, s'il a d'autres chances de la trouver, si différentes solutions possibles vont lui être proposées, si on reviendra plus tard sur une question manquée, ou encore si on acceptera - ou suscitera - des discussions entre élèves ou le recours à l'enseignant, etc.
Plus fondamentalement, cette étape permet donc de mettre en relation un modèle de l'élève - tenant compte de la variété des styles cognitifs ou d'apprentissage -, un modèle de l'enseignant - guide, tuteur, expert, facilitateur - et un modèle d'enseignement-apprentissage adaptant ses stratégies aux besoins de l'élève, de la matière (DEPOVER, 1987).

1.4. L'architecture informatique du projet

Elle consiste à déterminer à la fois quel système auteur ou langage de programmation utiliser, quelle compatibilité rechercher, quel type d'organisation informatique pour faciliter au maximum l'accès, quels logiciels-outils, etc.

1.5. L'étude des ressources et des contraintes

Il s'agit d'avoir une idée la plus précise possible des conditions dans lesquelles le projet d'informatique pédagogique peut être réalisé.
Par exemple, pourra-t-on travailler au sein d'une équipe constituée à la fois de spécialistes de contenus, d'informaticiens et de pédagogues ? De quel matériel et de combien de temps dispose-t-on ? Quelles sont les possibilités de financement ? Le contexte institutionnel permet-il de mettre le projet en oeuvre et de l'évaluer ?

1.6. L'élaboration d'un prototype

Cette étape, ainsi que la suivante, concerne surtout la réalisation de didacticiels. Il s'agit d'élaborer, sur une unité de matière sélectionnée, un premier produit qui possède les caractéristiques principales du produit final, et de l'expérimenter auprès d'une population représentative de la population-cible.
Il importe de choisir pour ce prototype l'unité de matière la plus représentative des difficultés qui pourraient apparaître afin que son expérimentation ne soit pas tronquée.

1.7. La mise en oeuvre des contenus-matières

Il s'agit de l'application des architectures pédagogique et informatique à l'ensemble des contenus-matières qui auront été délimités.

1.8. La mise en forme (« layout »)

Il s'agit de la mise au point des écrans et de la présentation générale de l'outil tel qu'il sera proposé à l'apprenant, ainsi que de l'élaboration des documents d'accompagnement.

1.9. L'utilisation

C'est la mise en oeuvre du projet d'informatique pédagogique en temps réel auprès de la population-cible.

2. Interactivité des composantes

Dans la réalité, ces composantes ne s'élaborent pas de façon linéaire ni successive ni structurée, mais en interaction étroite les unes avec les autres. Il n'est par exemple pas nécessaire, ni même souhaitable, de fixer trop tôt les objectifs de façon définitive. En effet, rien de tel pour valider des objectifs que la confrontation aux premières difficultés de la planification et de la conception.
Il est en revanche nécessaire que certaines composantes soient validées avant d'en aborder d'autres. C'est ainsi qu'avant de construire un prototype représentatif du produit final, il faudrait s'être prononcé sur les objectifs à poursuivre. De même, avant de commencer la mise en oeuvre des contenus-matières, il faudrait s'être prononcé de façon définitive sur l'architecture pédagogique et l'architecture informatique.

On peut dégager quatre grandes phases du projet :

  • une phase de définition du projet, qui se termine lorsque les objectifs sont fixés ;
  • une phase de finalisation de l'architecture, qui commence quand les objectifs sont déterminés et qui débouche sur les stratégies à mettre en oeuvre pour mener le projet à bien ;
  • une phase d'élaboration du produit, qui commence avec la mise en oeuvre de l'ensemble des contenus-matières ;
  • une phase d'utilisation du projet, qui suit l'élaboration du produit.

Le schéma de la figure 1 permet de donner une idée de l'enchaînement de ces composantes et de ces phases.

3. Quelles évaluations ?

Ces quatre phases sont à mettre en relation avec les différents types d'évaluation définis par STUFFLEBEAM (1980) :

  • l'évaluation de contexte qui vise à préciser les effets attendus, et à déterminer les objectifs du projet ;
  • l'évaluation des intrants, qui a pour fonction de préciser les stratégies ;
  • l'évaluation de processus qui compare les stratégies effectives aux stratégies prévues. Nous ne développerons pas cette évaluation dans le cadre de cet article ;
  • l'évaluation de produit, qui a pour fonction de valider le produit obtenu. Elle se prolonge par une évaluation des effets sur le terrain.

La tentation serait grande de dire que l'évaluation de contexte correspond à la phase 1, l'évaluation des intrants à la phase 2, l'évaluation de processus à la phase 3 et l'évaluation de produit à la phase 4. La réalité est un peu plus complexe, et plus riche à la fois.

Proposons quelques pistes pour structurer et opérationaliser les principaux moments d'évaluation.

3.1. Évaluation de contexte

Il y a lieu de mener tout d'abord les opérations d'évaluation qui conduisent à définir les effets à obtenir, ainsi que les objectifs du projet, notamment les fonctions que le projet doit remplir (phase 1).
Il s'agit d'une part des opérations qui permettent de déterminer les fonctions « ex ante », c'est-à-dire celles qui consistent à identifier les fonctions qui pourront au mieux satisfaire les besoins. C'est l'évaluation de contexte (c), au sens de STUFFLEBEAM.
Il s'agit d'autre part de l'ensemble des opérations qui permettent d'ajuster les fonctions « ex post », après avoir cerné les moyens disponibles. Il s'agit d'une autre facette de l'évaluation de contexte, au sens où BOURGEOIS et ROEGIERS (1993) proposent d'étendre cette notion.

c1. L'évaluation de contexte « ex ante » : une question de pertinence

Cette évaluation consiste à poser des questions qui permettent d'orienter le projet. Elle se place avant l'analyse des contenus-matières, et avant toute réflexion sur l'architecture, tant pédagogique qu'informatique.
Les questions posées sont très générales. Elles sont relatives à la pertinence du projet, au sens où DE KETELE et ROEGIERS (1993) entendent ce terme :

  • Quels besoins faut-il satisfaire ? Quels effets veut-on obtenir ?
  • Est-ce bien un didacticiel ou autre type de projet d'informatique pédagogique qui permettra de produire les effets escomptés ?
  • Sur quel type de produit faut-il déboucher ?
  • En supposant que l'on aboutisse à un produit idéal, comment celui-ci sera-t-il exploité dans la pratique ?
  • En quoi cet outil est-il complémentaire ou non aux autres stratégies d'apprentissage développées par l'enseignant ?
  • Quelles résistances pourraient se manifester ?
  • etc.

Ces questions posent donc le problème - abordé ci-dessus - des fonctions que le projet d'informatique pédagogique doit remplir.
Les questions portent également sur les possibilités de mise en oeuvre du produit pour obtenir l'effet recherché. Il est en effet vain de produire un produit informatique performant s'il n'est pas utilisé dans la pratique. Ce sont les conditions, ou contraintes, de mise en oeuvre, à évaluer a priori. De nombreuses recherches ont mis en évidence les conditions - tant matérielles qu'humaines, ou encore institutionnelles ou temporelles - qui favorisent ou non l'implantation d'un projet informatique, notamment dans une perspective systémique (MORIN, 1992).
L'évaluation de contexte abordera non seulement les effets directs à obtenir, mais aussi les effets indirects qu'il faut tenter d'anticiper. Ces effets peuvent être nombreux :
* des effets indirects négatifs, tels une fragmentation des rapports sociaux, ou encore une divinisation de l'ordinateur qui pourrait apparaître comme celui qui sait tout et peut tout ;
* des effets indirects positifs tels la motivation, ou la mise en confiance de l'apprenant, qui apprend à son rythme, hors du regard des autres, ou encore l'apparition du déclic « apprendre à apprendre » chez l'élève qui s'habitue à recourir à un menu, à faire appel à une fonction d'aide, et plus loin à recourir plus souvent à la bibliothèque Des recherches ont montré également que loin de favoriser l'individualisation, des projets d'informatique pédagogique pouvaient, dans des conditions propices, exercer une fonction de socialisation en provoquant de nombreux échanges entre apprenants (BAGLEY & HUNTER, 1992).
L'ensemble de ces questions débouchent d'une part sur les objectifs, et d'autre part sur le cahier des charges du projet d'informatique pédagogique, qui sera exprimé tant en termes de fonctions à poursuivre qu'en termes de conditions d'utilisation.

c2. L'évaluation de contexte « ex post » : une question de faisabilité

Pour être adoptés définitivement, les objectifs d'un projet doivent être confrontés aux moyens qui seront mobilisés pour atteindre ces objectifs. Il s'agit en quelque sorte d'une évaluation de la faisabilité du projet.
En effet, avant de se prononcer de façon définitive sur les objectifs et les fonctions à remplir, il est bon d'avoir une idée assez précise :

  • de la délimitation des contenus : on se posera notamment la question de savoir si l'étendue des contenus permet d'atteindre les fonctions visées ;
  • de l'architecture pédagogique : on se posera la question de savoir si le type d'interactions que nécessitent les différentes fonctions souhaitées sont compatibles, ou tout simplement si elles peuvent être intégrées dans un produit unique de façon cohérente ;
  • de l'architecture informatique : les différentes fonctions peuvent-elles se combiner sur le plan de la conception informatique ?
  • des ressources et des contraintes liées à l'élaboration : est-il réaliste de s'engager dans un projet de cette envergure compte tenu des moyens matériels, temporels, financiers et humains dont on dispose ?

Cette évaluation, qui ne fait que prolonger l'évaluation de contexte « ex ante », conduit souvent à réduire, parfois même de façon sérieuse, les ambitions du projet initial.
Il n'est par exemple pas rare qu'ayant élaboré un premier cahier des charges précisant qu'un didacticiel devait à la fois poursuivre les fonctions d'évaluation des acquis, de diagnostic et de remédiation, les fonctions complémentaires de diagnostic et de remédiation soient transformées en une fonction d'exercice, faute de disposer du temps, des compétences voire même de la mémoire nécessaires pour développer la fonction de diagnostic.

3.2. L'évaluation des intrants

L'évaluation des intrants (i), au sens de STUFFLEBEAM, pose la question de la cohérence stratégies - objectifs. Il s'agit tant des moyens en temps, que des compétences nécessaires (équipes mixtes informaticien - spécialiste de contenu - pédagogue) ou encore des moyens financiers.
De même que l'évaluation de contexte, l'évaluation des intrants comprend une composante « ex ante » et une autre « ex post ».

i1. L'évaluation des intrants « ex ante » : une question de cohérence

Cette première évaluation des intrants vise à dégager a priori les grandes lignes de la stratégie. Elle est parallèle à l'évaluation de contexte « ex post ». Elle relève des mêmes démarches, des mêmes prises d'informations. Mais, au contraire de l'évaluation de contexte, qui a pour but de fixer les objectifs, elle a pour but de préciser les stratégies de mise en oeuvre.
Au lieu de se demander « les objectifs sont-ils réalistes compte tenu des stratégies et moyens que l'on peut mobiliser ? », elle pose la question « quelles stratégies et quels moyens utiliser pour atteindre l'objectif ? ». Il s'agit de deux questions entre lesquelles il convient de faire plusieurs va-et-vient avant de finaliser tant les objectifs que les stratégies.

i2. L'évaluation des intrants « ex post » : une question de réalisme

Dans sa composante « ex post », l'évaluation des intrants vise à affiner les stratégies pressenties, notamment sur la base d'une première expérimentation menée à la suite de l'élaboration du prototype. En quelque sorte, elle se nourrit d'une première évaluation de produit (de même d'ailleurs que d'une première évaluation de processus) pour jouer sa fonction de délimitation des stratégies.
Pour l'essentiel, elle couvre la phase 2. Elle commence avec l'élaboration du prototype, et se termine avec la mise au point de l'architecture.

3.3. L'évaluation de produit

D'autres opérations visent à évaluer le projet d'informatique pédagogique une fois que ce dernier est élaboré, en tout ou en partie (phases 3 et 4).
Il s'agit de l'évaluation de produit (p), au sens de STUFFLEBEAM. C'est celle à laquelle il est fait référence le plus spontanément quand il est question d'évaluation de didacticiel, mais on a vu qu'il serait réducteur de ne prendre en compte que ce type d'évaluation dans le cadre d'un projet, même si la grille d'évaluation utilisée ne se limite pas aux aspects technologiques mais propose de tenir compte également d'une certaine image de ce qu'est un élève, son apprentissage, son activité (DONNAY et ROMAINVILLE, 1984).

L'évaluation de produit comprend elle aussi deux composantes.
Elle porte tout d'abord sur le produit informatique lui-même, indépendamment de sa mise en oeuvre, ainsi que sur les documents d'accompagnement. On pourrait l'appeler évaluation du produit « ex ante », qui commence d'ailleurs lorsqu'on évalue le prototype.
Elle porte ensuite sur les effets provoqués par l'utilisation du produit informatique. Il s'agit de l'évaluation de produit « ex post ».

p1. L'évaluation du produit « ex ante » : une opération multiforme.

Cette évaluation, qui a lieu avant le début de la phase 4, c'est-à-dire avant la phase d'utilisation, concerne essentiellement les projets se concrétisant par un didacticiel. Elle pose la question de la qualité du produit informatique. La question générale « le produit est-il bon ? » est toutefois bien trop vaste. Il ne s'agit pas d'une seule question, mais bien d'un ensemble de questions, à poser au terme de la phase 3, et reflétant différents points de vue (DE KETELE et ROEGIERS, 1993). Retenons principalement :
* l'efficacité interne - le produit est-il bien celui que l'on désirait obtenir ? Par exemple, elle consiste à se demander si les fonctions qu'on déclarait viser sont effectivement celles qui sont développées ;
* la conformité - le produit répond-il aux normes en la matière ? Cette évaluation pose les questions de savoir si le produit est conforme aux programmes d'enseignement, aux exigences scientifiques en la matière, s'il est conforme aux exigences en termes de hardware, de respect des droits,...

L'évaluation d'un produit informatique, comme celle de tout produit, est donc toujours une opération multiforme, qui nécessite de prendre en compte plusieurs angles de vue.

p2. L'évaluation du produit « ex post » : une question d'efficacité externe

Cette évaluation du produit « ex post », que l'on peut aussi qualifier d'évaluation des effets, comprend les opérations qui visent à évaluer la façon dont le projet d'informatique pédagogique est effectivement mis en oeuvre. Ce sont celles qui sont relatives à la phase 4.
Elles posent la question de l'efficacité externe, au sens de DE KETELE et ROEGIERS (1993) : le produit est-il celui qui permet de répondre aux besoins que l'on avait déterminés ? Produit-on les effets désirés ? Par exemple, face à un besoin de développer des capacités d'analyse, on se demande si le didacticiel de résolution de problèmes permet de répondre à ce besoin, ou s'il ne fallait pas avoir recours à d'autres solutions, y compris non informatiques.

Seule cette évaluation permet de valider a posteriori la décision de concrétiser le projet. Ce n'est que si les effets escomptés sont atteints de manière suffisante que l'on pourra dire - avec certitude - à la fois que le projet est pertinent et le produit de qualité.
Cette évaluation rencontre deux types de problèmes :
* d'une part, la difficulté d'isoler les variables. La réussite ou l'échec d'un projet d'informatique pédagogique peut être due au produit utilisé (le didacticiel, le logiciel-outil,), mais aussi à l'enthousiasme des enseignants, à leur formation, à la nouveauté du processus, à l'adéquation du découpage des contenus et du type d'élèves concernés, etc. Il est donc toujours difficile de généraliser les résultats d'une évaluation des effets, même réalisée avec rigueur ;
* d'autre part, l'évaluation des effets ne doit pas se cantonner aux effets immédiats mais également porter sur les effets à long terme. Par exemple, pour un didacticiel de conjugaison, il ne suffit pas de mesurer l'efficacité d'un didacticiel par un test de maîtrise orthographique. Encore faut-il que les élèves transfèrent leurs acquis. Et si - dans le meilleur des cas - on pouvait montrer un transfert, il faudrait encore pouvoir estimer dans quelle mesure il est imputable au projet.
Ce sont bien sûr là des difficultés communes à toute évaluation des effets d'un processus d'enseignement-apprentissage et qui mettent en évidence - une fois de plus - la complexité d'un processus d'évaluation.

4. Un modèle en escalier

L'approche de ces trois évaluations, avec pour chacune une composante « ex ante » et une autre « ex post », suggère dès lors une évaluation de projet d'informatique pédagogique « en escalier », dans lequel les marches - correspondant aux différents moments d'évaluation - se superposent partiellement, ce qui reflète bien ces va-et-vient incessants entre objectifs, stratégies, processus et produit.
Le schéma de la figure 2 permet de visualiser ces différents moments d'évaluation.

La réalité d'un projet d'informatique pédagogique est donc complexe. On ne peut le réduire ni à des objectifs sur papier, si intéressants soient-ils, ni à des moyens, si importants soient-ils, ni à un processus d'élaboration, si harmonieux soit-il, ni même à un produit, si exemplaire soit-il. Seul l'équilibre entre ces éléments peut garantir la réussite du projet. Le maître-mot reste des évaluations régulières et interactives, à tous les niveaux de l'élaboration du projet. Elles ne requièrent pas nécessairement un dispositif pesant. Elles peuvent être légères, tout en finesse : il leur suffit avant tout de poser les bonnes questions.

Références bibliographiques

BAGLEY C. & HUNTER B. (1992), Restructuring, Constructivism and Technology, Educational Technoloy, pp. 22-27.
BOURGEOIS E. & ROEGIERS X. (1993), Évaluer les projets de formation continue - Une révision du modèle de Stufflebeam, in DELORME C. (1994, à paraître), L'évaluation de la formation continue, Paris : E.S.F.
DE KETELE J.M. & ROEGIERS X. (1993), L'évaluation - Approches et démarches, Louvain-la-Neuve : CIACO
DEPOVER C. (1987), L'ordinateur media d'enseignement - Un cadre conceptuel, Bruxelles : De Boeck Université
DEPOVER C., GILLET E. & VERBRUGGEN I. (1993), Une expérience d'intégration de logiciels-outils dans l'enseignement fondamental, Recherche en éducation - théorie & pratique, n° 13, pp. 15-18.
DONNAY J. & ROMAINVILLE M. (1984), Grille d'analyse de didacticiels, Namur : Centre O.S.E.
ENTWISTLE N., ODOR P. & ANDERSON C. (1987), Anticiping the experience of higher education through computer simulation, Higher Education, 16, 337-355., cité in WOUTERS P. & DE KETELE J.M. (1993), Les dispositifs de préparation des étudiants à l'enseignement supérieur et universitaire, Res Academica, Vol. 11, n° 1, 41-72.
GERARD F.M. & ROEGIERS X. (1993), Concevoir et évaluer des manuels scolaires, Bruxelles : De Boeck Université.
LEBRUN M. (1991), Possibilités et méthodologies d'intégration d'outils informatiques dans l'apprentissage des sciences, Recherche en éducation - théorie & pratique, n° 7, pp. 15-29.
MORIN A. (1992), L'évolution de la recherche en technologie éducative, CIPTE, pp. 287-292.
STUFFLEBEAM D.L., FOLEY W.J., GEPHART W.J., GUBA E.G., HAMMOND R.L., MERRIMAN H.O. & PROVUS M.M. (1980), L'évaluation et la prise de décision en éducation, Victoriaville (Canada), N.H.P. (1974 pour l'édition américaine).

BIEF