Du jeu de rôle pour aborder l’informatique [archives]

C’est l’été, les animateurs, scientifiques ou non, proposent aux jeunes des animations sur les séjours de vacances dans les maisons de quartier, les MJC… L’éventail d’activités est large mais quand on est animateur on n’a jamais trop de bonnes idées pour les jeunes. On cherchant rapidement sur le web on trouvera sans mal des idées et des exemples prêts à l’emploi. Mais Sans chercher très loin cependant, en fouillant dans les archives du secteur robotique de Planète Sciences, on trouve de quoi préparer de prochaines animations et des sensibilisations tant d’un point de vue technique que pédagogique. Je vous propose ici deux articles qui peuvent paraitre un peu « vieux jeu » mais dont le contenu reste très riche : publiés dans le premier numéro de Microbe en 1986, ils abordent le jeu de rôle comme moyen d’approche collective et ludique de l’informatique. Description de jeux de rôle et analyse de leur portée.

Microbe : la revue du Groupe RObotique INformatique

Microbe, 23 numéros et 2 hors série entre Décembre 1986 et Septembre 2005 : ça n’est pas la plus prolifique des publications de Planète Sciences, mais certainement l’une des plus riches en réflexion, découvertes et tutoriels. Le slogan de cette revue était à sa création : « le virus de l’informatique, la fièvre de l’animation ». Microbe voulait « aider à réfléchir ceux qui se posent des questions sur les objectifs réels et les moyens de la pratique de l’informatique pour les jeunes ».

On retrouvera sur ce blog, certainement avec plaisir mais aussi beaucoup d’intérêt plusieurs articles issus des archives de Microbe ; ils seront légèrement modernises grâce à l’ajout de liens HTML (parfois bien utiles pour comprendre le sens de certains concepts technologiques d’une autre époque, alors que les ordinateurs 8 bits affichaient leurs puissance sur un écran monochrome ou bien tout juste à peine en couleurs)

Note: le lecteur ou animateur novice pourra « décrypter » un peu mieux les détails techniques cet l’article à l’aide de cette introduction simple d’un système à microprocesseur.

Allez, c’est parti pour une plongée dans les techniques d’animation des années ’80, au temps où Planète Sciences s’appelait ANSTJ, et les disquettes mesuraient 5″ ¼, sinon 8 pouces !

I- Trois jeux de rôle : ORDITABLE, MAXIPUCE et LISP

Les premiers jeux de rôle créés par l’équipe de DOUCY 1980/1981 nous révèlent les idées qui ont mené à leur création. Ces jeux sont toujours utilisés, comme si chaque équipe d’animation les interprète différemment en les reprenant à son compte. Ils s’appellent ORDITABLE et MAXIPUCE.

Microbe_JeuDeRole09

ORDITABLE

Orditable nécessite outre l’utilisateur quatre personnages : l’interpréteur, l’écran, la zone mémoire et l’additionneur. Le clavier est quant à lui représenté par un bout de carton incliné. Les personnages sont assis autour d’une table et communiquent entre eux oralement.

Figure 1 - ORDITABLE : organisation spatiale et détails du clavier

Figure 1 – ORDITABLE : organisation spatiale et détails du clavier

Le programme qui tourne sur cet Orditable est celui de la figure 2.

Figure 2 - ORDITABLE, le programme de référence

Figure 2 – ORDITABLE, le programme de référence

L’interpréteur a nettement un rôle de leader : c’est lui qui a le programme écrit sur un petit cahier avec une instruction à chaque page. Page après page, il lit l’instruction à voix haute et l’exécute. Il dispose des services de l’additionneur pour l’instruction ‘ajouter’ et ceux de la zone mémoire à qui il donne des ordres du type :

  • ‘mets ce nombre dans A’ ou
  • ‘quel est le nombre dans A ?’

Il lui passe ou reçoit un papier portant la valeur de A. L’acteur jouant la zone mémoire gère les mémoires physiques. Celles-ci sot représentées par des petites boites ou il place la valeur, et sur lesquelles il écrit le nom de la variable. L’écran quant à lui reçoit les messages à afficher sur un tableau ou une grande affiche murale.

