# Typologie d'erreurs en programmation et détection automatique dans un code Python

Eva Chouaki, Badmavasan Kirouchenassamy, Sébastien Jolivet, Amel Yessad

► To cite this version:

Eva Chouaki, Badmavasan Kirouchenassamy, Sébastien Jolivet, Amel Yessad. Typologie d'erreurs en programmation et détection automatique dans un code Python. 8e Atelier "Apprentissage de la pensée informatique de la maternelle à l'Université (APIMU 1000)" @ EIAH 2025, 2025, Villeneuve d'Ascq, France. pp.7-19. hal-05084739

HAL Id: hal-05084739

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

Submitted on 26 May 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_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Typologie d'erreurs en programmation et détection automatique dans un code Python

Eva Chouaki<fnref n="1" /> Badmavasan Kirouchenassamy<fnref n="2" /> Sébastien Jolivet<fnref n="1" />, <fnref n="2" />, ³ Amel Yessad<fnref n="2" />

(1) IUFE, UNIGE, Genève, Suisse

(2) Sorbonne Université, CNRS, LIP6, F-75005 Paris, France

(3) TECFA, UNIGE, Genève, Suisse

eva.dechaux@unige.ch, sebastien.jolivet@unige.ch, prenom.nom@lip6.fr

## RÉSUMÉ

Cette contribution s'inscrit dans un contexte plus large de décision de rétroaction dans l'environnement AlgoPython. Pour décider ces rétroactions, nous devons identifier et catégoriser finement des erreurs dans des codes Python produits par des novices en programmation. Après avoir précisé nos besoins et les avoir mis en regard de la littérature, nous exploitons un référentiel de types de tâches déjà existant pour construire notre propre typologie d'erreurs. Puis nous présentons un processus, réifié dans une librairie Python, que nous avons développé pour identifier les erreurs de notre typologie dans des codes erronés.

## ABSTRACT

This contribution is part of a wider context of feedback decision in the AlgoPython environment. To decide on feedback, we need to identify and finely categorize errors in Python code produced by programming novices. After specifying our needs and comparing them with the literature, we exploit an existing repository of types of tasks to build our own typology of errors. We then present a process, reified in a Python library, that we have developed to identify the errors of our typology in erroneous codes.

**MOTS-CLÉS** : Python, erreur en programmation, types de tâches.

**KEYWORDS:** Python, programming error, types of tasks.

# 1 Introduction

Cette contribution se focalise sur un enjeu particulier d'un projet d'implémentation de rétroactions épistémiques adaptées dans l'environnement AlgoPython<fnref n="1" /> (Jolivet et al., 2025). Parmi les éléments définissant l'état utilisé pour décider la rétroaction, deux nécessitent de pouvoir identifier et catégoriser les erreurs dans un code proposé. Tout d'abord, lors de la soumission d'un code erroné<fnref n="2" />, un des éléments contribuant à la décision de la rétroaction est la ou les erreurs identifiées dans ce code. Par ailleurs, nous construisons aussi, au fil de l'utilisation de l'environnement, un profil de l'apprenant prend notamment en compte son rapport aux différentes erreurs (apparition, fréquence...).

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

<footnote n="1">1. http://algopython.fr</footnote>

<footnote n="2">2. Dans notre contexte il s'agit d'un code syntaxiquement correct mais qui ne résout pas le problème donné</footnote>
Pour répondre à ces deux besoins, nous devons, sur la base d'un code erroné, pouvoir identifier et
positionner par rapport à une typologie, les erreurs dans ce code. C'est ce double objectif que nous
abordons dans cette contribution.

Dans un premier temps (section 2), pour définir notre grille d'analyse de la littérature, nous précisions
les besoins issus de notre contexte de travail. Nous proposons alors une synthèse de différentes
approches proposées dans la littérature relativement aux erreurs dans le domaine de la programmation.
Face au constat de l'absence d'une typologie permettant de satisfaire nos besoins, nous proposons la
définition d'une typologie d'erreurs (section.3). Elle est basée sur un référentiel de types de tâches
déjà exploité par ailleurs dans le projet.

Dans un deuxième temps (section.4) nous présentons notre moyen de lier notre typologie d'erreurs
et les codes erronés des apprenants. Il est basé sur une analyse des codes AST et est implémenté au
moyen d'une librairie Python.

## 2 Définition et classification des erreurs en programmation

