Les problèmes rencontrés dans l’apprentissage de la programmation

Les problèmes rencontrés dans l’apprentissage de la programmation

Un certain nombre d’études montrent que – contrairement au mythe de l’ « enfant programmeur » – les débutants en programmation éprouvent un certain nombre de difficultés importantes. Celles-ci peuvent être regroupées en trois moments (DU BOULAY B. et O. SHEA T.)
a. La planification : les erreurs ont trait, dans ce cas, au découpement logique et préalable de la tâche. Ex. : sous-spécifier le problème : ne pas prévoir ce qui se passe quand telles conditions ne sont pas remplies.
b. Le codage : il s’agit des erreurs concernant le langage utilisé (sa syntaxe, sa logique interne, etc.). Ex. : erreur de logique interne au langage : lire un fichier sans l’avoir ouvert.
c. Le debugging .
En LOGO, par exemple, des enfants de 9 à 15 ans éprouvent des difficultés dans les domaines suivants : (DU BOULAY B. et O.SHEA T. J.)
1) manque de spécifications ;
2) confusion des rôles de la machine : – chargeur de LOGO ;
– exécution ;
– édition ; – utilisation d’un programme LOGO.
3) croyance que le système stocke automatiquement un certain nombre de données ;
4) distinction nom/valeur d’une variable, d’une procédure.
Ex. : croire qu’un nom de procédure doit obligatoirement signifier ce qu’elle fait ;
5) distinction répétition/récursivité ; etc. Remarquons au passage qu’il ne s’agit pas souvent d’erreurs de syntaxe ou de règles sémantiques. Les auteurs notent également que les enfants ne décomposent pas assez leurs problèmes, construisent des procédures peu élégantes, n’utilisent pas les solutions apprises dans de nouvelles situations. Enfin ces problèmes semblent être d’une importance très variable d’un enfant à l’autre. Bref, il n’est pas sûr qu’un certain nombre de concepts riches (variable – récursivité) soit réellement maîtrisé par la plupart des enfants.
Un bel exemple de représentation erronée et systématique d’un concept de base est analysé dans un article de KURLAND et PEA. Il concerne la manière dont se déroule une procédure récursive en LOGO. « La plupart des enfants croient que le fait de placer le nom d’une procédure à l’intérieur d’elle-même provoque l’exécution d’une boucle à l’intérieur de la procédure, alors qu’en réalité, le contrôle passe à une copie de la procédure. Cette procédure est exécutée et, quand le processus est terminé, elle repasse la main à la procédure qui l’a appelée en dernier lieu. Les enfants adoptent des modèles mentaux de déroulement du programme qui marchent pour des cas simples, tels que des programmes constitués d’une seule procédure, mais qui se révèlent inadéquats quand le projet requiert une constitution de procédures plus complexes ».
Une étude intéressante de MENDELSOHN tente d’ailleurs de faire un parallèle entre les difficultés rencontrées par des enfants de 8 à 13 ans et leur niveau opératoire (en terme piagétien, leur niveau de développement intellectuel) : on donne aux enfants (après un entraînement de 10 heures au LOGO) un quadrillage représentant l’écran et un énoncé de programme que l’enfant est invité à exécuter lui-même en dessinant le trajet de la tortue. Deux types d’erreurs sont isolés : – les erreurs d’interprétation : erreur sur la signification d’une instruction ; – les erreurs de coordination : les instructions isolées sont correctement interprétées mais mal agencées ;
ex. : certains appliquent à la répétition une sortie de règle de distributivité : l’instruction (répète 4 [av 20 av 90 av 20] est « exécutée » de la manière suivante (répète 4 fois av 20, puis répète 4 fois av 90, etc.. Ces mêmes enfants passent une épreuve de « l’Echelle de Développement de la Pensée Logique » permettant de répartir les enfants en 3 groupes : niveau opératoire concret, niveau préformel, niveau formel. L’étude montre qu’il existe des différences significatives entre les moyennes des erreurs en fonction du niveau opératoire. En particulier de programmes dont la complexité va au-delà de la structure séquentielle semble requérir la mise en place des opérations formelles (10 – 11 ans). D’autres recherches chez des enfants plus âgés mettent également en évidence des difficultés d’appropriation de certains concepts : l’itération pour des enfants de 11 à 15 ans (LABORDE), la planification et la mise en évidence des implicites chez des élèves de 15 à 16 ans (SAMURCAY). Enfin, le GRAI (groupe de recherche sur l’apprentissage et l’informatique)(5) poursuit depuis plusieurs années des recherches exploratoires visant à mettre en évidence (5) Département Education et Technologie, FNDP, 61, rue de Bruxelles, Namur.
les difficultés rencontrées par des adultes lors de leurs premières initiations à l’informatique. Les observations sont réalisées d’une part à l’occasion de nos formations d’enseignants et d’autre part, en situation individuelle avec enregistrement des commentaires et des ordres donnés au clavier, l’adulte étant dans ce cas confronté à une première situation problème LOGO. Les premiers résultats permettent d’épingler un certain nombre de difficultés : a) La découverte des caractéristiques du dialogue homme-machine semble poser problème. Les adultes observés éprouvent notamment des difficultés à :
– cerner le type de langage : mode, temps, personne, degrés de simplicité, de complexité de la syntaxe, etc ; – cerner les caractéristiques de la tortue : elle a une orientation, etc. ; – accepter l’impossibilité de projeter sur la tortue une compétence linguistique ; contrairement à ce qui se passe dans le dialogue humain, les adultes ne peuvent supposer à aucun moment un « background » chez la tortue leur permettant de laisser les implicites habituels dans leurs discours.
b) Un autre problème important est la difficulté de cerner la fonction en cours de la machine : ils confondent ainsi l’exécution et l’édition, l’utilisation du programme et sa construction. Les comportements indicateurs de ces problèmes sont les suivants :
– tenter d’exécuter un programme dans l’édition ; – croire que les ordres donnés en mode direct sont enregistrés ; – en faisant exécuter un programme, ne pas « jouer le rôle  » de l’utilisateur ; – attribuer des contenus de variables dans l’éditeur ; – etc.
c) La confusion entre le nom de la variable et son contenu est également fréquente : pour certains, il est difficile de savoir quand on la définit et quand on lui donne une valeur ; le problème étant résolu, dans certains cas, en faisant les deux en même temps ! Ex. : POUR CARRE :20 Il est à noter que ce problème est en rapport avec celui évoqué au point a) : dans ce cas, l’adulte confond la définition de la procédure et son appel. Ce problème se retrouve quand il s’agit de manipuler les variables. Ex. : ECRIS « X pour écrire le contenu de X.
d) La distinction n’est pas toujours bien établie entre ce qui est conventionnel et ce qui ne l’est pas. Il n’est ainsi pas rare qu’on nous demande si le nom de telle ou telle procédure ou variable pourrait être modifié. Tout se passe comme si l’adulte, inhibé par les inévitables erreurs de syntaxe réalisées en début d’apprentissage, semble s’en remettre le plus possible à « ce qui a marché », y compris des désignations purement conventionnelles. e) Les nombreuses informations contenues dans les messages d’erreurs sont fort peu utilisées ; l’attitude face au « bug » est essentiellement passive (éditer la procédure, la relire), c’est surtout la formulation d’hypothèses et l’organisation de tests qui font défaut.

