# Mesurer l'acquisition de la pensée informatique : conception et validation de deux instruments

Kevin Sigayret, A. Tricot, N. Blanc

<figure><img src="image_1.png" /></figure>

## To cite this version:

Kevin Sigayret, A. Tricot, N. Blanc. Mesurer l'acquisition de la pensée informatique: conception et validation de deux instruments. European Review of Applied Psychology / Revue Européenne de Psychologie Appliquée, 2025, 75, pp.101116. 10.1016/j.erap.2025.101116. hal-05302190

HAL Id: hal-05302190

https://hal.science/hal-05302190v1

Submitted on 7 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>
Article original

# Mesurer l'acquisition de la pensée informatique : conception et validation de deux instruments

## *Measuring the acquisition of computational thinking: Design and validation of two instruments*

K. Sigayret<sup>a,b,*</sup> <sup>●</sup>, A. Tricot<sup>a,●</sup>, N. Blanc<sup>a,●</sup>

<figure><img src="image_3.png" /></figure>

## ARTICLE INFO

**Mots clés:**

Programmation

Pensée informatique

Évaluation

Concepts computationnels

Algorithmique

**Keywords:**

Programming

Computational thinking

Evaluation

Computational concepts

Algorithmic

## RÉSUMÉ

**Introduction:** L'apprentissage de la programmation et le développement de la pensée informatique font désormais partie des objectifs pédagogiques dans de nombreux systèmes scolaires à travers le monde. Toutefois, l'absence de consensus sur la définition de la pensée informatique complique l'évaluation de son acquisition en contexte scolaire.

**Objectif:** Cet article vise à proposer deux instruments d'évaluation de la pensée informatique adaptés au contexte scolaire francophone, en distinguant clairement deux dimensions fondamentales : la maîtrise des concepts de programmation et la capacité à résoudre des problèmes algorithmiques.

**Méthode:** Deux tests ont été conçus, le Test de Maîtrise des Concepts Computationnels, centré sur la connaissance des concepts de programmation, et le Test d'Algorithmique, évaluant la capacité à résoudre des problèmes algorithmiques. Ces instruments ont été développés en français et validés à l'aide d'analyses psychométriques.

**Résultats:** Les résultats montrent que les deux tests présentent de bonnes propriétés psychométriques, tant en termes de fiabilité que de validité.

**Conclusion:** Ces deux instruments offrent une alternative pertinente aux outils existants, souvent peu adaptés aux contextes francophones ou trop exigeants en durée de passation. Ils peuvent contribuer à une évaluation plus fine de la pensée informatique dans le contexte scolaire.

## ABSTRACT

**Introduction:** The learning of programming and the development of computational thinking are now part of the educational objectives in many school systems around the world. However, the lack of consensus on the definition of computational thinking complicates the assessment of its acquisition in a school context.

**Objective:** The aim of this article is to propose two assessment instruments for computational thinking adapted to the French-speaking school context, with a clear distinction between two fundamental dimensions: mastery of

<footnote><sup>a</sup> Laboratoire Epsilon UR 4556, université Paul-Valéry Montpellier 3, Montpellier, France</footnote>

<footnote><sup>b</sup> 2, rue Chamayou, 34090 Montpellier, France</footnote>

<footnote>* Auteur correspondant.</footnote>

<footnote>E-mail addresses: kevin sigayret@univ-montp3.fr (K. Sigayret), andre tricot@univ-montp3.fr (A. Tricot), nathalie blanc@univ-montp3.fr (N. Blanc).</footnote>
programming concepts and the ability to
solve algorithmic problems.

**Method:** Two tests were designed: the Mastery of Computational Concepts Test, focusing on knowledge of programming concepts, and the Algorithmic Test, assessing the ability to solve algorithmic problems. These instruments were developed in French and validated using psychometric analyses.

**Results:** Both tests were found to have good psychometric properties, both in terms of reliability and validity.

**Conclusion:** These two instruments offer a relevant alternative to existing tools, which are often ill-suited to French-speaking contexts or too demanding in terms of test-taking time. They can contribute to a more refined assessment of computational thinking in the school context.

# 1. Introduction

L'enseignement de la programmation a intégré (ou réintégré) les cursus scolaires des pays développés, y compris dès l'école primaire (Bocconi et al., 2016). Depuis quelques années, les curricula ont particulièrement mis l'emphase sur la nécessité de développer la pensée informatique, c'est-à-dire une façon particulière de résoudre des problèmes, qui s'appuie sur des concepts issus de l'informatique (Wing, 2006) et dont la maîtrise serait un atout indispensable pour les citoyens du XXᵉ siècle (Ioannou & Makridou, 2018 ; Mohaghegh & McCauley, 2016 ; Nogry, 2018 ; Nordby et al., 2022 ; Romero et al., 2018). Par conséquent, au vu de son importance croissante dans les curricula, il est nécessaire de s'interroger sur la manière d'évaluer les acquis qui font suite à un enseignement visant à développer la pensée informatique. Cet article a pour but de présenter deux instruments de mesure de la pensée informatique ainsi que le processus de validation de ces deux instruments. En premier lieu, nous aborderons la littérature concernant l'apprentissage de la pensée informatique à l'école et nous détaillerons les cadres conceptuels qui permettent de définir la pensée informatique, malgré l'absence de véritable consensus des chercheurs sur la question. La section suivante présentera une revue de la littérature concernant les différents instruments et approches employés pour évaluer ce construit, cette revue étant une synthèse d'une plus large étude publiée dans la revue *Enfance* (Sigayret et al., 2022). Enfin, les apports et les limites de l'existant seront commentés et donneront lieu à une synthèse relative aux manques actuels de la recherche dans ce domaine.

Cette synthèse nous permettra par la suite de proposer deux nouveaux instruments de mesure complémentaires, le Test de Maîtrise des Concepts Computationnels et le Test d'Algorithmique, que nous avons validés et qui nous semblent apporter une plus-value non négligeable pour évaluer les compétences liées à la pensée informatique dans le contexte d'un apprentissage de la programmation à l'école. Le premier test que nous avons conçu (et éprouvé) propose de mesurer la connaissance et la compréhension des concepts fondamentaux en programmation, tels que définis par Tchounikine (2017), à savoir les concepts d'algorithme, d'instruction, de boucle, d'instruction conditionnelle et de variable. Le deuxième test que nous avons conçu (et éprouvé) propose d'évaluer la capacité des élèves à résoudre des problèmes algorithmiques, c'est-à-dire des problèmes dont la solution peut être présentée sous la forme d'un algorithme. Nous conclurons cet article en discutant des limites et des perspectives d'évolution future des deux tests que nous avons conçus.

# 2. Revue de littérature

## 2.1. Apprendre la programmation et la pensée informatique

La programmation désigne « l'ensemble des activités liées à la définition, l'écriture, la mise au point et l'exécution de programmes informatiques » ainsi que la « séquence des ordres auxquels doit obéir un dispositif » (Dictionnaire Larousse en ligne, s.d.). La programmation est considérée comme un moyen de communiquer, partager, explorer des idées et serait un outil pour apprendre et réaliser des tâches (Chevalier, 2022). Elle implique généralement l'utilisation d'un logiciel ou d'un langage de programmation. En contexte scolaire, la programmation désigne généralement diverses activités qui permettent de développer la capacité à mettre en œuvre des algorithmes, c'est-à-dire des successions d'instructions utilisées pour concevoir un système ou résoudre un problème. Pour Tchounikine (2017, p. 11), un algorithme est « un enchaînement mécanique d'actions, dans un certain ordre, qui chacune a un effet, et dont l'exécution complète permet de résoudre ou de faire quelque chose ». Cependant, programmer est exigeant sur le plan cognitif, car cela implique la maîtrise de plusieurs domaines ; son apprentissage impliquerait de mettre en relation de nombreux concepts et procédures (Berssanette & de Francisco, 2021). La programmation exige généralement des programmeurs qu'ils aient une connaissance des langages de programmation, une expertise relative à la conception d'algorithmes spécifiques et à la logique, la capacité d'analyser, de comprendre et de résoudre des problèmes et d'évaluer l'exactitude et la mise en œuvre de l'algorithme dans un langage de programmation particulier (Forsström & Kaufmann, 2018).

Il est généralement admis que la programmation contribuerait à l'acquisition de la « pensée informatique », qui regrouperait un ensemble de compétences, et dont le développement est parfois considéré comme l'objectif d'apprentissage fondamental de toute pratique de la programmation à l'école. « Pensée informatique » s'est imposé en français comme la traduction de l'expression « computational thinking » en anglais. Cependant, cette traduction est imparfaite. En effet, l'expression originale comprend le mot « *thinking* » qui désigne le processus de pensée plutôt que la pensée elle-même (« *thought* »). De même, le mot « computationnel » existe en français et la traduction de « computational » en « informatique », qui est un terme plus général, semble critiquable. Ainsi, nous devrions probablement davantage parler de « processus de pensée computationnels » que de « pensée informatique ». Toutefois, nous employerons l'expression « pensée informatique » dans le texte, puisque cette expression semble faire consensus auprès de la
communauté des chercheurs et enseignants francophones.

Taslibeyaz et al. (2020) constatent que la capacité à analyser et résoudre un problème demeure la compétence la plus fréquemment mentionnée dans la littérature pour décrire la pensée informatique, devant l'aptitude à programmer, même si les activités de programmation constituent le contexte d'apprentissage le plus souvent mis en œuvre pour la développer. La pensée informatique peut être considérée comme l'ensemble des capacités cognitives de résolution de problèmes qui déterminent notamment la capacité à programmer (Denning, 2017). En théorie, la programmation est la meilleure approche pour enseigner la pensée informatique (Buitrago Flórez et al., 2017; Lye & Koh, 2014), bien que la pensée informatique représente généralement une capacité cognitive plus large (Tsarava et al., 2019). Pour Román-González et al. (2019), la pensée informatique fournit le cadre qui permet de se concentrer non pas sur la syntaxe de la programmation informatique, mais sur les processus mentaux sous-jacents. Les processus impliqués dans les activités de programmation requièrent des compétences en résolution de problèmes et participent en fin de compte à l'acquisition de la pensée informatique (Yadav et al., 2017). Pensée informatique et programmation semblent donc résolument liées. Par ailleurs, nous savons aujourd'hui avec un haut niveau de certitude que la programmation et la pensée informatique peuvent être enseignées en contexte scolaire. Scherer et al. (2020) ont rapporté dans leur méta-analyse que l'enseignement de la programmation a un effet fort sur les connaissances et compétences dans ce domaine (g = 0.81). Une méta-analyse récente de Sun et al. (2022) confirme cet état de fait en révélant un effet modéré en faveur d'un impact positif de l'apprentissage de la programmation sur les compétences en pensée informatique (g = 0.61).

La définition précise de la pensée informatique ne fait cependant pas l'objet d'un consensus entre les chercheurs et demeure aujourd'hui ouverte aux interprétations (Brennan & Resnick, 2012; Mohaghegh & McCauley, 2016; Román-González et al., 2017; Moreno-León et al., 2018; Tang et al., 2020). Dans une méta-analyse portant sur 101 études, Tikva et Tambouris (2021) ont recensé 60 éléments différents dans la littérature qui sont associés à un cadre conceptuel ou à une définition de la pensée informatique ou simplement évalués dans des études empiriques. Nous pouvons toutefois distinguer trois types de définitions de la pensée informatique (Román-González et al. (2017). Les définitions les plus générales considèrent la pensée informatique comme « l'ensemble des processus de pensée impliqués dans la formulation d'un problème et l'expression de sa solution de manière à ce qu'un ordinateur – humain ou machine – puisse effectivement l'exécuter » (Wing, 2011) ou de manière à ce que « sa solution puisse être représentée sous forme d'étapes de traitement ou de calcul (computational steps) et d'algorithmes » (Aho, 2012, p. 1). Les définitions opérationnelles décomposent la pensée informatique en un ensemble de sous-processus cognitifs impliqués notamment dans la résolution de problèmes algorithmiques. Ces définitions opérationnelles ne sont pas spécifiques à l'apprentissage de la programmation, contrairement aux définitions pédagogiques, plutôt centrées sur la mise en œuvre de la pensée informatique en contexte scolaire, en s'appuyant sur le logiciel de programmation éducatif Scratch.

Pour Selby et Woollard (2013), la pensée informatique est un processus cognitif qui inclue la capacité à penser en termes d'abstraction, de décomposition, d'évaluation, de généralisation et de manière algorithmique, associé (mais pas limité) à la résolution de problèmes. Cependant, ces processus ne sont pas nécessairement spécifiques à ce domaine et peuvent être retrouvés dans un grand nombre d'activités cognitives, ce qui témoigne de la difficulté à définir cette pensée informatique en des termes suffisamment spécifiques. Pourtant, les processus cités précédemment font souvent partie des nombreux cadres conceptuels qui ont tenté de définir la pensée informatique (Barr & Stephenson, 2011; CSTA & ISTE, 2011; Kalelioglu et al., 2016, Shute et al., 2017; Weintrop et al., 2016). Pour Grover et Pea (2013), l'abstraction, qui consiste à « définir des modèles et à généraliser à partir d'exemples

spécifiques » (p. 41), est la clé de voûte de la pensée informatique, ainsi qu'un moyen efficace de faire face à des problèmes complexes (Wing, 2011).