De nombreux travaux mettent en évidence la place et l'importance de l'erreur dans l'apprentissage
en général (Astolfi, 1997). Dans le cadre des rétroactions la prise en compte de l'erreur est aussi
pointée comme un critère d'efficacité (Brooks et al., 2019); (Small and Lin, 2018). Afin d'orienter
notre analyse de la littérature relative aux erreurs dans la programmation nous commençons par
spécifier nos besoins en termes de détection et d'analyse des erreurs. Il est important, à ce stade, de
préciser que l'EIAH *AlgoPython* est destiné à des apprenants totalement, ou largement, novices en
programmation et qu'ils sont amenés à y résoudre des problèmes simples (affichage, labyrinthes,
reproduction de dessins) ne demandant qu'un nombre limité de lignes de codes (entre 3 et une dizaine
au maximum) pour parvenir à une solution (ceci limite le nombre de solutions possibles pour un
problème donné). De plus, dans l'environnement, nous analysons le code de l'apprenant uniquement
s'il est syntaxiquement correct et s'il ne résout pas le problème donné. Nous considérons donc comme
erreur un écart entre le code de l'apprenant et un (ou plusieurs) code(s) permettant effectivement de
résoudre le problème donné.

### 2.1 Définition de nos besoins en terme de détection et classification d'erreur

