Typologie des pratiques de programmation

Cette étude empirique a mené, dans un processus itératif, à la déclinaison d’un ensemble de pratiques effectives de programmation d’élèves du primaire. Or, il aurait été peu judicieux de proposer une typologie strictement basée sur les observations réalisées dans le cadre de cette recherche, puisque le scénario pédagogique utilisé possède certaines limites inhérentes. En effet, tels qu’ils ont été conçus, ces niveaux ne sollicitent pas certaines pratiques qui sont pourtant pertinentes dans le contexte de l’enseignement primaire. Ainsi, cette proposition de typologie empirique tient compte d’autres pratiques qui ont été identifiées par Ruf, Berges et Hubweiser (2015) et qui ont été repérées à de nombreuses reprises dans la littérature. Le tableau 11 présente la typologie à l’aide de descripteurs et d’exemples : ces derniers ne sont présentés qu’à titre indicatif et n’ont pas pour but de restreindre ou limiter l’interprétation de ces pratiques, qui s’inscrivent dans une multitude de contextes variés.

Pratiques de programmation Descripteur 1. Assembler (fondamental) :

1.1. Chercher

L’élève cherche dans l’interface de programmation, à l’aide d’une bibliothèque ou d’un moteur de recherche, un code donné. Dans le cas des bibliothèques, il peut s’agir d’une liste du nom des codes, ou encore des boîtes elles-mêmes.

1.2. Sélectionner À partir de la bibliothèque ou de tout autre emplacement dans l’interface, l’élève sélectionne ou génère une boîte, puis la déplace dans l’espace de travail, le cas échéant.

[Robot] Lorsque le programme anime un dispositif robotique, la sélection peut aussi représenter l’activation de fonctionnalités du robot via l’interface de programmation.

1.3. Lier L’élève associe les codes (boîtes) entre eux et, s’il y a lieu, aux points de départ et de fin du programme. Cette pratique pourrait être sous-utilisée, voire insous-utilisée, dans le cas d’interfaces où le lien entre les boîtes est effectué par la juxtaposition de ces dernières (à la manière d’aimants). La pratique sélectionner possède alors une double finalité qui inclut la liaison.

1.4. Paramétrer L’élève ajoute des valeurs ou modifie et retire des valeurs préexistantes (par défaut). Ce paramétrage peut être effectué tant en surface, lorsque le paramétrage apparaît sur la boîte, qu’en entrant dans une boîte.

[Robot] Lorsque le programme anime un dispositif robotique, cette pratique peut impliquer des actions réalisées auprès du robot, par exemple pour créer une dance (création d’une séquence d’animation en volume).

2. Assembler en utilisant un code donné

L’élève conçoit un programme incluant un ou plusieurs codes suggérés par un agent réel ou virtuel.

3. Ajuster, étendre ou compléter

L’élève utilise un ou plusieurs codes liés, déjà présents dans l’espace de travail, afin de créer un programme. Contrairement à l’assemblage à partir d’un code donné, où le code était suggéré, la pratique d’ajustement s’effectue sur des éléments déjà présents dans l’espace de travail (qu’ils y aient été placés par un agent réel, virtuel, ou par l’élève lui-même, pour une autre tâche antérieure).

(Ce tableau continue à la page suivante.)

4. Tester L’élève lance le programme et en vérifie le résultat. Cette pratique peut amener à améliorer (optimiser), déboguer le programme. La vérification peut aussi servir d’étape intermédiaire dans le processus de programmation, c’est-à-dire pour valider un code ou une portion de programme.

[Robot] Lorsque le programme anime un dispositif robotique, la vérification consiste à observer le robot et à confirmer que toutes les actions (mouvements, voix, etc.) ont été effectuées.

5. Déboguer Après avoir constaté que le programme n’a pas donné le résultat escompté, l’élève part à la recherche du problème (bug) dans l’implémentation du programme. Il s’agit d’un processus itératif d’essai-erreur dans lequel sont utilisées de nombreuses autres pratiques ; surtout la vérification (tester) et les pratiques d’assemblage fondamentales.

6. Transformer* L’élève remplace un code par un autre code dont les fonctionnalités sont similaires et induisent un résultat semblable, voire identique. Il s’agit ici de comprendre que plusieurs codes peuvent mener à des résultats similaires.

7. Optimiser* L’élève adapte son programme ou son code de façon à retirer les boîtes inutiles ou les structures trop complexes. Contrairement à la transformation, cette pratique s’effectue lorsque l’élève manifeste explicitement son intention de rendre le code ou le programme plus efficace ou mieux structuré. Par exemple, plutôt que d’utiliser six boîtes pour une répétition d’actions, il pourrait utiliser la boîte une seule fois et y adjoindre un code dont la fonction est de répéter à n reprises.

8. Spécifier un problème* Se voyant offrir un programme donné, l’élève doit proposer un problème qui est cohérent avec la structure et les codes présents dans le programme. Cette pratique est induite par un intervenant, que ce soit l’enseignant ou un agent virtuel. Cette pratique ne nécessite pas l’utilisation d’un appareil numérique.

* Pratiques n’ayant pas été observées dans le cadre de cette étude.

(Ce tableau continue à la page suivante.)

