ÉVALUER UN PROJET D`INFORMATIQUE PÉDAGOGIQUE

ÉVALUER UN PROJET
D’INFORMATIQUE PÉDAGOGIQUE :
UNE QUESTION DE QUESTIONSi
François-Marie Gerard, Xavier Roegiers
Bureau d’Ingénierie en Éducation et en Formation (BIEF)
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.
Louvain-la-Neuve
Introduction
• 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.
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…
• 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.
Pour assurer la cohérence et la pérennité d’un projet
d’informatique pédagogique, il convient de mettre en œuvre
un processus d’évaluation.
• 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.
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
d’informatique pédagogique
projet
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 ?
i
GERARD, F.M., ROEGIERS, X., (1994). Évaluer un
projet d'informatique pédagogique : une question de
questions, Recherche en Éducation - théorie & pratique,
nos 16/17, Bruxelles.
• 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
1
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
2
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 œuvre 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.
• une phase d’élaboration du produit, qui commence
avec la mise en œuvre de l’ensemble des contenusmatiè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.
1 Définition
du projet
de
Élaboration
2 Finalisation
4 Utilisation
l'architecture 3 du produit
du produit
Fixation des objectifs
1.7. La mise en œuvre 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.
Analyse des contenus-matières
Architecture pédagogique
Architecture informatique
1.8. La mise en forme (« layout »)
Ressources et contraintes
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.
Prototype
Mise en forme
Mise en œuvre des contenus
1.9. L’utilisation
Utilisation
C’est la mise en œuvre du projet d’informatique pédagogique en temps réel auprès de la population-cible.
Figure 1 :
2.
composantes d’un projet d’informatique
pédagogique selon l’axe du temps
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
œuvre des contenus-matières, il faudrait s’être prononcé de
façon définitive sur l’architecture pédagogique et
l’architecture informatique.
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.
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 œuvre pour mener
le projet à bien ;
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
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é cidessus — des fonctions que le projet d’informatique pédagogique doit remplir.
Les questions portent également sur les possibilités de
mise en œuvre 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 œuvre, à é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).
4
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 œuvre.
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 luimême, indépendamment de sa mise en œuvre, 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.
5
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
œuvre. 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.
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.
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 logicieloutil,…), 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’enseignementapprentissage 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
6
Figure 2 :
Phases de l’élaboration et types d’évaluations d’un projet d’informatique pédagogique
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 soitil. 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).
7