Pour se servir du clavier, l’utilisateur écrit le nombre qu’il veut « taper » sur un papier qu’il glisse dans le clavier. C’est l’interpréteur lui-même qui récupère la valeur.

MAXIPUCE

MAXIPUCE se présente comme un zoom sur l’instruction :

’AJOUTER A ET B ET METTRE LE RESULTAT DANS T’

Contrairement au jeu précédent, qui donnait une vision « conviviale » de l’organisation interne de la machine, ce jeu met en évidence le fait que les organes n’ont pas de vue d’ensemble du fonctionnement de l’ordinateur.

Les personnages sont le Bus d’Adresse, le Bus de Données, le Décodeur d’Instruction, l’Unité Arithmétique et Logique. Le jeu se joue sans périphérique donc sans utilisateur. Les mémoires sont représentées par des chaises, chacune ayant une adresse numérique.

Figures 4, 5 - MAXIPUCE, organisation spatiale et programme

Figures 4, 5 – MAXIPUCE, organisation spatiale et programme

Le programme est celui donné en figure 4. Le décodeur d’instruction lit le programme sur un tableau ou une affiche et traduit les instructions aux autres organes de façon que chacun sache ce qu’il doit faire. Le bus d’adresse désigne toujours au bus de donnée la chaise concernée par l’instruction, et le bus de données prend/pose la valeur qu’il a reçue/doit donner à l’unité arithmétique et logique.

Déjà en comparant ces jeux ont voit apparaitre l’idée du modèle en couches superposées – dans l’effet zoom – et celle de la séparation des taches entre différents organes. En revanche, on sent une volonté de rester le plus proche possible de la réalité : les animateurs cherchaient à décrire l’intérieur de la machine et non-pas une représentation possible aidant à comprendre les concepts de base.

Jeu LISP

Ce jeu de rôle a été mis au point et testé par l’équipe micro du camp de St AFFRIQUE 1984. Il vise à dégager quelques caractéristiques des langages fonctionnels et notamment de LISP.

Personnages

Le jeu nécessite 6 personnes dont 4 faisant partie de l’ordinateur et 2 extérieurs à la machine :

  • 1 Interpréteur
  • 1 Clavier
  • 1 Ecran
  • 1 « Taxi »
  • 1 Utilisateur
  • 1 Orateur

L’orateur explique le déroulement du jeu. Il est donc indispensable qu’il ait parfaitement compris le jeu au moment ou celui-ci est joué devant le groupe. Ce n’est pas nécessairement l’animateur, mais il doit s’exprimer clairement et être fiable.

L’interpréteur a une tâche active, le clavier, l’écran et l’utilisateur ont chacun une tâche moins importante, le Taxi quant à lui n’a pas une tache ardue, mais il est au centre du jeu ; ce rôle peut parfois permettre, à la répétition, de lancer un participant qui comprend peu et menace de décrocher. C’est également un élément bien pratique du point de vue dramatique car il permet aux autres de ne pas bouger, ce qui clarifie le jeu.

Par rapport à une communication orale (qui permet également de ne pas avoir de mouvements désordonnés) il apporte aussi un peu de dynamisme et évite que le ‘passage d’argument’ ne se superpose aux explications qui noient parfois les informations échangées par les différents acteurs et…que le spectateur a tendance à oublier vite.

Déroulement

Figure 5 - LISP : le programme du jeu

Figure 5 – LISP : le programme du jeu

Il y a trois affiches au mur, qui constituent le programme en trois fonctions (figure 5). Devant chacune d’elles, une table. Les trois tables sont assimilées à trois chantiers. L’interpréteur débute au chantier BATNAV où il commence à lire les instructions sur l’affiche ; quand il rencontre COMPARE il donne les arguments au Taxi qui les porte au chantier COMPARE où il exécute les instructions écrites sur l’affiche. Quand il rencontre l’argument LIS, il va au chantier LIS, puis revient à COMPARE puis à BATNAV.

Figure 6 - Représentation spatiale du jeu de rôle

Figure 6 – Représentation spatiale du jeu de rôle

