Que le lecteur m’excuse pour ce titre, une nouvelle fois, facile, mais je suis bien conscient que ce n’est encore pas cette fois que je risque de gagner un prix de calembour. Plus sérieusement, ce billet présente une hypothèse aussi saugrenue qu’anachronique: « si on revenait au binaire pour apprendre à coder ». Pire, j’affirme ici qu’il est possible de revenir au binaire pour coder sans recourir à des écrans. Pour ce faire, je me suis inspiré des machines informatiques des années 60 qui recevaient des commandes par cartes perforées et émettaient leurs données sur des imprimantes.

Je ne reviendrais pas sur le mépris que j’éprouve pour le très indigent débat sur #lézécrans et sa cohorte de professeurs Nimbus (déjà évoqué ici). Je ne reviendrais pas non plus sur le fait que cette offensive un peu surannée porte en elle, sans doute de façon involontaire, une vraie bonne question: « Est-il indispensable d’avoir un écran pour apprendre à coder? ».

Apprendre à coder sans machine, une bonne idée?

Avant de débuter, il faut que je vous dise que je suis également très dubitatif envers le courant de l’informatique débranchée. J’avoue avoir du mal à comprendre l’intérêt que l’on peut avoir de l’apprentissage du code « Hors machine ». J’ai un peu le sentiment d’un apprentissage comme celui de la natation « à sec ».

En effet, la recherche en psychologie a montré une relation entre la rapidité de la rétroaction et l’efficacité de l’apprentissage (Van der Kleij et al., 2015). De même, elle a également montré l’avantage de la rétroaction de la machine sur la rétroaction humaine également sur ces apprentissages (Shute, 2008). De plus, les démarches d’investigations permises par les stratégies de débogage sont au cœur des démarches constructionnistes (Papert, 1982) qui ont abouti au logo, aux tortues et à la création de Scratch. Réutiliser ces outils « en débranché », c’est aussi faire fi du très long travail de réflexion des équipes du MIT sur cette question.

Enfin, quiconque a déjà programmé un peu sait que le programme non implémenté fonctionne toujours bien dans la tête du concepteur, mais que le passage dans la machine nous dit tout autre chose. Le « passage à la machine » et le débuggage font, à mon humble avis, partie intégrante de la démarche de programmation. Si le découpage d’une discipline en objets élémentaires a parfois des avantages, il faut avoir des raisons solides pour le faire. Or, le faible état d’avancement d’une didactique de l’informatique ne nous permet pas vraiment de trancher sur ce point. Pour se moquer un peu des saucissonnages un peu rapides, Freinet aurait dit « si vous débitez un arbre en morceaux et vous voulez les assembler ensuite, vous n’aurez pas un arbre, mais un tas de bois » (si vous avez la citation exacte, je prends). En séparant le codage de l’implémentation dans la machine, on prend le risque de se retrouver avec des buches numériques plutôt que de voir croitre un arbre de la programmation. À débattre… jusqu’au jour où l’on aura constitué une didactique solide de l’informatique et de la programmation.

Bref, si #lézécrans ne m’ont pas convaincu, le « codage débranché » qui est censé lui apporter une réponse ne me semble pas vraiment convaincant non plus. C’est donc une voie alternative à ces deux approches que j’ai cherché à mettre en place avec mes tortues.

S’inspirer des cartes perforées

Comme je l’ai dit plus haut, les premiers ordinateurs commerciaux étaient programmés par cartes ou au clavier et le périphérique de sortie était généralement constitué d’une imprimante qui servait de prompteur. Point d’écrans, donc!

À partir de ce constat, l’idée de programmer le robot par des instructions grâce à des cartes perforées s’est installée insidieusement chez moi. Je passe à l’acte après avoir découvert, un peu par hasard, la proposition génialissime de SeuPay.

J’ai conservé les grandes lignes de ce code, ainsi que l’idée d’une horloge sur la carte et du recours à un codage en binaire. Cette proposition tombait bien puisque je communiquais déjà avec mon robot avec des caractères ASCII. Même si l’ASCII est codé sur 7 bits, je n’ai jamais pu me résoudre à ne pas conserver un octet tout complet pour le codage et ce sont donc des cartes à 8 emplacements que j’ai imaginées. J’espère que cette option m’offrira des potentialités nouvelles pour les développements futurs du robot.

En m’inspirant très largement de ce stupéfiant lecteur, j’ai conçu un dispositif optique sur le même principe. Je trouvais, en effet, le lecteur à trombone trop cheap et vraisemblablement inadapté pour un travail régulier avec des élèves. Mais bon! La preuve de concept était là.

Le lecteur optique m’a permis de mettre l’horloge d’un côté, et le code binaire de l’autre. Ceci allait avoir pour conséquence que les cartes allaient devenir facile à réaliser avec une simple perforatrice de bureau.

