Avant de construire une programmation à l’aide de cartes « flèches », les élèves ont pour consigne de guider leur camarade en lui donnant des indications orales. La plupart des élèves utilisent un vocabulaire topologique de base : « avance tout droit », « recule » mais ne précisent pas le nombre de case sur lesquelles il doit avancer tout droit ou reculer. Le sens de rotation, par contre, est un véritable problème pour eux. En effet, ils demandent à leur camarade de tourner mais ce dernier ne sait pas dans quel sens. À partir de là, soit il anticipe la bonne rotation car il sait où il va devoir arriver soit il tourne dans la mauvaise direction et
le programmateur lui demande alors de tourner dans l’autre sens. Dans le premier cas, nous assistons à une stratégie d’évitement car cette difficulté n’en est plus vraiment une pour ces groupes-là. Dans le second cas, cette situation est source de confusion car l’élève « robot » ne sait plus où il en est et ne comprend pas pourquoi il s’est trompé de sens. Pour pallier ce problème, j’ai incité les élèves à utiliser des repères stables dans la salle : « Tourne vers la porte », « Tourne vers les fenêtres », « Tourne vers les vélos ». De là, les deux élèves se comprennent quel que soit leur position l’un par rapport à l’autre. Je constate que certains élèves utilisent encore les formes géométriques et ont du mal à employer un vocabulaire spatial afin de guider leur camarade jusqu’à la case arrivée.
o Stratégies mises en œuvre par les élèves avec les cartes « flèches »
De la séance n°3 à la séance n°5, le même type d’exercice est demandé aux élèves. Ils ont pour objectif de construire une programmation en prenant en compte la case départ et la case arrivée. Grâce à la répétition de cette tâche, les stratégies des élèves ont beaucoup évolué. Au début, les élèves ont tendance à adopter des stratégies qui n’aboutissent pas à une véritable programmation. Ces dernières ressemblent énormément à celles développées lors de la séance n°2. Les élèves montrent les cartes en ne donnant aucune autre indication ou bien au contraire en décrivant le déplacement que doit exécuter l’élève-robot. Puis d’autres stratégies sont apparues telles que le fait de poser les cartes sur la case où se trouve le camarade. Le déplacement de celui-ci est alors facilité à condition que la carte soit correctement orientée.
Puis, l’apparition de la bande blanche comme support induit la construction d’une programmation concrète communicable à son camarade qui peut être conservée et peut prendre diverses formes.
J’ai différencié deux grands types de stratégie : celles qui se construisent pas à pas et celles qui sont réfléchies d’un seul coup puis vérifiées par l’élève jouant au robot.
- Comme pour les formes géométriques, certains élèves se contentent de montrer la carte puis attendent que leur camarade se déplace sur le tapis. En général, les groupes utilisant cette stratégie non experte ne remarquent pas les erreurs de déplacement de l’élève-robot ou bien indiquent la direction en montrant avec le doigt. Il n’y a aucune trace de la programmation ce qui, de fait, empêche une vérification du programme. Ces groupes ont besoin de la présence d’un adulte pour les guider à chaque étape de la programmation. La stratégie juste au-dessus de celle-ci serait de donner les indications à l’oral en même temps que de montrer les cartes ce qui permettrait l’utilisation du vocabulaire topologique.
Image 12 : Présentation d'une stratégie d'élève : montrer les cartes les unes à la suite des autres à "l'élève robot"
- D’autres groupes montrent les cartes et les placent ensuite les unes à la suite des autres pour mettre en place leur programmation au fur et à mesure de l’avancée de leur camarade. Cette stratégie permet au programmateur de voir où se trouve son camarade étape par étape. Il n’a pas besoin d’imaginer les déplacements sur l’ensemble du parcours en une seule fois.
Image 13 : Phase de recherche de programmation Image 14 : Phase de recherche : début de programmation d'un parcours
- Un groupe a créé la programmation en une seule fois en ligne de la gauche vers la droite au bord du tapis puis a décidé de mettre les cartes en tas et de la transmettre à l’élève qui doit se déplacer sur le tapis comme le robot Blue bot. Ce dernier prend le tas et le place devant lui dans le but de tourner à chaque fois dans la bonne direction. L’élève-robot constate et communique à son programmateur les erreurs éventuelles et lui redonne le paquet de cartes. La programmation est alors vérifiée carte par carte en montrant le trajet avec le doigt sur le tapis. Le robot teste le programme rectifié et valide ou non cette nouvelle version. La vérification est effectuée à la fin de la programmation par les élèves eux-mêmes. Le programmateur identifie également les erreurs pendant que son camarade exécute son programme. La mise en œuvre de cette stratégie nécessite néanmoins une bonne communication et collaboration au sein du binôme.
- Une autre stratégie, quasi similaire à celle explicitée précédemment, utilise la même organisation mais cette fois-ci, le programmateur garde son programme sous forme de tas et le dicte à son camarade. Cette méthode empêche le robot de décoder le parcours proposé mais a également pour effet d’éviter les erreurs de décodage de ce dernier.
- Enfin, le reste des élèves construisent leur programmation en entier en posant les cartes les unes à la suite des autres puis demandent à leur camarade d’exécuter le programme. Il parvient alors à conclure si sa programmation comportait des erreurs ou non. Cette stratégie est efficace si l’élève-robot ne commet pas d’erreur de décodage du parcours et de déplacements.
Je remarque que les groupes utilisant ces stratégies parviennent plus facilement à mettre à jour et à rectifier des erreurs de programmation. Dans les stratégies de construction pas à pas, les élèves ne reviennent pas sur leur programmation en la faisant faire entièrement du début à la fin sans arrêts à leur robot. Ils ne peuvent donc pas vérifier si une erreur est présente ou non.
o Difficultés rencontrées par les élèves
Les difficultés ont été classées suivant trois critères : celles étant liées au matériel, celles relatives au programmateur et enfin celles concernant l’élève jouant au robot.
Les difficultés liées au matériel
Tout d’abord, je remarque que les élèves n’ont pas pensé par eux-mêmes à poser les cartes les unes à la suite des autres pour garder une trace de la programmation construite. J’ai donc dû induire cette stratégie. Nous pouvons également penser que l’absence de matériel peut aussi être à l’origine de l’absence de cette stratégie au début de la séquence d’apprentissage. En effet, lors de la quatrième séance, j’ai distribué à chaque binôme une bande de papier plastifiée avec de la patafixe. À partir de là, tous les groupes ont commencé à construire leur programmation sur cette bande.
Cependant, des difficultés quant au sens d’écrire du programme sont apparues. En effet, la majorité des élèves placent les cartes de la droite vers la gauche. Pour pallier ce problème, j’ai modifié les bandes de papier lors de la séance n°4 (deuxième groupe) et n°5. J’ai ajouté une grande gommette ronde pour indiquer le point de départ de la programmation.
Mais cela ne suffit pas car les élèves tournent la bande pour placer la gommette à droite. J’ai donc agrémenté le support d’une flèche pour indiquer le sens de l’écriture. Pour être certaine que les élèves ne commettent plus d’erreur à ce niveau-là, j’ai tracé une ligne verte en bas de la bande, je leur explique en début de séance qu’elle doit toujours être située en bas, c’est-à- dire vers eux.
L’ajout de cette ligne verte a été bénéfique car les erreurs étaient moins nombreuses. De plus, j’ai remarqué que les élèves se corrigeaient mutuellement quant à l’orientation de cette bande, support de leur programmation. C’est peut-être également dû à une insistance plus accrue de ma part lors de la passation des consignes.
Une dernière difficulté, et pas des moindres, s’ajoute à cette liste et correspond davantage à l’usage du matériel mis à disposition. L’élève créé sa programmation au bord du tapis face à lui puis demande à son camarade de l’exécuter pour vérifier son exactitude. Le programmateur ne prend pas l’initiative de tourner le programme pour que son camarade puisse le lire correctement. Ce dernier le déchiffre donc à l’envers ce qui peut être à l’origine d’erreurs de déplacements de sa part. De plus, nous pouvons ajouter que lorsque l’élève se trouve de dos à la programmation, il se tourne pour la lire de nouveau et perd souvent sa position initiale. J’en conclus que le matériel support de la programmation (bande de papier) n’est pas tout à fait adapté à la situation.
Pour pallier ce problème, une stratégie mise en œuvre par quelques groupes se révèle surement plus pertinente car elle réduit les erreurs pouvant éventuellement être commises par l’élève-robot. En effet, les cartes sont dans sa main, correctement orientée et le suivent à chaque déplacement.
Une autre solution aurait été un matériel plus solide et plus facilement transportable tel que la barre de programmation Blue bot.
Figure 3 Barre de programmation Blue bot @copyright9
Les difficultés relatives au programmateur
Au début de la séance n°3 et jusqu’au début de la séance 5, les élèves ont eu du mal à placer correctement les cartes « X » pour supprimer le programme précédent et « Go » pour faire démarrer le robot. Soit les élèves ne les utilisaient pas du tout soit ils les plaçaient n’importe où dans la programmation. Ce phénomène peut s’expliquer par le manque de manipulation du robot pédagogique. En effet, les élèves ont eu jusqu’à la séance 4 une seule fois la possibilité de prendre en main Blue bot. Ils se sont trop peu servis de ces touches pour pouvoir les maitriser totalement et les utiliser correctement lors de la construction d’un programme.
Image 16 : Programmation d'élève illustrant la difficulté à placer les cartes "X" et "GO"
Je constate qu’à partir de la séance n°4, où les élèves vérifient leur programmation à l’aide du robot, l’utilisation des cartes « X » et « GO » se démocratise et leur placement devient de plus en plus naturel et spontané. En effet, je remarque que certains binômes commencent d’abord par positionner la croix au début de la bande et « GO » à la fin avant même de commencer la programmation. C’est devenu un automatisme pour eux, ils ont compris et maitrisent désormais le fonctionnement de l’outil numérique Blue bot.
Je remarque toutefois que lorsqu’une des deux cartes est manquante c’est très régulièrement la carte « GO ». Celle-ci est un peu artificielle lorsque les élèves sont en phase de recherche de leur programmation. Elle l’est encore plus lorsque les élèves utilisent une stratégie de construction de programme pas à pas.
La deuxième difficulté concernant le programmateur se situe au niveau de la position de son camarade-robot sur la case départ. En effet, ils construisent une programmation tout à fait correcte mais quand vient le temps de la vérification, leur camarade change d’orientation sur la case départ ce qui rend la programmation erronée. L’élève doit donc retenir la position de départ de son camarade pour qu’il puisse vérifier sa programmation dans de bonnes
conditions. J’aurais dû imposer une position de départ à tous les binômes mais rien ne garantit son maintien jusqu’à la fin de l’activité.
La plus grande difficulté des programmateurs concerne le sens de rotation des robots. Les élèves connaissent les mots « droite » et « gauche » mais ne les maitrisent pas encore concrètement. Outre le vocabulaire topologique, pour réussir cet exercice, les élèves doivent se décentrer, c’est-à-dire se mettre à la place de leur camarade pour savoir dans quel sens il doit tourner. Deux élèves ont utilisé une stratégie pour pallier ce problème et garantir le choix de la bonne carte « tourner » (soit à droite, soit à gauche). L’élève choisit une carte, se place derrière son camarade tout en restant autour du tapis puis place la carte devant elle en faisant attention à l’orientation de celle-ci. Elle observe alors la direction que fait prendre cette carte au robot-élève. Elle essaie ensuite avec d’autres cartes jusqu’à ce qu’elle trouve celle qui lui convient. Les élèves ont du mal à différencier les cartes « tourner à gauche » et « tourner à droite » et les testent donc plusieurs fois de suite la même carte.
Après une mise en commun en fin de séance, de plus en plus d’élèves utilisent cette stratégie. Plutôt efficace, elle permet aux élèves de prendre la place du robot et de diminuer le nombre d’erreurs. En effet, lorsque les élèves s’imaginent dans leur tête les déplacements de leur camarade, beaucoup d’erreur sont commises. Elles sont principalement dues à une non- décentration de la part des élèves programmateurs, celui-ci ne prenant pas en compte les différences de point de vue entre lui et son camarade-robot.
Prenons l’exemple de la configuration de parcours la plus travaillée durant cette séquence d’apprentissage.
Certains élèves pour éviter ce problème choisissent une carte et l’orientent dans le sens qu’ils souhaitent sans prendre en compte le petit robot Bee bot qui doit toujours être vers le bas. Pour induire la bonne orientation des cartes « tourner », j’ai ajouté une gommette en bas de la carte, elle doit toujours être vers l’élève. J’ai alors constaté des améliorations mais trois élèves continuent à commettre cette erreur.
La mauvaise orientation des cartes ne concerne pas uniquement les cartes « tourner » mais aussi les cartes « avancer tout droit » qui sont quelques fois couchées. Les élèves ont voulu illustrer le déplacement du camarade-robot car celui-ci ne se déplace plus vers le programmateur mais parallèlement à lui.
Image 18 : Illustration d'une difficulté : mauvaise orientation des cartes "avancer tout droit »
Les difficultés relatives à l’élève jouant le robot
La première difficulté concerne le respect des déplacements spécifiques du robot. Il tourne d’abord sur lui-même avant de changer de case. Le camarade-robot doit donc respecter ce déplacement à la lettre pour que le programme soit correct. Je remarque néanmoins un grand nombre d’élèves-robot anticipant la rotation sur eux-mêmes lorsqu’ils se trouvent au bord du tapis. Le programmateur ne la prend en compte, oublie donc une carte dans la programmation et continue son programme comme si rien ne s’était passé. Ce comportement est difficilement interprétable même s’il concerne une grande majorité des élèves. Il peut être causé par la volonté de l’élève d’avoir une vision sur la totalité de l’espace dans lequel il est en train d’agir mais aussi par une anticipation de l’élève-robot car il connait déjà le chemin qu’il va devoir emprunter.
Dans de nombreux binômes, des erreurs sont commises non pas dans la programmation mais dans l’exécution de cette dernière, ce qui a des répercussions sur la
programmation elle-même. L’élève robot ne se déplace pas exactement comme l’a prévu son camarade, il n’aboutit donc pas au point d’arrivée initialement prévu. Le programmateur décide alors de modifier sa programmation sans penser une seule seconde que l’erreur peut provenir de son camarade.
Inversement, une programmation erronée peut être considérée comme juste par le binôme car l’élève-robot ne l’a pas respectée à la lettre.
La validation par les élèves est alors remise en cause durant cette phase. En effet, sans la vérification de l’adulte, nous ne pouvons pas être certains de la validité de la programmation car des erreurs peuvent se glisser à tout moment au cours de sa construction tant de la part du programmateur que de celle de l’élève jouant au robot. Cependant, au cours des séances, nous entendons régulièrement « Gagner ! ». Les élèves estiment qu’ils ont réussi l’exercice lorsqu’ils sont sur la case « arrivée ».
o Bilan des phases de recherche
Durant cette phase de recherche, j’ai été très présente auprès des élèves pour les aider à mettre en œuvre des stratégies plus efficaces et de plus en plus expertes. J’ai constamment rappelé le mode de déplacement spécifique du robot pédagogique Blue bot en manipulant directement les élèves pour leur faire sentir la rotation sur eux-mêmes qui précède l’avancée sur une autre case. De plus, je suis très régulièrement intervenue pour leur conseiller de se mettre à la place de l’élève-robot pour trouver la bonne direction et les amener peu à peu à se rendre compte qu’ils n’ont pas le même point de vue que leur camarade. Cette pratique est devenue plus spontanée lors des séances 7 et 8 même si l’intervention d’un adulte était quelques fois nécessaire
La même configuration de parcours a été travaillée lors des séances n°4 et 5 pour permettre à tous les élèves de réussir. Mais cette répétition a été utile pour tous les élèves de la classe. En effet, seul 2 groupes ont réussi à construire une programmation du premier coup lors de la séance n°5. Pour ces binômes-là, une complexification a été proposée : le changement de la position de départ en gardant les mêmes cases « départ » et « arrivée ». Aucun groupe n’a réussi ce nouvel exercice. Lors des séances 7 et 8, j’ai alors proposé une autre forme de différenciation pour les groupes ayant réussi la première étape : la présence d’une case interdite. Cette tâche a été mieux réussie et par un nombre de groupe plus important.
Les difficultés pourraient s’expliquer par le manque d’entraînement et de vécu dans cette tâche. En effet, de part cette complexification, la tâche demande à l’élève de se décentrer encore davantage. Or lorsque les élèves sont en phase de recherche, ce ne sont pas les programmateurs qui font l’expérience de l’espace. Ils observent de l’extérieur l’espace dans lequel évolue l’élève-robot. Cet exercice n’est alors possible que si l’élève jouant au robot est bien concentré, immobile et exécute la programmation sans aucune erreur afin de faciliter le travail de décentration de son camarade. Nous pouvons donc imaginer que l’utilisation du robot pédagogique Blue bot va simplifier la vérification du programme.
III. 1. d. Programmer le robot pédagogique à partir de sa programmation