L’interpréteur n’emporte jamais les arguments avec lui, c’est le taxi qui véhicule les informations, c’est également lui qui les porte aux périphériques.

Par soucis de simplicité, il n’a pas été choisi de considérer ET comme un chantier. Il suffit à l’interpréteur de poser sur la table BATNAV des papiers portant les mentions VRAI ou FAUX. L’orateur insiste sur le fait que le choix ‘si alors sinon’ se fait en fonction des deux papiers.

Objectifs

Notre objectif était d’opposer ce jeu au même, joué en BASIC, afin de dégager les notions de structuration et de passage d’argument des langages fonctionnels (LISP, PASCAL…) On pourra faire remarquer qu’il n’y a pas besoin de mémoires du fait que l’on peut travailler simultanément sur plusieurs chantiers en les laissant ‘en route’ pour y revenir plus tard, alors que en BASIC, il aurait été nécessaire de nettoyer la table à chaque étape (ce qui nécessiterait des mémoires de sauvegarde). Du ‘passage d’arguments’ entre les fonctions on arrive à la nécessité de communication entre les différents éléments du programme.

On pourra également remarquer qu’il n’est pas nécessaire de « séquentialiser » les ordres. C’est-à-dire que l’on peut écrire :

COMPARE (LIS, 7)

Alors que sous BASIC il aurait été nécessaire de décomposer en lecture puis comparaison :

INPUT A

COMPARE A, 10

(ou quelque-chose comme ça)

Cette propriété – contrairement à la précédente – est caractéristique de LISP où toutes les instructions retournent une valeur…même si celle-ci est sans intérêt. Alors que PASCAL ou LOGO par exemple ont des procédures agissant sur des mémoires si besoin est, d’où la nécessité de celles-ci et aussi de l’instruction d’affection.

(En BASIC : A= 10,

En LOGO : DONNE « A » 10)

Nous n’avons cependant pas poussé la logique jusqu’au bout puisque nous avons utilisé un ordre RETOURNE qui est inutile en LISP, mais qui clarifie la lecture du programme.

En revanche, nous n’avons pas insisté sur la deuxième différence entre LISP et PASCAL qui est la structure de données. Simplement nous avons écrit les constantes numériques sous la forme 5, 7 et les constantes alphanumériques entre guillemets.

 II- Les jeux de rôle : éléments d’analyse

Introduction

A la recherche de moyens originaux et collectifs de l’approche de l’informatique, les animateurs des premiers camps d’été de l’ANSTJ (1980) ont élaboré une séquence qui devrait faire son chemin : le jeu de rôle.

Un jeu de rôle est un sketch de courte durée dans lequel les acteurs incarnent certaines parties d’un ordinateur exécutant un programme simple, montrant ainsi le fonctionnement de la machine.

Depuis cinq ou six ans que nous utilisons et créons des jeux de rôle, il nous a paru utile de faire le point non-pas sur tel ou tel jeu (voir première partie de cet article) mais sur les objectifs que nous avions, sur ce qui s’est réellement passé et les problèmes que nous avons rencontrés.

Une approximation optimale

L’écho-écran [NDLR: affichage à l’écran de l’instruction passée au microprocesseur] est un problème qui s’est posé à nombre de ceux qui ont essayé de mettre au point un jeu de rôle : lors de la saisie au clavier d’un caractère, l’acteur qui joue le rôle de l’écran l’écrit en général sur son tableau de façon assez spontanée : n’est-ce pas ce qui se passe en réalité lorsque vous tapez sur un clavier ?

Pourtant, il est légitime de protester que l’écran n’a pas à prendre lui-même cette initiative. Différentes possibilités peuvent être avancées pour corriger ce défaut :

  • supprimer l’écho-écran, ce qui ne correspond plus à la réalité extérieure de la machine
  • faire dicter par le clavier à l’écran les caractères frappés en même temps qu’au microprocesseur, ce qui supprime le rôle de chef d’orchestre que l’on veut faire jouer au microprocesseur
  • faire gérer explicitement l’écho par le microprocesseur, ce qui rend l’exécution plus complexe donc augmente le risque d’erreur et diminue la compréhension.