Brennan et Resnick (2012) distinguent les concepts computationnels (notions à connaître en programmation), les pratiques computационnelles (ensemble de stratégies et de procédure à mettre en œuvre pour concevoir des programmes) et les perspectives computationnelles (nouvelles possibilités d'expression et d'exploration par le biais des activités de programmation). Zhang et Nouri (2019) ont complété les travaux de Brennan et Resnick (2012) et ont observé que dans la plupart des études la maîtrise des concepts computationnels est fréquemment évaluée, contrairement aux perspectives computationnelles, très rarement mesurées. Les concepts sont en effet aisément évalués, que ce soit par des tests ou par l'analyse automatique des artéfacts d'apprentissage (code), là où les perspectives sont nettement plus difficiles à mesurer par le biais des moyens traditionnels d'évaluation. Cependant, la distinction opérée par Brennan et Resnick (2012) entre la maîtrise de concepts, qui relève de la connaissance et de la compréhension, et la maîtrise de pratiques, qui relève davantage de la compétence, semble particulièrement pertinente et rejoint la définition originelle de Wing (2006) qui considère la pensée informatique comme une capacité à résoudre des problèmes qui s'appuie sur la maîtrise de concepts en informatique.

## 2.2. Revue des instruments d'évaluation de la pensée informatique

Les instruments de mesure de la pensée informatique peuvent être classés en quatre catégories distinctes : les échelles autoévaluatives, les outils d'analyse automatique du code produit par les élèves, les évaluations fondées sur la résolution de problèmes et les évaluations fondées sur l'apprentissage implicite de la pensée informatique. Cette section aura pour fonction de synthétiser les apports et limites de ces instruments. Un paragraphe sera consacré à chacune des catégories.

Korkmaz et al. (2017) ont développé le Computational Thinking Scales (CTS), qui compile des éléments de divers tests préexistants. Ils se fondent sur un document de l'International Society for Technology in Education (ISTE, 2015, citée dans Korkmaz et al., 2017) définissant la pensée informatique comme un ensemble de compétences. Le CTS vise à évaluer la créativité, l'algorithmique, la pensée critique, la résolution de problèmes et la coopération. Les items sont tirés de différents tests existants. Le questionnaire est autoadministré, ce qui soulève des questions sur la subjectivité des réponses. Il a été validé auprès de plus de 700 étudiants universitaires. La validité du CTS a été par la suite confirmée auprès d'élèves plus jeunes, âgés de 15 à 16 ans (Korkmaz & Bai, 2019). Cependant, l'utilisation du CTS comme instrument de mesure de la pensée informatique demeure critiquable. En effet, même s'il est pertinent de considérer que la pensée informatique entretient des liens avec la créativité ou la pensée critique, il peut sembler réducteur de considérer que la pensée informatique n'est constituée que d'une combination de compétences bien identifiées. D'autres échelles, comme celles de Weese et Feldhausen (2017) ou bien de Kukul et Karatas (2019), évaluent également le sentiment d'auto-efficacité des élèves concernant la pensée informatique. Ces échelles peuvent être utiles pour l'auto-évaluation après des interventions visant à développer la pensée informatique mais présentent le même biais de subjectivité que le CTS.

Alves et al. (2019) ont réalisé une revue des outils fondés sur l'analyse du code produit par les élèves, mais cette méthode suppose que les compétences sont visibles simplement à travers l'exploitation du code réalisé par les élèves, ce qui n'est pas nécessairement le cas. Cette approche est donc également limitée car l'utilisation de certains blocs (ou instructions) ne garantit pas la compréhension des concepts. Par exemple, l'outil Dr. Scratch analyse automatiquement les fichiers Scratch pour évaluer la pensée informatique et fournit un feedback en trois niveaux de compétence. Il a été montré que ce feedback améliore les performances des élèves et potentiellement leur maîtrise des compétences en pensée informatique (Moreno-León & Robles, 2015). Dr. Scratch évalue plutôt des compétences techniques, telles que la
synchronisation et la représentation des données, qui relève peut-être davantage de l'utilisation correcte du logiciel que de la pensée informatique au sens large. Certains critères, comme l'interactivité du programme, ne semblent pas toujours pertinents pour évaluer la maîtrise de la pensée informatique. Cependant, de fortes corrélations ont été mesurées entre les évaluations réalisées sur Dr. Scratch et celles réalisées par des experts humains (Moreno-León et al., 2017). Les instruments fondés sur l'analyse du code sont principalement utilisés pour une évaluation formative pendant l'apprentissage, afin d'aider les élèves à développer leurs compétences en pensée informatique. Ils sont spécifiques à un langage ou à un logiciel, ce qui limite leur utilisation, mais peuvent être adaptés à tous les niveaux d'âge et de compétence. Par exemple, Dr. Scratch peut être utilisé par tous les élèves ayant appris à programmer sur Scratch, indépendamment de leur niveau ou de leur âge.

D'autres méthodes d'évaluation de la pensée informatique vont au-delà de l'examen du code et impliquent des tâches de résolution de problèmes. Le Computational Thinking Test (CTt) de Román-González (2015) constitue probablement une des tentatives les plus abouties en ce sens. Il vise à évaluer la compréhension de concepts informatiques telles que les instructions de base, les boucles, les conditions et les fonctions. Ce CTt présente une validité convergente, étant corrélaté à d'autres tests mesurant des capacités spatiales, de raisonnement et de résolution de problèmes (Román-González et al., 2017) et une validité prédictive pour les performances académiques et la réussite en programmation au collège (Román-González et al., 2018). Cependant, il semble que dans le CTt, la distinction entre la maîtrise des concepts et les compétences pratiques de résolution de problème soit floue. Román-González (2015) souligne que la structure du test, basée uniquement sur des questions fermées à choix multiples, ne permet d'évaluer que les aspects les plus simples de la pensée informatique, tels que la compréhension des concepts et la reconnaissance de solutions parmi plusieurs options fournies. D'autres instruments de mesure se sont focalisés sur la résolution de problèmes indépendants des activités de programmation. Li et al. (2021) ont proposé le Computational Thinking Assessment for Chinese Elementary Students (CTA-CES) et ont montré à l'aide d'images par résonance magnétique (IRMf) que l'activité neuronale des élèves impliqués dans la réalisation de leur test était corrélatée à leur activité neuronale pendant les activités de programmation, ce qui semble renforcer la validité de leur instrument. Lai & Ellefson, 2022 ont également proposé (et validé) un test, le Computational Thinking Challenge (CTC), fondé sur des exercices de résolution de problèmes, qui propose à la fois des problèmes en lien avec des activités de programmation et des problèmes indépendants de toute activité de programmation. Cependant, à l'instar des autres tests mentionnés précédemment, le CTA-CES et le CTC ne proposent que des questions à choix multiples, ce qui signifie qu'ils ne mesurent pas la capacité des élèves à générer leurs propres solutions à un problème. À notre connaissance, seuls Chen et al. (2017) ont développé un instrument d'évaluation de la pensée informatique axé sur la résolution de problèmes et comprenant des questions ouvertes pour lesquelles les réponses n'impliquaient pas de choisir parmi différentes solutions proposées. Cependant, cet instrument implique la maîtrise d'une syn taxe spécifique et a été conçu pour des activités de robotique, ce qui le rend difficile à adapter dans un autre contexte. Par ailleurs, les tests visant à mesurer la capacité à résoudre des problèmes de programmation, indépendants des logiciels ou langages ayant été pratiqués par les élèves, se sont multipliés ces dernières années (Basu et al., 2021 ; El-Hamamsy et al., 2022 ; Kong & Wang, 2021 ; Relkin et al., 2020 ; Sung, 2022).

Enfin, Rowe et al. (2021) ont proposé une méthode novatrice pour évaluer l'apprentissage implicite des élèves face à des tâches impliquant des compétences liées à la pensée informatique. L'apprentissage implicite désigne ici un type d'apprentissage dont les résultats sont observables pendant l'activité d'apprentissage elle-même. Pour ce faire, l'activité des élèves est capturée et enregistrée en temps réel. Les auteurs ont utilisé le jeu vidéo éducatif Zoombinis, qui comprend des épreuves

fondées sur la logique et la déduction. Contrairement aux évaluations traditionnelles qui se concentrent sur la capacité à résoudre des problèmes, cette méthode évalue les processus sous-jacents à cette résolution. Les chercheurs ont développé des instruments pour détecter la maîtrise implicite de la pensée informatique chez les élèves âgés de 8 à 14 ans, en se basant sur les données recueillies. Ces instruments permettent notamment de repérer la capacité à décomposer un problème complexe en sous-problèmes plus simples, à identifier des règles implicites, à tester diverses hypothèses de manière systématique, et à réutiliser des stratégies efficaces. Ces comportements, tels que l'absraction et la décomposition, sont considérés par de nombreux chercheurs comme caractéristiques de la pensée informatique. Cette approche offre une évaluation formative en temps réel basée sur des activités ludiques, mettant en lumière les comportements révélateurs d'une maîtrise émergente de la pensée informatique, tout en se distinguant des évaluations traditionnelles sous forme de tests. Cependant, l'obtention et l'analyse des données de jeu requièrent des connaissances techniques et du temps, limitant la généralisation de cette méthode d'évaluation.

## 2.3. Limite des instruments d'évaluation de la pensée informatique

L'absence de consensus concernant une définition conceptuelle de la pensée informatique se traduit logiquement par une absence de consensus quant à la manière la plus appropriée de la mesurer ou de l'évaluer. Dans une revue de la littérature comprenant 26 études concernant l'évaluation de la pensée informatique, Babazadeh et Negrini (2022) recensent 59 dimensions associées à la pensée informatique évaluées par les différents instruments de mesure proposés, bien que seulement 21 d'entre elles ne soient pas spécifiques à un instrument particulier. Román-González et al. (2019) remarquent d'ailleurs que de nombreux chercheurs recommandent d'associer des instruments de mesure complémentaires pour évaluer l'apprentissage de la pensée informatique.

Dans l'ensemble, les instruments de mesure de la pensée informatique que nous avons précédemment examinés constituent des efforts pertinents pour évaluer cette compétence (ou cet ensemble de compétences). Cependant, ils ne parviennent pas à faire une distinction claire entre, d'une part, la connaissance et la maîtrise des concepts par les élèves et, d'autre part, leur capacité à appliquer ces connaissances pour résoudre des problèmes complexes. Souvent, ces deux aspects fondamentaux sont confondus, ce qui rend difficile de déterminer si les instruments d'évaluation mesurent le niveau de compréhension des élèves par rapport à certains concepts ou leur niveau de maîtrise des compétences nécessaires pour aborder des situations inédites en s'apuyant sur leurs connaissances. Nous estimons que cette distinction est essentielle. Si l'objectif est de créer des instruments d'évaluation permettant de discriminer différents niveaux de maîtrise de la pensée informatique, il est nécessaire de distinguer les aspects les plus fondamentaux, tels que la connaissance et la compréhension des concepts, des aspects plus complexes, comme l'assimilation et l'application pratique de ces concepts ainsi que le développement de stratégies pour résoudre les problèmes. Une évaluation distincte de ces deux aspects de l'apprentissage de la programmation permettrait aux enseignants d'affiner leur diagnostic concernant les éventuelles difficultés rencontrées par leurs élèves. Ces derniers maîtrisent-ils suffisamment les concepts fondamentaux utilisés en programmation ? Et si c'est le cas, sont-ils capables de les appliquer dans des contextes pratiques en utilisant les stratégies appropriées ?

Par ailleurs, nous avons pu constater certaines limites qui rendent difficile l'application de l'un ou de plusieurs de ces tests dans les classes françaises ou francophones. Les instruments d'évaluation fondés sur la résolution de problèmes semblent particulièrement indiqués pour mesurer la pensée informatique. Cependant, aucun de ces tests n'a été validé en langue française et il n'est pas évident qu'ils s'adaptent suffisamment aux différents systèmes scolaires du monde francophone. De
plus, les tests proposés, bien que relativement complets, sont souvent longs et donc peu pratiques à appliquer dans un contexte scolaire, particulièrement dans le second degré où la durée des cours est limitée. Ils sont généralement composés de plusieurs dizaines d'items pour une durée supérieure à 1 heure. Enfin, ceux-ci sont quasi exclusivement constitués de questions à choix multiples qui ne permettent donc pas d'évaluer la capacité de l'élève à produire par lui-même une solution à un problème sous la forme d'un algorithme ou d'un programme. Un instrument visant à évaluer les aspects plus complexes de la pensée informatique devrait au contraire demander aux élèves de démontrer leur capacité à résoudre des problèmes, en proposant leurs propres solutions. Pour ces différentes raisons, il nous a semblé pertinent de proposer nous-mêmes deux nouveaux instruments d'évaluation en français de la pensée informatique, en situation d'apprentissage de la programmation, qui respectent cette distinction entre maîtrise des concepts et capacité de résolution de problèmes algorithmiques, essentielle à nos yeux, qui répondent aux impératifs écologiques relatifs à l'organisation des séances en classes et qui ne se basent pas uniquement sur des questions à choix multiples. La conception et la validation de ces deux tests feront l'objet des parties suivantes.

Enfin, il est important de noter que dans le domaine de l'informa-
tique en général, et de la programmation en particulier, il semble
indispensable d'évaluer les différences entre les filles et les garçons, au
vu des inégalités maintes fois observées dans la littérature, que celles-ci
concernent les performances des élèves, ou leur niveau de motivation,
d'engagement et d'auto-efficacité. En effet, il est communément admis
que les garçons présentent un intérêt, une motivation et un engagement
plus important dans les activités de programmation en général (Gökçe &
Yenmez, 2022; Korkmaz & Bai, 2019; Rubio et al., 2015; Weintrop &
Wilensky, 2019), en raison de stéréotypes associés aux femmes et à
l'informatique (Armoni et al., 2015; Bers et al., 2022; Ching et al.,
2018). La question de l'adaptation d'un instrument à tous les élèves quel
que soit leur sexe n'est que rarement abordée dans les autres études de
validation. Par conséquent, une analyse différenciée des résultats à nos
deux tests selon le sexe des élèves sera également proposée.

3. Test de maîtrise des concepts computationnels

