Mis à jour le 11/07/2017
  • 15 heures
  • Facile

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

J'ai tout compris !

Transmettez grâce à la pédagogie de l’erreur

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Vous avez créé plusieurs petits programmes et testé des algorithmes. Pour cela, vous êtes sans doute passés par des phases de test, et vos essais n'ont sans doute pas toujours été fonctionnels. Pourtant, ils vous ont permis de comprendre l'utilisation des différents blocs dans Scratch.

En ce sens, on peut dire que l'erreur est riche d'enseignements. Mais ce n'est pas cette idée dont j'aimerais vous convaincre, puisque vous l'êtes certainement déjà : non, en fait, il s'agit plutôt ici de vous inciter à réfléchir sur la manière dont vous pourriez mettre en place un environnement qui valorise l'erreur en tant qu'étape incontournable dans le processus d'apprentissage.

La pédagogie de l'erreur

Eh oui, tout le monde se trompe ! Pourtant, on a beau répéter que l'erreur, en pédagogie, c'est essentiel dans le processus d'apprentissage, il n'en reste pas moins que les pratiques sanctionnent bien souvent durement ces erreurs, et cela est plutôt contre-productif. Alors, comment s'en sortir ?

Les pistes sont variées, et il n'y a pas de réponse absolue. D'ailleurs, je compte même sur vous pour ajouter et partager avec la communauté Class'Code vos propres méthodes à ce sujet. Voici cependant quelques éléments qui vous permettront de construire vos déroulés pédagogiques.

Les erreurs peuvent être dues à plusieurs choses : ça peut être lié, par exemple, à l'âge des enfants auprès de qui vous intervenez, et notamment leurs capacités psycho-motrices. Cela peut paraître évident, mais vous ne pouvez bien entendu pas concevoir un parcours de la même manière pour un adolescent de 14 ans, que pour un enfant de 8 ans. Celui-ci aura peut-être plus de mal avec certains concepts abstraits, et ses erreurs seront en quelque sorte des manifestations d'une incapacité physique à comprendre.

Mais une erreur peut aussi être provoquée par une mauvaise compréhension initiale du concept : plutôt que de la sanctionner, il faudrait donc s'appuyer dessus pour corriger la compréhension du concept (ou de la notion) qu'en a l'enfant. C'est un peu comme un indice qui révèle que là, quelque chose n'a pas été compris.

Le tâtonnement expérimental, pour désamorcer l'erreur, est souvent bien utile : on apprend en faisant (et je vous renvoie donc pour cela au dernier chapitre de la partie précédente ;) ).

On peut aussi faire en sorte que l'enfant garde une trace de ses erreurs par exemple. Il pourra ainsi voir comment les erreurs ont été les étapes de son apprentissage, et il n'aura plus peur de se tromper pour se lancer et faire. Eh oui, on amorce un cercle vertueux, car l'erreur est souvent le frein à l'action (on n'ose pas faire de peur de se tromper) et si on ne fait pas, on ne se trompe pas. Mais dans ce cas on n'apprend pas non plus. Inciter à faire et désamorcer l'erreur vont donc de pair.

Enfin, une fois que les erreurs ont été comprises, voire même une fois que l'enfant les considère comme triviales, il est essentiel de mettre en place un climat de bienveillance vis-à-vis des autres (qui font toujours l'erreur) pour soustraire à l'humiliation de l'erreur. Vous comprenez bien pourquoi. Quant au comment, je vous propose d'y réfléchir et nous y reviendrons dans la dernière partie.

Se tromper pour mieux apprendre à programmer

L'avantage de la programmation, c'est qu'on se trompe tout le temps. Enfin, c'est surtout qu'on peut tester son programme pratiquement immédiatement et si ça marche, eh bien… ça marche ! Sinon, c'est qu'il y a une erreur, ou un bug. Mais en tout cas, on peut repérer l'erreur très rapidement, et tenter de la corriger immédiatement.

À ce propos, laissez-moi revenir un instant sur la conception de l'histoire interactive. J'ai indiqué dans la vidéo que le programme aurait pu être conçu tout à fait différemment, et faire malgré tout la même chose. Le choix de séparer les différents événements en petits blocs n'est pas juste esthétique : cela permet de tester le fonctionnement des blocs indépendamment les uns des autres. Ainsi, si ça ne marche pas (c'est-à-dire si le programme ne fait pas ce que je souhaite qu'il fasse), je peux repérer l'erreur très vite et tester des choses pour la corriger aussitôt.

