Pour cet exercice, *AlgoInit* a bien classé la plupart des solutions (correctes et incorrectes) à une exception près. Nous allons maintenant étudier les différents résultats pour confirmer le comportement d'AlgoInit.

a) Exercice 2 : Vrais Positifs (VP)

Dans cet exercice nous observons que 16 solutions sont des vrais positifs (solution évaluée par *AlgoInit* et l'enseignant comme solution correcte). Nous avons trouvé deux solutions différentes rendues par les apprenants (figure 7-2). Nous avons trouvé dix solutions décrites comme la première solution (figure 7-2 : gauche) et six solutions décrites comme la deuxième solution (figure 7-2 : droite). Sur ce résultat, nous soulignons qu'AlgoInit arrive à détecter des solutions décrites différemment (ordre des instructions différent). Cette reconnaissance est faite grâce à une seule solution modèle contrairement aux systèmes étudiés dans l'état de l'art qui nécessitent un modèle pour chaque type de solution.

<figure><img src="image_51.png" /><figcaption>Figure 7-2: [Exercice 2] Deux solutions différentes, catégorisées Correcte par AlgoInit</figcaption></figure>

b) Exercice 2 : Vrais Négatifs (VN)

Nous observons que 13 solutions sont classées vrais négatifs (solution évaluées par *AlgoInit* et l'enseignant comme solutions incorrectes). Parmi ces solutions, les erreurs détectées peuvent être catégorisées comme suit :
- **Instructions non mise en œuvre par les étudiants** : 8 solutions. La figure 7-3 montre des exemples de cette catégorie. Dans le premier cas, *AlgoInit* a détecté que l'étudiant a oublié l'instruction qui vérifie l'heure (figure 7-3 : gauche). Cette instruction permet de vérifier si l'heure est égale à 24, si c'est le cas la variable heure doit être affectée à 0. Dans le deuxième cas, *AlgoInit* a détecté que l'étudiant a oublié de mettre en œuvre les instructions qui vérifient les secondes, minutes et heures (figure 7-3 : droite).

- **Instructions mal placées** : 3 solutions. La figure 7-4 (gauche) montre un exemple de cette catégorie.

- **Instruction non mise en œuvre par les étudiants et avec des instructions mal placées** : 2 solutions. La figure 7-4 (droite) montre un exemple de cette catégorie.

<figure><img src="image_52.png" /><figcaption>Figure 7-3: [Exercice 2] solution avec erreur (manque des instructions)</figcaption></figure>
<figure><img src="image_53.png" /><figcaption>Figure 7-4: [Exercice 2] solution avec erreur (manque des instructions + instructions mal placées)</figcaption></figure>

### c) Exercice 2 : Faux Négatifs (FN)

Nous observons que dans cet exercice, une solution est classée faux négatif (solution évaluée par AlgoInit comme solution incorrecte et par l'enseignant comme solution correcte). Cette solution est présentée figure 7-5. AlgoInit a évalué que toutes les instructions attendues ont bien été mise en œuvre et dans l'ordre. Toutefois, AlgoInit souligne, qu'il y a des instructions supplémentaires. L'enseignant considère que ces instructions ne faussent pas la solution qui reste correcte. Si l'enseignant juge que cette solution est correcte, il pourra l'ajouter dans la base de solutions modèles pour cet exercice.
<figure><img src="image_54.png" /><figcaption>Figure 7-5: [Exercice 2] solutions avec erreur (instruction supplémentaire)</figcaption></figure>

### 7.2.6.3 Résultat exercice 3

Cet exercice est le plus compliqué et celui qui présente la plus grande variabilité. Le résultat de la matrice de confusion est donné par le Tableau7-4. Nous observons qu'AlgoInit a reconnu 8 solutions comme correctes et 22 solutions comme incorrectes. Ainsi la précision d'AlgoInit pour la reconnaissance des solutions correctes est : $Pr \ SC = \frac{VP}{VP + FP} = \frac{8}{8 + 0} = 1$ c'est-à-dire 100%. Tandis que la précision pour la reconnaissance des solutions incorrectes est : $Pr \ SIC = \frac{VN}{VN + FN} = \frac{20}{20 + 2} = 0.91$, c'est-à-dire 91%.

<table><caption>Tableau7-4: Matrice de confusion pour l'exercice 3</caption><thead><tr><th>Expert (Enseignant)</th><th>Positif</th><th>Négatif</th></tr></thead><tbody><tr><th>AlgoInit</th><td></td><td></td></tr><tr><th>Positif</th><td>8</td><td>-</td></tr><tr><th>Négatif</th><td>2</td><td>20</td></tr></tbody></table>
Pour cet exercice, *AlgoInit* a encore une fois bien classé la plupart des solutions (correctes et incorrectes) à deux exceptions près. Nous allons maintenant étudier les différents résultats pour confirmer le comportement d'*AlgoInit*.

a) Exercice 3 : Vrais Positifs (VP)

Dans cet exercice nous observons que 8 solutions sont des vrais positifs (solution évaluée par *AlgoInit* et l'enseignant comme solution correcte). Parmi ces solutions, nous avons trouvé six écritures différentes. Cela confirme qu'*AlgoInit* arrive à détecter des solutions décrites différemment à partir d'une seule solution modèle.

b) Exercice 3 : Vrais Négatifs (VN)

Nous observons que 20 solutions sont classées en vrais négatifs (solution évaluée par *AlgoInit* et l'enseignant comme solutions incorrectes). Parmi ces solutions, les erreurs détectées peuvent être catégorisées comme suit :

- Instructions non mise en œuvre par les étudiants : 17 solutions.

- Instructions mal placées : 3 solutions.

c) Exercice 3 : Faux Négatifs (FN)

Nous observons, que dans cet exercice, deux solutions (*figure 7-6*) sont classées dans la catégorie **faux négatif** (solution évaluée par *AlgoInit* comme solution incorrecte et par l'enseignant comme solution correcte).

Pour la première solution, *AlgoInit* a détecté une instruction mal placée (*figure 7-6* : gauche). Après étude de la solution, l'enseignant considère que cette instruction ne fausse pas la solution. Pour remédier à cette erreur, l'enseignant ajoutera un nouveau modèle dans la base de solution modèle.

Pour la deuxième solution, *AlgoInit* a détecté deux types d'erreurs (*figure 7-6* : droite):
(i) des instructions supplémentaires et (ii) l'utilisation d'un boucle non attendue. Dans le paramétrage de l'exercice, l'enseignant avait indiqué que l'utilisation d'une *boucle Pour* était attendue et l'apprenant a utilisé *TantQue*. Pour cette erreur *AlgoInit*, informera l'apprenant qu'il doit utiliser la *boucle appropriée* (*boucle Pour au lieu de Tantque*). Cet exercice est donc classé dans faux négatif pour le type d'erreur instruction supplémentaire uniquement.
<figure><img src="image_55.png" /><figcaption>Figure 7-6: [Exercice 3] solution classifiée dans Faux Négatif</figcaption></figure>

### 7.2.6.4 Résultat global

Nous représentons sur le Tableau7-5, le résultat de la matrice de confusion sur l'ensemble des solutions. Nous observons qu'AlgoInit a bien reconnu 54 solutions correctes et 36 solutions incorrectes. Ainsi la précisions d'AlgoInit pour la reconnaissance des solutions correctes est de 100%. Tandis que la précision d'AlgoInit pour classer les solutions fausses est de 92% ($\frac{33}{33+3} = 0.92$).

<table><caption>Tableau7-5: Matrice de confusion pour les trois exercices</caption><thead><tr><th>Expert (Enseignant)</th><th>Positif</th><th>Négatif</th></tr></thead><tbody><tr><th>AlgoInit</th><td></td><td></td></tr><tr><th>Positif</th><td>54</td><td>-</td></tr><tr><th>Négatif</th><td>3</td><td>33</td></tr></tbody></table>
### 7.2.7 Synthèse

Cette première expérimentation avait pour but de valider le mécanisme d'évaluation des solutions algorithmiques par *AlgoInit*. Cette étape était nécessaire pour s'assurer d'une bonne reconnaissance qui va servir de base à la rétroaction et à la sélection des exercices suivants.

Pour cette validation, nous avons choisi trois exercices de niveaux de difficulté croissants selon les trois premiers niveaux de la taxonomie de Bloom. Cela nous a permis de confronter *AlgoInit* à des niveaux de variabilité et de complexité croissants des solutions. Nous observons que la performance d'*AlgoInit* pour la reconnaissance des solutions correctes est de 100%. Nous soulignons, la reconnaissance correcte par *AlgoInit*, des solutions écrites avec des ordres d'instructions différents.

La reconnaissance par *AlgoInit* des erreurs dans les solutions apprenants est également très importante. Nous soulignons qu'*AlgoInit* a raté 3 solutions sur les 36 solutions classifiées comme fausses. Ce défaut peut être corrigé en enrichissant la base des solutions modèles. Toutefois, *AlgoInit* arrive à bien identifier les erreurs de conception dans les solutions algorithmiques des apprenants comme : (i) des instructions attendues, non mises en œuvre ; (ii) des instructions attendues mises en œuvre mais au mauvais endroit ; ou (iii) l'utilisation d'un concept inapproprié. Dans le cas où il y a des instructions supplémentaires, la solution peut quant même être correcte. Pour cela, l'enseignant vérifie la solution, et dans le cas où celle-ci est correcte, elle sera ajoutée dans la base des solutions modèles.

Dans la suite, nous présentons une deuxième expérimentation, qui elle, vise à évaluer l'apport de l'assistance fournie par *AlgoInit* suite à la détection des erreurs.
## 7.3 Expérimentation #2 : Analyse de l'impact et de l'utilisabilité d'AlgoInit

### 7.3.1 Objectif de l'expérimentation

Notre première expérimentation nous a permis de valider la capacité d'AlgoInit à reconnaître les erreurs dans les solutions apprenants. Cette détection d'erreurs a pour objectif de permettre à AlgoInit de leur offrir des rétroactions pertinentes et une série d'exercices de niveaux de difficulté cognitive croissants. L'objectif de cette deuxième évaluation est de mesurer l'impact d'AlgoInit sur l'apprentissage des apprenants. Dans cet objectif, nous allons traiter dans cette section les questions suivantes :

1. Quel est l'impact des rétroactions fournies par AlgoInit sur le processus de résolution des exercices ?

2. Quel est l'impact de l'utilisation d'AlgoInit sur les capacités de résolution des problèmes des apprenants ?

3. Comment les apprenants évaluent-ils l'utilisabilité d'AlgoInit ?

Dans la suite, nous commencerons par la présentation du contexte d'expérimentation. Nous aborderons ensuite les trois questions posées ci-dessus.

### 7.3.2 Contexte de l'expérimentation

Cette expérimentation a été réalisée dans le même contexte que l'expérimentation précédente (cours de première année de DUT Génie Électrique et Informatique Industrielle de l'IUTI de l'université de Djibouti) et avec les mêmes étudiants. Pour réaliser cette expérimentation, nous avons intégré 12 exercices dans le système AlgoInit. La répartition des exercices dans les différents niveaux est donnée dans le Tableau 7-6.

Cette expérimentation s'est déroulée en 2 séances de 1h30 chacune. Pour cette expérimentation, nous avons activé dans le prototype le conditionnement du passage d'un exercice à un autre et la génération des rétroactions. Nous avons, également expliqué aux étudiants que l'environnement leur affecterait des exercices à résoudre et qu'en cas de non résolution, des rétroactions leurs seraient fournies.
<table><caption>Tableau 7-6: Répartition des différents exercices</caption><thead><tr><td>Taxonomie</td><td>Niveau de difficulté</td><td>Concept mis en œuvre / objectif</td><td>Nombre d'exercices</td></tr></thead><tbody><tr><td>Connaissance</td><td>1</td><td>Variables, affectation.</td><td>1</td></tr><tr><td>Connaissance</td><td>2</td><td>Structure conditionnelle.</td><td>2</td></tr><tr><td>Connaissance</td><td>3</td><td>Structures conditionnelles imbriqués.</td><td>2</td></tr><tr><td>Connaissance</td><td>4</td><td>Structure itérative.</td><td>2</td></tr><tr><td>Compréhension</td><td>1</td><td>Différencier l'utilisation des structures conditionnelles et structures conditionnelles imbriquées.</td><td>1</td></tr><tr><td>Compréhension</td><td>2</td><td>Utilisation de la structure répétitive appropriée.</td><td>1</td></tr><tr><td>Application</td><td>1</td><td>Utilisation de multiples concepts (structure conditionnelle + structure répétitive) pour résoudre un exercice.</td><td>3</td></tr></tbody></table>

### 7.3.3 Question 1 : quel est l'impact des rétroactions fournies par AlgoInit ?

Nous nous intéressons ici à vérifier l'effet des rétroactions fournies par AlgoInit aux apprenants dans le cas où ces derniers n'arrivent pas à résoudre un exercice. Nous présentons d'abord les traces collectées ainsi que notre méthodologie d'analyse des données. Nous rendons ensuite compte des résultats de l'évaluation.

#### 7.3.3.1 Collecte et méthodologie d'analyses de données

Pour traiter cette première question, nous nous basons sur les données obtenues grâce aux traces des étudiants (solutions soumises) et les rétroactions obtenues par les apprenants durant la réalisation des différents exercices. Nous obtenons ainsi pour chaque essai non fructueux une rétroaction spécifique.

Pour vérifier l'impact de la rétroaction fournie par AlgoInit, nous étudions l'effet de cette rétroaction sur l'essai suivant.

Nous définissons ci-dessous une **rétroaction à effet positif (RP)** et une **rétroaction sans effet (RSE)** et nous illustrons ces effets sur la figure 7-7.
**Définition 1** : une rétroaction est qualifiée comme ayant un effet positif (RP) : (i) si la rétroaction générée a permis à l'apprenant de résoudre l'exercice à l'essai suivant (figure 7-7: cas 1) ou (ii) si la rétroaction fournie lors de l'essai suivant est différente de celle de l'essai courant (figure 7-7: cas 2).

**Définition 2** : une rétroaction est qualifiée comme étant sans effet (RSE), si elle n'a engendré aucune amélioration sur la résolution de l'exercice à l'essai suivant (i.e., même rétroaction) (figure 7-7: cas 3).

<figure><img src="image_56.png" /><figcaption>Figure 7-7: Illustration des effets de rétroaction pour un exercice</figcaption></figure>

Nous calculons par la suite la fréquence des rétroactions qui ont eu un effet positif (RP) et des rétroactions qui ont été sans effet (RSE) pour chaque étudiant durant leur résolution de l'ensemble des exercices.

Pour chaque exercice, l'étudiant reçoit des rétroactions à chaque essai. Pour cela, nous calculons le taux des rétroactions à effet positif (RP) et de rétroactions sans effet (RSE), pour chaque étudiant comme suit :

$$RP = \sum_{i=1}^{n} \frac{NRPi}{NRi} \qquad RSE = \sum_{i=1}^{n} \frac{NRSEi}{NRi}$$

Ou :

**NRP** : Nombre de rétroactions positive pour ième exercice.

**NRSE** : Nombre de rétroactions sans effet pour ième exercice.

**NR** : Nombre de rétroactions obtenues pour ième exercice.

i : 1, 2, 3...N exercice.

Nous avons également soumis aux étudiants un questionnaire à la fin de l'expérimentation lors de la deuxième séance. Ce questionnaire (Tableau 7-8) avait pour objectif de recueillir le ressenti des étudiants sur l'apport des rétroactions fournies par AlgoInit.
### 7.3.3.2 Résultats

Nous avons calculé les taux de rétroactions à effet positif (RP) et de rétroactions sans effet (RSE) pour l'ensemble des étudiants. Ce résultat est représenté au Tableau 7-7. Nous observons, que la fréquence des rétroactions ayant un effet positif est largement plus importante (84%) que les rétroactions sans effet (16%).

<table><caption>Tableau 7-7: Résultat des fréquences des effets des rétroactions fournies par AlgoInit</caption><thead><tr><th></th><th>RP</th><th>RSE</th></tr></thead><tbody><tr><td>Fréquence</td><td>84 %</td><td>16%</td></tr></tbody></table>

Les réponses au questionnaire (Tableau 7-8) corroborent les résultats de l'analyse des traces. En effet, les étudiants ont jugé les rétroactions compréhensibles (96%) et 80% d'entre eux pensent que les rétroactions les ont aidés à corriger leurs erreurs.

<table><caption>Tableau 7-8: Questionnaire sur le ressenti des étudiants sur les rétroactions reçues</caption><thead><tr><th>Questions</th><th>Oui</th><th>Non</th></tr></thead><tbody><tr><td>Les rétroactions données sont compréhensibles et claires.</td><td>29</td><td>1</td></tr><tr><td>Les rétroactions obtenues après chaque exercice non résolu, vous ont aidé à le résoudre.</td><td>24</td><td>6</td></tr></tbody></table>

### 7.3.4 Question 2 : quel est l'impact de l'utilisation d'AlgoInit sur les capacités de résolution des problèmes des apprenants ?

Par cette question nous cherchons à évaluer l'impact de l'utilisation d'AlgoInit sur la capacité de résolution des problèmes des apprenants. Pour vérifier cela, nous présentons d'abord la collecte et la méthodologie d'analyse des données et par la suite le résultat de l'évaluation.

#### 7.3.4.1 Collecte et méthodologie d'analyse des données

Pour répondre à cette question, nous avons comparé les notes obtenues, après un test, par les apprenants du groupe ayant utilisé AlgoInit (Groupe 1) avec celles d'un groupe contrôle qui n'a pas utilisé l'environnement (Groupe 0). Ce dernier groupe a été constitué selon les mêmes critères que pour le groupe 1, à savoir 10 étudiants faibles, 10 moyens et 10
forts. Le groupe de contrôle (Groupe 0) a fait deux séances TD (sur les mêmes exercices) de 1h30 chacune, avec un enseignant.

Les étudiants de deux groupes ont par la suite été soumis à un test comportant trois exercices. Nous avons indiqué aux étudiants que le test serait noté afin de nous assurer qu’il soit fait sérieusement. La correction a été faite par un seul enseignant et nous avons récupéré par la suite les notes de ces 60 étudiants.

Nous calculons ensuite la moyenne de chaque groupe (Groupe 1 et Groupe 0). L'objectif est de comparer ces moyennes afin de vérifier s'il y a une différence et déterminer si cette différence est significative.

Pour vérifier cela, nous utilisons un test statistique, le **test t de Student**. Selon (Ramousse, Le Berre, & Le Guelte, 1996), ce test statistique repose sur la comparaison des moyennes de deux échantillons indépendants avec des données quantitatives. Ce test donne une décision statistique par un rejet ou non de l'hypothèse nulle (hypothèse qui suppose qu'il n'y a pas une différence significative entre les deux moyennes comparées). Pour utiliser ce test, (Ramousse et al., 1996) recommandent de vérifier : (i) le test de normalité et (ii) l'homogénéité des variances dans les deux échantillons. Si ces deux conditions sont vérifiées, alors le **test t de student** peut être utilisé.

Pour interpréter le résultat il faudra formuler deux hypothèses : H0 (hypothèse nulle) et H1. Ainsi nous formulons les hypothèses suivantes :

- **H0** : il n'y a pas une différence significative entre la moyenne du Groupe 1 et du Groupe 0.

- **H1** : il y a une différence significative entre la moyenne du Groupe 1 et du Groupe 0.

Pour analyser le résultat, nous avons utilisé le logiciel R.

### 7.3.4.2 Résultat

Pour nous assurer que ce test est valable sur nos données, nous avons donc réalisé les vérifications suivantes :

- dans une première étape, nous avons vérifié le test de normalité en utilisant le logiciel R, ce résultat à été positif.
- Dans une deuxième étape, nous avons vérifié l'homogénéité des variances dans les deux échantillons, ce résultat s'est également avéré positif.

Suite aux résultats positifs de deux étapes ci-dessus, nous avons effectué le **test t** **student** sur le logiciel R, le résultat est représenté sur la figure 7-8.

Welch Two Sample t-test
data:  notes by gr
t = -2.6671, df = 54.722, p-value = 0.01004
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
-3.6780933 -0.5219067
sample estimates:
mean in group 0 mean in group 1
9.95 12.05

<caption>Figure 7-8 : Résultat de t-test (test student) sur les notes de deux groupes</caption>

La moyenne du groupe 0 (groupe contrôle) est de 9,95. Celle du groupe 1 est de 12,05.

Ce qui nous donne une différence non négligeable de 2,55 points. Le *test t* nous montre que l'hypothèse *H0* est rejetée et nous donne surtout comme résultat une valeur *p* = *0,01*. Cette valeur est bien inférieure à la valeur généralement acceptée (*p* < *0,05*). Cela nous permet d'affirmer que cette différence de moyenne entre les deux groupes est significative et nous permet de conclure que l'utilisation d'*AlgoInit* a très certainement eu un impact positif sur la moyenne obtenue par le groupe qui l'a utilisé.

### 7.3.5 Question 3 : comment les apprenants évaluent l'utilisabilité d'AlgoInit ?

Nous nous intéressons à travers cette question à l'utilisabilité d'*AlgoInit*. Pour vérifier cela, nous présentons d'abord la méthodologie pour évaluer l'utilisabilité et par la suite le résultat de l'évaluation.

#### 7.3.5.1 Collecte et méthodologie d'analyse des données

Pour évaluer l'utilisabilité, nous avons utilisé le questionnaire SUS (*System Usability Scale*). C'est un outil standard, simple, rapide à remplir et facile à comprendre pour les utilisateurs (Bangor, Kortum, & Miller, 2009). Il est largement utilisé pour évaluer l'utilisabilité des systèmes. Le questionnaire comprend dix items, qui permettent de
déterminer le niveau de satisfaction des utilisateurs d'un système. Ce niveau de satisfaction peut être exprimé sur une échelle de Lickert à cinq niveaux allant de « Pas du tout d'accord » à « Tout à fait d'accord ».

Pour que le questionnaire SUS soit interprétable, (Tullis & Stetson, 2004) recommandent au moins 12 participants au sondage. Pour mesurer l'utilisabilité d'AlgoInit, nous avons 30 participants. Le questionnaire SUS, présenté dans le Tableau 7-9, a été distribué aux étudiants dès la fin de la deuxième séance de la deuxième expérimentation.

Pour calculer le score SUS, on procède comme suit (Bangor et al., 2009) : (i) pour les items impairs (1, 3, 5, 7 et 9) on soustrait un point au score donné par l'utilisateur. Par exemple si l'utilisateur coche 3 le score est de 3-1=2 ; (ii) pour les items pairs (2, 4, 6, 8 et 10) on calcule cinq moins le score donné par l'utilisateur. Par exemple si l'utilisateur coche 1 (pas du tout d'accord) le score est de 5-1=4 ; (iii) on additionne les scores ainsi calculés pour obtenir un total sur 40. Par la suite on multiple ce score par 2,5 pour obtenir un score sur 100. Une fois le score final obtenu pour chaque utilisateur, nous calculons la moyenne de tous ces scores. Cette moyenne représente le score SUS obtenu par notre système.

Pour interpréter le résultat (score SUS) ainsi obtenu, nous avons utilisé la plage d'acceptabilité d'un système proposé par (Bangor et al., 2009) présenté figure 7-9.

<table><caption>Tableau 7-9: Questionnaire SUS</caption><tr><td>1.</td><td>Je pense que j'aimerais utiliser ce système fréquemment</td></tr><tr><td>2.</td><td>J'ai trouvé ce système inutilement complexe.</td></tr><tr><td>3.</td><td>J'ai trouvé ce système facile à utiliser.</td></tr><tr><td>4.</td><td>Je pense que j'aurais besoin d'un support technique pour être capable d'utiliser ce système</td></tr><tr><td>5.</td><td>J'ai trouvé que les différentes fonctions de ce système étaient bien intégrées.</td></tr><tr><td>6.</td><td>J'ai trouvé qu'il y avait trop d'incohérences dans ce système.</td></tr><tr><td>7.</td><td>Je suppose que la plupart des gens apprendraient très rapidement à utiliser ce système</td></tr><tr><td>8.</td><td>J'ai trouvé ce système très contraignant à utiliser.</td></tr><tr><td>9.</td><td>Je me suis senti très confiant en utilisant ce système.</td></tr><tr><td>10.</td><td>J'ai dû apprendre beaucoup de choses avant de pouvoir utiliser ce système</td></tr></table>
<figure><img src="image_57.png" /><figcaption>Figure 7-9: Plage d'acceptabilité d'un système par le score SUS</figcaption></figure>

### 7.3.5.2 Résultat

Le score SUS obtenu pour AlgoInit est de 71,83. Selon la plage d'acceptabilité, AlgoInit peut être qualifié comme un « Bon » système d'après les étudiants interrogés.

## 7.3.6 Synthèse

Après une première expérimentation dédiée à l'efficacité de notre système, cette deuxième expérimentation était orientée sur son intérêt pédagogique. Nous avons cherché à évaluer cet intérêt selon trois axes : l'impact des rétroactions fournies par AlgoInit, l'impact global sur les résultats des étudiants ainsi que l'utilisabilité du système.

En ce qui concerne le premier axe, *l'impact des rétroactions*, l'analyse des traces ainsi que les retours des étudiants nous indiquent un effet positif encourageant. Sur cet axe, nous nous sommes limités à vérifier si les rétroactions générées suite à une détection d'erreurs, permettait à l'apprenant de corriger celles-ci. Nous pourrons dans une expérimentation de longue durée avec plus d'exercices évaluer l'effet de ces rétroactions entre les différents exercices d'une même famille et l'effet de ces rétroactions sur les différents niveaux de difficultés.

Nous avons comparé la moyenne des notes obtenues par le groupe ayant utilisé AlgoInit et celle d'un groupe contrôle assisté par un enseignant pour répondre à la deuxième question. L'analyse statistique de ces résultats a montré que l'utilisation d'AlgoInit a une influence significative sur les notes. Bien que le résultat obtenu pour cette question soit positif et encourageant, il nous semble raisonnable de mener des expérimentations sur des longues périodes afin de confirmer le résultat obtenu.
Enfin, nous avons utilisé le questionnaire System Usability Scale (SUS) pour évaluer l'utilisabilité d'AlgoInit, le résultat de ce test est plutôt correct avec un score supérieur à 71/100 indiquant une bonne utilisabilité.
# Conclusion générale

## Bilan

Dans le cadre de cette thèse, nous avons abordé la question de l'amélioration des connaissances stratégiques des apprenants dans les cours d'introduction à la programmation. L'objectif est de consolider leur capacité à utiliser les concepts appropriés lors de la résolution de problèmes de programmation. Pour arriver à cet objectif la littérature recommande que l'apprenant réalise de nombreux exercices avec des niveaux de difficulté croissants. La littérature a également souligné qu'à cause du nombre important d'apprenants et de l'hétérogénéité des niveaux, les enseignants ont des difficultés à vérifier l'exactitude de leurs solutions et à fournir l'assistance nécessaire.

Nous nous sommes donc attachés à identifier un processus d'évaluation qui permet de détecter rapidement les erreurs des apprenants, de les assister dans la correction de ces erreurs et qui serve de support pour proposer différents exercices de niveaux progressifs.

Notre problématique s'est donc axée sur trois points : comment évaluer la solution algorithmique pour que la détection d'erreur soit significative ? Comment assister ou accompagner un apprenant qui a une difficulté pour résoudre un exercice ? Et enfin, comment organiser les exercices en niveaux de difficulté croissants permettant une progression de l'apprenant ?

Pour répondre à la première question, **nous avons proposé une approche d'évaluation**, qui permet de détecter les erreurs de conception des apprenants et de leur associer une signification. Ce processus est basé sur la comparaison des solutions algorithmiques des apprenants à des solutions modèle préparées par l'enseignant. Cette comparaison est réalisée en deux étapes. La première étape consiste à transformer les solutions (apprenant et modèle) en des arbres étiquetés. Chaque nœud de cet arbre est représenté par une étiquette qui traduit la signification d'une ligne d'instruction. Pour construire les étiquettes de chaque instruction, nous avons défini une base de règles en collaboration avec les enseignants de l'université de Djibouti. Une fois les solutions standardisées, la deuxième étape consiste à comparer les deux arbres étiquetés pour statuer sur la solution de l'apprenant (correcte ou incorrecte). Selon le score de l'apprenant un état (**faible, moyen, bon**) de résolution de l'exercice est affecté dans le profil de l'apprenant.
Notre contribution par cette approche d'évaluation, se présente comme un moyen de diagnostiquer les erreurs de conception des apprenants sans nous appuyer sur des solutions modèle avec erreur. Cette approche propose également un moyen de réduire le nombre de solutions modèles.

Pour répondre à la deuxième question, **nous avons proposé un mécanisme de génération des rétroactions**. Celles-ci sont de deux types : (i) une rétroaction communiquant à l'apprenant une explication sur la façon de résoudre l'exercice. Elle est paramétrée par l'enseignant et est fournie à l'apprenant dans le cas où le nombre d'erreurs dans la solution dépasse un seuil significatif ; (ii) une rétroaction communiquant à l'apprenant ses erreurs. Le contenu de cette rétroaction est construit en se basant sur un type d'erreur et les étiquettes construites lors de l'évaluation. Pour énumérer les erreurs de l'apprenant selon des phrases compréhensibles, nous utilisons une base de règles qui transforme les étiquettes en des phrases (contenu de la rétroaction).

Pour répondre à la dernière question, **nous avons proposé un modèle d'organisation des exercices**. Nous avons organisé nos exercices selon les trois premiers niveaux cognitifs de la taxonomie de Bloom. Dans chaque niveau cognitif, nous répartissons nos exercices en niveaux de difficulté selon le concept qu'il met en œuvre. Pour chaque niveau de difficulté on peut proposer plusieurs exercices afin de favoriser l'acquisition des compétences liées à l'utilisation de ces concepts.

En nous basant sur ces modèles et algorithmes, **nous avons développé un environnement Web nommé AlgoInit**. C'est dans cet environnement que nous avons réifié nos propositions. Ceci nous a également permit d'évaluer nos propositions à travers des expérimentations en milieu écologique.

Nous avons ainsi mené deux expérimentations : une première qui était destinée à évaluer l'efficacité de notre approche d'évaluation et une autre orientée sur l'intérêt pédagogique de notre système.

Pour la première expérimentation, nous nous sommes inspirés des méthodologies d'évaluation des systèmes de recommandation. Dans ce cadre, nous avons utilisé une matrice de confusion pour étudier la précision d'AlgoInit, c'est-à-dire sa capacité à reconnaître des solutions correctes et incorrectes. Pour cela, nous avons comparé l'évaluation réalisée par notre environnement et celle d'un enseignant à travers 3 exercices. Le résultat de cette évaluation nous a montré que notre environnement arrivait à reconnaître avec une précision de 100% les solutions correctes. En ce qui concerne les solutions incorrectes, le taux de
reconnaissance est de 92%. L'analyse a montré que les cas où AlgoInit n'a pas reconnu une solution correcte correspondaient à des cas où il y a des instructions supplémentaires ou placées au mauvais endroit par rapport à la solution modèle.

Pour la deuxième expérimentation, nous avons cherché à évaluer l'intérêt pédagogique à travers trois axes : l'impact des rétroactions fournies par notre environnement, l'impact global sur les résultats des étudiants ainsi que l'utilisabilité du système.

En ce qui concerne, le premier axe, *l'impact des rétroactions*, nous avons cherché à évaluer l'apport des rétroactions générées par notre système sur la correction faite par les apprenants suite à des erreurs relevées dans leurs solutions. Pour évaluer ceci, nous nous sommes basé sur l'analyse des traces des solutions soumises par les apprenants suites aux rétroactions et sur des questionnaires soumis aux apprenants à la fin de l'expérimentation. Le résultat de cette évaluation à été généralement positif.

En ce qui concerne, le deuxième axe, *l'impact global sur les résultats des étudiants*, nous avons cherché à évaluer l'apport de l'utilisation de notre environnement sur les résultats des étudiants. Pour évaluer ceci, nous avons comparé les moyennes des notes obtenues par deux groupes : un groupe ayant utilisé notre environnement et un groupe témoin qui ne l'a pas utilisé. Le résultat de l'analyse statistique a indiqué que notre environnement a une influence significative sur les résultats des étudiants.

Pour le dernier axe concernant, *l'utilisabilité d'AlgoInit*, nous avons utilisé le classique questionnaire *System Usability Scale* (SUS). Le résultat est correct avec un score indiquant une bonne utilisabilité (71%). Nous avons toutefois des pistes d'amélioration immédiates suite aux discussions avec les apprenants (affichage des rétroactions, reprise de la solution erronée...).

## Perspectives

Nos principales perspectives pour ce travail sont liées à un souhait d'amélioration de notre environnement *AlgoInit* et une volonté d'améliorer nos propositions (approche d'évaluation, assistance et organisation des exercices) ainsi qu'une perspective d'expérimentation. Nous présentons ici ces principaux souhaits d'amélioration.
## Perspectives expérimentales

A moyen terme, afin de renforcer nos premiers résultats, nous envisageons de mener une expérimentation à plus large échelle : d'abord avec un nombre important d'étudiants (environ 200 étudiants) ; ensuite avec une grande quantité d'exercices et la possibilité d'utiliser l'environnement à distance (afin de permettre aux étudiants de continuer à l'utiliser en dehors de l'université). L'ajout d'exercices nous permettra de valider et d'enrichir si nécessaire notre base de règles.

Du point de vue expérimental, cela nous permettra :

- De mener une analyse plus fine de l'impact des rétroactions sur la capacité de résolution de problème. Dans cette analyse, nous cherchons à vérifier le nombre de rétroactions entre les différents niveaux et le nombre de rétroactions entre les différents exercices de même famille. Cela nous permettra de percevoir l'acquisition des concepts par les apprenants si le nombre de rétroactions liées à un concept donné tend à diminuer ;

- D'effectuer une évaluation pré/post des capacités de résolutions de problèmes des apprenants ;

- D'évaluer la capacité des apprenants à transposer les solutions algorithmiques dans divers langages de programmation. Dans cette évaluation nous mettrons en œuvre un moyen de récupérer les traces d'exécution des programmes des apprenants.

## Perspectives de recherche

Notre modèle de sélection des exercices est relativement linéaire et constitue une progression à travers les différents niveaux de concepts et de difficulté. Il nous semble intéressant de réfléchir à une progression plus personnalisée incluant des exercices de remédiation. Cette réflexion implique un travail selon trois axes :

- Un premier axe porte sur la diversification des formes d'exercices. Ces exercices seront sélectionnés selon le niveau de l'apprenant et ses résultats. Cela nous amène à une réflexion sur une approche d'évaluation générique, qui doit être capable d'évaluer différentes formes d'exercices (QCM, résoudre un exercice, question à trou, lire un code...).
- Cela nous conduit également à repenser notre modèle d'organisation des exercices afin d'intégrer les remédiations, de telle sorte que chaque apprenant puisse suivre un chemin d'exercice adapté selon son niveau.

- La personnalisation des parcours met en exergue la question de la modélisation de l'apprenant. Pour cela le système doit tenir compte des besoins, des connaissances ainsi que l'historique de résolution des exercices des apprenants. Ainsi il existe plusieurs approches pour construire le modèle apprenant (Chrysafiadi & Virvou, 2013). dans cette perspective il s'agit de répondre à la question : Comment représenter l'apprenant afin de l'aider ou l'assister dans ses difficultés ? Dans cette question nous chercherons à mettre en œuvre un modèle de prise de décision qui se basera sur le modèle apprenant pour générer l'assistance adéquate ainsi que l'exercice suivant.

Une autre perspective à plus long terme, concerne un changement du contexte d'utilisation. Nous envisageons d'étendre l'utilisation de notre outil dans l'enseignement secondaire (lycée) à Djibouti où l'algorithmique est intégrée au programme de mathématiques de la seconde à la terminale. Cela soulève la question de l'utilisation d'un langage visuel type Scratch pour aborder les notions d'algorithmique et du passage graduel aux langages textuels : en pseudo-code puis dans un langage de programmation. Pour cette perspective nous pouvons nous inspirer des travaux de (Muratet, 2010).
Annexe
# A. Base de règles

Les règles sont exprimées à partir des catégories d'instructions présentés page 72. La base de règles représentées ci-dessous est celle que nous avons utilisée lors de nos différentes expérimentations.

<table><thead><tr><td>Étiquette</td><td>Condition</td></tr></thead><tbody><tr><td>Incrementation</td><td>Si la ligne est composée d'une variable, un OE (affectation), la même variable que celle identifiée premièrement, un OA(+) et une valeur ou variable.</td></tr><tr><td>Decrementation</td><td>Si la ligne est composée d'une variable, un OE (affectation), la même variable que celle identifiée premièrement, un OA(-) et une valeur ou variable.</td></tr><tr><td>Initialisation</td><td>Si la ligne est composée d'une variable, un OE (affectation), et une valeur.</td></tr><tr><td>Calcul</td><td>variable avec un OE (affectation) suivi d'autre variable ou valeur, ses variables et valeur sont séparés par un OA.</td></tr><tr><td>Verifie</td><td>Si la ligne contient une SC(Si).</td></tr><tr><td>VerifieImbrique</td><td>Si la ligne contient une SC(SinonSi).</td></tr><tr><td>VerifieSelon</td><td>Si la ligne contient une SC(Selon).</td></tr><tr><td>Default</td><td>Si la ligne contient une SC(Sinon).</td></tr><tr><td>Repete</td><td>Si la ligne contient une SI.</td></tr><tr><td>Donnee</td><td>Si la ligne contient un OE (Lire).</td></tr><tr><td>Afficher</td><td>Si la ligne contient un OE (Ecrire).</td></tr></tbody></table>

Toutefois cette base de règle n'est pas exhaustive et peut évoluer. Pour l'étendre, nous souhaitons collaborer avec des enseignants, de cette matière algorithmique et programmation, d'autres universités. Pour cela nous souhaitons proposer une page web où les enseignants peuvent compléter un formulaire selon le format suivant :

<table><thead><tr><td>Etiquette</td><td>Condition</td><td>Explication</td></tr></thead><tbody><tr><td></td><td></td><td></td></tr></tbody></table>

L'étiquette représente le mot à associer au nœud et la condition représente la règle associée pour générer cette étiquette. L'explication traduit en une phrase l'étiquette. Celle-ci est essentielle dans la génération des rétroactions.

Une fois que l'enseignant a complété une ou plusieurs lignes de la base de règles, il soumettra pour validation et les règles ainsi validées par la majorité des enseignants seront intégrées dans notre base de règles.
B. Exemple d'exercices modélisés

Enoncé : Réaliser un algorithme permettant à un abonné EDF de calculer lui-même le montant de sa prochaine facture trimestrielle. Chaque abonné doit payer tous les trimestres un abonnement fixe de 200 DJF et 30 DJF par KW/H consommé. Pour calculer la facture il faut donc connaître les relevés de compteur de début et fin de période.

Niveau taxonomie : Connaissance

Niveau difficulté : 1

Exercice N° : 1

Enoncé : Ecrire un algorithme qui permet de déterminer si un entier lu est pair ou impair.

Niveau taxonomie : Connaissance

Niveau difficulté : 2

Exercice N° : 1

Enoncé : Ecrire un algorithme ou programme demandant la saisie d'une valeur entière et affiche ensuite si cette valeur est un multiple de 7.

Niveau taxonomie : Connaissance

Niveau difficulté : 2

Exercice N° : 2
Enoncé : Les étudiants ayant passé l'examen d'algorithmique en session de Juin ont été classés selon leurs notes en trois catégories :

- pour une note strictement inférieure à 5, l'étudiant est éliminé.

- pour une note supérieure ou égale à 5 et strictement inférieur à 10, l'étudiant passe la session de rattrapage.

- pour une note supérieure ou égale à 10, l'étudiant valide le module.

Ecrivez un algorithme qui demande à l'utilisateur d'entrer la note du module et affiche la situation de l'étudiant selon sa note.

Niveau taxonomie : Connaissance

Niveau difficulté : 3

Exercice N° : 1

Enoncé : Ecrire un algorithme qui affiche le mois en toute lettre selon son numéro en utilisant la structure conditionnelle *Selon*.

Niveau taxonomie : Connaissance

Niveau difficulté : 3

Exercice N° : 2

Enoncé : Ecrire un algorithme qui demande un nombre de départ, et qui calcule la somme des entiers jusqu'à ce nombre en utilisant le boucle Pour. Par exemple, si l'on entre 5, le programme doit calculer :
1 + 2 + 3 + 4 + 5 = 15

Niveau taxonomie : Connaissance

Niveau difficulté : 4

Exercice N° : 1
**Enoncé :** Écrire un algorithme qui fait la somme des données saisie par l'utilisateur, la saisie des nombres s'arrête lorsque l'utilisateur saisie un 0.

**Niveau taxonomie :** Connaissance

**Niveau difficulté :** 4

**Exercice N° :** 2

**Enoncé :** Ecrire un algorithme qui demande un nombre à l'utilisateur, et l'informe ensuite si ce nombre est positif, négatif ou nul.

**Niveau taxonomie :** Compréhension

**Niveau difficulté :** 1

**Exercice N° :** 1

**Enoncé :** On place un capital de 500DJF sur un compte rémunéré à 3% par an. Ecrire un algorithme qui permet de calculer le nombre d'années au bout desquelles le capital sera doublé.

**Niveau taxonomie :** Application

**Niveau difficulté :** 1

**Exercice N° :** 1

**Enoncé :** Écrire un algorithme qui demande deux entiers A et N. Ensuite l'algorithme lit la liste de N nombres entiers saisie par l'utilisateur. L'algorithme doit afficher combien de fois l'entier A apparaît dans cette liste.

**Niveau taxonomie :** Application

**Niveau difficulté :** 1

**Exercice N° :** 2
Bibliographie

ACM, AIS, & IEEE. (2005). *Computing Curricula 2005, the overview Report*. New York.

Ala-Mutka, K. (2005). A survey of automated assessment approaches for programming assignments. *Computer Science Education, 15*(2), 83–102.

Ala-Mutka, K., Uimonen, T., & Järvinen, H.-M. (2004). Supporting students in C++ Programming Courses with Automatic Program Style Assessment. *Journal of Information Technology Education, 3*(1), 245–262.

Altadmri, A., & Neil, C. B. (2015). 37 million compilations: Investigating novice programming mistakes in large-scale student data. In *Proceedings of the 46th ACM Technical Symposium on Computer Science Education* (pp. 522–527).

Amir, O., & Ya'akov, K. (2013). Plan Recognition and Visualization in Exploratory Learning Environments. *ACM Transactions on Interactive Intelligent Systems (TiiS)*, 3(3), 16.

Anderson, L. W., Krathwohl, D. R., Airasian, P. W., Cruikshank, K. A., Mayer, R. E., Pintrich, P. R., ... Wittrock, M. C. (2001). *A taxonomy for learning, teaching, and assessing: A revision of Bloom's taxonomy of educational objectives*. New York: Longman.

Arifi, S. M., Abdellah, I. N., Zahi, A., & Benabbou, R. (2015). Automatic program assessment using static and dynamic analysis. In *Third world Conference on Complex Systems (WCCS) (pp. 1–6)*.

Bangor, A., Kortum, P., & Miller, J. (2009). Determining what individual SUS scores mean: Adding an adjective rating scale. *Journal of Usability Studies, 4*(3), 114–123.

Beaubouef, T., Lucas, R., & Howatt, J. (2001). The UNLOCK system: enhancing problem solving skills in CS-1 students. *ACM SIGCSE Bulletin, 33*(2), 43–46.

Beaubouef, T., & Mason, J. (2005). Why the High Attrition Rate for Computer Science Students: Some Thoughts and Observations. *ACM SIGCSE Bulletin, 37*(2), 103–106.

Bennedsen, J., & Caspersen, M. E. (2007). Failure rates in introductory programming. *ACM SIGCSE Bulletin, 39*(2), 32–36.

Bergin, S., & Reilly, R. (2006). Predicting introductory programming performance: A multi-institutional multivariate study. *Computer Science Education, 16*(4), 303–323.
Bey, A., & Bensebaa, T. (2011). ALGO+, an assessment tool for algorithmic competencies. In *Global Engineering Education Conference (EDUCON). IEEE* (pp. 941–946).

Bloom, B. S. (1956). Taxonomy of educational objectives. Vol. 1: Cognitive domain. *New York: Mckay*, 20–24.

Bloom, B. S. (1971). Mastery learning: Theory and practice. *New York: Holt, Rinehart & Winston.*, 47–63.

Bosc-Miné, C. (2014). Caractéristiques et fonctions des feed-back dans les apprentissages. *L'Année Psychologique*, **114**(2), 315–353.

Boud, D., & Molloy, E. (2013). *Feedback in higher and professional education: understanding it and doing it well*. (eds, Ed.). London : Routledge.

Bouhineau, D. (2013). Utilisation de traits sémantiques pour une méthodologie de construction d'un système d'aide dans un EIAH de l'algorithmique. In *6e conférence sur les Environnements Informatiques pour l'Apprentissage Humain* (pp. 141–152). IRIT Press.

Carless, D. (2006). Differing perceptions in the feedback process. *Studies in Higher Education*, **31**(2), 219–233.

Chan, C. C., Tsui, M. S., Mandy, Y. C., & Hong, J. H. (2002). Applying the Structure of the Observed Learning Outcomes (SOLO) Taxonomy on Student's Learning Outcomes: An empirical study. *Assessment & Evaluation in Higher Education*, **27**(6), 511–527.

Chatzopoulou, D. I., & Economides, A. A. (2010). Adaptive assessment of student's knowledge in programming courses. *Journal of Computer Assisted Learning*, **26**(4), 258–269.

Chookaew, S., Panjaburee, P., Wanichsan, D., & Laosinchai, P. (2014). A Personalized E-Learning Environment to Promote Students' Conceptual Learning on Basic Computer Programming. *Procedia - Social and Behavioral Sciences*, **114**, 815–819.

Chrysafiadi, K., & Virvou, M. (2013). Student modeling approaches : A literature review for the last decade. *Expert Systems with Applications*, **40**(11), 4715–4729.

De Ketele, J.-M. (2010). Ne pas se tromper d'évaluation. *Revue Française de Linguistique Appliquée*, **15**(1), 25–37.

Delorme, F., Delestre, N., & Pécuchet, J.-P. (2004). Évaluer l’apprenant à l’aide de cartes conceptuelles. In *Technologies de l’Information et de la Connaissance dans l’Enseignement Supérieur et l’Industrie* (pp. 25–31).
Djelil, F. (2016). *Conception et évaluation d'un micromonde de Programmation Orientée-Objet fondé sur un jeu de construction et d'animation 3D*. Thèse de doct. Université Blaise Pascal - Clermont II.

Durand, G. (2006). *La scénarisation de l'évaluation des activités pédagogiques utilisant les Environnements Informatiques d'Apprentissage Humain*. Thèse de doct. Université de Savoie.

Eitelman, S. M. (2006). Computer tutoring for programming education. In *proceedings of the 44th annual Southeast regional conference* (pp. 607–610).

Engel, G., & Roberts, E. (2001). *Computing curricula 2001*. Computer science. The Joint Task Force on Computing Curricula, ACM Press. and IEEE Computer Society Press, New York.

Flowers, T., Carver, C. A., & Jackson, J. (2004). Empowering students and building confidence in novice programmers through Gauntlet. In *34th Annual Frontiers in Education, 2004. FIE 2004*. (pp. 10–13). https://doi.org/10.1109/FIE.2004.1408551

Fonte, D., Da Cruz, D., Gançarski, A. L., & Henriques, P. R. (2013). A flexible dynamic system for automatic grading of programming exercises. *2nd Symposium on Languages, Applications and Technologies, SLATE 2013*, 29, 129–144.
https://doi.org/10.4230/OASICS.SLATE.2013.129

Fuller, U., Johnson, C. G., Ahoniemi, T., Cukierman, D., Hernan-Losada, I., Jackova, J., ... Thompson, E. (2007). Developing a Computer Science-specific Learning Taxonomy. *ACM SIGCSE Bulletin*, *39*(4), 152–170.

Gardner-Medwin, A. R. (2006). Confidence based marking: towards deeper learning and better exams. In C. Bryan & K. Clegg (Eds.) (pp. 141–149). Innovative assessment in higher education, London : Routledge.

Geib, C. W., & Goldman, R. P. (2009). A probabilistic plan recognition algorithm based on plan tree grammars. *Artificial Intelligence*, *173*(11), 1101–1132.

Gerdes, A., Heeren, B., & Jeuring, J. (2017). Ask-Elle: an adaptable programming tutor for Haskell giving automated feedback. *International Journal of Artificial Intelligence in Education*, 27(1), 65–100.

Gomes, A., & Mendes, a. J. (2007). Learning to program - difficulties and solutions. In *International Conference on Engineering Education – ICEE*.
Gouli, E., Gogoulou, A., Papanikolaou, K., & Grigoriadou, M. (2004). COMPASS: an adaptive Web-based concept map assessment tool. In *Proceedings of the First International Conference on Concept Mapping* (pp. 295–302).

Granet, V. (2014). *Algorithmique et programmation en Java*. (Dunod, Ed.) (4 édition:).

Greiff, S., Scheiter, K., Scherer, R., Borgonovi, F., Britt, A., Graesser, A., ... Rouet, J.-F. (2017). Adaptive problem solving: Moving towards a new assessment domain in the second cycle of PIAAC. *OECD Education Working Papers* 156.

Guskey, T. R. (2007). Closing achievement gaps : revisiting Benjamin S.Bloom's "Learning for Mastering." *Journal of Advanced Academics*, 19(1), 8–31.

Hadji, C. (1990). *L'évaluation, règles du jeu* (ESF).

Harlen, W. (2007). *Assessment of Learning*. London: SAGE.

Hattie, J., & Timperly, H. (2007). The Power of Feedback. *Review of Education Research, 77*(1), 81–112.

Haydar, C. A. (2014). *Les systèmes de recommandation à base de confiance*. Thèse de doct. Université de Lorraine.

HO, C.-H. (2001). Some phenomena of problem decomposition strategy for design thinking: differences between novices and experts. *Design Studies*, 22(1), 27–45.

Ihantola, P., Ahoniemi, T., Karavirta, V., & Seppälä, O. (2010). Review of recent systems for automatic assessment of programming assignments. In *Proceedings of the 10th Koli calling international conference on computing education research* (pp. 86–93).

Inventado, P. S. (2019). Promoting Mastery Learning in an Introductory Programming Course. In *Proceedings of the 50th ACM Technical Symposium on Computer Science Education* (pp. 1285–1285).

Jackson, D., & Usher, M. (1997). Grading Student Programs using ASSYST. *ACM SIGCSE Bulletin*, 29(1), 335–339.

Jenkins, T. (2002). On The Difficulty of Learning to Program. In *Proceedings of the 3rd Annual Conference of the LTSN Centre for information and Computer Sciences*. (pp. 53–58). Retrieved from http://www.psy.gla.ac.uk/~steve/localed/jenkins.html

Jonassen, D. H. (2010). *Learning to solve problems: A handbook for designing problem-solving learning environments*. New York: Routledge.

Juwah, C. (2003). Using peer assessment to develop skills and capabilities. *United States Distance Learning Association*, 17(1), 39–50.
Kaasbøll, J. (2002). Learning Programming. University of Oslo.

Kelly, T., & Buckley, J. (2006). A Context-Aware Analysis Scheme for Bloom's Taxonomy. In *14th IEEE International Conference on Program Comprehension (ICPC'06)* (pp. 275-284).

Keuning, H., Jeuring, J., & Heeren, B. (2018). A Systematic Literature Review of Automated Feedback Generation for Programming Exercises. *ACM Transactions on Computing Education (TOCE)*, 19(1), 3.

Konecki, M. (2014). Problems in programming education and means of their improvement. *DAAAM International Scientific Book*, 2014, 459-470.

Labat, J.-M. (2002). EIAH: Quel retour d'informations pour le tuteur? In *Technologies de l'Information et de la Communication dans les Enseignements d'ingénieurs et dans l'industrie* (pp. 81-88).

Lahtinen, E., Ala-Mutka, K., & Järvinen, H.-M. (2005). A study of the difficulties of novice programmers. *ACM SIGCSE Bulletin*, 37(3), 14-18.
https://doi.org/10.1145/1151954.1067453

Lane, H. C., & VanLehn, K. (2005). Teaching the tacit knowledge of programming to novices with natural language tutoring. *Computer Science Education, 15*(3), 183-201.
https://doi.org/10.1080/08993400500224286

Le, N.-T. (2016). A classification of adaptive feedback in educational systems for programming. *Systems*, 4(2), 22.

Le, N.-T., & Pinkwart, N. (2014). Towards a classification for programming exercises. In *Proceedings of the 2nd Workshop on AI-supported Education for Computer Science*.

Lefevre, M. (2009). *Processus unifié pour la personnalisation des activités pédagogiques : méta-modèle, modèle et outils*. Thèse de doct. Université Claude Bernard Lyon 1.

Lishinski, A., Yadav, A., Enbody, R., & Good, J. (2016). The Influence of Problem Solving Abilities on Students' Performance on Different Assessment Tasks in CS1. In *proceedings of the 47th ACM technical symposium on computing science education* (pp. 329-334).

Lister, R., & Leaney, J. (2003). Introductory programming, criterion-referencing, and bloom. In *ACM SIGCSE Bulletin* (pp. 143-147).

Luck, M., & Joy, M. (1999). A secure on-line submission system. *Software: Practice and Experience*, 29(8), 721-740.
Luxton-Reilly, A., Simon, Beker, B. A., Albluwi, I., Giannakos, M., Amruth N., K., ...
Szabo, C. (2018). Introductory Programming: A Systematic Literature Review. In
*Proceedings Companion of the 23rd Annual ACM Conference on Innovation and
Technology in Computer Science Education* (pp. 55–106).

Mayer, R. E., Dyck, J. L., & Vilberg, W. (1986). Learning to program and learning to think: what's the connection? *Communications of the ACM*, 29(7), 605–610.

McGettrick, A., Boyle, R., Ibbet, R., Lloyd, J., Lovegrove, G., & Mander, K. (2005). Grand challenges in computing : Education—a summary. *The Computer Journal*, *48*(1), 42–48.

Mead, J., Simon, G., John, H., Richard, J., Juha, S., Caroline, S. C., & Linda, T. (2006). A Cognitive Approach to Identifying Measurable Milestones for Programming Skill Acquisition. *ACM SIGCSE Bulletin*, *38*(4), 182–194.

Milne, I., & Rowe, G. (2002). Difficulties in Learning and Teaching Programming — Views of Students and Tutors. *Education and Information Technologies*, *7*(1), 55–66.
https://doi.org/10.1023/A:1015362608943

Mufti-Alchawafa, D. (2008). *Modélisation et représentation de la connaissance pour la conception d'un système décisionnel dans un environnement informatique d'apprentissage en chirurgie*. Thèse de doct. Université Joseph-Fourier-Grenoble.

Muratet, M. (2010). *Conception, réalisation et évaluation d'un jeu sérieux de stratégie temps réel pour l'apprentissage des fondamentaux de la programmation*. Thèse de doct.
Université Toulouse III - Paul Sabatier. Retrieved from http://tel.archives-ouvertes.fr/tel-00554287/

Narciss, S. (2008). Feedback strategies for interactive learning tasks. *Handbook of Research on Educational Communications and Technology*, *3*, 125–144.

Nicol, D. (2007). E-assessment by design: using multiple-choice tests to good effect. *Journal of Further and Higher Education*, *31*(1), 53–64.

Nijimbere, C. (2015). *L'enseignement de savoirs informatiques pour débutants, du second cycle de la scolarité secondaire scientifique à l'université en France. Une étude comparative*. Thèse de doct. Université Paris Descartes.

Novak, J. D., & Gowin, D. B. (1984). *Learning how to learn*. (C. U. Press, Ed.).

Ott, C., Robins, A., & Shephard, K. (2016). Translating Principles of Effective Feedback for Students into the CS1 Context. *ACM Transactions on Computing Education (TOCE)*, *16*(1), 1.
Pears, A., Seidman, S., Malmi, L., Mannila, L., Adams, E., Bennedsen, J., ... Paterson, J. (2007). A survey of literature on the teaching of introductory programming. *Acm Sigcse*, 39(4), 204–223. Retrieved from http://dl.acm.org/citation.cfm?id=1345441

Piton, T. (2011). *Une Méthodologie de Recommandations Produits Fondée sur l'Actionnabilité et l'Intérêt Économique des Clients : Application à la Gestion de la Relation Client du groupe VM Matériaux*. Thèse de doct. Université de Nantes.

Polya, G. (1957). How to solve it. Prentice University Press.

Prévit, D. (2008). *Génération d'exercices et analyse multicritère automatique de réponses ouvertes: PépiGen, un système auteur en algèbre élémentaire*. Thèse de doct. Université du Maine.

Py, D. (1998). Quelques méthodes d'intelligence artificielle pour la modélisation de l'élève. *Sciences et Techniques Educatives*, 5(2).

Qian, Y., & James, L. (2017). Students' Misconceptions and Other Difficulties in Introductory Programming: A Literature Review. *ACM Transactions on Computing Education (TOCE)*, 18(1), 1.

Rahman, khirulnizam abd, & Nordin, M. J. (2007). A Review on the Static Analysis Approach in the Automated Programming Assessment Systems. In *Proceedings of the national Conference on Programming*, 07, Kuala Lampur, Malaysia.

Rahman, khirulnizam abd, Nordin, M. J., & Che, W. S. B. C. (2008). Automated programming assessment using the pseudocode comparison technique: Does It Really Work? In *International Symposium in Information Technology (ITSim)* (pp. 1–4).

Raîche, G. (2004). L'évaluation des compétences à l'enseignement supérieur. Vers une vision intégratrice de l'évaluation des apprentissages. *Montréal, Québec : Université Du Québec à Montréal*.

Ramousse, R., Le Berre, M., & Le Guelte, L. (1996). Introduction aux statistiques.

Reek, K. A. (1989). The TRY System - or - How to Avoid Testing Student Programs. In *ACM SIGCSE Bulletin* (pp. 112–116).

Renumol, V. G., Jayaprakash, S., & Janakiram, D. (2009). Classification of cognitive difficulties of students to learn computer programming. *Indian Institute of Technology*, 12. Retrieved from http://dos.iitm.ac.in/publications/LabPapers/techRep2009-01.pdf
Robins, A., Rountree, J., & Rountree, N. (2003). Learning and Teaching Programming: A Review and Discussion. *Computer Science Education, 13*(2), 137–172.
https://doi.org/10.1076/csed.13.2.137.14200

Romli, R., Sulaiman, S., & Zamli, K. (2013). Designing a test set for structural testing in automatic programming assessment. *International Journal of Advanced Soft Computing and Application, 5*(3), 1–24.

Rongas, T., Kaarna, A., & Kalviainen, H. (2004). Classification of computerized learning tools for introductory programming courses: Learning approach. *Proceedings - IEEE International Conference on Advanced Learning Technologies, ICALT 2004*, 678–680.
https://doi.org/10.1109/ICALT.2004.1357618

Santos, Á., Gomes, A., & Mendes, A. (2013). A taxonomy of exercises to support individual learning paths in initial programming learning. In *Frontiers in Education Conference, IEEE* (pp. 87–93). https://doi.org/10.1109/FIE.2013.6684794

Scallon, G. (2000). L'évaluation formative. *Éditions Du Renouveau Pédagogique*.

Schorsch, T. (1995). An Automated Self-Assessment Tool To Check Pascal Programs For Syntax, Logic And Style Errors. In *ACM SIGCSE Bulletin* (pp. 168–172).

Selby, C. C. (2015). Relationships: computational thinking, pedagogy of programming, and Bloom's Taxonomy. In ACM (Ed.), *Proceedings of the workshop in primary and secondary computing education* (pp. 80–87).

Shaffer, D., Doube, W., & Tuovinen, J. (2003). Applying Cognitive Load Theory to Computer Science Education. In *15th Workshop of the Psychology of programming Interest Group* (pp. 333–346). Keele UK. Retrieved from
http://www.ppig.org/sites/ppig.org/files/2003-PPIG-15th-shaffer.pdf

Shuhidan, S., Hamilton, M., & D'Souza, D. (2009). A Taxonomic Study of Novice Programming Summative Assessment. In *Proceedings of the Eleventh Australasian Conference on Computer Education-Volume 95* (pp. 147–156).

Sweller, J. (1988). Cognitive Load During Problem Solving: Effects on Learning. *Cognitive Science, 12*(2), 257–285.

Tan, P. H., Ting, C. Y., & Ling, S. W. (2009). Learning difficulties in programming courses: Undergraduates' perspective and perception. In IEEE (Ed.), *ICCTD 2009 - International Conference on Computer Technology and Development* (pp. 42–46).
https://doi.org/10.1109/ICCTD.2009.188
Tchounikine, P. (2009). Précis de recherche en ingénierie des EIAH. Retrieved October 20, 2016, from http://membres-liglab.imag.fr/tchounikine/Precis.html

Tribollet, B., Françoise, L., & Laurence, J. (2000). Protocoles d'emploi des cartes conceptuelles au lycée et en formation des maîtres. *Trema, 18*, 61–78.

Truong, N., Roe, P., & Bancroft, P. (2004). Static Analysis of Students' Java Programs. In *Proceedings of the Sixth Australasian Conference on Computing Education-Volume 30* (pp. 317–325).

Tullis, T. S., & Stetson, J. N. (2004). A comparison of questionnaires for assessing website usability. In *Usability professional association conference* (pp. 1–12).

Wang, F. L., & Wong, T.-L. (2008). Designing Programming Exercises with Computer Assisted Instruction. In Springer (Ed.), *International Conference on Hybrid Learning and Education* (pp. 283–293). Berlin, Heidelberg.

Wang, T., Su, X., Wang, Y., & Ma, P. (2007). Semantic similarity-based grading of student programs. *Information and Software Technology, 49*(2), 99–107.

Whalley, J., Clear, T., Robbins, P., & Thompson, E. (2011). Salient elements in novice solutions to code writing problems. In *Proceedings of the thirteenth Australasian Computing Education Conference- Volume 114* (pp. 37–46). Australian Computer Society, Inc.

Winslow, L. E. (1996). Programming pedagogy---a psychological overview. *ACM SIGCSE Bulletin, 28*(3), 17–22. https://doi.org/10.1145/234867.234872

Zamin, N., Mustapha, E. E., Sugathan, S. K., Mehat, M., Ellia, & Anuar. (2006). Development Of A Web-Based Automated Grading System For Programming Assignments Using Static Analysis Approach. In *Proceedings of the international Conference on Technology and Operations Management*.