Afin d'établir un cadre clair et explicite, nous définirons les cinq concepts computationnels fondamentaux de la manière suivante : un algorithme est une succession d'actions (ou d'instructions), présentées dans un certain ordre, qui permet de résoudre un problème (au sens large) ; une instruction est un ordre (ou une action) à exécuter ; une boucle est une instruction qui permet de répéter plusieurs fois certaines instructions ; une instruction conditionnelle ne s'exécute que lorsqu'une certaine condition est remplie ; une variable permet de stocker et de modifier une valeur. Nous avons nommé notre test : Test de Maîtrise des Concepts Computationnels. En effet, au vu des similitudes entre les concepts identifiés par Tchounikine (2017) et les computational concepts identifiés par Brennan et Resnick (2012), et compte tenu de la traduction imparfaite de l'expression originale « computational thinking » en « pensée informatique », nous avons jugé plus opportun d'opter pour une traduction littérale en « concepts computationnels », ce qui permet de faire le lien entre les concepts de programmation de Tchounikine (2017) et le sens premier de l'expression « pensée informatique » qui désigne plutôt les processus de pensée computationnels (computational thinking). L'objectif est de valider un test en français, relativement court comparé aux autres instruments d'évaluation des connaissances et compétences en pensée informatique ou en programmation. Pour ce test, les items retenus correspondent tous à des questions à choix multiples. Le Test de Maîtrise des Concepts Computationnels est disponible en Annexe 1.

3.1. Méthode

3.1.1. Participants

La validation de ce test a mené au recrutement de 624 participants

(320 filles) dont 3 élèves en 7ᵉ année du primaire (9 ans), 27 en 8ᵉ année du primaire (10 ans), 98 en 1ᵉ année du secondaire (11 ans), 116 en 2ᵉ année du secondaire (12 ans), 183 en 3ᵉ année du secondaire (13 ans) et 197 en 4ᵉ année du secondaire (14 ans). Nous avons conçu deux versions de ce test, une version papier et une version en ligne, strictement similaires. Pour la version en ligne, nous avions 449 élèves (238 filles) dont 3 élèves de 7ᵉ année et 19 de 8ᵉ année (primaire) ainsi que 98 de 1ᵉ année, 16 de 2ᵉ année, 183 de 3ᵉ année et 130 de 4ᵉ année (secondaire). Pour la version papier, nous avions 175 élèves (82 filles), dont 8 élèves de 7ᵉ année (primaire), 100 de 2ᵉ année (secondaire) et 67 de 4ᵉ année (secondaire). Nous avons bénéficié du réseau de la Délégation Régionale Académique au Numérique Éducatif (DRANE) de l'Académie de Montpellier pour recruter des classes de différents niveaux dans cette région. Pour la version en ligne du test, nous avons élargi notre périmètre de recherche et nous avons fait appel à des enseignants issus d'autres régions françaises ainsi qu'à des associations ou à des écoles d'apprentissage du code informatique pour les enfants.

3.1.2. Matériel

Nous avons tout d'abord conçu un questionnaire visant à évaluer le niveau de pratique de la programmation des élèves, disponible en Annexe 2. L'objectif est de permettre de mesurer un lien de corrélation entre ce niveau de pratique de la programmation et les performances des élèves au Test de Maîtrise des Concepts Computationnels. Après avoir recueilli le sexe, l'âge et le niveau scolaire, nous demandons aux élèves s'ils ont déjà pratiqué la programmation. Si leur réponse est positive, ceux-ci doivent remplir un questionnaire comprenant 8 questions. Les quatre premières questions nous permettent de savoir approximativement à quelle période ils ont commencé la programmation, quand ils ont programmé pour la dernière fois, la fréquence de leurs activités de programmation depuis le début de l'année scolaire et enfin, une estimation du nombre d'heures passées à programmer. Les réponses à ces quatre questions devaient être apportées sur une échelle de Likert en trois, quatre ou cinq options de réponse (et donc codés de 0 à 2, 3 ou 4 points). Les quatre dernières questions proposaient aux élèves de répondre par oui ou par non (0 à 1 point), selon s'ils ont déjà programmé en dehors de l'école, s'ils ont déjà réalisé des activités de programmation débranchées (sans ordinateur ni outil numérique), s'ils ont déjà utilisé des logiciels de programmation tels que Scratch, Blockly etc., et s'ils ont déjà programmé un robot ou un objet connecté. Au total, le questionnaire de niveau de pratique en programmation était évalué sur 16 points.

Pour concevoir ce test, nous nous sommes appuyés sur la taxonomie révisée de Bloom (Krathwohl, 2002). Cette taxonomie des objectifs éducatifs se présente sous la forme d'un système de classification des buts, des objectifs et, plus récemment, des normes en matière d'éducation. Elle distingue deux composantes essentielles. D'une part, la dimension des connaissances regroupe les connaissances factuelles, conceptuelles, procédurales ou métacognitives. D'autre part, la dimension des processus cognitifs regroupe la capacité à se remémorer, comprendre, appliquer, analyser, évaluer et créer. Il est important de remarquer que ces processus sont hiérarchisés (et souvent représentés sous la forme d'une « pyramide ») en fonction de leur niveau de complexité, du plus simple (« se remémorer ») au plus complexe (« créer »).

Notre instrument de mesure propose de tester les connaissances factuelles, à savoir les éléments de base en programmation et la terminologie qui leur est associée, ainsi que les connaissances conceptuelles des élèves, à savoir les relations entre ces éléments de base (les concepts de programmation) qui peuvent être catégorisés, classifiés ou structurés. Certaines connaissances procédurales peuvent aussi être mises en jeu, comme nous le verrons un peu plus loin. De même, notre test est pensé pour évaluer les quatre types de processus cognitifs les plus simples, c'est-à-dire la capacité à se remémorer les concepts fondamentaux en programmation (retrouver des connaissances pertinentes), à comprendre ces concepts (en déterminer le sens), à appliquer les connaissances liées à ces concepts (réaliser ou utiliser une procédure dans une situation
donnée) et enfin à analyser (décomposer quelque chose en ses éléments constitutifs et détecter les relations entre ces éléments).

Nous avons ainsi conçu 22 items qui constituent ce Test de Maîtrise des Concepts Computationnels. Les cinq premiers items sont des items de catégorisation (chacun est relatif à un des cinq concepts évalués par ce test), pour lesquels l'élève doit distinguer parmi plusieurs propositions ce qui relève ou non du concept en question. Par exemple, l'item 1 propose quatre textes différents et l'élève doit sélectionner ceux qui sont des algorithmes. La Fig. 1 est un exemple d'item de catégorisation. Les quatre items suivants sont des items d'application, directement issus et traduits du Computational Thinking Test de Román-González (2015). Les élèves sont confrontés à une illustration représentant un personnage (Pac-Man) devant être programmé pour atteindre un autre personnage (un fantôme). Un ou plusieurs programmes leur sont proposés et ceux-ci doivent, selon l'item concerné, indiquer quelle est l'instruction fausse, quelle est l'instruction manquante ou tout simplement quel programme permet d'atteindre l'objectif donné. Ceci implique que l'élève maîtrise les connaissances procédurales qui consistent à exécuter mentalement un programme pour en déterminer le résultat. Deux de ces items concernent le concept de boucle et les deux autres le concept d'instruction conditionnelle, car ce type d'items est mieux adapté à l'évaluation de ces deux concepts.

Les items 10 à 14 sont des affirmations pour lesquelles les élèves doivent indiquer si elles sont vraies ou fausses. Ces affirmations mettent systématiquement en relation plusieurs de nos concepts. Pour les items 15 à 18, un programme est proposé aux élèves. Certaines parties de ce programme sont désignées par des flèches ou des accolades numérotées. Les élèves doivent associer ce qui est indiqué par les flèches ou accolades aux concepts d'algorithme, de boucle, de condition ou de variable, comme illustré sur la Fig. 2. Ceci permet donc d'évaluer la capacité à différencier les constituants d'un programme et à les organiser les uns à

l'intérieur des autres (par exemple, une boucle est intégrée à l'intérieur d'un algorithme). Aucune de ces flèches ou accolades ne correspond au concept d'instruction, afin de ne pas introduire une confusion. En effet, une boucle ou une instruction conditionnelle sont des instructions. Enfin, les quatre derniers items sont des textes à trous qui proposent aux élèves de retrouver les définitions des différents concepts (chaque trou doit être complété par un des concepts).

Le Tableau 1 associe chaque catégorie d'items à une ou plusieurs dimensions des connaissances et à une ou plusieurs dimensions des processus cognitifs (entre parenthèses la sous-dimension correspondante), selon la taxonomie révisée de Bloom (Krathwohl, 2002).

Pour chaque question, les élèves étaient informés si celle-ci exigeait une seule réponse correcte ou si plusieurs réponses correctes étaient possibles. Lorsqu'une seule réponse était attendue, une réponse correcte valait 1 point et toute autre réponse valait 0 point. Lorsque plusieurs réponses étaient correctes, cet item valait autant de points qu'il y avait de réponses correctes. Chaque bonne réponse valait 1 point et chaque mauvaise réponse valait -1 point. Si le nombre de points obtenus pour un item était négatif, cette valeur était ramenée à 0. Les items peuvent être regroupés en cinq catégories différentes correspondant aux cinq concepts fondamentaux : algorithme (quatre items, 7 points), instruction (deux items, 5 points), boucle (six items, 8 points), condition (six items, 7 points) et variable (quatre items, 4 points). Ce test est conçu pour évaluer une performance (sur 31 points). Ainsi, les résultats totaux ont été pris en compte même si certains items sont restés sans réponse.

### 3.1.3. Procédure

Avant de passer le test, les élèves devaient tout d'abord remplir le questionnaire évaluant leur niveau de pratique en programmation. Les interlocuteurs à qui nous avons présenté ce test (professeurs, membres d'associations...) ont été informés que les élèves devaient travailler seuls

Parmi les 4 programmes ci-dessous, lesquels contiennent une boucle ?

Plusieurs réponses possibles.

<figure><img src="image_4.png" /><figcaption>Fig. 1. Exemple d'item de catégorisation relatif au concept de boucle.</figcaption></figure>
Dans le programme ci-dessous, associe chaque numéro avec un des mots suivants :
Variable ; Boucle ; Condition ; Algorithme.

<figure><img src="image_5.png" /><figcaption>Fig. 2. Items 15 à 18 du Test de Maîtrise des Concepts Computationnels (ici les élèves doivent associer chaque flèche ou accolade à un concept computationnel).</figcaption></figure>

## Tableau 1

Répartition des items en fonction des dimensions des connaissances et des dimensions des processus cognitifs qui y sont associés, selon la taxonomie révisée de Bloom (Krathwohl, 2002).

<table><thead><tr><th>Dimensions</th><th>5 items<br/>catégorisation</th><th>4 items application</th><th>5 items<br/>vrai/faux</th><th>4 items reconnaissance</th><th>4 items<br/>textes à trous</th></tr></thead><tbody><tr><td>Connaissances</td><td>Factuelles</td><td>Procédurales</td><td>Factuelles<br/>Conceptuelles</td><td>Conceptuelles</td><td>Factuelles<br/>Conceptuelles</td></tr><tr><td>Processus cognitifs</td><td>Comprendre (classifier)</td><td>Appliquer (exécuter)</td><td>Analyser (différentier)</td><td>Se remémorer (reconnaître)<br/>Analyser (différentier -organiser)</td><td>Se remémorer (rappeler)<br/>Analyser (différentier)</td></tr></tbody></table>

et ne pouvaient bénéficier de l'aide d'un adulte, à l'exception de certaines précisions ponctuelles qui pouvaient être apportées concernant le vocabulaire employé ou la formulation des questions, lorsque celles-ci étaient jugées nécessaires. Un temps maximum de 20 minutes avait été fixé pour la réalisation du test. L'ensemble des questionnaires était anonymisé.

## 3.2. Résultats

Afin d'analyser les résultats obtenus, nous avons mesuré un indice de fiabilité et un indice de validité du test que nous proposons. La fiabilité est entendue comme la capacité d'un test à reproduire un résultat de manière cohérente dans le temps et l'espace alors que la validité se réfère à la capacité d'un test à mesurer exactement ce qu'il est censé mesurer (El-Hamamsy et al., 2022). L'impact du niveau scolaire et du sexe des élèves sur leur niveau de pratique et leurs performances au test a également été mesuré. Les analyses que nous avons menées ont été réalisées sur le logiciel Jamovi, version 2.3.26.0.

### 3.2.1. Analyse de fiabilité-version en ligne

Pour nos analyses de fiabilité, nous utiliserons le coefficient $\omega$ de McDonald, reconnu comme étant un indicateur plus pertinent et fiable que le très utilisé coefficient $\alpha$ de Cronbach, en particulier en ce qui concerne la recherche appliquée (Dunn et al., 2014; Trizano-Hermosilla & Alvarado, 2016). La fiabilité globale du test peut être considérée comme élevée, selon Taber (2018), car $\omega = .834$. Le Tableau 2 présente, pour certains items, la valeur du coefficient $\omega$ si cet item était supprimé du test ainsi que le lien de corrélation entre l'item en question et le reste des items, mesuré à l'aide du coefficient r de Pearson. Nous n'avons reporté dans ce Tableau 2 que les items pour lesquels une suppression entraîne une augmentation de la fiabilité globale du test. Les items sont notés A, I, B, C ou V selon s'ils permettent d'évaluer, respectivement, la maîtrise du concept d'algorithme, d'instruction, de boucle, de condition ou de variable. Par exemple, l'item I2 correspond au deuxième item portant sur le concept d'instruction.

