Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/06928.jsonl.gz/249

Programmer pour Apprendre ou Apprendre à Programmer
Traduction de " MENDELSOHN P., GREEN T.R.G. & BRNA P. (1990) - Programming languages in Education: The search for an easy start. In T. GREEN; J.M. HOC, R. SAMURCAY, D. GILMORE. "Psychology of programming" (175-194). New York: Academic Press.
Table des matières
UN CADRE POUR ANALYSER LA PROGRAMMATION PEDAGOGIQUE
PROGRAMMER POUR APPRENDRE OU APPRENDRE A PROGRAMMER
ALTERNATIVES: UN PROJET POUR LA PROGRAMMATION EDUCATIVE
Références Bibliographiques
Introduction
Le développement de l'informatique pédagogique dépend étroitement de différentes sources de contraintes matérielles, institutionnelles et humaines. L'enseignant qui décide d'utiliser un ordinateur dans sa classe n'a, au départ tout du moins, qu'une influence limitée sur ces contraintes. Il subit l'évolutions des matériels et des langages, il s'adapte aux choix politiques en matière d'équipement informatique plus qu'il ne participe aux décisions et il accompagne les transformations humaines plus qu'il ne les détermine. Pourtant, il reste à cet enseignant suffisamment d'alternatives pédagogiques pour qu'une réflexion sur l'adaptation des langages informatiques aux objectifs de l'enseignement ne soit pas inutile et stérile. Dans un premier temps, l'analyse de ces contraintes va servir à définir un cadre pour analyser les enjeux et les limites de l'informatique pédagogique; ensuite, la partie centrale de cet exposé abordera la question des objectifs assignés à l'activité de programmation à partir d'une revue de question sur des expériences concrètes réalisées avec des élèves; enfin, la dernière partie de ce chapitre comprend une analyse sur les perspectives offertes par le développement des logiciels spécialisés.
UN CADRE POUR ANALYSER LES PROBLEMES ET LES ENJEUX
L'environnement matériel
Les progrès rapides et spectaculaires, en matière de performance, des ordinateurs et des environnements logiciels, devraient inciter les décideurs à la plus grande prudence pour effectuer les choix pédagogiques indispensables à l'introduction des ordinateurs en classe. Comment et dans quels buts fautil utiliser les langages de programmation à l'école de façon à ce que cet usage et cet enseignement ne soient pas complètement dépassés dans 5 ans ?
Pour apporter des éléments de réponse à cette interrogation, il faut d'abord rappeler trois constats:
En d'autres termes, on pourrait dire que l'univers des possibles évolue relativement peu, seule la manière de les représenter est soumise à des changements qualitatifs importants. Par exemple, dans tout système de traitement de texte, on retrouve les mêmes fonctionnalités comme couper/coller, chercher, modifier, formater les pages, les lignes ou les caractères, etc... Par contre, leur mise en oeuvre peut différer sensiblement d'un logiciel à l'autre.
- 1. Il existe une organisation hiérarchique entre les langages de programmation (du plus bas niveau, le langage machine, jusqu'aux langages les plus évolués). Quand il souhaite aborder en classe des activités de programmation, l'enseignant doit choisir, en fonction des objectifs pédagogiques fixés, a) le niveau auquel il fera travailler ses élèves (en fonction du découpage de la tâche), et b) la nature des traitements à réaliser (chaque famille de langage induit une signification particulière par rapport à la tâche à effectuer).
- 2. l'environnement des systèmes de commandes subit une évolution qualitative notoire (système d'exploitation graphique, souris, écran tactile...).
- 3. au niveau des commandes proprement-dites, par contre, on note une certaine stabilité dans la nature des fonctionnalités proposées (ce fait se vérifie, par exemple, pour les différentes versions de Logo graphique disponibles actuellement).
Ce constat implique un travail de recherche pour identifier les invariants dont tout pédagogue à besoin pour enseigner les bases de la programmation. Ces invariants sont des compétences transposables dans le temps et dans l'espace des savoirs informatiques. On peut espérer que le choix des commandes va se stabiliser autour d'un certain nombre de fonctions et que ces fonctions, du moins pour ce qui concerne les langages utilisés à l'école, peuvent toujours être regroupées autour des principaux langages fondamentaux: à savoir tout ce qui permet d'écrire, de calculer, de faire des tableaux, de dessiner, d'organiser ou de gérer les connaissances.
L'environnement social et institutionnel
Les contraintes imposées par l'institution scolaire sont loin d'être négligeables même s'il est important de se dégager parfois des contingences matérielles pour imaginer des situations d'apprentissage radicalement différentes. L'organisation des savoirs en disciplines, les différents niveaux scolaires, et la formation des maîtres sont autant de facteurs auxquels l'enseignant doit faire face avant de pouvoir intégrer harmonieusement à son programme des activités ayant comme support l'ordinateur et comme objet l'apprentissage d'un nouveau langage.
L'école est aussi organisée en niveaux dont la pédagogie et le découpage disciplinaire peuvent s'avérer très différents: niveaux préscolaire, primaire, secondaire et supérieur. Ces constats nous invitent à se poser les questions suivantes:
Bien qu'il ne soit pas dans notre compétence d'apporter des réponses précises à ces interrogations, il est probable qu'elles jouent aussi un rôle déterminant dans les choix pédagogiques des enseignants concernés (voir sur ce thème, Bossuet, 1982).
- A quel niveau doit-on commencer une initiation à la programmation?
- Qu'est ce qui définit la spécificité des environnements de programmation à chaque niveau de la scolarité?
- Quelle importance relative doit-on accorder à l'anatomie fonctionnelle des ordinateurs, à la programmation, à l'utilisation de programmes disciplinaires, à l'exploration de nouveaux champs de savoir ou encore à l'utilisation d'aides au travail?
Le sujet apprenant
Les premières applications de l'informatique à l'éducation ont été marquées par un débat, souvent vif (Solomon, 1986), entre les tenants de l'enseignement programmé et les partisans d'un apprentissage ouvert sur la découverte et l'autoformation. Pour les premiers, l'informatique est essentiellement un outil efficace pour l'entraînement et la répétition de séquences d'enseignement (Suppes, 1979); pour les seconds, l'informatique est plus un médium, un support pour élaborer des environnements dans lesquels l'enfant est son propre constructeur de savoirs (Papert, 1980).
D'autre part, les connaissances scolaires sont organisées en disciplines. Chaque discipline revendique sa spécificité, ce qui est l'objet de l'approche didactique, et les relations entre ces disciplines se retrouvent dans les représentations que les enseignants et les élèves évoqueront spontanément en manipulant des langages de programmation. Le regroupement des commandes dans les manuels des langages de programmation évolué n'est pas sans relations avec ces découpages thématiques (commandes graphiques, mots et listes, opérations arithmétiques, variables...).
PROGRAMMER POUR APPRENDRE OU APPRENDRE A PROGRAMMER
Ces considérations générales nous conduisent naturellement à la partie centrale de ce chapitre dans laquelle quatre types de projets impliquant un langage de programmation vont être présentées. Dans ces illustrations le choix presque exclusif de Logo comme langage n'est bien évidement pas dû au hasard. Logo est le langage dont la pratique est dominante dans l'enseignement général. Cependant de nombreux constats dépassent ce choix et, chaque fois que cela s'avère pertinent, il sera fait référence à d'autres pratiques.
Il est possible de représenter ces quatre approches sur deux axes (figure 1).
Sur l'axe vertical, sont représentées les options qui consistent à utiliser Logo avec, comme idée directrice, l'hypothèse d'un transfert de compétences. L'intérêt du chercheur, dans cette perspective, porte moins sur la programmation, en tant qu'activité de mise au point de programmes, que sur l'exercice de compétences que le programmeur pourra réinvestir ensuite dans d'autres situations scolaires.
Sur l'axe horizontal, sont représentées, en les opposant aux premières, les pratiques des enseignants qui utilisent les langages de programmation en privilégiant l'idée que les enfants apprennent, avant tout, des contenus spécifiques et des savoir faire liés à la programmation.
Avant d'aller plus loin dans le détail de cette analyse, on peut déjà remarquer que les pratiques effectives dans la classe correspondent plutôt à ce qui se passe sur l'axe horizontal, alors que l'on invoque généralement l'existence de l'axe vertical (hypothèse du transfert) pour justifier ces pratiques!
Le transfert de compétences
L'hypothèse générale du transfert recoupe en réalité deux conceptions assez différentes:
- D'un côté, on trouve la position la plus classique à l'origine de la création de Logo. Un langage de programmation est considéré comme un médium qui permet de transmettre de nouvelles relations au savoir. L'enfant peut ainsi explorer sa propre manière de penser et se confronter profitablement à l'art des heuristiques (référence au terme transmettre). Cette perspective est défendue par de nombreux auteurs (Papert, 1980; O'Shea et Self, 1983; Solomon, 1986; Lawler, 1986). L'accent est mis sur l'autoformation et la découverte par l'enfant de ses propres stratégies de résolution. Ces auteurs évoquent d'ailleurs la pratique de la programmation comme une révolution dans la manière d'enseigner. Les savoirs sont transformés et rendent généralement caduques les compétences classiques enseignées à l'école. Ils se soucient en général peu des problèmes d'évaluation, car ils considèrent que tout ce qu'un seul élève peut faire doit pouvoir être fait par d'autres pour peu que l'on s'en donne les moyens.
- De l'autre, on trouve les auteurs qui défendent une perspective plus cognitiviste. A travers la pratique de la programmation, se développent chez les élèves des habiletés cognitives identifiables et transférables à d'autres situations (référence au terme développement). Parmi ces aptitudes élémentaires qui sont sollicitées par les activités de programmation, les plus étudiées ont été, le raisonnement temporel et analogique, les opérateurs mathématiques (Ross et Howe, 1981), la planification de l'action (Pea et Kurland, 1984), la correction d'erreur (Klahr et McCoy Carver, 1988), et le développement des opérations logiques et spatiales (Mendelsohn, 1986).
Transmettre une nouvelle relation au savoir.
Dans la perspective de Papert, Logo permet une meilleure approche de l'art des heuristiques. La force principale de la programmation structurée est que l'on peut créer des procédures, comme des blocs sépararables, pour obtenir une construction progressive de la solution ou pour résoudre des problèmes plus larges (un exemple de cette démarche est fournie par la procédure classique MAISON proposée aux débutants). Il est ainsi possible, en toute logique, de prendre conscience de la manière dont chacun est amené à découper un problème en unités élémentaires (chunks), pour ensuite coordonner ces unités en macroactions (structure de buts).
Dans l'exemple choisi ici pour illustrer cette direction de recherche, Howe et O'Shea (1978) ont essayé de valider l'hypothèse suivant laquelle l'enfant qui apprend la programmation Logo, a accès à un système de métaphores puissantes pour décrire le réel. Ces métaphores peuvent être liées au schéma corporel, (c'est-à-dire à l'utilisation de Logo pour signifier et préciser des déplacements), à la dénomination (c'est-à-dire au fait que les procédures ont un nom et peuvent être rappelées dans une autre partie du programme), à la décomposition d'un problème en sous-problème (programmation structurée). Pourquoi ne pas en déduire qu'il peut ensuite utiliser ces métaphores pour transmettre des connaissances à un tiers dans un contexte différent?
Pour valider cette hypothèse, Howe et O'Shea ont construit l'expérience suivante : Des enfants, certains ayant appris à programmer en Logo et d'autre ne sachant pas programmer, sont mis dans une position semblable à celle du jeu de la "bataille navale", devant un écran qui lui cache un comparse. Le sujet a, devant lui, une figure composée de petites formes géométriques sous la forme d'un puzzle; le comparse a, quant à lui, sur sa table une série de pièces, dont un sous-ensemble est identique à celles de la figure, mais elles sont mélangées à d'autres formes semblables. Le sujet de l'expérience doit expliquer au comparse, sans pouvoir lui montrer les pièces, comment construire la figure qui est devant lui.
Pour les auteurs, si les enfants, qui ont appris à programmer en Logo, ont appris quelque chose du point de vue des métaphores de communication (modularisation, dénomination, séquentialité...), ils seront mieux à même d'expliquer à leur camarade comment reconstruire la figure, que ceux qui n'ont jamais programmé. Les auteurs s'attendent donc à ce que les enfants "programmeurs" décomposent la figure en sous-ensembles pertinents, nomment ces sous-ensembles en utilisant des substantifs évocateurs et ne proposent à leur comparse que des actions exécutables. Les enfants "non-programmeurs" se limitant à l'énumération des pièces et donnant des consignes ambiguës.
Les résultats montrent que tout se passe comme si certains enfants avaient reconnu dans la situation une analogie avec la situation de programmation. Mais ces résultats sont forcément limités puisqu'aucune précaution méthodologique n'est prise pour pouvoir interpréter non-subjectivement les faits observés. Il n'en reste pas moins que ces considérations, et les réflexions pédagogiques associées à ces expériences, ont un impact non négligeables sur les pédagogues et peut les inciter à repenser certains objectifs pédagogiques dans leurs classes.
Développer des habiletés cognitives.
L'autre perspective de "l'axe des transferts" se caractérise par une approche expérimentale plus rigoureuse et par ses références explicites à la psychologie cognitive. Une "habileté cognitive" est une compétence associée à la manipulation d'opérateurs identifiables, non spécifiques à la programmation. De plus, cette compétence doit être suffisamment généralisable et exercée pour être réinvestie dans d'autres tâches. La recherche la plus représentative de ce type d'étude est celle que Pea et Kurland (1984) ont réalisé sur le développement des aptitudes à planifier les actions. Cette aptitude est évaluée par la capacité à optimaliser la représentation d'un parcours dont le nombre d'actions est trop important pour être géré directement en mémoire de travail. Les auteurs ont travaillé sur deux classes d'âge (7 et 11 ans), avec des élèves ayant fait une année de Logo, à raison d'une séance hebdomadaire d'une heure incluse dans le temps scolaire.
Pour Pea et Kurland, la planification n'est nécessaire que si plusieurs contraintes sont imposées au sujet par la situation, à savoir: a) la planification est le seul moyen pour résoudre le problème; b) la tâche doit être suffisamment complexe pour que les sousbuts ne soient pas mémorisables; c) le domaine de connaissance est suffisamment familier pour que les enfants puissent identifier les actions élémentaires à effectuer.
La situation-problème de référence a comme support la maquette, en trois dimensions, d'une classe avec des objets et des meubles (chaises, tables, plantes, etc...). Une porte représente le point de départ. L'objectif proposé aux enfants est de réaliser effectivement, sur la maquette, une série d'actions concrètes: arroser les plantes, effacer et laver les tableaux, disposer les chaises devant les tables, les laver, déplacer certains objets... Ces différentes actions peuvent être effectuées dans n'importe quel ordre, mais la consigne précise qu'il faut rechercher l'itinéraire qui minimalise les déplacements. Chaque élève a trois essais. Tous les sujets de l'expérience, ayant fait ou non du Logo, passe cette épreuve deux fois: comme prétest en début d'année scolaire et comme post-test en fin d'année. Différents indices de performance sont calculés pour chaque sujet.
Les résultats furent peu concluants pour l'hypothèse du transfert. En effet, les auteurs trouvent des différences attendues sur le facteur "âge" et relativement à l'ordre de l'essai, mais ils n'observent pas de différence significative entre les enfants ayant fait ou non du Logo (pas plus sur le type de stratégies utilisées que sur les indicateurs objectifs d'efficience). Pea et Kurland ont essayé, par une seconde expérience d'aller plus loin dans l'analyse du problème. Ayant émis l'hypothèse que la tâche de transfert est trop éloignée de ce qui est demandé habituellement de faire en situation de programmation, ils ont alors réalisé une version informatisée de cette même expérience. Au lieu d'être réalisées sur la maquette, les opérations sont simulées sur un écran d'ordinateur et l'enfant doit écrire la liste des commandes. Cette situation, qui pénalise pourtant les élèves du groupe témoin, n'a pas donné de meilleurs résultats.
Cette expérience, décevante dans ses résultats si on est un inconditionnel des thèses du transfert de compétence, amène à faire, au moins, trois constats (pour une analyse détaillée voir Crahay, 1987; Mendelsohn, 1988).
1) Il est irréaliste de penser qu'il puisse y avoir transfert d'une compétence aussi spécialisée que la planification après seulement un an de programmation à raison d'une heure hebdomadaire de pratique effective. Aurait-on l'idée de faire une expérience semblable pour n'importe quelle autre activité du même type ne faisant pas appel à l'informatique, comme la pratique du jeu d'échec, par exemple?
2) Peut être faut-il être plus réaliste et analyser plus en détail ce que font réellement les enfants avant de faire des hypothèses précises sur la nature du transfert attendu? Pea et Kurland (1984) soulignent aussi les difficultés méthodologiques liées à une mauvaise appréciation du niveau d'expertise atteint par les enfants "programmeurs". Pour contourner cette difficulté, Klahr et McCoy Carver (1988) proposent de soumettre le contenu de l'apprentissage et ce qui est supposé transférable à une analyse formelle préalable. Mais cette précaution, très coûteuse, est rarement prise par les chercheurs.
3) L'intérêt de Logo en classe n'est peut-être pas à rechercher, en priorité, dans cette direction. Un langage de programmation est avant tout un système de représentation et l'intérêt d'un tel système réside dans sa capacité à faire ressortir de nouvelles propriétés aux objets manipulés, tout en permettant l'exécution automatique de traitements complexes. Le bénéfice de l'apprentissage de l'arithmétique est moins de développer d'hypothétiques aptitudes à raisonner que de proposer un langage formel qui facilite le traitement symbolique de problèmes numériques complexes. Peut-être en est-il de même pour la programmation, ce thème de réflexion est au centre des pratiques correspondant au second axe de notre présentation.
L'acquisition de nouvelles connaissances
En considérant l'axe concerné par l'apprentissage des contenus (l'axe horizontal de la figure 1), il est possible également de mettre en opposition deux pratiques qui se différencient nettement du point de vue des objectifs. D'une part, on trouve l'idée qu'en programmant le sujet apprend, avant tout, à maîtriser des concepts informatiques: opérations de programmation, structures de données, notion de variable (référence au terme apprendre). De l'autre côté, on met plutôt l'accent sur l'enseignement des contenus abordés (le programme porte toujours sur une application); le langage de programmation sert alors de support à l'enseignement de la géométrie, de l'arithmétique ou encore de la grammaire (référence au terme enseigner).
La maîtrise des concepts informatiques.
L'apprentissage de la programmation à l'école n'a pas pour objectif de former des informaticiens mais plutôt des utilisateurs de l'informatique. On peut penser, néanmoins, que les concepts informatiques de base font partie intégrante de la culture informatique. A ce titre leur apprentissage a été considéré avec attention par les psychologues qui ont trouvé là un terrain de recherche particulièrement riche pour la recherche fondamentale. L'étude de la formation de ces concepts, les difficultés cognitives liées à leur maîtrise, leur filiation sont les principaux thèmes de recherche qui préoccupent les didacticiens de l'informatique (Rogalski et Vergnaud, 1987). Parmi les opérations étudiées, on trouve: l'itération (Soloway et al., 1983; Kessler et Anderson, 1986)), le branchement conditionnel (Rogalski, 1987), la récursivité (Anzai et Uesato, 1982; Rouchier, 1987; Mendelsohn, 1985; Pirolli, 1986). On peut aussi ajouter à cette liste des concepts plus simples, peu étudiées car implicitement liées aux précédentes: la séquentialité, la modularité et la notion de variable informatique.
La récursivité intéresse de nombreux auteurs en raison de son statut tout à fait particulier en programmation. C'est une opération puissante, triviale dans sa définition et qui pourtant pose de nombreux problèmes quand on souhaite l'enseigner dans ses formes les plus complexes. Pour Hofstader (1979), la récursion est un mode de raisonnement caractérisé par l'autoréférence et l'emboîtement des traitements (le mot "mot" a trois lettres). Roberts (1986) insiste sur le point de vue algorithmique. La récursivité est une manière de résoudre un problème en le réduisant à un ou plusieurs sous-problèmes qui sont, a) identiques dans leur structure au problème initial; b) plus simples à résoudre. Enfin, d'un strict point de vue informatique, la récursivité est une structure de contrôle de programme (dont l'écriture dépend du langage utilisé).
Devant les difficultés rencontrées par les élèves pour comprendre ce qui se passe dans une procédure récursive, nous avons mis au point une méthode d'apprentissage (Mendelsohn, 1985; Rouchier, 1987) qui consiste à reconnaître certaines caractéristiques figurales qui permettent à un graphique de se décrire de manière récursive. Pour cela, nous avons choisi un modèle de référence, le modèle de la récursivité centrale, qui peut s'écrire de la manière suivante:
POUR PROCEDURE :VAR
SI Prédicat [ACTION3 STOP]
ACTION1
PROCEDURE f(:VAR)
ACTION2
FIN
L'exemple prototype qui permet de faire comprendre aux élèves le fonctionnement de cette procédure est celui du téléski. En effet, il est possible d'imaginer une succession de téléskis qui emmènent le skieur au sommet des pistes. Chaque fois qu'il monte avec un téléski (ACTION1), il accumule potentiellement une descente (ACTION2) dont les paramètres sont liés à ACTION1 (dénivelée). La réalisation de celle ci est suspendue, et ne s'effectuera qu'au moment où le skieur aura décidé d'arrêter de monter. Arrivé au sommet, il peut alors faire n'importe quelle action, telle se reposer ou se substanter (ACTION3) et réaliser ensuite les descentes ainsi accumulées dans l'ordre inverse des montées.
A partir de ce modèle, on peut faire varier au cours de l'apprentissage: a) l'existence, le contenu et la structure des procédures ACTIONx, b) le nombre et la nature des fonctions de transformation associées aux variables. L'enseignement porte alors sur la conceptualisation des régularités observées lors de ces variations (figure 2).
L'élève apprend ainsi à utiliser une écriture récursive pour décrire des objets possédant des caractéristiques bien précises. Dans les exemples présentés, on peut insister sur la symétrie initiale et sur l'ordre dans lequel la figure se construit. Progressivement, l'enseignant peut introduire des sources de variations qui complètent petit à petit le schéma jusqu'à sa pleine puissance formelle. Cette technique d'apprentissage est la même que celle utilisée pour d'autres opérateurs comme la structure additive ou multiplicative en arithmétique.
POUR PROCEDURE1 :LONGUEUR
SI :LONGUEUR = 0 (STOP)
ACTION1
PROCEDURE1 :LONGUEUR - 10
FIN
POUR ACTION1
AV :LONGUEUR RE :LONGUEUR
LC TD 90 AV 20 TG 90 BC
FIN
PROCEDURE1 70
Cette procédure est une procédure classique avec récursivité terminale; ACTION2 et ACTION3 ne sont pas définies.
POUR PROCEDURE2
SI :LONGUEUR = 70 (STOP)
ACTION1
PROCEDURE2 :LONGUEUR + 10
ACTION1
FIN
PROCEDURE2 0
Cette procédure, qui utilise deux fois ACTION1 de part et d'autre de l'appel récursif, introduit l'idée d'une symétrie apparente avec un ordre inversé dans l'ordre d'exécution des deux parties du tracé.
POUR PROCEDURE3 :LONGUEUR
SI :LONGUEUR = 0 (STOP)
ACTION1
PROCEDURE3 :LONGUEUR - 10
ACTION2
FIN
POUR ACTION2
AV :LONGUEUR RE :LONGUEUR * 2
AV :LONGUEUR
LC TD 90 AV 20 TG 90 BC
FIN
PROCEDURE3 70
Cette procédure ajoute à la structure précédente, l'idée que chacune des moitiés du tracé peut porter sur des formes différentes (ACTION1 différent de ACTION2).
POUR PROCEDURE4 :LONGUEUR
SI :LONGUEUR = 0 (ACTION3 STOP)
ACTION1
PROCEDURE4 :LONGUEUR - 10
ACTION1
FIN
POUR ACTION3
TD 180
FIN
PROCEDURE4 70
Dans cette dernière procédure on peut dissocier les deux parties de la figure; la procédure gère maintenant deux tracés en "parallèle" à n'importe quel endroit de l'écran.
Exemple de progression à partir du schéma de référence de l'écriture de procédures récursives centrales en LOGO Figure 3
Enseigner des contenus scolaires.
Ce dernier thème traite de l'utilisation de Logo pour l'enseignement de contenus scolaires. L'accent est mis ici sur les contenus manipulés, le langage de programmation devient un support aux propriétés originales pour les représenter (Hoyles et Noss, 1987). Pour de nombreux enseignants c'est souvent l'unique projet qui les incite à utiliser Logo en classe. Plusieurs exemples originaux de cette pratique nous sont proposés par Bourbion (1986). Il s'agit d'applications pédagogiques dans lesquelles le contrôle de l'activité du sujet porte sur le contenu scolaire (essentiellement l'arithmétique et la géométrie). La programmation devient une activité implicite dont la maîtrise est souvent considéré comme un préalable au travail proposé.
Le problème que nous avons choisi comme exemple consiste, dans un premier temps, à éditer un petit programme graphique. Ce programme permet de construire deux murs de même hauteur (figure 3, première phase) avec des briques d'épaisseurs différentes à deux endroits P1 et P2. L'algorithme consiste à mettre une brique en P1, regarder si la hauteur du mur est plus basse en P2; si la réponse est négative, il faut continuer à mettre une brique en P1 et regarder à nouveau si la hauteur du mur en P2 est plus basse; si la réponse est affirmative, il faut aller en P2, y mettre une brique, regarder en P1 si la hauteur est plus basse...
Dans un deuxième temps, on se propose de faire subir à ce programme une transformation subtile qui consiste à dépouiller les procédures de tout leur support graphique (deuxième phase). On obtient ainsi un programme isomorphe qui, par généralisation, devient une procédure qui ne fait plus qu'exécuter un calcul bien connus des élèves: la recherche du Plus Petit Commun Multiple (en abrégé PPCM). La conceptualisation arithmétique retrouve, par cette technique, sa vocation première qui est d'épurer progressivement les actions que l'on est amené à exécuter dans la réalité afin de n'en conserver que les transformations essentielles. Le langage de programmation acquiert ainsi un statut de langage formel et peut même devenir, en tant que tel, un objet d'enseignement (voir aussi Vitale, 1987).
Première phase:
Mise au point d'une PROCEDURE POUR CONSTRUIRE 2 MURS
POUR CONSTRUIS
SI :H1 < :H2 [MUR1] [MUR2]
SI :H1 = :H2 [STOP]
CONSTRUIS
FIN
POUR MUR1
VA.EN "P1
AVANCE :H1
DONNE "EPAISSEUR :E1
POSEBRIQUE
DONNE "H1 :H1 + :E1
FIN
POUR MUR2
VA.EN "P2
AVANCE :H2
DONNE "EPAISSEUR :E2
POSEBRIQUE
DONNE "H2 :H2 + :E2
FIN
POUR MURS :E1 :E2
DEPART ......................... Initialise Donne "H1 0 et "H2 0
CONSTRUIS
RESULTAT ..................... EC PHRASE [Hauteur des Murs] :H1
FIN
? MURS 12 18
HAUTEUR DES MURS 36
Deuxième phase:
On débarrasse le programme de ses instructions graphiques en ne conservant que les calculs.
POUR DEPART
DONNE "H1 0
DONNE "H2 0
FIN
POUR MUR1
DONNE "H1 :H1 + :E1
FIN
POUR MUR2
DONNE "H2 :H2 + :E2
FIN
POUR CONSTRUIS devient ... POUR CALCULE
SI :H1 < :H2 [MUR1] [MUR2]
SI :H1 = :H2 [STOP]
CALCULE
FIN
La Procédure Pour Construire 2 Murs devient:
POUR PPCM
DEPART
CALCULE
RESULTAT ...... EC :H1
FIN
? PPCM 24 18
72
Procédure Pour Construire 2 Murs (d'après Bourbion, 1986) Figure 4
Alternatives: un projet pour la programmation éducative
Pour schématiser l'analyse précédente, on pourrait dire que dans le choix "Apprendre à programmer", Logo est, avant tout un nouveau langage qu'il faut maîtriser et qui peut, éventuellement, servir à l'enseignement de contenus conventionnels. Dans le choix alternatif, "Programmer pour apprendre", Logo est un médium qui sert à exercer des compétences spécifiques, terrain de sport pour s'entraîner ou miroir pour se voir résoudre des problèmes.
A cette alternative, qui nous enferme dans le choix entre l'hypothèse du transfert de compétence et l'hypothèse de l'acquisition de nouvelles connaissances, il est possible de substituer un autre projet que semble confirmer l'évolution actuelle des langages destinés à l'enseignement. Pourquoi ne pas considérer les langages de programmation comme des précurseurs à l'apprentissage de logiciels informatiques plus élaborés associés aux langages fondamentaux conventionnels (écrire, calculer, dessiner, organiser)? Cette voie est clairement celle qu'ont choisie les concepteurs de Logowriter (1). Au micro-monde des "tortues" programmables, ils ont associé le micro-monde du curseur et de la manipulation des mots, permettant par la même d'explorer l'univers des traitements de textes et de l'édition.
Cette proposition consiste à considérer l'apprentissage des langages de programmation et de leurs environnements comme une approche intégrée des logiciels d'aide à la conception. Si l'on se réfère aux systèmes de représenta-tion les plus conventionnels et non aux connaissances thématiques, les apprentissages scolaires portent essentiellement sur la lecture et l'écriture, sur les différentes formes de représentation graphique, sur le système numérique et les opérations arithmétiques, et enfin sur la logique et le raisonnement. Ces systèmes de représentation sont présents dans toute activité symbolique et ils sont plus ou moins radicalement transformés par le support informatique.
Les éditeurs de textes.
L'écriture est une activité présente dans tout travail d'édition de programmes. Un éditeur n'est rien d'autre qu'un traitement de texte, espace bien délimité avec ses fonctionnalités propres où l'on peut manipuler des mots, les déplacer ou encore les corriger. L'évolution récente des environnements de programmation (Logowriter, Smalltalk...) rend tout à fait compatible l'apprentissage des commandes d'un éditeur avec celles des traitements de texte professionnels. Le transfert de compétence est ici tout à fait réel et mérite d'autant plus d'être souligné que la possibilité de programmer des macro-actions sur ces logiciels est une activité similaire au micro-monde du curseur dans Logowriter.
Les éditeurs graphiques.
Les langages de programmation destinés à l'enseignement sont souvent réduits, par l'usage qui en est fait, à certains de leurs sous-ensembles graphiques. Le micro-monde de la tortue Logo, par exemple, permet d'aborder facilement tous les formalismes graphiques: point, ligne, orientation, déplacement, formes paramétrisables, systèmes de coordonnées. Ces formalismes sont présents, sous des représentations variées, dans tous les éditeurs graphiques proposés sur le marché qu'ils soient associés à la représentation de grandeurs numériques, à la construction de schéma ou encore à l'illustration de texte. Là encore l'évolution des pratiques pédagogiques observées et des environnements de programmation existant tend à rapprocher l'utilisation des langages classiques des logiciels spécialisés (bibliothèques de formes graphiques élémentaires paramétrisables, fonctions de remplissage, fonctions de réduction et d'agrandissement).
Le calcul numérique.
Tout programme nécessite la manipulation de dimensions, de fonctions numériques et de variables. Leur expression dans les langages de programmation classiques diffèrent peu de celles qu'on retrouvent sur une calculette programmable, un tableur ou une base de données. La programmation d'un tableur peut ainsi devenir un objectif réaliste pour l'enseignant qui utilise Logo et proposer une représentation intermédiaire à mis chemin entre les langages procéduraux classiques et les langages déclaratifs. En effet, chaque cellule du tableau contient soit une procédure, soit une valeur, sans que soit préciser l'ordre d'exécution du programme (voir aussi Orzech et Shelton, 1986).
Le raisonnement logique. Dernière composante, le traitement des relations logiques est aussi une donnée première de la programmation. Que ce soit la logique des prédicats proprement dite (opérateurs logiques), ou l'organisation du flux temporel du programme (raisonnement conditionnel, emboîtement des procédures), on retrouve ce traitement comme ossature de tous les programmes. On peut raisonnablement considéré la programmation structurée comme une sensibilisation à la manipulation des structures arborescentes qui sont elles mêmes au coeur de tous les systèmes de base de données, comme des systèmes experts.
Ces différents champs conceptuels peuvent être considérés comme des modules autonomes mais sont en général associés deux à deux pour former des unités plus larges spécialisées dans un domaine particulier de l'aide à la conception. Ainsi, l'association du traitement de texte et du calculateur programmable va générer le tableur qui permet de manipuler, sur la même structure de données, du texte et des calculs numériques. L'association du traitement de texte et de la logique (à travers la structure arborescente) engendre le gestionnaire de fichier qui n'est, tout compte fait, qu'une manière d'introduire des relations logiques sur des fragments de texte. La représentation graphique de données numériques (histogrammes, camemberts, courbes de fonctions...) associe les dimensions spatiales (angles, longueurs ou surfaces) à des valeurs numériques de référence; l'organigramme et le schéma par contre assimilent relations logiques avec des relations spatiales (proximité, emboîtements, partition...).
L'univers des pratiques pédagogiques et des langages de programmation pour l'école est en pleine mutation. Leur conception se rapproche maintenant davantage des logiciels d'aide à la conception qui ont fait leur preuve dans le grand public. Ils s'éloignent d'autant des systèmes professionnels dont ils étaient issus. Plus conviviaux dans leurs environnements, plus finalisés dans leurs possibilités, ils sont en train de devenir ce qu'ils auraient toujours dû être: des préfigurations intégrées de logiciels professionnels. La programmation éducative conservera ainsi son seul objectif légitime, proposer une sensibilisation aux différents concepts informatiques dans le but de préparer les enfants d'aujourd'hui à la culture informatique de demain.
Références Bibliographiques
- Anzai, Y. and Uesato, Y. (1982)
- Learning recursive procedures by middleschool children. Proceedings of the Forth Annual Conference of the Cognitive Science Society. Ann Harbour, MI.
- Bossuet, G. (1982)
- L'ordinateur à l'école. Paris: Presses Universitaires de France.
- Bourbion, M. (1986)
- Le choix Logo, Paris: Armand Colin Editeur.
- Hofstadter, D. (1979)
- Gödel, Escher, Bach: an Eternal Golden Braid, New York: Basic Books.
- Crahay, M. (1987)
- Logo, un environnement propice à la pensée procédurale. Revue Française de Pédagogie, 80, 37-56.
- Howe, J.A.M. and O'Shea, T. (1978)
- 'Computational metaphors for children', in F. Klix (ed.), Human and Artificial Intelligence, Berlin: Deutscher Verlag.
- Hoyles C. and Noss R. (1987)
- Synthesing mathematical conceptions and their formalisation through the construction of a logo based school mathematics curriculum. International Journal of Mathematics Education in Science and Technology, 18.
- Kessler, C.M. and Anderson, J.R.
- Learning Flow of Control: Recursive and Iterative Procedures. Human Computer Interaction, 2, 135-166.
- Klahr, D. and McCoy Carver S. (1988)
- Cognitive Objectives in a Logo Debugging Curriculum: Instruction, Learning, and Transfer. Cognitive Psychology, 20, 362-404.
- Lawler, R.W. (1985)
- Computer Experience and Cognitive Development: a child's learning in a computer culture. Chichester: Ellis Horwood.
- Mendelsohn, P. (1985)
- Learning recursive procedures through Logo programming. Proceedings of the second Logo and Mathematics Education Conference. University of London.
- Mendelsohn, P. (1988)
- Les activités de programmation chez l'enfant: le point de vue de la psychologie cognitive. Technique et Science Informatiques. 7, 47-58.
- Orzech, Z. and Shelton F.A. (1986)
- The Electronic Spreadsheet as a Didactic Learning Enhancement. Computer in Education, 10, 429-437.
- O'Shea, T. and Self J. (1983)
- Learning and Teaching with Computers, Artificial Intelligence in Education. Brighton: The Harverster Press.
- Papert, S. (1980)
- Mindstorm: Children, Computers and Powerful Ideas, New York: Basic Books.
- Pea, R.D. and Kurland, D.M. (1984)
- On the cognitive effects of learning computer programming. New Ideas in Psychology, 2, 137-168.
- Pirolli, P. (1986)
- A Cognitive Model and Computer Tutor for Programming Recursion. Berkeley: University of California.
- Roberts, E.S. (1986)
- Thinking recursively. New York: Wiley.
- Rogalski, J. (1987)
- Acquisition et didactique des structures conditionnelles en programmation informatique. Psychologie Française, 32, 275-280.
- Rogalski, J. and Vergnaud, G. (1987)
- Didactique de l'informatique et acquisitions cognitives en programmation. Psychologie Française, 32, 267-274.
- Ross, P. and Howe, J. (1981)
- Teaching mathematics through programming: Ten years on. In: R. Lewis and D. Tagg (Eds.), Computers in education. Amsterdam: North-Holland.
- Rouchier, A. (1987)
- L'écriture et l'interprétation de procédures récursives en Logo. Psychologie Française, 32, 281-285.
- Solomon, C. (1986)
- Computer environments for children: a reflexion on theories of learning and education, Cambridge (MA), Londres: The MIT Press.
- Soloway, E., Bonar, J. and Ehrlich, K. (1983)
- Cognitive Strategies and looping constructs: An empirical study. Communication of the ACM, 26, 853-860.
- Suppes, P. (1979)
- Current trends in computer-assisted instruction. In: M.C. Yovits (Ed), Advances in Computer 18, New-York: Academic Press.
- Vitale, B. (1987)
- Epistemology and Pedagogy of children's approach to informatics. Proceedings of the International Conference on Education, Bilbao.