La carte peut alors être lue lors du passage entre deux barrières optiques. (Ici une led et un capteur de luminosité Grove Seeed.

Les cartes finalisées ressemblent à celle-ci.

Avantages du recours au binaire et aux cartes perforées

À ce stade, le lecteur peut légitimement être déçu par le manque cruel d’innovation dans ma démarche. De mon point de vue ce n’est pas grave, puisque je suis convaincu que la vraie innovation est rarissime, contrairement aux innovateurs qui s’envolent en nuées dès lors que l’on met un coup de pied dans une fourmilière numérique (Voir ici, ce que j’ai déjà écrit sur le sujet). Je ne revendique donc pas le statut d’innovateur, mais juste le statut de celui qui a une connaissance suffisante de la technique pour comprendre que d’autres ont réfléchi bien avant moi.

Une fois ces bases posées, il me semble que ma proposition associe le meilleur des deux mondes, la programmation et le codage débranché. Du monde informatique, je conserve l’intérêt pour le débogage à travers l’épreuve de la machine et les qualités des rétroactions qu’elle offre pour les apprentissages. Du monde débranché, je garde l’idée que l’on n’a pas besoin de la Sainte Trinité chaise, clavier, écran pour réaliser un algorithme de programmation.

L’usage de la carte perforée permet de préparer le programme en dehors de la machine, tout en acceptant ces contraintes et mobilisant ces vertus. Il ne s’agit pas d’écrire un programme sur une feuille ou avec un puzzle, mais bien de préparer la programmation réelle du robot.

La photographie ci-dessus montre que les cartes se prêtent aisément à une forme de collaboration. Sur un poste informatique, celle-ci peine à dépasser l’échelle du binôme.

L’usage de cartes permet aisément de jouer sur les variables didactiques du problème posé. Le recours à des cartes déplacement + valeur du déplacement permet de limiter les fonctions disponibles (dessiner un carré en ne laissant que des cartes « Recule » et pas de carte « Avance »), de laisser plusieurs choix ( dessiner un carré en laissant « avance de 1cm »; « avance de 10cm »: »avance de 20cm »; pourquoi les carrés qui sont différents sont-ils tous des carrés?) ou de pratiquer une démarche d’investigation ( en s’appuyant sur le programme du carré, peut-on fermer une figure si on utilise un autre angle que l’angle droit, par exemple 120° ou 60°? ).

On peut également rendre le problème plus complexe en laissant les élèves réaliser leurs propres cartes pour le programme. Le fait d’avoir des cartes binaires trou/pas trou facilite le codage du caractère ASCII avec une simple perforatrice.

Le fait de réaliser ses propres cartes permet notamment d’appréhender les boucles itératives de façon tangible. En effet, à quoi bon faire plusieurs cartes « Avance 20 » alors que les cartes ne sont traitées qu’une par une une dans le lecteur. Au passage, la séquentialité du traitement des informations est également abordée lorsque l’on passe les cartes les unes derrière les autres.

Oui, mais… n’est-ce pas un peu gadget?

Dans la mesure où mes hypothèses de départ sont issues de celles du MIT, vous pourriez m’opposer le fait que ce que je fais, ce n’est jamais que du Scratch. En effet, vous n’auriez pas totalement tort. Je ne reviendrais pas sur l’intérêt d’un robot qui « existe » dans l’espace, dans la mesure où j’ai abordé la question du body syntonic learning dans un autre billet (voir ici). En revanche, le fait d’avoir des cartes en papier pose des alternatives surprenantes à Scratch.

Lors de la fête de la Science 2024, j’ai proposé à une classe de quatrième de tracer le parallélogramme suivant:

La difficulté principale de l’exercice était de tracer un parallélogramme sans faire appel aux parallèles, puisque le robot est incapable de le faire. Il fallait donc trouver/retrouver les relations entre les angles, sachant que, dans les cartes disponibles, les rotations sont de 1, 15, 30, 45, 60, 90 et 120 degrés à gauche comme à droite. J’ai été surpris de voir que les cartes perforées avaient été détournées de leur usage initial par un groupe pour devenir des brouillons.

Certains y verront peut être un effet Jourdain et pourraient me reprocher de voir des apprentissages là où il n’y en a pas. Néanmoins, la production des cartes rend bel et bien visibles des activités cognitives qui sont souvent difficilement décelables lorsque l’on est sur un ordinateur.

Pour conclure en attendant la suite

Voilà! Il est effectivement possible d’apprendre à programmer un objet technique sans avoir à passer par un poste informatique. Il est possible de pratiquer une informatique tangible sans passer par les écrans. Évidemment, le retour aux écrans est nécessaire pour qui compte programmer un peu sérieusement, mais on peut tout de même s’initier à la réflexion informatique avec des objets numériques concrets.

Bien entendu, vous avez le droit de ne pas être d’accord!

Bibliographie

Papert, S. (1982). Mindstorms : Children, computers, and powerful ideas (Reprint). Harvester Press.

Shute, V. J. (2008). Focus on Formative Feedback. Review of Educational Research, 78(1), 153‑189. https://doi.org/10.3102/0034654307313795

Van der Kleij, F. M., Feskens, R. C. W., & Eggen, T. J. H. M. (2015). Effects of Feedback in a Computer-Based Learning Environment on Students’ Learning Outcomes : A Meta-Analysis. Review of Educational Research, 85(4), 475‑511. https://doi.org/10.3102/0034654314564881