Nous pouvons observer dans le Tableau 2 que la fiabilité du test augmente lorsque les items I2, B4, C4 et V2 sont retirés. Ce sont aussi ces quatre items qui corrèlent le moins avec le reste du test (avec une valeur de $r$ comprise entre $-.03$ et .21). Ces items correspondent à quatre des cinq items vrai/faux de notre test. L'item A2, également un item vrai/ faux, ne semble pas poser problème. Cependant, conserver un seul des items vrai/faux aurait peu de sens, d'autant plus que celui-ci n'est pas non plus l'item qui corrèle le mieux avec les autres items du test. Ainsi, nous avons pris la décision de supprimer l'ensemble des items vrai/faux de notre test, en raison de leur manque de fiabilité. Ceci a pour conséquence d'augmenter la fiabilité globale de notre test ($\omega = .85$). Les cinq items vrais/faux ayant été supprimés sont disponibles en Annexe 3.

Il peut parfois être intéressant de mesurer la fiabilité de chaque facteur mesuré, c'est-à-dire, dans notre contexte, de chaque concept dont on évalue la maîtrise. Cependant, et ce d'autant plus après le retrait des cinq items vrai/faux, le nombre d'items par concept demeure faible (entre trois et cinq items pour les concepts d'algorithme, de boucle, de condition et de variable, un seul item pour le concept d'instruction). Pour cette raison, il est peu probable que la cohérence interne de chaque facteur mesuré soit élevée, puisque la fiabilité tend à augmenter avec le nombre d'items (Taber, 2018). Pour le concept d'instruction, basé sur un seul item après la suppression des items vrai/faux, cette mesure ne peut pas être effectuée. Pour les concepts d'algorithme, de boucle, de condition et de variable, les mesures de fiabilité sont respectivement : $\omega = .59$, $\omega = .56$, $\omega = .58$ et $\omega = .50$. Notons que, malgré le faible nombre

## Tableau 2

Valeur de $\omega$ si l'item correspondant est supprimé et lien de corrélation entre chacun de ces items et les autres items du Test de Maîtrise des Concepts Com- putationnels (version en ligne).

<table><thead><tr><th>Item</th><th>Valeur de ω si l'item est retiré</th><th>Corrélation item-reste du test</th></tr></thead><tbody><tr><td>I2</td><td>.838</td><td>.13</td></tr><tr><td>B4</td><td>.836</td><td>.21</td></tr><tr><td>C4</td><td>.837</td><td>.17</td></tr><tr><td>V2</td><td>.843</td><td>-.03</td></tr></tbody></table>
d'items, ces valeurs sont toutes supérieures ou égales à .50, ce qui correspond à une fiabilité modérée selon Hinton et al. (2014), cités par El-Hamamsy et al. (2022), et peut être considéré comme acceptable selon certains auteurs (Taber, 2018).

### 3.2.2. Analyse de validité-version en ligne

Nous avons mesuré les liens de corrélation qui existent entre, d'une part, le niveau de pratique de la programmation des élèves et, d'autre part, leurs performances à ce test. Le niveau de pratique et les performances globales au test sont liés par une corrélation positive d'intensité modérée (r = .61). Concernant les différents concepts dont la maîtrise est mesurée dans ce test, il existe également des liens de corrélations positifs d'intensité modérée avec le niveau de pratique en programmation, bien que ces coefficients soient plus faibles, que ce soit pour le concept d'algorithme (r = .48), d'instruction (r = .52), de boucle (r = .50), de condition (r = .49) ou de variable (r = .45). Toutes ces corrélations sont significatives à p < .001. Par ailleurs, nous avons pu observer que les performances au test varient significativement selon le niveau de pratique en programmation des élèves, avec un effet fort (F (14, 434) = 21.9, p < .001, η² = .414).

### 3.2.3. Différences en fonction du sexe et du niveau scolaire-version en ligne

Pour l'ensemble des 449 élèves ayant passé la version en ligne du test de Maîtrise des Concepts Computationnels, la moyenne, après suppression des items vrai/faux, est de 14.6/26 (ET = 6.09). Les moyennes et écarts-types pour la maîtrise des cinq concepts évalués sont les suivantes : algorithme (M = 3.33/6, ET = 1.61), instruction (M = 2.86/4, ET = 1.14), boucle (M = 3.64/7, ET = 2.01), condition (M = 3.33/6, ET = 1.72), variable (M = 1.47/3, ET = 1.05). Les résultats obtenus démontrent un effet significatif fort du niveau scolaire sur les performances au test (F(5, 443) = 27.6, p < .001, η² = .237). Au vu du faible échantillon d'élèves de niveau de 7ᵉ et 8ᵉ année du primaire et de 2ᵉ année du secondaire (respectivement, N = 3, N = 19 et N = 16), nous avons comparé deux à deux les élèves de 1ᵉ, 3ᵉ et 4ᵉ année du secondaire (respectivement, N = 98, N = 183 et N = 130). Le Tableau 3 rend compte des statistiques descriptives relatives au niveau de pratique en programmation et aux performances au test de ces élèves, en fonction de leur niveau scolaire.

La distribution du niveau de pratique en programmation ne suit pas la loi normale, ce qui nous a conduits à utiliser le test non paramétrique de Kruskal-Wallis et à mener des comparaisons post-hoc de Dwass, Steel, Critchlow et Fligner, concernant cette variable. Les élèves de 3ᵉ année présentent un niveau de pratique de la programmation et un niveau de performance significativement plus élevés que les élèves de 1ᵉ année, avec une grande taille d'effet (respectivement, W(280) = 7.77, p < .001 et t(280) = 9.52, p < .001, d = 1.19). De même, le niveau de pratique et les performances des élèves de 4ᵉ année sont plus élevés que ceux des élèves de 1ᵉ année, encore une fois avec une grande taille d'effet (respectivement, W(227) = 10.07, p < .001 et t(227) = 11.13, p < .001, d = 1.49). En revanche, même si les élèves de 4ᵉ année présentent des niveaux de pratique et de performances plus élevés que ceux des élèves de 3ᵉ année, ces différences ne sont pas significatives (respectivement, W (312) = 2.24, p = .61 et t(312) = 2.59, p = .10). Le Tableau 4 rend

<caption>Tableau 3</caption>

Moyennes (et écarts-types entre parenthèses) des scores au questionnaire de niveau de pratique en programmation et au Test de Maîtrise des Concepts Computationnels (version en ligne), selon le niveau scolaire.

<table><caption>Tableau 4</caption><thead><tr><td>Niveau scolaire</td><td>Niveau de pratique en programmation</td><td>Score total-test de Maîtrise des Concepts Computationnels</td></tr></thead><tbody><tr><td>1<sup>e</sup> année (secondaire)</td><td>3.66 (3.78)</td><td>9.33 (4.70)</td></tr><tr><td>3<sup>e</sup> année (secondaire)</td><td>6.75 (4.62)</td><td>15.7 (5.65)</td></tr><tr><td>4<sup>e</sup> année (secondaire)</td><td>7.68 (4.00)</td><td>17.3 (5.16)</td></tr></tbody></table>

Moyennes (et écarts-types entre parenthèses) des scores au questionnaire de niveau de pratique en programmation et au Test de Maîtrise des Concepts Computationnels (version en ligne), selon le sexe.

<table><thead><tr><td>Sexe</td><td>Niveau de pratique en programmation</td><td>Score total-test de Maîtrise des Concepts Computationnels</td></tr></thead><tbody><tr><td>Féminin</td><td>6.16 (4.40)</td><td>15.0 (6.21)</td></tr><tr><td>Masculin</td><td>6.33 (4.58)</td><td>14.2 (5.93)</td></tr></tbody></table>

Les différences observées ici ne sont pas significatives, qu'elles concernent l'impact du sexe sur le niveau de pratique de la programmation, ou sur les performances au test (respectivement, χ² = 0.12, p = .73 et F(1, 447) = 1.78, p = .18).

compte des statistiques descriptives relatives au niveau de pratique en programmation et aux performances au test des élèves, en fonction de leur sexe.

### 3.2.4. Analyse de fiabilité-version papier

La fiabilité globale du test en version papier peut être considérée comme élevée (ω = .826). Le Tableau 5 présente la valeur du coefficient ω si les items correspondants étaient supprimés du test ainsi que le lien de corrélation entre l'item en question et le reste des items, mesuré à l'aide du coefficient r de Pearson.

Comme pour la version en ligne, nous pouvons observer que la fiabilité du test augmente lorsque les items I2, B4, C4 et V2 sont retirés. Cette version papier confirme la nécessité suppression des items vrai/ faux. Ceci a pour conséquence d'augmenter la fiabilité globale de notre test (ω = .85). Pour les concepts d'algorithme, de boucle, de condition et de variable, les mesures de fiabilité sont respectivement de ω = .52, ω = .57, ω = .57 et ω = .58.

### 3.2.5. Validité-version papier

Le niveau de pratique et les performances globales au test sont liés par une corrélation positive d'intensité modérée (r = .54). Concernant les différents concepts dont la maîtrise est mesurée dans ce test, il existe également des liens de corrélations positifs d'intensité modérée avec le niveau de pratique en programmation, bien que ces coefficients soient plus faibles, que ce soit pour le concept d'algorithme (r = .44), d' instruction (r = .36), de boucle (r = .44), de condition (r = .49) ou de variable (r = .40). Toutes ces corrélations sont significatives à p < .001. Par ailleurs, nous avons pu observer que les performances au test varient significativement selon le niveau de pratique en programmation des élèves, avec un effet de grande taille (F(14, 160) = 6.18, p < .001, η² = .351).

### 3.2.6. Différences en fonction du sexe et du niveau scolaire-version papier

Pour l'ensemble des 175 élèves ayant passé la version en ligne du test de Maîtrise des Concepts Computationnels, la moyenne, après suppression des items vrai/faux, est de 14.6/26 (ET = 5.94). Les moyennes et écarts-types pour la maîtrise des cinq concepts évalués sont les suivants : algorithme (M = 3.63/6, ET = 1.58), instruction (M = 2.85/4, ET = 1.11), boucle (M = 3.40/7, ET = 2.06), condition (M = 3.33/6, ET = 1.62), variable (M = 1.37/3, ET = 1.09). Les résultats obtenus indiquent un effet significatif de grande taille du niveau scolaire sur les performances au test (F(2, 172) = 40.1, p < .001, η² = .318). Au vu du

<caption>Tableau 5</caption>

Valeur de ω si l'item correspondant est supprimé et lien de corrélation entre chacun de ces items et les autres items du Test de Maîtrise des Concepts Com- putationnels (version papier).

<table><thead><tr><td>Item</td><td>Valeur de ω si l'item est retiré</td><td>Corrélation item-reste du test</td></tr></thead><tbody><tr><td>I2</td><td>.830</td><td>.11</td></tr><tr><td>B4</td><td>.827</td><td>.19</td></tr><tr><td>C4</td><td>.835</td><td>-.03</td></tr><tr><td>V2</td><td>.832</td><td>.06</td></tr></tbody></table>
faible échantillon d'élèves de 8e année du primaire (N = 8), nous avons comparé deux à deux les élèves de 2e et de 4e année du secondaire (respectivement, N = 100 et N = 67). Le Tableau 6 rend compte des statistiques descriptives relatives au niveau de pratique en programmation et aux performances au test de ces élèves, en fonction de leur niveau scolaire.

La distribution du niveau de pratique en programmation ne suit pas la loi normale, ce qui nous a conduits à utiliser le test non paramétrique de Kruskal-Wallis, concernant cette variable. Les élèves de 4e année présentent un niveau de pratique de la programmation et un niveau de performance significativement plus élevés que les élèves de 2e année, avec un effet de grande taille en ce qui concerne les performances (respectivement $\chi^2 = 15.2, p < .001, \varepsilon^2 = .087$ et $t(166) = 8.45, p < .001, d = 1.33$). Le Tableau 7 rend compte des statistiques descriptives relatives au niveau de pratique en programmation et aux performances au test des élèves, en fonction de leur sexe.

## 4. Test d'algorithmique

Notre deuxième test vise à mesurer la capacité des élèves à mettre en pratique les concepts fondamentaux en programmation (dont nous avons évalué la maîtrise dans notre Test de Maîtrise des Concepts Computationnels) afin de résoudre un problème concret. Les problèmes proposés impliquent nécessairement, pour parvenir à leur résolution, d'user de certaines compétences, souvent associées à la pensée informatique, telles que la pensée algorithmique, l'abstraction, la généralisation, etc. Nous avons nommé ce test : Test d'Algorithmique (Annexe 4). L'objectif est de valider un test en français, relativement court comparé aux autres instruments d'évaluation des connaissances et compétences en pensée informatique ou en programmation. Contrairement à la quasi-totalité des instruments de mesure existants, notre Test d'Algorithmique implique la production d'un algorithme (écrit en langage naturel) pour résoudre les problèmes posés et ne repose donc pas sur des questions à choix multiples. De même, nous avons fait le choix de concevoir un test proposant des problèmes de programmation et non des problèmes de la vie quotidienne, ou a minima non reliés à des activités de programmation, et dont la résolution est censée être révélatrice de certaines compétences en pensée informatique, comme c'est très souvent le cas dans ce domaine.

### 4.1. Méthode

#### 4.1.1. Participants

La validation de ce Test d'Algorithmique a mené au recrutement de 180 participants (85 filles) dont 131 élèves en 2e année du secondaire (12 ans) et 49 en 4e année du secondaire (14 ans). Nous avons bénéficié du réseau de la DRANE de l'Académie de Montpellier pour recruter des classes de différents niveaux dans cette région.

#### 4.1.2. Matériel

Nous avons utilisé le même questionnaire visant à évaluer le niveau de pratique de la programmation des élèves que celui décrit dans la partie « Méthode–Matériel » du Test de Maîtrise des Concepts computationnels avec le même objectif : permettre de mesurer un lien de

<caption>Tableau 6</caption>

Moyennes (et écarts-types entre parenthèses) des scores au questionnaire de niveau de pratique en programmation et au Test de Maîtrise des Concepts Computationnels (version papier), selon le niveau scolaire.

