Programmation d'un robot.

• Matériel
• Déroulé
• Analyse

Cette activité a pour but d'introduire le caractère impératif de la programmation : un ordinateur ne fait qu'exécuter une série d'ordres, bêtement, sans essayer de corriger des erreurs « évidentes ».

Les élèves doivent programmer un robot (par exemple, un robot de la poste chargé de séparer les colis destinés à la France métropolitaine de ceux destinés à l'international), mais tout ceci se fait sur papier, sans ordinateur.

Cette séance dure une heure.

Matériel

Chaque groupe d'élève se voit distribuer :

• huit cubes (une moitié bleus et une moitié rouges) numérotés de 1 à 8 ;
• un « plateau » (une bande de papier avec cinq cases numérotées de 1 à 5, à la taille des cubes).

Les fichiers utilisés pour cette activité sont :

• liste des problèmes (source) ;
• plateau (source).

Déroulé

Premier exemple

Un premier exemple a pour but de souligner le besoin d'une définition rigoureuse de listes d'instructions élémentaires. Je présente une pile de cubes rouges et bleus, mélangés, et j'annonce : « Dites-moi ce que je dois faire pour trier les cubes : les bleus à gauche et les rouges à droite. »

• Je refuse les instructions trop complexes, comme « Mettez tous les cubes rouges à droite » en expliquant que je ne sais pas faire cela car c'est trop compliqué.
• J'interprète aussi mal que possible les instructions pas assez précises en ignorant l'implicite : lorsqu'on me demande de « prendre le cube bleu » (implicitement : celui au sommet de la pile), je prends un cube au milieu de la pile, en faisant tout tomber ; lorsqu'on me demande de « poser le cube à gauche » (implicitement : sur la pile de gauche), je le pose à gauche, mais à côté de la pile de gauche ; etc.

Je fais le bilan en expliquant qu'un ordinateur ne sait exécuter que des instructions élémentaires et précises. Puisqu'il n'est pas possible de donner des ordres en levant toute ambiguïté, je donne (affichée au tableau, ou photocopiée pour chaque élève) une liste d'instruction autorisées.

Langage reconnu par le robot

Voici la liste des instructions reconnues par le robot. Les parties entre parenthèses sont optionnelles, et peuvent être omises pour un code plus concis.

Cette liste est lue ensemble et commentée. Notamment, les implicites sont explicités (par exemple, « Aller à gauche » signifie « Se déplacer d'une case vers la gauche », et ainsi de suite).

• Déplacements

  • (Aller à) gauche
  • (Aller à) droite
  • (Aller à la case) nº 3

• Manipulation des cubes

  • Prendre (le cube du dessus de la pile)
  • Poser (le cube sur le dessus de la pile)

• Structures de contrôle

  Les conditions ne peuvent concerner que : le cube présent dans la main ; le cube du dessus de la pile (ou leur absence).

  • Conditionnelle

        Si CONDITION
        Alors
          …
        Sinon
          …
        FinSi
    

  • Boucle

        Tant que CONDITION
        Faire
          …
        FinTantQue
    

Certains élèves ont ajouté des instructions à cette liste.

• Un élève (sachant déjà programmer) a utilisé des goto) et une instruction Fin du programme. Je l'ai laissé faire, et lui ai montré, une fois son problème résolu, comment résoudre le même problème en utilisant à la place une instruction Tant que (ce qui était plus simple dans ce cas).
• Un autre a utilisé, sans le nommer comme tel, un sous-programme (ou fonction). Il a remarqué que pour déplacer une pile de cubes en conservant l'ordre, on pouvait, deux fois de suite, inverser une pile, problème pour lequel il venait d'écrire un algorithme. La mise en œuvre n'était pas rigoureuse, mais j'ai encouragé cette approche, puisqu'il venait de réinventer le concept de fonction informatique.

Second exemple

Puis le premier exemple est fait à nouveau, en se limitant à la liste d'instructions tout juste définie. Ceci est fait en deux étapes.

Premièrement, les ordres sont exécutés au fur et à mesure qu'ils sont donnés. Il n'est donc pas nécessaire, à ce stade, d'utiliser des structures de contrôle (et je le dis donc aux élèves qui en proposent déjà).

Puis cet exercice est résolu une troisième et dernière fois. Cette fois, j'annonce que nous allons écrire le programme, puis, une fois seulement le programme terminé, la pile de cube va être dévoilée, et le programme exécuté. Le programme est écrit puis exécuté collectivement par les élèves.

Travail en autonomie

Enfin, le gros de la séance est un travail en autonomie. Par groupes de deux, les élèves choisissent un problème à résoudre (dans la liste classée par ordre de difficulté), et écrivent un algorithme correspondant. De préférence, la correction n'est pas faite par le professeur, mais par un autre groupe d'élèves, qui doivent exécuter l'algorithme et deviner à quoi il sert. De cette manière, un algorithme n'est pas correct parce que le professeur l'a décrété, mais parce qu'il fonctionne.

Lorsque les élèves ont résolu un problème, ils en choisissent un autre, de difficulté similaire ou supérieure, et ainsi de suite.

Je n'ai pas demandé de retour aux élèves, mais il est possible d'imaginer de demander, à la fin de la séance, de rendre un problème et son algorithme, ou une analyse d'une erreur qui aurait été faite dans l'un des algorithmes travaillés.

Analyse

Boucles et conditionnelles

Un gros avantage de cette activité est que les boucles et conditionnelles, qui peuvent poser problème lorsqu'elles sont introduites en langage informatique, n'en posent aucun ici. Elles sont en effet très proches de leur signification en langue naturelle. Reste la question de la transition vers le langage informatique, que je n'ai pas encore résolue (voir plus loin).

Contexte et Mise au travail des élèves

J'ai réalisé cette activité deux fois : une fois en tout début d'année (il y a plus de deux ans, si bien que je ne serai plus capable d'en faire un bilan précis), et une autre en dernière séance de l'année. Pour cette dernière fois, seuls cinq élèves étaient présents (dernier jour de l'année, après le conseil de classe), donc la séance a été plutôt simple à animer. Néanmoins, ils ont essayé, se sont trompés, ont corrigé leurs erreurs, etc. Bref, ils ont fait de la recherche.

Intégration à la progression

La séance faite le dernier jour de l'année peut être considérée comme une séance-détente un peu à part du programme. À l'inverse, celle faite en tout début d'année avait pour but d'introduire la notion de programmation impérative. Je me souviens peu de cette séance, mais je me rappelle que je n'étais pas satisfait de la manière dont elle s'était inscrite dans la progression générale. J'ai eu l'impression que passer de « Programmer un robot sur papier » à « Faire des mathématiques en Python » était trop brusque pour que le lien soit fait par les élèves.

Je me demande si une séance intermédiaire, en utilisant CargoBot ou une adaptation de ce jeu en utilisant Python, serait pertinente.

Formulation des problèmes

Les énoncés sont tous accompagnés d'un exemple. Cela me paraît nécessaire pour illustrer le problème, mais je ne suis pas certain que ce soit une bonne idée, car j'ai vu de nombreux élèves se limiter à reproduire l'exemple plutôt que résoudre le problème en général.

Je ne sais pas quelle est la meilleure solution ici…

Qualité des problèmes

J'ai trié les problèmes par ordre de difficulté croissante, en faisant en sorte que les énoncés soient compréhensibles sans introduire de notions supplémentaires. Je pense avoir réussi pour la plupart des cas, sauf pour ceux les plus difficiles. Trier des cubes par ordre croissant est un très bon problème de ce point de vue là, mais les autres nécessitent tous des notions supplémentaires (logique propositionnelle, ou représentation binaire des nombres) qui ajoutent de la difficulté. Rares sont les élèves qui s'attaquent à ces problèmes, donc je pense que ce point n'est pas des plus importants.