Le même problème se pose lorsqu’il s’agit de savoir s’il faut mettre une horloge dans le jeu de MAXIPUCE (jeu de rôle décrivant le fonctionnement de l’unité centrale, dont les personnages sont les circuits électroniques) ou de vouloir gérer la pile dans le jeu de rôle « simulation d’un interpréteur LISP » etc…

Si ces problèmes sont en général imparfaitement résolus c’est qu’ils sont l’expression d’une contradiction inhérente aux jeux de rôle : la réalité d’un ordinateur est bien plus complexe que ne peut l’être un agencement de quelques tables, chaises et acteurs ; toute tentative de rigueur apporte une complexification (ajout d’un acteur, augmentation de la durée d’un jeu, etc…) Le cas limite vers lequel tend cette rigorisation est de recréer un ordinateur en matière humaine mille fois plus lent et mille fois plus encombrant qu’un vrai….

Cette représentation n’est guère plus claire que ce que l’on trouve sous le capot d’un ordinateur auquel on aurait ajouté quelques indicateurs (diodes électroluminescentes, voire appareils de mesures, etc…) ou que celles qu’apportent certains logiciels de simulation d’unité centrales tournant d’ailleurs sur celles qu’ils simulent – bonjour l’embrouillamini pédagogique !!!

On voit donc que le jeu de rôle porte en lui-même sa limite : il doit forcément trahir la vérité qu’il est censé décrire, car pour le décrire parfaitement, il doit en être différent.

Le sens dans lequel se fait cette trahison détermine le jeu de rôle que l’on a choisi (MAXIPUCE au niveau de l’unité centrale, ORDITABLE au niveau global, BASIC ou LISP au niveau des interpréteurs de langage).

Quand un tel dilemme se pose : clarté ou rigueur, c’est en général que la situation rigoureuse est obscure, donc à rejeter.

Il faut bien sûr rejeter les situations scandaleuses qui ne produiraient pas le même effet extérieur (supprimer l’écho à l’écran par exemple). Entre les situations qui restent…à s’éloigner de la réalité autant choisir la solution la meilleure du point de vue scénique (éviter les mouvements désordonnés, clarté et simplicité du processus) ou celle qui paraitra la plus « naturelle » au spectateur.

Homogénéité des personnages

Ces trahisons nécessaires ne sont en fait pas très graves dans le cas de l’écho-écran, détail qui sera de toute façon vite oublié, une fois la notion de « moniteur » (esclave faisant les basses besognes de ce genre) introduite, mais elles posent un problème beaucoup plus important en ce qui concerne l’homogénéité des personnages : ce problème mène à celui de la représentation du jeu, donc à celui de son utilisation pédagogique.

Microbe_JeuDeRole01

Le problème de l’homogénéité des personnages peut se poser de la façon suivante : souvent une personne joue le rôle du clavier et une autre celui de l’écran. Pour le spectateur novice, la notion d’écran est évidente mais déjà se pose un problème : le joueur « écran » dispose d’un tableau noir ; c’est en fait ce tableau l’écran, le joueur joue plus précisément le rôle d’une « interface écran ». Mais comme une interface écran reste un circuit, le problème n’est pas très grave.

Un jeu ou chacun des personnages représente un circuit électrique ne pose pas de problème d’homogénéité, c’est le cas d’une variante d’ORDITABLE -voir plus haut- expérimente au camp de DOUCY en 1983, où les personnages étaient : Ecran, Clavier, Contrôleur de disquettes, Unité centrale, et plus « naturellement » l’utilisateur, qui ne pose pas de problème dès qu’il est nettement séparé des autres (couleur du chapeau, situation spatiale, etc…)

C’est aussi le cas dans le cas du jeu MAXIPUCE où les personnages sont : Bus-adresses, Bus-données, Unité-Arithmétique-et-Logique, Décodeur-d’Instructions (les deux formant le Microprocesseur), et Mémoire. Le jeu se joue sans utilisateur ni périphérique.