<table><caption>Tableau 7</caption><thead><tr><td>Niveau scolaire</td><td>Niveau de pratique en programmation</td><td>Score total-test de Maîtrise des Concepts Computationnels</td></tr></thead><tbody><tr><td>2e année (secondaire)</td><td>6.27 (3.45)</td><td>12.2 (5.09)</td></tr><tr><td>4e année (secondaire)</td><td>7.48 (2.79)</td><td>18.8 (4.86)</td></tr></tbody></table>

Moyennes (et écarts-types entre parenthèses) des scores au questionnaire de niveau de pratique en programmation et au Test de Maîtrise des Concepts Computationnels (version papier), selon le sexe.

<table><thead><tr><td>Sexe</td><td>Niveau de pratique en programmation</td><td>Score total-test de Maîtrise des Concepts Computationnels</td></tr></thead><tbody><tr><td>Féminin</td><td>6.74 (3.07)</td><td>15.3 (5.87)</td></tr><tr><td>Masculin</td><td>6.58 (3.34)</td><td>13.9 (5.96)</td></tr></tbody></table>

Les différences observées ici ne sont pas significatives, qu'elles concernent l'impact du sexe sur le niveau de pratique de la programmation, ou sur les performances au test (respectivement, $\chi^2 = 0.17, p = .68$ et $F(1, 173) = 2.41, p = .12$).

corrélation entre ce niveau de pratique de la programmation et les performances des élèves au Test d'Algorithmique (Annexe 2). En se référant toujours à la taxonomie révisée de Bloom (Krathwohl, 2002), ce nouvel instrument de mesure propose cette fois-ci de tester principalement les connaissances procédurales des élèves, c'est-à-dire des connaissances relatives à comment faire quelque chose (ici, produire un algorithme pour résoudre un problème). Par ailleurs, on peut également considérer que des connaissances métacognitives peuvent être mises en jeu, en particulier les connaissances stratégiques qui permettent de résoudre des problèmes de programmation. De plus, notre test est pensé pour évaluer notamment le processus cognitif le plus complexe, selon la taxonomie révisée de Bloom (Krathwohl, 2002), qui est la capacité à créer, c'est-à-dire à assembler des éléments pour former un ensemble nouveau et cohérent ou à réaliser un produit original. Cette dimension se décompose en trois sous-dimensions essentielles dans le processus de conception d'un algorithme : « générer », « planifier » et « produire ». Le processus d'évaluation (« évaluer »), décrit par cette même taxonomie, est également une dimension du processus cognitifs impliquée dans la réalisation de ce test. Il consiste à porter un jugement sur la base de critères et de normes et se décompose en deux sous-dimensions : « vérifier » et « critiquer ». L'évaluation et la vérification de la pertinence des instructions utilisées font partie du processus naturel de la conception d'un algorithme.

Cependant, les tâches de résolution de problèmes que nous proposons ici reposent sur l'utilisation d'un ensemble d'instructions prédéterminées et les solutions possibles à un problème donné sont multiples mais peu nombreuses et fondamentalement assez similaires. Nous ne proposons donc pas de problèmes mal définis ou mal structurés (« ill-structured problems ») qui, par définition, n'ont pas de solution claire et unique et nécessitent des processus cognitifs plus complexes pour être résolus (Jonassen, 1997). Ainsi, même si notre Test d'Algorithmique implique la capacité à créer, telle que définie par la taxonomie révisée de Bloom (Krathwohl, 2002), celui-ci ne permet pas actuellement de solliciter les processus cognitifs de résolution de problèmes les plus complexes, ce qui est finalement conforme au public que nous visons qui reste assez jeune.

Nous avons ainsi conçu trois exercices pratiques, nécessitant la création de quatre algorithmes différents comme solutions aux problèmes décrits. En introduction, un personnage de robot est présenté (nommé « BOT »). Il est expliqué que ce robot comprend le français et peut être programmé pour réaliser certaines tâches à condition de lui donner des instructions claires et précises. Deux exemples d'algorithme, permettant à « BOT » de se déplacer sur une grille, sont fournis aux élèves pour les aider à comprendre comment ils doivent écrire leur algorithme. Le langage utilisé est un langage naturel (en français). Nous avons fourni aux élèves une liste d'instructions compréhensibles par le robot. Ainsi, les élèves ne sont pas censés produire eux-mêmes leurs instructions, mais simplement utiliser les instructions pertinentes, parmi une sélection.

L'exercice 1 demande aux élèves de produire deux algorithmes distincts qui doivent permettre à « BOT » de rejoindre sa maison en suivant un parcours représenté sur une grille, tout en évitant les obstacles qui
l'empêchent de passer. Le premier impose pour consigne de choisir le chemin le plus court (c'est-à-dire nécessitant de traverser le moins de cases que possible). Le second implique de produire un algorithme composé du moins d'instructions que possible pour aboutir à ce résultat. La consigne pour ce deuxième algorithme suggérait aux élèves d'utiliser une ou plusieurs boucles pour répéter certaines instructions. La capacité à choisir la meilleure solution parmi celles qui étaient possible (ici, celle qui correspond à la consigne donnée), souvent associée à la maîtrise de la pensée informatique, est ici évaluée. L'exercice 1 est illustré par la Fig. 3.

L'exercice 2 demande également aux élèves de produire un algorithme permettant à « BOT » de rejoindre sa maison, mais cette fois-ci, ils doivent uniquement réutiliser des instructions issues de deux algorithmes incorrects (proposés par deux élèves fictifs), ne prenant pas en compte les obstacles sur le chemin. Enfin, l'exercice 3 demande aux élèves, à partir d'un algorithme proposé par un élève fictif permettant à « BOT » de compter jusqu'à 5, de généraliser cet algorithme pour permettre à ce robot de compter indéfiniment les secondes qui passent, puis les minutes, en utilisant des variables.

Dans chaque exercice, la capacité à formuler une réponse sous forme d'algorithme, composé d'instructions pertinentes pour la résolution du problème, valait 1 point. Lorsque des mouvements devaient être programmés pour compléter un chemin, la capacité à programmer correctement ce chemin permettait l'obtention d'1 point supplémentaire. Lorsque l'utilisation d'une boucle ou d'une condition était requise, 1 point était attribué pour la capacité à utiliser correctement les boucles et les conditions pour obtenir le résultat requis. La capacité à utiliser correctement une variable dans l'exercice 3 permettait également l'obtention d'1 point. Dans l'exercice 1, la capacité à choisir le chemin correct et la capacité à produire un algorithme composé du moins d'instruction possible rapportaient chacune 1 point. Dans l'exercice 2, la capacité à n'utiliser que les instructions issues des deux algorithmes incorrects était également évaluée sur 1 point. Enfin, dans l'exercice 3, la capacité à généraliser l'algorithme permettant de compter les secondes pour compter cette fois-ci les minutes rapportait également 1 point.

Pour ce Test d'Algorithmique, nous avons tenté de mesurer

directement certaines compétences généralement associées à la pensée informatique (évaluation, réutilisation, généralisation), en plus d'évaluer la capacité des élèves à mettre en pratique les concepts computationnels fondamentaux pour résoudre des problèmes algorithmiques. Les items peuvent être regroupés en quatre catégories différentes correspondant à la fois à l'utilisation pratique des concepts computationnels et à certaines compétences associées à la pensée informatique : la capacité à produire des algorithmes composés d'instructions pertinentes (quatre items, 4 points), la capacité à produire un algorithme qui constitue une solution correcte permettant au robot d'atteindre sa maison (trois items, 3 points), la capacité à évaluer différentes solutions pour sélectionner et mettre en œuvre celle qui est demandée (deux items, 2 points), la capacité à utiliser des boucles (deux items, 2 points), des instructions conditionnelles (deux items, 2 points) et des variables (un item, 1 point), la capacité à réutiliser des éléments de solution déjà fournis (un item, 1 point) et la capacité à généraliser un élément de solution à un autre problème similaire (un item, 1 point). Ce test est conçu pour évaluer une performance (sur 16 points). Ainsi, les résultats totaux ont été pris en compte même si certains items sont restés sans réponse.

### 4.1.3. Procédure

Avant de passer le test, les élèves devaient tout d'abord remplir le questionnaire évaluant leur niveau de pratique en programmation. Les professeurs qui ont fait passer ce test à leurs élèves ont été informés que ceux-ci devaient travailler seuls et ne pouvaient bénéficier de leur aide, à l'exception de certaines précisions ponctuelles qui pouvaient être apportées concernant le vocabulaire employé ou la formulation des questions, lorsque celles-ci étaient jugées nécessaires. Si aucune limite de temps n'a été imposée, nous avons cependant demandé à ce que le test soit réalisé dans son intégralité durant une seule et même heure de cours et avons précisé qu'une demi-heure était suffisante pour la passation. L'ensemble des questionnaires était anonymisé.

## Exercice 1 : Plusieurs chemins

BOT doit rejoindre sa maison en évitant les obstacles (STOP) qui l'empêchent de passer.
Il y a plusieurs chemins possibles.

<figure><img src="image_6.png" /></figure>

Ecris l'algorithme qui permet à BOT d'atteindre l'arrivée par le chemin le plus court, c'est-à-dire en passant par le moins de cases possible (Algorithme 1).