Nous proposons des rétroactions sur des codes courts et erronés (même s'ils peuvent être proches
d'une solution). Pour avoir la possibilité de proposer des rétroactions les plus adaptées possible à
l'apprenant nous avons besoin de pouvoir identifier et classifier précisément la ou les erreurs présentes
dans son code. Ceci implique de pouvoir distinguer des différences précises entre deux codes, sans
se limiter à des analyses globales du type "Problème sur la boucle" ou "La structure proposée n'est
pas bonne". Précisons que l'identification des erreurs est un des éléments, parmi d'autres, guidant la
décision de la rétroaction. Ceci ne signifie ni que l'erreur identifiée soit explicitement signalée dans la
rétroaction ni que la rétroaction vise précisément, et encore moins exclusivement, à corriger cette
erreur. La décision de la meilleure rétroaction, au regard du contexte et des objectifs visés (réussite
de la tâche et apprentissage), n'est donc pas uniquement fondée sur les erreurs mais prend aussi en
compte par exemple le profil de l'apprenant, la tâche à réaliser, plus d'éléments sur ce processus de
décision sont présentés dans (Jolivet et al., 2025).
Afin d'identifier dans la littérature relative à l'erreur en programmation les éléments pouvant nous servir nous regardons donc :

1. ce qui est détecté : manifestation de l'erreur (i.e. problème dans le code) ou cause de l'erreur (i.e. élément relatif à l'apprenant)

2. finalité pour laquelle l'erreur est détectée;

3. contexte du travail (langage particulier, dans un EIAH ou non);

4. existence d'une classification ; *a priori* des erreurs ou la production d'une classification unique-ment sur la base des productions des apprenants;

5. existence d'une méthode de détection des erreurs (absente, manuelle, automatique).

Ces éléments précisés nous présentons maintenant les éléments essentiels issus de la littérature et les conséquences que nous en tirons.

## 2.2 Etude de la littérature

Pour réaliser cette étude nous avons travaillé de la manière suivante. Nous avons analysé plusieurs articles traitant des erreurs en programmation. Cela nous a permis d'extraire certaines caractéristiques communes à ces articles notamment sur les mots clés utilisés dans les résumés. En effet, le mot comme "error" combiné aux mots clés "programming", "programmer", "algorithm", "student" revenaient systématiquement dans les premiers articles étudiés. Nous avons ensuite cherché dans de grandes bases de données comme HAL plusieurs requêtes combinant ces différents mots clés, en filtrant sur le domaine relatif à l'informatique. Les quatre contributions suivantes ont re-tenues notre attention, car les autres ne proposaient pas de classification des erreurs en programmation.

Il s'agit des articles suivants :

A. **Types of Errors in Block Programming : Driven by Learner, Learning Environment de Ben-Yaacov et Hershkovitz, Journal of Educational Computing Research, 2023**

B. **Logic Error Detection Algorithm for Novice Programmers based on Structure Pattern and Error Degree de Yuto Yoshizawa et Yutaka Watanobe, iCAST, 2018**

C. **A New Look at Novice Programmer Errors de Davin McCall et Michael Kölling, King's College London, ACM Transactions on Computing Education, 2019**

D. **Novice Java Programming Mistakes : Large-Scale Data vs. Educator Beliefs de Neil C. C. Brown & Amjad Altadmri, ACM Transactions on Computing Education, 2017**

Dans le tableau 1, nous comparons ces quatre contributions au regard des critères identifiés dans la section précédente.

On constate que, dans l'ensemble des articles étudiés, les erreurs sont décrites en fonction de ce qui est observé dans les codes des apprenants ou dans les messages d'erreurs générés lors de la compilation et non pas relativement à une typologie d'erreurs préexistante. Il apparaît également que deux objectifs principaux motivent les auteurs dans leur volonté de classifier ces erreurs. Le premier, à visée pédagogique, vise à mieux comprendre les erreurs des apprenants afin d'adapter les stratégies d'enseignement. Le second objectif concerne la détection automatique des erreurs, dans le but de développer des outils capables d'identifier ces erreurs de manière autonome, par exemple dans le but d'adapter un EIAH (les activités, les rétroactions, etc.).

Concernant la manière dont les erreurs sont détectées, l'article A repose sur une analyse manuelle
<table><caption>TABLE 1 – Comparaison de quatre approches de détection et classification des erreurs</caption><thead><tr><th></th><th>(Ben-Yaacov and Hershkovitz, 2022)</th><th>(Yoshizawa and Watanobe, 2018)</th><th>(McCall and Köl-ling, 2019)</th><th>(Brown and Al-tadmri, 2017)</th></tr></thead><tbody><tr><th>Manifestation ou cause de l'erreur</th><td>Manifestation</td><td>Manifestation</td><td>Manifestation</td><td>Manifestation</td></tr><tr><th>Finalité de la détection</th><td>Pédagogique</td><td>Détection</td><td>Pédagogique</td><td>Pédagogique et détection</td></tr><tr><th>Contexte du travail</th><td>Plateforme Kodetu (programmation par blocs)</td><td>Aizu Online Judge (java : évaluation automatique)</td><td>BlueJ (java)</td><td>BlackBox pour collecter des soumissions en Java à partir d'autres environnements (BlueJ, Eclipse, etc.)</td></tr><tr><th>Classification des erreurs</th><td>Basés sur production d'apprenants</td><td>Basés sur production d'apprenants</td><td>Basés sur production d'apprenants</td><td>Basés sur production d'apprenants</td></tr><tr><th>Méthode de détection</th><td>Analyse manuelle et catégorisation</td><td>Utilisation d'AST</td><td>Analyse automatisée des messages du compilateur</td><td>Analyse automatisée des messages du compilateur</td></tr></tbody></table>

des codes. Pour les articles C et D il s'agit d'exploiter une analyse automatique des messages du compilateur, qui permet d'identifier le nombre d'erreurs similaires afin de déterminer une fréquence des erreurs. Enfin, l'article B utilise des algorithmes basés sur la représentation en Abstract Syntax Trees (AST) pour détecter automatiquement les erreurs.

On peut retenir en particulier des articles étudiés que nous n'avons identifié aucune typologie des erreurs en programmation, d'un niveau un peu plus fin que *erreurs syntaxiques*; *erreur logique*; *erreur d'exécution*. Par ailleurs, d'éventuelles classifications sont construites de manière dynamique au fur et à mesure de l'analyse de codes d'apprenants.

Or dans notre contexte nous devons pouvoir mettre en relation les erreurs observées avec d'autres éléments tels que l'énoncé de l'exercice et l'apprenant. Il est donc souhaitable pour nous de disposer d'un ensemble d'erreurs prédéfini. C'est la construction d'un tel ensemble que nous abordons dans la section suivante.

## 3 Proposition de typologie d'erreurs

Dans le projet au sein duquel s'inscrit ce travail, on exploite déjà un référentiel de types de tâches<fnref n="3" />, présenté par exemple dans (Jolivet et al., 2023), pour décrire les exercices et modéliser les rétroactions. Un extrait du référentiel des types de tâches relatif aux boucles est proposé figure 1.

Afin de conserver une cohérence globale aux différentes composantes de notre environnement nous

<footnote n="3">3. https://link.infini.fr/ref Prog</footnote>
<figure><img src="image_3.png" /><figcaption>FIGURE 1 – Extrait du référentiel de types de tâches relatif aux boucles</figcaption></figure>

avons donc décidé de construire notre typologie d'erreur sur la base de ce même référentiel. Pour cela, pour cela nous avons identifié les erreurs possibles associées à un ou plusieurs de ces types de tâches. Cette typologie est structurée de la même manière que le référentiel de type de tâches autour des thèmes suivants : Programmation et algorithme ; Variable ; Instruction conditionnelle ; Fonction ; Boucle ; Expression. Elle est présentée en intégralité dans l'Annexe 1 et un extrait qui contient les erreurs relatives aux boucles est proposé dans le tableau 2.

<table><thead><tr><th>ERREUR</th><th>DETAILS OU EXEMPLES</th><th>TYPE(S) DE TÂCHES</th></tr></thead><tbody><tr><td colspan="3" style="text-align: center; font-weight: bold;">BOUCLES</td></tr><tr><td>(LO-Iterator-Usage-Error)<br></td><td>L'apprenant s'est trompé dans les valeurs prises par l'itérateur (valeur de départ par exemple)</td><td>B. Déterminer si une (ou plusieurs) instruction(s) du corps d'une boucle bornée utilise(nt) l'itérateur</td></tr><tr><td>(LO-FOR-Number-Iteration-Error-Under2)<br>erreur nombre d'itérations de la boucle FOR (à un près)</td><td>La boucle s'exécute une fois de trop ou une fois de moins</td><td>B. Déterminer le nombre d'itérations à réaliser pour une boucle bornée</td></tr><tr><td>(LO-FOR-Number-Iteration-Error)<br>erreur nombre d'itérations de la boucle FOR (&gt;2)</td><td>La boucle ne s'exécute pas le bon nombre de fois</td><td>B. Déterminer le nombre d'itérations à réaliser pour une boucle bornée</td></tr><tr><td>(LO-WHILE-Number-Iteration-Error-Under2)<br>erreur nombre d'itérations de la boucle WHILE (à un près)</td><td>La boucle s'exécute une fois de trop ou une fois de moins</td><td>B. Déterminer le nombre d'itérations à réaliser pour une boucle bornée</td></tr><tr><td>(LO-WHILE-Number-Iteration-Error)<br>erreur nombre d'itérations de la boucle WHILE (&gt;2)</td><td>La boucle ne s'exécute pas le bon nombre de fois</td><td>B. Déterminer le nombre d'itérations à réaliser pour une boucle bornée</td></tr></tbody></table>

(suite page suivante)
<table><caption>TABLE 2 – Typologie d'erreurs, extrait relatif aux boucles</caption><thead><tr><td>ERREUR</td><td>DETAILS OU EXEMPLES</td><td>TYPE(S) DE TÂCHES</td></tr></thead><tbody><tr><td>(LO-Exit-Condition-Error-Start) Errur condition d'arrêt de la boucle : départ</td><td> technical details or examples</td><td>B. Déterminer la condition d'arrêt d'une boucle non bornée</td></tr><tr><td>(LO-Exit-Condition-Error-Evolution) Errur condition d'arrêt de la boucle : évolution</td><td> technical details or examples</td><td>B. Déterminer l'instruction modifiant la valeur de la condition d'arrêt d'une boucle non bornée</td></tr><tr><td>(LO-Body-Missing-Not-Present-Anywhere) Errur dans le corps de la boucle : Instruction manquante et non présente</td><td>Instruction absente dans le corps de la boucle et dans le programme</td><td>B. Déterminer les instructions à exécuter à chaque itération d'une boucle bornée<br>B. Déterminer les instructions à exécuter à chaque itération pour une boucle non bornée</td></tr><tr><td>(LO-Body-Misplaced) Errur dans le corps de la boucle : Instruction manquante et présente ailleurs dans le programme</td><td>Instruction présente ailleurs dans le programme</td><td>B. Déterminer les instructions à exécuter à chaque itération d'une boucle bornée<br>B. Déterminer les instructions à exécuter à chaque itération pour une boucle non bornée</td></tr><tr><td>(LO-Body-Error) Errur dans le corps de la boucle : Instruction erronée</td><td>Instruction présente proche de celle manquante</td><td>B. Déterminer les instructions à exécuter à chaque itération d'une boucle bornée<br>B. Déterminer les instructions à exécuter à chaque itération pour une boucle non bornée</td></tr><tr><td>(LO-For-Missing) Boucle FOR manquante</td><td>Absence d'une boucle FOR</td><td>B. Produire une boucle bornée</td></tr><tr><td>(LO-While-Missing) Boucle WHILE manquante</td><td>Absence d'une boucle WHILE</td><td>B. Produire une boucle non bornée</td></tr></tbody></table>

Nous présentons dans la section suivante l'exploitation de cette typologie dans le cadre de notre problème de détection des erreurs dans AlgoPython.

## 4 De la typologie d'erreurs à l'analyse de codes d'élèves

Dans le contexte de notre recherche, nous disposons du code erroné d'un apprenant et d'un (ou plusieurs) codes corrects. Pour identifier les erreurs présentes dans le code erroné nous avons défini le processus suivant : représentation du code erroné et du ou des codes corrects sous forme d'un arbre syntaxique abstrait (AST). Cette représentation, qui capture les principales constructions d'un programme tout en abstrayant les détails syntaxiques, a été fréquemment utilisée dans le domaine des EIAH (Piech et al., 2012; Broisin and Hérouard, 2019; Lazar et al., 2017) ainsi que dans d'autres domaines tels que le test logiciel ou la correction automatique de code (Le Goues et al., 2019; Shen and Chen, 2020). Ensuite, nous nous appuyons sur l'algorithme de Zang et Shasha (Zhang and Shasha, 1989) (AZS) de programmation dynamique pour apparaître l'AST de l'élève avec l'AST du code correct le plus proche. Cet algorithme permet de chercher une séquence d'opérations d'édition élémentaires et ordonnées (insertion, suppression et mise à jour de nœuds) permettant de transformer l'AST de l'élève en celui du code correct, tout en minimisant le coût cumulé de ces opérations (c'est-à-dire le nombre
Listing 3 – Liste des opérations d’édition pour passer de l’AST de l’élève à l’AST du code correct le plus proche. Les opérations surlignées définissent des patterns qui permettent d’identifier les erreurs LO-FOR-Number-Iteration-Error-Under2, LO-Body-Misplaced.

# 5 Conclusion et perspectives

Dans cette contribution nous proposons deux résultats principaux :

- Une typologie des erreurs en programmation, dans le contexte des premiers apprentissages, basée sur un référentiel de types de tâches de programmation;

- Un processus, et une librairie associé, permettant d'analyser un code erroné, au regard d'un code correct, et d'identifier les erreurs de la typologie présentes dans le code erroné.

L'exploitation de cette typologie dans la modélisation et la production de rétroaction est développée dans (Jolivet et al., 2025).

Enfin, si dans notre contexte ce travail vise à contribuer à la décision de rétroactions dans l'environnement AlgoPython, il est très certainement exploitable et adaptable dans d'autres contextes.

Ainsi, la typologie proposée est adaptable soit, par exemple, en réduisant le niveau de finesse pour un public d'apprenants plus expert, ou en introduisant des erreurs spécifiques à un autre contexte. Elle peut aussi être exploitée pour des finalités diverses, comme la recommandation d'activités adaptées, l'évaluation et la notation automatiques ou encore l'élaboration d'indicateurs comportementaux à destination des enseignants pour les aider dans leurs stratégies de remédiation. Ce travail pourrait également être utile à des chercheurs qui s'intéressent à l'apprentissage et à l'enseignement de la programmation pour un public débutant, ainsi qu'à la compréhension des phénomènes cognitifs sous-jacents.

De même, le processus proposé autour de l'analyse des AST de différents codes pourrait être déployé et adapté dans différents contextes, par exemple la comparaison de différents codes d'élèves, éventuellement tous corrects, pour mettre en exergue les différences et la diversité des stratégies souvent possibles dans un contexte de programmation. Il s'agirait alors de s'appuyer sur une typologie de différences et non pas une typologie d'erreurs.

# Références

Astolfi, J.-P. (1997). *L'erreur, un outil pour enseigner*. Pratiques et enjeux pédagogiques. ESF éditeur.
Publisher : ESF Paris.

Ben-Yaacov, A. and Hershkovitz, A. (2022). Types of Errors in Block Programming : Driven by Learner, Learning Environment. *Journal of Educational Computing Research*, page 073563312211023.

Broisin, J. and Hérouard, C. (2019). Design and evaluation of a semantic indicator for automatically supporting programming learning. In *12th International Conference on Educational Data Mining (EDM 2019)*, pages 270–275.

Brooks, C., Carroll, A., Gillies, R. M., and Hattie, J. (2019). A matrix of feedback for learning. *Australian Journal of Teacher Education (Online)*, 44(4):14–32.

Brown, N. C. C. and Altadmri, A. (2017). Novice Java Programming Mistakes : Large-Scale Data vs. Educator Beliefs. *ACM Transactions on Computing Education*, 17(2):1–21.
Jolivet, S., Dechaux, E., Gobard, A.-C., and Wang, P. (2023). Construction et exploitation d'un référentiel de types de tâches d'apprentissage de la programmation. In Iksal, S., Pélissier, C., Gilliot, J.-M., and Marzin-Janvier, P., editors, *Actes du colloque EIAH2023 : 11ème Conférence sur les Environnements Informatiques pour l'Apprentissage Humain*, pages 166-177, Brest.

Jolivet, S., Kirouchenassamy, B., Yessad, A., and Luengo, V. (2025). Modélisation et décision de rétroactions épistémiques dans l'environnement AlgoPython. In *Acte de la 10e conférence sur les Environnements Informatiques pour l'Apprentissage Humain, EIAH25*, Lille.

Lazar, T., Možina, M., and Bratko, I. (2017). Automatic extraction of ast patterns for debugging student programs. In *Artificial Intelligence in Education : 18th International Conference, AIED 2017, Wuhan, China, June 28-July 1, 2017, Proceedings 18*, pages 162-174. Springer.

Le Goues, C., Pradel, M., and Roychoudhury, A. (2019). Automated program repair. *Communications of the ACM*, 62(12):56-65.

McCall, D. and Kölling, M. (2019). A New Look at Novice Programmer Errors. *ACM Transactions on Computing Education*, 19(4):1-30.

Piech, C., Sahami, M., Koller, D., Cooper, S., and Blikstein, P. (2012). Modeling how students learn to program. In *Proceedings of the 43rd ACM technical symposium on Computer Science Education*, pages 153-160.

Shen, Z. and Chen, S. (2020). A survey of automatic software vulnerability detection, program repair, and defect prediction techniques. *Security and Communication Networks*, 2020(1):8858010.

Small, M. and Lin, A. (2018). Instructional feedback in mathematics. In Lipnevich, A. and Smith, J., editors, *The Cambridge handbook of instructional feedback*, pages 169-190. Cambridge University Press.

Yoshizawa, Y. and Watanobe, Y. (2018). Logic Error Detection Algorithm for Novice Programmers based on Structure Pattern and Error Degree. In *2018 9th International Conference on Awareness Science and Technology (iCAST)*, pages 297-301, Fukuoka. IEEE.

Zhang, K. and Shasha, D. (1989). Simple fast algorithms for the editing distance between trees and related problems. *SIAM journal on computing*, 18(6):1245-1262. Publisher: SIAM.
# 6 Annexe 1

Cette annexe présente l'intégralité des erreurs identifiées classifiées selon la structuration du référentiel de types de tâches.

<table><thead><tr><th>ERREUR</th><th>DETAILS OU EXEMPLES</th><th>TYPE(S) DE TÂCHE</th></tr></thead><tbody><tr><td colspan="3" style="text-align: center; font-weight: bold;">VARIABLE</td></tr><tr><td>(VA-Declaration-Initialization-Error) Errer de déclaration et initialisation variable</td><td>Mauvais choix du type dans la déclaration de la variable ou dans la valeur lors de l'initialisation</td><td>VA. Produire une variable (et ses fils)</td></tr><tr><td>(VA-Missing-Increment) Oubli incrémentation variable</td><td>Pour un compteur par exemple; soit la variable n'est pas modifiée, soit elle est réinitialisée à chaque fois</td><td>—</td></tr><tr><td>(VA-Invalid-Name) Errer dans choix du nom de la variable</td><td>Caractère interdit, mot réservé</td><td>VA. Choisir un nom valide (ne pas utiliser caractère interdit, nom réservé...)</td></tr><tr><td colspan="3" style="text-align: center; font-weight: bold;">INSTRUCTION CONDITIONNELLE</td></tr><tr><td>(CS-Incorrect-Number-Branches) Errer nombre de branches IC</td><td>Oubli d'un cas ou mauvais recouvrement des branches</td><td>IC. Déterminer les branches nécessaires pour une IC<br>IC. Déterminer l'ensemble des expressions de manière à définir une partition de l'ensemble des cas d'une instruction conditionnelle</td></tr><tr><td>(CS-Body-Error) Errer dans les instructions d'une IC</td><td>Une instruction est manquante ou erronée</td><td>IC. Déterminer les instructions à exécuter pour chaque branche d'une instruction conditionnelle</td></tr><tr><td>(CS-Body-Misplaced) Errer dans le corps de l'IC : Instruction manquante et présente ailleurs dans le programme</td><td>Une instruction ne se trouve pas dans la bonne branche ou se trouve en dehors de l'IC</td><td>IC. Déterminer les instructions à exécuter pour chaque branche d'une instruction conditionnelle</td></tr><tr><td>(CS-Missing) Instruction conditionnelle manquante</td><td>Absence de l'IC</td><td>IC. Produire une IC</td></tr><tr><td colspan="3" style="text-align: center; font-weight: bold;">FONCTIONS</td></tr><tr><td>(F-Definition-Error-Arg) Errer définition de la fonction sur les paramètres</td><td>Liée aux consignes de l'énoncé ou à la gestion possible avec le reste du code :<br>- oubli de paramètres ou mauvais choix de paramètres<br>- erreur sur les préconditions des paramètres</td><td>F. Déterminer les paramètres (noms, types, valeurs par défaut) d'une fonction<br>F. Déterminer les préconditions d'exécution (par exemple : tableau trié dans une recherche dichotomique...)</td></tr></tbody></table>

(suite page suivante)
<table><thead><tr><th>ERREUR</th><th>DETAILS OU EXEMPLES</th><th>TYPE(S) DE TÂCHE</th></tr></thead><tbody><tr><td>(F-Definition-Error-Return)<br>Érreur définition de la fonction sur les valeurs retournées</td><td>Liée aux consignes de l'énoncé ou à la gestion possible avec le reste du code :<br>- erreur sur ce qui est retourné ou non</td><td>F. Déterminer, le cas échéant, les éléments à retourner par une fonction</td></tr><tr><td>(F-Call-Error) Érreur dans l'appel de la fonction</td><td>Appel avec les mauvais paramètres ou pas d'affectation du résultat de la fonction</td><td>—</td></tr><tr><td>(F-Name-ParameterName-Error) Érreur nom de la fonction ou des paramètres</td><td>Caractère interdit, mot réservé</td><td>F. Déterminer le nom d'une fonction<br>F. Déterminer les paramètres (noms, types, valeurs par défaut) d'une fonction</td></tr><tr><td>(F-Definition-Missing) Définition d'une fonction abente</td><td>Absence d'une fonction</td><td>F. Produire une fonction</td></tr><tr><td colspan="3"><strong>BOUCLES</strong></td></tr><tr><td>(LO-Iterator-Usage-Error)<br>Érreur dans l'utilisation de l'itérateur de la boucle</td><td>L'apprenant s'est trompé dans les valeurs prises par l'itérateur (valeur de départ par exemple)</td><td>B. Déterminer si une (ou plusieurs) instruction(s) du corps d'une boucle bornée utilise(nt) l'itérateur</td></tr><tr><td>(LO-FOR-Number-Iteration-Error-Under2)<br>Érreur nombre d'itérations de la boucle FOR (à un près)</td><td>La boucle s'exécute une fois de trop ou une fois de moins</td><td>B. Déterminer le nombre d'itérations à réaliser pour une boucle bornée</td></tr><tr><td>(LO-FOR-Number-Iteration-Error)<br>Érreur nombre d'itérations de la boucle FOR (>2)</td><td>La boucle ne s'exécute pas le bon nombre de fois</td><td>B. Déterminer le nombre d'itérations à réaliser pour une boucle bornée</td></tr><tr><td>(LO-WHILE-Number-Iteration-Error-Under2)<br>Érreur nombre d'itérations de la boucle WHILE (à un près)</td><td>La boucle s'exécute une fois de trop ou une fois de moins</td><td>B. Déterminer le nombre d'itérations à réaliser pour une boucle bornée</td></tr><tr><td>(LO-WHILE-Number-Iteration-Error)<br>Érreur nombre d'itérations de la boucle WHILE (>2)</td><td>La boucle ne s'exécute pas le bon nombre de fois</td><td>B. Déterminer le nombre d'itérations à réaliser pour une boucle bornée</td></tr><tr><td>(LO-Exit-Condition-Error-Start)<br>Érreur condition d'arrêt de la boucle : départ</td><td>Érreur liée à la condition de départ</td><td>B. Déterminer la condition d'arrêt d'une boucle non bornée</td></tr><tr><td>(LO-Exit-Condition-Error-Evolution)<br>Érreur condition d'arrêt de la boucle : évolution</td><td>Érreur liée à une instruction qui n'est pas faite pour arrêter la boucle</td><td>B. Déterminer l'instruction modifiant la valeur de la condition d'arrêt d'une boucle non bornée</td></tr></tbody></table>

(suite page suivante)
<table><thead><tr><th>ERREUR</th><th>DETAILS OU EXEMPLES</th><th>TYPE(S) DE TÂCHE</th></tr></thead><tbody><tr><td>(LO-Body-Missing-Not-Present-Anywhere) Errur dans le corps de la boucle : Instruction manquante et non présente</td><td>Instruction absente dans le corps de la boucle et dans le programme</td><td>B. Déterminer les instructions à exécuter à chaque itération d'une boucle bornée<br>B. Déterminer les instructions à exécuter à chaque itération pour une boucle non bornée</td></tr><tr><td>(LO-Body-Misplaced) Errur dans le corps de la boucle : Instruction manquante et présente ailleurs dans le programme</td><td>Instruction présente ailleurs dans le programme</td><td>B. Déterminer les instructions à exécuter à chaque itération d'une boucle bornée<br>B. Déterminer les instructions à exécuter à chaque itération pour une boucle non bornée</td></tr><tr><td>(LO-Body-Error) Errur dans le corps de la boucle : Instruction erronée</td><td>Instruction présente proche de celle manquante</td><td>B. Déterminer les instructions à exécuter à chaque itération d'une boucle bornée<br>B. Déterminer les instructions à exécuter à chaque itération pour une boucle non bornée</td></tr><tr><td>(LO-For-Missing) Boucle FOR manquante</td><td>Absence d'une boucle FOR</td><td>B. Produire une boucle bornée</td></tr><tr><td>(LO-While-Missing) Boucle WHILE manquante</td><td>Absence d'une boucle WHILE</td><td>B. Produire une boucle non bornée</td></tr><tr><td colspan="3"><strong>EXPRESSIONS</strong></td></tr><tr><td>(EXP-Error-Conditional-Branch) Errur dans l'expression booléenne d'une des branches d'une IC</td><td>Test si une variable est &lt; au lieu de &le; par exemple</td><td>IC. Déterminer l'expression booléenne correspondant à une branche d'une instruction conditionnelle</td></tr><tr><td>(EXP-Error-Assignment-Variable) Errur dans l'expression affectée à une variable</td><td>Oubli d'une partie de l'expression, ou mauvais choix du signe</td><td>VA. Affecter la valeur d'une expression à une variable</td></tr><tr><td colspan="3"><strong>PROGRAMME ET ALGORITHME</strong></td></tr><tr><td>(PA-Problem-Decomposition-Algorithmic-Strategy) Errur de décomposition du problème ou mauvaise stratégie algorithmique</td><td>Le programme ne fait pas appel aux structures de contrôle attendues</td><td>P. Concevoir un algorithme permettant de réaliser une tâche t<br>A. Décomposer la tâche en sous-tâches t1...tn<br>A. Déterminer les instructions (affectations et structure de contrôles)<br>A. Ordonner et articuler les instructions (séquentialité et imbrication)</td></tr><tr><td>(PA-Misunderstanding-Task-Instructions) Errur liée à la compréhension de la consigne</td><td>Programme correct mais fait complètement autre chose que ce qui est demandé (exemple : exécuter le code de l'exemple donné)</td><td>—</td></tr><tr><td>(PA-Incomplete) Programme non terminé</td><td>Morceau de programme correct mais il manque une succession d'instructions</td><td>A. Déterminer les instructions (affectations et structure de contrôles)</td></tr></tbody></table>

(suite page suivante)
<table><thead><tr><td>ERREUR</td><td>DETAILS OU EXEMPLES</td><td>TYPE(S) DE TÂCHE</td></tr></thead><tbody><tr><td>(PA-Not-Optimized)<br/>Programme non optimisé</td><td>Fait la tâche demandée, mais de manière plus longue (redondance, non utilisation de boucles ou de fonctions)</td><td>P. Optimiser un programme<br/>A. Modifier un algorithme existant pour répondre à des contraintes particulières</td></tr></tbody></table>