C'est une pratique très courante en informatique, pensez-y pour vos propres programmes !

Vous êtes aussi familier avec la notion de bug. Et des bugs, ou des erreurs, en informatique, ça arrive tout le temps, et personne ne trouve ça anormal (même si on trouve ça quand même un peu ennuyeux…). Combien de personnes n'entendez-vous pas dire « mon ordi a un bug ! » pour tout et n'importe quoi ? Ne devez-vous pas faire régulièrement des mises à jour sur votre ordinateur pour corriger des bugs ?

Et tout ça à cause des informaticien(ne)s qui font des bugs constamment lorsqu’ils construisent leurs programmes. Mais l'avantage, c'est qu'on peut se rendre compte de ses erreurs plus tard (à l'utilisation par exemple) et aussi les corriger plus tard : on ne peut pas tout savoir, tout de suite, et c'est d'ailleurs comme ça que progresse la connaissance.

Ceci dit, si, à la conception du programme, les différentes étapes ont été découpées de manière propre et logique, il devient nécessairement plus facile de corriger ses erreurs lorsqu’on s’aperçoit qu’il y a un bug quelque part : on pourra en effet identifier à quelle étape se situe l’erreur, en faisant par exemple des tests sur des petits blocs du programme qu’on aura su découper logiquement.

Savoir dire « je ne sais pas »

Bon d'accord. Je le dis. Allez.

Même moi, je ne sais pas tout. Voilà. Moi aussi, je fais des erreurs.

Mais enfin, vous aussi ! Ce n'est pas grave, et c'est même plutôt réjouissant, ça veut dire que nous aurons toujours quelque chose à apprendre. Et vos enfants, d'autant plus.

Alors, lorsqu'ils vous poseront des questions, donnez l'exemple : vous ne savez pas ? Dites-le sans honte ! Bon évidemment, « je ne sais pas » ne peut pas être la fin d'une conversation : proposez par exemple de chercher la réponse ensemble. Indiquez comment ils pourraient trouver la réponse seul. Ou bien, si le cadre ne le permet pas, dites que vous allez vous renseigner, et que vous aurez une réponse pour la séance suivante.

Pour les bugs, c'est la même chose : si l'un des enfants a un bug, plusieurs stratégies sont possibles. Vous pouvez par exemple mettre les enfants par deux, l’un code et l’autre cherche les bugs ; incitez-les également à être méthodiques lorsqu’ils codent (en découpant leur programme en petites unités plus faciles à tester, en gardant sous la main les ressources, comme des tutoriels, qui les aideront à débugger, etc.). En ultime recours, si vous prenez la main pour montrer à l’enfant son bug, soyez sûr qu’il comprenne bien toutes les étapes : répétez, revalidez, questionnez ; l’enfant ne doit pas être passif alors que vous êtes en train de faire des choses sur son programme ! D'ailleurs, c'est souvent une fausse bonne idée de prendre la main sur le programme d'un enfant alors, répétons-le : seulement en ultime recours et en verbalisant bien tout ce qu'on fait ! Vous pouvez même poser la contrainte de ne jamais toucher le clavier ni la souris de quelqu'un d'autre... ‌

Et si vous ne parvenez pas à résoudre le bug ensemble, ajournez : on n’est pas obligé de tout trouver, tout de suite. Dites-lui de laisser le problème tourner dans sa tête : il peut même en parler à d’autres personnes ; et vous, de votre côté, vous allez aussi chercher.

Mais où trouver de l'aide me direz-vous ? D'abord, il y a la communauté Class'Code. Ensuite il y a la communauté Scratch. Et puis enfin, Internet entier est à votre disposition. Je veux dire par là, que vous trouverez toujours des personnes prêtes à répondre ou en tout cas, à donner des pistes. Là encore, vous n'êtes pas seuls !

D'ailleurs, un dernier conseil avant de clore cette partie : n'hésitez pas à faire des projets de groupe. Comme on le verra la semaine prochaine, apprendre à plusieurs est extrêmement bénéfique, mais se tromper à plusieurs est aussi beaucoup plus facile…  

Exemple de certificat de réussite
Exemple de certificat de réussite