9. Tracer ou expliquer* L’élève démontre sa compréhension du programme en expliquant, visuellement (avec son doigt) ou verbalement, son déroulement.

Cette pratique peut être initiée par l’élève ou sollicitée par un intervenant. Bien que pouvant être effectuée en lançant le programme sur l’ordinateur, cette pratique ne nécessite pas l’utilisation d’un appareil numérique.

[Robot] Lorsque le programme anime un dispositif robotique, le principal intérêt doit être accordé au programme en soi, et le comportement du robot peut être utilisé pour illustrer l’explication.

10. Concevoir un ordinogramme*

L’élève conçoit un diagramme représentant la structure d’un programme donné et toutes ses composantes. Cette pratique, qui ne nécessite pas l’utilisation d’un appareil numérique, permet de développer une vision d’ensemble du programme et de réfléchir au rôle de chaque composante (codes, paramètres, liaisons, etc.).

* Pratiques n’ayant pas été observées dans le cadre de cette étude.

Tableau 11. – Typologie des pratiques effectives de programmation

4.6 Discussion

D’emblée, il est important de mentionner que le scénario pédagogique a une forte incidence sur les pratiques de programmation effectives des élèves. En effet, si les tâches ou les mises en contexte proposées aux élèves ne favorisent pas la mise en œuvre de certaines pratiques, il est fort probable que ces dernières ne soient pas utilisées. Comme le scénario pédagogique Deviens un maître NAO est plutôt fermé, c’est-à-dire qu’il propose des tâches spécifiques, il est normal que certaines pratiques de programmation non sollicitées par le scénario n’aient pas été mises en œuvre par les élèves. Nous présentons ici les pratiques n’ayant pas été observées dans le cadre de cette étude, mais qui ont tout de même été incluses dans la typologie que nous proposons.

Les pratiques de transformation (transformer) et d’optimisation (optimiser) s’inscrivent dans une suite logique de pratiques plus complexes, mais tout de même accessibles à des élèves du primaire. La transformation implique de changer le corps d’un code tout en conservant sa fonctionnalité élémentaire. Ce changement de corps peut être au niveau du langage (passer d’un langage informatique à un autre) ou encore au niveau des fonctions (remplacer une fonction par

peuvent mener à des résultats similaires. Quant à l’optimisation, elle fait référence à l’action de rendre le code ou le programme plus efficace, notamment en évitant les combinaisons d’éléments pouvant être remplacées par moins d’éléments faisant le même travail.

L’optimisation est d’ailleurs un enjeu majeur dans le travail des programmeurs experts, qui se doivent d’effectuer des programmes hautement complexes tout en nécessitant le moins de ressources possible (Hoos, 2012; Sedgewick et Wayne, 2011).

Les pratiques restantes, c’est-à-dire la spécification d’un problème, le traçage ou l’explication, ainsi que la conception d’un ordinogramme relèvent davantage d’un processus réflexif, voire métacognitif. En effet, ces pratiques permettent de poser un regard différent sur un programme donné. Avec la spécification d’un problème, le processus de résolution de problème est inversé : plutôt que de se voir offrir un problème à résoudre à l’aide de la programmation, l’élève se voit offrir un programme pour lequel il doit trouver un problème dont les composantes et la structure sont en adéquation avec l’algorithme du programme en question. Le traçage ou l’explication sont utilisés pour amener l’apprenant à verbaliser le déroulement d’un programme, inspiré de la méthode think aloud, qui « consiste à demander à des individus de penser à voix haute pendant le processus de résolution d’un problème, puis d’analyser les protocoles verbaux qui en résultent »³³ (van Someren et al., 1994, p. xi). Alors que le traçage peut se faire avec le doigt à l’écran, au fur et à mesure que le programme progresse, l’explication se fait verbalement et consiste à décrire les actions qui surviennent, de même que la logique derrière celles-ci (s’il y a lieu). Enfin, la dernière pratique (concevoir un ordinogramme) a pour but de représenter visuellement la structure globale d’un programme donné. Ceci offre une opportunité tant d’avoir une vue d’ensemble du programme que de réfléchir à la coexistence de plusieurs codes qui se complètent ou qui, parfois, génèrent des contradictions ou des bogues. Il est à noter que les deux dernières pratiques évoquées, c’est-à-dire le traçage ou l’explication et la conception d’un ordinogramme, sont fortement liées à la programmation offline (hors ligne ou débranchées). Ce type de programmation insiste sur la possibilité de réaliser un programme sans support numérique. Il peut donc s’agir d’activités sur une feuille de papier, avec des blocs de bois, ou

33 Traduction libre (« The think aloud method consists of asking people to think aloud while solving a problem and analysing the resulting verbal protocols »)(van Someren, Barnard et Sandberg, 1994, p. xi).

encore au tableau à l’avant de la classe (Computer Science Education Research Group, 2018;

Conde et al., 2017; Horn et al., 2009; Romero et al., 2018). Ces activités mettent l’accent sur les processus cognitifs qui sous-tendent l’action de programmer en soi (le plus complexe) et non l’action, plus technique, d’implémenter le code à l’aide d’un ordinateur (plus technique) (Lopez, 1986).