Les problèmes de transfert

En supposant le premier point réalisé, il reste, nous l’avons vu, une question fondamentale : les élèves ont-ils ainsi acquis des techniques générales de résolution de problèmes ?
PEA et KURLAND ont réalisé sur ce sujet une revue de la question intéressante. Ils font d’abord remarquer qu’il s’agit d’une « vieille idée dans un nouveau costume » et que les arguments ressemblent étrangement à ceux utilisés naguère pour la défense de la logique, de la grammaire et du latin. Passant en revue une série d’études visant à mesurer le transfert réalisé par les élèves des activités de programmation à d’autres types d’activités, ils concluent qu’il n’existe encore que très peu de preuves de bénéfices cognitifs importants. Ainsi des transferts n’ont pu être mis en évidence ni par des mesures de stratégies de résolution de problèmes, ni par des mesures plus proches concernant la rigueur mathématique ou l’acquisition de certains concepts mathématiques. Ces résultats peuvent paraître décourageants mais il faut cependant insister sur la nécessité d’affiner ce type d’étude dans deux directions au moins :
1) la finesse des mesures de transfert ;
2) la spécification du contexte de l’activité de programmation.
1) Les mesures réalisées sont en effet souvent trop globales (ex. : 5 résolutions de problèmes mesurées en termes d’échec ou de réussite) et trop éloignées des situations LOGO. Des mesures plus fines peuvent faire apparaître des différences significatives parfois dans des domaines a priori peu en rapport avec l’activité de programmation. Un bon exemple nous est donné par l’étude de BIDEAULT visant à mesurer l’impact d’une pratique LOGO sur une épreuve de construction de parcours.
Deux groupes équivalents sont constitués ; le premier seulement prend part, une matinée par semaine, à des activités LOGO. Les deux subissent en fin d’année une épreuve sur feuille de papier : l’enfant dispose d’un plan et d’un bonhomme en plastique ; il lui est demandé de construire un tracé de manière à rejoindre deux maisons sans passer par un certains nombres de points, de rédiger une marche à suivre destinée au bonhomme et enfin de trouver le tracé le plus court. L’analyse des résultats montre que :
a) Il n’y a pas de différence entre les groupes au niveau du type de stratégie employée.
b) Le groupe expérimental est plus précis dans ses ordres en employant plus souvent la mesure.
c) Le groupe expérimental utilise des stratégies de vérification du codage énoncé en utilisant le bonhomme en plastique.
d) Le groupe expérimental se montre davantage capable d’expliquer le comment de leurs actions. Les expressions verbales utilisées font appel à des comparaisons, à des mesures, etc. Les bénéfices ne se mesurent donc pas globalement en terme de réussite ou d’échec mais se manifestent par l’acquisition d’attitudes telles que l’utilisation d’un outil de vérification, la nécessité d’expliciter aux autres ses actions, de prouver ses résultats.
2) La question de savoir quels sont les bénéfices cognitifs de la programmation est également trop générale pour une autre raison. En effet, qu’entend-on par programmation ? Qu’a-t-on enseigné aux élèves ? Quel langage ? Combien de temps ? Dans quelles conditions ? Etc. Il est, en effet, important de préciser le contexte dans lequel les étudiants ont eu l’occasion d’exercer des activités de programmation car celles-ci vont influencer fortement les possibilités de transfert :
« La question du rôle du contexte dans l’apprentissage de la programmation est complexe parce qu’il ne s’agit pas d’une compétence unique. Tout comme la lecture elle englobe un grand nombre d’habiletés qui interagissent avec les connaissances antérieures de l’élève, sa mémoire, ses capacités de traitement de l’information, ses stratégies générales de résolution de problèmes telles que l’inférence, la génération d’hypothèses, etc.. L’entraînement à la lecture suppose une gamme étendue d’expériences avec différents genres (narrations, essais, poésie, débat) et avec différents buts. Tout comme la lecture est souvent assimilée à l’habileté de décodage, l’apprentissage de la programmation est souvent équivalente à l’apprentissage d’une syntaxe et d’un vocabulaire d’un langage ; alors que l’entraînement à la programmation, comme la lecture, est complexe et fortement dépendante du contexte. Nous devons donc commencer par préciser le contexte dans lequel la programmation a été mise en pratique et apprise. » (PEA et KURLAND p.144)