Séance 17

Contenu de la séance

Dernière séance sur le pong. Après avoir conçu un pong (mono-joueur), les enfants l’avaient déjà transformé en casse-briques lors des séances précédentes. Ils ont eu pour mission cette semaine de le transformer en space invaders. Cette séance a aussi été l’occasion de tenter de nouvelles expériences : un ordinateur avec la solution à leur disposition, et un système de jetons pour se faire aider.

Déborah, animatrice à la MJC, nous a assistés durant cette séance, pour mieux découvrir l’atelier.

Retours

C’était la troisième séance sur le projet de pong, pour certains enfants, confirmant ainsi leurs capacités à restés intéressés par leurs créations, d’une séance à l’autre. Avant de démarrer l’atelier, la plupart des gens m’avaient indiqué que des enfants de cet âge n’étaient pas capables de rester concentrés sur une même activité durant plus de 30 minutes. Non seulement ils tiennent des séances de 2h complètes à travailler sur le même projet, mais ils sont désormais capables de reprendre leurs travaux plusieurs semaines de suite.

Les objectifs de la séance étaient :

1. avoir son jeu de pong qui fonctionne (la balle rebondi sur les murs et le plateau, et on perd si la balle touche le sol) ;
2. avoir ajouté des briques à casser avec la balle (les briques disparaissent quand la balle les touchent, et on gagne s’il ne reste plus de briques) ;
3. ajouter une fonctionnalité de tir au plateau, pour pouvoir faire disparaître des étoiles qui sont dans le décor, en plus des briques (mais qui, elles, ne disparaissent pas au passage de la balle).

La plupart des enfants avaient atteint les 2 premiers objectifs lors des séances précédentes. Le troisième objectif a été introduit grâce à une version complète du jeu que j’ai réalisé (il suffit de cliquer pour tirer).

De plus, cette séance était un peu particulière, puisqu’elle a donné lieu à 2 nouvelles expériences.

Système de jetons

Avec l’aide de Nicolas, je passe en général l’intégralité de la séance à courir d’un ordinateur à l’autre, pour aider les enfants qui sont constamment en demande d’aide. L’année avançant, je me rends compte que c’est de plus en plus fréquent que je constate que l’enfant n’a pas vraiment réfléchi à son problème avant de demander de l’aide. Ils maîtrisent de plus en plus Scratch, ils sont de plus en plus capables de comprendre leurs erreurs, et pourtant ils ne cherchent pas par eux-mêmes. Et c’est plutôt naturel, puisque c’est beaucoup plus éprouvant que se contenter de lever la main et attendre pour être débloqué par quelqu’un d’autre qui réfléchira à sa place.

Nous avions convenu à la fin de la séance précédente, de mettre un terme à cette habitude qui s’est installée petit à petit. Nicolas m’a proposé de mettre en place un système de jetons : chaque enfant a quelques jetons en début de séance, et chaque appel à l’aide lui coûte un jeton. Après, il se débrouille sans nous. Cette méthode permet de forcer l’enfant à se demander si c’est une bonne idée de griller son jeton pour son problème, ou s’il ne pourrait pas l’économiser en trouvant la solution lui-même.

Je leur ai donc fourni 5 jetons au début de la séance, qui sont en réalité de petits bouts de papiers avec leurs prénom imprimé dessus (pour éviter qu’ils ne se les échangent). La réaction des enfants a cette nouvelle a été mitigée… Globalement, ils ont bien compris qu’ils étaient piégés et que ça n’allait pas leur faciliter la vie. Pour ma part, j’ai été un peu mal à l’aise au début de la séance, avec l’impression que je faisais dès lors de la prestation de service, avec une monétisation de mon savoir (et les enfants adoptent très vite un vocabulaire commercial).

Mais rapidement, je me suis rappelé pourquoi on avait tenté de mettre ce système en place. Malgré cette possibilité d’aide limitée, certains enfants m’ont appelé à l’aide alors qu’ils n’en avaient pas du tout besoin. Je me suis retrouvé, comme trop souvent, à simplement leur demander de me lire ce qui était sous leurs yeux, et de m’expliquer ce que ça faisait. Ils se sentent alors idiot, parce qu’ils trouvent eux-mêmes la solution, simplement en faisant cet effort. Un autre exemple est la communication par messages dans Scratch : un lutin envoie un message toto (ou plus généralement quelque chose comme « xptrmdrrrrrloololoolllptdrrrrr ») aux autres lutins, pour leur demander de faire une action spéciale quand ils reçoivent ce message (c’est la seule façon pour communiquer entre lutins dans Scratch). Et bim, leur truc ne marche pas. Je leur demande qui est censé recevoir ce message, ils me montrent le lutin, et évidemment ils se sont gourés de message à la réception (c’était « loolololooololoolllmddrrrrrr » au lieu de « xptrmdrrrrrloololoolllptdrrrrr »). Et ils se sentent de nouveau idiot. Et ça fait plaisir de leur signaler qu’ils n’avaient pas besoin de moi, mais qu’ils ont pourtant crâmé un jeton pour ça.