Cette cohérence des personnages est possible dans ces deux jeux, mais elle ne l’est plus dès que l’on veut présenter, par le jeu de rôle, un langage. C’était le cas de la version originelle de l’ORDITABLE (camp 13/15 ans de DOUCY, 80 et 81) et des deux jeux présentés aux camps de St AFFRIQUE (1984) opposant un langage impératif (BASIC) et un langage fonctionnel (LISP-LOGO). Dans l’un comme dans l’autre, à coté de personnages comme Ecran ou Clavier, on trouve un personnage « interpréteur », c’est-à-dire que l’on met implicitement sur le même plan Circuit et Programme. De plus, les deux jeux font intervenir des personnages supplémentaires :

  • l’Esclave (dans le jeu « langage impératif ») et
  • le Taxi (dans le jeu « langage fonctionnel »)

qui ne correspondent pas à une entité parfaitement définie du point de vue informatique mais qui sont nécessaires à un fonctionnement souple du jeu (entre autres ils peuvent éviter d’avoir à fournir une explication compliquée sur certains fonctionnements que l’objectif du jeu n’est pas d’aborder en tant que tel…comme l’écho-écran !)

Jeux homogènes et hétérogènes

La conséquence de cette hétérogénéité est un jeu réclamant du spectateur une capacité d’abstraction beaucoup plus ardue : dans les jeux où tous les joueurs ont une correspondance matérielle, l’animateur peut introduire son jeu en le présentant comme ce qui se passe à l’intérieur de l’ordinateur. Il peut ouvrir la machine et montrer chacun des circuits. Si certains restent sans équivalent humain, le participant sera aisément convaincu que le rôle moins important serait mis en évidence par un approfondissement du jeu.

En d’autres termes, le jeu homogène peut se présenter comme une description grossière mais exhaustive de l’ordinateur vu « à un certain niveau ». La communication entre les divers éléments ne lui posera pas de problème s’il a quelques notions d’électricité, mais sinon il se la représentera tout de même, car il a déjà vu fonctionner des systèmes à communication interne structurée (administration scolaire, téléphone, etc…)

Cette représentation sécurisante n’est plus possible dès lors que l’on s’intéresse aux jeux hétérogènes.

L’abstraction qui est proposée n’est alors plus l’abstraction d’un tout mais de différentes parties extraites de différents niveaux : clavier et écran à un niveau, interpréteur à un autre, lui-même réparti selon différents niveaux logiciels – l’esclave, le taxi.

Dans le jeu de rôle LISP, en introduisant des lieux appelés « chantiers », on propose une abstraction de la séparation d’un programme en différentes fonctions.

Le fait que l’interpréteur se déplace de l’un à l’autre lors d’un appel ne correspond à rien du point de vue informatique mais permet de relier artificiellement deux niveaux : celui du programme, et celui de l’interpréteur qui l’exécute, voire deux concepts : celui de l’interprétation et celui de la structuration.Microbe_JeuDeRole02

Les différentes parties présentées à chaque niveau sont celles que l’animateur juge les plus importantes. Il choisit donc de braquer l’éclairage plutôt sur certains détails du fonctionnement de l’ordinateur.

Autant le jeu homogène était synthétique, autant le jeu hétérogène est analytique, les différents éléments analysés étant reliés vaille que vaille. La façon dont le conçoivent les spectateurs est variable mais de toute façon ils ne perçoivent pas en tant que tel cette hétérogénéité (ils ne sont pas censés savoir ce qu’est un programme).

En tout cas, ils n’ont pas la vision sécurisante des jeux homogènes où l’animateur insiste sur le fait que chaque personnage symbolise un circuit.

Certains d’entre eux essayent à tout prix de se représenter l’intérieur de l’ordinateur comme un sketch qu’ils voient , et aboutissent à une conception à la fois assez fausse et assez floue (car sans point de repère) de l’ordinateur, ils oublient assez vite ce qu’ils ont vu car ce qu’ils ont tenté de retenir est d’une abstraction folle : ce n’est pas une saynète, ce n’est pas un circuit, ce n’est pas un schéma, ce n’est pas un discours, c’est quasiment une sensation.

D’autres, et c’est cette attitude qu’il faut d’après-nous encourager, prennent pour argent comptant ce petit sketch, sans essayer de l’analyser, ni d’en saisir la portée informatique. Il sera toujours temps plus tard de relier ce qu’ils ont vu au fonctionnement de la machine. Ils peuvent avoir un souvenir précis de ce qu’ils ont vu, mais c’est un souvenir correct d’un jeu scénique et non un fonctionnement abstrait.