Puis, écris l'algorithme qui permet à BOT d'atteindre l'arrivée avec le moins d'instructions possibles (le moins de lignes dans l'algorithme). Tu dois utiliser au moins une boucle (« Répéter ») pour répéter certaines instructions (Algorithme 2).

<caption>Fig. 3. Exercice 1 du Test d'Algorithmique.</caption>
## 4.2. Résultats

Comme pour le Test de Maîtrise des Concepts Computationnels, nous avons mesuré un indice de fiabilité et un indice de validité de cette deuxième version, ainsi que le nombre et la proportion d'élèves ayant a minima essayé de produire un algorithme, à chaque fois que cette tâche était demandée. L'impact du niveau scolaire et du sexe des élèves sur leur niveau de pratique et leurs performances au test a également été mesuré. Les analyses que nous avons menées ont été réalisées sur le logiciel Jamovi, version 2.3.26.0.

### 4.2.1. Analyse de fiabilité

La fiabilité globale du test peut être considérée comme élevée (ω = .852). Un item, nommé Eval2 relatif à la capacité des élèves à évaluer quelle solution parmi toutes celles qui sont possibles correspond à celle demandée par la consigne, produirait une augmentation de la fiabilité globale du test, s'il était supprimé (ω = .857). Nous avons mesuré les indices de fiabilité concernant chaque sous-catégorie d'items, lorsque cette sous-catégorie comprenait au moins deux items. La capacité à produire des algorithmes composés d'instructions pertinentes (ω = .71), la capacité à produire un algorithme correct permettant au robot d'atteindre sa maison (ω = .68) ainsi que la capacité à produire des boucles (ω = .71) et des instructions conditionnelles (ω = .60) présentent des indices de fiabilité acceptables, au vu du très faible nombre d'items qui les compose (deux à quatre items).

Cependant, la capacité à évaluer correctement différentes solutions et à sélectionner la plus adaptée (composée de deux items, nommés Eval1 et Eval2) présente un indice de fiabilité anormalement faible (ω = .28). Ce résultat peut cependant s'expliquer. Le premier item de cette sous-catégorie demande aux élèves de choisir le chemin permettant au robot d'atteindre son objectif en passant par le moins de cases que possible. Cet item est assez facilement réussi par les élèves (il n'y a que deux chemins qui permettent d'atteindre l'objectif directement sans déplacements inutiles). Le deuxième item leur demande de produire un algorithme permettant également au robot d'atteindre son objectif, mais cette fois-ci, avec le moins d'instructions que possible (ce qui implique l'utilisation d'une boucle pour répéter certaines instructions). Ainsi, ce deuxième item suppose que les élèves doivent réussir à repérer un chemin plus long (en termes de distance, qui est représentée par le nombre de cases), mais qui peut être programmé en moins d'instructions, car une portion de ce trajet se répète trois fois. Cet item est donc nettement plus complexe que le premier et implique à la fois une capacité d'évaluation, mais également des capacités procédurales de mise en œuvre de cette solution. Il nous semble donc logique que la fiabilité liée à ces deux items ne soit pas très élevée. Ce résultat est à prendre en considération, car il traduit l'incapacité de ce deuxième item à évaluer une seule capacité. Cependant, nous pensons que, de par sa complexité, il est utile pour discriminer différents niveaux de performance chez les élèves et ne doit pas nécessairement être supprimé du test.

### 4.2.2. Validité

Le niveau de pratique et les performances globales au test sont liés par une corrélation positive d'intensité assez forte (r = .67). Concernant les différentes capacités qui sont évaluées dans ce test, il existe également des liens de corrélations positifs d'intensité plus modérée avec le niveau de pratique en programmation, bien que ces coefficients soient plus faibles, que ce soit pour la capacité à produire des algorithmes composés d'instructions pertinentes (r = .54), la capacité à produire un algorithme qui constitue une solution correcte permettant au robot d'atteindre sa maison (r = .56), la capacité à évaluer différentes solutions pour sélectionner et mettre en œuvre celle qui est demandée (r = .49), la capacité à utiliser des boucles (r = .54), des instructions conditionnelles (r = .53) et des variables (r = .38), la capacité à réutiliser des éléments de solution déjà fournis (r = .24) et la capacité à généraliser un élément de solution à un autre problème similaire (r = .37). Toutes

ces corrélations sont significatives à *p* < .001. Le niveau de pratique de la programmation est également différemment corrélatif suivant l'algorithme que les élèves devaient produire (algorithme 1, *r* = .61 ; algorithme 2, *r* = .51 ; algorithme 3, *r* = .52 ; algorithme 4, *r* = .71). Par ailleurs, nous avons pu observer que les performances au test varient significativement selon le niveau de pratique en programmation des élèves, avec un effet de grande taille (F(13, 166) = 12.7, *p* < .001, η² = .498).

### 4.2.3. Taux de complétion par algorithme

Tous les élèves recrutés ont essayé de produire au moins un des quatre algorithmes demandés. Cependant, tous n'ont pas terminé le test. Sur les 180 élèves, 179 ont produit le premier algorithme (99.4 %), 170 le deuxième (94.4 %), 155 le troisième (86.1 %) et seulement 63 le quatrième (35.0 %). Par conséquent, le quatrième algorithme n'a pas été produit par la majorité des élèves.

### 4.2.4. Différences en fonction du sexe et du niveau scolaire

Pour l'ensemble des 180 élèves ayant passé ce Test d'Algorithmique, la moyenne est de 7.70/16 (ET = 3.45). Les moyennes et écarts-types pour les sous-variables mesurées sont les suivants : capacité à produire des algorithmes composés d'instructions pertinentes (M = 2.79/4, ET = 0.91), capacité à produire un algorithme qui constitue une solution correcte permettant au robot d'atteindre sa maison (M = 1.93/3, ET = 1.07), capacité à évaluer différentes solutions pour sélectionner et mettre en œuvre celle qui est demandée (M = 1.02/2, ET = 0.57), capacité à utiliser des boucles (M = 0.68/2, ET = 0.59), des instructions conditionnelles (M = 0.38/2, ET = 0.56) et des variables (M = .09/1, ET = .28), la capacité à réutiliser des éléments de solution déjà fournis (M = .67/1, ET = .46) et la capacité à généraliser un élément de solution à un autre problème similaire (M = .11/1, ET = .31). Le Tableau 8 rend compte des statistiques descriptives relatives au niveau de pratique en programmation et aux performances au test de ces élèves, en fonction de leur niveau scolaire.

Le niveau de pratique de la programmation ne suit pas une distribution normale, ce qui nous a conduits à utiliser le test non paramétrique de Kruskal-Wallis. Les élèves de 4ᵉ année présentent un niveau de pratique de la programmation et un niveau de performance significativement plus élevés que les élèves de 2ᵉ année (respectivement, χ² = 15.9, *p* < .001, ε² = .089 et t(178) = 2.09, *p* < .05, *d* = 0.35). Le Tableau 9 rend compte des statistiques descriptives relatives au niveau de pratique en programmation et aux performances au test des élèves, en fonction de leur sexe.

## 5. Discussion

Afin de pouvoir mesurer les performances d'apprentissage des élèves dans un contexte d'enseignement de la programmation/de la pensée informatique, nous avons réalisé une revue des instruments d'évaluation existants. Cependant, nous avons considéré que ces instruments présentaient certaines limites et n'étaient pas suffisamment adaptés à ce contexte. Pour cette raison, nous avons conçu deux instruments supplémentaires permettant d'évaluer les connaissances et compétences à acquérir dans cette discipline. Nos instruments de mesure constituent

<caption>Tableau 8</caption>

Moyennes (et écarts-types entre parenthèses) des scores au questionnaire de niveau de pratique en programmation et au Test d'Algorithmique, selon le niveau scolaire.

<table><thead><tr><td>Niveau scolaire</td><td>Niveau de pratique en programmation</td><td>Score total-Test d'Algorithmique</td></tr></thead><tbody><tr><td>2ᵉ année (secondaire)</td><td>6.79 (3.53)</td><td>7.37 (3.21)</td></tr><tr><td>4ᵉ année (secondaire)</td><td>8.94 (3.15)</td><td>8.57 (3.91)</td></tr></tbody></table>
<caption>**Tableau 9**</caption>

Moyennes (et écarts-types entre parenthèses) des scores au questionnaire de niveau de pratique en programmation et au Test d'Algorithmique, selon le sexe.

<table><thead><tr><td>Sexe</td><td>Niveau de pratique en programmation</td><td>Score total-Test d'Algorithmique</td></tr></thead><tbody><tr><td>F</td><td>7.21 (3.51)</td><td>7.46 (3.56)</td></tr><tr><td>M</td><td>7.53 (3.61)</td><td>7.92 (3.35)</td></tr></tbody></table>

Les différences observées ici ne sont pas significatives, qu'elles concernent l'impact du sexe sur le niveau de pratique de la programmation, ou sur les performances au test (respectivement, $\chi^2 = 0.54$, $p = .46$ et $t(178) = 0.89$, $p = .38$).

des instruments d'évaluation sommative qui mesurent la maîtrise de concepts computationnels et incluent également des tâches de résolution de problèmes algorithmiques, relatifs à des activités de programmation. En ce sens, ils se rapprochent donc d'autres instruments tels que le Computational Thinking Test (Román-González, 2015).

Nous avons entrepris une démarche de validation psychométrique de nos nouveaux instruments d'évaluation. Pour ce faire, nous avons mesuré un indice de validité, fondé sur un coefficient de corrélation entre le niveau de pratique en programmation (évalué par un questionnaire de notre conception) et les performances à nos tests. Cette manière de procéder avait déjà été employée par Li et al. (2021), bien que leur questionnaire ne comportait que deux questions fermées relatives à la programmation (avec seulement deux réponses possibles, « oui » ou « non »). Nous avons également mesuré un indice de fiabilité interne à l'aide du coefficient $\omega$ de McDonald.

## 5.1. Test de maîtrise des concepts computationnels

Nous avons conçu le Test de Maîtrise des Concepts Computationnels, constitué de questions à choix multiples, évaluant la maîtrise de certains concepts fondamentaux en programmation, identifiés par Tchounikine (2017), et similaires à ceux décrits par Brennan et Resnick (2012), à savoir les concepts d'algorithme, d'instruction, de boucle, d'instruction conditionnelle et de variable. Une version en ligne et une version papier ont été proposées. L'analyse des résultats obtenus pour ces deux versions révèle un manque de fiabilité de la plupart des items de type vrai/faux, que nous avons donc choisi de supprimer des versions définitives du test.

Pour les deux versions, la fiabilité interne globale du test est satisfaisante et élevée ce qui signifie que l'ensemble du test évalue bien un seul et même construit, à savoir la maîtrise des concepts computationnels fondamentaux en programmation. La fiabilité interne relative aux différentes sous-catégories d'items est modérée, ce qui peut parfois être considéré comme trop faible selon les auteurs, mais ce résultat s'explique par le très petit nombre d'items qui constitue chaque sous-catégorie (Taber, 2018).

Il existe par ailleurs, dans les deux versions, une corrélation modérée entre le niveau de pratique de la programmation des élèves et leurs performances à ce Test de Maîtrise des Concepts Computationnels. Des corrélations modérées, bien que plus faibles, existent également entre le niveau de pratique et les performances relatives aux différentes sous-catégories d'items (maîtrise du concept d'algorithme, d'instruction, de boucle, etc.). Ceci est un indice satisfaisant de la validité de notre test, car il est logique de penser que la maîtrise de ces concepts est globalement plus élevée lorsque le niveau de pratique de la programmation augmente. On pourrait cependant s'interroger sur l'absence de lien de corrélation fort entre ces deux variables. Nous pensons toutefois qu'il serait trop optimiste de s'attendre à un lien de cette intensité. En effet, le niveau de pratique de la programmation est autoévalué par les élèves, ce qui a certainement pu mener à des approximations ou à des erreurs. De plus, suivant le contexte dans lequel les élèves ont pratiqué la programmation (à l'école ou ailleurs) et l'objectif pour lequel ils se sont engagés dans cette pratique, il n'est pas évident que le nombre d'heures passées à programmer, la fréquence des activités de programmation, etc., devraient être parfaitement reliés à la maîtrise des concepts en

question. Enfin, le Test de Maîtrise des Concepts Computationnels étant composé de questions à choix multiples, il est probable que certains élèves ayant un faible niveau réel de maîtrise des concepts computationnels aient pu, ponctuellement, répondre correctement à certains items, soit par hasard, soit par déduction au vu des autres réponses proposées. En outre, nous avons constaté des différences significatives et des effets de grande taille concernant les performances à notre test, selon le niveau de pratique de la programmation, en faveur des élèves ayant les niveaux de pratique les plus élevés, ce qui constitue également un indice de validité.

Nous avons toutefois observé que le coefficient de corrélation entre le niveau de pratique de la programmation et les performances au test est légèrement plus élevé dans la version en ligne du test, par rapport à la version papier. Ceci s'explique probablement par la taille et la variété de l'échantillon recruté pour la version en ligne, plus de deux fois supérieure à celle de l'échantillon pour la version papier et impliquant des élèves issus de toutes les classes de la 7ᵉ année du primaire jusqu'à la 4ᵉ année du secondaire. Pour les deux versions, le niveau scolaire influence significativement à la fois le niveau de pratique en programmation et les performances au test. Ceci est plutôt cohérent, puisque plus le niveau scolaire augmente, plus les élèves ont eu le temps de pratiquer des activités de programmation, ce qui pourrait confirmer que notre questionnaire évaluant le niveau de pratique en programmation est suffisamment bien construit. De même, nous savons que l'âge des élèves est positivement corrélaté au niveau de compréhension et de compétence liée à la pensée informatique (Zhang & Nouri, 2019).

Les Tableaux 3 et 8 témoignent bien d'une augmentation du niveau de pratique de la programmation associée à l'augmentation du niveau scolaire. Cependant, l'enseignement de la programmation dans les classes françaises n'est certainement pas uniforme et peut varier selon les établissements ou les enseignants. Ainsi, un élève plus âgé (ou d'un niveau scolaire supérieur) n'est pas nécessairement plus expérimenté qu'un élève plus jeune (ou d'un niveau scolaire inférieur). Dans l'ensemble, on peut toutefois supposer que plus le niveau scolaire augmente, plus les élèves ont pu être exposés à l'enseignement de la programmation, ce que nos résultats semblent confirmer. Cependant, pour la version en ligne du test, on observe que les différences entre les élèves de 3ᵉ et 4ᵉ année du secondaire, en faveur de ces derniers, ne sont pas significatives. Il est possible qu'entre deux niveaux scolaires proches, les différences soient trop faibles pour que notre questionnaire de pratique de la programmation et notre Test de Maîtrise des Concepts Computationnels puissent les détecter. Enfin, aucun effet du sexe sur ces deux variables n'a été observé.

Les indices de fiabilité et de validité nous incitent à penser que notre test mesure bien la maîtrise de nos cinq concepts computationnels. Certaines limites sont cependant à noter. En particulier, après la suppression des items vrai/faux, il ne subsiste qu'un seul item évaluant la maîtrise du concept d'instruction (sur 4 points). Ceci est probablement dû au fait que ce concept est finalement le plus simple : une instruction est un ordre à exécuter. Aucun item d'application ne nous a semblé pertinent pour évaluer ce concept. De même, demander aux élèves de reconnaître une instruction dans un programme pourrait s'avérer source de confusion, puisque d'autres concepts (boucles, instructions conditionnelles) sont également des instructions. Nous aurions cependant pu ajouter un item « texte à trous » relatif à ce concept. D'une manière générale, d'autres types d'items auraient pu être exploités. La taxonomie révisée de Bloom (Krathwohl, 2002) suggère par exemple d'évaluer la capacité des élèves à produire des inférences, des explications ou encore des interprétations pour permettre de mesurer leur niveau de compréhension. Cependant, ce type d'items se prête moins bien à des questions à choix multiples et notre volonté de proposer un test rapide et simple à mettre en œuvre nous a conduits à écarter ces options.

## 5.2. Test d'algorithmique

Nous avons également conçu un Test d'Algorithmique visant à
évaluer la capacité des élèves à résoudre des problèmes algorithmiques, c'est-à-dire des problèmes dont la solution peut être présentée sous la forme d'un algorithme. Ce test consistait à mesurer plus précisément la capacité des élèves à mettre en pratique les différents concepts computationnels (algorithme, instruction, boucle, instruction conditionnelle, variable) pour résoudre les problèmes posés. Ces problèmes impliquaient également l'utilisation de certaines compétences et stratégies régulièrement associées à la pensée informatique (pensée algorithmique, décomposition, abstraction, généralisation...), mais celles-ci n'étaient pas nécessairement évaluées directement, en raison de la difficulté d'isoler chacune de ces compétences dans un item précis. Pour produire leurs algorithmes, les élèves utilisaient un langage naturel (en français) en piochant parmi une liste d'instructions disponibles.

Tous les élèves recrutés ont essayé de produire au moins un algorithme et seul l'exercice 3 présente des faiblesses au niveau du taux de complétation. Celui-ci nécessitait l'utilisation de variables, et de nombreux élèves ont indiqué sur leur feuille qu'ils ne comprenait pas ce qu'était une variable. Ainsi, même si la notion de variable informatique fait partie des attendus de fin du cycle 4 en France, nous avons pu constater que ce concept était finalement rarement abordé, y compris en 4ᵉ année du secondaire. Ce résultat témoigne finalement de la difficulté à proposer un test qui implique la connaissance et la maîtrise de certains concepts, car la réalisation du test dépend de la manière dont la programmation est enseignée, qui n'est certainement pas identique entre toutes les écoles et tous les collèges francophones. Les concepts que nous avons identifiés comme fondamentaux en programmation ne sont pas systématiquement enseignés dès l'école élémentaire, ni même au début du secondaire. Ainsi, il semble difficile de proposer un test qui s'adresse à un niveau scolaire spécifique, tant il existe des disparités importantes en termes de concepts abordés et de temps d'exposition à l'enseignement de la programmation entre des élèves de même niveau scolaire.

Le Test d'Algorithmique présente un niveau global de fiabilité interne élevé. La fiabilité associée aux sous-catégories d'items est logiquement plus faible, au vu du petit nombre d'items qui les compose. La fiabilité des deux items liés à la mesure de la capacité d'évaluation des élèves est excessivement faible, mais s'explique par la difficulté d'évaluer cette compétence de manière isolée, sans impliquer d'autres compétences.

Les liens de corrélation que nous avons mesurés entre le niveau de pratique de la programmation et les performances au Test d'Algorithmique sont significatifs, d'intensité assez forte ce qui témoigne de la validité de notre test. En revanche, pour les sous-catégories d'items relatives à la mesure des compétences associées à la pensée informatique, les liens de corrélations avec le niveau de pratique en programmation sont plus faibles et renforcent l'idée que ces compétences sont finalement relativement indépendantes des activités de programmation, ce qui est généralement admis par la plupart des chercheurs dans ce domaine. En outre, le lien de corrélation le plus important, parmi les différentes sous-catégories d'items qui composent notre Test d'Algorithmique, est celui qui met en relation le niveau de pratique et la capacité à produire un algorithme correct pour permettre à « BOT » d'atteindre sa maison. La pratique de la programmation semble donc, avant tout, permettre de résoudre efficacement un problème concret. Des liens de corrélation forts sont également observés entre le niveau de pratique et les performances à l'exercice le plus complexe du test (exercice 3), ce qui signifie que cet exercice est tout de même pertinent pour permettre une distinction entre différents niveaux d'expertise. Enfin, les analyses de variance mettent en lumière des différences significatives entre les performances des élèves au test, selon leur niveau de pratique de la programmation, en faveur des élèves ayant le plus pratiqué. Le niveau scolaire des élèves a également un effet significatif sur leurs performances. Comme pour le Test de Maîtrise des Concepts Computationnels, aucune différence n'est observée entre les garçons et les filles concernant leurs performances ou leur niveau de pratique de la programmation.

### 5.3. Limites et perspectives

Il serait prématuré de penser que le travail de conception et de validation de nos deux tests est terminé. Nous avons mis en lumière certaines faiblesses qu'il serait souhaitable de corriger. En termes de généralisation tout d'abord, le dernier exercice du Test d'Algorithmique présentait des limites, en raison de la nécessité d'utiliser des variables, inconnues de la majorité de notre échantillon. De même, alors que pour le Test de Maîtrise des Concepts Computationnels plus de 600 élèves ont été recrutés, le Test d'Algorithmique n'a été soumis qu'à un peu moins de 200 élèves. Un échantillon plus large aurait pu confirmer davantage nos observations, même si, au vu des analyses que nous avons réalisées (fiabilité interne et coefficient de corrélation), un plus grand nombre de participants n'était pas forcément indispensable. En effet, l'ensemble des corrélations que nous avons mesurées étaient déjà significatives à *p* < .001. Enfin, nous avons pu observer qu'il était particulièrement difficile d'isoler certaines compétences associées à la pensée informatique pour les évaluer indépendamment de autres compétences ou connaissances. La définition de la pensée informatique, selon Tchounikine (2017), rend palpables les liens qu'entretiennent ces compétences : « savoir décomposer un problème en sous-problèmes plus simples ; savoir réfléchir aux tâches à accomplir pour résoudre un problème en termes d'étapes et d'actions ; savoir décrire les problèmes et les solutions à différents niveaux d'abstraction, ce qui permet d'identifier des similitudes entre problèmes et, par la suite, de pouvoir réutiliser des éléments de solution » (p. 11). Abstraction, reconnaissance de formes ou de patterns, réutilisation et généralisation semblent presque indissociables. On peut également considérer que la pensée algorithmique et la décomposition sont deux compétences proches, car produire un algorithme implique déjà de décomposer un mouvement ou une fonction en une série d'étapes simples. Çakiroglu et Çevik (2022) estiment par ailleurs que la capacité d'abstraction est impossible à dissocier de la décomposition, de la généralisation ou de la reconnaissance de formes et que ces dernières ne sont que des sous-composantes de l'abstraction, qui constituerait ainsi le cœur de la pensée informatique, ce que Grover et Pea (2013) ainsi que Wing (2008) avaient déjà avancé précédemment.

En outre, il serait pertinent d'essayer d'optimiser nos tests par des analyses complémentaires. Premièrement, nous pourrions à l'avenir proposer une plus grande réserve d'items que nous soumettrions à un jury d'experts, chargé d'évaluer la pertinence et la difficulté des items, ainsi que la longueur globale du test, selon le niveau des élèves. Ceci nous permettrait d'affiner la sélection de nos items afin de ne conserver que les plus appropriés pour nos objectifs d'évaluation. En termes de fiabilité, les mesures « test-retest », qui évaluent la cohérence entre deux mesures distinctes, séparées par un intervalle de temps (Polit, 2014), permettraient de s'assurer qu'en l'absence d'intervention relative à l'apprentissage de la programmation et de la pensée informatique, les performances des élèves restent approximativement constantes dans le temps.

La validité de nos tests pourrait également être mesurée par des liens de corrélation éventuels avec d'autres tests, évaluant des connaissances et compétences proches des nôtres (par exemple, le Computational Thinking Test, évoqué précédemment). Enfin, les analyses factorielles exploratoires ou confirmatoires sont généralement indiquées pour confirmer la validité d'un instrument de mesure. Elles permettent de révéler les facteurs latents (e.g., les différents concepts qui sont évalués), à travers le regroupement de certains facteurs observés (e.g., les items d'un questionnaire), afin d'établir le nombre et la nature des facteurs qui expliquent la variation et la covariation d'un ensemble de données (Brown & Moore, 2012). Celles-ci semblent toutefois difficiles à appliquer à nos deux tests, au vu des chevauchements qui existent entre les facteurs que nous mesurons et ce, y compris pour le Test de Maîtrise des Concepts Computationnels. En effet, pour évaluer la maîtrise d'un concept, nous proposons une assez grande variété de types d'items différents (catégorisation, application, reconnaissance, textes à trous) ce qui crée ainsi un chevauchement entre le concept dont la maîtrise est
évaluée et le processus d'évaluation de ce concept.

## 6. Conclusion

Malgré certaines limites que nous avons pu identifier dans notre discussion, les deux tests que nous avons conçus présentent des indices de fiabilité et de validité suffisants pour être exploitables en contexte scolaire. Nous les mettons donc à disposition de la communauté des enseignants et des chercheurs afin d'évaluer les performances d'apprentissage des élèves relatives à un enseignement de la programmation et de la pensée informatique. Les deux instruments que nous avons conçus, le Test de Maîtrise des Concepts Computationnels et le Test d'Algorithmique, sont complémentaires et permettent d'évaluer à la fois la connaissance et la compréhension des concepts fondamentaux en programmation, ainsi que la capacité des élèves à mettre en pratique ces concepts pour résoudre des problèmes algorithmiques. Ces tests se dis-tinguent des échelles autoévaluatives plus subjectives, des outils d'analyses automatiques du code produit par les élèves et des évaluations réalisées en temps réel pendant le processus d'apprentissage. Ils sont ainsi à ranger parmi les différents instruments qui tentent d'évaluer la maîtrise de la pensée informatique par le biais d'activités de résolution de problèmes, avec cependant quelques différences majeures. Nos tests évaluent la pensée informatique en direct avec les activités de programmation, ce qui n'est pas toujours le cas dans ce domaine. En effet, un grand nombre d'instruments de mesure de la pensée informatique, validés et publiés, est essentiellement constitué de problèmes indépendants de toute activité de pro-grammation. Pour nous, ces instruments ne peuvent être utilisés comme moyens d'évaluer les apprentissages en programmation, sauf pour mesurer l'effet de transfert, c'est-à-dire la capacité à appliquer ce qui a été appris dans un autre contexte, plus ou moins différent. Cet effet de transfert demeure cependant incertain (Denning et al., 2017).

Nos tests ont également été validés en français, auprès d'élèves issus du système éducatif français et, même s'ils sont passés consécutivement, ne devraient pas excéder une heure de passation, ce qui les rend donc particulièrement adaptés pour être mobilisés dans les classes franco-phones, dans lesquelles le temps d'apprentissage de l'informatique n'excède généralement pas une heure consécutive. De plus, notre approche a consisté à valider et à utiliser nos tests quasi exclusivement en contexte écologique, ce qui est un atout précieux au vu des conclu-sions d'une récente revue de littérature sur l'évaluation de la pensée informatique (Han, 2023), mettant en évidence une majorité d'articles dans le domaine ayant mesuré les compétences en pensée informatique dans un contexte de recherche, plutôt que dans un contexte pédagogique authentique. Notre contribution majeure consiste également en la tentative de proposer un test pour lequel les élèves devaient produire eux-mêmes un algorithme comme solution à un problème, ce qui n'a été envisagé qu'une seule fois à notre connaissance (Chen et al., 2017), et ce, d'une manière qui exigeait la maîtrise d'une syntaxe spécifique. Nous avons également veillé à ce que nos deux tests couvrent une large partie des objectifs éducatifs, comme défini par la taxonomie révisée de Bloom (Krathwohl, 2002), en évaluant principalement les connaissances fac-tuelles, conceptuelles et procédurales des élèves, ainsi que leur capacité à se remémorer, comprendre, analyser et appliquer les concepts com-putationnels dans l'optique de créer et d'évaluer des algorithmes per-mettant de résoudre des problèmes.

## Déclaration de liens d’intérêts

Les auteurs déclarent ne pas avoir de liens d'intérêts.

## Remerciements

Cette recherche a été réalisée dans le cadre d'une thèse soutenue et financée par la Délégation Régionale Académique au Numérique Edu-catif (DRANE) de l'Académie de Montpellier, France. Nous tenons à

remercier tous les enseignants qui ont participé à la conception et à la mise en œuvre des séances en classe.

## Annexes 1-4 Matériel complémentaire

Le matériel complémentaire accompagnant la version en ligne de cet article est disponible sur http://www.sciencedirect.com et https://doi.org/10.1016/j.erap.2025.101116.

## Références

Aho, A. V. (2012). *Computation and computational thinking.* *The Computer Journal*, **55**(7), 832–835. https://doi.org/10.1093/comjnl/bxs074

Alves, N. D. C., Von Wangenheim, C. G., & Hauck, J. C. (2019). Approaches to assess computational thinking competences based on code analysis in K-12 education: A systematic mapping study. *Informatics in Education, 18*(1), 17. https://doi.org/10.15388/infedu.2019.02

Armoni, M., Meerbaum-Salant, O., & Ben-Ari, M. (2015). From scratch to “real” programming. *ACM Transactions on Computing Education (TOCE),* **14**(4), 1–15. https://doi.org/10.1145/2677087

Babazadeh, M., & Negrini, L. (2022). How is computational thinking assessed in European K-12 education? A systematic review. *International Journal of Computer Science Education in Schools, 5*(4), 3–19. https://doi.org/10.21585/ijcses.v5i4.138

Barr, V., & Stephenson, C. (2011). Bringing computational thinking to K-12: What is involved and what is the role of the computer science education community? *ACM Inroads, 2*(1), 48–54. https://doi.org/10.1145/1929877.1929905

Basu, S., Rutstein, D. W., Xu, Y., Wang, H., & Shear, L. (2021). A principled approach to designing computational thinking concepts and practices assessments for upper elementary grades. *Computer Science Education, 31*(2), 169–198. https://doi.org/10.1080/08993408.2020.1866939

Bers, M. U., Strawhacker, A., & Sullivan, A. (2022). *The state of the field of computational thinking in early childhood education*. https://sites.bc.edu/devtech/wp-content/uploads/sites/113/2022/07/TheStateofFieldandComputationalThinkinginEarlyChildhoodEducation.pdf.

Berssanette, J. H., & de Francisco, A. C. (2021). Cognitive load theory in the context of teaching and learning computer programming: A systematic literature review. *IEEE Transactions on Education*, **65**(3), 440–449. https://doi.org/10.1109/TE.2021.3127215

Bocconi, S., Chioccariello, A., Dettori, G., Ferrari, A., & Engelhardt, K. (2016). *Developing computational thinking in compulsory education-Implications for policy and practice*. No. JRC104188). Joint Research Centre (Seville site).

Brennan, K., & Resnick, M. (2012). New frameworks for studying and assessing the development of computational thinking. *Proceedings of the 2012 annual meeting of the American educational research association, Vancouver, Canada* (Vol. 1, p. 25). http://scratched.gse.harvard.edu/ct/files/AERA2012.pdf.

Brown, T. A., & Moore, M. T. (2012). Confirmatory factor analysis. *Handbook of structural equation modeling, 361*, 379.

Buitrago Flórez, F., Casallas, R., Hernández, M., Reyes, A., Restrepo, S., & Danies, G. (2017). Changing a generation's way of thinking: Teaching computational thinking through programming. *Review of Educational Research, 87*(4), 834–860. https://doi.org/10.3102/0034654317710096

Çakıroğlu, Ü., & Çevik, İ. (2022). A framework for measuring abstraction as a sub-skill of computational thinking in block-based programming environments. *Education and Information Technologies, 27*(7), 9455–9484. https://doi.org/10.1007/s10639-022-11019-2

Chen, G., Shen, J., Barth-Cohen, L., Jiang, S., Huang, X., & Eltoukhy, M. (2017). Assessing elementary students' computational thinking in everyday reasoning and robotics programming. *Computers & Education, 109*, 162–175. https://doi.org/10.1016/j.compedu.2017.03.001

Chevalier, M. (2022). *Evaluation d'une expérimentation randomisée de la pensée informatique, vecteur d'apprentissage des mathématiques au cycle 3 de l'école élémentaire, en CM1 et CM2* (Thèse de doctorat, Université Grenoble Alpes).

Ching, Y. H., Hsu, Y. C., & Baldwin, S. (2018). Developing computational thinking with educational technologies for young learners. *TechTrends, 62*, 563–573. https://doi.org/10.1007/s11528-018-0292-7

CSTA et ISTE. (2011). *Computational Thinking in K-12 Education leadership toolkit*. http://csta.acm.org/Curriculum/sub/CurrFiles/471.11CTLeadershiptToolkit-SP-vF.pdf.

Denning, P. J. (2017). Remaining trouble spots with computational thinking. *Communications of the ACM*, **60**(6), 33–39. https://doi.org/10.1145/2998438

Denning, P. J., Tedre, M., & Yongpradit, P. (2017). Misconceptions about computer science. *Communications of the ACM*, **60**(3), 31–33. https://doi.org/10.1145/3041047

Dunn, T. J., Baguley, T., & Brunsden, V. (2014). From alpha to omega: A practical solution to the pervasive problem of internal consistency estimation. *British Journal of Psychology, 105*(3), 399–412. https://doi.org/10.1111/bjop.12046

El-Hamamsy, L., Zapata-Cáceres, M., Barroso, E. M., Mondada, F., Zufferey, J. D., & Bruno, B. (2022). The competent computational thinking test: Development and validation of an unplugged computational thinking test for upper primary school. *Journal of Educational Computing Research, 60*(7), 1818–1866. https://doi.org/10.1177/07356331221081753
Forsström, S. E., & Kaufmann, O. T. (2018). A literature review exploring the use of programming in mathematics education. *International Journal of Learning, Teaching and Educational Research*, 17(12), 18–32. https://doi.org/10.26803/ijlter.17.12.2

Gökçe, S., & Yenmez, A. A. (2022). Ingenuity of scratch programming on reflective thinking towards problem solving and computational thinking. *Education and Information Technologies*, 1–25. https://doi.org/10.1007/s10639-022-11385-x

Grover, S., & Pea, R. (2013). Computational thinking in K-12: A review of the state of the field. *Educational Researcher*, 42(1), 38–43. https://doi.org/10.3102/0013189X12463051

Han, J. (2023). A Systematic Review of Computational Thinking Assessment in the Context of 21st Century Skills. *2nd International Conference on Humanities, Wisdom Education and Service Management (HWESM 2023)* (pp. 271–283). Atlantis Press. https://doi.org/10.2991/978-2-38476-068-8_34

Ioannou, A., & Makridou, E. (2018). Exploring the potentials of educational robotics in the development of computational thinking: A summary of current research and practical proposal for future work. *Education and Information Technologies*, 23, 2531–2544. https://doi.org/10.1007/s10639-018-9729-z

Jonassen, D. H. (1997). Instructional design models for well-structured and III-structured problem-solving learning outcomes. *Educational Technology Research and Development*, 45(1), 65–94. https://doi.org/10.1007/BF02299613

Kalelioglu, F., Gulbahar, Y., & Kukul, V. (2016). A framework for computational thinking based on a systematic research review. *Baltic Journal of Modern Computing*, 4, 583–596.

Kong, S. C., & Wang, Y. Q. (2021). Item response analysis of computational thinking practices: Test characteristics and students' learning abilities in visual programming contexts. *Computers in Human Behavior*, 122, 106836. https://doi.org/10.1016/j.chb.2021.106836

Korkmaz, Ö., & Bai, X. (2019). Adapting computational thinking scale (CTS) for Chinese high school students and their thinking scale skills level. *Participatory Educational Research*, 6(1), 10–26. https://doi.org/10.17275/per.19.2.6.1

Korkmaz, Ö., Çakir, R., & Özden, M. Y. (2017). A validity and reliability study of the computational thinking scales (CTS). *Computers in Human Behavior*, 72, 558–569. https://doi.org/10.1016/j.chb.2017.01.005

Krathwohl, D. R. (2002). A revision of Bloom's taxonomy: An overview. *Theory into Practice*, 41(4), 212–218. https://doi.org/10.1207/s15430421tip4104_2

Kukul, V., & Karatas, S. (2019). Computational thinking self-efficacy scale: Development, validity and reliability. *Informatics in Education*, 18(1), 151–164. https://doi.org/10.15388/infedu.2019.07

Larousse. (s.d.). Programmation. Dans Dictionnaire en ligne. Consulté le 25 Mai 2023 sur https://www.larousse.fr/dictionnaires/francais/programmation/64205.

Lai, R. P., & Ellefson, M. R. (2022). How multidimensional is computational thinking competency? A bi-factor model of the computational thinking challenge. *Journal of Educational Computing Research*, 61(2), 259–282. https://doi.org/10.1177/07356331221121025

Li, Y., Xu, S., & Liu, J. (2021). Development and validation of computational thinking assessment of Chinese elementary school students. *Journal of Pacific Rim Psychology*, 15. https://doi.org/10.1117/18344909211010240, 18344909211010240.

Lye, S. Y., & Koh, J. H. L. (2014). Review on teaching and learning of computational thinking through programming: What is next for K-12? *Computers in Human Behavior*, 41, 51–61. https://doi.org/10.1016/j.chb.2014.09.012

Mohaghegh, D. M., & McCauley, M. (2016). Computational thinking: The skill set of the 21st century. *International Journal of Computer Science and Information Technology*, 7 (3), 1524–1530. https://ijcsit.com/docs/Volume%207/vol7issue3/ijcsit20160703104.pdf.

Moreno-León, J., & Robles, G. (2015). Dr. Scratch: A web tool to automatically evaluate Scratch projects. *Proceedings of the workshop in primary and secondary computing education* (pp. 132–133). https://doi.org/10.1145/2818314.2818338

Moreno-León, J., Román-González, M., Harteveld, C., & Robles, G. (2017). On the automatic assessment of computational thinking skills: A comparison with human experts. *Proceedings of the 2017 CHI Conference Extended Abstracts on Human Factors in Computing Systems* (pp. 2788–2795). https://doi.org/10.1145/3027063.3053216

Moreno-León, J., Román-González, M., & Robles, G. (2018). On computational thinking as a universal skill: A review of the latest research on this ability. In *2018 IEEE Global Engineering Education Conference (EDUCON)* (pp. 1684–1689). IEEE. https://doi.org/10.1109/EDUCON.2018.8363437

Nogry, S. (2018). In Comment apprenent les élèves au cours d'une sèquence de robotique éducative en classe de CP? (pp. 235–243). https://doi.org/10.3726/b13411

Nordby, S. K., Bjerke, A. H., & Mifsud, L. (2022). Computational thinking in the primary mathematics classroom: A systematic review. *Digital Experiences in Mathematics Education*, 8(1), 27–49. https://doi.org/10.1007/s40751-022-00102-5

Polit, D. F. (2014). Getting serious about test-retest reliability: a critique of retest research and some recommendations. *Quality of Life Research*, 23, 1713–1720. https://doi.org/10.1007/s11136-014-0632-9

Relkin, E., de Ruiter, L., & Bers, M. U. (2020). TechCheck: Development and validation of an unplugged assessment of computational thinking in early childhood education. *Journal of Science Education and Technology*, 29(4), 482–498. https://doi.org/10.1007/s10956-020-09831-x

Román-González, M. (2015). Computational thinking test: Design guidelines and content validation. *EDULEARN15 Proceedings* (pp. 2436–2444).

Román-González, M., Moreno-León, J., & Robles, G. (2019). Combining assessment tools for a comprehensive evaluation of computational thinking interventions. *Computational thinking education* (pp. 79–98). S.-C.. https://doi.org/10.1007/978-981-13-6528-7_6

Román-González, M., Pérez-González, J. C., & Jiménez-Fernández, C. (2017). Which cognitive abilities underlie computational thinking? Criterion validity of the Computational Thinking Test. *Computers in Human Behavior*, 72, 678–691. https://doi.org/10.1016/j.chb.2016.08.047

Román-González, M., Pérez-González, J. C., Moreno-León, J., & Robles, G. (2018). Can computational talent be detected? Predictive validity of the Computational Thinking Test. *International Journal of Child-Computer Interaction*, 18, 47–58. https://doi.org/10.1016/j.ijcci.2018.06.004

Romero, M., Lille, B., Viéville, T., Duflot-Kremer, M., de Smet, C., & Belhassein, D. (2018). Analyse comparative d'une activité d'apprentissage de la programmation en mode branché et débranché. *Educo-Conference internationale sur l'enseignement au numérique et par le numérique*. https://inria.hal.science/hal-01861732/file/Educode%20UnPlugged-CDS06_soumis.pdf

Rowe, E., Almeda, M. V., Asbell-Clarke, J., Scruggs, R., Baker, R., Bardar, E., & Gasca, S. (2021). Assessing implicit computational thinking in Zoombinis puzzle gameplay. *Computers in Human Behavior*, 120, 106707. https://doi.org/10.1016/j.chb.2021.106707

Rubio, M. A., Romero-Zaliz, R., Mañoso, C., & de Madrid, A. P. (2015). Closing the gender gap in an introductory programming course. *Computers & Education*, 82, 409–420. https://doi.org/10.1016/j.compedu.2014.12.003

Scherer, R., Siddiq, F., & Viveros, B. S. (2020). A meta-analysis of teaching and learning computer programming: Effective instructional approaches and conditions. *Computers in Human Behavior*, 109, 106349. https://doi.org/10.1016/j.chb.2020.106349

Selby, C., & Woollard, J. (2013). Computational thinking: the developing definition. *Paper presented at the 18th annual conference on innovation and technology in computer science education, Canterbury*. http://eprints.soton.ac.uk/id/eprint/356481

Shute, V. J., Sun, C., & Asbell-Clarke, J. (2017). Demystifying computational thinking. *Educational Research, 22*, 142–158. https://doi.org/10.1016/j.edurev.2017.09.003

Sigayret, K., Blanc, N., & Tricot, A. (2022). L'apprentissage de la programmation : quels outils pour évaluer le développement de la pensée informatique à l'école ? *Enfance*, 4 (4), 479–500. https://doi.org/10.3917/enf2.224.0479

Sun, L., Guo, Z., & Zhou, D. (2022). Developing K-12 students' programming ability: A systematic literature review. *Education and Information Technologies*, 27(5), 7059–7097. https://doi.org/10.1007/s10639-022-10891-2

Sung, J. (2022). Assessing young Korean children's computational thinking: A validation study of two measurements. *Education and Information Technologies*, 27(9), 12969–12997. https://doi.org/10.1007/s10639-022-11137-x

Taber, K. S. (2018). The use of Cronbach's alpha when developing and reporting research instruments in science education. *Research in Science Education*, 48, 1273–1296. https://doi.org/10.1007/s11165-016-9602-2

Tang, X., Yin, Y., Lin, Q., Hadad, R., & Zhai, X. (2020). Assessing computational thinking: A systematic review of empirical studies. *Computers & Education*, 148, 103798. https://doi.org/10.1016/j.compedu.2019.103798

Taslibeyaz, E., Kursun, E., & Karaman, S. (2020). How to develop computational Thinking: A systematic review of empirical studies. *Informatics in Education*, 19(4), 701–719. https://doi.org/10.15388/infedu.2020.30

Tchounikine, P. (2017). *Initier les élèves à la pensée informatique et à la programmation avec Scratch*. Laboratoire d'informatique de Grenoble. https://pdfbib.com/pdf/0690-i-initier-les-élèves-a-la-programmation-avec-scratch.pdf.

Tikva, C., & Tambouris, E. (2021). Mapping computational thinking through programming in K-12 education: A conceptual model based on a systematic literature review. *Computers & Education*, 162, 104083. https://doi.org/10.1016/j.compedu.2020.104083

Trizano-Hermosilla, I., & Alvarado, J. M. (2016). Best alternatives to Cronbach's alpha reliability in realistic conditions: congeneric and asymmetrical measurements. *Frontiers in Psychology*, 7, 769. https://doi.org/10.3389/psyg.2016.00769

Tsarava, K., Leifheit, L., Ninaus, M., Román-González, M., Butz, M. V., Golle, J., & Moeller, K. (2019). Cognitive correlates of computational thinking: Evaluation of a blended unplugged/plugged-in course. *Proceedings of the 14th workshop in primary and secondary computing education* (pp. 1–9). https://doi.org/10.1145/3361721.3361729

Yadav, A., Good, J., Voogt, J., & Fisser, P. (2017). Computational thinking as an emerging competence domain. *Competence-based vocational and professional education: Bridging the worlds of work and education*, 1051–1067. https://doi.org/10.1007/978-3-319-41713-4_49

Weese, J. L., & Feldhausen, R. (2017). STEM outreach: Assessing computational thinking and problem solving. *2017 ASEE Annual Conference & Exposition*. https://doi.org/10.18260/1-2-28845

Weintrop, D., & Wilensky, U. (2019). Transitioning from introductory block-based and text-based environments to professional programming languages in high school computer science classrooms. *Computers & Education*, 142, 103646. https://doi.org/10.1016/j.compedu.2019.103646

Weintrop, D., Beheshti, E., Horn, M., Orton, K., Jona, K., Trouille, L., & Wilensky, U. (2016). Defining computational thinking for mathematics and science classrooms. *Journal of Science Education and Technology*, 25, 127–147. https://doi.org/10.1007/s10956-015-9581-5

Wing, J. M. (2006). Computational thinking. *Communications of the ACM*, 49(3), 33–35. https://doi.org/10.1145/1118178.1118215

Wing, J. M. (2008). Computational thinking and thinking about computing. *Philosophical Transactions of the Royal Society A: Mathematical, physical and engineering sciences*, 366 (1881), 3717–3725. https://doi.org/10.1098/rsta.2008.0118

Wing, J. (2011). Research notebook: Computational thinking — What and why. *The Link Magazine*, 6, 20–23. https://people.cs.vt.edu/~kafura/CS6604/Papers/CT-What-And-Why.pdf.

Zhang, L., & Nouri, J. (2019). A systematic review of learning computational thinking through Scratch in K-9. *Computers & Education*, 141, 103607. https://doi.org/10.1016/j.compedu.2019.103607