Aucun enfant n’a utilisé l’intégralité de ses jetons. Certains ont appelé plusieurs fois d’affilée au début de la séance, mais ils se sont rapidement calmés. C’est un signe peut-être, qu’ils commencent déjà à comprendre ce qui cloche dans leur comportement.

Ils ont également été incités à s’entraider, ce qui permet d’obtenir de l’aide sans perdre de jeton. Nous en avons sentis certains un peu réticents à aider leurs camarades durant la séance (après tout, ils ont éventuellement « payé » pour avoir une solution, pourquoi la donner gratuitement…), mais il y a eu globalement plus d’entraide quand même que lors des séances passées.

Nous continuerons cette expérience lors des prochaines séances, avec quelques clarifications sur les règles, après cette première tentative :

• si nous estimons que l’enfant ne pouvait pas vraiment trouver tout seul la solution, ou qu’il s’agit d’un bug de Scratch, nous ne lui prenons pas de jeton pour le coup de main ;
• si nous venons nous-mêmes lui demander comment ça avance et que nous l’aidons, nous ne prenons pas non plus de jeton ;
• un jeton peut éventuellement être retiré, si un enfant est insupportable durant la séance.

Solution en libre accès

J’ai indiqué aux enfants au début de la séance, qu’un ordinateur était en libre accès dans la salle, avec une version du pong qui permet de tirer sur des étoiles. Ils ont eu le droit d’aller l’essayer quand ils voulaient, et ils avaient surtout le droit de regarder le code Scratch qui était dedans (en essayant de ne pas se taper dessus, pour accéder à l’ordinateur).

Cette seconde expérience se voulait complémentaire à la première. S’ils étaient bloqués parce qu’ils ne savaient tout simplement pas comment faire quelque chose, ils pouvaient aller voir directement comment j’avais résolu le problème dans ma version. Et sans griller de jeton.

Les réactions des enfants à cette nouvelle ont été : « ha mais non, je veux pas tricher » et « oh bah c’est trop facile, alors ».

La première réaction est très compliquée à contrer, et on la retrouve parfois quand un enfant regarde ce que fait un autre pour se débloquer. Le système scolaire, qui les a formaté, leur interdit de quitter leurs yeux de leur copie. Leur expliquer que s’inspirer ou regarder comment les autres font pour comprendre, ce n’est pas obligatoirement tricher, est très dur à leur faire avaler.

La seconde réaction est plus amusante. Ils ne se sont pas rendus compte que ma version du pong était obligatoirement différente de la leur, parce que nous n’avons forcément pas conçu le jeu de la même façon. Il ne s’agit donc pas simplement de recopier, il faut également comprendre ce que j’ai fait pour savoir ce qu’ils faut piocher. Et être ensuite capable d’appliquer ma solution à leur code-source. Aller « tricher » leur impose donc de lire du code et d’essayer de le comprendre… chose qu’ils ne sont pas du tout habitués à faire, y compris sur leur propre code.

Cette seconde expérience a certainement un peu nuit à leur créativité, puisqu’ils ont essayé de refaire ce que j’avais fait. Au-delà de cet aspect, elle a permis de fournir enfin une solution pour leur imposer de prendre du recul sur un programme pour essayer de le décortiquer. Et il y a fort à parier que qu’ils finiront par se dire qu’ils peuvent faire la même chose avec leurs jeux, quand il y a un comportement qu’ils ne comprennent pas.

À noter tout de même un enfant, qui a discrètement fait des aller-retours durant toute la séance, pour recopier petit à petit l’intégralité de mon code, dans son jeu. La recopie in extenso n’est pas forcément une mauvaise façon pour apprendre, mais je ne suis pas certain que ça lui ait été très bénéfique quand même. Malgré tout, un seul enfant a eu le réflexe de faire ça, ce qui est plutôt positif. On peut également noter qu’ils avaient un jeu à leur disposition, dans la salle, et qu’aucun enfant n’est resté plus de temps que nécessaire à jouer dessus, plutôt que travailler sur on projet. C’est une énorme évolution, vis-à-vis des premières séances de CodCodCoding.

Projets des enfants

Les projets sont de plus en plus aboutis, avec parfois plusieurs niveaux, la plupart du temps les règles du jeu expliquées, et de plus en plus de finitions intéressantes. Certains enfants ont aussi osé détourner les amélioration qui étaient proposées, d’une façon très intéressante (e.g. avec un fusil à la verticale en plus du plateau, un mode multi-balles au bout d’un certain nombre de points, etc.).

Certains cris de victoire, quand ils arrivent enfin à corriger un comportement qu’ils ne comprenaient pas, sont également plaisants à entendre.

• Projet de Clément
• Projet de Gaspard
• Projet de Lucie
• Projet de Ahmed
• Projet de Samuel
• Projet de Sarah
• Projet de Sofiane
• Projet de Vincent