Objectifs des jeux hétérogènes

De tels jeux, nous l’avons vu, ne peuvent plus répondre à l’objectif de représentation globale de l’ordinateur.

En créant des jeux hétérogènes les animateurs ont peu à peu élargi le champ des objectifs des jeux de rôle sans en être toujours totalement conscients ou du moins sans toujours l’exprimer clairement. Un des objectifs de ces jeux pourrait être de donner à l’animateur un ensemble de symbolisations faciles à utiliser pour la suite de son animation.

Expliquant ce qu’est un programme, il pourra faire référence au programme écrit en pseudo-LISP ou en pseudo-BASIC qui tournait dans l’ordinateur humain. Expliquant ce qu’est un passage d’arguments, il pourra évoquer le mouvement du Taxi, etc,…le jeu de rôle qui fournit alors un ensemble de matériaux semi-finis que la suite de l’animation lui permettra d’utiliser afin de construire, avec le participant, une réflexion critique sur le jeu… ce qui montrerait d’ailleurs qu’une étape de la compréhension de l’outil informatique est la critique d’une étape précédente.

Les objectifs, après avoir été centrés sur la configuration matérielle, passent à tel ou tel point de fonctionnement logiciel, voire à la fonction même de langage et ses différents types d’ordres.

Microbe_JeuDeRole03

Jeux hétérogènes et jeux homogènes s’affrontent pour dicter leur loi – (la dure loi des jeux de rôle, et pas celle des jeux de l’oie !)

Si l’on admet que cette attitude visant à garder à l’état brut les matériaux que fournit le jeu de rôle est meilleure que celle où le participant construit lui-même immédiatement sa représentation de l’ordinateur, à partir de ces matériaux -en les réutilisant d’une façon non-adéquate !- on ne peut plus présenter la séquence aux participants comme une incursion au cœur de l’ordinateur sans émettre de réserves, car cette présentation favorise la seconde attitude.

Problèmes de mise en scène

Naturellement, la mise en scène d’un jeu dépend des acteurs qui y figurent mais on pourra veiller à observer certaines règles qui évitent un jeu incompréhensible pour des raisons purement techniques. Par exemple, bien séparer les acteurs situés « dans l’ordinateur » de l’utilisateur éventuel.

Une idée expérimentée à St AFFRIQUE et qui semble positive est d’ajouter un orateur qui explique le fonctionnement. Ce « jeu de scène » permet que les acteurs ne parlent qu’aux autres éléments de la machine, et sépare donc nettement la communication interne à la machine et le commentaire, qui ont parfois tendance à s’emmêler lorsque celui-ci est fait directement par les acteurs.

Afin de ne pas monopoliser toute l’équipe d’animation, le sketch peut être joué dès la première représentation par des participants à condition que ceux-ci l’aient prépare auparavant avec l’animateur. Ce système a en outre l’avantage de favoriser une auto-animation de groupe, de « désacraliser » le message (ce que dit un copain est a priori moins complique que ce que dit un animateur).

De plus, voir ensemble, lors de la préparation, en direct et sans public, les points qui posent problème, permet éventuellement d’en tenir compte pour modifier ensemble la version qui sera présentée aux autres.

Ce sera également une reconnaissance de la spécificité de chacun au sein du groupe, puisque les autres participants préparent un autre jeu ou une autre séquence, et que chacun a quelque-chose de différent à apporter aux autres.

Conclusion

Nous avons volontairement dans cet article laissé de cote les objectifs des jeux de rôle relatifs à la dynamique de groupe pour nous concentrer sur les objectifs informatiques ; cela ne veut pas dire qu’ils soient moins importants, bien au contraire.

La conclusion qui semble s’imposer à la plupart de ceux qui ont déjà monté des jeux de rôle, est que leur apparente simplicité cache en fait une nature assez complexe et ne nous dispense pas d’une réflexion approfondie de la mise au point.

 

 

Laisser un commentaire