Pour apporter des éléments de réponse à cette interrogation, il faut d'abord rappeler trois constats:
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'é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:
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...).
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!
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.
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.
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
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).
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
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
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.
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.